What Is Eval-Driven Development? How to Improve AI Agents

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

평가 주도 개발(EDD)은 에이전트의 목표 행동을 정의하고 구현 전에 평가를 만든 뒤, 실험 비교로 개선과 회귀를 확인하며 성능을 높이는 개발 방식이다.

📌 핵심 요약

• EDD는 비결정적인 에이전트의 성능을 일관된 지표로 측정하며, 좋은 행동 정의 → 구현 전 평가 작성 → 변경 후 실험 비교의 세 단계로 진행된다.
• 한 번에 하나의 행동을 대상으로 발생 조건, 해야 할 일, 해서는 안 될 일, 유지해야 할 기존 행동을 명세한다. 문서 에이전트 사례에서는 장애 신고에 create_ticket을 호출하되 사용법 질문은 기존 search_docs와 web_search가 처리하도록 정한다.
• 실제 실행에서 수집하거나 직접 만든 사례로 데이터셋을 구성하고, 결정적인 검사는 코드 평가로, 그렇지 않은 검사는 LLM-as-a-judge로 평가한다. 변경 전에는 기준 실험을 실행해 기존 성능을 기록한다.
• LangSmith에서 실험별 평균 점수와 개별 사례의 회귀를 함께 비교한다. 사례에서는 create_ticket 추가 후 VPN 사용법 질문에도 티켓을 만드는 문제가 발생했으며, 트레이스로 원인을 확인하고 도구 설명을 좁혀 해결했다.
• 작은 데이터셋의 100% 점수만 추구하면 과적합할 수 있으므로 별도로 남겨 둔 검증 사례로 일반화를 확인한다. 평가는 CI와 운영 환경에서도 지속하고, 발견한 실패를 새 데이터셋 사례로 반영하며, 빠른 코드 검사와 느린 LLM 평가의 실행 시점을 구분한다.

🧩 주요 포인트

1. 명세에 금지 행동과 기존 동작 유지 조건까지 포함 → 새 기능의 성공 여부와 기존 기능의 보존 여부를 함께 판단하는 기준 마련.
2. 평균 점수 상승에도 개별 사례의 회귀 발생 가능 → 실험 비교와 트레이스를 결합해 개선의 대가와 실패 원인을 확인.
3. 작은 데이터셋의 100%와 실제 요청 대응력은 다를 수 있음 → 별도로 남겨 둔 검증 사례와 지속적인 실패 사례 추가로 평가의 대표성 보완.

🧠 상세 정리

1. 수동 조정에서 평가 주도 개발로

에이전트 개발은 흔히 프롬프트를 작성하고 몇 가지 질문을 직접 시험한 뒤 수정하는 방식으로 시작하며, 초기에는 오류와 개선이 눈에 잘 띈다. 그러나 시간이 지나면 최근 변경이 에이전트를 실제로 개선했는지 악화했는지 판단하기 어려워지고, EDD는 일관된 성능 지표를 통해 이 판단을 돕는다. EDD는 실패하는 테스트를 먼저 작성하는 테스트 주도 개발(TDD)에서 이름과 개념을 빌렸지만, 에이전트는 같은 질문에도 다른 답을 내고 서로 다른 표현이 모두 정답일 수 있다는 차이가 있다. 또한 불필요한 도구를 호출하거나 필요한 도구를 건너뛰고도 정답에 도달할 수 있어, 결과뿐 아니라 실행의 여러 측면을 평가할 필요가 있다. 따라서 여러 사례에 대한 실행을 채점하는 평가를 성공 기준으로 삼고, 목표 행동 정의, 구현 전 평가 작성, 변경 후 비교라는 세 단계를 반복한다.

2. 하나의 행동을 검증 가능한 명세로 정의

첫 단계는 에이전트가 수행해야 할 일과 이를 위해 필요한 행동을 정의하고, 각 행동의 요구사항을 제품 요구사항 문서(PRD)로 정리하는 것이다. EDD는 한 번에 하나의 행동에 집중해 변경들의 효과가 서로 뒤섞이지 않도록 하며, 대상은 새로 만들 기능이나 과거 실행에서 발견한 실패에서 선택할 수 있다. 구현 전 짧은 명세에는 행동이 발생해야 하는 조건, 해야 할 일, 해서는 안 될 일, 계속 작동해야 하는 기존 행동을 포함하고 통과와 실패를 판정할 수 있을 만큼 명확하게 적는다. 문서 에이전트 사례에서는 기존 search_docs와 web_search에 create_ticket을 추가하면서, 노트북이 VPN에 연결되지 않는다는 장애 신고에는 티켓을 만들도록 정한다. 반면 VPN 연결 방법을 묻는 사용법 질문에는 티켓을 만들지 않고, 기존 두 도구가 처리하던 질문도 계속 처리하도록 요구한다.

3. 실제 요청을 반영하는 데이터셋 구성

데이터셋은 입력과 선택적인 기준 정답을 가진 테스트 사례의 모음이며, 실제 에이전트 실행은 좋은 입력을 얻을 수 있는 중요한 출처다. 실제 사용자는 개발자가 예상하지 못한 표현을 사용하고 직접 작성할 때 놓치기 쉬운 경계 사례를 제시하므로, 평가 사례가 실제 트래픽과 닮을수록 좋은 점수가 운영 환경의 좋은 행동을 의미할 가능성이 커진다. LangSmith에서는 실제 실행을 데이터셋에 직접 추가할 수 있고, 아직 실행 기록이 없다면 사례를 처음부터 작성하는 방법도 사용할 수 있다. 문서 에이전트는 소수 사례로 시작하되 티켓 요청뿐 아니라 search_docs와 web_search가 계속 처리해야 할 질문도 포함하며, 각 질문에 호출해야 할 도구를 기준 정답으로 연결한다. 부족한 유형은 기존 사례를 LLM에 제공해 더 화난 사용자 표현으로 바꾸는 식으로 확장하고, 표현이 달라져도 올바른 도구를 호출하는지 확인할 수 있다.

4. 평가 대상과 에이전트 복잡도에 맞는 채점

평가기는 PRD에서 정의한 좋은 행동을 각 사례의 점수로 바꾸며, 최종 답변과 중간 행동 등 무엇을 검사할지 먼저 정해야 한다. 결정적으로 판별할 수 있는 조건에는 코드 평가를, 그렇지 않은 조건에는 LLM-as-a-judge를 사용하며, 문서 에이전트에서는 기준 정답에 지정된 도구를 호출했는지 코드로 확인한다. 그러나 환경을 변경하는 코딩 에이전트처럼 복잡한 경우에는 몇 번의 도구 호출과 최종 응답만으로 충분하지 않아, 실행이 남긴 시스템 상태를 검사하고 실행마다 깨끗한 환경을 제공해야 한다. Harbor는 이런 작업을 실행하는 오픈소스 프레임워크이자 Terminal-Bench의 실행 기반으로, 각 작업을 별도 샌드박스에서 실행하고 테스트 스크립트로 최종 상태를 채점한다. 글에서는 LangSmith Engine 개발 시 실제 실행과 합성 실행으로 만든 자체 벤치마크를 Harbor 평가로 실행했으며, Deep Agents에서도 할 일 목록 미들웨어나 시스템 프롬프트 일부를 제거해도 성능이 나빠지지 않는지 확인하는 데 Harbor를 사용한다고 설명한다.

5. 변경 전 기준 실험으로 비교점 확보

데이터셋과 평가기를 준비한 뒤에는 에이전트를 모든 사례에 실행하고 결과를 실험으로 기록하며, 변경하기 전에 기준 실험을 확보하는 것이 중요하다. LangSmith의 실험은 데이터셋 전체에 대한 한 차례 실행으로, 각 사례의 입력과 출력, 평가 점수를 함께 저장해 에이전트 버전 사이의 비교를 가능하게 한다. 문서 에이전트의 기준 실험에서는 create_ticket이 아직 존재하지 않으므로 티켓 요청 사례가 실패하지만, 다른 사례는 기존에 어떤 행동이 정상적으로 작동하는지 보여 준다. 이 기록은 새 도구 추가 후 나타난 성공만 확인하는 데 그치지 않고, 이전에 잘 처리하던 질문이 새 기능 때문에 실패하는지도 판단할 수 있게 한다. 따라서 아직 구현되지 않은 기능의 실패와 이미 작동하는 기능의 결과를 함께 남기는 것이 이후 변경의 효과를 해석하는 비교 기준이 된다.

6. 평균 점수보다 개별 회귀와 원인까지 비교

create_ticket을 구현한 뒤에는 동일한 평가를 다시 실행하고, 이후 변경도 각각 별도 실험으로 기록해 직전 실험과 비교하면서 개선과 조정을 반복한다. LangSmith의 비교 화면은 사례별 점수를 나란히 보여 주므로, 평균 점수 상승뿐 아니라 어떤 사례가 개선되거나 회귀했는지도 확인할 수 있다. 사례에서는 티켓 요청이 통과하면서 평균 점수는 올랐지만, VPN 연결 방법을 묻는 질문에도 티켓을 생성해 기존 문서 검색 행동이 깨졌다. 모든 모델 호출과 도구 호출을 기록한 트레이스를 살펴보니 create_ticket 설명이 VPN과 노트북 문제 전반을 대상으로 해, VPN을 언급하는 사용법 질문까지 포함하고 있었다. 도구 설명을 IT 담당자의 조치가 필요한 요청으로 좁힌 뒤 다시 평가하자 모든 사례가 통과했으며, 이는 점수 비교와 실행 기록 분석을 함께 사용하는 과정을 보여 준다.

7. 100% 점수의 한계와 평가 범위 확장

작은 데이터셋에서 모든 사례가 통과하는 것은 좋은 신호지만, 글은 100%가 언제나 적절한 목표는 아니라고 지적한다. 개발자가 바로 그 사례들을 보면서 도구 설명을 계속 조정했기 때문에, 평가를 모두 통과하도록 맞추는 과정에서 목표 행동 자체보다 데이터셋에 과적합할 수 있기 때문이다. 이 경우 평가에는 성공하더라도 데이터셋이 다루지 않는 표현으로 들어온 요청은 여전히 놓칠 수 있으므로, 반복 개선 중에는 들여다보지 않는 별도 검증 사례를 남겨 두어야 한다. 조정에 사용한 사례의 점수만 오르고 별도 검증 사례의 점수가 그대로라면 과적합 가능성이 있다는 것이 글에서 제시하는 판단 기준이다. 또한 여러 단계로 작동하는 에이전트는 어느 단계에서든 실패할 수 있으므로, LangSmith에서는 최종 답변 외에도 단일 단계, 전체 도구 호출 순서, 스레드로 묶은 여러 차례의 대화를 평가할 수 있다.

8. 배포 과정에서도 평가를 지속

변경을 더 빠르게 배포하기 시작하면 평가 실행을 건너뛰거나 오래된 사례를 놓치기 쉬워지므로, 글은 자동 평가를 개발 흐름에 포함해 사용자에게 도달하기 전에 회귀를 발견하도록 권한다. 구체적인 구성은 환경에 따라 달라지며, 빠른 코드 검사는 잘못된 병합을 차단하는 데 사용하고 느린 LLM 평가기는 야간이나 릴리스 전에 실행하는 방식을 제시한다. 반복 개발 중에는 데이터셋을 나눠 현재 다루는 행동의 사례만 실행하되, 배포 전에는 전체 사례를 실행하도록 설명한다. 핵심 요점에서는 CI와 운영 환경에서 평가를 계속 수행하고 발견한 실패를 새 데이터셋 사례로 전환할 것도 강조한다. LangSmith가 pytest와 Vitest에 통합된다는 내용까지 제시되지만, 제공된 원문은 해당 설명 문장 도중에 끝나므로 그 이후의 세부 운영 방식은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• EDD에서 성공의 정의에는 새 행동의 구현뿐 아니라 금지 행동의 방지와 기존 기능의 유지도 포함되므로, 기능 추가 자체와 전체 품질 개선을 구분할 수 있다.
• VPN 사용법 질문의 회귀는 평균 점수만으로 변경을 판단하기 어렵다는 점을 보여 주며, 사례별 비교는 문제를 드러내고 트레이스는 그 원인을 설명하는 역할을 한다.
• 평가 데이터셋은 한 번 완성하고 고정하는 기준이 아니라, 실제 실패를 반영해 보완하면서 별도 검증 사례로 과적합도 감시해야 하는 개발의 일부다.

✅ 액션 아이템

• EDD 적용 대상 행동의 발생 조건, 금지 행동, 기존 동작 유지 조건을 명세하고 변경 전 기준 실험 확보.
• LangSmith에서 평균 점수와 개별 사례의 회귀를 비교하고, 실패 사례는 트레이스로 원인 확인.
• 별도로 남겨 둔 검증 사례로 과적합을 점검하고, CI와 운영 환경의 실패를 데이터셋에 반영.

❓ 열린 질문

• create_ticket이 필요한 장애 신고와 search_docs가 처리할 사용법 질문을 어떤 조건으로 구분할 것인가?
• 평균 점수가 상승해도 개별 사례의 회귀가 발생한다면 해당 변경을 어떤 기준으로 판단할 것인가?
• 작은 데이터셋의 100% 점수가 과적합을 뜻하지 않는지 별도로 남겨 둔 검증 사례에서 어떻게 확인할 것인가?