Running 4 LLMs Simultaneously: A Real Multi-Agent Team's Selection and Cost Breakdown

지난달, J가 순찰 보고서에 한 줄을 썼다: “Mimi가 이번 주에 41개 글을 번역했는데, Claude 토큰 청구는 변하지 않았다.”

그 문장을 한참 봤다.

그때 기억났다—지난달에 번역 작업을 MiniMax로 옮겼었다. 41개 글. 거의 조용하게 끝났다.

그 순간 깨달았다: 여러 LLM을 동시에 운영하는 것은 기술 성과가 아니다. 비용에 쫓겨서 한 걸음씩 나온 실용적 답변일 뿐이다.

기술 선택이 아니라—결국 숫자 문제다

한동안 나는 가장 강력한 모델을 쓰는 게 가장 시간 절감이 된다고 생각했다.

틀렸다. 가장 비싼 길이었다.

우리의 월 AI 예산은 약 $255다—Claude 구독료가 큰 부분을 차지한다. J가 쓰는 몫이다. J는 아키텍처 결정, 코드 개발, 전체 에이전트 팀 조율을 맡는다. 이런 작업은 오류 비용이 높고, Claude Opus의 추론 능력이 실제 ROI를 전달한다.

근데 Mimi는 매주 수십 개의 시장 기사를 정리하고, 콘텐츠를 번역하고, 초안을 생성해야 한다. Ada는 코드 리뷰와 상품 페이지를 처리한다. 이 모든 게 Opus로 가면 예산이 버틸 수 없다.

찾아봤다: MiniMax M2.5의 API 가격이 Claude Opus보다 약 60배 저렴하다. 60배다. 적합한 작업을 MiniMax로 옮기면 월별로 상당한 액수를 절약할 수 있고, 그 작업들의 출력 품질은 눈에 띄게 떨어지지 않는다.

Gemini는 Xiaoyue가 쓴다—무료 버전이 아니라 유료 Gemini CLI 구독이다. 사람들이 무료 OAuth 버전으로 착각하는 경우가 많아서 항상 설명해야 한다. 정식 유료 구독이다. QA와 리서치 작업 량이 많고, 구독이 API 호출을 실행하는 것보다 비용 효율적이다.

이 조합은 처음부터 설계된 게 아니다. 몇 달간 테스트한 뒤 청구서가 강제했다. 한 걸음씩 정답을 찾아내게 된 거다.

복사 번역, 코드 개발, QA 테스트—누가 뭘 하는지는 추측이 아니다

구체적으로 말해보자.

J는 Claude를 쓴다—아키텍처 설계, 코드 개발, 논리적으로 복잡한 작업에 쓴다. 여기서 한 번의 실수는 처음부터 다시 시작하는 의미고, 수정 비용이 절감한 노력보다 크다. 일상적 개발은 Sonnet, 복잡한 작업은 Opus.

Mimi와 Ada는 MiniMax를 쓴다—복사 번역, 상품 페이지 초안, 시장 인텔 정리, 소셜 포스트에 쓴다. 속도가 중요하고, 물량이 많고, 깊은 추론이 필요 없다. M2.5는 이 작업들에서 안정적인 출력을 제공한다—포맷이 가끔 조금 어색하지만 수용 가능한 수준이다.

Xiaoyue는 Gemini를 쓴다—QA 테스트 리포트, 경쟁사 리서치, 대규모 데이터 정리에 쓴다. Gemini는 컨텍스트 윈도우가 엄청 크다—데이터를 한 뭉탱이로 던져서 결론을 도출하게 하는 게 Gemini의 장점이고, 구독 버전은 레이턴시가 일정하다.

Lily (콘텐츠 담당)는 원문 기사는 Claude Sonnet으로, 번역과 리서치는 MiniMax로 쓴다. 이 둘은 필요가 완전 다르다. 서로 다른 모델로 분리해서 운영하는 게 맞다는 걸 확인했다—미리 설계한 게 아니라 실제 운영으로 발견한 것이다.

멀티 LLM 협업의 현실—아무도 말하지 않는 문제들

포맷 불일치가 첫 번째 함정이다.

Claude는 자기 출력 습관이 있고, MiniMax는 자기 습관이 있고, Gemini는 또 자기 습관이 있다. 에이전트들이 서로의 출력을 읽어야 할 때 세 포맷 차이가 인터페이스 지점에서 문제를 일으킨다. 처음엔 예상하지 못했다. J가 나중에 파싱 레이어를 추가해서 안정화시켰다.

레이턴시 차이가 두 번째 함정이다. Claude Sonnet은 빠르게 응답하고, Opus는 가끔 오래 걸린다. MiniMax는 보통 빠르지만 피크 시간에 가끔 느려진다. Gemini 구독 버전은 거의 안 밀린다. 이 차이들이 자동화된 워크플로우에서 예상 밖의 문제를 일으킨다—한 에이전트가 너무 오래 기다리면 다음 작업 체인이 끊긴다. 자동 스케줄링에 레이턴시 버퍼를 고려해야 한다. 우리가 고생해서 배운 것이다.

청구 방식이 완전 다르다는 게 세 번째 함정이다. Claude와 MiniMax는 모두 구독 기반이지만, 사용량 할당과 계산 방식이 다르다. Gemini도 구독 기반이고 월별 청구다. 셋 다 사용 한도, 리셋 주기, 초과 처리가 다르다. 통합 사용량 추적으로 통합하는 건 생각만큼 직관적이지 않다. 결국 전체 소비 상황을 보기 위해 자체 사용량 추적 도구를 만들어야 했다.

이건 큰 문제는 아니지만 각각 처리 시간이 든다. 멀티 LLM으로 절약한 비용 일부가 이걸 처리하는 데 들어간다.

리더보드는 누가 가장 강한지 말해주지만, 누가 당신 작업에 가장 좋은지는 말하지 않는다

한때 한 모델로 표준화하는 걸 고민했다.

그다음 계산을 했다가 포기했다.

전부 Claude Opus로 가면 예산이 버틸 수 없다. 전부 MiniMax로 가면 J의 아키텍처 결정 품질이 떨어지고 복잡한 작업의 오류율이 올라간다—실수 수정 비용이 절감분보다 크다. 전부 Gemini로 가면 繁體中文 원문 콘텐츠 품질이—시도했는데 차이가 난다.

어떤 한 모델도 “충분히 좋고” 그러면서 “충분히 저렴한” 것을 모든 작업에서 동시에 이룰 수 없다. 벤치마크는 어느 모델이 어느 테스트 셋에서 최고 성능을 내는지 말해준다. 하지만 벤치마크는 당신의 언어, 당신의 작업량, 이번 달 남은 예산이 얼마나 되는지는 말해주지 않는다.

우리의 현재 설정이 최적의 솔루션인지 난 모른다. 하지만 몇 달간의 테스트를 거친 뒤 실제로 작동하는 답변이다—청구서는 여전히 수용 가능해 보인다.