두더지 잡기 같은 개발을 피하자

프로젝트 매니저가 알아야 할 97가지 - 두 번째 이야기

by - Venkat Subramaniam
Agile Developer사의 창업자로 미국, 캐나다, 유럽, 아시아 각국 수천 명의 소프트웨어 개발자를 교육, 지도하고 있다. 애자일 등 각종 소프트웨어 기술로 프로젝트를 성공으로 이끈다. 다양한 국제적 소프트웨어 콘퍼런스의 발표자로서 초대되고 있다. ". NETGotchas"의 저자이자 2007년 Jolt Productivity Award를 수상한 "Practices of an Agile Developer"의 공저자이기도 하다.

프로젝트 매니저는 납품을 위해 다양한 압박에 직면하게 됩니다. 특히나 시간이 아주 중요한 요소가 됩니다. 어떻게 하면 신속히 프로젝트를 완료할 수 있을까요?

팀에 바니와 롭이라는 두 명의 프로그래머가 있다고 가정합시다. 둘 다 유능하고 같은 수준의 지식을 갖고 있으며 다룰 수 있는 언어도 같습니다. 개발을 진행해보니 롭보다 바니가 빠르게 기능을 완성해낸다는 것을 알게 되었습니다. 바니는 코드를 빠르게 마무리하는 것에 전념했고, 한편 롭은 코드의 리팩터링에 시간을 들이고 있었습니다. 롭은 변수와 함수에 적절하게 이름을 붙이고 코드가 문제없이 돌아가는데도 코드를 더 작은 단위로 나눴습니다. 그리고 코드의 각 부분이 의도한 대로 움직이는지 확인하기 위해 테스트 코드도 작성하고 있었습니다. 어느 정도 본인이 만족한 수준이 되어야만 롭은 코딩이 완료되었다고 보고를 해옵니다.

이러한 세세한 것에 대해서 당신은 아무것도 몰랐다고 합시다. 기능이 완료되었다고 보고하는 속도만으로 분명히 바니가 뛰어나다고 생각하지 않았을까요?

몇 주 후, 고객에게 새로운 기능을 데모하게 되었습니다. 언제나처럼 고객은 완성된 기능을 마음에 들어했지만 몇 가지 변경과 개선을 의뢰받았습니다. 그래서 당신은 개발자에게 코드를 변경하도록 의뢰했습니다.

이윽고 새롭게 개선한 기능을 고객에게 가져갔습니다. 고객은 롭이 만든 기능을 시험하고 그 변경을 만족해했습니다. 하지만 안타깝게도 고객은 바니가 만든 기능에서 이상한 부분을 발견했습니다. 새로운 기능은 잘 돌아갔지만 이전에는 잘 돌아가던 곳에 문제가 생긴 걸 몇 개 발견했습니다. 당연히 고객은 이것을 결함으로 생각했고 당신은 바니에게 수정을 의뢰합니다. 그리고 고객은 다시 한번 그 기능을 테스트했습니다. 이번에는 또 다른 곳에서 이상한 일이 일어났습니다. 아무래도 뭔가가 크게 망가진 것 같습니다. 도대체 무슨 일이 일어나고 있는 걸까요?

당신에게도 아이가 있다면 두더지 잡기가 무슨 말인지 알 것입니다. 바니는 두더지 잡기 같은 코딩을 하고 있었습니다.
두더지 잡기는 게임의 일종입니다. 아이들은 나무망치를 손에 들고 무작위로 얼굴을 내미는 두더지를 때립니다. 두더지가 다음에 어디서 얼굴을 내밀지 모르기 때문에 아이들은 기뻐합니다. 그러나 여기저기 무작위 하게 망가진 코드가 얼굴을 내미는 애플리케이션을 고치는 건 조금도 즐거운 일이 아닙니다. 그건 당신을 짜증 나게 만들고, 앞으로 어떻게 될지 예측할 수도 없어서 더욱 지치게 만듭니다. 무엇보다 제품 개발을 지연시킵니다. 바니는 처음엔 앞서갔지만 잘못된 방향으로 달리고 있었던 것입니다.

롭은 언뜻 보기엔 느려 보였지만 실제로는 질 높은 코드를 작성하고 있었습니다. 그의 개발 페이스는 일정했고 처음부터 코드의 품질이 높았기 때문에 동작 가능한 상태로 빠르게 변경할 수 있었습니다. 게다가 지속해서 써둔 테스트 덕분에 새로운 코드가 다른 부분과 호환성을 유지하고 있는지 바로 피드백을 얻을 수 있었습니다.

기능 완성에 걸린 시간을 측정할 때는 처음 그 기능을 완성하는 데 걸린 시간을 이용해선 안 됩니다. 코드의 강화, 수정, 개선에 걸린 시간도 더해야 합니다. 품질 높은 코드와 테스트는 작성하는데에 많은 시간이 듭니다. 단기적으로는 손실로 보이지만, 장기적으로는 큰 이익을 가져옵니다.

속도 중시로 결과를 얻을지 지속 가능한 진척을 얻을지 상황에 맞춰서 판단합시다.