AI 용어집 · 기초 · MLOps·LLMOps · 에이전트
LLM 관측 가능성 LLM Observability
LLM 관측 가능성은 LLM을 쓰는 서비스가 실제로 무엇을 입력받고, 어떤 단계를 거쳐, 무엇을 답했는지 기록하고 들여다볼 수 있게 하는 것입니다. 문제가 생겼을 때 원인을 찾고 품질·비용을 관리하는 데 씁니다.
어떻게 작동하나
사용자 요청 하나가 들어오면 프롬프트 조립, 문서 검색, LLM 호출, 도구 사용, 최종 답변 같은 단계를 거칩니다. 관측 도구는 이 단계들을 하나의 흐름(트레이스)으로 묶어 각 단계의 입력·출력·걸린 시간·사용한 토큰 수를 기록합니다. 이렇게 모인 기록을 대시보드에서 보며 느린 단계, 비용이 많이 드는 요청, 오류가 난 지점을 찾습니다. 사용자의 좋아요·싫어요 같은 피드백이나 자동 평가 점수도 함께 붙여 둡니다.
요청마다 기록해 두면 좋은 것
흐름
- 어떤 단계를 거쳤는가
- 각 단계의 입력과 출력
- 오류가 난 지점
성능·비용
- 단계별 걸린 시간
- 사용한 토큰 수
품질
- 사용자 피드백
- 자동 평가 점수
왜 중요한가
LLM은 같은 질문에도 답이 조금씩 달라지고, 그럴듯하지만 틀린 답(환각)을 내기도 합니다. 일반 프로그램처럼 오류가 나면 멈추는 게 아니라 틀린 답을 자연스럽게 내놓기 때문에, 기록을 보지 않으면 문제를 알기 어렵습니다. 에이전트처럼 여러 단계를 스스로 밟는 시스템은 어디서 길을 잘못 들었는지 추적하는 일이 더욱 중요합니다. 토큰 사용량을 지켜보면 비용이 갑자기 늘어나는 것도 일찍 알아챌 수 있습니다.
알아 둘 점
대화 기록에는 개인정보나 회사 기밀이 들어 있을 수 있어, 저장 전에 가리거나 보관 기간을 정하는 등 관리가 필요합니다. 기록만 쌓아서는 품질이 좋아지지 않으므로, 모은 실패 사례를 Evals(평가 세트)로 만들어 프롬프트나 모델을 바꿀 때마다 확인하는 흐름과 연결해야 효과가 큽니다. LLM-as-a-Judge로 답변 품질을 자동 채점해 함께 기록하는 방식도 많이 씁니다. 전통적인 서비스 모니터링 도구에 LLM 전용 기능을 더한 형태가 흔합니다.
예시
사내 문서 검색 챗봇에서 '답이 엉뚱하다'는 불만이 들어오면, 담당자는 관측 도구에서 그 대화의 트레이스를 엽니다. 검색 단계에서 엉뚱한 문서가 뽑혔는지, 문서는 맞았는데 LLM이 잘못 요약했는지를 단계별 기록으로 확인할 수 있습니다. 원인이 검색이면 청킹이나 리랭커를 손보고, 이 사례를 평가 세트에 추가해 다음 변경 때 같은 실수가 반복되지 않는지 확인합니다.