🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LangChain 팀은 네 가지 딥 에이전트 애플리케이션을 출시하며, 딥 에이전트 평가는 일반 LLM 평가보다 테스트별 성공 기준, 실행 범위 선택, 재현 가능한 환경 구성이 훨씬 중요하다는 점을 정리했다.

📌 핵심 요약

• LangChain은 DeepAgents CLI, LangSmith Assist, Personal Email Assistant, Agent Builder를 구축·출시하면서 각 애플리케이션에 평가 체계를 추가했고, 그 과정에서 딥 에이전트 평가의 반복되는 패턴을 정리했다.
• 딥 에이전트는 최종 응답만으로 평가하기 어렵기 때문에, 각 데이터포인트마다 도구 호출 경로, 도구 인자, 생성된 파일이나 메모리 같은 상태, 사용자에게 전달된 최종 메시지를 별도로 검증해야 한다.
• 단일 단계 평가는 특정 상황에서 에이전트가 즉시 어떤 도구를 어떤 인자로 호출하려 하는지 확인하는 데 효율적이며, 토큰 비용을 줄이면서 의사결정 지점의 회귀를 빠르게 잡는 데 유용하다.
• 전체 턴 평가는 에이전트가 문제를 끝까지 수행하는 과정과 최종 상태를 보여 주며, 도구 호출 궤적, 최종 응답 품질, 파일·링크·아티팩트 같은 기타 상태를 함께 검증할 수 있다.
• 여러 턴 평가는 실제 사용자 상호작용에 가깝지만, 에이전트가 예상과 다르게 움직일 경우 이후 입력이 무의미해질 수 있어 각 단계 후 조건부 검증을 넣고, 테스트별로 깨끗하고 재현 가능한 환경을 구성해야 한다.

🧩 주요 포인트

1. LangChain은 DeepAgents CLI, LangSmith Assist, Personal Email Assistant, Agent Builder를 구축·출시하면서 각 애플리케이션에 평가 체계를 추가했고, 그 과정에서 딥 에이전트 평가의 반복되는 패턴을 정리했다.
2. 딥 에이전트는 최종 응답만으로 평가하기 어렵기 때문에, 각 데이터포인트마다 도구 호출 경로, 도구 인자, 생성된 파일이나 메모리 같은 상태, 사용자에게 전달된 최종 메시지를 별도로 검증해야 한다.
3. 단일 단계 평가는 특정 상황에서 에이전트가 즉시 어떤 도구를 어떤 인자로 호출하려 하는지 확인하는 데 효율적이며, 토큰 비용을 줄이면서 의사결정 지점의 회귀를 빠르게 잡는 데 유용하다.
4. 전체 턴 평가는 에이전트가 문제를 끝까지 수행하는 과정과 최종 상태를 보여 주며, 도구 호출 궤적, 최종 응답 품질, 파일·링크·아티팩트 같은 기타 상태를 함께 검증할 수 있다.
5. 여러 턴 평가는 실제 사용자 상호작용에 가깝지만, 에이전트가 예상과 다르게 움직일 경우 이후 입력이 무의미해질 수 있어 각 단계 후 조건부 검증을 넣고, 테스트별로 깨끗하고 재현 가능한 환경을 구성해야 한다.

🧠 상세 정리

1. 네 가지 딥 에이전트 출시에서 출발한 평가 논의

이 글은 LangChain 팀이 한 달 동안 네 가지 딥 에이전트 기반 애플리케이션을 출시한 경험에서 출발한다. 대상은 코딩 에이전트인 DeepAgents CLI, LangSmith 내부 작업을 돕는 LangSmith Assist, 사용자별 상호작용에서 학습하는 Personal Email Assistant, 메타 딥 에이전트로 구동되는 노코드 Agent Builder다. 팀은 이 애플리케이션들을 만들고 배포하면서 각각에 대한 평가를 추가해야 했고, 그 과정에서 일반 LLM 평가와 다른 요구사항을 확인했다. 핵심은 딥 에이전트 평가가 단일 점수나 최종 답변만으로 끝나지 않고, 실행 방식과 상태 변화, 테스트 환경까지 함께 다뤄야 한다는 점이다.

2. 기본 용어: 실행 범위와 평가 대상의 구분

글은 먼저 에이전트를 실행하는 방식을 단일 단계, 전체 턴, 여러 턴으로 구분한다. 단일 단계는 핵심 에이전트 루프를 한 번만 실행해 다음 행동을 확인하는 방식이고, 전체 턴은 하나의 입력에 대해 여러 도구 호출 반복까지 포함해 에이전트를 끝까지 실행하는 방식이다. 여러 턴은 에이전트를 여러 번 완전히 실행해 사용자와의 다중 대화 흐름을 시뮬레이션하는 방식이다. 평가 대상도 도구 호출 순서와 인자를 뜻하는 궤적, 사용자에게 반환되는 최종 응답, 실행 중 생성된 파일이나 아티팩트 같은 기타 상태로 나뉜다.

3. 데이터포인트별 맞춤형 테스트 로직의 필요성

전통적인 LLM 평가는 데이터셋을 만들고, 평가기를 작성하고, 동일한 애플리케이션 로직과 동일한 평가기로 모든 예시를 채점하는 흐름이 비교적 자연스럽다. 하지만 딥 에이전트에서는 이 전제가 깨진다. 각 테스트 케이스는 최종 메시지뿐 아니라 특정 도구를 호출했는지, 올바른 인자를 사용했는지, 실행 뒤 내부 상태가 원하는 방식으로 바뀌었는지까지 검증해야 할 수 있다. 그래서 성공 기준은 데이터포인트마다 달라지고, 평가 코드는 테스트별로 더 구체적인 단언과 피드백 로깅을 포함해야 한다.

4. 캘린더 메모리 예시가 보여 주는 상태 검증

글은 캘린더 스케줄링 딥 에이전트를 예로 들어 맞춤형 검증이 왜 필요한지 설명한다. 사용자가 회의를 오전 9시 전에는 잡지 말라고 기억해 달라고 요청하면, 테스트는 에이전트가 memories.md 파일에 대해 edit_file 도구를 호출했는지 확인할 수 있다. 또한 최종 메시지에서 사용자에게 메모리 업데이트를 알렸는지, 실제 memories.md 내용에 이른 시간 회의를 피해야 한다는 정보가 들어갔는지도 확인해야 한다. 이때 단순 정규식으로 9am 언급을 찾을 수도 있고, 더 포괄적인 판단을 위해 구체적 성공 기준을 가진 LLM-as-judge를 사용할 수도 있다.

5. 단일 단계 평가는 특정 의사결정 검증에 효율적이다

LangChain 팀의 딥 에이전트 평가 중 상당수는 특정 입력 메시지 뒤 LLM이 즉시 무엇을 하기로 결정하는지를 보는 단일 단계 평가였다. 이 방식은 회의 시간을 찾기 위해 올바른 도구를 호출했는지, 적절한 디렉터리 내용을 살폈는지, 메모리를 업데이트하려 했는지처럼 특정 상황의 첫 의사결정을 검증하는 데 적합하다. 회귀는 전체 실행 흐름보다 개별 결정 지점에서 발생하는 경우가 많기 때문에, 단일 단계 평가는 비용과 시간을 줄이면서 문제를 빠르게 드러낸다. LangGraph를 사용할 경우 도구 노드 직전에 실행을 중단하고, 생성된 도구 호출 인자를 검사하는 방식으로 이러한 평가를 구현할 수 있다.

6. 전체 턴 평가는 실행 결과의 전체 그림을 보여 준다

단일 단계 평가가 특정 상황의 단위 테스트에 가깝다면, 전체 에이전트 턴은 에이전트가 하나의 입력을 끝까지 처리하는 전체 행동을 보여 준다. 전체 턴에서는 특정 도구가 정확히 언제 호출됐는지보다, 실행 중 어느 시점에 필요한 도구가 호출됐는지를 확인하는 방식의 궤적 평가가 가능하다. 일정 조율 예시처럼 여러 번의 도구 호출을 거쳐야 적절한 시간대를 찾는 작업에서는 이런 관점이 중요하다. 또한 코딩이나 리서치처럼 경로보다 최종 산출물의 품질이 중요한 작업에서는 최종 응답이나 생성 파일, 확인한 링크와 출처 같은 기타 상태를 검사하는 방식이 더 적합할 수 있다.

7. 여러 턴 평가는 현실적인 대화를 모사하지만 통제가 필요하다

일부 시나리오는 여러 순차적 사용자 입력을 포함한 다중 턴 대화를 평가해야 한다. 그러나 입력 시퀀스를 단순히 하드코딩하면, 에이전트가 예상 경로에서 벗어났을 때 다음 사용자 입력이 더 이상 상황에 맞지 않는 문제가 생긴다. LangChain 팀은 Pytest와 Vitest 테스트에 조건부 로직을 넣어 첫 번째 턴을 실행한 뒤 결과가 기대와 맞는지 확인하고, 맞으면 다음 턴으로 진행하며, 맞지 않으면 일찍 실패시키는 방식을 사용했다. 특정 두 번째나 세 번째 턴만 따로 보고 싶을 때는 그 지점에 맞는 초기 상태를 구성해 독립 테스트로 시작했다.

8. 재현 가능한 평가 환경과 API 요청 재생의 중요성

딥 에이전트는 상태를 가지며 복잡하고 오래 걸리는 작업을 수행하도록 설계되어 있어, 단순하고 대체로 상태 없는 도구만 쓰는 LLM 평가보다 환경 구성이 중요하다. 각 평가 실행은 신선하고 깨끗한 환경에서 시작해야 결과가 재현 가능하며, 그렇지 않으면 테스트가 불안정해지고 디버깅이 어려워진다. 코딩 에이전트의 경우 전용 Docker 컨테이너나 샌드박스를 사용할 수도 있고, DeepAgents CLI처럼 테스트 케이스마다 임시 디렉터리를 만들어 그 안에서 실행하는 가벼운 방식을 택할 수도 있다. 실제 API에 의존하는 LangSmith Assist 같은 경우에는 HTTP 요청을 파일 시스템에 기록해 두고 테스트 때 재생하면, 평가를 더 빠르고 저렴하며 디버깅하기 쉽게 만들 수 있다.

🧾 핵심 주장 / 시사점

• 딥 에이전트 평가는 최종 답변 채점이 아니라, 도구 호출 궤적·도구 인자·생성 상태·사용자 커뮤니케이션을 함께 보는 테스트 설계 문제에 가깝다.
• 단일 단계, 전체 턴, 여러 턴 평가는 서로 대체 관계가 아니라 서로 다른 실패 양상을 잡기 위한 보완적 도구이며, 애플리케이션의 위험 지점에 맞게 조합해야 한다.
• 상태ful 에이전트의 평가는 모델 자체만큼이나 실행 환경의 초기화, 외부 API 의존성 통제, 테스트 재현성이 결과 신뢰도를 좌우한다.

✅ 액션 아이템

• 딥 에이전트 평가는 최종 응답만으로 끝내지 않고, 도구 호출 경로·인자·생성된 파일/메모리 상태·최종 메시지를 함께 점검한다.
• 평가 세트는 단일 단계와 전체 턴을 분리해 구성하고, 단일 단계에서 즉시 도구 선택 회귀를 확인한 뒤 전체 턴에서 최종 상태와 아티팩트를 검증한다.
• 테스트별 실행 범위를 명확히 정하고, 각 단계 후 클린하고 재현 가능한 환경을 유지해 결과 비교 가능성을 확보한다.

❓ 열린 질문

• 단일 단계 기준에서 어떤 판단 포인트를 성공 기준으로 두면 도구 호출 경로의 회귀를 안정적으로 포착할 수 있는가?
• 여러 턴 평가에서 에이전트가 예상과 다르게 이동했을 때 어떤 조건에서 추가 입력을 중단하고 상태를 재설정해야 하는가?
• 최종 상태 검증 시 도구 호출 궤적 외에 어떤 파일·링크·아티팩트 항목이 필수로 포함돼야 하는가?