외주개발 오픈소스 라이선스·SBOM 점검 가이드: 소스코드 인수 전 확인할 계약·검수 기준
외주개발 오픈소스 라이선스·SBOM 점검 가이드: 소스코드 인수 전 확인할 계약·검수 기준
외주개발에서 오픈소스 리스크를 줄이는 가장 현실적인 방법은 납품 후에 묻는 것이 아니라 견적 단계에서 요구하는 것입니다. 개발사가 어떤 npm·PyPI 패키지, 백엔드 프레임워크, 모바일 SDK, 결제·알림 API, AI 모델, Docker 베이스 이미지를 쓰는지 목록화하고, 라이선스·취약점·배포 조건·인수 범위를 계약 산출물로 지정해야 합니다. 단순히 Git 저장소를 넘겨받는 것만으로는 상업 서비스로 안전하게 운영 가능한 코드인지 알 수 없습니다.
이 글은 법률 자문이 아니라, 스타트업 대표·PM·정부지원사업 수행팀·비개발 임원이 외주 견적서와 계약서, 검수 체크리스트에 무엇을 넣어야 하는지 판단하기 위한 실무 기준입니다. 특히 웹·앱 MVP, SaaS, 관리자 시스템, 예약·매칭·결제 서비스, CRM·업무 자동화, AI 기능 개발을 외주로 맡길 때 유용합니다.

1. 기능 견적서만 보면 왜 위험한가
요즘 외주개발은 완전한 백지 개발이 아닙니다. 프런트엔드는 React·Next.js와 수십 개의 npm 패키지를 조합하고, 백엔드는 Python·Node.js·Java 프레임워크와 데이터베이스 드라이버를 쓰며, 배포는 Docker 이미지와 클라우드 매니지드 서비스를 활용합니다. AI 기능이 들어가면 LLM API, 임베딩 모델, 벡터DB, 오픈소스 모델, 추론 SDK까지 더해집니다.
문제는 견적서가 대개 로그인, 회원관리, 결제, 관리자, 통계, 알림 같은 기능 단위로 작성된다는 점입니다. 그 안에 어떤 외부 코드가 들어가는지, 그 코드가 상업적 이용에 적합한지, 나중에 취약점이 발견되면 누가 패치하는지, 소스코드와 배포 권한을 어디까지 넘겨받는지는 빠지는 경우가 많습니다. 그래서 출시 후에야 다음 질문이 터집니다.
- 이 GPL 계열 라이브러리를 써도 우리 SaaS 소스코드를 공개하지 않아도 되는가?
- Docker 이미지 안에 어떤 OS 패키지와 취약점이 들어 있는가?
- 개발사가 만든 공통 모듈과 우리에게 귀속되는 코드의 경계는 어디인가?
- AI 모델을 상업 서비스에 써도 되는가? 모델 카드의 라이선스와 베이스 모델은 확인했는가?
- 유지보수 업체를 바꾸면 빌드·배포·운영을 재현할 수 있는가?
오픈소스 점검의 목적은 오픈소스를 못 쓰게 하는 것이 아닙니다. 상업 서비스로 운영 가능한 조합인지, 그리고 그 조합을 인수할 수 있는지 확인하는 것입니다.
2. 오픈소스는 무료 코드가 아니라 조건이 붙은 사용 허락입니다
OSI는 오픈소스 소프트웨어가 상업적 목적으로 사용될 수 있다고 설명하지만, 상업적 이용 가능성과 독점 소프트웨어처럼 마음대로 재배포할 수 있다는 뜻은 다르다고 구분합니다. 특히 카피레프트 계열 라이선스는 배포 시 동일 라이선스 적용, 소스코드 제공, 고지 유지 같은 의무가 생길 수 있습니다. ([opensource.org](https://opensource.org/faq))
국내 OLIS는 오픈소스 라이선스를 강한 카피레프트, 약한 카피레프트, 퍼미시브로 나누어 설명합니다. 강한 카피레프트는 GPL처럼 수정·재배포 시 연결된 소스 공개 의무가 넓게 문제될 수 있고, 약한 카피레프트는 LGPL처럼 라이브러리나 모듈 범위에서 의무가 제한되는 경우가 있으며, 퍼미시브는 MIT·BSD·Apache처럼 주로 고지 의무가 핵심입니다. ([olis.or.kr](https://www.olis.or.kr/license/introduction.do))
| 구분 | 대표 예 | 외주개발에서의 실무 의미 | 견적 단계 질문 |
|---|---|---|---|
| 퍼미시브 | MIT, BSD, Apache-2.0 | 대체로 상업 서비스에 쓰기 수월하지만 저작권·라이선스 고지, NOTICE 파일, 특허 조항 확인은 필요합니다. | 라이선스 고지 파일을 산출물에 포함하는가? |
| 약한 카피레프트 | LGPL, MPL, EPL | 라이브러리 링크 방식, 수정 여부, 모듈 경계에 따라 공개 범위가 달라질 수 있습니다. | 정적 링크인지 동적 링크인지, 라이브러리를 수정했는지 설명할 수 있는가? |
| 강한 카피레프트 | GPL-2.0, GPL-3.0 | 배포되는 제품·앱·온프레미스 설치형 솔루션에서는 소스 공개와 동일 라이선스 적용 리스크를 검토해야 합니다. | GPL 코드가 서버 내부 도구인지, 배포물에 포함되는지, 파생저작물 판단이 필요한지 확인했는가? |
| 네트워크 카피레프트 | AGPL-3.0 등 | SaaS처럼 네트워크로 서비스를 제공하는 경우에도 소스 제공 의무가 문제될 수 있어 별도 승인 대상으로 두는 편이 안전합니다. | AGPL·SSPL·유사 라이선스 사용을 금지 또는 사전 승인 대상으로 뒀는가? |

GPL·LGPL·AGPL에서 대표가 꼭 물어볼 질문
- 우리가 배포하는가, 서버에서만 제공하는가? 일반 GPL 계열은 대체로 배포가 핵심 쟁점이지만, AGPL은 네트워크 서비스 제공까지 의무가 확장될 수 있습니다. OLIS도 SaaS 형태에서 GPL 등 대부분의 라이선스와 AGPL 계열을 구분해 확인하라고 설명합니다. ([olis.or.kr](https://www.olis.or.kr/license/guide/softwareGuide.do))
- 원본을 수정했는가, 단순 사용했는가? 라이브러리 자체를 수정했는지, 링크만 했는지, 코드 일부를 복사했는지에 따라 의무 범위가 달라집니다.
- 사용자가 내려받는 앱·프로그램에 포함되는가? 모바일 앱, 데스크톱 프로그램, 고객사 설치형 솔루션, Docker 이미지 납품은 SaaS보다 배포 쟁점이 강합니다.
- 고객사 보안심사에 제출할 수 있는가? B2B SaaS와 공공·대기업 납품은 실제 법적 의무와 별개로 고객 보안팀이 SBOM, 라이선스 목록, 취약점 조치 내역을 요구할 수 있습니다.
라이선스 호환성도 단순하지 않습니다. 예를 들어 Apache Software Foundation은 Apache-2.0 소프트웨어가 GPLv3 프로젝트에 포함될 수 있지만, GPLv3 소프트웨어를 Apache 프로젝트에 포함하는 것은 반대 방향으로 호환되지 않는다고 설명합니다. 이름이 익숙한 라이선스라도 조합 방식까지 확인해야 합니다. ([apache.org](https://www.apache.org/licenses/GPL-compatibility.html))
3. 외주개발에서 실제 점검해야 하는 구성요소
오픈소스 점검은 package.json 한 번 보는 일이 아닙니다. 프런트엔드, 백엔드, 모바일, 인프라, AI, 외부 API, 디자인 자산까지 범위를 정해야 합니다.
| 영역 | 확인 대상 | 놓치기 쉬운 리스크 | 요구 산출물 |
|---|---|---|---|
| 프런트엔드 | npm, yarn, pnpm 패키지와 lock 파일 | 직접 설치한 패키지보다 전이 의존성에서 취약점·라이선스가 나오는 경우가 많습니다. npm의 package-lock.json은 생성된 정확한 의존성 트리를 기록해 재현 설치를 돕습니다. ([docs.npmjs.com](https://docs.npmjs.com/cli/v6/configuring-npm/package-lock-json/?v=true&utm_source=openai)) | package.json, lock 파일, 라이선스 목록, 빌드 명령어 |
| 백엔드 | PyPI, Maven, Gradle, Composer, NuGet 등 | 개발환경과 운영환경의 버전 차이, 오래된 ORM·인증 라이브러리, 보안 패치 누락 | 의존성 파일, 런타임 버전, 취약점 스캔 결과 |
| 모바일 앱 | iOS·Android SDK, 푸시·지도·결제 SDK | 상용 SDK의 무료 한도, 재배포 조건, 스토어 심사 정책, 개인정보 처리 위탁 | SDK 목록, 계정 소유권, 스토어 배포 권한 |
| 컨테이너 | Dockerfile, 베이스 이미지, OS 패키지 | 애플리케이션 코드는 안전해도 이미지 안의 OpenSSL, glibc, 패키지 매니저 캐시에서 취약점이 발견될 수 있습니다. Docker는 BuildKit을 통해 SPDX 형식의 SBOM attestation을 생성하고 이미지에 첨부하는 방식을 제공합니다. ([docs.docker.com](https://docs.docker.com/build/metadata/attestations/sbom/?utm_source=openai)) | Dockerfile, 이미지 태그, SBOM, 이미지 취약점 리포트 |
| AI 기능 | LLM API, 오픈소스 모델, 임베딩 모델, 벡터DB | 모델 라이선스, 데이터셋 출처, 상업적 이용 제한, API 약관, 프롬프트·로그 보관 정책 | 모델·API 목록, 사용 목적, 라이선스·약관 확인표 |
| 디자인·콘텐츠 | 폰트, 아이콘, 이미지, 템플릿 | 소프트웨어 라이선스보다 폰트·이미지 라이선스 위반이 먼저 드러나는 경우도 있습니다. | 자산 출처, 구매 영수증, 사용 범위, 고지 문구 |
AI 모델은 특히 ‘다운로드 가능’과 ‘상업 서비스 사용 가능’을 구분해야 합니다. Hugging Face는 모델 카드 메타데이터에 라이선스, 베이스 모델, 데이터셋 정보를 표시할 수 있도록 안내합니다. 따라서 외주사가 오픈소스 모델을 썼다면 모델명만 받을 것이 아니라 라이선스, base model, fine-tune 여부, 데이터셋 메타데이터까지 확인해야 합니다. ([huggingface.co](https://huggingface.co/docs/hub/en/model-cards))
4. SBOM은 개발사가 사용한 부품명세서입니다
SBOM은 Software Bill of Materials, 즉 소프트웨어 자재명세서입니다. NIST는 SBOM을 소프트웨어를 구성하는 여러 컴포넌트와 공급망 관계를 담은 공식 기록으로 설명하며, 취약점 식별과 공급망 투명성 확보에 활용된다고 봅니다. 다만 SBOM은 보안 문제를 자동으로 해결하는 문서가 아니라, 취약점 관리·벤더 리스크 평가·보안 개발 활동을 보완하는 데이터 계층입니다. ([nist.gov](https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20))
2026년 7월 29일 캐나다 사이버보안센터가 공개한 공동 가이던스에 따르면, CISA와 국제 파트너들은 2026년 SBOM 최소 요소 가이던스를 발행했고 이는 2021년 NTIA 기준을 업데이트·대체합니다. 해당 설명은 업데이트된 기준이 오픈소스 소프트웨어, AI 소프트웨어, SaaS를 포함한 모든 소프트웨어에 적용된다고 밝힙니다. ([cyber.gc.ca](https://www.cyber.gc.ca/en/news-events/joint-guidance-minimum-elements-software-bill-materials))
형식은 엑셀보다 기계가 읽을 수 있는 표준 포맷이 중요합니다. SPDX 프로젝트는 SBOM과 AI·데이터·보안 참조를 표현할 수 있는 공개 국제 표준이며 ISO/IEC 5962:2021로 설명됩니다. CycloneDX는 OWASP와 Ecma TC54가 발전시키는 BOM 표준으로, SBOM뿐 아니라 SaaSBOM, AI/ML-BOM, 라이선스 지원 같은 확장 영역을 제시합니다. ([spdx.dev](https://spdx.dev/))

| SBOM에 최소로 요구할 항목 | 대표 확인 내용 | 검수 질문 |
|---|---|---|
| 컴포넌트 식별 | 패키지명, 공급자, 버전, 고유 식별자 | 동명이인 패키지나 fork 버전을 구분할 수 있는가? |
| 의존 관계 | 직접 의존성, 전이 의존성, 포함 관계 | 실제로 배포 이미지에 들어간 항목까지 포함했는가? |
| 라이선스 | 라이선스명, SPDX ID, NOTICE 필요 여부 | 금지·사전 승인 라이선스가 있는가? |
| 취약점 연결 | CVE, 심각도, 조치 여부, 예외 사유 | High 이상 취약점이 남아 있다면 이유와 보완책이 있는가? |
| 생성 맥락 | 생성 도구, 생성 시점, 대상 빌드·이미지 | 최종 배포 버전과 SBOM이 일치하는가? |
국내에서도 공급망 보안과 SBOM은 별도 보안팀만의 주제가 아닙니다. KISA의 2026년 공급망 보안 모델 구축 지원사업 공고는 SBOM을 생성·관리·분석하는 체계와 취약점 관리 고도화를 지원 내용으로 명시했습니다. 외주개발 발주자도 ‘우리 서비스가 어떤 코드 조각으로 구성되어 있는가’를 설명할 수 있어야 고객사 심사와 운영 리스크에 대응할 수 있습니다. ([kisa.or.kr](https://www.kisa.or.kr/401/form?postSeq=3616))
5. 견적요청서에 바로 넣을 요구 문구
아래 문구는 법무 검토 전 초안으로 사용할 수 있는 실무 표현입니다. 견적 단계에서 이 문구를 넣으면 개발사가 처음부터 의존성 선택과 산출물 범위를 계산하게 됩니다.
1) 오픈소스 사용 원칙
수급인은 본 프로젝트에 사용되는 오픈소스, 상용 SDK, 외부 API, AI 모델 및 컨테이너 이미지를 사전에 식별하고, 각 구성요소의 명칭, 버전, 라이선스, 사용 위치, 배포 포함 여부를 목록화한다. AGPL, SSPL, GPL 계열 등 발주사의 소스 공개 또는 서비스 운영에 중대한 의무를 발생시킬 수 있는 라이선스는 발주사의 사전 서면 승인 없이 사용하지 않는다.
2) SBOM 제출
수급인은 최종 납품 버전 기준으로 SPDX 또는 CycloneDX 등 기계 판독 가능한 형식의 SBOM을 제출한다. SBOM은 프런트엔드, 백엔드, 모바일, 컨테이너 이미지, 주요 AI·데이터 처리 구성요소를 포함하며, 제출 시점과 대상 빌드 버전을 명시한다.
3) 취약점 조치
납품 전 주요 의존성 및 컨테이너 이미지에 대해 취약점 점검을 수행하고, Critical 또는 High 등급 취약점은 패치, 버전 업그레이드, 대체, 제거 또는 수용 사유를 문서화한다. 예외적으로 남기는 취약점은 영향 범위와 보완 통제를 발주사에 설명한다.
4) 라이선스 고지
수급인은 서비스 내 고지 화면, README, NOTICE, LICENSE 파일 등 필요한 고지 산출물을 제공한다. 고지가 필요한 오픈소스와 고지 위치를 별도 표로 정리한다.
6. 계약서에서 빠지면 위험한 조항
소스코드 소유권은 ‘당연히 돈을 냈으니 우리 것’이라고 생각하면 위험합니다. 민간 외주개발에서는 계약서에 저작재산권 양도, 이용허락, 2차적 저작물 작성권, 개발사의 기존 모듈 사용권, 재사용 가능 범위, 오픈소스 제외 범위를 구분해 적어야 분쟁을 줄일 수 있습니다. 특히 개발사가 보유한 프레임워크나 공통 관리자 템플릿을 쓰는 경우, 그 전체 권리가 넘어오는지 아니면 프로젝트 사용권만 받는지 확인해야 합니다.
| 조항 | 확인할 내용 | 빠졌을 때 생기는 문제 |
|---|---|---|
| 산출물 정의 | 소스코드, 디자인 파일, DB 스키마, API 문서, 배포 스크립트, 관리자 매뉴얼, SBOM 포함 여부 | 소스는 받았지만 배포·운영을 못 하는 상황 |
| 권리 귀속 | 신규 개발 코드와 개발사 기존 모듈의 경계 | 업체 교체 후 수정·재판매·확장 권한 분쟁 |
| 오픈소스 승인 | 허용 라이선스, 사전 승인 라이선스, 금지 라이선스 | 출시 후 소스 공개·고지 누락·고객사 보안심사 이슈 |
| 취약점 책임 | 납품 전 조치, 하자보수 기간, 운영 중 패치 범위 | 새 CVE 발생 시 무상인지 유상인지 다툼 |
| 계정·서버 소유 | 클라우드, 도메인, 앱스토어, Git, CI/CD, 결제·문자·메일 계정 소유자 | 계정이 개발사 명의라 운영권 이전이 지연 |
| 인수인계 | 빌드 재현, 배포 재현, 운영 문서, 교육 세션 | 담당자 퇴사나 업체 교체 시 서비스 중단 |
업체 교체나 개발사 폐업 리스크까지 고려한다면 소스코드 보관·인출 조건도 함께 검토해야 합니다. 이 주제는 외주개발 소스코드 에스크로 가이드에서 별도로 정리했습니다.
7. 소스코드 인수 전 검수 체크리스트

납품 검수는 화면을 클릭해보는 QA와 다릅니다. 다음 항목이 준비되어야 유지보수 업체가 바뀌어도 서비스를 이어갈 수 있습니다.
| 검수 영역 | 체크 항목 | 합격 기준 |
|---|---|---|
| 저장소 | Git 전체 이력, 브랜치 전략, 태그, README | 최종 배포 버전이 태그로 식별되고 로컬에서 clone 가능 |
| 빌드 | 런타임 버전, 패키지 매니저, lock 파일, 환경변수 예시 | 새 PC 또는 CI에서 동일 버전 빌드 가능 |
| 배포 | Dockerfile, compose, Kubernetes manifest, 배포 스크립트 | 스테이징 환경에 재배포 가능 |
| SBOM | SPDX 또는 CycloneDX, 생성 시점, 대상 빌드 | 최종 납품 버전과 SBOM 버전이 일치 |
| 라이선스 | 라이선스 목록, NOTICE, 고지 화면 | 금지 라이선스 없음 또는 승인 내역 존재 |
| 보안 | 취약점 스캔, 비밀키 탐지, 관리자 권한 점검 | 중대 취약점 조치 또는 예외 승인 문서화 |
| 데이터 | DB 스키마, 마이그레이션, 초기 데이터, 백업·복원 | 빈 환경에서 서비스 구동 가능 |
| 운영 | 모니터링, 로그 위치, 장애 대응 절차, 계정 인수 | 비개발 운영자가 1차 확인 가능한 문서 제공 |
컨테이너 기반 서비스라면 애플리케이션 의존성뿐 아니라 이미지 레이어와 OS 패키지까지 봐야 합니다. 작은 팀에서 어느 정도까지 자동화할지 고민된다면 컨테이너 이미지 취약점 스캐닝과 SBOM 가이드도 함께 확인해보면 좋습니다.
8. 유지보수 책임은 ‘버그 수정’과 ‘보안 패치’를 분리해야 합니다
많은 계약서가 하자보수 3개월 또는 6개월이라고만 적습니다. 하지만 오픈소스 취약점은 납품 당시 버그가 아니더라도 운영 중 새로 공개될 수 있습니다. NIST도 SBOM이 취약점 식별과 리스크 관리에 도움을 주지만 기존 취약점 관리 역량을 대체하지는 않는다고 설명합니다. ([nist.gov](https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20))
따라서 유지보수 계약에는 다음 구분이 필요합니다.
| 구분 | 예시 | 계약상 정할 내용 |
|---|---|---|
| 하자보수 | 요구사항대로 구현되지 않은 기능, 명백한 오류 | 무상 범위, 접수 채널, 재현 기준 |
| 보안 패치 | 프레임워크 취약점, Docker 이미지 취약점, 인증 라이브러리 CVE | 심각도별 대응 시간, 유상·무상 범위, 예외 승인 절차 |
| 기능 변경 | 결제 정책 변경, 관리자 통계 추가, 권한 구조 변경 | 변경 견적, 일정 영향, 재검수 기준 |
| 운영 지원 | 서버 장애, 배포 실패, 클라우드 비용 급증 | 모니터링 책임, 야간·주말 대응, 커뮤니케이션 채널 |
보안 패치를 유지보수 범위에 넣을수록 월 비용은 올라갈 수 있습니다. 하지만 B2B SaaS, 개인정보 처리 서비스, 결제·예약·매칭 플랫폼, 정부지원사업 결과물을 실제 고객에게 공개할 계획이라면 이 비용은 출시 후 보험에 가깝습니다. SLA 설계는 외주개발 유지보수 SLA 설계 가이드에서 더 자세히 다룹니다.
9. AI 기능 외주라면 모델·SDK·데이터 조건까지 봐야 합니다
AI 챗봇, 문서 자동분류, RAG 검색, 이미지 분석, 상담 요약 기능은 일반 웹 기능보다 공급망이 복잡합니다. 2026년 SBOM 공동 가이던스 설명은 AI 소프트웨어와 SaaS까지 적용 범위에 포함한다고 밝히며, 별도 AI SBOM 논의에서는 모델, 데이터셋, 성능 지표, AI 인프라 같은 요소가 추가 쟁점으로 언급됩니다. ([cyber.gc.ca](https://www.cyber.gc.ca/en/news-events/joint-guidance-minimum-elements-software-bill-materials))
외주사가 ‘오픈소스 모델을 썼다’고 말하면 아래를 확인해야 합니다.
- 모델 라이선스가 상업적 이용을 허용하는가?
- 베이스 모델과 fine-tune 모델의 라이선스가 충돌하지 않는가?
- 학습·평가 데이터셋의 사용 조건이 서비스 목적과 맞는가?
- 모델을 고객 데이터로 추가 학습했는가? 했다면 데이터 처리 근거와 삭제 가능성이 있는가?
- LLM API를 쓴다면 입력 데이터, 로그 보관, 금지 사용 정책, 비용 폭증 대응 기준은 정했는가?
AI 기능은 처음에는 데모가 잘 돌아가는지가 눈에 띕니다. 그러나 실서비스에서는 모델 약관, 프롬프트 인젝션, 응답 품질, 토큰 비용, 개인정보 처리, 관리자 검수 화면이 함께 설계되어야 합니다. AgentMit이 AI 기능 개발을 검토할 때 모델 선택만 보지 않고 관리자 승인 흐름, 로그, 비용 추적, 운영 권한까지 같이 보는 이유가 여기에 있습니다.
10. 프로젝트 규모별로 어디까지 요구할까
모든 외주개발에 동일한 보안 산출물을 요구하면 비용이 과해질 수 있습니다. 반대로 B2B 납품용 SaaS를 단순 랜딩페이지 수준으로 관리하면 출시 후 다시 비용을 지불하게 됩니다. 아래 기준으로 요구 수준을 나눠보면 견적 비교가 쉬워집니다.
| 프로젝트 유형 | 권장 점검 수준 | 필수 산출물 | 추가 권장 |
|---|---|---|---|
| 사업계획서용 클릭 데모 | 경량 | 사용 기술 목록, 주요 외부 API 목록 | 상용 출시 전 재점검 조건 |
| MVP 웹·앱 출시 | 표준 | 소스코드, lock 파일, 라이선스 목록, 취약점 기본 점검, 배포 문서 | SBOM, 관리자 운영 문서 |
| B2B SaaS·고객사 납품 | 강화 | SPDX 또는 CycloneDX SBOM, 취약점 조치표, NOTICE, 계정 인수, SLA | 정기 스캔, 고객 보안질의 대응 문서 |
| 공공·대기업·민감정보 서비스 | 고도화 | SBOM, 보안 점검, 개인정보 흐름, 접근권한, 로그·감사, 백업·복구 문서 | 보안 아키텍처 리뷰, 법무·보안팀 검토 |
예산을 아끼려면 SBOM을 빼는 것보다 범위를 좁히는 편이 낫습니다. 예를 들어 1차 MVP에서는 고객용 핵심 플로우와 관리자 최소 기능만 만들고, 대신 소스코드·배포·의존성 인수 기준은 지키는 방식이 장기적으로 더 안전합니다.
11. 발주자가 견적 전에 준비하면 좋은 자료
- 서비스 유형: 웹, 앱, SaaS, 내부 관리자, 설치형 납품 중 무엇인지
- 배포 방식: 고객이 앱을 내려받는지, 서버에서만 제공하는지, 고객사 서버에 설치하는지
- 외부 연동: 결제, 문자, 메일, 지도, ERP, CRM, LLM API, 벡터DB
- 운영 데이터: 개인정보, 결제정보, 기업 고객 데이터, 파일 업로드 여부
- 고객사 요구: 보안점검, SBOM, 소스코드 제출, 클라우드 위치, 로그 보관 기간
- 출시 일정: 데모 발표일, 정부지원사업 중간점검, 실제 고객 오픈일
- 권리 요구: 소스코드 완전 양도, 특정 프로젝트 사용권, 개발사 공통 모듈 허용 여부
이 자료가 있으면 개발사는 ‘기능 몇 개’가 아니라 운영 가능한 납품물을 기준으로 견적을 낼 수 있습니다. 반대로 이 정보 없이 받은 저가 견적은 나중에 SBOM, 보안 패치, 배포 문서, 계정 이전, 라이선스 정리 비용이 추가될 가능성이 큽니다.
FAQ
Q1. 외주개발에서 GPL 라이브러리를 쓰면 우리 서비스 소스코드도 공개해야 하나요?
항상 그런 것은 아닙니다. 사용 방식, 수정 여부, 배포 여부, 링크 방식, AGPL 여부에 따라 달라집니다. 특히 SaaS처럼 서버에서 제공하는 서비스라도 AGPL 계열은 네트워크 제공 자체가 의무를 만들 수 있으므로 견적 단계에서 라이선스 목록과 사용 방식을 함께 검토해야 합니다.
Q2. SBOM은 작은 MVP 외주개발에서도 꼭 받아야 하나요?
모든 MVP에 대형 보안 산출물이 필요한 것은 아닙니다. 다만 상용 출시 예정이라면 최소한 의존성 목록, 라이선스 목록, 주요 취약점 점검 결과는 받는 것이 좋습니다. B2B 납품, 정부과제, 개인정보 처리, 결제·의료·교육·금융 연계가 있으면 SBOM 제출을 산출물로 넣는 편이 안전합니다.
Q3. 소스코드 인수 시 오픈소스 라이선스 목록만 받으면 충분한가요?
부족합니다. 정확한 버전, 전이 의존성, Docker 베이스 이미지, AI 모델·SDK, 외부 API, 고지 파일, 취약점 스캔 결과, 빌드 재현 방법, 배포 설정, 유지보수 책임까지 확인해야 운영 가능한 인수가 됩니다.
Q4. AI 모델이나 LLM API도 오픈소스 라이선스 점검 대상인가요?
네. 오픈소스 모델은 모델 라이선스, 베이스 모델, 데이터셋, 상업적 이용 조건, 재배포 조건을 확인해야 합니다. API형 LLM은 오픈소스라기보다 서비스 약관, 데이터 처리 조건, 금지 사용 정책, 장애·비용 리스크를 계약과 운영 정책에서 확인해야 합니다.
Q5. 납품 후 새 취약점이 발견되면 외주사가 무상으로 고쳐줘야 하나요?
계약에 없으면 분쟁이 생기기 쉽습니다. 하자보수, 기능 변경, 보안 패치, 라이브러리 업그레이드, 클라우드 이미지 재빌드, 긴급 장애 대응을 구분하고 심각도별 대응 시간과 비용 기준을 유지보수 SLA로 정해야 합니다.
참고자료
- 오픈소스의 상업적 이용 가능성과 카피레프트 조건: OSI FAQ, OLIS 라이선스 소개. ([opensource.org](https://opensource.org/faq))
- GPL·LGPL·AGPL, SaaS 형태 이용, 네트워크 서비스 제공 시 의무: OLIS 오픈소스SW 라이선스 가이드. ([olis.or.kr](https://www.olis.or.kr/license/guide/softwareGuide.do))
- SBOM의 정의, 기계 판독 가능 형식, 취약점 관리와의 관계: NIST SBOM guidance. ([nist.gov](https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20))
- SPDX와 CycloneDX 표준, SBOM·SaaSBOM·AI/ML-BOM 참고: SPDX Project, CycloneDX. ([spdx.dev](https://spdx.dev/))
- 2026년 SBOM 최소 요소 공동 가이던스 및 국내 공급망 보안 맥락: Canadian Centre for Cyber Security, KISA 공고. ([cyber.gc.ca](https://www.cyber.gc.ca/en/news-events/joint-guidance-minimum-elements-software-bill-materials))
AgentMit 관점: 외주개발은 기능 구현보다 인수 가능성이 중요합니다
AgentMit은 외주개발을 단순 화면 구현으로 보지 않습니다. MVP나 SaaS, 관리자 시스템, AI 자동화 기능을 만들 때 요구사항, UI, 백엔드, 데이터 구조, 외부 API, 배포, 보안, 운영 문서가 연결되어야 실제 서비스로 이어집니다. 오픈소스 라이선스와 SBOM도 그 연결의 일부입니다.
웹·앱·SaaS·관리자 시스템·AI 기능 개발을 앞두고 있다면, 기능 목록만 보내 견적을 받기 전에 사용 기술, 외부 연동, 배포 방식, 소스코드 인수 범위, 유지보수 책임을 함께 정리해보세요. AgentMit은 BizMit 기반의 업무 시스템·SaaS·자동화·AI 서비스 개발 경험을 바탕으로, 정부지원 MVP부터 실서비스 운영까지 필요한 범위와 기술 리스크를 함께 검토할 수 있습니다.
출시 후 다시 뜯어고치는 비용을 줄이고 싶다면, 견적 단계에서 오픈소스·SBOM·소스 인수 기준까지 포함해 상담을 요청해보세요.

