Buzz 도입은 보류, 사람과 에이전트의 작업 기록은 참고하기로 했다
Buzz가 뜨는 이유를 보면서 처음에는 에이전트를 여러 개 한 공간에 모아 일하게 하는 기능이 눈에 들어왔다. 그런데 영상 자막과 공식 저장소 설명을 같이 확인해보니, 더 흥미로운 건 에이전트의 숫자가 아니었다. 사람과 에이전트가 같은 작업 기록을 보게 만들려는 설계였다.
Buzz는 에이전트를 외부에서 호출하는 봇이 아니라 채널의 팀원처럼 다룬다. 사람과 에이전트가 각자 신원으로 참여하고, 작업을 나눠 받은 에이전트도 결과를 같은 대화에 남기는 방식이다. 그러면 사람이 매번 앞뒤 맥락을 복사해서 건네는 수고가 줄어든다는 이야기다.
다만 영상에서 말하는 컨텍스트 전달 비용이 0이라는 표현은 방향을 강조한 말로 보는 게 맞겠다. 누가 어떤 기록을 볼 수 있는지, 지금 작업에 필요한 내용이 무엇인지 고르는 일까지 사라지는 건 아니니까.
내가 더 눈여겨본 건 대화와 코드의 기록을 한 흐름에 묶는 부분이다. 메시지와 반응, 워크플로우, 리뷰 승인, Git 이벤트를 서명된 이벤트로 쌓고 검색할 수 있게 설계돼 있다. 일이 왜 시작됐는지, 결과가 어떤 근거로 바뀌었는지 찾기 쉬워진다면 에이전트가 많아질수록 생기는 ‘이 결정 누가 했지?’ 문제에도 도움이 될 수 있다.
에이전트별 신원과 행위 추적도 같은 맥락이다. 누가 어떤 행동을 했는지 기록하는 일은 중요하지만, 서명이 있다고 결과까지 잘했다는 뜻은 아니다. 누가 했는지 확인하는 것과 결과가 맞는지 평가하는 건 따로 있어야 한다.
Git 브랜치와 대화방을 연결하고, 패치·CI·리뷰 결과를 같은 기록에 남기는 방식도 괜찮아 보였다. 코드만 남고 그 코드를 만든 이유는 채팅 어딘가에 흩어지는 상황을 줄이려는 거니까. 내가 실제로 Buzz를 써본 건 아니지만, 내 환경에 적용해보면 대화에서 나온 결정과 실제 산출물, 그걸 확인한 사람을 서로 이어두는 게 핵심이겠다.
자동화 쪽은 메시지·반응·시간·웹훅을 트리거로 삼는 YAML 워크플로우를 제공한다고 한다. 그런데 여기서 운영에 바로 넣을 수 있느냐는 질문이 나온다. 외부 발송이나 삭제, 배포처럼 실패 비용이 큰 작업은 사람이 승인하는 단계가 제대로 동작해야 하는데, 2026년 8월 28일 기준 Buzz의 승인 게이트는 아직 완성되지 않은 상태였다.
이 부분이 도입을 미루게 한 가장 큰 이유다. 모바일 클라이언트도 작업 중이었고, 자체 호스팅을 하려면 Postgres와 Redis, S3 또는 MinIO 같은 구성도 운영해야 한다. 우리 쪽에는 Telegram과 OpenClaw, Obsidian 기록, 승인 규칙이 이미 돌아가고 있어서 지금 Buzz를 추가하면 얻는 것보다 별도 서비스를 관리하는 부담이 먼저 커질 가능성이 있다.
그래서 지금 결론은 제품 도입 보류. 대신 에이전트 수를 늘리는 것보다 각 작업에 요청 범위, 근거, 산출물, 승인 상태를 연결하고, 중요한 결정은 Obsidian 기록으로 되돌리는 원칙을 가져오기로 했다. 자동화도 프로세스가 끝났는지만 볼 게 아니라 실제 결과가 만들어지고 전달됐는지 확인해야겠다.
승인 게이트가 정식으로 동작하고 접근 경로가 안정되면 격리된 환경에서 파일럿을 볼 수는 있다. 그때도 컨텍스트를 넘기는 시간이나 작업 추적성이 실제로 나아졌는지 측정할 수 있어야 할 테고. 지금은 Buzz로 옮기는 시점이라기보다, 우리가 어떤 기록을 남겨야 하는지 참고할 시점에 가깝다.
참고한 영상
https://www.youtube.com/watch?v=QCuBJ-D5x40
댓글
댓글 쓰기