YouTube코드팩토리·2026년 8월 26일·0

슬랙을 오픈소스로 풀어버린 Buzz. AI와 휴먼의 협업 툴

Quick Summary

Buzz는 여러 로컬 구독형 AI와 사람을 하나의 공유 스레드에 연결하고, 서명된 기록과 백엔드 전환 기능으로 협업 맥락을 유지하는 오픈소스 Slack 대체 도구다.

영상 보기

클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.

원본 열기

🖼️ 인포그래픽

슬랙을 오픈소스로 풀어버린 Buzz. AI와 휴먼의 협업 툴 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

슬랙을 오픈소스로 풀어버린 Buzz. AI와 휴먼의 협업 툴의 핵심 내용을 4단계로 요약한 인포그래픽
슬랙을 오픈소스로 풀어버린 Buzz. AI와 휴먼의 협업 툴 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 결론

Buzz는 여러 로컬 구독형 AI와 사람을 하나의 공유 스레드에 연결하고, 서명된 기록과 백엔드 전환 기능으로 협업 맥락을 유지하는 오픈소스 Slack 대체 도구다.

📌 핵심 요점

  1. Buzz는 Codex, Claude Code, Grok 등 서로 다른 AI와 여러 사람을 하나의 화면과 스레드에서 관리하도록 설계됐다.
  2. 메시지·리액션·커밋을 각 참여자의 암호 키로 서명해, 릴레이 서버를 전적으로 신뢰하지 않아도 작성 주체와 기록의 무결성을 검증할 수 있다는 구조다.
  3. 릴레이는 메시지를 생성하지 않고 전달·보관하며, WSS 기반의 지속 연결을 통해 여러 사용자가 공유하는 커뮤니티와 작업 기록을 유지한다.
  4. 에이전트별 이름·AI 백엔드·시스템 프롬프트를 설정할 수 있고, 동일한 스레드의 맥락을 보존한 채 모델을 바꾸거나 결과를 비교할 수 있다.
  5. 채널, 다이렉트 메시지, 모바일 연결, 워크플로, SNS형 피드, Git 저장소까지 포함하지만 아직 리서치 프리뷰 단계이며 태그 누락과 작업 미실행 같은 버그도 관찰됐다.

🧩 배경과 문제 정의

Buzz가 해결하려는 문제는 Codex, Claude Code, Grok처럼 여러 AI를 동시에 사용할 때 작업 위치와 맥락이 분산되고, 사용량 제한이나 모델 교체 때 프롬프트로 작업 내용을 다시 전달해야 하는 불편이다.

기존 Slack형 서비스는 중앙 운영사가 메시지 작성 주체와 데이터의 신뢰성을 관리하지만, 셀프 호스팅 오픈소스에서는 서버 관리자가 데이터베이스를 바꿀 가능성을 고려해야 한다. Buzz는 참여자별 암호 키로 메시지와 작업 기록을 서명하고, 릴레이에는 봉인된 기록의 전달과 보관을 맡기는 방식으로 이 문제를 다루려 한다.

제품의 목표는 사람과 여러 AI가 같은 채널·스레드·프로젝트에서 일하면서 모델을 교체해도 맥락과 작업 이력을 유지하는 것이다. 영상은 아키텍처 설명부터 릴레이 배포, 에이전트 설정, 다중 에이전트 데모와 현재 버그까지 순서대로 보여준다.

🕒 시간순 섹션별 상세정리

1. Buzz 소개와 다중 AI 작업의 문제

  • 발표자는 Jack Dorsey가 만든 AI 에이전트용 오픈소스 Slack으로 Buzz를 소개하고, ‘Slack 킬러’라는 평가와 사용법 시연을 예고한다. [00:23]
  • 여러 AI에서 리팩터링·테스트·리서치를 병행하면 작업 위치를 잊거나 사용량 제한 때 맥락을 다시 정리해야 하며, 사람에게 동일한 스레드를 공유하기도 어렵다고 보여준다. [02:24]

2. 사람과 AI를 연결하는 서명 구조

  • Buzz는 여러 AI 에이전트와 사람을 하나의 스레드에서 관리해 컨텍스트 전환 없이 협업하도록 설계됐다고 보여준다. [02:27]
  • 중앙 서버를 신뢰하는 Slack과 달리 각 사람과 에이전트가 암호 키를 갖고 메시지·리액션·커밋을 서명하므로, 릴레이가 해킹돼도 개인 키 없이는 다른 주체를 사칭하기 어렵다고 주장한다. [04:46]

3. 릴레이와 기술 스택

  • 릴레이는 메시지를 만들지 않고 봉인된 데이터를 전달·보관하며, 24시간 연결을 유지하기 위해 WSS 기반 웹소켓을 사용한다. [05:30]
  • Rust 릴레이, ACP 기반 에이전트 연결, 해시 체인 감사 로그, PostgreSQL, Redis, MinIO, 내장 Git 서버로 구성된 멀티컨테이너 서비스라고 보여준다. [06:49]

4. 데스크톱 앱과 커뮤니티 연결

  • 데스크톱 앱은 사람과 AI가 함께 있는 Slack형 화면을 제공하고, 동일 스레드의 맥락을 유지한 채 Codex·Claude Code·Grok 등으로 백엔드를 바꿀 수 있다. [07:33]
  • 협업을 위해 상시 가동되는 별도 릴레이가 필요하며, 남는 컴퓨터나 원클릭 호스팅에 배포한 뒤 오너 공개키와 WSS 주소를 데스크톱 앱에 입력해 커뮤니티에 참여한다. [10:39]

5. 기본 에이전트와 역할 설정

  • 커뮤니티에 들어가면 기본 에이전트들이 메시지·이모지·스레드 답장을 주고받으며, 사람이 각 응답과 읽음 상태를 확인할 수 있다. [11:22]
  • 에이전트를 콘텐츠 리서처, 썸네일 생성기, 프로그래머로 바꾸고 각각 Grok, Codex, Claude Code와 역할별 인스트럭션을 지정한다. [12:24]

6. 로컬 런타임과 실험 기능

  • 설정 화면은 컴퓨터에 설치된 에이전트를 보여주며 다른 런타임도 추가할 수 있어, 사용자가 보유한 로컬 구동 모델과 구독 환경을 활용한다고 보여준다. [12:55]
  • 프로젝트 같은 실험 기능을 활성화할 수 있고, QR 코드로 모바일 앱을 페어링해 같은 커뮤니티에 접속할 수 있다. [13:18]

7. 다이렉트 메시지와 지속되는 맥락

  • 콘텐츠 리서처에게 유행 콘텐츠를 검색하도록 다이렉트 메시지를 보내면 읽음 표시, 실행 시간, 조사 상태와 스레드 답변이 표시된다. [14:39]
  • 서버가 유지되는 동안 스레드가 남기 때문에 에이전트의 AI 백엔드를 바꿔도 같은 맥락에서 테스트하거나 동일 워크플로의 결과를 비교할 수 있다고 강조한다. [15:02]

8. 다중 에이전트 채널과 프로젝트 저장소

  • 유튜브 팀 채널에 리서처·썸네일 생성기·프로그래머를 넣고, 뉴스 조사와 토픽 추천, 썸네일 제작, 랜딩 페이지 개발을 한 스레드에서 요청한다. [16:09]
  • 프로젝트 탭에는 Git 저장소형 화면이 생성되며, 참여 에이전트와 커밋을 서명된 기록으로 확인하고 리서치 전에도 개발 골격을 병렬로 만들 수 있다. [16:54]

9. 피드·인박스·워크플로와 초대

  • SNS나 방명록과 비슷한 피드에서 사람과 에이전트가 글과 댓글을 남길 수 있고, 인박스에서는 자신이 태그된 메시지를 모아 볼 수 있다. [17:24]
  • 반복 작업용 워크플로는 아직 복잡하다고 평가하며, 커뮤니티 URL을 공유해 다른 사람을 초대하거나 여러 서버와 커뮤니티를 동시에 운영할 수 있다고 보여준다. [18:26]

10. 데모 결과와 현재 버그

  • 리서처의 토픽 결과를 프로그래머가 기존 프로젝트에 반영하고, 프로젝트 화면에서는 실제 Git 저장소처럼 커밋과 서명 주체를 확인한다. [19:19]
  • 썸네일 생성기가 자동으로 반응하지 않는 문제가 발생했으며, 발표자는 태그 누락으로 추정하고 다시 직접 태그해 작업을 시작시킨다. [19:36]

11. Slack 대체 비전과 마무리

  • 발표자는 모든 기록의 보존과 손쉬운 AI 백엔드 전환이 필요한 사용자에게 Buzz가 유용하며, 프로젝트가 Slack의 완전한 대체제를 지향한다고 정리한다. [20:05]
  • 아직 리서치 프리뷰임을 강조한 뒤 제휴 호스팅 링크와 추가 할인 쿠폰을 다시 안내하고 영상을 마친다. [20:36]

🧾 결론

  • Buzz의 핵심 가치는 AI를 많이 연결하는 것보다 사람과 여러 AI가 동일한 작업 기록을 계속 공유하도록 만드는 데 있다.
  • 메시지 서명, 해시 체인 감사 로그, Git 커밋 기록은 셀프 호스팅 환경에서 기록의 작성 주체와 변경 여부를 확인하기 위한 기반으로 제시된다.
  • 로컬에 설치된 구독형 AI를 활용할 수 있어 API 연동 중심 플랫폼과 다른 사용 방식을 제공한다.
  • 다만 실제 데모에서 에이전트 호출이 이어지지 않는 문제가 나타났으므로 중요한 업무에 도입하기 전 제한된 파일럿 검증이 필요하다.

📈 투자·시사 포인트

  • AI 협업 도구의 경쟁 기준이 단일 모델의 성능에서 공유 맥락, 에이전트 전환, 인간 참여, 작업 이력 관리로 확장될 가능성을 보여준다.
  • 오픈소스 제품도 멀티컨테이너 운영의 복잡성을 줄이는 패키지형 호스팅과 원클릭 배포를 통해 수익화 접점을 만들 수 있다.
  • 서명된 메시지와 커밋 이력은 AI가 실제 업무 산출물에 관여할수록 중요해지는 작업 주체 확인과 변경 추적 수요에 대응할 수 있다.
  • 리서치 프리뷰 단계의 버그와 릴레이 운영 부담은 초기 도입 속도와 신뢰성에 영향을 줄 수 있는 핵심 변수다.

⚠️ 불확실하거나 확인이 필요한 부분

  • ‘Slack 킬러’, ‘지금까지 Buzz밖에 없다’, ‘관리자도 기록을 고칠 수 없다’는 설명은 발표자의 평가와 시연에 기반하며 별도의 비교 검증이나 보안 감사 결과는 제시되지 않았다.
  • 릴레이 해킹 시에도 개인 키 없이는 다른 주체를 사칭할 수 있다는 설명이 실제 구현 전체와 운영 환경에서 어느 범위까지 성립하는지는 추가 확인이 필요하다.
  • 영상에서 제품명, 웹 주소, 일부 기술 용어가 음성 인식상 불명확하게 기록돼 있으므로 공식 저장소와 문서에서 정확한 명칭을 대조해야 한다.
  • 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
  • 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
  • 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

  • 공식 저장소에서 라이선스, 최신 릴리스, 지원 운영체제, 리서치 프리뷰 범위와 알려진 문제를 확인한다.
  • 개인 키를 안전하게 보관하고 분실·유출·교체 시의 복구 및 폐기 절차를 확인한다.
  • 별도 릴레이에 테스트 커뮤니티를 만들고 사람과 두 개 이상의 AI가 동일 스레드의 맥락을 실제로 이어받는지 검증한다.
  • 에이전트 간 태그, 순차 의존 작업, 실패 후 재호출, 모델 교체 후 맥락 유지 여부를 작은 워크플로로 반복 시험한다.

❓ 열린 질문

  • 개인 키를 분실하거나 유출했을 때 기존 기록의 신뢰 관계와 커뮤니티 권한은 어떻게 복구·교체되는가?
  • 릴레이가 장시간 중단되거나 데이터가 손상됐을 때 스레드, 감사 로그, Git 저장소를 어떤 방식으로 복구하는가?
  • 에이전트 간 작업 인계는 명시적 태그에 얼마나 의존하며, 누락된 후속 호출을 자동으로 감지하거나 재실행할 수 있는가?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.