LLM 비용 절감, 토큰 427K를 104K로 줄인 기록

무엇이 문제였나 — 룰이 수백 개로 늘면서 생긴 일

퀀팃투자자문에서 Business Operation·Compliance Manager로 2022년 5월부터 2024년 8월까지, 그리고 2025년 1월부터 지금까지 합산 약 4년을 재직하며 금융투자 광고 컴플라이언스 자동 검토 시스템을 운영했습니다. 이 시스템은 광고 콘텐츠를 자본시장법·금융소비자보호법·금융투자협회 광고 심사 매뉴얼 기준으로 대조합니다.

원래 이 검토는 사람이 직접 했고, 건당 30분에서 2시간이 걸렸습니다. 자동 검토 시스템은 이 수기 작업을 PDF·PPTX·이미지까지 페이지 단위로 전수 대조하는 자동 보고서 생성으로 바꿨습니다. 사람이 문서를 넘겨 가며 눈으로 대조하던 절차를, 기준 룰과 콘텐츠를 나란히 놓고 기계가 맞춰 보는 절차로 옮긴 셈입니다.

검토 정확도를 더 높이려고 심사 룰 베이스를 10배 넘게, 수백 개 규모로 넓혔습니다. 놓치는 위반을 줄이는 방향이었고, 실제로 그 방향 자체는 맞았습니다. 문제는 룰을 늘린 방식이 아니라 늘어난 룰을 매 건 심사에 쓰는 방식에서 생겼습니다.

룰이 하나 늘 때마다 이 시스템은 그 룰의 텍스트를 광고 콘텐츠와 함께 LLM 프롬프트에 그대로 실어 보냈습니다. 룰이 수백 개가 되면서 광고 한 건을 심사하는 요청 하나의 크기도 같이 불어났습니다. 2026년 5월 5일부터 7월 24일까지, 작업일 18일 동안 파일 112건을 처리하며 이 문제가 눈에 띄게 드러났습니다.

체감으로 짐작만 하지 않으려고 그 시점의 값을 그대로 재기로 했습니다. 요청이 무겁다는 느낌은 있었지만, 얼마나 무거운지, 그 무게가 실제로 비용에 어떻게 옮겨지는지는 아직 숫자로 없었습니다.

이 개선은 재직 기간 전체 가운데 2022년부터 2025년 사이에 걸쳐 있었습니다. 시스템이 먼저 자리를 잡은 뒤, 룰 베이스를 넓히는 단계와 넓힌 룰을 가볍게 쓰는 단계가 순서대로 이어졌습니다.

이 시스템이 다루는 광고는 투자자가 직접 보는 콘텐츠였습니다. 위반 하나를 놓치면 그 대가는 재검토 정도로 끝나지 않고 규제 기관의 제재로 이어질 수 있었습니다. 그래서 검토 정확도를 높이려고 룰 베이스를 10배 이상 넓히는 결정 자체는 미룰 수 없었습니다.

룰 하나를 새로 추가할 때마다 시스템 전체를 다시 배포해야 하지는 않았습니다. 룰 텍스트를 등록하면 다음 심사부터 곧바로 반영하는 구조였습니다. 그래서 룰을 늘리는 작업 자체는 가벼웠고, 정작 무거워진 쪽은 그 룰을 매번 쓰는 심사 요청이었습니다.

처음 잰 숫자 — 입력 토큰 427K

체감이 아니라 숫자로 확인하려고 eval을 돌려 재는 방식을 썼습니다. 실제 심사 요청 하나가 LLM에 넣는 input 토큰 수를 그대로 측정하는 방식이고, 새로 만든 계측이 아니라 이미 있던 eval 파이프라인을 그대로 돌린 결과입니다.

기준값은 427K였습니다. 광고 콘텐츠 한 건을 심사할 때마다 이 정도 크기의 입력을 LLM에 밀어 넣고 있었다는 뜻입니다. 이 숫자는 곧바로 비용으로 이어집니다 — LLM 비용은 대체로 입력 토큰 양에 비례해 청구되기 때문입니다.

숫자를 먼저 재고 조치는 그다음이라는 순서는 이번에 새로 정한 규칙이 아니었습니다. 같은 팀이 다른 자동화 작업에서도 지켜 온 원칙이었습니다.

자동화 이전 소요 시간을 먼저 기록하고 그 값을 기준으로 개선 폭을 판단합니다. 체감이 아니라 기록으로 남깁니다.

이 원칙을 그대로 따라, 룰 베이스를 넓히기 전과 후를 곧장 비교하는 대신 넓힌 상태에서의 절대값 427K를 먼저 출발점으로 남겼습니다. 개선율이 아니라 절대값을 먼저 적어 둬야 나중에 무엇이 얼마나 줄었는지 정확히 말할 수 있습니다.

이 시점에는 아직 룰을 거르는 절차가 없었습니다. 그래서 427K라는 숫자는 사실상 룰 베이스 전체를 텍스트로 옮긴 크기와 거의 같았습니다. 룰이 늘어난 만큼 요청 크기도 그대로 늘어나는 구조였다는 뜻입니다.

세운 가설 — 룰을 다 넣어야 놓치는 게 없다

427K라는 숫자를 처음 봤을 때 세운 가설은 단순했습니다. 룰 베이스를 10배로 넓힌 이유 자체가 커버리지를 놓치지 않기 위해서였으니, 심사할 때도 넓힌 룰 전체를 매번 프롬프트에 넣는 편이 안전하다는 가설이었습니다.

이 가설에는 나름의 근거가 있었습니다. 어떤 룰을 미리 걸러 낸다는 것은 그 걸러내는 판단 자체가 틀릴 위험을 새로 만드는 일입니다. 잘못 걸러 낸 룰 하나가 실제로 걸려야 할 위반을 놓치면, 그 대가는 규제 위반이라는 오류 비용으로 돌아옵니다.

반복 주기가 잦고 건당 오류 비용이 큰 작업일수록 손을 적게 대는 편이 안전하다는 기준을 이 시스템에도 그대로 적용했습니다. 매 건 반복해야 하는 작업이고, 광고 컴플라이언스 위반의 오류 비용은 작지 않았습니다. 그래서 비용을 아끼려고 룰을 거르기보다 수백 개 전량을 그대로 넣는 쪽을 택했습니다.

반복 주기 × 건당 소요 시간 × 오류 비용으로 우선순위를 정하고, 감이 아니라 실측치로 착수 여부를 판단합니다.

이 가설 위에서는 427K라는 토큰 수가 비효율이 아니라 안전을 위해 치르는 비용으로 보였습니다. 룰을 줄이자는 이야기는 곧 커버리지를 줄이자는 이야기처럼 들렸고, 그래서 먼저 검토한 방향은 룰 선별이 아니라 프롬프트 텍스트 자체를 압축하는 쪽이었습니다.

이 시점에는 골든 케이스 회귀 감시도 아직 없었습니다. 룰을 건드리면 판정이 어떻게 달라지는지 배포 전에 확인할 장치가 없었기 때문에, 룰을 줄이는 시도 자체가 더 위험하게 느껴졌습니다. 안전장치가 없는 상태에서는 아무것도 바꾸지 않는 편이 가장 안전해 보였습니다.

이 가설은 팀 안에서 별다른 이견 없이 받아들여졌습니다. 매 건 오류 비용이 큰 영역에서는 손을 대는 쪽보다 안 대는 쪽이 안전하다는 판단이 그 시점 기준으로는 합리적이었기 때문입니다.

가설이 틀린 지점 — 왜 전체 룰 주입은 답이 아니었나

이 가설을 무너뜨린 것은 새로운 계측이 아니라 같은 숫자를 다르게 본 시선이었습니다. 427K짜리 입력 안에서, 광고 콘텐츠 한 건이 실제로 저촉될 가능성이 있는 룰이 몇 개나 있는지를 따로 세어 봤습니다.

답은 수백 개 중 일부였습니다. 특정 상품군·특정 문구·특정 매체에만 걸리는 룰들이 그 조건과 관련 없는 광고 콘텐츠에도 매번 똑같이 함께 실려 갔습니다. 룰을 다 넣는 방식은 위반을 놓치지 않는다는 목표는 지켰지만, 그 대가로 프롬프트 대부분을 무관한 텍스트로 채우고 있었습니다.

프롬프트 텍스트를 압축하는 방향으로 먼저 검토했던 것도 이 지점에서 방향을 잃었습니다. 룰 문장 하나하나를 짧게 줄여도, 애초에 그 문장이 이 광고와 관련이 없다면 짧아진 만큼만 이득일 뿐 문제의 크기는 그대로였습니다. 줄여야 할 것은 문장의 길이가 아니라 문장의 개수였습니다.

룰 전체 주입이 커버리지를 지키는 안전장치라는 전제 자체는 틀리지 않았습니다. 문제는 그 안전장치를 유지하는 방법이 '다 넣는다'밖에 없다고 가정한 데 있었습니다. 커버리지를 지키는 일과 룰 전량을 매번 주입하는 일은 같은 것이 아니었습니다.

같은 광고 콘텐츠 여러 건을 나란히 놓고, 각 건이 저촉될 가능성이 있다고 볼 수 있는 룰 목록을 비교해 봤습니다. 겹치는 룰은 일부에 그쳤고, 나머지는 그 광고와 무관한 상품군이나 매체 조건을 다루는 룰이었습니다. 같은 모습이 계측 구간의 파일 112건 전반에서 반복됐습니다.

이 발견은 새 도구를 도입한 결과가 아니었습니다. 이미 쌓여 있던 심사 로그를 다시 열어, 각 건에 실려 간 룰 텍스트와 실제 판정에 쓰인 룰을 나란히 놓고 비교한 결과였습니다. 새 도구를 만들기 전에 기존 기록을 다시 보는 쪽이 먼저였습니다.

진짜 원인 — 광고 콘텐츠 한 건에 걸리는 룰은 일부뿐이었다

진짜 원인은 룰의 개수가 아니라, 매 건 심사에서 관련 룰과 무관한 룰을 미리 가르지 않았다는 데 있었습니다. 시스템은 '이 광고에 어떤 룰이 걸리는가'라는 질문 자체를 심사 LLM에게 통째로 떠넘기고 있었고, 그 LLM은 이 질문에 답하기도 전에 이미 수백 개 룰 전체를 읽어야 했습니다.

이 구조는 사내 다른 규칙에서 이미 다뤄 온 문제와 같은 모양이었습니다. 사실을 주장하기 전에 근거 자료를 먼저 확인하고, 확인한 근거만 인용한다는 원칙입니다.

Read before claim. Cite or abstain.

이 원칙을 뒤집어 보면, 인용할 필요가 없는 자료까지 전부 끌어와 놓고 그 안에서 답을 찾는 방식은 비효율입니다. 광고 컴플라이언스 심사도 마찬가지였습니다. 광고 콘텐츠와 무관한 룰은 애초에 프롬프트에 인용될 필요가 없었는데, 그 판단을 아무도 먼저 하지 않았습니다.

결국 필요했던 것은 룰 수를 줄이는 일이 아니라, 매 건 심사보다 앞선 자리에서 '이 콘텐츠에 어떤 룰이 걸릴 수 있는가'를 먼저 판단하는 단계였습니다.

이 결론은 하루 만에 나오지 않았습니다. 여러 날에 걸쳐 처리한 파일 112건을 다시 열어, 각 건에서 실제로 인용된 룰과 인용될 필요가 없었던 룰을 나눠 세어 보고 나서야 이 결론에 이르렀습니다.

조치 — 경량 모델이 먼저 룰을 고르는 RAG 라우터

조치는 심사 LLM 앞에 RAG 라우터를 세우는 것이었습니다. 경량 모델이 광고 콘텐츠를 먼저 1차로 분류해, 수백 개 룰 중 실제로 걸릴 가능성이 있는 룰만 후보로 골라냅니다.

• 경량 모델이 광고 콘텐츠를 1차로 분류해 적용 가능성이 있는 룰 후보를 추린다
• 심사를 맡는 본 LLM에는 그 후보 룰만 프롬프트로 주입한다
• 룰이나 모델을 바꿀 때마다 골든 케이스 24개로 기존 판정이 깨지지 않는지 배포 전에 확인한다

세 번째 단계가 핵심 안전장치입니다. 룰을 거르는 방식으로 바꾸면 정말 걸러도 좋은지 의심이 새로 생깁니다. 그래서 골든 케이스 24개로 회귀 감시를 구성하고, 이것을 배포 게이트로 운영했습니다. 룰 베이스나 라우팅 모델을 바꿀 때마다 이 24개 케이스의 판정이 그대로인지 배포 전에 확인하고, 깨지면 배포하지 않습니다.

이 방식은 사내 소프트웨어 품질 평가 규칙에도 같은 문장으로 적혀 있습니다.

Golden pass@1이 5%+ 하락 시 release 차단합니다.

같은 규칙 문서는 골든 데이터셋을 처음부터 완벽하게 채우지 말라고도 정합니다. 10개에서 15개로 시작해 30개에서 50개까지 넓혀 가라는 순서입니다. 24개는 그 사이에 있는 규모이고, 처음부터 완벽한 표본이 아니라 되풀이하는 판정 패턴을 먼저 잡은 시작점이었습니다.

판정 기준도 LLM 하나에 맡기지 않았습니다. 여러 판정자의 의견을 평균 내는 방식은 전문가 동의율이 64%에서 68%에 그친다는 근거로 단독 판단에서 제외하고, 골든 케이스는 사람이 미리 정해 둔 정답과 그대로 맞는지 아닌지를 결정론적으로 대조합니다. 룰을 거르는 방식이 새로 만드는 위험은 이 회귀 감시가 대신 짊어졌고, 심사 LLM에 들어가는 프롬프트는 그만큼 가벼워졌습니다.

라우터가 고른 후보 룰 목록은 곧바로 심사 LLM에 넘어갔고, 사람이 다시 손으로 골라내는 단계는 따로 두지 않았습니다. 사람이 하는 일은 골든 케이스 24개의 판정 결과를 확인하는 것으로 좁혀졌습니다.

골든 케이스 24개를 외부 공개 벤치마크가 아니라 이 시스템이 실제로 심사한 콘텐츠에서 뽑은 이유도 있습니다. 널리 쓰이던 한 공개 검증 세트가 실제로는 문제의 59.4%에 결함이 있었다는 사실이 드러나 폐기된 사례가 근거였습니다. 개선 판단은 우리가 실제로 다루는 사례로만 내린다는 원칙을 그대로 따랐습니다.

순서도 중요했습니다. 심사 LLM을 먼저 손보고 골든 케이스를 나중에 만들면, 그사이 무엇이 깨졌는지 확인할 방법이 없습니다. 회귀 감시부터 먼저 갖추고 그다음 라우터를 넣은 순서가 이 조치에서 가장 중요한 부분이었습니다.

라우팅을 맡는 경량 모델이 잘못 판단해 필요한 룰을 후보에서 빠뜨릴 위험도 검토했습니다. 이 위험을 잡아내는 장치가 바로 골든 케이스 24개였고, 그래서 라우터 도입과 회귀 감시 도입을 하나의 조치로 묶어 함께 진행했습니다.

재측정 결과 — 토큰 76% 감소, 비용 54% 감소

RAG 라우터를 넣은 뒤, 처음 잰 것과 같은 방식으로 다시 쟀습니다. 같은 eval로 같은 방식의 심사 요청을 넣고 input 토큰과 총 비용을 측정했습니다.

입력 토큰은 427K에서 104K로 줄었습니다. 76% 감소입니다. 총 비용은 54% 줄었습니다. 두 수치 모두 같은 eval로 실측한 값입니다.

76%와 54%라는 두 숫자가 서로 다른 이유는 토큰만으로 비용이 정해지지 않기 때문입니다. 라우팅을 맡는 경량 모델도 매 건 호출되면서 그 자체로 비용을 씁니다. 토큰 절감폭 76%가 비용 절감폭 54%보다 큰 차이는 이 라우팅 호출 비용을 포함한 결과로 볼 수 있습니다.

골든 케이스 24개도 이 재측정과 함께 다시 돌렸습니다. 룰을 거르는 방식으로 바뀐 뒤에도 기존 판정이 그대로인지가 이 배포의 조건이었고, 그 조건을 통과한 뒤에야 이 수치를 실제 운영에 반영했습니다.

작업일 18일·파일 112건을 처리하던 그 계측 구간과 같은 조건에서 다시 쟀다는 점도 남겨 둡니다. 시스템도, 재는 방법도 바뀌지 않은 상태에서 오직 룰 주입 방식만 바뀐 결과입니다.

재측정 순서도 바꾸지 않았습니다. 먼저 절대값을 재고, 그다음 전후 비율을 계산하는 순서를 그대로 지켰습니다. 76%와 54%는 이 순서의 마지막 단계에서 나온 결과이지, 미리 정해 둔 목표치가 아니었습니다.

사람이 나서야 하는 비율의 상한도 10% 이하로 잡아 둡니다. 골든 케이스 판정이 그대로인 한, 사람이 직접 룰 후보를 다시 확인하는 일은 배포 게이트를 통과하지 못했을 때뿐입니다.

남는 한계 — 무엇을 아직 모르는가

이 글에 없는 숫자도 있습니다. 판정 정확도, 즉 위반을 놓치는 비율이 라우터 도입 전후로 각각 몇 퍼센트였는지는 이 기록에 없습니다. 골든 케이스 24개가 판정이 깨지지 않았다는 사실은 확인했지만, 그 24개가 수백 개 룰의 커버리지를 얼마나 대표하는지는 별도로 확인하지 않았습니다.

54%라는 비용 절감폭도 무엇을 포함한 숫자인지 이 기록만으로는 다 알 수 없습니다. 라우팅에 쓰는 경량 모델 호출 비용은 포함됐다고 볼 수 있지만, 심사 LLM의 output 토큰 비용까지 같은 조건으로 잡았는지는 이 코퍼스에 남아 있지 않아 확인이 필요합니다. 76%와 54%, 두 숫자의 차이가 정확히 어디서 갈리는지는 다음 계측에서 밝힐 부분으로 남겨 둡니다.

PDF·PPTX·이미지까지 페이지 단위로 전수 대조하는 이 시스템에서, 이미지 페이지에도 같은 라우터가 똑같이 걸리는지도 이 기록에는 없습니다. 텍스트 룰 선별과 이미지 룰 선별이 같은 방식으로 동작하는지는 다음에 확인할 부분으로 남깁니다.

골든 케이스 24개는 사내 규칙이 정한 확장 목표인 30개에서 50개에는 아직 못 미칩니다. 되풀이하는 판정 패턴을 먼저 잡은 시작점이라고는 했지만, 규모를 더 넓히는 작업 자체는 아직 끝나지 않았습니다. 다음 단계는 지금 있는 24개를 지키면서 새 사례를 그 위에 더 얹는 일입니다.

2026년 5월 5일부터 7월 24일까지의 계측 구간 이후로 파일 처리량이 늘거나 줄었을 때도 76%와 54%라는 같은 비율이 그대로인지는 이 글에 없습니다. 처리 규모가 지금보다 커지면 라우팅을 맡는 경량 모델 자체의 비용 비중이 달라질 수 있습니다.

골든 케이스 판정을 결정론적으로 대조하는 방식이 놓치는 것도 있습니다. 정답과 문구가 완전히 같은 경우가 아니라 표현은 다르지만 의미상 같은 판정으로 나온 경우까지 24개 안에서 잡아내는지는 이 기록에서 따로 확인하지 않았습니다.

이 글은 지금 시점에서 다시 정리한 기록입니다. 당시 심사 요청 하나하나의 룰 매칭 로그를 지금 다시 꺼내 재현하지는 않았고, 남아 있는 것은 eval이 남긴 집계값 427K·104K·76%·54%와 골든 케이스 24개라는 구성뿐입니다. 세부 로그가 없어도 이 정도 숫자만으로 무엇이 얼마나 줄었는지는 분명히 말할 수 있습니다.

숫자를 먼저 재고 조치는 그다음이라는 순서를 지키다가도, 정작 무엇을 재는 도구 자체를 의심해야 했던 경험은 다른 자리에도 있습니다. Claude Code가 자율 실행 중 왜 예상보다 일찍 멈추는지 계측한 기록도 같은 순서를 다룹니다. 심사·검토처럼 되풀이하는 작업에서 비용이 어디로 새는지 확인하고 싶다면 상담에서 이야기할 수 있습니다.