▲

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

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

제공되는 명령어

  • 로컬 파일
    • 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
▲
xguru 2시간전  [-]

관심받으면서 오해가 있는듯해서 FAQ를 따로 정리했네요
https://x.com/mitchellh/status/2020628046009831542

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

  • 한 프로젝트에서 신뢰받은 사용자가 다른 프로젝트에서도 자동으로 신뢰된다고 가정하는 건 위험하다고 생각함
    이런 구조는 공급망 공격에 악용될 수 있음. 공격자가 여러 프로젝트에서 ‘착한 기여자’로 신뢰를 쌓은 뒤, 목표 프로젝트로 접근할 수 있기 때문임
    이런 교차 신뢰가 자동화되면, 한 번이라도 신뢰받은 계정이 공격의 표적이 될 수 있음. 차라리 ‘신뢰 목록’보다 ‘불신 목록’으로 시작하는 게 더 안전하다고 봄

    • 설명을 보면, 이 시스템의 목적은 보안적 의미의 신뢰라기보다 AI 생성 저품질 기여물을 걸러내는 스팸 필터에 가까운 것 같음
    • 이런 우려는 과장된 면이 있음. Vouch는 단지 참여 권한을 제한하는 게이트일 뿐이고, 코드 병합 권한을 주는 건 아님. 이후에는 기존의 리뷰 절차가 그대로 유지됨. 결국 소음 최소화 레이어 정도로 보면 됨
    • 공격자가 장기간 착한 척하며 평판을 쌓는 건 이미 현실에서도 일어나는 일임. 결국 사람들은 그가 변했을 때 알아차림. 이건 xkcd 810 같은 상황임
    • 누군가 신뢰를 잃으면, 그를 신뢰하던 모든 프로젝트에서도 신뢰가 사라짐. 이건 스팸 필터 같은 개념이지, PGP 키 서명 수준의 신뢰가 아님. 국가급 공격자를 막기 위한 게 아니라, AI 스팸 PR을 막기 위한 장치임
    • 완벽한 시스템은 아니지만, “귀찮을 가치가 있는 개선” 이라 생각함. 진짜 기여자라면 약간의 추가 노력을 들일 가치가 있음. 나도 그 정도는 감수할 의향이 있음

  • PR 제출에 $1의 비용을 부과하면 좋겠다는 생각임.
    PR이 유효하면 유지보수가 환불해주는 방식.
    지금은 커뮤니케이션이 너무 쉬워져서 저품질 커뮤니케이션이 넘쳐남. 이런 건 단순히 가치가 없는 게 아니라, 시간을 갉아먹는 해악임

    • 이런 사고방식은 결국 크립토 세계의 스테이킹 개념으로 이어짐. 토큰을 잠그고, PR이 병합되면 돌려받는 구조임. 기술적으로는 우아하지만, 돈이 개입되면 제품 설계가 타락함. 절대 이렇게 하지 말아야 함
    • “내 댓글 읽고 싶으면 $1 내라”는 농담이지만, 아이디어의 본질을 잘 드러냄
    • 커뮤니케이션에 비용을 부과하면 부정적 효과도 있음. 적정 비용의 균형점이 중요함. 가까운 사람의 ‘저품질 대화’는 괜찮지만, 정치인들의 트위터 소통은 줄었으면 함
    • 이건 결국 비용의 외부화 문제임. 제조, 커뮤니케이션, 코드 생성 등 모든 영역에서 발생함. 이제는 개인 평판조차 거의 비용이 들지 않음
    • 나는 이런 구조라면 PR을 아예 안 낼 것 같음. 이미 많은 PR이 무응답인데, 돈까지 내야 한다면 그냥 포크에서 수정하겠음. 환불 유인이 없는 구조라면 더더욱 불공정함. 에스크로 서비스를 둔다 해도 복잡해짐. 단순히 버그를 고치고 싶을 뿐인데 이런 절차는 싫음

  • 새로운 기여자가 네트워크가 없으면 어떻게 진입 장벽을 뚫을 수 있을지 의문임.
    AI가 만든 잡음이 많다고 해도, 이건 해결책이 아님

    • 내 OSS 프로젝트에서는 PR보다 이슈나 토론으로 먼저 제안하는 걸 선호함. PR은 종종 프로젝트 방향성과 맞지 않아 거절하기 곤란한 상황을 만듦
    • 기여자와 화상 통화로 패치를 설명하게 하는 방법도 있음. 실제로 이런 방식으로 사기 지원자를 걸러낸 적 있음. 요즘 FOSS는 거의 사기 탐지 게임이 되어버림
    • 접근을 단계별로 제한하는 구조로 보임. 예를 들어 스테이징 환경에서 먼저 검증하고, 이후 프로덕션 접근을 허용하는 식. 이미 운영(ops) 세계에서는 흔한 방식임
    • Vouch 설정에 따라 다름. 일부는 완전히 닫을 수도 있고, 일부는 이슈·토론은 열어두고 PR만 제한할 수도 있음. 리눅스처럼 각 프로젝트의 관행에 맞게 접근하면 됨

  • “오픈소스는 신뢰하고 검증하는 시스템 위에서 작동한다”는 말에 동의하지 않음.
    이상적으로는 코드 자체로 평가할 수 있어야 함.
    나는 PR을 보면 몇 초 만에 병합 여부를 판단함. 어려운 건 거절 사유를 예의 있게 쓰는 일임.
    (참고: openpilot 저장소)

    • openpilot 코드를 최근에 살펴봤는데, msgq/cereal, Params, visionipc 등 구조가 흥미로움
    • 시간이 있을 때는 리뷰하고, 없을 때는 신뢰하는 식으로 돌아감

  • Vouch 프로젝트가 Bluesky처럼 폐쇄적 버블이 되는 걸 어떻게 막을지 궁금함.
    Bluesky는 선거 이후 점점 축소되고 있음. 이런 사회적 필터링이 새로운 기여를 막을 수도 있음

    • 선거 이후 감소한 건 맞지만, 그 전보다 여전히 사용자 수가 많음. 통계를 보면 스파이크 후 안정화 패턴임.
      게다가 Vouch의 목적은 애초에 진입 장벽을 높이는 것이라, 이런 문제를 걱정하지 않을 듯함
    • 프로젝트별로 독자적인 vouch 시스템을 둘 수 있음. 커뮤니티가 이슈나 PR로 반대 의견을 제시할 수도 있음
    • “Bluesky 같은 버블이 생기면 어쩌나?” → “그게 바로 의도일 수도 있음”이라는 시각도 있음
    • Bluesky에서 가장 많이 차단된 계정이 정부 공식 계정이라는 점이 흥미로움. 폐쇄적 커뮤니티의 단면을 보여줌

  • 이런 시스템은 드라마 없는 오픈소스 커뮤니티에서 절대 악용되지 않을 리 없다고 비꼼.
    혹시 블랙리스트 개발자 명단이라도 공유된 건지 궁금함

  • 신뢰 기반 시스템은 반드시 위험을 동반해야 작동한다고 생각함.
    내가 누군가를 보증했는데 그가 문제를 일으키면 내 평판도 떨어져야 함.
    반대로 근거 없이 비난했는데 그가 괜찮은 사람이라면 내 평판이 깎여야 함.
    그렇지 않으면 보증이 무책임하게 남용될 것임

    • 그래서 신중해야 함. 하지만 누군가를 보증해서 좋은 결과가 나면 나도 평판 상승을 얻을 수 있음. 인간 관계도 그런 식으로 작동함.
      이런 구조는 블록체인 기반 신뢰 그래프로 구현할 수도 있을 듯함
    • 회사에서 추천인을 세우는 것처럼, 함께 일하면 나도 이익을 얻기 때문에 보증하는 것임
    • 내가 보증한 사람이 좋은 기여를 하면 내 점수도 올라가는 구조면 동기부여가 될 것 같음
    • 하지만 이런 구조는 Epstein 같은 사례처럼, 연결이 많다는 이유로 잘못된 사람에게 면죄부를 줄 위험이 있음. 반대로 내성적인 유능한 사람은 배제될 수 있음
    • 이런 신뢰망은 그래프 탐색 문제로 볼 수 있음. 내가 신뢰하는 사람이 신뢰하는 사람의 관계를 통해 간접 신뢰도 계산할 수 있음

  • 이 시스템은 데이팅 앱과 비슷하게 느껴짐.
    필터링해야 할 의욕 과잉의 부적격자가 많고, 결국 유료 참여·위치 기반·신원 인증·사회적 점수화 같은 패턴이 생길 것 같음.
    요즘은 GitHub 명성을 얻으려는 사람들이 무의미한 기여 요청을 남발해서 피곤함

  • Git이 기본적으로 못 하는 기능만 남긴 미니멀 포지 구조를 상상해봄.
    핵심은 신원(Identity) , 서명된 주장(Attestation) , 정책(Policy) 임.
    Vouch는 이 중에서도 사람에 대한 서명을 다룸 — “이 사람은 신뢰할 만하다”는 서명이 “이 커밋은 테스트 통과했다”는 서명과 구조적으로 동일함.
    즉, 참여 자체를 제어하는 정책 레이어임.
    이런 기능은 GitHub 같은 폐쇄 플랫폼이 아니라 레포 내부 메타데이터로 존재해야 함.
    5년 뒤 이 개념이 어디까지 발전할지 궁금함

    • 이런 메타데이터를 .github/ 폴더처럼 표준화된 형태로 저장하면, 플랫폼 독립적 신뢰 모델이 가능함.
      LLM이 만든 코드가 늘어나는 시대에, 이런 평판 인프라는 인터넷의 필수 요소가 될 수 있음

  • 처음엔 괜찮아 보였지만, 결국 “신뢰받은 사람만 기여 가능” 한 구조로 귀결되는 것 같음

    • 혁신적이기보다는 잘 설계된 실행력이 중요하다는 점에서는 의미가 있음
    • 예전 Usenet의 killfile이나 스팸 RBL 리스트와 유사함
      (killfile 위키, DNS blocklist)
    • 대규모 프로젝트에는 이런 구조가 더 적합함. 저품질 PR을 기본적으로 차단하고, 핵심 유지보수자와의 신뢰를 쌓은 사람만 접근할 수 있게 함
답변달기