이 시리즈의 첫 번째 파트에서 나는 프롬프트 엔지니어링 (Prompt Engineering) — 즉, 문구를 작성하는 기술 — 이 사라지고 있으며, 그 노력이 사라진 것이 아니라 스택(stack)의 위로 올라갔다고 주장했습니다. 이것이 바로 그 노력이 올라온 지점입니다.

여기에 새로운 마찰(friction)이 있습니다. 나는 어떤 과업을 수행하기 위해 앉았을 때, 아무것도 하기 전에 격자(grid)를 마주하게 됩니다. OpenAI는 이제 GPT-5.6을 Sol, Terra, Luna라는 세 가지 티어로 출시하며, 여러 가지 추론 노력 (reasoning-effort) 설정과 새로운 max 레벨을 제공합니다. 여전히 순환 사용 중인 이전 5.x 모델들과 Codex 변체들을 더하면, 한 벤더가 이미 수십 개의 그럴듯한 (모델 × 노력) 경로를 제공하는 셈입니다. Claude의 노력 사다리 (effort ladder)는 low, medium, high, max로 구성되며, 지원되는 모델에서는 xhigh도 제공됩니다. Gemini에는 사고 예산 (thinking budget)이 있습니다. 이제 문구를 어떻게 작성하느냐는 더 이상 결정 사항이 아닙니다. _할당 (allocation)_이 결정 사항입니다. 즉, 어떤 작업을 어떤 조각으로 나눌 것인지, 어떤 모델을 어떤 노력 수준으로 사용할 것인지입니다. 이것을 제대로 해내는 것이 내가 라우팅 엔지니어링 (routing engineering)이라 부르는 것이며, 이는 조용히 가장 가치 있는 기술 중 하나가 되었습니다.

아무도 요청하지 않은 매트릭스 (matrix)

불편한 점은 이 격자가 우리가 이를 추론할 수 있는 능력보다 더 빠르게 성장했다는 것입니다. 단일 모델이 하나의 설정만을 가졌을 때는

저의 기본 방식은 부끄러울 정도로 단순하며, 그것은 바로 라우팅 (routing) 결정입니다. Claude Code에서 저는 Fable 5로 계획을 세운 뒤, Opus나 그보다 가벼운 모델로 실행합니다. 만약 계획 수준의 모델이 전체 작업을 주도하게 두면, 토큰 사용량이 폭발합니다. 지능이 집중되어야 하는 곳은 계획 단계이며, 실행은 대부분 그 계획을 '따라야' 합니다. 이 경계선을 따라 두 단계를 분리한 것이 저에게 긴 에이전트 (agent) 세션을 감당 가능한 수준으로 만들어 준 단 하나의 변화였습니다.

출판 참고 사항: 이 기사가 공개되기 이틀 전, Opus 5가 출시되었습니다. Opus 5는 많은 작업에서 Fable 5에 근접한 성능을 보이면서도 가격은 절반 수준입니다. 이는 이미 저의 플래너 (planner)로서 Fable을 대체했습니다. 기사가 발송되기도 전에 경로가 바뀌어 버렸는데, 이는 주제와 너무나도 잘 맞아떨어집니다.

저는 연구에서도 똑같은 일을 합니다. AI로 논문 작성하기에서 중요한 구분은 과학적 계획을 위한 Fable 5와, 두 번째 검토자로서의 GPT-5.6이었습니다. 즉, 판단력이 살아있는 강력한 모델을 사용하다가, 사용량 제한에 걸리면 교체하고, 그 사이에는 더 저렴한 실행 모델을 사용하는 방식입니다. 이 중 어느 것도 프롬프트 엔지니어링 (prompt craft)이 아닙니다. 이것은 라우팅 (routing)입니다. 즉, 작업의 형태에 맞춰 모델을 매칭하는 것입니다.

분리가 효과적인 이유

'계획은 강력하게, 실행은 저렴하게'라는 이 특정한 경계선이 계속해서 나타나는 이유는, 작업 난이도의 대부분이 몇 가지 결정에 집중되어 있기 때문입니다. Cursor는 최근 이를 수치화했습니다. 장기 실행 에이전트 '스웜 (swarms)'에 관한 연구에서, 그들은 835페이지 분량의 매뉴얼만을 가지고 Rust로 SQLite를 처음부터 구축하는 함대를 운용하며, 누가 계획하고 누가 실행할지를 다양하게 변화시켰습니다. 이 메커니즘에 대한 그들의 요약은 제가 본 원칙 중 가장 명확한 설명입니다:

"대규모 작업 중 진정으로 최첨단 지능 (frontier intelligence)을 요구하는 순간은 몇 안 됩니다. 초기 분해 (decomposition), 설계 결정, 특정 트레이드오프 (trade-offs) 등이 그것입니다. 일단 최첨단 플래너 (frontier planner)가 모호함을 상세하고 명시적인 지침으로 바꾸고 나면, 더 저렴한 모델들은 단순히 그 지침을 따르기만 하면 됩니다."

그 결과, 모든 모델 조합이 _유사한 품질(similar quality)_에 도달한 반면, 비용은 약 8배 차이가 났습니다. Opus-4.8-plans / Composer-2.5-executes 하이브리드 방식의 약 \1,339부터, GPT-5.5가 모든 것을 스스로 수행하는 방식의 \10,565까지 차이가 벌어졌습니다. 실행(execution) 영역만 놓고 보면 그 격차는 더욱 극명했습니다. 저렴한 작업자(workers)들의 비용은 약 \411였던 반면, 모든 과정을 최첨단 모델(all-frontier)로 실행했을 때의 작업자 비용은 \9,373이었습니다. 목적지는 같지만, 요금은 자릿수가 달랐습니다.

그리고 이것은 단순히 벤더(vendor)의 마케팅 주장만이 아닙니다. 기존의 학술적 증거들도 이미 같은 방향을 가리키고 있었습니다. RouteLLM은 각 쿼리를 강력한 모델 또는 약한 모델로 라우팅(routing)함으로써, GPT-4 품질의 95%를 유지하면서도 비용을 최대 85% 절감했다고 보고했습니다. 훨씬 이전의 FrugalGPT는 비용을 최대 98% 낮추면서도 최상위 모델과 대등한 성능을 내는 캐스케이드(cascades) 구조를 보여주었습니다. 이러한 사례들은 이러한 비대칭성이 오늘날의 최첨단 모델에 대한 측정값이 아니라, 이미 수년 전부터 알려져 왔음을 보여주는 유용한 증거들입니다. 보다 최신의 상황은 오히려 더 냉정합니다. 2026년 1월에 발표된 LLMRouterBench는 40만 개 이상의 예시, 21개의 데이터셋, 33개의 모델을 통해 10가지 라우팅 방법을 재평가했습니다. 이 연구는 모델들이 상호 보완적임을 확인했지만, 상용 라우터(commercial routers)를 포함한 여러 최신 방법론들이 단순한 베이스라인(baseline)을 안정적으로 능가하지 못한다는 점을 발견했습니다. 비용 절감은 실재하지만, 이를 안정적으로 추출해내는 것은 여전히 미해결 과제로 남아 있습니다.

이것을 _엔지니어링(engineering)_으로 만드는 부분

만약 이것이 단순히 "똑똑한 모델로 계획을 세워라"는 수준이었다면, 이는 하나의 팁(tip)일 뿐 학문적 규율(discipline)은 아니었을 것입니다. 이것을 엔지니어링으로 만드는 핵심은, 뻔해 보이는 선택이 종종 틀릴 수 있다는 점에 있습니다.

동일한 Cursor 연구에는 제가 계속해서 되새기게 되는 세부 사항이 하나 있습니다. 더 강력하고 새로운 (stronger, newer) 플래너(planner)인 Fable 5를 기반으로 구축된 하이브리드 모델이 Opus 4.8을 기반으로 구축된 모델보다 결과적으로 더 비쌌다는 점입니다. Fable 플래너 자체의 비용은 약간 더 낮았음에도 불구하고 말이죠. 문제는 다운스트림(downstream)에 있었습니다. Fable의 계획이 저렴한 작업자(workers)들로 하여금 몇 배나 더 많은 토큰을 소비하게 만들었고, 실제 볼륨은 작업자 단계에서 발생하기 때문입니다 (작업자들은 모든 실행에서 최소 69%, 대부분의 경우 90% 이상의 토큰을 차지했습니다). 더 나은 플래너가 더 비용이 많이 드는 실행을 만들어낸 것입니다.

이 하나의 데이터 포인트가 교훈의 전부입니다. 경로(route)의 비용은 비선형적(non-linear)이며, 주로 2차 효과(second-order effects) — 즉, 플래너 자체의 가격표가 아니라 계획이 실행을 어떻게 형성하느냐 — 에 존재합니다. 이는 사양서(spec sheet)만 보고는 알 수 없습니다. 경로를 엔드 투 엔드(end to end)로 측정해야 하며, 이것이 바로 엔지니어링 규율(engineering disciplines)이 존재하는 이유입니다.

수동(Manual), 또는 자동(automatic)

제가 하는 방식처럼 수동으로 경로를 지정하거나, 결정을 시스템에 맡길 수 있습니다.

자동화 계층은 빠르게 채워지고 있습니다. Cursor는 이제 각 작업을 분류하여 적절한 모델로 보내는 요청 레벨의 **Router**를 제공하며, 지능, 균형 또는 비용 중 하나로 편향을 설정할 수 있는 Auto 모드를 갖추고 있습니다. 이들은 초기 기업 사용 사례에서 프런티어(frontier) 급 품질을 유지하면서도 30~50%의 비용 절감을 보고했습니다. OpenRouter의 auto 엔드포인트는 (NotDiamond의 모델을 기반으로) 비용 대 품질 조절 다이얼을 통해 프롬프트별로 경로를 지정합니다. Martian과 NotDiamond도 동일한 아이디어를 서비스 형태로 판매합니다. 심지어 "라우팅이 정말로 얼마나 효과적인가"라는 질문에 답하려는 소규모 벤치마크 문헌도 존재하는데, 솔직한 평가는 _유망하지만 아직 정립되지 않았다(promising but unsettled much)_는 것입니다. 일부 라우터는 실제로 돈을 아껴주지만, 면밀히 조사해 보면 일부는 단순히 비싼 모델을 기본값으로 선택할 뿐입니다.

더 깊은 어려움이 있습니다. 바로 작업을 시작하기 전까지는 그 작업이 얼마나 어려운지 알 수 없는 경우가 많다는 점입니다. 일상적인 것처럼 보이는 프롬프트가 세 번의 도구 호출 (tool calls) 후에 까다로운 의존성 (dependency)을 숨기고 있을 수 있으며, 매우 위협적으로 보이는 작업이 첫 번째 검사 후에 무너져 내릴 수도 있습니다. 원샷 라우팅 (One-shot routing)은 작업 자체가 드러낼 증거를 확인하기 전에 이러한 잠재적 난이도를 예측해야 합니다. 최근 연구들은 이 결정을 실행 루프 (execution loop) 내부로 이동시키기 시작했습니다. 2026년 5월의 TwinRouterBench는 코딩 및 연구 에이전트 (research-agent) 궤적 내의 모든 호출 단계에서 라우팅을 수행하며, 전체 작업이 여전히 성공하는지 확인합니다. 한 진단 결과에 따르면, 라우터 역할을 수행한 Opus 4.6조차 나중에 실행 결과 실제 고성능 모델 (high tier)이 필요했던 것으로 밝혀진 147개 단계 중 단 7개만을 식별했으며, 40개의 SWE-bench 궤적은 모두 실패했습니다. NeurIPS 2025에서 발표된 R2R은 훨씬 더 세밀하게 접근합니다. 이 방식은 1.5B DeepSeek-R1 증류 (distilled) 모델로 생성을 시작하고, 추론 경로 (reasoning path)가 분기되기 시작할 때 32B 모델을 토큰 단위 (token by token)로 호출합니다. 이제 라우터는 입구에서 모델을 선택하는 접수원이 아니라, 작업이 전개되는 과정을 지켜보며 필요할 때 상급자에게 보고하는 감독관과 같습니다.

자동 라우팅은 점점 더 좋아지겠지만, 앞서 언급한 어려운 과제를 그대로 물려받게 됩니다. 즉, 제대로 라우팅하기 위해서는 단순히 난이도를 분류하는 것을 넘어 2차 비용 (second-order cost)을 예측해야 합니다. 현재로서는 검증되지 않은 라우터보다, 내가 직접 측정하고 확인한 수동 설정 (hand-drawn seam)을 더 신뢰합니다.

가치가 있는 경우

여기서 제가 과도한 기대(hype)에 반대하고 싶은 부분이 있습니다. 라우팅의 세밀함 (granularity) 자체에도 비용이 따르며, 그것이 항상 지불할 가치가 있는 것은 아니라는 점입니다.

일회성 작업의 경우, 전체적인 계산 방식은 흔히 "가장 좋은 모델을 사용하고 넘어가는 것"입니다. 경로(route)를 조정하는 데 소비되는 시간이 절약되는 토큰(tokens)보다 훨씬 크기 때문입니다. 세밀한 라우팅(Granular routing)이 제 역할을 다하는 경우는 다음 세 가지 중 하나가 충족될 때입니다: 규모 (volume) (작업을 수천 번 실행하는 경우), 엄격한 비용 또는 지연 시간 (latency) 예산, 또는 위에서 언급한 긴 에이전트 세션과 같은 **명확한 계획/실행 비대칭성 (clear plan/execute asymmetry)**입니다. 이 범위를 벗어난다면, 라우터는 엔지니어링의 탈을 쓴 성급한 최적화(premature optimization)에 불과합니다. 언제 라우팅을 하지 말아야 하는지를 아는 것도 라우팅 그 자체만큼이나 이 분야의 중요한 규율입니다.

단위가 점점 커지고 있습니다

한 걸음 물러나서 보면, 이 모든 것이 향하고 있는 방향에는 일관된 흐름이 있습니다. Cursor는 자신들의 스웜(swarm)을 일종의 확률적 컴파일러 (probabilistic compiler)로 정의했습니다. 즉, 플래너(planners)가 의도를 트리(tree) 구조로 분해하면, 더 저렴한 모델들이 리프(leaves) 노드를 컴파일하는 방식입니다. 그리고 그들은 "작업의 단위가 명세(specification)가 된다"고 언급했습니다. 이는 소프트웨어가 모델 속으로 녹아드는 현상과 맥락을 같이 합니다. 시스템에 전달하는 것은 점점 더 커지고 덜 문자 그대로(less literal) 변하며, 희소한 기술은 의도를 잘 설명하고 무엇을 어디서 실행할지 결정하는 능력이 됩니다.

유념할 만한 또 다른 솔직한 문제점이 하나 있습니다. 동일한 연구에서, 팀은 GPT-5.6 Sol을 프런티어 플래너(frontier planner)로 사용하고 싶어 했으나 그러지 못했습니다. 새 모델이 문자 그대로의 강조된 표현에 너무 민감하게 반응하여 통제 불능 상태로 치달았고, 결국 프롬프트를 재조정하는 대신 GPT-5.5로 회귀했습니다. 따라서 라우팅의 최전선에서도 프롬프트 엔지니어링 (prompt engineering)의 망령은 여전히 그 자리에 머물러 있습니다. 기술(craft)은 사라진 것이 아니라, 단어에서 배선(wiring)으로 옮겨갔을 뿐입니다. 모델을 선택하는 것 _자체_가 새로운 기술이 되었습니다.

이 글은 AI에서 "엔지니어링" 작업이 어떻게 계속해서 스택의 상위 계층으로 이동하는지에 관한 두 편의 글 중 두 번째 글입니다. 첫 번째 글은 프롬프트 엔지니어의 죽음 (The Death of the Prompt Engineer)입니다.

원문은 javieraguilar.ai에 게시되었습니다.

더 많은 AI 에이전트 (AI agent) 프로젝트를 보고 싶으신가요? 멀티 에이전트 시스템 (multi-agent systems), MCP 개발, 그리고 컴플라이언스 자동화 (compliance automation)를 소개하는 저의 포트폴리오를 확인해 보세요.