버그를 두려워 하거나 부끄러워 하는 개발자가 많다. 10년 전 월스트리트에서 CDS와 채권거래 시스템을 개발하던 시절, 매일 받은 심리적 압박이 기억난다. 사소한 버그가 어마어마한 돈의 방향을 바꿀 수 있기 때문에 코드의 정확성은 생명과 같았다. 런던에 출장을 가서 거래소에서 여러 사용자와 대화를 나누는데 우리가 만든 소프트웨어에서 버그가 출몰한 적이 있었다.
누군가와 통화를 나누던 사용자는 수화기를 던지며 욕설을 퍼부었고, 나는 그의 원초적인 분노를 받아내며 디버깅을 위한 자료를 수집해야 했다. 대체로 회사의 규모가 작을수록 개발자가 작성하는 코드와 회사의 비즈니스 사이의 간격이 좁아진다. 코드가 비즈니스에 미치는 영향이 더 직접적이라는 뜻이다. 그런 상황에서 버그를 양산한 개발자는 식은땀을 흘릴 수밖에 없다. 지옥행 급행열차에 올라타는 것이다.
지금 다니는 회사에서도 오묘한 곳에 숨어있는 버그를 잡은 적이 있다. 그럴 때마다 우리 눈 앞에는 지옥문이 활짝 열렸다. 1분 1초를 허비할 수 없는 절박한 위기감, CEO의 사무실에서 터져나오는 고함과 비명소리, 머리 잃은 닭의 몸통처럼 이리저리 뛰어다니는 개발자. 당황한 마음이 쏟아내는 잘못된 분석과 데이터. 영웅이 되고 싶은 욕망이 만들어내는 터무니 없는 제안. 이런 혼란과 소음이 가득한 미로 속에서 시간낭비 없이 정확히 길을 찾는 건 쉬운 일이 아니다.
버그는 기본적으로 송충이나 돈벌레처럼 징글징글하다. 그럴 수만 있다면 보거나 만지지 않고 살고 싶다. 하지만 버그가 없는 코드는 없다. 버그는 코드의 일부다. 그래서 버그의 유무가 아니라, 버그를 대하는 태도가 핵심이다. 나는 개발자라면 피할 수 없는 버그와의 투쟁을 다년간 경험하면서 버그에 반응하는 방식에 따라 개발자를 분류할 수 있음을 알게 되었다.
첫째는 당황류다. 가장 일반적인 유형이다. 자기가 작성한 코드에서 버그가 발생하면 멘탈이 붕괴하고 유체가 이탈한다. 문제를 해결하는 것보다 상사에게 사과하는데 더 집중하며, 자기가 작성한 코드의 논리적인 흐름을 다른 사람에게 설명하지 못한다. 문제가 해결된 이후에도 한동안 의기소침한 분위기가 지속되고, 외롭고 쓸쓸한 심정이 되어 이력서를 만지작거린다. 사과는 열심히 하지만 정작 문제해결은 다른 사람에게 기댄다는 점에서 무기력하다.
둘째는 뻔뻔류다. 버그를 만나면 앞의 당황류는 무기력한 태도와 사과로 시간을 허비하지만, 뻔뻔류는 잘잘못을 가리는데 치중한다. 100정도 되는 자기 잘못은 1로 축소시키고 1정도 되는 타인의 잘못을 100으로 확대해서 상황을 설명한다. 문제해결에 집중해야 하는 상황에서 코드 변경 히스토리를 뒤적거리며 누가 어떤 잘못을 범했는지 알아내는데 몰두한다. 매니저나 리더가 자기 코드를 수정해야 한다고 결정을 내리면 어쩔 수 없이 코드를 수정하지만 구구절절한 사연을 포기하지 않는다. 내 코드를 고치는 건 임시방편일 뿐이고, 다른 사람이 작성한 코드를 수정하는 것이 장기적으로 보았을 때 올바른 해결책이라고 사설을 늘어놓는다. 끝까지 자기 잘못을 인정하지 않는 것이다.
셋째는 호들갑류다. 영웅주의에 경도된 일부 개발자도 여기에 속한다. 버그가 자기 코드에서 발견되었는지 아니면 다른 사람의 코드에서 발견되었는지 크게 중요하게 생각하지 않는다. 일단 버그가 나타나면 세상이 무너질 것처럼 호들갑을 떨고, 이리저리 뛰어다니며 먼지를 일으킨다. 머리에 즉흥적으로 떠오르는 생각을 단정적으로 말하여 혼란을 야기하고, 쓸모 없는 분석과 제안으로 시간을 소모한다. 버그가 나타나지 않았으면 어쩔 뻔 했을까, 할 정도로 버그 앞에서 에너지가 넘친다. 누가 시키지 않았는데 자기 하던 일을 내려놓고 버그를 잡는데 힘을 쏟는다. 다만 에너지가 문제를 해결하는 방향으로 모이지 않고 무의미하게 흩어진다는 점에서 별 도움은 되지 않는다.
마지막은 침착류다. 표정만 보면 뻔뻔류와 비슷하다. 자기가 작성한 코드에서 버그가 발견되어도 당황하지 않는다. 멘붕도 없다. "미안하다", "다음부터 이런 일이 없도록 하겠다"는 식의 비굴한 말은 아예 입에 담지 않는다. 호들갑류처럼 먼지도 날리지 않는다. 침착류는 우선 버그가 등장한 상황을 이해하기 위해서 필요한 자료를 모은다. 로그 파일, 사용자 설명, 시간, 이벤트, 쓰레드 덤프, 메모리 사용량, 시각적 그래프 등을 남김없이 모아서 다른 개발자와 실시간으로 공유한다.
버그가 서식하는 지역을 정확하게 파악하기 위해서 동료들과 상의하여 논리의 천라지망을 구축한다. 추측이나 상상이 아닌 정확한 논리에 근거해서 다음 단계를 설정하고, 검증한 길은 목록에서 하나씩 제거해 나간다. 상사나 매니저에게 자기가 지금 무엇을 하고 있고, 언제까지 시간이 필요한지 수시로 알려주고, 필요한 도움이 있으면 지체없이 이야기해서 여러 가지 작업이 동시에 진행될 수 있게 만든다. 누군가 당황하거나 분노하여 감정을 드러내면 한 귀로 듣고 한 귀로 흘려 보낸다. 그런 감정에 반응하는 것은 문제해결에 도움이 되지 않기 때문이다. 시시비비를 가리는 것도 나중 문제다.
문제가 해결된 이후에는 자기가 문제를 일으킨 이유를 냉정하게 분석해서 공유하고, 같은 실수를 되풀이 하지 않을 방법을 찾는다. 예를 들어서 해당 코드를 작성할 때 시간적 압박을 심하게 받아서 단위 테스트를 작성하지 못할 정도로 서둘렀다고 하자. 이 경우 침착류는 매니저를 포함한 동료들과 시간적 압박과 코드 품질의 상관관계를 상의하여 비슷한 실수가 반복되지 않도록 만들 방법을 모색한다. 버그를 프로세스 개선으로 연결시키는 것이다.
최근 린펍에서 ‘Errors: Bugs, Boo-boos, Blunders’를 출간한 제랄드 웨인버그(Gerald M. Weinberg)는 아예 버그는 존재하지 않는다고 주장한다. 그에 의하면 세상의 모든 코드는 저마다의 존재 이유가 있으며 서로 상대적이다. 어떤 코드에서 버그로 해석되는 동작이 어떤 코드에서는 의도적인 기능으로 인식된다. 버그는 보편적인 참과 거짓의 문제가 아니라 상대적인 해석의 문제라는 것이다. 선과 악이라는 윤리적 차원의 문제는 더욱 아니다.
웨인버그의 주장을 받아들이면 개발자에게 버그는 부끄러운 것이 아니다. 코딩이라는 행위의 자연스러운 일부다. 개인의 능력에 관한 문제가 아니라 사용자 요구사항이나 개발환경 전체와 관련된 문제다. 현장에서 발견된 버그 때문에 당황하거나 무기력해 하는 개인이 있으면 오히려 팀이나 그룹이 그 사람에게 미안함을 느껴야 한다. 버그가 발생하는 원인을 분석하면 놀라울 정도로 많은 경우에 그 책임이 개인이 아니라 개인을 그런 상황으로 몰아넣은 환경에 있음을 알게 되기 때문이다.
사랑을 해보지 않은 사람이 성인이 될 수 없는 것처럼, 버그 때문에 상처받지 않은 사람은 진정한 개발자가 될 수 없다. 개발자는 버그를 통해서 배우고, 실력을 쌓아 나간다. 책에서 배운 지식은 회색이고 오직 영원한 것은 버그와의 투쟁을 통해서 얻은 깨달음이다. 버그를 양산하는 것을 두려워 하지 말라. 버그 앞에서 침착하지 않을 것을 두려워하라. 버그는 틀림이 아니라 다름이라는 웨인버그의 말을 기억하자. 그리하여 버그는 나의 힘이다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
임백준 IT칼럼니스트 (baekjun.lim@gmail.com)