요구사항이 덜 확정됐는데 고정가로 묶으면 생기는 일: 발주 방식을 가르는 기준

"견적 하나로 끝"이 끌리는 이유, 그리고 함정

외주 개발을 처음 맡기는 발주사일수록 고정가 계약을 선호합니다. 금액이 처음부터 정해져 있으니 예산을 통제하기 쉽고, 책임 소재도 명확해 보이기 때문입니다. 실제로 범위가 분명한 프로젝트라면 고정가는 합리적인 선택입니다. 문제는 요구사항이 아직 덜 확정된 상태에서 금액부터 묶을 때 생깁니다.

고정가는 '합의된 범위'를 전제로 가격이 정해집니다. 그런데 화면 설계도, 연동할 외부 시스템도, 사용자 시나리오도 확정되지 않은 단계에서 금액을 고정하면, 개발사는 불확실성을 가격에 미리 얹거나(비싸짐) 범위를 좁게 해석해 방어하게 됩니다(부실해짐). 그 사이에서 발주사가 "이건 당연히 포함 아니냐"라고 말하는 순간부터 추가 비용 협상과 책임 공방이 시작됩니다. 싸고 안전해 보이던 계약이 가장 많은 분쟁을 만드는 구조입니다.

공공은 왜 '투입인력 관리'를 금지했나

이 문제를 가장 오래 겪은 발주처가 공공입니다. 그 경험이 제도로 남아 있어, 민간 발주사가 참고하기 좋습니다.

과학기술정보통신부 고시 「소프트웨어사업 관리감독에 관한 일반기준」(제7조제3항·제9조제3항)은, 사업대가를 기능점수(FP) 방식으로 산정한 공공 SW사업에 대해 발주자가 제안요청서에서 투입인력의 수·인적사항·투입기간을 요구하거나 이를 관리할 수 없도록 정하고 있습니다. 흔히 말하는 '헤드카운트 관리 금지', '상주인력 관리 금지' 원칙입니다.

핵심은 "몇 명이 몇 달 붙었는가"가 아니라 "무엇을 만들어 넘겼는가"로 계약을 관리하라는 것입니다. 사람 수를 세기 시작하면 발주사는 관리 업무가 늘고, 개발사는 결과물이 아니라 출근을 증명하는 데 힘을 쓰게 됩니다. 과업과 성과 중심으로 관리해야 양쪽 모두 만들어야 할 것에 집중한다는 판단이 깔려 있습니다.

대가 산정 방식도 성격별로 나눕니다. 한국인공지능소프트웨어산업협회(KOSA) 「SW사업 대가산정 가이드」 2025년 개정판(2025년 8월 11일 공표)은 개발비는 기능점수(FP) 방식으로, 운영·유지관리비는 투입공수(MM) 방식으로 각각 산정한 뒤 합산하도록 안내합니다. 또한 이번 개정에서는 AI 도입사업의 대가산정 항목 명칭을 기존 '전문작업비'에서 '커스터마이징 작업비용'으로 바꾸고 유형별 작업 항목을 구체화했으며, SW개발과 운영을 통합한 데브옵스형 사업에 대한 별도 대가산정 기준을 신설했습니다.

여기서 민간이 가져갈 교훈은 한 가지입니다. '만들어 내는 일'과 '유지하는 일'은 성격이 다르므로 계약 방식도 달라야 한다는 것. 범위가 떨어지는 신규 개발을 사람 수와 기간으로만 묶으려 하거나, 반대로 끝없이 변하는 운영을 고정가로 틀어막으려 할 때 탈이 납니다.

프로젝트 성격별로 방식을 고르는 기준

발주사 입장에서 실무에 바로 쓸 수 있도록 세 가지로 정리하면 다음과 같습니다.

• 고정가가 맞는 경우: 요구사항과 산출물이 문서로 확정돼 있고, 범위 변경 가능성이 낮은 프로젝트. 예를 들어 디자인 시안이 확정된 회사 홈페이지, 기능 명세가 분명한 단일 연동 작업이 여기에 해당합니다.
• 투입공수(MM)가 맞는 경우: 방향은 있으나 세부가 계속 바뀌는 일. 출시 후 운영·유지관리, 지속적인 기능 개선, 사용자 반응을 보며 범위를 조정해야 하는 서비스가 대표적입니다.
• 혼합형이 맞는 경우: 신규 개발이지만 요구사항이 아직 덜 여문 경우. 초기 분석·설계·화면 정의 단계는 별도 계약(또는 소규모 투입공수)으로 끊어 범위를 확정한 뒤, 확정된 범위에 대해서만 고정가로 본개발을 계약하는 방식입니다. MVP나 신규 서비스처럼 불확실성이 큰 프로젝트에서 분쟁을 가장 많이 줄여 줍니다.

계약·검수에 반영할 체크리스트

• 범위를 확정하는 단계를 먼저 계약하세요. 설계가 끝나기 전에 전체 금액부터 고정하지 않습니다. 분석·설계 산출물을 받아 본 뒤 본개발 범위를 확정합니다.
• 검수 기준을 '사람'이 아니라 '산출물'로 적으세요. 투입 인원·상주 여부가 아니라, 어떤 기능이 어떤 조건에서 동작하면 완료인지를 계약서와 검수 조건에 명시합니다.
• 변경 관리 절차를 계약서에 넣으세요. 범위 변경이 생길 때 어떻게 추가 산정하고 승인하는지를 미리 정해 두면, 변경 자체가 분쟁이 되지 않습니다.
• 운영·유지관리는 별도 조건으로 분리하세요. 개발과 운영을 한 금액에 섞으면 책임 범위가 흐려집니다.

마무리: 계약 방식은 '불확실성을 누가, 어떻게 나눌지'의 문제

고정가냐 투입공수냐는 단순히 가격을 정하는 방법이 아니라, 요구사항 불확실성이라는 위험을 발주사와 개발사가 어떻게 나눌지를 정하는 일입니다. 범위가 분명하면 고정가로 위험을 개발사에 넘기는 것이 합리적이고, 범위가 흐릿하면 그 흐림을 함께 걷어 내는 단계부터 설계하는 편이 결국 더 저렴합니다.

FIRSTPIP은 발주사의 프로젝트 성격과 요구사항 성숙도를 먼저 진단한 뒤, 분석·설계부터 본개발·운영까지 어떤 계약 방식으로 끊어 갈지를 함께 설계해 드립니다. 요구사항이 아직 덜 정리된 상태라도 괜찮습니다. 범위를 확정하는 단계부터 상담받고 싶으시면 SI·시스템 구축 서비스를 통해 문의해 주세요.