맞춤형 소프트웨어 프로젝트의 가격 협상 시, 갑과 을 양측이 가장 흔히 맞추는 단위는 「인천」입니다: 몇 명의 엔지니어가 몇 일 동안 작업하고, 단가는 얼마인지에 관한 것입니다. 이 모델은 요구사항이 안정적이고, 납품 범위가 명확할 때나 잘 작동합니다; 하지만 현장 규칙이 자주 변경되고, AI 도구가 코딩 효율을 크게 높여도, 발주처가 여전히 「인력 중심」으로 검수를 진행한다면 갈등이 폭발하게 됩니다—乙方은 요구사항이 확대된다고 느끼고,甲方은 「인력은 늘었는데 결과물은 별로 없다」고 생각합니다.
정책 신호: 인력 판매에서 결과물 판매로
2026년 9월, 중국 공업정보화부는 「인공지능+소프트웨어」 특별 행동 계획을 발표했으며, 여기서 소프트웨어 생산 방식의 변화를 촉진하고 「모델 서비스」와 「지능체 서비스」를 발전시키며, 2028년까지 주요 산업 분야에서 지능체 소프트웨어의 선도적 적용 사례를 구축하겠다고 명시했습니다. 문서는 맞춤형 개발을 부정하지 않지만, 하나의 분명한 방향성을 제시합니다: 소프트웨어의 가치를 평가할 때, 점점 더 투입된 인천 수량보다는 실질적인 성과를 중시하게 될 것입니다.
ERP, MES, CRM, 산업 관리 시스템 등을 구축 중인 기업들에게 있어, 이는 계약서에 여전히 「XX명 × XX일」만 기재되어 있다면, 시스템이 도입된 후에도 「코드는 완성됐지만 실제 비즈니스에는 적용되지 않는다」는 식의 책임 다툼에 빠지기 쉽다는 것을 의미합니다. 보다 지속 가능한 방식은 납품을 검증 가능한 비즈니스 결과로 세분화하는 것입니다.
비즈니스 로직: 마일스톤은 인천보다 더 구체적이어야 합니다
프로젝트를 「단계별 결제」에서 「마일스톤별 결제」로 전환하고, 각 마일스톤은 반드시 네 가지 조건을 동시에 충족해야 합니다:
- 비즈니스 시나리오: 누가 사용하며, 어떤 작업을 해결하는지(예: 「창고 직원이 스캔하여 입고」가 아니라 「입고 모듈 완성」).
- 데이터 기준: 어떤 주요 데이터, 상태 필드, 권한 범위가 관련되며, 표본 추출 규칙은 무엇인지.
- 검수 스크립트: 주어진 테스트 데이터를 바탕으로 어떤 프로세스를 거쳐 어떤 문서나 보고서를 생성하는지.
- 예외 처리: 실패 시 시스템이 어떻게 알리고, 누가 수정 권한을 갖고, 기록이 남는지.
마일스톤은 2~4주를 넘지 않는 것이 좋습니다; 너무 길면 다시 「블랙박스 개발」로 돌아가게 됩니다. 전형적인 분할 예시: 주요 데이터 및 권한 → 핵심 문서의 폐쇄 루프 → 보고서 및 대차조정 → 인터페이스 및 시스템 전환.
설계 논리: 범위, 변경 사항 및 「지능형 지원」을 계약서에 명시합니다
AI 기반 코딩 지원, 테스트 케이스 자동 생성, 지능형 문서 보완 등은 동일한 기능을 수행하는 데 필요한 인천 소요 시간을 변화시킬 수 있지만, 비즈니스 복잡도는 자동으로 변하지 않습니다. 계약서와 요구사항 명세서에는 별도 항목으로 명시하는 것이 권장됩니다:
- 범위 기준(Baseline): 기능 목록 + 범위 밖 항목 목록(Out of Scope), 변경 사항은 반드시 변경 요청서를 통해 처리해야 합니다.
- 변경 요금 책정 규칙: 새로운 마일스톤은 「시나리오 + 검수 스크립트」 기준으로 평가하며, 임시로 인천을 추가하는 방식은 아닙니다.
- 지능형 지원 한계: 어느 부분에서 AI를 활용해 효율을 높일 수 있고(코드 생성, 문서 초안 작성), 어느 부분에서는 반드시 사람이 서명해야 하는지(보안, 규정 준수, 대외 약속)를 명확히 합니다.
- 지식 축적 귀속: 과정 문서, 설정, 스크립트는 누가 보유하는지 명확히 하여, 납품 이후 운영 유지를 위한 단절을 방지합니다.
개발 실행: 검수 자동화와 관찰 가능성
「결과 지향」을 실현하기 위해 기술 측에서는 세 가지 사항을 협력해야 합니다:
- 검수용 사례 저장: 각 마일스톤마다 일련의 자동화 또는 반자동화된 사례를 마련하고, 재검증이 반복적으로 가능하도록 합니다.
- 환경 및 데이터 격리: UAT 환경 데이터는 초기화 가능하여, 「데모 환경에서만 통과」하는 문제를 방지합니다.
- 관찰 가능한 로그: 주요 작업에는 감사 로그가 기록되어, 분쟁 발생 시 누가 무엇을 수정했는지 추적할 수 있습니다.
프로젝트에 지능체나 규칙 엔진이 포함된다면, 검수 시 샘플링 검사 메커니즘을 추가해야 합니다: 무작위로 경계 사례를 입력해, 답변 거부, 인력 상향 조정, 권한 차단 등이 설계에 부합하는지 확인하며, 단순히 「채팅 가능」 여부만 따지지 않습니다.
세 가지 일반적인 분쟁과 예방 방법
분쟁 1: 「기능은 다 구현했는데 왜 비즈니스에서는 사용되지 않나요?」—예방: 마일스톤에 직무별 작업과 교육 참석 기록을 연동하고, 검수 시 현장 점검을 실시해 PPT 시연에만 국한되지 않도록 합니다.
분쟁 2: 「작은 요구사항 하나 추가하는데 왜 돈을 더 내야 하나요?」—예방: 변경 요청서에 영향을 미치는 마일스톤, 스크립트, 공사 기간을 명확히 기재하고, 양측이 서명한 후에 개발을 진행합니다.
분쟁 3: 「AI가 효율을 높였는데, 인천은 줄일 수 없나요?」—예방: 계약서에서 「구현 비용」과 「비즈니스 복잡도」를 구분하고, 효율 향상의 이익은 총액이나 기간에 반영하되, 검수 기준은 낮추지 않습니다.
시범 사업 제안: 하나의 폐쇄 루프 모듈부터 시작합니다
전체 시스템을 새로 계약하는 것을 기다릴 필요는 없습니다. 2~3주 만에 폐쇄 루프를 형성할 수 있는 모듈(예: 입출고, 작업 지시서 보고, 경비 승인 등)을 선택하고, 새 템플릿을 이용해 보충 계약을 체결합니다: 시나리오, 스크립트, 예외 사항, 결제 시점 등을 명시합니다. 일단 성공적으로 운영되면 전체 프로젝트로 확대합니다. 성공 여부는 변경 요청서에 따라 분쟁 시간이 줄어들었는지, UAT 1회 통과율이 상승했는지, 그리고 乙方이 인천을 얼마나 적게 보고했는지가 아닌, 전체 프로젝트의 계약 개정이 설득력을 갖는지로 판단합니다. 시범 모듈을 잘 선택하면, 전체 프로젝트의 계약 개정이 더욱 설득력 있게 됩니다.
인천은 하룻밤 사이에 사라지지는 않지만, 이제는 「가격 결정의 유일한 단위」에서 「비용 추산의 참고 자료」로 변화하고 있습니다. 마일스톤과 검수 스크립트를 계약서에 명시하는 것만이, 「인공지능+소프트웨어」 시대에도 맞춤형 소프트웨어가 신뢰할 수 있는 결과물을 납품할 수 있는 기본 역량입니다.
고정 총액 계약과 애자일 반복 개발의 조화
마일스톤 검수는 애자일을 배제하지 않습니다: 각 스프린트마다 시연 가능한 증분을 납품할 수 있지만, 결제와 정식 검수는 더 큰 마일스톤에 연결됩니다. 특히 고정 총액 계약에서는 「범위 동결 시점」을 명확히 기재해야 합니다—어느 심사 이후에 추가 요구사항이 변경 요청서를 통해 처리되는지, 구두로 기능을 추가하는 일이 없도록 해야 합니다. 지능체가 포함된 모듈의 경우, 전체 시스템의 온라인 전환과 별개로, 「규칙 버전 + 샘플링 통과율」을 별도로 검수하는 것을 권장합니다.
산업 데이터에 따르면, 소프트웨어 프로젝트 실패의 약 3분의 1은 요구사항과 검수 기준이 불명확해서 발생하며, 기술적 구현 자체 때문은 아닙니다. 먼저 「무엇이 완성된 것인지」를 계약서에 명시하는 것이, AI가 몇 명의 프로그래머를 대체했는지에 대한 논쟁보다 훨씬 더 가치 있습니다. 다음 번 사업 기획 심사 시, 우선 이렇게 물어볼 수 있습니다: 만약 내일 乙方 전 직원이 휴가를 간다면, 우리는 현재 마일스톤이 기준을 충족하는지 스크립트만으로 판단할 수 있을까요—답변이 어렵다면, 아직 검수가 명확히 정리되지 않았음을 의미합니다. 마일스톤을 계약서에 기재하는 것은 乙方을 어렵게 만들기 위함이 아니라, 양측이 같은 페이지에서 「완성 여부」를 논의하도록 하기 위함입니다. 특히 AI가 효율을 높이는 프로젝트일수록, 이러한 점을 미리 명확히 해야 합니다.