무엇이 출시되었고, 실제로 무엇이 가능해졌는가
ori는 curl -fsSL https://openrouter.ai/labs/ori/install.sh | bash 명령어로 설치할 수 있습니다. OpenRouter 자격 증명으로 로그인하고 이를 통해 하네스(harness)를 실행하면 됩니다. OpenRouter는 이 도구가 해결하는 문제에 대해 솔직하게 밝히고 있습니다: "OpenRouter와 같은 게이트웨이를 사용할 때, Anthropic의 퍼스트 파티 하네스를 사용할 때와 동일한 Claude Code 경험을 즉시 얻으려면 설정해야 할 환경 변수가 아주 많습니다." 또한 이 CLI는 실행 중인 환경에 맞게 조정됩니다 — "ori claude에서는 사용자의 --model 플래그를 감지하여 사용 중인 모델에 가장 최적화된 설정으로 전환합니다."
이와 함께 OpenRouter의 Claude Code 쿡북에는 3개의 환경 변수를 사용하여 CLI를 Anthropic 호환 엔드포인트로 리디렉션하는 방법이 문서화되어 있습니다. 이 설정이 완료되면 크레딧을 통해 결제되는 Claude 모델을 계속 사용하거나, Opus, Sonnet, Haiku "슬롯"을 GLM-5.2, DeepSeek V4, Qwen3-Coder, Kimi와 같은 더 저렴한 오픈 모델로 대체할 수 있습니다.
Google의 게이트웨이 접근 방식은 인프라 측면에서 동일한 동작을 목표로 합니다: OpenAPI 3.x 사양에 가상 모델 이름을 구성하고, 이를 Gemini, Claude, OpenAI의 OSS-GPT 모델을 포함한 백엔드로 지정하여 엔드포인트를 하드코딩하거나 자체 프록시를 실행하지 않고도 트래픽을 라우팅할 수 있습니다.
가격 책정 역시 같은 방향으로 흘러가고 있습니다. OpenAI 팀은 GPT-5.6 Luna의 80% 가격 인하가 프로모션이 아닌 영구적인 조치라고 공개적으로 밝혔으며, 같은 주에 발표된 업계 분석에 따르면 이는 Anthropic의 Fable 5가 출력 토큰 100만 개당 $50로 출시된 지 며칠 만에 이루어진 일입니다. 구체적인 수치는 2026년 8월 초 기준이므로 계획을 세우기 전에 현재 가격을 확인하시기 바랍니다 — 하지만 방향성은 확실합니다: 모델 선택은 이제 작업별로 결정하는 사안이 되고 있으며, 도구들은 이제 사용자가 모델을 자주 전환할 것이라고 가정하고 있습니다.
모델을 전환할 때 컨텍스트가 초기화되는 이유
모델은 호출 간에 상태를 유지하지 않습니다
모든 요청은 독립적입니다. 모델이 프로젝트에 대해 "알고 있는" 것처럼 보이는 모든 정보는 해당 요청의 컨텍스트 창을 통해 전달되었으며, 요청이 끝나면 함께 사라집니다. Cursor의 자체 문서에서도 이 일반적인 상황을 명확히 밝히고 있습니다: "대규모 언어 모델은 완성(completion) 간에 메모리를 유지하지 않습니다." 라우팅을 사용한다고 해서 이 사실이 바뀌지는 않습니다 — 게이트웨이는 요청을 전달할 뿐, 지식을 축적하지 않습니다.
각 벤더의 메모리 기능은 해당 벤더에만 종속됩니다
현재 사용하는 도구들에는 유용한 메모리 기능들이 탑재되어 있습니다. 하지만 이 기능들은 각각 자체 제품에 종속되어 있습니다: Claude의 메모리 항목, ChatGPT의 합성된 크로스 채팅 메모리, Codex의 로컬 메모리 파일, IDE의 규칙 디렉토리 등이 그렇습니다. 요청을 다른 백엔드로 라우팅하면 이 중 어떤 것도 따라가지 않습니다. 애초에 요청의 일부가 아니었기 때문입니다.
하네스 설정은 컨텍스트가 아닙니다
이것이 바로 ori를 사용할 때 저지르기 쉬운 실수입니다. 환경 변수, 모델 슬롯, 추론 설정이 모두 자동으로 처리되면 전환이 완벽하게 완료된 것처럼 느껴집니다 — 도구가 시작되고, 모델이 응답하며, 모든 것이 구성된 것처럼 보입니다. 하지만 실제로 이동한 것은 배관(연결 구조)뿐입니다. 코드베이스에 대해 축적된 지식, 결정 사항, 막다른 골목, 특정 모듈이 잘못되어 보이지만 그대로 유지해야 하는 이유 등은 전혀 이동하지 않았습니다.
저렴한 모델은 문제를 덜 보이게 만드는 것이 아니라 더 도드라지게 만듭니다
라우팅의 경제적 명분은 확실합니다: 일상적인 작업은 저렴한 모델로 보내고, 비싼 모델은 어려운 문제를 위해 아껴두는 것입니다. 하지만 컨텍스트가 없는 저렴한 모델은 수정해야 할 결과물을 만들어내고, 이를 수정하는 데는 절약하려 했던 사람의 시간이 소모됩니다. 비용 절감은 저렴한 모델이 비싼 모델과 동일한 이해도를 가지고 시작할 때만 실제로 실현됩니다.
사람들이 시도하는 방법들
브리핑 다시 붙여넣기. 모든 세션의 시작 부분에 프로젝트 컨텍스트 블록을 붙여넣는 방식입니다. 효과가 있고 범용적이어서 거의 모든 사람이 이 방식을 사용합니다. 하지만 매 호출마다 토큰 비용이 발생하며, 요약본이기 때문에 누군가 더 짧게 다시 쓸 때마다 세부 정보가 유실됩니다.
지침 파일. AGENTS.md, .cursor/rules, CLAUDE.md, .trae/rules. 이 파일들은 항상 적용되어야 하는 규칙을 정의하는 데 적합한 도구이며, 대부분의 하네스는 백엔드 모델에 관계없이 이 파일들을 읽으므로 가장 이식성이 높은 옵션입니다. 하지만 이는 지식 저장소가 아닙니다: 매주 늘어나는 900줄짜리 서문을 수동으로 관리하고 싶어 하는 사람은 없으며, 모든 요청마다 로드되는 규칙은 매 요청마다 비용을 지불해야 하는 규칙이 됩니다.
모든 작업에 하나의 모델만 유지하기. 가장 간단한 해결책은 전환을 피하는 것입니다. 하지만 이는 사소한 작업에도 프리미엄 요금을 지불해야 하고, 특정 작업에 실제로 가장 적합한 모델을 사용하지 못한다는 것을 의미합니다.
도구별 메모리 기능. 모든 곳에서 메모리 기능을 켜고 잘 작동하기를 바라는 방식입니다. 결국 서로 어긋나는 여러 개의 불완전한 그림을 얻게 되며, 가장 중요한 순간에 이들이 서로 달라졌음을 깨닫게 됩니다. 이는 공유 메모리 없이 여러 에이전트가 작동할 때 발생하는 실패와 동일합니다.
리포지토리 검색(Retrieval). 유용하며 아무것도 없는 것보다 낫습니다. 검색은 쿼리와 유사한 텍스트를 찾아내지만, 지난 6월에 내린 결정이나 이미 거부한 접근 방식은 기억하지 못합니다. 이것이 바로 검색 자체만으로는 메모리가 될 수 없는 이유입니다.
해결책: 라우터가 건드릴 수 없는 레이어에 컨텍스트 유지하기
이제 모델이 교체 가능한 컴포넌트가 되었다면, 컨텍스트는 모델 내부에 머물러서는 안 됩니다. 지식을 자체 레이어에 두고, 어떤 모델로 라우팅하든 그 레이어에서 읽을 수 있도록 하세요 — ori가 어떤 모델을 선택하든 동일한 하네스를 사용할 수 있게 해주는 것과 같은 방식입니다.
MemoryLake는 스택에서 정확히 그 위치를 위해 구축되었습니다: 이전에 어떤 모델이 응답했는지와 무관하게 MCP 또는 API를 통해 액세스할 수 있는 독립적인 레이어로서의 메모리입니다.
1단계: API 키 생성
키를 생성하고 약 30초 만에 첫 번째 요청을 보내보세요.
2단계: 첫 번째 메모리 업로드
어떤 모델이 작동하든 상관없이 모든 모델에 필요한 자료를 로드하세요: 아키텍처 노트, API 계약서, 결정 로그, 런북, 코드만으로는 명확하지 않은 컨벤션 등이 이에 해당합니다. 문서, 이미지 및 기타 파일이 모두 같은 장소로 저장됩니다.
3단계: AI 및 에이전트 연결
Claude, Codex, OpenClaw 및 기타 에이전트에 MCP를 통해 액세스 권한을 부여하세요. 네이티브 MCP 클라이언트가 아닌 게이트웨이를 통해 접근하는 경우, API를 통해 관련 메모리를 검색하여 라우터가 전달하는 요청에 포함시키세요. 라우팅 경로는 바뀌어도 모델이 프로젝트에 대해 알고 있는 정보는 바뀌지 않습니다.
실제 업무에서 달라지는 점
첫 번째 효과는 라우팅 결정이 순수하게 경제적인 관점에서 이루어진다는 점입니다. 현재로서는 더 저렴한 모델을 선택할 때 '컨텍스트 재구축 비용'이라는 숨겨진 비용이 발생합니다 — 이 때문에 팀들은 굳이 필요하지 않은 작업에도 비싼 모델을 묵묵히 계속 사용하곤 합니다. 이 비용을 제거하면 "이 작업에 어떤 모델을 쓸 것인가"는 오직 가격과 성능만으로 답할 수 있게 되며, 이는 전체 라우팅 생태계가 구축된 전제이기도 합니다.
두 번째는 새로운 모델 출시가 더 이상 기존 워크플로우를 방해하지 않는다는 점입니다. 지난 몇 달 동안 전환할 가치가 있는 프론티어 모델이 6~7개 출시되었습니다. 새 모델을 평가할 때마다 코드베이스에 대한 이해를 처음부터 다시 구축해야 한다면, 결국 장난감 같은 간단한 문제로만 평가하게 되어 유용한 정보를 얻지 못할 것입니다. 컨텍스트가 공유된다면 동일한 메모리를 가리키게 하여 반나절 만에 실제 비교 결과를 얻을 수 있습니다.
세 번째는 혼합 플릿(mixed fleet) 전반의 일관성입니다. 저렴한 모델이 테스트 스캐폴딩을 처리하고 프론티어 모델이 아키텍처를 처리하는 경우, 두 모델은 시스템에 대해 동일한 이해를 바탕으로 작동해야 합니다. 그렇지 않으면 저렴한 모델의 결과물이 비싼 모델의 설계와 모순되어 누군가 이를 잡아내야 하는 번거로움이 생깁니다.
다중 모델 구성을 위한 모범 사례
규칙과 지식을 다른 곳에 보관하세요
지침 파일은 하네스와 모델 간에 쉽게 이식할 수 있으므로 항상 적용되어야 하는 규칙에 사용하세요. 대신 계속 늘어나는 프로젝트 지식은 메모리 레이어에 두어, 매 요청마다 거대한 서문 비용을 지불하지 않고 매주 변경되는 파일을 수동으로 편집하지 않도록 하세요.
라우팅 대상뿐만 아니라 라우팅한 이유를 기록하세요
"테스트 생성은 저렴한 모델로 보낸다"는 결정은 새벽 2시에 대기 중인 당직자에 의해 소리 소문 없이 뒤집힐 수 있습니다. 반면 "테스트 생성은 저렴한 모델로 보낸다. 프론티어 모델의 우위가 우리 테스트 스위트에서 3% 미만으로 측정되었기 때문이다"라는 기록은 살아남아 다음 사람에게 무엇을 다시 측정해야 하는지 알려줍니다.
재라우팅 시 사실 관계를 다시 확인하세요
모델의 성능, 컨텍스트 제한, 가격은 매달 변하고 있으며, 이 글에 언급된 세부 정보는 2026년 8월 초 기준입니다. 라우팅 정책을 확정하기 전에 소스에서 현재 수치를 확인하세요. Opus 5, DeepSeek V4, GPT-5.6 등 지금까지의 모든 모델 전환에서 얻은 일반적인 교훈은 여러분이 신경 써야 할 벤치마크는 바로 여러분 자신의 코드베이스라는 점입니다.
결론
이번 주에 도구들이 마침내 따라잡았습니다. ori를 사용하면 한 줄의 설치만으로 모든 모델에 대해 Claude Code, Codex, OpenCode, Hermes를 실행할 수 있으며, 게이트웨이 수준의 라우팅 덕분에 인프라 레이어에서도 동일한 작업이 가능해졌습니다. 모델 선택은 이제 작업별로 결정하는 사안이 되었으며, 전환을 꺼리게 만들던 마찰은 대부분 사라졌습니다.
하지만 매일의 업무에서 가장 중요한 문제는 아직 해결되지 않았습니다. 모델은 호출 간에 상태를 유지하지 않고, 벤더별 메모리 기능은 다른 벤더와 호환되지 않으며, 완벽하게 구성된 하네스라 할지라도 여전히 여러분의 리포지토리를 낯선 사람에게 넘겨주는 꼴이 됩니다. 프로젝트 지식이 라우팅 대상 모델의 외부에 있는 레이어에 존재하기 전까지는, 전환할 때마다 기존 컨텍스트를 잃게 되며, 전환한 저렴한 모델은 잘못된 결과를 내놓음으로써 절약한 비용을 고스란히 낭비하게 만들 것입니다.