나의 고등학생 때의 고민은 코 주변에 나는 여드름이었다. 자고 일어나면 얄밉게도 어제와 다르게 오늘 빨갛게 솟아 올라있는 녀석들은 나를 하루에도 수번 화장실로 가게 만들었고, 급기야 시간이 흘러 노랗게 곪아가기 시작하면 성질을 못 참고 손톱으로 꾹꾹 눌러 짜버린 후 넓어진 모공을 보고 후회하는 것이다. 여드름은 당연한 것이고, 손톱은 유일한 해결책이었다. 그래서 결국은? 지금에서는 넓어진 모공을 좁히는 획기적인 해결책이 나오기를 기대하면서 나의 피부를 후회 섞인 눈초리로 바라볼 수 밖에 없는 것이다.
나의 프로그래머 시절의 고민은 시도 때도 없이 나타나는 버그들이었다. 나에게 전달되는 경로도 다양해서 출시된 제품의 고객 민원으로 접수 된 경우, 나 혼자 테스트 하면서 발견 한 경우, 회사의 다른 분이 테스트 하다가 발견 된 경우, 물론 최악의 상황은 프로젝트 완료 보고 후 시연회에 나오는 버그. 이 것들은 꼼짝없이 야근으로 나를 몰아가고 저녁을 주문하게 만들었다. 고등학교 때 손톱으로 짰던 여드름에 후회하고 있던 나는, 이 자고 일어나면 발생하는 버그들을 더 이상 모니터에 덕지덕지 붙인 포스트잇으로 해결하지 않기로 마음 먹었다. 늘, 그렇다. 내가 고민 중이면 다른 사람도 고민하는 것이고 누군가는 이미 해결책을 만들어 놓았을 것이다.
버그를 피할 수 없는 것이라는 것은 누구나 동의하는 일이다. 100% 완벽한 인간이 존재하지 않듯이 100% 완벽한 프로그램도 존재하지 않는 다는 것을 인정해야 이야기는 출발 할 수 있다. (디지털 중의 디지털 컴퓨터에서도 100%라는 것은 존재하지 않으니 이 얼마나 아이러니한 일인가?) 역사상 수많은 위대한 프로그래머들도 버그로 고생하기는 마찬가지였다. 지금은 우주 정거장에 가 있는 찰스 시모니 할아버지 같은 구루로 칭송 받는 이들도 버그로 고민하다가 헝가리안 노테이션 같은 것도 만들고 그런 것이다.
의욕적이지 않은 나는 회사에 입사하고 쏟아지는 버그들에 위와 같은 사실을 상기하며 안심하고 있었다. “나뿐이 아니야”하면서 말이다. 주먹구구식으로 접근했던 나의 최초의 버그 관리 방법은 입사 기념으로 파란색과 초록색 2가지를 샀던 조그만 스프링노트였다. 파란색은 건설적으로 프로젝트 일정을 적는데 사용했고, 초록색은 불행하게도 수정사항. 즉 버그를 적는데 썼다. 물론, 초록색을 훨씬 금방 다 써버렸다.
혼자서 테스트를 하다가 나타나는 버그들은 바로 수정이 가능하면 기록을 남기지 않고 코드를 보면서 고쳐버렸고, 조금 시간이 걸릴 것 같거나, 지금 당장 고칠 수 없는 상황이라면 볼펜으로 그 스프링노트에 나만이 알아볼 수 있는 필기체로 휘갈겨서 적는 것이 다였다. 이때까지만 해도 버그는 부끄러운 것이고 남들이 알아서는 안 되는 것이었다. 마치, 의사들이 그러는 것 처럼 말이다. 다른 개발자나, 테스트를 했던 동료 분들로부터 들은 버그도 역시 그 조그만 스프링 노트에 기입되었다. 몇 달이 지난 후에 내가 만든 첫 제품이 출시된 후 사용자 민원으로 버그가 신고 될 때까지도 모든 버그들은 그 노트에 기록되고 수정되면 위에 한 줄로 찍 그었다. 해결 완료.
하나의 필요성이 생겼다. 바로 버그의 우선순위 관리였다. 어떤 버그는 매우 크리티컬해서 야근이 문제가 아니라 내일, 혹은 몇 시간 후까지 수정해야 하는 것도 있었고, 어떤 버그는 버그로 보고되긴 했지만 보는 사람 입장에 따라서 의견이 갈릴 수 있어 기획 쪽에서 다시 검토가 필요한 것 같은 문제였다. 이런 문제는 서둘러 내 마음대로 수정할 수 있는 것도 아니었다. 그래서 나의 버그 관리 방법을 바꿨다. 우선순위 없이 발생 순서대로 적어 놓았던 스프링노트는, 뭐부터 처리해야 할지 앞뒤를 왔다갔다하면서 찾는 귀찮음이 너무 컸던 것이다. 2권째의 스프링노트를 거의 다 썼던 시점에서 말이다.
대안으로 등장했던 것은 3M의 세기의 발명품. 포스트잇 이었다. 그렇다. 겨우 포스트잇 이었다. 작은 사이즈의 포스트잇 한 장 당 하나의 버그와 발견 날짜를 적고 모니터 하단에 좌측에서 우측으로 쭉~ 일렬로 붙여 놓는다. 가장 크리티컬한 것이 가장 좌측 끝에 위치해 있어서 버그 수정시간이 되면 (나는 하루에 2시간 정도를 버그 수정에 사용했다) 좌측부터 하나씩 때어내어 수정하기 시작한다. 수정이 완료 되었으면 간단하게 표시하고 서랍 안에 넣어놓는다. 어떤 버그는 중간에 끼어들기도 한다. 이 글을 읽는 것도 거의 프로그래머라고 가정하고 간단히 설명하면 포스트잇의 우선순위 큐인 것이다!
눈으로 보이는 자료구조를 구현했다는 뿌듯함도 있었고, 포스트잇 특유의 접착제 냄새도 좋아해서 만족하게 알록달록한 여러 가지색의 포스트잇을 사서 즐겁게 모니터를 꾸며나가고 있었는데, 회사 차원에서 정책이 바뀌는 바람에 중단 될 수 밖에 없었다. 인트라넷에 제로보드;로 게시판을 만들고 그 곳에 버그를 기록하는 것이었다. 왜냐하면 버그를 혼자만 알고 있어서는 안되기 때문이었다. 버그는 발견하거나 기록한 사람이 수정하는 것이 아니라 어떤 사람도 수정 가능하다고 가정해야 하며 그러기 위해서 발견된 버그는 퍼블릭하게 전파되어야 하기 때문이다.
옳은 철학이지만, 방법이 조금 잘못되었다. 모든 프로그래머들에게 “제로보드를 사용해서 버그를 올려놓으세요.” 라고 하자. 어떤 반응이 생겼을까? 글을 읽는 사람이 프로그래머라면 쉽게 예상할 수 있겠지만, 우선 로그인하고 글을 작성하는 귀찮음에 대부분 간단한 버그들은 기록을 남기지 않는 쪽으로 무시되어 버렸고, 일단 혼자 해결하려고 노력한 후 해결 되지 않는 정말로 심각한 버그들만 기록되게 되었다. (회사 내의 테스트의 대부분은 그 프로그램을 작성한 프로그래머에 의해 이루어 졌으므로 이런 식으로 버그 발생 자체를 무시해버릴 수 있었다.) 프로그래머의 입장에서 보면, 버그를 보고하기 위해서 인트라넷에 접속해서 글을 하나씩 작성하는 노력보다 간단한 버그를 즉시 수정해버리는 것이 효율적이었기 때문이다. 어디 버그의 보고 뿐이랴, 보고 후에 수정하고, 또 완료했다고 적는 것 조차 꽤나 시간과 노력이 드는 일이었다.
또 하나의 문제점은 명확한 표준 보고 양식이 정해지지도 않았다는 점이다. 프로그래머마다 다른 방식으로 버그를 표현하고 있었다. 최대한 품이 덜 들고 간단하게 작성하기를 원하는 프로그래머들이기 때문에 결국 버그를 퍼블릭하게 공개시키는 목적인 다른 사람들이 손대고 고칠 수 있는 만큼의 정보가 제공되지 않았던 것이다. 암호처럼 작성된 버그의 상세 설명은 두 번 다시 참조되지 않은 상태로 DB 속 저 깊은 곳으로 사라졌다.
결국 이러한 지침이 생기고 투덜거리며 제로보드에 로그인 했던 프로그래머들도 얼마 지나지 않아 다시 자기만의 버그 관리 방법으로 돌아가기 시작했고, 버그 보고를 위해 마련되었던 제로보드 게시판은 아무도 사용하지 않은 상태로 남겨졌다. 물론, 나도 다시 포스트잇의 우선순위 큐를 이용한 버그 관리 방식으로 돌아갔다. 수천 라인 정도의 개발중인 프로젝트에서는 이러한 방식의 버그관리 방법에 특별한 문제는 없는 것 처럼 보였다.
문제가 있다고 느낀 것은 내가 작성한 코드가 만 라인에 가까워져 갈 무렵이었다. 프로그램의 크기가 더 커지면서 버그의 증상을 파악해서 어느 부분에서 잘못되었는지 추적해 들어가는 것이 상당한 시간을 잡아 먹게 되어서 더 이상 자잘한 버그들 조차 즉석에서 고칠 수 없었다. 또 프로그래머 스스로 프로그램을 테스트 하는 것이 커다란 인력의 낭비라고 느낀 회사에서는 테스트를 전담하는 사람을 고용했고, 그에 따라 버그의 많은 부분이 다른 사람에 의해서 발견 되었던 것이다. 더군다나 이미 출시된 프로그램이므로 사용자부터의 버그 보고도 생겨났다.
결국 더 이상 발견되는 버그들 모두를 한정된 모니터 가로 폭에 붙일 수 없게 되었으며 또한 더 이상 포스트잇의 접착력이 유지 될 시간 동안에 버그를 고쳐낼 재간도 없었다. 이처럼 산처럼 쌓여만 가는 버그들을 처리 하다 보니 이미 수정한 부분에서 또 문제가 발생하기 일쑤였고 심지어는 보고된 버그를 누락시켜버리는 일도 종종 생겨났다. 이에 지친 나는 조금 더 강력한 버그 관리 방법을 찾기 시작했고 몇몇 영리한 프로그래머들이 이를 위한 편리한 툴을 만들어 냈다는 것을 알아냈다.
버그질라, Mantis 등의 버그 관리 툴에 관심을 가지게 된 것은 바로 이 무렵이었다. 우선 간단한 Mantis라는 버그 관리 툴을 설치해서 사용해보았다. 기본적으로 다수의 사용자가 접속해서 사용하는 환경을 위해 디자인 되어진 제품이었지만 혼자서 사용하기에도 문제가 없었다. 간단한 메모에 의해 전달되었건, 말로 들었건, 혹은 스스로 발견 했건 모든 버그는 나 나름의 상세 설명과 함께 이 서버에 기록되었고 우선 순위가 매겨졌다. 클릭 몇 번으로 관리 할 수 있었으므로 편했다.
덕지덕지 붙은 포스트잇을 때어내고 자동화된 툴로 관리하기 시작한지 몇 달이 지나 사장님이 내가 일하는 책상 옆을 지나가면서 “지금 무엇을 하고 계신 거죠?” 라고 물어보자 나는 신이 나서 설명하기 시작했다. “네, 이런 노력을 하고 있습니다.” 이윽고 며칠이 지나, 이 시스템은 회사 서버에 설치되었고 모든 프로그래머와 테스터들에게는 이 시스템을 사용하라는 지시가 내려졌다. DB를 회사 서버로 옮겨오는 일은 성가셨지만, 이런 식으로 회사 전체가 버그를 관리하게 되면 훨씬 더 큰 기대효과가 있을 것이라고 생각했기 때문에 이 시스템의 관리자 역할도 기쁘게 맡은 것이다.
결과적으로? 회사 전체의 시스템을 거의 나 혼자 사용하게 되었을 뿐 별로 바뀐 것은 없었다. 몇 번의 사용법에 대한 세미나와 규칙의 상세 문서 같은 것도 무의미한 노력으로 남게 되었는데, 필요에 의한 본인의 노력이 아닌 다른 사람의 강요에 의해서 이루어진 것은 그리 오래가지 못한 다는 것만 다시 확인 시켜주었다. 아마, 다른 많은 분들이 이러한 버그관리의 필요성을 느끼지 못하고 있는 상태였기 때문이었나 보다.
지금에 와서도 많은 회사들은 버그를 어떻게 효율적으로 관리 할 수 있는지 애를 먹고 있을 것이라고 생각한다. 물론 아주 체계적으로 막대한 돈을 들여 시스템을 구축하고 버그가 빠져나갈 수 있는 구멍을 원천적으로 봉쇄해서 관리하려는 회사도 있을 것이고, 아주 단순한 시스템으로 프로그래머의 능력에 대부분을 의존하는 회사도 있을 것이고 말이다. 어느 쪽이든 그 회사에 최적화된 시스템이 존재해야 되고 더 나은 시스템이 되기 위해서는 끊임없이 노력해야 한다는 것과 그 노력에 끝이 없다는 생각은 가지고 있다. 그리고 가끔은 익숙해진 자신의 방법을 돌아볼 기회를 가져야 한다는 것도 말이다.