2005년, 스마트폰이라는 단어조차 생소하던 시절입니다. 사람들은 벨소리 64화음에 감동하고, 화면이 가로로 돌아가는 '가로본능' 핸드폰에 열광했죠. 저는 당시 휴대전화 SW 개발을 하고 있었습니다.
출시를 앞둔 긴박한 검증 시즌, 품질 검수(QA) 팀에서 아주 디테일한 ‘버그 리포트’가 날아왔습니다.
문제의 버그: 비프음의 일관성
- 경로 A: 통화 중 [메뉴] → [1번 키패드] → [1번 메뉴] 선택 시: 비프음 "삐빅!" (두 번)
- 경로 B: 통화 중 [메뉴] → [방향키 이동] → [OK] 선택 시: 비프음 "삑!" (한 번)
요청 사항: "경로 A도 경로 B처럼 한 번만 울리게 수정해 주세요."
저는 이 업무를 팀의 신입 여직원에게 맡겼습니다. 비록 신입이지만 경력도 2년이나 있었기에, '비프음 출력 함수'의 로직만 살짝 손보면 되는 이 일은 식은 죽 먹기라 생각했죠.
🛠 수정 완료, 그리고 찾아온 '정적'
얼마 후, 그녀가 당당하게 보고했습니다. “대리님! 이제 경로 A에서도 비프음이 한 번만 울려요!”
오~~. 짧은 감탄 후 저는 확인을 해보았습니다. 그런데... 이상했습니다. 경로 A만 고쳐진 게 아니었습니다. 통화 중 메뉴를 누를 때 나야 할 모든 비프음이 사라졌던 것입니다.
핸드폰이 갑자기 절에 들어간 스님처럼 묵언 수행에 들어간 것이죠. 순간 불길한 예감이 들었죠. "OO씨 모든 비프음이 사라졌어요, 어떻게 처리한거죠?" 그곳에서 저는 ‘절대 고독’의 철학을 마주했습니다.
/* 신입 사원이 작성한 전설의 코드 */
bool b_skip_beep = true; // 비프음을 건너뛸 것인가? 초기값 "Yes!"
void mmi_play_menu_beep(void)
{
// b_skip_beep가 false이면 비프음을 울려라.
// 즉, 이 조건문은 지구 멸망 전까지 실행될 일이 없다.
if(false == b_skip_beep)
{
play_beep();
}
}💬 “대리님, 그건 세상에 존재하지 않아요.”
저는 떨리는 목소리로 그녀에게 물었습니다.
나: “...저기, 이 b_skip_beep라는 변수가 false로 바뀌는 시점은 코드 어디에 있나요?” (즉, 비프음이 다시 울리게 설정되는 로직이 어디 있냐는 질문이었죠.)
그러자 그녀는 아주 맑고 순수한 눈망울로, 마치 제가 당연한 걸 묻는다는 듯 대답했습니다.
“없는데요?”
“없는데요?”... “없는데요?”... 그 대답은 제 귓가에 비프음보다 더 강렬하게 맴돌았습니다.
그녀의 논리는 명쾌했습니다. “비프음이 두 번 울리는 게 문제라고 하셔서, 아예 안 울리게 초기값을 잡아버렸어요. 그러면 두 번 울릴 일도 없잖아요?”
💡 오늘의 교훈: 빈대 잡으려다 초가삼간 다 태운다
그날 이후, 그녀는 우리 팀에서 아주 중요한 업무를 맡게 되었습니다. 로직의 미궁에 빠질 위험이 없는 'UI 레이아웃 수정'과 '메뉴 텍스트 변경' 전담 요원이 되었죠.
2005년의 그 사건은 저에게 큰 깨달음을 주었습니다.
- 경력의 숫자가 반드시 실력을 보장하진 않는다.
- 완벽한 버그 수정은 그 기능을 세상에서 없애버리는 것이다(?).
- 질문할 때는 대답이 "없는데요"가 나올 가능성을 항상 염두에 두자.
혹시 여러분의 코드 어딘가에도, 영원히 false가 될 수 없는 슬픈 변수가 잠자고 있지는 않나요? 사소한 예외 처리가 때로는 시스템 전체를 침묵하게 만들 수 있다는 사실, 우리 임베디드 개발자들은 항상 경계해야 할 것 같습니다.
여러분의 가장 기억에 남는 '삽질' 에피소드는 무엇인가요?
'개발 삽질의 기록(Dev Digging Log)' 카테고리의 다른 글
| 기존 코드의 함정과 급박한 수정이 부른 NullPointerException 대참사: 2013년 개발 잔혹사 (0) | 2026.05.06 |
|---|---|
| 마지막 릴리즈 날 걸려온 이사님의 전화 "허허허" 웃음 뒤에 숨겨진 최악의 릴리즈 사고 (0) | 2026.05.05 |