"일이 되게 하는" 기술
1장에서 소프트웨어 개발은 계획부터 유지보수까지 여섯 단계를 거친다고 했다. 이번 장부터는 그 여섯 단계를 누가, 언제, 얼마의 예산으로 진행할지를 다루는 축 — 프로젝트 관리로 넘어간다. 프로젝트 관리를 한 문장으로 정의하면 "일이 되게 하는 과학(the science of getting things done)"이다. 아이디어는 좋았는데 결국 흐지부지된 프로젝트를 떠올려보면, 대개 기술이 부족해서가 아니라 관리가 없어서였다.
프로젝트는 왜 "특별 취급"이 필요한가
프로젝트는 회사의 일상 업무와 성격이 다르다. 책마루 매장의 계산대 운영은 매일 반복되는 **운영(operation)**이지만, "온라인 주문 시스템을 만든다"는 일은 다음 세 가지 특징을 가진 프로젝트다.
- 한시적(temporary): 시작일과 종료일이 있다. 시스템이 완성되면 프로젝트는 끝난다 (그 이후는 유지보수라는 별개의 활동).
- 유일함(unique): 책마루의 예산·인력·요구사항 조합은 다른 어떤 카페의 시스템 구축과도 같지 않다. 과거 사례를 참고할 수는 있어도 그대로 복사할 수는 없다.
- 점진적 구체화(progressive elaboration): 처음 계획은 추상적일 수밖에 없다. "온라인 주문 되게 해주세요"에서 시작해 진행하면서 점점 구체적인 계획으로 다듬어진다.
이 특징들 때문에 프로젝트는 표준화된 매뉴얼만으로 굴러가지 않는다. 매번 계획을 새로 세우고, 계획대로 가는지 계속 확인하는 관리 활동이 따로 필요하다.
PDCA — 모든 관리의 뼈대
프로젝트 관리의 바탕에는 PDCA(Plan-Do-Check-Action) 사이클이 있다. 계획하고(Plan), 실행하고(Do), 점검하고(Check), 개선한다(Action) — 이 네 박자가 프로젝트 전체에 반복 적용된다.
책마루 프로젝트로 예를 들어보자.
- Plan: "8주 안에, 500만원 예산으로 주문·결제·배달 기능을 갖춘 시스템을 만든다"는 계획을 세운다.
- Do: 개발자를 배정하고 실제로 화면과 서버를 만든다.
- Check: 4주 차에 진행 상황을 점검했더니 결제 연동이 예상보다 늦어지고 있다는 걸 발견한다.
- Action: 배달 기능의 범위를 줄이거나(범위 조정), 결제 연동에 인력을 추가하거나(자원 재배분), 일정을 1주 연장하는(일정 조정) 대응책을 정한다.
이 사이클이 한 바퀴로 끝나지 않고 프로젝트 종료까지 계속 반복된다는 점이 중요하다. "계획은 프로젝트 초반에 한 번 세우고 끝"이 아니라, 점검할 때마다 계획이 갱신된다.
두 종류의 프로세스: 무엇을 만들지, 어떻게 관리할지
프로젝트 안에는 서로 다른 성격의 두 프로세스가 함께 돌아간다.
- 제품 개발 프로세스: 분석 → 설계 → 구현 → 시험, 즉 1장에서 다룬 소프트웨어 생명주기 그 자체
- 프로젝트 관리 프로세스: 범위 관리, 일정 관리, 원가 관리, 품질 관리처럼 제품 개발이 계획대로 흘러가도록 감싸는 "우산(umbrella) 프로세스"
비유하자면 제품 개발 프로세스는 카페의 요리 레시피고, 프로젝트 관리 프로세스는 그 요리가 제시간에, 예산 안에서, 정한 맛으로 나오게 하는 주방 운영이다. 레시피만 있고 운영이 없으면 요리는 완성되지만 늘 늦게 나오거나 재료비가 초과된다.
PMBOK: 프로젝트 관리를 위한 공통 언어
국제 프로젝트관리협회(PMI)가 정리한 PMBOK(Project Management Body of Knowledge) 지침서는 산업 분야에 관계없이 쓸 수 있는 프로젝트 관리 표준이다. 이 지침서는 프로젝트 관리 활동을 5대 프로세스 그룹으로 나눈다.
| 프로세스 그룹 | 하는 일 | 책마루 예제 |
|---|---|---|
| 착수(Initiating) | 프로젝트를 공식적으로 승인 | 사장님이 예산 승인, 프로젝트 헌장 작성 |
| 기획(Planning) | 목표 달성을 위한 세부 계획 수립 | 일정표, 예산 배분, 리스크 목록 작성 |
| 실행(Executing) | 계획된 작업을 실제로 수행 | 개발자가 화면·서버 개발 |
| 감시 및 통제(Monitoring & Controlling) | 계획과 실제를 비교하고 시정 | 주간 진행 점검, 변경 요청 검토 |
| 종료(Closing) | 공식적으로 마무리 | 사장님 검수, 인수인계 문서 정리 |
이 다섯 그룹은 프로젝트의 "단계(phase)"가 아니라는 점에 유의할 필요가 있다. 착수에서 종료로 한 방향으로만 흐르지 않고, 특히 기획-실행-감시통제 셋은 프로젝트 내내 서로 되먹임하며 반복된다. PDCA로 보면 기획이 P, 실행이 D, 감시통제가 C와 A에 해당한다 — 결국 PMBOK의 프로세스 그룹은 PDCA를 프로젝트 관리에 맞게 풀어놓은 것이다.
여기에 범위·일정·원가·품질·인적자원·의사소통·리스크·조달·이해관계자 관리라는 10개 지식 영역을 교차시키면, "기획 단계에서 리스크를 어떻게 다루는가", "감시통제 단계에서 원가를 어떻게 통제하는가" 같은 구체적인 활동들이 매트릭스로 정리된다. (범위·원가·일정 관리는 22장에서, 품질 관리는 19장에서 따로 더 깊이 다룬다.)
프로젝트 헌장 — 프로젝트의 "정관"
착수 프로세스 그룹에서 가장 중요한 산출물은 **프로젝트 헌장(Project Charter)**이다. 프로젝트의 존재 자체를 공식적으로 승인하는 문서로, 보통 다음 내용을 담는다.
- 프로젝트의 목적과 정당성 ("배달 요청이 늘어 온라인 주문 채널이 필요")
- 상위 수준의 요구사항과 범위 ("주문·결제·배달 추적, 회원 관리는 이번 범위 제외")
- 예산과 일정의 개략치 ("500만원, 8주")
- 프로젝트 관리자의 권한 범위 ("외주 개발사 선정 권한, 최종 지출 승인은 사장님")
- 주요 이해관계자
책마루 프로젝트라면 이 헌장 한 장이 없을 때 무슨 일이 생길까? 개발이 진행되다가 "회원 등급별 할인도 넣어주세요"라는 요청이 들어왔을 때, 이게 원래 범위인지 추가 범위(=추가 비용·일정)인지 판단할 근거가 없다. 헌장은 이런 상황에서 "이건 원래 약속한 범위가 아니다"라고 근거를 대는 문서 역할을 한다 — 프로젝트의 방향이 흔들릴 때 되돌아갈 기준점이다.
이해관계자를 놓치면 생기는 일
착수 단계의 또 다른 핵심 활동은 이해관계자 식별이다. 책마루 프로젝트의 이해관계자를 나열해보면 이렇다.
- 스폰서: 사장님 — 예산 승인권, 최종 수락 여부 결정권
- 현업 사용자: 매장 직원 — 실제로 주문 알림을 받고 포장을 하게 될 사람들
- 고객: 동네 손님들 — 시스템을 쓰게 될 최종 사용자
- 외부 이해관계자: 결제대행사, 배달 연동사 — 기술적 제약을 거는 존재
이 중 매장 직원을 빠뜨리면 어떤 일이 생길까? 사장님 입장의 요구사항("주문이 잘 들어오면 된다")만 반영하고 직원 입장("포장 목록을 프린터로 뽑고 싶다", "재고가 없으면 자동으로 품절 처리되면 좋겠다")을 놓치면, 시스템은 완성돼도 현장에서 안 쓰이는 시스템이 된다. 이해관계자 식별이 착수 단계에서 이루어지는 이유는, 이 단계에서 빠뜨린 이해관계자의 요구는 뒤로 갈수록 반영 비용이 커지기 때문이다.
10개 지식 영역, 한 장으로 훑기
PMBOK은 프로세스 그룹(언제)과 별개로 지식 영역(무엇을) 10가지를 정의한다. 각 지식 영역은 뒤에서 별도 장으로 다룰 만큼 크지만, 지금은 책마루 프로젝트에 대입해 감을 잡는 정도로 충분하다.
| 지식 영역 | 책마루 프로젝트에서의 의미 |
|---|---|
| 통합 관리 | 헌장 작성부터 종료까지 프로젝트 전체를 하나로 묶어 조율 |
| 범위 관리 | "주문·결제·배달 추적까지"로 선을 긋고 지키기 (22장) |
| 일정 관리 | 8주 안에 어떤 순서로 무엇을 끝낼지 (5장) |
| 원가 관리 | 500만원을 기능별로 어떻게 배분할지 (22장) |
| 품질 관리 | "3초 이내 로딩" 같은 기준을 지켰는지 확인 (19장) |
| 인적자원 관리 | 개발자·디자이너를 누가, 언제 투입할지 |
| 의사소통 관리 | 사장님에게 매주 진행 상황을 어떻게 보고할지 |
| 리스크 관리 | 결제대행사 심사 지연 같은 위험을 미리 대비 |
| 조달 관리 | 외주 개발사를 어떻게 선정하고 계약할지 |
| 이해관계자 관리 | 직원·손님·PG사의 요구를 누락 없이 반영 |
이 10개를 전부 별도 문서로 챙기는 건 대기업 프로젝트 얘기고, 책마루처럼 작은 프로젝트에서는 이 표 자체가 체크리스트 역할을 한다 — "이 중에 우리가 전혀 안 챙기고 있는 항목이 있는가"를 점검하는 용도로 충분하다.
리스크는 미리 적어두는 것만으로 절반은 막는다
리스크 관리는 10개 지식 영역 중에서도 소규모 프로젝트가 가장 먼저 생략하는 항목이다. 하지만 "일어날 수 있는 나쁜 일을 미리 목록으로 적어두는 것"만으로도 실제 발생 시 대응 속도가 크게 달라진다. 책마루 프로젝트의 리스크 목록은 이런 식으로 시작할 수 있다.
| 리스크 | 발생 가능성 | 영향 | 대응 |
|---|---|---|---|
| 결제대행사 가입 심사가 예상보다 오래 걸림 | 중간 | 결제 기능 지연 | 프로젝트 착수와 동시에 PG사 가입부터 신청 |
| 매장 직원이 새 태블릿 사용을 낯설어함 | 높음 | 오픈 초기 주문 누락 | 오픈 1주 전 직원 대상 리허설 진행 |
| 배달 가능 지역 기준이 모호함 | 낮음 | 요구사항 재작업 | 요구사항 분석 단계에서 우편번호 목록으로 명확히 확정 |
리스크 관리의 핵심은 표를 정교하게 만드는 것이 아니라, 착수 시점에 이런 대화를 한 번이라도 하고 넘어가는 것이다. 리스크를 적어두지 않은 프로젝트는 문제가 터진 뒤에야 대응책을 즉흥적으로 찾게 되고, 그 즉흥적인 대응이 일정과 예산을 추가로 갉아먹는다.
프로젝트 조직은 어떻게 구성하는가
프로젝트를 누가, 어떤 구조로 수행하느냐도 관리의 일부다. 조직 구조는 보통 세 가지로 나뉜다.
- 기능 조직: 개발팀·디자인팀처럼 부서별로 나뉜 조직. 프로젝트 관리자의 권한이 약하고, 자원은 각 부서장이 쥐고 있다.
- 프로젝트 조직: 프로젝트를 위해 전담 팀을 따로 꾸린다. 프로젝트 관리자의 권한이 강하지만, 프로젝트가 끝나면 팀이 해체된다.
- 매트릭스 조직: 기능 조직과 프로젝트 조직을 절충한 형태. 팀원이 부서장과 프로젝트 관리자 양쪽에 동시에 보고한다.
책마루처럼 외주 개발사에 맡기는 소규모 프로젝트는 사실상 프로젝트 조직에 가깝다 — 이 프로젝트를 위해 모인 소수의 인원이 시작부터 끝까지 함께 간다. 조직 구조를 이야기하는 이유는, 구조에 따라 "프로젝트 관리자가 실제로 얼마나 결정권을 갖는가"가 달라지기 때문이다. 권한이 약한 구조에서 관리자가 강한 구조를 흉내 내려 하면 곳곳에서 마찰이 생긴다.
감시 및 통제 — 변경을 함부로 반영하지 않는다
실행 단계에서 계획과 다른 일이 생기는 건 당연하다. 문제는 그 변경을 누가 승인하는가다. 책마루 프로젝트 중간에 "배달 지역을 옆 동네까지 넓혀달라"는 요청이 들어왔다고 하자. 이 요청을 개발자가 임의로 반영해버리면 일정과 예산이 소리 없이 틀어진다.
PMBOK에서는 이런 변경 요청을 검토·승인하는 주체로 **변경통제위원회(Change Control Board)**라는 개념을 둔다. 책마루처럼 작은 프로젝트에서는 위원회씩이나 꾸릴 필요는 없지만, 원칙은 똑같이 적용된다 — 변경 요청은 문서화하고, 일정·비용에 미치는 영향을 따져보고, 승인권자(사장님)의 확인을 받은 뒤에만 반영한다. 이 원칙이 없으면 "범위 관리"라는 말 자체가 무의미해진다.
핵심 정리
- 프로젝트는 한시적이고 유일하며 점진적으로 구체화된다는 점에서 일상 업무와 다르고, 그래서 별도의 관리 활동이 필요하다.
- PDCA 사이클이 프로젝트 관리의 기본 골격이며, PMBOK의 착수-기획-실행-감시통제-종료 5대 프로세스 그룹은 이 사이클을 프로젝트에 맞게 구체화한 것이다.
- 제품 개발 프로세스(무엇을 만들지)와 프로젝트 관리 프로세스(어떻게 관리할지)는 서로 다른 축이며 함께 돌아간다.
- 프로젝트 헌장은 프로젝트의 목적·범위·권한을 못 박아, 나중에 방향이 흔들릴 때 되돌아갈 기준이 된다.
- 이해관계자를 착수 단계에서 빠짐없이 식별하지 않으면, 뒤늦게 발견된 요구사항은 훨씬 비싼 비용으로 반영해야 한다.
다음 장(5장)에서는 이 프로젝트 헌장을 바탕으로 실제 일정과 산출물을 짜는 프로젝트 계획 단계를 다룬다.