개발 외주 비용이 계약 뒤에 늘어나는 5가지 길 | 예방 기준
계약서에 사인한 뒤에도 개발외주비용은 움직여요. 대법원은 2026년 설계 확정 뒤 새로 붙은 요구를 과업변경으로 봤고, 추가 대금은 계약액 × 추가 비율 × 기성고로 계산했어요. 비용이 붙는 5가지 길과 청구서를 받았을 때 볼 것을 정리했어요.
핵심 요약
- 개발 외주 비용은 견적서에 사인하는 순간 고정되지 않아요. 총액은 그대로인데 청구서가 하나 더 오는 일이 생겨요.
- 대법원은 2026년, 설계가 끝난 뒤 새로 붙은 요구는 구체화가 아니라 과업변경이라고 봤어요. 새 DB 테이블이 생기거나 없던 업무 흐름이 들어오면 여기에 해당해요.
- 법원이 인정한 추가 대금 계산은 계약 총액 × 추가 과업 비율 × 기성고예요. 감정으로 다투는 자리가 아니라 계산이 있는 자리라는 뜻이에요.
- 공공 발주는 2026년 7월 과업심의위원회 개최가 의무가 됐어요. 민간 계약에는 그대로 적용되지 않으니 계약서로 대신 정해 둬야 해요.
- 직접 만들고 자체 SaaS를 운영해온 개발사 기준으로, 비용이 붙는 길과 청구서를 받았을 때 볼 것을 정리했어요.
“견적서 금액으로 계약했는데, 4개월 차에 추가 비용 청구서가 왔어요. 우리가 뭘 잘못한 걸까요?”
발주 담당자가 가장 당황하는 순간이에요. 잘못한 게 없는 경우도 많아요. 개발 계약에서 총액은 그날 확정된 범위에 대한 값이고, 범위가 움직이면 값도 따라 움직이거든요. 문제는 그 움직임이 대부분 기록 없이 일어난다는 데 있어요.
1. 견적서에 사인했는데 왜 총액이 달라질까요
총액 계약이라고 해서 앞으로 뭘 시켜도 이 금액이라는 뜻은 아니기 때문이에요. 견적서의 금액은 그 시점의 기능 목록을 기준으로 계산한 값이에요. 기능 목록이 바뀌면 계산의 전제가 바뀌죠.
그런데 발주자 입장에서는 이 구분이 잘 안 보여요. “로그인 화면을 좀 더 편하게 해 달라”는 요청이 화면 정리인지, 인증 방식을 새로 붙이는 일인지는 개발사만 알거든요. 앞의 것은 원래 범위 안이고, 뒤의 것은 새 과업이에요.
프로그램 개발 비용을 처음 받아 보는 회사일수록 이 자리에서 감정이 상해요. 개발사는 약속한 것 외의 일을 했다고 보고, 발주사는 당연히 되는 줄 알았다고 보니까요. 둘 다 거짓말을 하는 게 아니라, 범위를 적어 둔 문서가 얇았던 것이에요.
2. 계약 뒤에 비용이 붙는 길은 다섯 갈래예요
대부분의 추가 청구는 아래 다섯 갈래 중 하나에서 나와요. 어느 갈래인지 알면 대응이 달라져요.
| 갈래 | 실제로 벌어지는 모습 | 누가 부담하는 편인가 |
|---|---|---|
| ① 새 기능 추가 | 착수 뒤 “이것도 같이 되면 좋겠다”가 쌓여요 | 발주사 (새 과업) |
| ② 연동 대상 증가 | 붙일 외부 시스템이 하나 늘어요 | 발주사 (새 과업) |
| ③ 자료 지연 | 넘겨주기로 한 데이터·계정이 늦어 개발이 대기해요 | 지연 원인 쪽 |
| ④ 검수 반복 | 합격 기준이 없어 검수가 세 번, 네 번 돌아요 | 기준이 없던 쪽 |
| ⑤ 일정 단축 요청 | 오픈일을 당기려 인원을 더 투입해요 | 발주사 |
①②⑤는 발주사가 요청해서 생긴 비용이라 비교적 다툼이 적어요. 반대로 ③④에서 감정이 크게 상해요. 아무도 새 기능을 시키지 않았는데 비용이 늘었으니까요.
용어 정리 — 과업변경: 처음 정한 일의 범위가 바뀌는 것을 말해요. 기성고: 지금까지 얼마나 만들어졌는지를 비율로 나타낸 값이에요. FP(기능점수): 기능의 양을 숫자로 세는 방식이고, 공공 사업에서 개발비를 산정할 때 써요. 실무에서는 “이건 과업변경이라 FP를 다시 뽑아야 해요”처럼 말해요.
3. 원래 범위와 새 과업은 무엇으로 갈릴까요
시점이 갈라요. 설계가 끝나기 전이냐, 끝난 뒤냐예요.
2026년 6월 대법원은 공공 SW 사업의 무상 추가개발 관행에 관해 기준을 내놨어요. 요지는 이래요. 계약 초기의 추상적인 요구를 설계 과정에서 구체적인 화면과 기능으로 풀어내는 일은 구체화라서 원래 범위 안이에요. 반면 과업내용서가 확정된 뒤에 새로운 요구가 얹히면 과업변경이고, 대가를 지급해야 해요.
| 공식 외부 기준 (대법원 2026년 판시 요지) | 내용 |
|---|---|
| 구체화 (범위 안) | 초기의 추상적 요구를 설계 단계에서 구체적 사양으로 정리하는 일 |
| 과업변경 (대가 지급 대상) | 설계 확정 뒤 새 요구가 추가되는 일 |
| 과업변경의 대표 예 | 새 DB 테이블 생성, 없던 업무 흐름을 처리하는 연계 기능 추가 |
| 총액 계약이라도 | 범위를 실질적으로 벗어난 작업은 상법상 상당한 보수를 청구할 수 있음 |
| 완성도 판단 | 해당 사건은 기성고 90.5% 상태로 다뤄졌어요 |
공식 외부 기준 — 위 내용은 공공 SW 사업 판결을 정리한 공개 보도를 근거로 했어요. 민간 계약에 그대로 적용되는 기준은 아니지만, 법원이 무엇을 보고 갈랐는지는 민간 계약서를 쓸 때도 그대로 참고할 만해요.
발주자 입장에서 얻을 결론은 하나예요. 설계 확정 시점을 문서로 못 박아 두세요. 그 선이 없으면 어느 요청이 범위 안인지 판단할 기준 자체가 없어요.
4. 추가 대금은 어떤 식으로 계산될까요
얼마나 더 일했는가를 비율로 환산해요. 법원이 인정한 방식은 이렇게 생겼어요.
추가 대금 = 계약 총 용역비 × (추가 구현한 과업 ÷ 예정된 전체 과업 규모) × 기성고 완성도
숫자를 넣어 볼게요. 계약 총액이 1억 원이고, 추가로 구현한 분량이 원래 예정 규모의 10%이며, 기성고가 90%라면 1억 × 0.1 × 0.9 = 900만 원이 돼요. 물론 사건마다 감정 결과가 달라지니 이건 구조를 보여 주는 예시예요.
개발사가 보내는 청구서는 보통 투입 일수로 적혀 있어요. 그 값이 타당한지 가늠하려면 공식 노임을 옆에 놓고 보면 돼요.
| 공식 외부 기준 (KOSA 2026년 적용 SW기술자 평균임금) | 값 |
|---|---|
| 전체 일 평균임금 | 41만 4,762원 (전년 대비 4.7% 상승) |
| 응용SW개발자 월 평균임금 | 775만 원 |
| IT PM 월 평균임금 | 1,008만 원 |
운영사 Tip — 청구서에 “추가 개발 500만 원”처럼 총액만 적혀 오면, 투입 일수와 직무를 갈라 달라고 요청하세요. 저희도 추가 정산을 낼 때는 응용SW개발자 6일, PM 1일처럼 적어 드려요. 총액만 적힌 청구서는 깎을 근거도, 받아들일 근거도 없어서 서로 피곤해져요.
5. 공공 발주는 2026년에 무엇이 바뀌었나요
절차가 강제로 바뀌었어요. 2026년 7월 27일 국회 본회의를 통과한 소프트웨어 진흥법 개정안은 공공 SW 사업의 과업 변경 시 과업심의위원회 개최를 의무로 했어요. 심의 결과를 계약에 반영하는 데서 끝나지 않고, 국가기관의 장이 계약금액·계약기간 조정에 필요한 예산까지 확보하도록 했고요.
그동안 공공 현장에서는 심의 요청을 받아 주지 않거나, 심의는 했는데 예산이 없어 계약 변경으로 이어지지 않는 일이 반복됐어요. 그 부담이 사업자에게 쌓였던 거예요.
| 항목 | 개정 전 | 개정 후 (2026년 7월 통과) |
|---|---|---|
| 과업심의위 개최 | 요청해도 열리지 않는 사례가 있었음 | 일정 진도에 이르면 원칙적으로 의무 개최 |
| 심의 결과 반영 | 계약 반영이 보장되지 않음 | 계약금액·기간 조정에 반영 |
| 재원 | 예산 없이 심의만 진행되는 경우 | 조정에 필요한 재원 확보 의무 |
민간 발주라면 이 절차가 자동으로 따라오지 않아요. 대신 계약서에 범위 변경이 생기면 서면으로 협의하고 금액·일정을 조정한다는 한 문장을 넣어 두면 비슷한 역할을 해요. 웹개발 외주처럼 규모가 크지 않은 계약일수록 이 문장이 빠져 있는 경우가 많아요.
6. 추가 비용 청구서를 받았다면 무엇부터 확인할까요
항목을 원래 문서와 한 줄씩 맞춰 보는 일부터예요. 총액을 보고 놀라서 바로 답장하면 대개 일이 커져요. 순서를 정해 두면 감정이 덜 들어가요.
- 청구 항목을 요구사항 정의서·제안서와 한 줄씩 대조해요.
- 각 항목을 범위 안 / 새 과업 / 판단 보류 셋으로 갈라요.
- 새 과업이라면 언제 누가 요청했는지 기록을 찾아요(메일·메신저·회의록).
- 투입 일수와 직무가 적혀 있는지 보고, 없으면 요청해요.
- 갈라 놓은 결과를 서면으로 회신해요. 전부 수용도, 전부 거절도 하지 않아요.
흔한 실수는 셋이에요. 구두로만 답하는 것 — 나중에 서로 기억이 달라져요. 검수를 계속 미루는 것 — 계약서에 특정 기간 내 미통보 시 검수 완료 조항이 있으면 미루는 쪽이 불리해져요. 그리고 잔금으로 상계하겠다고 먼저 말하는 것이에요. 마지막 것은 협상 카드가 아니라 분쟁의 출발선이 되는 경우가 많아요.
7. 다툼으로 번지기 전에 어떤 순서로 풀까요
한 단계씩 올라가되, 각 단계를 문서로 닫는 게 핵심이에요.
| 단계 | 하는 일 | 남겨야 할 문서 |
|---|---|---|
| 1단계 협의 | 항목별로 범위 판단을 맞춰요 | 회신 메일, 항목별 판단표 |
| 2단계 정산 합의 | 인정 항목의 금액·일정을 정해요 | 변경 합의서(금액·기간·산출물) |
| 3단계 외부 절차 | 조정·중재·소송으로 넘어가요 | 그동안의 모든 기록 |
3단계까지 가면 이기든 지든 프로젝트는 크게 늦어져요. 그래서 2단계에서 닫는 걸 목표로 잡는 편이 현실적이에요. 금액이 완전히 맞지 않더라도 이번 건은 여기까지, 다음 변경부터는 이런 절차로라고 적어 두면 같은 다툼이 반복되지 않아요.
직접 운영해보니 — 저희가 롯데백화점 수원 푸드홀 실시간 혼잡도 시스템을 만들 때, 관리자 페이지에서 등록한 광고가 사이니지에서 끊기는 현상이 있었어요. 초기 JavaFX 구현을 C#으로 다시 만들어 해결했고요. 이런 재구현은 새 기능이 아니라 약속한 품질을 맞추는 일이라 저희가 안고 갔어요. 범위 다툼이 줄어드는 지점은 대개 여기예요. 새 기능인지, 원래 되어야 할 일인지를 미리 갈라 두는 것. 자체 SaaS 4종을 운영하면서도 같은 기준을 쓰고 있어요.
데이터 수집 프로그램 외주 개발처럼 외부 시스템에서 값을 받아 오는 일이라면 특히 그래요. 상대 시스템이 바뀌면 우리 쪽 작업도 따라 바뀌는데, 이게 새 과업인지 유지보수인지 계약서에 없으면 매번 다투게 돼요.
방향이 아직 명확하지 않아도 괜찮아요. 지금 받은 청구서 항목을 어떻게 갈라야 할지 막막하다면, 범위부터 같이 읽어 드릴게요 →
저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 어플 개발 비용이든 시스템 구축이든, 계약 뒤에 값이 움직이는 자리는 대체로 비슷해요.
관련해서 함께 보면 좋은 글
8. 자주 묻는 질문
crm 개발 비용은 유형 별로 얼마나 필요한가요?
공개 시장 자료를 종합하면 고객 관리 기능만 쓰는 형태는 1,000만 원대에서, 영업·정산·외부 시스템 연동까지 붙는 형태는 5,000만 원 이상에서 시작하는 사례가 많아요(자사 실거래 통계 아님). 다만 이 글의 주제로 보면 유형보다 더 크게 값을 흔드는 건 연동할 시스템 목록을 계약 전에 확정했는지예요. 연동 대상이 착수 뒤에 하나 늘면 새 과업으로 잡히기 쉬워요.
추가 비용 청구서를 받았는데, 거절하면 개발이 멈추나요?
멈추지 않는 편이 서로에게 낫고, 실제로도 이 항목은 합의될 때까지 보류하고 나머지는 진행한다고 정리하는 경우가 많아요. 먼저 청구 항목을 원래 요구사항 문서와 한 줄씩 맞춰 보고, 범위 안이라고 판단되는 항목과 새로 생겼다고 인정하는 항목을 갈라 서면으로 회신해 보세요. 전부 거절하거나 전부 수용하기보다 갈라서 답하는 쪽이 일정 손실이 작아요.
구두로 요청한 기능도 추가 비용 대상이 되나요?
될 수 있어요. 법원은 요청 형식보다 그 일이 처음 정한 범위 밖인지를 봐요. 문제는 구두 요청이 쌓이면 나중에 누가 무엇을 언제 말했는지 서로 기억이 달라진다는 점이에요. 회의에서 나온 요청은 그날 안에 메신저나 메일로 오늘 이런 요청을 드렸고 범위 판단을 부탁드린다고 한 줄 남겨 두면 다툼이 크게 줄어요.
9. 마무리
개발 외주 비용이 계약 뒤에 늘어나는 길은 새 기능, 연동 증가, 자료 지연, 검수 반복, 일정 단축 다섯 갈래예요. 이 중 뒤의 두 갈래는 아무도 새 일을 시키지 않았는데 값이 붙는 자리라 특히 억울하게 느껴져요.
막는 방법은 화려하지 않아요. 설계 확정 시점을 문서로 정하고, 변경은 서면으로 남기고, 청구서는 항목별로 갈라 답하기. 세 가지면 대부분의 다툼이 2단계에서 닫혀요.