IT 인프라의 중요성이 강조되면서, 대기업이나 공공기관이 주도하는 대형 프로젝트를 심심치 않게 볼 수 있습니다. 엄청난 투자 비용이 들어가며, 인력 투입 역시 어마어마합니다. 또한 전문 업체의 컨설팅을 받기도 하고, 훌륭하다고 회자되는 방법론을 적용하기도 합니다.
 
그런데 이러한 SI프로젝트들 중 성공적으로 완료되었다는 소식을 듣기는 쉽지 않습니다. 물론 표면적으로는 모두 대성공을 거둔 것처럼 포장이 됩니다만, 실제 업무를 담당한 사람에게 슬쩍 물어 볼 경우 한숨만 푹푹 쉬는 경우가 꽤 많습니다.
 
훌륭한 트레이닝을 받은 컨설턴트들의 지도를 받고, 유명한 방법론을 적용하였음에도 왜 이런 결과가 나타날까요? 여러 이유가 있겠지만 제가 생각하기에는 이러한 개발 방법의 전제 조건을 무시하였거나 원칙을 지키지 않는 것이 가장 큰 이유일 겁니다.
 
특히 전제조건이 매우 중요한데, 상당히 많은 경우에 이러한 전제 조건을 명확하게 설명하지 않는 경우가 많습니다. 그냥 이런 방법을 사용하면 무조건 성공해! 라는 식인 경우이죠.
 
예를 들어 최근 인기를 얻고 있는 XP의 짝 프로그래밍을 예로 들어 보죠. 이렇게 일할 때의 장점은 많습니다. 기본적으로 버그를 발견할 확률이 높아지고, 전반적으로 이해하기 쉬운 코드가 작성되며 더 나은 아이디어가 추가될 가능성이 큽니다. 하지만 장점만 있을까요?
 
위의 성과를 얻기 위해서는 기본적인 전제 조건이 충족되어야 합니다. 즉 함께 일할 두 사람은 최소한 비슷한 지식 수준을 가지고 있어야 합니다. 두 사람의 지식 수준에 차이가 크다면 더 잘 알고 있는 사람은 지루해 하거나 답답해 할 것이고, 다른 한 명은 위축되어 자기 생각을 제대로 표현하기도 힘들어 질 겁니다. 1+1이 3이나 4가 되길 원하지만 실제로 1.5 정도가 되어 버리는 것이죠.
 
또한 개발 조직 구성이 미치는 영향도 큽니다. 예를 들어 TDD에서 강조되는 유닛 테스트를 생각해 보죠. 유닛 테스트는 소스의 품질을 지킬 수 있는 매우 유용한 방법이라는 것은 분명합니다. 하지만 원하는 성과를 얻기 위해서는 역시 기본적으로 지켜져야 할 것이 존재하죠.
 
즉, 테스트를 할 수 있을만한 충분한 시간이 제공되어야 하고, 개발자 자신이 유닛 테스트를 수행하는 목적과 이유에 대해 충분히 이해하고 있어야 합니다. 그리고 적극적으로 자신의 코드에 대한 테스트 코드를 작성해야 하는 것이죠.
 
하지만 대부분의 SI 프로젝트가 갑을병정으로 이어지는 하도급으로 수행되는 현실에서, 실제로 일하는 개발자가 이러한 전제 조건이 충족되는 환경에 있기는 어렵습니다. 결국 상부에서 “유닛 테스트를 코드 1000라인당 몇 개 이상씩 작성하시오!!”와 같은 지시가 내려오면, 지표에 맞게 적당히 만들고 지나가는 수준으로 끝나 버리기 쉽습니다. 전혀 의미 없는 시간과 노력의 낭비가 되어 버리는 것이죠.
 
이론적으로 훌륭한 방법은 얼마든지 있을 수 있습니다. 하지만 우리는 현실의 세계에서 살고 있습니다. 수 많은 복잡한 요인이 존재하고, 프로젝트의 설계 과정에서 흔히 간과되는 정치적 영향력의 세계에 살고 있는 것이죠. 이러한 현실에서 절대 선이 될 수 있는 방법이란 존재하지 않습니다.
 
결국 왜 이러한 방법을 쓰는가에 대한 명확한 이해, 현재 상황에 대한 냉정한 분석, 성공에 필요한 전제조건의 확인 과정이 없이 어떠한 방법을 기계적으로 사용하는 것은 반드시 실패할 뿐입니다. 현실에서는 최적의 방법이 있을 뿐, 절대적인 최고의 방법이란 없는 것입니다.