왜 거버넌스 체계가 필요한가

• 2009년 Busybox 소송 — 배포만 한 기업도 소송 대상이 됨, 공급망 전체가 동시에 리스크에 노출
• 개발자의 지식만으로는 부족 — 라이선스를 알아도 조직적 검토·기록 프로세스가 없으면 누락은 반드시 발생
• ISO 국제표준 — 이 체계를 만들기 위한 검증된 프레임워크, 전 세계 공급망이 공통 언어로 인정

오늘 강의에서 얻어갈 것

강의 구성 로드맵

OpenChain Project란?

• Linux Foundation이 운영하는 오픈소스 컴플라이언스 국제 프로젝트
• 핵심 철학: "공급망 전체가 함께 컴플라이언스를 지켜야만 한 기업이 안전하다"
• 글로벌 참여 기업: Qualcomm, Siemens, ARM, Bosch, Toyota 등

ISO/IEC 5230 — 라이선스 컴플라이언스

• 2020년 12월 제정 — 오픈소스 라이선스 컴플라이언스에 관한 유일한 국제표준
• OpenChain 규격(6가지 핵심 요구사항)이 ISO 표준으로 채택됨
• 공급망 연쇄 요구 — Bosch, Scania 등 대형 OEM이 공급자에게 준수를 요구하기 시작

ISO/IEC 5230의 6가지 핵심 요구사항

ISO/IEC 5230

ISO/IEC 18974 — 보안 보증

ISO/IEC 18974

• 2023년 제정 — 오픈소스 소프트웨어의 알려진 보안 취약점 관리를 위한 국제표준
• ISO/IEC 5230(라이선스)과 쌍으로 운영 — 컴플라이언스 + 보안의 두 축
• CVE 모니터링, 취약점 대응 프로세스, SBOM 기반 보안 관리를 다룸

ISO/IEC 42001 — AI 관리 시스템

ISO/IEC 42001

• 2023년 제정 — AI 시스템을 책임감 있게 개발·운영·관리하기 위한 AI 관리 시스템 표준
• ISO 9001, ISO 27001과 동일한 경영 시스템 구조 (PDCA 사이클)
• 오픈소스 담당자 관점: §5.2(AI 역할 정의), §6.1.2(AI SBOM), §8.5(AI 공급망 검증) 등이 교차

세 표준 비교 한눈에

자가 인증이란?

자가 인증 결과 예시

인증 후 얻을 수 있는 것

OpenChain 인증 선언 기업: LG전자, Kakao, SK텔레콤, 현대자동차 등 국내 다수 기업 포함

ISO/IEC 5230 입증자료 25개 한눈에

ISO/IEC 18974 전용 추가 항목 9개

파트 1 요약

6대 핵심 요소 전체 구조

1. 조직

역할·책임·역량을 정의하고 사람을 배치한다

오픈소스 관리 조직 (OSPO)

• 전담 OSPO 또는 역할 담당자 지정 — 규모와 무관하게 반드시 책임자 존재해야 함
• 핵심 역할: 오픈소스 프로그램 매니저(PM), 법무, IT/보안, 개발 대표
• 규모에 따라 1인 겸직 담당자 → 전담 팀으로 성장 가능

규모별 조직 구성 예시

담당자 역할 매트릭스

역할별 역량 정의 및 평가

18974 전용 참여자 목록 및 역할 문서화

• 참여자 전원 문서화 — 오픈소스 프로그램에 참여하는 모든 담당자의 이름·직함·담당 역할을 목록으로 관리
• 이력 관리 — 조직 변경·인사 이동 시마다 목록 갱신, 이전 버전 이력 보관
• 외부 참여자 포함 — 외부 법무 자문사, 오픈소스 컨설턴트 등 외부 참여자도 목록에 포함

2. 정책

모든 구성원이 따르는 성문화된 판단 기준을 만든다

정책 — 판단 기준의 통일

• 담당자마다 다른 판단 — 같은 MIT 라이선스라도 누구는 허용, 누구는 재검토 요청 → 일관성 붕괴
• 정책은 공통 규칙서 — 모든 구성원이 동일한 기준으로 판단·행동하도록 성문화한 문서
• ISO/IEC 5230·18974 공통 요구 — 두 표준 모두 문서화된 오픈소스 정책을 첫 번째 요구사항으로 규정

정책에 담아야 할 핵심 항목

라이선스 컴플라이언스 정책 — 상세 항목

보안 보증 정책 — 상세 항목

18974 전용 성과 메트릭 정의

18974 전용 지속적 개선 원칙

프로그램 적용 범위 정의

• 적용 대상 명시 — 어떤 제품·서비스·팀·공급 소프트웨어에 이 프로그램이 적용되는지 문서화
• 적용 제외 범위 — 내부 도구, 연구 목적 프로토타입, 폐기 예정 레거시 등 예외 범위 정의
• 정기 재검토 — 신제품 출시·조직 개편·사업 영역 변경 시마다 범위 최신화

역할 배치 및 예산 확인

• 담당자 지정 확인 — 각 역할(PM·법무·IT·개발 대표)에 실제 이름이 지정되어 있음을 문서로 확인
• 예산 승인 확인 — 도구 라이선스·외부 교육·법률 자문 등 프로그램 운영 예산이 승인되어 있음을 확인
• 백업 체계 — 핵심 담당자 부재(휴가·이직) 시 누가 역할을 대행하는지 정의

전문 자문 제공 방법

• 자문 요청 절차 — 라이선스 해석·분쟁·계약 검토가 필요한 경우 내부 법무팀 또는 외부 전문 자문에 접근하는 절차를 문서화
• 자문 프로세스 — 요청 → 검토 → 회신 → 기록 보관 흐름 명시, 회신 기한(예: 영업일 5일) 설정
• 소규모 기업 대안 — 외부 로펌, OpenChain 파트너사 자문 서비스, 법무법인 오픈소스 전담팀 활용

내부 책임 할당 절차

미준수 사례 검토 및 시정 절차

외부 문의 공개 채널 운영

• 채널 예시 — opensource@company.com, 웹 문의 양식, GitHub 이슈, 전용 포털
• 채널 공개 위치 — 제품 패키지·웹사이트·오픈소스 고지문·앱 스토어 설명에 명시
• 채널 구분 — 라이선스 문의와 보안 취약점 신고 채널을 분리하여 운영 권장

외부 문의 내부 대응 절차

정책 템플릿 — 바로 사용 가능한 출발점

• ISO 5230 + 18974 모두 충족 설계 — 25+9개 입증자료 요건 반영
• 라이선스 컴플라이언스·보안·기여·외부문의 항목 포함
• CC BY 4.0 — 무료 사용·수정·배포 가능

3. 프로세스

정책이 실제로 작동하는 절차와 흐름을 설계한다

3. 프로세스 — 오픈소스 사용 흐름도

SBOM 수명주기 관리 절차

컴플라이언스 산출물 준비·배포

• 산출물 3종 — ① 오픈소스 고지문(NOTICE) ② 소스코드 패키지(GPL 등) ③ SBOM
• 배포 방법 — 제품 패키지 동봉, 공식 웹사이트 게시, 서면 요청 시 제공(written offer)
• 버전 관리 — 릴리스마다 별도 산출물 생성, 버전·배포처·날짜 기록

컴플라이언스 산출물 보관 절차

• 보관 기간 — 제품 판매 종료 후 최소 3년 (GPL §3 written offer 유효 기간 기준)
• 보관 방법 — 버전 관리 시스템(Git), 아카이브 스토리지, 클라우드 백업으로 이중 보관
• 기록 항목 — 버전·배포 일자·배포처·제공 방법별로 언제 어떤 산출물을 제공했는지 이력 유지

보안 취약점 대응 프로세스

18974 전용 취약점 처리 8가지 방법

취약점 및 조치 기록

18974 전용 주기적 검토 및 변경 증거

• 정기 검토 의무 — 프로그램의 역할·역량·절차·도구를 정기적으로 검토하고 변경 이력을 기록
• 최소 검토 주기 — 연 1회 이상 (조직 변경·신규 표준 발행·보안 사고 발생 시 수시 검토)
• 변경 사항 문서화 — 검토 일시, 참여자, 변경 내용, 변경 이유를 기록하여 보관

18974 전용 내부 모범 사례 일치 검증

• 검증 대상 — 조직의 보안 관련 내부 모범 사례가 오픈소스 보안 보증 프로그램과 일치하는지 확인
• 모범 사례 출처 — OpenChain 권고사항, NIST SSDF(Secure Software Development Framework), OWASP Top 10 등
• 불일치 시 조정 — 내부 모범 사례와 표준 요구사항 간 차이가 발견되면 조정 절차와 결과를 문서화

오픈소스 기여 프로세스

프로세스 템플릿 — 바로 사용 가능한 절차서

• 포함 절차: 오픈소스 사용·검토·배포 / 외부 문의 대응 / 취약점 대응 / SBOM 관리 / 기여·공개
• ISO 5230·18974 입증자료 매핑 포함 — 어떤 절차가 어떤 입증자료를 커버하는지 명시
• CC BY 4.0 — 무료 사용·수정 가능

4. 도구

사람이 감당할 수 없는 규모를 자동화로 해결한다

4. 도구 — 수작업의 한계

오픈소스 거버넌스 도구 생태계

소스코드 스캔: FOSSology & SCANOSS

SBOM 생성: cdxgen & Syft

거버넌스·SBOM 관리: FOSSLight & Dependency-Track

CI/CD 파이프라인 연동 아키텍처

cdxgen + Dependency-Track: 하루 만에 자동화 환경 구축

5. 교육

체계가 현장에서 작동하려면 사람이 알고 있어야 한다

5. 교육 — 체계의 마지막 퍼즐

• 정책·프로세스의 한계 — 아무리 잘 만들어도 구성원이 인식하지 않으면 현장에서 작동하지 않는다
• 교육 대상 — 공급 소프트웨어의 개발·배포에 관여하는 모든 직원 (개발자·PM·법무·경영진 포함)
• ISO 요구 3가지 — ① 오픈소스 정책의 존재 인식 ② 정책의 목적 이해 ③ 미준수 시 영향 인지

정책 전파 절차

• 전파 방법 — 신규 입사자 온보딩, 내부 위키/인트라넷 게시, 정기 교육(연 1회 이상)
• 전파 대상 — 공급 소프트웨어의 개발·배포·검토에 관여하는 모든 직원에게 전파
• 전파 확인 — 교육 이수 서명, LMS 완료 기록, 온보딩 체크리스트로 확인 및 보관

신규 입사자 교육 설계

교육 효과 측정 및 인식 평가

교육 자료 — 무료로 시작하기

• OpenChain KWG 가이드 — 정책·프로세스 템플릿, 입증자료 체크리스트, 조항별 가이드
• NIPA 오픈소스 라이선스 가이드 — 국내 기업 대상 실무 해설

참고 — SK텔레콤 오픈소스 가이드

기업이 공개한 실무 중심 오픈소스 가이드 — 사용·기여·공개·공급망 보안을 단계별로 안내

6. 준수·개선

갖춘 체계를 공식 확인하고 지속적으로 유지한다

6. 준수·개선 — 준수 선언이란?

자가 인증 절차 상세

인증 후 18개월 유지 의무

• 18개월 재확인 — 인증 취득 후 18개월 이내에 모든 요구사항을 여전히 충족하고 있음을 재확인
• 연 1회 내부 감사 — 25개(+9개) 입증자료 현행화 여부 점검, 담당자 변경·프로세스 갱신 반영
• 표준 버전 갱신 대응 — 새 버전 발행 시 18개월 유예 기간 내 갱신 권장

성과 메트릭 측정 및 개선

지속적 개선 증거 수집

• 개선 활동 기록 — 무엇을 왜 변경했는지 문서화 (변경 전 상태 → 변경 후 상태 → 효과)
• 연 1회 전체 프로그램 리뷰 — 6대 요소 전체를 점검하고 개선 보고서 작성, 경영진 보고
• 개선 전·후 메트릭 비교 — 수치로 효과를 증명 → "개선했다"는 주장이 아닌 증거

ISO 5230 + 18974 통합 준수 체크

파트 2 요약

AI 컴플라이언스 — 기존 거버넌스로 충분한가?

AI 시스템 오픈소스 3대 영역

AI 프레임워크 라이선스 관리

① AI 프레임워크

• 기존 프로세스 그대로 적용 — AI 개발에 사용하는 오픈소스 프레임워크는 일반 소프트웨어와 동일하게 ISO/IEC 5230 프로세스를 적용
• 기존 도구 활용 — cdxgen, Syft 등 기존 스캔 도구로 AI 코드 저장소도 분석 가능
• SBOM에 포함 — SBOM에 AI 프레임워크·라이브러리와 버전 정보를 반드시 포함

AI 프레임워크 주요 라이선스

① AI 프레임워크

오픈소스 AI 모델 라이선스 관리

② 사전 훈련 모델

• 커스텀 라이선스 주의 — 사전 훈련 모델은 일반 오픈소스와 달리 모델별 커스텀 라이선스를 사용하는 경우가 많음
• 다양한 제한 조건 — 상업적 사용 제한, 사용자 수(MAU) 기반 제한, 파생 모델 공개 의무 등 조건이 모델마다 다름
• 개별 직접 확인 필수 — Hugging Face 모델 허브에서 모델 카드(Model Card)와 라이선스를 반드시 직접 확인

AI 모델 라이선스 유형 비교

② 사전 훈련 모델

학습 데이터셋 라이선스 관리

③ 학습 데이터셋

AI-BOM (AI SBOM)이란?

• 일반 SBOM의 AI 버전 — AI 시스템의 구성 요소(프레임워크·모델·데이터셋)를 명세한 문서
• SPDX 3.0 AI Profile — 국제 표준 형식으로 AI-BOM을 작성하면 공급망 신뢰 확보 가능
• ISO/IEC 42001 §7.5 직접 대응 — AI 시스템 문서화 요구사항을 AI-BOM으로 충족

AI-BOM 실제 예시 (SPDX 3.0 AI Profile)

# AI SBOM 모델 항목 예시 (SPDX 3.0 AI Profile 기반)
- name: "meta-llama/Llama-3.1-8B"
  version: "3.1"
  license: "Llama Community License Agreement"
  primaryPurpose: "inference"
  hyperparameter:
    contextWindow: 131072
  modelCard: "https://huggingface.co/meta-llama/Meta-Llama-3.1-8B"

- name: "CommonCrawl-2024Q1"
  type: "dataset"
  license: "CC0-1.0"
  source: "https://commoncrawl.org/"

- name: "torch"
  version: "2.3.0"
  license: "BSD-3-Clause"
  type: "framework"

ISO/IEC 42001 — 오픈소스 담당자 교차 조항 & 체크포인트

파트 3 요약

Trusted OSS란?

AI Agent와 대화하며 오픈소스 거버넌스 체계를 스스로 구축하는 셀프스터디 플랫폼

• ISO/IEC 5230·18974 기반 셀프스터디 모드 제공
• Agent와 대화하며 우리 회사 상황에 맞는 정책·프로세스 설계
• 가이드 링크와 템플릿을 실시간으로 안내받으며 진행

데모 시나리오 미리보기

데모 후: 혼자서 따라가는 방법

1. Step 1 trustedoss.github.io/docs 접속
2. Step 2 셀프스터디 모드에서 현재 상황 입력 (팀 규모, 현재 체계 수준)
3. Step 3 Agent 안내에 따라 가이드·템플릿 활용
4. Step 4 자가 인증 체크리스트로 진행 현황 점검

오늘 배운 핵심 3가지

OpenChain KWG — 함께 만드는 오픈소스 컴플라이언스