한 일꾼이 망치의 주인이 될 수는 있으나, 여전히 망치는 그를 능가하는 수준에 있다. 도구
는 자신이 사용되는 방법을 정확히 알고 있는 반면, 그 도구 이용자는 대략적인 이해만 지니고 있을 뿐이다. – 밀란 쿤데라, 웃음과 망각의 책


한국 사람들에 대한 외국인들의 평가를 물어보면 유난히 많이 나오는 말 중의 하나가 ‘빨리빨리’ 이다. 원래 느릿느릿하고 체통을 중시하는 선비문화의 전통이 급격한 산업화 과정에서 스피드를 강조하는 의식으로 변모하여 외국인들이 가장 빨리 배우는 한국말이 되어 버렸다. 남들이 몇 백 년 걸려서 진행한 일을 우리는 불과 몇 십 년 만에 해야만 했었던 강박증이 만들어낸 결과이다. 현대와 같이 속도를 제일의 미덕으로 치는 상황에서는 상당한 경쟁력의 요소가 되기도 하지만 다른 요소가 동반되지 못하고 오직 속도만을 따지는 것은 부실의 요소가 될 여지가 다분하다. 우리는 그 동안 속도로 인한 부작용과 아픔을 건설업계의 부실 공사에서 너무도 많이 보았다.

소프트웨어 개발 분야에는 소프트웨어 생명주기(Software Life Cycle)란 용어가 있다. 소프트웨어를 하나의 생명처럼 탄생, 성장, 소멸하는 것처럼 간주하는 것이다. 소프트웨어 개발의 직선적인 진행을 강조하는 전통적인 생명주기인 폭포수 모델(Waterfall Model), 위험을 최소화 하기 위해 반복을 강조하는 나선형 모델(Spiral Model) 등 여러 가지의 생명주기 모델 들이 계획 수립, 분석, 설계, 구축, 테스트, 구현, 유지보수로 이어지는 개발 과정을 체계적으로 제시하고 있다. 그래서 실제 소프트웨어 개발의 시작단계에서 프로젝트의 특성에 맞는 생명주기와 개발 방법론을 결정한다. 그러나 실제 많은 IT 현장에서는 다른 모든 부분이 생략되고 소프트웨어 개발 작업이 구축(프로그래밍)이 먼저 진행되는 ‘일단 짜보고 고치기’(code and fix development)라는 수공업적인 방식으로 진행된다.

‘일단 짜보고 고치기’는 프로젝트에서 해야 할 일을 정의하고 계획을 수립하는 절차를 무시하고 진행한다. 고객의 요구사항을 정확히 파악하려는 노력을 게을리하고 이를 순차적으로 시스템에 조율하는 과정을 생략한다. 즉 이러한 개발 방식은 계획 수립과 분석, 설계의 상류 과정을 등한시하고 오로지 코딩(프로그래밍)만을 강조하는, 빨리 일정을 끝내려는 변형된 무리한 속성과정이다.

더욱이 이 방식은 일정이 촉박해지면 미친 듯이 코딩하기로 변신한다. 일에 대한 아무런 생각이 없는 무식한 방법으로 돌변한다. 이럴 때 나는 가끔 내가 자동차 생산 공장에서 부품을 조립하는 단순 노동자라는 기분을 떨쳐 버릴 수 없었다. 연일 계속되는 야근 철야의 흔적이 책상에 가득하다. 담배꽁초가 재떨이에 수북이 너 불어져 있고, 지난 밤 덜 익은 컵라면에 느글느글한 뱃속을 부여 잡고 위 통증을 호소하며 화장실을 들락거리는 내 모습이 한심하고 처량하였다.

왜 이렇게 무식하게 개발하는가? 납기가 촉박하기 때문이다. 짧은 개발 일정은 마음을 조급하게 만든다. 정상적인 절차에 의한 개발은 왠지 멀리 돌아가는 느낌이 든다. 상황이 이러할진대 일단 눈에 보이는 결과에 집착하지 않을 수 없다. 개발자는 빨리 코딩을 들어가길 원하고, 관리자들은 일단 빨리 짠 프로그램을 보고 진척이 진행되고 있는 것을 확인해야 안심이 되기 때문이다. 여기에 요구사항과 품질이 끼여들 여지는 별로 많지 않다. 나아가 무조건 일을 해야 하는데 시간을 써야 한다는 획일적인 사고 방식에 사로잡히면서 자기계발, 건강, 운동, 유머, 독서, 가정생활 등에 신경을 쓸 수 없는 것이 당연시 되고 또 어떤 관리자들은 강요하기까지 한다. ‘진정한 프로그래머는 잠을 자지 않는다’는 해병대 정신을 강조하며 ‘돌격 앞으로!’를 외친다.

‘일단 짜보고 고치기’를 택하는 또 하나의 이유는 이 방법이 제일 쉬운 개발 방법이기 때문이다. 요구사항 개발, Use Case(사용자 요구사항을 도출하는 기법), 프로토타입, 데이터 모델링, 프로세스 모델링 등 온갖 기법들에 대해 알 필요가 없기 때문이다. 오로지 개발 언어와 도구만 잘 알고 있으면 되기 때문이다.

이러한 작업의 결과는 어떨까? 대략 짐작이 갈 것이다. 아무리 해당 업무에 대해 확실히 안다 하더라도 재작업(Rework)이 필수적으로 발생할 수 밖에 없다. 진행된 과정을 거슬러 올라갈 수 밖에 없다. 결국 납기를 단축시키려 하다가 더 늘어나는 결과가 나타난다. 프로젝트는 폭주하며 Death March 프로젝트로 전락한다. 프로젝트를 성공하는 것이 목적이 아니라 살아 남는 것이 목적이 된다.

이 방식은 프로젝트 진행상황에 대한 평가, 품질 평가, 위험 평가 방법이 없다. 그저 완성될 때까지 구현한다. 그러나 실제 이런 개발 패턴이 결함을 제거하고, 품질을 관리하는 것을 무시하는 것은 아니다. 다만 프로젝트 후반에 그것을 시작한다. 그래서 코딩에 몰리면 테스트는 버퍼 기간으로 간주되어 무시되거나 단축된다. 당연히 품질이 좋아질 리가 없다.

이 방식은 한번 만들어 보고 버릴 목적에만 유용하다. 고객의 요구사항을 확실히 파악하기 위해서 프로토타입을 하거나 잠깐 쓰기 위한 데모 프로그램 작성에 활용될 수 있을 뿐이다. 프로젝트는 데모가 아니라 라이브다.

프로젝트를 성공으로 이끌기 위해서는 ‘일단 짜보고 고치기’ 방법을 지양하고 먼저 소프트웨어 개발 전반의 프로세스를 혁신해야 한다. 즉 요구사항에서부터 모델링, 개발, 테스트, 배포 및 관리 등 종료시점까지 소프트웨어 생명주기를 체계적으로 관리하여 소프트웨어 개발 진행사항을 실시간으로 통제할 수 있어야 한다.

결국 문제는 이 방식이 생산성을 높일 수 있느냐의 문제로 귀결된다. 생산성을 높여야 납기를 단축시킬 수 있다. 생산성은 품질과 불가분의 관계가 있다. 품질은 생산성과 일견 반비례 관계인 것 같지만 실제로는 정비례한다. 생산성은 단위 시간당 얼마나 많은 노동력을 투입하느냐가 아니라 얼마나 양질의 산출물을 만들어 낼 수 있느냐의 관점으로 보아야 한다. 따라서 분석, 설계 등의 상류 활동에 집중하고 프로젝트 전반부에 동료검토 등 결함 제거 활동이 있어야 품질이 높아진다.

프로젝트는 마라톤과 비슷하다. 출발이 빠르다고 결승선에 빨리 도착하는 것은 아니다. 프로젝트 성공은 프로젝트 초기에 얼마나 빨리 코딩 하는가에 달려있지 않다. 진행 중인 프로젝트의 궁극적 목적은 프로젝트 수행에 있는 것이 아니라 어떤 결과물을 산출하느냐에 있다는 것을 잊어서는 안 된다.

일단 짜보고 고치기 방식은 ‘급하니까 일단 짜보면 잘 되겠지’ 라는 운명에 맡기는 방식이다. 무식하게 일만 하는 패턴이다. 절대 Just do it이 아니다. 그 동안 우리는 주어진 일을 해치우는 데에 너무 많은 시간을 할애했고, 정말 핵심적인 질문인 “이 일이 대체 할 필요가 있긴 한 것인가”라는 것에 대해서는 시간을 내지 못했다. 주위를 둘러보라. 정작 일 잘하는 사람은 일 자체에 대해 생각하는 사람이라는 것을…