AWS에서 LangSmith를 사용한 딥 에이전트 평가 방법

딥 에이전트(deep agent)는 단일 LLM 호출이 아니라 장기 실행 동안 여러 단계의 계획·도구 호출·하위 작업 위임을 수행하는 자율 에이전트를 가리킨다. 이 글은 그런 에이전트의 품질을 측정하기 위한 다섯 가지 평가 패턴을 제시하는데, 핵심은 단순히 최종 답변의 정답 여부만 보는 것이 아니라 에이전트가 거쳐 간 궤적(trajectory) 전체를 평가한다는 점이다. 예제로 사용된 text-to-SQL 에이전트의 경우, 생성한 SQL의 정확성뿐 아니라 어떤 도구를 어떤 순서로 호출했는지, 중간 추론이 타당했는지까지 검증 대상이 된다. 기술 스택 측면에서는 오프라인 평가를 pytest와 LangSmith로 구성하고, 모델 추론은 Amazon Bedrock에서 처리하며, 운영 환경에서는 LangSmith의 온라인 모니터링으로 실시간 트레이스를 수집·평가하는 방식으로 개발부터 프로덕션까지의 전체 라이프사이클을 하나의 평가 체계로 연결한다.

실무적으로 이 접근이 중요한 이유는, 에이전트가 복잡해질수록 "왜 틀렸는가"를 디버깅하기가 기하급수적으로 어려워지기 때문이다. 기존의 단발성 프롬프트 테스트로는 다단계 에이전트의 회귀를 잡아내기 어렵고, 모델·프롬프트·도구 정의 중 어느 것을 바꿨을 때 성능이 떨어졌는지 추적하기 힘들다. pytest 기반 오프라인 평가를 CI에 통합하면 프롬프트나 도구를 수정할 때마다 골든 데이터셋에 대해 자동 회귀 검증을 돌릴 수 있고, LangSmith 트레이싱은 실패한 실행의 전체 단계를 시각적으로 들여다보게 해 준다. 또한 오프라인에서 검증한 기준을 그대로 프로덕션 온라인 모니터링으로 가져갈 수 있어, 실제 사용자 트래픽에서 발생하는 환각·잘못된 SQL·비용 급증 같은 문제를 배포 후에도 지속적으로 감시할 수 있다는 점이 개발자에게 직접적인 가치를 준다.

한국 개발자가 당장 취해야 할 행동은, 에이전트를 만들기 전에 "평가 데이터셋"부터 확보하는 것이다. 소수라도 입력-기대출력 쌍을 정리해 두면 LangSmith의 Dataset으로 등록해 반복 평가의 기준선으로 쓸 수 있고, LLM-as-judge 방식과 결정론적 어서션을 적절히 섞어 비용과 신뢰성의 균형을 맞추는 설계를 초기부터 고민해야 한다. 다만 이 가이드는 LangSmith·Bedrock에 특화되어 있으므로, 벤더 종속이 부담된다면 평가 로직 자체(궤적 평가, 단계별 검증)는 추상화해 두고 트레이싱 백엔드는 교체 가능하게 구성하는 것이 안전하다. 무엇보다 LangChain과 Anthropic 양쪽 가이드가 공통적으로 강조하는 메시지는 분명하다. 에이전트 품질은 직관이 아니라 측정으로 관리해야 하며, 평가 체계는 출시 후에 덧붙이는 것이 아니라 개발 첫 단계부터 함께 구축해야 한다는 것이다.