TL:DR
- PaaS 비용 문제의 본질은 플랫폼이 아니라 프롬프트·모델·RAG 설계 방식에 있다.
- 토큰 중앙화의 목적은 통제가 아니라 조직 단위의 통찰 확보이며,
- “가시성은 중앙에서, 실행은 서비스에서”라는 선을 넘으면 구조는 오히려 무거워진다.
- 0. 글을 작성하게 된 개요
- 1. 토큰이 많아질 때 시스템에서 실제로 발생하는 문제
- 2. Azure AI Foundry 비용 논쟁을 다시 바라봐야 하는 이유
- 3. 토큰 최적화는 중앙이 아니라 각 솔루션의 책임이다
- 4. Ops 관점에서 필요한 것은 ‘제어’가 아니라 ‘관찰’이다
- 5. Azure AI Foundry 기반 모니터링의 명확한 한계
- 6. [핵심] 다양한 환경에서 토큰 데이터를 전송하는 3가지 방법
- 7. 모든 데이터의 종착지: Log Analytics Workspace(LAW) 중앙화
- 8. 중앙화된 시스템이 해결해주지 못하는 ‘제어’의 영역
- 9. 결론: 토큰 중앙화의 목적은 ‘통찰’이지 ‘통제’가 아니다
0. 글을 작성하게 된 개요
최근 프로젝트를 진행하며 여러 AI Solution을 Azure Native 환경으로 이관(Migration)하는 작업을 간접적으로 접할 기회가 있었습니다. 해당 작업이 제 역할의 중심은 아니었지만, 설계 논의와 운영 이슈를 옆에서 지켜보며 자연스럽게 함께 고민하게 되었습니다.
그 과정에서 눈에 띄었던 점은, 대부분의 AI Solution이 토큰 사용량을 명확한 운영 지표로 다루지 않고 있었다는 것입니다. 모델 성능, 응답 품질, 기능 구현에는 많은 관심이 있었지만, 정작 얼마나 많은 토큰을 쓰고 있는지, 그 증가가 무엇을 의미하는지에 대한 논의는 부족했습니다.
이 글은 “토큰 계산이 왜 이렇게 중요한가?”라는 단순한 질문에서 출발합니다. 비용 이야기를 하기 이전에, 토큰이 시스템과 사용자 경험에 어떤 영향을 미치는지를 먼저 정리해보고자 합니다.
1. 토큰이 많아질 때 시스템에서 실제로 발생하는 문제
토큰 증가는 흔히 비용 문제로만 인식됩니다. 하지만 운영 관점에서 보면, 이는 훨씬 더 직접적인 리소스 소비 문제입니다. 출력 토큰이 많아질수록 시스템은 다음과 같은 부담을 동시에 안게 됩니다.
- 네트워크 점유 시간 증가: 응답 데이터를 전송하기 위한 세션 유지 시간 증대
- 연결 유지 비용 증가: 스트리밍 응답을 유지하기 위한 서버 및 로드밸런서의 부하
- Latency(지연 시간) 증가: 전체 응답이 완료될 때까지의 대기 시간 가중
여기서 중요한 점은, 사용자 경험(UX)은 단순히 첫 토큰이 얼마나 빨리 도착했는지(TTFT)로만 결정되지 않는다는 것입니다. 첫 토큰이 빠르게 도착하더라도, 출력 토큰이 과도하게 많다면 전체 응답이 끝나는 시점은 오히려 늦어질 수 있습니다.
핵심 요약
출력 토큰이 많다는 것은 “사용자에게 전달해야 할 데이터가 많아졌고, 그만큼 시스템 자원을 오래 점유한다”는 의미입니다.
제한된 리소스 환경에서는 이 특성이 곧바로 UX 저하, 동시 처리량 감소, 운영 리스크 증가로 이어집니다. 그래서 토큰은 단순한 과금 단위가 아니라, 시스템 상태를 드러내는 '신호(Signal)'로 다뤄져야 합니다.
2. Azure AI Foundry 비용 논쟁을 다시 바라봐야 하는 이유
솔직히 말하면, 처음에는 "PaaS는 나를 눈탱이 친다"고 생각했습니다. Azure AI Foundry를 쓰면서도 “이 비용이 정말 예측 가능했는가?”라는 질문에 명확히 답할 수 없었고, OpenAI 모델 역시 충분히 사용해본 경험이 없었기 때문에 비용 구조를 신뢰하기 어려웠습니다.
이런 경험이 쌓이다 보니 “PaaS는 편한 대신 무조건 비싸다”라는 인식이 자연스럽게 자리 잡았습니다. 하지만 비용을 조금 더 구조적으로 분해해보면, 이 인식은 몇 가지 중요한 요소를 간과하고 있다는 것을 알게 됩니다.
1) PaaS 비용에는 '관리 오버헤드'가 포함되어 있습니다
GPU 프로비저닝, 스케줄링, 장애 대응, API 안정성, 모니터링과 같은 운영 비용은 눈에 잘 보이지 않지만, 자체 운영 시에는 반드시 사람이 감당해야 하는 영역입니다. PaaS는 이 비용을 숨기는 대신 청구서에 명시적으로 드러낼 뿐입니다.
2) GPU 직접 운영 시의 '유휴 자원 비용'
피크 트래픽을 기준으로 잡은 GPU는 대부분의 시간 동안 놀고 있고, 그 비용은 그대로 고정비로 남습니다. 이 비용은 “안 보이기 때문에 싸다고 느껴질 뿐” 실제로는 꾸준히 누적됩니다.
문제는 플랫폼이 아니라 '사용 방식'
이 지점까지 정리하고 나서야, 비용 문제의 초점이 조금씩 이동하기 시작했습니다. 결국 비용을 폭증시키는 주된 요인은 플랫폼이 아니라, 우리가 모델을 어떻게 쓰고 있느냐였습니다.
- 필요 이상으로 큰 모델을 선택하지 않았는가?
- 출력 토큰을 통제하지 않은 프롬프트를 사용하고 있지는 않은가?
- RAG 컨텍스트를 무의식적으로 키우고 있지는 않은가?
"비용의 근본 원인은 플랫폼이 아니라, 사용 방식(프롬프트 설계와 모델 선택)에 있습니다."
아래는 요청하신 3, 4, 5번 섹션 본문 초안입니다.
앞선 섹션들과 동일하게, 불필요한 설명은 제거하고 판단 기준이 드러나도록 구성했습니다.
3. 토큰 최적화는 중앙이 아니라 각 솔루션의 책임이다
토큰 최적화는 중앙에서 일괄적으로 처리할 수 있는 문제가 아닙니다.
이유는 단순합니다. 토큰을 왜 쓰는지 아는 주체는 각 솔루션뿐이기 때문입니다.
솔루션 단위에서 반드시 통제해야 할 요소들은 명확합니다.
- 출력 토큰 상한 설정 응답 품질과 UX를 고려한 합리적인 최대 길이
- RAG 컨텍스트 크기 관리 “많이 넣을수록 정확하다”는 착각에서 벗어나는 설계
- 프롬프트 압축과 구조화 설명을 늘리는 대신, 의도를 정확히 전달하는 방향
이 결정들은 모두 비즈니스 맥락을 전제로 한 판단입니다.
어떤 기능은 요약이 적합하고, 어떤 기능은 상세 응답이 필요합니다.
이 차이는 중앙 시스템이 알 수 없습니다.
중앙에서 토큰을 직접 제어하려고 하면, 필연적으로 부작용이 발생합니다.
- 중요한 응답이 잘려 UX가 깨지거나
- 특정 기능의 품질이 예고 없이 저하되거나
- 문제의 원인이 플랫폼인지, 서비스인지 분간하기 어려워집니다
결국 토큰 최적화는
“어디까지가 적절한 응답인가”를 가장 잘 아는 쪽,
즉 각 솔루션의 책임으로 남겨두는 것이 합리적입니다.
4. Ops 관점에서 필요한 것은 ‘제어’가 아니라 ‘관찰’이다
Ops 관점에서 토큰을 다루는 방식은 다릅니다.
여기서 토큰은 더 이상 과금 단위가 아니라, 시스템 상태를 드러내는 신호입니다.
토큰 사용량을 보면 다음과 같은 이상 징후를 감지할 수 있습니다.
- 특정 API에서 출력 토큰이 갑자기 급증한다면 → 프롬프트 변경, RAG 버그, 무한 반복 가능성
- 사용자별 토큰 사용량이 비정상적으로 높다면 → Abuse, 자동화 요청, 권한 문제
- 시간대별 토큰 패턴이 달라진다면 → 트래픽 특성 변화 또는 신규 기능 영향
중요한 점은, Ops는 여기서 직접 개입하지 않는다는 것입니다.
Ops의 역할은 “막는 것”이 아니라 “보여주는 것”에 가깝습니다.
주기적인 점검과 추세 기반 관찰을 통해
- 어디서 이상이 발생하고 있는지
- 누가 판단해야 하는 문제인지를 빠르게 전달하는 것이 핵심입니다.
5. Azure AI Foundry 기반 모니터링의 명확한 한계
Azure AI Foundry를 기반으로 한 토큰 모니터링은 분명한 장점이 있습니다.
Azure OpenAI 모델을 사용하는 경우, 요청·응답 단위의 토큰 사용량을 비교적 쉽게 확인할 수 있습니다.
하지만 이 가시성은 PaaS 경계 안에서만 유효합니다.
문제는 커스텀 모델이나 자체 호스팅 모델로 시선이 옮겨갈 때 발생합니다.
모델을 직접 띄워 사용하는 순간, Azure AI Foundry가 제공하던 토큰 가시성은 더 이상 적용되지 않습니다.
즉, 모델이 다양해질수록 관측은 분절됩니다.
- PaaS 모델은 보이고
- 커스텀 모델은 보이지 않는 구조
이 Observability 공백은, 이후 토큰 중앙화를 고민하게 되는 직접적인 계기가 됩니다.
6. 토큰 데이터를 전송하는 2가지 방법
토큰 중앙화를 논의할 때 가장 먼저 결정해야 할 것은 단순합니다.
“어디에서 토큰 데이터를 추출할 것인가”입니다.
Azure 환경에서는 크게 세 가지 선택지가 존재합니다.
방법 A: APIM(Azure API Management) 프록시 활용
Azure API Management를 프록시로 두고, 요청·응답을 가로채 토큰 메트릭을 수집하는 방식입니다.
Azure에서 공식적으로 제공하는 llm-emit-token-metric 정책은 이 접근을 표준화합니다.
이 방식의 가장 큰 장점은 애플리케이션 코드 변경이 필요 없다는 점입니다.
외부 SaaS 모델이나, 이미 배포된 서비스처럼 코드를 수정하기 어려운 경우 사실상 유일한 선택지입니다.
반면, APIM은 어디까지나 프록시 계층입니다.
토큰 수는 알 수 있지만, 왜 그 토큰이 사용되었는지에 대한 맥락은 담기 어렵습니다.
설정 중심, 빠른 도입, 낮은 침투성
대신 맥락은 제한적
방법 B: 애플리케이션 직접 구현 (SDK / OpenTelemetry)
애플리케이션 코드 내부에서 LLM 응답을 파싱하고, 토큰 정보를 직접 전송하는 방식입니다.
Application Insights와 OpenTelemetry를 함께 사용하면 자연스럽게 확장할 수 있습니다.
이 방식의 핵심 가치는 맥락(Context)입니다.
- 조직 ID
- 기능 이름
- 요청 유형
- 비즈니스 이벤트
- .... etc
토큰 수치에 이러한 차원을 함께 붙일 수 있기 때문에, “누가”, “어떤 기능에서”, “왜 많이 썼는지”까지 분석이 가능합니다.
단점은 명확합니다.
개발 비용이 들고, 모든 서비스에 일관되게 적용하기 어렵습니다.
비즈니스 중심, 정밀한 분석
대신 구현 책임은 각 팀에 있음
7. 모든 데이터의 종착지: Log Analytics Workspace(LAW) 중앙화
수집 경로가 어디든, 데이터는 결국 하나로 모여야 합니다.
Azure 환경에서 그 역할을 맡는 곳이 Log Analytics Workspace입니다.
LAW를 사용하는 이유는 단순합니다.
모든 로그와 메트릭을 같은 언어로 분석할 수 있기 때문입니다.
- APIM에서 수집한 토큰 로그
- 애플리케이션이 직접 보낸 커스텀 메트릭
- Azure AI Foundry의 진단 로그
이 모든 데이터를 Kusto Query Language(KQL)로 조인하여 분석할 수 있습니다.
이때 중앙화의 진짜 가치는 대시보드 그 자체가 아닙니다.
다음과 같은 질문에 즉시 답할 수 있는 능력입니다.
- 이번 달 전체 AI 워크로드의 총 토큰 사용량은?
- 특정 서비스가 평균 대비 얼마나 더 쓰고 있는가?
- 비용 급증의 시작 지점은 언제인가?
“로그가 모였다”가 아니라, “조직 단위로 사고할 수 있게 되었다”는 점이 핵심입니다.
8. 중앙화된 시스템이 해결해주지 못하는 ‘제어’의 영역
토큰 데이터가 중앙에 모이면, 자연스럽게 이런 요구가 등장합니다.
- “많이 쓰는 요청은 중앙에서 끊자”
- “임계치 초과 시 자동으로 큐잉하자”
하지만 이 지점에서 시스템은 급격히 무거워집니다.
실시간 제어를 중앙에서 수행하려면,
- 요청 경로가 길어지고
- 정책 판단이 복잡해지며
- 장애 시 영향 범위가 커집니다
무엇보다, 중앙 시스템은 여전히 비즈니스 맥락을 알지 못합니다.
이 요청이 중요한지, 단순한 실험인지 판단할 수 없습니다.
그래서 적정선은 명확합니다.
가시성은 중앙에서, 실행과 제어는 로컬(App)에서
중앙은 “보여주고”, 각 솔루션은 “결정한다”. ⚠️⚠️⚠️ 이 분리가 깨지는 순간, 중앙화는 장점보다 위험이 커집니다.
9. 결론: 토큰 중앙화의 목적은 ‘통찰’이지 ‘통제’가 아니다
토큰 중앙화의 목적은 비용 절감이 아닙니다.
또한 모든 것을 중앙에서 통제하기 위함도 아닙니다.
진짜 목적은 통찰(Insight)입니다.
- 어떤 설계가 토큰을 낭비하고 있는지
- 어떤 프롬프트가 비효율적인지
- 어떤 서비스가 위험 신호를 보내고 있는지
토큰은 AI 시스템의 상태 신호입니다.
CPU 사용률이나 메모리와 다르지 않습니다.
그래서 가장 현실적인 결론은 다음과 같습니다.
- 중앙에서는 보인다
- 로컬에서는 판단하고 최적화한다
- 그리고 그 판단은 다시 데이터로 검증된다
이 선을 지킬 때,
토큰 중앙화는 비용 관리 도구를 넘어 성숙한 AI 운영의 기반이 됩니다.
Top comments (0)