거버넌스 프로세스

거버넌스 프로세스 (Governance Process)

vLLM의 성공은 강한 오픈소스 커뮤니티에서 나와요. vLLM은 공식적인 정책보다 비공식적이고 능력주의(meritocratic)적인 규범을 선호해요. 이 문서는 vLLM의 거버넌스 철학과 관행을 설명합니다.

출처: vLLM 공식 문서 — governance-process

가치 (Values)

vLLM은 가장 빠르고 사용하기 쉬운 LLM 추론 및 서빙 엔진을 목표로 해요. 최신 발전에 뒤처지지 않고, 혁신을 가능하게 하며, 다양한 모델·모달리티·하드웨어를 지원합니다.

설계 가치 (Design Values)

최고의 성능 (Top performance): 시스템 성능이 최우선이에요. 오버헤드를 모니터링하고, 커널을 최적화하며, 벤치마크를 공개합니다. 성능을 남겨두지 않아요.
사용 용이성 (Ease of use): vLLM은 설치·구성·운영이 간단해야 해요. 명확한 문서, 빠른 시작, 깨끗한 로그, 도움되는 오류 메시지, 모니터링 가이드를 제공합니다.
넓은 커버리지 (Wide coverage): 최첨단 모델과 고성능 가속기를 지원하며 새 모델과 하드웨어를 쉽게 추가할 수 있게 해요.
프로덕션 준비 (Production ready): vLLM은 프로덕션에서 24/7 실행돼요. 건강 문제를 운영하고 모니터링하기 쉬워야 해요.
확장성 (Extensibility): vLLM은 근본적인 LLM 인프라로 기능해요. 모든 사용 사례를 다룰 수 없으므로 포크와 커스터마이징이 쉬운 설계를 지향합니다.

협업 가치 (Collaboration Values)

긴밀하고 빠르게 움직임 (Tightly Knit and Fast-Moving): 관리자 팀은 비전, 철학, 로드맵에 대해 정렬돼 있고 서로를 막힘없이 풀어주며 빠르게 움직여요.
개인의 능력 (Individual Merit): 아무도 거버넌스에 돈으로 들어올 수 없어요. 커미터 지위는 개인에게 속하지 회사에 속하지 않습니다. 기여, 유지보수, 프로젝트 관리(스튜어드십)에 보상합니다.

프로젝트 관리자 (Project Maintainers)

관리자는 지속적이고 고품질의 기여와 설계 철학과의 정렬을 바탕으로 계층을 이룹니다.

핵심 관리자 (Core Maintainers)

핵심 관리자는 프로젝트 계획과 의사결정 위원회처럼 기능해요. 다른 관례에서 기술운영위원회(TSC)라고 불릴 수 있는데, vLLM 용어로는 "Project Leads"라고 흔히 불러요. 주간 회의에서 로드맵 우선순위를 조율하고 엔지니어링 자원을 배분합니다.

Project Leads: Woosuk Kwon (@WoosukKwon), Zhuohan Li (@zhuohan123), Simon Mo (@simon-mo), Kaichao You (@youkaichao), Robert Shaw (@robertgshaw2-redhat) 등

책임:

분기별 로드맵 작성 및 각 개발 노력에 대한 책임
vLLM의 기술 방향이나 범위에 대한 주요 변경
프로젝트의 릴리스 전략 정의
모델 제공자, 하드웨어 벤더, 핵심 사용자와 협업해 프로젝트가 올바른 궤도에 있는지 확인

리드 관리자 (Lead Maintainers)

핵심 관리자가 일상 책임을 맡는 동안, 리드 관리자는 프로젝트의 전반적인 방향과 전략을 책임져요. 책임: 핵심 관리자 간 합의가 안 될 때 결정, 기술 거버넌스 변경 채택, 새 커미터 투표 과정 조직.

커미터와 Area Owners

커미터는 쓰기 접근과 병합 권한을 가져요. 특정 영역에 깊은 전문성을 갖고 커뮤니티를 도와주는 경우가 많아요. 책임: PR 리뷰 및 피드백 제공, 커뮤니티 이슈·질문 해결, 코드베이스 특정 영역 소유(PR 리뷰, 이슈 해결, 질문 답변, 문서 개선).

커미터는 거의 모두 area owner예요. 모든 area owner는 해당 영역에 깊은 전문성을 가진 커미터지만, 모든 커미터가 area를 소유하는 것은 아니에요.

커미터 제안 프로세스 (Committer Proposal Process)

어떤 커미터든 비공개 커미터 메일링 리스트를 통해 후보를 지명할 수 있어요. 과정은 다음과 같아요.

지명 (Nominate): 커미터가 후보를 지명하고 기여(PR, 리뷰, RFC, 이슈, 벤치마크, 채택 증거 링크 등)를 강조해 메일을 보내요.
논의 및 투표 (Discuss and vote): 커미터 그룹이 지명을 논의하고 투표하며 필요시 우려를 표명해요. 공유된 우려는 과정을 중단시킬 수 있어요.
피드백 기간 (Feedback period): 2주 피드백 기간 후 차단 우려가 없고 지명자가 리드 관리자 그룹과 진행을 확인하면, 초대장을 보내 코드 소유권(CODEOWNERS, 커미터 목록)을 업데이트하는 PR을 열게 해요.
권한 및 온보딩 (Permissions and onboarding): 병렬로 리드 관리자가 GitHub 권한을 부여하고 메일링 리스트, 커미터 전용 Slack 채널 등에 추가해요.
완료 (Finalize): CODEOWNERS/커미터 PR이 준비되고 권한이 갖춰지면 병합되고 새 커미터가 환영받아요.

커미터십은 매우 선별적이고 능력 기반이에요. 기준은 영역 전문성, 지속적 기여, 커뮤니티 리더십입니다. 예를 들어 과거 커미터들은 약 30+개의 실질적 PR, 10+개의 외부 기여자 PR 리뷰, 다수의 이슈·질문 해결, RFC 구현 리드 등을 해왔어요.

워킹 그룹 (Working Groups)

vLLM은 CI, CI 인프라, torch compile, 시작 UX 같은 비공식 워킹 그룹을 운영해요. vLLM Slack의 #sig-(또는 #feat-) 채널로 느슨하게 추적됩니다.

자문 위원회 (Advisory Board)

vLLM 프로젝트 리드는 모델 제공자, 하드웨어 벤더, 생태계 파트너로 구성된 비공식 자문 위원회와 협의해요. Slack의 협업 채널과 빈번한 커뮤니케이션으로 나타납니다.

프로세스 (Process)

프로젝트 로드맵 (Project Roadmap)

Project Leads는 분기별 로드맵을 GitHub 이슈로 게시해요. https://roadmap.vllm.ai/에서 볼 수 있어요.

의사결정 (Decision Making)

Slack과 GitHub에서 RFC와 설계 문서로 기술 결정을 내려요. 중요한 변경의 공개 기록(문제 설명, 근거, 고려된 대안)을 유지합니다.

코드 병합 (Merging Code)

PR은 최소 한 명의 커미터 리뷰와 승인이 필요해요. CODEOWNERS가 커버하는 코드는 CODEOWNERS가 리뷰해야 해요. 사소한 코드나 핫픽스는 리드 관리자가 직접 병합할 수 있어요. PR과 무관한 이유로 CI가 실패한 경우에는 리드 관리자가 "force merge" 옵션으로 병합할 수 있어요.

AI 지원 기여 (AI Assisted Contributions)

AI 도구가 개발을 가속화할 수 있지만, 기여자는 제출하는 모든 코드에 전적으로 책임을 져요. AI 지원 기여도 다른 코드와 동일한 품질, 테스트, 리뷰 기준을 충족해야 해요. 제출 전에 AI 생성 코드를 리뷰하고 이해해야 합니다.

"순수 에이전트" PR을 제출하지 마세요. 제출하는 사람이 모든 변경 라인을 리뷰하고 E2E 동작을 검증하며 관련 테스트를 실행할 책임이 있어요.
기여자는 PR에서 AI 지원을 공개하고 커밋에 적절한 트레일러(예: Co-authored-by:)를 표시해야 해요.
일회성 "뻔한 작업" PR(단일 오타, 단독 스타일 정리 등)을 피하고, 기계적 정리를 체계적인 범위로 묶으세요.

경고: 이 주제는 AGENTS.md에 에이전트를 위해 정리되어 있어요.

Slack과 회의 (Slack and Meetings)

기여자는 #pr-reviews와 #contributors 채널에 참여하는 것이 권장됩니다. 주간 기여자 싱크 회의가 있어서 진행, 블로커, 계획을 스탠드업 방식으로 공유해요. 참여 안내는 standup.vllm.ai에서 볼 수 있어요.

거버넌스 프로세스