1. 2013년, 스마트폰 S/W 개발 막바지의 긴박함
2013년 어느 날, 스마트폰 소프트웨어 개발 프로젝트는 거의 막바지에 다다랐습니다. 발주사 PM은 프로젝트 완수를 위해 동분서주하고 있었고, 품질팀과의 최종 협의 끝에 '양산 검증 종료'라는 큰 산을 앞두고 있었죠.
전달된 지침은 명확했습니다.
"이번 릴리즈로 양산 검증을 종료합니다. 민감하거나 복잡한 이슈는 품질 담당자와 협의하여 다음 '잔여 이슈 정리 릴리즈'로 넘기세요."
당시 제가 담당하던 SMS/MMS 파트는 대부분의 이슈가 정리된 상태였지만, 마지막 단 하나의 이슈가 발목을 잡고 있었습니다.
2. 분석되지 않은 이슈, 그리고 강행된 릴리즈
당시 SMS는 단순 메시지를 넘어, 전화번호 앞에 '#'이나 특수한 문자를 붙여 발신하는 '특수 용도 메시지' 기능을 포함하고 있었습니다. 메시지 애플리케이션 하나가 SMS, MMS, 특수 메시지를 모두 처리하다 보니 로직이 복잡했고, 그중 특정 케이스에서 메시지 타입을 오인식하는 문제가 발생했습니다.
문제는 원인이 완벽하게 분석되지 않았다는 점이었습니다.
저는 PM의 가이드에 따라 품질 담당자에게 상황을 설명했습니다. "원인 분석이 더 필요하니 다음 차수에 검증하자"고 협의를 시도했죠. 하지만 담당자는 단호했습니다. "무조건 수정해서 이번 릴리즈에 포함하세요."
PM의 의도와 현장의 압박, 그리고 PL과의 논의 끝에 결국 '수정 후 릴리즈'라는 무리한 선택을 하게 되었습니다. 급하게 원인이라 짐작되는 곳을 수정해 릴리즈 버튼을 눌렀습니다.
3. 다음 날 터진 'NullPointerException' 대참사
릴리즈 다음 날, 우려는 현실이 되었습니다. 제가 수정했던 코드가 도화선이 되어 메시지 애플리케이션이 NullPointerException으로 강제 종료되는 현상이 발생한 것입니다.
단순히 제 수정 사항만의 문제는 아니었습니다. 근본적인 원인은 기존 MMS Body를 받아오는 메서드 내부의 설계에 있었습니다. 기존 코드는 메시지 본문을 가져올 때 null 가능성을 전혀 고려하지 않은 채 구현되어 있었고, 평소에는 잘 드러나지 않던 이 허점이 제가 추가한 특수 메시지 판별 로직과 맞물리며 폭발한 것이었습니다.
완벽하게 구조를 파악하지 못한 상태에서 품질 담당자의 압박에 밀려 수행한 '급한 수정'이, 시스템 깊숙이 숨어있던 기술적 부채(Technical Debt)를 건드린 셈이었습니다.
양산 검증 종료를 앞두고 발주사는 발칵 뒤집혔고, 저희 쪽 PL님은 상황 수습을 위해 정신없이 뛰어다녀야 했습니다. 천신만고 끝에 상황이 진정되고, 다음 날 재릴리즈 일정이 잡힌 후, PL님이 저를 찾아오셨습니다.
나: "이렇게 되어서 정말 죄송합니다...
" PL: "어렵네요. 협의 안 되는 품질팀도, 일정을 몰아붙이는 PM도... 그냥 운이 없었다고 생각합시다."
PL님의 따뜻한 위로였지만, 마음은 무거웠습니다. 결국 완벽하게 분석하지 못했고, 철저하게 테스트하지 못한 제 잘못이 컸기 때문입니다.
4. 이번 '삽질'에서 배운 교훈
개발자에게 '일정'과 '품질'은 늘 외줄 타기와 같습니다. 하지만 이 사건을 통해 뼈저리게 느낀 점이 있습니다.
- 신뢰의 오류: 기존 코드는 당연히 안전할 것이라는 믿음은 매우 위험합니다.
- 분석되지 않은 수정은 독이다: 확신이 없는 코드는 수정을 안 하느니만 못합니다.
- 테스트는 타협의 대상이 아니다: 급박한 릴리즈일수록 기본을 놓치기 쉽습니다.
- 거절하는 용기: 기술적으로 위험한 상황이라면, 데이터와 근거를 가지고 더 강력하게 'No'를 외칠 수 있어야 합니다.
2013년의 그 뜨거웠던 실패 기록은 지금도 제가 코드를 짤 때 'NullPointerException'을 한 번 더 체크하게 만드는 소중한 자산이 되었습니다.
'개발 삽질의 기록(Dev Digging Log)' 카테고리의 다른 글
| 마지막 릴리즈 날 걸려온 이사님의 전화 "허허허" 웃음 뒤에 숨겨진 최악의 릴리즈 사고 (0) | 2026.05.05 |
|---|---|
| 경력 2년 차 신입의 기적(?)... 버그 고치랬더니 기능을 삭제해 버린 사연 (0) | 2026.05.04 |