이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.

§3.1 프로그램 기반

1: §3.1.1 정책

2: §3.1.2 역량

3: §3.1.3 인식

4: §3.1.4 프로그램 범위

5: §3.1.5 라이선스 의무

1 - §3.1.1 정책

1. 조항 개요

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

2. 해야 할 활동

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

3. 요구사항 및 입증자료

조항 번호	요구사항 (KO)	입증자료
§3.1.1	공급 소프트웨어의 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 오픈소스 정책이 있어야 한다. 이 정책은 조직 내부에 전파되어야 한다.	3.1.1.1 문서화된 오픈소스 정책 3.1.1.2 프로그램 참여자가 오픈소스 정책의 존재를 알 수 있게 하는 문서화된 절차 (교육, 내부 위키, 혹은 기타 실질적인 전달 방법 등)

영문 원문 보기

§3.1.1 Policy A written open source policy shall exist that governs open source license compliance of the supplied software. The policy shall be internally communicated.
Verification Material(s): 3.1.1.1 A documented open source policy. 3.1.1.2 A documented procedure that makes program participants aware of the existence of the open source policy (e.g., via training, internal wiki, or other practical communication method).

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. 정책
관련 템플릿: 오픈소스 정책 템플릿

2 - §3.1.2 역량

1. 조항 개요

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

2. 해야 할 활동

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

3. 요구사항 및 입증자료

조항 번호	요구사항 (KO)	입증자료
§3.1.2	조직은 다음을 수행해야 한다: - 프로그램의 성과와 효율에 영향을 미치는 역할과 그 책임을 확인한다 - 각 역할을 수행할 프로그램 참여자가 갖춰야 할 필요 역량을 결정한다 - 프로그램 참여자가 적절한 교육·훈련·경험을 바탕으로 자격을 갖춘 자임을 확인한다 - 해당되는 경우 필요한 역량을 확보하기 위해 조치한다 - 역량 보유를 증명하기 위한 정보를 문서화하여 유지한다	3.1.2.1 프로그램의 여러 참여자에 대한 역할과 각 역할의 책임을 나열한 문서 3.1.2.2 각 역할을 위해 필요한 역량을 기술한 문서 3.1.2.3 각 프로그램 참여자의 역량을 평가한 문서화된 증거

영문 원문 보기

§3.1.2 Competence The organization shall:
Identify the roles and responsibilities that impact the performance and effectiveness of the program;
Determine the necessary competence of program participants fulfilling each role;
Ensure that program participants are competent on the basis of appropriate education, training, and/or experience;
Where applicable, take actions to acquire the necessary competence;
Retain appropriate documented information as evidence of competence.
Verification Material(s): 3.1.2.1 A documented list of roles with corresponding responsibilities for the different participants in the program. 3.1.2.2 A document that identifies the competencies for each role. 3.1.2.3 Documented evidence of assessed competence for each program participant.

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. 담당자 현황

3 - §3.1.3 인식

1. 조항 개요

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

2. 해야 할 활동

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

3. 요구사항 및 입증자료

조항 번호	요구사항 (KO)	입증자료
§3.1.3	조직은 프로그램 참여자가 다음 사항을 인식하도록 해야 한다: 오픈소스 정책의 존재와 위치 / 오픈소스 관련 목표 / 프로그램 효과에 대한 자신의 기여 방법 / 프로그램 요구사항을 따르지 않을 경우 발생하는 영향	3.1.3.1 프로그램의 목표, 프로그램 내에서의 참여자 기여 방법 및 프로그램을 준수하지 않을 경우 미치는 영향에 대한 프로그램 참여자의 인식을 평가하였음을 나타내는 문서화된 증거

영문 원문 보기

§3.1.3 Awareness The organization shall ensure that the program participants are aware of:
The open source policy and where to find it;
Relevant open source objectives;
Their contribution to the effectiveness of the program; and
The implications of not following the program’s requirements.
Verification Material(s): 3.1.3.1 Documented evidence of assessed awareness for the program participants - which should include the program’s objectives, contributions within the program, and implications of failing to follow the program’s requirements.

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 교육 및 인식 제고

4 - §3.1.4 프로그램 범위

1. 조항 개요

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

2. 해야 할 활동

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

3. 요구사항 및 입증자료

조항 번호	요구사항 (KO)	입증자료
§3.1.4	공급자의 필요와 비즈니스 모델에 따라 프로그램의 적용 범위가 다를 수 있다. 범위는 전체 조직, 특정 사업 단위, 특정 제품군, 특정 제품, 또는 단일 오픈소스 컴포넌트가 될 수 있다. 범위의 정의는 명확해야 한다.	3.1.4.1 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술

영문 원문 보기

§3.1.4 Program Scope Different programs may be designed to address different scopes depending on the supplier’s needs and business model. The scope might include the entire organization, a particular business unit, a particular product line, a specific product, or even a single open source component. The definition of the scope needs to be clear.
Verification Material(s): 3.1.4.1 A written statement that clearly defines the scope and limits of the program.

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

3.1.4.1 프로그램 적용 범위 진술

준수 방법

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

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

고려사항

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

샘플

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

## 프로그램 적용 범위

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

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

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

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

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

5. 참고

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

5 - §3.1.5 라이선스 의무

1. 조항 개요

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

2. 해야 할 활동

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

3. 요구사항 및 입증자료

조항 번호	요구사항 (KO)	입증자료
§3.1.5	식별된 라이선스가 부과하는 의무, 제한 및 권리를 결정하기 위해 식별된 라이선스를 검토하는 프로세스가 존재해야 한다.	3.1.5.1 각 식별된 라이선스에 의해 부여된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차

영문 원문 보기

§3.1.5 License Obligations A process shall exist for reviewing the identified licenses to determine the obligations, restrictions and rights granted by each license.
Verification Material(s): 3.1.5.1 A documented procedure to review and document the obligations, restrictions, and rights granted by each identified license.

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. 프로세스
관련 템플릿: 오픈소스 프로세스 템플릿