AI 요청, 어디서 돌릴지 나눠도 될까?
경량·로컬 모델이 쏟아지는 지금, 작은 팀이 요청별 처리 경로를 나누는 실전 설계법
지난 열흘간의 AI 소식을 늘어놓고 보면, 새 모델 이름보다 더 눈에 띄는 공통점이 하나 있습니다. "이 요청을 어디서 처리할 것인가"가 제품 기능으로 올라왔다는 점입니다.
퍼플렉시티는 9월 1일 하이브리드 컴퓨트를 내놓으면서 기기에서 도는 로컬 모델(PPLX Qwen 3.8 27B)을 함께 선보였고, 구글 딥마인드는 다음 날 제미나이 3.8 플래시를, 알리바바는 그 직전 Qwen3.8 플래시를 내놨습니다.
크고 똑똑한 모델 옆에 작고 빠른 선택지가 촘촘히 깔린 셈입니다.
작은 팀에게 이 흐름은 "더 좋은 모델로 갈아타기" 문제가 아니라 "요청마다 처리 장소를 나누기"라는 설계 문제로 옵니다.
GPU를 사거나 서버를 직접 운영하자는 이야기가 아닙니다.
같은 서비스 안에서 어떤 요청은 가볍고 가까운 곳에서, 어떤 요청은 비싸고 정확한 곳에서 처리하도록 길을 나누자는 쪽에 가깝습니다.
왜 지금 '실행 위치'가 설계 문제가 됐을까?
모델 품질 차이보다 응답 속도, 데이터 경계, 네트워크 상태가 사용자 경험을 더 크게 좌우하는 구간이 생겼기 때문입니다.
엣지·온디바이스 흐름이 반복해서 말하는 이유도 같습니다.
가까운 곳에서 추론하면 응답이 빠르고, 데이터가 밖으로 덜 나가며, 연결이 불안정해도 서비스가 멈추지 않습니다.
예전에는 선택지가 사실상 "좋은 모델 API 하나"였습니다.
지금은 같은 세대 안에 플래시급 경량 모델이 나란히 있고, 소비자 제품이 로컬 모델을 기본으로 얹기 시작했습니다.
사용자는 이미 "이 답은 왜 3초나 걸리지?"를 기준으로 제품을 평가합니다.
라우팅이 곧 체감 품질이 된 겁니다.
우리 제품에서 무엇을 가벼운 경로로 내려보낼 수 있을까?
판단 난이도가 낮고 반복이 많은 작업부터 내려보내면 됩니다.
기본 원칙은 하나입니다.
쉬운 건 싸고 빠르게, 어려운 것만 위로 올립니다.
- 입력 분류와 라우팅: 문의 유형 판별, 중복·스팸 거르기
- 형식 정리: 맞춤법, 말투 통일, 표 정돈, 태그 자동 부착
- 즉답이 중요한 UI: 짧은 요약, 자동완성, 검색어 보정
- 민감 정보 1차 처리: 연락처·주문번호를 가린 뒤 상위 모델 호출
- 네트워크가 흔들릴 때의 폴백 응답
예를 들어 예약 문의를 받는 동네 사진 스튜디오 챗봇이라면, "영업시간·가격·주차" 같은 반복 질문은 경량 모델과 문서 검색으로 즉시 답하고, "셋째 주 주말 야외촬영이 가능한지, 비가 오면 일정이 어떻게 되는지" 같은 복합 판단만 상위 모델로 올립니다.
사용자는 앞쪽 대부분을 빠르게 받고, 팀은 비싼 호출을 꼭 필요한 곳에만 씁니다.
월요일 아침에 당장 뭘 하면 될까?
모델을 바꾸기 전에 로그부터 봅니다.
최근 한 주 요청을 난이도와 민감도로 분류해 보면, 어디를 가벼운 경로로 내려보낼지 대부분 답이 나옵니다.
- 최근 1주 요청 100건을 뽑아 '쉬움 / 민감 / 어려움'으로 라벨을 붙입니다.
- '쉬움' 묶음에만 경량 모델을 붙이고, 기존 답변과 같은 입력·같은 평가표로 나란히 비교합니다.
- 에스컬레이션 규칙을 글로 적습니다.
확신이 낮을 때, 환불·계약·금액이 언급될 때, 사용자가 사람을 찾을 때는 상위 모델 또는 담당자로 넘깁니다. - 실패 경로를 먼저 만듭니다.
경량 경로가 죽으면 클라우드로, 클라우드가 죽으면 정해진 안내문으로 내려앉게 합니다. - 지표는 세 개면 충분합니다.
첫 응답 시간, 에스컬레이션 비율, 요청당 비용.
주의할 점도 있습니다.
경로가 둘이 되면 프롬프트와 평가도 두 벌이 됩니다.
평가 세트는 하나로 두고 양쪽을 같은 기준으로 채점하세요.
로컬·경량 경로는 기기와 상황에 따라 편차가 크니, 스위치 하나로 언제든 끄고 전부 상위 모델로 돌릴 수 있게 만들어 두는 편이 안전합니다.
모델 발표는 앞으로도 계속 쏟아질 겁니다.
그 사이에서 흔들리지 않는 건 "요청을 분류하고, 쉬운 건 가볍게, 어려운 건 정확하게" 보내는 라우팅 규칙입니다.
이번 주의 변화는 그 규칙을 짤 재료가 갑자기 늘었다는 뜻이고, 규칙을 가진 팀만 그 재료를 원가와 속도로 바꿔 냅니다.