Extremely Agile - 프로그래머 16

프로그래머 16 :: 2009/05/05 23:44

[이전 글에서 계속...]

그래서 저는 유식에게 물었습니다. "어떻게 했습니까?" 그가 대답했습니다. "어떻게 하다뇨?" 저는 다시 물었죠. "그 일을 계속 했느냐구요."

별 도리가 없었습니다. 그는 그 일을 계속 했습니다. 아니, 이전보다 더 열심히 했죠. 연구소장은 당황했습니다. 애초 의도와는 달리, 유식의 태도는 점점 더 진지해져 갔으니까요.

실질적으로 그 일에 관한 한, 유식씨가 팀장이었습니다. 비슷한 연배라 누가 팀장이고 누가 팀원이다 이런 개념은 없는 상태로 일했는데, 어느날 유식씨가 새 명함이라면서 한장씩 돌리길래 보니 '팀장'이라고 떡 하니 찍혀 있더군요. SI개발팀장이라구요. 그래서 유식씨가 회의를 소집하면 우리 모두 '예, 팀장님" 하고 웃으면서 응했습니다.

그런데 하루는 이런 일이 있었습니다. 유식씨가 그 '3억' 회사에 외근을 나갔다가 들어와서는 심각한 표정으로 미팅을 하자고 이야기를 하더라구요. 그래서 모두 모였습니다. 무슨 일인지 궁금했죠. 그런데 유식씨가 쉽게 말문을 열지 않는 겁니다. 한 일분 정도? 모두의 얼굴을 빤히 쳐다보기만 하는 겁니다. 아시잖아요. 그런 상황이 되면 시간이 평소보다 길게 느껴지는거. 견디다 못한 한 사람이 (유식씨보다 세살 윈가 그랬습니다) 유식씨에게 물었습니다.

"무슨 일이길래 그러시나요?"

"저 쪽에서 우리가 개발한 서버 페이지들을 테스트하기 시작했어요."

"그런데요?"

"베타 테스트 시작한 지 삼십분 만에 서버가 뻗었습니다. 저도 가서 확인했구요. 데이터베이스 접속이 종료되어서 복구되지가 않습니다."

모두들 웅성거렸습니다. 큰일은 큰일이었죠. 사이트 오픈까지 보름 남짓 남았는데 DB 접속이 뻗는다니.

"DB쪽 코딩은 어느 분이 하셨죠?"

"제가 했습니다."

유식씨보다 세살 많은 프로그래머, 바로 그 사람이었습니다. 그 분의 표정도 이제 눈에 보일 정도로 굳어 있었죠.

"테스트를 제대로 하신 건가요?"

"... 어느 정도까지 해야 '제대로' 한 건지는 모르겠습니다만, 하느라고 했습니다."

"만드신 API를 쓰는 분들하고 연동 시험까지 다 하신 건가요?"

"기본적인 것은 했습니다만..."

"30분 이상 돌려보신 적은 없으시죠?"

그쯤 되자 분위기가 조금씩 살벌해지기 시작했습니다. 말은 꺼내지 않았습니다만, '이거 좀 너무한다'는 생각들을 하기 시작했죠. 어차피 팀장이라는 직함도 자임한 것인데, 사정 다 아는 처지에 이렇게까지 추궁해야 하나 싶었던 것이죠. 그런데 추궁을 당하던 그 분이 대뜸 이렇게 물었습니다.

"그렇게까지 할 필요가 있나요?"

그러자 갑자기 유식씨가 의자에 깊숙히 몸을 기대며 뒤로 조금 물러 앉더군요.

"무슨 말씀이죠?"

"어차피 우리 일도 아닌데 그렇게까지 해 줄 필요가 있느냐는 말입니다. 그냥 SI 아닙니까? 우리 일에 쏟아부을 시간도 없어서 다들 진이 빠질 지경인데 무슨 이런 프로젝트에까지 그렇게 성심 성의껏..."

그 말을 들은 유식씨는 잠깐 동안 아무 말도 하지 않았습니다.

뭔가를 생각하느라 아무 말도 하지 않았던 것은 아닐 겁니다. 나중에 알게 된 일이지만 유식군은 말을 하기 전에 생각부터 깊이 하는 스타일은 아니었어요. 그 순간, 그는 그저 말문이 막혔던 겁니다. 자기 딴에는 심각하기 짝이 없는 이슈를 제기한 것인데, 듣는 사람은 대뜸 그 문제 제기의 엉뚱한 지점을 걸고 넘어지고 있었으니까요.

그래서 그는 이렇게 대답했습니다.

"우리가 하겠다고 도장을 찍은 일은 다 우리 일입니다."

회의는 이렇다 할 결론 없이 끝났습니다. 하긴 결론이 있을 수가 없었죠. "최대한 빨리, 최대한 많은 버그를 신속하게 찾아 낸다"는 것은 원칙이지 결론이라고 볼 수는 없으니까요. 그들은 그냥 원칙을 충실하게 따르자는 데 합의하고, 그날부터 테스트를 위해 밤을 새기 시작했습니다.

그리고 그날부터 보름간 지속된 야근 행군은 그들이 까먹은 초코파이와 컵라면 숫자 만큼이나 지리멸렬했습니다. 새로운 기능을 추가할 시간은 거의 주어지지 않았고, 그들은 시스템을 동결시킨 다음에 버그의 위치를 추적하기 위한 System.out.println을 산더미같이 코드에 삽입했습니다. 버그가 하나 잡힐 때 마다 화이트보드에 슬래쉬 기호가 그려졌습니다. 하지만 대미를 장식할 마지막 버그, 30분마다 시스템을 동결시키는 바로 그 최악의 버그는 아직 모습을 드러내지 않고 있었습니다.

마지막 보름째 되던 날, 그들은 계속해서 밀려오는 졸음기에 잔뜩 젖은 얼굴로 밤 11:00 정각에 커피 타임을 가졌습니다.

"어떻게 되어 가고 있습니까?" 유식이 물었습니다.

"어제 릴리즈 브랜치를 따로 쪼갰습니다. 그러니 저쪽 요구사항은 그쪽 브랜치에 수용하면 됩니다. 릴리즈 날짜가 일주일 늦춰져서, 새로 추가된 요구사항을 받아들일 시간이 생겼죠. 그래서 두 명이 그 작업을 해야 하는데, 너무 피곤해 해서 일단 그 두 명은 집에 보냈습니다. 자고 내일 정오에 나오라고 했습니다."

"잘하셨습니다. 그런데 그 버그가 어디 있는지는 아직 확인을 못한 건가요?" 유식이 다시 물었습니다. 그러자 거의 눈을 감은 채로 회의를 듣던 한 프로그래머가 입을 열었습니다.

"결국 안쪽 코드부터 테스트를 해 나가고 있습니다. 이렇게 바깥쪽으로 나가다 보면, 문제가 발견되겠죠."

"일주일 안에 말이죠." 유식이 말했습니다. 그러자 그 프로그래머가 다시 답했습니다.

"네. 일주일 안에."

"잘 되어야 할텐데." 유식이 뇌까렸습니다. 모두들 고개를 끄덕였습니다. 잘 되어야 할 텐데. 그리고 회의실에는 그들이 느끼는 피곤함의 총합보다 무거운 정적이 찾아왔습니다. 모두들 회의실 의자에 몸을 파묻고, 한 가지 만을 생각하고 있었습니다. 대체, 그 버그는, 어디에 있는가.

바로 그때였습니다.

"아."

갑자기 회의실 한 쪽 구석에서 실낱같은 탄식이 터져나왔습니다. 평소같으면 무시하고 말 정도의 데시벨이었습니다만, 그들은 너무 지쳐 있었습니다. 제발 상황을 반전시킬만한 발견이기를 기원하는 간절한 눈빛들이, 그 프로그래머의 얼굴에 꽂혔습니다.

순간, 그 프로그래머는 반사적으로 자리를 박차고 일어났습니다. 그리고는 자리로 돌아가, 미친듯이 무언가를 두들기기 시작했습니다. 그러기를 십여분. 모두들 그의 뒤에 모였습니다. 그리고는 그가 하는 양을 물끄러미 쳐다보기 시작했습니다. 모두가 그의 손에서 미칠듯이 뿜어져 나오는 System.out.println과 시시각각 변해 가는 로그 메시지를 바라보고 있었습니다. 그러자, 또 누군가의 입에서 가느다란 탄식이 흘러나왔습니다.

"아."

그 탄식은 순식간에 모두를 감염시켰습니다. 모두들 아, 하는 소리를 내 뱉었습니다. 누군가는 껄껄 웃었고, 누군가는 자리로 돌아가 훌쩍거렸습니다. 보름 동안의 야근 끝에, 그토록 찾아 헤메던 버그가 발견된 것입니다.

제가 나중에 유식씨에게 물었습니다. "어떤 버그였나요?"

그러자 유식씨는 이렇게 대답하더군요.

DB 접속을 해제하는 코드를 누군가가 finalize 블럭 안에 넣어놨더군요. 누군지는 알고 싶지 않아서 묻지 않았습니다. 당시 용역을 준 회사에 소프트웨어 테스팅에 관심있는 친구가 한 명 입사했는데, 그 친구가 자동화된 서버 테스팅 툴을 도입해서 서버를 스트레스 테스트하고 있었어요. 우리도 당연히 그 툴을 공유했구요. 30분 마다 서버가 죽은 건, 그 삼십분 동안 계속해서 발생한 HTTP REQUEST가 서버의 가비지 콜렉터를 극한까지 밀어부쳤기 때문이었습니다. 결국 finalize 블럭이 실행되었고, 그 덕에 DB 접속이 닫힌 거죠. 아, 물론 여기까지 들으면 감이 오시겠지만, 그건 우리가 발견한 문제의 결과이지 진짜 원인은 아니었습니다. 진짜 원인은, 배열 안에 저장된 객체 참조가 삭제되지 않은 것이었어요. 덕분에 메모리 누수가 생겼고, 메모리가 객체들로 가득 차자 가비지 콜렉터가 발광을 시작했던 것이죠.

그 사소한 버그가 그토록 오랜 시간 동안 우리를 괴롭힌 것은, '30분'이라는 절묘함때문이었습니다. 모두가 '왜 하필 30분일까'를 고민하고 또 고민했죠. 하지만 그건 그저 우연일 뿐이었습니다. '하필 30분'이 아니라, '그저 30분'일 뿐이었던 거죠.

아, 운명이란!

크리에이티브 커먼즈 라이선스