LLM 토큰 비용 76% 절감 — 룰을 다 넣지 않고 골라 넣었다

무엇이 문제였나 — 룰을 늘리자 LLM 토큰 비용도 따라 늘었다

LLM 토큰 비용을 76% 줄인 열쇠는 더 싼 모델이 아니라 "이 광고에 어떤 룰이 걸리는가"를 먼저 묻는 단계였습니다. 금융투자 광고 검토 시스템은 수백 개 룰을 매번 통째로 모델에 넣고 있었고, 평가 세트로 재 보니 입력 토큰이 427K였습니다. 경량 모델이 먼저 관련 룰만 골라 넣게 바꾸자 같은 평가 세트에서 입력 토큰이 104K로 내려갔고 총비용은 54% 줄었습니다.

출발점은 사람의 검토 시간이었습니다. 금융투자 상품 광고는 내보내기 전에 자본시장법, 금융소비자보호법, 금융투자협회 광고 심사 매뉴얼에 맞는지 확인해야 합니다. 담당자가 광고물 한 건을 손으로 대조하면 짧게는 30분, 길게는 2시간이 걸렸습니다. 광고물 형식도 제각각이라 PDF, PPTX 슬라이드, 이미지 파일이 섞여 들어왔습니다.

팀은 이 수기 검토를 자동 보고서 생성으로 바꾸기로 했습니다. 광고물을 페이지 단위로 쪼개고, 이미지는 Vision 기능으로 읽고, 각 페이지를 검토 룰과 하나씩 대조해 위반 의심 항목을 보고서로 내는 구조입니다. 이 구조에서 품질을 좌우하는 재료는 룰입니다. 룰이 빠지면 모델은 그 위반을 볼 이유가 없고, 보고서는 깨끗하게 나옵니다. 그래서 룰 베이스를 10배 이상, 수백 개 규모로 넓혔습니다.

문제는 그 다음에 왔습니다. 룰을 넓힌 만큼 모델에 넣는 글의 양이 커졌고, LLM API 요금은 넣는 토큰 수를 따라 올라갑니다. 정확도를 올리려고 한 확장이 그대로 운영비 확장이 됐습니다. 사람 검토를 줄이려고 만든 시스템이 비싸서 못 쓰는 시스템이 되면 자동화의 이유가 사라집니다. 같은 시스템이 감독기관 보고와 자료요구 회신까지 맡게 된 과정은 컴플라이언스 자동화 기록에 따로 적었고, 이 글은 그중 비용 한 축만 깊게 봅니다.

처음 잰 숫자는 무엇이었나

비용을 말하기 전에 잣대부터 정해야 했습니다. 실제 운영 청구서는 광고물이 몰리는 달과 한산한 달에 따라 출렁이므로, 시스템을 바꾸기 전후를 비교하는 잣대로 쓰기 어렵습니다. 팀은 평가 세트(eval)를 잣대로 삼았습니다. 같은 광고 사례 묶음을 바꾸기 전 시스템과 바꾼 뒤 시스템에 똑같이 넣고, 모델에 들어간 입력 토큰과 총비용을 셉니다. 입력이 같으니 차이는 시스템에서만 나옵니다.

그렇게 잰 첫 숫자가 입력 토큰 427K입니다. 여기서 K는 천 단위이므로 42만 7천 토큰 규모입니다. 비교 대상인 사람 검토는 건당 30분에서 2시간이었습니다. 두 숫자는 단위가 달라 바로 견줄 수 없지만, 하나는 분명했습니다. 룰을 수백 개로 늘린 상태에서 입력 토큰의 대부분은 광고 본문이 아니라 룰 텍스트가 차지할 수밖에 없는 구조였습니다. 광고 한 페이지는 짧고, 룰 수백 개는 깁니다.

검토 방식도 입력을 키우는 쪽으로 짜여 있었습니다. 시스템은 PDF, PPTX, 이미지까지 광고물을 페이지 단위로 나눠 전수 대조합니다. 한 페이지도 건너뛰지 않으려는 설계라 정확도에는 유리하지만, 비용 쪽에서 보면 대조 횟수가 페이지 수를 따라 늘어나는 구조입니다. 룰 텍스트가 대조마다 붙는다면 비용은 룰 수와 페이지 수를 곱한 만큼 커집니다(추정 — 호출 단위별 토큰 기록은 남아 있지 않습니다). 어느 쪽이든 룰 수가 비용의 한 축이라는 점은 427K라는 숫자가 보여 줍니다.

기록에 남은 첫 측정은 여기까지입니다. 427K가 광고 한 건 기준인지 평가 세트 전체 합계인지는 남은 자료에 적혀 있지 않습니다. 그래서 이 글은 427K를 "같은 평가 세트에서 잰 바꾸기 전 값"으로만 다룹니다. 단위가 무엇이든 바꾼 뒤 값 104K와 같은 잣대로 잰 숫자이므로, 줄어든 비율 76%는 그대로 성립합니다.

세운 가설 — 룰을 많이 넣을수록 검토가 정확해진다

룰 베이스를 10배 이상 키울 때 깔고 있던 생각은 단순했습니다. 모델은 프롬프트에 없는 기준으로 판단하지 않는다, 그러니 놓치지 않으려면 아는 룰을 전부 보여 줘야 한다. 광고 검토에서 가장 비싼 실수는 위반을 못 보고 통과시키는 실수입니다. 거짓 경보는 사람이 한 번 더 보면 끝나지만, 놓친 위반은 광고가 나간 뒤에야 드러납니다.

• 가설 1 — 룰이 많을수록 모델이 놓치는 위반이 줄어든다
• 가설 2 — 그러려면 매 광고마다 룰 전체를 프롬프트에 넣어야 한다
• 가설 3 — 늘어나는 비용은 사람 검토 시간 30분~2시간을 아끼는 값으로 상쇄된다

세 가설 가운데 첫째는 지금도 틀렸다고 보지 않습니다. 룰을 넓힌 결정은 유지했고, 지금도 수백 개 규모입니다. 문제는 둘째와 셋째였습니다. 둘째는 "보여 줘야 한다"를 "매번 전부 넣어야 한다"로 옮겨 적은 비약이었고, 셋째는 그 비약이 만든 비용을 확인하지 않고 받아들인 낙관이었습니다.

룰이 빠지면 모델은 그 위반을 볼 이유가 없다. 그래서 전부 넣는다.

가설은 어디서 틀렸나

틀린 지점은 평가 세트 숫자에서 드러났습니다. 입력 토큰 427K는 "룰을 전부 넣는다"는 방식이 비용을 룰 개수에 비례해 키운다는 뜻이었습니다. 룰을 10배로 늘리면 매 건 넣는 룰 텍스트도 10배 가까이 늘어나고, 광고 한 건을 볼 때마다 그 값을 다시 냅니다. 룰 베이스를 키운 결정과 비용이 커진 결과가 한 줄로 이어져 있었습니다.

셋째 가설, 즉 비용이 사람 시간 절약으로 상쇄된다는 생각도 검증 없이는 서지 않았습니다. 사람 검토는 건당 30분에서 2시간이라는 범위만 있고, 자동화 뒤 사람이 보고서를 확인하는 데 드는 시간은 기록에 없습니다. 상쇄 여부를 따질 숫자가 한쪽에만 있었던 셈입니다. 정직하게 말하면, 팀은 그 계산을 끝내기 전에 비용 쪽부터 줄이는 길을 골랐습니다.

여기서 한 가지를 분명히 해 둡니다. 남은 기록에는 "룰을 전부 넣는 방식"과 "골라 넣는 방식" 두 시점의 숫자만 있고, 그 사이 여러 번 시도한 중간 측정은 없습니다. 이 글의 가설 단계는 그 두 숫자와 설계 기록에서 거꾸로 짚어 낸 사고 순서입니다. 처음부터 라우터를 염두에 두고 출발한 듯 쓰면 사실과 다릅니다. 처음 설계는 분명히 "다 넣는다" 쪽이었습니다.

진짜 원인 — 광고 한 건에 실제로 걸리는 룰은 일부뿐이다

원인을 비용 쪽에서만 보면 "룰이 많다"로 끝납니다. 검토 쪽에서 보면 다른 그림이 나옵니다. 광고 한 건이 수백 개 룰에 전부 해당하는 일은 없습니다. 광고가 다루는 상품과 쓰는 표현에 따라 걸리는 룰 묶음이 달라집니다. 시스템이 "실제로 걸리는 룰만 선별"하는 구조로 바뀐 이유가 바로 이 점입니다. 룰 베이스가 넓어질수록 한 광고에 해당하는 비율은 오히려 작아집니다.

즉 비용을 키운 주범은 룰의 개수가 아니라, 해당하지 않는 룰까지 매번 넣는 방식이었습니다. 모델은 넣어 준 룰을 다 읽고 그 값을 다 받아 갑니다. 해당 없는 룰 수백 줄은 정확도에 보태는 몫 없이 요금에만 보탭니다. 길고 무관한 맥락은 모델의 주의도 흩뜨릴 수 있지만, 이 효과는 이번 기록에서 따로 재지 않았으므로 원인으로 세우지 않습니다.

원인을 이렇게 다시 쓰자 해법의 방향이 바뀌었습니다. 룰을 줄이면 첫째 가설, 곧 놓치지 않으려는 목적을 버리게 됩니다. 룰은 그대로 두고, 광고마다 넣는 룰만 줄이면 됩니다. 문제는 "이 광고에 어떤 룰이 걸리는가"를 누가, 얼마의 비용으로 판단하느냐였습니다.

돌아보면 이 원인은 비용 숫자를 재기 전까지 보이지 않았습니다. 룰을 늘리는 작업은 정확도 쪽에서만 평가했고, 그 평가에서는 룰이 많을수록 좋아 보였습니다. 같은 변경을 비용 쪽 잣대로 한 번 더 재자 비로소 "전부 넣기"가 숨은 비용이었다는 사실이 드러났습니다. 한 변경을 두 잣대로 재는 습관이 이번 개선의 실제 출발점이었습니다.

어떻게 고쳤나 — 경량 모델이 먼저 고르는 RAG 라우터

팀이 둔 장치는 RAG 라우터입니다. RAG는 질문에 맞는 자료를 먼저 찾아 모델에 붙여 주는 방식이고, 라우터는 그 찾기를 맡는 앞단입니다. 이 시스템에서는 광고 콘텐츠를 먼저 경량 모델이 1차 분류하고, 그 분류에 해당하는 룰만 골라 본 검토 모델의 프롬프트에 주입합니다. 비싼 모델은 짧아진 프롬프트로 정밀 검토만 맡습니다.

이 구조를 고른 이유는 비용의 비대칭에 있습니다. 1차 분류는 "이 광고가 어떤 종류인가"만 판단하면 되므로 가벼운 모델로 충분하고, 그 호출이 만드는 비용은 수백 개 룰을 매번 넣는 비용보다 작습니다. 정밀한 판단이 필요한 위반 대조는 그대로 본 모델이 맡습니다. 싼 모델에 판단 전체를 넘기지 않고, 고르는 일만 넘겼습니다.

같은 문제를 만나면 먼저 떠오르는 길은 두 가지입니다. 첫째는 룰을 다시 줄이는 길입니다. 비용은 곧바로 내려가지만, 룰 베이스를 10배 이상 넓힌 이유였던 "놓치지 않기"를 그대로 버립니다. 수기 검토 30분에서 2시간을 대신하려는 시스템이 사람보다 좁은 기준으로 보면 자동화의 근거가 무너집니다. 둘째는 검토 전체를 더 싼 모델로 바꾸는 길입니다. 단가는 내려가도 넣는 룰의 양은 그대로이고, 위반 대조라는 가장 정밀한 판단을 약한 모델에 맡기게 됩니다. 남은 기록에 이 두 길을 실제로 시험한 숫자는 없습니다. 다만 두 길 모두 비용과 정확도 가운데 하나를 내주는 거래라는 점은 구조만 봐도 분명했고, RAG 라우터는 그 거래를 피하는 쪽이었습니다.

고르는 단계를 하나 더 두면 새로운 실패가 생깁니다. 라우터가 해당 룰을 빠뜨리면 본 모델은 그 룰을 보지 못하고, 처음 가설이 막으려던 "놓친 위반"이 다시 생깁니다. 비용을 줄이려다 정확도를 내주는 거래가 될 수 있습니다. 검색 단계가 정답 재료를 빠뜨리면 뒤에서 아무리 프롬프트를 다듬어도 소용없다는 점은 RAG 성능 평가 기록에서도 같은 모양으로 확인했습니다.

그래서 라우터와 함께 회귀 감시를 배포 게이트로 걸었습니다. 반드시 맞혀야 하는 골든 케이스 24개를 정해 두고, 라우터나 룰을 바꿀 때마다 이 24개를 다시 돌립니다. 하나라도 결과가 달라지면 배포하지 않습니다.

• 룰 베이스 — 줄이지 않는다. 10배 이상 확장한 수백 개 규모를 유지
• 1차 분류 — 경량 모델이 광고 콘텐츠를 분류하고 해당 룰만 고른다
• 정밀 검토 — 본 모델이 고른 룰과 페이지를 대조해 보고서를 쓴다
• 배포 게이트 — 골든 케이스 24개 회귀 감시를 통과한 변경만 배포
• 측정 — 바꾸기 전후를 같은 평가 세트로 돌려 입력 토큰과 총비용을 비교

재측정 결과 — 입력 토큰 427K에서 104K로

같은 평가 세트를 바꾼 시스템에 다시 넣었습니다. 입력 토큰은 427K에서 104K로 내려갔고, 줄어든 비율은 76%입니다. 총비용은 54% 줄었습니다. 두 숫자 모두 운영 청구서가 아니라 eval로 실측한 값입니다. 바꾼 구조는 지금 골든 케이스 24개 회귀 감시를 배포 게이트로 두고 운영합니다.

• 1단계 — 바꾸기 전 시스템(룰 전체 주입)에 평가 세트를 넣고 입력 토큰과 총비용을 기록한다
• 2단계 — RAG 라우터를 붙인 시스템에 같은 평가 세트를 그대로 넣는다
• 3단계 — 같은 항목을 기록하고 두 값의 차이를 비율로 낸다
• 4단계 — 골든 케이스 24개 회귀 감시로 결과가 달라진 사례가 없는지 확인한다

측정을 이렇게 짠 이유는 비교를 공정하게 하려는 데 있습니다. 평가 세트가 바뀌면 광고 길이와 페이지 수가 달라지고, 토큰 수는 시스템과 무관하게 출렁입니다. 같은 사례 묶음을 양쪽에 넣어야 차이를 라우터 덕으로 돌릴 수 있습니다. 넷째 단계는 절감이 품질을 깎아 먹지 않았는지 보는 장치입니다. 비용만 재고 품질을 재지 않으면, 룰을 마구 덜어 낸 시스템도 훌륭한 절감 사례처럼 보입니다.

표에서 눈여겨볼 줄은 룰 베이스 규모입니다. 비용은 줄었지만 룰은 하나도 버리지 않았습니다. 처음 가설의 옳은 절반, 즉 놓치지 않으려면 룰이 넓어야 한다는 판단은 그대로 살리고, 틀린 절반인 "매번 전부 넣는다"만 걷어 냈습니다.

왜 입력은 76% 줄었는데 총비용은 54%만 줄었나

두 비율이 다르다는 점이 이번 재측정에서 가장 쓸모 있는 신호입니다. 입력 토큰만 비용을 만든다면 총비용도 76% 가까이 줄어야 합니다. 실제로는 54%였습니다. 비용의 일부는 입력 토큰이 아닌 곳에서 나오고 있었고, 그 부분은 라우터를 붙여도 줄지 않았다는 뜻입니다.

기록은 그 차이의 내역을 나눠 적지 않았습니다. 다만 구조에서 짐작할 수 있는 후보는 둘입니다(추정 — 비용 항목별 분해 기록 없음). 하나는 출력 토큰입니다. 모델이 쓰는 검토 보고서의 길이는 넣는 룰 수와 상관없이 광고의 페이지 수와 위반 의심 항목 수를 따라갑니다. 다른 하나는 라우터 자신의 비용입니다. 경량 모델의 1차 분류 호출도 공짜가 아니고, 바꾸기 전에는 없던 비용입니다.

이 차이가 주는 교훈은 비용 절감 성과를 보고할 때 입력 토큰 감소율만 내세우면 안 된다는 점입니다. 76%는 엔지니어에게 정확한 숫자지만, 예산을 쥔 사람에게 의미 있는 숫자는 54%입니다. 이번에 두 값을 함께 잰 이유도 여기 있습니다. 한쪽만 쟀다면 절감 효과를 크게 부풀려 말했을 겁니다.

남는 한계는 무엇인가

이번 개선은 두 시점의 숫자로 결론을 냈고, 그 사이를 채우는 숫자는 비어 있습니다. 비어 있는 칸을 감추지 않고 그대로 적습니다.

• 427K와 104K가 광고 한 건 기준인지 평가 세트 합계인지 기록에 없다. 비율 76%는 성립하지만 건당 비용을 계산할 수는 없다
• 라우터가 해당 룰을 빠뜨린 비율은 따로 재지 않았다. 골든 케이스 24개를 통과했다는 사실은 그 24개 범위 안에서만 누락이 없다는 뜻이다
• 총비용 54% 감소의 내역, 곧 출력 토큰과 라우터 호출이 각각 얼마를 차지하는지는 나눠 재지 않았다
• 자동화 뒤 사람이 보고서를 확인하는 데 드는 시간은 아직 재지 않았다. 건당 30분~2시간과 맞비교할 숫자가 없다

가장 무거운 한계는 둘째 항목입니다. 골든 케이스 24개는 배포를 막는 최소선이지 라우터 품질의 증명이 아닙니다. 광고 유형이 새로 생기면 24개 밖의 사례에서 라우터가 룰을 빠뜨릴 수 있고, 그 실패는 "위반 없음" 보고서로 조용히 나옵니다. 다음 측정은 라우터가 고른 룰 묶음과 룰 전체 주입 결과를 같은 사례에서 비교해, 결과가 갈린 건수를 세는 방식이어야 합니다.

넷째 항목도 가볍지 않습니다. 이 시스템이 처음 겨냥한 숫자는 사람 검토 건당 30분에서 2시간이었고, 토큰 비용은 그 목표를 이루는 과정에서 생긴 부작용이었습니다. 비용을 54% 줄였다는 결과는 부작용을 다스렸다는 뜻이지, 처음 목표를 얼마나 이뤘는지 말해 주지 않습니다. 담당자가 자동 보고서를 받아 확인하고 고치는 데 드는 시간을 재야 비로소 이 자동화가 사람의 시간을 얼마나 돌려줬는지 말할 수 있습니다. 그 측정은 아직 하지 않았고, 이 글은 그 숫자를 지어내지 않습니다.

같은 원리를 다른 LLM 자동화에 옮길 때 무엇을 먼저 잴까

이 원리, 즉 "기준은 넓게 두고 매 건 넣는 기준은 고른다"는 규정 검토형 LLM 자동화라면 어디에나 옮길 수 있습니다. 같은 팀이 맡은 다른 자동화에서도 비슷한 모양이 나옵니다. 감독기관 자료요구 회신 자동 제출은 판정 규칙 회귀 테스트 29케이스와 과거 실제 회신 3건 검증에서 오탐 0을 확인한 뒤에야 켰고, 판정이 명확하고 첨부 없이 텍스트로 끝나는 답변만 자동 제출합니다. 마지막 메시지 뒤 15분 정정 대기와 실패 시 재시도 중단 스위치도 같은 이유로 붙였습니다. 넓게 받되, 실제로 내보내는 범위는 좁히고, 좁힌 범위는 회귀 테스트로 지킵니다.

• 평가 세트부터 만든다 — 운영 청구서는 물량에 따라 출렁여 전후 비교 잣대가 못 된다
• 입력 토큰과 총비용을 둘 다 잰다 — 이번에는 76%와 54%로 갈렸다
• 고르는 단계를 넣으면 누락 감시를 같이 넣는다 — 이번에는 골든 케이스 24개를 배포 게이트로 걸었다
• 기준 자체는 줄이지 않는다 — 룰 베이스는 수백 개 규모를 유지했다

LLM 토큰 비용 청구서가 불어나고 있다면 모델 교체보다 먼저 프롬프트에 매번 들어가는 고정 텍스트의 비중을 재 보길 권합니다. 그 텍스트 가운데 이번 요청과 무관한 몫이 크다면, 앞단에서 고르는 단계 하나로 이번과 같은 폭의 절감을 기대할 여지가 있습니다. 사내 문서 검토나 규정 대조 업무를 LLM으로 옮기는 중인데 비용과 정확도 사이에서 막혔다면 상담으로 상황을 알려 주세요.