같은 SI 프로젝트, 두 PM.
A는 계약서에 도장을 찍자마자 개발자들에게 "일단 화면부터 만들어 주세요"라고 말합니다. 목표도, 범위 경계도, 누가 무엇을 결정하는지도 정리하지 않았습니다. 3개월 뒤, 발주사는 "이건 우리가 원한 게 아닌데요"라고 하고, 개발팀은 "요구대로 만들었는데요"라고 합니다. 검수에서 막히고, 추가 개발 비용을 누가 댈지로 다툼이 시작됩니다.
B는 착수하자마자 Kick-off 미팅을 엽니다. 목표와 범위(무엇을 하고 무엇을 안 하는지), 역할과 책임, 일정과 마일스톤, 보고 방식을 한자리에서 합의합니다. 그리고 "이 사업은 요구가 초기에 거의 확정됐고 규제 검수가 강하다"고 판단해 예측형(워터폴) + 단계별 검수 게이트로 진행하되, 변동이 잦은 일부 화면만 반복 개발로 묶는 하이브리드를 택합니다. 같은 3개월 뒤, B의 프로젝트는 검수 게이트를 차례로 통과하고 있습니다.
둘의 차이는 손이 빠르고 느린 게 아닙니다. 프로젝트를 어떤 생애주기로 흐르게 하고, 어떤 접근법으로 일할지를 처음에 설계했는가입니다. 이 모듈은 그 설계 — 생애주기 단계와 접근법 선택 — 를 다룹니다.
- 1프로젝트 생애주기 5단계(착수·기획·실행·감시통제·종료)의 역할과 순서를 설명할 수 있다
- 2Kick-off(착수) 미팅에서 무엇을 합의·공유해야 하는지 체크리스트로 말할 수 있다
- 3예측형(워터폴)·애자일(반복)·하이브리드의 차이와 각각의 장단점을 구분할 수 있다
- 4요구 명확성·변화 빈도·규제를 기준으로 어떤 접근법이 적합한지 판단할 수 있다
- 5한국 SI/SM 프로젝트에서 예측형 + 검수 게이트가 흔한 이유를 맥락으로 설명할 수 있다
프로젝트는 단계를 따라 흐른다
생애주기 5단계 — 시작에서 끝까지의 골격
프로젝트는 "어느 날 그냥 시작되고 어느 날 그냥 끝나는" 것이 아닙니다. 같은 모양의 단계를 거치며 흐릅니다. 이 골격을 알면, 지금 우리가 프로젝트의 어디쯤 와 있고 다음에 무엇을 해야 하는지가 보입니다.
다섯 단계는 다음과 같습니다.
| 단계 | 한 줄 정의 | 이 단계의 핵심 질문 | 대표 산출물 |
|---|---|---|---|
| 착수(Initiating) | 프로젝트를 공식적으로 출범시킨다 | "왜 이 프로젝트를 하는가? 누가 책임지는가?" | 프로젝트 헌장, 핵심 이해관계자 식별 |
| 기획(Planning) | 어떻게 할지 계획을 세운다 | "무엇을, 언제까지, 누가, 얼마로 하는가?" | 범위·WBS·일정·원가·리스크 계획 |
| 실행(Executing) | 계획대로 일을 수행한다 | "계획한 산출물을 실제로 만든다" | 개발 결과물, 진척 보고 |
| 감시 및 통제(Monitoring & Controlling) | 계획과 실제의 차이를 측정·시정한다 | "계획대로 가고 있는가? 벗어나면 어떻게 잡는가?" | 진척률, 변경요청, 시정조치 |
| 종료(Closing) | 인도하고 마무리·정리한다 | "인수받았는가? 무엇을 배웠는가?" | 최종 인수, 교훈(lessons learned) |
여기서 자주 오해하는 지점이 두 가지입니다.
- 감시 및 통제는 '실행 다음'이 아니라 실행과 나란히 돈다. 실행이 진행되는 내내 계획 기준선(baseline) 대비 일정·원가·범위를 측정하고, 벗어나면 바로 시정하거나 변경 절차를 태웁니다. 통제가 약하면 범위가 슬그머니 늘어나는 **스코프 크립(scope creep)**이 일어나도 아무도 모릅니다.
- 단계는 칼로 자르듯 끊기지 않는다. 실제로는 기획과 실행이 겹치고, 접근법(특히 애자일)에 따라 이 단계들이 짧게 반복됩니다. 생애주기는 '순서대로 한 번'이 아니라 '일이 흐르는 골격'으로 이해하는 편이 정확합니다.
Kick-off — 같은 그림 위에 올라서는 자리
착수 단계의 핵심 이벤트가 Kick-off(착수) 미팅입니다. 프로젝트가 본격적으로 굴러가기 전에, 관련된 모든 사람을 한자리에 모아 같은 그림을 그리는 자리입니다. 시나리오의 A가 실패한 이유가 바로 이 자리를 건너뛴 것이었습니다.
Kick-off에서 합의·공유해야 하는 것은 다음과 같습니다.
| 항목 | 무엇을 맞추나 | 안 맞추면 생기는 일 |
|---|---|---|
| 목표·배경 | 이 프로젝트가 왜 존재하고 무엇을 이루려는가 | 각자 다른 목표를 향해 일한다 |
| 범위(Scope) | 무엇을 하고 무엇을 안 하는가 | 검수 단계에서 "이건 빠졌잖아"로 다툼 |
| 역할과 책임(R&R) | 누가 결정·수행·검토·승인하는가 | 결정이 안 나거나 책임 떠넘기기 |
| 일정·마일스톤 | 언제 무엇이 끝나야 하는가 | 마감이 닥쳐야 늦은 걸 안다 |
| 의사소통·보고 | 누가 누구에게 무엇을 언제 보고하는가 | 발주사가 깜깜이가 되어 불신이 쌓인다 |
| 주요 리스크 | 무엇이 프로젝트를 위협하는가 | 알았던 위험에 그대로 당한다 |
범위에서 "무엇을 안 하는가"(범위 제외, out of scope)를 명시하는 것이 특히 중요합니다. 한국 SI에서 분쟁의 상당수는 "그건 당연히 포함인 줄 알았다"에서 출발합니다. 처음에 경계선을 그어 두면, 나중에 들어오는 추가 요구는 자연스럽게 변경 절차로 흘러갑니다.
같은 일도 다른 방식으로 — 세 가지 접근법
예측형 · 애자일 · 하이브리드
프로젝트를 '어떻게' 진행할지에는 크게 세 가지 길이 있습니다. 좋고 나쁨이 아니라, 상황에 맞느냐의 문제입니다.
- 예측형(Predictive, 워터폴): 요구사항을 앞에서 최대한 확정한 뒤, 분석 → 설계 → 개발 → 검수 → 인도를 순차적으로 진행합니다. 단계마다 산출물과 검수 게이트가 있어 진척이 명확하고 계약·감사에 강합니다. 대신 뒤에서 요구가 바뀌면 비용이 큽니다.
- 애자일(Agile, 반복·점진): 짧은 주기(스프린트)로 작동하는 결과물을 반복해 만들고, 매 주기마다 피드백을 받아 변화를 수용합니다. 요구가 불확실하거나 자주 바뀌는 제품 개발에서 빛납니다. 대신 "최종 범위·일정·금액을 처음에 못 박는" 계약과는 잘 안 맞습니다.
- 하이브리드(Hybrid, 혼합): 큰 틀(범위·일정·산출물·검수)은 예측형으로 묶어 계약 안정성을 지키고, 변동이 잦은 일부(예: UI, 일부 기능)는 반복적으로 개발해 변화를 흡수합니다. 두 방식의 강점을 한 프로젝트에 섞습니다.
세 접근법을 한 표로 비교하면 다음과 같습니다.
| 비교축 | 예측형(워터폴) | 애자일(반복) | 하이브리드(혼합) |
|---|---|---|---|
| 요구사항 | 초기에 확정 | 진행하며 발전 | 큰 틀 고정 + 일부 유동 |
| 진행 방식 | 순차(분석→설계→개발→검수) | 짧은 반복(스프린트) | 골격은 순차 + 일부 반복 |
| 변화 대응 | 약함(변경 비용 큼) | 강함(변화 환영) | 중간(통제된 변화 수용) |
| 적합 상황 | 요구 안정·규제·검수 강함 | 요구 불확실·빠른 피드백 | 둘이 섞인 현실적 사업 |
| 장점 | 진척·계약·감사에 명확 | 빠른 가치 인도·유연성 | 안정성과 유연성의 절충 |
| 단점 | 뒤늦은 변화에 취약 | 고정 범위·계약과 충돌 | 운영 복잡·역할 혼선 가능 |
| 한국 SI 흔함 | 매우 흔함(+검수 게이트) | 제품·스타트업 중심 | 점점 늘어나는 절충안 |
핵심은 "애자일이 더 좋은 방법"이 아니라는 점입니다. 요구가 초기에 확정되고 규제 검수가 강한 사업에서 억지로 애자일을 끼우면, 계약·검수와 충돌해 오히려 혼란만 커집니다. 접근법은 유행이 아니라 상황의 함수입니다.
그림: 순차 진행의 예측형, 반복 진행의 애자일, 둘을 섞은 하이브리드를 요구·변화·상황 기준으로 비교 — 선택은 상황의 함수다.
직접 해보기 — 사업 4건의 접근법 고르기
아래 4개 사업을 읽고, 각각 (1) 예측형 / 애자일 / 하이브리드 중 무엇이 적합한지, (2) 그 근거를 요구 명확성·변화 빈도·규제/검수의 세 축으로 한 줄씩 적어 보세요. 정답과 해설은 ObserveBlock에 있습니다.
A. 공공기관 행정 시스템 재구축. 요구사항 정의서가 입찰 단계에서 확정됨.
단계별 산출물 검수와 감사 추적이 계약상 의무.
B. 사내 신규 모바일 앱. 사용자 반응을 보며 기능을 계속 바꿔 갈 예정.
초기 요구가 흐릿하고, 빠르게 출시해 피드백을 받고 싶음.
C. 금융사 차세대 시스템. 핵심 거래·정산은 요구가 고정이고 규제 검수가 강하지만,
고객용 화면(UI)은 출시 후에도 자주 바뀔 전망.
D. 스타트업 MVP. 2주마다 데모를 보여주며 투자자·사용자 피드백으로 방향을 잡음.
판단 직관: 요구가 굳어 있고 검수가 강하면 예측형, 요구가 흐릿하고 변화가 잦으면 애자일, 둘이 한 사업 안에 섞여 있으면 하이브리드입니다.
기준: 요구 명확성 · 변화 빈도 · 규제/검수 강도- A = 예측형(워터폴). 요구 확정 + 단계별 검수·감사 의무 → 순차 진행과 검수 게이트가 정확히 맞는 상황
- B = 애자일(반복). 초기 요구 흐릿 + 잦은 변화 + 빠른 피드백 → 스프린트로 작동 결과물을 반복 인도
- C = 하이브리드. 거래·정산은 규제·고정(예측형), 고객 화면은 변동 잦음(반복) → 한 사업에 두 방식 혼합
- D = 애자일(반복). 2주 데모 + 피드백 기반 방향 전환 = 애자일의 교과서적 상황
- 핵심 감각: "더 좋은 접근법"은 없다 — 요구 명확성·변화 빈도·규제/검수의 조합이 접근법을 결정한다
- 한국 SI 현실: A·C 같은 공공·금융 사업이 많아 예측형 + 검수 게이트가 기본값처럼 쓰이고, 하이브리드가 점점 늘어난다
현장에서 자주 보는 함정
증상: 개발은 다 끝났는데 검수 단계에서 발주사가 "이건 우리가 원한 게 아니다"라고 합니다. 개발팀은 "요구사항대로 만들었다"고 맞섭니다. 일정은 밀리고, 추가 개발 비용을 누가 부담할지로 감정 싸움이 됩니다.
원인: 두 가지가 겹친 경우가 대부분입니다.
- 착수에서 범위와 R&R을 명확히 합의하지 않았다(특히 "무엇을 안 하는가"가 빠짐). 그래서 "당연히 포함인 줄 알았다"가 양쪽에서 나옵니다.
- 요구가 바뀌었는데 변경 절차 없이 말로만 오갔다. 예측형 사업에서 통제 없는 변화는 그대로 분쟁이 됩니다.
해결 방향:
- Kick-off에서 범위(포함/제외)·R&R·검수 기준을 문서로 합의하고 서명합니다.
- 진행 중 새 요구는 반드시 **변경요청(Change Request)**으로 받아, 일정·원가 영향과 승인 여부를 기록합니다.
- 요구 변화가 잦을 게 뻔하면, 처음부터 하이브리드로 설계해 변동부를 반복 개발로 흡수합니다 — 변화를 '사고'가 아니라 '설계'로 만듭니다.
함정의 뿌리는 손이 느려서가 아니라, 생애주기 초반(착수·기획)에서 합의와 통제를 건너뛴 것입니다.
실무에서 접근법 선택은 PM·PMO·사업관리자의 첫 의사결정 중 하나입니다. 발주사·원청과 계약을 맺는 순간, 그 사업이 예측형으로 묶일지 일부라도 반복으로 굴러갈지가 일정·원가·검수·분쟁 가능성을 모두 좌우하기 때문입니다.
한국의 SI/SM 현장에서는 공공·금융 사업이 많아 예측형 + 단계별 검수 게이트가 사실상 기본값처럼 쓰입니다. 요구사항정의서가 입찰 단계에서 확정되고, 단계마다 산출물을 검수받아야 다음으로 넘어가는 구조죠. 그래서 PM은 "이번 검수에서 무엇을 인수받아야 하는가"를 늘 머릿속에 두고, 범위 밖 요구가 들어오면 변경 절차로 돌립니다. 동시에 화면·일부 기능처럼 변동이 잦은 부분은 반복적으로 개발하는 하이브리드가 점점 늘고 있어, "이 사업의 어디는 고정이고 어디는 유동인가"를 가르는 감각이 실무 경쟁력이 됩니다.
협력사(하도급) 개발팀이 실제 코드를 짜더라도, 어떤 생애주기와 접근법으로 일이 흐르게 할지를 설계하고, Kick-off에서 같은 그림을 그리게 하고, 검수 게이트를 통과시키는 책임은 관리자에게 있습니다. 접근법을 잘못 고르면 아무리 손이 빨라도 검수에서 막힙니다.
관련 모듈로 더 깊이:
- PMBOK 7 — 접근법 선택의 근거가 되는 조정 원칙·생애주기 성과 영역
- 범위와 요구사항 — 고른 접근법 위에 범위를 정의하고 검수 게이트를 거는 법
- WBS와 일정 관리 — 착수·기획에서 합의한 범위를 WBS와 일정으로 쪼개는 법
다음 모듈에서는 이렇게 고른 접근법 위에서 프로젝트의 뼈대를 세우는 작업 — 범위·요구사항을 정의하고 이를 WBS(작업분해구조)로 쪼개 일정과 책임으로 연결하는 방법을 다룹니다.