아마존 사내 티켓 분류, 모델 바꿔 100만 건당 추산 비용 98% 감소
아마존 엔지니어 Carr Onstott와 Mehul Jaiswal은 사내 티켓을 20개 범주로 분류하는 모델을 Claude Sonnet 4.6에서 선택 결과만 내는 Strands Decider E4B로 바꿨다고 밝혔습니다. AWS 공개 단가를 적용한 모델 비용 계산은 100만 건당 약 2만2,200달러에서 약 500달러로 줄었으며, Lambda 비용은 포함하지 않았습니다.
아마존 엔지니어 Carr Onstott와 Mehul Jaiswal은 사내 티켓 분류 시스템에서 Claude Sonnet 4.6을 Strands Decider E4B로 교체했다고 밝혔습니다. Strands Agents 블로그에 실린 사례에서 두 사람은 이 전환으로 연간 토큰 비용이 수백만 달러 줄 것으로 예상했습니다. 비용 비교는 AWS 공개 단가와 티켓당 토큰 사용량, 모델 인스턴스의 가동률을 바탕으로 한 계산입니다.
분류 대상은 고객 문의와 용량 요청, 자동 경보, 보안 조사 결과 등 회사 전반에서 올라오는 티켓입니다. 기존 시스템은 이를 20개 범주 가운데 하나로 분류했습니다. Sonnet은 티켓마다 긴 지시문과 범주 설명을 읽고 추론한 뒤 JSON으로 답했습니다. 반면 결정 모델인 Strands Decider는 티켓을 상태로, 범주 목록을 선택지로 받아 각 선택지의 확률과 신뢰도 점수를 내놓습니다. 범주 선택이 필요한 작업에 맞춰 설명문을 만들지 않고 선택 결과를 출력하는 구조입니다.
엔지니어들은 처음에 Strands Decider 2B를 시험했습니다. 티켓 시험 자료에서 더 나은 결과를 낸 Gemma 4 E4B 구성으로 바꾸고, 라벨을 적용할 때 필요한 신뢰도 기준도 조정했습니다. 별도 티켓 자료에서도 E4B가 운영 중인 Sonnet보다 나은 결과를 냈다고 보고했습니다. 블로그에는 해당 평가의 점수와 표본 규모가 실리지 않았습니다.
입력 방식도 분류 작업에 맞게 줄였습니다. 운영 환경의 범주 설명만으로도 Decider의 4,096토큰 문맥 한도를 넘었기 때문에, 팀은 20개 범주를 각각 한두 문장짜리 기준으로 다시 써 하나의 선택 질문에 넣었습니다. 어느 범주에도 맞지 않는 티켓을 위한 ‘없음’ 선택지도 추가했습니다. Decider에 보낸 티켓 내용은 Sonnet에 보내던 것과 같지만, 긴 티켓에서는 문맥 한도에 맞춰 오래된 댓글부터 제외했습니다. 답변도 JSON 문서 대신 선택 결과 하나로 줄였습니다.
실제 처리 경로에서는 티켓 이벤트가 SQS 대기열에 쌓이고, 이를 받은 Lambda 함수가 티켓을 읽어 Strands Decider를 실행하는 SageMaker AI 엔드포인트를 호출합니다. AWS AppConfig는 메시지마다 사용할 모델을 정합니다. BEDROCK 설정에서는 Sonnet만 호출하고, DECIDER에서는 Strands Decider만 호출합니다. DUAL에서는 두 모델을 동시에 호출해 Sonnet의 결과를 티켓에 적용하면서 Decider의 결과와 비교합니다. 엔지니어들은 실제 트래픽에서 두 결과가 다른 티켓을 살펴봤으며, 설정을 바꾸면 45초 만에 기존 경로로 돌아갈 수 있었다고 설명했습니다.
비용 비교에는 AWS의 미국 동부(us-east-1) 온디맨드 공개 단가를 적용했습니다. Sonnet은 Bedrock 글로벌 엔드포인트의 입력 요금(100만 토큰당 3달러)과 출력 요금(100만 토큰당 15달러)에 티켓당 실제 토큰 사용량을 적용해 100만 건당 약 2만2,200달러로 계산했습니다. Strands Decider는 시간당 1.408달러인 SageMaker ml.g5.xlarge 인스턴스 한 대를 기준으로 삼았습니다. 엔드포인트는 트래픽에 따라 자동 확장합니다. 한 인스턴스에서 요청 하나에 약 640밀리초가 걸려 시간당 약 5,600건을 처리할 수 있으며, 이를 가득 가동하면 100만 건당 약 250달러입니다. 급증에 대비해 여유 용량을 두면 약 500달러라는 계산입니다. 이에 따르면 Decider의 모델 비용 계산치는 Sonnet의 약 44분의 1로, 약 98% 낮습니다. 이 비교에는 Lambda 비용이 포함되지 않았습니다.
티켓당 총 토큰은 Sonnet의 6,724개에서 E4B의 2,010개로 약 70% 줄었습니다. 입력 토큰은 6,554개에서 2,009개로, 출력 토큰은 JSON 대신 선택 결과 하나를 내면서 170개에서 1개로 감소했습니다. 엔지니어들은 Sonnet 사용을 끈 날 Lambda의 평균 실행 시간도 74% 줄었다고 별도로 전했습니다.
엔지니어들은 범주가 정해져 있고 처리량이 많으며, 매번 설명문을 만들 필요가 없는 분류 작업에 이 방식이 맞았다고 설명했습니다. 범주 목록이 매주 바뀌거나 라벨마다 설명을 생성해야 하는 작업, 유용한 티켓 맥락을 수천 토큰 안에 담기 어려운 작업에는 결정 모델이 적합하지 않을 수 있다고 밝혔습니다.