금요일 오후, 발주사 담당자가 메신저로 가볍게 묻습니다. "PM님, 이 통계 화면에 엑셀 다운로드 버튼 하나만 추가하면 안 될까요? 간단하잖아요."
신입 PM A는 "네, 해드릴게요" 하고 개발자에게 넘깁니다. 그런데 그 '버튼 하나'는 집계 쿼리 변경, 권한 체크, 대용량 다운로드 처리, QA까지 사흘이 걸립니다. 다음 주에 또 "캘린더 필터도 하나만…"이 옵니다. 한 달 뒤, 계약 M/M은 그대로인데 일은 1.5배가 됐고, 팀은 야근하며, 회사는 적자입니다. 그런데 발주사는 "원래 해주기로 한 거 아니었나요?"라고 합니다.
선배 PM B는 같은 요청에 이렇게 답합니다. "확인해보니 이 기능은 과업범위(SOW)에 없는 추가 과업입니다. 공수는 약 3 M/M, 일정 영향은 +1주입니다. 비용을 추가하시거나, 기존 범위 중 후순위 항목을 조정하는 방식으로 진행할 수 있는데 어느 쪽으로 합의할까요?" 그리고 이 내용을 변경요청서로 남깁니다.
둘의 차이는 친절함이 아니라 '돈과 책임의 경계'를 문서로 그을 줄 아는가입니다. A는 호의로 회사를 적자에 빠뜨렸고, B는 경계를 지키면서도 길을 열어줬습니다. 이 모듈은 계약·과업범위·M/M·검수 — SI/SM에서 '어디까지가 우리 일이고, 그 대가는 어떻게 정산되는가'를 다룹니다.
- 1도급·위탁·SLA 기반 계약 유형의 차이와, 각 유형에서 책임과 정산이 어떻게 달라지는지 설명할 수 있다
- 2과업범위(SOW)를 기준으로 어떤 요청이 "범위 내"이고 무엇이 "추가 과업"인지 문서로 판단할 수 있다
- 3M/M(투입공수)의 의미를 이해하고, 투입형과 성과형(완료 기준) 정산의 차이를 구분할 수 있다
- 4검수(완료 기준)와 검수확인서가 왜 대금 지급의 기산점인지, SLA 페널티·감점이 어떻게 작동하는지 설명할 수 있다
- 5추가 과업의 비용·일정 영향을 산정해 표로 만들고, 변경계약(변경합의)으로 처리하는 흐름을 설계할 수 있다
계약 유형 — 무엇을 약속하는가에 따라 책임이 달라진다
도급·위탁·SLA 기반 — 약속의 종류가 정산을 결정한다
SI/SM 계약을 읽을 때 가장 먼저 봐야 할 것은 "이 계약이 무엇을 약속하는가"입니다. 약속의 형태에 따라 책임의 무게와 돈을 받는 방식이 완전히 달라지기 때문입니다. 같은 인력이 같은 일을 해도, 계약 유형이 다르면 위험을 누가 떠안는지가 바뀝니다.
크게 세 가지 축으로 봅니다.
| 계약 유형 | 약속하는 것 | 정산 방식 | 위험을 떠안는 쪽 | 흔한 사례 |
|---|---|---|---|---|
| 도급(완성물) | 정해진 결과물의 완성 | 성과형(고정가). 완성·검수 후 지급 | 주로 수행사(못 끝내면 손해) | SI 구축 프로젝트 |
| 위탁(인력·업무) | 인력 투입·업무 수행 | 투입형(M/M 단가 × 투입) | 주로 발주사(완성 여부보다 투입에 지불) | SM 상주 운영, 인력 도급 |
| SLA 기반 | 서비스 수준(가용성·응답) | 기본료 + SLA 달성/미달에 따른 가감 | 양쪽이 수준으로 나눔 | 운영 위탁, MSP |
핵심 구분의 감각:
- 도급은 "완성"을 판다: 결과물이 검수를 통과해야 돈을 받습니다. 중간에 무엇을 얼마나 투입했는지는 상대적으로 덜 중요합니다. 못 끝내면 수행사가 손해를 봅니다.
- 위탁은 "투입"을 판다: 약속한 인력을 약속한 기간 투입하면 대금이 발생합니다. SM(운영) 상주처럼 일이 계속 흘러 '완성'을 정의하기 어려운 경우에 맞습니다.
- SLA 기반은 "수준"을 판다: 단순 투입이 아니라 "가용성 99.9%, 장애 30분 내 대응" 같은 서비스 수준을 약속하고, 그 달성도에 따라 대금이 가감됩니다.
실무에서는 한 계약 안에 이 셋이 섞입니다. 예를 들어 "구축은 도급(고정가), 이후 1년 운영은 SLA 기반 위탁"처럼요. 그래서 "이 계약의 이 항목은 어떤 유형인가" 를 항목 단위로 읽는 습관이 중요합니다.
세 유형은 결국 "무엇을 샀는가" 로 갈립니다 — 도급은 결과물을, 위탁은 사람(노무)을, SLA 기반은 목표 수준을 산 것입니다. 산 것이 다르면 대금이 나오는 순간(검수 통과 / 투입 공수 / 달성률)과 책임의 무게도 달라집니다. 현장 분쟁의 상당수는 이 셋을 한 문장에 뭉뚱그려 약속해 "결과를 책임지는가, 투입만 책임지는가"가 흐려진 데서 생깁니다.
과업범위(SOW) — '우리 일'의 경계선
과업범위(SOW)와 안/밖 판단 — 감정이 아니라 문서로 긋는다
과업범위(SOW, Statement of Work) 는 "이 계약에서 우리가 무엇을, 어디까지 하기로 했는가"를 적은 문서입니다. 어떤 기능·산출물·운영 업무가 포함되는지, 그리고 무엇이 포함되지 않는지(범위 제외, out of scope) 를 명시합니다. SOW는 보통 제안요청서(RFP)·제안서·요구사항정의서와 연결되어 '약속의 총합'을 이룹니다.
과업범위가 중요한 이유는 단순합니다. 여기 적힌 것이 "범위 내(우리 일)"이고, 적히지 않은 새 요구는 "추가 과업" 이기 때문입니다. 이 경계가 흐리면 일은 무한히 늘고(스코프 크리프, scope creep), 대금은 그대로여서 수행사가 적자에 빠집니다.
안/밖을 판단하는 기준은 '버튼이 크냐 작냐'나 '요청자가 누구냐'가 아닙니다. 다음 순서로 문서를 근거로 판단합니다.
- 계약서·SOW·요구사항정의서에 적혀 있는가? — 적혀 있으면 범위 내.
- 적힌 기능의 '정상 범위 내 보완'인가, '새 기능'인가? — 명시된 기능을 정상 동작시키기 위한 보완(버그 수정 등)은 범위 내. 없던 기능을 새로 만드는 것은 추가.
- 범위 제외(out of scope) 항목에 해당하는가? — 명시적으로 제외된 일은 당연히 추가.
- 요구가 기존 합의를 '변경'하는가? — 이미 합의한 사양을 바꾸는 것도 변경(추가) 과업.
판단이 애매할 때의 원칙: "애매하면 문서로 확인하고, 영향이 있으면 영향을 산정해 알린다." 호의로 즉답하지 말고, 경계를 문서로 확인한 뒤 답하는 것이 PM의 기본기입니다.
M/M(투입공수)와 정산 — 무엇으로 돈을 계산하는가
M/M·투입형·성과형 — 공수를 세는 단위와 정산의 두 갈래
M/M(맨먼스, Man-Month) 은 공수(투입 노동량)를 세는 단위입니다. 1 M/M = 1명이 1개월 일하는 분량으로, 표준 근무일(예: 월 20일 안팎)을 기준으로 환산합니다. 5 M/M이면 "1명 5개월" 또는 "5명 1개월"의 분량입니다. 단가(月 단가)에 M/M을 곱하면 인건비 기반 견적이 나옵니다.
M/M은 견적의 언어이자 정산의 언어입니다. 다만 정산 방식이 두 갈래로 갈립니다.
| 구분 | 투입형(인력 투입 기반) | 성과형(완료 기준) |
|---|---|---|
| 대금 기준 | 실제 투입한 인력·기간(M/M) | 정해진 산출물의 완성·검수 |
| "무엇을 파는가" | 시간·인력(투입) | 결과물(완성) |
| 위험 부담 | 발주사(완성과 무관히 투입에 지불) | 수행사(못 끝내면 못 받음) |
| 잘 맞는 경우 | SM 상주 운영, 업무가 계속 흐름 | SI 구축, 완성물이 명확 |
| 추가 과업 처리 | 추가 M/M 투입 → 추가 정산 | 추가 산출물 → 변경계약·추가 비용 |
여기서 추가 과업과 정산이 연결됩니다.
- 투입형에서 추가 과업은 비교적 단순합니다. 추가로 필요한 M/M을 산정해 투입을 늘리고, 그만큼 정산합니다. 다만 "추가 M/M에 대한 사전 승인"이 없으면 나중에 정산 분쟁이 납니다.
- 성과형(고정가) 에서 추가 과업은 더 민감합니다. 고정가는 '정해진 범위를 정해진 돈에' 약속한 것이므로, 범위가 늘면 그 자체로 계약 전제가 깨집니다. 그래서 반드시 변경 절차(비용·일정 재산정 → 변경계약)로 처리해야 하며, 그냥 받아주면 추가 비용을 못 받고 손해를 봅니다.
요약하면: M/M은 일의 크기를 재는 자, 투입형/성과형은 그 자로 잰 일을 돈으로 바꾸는 두 가지 환율입니다.
검수와 SLA 페널티 — 돈을 받는 순간과 깎이는 순간
검수(완료 승인)·검수확인서·SLA 감점 — 대금의 트리거와 패널티
검수(완료 승인) 는 "약속한 산출물이 기준을 충족했음을 발주사가 공식적으로 인정"하는 절차입니다. 검수를 통과하면 발주사는 검수확인서(검수조서·완료확인서)에 서명하고, 이 문서가 대개 대금 청구·지급의 기산점(트리거) 이 됩니다. 즉 "일을 끝냈다"가 아니라 "발주사가 끝났다고 인정했다"가 돈의 출발점입니다.
이 때문에 검수는 SI/SM에서 가장 분쟁이 잦은 지점입니다. 잘 관리하는 방법은:
- 완료 정의(검수 기준)를 계약 단계에서 구체화한다. "잘 동작하면 검수"가 아니라 "산출물 목록 + 각 항목의 검수 기준(기능 충족·문서 제출·테스트 통과)"을 미리 합의합니다. 기준이 모호하면 발주사는 끝없이 보완을 요구할 수 있습니다.
- 검수 요청과 결과를 문서로 남긴다. 언제 검수를 요청했고, 무엇이 지적됐고, 언제 보완·재검수했는지를 기록합니다.
- 간주검수 조항을 둔다. "검수 요청 후 N일 내 발주사가 사유 통보 없이 검수하지 않으면 검수 완료로 간주" 같은 조항으로, 검수 무한 지연 리스크를 줄입니다.
SLA 페널티(감점) 는 검수와 별개로, 주로 운영(SM)·SLA 기반 계약에서 작동합니다. 약속한 서비스 수준(가용성·응답시간·장애 대응시간)을 못 지키면 약정한 만큼 대금이 감액됩니다. 예: "가용성 99.9% 미달 시 구간별 감액", "장애 대응시간 초과 건당 감점". 반대로 일부 계약은 초과 달성에 인센티브를 두기도 합니다.
관리자에게 중요한 감각은 이것입니다. 검수는 "받을 돈의 시작점"이고, SLA 페널티는 "받을 돈을 깎는 장치" 입니다. 둘 다 '잘했다'는 주관이 아니라 사전에 합의한 기준(완료 정의·SLA 지표) 으로 작동하므로, 그 기준을 계약 단계에서 명확히 잡는 것이 분쟁을 예방하는 최선입니다.
그림: SOW가 "우리 일"의 경계를 긋고, M/M이 돈으로 환산하며, 검수확인서가 대금을 열고 SLA 페널티가 깎는다.
직접 해보기 — 추가 과업 영향 산정과 변경 처리
당신은 어느 SI 구축(성과형 고정가) 프로젝트의 PM입니다. 계약 SOW에는 "주문 관리 화면, 통계 대시보드(기본 3종 차트), 사용자 권한 관리"가 명시되어 있고, "외부 시스템 연동·모바일 앱"은 범위 제외로 적혀 있습니다. 아래 4건을 (1) 범위 내/추가 과업으로 판단하고, (2) 추가 과업이면 대략의 공수(M/M) 와 일정 영향을 산정해 표로 만들어 보세요. 정답 감각은 ObserveBlock에 있습니다.
가. "통계 대시보드 차트가 데이터가 많으면 깨져요. 고쳐주세요." (이미 만든 기본 3종 차트의 버그)
나. "통계 화면에 엑셀 다운로드 버튼을 추가해 주세요." (집계·권한·대용량 처리 포함, SOW에 없음)
다. "외부 ERP와 주문 데이터를 실시간 연동해 주세요." (계약서 범위 제외 항목)
라. "권한 관리 화면 색상을 회사 브랜드 색으로 바꿔주세요." (이미 만든 화면의 사소한 스타일)
산정 감각: 추가 과업은 (개발 + 테스트 + 검수 반영) 까지 포함해 공수를 보고, 일정은 '현재 일정에 끼워넣을 때 다른 작업을 얼마나 미루는가'로 봅니다. "버튼 하나"처럼 작아 보여도 권한·대용량·QA가 붙으면 공수가 커집니다.
판단: 범위 내 / 추가 과업 → 추가면 M/M·일정 영향 산정- 가 = 범위 내. SOW에 있는 기본 3종 차트를 정상 동작시키는 보완(버그 수정)이므로 추가 비용 대상 아님. 단, 기록은 남긴다
- 나 = 추가 과업. SOW에 없는 새 기능. 예시 산정: 개발 1.5 M/M + 테스트·검수 반영 0.5 M/M = 약 2 M/M, 일정 영향 +1주(다른 후순위 작업 1건 지연). 변경요청서로 합의 필요
- 다 = 추가 과업(범위 제외 명시). 외부 ERP 실시간 연동은 별도 사안. 예시 산정: 연동 설계·개발·테스트 포함 약 4~5 M/M, 일정 +3주 이상. 별도 변경계약 강력 권장
- 라 = 범위 내(또는 무상 경미 조정). 이미 만든 화면의 사소한 스타일 변경으로 통상 미미한 공수. 다만 "사소함"이 반복되면 누적 관리하고 패턴화되면 변경으로 전환
- 핵심 감각 1: 같은 "추가해줘"라도 SOW 기준 안/밖이 다르고, 안/밖이 같아도 공수·일정 영향이 다르다
- 핵심 감각 2: 추가 과업은 비용·일정을 "산정해 보여주고" 발주사가 (비용추가/일정연장/범위조정) 중 선택하게 한 뒤, 그 합의를 변경요청서·변경계약으로 문서화한다
현장에서 자주 보는 함정
증상: 발주사와 관계가 좋아 "버튼 하나", "필터 하나", "이것도 잠깐만" 같은 작은 요청을 PM이 그때그때 흔쾌히 받아줍니다. 개별로는 작아 보입니다. 그런데 두세 달 뒤, 계약상 투입 M/M·대금은 그대로인데 실제 일은 1.5배가 되어 팀은 야근하고 회사는 적자입니다. 더 나쁜 건, 그동안 다 받아줬기에 발주사는 그게 원래 범위라고 인식한다는 점입니다.
원인: 과업 안/밖의 경계를 문서로 긋지 않고 호의로 응답했습니다. 작은 요청도 추가 과업이면 (1) SOW 기준 안/밖을 확인하고 (2) 비용·일정 영향을 산정해 알리고 (3) 합의를 기록해야 하는데, 이 세 단계를 건너뛰면 추가 과업이 '공짜 누적'됩니다. 이것이 스코프 크리프(scope creep)입니다. 호의 자체가 문제가 아니라, 경계 없는 호의가 회사를 위험에 빠뜨리는 것입니다.
해결 방향:
- 모든 추가 요청을 변경요청 채널 하나로 받는다. 메신저 즉답이 아니라 "확인 후 영향과 함께 회신"을 기본 응답으로 만든다.
- 추가 과업이면 비용·일정 영향을 표로 산정해 보여주고, 발주사가 (비용추가/일정연장/범위조정) 중 고르게 한다 — 거절도, 무조건 수용도 아닌 '선택지 제시'.
- 합의를 변경요청서·변경계약(또는 변경합의) 으로 문서화한다. 누적분은 주기적으로(예: 주간 보고) 가시화해 "지금까지 추가된 범위"를 발주사와 공유한다.
- 경미한 무상 조정도 누적 기록해 패턴이 보이면 변경으로 전환한다. "작아서 그냥 해드린 것"이 쌓이면 결국 큰 적자다.
스코프 관리는 발주사와 싸우는 일이 아니라, 경계를 명확히 해서 양쪽이 같은 그림을 보게 만드는 일입니다. 경계가 분명할수록 오히려 신뢰가 쌓입니다.
이 모듈의 내용은 발주사 IT 담당, 원청·협력사의 PM/PMO, SI 사업관리, SM 운영관리자가 매일 쓰는 언어입니다. 한국 SI/SM 현장에서 가장 자주 듣는 한마디가 바로 "이거 과업범위 안인가요?"입니다.
이 질문에 신입은 감(感)이나 분위기로 답하고, 숙련된 관리자는 계약서·SOW·요구사항정의서를 펴서 문서로 답합니다. 그리고 추가 과업이라면 "안 됩니다"로 끝내지 않고, 비용·일정 영향을 산정한 표를 들고 가 발주사가 선택할 수 있게 만듭니다. 이 차이가 프로젝트의 손익과 팀의 야근, 그리고 발주사와의 신뢰를 가릅니다.
당신이 직접 코드를 짜지 않더라도, 협력사 엔지니어가 "이건 추가 작업인데요"라고 할 때 그 말이 맞는지 SOW로 검증하고, 발주사에게는 "이건 범위 밖이라 변경 처리가 필요합니다"를 근거와 함께 설득하는 것이 관리자의 핵심 역량입니다. 계약 유형(도급/위탁/SLA)을 읽을 줄 알면 어떤 위험을 누가 지는지 보이고, M/M을 읽을 줄 알면 견적과 정산에 속지 않으며, 검수·SLA 조항을 읽을 줄 알면 '언제 돈이 들어오고 언제 깎이는지'를 통제할 수 있습니다. 기술을 아는 관리자가 계약까지 읽으면, 협력사와도 발주사와도 대등하게 대화할 수 있습니다.
관련 모듈로 더 깊이:
- SM 운영·유지보수·하자보수 — 이 계약·과업범위가 운영(SM)의 하자/유상 판정으로 실제 쓰이는 현장
- 공공 정보화사업과 감리 — 공공사업에서 계약·검수가 감리·검사 절차로 어떻게 통제되는지
- PMO 운영과 벤더 관리 — 복수 벤더의 범위·책임 경계를 PMO가 통합 관리하는 법
다음 모듈에서는 한국 공공 정보화사업의 특수성 — 발주·제안·계약의 공공 절차와, 사업 품질을 제3자가 점검하는 감리(監理) 제도가 SI/SM 수행사에게 어떤 의무와 통제를 부과하는지를 다룹니다.