로디 서비스 기획 실무 트레이닝 내용을 기반으로 정리한 내용입니다.

구축 프로세스 

운영과 전략은 조직의 성격이나 리더의 방향성에 따라 각기 다른 방식으로 전개될 수 있습니다. 그러나 ‘구축’ 영역만큼은 비교적 일반화된 방법론을 따르는 경우가 많습니다. 특히 소프트웨어 개발이나 SI(System Integration) 프로젝트에서는 일정한 단계 구조를 기반으로 프로젝트가 진행됩니다. 일반적으로는 착수, 설계, 구현, 검수라는 네 단계로 나누어 진행하게 되며, 이는 오래전부터 사용되어 온 전통적인 개발 방법론에 해당합니다.

이러한 방식은 흔히 ‘워터폴(Waterfall)’ 방법론이라고 불립니다. 물이 위에서 아래로 흘러내리듯, 앞 단계가 마무리되어야 다음 단계로 넘어갈 수 있는 구조이기 때문에 이런 이름이 붙었습니다. 즉, 착수가 끝나야 설계가 시작되고, 설계가 완료되어야 구현이 가능하며, 구현이 완료된 이후에야 검수 단계로 진입할 수 있습니다. 이 구조의 특징은 관리가 명확하다는 장점이 있지만, 동시에 앞 단계가 지연될 경우 뒤 단계까지 연쇄적으로 일정이 밀릴 수밖에 없다는 한계도 함께 지니고 있습니다. 이러한 한계를 보완하기 위해 애자일(Agile) 방식이 등장하기도 했지만, 여전히 대규모 구축 프로젝트나 SI 사업에서는 워터폴 방식이 가장 범용적으로 사용되고 있는 것이 현실입니다.

 

착수의 출발점: 계약

구축 프로젝트의 시작은 ‘착수’이며, 그 착수의 근거는 보통 계약이나 지시입니다. 에이전시나 외주 수행사의 경우에는 계약이 체결되는 시점이 곧 프로젝트의 공식적인 출발점이 됩니다. 그 이전 단계에서 자주 등장하는 문서가 바로 RFP(Request for Proposal, 제안요청서)입니다.

RFP는 고객사가 수행사에게 “우리는 이런 프로젝트를 하려고 하니 제안을 보내 달라”고 요청하는 문서입니다. 이 문서에는 프로젝트의 목적, 요구사항, 기대 효과, 범위 등이 담겨 있습니다. 예를 들어, 상품 전시 영역에서 구매 결정을 유도하기 위한 UI 개선 요청, 리스트 페이지와 상세 페이지 개편, 검색 기능 변경, 주문 및 배송 프로세스 개선, 신규 서비스 추가 등 다양한 요구사항이 포함될 수 있습니다.

수행사는 이 RFP를 기반으로 제안서를 작성하여 제출하고, 고객사는 이를 검토하여 수행 기업을 선정합니다. 흔히 이를 Bidding(입찰) 과정이라고 합니다. 선정이 완료되고 계약이 체결되면, 그 시점부터 프로젝트는 공식적으로 착수 단계에 들어가게 됩니다. 따라서 RFP는 단순한 참고 문서가 아니라, 향후 계약과 수행 범위의 근거가 되는 매우 중요한 문서라고 볼 수 있습니다. 기획자로 프로젝트에 참여하셨다면 반드시 확인하셔야 할 문서 중 하나가 바로 이 RFP입니다.

인하우스 조직의 경우에는 계약 대신 ‘지시’가 착수의 근거가 됩니다. 예를 들어 본부장이나 팀장이 “이 프로젝트 시작하십시오”라고 공식적으로 지시하는 순간, 그 지시가 프로젝트의 시작을 의미합니다.

 

수행 계획서의 중요성

프로젝트가 공식적으로 시작되면 PM(Project Manager)이 선정됩니다. PM은 프로젝트 전체를 총괄하며 주도권을 가지고 관리하는 역할을 수행합니다. 그리고 착수 단계에서 PM이 가장 먼저 작성하는 문서가 바로 ‘수행 계획서’입니다. 수행 계획서는 단순한 계획 문서가 아니라, 프로젝트의 범위와 방향을 확정하는 기준 문서라고 보셔도 무방합니다. 이 문서를 작성할 때 PM이 가장 중요하게 고려하는 요소는 크게 두 가지입니다.

첫 번째는 프로젝트의 범위를 명확히 하는 일입니다. 프로젝트 범위는 가장 빈번하게 분쟁이 발생하는 영역이기 때문에, 요구를 제시한 쪽과 수행하는 쪽이 모두 합의할 수 있도록 명확히 정의해야 합니다. 예를 들어, 프론트엔드만 변경하는 것인지, 백오피스까지 포함하는 것인지, 기획과 디자인까지 수행하는 것인지, 아니면 퍼블리싱과 개발만 진행하는 것인지 등을 구체적으로 정해야 합니다. 앱까지 포함되는지 여부 역시 사전에 명확히 해야 합니다.

이러한 범위 정의가 불명확할 경우, 프로젝트 진행 중 “이 부분도 당연히 포함된 것 아니냐”는 오해가 발생하기 쉽습니다. 예를 들어 프론트엔드를 변경하면서 내부 인트라넷 시스템도 함께 수정해야 한다면, 그 작업을 수행 범위에 포함시킬 것인지 사전에 합의하지 않으면 나중에 비용과 책임을 두고 갈등이 생길 수 있습니다.

또한 유료 솔루션 도입 여부도 수행 계획서에 포함되어야 합니다. 무료 솔루션이 존재하더라도, 성능이나 확장성 측면에서 유료 솔루션이 더 적합할 수 있습니다. 특히 통합 검색 기능처럼 비용이 크게 발생하는 항목은 사전에 구매 여부를 결정하고 계획서에 명시해야 합니다. 그렇지 않으면 구현 단계에서 예산 문제로 프로젝트가 지연될 수 있습니다.

크로스 브라우징 범위, 다양한 디바이스 해상도 대응 여부 역시 사전에 협의해야 할 중요한 사항입니다. 이러한 기술적 범위가 명확하지 않으면 구현 단계에서 추가 이슈가 발생하게 됩니다.

두 번째로 중요한 요소는 산출물과 관리 체계를 명확히 정의하는 일입니다. 프로젝트 진행 과정에서 어떤 단계에서 어떤 산출물이 나오는지, 그리고 그 산출물이 어떤 형태로 제공되는지를 미리 합의하는 것이 바람직합니다. 예를 들어 요구사항정의서, 정보구조도, 화면설계서, 작업관리서, 이슈보고서, 검수계획서, 운영매뉴얼, 종료보고서 등 각 단계별 산출물을 사전에 정해 두는 것입니다.

뿐만 아니라 프로젝트 조직 구성, 소통 체계, 보고 라인, 주요 마일스톤, 일정 관리 방식(WBS 기반 상세 일정 포함)도 수행 계획서에 포함되어야 합니다. 위기 상황이 발생했을 때 어떻게 대응할 것인지, 누구와 어떤 방식으로 커뮤니케이션할 것인지까지 명확히 정의되어야 프로젝트가 안정적으로 운영될 수 있습니다.

결국 수행 계획서는 프로젝트의 범위와 책임, 일정과 소통 구조를 모두 명확히 하는 기준 문서이며, PM은 이 문서를 중심으로 프로젝트를 관리하게 됩니다.

 

단계별 흐름과 워터폴의 의미

착수 단계가 마무리되면 설계 단계로 넘어가게 됩니다. 설계 단계에서는 정보구조도와 화면설계서가 주요 산출물로 도출됩니다. 이후 구현 단계에서는 작업관리서와 이슈보고서를 중심으로 실제 개발이 진행됩니다. 마지막으로 검수 단계에서는 검수계획서를 기준으로 테스트가 이루어지고, 운영매뉴얼과 종료보고서를 통해 프로젝트를 마무리하게 됩니다.

이 모든 단계는 앞 단계가 완료되어야 다음 단계로 넘어갈 수 있다는 점에서 워터폴의 특성을 그대로 보여 줍니다. 따라서 착수 단계에서의 명확한 합의와 수행 계획서 작성이 매우 중요합니다. 초기에 모호하게 시작된 프로젝트는 중후반부에 더 큰 문제로 확대되기 때문입니다.

 

표준화된 방법론으로 주로 진행되는 구축 프로세스

정리하자면, 구축 프로젝트는 비교적 표준화된 방법론을 따르며, 그 출발점은 계약 또는 지시에 기반한 착수입니다. 착수 단계에서 PM이 작성하는 수행 계획서는 프로젝트의 범위, 산출물, 일정, 조직, 소통 체계를 명확히 규정하는 핵심 문서입니다. 이 문서가 탄탄할수록 이후 설계, 구현, 검수 단계가 안정적으로 이어질 수 있습니다.