오랫동안 운영 모델은 당시 인기 있던 도구들의 형태에 맞춰져 있었습니다. Asana, Jira, Linear는 스프린트, 주간 계획, 칸반을 체계적으로 구현할 수 있는 의식으로 만들어 기업이 프로세스를 추진하도록 했습니다. 도구가 운영 모델을 형성하고, 운영 모델이 도구를 형성했습니다. 이것이 최고의 운영 모델은 아니었고, 당시 도구가 지원할 수 있는 최선의 모델이었을 뿐입니다. 도구가 Buzz처럼 구성 가능한 것으로 바뀌면 이러한 제약은 사라집니다. 이제 운영 모델이 도구가 지원하는 기능을 따라잡아야 합니다.
Buzz에서 하나의 스레드가 진단, 작업, 수정, 그리고 문제에 대한 대화로 압축되면, 이전에는 여러 도구를 사용해야 했던 것을 하나의 스레드로 누구나 따라갈 수 있게 만듭니다. 사용자가 결정이 내려진 이유를 이해할 수 있는 완전한 맥락을 제공합니다. 또한 Buzz에는 모든 것에 대한 CLI 명령이 있어, 에이전트가 자신의 채널을 만들고, 자신의 메모리를 업데이트하며, 다른 사용자 수준의 작업을 수행할 수 있습니다. 사용자는 각 에이전트의 동작, 도구, 모델, 그리고 활용 능력을 조정하면서, 에이전트가 따라야 할 채널별 또는 스레드별 규칙을 설정할 수 있습니다. 그것만으로 충분하지 않다면, 앱은 오픈 소스이므로 사용자가 수정하거나 개선하거나 기여하여 Buzz를 업무의 표준 인터페이스로 만들 수 있습니다.
Buzz는 너무나 구성 가능해서, '이게 이것저것 할 수 있느냐'가 아니라 '정확히 원하는 대로 설정하는 방법'이 문제입니다. 저는 모든 스레드에 대해 화이트보드를 생성하고, 그 스레드에서 작업하는 모든 에이전트와 공유하는 에이전트를 실험해 왔습니다. 이는 제가 추가 작업을 하지 않아도 더 나은 컨텍스트 전달을 가능하게 하는데, 그 이유는 참여 규칙이 채널에 정의되어 있기 때문입니다. 실험할 수 있는 방법은 훨씬 더 많습니다.
이렇게 많은 유연성 속에서 병목은 운영 모델이 됩니다. 사용 가능한 도구로 출력을 극대화하려면 리듬과 프로세스를 어떻게 구성해야 할까요? 사용자가 Buzz에서 직접 스레드로 작업을 추적할 수 있는데, 프로젝트 추적 도구의 가치는 무엇일까요? 모든 것이 인간과 에이전트에 의해 스레드에 포착된다면, 무엇을 추적해야 할까요?
이제 제한 요소는 더 이상 사용자가 한 도구에서 다음 도구로 복사해서 붙여넣는 속도가 아닙니다. 저희는 몇 달 동안 이에 대해 실험해 왔지만, 조직을 위해 Buzz의 가치를 극대화하는 운영 모델을 아직 찾지 못했습니다. Buzz로 Buzz를 작업하면서 이전에는 묻지 않았을 새로운 질문들이 생겼습니다: 에이전트 간의 올바른 협업 모델은 무엇인가? 비엔지니어링 작업에서는 이것이 어떻게 달라지는가? 에이전트가 효과적으로 잘 작동하기 위한 최적의 추상화 수준은 무엇인가? 당신 없이 에이전트 팀이 잘 협업하는 방식을 어떻게 정의할 것인가? 에이전트가 자신의 채널을 만들고 다른 에이전트만 초대할 수 있다면, 팀이 자동화의 한계를 어디까지 밀어붙일 수 있을까?
개인적으로, 새로운 협업 방식을 고안하는 것은 정말 멋진 경험이었습니다. 가장 분명한 것은 우리가 아직 시도해야 할 것이 얼마나 많다는 점입니다.
우리의 작업은 대부분 협업적이며, 그것이 AI와 함께 멈출 필요는 없습니다. Buzz를 인터페이스이자 조정 계층으로 삼아 모든 것을 하나로 모으는 새로운 작업 방식을 만들어 보세요 - buzz.xyz / github.com/block/buzz
