외주개발 계약서 필수 조항 체크리스트: 범위·검수·소스코드·유지보수까지
답부터 말하면, 외주개발 계약서의 핵심은 ‘무엇을 만들지’보다 ‘어떤 상태가 완료인지, 완료 후 누가 운영할 수 있는지’를 문서로 남기는 것입니다. 웹사이트 리뉴얼처럼 범위가 비교적 단순한 프로젝트도 있지만, 앱·웹 서비스 MVP, SaaS, 예약·결제·매칭 서비스, 관리자 시스템, AI 자동화 기능은 개발 완료 이후에도 서버 운영, 계정 권한, 데이터 관리, 유지보수, 기능 개선이 계속 이어집니다. 그래서 견적서 한 장과 착수금 입금만으로 시작하면 개발 지연, 추가 비용, 소스코드 미인수, 운영 중단 문제가 생기기 쉽습니다.
이 글은 변호사의 법률 자문이 아니라, 창업자·PM·마케터·정부지원사업 수행자가 외주개발 계약 전에 기술적으로 무엇을 확인해야 하는지 정리한 실무 체크리스트입니다. 최종 계약서는 거래 구조, 금액, 하도급 여부, 개인정보 처리 범위, 지식재산권 이전 방식에 따라 전문가 검토를 받는 것이 안전합니다.

계약서는 싸움을 위한 문서가 아니라 운영 기준서입니다
좋은 외주개발 계약서는 상대를 압박하는 문서가 아닙니다. 개발 중 의사결정이 바뀌었을 때 일정과 비용을 어떻게 조정할지, 검수에서 무엇을 확인할지, 출시 후 장애가 나면 누구에게 어떤 방식으로 요청할지 정하는 운영 문서에 가깝습니다.
외주개발 분쟁은 ‘개발사가 코딩을 못해서’만 생기지 않습니다. 상당수는 요구사항, 승인 기준, 계정 소유권, 유지보수 범위가 계약서에 없어서 발생합니다.
국내에는 과기정통부·한국인공지능·소프트웨어산업협회가 안내하는 SW분야 표준계약서와 공정거래위원회의 표준하도급계약서가 존재합니다. 다만 민간 스타트업의 앱·SaaS·관리자 시스템 계약에서는 표준 양식을 그대로 쓰기보다 프로젝트별 산출물, 검수 기준, 서버·계정 인수, 유지보수 별첨을 보완해야 합니다. ([sw.or.kr](https://www.sw.or.kr/site/sw/ex/board/View.do?bcIdx=48892&cbIdx=292&utm_source=openai))
외주개발 계약 전 준비물: 계약서는 요구사항 정리 수준을 넘지 못합니다
계약서를 잘 쓰려면 먼저 발주자가 정리해야 할 자료가 있습니다. 100페이지 기획서가 필요하다는 뜻은 아닙니다. 최소한 아래 항목은 견적 요청 전 한 번은 표로 정리해야 합니다.
| 준비물 | 실무 작성 기준 | 계약서 반영 위치 |
|---|---|---|
| 서비스 목적 | 매출, 리드 수집, 예약 운영, 내부 업무 자동화 등 1차 목적을 적습니다. | 계약 목적, 개발 대상 |
| 사용자 유형 | 일반 회원, 관리자, 파트너, 상담원, 슈퍼관리자 등 권한을 구분합니다. | 범위, 권한, 관리자 기능 |
| 핵심 플로우 | 가입→신청→결제→알림→관리자 처리처럼 실제 업무 흐름을 씁니다. | 기능 명세, 검수 기준 |
| 기능 목록 | 이번 MVP에 꼭 필요한 기능과 추후 개발 기능을 분리합니다. | 과업 범위, 제외 범위 |
| 데이터 항목 | 회원정보, 주문, 예약, 상담 이력, 첨부파일, 로그 등 저장 대상을 정합니다. | DB 설계, 개인정보, 백업 |
| 외부 연동 | 결제, 문자, 카카오 알림, 지도, CRM, ERP, LLM API 등 계정 주체를 정합니다. | 연동 범위, 비용 부담, 계정 소유권 |
| 관리자 화면 | 조회, 승인, 환불, 통계, 권한 관리, 엑셀 다운로드 등 운영 기능을 적습니다. | 산출물, 검수 항목 |
| 출시 일정 | 행사일, 지원사업 마감일, 광고 집행일, 심사 일정 등 고정 마감일을 공유합니다. | 마일스톤, 지연 책임 |
견적 금액이 왜 업체마다 다르게 나오는지부터 정리해야 한다면 외주개발 비용 산정 방법을 먼저 참고해 기능, 인력, 일정, 리스크가 견적에 반영되는 구조를 이해하는 것이 좋습니다.

외주개발 계약서 필수 조항 체크리스트
아래 15개 항목은 앱, 웹, SaaS MVP, 관리자 시스템, 예약·매칭·결제 서비스, AI 기능 개발에서 반복적으로 문제가 되는 조항입니다. 업체가 제공한 계약서에 이 항목이 없거나 추상적으로 적혀 있다면 별첨으로 보완하는 것을 권합니다.
| 필수 조항 | 반드시 적을 내용 | 빠지면 생기는 문제 |
|---|---|---|
| 1. 계약 목적과 개발 대상 | 서비스명, 플랫폼, 개발 유형, 이번 계약의 목표 | 홈페이지인지 SaaS인지, MVP인지 정식 서비스인지 해석이 갈립니다. |
| 2. 과업 범위 | 화면, 기능, 관리자, API, 배포, 디자인, 테스트 범위 | 발주자는 당연하다고 생각한 기능이 업체 기준에서는 추가 개발이 됩니다. |
| 3. 제외 범위 | 콘텐츠 입력, 데이터 정제, 앱스토어 심사 대응, 광고 스크립트, 보안 인증 등 | 계약 후 ‘이것도 포함 아니었나요?’라는 비용 분쟁이 생깁니다. |
| 4. 산출물 | 소스코드, 디자인 파일, DB 스키마, API 문서, 배포 문서, 계정 목록 | 완성된 화면은 보이지만 운영·수정 가능한 자료를 받지 못할 수 있습니다. |
| 5. 일정과 마일스톤 | 기획 확정, 디자인 승인, 개발, 테스트, 배포, 검수 일자 | 완료일만 있고 중간 승인 기준이 없어 지연 원인을 특정하기 어렵습니다. |
| 6. 발주자 협조 의무 | 자료 제공, 계정 생성, 정책 승인, 피드백 기한 | 발주자 의사결정 지연이 개발사 지연인지 구분되지 않습니다. |
| 7. 변경관리 | 추가 기능, 정책 변경, 화면 추가, API 변경의 승인·견적·일정 조정 방식 | 구두 요청이 누적되어 서로 다른 범위를 기억합니다. |
| 8. 대금 지급 | 계약금, 중도금, 잔금, 세금계산서, 지급 조건, 보류 가능 사유 | 검수 전 잔금, 미완료 상태의 대금 청구, 지급 지연 분쟁이 생깁니다. |
| 9. 검수 기준 | 검수 기간, 검수 항목, 불합격 기준, 재검수, 승인 방식 | ‘대체로 돌아간다’와 ‘상용 운영 가능하다’ 사이의 간극이 커집니다. |
| 10. 지연과 책임 | 개발사 귀책, 발주자 자료 지연, 외부 API 장애, 앱스토어 심사 지연 등 | 모든 지연을 한쪽 책임으로 몰아 협업이 깨집니다. |
| 11. 소스코드 인수 | 저장소 권한, 브랜치, 빌드 방법, 환경변수, 배포 스크립트, README | 코드 파일을 받아도 다른 개발사가 실행하지 못합니다. |
| 12. 서버·도메인·외부 계정 소유권 | 클라우드, 도메인, 결제, 문자, 지도, AI API 계정의 명의와 비용 부담 | 개발사 계정에 서비스가 묶여 운영 이관이 어려워집니다. |
| 13. 지식재산권과 라이선스 | 맞춤 개발 코드, 기존 모듈, 오픈소스, 상용 라이브러리의 권리 범위 | 수정·재판매·타 서비스 재사용 가능 여부가 불명확해집니다. |
| 14. 개인정보와 보안 | 처리위탁, 접근권한, 로그, 암호화, 파기, 사고 통지, 재위탁 제한 | 개발 중 테스트 데이터나 운영 DB 접근 책임이 불분명해집니다. |
| 15. 하자보수·유지보수·해지 | 하자보수 기간, 유상 유지보수 범위, 장애 대응, 계약 종료 시 인수인계 | 출시 후 수정 요청이 모두 무료인지, 유료인지 다툼이 생깁니다. |
표준계약서와 업체 양식, 무엇이 부족할 수 있나

표준계약서는 공정한 거래의 출발점으로 유용합니다. 하지만 실제 외주개발은 서비스마다 데이터 흐름, 외부 연동, 관리자 권한, 운영 방식이 다르기 때문에 계약서 본문보다 별첨 문서가 더 중요해지는 경우가 많습니다.
| 문서 유형 | 장점 | 보완해야 할 부분 |
|---|---|---|
| 단순 견적서 | 금액과 큰 기능 범위를 빠르게 확인할 수 있습니다. | 검수, 산출물, 계정 소유권, 변경관리, 유지보수 조항이 부족한 경우가 많습니다. |
| 일반 용역계약서 | 대금, 기간, 비밀유지, 해지 등 기본 조항을 담을 수 있습니다. | 소스코드, 배포, API, 관리자, 개인정보 처리 같은 개발 특화 조항을 추가해야 합니다. |
| SW 표준계약서 | 소프트웨어 거래의 기본 구조를 잡는 데 도움이 됩니다. | 프로젝트별 기능 목록, 검수 기준, 서비스 운영 구조를 별첨으로 구체화해야 합니다. |
| 프로젝트 별첨 | 실제 분쟁을 줄이는 가장 구체적인 문서입니다. | 계약서 본문과 충돌하지 않도록 우선순위와 변경 절차를 정해야 합니다. |
정부지원사업으로 MVP를 개발하는 경우에는 계약서와 함께 사업계획서의 기능목록, 견적서, 개발 로드맵도 일관되어야 합니다. 초기창업패키지를 준비 중이라면 초기창업패키지 사업계획서 개발 범위, 예비창업패키지 단계라면 예비창업패키지 MVP 범위 설정 가이드를 함께 확인하면 계약 범위를 과제 목표와 맞추는 데 도움이 됩니다.
검수 조항: ‘완료’의 의미를 숫자와 시나리오로 바꾸기
검수는 화면이 예쁘게 나왔는지 보는 절차가 아닙니다. 실제 사용자가 가입하고, 결제하고, 예약하고, 알림을 받고, 관리자가 처리하고, 데이터가 저장되는지를 확인하는 절차입니다. 검수 조항에는 최소한 다음 네 가지가 들어가야 합니다.
- 검수 대상: 사용자 화면, 관리자 화면, API, 알림, 결제, 데이터, 권한, 배포 환경
- 검수 방법: 테스트 계정, 테스트 결제, 관리자 승인, 엑셀 다운로드, 로그 확인 등
- 불합격 기준: 핵심 플로우 중단, 데이터 누락, 권한 오류, 결제 오류, 보안상 위험
- 재검수 절차: 보완 요청 방식, 보완 기한, 재검수 기간, 최종 승인 방식
| 서비스 예시 | 검수 기준 예시 | 증빙 방식 |
|---|---|---|
| 예약 서비스 | 예약 생성, 중복 예약 방지, 취소, 관리자 승인, 알림 발송이 정상 동작해야 합니다. | 테스트 예약 로그, 관리자 화면 캡처, 알림 수신 기록 |
| 매칭 서비스 | 회원 유형별 권한, 매칭 신청, 승인·거절, 메시지 또는 알림 흐름이 확인되어야 합니다. | 역할별 테스트 계정, 매칭 상태 변경 기록 |
| SaaS 구독 서비스 | 요금제, 결제 성공·실패, 구독 상태 변경, 관리자 조회, 권한 제한이 동작해야 합니다. | 결제 테스트 내역, DB 상태, 관리자 로그 |
| AI 문의 자동화 | 지정된 지식베이스 기준 답변, 상담 이관 조건, 로그 저장, 민감정보 차단 기준을 확인해야 합니다. | 질문 세트, 답변 로그, 예외 처리 기록 |
소스코드와 지식재산권: ‘돈 냈으니 당연히 우리 것’이라고 쓰면 위험합니다
외주개발에서 가장 많이 놓치는 부분이 소스코드와 지식재산권입니다. 저작권법은 업무상저작물의 저작자, 저작재산권의 양도, 프로그램 저작물의 권리 관계를 별도로 다룹니다. 따라서 개발비를 지급했다는 사실만으로 저장소 권한, 수정 권한, 2차 개발 권한, 기존 모듈 사용권까지 모두 정리되었다고 단정하지 말고 계약서에 권리 범위를 명시해야 합니다. ([law.go.kr](https://law.go.kr/LSW/LsiJoLinkP.do?languageType=KO&lsNm=%EC%A0%80%EC%9E%91%EA%B6%8C%EB%B2%95&utm_source=openai))
실무에서는 맞춤 개발 결과물, 개발사가 기존에 보유한 공통 모듈, 오픈소스 라이브러리, 유료 API, 디자인 리소스를 분리해서 봐야 합니다. 예를 들어 결제 모듈, 관리자 템플릿, 인증 모듈, 배포 자동화 스크립트가 개발사의 기존 자산이라면 발주자가 독점 소유권을 요구하기 어렵거나 별도 비용이 필요할 수 있습니다. 반대로 발주자의 핵심 비즈니스 로직, DB 구조, 고유 UI, 자동화 규칙은 운영 이관 가능성을 고려해 이용 범위를 분명히 해야 합니다.
소스코드 인수 조항에 들어갈 항목
- Git 저장소 소유권 또는 관리자 권한
- 최종 배포 버전의 브랜치와 태그
- 로컬 실행 방법과 빌드 방법
- 환경변수 목록과 비밀키 전달 방식
- DB 스키마, 마이그레이션 파일, 샘플 데이터
- 배포 문서, CI/CD 설정, 롤백 방법
- 클라우드 인프라 구조와 비용 발생 리소스 목록
- 외부 API, 결제, 문자, 이메일, 지도, AI 모델 계정 정보
- 오픈소스 및 상용 라이선스 목록
- 인수인계 미팅, 녹화본, 운영 매뉴얼 제공 여부
개발사가 소스코드 전체 이전을 원하지 않는 SaaS 공급형 거래라면, 소스코드와 기술정보를 제3기관에 맡겨 두는 SW 임치도 대안이 될 수 있습니다. 저작권법 제101조의7은 프로그램의 원시코드와 기술정보 임치 근거를 두고 있고, 한국저작권위원회도 SW임치 제도를 안내하고 있습니다. ([law.go.kr](https://www.law.go.kr/LSW/lsLawLinkInfo.do?chrClsCd=010202&lsJoLnkSeq=1000752160&utm_source=openai))
서버·도메인·계정 소유권: 소스코드보다 먼저 확인해야 할 운영 권한
실제 운영에서는 소스코드보다 계정 권한이 더 급합니다. 도메인, 클라우드, DB, 파일 저장소, 결제 PG, 문자, 이메일, 카카오 알림, 지도, 앱스토어, 플레이스토어, LLM API 계정이 개발사 명의로만 되어 있으면 발주자는 서비스를 직접 운영하거나 다른 개발사로 이전하기 어렵습니다.
| 계정 유형 | 권장 확인 사항 | 계약서 문구 방향 |
|---|---|---|
| 도메인 | 등록자, 관리자 이메일, 만료일, DNS 접근 권한 | 발주자 명의 등록 또는 계약 종료 시 이전 의무 |
| 클라우드 | AWS, GCP, Azure, Naver Cloud 등 루트 계정과 결제 수단 | 발주자 소유 계정 사용, 개발사는 작업 권한 부여 |
| 결제·문자·알림 | PG 계약 주체, API 키, 발송 단가, 정산 계좌 | 발주자 명의 원칙, 테스트·운영 키 분리 |
| 앱스토어 | 개발자 계정, 인증서, 번들 ID, 심사 이력 | 발주자 계정에 앱 등록, 개발사는 초대 계정으로 작업 |
| AI·자동화 API | 모델 제공사 계정, 사용량 과금, 로그 보관, 데이터 사용 조건 | 계정 주체와 비용 부담, 입력 데이터 관리 책임 명시 |
개인정보와 보안: 개발 중 테스트 데이터도 계약 범위입니다
회원가입, 상담 신청, 예약, 결제, 매칭, CRM 연동이 있는 서비스는 개발사가 개인정보에 접근할 가능성이 큽니다. 개인정보 보호법 제26조는 개인정보 처리 업무를 위탁하는 경우 목적 외 처리 금지, 기술적·관리적 보호조치, 공개, 감독, 재위탁 동의 등 문서화와 관리 기준을 요구합니다. ([law.go.kr](https://law.go.kr/lsLawLinkInfo.do?chrClsCd=010202&lsJoLnkSeq=900079876))
계약서에는 최소한 다음 내용을 넣어야 합니다. 첫째, 개발사가 접근할 개인정보 항목과 목적을 제한합니다. 둘째, 운영 DB 접근은 필요한 기간과 담당자로 제한합니다. 셋째, 테스트에는 가급적 가명·샘플 데이터를 사용합니다. 넷째, 계약 종료 후 접근권한 회수와 데이터 파기 또는 반환 증빙을 정합니다. 다섯째, 보안사고 발생 시 통지 기한과 협조 범위를 정합니다.
하자보수와 유지보수: 무료 수정의 범위를 먼저 나누세요
출시 후 모든 요청이 ‘하자’는 아닙니다. 계약 범위에 있던 기능이 명세대로 동작하지 않으면 하자보수에 가깝지만, 정책 변경, 화면 추가, 관리자 통계 추가, 결제 정책 변경, 새로운 AI 프롬프트 설계, 외부 API 교체는 기능 개선 또는 운영지원일 수 있습니다.
| 구분 | 예시 | 계약서에서 정할 것 |
|---|---|---|
| 하자보수 | 명세된 기능 오류, 데이터 저장 누락, 권한 오류, 배포 버그 | 기간, 대상 기능, 접수 방식, 보완 기한, 제외 사유 |
| 운영지원 | 서버 모니터링, 라이브러리 업데이트, 소규모 문구 수정, 백업 확인 | 월 지원 시간, 응답 시간, 작업 범위, 초과 비용 |
| 기능개선 | 새 관리자 통계, 신규 결제수단, 추천 로직, AI 자동 응답 고도화 | 변경요청서, 별도 견적, 일정 재협의 |
| 긴급 장애 대응 | 서비스 접속 불가, 결제 중단, 데이터 손상, 보안 사고 의심 | 장애 등급, 연락 채널, 응답 목표, 야간·휴일 대응 여부 |
KOSA의 SW사업 대가산정 가이드는 소프트웨어 기획, 구현, 운영 등 수명주기 관점에서 대가 산정 기준을 다루고 있습니다. 민간 외주계약에서도 개발비와 운영·유지관리비를 한 덩어리로 보지 말고, 어떤 업무가 구현이고 어떤 업무가 운영인지 나누어 견적과 계약서에 반영하는 것이 합리적입니다. ([swai.or.kr](https://www.swai.or.kr/site/sw/01/10101000000002017062610.jsp?utm_source=openai))

계약서에 바로 반영할 수 있는 문장 예시
아래 문장은 법률 문안이 아니라 실무 협의를 위한 예시입니다. 실제 계약서에 넣기 전에는 거래 구조와 법률 검토에 맞게 조정해야 합니다.
- 범위: 본 계약의 개발 범위는 별첨 기능목록, 화면목록, 관리자 기능목록, 연동 목록에 기재된 항목으로 한정한다.
- 제외 범위: 별첨에 명시되지 않은 신규 화면, 신규 API, 정책 변경, 데이터 입력·정제, 마케팅 콘텐츠 제작은 별도 협의 대상으로 한다.
- 변경관리: 계약 후 기능 추가 또는 범위 변경은 서면 또는 협업툴 기록으로 요청하고, 양 당사자가 비용과 일정 변경에 합의한 경우에만 수행한다.
- 검수: 발주자는 산출물 수령 후 정해진 기간 내 검수 결과를 통지하며, 불합격 항목은 기능명, 재현 절차, 기대 결과를 포함해 전달한다.
- 소스코드: 개발사는 최종 검수 완료 및 대금 지급 후 운영 가능한 최종 소스코드, 배포 문서, DB 스키마, 환경 설정 목록을 발주자에게 인도한다.
- 계정: 도메인, 클라우드, 결제, 문자, 알림, 앱스토어 등 운영 핵심 계정은 원칙적으로 발주자 명의로 생성하고, 개발사는 작업 권한을 부여받아 수행한다.
- 유지보수: 하자보수는 계약 범위 내 기능 오류에 한정하며, 운영지원 및 기능개선은 별도 유지보수 계약 또는 변경요청서에 따른다.
- 개인정보: 개발사는 위탁받은 목적 범위 내에서만 개인정보에 접근하며, 계약 종료 또는 발주자 요청 시 접근권한을 반환·폐기하고 필요한 증빙을 제공한다.
최종 서명 전 30분 체크리스트
계약서 서명 직전에는 아래 질문에 모두 답할 수 있어야 합니다.
- 이번 계약에 포함되는 화면과 기능 목록이 별첨으로 존재하는가?
- 이번 계약에 포함되지 않는 항목도 명시되어 있는가?
- 중간 산출물과 최종 산출물이 구분되어 있는가?
- 검수 기준이 기능명 수준이 아니라 실제 업무 시나리오로 적혀 있는가?
- 발주자 피드백 지연, 자료 제공 지연, 외부 API 지연 시 일정 조정 기준이 있는가?
- 소스코드 저장소, 서버, 도메인, 결제, 앱스토어 계정의 소유자가 정해져 있는가?
- 오픈소스, 상용 라이브러리, 개발사 기존 모듈의 사용 범위가 정리되어 있는가?
- 개인정보 처리위탁, 보안, 접근권한, 계약 종료 후 파기 기준이 있는가?
- 하자보수와 유상 유지보수의 경계가 정리되어 있는가?
- 계약 종료 또는 분쟁 시 인수인계와 서비스 중단 방지 절차가 있는가?
AgentMit이 계약 전 기술 검토에서 보는 것
AgentMit은 계약서 법률 검토를 대신하지 않습니다. 다만 외주개발 계약 전 기술 관점에서 범위가 빠졌는지, 견적이 과소 또는 과대 산정될 위험이 있는지, MVP 이후 운영 가능한 구조인지 검토할 수 있습니다. 특히 SaaS, 관리자 시스템, 예약·결제·매칭 서비스, 업무 자동화, AI 기능 개발처럼 운영 흐름이 복잡한 프로젝트는 계약 전 범위 정의가 실제 개발비와 유지보수 리스크를 크게 좌우합니다.
AgentMit은 요구사항 정리, MVP 기능목록, UI, 백엔드, 관리자 대시보드, 자동화, AI 기능, 배포, 유지보수까지 연결해 실제 서비스 운영 기준으로 개발 범위를 잡습니다. 단순히 저렴한 견적을 맞추는 것보다, 출시 후 발주자가 서비스를 직접 운영하고 개선할 수 있는 구조를 만드는 데 초점을 둡니다. 계약 전 기능 범위 검토나 MVP 견적 산정이 필요하다면 AgentMit 제작 문의로 현재 기획서, 참고 서비스, 희망 출시일을 공유해 주세요.
FAQ
Q1. 외주개발 계약서에 소스코드 양도 조항을 꼭 넣어야 하나요?
운영을 직접 하거나 다른 개발사로 이관할 가능성이 있다면 반드시 넣는 편이 안전합니다. 소스코드, DB 스키마, 배포 문서, 계정 권한, 이용허락 또는 양도 범위를 분리해 적어야 합니다.
Q2. 외주개발 검수 기준은 어떻게 써야 하나요?
기능명만 적지 말고 정상 시나리오, 예외 시나리오, 관리자 처리 기준, 결제·알림·권한·데이터 저장 기준을 함께 적어야 합니다. 검수 기간과 재검수 절차도 필요합니다.
Q3. 하자보수와 유지보수는 무엇이 다른가요?
하자보수는 계약 범위의 기능 오류를 고치는 것이고, 유지보수는 출시 후 운영지원, 업데이트, 장애 대응, 개선 요청을 포함할 수 있습니다. 기능 추가는 별도 개발로 보는 경우가 많습니다.
Q4. 외주개발 추가 비용 분쟁을 줄이려면 어떤 조항이 필요하나요?
변경관리 조항이 핵심입니다. 계약 범위에 없는 기능, 화면 추가, 외부 API 연동, 정책 변경은 별도 견적 또는 일정 조정 대상임을 명시해야 합니다.
Q5. 개인정보를 다루는 서비스도 개발용역계약서만 있으면 되나요?
개발사가 개인정보에 접근하거나 처리한다면 개인정보 처리위탁 관련 조항 또는 별도 문서가 필요합니다. 위탁 업무 범위, 보안조치, 재위탁 제한, 사고 통지, 파기·반환 기준을 반영해야 합니다.
참고자료
아래 자료는 2026년 6월 10일 기준으로 외주개발 계약 실무 항목을 정리하는 데 참고했습니다. 실제 계약에는 거래 형태와 최신 법령 변경이 반영되어야 합니다.
- 과기정통부·한국인공지능·소프트웨어산업협회 SW분야 표준계약서 안내: SW 표준계약서 존재와 활용 범위 확인. ([sw.or.kr](https://www.sw.or.kr/site/sw/ex/board/View.do?bcIdx=48892&cbIdx=292&utm_source=openai))
- 공정거래위원회 표준하도급계약서 및 SW 업종 표준하도급계약서 자료: 하도급형 SW 거래의 계약 구조 참고. ([ftc.go.kr](https://www.ftc.go.kr/www/selectBbsNttList.do?bordCd=202&key=203&pageIndex=2&pageUnit=10&searchCnd=all&utm_source=openai))
- 저작권법 제9조, 제45조, 제101조의7: 업무상저작물, 저작재산권 양도, 프로그램 임치 관련 쟁점 확인. ([law.go.kr](https://law.go.kr/LSW/LsiJoLinkP.do?languageType=KO&lsNm=%EC%A0%80%EC%9E%91%EA%B6%8C%EB%B2%95&utm_source=openai))
- 개인정보 보호법 제26조: 개인정보 처리위탁 문서화와 위탁자 감독 의무 확인. ([law.go.kr](https://law.go.kr/lsLawLinkInfo.do?chrClsCd=010202&lsJoLnkSeq=900079876))
- KOSA SW사업 대가산정 가이드 안내: 기획·구현·운영 단계의 대가 산정 관점 참고. ([swai.or.kr](https://www.swai.or.kr/site/sw/01/10101000000002017062610.jsp?utm_source=openai))

