서론

"당신이 소유한 릴레이(relay) 위에서 인간과 에이전트가 함께 구축하는 워크스페이스."

이 글은 "하루에 하나의 오픈 소스 프로젝트(One Open Source Project a Day)" 시리즈의 132번째 기사입니다. 오늘의 프로젝트는 Buzz입니다. 이는 Block Inc.(Square, Cash App, TBD의 모기업)에서 만든 오픈 소스 셀프 호스팅(self-hostable) 팀 워크스페이스로, Nostr 릴레이를 기반으로 구축되었으며 인간과 AI 에이전트가 동일한 채널을 공유합니다.

대부분의 AI 에이전트 통합은 다음과 같이 작동합니다: Slack이나 Teams에 봇을 추가하고, 봇은 @멘션되었을 때만 응답하며 그 외에는 아무것도 하지 않습니다. Buzz는 다른 질문에서 시작합니다: 왜 에이전트의 역량 범위가 인간 팀원의 범위보다 작아야 하는가? 만약 에이전트가 코드를 리뷰하고, 워크플로우(workflow)를 트리거하며, 채널을 열고, 협업자를 불러올 수 있다면 — 즉, 인간이 하는 것과 동일한 일을 동일한 신원 시스템(identity system)과 감사 추적(audit trail)을 통해 수행할 수 있다면 — 그때의 팀 협업은 어떤 모습일까요?

12,390 Stars. 2026년 3월 생성. Apache 2.0.

학습 내용

• Buzz가 왜 Nostr를 기반으로 구축되었는지, 그리고 그것이 실제로 무엇을 의미하는지
• 봇이 아닌 "1급 구성원(first-class members)"으로서의 에이전트 메커니즘
• 세 가지 구체적인 시나리오: 장애 메모리(incident memory), 브랜치-애즈-룸(branch-as-room), 스스로 작성되는 릴리스 노트(release notes)
• buzz-cli 및 ACP 어댑터: Claude Code를 Buzz에 연결하는 방법
• 아키텍처: Rust 크레이트(crate) 맵, Postgres + Redis + MinIO 데이터 레이어
• 현재 작동하는 것, 연결 중인 것, 그리고 아직 "강한 의견만 있고 코드는 대기 중(strong opinions, pending code)"인 것

사전 요구 사항

• 팀 협업 도구(채널, 메시지, 워크플로우)에 대한 기본적인 친숙함
• AI 에이전트 도구 호출(tool-calling)에 대한 일반적인 이해
• 기본적인 Git 지식

프로젝트 배경

개요

Buzz는 기술적 기반이 Nostr 릴레이(NIP-01 / NIP-42)인 셀프 호스팅 팀 워크스페이스입니다. 메시지, 반응(reactions), 워크플로우 단계, 코드 리뷰 승인, Git 이벤트 — 이 모든 것들은 동일한 서명된 이벤트 로그(signed event log) 내의 이벤트입니다. 작성자가 인간이든 프로세스이든 관계없이 동일한 형식, 동일한 신원 모델, 동일한 감사 추적을 가집니다.

저자 / 팀

• 저자 / 회사: Block, Inc.
• 주요 언어: Rust (백엔드) + TypeScript (데스크톱 UI)
• 라이선스: Apache-2.0
• 데스크톱 앱: Tauri + React

프로젝트 통계 (Project Stats)

• ⭐ GitHub Stars: 12,390+
• 🍴 Forks: 996+
• 📄 라이선스: Apache-2.0
• 📅 생성일: 2026-03-06

빠른 시작 (Quick Start)

Docker와 Hermit이 필요합니다 (또는 수동 설치: Rust 1.88+, Node 24+, pnpm 10+, just).

최초 설정:

git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit   # 고정된 툴체인 (첫 사용 시 도구 다운로드)
just setup && just build

just setup은 just bootstrap을 자동으로 실행합니다 — .env.example을 복사하고, 도구를 다운로드하며, Docker 서비스 및 마이그레이션(migrations)을 시작합니다.

매일 작업 시:

. ./bin/activate-hermit
just dev   # 릴레이(relay)와 데스크톱 앱을 함께 시작

릴레이는 ws://localhost:3000에서 실행됩니다. 데스크톱 앱이 팝업됩니다. 이제 시작할 준비가 되었습니다.

터미널 분할 워크플로(Vite 출력과 릴레이 로그를 분리하는 경우):

# 터미널 1
just relay

...

핵심 설계: 모든 것은 이벤트다 (Everything Is an Event)

왜 Nostr인가

Buzz의 기술적 토대는 Nostr 릴레이 (Nostr relay) (NIP-01 / NIP-42)입니다. 이 선택은 다음과 같은 몇 가지 깊은 함의를 갖습니다:

1. 통합된 신원 모델 (Unified identity model): 인간은 Schnorr 키 쌍(keypairs)으로 서명하고, AI 에이전트도 Schnorr 키 쌍으로 서명합니다. 신원은 역할이나 권한 플래그가 아니라, 암호학적 신원(cryptographic identity)입니다. 에이전트는

• 특별한 "봇 (bot)" 계정 유형을 가짐
• 특정 트리거(@mention, webhook)에만 응답할 수 있음
• 인간 구성원이 할 수 있는 일의 제한된 하위 집합만 수행 가능
• 인간과 분리된 별도의 감사 추적 (audit trail)을 가짐

Buzz 에이전트:

• 자신만의 Nostr 키 쌍 (keypair)을 가짐 (인간 구성원과 동일)
• 자신만의 채널 멤버십을 가짐
• 인간 구성원이 할 수 있는 모든 것을 수행할 수 있음: 메시지 전송, 채널 생성, 캔버스 (canvases) 편집, 워크플로우 (workflows) 트리거, 보이스 허들 (voice huddles) 참여, 리포지토리 (repos) 열기, 패치 (patches) 전송, 코드 리뷰, 다른 에이전트 오케스트레이션 (orchestrate)
• 감사 추적 (audit trail)이 인간과 동일한 로그에 존재하며, 암호학적 키 (cryptographic key)로 구분됨

프로젝트 자체의 설명: "에이전트는 자신만의 키와 자신만의 감사 추적을 가지며, 인간과 동일한 표면적 (surface area)을 가집니다."

세 가지 구체적인 시나리오

README는 이 설계가 실제 환경에서 무엇을 의미하는지 구체적으로 보여주는 세 가지 시나리오를 설명합니다:

시나리오 1: 장애 메모리 (Incident Memory)

새벽 2시입니다. 당신은 _"이 에러를 전에 본 적이 있나요?"_라고 입력합니다. 채널을 모니터링하던 에이전트가 6개월 치의 기록을 불러와 스레드, 근본 원인 (root causes), 수정 사항을 게시하고, 마지막으로 해당 코드를 배포한 사람에게 페이지 (page)를 보낼 것을 제안합니다. 질문, 답변, 증거를 포함한 전체 교환 내용은 채널에 그대로 남습니다.

이것이 해결하는 문제: 장애 메모리는 보통 Slack 스레드, Jira 티켓, PagerDuty 알림, 코드 주석 등 서로 다른 도구들에 흩어져 있습니다. 새벽 2시에는 아무도 이들을 상관 분석 (correlate)할 수 없습니다. 모든 것이 동일한 이벤트 로그 (event log)에 있으면, 에이전트의 "6개월 치 기록 검색"은 시스템 간의 API 크롤링이 아니라 단일 인덱스 (index)를 쿼리하는 작업이 됩니다.

시나리오 2: 룸으로서의 브랜치 (Branch as Room)

기능 브랜치 (feature branch)를 엽니다. 채널이 나타납니다. 패치 (patches)는 NIP-34 이벤트로 기록되고, CI가 결과를 게시하며, 에이전트가 1차 리뷰를 수행합니다. 팀원들은 자신이 관심 있는 부분에 반응하고, 머지 (merge) 결정은 증거와 함께 동일한 공간에 기록됩니다. 따라서 채널은 코드가 존재하는 이유에 대한 기록이 됩니다.

전통적인 PR (Pull Request) 문제: 왜 이 PR을 생성하겠다는 결정은 Slack에서, PR 자체는 GitHub에서, CI는 또 다른 도구에서, 그리고 배포 승인은 또 다른 도구에서 이루어져야 할까요? Buzz의 해답은 간단합니다. 이 모든 것은 이벤트 (event)이며, 모두 동일한 채널에 속해야 한다는 것입니다.

시나리오 3: 스스로 작성되는 릴리스 노트 (Release Notes)

태그 (tag)가 생성되면 워크플로 (workflow)가 실행됩니다. 에이전트 (agent)가 프로젝트 채널에서 머지 (merge)된 PR들을 읽고, 릴리스 노트를 초안 작성하며, 인간의 검토를 위해 게시합니다. 이후 👍 반응을 얻으면 배포를 완료합니다. 모든 단계는 서명되며, 모든 단계는 검색 가능합니다.

"승인 게이트로서의 👍 반응" 설계를 주목하십시오. 이는 특별한 승인 UI나 별도의 승인 도구가 아니라, 단지 채널 내의 이모지 반응일 뿐입니다. 왜냐하면 이 반응 또한 워크플로가 감지할 수 있는 서명된 이벤트 (signed event)이기 때문입니다.

에이전트 통합: buzz-cli 및 ACP 어댑터 (ACP Adapter)

buzz-cli

buzz-cli는 AI 에이전트를 위해 특별히 설계된 명령줄 도구(command-line tool)입니다. JSON 입력, JSON 출력 (JSON in, JSON out) 방식으로, LLM 도구 호출 (tool calls)에 최적화되어 있습니다.

# 에이전트의 Nostr 개인키 설정
export BUZZ_PRIVATE_KEY=nsec...

...

설계 원칙: 모든 명령 입출력 (I/O)은 파싱하기 어려운 인간용 출력 대신, LLM 도구 호출을 위해 구조화되어 있습니다.

ACP 어댑터 (buzz-acp)

Buzz는 다음과 같은 AI 코딩 에이전트들이 Buzz에 직접 연결할 수 있도록 하는 ACP (Agent Communication Protocol) 어댑터를 제공합니다:

• Claude Code
• Goose (Block 자체 AI 에이전트)
• Codex

buzz-acp는 ACP ↔ MCP를 연결합니다. 즉, Buzz의 기능들을 MCP 도구로 변환하여, MCP 호환 에이전트가 이를 직접 호출할 수 있게 합니다.

buzz-dev-mcp

buzz-dev-mcp는 다음과 같은 기능을 노출하는 MCP 서버입니다:

• 셸 도구 (Shell tools, Buzz 컨텍스트 내에서 명령 실행)
• 파일 편집 도구 (File editing tools)

이를 통해 Claude Code 및 유사한 도구들은 새로운 API를 배울 필요 없이, 익숙한 MCP 도구 호출 패턴을 사용하여 Buzz 채널 내부에서 작업할 수 있습니다.

아키텍처 심층 분석

시스템 아키텍처

┌────────────────────────────────────────────────────────────┐
│                         클라이언트 (Clients)                            │
│  인간 클라이언트 (Human client)      AI 에이전트 (AI agent)             CLI / 스크립트 (scripts)      │
...

단일 진실 공급원 (Single source of truth): 릴레이 (relay). 모든 상태는 릴레이를 통해 흐르며, 클라이언트와 서버 간의 불일치 (drift)를 제거합니다. 에이전트의 동작 측면에서 이는 매우 중요한데, 에이전트가 쿼리하는 히스토리가 인간이 보는 히스토리와 동일하기 때문입니다.

Rust 크레이트 맵 (Rust Crate Map)

코어 프로토콜 (Core protocol)

• buzz-core — I/O가 없는 타입 (zero-I/O types), NIP-01 필터, Schnorr 검증
• buzz-relay — Axum WebSocket + REST 서버

서비스 (Services)

• buzz-db — Postgres
• buzz-auth — NIP-42/98 Schnorr 인증 + 속도 제한 (rate limiting)
• buzz-pubsub — Redis pub/sub + 존재 여부 (presence) + 타이핑 (typing)
• buzz-search — Postgres 전문 검색 (full-text search)
• buzz-audit — 해시 체인 감사 로그 (hash-chain audit log)

에이전트 접점 (Agent surface)

• buzz-cli — 에이전트 우선 CLI (JSON 입출력)
• buzz-acp — Goose/Codex/Claude Code를 위한 ACP 어댑터
• buzz-agent — ACP 에이전트 구현체
• buzz-dev-mcp — 쉘 + 파일 편집 MCP 도구
• buzz-workflow — YAML 자동화
• buzz-persona — 에이전트 페르소나 팩

Git + 페어링 (Git + pairing)

• git-sign-nostr / git-credential-nostr — Nostr로 서명된 Git
• buzz-pair-relay / buzz-pairing-cli — 릴레이 페어링

멀티 커뮤니티 모드 (Multi-Community Mode)

릴레이는 기본적으로 하나의 커뮤니티 (워크스페이스)를 호스팅합니다. 호스팅 운영자는 여러 도메인/서브도메인 뒤에서 여러 커뮤니티에 서비스를 제공할 수 있지만, 클라이언트 측 규칙은 동일하게 유지됩니다: URL은 워크스페이스에 대한 권위 있는 식별자 (authoritative identifier)이며, 백엔드가 단일 Postgres 및 Redis 인스턴스를 공유하더라도 테넌트가 관찰 가능한 모든 상태는 커뮤니티별로 범위가 지정됩니다.

현재 작동 중 / 연결 중 / 코드 작성 중인 강력한 의견 (Works Today / Being Wired Up / Strong Opinions, Pending Code)

프로젝트 상태에 대한 README의 투명성은 언급할 가치가 있습니다:

README는 이 표를 다음과 같이 마무리합니다: 💭 열을 기준으로 컴플라이언스 프로그램을 계획하지 마십시오. 무엇이 실체가 없는 기능(vaporware)이고 무엇이 출시될 예정인지에 대한 이러한 명시적인 투명성은 오픈 소스 프로젝트의 README에서는 흔치 않은 일입니다.

리소스 (Resources)

공식 링크 (Official Links)

• 🌟 GitHub: block/buzz
• 📖 아키텍처 (Architecture): ARCHITECTURE.md
• 🔭 비전 (Vision): VISION.md
• 🤖 에이전트 비전 (Agent vision): VISION_AGENT.md
• 🚀 최신 릴리스 (Latest release): Releases

요약 (Summary)

Buzz의 핵심 논지는 "에이전트가 인간과 동일한 신원 시스템(identity system)을 사용하고 동일한 감사 추적(audit trail)을 남기며 인간이 하는 일을 수행하게 하자"라는 가설을 진지하게 테스트할 가치가 있다는 것입니다. 에이전트를 제한하기 위해 권한 플래그(permission flags)를 사용하는 대신, Buzz는 서로 다른 인간 구성원을 구분하는 것과 동일한 방식으로 암호화된 신원(cryptographic identity)을 사용하여 에이전트를 구분합니다.

주목할 만한 세 가지 엔지니어링 결정 사항은 다음과 같습니다:

통합 기반으로서의 Nostr relay: 단순히 "Git 통합 기능이 덧붙여진 Slack"이 아니라, 모든 이벤트 유형(메시지, 코드, 승인, 워크플로 단계)을 동일한 프로토콜에 담는 방식입니다. 이는 상대적으로 니치(niche)한 기반 프로토콜을 채택해야 하는 비용을 치르는 대신, "이력을 재구성하기 위해 여러 시스템을 검색해야 하는 문제" 자체를 제거합니다.

단일 진실 공급원 (Single source of truth): 모든 상태(state)는 relay를 통해 흐르며, 클라이언트 로컬 상태가 서버의 진실과 어긋나는 일이 발생하지 않습니다. 이는 특히 에이전트의 신뢰성 측면에서 중요한데, 에이전트가 조회하는 이력이 인간이 보는 것과 동일하기 때문입니다.

감사 추적 (Audit trail)은 선택 사항이 아닙니다: 해시 체인 (hash-chain) 감사 로그는 별도로 덧붙여진 것이 아니라 내장되어 있습니다. 인간이 수행했든 에이전트가 수행했든 관계없이, 모든 단계는 서명되며 모든 단계는 추적 가능합니다.

ACP 어댑터 (adapter) + buzz-dev-mcp: Claude Code 사용자들에게 이는 새로운 API를 처음부터 배울 필요 없이, 익숙한 MCP 도구 호출 (tool-call) 패턴을 사용하여 Buzz 채널 내에서 작업할 수 있음을 의미합니다.

Block Inc.는 여기서 구조적인 이점을 가지고 있습니다. 그들은 자체 AI 코딩 에이전트인 Goose를 구축하고 있으므로, "인간-에이전트 협업 워크스페이스"는 단순한 제품 비전이 아니라 그들의 내부 툴링 (tooling) 그 자체입니다. 이는 순수하게 추측에 기반한 제품 개발과는 다른 방식으로 요구 사항을 날카롭게 다듬는 경향이 있습니다.

실제 기업 워크플로우에 맞춰 검증된 AI 에이전트 및 기술의 큐레이션 마켓플레이스인 PrimeSkills를 탐색해 보세요. 과장 없이, 실제로 작동하는 것들만 제공합니다.

더 많은 통찰력과 흥미로운 제품을 보려면 저의 개인 사이트를 방문해 주세요.