3줄 요약
- PMBOK 12장 조달 관리는 “만들까 살까(Make or Buy)”를 결정하고, 계약 유형으로 리스크를 배분하며, 계약 이행을 통제하는 체계다.
- 고정가(FP) 계약은 공급자가 리스크를 지고, 시간·자재(T&M) 계약은 발주자가 리스크를 진다. 범위 확실성에 따라 선택이 달라진다.
- PSTA는 계약·발주·정산 기능이 없다. 외주 작업을 Action으로 등록해 진척을 함께 보는 정도만 가능하다 — 조달 전용 도구를 별도로 써야 한다.
“외주 업체가 요구사항대로 만들었다고 하는데 우리가 원한 건 이게 아니다.” 개발 PM이라면 한 번쯤 들어봤거나, 직접 겪어봤을 말이다. 소프트웨어 외주 계약에서 발주자와 수주자가 같은 문서를 보면서 다른 그림을 그리는 일은 생각보다 훨씬 자주 일어난다. PMBOK 12장 조달 관리는 이 문제에 대한 정석적인 답을 담고 있다. 결론부터 말하면: 조달 관리의 핵심은 계약 유형 선택이 곧 리스크 배분이라는 사실을 이해하는 것이다. 발주자가 리스크를 질 것인가, 공급자에게 넘길 것인가 — 이 판단이 계약서 한 줄에 담긴다.
📖 PMBOK이 말하는 조달 관리: 정석의 3단계
조달 관리(Procurement Management)란 프로젝트 팀 외부에서 제품·서비스·결과물을 확보하는 전 과정을 계획하고 통제하는 지식 영역이다. PMBOK은 이를 크게 세 단계로 구분한다.
1단계 — 조달 계획(Plan Procurement Management)
가장 먼저 “만들까, 살까(Make or Buy)”를 결정한다. 내부에서 직접 개발·수행할지, 외부에서 구매하거나 외주를 줄지를 비용·역량·일정·전략적 중요성 등을 고려해 의식적으로 선택하는 과정이다. 이 결정이 확정되면 작업기술서(SOW, Statement of Work)를 작성한다. SOW란 공급자가 수행해야 할 작업의 범위·내용·인도물·기준을 구체적으로 서술한 문서다. SOW가 부실하면 이후 모든 단계가 흔들린다.
2단계 — 조달 수행(Conduct Procurements)
공급자를 선정하는 단계다. 입찰 공고를 내고 제안 요청서(RFP, Request for Proposal)를 발송하며, 응찰한 업체의 제안서를 평가해 최종 공급자를 선정하고 계약을 체결한다. 이 과정에서 계약 유형이 결정된다.
PMBOK이 정의하는 주요 계약 유형은 세 가지다.
- 고정가(FP, Fixed Price) — 총 금액을 미리 확정한다. 범위가 명확할 때 유리하다. 비용 초과 리스크는 공급자가 부담한다. 발주자 입장에서는 예산 확실성을 얻는다.
- 원가 정산(CR, Cost Reimbursable) — 실제 발생한 원가에 수수료(Fee)를 더해 정산한다. 범위가 불확실하거나 요구사항이 진화할 때 사용한다. 비용 리스크는 발주자에게 있다.
- 시간·자재(T&M, Time and Materials) — 투입 시간과 재료비를 단가로 정산한다. 소규모·단기 프로젝트나 범위를 정하기 어려운 작업에 쓰인다. 발주자가 비용 초과 리스크를 모두 진다.
3단계 — 조달 통제(Control Procurements)
계약 체결 후 공급자의 이행을 관리하고, 계약 범위 변경 시 변경 절차를 따르며, 최종적으로 인수 조건(Acceptance Criteria)을 확인하고 계약을 종료하는 단계다. 계약 통제를 제대로 하지 않으면 “추가 요청”이 구두로 쌓이고, 결국 정산 시 분쟁이 발생한다.
✅ 읽으며 좋았던 점: 계약 유형이 곧 리스크 배분표다
12장을 읽으면서 가장 유익했던 통찰은 “계약 유형 선택 = 리스크를 누가 감수하느냐”라는 관점이다. 많은 PM이 계약서를 법무팀이나 구매팀 소관으로 넘기고 기술 사양에만 집중하는 경향이 있다. 그러나 계약 유형을 모르면 프로젝트 리스크 구조 자체를 모르는 것이다.
예를 들어 요구사항이 명확하게 고정된 단순 유지보수 작업을 T&M으로 발주하면, 업체 입장에서는 시간을 끌수록 이익이 된다. 반대로 요구사항이 계속 바뀌는 신규 서비스 개발을 고정가(FP)로 수주한 업체는 중간에 적자가 나면 품질을 희생하거나 계약 분쟁을 일으킨다. 계약 유형 하나가 프로젝트 전체의 인센티브 구조를 결정한다는 사실을 명시적으로 가르쳐주는 점에서 이 장은 실용적이다.
또 “Make or Buy”를 의식적으로 결정하라는 요구도 유효하다. 많은 팀이 “우리가 할 수 있으니까 만들자”는 감으로 내재화 결정을 내리거나, 반대로 “귀찮으니 외주 주자”는 식으로 전략 없이 외주를 택한다. 비용·역량·일정·전략적 중요성을 항목별로 비교해 결정하라는 구조적 접근은 현장에서도 충분히 써먹을 수 있다.
⚠️ 현장과의 괴리: 순수 내부 개발팀엔 조달이 낯설다
솔직히 말하면, 내부 인력으로만 운영하는 스타트업이나 소규모 SW 개발팀에게 PMBOK 12장은 상당 부분이 현실과 동떨어져 보인다. 공개 입찰·RFP·공식 계약 종료 같은 프로세스는 공공 발주나 대기업 조달 부서가 있는 환경을 전제로 설계된 것이다.
그러나 한국 SI·외주 시장의 현실은 다르다. 수주 업체 PM이라면 “추가 요청”이 구두로 쌓이다가 마지막에 한꺼번에 정산을 요청하거나, 반대로 발주처가 “이건 원래 계약 범위에 있던 것”이라며 추가 비용을 부인하는 상황을 겪어봤을 것이다. 스타트업이 프리랜서·외주 업체에 개발을 맡길 때도 비슷하다. 노션이나 카카오톡으로 요구사항을 전달하고, 구두로 마감을 합의하며, 검수 기준 없이 “완성이면 됩니다”로 계약이 끝나는 경우가 여전히 많다.
PMBOK의 조달 프로세스를 그대로 쓰기는 어렵지만, 그 안에 담긴 핵심 사고 — SOW 명확화, 계약 유형별 리스크 인식, 인수 기준 사전 합의 — 는 규모와 무관하게 적용할 수 있다.
🔧 실전 번역: 소프트웨어 외주 계약에서 살아남는 법
PMBOK 12장을 IT 현장 언어로 번역하면 다음 다섯 가지로 압축된다.
- SOW를 계약서에 붙여라. 구현 범위·인도물·완료 기준을 문서로 명확히 하고, 계약서 별첨으로 포함한다. “요구사항 명세서에 있는 기능 전부”라는 표현은 분쟁의 씨앗이다. 기능 목록을 행 단위로 나열하고, 각 항목에 검수 기준을 함께 적는다.
- 범위가 확실하면 고정가(FP), 불확실하면 T&M 또는 단계 분리. 요구사항이 잘 정의된 유지보수·단순 기능 추가는 FP로 발주해 예산을 고정한다. 신규 서비스처럼 요구사항이 변할 여지가 크다면 T&M 또는 전체를 단계(Phase)로 쪼개 단계별 FP 계약으로 리스크를 분산한다.
- “추가 요청”은 반드시 변경 계약(Change Order)으로. 슬랙이나 카카오톡으로 합의한 추가 요청은 계약 효력이 없다. 아무리 소소한 기능이라도 범위 변경이면 서면으로 합의하고 대가를 확정한다. “나중에 정산하자”는 분쟁 예약이다.
- 마일스톤 기반 분할 정산으로 레버리지를 유지하라. 착수금·중간 인도물·최종 검수 단계별로 대금을 쪼개 지급하면 공급자의 이행 인센티브를 유지하면서 발주자의 레버리지도 보존한다. 선불로 100%를 지급하면 이후 수정 협상력이 급격히 낮아진다.
- 인수 조건(Acceptance Criteria)을 계약 전에 합의하라. “만족스러운 품질”이 아니라 “API 응답 시간 95th percentile 2초 이하, 결제 모듈 단위 테스트 커버리지 80% 이상” 같이 수치화된 기준을 사전에 서면으로 정한다. 검수 분쟁의 90%는 인수 기준 부재에서 발생한다.
스타트업 PM을 위한 추가 조언: 프리랜서·외주 업체를 쓸 때 계약 규모가 작다고 SOW를 생략하지 말 것. 오히려 소규모 외주일수록 명문화된 범위가 더 중요하다. 금액이 크지 않을수록 분쟁 해결 비용(시간·감정·기회비용)이 상대적으로 더 크기 때문이다.
PSTA로 보면
🟥 PSTA가 도움이 되는 지점: 외주 업체와 협업할 때, 해당 작업을 PSTA의 Action으로 등록하면 진척과 산출물을 내부 팀과 함께 추적할 수 있다. 외주 공급자가 제출한 산출물(설계서·테스트 결과·배포 이력)을 Action에 첨부하거나 상태 이력으로 남기면, 검수 시점에 “언제 무엇을 납품했는가”의 근거를 박제할 수 있다. 마일스톤별 Action 완료 상태를 정산 근거로 활용하는 방식도 가능하다.
🟨 PSTA도 아쉬운 점 — 계약·벤더 관리 기능 없음: 솔직하게 말하면 PSTA는 조달 관리 도구가 아니다. SOW 작성, 입찰 관리, 계약서 버전 관리, 정산 승인 워크플로 같은 기능은 PSTA에 없다. 외주 공급자를 PSTA 워크스페이스에 초대해 함께 쓸 수는 있지만, 계약 이행 관리나 변경 계약 추적은 별도 도구(계약 관리 솔루션 또는 스프레드시트라도)를 써야 한다. 조달 특화 기능이 필요하다면 PSTA만으로는 부족하다는 점을 분명히 밝혀 둔다.
🎓 이 장을 떼면 당신은 이걸 할 수 있다
- 외주·프리랜서 계약 전에 “Make or Buy” 판단 근거를 문서화할 수 있다.
- 프로젝트 범위 확실성에 따라 FP·T&M·단계별 계약 유형을 골라 리스크를 배분할 수 있다.
- SOW(작업기술서)에 범위·인도물·검수 기준을 포함해 작성할 수 있다.
- 구두로 쌓이는 “추가 요청”을 변경 계약 절차로 전환해 분쟁을 예방할 수 있다.
- 마일스톤 기반 분할 정산으로 공급자 이행 인센티브와 발주자 레버리지를 동시에 유지할 수 있다.
❓ FAQ
고정가(FP)와 T&M 계약의 차이는 무엇인가?
고정가(FP) 계약은 총 금액을 사전에 확정해 비용 초과 리스크를 공급자가 진다. 범위와 요구사항이 명확할 때 발주자에게 유리하다. 시간·자재(T&M) 계약은 실제 투입 시간과 단가로 정산하므로 비용 초과 리스크를 발주자가 모두 부담한다. 범위가 불명확하거나 요구사항이 자주 바뀌는 초기 단계 개발에 적합하다. 핵심은 리스크를 누가 감수하느냐의 선택이다.
소프트웨어 외주 검수 분쟁을 어떻게 예방할 수 있나?
분쟁의 근본 원인은 대부분 인수 기준(Acceptance Criteria) 부재다. 계약 전에 “무엇을 어떤 수준으로 납품하면 완료로 인정하는가”를 수치와 목록으로 명문화해야 한다. 기능 체크리스트, 성능 수치, 테스트 커버리지 기준 등을 계약서 또는 SOW에 첨부하고, 양측이 서명한 상태에서 프로젝트를 시작하면 검수 단계의 해석 차이를 크게 줄일 수 있다.
작업기술서(SOW)에 반드시 담아야 할 내용은?
SOW의 핵심 항목은 네 가지다. ① 범위(무엇을 만드는가 — 기능 목록과 제외 항목 명시), ② 인도물(언제 무엇을 납품하는가 — 마일스톤별 산출물), ③ 완료 기준(각 인도물을 어떻게 검수하는가 — 수치 기준 포함), ④ 전제 조건과 제약(발주처가 제공할 데이터·API·환경, 공급자가 가정한 조건). 이 네 항목이 빠지면 SOW가 아니라 구두 합의의 종이 버전에 불과하다.
스타트업이 외주 개발을 맡길 때 특히 주의할 점은?
스타트업은 첫 외주 계약에서 두 가지 실수를 자주 한다. 첫째, 요구사항이 정해지지 않은 상태에서 고정가 계약을 맺어 중간에 요구사항이 바뀔 때마다 갈등이 생긴다. 초기에는 T&M 또는 단계별 FP 계약으로 유연성을 확보하는 것이 낫다. 둘째, 슬랙·카카오톡 메시지로 “이것도 해주세요”를 남발하다가 정산 시 “그건 계약 범위 밖입니다”로 충돌한다. 아무리 작은 추가 요청이라도 서면으로 합의하고 변경 계약 처리하는 습관이 장기적으로 공급자와의 신뢰도 높이고 분쟁도 줄인다.
조달 관리는 PM의 영역이지만, 계약서는 법무·구매팀 몫이라고 선을 긋는 순간 프로젝트 리스크의 절반을 통제력 밖으로 넘기는 것이다. SI 검수 분쟁이든 스타트업의 프리랜서 갈등이든, 결국은 계약 전에 범위와 기준을 얼마나 정밀하게 서면화했느냐로 귀결된다. 프로젝트 관리 도구나 솔루션은 그 이후의 이행 추적을 돕는 것이고, 계약 자체를 대신할 수는 없다. 외주를 준다면 SOW부터 시작하라.
PSTA나 프로젝트 관리 도입을 고려 중이라면 주니크(GUNIQ) 상담 페이지를 참고하거나 psta.app에서 직접 살펴볼 수 있다.
『PMBOK 완독기』 시리즈
← 이전: 09. 리스크관리: 관리대장을 살리는 법 (11장)
→ 다음: 11. 이해관계자관리: 가시성 (13장)
