슬랙을 오픈소스로 풀어버린 Buzz. AI와 휴먼의 협업 툴
📺 원본 영상: 슬랙을 오픈소스로 풀어버린 Buzz. AI와 휴먼의 협업 툴
🎙️ 채널: 코드팩토리
📅 정리 일자: 2026-08-26
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환한 STT 자료를 바탕으로 정리한 것이다. 화면에 표시된 코드, 설정 화면, 아키텍처 다이어그램 등은 포함되지 않을 수 있으며, 제품의 최신 상태와 세부 사양은 원본 영상과 공식 자료를 함께 확인할 필요가 있다.
개요
Buzz는 Slack과 유사한 채널 및 스레드형 인터페이스에서 사람과 여러 AI 에이전트가 함께 작업하도록 만든 오픈소스 협업 도구다. 영상은 Codex, Claude Code, Goose처럼 서로 다른 AI 런타임을 하나의 워크스페이스에 연결하고, 대화 맥락과 작업 기록을 참여자 모두가 공유할 수 있다는 점을 핵심 가치로 제시한다.
Buzz가 해결하려는 문제는 단순히 AI 채팅창을 한곳에 모으는 데 그치지 않는다. 여러 AI를 오가면서 발생하는 Context Switching(컨텍스트 전환), 작업 인계 과정의 정보 손실, 사람과 AI 사이의 진행 상황 불일치까지 하나의 공유 스레드로 통합하려는 시도다. 여기에 암호학적 서명, Relay 서버, 감사 로그, Git 저장소를 결합함으로써 대화와 코드 변경의 출처까지 추적할 수 있는 협업 환경을 지향한다.
여러 AI를 사용할수록 커지는 협업 비용
영상이 먼저 짚는 문제는 AI 모델의 성능이 아니라 작업 맥락의 파편화다. 예를 들어 Codex에서는 리팩터링을 진행하고, Claude Code에는 테스트 작성을 맡기며, Goose에는 콘텐츠 조사를 요청할 수 있다. 각 도구는 맡은 역할을 수행하지만 대화 기록과 작업 상태가 서로 다른 세션에 갇히기 때문에, 사용자는 어느 AI가 무엇을 하고 있었는지 직접 기억하고 관리해야 한다.
한 서비스의 사용량 한도에 도달하면 문제는 더욱 복잡해진다. 기존 작업을 요약해 달라고 요청한 뒤 그 결과를 다른 AI에 전달해야 하며, 이 과정에서 세부 요구 사항이나 판단 근거가 빠질 수 있다. 요약 프롬프트는 원본 대화와 동일한 맥락이 아니므로, 새 AI가 이미 검토한 대안을 다시 탐색하거나 앞선 결정과 충돌하는 답을 내놓을 가능성도 생긴다.
팀 작업에서는 이러한 문제가 사람에게까지 확장된다. AI와 사용자가 어떤 판단을 내렸는지 동료가 이해하려면 별도의 문서나 메시지로 다시 정리해야 하고, 그 정리 역시 실제 작업 기록과 점차 어긋날 수 있다. Buzz는 사람과 AI 에이전트를 동일한 채널과 스레드에 참여시켜, 작업 과정 자체를 공동의 기록으로 남기는 방식으로 이 문제를 풀려고 한다.
AI 시대의 Slack을 지향하는 인터페이스
Buzz의 화면은 채널, Direct Message(다이렉트 메시지), 스레드, 반응 이모지 등 익숙한 협업 도구의 문법을 사용한다. 다만 대화 상대가 사람으로 제한되지 않으며, AI 에이전트 역시 독립된 구성원처럼 메시지를 읽고 반응하며 작업 결과를 게시한다. 사용자는 특정 에이전트와 일대일로 대화하거나, 여러 에이전트와 사람을 하나의 채널에 모아 공동 작업을 진행할 수 있다.
중요한 차이는 에이전트의 정체성과 그 뒤에서 실행되는 AI 백엔드가 분리돼 있다는 점이다. 동일한 역할의 에이전트를 Codex에서 Claude Code로, 다시 다른 런타임으로 전환하더라도 기존 스레드의 맥락은 워크스페이스에 남는다. 따라서 사용자는 같은 요청과 대화 기록을 유지한 채 모델별 결과를 비교하거나, 특정 모델의 사용량이 소진됐을 때 다른 모델로 작업을 이어갈 수 있다.
이 구조는 개인 사용자에게도 의미가 있다. 여러 AI 서비스를 구독하는 사람이 각 앱과 터미널을 오가는 대신, 역할별 에이전트를 구성하고 하나의 인터페이스에서 관리할 수 있기 때문이다. 팀 환경에서는 여기에 사람의 참여가 더해지면서 Buzz가 단순한 멀티 모델 클라이언트를 넘어 공동 작업 공간으로 확장된다.
💡 [영상 참조] 강연자는 Buzz의 Slack형 인터페이스에서 사람과 AI가 함께 표시되고, 대화 기록이 스레드에 남는 모습을 시연한다.
📺 원본 영상에서 실제 화면을 확인할 수 있다.
서버의 신뢰를 서명의 신뢰로 바꾸는 구조
일반적인 중앙형 협업 서비스에서는 서버가 메시지 작성자의 신원을 보증한다. 특정 사용자가 보낸 메시지라는 사실은 서비스 운영자가 관리하는 데이터베이스와 인증 체계를 신뢰함으로써 성립한다. 운영 주체가 명확한 상용 서비스에서는 사용자가 이러한 중앙 신뢰 모델을 자연스럽게 받아들이지만, 누구나 서버를 운영할 수 있는 Self-hosting(셀프 호스팅) 환경에서는 서버 관리자가 데이터를 직접 변경할 수 있다는 문제가 생긴다.
영상에 따르면 Buzz는 사람과 에이전트가 각각 암호 키를 가지고, 메시지와 반응 및 Git 이벤트에 서명하도록 설계돼 있다. 따라서 기록의 진위를 판단할 때 서버가 주장하는 작성자 정보에만 의존하지 않고, 해당 주체의 키로 생성된 서명을 검증할 수 있다. Relay가 침해되더라도 개인 키가 노출되지 않았다면 공격자가 다른 사람이나 에이전트의 신원을 가장해 유효한 서명을 만드는 것은 어렵다는 설명이다.
다만 서명이 모든 보안 문제를 자동으로 해결하는 것은 아니다. 개인 키가 유출되면 공격자는 정상적인 서명처럼 보이는 기록을 생성할 수 있고, 악성 Relay가 데이터를 삭제하거나 전달을 거부하는 가용성 문제도 별도로 남는다. 그러므로 이 구조의 핵심은 서버를 완전히 불필요하게 만드는 것이 아니라, 서버가 임의로 작성자를 가장하기 어렵도록 신뢰의 기준을 서버 권한에서 암호학적 키로 옮기는 데 있다.
💡 [영상 참조] 강연자는 중앙 서버를 신뢰하는 Slack식 모델과 각 기록에 암호학적 서명을 남기는 Buzz의 모델을 비교한다.
📺 원본 영상에서 관련 아키텍처 설명을 확인할 수 있다.
Relay는 기록의 작성자가 아니라 운반자다
Buzz의 서명된 기록은 Relay라고 불리는 서버를 통해 보관되고 전달된다. 영상은 Relay가 메시지를 직접 만들어 내는 주체가 아니라, 이미 서명된 데이터를 받아 저장한 뒤 다른 참여자에게 전송하는 중계자라고 설명한다. 강연자는 이를 데이터가 봉인된 채 들어오고 봉인된 채 나가는 구조에 비유한다.
Relay는 여러 사용자가 지속적으로 연결되어야 하므로 개인용 컴퓨터에서 잠깐 실행하는 것만으로는 협업 서버의 역할을 안정적으로 수행하기 어렵다. 컴퓨터가 꺼지면 다른 참여자가 접속할 수 없고 실시간 메시지 전달도 중단되기 때문이다. 영상에서는 지속적인 실시간 연결에 WSS(WebSocket Secure)를 사용한다고 설명하며, 24시간 접근할 수 있는 별도 서버에 Relay를 배치하는 방식을 권한다.
이 구조는 완전히 탈중앙화된 Peer-to-Peer(피어 투 피어) 통신이라기보다는, 중앙 중계 서버를 사용하되 기록의 진위를 서버만으로 결정하지 않는 절충형 설계로 이해할 수 있다. Relay는 연결성과 저장을 책임지고, 서명은 누가 기록을 만들었는지 검증하는 역할을 맡는다. 이처럼 책임을 분리하면 사용자가 자체 서버를 운영하면서도 서버 관리자에게 모든 신뢰를 집중시키지 않을 수 있다.
Buzz를 구성하는 기술 스택
영상에서 소개된 Relay 서버는 Rust로 작성됐으며, 워크스페이스의 Single Source of Truth(단일 진실 공급원) 역할을 한다. AI 에이전트는 ACP(Agent Client Protocol)를 통해 별도 프로세스로 실행되고 Buzz에 연결된다. Buzz의 buzz-acp는 Goose, Codex 및 Claude Code 같은 ACP 기반 에이전트를 워크스페이스에 연결하는 역할을 한다.
| 구성 요소 | 영상에서 설명한 역할 |
|---|---|
| Rust 기반 Relay | 서명된 메시지와 작업 기록의 중계 및 워크스페이스 상태 관리 |
| WSS | 클라이언트와 Relay 사이의 지속적인 실시간 연결 |
| PostgreSQL | 메시지와 워크스페이스 관련 데이터 저장 |
| Redis | 실시간 기능과 상태 처리를 지원 |
| MinIO | S3 호환 방식의 파일 저장소 역할 |
| Hash Chain | 감사 로그 변경 여부를 감지하기 위한 무결성 구조 |
| Git Server | 외부 GitHub 없이 프로젝트 저장소와 Git 관련 이벤트 관리 |
| ACP | 로컬에서 실행되는 AI 에이전트 프로세스의 연결 방식 |
감사 로그는 Hash Chain(해시 체인)으로 연결되어, 과거 기록을 변경하면 이후 체인의 무결성이 깨지도록 설계됐다고 소개된다. 이는 관리자가 데이터를 기술적으로 전혀 삭제할 수 없다는 의미라기보다는, 기록을 조작했을 때 그 흔적을 검증 가능한 형태로 드러내는 장치로 해석하는 편이 정확하다. 데이터베이스 관리 권한과 암호학적 무결성은 서로 다른 문제이기 때문이다.
MinIO, PostgreSQL, Redis까지 포함하는 구성은 Buzz가 단순한 데스크톱 채팅 앱이 아니라 여러 서버 구성 요소에 의존하는 서비스임을 보여준다. 기능을 모두 자체 운영하려면 컨테이너 구성, 저장소 백업, TLS 인증서, 네트워크 접근 제어와 버전 업그레이드까지 관리해야 한다. 원클릭 배포가 진입 장벽을 낮출 수는 있지만, 운영 책임 자체를 없애 주는 것은 아니다.
설치와 커뮤니티 연결 과정
영상에서 Buzz 데스크톱 앱은 공식 웹사이트의 다운로드 메뉴를 통해 설치한다. 초기 설정에서는 Community(커뮤니티)를 선택하거나 새 Relay에 연결하는데, 여기서 커뮤니티는 여러 사용자가 공유하는 하나의 워크스페이스이자 Relay 접속 단위로 볼 수 있다. 로컬에 Relay를 설치하는 것도 가능하지만, 상시 접속과 외부 협업이 필요하다면 계속 실행되는 서버가 더 적합하다는 것이 강연자의 설명이다.
영상은 별도 호스팅 서비스의 원클릭 설치 절차도 시연한다. 배포 과정에서는 Buzz 클라이언트에 표시되는 Relay Owner Public Key를 서버 설정에 입력하고, 설치가 끝난 뒤 제공되는 서버 주소를 데스크톱 앱에 등록한다. STT에서 이 값은 여러 차례 “PUP 키”로 인식됐지만, 문맥상 “PUB 키”, 즉 Public Key(공개 키)를 의미한다.
서버 주소는 일반 HTTP 주소를 그대로 사용하는 것이 아니라 wss 스킴을 적용해 보안 WebSocket 연결 주소로 입력한다. 연결을 완료하면 사용자는 커뮤니티 이름을 설정하고, 기본으로 생성된 에이전트와 환영 메시지를 확인할 수 있다. 실제 주소 형식과 키 관리 절차는 버전에 따라 달라질 수 있으므로, 영상의 화면과 최신 공식 설치 문서를 함께 확인하는 것이 안전하다.
💡 [영상 참조] 강연자는 호스팅된 Relay의 공개 키와 접속 주소를 Buzz 데스크톱 앱에 등록하고 WSS로 커뮤니티에 접속하는 과정을 보여준다.
📺 원본 영상에서 입력 필드와 설정 순서를 확인할 수 있다.
영상 중간에는 특정 호스팅 서비스와 할인 쿠폰에 관한 제휴성 안내가 포함돼 있다. 강연자는 월 비용, 추가 할인율, 권장 서버 사양으로 8GB RAM과 2개의 vCPU가 제공되는 KVM 2 상품을 언급한다. 이러한 가격과 상품 사양은 변경될 수 있고 실제 필요한 자원도 동시 사용자 수와 실행하는 에이전트에 따라 달라지므로, 고정된 기술 요구 사항으로 받아들이기보다는 영상 촬영 시점의 배포 예시로 보는 것이 적절하다.
역할별 에이전트와 로컬 구독 모델의 결합
Buzz에서는 기본 에이전트의 이름과 역할을 바꾸고, 각 에이전트가 사용할 AI 런타임을 선택할 수 있다. 영상은 콘텐츠 조사 에이전트, 썸네일 생성 에이전트, 프로그래머라는 역할을 만든 뒤 서로 다른 AI 백엔드를 연결하는 과정을 보여준다. Agent Instruction은 각 에이전트의 행동 원칙을 지정하는 System Prompt(시스템 프롬프트)와 유사한 설정으로 설명된다.
강연자가 강조하는 특징은 별도의 API 호출만을 전제로 하지 않고, 사용자의 컴퓨터에 설치되어 인증된 구독형 AI 도구를 활용할 수 있다는 점이다. 사용자는 설정 화면의 Agent 메뉴에서 감지된 런타임을 확인하고, Add Runtime 기능을 통해 추가 에이전트를 등록할 수 있다. 다만 구독 계정의 로컬 사용 허용 범위와 인증 방식은 각 제공업체의 약관 및 클라이언트 정책에 따라 다를 수 있으므로, 실제 연동 전 확인이 필요하다.
Experiments 메뉴에서는 실험 기능을 활성화할 수 있으며, 영상은 특히 Project 기능을 유용한 기능으로 평가한다. 모바일 앱은 QR 코드를 이용해 데스크톱 환경과 페어링할 수 있다고 소개된다. 이러한 기능은 아직 Research Preview(리서치 프리뷰) 단계라는 설명과 함께 제시되므로, 안정성과 호환성이 완성된 제품 수준이라고 단정하기는 어렵다.
하나의 채널에서 구성하는 멀티 에이전트 워크플로
시연에서는 먼저 콘텐츠 조사 에이전트에게 최근 유행하는 주제를 찾도록 Direct Message를 보낸다. 에이전트는 메시지를 확인했다는 반응을 남기고 작업을 시작하며, 인터페이스에는 실행 상태와 경과 시간이 표시된다. 결과가 스레드에 게시되면 사용자는 그 답변을 중심으로 후속 대화를 이어갈 수 있다.
그다음에는 “유튜브 팀”이라는 채널을 만들고 콘텐츠 조사, 썸네일 생성, 프로그래밍 역할의 에이전트를 함께 참여시킨다. 콘텐츠 조사 에이전트가 AI 관련 최신 뉴스를 찾아 조회 가능성이 높은 주제를 추천하고, 썸네일 에이전트가 그 결과를 바탕으로 이미지 두 개를 만들며, 프로그래머는 데모용 랜딩 페이지를 제작해 Buzz 프로젝트에 저장하도록 지시한다. 서로 다른 모델이 하나의 작업 목표와 공개된 스레드를 공유한다는 점이 이 시연의 핵심이다.
작업 사이에는 선후 관계와 병렬성이 동시에 존재한다. 프로그래머는 조사 결과가 나오기 전에 페이지 골격을 만들 수 있지만, 썸네일 에이전트는 주제가 확정되어야 본격적으로 작업할 수 있다. Buzz가 진행 상태를 한 화면에 보여 주더라도 이러한 의존성을 자동으로 완벽하게 해결하는 것은 아니며, 에이전트가 다음 담당자를 명시적으로 태그하거나 사용자가 작업 순서를 조정해야 할 수 있다.
💡 [영상 참조] 강연자는 서로 다른 AI 백엔드를 사용하는 세 에이전트를 하나의 채널에 추가하고, 조사·썸네일·개발 작업을 연결하는 프롬프트를 입력한다.
📺 원본 영상에서 멀티 에이전트 채널 구성을 확인할 수 있다.
공유 스레드가 만드는 모델 교체와 벤치마킹 가능성
Buzz에서는 에이전트의 AI 백엔드를 교체해도 과거 스레드가 Relay에 남는다. 따라서 사용자는 동일한 대화 맥락에서 여러 모델을 번갈아 적용해 보고, 어느 모델이 특정 역할에 더 적합한지 비교할 수 있다. 이는 각 모델의 웹이나 터미널 세션을 따로 사용할 때보다 입력 조건을 일정하게 유지하기 쉽다는 장점으로 이어진다.
다만 대화 기록이 같다고 해서 모델 비교가 자동으로 엄밀한 Benchmark(벤치마크)가 되는 것은 아니다. 모델마다 지원하는 도구와 컨텍스트 처리 방식이 다르고, 실행 시점의 외부 데이터나 에이전트 설정도 결과에 영향을 줄 수 있기 때문이다. 공정한 비교를 원한다면 역할 지시, 사용 도구, 입력 파일, 성공 조건과 평가 기준을 고정해야 한다.
그럼에도 공통 스레드는 실무적인 비교 기반으로 충분한 가치가 있다. 사용자는 한 모델이 실패한 지점에서 다른 모델로 이어서 작업하게 하거나, 같은 문제에 대한 접근법을 나란히 검토할 수 있다. 특히 팀원이 모든 모델의 개별 세션에 접근하지 않아도 의사결정 과정을 확인할 수 있다는 점에서, 모델 교체 비용과 인수인계 비용을 동시에 줄일 가능성이 있다.
Git 저장소와 서명된 작업 이력
Buzz의 Project 기능은 Relay가 Git 관련 이벤트와 프로젝트 기록을 함께 다룬다는 점에서 일반적인 AI 채팅 도구와 구별된다. 영상에 따르면 프로젝트 탭에서는 GitHub와 유사한 저장소 인터페이스가 나타나며, 커밋 목록과 작업 주체를 확인할 수 있다. 외부 GitHub 저장소 없이도 커뮤니티 내부에서 코드와 변경 이력을 관리할 수 있다는 설명이다.
각 Git 커밋이나 관련 이벤트에 서명을 결합하면 어떤 사람이나 에이전트가 변경을 만들었는지 추적할 수 있다. 이는 여러 AI가 동시에 코드를 생성하는 환경에서 특히 중요하다. 최종 결과만 남기는 방식으로는 오류를 만든 주체와 판단 과정을 찾기 어렵지만, 서명된 변경 이력과 연결된 대화 스레드가 있으면 변경의 배경까지 거슬러 올라갈 수 있기 때문이다.
다만 서명은 작성 주체를 증명할 뿐, 코드의 정확성이나 안전성을 보증하지 않는다. AI가 서명한 변경이라도 테스트 실패, 보안 취약점 또는 라이선스 문제가 포함될 수 있으므로 코드 리뷰와 CI(지속적 통합)는 여전히 필요하다. Buzz의 감사 가능성은 품질 검증을 대체하는 기능이 아니라, 검증할 대상을 더 명확하게 만드는 기반으로 이해해야 한다.
💡 [영상 참조] 강연자는 Project 탭에서 실제 Git 저장소와 커밋 기록을 열어 작업자, 에이전트 및 서명 정보를 확인한다.
📺 원본 영상에서 저장소 UI와 커밋 내역을 확인할 수 있다.
Pulse와 Inbox 및 Workflow의 역할
Pulse는 사람과 AI 에이전트가 짧은 글을 게시하고 댓글을 주고받는 내부 소셜 피드에 가깝다. 사용자는 어떤 작업을 수행했는지 기록할 수 있고, 다른 참여자나 에이전트가 그 게시물에서 대화를 이어갈 수 있다. 채널이 특정 프로젝트의 실시간 작업 공간이라면, Pulse는 커뮤니티 전반의 활동과 생각을 느슨하게 공유하는 공간으로 볼 수 있다.
Inbox는 사용자가 태그된 메시지를 한곳에 모아 보여 준다. 여러 채널과 에이전트가 동시에 작동하는 환경에서는 중요한 요청이 대화 속에 묻힐 수 있으므로, 개인에게 필요한 메시지를 분리하는 기능이 필요하다. 이는 Slack과 유사한 사용 경험을 제공하면서도 다수의 자동화된 에이전트가 생성하는 메시지량을 관리하기 위한 장치다.
Workflow 기능은 반복 작업을 구성하는 용도로 소개되지만, 강연자는 현재 복잡도가 높아 개인적으로 적극 사용하지 않는다고 평가한다. 반복 실행이 필요한 작업에는 잠재적으로 유용하지만, 영상 시점에는 설정 편의성과 사용성이 더 개선될 필요가 있다는 판단이다. 따라서 처음 도입할 때는 채널과 역할별 에이전트부터 구성하고, 안정적인 반복 패턴이 확인된 뒤 Workflow로 확장하는 편이 현실적이다.
시연에서 드러난 한계와 운영 위험
영상의 실제 시연에서는 콘텐츠 조사 결과가 나왔음에도 썸네일 생성 에이전트가 자동으로 반응하지 않는 상황이 발생한다. 강연자는 선행 에이전트가 다음 에이전트를 태그하지 않았기 때문으로 추정하고, 사용자가 직접 다시 태그해 작업을 시작시킨다. 이 사례는 공유 채널이 존재하는 것과 에이전트 사이의 안정적인 작업 전달이 보장되는 것이 별개의 문제임을 보여 준다.
강연자는 요청이 실행되지 않거나 답변이 정상적으로 이어지지 않는 경우가 가끔 있다고도 언급한다. Buzz가 Research Preview 단계라는 점을 고려하면, 중요한 업무를 완전히 무인으로 맡기기보다는 사람이 중간 결과와 작업 상태를 확인하는 Human-in-the-loop(사람이 개입하는 운영 방식)가 필요하다. 실패를 감지하고 재시도하는 정책, 작업 제한 시간, 담당자 태그 규칙도 명시적으로 마련하는 편이 좋다.
자체 호스팅 환경에서는 소프트웨어 안정성뿐 아니라 운영 보안도 고려해야 한다. Relay의 공개 노출 범위, WSS 인증서, 데이터베이스와 객체 저장소의 접근 권한, 개인 키 보관, 백업 및 장애 복구가 모두 운영자의 책임이 된다. 서명된 기록을 장기간 보존하는 장점은 동시에 민감한 프롬프트와 소스 코드가 서버에 오래 남는다는 의미이므로, 보존 정책과 삭제 정책도 도입 전에 검토해야 한다.
Buzz의 진짜 의미는 채팅 통합이 아니라 작업 주체의 통합이다
Buzz를 단순히 “오픈소스 Slack”이라고 부르면 익숙한 인터페이스는 잘 설명할 수 있지만, 제품의 더 중요한 지점은 놓치기 쉽다. Buzz가 제시하는 변화는 AI를 별도의 도구가 아니라 채널 안에서 역할과 정체성을 가진 협업 주체로 다루는 것이다. 사람과 AI가 같은 스레드를 읽고 동일한 프로젝트 기록에 참여하면, AI 사용은 개인의 비공개 프롬프트 작업에서 팀이 관찰하고 검토할 수 있는 프로세스로 이동한다.
암호학적 서명과 Git 통합도 같은 방향을 가리킨다. 앞으로 수많은 에이전트가 코드를 만들고 문서를 수정한다면, 결과물뿐 아니라 누가 어떤 맥락에서 무엇을 변경했는지 증명하는 Provenance(출처 추적성)가 중요해진다. Buzz는 메시지, 반응, Git 이벤트를 하나의 추적 가능한 활동 기록으로 묶으려 한다는 점에서 AI 시대의 협업 인프라에 관한 구체적인 제안을 내놓는다.
반면 이러한 비전이 실현되려면 에이전트 간 호출의 신뢰성, 권한 분리, 비밀 정보 관리와 장애 복구가 충분히 성숙해야 한다. 익숙한 채팅 UI는 복잡한 분산 시스템을 쉽게 보이게 만들지만, 실제 운영 복잡성까지 제거하지는 않는다. 현재 단계에서 Buzz는 Slack의 완성된 대체재라기보다는, 사람과 여러 AI가 같은 업무 공간에서 어떻게 협업할 수 있는지를 보여 주는 실험적 플랫폼으로 평가하는 것이 균형 잡힌 해석이다.
마무리 / 핵심 정리
영상이 제시하는 Buzz의 가장 큰 가치는 여러 AI 모델의 대화창을 한곳에 모으는 편의성이 아니다. 진짜 핵심은 사람과 AI가 같은 스레드와 프로젝트 이력을 공유함으로써, 모델을 교체하더라도 작업 맥락과 책임 추적성을 유지하려는 데 있다. Relay, 암호학적 서명, 해시 체인 감사 로그와 Git 기능은 이러한 목표를 뒷받침하는 기술적 기반이다.
특히 여러 구독형 AI 도구를 병행하는 개인이나, 콘텐츠 조사와 디자인 및 개발처럼 성격이 다른 작업을 여러 에이전트에 분배하는 소규모 팀에는 매력적인 접근법이 될 수 있다. 공통 컨텍스트를 통해 인수인계 비용을 줄이고, 모델별 성능을 같은 작업 흐름에서 비교하며, 사람이 전체 진행 과정을 관찰할 수 있기 때문이다. 이는 AI 에이전트를 단발성 응답기가 아니라 지속적인 팀 구성원으로 다루려는 흐름과 맞닿아 있다.
그러나 영상 시점의 Buzz는 Research Preview 단계이며, 실제 시연에서도 태그 누락과 작업 미실행 같은 문제가 나타났다. 따라서 중요한 운영 환경에 즉시 전면 도입하기보다는 비민감한 프로젝트에서 안정성, 권한 관리, 비용과 백업 방식을 먼저 검증하는 편이 바람직하다. Buzz는 아직 완성된 Slack 대체재라기보다, AI와 사람이 공유할 차세대 업무 공간의 형태를 선명하게 보여 주는 유망한 실험에 가깝다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | 슬랙을 오픈소스로 풀어버린 Buzz. AI와 휴먼의 협업 툴 |
| 공식 저장소 | Block Buzz GitHub 저장소 |
| 공식 지원 문서 | Buzz Support |
| 채널 | 코드팩토리 |
| 영상 길이 | 약 20분 37초 |
| 리포트 작성 | 2026-08-26 |
| 작성 방식 | YouTube 영상 STT 변환 후 문맥 교정 및 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었다. STT에서 불명확하게 인식된 고유명사와 설정 용어는 기술적 문맥 및 공식 자료에 따라 교정했으며, 프로젝트의 창업 배경과 영상에 언급된 가격 정보는 별도로 검증하지 않았다. 정확한 시연 내용은 원본 영상을 참조해야 한다.