프로젝트 계획

헌장 다음에 오는 것

4장에서 책마루 프로젝트 헌장이 승인됐다. "8주, 500만원, 주문·결제·배달 추적까지" — 이 정도의 큰 틀은 정해졌지만, 헌장만으로는 아직 아무도 코드를 짤 수 없다. 누가 언제까지 무엇을 만들지, 얼마의 비용이 어디에 들어갈지는 여전히 빈칸이다. 이 빈칸을 채우는 작업이 이번 장에서 다룰 계획 단계다.

계획 이전 단계 — 제안요청서와 제안서

책마루처럼 사장님이 직접 개발사를 골라 계약하는 경우에도, 원리상으로는 계획 이전에 한 단계가 더 있다. 발주자(사장님)가 원하는 제품의 사양·예산·일정을 정리한 **제안요청서(RFP)**를 만들고, 이를 본 개발사 후보들이 자신들의 개발 계획을 담은 제안서를 제출하는 절차다. 대형 프로젝트에서는 여러 업체가 제안서로 경쟁하고 발주자가 그중 하나를 고르는 정식 입찰 과정을 거치지만, 책마루처럼 소규모 프로젝트에서는 이 과정이 사장님과 개발사 사이의 미팅 몇 번으로 간소화된다. 형식은 가벼워져도 "무엇을 원하는지 먼저 문서로 정리하고, 그걸 근거로 계약한다"는 원리 자체는 똑같이 적용된다.

계획 단계란 무엇인가

프로젝트 헌장이 공식 승인되면, 프로젝트 관리자는 이를 근거로 범위·일정·원가·품질 등 세부 계획을 하나씩 채워나간다. 이 세부 계획들을 모아 정리한 문서가 **프로젝트 관리 계획서(PMP)**다. 계획 문서는 프로젝트가 완료 지점에 어떻게 도달할지 알려주는 지도이자, 진행 상황을 판단하는 기준선(baseline) 역할을 한다 — 계획이 없으면 지금 프로젝트가 잘 되고 있는지조차 판단할 근거가 없다.

계획을 세울 때는 언제나 세 가지 제약 조건 — 시간, 비용, 품질(또는 범위) — 안에서 움직여야 한다. 책마루라면 "8주 안에, 500만원으로, 3초 이내 로딩이 되는 시스템"이 그 제약이다. 셋 중 하나를 무리하게 당기면 나머지가 흔들린다 — 기간을 4주로 줄이려면 예산을 늘리거나 기능 범위를 줄여야 하는 식이다. 계획 단계의 본질은 이 세 축의 균형점을 찾아 문서로 못 박는 일이다.

범위 관리 — 할 일과 하지 않을 일의 경계

범위 관리는 프로젝트가 해야 할 일과 하지 않을 일의 경계를 정하는 작업이다. 헌장에서 "회원 등급 할인은 이번 범위 제외"라고 정해뒀다면, 그 경계를 더 구체적인 작업 목록으로 풀어내는 게 범위 관리의 역할이다.

이 경계를 나눌 때는 제품 범위와 프로젝트 범위를 구분해두면 유용하다. 제품 범위는 완성된 시스템이 갖는 기능 자체(주문, 결제, 배달 추적)를 말하고, 프로젝트 범위는 그 기능을 만들어내기까지 필요한 모든 작업(요구사항 분석, 설계, 테스트, 배포, 문서화까지)을 뜻한다. 사장님은 보통 제품 범위(눈에 보이는 기능)만 떠올리지만, 개발팀이 실제로 관리해야 하는 건 프로젝트 범위 전체다.

작업 분류 체계(WBS)로 책마루 프로젝트 쪼개기

범위를 구체적인 작업 단위로 쪼갠 구조가 **작업 분류 체계(WBS, Work Breakdown Structure)**다. 인도물(산출물) 중심으로 계층을 나눠, 일정과 비용을 산정할 수 있는 크기까지 잘게 쪼갠다. 책마루 프로젝트의 WBS 일부를 표로 옮기면 이런 모습이다.

이 최하위 항목들을 **작업패키지(work package)**라고 부른다. WBS에 없는 일은 프로젝트 범위 밖이라는 뜻이므로, 나중에 "이것도 해주세요"라는 요청이 들어왔을 때 이 표가 원래 범위였는지 아닌지를 가르는 기준이 된다. 작업패키지를 나눌 때는 보통 1~2주 안에 끝낼 수 있는 크기로 자른다 — 3.2 결제 연동을 통째로 두면 진행 상황을 가늠하기 어렵지만, "PG사 API 연동", "결제 실패 처리" 정도로 더 쪼개면 매주 진행률을 확인할 수 있다.

일정 관리 — 활동을 순서대로 배열하기

WBS로 작업패키지가 정해지면, 이 작업들을 언제 할지 배열하는 일정 관리로 넘어간다. 이 과정은 대략 다섯 단계를 거친다.

1. 활동 정의: 작업패키지를 실제 수행 가능한 활동 단위로 나눈다.
2. 활동의 순서 배열: "결제 연동은 화면 설계가 끝나야 시작할 수 있다"처럼 활동 간 선후 관계를 정리한다.
3. 활동의 자원 산정: 각 활동에 필요한 인력·도구를 가늠한다.
4. 활동의 기간 산정: 배정된 자원을 고려해 활동별 소요 기간을 추정한다.
5. 일정 개발: 앞의 결과를 모아 실제 일정표를 만든다.

책마루 8주 일정을 단순화하면 이런 흐름이 나온다.

여기서 눈여겨볼 대목은 5주차 결제 연동이다. PG사 가입 심사는 개발팀이 통제할 수 없는 외부 일정이라, 4장에서 짚은 리스크(결제대행사 심사 지연)가 실제로 일정에 반영된 모습이다. 활동의 순서를 배열할 때는 이렇게 우리가 통제할 수 없는 의존관계를 최대한 앞쪽에 배치해 여유를 확보하는 게 요령이다.

원가 관리 — 무엇을 근거로 비용을 추정할까

원가 관리는 프로젝트 라이프사이클 각 단계에 얼마의 비용이 들지 추산하는 작업이다. 추정 방법은 크게 두 갈래로 나뉜다.

• 상향식 추정: 작업패키지 하나하나에 드는 비용을 계산해서 위로 합산하는 방식. 정확도는 높지만 각 작업패키지에 대한 상세한 자료가 필요해 시간이 오래 걸린다.
• 하향식 추정: 과거 경험과 전문가 판단에 기대어 전체 규모를 먼저 어림잡는 방식. 소프트웨어 프로젝트는 과거 데이터가 상대적으로 부족한 경우가 많아 이 방식이 자주 쓰인다.

하향식 추정을 뒷받침하는 대표적인 척도가 두 가지 있다. 하나는 소스 코드 줄 수를 세는 **LOC(Line of Code)**로, 계산은 간단하지만 코딩에 들어가기 전 단계(분석·설계처럼 코드로 안 잡히는 작업)의 비용은 반영하기 어렵다. 다른 하나는 사용자 관점에서 요구되는 기능 개수를 세는 **기능 점수(function point)**로, 요구사항이 정리되는 시점이면 비교적 이른 단계에서도 신뢰할 만한 추정치를 낼 수 있다. 책마루처럼 예산 500만원 안에서 이 정도 기능이면 얼마가 들지를 미리 가늠해야 하는 소규모 프로젝트에서는, 기능 점수 방식으로 주문·결제·배달 추적 각 기능 단위의 규모를 어림잡고, 여기에 개발사가 보유한 과거 프로젝트 단가를 곱하는 식의 하향식 추정이 현실적이다.

원가 산정은 한 번으로 끝나지 않는다: 계약 전 타당성 검토 단계에서는 개략적으로, 계획 단계에서는 좀 더 구체적으로, 그리고 프로젝트가 진행되는 동안에도 계속 갱신된다. 책마루 결제 연동이 예상보다 늦어지면 그 시점에 원가 산정도 다시 손봐야 한다.

원가 산정 결과는 보통 항목별 표로 정리해 사장님에게 공유한다. 책마루 프로젝트라면 대략 아래와 같은 배분표가 나올 수 있다.

이 표에서 예비비를 별도로 잡아두는 것도 요령이다. 8주짜리 프로젝트라도 PG사 심사 지연 같은 외부 변수는 언제든 생길 수 있으므로, 예산 전체를 기능 개발에만 쏟아붓기보다 일부를 돌발 상황에 대비한 여유로 남겨두는 편이 실제 프로젝트에서는 더 안전하다.

품질 관리 계획 — 기준을 미리 정해둔다

품질은 "요구사항에 대한 적합도"다. 책마루 요구사항 명세서에 적힌 "주문 목록 페이지는 3초 이내에 로딩된다"는 문장은 그 자체로 품질 기준이다. 품질 관리 계획의 역할은 이런 기준을 프로젝트 초반에 명확히 정의해두고, 그 기준에 맞는지 확인할 방법과 절차까지 미리 정해두는 것이다. 기준이 계획 단계에서 정해지지 않으면, 테스트 단계에 가서야 이게 통과 기준을 만족한 건지 아닌지를 놓고 다투게 된다.

형상 관리 계획 — 변경을 통제하는 절차

소프트웨어의 형상(모습)은 결국 각 단계에서 만들어지는 문서와 코드로 나타난다. 이 산출물들을 관리하는 것이 **형상 관리(SCM, Software Configuration Management)**다. 책마루 프로젝트에서 배달 가능 지역 기준이 개발 중간에 "도보 30분"에서 "반경 2km"로 바뀌었다고 하자. 이 변경이 요구사항 명세서, 설계 문서, 코드에 모두 반영돼야 하고, 언제 누가 왜 바꿨는지 기록이 남아야 한다. 형상 관리 계획은 이런 변경을 누가 승인하고, 어떤 문서까지 함께 갱신할지를 미리 정해두는 절차다 — 계획이 없으면 명세서는 옛 기준 그대로인데 코드만 새 기준으로 바뀌는 불일치가 생기기 쉽다.

확인 및 검증(V&V) 계획 — 제대로 이해했는가, 제대로 만들었는가

계획 단계에서 마지막으로 짚어둘 것은 **확인(validation)**과 **검증(verification)**의 구분이다. 확인은 사장님이 원하는 걸 우리가 제대로 이해했는가를 점검하는 활동이고, 검증은 이해한 대로 소프트웨어가 정확히 동작하는가를 점검하는 활동이다. 책마루의 배달지역 판단 기능으로 예를 들면, 확인은 사장님이 말한 배달 가능 범위를 요구사항 명세서가 정확히 담았는가를 확인하는 일이고, 검증은 그 명세서대로 코드가 실제로 판단을 내리는가를 테스트하는 일이다.

두 활동을 연결하는 개념이 **추적성(traceability)**이다. 요구사항 명세서의 한 줄이 설계 문서의 어느 부분에 반영됐고, 그게 다시 코드의 어느 함수로 구현됐고, 어떤 테스트 케이스로 검증됐는지를 계속 연결해서 따라갈 수 있어야 한다. 이 연결이 끊기면, 나중에 요구사항 하나가 빠졌다는 사실을 인수 테스트 직전에야 발견하는 사고가 생긴다.

책마루처럼 규모가 작은 프로젝트에서는 이 추적을 거창한 도구 없이 표 하나로도 충분히 관리할 수 있다. 요구사항 번호, 관련 설계 문서 절, 구현 파일, 테스트 케이스 번호를 한 줄에 나란히 적어두기만 해도, "이 요구사항이 정말 반영됐는가"를 나중에 다시 확인할 때 훨씬 빠르게 답을 찾을 수 있다. 계획 단계에서 이런 최소한의 추적 장치를 마련해두는 것과, 아무 장치 없이 진행하다가 인수 테스트에서 처음으로 빠진 요구사항을 발견하는 것 사이의 차이는, 프로젝트 막바지의 여유 시간을 결정짓는다.

핵심 정리

• 계획 단계는 프로젝트 헌장이라는 큰 틀을 범위·일정·원가·품질·형상관리 같은 구체적인 계획 문서(PMP)로 채워나가는 과정이다.
• 범위 관리는 WBS로 프로젝트를 작업패키지 단위까지 쪼개, 무엇이 이 프로젝트의 범위인지를 명확한 기준으로 남긴다.
• 일정 관리는 활동 정의부터 일정 개발까지 다섯 단계를 거치며, 외부 의존관계(PG사 심사 등)는 최대한 앞쪽에 배치해 리스크를 줄인다.
• 원가 관리는 상향식(정확하지만 느림)과 하향식(LOC·기능 점수 등에 기대는 빠른 추정) 두 방식을 상황에 맞게 쓴다.
• 품질·형상관리 계획은 기준과 변경 통제 절차를 미리 정해두는 일이고, 확인(요구사항을 제대로 이해했는가)과 검증(제대로 구현했는가)은 추적성으로 서로 연결돼야 한다.

다음 장(6장)에서는 이렇게 계획된 범위를 실제 요구사항으로 구체화하는 단계 — 요구사항 분석과 모델링을 다룬다.