LLM Observability
observability는 LLM 시스템 안에서 실제로 무슨 일이 벌어졌는지를 단계별로 추적할 수 있게 만드는 운영 계측입니다. 최종 답변만 보는 것이 아니라, 어떤 프롬프트가 들어갔고 어떤 문서가 검색됐고 어떤 도구가 얼마나 걸렸는지까지 연결해 보는 것이 핵심입니다.
▶아키텍처 다이어그램
📊 데이터 흐름 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
운영 중 품질이 떨어졌을 때 원인은 모델 자체가 아니라 검색 recall(관련 근거를 놓치지 않는 정도), 잘린 컨텍스트, 느린 도구, 잘못된 schema validation(구조 검증), 오래된 memory일 수 있습니다. 그런데 최종 채팅 로그만 보면 이 단계들이 전부 한 덩어리로 보이기 때문에, 문제를 프롬프트 수정으로만 해결하려다 시간을 낭비하기 쉽습니다.
초기 LLM 앱은 사람이 채팅 로그를 읽어가며 감으로 디버깅하는 경우가 많았습니다. 하지만 RAG, tool use, agent loop가 붙으면서 한 번의 요청이 여러 내부 단계로 쪼개졌고, 그 단계별 trace 없이는 원인 분석이 불가능해졌습니다.
보통은 요청 메타데이터, 실제 prompt/context snapshot, retrieval hit, tool span, 최종 응답, 사용자 피드백을 하나의 trace(한 요청의 단계별 기록)로 묶습니다. 이 trace를 쌓으면 특정 실패가 항상 retrieval 이후에 생기는지, 특정 도구가 지연을 키우는지, 어떤 memory가 계속 잘못 인용되는지 같은 패턴이 드러납니다. 좋은 observability는 단순 로그 수집이 아니라, 원인 추적이 가능한 연결 구조를 만드는 데 있습니다.
observability와 evals는 둘 다 품질 실패를 다루지만, observability는 실제 트래픽에서 왜 실패했는지를 추적하고 evals는 그 실패를 배포 전에 다시 재현하는 도구입니다. 운영 원인을 먼저 파악해야 하면 observability를 보고, 발견한 실패를 회귀 테스트로 고정하려면 evals를 봐야 합니다. trace를 많이 모아도 그것만으로 목표 품질이 자동으로 정의되지는 않는다는 점이 한계입니다.
실무에서는 incident 대응, retrieval 튜닝, 비용 최적화, 안전 정책 조정, 에이전트 루프 디버깅에 직접 쓰입니다. thumbs up/down 같은 최종 반응만 보면 실패를 안다는 데서 끝나지만, trace가 있으면 어느 단계가 병목인지까지 보입니다. 결국 observability는 '이 시스템이 왜 이렇게 행동했는가'를 설명 가능하게 만드는 운영 기반입니다.