<div id="readability-page-1" class="page"><div>토스의 수많은 서비스와 내부 업무에도 생성형 AI가 정말 많이 사용되고 있습니다. 복잡한 정책을 읽고, 상품 정보를 비교하고, 문서를 요약하고, 정해진 형식의 값을 추출하는 등, LLM이 맡는 범위도 빠르게 넓어지고 있죠.시간도 비용도 비싼 데이터 레이블링을 통해 모델을 학습하고 문제를 해결하던 과거 방식과 달리, LLM을 사용하면 빠른 시간 내에 사용할 수 있는 솔루션이 만들어집니다. 프롬프트를 작성하고, 몇 가지 예시를 넣고, 응답 형식을 고정하면 동작하는 Workflow가 나오죠. 하지만 프롬프트 튜닝을 마치고 본격적으로 대용량 호출을 시작하면 새로운 문제가 보이기 시작합니다.바로 비용과 Latency입니다.이 토큰 먹는 하마는 정말 토스의 모든 문제 해결에 지속적으로 필요한걸까요?<h2 id="405a360d-33e3-803a-8a13-c202b70048ca">LLM Fine-Tuning is all you need?</h2>상용 LLM을 사용하지 않고 내재화 한다면, 비용을 크게 절감할 수 있습니다. 작업 목표에 따라 LoRA(Low-Rank Adaptation)처럼 효율적인 Adapter 학습을 사용할 수도 있고, 더 큰 품질 개선이나 안정성이 필요하다면 Full Fine-Tuning을 검토할 수도 있습니다. 실제로 토스에서도 LLM Fine-Tuning 을 통해 비용을 크게 절감한 사례도 있어요.그런데 모든 LLM 호출에 같은 수준의 능력이 필요한 것은 아닙니다. 복잡한 문맥을 이해하고 긴 답변을 생성해야 하는 작업도 있지만, 두 상품이 같은지 판단하거나 정해진 카테고리 중 하나를 고르는 작업도 있어요. 이런 작업이 반드시 범용 LLM의 모든 능력을 필요로 하지는 않습니다. 작업의 복잡도와 요구되는 품질에 따라, 전통적인 ML 모델이나 특정 작업에 최적화한 소형 모델을 적절히 선택해도 충분히 처리할 수 있는 경우가 있죠. 중요한 것은 모델의 크기보다, 주어진 작업에 필요한 품질을 확보할 수 있느냐입니다.<figure id="405a360d-33e3-8006-864f-cb2dfefa5e21"><img src="https://static.toss.im/ipd-tcs/toss_core/live/6dc9854f-7439-4012-85d0-48eb97209fe9/figure-01-task-types.png" alt=""><figcaption>Figure 1. LLM이 처리하는 다양한 작업. 작업의 특성과 요구 품질에 따라 적합한 모델도 달라집니다.</figcaption></figure><h2 id="405a360d-33e3-800e-b9b2-d99e9cffc2e6">전환이 가능한 트래픽부터 내재화하기</h2>'작은 모델'이 가지는 장단점은 명확합니다. 빠르고, 자원 소모가 적지만, 처리할 수 있는 문제의 범위에는 제약이 있어요.간단한 질문으로 시작해봤습니다. 내재화 모델은 꼭 LLM과 동등한, 혹은 견줄 만한 수준으로 성능을 끌어올려야만 사용할 수 있는 걸까? 빠르고 작은 모델이라도 쉬운 요청은 충분히 처리할 수 있을 텐데?이 질문으로부터 선택적 내재화(SNAP, Selective Native AI Processing)를 기획하게 되었어요. SNAP의 핵심은 해결해야 하는 문제의 모든 요청을 한 번에 Native Model로 처리하는 것이 아니라, 작은 모델도 높은 신뢰도로 처리할 수 있는 트래픽부터 빠르게 처리하는 것입니다.고비용 LLM Traffic을 한 번에 없애기보다, 처리 가능한 구간을 찾아 타노스가 손가락을 튕기듯(SNAP!) 손쉽게 줄여보자는 의미도 담겨 있죠. 큰 틀에서 SNAP은 다음 3가지 규칙을 하나의 Workflow로 묶습니다.자, 그렇다면 작업별 소형 모델을 만들기 위해서 먼저 작업별로 학습데이터가 될 LLM 로그부터 수집해야겠죠? 그런데 여기서 한 가지 문제가 있었습니다.<h2 id="405a360d-33e3-8095-9378-fbcfd0735ec5">방대한 LLM 로그들을 동일한 작업으로 어떻게 분류하죠?</h2>LLM 호출 로그에는 굉장히 다양하고 이질적인 요청들이 섞여서 들어옵니다. LLM 으로 보내는 요청은 사람에게 말하듯 높은 자유도가 주어지기 때문에 같은 API Key, 같은 Endpoint를 사용해 호출하더라도 동일한 작업임을 전혀 보장할 수가 없죠. 그래서 먼저 요청을 작업 단위로 묶을 기준이 필요했습니다. 다양한 Task들의 로그에서 나타나는 공통적인 특징은 Prompting 방식이었습니다. 많은 LLM Workflow는 System Prompt 앞부분에서 LLM에게 Role을 부여하고, 해결해야 할 문제와 함께 문제 해결 방식을 정의하는데요. 살펴본 로그에서는 Few-shot 예제가 바뀌어도 역할과 작업 정의는 대체로 유지됐습니다. SNAP은 이 특성을 이용해 system prompt 앞부분을 해시하고, 이를 작업을 구분하는 Fingerprint로 사용했습니다.<figure id="405a360d-33e3-80de-a6dc-c47d385b7b61"><img src="https://static.toss.im/ipd-tcs/toss_core/live/2f209567-ed52-4489-b0ca-90207fb8d5e6/image.png" alt=""><figcaption>Figure 2. Role 부여와 작업 정의에 변동 폭이 작은 LLM 호출 프롬프트의 특성을 이용한 작업 분리</figcaption></figure><h2 id="405a360d-33e3-8096-8d46-e9ed04066227">후보 발굴부터 모델 학습까지 자동화하기</h2>작업 단위로 로그를 살펴보니 또 다른 문제가 있었습니다. 짧은 기간 안에 새로운 작업이 생기기도 했고, 얼마 지나지 않아 사라지기도 했어요. LLM으로 빠르게 개념 검증(PoC, Proof of Concept)을 진행한 뒤 작업을 변경하거나 프로젝트를 중단하는 경우가 있기 때문이었죠. 계속 바뀌는 작업을 사람이 하나씩 살펴보며 내재화 후보를 고르기에는 한계가 있었습니다.그래서 SNAP은 내재화 후보 발굴부터 데이터셋 구축, 모델 학습까지의 과정을 자동화했습니다. 먼저 매일 호출 로그를 Task Fingerprint별로 묶어 호출량, 사용 중인 LLM 모델, 입력·출력 토큰 수와 추정 비용을 집계합니다. 최근 일정 기간의 추정 비용이 최소 기준을 넘는 작업을 비용순으로 정렬하고, 정해진 수만큼 후속 검증 대상으로 선정합니다. Table 1은 비용 기반 상위 30개 작업을 선정한 로그를 재구성한 예시입니다.<figure id="405a360d-33e3-80e1-abcd-fdc8ddd88685"><img src="https://static.toss.im/ipd-tcs/toss_core/live/94e0259a-41bb-44d3-8b08-21ab5308ccc0/image.png" alt=""><figcaption>Table 1. 작업별 추정 비용을 기준으로 상위 30개 작업을 후속 검증 대상으로 선정한 예시. 중간 순위는 생략했으며, 비용은 설명을 위한 가상 값입니다.</figcaption></figure>선정된 작업은 요청과 응답을 분석해 학습 가능성을 검증합니다. 응답이 정형화되어 있고 그 안에서 학습용 레이블을 안정적으로 추출할 수 있는지 확인합니다. 데이터셋을 구성하면서 레이블별 데이터가 충분한지, 학습과 평가에 사용할 데이터를 분리할 수 있는지도 검증합니다. 이 조건을 통과한 작업만 모델 학습으로 이어집니다.이 과정은 Airflow의 일일 배치로 연결했습니다. 후보 선정과 데이터 구성 기준을 충족한 작업은 사내 학습 라이브러리를 통해 하루 안에 학습된 모델을 확보할 수 있습니다. 학습한 모델은 모델 레지스트리에 등록하며, 운영에 적용할 모델은 서빙 엔진이 불러와 요청을 처리합니다.<h2 id="405a360d-33e3-80c0-b534-cfda511e8e9d">SNAP의 첫 내재화 모델 배포: 텍스트 기반 동일상품 판별</h2>SNAP의 첫 적용 대상은 두 상품의 이름과 옵션 정보를 비교해 같은 판매 단위인지 판단하는 작업이었습니다. 브랜드, 모델명, 용량, 색상, 구성품 등의 차이를 읽고 동일 상품 여부를 분류하는 문제였죠. 입력과 출력의 범위가 명확하고 기존 LLM 응답도 충분히 쌓여 있어, 소형 분류 모델을 적용하기에 적합했습니다.첫 적용 모델과 평가 데이터는 다음과 같이 구성했습니다.<figure id="405a360d-33e3-8035-80fe-d79d5305ed71"><img src="https://static.toss.im/ipd-tcs/toss_core/live/d542dc7f-68b7-4a68-8066-893f0b3d0575/image.png" alt=""></figure><h3 id="405a360d-33e3-8043-93cd-fabfb95f47a9">Confidence로 채택 범위 정하기</h3>모델은 판단 결과와 함께 자신 있는 정도를 나타내는 점수, Confidence를 반환합니다. 하지만 이 점수가 높다고 해서 실제로 얼마나 잘 맞히는지까지 알 수 있는 것은 아니에요. Confidence가 0.95라고 해서 정답률이 95%라는 뜻은 아니죠. 그래서 검증 데이터에서 Confidence 점수가 높은 결과만 골라 다음 두 가지를 확인했습니다.먼저 목표 일치율을 정하고, 결과를 채택할 최소 점수(Threshold)를 바꿔가며 비교했습니다. 목표를 만족하는 범위에서 가장 많은 요청을 처리할 수 있는 기준을 찾는 것입니다. 학습 중 저장한 모델들도 같은 방식으로 비교해 사용할 모델과 기준 점수를 함께 선택했습니다.<figure id="405a360d-33e3-8025-9fc6-fc5845b4663c"><img src="https://static.toss.im/ipd-tcs/toss_core/live/f38f01bf-4049-4e00-8a4c-492e14bed94c/figure-03-confidence.png" alt=""><figcaption>Figure 3. Confidence threshold에 따른 요청 채택 범위. 분포와 threshold 위치는 설명을 위한 가상 값입니다.</figcaption></figure>첫 배포의 목표 일치율은 99.9%로 정했습니다. 이 조건에서 검증 요청 100,648건 중 34,963건을 채택해 coverage 34.74%를 확보했습니다. 채택한 결과 중 기존 LLM 판단과 불일치한 건수는 34건으로, 실제 일치율은 99.9028%였습니다. 목표 일치율을 99%로 낮추면 coverage는 51.59%, 95%로 낮추면 72.35%까지 높아졌습니다. 작업에서 요구하는 품질에 따라 내재화할 수 있는 요청의 범위도 달라지는 것이죠.<figure id="405a360d-33e3-80d2-85f5-d911c0c05190"><img src="https://static.toss.im/ipd-tcs/toss_core/live/2c1d971d-22e9-4ca3-afae-9d5dfb599e59/figure-04-coverage.png" alt=""><figcaption>Figure 4. 목표 LLM 레이블 일치율에 따른 오프라인 Coverage. 첫 배포에서는 목표 일치율 99.9%, Coverage 34.74%인 조건을 선택했습니다. 이 수치는 모델과 Threshold 선택에 사용한 검증 데이터에서 측정했습니다.</figcaption></figure><h2 id="405a360d-33e3-80f2-9b43-c150431d9e58">Client는 언제 어떤 모델을 사용할지 어떻게 판단하죠?</h2>클라이언트는 GenAI Gateway를 통해 먼저 내재화 모델을 호출합니다. 반환된 Confidence가 Threshold 이상이면 모델의 결과를 사용하고, 기준에 못 미치면 기존 LLM을 추가 호출합니다.<figure id="405a360d-33e3-8088-89a2-fbf1ff23180b"><img src="https://static.toss.im/ipd-tcs/toss_core/live/c477a31b-4111-4c35-932a-9faf03a50cd2/figure-05-pipeline.png" alt=""><figcaption>Figure 5. 클라이언트가 내재화 모델의 Confidence Score를 기준으로 결과를 채택하거나 LLM을 추가 호출합니다.</figcaption></figure><h2 id="405a360d-33e3-80af-a45a-caa870fb26e0">첫 배포 결과</h2>결과는 어땠을까요? 첫 배포 후 약 6일간, 동일 상품 판별 작업에서 내재화 모델이 처리한 요청 비율은 일별 약 33~37%였습니다. 오프라인에서 확인한 Coverage 34.74%와 비슷한 비율의 요청을 실제 운영에서도 내재화 모델로 처리했네요. 모델이 자신 있게 처리할 수 있다고 판단한 구간이 실제 운영에서도 의미 있게 적용되고 있다는 뜻입니다.이 기간에 줄어든 LLM Token 사용량은 다음과 같습니다.<ul><li id="405a360d-33e3-8081-be43-dd3b8271304d">입력 토큰: 약 76억 개</li><li id="405a360d-33e3-8015-9240-d99a590d1a14">출력 토큰: 약 4,520만 개</li></ul>서빙 성능도 부하 테스트에서 확인했습니다. 목표 요청량을 초당 10건부터 1,200건까지 높이며 클라이언트에서 응답 시간을 측정했습니다. 운영 피크인 초당 약 500건을 넘는 598건 처리 구간에서 p50(중앙값) 응답 시간은 7.24ms였습니다. 실제 처리량이 초당 1,203건인 구간에서도 p50은 9.02ms, p99(상위 1% 응답 시간)는 15.23ms였고, 모든 테스트 구간에서 실패하거나 드롭된 요청은 없었습니다.<figure id="405a360d-33e3-800f-a03f-ca2fb6ff64e8"><img src="https://static.toss.im/ipd-tcs/toss_core/live/df9699c4-a2e5-4b84-affa-7c03ca8fe6f2/figure-06-latency.png" alt=""><figcaption>Figure 6. L4 GPU 1장 환경에서 측정한 실제 처리량과 클라이언트 응답 시간의 p50·p99. </figcaption></figure><h3 id="405a360d-33e3-806e-bc2e-c56a7c9e71d9">전부 바꾸지 않아도 절감은 시작됩니다</h3>전체 요청을 내재화 모델로 대체하려면, 그만큼 넓은 범위에서 요구 품질을 확보해야 합니다. 어려운 요청까지 처리하기 위해 개발과 학습을 반복하다 보면 투자 규모가 커질 수 있고, 목표 품질에 도달하지 못하면 운영 적용 자체가 미뤄질 수도 있습니다. 실제 유사한 분류 작업을 전체 내재화하기 위해 여러 버전의 테스트셋으로 반복하는 과정을 거쳤고, 개발에 1~2개월의 시간이 소요되었습니다.SNAP은 이 부담을 줄이기 위해 후보 발굴과 학습을 자동화하고, 소형 모델이 검증 기준을 만족하는 요청부터 적용했습니다. 모든 요청을 해결하는 모델을 완성하기 전에, 운영에서 LLM 호출을 줄이기 시작한 것입니다. 작업이 빠르게 생겨나고 바뀌는 환경에서는 최종 전환율 뿐 아니라, 얼마만큼의 자원으로 얼마나 빨리 적용할 수 있는지도 중요합니다.<figure id="405a360d-33e3-8023-8ee2-fad821198fde"><img src="https://static.toss.im/ipd-tcs/toss_core/live/140884af-6062-4942-8cef-7dfb79a114c8/figure-07-conversion.png" alt=""><figcaption>Figure 7. 전체 요청을 한 번에 전환하는 방식과 달리, SNAP은 검증된 구간부터 부분 적용해 비용 절감을 먼저 시작합니다. </figcaption></figure><h2 id="405a360d-33e3-802a-9c3a-d4cc8b7987fd">LLM을 더 자유롭게 사용할 수 있도록</h2>오늘도 SNAP은 반복되는 LLM 호출을 집계하고, 내재화할 수 있는 작업을 찾아 새로운 소형 모델을 학습하고 있습니다. 앞으로는 각 도메인 팀과 실제 요청에서 드러나는 오류와 요구 품질을 함께 살피고, 데이터와 모델을 개선하며 적용 범위를 넓혀가려 합니다.모델의 선택지도 넓혀가고 있습니다. JEV처럼 특정 판단 문제에 맞춘 Decision Engine 형태의 모델도 튜닝하며 SNAP에 활용할 수 있을지 실험하고 있습니다. 실제 운영 결과를 바탕으로 품질과 비용을 함께 고려한 내재화 기준을 다듬어 가겠습니다.이 과정을 통해 각 도메인의 팀이 비용 걱정보다 풀고 싶은 문제에 더 집중할 수 있기를 바랍니다. LLM으로 아이디어를 빠르게 검증하고, 더 나은 의사결정과 비즈니스 임팩트로 연결할 수 있도록요. LLM을 활용한 시도는 더 자유롭게, 그 시도를 이어가는 비용 부담은 더 작게. 그것이 토스가 만들어가고 싶은 방향입니다.</div></div>

토스테크

토스의 수많은 서비스와 내부 업무에도 생성형 AI가 정말 많이 사용되고 있습니다. 복잡한 정책을 읽고, 상품 정보를 비교하고, 문서를 요약하고, 정해진 형식의 값을 추출하는 등, LLM이 맡는 범위도 빠르게 넓어지고 있죠.
시간도 비용도 비싼 데이터 레이블링을 통해 모델을 학습하고 문제를 해결하던 과거 방식과 달리, LLM을 사용하면 빠른 시간 내에 사용할 수 있는 솔루션이 만들어집니다. 프롬프트를 작성하고, 몇 가지 예시를 넣고, 응답 형식을 고정하면 동작하는 Workflow가 나오죠. 하지만 프롬프트 튜닝을 마치고 본격적으로 대용량 호출을 시작하면 새로운 문제가 보이기 시작합니다.
바로 비용과 Latency입니다.
이 토큰 먹는 하마는 정말 토스의 모든 문제 해결에 지속적으로 필요한걸까요?
LLM Fine-Tuning is all you need?
상용 LLM을 사용하지 않고 내재화 한다면, 비용을 크게 절감할 수 있습니다. 작업 목표에 따라 LoRA(Low-Rank Adaptation)처럼 효율적인 Adapter 학습을 사용할 수도 있고, 더 큰 품질 개선이나 안정성이 필요하다면 Full Fine-Tuning을 검토할 수도 있습니다. 실제로 토스에서도 LLM Fine-Tuning 을 통해 비용을 크게 절감한 사례도 있어요.
그런데 모든 LLM 호출에 같은 수준의 능력이 필요한 것은 아닙니다. 복잡한 문맥을 이해하고 긴 답변을 생성해야 하는 작업도 있지만, 두 상품이 같은지 판단하거나 정해진 카테고리 중 하나를 고르는 작업도 있어요. 이런 작업이 반드시 범용 LLM의 모든 능력을 필요로 하지는 않습니다. 작업의 복잡도와 요구되는 품질에 따라, 전통적인 ML 모델이나 특정 작업에 최적화한 소형 모델을 적절히 선택해도 충분히 처리할 수 있는 경우가 있죠. 중요한 것은 모델의 크기보다, 주어진 작업에 필요한 품질을 확보할 수 있느냐입니다.
전환이 가능한 트래픽부터 내재화하기
'작은 모델'이 가지는 장단점은 명확합니다. 빠르고, 자원 소모가 적지만, 처리할 수 있는 문제의 범위에는 제약이 있어요.
간단한 질문으로 시작해봤습니다. 내재화 모델은 꼭 LLM과 동등한, 혹은 견줄 만한 수준으로 성능을 끌어올려야만 사용할 수 있는 걸까? 빠르고 작은 모델이라도 쉬운 요청은 충분히 처리할 수 있을 텐데?
이 질문으로부터 선택적 내재화(SNAP, Selective Native AI Processing)를 기획하게 되었어요. SNAP의 핵심은 해결해야 하는 문제의 모든 요청을 한 번에 Native Model로 처리하는 것이 아니라, 작은 모델도 높은 신뢰도로 처리할 수 있는 트래픽부터 빠르게 처리하는 것입니다.
고비용 LLM Traffic을 한 번에 없애기보다, 처리 가능한 구간을 찾아 타노스가 손가락을 튕기듯(SNAP!) 손쉽게 줄여보자는 의미도 담겨 있죠. 큰 틀에서 SNAP은 다음 3가지 규칙을 하나의 Workflow로 묶습니다.
비교적 쉬운 요청은 작업별 소형 내재화 모델이 처리합니다.
어렵거나 애매한 요청은 기존 LLM으로 Fallback합니다.
Fallback의 기준은 내재화 모델의 Confidence와 Offline 검증 결과로 정합니다.
자, 그렇다면 작업별 소형 모델을 만들기 위해서 먼저 작업별로 학습데이터가 될 LLM 로그부터 수집해야겠죠? 그런데 여기서 한 가지 문제가 있었습니다.
방대한 LLM 로그들을 동일한 작업으로 어떻게 분류하죠?
LLM 호출 로그에는 굉장히 다양하고 이질적인 요청들이 섞여서 들어옵니다. LLM 으로 보내는 요청은 사람에게 말하듯 높은 자유도가 주어지기 때문에 같은 API Key, 같은 Endpoint를 사용해 호출하더라도 동일한 작업임을 전혀 보장할 수가 없죠. 그래서 먼저 요청을 작업 단위로 묶을 기준이 필요했습니다. 
다양한 Task들의 로그에서 나타나는 공통적인 특징은 Prompting 방식이었습니다. 많은 LLM Workflow는 System Prompt 앞부분에서 LLM에게 Role을 부여하고, 해결해야 할 문제와 함께 문제 해결 방식을 정의하는데요. 살펴본 로그에서는 Few-shot 예제가 바뀌어도 역할과 작업 정의는 대체로 유지됐습니다. SNAP은 이 특성을 이용해 system prompt 앞부분을 해시하고, 이를 작업을 구분하는 Fingerprint로 사용했습니다.
후보 발굴부터 모델 학습까지 자동화하기
작업 단위로 로그를 살펴보니 또 다른 문제가 있었습니다. 짧은 기간 안에 새로운 작업이 생기기도 했고, 얼마 지나지 않아 사라지기도 했어요. LLM으로 빠르게 개념 검증(PoC, Proof of Concept)을 진행한 뒤 작업을 변경하거나 프로젝트를 중단하는 경우가 있기 때문이었죠. 계속 바뀌는 작업을 사람이 하나씩 살펴보며 내재화 후보를 고르기에는 한계가 있었습니다.
그래서 SNAP은 내재화 후보 발굴부터 데이터셋 구축, 모델 학습까지의 과정을 자동화했습니다. 먼저 매일 호출 로그를 Task Fingerprint별로 묶어 호출량, 사용 중인 LLM 모델, 입력·출력 토큰 수와 추정 비용을 집계합니다. 최근 일정 기간의 추정 비용이 최소 기준을 넘는 작업을 비용순으로 정렬하고, 정해진 수만큼 후속 검증 대상으로 선정합니다. Table 1은 비용 기반 상위 30개 작업을 선정한 로그를 재구성한 예시입니다.
선정된 작업은 요청과 응답을 분석해 학습 가능성을 검증합니다. 응답이 정형화되어 있고 그 안에서 학습용 레이블을 안정적으로 추출할 수 있는지 확인합니다. 데이터셋을 구성하면서 레이블별 데이터가 충분한지, 학습과 평가에 사용할 데이터를 분리할 수 있는지도 검증합니다. 이 조건을 통과한 작업만 모델 학습으로 이어집니다.
이 과정은 Airflow의 일일 배치로 연결했습니다. 후보 선정과 데이터 구성 기준을 충족한 작업은 사내 학습 라이브러리를 통해 하루 안에 학습된 모델을 확보할 수 있습니다. 학습한 모델은 모델 레지스트리에 등록하며, 운영에 적용할 모델은 서빙 엔진이 불러와 요청을 처리합니다.
SNAP의 첫 내재화 모델 배포: 텍스트 기반 동일상품 판별
SNAP의 첫 적용 대상은 두 상품의 이름과 옵션 정보를 비교해 같은 판매 단위인지 판단하는 작업이었습니다. 브랜드, 모델명, 용량, 색상, 구성품 등의 차이를 읽고 동일 상품 여부를 분류하는 문제였죠. 입력과 출력의 범위가 명확하고 기존 LLM 응답도 충분히 쌓여 있어, 소형 분류 모델을 적용하기에 적합했습니다.
첫 적용 모델과 평가 데이터는 다음과 같이 구성했습니다.
Confidence로 채택 범위 정하기
모델은 판단 결과와 함께 자신 있는 정도를 나타내는 점수, Confidence를 반환합니다. 하지만 이 점수가 높다고 해서 실제로 얼마나 잘 맞히는지까지 알 수 있는 것은 아니에요. Confidence가 0.95라고 해서 정답률이 95%라는 뜻은 아니죠. 그래서 검증 데이터에서 Confidence 점수가 높은 결과만 골라 다음 두 가지를 확인했습니다.
골라낸 결과가 기존 LLM 판단과 일치하는 비율인 선택적 정확도(Selective Accuracy)
전체 검증 요청 중 채택된 비율인 Coverage
먼저 목표 일치율을 정하고, 결과를 채택할 최소 점수(Threshold)를 바꿔가며 비교했습니다. 목표를 만족하는 범위에서 가장 많은 요청을 처리할 수 있는 기준을 찾는 것입니다. 학습 중 저장한 모델들도 같은 방식으로 비교해 사용할 모델과 기준 점수를 함께 선택했습니다.
첫 배포의 목표 일치율은 99.9%로 정했습니다. 이 조건에서 검증 요청 100,648건 중 34,963건을 채택해 coverage 34.74%를 확보했습니다. 채택한 결과 중 기존 LLM 판단과 불일치한 건수는 34건으로, 실제 일치율은 99.9028%였습니다. 목표 일치율을 99%로 낮추면 coverage는 51.59%, 95%로 낮추면 72.35%까지 높아졌습니다. 작업에서 요구하는 품질에 따라 내재화할 수 있는 요청의 범위도 달라지는 것이죠.
Client는 언제 어떤 모델을 사용할지 어떻게 판단하죠?
클라이언트는 GenAI Gateway를 통해 먼저 내재화 모델을 호출합니다. 반환된 Confidence가 Threshold 이상이면 모델의 결과를 사용하고, 기준에 못 미치면 기존 LLM을 추가 호출합니다.
첫 배포 결과
결과는 어땠을까요? 첫 배포 후 약 6일간, 동일 상품 판별 작업에서 내재화 모델이 처리한 요청 비율은 일별 약 33~37%였습니다. 오프라인에서 확인한 Coverage 34.74%와 비슷한 비율의 요청을 실제 운영에서도 내재화 모델로 처리했네요. 모델이 자신 있게 처리할 수 있다고 판단한 구간이 실제 운영에서도 의미 있게 적용되고 있다는 뜻입니다.
이 기간에 줄어든 LLM Token 사용량은 다음과 같습니다.
입력 토큰: 약 76억 개
출력 토큰: 약 4,520만 개
서빙 성능도 부하 테스트에서 확인했습니다. 목표 요청량을 초당 10건부터 1,200건까지 높이며 클라이언트에서 응답 시간을 측정했습니다. 운영 피크인 초당 약 500건을 넘는 598건 처리 구간에서 p50(중앙값) 응답 시간은 7.24ms였습니다. 실제 처리량이 초당 1,203건인 구간에서도 p50은 9.02ms, p99(상위 1% 응답 시간)는 15.23ms였고, 모든 테스트 구간에서 실패하거나 드롭된 요청은 없었습니다.
전부 바꾸지 않아도 절감은 시작됩니다
전체 요청을 내재화 모델로 대체하려면, 그만큼 넓은 범위에서 요구 품질을 확보해야 합니다. 어려운 요청까지 처리하기 위해 개발과 학습을 반복하다 보면 투자 규모가 커질 수 있고, 목표 품질에 도달하지 못하면 운영 적용 자체가 미뤄질 수도 있습니다. 실제 유사한 분류 작업을 전체 내재화하기 위해 여러 버전의 테스트셋으로 반복하는 과정을 거쳤고, 개발에 1~2개월의 시간이 소요되었습니다.
SNAP은 이 부담을 줄이기 위해 후보 발굴과 학습을 자동화하고, 소형 모델이 검증 기준을 만족하는 요청부터 적용했습니다. 모든 요청을 해결하는 모델을 완성하기 전에, 운영에서 LLM 호출을 줄이기 시작한 것입니다. 작업이 빠르게 생겨나고 바뀌는 환경에서는 최종 전환율 뿐 아니라, 얼마만큼의 자원으로 얼마나 빨리 적용할 수 있는지도 중요합니다.
LLM을 더 자유롭게 사용할 수 있도록
오늘도 SNAP은 반복되는 LLM 호출을 집계하고, 내재화할 수 있는 작업을 찾아 새로운 소형 모델을 학습하고 있습니다. 앞으로는 각 도메인 팀과 실제 요청에서 드러나는 오류와 요구 품질을 함께 살피고, 데이터와 모델을 개선하며 적용 범위를 넓혀가려 합니다.
모델의 선택지도 넓혀가고 있습니다. JEV처럼 특정 판단 문제에 맞춘 Decision Engine 형태의 모델도 튜닝하며 SNAP에 활용할 수 있을지 실험하고 있습니다. 실제 운영 결과를 바탕으로 품질과 비용을 함께 고려한 내재화 기준을 다듬어 가겠습니다.
이 과정을 통해 각 도메인의 팀이 비용 걱정보다 풀고 싶은 문제에 더 집중할 수 있기를 바랍니다. LLM으로 아이디어를 빠르게 검증하고, 더 나은 의사결정과 비즈니스 임팩트로 연결할 수 있도록요. LLM을 활용한 시도는 더 자유롭게, 그 시도를 이어가는 비용 부담은 더 작게. 그것이 토스가 만들어가고 싶은 방향입니다.

손가락 튕기기로 LLM 비용 줄이기

댓글