AI 코딩 모델 라우팅AI Coding Model Routing
📅
들어가기 전에 🔗
버튼 문구를 바꾸는 작업과 로그인 세션이 간헐적으로 풀리는 문제를 같은 모델, 같은 추론 강도로 처리하고 있지 않으신가요?
문구 수정은 변경 위치만 알면 끝나지만, 세션 문제는 쿠키·서버 렌더링·리다이렉트가 연결된 원인을 찾아야 합니다.
두 작업에 같은 설정을 적용하면 작은 수정에서 기다리는 시간이 늘거나, 복잡한 문제에서 틀린 수정을 반복하게 됩니다.
모델 라우팅은 작업에 맞는 모델과 추론 강도를 선택하고, 필요할 때 그 선택을 바꾸는 규칙
입니다.
거창한 자동 분류 시스템부터 만들 필요는 없습니다.
혼자 개발한다면 작업 시작 전 모델을 고르는 기준과, 막혔을 때 설정을 바꾸는 기준만 있어도 충분합니다.
이번 글에서는 Claude Code와 Codex에 적용할 수 있는 선택 기준부터 설정 예시, 승격과 비용 비교까지 정리합니다.작업 분류 🔗
파일 수보다 중요한 것은 정답의 명확성과 잘못 고쳤을 때의 영향입니다.
한 파일의 변경이라고 모두 쉬운 작업은 아닙니다.
권한 검사 한 줄은 서비스 전체에 영향을 줄 수 있고, 파일 20개의 import 경로 변경은 정해진 규칙대로 처리하면 됩니다.
작업을 받으면 먼저 다음 세 질문에 답해 보시기 바랍니다.
- 무엇이 정답인가?수정 전후의 예시와 완료 조건이 있으면 판단 부담이 작습니다.
- 어디까지 영향을 주는가?화면 한 곳에 그치는지, API·DB·인증 경계를 함께 바꾸는지 확인합니다.
- 어떻게 확인할 수 있는가?타입 검사로 끝나는지, 여러 상태와 사용자 권한을 재현해야 하는지 살펴봅니다.
이 기준으로 작업을 빠른 경로, 기본 경로, 고성능 경로로 나눕니다.
각 경로는 특정 모델의 영구적인 등급이 아니라, 팀에서 테스트해 정한 역할입니다.
| 경로 | 작업 조건 | 개발 예시 | 시작 설정 |
|---|---|---|---|
| 빠른 경로 | 정답과 수정 위치가 명확함 | 버튼 문구 변경, import 정리, 재현된 단순 타입 오류 | 가벼운 모델, 낮은 추론 강도 |
| 기본 경로 | 기존 패턴을 읽고 구현을 선택해야 함 | 검색 필터 추가, 폼 검증, API 응답 처리 | 주력 모델, 기본 추론 강도 |
| 고성능 경로 | 여러 가설·설계 선택·위험 검토가 필요함 | 세션 유실 분석, 동시성 오류, 데이터 마이그레이션 설계 | 판단력이 높은 모델, 필요에 맞춘 추론 강도 |
명확한 수정은 빠른 경로, 일반 구현은 기본 경로, 복잡한 판단은 고성능 경로로 배치하는 모델 라우팅
OpenAI 공식 문서는 같은 입력으로 모델과 추론 설정을 비교하고, 요구하는 품질을 만족하는 가장 가벼운 설정을 선택하도록 안내합니다.
OpenAI 모델 선택 가이드↗
👨💻
처음에는 평소 쓰는 주력 모델을 기본 경로로 두고, 반복되는 단순 작업부터 빠른 경로로 옮겨 보시기 바랍니다.
낯선 저장소의 작업까지 한꺼번에 가벼운 모델로 바꾸면 모델 성능과 부족한 작업 정보를 구분하기 어렵습니다.
모델과 추론 강도 🔗
모델을 바꾸는 것과 추론 강도를 바꾸는 것은 별도의 선택입니다.
모델은 기본 능력과 가격 구조를 바꾸고, 추론 강도는 지원하는 모델 안에서 생각에 들이는 양을 조절합니다.
높은 강도로 설정한 가벼운 모델이 다른 고성능 모델과 같은 결과를 낸다고 가정해서는 안 됩니다.
예를 들어 기존 React 폼에 필수값 검사를 추가할 때는 주력 모델의 기본 강도에서 시작할 수 있습니다.
검증 함수와 에러 표시 위치가 분명해진 뒤 문구만 정리한다면 낮은 강도로 처리해도 됩니다.
반대로 어떤 계층에서 검증해야 하는지, 서버와 클라이언트의 오류 계약을 어떻게 맞출지 결정해야 한다면 판단에 더 많은 예산을 배정합니다.
👍
모델과 추론 강도를 동시에 바꾸면 결과가 좋아지거나 나빠진 이유를 알기 어렵습니다.
같은 작업 요청과 검증 기준을 유지한 채 한 가지씩 바꿔 비교합니다.
지원하는 추론 수준도 모델과 제품에 따라 다르므로 선택 화면이나 공식 설정 문서를 확인합니다.
Claude Code 설정 🔗
Claude Code에서는 시작할 때
--model을 지정하거나, 세션 안에서 /model로 모델을 선택할 수 있습니다.
sonnet, opus 같은 별칭의 실제 모델과 사용 가능 여부는 실행 환경에 따라 확인해야 합니다.
Claude Code 모델 설정↗claude --model sonnet작업을 진행하다 복잡한 원인 분석이 필요해지면 세션에서 모델을 바꿀 수 있습니다.
/model opus계획과 구현 🔗
“구조를 결정하는 단계”와 “결정된 구조대로 구현하는 단계”를 나누는 것도 라우팅입니다.
Claude Code의
opusplan은 계획 모드에서 Opus를 사용하고, 실행 모드에서는 Sonnet으로 전환하는 방식입니다.
Claude Code의 opusplan 설정↗claude --model opusplan예를 들어 검색 기능을 추가한다면 계획 단계에서 URL 쿼리 구조, 데이터 조회 위치, 빈 결과 처리를 정합니다.
구현 단계에서는 그 결정을 기준으로 컴포넌트와 테스트를 작성합니다.
계획에는 “서버에서 처리한다”처럼 짧은 결론만 남기지 말고, 변경 파일·입출력·검증 조건까지 포함해야 구현 모델이 같은 문제를 다시 풀지 않습니다.
단계 분리에는 전달 비용도 있습니다.
문구 하나를 고치기 위해 별도의 설계 단계를 만들면 절약보다 호출과 대기 시간이 늘어날 수 있습니다.
설계 선택이 실제로 필요한 작업에 적용합니다.
Codex 설정 🔗
Codex는 모델과 추론 강도를 각각 설정할 수 있습니다.
CLI 설정의
model_reasoning_effort에 사용할 수 있는 값은 선택한 모델과 클라이언트가 지원하는 수준에 따라 달라집니다.
Codex 설정 레퍼런스↗다음은 CLI에서 모델과 추론 강도를 명시하는 예시입니다.
모델 ID는 현재 계정에서 사용할 수 있는 값으로 선택합니다.
codex --model gpt-6.1-sol --config model_reasoning_effort='medium'codex --model gpt-6.1-sol --config model_reasoning_effort='high'두 번째 예시는 같은 모델의 추론 강도만 높입니다.
어떤 작업에서 이 변경이 도움이 되는지 먼저 비교한 뒤, 부족할 때 다른 모델을 검토할 수 있습니다.
앱에서는 제공되는 모델·추론 수준 선택 화면에서 같은 기준을 적용합니다.
이 예시를 실행한다고 작업 난이도에 따른 자동 라우팅이 만들어지는 것은 아니며, 선택 규칙은 사용자가 운영해야 합니다.
실패 원인과 승격 🔗
테스트가 실패했다고 바로 모델을 바꾸면 안 됩니다.
의존성 설치 실패, 비어 있는 환경 변수, 잘못된 재현 절차는 모델 능력보다 실행 조건의 문제일 수 있습니다.
먼저 실패를 분류하고, 그다음 모델이나 추론 강도를 높이는
승격
을 결정합니다.| 실패 신호 | 먼저 할 일 | 승격 판단 |
|---|---|---|
| 파일을 찾지 못함 | 실제 경로와 진입점을 제공 | 경로를 알려줘도 의존 관계를 반복해서 오해하면 검토 |
| 요구사항이 모호함 | 기대 동작과 제외 범위를 확정 | 제품 결정이 필요하면 사용자에게 확인 |
| 테스트 실행 불가 | 환경·명령·테스트 데이터를 점검 | 실행 환경 문제만으로 승격하지 않음 |
| 같은 수정이 반복 실패 | 실패 입력과 관찰 결과를 고정 | 가설을 갱신하지 못하면 승격 |
| 인증·데이터 경계 발견 | 영향 범위와 검증 절차를 재설계 | 높은 판단 예산과 사람의 리뷰를 배정 |
재시도 횟수에도 경계를 둡니다.
예를 들어 “동일한 재현 사례에 대해 두 번 수정해도 원인을 좁히지 못하면 요약하고 승격한다”는 규칙으로 시작할 수 있습니다.
두 번이라는 숫자는 제품 기능이 아니라 팀이 조정할 운영 기준입니다.
🖐️
권한 검사 제거, 테스트 삭제, 예외 무시로 실패를 없애는 수정은 승격 전에 중단해야 합니다.
고성능 모델을 선택하더라도 인증·결제·데이터 변경의 검토와 완료 조건이 자동으로 충족되는 것은 아닙니다.
반복 실패와 높은 위험을 점검하고, 완료한 변경·실패한 검증·남은 판단을 전달하는 모델 승격 흐름
그림의 승격 신호는 모델 전환을 검토할 계기입니다.
위 표처럼 경로 누락이나 요구사항 부족을 먼저 보완해야 하는 경우도 있습니다.
전달 요약 🔗
새 세션이나 다른 도구로 넘길 때는 대화 전체를 복사하기보다 작업 상태와 확인 근거를 정리합니다.
현재 코드와 로그를 다시 확인할 수 있는 경로도 함께 남깁니다.
목표: 새로고침 뒤 검색 필터 유지
완료 조건: q와 status가 URL에서 복원되고 뒤로 가기도 동작
수정 파일: src/features/search/SearchForm.tsx
현재 변경: 초기값을 searchParams에서 읽도록 수정
통과: 타입 검사, 초기 필터 복원 테스트
실패: 뒤로 가기 후 입력값이 이전 상태로 돌아오지 않음
재현: 필터 A → 필터 B → 브라우저 뒤로 가기
관찰: URL은 A지만 입력값은 B로 남음
남은 판단: URL 변경과 로컬 입력 상태의 동기화 방식
제외 범위: API와 검색 결과 정렬은 변경하지 않음상위 모델은 이 정보로 URL과 로컬 상태의 관계부터 확인할 수 있습니다.
이미 끝난 API 탐색이나 첫 재현 과정까지 다시 반복할 필요가 줄어듭니다.
완료당 비용 🔗
라우팅의 효과는 첫 호출 가격보다
검증을 통과한 작업 하나의 총비용
으로 비교합니다.
가벼운 모델이 실패한 뒤 고성능 모델로 다시 처리하면 첫 시도 비용과 인계 비용이 추가되기 때문입니다.아래는 실제 가격이나 벤치마크가 아닌 계산용 예시입니다.
입력·출력·추론 토큰을 금액으로 환산한 호출 비용을 같은 단위로 가정합니다.
| 경로 | 첫 시도 | 재시도·인계 | 상위 모델 실행 | 완료까지 합계 |
|---|---|---|---|---|
| 고성능 모델로 시작 | 10 | 0 | 0 | 10 |
| 가벼운 모델에서 완료 | 2 | 0 | 0 | 2 |
| 가벼운 모델 실패 후 승격 | 2 | 1 | 10 | 13 |
승격 비율이
p라면 이 예시의 평균 비용은 2 + 11 × p입니다.
다만 실제로는 상위 모델이 앞선 변경을 활용해 더 짧게 끝낼 수도 있고, 잘못된 변경을 되돌리느라 더 오래 걸릴 수도 있습니다.
따라서 이 식을 절약률로 일반화하지 말고 실제 작업 기록으로 계산합니다.비교 기록 🔗
반복되는 대표 작업으로 기본 경로의 기준값을 잡고, 동일한 시작 코드·요청·검증 조건에서 다른 설정을 비교합니다.
기록은 처음부터 다음 정도면 충분합니다.
- 작업 유형과 시작 모델·추론 강도
- 완료 조건 충족 여부와 승격 이유
- 재시도와 승격을 포함한 전체 소요 시간
- API 사용 시 실제 사용량·청구 기준에 따른 비용
- 사람의 수정 시간과 리뷰에서 발견한 문제
구독형 Claude·Codex의 사용 한도를 API 토큰 단가로 그대로 환산하지는 않습니다.
구독 환경에서는 완료율·대기 시간·한도 소모를 비교하고, API 환경에서는 실제 사용량과 적용 요금으로 비용을 계산합니다.
👨💻
오타 수정, 일반 기능 구현, 복잡한 버그 분석처럼 서로 다른 작업 유형을 따로 비교해 보시기 바랍니다.
전체 평균만 보면 쉬운 작업에서 절약한 비용이 어려운 작업의 재작업을 가릴 수 있습니다.
결론 🔗
모델 라우팅은 작업의 정답이 얼마나 명확한지, 어떤 경계에 영향을 주는지, 어떻게 검증할지를 보고 시작 설정을 정하는 일입니다.
반복되는 단순 수정부터 가벼운 경로를 시험하고, 복잡한 설계와 위험한 변경에는 충분한 판단 예산을 배정합니다.
막히면 환경과 작업 정보부터 확인하고, 모델 판단이 부족한 경우에 승격합니다.
시작 설정·승격 기준·전달 요약·완료당 비용
을 함께 관리하면 작업을 끝내는 시간과 비용을 근거로 모델을 선택할 수 있습니다.