"can it do this at all?" 이 질문은 초기 개발 단계에서 모델의 가능성을 타진할 때 던지는 기초적인 물음이다. 하지만 에이전트가 복잡한 도구를 사용하고 다단계 추론을 수행하는 '딥 에이전트(Deep Agents)'로 진화하면서, 개발자들은 결과값의 도출 여부를 넘어 그 과정의 신뢰성을 증명해야 하는 과제에 직면했다. 에이전트는 비결정적이며, 초기 단계의 작은 오류가 전체 워크플로우를 무너뜨리는 연쇄 반응을 일으키기 때문이다. LangChain과 Amazon Bedrock을 활용한 딥 에이전트 아키텍처는 프로덕션 환경의 안정성을 확보하기 위한 평가 프레임워크를 필수적으로 요구한다.

딥 에이전트 평가를 위한 3단계 등급 분류 체계

단순한 LLM 응답 평가와 달리 딥 에이전트는 비결정론적 특성과 다단계 워크플로우를 가지므로 측정 방식이 세분화되어야 한다.

코드 기반 평가자는 정규표현식이나 도구 호출 검증 같은 결정론적 논리를 사용하여 특정 조건을 확인한다. 문자열 일치 여부, 바이너리 통과/실패 테스트, 정적 분석뿐 아니라 트랜스크립트 분석을 통해 턴 횟수와 토큰 사용량을 측정한다. 속도가 빠르고 비용이 저렴하며 결과가 객관적이지만, 의미가 동일함에도 표현이 다른 변형 답변에는 취약하다. 성공 기준을 명확한 코드로 표현할 수 있는 영역에서 가장 효율적인 검증 수단이 된다.

모델 기반 평가자는 또 다른 LLM을 판정자로 세워 답변의 뉘앙스와 복잡한 분석 내용을 평가한다. 루브릭 기반 점수 산정, 자연어 단언, 쌍별 비교, 다수 판정자 합의 방식을 활용해 정형화되지 않은 자유 형식의 출력을 처리한다. 유연성과 확장성이 높으나 결과가 비결정론적이며 비용이 많이 든다. 판정 모델의 환각을 막기 위해 '알 수 없음'이라는 선택지를 주는 설계가 필요하다. 랭스미스(LangSmith)의 얼라인 이밸류에이터(Align Evaluator) 기능은 인간 전문가의 피드백을 바탕으로 LLM 판정자를 캘리브레이션하는 단계를 지원한다.

인간 평가자는 전문가 검토나 크라우드소싱 판단을 통해 주관적 품질을 측정하는 골드 스탠다드 역할을 한다. 자동화 방식보다 비용이 많이 들고 속도가 느리지만 모델 기반 평가자의 정확도를 보정하는 데 필수적이다. 초기 단계에서 LLM 판정자의 루브릭을 전문가의 판단과 대조해 맞춘 뒤, 주기적인 샘플링 검토를 통해 자동 평가자가 기준에서 벗어나지 않았는지 확인한다.

Amazon Nova 2 Lite와 LangSmith의 기술적 결합

Amazon Bedrock의 Amazon Nova 2 Lite와 LangSmith의 평가 프레임워크를 결합해 딥 에이전트의 전체 생명주기를 통합 관리할 수 있다. Amazon Nova 2 Lite는 100만 토큰의 컨텍스트 윈도우를 지원하는 고속 추론 모델로, 텍스트, 이미지, 비디오, 문서 등 멀티모달 데이터를 처리한다. 특히 지시사항 준수와 함수 호출, 코드 생성 능력이 뛰어나 복잡한 에이전트 워크로드를 수행하는 데 최적화되어 있다.

딥 에이전트의 핵심인 DeepAgents 프레임워크는 LangGraph를 기반으로 설계되어 계획 수립, 파일 시스템 저장, 점진적인 컨텍스트 로딩을 지원한다. 개발자는 pytest와 LangSmith를 연동해 에이전트의 궤적과 상태를 검증하는 오프라인 평가 환경을 구축할 수 있다. 이는 에이전트가 최종 답변을 내놓기 전, 각 단계에서 적절한 도구를 호출했는지 혹은 올바른 계획을 수립했는지를 단위 테스트 수준에서 확인하게 한다.

이러한 결합은 에이전트가 특정 상태를 유지하고 도구 사용의 정확성을 확보하는지 실시간으로 모니터링하게 한다. Nova 2 Lite의 추론 능력은 긴 호흡의 작업에서 발생하는 문맥 손실을 최소화하며, LangSmith의 정밀한 추적은 에이전트가 의도한 경로를 이탈했을 때 즉각적인 수정과 개선을 가능하게 한다. 결과적으로 개발팀은 지속적인 회귀 테스트를 통해 에이전트의 일관된 신뢰성을 유지할 수 있다.

LLM 평가와 에이전트 평가의 차이

기존의 LLM 평가는 입력값에 대해 모델이 내놓은 최종 답변이 정답과 일치하는지만 확인하는 단일 입출력 방식에 집중했다. 하지만 에이전트는 목표 달성을 위해 스스로 계획을 세우고 도구를 호출하는 다단계 추론 과정을 거치므로 결과값만으로는 성능을 확신할 수 없다. 특히 에이전트의 추론은 비결정적 특성을 가져 매번 실행할 때마다 서로 다른 경로를 생성하며, 이 과정에서 발생하는 작은 오류가 전체 워크플로우로 전이된다. 따라서 최종 메시지가 아니라 에이전트가 밟아온 전체 실행 경로인 트래젝토리(Trajectory)와 중간 상태(State)를 추적하는 검증 방식이 필요하다.

에이전트 평가에서는 특정 도구가 적절한 시점에 호출되었는지, 그리고 그 도구에 전달된 인자(Argument)가 정확한지를 확인하는 과정이 포함된다. 이는 전체 실행 시퀀스를 분석하기 전 특정 지점의 오류를 빠르게 잡아내는 유닛 테스트의 역할을 수행한다.

정답의 형태와 검증 기준이 제각각인 에이전트 환경에서는 코드 기반 검증과 모델 기반 검증을 혼합해 사용해야 한다. LangSmith의 Pytest 통합 기능은 테스트 케이스별로 트래젝토리, 최종 메시지, 상태에 대해 서로 다른 단언(Assertion)을 설정할 수 있게 지원한다. 특정 도구가 트래젝토리에 포함되었는지만 확인하고 호출 순서는 제한하지 않는 방식으로 평가 설계를 유연하게 가져갈 수 있다.

딥 에이전트 신뢰성 확보를 위한 4가지 평가 패턴

첫째, 단일 단계 평가(Single-step Evaluation)는 특정 입력 직후 에이전트가 어떤 도구를 호출했는지, 인자는 정확한지 확인하는 단위 테스트 방식이다. 텍스트-투-SQL 에이전트가 쿼리를 바로 작성하지 않고 데이터베이스 스키마를 먼저 탐색하는 `sql_db_list_tables`나 `sql_db_schema`를 호출했는지 확인하는 작업이 대표적이다. 이는 개별 의사결정 지점에서 발생하는 회귀 오류를 빠르게 잡아내기 위한 목적이다.

둘째, 전체 에이전트 턴 평가(Full-turn Evaluation)는 입력부터 최종 결과까지의 전 과정을 엔드-투-엔드로 검증한다. 도구 호출의 정확한 순서보다 최종 결과물의 유효성과 경로의 적절성을 평가한다. 랭스미스는 `write_todos` 같은 계획 단계부터 실제 SQL 쿼리 실행, 최종 답변 포맷팅까지의 전체 트레이스(Trace)를 시각화해 경로의 유효성을 증명한다.

셋째, 다중 턴 대화 평가(Multi-turn Evaluation)는 사용자의 후속 질문에 따라 조건부 로직을 적용한다. 에이전트가 예상 경로를 벗어나면 이후의 입력값은 의미를 잃으므로, 테스트 코드 내에 조건문을 삽입하여 상태에 따라 검증 단계를 분기한다. 특정 턴만 독립적으로 테스트해야 할 때는 이전 단계의 예상 출력값을 초기 상태로 강제 설정해 효율을 높인다.

넷째, 회귀 스위트(Regression Suite) 전환이다. 높은 통과율을 기록하며 신뢰성이 입증된 기능들은 프로덕션 배포 전 회귀 스위트로 전환되어, 기존 기능이 여전히 안정적으로 수행되는지 확인하는 상시 감시 체계로 작동한다.

한국 실무자를 위한 텍스트-투-SQL 에이전트 적용 사례

데이터베이스와 상호작용하는 에이전트를 설계할 때, 모델이 의도대로 스키마를 탐색하는지 확인하기 위해 코드 기반 평가를 활용한다. 에이전트가 실행 초기 단계에서 `sql_db_list_tables`나 `sql_db_schema`와 같은 도구를 올바르게 호출하는지 확인하는 방식이다.

python

도구 호출 검증 예시

assert "sql_db_list_tables" in [tool_call.name for tool_call in trace.tool_calls]

반면 매출 상위 직원과 국가를 묻는 복잡한 분석 질문은 답변 형식이 다양하므로 LLM 판정자(Model-based grader)를 도입해 정확성과 완전성을 평가한다. 모델이 판단 근거를 잃지 않도록 정보가 부족할 경우 '알 수 없음(Unknown)'을 반환하게 하는 가이드라인 설정이 중요하다.

실무 환경에서는 명확한 절차는 코드 기반 평가로 비용을 절감하고, 정답 형식이 가변적인 분석 질문은 LLM 판정자로 보완하는 하이브리드 전략이 권장된다. 이는 에이전트의 전체 실행 경로를 추적하면서 각 단계별로 최적의 검증 도구를 배치하는 방식이다. 결과적으로 개발자는 에이전트가 단순히 쿼리를 생성하는 과정을 넘어, 데이터베이스의 상태와 계획 수립 단계까지 신뢰성 있게 수행하는지 검증할 수 있다.

AI 에이전트가 단순한 질의응답을 넘어 다단계의 복잡한 워크플로우를 스스로 수행하면서, 예측 불가능한 오류의 변수가 늘어났다. 과거의 LLM 평가가 정답의 일치 여부에 집중했다면, 이제는 추론 과정의 논리적 결함과 도구 사용의 정확성을 동시에 검증해야 한다. 본문에서 다룬 네 가지 평가 패턴은 모호한 체감 성능을 측정 가능한 객관적 지표로 전환하는 실무적인 검증 기준으로 활용된다. 결국 AI 에이전트의 상용화 가능성은 모델의 규모가 아니라 검증 시스템의 정교함에 달려 있다.