프로젝트는 어떻게 졸업하고, 결정은 누가 내리는가

한 줄 요약

CNCF 프로젝트는 Sandbox → Incubating → Graduated 세 단계를 지나며 TOC(Technical Oversight Committee)가 승인합니다. 쿠버네티스 안에서는 SIG 가 코드와 결정을 소유하고, WG 는 SIG 를 가로지르는 주제를 다루며, 큰 변경은 KEP 로 제안합니다. 기여는 CLA 서명과 행동 강령 준수에서 시작해 OWNERS 파일의 reviewer·approver 가 /lgtm·/approve 로 승인하면 자동으로 병합됩니다.

왜 이게 필요했나

KCNA 의 Cloud Native Architecture 도메인은 도구만이 아니라 도구를 만드는 사람들의 구조를 묻습니다. 이유는 실무적입니다. 어떤 프로젝트를 채택할지 판단하려면 그것이 Sandbox 인지 Graduated 인지가 성숙도의 첫 신호이고, 버그를 만났을 때 어느 SIG 에 이슈를 내야 하는지 알아야 답을 받으며, 기능이 왜 그렇게 설계됐는지는 KEP 에 적혀 있습니다. 커뮤니티 구조를 모르면 오픈 소스를 쓰는 것이 아니라 내려받기만 하는 것입니다.

어떻게 동작하나

CNCF 프로젝트의 성숙도와 TOC

[CNCF TOC 저장소](https://github.com/cncf/toc) 에 따르면 TOC 는 CNCF 의 기술 통치 기구로, 모든 프로젝트를 받아들이고 감독하며, 기술 비전과 원칙을 정하고, 이사회(Governing Board)가 정한 범위 안에서 새 프로젝트를 승인하고, 프로젝트를 정렬·제거·보관하며, 최종 사용자 기술 자문 위원회의 의견을 프로젝트에 반영합니다. 구성원 목록에는 GB 가 임명한 위원, TOC 가 임명한 위원, 최종 사용자가 임명한 위원이 각각 2년 임기로 적혀 있습니다.

프로젝트 단계는 [TOC 프로세스 문서](https://github.com/cncf/toc/blob/main/process/README.md) 가 정의합니다.

| 단계 | 문서의 정의 |
| --- | --- |
| Sandbox | 초기 단계의 실험적·혁신적 프로젝트. 실패 가능성이 있고, 큰 변경과 호환성 깨짐이 예상되며, 초기 채택자의 피드백으로 다듬어지는 중 |
| Incubating | 채택이 늘고 안정성이 보이는 중간 단계. 변경 속도가 느려지고 버전이 붙은 API 가 안정되며, TOC 가 채택을 적극적으로 평가하기 시작하는 지점 |
| Graduated | 가장 성숙한 단계. 안정성·기능·시장에서의 폭넓은 채택을 보였고, 성숙한 관행·보안 조치·활발한 커뮤니티 참여를 갖춤 |
| Archived | 활동이 없거나 낮아 TOC 가 더 지원하지 않거나 사용을 권하지 않는 프로젝트 |

[CNCF 프로젝트 페이지](https://www.cncf.io/projects/) 는 Graduated 와 Incubating 프로젝트를 "안정적이며 운영 환경에서 성공적으로 쓰이는 것으로 간주된다" 고 소개하고, [Sandbox 페이지](https://www.cncf.io/sandbox-projects/) 는 Sandbox 를 기존 CNCF 프로젝트를 확장하는 새 프로젝트, 새로운 접근을 시도하는 독립 프로젝트, CNCF 가 의뢰한 실험 프로젝트의 집이라고 설명합니다. 채택 판단에서 단계는 "얼마나 검증됐는가" 의 신호이지 "얼마나 좋은가" 의 신호가 아닙니다. Sandbox 도 일부 조직은 운영에 쓴다고 문서가 적습니다.

쿠버네티스의 SIG, WG, 위원회

[쿠버네티스 거버넌스](https://github.com/kubernetes/community/blob/master/governance.md) 문서에 따르면 프로젝트는 주로 SIG(Special Interest Group)로 조직됩니다. SIG 는 여러 회사와 조직의 구성원으로 이루어지고 네트워킹·문서처럼 특정 주제에 대해 프로젝트를 발전시키는 공통 목적을 가집니다. 목표는 분산된 결정 구조와 코드 소유권이며, 프로젝트의 식별 가능한 모든 부분(GitHub 조직·저장소·디렉터리·API·테스트·이슈·PR)은 어떤 SIG 가 소유하도록 되어 있습니다. SIG 의 종류는 수직(Network·Storage·Node·Scheduling), 수평(Scalability·Architecture), 프로젝트 지원(Testing·Release·Docs·Contributor Experience)으로 나뉩니다. SIG 마다 최소 한 명, 바람직하게는 두 명의 의장(chair)이 있고, 범위·책임·권한·역할 선출 방식·결정 방식·갈등 해결 방식을 적은 헌장(charter)이 있어야 합니다. [SIG 거버넌스](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md) 는 SIG 가 적어도 3주마다 30분 이상 공개 회의를 하고, 회의록과 녹화를 공개하며, 연간 보고서를 내야 한다고 정합니다. SIG 안에는 하위 프로젝트(subproject)가 있고, [SIG 목록](https://github.com/kubernetes/community/blob/master/sig-list.md) 은 각 SIG 의 의장·연락처·회의 시간을 적어 둔 곳입니다.

WG(Working Group)는 거버넌스 문서에 따르면 쿠버네티스 범위 안에 있지만 SIG 경계를 가로지르는 주제를 논의하기 위한 것이고, SIG 목록 문서는 이를 시간이 정해진(time bounded) 그룹이라고 부릅니다. 위원회(Committee)는 보안이나 행동 강령처럼 신중함이 필요한 주제를 다루며, SIG 와 달리 열린 회원제가 아니고 항상 공개로 운영되지도 않습니다. 운영 위원회(Steering Committee)가 필요에 따라 위원회를 만들고 구성원을 정합니다.

KEP — 변경을 제안하는 방법

[KEP 안내](https://github.com/kubernetes/enhancements/blob/master/keps/README.md) 에 따르면 KEP(Kubernetes Enhancement Proposal)는 쿠버네티스에 새 작업을 제안·소통·조율하는 방법입니다. 시작은 후원 SIG 에 아이디어를 알리는 것입니다 — 메일링 리스트에 보내거나 회의 안건에 올려, 다른 사람들이 그 일이 할 만하다고 보고 리뷰를 도울지 확인한 뒤 KEP 템플릿을 따릅니다. 문서는 "대체로 KEP 를 써야 한다" 고 답합니다 — 논쟁이 될 수 있는 것, 아주 작은 것을 뺀 대부분의 새 기능, 기존 기능의 큰 변경, 프로젝트 대부분에 영향을 주는 변경은 KEP 가 필요합니다. 거의 모든 KEP 는 SIG 하위 디렉터리에 두고, 과정은 IETF RFC·Python PEP·Rust RFC 에서 영감을 받았습니다. KEP 의 가치는 승인자와 리뷰어가 있는 분명한 절차로 결정이 남고, 그 결정을 나중에 찾아볼 수 있다는 데 있습니다.

행동 강령

[쿠버네티스 커뮤니티 행동 강령](https://kubernetes.io/community/code-of-conduct/) 페이지는 쿠버네티스가 CNCF 행동 강령(v1.3)을 따른다고 적고 전문을 옮겨 둡니다. 서약의 요지는 이슈 보고·기능 요청·문서 갱신·PR 제출·행사 참석 등 어떤 방식으로 참여하든 모든 사람을 존중하고, 나이·장애·민족·경험 수준·성별·국적·인종·종교·성적 지향 등 어떤 차원에서도 괴롭힘 없는 참여를 보장한다는 것입니다. 적용 범위는 프로젝트와 커뮤니티 공간, 그리고 참여자의 말과 행동이 CNCF 프로젝트나 다른 참여자를 향할 때의 다른 공간까지입니다. 리눅스 재단이 전문 인력으로 운영하는 CNCF 행사는 별도의 행사 행동 강령을 따릅니다. [CNCF 행동 강령 페이지](https://www.cncf.io/conduct/) 에는 강령 본문 외에 FAQ, 행동 강령 위원회와 그 헌장, 사건 해결 절차, 관할과 상신 정책, 투명성 보고서, 옴부즈퍼슨이 정리되어 있습니다.

기여 — 이슈, PR, 리뷰

[기여자 안내](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) 는 코드를 내기 전에 할 일을 셋으로 정합니다 — GitHub 계정 만들기, CLA(Contributor License Agreement) 서명(연습용 저장소 kubernetes-sigs/contributor-playground 에 PR 을 여는 것이 가장 쉬운 길), 행동 강령과 커뮤니티 가치 읽기. 이 셋은 첫 제출 때 봇이 자동으로 확인합니다. 개발 환경 설정은 코드 변경을 낼 때만 필요하고, 문서나 이슈로도 기여할 수 있습니다.

[PR 안내](https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md) 가 설명하는 리뷰는 두 단계입니다. 해당 디렉터리의 [OWNERS 파일](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) 에 reviewer 로 적힌 사람이 /lgtm 을 붙이면 코드가 신뢰받는 리뷰어의 검토를 통과했다는 신호이고, approver 로 적힌 사람이 /approve 를 붙이면 최종 검토를 통과해 자동 병합할 준비가 됐다는 신호입니다. 병합은 Prow 봇이 합니다. OWNERS 파일은 디렉터리마다 둘 수 있고 하위 디렉터리에도 적용되며, Chromium 의 OWNERS 파일에서 영감을 받았습니다. 리뷰 속도는 리뷰할 수 있는 사람 수에, 리뷰 품질은 그 코드에 대한 익숙함에 매이므로, OWNERS 로 책임을 나누는 것이 두 문제를 함께 푸는 방법입니다.

행사

[CNCF 행사 페이지](https://www.cncf.io/events/) 는 행사를 네 갈래로 나눕니다. KubeCon + CloudNativeCon 은 채택자와 기술자를 전 세계 규모로 모으는 대표 콘퍼런스이고, Co-located Event 는 특정 프로젝트·랜드스케이프 계층·산업 분야에 집중해 KubeCon 과 함께 열리는 CNCF 주최 행사이며, Project Event 는 특정 프로젝트를 중심으로 한 몰입형 모임이고, KCD(Kubernetes Community Days)는 지역 커뮤니티가 주최하고 CNCF 가 지원하는 행사로 처음 발표하는 사람과 커뮤니티에 새로 온 사람에게 낮은 문턱을 제공합니다.

현장에서 만나는 모습

"이 프로젝트 써도 되나요?" CNCF 랜드스케이프에서 단계를 먼저 봅니다. Graduated 면 여러 조직이 운영에서 검증했다는 뜻이고, Sandbox 면 호환성 깨짐을 각오하고 초기 채택자로 들어가는 것입니다. 단계는 TOC 의 판단이지 벤더의 광고가 아닙니다.

버그를 발견했는데 어디에 낼지 모르겠다. 쿠버네티스 저장소의 해당 디렉터리에서 OWNERS 파일을 열면 그 코드를 소유한 SIG 와 리뷰어가 보입니다. SIG 목록에서 회의 시간과 슬랙 채널을 찾아 먼저 물어보는 것이 이슈를 방치되지 않게 하는 길입니다.

다음 퀴즈에서 확인할 것

퀴즈에서는 성숙도 단계의 정의와 TOC 의 역할, SIG 와 WG 의 차이, KEP 가 필요한 변경, 기여 전 필수 절차, /lgtm 과 /approve 의 주체, 그리고 행사의 종류를 묻습니다.