LLM 애플리케이션 프로덕션 운영, 옵저버빌리티로 풀다

안녕하세요! AI 네이티브 옵저버빌리티 플랫폼, 와탭랩스입니다.

최근 몇 줄의 코드만으로 강력한 언어 모델을 호출할 수 있는 시대가 열리며, LLM(대규모 언어 모델) 애플리케이션 구축의 진입 장벽은 빠르게 낮아졌습니다. boto3 클라이언트를 생성하고 invoke_model을 호출하여 프롬프트를 전달하는 등 불과 16줄의 코드로 AI를 애플리케이션에 이식할 수 있습니다.

하지만 “만드는 것은 쉬운데, 운영은 어떻게 할 것인가?”라는 질문에 명확히 답하기란 결코 쉽지 않습니다. 프로덕션 환경에서 LLM 애플리케이션을 운영하려면 예측하기 어려운 토큰 비용, 모델의 비결정적(Non-deterministic) 출력 특성, 그리고 무엇보다 할루시네이션(환각)이라는 치명적인 리스크를 함께 관리해야 하기 때문입니다.

이 글에서는 프로덕션 환경의 LLM 운영이 직면한 핵심 과제와 이를 해결하기 위한 LLM 옵저버빌리티(Observability) 구축 전략을 살펴봅니다.

본 글은 지난주 AWS Summit Seoul 2026에서 와탭랩스 신민철 Agent Developer가 발표한 <LLM 애플리케이션 프로덕션 운영, 옵저버빌리티로 풀다> 세션을 바탕으로 구성되었습니다.

‍

생성형 AI 운영의 숨겨진 리스크

기업 환경에 도입된 AI가 초래할 수 있는 비즈니스 리스크는 이미 세계 곳곳에서 현실화되고 있습니다.

대표적으로 에어캐나다(Air Canada)의 고객 지원 챗봇이 실제로는 존재하지 않는 가족 사망 관련 항공권 할인 정책과 환불 절차를 고객에게 안내해, 결국 법원의 배상 판결을 받은 사건이 있습니다. 또한, 자동차 딜러의 챗봇이 사용자의 교묘한 프롬프트 조작에 속아 2024년형 쉐보레 타호를 단 1달러에 판매하기로 합의하고, “법적 구속력이 있는 제안이며 취소 불가”라고 응답한 사례도 있습니다.

이러한 문제로 인해 2024년 기준 AI 할루시네이션으로 발생한 비즈니스 손실 추정치는 약 67.4억 달러에 달합니다. 도메인별 할루시네이션 발생률을 살펴보면 일반 지식 분야가 9.2%인 반면, 법률 정보 18.7%, 과학 연구 16.9%, 의료/헬스케어 15.6%, 코딩 15.2%, 금융 데이터 13.8% 등 정확성이 중요한 엔터프라이즈 핵심 영역에서 훨씬 높은 발생 빈도를 보이고 있습니다.

여기에 모델을 업그레이드하거나 논리적 사고 기능이 강화된 추론(Reasoning) 모델로 전환할 때 발생하는 예측하기 어려운 선형적 비용 상승 역시 기업의 운영 예산을 위협하는 요인이 되고 있습니다.

‍

LLM 애플리케이션의 기술적 특성과 기존 APM의 맹점

이러한 위협을 사전에 차단하기 위해서는 모니터링 체계가 필수적입니다. 그러나 기존 방식만으로는 한계가 명확합니다.

일반적인 API는 수십 밀리초(ms) 내에 일관된 응답을 반환하는 반면, LLM API는 수 초 단위의 긴 지연 시간(Latency)을 보일 수 있습니다. 또한 동일한 질문에도 매번 다른 텍스트를 생성하는 비결정적 특성을 지닙니다. 따라서 기존 개발 환경에서 흔히 사용하던 assert expected == actual 형태의 단순 값 비교 테스트는 LLM 환경에서는 의미가 제한적입니다.

가장 치명적인 문제는 기존 애플리케이션 성능 모니터링(APM) 도구가 LLM 환경에서 착시를 일으킬 수 있다는 점입니다. APM은 서버가 HTTP 200 OK를 반환하면 시스템이 정상이라고 판단하지만, 실제 출력 텍스트에는 심각한 할루시네이션이 포함되어 고객에게 피해를 주고 있을 수 있습니다.

또한, 기존 모니터링은 트랜잭션 횟수(TPS)를 집계할 수는 있지만, 사용된 토큰 수까지 측정하지는 못합니다. 사용자 유입 수치나 트랜잭션 수가 지난달과 동일하더라도, 더 긴 프롬프트를 처리했거나 고비용 모델을 사용했다면 이번 달 비용이 10배 이상 폭증할 수 있습니다. 그러나 기존 방식만으로는 이를 즉각 감지하기 어렵습니다.

예를 들어 하나의 API 요청 처리에 총 8,000ms가 소요되었다고 가정해 보겠습니다. 기존 APM은 이를 ‘하나의 느린 일반 API’로 인식할 수 있습니다. 하지만 그 내부에는 RAG 문서 검색 2초, 에이전트 도구 실행 1초, 최종 응답 종합 5초 등 복잡한 내부 호출 체인(Chain)이 숨어 있을 수 있습니다.

‍

비용과 성능을 통제하는 LLM Observability 핵심 지표

이러한 기존 모니터링의 사각지대를 메우기 위해서는 LLM 호출을 딥 다이브 분석할 수 있는 특화된 옵저버빌리티 체계가 필요합니다. 이는 크게 애플리케이션 레이어와 LLM API 레이어로 나누어 추적해야 합니다. 먼저 애플리케이션 레이어에서는 사용자의 요청부터 최종 응답이 반환될 때까지의 전체 흐름, 즉 E2E(End-to-End) 지연 시간을 트레이스(Trace) 단위로 상세히 추적해야 합니다.

LLM API 레이어에서는 다음 지표를 실시간으로 모니터링해야 합니다.

• TTFT(Time To First Token): 사용자 체감 응답 속도를 결정하는 첫 토큰 생성 시간
• TPOT(Time Per Output Token): 스트리밍 출력 시 토큰 하나를 생성하는 데 걸리는 시간
• TPS(Tokens Per Second): 모델 서빙의 전반적인 처리량

동시에 입력 토큰, 출력 토큰, 전체 토큰 사용량을 명확히 분리해 기록하고, 모델별 토큰 단가를 시스템에 매핑해야 합니다. 이를 통해 호출 한 건당 발생하는 정확한 과금액(Cost)을 실시간으로 확인할 수 있어야 예기치 못한 비용 폭증을 방지할 수 있습니다.

‍

서비스 아키텍처에 따른 전략 분리: Provider vs Local LLM

어떤 LLM 서빙(serving) 방식을 선택하느냐에 따라 모니터링의 중점 영역도 달라집니다.

OpenAI API, Amazon Bedrock, Anthropic API와 같이 외부 API를 사용하는 프로바이더(Provider) LLM 환경에서는 주로 토큰 카운트 측정, 4xx/5xx 에러율 관리, API 레이어의 지연 시간 확인에 집중해야 합니다. 무엇보다 정상 응답 안에 포함될 수 있는 내용적 오류를 검증하고, 다양한 프롬프트 로그를 수집해 응답 품질을 지속적으로 최적화하는 것이 중요합니다.

반면 데이터 보안과 맞춤화를 위해 vLLM, Ollama, TGI 등을 활용해 로컬(Local) LLM을 자체 인프라에 구축한 경우에는 소프트웨어를 넘어 하드웨어 인프라 관리가 필수적입니다. GPU 메모리(vRAM) 사용량, 추론 엔진의 핵심 지표인 KV Cache 활용률, GPU 디바이스별 실제 사용량 등을 통합 모니터링 대시보드에서 면밀히 관제해야 병목 현상을 예방할 수 있습니다.

‍

통합 모니터링으로 완성하는 End-to-End 가시성

결국 성공적인 LLM 애플리케이션 프로덕션 운영은 사용자 경험부터 인프라까지 모든 흐름을 하나의 선으로 연결하는 통합 모니터링 확보에 달려 있습니다.

프론트엔드 사용자의 브라우저 렌더링을 추적하는 RUM(Real User Monitoring), 백엔드 서버의 트랜잭션을 분석하는 APM, 쿠버네티스(K8s)와 GPU 인프라 리소스를 관제하는 시스템, 그리고 LLM의 프롬프트 품질과 토큰별 비용을 산출하는 LLM 전용 모니터링(LLM Observability)이 하나의 유기적인 대시보드로 통합되어야 합니다.

와탭(WhaTap)과 같은 통합 모니터링 도구를 활용해 시스템 내부를 관통하는 추적성을 확보한다면 기업은 통제하기 어려운 비용과 치명적인 할루시네이션 리스크에서 벗어나 보다 안정적이고 신뢰할 수 있는 엔터프라이즈 AI 서비스를 제공할 수 있습니다.

‍

LLM Observability FAQ

Q1. 기존 애플리케이션 성능 모니터링(APM) 툴로는 LLM 애플리케이션을 관리할 수 없나요?

A. 기존 방식만으로는 LLM의 고유한 문제를 감지하기 어렵습니다. 기존 APM은 서버가 200 OK 정상 상태 코드를 반환하면 시스템에 문제가 없다고 판단합니다. 그러나 실제 LLM의 텍스트 출력에는 치명적인 할루시네이션이 포함되어 사용자에게 잘못된 정보를 전달하고 있을 수 있습니다.

또한 기존 툴은 트랜잭션 수(TPS)를 집계할 수는 있지만, 사용된 토큰 수까지는 집계하지 못합니다. 따라서 트랜잭션 건수가 동일하더라도 내부 프롬프트가 길어지거나 고비용 모델을 사용할 경우, 토큰 비용이 10배 이상 폭증하는 현상을 파악하기 어렵습니다.

Q2. LLM의 성능과 비용을 통제하기 위해 집중적으로 모니터링해야 할 핵심 지표는 무엇인가요?

A. LLM API 레이어에서는 다음과 같은 세부 지표를 추적하는 것이 중요합니다.

• TTFT(Time To First Token): 사용자가 체감하는 첫 토큰 생성 소요 시간
• TPOT(Time Per Output Token): 토큰 하나가 생성되는 데 걸리는 스트리밍 속도
• TPS(Tokens Per Second): 초당 모델 처리량

이와 함께 입력(Input) 토큰과 출력(Output) 토큰 사용량을 명확히 분리해 추적하고, 모델별 토큰 단가를 매핑해 호출 한 건당 발생하는 과금액(Cost)을 실시간으로 모니터링해야 합니다.

Q3. 외부 API를 쓰는 Provider LLM과 자체 구축한 Local LLM은 모니터링 전략이 다른가요?

A. 네. 두 환경은 아키텍처가 다르기 때문에 중점적으로 봐야 할 영역도 다릅니다.

OpenAI API, Amazon Bedrock, Anthropic API 같은 Provider LLM 환경에서는 사용 토큰 수, 4xx/5xx 에러율, API 지연 시간 추적과 함께 정상 응답 내 할루시네이션 검증 및 프롬프트 품질 관리에 집중해야 합니다.

반면 vLLM, Ollama 등을 자체 인프라에 올린 Local LLM 환경에서는 API 레이어뿐 아니라 하드웨어 레이어 모니터링이 필수적입니다. 특히 GPU의 vRAM 실제 활용률, 추론 엔진의 핵심 요소인 KV Cache 사용률 등을 통합적으로 관제해야 안정적인 운영이 가능합니다.