개발자 맷은 결심했다. 오늘이야말로 저 지긋지긋한 유령 버그, ‘알림 아이콘’에 종지부를 찍겠다고. 그는 뜨거운 커피를 한 모금 들이켜고는, 마치 전장에 나서는 장수처럼 비장하게 키보드 위에 손을 올렸다.
“이번에야말로 끝장이다.”
그의 첫 번째 무기는 브라우저의 개발자 도구였다. 그는 페이스북 페이지를 열고 문제의 알림 아이콘 위에서 오른쪽 클릭, ‘요소 검사’를 선택했다. 화면 한쪽에 복잡한 HTML 코드들이 펼쳐졌다.
<span id="notification_count_wrapper">
<span id="notification_badge_count">1</span>
</span>
범인은 저 id="notification_badge_count"를 가진 <span> 태그였다. 이제 이 녀석을 조종하는 자바스크립트 코드를 찾아내기만 하면 된다. 그는 터미널을 열어 프로젝트 전체에서 ‘notification_badge_count’라는 문자열을 검색했다.
결과는 처참했다. 수십 개의 파일 목록이 화면을 가득 채웠다. 메시지, 친구 요청, 이벤트 초대, 담벼락 댓글, 사진 태그… 페이스북의 거의 모든 기능이 저 작은 숫자 하나에 관여하고 있었다.
맷은 끈질겼다. 그는 몇 시간에 걸친 추적 끝에 가장 유력한 용의자 코드를 찾아냈다. 친구 요청을 수락했을 때 실행되는 코드 블록이었다. 요청을 수락하면 알림 숫자가 하나 줄어야 하는데, 특정 조건이 겹쳤을 때 그 부분이 실행되지 않고 건너뛰는 것을 발견했다.
“찾았다!”
그는 환호성을 지르며 코드를 수정했다. 친구 요청을 처리한 후, 무조건 알림 숫자를 다시 계산해서 업데이트하도록 명시적인 코드를 추가했다. 로컬 테스트 환경에서 버그는 완벽하게 사라졌다. 새로운 알림이 올 때만 숫자가 나타났고, 확인하면 귀신같이 사라졌다. 완벽한 승리였다.
의기양양하게 수정된 코드를 중앙 저장소에 올리고, 동료들에게 자랑스럽게 외쳤다.
“알림 버그, 제가 해결했습니다!”
바로 그 순간이었다. 코드가 실제 서버에 반영되자마자, 사내 메신저가 미친 듯이 울리기 시작했다. QA팀의 제인이었다.
“맷! 방금 뭘 배포한 거죠? 사용자들이 보낸 메시지가 수신자에게 제대로 도착하지 않는다는 리포트가 폭주하고 있어요!”
맷의 피가 차갑게 식었다. 메시지라고? 알림 아이콘과 메시지가 대체 무슨 상관이란 말인가? 그는 부리나케 원인 파악에 나섰다. 그리고 잠시 후, 경악스러운 사실을 발견했다.
메시지 전송 스크립트는 메시지를 보내기 직전, 아주 기묘한 검사를 하고 있었다. 바로 $('#notification_badge_count').text()를 호출해 현재 알림 숫자를 읽어오는 것이었다. 그리고 그 숫자를 기반으로 다른 로직을 처리하고 있었다. 오래전 다른 개발자가 임시방편으로 추가해 놓은 코드였다.
맷이 수정한 코드는 알림 숫자를 ‘더 자주, 더 정확하게’ 업데이트했다. 그 결과, 메시지 스크립트가 숫자를 읽어오는 바로 그 찰나의 순간에 값이 바뀌어 버렸고, 연쇄적으로 로직이 꼬이면서 메시지 전송 시스템 전체를 마비시킨 것이었다.
그는 허탈하게 의자에 등을 기댔다. 이건 배신이었다. 자신이 믿었던 코드가, 자신이 만든 로직이 자신의 뒤통수를 친 것이다. 하나의 버그를 잡기 위해 더 큰 버그를 만들어 낸 꼴이었다.
그때, 등 뒤에서 나지막한 목소리가 들렸다.
“맷.”
조던 워크였다. 그는 맷의 모니터에 떠 있는 엉망진창이 된 코드들을 보며 조용히 물었다.
“만약에 말이야, 메시지 팀이 알림 팀의 코드를 아예 읽을 수 없다면 어떨까?”
“네? 그게 무슨…”
“메시지 스크립트가 알림 아이콘의 숫자가 몇인지 전혀 신경 쓰지 않는 거지. 알림 아이콘도 메시지가 오는지 마는지 전혀 모르고. 각자 그냥… 위에서 내려오는 명령만 처리하는 거야. 마치 서로 다른 부서에서 일하는 직원들처럼.”
맷은 그 말의 깊은 뜻을 아직 이해할 수 없었다. 하지만 조던의 눈빛은 무언가 근본적인 해답을 꿰뚫어 보는 듯했다. 그는 지금의 혼돈과는 전혀 다른, 새로운 질서에 대한 확신에 차 있었다.
