채팅방에서 코드까지, Buzz는 팀의 일을 한곳에 모으려 한다

Block의 Buzz는 사람과 AI가 함께 일하는 공간입니다. 채팅을 하다가 계획을 세우고, 코드를 고치고, 검토하고, 배포하는 일까지 한곳에서 이어가려 합니다.

겉으로는 Slack, GitHub, CI 도구를 합친 것처럼 보입니다. 하지만 Buzz가 바꾸려는 것은 화면의 수가 아닙니다. 일을 나누는 방식 자체입니다.

Buzz는 어떻게 작동하나

Buzz에는 채널이 있습니다. Slack의 채널과 비슷하지만, 대화만 하는 곳은 아닙니다. 프로젝트의 코드, 작업 과정, AI의 답변, 검토 결과를 모두 모아두는 방입니다.

AI도 이 방의 멤버입니다. 뒤에서 몰래 실행되는 자동화가 아니라, 이름과 계정을 가진 팀원처럼 들어옵니다. AI가 무엇을 했는지도 기록으로 남습니다.

Buzz 채널에서 사람과 에이전트가 같은 프로젝트를 조율하는 화면

출처: Block / Buzz GitHub 저장소. 사람과 AI가 같은 채널에 들어와 있는 화면.

Buzz의 공식 저장소는 이 기록을 이벤트 로그라고 부릅니다. 이벤트 로그는 “누가, 언제, 무엇을 했는지”를 차례대로 남기는 기록입니다. 메시지, 반응, 코드 변경, 검토, 승인도 같은 방식으로 저장합니다.

실제로 일이 어떻게 달라지나

Buzz가 보여주는 예시는 세 가지입니다.

오류를 다시 찾기

새벽에 같은 오류가 또 생겼다고 해보겠습니다. 채널에 “이 오류를 예전에 본 적 있나?”라고 물으면 AI가 지난 기록을 찾아봅니다.

관련된 대화, 원인, 해결 방법을 모아 같은 채널에 답합니다. 어느 팀원이 마지막으로 이 코드를 고쳤는지도 알려줄 수 있습니다.

지금은 이런 일이 여러 곳에 흩어져 있습니다. Slack에서 대화를 찾고, GitHub에서 코드를 찾고, 문서에서 해결 방법을 찾아야 합니다. Buzz는 그 과정을 한곳으로 가져오려 합니다.

코드 작업이 방이 되기

기능을 만들기 위해 새 코드 갈래, 즉 브랜치를 만들면 그 작업을 위한 채널이 생깁니다.

그 채널에서 코드를 올리고, AI가 먼저 검토하고, CI가 테스트 결과를 남기고, 사람이 의견을 보탭니다. 마지막 결정도 같은 방에 남습니다.

이렇게 되면 나중에 “왜 이렇게 고쳤지?”라고 물었을 때 코드만 볼 필요가 없습니다. 코드가 만들어진 대화와 결정까지 함께 볼 수 있습니다.

배포 과정도 이어지기

새 버전을 만들 때 AI가 바뀐 코드를 읽고 배포 안내문을 먼저 씁니다. 사람이 내용을 확인하고 승인하면 다음 단계로 넘어갑니다.

완료된 결과도 다시 채널에 남습니다. 질문, 코드, 검토, 배포가 각각 다른 도구에 흩어지지 않는 구조입니다.

Buzz에서 영상의 특정 장면에 댓글을 붙이는 화면

출처: Block / Buzz GitHub 저장소. 영상의 특정 장면에 연결된 댓글 화면.

디자인 관점에서 보면

Buzz의 핵심은 기능을 많이 넣는 데 있지 않습니다. 일의 방을 다시 만드는 데 있습니다.

지금의 팀은 보통 이렇게 일합니다.

대화는 Slack에서 함
코드는 GitHub에서 관리함
테스트 결과는 CI 화면에서 확인함
결정은 PR이나 문서에 남음

각 도구는 잘 작동합니다. 문제는 사람이 그 사이를 계속 오가야 한다는 점입니다. 대화 내용을 코드 설명에 다시 붙여 넣고, 코드 링크를 채널에 다시 올리고, 결정 내용을 문서에 다시 정리해야 합니다.

Buzz는 이 연결 작업을 줄이려 합니다. 채널 하나가 대화방이면서 작업 기록이고, 코드 검토 공간이 되도록 만드는 것임.

AI를 숨기지 않는 점도 눈에 띕니다. AI가 답을 내놓기만 하는 것이 아니라, 어떤 일을 했고 어디까지 실행했는지를 같은 화면에서 보여주려 합니다. 이 방식이 잘 작동하면 AI를 믿을지 말지 판단하기 쉬워집니다.

반대로 문제가 생길 수도 있습니다. AI가 남기는 기록이 너무 많으면 채널이 알림과 작업 로그로 가득 찰 수 있습니다. 무엇을 바로 보여주고, 무엇을 접어둘지 정하는 디자인이 중요해집니다.

워크플로우는 어떻게 달라지나

Buzz에서는 AI에게 매번 긴 설명을 복사해 줄 필요가 줄어듭니다. 채널에 이전 결정과 코드, 실패 기록이 남아 있기 때문입니다.

그래서 앞으로는 AI에게 질문을 잘 쓰는 능력만큼, 팀의 기록을 잘 남기는 능력이 중요해질 수 있습니다. 어떤 결정은 채널에 남기고, 어떤 내용은 문서로 정리할지 정해야 합니다.

Buzz는 워크플로우도 지원합니다. 워크플로우는 “어떤 일이 일어나면 다음에 무엇을 할지” 미리 정해두는 규칙입니다.

예를 들면 다음과 같습니다.

코드가 올라옴
AI가 먼저 확인함
테스트를 실행함
사람이 승인함
배포함

메시지, 반응, 일정, 웹훅 같은 신호로 워크플로우를 시작할 수 있습니다. 웹훅은 다른 서비스에서 “새 일이 생겼다”고 보내는 알림입니다.

다만 모든 기능이 완성된 것은 아닙니다. 공식 README에 따르면 승인 후 작업을 멈췄다가 다시 이어가는 기능은 아직 연결 중입니다. 따라서 Buzz가 그리고 있는 전체 그림과 지금 바로 쓸 수 있는 기능은 구분해서 봐야 합니다.

소유권과 보안

Buzz는 relay라는 서버를 중심으로 작동합니다. relay는 메시지와 파일, 프로젝트 기록을 보관하고 전달하는 서버입니다. 직접 서버를 운영할 수도 있고, Block이 운영하는 서버를 사용할 수도 있습니다.

Buzz는 Nostr라는 기술을 사용합니다. 여기서는 계정 대신 키로 사용자를 확인합니다. AI도 자기 키를 가질 수 있습니다. 그래서 AI가 남긴 답변이나 코드도 어느 AI가 했는지 기록할 수 있습니다.

대신 키를 잃어버리면 비밀번호를 다시 만드는 것처럼 간단하지 않습니다. 공식 지원 문서도 개인 키와 백업을 잘 보관하라고 안내합니다.

Block이 운영하는 커뮤니티의 메시지와 파일은 종단간 암호화가 아닙니다. 종단간 암호화는 보내는 사람과 받는 사람만 내용을 볼 수 있게 하는 방식입니다. Buzz의 호스팅 서버 운영자는 필요한 경우 내용을 볼 수 있습니다.

현재 Block 호스팅 커뮤니티는 초기 이용 기간에 무료입니다. 커뮤니티 하나당 미디어 저장공간은 5GB이고, 콘텐츠는 365일 동안 보관됩니다. 이 조건도 제품을 사용할 때 확인해야 할 부분입니다.

crit의 관점

Buzz는 AI를 채팅창에 붙이는 도구라기보다, AI가 팀의 일하는 공간에 들어오는 방식을 다시 설계하려는 제품입니다.

좋은 점은 분명합니다. 대화와 코드와 결정이 이어지면, 일이 왜 그렇게 진행됐는지 따라가기 쉬워집니다. AI가 한 일도 기록으로 남기 때문에 단순히 “AI가 처리했다”로 끝나지 않습니다.

하지만 기록이 많아진다고 팀이 자동으로 더 잘 일하는 것은 아닙니다. 사람이 읽어야 할 결정과 AI가 남겨야 할 실행 기록을 나누는 화면이 필요합니다. AI를 팀원처럼 보이게 하는 것과, 사람과 다른 책임을 분명히 보여주는 것도 함께 풀어야 합니다.

다르게 볼 부분

도구를 한곳에 모아도 복잡성이 사라지는 것은 아닙니다. 복잡성이 채널, 키, 규칙 설정으로 옮겨갈 수 있습니다.
브랜치마다 채널이 생기면 작업은 잘 나뉘지만, 프로젝트 전체를 이해하기는 더 어려워질 수 있습니다.
AI의 서명이 남는다고 해서 책임 문제가 모두 해결되지는 않습니다. 그 AI에게 어떤 권한을 줬는지도 함께 보여야 합니다.
직접 서버를 운영할 수 있다는 것은 장점이지만, 서버 관리라는 일이 새로 생깁니다.

남는 질문

AI가 남긴 기록이 많아졌을 때, 사람에게 꼭 필요한 내용만 어떻게 보여줄 것인가.
AI가 코드를 고치거나 배포할 때, 사람이 어디에서 멈추게 하고 확인해야 하는가.
365일 뒤 삭제되는 기록과 프로젝트의 장기 기억은 어떻게 함께 가져갈 것인가.
팀을 처음 방문한 사람에게 채널, 코드, 결정의 순서를 어떻게 보여줄 것인가.

출처: Buzz — Your people, your agents, your project — all in one place.

추가 자료: Block/buzz GitHub 저장소, README, VISION.md, Buzz Support