OpenRouter Fusion 출시가 주목받는 이유: API로 구현된 모델 합성 루프

OpenRouter Fusion의 출시는 제 관심을 끌었습니다. 왜냐하면 이는 기본적으로 제가 한동안 수동으로 실행해 오던 루프를 그들이 API로 전환한 것이기 때문입니다.

Fusion이 하는 일은 하나의 프롬프트를 모델 패널(panel of models)에 보내면, 심사역(judge)이 모델들이 서로 동의하는 부분, 서로 모순되는 부분, 그리고 각 모델이 놓친 부분이 무엇인지 살펴본 뒤, 합성기(synthesizer)가 이를 바탕으로 최종 답변을 작성하는 방식입니다.
그들은 Fable 수준의 결과를 절반의 가격으로 제공한다고 주장하고 있으며, 제가 계속 주목하게 되는 세부 사항은 성능 향상의 약 4분의 3이 합성(synthesis) 단계에서 오고, 모델들이 실제로 다르게 생각하는 데서 오는 것은 4분의 1에 불과하다는 점입니다. 이는 제가 목격해 온 것과 일치합니다. 가치는 단순히 방 안에 여러 모델을 두는 것이 아니라, 결합(combining)과 검증(checking)에 있습니다.

제가 이를 실행하는 방식은, Opus 4.8은 Claude Code에 두고 GPT 5.5 xhigh는 Codex에 둡니다. 이들은 단순히 복사해서 붙여넣는 두 개의 탭이 아닙니다. 이들은 작은 로컬 브리지(local bridge)를 통해 서로의 세션을 시작하고 재개할 수 있는 동료 에이전트(peer agents)입니다. 특정 시점에는 한 모델이 구현(implementation)을 담당하고, 다른 모델은 검토(review) 용도로만 투입되어, 조용히 작업을 가로채지 않고 반론을 제기할 수 있게 합니다.
모든 인수인계(handoff)는 누가 담당했는지, 어떤 역할을 수행했는지, 어떤 파일에 접근했는지, 그리고 실제로 무엇을 검증했는지를 포함하여 공유 파일에 기록됩니다. 정말 어려운 문제가 발생하면 GPT 5.5 Pro로 에스컬레이션(escalate)하여 결론을 도출합니다.

Fable이 중단되기 전 약 이틀 동안 Fable 5와 GPT 5.5를 사용하여 이 방식을 실행했을 때는 정말 마법 같았습니다.
두 모델이 서로의 실수를 너무나 깔끔하게 잡아내어 제가 개입할 일이 거의 없었습니다. Fable을 잃은 이후에는 Opus 4.8과 GPT 5.5로 실행하고 있는데, 그 정도까지는 아니지만 여전히 매우 훌륭합니다. 아키텍처(architecture)가 대부분의 비중을 차지하기 때문에, 약간 덜 유능한 조합이라 하더라도 결과물은 유지됩니다.

이것이 작동하는 비결은 규율(discipline)에 있습니다. 어느 에이전트도 상대방의 결과물을 무조건 승인(rubber stamp)할 수 없기 때문입니다. Codex가 코드 한 줄을 작성하기 전에 Claude가 데이터 계약(data contract)을 검토하며, Codex는 Claude의 주장을 맹목적으로 믿는 대신 실제 코드베이스(codebase)를 바탕으로 다시 확인합니다.

핸드오프 파일(handoff file)은 메모리 역할을 하므로, 몇 주가 지난 후에도 Claude가 무엇이라고 말했는지 물어보거나 Codex의 정확한 스레드(thread)를 재개할 수 있습니다.

관심 있는 분들이 계신다면, MCP 설정과 이 모든 것을 오케스트레이션(orchestrate)하는 기술들을 공유할 수 있습니다.