외주개발 오픈소스 라이선스·SBOM 점검 가이드: 소스코드 인수 전 확인할 계약·검수 기준 > 인사이트

본문 바로가기

인사이트

#외주개발

외주개발 오픈소스 라이선스·SBOM 점검 가이드: 소스코드 인수 전 확인할 계약·검수 기준

외주개발 오픈소스 라이선스·SBOM 점검 가이드: 소스코드 인수 전 확인할 계약·검수 기준

외주개발에서 오픈소스 리스크를 줄이는 가장 현실적인 방법은 납품 후에 묻는 것이 아니라 견적 단계에서 요구하는 것입니다. 개발사가 어떤 npm·PyPI 패키지, 백엔드 프레임워크, 모바일 SDK, 결제·알림 API, AI 모델, Docker 베이스 이미지를 쓰는지 목록화하고, 라이선스·취약점·배포 조건·인수 범위를 계약 산출물로 지정해야 합니다. 단순히 Git 저장소를 넘겨받는 것만으로는 상업 서비스로 안전하게 운영 가능한 코드인지 알 수 없습니다.

이 글은 법률 자문이 아니라, 스타트업 대표·PM·정부지원사업 수행팀·비개발 임원이 외주 견적서와 계약서, 검수 체크리스트에 무엇을 넣어야 하는지 판단하기 위한 실무 기준입니다. 특히 웹·앱 MVP, SaaS, 관리자 시스템, 예약·매칭·결제 서비스, CRM·업무 자동화, AI 기능 개발을 외주로 맡길 때 유용합니다.

외주개발 오픈소스 라이선스와 SBOM을 점검하는 B2B 기술 회의 장면
외주개발의 인수 기준은 소스코드 파일이 아니라 상업 운영 가능한 구성인지 확인하는 데서 시작됩니다.

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에서 대표가 꼭 물어볼 질문

  1. 우리가 배포하는가, 서버에서만 제공하는가? 일반 GPL 계열은 대체로 배포가 핵심 쟁점이지만, AGPL은 네트워크 서비스 제공까지 의무가 확장될 수 있습니다. OLIS도 SaaS 형태에서 GPL 등 대부분의 라이선스와 AGPL 계열을 구분해 확인하라고 설명합니다. ([olis.or.kr](https://www.olis.or.kr/license/guide/softwareGuide.do))
  2. 원본을 수정했는가, 단순 사용했는가? 라이브러리 자체를 수정했는지, 링크만 했는지, 코드 일부를 복사했는지에 따라 의무 범위가 달라집니다.
  3. 사용자가 내려받는 앱·프로그램에 포함되는가? 모바일 앱, 데스크톱 프로그램, 고객사 설치형 솔루션, Docker 이미지 납품은 SaaS보다 배포 쟁점이 강합니다.
  4. 고객사 보안심사에 제출할 수 있는가? 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/))

견적 단계부터 개발과 검수까지 오픈소스 의존성을 추적하는 워크플로우
의존성 목록은 개발 중 계속 바뀌므로 계약서와 CI/CD 단계에서 업데이트 기준을 정해야 합니다.
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. 소스코드 인수 전 검수 체크리스트

외주개발 소스코드 인수 전 SBOM과 보안 체크리스트를 확인하는 장면
검수 체크리스트가 있어야 유지보수 업체 교체와 긴급 보안 패치가 현실적으로 가능합니다.

납품 검수는 화면을 클릭해보는 QA와 다릅니다. 다음 항목이 준비되어야 유지보수 업체가 바뀌어도 서비스를 이어갈 수 있습니다.

검수 영역체크 항목합격 기준
저장소Git 전체 이력, 브랜치 전략, 태그, README최종 배포 버전이 태그로 식별되고 로컬에서 clone 가능
빌드런타임 버전, 패키지 매니저, lock 파일, 환경변수 예시새 PC 또는 CI에서 동일 버전 빌드 가능
배포Dockerfile, compose, Kubernetes manifest, 배포 스크립트스테이징 환경에 재배포 가능
SBOMSPDX 또는 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·소스 인수 기준까지 포함해 상담을 요청해보세요.

자주 묻는 질문

외주개발에서 GPL 라이브러리를 쓰면 우리 서비스 소스코드도 공개해야 하나요?
항상 그런 것은 아닙니다. 사용 방식, 수정 여부, 배포 여부, 링크 방식, AGPL 여부에 따라 달라집니다. SaaS처럼 서버에서만 제공하는 경우에도 AGPL 계열은 네트워크 제공 자체가 의무를 만들 수 있으므로 견적 단계에서 라이선스 목록과 사용 방식을 함께 검토해야 합니다.
SBOM은 작은 MVP 외주개발에서도 꼭 받아야 하나요?
모든 MVP에 대형 보안 산출물이 필요한 것은 아니지만, 상용 출시 예정인 웹·앱·SaaS라면 최소한 의존성 목록, 라이선스 목록, 주요 취약점 점검 결과는 받는 것이 안전합니다. B2B 납품, 정부과제, 개인정보 처리, 결제·의료·교육·금융 연계가 있으면 SBOM 제출을 산출물로 넣는 편이 좋습니다.
소스코드 인수 시 오픈소스 라이선스 목록만 받으면 충분한가요?
부족합니다. 라이선스 목록뿐 아니라 정확한 버전, 전이 의존성, Docker 베이스 이미지, AI 모델·SDK, 외부 API, 고지 파일, 취약점 스캔 결과, 빌드 재현 방법, 배포 설정, 유지보수 책임까지 확인해야 운영 가능한 인수가 됩니다.
AI 모델이나 LLM API도 오픈소스 라이선스 점검 대상인가요?
네. 오픈소스 모델은 모델 라이선스, 베이스 모델, 데이터셋, 상업적 이용 조건, 재배포 조건을 확인해야 합니다. API형 LLM은 오픈소스라기보다 서비스 약관, 데이터 처리 조건, 금지 사용 정책, 장애·비용 리스크를 계약과 운영 정책에서 확인해야 합니다.
납품 후 새 취약점이 발견되면 외주사가 무상으로 고쳐줘야 하나요?
계약에 없으면 분쟁이 생기기 쉽습니다. 하자보수, 기능 변경, 보안 패치, 라이브러리 업그레이드, 클라우드 이미지 재빌드, 긴급 장애 대응을 구분하고, 심각도별 대응 시간과 비용 기준을 유지보수 SLA로 정해야 합니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 남구 전포대로 133, 11층 102호(문현동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.