# Vouch - 오픈소스 컨트리뷰터 신뢰 관리 시스템

> Clean Markdown view of GeekNews topic #26524. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26524](https://news.hada.io/topic?id=26524)
- GeekNews Markdown: [https://news.hada.io/topic/26524.md](https://news.hada.io/topic/26524.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-02-09T09:51:01+09:00
- Updated: 2026-02-09T09:51:01+09:00
- Original source: [github.com/mitchellh](https://github.com/mitchellh/vouch)
- Points: 9
- Comments: 3

## Summary

AI 도구 확산으로 기여 장벽이 낮아지면서, 오픈소스의 **암묵적 신뢰 모델**이 흔들리고 있습니다. Vouch는 기여 전에 신뢰를 명시적으로 보증하도록 설계된 시스템으로, 프로젝트별 정책에 따라 사용자를 **vouch**하거나 **denounce**할 수 있게 합니다. 모든 신뢰 데이터는 저장소 내 평문 파일로 버전 관리되어 투명성을 유지하며, 장기적으로는 프로젝트 간 **신뢰망(Web of Trust)** 형성을 목표로 합니다. GitHub Actions와 연동해 `lgtm`, `denounce` 같은 키워드로 간단히 관리할 수 있습니다.

## Topic Body

- 오픈소스는 전통적으로 **trust and verify** 모델 위에서 작동해 왔음  
- AI 도구 확산으로 **기여 진입 장벽이 사실상 사라져**, 기존 암묵적 신뢰 모델이 더 이상 작동하지 않음  
- **기여 전에 신뢰를 명시적으로 보증(vouch)** 해야만 참여할 수 있도록 설계된 오픈소스 신뢰 관리 시스템  
- 신뢰받은 기여자는 다른 사용자를 **vouch**할 수 있고, 악의적 행위자는 **denounce(비난/고발하다)** 로 명시적으로 차단 가능  
  - denounce는 공개 기록으로 유지되어 **다른 프로젝트가 참고 가능**  
  - 누가, 어떤 기준으로 vouch/denounce할지는 **각 프로젝트 자율 결정**  
  - 시스템은 특정 가치관을 강제하지 않으며, **정책 결정은 커뮤니티 몫**  
- 모든 신뢰 데이터는 저장소 내 **단일 평문 파일(VOUCHED)** 로 코드와 함께 **버전 관리**되며 투명성과 이식성 보장  
- 장기적으로 프로젝트 간 **신뢰망(Web of Trust)** 형성을 통해 신뢰 정보를 공유하는 구조  
  - 상위 프로젝트의 판단을 그대로 수용할지 여부는 **하위 프로젝트가 선택**  
  - 무분별한 vouch/denounce를 하는 프로젝트는 **신뢰 네트워크에서 자연스럽게 배제 가능**  
- **GitHub Actions**로 **간단히 연동 가능**하며, 이슈나 PR 댓글에서 `lgtm`, `denounce` 같은 키워드로 관리 가능  
- Ghostty는 기여 모델을 **vouch 기반 시스템으로 전환**  
- [Pi](https://github.com/badlogic/pi-mono) 프로젝트에서 영감을 받아 구현, 현재는 **실험적 단계**  
  
  
### 제공되는 명령어  
- 로컬 파일   
  - `vouch.nu check <user>`: 사용자 vouch/denounce 상태 확인  
  - `vouch.nu add <user>`: 사용자 vouch  
  - `vouch.nu denounce <user>`: 사용자 denounce  
- 깃헙 연동  
  - `vouch.nu gh-check-pr <pr>`: PR 작성자 상태 확인 및 자동 처리  
  - `vouch.nu gh-manage-by-issue <issue> <comment>`: 이슈 댓글 기반으로 vouch/denounce

## Comments



### Comment 50887

- Author: kuthia
- Created: 2026-02-09T14:16:32+09:00
- Points: 1

시스템 자체가 권위를 얻어야 수용될 것이라는 생각이 드네요

### Comment 50863

- Author: xguru
- Created: 2026-02-09T10:15:53+09:00
- Points: 1

관심받으면서 오해가 있는듯해서 FAQ를 따로 정리했네요   
https://x.com/mitchellh/status/2020628046009831542  
  
- **초보 및 신규 참여자는 참여하기 어렵다**  
  - Vouch를 받는 게 어려울 이유가 전혀 없음  
  - Vouch의 주된 목적은 노력 없이 무턱대고 참여하는 것을 막는 것  
  - 제 프로젝트(이 프로젝트 포함)에서는 이슈에 자기소개를 하고 어떻게 기여하고 싶은지 간단히 설명하면 Vouch를 받을 수 있음  
  - 간단히 말해서, 일반적인 사회생활처럼 자기소개를 하면 Vouch를 받을 수 있음  
  - 하지만 그룹 내에서 권한을 남용하면 제재를 받게 됨  
- **소셜 엔지니어링에 취약하다**  
  - Vouch를 받은 사용자는 프로젝트에 참여할 수 있는 권한만 얻게 됨  
  - 풀 리퀘스트 병합, 코드 푸시, 릴리스 등의 권한을 얻지 못함   
  - 이러한 모든 작업은 기존 검토 및 시스템 제어를 통해 제한됨  
  - 또한 관리자/협업 구성원만 사용자를 추천할 수 있음   
  - 따라서 문제가 있는 사용자가 추천을 받았다면 다른 사용자를 추천할 수 없음   
- **Denouncing에 대한 이의제기 절차가 없습니다.**   
  - 이의 제기 절차는 하위 프로젝트에 따라 다름   
  - 제 프로젝트의 경우, 디스코드, 이메일 등 어떤 방식으로든 저희에게 연락하여 사람처럼 이야기하고, 실수를 인정하면 다시 기회를 드림. 어렵지 않음   
- 이 프로젝트의 핵심은 AI가 API 호출을 통해 사람들에게 정보를 제공함으로써 기존의 자연적인 장벽을 최소화하는 것  
- 인간 중심의 커뮤니티 프로젝트에서는 경계선에서만 인간적인 상호 작용이 필요함

### Comment 50857

- Author: neo
- Created: 2026-02-09T09:52:02+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46930961)   
- 한 프로젝트에서 **신뢰받은 사용자**가 다른 프로젝트에서도 자동으로 신뢰된다고 가정하는 건 위험하다고 생각함  
  이런 구조는 **공급망 공격**에 악용될 수 있음. 공격자가 여러 프로젝트에서 ‘착한 기여자’로 신뢰를 쌓은 뒤, 목표 프로젝트로 접근할 수 있기 때문임  
  이런 교차 신뢰가 자동화되면, 한 번이라도 신뢰받은 계정이 공격의 표적이 될 수 있음. 차라리 ‘신뢰 목록’보다 ‘불신 목록’으로 시작하는 게 더 안전하다고 봄  
  - 설명을 보면, 이 시스템의 목적은 보안적 의미의 신뢰라기보다 **AI 생성 저품질 기여물**을 걸러내는 **스팸 필터**에 가까운 것 같음  
  - 이런 우려는 과장된 면이 있음. Vouch는 단지 **참여 권한을 제한하는 게이트**일 뿐이고, 코드 병합 권한을 주는 건 아님. 이후에는 기존의 리뷰 절차가 그대로 유지됨. 결국 **소음 최소화 레이어** 정도로 보면 됨  
  - 공격자가 장기간 착한 척하며 평판을 쌓는 건 이미 현실에서도 일어나는 일임. 결국 사람들은 그가 변했을 때 알아차림. 이건 [xkcd 810](https://xkcd.com/810/) 같은 상황임  
  - 누군가 신뢰를 잃으면, 그를 신뢰하던 모든 프로젝트에서도 신뢰가 사라짐. 이건 **스팸 필터** 같은 개념이지, PGP 키 서명 수준의 신뢰가 아님. 국가급 공격자를 막기 위한 게 아니라, **AI 스팸 PR**을 막기 위한 장치임  
  - 완벽한 시스템은 아니지만, **“귀찮을 가치가 있는 개선”** 이라 생각함. 진짜 기여자라면 약간의 추가 노력을 들일 가치가 있음. 나도 그 정도는 감수할 의향이 있음  
  
- PR 제출에 **$1의 비용**을 부과하면 좋겠다는 생각임.  
  PR이 유효하면 유지보수가 환불해주는 방식.  
  지금은 커뮤니케이션이 너무 쉬워져서 **저품질 커뮤니케이션**이 넘쳐남. 이런 건 단순히 가치가 없는 게 아니라, **시간을 갉아먹는 해악**임  
  - 이런 사고방식은 결국 **크립토 세계의 스테이킹** 개념으로 이어짐. 토큰을 잠그고, PR이 병합되면 돌려받는 구조임. 기술적으로는 우아하지만, **돈이 개입되면 제품 설계가 타락**함. 절대 이렇게 하지 말아야 함  
  - “내 댓글 읽고 싶으면 $1 내라”는 농담이지만, 아이디어의 본질을 잘 드러냄  
  - 커뮤니케이션에 비용을 부과하면 부정적 효과도 있음. **적정 비용의 균형점**이 중요함. 가까운 사람의 ‘저품질 대화’는 괜찮지만, 정치인들의 트위터 소통은 줄었으면 함  
  - 이건 결국 **비용의 외부화** 문제임. 제조, 커뮤니케이션, 코드 생성 등 모든 영역에서 발생함. 이제는 개인 평판조차 거의 비용이 들지 않음  
  - 나는 이런 구조라면 PR을 아예 안 낼 것 같음. 이미 많은 PR이 무응답인데, 돈까지 내야 한다면 그냥 **포크에서 수정**하겠음. 환불 유인이 없는 구조라면 더더욱 불공정함. **에스크로 서비스**를 둔다 해도 복잡해짐. 단순히 버그를 고치고 싶을 뿐인데 이런 절차는 싫음  
  
- 새로운 기여자가 네트워크가 없으면 어떻게 **진입 장벽을 뚫을 수 있을지** 의문임.  
  AI가 만든 잡음이 많다고 해도, 이건 해결책이 아님  
  - 내 OSS 프로젝트에서는 PR보다 **이슈나 토론으로 먼저 제안**하는 걸 선호함. PR은 종종 프로젝트 방향성과 맞지 않아 거절하기 곤란한 상황을 만듦  
  - 기여자와 **화상 통화로 패치를 설명**하게 하는 방법도 있음. 실제로 이런 방식으로 **사기 지원자**를 걸러낸 적 있음. 요즘 FOSS는 거의 **사기 탐지 게임**이 되어버림  
  - 접근을 단계별로 제한하는 구조로 보임. 예를 들어 **스테이징 환경에서 먼저 검증**하고, 이후 프로덕션 접근을 허용하는 식. 이미 **운영(ops)** 세계에서는 흔한 방식임  
  - Vouch 설정에 따라 다름. 일부는 완전히 닫을 수도 있고, 일부는 이슈·토론은 열어두고 PR만 제한할 수도 있음. **리눅스처럼 각 프로젝트의 관행에 맞게** 접근하면 됨  
  
- “오픈소스는 **신뢰하고 검증하는 시스템** 위에서 작동한다”는 말에 동의하지 않음.  
  이상적으로는 코드 자체로 평가할 수 있어야 함.  
  나는 PR을 보면 몇 초 만에 병합 여부를 판단함. 어려운 건 **거절 사유를 예의 있게 쓰는 일**임.  
  (참고: [openpilot 저장소](https://github.com/commaai/openpilot))  
  - openpilot 코드를 최근에 살펴봤는데, **msgq/cereal, Params, visionipc** 등 구조가 흥미로움  
  - 시간이 있을 때는 리뷰하고, 없을 때는 신뢰하는 식으로 돌아감  
  
- Vouch 프로젝트가 **Bluesky처럼 폐쇄적 버블**이 되는 걸 어떻게 막을지 궁금함.  
  Bluesky는 선거 이후 점점 축소되고 있음. 이런 **사회적 필터링**이 새로운 기여를 막을 수도 있음  
  - 선거 이후 감소한 건 맞지만, 그 전보다 여전히 사용자 수가 많음. [통계](https://bsky.jazco.dev/stats)를 보면 **스파이크 후 안정화** 패턴임.  
    게다가 Vouch의 목적은 애초에 **진입 장벽을 높이는 것**이라, 이런 문제를 걱정하지 않을 듯함  
  - 프로젝트별로 **독자적인 vouch 시스템**을 둘 수 있음. 커뮤니티가 이슈나 PR로 반대 의견을 제시할 수도 있음  
  - “Bluesky 같은 버블이 생기면 어쩌나?” → “그게 바로 의도일 수도 있음”이라는 시각도 있음  
  - Bluesky에서 가장 많이 차단된 계정이 **정부 공식 계정**이라는 점이 흥미로움. 폐쇄적 커뮤니티의 단면을 보여줌  
  
- 이런 시스템은 **드라마 없는 오픈소스 커뮤니티**에서 절대 악용되지 않을 리 없다고 비꼼.  
  혹시 **블랙리스트 개발자 명단**이라도 공유된 건지 궁금함  
  
- **신뢰 기반 시스템**은 반드시 **위험을 동반해야** 작동한다고 생각함.  
  내가 누군가를 보증했는데 그가 문제를 일으키면 내 평판도 떨어져야 함.  
  반대로 근거 없이 비난했는데 그가 괜찮은 사람이라면 내 평판이 깎여야 함.  
  그렇지 않으면 **보증이 무책임하게 남용**될 것임  
  - 그래서 신중해야 함. 하지만 누군가를 보증해서 좋은 결과가 나면 **나도 평판 상승**을 얻을 수 있음. 인간 관계도 그런 식으로 작동함.  
    이런 구조는 **블록체인 기반 신뢰 그래프**로 구현할 수도 있을 듯함  
  - 회사에서 추천인을 세우는 것처럼, **함께 일하면 나도 이익을 얻기 때문에** 보증하는 것임  
  - 내가 보증한 사람이 좋은 기여를 하면 **내 점수도 올라가는 구조**면 동기부여가 될 것 같음  
  - 하지만 이런 구조는 **Epstein 같은 사례**처럼, 연결이 많다는 이유로 잘못된 사람에게 면죄부를 줄 위험이 있음. 반대로 **내성적인 유능한 사람**은 배제될 수 있음  
  - 이런 신뢰망은 **그래프 탐색 문제**로 볼 수 있음. 내가 신뢰하는 사람이 신뢰하는 사람의 관계를 통해 **간접 신뢰도 계산**할 수 있음  
  
- 이 시스템은 **데이팅 앱**과 비슷하게 느껴짐.  
  필터링해야 할 **의욕 과잉의 부적격자**가 많고, 결국 **유료 참여·위치 기반·신원 인증·사회적 점수화** 같은 패턴이 생길 것 같음.  
  요즘은 GitHub 명성을 얻으려는 사람들이 **무의미한 기여 요청**을 남발해서 피곤함  
  
- Git이 기본적으로 못 하는 기능만 남긴 **미니멀 포지 구조**를 상상해봄.  
  핵심은 **신원(Identity)** , **서명된 주장(Attestation)** , **정책(Policy)** 임.  
  Vouch는 이 중에서도 사람에 대한 서명을 다룸 — “이 사람은 신뢰할 만하다”는 서명이 “이 커밋은 테스트 통과했다”는 서명과 구조적으로 동일함.  
  즉, **참여 자체를 제어하는 정책 레이어**임.  
  이런 기능은 GitHub 같은 폐쇄 플랫폼이 아니라 **레포 내부 메타데이터**로 존재해야 함.  
  5년 뒤 이 개념이 어디까지 발전할지 궁금함  
  - 이런 메타데이터를 **.github/** 폴더처럼 표준화된 형태로 저장하면, **플랫폼 독립적 신뢰 모델**이 가능함.  
    LLM이 만든 코드가 늘어나는 시대에, 이런 **평판 인프라**는 인터넷의 필수 요소가 될 수 있음  
  
- 처음엔 괜찮아 보였지만, 결국 **“신뢰받은 사람만 기여 가능”** 한 구조로 귀결되는 것 같음  
  - 혁신적이기보다는 **잘 설계된 실행력**이 중요하다는 점에서는 의미가 있음  
  - 예전 **Usenet의 killfile**이나 **스팸 RBL 리스트**와 유사함  
    ([killfile 위키](https://en.wikipedia.org/wiki/Kill_file), [DNS blocklist](https://en.wikipedia.org/wiki/Domain_Name_System_blocklist))  
  - 대규모 프로젝트에는 이런 구조가 더 적합함. **저품질 PR을 기본적으로 차단**하고, 핵심 유지보수자와의 신뢰를 쌓은 사람만 접근할 수 있게 함