I. 서론: 에이전트(Agent) 및 RAG 평가란 무엇인가

여러분이 구축한 시스템이 테스트 환경에서는 매우 잘 작동하다가, 프로덕션(Production) 환경에 배포하자마자 실패하는 상황을 경험해 본 적이 있나요?

매우 잘 작동하고, 정답을 제시하며, 심지어 평가(Evaluation)까지 통과했던 AI 에이전트(AI agent)를 만들었는데, 프로덕션에 적용하자마자 실패한 적이 있나요?

멀티 에이전트 시스템(Multi-agent system)에서 RAG를 구현했는데, 테스트에서는 잘 작동했음에도 불구하고 프로덕션에서는 추가된 RAG가 제대로 참조되거나 활용되지 않는 것을 발견하고 좌절한 적이 있나요?

프로덕션 환경에서 LLM(Large Language Model)이 신뢰할 수 없다는 점이 아무리 비용이 많이 들더라도, 다음과 같은 손실을 초래할 수 있습니다:

• 평판
• 비즈니스
• 시간
• 소중한 고객
• 그리고 법적 조치로 이어질 수도 있습니다

사람들은 여전히 평가를 수행할 때 단순히 느낌(Vibe check)으로 확인하거나, 약한 평가(Weak evaluations)를 수행하거나, 혹은 단순히 해피 패스(Happy path)만을 따르곤 합니다. 이는 LLM이 예측 가능한 답변을 내놓으며 테스트 환경에서는 매우 잘 작동하게 만들 수 있지만, 실제 세상에서는 실패하게 만들 수 있습니다. 그러한 실패가 발생했던 몇 가지 사례를 소개합니다.

II. AI 실패가 막대한 비용을 초래할 때: 실제 사례 연구

When AI Failures Get Expensive

작동하는 AI 에이전트(또는 "신뢰할 수 있는" 에이전트, LLM, 또는 RAG)조차 프로덕션 환경에서 비용이 많이 드는 상황으로부터 안전하지 않습니다. Moffatt v. Air Canada 사례에 대해 말씀드리겠습니다.

Air Canada는 주로 고객 서비스를 위해 LLM을 기반으로 구축된 시스템을 보유하고 있었습니다. Moffatt 씨의 어머니가 돌아가셨고, 어느 날 그가 비행기를 타려고 할 때 어머니의 유해를 어떻게 운송해야 하는지 물었습니다. LLM은 잘못된 답변을 제공했습니다. 그는 결국 항공사를 고소했고, 승소했습니다.

또 다른 시나리오: 한 변호사가 법정 사건을 준비할 때 ChatGPT를 참고 자료로 사용하고자 했습니다. ChatGPT가 제공한 참고 문헌과 판례는 부정확했으며 환각 (hallucinations)으로 가득 차 있었습니다. 결국 그 변호사는 5,000달러 이상의 벌금을 물게 되었습니다. 이와 같은 사례는 매우 많습니다. 제가 공유한 환각 관련 법적 사례 링크를 찾아보실 수 있으며, 다음 그래프를 확인해 보시기 바랍니다:

Refer to https://www.damiencharlotin.com/hallucinations/?graphs=1

Graph Example

III. 이 글의 약속

목적: 문제의 중요성을 설정하고 독자가 달성할 내용을 개괄합니다.

핵심 개념: 독자의 팀이 취약한 에이전트 프로토타입 (agent prototypes)을 구축하는 단계에서 벗어나, 자동화된 가드레일 (guardrails)을 갖춘 프로덕션급의 관찰 가능한 에이전트 시스템 (observable agentic systems)을 출시할 수 있도록 전환하는 것을 목표로 합니다.

그렇다면 이 글을 통해 제가 무엇을 약속할 수 있을까요? 몇 가지가 있습니다:

1. LLM 에이전트가 왜 환각을 일으키는지, 그리고 그것이 왜 비용 손실로 이어질 수 있는지 이해하기 시작할 것입니다.
2. 귀하가 소기업이든 대기업이든 관계없이, 신뢰할 수 있는 AI 에이전트를 구축하고 평가 (evaluations)를 실행할 수 있도록 단계별로 도와드리겠습니다.
3. LLM 평가 (LLM evaluation) 주제와 관련하여 사용할 수 있는 유능한 도구들과 학습할 수 있는 리소스들을 제공하겠습니다.

시작해 봅시다!

목적: 단일 LLM 출력 평가 (정적, static)와 자율 AI 에이전트 또는 RAG 파이프라인 평가 (동적, 다단계, 도구 사용, dynamic, multi-step, tool-using) 사이의 차이점을 정의합니다.

단일 LLM을 테스트하는 것은 가장 쉬운 일 중 하나입니다. 어떤 시나리오에서는 단순히 프롬프트 (prompts)를 개선하거나, 얻은 출력을 원하는 출력과 비교하는 것만으로 충분할 수도 있습니다. LLM은 단지 다음 토큰 예측기 (next-token predictor)일 뿐이기에 이는 관리 가능한 수준입니다.

멀티 에이전트 시스템 (multi-agent systems)이나 RAG를 테스트하는 것은 더 어렵습니다. 이들은 여러 단계를 거치며 동적이거나 심지어 자율적일 수 있기 때문입니다. 때로는 어떤 정확한 출력이 나올지, 혹은 무엇이 "원하는 (desired)" 출력이어야 하는지조차 알 수 없을 때가 있습니다. AI 에이전트나 RAG 시스템이 취할 수 있는 경로가 여러 개일 수 있으며, 이는 오늘날 복잡한 시스템 평가를 적절하고 신뢰성 있게 수행하는 것을 훨씬 더 어렵게 만듭니다. 하지만 제대로 테스트되고 평가된 시스템이나 하네스 (harness)를 갖추지 못했을 때 발생하는 결과가 이제는 훨씬 더 크기 때문에, 우리는 여전히 시도해야 한다고 생각합니다.

일반적인 실패 유형

a. 에이전트 로직 및 실행 실패 (Agentic logic and execution failures)

여기서 언급할 만한 세 가지 유형이 있습니다:

1. 무한 액션 루프 (Infinite action loop). 매우 흔한 사례입니다. 에이전트가 도구 (tool)를 계속 호출하지만 계속 에러가 발생하고, 동일한 실패 호출을 반복하며 토큰 예산 (token budget)을 낭비하는 상황입니다.
2. 타입 불일치 (Type mismatch). 도구의 파라미터 (parameters)가 예상대로 전송되지 않는 경우입니다. 예를 들어, 이메일 도구는 문자열 (string)을 기대하는데 계속 정수 (integer)가 들어오면, 애플리케이션이 완전히 충돌(hard-crash)하거나 계속 실패하게 됩니다. 이것이 운영 환경 (production)에서 발생한다고 상상해 보십시오.
3. 상태 비동기화 및 메모리 손실 (State desynchronization and memory loss). 복잡한 멀티 에이전트 워크플로 (multi-agent workflow)에서 에이전트가 프롬프트 (prompt)에 제대로 답변하는 데 필요한 중요한 컨텍스트 (context)를 놓치게 되어, 결국 원래의 전체 프롬프트를 무시한 채 사용자에게 모호하고 일반적인 답변을 제공하게 됩니다.

b. RAG 및 검색 실패 (RAG & retrieval failures)

가장 흔한 것은 "쓰레기가 들어가면 쓰레기가 나온다 (garbage in, garbage out)"입니다. 저급한 정보를 제공했거나, 부실한 청킹 전략 (chunking strategy)을 사용했거나, 좋지 않은 데이터를 입력한 경우입니다. 결과적으로 관련 없는 문서를 검색하게 되며, 때로는 모른다고 말하기도 합니다. 더 나쁜 것은, 당신이 기대한 것과 전혀 상관없는 답변을 아주 자신 있게 내놓는 것입니다.

예를 들어, 장례 정책 FAQ에 대한 답변을 제공하지만 잘못된 답변(환각 (hallucination))을 내놓는 경우가 있습니다. 이는 FAQ를 입력(ingested)했음에도 불구하고, 시스템에 적절하게 청킹(chunked)되고 검증(vetted)되지 않았기 때문입니다.

또 다른 흔한 사례는 "중간에서 길을 잃는 (lost-in-the-middle)" 효과입니다. 이는 프롬프트(prompt)를 비대하게 만드는 매우 큰 컨텍스트(context)를 제공했을 때 발생합니다. 이러한 거대한 컨텍스트 윈도우(context window)로 인해, 모델은 사용자의 실제 지침 중 일부를 단순히 무시하고 프롬프트의 맨 앞부분이나 맨 뒷부분에만 집중하게 됩니다. 당연히, 이는 앞뒤가 맞지 않는 답변으로 이어집니다.

c. 침묵하는 실패 (Silent failures)

이것은 최악의 시나리오에 해당하는 실패 유형입니다. 왜냐하면 특히 평가(evaluations)나 바이브 체크(vibe checks)를 수행할 때조차 이를 인지하지 못할 수도 있기 때문입니다. 시스템이 이미 프로덕션(production) 환경에서 한동안 운영되고 있었음에도 불구하고, 예를 들어 파워 유저가 문제를 겪고 나서야 비로소 눈에 띄게 됩니다. 전통적인 소프트웨어와 달리, 시스템이 요란하게 중단(break)되지 않습니다. 아마도 상태 코드 200(status 200)을 반환하며 모든 것이 완벽해 보일 것입니다.

에이전트(agent)는 모든 업데이트를 조용히 실행하지만, 어쩌면 DB에서 잘못된 고객 레코드를 업데이트하고 있을지도 모릅니다. 또 다른 시나리오로는, A에게 이메일을 보내야 하는데 관련 없는 잠재 고객인 B에게 보내는 경우입니다. 이것이 바로 포착하기 가장 어려운 침묵하는 실패입니다. 시스템은 여전히 "작동"하고 있기 때문입니다. 여전히 전송하고 있고, 여전히 업데이트하고 있습니다. 단지 잘못된 데이터를 대상으로 수행하고 있을 뿐입니다.

IV. 심층 분석: AI 에이전트가 실패하는 원인

목적: 에이전트 실패의 아키텍처적 근본 원인을 설명합니다.

핵심 개념:

• 인식론적 모호성 (Epistemic ambiguity): 에이전트가 시스템 컨텍스트에 대해 자신이 무엇을 모르는지 알지 못하면서도 일단 실행을 진행하는 현상입니다.
• 눈덩이처럼 불어나는 환각 및 계획 실패 (Snowballing hallucinations & planning failures): 사고/행동/관찰 (Thought/Action/Observation, ReAct) 루프 과정에서 초기에 저지른 실수를 그대로 고수하는 것입니다.
• 검색 실패 (Retrieval failures, RAG): 에이전트가 잘못된 벡터 데이터(vector data)를 가져와서, 결국 환각이 섞인 최종 응답을 생성하게 되는 경우입니다.

프로덕션 환경에서 AI 시스템을 실패하게 만드는 문제들

요약:

1. 테스트를 전혀 하지 않음
2. 테스트를 하지만, 해피 패스 (happy path)만 테스트함
3. 평가 테스트는 통과하지만 프로덕션에서 실패함
4. 지속적인 평가 파이프라인 (continuous eval pipeline)이 없음

각 항목에 대해 자세히 설명하겠습니다. 우선 아예 테스트를 하지 않는 경우부터 시작하겠습니다.

**아예 테스트를 하지 않음 (Not testing at all)**이 반드시 테스트를 전혀 하지 않는다는 의미는 아닙니다. 대부분의 AI 엔지니어들(적어도 제가 접해온 엔지니어의 90% 이상)은 모든 것이 제대로 작동하게 만드는 데 대부분의 노력을 기울이며, 테스트에는 아주 적은 시간, 아마도 10% 이하의 시간만을 할애합니다. 대신 그들이 보통 하는 방식은 '바이브 체크 (vibe check)'입니다. 대략 10~20개의 프롬프트 (prompt)를 던져보고 시스템이 출력을 생성하는지만 확인하는 것입니다. 때로는 그 출력의 품질조차 확인하지 않기도 합니다.

• 공정 (fair)한가?
• 법적 책임 (liable)의 소지가 있는가?
• 프롬프트 (prompt)를 따르고 있는가?
• 누군가가 그 응답을 점수화 (scoring)하고 있는가?

**해피 패스 (The happy path)**는 실제로 테스트가 이루어지는 단계이지만, 오직 해피 패스 테스트뿐입니다. 엣지 케이스 (edge cases)도 없고, 레드 티밍 (red teaming)도 수행되지 않으며, 질문들이 적대적 (adversarial)이지도 않습니다. 모든 것이 매우 쉽습니다. "내 이름이 뭐야?" 또는 "X는 무엇인가?"와 같은 예측 가능한 것들 말입니다. 해피 패스는 항상 통과할 것이며, 프로덕션 (production)에서 엣지 케이스가 나타날 때 비로소 사람들은 패닉에 빠집니다.

평가 (evals)는 통과하지만 프로덕션에서 여전히 실패함은 가장 무서운 경우입니다. 왜냐하면 이 단계는 과거에 공을 들여 적절한 평가를 수행했음에도 불구하고 발생하는 문제이기 때문입니다. 그런데 왜 여전히 실패할까요? 바로 이 지점에서 대부분의 AI 엔지니어들이 허점을 보입니다. 몇 가지 이유는 다음과 같습니다:

1. 우리가 올바른 것을 보고 있지 않을 수도 있습니다. 우리는 단지 최종 출력물(final output)만을 보고 있을지도 모릅니다. 만약 그것이 AI 에이전트(AI agent)라면, 해당 답변에 도달하기 위해 올바른 단계들을 따랐는지도 확인해야 합니다. "정확함(Correct)"과 "수용 가능함(acceptable)"은 서로 다른 의미일 수 있습니다. 이것이 제가 말하는 '정답으로 가는 잘못된 경로(wrong-path-to-right-answer)' 문제입니다. 즉, 정답은 맞혔지만 잘못된 과정을 거친 것입니다. 예를 들어, 날씨 애플리케이션에서 에이전트가 날씨 API를 사용하는 대신, 답변을 환각(hallucinate)하거나 샌프란시스코의 날씨를 "찾기" 위해 완전히 다른 도구를 사용할 수도 있습니다. 교차 검증(cross-checking) 없이는 에이전트가 제대로 작동하고 있다고 가정하게 될 것입니다. 이것은 지름길 행동(shortcut behavior)입니다. 적절한 추론(reasoning)과 올바른 단계 없이도 여전히 정답을 만들어낼 수 있습니다. 문제는 에이전트가 당신이 실제로 사용하기를 원했던 도구를 일관되게 사용하지 않기 때문에, 항상 정답을 만들어내지는 않을 것이라는 점입니다.

weather in San Francisco

1. 에이전트가 필수 단계를 건너뜁니다. 에이전트가 반드시 따라야 하는 단계들이 있을 수 있습니다. 예를 들어, 잠재 고객(prospect)이나 리드(lead)에게 이메일을 보내기 전에 다음과 같은 과정을 거치기를 원할 수 있습니다:
   1. 해당 잠재 고객에 대한 세부 정보를 찾습니다.
   2. 해당 잠재 고객의 프로필을 가져오는 함수(function)를 호출합니다.
   3. 이메일을 초안 작성하고 전송하는 프롬프트(prompt)를 사용합니다.
   4. 전송 후, 잠재 고객이 "리드(lead)"에서 "아웃바운드 리드(outbound lead)"로 이동하도록 파이프라인(pipeline)을 업데이트합니다.

문제는 에이전트가 이메일을 보내고 다른 모든 것을 업데이트할 수는 있지만, 정작 먼저 잠재 고객의 세부 정보를 찾는 단계를 건너뛸 수 있다는 점입니다. 결과적으로 불완전한 컨텍스트(context)를 바탕으로 작업을 수행하게 됩니다. 만약 당신이 새로운 잠재 고객을 확보하는 비즈니스를 하고 있다면, 이는 비즈니스에 큰 손실을 초래할 수 있습니다.

1. 높은 확신을 가진 오답 (The high-confidence wrong answer). 이는 에이전트(Agent)가 매우 확신에 차 있지만, 완전히 틀린 답을 내놓는 경우를 말합니다. 이는 RAG (Retrieval-Augmented Generation)와 직결됩니다. 만약 데이터를 적절하게 청킹 (Chunking) 하지 않았다면, 검색기 (Retriever)는 여전히 문서를 가져올 수 있고, 에이전트는 그 문서들이 프롬프트 (Prompt)와 관련이 없음에도 불구하고 관련이 있다고 판단할 수 있습니다. 모든 것이 정상적으로 작동하는 것처럼 보이지만, 정답은 틀린 상태입니다. 예를 들어, 자동차 보험과 소액 대출 등 서로 다른 제품에 대한 FAQ 문서가 있는 대규모 조직에서 소액 대출 문서만 제대로 청킹 및 인덱싱 (Indexing) 되었다고 가정해 봅시다. 이 모든 엔티티 (Entity)를 동시에 다루는 고객 서비스 에이전트는 장례 보험에 대해 묻는 고객에게 매우 확신에 찬 태도로 잘못된 답변을 제공할 수 있습니다.

V. 에이전트 및 RAG를 다루기 위한 이상적인 워크플로우 (The Ideal Workflow for Dealing with Agents and RAG)

이것은 단순히 느낌으로 확인하는 '바이브 체크 (Vibe-checking)'를 멈추고, 당신의 AI 프로젝트를 취미 수준에서 벗어나 실제 프로덕션 (Production) 환경에서 실질적인 영향력을 발휘하며 높은 신뢰성을 갖춘 솔루션으로 전환하고자 할 때 사용할 워크플로우입니다.