Buzz 그룹챗

같은 구조로 데모를 둘 돌렸는데 하나만 먹혔고, 화자가 그걸 스스로 인정합니다 — 그 한 문장이 이 15분에서 제일 값어치 있습니다. Buzz는 슬랙처럼 생긴 데스크톱 앱인데 채널 멤버가 사람만이 아니라 제 PC에 깔린 코딩 CLI들입니다. Claude Code·Codex·Kimi를 각각 별개의 “직원”으로 등록해 두고 @팀장 하고 부르면 팀장이 나머지에게 일을 쪼개 던집니다. 주식 분석은 34턴 만에 제대로 나왔고, 웹페이지 제작은 24턴을 돌고도 단일 모델 수준이었습니다. 차이는 도구가 아니라 「나눌 게 실제로 있었는가」였습니다.

무엇을 하는 물건인가

슬랙 UI에 자체 LLM이 없는 앱입니다. 채널을 만들고, 사람과 에이전트를 초대하고, @ 로 부릅니다. 초대된 에이전트는 처음에 깨어나는 중으로 뜹니다 — 하네스 프로세스가 기동하는 중이라서입니다.

기존 오케스트레이션과의 진짜 차이는 관계의 방향입니다. 서브에이전트나 제 tc-team 같은 구조는 한 프로세스 안에서 부모가 자식을 부릅니다. Buzz는 그걸 뒤집습니다 — 에이전트가 프로세스가 아니라 주소를 가집니다. 부모-자식이 아니라 동료라서 에이전트끼리 서로 호명하고 되묻는 게 자연스럽고, 대화 로그가 곧 작업 기록입니다. 누가 누구에게 뭘 시켰고 몇 번 반려됐는지가 스레드 답글 수로 그냥 보입니다.

그리고 한 채널 안에서 모델이 섞입니다. 워런 버핏 역은 Kimi로, 피터 린치 역은 Claude로, 벤저민 그레이엄 역은 GPT로 돕니다. 뒤에서 보겠지만 이게 이 영상에서 제일 중요한 설계 결정입니다.

경제적으로도 축이 하나 있습니다. API 키에 종량 과금하는 게 아니라 이미 내고 있는 구독을 그대로 태웁니다. 에이전트를 다섯 굴려도 추가 API 비용이 아니라 구독 사용량으로 나갑니다.

대표 기법 — 팀장 인스트럭션이 한 문장이다

오케스트레이션 로직이 코드에 없습니다. 팀장 에이전트의 시스템 프롬프트 전문이 이것뿐입니다.

너는 작업을 하지 않고 해당 채널에 있는 전문가들을 활용해서 최종적으로 작업을 매니징하는 역할을 할 거야

라우팅 로직도 도구 정의도 없습니다. 팀장은 런타임에 CLI 명령으로 채널 멤버를 조회해서 알아서 나눠 줍니다 — 관측 패널에 그 명령이 실제로 찍힙니다. 팀 구성이 코드가 아니라 채널 멤버십에 들어 있습니다.

관측 창이 열려 있는 것도 좋습니다. 에이전트 이름을 누르면 사고 블록, 실행한 명령, 컨텍스트 소진율(26,537/258,400 같은 실제 수치), 사용 가능한 명령 수, 권한 요청이 인라인으로 보입니다.

설치 중 막힌 걸 푸는 방법이 재밌었습니다. CLI가 깔려 있는데 목록에 안 뜨자, 하네스 설정 블록을 그 CLI 자신에게 붙여넣고 “연동이 안 된다, 가능하면 경로를 정정해서 적용해 줘” 라고 시킵니다. 에이전트에게 자기 배선을 고치게 하는 방식이고, 환경 트러블슈팅의 일반형으로 재사용할 만합니다.

깨본 결과 — 데모 둘이 갈렸다

주식 케이스에서 제일 값어치 있는 장면은 팀장이 기다린 것입니다. 세 전문가 중 하나가 먼저 보고했는데 팀장이 최종화하지 않고 명시적으로 미완성을 선언하고 대기했습니다. 그리고 부족한 부분은 같은 팀원에게 다시 반려했습니다. 프롬프트 한 줄에서 자연발생한 완결성 게이트입니다. 코드로 강제한 게 아니라 산문으로 유도된 것이라 재현이 보장되지 않지만, 비용 0으로 얻은 것치곤 값이 큽니다.

그리고 「세 전문가 판단이 충돌하지 않았다」가 의미를 가지는 조건이 있습니다. 세 사람이 서로 다른 모델이었기 때문에 일치가 정보량을 가집니다. 같은 모델 셋에 페르소나만 씌웠다면 일치는 거의 자동이고, 그건 검증이 아니라 자기 확인입니다.

웹 케이스는 반대였습니다. 지시가 “애플과 테슬라 디자인 참조해서 현대적인 웹페이지” 한 줄이었고, 디자이너는 상세 지시가 없어 컨셉을 스스로 확정했습니다. 결과는 나쁘지 않았지만 셋이 나눌 게 별로 없었습니다. 화자가 직접 이렇게 말합니다 — “실제로 웹을 만들 때는 각 하나의 모델을 그냥 사용해서 만드는 게 더 나을 수도 있다.”

내 환경에 대봤다 — 그리고 안 깔았습니다

확인된 빌드가 macOS Apple Silicon 하나뿐입니다. Windows 지원 여부는 영상 범위 밖이고 미확인입니다. 이 한 줄로 실측 자체가 불가능했습니다.

깔 수 있었어도 먼저 결론 내야 할 것이 셋 있었습니다.

• 실행 권한 범위. 관측 패널에 권한 우회 모드가 찍혔고, 승인 옵션에 “이 접두사로 시작하는 명령 전부 허용” 이 있습니다. 접두사 승인은 폭발 반경을 넓힙니다.
• 제3자 릴레이. 커뮤니티는 외부 서비스가 릴레이를 호스팅합니다. 채널 대화가 어디까지 나가는지 확인하기 전에는 업무 내용을 넣을 수 없습니다.
• 비밀 개수. 제 아이덴티티 키 하나 + 에이전트마다 하나, 그리고 생성 시 딱 한 번만 노출됩니다. 에이전트 다섯이면 비밀 여섯입니다. 편의 기능이 아니라 운영 부담으로 계산해야 할 항목입니다.

판정 — 도구는 안 쓰고 원칙 셋을 가져왔다

무엇	판정
이종 모델 패널 — 검증용 다중 리뷰는 페르소나가 아니라 모델을 갈라야 한다	채택. 적대 검증 설계에 그대로 적용
지휘자가 미완성을 선언하고 대기 — 산문 한 줄로 만든 완결성 장치	채택. 코드 게이트가 없는 임시 작업에 비용 0
에이전트에게 자기 배선을 고치게 하기	채택. 환경 트러블슈팅의 일반형
도구 도입	보류. 플랫폼 미지원 + 권한·릴레이 미결

제일 크게 얻은 건 첫 줄입니다. 저는 검증용 다중 리뷰를 돌릴 때 같은 모델에 다른 역할을 주는 방식을 써 왔는데, 이 영상이 그게 왜 약한지를 보여줬습니다. 일치가 정보량을 가지려면 틀리는 방식이 서로 달라야 합니다. 페르소나만 갈아서는 틀리는 방식이 같습니다.

공정하게 덧붙이면, 영상이 스스로 한계를 자백한 게 이 자료의 신뢰도를 올렸습니다. 잘 된 데모만 보여주고 끝냈으면 저는 “34턴 돌았으니 좋은가 보다” 로 읽었을 겁니다. 턴 수는 품질 지표가 아니고, 영상 어디에도 턴이 많은 게 좋다는 근거는 없습니다. 비용 절감량도 단일 에이전트 대비 정확도 향상도 측정된 바 없습니다 — 인용할 때는 여기까지입니다.