feat(i18n): add Korean translation for MAINTAINERS

MAINTAINERS.ko.md

@@ -0,0 +1,191 @@
+# Maintainers
+
+<p align="center"><a href="MAINTAINERS.md">English</a> · <a href="MAINTAINERS.pt-BR.md">Português (Brasil)</a> · <a href="MAINTAINERS.de.md">Deutsch</a> · <a href="MAINTAINERS.fr.md">Français</a> · <a href="MAINTAINERS.zh-CN.md">简体中文</a> · <a href="MAINTAINERS.ja-JP.md">日本語</a> · <b>한국어</b></p>
+
+이 문서는 `nexu-io/open-design`의 Maintainer가 되고, 그 역할을 맡고, 물러나는 규칙을 정합니다. Core Team의 개별 명단은 내부에서 관리하므로 여기에 적지 않습니다. 공개적으로 중요한 건 모두가 따르는 규칙 그 자체입니다.
+
+> **상태**: v1, 2026-05-11 초안 작성. [`CONTRIBUTING.ko.md`](CONTRIBUTING.ko.md#maintainer-되기)와 짝을 이루는 문서입니다. CONTRIBUTING.ko.md는 전체 규칙을 확인하려는 기여자를 이 문서로 안내합니다.
+
+---
+
+## 역할
+
+| 역할 | 권한 |
+|---|---|
+| **Contributor** | 머지된 PR이 1건 이상인 모든 사람. 특별한 권한은 없습니다. |
+| **External Maintainer** | 아래 규칙에 따라 승격된 커뮤니티 기여자. 리뷰, 승인, issue 닫기/다시 열기, issue 셀프 배정을 할 수 있습니다. **머지 버튼은 누를 수 없습니다** — 이 권한은 Core Team이 갖습니다. |
+| **Core Team** | Open Design의 내부 팀. 저장소 전체 쓰기 권한을 갖고, 거버넌스 결정의 최종 권한을 가집니다. 명단은 내부에서 관리합니다. |
+
+별도 언급이 없으면 이 문서의 나머지는 모두 **External Maintainer**에 관한 내용입니다.
+
+---
+
+## Maintainer만 할 수 있고 Contributor는 할 수 없는 것
+
+| 동작 | Contributor | Maintainer |
+|---|:---:|:---:|
+| PR 승인 | ⚠️ 단순 코멘트로 처리되며, 머지에 필요한 승인으로 **인정되지 않음** | ✓ 머지에 필요한 승인으로 인정됨 |
+| issue 닫기 / 다시 열기 | 본인이 연 issue만 | ✓ 모든 issue |
+| 열려 있고 배정되지 않은 issue 셀프 배정(P0 우선) | ✗ | ✓ |
+
+### 머지 조건
+
+PR은 누가 작성했든 다음 **세 가지를 모두** 만족해야 합니다.
+
+1. 코드 충돌이 없을 것.
+2. CI가 완전히 통과(green)할 것.
+3. Maintainer 또는 Core Team 멤버의 승인이 최소 1건 있을 것.
+
+대부분의 PR은 Maintainer의 승인을 거쳐 머지됩니다. Maintainer의 신뢰가 프로젝트의 일상에 가장 직접적으로 드러나는 방식입니다.
+
+---
+
+## Maintainer가 되는 방법
+
+진입 조건은 **세 가지**이며, 모두 충족해야 합니다.
+
+### 1. 기여량
+
+- `nexu-io/open-design`에 머지된 PR **20건 이상**.
+
+이 수치는 자동 통과 기준이 아니라 최소선입니다. PR 20건을 넘기면 검토 대상에 오를 뿐, 역할이 보장되지는 않습니다.
+
+### 2. 계정 신뢰도(다중 계정·봇 방지)
+
+후보의 GitHub 프로필을 일곱 가지 항목으로 점검합니다. **7개 중 5개 이상의 통과 기준을 만족하고, 거부 기준은 하나도 건드리지 않아야 합니다.**
+
+| # | 항목 | 통과 기준 | 거부 기준 |
+|---|---|---|---|
+| 1 | GitHub 계정 나이 | 1년 이상 | 90일 미만 |
+| 2 | 공개 저장소 | 3개 이상 | 0개 |
+| 3 | 팔로워 | 10명 이상 | 3명 미만 |
+| 4 | 팔로워 / 팔로잉 비율 | 0.30 초과 | 0.05 미만(전형적인 팔로우 농장 패턴) |
+| 5 | 프로필 완성도 | 커스텀 아바타 **그리고** bio / company / blog / twitter 중 하나 이상 | 기본 아바타 **그리고** bio·company·blog가 모두 비어 있음 |
+| 6 | 다른 프로젝트 활동 | **다른** 공개 저장소에 머지된 PR이 하나 이상 있거나, issue/star 활동이 꾸준함 | 머지된 PR이 이 저장소에만 있음 |
+| 7 | 계정 상태 | GitHub 플랫폼 제재 이력 없음(스팸/차단/복구) | 위 항목 중 하나라도 해당 |
+
+#### 초기 프로젝트 면제(저장소가 6개월이 되면 자동 만료)
+
+`nexu-io/open-design`이 최초 커밋으로부터 6개월 미만인 동안에는, 다음 조건에서 **다른 프로젝트 활동**(#6) 거부 기준을 Core Team 합의로 면제할 수 있습니다.
+
+- 항목 1, 2, 3, 5가 통과 기준을 명확히 넘을 것, **그리고**
+- 이 저장소에서의 PR 품질이 Core Team의 직접 리뷰로 높게 평가될 것.
+
+면제할 때는 후보 이름과 날짜를 Core Team 내부 기록에 함께 남깁니다. 저장소가 6개월에 도달하면 이 면제 조항은 더 이상 적용되지 않습니다.
+
+### 3. 기여 품질(Core Team 판단)
+
+정성적인 평가이며 공식에 따르지 않습니다. Core Team은 다음을 봅니다.
+
+- 머지된 PR의 **코드 품질**(정확성, 작업 범위 준수, 저장소 경계 존중).
+- 다른 사람의 PR에 남긴 리뷰 코멘트의 **리뷰 품질**.
+- **커뮤니티 참여** — Discussions, issue 분류, Discord 활동.
+- **협업 신호** — 피드백에 대한 반응, 기꺼이 수정하려는 자세.
+
+앞의 두 조건을 통과하면 후보군에 들어갑니다. 이 세 번째 기준을 넘어서야 지명을 받습니다.
+
+### 선정 절차
+
+1. Core Team 멤버가 내부에서 후보를 제안합니다.
+2. Core Team이 합의에 이릅니다.
+3. Core Team 멤버가 비공개로 연락해 후보의 의사를 확인합니다.
+4. 온보딩.
+5. 공개 발표.
+
+지명 PR도, 공개 투표도, 정해진 임기도 없습니다. 이는 의도적으로 **K8s/Apache의 승인자 투표 모델을 뒤집은** 방식입니다. 프로젝트 초기에는 가벼운 Core Team 합의가 더 빠르게 움직이면서도 같은 수준의 결과를 냅니다. Maintainer 인원이 External Maintainer 다섯 명을 넘어 늘어나면 이 부분을 다시 검토합니다.
+
+---
+
+## 책임과 기대
+
+**엄격한 할당량은 없습니다.** 주간 PR 리뷰 횟수도, 최소 issue 분류 비율도, 응답 시간 SLA도 없습니다. Maintainer는 신뢰의 인정이지, 보수 없는 업무가 아닙니다.
+
+다만 원칙적으로 부탁드리는 것은 다음과 같습니다.
+
+- 맥락을 아는 PR은 승인하고, 모르는 PR은 판단을 보류하세요.
+- 머지 조건(§"머지 조건")을 지키세요. 당신의 승인은 형식적인 도장이 아니라 실질적인 신호입니다.
+- 오랜 기간 자리를 비울 때는 `#maintainers`에 알려 주세요.
+- `#maintainers`에서 공유되는 미공개 로드맵은 기밀로 다뤄 주세요.
+
+Core Team이 나쁜 행태(형식적 승인, 악의적 issue 닫기, 미공개 로드맵 유출 등)의 패턴을 확인하면, §"사유 기반 사임"에 따라 권한을 회수합니다.
+
+---
+
+## Maintainer 전용 접근 권한
+
+위에 적은 저장소 권한 외에도, Maintainer는 일반 커뮤니티가 받지 못하는 몇 가지를 받습니다.
+
+- **Discord `#maintainers` 채널** — Core Team과 공유하는 비공개 작업 공간. 디자인 미리보기, RFC 초안, 그리고 아직 공개되지 않은 로드맵에 대한 내부 조율에 씁니다.
+- **기밀 로드맵** — 아직 발표되지 않은 작업을 미리 볼 수 있습니다. Maintainer는 Core Team 멤버가 공개로 발표하기 전까지 그 내용을 기밀로 다루기로 합의합니다.
+- **Core Team과의 직통 라인** — `#maintainers` 메시지는 공개 Discussions보다 더 빠르고 충실한 답을 받습니다. Core Team은 아키텍처와 로드맵 결정에 Maintainer의 의견을 진심으로 구합니다.
+- **Maintainer 배지** — GitHub 프로필과 MAINTAINERS 관련 저장소 화면에 표시되는 공개 신뢰 표식(GitHub 배지 기능이 준비되는 대로 적용).
+- **승격 시 공개 인정** — 합류할 때 Twitter, GitHub Discussions, Discord에서 발표합니다.
+
+---
+
+## 사임
+
+Maintainer는 종신직이 아닙니다. 세 가지 퇴장 경로가 있습니다.
+
+### 자발적 사임(스스로)
+
+- Maintainer가 Core Team에 메시지를 보내거나 `#maintainers`에 글을 올립니다.
+- 권한은 24시간 안에 회수됩니다.
+- 해당 Maintainer는 **Emeritus** 상태로 전환됩니다.
+- 공개적인 사유는 필요 없습니다.
+
+### 비활동 전환
+
+다음 중 **하나라도** 해당하면 비활동 전환 대상으로 검토합니다.
+
+- 활동 신호(머지된 PR, 리뷰 코멘트, issue 분류, 비중 있는 Discussion이나 Discord 참여)가 90일 연속 없거나, **또는**
+- @ 멘션(PR 리뷰 요청, issue 배정)에 60일 연속 응답이 없음.
+
+절차:
+
+1. Core Team이 `#maintainers`에서 해당 Maintainer를 비공개로 @ 멘션하고, **14일의 응답 기간**을 줍니다.
+2. 14일 안에 의미 있는 응답이 없으면 Emeritus로 전환되고 권한이 회수됩니다.
+3. GitHub Discussions에 짧고 따뜻한 공개 안내를 올립니다: "그동안의 기여에 감사합니다. Emeritus로 전환되었으며, 언제든 다시 돌아오셔도 좋습니다."
+4. 복귀는 쉽습니다 — 아래 "Emeritus"를 참고하세요.
+
+### 사유 기반 사임
+
+다음에 의해 발동됩니다.
+
+- 반복되는 나쁜 행태(예: 함량 미달 PR에 대한 형식적 승인, 악의적 issue 닫기, 권한 남용).
+- 프로젝트 [행동 강령][coc] 위반.
+- 보안 등급의 사고(계정 탈취를 즉시 보고하지 않음, 미공개 로드맵 고의 유출 등).
+
+절차:
+
+1. Core Team 멤버는 누구나 논의를 시작할 수 있습니다.
+2. 조치를 취하기 전에 **Core Team 멤버 3명 이상**이 동의해야 합니다(Core Team 전원 합의까지는 필요하지 않습니다).
+3. 결정 후 24시간 안에: 권한 회수, `#maintainers`에서 제외, 모든 Maintainer 명단에서 제거(Emeritus로 전환되지 **않습니다**).
+4. 당사자에게 결정과 사유를 알리며, 한 차례 이의를 제기할 수 있습니다.
+
+원칙은 **Maintainer를 가급적 유지하는 쪽**입니다. 작은 실수 한 번은 강제 사임의 사유가 되지 않습니다. 사유 기반 경로는 반복되는 패턴이나 심각한 일회성 사고에만 적용합니다.
+
+[coc]: https://www.contributor-covenant.org/
+
+---
+
+## Emeritus
+
+자발적으로 사임하거나 비활동으로 전환된 Maintainer는 **Emeritus**가 됩니다. Emeritus 상태는 다음과 같습니다.
+
+- 쓰기/승인/닫기 권한을 회수합니다.
+- (내부) 명단의 Emeritus 항목에 이름을 남겨 공로를 기립니다.
+- Discord `#maintainers` 접근 권한을 유지합니다(읽기든 글쓰기든 Maintainer가 선택).
+- 이어지는 책임은 없습니다.
+
+### Emeritus에서 복귀
+
+가장 간단한 복귀 경로: 최근 30일 안에 머지된 PR 3건. 그러면 Core Team이 권한을 복원합니다. 다시 지명받을 필요는 없습니다.
+
+Emeritus의 취지는 인생에는 늘 일이 생긴다는 점을 인정하는 것입니다. 안식년, 이직, 육아 같은 일을 양쪽 모두에게 아무런 부담이나 사회적 비용 없이 받아들이려는 것입니다.
+
+---
+
+## 이 문서의 변경
+
+이 문서의 규칙은 Core Team 합의로 개정할 수 있습니다. 중대한 변경(진입 조건, 사임 기준)은 활동 중인 후보에게 적용되기 전에 GitHub Discussions에 발표합니다. 편집상의 명확화는 곧바로 반영할 수 있습니다.