Skip to content
←

필사 모드: 버스 팩터는 아는 사람의 수가 아니라 결정할 수 있는 사람의 수다

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 저장소는 그대로인데 리더십이 사라졌다

2026년 8월 7일, NixOS Discourse에 Nixpkgs 코어 팀이 해산한다는 글이 올라왔습니다. qyliss가 @alyssais와 @emilazy를 대신해 작성했고, 같은 날 NixOS/org 저장소의 PR #277이 병합되면서 @NixOS/nixpkgs-core 팀 정의 자체가 삭제되었습니다.

Nixpkgs는 10만 개가 넘는 패키지를 담은 저장소입니다. 제가 2026년 8월 9일 GitHub API로 직접 세어 보니 최근 2주 남짓(2026년 7월 24일 이후) 병합된 PR이 4,468건이었습니다.

curl -s "https://api.github.com/search/issues?q=repo:NixOS/nixpkgs+is:pr+is:merged+merged:>=2026-07-24&per_page=1" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['total_count'])"
# 4468

그런데 이 저장소의 위임된 기술 리더십을 맡고 있던 팀의 인원은 두 명이었습니다. 그 두 명이 물러나면서 발표문은 이렇게 씁니다. "우리 관할에 속했던 사안들은 현재 직접적인 주인이 없는 상태로 남는다."

이 글은 Nix를 쓰라거나 쓰지 말라는 이야기가 아닙니다. 여러분이 의존하는 프로젝트의 위험을 어디서 재야 하는가에 대한 이야기입니다.

버스 팩터는 지식이 아니라 권한의 수다

버스 팩터를 보통 이렇게 설명합니다. "핵심 인력 몇 명이 버스에 치이면 프로젝트가 멈추는가." 그리고 대개 지식의 문제로 해석합니다. 문서가 부족하다, 특정 모듈을 한 사람만 안다.

Nixpkgs 사례가 보여 주는 것은 다른 축입니다. Nixpkgs는 지식이 집중된 프로젝트가 아닙니다. 기여자가 수천 명이고 커미터도 계속 늘고 있습니다. 코어 팀이 10개월 동안 한 일 중 하나가 바로 커미터 위임 절차를 개혁하고 신규 커미터 19명을 온보딩한 것이었습니다.

그럼에도 팀 두 명이 빠지자 공백이 생겼습니다. 왜냐하면 그 두 명이 갖고 있던 것은 코드 지식이 아니라 결정 권한이었기 때문입니다. 발표문이 인용하는 헌법상 위임 사항은 "Nixpkgs와 관련되는 한에서의 프로젝트 방향, 의사결정, NixOS 재단 이사회와의 조율, 팀의 생성과 관리"입니다.

코드를 짤 사람은 많습니다. "이 방향으로 간다"고 말할 자격이 있는 사람은 두 명이었습니다. 이 둘은 전혀 다른 수이고, 우리는 보통 앞의 수만 셉니다.

발표문이 실제로 말하는 것

해석을 얹기 전에 원문의 사실 관계부터 정확히 옮기겠습니다.

  • 팀은 10개월간 활동했습니다.
  • 성과로 커미터 위임 절차 개혁과 신규 커미터 19명 온보딩, 병합 봇 확장을 통한 메인테이너 권한 강화, GitHub과의 관계 재정립 및 Enterprise Cloud 후원 확보, 보안 권고 GHSA-67f2-674w-6g63 분류 지원, 초기 자동화/AI 정책 수립을 듭니다.
  • 물러나는 직접적 이유는 건강입니다. 원문은 "적극적인 기술 기여와 병행할 수 있는 가벼운 역할로 밝혀지지 않았고, 2주 전 물러나는 것이 우리 건강을 위해 필요하다는 결론에 이르렀다"고 씁니다.
  • 신규 인원 모집에 "실제로 지원한 사람은 한 명"이었고 아웃리치에 대한 반응도 엇갈렸다고 밝힙니다.
  • 운영 위원회에 대해서는 "헌법이 상정한 위임에 대한 본능이 제도적으로 결여되어 있으면서, 그 수준의 개별 결정을 스스로 처리할 만큼 관여하거나 응집되어 있지도 않다"고 진단합니다. 그 결과가 하위 팀에 대한 불필요한 마이크로매니지먼트와 만성적인 소통 부실이라는 것입니다.
  • 마지막으로 "이 결정은 어떤 하나의 사건 때문이 아니라 오래된 패턴의 귀결"이라고 명시합니다.

여기까지가 원문입니다. Nixpkgs 자체가 멈춘다거나 개발이 중단된다는 이야기는 어디에도 없습니다. 저장소는 그대로 돌아가고 있습니다.

위임이 이름만 남을 때 무엇이 무너지나

발표문에서 가장 일반화 가능한 부분은 위임에 대한 진단입니다.

거버넌스 구조를 설계할 때 흔히 이렇게 만듭니다. 최상위에 대의 기구를 두고, 그 아래에 영역별 팀을 두고, 헌법이나 규정에 "이 영역은 저 팀에 위임한다"고 적습니다. 문서상으로는 완결됩니다.

문제는 위임이 행위라는 점입니다. 문서에 적는다고 위임되는 것이 아니라, 상위 기구가 실제로 손을 떼야 위임됩니다. 발표문이 나열하는 실패 양상이 정확히 그 지점입니다.

  • 운영 위원회 구성원이 개인 의견을 말하는지 공동 입장을 대변하는지 불분명함
  • 사안이 원하는 결론이 이미 붙은 채로 전달됨
  • 위임 영역에 전적으로 속하는 사안을 관련 팀 없이 위원회가 직접 처리함
  • 우려 제기에 대한 응답이 불충분하고 지연됨

마지막 문장이 결정적입니다. "우리가 우리 권한 범위 안에서 자율적으로 결정할 수 있다고 신뢰받고 있는지에 대한 전반적인 불확실성."

권한 없는 책임이 이렇게 생깁니다. 위임된 팀은 결과에 대한 책임을 지지만 결정의 확정성은 갖지 못합니다. 이 상태는 사람을 빠르게 소진시킵니다. 사내 플랫폼 팀이나 아키텍처 리뷰 그룹을 운영해 본 적이 있다면 낯설지 않은 구조일 것입니다.

10개월간의 성과 목록이 곧 사라진 기능 목록이다

발표문의 성과 목록을 자랑으로 읽으면 절반만 읽은 것입니다. 다르게 읽으면 지금 주인이 없어진 기능의 목록입니다.

커미터 온보딩, 병합 봇을 통한 메인테이너 권한 위임, GitHub 조직 소유권 개혁, 보안 권고 분류, 자동화/AI 정책, 에스컬레이션된 분쟁 조정.

이 중 상당수는 "평소에는 아무도 필요를 느끼지 않다가 필요해지는 순간에는 즉시 필요한" 종류의 일입니다. 보안 권고 분류가 특히 그렇습니다. 커미터 온보딩이 멈추면 몇 달 뒤 처리량으로 나타나고, 분쟁 조정이 멈추면 갈등이 스레드 길이로 나타납니다. 즉시 장애가 나지 않기 때문에 위험이 조용히 누적됩니다.

발표문 자체도 이 점을 인정합니다. 코어 팀에 조정을 요청할 수 있다는 사실이 긴장을 완화하고 합의 가능한 결론으로 이끈 사례가 많았다고 씁니다. 그 통로가 지금은 없습니다.

사용자 입장에서 이것이 뜻하는 것

그렇다면 Nixpkgs를 쓰는 팀은 무엇을 해야 할까요. 과장도 축소도 없이 정리하면 이렇습니다.

지금 당장 바뀌는 것은 없습니다. 패키지는 계속 갱신되고 채널도 계속 나옵니다.

바뀐 것은 에스컬레이션 경로입니다. 이전에는 정책 수준의 사안(예를 들어 LLM이 생성한 기여를 어떻게 다룰 것인가, 조직 소유권을 누가 갖는가)에 대해 물어볼 곳이 있었습니다. 지금은 발표문 표현대로 운영 위원회가 "언제나처럼 최종 백스톱"으로 남아 있을 뿐입니다. 백스톱은 통로가 아닙니다.

그리고 발표문에 따르면 두 사람 모두 Nixpkgs 관여를 줄일 계획이며 운영 위원회에 출마할 의사가 없습니다. 즉 이 공백은 그 자리에 다른 사람이 들어오기 전까지 유지됩니다.

실무적으로는 이렇게 대응합니다. 정책 변화에 민감한 의존성이 있다면 채널 고정과 자체 오버레이 비중을 다시 점검하고, 보안 권고를 상류 조율에만 의존하지 말고 자체 취약점 스캔 경로를 확인하고, 마이그레이션 비용을 지금 계산해서 문서에 남겨 둡니다. 지금 옮기라는 뜻이 아니라 옮겨야 할 때의 비용을 알고 있으라는 뜻입니다.

의존성의 거버넌스를 실제로 측정하는 법

스타 수는 인기 지표이지 위험 지표가 아닙니다. 대신 셀 수 있는 것들이 있습니다. 아래 명령은 실제로 동작하는 형태이고, GitHub 검색 API는 인증 없이 쓰면 분당 요청 제한이 낮으니 토큰을 붙이는 편이 낫습니다.

# 최근 90일간 병합된 PR 수 — 처리량
OWNER_REPO="NixOS/nixpkgs"
SINCE="2026-05-11"
curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  "https://api.github.com/search/issues?q=repo:${OWNER_REPO}+is:pr+is:merged+merged:>=${SINCE}&per_page=1" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['total_count'])"

# 최근 100개 병합 PR을 실제로 병합한 사람의 분포 — 권한의 집중도
curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  "https://api.github.com/repos/${OWNER_REPO}/pulls?state=closed&per_page=100" \
  | python3 -c "
import sys, json, collections
prs = json.load(sys.stdin)
c = collections.Counter(p['merged_by']['login'] for p in prs if p.get('merged_by'))
for who, n in c.most_common(15):
    print(f'{n:4d}  {who}')
print('distinct mergers:', len(c))
"

두 번째 명령이 핵심입니다. 기여자는 많은데 병합자가 소수에 집중되어 있다면, 그 소수가 곧 버스 팩터입니다. 반대로 병합자가 넓게 퍼져 있다면 개인 이탈에 대한 내성이 높습니다.

숫자로 재지 못하는 것은 문서로 확인합니다. 의사결정 기구가 문서화되어 있는가, 위임 영역이 명시되어 있는가, 분쟁을 어디에 올리는지 적혀 있는가, 그리고 최근에 실제로 그 경로가 작동한 사례가 있는가. 마지막 항목이 가장 중요한데 자동화할 수 없습니다. 이슈 트래커와 포럼을 직접 읽어야 합니다.

소진은 성격이 아니라 프로세스의 산출물이다

마지막으로 발표문에서 개인적으로 가장 인상 깊었던 대목을 옮깁니다.

발표문은 커뮤니티에 거버넌스에 대한 전반적인 불신이 있다는 점을 인정하고, 그 불신이 대립적이고 제로섬적인 갈등 방식을 부추겼다고 씁니다. 그리고 이렇게 이어집니다. 그런 방식은 리더십 공백 상태나 무응답 거버넌스를 상대로는 효과가 있을지 몰라도, 선의로 참여하려는 리더십 팀을 상대로는 소진을 만들어 낸다는 것입니다.

그 결과 "듣지 않는 쪽"이 보상받고, 거버넌스에 참여할 시간과 의지가 있는 경험 많은 기여자 풀이 더 줄어들며, 교착과 이탈에 의한 의사결정이라는 역사적 현상이 고착될 위험이 있다고 진단합니다.

이 진단은 오픈소스에 한정되지 않습니다. 사내 아키텍처 리뷰, 코드 오너 제도, 플랫폼 팀에도 그대로 적용됩니다. 위임된 팀에 결정 권한이 실제로 없고, 갈등을 해소하는 정식 경로가 없으면, 갈등은 가장 지친 사람이 먼저 나가는 방식으로 해소됩니다. 그리고 그렇게 해소된 갈등은 기록에 남지 않기 때문에 다음에 또 같은 방식으로 해소됩니다.

버스 팩터를 낮추는 일은 문서를 더 쓰는 것으로만 되지 않습니다. 누가 무엇을 확정할 수 있는지를 명확히 하고, 그 확정을 실제로 존중하는 것이 절반입니다.

참고 자료

병합 PR 4,468건은 2026년 8월 9일에 GitHub 검색 API로 직접 조회한 값이며, 검색 API 결과는 시점에 따라 달라집니다.

현재 단락 (1/63)

2026년 8월 7일, NixOS Discourse에 [Nixpkgs 코어 팀이 해산한다는 글](https://discourse.nixos.org/t/the-nixpkgs-core...

작성 글자: 0자원문 글자: 4,805자작성 단락: 0/63