개발자들이 ‘개발 거의 다 끝났다’라고 하는 말은 이제 테스트 해 볼 만한 모듈이 만들어 졌다는 뜻으로 받아들여야 한다.

개발자도 사람인지라 ‘인지편향’의 경향을 지닐 수 밖에 없다. 자신이 만든 기능만을 테스트하고 테스트 케이스도 앞으로 들어올 데이터를 모두 대변할 만한 그런 샘플링 데이터가 아니라, 지극히 편향된 데이터로만 테스트를 하게 된다. 따라서 이전 기능이 모두 잘 돌아가는지 테스트를 반드시 거쳐야 하며 코드리뷰와 새로운 테스트 케이스 작성도 게을리 하면 안된다. 게다가 문서화까지 생각한다면 ‘테스트 해 볼만한 모듈’이 만들어 졌다 함은 일 전체의 20% 남짓 정도만 된 상황일 뿐이다.

80% 정도의 일이 남은 상태로 제품을 출시한다면 100에 99는 반드시 긴급 버그 패치가 나가게 되고 그 후 버그 패치도 빈번해 질 것이 뻔하다. 왜냐면 버그 패치시마다 그 부분만 생각해서 버그 고칠텐데.. 남은 80%를 버그 패치의 연속으로 매꾸게 될 것이다.

비슷하게 “1시간 만 더 있으면 개발 완료입니다” 이 말은 일주일이 더 필요하다는 말과 다를게 없다.

ps. 그냥 요즘 몇몇 큰 회사에서 버그로 인해 제품 보급에 차질이 생기거나 긴급 버그 패치를 남발하고 있다는 소문을 듣고 뻔한 스토리일꺼라고 생각하니 좀 마음이 복잡해서 써봤다.  개발자는 일정탓에 그랬다고 하겠고, 기획자나 팀장은 개발자 탓을 하겠지… 그것보다는 정말 제대로 테스트 일정이나 코드리뷰 일정이 개발프로세스에 빠지지 않고 들어갔는지 그리고 테스트 플랫폼이 구축이 되어 있는지 먼저 확인해야 되지 않을까 한다.

테스트와 코드리뷰가 충분히 포함된 개발 프로세스를 따라 개발해본 경험에 빗대 이야기 하자면, 개발 후 서비스 론치하고 난 다음에 내가 만든 모듈이 서버 프로그램임에도 불구하고 그 모듈로 인한 시스템 다운이 한번도 없었다. 따라서 긴급 패치도 없었으며 홀가분하게 다음 프로젝트에 전념할 수 있었던 경험이 있다. 이는 내가 개발 실력이 뛰어나다는 것을 말하는 것이 아니라, 테스트 프로세스 정립이 안정성 있는 소프트웨어 개발의 핵심이라는 것을 이야기하고 있을 뿐이다.

‘개발 거의 다 했다’는 말은… by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.