Buzz는 무엇인가
Buzz는 Block이 2026년 7월 공개한 오픈소스 협업 앱이다. Block은 잭 도시(Jack Dorsey)가 창업한 회사이고, Buzz는 Apache 2.0 라이선스로 소스가 전부 공개돼 있다. macOS·Windows·Linux용 데스크톱 앱이 각각 제공되며, 직접 서버를 띄워 자체 호스팅할 수도 있다. Slack을 쓰던 사람이라면 화면에서 낯선 것이 거의 없다 — 왼쪽에 채널 목록, 가운데 대화, 스레드, 다이렉트 메시지, 전체 검색까지 구조가 같다.
다른 점은 멤버 목록에 있다. Buzz에서 AI 에이전트는 채널에 붙는 봇이 아니라 사람과 같은 자격의 멤버다. 에이전트마다 고유한 신원 키가 발급되고, 누가 무엇을 말했고 어떤 명령을 실행했는지가 전부 기록으로 남는다. 신원과 기록은 Nostr라는 공개 메시징 프로토콜 위에 얹혀 있는데, 쓰는 입장에서 이 이름을 외울 필요는 없다. 실무에서 체감되는 결과는 하나다 — 에이전트도 초대하고 내보내고 멘션할 수 있는 '사람 취급' 대상이 된다.
정리하면 Buzz가 파는 것은 새 모델이 아니라 '여러 에이전트가 사람과 같은 자리에서 일하게 하는 판'이다. 그래서 이 글도 무엇을 설치하고 무엇을 눌러야 하는지를 순서대로 따라간다.
왜 API 키가 아니라 CLI를 물어보나
설치하고 나면 온보딩 3단계에서 이런 문장이 나온다. "Buzz checks for command-line harnesses on this machine." 이 컴퓨터에 깔린 명령줄 도구를 찾는다는 뜻이다. 여기서 하네스(harness)란 모델을 감싸서 실제로 일을 시키는 실행기, 쉽게 말해 이미 쓰고 있는 Claude Code·Codex·goose 같은 CLI 프로그램이다.
이게 왜 중요하냐면, 대부분의 멀티 에이전트 도구는 모델 API 키를 요구하고 토큰 단위로 따로 과금된다. Buzz는 그 대신 이미 로그인이 끝난 CLI를 붙인다. Claude Code에 Max 요금제로 로그인돼 있으면 그 구독이 그대로 쓰이고, Codex도 마찬가지다. 에이전트를 여섯 명 만들어 동시에 돌려도 새로 여는 계정이나 별도 종량 요금이 없다.
대가는 분명하다. 에이전트가 내 컴퓨터에서 돌기 때문에 그 컴퓨터가 켜져 있어야 한다. Buzz 설정에도 'Keep awake while agents are active'(에이전트가 도는 동안 컴퓨터가 잠들지 않게 막는) 항목이 따로 있을 정도다. 클라우드에 올려두고 노트북을 덮는 방식이 아니라, 내 기계를 작업장으로 쓰는 방식이라고 이해하면 된다.
1단계 — 내려받고 신원 키 만들기
먼저 데스크톱 앱을 내려받는다. 공식 사이트 buzz.xyz의 Get App 버튼이나 GitHub 저장소(github.com/block/buzz)의 릴리스 페이지에서 내 운영체제에 맞는 파일을 받으면 된다. 설치는 평범한 앱과 같고, 끝나면 실행한다.
처음 실행하면 계정을 만들면서 신원 키가 발급된다. 화면에는 'Your unique identity key has been created'라고 뜬다. 이 키는 로그인 비밀번호가 아니라 개인키다 — 화면 아래에도 "Never share your private key. Anyone with this key can impersonate you and access everything in your account"라고 적혀 있다. 이 키를 가진 사람은 나로 위장할 수 있다는 뜻이다.
Buzz는 이 키를 운영체제의 키체인에 넣어 두므로 매번 입력할 일은 없다. 다만 컴퓨터를 바꾸거나 초기화하면 계정을 되살릴 수단이 그 키뿐이다. 그래서 이 화면에서 그냥 Next를 누르고 넘어가지 말고, 옆의 'review backup options'를 눌러 백업 방법을 한 번 확인해 두는 편이 낫다. 개인키를 남에게 보내거나 채팅·문서에 붙여 넣는 일은 하지 않는다.
2단계 — 쓸 CLI(하네스) 연결하기
다음 화면이 이 글 맨 위의 'Set up your agent harnesses'다. Claude Code·Codex·Goose·Buzz 네 칸이 나오고, 각 칸 아래에 이 컴퓨터에서의 상태가 적힌다.
상태 문구는 세 가지로 갈린다. 'CLI not detected'는 그 도구가 아예 안 깔려 있다는 뜻이고, 'CLI detected; ACP adapter missing'은 도구는 있는데 Buzz와 말을 주고받는 어댑터가 없다는 뜻이다. 여기서 ACP(Agent Client Protocol)는 Buzz가 어느 회사 도구든 같은 방식으로 붙이기 위해 쓰는 공개 규약이다. Buzz 자체 에이전트는 처음부터 READY로 뜬다.
칸 아래 INSTALL 버튼을 누르면 부족한 것을 알아서 채운다 — CLI가 없으면 CLI를 설치하고, 어댑터만 없으면 어댑터를 붙인다. 여러 칸을 동시에 눌러도 되고, 진행 상황이 그 자리에서 INSTALLING으로 바뀐다. 최소 하나만 READY가 되면 Next로 넘어갈 수 있다.
그다음 화면은 'Configure your default model settings'다. 기본 하네스(예: Claude Code)와 기본 모델(예: opus[1m])을 고르는 곳인데, 여기서 정한 값은 말 그대로 기본값이고 에이전트마다 따로 바꿀 수 있다. 지금 고민하지 말고 평소 쓰는 조합으로 넘어가면 된다.
3단계 — 커뮤니티 만들기
다음은 커뮤니티다. Slack의 워크스페이스에 해당하는 단위로, 이미 초대받은 곳이 있으면 Join, 처음이면 'Create a community'를 고른다.
커뮤니티를 만들려면 계정 가입이 필요하다. 이메일 주소와 비밀번호를 넣으면 확인 메일이 오고, 메일에 적힌 인증 번호를 앱에 붙여 넣으면 가입이 끝난다. 그 뒤 커뮤니티 이름과 내 표시 이름·이모지를 정하고 밝은 톤·어두운 톤 중 하나를 고르면 준비가 끝난다. 서버를 직접 운영하고 싶으면 이 대신 자체 호스팅으로 갈 수도 있다.
만들고 나면 Welcome 채널이 먼저 열리고 기본 에이전트가 인사를 건넨다. 여기서 바로 말을 걸어 볼 수 있다 — 예를 들어 "간단한 애플 스타일 버튼 웹사이트를 HTML로 만들어 줘"라고 보내면 아래쪽에 '에이전트 작동 중' 표시가 뜨고, 이름을 누르면 무슨 작업을 하고 있는지 펼쳐 볼 수 있다. 끝나면 로컬 서버 주소가 결과로 돌아온다.
나중에 CLI를 더 붙이거나, 안 잡힐 때
온보딩에서 건너뛴 도구는 나중에 붙이면 된다. 왼쪽 아래 프로필에서 설정으로 들어가 App 항목의 Agents를 누르면 'Agent runtimes' 목록이 나온다. 이 컴퓨터에서 Buzz가 쓸 수 있는 도구들이고, 붙은 것은 Ready로 표시된다.
목록 아래 'Add runtimes'를 누르면 추가로 붙일 수 있는 도구가 더 나온다. 이미 깔아 둔 다른 CLI가 있으면 여기서 추가한다. 오른쪽 위 'Check again'은 방금 설치한 도구를 다시 훑어보라는 버튼이다.
분명히 깔았는데 목록에서 안 잡히는 경우가 있는데, 대개 실행 경로(PATH) 문제다. 이럴 때 쓸 만한 우회가 하나 있다 — 화면의 상태 문구를 복사해서 그 CLI 자신에게 물어보는 것이다. 참고한 영상에서는 Kimi 계열 CLI가 안 잡히자 해당 도구에게 "연동이 안 된다고 하는데 확인해 보고 가능하면 경로를 고쳐서 적용해 달라"고 시켰고, 그렇게 붙였다. 에이전트를 쓰는 앱이니 설정 문제도 에이전트에게 넘기면 된다.
같은 설정 화면 아래에는 'Agent defaults'가 있다. 하네스·모델·작업 강도 같은 값을 여기서 한 번에 정해 두면 개별 에이전트가 그것을 물려받고, 에이전트별 설정이 있으면 그쪽이 항상 우선한다.
4단계 — 에이전트 만들기
이제 팀원을 만든다. 왼쪽 Agents 화면이나 채널 안의 'Create agent' 카드에서 시작한다. 입력할 것은 셋이다.
첫째는 Agent name, 곧 이름이다. '팀장', '워런 버핏', '프론트엔드 개발자'처럼 역할이 바로 읽히는 이름을 쓰는 편이 낫다. 채널에서 @이름으로 부르게 되기 때문이다. 이모지도 하나 붙일 수 있다.
둘째는 Agent instructions, 곧 지시문이다. 이 에이전트가 무엇을 하는 사람인지 평문으로 적는다. 여기 적힌 내용이 그 에이전트의 성격과 판단 기준이 되므로, 나중에 결과가 마음에 안 들면 대개 여기를 고치는 것이 가장 빠른 수정이다.
셋째는 AI configuration이다. 'Use harness defaults'를 고르면 앞서 정한 기본값을 그대로 쓰고, 'Customize for this agent'를 고르면 이 에이전트만 다른 하네스와 모델을 쓴다. 만들기를 누르면 이 에이전트에도 고유한 키가 발급되고 상태가 Ready로 바뀐다.
너는 작업을 하지 않고 해당 채널에 있는 전문가들을 활용해서
최종적으로 작업을 매니징 하는 역할을 할거야에이전트마다 다른 모델을 물리기
'Customize for this agent'를 누르면 하네스를 고르는 칸과 모델을 고르는 칸이 나온다. 모델 목록은 고른 하네스가 제공하는 것으로 채워지고, 항목이 많으면 위 검색창으로 걸러 쓴다. 같은 모델이라도 medium·high·max처럼 생각의 깊이를 나타내는 등급이 따로 붙는 경우가 있는데, 등급이 높을수록 오래 생각하고 비용도 그만큼 든다.
이 화면이 Buzz에서 가장 실용적인 부분이다. 판단을 맡는 팀장에게는 무거운 모델을, 자료를 모아 오는 담당에게는 가벼운 모델을 물리면 같은 구독 안에서 역할별로 힘을 배분할 수 있다. 참고한 영상에서도 팀장·워런 버핏·피터 린치·벤저민 그레이엄 네 명에게 각각 다른 하네스와 모델을 붙였다.
모델은 나중에 언제든 바꿀 수 있다. 결과가 얕으면 지시문을 먼저 고치고, 그다음에 모델 등급을 올리는 순서가 낭비가 적다.
5단계 — 채널 만들고 팀 초대하기
채널은 일감 하나에 하나씩 만드는 편이 좋다. 왼쪽 Channels 옆의 새 채널 만들기를 눌러 이름을 정하고(예: '주식분석기'), 공개(public)와 비공개(private) 중 하나를 고른다.
새 채널에는 'Create agent'와 'Add people' 카드가 크게 뜬다. 앞에서 만들어 둔 에이전트를 부르려면 오른쪽 위 멤버 아이콘을 눌러 채널 멤버 창을 열고 이름을 검색해 초대한다. 여기서 새 에이전트를 바로 만들어 넣을 수도 있다. 초대된 에이전트는 사람 멤버와 같은 목록에 'agent' 표시와 함께 뜬다.
구성은 단순하게 시작하는 편이 낫다. 참고한 영상의 주식 분석 채널은 팀장 하나에 관점이 다른 전문가 셋(워런 버핏·피터 린치·벤저민 그레이엄)이었고, 웹페이지 채널은 팀장에 UX/UI 디자이너·프론트엔드·백엔드 셋이었다. 팀장은 직접 일하지 않고 나눠 주고 취합하는 역할만 맡는다.
6단계 — 지시하고, 무슨 일이 벌어지는지 보기
지시는 채널에 평범하게 쓰면 된다. 다만 앞에 @로 받을 사람을 지정한다. 예를 들어 "@팀장 지금 SK하이닉스와 삼성전자를 해당 채널 전문가에게 분석을 시켜 달라고 하고 결과를 줘"처럼 보낸다.
보내고 나면 에이전트 이름을 눌러 오른쪽 Activity 패널을 연다. Thinking 항목을 펼치면 이 에이전트가 무엇을 판단했는지, 어떤 명령을 실행했는지가 순서대로 보인다. 여기서 Buzz의 작동 방식이 드러난다 — 에이전트는 buzz 명령줄 도구로 채널을 읽고(messages get) 채널에 쓴다(messages send). 즉 채널 자체가 에이전트들의 통신 회선이고, 사람은 그 회선을 그대로 들여다보는 셈이다.
명령을 실제로 실행하기 전에는 'Permission requested' 창이 뜬다. Allow Once(이번만), Allow for Session(이번 세션 동안), Allow Commands Starting With(이 접두사로 시작하는 명령 전부), Reject 중에서 고른다. 처음에는 Allow Once로 무슨 명령이 오가는지 몇 번 지켜보고, 익숙해지면 세션 단위로 열어 주는 편이 안전하다.
buzz --format compact messages get --channel <채널 ID> --limit 50
buzz messages send --channel <채널 ID>실제로 어떻게 굴러가나 — 그리고 한계
지시를 받은 팀장은 채널 멤버를 먼저 읽고, 각 전문가에게 관점을 나눠 한 번에 멘션한다. 참고 영상의 주식 분석 사례에서는 워런 버핏에게 사업의 질과 장기 보유 리스크를, 피터 린치에게 성장률과 수요·실적 변화를, 벤저민 그레이엄에게 재무 안전성과 안전마진을 맡기고, 출처와 기준일을 명시하라는 공통 조건을 함께 걸었다.
그다음은 사람이 손대지 않아도 진행된다. 각 전문가가 스레드에 보고를 올리고, 팀장이 읽은 뒤 부족한 부분은 다시 요청한다. 영상의 주식 채널에서는 그렇게 34번의 주고받음이 오간 뒤 최종 결론이 나왔고, 웹페이지 채널에서는 24번이었다. 사람은 그 과정을 스레드에서 그대로 볼 수 있다.
한계도 분명하다. 영상 제작자의 결론이 정확한데, 지시문과 요청이 성기면 결과도 성기다. 웹페이지를 만든 쪽은 디자인 요구가 두루뭉술해 결과가 평범했고, "이런 작업은 차라리 모델 하나로 만드는 게 나을 수도 있다"는 평가가 나왔다. 여러 관점을 부딪혀야 이득이 생기는 일(분석·검토·리뷰)에는 팀이 유리하고, 결과물이 하나로 떨어져야 하는 일(한 벌의 코드·한 장의 디자인)에는 손이 여럿인 게 오히려 방해가 된다.
이 글의 화면들은 Hodu's AI Analysis Lab 채널의 Buzz 입문 영상에서 가져왔다. 실제 채널 구성과 에이전트 이름은 그 영상 제작자의 작업이다.
지금 해볼 순서
① buzz.xyz 또는 github.com/block/buzz 릴리스에서 내 운영체제용 앱을 내려받아 설치한다. ② 실행해 신원 키를 만들고 백업 방법을 확인해 둔다. ③ 'Set up your agent harnesses'에서 평소 쓰는 CLI 하나 이상을 READY로 만든다. ④ 커뮤니티를 만들고 Welcome 채널에서 아무 요청이나 한 번 던져 본다.
여기까지가 10분이면 끝난다. 팀을 굴리는 것은 그다음이다 — ⑤ 역할이 읽히는 이름과 지시문으로 에이전트를 셋 안팎 만들고, ⑥ 일감 하나짜리 채널을 만들어 전부 초대한 뒤 @팀장에게 한 문장으로 시킨다.
첫 판은 결과보다 과정을 보는 데 쓰는 편이 낫다. Activity 패널을 열어 두고 권한 창을 Allow Once로 받으면, 에이전트들이 어떤 명령으로 서로에게 일을 넘기는지가 그대로 보인다. 그 흐름을 한 번 보고 나면 지시문을 어디서 고쳐야 하는지도 같이 보인다.