무료 LLM으로 멀티 에이전트를 운영한다면, '모델의 지능'보다 '상류의 가용성'을 보아야 한다

본 기사는 AI 에이전트(Claude / 자체 제작 멀티 에이전트 환경)와의 대화를 통해 검토 및 검증한 내용을 필자가 재구성한 것입니다. AI 협업 및 AI 교정 활용 사실을 공개합니다. 기재된 수치 및 사양은 2026년 6월 시점의 것이며, 말미에 1차 정보 링크를 정리해 두었습니다.

출근길에, 막 정비한 환경이 무너졌다

출근길에 인터넷 서핑을 하던 중, Gemini CLI의 무료 티어(Free tier)가 2026년 6월 18일로 종료된다는 정보가 눈에 들어왔습니다.

조금 전, 쇼군·가로·아시가루(하급 무사)로 구성된 계층형 멀티 에이전트(Multi-agent) 환경을 막 정비한 참이었습니다(그 기록이 첫 번째 기사입니다). 그 아시가루(실행 워커)의 일부를 바로 Gemini CLI의 무료 티어로 돌리고 있었습니다. "사전에 좀 더 조사해 두었더라면..." 하는 후회가 막심했습니다.

그리하여 대체 모델 찾기가 시작되었습니다. 결론부터 말씀드리면, 이번 교체에서 가장 효과적이었던 것은 "어떤 무료 모델이 똑똑한가"가 아니라, 훨씬 앞단의 문제였습니다.

먼저 결론: 무료 LLM 운용에서 중요한 3가지 축 (그리고 내가 저지른 순서 실수)

무료 클라우드 LLM을 아시가루로서 상시 가동해 보며 알게 된 것은, 걸림돌이 되는 것이 모델의 성능이 아니라는 점입니다. 같은 모델 ID라도, 배후에서 처리하는 상류 프로바이더(Upstream provider)의 상태에 따라 쉽게 작동하지 않게 된다——이 점이 가장 결정적입니다.

따라서 무료 LLM으로 아시가루를 선택할 때는 이 순서로 생각했어야 했습니다.

우선순위	축	무엇을 보는가	왜 중요한가
1	가용성 (Availability)	상류 프로바이더가 복수 존재하는가·장애 시 우회 가능한가	작동하지 않으면 성능은 제로. 최우선 순위
2	tool-use 신뢰성	function calling으로 도구 호출을 정확히 수행하는가	아시가루의 업무는 파일 조작·명령 실행임
3	토큰 효율성	CoT(Chain of Thought)를 상시 강제하지 않는가	무료 티어의 레이트 리밋(Rate limit)은 엄격함. 1req를 가볍게

솔직히 말하자면, 저는 처음에 이 순서를 틀렸습니다. 최초 선정 시에는 제1축(가용성)을 건너뛰고, 제2축인 tool-use 신뢰성만으로 모델을 선택했다가, 보기 좋게 상류 장애로 발목을 잡혔습니다. 다음은 그 전말과 재정비의 기록입니다.

후보 1: 후속 Antigravity CLI → 보류

먼저 후보에 오른 것은 Gemini CLI의 후속으로 안내되고 있는 Antigravity CLI입니다. 순순히 후속으로 옮기면 되겠다고 생각했지만, 무료 티어의 제한 방식 자체가 바뀌어 있었습니다. 공식 문서에 따르면, 기존 Gemini CLI의 "하루당 요청 수"가 아니라, 작업량에 따른 상한을 몇 시간~주 단위로 리셋하는 방식입니다. 구체적인 무료 티어 수치는 집필 시점 기준으로 공식적으로 명시되지 않았으며, 이행 가이드 곳곳에서도 "대폭 축소되었다"는 견해가 눈에 띌 정도입니다.

수치의 정확성을 떠나 확실한 것은, 지금까지처럼 제한을 신경 쓰지 않고 병렬로 아시가루를 돌리는 것은 어려워졌다는 점입니다. 애초에 Gemini CLI의 무료 티어가 지나치게 관대했을 뿐, 무료 티어란 본래 이 정도로 엄격한 것이라고 인식을 고쳐먹고 다른 무료 모델을 찾기로 했습니다.

후보 2: OpenRouter를 경유한 qwen3-coder:free → 채택 (하지만 여기서 축 하나를 놓침)

아시가루에게 맡기고 싶은 것은 단순한 실행 태스크(코딩·조사 계열)입니다. 이미 아시가루 일부에서 OpenCode를 사용하고 있고 OpenRouter에 네이티브로 대응하고 있다는 점 때문에, OpenRouter의 무료 모델(모델 ID 끝에 :free가 붙는 모델)을 사용하기로 했습니다. 접속처를 교체하는 것만으로 에이전트의 구성을 바꾸지 않아도 됩니다.

그중에서 코딩 특화인 qwen/qwen3-coder:free를 주력으로 선택했습니다. 아시가루의 업무는 tool-use(도구 호출)가 중심이므로, 그 신뢰성과 토큰 효율성으로 선택했습니다.

agentic tool-use에 최적화되어 도구 호출의 신뢰성이 높다고 알려짐
CoT를 상시 강제하지 않아 1req가 가벼우며, 엄격한 레이트 제한(Rate limit)을 절약할 수 있음
480B MoE · 1M 컨텍스트

——눈치채셨겠지만, 이 선정 이유에는 "가용성"이 들어있지 않습니다. 이 점이 나중에 문제가 됩니다.

무료 티어의 레이트 제한 주의 (여기서도 한 번 실수했습니다)

선정 중, 레이트 제한에 대해 제3자 사이트의 "200req/일"이라는 정보를 그대로 믿고, 하마터면 잘못된 전제로 설계를 할 뻔했습니다. 공식 문서에서 확인한 올바른 사양은, 누적 크레딧 구매액에 따른 2단계 방식입니다.

누적 구매 $10 미만 → 일일 50 요청 (req/day)
누적 구매 $10 이상 (1회 한정·이후 영구 적용) → 일일 1,000 요청 (req/day)
분당 20 요청

완전 무료라면 일일 50 req/day로 상당히 엄격하지만, 한 번만 $10를 충전하면 영구적으로 일일 1,000 req/day로 올라갑니다. 아시가루(足軽, 에이전트)로서 상시 가동하려면 이 $10는 실질적인 필요 경비였습니다. (수치는 2026년 6월 기준. 끝부분의 공식 링크 참조)

셋업은 허탈할 정도로 간단하다

OpenCode를 실행하고, /connect 명령어로 OpenRouter를 선택해 API 키를 붙여넣은 뒤, /models 명령어로 Qwen3 Coder 480B A35B (free)를 선택하기만 하면 되었습니다.

💡

주의할 점: 모델 선택 시에는 반드시 끝에 (free)가 붙은 것을 선택할 것. :free가 붙지 않은 동일한 이름의 모델은 유료 패스스루 (pass-through)로 취급되어, 자신도 모르는 사이에 과금됩니다. 인증 정보는 ~/.local/share/opencode/auth.json에 저장되므로, API 키를 별도로 메모할 필요는 없습니다.

예상 밖: 똑똑한 모델을 골랐는데, 작동하지 않는다

모델을 변경하고 드디어 사용. 동작을 확인하고 있는데——프롬프트의 상태가 이상하다.

상황을 확인해 보니, 원인은 모델의 성능이 아니었습니다. 무료 상류 프로바이더 (upstream provider, Venice)가 혼잡하여 제대로 사용할 수 없는 상태였던 것입니다.

OpenRouter의 무료 모델은 동일한 모델 ID라도 실제로 처리하는 상류 프로바이더가 여러 개 존재하며, 어디로 배정되느냐에 따라 안정성이 달라집니다. 도구 사용 (tool-use) 능력이 뛰어나고 벤치마크 점수가 높더라도, 상류가 부실하면 아시가루는 일을 하지 않습니다. "똑똑한 모델을 고르면 된다"라는 나의 전제(=제1축을 건너뛴 대가)가 여기서 무너졌습니다.

나중에 알게 된 사실: 설정으로 회피할 수 있었을 가능성

기사를 작성하며 다시 조사해 본 결과, OpenRouter에는 **프로바이더 라우팅 (provider routing)**이라는 메커니즘이 있어, 요청의 provider 필드에서 상류 프로바이더를 지정, 제외 또는 순서를 정할 수 있다는 것을 알게 되었습니다.

ignore를 통해 특정 프로바이더(이번 경우에는 Venice)를 피함
order로 우선순위를 부여하고, allow_fallbacks로 폴백 (fallback) 가능 여부를 제어함 - 사실 기본 설정에서도 최근 장애를 일으킨 프로바이더는 후순위로 밀려난다. 또한 도구 호출 (tool call)을 포함하는 요청에는 "Auto Exacto"라는, 도구 사용 (tool-use) 품질이 높은 프로바이더를 전면에 배치하는 라우팅이 자동으로 적용된다.

즉, 구조상 처음부터 상류를 의식한 설정을 해두었다면 이번과 같은 공전은 어느 정도 피할 수 있었을 가능성이 있습니다.

다만 주의사항이 있습니다. OpenCode에서 이 provider 파라미터를 사용하려면, OpenRouter API에 직접 요청하는 것과는 달리 opencode.jsonc 설정 파일을 통해 모델별로 기술해야 합니다. 실제 기기에서 qwen/qwen3-coder:free에 order와 allow_fallbacks를 설정할 수 있음을 확인했습니다 (v1.17.9 기준). ignore (특정 프로바이더 제외)는 OpenRouter API 자체에는 존재하는 필드이지만, OpenCode의 opencode.jsonc를 통해 동일하게 전달할 수 있는지는 확인되지 않았습니다. 적어도 order와 allow_fallbacks에 대해서는 프록시 계층 없이 설정 파일만으로 대응할 수 있음을 확인했습니다.

대응: 가용성을 최우선으로 하여 교체 (gpt-oss)

프로바이더 지정 검증에는 시간이 걸리기 때문에, 우선 "지금 바로 작동하는 것"을 우선하여 다른 무료 모델로 주력을 옮겼습니다. 선택한 것은 openai/gpt-oss-120b:free입니다. OpenAI가 공개한 120B 오픈 웨이트 (open-weight) 모델로, 여러 프로바이더를 통해 제공되는 만큼 특정 상류가 막히더라도 다른 곳으로 흐르기 쉬울 것이라 기대할 수 있습니다. 함수 호출 (function calling)도 네이티브로 지원하므로, 아시가루의 기능 요구 사항을 충족합니다.

성능이 떨어지지는 않을지 걱정되어, 이관 전에 기존의 Gemini 2.5 Flash(Gemini CLI의 무료 티어 모델)와 gpt-oss-120b의 공개 벤치마크를 비교해 보았습니다. 세부적인 점수는 출처(하단 링크)에 맡기겠지만, 대략적으로 말하자면 지표에 따라 승패가 뒤바뀔 정도의 차이였으며, 어느 한쪽이 명확하게 우위에 있지는 않았습니다. 실용적인 측면에서 의식해야 할 차이는 컨텍스트 길이(Context Length)(Gemini 약 1M / gpt-oss 약 131K) 정도이지만, 아시가루(足軽)는 가로(家老)가 할당한 개별 태스크를 처리하므로 이 부분은 큰 영향을 미치지 않습니다.

⚠️ 보충: 벤치마크는 '지능'의 지표이지, 이 글의 주제인 '가용성'을 보장하는 것은 아닙니다. 어디까지나 '교체 시 기본 역량이 크게 떨어지지 않는다'는 것을 확인하기 위한 용도로 사용한 것이며, 안정성 그 자체는 아래와 같이 운영을 통해 확인할 수밖에 없습니다.

성능이 떨어진 qwen3-coder:free는 삭제하지 않고, 콜드 스탠바이(Cold Standby)로 보존했습니다. Venice 측이 회복되면 언제든 도구 사용(Tool-use)에 가장 강력한 주력 모델로 복귀할 수 있는 상태로 두었습니다.

솔직히 말해서: 교체 후의 '안정성'은 아직 검증 중

제목에서 '상류의 가용성을 보는 것이 좋다'고 썼지만, 이 부분은 명확히 구분해 두겠습니다. 이번 경험을 통해 증명할 수 있었던 것은 '가용성' — 즉, 특정 상류(Upstream)가 막혔을 때 도망갈 곳(다른 프로바이더)이 있는가 하는 점입니다. 반면, 교체 대상인 gpt-oss가 개체로서 장기간 안정적으로 작동할지는 아직 충분한 운영 기간을 확보하지 못해 검증 중입니다. 현재 시점에서 말할 수 있는 것은 "Venice 장애 시 qwen이 공회전했고, gpt-oss에서는 동일한 증상이 나타나지 않았다"는 제한적인 관측까지입니다. "여러 프로바이더를 사용하므로 잘 떨어지지 않을 것이다"라는 설계상의 기대와 실제 측정된 안정성은 별개의 문제이므로, 후자는 지속적으로 관측하여 별도로 추가할 예정입니다. 가용성은 구조적인 이야기로서 단언할 수 있지만, 안정성은 현재 진행 중인 가설로서 읽어주시기 바랍니다.

남겨진 숙제: 수동 전환은 본래 지향해야 할 모습이 아니다

이번에 주력 모델이 작동하지 않았을 때 저는 수동으로 대체 모델로 전환했습니다. 작동은 하고 있지만, 본래는 "살아있는 프로바이더/모델로 자동 전환되는 페일오버(Failover)"를 갖추어야 합니다. OpenRouter의 provider 라우팅(order + allow_fallbacks)을 자신의 구성에서 적용할 수 있다면, 그것이 그 첫걸음이 될 것입니다.

주력 모델 하나에만 의존하는 구성은 상류 장애 시 그대로 멈춥니다. 이번에 그것이 증명된 셈입니다. 해야 할 일은 두 가지가 남았습니다.

(1) OpenCode의 opencode.jsonc에 provider routing 설정을 추가하여, Venice 제외 및 우선 프로바이더 순서가 실제로 작동하는지 실측을 통해 확인한다.
(2) 안정성 개선이 실측으로 확인되면 본 절을 "검증 완료"로 업데이트한다.

무료 LLM으로 운영하는 이상, 상류의 불안정함은 전제 조건이며, 이를 흡수하는 메커니즘까지 포함해야 비로소 "운영 가능한 구성"이라고 생각합니다.

요약

막 구축한 환경이 외부 요인으로 무너진 것은 뼈아픈 일이었지만, 덕분에 설계의 관점이 한 단계 진보했습니다. 무료 LLM으로 멀티 에이전트를 돌린다면, 고려해야 할 우선순위는 다음과 같습니다.

가용성 (떨어지면 성능은 0입니다. 상류가 여러 개 있고, 장애 시 도망갈 수단이 있는가)
도구 사용(Tool-use) 신뢰성 (아시가루의 업무는 도구를 호출하는 것입니다)
토큰 효율성 (엄격한 레이트 리밋(Rate Limit) 내에서 1회 요청당 비용을 절약)

저는 처음에 이 1번을 건너뛰었다가 큰 교훈을 얻었습니다. 똑똑한 모델을 하나 고르는 것보다, 떨어지더라도 전환되는 구성을 만드는 것이 무료 티어 운영에서는 훨씬 효과적입니다. "만드는 것"에서 "떨어지는 것을 전제로 운영하는 것"으로 — 이것이 이번의 가장 큰 수확이었습니다.

참고 (1차 정보 · 2026년 6월 기준)

OpenRouter FAQ (무료 모델의 레이트 리밋: 50 / 1,000 req/일)
OpenRouter Provider Routing 문서 (only / order / ignore / allow_fallbacks / Auto Exacto)
gpt-oss-120b 벤치마크: OpenAI 공식 발표 / Artificial Analysis
Gemini 2.5 Flash vs gpt-oss-120b 비교 (Gemini 측의 공개 벤치마크는 본 비교 페이지에 의거)