외주개발 소스코드 에스크로 가이드: 업체 교체·파산·유지보수 리스크를 줄이는 인수 기준
외주개발 리스크 관리
외주개발 소스코드 에스크로 가이드: 업체 교체·파산·유지보수 리스크를 줄이는 인수 기준
결론부터 말하면, 외주개발로 만든 웹·앱·SaaS·관리자 시스템은 Git 저장소만 받아서는 안전하게 인수했다고 보기 어렵습니다. 서비스가 계속 운영되려면 소스코드, 빌드 방법, 배포 파이프라인, DB 스키마, 서버 권한, API 키 관리 방식, 외부 라이선스, 운영 문서가 함께 재현 가능해야 합니다. 소스코드 에스크로 또는 국내 SW임치는 이 산출물을 제3자에게 보관해 두고, 개발업체의 폐업·유지보수 불이행·분쟁 같은 조건이 발생했을 때 발주사가 운영을 이어갈 수 있게 만드는 사업 지속성 장치입니다.
이 글은 법률 의견이 아니라 외주개발 의사결정자를 위한 실무 기준입니다. 실제 계약 문구와 권리 귀속은 변호사 검토가 필요하지만, 대표·PM·마케터·운영자가 견적 단계에서 무엇을 요구해야 하는지는 충분히 정리할 수 있습니다.

1. 소스코드 에스크로와 국내 SW임치, 무엇이 다른가
소스코드 에스크로는 일반적으로 개발사 또는 솔루션 공급사가 소스코드와 기술자료를 신뢰할 수 있는 제3자에게 맡겨 두는 구조를 말합니다. 발주사는 평상시에는 개발사의 영업비밀을 침해하지 않으면서도, 약정한 사유가 생기면 필요한 자료를 받아 유지보수를 이어갈 수 있습니다.
국내에는 저작권법 제101조의7에 근거한 프로그램 임치 제도가 있습니다. 해당 조항은 프로그램 저작재산권자와 이용허락을 받은 자가 서로 합의해 프로그램의 원시코드와 기술정보 등을 수치인에게 임치할 수 있고, 합의에서 정한 사유가 발생하면 이용허락을 받은 자가 원시코드와 기술정보 제공을 요구할 수 있다고 정합니다. 시행령 제39조의2는 이 수치인을 위원회로 규정합니다. ([law.go.kr](https://www.law.go.kr/LSW/lsLawLinkInfo.do?chrClsCd=010202&lsJoLnkSeq=1000752160))
한국저작권위원회 SW임치 안내에 따르면 임치 대상은 소스프로그램뿐 아니라 오브젝트프로그램, 실행프로그램, 설계서·사양서, 플로차트, 매뉴얼, 유지보수 자료, 개발기술자 정보 등을 포함할 수 있습니다. IT 분야 대상물로 데이터베이스와 디지털콘텐츠, 계약 당사자 간 협의한 핵심 기술자료도 제시됩니다. 안내 페이지에는 온라인 또는 방문 계약 방식과 함께 신규 계약, 갱신 계약, 최신본 임치 수수료도 공지되어 있으므로 실제 진행 전 최신 내용을 확인해야 합니다. ([copyright.or.kr](https://www.copyright.or.kr/business/sw-deposit/index.do))
핵심은 ‘코드를 받느냐’가 아니라 ‘다른 개발자가 해당 서비스를 다시 빌드하고 배포하고 운영할 수 있느냐’입니다.
2. 모든 외주개발에 에스크로가 필요한 것은 아니다
랜딩페이지, 회사소개 웹사이트, 단순 예약 폼처럼 발주사가 CMS 계정과 호스팅 권한을 보유하고 있고 코드 변경 빈도가 낮은 프로젝트라면 전체 임치보다 직접 인수인계가 현실적일 수 있습니다. 반면 고객 데이터, 결제, 정산, 관리자 권한, 자동화 로직, AI API 비용이 얽힌 서비스라면 개발사가 사라지는 순간 매출과 운영이 멈출 수 있습니다.
| 프로젝트 유형 | 운영 리스크 | 권장 인수 방식 |
|---|---|---|
| 회사 홈페이지·브랜드 랜딩 | 낮음. 콘텐츠 수정과 서버 갱신이 중심 | 저장소, 호스팅, 도메인, CMS 관리자 권한 직접 인수 |
| 예약·매칭·문의 관리 시스템 | 중간. 고객 데이터와 알림, 관리자 업무가 연결 | 직접 인수에 더해 빌드·배포 문서와 정기 산출물 보관 |
| 결제·정산·CRM·SaaS 관리자 | 높음. 장애 시 매출·정산·고객지원 중단 가능 | 소스코드 에스크로 또는 SW임치, 검증 테스트, 교체 권한 명시 |
| AI 자동화·RAG·챗봇 서비스 | 높음. 프롬프트, 벡터DB, API 키, 평가 기준까지 의존 | 코드와 함께 프롬프트 버전, 데이터 파이프라인, 모델 설정, 비용 한도 문서화 |
| 개발사 자체 솔루션 기반 SaaS | 상황별. 발주사가 전체 소스 소유자가 아닐 수 있음 | 소유권 이전보다 릴리즈 조건, 사용권, 데이터 반출, 대체 운영권 협의 |
초기 스타트업은 비용 때문에 이 절차를 뒤로 미루기 쉽습니다. 그러나 서비스가 출시되고 고객 데이터가 쌓인 뒤에는 협상력이 줄어듭니다. 특히 정부지원사업으로 만든 MVP가 선정 이후 실서비스로 전환되거나 투자 실사 대상이 되는 경우, 단순 시연 화면보다 저장소 구조와 운영 가능성이 더 중요해집니다.
3. 에스크로는 계약서 조항이 아니라 운영 프로세스다
실무에서 자주 생기는 문제는 ‘계약서에는 소스코드 제공이라고 되어 있는데 실제로는 빌드가 안 되는 코드만 받은 경우’입니다. 에스크로를 제대로 설계하려면 계약 전 정의, 개발 중 갱신, 출시 전 검증, 유지보수 중 최신본 반영, 릴리즈 조건 발생 시 교부 절차까지 이어져야 합니다.

- 계약 전: 임치 또는 인수 대상 산출물을 기능 범위와 함께 정의합니다. 자체 솔루션, 오픈소스, 상용 라이브러리, 발주사 전용 코드의 경계를 나눕니다.
- 개발 중: 저장소 브랜치, 태그, 릴리즈 노트, DB 마이그레이션 파일, 환경변수 템플릿을 정리합니다.
- 마일스톤 검수: 스테이징 환경에서 새 개발자가 문서만 보고 빌드·배포할 수 있는지 확인합니다.
- 출시 시점: 운영 버전의 커밋 해시, 컨테이너 이미지, 배포 스크립트, 관리자 계정, 외부 API 목록을 확정합니다.
- 유지보수 기간: 주요 릴리즈, 보안 패치, 인프라 변경, 결제·알림 연동 변경 후 최신본을 갱신합니다.
- 릴리즈 조건 발생: 계약에서 정한 폐업, 유지보수 불이행, 중대한 계약 위반, 장기간 연락 두절 등 조건과 절차에 따라 자료를 교부받습니다.
해외 공공 조달 가이드에서도 소스코드 에스크로는 최신 버전, 기술 스택, 개발·테스트·지원에 필요한 도구와 버전, 문서, 빌드 지침, DB 스키마, 컴파일 테스트, 운영 가능성 테스트까지 포함해 검증하는 구조로 다뤄집니다. 한국의 중소 프로젝트에 그대로 적용할 필요는 없지만, ‘보관’보다 ‘검증’이 중요하다는 점은 동일합니다. ([vita.virginia.gov](https://www.vita.virginia.gov/media/vitavirginiagov/supply-chain/pdf/Guidance-on-Source-Code-Escrow-2025-02-27.pdf))
4. 직접 인수, 에스크로, 하이브리드 방식 비교
발주사가 꼭 선택해야 하는 것은 하나의 방식이 아닙니다. 프로젝트의 지식재산권 구조와 운영 중요도에 따라 직접 인수와 에스크로를 조합할 수 있습니다.

| 방식 | 적합한 경우 | 장점 | 주의할 점 |
|---|---|---|---|
| 직접 인수 | 발주사 전용 개발이고 소스 소유권과 클라우드 계정을 발주사가 보유 | 교체 개발사가 바로 접근 가능. 투명성이 높음 | 비밀키, 배포 권한, 운영 문서가 빠지면 저장소만 있어도 무용지물 |
| 소스코드 에스크로·SW임치 | 개발사가 핵심 기술을 보유하거나 평상시 전체 소스 공개가 어려운 솔루션 | 개발사의 영업비밀과 발주사의 운영 지속성을 동시에 고려 가능 | 교부 조건과 사용 범위가 애매하면 분쟁 시 실효성이 낮음 |
| 하이브리드 | 발주사 전용 기능은 직접 인수하고, 개발사 공통 모듈은 제한적 임치 | 스타트업 MVP와 SaaS 외주에서 현실적인 타협안 | 어떤 모듈이 발주사 전용인지, 교체 개발사가 어디까지 수정 가능한지 명시 필요 |
AgentMit이 MVP·SaaS·관리자 시스템을 검토할 때도 먼저 묻는 것은 ‘소스코드를 줄 수 있느냐’가 아니라 ‘운영 책임을 누가 어느 계정과 문서로 이어받을 수 있느냐’입니다. 이 관점이 있어야 견적서의 개발 범위와 유지보수 범위가 현실적으로 나뉩니다.
5. Git 저장소 외에 반드시 확보해야 할 산출물
OWASP의 소프트웨어 구성요소 검증 기준은 빌드 파이프라인이 소스코드 저장소, 패키지 저장소, CI/CD, 테스트 절차, 이를 가능하게 하는 네트워크 인프라와 서비스까지 포함될 수 있다고 설명합니다. 또한 반복 가능한 빌드와 빌드 반복 지침 문서화를 검증 항목으로 둡니다. 즉, 저장소 링크 하나로는 실제 운영 가능성을 입증하기 어렵습니다. ([scvs.owasp.org](https://scvs.owasp.org/scvs/v3-build-environment/))
| 구분 | 확보할 내용 | 검수 질문 |
|---|---|---|
| 소스 저장소 | Git 원격 저장소, 브랜치 전략, 태그, 릴리즈 노트, 커밋 권한 | 운영 버전이 어떤 커밋인지 특정할 수 있는가? |
| 빌드 환경 | Node, Java, Python, PHP, Flutter 등 런타임 버전, 빌드 명령, lock 파일 | 새 노트북이나 깨끗한 컨테이너에서 빌드되는가? |
| 패키지·라이선스 | 오픈소스 목록, 상용 라이브러리 계약, 폰트·템플릿 라이선스, SBOM 가능 여부 | 상용 라이브러리 만료나 라이선스 위반 위험이 없는가? |
| 환경설정 | .env.example, 설정 키 설명, 운영·스테이징 분리 기준 | 실제 비밀키를 코드에 넣지 않고 안전하게 이전할 수 있는가? |
| DB | ERD, 마이그레이션, 시드 데이터, 데이터 사전, 백업·복원 절차 | 운영 DB를 새 환경에 복원하거나 익명화 샘플로 재현할 수 있는가? |
| 인프라 | 클라우드 계정, 서버 목록, 컨테이너, 스토리지, CDN, DNS, IaC 파일 | 개발사 개인 계정이 아닌 발주사 소유 계정에서 운영되는가? |
| 배포 | CI/CD 설정, 배포 스크립트, 롤백 절차, 배포 권한 | 장애 발생 시 이전 버전으로 되돌릴 수 있는가? |
| 외부 연동 | PG, 카카오·네이버·구글 로그인, 문자, 이메일, 지도, AI API, 웹훅 | API 키 소유자와 과금 계정이 발주사인지 확인했는가? |
| 관리자 | 관리자 역할, 권한표, 계정 생성 방법, 감사 로그 위치 | 운영자가 개발자 없이 필수 업무를 처리할 수 있는가? |
| 테스트 | 테스트 계정, 주요 시나리오, 자동화 테스트, 결제 샌드박스 | 회원가입·결제·정산·알림·관리자 기능을 반복 검증할 수 있는가? |
| 운영 문서 | 장애 대응, 로그 위치, 모니터링, 백업 주기, 문의 처리 루틴 | 새 유지보수 업체가 첫 주에 장애를 추적할 수 있는가? |
SBOM은 모든 초기 프로젝트에 의무적으로 요구할 산출물은 아니지만, SaaS·B2B·공공 납품·투자 실사 가능성이 있는 서비스에서는 검토 가치가 있습니다. NIST는 SBOM을 소프트웨어 구성요소와 공급망 관계를 담은 공식 기록으로 설명하며, 취약점 식별과 공급망 투명성을 높이는 도구로 다룹니다. ([nist.gov](https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20))
일반 인수인계 범위를 먼저 정리하려면 외주개발 인수인계 체크리스트를 함께 확인하면 좋습니다. 에스크로는 이 체크리스트 중 운영 지속성에 필요한 항목을 제3자 보관과 릴리즈 조건으로 확장한 구조라고 보면 됩니다.
6. 계약서에는 ‘소유권’보다 ‘사용 가능한 권리’를 써야 한다
외주개발 분쟁에서 자주 나오는 문장은 ‘소스코드는 발주사 소유로 한다’입니다. 하지만 이 한 문장만으로 충분하지 않습니다. 소유권, 저작재산권 양도, 이용허락, 2차적 개발, 유지보수 업체에 대한 제공 권한, 개발사 공통 모듈 사용권, 오픈소스 의무는 서로 다른 문제입니다.
계약 단계에서는 최소한 다음 조항을 별도로 검토해야 합니다.
- 산출물 정의: 소스코드, 디자인 원본, DB 스키마, 문서, 배포 스크립트, 테스트 자료, 운영 매뉴얼을 구체적으로 적습니다.
- 권리 귀속: 발주사 전용 코드와 개발사 기존 자산, 오픈소스, 상용 라이브러리를 구분합니다.
- 사용 범위: 발주사가 자체 운영, 유지보수 업체 교체, 기능 추가, 서버 이전을 할 수 있는지 정합니다.
- 에스크로·임치 대상: 맡길 파일과 문서, 갱신 주기, 최신본 기준, 검증 방법을 정합니다.
- 교부 조건: 폐업·파산뿐 아니라 유지보수 불이행, 중대한 장애 미대응, 연락 두절, 계약 위반의 판단 기준을 둡니다.
- 비밀정보: 실제 운영 비밀키와 개인정보를 어떤 방식으로 제외하거나 안전하게 이전할지 정합니다.
- 비용 부담: 임치 수수료, 검증 비용, 갱신 비용, 교부 후 지원 비용의 부담 주체를 정합니다.
- 종료 시 인수인계: 계약 종료 후 자료 제공 기한, 질의응답 기간, 계정 이전, 데이터 반출 형식을 정합니다.
계약 조항 자체를 점검하려면 외주개발 계약서 필수 조항 체크리스트와 함께 보되, 소스코드 에스크로가 필요한 프로젝트라면 ‘인수 가능한 산출물’과 ‘릴리즈 후 사용권’을 별도 부속합의서로 분리하는 편이 실무적으로 명확합니다.
7. 운영 가능한지 확인하는 인수 테스트 기준
에스크로의 품질은 계약서가 아니라 테스트로 드러납니다. 납품 전 또는 주요 릴리즈 시점에 아래 테스트를 해보면, 실제로 다른 개발사가 이어받을 수 있는지 확인할 수 있습니다.
- 클린 빌드 테스트: 기존 개발자 노트북이 아닌 새 환경에서 문서만 보고 설치·빌드합니다.
- DB 재현 테스트: 마이그레이션 파일로 빈 DB를 구성하고, 샘플 데이터로 주요 화면을 확인합니다.
- 스테이징 배포 테스트: 운영과 분리된 환경에 배포하고 도메인·HTTPS·스토리지·알림을 확인합니다.
- 핵심 업무 시나리오: 회원가입, 로그인, 예약, 결제, 취소, 정산, 관리자 승인, 알림 발송 등 매출과 운영에 직결되는 흐름을 검증합니다.
- 권한 테스트: 슈퍼관리자, 운영자, 파트너, 일반 사용자 권한을 나누어 접근 제한을 확인합니다.
- 비밀키 교체 테스트: API 키와 DB 비밀번호를 새 값으로 바꿔도 서비스가 정상 동작하는지 봅니다.
- 백업·복원 테스트: 백업 파일로 스테이징 DB를 복원하고 데이터 무결성을 점검합니다.
- 롤백 테스트: 배포 실패 또는 장애 상황에서 이전 버전으로 되돌리는 절차를 확인합니다.
외주개발 유지보수 계약까지 연결된다면 장애 등급, 응답 시간, 무상 하자보수와 운영 지원의 경계를 함께 정해야 합니다. 이 부분은 외주개발 유지보수 SLA 설계 가이드와 함께 보면 에스크로의 릴리즈 조건을 더 현실적으로 잡을 수 있습니다.
8. 발주사가 견적 전 준비할 체크리스트

소스코드 에스크로는 개발이 끝난 뒤 갑자기 요구하면 갈등이 커집니다. 견적 요청서나 요구사항 정의서 단계에서 아래 질문을 먼저 정리해 두면 업체도 범위와 비용을 더 정확히 산정할 수 있습니다.
| 질문 | 발주사 준비 내용 |
|---|---|
| 서비스가 중단되면 하루에 어떤 손실이 생기는가? | 예약·결제·고객응대·내부 업무 중단 범위를 적습니다. |
| 발주사가 반드시 직접 보유해야 할 계정은 무엇인가? | 도메인, 클라우드, PG, 문자, 이메일, 앱스토어, AI API 계정을 나열합니다. |
| 개발사 기존 자산을 사용할 수 있는가? | 템플릿, 공통 관리자, 내부 프레임워크 사용 여부와 권리 범위를 확인합니다. |
| 교체 개발사가 수정해야 할 가능성이 높은 영역은 어디인가? | 관리자, 정산, 알림, 리포트, 권한, 자동화 로직을 우선순위로 표시합니다. |
| 개인정보나 영업비밀 데이터가 임치물에 포함되는가? | 운영 데이터 대신 익명화 샘플과 스키마를 제공할 수 있는지 검토합니다. |
| 최신본 갱신 주기는 어느 정도가 필요한가? | 매 릴리즈, 월 1회, 분기 1회, 기능 고도화 종료 시점 중 선택합니다. |
| 인수 테스트에 누가 참여할 것인가? | 대표, PM, 운영자, 외부 기술검토자, 유지보수 후보 업체의 역할을 정합니다. |
발주사가 준비해야 할 자료는 거창하지 않습니다. 필수 기능 목록, 화면 흐름, 데이터 흐름, 관리자 역할, 참고 서비스, 외부 연동 목록, 출시 마감일, 검수 기준을 정리하면 됩니다. 이 자료가 있어야 개발업체가 ‘소스코드 제공 가능’이라는 추상 답변 대신 ‘어떤 산출물을 언제 어떤 형태로 넘길 수 있는지’를 제시할 수 있습니다.
9. 개발업체가 거부할 때 볼 신호
개발업체가 전체 소스 공개나 임치를 조심스러워하는 것은 항상 나쁜 신호가 아닙니다. 자체 솔루션, 공통 모듈, 라이선스가 포함되어 있으면 무제한 양도는 어려울 수 있습니다. 문제는 발주사의 운영 지속성에 필요한 최소 범위까지 불명확하게 만드는 경우입니다.
- 저장소 제공은 가능하지만 빌드 방법은 내부 노하우라며 문서화를 거부합니다.
- 클라우드와 도메인을 개발사 개인 또는 업체 계정으로만 운영하겠다고 합니다.
- DB 스키마와 데이터 반출 형식을 설명하지 않습니다.
- PG, 문자, 이메일, AI API 키를 개발사 공용 계정으로 묶어 둡니다.
- 앱스토어, Firebase, 지도 API, 소셜 로그인 권한 이전 계획이 없습니다.
- 오픈소스·상용 라이브러리 목록을 제공하지 않습니다.
- 유지보수 종료 시 질의응답 기간이나 장애 인수 기준을 정하지 않습니다.
반대로 좋은 개발 파트너는 모든 것을 무조건 넘긴다고 말하기보다, 발주사 전용 코드와 개발사 자산을 구분하고, 운영에 필요한 권한·문서·릴리즈 조건을 현실적으로 제안합니다. 스타트업 입장에서는 이 차이가 단기 견적보다 더 중요할 수 있습니다.
10. AgentMit 관점: 인수 가능한 구조까지 개발 범위에 넣어야 한다
AgentMit은 MVP, 웹·앱 서비스, SaaS, 관리자 시스템, 업무 자동화, AI 기능 개발을 검토할 때 기능 구현만 보지 않습니다. 요구사항 정의, UI, 백엔드, 관리자 권한, 외부 API, 배포 환경, 운영 문서, 유지보수 체계가 이어져야 실제 서비스가 됩니다. BizMit 기반의 업무 시스템이나 정부지원사업 MVP도 마찬가지입니다. 데모가 아니라 운영을 목표로 한다면 처음부터 저장소 구조와 빌드·배포·계정 소유권을 설계해야 합니다.
이미 외주개발이 진행 중이라면 지금이라도 늦지 않습니다. 다음 세 가지만 먼저 확인해 보세요. 첫째, 운영 버전의 소스코드 위치와 커밋을 특정할 수 있는지. 둘째, 개발사 없이 스테이징 환경에 배포할 수 있는 문서가 있는지. 셋째, 클라우드·도메인·PG·API 키의 최종 소유자가 발주사인지. 이 세 가지가 불분명하면 개발업체 교체, 투자 실사, 유지보수 종료 시점에 비용이 크게 늘어날 수 있습니다.
새 MVP나 SaaS 개발을 준비 중이거나 기존 외주 산출물의 인수 가능성을 점검해야 한다면, AgentMit에 범위 검토를 요청해 보셔도 좋습니다. 단순히 ‘개발비가 얼마인가’보다 ‘어떤 산출물을 어떤 계정과 문서로 인수할 것인가’를 함께 정리하면 재개발 위험을 줄일 수 있습니다. AgentMit 개발 상담 요청하기
자주 묻는 질문
Q1. 외주개발 소스코드 에스크로와 소프트웨어 임치는 같은 건가요?
비슷한 목적을 가진 개념이지만 표현과 제도 범위가 다릅니다. 소스코드 에스크로는 제3자에게 소스와 기술자료를 맡겨 두는 일반적 표현이고, 국내에서는 저작권법상 프로그램 임치 제도가 운영됩니다. 실무에서는 계약서에 임치 대상, 최신본 갱신 주기, 교부 조건, 교부 후 사용 범위를 함께 정해야 합니다.
Q2. GitHub 저장소와 서버 계정만 받으면 충분한가요?
대부분의 웹·앱·SaaS에서는 부족합니다. 저장소 외에도 빌드 명령, 런타임 버전, 패키지 잠금 파일, 환경변수 템플릿, DB 마이그레이션, 배포 파이프라인, 클라우드 권한, 외부 API 계정, 운영 문서가 있어야 다른 개발자가 재현하고 유지보수할 수 있습니다.
Q3. 소스코드 소유권을 발주사로 명시하면 에스크로가 필요 없나요?
항상 그렇지는 않습니다. 발주사가 저장소와 클라우드 권한을 직접 보유하고 최신 코드와 문서를 지속적으로 받을 수 있다면 별도 에스크로 필요성이 낮아질 수 있습니다. 반대로 개발사가 공통 프레임워크나 자체 솔루션을 사용하고 소스 전체를 즉시 넘기기 어렵다면 임치 또는 제한적 릴리즈 구조가 현실적입니다.
Q4. MVP나 정부지원사업 프로젝트도 소스코드 에스크로를 해야 하나요?
서비스가 데모 수준이면 전체 임치보다 인수인계 체크리스트와 저장소 권한 확보가 우선입니다. 다만 선정 이후 실사용 고객, 결제, 개인정보, 관리자 운영이 들어가는 MVP라면 정부지원사업 종료 후 유지보수와 기술 실사를 대비해 빌드·배포·DB·계정 인수 기준을 계약 단계에서 정하는 것이 좋습니다.
Q5. 개발업체가 소스코드 에스크로를 거부하면 어떻게 판단해야 하나요?
무조건 나쁜 신호로 보기는 어렵습니다. 업체가 자체 솔루션을 보유했거나 공통 모듈을 재사용하는 경우 전체 소스 공개를 제한할 수 있습니다. 그러나 발주사의 서비스 운영에 필요한 범위, 장애 시 교체 권한, 데이터 반출, 빌드 가능한 산출물, 문서 제공까지 거부한다면 운영 리스크가 크므로 계약 구조를 다시 검토해야 합니다.
참고한 공개 자료
- 한국저작권위원회 SW임치 안내: 임치 제도의 개요, 대상물, 신청 방식, 수수료 기준을 확인했습니다. ([copyright.or.kr](https://www.copyright.or.kr/business/sw-deposit/index.do))
- 국가법령정보센터 저작권법 제101조의7 및 시행령 제39조의2: 프로그램 임치의 법적 근거와 수치인 규정을 확인했습니다. ([law.go.kr](https://www.law.go.kr/LSW/lsLawLinkInfo.do?chrClsCd=010202&lsJoLnkSeq=1000752160))
- OWASP SCVS V3 Build Environment Requirements: 빌드 환경과 반복 가능한 빌드 문서화 기준을 참고했습니다. ([scvs.owasp.org](https://scvs.owasp.org/scvs/v3-build-environment/))
- NIST SBOM 자료: 소프트웨어 구성요소와 공급망 투명성 관리 관점을 참고했습니다. ([nist.gov](https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20))
- Virginia IT Agency Source Code Escrow Guidance: 해외 공공 조달에서 에스크로 검증과 릴리즈 조건을 다루는 방식을 참고했습니다. ([vita.virginia.gov](https://www.vita.virginia.gov/media/vitavirginiagov/supply-chain/pdf/Guidance-on-Source-Code-Escrow-2025-02-27.pdf))

