블록 버즈: 에이전트가 봇이 아닌 팀원인 AI 에이전트 워크스페이스
대부분의 "AI in your chat" 설정은 동일한 방식으로 작동합니다: Slack이나 Discord에 봇을 붙이고, 슬래시 명령을 부여한 다음, 소환되면 답변합니다. 봇은 팀 외부에 있습니다. 별도의 정체성, 별도의 감사 로그를 가지고 있으며, 건드릴 수 있는 것에 대해 엄격한 한계가 있습니다. Block은 이 패턴을 살펴보고 에이전트를 그냥 방의 멤버로 만들기로 결정했습니다.
그 아이디어가 바로 Buzz입니다. Block, Inc.의 오픈소스 워크스페이스로, 이미 약 18,000개의 GitHub 스타를 모았습니다. Buzz에서 인간과 AI 에이전트는 동일한 채널을 공유하고, 같은 종류의 암호화 키로 자신의 행동에 서명하며, 결국 동일한 검색 가능한 로그에 남습니다. Rust로 작성되었으며 Apache 2.0 라이선스를 받았습니다. 저는 저 대신 리포지토리의 아키텍처 문서를 읽고 시간을 보냈는데, 설계 선택지들이 마케팅이 제안하는 것보다 훨씬 흥미롭습니다.
블록 버즈란?
Buzz는 Block, Inc.의 자체 호스팅 가능한 워크스페이스로, 인간과 AI 에이전트가 동일한 채널을 공유합니다. Nostr 릴레이에서 실행되므로, 모든 메시지, 반응, 코드 패치, 승인, 워크플로우 단계는 단일 검색 가능하고 변조 방지 로그에 하나의 서명된 이벤트입니다. Apache 2.0 라이선스의 오픈소스이며, Rust로 빌드되었고, 릴레이를 직접 실행합니다.
핵심 사항:
- 에이전트는 측면에 붙인 봇이 아니라 자신만의 키와 감사 로그를 가진 일급 멤버입니다.
- 모든 것(채팅, 패치, CI, 승인)이 단일 검색 가능한 로그에 하나의 서명된 Nostr 이벤트입니다.
- 에이전트는 ACP와 MCP를 통해 연결되므로, Goose, Codex, Claude Code가 바로 작동합니다.
- 자체 호스팅 및 오픈소스(Apache 2.0)이며, 아직 완료되지 않은 것에 대한 정직하고 공개된 목록이 있습니다.
이 프로젝트가 강조하는 표현은 "하이브 마인드 통신 플랫폼"입니다. 듣기에는 거창하지만, 일상적인 현실은 더 간단합니다: 팀 워크스페이스처럼 느껴집니다. 채널, 스레드, DM, 캔버스, 음성 허들, 검색. 트위스트는 밑에 있습니다. 모든 행동은 서명된 Nostr 이벤트이고, 해당 이벤트의 작성자는 사람이거나 프로세스일 수 있습니다. 모양은 같고, 정체성 모델은 같으며, 감사 로그도 어느 쪽이든 같습니다.
LangGraph, CrewAI, OpenAI Agents SDK 같은 에이전트 프레임워크를 비교해본 경험이 있다면, Buzz는 완전히 다른 계층입니다. 그것들은 에이전트의 추론을 조율하기 위해 코드에 임베드하는 라이브러리입니다. Buzz는 에이전트와 팀이 대화하고, 작업을 인계하며, 기록을 남기는 방입니다. 이들은 경쟁 관계가 아니라 상호 보완 관계입니다.
"멤버로서의 에이전트"가 모델을 바꾸는 이유
봇 모델에는 구조적인 문제가 있습니다: 에이전트가 손님입니다. 권한 플래그를 부여하고, 좁은 API를 통해 작동하며, 뭔가 잘못되면 두 개의 별도 히스토리인 팀의 채팅과 봇의 로그를 조율해야 합니다.
Buzz는 이를 뒤집습니다. 에이전트는 자신의 키쌍, 채널 멤버십, 자신의 감사 로그를 얻습니다. 사람을 채널에 추가하는 것과 동일한 방식으로 에이전트를 채널에 추가합니다. 이 프로젝트는 스코핑을 "권한 플래그가 아닌 정체성으로"라고 설명하는데, 이는 인간 팀원을 스코핑하는 것과 같은 방식입니다. 당신은 어떤 방에서는 신뢰하고 다른 방에서는 신뢰하지 않습니다.
에이전트가 멤버가 되면, 다른 모든 사람이 가진 것과 동일한 affordance를 얻습니다. 리포지토리를 열고, 패치를 보내고, 코드를 검토하고, 워크플로우를 실행하고, 캔버스를 편집하고, 다른 에이전트를 조율하고, 채널을 만들고, 음성 허들에 뛰어들 수 있습니다. README는 이를 구체적으로 만드는 세 가지 시나리오를 설명합니다:
- 사건 메모리. 오전 2시, "이 오류를 전에 본 적 있나?"라고 묻고, 채널을 보고 있는 에이전트가 6개월의 히스토리를 가져와 스레드와 근본 원인을 게시하고 마지막 수정을 배포한 사람에게 연락할 것을 제안합니다. 전체 교환이 증거로 채널에 남습니다.
- 방으로서의 브랜치. 기능 브랜치를 열면 채널이 나타납니다. 패치는 이벤트로 착륙하고, CI는 결과를 게시하고, 에이전트가 첫 번째 패스 검토를 실행하고, 병합 결정이 이를 정당화한 증거와 같은 방에 있습니다.
- 자체적으로 작성되는 릴리스. 워크플로우가 태그에서 시작되고, 에이전트가 병합된 PR에서 릴리스 노트를 작성하고, 인간 검토를 위해 게시하고, 엄지손가락 반응을 받고, 배포합니다. 모든 단계가 서명되고, 모든 단계가 검색 가능합니다.
공통된 주제는 대화, 코드, 결정이 일곱 개의 탭이 서로를 알려고 하는 대신 한 곳에 살아있다는 것입니다.
에이전트가 실제로 어떻게 연결되는가: ACP와 MCP
이것이 엔지니어링이 깔끔해지는 부분입니다. Buzz는 에이전트용 두 개의 작은 바이너리를 제공하며, 의도적으로 서로를 알지 못합니다.
buzz-agent는 ACP 에이전트입니다. Agent Client Protocol을 stdio를 통해 말하고, LLM을 호출하고, MCP 도구를 사용합니다. 최대 8개의 동시 세션을 실행하며, 각각 자신의 MCP 서버, 히스토리, 컨텍스트를 가집니다. 세션의 컨텍스트가 가득 차면, 자신의 히스토리를 요약하고 계속 진행합니다. Zed, JetBrains 또는 ACP를 말하는 다른 것이면 작동합니다.
buzz-dev-mcp는 MCP 서버입니다. 모든 에이전트에 셸과 파일 편집기를 제공합니다. 프로세스는 모든 종료 경로에서 프로세스 그룹 킬로 일시적이고, 출력은 제한되며, 파일 편집은 작업 디렉토리에 대해 해결됩니다. 이전에 Model Context Protocol로 빌드한 경험이 있다면, 이것은 익숙하게 느껴질 것입니다: 강화된 표준 "에이전트에 손을 주기" 패턴입니다.
리포지토리의 설계 노트가 직설적으로 말합니다: "두 개의 바이너리, 두 개의 프로토콜, 그들 간의 결합이 없음." 에이전트는 어떤 MCP 서버와 대화하는지 알지 못하고, MCP 서버는 어떤 에이전트가 그것을 호출하는지 알지 못합니다. 그들은 임포트가 아닌 프로토콜을 통해 구성됩니다. 실질적인 이점은 다양한 MCP 구성으로 Buzz 뒤에 열 개의 에이전트를 실행하거나, 하나의 환경 변수로 LLM 공급자를 바꿀 수 있다는 것입니다.
buzz-acp가 릴레이 @mentions를 에이전트 부프로세스에 연결하기 때문에, Goose, Codex, 또는 Claude Code를 가리킬 수 있습니다. 이미 백그라운드 코딩 에이전트를 실행 중이라면, Buzz는 침묵하는 헤드리스 루프가 아니라 공유된 방을 제공합니다. 그리고 자신의 도구를 가져오고 싶다면, MCP 서버를 빌드하는 것이 지원되는 경로이며, 시작할 수 있는 많은 준비된 MCP 서버가 있습니다.
내부 동작: 아키텍처
Buzz는 Rust 모노레포이며, 가장 중요한 사실은 이것입니다: 릴레이가 단일 진실의 원천입니다. 피어 투 피어 가십도 없고 복제도 없습니다. 클라이언트는 WebSocket을 통해 하나의 릴레이에 연결되고, 릴레이는 인증을 처리하고, 서명을 검증하고, 이벤트를 지속하고, 구독자에게 팬아웃하고, 검색을 위해 인덱싱하고, 자동화를 트리거합니다.
모든 것은 Nostr NIP-01 이벤트입니다. 각 이벤트는 6개의 필드를 가집니다: id(직렬화된 이벤트의 SHA-256), pubkey, kind 정수, 태그, 콘텐츠, Schnorr 서명. kind 정수가 유일한 디스패치 스위치입니다. 새로운 기능을 원하나요? 새로운 kind 번호를 정의하세요. 기존 클라이언트는 아무것도 보지 못하고 깨지지 않습니다. 코드베이스는 81개의 kind를 정의하며, 사용자 정의 Buzz kind는 40000-49999 범위에 살아있습니다.
지원 스택은 가장 좋은 의미에서 의도적으로 지루합니다:
Postgres는 이벤트를 보유하고 전체 텍스트 검색을 실행합니다. Redis는 pub/sub 팬아웃, 현재 상태, 타이핑을 처리합니다. S3 호환 객체 저장소(로컬로는 MinIO)는 Blossom 프로토콜을 통해 미디어를 보유합니다.
보안 모델이 제가 훑어보기를 멈춘 부분입니다. 모든 이벤트의 Schnorr 서명과 SHA-256 ID는 저장 전에 검증됩니다. NIP-42 인증은 ±60초 타임스탐프 허용을 사용하여 재생 공격을 차단하고, 인증 이벤트는 저장되거나 감사되지 않습니다. 감사 로그는 진정한 해시 체인입니다: 각 항목의 SHA-256은 이전 해시를 포함한 모든 필드를 포함하므로, 하나의 항목을 변조하면 그 이후의 모든 항목이 깨집니다. 아웃바운드 웹훅은 사설 IP 범위를 확인하는 SSRF 보호를 받습니다. 그리고 채널 멤버십이 유일한 액세스 게이트이며, 모든 작업에서 시행되며, 구독 핸들러가 구독을 등록하기 전에 액세스를 확인하므로 사설 채널 누수에 대한 경쟁 윈도우가 없습니다.
통제하는 인프라에서 에이전틱 AI를 배포하는 방법을 평가하고 있다면, 이것이 두 번 읽을 가치가 있는 부분입니다.
오늘 작동하는 것(그리고 작동하지 않는 것)
...