외부 LLM이 429를 뱉기 시작했다 — 탈출구는 더 싼 모델이 아니었다

지난달 제안서 지식검색 도구의 로그에 429가 쌓이기 시작했습니다. 외부 LLM 구독의 레이트리밋에 걸린 것인데, 문제는 이것이 일시적 급증이 아니라 사용량 성장 곡선 그 자체였다는 점입니다. 청구서도 같은 곡선을 그리고 있었습니다. 질문 하나를 처리할 때마다 검색, 엔티티 추출, 답변 생성까지 전부 외부 고급 모델을 호출하는 구조였으니 당연한 결과였습니다.

티어를 갈라도 남는 한계

비슷한 벽을 한 번 넘어본 적이 있습니다. 그때는 한 provider 안에서 라우팅처럼 가벼운 호출과 답변처럼 무거운 호출을 모델 티어로 갈라 비용을 60% 줄였습니다. 하지만 이번엔 사정이 달랐습니다. 티어를 아무리 갈라도 호출이 같은 외부 구독으로 나가는 이상 레이트리밋 총량은 그대로였고, 사용량이 늘면 비용 곡선도 결국 따라 올라왔습니다. 그 앞 단계의 기록은 아래에서 볼 수 있습니다.

이번에 필요한 것은 티어 분리의 다음 단계, 즉 외부 구독 바깥으로 나가는 길이었습니다. 다만 '더 싼 모델 하나로 전부'는 처음부터 배제했습니다. 최종 답변의 추론 품질이 무너지면 이 도구의 존재 이유가 사라지기 때문입니다.

일을 모델에 맞춰 가르기

파이프라인을 다시 보면 단계마다 요구가 전혀 달랐습니다. 엔티티 추출은 호출량이 압도적으로 많지만 출력이 정형이고 품질 민감도가 낮은 작업입니다. 반면 최종 답변은 호출량은 적어도 추론과 서술 품질이 사용자 체감을 그대로 좌우합니다. 같은 모델로 처리할 이유가 없는 두 종류의 일이었습니다.

추출은 한 국내 클라우드의 vLLM 엔드포인트에 올린 Gemma 계열 오픈 모델로 내렸습니다. 어디까지 로컬이 품질을 견디는지는 벤치마크 표가 아니라 실엔드포인트로 측정해 정했습니다. 엔티티와 관계 추출 정확도를 실제 데이터로 검증했고, 이 정도 정형 작업은 로컬 모델이 충분히 버틴다는 결과를 얻은 뒤에야 전환했습니다.

설정 한 줄로 갈아끼우는 구조

모델을 직접 코드에 박는 대신 OpenAI 호환 provider 인터페이스로 감싸고, 로컬 분기를 환경변수로 토글하게 만들었습니다. 태스크별·환경별로 어떤 모델을 쓸지가 config 한 줄로 결정되고, 외부 모델로 되돌아가는 폴백 경로도 그대로 보존됩니다. 외부 장애나 정책 변화가 와도 코드가 아니라 설정이 대응합니다.

비용은 모델을 바꿔서가 아니라 일을 갈라서 줄어든다.

전부 외부 고급 모델은 품질은 최고지만 429와 비용을 안고 가야 하고, 전부 로컬은 비용은 최저지만 답변 품질 저하 위험을 안습니다. 하이브리드는 태스크 성격으로 갈라 비용을 크게 줄이면서 답변 품질을 지키는 중간이 아니라, 두 극단의 장점만 가져오는 배치였습니다.

함수호출 못 하는 모델에 함수호출 입히기

로컬로 내려가는 길에 걸림돌이 하나 있었습니다. 사내 에이전트는 함수호출 기반으로 동작하는데, vLLM에 올린 모델은 tool-calling을 네이티브로 지원하지 않았습니다. 처음엔 이 모델을 포기해야 하나 싶었지만, 운영 관점에서 다시 보니 문제는 모델이 아니라 규약이었습니다.

그래서 모델 앞에 프록시를 세웠습니다. 요청이 들어오면 함수 정의를 프롬프트로 렌더링해 모델에 넣고, 모델의 텍스트 응답을 다시 함수호출 형식으로 파싱해 돌려주는 범용 변환 레이어입니다. 에이전트 코어는 한 줄도 고치지 않고 향하는 주소만 프록시로 바꿨습니다. 이 구성으로 멀티턴 대화, 병렬 함수호출, 검색 확장까지 실제로 동작하는 것을 검증했습니다.

다만 프롬프트 기반 함수호출은 네이티브보다 깨지기 쉽습니다. 형식 일탈이나 파싱 실패가 실제로 발생하므로 검증, 재시도, 폴백이 반드시 함께 가야 합니다. 그래서 '답변까지 전부 로컬'을 기본값으로 켜는 대신, 언제든 설정 한 줄로 전환할 수 있는 검증된 옵션으로 보존해 뒀습니다.

하이브리드의 청구서

결과적으로 추출이 로컬로 내려가면서 429와 비용 압박이 눈에 띄게 줄었고, 답변은 외부 고급 모델로 품질을 지켰습니다. 다만 처음엔 로컬 전환을 만능처럼 여겼지만, 운영해보니 하이브리드에도 청구서가 따라왔습니다.

로컬 운영 비용(GPU·유지보수)이 외부 API보다 비쌀 수 있습니다 — 물량이 받쳐줄 때 로컬이 이득이므로 손익분기를 측정해야 합니다

프롬프트 기반 함수호출은 형식 일탈과 파싱 실패에 취약합니다 — 검증·재시도·폴백 없이는 운영에 올릴 수 없습니다

두 모델의 운영·관측·프롬프트 관리 부담이 2배가 됩니다 — 단순함과 비용 사이의 트레이드오프입니다

그래도 이 트레이드오프는 감수할 가치가 있었습니다. 429는 협상이 안 되는 벽이고, 비용 곡선은 사용량과 함께 계속 올라가는 문제였기 때문입니다. 같은 상황이라면 아래를 먼저 점검해 보길 권합니다.

파이프라인 단계별로 호출량·출력 정형성·품질 민감도를 표로 정리했는가

로컬 전환 대상의 품질을 실엔드포인트에서 실제 데이터로 측정했는가 (추측 금지)

모델 교체가 설정 한 줄로 되는 provider 추상화가 있고 폴백 경로가 보존되는가

프롬프트 기반 함수호출에 검증·재시도·폴백이 붙어 있는가

로컬 운영 비용(GPU·유지보수)의 손익분기를 계산했는가

티어 분리가 1단계였다면 태스크 분리는 그 다음 단계였습니다. '한 모델로 전부'는 편하지만, 429와 청구서는 파이프라인의 단계별 사정을 봐주지 않습니다. 갈라야 했던 것은 모델이 아니라 일이었습니다.