ISO/IEC 5230 준수 가이드

• 1: §3.1 프로그램 기반
• 1.1: §3.1.1 정책
• 1.2: §3.1.2 역량
• 1.3: §3.1.3 인식
• 1.4: §3.1.4 프로그램 범위
• 1.5: §3.1.5 라이선스 의무
• 2: §3.2 관련 업무
• 2.1: §3.2.1 외부 문의 대응
• 2.2: §3.2.2 효과적 리소스
• 3: §3.3 콘텐츠 검토 및 승인
• 3.1: §3.3.1 SBOM
• 3.2: §3.3.2 라이선스 컴플라이언스
• 4: §3.4 컴플라이언스 산출물
• 4.1: §3.4.1 산출물
• 5: §3.5 커뮤니티 참여
• 5.1: §3.5.1 기여
• 6: §3.6 규격 준수
• 6.1: §3.6.1 적합성
• 6.2: §3.6.2 지속 기간

1 - §3.1 프로그램 기반

1.1 - §3.1.1 정책

1. 조항 개요

오픈소스 정책이 없는 기업은 개발자가 오픈소스 라이선스 의무를 인지하지 못한 채 소프트웨어를 배포하게 되며, 이는 저작권 침해 소송, 소스코드 강제 공개, 거래처 계약 해지 등 심각한 법적·사업적 위험으로 이어질 수 있다. §3.1.1은 이러한 위험을 예방하기 위해 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 정책을 수립하고, 조직 내 모든 프로그램 참여자가 정책의 존재를 인식할 수 있도록 전파할 것을 요구한다. 이 조항은 ISO/IEC 5230 프로그램 전체의 기반이 되며, 이후 모든 조항(역량·프로세스·산출물 등)은 이 정책 위에서 작동한다.

2. 해야 할 활동

• 오픈소스 라이선스 컴플라이언스를 관리하는 정책 문서를 작성하고 공식화한다.
• 정책에 적용 범위(외부 배포 소프트웨어, 기여 활동, 사내 공개 등)를 명확히 정의한다.
• 정책 내에 오픈소스 사용·기여·배포·SBOM 관리·보안 취약점 대응 원칙을 포함한다.
• 프로그램 참여자(개발자·법무·IT·보안 등)에게 정책을 전파하는 절차를 수립하고 문서화한다.
• 전파 사실을 증명할 수 있는 기록(교육 이수, 공지 이력 등)을 보관한다.
• 정기적으로 정책을 검토하고 변경 시 재전파하는 절차를 정책 내에 포함한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.1.1.1 문서화된 오픈소스 정책

준수 방법

오픈소스 정책은 기업이 오픈소스 소프트웨어를 안전하고 효과적으로 활용하기 위한 원칙과 절차를 담은 공식 문서다. 정책 문서에는 목적, 적용 범위, 역할과 책임, 오픈소스 사용·기여·배포 원칙, SBOM 관리, 보안 취약점 대응, 교육 및 검토 주기 등 핵심 항목이 포함되어야 한다. 이 문서 자체가 입증자료 3.1.1.1에 해당하므로 반드시 공식 문서로 관리해야 하며, 버전과 승인 이력을 기록해야 한다.

정책 수립 시에는 회사의 비즈니스 환경과 소프트웨어 공급망 특성을 반영해야 한다. 예를 들어 외부에 소프트웨어를 배포하는 제품 기업과 서비스 기업은 컴플라이언스 산출물 생성 의무 범위가 다를 수 있으므로, 적용 범위를 명확하게 정의한다. 정책은 법무팀 또는 OSRB(Open Source Review Board)의 검토를 거쳐 최고 경영진 또는 권한 있는 부서장이 승인하는 절차를 거쳐야 한다.

정책은 한 번 수립한 뒤 방치하는 문서가 아니다. ISO/IEC 5230 요구사항 변경, 새로운 라이선스 유형의 등장, 법적 환경 변화 등을 반영하여 최소 연 1회 정기 검토를 실시하고, 변경 이력을 문서에 기록해야 한다.

고려사항

• 포함 항목: 오픈소스 사용, 외부 기여, 사내 프로젝트 공개, SBOM 관리, 보안 취약점 대응 원칙을 정책에 모두 포함한다.
• 적용 범위 명시: 외부 배포 소프트웨어, 내부 사용 소프트웨어, 기여 활동 등 정책이 적용되는 범위를 명확하게 구분한다.
• 승인 절차: OSRB 또는 법무팀장 이상이 최종 승인하고, 승인 날짜와 승인자를 문서에 기록한다.
• 버전 관리: 문서 버전 번호와 변경 이력을 유지하여 감사 시 이전 버전과 비교할 수 있도록 한다.
• 정기 검토: 연 1회 이상 정책을 검토하며, 검토 완료 날짜와 검토자를 기록한다.

샘플

아래는 오픈소스 정책 문서의 목적 및 적용 범위 샘플이다. 이 텍스트 자체가 입증자료 3.1.1.1(문서화된 오픈소스 정책)의 핵심 구성 요소가 된다.

## 1. 목적 및 적용 범위

### 1.1 목적

이 정책은 회사가 오픈소스 소프트웨어를 안전하고 효과적으로 활용하기 위한 원칙과
절차를 제공합니다. 정책의 주요 목적은 다음과 같습니다:

1. 오픈소스 라이선스 컴플라이언스:
   공급 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 의무를 준수하고,
   관련 법적 요구사항을 충족합니다.
2. 오픈소스 보안 보증:
   공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 식별하고,
   적절한 대응 조치를 통해 보안 위험을 최소화합니다.

이러한 원칙은 ISO/IEC 5230(오픈소스 라이선스 컴플라이언스) 및
ISO/IEC 18974(오픈소스 보안 보증)의 요구사항을 충족하도록 설계되었습니다.

### 1.4 적용 범위

이 정책은 회사가 개발, 배포, 또는 사용하는 모든 소프트웨어 프로젝트에 적용됩니다.

- 외부로 제공하거나 배포하는 모든 공급 소프트웨어.
- 외부 오픈소스 프로젝트에 기여하는 활동.
- 내부 프로젝트를 오픈소스로 공개하는 활동.

단, 내부 사용 목적으로만 사용되는 오픈소스는 별도의 검토 절차를 통해
정책 적용 여부를 결정할 수 있습니다.

정책의 적용 범위는 회사의 비즈니스 환경 변화에 따라 정기적으로 검토되고 갱신됩니다.

3.1.1.2 정책 인식 방법 문서화

준수 방법

정책 문서를 작성하는 것만으로는 부족하다. 프로그램 참여자(소프트웨어 개발·배포·기여에 관여하는 모든 직원)가 정책의 존재를 실제로 인식할 수 있도록 전파 절차를 수립하고 문서화해야 한다. 전파 절차 문서에는 어떤 채널을 통해, 언제, 누구에게 정책을 전달하는지 구체적으로 명시해야 한다. 이 전파 절차 문서 자체가 입증자료 3.1.1.2다.

전파 방법은 복수의 채널을 조합하는 것이 효과적이다. 신규 입사자에게는 온보딩 과정에 오픈소스 정책 안내를 포함하고, 기존 직원에게는 사내 위키 게시와 이메일 공지를 활용한다. 정책 변경 시에는 변경 내용을 즉시 공지하는 절차도 포함해야 한다. 전파 사실을 증명하기 위해 공지 발송 이력, 교육 이수 기록, 정책 인식 확인 서명 등의 증거를 최소 3년간 보관한다.

고려사항

• 복수 채널 활용: 사내 위키, 이메일 공지, 온보딩 교육 등 둘 이상의 채널을 활용하여 전파 효과를 높인다.
• 신규 입사자: 온보딩 프로세스에 오픈소스 정책 안내를 필수 항목으로 포함한다.
• 정책 변경 시: 변경 사항을 프로그램 참여자에게 즉시 공지하는 별도 절차를 수립한다.
• 증거 보관: 공지 이력, 교육 이수 확인서, 정책 인식 확인 서명을 최소 3년간 보관한다.
• 접근성: 정책 문서를 사내 포털이나 위키에 항시 게시하여 참여자가 언제든 확인할 수 있도록 한다.

샘플

아래는 정책 전파 공지 이메일 샘플이다. 전송 이력을 보관하면 입증자료 3.1.1.2의 증거로 활용할 수 있다.

제목: [오픈소스] 오픈소스 정책 안내 및 숙지 요청

수신: 전체 개발/배포 관련 임직원
발신: 오픈소스 프로그램 매니저

안녕하세요.

당사의 오픈소스 정책이 제정(또는 개정)되었습니다.
오픈소스 소프트웨어를 사용, 기여, 또는 배포하는 업무에 관여하는
모든 임직원은 아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다.

- 정책 문서: [사내 포털 링크]
- 주요 내용: 오픈소스 사용 원칙, 라이선스 컴플라이언스 절차,
             SBOM 관리, 보안 취약점 대응 원칙
- 정책 버전: v1.0 (시행일: YYYY-MM-DD)

정책 내용에 대한 문의는 오픈소스 프로그램 매니저(oss@company.com)에게
연락해 주십시오.

감사합니다.
오픈소스 프로그램 매니저

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 2. 정책
• 관련 템플릿: 오픈소스 정책 템플릿

1.2 - §3.1.2 역량

1. 조항 개요

오픈소스 프로그램이 실제로 작동하려면 관련 역할을 맡은 사람들이 그 역할을 수행할 역량을 갖추어야 한다. 역할과 책임이 문서에만 적혀 있고 담당자가 오픈소스 라이선스나 보안 취약점 관리에 대한 기본 지식도 없다면, 정책과 프로세스는 유명무실해진다. §3.1.2는 프로그램에 관여하는 역할을 식별하고 각 역할에 필요한 역량을 정의하며, 참여자가 실제로 그 역량을 갖추었는지 평가하고 기록하도록 요구한다. 이 조항은 §3.1.1 정책에서 정의한 역할 구조를 구체적인 역량 체계로 발전시키는 단계다.

2. 해야 할 활동

• 오픈소스 프로그램의 성과에 영향을 미치는 역할과 각 역할의 책임을 목록으로 작성한다.
• 각 역할을 수행하는 데 필요한 역량(지식·기술·경험)을 구체적으로 정의하고 문서화한다.
• 각 프로그램 참여자가 해당 역할에 필요한 역량을 갖추었는지 평가한다.
• 역량이 미흡한 경우 교육·훈련·멘토링 등 역량 확보 조치를 취한다.
• 역량 평가 결과와 후속 조치 이력을 문서화하여 보관한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.1.2.1 역할과 책임 목록 문서

준수 방법

프로그램에 관여하는 모든 역할을 열거하고, 각 역할이 어떤 책임을 지는지 명확하게 정의한 문서를 작성해야 한다. 일반적으로 오픈소스 프로그램 매니저, 법무 담당, IT 담당, 보안 담당, 개발 문화 담당, 사업 부서가 핵심 역할에 해당한다. 기업 규모나 조직 구조에 따라 역할을 겸임하거나 OSRB(Open Source Review Board) 형태의 가상 조직으로 운영하는 것도 가능하다.

역할 정의 시 추상적인 서술보다 구체적인 책임 항목을 나열하는 것이 감사 시 입증에 유리하다. 예를 들어 “오픈소스 관리"가 아니라 “공급 소프트웨어에 사용된 오픈소스 컴포넌트의 라이선스 검토 및 SBOM 생성 감독"처럼 명확하게 기술한다. 이 문서는 오픈소스 정책 문서(§3.1.1.1)의 역할 및 책임 섹션에 포함하거나 별도 Appendix로 관리할 수 있다.

고려사항

• 역할 식별 범위: 개발·법무·IT·보안·구매 등 소프트웨어 공급망에 관여하는 모든 조직의 역할을 포함하며, 외주 개발 및 벤더 관리 담당도 검토한다.
• 책임 구체화: 역할별 책임은 추상적 서술이 아닌 구체적 활동 단위로 기술한다.
• 겸임 명시: 한 사람이 여러 역할을 겸임하는 경우 해당 사실을 문서에 명기한다.
• 갱신 주기: 조직 변경·인사 이동 발생 시 즉시 문서를 갱신하고 버전을 업데이트한다.

샘플

아래는 오픈소스 정책 Appendix의 역할·책임 목록 샘플이다. 오픈소스 정책 템플릿 Appendix 1에서 전체 양식을 확인할 수 있다.

| 역할 | 책임 |
|------|------|
| 오픈소스 프로그램 매니저 | 회사의 오픈소스 프로그램 총괄 / SBOM 생성 감독 /
                            외부 문의 대응 / 내부 모범 사례 관리 |
| 법무 담당 | 오픈소스 라이선스 의무 해석 및 검토 /
             라이선스 호환성 검토 / 법적 위험 평가 및 자문 |
| IT 담당 | 오픈소스 분석 도구 운영 및 CI/CD 파이프라인 통합 /
            SBOM 생성 자동화 지원 |
| 보안 담당 | 알려진 취약점 및 새로 발견된 취약점 대응 /
             DevSecOps 환경 통합 및 보안 조치 수행 |
| 개발 문화 담당 | 오픈소스 커뮤니티 참여 장려 / 교육 프로그램 운영 |
| 사업 부서 | 오픈소스 정책 및 프로세스 준수 / 오픈소스 식별 및 신고 |

3.1.2.2 역할별 필요 역량 문서

준수 방법

각 역할을 수행하기 위해 필요한 지식·기술·경험을 구체적으로 정의하고 문서화해야 한다. 역량 정의는 해당 역할을 새로 맡은 사람이 “내가 무엇을 알아야 하는가"를 명확히 파악할 수 있는 수준으로 작성한다. 단순히 “오픈소스 지식 필요"처럼 모호하게 쓰지 않고, “주요 오픈소스 라이선스(MIT, Apache-2.0, GPL-2.0 등)의 의무 사항 및 호환성 이해"처럼 구체적으로 기술한다.

역량 수준을 “기본 이해”, “실무 적용 가능”, “전문가” 등으로 세분화하면 평가 기준이 명확해지고 교육 계획을 수립하기 쉬워진다. 이 문서는 오픈소스 정책 문서에 포함하거나 별도 역량 정의서로 관리할 수 있으며, 정기적으로 검토하여 기술 환경 변화를 반영해야 한다.

고려사항

• 구체성: 역량 항목은 측정 가능한 수준으로 기술하여 평가 기준으로 활용할 수 있게 한다.
• 역량 수준 구분: “기본 이해 / 실무 적용 / 전문가” 등 수준을 정의하면 평가와 교육 설계가 용이해진다.
• 갱신 주기: 새로운 도구·라이선스·보안 기술 등장 시 역량 항목을 업데이트한다.
• 교육 연계: 정의된 역량을 기반으로 역할별 교육 커리큘럼을 설계한다.

샘플

아래는 역할별 필요 역량 정의표 샘플이다.

| 역할 | 필요 역량 |
|------|-----------|
| 오픈소스 프로그램 매니저 | 주요 오픈소스 라이선스 의무 및 호환성 이해 /
                            소프트웨어 개발 프로세스 이해 /
                            SBOM 생성·관리 지식 / 커뮤니케이션 스킬 |
| 법무 담당 | 소프트웨어 저작권법 전문 지식 /
             오픈소스 라이선스 해석 능력 / 법적 위험 평가 능력 |
| IT 담당 | 오픈소스 분석 도구(FOSSology, ORT, Syft 등) 운용 /
            CI/CD 파이프라인 이해 / IT 인프라 전문 지식 |
| 보안 담당 | DevSecOps 이해 / 취약점 분석 도구 운용 /
             CVSS 점수 해석 및 위험 평가 능력 |
| 개발 문화 담당 | 오픈소스 정책 이해 / 교육 설계 능력 /
                  오픈소스 커뮤니티 참여 경험 |
| 사업 부서 | 오픈소스 컴플라이언스 기본 지식 /
              오픈소스 라이선스 기본 이해 / 오픈소스 정책 이해 |

3.1.2.3 역량 평가 증거

준수 방법

각 프로그램 참여자가 정의된 역량을 실제로 갖추었는지 평가하고, 그 결과를 문서화하여 보관해야 한다. 평가 방법은 온라인 교육 이수 확인, 자격증 보유 여부 확인, 필기·실기 시험, 담당 업무 수행 실적 검토, 면담 등 다양한 방식을 조합할 수 있다. 중요한 것은 평가 결과가 기록으로 남아야 한다는 점이다. 이 기록 자체가 입증자료 3.1.2.3이다.

평가 결과 미흡한 역량이 발견되면 교육 수강, 외부 컨설팅, 멘토링 등 보완 조치를 취하고 그 완료 기록도 함께 보관한다. 평가는 최소 연 1회 정기적으로 실시하고, 담당자 변경 시에는 신규 담당자에 대해 즉시 초기 평가를 수행한다. 평가 기록은 사내 학습 관리 시스템(LMS) 또는 문서 시스템에 저장하여 감사 시 즉시 제출 가능한 상태로 유지한다.

고려사항

• 평가 방법 다양화: 온라인 교육 이수, 시험, 실무 수행 실적 등 복수의 방법을 조합하여 역량을 종합적으로 평가한다.
• 정기 평가 주기: 최소 연 1회 실시하며, 담당자 변경 시 즉시 신규 평가를 수행한다.
• 미흡 역량 보완: 평가 결과 미흡 항목에 대해 교육 계획을 수립하고 이수 후 재평가를 실시한다.
• 기록 보관 기간: 평가 기록은 최소 해당 담당자 재직 기간 동안 보관하며, 퇴직 후에도 감사 목적으로 일정 기간 유지한다.

샘플

아래는 역량 평가 기록부 샘플이다. 역할별로 작성하여 LMS 또는 문서 시스템에 보관한다.

| 이름 | 역할 | 평가 항목 | 평가 방법 | 평가 결과 | 평가일 | 비고 |
|------|------|-----------|-----------|-----------|--------|------|
| 홍길동 | 오픈소스 프로그램 매니저 | 라이선스 의무 이해 | 온라인 교육 이수 | 완료 (95점) | 2026-01-15 | - |
| 홍길동 | 오픈소스 프로그램 매니저 | SBOM 관리 지식 | 실무 평가 | 완료 | 2026-01-15 | - |
| 김철수 | 보안 담당 | DevSecOps 이해 | 외부 교육 이수 | 완료 | 2026-02-03 | 수료증 보관 |
| 이영희 | 법무 담당 | 오픈소스 라이선스 해석 | 면담 평가 | 완료 | 2026-01-20 | - |

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 1. 조직
• 관련 템플릿: 오픈소스 정책 템플릿 — Appendix 1. 담당자 현황

1.3 - §3.1.3 인식

1. 조항 개요

역할과 역량을 갖춘 참여자라도 오픈소스 프로그램의 목적과 자신의 기여가 전체 컴플라이언스 체계에 어떤 의미를 갖는지 인식하지 못하면 형식적 참여에 그치게 된다. §3.1.3은 프로그램 참여자가 프로그램의 목표, 자신의 기여 방법, 그리고 프로그램을 준수하지 않을 경우 발생하는 결과를 실제로 인식하고 있음을 평가하고 기록할 것을 요구한다. 이 조항은 §3.1.2 역량(지식·기술 보유)의 다음 단계로, 참여자가 보유한 역량을 프로그램 목적과 연결하여 실질적 동기를 형성하는 단계다.

2. 해야 할 활동

• 프로그램 참여자가 오픈소스 프로그램의 목표(라이선스 컴플라이언스, 보안 보증 등)를 이해하고 있는지 확인한다.
• 각 참여자가 자신의 역할이 전체 프로그램 운영에 어떻게 기여하는지 인식하고 있는지 평가한다.
• 프로그램 요구사항을 미준수할 경우 발생할 수 있는 법적·사업적 영향에 대해 참여자가 인식하고 있는지 확인한다.
• 인식 평가를 주기적으로 실시하고, 그 결과를 문서로 기록하여 보관한다.
• 인식이 미흡한 참여자에 대해서는 추가 교육을 실시하고 재평가 결과를 보관한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.1.3.1 참여자 인식 평가 증거

준수 방법

프로그램 참여자가 세 가지 핵심 내용을 인식하고 있음을 평가하고 그 결과를 기록해야 한다. 세 가지 핵심 내용은 ①프로그램의 목표(오픈소스 라이선스 컴플라이언스 및 보안 보증), ②자신의 역할이 프로그램에 기여하는 방법, ③프로그램을 준수하지 않을 경우 발생하는 법적·사업적 영향이다.

평가 방법은 온라인 퀴즈, 오프라인 설문, 교육 후 이수 확인, 인터뷰 등 다양하게 조합할 수 있다. 중요한 것은 평가 결과가 문서로 남아야 한다는 점이다. 이 기록이 입증자료 3.1.3.1에 해당한다. 평가는 최소 연 1회 정기적으로 실시하고, 신규 참여자는 프로그램 합류 시 즉시 초기 평가를 수행한다. 인식이 미흡한 참여자에 대해서는 추가 교육을 실시하고 재평가 결과를 함께 보관한다.

고려사항

• 평가 범위: 세 가지 핵심 인식(목표·기여·영향)을 모두 포함하는 평가 문항을 설계한다.
• 평가 주기: 최소 연 1회 정기 평가를 실시하고, 신규 참여자는 합류 즉시 초기 평가를 수행한다.
• 증거 형식: 퀴즈 결과, 서명된 정책 인식 확인서, 교육 이수 증명 등 감사 시 제출 가능한 형식으로 보관한다.
• 미흡자 조치: 평가 결과 미흡한 참여자에 대해 추가 교육을 실시하고 재평가 기록을 남긴다.
• 접근성: 평가에 활용되는 정책 문서 및 교육 자료를 사내 포털에 항상 접근 가능한 상태로 유지한다.

샘플

아래는 참여자 인식 평가 기록부 샘플이다. 교육 이수 시 작성하여 LMS 또는 문서 시스템에 보관한다.

| 이름 | 역할 | 평가 항목 | 평가 방법 | 결과 | 평가일 | 비고 |
|------|------|-----------|-----------|------|--------|------|
| 홍길동 | 오픈소스 프로그램 매니저 | 프로그램 목표 이해 | 온라인 퀴즈 | 완료 (90점) | 2026-01-15 | - |
| 홍길동 | 오픈소스 프로그램 매니저 | 미준수 영향 인식 | 온라인 퀴즈 | 완료 (90점) | 2026-01-15 | - |
| 김철수 | 개발자 | 프로그램 목표 이해 | 온라인 퀴즈 | 완료 (85점) | 2026-01-20 | - |
| 이영희 | 보안 담당 | 자신의 기여 방법 인식 | 인터뷰 | 완료 | 2026-01-22 | 면담 기록 보관 |

아래는 정책 인식 확인서 샘플이다. 교육 완료 후 서명을 받아 보관하면 입증자료로 활용할 수 있다.

[오픈소스 정책 인식 확인서]

본인은 다음 사항을 숙지하였음을 확인합니다:

1. 당사 오픈소스 정책의 존재와 해당 문서의 위치
2. 오픈소스 라이선스 컴플라이언스 및 보안 보증 프로그램의 목표
3. 본인의 역할이 오픈소스 프로그램 운영에 기여하는 방법
4. 오픈소스 정책 및 프로세스를 준수하지 않을 경우 발생할 수 있는
   법적·사업적 위험

이름: ________________  역할: ________________
서명: ________________  날짜: ________________

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 5. 교육
• 관련 템플릿: 오픈소스 정책 템플릿 — §6 교육 및 인식 제고

1.4 - §3.1.4 프로그램 범위

1. 조항 개요

오픈소스 프로그램이 조직 전체에 적용되는지, 특정 제품군이나 사업 단위에만 적용되는지 명확하지 않으면 컴플라이언스 활동의 경계가 모호해지고 책임 소재가 불분명해진다. §3.1.4는 오픈소스 프로그램이 어떤 소프트웨어·조직 단위·배포 채널에 적용되는지, 그리고 어디까지가 적용 범위 밖인지를 명확하게 정의한 문서화된 진술을 요구한다. 적용 범위는 조직의 규모와 비즈니스 모델에 따라 다를 수 있으며, 이 조항은 그 선택을 명시적으로 기록하도록 한다.

2. 해야 할 활동

• 오픈소스 프로그램이 적용되는 소프트웨어 유형(외부 배포 제품, 서비스, 내부 시스템 등)을 결정한다.
• 프로그램이 적용되는 조직 범위(전사, 특정 사업부, 특정 제품군 등)를 정의한다.
• 적용 범위에서 명시적으로 제외되는 항목이 있다면 해당 예외 사항과 그 근거를 함께 기록한다.
• 적용 범위 진술을 문서화하여 오픈소스 정책 또는 별도 문서로 공식 관리한다.
• 비즈니스 환경 변화(신규 사업 진출, 인수합병 등) 시 적용 범위를 재검토하고 갱신한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.1.4.1 프로그램 적용 범위 진술

준수 방법

프로그램이 어디에 적용되고 어디에 적용되지 않는지를 명확하게 서술한 문서를 작성해야 한다. 이 진술은 오픈소스 정책 문서(§3.1.1.1)의 적용 범위 섹션에 포함하거나 별도 문서로 관리할 수 있다. 핵심은 경계가 명확해야 한다는 점이다. 예를 들어 “외부에 배포하는 모든 소프트웨어 제품"처럼 명확하게 기술하거나, “A 사업부가 개발하는 임베디드 소프트웨어에 한정"처럼 범위를 구체적으로 한정할 수 있다.

적용 범위를 결정할 때는 소프트웨어 배포 형태(바이너리 제품, SaaS, 내부 도구), 오픈소스 사용 방식(직접 사용, 간접 의존성), 외부 기여 활동 등을 종합적으로 고려한다. 내부 사용 목적 소프트웨어에 대한 처리 방침도 명시하는 것이 바람직하다. 적용 범위 진술은 비즈니스 환경 변화에 따라 정기적으로 검토하고 버전을 관리해야 한다.

고려사항

• 배포 형태 구분: 외부 배포 제품, SaaS 서비스, 내부 시스템 등 소프트웨어 배포 유형별로 적용 여부를 명시한다.
• 조직 범위 명시: 전사 적용인지, 특정 사업부·제품군에만 적용되는지 명확하게 기술한다.
• 예외 항목 기록: 적용 범위에서 제외되는 항목이 있다면 예외 사유와 함께 문서에 명기한다.
• 갱신 주기: 신규 사업 진출, 인수합병, 제품 포트폴리오 변경 시 즉시 재검토하고 버전을 업데이트한다.
• 정책 연계: 적용 범위 진술은 오픈소스 정책 §1.4 적용 범위 섹션과 일관성을 유지한다.

샘플

아래는 오픈소스 정책 내 적용 범위 진술 샘플이다. 이 텍스트 자체가 입증자료 3.1.4.1에 해당한다.

## 프로그램 적용 범위

본 오픈소스 프로그램은 다음 범위에 적용된다:

**적용 대상**
- 회사가 외부에 배포하거나 판매하는 모든 소프트웨어 제품 (임베디드 소프트웨어
  포함)
- 외부 오픈소스 프로젝트에 대한 기여 활동
- 내부 프로젝트를 오픈소스로 공개하는 활동

**적용 제외**
- 외부에 배포되지 않고 사내에서만 사용되는 소프트웨어 (단, 별도 검토 절차
  적용 가능)
- 제3자로부터 도입하는 상용 소프트웨어 (단, 오픈소스 포함 여부 검토 필요)

**조직 범위**
본 프로그램은 [회사명] 전 사업부에 적용되며, 자회사 및 계열사는 별도 협의를
통해 적용 여부를 결정한다.

이 적용 범위는 비즈니스 환경 변화에 따라 연 1회 이상 검토하며,
변경 시 오픈소스 프로그램 매니저가 개정 버전을 공표한다.

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 2. 정책
• 관련 템플릿: 오픈소스 정책 템플릿 — §1.4 적용 범위

1.5 - §3.1.5 라이선스 의무

1. 조항 개요

오픈소스 컴포넌트를 소프트웨어에 포함할 때 가장 핵심적인 작업은 해당 컴포넌트에 적용된 라이선스가 부과하는 의무·제한·권리를 정확히 파악하는 것이다. 라이선스 의무를 검토하지 않고 배포하면 소스코드 강제 공개, 저작권 고지 누락, 특허 조항 위반 등 심각한 법적 리스크가 발생할 수 있다. §3.1.5는 식별된 모든 라이선스에 대해 의무·제한·권리를 검토하고 기록하는 절차를 수립하도록 요구한다. 이 절차는 §3.3.2 라이선스 컴플라이언스 프로세스의 토대가 된다.

2. 해야 할 활동

• 소프트웨어에 사용된 오픈소스 컴포넌트의 라이선스를 식별하고 목록화한다.
• 각 라이선스가 부과하는 의무(고지 의무, 소스코드 공개 의무 등), 제한(상업적 사용 제한, 특허 사용 제한 등), 권리(사용·수정·재배포 권리 등)를 검토한다.
• 검토 결과를 라이선스별로 문서화하고 기록을 유지한다.
• 라이선스 해석에 불확실성이 있는 경우 법무 담당에게 검토를 의뢰하는 절차를 수립한다.
• 신규 라이선스 등장 또는 기존 라이선스 해석 변경 시 절차를 갱신한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.1.5.1 라이선스 의무 검토 절차

준수 방법

각 오픈소스 라이선스의 의무·제한·권리를 검토하고 기록하는 절차를 문서화해야 한다. 절차에는 ①라이선스 식별, ②의무·제한·권리 분석, ③검토 결과 기록, ④불확실 사항에 대한 법무 검토 의뢰, ⑤기록 보관의 단계가 포함되어야 한다. 이 절차 문서 자체가 입증자료 3.1.5.1이다.

라이선스별 의무는 사전에 정리된 라이선스 데이터베이스(SPDX License List 등)를 활용하면 효율적으로 관리할 수 있다. 주요 라이선스(MIT, Apache-2.0, GPL-2.0, GPL-3.0, LGPL-2.1, AGPL-3.0 등)에 대한 의무 요약표를 미리 작성해 두고, 신규 라이선스 발견 시 즉시 추가 검토하는 방식이 실무적으로 효과적이다. 복잡한 라이선스 조합이나 법적 판단이 필요한 경우 법무 담당에게 에스컬레이션하는 기준도 절차에 명시한다.

고려사항

• SPDX 활용: SPDX License List를 기준 라이선스 목록으로 사용하면 식별과 분류가 표준화된다.
• 의무 유형 구분: 고지 의무, 소스코드 공개 의무, 특허 조항, 상표 제한 등 의무 유형을 구분하여 기록한다.
• 배포 형태별 검토: 바이너리 배포, SaaS, 내부 사용 등 배포 형태에 따라 라이선스 의무가 달라질 수 있으므로 형태별로 검토한다.
• 에스컬레이션 기준: 법무 검토가 필요한 상황(라이선스 충돌, 비표준 라이선스, 상업적 제한 조항 등)을 절차에 명시한다.
• 갱신 주기: 신규 라이선스 채택 또는 기존 라이선스 해석 변경 시 즉시 절차와 기록을 갱신한다.

샘플

아래는 주요 오픈소스 라이선스 의무 요약표 샘플이다. 라이선스 검토 절차의 일환으로 작성하여 보관하면 입증자료로 활용할 수 있다.

| 라이선스 | 고지 의무 | 소스코드 공개 | 수정본 동일 라이선스 | 특허 조항 | 상업적 사용 |
|----------|-----------|--------------|----------------------|-----------|-------------|
| MIT | O | X | X | X | O |
| Apache-2.0 | O | X | X | O (특허 허여) | O |
| GPL-2.0 | O | O (배포 시) | O | X | O |
| GPL-3.0 | O | O (배포 시) | O | O (특허 허여) | O |
| LGPL-2.1 | O | O (라이브러리) | O (라이브러리) | X | O |
| AGPL-3.0 | O | O (네트워크 포함) | O | O (특허 허여) | O |
| MPL-2.0 | O | O (파일 단위) | O (파일 단위) | O (특허 허여) | O |
| BSD-2-Clause | O | X | X | X | O |
| BSD-3-Clause | O | X | X | X | O |

아래는 라이선스 의무 검토 절차 개요 샘플이다.

[라이선스 의무 검토 절차]

1. 라이선스 식별
   - SBOM 생성 도구(FOSSology, ORT 등)를 통해 오픈소스 컴포넌트 및
     라이선스를 식별한다.

2. 의무·제한·권리 분석
   - 사전 작성된 라이선스 의무 요약표를 참조하여 해당 라이선스의
     의무·제한·권리를 확인한다.
   - 요약표에 없는 라이선스는 SPDX License List 및 라이선스 원문을
     검토하여 신규 항목을 추가한다.

3. 법무 검토 의뢰 (해당 시)
   - 라이선스 충돌, 비표준 라이선스, 상업적 제한 조항이 포함된 경우
     법무 담당에게 검토를 의뢰한다.

4. 검토 결과 기록
   - 검토 결과를 SBOM 또는 라이선스 검토 기록서에 기록하고
     오픈소스 관리 시스템에 보관한다.

5. 의무 이행 확인
   - 배포 전 라이선스 의무(고지문 포함, 소스코드 공개 등)가 완료되었는지
     확인한다.

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 템플릿: 오픈소스 프로세스 템플릿

2 - §3.2 관련 업무

2.1 - §3.2.1 외부 문의 대응

1. 조항 개요

소프트웨어를 배포하는 기업은 제3자(고객, 오픈소스 저작권자, 연구자 등)로부터 오픈소스 라이선스 컴플라이언스에 관한 문의를 받을 수 있다. 이 문의에 제때 응답하지 못하면 저작권 침해 분쟁으로 확대될 위험이 있다. §3.2.1은 외부 문의를 접수할 수 있는 공개된 연락 수단을 마련하고, 내부적으로는 문의에 체계적으로 대응하기 위한 절차를 문서화하도록 요구한다. 이 조항은 공개 채널(입증자료 3.2.1.1)과 내부 대응 절차(입증자료 3.2.1.2) 두 가지를 모두 갖출 것을 요구한다.

2. 해야 할 활동

• 제3자가 오픈소스 라이선스 컴플라이언스 문의를 보낼 수 있는 공개 연락처(이메일 주소, 웹폼 등)를 제품 또는 웹사이트에 명시한다.
• 외부 문의 접수부터 검토·답변·종결까지의 내부 대응 절차를 문서화한다.
• 문의 유형별 담당자(오픈소스 프로그램 매니저, 법무 담당 등)와 에스컬레이션 경로를 절차에 포함한다.
• 문의 접수 및 대응 이력을 기록하고 보관한다.
• 정기적으로 공개 연락처 유효성과 내부 절차의 최신성을 점검한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.2.1.1 공개된 외부 문의 채널

준수 방법

제3자가 오픈소스 라이선스 컴플라이언스에 관한 문의를 보낼 수 있는 수단을 공개적으로 명시해야 한다. 가장 일반적인 방법은 전용 이메일 주소(예: oss@company.com)를 제품 설명서, 소프트웨어 오픈소스 고지문, 또는 회사 웹사이트에 게시하는 것이다. 이 공개 연락처 자체가 입증자료 3.2.1.1이다.

연락처는 담당자 개인 이메일이 아닌 역할 기반 주소(role-based address)를 사용하는 것이 좋다. 담당자가 변경되더라도 주소가 유지되며, 문의가 누락되지 않도록 팀 메일함으로 관리하는 것이 바람직하다. OpenChain Conformance 웹사이트에 연락처를 등록하는 방법도 활용할 수 있다.

고려사항

• 역할 기반 주소 사용: 개인 이메일 대신 oss@company.com과 같은 역할 기반 주소를 사용하여 담당자 변경에 대비한다.
• 게시 위치: 제품 매뉴얼, 오픈소스 고지문(NOTICES 파일), 회사 웹사이트 등 제3자가 쉽게 찾을 수 있는 위치에 게시한다.
• 응답 가능성 확인: 게시된 연락처가 실제로 수신되고 모니터링되는지 정기적으로 점검한다.
• 다국어 고려: 글로벌 제품의 경우 영문 연락처도 함께 제공한다.

샘플

아래는 제품 오픈소스 고지문 또는 웹사이트에 게시하는 공개 연락처 샘플이다.

오픈소스 라이선스 컴플라이언스 문의

이 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 컴플라이언스에 관한
문의는 아래 이메일로 연락해 주십시오.

- 이메일: oss@company.com
- 응답 기간: 영업일 기준 14일 이내

Open Source License Compliance Inquiry

For inquiries regarding open source license compliance of this software,
please contact: oss@company.com

3.2.1.2 내부 외부 문의 대응 절차

준수 방법

외부 문의가 접수되었을 때 어떻게 처리할지를 정의한 내부 절차를 문서화해야 한다. 절차에는 ①문의 접수 및 분류, ②담당자 배정, ③검토 및 답변 작성, ④법무 검토 (필요 시), ⑤답변 발송, ⑥기록 보관의 단계가 포함되어야 한다. 이 절차 문서가 입증자료 3.2.1.2다.

답변 기한은 합리적인 범위에서 설정하고 절차에 명시한다. 일반적으로 14일 이내 초기 응답, 60일 이내 최종 답변을 기준으로 삼는 경우가 많다. 문의 접수·처리· 종결 이력은 사내 시스템에 기록하여 감사 시 제출할 수 있도록 보관한다.

고려사항

• 담당자 및 에스컬레이션: 1차 담당자(오픈소스 프로그램 매니저)와 법무 검토 에스컬레이션 경로를 절차에 명시한다.
• 응답 기한: 초기 응답과 최종 답변의 기한을 절차에 명시하고 준수한다.
• 기록 보관: 문의 내용, 검토 과정, 최종 답변을 기록하고 최소 3년간 보관한다.
• 유형별 대응: 라이선스 고지 요청, 소스코드 제공 요청, 저작권 침해 주장 등 문의 유형별 대응 방법을 절차에 포함한다.

샘플

아래는 외부 문의 대응 절차 개요 샘플이다.

[외부 오픈소스 문의 대응 절차]

1. 접수 및 분류 (1영업일 이내)
   - oss@company.com 수신함을 매일 확인한다.
   - 문의를 유형별로 분류한다:
     A. 오픈소스 고지문 또는 소스코드 제공 요청
     B. 라이선스 의무 준수 여부 확인 요청
     C. 저작권 침해 주장 또는 법적 경고

2. 담당자 배정 및 초기 응답 (3영업일 이내)
   - 오픈소스 프로그램 매니저가 문의를 검토하고 수신 확인 답변을 발송한다.
   - C유형(법적 경고)은 즉시 법무 담당에게 에스컬레이션한다.

3. 검토 및 답변 작성 (14영업일 이내)
   - 관련 SBOM, 라이선스 기록, 컴플라이언스 산출물을 검토한다.
   - A유형: 고지문 또는 소스코드를 확인하여 제공한다.
   - B유형: 컴플라이언스 이행 증거를 검토하여 답변한다.
   - 필요 시 법무 담당에게 답변 초안 검토를 의뢰한다.

4. 답변 발송 및 종결
   - 최종 답변을 발송하고 문의를 종결 처리한다.

5. 기록 보관
   - 문의 내용, 검토 과정, 최종 답변을 문서화하여 최소 3년간 보관한다.

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 템플릿: 오픈소스 정책 템플릿 — §9 외부 문의 대응

2.2 - §3.2.2 효과적 리소스

1. 조항 개요

오픈소스 프로그램이 실제로 작동하려면 역할을 정의하는 것만으로는 부족하다. 각 역할을 담당할 실제 인원이 배정되고, 업무 수행에 필요한 시간과 예산이 충분히 지원되어야 한다. §3.2.2는 프로그램 역할별 담당자를 문서로 명시하고, 인원 배치와 예산이 적절히 이루어졌음을 확인하며, 법률 자문 접근 방법과 내부 책임 할당 절차, 미준수 사례 처리 절차를 갖출 것을 요구한다. 이 조항은 5개의 입증자료 항목으로 구성되어 §3.1 프로그램 기반에서 정의한 역할 구조를 실제 운영 체계로 구현하는 단계다.

2. 해야 할 활동

• 프로그램 내 각 역할(오픈소스 프로그램 매니저, 법무 담당, IT 담당 등)을 맡은 담당자의 이름 또는 직무를 문서에 기재한다.
• 각 역할 담당자가 업무를 수행할 수 있도록 충분한 시간과 예산이 배정되었음을 확인하고 기록한다.
• 오픈소스 라이선스 컴플라이언스 관련 법적 문제 발생 시 이용할 수 있는 내부 또는 외부 법률 자문 수단을 식별하고 문서화한다.
• 오픈소스 컴플라이언스 내부 책임을 각 역할에 할당하는 절차를 문서화한다.
• 컴플라이언스 미준수 사례를 발견했을 때 검토하고 시정하는 절차를 문서화한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.2.2.1 역할 담당자 명시 문서

준수 방법

프로그램의 각 역할을 실제로 담당하는 인원의 이름, 그룹명, 또는 직무명을 기재한 문서를 작성해야 한다. 이 문서는 §3.1.2.1의 역할·책임 목록 문서에 담당자 정보를 추가하는 형태로 관리하거나, 오픈소스 정책 Appendix에 담당자 현황표로 포함할 수 있다. 특정 개인 이름 대신 직무명(오픈소스 프로그램 매니저, 법무팀장 등)을 사용해도 무방하며, 조직 변경 시 즉시 갱신해야 한다.

고려사항

• 개인명 또는 직무명: 이름 대신 직무명을 사용하면 인사 변동 시에도 문서를 자주 갱신할 필요가 줄어든다.
• 겸임 명시: 한 사람이 여러 역할을 담당하는 경우 모든 역할에 해당 사실을 기재한다.
• 갱신 관리: 조직 변경·인사 이동 발생 시 즉시 문서를 업데이트하고 버전을 기록한다.

샘플

아래는 역할 담당자 현황표 샘플이다. 오픈소스 정책 템플릿 Appendix 1에서 전체 양식을 확인할 수 있다.

| 역할 | 담당자 | 연락처 |
|------|--------|--------|
| 오픈소스 프로그램 매니저 | 홍길동 (개발팀장) | oss@company.com |
| 법무 담당 | 김법무 (법무팀장) | legal@company.com |
| IT 담당 | 이인프라 (인프라팀) | it-oss@company.com |
| 보안 담당 | 박보안 (보안팀) | security@company.com |
| 개발 문화 담당 | 최문화 (HR팀) | culture@company.com |

3.2.2.2 인원 배치 및 예산 지원 확인

준수 방법

각 역할 담당자가 오픈소스 프로그램 업무를 수행할 수 있도록 충분한 시간과 예산이 배정되었음을 확인하고 그 근거를 기록해야 한다. 별도의 전담 조직이 없는 경우에도 겸임 담당자가 해당 업무에 투입할 수 있는 시간이 확보되었는지, 도구 구매나 교육비 등 필요 예산이 편성되었는지를 확인하는 내부 기록이 있어야 한다. 경영진 승인이 포함된 예산 계획서나 업무 분장 문서가 이 입증자료에 해당할 수 있다.

고려사항

• 전담 여부 명시: 전담 인원인지 겸임인지를 기록하고, 겸임의 경우 투입 비율(예: 업무 시간의 20%)을 명시한다.
• 예산 근거 보관: 도구 구매 계약서, 교육비 집행 내역, 외부 컨설팅 계약 등 예산 지원을 증명하는 기록을 보관한다.
• 경영진 확인: 인원 배치와 예산 지원에 대한 경영진 승인 또는 확인 기록을 유지한다.

샘플

[오픈소스 프로그램 리소스 배정 확인서]

프로그램 연도: 2026년
승인자: [임원명] / 승인일: 2026-01-10

| 역할 | 담당자 | 투입 비율 | 연간 예산 |
|------|--------|-----------|-----------|
| 오픈소스 프로그램 매니저 | 홍길동 | 50% | - |
| 법무 담당 | 김법무 | 20% | - |
| IT 담당 (도구 운영) | 이인프라 | 10% | 도구 라이선스 비용 포함 |
| 교육 예산 | - | - | 연간 OOO만 원 |
| 외부 법률 자문 예산 | - | - | 필요 시 집행 |

3.2.2.3 법률 자문 접근 방법

준수 방법

오픈소스 라이선스 컴플라이언스와 관련된 법적 문제가 발생했을 때 전문 법률 자문을 받을 수 있는 방법을 식별하고 문서화해야 한다. 내부 법무팀이 있는 경우 해당 팀의 연락처와 에스컬레이션 절차를 기록하고, 내부 법무팀이 없거나 전문성이 부족한 경우 외부 법무법인 또는 오픈소스 컨설팅 전문가를 활용하는 방법을 문서에 명시한다.

고려사항

• 내부 vs. 외부: 내부 법무팀 활용 방법과 외부 자문 의뢰 기준을 모두 명시한다.
• 에스컬레이션 기준: 어떤 상황에서 법률 자문을 받아야 하는지(저작권 침해 주장, 비표준 라이선스, 특허 조항 등) 기준을 절차에 포함한다.
• 외부 자문 목록 관리: 오픈소스 전문 외부 법무법인 또는 컨설턴트 정보를 최신 상태로 유지한다.

샘플

[법률 자문 접근 방법]

내부 법무팀:
- 담당: 법무팀 (legal@company.com)
- 에스컬레이션 기준: 저작권 침해 주장 접수, GPL 계열 라이선스 의무
  해석 불확실, 비표준 라이선스 검토 필요 시

외부 법률 자문:
- 활용 기준: 내부 법무팀에서 판단이 어려운 복잡한 법적 분쟁 발생 시
- 계약 현황: [외부 법무법인명] (연간 자문 계약 체결)
- 오픈소스 전문 컨설팅: OpenChain 파트너사 목록 참조

3.2.2.4 내부 책임 할당 절차

준수 방법

오픈소스 컴플라이언스와 관련된 내부 책임을 각 역할에 명확히 할당하는 절차를 문서화해야 한다. 이 절차는 누가 무엇을 책임지는지를 정의하며, 오픈소스 사용 승인, SBOM 생성, 라이선스 검토, 컴플라이언스 산출물 배포 등 각 업무 단계별 책임자를 명시한다. 이 절차 문서는 오픈소스 정책 또는 프로세스 문서에 포함할 수 있다.

고려사항

• 업무 단계별 책임 명시: 오픈소스 도입, 검토, 승인, 배포 각 단계마다 책임자를 지정한다.
• RACI 활용: 역할별 책임(Responsible, Accountable, Consulted, Informed)을 RACI 매트릭스로 정의하면 명확성이 높아진다.
• 갱신 주기: 조직 변경 또는 프로세스 변경 시 절차를 즉시 갱신한다.

샘플

| 업무 | 오픈소스 PM | 법무 담당 | IT 담당 | 보안 담당 | 개발자 |
|------|------------|-----------|---------|-----------|--------|
| 오픈소스 사용 승인 | A | C | - | C | R |
| 라이선스 의무 검토 | R | A | - | - | I |
| SBOM 생성 | A | - | R | - | C |
| 취약점 모니터링 | I | - | C | A/R | I |
| 컴플라이언스 산출물 배포 | A | C | R | - | I |
| 외부 문의 대응 | A/R | C | - | - | - |

R: 실행 책임 / A: 최종 책임 / C: 협의 / I: 정보 공유

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

준수 방법

오픈소스 컴플라이언스 미준수 사례(라이선스 의무 불이행, SBOM 누락, 무승인 오픈소스 사용 등)가 발견되었을 때 이를 검토하고 시정하는 절차를 문서화해야 한다. 절차에는 ①미준수 사례 식별 및 보고, ②심각도 평가, ③원인 분석, ④시정 조치, ⑤재발 방지 대책, ⑥기록 보관이 포함되어야 한다.

미준수 사례는 내부 감사, 외부 문의, 자동화 도구 알림 등 다양한 경로로 발견될 수 있다. 심각도에 따라 긴급 조치(배포 중단, 소스코드 즉시 공개 등)와 일반 조치를 구분하여 처리 기한을 다르게 설정하는 것이 효과적이다.

고려사항

• 심각도 분류: 미준수 사례의 법적 리스크에 따라 심각도(높음/중간/낮음)를 분류하고 처리 기한을 다르게 설정한다.
• 에스컬레이션: 심각도가 높은 사례는 경영진 보고 및 법무 검토를 의무화한다.
• 재발 방지: 시정 조치 완료 후 동일 유형의 미준수가 재발하지 않도록 프로세스 개선 방안을 도출하고 기록한다.
• 기록 보관: 미준수 사례 이력과 시정 완료 기록을 최소 3년간 보관한다.

샘플

[미준수 사례 처리 절차]

1. 식별 및 보고
   - 내부 감사, 외부 문의, CI/CD 도구 알림 등을 통해 미준수 사례를 식별한다.
   - 오픈소스 프로그램 매니저에게 즉시 보고한다.

2. 심각도 평가
   - 높음: 배포된 소프트웨어의 GPL 소스코드 미공개, 저작권 침해 주장 접수
     → 48시간 이내 긴급 검토 착수
   - 중간: SBOM 누락, 라이선스 고지문 불완전
     → 7영업일 이내 시정 조치 완료
   - 낮음: 내부 프로세스 미준수 (승인 절차 생략 등)
     → 30일 이내 시정 조치 완료

3. 원인 분석 및 시정 조치
   - 미준수 원인을 파악하고 시정 방안을 수립한다.
   - 높음·중간 사례는 법무 담당과 협의 후 조치한다.

4. 재발 방지
   - 프로세스 또는 교육 개선 방안을 도출하고 이행한다.

5. 기록 보관
   - 사례 내용, 조치 경과, 완료 일자를 기록하고 최소 3년간 보관한다.

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 1. 조직
• 관련 템플릿: 오픈소스 정책 템플릿 — Appendix 1. 담당자 현황

3 - §3.3 콘텐츠 검토 및 승인

3.1 - §3.3.1 SBOM

1. 조항 개요

공급 소프트웨어에 어떤 오픈소스 컴포넌트가 포함되어 있는지 파악하지 못하면 라이선스 의무를 이행할 수 없고 보안 취약점 대응도 불가능하다. §3.3.1은 공급 소프트웨어를 구성하는 오픈소스 컴포넌트를 식별·추적·검토·승인·보관하는 절차를 수립하고, 그 절차가 실제로 이행되었음을 입증하는 컴포넌트 기록(SBOM)을 유지하도록 요구한다. 이 조항은 오픈소스 라이선스 컴플라이언스와 보안 보증의 핵심 인프라인 SBOM을 운영하는 기반이 된다.

2. 해야 할 활동

• 공급 소프트웨어에 포함된 오픈소스 컴포넌트를 자동화 도구(FOSSology, ORT, Syft, cdxgen 등)를 활용하여 식별하고 목록화한다.
• 오픈소스 컴포넌트 정보(컴포넌트명, 버전, 라이선스, 출처 등)를 추적하고 검토·승인·보관하는 절차를 문서화한다.
• 각 공급 소프트웨어 릴리스에 대한 SBOM을 생성하고 관리한다.
• SBOM 데이터를 SPDX 또는 CycloneDX 표준 형식으로 작성하여 상호 운용성을 확보한다.
• 소프트웨어 변경(신규 컴포넌트 추가, 버전 업그레이드, 컴포넌트 제거) 시 SBOM을 즉시 갱신한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.3.1.1 오픈소스 컴포넌트 관리 절차

준수 방법

공급 소프트웨어에 포함된 오픈소스 컴포넌트를 식별·추적·검토·승인·보관하는 일련의 절차를 문서화해야 한다. 절차는 소프트웨어 개발 주기 전반에 걸쳐 오픈소스가 어떻게 관리되는지를 다루며, ①컴포넌트 식별, ②라이선스 확인, ③의무 검토, ④사용 승인, ⑤SBOM 생성 및 등록, ⑥배포 시 SBOM 제공, ⑦변경 시 SBOM 갱신, ⑧SBOM 보관의 단계를 포함해야 한다. 이 절차 문서 자체가 입증자료 3.3.1.1이다.

SBOM은 SPDX(ISO/IEC 5962) 또는 CycloneDX 형식을 채택하여 표준화하는 것을 권장한다. 자동화 도구를 CI/CD 파이프라인에 통합하면 컴포넌트 변경 시 SBOM이 자동으로 갱신되어 최신성을 유지하기 쉽다.

고려사항

• 자동화 도구 통합: FOSSology, ORT, Syft, cdxgen 등을 CI/CD에 통합하여 SBOM 생성을 자동화한다.
• 표준 형식 채택: SPDX 또는 CycloneDX 형식으로 SBOM을 작성하여 공급망 파트너와의 상호 운용성을 확보한다.
• 갱신 트리거 정의: 신규 컴포넌트 추가, 버전 업그레이드, 컴포넌트 제거, 라이선스 변경 발생 시 SBOM 갱신을 의무화한다.
• 승인 절차 명시: 새로운 오픈소스 컴포넌트 도입 시 오픈소스 프로그램 매니저 또는 OSRB의 승인 절차를 절차에 포함한다.
• 보관 기간: SBOM은 해당 소프트웨어 배포 후 최소 [N]년간 보관한다.

샘플

아래는 오픈소스 컴포넌트 관리 절차 개요 샘플이다. 오픈소스 프로세스 템플릿에서 전체 프로세스 양식을 확인할 수 있다.

[오픈소스 컴포넌트 관리 절차 개요]

(1) 식별
    - 개발자는 오픈소스 컴포넌트 도입 시 오픈소스 관리 시스템에 신고한다.
    - CI/CD 파이프라인의 SCA 도구(Syft, ORT 등)가 컴포넌트를 자동 탐지한다.

(2) 라이선스 확인 및 의무 검토
    - 식별된 컴포넌트의 라이선스를 SPDX License List 기준으로 확인한다.
    - 라이선스 의무 요약표를 참조하여 배포 형태에 따른 의무를 검토한다.
    - 불확실한 경우 법무 담당에게 검토를 의뢰한다.

(3) 사용 승인
    - 오픈소스 프로그램 매니저가 검토 결과를 바탕으로 사용을 승인한다.
    - 라이선스 정책에 반하는 컴포넌트는 대안 검토 후 반려한다.

(4) SBOM 생성 및 등록
    - 승인된 컴포넌트를 SBOM에 등록한다 (형식: SPDX 또는 CycloneDX).
    - SBOM에는 컴포넌트명, 버전, 라이선스, 출처(URL), 저작권 고지를 포함한다.

(5) 배포 및 SBOM 제공
    - 소프트웨어 배포 시 SBOM을 함께 제공하거나 요청 시 제공한다.

(6) 변경 시 갱신
    - 컴포넌트 추가·업그레이드·제거·라이선스 변경 발생 시 SBOM을 즉시 갱신한다.

(7) 보관
    - SBOM은 소프트웨어 배포 후 최소 [N]년간 버전별로 보관한다.

3.3.1.2 오픈소스 컴포넌트 기록 (SBOM)

준수 방법

3.3.1.1에서 정의한 절차가 실제로 이행되었음을 보여주는 컴포넌트 기록을 공급 소프트웨어별로 유지해야 한다. 이 기록이 SBOM(Software Bill of Materials)이며 입증자료 3.3.1.2에 해당한다. SBOM에는 최소한 각 오픈소스 컴포넌트의 이름·버전· 라이선스·출처가 포함되어야 하며, SPDX 또는 CycloneDX 형식으로 작성하면 감사 시 즉시 제출 가능한 형태가 된다.

SBOM은 소프트웨어 릴리스 버전별로 관리하고, 과거 버전의 SBOM도 보관하여 특정 시점의 컴포넌트 구성을 언제든 확인할 수 있어야 한다. SBOM 생성 도구의 출력 결과를 그대로 활용하거나, 오픈소스 관리 시스템(SW360, Dependency-Track 등)에 저장·관리하는 방식을 사용할 수 있다.

고려사항

• 필수 포함 항목: 컴포넌트명, 버전, 라이선스 식별자(SPDX ID), 출처(패키지 레지스트리 URL 또는 소스 저장소), 저작권 고지를 포함한다.
• 버전별 관리: 소프트웨어 릴리스 버전별로 SBOM을 별도 관리하고 과거 버전도 보관한다.
• 관리 도구 활용: SW360, Dependency-Track 등 오픈소스 관리 시스템을 활용하면 SBOM의 생성·추적·배포를 체계적으로 관리할 수 있다.
• 고객 제공: 고객 또는 공급망 파트너가 SBOM을 요청하는 경우 즉시 제공할 수 있도록 접근 가능한 형태로 보관한다.

샘플

아래는 SPDX 형식 SBOM의 핵심 항목 샘플이다.

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: MyProduct-v1.2.0-sbom
DocumentNamespace: https://company.com/sbom/myproduct-1.2.0

PackageName: openssl
SPDXID: SPDXRef-openssl
PackageVersion: 3.0.8
PackageDownloadLocation: https://www.openssl.org/source/openssl-3.0.8.tar.gz
PackageLicenseConcluded: Apache-2.0
PackageLicenseDeclared: Apache-2.0
PackageCopyrightText: Copyright (c) 1998-2023 The OpenSSL Project

PackageName: zlib
SPDXID: SPDXRef-zlib
PackageVersion: 1.2.13
PackageDownloadLocation: https://zlib.net/zlib-1.2.13.tar.gz
PackageLicenseConcluded: Zlib
PackageLicenseDeclared: Zlib
PackageCopyrightText: Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 템플릿: 오픈소스 프로세스 템플릿
• 관련 도구: FOSSology, ORT, Syft, cdxgen, Dependency-Track

3.2 - §3.3.2 라이선스 컴플라이언스

1. 조항 개요

오픈소스 컴포넌트는 배포 형태(바이너리·소스코드), 수정 여부, 다른 컴포넌트와의 결합 방식에 따라 라이선스 의무가 달라진다. §3.3.2는 공급 소프트웨어에 포함된 오픈소스 컴포넌트에 대해 자주 발생하는 라이선스 사용 사례들을 처리할 수 있는 능력을 프로그램이 갖추도록 요구한다. 이 조항은 단순히 라이선스를 식별하는 것을 넘어, 다양한 배포 시나리오별로 의무 이행 방법을 정의한 절차를 마련하도록 한다.

2. 해야 할 활동

• 바이너리 형태 배포, 소스코드 형태 배포, 수정된 오픈소스 배포 등 주요 라이선스 사용 사례를 식별하고 각 사례별 처리 절차를 수립한다.
• 라이선스 충돌(비호환 라이선스 컴포넌트 결합)이 발생했을 때의 처리 방법을 절차에 포함한다.
• 고지 의무(저작권 고지문, 라이선스 전문 포함)가 필요한 라이선스에 대한 처리 방법을 정의한다.
• GPL 등 소스코드 공개 의무가 있는 라이선스가 포함된 소프트웨어의 배포 절차를 수립한다.
• 절차를 문서화하고 정기적으로 검토하여 새로운 라이선스 유형에 대응한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.3.2.1 라이선스 사용 사례별 처리 절차

준수 방법

공급 소프트웨어에 오픈소스가 포함되는 다양한 시나리오별로 라이선스 의무를 어떻게 이행하는지 정의한 절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.3.2.1이다. ISO/IEC 5230은 아래 6가지 주요 사용 사례를 예시로 제시하며, 조직의 비즈니스 환경에 따라 해당되는 사례를 선택하여 처리 절차를 수립한다.

각 사용 사례별 절차에는 ①해당 사례 해당 여부 판단 기준, ②라이선스 의무 항목, ③의무 이행 방법, ④담당자, ⑤산출물(고지문, 소스코드 패키지 등)이 포함되어야 한다. 라이선스 충돌이 발생하는 경우 법무 담당에게 에스컬레이션하는 경로도 명시한다.

고려사항

• 사용 사례 범위 확정: 조직의 소프트웨어 배포 방식에 맞는 사용 사례를 선택하여 절차를 수립한다 (모든 사례가 모든 조직에 해당되지 않을 수 있다).
• 라이선스 충돌 대응: GPL과 Apache-2.0 등 비호환 라이선스 조합 발생 시 처리 방법을 미리 정의해 둔다.
• 고지문 관리: 저작권 고지 의무가 있는 라이선스에 대해 NOTICES 파일 또는 제품 설명서 내 고지문 작성 절차를 수립한다.
• 소스코드 공개 절차: GPL 계열 라이선스의 소스코드 공개 요청 대응 절차를 별도로 정의한다.
• 갱신 주기: 신규 라이선스 유형 도입 또는 배포 형태 변경 시 절차를 갱신한다.

샘플

아래는 라이선스 사용 사례별 처리 절차 요약표 샘플이다.

| 사용 사례 | 라이선스 예시 | 주요 의무 | 처리 방법 |
|-----------|--------------|-----------|-----------|
| 바이너리 형태 배포 | MIT, Apache-2.0 | 저작권 고지문 포함 | NOTICES 파일 또는 앱 내 고지 화면에 고지문 포함 |
| 바이너리 형태 배포 | GPL-2.0, GPL-3.0 | 소스코드 공개 또는 제공 약정서 포함 | 소스코드 패키지 배포 또는 written offer 동봉 |
| 소스코드 형태 배포 | 모든 라이선스 | 원본 라이선스 파일 및 저작권 고지 보존 | 라이선스 파일과 저작권 고지를 그대로 유지 |
| 수정된 오픈소스 포함 | GPL-2.0, LGPL-2.1 | 수정 사항 명시, 수정본 동일 라이선스 적용 | 수정 내역 기록, 수정본 소스코드 공개 |
| 비호환 라이선스 결합 | GPL-2.0 + Apache-2.0 | 라이선스 충돌 해소 | 법무 검토 후 컴포넌트 대체 또는 구조 변경 |
| 저작권 고지 요건 | BSD-3-Clause, Apache-2.0 | 제품 문서 또는 UI에 저작권 고지 포함 | 제품 설명서 또는 About 화면에 고지문 추가 |

아래는 배포 형태별 라이선스 의무 처리 절차 개요 샘플이다.

[바이너리 배포 시 라이선스 의무 처리 절차]

1. SBOM 확인
   - 배포 소프트웨어의 최신 SBOM을 기준으로 포함된 오픈소스 목록을 확인한다.

2. 라이선스 의무 분류
   - 고지문 의무: MIT, Apache-2.0, BSD 등 → NOTICES 파일 작성
   - 소스코드 공개 의무: GPL-2.0, GPL-3.0 → 소스코드 패키지 준비
   - LGPL: 동적 링크 여부에 따라 의무 범위 판단 (필요 시 법무 검토)

3. 컴플라이언스 산출물 준비
   - NOTICES 파일: 모든 오픈소스의 저작권 고지문 및 라이선스 전문 포함
   - 소스코드 패키지: GPL 컴포넌트의 수정된 소스코드 및 빌드 스크립트 포함

4. 검토 및 승인
   - 오픈소스 프로그램 매니저가 산출물의 완전성을 최종 검토한다.
   - 라이선스 충돌 또는 불확실한 사항은 법무 담당에게 에스컬레이션한다.

5. 배포
   - 컴플라이언스 산출물을 소프트웨어와 함께 제공한다.
   - 산출물 사본을 보관한다 (§3.4.1 참조).

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 템플릿: 오픈소스 프로세스 템플릿

4 - §3.4 컴플라이언스 산출물

4.1 - §3.4.1 산출물

1. 조항 개요

라이선스 의무를 이행하려면 실제로 고지문, 소스코드 패키지 등 컴플라이언스 산출물을 준비하여 소프트웨어와 함께 제공해야 한다. §3.4.1은 식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고 공급 소프트웨어와 함께 배포하는 절차, 그리고 산출물 사본을 일정 기간 보관하는 절차를 수립하도록 요구한다. 이 조항은 §3.3 검토·승인 단계의 결과물을 실제 배포와 보관으로 연결하는 단계다.

2. 해야 할 활동

• 라이선스별로 요구되는 컴플라이언스 산출물(NOTICES 파일, 소스코드 패키지, written offer 등)의 유형을 정의한다.
• 산출물을 준비하여 공급 소프트웨어와 함께 제공하는 절차를 문서화한다.
• 배포된 산출물의 사본을 일정 기간 보관하는 절차를 수립하고 문서화한다.
• 산출물 보관 기간을 정책에 명시한다 (업계 관행: 마지막 배포 후 최소 3년).
• 보관 절차가 올바르게 수행되었음을 입증하는 기록을 유지한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.4.1.1 컴플라이언스 산출물 준비 및 배포 절차

준수 방법

라이선스 의무에 따른 컴플라이언스 산출물을 준비하고 공급 소프트웨어와 함께 제공하는 절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.4.1.1이다. 절차에는 ①산출물 유형 결정, ②산출물 작성, ③검토 및 승인, ④소프트웨어와 함께 제공, ⑤기록 보관의 단계가 포함되어야 한다.

컴플라이언스 산출물의 유형은 배포하는 라이선스에 따라 달라진다. 일반적으로 고지 의무 라이선스(MIT, Apache-2.0 등)는 NOTICES 파일이 필요하고, GPL 계열 라이선스는 소스코드 패키지 또는 written offer가 필요하다. 산출물 형태는 제품에 동봉, 패키지에 포함, 웹사이트 게시, 요청 시 제공 등 다양한 방식으로 제공할 수 있다.

고려사항

• 산출물 유형 정의: 라이선스별로 어떤 산출물이 필요한지 미리 정의하여 배포 준비 시 빠르게 대응할 수 있도록 한다.
• NOTICES 파일 품질: 모든 오픈소스 컴포넌트의 저작권 고지문과 라이선스 전문이 누락 없이 포함되었는지 검토한다.
• 소스코드 패키지: GPL 컴포넌트의 경우 수정된 소스코드와 빌드 스크립트를 포함한 완전한 소스코드 패키지를 준비한다.
• 제공 방식: 산출물을 소프트웨어에 동봉할지, 웹사이트에 게시할지, 요청 시 제공할지를 라이선스 요건에 맞게 결정한다.
• 최종 검토: 배포 전 오픈소스 프로그램 매니저가 산출물의 완전성을 최종 확인한다.

샘플

아래는 컴플라이언스 산출물 준비 및 배포 절차 개요 샘플이다.

[컴플라이언스 산출물 준비 및 배포 절차]

1. 산출물 유형 결정
   - SBOM을 기준으로 포함된 라이선스 목록을 확인한다.
   - 라이선스별 의무에 따라 필요한 산출물을 결정한다:
     · 고지 의무 라이선스 → NOTICES 파일
     · GPL-2.0/3.0 → 소스코드 패키지 또는 written offer
     · LGPL → 동적 링크 구조 증명 문서 또는 소스코드

2. 산출물 작성
   - NOTICES 파일: 자동화 도구(FOSSology, ORT 등)로 생성하거나 수동 작성.
     컴포넌트명, 버전, 라이선스 전문, 저작권 고지문 포함.
   - 소스코드 패키지: GPL 컴포넌트의 수정된 소스코드와 빌드 스크립트 포함.

3. 검토 및 승인
   - 오픈소스 프로그램 매니저가 산출물의 완전성과 정확성을 검토한다.
   - 불완전한 항목은 수정 후 재검토한다.

4. 소프트웨어와 함께 제공
   - 제품 패키지에 동봉하거나 설치 시 표시되는 화면에 포함한다.
   - 웹사이트 게시 또는 요청 시 제공하는 경우 해당 URL 또는 절차를 명시한다.
   - written offer를 사용하는 경우 3년간 유효한 서면 약정을 포함한다.

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

준수 방법

배포된 공급 소프트웨어의 컴플라이언스 산출물 사본을 일정 기간 보관하는 절차를 문서화하고, 그 절차가 실제로 이행되었음을 입증하는 기록을 유지해야 한다. 이 절차 문서와 보관 기록이 입증자료 3.4.1.2다.

보관 기간은 해당 소프트웨어의 마지막 배포 시점으로부터 합리적인 기간이어야 하며, 업계 관행상 최소 3년을 권장한다. 보관 대상은 NOTICES 파일, 소스코드 패키지, written offer 사본, SBOM 등 배포 시 제공한 모든 산출물이다. 소프트웨어 버전별로 산출물을 체계적으로 관리하여 특정 버전의 산출물을 즉시 검색·제출할 수 있어야 한다.

고려사항

• 보관 기간 명시: 정책 또는 절차 문서에 보관 기간(최소 3년)을 명시한다.
• 버전별 관리: 소프트웨어 릴리스 버전과 산출물을 연결하여 버전별로 보관한다.
• 보관 위치: 사내 파일 서버, 문서 관리 시스템, 소스코드 저장소 등 접근 가능하고 안전한 위치에 보관한다.
• 보관 기록 유지: 어떤 버전의 산출물을 언제 보관했는지 이력을 기록한다.
• 접근성: 감사 또는 외부 문의 발생 시 즉시 산출물을 제출할 수 있도록 검색 가능한 형태로 보관한다.

샘플

아래는 컴플라이언스 산출물 보관 기록부 샘플이다.

| 소프트웨어명 | 버전 | 배포일 | 산출물 유형 | 보관 위치 | 보관 기한 | 담당자 |
|-------------|------|--------|------------|-----------|-----------|--------|
| MyProduct | v1.0.0 | 2024-03-01 | NOTICES 파일, GPL 소스코드 패키지 | /archive/myproduct/v1.0.0/ | 2027-03-01 | 홍길동 |
| MyProduct | v1.1.0 | 2024-09-15 | NOTICES 파일 | /archive/myproduct/v1.1.0/ | 2027-09-15 | 홍길동 |
| FirmwareX | v2.3.0 | 2025-01-10 | NOTICES 파일, LGPL 소스코드 패키지, SBOM | /archive/firmwarex/v2.3.0/ | 2028-01-10 | 이인프라 |

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 템플릿: 오픈소스 프로세스 템플릿

5 - §3.5 커뮤니티 참여

5.1 - §3.5.1 기여

1. 조항 개요

많은 기업이 외부 오픈소스 프로젝트에 코드·문서·버그 리포트 등을 기여한다. 기여 활동은 커뮤니티 신뢰를 높이고 기술 영향력을 확대하지만, 회사 코드나 특허가 의도치 않게 공개될 수 있는 리스크도 수반한다. §3.5.1은 조직이 외부 오픈소스 기여를 허용하는 경우, 기여를 규율하는 문서화된 정책과 절차를 수립하고 프로그램 참여자가 그 존재를 인식하도록 할 것을 요구한다. 이 조항은 기여를 허용하지 않는 조직에는 적용되지 않으나, 허용하는 경우 세 가지 입증자료를 모두 갖추어야 한다.

2. 해야 할 활동

• 조직의 외부 오픈소스 기여 허용 여부를 결정하고 정책에 명시한다.
• 기여를 허용하는 경우 기여 유형(코드, 문서, 버그 리포트 등), 승인 절차, 저작권·특허 처리 방침 등을 포함한 기여 정책을 문서화한다.
• 기여 제안부터 승인·제출·기록까지 실제 기여를 관리하는 절차를 수립하고 문서화한다.
• 기여 정책의 존재를 프로그램 참여자에게 전파하는 절차를 마련한다.
• 기여 이력을 기록하고 보관한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.5.1.1 오픈소스 기여 정책

준수 방법

외부 오픈소스 프로젝트에 기여하는 행위를 규율하는 정책을 문서화해야 한다. 이 정책 문서가 입증자료 3.5.1.1이다. 기여 정책에는 ①기여 허용 범위(코드, 문서, 버그 리포트 등), ②기여 승인 절차, ③저작권 처리(회사 소유 vs. 개인 소유), ④특허 처리 방침, ⑤CLA(Contributor License Agreement) 서명 기준, ⑥기여 금지 항목(영업 비밀, 미공개 특허 등)이 포함되어야 한다.

정책은 오픈소스 정책 문서의 별도 섹션으로 포함하거나 독립된 기여 정책 문서로 관리할 수 있다. 기여를 완전히 금지하는 조직도 “기여를 허용하지 않는다"는 정책을 명시적으로 문서화하는 것이 바람직하다.

고려사항

• 기여 범위 정의: 허용되는 기여 유형(버그 수정, 기능 추가, 문서 작성 등)을 구체적으로 열거한다.
• 저작권 귀속: 기여물의 저작권이 회사에 귀속되는지, 개인에게 귀속되는지 정책에 명시한다.
• 특허 리스크 관리: 기여물에 회사 특허가 포함될 수 있는 경우 법무 검토를 의무화한다.
• CLA 처리: 외부 프로젝트가 CLA를 요구하는 경우 서명 권한자와 절차를 정책에 명시한다.
• 기여 금지 항목: 영업 비밀, 미등록 특허, 제3자 지식재산이 포함된 코드는 기여를 금지한다.

샘플

아래는 오픈소스 기여 정책 핵심 항목 샘플이다.

## 오픈소스 기여 정책

### 기여 허용 범위
회사는 임직원이 업무 목적으로 외부 오픈소스 프로젝트에 기여하는 것을 허용한다.
허용되는 기여 유형은 다음과 같다:
- 버그 수정 및 패치 제출
- 문서 개선
- 기능 추가 (사전 승인 필요)
- 버그 리포트 및 이슈 제기

### 저작권 및 특허
- 업무 시간에 회사 자원을 사용하여 작성한 기여물의 저작권은 회사에 귀속된다.
- 기여물에 회사 특허가 포함될 가능성이 있는 경우 법무 담당의 사전 검토를 받아야 한다.

### 기여 금지 항목
다음 항목이 포함된 코드는 기여할 수 없다:
- 영업 비밀 또는 기밀 정보
- 제3자의 지식재산
- 회사의 미공개 특허 기술

### CLA (Contributor License Agreement)
외부 프로젝트가 CLA 서명을 요구하는 경우 오픈소스 프로그램 매니저에게
사전 보고하고 승인을 받아야 한다.

3.5.1.2 오픈소스 기여 관리 절차

준수 방법

실제 기여 활동을 어떻게 처리하는지 단계별로 정의한 절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.5.1.2다. 절차에는 ①기여 제안 및 승인 요청, ②법무·특허 검토(필요 시), ③승인, ④기여 제출, ⑤기여 이력 기록의 단계가 포함되어야 한다. 기여 규모나 유형에 따라 간소화된 절차(소규모 버그 수정)와 정식 절차(대규모 기능 추가)를 구분하여 운영할 수 있다.

고려사항

• 기여 규모별 절차 구분: 소규모 버그 수정은 간소 승인, 대규모 기능 추가는 정식 법무 검토를 거치도록 규모별 기준을 설정한다.
• 기여 기록 보관: 기여 제안서, 승인 기록, 제출 링크(PR/커밋 URL)를 기록하고 보관한다.
• 에스컬레이션: 특허 또는 저작권 이슈가 발생하는 경우 법무 담당에게 에스컬레이션하는 경로를 절차에 포함한다.

샘플

아래는 오픈소스 기여 관리 절차 개요 샘플이다.

[오픈소스 기여 관리 절차]

1. 기여 제안
   - 임직원이 기여하고자 하는 내용(프로젝트명, 기여 유형, 내용 요약)을
     오픈소스 프로그램 매니저에게 보고한다.

2. 검토 및 승인
   - 소규모 기여 (버그 수정, 문서 개선):
     오픈소스 프로그램 매니저가 정책 적합성을 확인 후 승인한다.
   - 대규모 기여 (기능 추가, 핵심 모듈 기여):
     법무 담당의 특허·저작권 검토 후 오픈소스 프로그램 매니저가 최종 승인한다.

3. CLA 처리 (해당 시)
   - 외부 프로젝트가 CLA를 요구하는 경우 승인된 CLA 서명 양식에 따라 처리한다.

4. 기여 제출
   - 승인된 내용에 한정하여 기여를 제출한다.
   - 회사 이메일 또는 회사가 승인한 계정으로 기여한다.

5. 기여 기록
   - 기여 내용, 승인자, 제출일, 기여 URL(PR/커밋 링크)을 기록하고 보관한다.

3.5.1.3 기여 정책 인식 절차

준수 방법

모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식할 수 있도록 전파하는 절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.5.1.3이다. §3.1.1.2의 오픈소스 정책 전파 절차에 기여 정책을 포함하는 방식으로 통합 관리할 수 있다.

전파 방법은 신규 입사자 온보딩 시 기여 정책 안내, 사내 위키 게시, 이메일 공지 등을 조합하는 것이 효과적이다. 전파 사실을 증명하기 위해 공지 이력, 교육 이수 기록 등을 보관한다.

고려사항

• 온보딩 포함: 신규 입사자 온보딩 과정에 기여 정책 안내를 필수 항목으로 포함한다.
• 정책 갱신 시 재전파: 기여 정책이 변경된 경우 프로그램 참여자에게 즉시 공지한다.
• 증거 보관: 공지 발송 이력, 교육 이수 확인서 등을 최소 3년간 보관한다.
• 정책 접근성: 기여 정책을 사내 포털 또는 위키에 항시 게시하여 언제든 확인할 수 있도록 한다.

샘플

아래는 기여 정책 전파 공지 이메일 샘플이다.

제목: [오픈소스] 오픈소스 기여 정책 안내

수신: 전체 개발 관련 임직원
발신: 오픈소스 프로그램 매니저

안녕하세요.

당사 오픈소스 기여 정책을 안내드립니다.
외부 오픈소스 프로젝트에 기여하는 업무에 관여하는 모든 임직원은
아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다.

- 정책 문서: [사내 포털 링크]
- 주요 내용: 기여 허용 범위, 승인 절차, 저작권·특허 처리 방침
- 정책 버전: v1.0 (시행일: YYYY-MM-DD)

기여를 희망하는 경우 반드시 사전 승인 절차를 거쳐 주십시오.
문의: 오픈소스 프로그램 매니저 (oss@company.com)

감사합니다.
오픈소스 프로그램 매니저

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 6. 기여
• 관련 템플릿: 오픈소스 정책 템플릿 — §3 오픈소스 기여

6 - §3.6 규격 준수

6.1 - §3.6.1 적합성

1. 조항 개요

ISO/IEC 5230 인증을 받으려면 §3.1.4에서 정의한 프로그램이 이 규격의 모든 요구사항을 충족한다는 사실을 문서로 확인해야 한다. §3.6.1은 앞서 §3.1부터 §3.5까지의 모든 조항을 충족하였음을 공식적으로 선언하는 단계다. 이 조항은 규격 준수를 완결 짓는 최종 확인 절차로, 프로그램이 ISO/IEC 5230:2020 버전 2.1의 모든 요구사항을 만족한다는 조직의 공식 확인이 필요하다.

2. 해야 할 활동

• §3.1부터 §3.5까지 모든 조항의 입증자료(24개 항목)가 갖추어졌는지 자체 점검한다.
• 프로그램이 §3.1.4에서 정의한 적용 범위 내에서 ISO/IEC 5230의 모든 요구사항을 충족함을 확인하는 문서를 작성한다.
• 확인 문서에 검토자, 승인자, 확인 날짜를 기록한다.
• 자가 인증, 독립 평가, 또는 제3자 인증 중 적합한 인증 방법을 선택하여 진행한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.6.1.1 규격 준수 확인 문서

준수 방법

§3.1.4에서 정의한 프로그램의 적용 범위 내에서 ISO/IEC 5230:2020의 모든 요구사항을 충족한다는 사실을 확인하는 문서를 작성해야 한다. 이 문서가 입증자료 3.6.1.1이다. 이 문서는 24개 입증자료 항목 각각에 대해 준수 여부를 확인하는 체크리스트 형태, 또는 전반적인 준수 선언문 형태로 작성할 수 있다.

작성 전 이 가이드의 전체 조항 체크리스트를 활용하여 모든 입증자료가 갖추어졌는지 점검한다. 문서에는 확인 대상 프로그램의 적용 범위, 확인 기준 규격 버전(ISO/IEC 5230:2020 버전 2.1), 확인 날짜, 검토자 및 승인자가 반드시 포함되어야 한다.

고려사항

• 자체 점검 선행: 문서 작성 전 24개 입증자료 항목 전체를 자체 점검하여 누락 항목이 없는지 확인한다.
• 규격 버전 명시: 준수를 확인한 규격 버전(ISO/IEC 5230:2020 버전 2.1)을 문서에 명시한다.
• 승인 절차: 오픈소스 프로그램 매니저의 검토와 경영진 또는 OSRB의 승인을 거쳐 문서를 공식화한다.
• 갱신 주기: 규격 새 버전 발행 후 18개월 이내에 최신 버전 기준으로 재확인해야 한다 (§3.6.2 참조).

샘플

아래는 ISO/IEC 5230 규격 준수 확인 문서 샘플이다.

[ISO/IEC 5230 규격 준수 확인서]

프로그램 명칭: [회사명] 오픈소스 컴플라이언스 프로그램
적용 범위: [§3.1.4에서 정의한 범위 기재]
준수 확인 규격: ISO/IEC 5230:2020 (버전 2.1)
확인 날짜: YYYY-MM-DD

본 문서는 위 프로그램이 ISO/IEC 5230:2020의 §3.1부터 §3.6까지
모든 요구사항을 충족함을 확인한다.

준수 확인 항목 요약:
- §3.1 프로그램 기반 (5개 조항, 8개 입증자료): 충족 ✓
- §3.2 관련 업무 (2개 조항, 7개 입증자료): 충족 ✓
- §3.3 콘텐츠 검토 및 승인 (2개 조항, 3개 입증자료): 충족 ✓
- §3.4 컴플라이언스 산출물 (1개 조항, 2개 입증자료): 충족 ✓
- §3.5 커뮤니티 참여 (1개 조항, 3개 입증자료): 충족 ✓
- §3.6 규격 준수 (2개 조항, 2개 입증자료): 충족 ✓

검토자: [오픈소스 프로그램 매니저 이름]
승인자: [경영진 또는 OSRB 책임자 이름]
승인일: YYYY-MM-DD

5. 참고

• ISO/IEC 5230 자가 인증: https://certification.openchainproject.org/
• 전체 조항 체크리스트: ISO/IEC 5230 준수 가이드

6.2 - §3.6.2 지속 기간

1. 조항 개요

ISO/IEC 5230 인증은 한 번 취득으로 영구히 유효하지 않다. 규격의 새 버전이 발행되면 이전 버전 기준으로 인증을 받은 프로그램은 새 버전 발행 후 18개월까지만 적합성이 유지된다. §3.6.2는 프로그램이 적합성 인증을 취득한 날로부터 최근 18개월 이내에 규격의 모든 요구사항을 충족하고 있음을 확인하는 문서를 유지하도록 요구한다. 이 조항은 오픈소스 컴플라이언스 프로그램이 형식적 인증에 그치지 않고 지속적으로 운영되는지 확인하는 장치다.

2. 해야 할 활동

• 적합성 인증 취득 날짜를 기록하고 관리한다.
• 인증 취득 후 최근 18개월 이내에 규격의 모든 요구사항을 충족하고 있음을 재확인하고 문서화한다.
• 새로운 버전의 규격이 발행된 경우 18개월 이내에 최신 버전 기준으로 프로그램을 갱신하고 재확인한다.
• 정기적인 내부 감사를 통해 프로그램의 지속적 준수 여부를 점검한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.6.2.1 18개월 이내 요구사항 충족 확인 문서

준수 방법

적합성 인증 취득 후 18개월 이내에 프로그램이 규격의 모든 요구사항을 여전히 충족하고 있음을 확인하는 문서를 유지해야 한다. 이 문서가 입증자료 3.6.2.1이다. 가장 간단한 방법은 §3.6.1.1의 규격 준수 확인 문서를 정기적으로(최소 연 1회) 재검토하고 갱신하는 것이다. 갱신 시마다 검토 날짜와 검토자를 기록하여 최근 18개월 이내에 검토가 이루어졌음을 증명할 수 있도록 한다.

새로운 버전의 ISO/IEC 5230이 발행된 경우 18개월의 유예 기간 내에 최신 버전 기준으로 프로그램을 갱신하고 재확인 문서를 작성한다. 유예 기간을 초과하면 인증 효력이 만료되므로, 규격 개정 동향을 모니터링하고 적시에 대응하는 것이 중요하다.

고려사항

• 정기 재확인 일정 수립: 최소 연 1회 정기 내부 감사를 통해 모든 입증자료 항목의 유효성을 재확인하고 문서화한다.
• 규격 개정 모니터링: OpenChain 프로젝트의 규격 개정 공지를 정기적으로 확인하고, 새 버전 발행 시 18개월 이내에 대응 계획을 수립한다.
• 인증 만료 관리: 인증 취득일과 유효 기간(18개월)을 캘린더 또는 관리 시스템에 등록하여 만료 전 갱신 알림을 받도록 설정한다.
• 변경 사항 반영: 조직 구조, 제품 포트폴리오, 프로세스 변경 발생 시 즉시 프로그램에 반영하고 재확인 문서를 갱신한다.

샘플

아래는 ISO/IEC 5230 규격 준수 정기 재확인 기록 샘플이다.

[ISO/IEC 5230 규격 준수 정기 재확인 기록]

프로그램 명칭: [회사명] 오픈소스 컴플라이언스 프로그램
최초 인증 취득일: YYYY-MM-DD
준수 확인 규격: ISO/IEC 5230:2020 (버전 2.1)

| 재확인 날짜 | 확인 결과 | 변경 사항 | 검토자 | 비고 |
|------------|-----------|-----------|--------|------|
| 2025-01-10 | 전체 충족 | 담당자 변경 반영 (§3.2.2.1 갱신) | 홍길동 | - |
| 2026-01-08 | 전체 충족 | 없음 | 홍길동 | 다음 재확인 예정: 2027-01-08 |

다음 재확인 예정일: YYYY-MM-DD (최근 재확인일로부터 12개월 이내)
18개월 유효 기한: YYYY-MM-DD (최근 재확인일로부터 18개월)

아래는 규격 새 버전 발행 시 대응 체크리스트 샘플이다.

[ISO/IEC 5230 새 버전 발행 대응 체크리스트]

새 버전 발행일: YYYY-MM-DD
대응 기한 (18개월): YYYY-MM-DD

□ 새 버전과 현행 버전의 요구사항 변경 사항 파악
□ 변경된 요구사항에 따른 프로그램 갱신 계획 수립
□ 갱신 작업 완료 및 새 버전 기준 입증자료 정비
□ 새 버전 기준 규격 준수 확인 문서 작성 및 승인
□ 자가 인증 또는 인증 갱신 절차 진행

5. 참고

• OpenChain 규격 최신 버전 확인: https://www.openchainproject.org/license-compliance
• 자가 인증 갱신: https://certification.openchainproject.org/
• §3.6.1 적합성: 이전 조항 바로가기