합리성의 함정, 방법론의 환상에 빠지지 마세요

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

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

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

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

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

트랙백 (2) | 덧글 (10)
트랙백 주소: http://www.smartplace.kr/trackback_post_81.aspx
스마트플레이스의 트랙백은 스팸방지를 위해 관리자 승인 후 등록됩니다.
루미넌스 - miscellaneous 2007-01-17 02:11:39
파인만이 제시한 궁극의 알고리즘
20세기 중반 미국의 물리학자 리처드 파인만은 21세기에도 절대 통용되는 궁극의 알고리즘을 가지고 있었습니다. Write down the problem. Think very hard. Write down the solution. 정말 대단하지 않습니까?예전에 어느 블로그에선가 한번 보고 기억해두고 있었는데, 최근에 회사에서 제 옆자리에 앉는 "하녕오빠"-_...
사가의 잼있는세상 2007-01-19 12:59:23
전 문서작업이나 하는 직원이 아니랍니다. 프로그래머에요~~~
무식이 힘이다.~~~2년 전엔 이런 생각은 있었지만 막상 일을 해보고 경험해보고 나서 알게된.. 그리고 경험하게된 일들이다.. 사실 이전 회사에선 인원도 적고.. 일만 무지하게 많았던 관계로 어떤 프로그램을 작성할때 그에 맞는 DB설계, 프로그램 구조설계.. 이런거 생각할 시간도 없었고.. 당연히 그냥 짜~~ 그럼 짰다.. 그런회사에서 2년 반을 근무하다,...

cavin 2007-01-17 07:44:58     답글 삭제
예로 드신 내용이 적절치 않은것 같습니다. CMMI는 방법론이 아니라 성숙도 모델이죠. 오히려 CMMI에 빠져있는 것이 '방법론'이기 때문에, 방법론의 허상과 CMMI를 같이 언급하기엔 무리가있지 않을까 싶습니다. (CMMI컨설팅회사들이 느끼는 공통적인 고민이 '방법론의 구멍'을 어떻게 채울 것인가죠. 국내 대다수의 'CMMI적용'은 인증을 받기위한 작은 2-3개 프로젝트 레퍼런스를 만들때 적용을 하니 구비해야 할 문서가 상당하죠. 예로 언급하신 프로젝트가 그러한 종류가 아니였을까 싶네요.
앤디 2007-01-18 10:09:58     삭제
피드백 감사합니다. CMMI는 소프트웨어 개발 원칙 및 관리에 대한 가이드이고, 업체의 역량을 측정하는 모델이라는 말은 맞습니다. 하지만 실질적으로 용어가 다를 뿐 개발 원칙을 정하고 관리 방침을 다룬다는 점에서는 동일합니다. 단지 보는 범위가 개발 문서의 형식이나 실제 개발자가 어떻게 일해야 하는지와 같은 미세한 부분을 다루지 않을 뿐입니다. 즉 전체적인 개발 라이프 사이클 관리를 다루기 때문에, 세세한 부분 은 비어있지만 넓은 의미로 볼 때 CMMI 역시 방법론이라 볼 수 있다고 봅니다. http://www.hyperthot.com/pm_sdm.htm 을 보시면 Waterfall, Spiral 방법론과 같이 CMM을 다루고 있는 것을 볼 수 있습니다.

데니 2007-01-17 09:55:39     답글 삭제
저의 경우 개발방법론을 도입한 입장입니다. 여러가지 긍정적인 효과를 기대하기 위해 접근했지만, 실제 일어나는 다양한 환경에 그대로 적용하기에는 너무나 무리더군요.
결국 윗선이 요구하는 수많은 문서들을 프로젝트에 맞게 과감히 삭제 및 재구성하여 효율성을 증명하고 각 프로젝트별로 방법론을 바꿔나가며 진행하니 점차 자리를 잡아가게 되었습니다.
때로는 방법론을 무시한 방법론이 적절할때도 있더라구요. ^^
결국 방법론에 얽매이지 않고 이를 어떻게 풀어나가느냐가 중요하지 않을까요? ^^
p.s 3800개의 문서. 압권이네요. T.T
앤디 2007-01-18 10:12:28     삭제
보기 드문 성공 사례로군요. ^^ 사실 어떠한 방법론을 적용할 때, 조직에 맞는 테일러링이 제일 중요한데 이 부분이 제대로 이루어지는 경우가 드물죠. 실무자들은 너무 복잡하고 힘들다고 불만을 토로하지만, 관리하는 입장에서는 막상 빼버리면 합리적인 요소들을 제거하는 것 같은 불안감에 빠지기 때문이죠. 잘 적용하고 계신다니 정말 다행입니다.

FineApple 2007-01-17 10:23:10     답글 삭제
좋은 말씀이네요. 요즘 일이 진척되지 않아 조급해하는 제게 큰 도움이 됐습니다. 감사합니다.
앤디 2007-01-18 10:19:40     삭제
제 글이 조금이나마 도움이 되었다니 다행입니다. 마음이 급할수록 조금 더 진정하고, 차분히 판단하셔서 좋은 결과가 있으시길 진심으로 바랍니다. 피드백 감사합니다.

winever 2007-01-17 11:36:09     답글 삭제
방법론을 신봉할 필요는 없다고 봅니다. 방법론을 잘 따른다는 것은, 결과적으로 다른길로 빠짐으로 인해 발생가능한 리스크를 줄이자는 것이지, 무조건 다 따랐을때 우수한 품질의 성과물이 나옴을 보장하지는 못한다고 생각합니다. 즉, 어떤 개발/프로젝트를 진행할 때에는 유연성을 가미한 방법론의 적용이 답일 수 있다고 보지요. 사람이 기계가 아닌지라, 프로젝트에는 그마만큼의 다양한 변수가 발생하는 것인데, 그 모든 것이 책에 절차와 문서로 기술되어 있지는 않은 거니깐...

진행하시는 분의 유연성과 합리성, 그리고 노하에 기반하여 방법론을 적절히 이용하는 것이 최선이 아닐까 싶네요...
앤디 2007-01-18 10:23:51     삭제
옳은 말씀이십니다. 개인적으로 조직의 차이, 개발 플랫폼의 차이, 문화의 차이를 반영하지 못한 무조건적인 적용은 반드시 실패로 끝난다고 믿고 있습니다. 말씀하신 것처럼 적절한 수준의 합리성과 조직에 맞게 적용하기 위한 유연성이 핵심 포인트라고 봅니다. 피드백 감사합니다.

holdingu 2007-02-25 12:44:44     답글 삭제
석사때까지 c++의 클래스와 코드들이 머리속을 떠다녔는데,
입사 이후로 문서작업만 하고 있는 저를 발견했었죠.
위탁관리를 위한 요구사항서 작성부터 평가서까지...
개발자도 관리자도 아닌 애매한 위치에서 한동안 고민이 많았었습니다. 하지만 덕분에 이직을 할 때 어렵지않게 인수인계가 이루어지더군요.

자히르 2007-04-21 11:19:37     답글 삭제
요즘 프로젝트를 하면서 위 문제에 직면해 있었습니다.
합리성에 대한 강박 관념과 그 뒤에 깔린 불안함... 100%현재 저의 상태를 요약하는군요. 내가 가고 있는 방향이 맞는지에 대한 의심에 방법론에 집착을 하게 되는 셈이지요. 위에 글 정말 많은 도움이 되었습니다. ^^

이름 비밀번호
홈페이지
덧글
비밀글
RSS 피드
전체글한RSS 추가 구글추가
스마트가젯북스타일
Demo Day