2027년까지 모든 버티컬 AI 앱이 갖춰야 할 3계층 라우팅

모든 요청을 GPT-5에 던지고 있다면, 이미 지고 있어요

지난달에 한 AEC 스타트업 CTO 분이랑 통화를 했어요. 도면 PDF에서 자재 수량을 뽑아주는 기능을 만들고 있었는데, 한 달 OpenAI 청구서가 1,200만원이 찍혔다고요.

기능 자체는 잘 돌아갔어요. 문제는 사용자가 던지는 요청의 70%가 “이 도면 몇 페이지짜리예요?” 같은 단순 질문이었다는 거예요. 그걸 전부 GPT-5에 토큰 풀로 넣고 있었던 거죠.

이건 그 팀이 못해서가 아니에요. 2024-2025년에 만들어진 많은 버티컬 AI 앱이 이 함정에 빠져 있었어요. “제일 똑똑한 모델 하나 붙이고 프롬프트로 밀어붙인다”가 작년까지의 정석이었거든요.

하지만 이 방식은 2026년부터는 통하지 않아요. 2027년에 라우팅이 없는 버티컬 AI 앱은 자연스럽게 비싸고 느린 앱이 됩니다.

왜 단일 모델 아키텍처가 무너지고 있나

무너지는 이유는 분명해요.

• 가격이 양극화됐어요. GPT-5 mini 같은 소형은 토큰당 거의 공짜에 가까워졌고, Claude Opus 4급 대형은 오히려 더 비싸졌죠. 같은 요청이라도 어디로 보내느냐에 따라 비용이 수십 배 차이 납니다.
• 모델마다 장기가 뚜렷해졌어요. 구조화 추출은 Claude Sonnet 계열이 안정적이고, 긴 추론은 GPT-5 reasoning, 음성·이미지까지 섞이면 Gemini가 유리하죠. 한국어 뉘앙스는 또 다른 선택지가 있고요. 하나로 다 잘하는 모델은 이제 없어요.
• 무엇보다 교체 주기가 짧아요. 모델은 6개월 단위로 바뀝니다. 바꾸는 일은 config 한 줄이 아니라 부분 재작성이에요. 라우팅 층이 없으면 모델 교체 때마다 앱이 흔들립니다.

그래서 이렇게 봐야 해요. 모델은 부품이고, 제품 가치는 라우팅에서 나와요.

1계층: 분류기 (Classifier) — 요청을 읽는 얇은 층

첫 번째 층은 들어온 요청이 “무엇인지”를 가려내는 일이에요.

여기서 자주 생기는 오해가 있어요. “분류도 LLM이 하면 되지 않나?”라는 생각이요. 비용이 터집니다. 분류기는 싸고, 빠르고, 결정적이어야 해요.

실제로는 이렇게 구현하면 돼요:

• 루프 기반 1차 필터: 정규식, 키워드, 파일 형식으로 명백한 케이스부터 걷어내요. AEC 앱이라면 “PDF 첨부 + ‘BIM’ 등장” 같은 패턴이 즉시 분기 신호예요.
• 작은 분류 모델 2차: 룰로 못 잡는 건 GPT-5 mini나 더 작은 임베딩 기반 분류기로 의도를 잡아요. 토스의 사기 탐지처럼 룰 엔진과 ML 분류기를 함께 쓰는 구조예요.
• 신뢰도 점수 출력: 라벨 하나가 아니라 “수량 추출 0.92, 일반 질문 0.08”처럼 확률을 내야 해요. 다음 층이 이 점수를 보고 결정을 내립니다.

당근 모더레이션도 비슷해요. 신고가 들어오면 키워드와 패턴으로 명백한 스팸은 즉시 처리하고, 애매한 것만 무거운 모델로 넘기죠. 신고 1건마다 GPT-5를 돌리면 회사가 버티기 어려워요.

2계층: 라우터 (Router) — 어느 모델로 보낼지 결정

분류가 끝나면 이제 “어느 모델로 처리할지”를 고르는 단계예요. 이게 라우터예요.

라우터가 고려할 축은 보통 네 가지예요:

1. 요청 유형 — 분류기가 준 라벨
2. 품질 요구 수준 — 사용자 등급, 사용 맥락(빠른 답변 vs 보고서급 결과)
3. 지연 허용치 — 채팅은 2초 안에, 백그라운드는 30초까지
4. 현재 비용 상태 — 이번 달 예산 소진율, 특정 모델의 레이트 리밋

이걸 매핑하는 룰을 세우면 됩니다. AEC 도면 추출 앱을 예로 들면:

• “PDF 페이지 수 질문” → GPT-5 mini, 즉시 응답
• “표 추출 요청” → Claude Sonnet 4.5, 구조화 출력 모드
• “도면 해석 + 자재 산정” → Claude Opus 또는 GPT-5 reasoning, 백그라운드 처리
• “전체 프로젝트 비교 분석” → 멀티 에이전트 파이프라인

중요한 건 라우터가 코드에 모델 이름을 직접 박지 않는 거예요. “구조화 추출-고품질” 같은 역할 이름으로 부르고, 그 추상 이름을 실제 모델로 매핑하는 테이블을 따로 둡니다. 모델이 바뀌면 매핑 테이블만 갈아끼우면 돼요. 쿠팡 검색팀이 의도 분류 후 다른 랭킹 모델로 라우팅하는 방식과 비슷합니다. “어느 모델”이 아니라 “어느 역할”로 부르세요.

3계층: 폴백 (Fallback) — 모델이 실패할 때

세 번째 층은 종종 생략되지만, 프로덕션에서는 가장 자주 발동돼요.

OpenAI가 30분 멈춘 적 있죠. Anthropic도 마찬가지였고요. 모델 API는 실패합니다. 레이트 리밋, 타임아웃, 갑작스런 품질 저하, 응답 포맷 깨짐 — 매주 겪어요.

현장에서 자주 맞닥뜨리는 상황은 이렇습니다:

시나리오 1: 1차 모델이 응답을 안 줌 타임아웃 또는 5xx 에러. 라우터가 정의해 둔 백업 모델로 자동 전환해요. 여기서 핵심은 백업 모델을 다른 제공사로 두는 거예요. OpenAI가 죽으면 Anthropic, 그 반대도. 같은 회사 모델로 폴백하면 의미가 없어요.

시나리오 2: 응답은 받았는데 형식이 깨짐 JSON 스키마 불일치, 필수 필드 누락, 명백한 환각. 검증 층에서 잡아내 재시도하거나 더 강한 모델로 에스컬레이션해요.

시나리오 3: 모델은 정상이지만 결과 신뢰도가 낮음 “잘 모르겠습니다” 류의 응답이거나 자체 신뢰도 점수가 낮을 때. 자동으로 인간 검토 큐로 보내거나, 사용자에게 “더 정확한 답변이 필요하면…” 옵션을 보여줘요.

참고로 OpenAI의 함수 호출 스키마와 Anthropic의 도구 사용 스키마는 달라요. 폴백 층은 이 스키마 차이를 흡수하는 어댑터 역할도 해야 해요. 그렇지 않으면 폴백이 발동될 때마다 코드가 깨집니다.

이걸 직접 만들 거예요, 살 거예요?

사서 쓸까요, 직접 만들까요? 제 답은 이렇습니다. 2026년까지는 직접 만드세요.

라우팅 SaaS들이 나오고 있긴 해요. 그런데 버티컬 AI에서는 라우팅 룰 자체가 도메인 지식이에요. AEC에서 “이 요청은 무거운 추론이 필요하다”를 판단하는 기준은 핀테크나 커머스와 완전히 달라요. 이걸 외부 SaaS에 맡기면 핵심 워크플로우 IP를 잃습니다.

추천하는 단계는 이래요:

1. 첫 달: 분류기를 룰 기반으로 단순하게 만드세요. 룰 50개면 충분해요. 분기 통계부터 쌓아요.
2. 2-3개월차: 라우터를 매핑 테이블 형태로 분리해요. 코드에서 모델 이름을 추상화하는 게 목표예요.
3. 4-6개월차: 폴백 어댑터를 붙여요. 최소 두 개 제공사에 동시 연결해요.
4. 그 이후: 분류기를 학습 기반으로 점진 교체. 라우터에 비용·지연 최적화 자동화를 추가해요.

이번 주에 할 수 있는 것

이 글을 읽고 “맞는 말인데…”에서 멈추지 마세요. 이번 주에 30분만 내서 두 가지만 측정해 보세요.

첫째, 현재 앱에서 가장 많이 들어오는 요청 유형 상위 5개를 로그에서 뽑아 보세요. 그리고 그중 몇 퍼센트가 GPT-5 mini로도 충분한 단순 요청인지 추정해 보세요. 대부분 50%를 넘습니다.

둘째, 지난달 모델 API 청구서를 열고 요청당 평균 비용을 계산해 보세요. 그다음 그 평균을 절반 이하로 낮추려면 어디서 라우팅이 일어나야 하는지 적어 보세요.

이 두 숫자가 라우팅 로드맵이에요. 모델은 또 바뀔 거예요. 6개월 뒤에. 그때 흔들리지 않는 건 라우팅 구조뿐이에요.