2026 Buzz 완전정리: 사람과 AI 에이전트가 같은 방에서 함께 일하는 오픈소스 워크스페이스
2026 Buzz 완전정리: 사람과 AI 에이전트가 같은 방에서 함께 일하는 오픈소스 워크스페이스
AI에게 "이것 좀 해줘"라고 부탁하는 시대는 이미 익숙합니다. 그런데 잭 도시의 Block은 다른 질문을 던졌습니다. 부탁하는 대신 같은 방에 앉혀 두면 어떨까. 2026년 7월 21일 공개된 오픈소스 협업 플랫폼 Buzz가 그 답을 코드로 옮긴 결과물입니다.
Buzz(버즈): Block(구 Square)이 만든 무료 오픈소스 협업 워크스페이스. 사람과 AI 에이전트가 같은 채널에서 함께 일하도록 설계됐고, buzz.xyz에서 바로 쓸 수 있습니다.
Buzz가 대체 뭔가요
겉으로 보면 Slack과 비슷합니다. 채널이 있고 스레드가 있고 DM과 음성 통화, 미디어 공유, 검색이 됩니다. 처음 켜면 "요즘 팀 채팅 앱이랑 똑같네" 싶습니다.
차이는 그 방 안에 앉아 있는 존재입니다. Buzz에서는 AI 에이전트가 사람 옆자리에 "멤버"로 함께 있습니다. 관리자가 부르면 답만 하고 사라지는 챗봇이 아니라, 채널에 정식으로 소속된 구성원입니다.
Block은 이 방향을 지난 2년간 여러 AI 도구를 오픈소스로 만들며 얻은 결론이라고 밝혔습니다. 가장 생산적인 순간은 누군가 AI에게 도움을 요청할 때가 아니라, 사람과 에이전트가 같은 방에서 같은 것을 공유된 맥락으로 함께 붙잡고 있을 때 온다는 것입니다.
에이전트가 봇이 아니라 멤버라는 말의 뜻
핵심은 신원입니다. Buzz의 에이전트는 사람과 똑같이 자기만의 키(신원), 자기가 속한 채널, 자기 행동 기록(감사 로그)을 가집니다.
감사 로그(audit trail): 누가 언제 무엇을 했는지 남는 서명된 기록. 사람이 한 일이든 에이전트가 한 일이든 똑같은 형태로 남아, 나중에 "왜 이렇게 됐지"를 추적할 수 있습니다.
권한을 플래그로 켜고 끄는 방식이 아닙니다. 신입 팀원에게 "너는 이 채널까지만 봐"라고 정해 주듯, 에이전트도 신원으로 범위가 정해집니다. 그래서 버그 하나를 맡기더라도 회사 전체 열쇠를 넘길 필요가 없습니다. 그 에이전트가 속한 채널과 그 에이전트의 감사 로그 안에서만 움직입니다.
에이전트가 방 안에서 실제로 할 수 있는 일도 사람과 거의 같습니다. 채널을 만들고, 저장소를 열고, 패치를 보내고, 코드를 리뷰하고, 워크플로우를 실행하고, 캔버스를 편집하고, 음성 허들에 들어오고, 다른 에이전트를 조율합니다.
브랜치가 방이 되고 릴리스가 스스로 쓰인다
Buzz가 보여 준 세 가지 장면이 구조를 잘 설명합니다.
첫째, 사고 기억입니다. 새벽 2시에 "이 에러 예전에 본 적 있나요"라고 물으면, 채널을 지켜보던 에이전트가 6개월치 히스토리를 뒤져 관련 스레드와 근본 원인, 그때의 수정을 인용해 답합니다. 느낌이 아니라 근거를 붙여서입니다.
둘째, 방이 된 브랜치입니다. 피처 브랜치를 열면 채널이 하나 생깁니다. 패치가 이벤트로 올라오고, CI가 결과를 게시하고, 에이전트가 1차 리뷰를 돌리고, 팀원이 관심 있는 부분에 반응을 답니다. 머지 결정이 그 근거들과 같은 방에 남습니다. 채널 자체가 "이 코드가 왜 존재하는지"의 기록이 됩니다.
셋째, 스스로 쓰이는 릴리스입니다. 태그가 찍히면 워크플로우가 발동합니다. 에이전트가 머지된 PR들을 읽어 릴리스 노트 초안을 쓰고, 사람이 반응 하나로 승인하면 배포됩니다. 모든 단계가 서명되고 검색됩니다.
이게 가능한 이유는 하나의 로그 덕분입니다.
Nostr(노스터): 서명된 이벤트를 relay라는 서버에 쌓는 개방 프로토콜. Buzz는 메시지, 반응, 워크플로우 단계, 리뷰 승인, git 이벤트를 전부 이 위에 같은 형태로 올립니다.
기존 팀은 채팅, 코드 저장소, CI 대시보드, 릴리스 도구, 검색을 서로 다른 탭 일곱 개로 흩어 씁니다. Buzz의 베팅은 이 전부를 하나의 기질 위에 올리면 각 탭이 서로를 아는 척하지 않아도 된다는 것입니다.
기술 구성과 성숙도
주력 언어는 Rust입니다. 데스크톱 앱은 Tauri와 React로 만들었고, 모바일은 Flutter로 개발 중입니다. 에이전트가 붙는 통로는 buzz-cli(JSON을 넣으면 JSON이 나오는 명령줄 도구)와 ACP 하네스입니다. 여기에는 Goose, Codex, Claude Code가 연결됩니다. 워크플로우는 YAML로 정의하고 메시지, 반응, 스케줄, 웹훅으로 발동합니다. git은 NIP-34라는 방식으로 이벤트가 됩니다.
라이선스는 Apache 2.0이고, 공개 3일 만에 깃허브 별이 8천 개를 넘었습니다.
주목할 점은 Buzz가 자기 성숙도를 솔직하게 세 칸으로 나눠 밝혔다는 것입니다. relay와 채널, 스레드, DM, 검색, 감사 로그, 데스크톱 앱, buzz-cli는 지금 동작합니다. 모바일 클라이언트와 워크플로우 승인 게이트는 배선 중입니다. relay 간 평판 시스템과 푸시 알림은 아직 의견만 있고 코드는 대기 중입니다. README는 마지막 칸을 두고 "컴플라이언스 계획에 넣지 말라"고 스스로 경고합니다.
커뮤니티는 냉정하게 갈렸다
과장 없이 정리하면, 반응은 양분됐습니다. Hacker News에서는 374포인트에 331개 댓글이 달릴 만큼 크게 논의됐습니다.
호의적인 쪽은 개방 프로토콜과 감사 추적을 높이 삽니다. Slack이 IRC의 한계 때문에 생겼듯, AI 에이전트가 제대로 쓰이려면 채팅이 개방 프로토콜을 품어야 한다는 시각입니다.
회의적인 쪽의 지적도 날카롭습니다. "마케팅 수사를 빼면 결국 채팅방의 봇 아니냐"는 냉소가 있었고, Slack에서 일한다는 사람은 "에이전트가 다 보는 건 멋지지만, 어떤 걸 특정 사람에게만 비공개로 하고 싶어지는 순간 여러 에이전트가 데이터를 새게 만들지 않도록 막아야 한다"고 짚었습니다. 야심이 오히려 발목일 수 있다는 말도 나왔습니다. 이렇게 통합된 도구는 점진적으로 도입하기가 어렵다는 것입니다.
정리하면 야심은 인정받았고, 실효성과 프라이버시는 아직 물음표입니다.
QJC 관점에서 왜 흥미로운가
Buzz의 그림은 QJC가 이미 하고 있는 일과 정확히 겹칩니다. 저희는 Claude Code, Codex, Hermes 에이전트에게 신원을 주고, 감사 로그를 남기고, 회사 운영을 함께 맡깁니다. 에이전트를 봇이 아니라 팀원급으로 다루는 방식입니다.
Buzz는 그 조각들을 하나의 개방 프로토콜로 묶어, 자기 서버에 직접 올려 쓰는 형태로 제시했습니다. 지금 당장 이걸 도입하자는 이야기가 아니라, 사람과 에이전트가 한 방에서 일하는 구조가 어디까지 표준이 될지 지켜볼 좋은 참고점이라는 뜻입니다.
자주 묻는 질문
Buzz는 무료인가요? 네. 무료 오픈소스이고 Apache 2.0 라이선스입니다. buzz.xyz에서 바로 쓰거나 소스로 직접 서버를 세울 수 있습니다.
Slack이나 Discord와 뭐가 다른가요? 겉모습은 비슷하지만, AI 에이전트가 봇이 아니라 정식 멤버로 참여하고, 채팅과 코드 저장소와 CI와 릴리스가 하나의 서명된 이벤트 로그 위에 올라간다는 점이 다릅니다.
바로 실무에 써도 되나요? 핵심 기능은 동작하지만 모바일과 일부 승인 게이트는 개발 중입니다. 지금은 실험과 관찰에 적합하고, 미션 크리티컬한 운영에 바로 얹기에는 이릅니다.
QJC는 Buzz를 도입하나요? 현재는 도입이 아니라 관찰 대상입니다. 다만 사람과 에이전트가 같은 방에서 일한다는 방향은 QJC가 이미 실천하는 운영 방식과 맞닿아 있습니다.
참고자료
https://github.com/block/buzz https://block.xyz/inside/introducing-buzz-where-humans-and-agents-work-together https://buzz.xyz https://engineering.block.xyz/blog/buzz https://news.ycombinator.com/item?id=48995213

