![[심층분석] 잭 도시의 다음 승부수, 사람과 AI가 '한 방'을 쓰는 워크스페이스 Buzz](/newsimg/CTJg5Yt1CnO2MNJs.jpg)
채팅방에 'AI 동료'가 정식 멤버로 합류한다면?
요즘 개발자들 사이에서 가장 뜨거운 질문 중 하나가 "AI 에이전트를 어디서, 어떻게 굴릴 것인가"인데요. Claude Code나 Codex 같은 코딩 에이전트가 터미널과 IDE를 점령한 지금, 다음 격전지는 의외로 '채팅방'이 될 것 같아요. 트위터 창업자 잭 도시가 이끄는 Block이 공개한 오픈소스 프로젝트 Buzz가 바로 그 신호탄이거든요.
Buzz는 스스로를 "hive mind communication platform", 그러니까 '벌집 사고(집단 지성) 커뮤니케이션 플랫폼'이라고 소개해요. 벌집에서 수많은 벌이 각자 일하면서도 하나의 군집처럼 움직이듯, 사람과 AI 에이전트가 한 공간에서 유기적으로 협업하는 그림을 그리고 있는 거죠. 공식 소개 문구가 이 프로젝트의 정체성을 딱 한 문장으로 보여줘요. "사람과 에이전트가 같은 방에서 함께 만들어가는, 당신이 소유한 릴레이 위의 워크스페이스."
이게 왜 중요하냐면요. 지금까지 우리가 슬랙이나 디스코드에서 봇을 쓰는 방식은 어디까지나 '손님 초대'였어요. 봇은 플랫폼이 허락한 API 범위 안에서만 움직이고, 요금 정책이나 약관이 바뀌면 하루아침에 쫓겨날 수도 있죠. 그런데 Buzz는 발상을 뒤집어서, 에이전트를 처음부터 사람과 동등한 정식 멤버로 설계한 협업 공간이에요. AI가 팀의 일원이 되는 시대에 맞는 새로운 '사무실'을 만들겠다는 거예요.
아키텍처 뜯어보기: "URL이 곧 워크스페이스"
Buzz의 구조에서 가장 눈에 띄는 개념은 릴레이(relay)예요. 릴레이가 뭐냐면, 쉽게 말해 모든 메시지가 거쳐 가는 중계 서버예요. 우체국이라고 생각하면 편한데요. 슬랙은 전 세계에 하나뿐인 거대한 우체국(슬랙 본사 서버)을 모두가 같이 쓰는 구조라면, Buzz는 팀마다 자기 우체국을 직접 차릴 수 있는 구조예요. 저장소에 NOSTR.md 파일이 있는 것에서 알 수 있듯 탈중앙 메시징 프로토콜인 Nostr를 기반에 깔고 있는데요. Nostr는 계정을 중앙 서버가 아니라 암호 키 쌍으로 관리하고, 누구나 릴레이를 운영할 수 있게 하는 오픈 프로토콜이에요.
재미있는 설계 원칙이 하나 있는데, 바로 "URL이 워크스페이스의 기준(authoritative)"이라는 거예요. 기본 구성인 단일 릴레이 셋업에서는 릴레이 URL 하나가 곧 하나의 커뮤니티를 가리켜요. 호스팅 사업자가 여러 도메인 뒤에서 여러 커뮤니티를 운영할 수도 있지만, 클라이언트 입장에서 규칙은 항상 같아요. 주소창에 입력한 URL이 곧 그 워크스페이스의 신원이라는 거죠. 복잡한 테넌트(입주사) 관리 로직을 URL 하나로 단순화한, 꽤 우아한 접근이에요.
기술 스택도 흥미로워요. 핵심 서버는 Rust로 작성됐어요(crates 디렉토리와 Cargo.toml이 그 증거죠). 러스트는 메모리 안전성과 고성능을 동시에 잡는 언어라서, 수많은 사람과 에이전트가 쉴 새 없이 메시지를 주고받는 실시간 릴레이 서버에 딱 맞는 선택이에요. 그 위에 웹, 데스크톱, 모바일, 관리자 웹까지 클라이언트를 전부 갖추고 있고, 마이그레이션과 배포 구성(deploy, docker-compose)까지 포함된, 생각보다 '완성형'에 가까운 프로젝트예요. 커밋이 1,700개를 넘는다는 것도 이게 하루아침에 나온 데모가 아니라는 걸 보여주고요.
그리고 진짜 재미있는 부분이 있어요. 저장소 루트에 .claude/skills, .codex/skills, .goose/skills, .agents/skills 디렉토리가 나란히 있거든요. 이게 뭐냐면, Claude Code, Codex, 그리고 Block이 직접 만든 오픈소스 에이전트인 Goose 같은 여러 AI 코딩 에이전트가 이 프로젝트를 함께 개발할 수 있도록 각 에이전트용 '업무 매뉴얼'을 미리 깔아둔 거예요. AGENTS.md, CLAUDE.md 같은 문서도 있고요. 즉 Buzz는 "사람과 에이전트가 함께 만든다"는 비전을 남에게 팔기 전에, 자기 저장소에서 이미 실천하고 있는 셈이에요.
슬랙 봇이랑 뭐가 다른데?
"그래서 슬랙에 봇 붙이는 거랑 뭐가 달라?"라는 질문이 자연스럽게 나올 텐데요. 비유하자면 이래요. 슬랙 봇은 출입증을 받아서 가끔 사무실에 들르는 외부 협력사 직원이에요. 회사(플랫폼)가 정한 출입 규칙을 따라야 하고, 규칙이 바뀌면 못 들어올 수도 있죠. 반면 Buzz의 에이전트는 자기 자리와 사원증이 있는 정직원이에요. 사람과 같은 방에 상주하면서, 같은 메시지 스트림을 보고, 같은 프로젝트 문맥을 공유해요.
기존 대안들과 비교해보면 포지션이 더 선명해져요.
- 슬랙/팀즈 + 코파일럿: 가장 편하지만, 데이터가 벤더의 클라우드에 있고 AI 기능도 벤더가 정한 형태로만 써야 해요. 구독료도 계속 나가고요.
- Matrix/Element: 셀프호스팅 가능한 오픈 프로토콜 메신저라는 점은 비슷한데, 어디까지나 '사람 간 대화'가 중심이고 에이전트는 여전히 봇 취급이에요.
- Buzz: 셀프호스팅 + 오픈 프로토콜에 더해, 에이전트 협업 자체를 1급 시민으로 설계했어요. VISION_AGENT, VISION_MODERATION, VISION_MESH 같은 로드맵 문서를 보면 에이전트 활동 관리, 여러 릴레이를 잇는 메시(mesh) 구조까지 내다보고 있고요.
한국 개발자에게는 어떤 의미일까?
구체적인 시나리오로 생각해볼게요.
시나리오 1: 에이전트 여러 개를 굴리는 소규모 팀. 요즘 스타트업에서는 한 사람이 코딩 에이전트 두세 개를 병렬로 돌리는 게 흔해졌는데요. 문제는 이 작업들이 각자 터미널 안에 갇혀 있어서, 옆자리 동료는 내 에이전트가 뭘 하고 있는지 전혀 모른다는 거예요. Buzz 같은 구조에서는 에이전트가 채팅방 멤버니까, "지금 결제 모듈 리팩토링 중, 테스트 3개 실패" 같은 진행 상황이 팀 전체에 실시간으로 투명하게 공유돼요. 에이전트 작업의 '가시성' 문제를 협업 도구 차원에서 푸는 거죠.
시나리오 2: 보안이 민감한 조직. 금융권이나 공공기관처럼 외부 SaaS에 데이터를 못 올리는 곳에서는 AI 협업 도구 도입 자체가 벽에 막히는 경우가 많잖아요. 셀프호스팅이 기본인 Buzz는 사내망 안에서 사람-에이전트 협업 공간을 구축할 수 있는 선택지가 될 수 있어요. 물론 아직 초기 프로젝트라 당장 프로덕션에 넣기보다는, PoC(개념 검증)로 가능성을 타진해보는 단계가 현실적이겠지만요.
도입 전에 고려할 점도 분명 있어요. 릴레이를 직접 운영한다는 건 백업, 모니터링, 업그레이드를 내가 책임진다는 뜻이고, Nostr 프로토콜은 국내에서 아직 생소한 편이라 레퍼런스가 적어요. 학습 순서를 제안하자면 이래요. 먼저 저장소의 docker-compose로 로컬에 띄워서 감을 잡고, 그다음 NOSTR.md와 ARCHITECTURE.md를 읽으면서 릴레이 모델을 이해하고, 마지막으로 skills 디렉토리를 참고해 내가 쓰는 에이전트를 방에 붙여보는 순서요. 러스트를 몰라도 사용자로 시작하는 데는 전혀 지장이 없어요.
마무리: '에이전트 네이티브' 협업 도구의 시작
슬랙이 이메일 시대의 협업을 재정의했다면, 다음 세대 협업 도구는 "AI 에이전트가 팀원인 시대"를 전제로 다시 설계될 거예요. Buzz는 그 방향으로 가장 급진적으로 치고 나간 시도 중 하나고요. 성공 여부와 별개로, "에이전트를 손님이 아니라 멤버로 대하는 설계"와 "그 인프라를 팀이 직접 소유하는 구조"라는 두 가지 질문은 앞으로 모든 협업 도구가 답해야 할 숙제가 될 거라고 봐요.
여러분 팀은 어떤가요? 에이전트가 채팅방에 상주하면서 작업 상황을 공유한다면 생산성이 올라갈까요, 아니면 알림 지옥이 하나 더 늘어날 뿐일까요? 그리고 사내 커뮤니케이션 인프라, 직접 소유할 가치가 있다고 생각하시나요? 댓글로 의견 나눠주세요.
🔗 출처: GitHub
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공