AI 비용이 너무 비싸다: 토큰 경제학 입문

URL: https://www.youtube.com/watch?v=Ti-BmGU1_mQ 날짜: 2026-10-17 채널: aiDotEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 지출을 줄이는 출발점은 토큰 단가 흥정이 아니라 부서·팀·업무별 사용량과 결과를 측정하고, 작업 특성에 맞춰 모델·속도·용량·검증 절차를 설계하는 것이다.== 비용을 크게 늘려도 성과가 같은 비율로 늘지 않을 수 있으므로, 사용량을 성과로 착각하지 말고 업무 결과와 검증 병목까지 함께 살펴야 한다.

• 공용 API 키를 업무별로 분리하면 어디서 토큰이 쓰이는지, 어떤 호출이 속도와 품질을 필요로 하는지 드러난다.
• 장시간 컨텍스트를 쓰는 에이전트와 대량·단건 처리를 하는 자동화는 비용 구조가 다르므로 별도로 최적화해야 한다.
• 평가(Evals)로 더 작고 싼 모델을 탐색하고, 토큰 생성 속도·캐시·전용 GPU 용량을 워크로드에 맞추면 비용과 지연 시간을 조정할 수 있다.
• AI가 만든 코드·문서·슬라이드의 양이 늘어도 검토와 조직 프로세스가 따라오지 않으면 생산성은 정체되거나 검증 부담만 커진다.

발표자는 Featherless AI의 대규모 추론 운영 경험을 바탕으로 측정, 워크로드 크기와 모델 선택, 용량 조달, 프로세스 검증을 차례로 설명한다. 지출 규모가 작은 조직은 토큰 최적화보다 경제적 가치가 큰 활용 사례를 먼저 찾고, 규모가 커지면 데이터와 평가를 토대로 조직의 실제 결과를 개선하는 방식으로 토큰 경제학(tokenomics)을 관리해야 한다.

---

1. 발표자의 배경과 토큰 경제학의 범위

발표의 전제는 특정 업체의 가격표를 홍보하는 것이 아니라, 대규모 추론(inference)에서 공통으로 나타나는 비용 구조와 최적화 방법을 공유하는 데 있다.

1.1. Eugene Cheah와 Featherless AI

1. 발표자와 오픈소스 AI 활동

   1. 발표자 소개: Eugene Cheah는 Featherless AI의 CEO이자 창업자라고 소개한다. 오픈소스 Arabic AI 프로젝트팀에도 참여하며, Linux Foundation의 후원 아래 진행되는 첫 AI 모델 프로젝트의 일원이라고 말한다.
   2. 연구·개발 배경: 발표 초반에는 자신의 학술 경험을 간략히 언급하고, 온라인 별칭은 PicoCreator라고 밝힌다. 팀은 차세대 AI 아키텍처를 연구하고 있다고 덧붙인다.

2. Featherless AI의 미션과 모델 포트폴리오

   1. 접근성 목표: 언어, 방언, 국가에 상관없이 누구나 AI를 이용할 수 있게 하는 것이 회사의 목표다.
   2. 40,000개가 넘는 모델: 세계 최대 규모의 오픈 모델 플랫폼을 만든다고 설명한다. 대형 오픈소스 모델만이 아니라 특정 언어·분야·사용 사례에 맞춘 사전학습 모델도 포함한다.
   3. Sunflower 사례: 우간다의 언어를 위해 특별히 구축한 첫 언어 모델 Sunflower를 사례로 든다. 범용 모델 외에 틈새 언어와 특수한 요구에 맞는 모델의 다양성도 중요하다는 취지다.

1.2. 대규모 고객 사례와 적용 범위

1. 2조 토큰/일 운영 사례

   1. 처리 규모와 비용: 가장 큰 고객 가운데 한 곳은 하루 약 2조 토큰을 처리하며, 발표 중 제시한 단가는 백만 토큰당 약 0.03달러, 하루 비용은 약 6만 달러다. 2조 토큰에 이 단가를 적용하면 하루 6만 달러가 되며, 뒤에서 다시 언급하는 가격과도 일치한다.
   2. 하드웨어와 모델: 약 512대의 AMD MI25 GPU에서 프라이빗 400B MoE(Mixture of Experts) 모델을 운영한다고 설명한다.
   3. 품질과 동시성: 이 고객의 모델은 Opus 4.8급 성능을 목표로 하며, 많은 병렬 요청과 방대한 토큰량을 처리한다. 공개 클라우드 시장에서 이 규모와 가격을 동시에 얻기는 어렵고, 특수한 배치·운영 환경을 설계해야 한다.

2. 발표의 두 가지 전제

   1. 특정 공급자에 국한되지 않음: Featherless AI는 추론 서비스를 판매하지만, 발표 내용은 회사만의 비법이 아니라 데이터와 운영 경험을 토대로 한 것으로 모든 추론 제공자에 대체로 적용된다고 전제한다.
   2. 월 1만 달러는 임의의 기준: 조직의 AI 지출이 월 1만 달러 미만이라면 이 워크숍의 대규모 최적화가 우선순위가 아닐 수 있다. 그 기준은 절대적이지 않다.
   3. 작은 조직은 활용 사례부터 찾음: 월 지출이 적은 조직은 토큰 단가를 세밀하게 줄이기보다 회사 안에서 경제적 가치가 큰 AI 활용 사례를 찾아야 한다. 제대로 된 활용 사례 하나가 월 1만 달러보다 훨씬 큰 가치를 낼 수 있기 때문이다.

1.3. 워크숍의 네 단계

1. 측정(Measurement)

   1. 부서·팀·업무별 토큰 사용량과 비용을 파악해 이후 최적화의 기준선을 만든다.
   2. 발표자는 측정이 가장 큰 투자수익률(ROI)을 가져오는 첫 단계라고 강조한다.

2. 규모 산정(Sizing)과 모델 적합성

   1. 작업마다 필요한 품질, 컨텍스트, 응답 속도와 처리량을 정한다.
   2. 최고 성능 모델을 모든 일에 적용하지 않고 평가 결과에 맞는 더 작은 모델을 찾는다.

3. 용량 조달(Procurement)

   1. 워크로드의 기본 부하와 피크, 토큰/초 요구량을 파악한 뒤 GPU와 전용 인스턴스의 규모를 결정한다.
   2. 전용 용량, 공개 클라우드, 피크 트래픽의 혼합 운용을 검토한다.

4. 프로세스 검증(Process Validation)

   1. AI 사용량 자체가 아니라 실제 결과와 검토 부담을 평가한다.
   2. 조직의 테스트·신뢰·리뷰 절차가 AI가 만들어내는 속도와 양을 감당하는지 확인한다.

---

2. 측정과 워크로드 분류

비용 최적화는 조직의 토큰 사용을 관측할 수 있게 만드는 일에서 시작한다. 모든 요청을 한 바구니로 보면 어느 팀의 어떤 업무가 비용을 만들고 있는지 알 수 없다.

2.1. 키를 분리해 사용량을 보이게 만들기

1. 조직의 측정 수준을 확인함

   1. 전체 지출부터 질문함: 발표자는 청중에게 전체 토큰 지출을 아는지 손을 들어 보라고 한다. 대략 절반만 손을 든다.
   2. 부서·팀·업무 단위로 갈수록 가시성이 떨어짐: 부서별 사용량을 측정할 수 있는지 묻자 손을 든 사람 중 절반가량이 손을 내린다. 팀과 구체적 업무 수준으로 내려갈수록 아는 사람은 더 줄어든다.
   3. 공용 키의 문제: 처음 상담하는 고객의 최소 30~40%는 조직 구성원 모두가 하나의 API 키를 공유한다. 이런 상태에서는 “얼마나 썼는가”는 알아도 “어디서 왜 썼는가”를 설명하기 어렵다.

2. 키를 부서와 주된 업무별로 나눔

   1. 분리의 목적: 공급자가 어디든 API 키를 부서와 주요 업무별로 분리해야 토큰이 실제로 쓰이는 위치를 알 수 있다. 키 생성 자체는 어려운 일이 아니다.
   2. 업무의 우선순위를 반영함: 사용자와 직접 상호작용하는 팀에는 일정한 토큰/초를 제공할 이유가 있지만, 한밤중에 도는 백그라운드 에이전트에는 같은 속도를 지불할 필요가 없다.
   3. 과잉 요금제를 피함: 백그라운드 작업에 최고급(Ultra) 속도·요금제를 적용하는 것은 낭비다. 작업별 사용량이 보이면 전용 용량을 어떤 모델과 팀에 배정할지 더 합리적으로 계획할 수 있다.

3. 사용량과 생산성을 함께 살핌

   1. 어떤 팀이 가장 많은 토큰을 쓰는지 알아내는 데서 멈추지 않고, 그 팀이 실제로 더 나은 결과를 내는지 확인해야 한다.
   2. 발표자는 토큰 사용이 큰 팀이 반드시 생산성이 높은 것은 아니라는 점을 이후 프로세스 검증과 연결한다.

2.2. 서로 다른 두 종류의 AI 워크로드

1. 장시간·다단계 에이전트 워크로드

   1. 코딩 에이전트는 긴 컨텍스트를 유지하고 여러 단계를 반복하는 대표 사례다. 개발자가 밤새 에이전트를 돌리고 여러 차례 컨텍스트 압축(compaction)을 수행하기도 한다.
   2. 이런 워크로드는 컨텍스트와 입력 토큰을 많이 쓰며, 같은 프롬프트·상태를 여러 번 참조한다. 따라서 캐시와 입력량이 경제성에 큰 영향을 주고, 출력 토큰은 전체 사용량에서 작은 비중을 차지할 수 있다.
   3. 대화형 개발 도구의 요청 99%가 소스(source) 토큰이라는 관측을 제시한다. 한 번의 출력보다 반복되는 입력·캐시 토큰을 어떻게 과금하고 재사용하느냐가 중요하다는 설명이다.

2. 프로세스 자동화·대량 처리 워크로드

   1. 콜센터 분류, 이메일 라우팅, 회의록 작성처럼 작업 단위가 분리되고 컨텍스트가 비교적 짧은 자동화가 반대편에 있다. 예외는 많지만 전체적으로는 요청량이 큰 ‘볼륨 게임’이다.
   2. 통신사의 아동용 안전 전화 서비스는 문자 메시지를 욕설·성적 뉘앙스 등으로 검사한다. 새해 인사 “Happy New Year”가 최악의 사례라는 농담을 덧붙이며, 짧은 판정이지만 처리량이 매우 큰 유형임을 설명한다.
   3. 한 통신 고객은 분당 최대 1,000만 건의 메시지를 처리한다. 이 밖에도 문서 생성·추적, 승인 흐름, 문서 처리, OCR, 거래 위험 평가 등이 대규모 프로세스형 업무에 해당한다.

3. 워크로드 사이의 중간 지대

   1. 장시간 다단계 에이전트와 대량 단건 처리 사이에는 오래 실행되는 다중 패스 에이전트처럼 두 성격을 섞은 작업이 있다.
   2. 한 조직 안에서도 코딩·문서 처리·콜센터 등 업무마다 컨텍스트 크기와 지연 민감도가 다르므로, 한 가지 토큰 경제 모델을 모든 일에 적용하면 안 된다.

2.3. 측정 도구와 사용량 분석

1. 토큰 경제 추적 도구

   1. 발표자는 API 키를 분리하고 각 키의 지출을 추적하는 Tokenomics Tracking Tool을 공개한다고 말한다.
   2. 도구 정보 갱신을 위한 QR 코드와, 발표 슬라이드를 받거나 AI Engineering 영상 공개 시점을 확인할 수 있는 양식을 안내한다.

2. 측정의 우선순위

   1. 토큰 지출과 결과를 측정하지 않았다면 나머지 최적화 조언보다 측정부터 해야 한다.
   2. 측정이 가장 큰 ROI를 제공하며, 사용량·트래픽 패턴을 알아야 모델 교체나 용량 조달이 근거 있는 결정이 된다.

---

3. 모델·업무 규모를 맞추는 법

모든 문제에 최고급 모델을 쓰는 것은 반짝이는 새 망치로 모든 것을 두드리는 것과 같다. 모델 성능과 가격은 빠르게 변하므로 업무에 맞는 후보를 계속 평가해야 한다.

3.1. 업무에 맞는 모델을 선택함

1. AI를 모든 일에 적용하는 함정

   1. 조직은 AI라는 새 도구가 생기면 특히 혁신 조직에서 사소한 일까지 AI로 처리하려는 경향이 있다.
   2. 실제로는 AI를 붙여도 가치가 없거나 비용만 드는 업무가 있으므로, 모델을 선택하기 전에 어떤 문제를 해결할지 정해야 한다.

2. 오픈 모델과 클로즈드 모델의 격차가 좁아짐

   1. 전년도에는 최고 클로즈드 모델이 최고 오픈 모델보다 상당히 앞섰지만, 발표자가 말하는 올해에는 격차가 줄어 일부 오픈 모델이 동급이거나 앞서는 사례가 나타난다.
   2. 업데이트 전 Opus 5.5와 비교할 때 Kimi K3가 일부 사용자 인터페이스(UI) 디자인 테스트에서 더 나은 결과를 냈다고 말한다. 이는 공개 벤치마크 기반의 사례다.
   3. 좁은 도메인 고객 테스트에서는 오픈 모델이 특화 벤치마크에서 이기기 시작했다. 따라서 업무를 정확히 알고 배치하면 기존 모델을 직접 대체하면서 비용을 때로 10분의 1까지 낮출 수 있다.

3. 특정 업무에서 강한 작은 모델

   1. Step 1.5는 금융 벤치마크와 금융 사용 사례에서 Opus에 가까운 품질을 10분의 1 크기로 냈다고 소개한다. 코딩 최고 모델이라는 뜻은 아니지만 금융 업무에서는 강하고 유능하다는 점이 핵심이다.
   2. DeepSeek V4 Flash는 점수만으로 인기를 설명하기 어렵지만 프롬프트 관리가 쉬워 여러 기업이 폭넓은 작업에 쓰는 모델이라고 언급한다.
   3. 모델 품질 기준은 분야별로 계속 달라진다. 발표자는 오픈 모델이 수개월마다 나오고 클로즈드 모델도 빠르게 바뀌므로, 제시한 일반 규칙을 매달 새로 확인해야 한다고 말한다.

4. 분류기 중심의 새 모델 유형

   1. 발표자는 최근 등장한 “classifier”, “one-shot classifier”, 또는 JAF라고 부르는 모델 계열을 소개한다. 오픈소스 프로젝트 Simple JAF도 개발되고 있다고 말한다.
   2. 이 모델은 대화 유지가 아니라 판정과 작업 분류에 집중한다. 기존 모델보다 기술적으로 약 10배 저렴하고 빠른 경우가 장점이다.
   3. 대화형 모델을 과도하게 쓰던 분류 업무를 전용 분류기로 옮기면 프로세스형 조직의 토큰 비용을 크게 줄일 수 있다.

3.2. 평가(Evals)로 작은 모델을 찾음

1. “작은 모델이 충분히 좋은가?”를 실험으로 답함

   1. 발표자는 이 질문에 추상적으로 답하려 하지 말고 테스트 케이스, 평가, 예제를 마련하라고 권한다.
   2. 그 평가 세트를 사용해 검색·비교 과정을 반복하고 대부분의 테스트를 통과하는 가장 저렴한 모델을 선택한 뒤, 추가 개선이나 파인튜닝을 검토한다.
   3. Hugging Face에서 모델 10개를 내려받아 직접 시도하는 일도 어렵지 않다. 40,000개가 넘는 모델을 보유한 업체의 도움을 받을 수도 있지만, 평가와 탐색은 조직이 직접 시작할 수 있다.

2. 통신 고객 비용 절감 사례

   1. 대형 통신사의 고객 지원 사용 사례에서 기존 클로즈드 모델의 추론비를 월 25만 달러에서 7,600달러로 줄였다고 소개한다.
   2. 시작은 가장 좋은 모델을 기준으로 삼고, 대체 후보를 찾고, 실제로 배치한 뒤 무엇을 배울 수 있는지 확인하는 단계적 탐색이었다.
   3. 비용 절감은 단순히 저렴한 모델 이름을 선택한 결과가 아니라, 업무별 평가와 적용 절차를 밟아 가능해졌다.

3. 분류 비중을 다시 살핌

   1. 고객 지원의 최종 응답이 문장이라도, 많은 팀은 모델에 미리 정해 둔 텍스트를 컨텍스트로 넣어 사실상 분류·선택 작업을 시킨다.
   2. 그런 요청을 대화형 모델 대신 분류기로 처리할 수 있다. 발표자는 자사 오픈 프로젝트 Simple JAF를 언급하며, AI 트래픽 중 분류 비중이 예상보다 높을 수 있다고 강조한다.

3.3. 도메인 모델 파인튜닝과 증류

1. 특수 업무에서는 자체 모델이 경제적일 수 있음

   1. 코딩 분야는 Devin 같은 전문 서비스와 최상급 모델 경쟁을 따라가기 어려워 개별 조직이 모델을 직접 훈련하는 부담이 크다.
   2. 반면 통신·금융·기업 내부 언어처럼 도메인이 좁고 처리량이 큰 작업은 해당 업무에 맞춘 더 작은 모델을 훈련할 가치가 있다.
   3. AT&T는 통신 도메인 모델을 오픈소스 계열에서 27B, 나아가 7B까지 다듬어 공개했다. Featherless AI는 출시 파트너였고, AT&T가 실제 내부에서 쓰는 모델이라고 소개한다.

2. 특수 도메인의 구체적 사례

   1. Shopify는 자사 온라인 상점 구축에 쓰는 고유 프로그래밍 언어를 기존 모델이 잘 다루지 못해 맞춤 모델을 훈련했다.
   2. AT&T는 기지국 배치처럼 통신 분야에 매우 특화된 문제도 가지고 있다. 범용 코딩 점수보다 특정 업무에서 잘 작동하는지가 훈련 여부를 결정한다.
   3. 대규모 콜센터도 요청량이 크기 때문에 27B 모델과 7B 모델을 업무 층위에 따라 운용하는 것이 합리적일 수 있다.

3. 데이터를 만드는 실용적 경로

   1. 직접 데이터를 작성하거나 수집하는 방식은 어렵고, 많은 조직이 이를 꺼린다.
   2. 다른 방법은 비싼 최상급 모델을 작은 규모로 먼저 배치해 사례를 만들고 데이터셋을 생성하는 것이다. 다만 일부 연구실·사업자의 서비스 약관이 이를 제한할 수 있으므로 법무 검토가 필요하다.
   3. Google Gemini의 고급 모델은 이런 목적의 데이터셋 생성을 위한 별도 API 서비스를 제공한다고 예를 든다. 강한 모델로 만든 데이터를 사용해 7B급 모델 등 훨씬 작은 모델로 축소·증류할 수 있다.
   4. 오픈소스 모델도 시작과 증류에 적합하다. 데이터를 모은 뒤 추가 학습을 하고 크기가 다른 모델들을 비교해 적절한 지점을 찾는다.

4. 작은 모델로 트래픽을 단계별 라우팅함

   1. 일반 문의는 작은 모델로 보내고, 분류기 트리거가 특정 조건을 감지하면 더 큰 모델로 넘기는 구조를 만들 수 있다.
   2. 어떤 요청을 어느 크기의 모델로 보낼지는 실제 통화·업무 데이터와 평가에 따라 달라진다. 발표자는 특정 콜센터 문의에 몇 B가 맞는지는 공개하기 어렵다고 선을 긋는다.
   3. 완전히 맞춤 모델로 옮긴 뒤에도 일부 트래픽을 최상급 모델로 섀도 트래픽(shadow traffic) 처리하면, 최신 오픈 모델의 결과를 계속 수집해 데이터셋과 기준을 갱신할 수 있다.

5. 모델 발전 속도와 단위 경제성

   1. 발표자는 최고급 MacBook Pro에서 실행할 수 있는 최선의 모델을 살펴본다고 말한다. 현재는 31B·32B·27B MoE 모델이 작년의 GPT-4보다 상당히 나은 성능을 보인다는 것이 대략적인 비교다.
   2. 세부 순위에는 이견이 있을 수 있지만, 노트북에서도 작년 최고 모델보다 나은 모델을 돌릴 수 있다는 변화가 중요하다.
   3. 그 모델을 특정 업무에 맞춰 다시 훈련하면, 노트북에서 돌릴 수 있는 모델을 GPU 서버에서 대규모로 더 효율적으로 운영할 수 있다.

---

4. 에이전트 비용과 조직 내 사용 방식

에이전트 비용은 입력과 캐시를 반복 소비하는 구조, 모델 선택, 속도 설정, 사용자의 습관에 따라 달라진다. 좋은 모델을 정하는 일만으로는 실제 비용 절감이 일어나지 않는다.

4.1. 에이전트의 입력·캐시 경제성

1. 입력과 캐시가 비용의 중심임

   1. 장시간 에이전트는 반복적인 다단계 실행을 하므로 입력 컨텍스트와 캐시가 중요한 비용 요소가 된다.
   2. 발표자의 관측에서 에이전트 사용 요청은 소스 입력 토큰 비중이 약 99%다. 출력이 단가 표에서 비싸 보이더라도 반복해서 읽히는 입력과 캐시의 비중이 크면 실제 비용 판단이 달라진다.
   3. 토큰 가격표만 보고 결론을 내리지 말고, 실제 배포 구성에서 어떤 토큰이 얼마나 반복되는지를 측정해야 한다.

2. 계획·실행·검증 모델을 나눔

   1. 개발 에이전트 배포의 흔한 패턴은 계획에 가장 똑똑한 모델을 쓰고, 토큰 사용량이 큰 구현에는 빠르고 싼 모델을 쓰며, 검증은 다시 강한 모델에 맡기는 것이다.
   2. 구현 단계는 파일 수정, 테스트, 결과 확인, 재수정이 반복되어 토큰을 많이 소비한다. 이 구간에는 Gemini 1.5 Flash처럼 더 싼 모델도 계획을 담당한 최고 모델과 비슷한 품질로 실행할 수 있는 경우가 있다.
   3. 실제로 계획·검증은 강한 모델이 맡고 실행은 Gemini 1.5 Flash나 GPT-4o mini가 맡는 조직 사례를 보았다고 한다.

3. 모델 분리의 마찰을 줄임

   1. 사람들은 회사 비용만 아끼려고 모델을 바꾸지 않는다. 모델 전환이 번거롭거나 결과가 늦으면 비싼 모델을 계속 쓰기 쉽다.
   2. MemGPT처럼 에이전트 프레임워크가 약한 모델을 기본으로 쓰다가 더 높은 전문성이 필요할 때 강한 모델로 자동 전환하면 사용자의 선택 부담을 줄일 수 있다.
   3. 기본 원칙은 더 똑똑한 모델을 기준선으로 두되, 빠르고 저렴한 모델이 더 빨리 결과를 내도록 설계하는 것이다. 사용자는 비용 절감보다 속도 때문에 싼 모델을 선택할 가능성이 크다.
   4. 두 모델의 토큰/초가 같고 예산도 남아 있으면 사용자가 모델을 바꾸지 않는 사례가 있었다. 반대로 예산을 지나치게 낮춰 강한 모델이 하루 만에 한도를 다 쓰게 하면 모두가 싼 모델로 옮겨가지만, 강한 모델이 사실상 쓸모없게 된다.
   5. 가장 좋은 절충은 사용자가 자연스럽게 선택하도록 빠른 모델을 제공하는 것이다. 강한 모델을 없애거나 사람에게 억지로 전환을 요구하기보다, 속도와 업무 품질을 설계한다.

4.2. 사용자·백그라운드 업무별 속도 설정

1. CI/CD와 백그라운드 호출을 분리함

   1. CI/CD 파이프라인은 사람이 즉시 기다리는 호출이 아니라 백그라운드 업무의 대표 사례다.
   2. 사람 사용자에게는 높은 토큰 생성 속도를 주고 CI/CD에는 훨씬 느린 속도를 설정하면 비용을 크게 줄일 수 있다.
   3. 이 설정은 팀이나 개인 키 수준에서 업무 우선순위에 따라 조정할 수 있다.

2. 비개발 부서에 기능 기반 모델 이름을 제공함

   1. CEO가 “모두 AI를 써라”, “모두 두 번째 뇌를 만들어라”라고 지시하는 조직이 늘고 있고, UAE처럼 일부 지역에서는 법적 요구가 되었다는 사례도 든다.
   2. 개발자는 DeepSeek Flash와 GRM 5.3의 차이를 알 수 있지만 재무·지원 부서는 모델 이름과 성능 차이를 이해하지 못할 수 있다. 이들은 기본 모델을 선택한 뒤 계속 쓰는 경향이 있다.
   3. 모델 이름 대신 “빠른 모델”, “똑똑한 모델”, “재무 에이전트”, “스프레드시트 에이전트”처럼 기능에 따라 보여주면 사용자가 선택하기 쉽고 관리자가 교체하기도 쉽다.
   4. 전문 업무에 맞게 추가 학습한 에이전트라는 점을 기능으로 표현할 수도 있다.

3. 모델 교체와 실험 권한을 보존함

   1. 조직이 노출되는 API 이름을 모델의 기능으로 추상화하면 트래픽을 나누고 교체 모델을 시험할 수 있다.
   2. 이를 통해 매번 사용자에게 “새 모델을 써보라”고 알리지 않고도 비교 실험을 할 수 있다. 잘못 교체하면 사용자가 불만을 제기할 수 있으므로 품질 검증은 필요하다.
   3. “이전 버전” 같은 변형도 조직에 잦은 변경 공지를 부담시키지 않으면서 운영자가 통제하는 방식이다.
   4. 설정을 바꾸지 않아 Llama 2를 계속 사용하는 팀을 실제로 보았다고 한다. 오래된 기본값이 방치되지 않도록 모델 설정과 교체 주기를 관리해야 한다.

4.3. 도구 종속성과 에이전트 프레임워크

1. Claude Code의 생태계 종속 문제

   1. 청중은 Claude Code와 내부 통합 도구가 토큰 오버헤드를 만들고, 모델을 Claude 생태계에 묶어 두는 문제를 질문한다.
   2. 발표자는 Claude Code가 완전한 도구 종속(lock-in)의 사례가 될 수 있다고 답한다. 첫 단계는 경우에 따라 도구 자체를 바꾸도록 설득하는 일이다.
   3. Devin이나 특정 도구만 쓰는 조직처럼 한 시스템에 완전히 잠긴 팀도 있고, 자체 에이전트 시스템을 직접 운영하는 팀도 있다. 발표자는 “왜 처음부터 에이전트 시스템을 직접 만드느냐”고 반문하며 단순하고 유연한 도구를 검토하라고 한다.

2. Pi를 이용한 단계적 전환

   1. Pi는 가볍고 바꾸기 쉬운 코딩 에이전트 시스템의 예로 든다. 같은 모델을 사용해도 단순성과 효율성 때문에 토큰 비용이 낮다는 사례가 공유되고 있다.
   2. 팀은 먼저 에이전트에게 수정 작업을 시키며 실험을 시작할 수 있다. 토큰/초 100 정도를 내는 빠른 모델을 제공하면 새 도구를 사용해 볼 유인이 생긴다.
   3. 일부 팀은 Claude Code를 계획자(planner)로 유지하면서 Pi 에이전트와 더 싼 모델을 구현자(implementer)로 부른다. 계획과 실행을 분리하는 방식이 기존 도구에서 새 시스템으로 넘어가는 발판이 된다.

3. MCP의 한계와 간단한 실행 경로

   1. 더 작은 에이전트를 Claude 안에서 MCP로 제공하는 아이디어도 언급된다.
   2. 다만 MCP 에이전트는 구성을 제대로 하지 않으면 로컬 파일 시스템에 접근하지 못해 복잡해질 수 있다.
   3. 발표자는 Python을 설치해 python this.py와 같은 배치 파일을 실행하는 더 단순한 연동이 보통 실용적이라고 답한다.

---

5. GPU 용량 조달과 토큰 생성 속도

성능과 단가는 선형으로 함께 움직이지 않는다. 필요한 토큰/초를 낮추거나 요청을 병렬화하면 같은 하드웨어에서 훨씬 많은 작업을 처리할 수 있다.

5.1. 속도와 비용의 비선형 관계

1. 토큰/초 요구량은 비용을 좌우함

   1. 고객은 모델 품질뿐 아니라 한 요청당 필요한 토큰/초도 먼저 정해야 한다. 그 뒤에 GPU 수와 배포 규모를 산정할 수 있다.
   2. 비용을 고려하지 않고 최고 모델을 최고 하드웨어의 GPU 8개에 배치해 배치 크기(batch size)를 1로 두면, 단일 요청에서 초당 100~200 토큰을 얻을 수 있다.
   3. 초당 수천 토큰이 필요하면 Cerebras 같은 사업자가 제공하는 매우 빠른 시스템이 후보가 되지만 비용은 더 높다. 그런 속도가 꼭 필요한 사용 사례도 있으나 모든 조직에 필요한 것은 아니다.

2. 속도를 두 배로 올리면 비용은 세 배가 될 수 있음

   1. 발표자의 경험칙은 속도를 두 배로 높일 때 비용이 세 배가 되며, 속도를 높일수록 비용 증가가 점진적으로 커진다는 것이다.
   2. “속도가 빨라지면 가격이 절반쯤 될 것”이라고 기대하는 것은 현실과 거리가 멀다. 목표 속도 프로필 자체가 단가를 결정하는 중요한 절충점이다.

3. 병렬 처리로 총 처리량을 높임

   1. 같은 서버의 H100 한 장에서 GRM 5.3 단일 쿼리는 약 112토큰/초를 처리하는 사례를 제시한다.
   2. 쿼리 16개를 병렬 실행하면 각 요청의 속도는 대략 절반으로 줄지만 전체 처리량은 약 10배가 된다.
   3. 목표 속도를 낮추고 병렬성을 높이는 것만으로도 토큰당 비용이 약 9~10배 낮아질 수 있다.

5.2. 업무에 필요한 응답 속도와 용량

1. 속도 구간을 업무별로 선택함

   1. 일반적인 고객은 초당 20~30토큰에서 시작하고, 더 빠른 사용 사례는 약 60토큰/초까지 고려한다. 발표자는 60을 매우 높은 속도에 가까운 구간으로 설명한다.
   2. 120토큰/초 요구는 드물지만, 사용자가 결과를 직접 기다리는 일부 작업에서 필요할 수 있다.
   3. 에이전트가 여러 단계를 거치는지에 따라 적절한 속도는 달라진다. 작업 체인이 길면 각 단계에서 기다리는 시간이 누적될 수 있다.

2. 사람이 기다리는 작업에만 속도 프리미엄을 지불함

   1. 개발자나 고객 앞에서 실시간으로 응답하는 작업은 속도에 비용을 지불할 이유가 있다.
   2. 설정을 조금만 낮춰도 고객 영향은 거의 없이 비용을 절반으로 줄인 사례를 보았다고 한다.
   3. 백그라운드 작업을 초당 120토큰으로 운영하는 것은 낭비다. 사람이 기다리지 않는 작업은 더 낮은 속도와 더 높은 배치 효율을 우선할 수 있다.

5.3. 트래픽 모양에 따른 용량 구성

1. 기본 부하와 피크를 구분함

   1. 토큰 사용량을 측정하면 지속적으로 발생하는 기본 부하(base load)와 순간적인 피크를 구분할 수 있다. 백그라운드 에이전트가 있으면 누군가 항상 실행하므로 기본 부하가 생긴다.
   2. 전용 인스턴스를 쓰는 금융업처럼 운용 조건상 유연성이 낮은 경우도 있다. 가능하다면 전용 용량에 클라우드 피크 처리를 더하는 하이브리드 구성이 유연성을 제공한다.
   3. 기본 부하를 충분히 채울 수 있다면 전용 인스턴스가 현재 가장 큰 절감 효과를 낼 수 있다. 다만 트래픽 모양에 따라 복잡한 검증이 필요하다.

2. 공급자와 함께 실제 트래픽으로 검증함

   1. 추론 사업자는 고객에게 트래픽 데이터를 알고 있는지, 제공할 수 있는지 물은 뒤 제안한 구성을 시험하게 한다.
   2. 고객은 새 옵션으로 전환해 실제 절감 효과를 비교하고, 측정값에 따라 용량을 수정한다.
   3. 피크가 매우 큰 경우에는 전용 용량을 제한하고 초과분을 공개 클라우드로 보내는 편이 낫다. 트래픽 특성에 따라 확장 전략을 달리해야 한다.

3. 규모가 커질수록 기본 부하도 중요함

   1. 한 달에 한 번만 극단적 피크가 있고 나머지 시간에는 거의 쓰지 않는 사례는 드물다고 발표자는 말한다.
   2. 대규모 워크로드도 보통 기본 부하가 있으며, 핵심 질문은 그 부하가 어느 정도인지다.
   3. 하루 2조 토큰을 처리하는 고객 사례는 Opus 4.8급 모델을 백만 토큰당 0.03달러 미만에 운영한다. 공개 클라우드에서 찾기 어려운 가격은 측정, 전용 배치, 규모에 최적화한 운영의 결과라는 설명이다.

---

6. 프로세스 검증과 조직의 생산성

토큰을 더 쓰는 일은 성과를 내는 최종 제품이 아니다. AI를 이용해 산출물을 늘려도 신뢰·테스트·검토·승인 절차가 따라오지 못하면 병목은 다른 곳으로 이동한다.

6.1. AI 사용량과 업무 성과를 구분함

1. 지출 10~100배 증가가 성과 증가를 보장하지 않음

   1. 여러 조직이 토큰 지출을 10~100배 늘렸지만 성과는 그만큼 늘지 않았다고 보고한다.
   2. AI가 성과를 개선한 폭이 6~7%에 불과하다는 보고도 있다. 기대했던 생산성 증가와 실제 성과 사이에 큰 차이가 생길 수 있다.
   3. AI가 쓸모없다는 뜻은 아니다. AI를 모든 일에 적용하는 ‘큰 망치’식 접근으로 인해 효과가 제한되는 경우가 있다는 설명이다.

2. 조직 프로세스가 기술 변화보다 느릴 수 있음

   1. 사람이 AI로 더 빨리 만들기 시작하면 개발 환경의 CI/CD와 CPU가 병목이 될 수 있다.
   2. 회사의 운영·검증 프로세스도 병목이다. “이 결과를 믿어도 되는가, 어떻게 확인하는가”라는 질문에 답이 없으면 신뢰 부족이 전체 속도를 낮춘다.
   3. 에이전트가 잘못 설계되어 신뢰할 수 없는 경우도 있다. 반대로 에이전트가 완벽하게 일했는데 테스트·검증 체계가 부실해 사람에게 신뢰를 얻지 못하는 경우도 있다.
   4. 따라서 기술에 맞춰 팀의 검토·실행 방식을 함께 조정해야 한다.

6.2. 코드와 산출물의 ‘슬롭 수류탄’ 문제

1. 큰 변경과 코드 리뷰 병목

   1. 에이전트가 버그를 자동으로 고쳐 QA가 보고한 문제를 개발자 개입 없이 해결하면 좋은 성과다.
   2. 그러나 팀이 곧바로 변경 범위를 키워 코드베이스의 4분의 1이나 절반을 한 번에 다시 쓰게 하면 리뷰어가 병목이 된다. 계획과 테스트가 충분한 대규모 변경은 가능하지만, 그렇지 않은 변경은 검토하기 어렵다.
   3. 대량 코드 생성 과정에서 구현되지 않은 문제나 빠진 요구사항이 검토자의 시야에서 빠질 수 있다.
   4. 리뷰어는 변경량이 너무 많으면 에이전트에게 핵심 차이를 요약하거나 재작업하게 한다. 결과적으로 첫 에이전트의 작업을 사실상 거부하고 사람이 다시 통제하며 에이전트와 함께 수정한다.
   5. 품질과 핵심 코드베이스 통제를 원하는 리뷰어의 요구는 타당하지만, 프로세스가 준비되지 않으면 생성량이 늘어도 병합 속도는 빨라지지 않는다.

2. 테스트와 모듈화로 부담을 낮춤

   1. 테스트 모범 사례를 도입해 자동으로 오류를 걸러내면 리뷰어가 모든 문제를 직접 확인할 필요가 줄어든다.
   2. 병합을 작은 단위로 나누고 변경을 모듈화하면 리뷰가 쉬워진다.
   3. 이 조치는 모델 개선이 아니라 사람의 개발 프로세스 개선이다. AI가 코드를 많이 만들게 하는 것만으로 해결되지 않는다.

3. 슬라이드·보고서에도 같은 문제가 생김

   1. 발표 자료는 디자인 관점에서 AI로 만들었지만 한 번의 프롬프트로 끝내지 않았다. 각 페이지를 최소 30차례 수정했다.
   2. 일부 구성원이 프레젠테이션 전체를 한 번에 생성해 회의를 열면, 다른 사람이 내용의 모순과 데이터 왜곡을 걸러내야 한다. 서로 다른 두 수치가 왜 맞지 않는지 확인하는 부담이 생긴다.
   3. 코드·슬라이드·보고서 모두에서 생성자는 검증을 다른 사람에게 떠넘길 수 있다. 이를 발표자는 ‘슬롭 수류탄(slop grenade)’이라 부른다.

6.3. 책임과 결과 중심의 평가

1. 생성물에 대한 책임을 제작자가 짐

   1. 슬롭 수류탄을 줄이려면 공유·배포한 결과에 대해 생성자가 책임지게 해야 한다.
   2. 발표자는 AI로 만든 문구와 디자인을 포함해 이 슬라이드의 책임이 자신에게 있다고 말한다. 문제가 생겨도 AI 에이전트 탓으로 돌릴 수 없다.
   3. 같은 원칙을 코드와 다른 생성물에도 적용해야 한다.

2. 사용량 대신 결과를 측정함

   1. 발표자는 토큰 비용을 실제 결과로 나눈 값을 간단한 경험칙으로 제시한다. 이를 통해 더 작고 효율적인 모델, 더 빠른 모델, 더 강력한 모델 중 무엇이 가치 있는지 판단할 수 있다.
   2. 결과 측정은 어렵고 불완전하지만 관찰하고 평가할 수 있는 대상이다. 토큰 사용만으로 생산성을 판단하지 말아야 한다.
   3. AI를 보충제나 스테로이드에 비유한다. 같은 도구를 써도 어떤 팀은 생산성이 오르고 어떤 팀은 그렇지 않으며, AI는 기존 역량에 더해지는 요소이지 모든 것을 자동으로 바꾸는 마법이 아니다.
   4. 건설 현장에서 노동자의 근육을 늘린다고 가정하는 윤리적으로 부적절한 비유를 예시로 들며, 증강 효과가 모든 팀에서 동일하지 않다는 점을 설명한다.

3. 팀별 비교를 통해 효과를 찾음

   1. 부서·팀별 토큰 지출을 알아야 사용량 대비 성과가 높은 팀과 낮은 팀을 비교할 수 있다.
   2. 이를 통해 어떤 업무와 도구가 실제로 작동하는지, 어디에서 비효율이 발생하는지 발견할 수 있다.
   3. 측정 결과는 완벽한 생산성 지표가 아니지만 개선을 시작할 기준이 된다.

6.4. 도메인 지식으로 큰 활용 사례를 찾음

1. AI 전문가는 조직의 문제를 전부 알 수 없음

   1. 업무 도메인을 가장 잘 아는 사람은 조직 내부의 구성원이다. AI 전문가가 모든 곳에서 가치 있는 자동화 사례를 대신 찾아줄 수는 없다.
   2. 조직 내부의 지식으로 AI 자동화가 수백만 달러를 절감하거나 생산성을 크게 높이는 업무를 찾아야 한다.

2. Walmart의 발판 사례

   1. 발표자는 Walmart였던 것으로 기억한다며, 트럭마다 발판을 설치한 사례를 든다.
   2. 단순한 발판 하나가 무거운 짐을 다룰 때 생기는 허리 부상을 줄여 수백만 달러의 비용을 아꼈다고 설명한다.
   3. 가장 복잡하거나 최고 성능인 AI 모델이 아니라도, 업무 현장의 정확한 문제를 해결하면 큰 효과를 낼 수 있다는 비유다.

---

7. Q&A: 미세조정·도구·캐시·라우팅

질의응답에서는 모델을 언제 미세조정할지, 실패한 학습 데이터를 어떻게 다룰지, 특정 코딩 도구에서 벗어날 수 있는지, 캐시와 자동 라우팅을 어떻게 설계할지가 다뤄진다.

7.1. 파인튜닝 방식과 학습 데이터

1. SFT와 강화학습 선택

   1. 청중은 모델 미세조정이 SFT(Supervised Fine-Tuning)인지, 데이터에 따라 다른 방법을 쓰는지 묻는다.
   2. 발표자는 일반적으로 SFT를 많이 제공하지만 사전학습 서비스도 있다고 답한다.
   3. 강화학습(RL)은 코딩처럼 반복 환경에서 데이터를 만들기 쉬운 분야에서 인기가 높다. 반면 뉴욕 금융기관의 금융 업무처럼 현실적인 RL 환경을 만들기 어려운 조직은 SFT를 더 많이 사용한다.
   4. Adaptation AI 같은 회사는 SFT나 머신러닝 학습에 맞춰 데이터셋 정제를 자동화하기 시작했다고 언급한다.

2. 학습보다 평가 결과가 먼저임

   1. 발표자는 핵심이 특정 미세조정 기법의 이름보다 평가(Evals)라고 강조한다.
   2. Simple JAF는 기존 오픈 모델에 JAF API를 씌우는 오픈소스 프로젝트다. 공개 후 Qwen 27B가 해당 작업을 잘한다는 사실을 여러 팀이 발견해 Qwen 27B를 훈련하기 시작했다.
   3. 발표자의 회사는 모델 위에 API를 만들고 프롬프트 설정을 바꾸는 접근도 시험했다. Hugging Face가 10,000개가 넘는 질문으로 대규모 벤치마크를 실행했을 때, 맞춤 프롬프트를 적용한 Qwen 27B가 다수의 사전훈련 27B 모델보다 좋은 결과를 냈다고 한다.
   4. 발표자는 그 모델이 이후 Cloudflare의 새 사전훈련 모델에 뒤처졌을 수 있다고 인정한다. 핵심은 자기 모델의 우월성을 주장하는 것이 아니라, 프롬프트 조정만으로도 성능을 개선할 수 있으며 평가 점수와 결과를 확인해야 한다는 것이다.

3. 골든 트레이스와 실패 사례의 활용

   1. 청중은 최상급 모델이 80% 정확할 때 오류가 있는 궤적까지 학습시키면 작은 모델도 20% 오류를 물려받는지, 정답이 검증된 ‘골든’ 트레이스만 남겨야 하는지 묻는다.
   2. 발표자의 개인적 방식은 데이터 필터링이 소홀해지기 쉬우므로 최소한 골든 트레이스 세트를 별도로 만들고, 더 작은 데이터라도 학습에서 가중치를 높이는 것이다.
   3. 반면 사고 토큰(thinking tokens)에 관한 여러 글은 실패한 작업도 사고 과정 개선에는 도움이 될 수 있다고 말한다. 오답이 포함되어도 더 작은 모델이 추론 과정을 배우는 데 이득을 얻을 수 있다.
   4. 따라서 골든 데이터 비율을 늘려야 하는지 포함 여부를 시험하고 측정해야 한다. 일반 규칙 하나로 정할 수 없다.
   5. 작은 모델의 SFT에서는 성능을 비슷하게 유지할 수 있는지가 주된 기준이다. 점수가 1% 떨어질 수도 있지만, 기초 모델이 해당 업무에 특화되지 않았다면 10% 좋아질 수도 있다. 성능을 유지하거나 개선하면서 비용을 100분의 1로 낮출 수 있는지가 동기다.
   6. 기본 수준을 넘어가려면 기준이 되는 참조 샘플이 중요하다. 데이터를 직접 살펴야 하지만 고객들이 데이터 검토를 꺼리는 점이 어려움으로 남는다.

7.2. Claude Code 종속과 대안으로의 전환

1. 도구를 바꾸는 것이 첫 단계일 수 있음

   1. 청중은 Claude Code와 통합 기능이 만드는 오버헤드 때문에 특정 모델 생태계에 묶이는 상황을 질문한다.
   2. 발표자는 Claude Code가 완전한 종속의 사례라고 인정하고, 경우에 따라서는 사용 중인 도구를 바꾸는 것부터 시작해야 한다고 답한다.
   3. 어떤 팀은 Devin 또는 다른 한 도구만 쓰지만, 도구 선택에 유연한 팀도 있다. 발표자는 처음부터 자체 에이전트 시스템을 만드는 것에 회의적이며, 간단한 대안을 검토할 것을 권한다.

2. Pi를 계획·구현 분리에 활용함

   1. Pi는 단순하고 가벼워 수정이 쉬우며, 같은 모델에서도 토큰 비용이 낮다는 평가를 받는다.
   2. 100토큰/초 수준으로 빠른 모델을 제공하면 사용자들이 새로운 도구를 시도할 가능성이 커진다.
   3. Claude Code를 계획자로 유지하고 Pi를 구현자로 연결하면 기존 습관을 한 번에 버리지 않고 새 모델로 이행할 수 있다.

3. MCP보다 단순한 로컬 연동

   1. 작은 에이전트를 MCP로 노출하는 방법이 제안된다.
   2. MCP 에이전트는 올바르게 설정하지 않으면 파일 시스템에 접근하지 못할 수 있어 복잡성이 생긴다.
   3. Python을 설치하고 python this.py 형식의 배치 파일을 실행하는 단순한 방식이 흔히 더 실용적이라고 답한다.

7.3. 캐시 전략과 프라이버시

1. 고객 전용 캐시를 구성함

   1. 청중은 고객별로 캐싱 전략을 설계해 얻은 성과 사례를 익명으로 공유할 수 있는지 묻는다.
   2. 발표자는 대형 고객에게 전용 캐시(dedicated cache)를 구축한다고 답한다.
   3. 캐시가 특정 고객에게만 속하면 다른 고객의 정보가 캐시에 섞이는 문제를 줄여 프라이버시를 보호할 수 있다.

2. 캐시 문제의 구체적 맥락을 확인해야 함

   1. 프롬프트 포맷팅(prompt formatting)도 관련 있지만, 질문의 의미가 여러 가지일 수 있어 어떤 캐싱 기법을 묻는지 추가로 확인해야 한다고 말한다.
   2. 요약 답은 “가능하다”이지만, 구체적인 고객 사례와 결과는 별도로 논의할 수 있다고 한다.

7.4. 자동 라우팅 방식

1. 턴 단위보다 작업 단위 라우팅을 선호함

   1. 청중은 턴 기반(turn-based)과 작업 기반(task-oriented) 자동 라우팅 중 어떤 방식을 권하는지 묻는다.
   2. 발표자는 부서나 조직의 기대치를 통제하기 쉬워 작업 단위 라우팅을 선호한다고 답한다.
   3. 한 부서의 라벨링 업무에 전용 모델을 배정하고 해당 부서의 요청을 자동으로 그 모델에 보내는 식으로 운영할 수 있다.

2. 모델 수를 두세 개로 제한함

   1. 단계별(step-by-step) 라우팅이 주목받지만 사용할 모델을 최대 두세 개 정도로 제한해야 캐시 효율을 유지하기 쉽다.
   2. GRM 5.3과 GRM 5.3 Flash처럼 관련된 두 모델 사이에서 분기하는 것은 합리적일 수 있다.
   3. 모델 30개를 두고 단계마다 모델을 바꾸면 캐시 적중률이 크게 떨어져 최적화 효과를 깎아먹는다.
   4. 질의 단위로 수많은 모델 사이를 오가는 구성은 설득력이 떨어지며, 작업과 조직 단위의 명확한 모델 선택이 낫다는 데 발표자와 청중이 동의한다.

---

주요 발언 모음

“토큰 지출과 사용량을 측정하지 않았다면, 내가 하는 다른 말은 모두 무시하고 측정부터 시작해라.”

“사람들은 회사를 위해 모델을 바꾸지 않는다. 더 빠르기 때문에 바꾸게 만들어라.”

“백그라운드 에이전트에 초당 120토큰을 지불하지 마라. 말이 되지 않는다.”

“토큰은 최종 제품이 아니다.”

“내 AI 에이전트에 문제가 있다고 넘길 수 없다. 생성물의 책임은 나에게 있다.”

“사용량이 아니라 결과를 측정해라.”

핵심 데이터 & 수치

• 2조 토큰/일: 대형 고객 한 곳이 처리하는 일일 토큰 규모다.
• 약 0.03달러/백만 토큰, 약 6만 달러/일: 2조 토큰/일 고객 사례에서 언급한 추론 단가와 하루 비용이다.
• 512대 AMD MI25 GPU: 대형 고객의 프라이빗 400B MoE 모델 운영 규모다.
• 월 1만 달러: 워크숍의 대규모 최적화가 유용할 수 있는 임의의 지출 기준이다.
• 30~40%: 초기 상담 고객 중 전사 공용 API 키를 사용하는 비율이다.
• 분당 최대 1,000만 메시지: 아동 안전 문자 필터링을 수행하는 통신 고객의 피크 처리량이다.
• 약 10배 저렴·빠름: 발표자가 새 분류기(one-shot classifier/JAF)의 대화형 모델 대비 장점으로 제시한 수준이다.
• 10배 작은 크기: Step 1.5가 금융 벤치마크에서 Opus급에 가까운 품질을 보였다는 비교다.
• 월 25만 달러 → 7,600달러: 고객 지원 업무에서 모델 평가와 교체로 줄인 한 통신 고객의 월 추론비다.
• 27B·7B: AT&T의 통신 도메인 모델 규모다.
• 약 10분의 1 비용: 적합한 오픈 모델을 선택해 기존 사용 사례를 대체할 때 가능한 비용 절감 사례다.
• 31B·32B·27B MoE: 발표자가 노트북에서 실행 가능한 모델의 예로 든 크기다.
• 요청의 약 99%: 에이전트 사용에서 입력 소스 토큰이 차지한다고 관찰한 비중이다.
• 속도 2배 → 비용 3배: 속도와 비용의 비선형 관계를 설명하는 발표자의 경험칙이다.
• H100 1장, 112토큰/초: GRM 5.3 단일 쿼리 사례다.
• 16개 병렬 요청: 각 요청 속도는 대략 절반이지만 전체 처리량은 약 10배가 되고 비용은 9~10분의 1로 낮아질 수 있다.
• 20~30, 60, 120토큰/초: 각각 보통의 대화 속도, 더 빠른 사용자 대면 속도, 일부 고속 작업에서 고려하는 속도 구간이다.
• AI 지출 10~100배, 성과 개선 6~7%: 비용 증가와 성과 증가가 비례하지 않는 조직 사례를 설명한다.
• 페이지당 최소 30회 수정: 발표자가 AI로 디자인한 슬라이드 자료를 한 번에 생성하지 않고 반복 검토한 횟수다.
• 10,000개 이상 질문: Hugging Face가 Qwen 27B 변형을 평가하는 데 사용한 질문 수다.
• 1% 하락·10% 상승·100배 절감: 맞춤 학습 모델을 평가할 때 발표자가 제시한 성능·비용 절충의 예다.
• 최대 2~3개 모델: 단계적 라우팅에서 캐시 효율을 위해 제한하라고 권하는 모델 수다.

결론 및 시사점

1. 조직은 전사 공용 키를 업무별로 분리하고 부서·팀·작업별 토큰 비용과 결과를 측정해야 한다.
2. 장시간 컨텍스트 에이전트와 대량 단건 자동화를 별개 워크로드로 다루고, 캐시·입력 토큰·병렬성을 각각 분석해야 한다.
3. 평가 세트로 업무를 통과하는 가장 저렴한 모델을 찾고, 분류 업무에는 전용 분류기, 반복·대량 업무에는 도메인 모델과 증류를 검토해야 한다.
4. 강한 모델은 계획과 검증에, 빠르고 싼 모델은 반복 실행에 배치하고, 사용자가 비용이 아니라 속도를 이유로 싼 모델을 선택하도록 설계해야 한다.
5. 사용자 대면 호출에만 속도 프리미엄을 지불하고, CI/CD와 백그라운드 작업은 낮은 속도·높은 병렬 처리로 운영해야 한다.
6. 기본 부하와 피크를 측정해 전용 GPU와 공개 클라우드의 비중을 정하고, 실측 트래픽으로 공급자 제안을 검증해야 한다.
7. AI가 만든 코드·슬라이드·보고서의 책임은 제작자에게 두고, 테스트·작은 병합·모듈화로 검토 병목을 줄여야 한다.
8. 토큰 사용량 대신 실제 유용한 결과를 평가하며, AI를 어디에 적용할지는 조직의 도메인 지식으로 찾아야 한다.
9. 팀에서 토큰을 얼마나 쓰는지, 더 싼 모델을 쓰려면 무엇을 시험해야 하는지, 기본 부하가 얼마인지, 팀별 기본 모델은 무엇인지 확인해야 한다.
10. 여기에 사용자가 기다리는 작업은 무엇인지, 생성한 결과 중 실제로 쓸 수 있는 것은 어느 정도인지 더해 조직의 토큰 경제를 개선한다.

핵심 요약 (20줄)

부서·팀·업무별 API 키를 분리하면 토큰 비용이 어디서 발생하는지 추적할 수 있다. 월 1만 달러 미만을 쓰는 조직은 단가 최적화보다 가치가 큰 AI 활용 사례를 먼저 찾아야 한다. 하루 2조 토큰을 처리하는 고객은 512대의 AMD MI25 GPU로 400B MoE 모델을 운영한다. 장시간 에이전트는 입력과 캐시 토큰을 반복 사용하고 대량 자동화는 짧은 작업을 높은 처리량으로 실행한다. 통신사의 아동 안전 문자 필터는 분당 최대 1,000만 건의 메시지를 분류한다. 작업별 평가 세트를 만들면 테스트를 통과하는 가장 저렴한 모델을 선택할 수 있다. 한 통신 고객은 고객 지원 모델을 교체해 월 추론비를 25만 달러에서 7,600달러로 줄였다. 분류 전용 모델은 대화형 모델보다 약 10배 저렴하고 빠를 수 있다. AT&T는 통신 업무에 맞춘 27B와 7B 모델을 공개해 대규모 특화 추론을 운영한다. 최상급 모델로 학습 데이터를 만든 뒤 작은 모델로 증류하면 비용을 낮추면서 도메인 성능을 유지할 수 있다. 코딩 에이전트는 강한 모델로 계획과 검증을 하고 빠르고 싼 모델로 반복 구현을 맡길 수 있다. 사용자는 비용 절감보다 빠른 응답을 선호하므로 싼 모델의 속도를 높여 자연스럽게 선택하게 해야 한다. 기능 기반 모델 이름은 비개발 부서도 용도에 맞게 모델을 선택하고 조직이 모델을 교체하도록 돕는다. 백그라운드 CI/CD 작업은 사용자 대면 요청보다 낮은 토큰 생성 속도로 운영해야 한다. 속도를 두 배 높이면 비용이 세 배가 될 수 있으므로 업무별 토큰/초 요구량을 먼저 정해야 한다. H100 한 장에서 16개 요청을 병렬 처리하면 개별 속도는 줄어도 전체 처리량이 약 10배가 된다. 전용 GPU 용량은 기본 부하를 채울 수 있을 때 유리하며 피크는 클라우드로 넘기는 구성이 가능하다. 토큰 지출을 10~100배 늘려도 성과가 6~7%만 개선되는 조직 사례가 보고된다. 작은 코드 변경과 자동 테스트는 에이전트가 만든 코드·문서의 검토 병목을 줄인다. 생성물을 공유한 사람은 AI 탓으로 돌리지 말고 결과와 정확성에 대한 책임을 져야 한다.