글

라벨이 개발 도구인 게시물 표시

Buzz 도입은 보류, 사람과 에이전트의 작업 기록은 참고하기로 했다

이미지
Buzz가 뜨는 이유를 보면서 처음에는 에이전트를 여러 개 한 공간에 모아 일하게 하는 기능이 눈에 들어왔다. 그런데 영상 자막과 공식 저장소 설명을 같이 확인해보니, 더 흥미로운 건 에이전트의 숫자가 아니었다. 사람과 에이전트가 같은 작업 기록을 보게 만들려는 설계였다. AI 생성 일러스트 · 사람과 AI 에이전트가 작업 맥락을 공유하는 모습을 나타낸 개념 일러스트 Buzz는 에이전트를 외부에서 호출하는 봇이 아니라 채널의 팀원처럼 다룬다. 사람과 에이전트가 각자 신원으로 참여하고, 작업을 나눠 받은 에이전트도 결과를 같은 대화에 남기는 방식이다. 그러면 사람이 매번 앞뒤 맥락을 복사해서 건네는 수고가 줄어든다는 이야기다. 다만 영상에서 말하는 컨텍스트 전달 비용이 0이라는 표현은 방향을 강조한 말로 보는 게 맞겠다. 누가 어떤 기록을 볼 수 있는지, 지금 작업에 필요한 내용이 무엇인지 고르는 일까지 사라지는 건 아니니까. 내가 더 눈여겨본 건 대화와 코드의 기록을 한 흐름에 묶는 부분이다. 메시지와 반응, 워크플로우, 리뷰 승인, Git 이벤트를 서명된 이벤트로 쌓고 검색할 수 있게 설계돼 있다. 일이 왜 시작됐는지, 결과가 어떤 근거로 바뀌었는지 찾기 쉬워진다면 에이전트가 많아질수록 생기는 ‘이 결정 누가 했지?’ 문제에도 도움이 될 수 있다. AI 생성 일러스트 · 대화와 작업 이벤트가 하나의 기록 흐름에 연결되는 개념 일러스트 에이전트별 신원과 행위 추적도 같은 맥락이다. 누가 어떤 행동을 했는지 기록하는 일은 중요하지만, 서명이 있다고 결과까지 잘했다는 뜻은 아니다. 누가 했는지 확인하는 것과 결과가 맞는지 평가하는 건 따로 있어야 한다. Git 브랜치와 대화방을 연결하고, 패치·CI·리뷰 결과를 같은 기록에 남기는 방식도 괜찮아 보였다. 코드만 남고 그 코드를 만든 이유는 채팅 어딘가에 흩어지는 상황을 줄이려는 거니까. 내가 실제로 Buzz를 써본 건 아니지만, 내 환경에 적용해보면 대화에서 나온 결정과 실제 산출물, 그걸 확인한 사람...