2. 정책

1. 오픈소스 정책 문서화

기업은 소프트웨어 개발, 서비스, 배포에 관여하는 조직이 올바르게 오픈소스를 활용하기 위한 원칙으로 구성된 오픈소스 정책을 수립하여 문서화하고 이를 조직 내 전파해야 합니다.

이를 위해 ISO 표준은 공통적으로 다음과 같이 문서화된 오픈소스 (보안 보증) 정책을 요구합니다.

일반적인 오픈소스 정책은 다음을 포함합니다. 기업은 이러한 원칙을 포함한 오픈소스 정책을 만들어서 문서화해야 합니다.

• 소프트웨어 제품과 서비스 배포할때 라이선스 및 보안 취약점 리스크를 최소화하기 위한 원칙
• 외부 오픈소스 커뮤니티에 기여하기 위한 원칙
• 기업의 소프트웨어를 오픈소스로 공개하기 위한 원칙

2. 오픈소스 정책에서 다뤄야할 내용

오픈소스 정책이 어떤 내용을 포함해야 하는지 보다 자세히 알아보겠습니다.

오픈소스 리스크 대응

오픈소스를 사용하여 제품/서비스를 개발 시 발생할 수 있는 라이선스 및 보안취약점 리스크를 최소화하기 위해 다음과 같은 원칙을 포함해야 합니다.

1. 오픈소스 식별 및 라이선스 의무 사항 검토
2. 오픈소스 라이선스 고려 설계
3. 오픈소스 컴플라이언스 산출물 생성
4. SBOM (Software Bill of Materials) 생성
5. 오픈소스 라이선스 컴플라이언스 이슈 대응
6. 오픈소스 보안 취약점 대응

[부록1] 오픈소스 정책 template의 6. 오픈소스 사용에서 이를 문서화한 원칙을 살펴보실 수 있습니다.

1. 오픈소스 사용

오픈소스를 사용하여 제품 및 서비스를 개발하고 배포하려면 각 오픈소스 라이선스가 요구하는 의무 사항을 준수해야 합니다. 이를 위한 활동을 오픈소스 컴플라이언스라고 합니다.

올바른 오픈소스 컴플라이언스 활동을 위해 소프트웨어 개발/배포 조직은 다음 사항을 준수하고 모든 과정은 Jira Tracker에 기록하여 보존합니다. 

(1) 오픈소스 식별 및 라이선스 의무 사항 검토

오픈소스를 제품 / 서비스 개발에 도입 시, 먼저 오픈소스 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무 사항을 검토하고 확인합니다.

회사의 [오픈소스 라이선스 가이드]에는 주요 오픈소스 라이선스 목록이 포함되어 있으며, 라이선스마다 다음의 배포 형태별 요구하는 의무사항을 구분하여 설명합니다.

- 바이너리 형태
- 소스 형태
- 강한/약한 Copyleft
- SaaS 기반 제공
- 수정 여부
- 저작자 표시 요구 오픈소스 포함 등. 

소프트웨어 개발/배포 조직은 오픈소스 라이선스 의무 검토 시 이 가이드를 참고할 수 있습니다. 이 가이드에서 언급하지 않는 오픈소스 라이선스의 검토가 필요할 경우, 오픈소스 프로그램 매니저에게 문의합니다.

(2) 오픈소스 라이선스 고려 설계

오픈소스의 결합 관계를 파악하여 자사의 코드가 오픈소스 라이선스의 영향을 받지 않도록 소프트웨어 아키텍처를 설계합니다.

회사의 [오픈소스 라이선스 가이드]에서는 오픈소스 라이선스별 소스 코드 공개 범위 및 자사 코드의 공개를 방지하기 위한 설계 방법을 설명합니다.

(3) 오픈소스 컴플라이언스 산출물 생성

오픈소스 컴플라이언스 활동의 가장 기본은 배포용 소프트웨어에 포함된 오픈소스 현황을 파악하는 것입니다. 이는 바로 오픈소스 컴플라이언스의 핵심인 오픈소스 라이선스 요구사항을 올바르게 충족하기 위해서입니다. 즉, 배포용 소프트웨어에 포함된 오픈소스에 대한 컴플라이언스 산출물 세트를 생성해야 합니다.

오픈소스 컴플라이언스 산출물은 크게 두 가지로 구분됩니다.

1. 오픈소스 고지문 : 오픈소스 라이선스 전문과 저작권 정보 제공을 위한 문서
2. 공개할 소스 코드 패키지 : GPL, LGPL 등 소스 코드 공개를 요구하는 오픈소스 라이선스 의무 이행을 위해 공개할 소스 코드를 취합한 패키지

이러한 컴플라이언스 산출물을 취합, 배포, 보관하기 위해 다음 사항을 준수합니다.

- 오픈소스 고지문이나 공개할 소스 코드 패키지는 각 라이선스가 요구하는 조건대로 취합합니다. 예를 들어, 라이선스가 라이선스 전체 텍스트의 동봉을 요구하는데, 링크만을 제공해서는 안 됩니다.
- 취합한 산출물은 별도의 저장소에 보관합니다.
- 공개할 소스 코드를 서면 약정서로 제공할 경우, 취합한 산출물의 저장소를 외부에서 접근할 수 있도록 다운로드 링크를 공개합니다.
  
회사의 오픈소스 프로세스를 통해 오픈소스 고지문을 발급하고, 공개할 소스 코드 패키지를 취합할 수 있습니다.

(4) SBOM (Bill of Materials) 생성

배포용 소프트웨어에 포함된 오픈소스 현황(BOM : Bill of Materials)을 생성하고 관리해야 합니다.

회사의 오픈소스 프로세스를 통해 오픈소스 도구를 활용하여 SBOM을 생성하고 보존할 수 있습니다.

(5) 컴플라이언스 이슈 대응 절차

컴플라이언스 이슈가 제기될 경우, 오픈소스 프로그램 매니저는 다음의 절차를 수행하여 신속히 대응합니다.

1. 문의 접수를 확인하고 적절한 해결 시간을 명시합니다.
2. 이슈 내용이 실제 문제를 지적하고 있는지를 확인합니다. (아닐 경우, 이슈 제기자에게 문제가 아님을 알립니다.)
3. 실제 문제인 경우, 우선순위를 정하고 적절한 대응 방안을 결정합니다.
4. 대응을 수행하고, 필요할 경우, 오픈소스 프로세스를 적절하게 보완합니다.
5. 위의 내용은 Jira Tracker를 이용하여 보존합니다.

(6) 오픈소스 보안취약점 대응

- 오픈소스 취약점을 식별하고, 심각도를 평가합니다. 
- 오픈소스 취약점 분석 결과에 따라 취약점을 수정하거나 보안 패치를 적용합니다. 취약점 조치는 취약점의 심각도, 시스템의 중요도, 취약점 수정 또는 보안 패치의 가용성 등을 고려하여 결정합니다. 
- 새로운 오픈소스 보안 취약점이 발표되는 것을 감시하고, 취약점 발생 시 신속하게 대응합니다. 오픈소스 취약점 모니터링은 CVE와 같은 취약점 데이터베이스, 보안 전문 기관의 웹사이트 등을 통해 수행할 수 있습니다. 

내부 책임 할당 절차

오픈소스 정책은 오픈소스 관리 이슈를 해결하기 위한 책임을 내부에 할당하는 절차를 다뤄야 합니다.

ISO 표준은 공통적으로 다음과 같이 내부 책임을 할당하는 문서화된 절차를 요구합니다.

먼저 오픈소스 프로그램 매니저는 컴플라이언스 이슈를 파악하고 이를 해결하기 위해 각 역할의 담당자에게 적절히 책임을 할당해야 합니다. 마찬가지로 오픈소스 보안 취약점 이슈에 대해서는 보안 담당이 이슈를 파악하고 이를 해결하기 위해 적절한 인원에게 책임을 할당합니다.

이를 위해 아래의 예시와 같이 오픈소스 정책에 내부 책임을 할당하는 문서화된 절차를 반영할 수 있습니다.

4. 역할, 책임 및 역량

정책의 효과를 보장하기 위해 다음과 같이 역할과 책임 및 각 역할의 담당자가 갖추어야 할 역량을 정의합니다.

(2) 오픈소스 프로그램 매니저

- 오픈소스 컴플라이언스를 위해 필요한 역할을 정의하고, 각 역할을 책임질 담당 조직 및 담당자를 지정합니다. 필요 시 OSRB와 협의합니다. 오픈소스 보안 보증을 위한 내부 책임은 보안 담당자가 할당합니다.

(6) 보안 담당

- 오픈소스 보안 보증을 성공할 수 있도록 각 업무에 대한 책임을 할당합니다.

미준수 사례 대응

기업은 컴플라이언스 미준수 사례가 발생히면 이를 신속히 검토하고 대응하기 위한 절차를 문서화해야 합니다.

ISO/IEC 5230은 다음과 같이 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차 요구합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차를 반영할 수 있습니다.

6. 오픈소스 사용

(5) 컴플라이언스 이슈 대응 절차

컴플라이언스 이슈가 제기될 경우, 오픈소스 프로그램 매니저는 다음의 절차를 수행하여 신속히 대응합니다.

1. 문의 접수를 확인하고 적절한 해결 시간을 명시합니다.
2. 이슈 내용이 실제 문제를 지적하고 있는지를 확인합니다. (아닐 경우, 이슈 제기자에게 문제가 아님을 알립니다.)
3. 실제 문제인 경우, 우선순위를 정하고 적절한 대응 방안을 결정합니다.
4. 대응을 수행하고, 필요할 경우, 오픈소스 프로세스를 적절하게 보완합니다.
5. 위의 내용은 Jira Tracker를 이용하여 보존합니다.

인원, 예산 지원

기업은 오픈소스 프로그램이 원활하게 기능을 수행할 수 있도록 충분한 리소스를 제공해야 합니다. 프로그램 내 각 역할을 담당하는 인원을 적합하게 배치하고, 충분한 예산과 업무 시간을 보장해야 합니다. 그렇지 않을 경우, 이를 보완할 수 있는 절차가 마련되어야 합니다.

ISO 표준은 공통적으로 다음과 같이 프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되어야 함을 요구합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 인원, 예산 지원에 대한 내용을 반영할 수 있습니다.

4. 역할, 책임 및 역량

각 역할에 대한 담당 조직의 장은 조직 내 담당자를 지정하고, 담당자가 역할을 충실하게 수행할 수 있는 적절한 시간과 예산을 할당합니다.

- 각 역할의 담당자는 자신이 역할을 수행하면서 적절한 지원이 되지 않는다면 오픈소스 프로그램 매니저에게 문제를 제기해야 합니다.
- 오픈소스 프로그램 매니저는 해당 조직장과 문제 해결을 논의합니다. 적절하게 해결되지 않는다면, 오픈소스 프로그램 매니저는 OSRB에 문제 해결을 요청할 수 있습니다.
- OSRB는 상위 조직의 장에게 문제를 공유하고 해결을 요청합니다.

전문 자문 제공

기업은 각 역할의 담당자가 오픈소스 이슈를 해결하기 위해 전문적인 검토가 필요할 경우, 이에 대한 자문을 요청할 수 있는 방법을 제공해야 합니다.

ISO 표준은 공통적으로 다음과 같이 문제 해결을 위해 내부 또는 외부의 전문 자문을 이용할 수 있는 방법을 요구합니다.

오픈소스 라이선스 컴플라이언스 이슈에 대해서는 회사 내의 법무팀을 통해 우선 담당하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있습니다.

오픈소스 보안 취약점 이슈에 대해서는 회사 내 보안팀에서 우선 담당하고, 이슈가 복잡하고 첨예한 경우, 외부 보안 전문 기술 업체에 자문을 요청할 수 있습니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 자문을 제공하기 위한 내용을 반영할 수 있습니다.

4. 역할, 책임 및 역량

(4) 법무 담당

법무 담당은 오픈소스 라이선스와 의무를 해석하는 등 오픈소스 활용 과정에서 발생할 수 있는 법적 위험과 완화 방안에 대한 자문을 제공합니다.

- 구성원이 오픈소스 컴플라이언스 이슈에 대한 문의를 할 수 있는 합리적인 방법을 제공합니다.
- 호환되지 않는 오픈소스 라이선스로 인한 충돌을 포함하여 라이선스 및 지식재산권 문제에 대해 자문을 제공합니다.
- 외부 오픈소스 프로젝트로의 기여 시 오픈소스 라이선스, CLA(Contributor License Agreement) 등 필요한 법적 사항을 검토합니다.
- 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인에 자문을 요청합니다.

(6) 보안 담당

보안 담당은 오픈소스 보안 취약점 분석 도구를 운영하여 모든 배포용 소프트웨어에 대해 보안 취약점 분석이 원활히 수행되도록 시스템을 구축합니다.

- 구성원이 보안 취약점에 대한 문의를 할 수 있는 합리적인 방법을 제공하고, 취약점 해결을 위해 필요 시 외부 전문 기술 자문을 이용합니다.

참고로, OpenChain 프로젝트에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공합니다. : https://www.openchainproject.org/partners

OpenChain 파트너로 등록된 법무법인은 OpenChain 프로젝트에서 요구하는 요건을 충족한 곳들이며, 대한민국에서는 유일하게 법무법인 태평양이 등록되어 있습니다.

적용 범위 지정

하나의 오픈소스 정책(프로그램)을 반드시 전체 조직에 적용해야 하는 것은 아닙니다. 기업 내 각 조직과 제품의 특성에 따라 적용 범위를 달리 지정할 수 있습니다. 예를 들어, 소프트웨어를 전혀 배포하지 않는 조직은 오픈소스 프로그램의 적용 범위에서 제외할 수 있습니다.

ISO 표준은 공통적으로 다음과 같이 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술 등을 요구합니다.

기업은 조직과 제품의 특성을 고려하여 오픈소스 프로그램의 적용 범위와 한계를 명확히 정의하고, 이를 오픈소스 정책에 명시해야 합니다.

또한, 비즈니스 환경에 맞추어 변화함에 따라 조직 구조, 제품 및 서비스가 프로그램의 적용 범위를 결정하거나 수정해야 하는 상황이 발생할 수 있습니다. 기업은 적용 범위를 평가하기 위한 측정 기준을 수립하고, 지속적인 개선을 위해 검토, 검사를 수행하여 미흡한 부분을 개선해야 합니다.

이를 위해 기업은 아래와 같이 오픈소스 정책에 다음과 같이 적용 범위에 대해 명확히 정의하고, 활동 이력을 문서화하는 체계를 갖춰야 합니다.

2. 적용 범위

이 정책은 다음 세 부분에 적용됩니다.

1. 회사가 외부로 제공하거나 배포하는 모든 제품에 적용됩니다. 단, 오픈소스를 내부 사용 목적으로만 사용하는 것은 이 정책의 범위에 포함되지 않습니다.
2. 구성원이 외부 오픈소스 프로젝트에 기여할 때 적용됩니다.
3. 내부 코드를 오픈소스로 공개할 때 적용됩니다.

적용 범위는 회사의 비즈니스 환경에 맞추어 변경할 수 있습니다. 특히, 오픈소스 프로그램 매니저는 지속적인 효과를 보장하기 위해 이 정책의 적용되지 않고 사외로 배포 혹은 서비스되는 제품이 있는지 월 1회 이상 조사합니다. 이를 측정하여 1건이라도 발견 시 적용 범위를 변경해야 하는 기준으로 삼습니다.

적용 범위를 변경하기 위한 절차는 다음과 같습니다.

1. 오픈소스 프로그램 매니저는 신규사업, 조직개편 등 회사의 비즈니스 환경이 변화에 따라 정책의 적용 범위 변경이 필요하다고 판단할 경우, 이를 위한 제안을 OSRB에 제출합니다.
2. OSRB에서는 적절한 수준의 적용 범위 변경을 승인합니다.
3. OSRB는 오픈소스 정책을 수정하여 정책의 적용 범위를 변경합니다.

오픈소스 프로그램 매니저는 지속적으로 월 1회 이상 적용 범위를 개선하기 위해 검토, 업데이트 및 검사 이력을 Jira Issue Tracker를 활용하여 문서화합니다.

따라서 기업은 오픈소스 정책에 다음과 같이 적용 범위를 명확히 정의하고, 활동 이력을 문서화하는 체계를 갖춰야 합니다.

외부 문의 대응

오픈소스를 사용하여 개발한 제품 또는 서비스에 대해 고객 및 오픈소스 저작권자가 기업에 오픈소스 관련 문의, 요청 및 클레임을 제기하기 위해 연락을 취하는 경우가 있습니다. 외부 문의 및 요청의 주된 내용은 다음과 같습니다.

• 특정 제품 또는 서비스에 오픈소스가 사용되었는지 문의
• 서면 약정(Written Offer)에 언급된 GPL, LGPL 라이선스 하의 소스 코드 제공 요청
• 오픈소스 고지문에 명시되지 않았지만, 제품에서 발견된 오픈소스에 대한 해명 및 소스 코드 공개 요청
• GPL, LGPL 등의 의무로 공개된 소스 코드에 누락된 파일 및 빌드 방법 제공 요청
• 저작권 표시 요청
• 오픈소스 보안 취약점 관련한 문의 및 요청

기업은 이러한 외부 문의를 처리할 담당자를 지정해야 합니다. 일반적으로 오픈소스 프로그램 매니저가 담당합니다.

외부의 오픈소스 개발자가 특정 기업의 오픈소스 관련 이슈를 논의하기 위해 기업 담당자에게 연락하고 싶어도 연락 방법을 찾지 못하다가 결국 바로 법적 클레임을 제기하는 경우가 있습니다. 이를 방지하기 위해 기업은 제3자가 기업에 오픈소스 관련하여 문의 및 요청을 할 수 있는 연락 방법을 항시 공개적으로 밝혀야 합니다.

ISO 표준은 공통적으로 다음과 같이 제3자가 오픈소스에 대해 문의할 수 있는 공개된 방법을 요구합니다.

외부에서 기업에 오픈소스 관련 문의를 할 수 있도록 다음과 같이 연락 방법을 제공할 수 있습니다.

1. 오픈소스 담당 조직의 대표 이메일 주소를 공개합니다.
2. Linux Foundation의 Open Compliance Directory를 이용합니다.
3. 기업의 오픈소스 웹사이트가 있다면 이를 통해 이메일 주소를 공개합니다.

제품 및 서비스와 동봉하는 오픈소스 고지문에 오픈소스 담당 조직의 대표 이메일 주소를 포함하여 공개하는 것도 좋은 방법입니다.

기업은 아래의 예시와 같이 오픈소스 정책에 외부 문의 대응에 대한 내용을 반영할 수 있습니다.

9. 외부 문의 대응

(1) 외부 문의 대응 책임

외부로부터 오픈소스에 대한 문의 및 요청에 대한 대응은 오픈소스 프로그램 매니저가 담당합니다.

- 오픈소스 프로그램 매니저는 회사 내의 적절한 인원에게 문의에 대한 전체 또는 일부의 처리를 할당할 수 있습니다. 필요할 경우 법률 담당자에게 문의하여 처리합니다.
- 외부로부터 오픈소스에 대한 문의를 받은 사람은 누구나 이를 오픈소스 프로그램 매니저에게 알려서 신속한 대응이 될 수 있게 합니다.

(2) 연락처 공개

오픈소스 프로그램 매니저는 외부에서 오픈소스 관련한 문의 및 요청을 할 수 있도록 담당자의 연락처를 공개적으로 제공합니다.

- 오픈소스 고지문에 연락받을 수 있는 이메일 주소 정보를 제공합니다.
- 오픈소스 웹사이트에 이메일 주소 정보를 제공합니다.
- Linux Foundation의 Open Compliance Directory에 연락처를 등록합니다.

(3) 외부 문의 대응 절차

외부로부터의 오픈소스 문의에 신속하고 정확하게 대응한다면 클레임이나 법적 소송 위험을 크게 줄일 수 있습니다. 이를 위해 회사는 외부의 오픈소스 문의에 대응하기 위해 회사의 오픈소스 프로세스에서 정의한 외부 문의 대응 절차를 준수합니다.

SK텔레콤은 모든 제품에 오픈소스 고지문을 포함하고 있습니다. 오픈소스 고지문에는 SK텔레콤 오픈소스 웹사이트 주소와 오픈소스 프로그램 오피스로 연락할 수 있는 메일 주소가 함께 제공됩니다.

또한, SK텔레콤 오픈소스 웹사이트에서도 오픈소스 프로그램 오피스로 연락할 수 있는 메일 주소를 제공하고 있습니다.

오픈소스 기여

글로벌 소프트웨어 기업들은 제품을 만들고 서비스를 제공하는 데 오픈소스를 사용하는 것뿐만 아니라 오픈소스 프로젝트에 기여하고 창출할 수 있는 전략적 가치도 중요시합니다. 그러나 오픈소스 프로젝트 생태계와 커뮤니티 운영 방식에 대한 충분한 이해와 전략 없이 접근한다면 예기치 않게 회사의 명성이 손상되고 법적 위험이 발생할 수 있습니다. 따라서 기업은 오픈소스 프로젝트에 참여하고 기여하기 위한 전략과 정책을 수립하는 것이 중요합니다.

ISO/IEC 5230은 다음과 같이 문서화된 오픈소스 기여 정책을 요구합니다.

이러한 오픈소스 기여에 대한 정책은 [부록1] 오픈소스 정책 샘플 7. 오픈소스 기여에서 확인할 수 있습니다.

7. 오픈소스 기여

회사는 오픈소스에서의 비즈니스 가치 창출을 위해 외부 오픈소스 프로젝트로의 참여와 기여를 권장합니다. 그러나 이 과정에서 의도하지 않은 회사의 지식 재산 노출 혹은 제 3자의 권리 침해에 주의해야 합니다. 이를 위해 회사의 구성원이 외부 오픈소스 프로젝트로의 기여를 위해서는 다음 사항을 준수해야 합니다.

(1) 리뷰 요청 및 승인

오픈소스 기여는 저작권 관점에서 저작자가 저작물을 수정/사용/배포할 수 있는 권한을 오픈소스 프로젝트에 부여하는 것입니다. 때에 따라서는 오픈소스 프로젝트에 여러분의 저작권을 양도해야 하기도 합니다. 그런데 일반적으로 고용 기간에 만든 저작물의 저작권은 고용주가 소유합니다. 즉, 회사 구성원이 만든 저작물은 회사가 소유합니다. 구성원이 임의로 저작물을 오픈소스에 기여하는 행위는 불필요한 저작권 침해 이슈를 유발할 수 있습니다.

따라서, 기여하고자 하는 오픈소스 프로젝트가 있다면 오픈소스 기여 프로세스에 따라 최초 기여하기 전에 리뷰 요청 및 승인 절차를 준수합니다.

단, 다음과 같이 단순한 내용일 경우, 저작권 침해 리스크가 크지 않기 때문에 리뷰 절차 없이 구성원의 판단에 따라 기여할 수 있습니다.

- 10 라인 이하의 작은 코드 조각
- Stack Overflow에서의 문의 / 답변
- GitHub에서의 관리 활동 : Issue 생성, Pull Request Review / Approve 등

...

기업은 이를 참고하여 기업의 상황에 맞는 오픈소스 기여에 대한 원칙을 오픈소스 정책에 포함해야 합니다.

Summary

오픈소스 정책을 문서화하는 것은 효과적인 오픈소스 관리를 위해 가장 중요한 과정입니다.

다음 페이지에서 위에서 언급한 ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족하는 샘플 오픈소스 정책 문서를 제공합니다. : [부록1] 오픈소스 정책 (template)

위의 내용을 참고하여 각 요구사항을 회사의 상황에 맞게 적절한 원칙을 수립하는 것이 필요합니다. 또한 문서로만 그치지 않고, 실행 가능한 절차까지 고려해야 합니다. 말뿐인 정책은 소용이 없습니다.

이렇게 오픈소스 정책을 수립하고 문서화하면, ISO 표준 규격 중 아래의 주황색으로 표시된 요구사항을 충족할 수 있습니다.