본문으로 건너뛰기

오픈소스 정책 수립: 법적 보호의 첫걸음

1. 이 챕터에서 하는 일

이 챕터에서는 회사 맞춤형 오픈소스 정책 문서를 작성합니다. 오픈소스 정책은 단순한 내부 규정집이 아닙니다. 라이선스 분쟁이나 취약점 사고가 발생했을 때 회사가 체계적인 컴플라이언스 관리를 해왔다는 법적 보호 수단이 됩니다. 납품처나 파트너사에서 오픈소스 관리 체계 증빙을 요구할 때도 즉시 제출할 수 있는 공식 문서가 됩니다.

agents/03-policy-generator 를 실행하면 회사의 배포 방식, 개발 언어, 납품 여부 등 5가지 질문에 대한 답변을 바탕으로 output/policy/oss-policy.md 와 output/policy/license-allowlist.md 두 가지 산출물을 자동 생성합니다.

2. 배경 지식

팁

CVE·SBOM·Copyleft 등 낯선 약어는 용어집에서 쉬운 설명을 볼 수 있습니다.

오픈소스 정책이 왜 필요한가

오픈소스 라이선스 위반은 실제 법적 분쟁으로 이어진 사례가 있습니다.

Artifex vs Hancom (2017) 한컴오피스는 GPL 라이선스로 배포되는 Ghostscript(PDF 렌더링 엔진)를 제품에 무단으로 사용했습니다. Artifex Software는 미국 캘리포니아 법원에 소송을 제기했고, 법원은 1심에서 GPL 라이선스가 계약으로서 법적 구속력을 가진다고 판결했습니다. 오픈소스 라이선스 위반이 단순한 저작권 문제를 넘어 계약 위반 책임까지 일으킬 수 있음을 보여준 사건입니다.

정책 부재 시 실무에서 발생하는 문제

  • 라이선스 충돌: GPL 코드가 Apache-2.0 프로젝트에 섞이면 전체 배포가 불가능해질 수 있습니다
  • 고지 누락: Apache-2.0, MIT 등 Permissive 라이선스도 NOTICE 파일 또는 저작권 고지 의무가 있습니다
  • 취약점 방치: 오픈소스 컴포넌트의 알려진 CVE를 추적하지 않으면 제품에 보안 취약점이 방치됩니다

문서화된 정책이 있으면 위반 발생 시 "고의성 없음"을 입증하는 근거가 되고, 체계적인 절차를 운영했다는 증거로 활용됩니다.

표준이 요구하는 정책 필수 구성 요소

두 표준 모두 허용 범위, 라이선스 의무 이행 절차, 담당자, 위반 처리 절차, 검토 주기를 공통으로 요구합니다. ISO/IEC 18974는 여기에 더해 취약점 대응 절차, 보안 취약점 공개 정책, 프로그램 성과 지표(KPI)를 추가로 요구합니다. 또한 두 표준 모두 정책 문서의 존재만으로는 부족하며, 실제로 직원들이 접근할 수 있고 인지하고 있어야 한다고 요구합니다.

팁

정책에 포함해야 할 항목의 상세 설명과 예시 정책 문서는 KWG 오픈소스 가이드 — 정책를 참조하세요.

ISO/IEC 18974 §4.1.4.2 — 프로그램 성과 지표

ISO/IEC 18974는 오픈소스 보안 보증 프로그램이 **측정 가능한 성과 지표(KPI)**를 포함해야 한다고 요구합니다. 정책 문서에 아래 유형의 KPI를 명시하면 이 요구사항을 충족할 수 있습니다.

KPI 예시측정 방법
CVE 탐지 후 Critical 취약점 패치 기간발견일 ~ 패치 배포일 (목표: 1주일 이내)
SBOM 갱신 주기 준수율릴리즈 시 SBOM 업데이트 횟수 / 전체 릴리즈 수
CVE 정기 스캔 주기릴리즈마다 + 월 1회 정기 스캔
취약점 대응률기한 내 해소 90% 이상 (미해소 시 사유·완화 계획 문서화)
교육 이수율오픈소스 관련 직군 연간 100% 이수
오픈소스 사용 승인 처리 기간승인 요청 대비 처리 기간 (목표: 3영업일 이내)
참고

위 기한은 OpenChain KWG 가이드 기준선입니다. 조직의 리스크 프로파일에 따라 Critical 24시간, High 1주일 같은 더 엄격한 기한을 내부 SLA로 적용할 수 있습니다.

agent가 생성하는 oss-policy.md 에는 위와 같은 KPI 섹션이 포함됩니다.

AI 생성 코드 정책

GitHub Copilot, ChatGPT 등 AI 코딩 도구가 생성한 코드를 제품에 포함할 경우, 학습 데이터로 사용된 오픈소스의 라이선스 의무가 적용될 수 있습니다. KWG 오픈소스 가이드는 이를 정책에 명시적으로 반영할 것을 권장합니다.

  • AI 생성 코드도 일반 오픈소스와 동일한 검토 절차를 적용
  • 소스 코드 스캔 도구(SCANOSS 등)를 활용한 스니펫 탐지 권장
  • 사용하는 AI 도구의 이용약관(저작권 귀속, 라이선스 조건) 확인 필요

agent가 생성하는 oss-policy.md 에는 AI 생성 코드 정책 섹션이 포함됩니다. 조직에서 AI 코딩 도구를 사용하지 않는 경우에도 "해당 없음"으로 명시해두는 것이 좋습니다.

정책 전파 (Policy Communication)

ISO/IEC 5230과 18974 모두 정책이 관련 인원에게 전달되고 이해되었음을 요구합니다. 단순히 문서를 작성하는 것으로는 부족합니다.

정책 전파 방법:

  • 사내 위키(Confluence, Notion 등)에 정책 게시
  • 온보딩 교육 자료에 정책 링크 포함
  • 연 1회 전체 개발자 대상 정책 변경사항 공유
  • 담당자 임명장에 정책 인지 서명란 포함 (appointment-template.md 활용)

이 단계는 ISO/IEC 5230 3.1.1 (오픈소스 정책 수립 및 문서화) 요구사항을 충족합니다.

정책 운영 및 변경 관리

정책은 한 번 쓰고 끝나는 문서가 아닙니다. 두 표준 모두 정책을 정기적으로 검토·갱신하도록 요구합니다. 실무에서 더 중요한 것은 운영 중 변경을 어떻게 처리하는가입니다.

  • 변경 요청 흐름: 구성원이 "이 라이선스를 허용해 달라" 같은 요청을 하면 담당자 심사, 승인, 정책·허용 목록 반영, 전파의 순서로 처리하는 절차를 정해 둡니다.
  • 규제 모니터링: EU CRA·국내 SBOM 의무화처럼 규제가 바뀌면 정책도 따라가야 하므로, 담당자가 정기적으로 동향을 점검합니다.

agent가 생성하는 oss-policy.md 에는 이 변경 요청·운영 절(§11)이 포함됩니다.

이 단계는 ISO/IEC 18974 §4.1.1 (보안 보증 정책의 운영·검토) 요구사항을 충족합니다.

라이선스 분류 이해

오픈소스 라이선스는 의무사항의 강도에 따라 Permissive, Weak Copyleft, Strong Copyleft, Network Copyleft로 분류됩니다. 같은 코드라도 회사의 배포 방식(SaaS/앱스토어/임베디드)에 따라 의무 발생 여부가 달라지므로, 정책 작성 전에 반드시 이해해야 합니다.

분류 기준의 정본

분류별 대표 라이선스와 핵심 의무, 배포 방식별 영향, 배포 채널 허용 매트릭스는 라이선스 분류에 정리돼 있습니다. policy-generator 에이전트는 이 기준을 회사 배포 방식에 맞는 허용 목록으로 구체화합니다.

이 단계는 ISO/IEC 5230 3.1.4 (프로그램 범위 정의) 요구사항을 충족합니다.

실습 전 확인

이 실습은 trustedoss 프로젝트 루트에서 Claude Code 를 실행하는 환경을 전제합니다.

  • trustedoss 저장소를 클론했나요? git clone https://github.com/trustedoss/trustedoss-agents.git
  • 터미널에서 프로젝트 루트에 있나요? cd trustedoss-agents
  • Claude Code 가 실행 중인가요? claude

모두 체크되지 않았다면 → 1. 환경 준비 챕터를 먼저 진행하세요.

3. 셀프 스터디

셀프스터디 모드 (약 1시간)

agent와 대화하며 정책 문서를 생성합니다. 아래 5개 질문에 미리 답변을 준비해두면 빠르게 진행됩니다.

사전 준비: 5개 질문에 대한 답변 정리

agent 실행 전에 아래 질문에 대한 회사 상황을 간단히 메모해두면 작업이 빠르게 진행됩니다.

  1. 소프트웨어 배포 방식: SaaS / 앱스토어(모바일·데스크톱) / 임베디드(펌웨어·하드웨어) / 내부 도구만 / 복합 (중복 선택 가능)
  2. 주요 개발 언어와 패키지 매니저: 예) Python + pip, JavaScript + npm, Java + Maven 등
  3. 오픈소스 프로젝트 기여 계획: GitHub 등 외부 오픈소스 프로젝트에 코드를 기여할 계획이 있는가
  4. 외부 고객/납품처에 납품 여부: 제품이나 소프트웨어를 외부 고객에게 납품하거나 판매하는가
  5. 현재 라이선스 검토 절차 유무: 현재 오픈소스 도입 시 라이선스를 검토하는 절차가 있는가

단계별 실습

Step 1. policy-generator agent 실행

실행 전 확인

현재 Claude 세션을 먼저 종료(/exit 또는 Ctrl+C)한 뒤, 새 터미널에서 아래 명령을 실행하세요.

Bash
cd agents/03-policy-generator
claude

Step 2. Claude 프롬프트가 열리면 시작 을 입력합니다.

Agent 대화 예시 (클릭해서 펼치기)

아래는 실제 agent와의 대화 흐름 예시입니다. 사용자가 시작 입력 시 이런 형태로 진행됩니다.

Agent 안내 메시지:

안녕하세요! 오픈소스 정책 산출물을 생성하는 agent입니다. 5개 질문에 답변하시면 정책 문서 2개가 자동으로 생성됩니다.

질문 1/5 — 소프트웨어 배포 방식은? (SaaS / 앱스토어 배포 / 임베디드 / 내부용 / 복합)

예시 답변: SaaS

질문 2/5 — 주로 사용하는 개발 언어와 패키지 매니저는?

예시 답변: Python + pip, JavaScript + npm

질문 3/5 — 오픈소스 프로젝트에 기여할 계획이 있나요?

예시 답변: 없음 (내부 서비스 개발에 집중)

질문 4/5 — 외부 고객/납품처에 소프트웨어를 납품하나요?

예시 답변: 없음 (자사 SaaS 서비스만 운영)

질문 5/5 — 현재 라이선스 검토 절차가 있나요? (있음 / 없음 / 비공식적으로 있음)

예시 답변: 비공식적으로 있음

생성되는 파일과 직접 확인할 항목은 아래 "4. 완료 확인 체크리스트"에 정리되어 있습니다. 일부 항목은 직접 기입해야 합니다.

직접 기입이 필요한 항목:

  • 담당자 실제 성명 및 이메일
  • 정책 시행일
  • 정책 검토 주기 확정

Step 3. agent 질문에 순서대로 답변 agent가 5개 질문을 하나씩 물어봅니다. 준비한 답변을 바탕으로 대화합니다. 확실하지 않은 항목은 agent에게 가이드를 요청할 수 있습니다.

Step 4. oss-policy.md 검토

Bash
open output/policy/oss-policy.md
  • 회사명과 실제 담당자 이름이 반영되어 있는지 확인
  • 배포 방식에 맞는 라이선스 의무 이행 절차가 포함되어 있는지 확인
  • 정책 검토 주기(예: 연 1회)가 명시되어 있는지 확인

Step 5. license-allowlist.md 검토 및 수정

Bash
open output/policy/license-allowlist.md
  • 우리 배포 방식에 맞는 분류가 적용되어 있는지 확인
  • 실제 사용 중인 라이선스가 목록에 포함되어 있는지 확인
  • 필요 시 항목 추가 또는 조건 수정

Step 6. 완료 확인 체크리스트 점검 아래 "4. 완료 확인 체크리스트" 섹션의 항목을 하나씩 확인합니다.

이 단계는 ISO/IEC 5230 3.5.1 (오픈소스 기여 정책 수립) 요구사항을 충족합니다.

충족되는 표준 요구사항

이 실습을 완료하면 아래 요구사항이 충족됩니다.

ISO/IEC 5230

항목 ID요구사항자체인증 체크리스트
3.1.1오픈소스 정책 문서화Do you have a documented open source policy?
3.1.4프로그램 범위 정의Is the scope of your open source program documented?
3.5.1오픈소스 커뮤니티 참여 정책Do you have a policy for open source community participation?
3.5.1오픈소스 기여 프로세스Do you have a process for contributing to open source projects?

ISO/IEC 18974

항목 ID요구사항자체인증 체크리스트
4.1.1보안 보증 정책 문서화Do you have a documented open source security assurance policy?
4.1.4보안 프로그램 범위 정의Is the scope of your open source security assurance program documented?

4. 완료 확인 체크리스트

agent 실행 후 사람이 직접 확인해야 할 항목들입니다. 체크리스트를 모두 통과해야 이 챕터가 완료됩니다.

파일 생성 확인

  • output/policy/oss-policy.md 파일이 존재한다
  • output/policy/license-allowlist.md 파일이 존재한다

정책 내용 확인

  • 정책에 회사명과 실제 담당자 이름이 반영되어 있다
  • 우리 배포 방식에 맞는 라이선스 분류와 의무사항이 적용되어 있다
  • 오픈소스 기여 정책이 포함되어 있다 (기여 계획이 있는 경우)
  • 취약점 대응 절차가 포함되어 있다 (ISO/IEC 18974 요구사항)
  • 정책 검토 주기가 명시되어 있다 (예: 연 1회)

oss-policy.md 주요 섹션 목차 예시

생성된 정책 문서가 아래 섹션을 포함하고 있는지 확인합니다.

1. 목적 및 적용 범위
2. 정책 담당자 및 책임
3. 오픈소스 사용 허용 기준
4. 라이선스 의무 이행 절차
5. 오픈소스 기여 정책
6. 보안 취약점 대응 절차
7. 정책 위반 처리
8. 정책 검토 및 개정

license-allowlist.md 샘플 표 예시

생성된 허용 라이선스 목록이 배포 방식별로 올바르게 분류되어 있는지 아래 샘플과 비교합니다.

Markdown
| 라이선스   | 분류             | 내부 사용 | SaaS 배포   | 앱 배포     | 임베디드    |
| ---------- | ---------------- | --------- | ----------- | ----------- | ----------- |
| MIT        | Permissive       | ✓ 허용    | ✓ 허용      | ✓ 허용      | ✓ 허용      |
| Apache-2.0 | Permissive       | ✓ 허용    | ✓ 허용      | ✓ 허용      | ✓ 허용      |
| LGPL-2.1   | Weak Copyleft    | ✓ 허용    | ✓ 허용      | △ 조건부    | △ 조건부    |
| GPL-2.0    | Strong Copyleft  | ✓ 허용    | ✓ 허용      | ✗ 검토 필요 | ✗ 검토 필요 |
| AGPL-3.0   | Network Copyleft | ✓ 허용    | ✗ 검토 필요 | ✗ 검토 필요 | ✗ 검토 필요 |
산출물 예시

정책 산출물 Best Practice에서 생성된 파일의 실제 형식을 확인할 수 있습니다.

5. 다음 단계

이 챕터를 완료했으면 프로세스 설계 단계로 이동합니다. 오픈소스 프로세스는 정책에서 정의한 절차를 실제 업무 흐름으로 구체화하는 단계입니다.

실행 전 확인

현재 Claude 세션을 먼저 종료(/exit 또는 Ctrl+C)한 뒤, 새 터미널에서 아래 명령을 실행하세요.

Bash
cd agents/04-process-designer
claude

또는 오픈소스 프로세스: 사용부터 배포까지로 이동하여 챕터 문서를 읽고 진행합니다.

이 단계는 ISO/IEC 5230 3.1.1, 3.1.4, 3.5.1 및 ISO/IEC 18974 4.1.1, 4.1.4 요구사항을 충족합니다.