외주 예산이 중반에 무너지는 진짜 이유, '스코프 크립'을 막지 말고 관리하세요

킥오프 때 맞춘 예산은 왜 중반부터 흔들릴까요

많은 발주사가 착수 시점에는 예산과 일정에 자신 있어 합니다. 견적서에 금액이 적혀 있고, 일정표에 마일스톤이 찍혀 있으니까요. 그런데 개발이 절반쯤 진행되는 시점부터 이상하게 숫자가 어긋나기 시작합니다. Gitnux가 정리한 2026년 소프트웨어 개발 예산 통계에 따르면 소프트웨어 프로젝트의 약 70%가 초기 예산을 초과하고, 평균 초과율은 27%에 달합니다. 결코 예외적인 사고가 아니라, 오히려 기본값에 가깝다는 뜻입니다.

원인을 '개발사의 실력 부족'으로만 돌리면 진짜 문제를 놓칩니다. 국내 IT 아웃소싱 실패의 3대 원인으로는 요구사항 불명확·소통 부재·기술 역량 미검증이 꼽히는데, 그중 요구사항 불명확이 1순위입니다. 초기에 흐릿하게 합의한 범위가 진행 중에 계속 구체화·확장되면서 예산과 일정을 잠식하는 것, 이것이 바로 '스코프 크립(scope creep)'입니다.

스코프 크립의 무서운 점은 큰 결정이 아니라 작은 요청의 누적이라는 데 있습니다. "이 버튼 하나만", "이 화면에 항목 몇 개만 추가", "이왕이면 관리자 기능도 조금만" 같은 요청은 개별적으로 보면 사소합니다. 하지만 Gitnux의 2026년 아웃소싱 통계는 아웃소싱에서 스코프 크립이 예산을 20~30% 초과시키고, 여기에 숨은 수수료가 총액을 다시 15~25% 끌어올린다고 지적합니다. 국내 외주 현장에서도 초기 계약 범위 밖 요구가 쌓이면 최종 비용이 처음 견적의 2~3배가 되는 사례가 드물지 않습니다.

변경을 '막는' 게 아니라 '관리'해야 하는 이유

여기서 흔한 오해가 하나 있습니다. 스코프 크립을 막으려면 변경 요청을 무조건 거절해야 한다는 생각입니다. 그러나 현실의 프로젝트에서 변경은 자연스러운 일입니다. 시장이 움직이고, 사용자 피드백이 들어오고, 대표의 판단이 바뀝니다. 변경을 원천 차단하면 오히려 완성도 낮은 결과물이 나오거나, 공식 절차를 우회한 '몰래 요청'이 늘어 프로젝트가 더 통제 불능이 됩니다.

성공하는 프로젝트가 다른 지점은 범위를 다루는 방식에 있습니다. Asana의 범위 관리 자료나 국내 외주 가이드가 공통으로 강조하듯, 잘 굴러가는 프로젝트는 범위를 '고정된 기능 리스트'가 아니라 '반드시 지킬 핵심 범위'와 '상황에 따라 조정 가능한 영역'으로 구분해 관리합니다. 핵심 범위는 이 프로젝트가 존재하는 이유이자 예산의 근거이므로 함부로 흔들지 않습니다. 반면 조정 가능 영역은 우선순위를 두고 유연하게 넣고 뺄 수 있게 열어 둡니다.

즉 목표는 변경을 없애는 게 아니라, 모든 변경이 비용과 일정에 미치는 영향을 눈에 보이게 만드는 것입니다. 영향이 보이면 발주사도 냉정하게 판단할 수 있습니다. "이 기능을 지금 넣으면 2주가 밀리고 예산이 늘어난다"는 사실을 알면, 정말 필요한지 다시 저울질하게 되니까요.

실전 변경관리 룰: 접수 → 재산정 → 승인

SI 파트너로서 저희가 권하는 변경관리 룰은 단순합니다. 복잡한 절차가 아니라, 모든 변경이 반드시 거치는 하나의 통로를 만드는 것입니다.

• 구분: 킥오프 시점에 요구사항을 '핵심 범위'와 '조정 가능 영역'으로 나눠 문서화합니다. 무엇이 흔들리면 안 되는지 양측이 같은 그림을 공유합니다.
• 접수: 모든 변경 요청은 구두·메신저가 아니라 정해진 양식(변경요청서, CR)으로 접수합니다. 요청자, 요청 내용, 이유, 희망 시점을 남깁니다.
• 재산정: 접수된 변경에 대해 개발사가 추가 공수·비용·일정 영향을 산정해 회신합니다. '무료로 되는지'가 아니라 '얼마의 대가가 드는지'를 명시합니다.
• 승인: 발주사의 의사결정권자가 재산정 결과를 보고 채택·보류·반려를 결정합니다. 승인된 변경만 개발에 반영하고, 예산·일정 기준선을 갱신합니다.

이 룰의 핵심은 속도가 아니라 가시성과 합의입니다. 변경이 자유롭게 들어오되, 그 대가가 누구에게나 보이고, 결정 권한을 가진 사람이 책임지고 승인합니다.

계약·킥오프 단계 체크리스트

변경관리 룰은 프로젝트가 시작된 뒤 만들면 이미 늦습니다. 계약과 킥오프 단계에서 다음을 문서로 합의해 두시길 권합니다.

• 요구사항을 핵심 범위와 조정 가능 영역으로 나눈 범위 정의서가 계약 부속 문서로 있는가
• 변경요청 접수 양식과 처리 절차(접수→재산정→승인)가 계약서에 명문화되어 있는가
• 변경에 따른 추가 비용·일정을 어떤 기준으로 산정하는지(단가·공수 기준) 사전에 합의했는가
• 변경을 최종 승인할 양측 의사결정권자가 각각 지정되어 있는가
• 정기 보고 주기와 커뮤니케이션 채널이 정해져 있는가 — Gitnux 통계에서 아웃소싱 고객의 42%가 커뮤니케이션 문제를 가장 흔한 어려움으로 꼽습니다
• 범위 밖 재작업을 줄이기 위한 검수·품질 기준이 있는가 — 외주 코드의 품질 이슈로 평균 27% 수준의 재작업이 발생한다는 통계가 있습니다

마무리: 변경은 리스크가 아니라 관리 대상입니다

예산이 중반에 무너지는 프로젝트와 끝까지 궤도를 지키는 프로젝트의 차이는 '변경이 있었느냐'가 아니라 '변경을 어떻게 다뤘느냐'에 있습니다. 변경은 어느 프로젝트에나 찾아옵니다. 그것을 감정적으로 막거나 조용히 삼키는 대신, 접수하고 재산정하고 승인하는 눈에 보이는 룰로 통제할 때 예산과 신뢰가 함께 지켜집니다.

FIRSTPIP은 견적과 계약 단계부터 범위 정의서와 변경관리 절차를 함께 설계해, 프로젝트 중반의 예산 붕괴를 구조적으로 줄이는 방식으로 일합니다. 지금 준비 중인 프로젝트가 있다면, 기능 목록보다 먼저 '무엇이 핵심 범위이고 무엇이 조정 가능한가'부터 정리해 보시길 권합니다.