Critical Path와 통합

CPM (Critical Path Method)은 1950년대에 당시 듀퐁에 근무한 Morgan R. Walker와 Remington Rand사에 근무한 James E. Kelley, Jr.에 의해서 고안된 프로젝트 모델링 기법이며, 전체 일정 중에서 가장 중요한 경로를 집중적으로 관리하려는 목적이 강합니다.

PERT (Program/Project Evaluation and Review Technique) 역시 CPM과 같이 프로젝트 수행하는 경로들을 관리하는데, 그 경로에 작업을 수행하는데 필요한 요소들을 식별하여 그 경로에 가중치를 두어서 실질적인 작업 경로를 관리하는 방법입니다.

이 두가지 방법은 프로젝트를 관리하는 방법에 있어서 가장 기본이고, 기초가 되는 이론이며 현실에서도 적용 가능한 방법들입니다. 이러한 방법들은 프로젝트를 수행하는데 있어서 선후행 작업간에 의존관계가 존재하고, 그러한 의존관계를 맺는 작업들 중에서 가장 오래 걸리고, 반드시 거쳐야 하는 작업을 집중적으로 관리하겠다는 목표를 가지고 있습니다.

SW 프로젝트에서는 구현해야 하는 기능의 목록들이 식별될 것이고, 이들 간의 선후행 관계도 식별될 것입니다. 그러한 기능들 중에는 반드시 구현해야 하는 우선순위가 높은 기능들이 있으며, 이들을 구현하기 위해서 먼저 준비되거나 완료가 되어야 하는 작업들이 있습니다. 예를 들어, 해당 우선순위가 높은 기능이 외부시스템과 연계가 필요하다면, 연계가 필요한 메커니즘이나 인터페이스 협의가 필요할 것이며 이러한 작업들 역시 우선순위가 높아질 수 밖에 없습니다. 또한, 기본적으로 고객 기능이 다 만들어져야 다른 기능들이 이를 사용해서 구현할 수 있는 것들도 있기 때문에 고객에 대한 기능은 당연히 가장 먼저 그리고 최우선적으로 작업해야 하는 것들입니다.

이러한 작업의 결과는 시스템적으로 궁극적으로 컴포넌트와 이들의 의존관계 형성으로 나타나게 됩니다. 아무리 인터페이스 협의를 잘했다고 하더라도 실제 구현체에서 인터페이스를 할 때 누락 혹은 추가된 데이터에 대한 행위를 어떻게 할지를 사전에 정해놓지 않는 한 통합시 문제가 발생될 수 밖에 없습니다. 고객에서는 나이라는 정보를 필수로 입력받게끔 처리했는데, 이를 사용하는 측에서는 나이 정보를 보내주지 않게 된다면, 고객에서 제공하는 인터페이스를 사용할 수 없습니다.

Integration by certified su

이와 같이 SW에서는 컴포넌트/시스템 통합이 가장 중요한 실질적인 작업이 됩니다. 즉, Critical Path로 잡혀야 하는 것들이죠. 하지만, 대다수 프로젝트에서는 이러한 통합이 프로젝트 가장 끝 부분에 위치합니다. 즉, 각 기능 개발을 알아서 각자 수행하고, 제일 말미에 컴포넌트/시스템 통합을 수행하다보니, 프로젝트 초반에 세밀하지 못하게 협의된 인터페이스 정의만을 가지고는 통합하기가 수월하지 않습니다. 또한, 전체 프로젝트의 인원과 비용 관리상 초반에 기능이 간단한 것들은 빨리 끝내고, 추후에 테스트/통합 시점에만 잠시 이를 담당하는 사람만을 계획상에서 잡기 때문에 통합이라는 작업은 초중반에 일어날 가능성 역시 점점 없어집니다. 고객 기능은 초반 2 ~ 3 개월 만에 만들고 이를 담당했던 인력들은 모두 사라지거나 다른 영역으로 옮겨지고, 그 중간에 고객과의 인터페이스가 필요한 업무에서는 고객이 일방적으로 정해놓은 인터페이스만을 사용하다보니, 시스템 자체가 더 복잡해질 우려도 있습니다.

결국 컴포넌트/시스템 통합은 보통 생각하는 것처럼 그리 쉽고 단순한 작업은 아니며, 항상 많은 문제가 발생되는 작업입니다. 또한, 이러한 문제를 해결하는 시간은 상당히 걸리는 작업이구요. 통합이 발생되는 시점은 통상 반복(iteration)의 마지막 시점에 작업이 이루어집니다. 통합과 통합의 간격의 차이가 SW가 변경된 기능입니다. SW의 변경의 차이가 클수록 통합을 어렵게 만듭니다.

통합에 대한 위험을 줄이는 방법은 결국 이러한 SW 변경의 차이를 줄여야 하며, 궁극적으로는 자주 빨리 통합을 해야 합니다. 자주라는 의미는 통합을 하나의 작업 단계로써 전체 프로젝트 일정 중에서 최대한 많이 나타나야 한다는 것입니다. 이와 같은 잦은 통합을 위해서는 사람이 수행하는 것보다는 자동화시켜서 통합으로 인한 노력이나 부담을 줄여야 합니다. 통합이 Critical Path에 포함되지 않았다면, Critical Path에 넣고 그에 맞게 전체 일정을 조정해야 할 겁니다.

하지만, 통합은 어느 정도 절차를 가지고 있습니다. 통합을 수행하는 사람의 작업을 가만히 들여다보면, 기계적인 작업들이 대부분이라는 것을 아실 수 있을겁니다. 즉, 통합은 자동화될 수 있는 영역입니다. 컴포넌트/시스템 통합은 Critical Path이기 때문에 이를 자동화시키고, 프로젝트 초기부터 자주 수행한다면, SW 개발에 대한 위험이 상당히 줄일 수 있습니다. 하지만, 통합 절차에 대한 자동화는 어느 정도 이를 수행하기 위한 전제 조건을 내포하고 있으며, 개발을 하는 사람들은 이를 위해 반드시 지켜야하는 작업들이 있습니다.

우선, 통합의 제일 첫번째 단계는 빌드 단계입니다. 빌드는 소스 코드를 가지고 와서 실행 코드를 만드는 작업으로 만일 소스 코드가 변경된다면 기존의 실행되던 코드는 깨짐(break) 현상이 발생되어서 빌드가 되지 않을 수 있습니다. 대부분 소스 코드는 형상 레파지토리에서 관리되며 개발 작업을 수행한 사람들이 자신의 PC에서 작업한 내용을 레파지토리에 옮겨 놓기(커밋하기) 때문에 결국 소스를 수정한 사람은 변경된 소스 코드가 현재의 빌드된 상태에 추가하더라도 동작에 아무런 이상이 없음을 증명해야 합니다. 여기에서 자동화에 대한 첫번째 장벽이 생깁니다. 즉, 개발 작업을 한 사람은 자신이 변경한 코드가 이상이 없음을 증명해야 하기 때문에 전체 소스를 가지고 와서 로컬 빌드를 하고, 변경된 기능에 대해서 테스트를 수행하고 이상이 없다는 것을 눈으로 확인하는 과정을 거쳐야 합니다. 이는 통합을 위한 자동화에 있어서 대전제이지만, 기술적으로는 강제하지는 않습니다. 하지만, 이는 소스 코드에 대한 변경만을 개발자의 작업이다라고 생각하는 기존 개발 방식의 전환을 필요로 합니다. 개발 작업은 소스 코드에 대한 변경 뿐만 아니라, 그 변경으로 인해서 영향 받는 것들까지 책임을 져야 하며, 궁극적으로 전체 시스템이 제대로 동작한다는 것까지도 같이 책임을 져야 합니다. 이는 사실 통합 자동화에 있어서 제일 먼저 공유되고 공감을 얻어야 하는 작업에도 불구하고, 수많은 이유와 이슈로 인해서 그냥 권고 형태로 은근슬쩍 넘어가는 단계이기도 합니다.

이 단계가 개발에 대한 부담이라는 이유 중 하나는 자신의 코드가 변경되었지만, 이상이 없음을 검증하는 방법을 모른다는 것이고, 거기다고 이를 검증하려면 개발할 시간도 부족한데 검증(테스트)까지 해야 하냐고 화까지 냅니다. 무책임한 발언임에도 불구하고 서슴없이 이러한 이야기를 한다는 것이 참으로 안타까울 뿐입니다. 그동안의 현장에서 개발이라는 작업을 어떻게 수행했었고, 어떠한 관행으로 프로젝트가 수행되었는지를 전적으로 보여주는 현상입니다. 이는 단순히 책에 나오는 이론적인 이야기가 아니며, 현실적으로 지금도 프로젝트에서 우리가 부딪히는 일입니다. 이러한 상황이 되면, 정말 통합에 대한 과정은 요원해집니다. 개발자는 자신의 코드를 어떻게 해서든 검증을 수행해야 하며, 이에 대한 이상없음으로 어떠한 방식으로든 가시적으로 보여주어야 합니다. 말로 하는 것이 아니라, 명확하게 다른 사람의 PC에서든 개발서버에서든 상관없이 그러한 것을 보여주어야 합니다. 이러한 기준을 정하지 않으면, 다시 통합은 자동화가 되기 이전 상태와 별반 달라진 것은 없을 겁니다.

결국은 통합의 자동화는 개발 문화(프로세스)의 변경을 가지고 오게 되며, 이에 대한 구성원들의 합의가 있어야 합니다. 이러한 장벽을 넘게 되면, 그 다음은 순전히 기술적인 관점들입니다. 물론, 이후 절차에서 문제가 발생되지 않으리라는 보장은 하지 못하지만, 상당 부분은 환경의 다름으로 인해서 발생되는 문제들이고 이러한 문제들은 설정이나 기타 방법으로 해결될 수 있습니다. 통합을 하는 과정에서 다양한 품질 검토 작업을 넣어볼 수도 있습니다. 소스 코드에 대한 inspection과 다양한 테스트들이 그러한 것들이며, 이러한 것들은 SW의 품질을 더 높여주는 것들입니다.

이와 같은 방식으로 Critical Path 상의 통합은 자동화되어서 작업이 수행되기 때문에 개발 작업은 소스 코드 변경과 이를 동작하게 만드는 노력이 남게 됩니다. 결과적으로 Critical Path는 자동화되기 이전보다도 훨씬 작업이 수월해질 수도 있으며, 전체 작업 공정 기간이 더 효율적으로 구성될 수도 있습니다. 통합을 Critical Path에 위치시키고, 이를 최대한 자동화시킬 수 있는 노력을 하십시오.