Jack Dorsey, 팀 채팅·AI 에이전트·Git 호스팅을 결합한 Buzz 출시

 (runtimewire.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Block이 직원과 AI 에이전트, 대화, 소프트웨어 저장소를 하나의 신원 체계로 연결하는 오픈소스 워크스페이스 Buzz를 출시해 Slack과 GitHub 의존도를 줄이려 함
  • 메시지·반응·워크플로 단계·코드 이벤트·승인을 서명된 Nostr 이벤트로 저장하고, 사람과 에이전트에 키 쌍·채널 멤버십·감사 추적을 동일하게 부여함
  • 에이전트는 대화 검색부터 패치 제출·코드 검토·워크플로 실행까지 수행하며, Goose·Codex·Claude Code 하네스로 워크스페이스와 기반 모델을 분리함
  • 자체 호스팅과 데이터 소유권을 제공하지만 모든 읽기·쓰기가 단일 중앙 릴레이를 거치므로 운영자가 가용성·백업·보안·업그레이드를 책임져야 함
  • 채팅·코드 호스팅·자동화·검색·에이전트 조율을 한곳에 묶었지만 모바일 앱과 푸시 알림은 미완성이며, 도입률·가격·외부 고객 수도 공개되지 않음

사람과 에이전트를 잇는 통합 워크스페이스

  • Buzz는 직원, AI 에이전트, 대화, 소프트웨어 저장소를 하나의 신원 체계 아래 두는 자체 호스팅 가능 오픈소스 워크스페이스임
    • Jack Dorsey는 이를 통해 Block의 Slack 및 GitHub 의존도를 줄이려 함
    • Block의 공개 저장소에는 사내 릴레이와 에이전트 제공자에 맞춘 별도 내부 빌드도 문서화돼 있음
  • 자체 호스팅 Nostr 릴레이를 중심으로 메시지, 반응, 워크플로 단계, 코드 이벤트, 승인을 암호학적으로 서명된 이벤트로 저장함
    • 직원과 에이전트 모두 고유 키 쌍, 채널 멤버십, 감사 추적을 가짐
    • 공유 신원과 서명된 이벤트 덕분에 에이전트가 기존 챗봇을 넘어 책임을 추적할 수 있는 구성원으로 참여하는 구조임
  • 에이전트는 이전 대화 검색, 저장소 열람, 패치 제출, 코드 검토, 워크플로 실행, 공유 캔버스 편집, 채널 생성을 수행할 수 있음
    • 에이전트용 CLI와 Goose·Codex·Claude Code 하네스를 제공해 기반 모델을 워크스페이스에서 분리함
  • 프로젝트 명세는 표준 Git Smart HTTP를 사용하는 내장 소프트웨어 포지를 정의함
    • 기능 브랜치를 전용 채널로 만들고 패치, 지속적 통합 결과, 검토 의견, 병합 결정을 같은 기록에 보존함
    • 저장소, 대화, 워크플로 이력은 하나의 검색 인덱스를 공유함
  • 현재 채널, 스레드, 다이렉트 메시지, 공유 캔버스, 미디어, 검색, 감사 로그, 데스크톱 앱, YAML 기반 워크플로가 작동함
    • macOS·Windows·Linux용 패키지 빌드를 제공하며 Apache 2.0 라이선스를 적용함

단일 릴레이 구조와 초기 제품의 제약

  • Dorsey는 Buzz를 탈중앙·자주권형 제품으로 소개했지만, 아키텍처 문서에 따르면 현재 릴레이 간 P2P 이벤트 교환, 가십 계층, 복제 기능은 없음
    • 모든 읽기와 쓰기는 사용자를 인증하고 서명을 검증하며 이벤트를 저장·배포하는 단일 릴레이를 통과함
    • 조직은 자체 릴레이와 도메인·데이터를 소유하고 이식 가능한 Nostr 키 쌍을 쓸 수 있지만, 각 커뮤니티 안에서는 해당 릴레이가 권위 서버로 남음
    • 호스팅 사업자는 공유 인프라에서 서로 격리된 여러 커뮤니티를 운영할 수 있음
  • 자체 호스팅은 인프라와 데이터 위치에 대한 통제권을 주는 대신 가용성·백업·보안·업그레이드 책임을 운영자에게 넘김
    • 서명된 이벤트는 행위 귀속과 감사 추적을 지원하지만 서버 운영 위험까지 없애지는 않음
  • Buzz는 테스트와 개발에 사용할 수 있으나 문서에서 반복적으로 미완성 제품으로 분류됨
    • 모바일 클라이언트는 개발 중이며 푸시 알림은 아직 제공되지 않음
    • 워크플로 승인 게이트에는 데이터베이스·API·인터페이스 구성요소가 있지만 완성된 실행 경로가 없음
    • 데스크톱 버전 0.4.21은 7월 21일 에이전트 제어, 인증, 워크스페이스 온보딩 관련 기능 추가와 수정 사항을 담아 출시됨
  • 하나의 이벤트 체계로 채팅, 코드 호스팅, 워크플로 자동화, 프로젝트 검색, 에이전트 조율 일부를 대체하려 함
    • 통합 구조는 에이전트에 필요한 맥락과 제한된 접근 권한을 제공하기 위한 연동 작업을 줄일 수 있음
    • 반면 역할별로 분리된 기존 제품은 개발 스택 전체를 이전하지 않고 도구 하나만 교체할 수 있음
  • Block은 Buzz 문서에 포함된 첫 고객 사례지만 도입률·가격·외부 고객 수를 공개하지 않았으며, 현재는 오픈소스 빌드와 기여 요청 단계임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 저 스크린샷은 무슨 David Lynch식 공포물 같음. “#engineering. 새 방향입니다. 프로토타입을 Flutter로 옮깁니다”라고 하자 사람과 에이전트 봇이 귀여운 이름과 이모지로 “물리 처리는 끝냈어, UI 셸은 어때 @Honeybot?” 같은 대화를 나눔
    이런 방식으로 소프트웨어 개발을 조직하는 게 자연스러운 세상을 상상하기 어렵고, 블록체인 비슷한 무언가를 쓴다는 점도 전형적으로 느껴짐
    https://github.com/block/buzz/blob/main/docs/assets/screensh...

    • 미래의 프로그래밍이 Ian McKellen의 그린 스크린 촬영 같은 절망을 주지 않을까 싶음. 셰익스피어 연극의 노장이 실제 배우 없이 《The Hobbit》을 촬영하며 “다른 사람과 연기하는 게 내 직업이지, 혼자 연기하는 게 아니다”라고 느꼈던 상황과 비슷할 수 있음
      https://www.theguardian.com/film/2013/nov/20/the-hobbit-gand...
    • 어릴 때 AI 연구에 뛰어든 이유 중 하나는 언젠가 인간처럼 대화하고 교류할 수 있는 지적인 존재가 생기리라는 기대였음. 이제 실제로 가능해졌는데 모두가 싫어하는 듯하지만, 나는 여전히 좋고 AI 에이전트를 팀원으로 만드는 시도가 멋지다고 봄
      다만 아첨만 하는 복제본 대신 실제 성격을 부여해, 능력과 행동 양쪽에서 각 에이전트의 차이가 분명해야 함
    • 저 화면은 여러 사람과 에이전트의 움직임을 실시간으로 맞추기 어려워 만든 스크립트 기반 데모이며, 저장소에서 해당 PR도 확인할 수 있음
      본질적으로 낯선 것을 직관적으로 느끼게 만드는 데 장난스러운 연출을 과소평가할 필요는 없음. 봇마다 관리 주체, 능력, 권한이 다르므로 이름과 이미지는 인스턴스를 구분하는 편리한 약칭이고, 귀엽게 꾸밀지는 선택 사항임
    • 여기에는 블록체인이 없음. Nostr는 단순한 저장 후 전달 릴레이 서버를 거치는 서명된 메시지 형식 표준일 뿐임
    • 모든 메시지 시간이 5시 42분인 것으로 보아 미리 넣은 테스트 데이터로 만든 캡처이거나 그 캡처에 기반한 목업임

  • “5살에게 설명하듯”이라면서 “Buzz는 서명된 Nostr 이벤트로 팀 채팅, AI 에이전트, Git 호스팅을 결합한 오픈소스 자체 호스팅 작업 공간”이라고 설명하니, 기대하는 5살의 수준이 상당히 다름

    • 원래 AskReddit 스레드에서 파생된 서브레딧 이름이었던 ELI5가 이제 기술 업계의 흔한 마케팅 문구가 된 과정이 흥미로움. 현재는 “예상 독자가 알아야 할 제1원리부터 설명하라”는 뜻의 약칭에 가까우며, 업계 종사자 다수가 2010년대 Reddit을 애틋하게 기억하는 듯함
    • 에이전트에게 eli5 (작업)라고 하다가 정말 5살에게 말하듯 설명할까 걱정한 적이 있음. 비합리적인 우려였고, 에이전트는 HN 댓글란과 달리 대개 실제 의도를 이해함
    • 어제 받은 ELI5도 이해되지 않아 합리적인 다음 단계로 “ELI4”를 요청했음
    • “TechCrunch Disrupt에서 발표하듯 설명해 줘”라는 뜻에 가까움
    • Buzz를 읽어도 유행어와 기업식 전문용어만 겹쳐 보여서, 실제로 무엇을 하는지 알기 어려움

  • Slack에서 일하지만 개인 견해임. 에이전트가 나와 동료가 보는 모든 것을 볼 수 있다는 점은 멋지지만, 일부 정보를 특정인에게만 공개하려는 순간 어려워짐
    다중 사용자 에이전트가 데이터를 유출하지 않도록 리소스별 접근 규칙을 복잡하게 작성하고 유지해야 함. 반면 단일 사용자 에이전트는 한 사용자를 대신하므로 구조가 단순하고, 명시적 허가 없이 비공개 데이터를 공유 공간으로 반출하지 못하게 하는 것이 핵심임

    • 진정한 협업 환경에서 비공개 그룹은 최악임. Slack에 스레드 전체를 공개 채널로 발행하는 버튼이 있으면 좋겠음
    • Asana 출신이라 편향됐을 수 있지만, 단일 사용자 에이전트가 더 쉽다는 데 동의함. 그래도 전체 작업 흐름을 이해하는 다중 사용자 에이전트는 매우 강력함
      개인정보를 의식하고 잘못된 대상에게 정보가 새지 않도록 만드는 데 많은 고민과 시간이 들었음. Buzz는 아직 써보지 않았지만 색다르게 사고하며 흥미로운 것을 만드는 시도는 높이 평가함
    • Buzz에서는 에이전트가 앱 통합이 아니라 그 자체로 일급 사용자인 듯함. Claude라는 사용자를 만들고 일반 ACL을 적용한다면 인간인지 봇인지 신경 쓸 필요가 없지 않을까 싶음
    • 우리 클라우드 실행 환경은 공유 비밀과 개인 비밀을 구분함. 공유 비밀로 인증된 항목은 공개 환경에서 쓸 수 있고, 개인 항목은 신뢰 채널로만 접근할 수 있어 Slack이나 Telegram 등에도 적용됨
      Slack 에이전트는 이 부분이 강력하며 비공개 정보가 전혀 유출되지 않도록 보장함
    • 대화 키로 그룹 채팅 ID와 추가 정보를 사용하면 되지 않나 싶음

  • 이제 새 소프트웨어 프로젝트를 보면 얼마나 많은 부분이 에이전트로 만들어졌는지, 그에 따른 불안정성과 손쉬운 포기부터 떠오름. 10년 전이었다면 제품 품질을 어느 정도 짐작할 수 있었겠지만, Buzz를 특정해 말하는 것은 아님

    • 예전에는 무언가를 만드는 마찰 자체가 어느 정도 숙고했다는 신호였지만, 지금은 사용자에게 던져 놓고 가치가 있는지 직접 판별하게 하는 듯함
      이런 제품은 초기 도입의 이점보다 위험이 크므로 몇 달 기다리는 편이 나음. 지속 가능한 제품이라면 몇 달 늦어져도 별 차이가 없음
    • 대부분의 소프트웨어는 에이전트 사용 여부와 무관하게 결국 사라지므로 그런 사고방식에는 결함이 있음. Google도 LLM 이전인 2010년에 비슷한 소셜 제품 Google Buzz를 출시했지만 16개월 만에 끝냈음
      프로젝트가 시장 적합성을 찾느냐가 핵심이며, 2년 뒤에도 존재할지는 엔지니어가 믿고 싶어 하는 것만큼 코드 품질과 강하게 연결되지 않음
    • 이제는 초기 도입자가 되고 싶지 않으며, 최소 6개월의 검증을 거쳐 잠깐의 유행인지 확인해야 함
    • 모두 LLM으로 생성됐다고 가정하는 편이 안전함
    • 손쉽게 포기하게 된다는 건 현실임. AI로 함수와 테스트를 만들고, AI로 함수를 수정한 뒤 테스트가 깨지면 전부 삭제하고 다시 AI로 테스트를 생성하는 흐름이 됨

  • 예전에 Slack에서 일했음. 채팅의 현상 유지에 도전하는 건 좋지만, Slack과 Teams가 에이전트 시대에도 살아남거나 그 수준으로 발전할지는 회의적임
    다만 Nostr가 정말 적절한 프로토콜인지는 궁금함. 대기업에서는 휴대전화와 로컬 에이전트를 포함한 수많은 클라이언트와 팀별 에이전트를 다뤄야 함. 중앙 호스팅 에이전트에는 현재 신원 구조가 맞지만, 개인 에이전트가 사용자 자격 증명을 재사용하는지 별도로 구분되는지는 알 수 없음
    Git이 필수 의존성일 필요가 있는지도 의문임. Block에는 필요할 수 있지만 복잡성이 커지므로, 버전 관리 호스트 이벤트를 Buzz 이벤트 로그에 병합하는 방식으로 분리할 수도 있음
    Sol과 Claude가 채팅 창에서 네이티브 구성 요소를 렌더링해 디자인 변경을 구체화하는 것처럼 새 기능이 등장할 때 어떤 문제가 생길지도 궁금함. Rust를 선택한 이유와 검토한 대안도 알고 싶음

    • Signal 같은 절충안이 더 나아 보임. Slack은 사무직 비즈니스 관계에서 떼기 어려운 존재가 됐지만, 24시간 사이버 공격에 노출된 상황에서는 회사의 약속보다 영지식 시스템을 통한 기밀성과 보안이 보장되면 좋겠음
      Signal은 친구 그룹에서 써 본 클라이언트 중 플랫폼 간 메시징 경험이 가장 좋았으며, 현재 구조에 Slack 같은 체계를 더하면 시끄러운 채널 문제를 줄이는 데 유용할 것임
    • 코드와 파일 같은 공유 정보는 사람과 에이전트의 정렬을 유지하는 데 갈수록 중요하며, AI 네이티브 기업은 코드 의존도가 더 높아질 테니 Git 통합이 타당함
    • Rust가 왜 나쁜 선택처럼 느껴지는지 궁금함. 의료기기 소프트웨어를 출시한 경험상 팀이 작성한 코드를 응집력 있고 정확하게 유지하는 데 훌륭했음

  • Google Buzz와 Wave는 이 세상에 너무 일찍 나왔음
    https://en.wikipedia.org/wiki/Google_Buzz

    • 아직도 Gmail에서 Buzz 라벨을 만들 수 없음
    • 보자마자 Google+와 Buzz가 떠올랐음

  • 팀 채팅에 봇을 넣는 건 나쁘지 않아 몇 달째 실험 중임. Slack은 작동하긴 하지만 수많은 권한을 맞추기가 고통스럽고 새 봇마다 반복해야 함
    자체 호스팅 대안으로 Matrix를 써 봤지만, 종단간 암호화가 너무 엄격해 봇과 정보를 공유할 때 방해가 됐음. 몇 주 전 Zulip으로 옮겼고 설치와 봇 사용자 생성, 자동화가 모두 간단했음. Openclaw로 만든 자동화는 상태가 덜 엉망인 Haystack 기반 코드로 교체했음
    설치 후 알게 됐는데 Zulip 경영진이 Anthropic에 채용됐음. Jack Dorsey가 먼저 발표한 듯하지만 Anthropic도 비슷한 계획이 있을 수 있음
    팀 단위 에이전트는 충분히 타당함. 조직이 커질수록 협업 비용이 늘어나 AI로 최적화하기 좋고, AI 활용이 많아질수록 무엇을 하는지 공개 채널에서 공유하고 조율할 필요도 커짐. 공통 안전장치와 사람·에이전트 간 인계가 포함된 복잡한 프로세스에도 팀 채팅이 잘 맞음

    • XMPP는 어떨지 궁금함

  • 유용한 틈새를 채울 수 있지만 Anthropic과 OpenAI가 6~12개월 안에 자체 제품으로 밀어붙일 가능성이 큼
    에이전트 군집용 Git 포지를 살펴보니 Radicle은 신원 계층이 부족하지만 연합형 COB 모델은 좋아 보였고, Tangled는 비공개 저장소 지원이 없지만 소셜 계층은 탄탄했음. 다만 이슈를 저장소 소유 객체가 아니라 게시물로 모델링한 점은 어색함
    따라서 비공개 에이전트 우선 포지의 자리가 있음. Anthropic은 이미 이 방향으로 가고 있으며, 최신 제품 Tag는 Slack 안에서 에이전트를 비동기로 실행하기 위한 인증 모델임
    다음 단계는 자연스럽게 포지가 될 수 있음. 에이전트 UI가 GitHub를 중개하지 않게 되면 Anthropic은 내부 구현을 자유롭게 교체할 수 있고, 다중 사용자 채팅과 저장소·프로젝트 관리가 다음 플랫폼 구성 요소로 보임

    • 새 코드 포지 https://juju.bi를 만들고 있음. 에이전트 우선 제품은 아니지만, 확장성 외에 에이전트에 특별히 필요한 기능은 떠오르지 않음

  • Slack이 존재하는 큰 이유는 IRC가 채널 기록과 검색 등을 기본 지원하지 않아 부족했기 때문임. AI 에이전트가 번성하려면 Slack이 네트워크를 프로토콜로 완전히 개방하거나 결국 대체돼야 함
    Slack이 AT Protocol 기반 채팅을 채택하고 Buzz 같은 앱이 이를 구현하면 좋겠음. 사용자는 @yourname.com, 에이전트는 @agent1.yourname.com 같은 도메인 핸들을 쓰면서 완전한 통제권을 가질 수 있음

    • 왜 에이전트를 번성하게 하는 것이 Slack의 책임인지 모르겠음. 업계 전반에서 AI에 맞춰 작업 흐름을 바꾸는 주객전도를 직접 겪고 있는데, 도구가 사람을 위해 작동해야지 그 반대여서는 안 됨
    • Matrix의 봇·퍼핏 계정과 비슷함
    • 처음 Slack을 좋아한 이유는 “현대적인 편의 기능을 갖춘 IRC”였기 때문임. Microsoft에 밀리고 Salesforce에 매각된 뒤로는 사실상 정체됐으며, 대부분의 변경이 제품을 더 나쁘게 만들었음
    • 아직 확정되지 않은 ATProto 권한 체계로는 기업이 요구하는 세밀한 제어가 부족함. 그룹 같은 기능은 앱 뷰에서 구현돼 사실상 중앙화될 것이며, ACL은 신원 및 접근 관리 역사에서 두 세대 전 방식임
      채팅도 PDS/ATP에 잘 맞는 형식이 아님. Roomy도 이를 깨닫고 전용 프로토콜과 브리지를 만들고 있음
    • Slack보다는 HipChat에 가까우며 시대를 약 15년 잘못 짚었음

  • 웹사이트에서 커서 움직임이 0.5초나 지연되는 불쾌한 경험은 처음임

답변달기