AI 동료라고 하면 많은 사람이 처음에는 팀처럼 일해야 한다고 생각합니다. 역할마다 에이전트 하나씩. 엔지니어링 담당 하나, 마케팅 담당 하나, 블로그 글만 쓰는 담당 하나처럼요.
저희도 그렇게 만들었습니다. Okou에서는 워크스페이스 안에 여러 에이전트를 만들 수 있었고, 각 에이전트는 저마다의 이름, 아바타, 지침, 워크플로를 가졌습니다. 8월에는 여러 에이전트가 일을 어떻게 나누고 넘겨주는지에 관한 글도 올렸습니다. 저희 워크스페이스에도 에이전트가 꽤 많았습니다. Lucas는 블로그 글을 썼고, Lisa는 회계 장부를 맡았고, Iris는 투자자 관계를 담당했고, 저에게는 이메일을 분류해 주는 Emily가 있었습니다.
하지만 사용자의 직관은 참고 기준일 뿐입니다. Notion이 나오기 전, 사람들은 문서 도구라면 머리글과 바닥글이 있어야 한다고 직관적으로 생각했습니다.
멀티 에이전트는 기반 역량도 아닙니다. 기반 역량이란 모든 AI 제품이 결국 갖춰야 하는 것들입니다. 채팅, 슬라이드와 웹사이트 만들기, 컴퓨터 조작 같은 것들이죠. 여러 에이전트는 그 목록에 없습니다.
예전 블로그 에이전트였던 Lucas를 예로 들어 보겠습니다. Lucas의 지침 가운데 약 3분의 1은 기본 Okou가 쓰는 것과 똑같은 범용 템플릿입니다. 나머지는 세 가지 구체적인 절차입니다. Strapi에서 블로그 글을 게시하는 방법, 저희 웹사이트의 활용 사례 페이지를 쓰는 방법, 그리고 일일 가입 전환율 보고서를 만드는 방법입니다. Lucas에 연결된 워크플로 13개는 모두 워크스페이스에 공개되어 있습니다. Lucas만의 것은 하나도 없습니다.
결국 Lucas와 기본 Okou의 차이는 이름, 아바타, 그리고 원래 워크플로였어야 할 세 가지 절차뿐입니다. 그 절차들은 Lucas 안에 갇혀 있습니다. 기본 Okou에게 블로그 글 게시를 부탁하면, 그런 규칙은 하나도 모릅니다.
에이전트 수가 늘면서 조합도 늘어났습니다. 수많은 에이전트, 수많은 워크플로, 수많은 대화가 서로 얽히고, 그 조합 하나하나가 저희가 유지보수해야 하고 사용자가 익혀야 하는 로직이 됩니다. 사용자 입장에서 제대로 답하기 어려운 질문들도 생겼습니다.
- 왜 두 에이전트가 같은 워크플로를 함께 쓸 수 없나요?
- 왜 Slack에서는 Okou하고만 대화할 수 있고, 제 개인 에이전트와는 대화할 수 없나요? Lucas가 한 사람이라면 어디서든 부를 수 있어야 하잖아요.
- 왜 메모리가 모든 에이전트에 공유되나요? 각 에이전트가 한 사람이라면 저마다 자기 메모리를 가져야 하잖아요.
모두 해결할 수는 있지만, 하나하나에 상당한 엔지니어링 작업이 듭니다. 해결하지 않고 두면 멀티 에이전트는 반쯤 완성된 경험으로 남습니다. 게다가 여러 에이전트만 풀 수 있는 문제도 좀처럼 찾지 못했습니다. 오히려 더 자주 들은 불만은 관리할 에이전트가 너무 많다는 것이었습니다.
그래서 한 사람당 Okou 하나로 정했습니다. 모델은 더 단순해집니다.
- 모든 사람은 기본 Okou를 하나씩 가집니다.
- 내 Okou는 나의 것이며 비공개입니다.
- 내 Okou와 동료의 Okou는 같은 에이전트가 아닙니다.
- 내 Okou는 조직 내 누군가가 Public으로 설정한 워크플로라면 무엇이든 쓸 수 있습니다.
예전에 에이전트에 딸려 있던 것들은 이제 더 잘 맞는 곳으로 옮겨 갑니다.
- 지침은 나에게 속합니다. 한 벌만 작성하면 Okou가 웹, Slack, 자동화 어디에서든 그대로 따릅니다.
- 워크플로는 워크스페이스에 속합니다. 동료가 게시한 Public 워크플로는 누구나 쓸 수 있고, 복사해서 내 것으로 만들 수도 있습니다.
- 연결된 계정은 나에게 속하므로, 어떤 에이전트에 접근 권한을 줄지 더는 고를 필요가 없습니다.
- 대화는 프로젝트로 묶어 고객별, 프로젝트별, 주제별로 정리합니다.
이 모델에서 에이전트는 지침 한 묶음과 크게 다르지 않습니다. Lucas 안에 있던 세 가지 절차는 누구나 쓸 수 있는 워크플로가 되어야 합니다.
멀티 에이전트는 사실 조직 안의 관리 방식, 즉 AI가 할 수 있는 일을 관리하는 하나의 방법입니다. 조직마다 고유한 관리 방식이 있고, 모두에게 맞는 단 하나의 방식은 없습니다. 단일 에이전트는 도구에 더 가깝고, 도구는 이해하기도 도입하기도 더 쉽습니다. 사용자에게 가장 필요한 것은 일을 끝내는 것입니다. 그다음이 그 일을 할 도구입니다. 가장 덜 필요한 것은 그 일을 하는 방법론입니다.
Anthropic의 Applied AI 팀도 엔터프라이즈 에이전트 도입에 관한 최근 글에서 비슷한 점을 짚었습니다. 여러 도입 사례를 비교해 보니, Skills를 갖춘 단일 에이전트가 전문 서브에이전트로 나눈 설계보다 품질 면에서 앞서는 경우가 많았고, 작업당 비용과 지연 시간도 더 낮은 경우가 많았다고 합니다. 또한 "너무나 자주 기업들이 팀이나 문제 유형마다 전용 서브에이전트를 두고, 그 결과 에이전트 아키텍처가 조직도의 복사본이 되어 버리는 것을 봅니다"라고도 썼습니다. 이 글은 제품 설계가 아니라 에이전트 아키텍처를 다루지만, 그 논리는 그대로 적용됩니다.
오늘날의 AI 제품을 살펴보면 네 가지 모델이 있습니다.
- 여러 에이전트, 여러 대화. 이것이 Okou였습니다.
- 하나의 에이전트, 여러 대화. ChatGPT, Codex, Claude Cowork가 이렇게 작동합니다.
- 하나의 에이전트, 하나의 대화. Instinct가 이렇게 작동합니다.
- 여러 에이전트, 각각 하나의 대화. Grok bot이 이렇게 작동합니다.
저희는 가장 복잡한 조합을 택했지만, 그렇다고 더 많은 문제를 해결하지는 못했습니다.
이것이 기존 방식을 깨는 변화라는 것을 알고 있습니다. 더 일찍 결정하지 못한 이유는 두 가지였습니다. Okou 하나에 워크플로를 더하는 새로운 일하는 방식을 익혀 달라고 부탁해야 한다는 점, 그리고 이미 만들어 둔 것들을 어떻게 옮길지에 대한 분명한 길이 없었다는 점입니다. 그 길은 다음과 같습니다.
- 대화는 그대로 남아 있습니다. 프로젝트, 검색, 원래 링크로 찾을 수 있습니다.
- 여러 에이전트로 대화를 나눠 정리했다면, 이제 프로젝트를 쓰세요. 대화를 카테고리별로 묶어 두는 것이 많은 분이 에이전트를 추가로 만든 주된 이유였습니다. Claude와 ChatGPT도 같은 필요를 프로젝트로 해결합니다.
- 에이전트마다 다른 지침을 썼다면, 공통된 내용은 개인 지침에 남기고, 구체적인 절차는 워크플로로 바꾸세요.
여러 에이전트 위에 추상화를 쌓는 일은 빨리 멈출수록 좋습니다. 이제 Okou를 열 때 어떤 에이전트에게 물어볼지 정할 필요가 없습니다. 필요한 일을 Okou에게 말하면 나머지는 Okou가 알아서 처리합니다.
