드리프트에서 신뢰성으로: AI 에이전트를 위한 지속적 평가(Continuous Evaluation) 파이프라인 구축
날짜
June 25th, 2026
소요 시간
7분
최신 소식
AI 에이전트의 실패는 대개 조용히 찾아옵니다.
어느 날까지는 고객 문의에 정확하고 자신감 있게 답변하던 에이전트가, 몇 주 뒤에는 근거가 부족한 답변을 하거나 도구를 일관성 없이 사용하기 시작할 수 있습니다. 제품 경험에 맞지 않는 어조를 사용하는 경우도 있습니다.
전통적인 소프트웨어 개발에서는 이러한 문제를 해결하기 위한 검증된 방법이 존재합니다. 바로 Continuous Integration(CI)입니다. 코드가 변경될 때마다 자동 테스트를 수행하여 회귀(regression)를 사전에 발견하고, 문제가 있는 변경 사항이 프로덕션 환경으로 배포되는 것을 방지합니다.
하지만 AI 에이전트는 일반적인 소프트웨어 컴포넌트와 다릅니다. AI 에이전트는 자연어를 생성하고, 확률적으로 의사결정을 내리며, 상황에 따라 동적으로 도구를 호출합니다. 따라서 단순한 단위 테스트만으로는 답변이 정확한지, 안전한지, 유용한지, 혹은 단지 표현만 다른 것인지를 판단하기 어렵습니다.
AI 에이전트를 안정적으로 운영하고 확장하기 위해서는 새로운 엔지니어링 접근 방식이 필요합니다. 그것이 바로 **지속적 평가(Continuous Evaluation - CE)**입니다.
CI가 "코드가 여전히 정상적으로 동작하는가?"를 묻는다면, CE은 다음과 같은 질문을 던집니다.
"AI 에이전트는 실제 환경에서도 여전히 신뢰할 수 있고, 올바르며, 안전하게 동작하는가?"
더 알아보기: AI 에이전트는 왜 시간이 지날수록 신뢰성이 떨어질까?
왜 AI 에이전트에는 기존 CI만으로 부족할까?
기존의 CI가 효과적인 이유는 대부분의 소프트웨어가 결정론적이기 때문입니다. 함수에 동일한 입력을 주면 항상 동일한 출력이 반환되어야 합니다. 유닛 테스트는 1 + 1은 2라거나, API가 특정 상태 코드를 반환한다는 점을 확언(assert)할 수 있으며, 테스트는 **‘통과’**하거나 **‘실패’**할 뿐입니다.
하지만 AI 에이전트는 다르게 작동합니다. 동일한 사용자 질문에 대해 표현이 다른 두 가지 유효한 답변을 생성할 수 있습니다. 정확히 일치하는지 확인하는 단언문은 지나치게 취약합니다. 정중하고 자신감 넘치게 들리는 미묘한 환각(hallucination) 현상은 놓치면서, 올바른 답변을 실패로 처리할 수 있기 때문입니다.
그래서 많은 조직은 여전히 "감(感)에 의존한 테스트(Vibe Check)"를 수행합니다. 배포 전에 몇 개의 프롬프트를 직접 입력해 보고, 응답을 살펴본 뒤 "괜찮아 보인다"고 판단하는 방식입니다. 프로토타입 단계에서는 통할지 몰라도 실운영 환경에서는 무너집니다.
AI 에이전트를 테스트할 수 없다는 것이 아닙니다. 확률적 행동에 맞추어 설계된 테스트가 필요하다는 점입니다. 출력이 하나의 고정된 문자열과 일치하는지 묻는 대신, 출력이 정의된 품질 기준을 충족하는지 평가해야 합니다.
지속적 평가의 두 가지 핵심 기둥
실용적인 지속적 평가 파이프라인은 두 가지 기반 위에 세워집니다. 바로 **'골든 데이터셋’**과 자동화된 채점 메커니즘 - LLM-as-a-Judge입니다. 이 두 가지가 결합될 때, 팀은 주관적인 수동 검토에서 벗어나 반복 가능한 평가 게이트로 나아갈 수 있습니다.
1. 골든 데이터셋
골든 데이터셋은 에이전트가 처리해야 하는 가장 중요한 시나리오를 모아둔 정제된 테스트 세트입니다.
입력 프롬프트, 예상되는 맥락, 이상적인 출력, 수용 기준 및 에지 케이스가 포함됩니다. 기업용 지식 에이전트의 경우 사실 관계 질문, 멀티홉 추론(multi-hop reasoning) 작업, 오래된 문서 함정, 컴플라이언스(규정 준수)에 민감한 질의 등이 포함될 수 있습니다.
가장 훌륭한 골든 데이터셋은 실제 실패 모드를 바탕으로 구축됩니다. 프로덕션 로그, 지원 티켓, 사람의 검토 메모, 사용자 피드백에서부터 시작하세요. 그 다음 강력한 프런티어 모델이 생성한 합성 데이터를 추가하여 드물지만 위험성이 높은 상호작용을 시뮬레이션함으로써 데이터셋을 풍부하게 만듭니다.
목표는 모든 가능한 프롬프트를 테스트하는 것이 아닙니다. 가장 중요하고, 비용이 많이 들고, 위험하거나 에이전트가 잘못 처리하기 쉬운 프롬프트를 테스트하는 것입니다.
2. LLM-as-a-Judge
에이전트의 출력은 대개 개방형이기 때문에 하드코딩된 단언문만으로는 부족합니다. LLM-as-a-Judge는 역량 있는 모델을 활용하여 명확한 루브릭(평가 기준)에 따라 출력을 채점합니다. 답변이 참조 답변과 정확히 일치하는지 묻는 대신, 평가자는 다음과 같은 품질 기준을 충족하는지 평가합니다.
-
충실도: 답변이 제공된 맥락에 근거하고 있는가, 아니면 근거 없는 주장을 도입(환각)하고 있는가?
-
답변 관련성: 답변이 사용자의 실제 의도를 다루고 있는가?
-
작업 완료도: 에이전트가 요청된 워크플로우를 완료했는가, 아니면 너무 일찍 중단했는가?
-
도구 사용 정확성: 에이전트가 올바른 파라미터로 올바른 도구를 호출했는가?
-
안전성 및 가드레일: 에이전트가 프롬프트 인젝션에 저항하고, 시스템 지침 유출을 방지하며, 정책 경계 내에 머물렀는가?
물론 평가 모델을 무조건 신뢰해서는 안 됩니다. 명확한 평가 기, 안정적인 예시 데이터, 적절한 임계값, 그리고 주기적인 사람의 검토가 함께 이루어져야 합니다.
또한 평가 모델 역시 버전 관리(Versioning)하는 것이 좋습니다. 그렇지 않으면 평가 시스템 자체가 새로운 드리프트의 원인이 될 수 있습니다.
AI 네이티브 CE 파이프라인은 어떻게 구성될까?
지속적 평가 파이프라인은 이미 CI/CD를 사용하고 있는 엔지니어링 팀에게 매우 친숙하게 느껴질 것입니다.
여기서 CD는 지속적 배포(Continuous Deployment)를 의미하며, 검증된 변경 사항을 사용자나 실운영 환경에 자동으로 출시하는 관행입니다. 차이점은 이 파이프라인이 코드의 정확성뿐만 아니라 행동을 평가한다는 점입니다.
Step 1: 변경 감지 (트리거)
지속적 평가 파이프라인은 무언가 변경될 때 시작됩니다. 개발자가 시스템 프롬프트를 수정하거나, 에이전트 코드를 업데이트하거나, 검색 전략을 변경하거나, 도구 스키마를 수정하거나, 지식 베이스를 새로 고치는 경우입니다. 이러한 변경 사항은 모두 에이전트의 행동을 바꿀 수 있으므로 배포 전에 반드시 평가를 트리거해야 합니다.
Step 2: 테스트 실행
CI 파이프라인은 새로운 에이전트 버전을 구동하고 이를 골든 데이터셋에 대해 실행합니다. 각 테스트 케이스는 최종 답변뿐만 아니라 검색된 문서, 도구 호출, 사용 가능한 경우 추론 단계, 지연 시간, 토큰 사용량 및 정책 플래그와 같은 중간 실행 정보를 모두 수집해야 합니다.
Step 3: 평가
Ragas, DeepEval, TruLens, LangSmith, Promptfoo, MLflow와 같은 평가 프레임워크를 사용하면 충실도, 관련성, 환각 위험, 도구 사용 품질, 대화 수준 성능 등의 다양한 차원에서 에이전트의 행동을 채점할 수 있습니다.
예를 들어, Ragas는 RAG 특화 평가에 자주 사용되며, DeepEval은 개발자 친화적인 CI 스타일 테스트로 인기가 높습니다. TruLens는 평가와 트레이싱(추적)을 결합하고, LangSmith는 LangChain 또는 LangGraph 기반 애플리케이션에서 흔히 사용됩니다.
핵심은 단 하나의 총점에만 의존하지 않는 것입니다. 평균 통과 점수 뒤에 치명적인 안전성 실패가 숨겨져 있을 수 있습니다. 성숙한 파이프라인은 여러 차원을 독립적으로 평가하고 카테고리별로 성능 저하를 보고합니다.
Step 4: 게이트 (배포 결정)
마지막으로 파이프라인은 평가 결과를 사전에 정의된 임계값과 비교합니다. 예를 들어, 팀은 충실도 0.85 이상, 답변 관련성 0.80 이상, 도구 사용 정확성 0.90 이상 및 치명적인 안전 위반 제로(0)를 요구할 수 있습니다. 새로운 버전이 이 기준을 통과하면 변경 사항을 병합(merge) 및 배포할 수 있습니다. 만약 점수가 임계값 미만으로 떨어지면 파이프라인은 배포를 차단하고 팀에 알림을 보냅니다.
LLM 출력은 확률적이기 때문에 임계값은 신중하게 설계되어야 합니다. 목적은 파이프라인을 불안정하게 만드는 것이 아니라 의미 있는 성능 저하를 잡아내는 것입니다.
지속적 평가(CE)와 AgentOps의 관계
CE와 AgentOps는 밀접하게 연결되어 있지만 서로 다른 역할을 담당합니다. CE는 배포 이전을 담당하고, AgentOps는 배포 이후를 담당합니다.
CE가 답하는 질문은 다음과 같습니다.
-
프롬프트 변경이 환각을 줄였는가?
-
새로운 검색 전략이 관련성을 높였는가?
-
모델 업데이트 이후에도 컴플라이언스를 유지하는가?
반면 AgentOps는 다음 질문에 답합니다.
-
실제 사용자들은 에이전트를 어떻게 사용하고 있는가?
-
어떤 시나리오에서 실패가 발생하는가?
-
어떤 대화가 부정적인 평가를 받고 있는가?
-
어떤 도구 호출이 실패하고 있는가?
-
비용과 지연 시간이 어디서 증가하고 있는가?
가장 이상적인 구조는 두 시스템을 하나의 피드백 루프로 연결하는 것입니다.
운영 환경에서 발견된 실패 사례를 ‘골든 데이터셋’에 추가하고, 다음 배포부터는 자동 평가 대상에 포함시키는 것입니다. 이렇게 하면 운영 중 발생한 문제를 단순한 사고가 아닌 영구적인 보호 장치로 전환할 수 있습니다.
시간이 지날수록 골든 데이터셋은 에이전트가 경험한 위험 요소를 축적한 지식 저장소가 됩니다.
더 알아보기: AI 에이전트가 실패하지 않으려면 - AgentOps 도입 완전 가이드
엔지니어링 팀을 위한 실무 체크리스트
-
프롬프트를 코드처럼 취급하세요. 버전을 관리하고, 리뷰하고, 테스트하며, 배포 전에 안전하지 않은 변경 사항을 차단하세요.
-
작은 골든 데이터셋부터 시작하세요. 수백 개의 모호한 프롬프트보다 위험성이 높은 50개의 집중된 테스트 케이스가 훨씬 더 유용합니다.
-
다차원적으로 평가하세요. 충실도, 관련성, 도구 사용, 안전성, 지연 시간, 비용을 독립적으로 추적하세요.
-
LLM 평가자를 신중하게 사용하세요. 루브릭을 정의하고, 가능한 경우 평가자 버전을 고정하며, 인간의 검토를 통해 정기적으로 보정하세요.
-
에이전트옵스로 루프를 닫으세요. 실운영 환경의 실패를 새로운 평가 케이스로 변환하여 동일한 문제가 조용히 재발하지 않도록 하세요.
결론: 신뢰성은 하나의 엔지니어링 시스템입니다
시간이 지나도 AI 에이전트의 신뢰성을 유지하는 것은 운에 맡길 일이 아닙니다. 기존 CI/CD의 엄격한 엔지니어링 규율을 확률적인 AI 세계로 가져와야 합니다. 지속적 평가(CE)는 팀에게 그러한 시스템을 제공합니다.
이러한 전환은 단순하지만 깊은 의미를 지닙니다. "데모가 여전히 잘 작동하는가?"라고 묻지 마세요. "가장 중요한 시나리오 전반에서 에이전트가 정의된 기준을 여전히 충족하는가?"라고 질문해야 합니다.
드리프트에서 신뢰성으로, 이것이 바로 AI 에이전트가 프로토타입에 머물지 않고 실제 프로덕션 시스템으로 진화하는 방식입니다.
여러분의 팀은 현재 실운영 배포 전에 AI 에이전트를 어떻게 테스트하고 계신가요?
자주 묻는 질문 (FAQ)
Q: AI 에이전트를 위한 지속적 평가(Continuous Evaluation)란 무엇인가요?
A: 지속적 평가는 유의미한 변경이 발생할 때마다 AI 에이전트의 행동을 자동으로 테스트하고 측정하는 관행입니다. 단순한 통과/실패 출력 위주의 기존 소프트웨어 테스트와 달리 충실도, 관련성, 도구 사용 정확성, 작업 완료도, 안전성과 같은 행동 품질 지표에 초점을 맞춥니다.
Q: 골든 데이터셋이란 무엇인가요?
A: 골든 데이터셋은 AI 에이전트가 처리해야 하는 가장 중요한 시나리오를 나타내는 정제된 테스트 케이스 모음입니다. 여기에는 일반적인 사용자 요청, 에지 케이스, 과거의 실패 사례, 안전 위협 요소 및 고위험 워크플로우가 포함됩니다. 골든 데이터셋은 반복 가능하고 신뢰할 수 있는 에이전트 평가의 기반 역할을 합니다.
Q: LLM-as-a-Judge란 무엇인가요?
A: LLM-as-a-Judge는 우수한 역량을 가진 언어 모델이 구조화된 채점 루브릭을 사용하여 다른 모델의 출력을 미리 정의된 기준에 따라 평가하는 방식입니다. 정답과 정확히 일치하는지 확인하는 대신, 사실 관계의 정확성, 관련성, 충실도, 작업 완료도, 안전성 등의 차원을 평가합니다.
Q: 지속적 평가가 기존의 CI/CD 파이프라인을 대체하나요?
A: 아닙니다. CE는 기존 CI/CD를 확장하는 개념입니다. CI/CD가 코드 품질과 시스템 안정성을 검증한다면, CE는 AI 에이전트의 행동 품질을 검증합니다.
Q: 지속적 평가가 사람의 검토를 대체하나요?
A: 아닙니다. 자동 평가를 통해 수작업을 크게 줄일 수 있지만, 평가 기준 조정과 중요한 워크플로우 검증을 위해서는 여전히 사람의 검토가 필요합니다.
Q: 지속적 평가와 AgentOps의 관계는 무엇인가요?
A: CE는 배포 전 검증을 담당하고, AgentOps는 배포 후 모니터링과 최적화를 담당합니다. 두 시스템을 연결하면 운영 환경의 실패 사례를 평가 데이터셋으로 재활용하여 지속적으로 에이전트를 개선할 수 있습니다.
Newsletter
더 보기
![[Recap] UPP Global Technology JSC Establishing Anniversary](/homepage/news-section/new-4.webp)
대화하기
원하신 정보를 이메일로 보내드립니다
이메일을 입력해 주세요
원하시는 내용을 입력해 주세요
Hanoi, Vietnam
Web3 Tower, No. 15, Alley 4, Duy Tan, Cau Giay, Hanoi, Vietnam