AI가 팀원이 되는 방, Buzz: 사람·AI·AI 협업과 설치 가이드

조회 441좋아요 0

AI와 협업한다고 하면 보통 개인용 채팅창을 떠올립니다. 사람은 AI에게 일을 시키고, 결과를 복사해 메신저에 붙이고, 동료의 의견을 다시 AI에게 전달합니다. AI가 똑똑해질수록 정작 사람은 여러 도구 사이에서 맥락을 나르는 전달자가 되기 쉽습니다.

Block이 공개한 Buzz는 이 구조를 뒤집습니다. 사람과 AI 에이전트가 같은 채널에 들어오고, 에이전트끼리도 서로 일을 나누며, 대화·코드·검토·승인 기록을 한 공간에 남깁니다. 아직 초기 제품이라 거친 부분이 있고 모바일은 더 다듬어질 필요가 있지만, “AI를 도구가 아니라 팀원으로 다루는 협업 공간은 어떤 모습인가”를 가장 직접적으로 보여주는 시도입니다.

사람과 여러 AI 에이전트가 한 프로젝트 공간에서 대화하고 코드와 작업을 함께 검토하는 모습

Buzz를 한 문장으로 설명하면

Buzz는 사람과 AI 에이전트가 같은 방에서 일하는 오픈소스 워크스페이스입니다. 겉으로는 채널과 스레드가 있는 팀 메신저처럼 보이지만, 안쪽에는 Nostr 기반의 서명 이벤트 로그가 있습니다. 사람의 메시지, 에이전트의 작업, 반응, 워크플로 단계, 검토 승인, Git 이벤트가 같은 방식으로 기록됩니다.

이 설계가 중요한 이유는 책임 주체가 분명해지기 때문입니다. 기존 봇은 사람의 API 키나 계정을 빌려 움직이는 경우가 많습니다. 그러면 누가 실제로 작업했는지 구분하기 어렵습니다. Buzz에서는 사람과 에이전트가 각자의 키와 정체성을 가지고 자신의 작업에 서명합니다. 에이전트 키가 노출되면 사람의 계정까지 바꾸지 않고 그 에이전트만 취소할 수 있습니다.

또 하나의 차이는 AI가 답변만 하는 것이 아니라 워크스페이스를 실제로 움직인다는 점입니다. 채널을 만들고, 저장소를 열고, 패치를 보내고, 코드를 검토하고, 워크플로를 실행하고, 다른 에이전트를 호출할 수 있습니다. 사람에게 보이는 협업 도구와 에이전트에게 주어진 작업 표면이 가깝습니다.

사람과 AI, AI와 AI는 어떻게 협업하나

가장 이해하기 쉬운 예는 기능 개발입니다. 사람이 “로그인 오류를 조사해 달라”고 채널에 요청하면, 리드 에이전트가 과거 대화와 저장소를 찾습니다. 조사 에이전트에는 오류 재현을, 구현 에이전트에는 수정 패치를, 검토 에이전트에는 보안과 회귀 위험 확인을 맡길 수 있습니다. 각 에이전트는 별도 채널이나 멘션으로 결과를 주고받고, 사람은 진행 중에 방향을 바꾸거나 중단시킵니다.

최종 결과만 남는 것이 아닙니다. 어떤 가설이 틀렸는지, 왜 특정 패치를 버렸는지, 누가 승인했는지가 같은 채널 기록에 남습니다. 몇 달 뒤 비슷한 문제가 생기면 에이전트가 과거 스레드와 근거를 찾아올 수 있습니다. Buzz가 강조하는 것은 모델의 지능보다 협업 기억과 조율입니다.

현재 공식 문서가 사용 가능하다고 밝힌 주요 기능은 다음과 같습니다.

영역 현재 제공 기능
대화 채널, 스레드, DM, 반응, 검색
협업 캔버스, 미디어, 감사 로그, 음성 허들 관련 기반
에이전트 buzz-cli, ACP 하네스, Goose·Codex·Claude Code 연결
자동화 메시지·반응·일정·웹훅을 트리거로 하는 YAML 워크플로
개발 Git 이벤트, 패치, 저장소 공지, 상태, Git 호스팅 백엔드
운영 자체 릴레이, 호스팅 릴레이, 별도 사람·에이전트 정체성

Claude Code, Codex, Goose처럼 Agent Client Protocol을 지원하는 도구를 연결할 수 있어 한 모델이나 한 실행 환경에만 묶이지 않습니다. 에이전트를 바꿔도 프로젝트의 채널, 권한, 기록은 워크스페이스에 남는다는 것이 Buzz의 방향입니다.

아직 초기 단계라는 점도 분명하다

Buzz를 지금 당장 완성된 Slack·GitHub 대체품으로 보면 기대가 어긋날 수 있습니다. 공식 README도 제품 상태를 “지금 작동함”, “연결 중”, “구상 단계”로 나누어 공개합니다. 데스크톱 앱과 기본 협업, CLI/ACP, Git, 워크플로는 작동하는 영역에 들어가지만 iOS·Android Flutter 클라이언트는 아직 연결 중으로 표시됩니다. 푸시 알림은 구상 단계입니다.

따라서 모바일에서 데스크톱과 같은 완성도와 흐름을 기대하기에는 이릅니다. 현시점에서는 데스크톱을 중심으로 작은 내부 프로젝트나 실험 팀에서 써보는 편이 현실적입니다. Block의 공식 소개 글도 거친 부분과 아직 구현되지 않은 큰 간격이 있다고 솔직하게 밝힙니다.

초기 제품의 장점도 있습니다. Apache 2.0 라이선스로 소스가 공개되어 있고, 릴레이를 직접 운영할 수 있으며, 기능이 어디까지 구현됐는지 문서에서 구분합니다. 다만 중요한 업무에 도입하기 전에는 백업, 키 관리, 권한, 감사 로그, 모바일 알림, 기존 도구 연동을 직접 검증해야 합니다.

설치 전에 꼭 알아야 할 두 가지: 앱과 릴레이

이 글은 서버나 코딩을 모르는 독자를 기준으로 설명합니다. Buzz를 사용하려면 내 컴퓨터에 설치하는 Buzz 프로그램과 대화 내용을 보관할 인터넷 공간이 모두 필요합니다. Buzz 문서에서는 이 인터넷 공간을 릴레이라고 부릅니다.

  • Buzz 프로그램은 사람이 채널과 메시지를 보는 화면입니다. 카카오톡 앱과 비슷합니다. 공식 문서의 “데스크톱 앱” 또는 “클라이언트”가 이 프로그램을 뜻합니다.
  • 릴레이는 채널, 메시지, 멤버, AI 에이전트와 파일을 보관하는 인터넷 공간입니다. 카카오톡 회사의 서버와 비슷합니다.

앱만 설치하고 릴레이를 정하지 않으면 들어갈 협업 공간이 없습니다. Buzz 앱은 처음에 ws://localhost:3000을 찾는데, 이는 “내 컴퓨터에서 실행 중인 Buzz 서버”라는 뜻입니다. 내 컴퓨터에 릴레이를 설치하지 않았다면 연결 오류가 나는 것이 정상입니다.

릴레이를 누가 마련하고 관리하느냐에 따라 실제 운영 방법은 다음 세 가지로 나뉩니다. 여기서 “호스팅”은 다른 회사의 컴퓨터와 저장 공간을 빌려 쓰는 것을 뜻합니다. 내 컴퓨터에서 소스코드를 실행하는 방법은 개발 시험용이므로 아래 세 가지 팀 운영 방식에 포함하지 않습니다.

운영 방식 쉬운 비유 내가 해야 할 일 추천 대상
1. Block 호스팅 관리사무소가 있는 임대 사무실 가입, 방 만들기, 사람 초대 처음 써보는 개인과 비전공자 팀
2. Railway 관리형 서버 설비 관리는 업체가 해주는 독립 사무실 이용료 확인, 공개키 입력, 백업 확인 별도 공간은 필요하지만 서버 담당자는 없는 팀
3. 자체 서버·VPS 건물과 설비를 직접 관리하는 사무실 설치, 보안, 장애 처리, 백업 전부 전담 IT 담당자가 있는 조직

세 방법은 같은 Buzz를 사용하지만 책임 범위가 다릅니다. 1번은 Block이 인터넷 공간까지 만들어 주고, 2번은 Railway라는 클라우드 회사가 서버의 기본 설비를 대신 준비하며, 3번은 우리 조직이 서버를 직접 준비하고 관리합니다.

어느 것을 골라야 할지 모르겠다면 1번을 선택하세요. 별도 공간을 소유해야 한다는 조직 규칙이 있지만 서버 전문가는 없다면 2번을 검토합니다. 3번은 “우리 서버에 직접 설치해야 한다”는 명확한 이유와 담당자가 있을 때만 선택하는 편이 안전합니다.

공통 1단계: Buzz 데스크톱 앱 설치하기

세 운영 방식 모두 사람의 컴퓨터에는 Buzz 데스크톱 앱을 설치해야 합니다.

운영체제에 맞는 파일 고르기

1. 웹브라우저에서 Buzz 공식 설치 파일 페이지를 엽니다. GitHub은 프로그램 제작자가 설치 파일과 소스코드를 공개하는 웹사이트입니다.

2. 화면 아래쪽의 설치 파일 목록(Assets)을 펼칩니다. 영어로 Assets라고 표시된 부분이 접혀 있으면 글자를 한 번 누릅니다.

3. 아래 표에서 자기 컴퓨터에 맞는 파일을 누르면 다운로드가 시작됩니다.

내 컴퓨터 내려받을 파일
Apple M1·M2·M3·M4·M5 Mac Buzz_<version>_aarch64.dmg
Intel CPU Mac Buzz_<version>_x64.dmg
일반적인 64비트 Windows PC Buzz_<version>_x64-setup_alpha-unsigned.exe
Ubuntu·Debian 계열 Linux Buzz_<version>_amd64.deb
그 밖의 x86_64 Linux Buzz_<version>_amd64.AppImage

Mac의 칩을 모르면 화면 왼쪽 위 Apple 메뉴 → 이 Mac에 관하여를 엽니다. “칩”에 Apple M 시리즈가 표시되면 aarch64, “프로세서”에 Intel이 표시되면 x64 파일을 선택합니다.

Windows에서 설치하기

1. 다운로드 폴더에서 Buzz_..._x64-setup_alpha-unsigned.exe를 두 번 누릅니다.

2. 현재 Windows용 파일은 코드 서명이 없는 알파 빌드라 SmartScreen이 “Windows의 PC 보호”라고 표시할 수 있습니다.

3. 파일을 받은 주소가 github.com/block/buzz/releases인지 먼저 확인합니다.

4. 공식 주소가 맞을 때만 추가 정보 → 실행을 선택합니다.

5. 설치가 끝나면 시작 메뉴에서 Buzz를 찾아 실행합니다.

출처가 이메일 첨부나 파일 공유 사이트라면 경고를 무시하지 말고 삭제한 뒤 공식 릴리스에서 다시 받으세요.

macOS에서 설치하기

1. 다운로드한 .dmg 파일을 엽니다.

2. 나타난 Buzz 아이콘을 Applications 폴더로 끌어 놓습니다.

3. Finder의 응용 프로그램에서 Buzz를 실행합니다.

4. macOS가 실행을 막으면 시스템 설정 → 개인정보 보호 및 보안에서 차단 내용을 확인합니다. 공식 block/buzz 릴리스 파일이 맞는 경우에만 열기를 허용합니다.

Linux에서 설치하기

Ubuntu나 Debian 사용자는 다운로드 폴더에서 .deb 파일을 열어 소프트웨어 설치 화면을 이용할 수 있습니다. 터미널을 쓸 수 있다면 다음과 같이 설치합니다. 실제 파일 이름은 다운로드한 버전에 맞춰 바꿉니다.

Terminal
bash
cd ~/Downloads
sudo apt install ./Buzz_<version>_amd64.deb

AppImage를 받은 경우 실행 권한을 한 번 준 다음 실행합니다.

Terminal
bash
cd ~/Downloads
chmod +x Buzz_<version>_amd64.AppImage
./Buzz_<version>_amd64.AppImage

처음 실행하고 내 신분증 역할의 키 보관하기

Buzz가 처음 실행되면 표시 이름과 Buzz 정체성을 만듭니다. 정체성은 Buzz 안에서 “이 작업을 누가 했는가”를 구분하는 전자 신분증입니다. 이때 만들어지는 키는 두 종류입니다.

  • 공개키(Public key): 명함의 주소처럼 다른 사람에게 알려줘도 됩니다. 사람 초대와 공간 소유자 등록에 사용합니다.
  • 개인키(Private key): 신분증의 비밀번호와 같습니다. 이 키를 가진 사람은 나인 것처럼 행동할 수 있으므로 누구에게도 보내면 안 됩니다.

앱의 설정(Settings) → 신원(Identity)에서 공개키를 볼 수 있습니다. 개인키 백업 기능이 제공되면 다른 사람이 열 수 없는 안전한 저장소에 보관합니다. Buzz 고객지원, AI 에이전트, Railway 입력 화면도 개인키를 요구해서는 안 됩니다.

운영 방법 1: Block 호스팅으로 가장 쉽게 시작하기

이 방법은 무엇인가

Block은 Buzz를 만든 회사입니다. Block 호스팅은 Block이 대화 저장 공간을 만들어 관리해 주는 방식입니다. 사용자는 회원가입을 하고 모임 이름을 정한 뒤 사람을 초대하면 됩니다. 서버 설치, 보안 인증서, 데이터베이스 같은 기술 설정은 하지 않습니다.

임대 사무실에 비유하면 건물과 전기·수도는 관리회사가 맡고, 사용자는 사무실 이름과 출입할 사람을 정하는 방식입니다. 가장 간단하므로 비기술자에게 권장합니다.

이 방법에서 내가 하는 일

  • Buzz 프로그램을 설치한다.
  • buzz.xyz에 가입하고 커뮤니티를 만든다.
  • 함께 일할 사람과 AI 에이전트를 초대한다.
  • 공개 채널과 비공개 채널을 구분한다.

Block이 하는 일

  • 인터넷에서 항상 접속할 수 있는 릴레이를 운영한다.
  • 저장 공간과 서비스 보안, 장애 대응을 관리한다.
  • 서비스 운영과 법적 의무에 필요한 범위에서 신고 내용과 저장된 자료를 처리한다.

커뮤니티 만들기

1. Buzz 데스크톱 앱을 먼저 실행해 정체성을 만듭니다.

2. 웹브라우저에서 buzz.xyz를 엽니다.

3. 로그인(Sign in)을 누르고 로그인하거나 새 계정을 만듭니다. 공식 지원 문서상 사용자는 만 18세 이상이어야 합니다.

4. 웹사이트에서 Buzz 프로그램의 정체성 연결(Connect your Buzz desktop identity) 단계가 나오면 연결을 진행합니다.

5. 데스크톱 앱이 확인 서명 요청을 보여주면 대상이 buzz.xyz인지 확인하고 승인합니다. 이 과정은 공개 정체성의 소유 여부만 확인하며 개인키를 웹사이트에 전달하지 않습니다.

6. 사용 가능한 Buzz 주소와 커뮤니티 이름을 고른 뒤 커뮤니티 만들기(Create community)를 누릅니다. 커뮤니티는 우리 팀이 사용할 하나의 협업 공간입니다.

7. 생성이 끝나면 데스크톱 앱에서 새 커뮤니티가 보이는지 확인합니다.

초기 이용 기간에는 Block 호스팅 커뮤니티가 무료입니다. 공식 지원 페이지 기준으로 커뮤니티당 미디어 저장 공간은 5GB, 콘텐츠 보관 기간은 365일이며 한 계정은 최대 5개 커뮤니티를 만들 수 있습니다. 초기 정책이므로 이후 변경될 수 있습니다.

사람 초대하기

Block 호스팅 커뮤니티는 초대 전용입니다. 상대방이 릴레이 주소만 입력해서 들어올 수는 없습니다.

1. 커뮤니티에서 설정(Settings)을 엽니다.

2. 릴레이 접근 권한(Relay access)을 선택합니다.

3. 상대방의 공개키를 입력하거나 초대 링크 만들기(Create invite link)를 눌러 링크를 만듭니다.

4. 링크 옆의 만료 시간을 확인한 후 상대방에게 전달합니다.

5. 상대방이 참여하면 멤버 목록에서 이름과 역할을 확인합니다.

공개 채널은 커뮤니티 멤버가 볼 수 있고, 비공개 채널은 그 채널에 추가된 사람과 에이전트만 볼 수 있습니다. 공식 지원 문서에 따르면 Block 호스팅의 메시지, 개인 대화(DM)와 업로드 파일은 “보낸 사람과 받는 사람만 내용을 볼 수 있게 만드는 종단간 암호화” 방식이 아닙니다. 서비스 운영, 보안과 신고 처리에 필요할 때 Block이 접근할 수 있으므로 주민번호, 계약 비밀, 의료정보 같은 민감한 자료는 올리지 않는 편이 안전합니다.

완료 확인

  • Buzz 앱 왼쪽에 만든 커뮤니티가 보인다.
  • 테스트 채널을 만들 수 있다.
  • 초대한 사람이 채널에 메시지를 보낼 수 있다.

이 세 가지가 되면 기본 설치와 커뮤니티 연결은 끝난 것입니다.

운영 방법 2: Railway에서 독립 릴레이 만들기

이 방법은 무엇인가

Railway는 인터넷 서버를 빌려주고 기본 설치를 자동으로 해주는 해외 클라우드 회사입니다. Buzz 공식 설치 양식을 이용하면 버튼을 누르고 공개키 하나를 입력하는 것만으로 우리 팀이 소유하는 별도 Buzz 공간을 만들 수 있습니다.

임대 사무실에 비유하면 Block 건물에 입주하는 1번과 달리, 우리 이름으로 독립 사무실을 빌리되 전기·수도·출입 설비는 Railway가 관리하는 방식입니다. Block 호스팅의 저장·보관 정책과 분리된 공간이 필요하지만 서버 명령을 직접 다루기 어려울 때 선택합니다.

다만 무료 서비스라고 생각하면 안 됩니다. Railway 사용량에 따라 비용이 발생할 수 있고, 서비스가 멈추지 않았는지와 백업이 있는지는 사용자가 확인해야 합니다.

이 방법에서 내가 하는 일

  • Railway에 가입하고 예상 요금을 확인한다.
  • Buzz 공개키를 입력해 내 공간의 소유자를 지정한다.
  • Railway가 만든 인터넷 주소를 Buzz 프로그램에 연결한다.
  • 중요한 대화와 파일의 백업 상태를 확인한다.

Railway가 하는 일

  • 서버와 데이터 저장 장치를 자동으로 만든다.
  • 인터넷 주소와 주소창의 자물쇠에 해당하는 보안 인증서를 준비한다.
  • 기본적인 서비스 연결과 작동 상태 확인을 제공한다.

준비물

  • 설치가 끝난 Buzz 데스크톱 앱
  • Buzz의 64글자 공개키. 숫자 0~9와 영문 a~f로 이루어진 긴 문자열입니다.
  • Railway 계정
  • Railway 사용료를 확인할 결제 수단과 예산

공개키는 Buzz 앱의 설정(Settings) → 신원(Identity) → 공개키(Public key)에서 복사합니다. npub1...로 시작하는 짧은 표시가 아니라 Railway가 요구하는 64글자 16진수(64-character hex) 형식을 사용해야 합니다. “개인”을 뜻하는 PRIVATE 또는 “비밀”을 뜻하는 SECRET이 이름에 들어간 키는 절대 입력하지 않습니다.

배포 순서

1. Railway의 Buzz 공식 자동 설치 페이지를 엽니다.

2. 지금 설치(Deploy Now)를 누르고 Railway에 로그인합니다.

3. 변수 입력 화면의 RELAY_OWNER_PUBKEY에 Buzz의 64글자 공개키를 붙여넣습니다.

4. 프로젝트와 예상 사용료를 확인한 뒤 배포를 시작합니다.

5. 화면에 표시되는 네 개 서비스가 모두 준비될 때까지 기다립니다. Postgres는 대화와 회원 정보를 보관하고, Redis는 실시간 전달을 돕고, Bucket은 파일을 보관하며, Buzz Relay는 이들을 묶어 Buzz에 제공합니다. 이름을 외울 필요는 없고 네 항목이 모두 정상인지 확인하면 됩니다.

6. Railway가 만들어 준 https://...up.railway.app 형태의 인터넷 주소를 복사합니다.

7. Buzz 앱에서 커뮤니티 참여(Join a Community)를 선택합니다.

8. 주소 맨 앞의 https://를 wss://로 바꿔 입력합니다. 이는 Buzz가 일반 웹페이지가 아니라 실시간 대화 서버에 접속한다는 뜻입니다. 예를 들어 https://my-buzz.up.railway.app은 wss://my-buzz.up.railway.app이 됩니다.

9. 연결 후 설정(Settings)에서 자신의 역할이 소유자(owner)인지 확인합니다.

Railway가 기술 설비를 자동으로 만들어도 공간의 운영 책임은 사용자에게 있습니다. Railway 설정에 자동 생성된 릴레이 개인키, 대화와 회원 정보, 업로드 파일을 백업해야 합니다. 릴레이 개인키는 공간 자체의 신분증과 같으므로 임의로 새 값으로 바꾸면 다른 공간으로 인식될 수 있습니다. 이 백업 항목이 이해되지 않는다면 설치 전에 IT 경험이 있는 사람의 도움을 받는 편이 좋습니다.

막힐 때 확인할 것

  • RELAY_OWNER_PUBKEY에 npub 주소가 아니라 64글자 16진수 공개키를 넣었는가.
  • 브라우저 주소 https://를 Buzz 앱에서 wss://로 바꿨는가.
  • Railway의 Buzz Relay, Postgres, Redis, Bucket이 모두 정상 상태인가.
  • Railway 프로젝트가 사용 한도나 결제 문제로 중지되지 않았는가.

운영 방법 3: 자체 서버나 VPS에서 직접 운영하기

이 방법은 무엇인가

VPS는 인터넷에 24시간 켜져 있는 가상 컴퓨터를 빌리는 서비스입니다. 자체 서버·VPS 운영은 그 컴퓨터에 Buzz를 직접 설치하고 우리 조직이 모든 것을 관리하는 방식입니다.

임대 사무실 비유로는 건물 설비와 출입 보안까지 직접 책임지는 것에 가깝습니다. 데이터가 저장되는 위치와 운영 규칙을 가장 세밀하게 통제할 수 있지만, 서버가 멈추거나 공격받거나 자료가 사라졌을 때 복구하는 책임도 우리에게 있습니다.

이 방법은 비기술자가 혼자 진행하지 않는다

아래 단어가 낯설다면 1번 Block 호스팅을 선택하거나 전담 IT 담당자에게 이 절을 전달하세요.

  • Linux: 서버에서 많이 사용하는 운영체제
  • Docker: 여러 서버 프로그램을 정해진 구성대로 실행하는 도구
  • DNS: buzz.example.com 같은 주소를 실제 서버와 연결하는 인터넷 주소록
  • 방화벽: 허용한 통신만 서버에 들어오게 막는 보안 장치
  • 백업 복구: 자료를 복사해 두는 것뿐 아니라 장애 후 실제로 되살리는 작업

이 방법에서 조직이 직접 하는 일

  • 서버와 도메인을 계약하고 비용을 낸다.
  • Buzz와 필요한 저장 프로그램을 설치하고 업데이트한다.
  • 외부 공격을 막고 접근 권한을 관리한다.
  • 장애를 감시하고 데이터와 키를 백업·복구한다.

준비물

  • 24시간 켜져 있는 Linux 가상 서버(VPS) 또는 조직 소유 서버
  • 서버에 설치된 Git과 Docker
  • 서버를 가리킬 도메인과 DNS 설정 권한
  • Buzz 소유자의 공개키
  • 안전한 비밀키·비밀번호 보관소

운영용 파일 준비하기

Buzz 저장소 루트의 docker-compose.yml은 개발용입니다. 실제 서버에서는 반드시 deploy/compose/에 있는 운영 번들을 사용합니다.

Terminal
bash
git clone https://github.com/block/buzz.git
cd buzz/deploy/compose
cp .env.example .env

.env는 서버 주소와 비밀번호를 적는 설정 파일입니다. 이 파일에서 CHANGE_ME, 즉 “여기를 바꾸세요”라고 표시된 값을 모두 바꿉니다. 릴레이 개인키, 소유자 공개키, 데이터 저장 프로그램의 비밀번호와 파일 저장소의 접속 정보를 입력해야 합니다. 이 단계는 서버 담당자가 수행해야 하며 개인키와 비밀번호는 GitHub나 채팅에 올리면 안 됩니다.

외부에서 접속할 주소가 buzz.example.com이라면 RELAY_URL은 wss://buzz.example.com으로 설정합니다. 멤버를 받기 전에 주소를 확정해야 합니다. 이 값이 바뀌면 기존 주소와 다른 새 커뮤니티로 취급될 수 있습니다.

시작하고 상태 확인하기

Terminal
bash
BUZZ_COMPOSE_TLS=true ./run.sh start
./run.sh status

이 명령은 인터넷 주소 옆에 자물쇠가 표시되도록 보안 인증서를 자동 발급하고 외부 접속을 Buzz로 전달합니다. 공식 가이드는 Docker Compose 2.24.4 이상을 요구합니다. 시작 후 서버 담당자는 다음 명령으로 Buzz가 살아 있는지 확인합니다.

Terminal
bash
curl -fsS http://127.0.0.1:3000/_liveness

Buzz 앱의 Join a Community에 wss://buzz.example.com을 입력합니다. 연결되면 멤버를 추가하고 테스트 채널에서 메시지를 주고받습니다.

운영자가 정기적으로 해야 할 일

  • 릴레이 개인키와 소유자 키를 안전하게 백업한다.
  • Postgres 데이터베이스를 정기적으로 백업하고 복구 시험을 한다.
  • 미디어·Git 데이터가 있는 오브젝트 저장소와 Git 볼륨을 백업한다.
  • ./run.sh upgrade 전 백업을 확인하고 가능하면 이미지 버전을 고정한다.
  • 도메인, TLS 인증서, 디스크 공간과 서비스 상태를 감시한다.
  • 퇴사자와 불필요한 에이전트의 접근 권한을 제거한다.

별도 시험 방법: 내 컴퓨터에서만 로컬 실행하기

다른 사람에게 공개하지 않고 기능을 시험하거나 Buzz 개발에 참여할 때 쓰는 방법입니다. 내 컴퓨터를 끄면 함께 사용할 수 없으므로 세 가지 운영 방식에는 포함하지 않습니다. 이 절은 개발 도구 설치와 터미널 사용에 익숙한 사람을 위한 참고사항이며, 일반 사용자는 건너뛰어도 됩니다.

공식 빠른 시작에는 Docker와 Hermit이라는 개발 도구가 필요합니다. 다른 개발 도구를 직접 준비하는 방법도 있지만 비기술자에게는 권하지 않습니다.

Terminal
bash
git clone https://github.com/block/buzz.git
cd buzz
. ./bin/activate-hermit
just setup && just build

첫 준비가 끝나면 다음 명령으로 로컬 릴레이와 데스크톱 앱을 함께 실행합니다.

Terminal
bash
. ./bin/activate-hermit
just dev

앱은 ws://localhost:3000에 연결됩니다. 컴퓨터를 끄면 다른 사람은 사용할 수 없고, 인터넷 팀 운영에 필요한 도메인·TLS·백업 구성도 없으므로 학습과 개발 시험에만 사용합니다.

Windows에서 에이전트의 셸 기능을 쓰려면 Git for Windows를 설치해 Git Bash를 준비합니다. 다른 Bash 호환 셸을 쓰는 경우 BUZZ_SHELL에 해당 실행 파일 경로를 지정합니다.

처음 써볼 때 추천하는 작은 실험

Buzz의 가치는 채팅 화면만 구경해서는 잘 드러나지 않습니다. 사람 한 명, 에이전트 두 개, 작은 저장소 하나로 다음 실험을 해보면 차이를 빨리 알 수 있습니다.

1. #bug-triage 채널을 만들고 작은 오류 하나를 등록합니다.

2. 조사 에이전트에는 재현 조건과 과거 기록을 찾게 합니다.

3. 구현 에이전트에는 조사 결과를 멘션으로 넘겨 최소 패치를 만들게 합니다.

4. 사람이 중간에 범위를 수정하고, 마지막 병합 판단은 직접 승인합니다.

5. 다음 날 같은 오류를 질문해 채널 기록과 근거를 다시 찾는지 확인합니다.

이 과정에서 반드시 살펴볼 것은 답변의 화려함이 아닙니다. 에이전트별 작성자가 구분되는지, 권한을 좁힐 수 있는지, 중간 실패가 기록되는지, 사람이 취소하고 방향을 바꿀 수 있는지, 비용과 작업 이력을 추적할 수 있는지를 확인해야 합니다.

Buzz가 흥미로운 진짜 이유

지금의 AI 협업은 대개 개인 생산성 도구를 여러 사람이 억지로 이어 붙인 모습입니다. 개인 AI 대화는 팀의 기억이 되지 못하고, 팀 채팅은 AI가 실제로 일한 과정까지 알지 못합니다. Buzz는 대화, 에이전트 실행, 코드, 검토, 승인을 하나의 협업 기록으로 만들려 합니다.

물론 아직은 실험적인 선택입니다. 모바일과 알림이 충분히 성숙하지 않았고, 운영형 릴레이는 키와 백업, 저장소를 직접 관리해야 합니다. 기존 Slack과 GitHub 생태계의 넓은 연동을 곧바로 대체하기도 어렵습니다.

그럼에도 Buzz는 중요한 질문을 던집니다. 앞으로 팀에서 AI는 누군가의 개인 도구로 남을 것인가, 아니면 이름과 권한과 책임을 가진 동료가 될 것인가. Buzz의 답은 명확합니다. 사람과 AI, AI와 AI가 같은 방에서 일하고, 사람은 그 과정을 실시간으로 이끕니다. 완성된 미래라기보다 그 미래를 먼저 만져볼 수 있는 흥미로운 초기 버전입니다.


참고자료