깃허브에 올라온 도구 하나를 살펴보다가, 이름부터 눈에 들어왔다. Vomit. 설명도 직설적이다. "Claude 5는 가망이 없다, 토큰을 아껴라."
만든 사람은 Claude Code를 쓰다가 출력이 너무 장황해서 견디기 어려웠던 모양이다. 그래서 로컬 LLM 하나를 세우고, Claude가 내놓는 원문을 그 모델에 한 번 통과시켜 정제된 문장으로 바꾸는 파이프를 만들었다. 별도 인프라 없이 Llama.app이나 Ollama 위에 GPT-OSS 20B 같은 경량 모델을 얹으면 되는 구조다.
이 프로젝트가 흥미로웠던 건 도구 자체보다 구조였다. 주 모델이 낸 결과를 그대로 쓰지 않고, 두 번째 모델에게 한 번 더 맡긴다는 발상. 이걸 로컬 프로세스 대신 API 호출 체인으로 옮기면, LLM Router 위에서는 같은 엔드포인트에서 모델과 프리셋을 바꿔 두 번 호출하는 것만으로도 똑같은 일이 된다.
왜 출력 하나에 모델을 두 개 쓰는가
주 모델은 대체로 추론이 무겁고 비용도 높으며, 코드를 고치거나 복잡한 로직을 판단하는 작업에는 그만한 값어치를 하지만 결과를 사람이 읽기 좋은 문장으로 다듬는 일까지 맡길 필요는 없다.
Vomit이 로컬 LLM을 정제 전용으로 따로 둔 이유도 여기서 찾을 수 있다. 판단은 무거운 모델에 맡기고, 표현을 다듬는 일은 가벼운 모델로도 충분했다.
이 구조를 API 기반 서비스로 그대로 옮기면 별도의 로컬 인프라나 두 번째 API 키 관리가 따라붙는다. 엔드포인트 하나에서 두 모델을 오갈 방법만 있다면 이 부담은 사라진다.
실제로 얼마나 차이가 나는지 재봤다
발상이 그럴듯해도 숫자로 확인하지 않으면 의미가 없다. 다만 아래 수치는 모델당 한 번씩만 호출한 결과라 호출마다 편차가 있을 수 있어, 일반적인 성능 순위로 확대 해석하기는 어렵다. 방향성을 가늠하는 참고 자료로 읽어주길 바란다.
LLM Router로 같은 질의를 서로 다른 모델에 보내 비교했다. 조건은 비스트리밍, 단건 호출, max_tokens 600으로 고정했고 태스크는 두 가지로 나눴다. 정답이 명확한 오프바이원 버그 수정, 그리고 정답이 따로 없는 한국어 CS 답변 작성이다. 날짜는 2026년 8월 24일이다.
버그 수정 태스크에서는 claude-sonnet-5, gpt-4o, gpt-4o-mini 세 모델 모두 정답을 냈다.
| 모델 | 코드 버그 수정 결과 |
|---|---|
| claude-sonnet-5 | 정답 |
| gpt-4o | 정답 |
| gpt-4o-mini | 정답 |
이번 단건 측정에서는 정확도가 갈리지 않았지만 지연시간은 벌어졌다.
같은 정답을 냈는데도 claude-sonnet-5는 gpt-4o-mini보다 1.4초 더 걸렸다. 판단이 필요한 작업이니 여기까지는 그럴 만하다.
정작 눈에 띄는 차이는 한국어 CS 답변 작성 쪽에서 나왔다. 이 태스크는 정답이 정해져 있지 않고 품질을 사람이 판단해야 하는 영역인데, 모델별로 낸 분량 자체가 크게 갈렸다.
claude-sonnet-5는 268토큰을 썼고 gpt-4o-mini는 83토큰으로 끝냈다. 세 배가 넘는 차이다. 실제 답변 내용을 비교해보니 claude-sonnet-5 쪽은 배경 설명과 완곡한 표현을 길게 붙이는 경향이 있었고, gpt-4o-mini는 필요한 문장만 짧게 냈다. 앞서 인용한 Vomit 저장소의 문제의식이 한국어 응답에서도 비슷하게 확인된 셈이다.
이 두 결과를 체인 관점에서 이어보면 그림이 좀 더 분명해진다. claude-sonnet-5가 낸 268토큰짜리 답변을 1단계 원문으로, gpt-4o-mini가 낸 83토큰짜리 답변을 2단계 정제본에 대응하는 값으로 놓으면 아래와 같이 정리된다.
| 구분 | 모델 | 출력 토큰 수 |
|---|---|---|
| 1단계 원문 | claude-sonnet-5 | 268 |
| 2단계 정제본 | gpt-4o-mini | 83 |
토큰 수가 3분의 1 이하로 줄어드는 만큼 지연도 함께 줄어들 여지가 있다. 다만 이 표는 두 모델을 독립적으로 호출한 결과를 나란히 놓은 것이라, 1단계 출력을 실제로 2단계 입력에 그대로 넣어 측정한 값은 아니라는 점을 밝혀둔다. 정확한 비용 비교를 하려면 입력·출력 토큰 단가를 곱한 표가 필요한데, 이번에는 토큰 수와 지연만 확인했다.
프리셋만 바꿔 체인을 구성한다
방향성을 확인했으니 이제 실제로 체인을 어떻게 짜는지 볼 차례다. Vomit은 Claude의 출력을 로컬 프로세스로 가로채 별도의 로컬 LLM에 통과시킨다. LLM Router 위에서는 로컬 인프라 없이, 같은 엔드포인트에 model 필드만 바꿔 두 번 호출하는 것으로 같은 흐름을 재현할 수 있다.
첫 번째 호출은 판단이 필요한 주 모델로 보낸다. 두 번째 호출은 첫 응답을 입력값으로 받아 정제 전용의 경량 모델에 보낸다. 두 호출 모두 같은 Base URL과 같은 키를 쓰므로 관리할 자격 증명은 하나뿐이다.
이때 정제 모델에 원문만 그대로 넘기면 문제가 생긴다. 원래 질문이 무엇이었는지 모른 채 문장만 다듬다 보니 의미가 살짝 틀어지는 경우가 있었다. Vomit 저장소도 로컬 LLM이 "Claude가 전달하려는 것만 볼 수 있어 약간의 환각이 생긴다"고 밝힌 바 있는데, 이번 체인에서도 비슷한 문제가 나타났다. 그래서 정제 프롬프트에는 원문과 함께 원래 질문을 한 줄로 요약해 같이 넣었다.
아래 예시는 이 두 가지를 반영한 형태다. jq가 설치되어 있어야 하고, 쉘 문자열에 $RAW를 그대로 끼워 넣으면 따옴표나 줄바꿈이 있을 때 JSON이 깨지므로 jq로 payload를 구성해 안전하게 전달한다.
# 1) 주 모델 호출, 판단이 필요한 원래 작업
RAW=$(curl -s https://llm-router.cafe24.com/api/v1/chat/completions \
-H "Authorization: Bearer sk-cafe24-**********" \
-H "Content-Type: application/json" \
-d '{"model":"claude-sonnet-5","messages":[{"role":"user","content":"고객 CS 문의에 대한 답변 초안 작성"}]}' \
| jq -r '.choices[0].message.content')
# 2) 원질문 요약과 1단계 응답을 함께 담아 정제 모델 호출
QUESTION="고객 CS 문의: 환불 정책에 대한 답변 초안 요청"
PAYLOAD=$(jq -n --arg q "$QUESTION" --arg raw "$RAW" '{
model: "gpt-4o-mini:floor",
messages: [{
role: "user",
content: ("원래 질문: " + $q + "\n\n다음은 그 답변 초안이다. 맥락을 유지하면서 핵심만 남겨 간결하게 다듬어줘.\n\n초안: " + $raw)
}]
}')
curl -s https://llm-router.cafe24.com/api/v1/chat/completions \
-H "Authorization: Bearer sk-cafe24-**********" \
-H "Content-Type: application/json" \
-d "$PAYLOAD"
여기서 :floor 접미사를 정제 단계에 붙였다. 정제는 판단이 아니라 표현을 다듬는 작업이므로 최저가 프로바이더로 라우팅해도 품질 손실이 크지 않다. 접미사와 provider 옵션으로 태스크별 모델을 고르는 기준은 이전 글에서 더 자세히 다뤘다.
체인이 의도대로 도는지는 각 호출의 응답에 담긴 extra_fields로 확인했다. resolved_model_used로 실제 어떤 모델이 처리했는지, latency로 각 단계가 얼마나 걸렸는지 알 수 있다. 정제 단계가 예상보다 오래 걸린다면 provider의 sort 옵션을 price에서 latency로 바꿔보면 된다.
정리
Vomit이 로컬 프로세스로 하던 일을, LLM Router에서는 같은 엔드포인트에서 모델과 프리셋을 바꿔 두 번 호출하는 방식으로 재현했다. 새 인프라나 별도의 키 관리는 필요하지 않았고, 이미 연결된 엔드포인트를 두 번 호출하는 것만으로 충분했다. 판단은 비싼 모델에, 표현은 저렴한 모델에 맡기자 이번 단건 측정에서는 출력 토큰 수와 지연이 함께 줄었다. 다만 이는 토큰 수와 지연을 비교한 결과일 뿐, 입력·출력 단가를 곱한 비용표를 확인한 것은 아니다. 실제 비용 절감 폭을 따지려면 이 부분을 별도로 측정해야 한다. 두 모델을 오가는 체인을 직접 실험해보고 싶다면 LLM Router에서 모델과 프리셋을 바꿔가며 확인해보길 권한다.