요구사항은 반드시 바뀐다: 공공이 과업심의위를 의무화한 지금, 민간 발주사가 계약에 넣어야 할 변경관리 장치

과업 변경은 사고가 아니라 프로젝트의 기본값입니다

외주 개발 프로젝트에서 가장 흔하게 반복되는 갈등은 품질 그 자체가 아니라 "이게 원래 범위였나"를 둘러싼 다툼입니다. 착수 시점에 아무리 꼼꼼히 요구사항을 정의해도, 시장 상황이 바뀌고 이해관계자의 생각이 정리되면서 요구사항은 반드시 움직입니다. 문제는 이 변화를 예외적 사고로 취급하느냐, 처음부터 상수로 놓고 관리 장치를 계약에 넣느냐입니다.

이 변화가 예외가 아니라는 점은 데이터로도 드러납니다. PMI의 Pulse of the Profession 2018에 따르면 지난 12개월간 완료된 프로젝트의 절반가량이 통제되지 않은 범위 변경, 즉 스코프 크리프를 겪었고, 이는 5년 전보다 뚜렷하게 오른 수치입니다. 절반에 가까운 프로젝트가 겪는 일이라면 그것은 리스크가 아니라 관리해야 할 상태입니다.

공공은 이 상수를 제도로 인정했습니다

2026년 7월 23일 국회 본회의를 통과한 소프트웨어진흥법 개정안은 이 문제를 정면으로 다뤘습니다. 그동안 발주기관 재량에 맡겨졌던 과업심의위원회 개최가 원칙적으로 의무가 됐고, 국가기관 등의 장은 심의 결과를 계약에 반영하는 데 그치지 않고 그에 필요한 재원(예산)까지 확보하도록 의무를 지게 됐습니다.

핵심은 두 가지입니다. 첫째, 과업이 바뀔 수 있다는 전제를 제도가 공식적으로 인정했습니다. 둘째, 변경을 인정하는 데서 멈추지 않고 추가 대가를 지급할 재원까지 미리 확보하도록 했습니다. 변경은 일어나고, 일어난 만큼 정산한다는 원칙을 공공이 강제 규정으로 옮긴 셈입니다.

민간 발주 프로젝트에는 이런 강제 장치가 없습니다. 과업심의위도, 예산 확보 의무도 없기 때문에 변경 요청이 들어오면 그 부담은 협상력이 약한 쪽으로 쏠리고, 결국 지연, 분쟁, 품질 저하로 이어집니다. 공공이 법으로 만든 안전장치를 민간은 계약서로 직접 설계해야 한다는 뜻입니다.

발주사 PM이 계약과 기준선에 미리 박아야 할 것

변경관리는 착수 후에 대응하는 프로세스가 아니라, 계약서에 조항으로 먼저 존재해야 합니다. 발주사 PM 관점에서 준비해야 할 항목을 정리했습니다.

1. 요구사항 기준선을 문서로 고정합니다

• 기준선(baseline) 명시: 계약 부속서로 요구사항 정의서, 화면 목록, 기능 목록을 첨부하고 "이 문서가 범위의 기준"임을 계약 본문에 적습니다. 무엇이 범위 안인지 정의돼 있어야 무엇이 밖인지 판단할 수 있습니다.
• 가정과 제외 항목 기재: 포함되는 기능만큼 제외되는 항목(예: 특정 외부 시스템 연동, 데이터 이관 범위)을 함께 적어 회색지대를 줄입니다.

2. 변경관리 절차를 조항으로 만듭니다

• 변경요청서(CR) 양식과 흐름: 변경 요청은 구두가 아니라 문서로 접수하고, 영향분석(일정, 공수, 비용) 후 양측 서명으로 확정하는 절차를 계약에 넣습니다.
• 의사결정 창구 단일화: 발주사와 수행사 양쪽에 변경 승인 권한자를 지정합니다. 실무자가 흘리듯 요청한 기능이 범위로 굳어지는 일을 막는 장치입니다.
• 경미한 변경과 중대한 변경의 구분 기준: 일정과 대가에 영향을 주지 않는 소소한 조정과, 추가 정산이 필요한 변경을 나누는 기준을 미리 합의합니다.

3. 추가 대가 정산 방식을 미리 정합니다

• 산정 기준 사전 합의: 변경이 확정된 뒤 단가를 협상하면 늦습니다. 기능점수(FP) 단가나 인월 단가를 계약 시점에 표로 붙여 둡니다. 참고로 KOSA의 SW사업 대가산정 가이드 2024년 개정판(2024년 5월 13일 공표)은 기능점수당 단가를 기존 553,114원에서 605,784원으로 상향했습니다. 민간 계약에서 그대로 쓸 의무는 없지만, 양측이 납득할 만한 객관적 기준선으로 활용할 수 있습니다.
• 범위가 유동적인 작업은 투입공수형으로 분리: 같은 개정판은 AI 도입사업 대가체계를 처음 공개하며, 데이터 수집·전처리, 학습, 테스트·검증처럼 범위가 유동적인 작업은 고정 기능점수가 아니라 투입공수방식의 전문작업비로 별도 산정하도록 제시했습니다. 요구사항이 확정되지 않은 영역을 고정가로 묶으면 분쟁이 생깁니다. 확정 가능한 부분은 고정가로, 불확실한 부분은 투입공수형으로 나누는 이중 구조가 현실적입니다.

4. 변경을 흡수할 여유를 처음부터 예산에 넣습니다

• 변경 대비 예비비: 공공이 예산 확보를 의무화한 취지를 민간이 자발적으로 가져오는 방법입니다. 전체 예산에 변경 대응용 예비 항목을 두면, 변경이 생길 때마다 새 품의를 올리느라 프로젝트가 멈추는 상황을 줄일 수 있습니다.
• 일정 버퍼 명시: 마일스톤 사이에 변경 흡수용 기간을 배치해 두면 작은 변경이 곧바로 납기 지연으로 번지지 않습니다.

정리: 변경을 막지 말고, 관리되게 만드십시오

스코프 크리프의 반대말은 "변경 없는 프로젝트"가 아닙니다. 그런 프로젝트는 현실에 거의 없습니다. 반대말은 "변경이 문서로 접수되고, 영향이 분석되고, 대가가 정산되는 프로젝트"입니다. 공공은 이 원칙을 법으로 강제했지만, 민간 발주사는 계약서와 요구사항 기준선을 통해 스스로 같은 장치를 갖춰야 합니다.

FIRSTPIP은 외주 개발 프로젝트를 수행할 때 요구사항 기준선과 변경관리 절차를 착수 단계에서 함께 설계합니다. 변경 자체를 없애려 하기보다, 변경이 생겨도 일정과 비용과 품질이 예측 가능하도록 계약과 프로세스를 먼저 맞추는 것이 지연과 분쟁을 줄이는 현실적인 길이라고 봅니다. 지금 준비 중인 발주 프로젝트가 있다면, 위 체크리스트를 계약서 초안과 나란히 놓고 하나씩 점검해 보시길 권합니다.