열정에 찬 젊은 개발자가 있었습니다. 업계에서 일하기 시작하면서 무수히 많은 야근을 경험했고, 자투리 시간을 쪼개 열심히 공부하면서 실력을 키웠죠.
 
그런데 어느 순간 깨닫게 됩니다. 자신의 회사가 너무나 일을 주먹구구식으로 한다는 것을요. 계획을 짤 때도 대충 감으로 잡고, 설계 문서도 빈약하고, 회사를 떠나 버린 전임자의 소스는 암호처럼 난해합니다. 아.. 속이 탑니다.
 
그래서 언젠가 책에서 얼핏 본 개발 방법론을 떠올립니다. 자세히 알아 보니 너무나 매력적입니다. 모든 작업은 트래킹 되고, 현재 개발 진척도는 한 눈에 들어오며, 개발 문서는 완벽하게 정리될 것 같습니다. 너무 멋진 이야기입니다..
 
세월이 흐르고 이 개발자는 드디어 그러한 방법론을 적용하는 회사에 들어가게 됩니다. 그런데 뭔가가 이상합니다. ‘왜 나는 개발은 안 하고 문서만 만들고 있는 거지?’ 하는 의문이 머리를 떠나지 않습니다. 그리고 어느 순간 이 개발자는 모든 일에 회의적인 염세주의자가 되어 버립니다.
 
방법론 = 만병통치약?

이와 같은 경험을 해 보신 적이 있으신가요? 마지막 부분이 조금 과장되었다고 느끼는 분도 있겠지만, 실제로 이러한 일을 겪는 사람들이 많습니다.
 
최근 몇 년간 여러 가지 방법론이 인기를 얻고 있습니다. 저마다 개발 과정에 대한 통찰력을 제공하며, 생산성이 높아지고, 품질을 향상시킬 수 있다고 이야기 합니다.
 
치밀하게 짜인 프로세스는 오류가 발생할 틈을 원천 봉쇄하고, 철저하게 계획된 문서화는 개발 산출물이 완벽하게 관리될 것을 보장할 것 같습니다. 게다가 몇 단계에 걸친 검증과 승인 과정을 거치기 때문에 어설픈 실수 따위는 존재할 수도 없을 것 같습니다.
 
그리고 이러한 방법론을 몇 년간 적용하면, 개발자들의 몸에 내재화 되어 자연스럽게 전체 팀의 수준이 올라간다고 하니 이 보다 좋은 일은 없을 것 같습니다.
 
이러한 이야기는 관리자나 경영자들에게는 너무나 달콤한 것이기에, 자신의 개발 조직에 멋진 방법론을 적용하고픈 유혹은 너무도 강렬하고 그 결과 별다른 고려 없이 덜컥 적용해 버리는 경우가 흔합니다.
 
하지만 현실은 그렇지 간단하지 않습니다. 우리는 이상적인 세계에 살고 있지 않거든요. 프로세스와 문서로 상징되는 방법론들은 현실 세계에서 전혀 다른 모습을 보입니다.
 
합리성, 그것도 적당할 때나 좋은 것

제 경우 몇 년 전에 수행했던 프로젝트에서 이에 관한 엄청난 경험을 한 적이 있습니다. 6개월 정도의 개발 기간을 가지고 진행한 프로젝트에서 3800여 개의 문서가 쏟아져 나오는 것을 본 것이죠. 개발 인원이 어마어마하게 많지도 않았고, 테스트와 설계 기간을 제외하면 6-7명이 2개월간 구현한 크지 않은 프로젝트였는데 말이죠. 참고로 CMMI (Capability Maturity Model Integration) 라는 방법론이 적용되었던 프로젝트였습니다.
 
어이 없는 짓이라고요? 네. 저도 동의합니다. 문서 작업만 전담하는 사람이 있을 정도였으니까요. 하지만 이렇게 되는 데에는 다 이유가 있습니다.
 
그 이유는 합리성에 대한 강박 관념과 그 뒤에 깔린 불안함으로 요약됩니다. 이 두 가지 요소가 복합적으로 네거티브한 시너지 효과를 내면 위에서 언급한 저런 결과가 나오는 것이죠.
 
합리성이 문제라니, 이상하죠? 예를 들자면 이런 겁니다. “어떤 결정을 내릴 때에는 그럴 만한 근거가 있어야 한다”, “혼자 내린 결정은 중요한 요소를 빠뜨릴 수 있으니, 동료들과 논의하여 결정하여야 한다”, “각 팀은 전문화 되어야 하며, 상호 검증하여 오류를 낮춰야 한다” 와 같은 이야기 들입니다.
 
틀린 이야기는 하나도 없는 것 같습니다. 그런데 이게 과하면 이렇게 됩니다. 개발 중에 결정하는 다양한 선택에서 왜 그런 선택을 하게 되었는지에 대한 비교 문서를 작성해서 근거를 마련해야 됩니다. 게다가 이를 결정하기 위한 회의가 반드시 있어야 하고, 이러한 회의의 회의록은 포맷에 맞게 작성되어 각 책임자의 의견 및 결정이 모두 기록으로 남아야 하죠. 한 주에 몇 가지 결정만 해도 만들어야 하는 문서는 금새 수십 개에 도달합니다.
 
게다가 모든 문서는 프로세스를 관리하는 팀의 검증을 받게 됩니다. 하지만 프로세스 관리 팀은 우리가 실제로 개발하고 있는 내용보다는 방법론을 정확히 준수하는지에 더 관심이 많습니다.
 
문서가 빠진 것은 없는지, 이 문서에 기록 된 것과 저 문서에 기록된 것이 다르지는 않은 지와 같은 방법론의 규칙 준수 여부만 열심히 검사합니다. 그도 그럴 것이 이 분들이 처리해야 할 프로젝트가 한두 개가 아니거든요. 보아야 할 문서는 수백 개가 넘죠. 그 많은 복잡한 속사정을 어떻게 다 이해할 수 있겠습니까?
 
근심은 만병의 원인, 소프트웨어도 예외는 아니다

게다가 소프트웨어를 모르는 높은 분들은 항상 불안감에 시달립니다. 소프트웨어 개발이라는 것이 근본적으로 지식 집약적인 일이다 보니, 어느 정도 구체적인 모습을 보려면 꽤 시간이 걸리거든요.
 
사실 그런 분들은 개발자들이 모니터를 보고 있으면 이게 일을 하고 있는 건지, 웹 서핑을 하고 있는 건지, 몽상에 빠져 있는 건지 판단도 잘 안 되거든요.
 
그래서 이전의 실패 경험을 가지고 있는 높은 분들은 끊임 없이 무언가를 요구하게 됩니다. 혹시나 잘못 되어 가고 있는 것은 아닌지, 잘 되어 가고 있는 것처럼 보여도 속은 엉망이 아닐지 하는 불안함을 느끼면서 말이죠.
 
결국 다양한 형태의 보고서가 작성되기 시작합니다. 막연한 불안감을 달래기 위한 문서들이죠. 수 많은 차트, 프리젠테이션, 다이어그램 등이 동원되고, 이러한 문서들을 만들기 위해 개발자들은 시간을 빼앗기고 지쳐 가게 됩니다.
 
결국 모든 일은 사람이 하는 것

오해는 하지 마세요. 지금 저는 모든 방법론은 무용지물이다라고 주장하는 것이 아닙니다. 정말 사소한 실수나 오류가 사람의 생명과 직결된다면, 개발 외적인 작업이 아무리 많아도 불평할 수 없습니다.
 
항공기 시뮬레이션 프로그램이나 의학용 프로그램들이 대표적인 예라 할 수 있겠군요. 작은 실수로 비행기가 추락해 버린다면 안 되겠죠.
 
하지만 대부분의 다른 프로젝트들은 그렇게 심각한 상황이 아닙니다. 이런 경우에는 정말 적절한 수준을 결정 하는 것이 매우 중요합니다. 프로젝트를 난잡한 수준에서 탈출시키되 개발자들이 문서의 홍수에서 허우적거리지 않도록 말이죠.
 
그러니 여러분이 개발자라면, 이러한 상황에서 현명해져야 합니다. 윗 분들을 설득해서 불필요한 작업 부하를 최대한 덜어내거나, 아니면 요구되는 수준을 맞출 정도까지만 최소한의 노력을 들이는 센스가 필요합니다.
 
혹시 여러분이 관리자라면? 한 가지만 명심하세요. 여러분의 똑똑한 부하들을 지금까지의 히스토리에 기반해서 판단해 보고, 믿을만하다면 철저하게 그들을 믿고 후원해 주세요. 문서로 휘두르는 것보다는 더 많은 결과를 얻어 낼 수 있을 겁니다.
 
결국 소프트웨어의 개발은 사람이 하는 것이지, 프로세스나 문서가 대신해 주는 일은 아니니까요.