멀티에이전트는 토큰 폭탄이 아니다, 이미 낸 구독으로 굴린다

멀티에이전트라는 말을 들으면 보통 청구서부터 떠오릅니다. 모델 세 개를 동시에 부르면 토큰이 세 배로 나가고, API 미터기가 쉴 새 없이 돈다는 그림입니다. 실제로 많은 팀이 그 걱정 하나 때문에 시도조차 미뤄둡니다. 자동화 한 번 잘못 켜뒀다가 다음 달 청구서를 보고 식은땀을 흘린 적, 한 번쯤 있으셨을 겁니다.

그런데 추가 비용 없이 같은 일을 해본 사람의 그림은 좀 다릅니다. 토큰을 새로 사지 않고, 이미 가진 도구를 다시 쓰는 쪽으로 방향을 틀면 됩니다.

API 미터기 대신 구독을 다시 쓴다

핵심은 발상의 전환입니다. API 키를 새로 발급받아 토큰 단위로 과금되는 길 대신, 이미 매달 정액으로 내고 있는 CLI를 그대로 부른다. 그게 전부입니다. Claude, Codex, Gemini 모두 터미널에서 도는 명령줄 도구를 제공합니다. 월 구독료 안에 이미 쓸 수 있는 분량이 들어 있는 셈입니다. 대화 한 번 더 한다고 별도 청구가 붙을까요. 그렇지 않습니다.

음악 생성 도구를 붙이려다 같은 결론에 다다른 적도 있습니다. Suno API를 붙이려니 호출마다 돈이 나가는 구조. 결국 API를 사는 대신 이미 구독 중인 AI에게 프롬프트 설계를 맡기는 스킬로 방향을 틀었습니다. 비용을 새로 만들지 않고, 쥐고 있던 구독을 끝까지 짜내는 쪽이 더 멀리 갔습니다. 멀티에이전트도 같은 길입니다.

방법은 단순합니다. 봇이 메시지를 받으면 해당 CLI를 자식 프로세스로 띄우고, 프롬프트를 표준 입력으로 흘려보낸 뒤 출력만 받아 채팅으로 돌려줍니다. 모델을 직접 임베드하지 않습니다. 이미 깔려 있는 도구를 그대로 빌려 쓰는 셈입니다.

1. 01메시지 수신
2. 02CLI 프로세스 spawn
3. 03프롬프트 주입·출력 수신
4. 04채팅으로 응답

세 모델을 한 디스코드 봇에 묶어두면, 같은 질문을 셋에게 동시에 던지고 답을 나란히 비교할 수 있습니다. 교차검증이 공짜로 따라옵니다.

진짜 어려운 건 비용이 아니라 살림이다

붙이는 발상은 쉽지만, 실제로 띄워두면 살림에서 막힙니다. 가장 먼저 부딪힌 건 다중 인스턴스 문제였습니다. 같은 봇을 여러 프로세스로 켜두니, 메시지 하나에 답이 세 번씩 달리는 일이 벌어졌습니다. 프로세스 수만큼 응답이 그대로 곱해진 겁니다. 사용자 눈에는 봇이 같은 말을 도배하는 것처럼 보입니다. 정작 새 나가는 건 비용이 아니고 신뢰. 단일 인스턴스 보장 장치 하나가 없으면 조용히 무너지는 지점이 여기입니다.

다음은 인증이었습니다. macOS Keychain은 GUI 세션 밖에서는 열리지 않더군요. pm2로 띄워봐도, tmux 안에서도, LaunchAgent로 등록해봐도 자격 증명을 못 읽는 벽. 백그라운드 데몬으로 곱게 상주시키려던 계획이 여기서 한 번 무너졌습니다. 결국 키를 읽을 수 있는 세션 안에서 프로세스를 살려두는 쪽으로 우회해야 했습니다. 문서 어디에도 굵게 적혀 있지 않은, 비-GUI 환경의 키 접근이라는 함정. 손대보기 전엔 좀처럼 보이지 않습니다.

마지막은 실행 모드였습니다. 일반 대화라면 셋이 동시에 답해도 됩니다. 빠르게 세 관점을 한꺼번에 받으면 그만이니까요. 그런데 토론은 성격이 다릅니다. 앞 모델의 답을 다음 모델이 받아 반박하고 다시 다듬어야 의미가 생깁니다. 그래서 병렬과 순차, 두 모드로 길을 갈라야 했습니다. 같은 세 모델인데 묶는 방식만 바꾸면 쓰임이 완전히 달라집니다.

세 가지 모두 모델 성능과는 무관합니다. 프로세스를 어떻게 띄우고 묶느냐의 문제였습니다. 멀티에이전트의 난이도는 모델이 아니라 오케스트레이션에 있다는 뜻입니다.

작은 팀이 당장 할 수 있는 것

지금 Claude나 Codex, Gemini 중 하나라도 정액으로 쓰고 계신다면, 시작점은 이미 손에 있습니다. 새 예산을 따로 잡지 않아도 됩니다. 가진 구독의 CLI를 메신저 봇에 한 번 붙여보세요.

먼저 모델 하나만 단순하게 연결해 동작을 확인합니다. 그다음 둘째, 셋째를 더하면서 다중 인스턴스가 답을 곱하지 않는지, 인증이 백그라운드에서도 살아 있는지를 차례로 점검해 봅니다. 대화와 토론 모드를 가르는 일은 그 뒤에 붙여도 늦지 않습니다.

규모를 그려 보면 체감이 더 분명합니다. 개발자 한 명이 막히는 문제를 들고 텔레그램 봇에 던지면, 세 모델이 각자 진단을 답합니다. 한쪽이 놓친 엣지 케이스를 다른 쪽이 짚어 주고, 셋의 답이 갈리는 지점이 곧 사람이 들여다볼 자리입니다. 시니어 동료 세 명을 옆에 앉혀 둔 셈인데, 이 모두가 이미 내고 있던 구독 안에서 돌아갑니다.

작은 팀에게 이 방식이 주는 건 비용 절감만이 아닙니다. 세 모델의 답을 나란히 놓고 보는 습관이 생깁니다. 한 모델의 확신을 다른 모델이 깎아내는 장면을 보면, 어디서 멈춰 사람이 판단해야 하는지가 또렷해집니다. 이제 물어야 할 건 "멀티에이전트에 얼마가 드나"가 아니라, "이미 낸 구독을 얼마나 다시 쓰고 있나"입니다.