투이컨설팅 임병우 수석

차세대프로젝트는 개발 범위가 크고, 많은 사람이 투입되며, 오랜 기간 동안 진행된다. 프로그램 수로는 5천본에서 2만본에 이르는 규모이다. 개발에 참여하는 회사 수는 수십 개에 이르고, 직접 참여 인원도 수백명에 달한다. 기간은 1년 이상 길게는 3년까지 걸린다. 차세대 프로젝트는 대부분 빅뱅 접근법으로 진행된다. 최초 예정된 날짜에 오픈하는 것은 마치 1km 앞에 있는 표적을 단 한번의 화살로 명중시키는 것과 같은 일이다.

그럼에도 불구하고, 빅뱅 접근은 시간과 비용을 줄일 수 있고, 통합 아키텍처 달성에 유리하기 때문에 우리나라에서는 절대적으로 지지를 받고 있다. 빅뱅 접근은 성공할 수만 있다면 당연히 최선의 방법이긴 하다. 빅뱅 접근이 성공하기 위해서는 몇 가지 전제 조건이 있다.

첫째, 전사적으로 적극적인 지원체계가 뒷받침되어야 한다. IT의 개발 부서와 운영 부서는 한 팀이 되어야 하고, 현업 부서는 신 시스템의 손님이 아니라 주인 역할을 해주어야 한다.

둘째, 업무 요건을 충분히 알 수 있고 시간에 따른 변화가 적어야 한다. 업무 요건이 명확하지 않거나 흔들리면 빅뱅 접근의 대상 범위에서 제외하는 것이 맞다.

셋째, 정교한 프로젝트 관리가 뒷받침되어야 한다. 프로젝트 상황을 투명하게 파악해야 하고, 위험요인을 추적 관리해야 한다. 필요한 의사결정은 신속하게 이루어지도록 해야 한다.

프로젝트 관리는 컨설팅의 종합예술과 같다. 오케스트라 지휘자처럼 많은 악기들의 소리를 어우러지게 만들어서 하나의 멋진 화음으로 만들어가는 통합 역할을 해야 한다. 또한, 특정 사안에 대해서는 심도 있는 분석을 통해 해결점을 찾아내는 역할도 수행해야 한다. 이 글에서는 차세대 프로젝트 단계(분석, 설계, 개발, 테스트/이행)별로 집중적으로 관리해야 할 중점 관리 요인들을 설명하고자 한다.

1. 분석 단계

분석 단계가 시작되면 수행사는 작업계획서(WBS, Work Breakdown Structure, 작업분할구조라고도 함)를 제시하게 된다. WBS에는 타스크 목록, 타스크 정의, 타스크 일정 등이 포함되어 있다. 프로젝트 관리의 시작은 WBS를 검토하여 완성시키는 것이다.

첫째, 필요한 타스크들이 완전하게 식별되어 있으며, 타스크들 사이에 중복은 없는 지 검토한다. 여기에는 MECE(Mutually Exclusive Collectively Exhaustive) 원칙을 적용할 수 있다. 누락된 타스크를 찾아내고 중복된 타스크를 통합해야 한다.

둘째, 각 타스크의 수행 일정(타스크 수행 기간)과 자원 계획(공수 투입 계획)의 적절성을 검토해야 한다.

셋째, 전체적인 관점에서 세부 타스크 간 업무의 연관성과 선후관계가 적절하게 고려되어 있는지를 검토해야 한다.

넷째, 프로젝트 수행 중 지속적으로 발생할 수 있는 WBS 변경을 위한 제도적 장치(상시, 정례적인 절차)가 마련되어 있는지 검토해야 한다.

WBS가 확정되면, 각 타스크에 따라 작성되는 산출물 목록을 검토한다. 산출물 간의 계층 관계가 명확하게 정의되어 있는지 확인하여야 한다. 예를 들어, 아키텍처정의서라는 산출물이 있다면, 데이터아키텍처정의서, 기술아키텍처정의서 등이 상세 산출물로 기술되어 있는지 살펴봐야 한다.

2. 설계 단계

설계 단계의 핵심 작업은 단연 선도개발이라고 말할 수 있다. 설계 본연의 업무도 중요하지만 선도개발의 결과가 전체 품질을 가늠할 수 있는 척도로 작용하는 경우가 많다. 선도개발에서 높은 수준의 품질을 확보하는 것이 상당히 중요하다.

첫째, 수행사가 제시하는 아키텍처와 개발방법론이 기업의 비즈니스 및 기술 환경 특성에 적합하도록 충분히 확인하고 조정해야 한다. 개발 방법론과 아키텍처는 기업의 비즈니스와 IT시스템에 적절하지 않다면 쓸모가 없다.

둘째, 선도개발의 결과를 토대로 개발 범위를 조정하고 솔루션과 인프라 선정 및 활용방안을 확정한다. 또한 개발 환경과 지원 조직 운영 방안도 결정한다.

셋째, 선도개발의 결과를 토대로 공유하고 재사용할 수 있는 모범사례(Best Practice)를 식별하고, 확산 방안을 준비한다.

선도개발의 산출물 품질이 높다면 실제 개발 단계의 산출물 탬플릿으로 활용할 수 있다. 선도개발이 기술적 병목들을 해결하는 정도에 따라 개발단계의 생산성과 품질이 좌우된다. 선도개발의 대상 업무 선정과 기간 및 자원 투입의 최적 방안을 찾는 것이 중요하다.

3. 개발 단계

개발 단계가 되면 다수의 개발자들이 매일 프로그램들을 만들어낸다. 각각의 프로그램들을 수작업으로 일일이 확인한다는 것은 사실상 불가능에 가깝다. 형상관리 및 변경관리 솔루션들을 활용하게 된다.

첫째, 영향도 분석: 어플리케이션 간 연관 호출 관계에 대한 정보 제공, 변경 영향 분석을 통해 개발, 테스트 시 서버 로직 간 혹은 데이터 간 변경에 따른 개발 영향 파악

둘째, 코드 인스펙션: 소스코드 품질저하 문제 분석 및 일정 수준 이상의 시스템 품질 유지

셋째, 커버리지 분석: 업무 요건이 프로그램에 정확히 반영되어 있는지 여부 검토, 기능의 정상 및 예외처리 등 검증

넷째, PMS(Project Management System): 개발자 간 의사소통 채널, 프로젝트 진행 현황 공유, 프로젝트 전반에 대한 모니터링 등

이외에도 다양한 관리 도구가 있다. 각 관리 도구는 기능적 우수성 보다는 해당 기업의 IT시스템환경과 적합성을 우선적으로 고려해서 선정해야 한다.

인프라 관점에서는 기업의 인프라 설치 계획과 수행사의 인프라 도입계획과의 정합성 확보가 가장 중요하다. 즉 수행사가 제안요청서(RFP) 내용을 최대한 반영하여 인프라 도입계획을 수립한다고 하더라도 고객사의 인프라 환경 등 구체적인 내용을 확인할 수 없기 때문에 최적화된 인프라 도입계획을 수립할 수는 없다는 가정으로 출발해야 한다. 개발 단계를 진행하면서 고객사의 인프라 환경과 수행사의 인프라 제공 역량 등을 종합적으로 판단하여 상호 조율하는 과정이 필요하다. 상호 합의된 내용에 따라 인프라 구축이 진행되는지 여부를 상세하게 모니터링 하고, 인프라 설치 계획과 실제 스펙 및 수행사 지원 가능 범위 간 지속적인 Gap 분석을 통한 설치계획 명확화를 주도할 필요성이 있다.

4. 테스트/이행 단계

테스트 단계에는 다양한 테스트가 진행된다.

첫째, 수행 테스트 별로 테스트 범위, 테스트 절차 및 테스트 케이스 확정, 테스트 자원 계획(인력 투입 계획, 데이터 제공 계획 등) 등을 토대로, 테스트의 충분성과 적합성을 확인해야 한다.

둘째, 테스트 목적에 따라 다른 방안을 적용해야 한다. 예를 들어, 비즈니스 로직이 간단하여 단순히 입력값에 대한 결과값만 확인하면 되는 경우에는 블랙박스 테스트를 수행하면 된다. 하지만 이와는 반대로 복잡한 비즈니스 로직이 존재하여 입력 값, 결과 값뿐만 아니라 코드 실행 경로 검증 및 로직 효율성 검증까지 겸해야 하는 경우에는 화이트박스 테스트를 수행해야 한다.

셋째, 테스트 단계 동안에 수행사가 개발한 시스템을 기업이 인수할 수 있도록 준비가 함께 진행되어야 한다. 차세대 프로젝트에 참여하지 않은 직원들은 시스템을 어떻게 활용하는지, 어떻게 운영하는지, 문제가 생겼을 때는 어떻게 대처해야 하는지에 대해서 전혀 학습되지 않은 상태이다. 즉 수행사는 실제 시스템을 사용하는 대상인 현업 담당자들을 위한 사용자 매뉴얼과 시스템 운영 대상인 IT담당자들을 위한 운영자 매뉴얼을 작성해야 한다.

넷째, 오픈 이후 안정화 단계가 종료된 시점이라도 일정 기간 동안은 애프터서비스 차원의 기술지원이 필요한데, 이 기간 동안 예정된 기술지원뿐만 아니라 현업과 시스템 운영자 대상 시스템 교육 실행 여부와 교육 계획 및 교육 커리큘럼 등의 적절성 여부를 검토해야 한다.

차세대프로젝트는 기업에 속해 있는 직원들에게는 대부분 처음으로 겪어보는 일이다. 시작할 때 전체 프로젝트가 어떻게 진행되고, 무엇을 잘 해야 하는지 알기가 어렵다. 무엇을 관리해야 하는가를 잘 알지 못한다면 관리를 잘 할 수 없을 것이다. 차세대프로젝트 관리의 단계별로 해야 하는 작업, 중점 관리 요인, 예상되는 위험 요인, 의사소통 방안 등을 미리 파악하고 준비하는 것이 프로젝트 성공을 보장할 수 있다.

-끝-