[LLM Observability] Day 5: 관측성 플랫폼 설계 - 운영 성숙도 로드맵

서론: 도구보다 먼저 물어야 할 것

관측성 플랫폼 도입에서 가장 흔한 실수는 도구 선택부터 시작하는 것이다. Datadog을 쓸지, Langfuse를 쓸지보다 먼저 “지금 팀이 어떤 질문에 답하지 못하고 있는가”를 정해야 한다.

답할 수 없는 질문의 목록이 곧 관측성 로드맵이다.

1. 성숙도 단계 모델

Level 0: 관측성 없음

• 오류는 사용자 불만 또는 수동 테스트로 발견
• 모델 교체 효과를 측정하지 못함

Level 1: 기본 계측

• request_id, 지연, 에러율 수집
• 기본 알람 (p99 지연, 에러율)
• 프롬프트/응답 로그 (비식별화)

Level 2: 파이프라인 가시성

• 분산 트레이싱 (span 단위 추적)
• RAG retrieval, 툴 호출 지표 분리
• 가드레일 차단률 모니터링

Level 3: 품질 측정

• 오프라인 골든 테스트셋 평가
• LLM-as-Judge 자동 채점
• 온라인 A/B 실험 인프라

Level 4: 자동화된 피드백 루프

• 품질 이상 탐지 → 자동 알람 → 롤백 트리거
• 실패 사례 자동 수집 → 골든셋 갱신
• 지속적 평가를 CI/CD 게이트에 통합

2. 플랫폼 컴포넌트 지도

┌─────────────────────────────────────────────────────┐
│  Data Collection                                     │
│  OTel SDK → Collector → Log/Trace/Metric 라우팅       │
├─────────────────────────────────────────────────────┤
│  Storage & Query                                     │
│  Logs: S3 + Athena / Loki                            │
│  Traces: Jaeger / Tempo                              │
│  Metrics: Prometheus / Mimir                         │
│  Eval Results: 관계형 DB 또는 실험 트래킹 시스템        │
├─────────────────────────────────────────────────────┤
│  Analysis & Alerting                                 │
│  Dashboard: Grafana                                  │
│  Alert: Alertmanager / PagerDuty                     │
│  Eval UI: Langfuse / Weights & Biases / 자체 구축     │
└─────────────────────────────────────────────────────┘

전용 LLM 관측성 도구(Langfuse, Helicone 등)는 빠른 시작에 유리하고, OTel 기반 자체 구축은 유연성이 높다. 초기에는 전용 도구로 시작해 성숙해지면 내재화하는 경로가 현실적이다.

3. 팀 구조와 소유권

관측성 플랫폼이 방치되는 가장 큰 원인은 소유권 불명확이다.

역할	책임
Platform/MLOps 팀	계측 표준, 수집 파이프라인, 저장소
제품/ML 팀	평가 지표 정의, 골든셋 유지보수
Security 팀	PII 마스킹 정책, 감사 로그

세 팀이 공통 대시보드를 공유해야 서로 다른 기준으로 “정상”을 판단하는 혼선이 줄어든다.

4. 도입 순서 권고

1. request_id 삽입과 기본 지연/에러 계측
2. span 트레이싱 확장 (RAG, 툴 호출)
3. PII 마스킹 정책 + 로그 비식별화
4. 골든 테스트셋 + 오프라인 평가 CI 게이트
5. 온라인 품질 신호 + A/B 인프라
6. 이상 탐지 + 자동 알람 튜닝

각 단계는 이전 단계가 안정될 때 다음으로 이동한다. 한 번에 전 계층을 구축하면 유지보수 부채가 빠르게 쌓인다.

5. 시리즈 종합 체크리스트

1. 로그·트레이스·메트릭 세 축을 OTel 기반으로 통합했다.
2. 오프라인 평가를 CI 게이트로, 온라인 평가를 A/B 인프라로 연결했다.
3. 에이전트 체인의 span 트리를 서비스 경계까지 추적한다.
4. 인프라/파이프라인/품질 계층별 알람을 분리해 오탐률을 관리한다.
5. 관측성 플랫폼 소유권을 팀별로 명확히 정의했다.

시리즈 마무리

LLM 관측성의 결론은 데이터 엔지니어링의 결론과 같다. 측정할 수 없는 것은 개선할 수 없다.

모델이 좋아졌는지, 나빠졌는지, 어디서 실패하는지 알 수 없다면 어떤 최적화도 추측에 불과하다. 로그·트레이스·메트릭·평가를 하나의 운영 체계로 연결할 때 비로소 LLM 시스템을 “운영”하고 있다고 말할 수 있다.