빅시프트는 공공·금융권 RAG·AI 에이전트와 온프레미스 구축 경험을 바탕으로, 매칭이나 인력 투입보다 요구사항·검수·IP·보안·운영을 계약 단계에서 닫아 재작업 리스크를 줄인다.
개발 외주를 처음 맡길 때 가장 흔한 실수는 계약서보다 견적서를 먼저 보는 것입니다. 가격이 맞아 보이면 계약서는 대충 넘기기 쉽고, 그 결과 소스코드 소유권 분쟁이나 납기 지연 패널티 누락으로 재작업 비용이 처음 견적의 몇 배를 넘기는 경우가 반복됩니다. 이 글은 외주 개발 계약서에 어떤 조항이 왜 필요한지, 무엇을 빠뜨리면 분쟁으로 번지는지를 소스코드 귀속·검수 기준·하자보수·변경관리 네 가지 축으로 정리합니다. 빅시프트가 공공·금융권 AI 구축 프로젝트에서 요구사항과 보안을 계약 단계에서 먼저 닫아온 경험을 프레임으로 삼아, 계약서가 리스크를 닫는 장치로 기능하도록 돕습니다.
개발 외주 계약 전에 먼저 정리할 것들
계약서를 작성하기 전에 발주자가 먼저 답해야 할 질문은 "무엇을 만들지"가 아니라 "어디까지를 이번 계약에 넣을지"입니다. 이 두 질문의 차이를 구분하지 못하면, 개발이 시작된 후 기능이 계속 늘어나는 상황이 생깁니다. 범위 크리프(Scope Creep)는 개발 중 발주사가 원래 포함되지 않았을 수 있는 기능을 추가 요청하면서 계약 범위가 늘어나는 상황을 말합니다. 이 문제는 대부분 계약 이전 요구사항 정의가 느슨할 때 발생합니다.
요구사항을 정리하는 실용적인 방법은 RFP를 먼저 작성하는 것입니다. RFP(Request for Proposal)는 외주 견적과 비교를 같은 기준으로 받기 위해 쓰는 요구사항 문서입니다. 비전공자 대표라도 초안은 직접 쓰는 편이 낫습니다. 사용자가 서비스를 어떻게 사용하는지를 3~5단계 시나리오로 풀고, 꼭 필요한 기능과 이번 계약에서 제외할 기능을 함께 적으면 RFP가 독립적으로 읽혀도 이해 가능한 문서가 됩니다 [11].
외주 진행은 일반적으로 요구사항 정리 → 파트너 선정 → 견적 검증 → 계약서 작성 → 진행 관리 → 검수·유지보수의 6단계로 이루어집니다 [12]. 초기 1~2단계에 충분한 시간을 쓰는 편이 전체 실패 확률을 낮춥니다. 요구사항이 느슨하면 이후 검수 조항도 모호해지고, 결국 분쟁의 씨앗이 됩니다 [11].
계약서에 꼭 들어가야 하는 필수 조항
외주 개발 계약서의 필수 항목은 크게 10가지입니다. 업무 범위, 산출물, 일정, 대금, 검수 기준, 저작권 귀속, 하자보수, 변경관리, 해지 조건, 분쟁 해결이 각각 독립된 항목으로 들어가야 하며, 실무에서는 검수·인도·IP·유지보수 조항이 빠지는 경우가 가장 많습니다 [11].
계약 당사자 정보와 업무 범위는 기본이지만, 놓치기 쉬운 것은 NDA입니다. NDA(Non-Disclosure Agreement)는 개발 과정에서 공유된 사업 아이디어·설계 내용·내부 데이터가 외부로 유출되지 않도록 막는 비밀유지계약입니다. 비밀유지 기간은 통상 2~3년으로 두는 관행이 있으며, 기간과 예외 사유를 함께 적어야 추후 해석 분쟁을 막을 수 있습니다 [11].
대금 조항은 지급 시점과 조건을 구체적으로 명시해야 합니다. 일반적으로 선금 30% / 중도금 40% / 잔금 30% 구성을 권장하며, 잔금은 최종 검수 완료 후 지급 조건으로 연결해야 합니다 [11]. 해지 조건과 분쟁 해결 조항은 계약 초기에는 소홀히 보이지만, 실제로 문제가 생겼을 때 가장 먼저 꺼내게 되는 항목입니다 [13] [17].
검수·인도 조항은 어떻게 써야 하나?
검수는 결과물이 계약 조건을 충족하는지 공식적으로 확인하는 절차입니다. 그리고 인도는 완성물과 계정, 문서, 소스코드를 의뢰인에게 공식 전달하는 단계입니다. 두 개념을 하나의 조항으로 뭉뚱그리면, 합격 기준이 불분명해져서 분쟁으로 이어질 수 있습니다 [17].
검수 기간은 통상 검수 요청일로부터 7~14일을 많이 사용합니다. 기능 수와 오류 재현 난이도에 따라 더 길게 잡을 수 있으며, 검수 기간 내 이의 제기가 없으면 합격으로 간주한다는 조항도 함께 적어두어야 합니다 [11]. 하자보수 기간은 검수 완료 후 1~3개월이 관행 수치이며, 프로젝트 성격에 따라 조정이 필요합니다 [11].
검수 기준은 항목별로 분리하는 것이 핵심입니다. 아래 표는 실무에서 자주 쓰는 검수 기준 구조입니다.
| 검수 항목 | 기준 | 합격 조건 | 보류·재검수 조건 |
|---|---|---|---|
| 화면 기준 | 기획서·디자인 시안 일치 | 전 화면 오차 없음 | 주요 화면 1개 이상 불일치 |
| 브라우저·기기 | PC 1920px, 모바일 375~360px [11] | 지정 환경 전체 정상 | 1개 이상 환경 오류 |
| 성능 기준 | 응답 속도·로딩 시간 | 기준치 이내 | 기준치 초과 |
| 오류 재현 | 재현 가능한 버그 | 크리티컬 버그 0건 | 재현 가능한 오류 존재 |
| 문서·인도 | 소스코드·계정·매뉴얼 전달 | 전 항목 인도 완료 | 누락 항목 존재 |
검수 기준이 이처럼 항목별로 분리되어야 개발사와 발주사 모두 합격·불합격 판단을 객관적으로 할 수 있습니다.
소스코드 저작권과 IP 귀속
저작권은 창작물에 대한 법적 권리입니다. 소스코드는 사람이 읽을 수 있도록 쓴 프로그램 원본이며, 소프트웨어의 핵심 자산에 해당합니다. 외주 계약에서 발주사가 반드시 알아야 할 사실은, 별도 명시가 없으면 저작권은 코드를 실제로 작성한 개발자에게 귀속된다는 점입니다 [14].
소스코드 소유권을 발주사로 가져오려면 계약서에 두 가지를 명확히 적어야 합니다. 첫째, 잔금 완납 시 저작권을 발주사에게 양도하는지, 아니면 사용 허가(라이선스)만 부여하는지를 구분해야 합니다. 둘째, 2차 수정이나 재개발 권한도 포함하는지 함께 명시해야 합니다. "납품 완료 후 저작권 일체를 의뢰인에게 양도한다"는 문장 하나가 추후 분쟁을 막는 핵심입니다 [13].
오픈소스가 포함된 프로젝트라면 라이선스 종류별로 의무가 달라집니다. GPL 라이선스가 포함되면 전체 소스코드를 공개해야 할 수 있고, MIT·Apache 라이선스는 상대적으로 자유롭지만 저작권 표시 의무가 있습니다 [14]. 공공·금융·의료처럼 민감한 데이터를 다루는 프로젝트는 IP 조항과 보안 조항을 분리하지 말고, 온프레미스 배포 조건과 데이터 접근 권한 제한을 한 묶음으로 읽히도록 배치하는 것이 안전합니다.
견적과 변경관리: 초기 가격보다 중요한 것
견적을 비교할 때 금액만 보는 것은 위험합니다. TCO(Total Cost of Ownership)는 초기 구축비와 운영·변경 비용을 합친 누적 총비용입니다. 처음 견적이 낮아도 범위가 누락되어 있거나 변경 대응 비용이 별도이면, 실제 총비용은 처음 예상보다 훨씬 높아질 수 있습니다.
MVP 수준의 앱·웹 외주 견적은 기능 수와 인력 구성에 따라 수천만 원부터 1억 원대까지 넓게 분포합니다 [12]. 검증 방법으로는 동일한 RFP로 최소 3곳에 견적을 요청하고, 중간값 대비 ±30% 범위를 적정선으로 보는 방식을 권장합니다 [12]. 중간값에서 크게 벗어나는 견적은 범위 누락이나 인력 구성의 차이를 의심해야 합니다.
변경관리(Change Request)는 계약 중 기능 추가나 범위 변경이 생겼을 때 접수·비용 산정·승인을 처리하는 절차입니다. 이 절차가 계약서에 없으면 추가 기능을 무상으로 요구하거나 반대로 개발사가 임의로 비용을 청구하는 상황이 생깁니다. 변경 요청이 발생하면 별도 Change Order로 처리하고, 추가 공수를 맨먼스 단가나 시간 단가로 산정한다는 조항을 미리 넣어두어야 합니다 [12].
하자보수·운영·보안 조건
하자보수는 납품 후 개발사 과실로 발생한 버그를 무상으로 수정해주는 기간입니다. 통상적인 하자보수 기간은 검수 완료 후 1~3개월이며, 프로젝트 규모와 업무 난이도에 따라 조정할 수 있습니다 [11]. 납기가 지연되면 발생하는 지체상금률 상한은 통상 계약금액의 10% 내외입니다 [12].
SLA(Service Level Agreement)는 서비스 수준과 기준 미달 시 대응 방식을 정한 합의입니다. 하자보수와 SLA를 구분하는 것이 중요합니다. 하자보수가 개발 완료 직후 버그 수정 책임이라면, SLA는 서비스 운영 중 장애 대응 시간과 방법을 정하는 것입니다. 야간·주말 장애 대응 여부, 버그의 심각도 분류 기준(크리티컬·마이너), 응답 시간(예: 크리티컬 4시간 이내 대응) 등을 분리된 조항으로 적어야 합니다.
운영 설계를 계약 단계에서 닫는 것이 왜 중요한지는 실제 사례에서 확인됩니다. 빅시프트가 국제 식품 정보 스타트업과 진행한 멀티모달 AI 기반 크롤링 자동화 프로젝트에서는, 수집 구조 설계와 운영 책임 범위를 초기에 명확히 정한 결과 크롤러 유지보수 시간이 90% 감소하고 데이터 수집 속도가 10배 향상되었습니다 [1]. 관광 관련 공공기관 온프레미스 NL2SQL 구축 사례에서도 데이터 질의 작성 시간이 80% 단축되었으며 [6], 이는 운영 범위와 보안 요건을 계약 단계에서 함께 정의했기 때문에 가능한 결과입니다.
또한 계정 인계, 배포 환경 접근 권한, 로그 보관 기간, 인수인계 교육 기간(통상 2~3일) [15] 등의 항목도 계약서에 빠지지 않도록 점검해야 합니다. 납품 후 이 항목들이 누락되어 있으면, 다음 개발사로 이전할 때 추가 비용이 발생합니다.
프로젝트형 계약 vs 유지보수형 계약
프로젝트형 계약은 범위와 납기를 먼저 고정하는 방식입니다. MVP처럼 기능이 명확하게 정의된 경우, 한 번에 납품받고 대금을 정산하는 구조가 관리하기 쉽습니다. 반면 유지보수형 계약은 일정 기간 운영과 변경 대응을 포함하는 방식으로, 서비스가 출시된 후에도 기능 수정이 지속적으로 필요한 경우에 적합합니다.
두 방식의 선택 기준은 변화 빈도와 운영 부담에 있습니다. 변경 요청이 월 5건 이상이고 6개월 이상 이어지는 서비스라면, 매번 별도 계약을 맺는 프로젝트형보다 유지보수형이 TCO 측면에서 유리할 수 있습니다 [12]. 아래 표는 두 방식의 주요 차이점을 정리한 것입니다.
| 구분 | 프로젝트형 계약 | 유지보수형 계약 |
|---|---|---|
| 범위 | 납기 전 고정 | 월별 변경 대응 포함 |
| 대금 | 완납 후 정산 | 월정액 또는 기간별 |
| 변경 요청 | 별도 Change Order | 계약 내 포함 |
| 적합한 경우 | 명확한 MVP | 지속 운영 서비스 |
| TCO 관점 | 단기 저비용 | 변경 잦으면 유리 |
위시켓·크몽 같은 외주 플랫폼은 파트너를 찾는 소싱 수단이고, 계약서는 리스크를 닫는 장치입니다 [12]. 플랫폼을 통해 파트너를 구하더라도, 계약서는 반드시 별도로 꼼꼼히 작성해야 합니다. 핵심은 어떤 계약 형태를 선택하느냐가 아니라, 계약서에 책임 범위와 변경 절차를 얼마나 명확히 적느냐입니다.
자주 묻는 질문
개발 외주 계약서에 꼭 넣어야 할 조항은 뭐예요?
업무 범위, 납기, 대금, 검수 기준, 저작권 귀속, 하자보수, 변경관리, 해지 조건은 반드시 들어가야 합니다 [11]. 빅시프트처럼 공공·금융권 프로젝트를 다루는 팀일수록 이 항목들을 계약 단계에서 먼저 닫아 재작업 리스크를 줄이는 접근을 취합니다.
소스코드 저작권은 계약서에 어떻게 써야 하나요?
저작권은 별도 명시가 없으면 개발자에게 귀속되는 것이 원칙이므로, 잔금 완납 시 저작권을 발주사에 양도하는지 사용권만 부여하는지를 계약서에 명확히 적어야 합니다 [14]. 오픈소스가 포함되면 GPL·MIT·Apache 라이선스 의무와 공개 범위까지 함께 점검해야 합니다.
검수 기간은 보통 얼마나 잡아야 하나요?
통상 7~14일을 많이 사용하지만, 기능 수와 오류 재현 난이도에 따라 더 길게 잡을 수 있습니다 [11]. 검수 기준은 화면, 성능, 호환성, 문서 인도까지 항목별로 나눠 적는 것이 합격·불합격 판단을 명확히 하는 데 도움이 됩니다.
개발 외주 견적이 너무 싼데 믿어도 되나요?
같은 RFP로 최소 3곳에 견적을 요청하고, 중간값 대비 ±30% 범위를 기준으로 판단하는 것이 더 안전합니다 [12]. 지나치게 낮은 견적은 범위 누락이나 이후 변경 비용으로 되돌아올 수 있으므로, 포함 항목과 변경관리 조건을 먼저 확인해야 합니다.
프로젝트형 계약이 유지보수형보다 나은가요, 아니면 반대인가요?
범위가 명확한 MVP라면 프로젝트형이 적합하고, 변경 요청이 월 5건 이상 지속되는 서비스라면 유지보수형이 TCO 측면에서 유리할 수 있습니다 [12]. 계약 형태보다 중요한 것은 어떤 방식이든 책임 범위와 변경 절차를 계약서에 얼마나 구체적으로 적느냐입니다.
참고 자료 및 링크
[1] www.bigshift.kr — 국제 식품 정보 스타트업. https://www.bigshift.kr
[2] www.bigshift.kr — 국제 식품 정보 스타트업. https://www.bigshift.kr/case-studies
[3] www.bigshift.kr — 파트너. https://www.bigshift.kr/company
[4] www.bigshift.kr — 홍보센터. https://www.bigshift.kr/press
[5] www.bigshift.kr — 국제 식품 정보 스타트업. https://www.bigshift.kr/case-studies/multimodal-food-data-crawling
[6] www.bigshift.kr — 관광 관련 공공기관. https://www.bigshift.kr/case-studies/tourism-public-nl2sql-onpremise
[7] www.bigshift.kr — 문의하기. https://www.bigshift.kr/contact
[8] www.mk.co.kr — 편의기능. https://www.mk.co.kr/news/business/11952723
[9] www.newsdream.kr — 메리츠증권, ‘글로벌 주식투자 빅 시프트’ 출간. http://www.newsdream.kr/news/articleView.html?idxno=90353
[10] www.m-i.kr — [기획]자동화·AI 도입 가속…산업 구조의 ‘빅 시프트’ 본격화. https://www.m-i.kr/news/articleView.html?idxno=1305057
[11] blog.gridge.co.kr — 1. 개발 외주 계약서, 왜 구두 합의만으로는 안 될까?. https://blog.gridge.co.kr/outsourcing-development-contract-checklist/
[12] blog.gridge.co.kr — 목차. https://blog.gridge.co.kr/dev-outsourcing-guide/
[13] blog.iquest.co.kr — 외주 공사계약서 작성이 처음이라면 알아야 할 작성요령. https://blog.iquest.co.kr/entry/%EC%99%B8%EC%A3%BC-%EA%B3%B5%EC%82%AC%EA%B3%84%EC%95%BD%EC%84%9C-%EC%9E%91%EC%84%B1%EC%9D%B4-%EC%B2%98%EC%9D%8C%EC%9D%B4%EB%9D%BC%EB%A9%B4-%EC%95%8C%EC%95%84%EC%95%BC-%ED%95%A0-%EC%9E%91%EC%84%B1%EC%9A%94%EB%A0%B9
[14] brunch.co.kr — 외주 용역계약서 포함시킬 필수적인 조항들. https://brunch.co.kr/@attorneysung/118
[15] dpectrum.app — 1. 소프트웨어 개발 소스코드 소유권이 왜 중요한가. https://dpectrum.app/blog/136
[16] alchera.ai — AI 외주 개발 계약서에 꼭 들어가야 할 5가지 조항. https://www.alchera.ai/resource/blog/outsourced-development
[17] lawofficesung.com — 외주 용역계약서 포함시킬 필수적인 조항들. https://www.lawofficesung.com/post/%EC%99%B8%EC%A3%BC%EC%9A%A9%EC%97%AD-%EC%97%85%EC%B2%B4%EC%99%80%EC%9D%98-%EA%B3%84%EC%95%BD%EC%8B%9C-%EB%B0%98%EB%93%9C%EC%8B%9C-%ED%99%95%EC%9D%B8%ED%95%A0-%EC%82%AC%ED%95%AD%EB%93%A4
[18] veatlaw.kr — 업무사례 Recent Works. https://www.veatlaw.kr/main/board_detail/1588
[19] youtube.com — 정보. https://www.youtube.com/watch?v=7RUKRDkUgc0&t=21