로깅·모니터링·관측성

어떤 지표를 모을지 정했다면, 이제 그 데이터를 실제로 수집하는 시스템을 만들어야 한다. 이번 편은 관측성을 구현하는 observability platform과, 그 핵심 도구인 trace·실험·집계 리포트를 정리한다.

 

 

1. Observability 플랫폼

LLM 기반 앱을 위한 관측성 플랫폼은 많다. 이들은 system/component 지표 캡처, traffic 로깅, 새 설정 실험 같은 일반적 평가 작업을 하도록 설계돼 있다. 이런 플랫폼을 쓰면 관측성 시스템을 설계·구현하는 시간은 줄고, 성능을 모니터링하고 개선을 실험하는 데 더 많은 시간을 쓸 수 있다. 예시로 Arise가 만든 오픈소스 플랫폼 Phoenix를 본다.

그림 1. Observability 플랫폼 — system/component 지표·로깅·실험을 지원한다(예: Arise Phoenix).

 

 

2. Trace — 프롬프트의 처리 경로 추적

가장 자주 쓰는 도구가 trace다. 프롬프트가 전체 파이프라인을 통과하는 경로를 따라가며, 각 component가 그것을 어떻게 바꾸는지 본다. 초기 텍스트 프롬프트 → retriever로 보낸 query → 반환된 chunk → re-ranker 처리 → 최종적으로 core LLM에 전달된 프롬프트 → 생성된 응답까지, 그리고 각 단계의 latency도 기록된다. 어떤 프롬프트가 나쁜 성능을 냈다면, 경로를 trace해 어느 단계가 원인인지 짚을 수 있다.

그림 2. Trace — 프롬프트가 각 component를 거치는 경로와, 각 단계에서 보이는 정보(초기 프롬프트·retriever query·반환 chunk·최종 프롬프트·응답·latency)를 함께 보여준다.

 

 

3. 평가 통합 — RAGAS

Phoenix는 이 모듈에서 본 여러 eval을 쉽게 수집하게 한다. 특히 RAGAS 라이브러리와 통합돼, retriever의 search relevancy나 LLM의 정확한 출처 인용 여부 같은 평가 단계를 손쉽게 추가할 수 있다.

그림 3. 평가 통합 — RAGAS와 연동해 search relevancy·citation 정확성 등을 파이프라인에 붙인다.

 

 

4. 간단한 실험 — 프롬프트 시도 · A/B

기본 평가 파이프라인이 서면 간단한 실험을 시작할 수 있다. 직접 프롬프트를 반복 시도해 파이프라인이 어떻게 처리하는지 보고, 시스템 변경을 A/B 테스트해 성능 영향을 확인한다. 새 시스템 프롬프트가 실제로 응답 품질을 높이는지, re-ranker 추가로 어떤 이득이 있는지 판단하는 데 도움이 된다.

그림 4. 간단한 실험 — 프롬프트를 직접 시도하고, 변경을 A/B로 검증한다.

 

 

5. 집계 리포트, 그리고 도구의 빈틈

trace가 저수준 정보를 준다면, 성능 추적엔 고수준 집계 통계도 필요하다. Phoenix는 retriever 정확도부터 환각률(hallucination rate)까지 key metric의 일일 리포트를 제공한다. 다만 이런 LLM 관측성 플랫폼도 빈틈이 있다 — 예컨대 벡터 DB의 compute·memory 사용량 모니터링엔 최적이 아니다. 이럴 땐 Datadog·Grafana 같은 더 전통적인 도구로 보완한다.

그림 6. 도구의 빈틈 — 벡터 DB 자원 모니터링 등은 Datadog·Grafana 같은 전통적 도구로 채운다.

 

개선의 flywheel. 좋은 관측성 파이프라인은 결국 개선의 선순환으로 이어진다. 실제 production 트래픽을 어떻게 처리하는지 보며 버그·개선 대상을 찾고, 변경의 영향을 확인해, 시간이 지나며 각 component를 사용자의 실제 사용 방식에 맞춘다. 이 과정에서 유용한 도구가 — 시스템이 이전에 처리한 프롬프트로 커스텀 데이터셋을 만드는 것이다(다음 편 주제).

다음 글에서는 실제 처리한 프롬프트로 커스텀 평가 데이터셋을 만들어 시스템을 정밀 튜닝하는 방법을 다룬다.