소프트웨어를 개발하는 사람들, 혹은 엔지니어들은 복잡함에 매료되는 경향이 있습니다. 성급한 일반화의 오류일 수 있지만요. ‘과거의 저’나 ‘저와 함께 일했던 일부 분들’은 상당히 복잡한 것을 잘 이해하고 제어할 수 있다는 것을 자랑스러워하거나 좋아했습니다.
‘고약한 문제 합당한 해결’에서도 폭포수 방법의 문제점을 지적하면서 이런 점을 언급합니다.
둘째, (폭포수 방법에서) 프로세스로의 입력은 출력보다 덜 복잡한 경향이 있다. 입력은 출력보다 더 짧고, 대개 출력보다 더 쉽게 이해할 수 있는 용어로 표현되는 경우가 흔하다.
셋째, 이상하게도 출력의 어떤 항목은 입력보다 덜 복잡하게 보이기도 하는데 전체를 놓고 보면 출력이 입력보다 복잡하다. 프로세스를 더 단순한 요소로 분해해보면, 우리는 이상하리만치 전체적으로 일을 더 복잡하게 만들고 있는 셈이다.
복잡성과 비슷한 맥락의 것이 있습니다. 프로젝트를 하다 보면, 팀원들은 상당히 많은 일을 하려고 합니다. 물론 고객이 찾아와서 이것 바꿔 달라 저것 추가해 달라고 하면 질색을 하던 분들도, 스스로 일을 더 찾아서 하려는 경향이 있습니다. 특히 프로젝트 초반에는 이런 경향이 심하죠. 하지만 스스로 일을 벌리다 보면, 프로젝트 끝무렵에 가서 벌린 일을 수습하려고, ‘품질’과 ‘일의 양’을 등가교환하는 경우가 생기죠.
이런 문제를 미연에 방지하려면, “어떻게 하면 더 많은 걸 만들어 낼까?”하는 긍정적인 상상에서 “어떻게 하면 일을 더 적게 할 수 있을까”하는 보수적인 실행을 해야 한다고 생각합니다. 크지 않지만, 이건 발상의 전환이라고 볼 수 있죠. 이런 마인드로 접근하는 게, 고객의 정당한 요구를 거절하는 걸 뜻하지 않습니다. 단 고객의 정당한 요구라도, 적은 노력을 들여서 할 수 있는 방법이 없는지 혹은 그런 요구가 정말로 프로젝트 성공에 필요한 것인지, 항상 반문하는 자세가 필요합니다.
지금 참여하는 프로젝트 팀원들은 PM포함해서 모두 산전수전을 겪은 고참들이죠. 그래서 이런 마인드가 창궐합니다. 그렇다고 해서 프로젝트 품질이 떨어지지 않죠. 반대로 고객의 희망적인 기대에 현실을 인식하게 하고, 결국 훌륭한 품질의 결과를 인도할 것으로 생각합니다. 여러분도 프로젝트에서 ‘더 많이’가 아닌 ‘더 적게’의 사고로 접근해 보시길 바랍니다. 조금 난해한 문제가 쉽게 풀리지도 모르죠. ‘더 적게’의 사고를 재미나게 소개한 일화로 글을 마무리합니다.
학교를 졸업하고 나서 이번이 두 번째 프로젝트입니다. 첫 번째 프로젝트에서 관리자는 코딩에 필요한 시간이 어느 정도인지 듣고 나서 이렇게 말했습니다. “이번이 처음 맡은 프로젝트니까, 개발이 끝날 무렵에 자네가 짠 소스를 코드와 통합하는 데 시간을 더 주는 게 어떨까?” 저는 관리자가 바보 같은 소리를 하다고 생각했지만, 시간을 조금 더 준다는 건 괜찮았습니다. 저는 열심히 일했고, 데드라인을 지켰지만 전체 시스템이 실제로 어떻게 작동하는지 피드백을 얻으면서 코드를 변경해야 했습니다. 저는 관리자가 준 여분의 시간을 모두 써버렸고 시간이 조금 더 필요했죠. 하지만 제가 정말로 당황한 것은 이 일 때문입니다. 저는 문제를 해결하려고 코드를 작성하지 않았습니다. 단지 코드를 간단히 만들려고 코드를 제거했죠. 그랬더니 제가 작성한 코드가 모두 사라져 버렸습니다.
두 번째 프로젝트에서 지속적인 통합을 사용했고, 진행하면서 리팩터링을 했습니다. 진행하면서 설계를 바꾸지 않았지만 간단하게 만드는 작업과 정리 작업을 수행한 덕분에 제가 무슨 일을 했고 얼마나 빨리 개발하는지 알게 됐습니다. 하지만 제가 작성한 코드는 여전히 사라져 버렸습니다.