최근 소프트웨어 개발 현장에서 AI를 활용하는 방식이 조용하지만 근본적으로 바뀌고 있다는 것을 체감하고 있다.
얼마 전까지만 해도 새로운 AI 모델이 등장했을 때의 비교는 아주 단순하고 직선적이었다.
“그래서 이 모델이 기존 모델보다 더 똑똑한가?”
커뮤니티는 MMLU나 HumanEval 같은 벤치마크 점수표를 확인하고, 몇 가지 까다로운 추론 문제를 던져본 뒤 서열을 매겼다. 나 역시 마찬가지였다. 항상 현존하는 가장 높은 벤치마크 순위의 모델을 기본값으로 설정하고 코딩과 설계를 맡겼다.
그런데 여러 모델을 실제 복잡한 개발 워크플로우 안에서 번갈아 사용하면서 점차 다른 생각을 하게 되었다. 이제는 “어떤 모델이 가장 좋은가”를 묻는 것보다, **“내가 하려는 작업에 어떤 모델을 배치하는 것이 가장 합리적인가”**를 묻는 것이 훨씬 더 중요해졌기 때문이다.
처음에는 단순히 여러 모델을 직접 써보며 생긴 개인적인 경험칙이라고 생각했다. 그러나 조금만 시야를 넓혀보면, 이미 테크 산업 전체의 거대한 조류가 정확히 이 방향으로 움직이고 있다.
1. 6개월 전과 지금의 체감: 모델 격차보다 커진 피드백 루프의 힘
최근 몇 달 동안 여러 모델을 번갈아 사용하면서 가장 먼저 느낀 변화는, 실제 개발에서 모델 간의 체감 격차가 예전만큼 절대적이지 않다는 사실이다.
물론 이것이 “이제 모든 모델의 성능이 평준화되었다”는 뜻은 결코 아니다. 어려운 논리 추론이나 완전히 새로운 도메인의 문제를 풀어야 할 때는 여전히 프론티어 모델의 원천 역량(Raw capability)이 결정적인 차이를 만든다.
내가 이야기하고자 하는 것은 실제 소프트웨어 개발 환경에서의 결과물이다. 현대의 AI 개발은 모델에게 질문 하나를 던지고 완성된 코드 한 덩어리를 받는 단발성 질의응답이 아니다.
- 기존 코드베이스의 의존성과 컨텍스트를 읽는다.
- 관련된 파일을 탐색하고 수정 범위를 결정한다.
- 코드를 작성하고 로컬 테스트와 린터를 실행한다.
- 실행이 실패하면 터미널의 에러 로그를 분석한다.
- 부족한 컨텍스트를 다시 주입하고 코드를 수정한다.
- 다른 관점을 가진 모델에게 리뷰를 맡기고 다시 검증한다.
결국 실제 프로덕션에서 유효한 코드를 만들어내는 것은 모델 하나의 두뇌가 아니다.
$$\text{Final Outcome} = \text{Model} \times \text{Context} \times \text{Tools} \times \text{Harness} \times \text{Verification}$$
단독으로 테스트했을 때는 다소 아쉬운 성능을 보이던 모델이라도, 정교한 파일 검색 도구와 테스트 실패 피드백 루프(Harness)가 갖춰진 에이전트 환경에 올려두면 놀라울 정도로 안정적인 결과를 낸다. 모델이 한 번에 완벽한 답을 내지 못해도 상관없다. 틀리면 테스트가 알려주고, 오해하면 저장소의 실제 컨텍스트가 다시 보정해 준다.
모델의 부족한 부분을 시스템의 피드백 루프가 보완하기 시작하면서, 공개 벤치마크 점수 몇 점 차이로 실제 개발 생산성을 가늠하는 일은 점점 더 어려워지고 있다.
2. 멀티 모델의 본질: 머릿수 채우기가 아닌 ‘오류 패턴의 분산’
이러한 피드백 루프를 경험하면서 자연스럽게 멀티 모델 워크플로우에 주목하게 되었다.
실제로 모델마다 두드러지는 특성이 다르다. 어떤 모델은 문제를 구조화하고 설계를 쪼개는 데 능하고, 어떤 모델은 지연 시간 없이 코드를 빠르게 생성하는 데 강하며, 어떤 모델은 이미 작성된 코드에서 엣지 케이스와 보안 허점을 짚어내는 데 날카롭다.
그렇다면 단 하나의 고비용 모델에게 모든 역할을 전담시킬 이유가 없다.
[문제 분석 및 아키텍처 구조화]
│
▼
Model A
│
▼
[코드 구현 및 변환]
│
▼
Model B
│
▼
[테스트 러너 실행 및 피드백]
│
▼
실행 결과
│
▼
[코드 리뷰 및 취약점 검증]
│
▼
Model C
│
▼
[수정 및 반영]
│
▼
Model B여기서 핵심은 “모델을 많이 쓴다”는 물리적인 양에 있지 않다. 서로 다른 강점과 약점을 가진 모델들이 서로의 사각지대를 상호 보완한다는 데 있다.
만약 파이프라인에 배치된 모델들이 모두 동일한 편향과 동일한 이유로 실패한다면, 아무리 여러 모델을 엮어도 비용만 늘어날 뿐이다. 중요한 것은 리더보드 최상위 점수의 모델들을 무작정 모으는 것이 아니라, 서로 다른 오류 패턴을 가진 모델들을 적재적소에 조합하는 일이다.
3. 지능(Intelligence)은 비용이 매겨진 시스템 자원이다
이 지점에서 질문의 축은 근본적으로 변화한다.
- 과거의 질문: “Claude와 GPT 중 어느 것이 더 뛰어난가?”
- 전환된 질문: “내가 지금 수행하려는 작업에는 어떤 모델이 가장 적합한가?”
- 엔지니어링 관점의 질문: “요구되는 품질을 만족하면서 가장 낮은 비용으로 작업을 완수하려면 어떤 모델을 배치해야 하는가?”
소프트웨어 엔지니어링에서 자원을 다루어 온 방식과 정확히 일치한다.
모든 HTTP 요청을 처리하기 위해 최고 사양의 베어메탈 서버를 투입하지 않는다. 단순한 키-값 캐시 조회를 위해 초대형 분산 DB 클러스터를 전면에 세우지도 않는다. 엔지니어는 항상 워크로드의 특성(CPU 중심인가, 메모리 중심인가, 레이턴시가 우선인가, 처리량이 우선인가)에 맞춰 시스템 자원을 배분한다.
AI 역시 프로덕션 아키텍처 안에 안착하면서 똑같은 법칙을 따르게 된다.
개인 개발자가 토이 프로젝트에서 하루 몇 달러를 더 쓰는 것은 사소한 문제일 수 있다. 그러나 AI 파이프라인이 기업의 핵심 비즈니스 로직에 결합되어 하루 호출량이 수십만, 수백만 건에 도달하면 이야기는 완전히 달라진다. AI 비용은 더 이상 ’개발자가 편의를 위해 결제하는 API 사용료’가 아니라, **‘소프트웨어 아키텍처의 수익성과 지속 가능성을 결정하는 핵심 설계 변수’**가 된다.
4. 이미 산업에서 확인되는 표준: Microsoft Model Router
이러한 흐름은 단순한 개인적 관찰이나 이상론에 머물지 않는다. 이미 글로벌 빅테크 기업의 프로덕션 플랫폼에서 명확한 인프라로 자리 잡고 있다.
대표적인 사례가 Microsoft Foundry의 Model Router다. 마이크로소프트는 여러 공급자의 다양한 모델을 하나의 통합 라우팅 레이어로 묶어 제공하며, 요청의 복잡도와 작업 특성에 따라 최적의 모델을 동적으로 선택한다.
특히 주목할 부분은 마이크로소프트가 제공하는 라우팅 전략이다.
- Cost 모드: 비용 절감을 최우선으로 고려하여 경량 모델을 적극 활용
- Balanced 모드: 품질과 비용, 지연 시간 사이의 최적 균형점을 탐색
- Quality 모드: 복잡한 추론과 정확도가 필수적인 작업에 상위 프론티어 모델을 투입
마이크로소프트의 공식 문서에서는 모델 선택의 기준을 단순한 리더보드 순위가 아닌 **‘Workload Fit(작업 적합도)’**으로 규정한다. 또한 프로덕션 환경에서는 공개 벤치마크 점수만으로 모델을 결정할 수 없으며, 기업의 실제 워크로드와 데이터셋을 바탕으로 자체적인 평가(Evaluation)를 수행해야 한다고 명시한다.
모델 라우팅은 이제 최신 논문의 연구 주제를 넘어, 현실의 클라우드 인프라가 요구하는 표준 설계 패턴이 되었다.
5. 지표의 재정의: Cost per Successful Task
그렇다면 라우터가 모델을 합리적으로 선택하기 위해 우리는 어떤 데이터를 보아야 할까? 제조사가 홍보하는 정적 벤치마크 점수만으로는 실제 현장의 질문에 답할 수 없다.
실제 필요한 데이터는 이런 형태다.
| 모델 | 대상 워크로드 성공률 | 건당 평균 비용 |
|---|---|---|
| Model A | 94% | $0.40 |
| Model B | 91% | $0.06 |
| Model C | 96% | $1.20 |
단순 벤치마크 점수의 관점에서는 성공률 96%의 Model C가 1등이다. 그러나 프로덕션 시스템 아키텍처의 관점에서는 완전히 다른 결론에 도달한다.
Model B는 성공률이 91%로 다소 낮지만, 비용은 Model C의 20분의 1에 불과하다. 그렇다면 일상적인 대다수의 요청은 Model B로 처리하고, 실패 신호가 감지되거나 복잡도가 높은 작업에 한해서만 Model C로 에스컬레이션하는 라우팅 파이프라인을 설계하는 것이 훨씬 합리적이다.
결국 엔지니어링 관점에서 추적해야 할 진짜 핵심 지표는 종합 점수가 아니라, **“성공한 작업 하나를 만드는 데 실제 얼마의 비용이 들었는가(Cost per Successful Task)”**다.
6. Model Routing에서 Workflow Routing으로
여기서 라우팅의 개념은 한 단계 더 진화한다. 라우터가 계산해야 하는 것은 작업의 ’난이도’뿐만이 아니다. 바로 **‘실패 비용(Failure Cost)’**이다.
- 사내 주간 회고 이메일 초안 작성: 실패 비용이 매우 낮음. 오타나 결함이 발생해도 사람이 직접 빠르게 수정할 수 있다.
- 코어 금융 결제 시스템의 데이터베이스 마이그레이션: 실패 비용이 치명적임. 미세한 엣지 케이스 누락이 대규모 금전 사고나 서비스 장애로 직결된다.
따라서 미래의 라우터는 단순히 “Model A로 보낼 것인가, Model B로 보낼 것인가”를 선택하는 단일 문지기에 머물지 않는다.
[작업 특성 및 실패 비용 분석]
│
┌──────┴──────┐
▼ ▼
[낮은 실패 비용] [높은 실패 비용]
│ │
저렴한 모델 프론티어 모델
│ │
결과 반환 다단계 검증 루프 (Planner → Coder → Reviewer)어떤 경우에는 저렴한 모델로 초안을 만들고, 테스트를 통과하면 즉시 종료하되 실패할 때만 고성능 추론 모델을 호출하는 폴백(Fallback) 구조를 택할 수 있다. 또 다른 경우에는 기획-구현-테스트-리뷰로 이어지는 다단계 워크플로우를 구성할 수도 있다.
즉 미래의 라우팅은 모델 라우팅을 넘어, **“이 문제의 가치와 위험도를 고려할 때 어떤 지능의 조합과 검증 절차(Workflow)를 배분할 것인가”**를 결정하는 **워크플로우 라우팅(Workflow Routing)**으로 확장된다.
7. 프론티어 모델에 대한 균형 잡힌 시각
이런 논의를 진행하다 보면 쉽게 마주치는 극단적인 오해가 있다.
“그렇다면 작은 모델 여러 개와 검증 루프만 조합하면, 값비싼 거대 프론티어 모델은 더 이상 필요 없는 것 아닌가?”
결코 그렇지 않다.
요약, 번역, 정형화된 코드 변환처럼 이미 존재하는 패턴을 재구성하거나 테스트 코드로 정답을 기계적으로 판별할 수 있는 영역에서는 경량 모델과 피드백 루프의 결합이 극적인 효율을 발휘한다.
그러나 세상에 없던 새로운 아키텍처를 설계하거나, 복잡하게 얽힌 도메인 정책의 숨은 인과관계를 추론하거나, 기존의 학습 데이터 패턴을 벗어난 새로운 가설을 세워야 하는 ’답이 정해져 있지 않은 문제(Zero-to-One)’에서는 여전히 모델 자체의 순수한 파라미터 규모와 추론 깊이가 절대적이다.
평범한 지능 열 개를 병렬로 연결한다고 해서, 프론티어 모델 하나가 짚어내는 창의적인 도약이나 직관적인 통찰이 저절로 만들어지지는 않는다.
따라서 시장의 본질은 “거대 모델 vs 소형 모델”의 대립 구도가 아니다. **“가장 강력하고 값비싼 지능을 어느 결정적인 순간에 국소적으로 투입할 것인가”**의 선택 최적화 문제다.
8. 평가의 미래: 정적 벤치마크에서 ’실제 사용 행동 데이터’로
라우터가 이러한 최적의 선택을 내리려면, 무엇보다 모델의 실제 역량을 투명하게 파악하고 있어야 한다. 그러나 제조사가 자체 측정한 공개 벤치마크는 실제 엔지니어링 워크로드와 상당한 괴리가 있다.
내가 정말로 확인하고 싶은 것은 전체 1위 점수가 아니다.
“TypeScript + 대규모 모노레포 + 기존 아키텍처 유지 + 중간 규모 리팩터링 조건에서 이 모델의 성공률과 평균 수정 비용은 얼마인가?”
이 질문에 답하려면 정적인 질문-답변 테스트를 넘어, 실제 런타임에서 발생하는 사용자의 엔지니어링 행동 데이터를 관측해야 한다.
- 모델이 생성한 코드가 로컬 컴파일과 단위 테스트를 몇 회 만에 통과했는가?
- 개발자가 모델의 생성물을 그대로 머지(Merge)했는가, 아니면 대폭 수정했는가?
- 문서 작업에서 생성된 결과물의 몇 퍼센트가 실제 최종 산출물에 잔존했는가?
이러한 실제 행동 신호들이 누적될 때, 비로소 모델별 세부적인 **‘역량 지도(Capability Map)’**가 그려진다. 그리고 이 역량 지도가 완성될 때, 라우터는 비로소 정밀한 경험적 근거를 바탕으로 지능을 적재적소에 배치하는 플라이휠을 완성하게 된다.
사용자 및 엔지니어
│
▼
실제 프로덕션 Task
│
▼
런타임 행동 데이터 기반 평가 (Test, Diff, Merge)
│
▼
Capability Map 구축 (역량 × 비용 × 지연 시간)
│
▼
지능형 Model Router
│
▼
최적의 모델 및 워크플로우 실행
│
└───────────────▶ 결과 데이터 피드백에필로그: 지능을 운영(Ops)하는 엔지니어링의 시대
처음에는 단순히 새로운 모델이 나올 때마다 호기심으로 터미널에서 써보며 느낀 작은 체감이었다.
하지만 그 체감을 파고들며 마주한 것은 AI를 대하는 패러다임의 거대한 이동이었다.
가장 뛰어난 단 하나의 완벽한 모델을 찾아 헤매는 일은 점점 매력을 잃어가고 있다. 시장에는 이미 충분히 우수한 지능들이 넘쳐나고 있으며, 모델 간의 비용은 실시간으로 떨어지고 있다.
결국 앞으로 엔지니어와 조직의 진짜 경쟁력은 단순히 최고급 모델의 API 키를 발급받는 데 있지 않다. “주어진 예산과 허용된 시간 안에서, 서로 다른 특성을 가진 지능들을 어떻게 오케스트레이션하고, 검증하고, 배치하여 비즈니스 가치를 만들어낼 것인가.”
AI는 이제 경외의 대상인 ’초지능’에서, 엔지니어가 비용과 성능을 따져가며 다루어야 할 ’클라우드 컴퓨팅 자원’의 영역으로 내려왔다.
가장 좋은 AI를 숭배하던 시대는 지나가고 있다.
이제는 필요한 만큼의 지능을 구매하고, 정밀하게 운영하는 시대다.