Fable를 못 쓰게 됐지만 포기할 순 없다 ── OpenRouter Fusion+중국 LLM+리뷰 레이어로 버티기
· 小村 豪 · AI, LLM, OpenRouter, Claude, ChatGPT, DeepSeek, 프롬프트 엔지니어링, 개발 효율화, 도구 소개
1. Fable가 죽었다. 이제 곤란하다
솔직히 말씀드리겠습니다. Fable에는 한참 못 미칩니다.
이 글을 쓰는 시점에서, Anthropic이 제공했던 AI 코딩 에이전트 「Fable」은 서비스를 종료했습니다. 그 정확도, 그 속도, 그 통합감. 이를 뛰어넘는 대안은 아직 존재하지 않습니다.
그렇다고 손 놓고 있을 수만은 없습니다. 대안을 찾아보면 다음과 같은 얼굴들이 있습니다.
- Claude Code / Claude Sonnet: 똑똑합니다. 하지만 단독으로는 Fable의 정확도에 못 미치고, 비용도 부담스럽습니다
- GPT-5 / GPT-5.5: 의외로 부실합니다. 긴 코드베이스를 다루면 금방 숨이 찹니다. 게다가 비쌉니다
- Cursor / Windsurf: 체감은 좋지만 백엔드 모델에 좌우됩니다. 자유로운 구성은 어렵습니다
- 로컬 LLM(Ollama 등): 속도는 나오지만 실제 리포지토리를 넘기면 정확도가 확 떨어집니다
그렇게 이것저것 시도해 본 끝에 도달한 것이, OpenRouter의 Fusion 기능+중국 LLM으로 코드를 생성하고, 마무리로 gpt-5.5-pro 리뷰 또는 Codex의 PR 리뷰를 거치는 구성입니다. Fable에는 전혀 못 미치지만, 순수 gpt-5.5보다는 훨씬 낫습니다. 어느 정도 쓸 만합니다.
다만, 중국 LLM이라 업무용 코드를 먹이기에는 역시 무섭습니다. 어디까지나 취미 프로젝트나 개인 개발 범위에서 쓰는 것을 전제로 합니다.
2. OpenRouter Fusion이란
OpenRouter는 여러 LLM 제공사를 하나의 인터페이스로 호출할 수 있는 API 게이트웨이입니다. Claude도 GPT도 Gemini도 DeepSeek도, 전부 같은 인터페이스로 쓸 수 있습니다.
이 OpenRouter에는 「Fusion」이라는 기능이 있습니다.
간단히 말하면, 하나의 프롬프트를 여러 모델에 던지고, 그 답변들을 분석한 다음, 최종 출력을 하나의 모델이 정리하는 구조입니다. 말하자면 「모델들의 합의체」입니다.
구체적으로는 다음과 같은 흐름으로 동작합니다.
- 사용자가 프롬프트를 입력한다
analysis_models에 지정한 여러 모델이 동시에 같은 프롬프트에 답변을 생성한다- 그 답변들을
model에 지정한 모델이 비교·분석하여, 합의점·불일치점·빠진 부분·사각지대 등을 구조화한다(= judge 역할) - 이어서, 같은 모델이 그 분석을 바탕으로 최종 답변을 작성한다
중요한 점은, 각 분석 모델에 별도의 역할이나 프롬프트를 줄 수는 없다는 것입니다. 모든 모델이 같은 프롬프트를 받고, 각자 독립적으로 답변하며, 그 차이를 judge가 평가하는——그런 단순한 구조입니다.
opencode라는 CLI 코딩 에이전트는 이 Fusion을 플러그인으로 네이티브 지원합니다. opencode.json에 설정만 적으면, 여러 모델이 협력해서 코드를 생성·리뷰하는 에이전트를 손에 넣을 수 있습니다.
3. 실제 설정
다음은 제가 현재 사용 중인 opencode.json의 핵심 부분입니다.
{
"model": "openrouter/openrouter/fusion",
"provider": {
"openrouter": {
"models": {
"openrouter/fusion": {
"name": "OpenRouter Fusion (Custom DeepSeek V4 Pro)",
"options": {
"plugins": [
{
"id": "fusion",
"analysis_models": [
"xiaomi/mimo-v2.5-pro",
"z-ai/glm-5.1",
"deepseek/deepseek-v4-pro",
"moonshotai/kimi-k2.7-code",
"minimax/minimax-m3"
],
"model": "deepseek/deepseek-v4-pro",
"max_tool_calls": 8
}
]
}
}
}
}
}
}
5개의 분석 모델과 1개의 실행 모델로 구성되어 있습니다.
분석 모델(모두가 같은 프롬프트를 보고 동시에 답변한다)
| 모델 | 개발사 | 특징 |
|---|---|---|
xiaomi/mimo-v2.5-pro |
Xiaomi(小米) | 중국 최대급 스마트폰 제조사 제작. 가격 대비 성능이 매우 높음 |
z-ai/glm-5.1 |
Zhipu AI(智譜AI) | 清华大学(칭화대학) 출신. 중국어권 벤치마크에서 상위권 상주. 논리적 추론에 강함 |
deepseek/deepseek-v4-pro |
DeepSeek(深度求索) | 말할 필요 없는, 중국발 파괴적 LLM. 코딩 성능이 두드러짐 |
moonshotai/kimi-k2.7-code |
Moonshot AI(月之暗面) | 코드 생성 특화 모델. 긴 컨텍스트 처리에 정평이 있음 |
minimax/minimax-m3 |
MiniMax(稀宇科技) | 멀티모달·긴 텍스트 처리에서 평가가 급상승 중인 신예 |
실행 모델(분석 결과를 바탕으로 최종 답변을 작성한다)
deepseek/deepseek-v4-pro: 분석 모델들의 답변을 바탕으로, 실제 코드 생성·파일 편집을 담당합니다.
왜 중국 LLM인가
단순히 가격 대비 성능이 압도적이기 때문입니다.
2026년 현재, 중국발 LLM은 API 가격이 Anthropic이나 OpenAI의 5분의 1에서 20분의 1 수준이면서, 성능은 동등하거나 그 이상입니다. 특히 DeepSeek V4 Pro의 코딩 성능은 실무 수준에서 Claude Sonnet이나 GPT-5.5와 맞먹거나 그 이상으로 느껴지는 경우가 적지 않습니다.
4. 어떻게 동작하는가 ── Fusion만으로는 부족하다
Fusion 단독의 흐름은 이렇습니다.
- 사용자가 프롬프트를 입력
- 5개의 분석 모델이 각자 독립적으로 답변을 생성
- 실행 모델(DeepSeek V4 Pro)이 그 답변들을 비교·분석하여, 합의점·불일치점·빠진 부분을 추출한 구조화된 분석을 생성한다
- 그 분석을 바탕으로, 같은 실행 모델(DeepSeek V4 Pro)이 최종 코드를 생성한다
이는 인간 팀 개발과 비슷합니다. 5명의 엔지니어가 같은 스펙을 보고 각자 리뷰 의견을 내고, 1명(DeepSeek V4 Pro)이 그것을 분석·정리한 다음 구현한다——그런 이미지입니다.
컨텍스트 윈도우 제한에 대해: Fusion의 컨텍스트 윈도우는 128K 토큰입니다. 얼핏 적어 보이지만, 대화 이력에 5개 모델의 답변을 모두 포함해야 하므로 의외로 금방 채워집니다. 다만 당황할 필요는 없습니다. 128K를 넘어 Fusion의 합성 단계가 실패해도, 각 분석 모델은 개별적으로(DeepSeek V4 Pro는 100만 토큰, Kimi K2.7은 약 26만 토큰 등, 각각 충분히 큰 컨텍스트 윈도우로) 프롬프트 처리를 마친 상태입니다. opencode도 세션 전체의 대화 이력을 유지하고 있으므로, 모델의 「기억」이 사라지는 것은 아닙니다. 실용상 큰 문제는 되지 않는다는 것이 실제 체감입니다.
하지만 이것만으로는 Fable에는 전혀 미치지 못합니다. 어쨌든 Fable은 단일 모델이면서도 여러 모델 합의체를 가볍게 능가하는 정확도를 냈습니다. Anthropic의 저력입니다.
그래서 Fusion의 출력에 한 단계 더 리뷰 레이어를 추가합니다. 선택지는 두 가지입니다.
선택지 A: gpt-5.5-pro에 의한 코드 리뷰
- Fusion 구성으로 코드 생성
- 생성된 코드를 gpt-5.5-pro에게 「리뷰하고 수정안을 내라」고 던진다
- 그 수정안을 원래 실행 모델에 적용시킨다
gpt-5.5-pro는 단독 코드 생성으로는 부실하지만, 기존 코드 리뷰는 의외로 잘합니다.
선택지 B: GitHub Codex의 PR 리뷰
- Fusion 구성으로 코드 생성
- PR로 올려서, GitHub Codex의 PR 리뷰를 거친다
- Codex가 버그 가능성이나 설계상의 우려를 지적해 주므로, 이를 반영한다
Codex는 GitHub의 맥락(이슈, 과거 PR, 프로젝트 구조)을 반영한 리뷰를 하므로, 범용 LLM 리뷰와는 다른 관점으로 파고듭니다.
둘 중 하나만으로도 충분합니다. Fusion(5개 모델 합의) → 리뷰(gpt-5.5-pro 또는 Codex)의 이단 구성. Fable 한 번에는 한참 못 미치는 만큼, 프로세스로 보완한다는 발상입니다.
순수 gpt-5.5에서 자주 벌어지는 라이브러리 버전 오류나 존재하지 않는 API 사용은, 이 구성으로 꽤 줄었습니다.
5. 속도와 실용성
속도 자체는 단일 모델과 크게 다르지 않습니다. 5개 모델이 병렬로 동작하므로, 실제 응답 시간은 감내할 만한 수준입니다.
문제는 정확도입니다. Fable이라면 한 번에 통과할 부분에서, 이 구성은 몇 차례 재작업이 발생합니다. 결과적으로 전체 개발 시간은 Fable보다 명백히 느립니다. 틀리는 만큼 느려집니다.
다만, 순수 gpt-5.5보다는 훨씬 낫습니다. Fusion+리뷰로 생성된 코드는 처음부터 꽤 정답에 가깝고, gpt-5.5 단독으로 생성→수정→수정→수정의 무한 루프에 빠지는 것보다는 확실히 빠릅니다.
체감으로는, 「속도는 나쁘지 않다. Fable에는 정확도로 한참 못 미치지만, 순수 gpt-5.5보다는 몇 단계 낫다」 정도의 균형입니다.
6. 덧붙여: 리뷰 레이어와 그 밖의 opencode 설정
리뷰 레이어: gpt-5.5-pro 또는 Codex PR 리뷰
Fusion 구성만으로는 미덥지 않으므로, 둘 중 하나를 리뷰 레이어로 사용합니다.
gpt-5.5-pro: opencode의 task 기능으로 서브 에이전트에 지정하여, 생성된 코드를 「리뷰하고 수정안을 제안하라」고 지시합니다. 처음부터 코드를 작성시키면 미묘하지만, 남이 쓴 코드의 결점 찾기는 유난히 잘합니다.
GitHub Codex: PR을 올리는 시점에 Codex의 PR 리뷰를 돌립니다. 프로젝트 전체 맥락을 반영한 리뷰를 해 준다는 점이, 범용 LLM 리뷰와는 다른 맛입니다.
어느 쪽을 쓸지는 그날 기분에 따라 다릅니다. 둘 다 쓰는 건 확실히 과하고 너무 느립니다.
그 밖의 설정
opencode.json에는 Fusion 외에도 실용적인 설정을 몇 가지 넣어 두었습니다.
{
"permission": {
"read": "allow",
"glob": "allow",
"grep": "allow",
"task": "allow",
"webfetch": "allow",
"websearch": "allow",
"lsp": "allow",
"edit": "allow",
"bash": {
"*": "allow",
"Remove-Item *": "deny",
"del *": "deny",
"rm *": "deny",
"rmdir *": "deny",
"rd *": "deny",
"erase *": "deny",
"git clean *": "deny"
}
},
"experimental": {
"primary_tools": ["task"]
}
}
포인트는 두 가지입니다.
1. 삭제 계열 명령 차단
Remove-Item, del, rm, rmdir, rd, erase, git clean을 명시적으로 거부하고 있습니다. AI 에이전트에게 파일 삭제를 맡기는 것은 무섭기 때문입니다. 정말로 삭제가 필요할 때는 직접 합니다.
2. primary_tools: ["task"]
서브 에이전트(task)를 통한 병렬 탐색을 우선시하고 있습니다. 큰 코드베이스에서 여러 파일을 동시에 읽거나 검색할 때, task를 경유하는 쪽이 압도적으로 빠릅니다.
7. 마무리
Fable의 종료는 아픕니다. 정말로 아픕니다. 이를 뛰어넘는 것은 아직 없습니다.
하지만 손 놓고 있을 수는 없으니, OpenRouter Fusion+중국 LLM으로 생성하고, gpt-5.5-pro 또는 Codex PR 리뷰로 마무리하는 구성으로 버티고 있습니다.
이 구성의 요점:
- OpenRouter Fusion으로 5개 모델의 「합의체」에 의한 코드 생성
- 분석 모델: Xiaomi Mimo / GLM / DeepSeek / Kimi / MiniMax
- 실행 모델: DeepSeek V4 Pro
- 마무리 리뷰 레이어: gpt-5.5-pro 또는 Codex PR 리뷰(둘 중 하나)
- 속도는 단일 모델과 비슷. 다만 Fable보다 정확도가 떨어지는 만큼 재작업으로 느려짐
- 순수 gpt-5.5보다는 훨씬 나음. Fable에는 한참 못 미치지만 실용에는 견딜 만함
- 중국 LLM이라 업무용 코드에는 쓰기 어려움. 취미·개인 개발까지가 한계
AI 코딩 에이전트로 「Fable 상실감이 힘들다」, 「순수 gpt-5.5가 너무 부실하다」고 느끼는 분이라면, 임시방편으로 시도해 볼 가치는 있습니다.
OpenRouter 계정만 있으면, 오늘부터 바로 쓸 수 있습니다.
참고 링크
관련 기사
같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.
챗봇 작성의 베스트 프랙티스 - 무엇이든 답하는 상자로 끝내지 않고, 업무에서 도움 되는 도선으로 만든다
챗봇은 모델 선정 전에 용도, 지식 정본, 권한, 인계 조건, 평가 세트를 정해야 실무에서 기능합니다. Web 사이트용·사내용 양쪽에 통하는 설계 순서와 90일 도입 흐름, 자주 있는 실패까지 정리해, 문의 도선이나 자체 해결률로 이어지는 형태로...
PerfView와 dotnet-trace로 “느림”의 원인을 찾는다 ── .NET 성능 조사 실무 입문
업무 앱이 “느리다”, “CPU를 다 써버린다”, “가끔 멈춘다”고 할 때, 어떤 도구로 무엇을 봐야 할까요. PerfView와 dotnet-trace의 역할 분담, CPU 샘플링을 읽는 방법(inclusive/exclusive), ThreadT...
BtoB용 구글 광고 소액 운영 - 월 몇만 엔으로 성과를 내는 설계와 주간 운영 절차
월 몇만 엔의 예산으로 구글 광고를 시작하려는 BtoB 기업을 위한 실무 가이드입니다. 평균 일일 예산과 청구 상한의 구조, 전환 측정 정비, 고의도 키워드로의 압축, 제외 키워드와 검색어 보고서의 주간 운영, 소액 예산에서의 입찰 전략 선택까지...
지역명 검색에 노출되는 사이트 만들기 - 중소기업을 위한 로컬 SEO 실전 가이드(지역 페이지와 구글 비즈니스 프로필)
'지역명+업종'으로 검색했을 때 자사가 나오지 않는 중소기업을 위해, 로컬 SEO를 고치는 순서를 정리합니다. 구글 비즈니스 프로필 정비, NAP 정보 통일, 지역 페이지 설계, 사이트 측 기반 다지기, Search Console을 통한 효과 측...
Windows 이벤트 로그·ETW 입문 ── 업무 앱의 로그를 OS 표준 체계에 올리기
Windows 업무 앱의 로그를 파일 로그만으로 해결하고 있지는 않은가요? 이벤트 로그와 ETW는 운영 담당자나 OS 표준 도구에서 보이는 또 다른 계층의 기록입니다. 3가지 수단을 구분해서 쓰는 방법, .NET에서 기록하는 방법, EventSo...
관련 토픽
이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.
Windows 기술 토픽
Windows 개발, 장애 조사, 기존 자산 활용에 관한 KomuraSoft LLC 기사를 모은 토픽 허브입니다.
자주 묻는 질문
이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.
- OpenRouter의 Fusion은 어떤 기능인가요?
- 하나의 프롬프트를 여러 모델에 동시에 던지고, 그 답변들을 하나의 모델(judge 역할)이 비교·분석해 합의점·불일치점·빠진 부분을 구조화한 뒤, 같은 모델이 그 분석을 바탕으로 최종 답변을 작성하는 구조입니다. 말하자면 모델들의 합의체입니다. 각 분석 모델에 별도의 역할이나 프롬프트를 줄 수는 없고, 모든 모델이 동일한 프롬프트를 받습니다. CLI 코딩 에이전트인 opencode는 Fusion을 플러그인으로 네이티브 지원하며, opencode.json에 설정만 적으면 바로 사용할 수 있습니다.
- 왜 중국 LLM을 쓰는 건가요?
- 가격 대비 성능이 압도적이기 때문입니다. 2026년 현재, 중국산 LLM은 API 가격이 Anthropic이나 OpenAI의 5분의 1에서 20분의 1 수준이면서 성능은 동등하거나 그 이상입니다. 특히 DeepSeek V4 Pro의 코딩 성능은 실무 수준에서 Claude Sonnet이나 GPT-5.5와 맞먹거나 그 이상으로 느껴지는 경우가 적지 않습니다. 다만 중국 LLM에 업무용 코드를 맡기는 것은 위험이 있으므로, 취미 프로젝트나 개인 개발 범위에서 쓰는 것을 전제로 합니다.
- Fusion만으로는 왜 부족한가요?
- 5개 모델의 합의체로도 Fable의 정확도에는 미치지 못하기 때문입니다. 그래서 Fusion의 출력에 리뷰 레이어를 한 단계 추가합니다. 선택지는 생성된 코드를 gpt-5.5-pro에게 리뷰시켜 수정안을 적용하는 방법과, PR로 올려서 GitHub Codex의 PR 리뷰를 거치는 방법 두 가지이며, 어느 한쪽만으로도 충분합니다. gpt-5.5-pro는 단독 코드 생성 성능은 낮은 반면 기존 코드 리뷰에는 강하고, Codex는 프로젝트 전체 맥락을 반영한 지적을 해 줍니다.
- 이 구성의 실용성은 어느 정도인가요?
- 속도는 5개 모델이 병렬로 동작하기 때문에 단일 모델과 크게 다르지 않습니다. 다만 정확도는 Fable에는 한참 못 미치며, 재작업이 발생하는 만큼 전체 개발 시간은 명백히 더 걸립니다. 그래도 순수 gpt-5.5 단독으로 생성과 수정의 무한 루프에 빠지는 것보다는 확실히 빠르고, 라이브러리 버전 오류나 존재하지 않는 API 사용도 꽤 줄었습니다. OpenRouter 계정만 있으면 바로 시도해 볼 수 있습니다.
저자 프로필
기사 저자의 프로필 페이지입니다.
Go Komura
합동회사 코무라소프트 대표
Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.
공개 링크