Nostr 위에서 인간과 AI 에이전트를 연결하는 Buzz의 협업 설계

협업 참여자의 신원을 플랫폼 밖으로 꺼내는 Buzz

2026년 7월 21일, Jack Dorsey가 이끄는 Block은 오픈소스 협업 워크스페이스 Buzz를 공개했다. Buzz는 탈중앙 프로토콜 Nostr 위에 채팅, Git 호스팅, 워크플로 자동화를 연결한 도구다. Slack과 GitHub를 함께 겨냥한 대안으로 소개됐지만, 설계의 중심은 기능 묶음보다 참여자 신원에 있다.

Buzz에서 AI 에이전트는 명령만 수행하는 봇이 아니다. 인간과 마찬가지로 자체 권한을 가진 1급 참여자로서 글을 작성하고, 코드 리뷰에 참여하며, 승인된 자동화를 실행할 수 있다. 사람과 에이전트 모두 플랫폼 계정이 아니라 자신에게 귀속되는 secp256k1 키페어를 보유한다. 에이전트의 행위에는 자신과 소유 인간을 연결하는 이중 서명이 붙어, 누가 해당 에이전트를 authorize했는지 확인할 수 있는 관리 사슬을 만든다.

Block은 소스를 Apache 2.0 라이선스로 github.com/block/buzz에 게시했다. 공개 당시 Buzz는 버전 0.4.21의 초기 단계 소프트웨어이며, 모바일 앱은 미완성이고 푸시 알림은 대기 상태다. 자체 호스팅과 Block의 매니지드 릴레이 buzz.xyz를 모두 배포 선택지로 제공한다. Claude Code, Codex, Block의 오픈소스 프레임워크 goose 위에서 구축된 에이전트도 지원한다.

서명된 이벤트 하나로 묶는 협업 상태

Buzz의 구조는 모든 행위를 서명된 이벤트로 남긴다는 원칙에서 출발한다. 메시지와 반응, 워크플로 단계, 리뷰 승인, Git 이벤트는 작성자가 사람이든 프로세스든 같은 형태의 로그에 기록된다. 같은 신원 모델과 감사 추적을 공유하므로, 협업 상태를 별도 시스템마다 맞춰야 하는 이질감을 줄이는 방식이다.

Nostr는 암호학적으로 서명된 이벤트를 릴레이가 중계하는 단순 프로토콜이다. 중앙 서버에 신원과 데이터를 위탁하지 않는 구조를 제공하며, Buzz 릴레이도 Apache 2.0으로 공개돼 조직 인프라에서 직접 구동할 수 있다. 자체 릴레이를 사용하면 메시지, 코드, 에이전트 활동을 통제 가능한 인프라 안에 유지할 수 있다.

신원도 특정 플랫폼 계정에 매이지 않는다. Nostr 호환 시스템에서는 같은 에이전트 신원으로 참여할 수 있으며, 플랫폼 이전 뒤에도 동일한 신원과 감사 추적을 유지하는 것이 목표다.

에이전트를 도구가 아닌 멤버로 다룰 때

에이전트는 자체 권한을 가진 멤버로서 대화 참여, 코드 리뷰, 글 작성, 승인된 자동화 실행을 수행한다. 팀이 설정한 권한 범위 안에서 데이터베이스, CRM, 코드베이스, 파일시스템에 접근할 수 있다.

이 모델에서 중요한 것은 독립 키와 책임 연결을 함께 유지하는 방식이다. 모든 참여자는 secp256k1 키페어를 보유하고, 키의 소유권은 플랫폼이 아니라 개인 또는 에이전트에 있다. 에이전트는 자신의 서명에 더해 소유 인간과 연결되는 두 번째 서명을 부착한다. 따라서 에이전트가 독립 신원을 가져도, 그 행위를 authorize한 인간을 검증할 수 있다.

OAuth 토큰처럼 벤더가 발급하고 관리하는 신원 모델과 대비된다. Buzz는 자기 소유 키를 권한의 근거로 사용하므로, 플랫폼 정책이 아니라 암호학적 증거 위에서 권한 관계를 구성한다.

⤢✕

자체 릴레이 도입 전 확인할 운영 항목

Buzz 도입은 협업 도구를 교체하는 일에 그치지 않는다. 신원, 권한, 감사 체계를 다시 설계하는 작업이다. 초기에는 Block 매니지드 릴레이 buzz.xyz에서 PoC를 수행하고, 데이터 주권 요건을 충족해야 할 때 자체 릴레이로 이관하는 방식이 가능하다. 버전 0.4.x의 미성숙도를 고려하면 비핵심 워크로드부터 적용하는 편이 현실적이다.

에이전트별 키페어의 생성, 회전(rotation), 폐기 정책을 마련하고, 이중 서명의 소유자 매핑을 인사·계정 체계와 연동해야 한다. 데이터베이스, CRM, 코드베이스, 파일시스템처럼 에이전트가 접근하는 자원은 최소 권한 원칙으로 스코프화한다. 권한 상승은 별도 승인 이벤트로 남기는 구성이 필요하다.

tamper-evident 서명 로그는 컴플라이언스 증적으로 활용할 수 있다. 감사의 기본 질문은 “어떤 인간이 어떤 에이전트 행위를 승인했는가”가 된다. 규제 요건이 강한 조직이라면 자체 릴레이를 통해 메시지, 코드, 에이전트 활동을 통제 인프라 안에 보존하는 선택도 검토 대상이다.

Apache 2.0 라이선스는 릴레이와 클라이언트의 포크·커스터마이즈를 허용한다. Nostr 호환성은 사내 다른 Nostr 시스템과 신원을 상호운용할 여지도 만든다. 반면 서명 검증만으로 운영 문제가 끝나지는 않는다. 탈중앙 환경에서는 스팸과 과다 이벤트에 대응할 릴레이 수준의 필터링, 레이트 리밋, 화이트리스트를 자체 정책으로 보강해야 한다. 에이전트 온보딩·오프보딩, 키 관리, 릴레이 운영 책임, 이벤트 보존 기간도 협업 거버넌스 문서에 명시할 항목이다.

중앙형 플랫폼과 갈리는 지점

중앙형 협업 플랫폼에서는 Slack이나 GitHub 같은 벤더가 신원과 데이터를 관리한다. 계정 정지와 검열의 위험도 그 플랫폼에 종속된다. Buzz는 자기 소유 키와 자체 릴레이를 통해 검열 저항과 데이터 주권을 확보하려 한다. 대신 스팸 방어, 릴레이 가용성, 운영 부담은 조직이 직접 감당해야 한다.

기존 봇이나 어시스턴트는 플랫폼이 발급한 OAuth 토큰에 의존하는 도구 종속 신원이다. 벤더 정책이 바뀌면 사용 범위도 함께 제한될 수 있다. Buzz의 에이전트는 이식 가능한 자기 소유 신원을 사용해 플랫폼을 옮긴 뒤에도 동일한 신원과 감사 추적을 이어가는 방향을 택한다.

관점	Buzz(Nostr, 오픈소스)	중앙형 상용(Slack·GitHub 등)
신원 소유권	사용자/에이전트 키페어	플랫폼 발급 계정·토큰
데이터 주권	자체 릴레이 완전 통제	벤더 인프라 위탁
검열 저항	높음(탈중앙)	낮음(계정 정지 가능)
에이전트 위상	1급 참여자(이중 서명)	도구·봇(토큰 종속)
감사 추적	tamper-evident 단일 로그	플랫폼 로그(가변)
라이선스·확장	Apache 2.0, 포크 가능	상용, 폐쇄
성숙도	v0.4.21 초기	성숙·안정
운영 부담	높음(릴레이·스팸 자체 관리)	낮음(벤더 운영)

협업 시스템과 신원 거버넌스에 남는 과제

CSCW 관점에서 Buzz는 인간과 에이전트가 섞인 팀을 단일 이벤트 로그로 다루는 사례다. 협업 상태의 일관성과 감사성을 함께 확보하려는 구조이며, 상태 재개와 추적성은 이벤트 소싱(event sourcing) 패턴과도 맞닿아 있다.

이중 서명은 IAM에서 다루는 위임(delegation)과 책임 소재(accountability)를 암호학적으로 풀려는 접근이다. 에이전트 신원을 사람 신원 아래에 연결하면서도 독립 키를 분리해, 권한 관리(entitlement)와 감사(audit)를 함께 다룬다. 실무 적용은 키 라이프사이클, 폐기·회전, 릴레이 이벤트 보존 정책을 기존 정보보안 거버넌스에 통합할 때 비로소 완성된다.

2026년에 주목할 변화

에이전트를 1급 참여자로 다루는 협업 프로토콜 실험은 확산될 전망이다. OAuth 토큰 중심 신원에서 이식 가능한 암호학적 신원으로 이동하려는 시도도 가속될 가능성이 있다.

Buzz는 v0.4.x의 초기 성숙도를 고려하면 즉시 전면 도입보다 비핵심 워크로드 PoC가 적합하다. 스팸과 릴레이 가용성처럼 탈중앙 운영에서 남는 과제를 해결하는 일이 대중화의 관건이다. Nostr 호환 에이전트 신원 표준화 논의와 검열 저항·데이터 주권을 요구하는 규제 산업의 채택 여부는 2026년 하반기에 살펴볼 지점이다.

Buzz는 협업의 초점을 메시지를 어디에 저장하는가에서 누가 무엇을 서명했는가로 옮긴다. 에이전트를 자기 소유 신원을 가진 참여자로 규정한 설계는, AI 에이전트가 조직 워크플로에 깊이 편입될 때 책임 소재와 감사성을 암호학적으로 다루려는 실험으로 볼 수 있다. 다만 버전 0.4.21의 미성숙도와 스팸 방어, 릴레이 운영 부담은 남아 있다. 자체 릴레이 이관과 키 라이프사이클 관리 체계를 함께 준비하는 단계적 도입이 합리적이다.