지원 에이전트가 사용자의 2단계 인증 재설정 요청에 대해 존재하지도 않는 단계들을 안내하며 답변했습니다. 답변은 확신에 찬 것처럼 보였고, HTTP 요청은 200 OK를 반환했으며, 지연 시간은 정상이었고 모든 모니터링 차트는 초록색을 유지했습니다.

AI 기반 지원 에이전트가 환각(hallucination) 현상을 일으킨 이유는 오류를 잡아냈어야 할 내부 체크가 전혀 실행되지 않았기 때문입니다. 엔지니어들이 신뢰하는 대시보드는 완벽한 실행을 보고했지만, 에이전트는 조용히 허구의 해결책을 만들어내고 있었습니다.

기존 대시보드가 AI 환각을 놓치는 이유

대부분의 관측성(observability) 스택은 AI 에이전트를 다른 마이크로서비스와 동일하게 취급합니다. 즉, 단일 인바운드 요청과 단일 아웃바운드 응답으로 보는 것입니다. 이들은 HTTP 상태, 응답 시간, 에러 횟수를 기록합니다. 하지만 요청 내부의 숨겨진 단계들 — 외부 문서 검색(retrieval), 대규모 언어 모델(LLM) 호출, 보조 도구 사용, 그리고 출력을 검증하는 가드레일(guard-rail) 로직 등 — 은 기록하지 않습니다.

검색 단계에서 빈 결과가 반환되면, 모델은 종종 그 공백을 그럴듯하게 들리는 텍스트로 "채워 넣습니다". 모니터링 시스템 관점에서는 아무런 충돌이 발생하지 않았고 상태 코드가 200을 유지했으므로 호출이 성공한 것으로 간주됩니다. 환각은 보이지 않는 상태로 남으며, 유일한 증상은 사용자에게 잘못된 답변이 전달되는 것뿐입니다.

블랙박스를 읽기 쉬운 트리 구조로 전환하기

신뢰할 수 있는 디버깅을 위한 첫 번째 단계는 에이전트를 단일 호출(monolithic call)로 취급하는 것을 멈추고, 각 내부 작업을 트레이스 테이블(trace table)의 개별 행으로 시각화하는 것입니다. 일반적인 실행 과정은 다음과 같이 나뉩니다:

  • 최상위 에이전트 호출
  • 관련 문서를 가져오는 검색 단계
  • 검색된 데이터를 처리하는 모든 언어 모델 추론
  • 각 도구 호출 (예: 데이터베이스 조회, API 요청)
  • 사실 관계나 정책 준수를 강제하는 가드레일 체크

각 행에는 타임스탬프, 성공 여부 플래그, 해당 단계를 통과한 페이로드(payload)가 기록됩니다. 이러한 구조를 통해 실행 과정은 최종 출력값만 보고 추측하는 대신, 한 줄씩 검사할 수 있는 트리 구조가 됩니다.

놓쳐버린 버그

문제가 된 지원 상호작용의 트레이스는 다음과 같았습니다:

  1. **검색(Retrieval)**이 실행되었으나 문서가 반환되지 않았습니다.
  2. 다음 단계가 그대로 진행되어 모델에 빈 컨텍스트(context)를 전달했습니다.
  3. 모델은 누락된 정보를 지어낸 단계들로 채워 답변을 생성했습니다.
  4. 파이프라인에서 예외(exception)가 발생하지 않았기 때문에 시스템은 200을 반환했습니다.

환각은 언어 모델 자체의 결함이 아니었습니다. 검색 단계와 생성 단계 사이에 가드레일이 없었던 것이 문제였습니다. 에이전트는 답변의 근거로 삼을 정보가 전혀 없음에도 불구하고 답변을 해버린 것입니다.

환각을 방지하는 간단한 가드레일

두 가지 구체적인 변경을 통해 문제를 해결했습니다:

  • 빈 검색 시 중단(Abort on empty retrieval) – 문서 저장소에서 아무것도 반환되지 않으면, 에이전트는 생성 단계로 넘어가는 대신 "필요하신 정보를 찾을 수 없습니다"라고 답변해야 합니다.
  • 근거 확인(Grounding check) – 모델이 응답을 생성한 후, 모든 사실적 주장이 검색된 내용에 포함되어 있는지 확인합니다. 확인에 실패하면 답변을 거부하고 "답변할 수 없습니다"라는 응답으로 대체합니다.

빠른 디버깅을 위한 실무 워크플로우

  1. 모든 내부 호출을 트레이스(Trace) 하세요 – 각 검색, 모델 추론, 도구 사용이 영구 로그에 한 행씩 기록되도록 에이전트를 구성하십시오.
  2. 실패한 실행 기록을 보존하세요 – 사용자가 잘못되었다고 보고한 모든 상호작용의 전체 트레이스를 저장하십시오. 저장 공간을 아끼기 위해 이를 삭제하면 회귀(regression)를 찾는 데 필요한 데이터를 숨기게 됩니다.
  3. 버전 정보로 실행 기록에 태그를 다세요 – 각 트레이스 행에 릴리스 식별자와 기능 플래그(feature-flag) 상태를 포함하십시오. 이를 통해 새로운 버그를 최근의 코드 변경 사항과 연관 지을 수 있습니다.
  4. 속도뿐만 아니라 품질을 측정하세요 – 답변이 지침을 얼마나 잘 따르는지, 검색된 내용에 얼마나 충실한지(grounded) 측정하는 메트릭을 추가하십시오. 답변이 틀리다면 처리량이 높은 것은 의미가 없습니다.
  5. 실패 사례를 매일 검토하세요 – 저장된 실패 사례를 짧고 정기적으로 검토하면, 많은 사용자에게 영향을 미치기 전에 특정 패턴(예: 특정 유형의 쿼리가 지속적으로 빈 검색 결과를 반환함)을 발견할 수 있습니다.

"초록색(정상)"을 "검증됨(verified)"으로 전환함으로써, 팀은 환각을 조기에 발견하고 사용자 경험의 신뢰성을 유지할 수 있습니다.

내부 실패를 무시할 때 치르는 대가

대시보드가 HTTP 계층에서의 성공만 보고할 때, 기업은 겉으로는 신뢰할 수 있어 보이지만 정기적으로 잘못된 안내를 제공하는 에이전트를 배포하게 됩니다.

다음에 살펴볼 내용

그것들이 보편화되기 전까지는, 모든 내부 작업을 관찰 가능한 상태로 취급하고 증거가 부족할 때 즉시 실패(fail fast) 처리하는 것이 가장 안전한 접근 방식입니다.

핵심 요약: 대시보드가 초록색이라는 것은 시스템의 기반 구조가 잘 작동하고 있음을 의미할 뿐, 답변이 정확하다는 것을 보장하지는 않습니다. 각 검색, 모델 호출, 가드레일 체크를 추적함으로써, 숨겨진 환각 현상을 사용자에게 도달하기 전에 수정할 수 있는 가시적인 실패로 전환할 수 있습니다.