거의 아무런 정보도 없이 이제 시작하는 프로젝트에 대해 일정을 내놓으라는 이야기를 너무 많이 들어왔고, 그 때마다 신뢰 구간 -50% ~ + 300% 의 일정이 그렇게 중요하냐고 묻으며 항의해보았다. 돌아오는 답변은, ‘그래도 일정은 필요하지 않느냐?’ 정도.. -_-a 결국 ‘일정을 위한 일정’ 만들기를 하게 된다.
어쩔 수 없이 일정을 내어주며, ‘이것은 신뢰성 10% 에요’ 라고 강조해보지만 절대 귀담아 듣지 않는다. 그 일정을 기준으로 종속된 모듈/기능 등을 고려한 전체 일정이 산출되고 임원들에게까지 보고된다. 그리고 기획과 마케팅 부서 역시 이를 기준으로 상품화 일정과 마케팅 일정을 등을 잡아 놓는다.
조금만 지나면 ‘신뢰성 10%’ 일정은 부메랑이 되어 개발자들을 옭아매기 시작한다. 진행중 (예외 없이) 예상치 못했던 문제들이 붉어져 나와도 ‘이미 윗선에 보고가 되어 있고 다른 부서들이 그에 맞춰 움직이고 있기 때문에 어쩔 수 없다. 무슨 수를 써서라도 이 때 끝내야 한다’는 식이다.
중간 관리자 몇 명만 설득해서 될 일은 아니다. 그들 대부분도 스스로를 피해자라 생각하고 있다. (틀린 말은 아니지만, 그들 중 윗사람들의 인식을 바꿔보려고 노력하는 사람은 단 한 명도 만나보지 못했다. 아쉽다.) 그래서 적어도 임원들까지는 제대로된 소프트웨어 개발 모델을 이해시킬 필요가 있다.
하지만 권위도 없고 직급도 낮은 사람들이 아무리 떠들어봐야 먹힐리 만무하다 (당장 바로 윗사람도 귀담아 듣지 않는데 -_-a). 책 좀 보라고 던져 주는 것도 아닌 듯 싶고.. 이런저런 생각을 해보다 우선 참조하기 좋은 블로그에 괜찮은 글을 하나 발췌해 놓기로 했다.
이 글은 스크럼 : 팀의 생산성을 극대화시키는 애자일 방법론 [1] (원서: Agile Software Development with Scrum [2]) 에서 발췌한 내용이다. 2장 ‘스크럼 준비 – 스크럼은 다르다’ 중 프로세스 제어 모델에 대한 블록으로, 저자가 왜 전통적인 프로세스들이 계속 실패하는지에 대한 통찰을 얻게된 계기를 이야기한 부분이다.
나는 1990년대 초반에 MATE라고 불리는 프로세스 관리 제품을 개발하고 라이선스하던 소프트웨어 업체를 운영했다. 우리의 최대 고객은 쿠퍼스 & 라이브랜드와 IBM 이었는데, 그들은 우리가 그들의 방법론을 사용해서 MATE를 개발하기를 원했다. 몇 차례 시도하긴 했으나 그 결과는 전적으로 불만족스러웠다. 당시, 우리 회사의 요구사항은 끊임없이 변하고 있었고 우리는 계속 신기술들을 도입하로 있었는데, 그 방법론은 우리를 도와주기는커녕 오히려 장애물을 만들고 유연성을 떨어뜨리는 등 마치 우리의 발목을 잡는 것과 같았다.
나는 왜 우리 고객들의 방법론이 우리 회사에는 효과가 없는지를 알고 싶었다. 그래서 1995년, 듀폰 연구소의 공정 제어 이론 전문가에게 시스템 개발 방법론에 대한 자문을 구했다. 바바툰데 ‘툰데’ 오거나이케(Babatunde ‘Tunde’ Ogannaike) 박사가 이끄는 전문가들은 산업 공정 제어 분야(industrial process control)에서 가장 존경 받는 이론가들이었다. 그들은 공정 제어에 대해 속속들이 알고 있었다. 심지어 연구자들의 일부는 유명 대학들에서 해당 주제에 대한 강연을 하기도 했다. 그들 모두가 시장 예측에서부터 제품 주문과 배달에 이르기까지 듀폰의 제품 생산 전 공정을 자동화하는데 관여하고 있었다.
듀폰의 연구자들에게 우리의 시스템 개발 프로세들을 살펴보도록 한 것은 듀폰의 연구자들에게 엄청난 우스갯거리를 선사한 거나 마찬가지였다. 그들은 우리 시스템 개발 산업이 전적으로 부적절한 공정 제어 모델에 따라 개발을 하고 있다는 사실에 깜짝 놀랐고 매우 의아해 했다. 듀폰의 연구자들은 시스템 개발이 너무 복잡하고 예측하기 힘들기 때문에, ‘경험주의적’이라고 부르는 다른 공정 제어 모델을 사용해야 한다고 말했다. 그들은 내가 왜 올바르지 못한 길로 가고 있는지를 이해시키기 위해서, “프로세스 역학, 모델링과 제어(Process Dynamics, Modeling and Control)” 라는 산업 공정 제어 이론의 필독서를 권했다.
간단히 말하자면 공정 제어에는 두 가지 주요 접근법이 있다. 하나는 ‘명시적인(defined)’ 공정 제어 모델로서 작업자들이 작업의 모든 부분을 완전히 이해해야 하는 것이다. 사전에 잘 정의된 일련의 입력들이 주어지면 매번 동일한 결과물이 산출된다. 명시적인 프로세는 완료 시점마다 매번 동일한 결과물을 내놓는 경우에 적용 가능하다. 툰데 박사는 내가 그에게 보여준 방법론들이 앞서 설명한 명시적인 프로세스를 사용하려고 했지만, 어느 프로세스나 태스크도 반복 가능하며 예측 가능할 정도로 충분히 명시되어 있지 않다고 말했다. 또한 그는 우리 산업이 명시적인 접근법을 쓰기에는 너무 많은 사고와 창조성을 요구하는 지식 집약적인 사업이라고 했다 툰데 박사는 우리 산업이 명시적인 방법론을 사용할 경우, 통제력 상실과 불완전한(혹은 잘못된) 제품 생산을 초래할 것이라는 사실을 이론적으로 증명해 보였다. 그럼에도 우리 분야의 여러 태스크들이 마치 시작과 종료가 예측 가능하기라도 한 듯이 명시적인 공법 프로세스처럼 서로 종속적으로 연결되어 있다는 점을 놀라워했다.
한편, 툰데 박사는 불확실성을 기반으로 하는 경험주의적인 공정 제어 모델에 대해서도 설명해 주었다. 경험주의 모델은 불완전하게 정의되어 예상 못한 결과를 만들어내는 프로세스를 빈번하게 검사하고 적응하는 방식을 통해 프로젝트를 제어하는 방법을 제공한다. 그는 내게 이 모델을 연구해서 시스템 개발 프로세스에 적용해볼 것을 권유했다.
듀폰 연구소 방문 기간 동안 나는 이 문제에 대한 진정한 통찰을 얻었다. 갑자기 내 안의 무엇인가가 번뜩이더니, 왜 우리 산업의 모든 사람이 시스템을 구축하는 데 그런 문제를 겪는지를 알게 되었다. 즉, 왜 우리 산업이 그런 곤경에 처했고, 형편없는 명성을 갖게 되었는지를 깨달은 것이다. 우리에게 필요한 것은 빈번하고 직접적인 테스트와 그에 뒤이은 즉각적인 수정임에도 불구하고 우리는 마치 조립 라인에서 일하는 것처럼 업무를 처리하는데 시간을 낭비하고 있었던 것이다.
경험주의적 공정 제어 모델은 애자일 측에서 목에 핏대가 서도록 강조하는 것들이다. 빈번한 검사와 즉각적인 적응 과정. 이를 위해 항시 동작 가능한 제품을 만들고 고객과 직접 ‘이것이 원하는 것이 맞는가?’를 확인하고 조정하는 것이다.
전통적인 프로세스에서도 이를 간과하고 있지는 않다. 다만 그 중요성을 제대로 인지하지 못하고 충분히 강조하지 못하고 있었다고 말할 수 있겠다. 그리고 안타깝게도 내가 만나본 SE 전공자들 대부분은 스스로도 깨닫지 못하고 있어 잘못된 사상과 프로세스를 전파하고 강요하고 있었다.
References
- 스크럼: 팀의 생산성을 극대화시키는 애자일 방법론 (켄 슈와버, 바이클 비들 | 박일, 김기웅 | 인사이트)
- Agile Software Development with Scrum (Ken Schwaber, Mike Beedle | Pearson Education, Inc)
