Samsung SDS

이 글은 IDG의 아티클을 전재하여 제공합니다.
[원문보기]

가장 앞선 기술이 가장 설명하기 어려운 기술이라는 역설이 있습니다. LLM이 그렇습니다. 모델을 직접 만드는 개발자들조차 윈스턴 처칠의 표현을 빌려 LLM을 '수수께끼 속에 감춰진 미스터리, 그 안의 불가해한 존재(a riddle, wrapped in a mystery, inside an enigma)'에 빗대곤 합니다. 수천억 개에 달하는 가중치가 서로 영향을 주며 만들어내는 결과를 사람이 직관적으로 이해하기란 사실상 불가능에 가깝습니다.

문제는 기업이 바로 이 불가해한 존재에 실제 업무를 맡기기 시작했다는 점입니다. 에이전트형 AI(Agentic AI)는 질문에 답하는 수준을 넘어 스스로 계획을 세우고, 필요한 도구를 호출하고, 여러 단계를 거쳐 목표를 수행합니다. 자율성이 커질수록 자연스럽게 따라오는 질문이 있습니다. "지금 제대로 일하고 있는가?"

사람에게 업무를 맡길 때는 목표와 평가 기준을 정하고 결과를 확인하며 피드백을 제공합니다. 하지만 사람보다 행동을 예측하기 어려운 AI 에이전트는 제대로 된 검증 체계 없이 업무에 투입되는 경우가 적지 않습니다.

이 공백을 메우는 분야가 평가 및 벤치마킹(Evaluation and Benchmarking)입니다. 성능과 실행 상태를 추적하는 에이전트옵스(AgentOps)·옵저버빌리티(Observability), 응답의 신뢰성과 안전성을 관리하는 트러스트 및 가드레일(Trust and Guardrails)과도 맞닿아 있습니다. 아직 시장의 경계가 뚜렷하지 않고 각 제품이 빠르게 인접 영역으로 확장되고 있어 앞으로도 경쟁 구도는 계속 달라질 전망입니다.

현재 주목할 만한 13가지 도구를 역할에 따라 ① 실행 추적과 가시성, ② 지속적인 테스트와 벤치마킹, ③ 시뮬레이션과 협업 평가, ④ RAG와 보안 검증이라는 네 가지 영역으로 나눠 살펴봅니다.

1. 보이지 않는 실패는 고칠 수도 없습니다 - 실행 추적과 가시성

에이전트 검증의 출발점은 정답을 확인하는 것이 아니라 실패를 보이게 만드는 것입니다. 최종 결과가 잘못됐다는 사실만 알아서는 부족합니다. 어느 단계에서 판단이 어긋났는지, 어떤 도구 호출이 문제였는지, 컨텍스트가 어디서 변질됐는지를 확인할 수 있어야 수정할 수 있습니다.

브레인트러스트(Braintrust)는 '모든 것을 추적한다(trace everything)'는 접근 아래 대규모 사용자를 상대하는 엔터프라이즈 환경에서 응답 실패를 분석하는 데 필요한 데이터를 확보합니다. 통합 대시보드에서 지연 시간, 비용, 품질의 이상 징후를 확인할 수 있고 자동화된 평가를 통해 에이전트 스택이 실제 사용자 요구를 충족하고 있는지를 측정합니다.

특히 '루프 에이전트(Loop Agent)'는 여러 차례 반복되는 실행 과정을 추적해 문제가 발생한 지점을 깊이 파고들 수 있도록 지원합니다. 단순히 '틀린 답을 했다'는 사실을 넘어 왜 그런 결과에 도달했는지를 확인하려는 조직에 적합합니다.

랭스미스(LangSmith)는 추적 범위를 에이전트 내부로 한 단계 더 확장합니다. 입력과 출력뿐 아니라 에이전트가 거친 단계와 그 과정에서 변화한 컨텍스트까지 기록합니다. 복잡한 에이전트 그래프에서 지연이나 품질 저하가 어느 단계, 어떤 메커니즘에서 시작됐는지를 찾아내는 데 유용합니다. 파이썬, 고(Go), 자바, 타입스크립트와 연동되며 랭체인(LangChain) 생태계를 활용하는 팀이라면 자연스럽게 검토할 수 있는 선택지입니다.

랭퓨즈(Langfuse)는 '어떤 조합이 가장 좋은가'라는 질문에 초점을 맞춥니다. 같은 프롬프트를 여러 모델에 적용하고 결과를 비교하는 일은 에이전트가 복잡해질수록 관리하기 어려워집니다. 랭퓨즈는 프롬프트와 추적 정보, 응답을 팀 단위로 관리하면서 이러한 평가 루프를 체계화합니다. 오픈텔레메트리(OpenTelemetry)를 지원해 다양한 시스템과 연결할 수 있다는 점도 특징입니다.

세 도구의 공통점은 AI 에이전트를 블랙박스 상태로 운영하지 않도록 만드는 것입니다. 에이전트의 자율성이 커질수록 결과만 확인하는 방식으로는 원인을 찾기 어렵습니다. 실행 과정을 관찰할 수 있는 능력이 곧 품질 관리의 출발점이 됩니다.

2. 어제 합격한 AI가 오늘도 합격한다는 보장은 없습니다 - 지속적 테스트와 벤치마킹

LLM 검증이 일회성 시험으로 끝날 수 없는 이유는 모델의 행동이 고정돼 있지 않기 때문입니다. 소프트웨어가 변경될 때마다 단위 테스트와 회귀 테스트를 수행하듯 AI도 모델, 프롬프트, 데이터가 달라질 때 기존 품질이 유지되는지 확인해야 합니다.

딥이밸(DeepEval)은 이런 접근을 AI 평가에 적용한 오픈소스 프레임워크입니다. 파이테스트(PyTest) 기반의 파이썬 스크립트를 로컬 환경이나 CI/CD 파이프라인에서 실행할 수 있으며, 일반적인 오류뿐 아니라 환각(Hallucination), 모델 드리프트(Drift), 역할 준수, 지식 유지, 대화 완결성과 같이 포착하기 어려운 문제도 검사합니다. 모델이 예상과 다르게 행동하거나 유해한 응답을 만들기 시작하면 자동 테스트로 이를 찾아내는 방식입니다.

딥이밸의 기능을 활용하면서 직접 운영하는 부담을 줄이고 싶다면 컨피던트 AI(Confident AI)가 대안이 될 수 있습니다. 클라우드 기반 환경에서 테스트 실행 기록을 추적하고 팀 단위로 결과를 공유할 수 있습니다. 자동화된 레드팀 테스트와 온디맨드 침투 테스트도 제공해 일반적인 품질 검증에서 보안 영역까지 평가 범위를 넓힐 수 있습니다.

모델 자체의 실력을 객관적으로 비교하려면 평가자의 편향도 고려해야 합니다. 라이브벤치(LiveBench)가 주목하는 부분입니다. 최근에는 LLM이 다른 LLM의 답을 평가하는 'LLM-as-a-Judge' 방식이 널리 쓰이지만 평가 모델 역시 오류와 편향에서 자유롭지 않습니다.

라이브벤치는 다른 LLM에 채점을 맡기는 대신 사전에 정의한 정답과 결과를 직접 비교합니다. 화려한 사용자 인터페이스보다 설정 파일과 명시적인 정답을 활용하는 방식에 가깝습니다. 벤치마크 문제가 지속적으로 갱신되기 때문에 모델이 기존 평가 데이터를 이미 학습해 높은 점수를 얻는 데이터 오염(Contamination) 문제를 줄일 수 있다는 점도 특징입니다.

결국 이 영역의 핵심은 평가를 개발의 마지막 관문이 아니라 개발 과정 자체에 넣는 것입니다. 한 번의 테스트에서 좋은 결과를 냈다는 사실보다 변경 이후에도 품질이 유지되는지를 지속적으로 확인하는 체계가 중요합니다.

3. 실전의 실패는 비용이지만 시뮬레이션의 실패는 자산입니다 - 배포 전 검증과 협업 평가

실제 고객을 응대하거나 업무를 수행하는 운영 환경에서 에이전트가 실패하면 비용이 발생합니다. 반대로 시뮬레이션에서 발생한 실패는 시스템을 개선하는 학습 데이터가 될 수 있습니다. 배포 전에 가능한 한 많은 실패를 경험하게 하는 것이 시뮬레이션 기반 평가의 목적입니다.

맥심 AI(Maxim AI)는 에이전트 평가와 시뮬레이션을 아우르는 종단 간(End-to-end) 플랫폼입니다. 프롬프트와 에이전트가 결과에 도달하는 전체 궤적을 배포 전에 반복적으로 시뮬레이션하고, 실제 배포 이후에도 실행 과정을 관찰합니다. 특정 프레임워크에 종속되지 않으며 다양한 사용자와 시나리오를 구현할 수 있어 복잡한 대화형 에이전트를 검증하는 데 활용할 수 있습니다.

ML플로우(MLflow)는 시야를 모델과 에이전트의 전체 생애주기로 넓힙니다. AI 개발 과정에서는 모델, 프롬프트, 데이터와 설정의 수많은 조합을 반복적으로 시험하게 됩니다. ML플로우는 학습에서 배포까지 이어지는 실험을 기록하고 비교할 수 있도록 지원합니다. 프롬프트 레지스트리(Prompt Registry)와 같은 버전 관리 기능을 이용하면 프롬프트의 변화와 결과를 연결해 관리할 수도 있습니다.

이 시장의 많은 도구가 개발자를 주요 사용자로 삼는 반면 레시스 AI(Rhesis AI)는 도메인 전문가와 제품 관리자, 경영진까지 평가 과정에 참여시키는 데 초점을 둡니다. AI 에이전트의 품질은 기술적으로 정상 작동하는지만으로 판단하기 어렵습니다. 업무 맥락을 제대로 이해했는지, 현장에서 받아들일 수 있는 답변인지는 해당 업무를 아는 사람이 판단해야 하기 때문입니다.

개발자가 아닌 이해관계자가 직접 테스트를 만들고 대화 품질을 평가할 수 있으며 극단적인 상황이나 대립적인 대화도 반복적으로 시뮬레이션할 수 있습니다. 휴먼 인 더 루프(Human-in-the-loop) 평가가 필요한 프로젝트에서 의미 있는 접근입니다.

벨럼(Vellum)은 자체 데이터와 업무 환경을 기반으로 AI 애플리케이션을 구축하려는 조직을 위한 통합 환경입니다. 직접 정의한 지표와 사용 사례를 기준으로 성능을 검증하고 토큰 비용, 지연 시간, 응답 품질을 대시보드에서 추적할 수 있습니다. 버전 관리 기능을 활용해 여러 팀이 서로 다른 접근법을 병렬로 개발하고 비교할 수도 있습니다.

이들 도구가 보여주는 공통점은 실패를 피하는 것보다 통제된 환경에서 먼저 발견하는 것이 중요하다는 사실입니다. 정상적인 사용자만 가정해서는 실제 운영 환경의 복잡성을 재현하기 어렵습니다. 다양한 사용자와 예외 상황을 평가 과정에 의도적으로 포함해야 합니다.

4. 에이전트는 아는 만큼 답하고 흔들리는 만큼 뚫립니다 - RAG와 보안 검증

기업용 에이전트의 신뢰성을 좌우하는 두 가지 축은 지식과 보안입니다. 에이전트가 잘못된 정보를 검색하면 아무리 좋은 모델이라도 정확한 답을 만들기 어렵습니다. 반대로 정상적인 상황에서 뛰어난 답을 내놓더라도 악의적인 입력에 쉽게 통제력을 잃는다면 중요한 업무를 맡기기 어렵습니다.

지식 측면에서 검색 증강 생성(RAG)이 에이전트 스택의 핵심이라면 RAGAS가 평가 도구가 될 수 있습니다. 이 파이썬 라이브러리는 RAG의 저장·검색·생성 과정을 평가하면서 충실성(Faithfulness), 관련성(Relevance), 재현율(Recall)과 같은 지표를 측정합니다.

핵심은 결과를 읽어보고 '대체로 괜찮다'고 판단하는 이른바 '바이브 체크(Vibe Check)'에서 벗어나는 것입니다. 어떤 정보를 검색했고 그 정보가 질문과 얼마나 관련돼 있는지, 최종 답변이 검색된 근거를 얼마나 충실하게 반영했는지를 반복 가능한 지표로 확인해야 RAG 시스템을 지속적으로 개선할 수 있습니다.

오닉스(Onyx)는 RAG 기반 챗봇 구축과 평가를 함께 고려하는 접근입니다. MIT 라이선스 커뮤니티 버전과 상용 버전으로 제공되며 RAG 성능을 시험하기 위한 오픈소스 프레임워크 'EnterpriseRAG-Bench'도 제공합니다. 관리자는 사용자가 어떤 질문을 하는지, 결과에 얼마나 만족하는지를 확인할 수 있어 실제 운영 환경의 RAG 품질을 살펴보는 데 활용할 수 있습니다.

보안 측면에서는 프롬프트푸(Promptfoo)가 대표적입니다. 실제 사용자 상호작용과 유사한 테스트를 반복하면서 LLM이 운영 과정에서 마주칠 수 있는 문제를 사전에 점검합니다. 특히 자동화된 레드팀 테스트를 통해 악의적인 입력과 가드레일 우회 가능성을 확인하고 유해 응답, 개인정보(PII) 노출, 탈옥(Jailbreak)과 같은 위험을 탐색합니다.

중요한 것은 정상적인 질문에 정확하게 답한다는 사실만으로 안전한 에이전트라고 판단할 수 없다는 점입니다. 기업 시스템과 연결되는 에이전트가 늘어날수록 의도적으로 시스템을 흔들어보고 어디까지 방어할 수 있는지를 확인하는 과정도 품질 평가의 일부가 됩니다.

AI 에이전트의 신뢰성은 지속적인 검증에서 시작됩니다

13가지 도구를 살펴보면 제품과 기능은 서로 다르지만 방향은 하나로 모입니다. 추적으로 실패를 가시화하고, 자동 테스트로 회귀를 막고, 시뮬레이션으로 실제 환경의 실패를 사전에 경험하며, RAG와 보안이라는 약한 고리를 집중적으로 검증하는 것입니다.

이는 AI 에이전트 평가가 단순히 모델의 점수를 매기는 작업이 아니라는 의미이기도 합니다. 실제 기업 환경에서는 '어떤 모델의 벤치마크 점수가 더 높은가'보다 '우리 업무를 안정적으로 수행하는가'가 더 중요한 질문입니다.

고객 상담 에이전트라면 답변 품질과 대화 완결성이 중요할 수 있습니다. 기업 지식을 검색하는 에이전트라면 검색 결과의 관련성과 근거 충실성을 우선적으로 살펴야 합니다. 여러 시스템과 API를 호출해 실제 업무를 실행하는 에이전트라면 최종 결과뿐 아니라 실행 경로와 도구 호출의 정확성까지 추적해야 합니다. 민감한 정보를 다루는 경우라면 개인정보 노출과 탈옥, 권한 통제 역시 빠뜨릴 수 없습니다.

LLM 내부에서 수많은 가중치가 어떻게 상호작용해 특정 답을 만들어냈는지를 완벽하게 설명하는 일은 여전히 어렵습니다. 하지만 내부를 완전히 이해할 수 없다는 것이 행동까지 검증할 수 없다는 의미는 아닙니다. 설명하기 어렵다면 더 많이 관찰하고, 예측하기 어렵다면 더 자주 시험해야 합니다.

조직에서 채용 면접 한 번으로 구성원의 역량을 영구적으로 보증하지 않는 것처럼 AI 에이전트도 배포 전 한 차례의 평가로 끝낼 수 없습니다. 모델이 바뀌고 프롬프트가 수정되며 데이터와 사용자의 행동도 계속 달라집니다. 어제 합격한 에이전트가 오늘도 같은 품질을 보장한다는 법은 없습니다.

평가 및 벤치마킹 시장은 아직 빠르게 변화하고 있습니다. 에이전트옵스, 옵저버빌리티, 평가, 가드레일, 보안의 경계 역시 계속 겹치고 있습니다. 하지만 도구가 완전히 정리될 때까지 기다릴 필요는 없습니다. 지금 필요한 것은 모든 도구를 한꺼번에 도입하는 일이 아니라, 우리 조직의 업무와 위험 수준에 맞는 평가 기준을 세우고 이를 반복적으로 검증하는 일입니다.

FAQ

▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.