[AWS SUMMIT 2025] LLM Observability: LLM의 잘못된 응답(Hallucination)을 잡아내는 법
들어가며
LLM Observability: LLM의 잘못된 응답(Hallucination)을 잡아내는 법
🎙️Datadog, SE Manager 이성욱님
🗂️ 세션 토픽: 기술 트랜드, 생성형 AI, 보안및거버넌스
연사는 기존의 모니터링 체계가 API 응답 코드나 예외 발생 여부 중심으로 설계되어 왔다고 지적하며, 이러한 방식이 LLM 시스템에는 충분하지 않다고 강조했다. LLM 시스템에서는 겉보기에는 정상이지만, 실제로는 전혀 다른 잘못된 응답이 나오는 경우가 빈번하다. 이처럼 ‘이상하지만 감지되지 않는’ 문제를 어떻게 추적할 수 있을지에 대해, 세션에서는 새로운 관점의 Observability 구조 필요성을 중심으로 발표가 전개되었다.
LLM이 기존 시스템과 다른 점
LLM은 단순히 입력-출력만으로 파악되지 않는다. 프롬프트 구성 → 문서 검색 → 응답 생성의 여러 단계를 거치기 때문에, 이 중 어느 하나라도 어그러지면 결과물이 왜곡될 수 있다.
세션에서는 이러한 데이터 흐름 전반을 시각화하며, 기존의 단일 로그 기반 진단으로는 LLM 특유의 오류를 감지하기 어렵다는 점이 강조되었다.
특히 응답 품질 문제는 단순히 기술적인 문제가 아니라 사용자 신뢰도와 직결된다. 사용자가 “답변이 이상하다”고 느끼는 순간, 단순한 기술 결함이 아니라 서비스 전체의 인식에 영향을 미칠 수 있다. 따라서 품질 관리는 기술적 영역과 사용자 경험을 동시에 고려해야 하는 과제로 부상하고 있다.
세션에서는 이러한 데이터 흐름 전반을 시각화하며, 기존의 단일 로그 기반 진단으로는 LLM 특유의 오류를 감지하기 어렵다는 점이 강조되었다.
특히 응답 품질 문제는 단순히 기술적인 문제가 아니라 사용자 신뢰도와 직결된다. 사용자가 “답변이 이상하다”고 느끼는 순간, 단순한 기술 결함이 아니라 서비스 전체의 인식에 영향을 미칠 수 있다. 따라서 품질 관리는 기술적 영역과 사용자 경험을 동시에 고려해야 하는 과제로 부상하고 있다.
관찰 가능한 구조를 설계하는 세 가지 핵심
1. End-to-End 트레이스 확보
단순한 호출 성공/실패를 넘어서, 입력부터 출력까지 전체 처리 과정을 연속적으로 추적할 수 있어야 한다. 특히 사용자 요청 → 응답 생성까지의 과정을 시간 순으로 시각화한 화면이 공유되었고, 병목 발생 지점을 어떻게 파악하는지를 예시로 설명했다.
이는 단순히 기술적 이슈 해결을 넘어서, 실제 사용자 여정(User Journey) 상 어떤 지점에서 문제가 발생하는지를 함께 파악할 수 있다는 점에서 강력한 분석 도구로 기능한다. 이를 통해 특정 사용자나 특정 경로에서 반복적으로 발생하는 문제를 빠르게 식별하고, 유입 경로나 UI 구성의 변경, 백엔드 최적화 등 구체적인 조치를 취할 수 있는 실질적인 실행 근거를 마련할 수 있다.
단순한 호출 성공/실패를 넘어서, 입력부터 출력까지 전체 처리 과정을 연속적으로 추적할 수 있어야 한다. 특히 사용자 요청 → 응답 생성까지의 과정을 시간 순으로 시각화한 화면이 공유되었고, 병목 발생 지점을 어떻게 파악하는지를 예시로 설명했다.
이는 단순히 기술적 이슈 해결을 넘어서, 실제 사용자 여정(User Journey) 상 어떤 지점에서 문제가 발생하는지를 함께 파악할 수 있다는 점에서 강력한 분석 도구로 기능한다. 이를 통해 특정 사용자나 특정 경로에서 반복적으로 발생하는 문제를 빠르게 식별하고, 유입 경로나 UI 구성의 변경, 백엔드 최적화 등 구체적인 조치를 취할 수 있는 실질적인 실행 근거를 마련할 수 있다.
2. 응답 품질 자동 점검
연사는 사람이 하나하나 응답을 검토하는 것은 현실적으로 불가능하다고 강조하며, 그 대안으로 시스템이 다음과 같은 기준에 따라 응답의 품질을 자동으로 평가하고, 이상 징후를 마킹해야 한다고 제시했다:
- 답변 실패 또는 불완전한 응답
- 질문과 무관한 응답
- 유해하거나 부정적인 표현
- 언어 불일치 (예: 한글 질문에 영어 응답)
세션에서는 실제 데이터에서 이런 마킹이 어떻게 적용되는지를 예시로 보여주며, 정적 평가뿐 아니라 LLM을 활용한 재분석 루프를 통해 준실시간으로 결과를 보정하는 전략도 제시되었다. 연사는 “데이터독이 수집한 LLM 트레이스에서 인풋과 아웃풋을 다시 한 번 LLM에 태워서, 실패 여부나 부정 응답, 언어 오류, 주제 일치 여부를 실시간으로 마킹한다”고 언급하며, 단순 로그 확인이 아닌 자동화된 후처리 분석이 운영 효율을 높인다고 강조했다.
3. 보안 이슈 대응
LLM은 외부 입력을 기반으로 응답을 생성하기 때문에, 프롬프트 인젝션, 민감정보 노출 등의 리스크가 내재되어 있다. 특히 최근에는 공격자가 어시스턴트 구조를 우회해 가격 협상을 유도하거나, 프롬프트 내 민감 정보 유출을 시도하는 등 복합적 리스크가 증가하고 있다.
이를 방지하기 위한 입력 필터링, 응답 마스킹, URL 감지 등에 대한 구성도 함께 소개되었으며, 보안 위협 탐지를 위한 후처리 LLM 실행 구조도 설명되었다. 연사는 “대부분은 끝나고 나서 인풋과 아웃풋을 한 번씩 돌려요. 그런데 그러면 민감 데이터가 노출된 이후고, 대처하기에는 늦은 타이밍일 수 있다”고 말하며, 데이터독은 응답 전 단계에서 자체적으로 인풋·아웃풋을 받아 LLM에 다시 태워 민감 정보나 이상 징후를 실시간으로 마킹하는 구조를 갖추고 있다고 강조했다.
LLM은 외부 입력을 기반으로 응답을 생성하기 때문에, 프롬프트 인젝션, 민감정보 노출 등의 리스크가 내재되어 있다. 특히 최근에는 공격자가 어시스턴트 구조를 우회해 가격 협상을 유도하거나, 프롬프트 내 민감 정보 유출을 시도하는 등 복합적 리스크가 증가하고 있다.
이를 방지하기 위한 입력 필터링, 응답 마스킹, URL 감지 등에 대한 구성도 함께 소개되었으며, 보안 위협 탐지를 위한 후처리 LLM 실행 구조도 설명되었다. 연사는 “대부분은 끝나고 나서 인풋과 아웃풋을 한 번씩 돌려요. 그런데 그러면 민감 데이터가 노출된 이후고, 대처하기에는 늦은 타이밍일 수 있다”고 말하며, 데이터독은 응답 전 단계에서 자체적으로 인풋·아웃풋을 받아 LLM에 다시 태워 민감 정보나 이상 징후를 실시간으로 마킹하는 구조를 갖추고 있다고 강조했다.
Hallucination은 진짜 잡을 수 있는가?
세션 후반에서는 ‘Hallucination’ 문제 해결 전략이 구체적으로 제시되었다. 연사는 문제의 심각성을 강조하기 위해 ‘세종대왕 맥북 던짐 사건’이라는 유머러스한 예시를 소개하며, 명백하게 비현실적인 응답은 빠르게 인지할 수 있지만, 실제로는 환불 금액을 과장하는 등 사실처럼 보이지만 틀린 응답이 더 위험하다고 지적했다. 특히, RAG 기반 구조에서 참조 문서와 최종 응답 간의 일치율을 비교해 검증하는 방법이 소개되었고, 이를 시각적으로 표현한 루프 구조가 강조되었다.
예를 들어 “환불비용이 2천 원인데 5천 원으로 잘못 안내하는” 사례처럼 미묘한 오류는 치명적일 수 있으며, 단순한 고발적 모니터링으로는 포착이 어렵다. 따라서 LLM 트레이스를 기반으로 인풋/아웃풋을 재분석하여 의미적 불일치를 탐지하는 구조가 제안되었다.
예를 들어 “환불비용이 2천 원인데 5천 원으로 잘못 안내하는” 사례처럼 미묘한 오류는 치명적일 수 있으며, 단순한 고발적 모니터링으로는 포착이 어렵다. 따라서 LLM 트레이스를 기반으로 인풋/아웃풋을 재분석하여 의미적 불일치를 탐지하는 구조가 제안되었다.
운영은 실험과 개선의 루프로 완성된다
연사는 단순 모니터링을 넘어서 ‘실험과 반복’을 강조했다. 다양한 설정을 반복 테스트하고, 이를 통해 신뢰 가능한 응답 환경을 유지하는 것이 핵심이라는 메시지였다.
예를 들어 동일한 질문에 대해 온도(temperature), 토픽, 모델 종류 등을 바꿔가며 성능을 비교하고, 이를 기반으로 어떤 모델이 가장 ‘현실적으로 적합한가’를 시각화할 수 있는 기능이 공유되었다.
세션에서는 실제 실험 구조 예시와, 이를 시각적으로 통합 관리하는 대시보드도 함께 공개되었다.
또한 트레이스 로그 기반으로 버튼 하나로 플레이그라운드 테스트를 실행하고, 실험 결과를 기반으로 모델 혹은 설정을 실시간으로 조정할 수 있는 프로세스도 시연되었다.
이러한 실험 기반 구조는 단순한 모니터링을 넘어, 문제 발생 원인을 추적하고 그에 맞는 설정값이나 모델 조합을 반복적으로 검증할 수 있게 해준다. 특히 반복 실험을 통해 어떤 모델이 특정 주제에 더 적합한지, 비용 대비 성능이 어떤지에 대한 인사이트를 확보함으로써, Hallucination 현상도 점차 ‘모호한 현상’이 아닌 ‘측정 가능하고 개선 가능한 품질 요소’로 접근할 수 있게 된다.
예를 들어 동일한 질문에 대해 온도(temperature), 토픽, 모델 종류 등을 바꿔가며 성능을 비교하고, 이를 기반으로 어떤 모델이 가장 ‘현실적으로 적합한가’를 시각화할 수 있는 기능이 공유되었다.
세션에서는 실제 실험 구조 예시와, 이를 시각적으로 통합 관리하는 대시보드도 함께 공개되었다.
또한 트레이스 로그 기반으로 버튼 하나로 플레이그라운드 테스트를 실행하고, 실험 결과를 기반으로 모델 혹은 설정을 실시간으로 조정할 수 있는 프로세스도 시연되었다.
이러한 실험 기반 구조는 단순한 모니터링을 넘어, 문제 발생 원인을 추적하고 그에 맞는 설정값이나 모델 조합을 반복적으로 검증할 수 있게 해준다. 특히 반복 실험을 통해 어떤 모델이 특정 주제에 더 적합한지, 비용 대비 성능이 어떤지에 대한 인사이트를 확보함으로써, Hallucination 현상도 점차 ‘모호한 현상’이 아닌 ‘측정 가능하고 개선 가능한 품질 요소’로 접근할 수 있게 된다.
결론
이번 세션에서 강조된 가장 중요한 메시지는, 더 이상 “응답이 있으면 정상”이라는 관점으로는 LLM 시스템을 운영할 수 없다는 점이다. 겉으로 멀쩡해 보이지만 내부적으로 이상한 응답을 감지하는 능력, 그리고 그것을 개선 루프로 연결하는 설계야말로 차세대 AI 시스템 운영의 핵심이라는 점이 인상 깊게 전달되었다.
글 │메가존클라우드, Specialty Service Unit(SSU), AI Communication Service Team, 이민호 매니저
AWS SUMMIT 2025
전문가의 시선으로 정리된 테크 블로그를 통해
2025년 IT 트렌드의 현재와 미래를 살펴보세요.
테크 블로그 목차 (바로 가기→)
게시물 주소가 복사되었습니다.
![[AWS SUMMIT 2025] 클라우드를 위해 구축되고 AI에 최적화된: MongoDB Atlas on AWS](https://img.iting.co.kr/wp-content/uploads/2025/05/iting-event-bg-aws-summit-2025.png)
