외주 개발 견적서와 계약서에서 자주 빠지는 항목들 체크하기

Insight

2026년 4월 13일

프로젝트가 동시에 3~4개 돌아가기 시작하면서부터 이런 일이 생기기 시작했을 거예요.

A 프로젝트 계약서는 김 이사가 만든 워드 파일에 있고, B 프로젝트 견적서는 박 팀장 로컬 폴더에 있고, 클라이언트와 나눈 수정 합의 내용은 카카오톡 어딘가에 묻혀 있어요. 담당자가 각자 알아서 챙기는 구조에서는 누군가 한 명이 아무리 꼼꼼해도 팀 전체의 계약 품질을 보장하기 어려워요.

그 결과는 계약서에 도장 찍고 나서야 발견되는 경우가 많아요. "이 기능이 범위에 포함된다고 생각했는데", "잔금 지급 기준이 이렇게 해석될 수도 있었네." 혼자 꼼꼼하지 않아서 생기는 문제가 아니에요. 팀이 생기고 프로젝트 수가 늘면서 기존의 분산된 방식이 더 이상 버티지 못하는 거예요.

이 글에서는 IT 개발사에서 특히 자주 발생하는 견적·계약 리스크 항목을 짚고, 구조적으로 이걸 방지하려면 어떤 흐름이 필요한지 살펴볼게요.

외주 개발 견적서에서 반복적으로 빠지는 항목들

견적서는 보통 금액 중심으로 작성돼요. 얼마짜리 개발, 얼마짜리 유지보수. 그런데 이후 분쟁이 생기는 이유는 대부분 금액이 아니라 범위 때문이에요. IT 개발사에서 특히 반복되는 누락 항목들을 정리하면 이렇게 돼요.

① 개발 범위 기준이 없는 견적
"기본 기능 개발"이라고만 적혀 있으면 클라이언트는 로그인부터 알림 시스템, 관리자 페이지까지 다 포함이라고 생각할 수 있어요. 포함 기능 목록과 제외 항목을 견적서에 명시해두지 않으면, 추가 요청이 들어올 때마다 개발사가 수세에 몰리게 돼요. 범위 크리프(scope creep)가 시작되는 지점이 바로 여기예요. 인력이 추가 투입됐는데 정산 기준이 없어서 공수를 받지 못하는 상황, IT 개발사에서는 흔한 일이에요.

② 수정 횟수 또는 수정 기준 미정
디자인 변경, 기능 스펙 조정 요청이 계속 들어오는데 "수정은 몇 번까지"가 없으면 무한 수정이 기본값이 돼요. 개발사 입장에서는 인력과 일정에 직접 영향을 주는 항목인데, 견적서 단계에서 빠지는 경우가 많아요.

③ 유지보수 조건 누락
개발 완료 후 유지보수 조건이 구두로만 합의되면 나중에 "그게 무상이냐, 유상이냐", "버그 수정이 포함이냐, 기능 추가는 별도냐"로 이어져요. 범위, 기간, 응답 시간까지 견적서 단계에서 정리해두는 게 좋아요.

④ M/M 단가 산정 근거 없음
클라이언트 입장에서 단가가 왜 이 금액인지 이해가 안 되면 불신이 쌓여요. 기능별 공수를 나눠 보여주거나 M/M 기준으로 단가를 설명할 수 있어야 "왜 이렇게 비싸냐"는 질문이 줄어들어요. 단가 분쟁은 대부분 근거가 보이지 않는 데서 시작해요.

IT 개발사가 계약서에서 놓치면 가장 비싸게 치르는 조항들

견적서보다 더 무거운 게 계약서예요. 견적은 조율이 가능하지만 계약은 법적 효력이 있거든요. 특히 아래 항목들은 IT 개발사의 재무 리스크와 직결돼요.

① 납품 기준이 없는 계약
"개발 완료 시 잔금 지급"이라고만 적혀 있으면 완료의 기준이 없어요. 클라이언트가 "아직 완료가 아니다"라고 주장하는 순간 잔금 수령이 무기한 연기돼요. 납품 기준을 기능 목록 확인, QA 완료 여부, 스테이징 환경 배포 등으로 구체화해두는 게 중요해요.

② 정산 일정 불명확
착수금 30%, 중도금 40%, 잔금 30% 같은 비율만 있고 지급 일정이 없으면 실질적으로 언제 받는지 알 수 없어요. "1차 개발 완료 후 7일 이내" 같은 형태로 날짜 트리거를 명확히 해야 해요. 정산이 늦어지면 다음 프로젝트 인력 투입에도 영향을 주거든요.

③ 소스코드 소유권 귀속 조항 누락
소스코드, 디자인 산출물의 소유권이 계약서에 없으면 나중에 분쟁이 생길 수 있어요. 특히 IT 개발사에서 자주 벌어지는 상황은 두 가지예요. 클라이언트가 납품받은 소스코드를 다른 개발사에 넘겨 유사 제품을 만드는 경우, 반대로 개발사가 해당 코드 자산을 유사 프로젝트에 활용하려 할 때 클라이언트가 제동을 거는 경우예요. 어느 쪽이든 계약서에 명시가 없으면 양쪽 다 손해를 봐요.

④ 프로젝트 중도 해지 조건 미정
클라이언트 사정으로 프로젝트가 중단될 때, 이미 투입된 개발 공수에 대한 대금을 어떻게 정산할지 없으면 개발사가 손해를 고스란히 떠안게 돼요. 진행률 기준 정산 조항은 반드시 넣어야 해요.

⑤ 하자보수 범위와 기간 미정
계약 완료 후 버그가 나왔을 때 무상 대응 범위가 없으면 매번 협상을 다시 해야 해요. "개발사 귀책 결함에 한해 납품 후 3개월 무상 수정"처럼 조건을 넣어두면 불필요한 소모를 줄일 수 있어요.

리스크가 생기는 건 실수가 아니라 구조 때문이에요

여기서 솔직하게 짚고 싶은 게 있어요.

위 항목들을 이미 알고 있는 분들도, 실제로 계약서에 다 담지 못하는 경우가 많아요. 이유는 간단해요. 프로세스가 단절돼 있기 때문이에요.

지금 이런 상황이라면 한번 확인해보세요. 클라이언트와 나눈 논의 내용은 메신저에 있고, 견적서는 담당자별로 다른 엑셀 파일로 존재하고, 계약서는 워드 파일로 별도 작성하고, 정산 일정은 스프레드시트에 따로 관리하고 있지는 않나요?

이 구조에서는 아무리 꼼꼼한 담당자도 어딘가 하나는 빠뜨리게 되어 있어요. 그리고 담당자가 바뀌거나 동시에 여러 프로젝트를 맡게 되면, 그 리스크는 배로 커져요.

리스크 관리는 체크리스트를 외우는 게 아니에요. 견적에서 계약으로, 계약에서 정산으로 데이터가 자연스럽게 흘러가는 구조를 만드는 게 본질이에요.

흐름이 연결되면 무엇이 달라질까요?

이런 흐름을 상상해보세요.

클라이언트 문의가 들어오면 의뢰로 수집되고, 그 데이터를 바탕으로 견적서를 만들어요. 기능 목록, M/M 단가, 수정 조건까지 견적서에 담긴 내용이 계약 생성 단계로 그대로 이어지고, 계약에서 정한 정산 일정이 자동으로 등록돼요.

이 흐름에서는 입력을 두 번 하지 않아도 돼요. 견적서에 적은 범위가 계약 단계에서도 그대로 참조되고, 계약에 적은 정산 일정이 미수금 트래킹으로 연결돼요.

담당자가 놓치는 게 아니라, 놓칠 수 없는 구조가 되는 거예요.

플러그가 IT 개발사의 견적·계약 흐름을 어떻게 연결하나요?

플러그는 IT 개발사를 포함한 프로젝트 기반 B2B 기업들이 의뢰 수집부터 세금계산서 발행까지를 하나의 흐름 안에서 관리할 수 있도록 만든 도구예요.

실제로 이렇게 연결돼요.

문의 폼 → 의뢰 자동 수집: 클라이언트가 폼을 제출하면 의뢰로 바로 들어와요. 수기 입력 없이요.
의뢰 → 견적서 생성: 의뢰에 연결된 고객 정보와 요청 내용을 바탕으로 견적서를 만들어요. 기능별 항목과 M/M 단가를 담아 PDF로 발송까지 한 곳에서 처리돼요.
견적 → 계약 연결: 견적 정보를 바탕으로 계약을 생성할 수 있어요. 범위와 금액 정보가 이어지니까 다시 입력하는 수고가 줄어요.
계약 → 정산 자동 등록: 계약에서 정한 정산 일정이 자동으로 정산 현황에 잡혀요. 계좌 연동으로 입금 여부도 자동으로 체크돼요.
정산 → 세금계산서 발행: 정산 완료 건에서 바로 세금계산서를 발행할 수 있어요. 홈택스 연동으로 처리돼요.

리소스 관리 기능에서는 프로젝트별로 투입된 인력과 M/M을 계산해서 실제 수익성도 확인할 수 있어요. 계약 단가가 합리적인지, 이 프로젝트가 실제로 남는 장사인지 숫자로 볼 수 있는 거예요. 범위 크리프로 인력이 추가 투입됐을 때 그 손익이 어디에 어떻게 반영되는지도 바로 보여요.