당신은 아마도 AI를 잘못 사용하고 있습니다. 그리고 그것은 생각보다 더 많은 비용을 치르게 합니다.

오늘날 대부분의 기업은 한 가지 AI 설정 방식을 가지고 있습니다. 가능한 가장 강력한 모델로 모든 것을 보내고, 비용을 지불하고, 이를 반복하는 것입니다.

이 방식은 작동합니다. 하지만 비용이 많이 들고, 필요 이상으로 느리며, 솔직히 말해서 — 전구를 갈기 위해 외과의사를 고용하는 것과 비슷합니다.

아무도 이야기하지 않는 문제

모든 환자가 — 개방형 심장 수술이 필요하든 종이에 베인 상처에 반창고를 붙여야 하든 — 가장 먼저 수석 컨설턴트(senior consultant)에게 진료를 받는 병원을 상상해 보세요.

그 컨설턴트는 매우 뛰어나지만, 대기실은 혼란 그 자체입니다. 비용은 하늘 높은 줄 모르고 치솟습니다. 그리고 그의 시간 절반은 간호사가 2분 만에 처리할 수 있었던 일들에 소비됩니다.

그것이 오늘날 대부분의 AI 파이프라인(pipeline)이 처한 모습입니다.

당신의 팀이 AI 모델로 무언가를 보낼 때, 그것은 Python 파일일 수도 있고, 힌디어로 된 고객 불만 사항일 수도 있으며, SQL 쿼리나 일상적인 Hinglish(힌디어와 영어가 섞인 언어) 지원 티켓일 수도 있습니다. 이것들은 서로 완전히 다른 문제이며, 각기 다른 전문 지식, 다른 깊이, 그리고 다른 비용을 요구합니다.

그럼에도 불구하고 대부분의 시스템은 이 모든 것을 동일한 모델에, 동일한 가격으로, 동일한 대기 시간을 가지고 보냅니다.

더 스마트한 접근 방식: 적절한 작업에 적절한 모델 사용

어떤 입력값들은 엄격하고 결정론적인(deterministic) 경계를 가집니다. .py 파일은 Python을 포함하고 있습니다. .sql 파일은 SQL을 포함하고 있습니다. 이를 파악하기 위해 세상에서 가장 강력한 AI가 필요하지는 않습니다 — 규칙이 필요할 뿐입니다.

더 스마트한 파이프라인은 다음과 같습니다:

입력 도착
      ↓
Orchestrator SLM — 읽기 기능을 갖춘 작고 빠른 모델
...

별도의 라우팅(routing) 시스템을 구축할 필요는 없습니다. 오케스트레이터(orchestrator) 자체가 입력값을 분류하고 트래픽을 안내하도록 훈련된 작은 AI 모델입니다. 이를 실행하는 데 드는 비용은 거의 없습니다.

강력한 프론티어 모델(frontier model) — 당신의 Claude, 당신의 GPT-4 — 는 최종 답변을 위해 루프(loop) 안에 머뭅니다. 단지 더 이상 분류 작업을 수행하지 않을 뿐입니다.

대부분의 팀이 놓치는 한 가지 통찰

전문가 모델(specialist models)이 발견한 내용을 프론티어 모델에 전달할 때, 본능적으로 출력값을 사람이 읽기 좋게 형식을 맞추려 합니다. 문단, 설명, 완전한 문장 등으로 말이죠.

잘못된 목표 설정입니다.

하위 소비자 (downstream consumer)는 사람이 아니라 또 다른 모델입니다. 전문 모델 (Specialist models)은 기계가 읽을 수 있는 구조화된 출력 (structured output)을 생성해야 합니다. 조밀하게, 정밀하게, 설명 없이 말이죠.

{
  "language": "python",
  "issues_detected": ["unbounded loop at line 47"],
...

이것은 사람이 읽기 위한 것이 아닙니다. 모델이 효율적으로 소비하기 위한 것입니다. 제약 조건은 런타임 (runtime) 시 외부에서 잘라내는 방식이 아니라, 학습 (training) 단계에 내재되어 있어야 합니다. 수정보다는 예방이 우선입니다.

마치 의사가 컨설턴트에게 5페이지 분량의 서술형 보고서 대신 구조화된 차트를 전달하는 것과 같습니다. 정보는 동일하지만, 더 빠르게 읽을 수 있고, 생각할 여유가 더 많아집니다.

컨텍스트 (context)가 너무 커지면 어떤 일이 발생하나요?

프런티어 모델 (frontier model)은 유한한 작업 메모리 (working memory)를 가지고 있습니다. 여러 전문 모델이 출력을 기여하면 메모리는 빠르게 채워집니다. 다음은 순차적인 폴백 스택 (fallback stack)입니다:

첫 번째 — 전문 모델은 필수적인 구조화된 신호 (structured signal)만 보냅니다. 추론 과정 (reasoning traces)은 포함하지 않습니다. 이것이 기본값입니다.

필요한 경우 — 먼저 원래 입력을 요약합니다. 라우팅 (routing)하기 전에 압축합니다.

여전히 필요한 경우 — 전문 모델의 출력을 한 번에 하나씩 입력합니다. 프런티어 모델이 컨텍스트를 점진적으로 구축합니다. 속도는 느리지만 정확합니다.

최후의 수단 — 전문 모델을 완전히 건너뜁니다. 원본 입력을 프런티어 모델에 직접 전달합니다. 비용은 최대치이지만, 품질은 보장됩니다.

파이프라인은 항상 정답으로 가는 경로를 가지고 있습니다. 당신은 단지 그 비용을 얼마나 지불할지를 선택하는 것뿐입니다.

이것이 실제로 비용을 절감하나요?

솔직한 답변은 다음과 같습니다: 규모가 커질 때만 그렇습니다.

전문 모델은 오픈 소스 (open-source)이므로 사용료는 무료이지만, 컴퓨팅 (compute) 비용은 지불해야 합니다. 합리적인 GPU 설정 비용은 월 $1,000–1,100 정도입니다. 절감 효과는 대량의 쿼리 (queries)를 비용이 많이 드는 프런티어 API 호출로부터 분리하여 라우팅함으로써 발생합니다.

월간 AI API 지출액	이것이 타당한가요?
$2,000 미만	아마 아닐 것입니다 — 단순하게 유지하세요
...
한 가지 중요한 주의 사항. 만약 귀하의 팀이 현재 Claude.ai, Claude Code 또는 관리형 AI 인터페이스 (managed AI interface)를 사용하고 있다면 — 이 아키텍처 (architecture)는 거기서 벗어남을 의미합니다. 귀하는 귀하의 자체 시스템에서 API를 직접 호출하게 될 것이며, 이는 직원들이 사용하는 상호작용 계층 (interaction layer)을 직접 구축하고 소유해야 함을 의미합니다.

현재 AI 사용 방식	이것이 의미하는 바
관리형 인터페이스 (Claude.ai 등)	먼저 커스텀 인터페이스를 구축해야 합니다 — 엔지니어링 비용 (engineering cost)을 고려하세요
이미 커스텀 툴링과 함께 API를 사용 중	자연스럽게 연결됩니다

당신은 이미 이 아키텍처를 경험했습니다

만약 AI 코딩 툴인 Cursor의 에이전트 모드 (agent mode)를 사용해 보았다면, 자신도 모르게 정확히 이 패턴을 경험한 것입니다.

Cursor는 전체 코드베이스 (codebase)를 하나의 모델에 보내고 결과가 좋기를 바라지 않습니다. 경량 오케스트레이터 (lightweight orchestrator)가 귀하의 요청을 읽고, 파일을 읽을지, 코드베이스를 검색할지, 터미널 명령을 실행할지 결정한 다음, 적절한 도구로 라우팅 (routing)하고, 그 후 프런티어 모델 (frontier model)이 최종 응답을 합성 (synthesise)합니다.

Atlassian의 Rovo와 같은 엔터프라이즈 도구들도 업무 워크플로 (workplace workflows)를 위해 동일한 방향으로 움직이고 있습니다.

이러한 도구들을 만든 회사들은 하나의 모델이 모든 것을 수행하는 것이 낭비라는 점을 깨달았습니다. 문제는 귀하의 조직 내부의 AI 파이프라인 (AI pipelines)이 동일한 지능을 가지고 설계되었는지, 아니면 여전히 모든 쿼리 (query)를 사용 가능한 가장 비싼 모델로 보내고 있는지입니다.

진짜 교훈

대부분의 AI 비용 및 속도 문제는 모델의 문제가 아닙니다. 그것은 라우팅 (routing)의 문제입니다.

최고의 AI 파이프라인은 "모든 것을 수행하는 한 명의 천재"라기보다 잘 운영되는 팀에 더 가깝습니다. 즉, 똑똑한 접수원, 숙련된 전문가, 그리고 정말로 중요한 곳에만 적용되는 시니어의 판단력이 조화를 이루는 형태입니다.

질문은 어떤 모델이 최고인가가 아닙니다.

질문은 이것입니다: 귀하는 적절한 작업에 적절한 모델을 사용하고 있습니까?

귀하의 조직은 어떤 라우팅 결정 (routing decisions)을 내리고 있습니까, 아니면 회피하고 있습니까? 댓글로 의견을 들려주세요.