같은 상품인지 판별하는 데에도 긴 답변을 만드는 범용 AI가 매번 필요할까. 토스가 10월 27일 공개한 선택적 내재화 ‘SNAP’은 이 질문에서 출발한다. 검증 기준을 통과한 요청은 작업별 소형 모델이 맡고, 기준에 못 미치는 요청은 기존 대형 언어 모델로 보낸다. 한 모델이 전체 업무를 다 해결할 때까지 기다리는 대신, 검증할 수 있는 일부부터 운영에 넣는 방식이다.
모든 호출을 한 번에 바꾸지 않는 선택
같은 날 리퀴드AI가 소개한 LFM3도 작은 모델을 특정 작업에 맞추는 방향을 제시했다. 다만 토스가 LFM3를 사용했다는 사례는 아니다. 한쪽은 운영 중인 요청을 나눠 맡기는 기록이고, 다른 쪽은 입력 종류와 목적에 맞춰 모델을 고르고 학습하는 도구다. 두 자료를 비교할 지점은 작업의 범위를 먼저 정한다는 데 있다.
토스는 API 주소 대신 작업을 묶었다
토스의 로그에는 같은 API 키와 호출 주소를 쓰더라도 서로 다른 업무가 섞여 있었다. 팀은 시스템 프롬프트 앞부분에서 역할과 작업 정의가 비교적 유지된다는 점을 이용해 요청을 식별했다. 이 부분을 해시한 작업 지문으로 호출을 모으고, 호출량과 토큰·추정 비용을 집계해 검토할 후보를 골랐다.
비용이 큰 후보가 모두 학습으로 이어지는 것은 아니다. 응답이 정형화돼 학습용 레이블을 추출할 수 있는지, 충분한 자료가 있는지, 학습과 평가 데이터를 나눌 수 있는지를 확인한다. 첫 적용 대상은 상품명과 옵션에서 브랜드·모델·용량·색상·구성품을 비교해 같은 판매 단위인지 판단하는 일이었다. 자료 수집과 출력 범위가 비교적 명확한 작업을 먼저 택한 것이다.
99.9%가 가리키는 비교 대상
첫 배포에서는 검증 요청 100,648건 가운데 34,963건을 채택해 34.74%의 처리 범위를 확보했다. 채택한 결과 중 34건은 기존 LLM의 판단과 달랐다. 여기서 약 99.9%라는 수치는 독립적으로 확정한 상품 정답과의 정확도가 아니라 기존 LLM 레이블과의 일치율이다. 모델이 내놓는 확신 점수도 그 자체로 정답 확률을 뜻하지 않는다.
클라이언트는 소형 모델을 먼저 호출하고, 점수가 선택한 기준에 못 미치면 기존 LLM을 추가로 호출한다. 토스는 첫 배포 뒤 약 6일 동안 소형 모델이 맡은 요청 비중이 일별 약 33~37%였다고 보고했다. 전부 바꾸지 않아도 운영 가능한 구간이 있다는 관찰이지만, 이 범위를 다른 업무의 예상치로 옮길 수는 없다.
입력과 출력을 좁혀 만드는 작은 도구
리퀴드AI가 제시한 LFM3 계열은 공통 백본에서 텍스트, 시각, 음성, 여러 입력을 함께 다루는 모델로 갈라진다. 회사는 각 모델을 단일 GPU에서 작업에 맞게 미세 조정할 수 있다고 설명한다. 같은 작은 모델이라는 이름 아래에서도 어떤 종류의 입력을 받을지부터 선택이 달라지는 구성이다.
공개한 학습 예제에는 정돈되지 않은 문서에서 JSON을 추출하기, 영수증 사진을 JSON으로 읽기, 음성 스마트홈 명령을 함수 호출로 바꾸기가 있다. 검색된 문서로 답하거나 답변을 거절하도록 학습하는 예제도 제시했다. 범용 대화 능력을 그대로 기대하기보다 받을 자료와 내보낼 결과, 답하지 않을 조건을 정해 특화하는 접근을 구체적으로 보여준다.
처리 범위가 넓어져도 모든 호출 비용이 사라지지는 않는다
요청마다 소형 모델을 먼저 호출하고 일부만 기존 LLM으로 돌린다면, 평균 모델 호출 비용은 소형 모델 비용에 되돌린 비중의 LLM 비용을 더한 값이다. 채택 비중을 p라고 두면 C소형+(1-p)×CLLM으로 표현할 수 있다. 소형 모델을 쓰는 비중만큼 전체 비용이 그대로 줄어든다는 계산과는 다르다.
이 식은 호출 비용만 단순화한 비교이며 학습·서빙의 고정비와 검증, 지연 시간은 포함하지 않는다. 높은 기준으로 채택 범위를 줄이면 되돌리는 요청은 늘어날 수 있다. 토스가 공개한 일치율과 처리 범위를 함께 읽어야 하는 이유다. 리퀴드AI의 특화 모델 선택과도 같은 비용 실험을 수행한 결과로 합칠 수 없다.
| 지표 | 확인하는 질문 |
|---|---|
| 처리 범위 | 전체 요청 중 소형 모델 결과를 채택한 비중은 얼마인가 |
| 기존 LLM과의 일치율 | 채택한 결과가 비교 레이블과 얼마나 같은가 |
| 전체 운영 비용 | 첫 호출·되돌림·서빙·학습을 합치면 얼마인가 |
두 사례는 작은 모델을 쓰기 전에 맡길 작업과 검증 기준을 정했다. 통과한 요청의 범위와 입력별 특화, 실패하면 돌아갈 경로를 함께 설계해야 모델 크기의 선택을 실제 운영에 연결할 수 있다.
ARCH.B 의견
두 자료를 제작 도구의 설계로 읽으면 핵심 단위는 모델 이름보다 요청이다. 토스에서는 같은 상품을 판별하는 좁은 작업과 그 안의 채택 기준이 단위가 됐다. LFM3의 예제에서는 영수증 사진과 구조화된 결과처럼 입력·출력의 짝이 먼저 정해진다. 처리할 일이 명료해야 무엇을 학습하고 무엇과 비교할지도 드러난다.
실제 서비스에서 작은 모델이 맡는 부분을 정할 때에는 다음 단계도 함께 남는다. 토스의 사례처럼 기준을 넘지 못한 요청이 갈 곳이 있거나, 리퀴드AI의 예제처럼 근거가 없을 때 답하지 않도록 학습할 수 있다. 이를 비교하면 좋은 경량화는 더 작은 모델 하나를 고르는 결정에서 끝나지 않는다. 어떤 판단을 맡기고, 어떤 요청을 다른 처리로 돌릴지를 눈에 보이는 작업 경로로 만드는 일이다.
