LLM Observability 도입하기

LLM(Large Language Model)을 제품에 붙이기 시작하면 기존 APM으로는 보이지 않는 영역이 생깁니다. 추론 API가 HTTP 200을 반환해도 응답 품질이 깨져 있을 수 있고, 트래픽 증가가 그대로 토큰 비용 폭증으로 이어지며, 같은 프롬프트도 매번 다른 응답을 내놓아 재현이 어렵습니다. 이 가이드는 LLM Observability가 왜 별도 접근이 필요한지, WhaTap LLM Observability로 어떤 관측 흐름을 만들 수 있는지 정리합니다.

LLM 기능을 프로덕션에 투입했거나 투입 예정인 백엔드 개발자, SRE, 플랫폼 엔지니어를 대상으로 합니다. 관점·개념·메뉴 맵·활용 시나리오를 다루며, 에이전트 설치 절차나 상세 파라미터는 하위 문서로 분기합니다.

기존 APM만으로 부족한 이유

HTTP 200 뒤에 숨은 모델 이상

LLM 추론 엔진은 할루시네이션이나 비정상 응답도 HTTP 200으로 반환합니다. 서버 지표만 보면 문제가 드러나지 않기 때문에, 별도 관측이 없으면 장애 인지가 늦어집니다.

보이지 않는 토큰 비용

LLM API는 호출마다 토큰 단위로 과금합니다. 건당 비용은 모델·프롬프트 길이·응답 크기에 따라 크게 달라집니다. 에러로 실패한 요청에도 토큰이 소비되므로, 낭비 비용을 별도로 추적해야 합니다.

사용자 체감 응답 지연

LLM은 기존 API보다 수 초 느릴 수 있습니다. 스트리밍 환경의 첫 토큰 지연과 토큰 생성 속도 저하는 사용자가 "멈춘 것"으로 체감합니다. 평균값만으로는 일부 구간의 느려짐을 놓치기 쉽습니다.

프롬프트 재현 불가

같은 프롬프트라도 매번 다른 응답이 나옵니다. 문제가 발생한 시점의 프롬프트·모델·파라미터를 보존하지 않으면 이슈 재현이 불가능합니다.

멀티 모델 비교 부재

하나의 애플리케이션에서 여러 모델(Claude, GPT, Gemini 등)을 함께 쓰는 경우가 일반적입니다. 모델별 성능·비용·에러율 비교 데이터가 없으면 모델 선택 의사결정이 객관적 근거 없이 이루어지게 됩니다.

데이터 파편화

로그·메트릭·비용·트레이스가 서로 다른 플랫폼에 흩어져 있으면, 문제가 발생했을 때 여러 도구를 오가며 수동으로 연결해야 합니다. 원인 파악이 그만큼 늦어집니다.

WhaTap LLM Observability가 제공하는 관측 축

표 | LLM Observability 관측 축

Category	Description
성능	응답 시간(p50·p95·p99), 스트리밍 첫 토큰 지연, 토큰 생성 속도
비용	모델·요청·팀별 토큰 사용량, 에러 비용, 예산 대비 추세
품질·안정성	HTTP 200 내 이상 감지, 에러 유형 분류, 응답 패턴 변화
맥락	시스템 메시지·입력 프롬프트·모델 응답·도구 호출 원본 보존
연결	APM 트랜잭션 ↔ LLM 호출 ↔ GPU 인프라 엔드투엔드 트레이스

도입 단계

1단계. 에이전트 연동

현재 Python과 Java 언어를 지원합니다. Node.js와 OpenTelemetry 환경은 이후 확장 예정입니다.

• Python 설치
• Java 설치

2단계. 대시보드 탐색

에이전트 연동이 끝나면 LLM 대시보드 메뉴에서 기본 지표를 확인하세요. 초기에는 익숙한 지표(요청량·응답 시간·에러율)부터 보고, 이후 LLM 고유 지표(토큰 사용량·프롬프트 패턴)로 범위를 넓힙니다.

• LLM 대시보드

3단계. 비용 가시화

비용 분석 메뉴와 토큰 트렌드 메뉴로 모델별·팀별·시간대별 비용 구조를 파악합니다. 예산 초과 위험을 조기에 포착할 수 있습니다.

• 비용 분석
• 토큰 트렌드

4단계. 품질 이슈 추적

프롬프트 로그 메뉴로 원본 맥락을 보존하면, 이상 응답을 발견했을 때 "그때 어떤 프롬프트였는지"를 즉시 재현할 수 있습니다. LLM API 트레이스 메뉴로는 호출 흐름을 드릴다운합니다.

• 프롬프트 로그
• LLM API 트레이스

활용 시나리오

신규 LLM 기능 배포 검증

1. 베이스라인을 기록합니다. 기존 모델 기준 응답 시간·에러율·요청당 토큰 수를 저장합니다.
2. 배포 후 동일 지표를 비교합니다. 릴리즈 검증 시나리오와 동일한 흐름을 따릅니다.
3. 응답 품질에 이상이 보이면 프롬프트 로그로 원본 맥락을 재현합니다.

비용 튜닝

• 시간대별 모델 사용량을 분석해 경량 모델로 분기 가능한 요청을 식별합니다.
• 에러 요청 비용을 정량화해 재시도 로직과 타임아웃을 조정하는 절감 기준으로 활용합니다.
• 월간 비용 리포트에 포함합니다. 성능 리포팅 시나리오를 참고하세요.

사용자 체감 저하 원인 분석

1. LLM 대시보드 메뉴에서 p95·p99 응답 시간 급증을 확인합니다.
2. 해당 시간대에 어떤 모델과 어떤 엔드포인트가 느렸는지 드릴다운합니다.
3. 프롬프트 로그와 APM 트랜잭션 트레이스를 교차해 애플리케이션 레벨 문제인지 모델 레벨 문제인지 구분합니다.

GPU 인프라 연계 분석

• LLM 응답 저하 시점의 GPU 대시보드를 교차 확인합니다.
• GPU 사용률이 포화 상태라면 인프라 증설 또는 요청 분산을 검토합니다.

주요 메뉴와 문서 맵

표 | LLM Observability 주요 메뉴

Menu	Purpose	Reference
LLM 대시보드	종합 상태 보기	대시보드
비용 분석	토큰·금액 가시화	비용 분석
토큰 트렌드	사용량 추세 분석	토큰 트렌드
프롬프트 로그	원본 맥락 보존·재현	프롬프트 로그
LLM API 트레이스	호출 흐름 드릴다운	LLM API 트레이스
LLM 메트릭	커스텀 지표 정의	LLM 메트릭

다음 단계

• 에이전트 설치 → LLM Observability 시작하기
• 지원 스펙과 언어 → 지원 스펙
• MCP와 결합해 AI 에이전트가 LLM 모니터링 데이터를 자연어로 조회 → MCP 연동
• GPU 인프라 관점 → Kubernetes Observability
• 월간 비용 리포트 자동화 → 성능 리포팅 시나리오의 MCP 섹션