기록
OpenClaw로 워크플로우 구축하기
처음 OpenClaw가 나왔을 땐 그냥 신기했다. Discord에 붙여서 이것저것 해보다가, 막상 이걸로 뭘 해야 할지는 잘 감이 안 와서 그대로 묻어뒀다. 그러다 퇴사를 하고 나서 여러 유튜브를 보고 생각이 바뀌었다. 단순히 챗봇처럼 쓰는 게 아니라, 실제 회사처럼 돌아가는 구조를 만들 수 있지 않을까 싶어서 Slack에 에이전트들을 붙이기 시작했다.
위는 OpenClaw 프로젝트에 따로 대시보드를 만들어 Slack에 연결한 에이전트들을 관리했다. 조직도도 만들어봤다.
처음에는 꽤 단순하게 접근했다. 에이전트들을 역할별로 나눠서 Slack 채널에 초대하면 알아서 협업이 되지 않을까 싶었다. Elon, Jobs, Linus 같은 식으로 역할을 나누고 한 공간에 모아두면 자연스럽게 일이 굴러갈 거라고 생각했다. 그런데 막상 돌려보니까 전혀 그렇지 않았다.
일이 돌아가는 게 아니라 채널이 먼저 시끄러워졌다. 누가 답해야 하는지 애매한 순간마다 여러 에이전트가 동시에 반응했고, 서로 이어서 일을 하는 게 아니라 각자 따로 말하는 구조가 됐다. 결과적으로 협업이라기보다는 그냥 똑똑한 봇들이 모여서 떠드는 느낌에 가까웠다.
이때부터 문제를 다시 보기 시작했다. 에이전트가 똑똑하냐의 문제가 아니라, 누가 언제 말해야 하는지가 정의되지 않은 상태였다는 게 문제였다. 그래서 접근을 완전히 바꿨다. 에이전트를 더 잘 만드는 게 아니라, 어떻게 일하게 만들지를 먼저 설계하기로 했다.
가장 크게 바꾼 건 모든 에이전트가 다 말하게 두지 않는 것이었다. 대신 하나의 중심 에이전트를 두고, 그 에이전트만 판단하고 나머지는 실행하도록 구조를 나눴다. Elon을 오케스트레이터로 두고, 작업을 받으면 적절한 역할로 라우팅하고 결과를 다시 받아 판단하는 구조로 만들었다. Jobs는 기획, Linus는 개발, Seth는 마케팅, Bezos는 운영처럼 역할을 고정했고, 서로의 영역을 넘나들지 않도록 채널도 분리했다. 이걸 적용하고 나니까 확실히 달라졌다. 누가 일을 시작하고, 누가 처리하고, 누가 책임지는지가 명확해지면서 흐름이 생기기 시작했다. 그제야 에이전트들이 답하는 봇이 아니라, 일하는 조직처럼 바뀌었다.
몇 가지의 파이프라인을 만들고 연결하며 깨달은 게 있었다. 모든 걸 Slack 위에서 처리하려고 하면 다시 노이즈가 커진다는 점이었다. 사람이 봐야 하는 흐름과, 굳이 드러낼 필요 없는 실행 과정을 분리해야 했다. 그래서 Slack은 조직처럼 쓰고, 실제 실행은 agent-to-agent로 내부에서 처리하는 방식으로 나눴다. 예를 들어 Shorts를 만드는 작업에서는 Mina가 주제와 업로드 타이밍을 정하고, Noah가 실제 생성과 업로드를 담당하게 했다. 이때 중간 과정은 Slack에 다 흘리지 않고, 내부에서 바로 넘겨서 처리하고 Mina가 결과만 보고하게 했다. 반대로 사람의 판단이 중요한 작업은 Slack 채널에서 그대로 드러나도록 유지했다. 이 차이를 두고 나니까 구조가 훨씬 안정적으로 돌아갔다.
이러한 작업을 진행하며 느낀건 멀티 에이전트 시스템은 모델 성능보다 조직 설계에 더 가깝다는 것이다. 그래서 이 구조를 더 확장해보고 싶어서 Frog라는 에이전트를 만들어 GitHub까지 연결해봤다.
GitHub에서 이벤트가 발생하면 Slack으로 보내고, Frog가 그걸 받아서 판단한 뒤 다시 GitHub에 코멘트를 남기는 흐름으로 만들었다.
이렇게 하니까 기존에 Slack에서 돌아가던 구조를 그대로 확장할 수 있었다. PR 리뷰뿐 아니라 Issue 처리나 명령 기반 작업까지 한 흐름 안에서 이어갈 수 있고, 무엇보다 Frog가 단순한 알림 봇이 아니라 실제로 코드를 읽고 판단하는 주체로 동작하게 됐다.
여기까지 붙여보면서 느낀 건 AI를 어디에 붙이느냐보다 이미 쓰고 있는 운영 흐름 안에 어떻게 녹여낼지가 훨씬 중요하다는 것이다. Slack에서 이미 조직처럼 돌아가고 있었다면, GitHub는 그 조직이 일하는 또 하나의 공간으로 붙이는 게 맞았다. 그렇게 생각하고 나니까 구조가 훨씬 자연스럽게 정리됐다.
결국 멀티 에이전트 시스템에서 중요한 건 에이전트를 얼마나 많이 만들었느냐가 아니다. 누가 판단하고, 누가 실행하고, 그 결과가 어디에 남는지를 먼저 설계해야 한다. 그걸 정하지 않으면 에이전트가 많아질수록 더 똑똑해지는 게 아니라 더 시끄러워진다. 반대로 이 구조를 잡고 나면, 그제야 에이전트들이 단순히 답하는 도구가 아니라 실제로 일을 하는 구성원처럼 동작한다.
물론 지금 완벽하게 자동화가 되어있는건 아니다. 사람이 개입을 해야하고 아이디어를 던져주고 지시를 해야한다. 하지만 설계를 고도화해 구조에 변화를 조금 준다면 완전 자동화도 될 수 있을 것 같다. 테스트를 더 해볼 필요가 있을 것 같다.