프로젝트를 추진하는 과정에서 ‘협약 및 계약’은 흔히 간과되기 쉽지만, 사실상 프로젝트 성패에 절대적인 영향을 미치는 요인이다. 어떤 자재를 언제 공급받을지, 외주 파트너가 어느 수준의 서비스를 제공해야 하는지, 그리고 이해관계자들이 어떠한 역할과 책임을 부담해야 하는지가 명확하지 않다면, 프로젝트 팀은 번번이 리스크에 노출되고 목표 일정을 지키기 어려워진다. PMBOK에서는 ‘4.6.8 협약 및 계약’을 중요한 결과물로 꼽고 있는데, 이는 단지 법적 구속력이 있는 문서를 만드는 것 이상의 의미를 지닌다. 프로젝트 기획부터 종료까지 전 영역에 걸쳐 ‘무엇을 누구와 어떻게 약속할 것인가’를 체계적으로 관리해야 한다는 점을 의미한다.
이 글에서는 협약과 계약의 본질적 개념을 이해하고, 이를 효과적으로 체결하고 운영하기 위한 프로세스를 차근차근 살펴본다. PMBOK 지식 영역인 조달관리(Procurement Management)와 통합관리(Integration Management), 그리고 이해관계자관리(Stakeholder Management), 커뮤니케이션관리(Communications Management)까지 폭넓게 연계되는 영역을 아울러 설명할 것이다. 또한 프로젝트 실무에서 흔히 맞닥뜨리는 계약 이슈와 그 해결 사례, 최신 트렌드(애자일 접근법) 및 디지털 툴(요구사항 추적 시스템 등)을 활용하는 방법도 함께 제시한다. 체계적인 협약 및 계약 프로세스가 정립되면, 프로젝트 팀은 예측 가능성을 높이고 필요할 때 신속하게 의사결정을 내릴 수 있다.
협약 및 계약의 핵심 개념
프로젝트에 있어 협약이란 무엇인가
협약이란, 프로젝트 수행자와 이해관계자 또는 고객·공급업체 간에 맺는 ‘상호 간의 약속’을 말한다. 이 약속은 구두일 수도 있지만, 대체로 서면 문서를 통해 구체적으로 명시되는 경우가 많다. PMBOK 조달관리(Procurement Management)에서 말하는 계약(Contract)도 넓은 범위의 협약에 포함되는 개념이며, 법적 효력을 갖는다. 예컨대 소프트웨어 개발 프로젝트에서는 외부 솔루션 업체와 ‘모듈 구매 계약’을 맺거나, 하드웨어 장비를 공급받는 ‘공급 계약’을 체결할 수 있다. 이러한 계약서에는 납품 일정, 대금 지급 조건, 품질 기준, 변경 절차 등이 세세하게 포함된다.
프로젝트 관리 관점에서 협약 및 계약은 단지 법률 문제에 국한되지 않는다. 특정 범위(Scope)에 대한 요구사항, 일정(Schedule), 원가(Cost)에 대한 리스크를 어떻게 배분할 것인가에 관한 협상이기도 하다. 계약서 조항을 통해 변경 요청이 발생했을 때의 절차, 의무 불이행 시의 책임 소재, 일정 지연에 따른 페널티 등 다양한 요소가 다뤄진다. 즉, 협약과 계약은 프로젝트 실행 전반에 영향을 미치는 ‘룰북(rulebook)’ 역할을 하며, 이해관계자들이 어떻게 협력해야 하는지를 명시해준다.
PMBOK에서의 계약 프로세스와 연계
PMBOK에서는 주로 ‘조달관리(Procurement Management)’를 통해 협약과 계약을 다룬다. 조달관리는 프로젝트에서 필요한 물품, 서비스, 결과물을 외부로부터 획득하는 모든 과정을 포괄한다. 구체적으로 다음과 같은 프로세스 그룹과 지식 영역을 염두에 두어야 한다.
- 계획 조달관리(Plan Procurement Management): 무엇을 언제, 그리고 어떻게 조달할지 결정한다. 이 과정에서 협약 및 계약에 필요한 범위, 요구사항, 스펙, 예산 등 핵심 요소를 초기 설정한다.
- 조달 수행(Conduct Procurements): 실제로 공급업체 선정 또는 파트너 계약을 체결한다. 제안서(RFP, RFQ 등) 작성, 입찰, 협상, 계약 체결이 포함된다.
- 조달 통제(Control Procurements): 체결된 계약이 제대로 이행되는지 확인한다. 납품이 지연되진 않는지, 품질이 계약 조건을 충족하는지 모니터링하며, 필요한 경우 계약 변경도 진행한다.
이 밖에도 통합관리(Integration Management) 측면에서, 각 계약이 프로젝트 전체 일정과 범위에 어떤 영향을 미치는지 지속적으로 연계해야 한다. 커뮤니케이션관리(Communications Management)에서는 이해관계자들에게 계약 정보를 정확히 전달하고, 계약과 관련된 이슈나 리스크를 투명하게 공유해야 한다. 또한 이해관계자관리(Stakeholder Management)는 계약 체결 시 협력업체나 외주사, 정부 기관 등이 어떻게 관여하는지를 체계적으로 파악한다.
협약 및 계약 체결 프로세스
요구사항 수집과 범위 정의
계약 체결의 첫걸음은 프로젝트 차원에서 ‘무엇을 외부에서 얻고, 내부에서 처리할 것인가’를 결정하는 것이다. 예를 들어 특정 IT 프로젝트를 진행한다고 가정하자. 이 프로젝트가 요구하는 인프라(서버, 네트워크 장비), 소프트웨어(라이선스), 인력(개발자, 디자이너), 자문 서비스(컨설팅) 중 어떤 부분을 외주로 돌려야 할지 구체적으로 판단해야 한다. 이는 PMBOK 범위관리(Scope Management)에서 요구사항 수집, 범위 정의 단계를 거치며, “프로젝트 목표 달성을 위해 어느 정도 수준의 외부 자원이 필요한가”를 명확히 하는 과정이다.
이 단계에서 자주 발생하는 이슈는 범위가 불명확하거나, 이해관계자 간에 서로 다른 기대치를 갖고 있다는 점이다. 예컨대 경영진은 “하드웨어 서버를 사서 구축하자”고 생각하지만, 현장 엔지니어는 “클라우드 호스팅이 더 경제적이다”라고 주장할 수 있다. 이런 갈등을 조기에 해소하기 위해서는, 관련 정보를 투명하게 공유하고, 장단점이나 비용·일정 시뮬레이션을 함께 검토하여 최종적으로 무엇을 계약할지 합의해야 한다.
계약 형태와 조달 전략 결정
프로젝트 요구사항이 정리되면, 어떤 형태의 계약을 맺을지 결정해야 한다. 아래 표는 대표적인 계약 유형을 간단히 요약한 예시다.
| 계약 유형 | 특징 | 예시 |
|---|---|---|
| 정액(Lump-Sum)/고정가(Fixed-Price) 계약 | 사전에 합의된 금액으로 전체 작업을 완수 | 소프트웨어 모듈 1개당 100만원에 구매 |
| 단가(Unit Price) 계약 | 실제 사용량에 따라 가격이 달라지는 구조 | 서버 임대료나 사용 시간 단가에 기반해 비용 산정 |
| 원가보상(Cost-Reimbursable) 계약 | 실제 소요 원가를 지불하고, 별도 인건비나 마진을 추가로 책정 | R&D 프로젝트, 컨설팅 업무에서 자주 활용 |
| 시간 및 자재(Time & Material) 계약 | 작업 시간 단위와 투입 자재 비용을 기준으로 청구 | 시간당 10만원, 자재비 실비 청구, 개발 서비스 |
이처럼 프로젝트 특성, 리스크 배분 의지, 시장 환경 등에 따라 계약 형태가 결정된다. 예컨대 범위가 명확하고 일정이 짧은 작업이면 고정가 계약이 유리하다. 반대로 연구개발이나 신규 기술 적용 등 범위를 예측하기 어려운 프로젝트라면 원가보상형 계약을 고려할 수 있다. PMBOK 조달관리 측면에서 계약 유형은 리스크와 밀접하게 연관된다. 고정가 계약은 발주 측(조달하는 쪽)은 비용을 예측하기 쉬운 반면, 공급업체는 범위가 늘어나면 손해를 볼 수 있다. 원가보상 계약은 공급업체 입장에서 위험이 작지만, 발주 측은 예산 초과 가능성을 염두에 둬야 한다.
계약 형태를 결정하는 데는 단순히 비용만이 아니라, ‘책임과 의무 분담’이라는 측면도 중요하다. 애자일 프로젝트에서는 빈번한 변경이 있을 수 있으므로, 너무 딱딱한 고정가 계약보다는 일부 유연성을 허용하는 형태의 계약이 적절할 수 있다. 예컨대 시간 및 자재(T&M) 계약을 맺고, 일정 기간 동안 특정 인원이 프로젝트에 전담 배정되는 구조를 택하면, 요구사항이 바뀔 때마다 별도 협상을 할 필요가 줄어든다.
협상과 계약서 작성
계약 형태가 결정되면, 실제로 파트너나 공급업체와 협상을 통해 세부 조건을 합의한다. 일반적으로 입찰(RFP, RFQ 등) 과정을 거쳐 여러 업체를 비교한 뒤, 최적의 후보를 선정해 계약서를 작성하게 된다. 계약서에는 다음과 같은 사항이 포함되는 경우가 많다.
- 범위(Scope): 공급 또는 수행해야 할 작업 내역, 인도물(deliverables)
- 일정(Schedule): 중간 마일스톤, 최종 납기일, 일정 지연 시 처리 방안
- 원가(Cost) 및 지불 조건: 총계약금, 지불 시점, 지급 방식
- 품질(Quality) 기준: 준수해야 할 규격, 테스트 또는 검수 기준
- 변경 관리(Change Control): 계약 내용 변경 시 승인 절차, 비용 및 일정 조정 방식
- 리스크(Risk) 및 책임 배분: 특정 위험 발생 시 어느 쪽이 어떻게 책임지는지, 보험 가입 여부
- 분쟁 해결 조항: 분쟁 발생 시 중재·협의 절차, 법률 적용 범위
- 해지 조건: 계약 해지 사유와 그에 따른 손해배상 범위
이는 PMBOK 조달관리의 ‘조달 수행(Conduct Procurements)’ 단계에 속하며, 이 과정에서 커뮤니케이션관리와 이해관계자관리의 협력이 필수적이다. 예컨대 외주 업체가 제안한 조건이 내부 정책과 충돌하면, 해당 부서(재무, 법무, 인사 등)와의 협의를 통해 조정해야 한다. 이렇게 여러 이해관계자가 관련된 조정 과정을 거쳐 최종 계약서가 완성되면, 프로젝트에서는 ‘법적·관리적 기반’이 마련된 셈이다.
계약 통제와 변경 관리
계약이 체결된 뒤에는 프로젝트 실행(Executing)과 모니터링 및 통제(Monitoring and Controlling) 단계에서 실제 계약 이행 상태를 감독한다. 납품이 지연되거나, 품질 문제가 발생하거나, 비용이 예상을 초과하는 상황이 발견되면, 즉시 공급업체와 조율해 원인을 파악하고 대응 조치를 취한다. 때로는 계약서의 수정이 불가피할 때가 있다. 예컨대 고객이 범위 확장을 요청하면서, 공급업체에게 추가로 기능을 개발해달라고 할 수 있다. 그러면 계약 금액이나 일정이 달라질 수밖에 없다.
이 과정은 PMBOK ‘조달 통제(Control Procurements)’ 프로세스에 해당한다. 변경이 생길 때마다 계약 변경 요청서를 작성하고, 필요하면 내부·외부 승인 절차를 거쳐 계약서를 수정한다. 디지털 요구사항 추적 시스템을 쓰면, 변경된 요구사항이나 협상 결과를 즉시 기록하고, 버전 관리가 용이해진다. 만약 이해관계자가 많고, 변경이 자주 발생하는 대규모 프로젝트라면, 자동화된 시스템 없이는 혼란이 커지기 쉽다. 모든 계약 변경 내역이 공유되지 않는다면, 엉뚱한 작업이 진행되거나 예산이 예기치 않게 초과될 위험이 있다.
프로젝트 실무에서 자주 발생하는 협약·계약 이슈와 해결 사례
범위 변동으로 인한 추가 비용 분쟁
프로젝트 현장에서 가장 빈번히 일어나는 문제는 범위 변동에 따른 추가 비용 문제다. 예를 들어, 발주자가 “프로젝트 목표를 달성하기 위해 더 많은 기능이 필요하겠다”라고 느끼고, 중도에 기능 확장을 요청할 수 있다. 반면 공급업체는 “당초 계약 범위에는 없었던 기능이므로 추가 비용이 필요하다”라고 주장한다. 만약 초기에 범위와 비용 조정 절차가 명시된 계약서를 갖고 있지 않다면, 서로의 해석이 달라 분쟁으로 비화하기 쉽다.
이 문제의 해결 사례로, 어떤 IT 회사는 프로젝트 초기에 세부 스펙을 유연하게 정의하고, “요구사항 추가 또는 변경 요청 시 단가 얼마로 비용을 산정한다”는 별도 조항을 계약서에 삽입했다. 이로써 범위 변경이 발생하면 즉시 공급업체와 협의를 통해 추가비용을 확정하고, 결제 프로세스를 간소화했다. 덕분에 프로젝트가 중단되지 않고 유동적으로 범위를 조정할 수 있었고, 공급업체 측에서도 불확실성을 줄일 수 있었다.
품질 불일치와 납기 지연
또 다른 흔한 문제는 “합의된 품질 수준에 도달하지 못했을 때, 재작업 비용을 누가 부담하는가”다. 예컨대 하청업체가 만든 부품이 요구 품질 기준에 미달했는데, 하청업체는 “지시 사항이 충분히 명확하지 않았다”고 항변하고, 발주 측은 “계약에 품질 기준이 명시되어 있으니 재작업 비용은 전적으로 하청업체가 부담해야 한다”고 주장할 수 있다.
이 경우 애초에 계약서에 테스트·검수 기준, 불합격 시 재작업 책임과 비용 분담, 일정 지연에 대한 페널티 조항을 명확히 규정해두면 문제가 훨씬 간단해진다. 예를 들어 ‘테스트에서 불합격 처리된 항목은 공급업체가 무상 재작업한다. 단, 품질 기준이 불분명하거나 임의로 변경되었다면, 추가 비용은 발주자가 부담한다’는 식이다. PMBOK 품질관리(Quality Management)와 조달관리(Procurement Management) 프로세스가 이처럼 상호 연계돼야 품질 이슈가 갈등으로 번지는 것을 최소화할 수 있다.
지연된 의사결정, 늦춰진 대금 지급
계약의 실행 과정에서 의사결정이 늦어져, 공급업체가 제때 대금 지급을 받지 못하거나, 중간 승인 절차에 딜레이가 생겨 작업이 지체되는 경우도 많다. 프로젝트가 복잡할수록, “담당자가 다른 업무에 바빠 승인 처리가 지연됐다”는 일이 비일비재하다. 이때 계약서에 “확인·검수·승인 요청 후 며칠 이내에 서면 피드백을 제공하지 않으면 자동 승인된 것으로 간주한다” 같은 타임라인 조항이 있으면, 의사결정 지연을 어느 정도 방지할 수 있다.
물론 발주 측에서는 “승인 없이 자동으로 넘어가는 것을 허용할 수 없다”고 반발할 수 있으므로, 업무 프로세스와 계약 조항을 어떻게 매끄럽게 연결하느냐가 중요하다. 최근에는 디지털 툴을 도입해 승인·결제 요청을 자동으로 알림해주고, 일정 기한 내 응답이 없으면 시스템이 재공지하도록 설정하는 방식도 시도되고 있다. 이처럼 계약 조항+프로세스+디지털 툴이 유기적으로 동작하면, 대금 지급이나 의사결정 지연이 최소화된다.
애자일 접근법과 협약·계약
빈번한 변경을 수용하는 계약 구조
애자일(Agile) 방식이 확산되면서, 전통적인 폭포수(Waterfall) 접근과 달리 요구사항이 스프린트 단위로 빠르게 변할 수 있다. 이는 계약 측면에서 “초기부터 모든 기능 범위와 비용을 확정하기 어렵다”는 문제를 야기한다. 일부 프로젝트 팀은 이를 해결하기 위해 “시간 및 자재(Time & Material)”나 “단가 계약(Unit Price)” 형태를 채택한다. 즉, 개발자가 실제로 투입된 시간만큼 비용을 지불하거나, 사용자 스토리 하나당 얼마 식으로 기능 단위를 기준으로 비용을 설정한다.
또 다른 방안으로, “기본 계약서 + 협상 옵션” 구조를 도입할 수도 있다. 예컨대 주요 기능은 고정가로 계약하고, 추가 기능이나 개선안은 스프린트별로 협상을 통해 단가를 정하거나, 일정에 따라 별도 계약을 체결한다. 이렇게 하면 애자일 프로젝트 특유의 유연성을 어느 정도 수용할 수 있다.
디지털 요구사항 추적 시스템과의 연계
애자일 환경에서는 지라(Jira), 애저 DevOps(Azure DevOps), 트렐로(Trello) 같은 시스템을 활용해 사용자 스토리, 백로그, 스프린트 계획을 관리한다. 만약 계약사항(예: 기능 추가 비용, 완료 조건, 승인 절차)이 이 툴과 별도로 관리되면, 실제 계약 범위와 개발 범위가 어긋나는 일이 발생할 수 있다. “스토리 10개를 완료해야 프로젝트가 1단계 종료”라고 계약에 써 있는데, 현장에서는 이미 12개 스토리를 진행하고 있을 수도 있다는 얘기다.
이런 문제를 피하려면, 요구사항 추적 시스템과 계약 관리 프로세스를 연동하여 기능이 추가되면 즉시 계약 변경 검토가 이루어지도록 설계해야 한다. 예를 들어 지라에서 새 에픽(Epic)을 만들 때, 비용이나 일정 영향도를 자동 계산해주는 플러그인을 사용하거나, PM이 별도로 계약 관리 모듈을 점검해 “이 이슈는 추가 비용 청구 대상인지”를 체크하는 식이다. 이 과정을 잘 운영하면, 애자일 프로젝트에서도 계약사항이 실시간으로 업데이트되어, 이해관계자들이 뒤늦게 “이 기능은 왜 추가됐고 비용은 누가 부담하지?” 같은 갈등을 겪지 않게 된다.
협약·계약 적용 시 주의점과 전체적 중요성
법률적 안정성과 프로젝트 유연성의 조화
계약은 법적 구속력을 갖는 만큼, 한 번 체결하면 쉽게 바꾸기 어렵다. 그러나 프로젝트는 수많이 변동되는 요소로 가득하다는 점을 생각하면, 안정성과 유연성 간의 균형이 중요하다. 너무 경직된 계약은 프로젝트 변화에 대응하기 어렵게 만들고, 지나치게 느슨한 계약은 책임 소재가 불명확해진다. 따라서 프로젝트 초기에 이 균형점을 잘 찾고, ‘경미한 변경은 언제든 허용하되, 주요 변경은 정식 협상을 통해 계약서를 수정한다’는 구조를 구축해야 한다.
이 과정에서 리스크관리(Risk Management)도 크게 작용한다. 시장 상황이 급변하거나, 기술적 난제가 예상보다 크게 발견될 가능성이 높은 프로젝트라면, 일정이나 비용 측면에서 유연함을 확보해두는 편이 낫다. 반면 안정적인 환경에서 반복적으로 수행되는 표준 작업이라면, 고정가 계약으로 비용 예측성을 높이고 관리 오버헤드를 줄이는 전략이 합리적이다.
이해관계자와 커뮤니케이션 계획
협약·계약에 관한 정보가 소수의 담당자에게만 공유되고, 나머지 팀원이나 경영진에게는 제대로 전달되지 않는다면, 프로젝트 전반이 위험에 처할 수 있다. 계약으로 인해 정해진 범위, 일정, 품질 기준, 리스크 책임이 실제로 어떻게 구성되어 있는지 모르는 상태에서 업무를 진행하면, 막판에 큰 갈등이 발생할 수 있다. 따라서 커뮤니케이션관리(Communications Management)에서 협약·계약 정보를 어떤 형식으로, 누구에게, 어느 시점에 공유해야 하는지 미리 계획해야 한다.
예를 들어 프로젝트가 일정 단계(마일스톤)에 도달했을 때, “현재 계약 범위를 모두 달성했는지, 추가로 계약 변경이 필요한지”에 대한 체크를 정례회의 의제로 삼는다. 이때 팀원들이 계약 범위를 잘 알고 있어야, “이 기능은 계약에 포함되어 있지 않은데, 작업 요청이 들어왔다” 같은 상황을 인지하고 즉시 보고할 수 있다. 또한 변경 발생 시 누구에게 어떤 서류를 제출해야 하는지도 명확히 안내해야, 승인 지연이나 중복 업무를 막을 수 있다.
간단한 예시: 소프트웨어 개발 계약 시나리오
예시 상황
가령 A회사에서 B외주사에게 ‘신규 CRM(Customer Relationship Management) 시스템’을 개발 의뢰한다고 하자. 계약 범위를 분석해보니, 핵심 기능으로 영업관리, 고객정보 조회, 리포팅 기능 등이 포함된다. 기간은 6개월이며, 예산은 3억 원 수준으로 잡았다.
A회사는 “스프린트마다 요구사항을 조정할 수도 있으니, 전체 범위를 확정하기 어렵다”고 주장한다. B외주사는 “고정가 계약이라면 우리에게 리스크가 크다. 기능이 늘어날 때마다 추가 비용이 있어야 한다”라고 말한다. 결국 양측은 다음과 같이 합의한다.
- 기본 기능 10개는 고정가 계약(2억 5천만 원)으로 진행.
- 기능 추가 또는 변경 시에는 “기능 1개당 OO만 원”이라는 단가 계약을 적용.
- 6개월이 지나도 나머지 기능이 계속 들어오면, T&M(Time & Material) 개념으로 별도 협약을 맺어 계속 개발한다.
- 시스템 품질 기준 및 테스트 방식은 계약에 명시, 불합격 시 외주사가 재작업. 단, 요구사항 자체가 변경되면 협의 후 비용 추가.
위 시나리오는 프로젝트 범위, 일정, 비용, 품질을 종합적으로 고려한 ‘혼합형 계약’ 사례다. PMBOK 관점에서는 조달관리 프로세스(계획→수행→통제) 전반에 걸쳐, 각 단계에서 발생할 수 있는 리스크를 미리 분담하는 구조다. 또한 이렇게 만들어진 계약 내용은 프로젝트 관리 툴(예: 지라, 애저 DevOps)에서 작업 범위를 지정할 때마다 참조되며, 수시로 변경 사항을 추적해 계약 조항을 업데이트한다.
결론
협약 및 계약은 프로젝트 관리의 기본 토대를 이루며, 단순히 ‘법적 문서’를 넘어 프로젝트 범위, 일정, 비용, 품질, 리스크, 이해관계자 관리를 한데 엮어주는 중추적 역할을 담당한다. PMBOK에서는 이를 ‘4.6.8 일반적으로 사용되는 결과물’ 가운데 하나로 꼽으며, 조달관리(Procurement Management)를 중심으로 통합관리(Integration Management), 이해관계자관리(Stakeholder Management), 커뮤니케이션관리(Communications Management) 등 다양한 지식 영역과 연계해 다루도록 권고한다.
프로젝트 실무에서는 범위 변동, 납기 지연, 품질 불합격, 비용 초과 등 온갖 문제가 계약 조항과 엮여 발생하기 쉽다. 협약을 제대로 맺으면 이러한 문제들을 사전에 방지하고, 문제가 터지더라도 신속하게 책임 소재와 대안을 결정할 수 있다. 반면 계약을 부실하게 체결하면, 후반부에 예산이 터무니없이 늘어나거나, 의사결정이 지연되어 프로젝트가 무기한 표류하는 사태가 발생하기 쉽다. 따라서 애자일 환경에서든 전통적 폭포수 방식에서든, 프로젝트 관리자와 실무자들은 협약·계약 체결 프로세스를 꼼꼼히 챙기고, 디지털 요구사항 추적 시스템 등을 통해 실시간으로 반영·통제하는 체계를 구축해야 한다.
결국, 협약과 계약은 프로젝트의 방향과 한계를 규정하며, 모든 이해관계자가 같은 규칙 하에서 협력할 수 있게 만든다. 이것이 프로젝트 성공을 위한 든든한 기반이 되는 이유다.