[PM온보딩] 프로젝트 시작 전 : 계약서 검토

by 양지은

May 5. 2025

Chapter 1 프로젝트는 이미 시작되었다.

계약 전의 계약서 검토는 왜 중요한가요?

프로젝트는 계약서에 사인하는 순간 시작되는 것이 아닌, 체결되기 전부터 이미 시작되었다고 볼 수 있습니다.

영업팀은 고객과 구체적인 범위 조율을 마칩니다.

견적은 산출되고, 기능정의서의 초안이 전달됩니다.

리소스가 요청되고, ‘사전 배정’을 진행합니다.

이 시점에 PM이 참여하지 않는다면, 프로젝트가 본격적으로 착수되기 전에 잘못된 방향으로 흘러가게 될 수 있습니다.

PM이 계약서를 검토해야 하는 이유

리소스 산정이 실제 필요와 다를 수 있습니다.

기능정의서가 너무 모호하거나 빠진 내용이 많을 수 있습니다.

클라이언트가 요청하는 기술 스택이 조직과 맞지 않을 수 있습니다.

산출물 정의가 없어 QA와 납품 시점에 혼란이 발생할 수 있습니다.

이러한 리스크는 계약 전 단계에서 PM이 부재할 때 발생할 확률이 높습니다.
계약 전부터 PM이 참여하여 계약서를 검토하고 위험요소를 식별하는 것이 추후 발생될 리스크를 줄일 수 있습니다.

영업팀에서 프로젝트 정보를 전달하는 시점

계약이 확정되지는 않았지만,
계약 가능성이 높다고 판단되면 영업팀은 아래와 같은 자료를 전달합니다.

✔️ 프로젝트 견적서

✔️ 계약서(초안 또는 Draft)

✔️ 기능정의서 (초안 또는 Draft)

✔️ 프로젝트 개요 및 특이사항

또한, 견적서를 기반으로 리소스도 함께 요청합니다.
예:

"DE 1, FE 1, BE 1, PM 1"

각 팀 리더는 이에 따라 가능한 인력을 확인하여 배정합니다.

예:

“해당 프로젝트의 디자이너는 지연님, 프론트엔드 개발자 민재님, 백엔드 개발자 태윤님, PM은 지은님으로 배정하겠습니다.”

PM이 자료를 받으면 가장 먼저 보는 것

배정된 PM은 위 자료들을 토대로 정합성과 리스크가 될 만한 사항들을 검토해야 합니다.

계약서 검토 체크포인트

1. 계약기간

시작일과 종료일은 실제 일정과 동일한가?

착수일과 납품일의 일정은 충분한가?

우리에게 주어진 기간 대비 리소스 견적과 기능은 적합한가?

2. 하자보수 기간 및 범위

하자보수의 종료 시점은 명시되어 있는가?

하자보수는 무상인가 유상인가?

하자보수의 기준은?

3. 프로젝트 형태

웹인지 앱인지, 혹은 웹앱인가?

웹이라면 반응형인가, 적응형인가?

반응형이라면 브레이크포인트는 몇 개인가? | 브레이크포인트가 누락된 계약서는 해석의 여지가 발생할 수 있습니다.

앱이라면 어떤 플랫폼을 대상으로 하는가? iOS / Android?

네이티브 개발인지 패키징인지? 앱 심사와 출시까지 포함된 프로젝트인가?

4. 테스트 기준

어떤 디바이스에서 테스트할 것인가?

어떤 브라우저, 어떤 버전까지 지원 대상인가?

5. 개발 스택

기술 스택은 고정인가 협의인가?

우리 조직의 기술력과 일치하는가?

“클라이언트가 준비”라는 표현에 주의합니다. (예를 들어, 클라이언트 측에서 백엔드 API 문서를 제공하기로 했다면, 이미 API 개발이 완료되어 프로젝트 착수 시점에 API 명세서를 바로 받을 수 있는지, 프로젝트 진행에 차질이 생기지는 않을지 등을 미리 고려해야 합니다.)

6. 최종 산출물

어떤 항목들을 어떤 형태로 제출해야 하는가?

산출물에 대한 검수 기준과 방법은 명시되어 있는가?

7. 지급 조건

선금, 중도금, 잔금의 기준과 지급 조건은?

계약서 내의 한 줄이 프로젝트의 방향을 바꿉니다.

계약서 내의 단 한 줄이 프로젝트 전체 일정을 바꾸거나 인력 배정을 다시 짜게 만들기도 합니다.

사례 1. 리소스 산정 오류, 일정으로 재조율 진행

견적서에서 리소스 산정 오류 발견 → 인력 추가 없이 일정으로 재조율

견적서에는 프론트엔드 개발자 1명이 100%로 2개월 투입으로 되어 있었지만,
기능정의서를 확인해 보니 사용자 권한, 외부 API 연동 등 예상보다 높은 난이도의 기능이 포함되어 있었습니다.
PM은 바로 개발팀과 협의하여 인력은 그대로 두되 기능을 단계별로 배포하는 일정으로 제안하여 클라이언트를 설득하였습니다.

사례 2. 계약서의 한 줄이 테스트 지옥을 만들 수 있어요.

“테스트는 iOS 최신 버전 기준으로 진행” → QA 인력과 디바이스 이슈 발생

계약서에 'iOS 최신 버전 기준으로 테스트 진행'이라는 문장이 있었습니다.
하지만 실제로는 클라이언트 측에서 iOS 13 이하의 사용자를 고려해야 한다는 요구사항이 뒤늦게 나왔고,
테스트 대상 디바이스가 추가되면서 QA 인력 충원 및 장비 대여가 필요해졌습니다.
PM은 테스트 범위를 재조율하고 공식 지원 버전을 규정한 변경계약서를 따로 체결함으로써 상황을 수습했습니다.

⚠️ “최신”이라는 단어는 기준이 아닙니다. 범위를 명확히 해야 리스크를 줄일 수 있습니다.

사례 3. 기능정의서의 '미정'을 주의하세요.

‘미정’으로 남아있던 관리자 기능 → 개발 소요 2주 예상, PM이 조율 요청

기능정의서에서 '관리자 기능' 항목에 대해 "상세한 내용은 추후 협의"로 표기되어 있었습니다.
PM이 클라이언트와 커뮤니케이션을 진행해 보니, 게시물 관리, 로그 확인 등의 기능을 기대하고 있었고, 개발팀과 협의한 결과 약 2주 이상의 추가 개발이 필요하다는 판단이 내려졌습니다.
PM은 해당 기능을 1차 개발 범위에서 제외하고, 별도 계약으로 분리해 프로젝트 일정에 미치는 영향을 최소화했습니다.

사례 4. 프론트만 요청한 프로젝트에 백엔드 기능이?

프론트엔드만 투입되기로 한 프로젝트의 기능정의서에 공지사항 관리 기능 확인 → 백엔드 인력 추가 견적 요청

기존 견적서에는 프론트엔드 개발자만 투입되어 있었지만, 기능정의서에 공지사항 게시판 생성, 수정, 삭제 기능이 포함되어 있었습니다.
클라이언트는 백오피스 시스템을 당연히 포함된 것으로 이해하고 있었고, API는 전혀 준비되어 있지 않았습니다.
PM은 해당 내용을 확인한 후 백엔드 인력을 추가 투입하는 방향으로 견적서를 재작성하고, 클라이언트에게 해당 변경 내용을 안내했습니다.