🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

딥 에이전트 평가는 많은 테스트를 쌓는 것이 아니라, 프로덕션에서 중요한 행동을 직접 측정하는 표적 평가를 설계하고 반복적으로 개선하는 과정이다.

📌 핵심 요약

• 글은 평가가 에이전트의 행동을 정의하고 장기적으로 압력을 가하는 장치라고 설명하며, 무조건 많은 평가를 추가하는 방식은 실제 프로덕션 품질과 무관한 착시를 만들 수 있다고 지적한다.
• 딥 에이전트 팀은 파일 탐색, 다중 도구 호출, 검색, 기억, 대화 유지처럼 실제 제품에서 중요한 행동을 먼저 정리한 뒤, 그 행동을 검증 가능한 방식으로 측정하는 평가를 선별하거나 직접 작성한다.
• 평가 데이터는 에이전트를 직접 사용하며 발견한 실패 사례, 추적 로그 분석, 외부 벤치마크의 선별·수정, 수작업으로 만든 단위적 행동 평가에서 나온다.
• 모델 비교에서는 먼저 정확성을 확인하고, 일정 수준을 넘은 모델들 사이에서 단계 수, 도구 호출 수, 지연 시간, 비용에 영향을 주는 효율성을 함께 본다.
• 평가는 태그와 분류 체계로 묶어 필요한 범위만 실행할 수 있게 하고, 추적 가능한 실행 환경과 지속적 통합을 통해 실패 양상, 회귀, 개선 여부를 팀이 함께 분석하도록 운영한다.

🧩 주요 포인트

1. 글은 평가가 에이전트의 행동을 정의하고 장기적으로 압력을 가하는 장치라고 설명하며, 무조건 많은 평가를 추가하는 방식은 실제 프로덕션 품질과 무관한 착시를 만들 수 있다고 지적한다.
2. 딥 에이전트 팀은 파일 탐색, 다중 도구 호출, 검색, 기억, 대화 유지처럼 실제 제품에서 중요한 행동을 먼저 정리한 뒤, 그 행동을 검증 가능한 방식으로 측정하는 평가를 선별하거나 직접 작성한다.
3. 평가 데이터는 에이전트를 직접 사용하며 발견한 실패 사례, 추적 로그 분석, 외부 벤치마크의 선별·수정, 수작업으로 만든 단위적 행동 평가에서 나온다.
4. 모델 비교에서는 먼저 정확성을 확인하고, 일정 수준을 넘은 모델들 사이에서 단계 수, 도구 호출 수, 지연 시간, 비용에 영향을 주는 효율성을 함께 본다.
5. 평가는 태그와 분류 체계로 묶어 필요한 범위만 실행할 수 있게 하고, 추적 가능한 실행 환경과 지속적 통합을 통해 실패 양상, 회귀, 개선 여부를 팀이 함께 분석하도록 운영한다.

🧠 상세 정리

1. 평가는 점수가 아니라 행동을 바꾸는 압력이다

글의 출발점은 에이전트 평가가 단순한 품질 측정 도구가 아니라 에이전트 시스템의 행동을 실제로 형성한다는 점이다. 어떤 평가가 실패하면 개발자는 시스템 프롬프트나 도구 설명을 조정해 그 평가를 통과하도록 에이전트를 바꾸게 된다. 따라서 유지되는 모든 평가는 시간이 지날수록 시스템 전체에 특정 방향의 압력을 가한다. 이 때문에 평가를 많이 추가하는 것 자체가 목표가 되어서는 안 되며, 실제 프로덕션에서 원하는 행동과 맞지 않는 평가 묶음은 개선처럼 보이는 점수 상승만 만들 수 있다. 저자들은 더 많은 평가가 더 좋은 에이전트를 뜻하지 않으며, 중요한 행동을 겨냥한 표적 평가가 필요하다고 강조한다.

2. 중요한 행동을 먼저 정하고 평가를 설계한다

딥 에이전트 팀은 평가를 만들기 전에 프로덕션에서 중요하게 보는 행동을 목록화한다. 예로 여러 파일에서 필요한 내용을 찾아내는 능력, 다섯 번 이상의 도구 호출을 정확히 이어서 구성하는 능력, 올바른 도구를 선택하고 상태를 추적하는 능력 등이 제시된다. 이들은 범용 벤치마크 점수를 한꺼번에 합산하는 방식보다, 원하는 행동을 먼저 정의하고 그 행동을 검증 가능한 방식으로 측정하는 평가를 큐레이션하는 방식을 택한다. 각 평가에는 그 평가가 어떤 에이전트 능력을 어떻게 측정하는지 설명하는 문서 문자열을 붙여 자체 설명성을 갖게 한다. 또한 도구 사용 같은 범주 태그를 달아 그룹 단위 실행과 분석이 가능하도록 만든다.

3. 데이터는 실제 사용, 추적, 벤치마크, 수작업 평가에서 온다

평가 데이터의 주요 원천은 네 가지로 정리된다. 첫째, 팀이 매일 에이전트를 직접 사용하면서 발견한 오류를 평가로 바꾸는 방식이다. 둘째, 추적 로그를 읽고 실패 모드를 파악해 재현 가능한 평가로 만드는 방식이다. 셋째, 함수 호출이나 터미널 작업 관련 외부 벤치마크에서 일부 과제를 가져와 특정 에이전트에 맞게 수정하는 방식이다. 넷째, 중요한 행동을 고립해서 관찰하기 위해 손으로 직접 만든 평가와 단위 테스트다. 글은 시스템 프롬프트 전달, 인터럽트 설정, 서브에이전트 라우팅 같은 SDK 단위·통합 테스트와 모델 능력 평가는 분리해야 한다고 설명한다. 그런 테스트는 필요하지만 어떤 모델이든 통과할 수 있으므로 모델 점수에는 별 신호를 주지 않는다는 이유다.

4. 추적 로그는 실패를 평가로 바꾸는 핵심 자료다

저자들은 에이전트 실행 추적이 실수를 발견하고 이해하는 데 중요한 자료라고 말한다. 추적은 에이전트가 어떤 입력을 받고 어떤 도구를 호출했으며 어디서 잘못된 판단을 했는지 보여주기 때문에, 실패 모드를 분석하고 수정안을 세운 뒤 다시 실행해 개선과 회귀를 확인할 수 있게 한다. 추적 로그가 큰 경우에는 별도 에이전트나 분석 도구를 사용해 대규모로 읽고 요약할 수 있다고 설명한다. 예시로 오픈소스 배경 코딩 에이전트인 오픈 SWE가 여러 코드베이스와 서로 다른 문맥에서 사용되며 자연스럽게 실수를 만들고, 그 모든 상호작용이 추적되기 때문에 이후 같은 실수가 반복되지 않도록 평가로 전환될 수 있다고 말한다. 즉 실제 사용 중의 오류는 단순한 버그 보고가 아니라 평가 세트를 강화하는 재료가 된다.

5. 평가는 출처보다 측정 행동 기준으로 묶는다

글은 평가 분류 체계를 만들 때 평가가 어디서 왔는지보다 무엇을 테스트하는지를 기준으로 삼으라고 조언한다. 예를 들어 외부 벤치마크에서 온 과제를 단순히 외부 벤치마크라고 묶으면, 그 과제가 검색 능력을 보는지 도구 사용 능력을 보는지 드러나지 않는다. 딥 에이전트 팀은 파일 읽기·쓰기·검색·페이지네이션을 보는 파일 작업, 여러 파일에서 정보를 찾고 종합하는 검색, 올바른 도구 선택과 다단계 호출을 보는 도구 사용, 맥락과 선호를 기억하는 메모리, 모호한 요청에 질문하고 다중 턴을 유지하는 대화, 컨텍스트 초과와 요약 복구를 보는 요약 같은 범주를 사용한다. 이러한 중간 수준의 분류는 전체 평균 하나만 보는 것보다 구체적이고, 개별 실행만 보는 것보다 전체 경향을 파악하기 쉽다.

6. 정확성을 먼저 보고, 그다음 효율성을 비교한다

모델을 선택할 때 저자들이 가장 먼저 보는 기준은 정확성이다. 관심 있는 작업을 안정적으로 해결하지 못하는 모델이라면 다른 장점은 의미가 없기 때문이다. 정확성 측정 방식은 평가 대상에 따라 달라진다. 내부 평가는 에이전트가 도구 호출을 병렬화했는지 같은 맞춤형 단언을 사용할 수 있고, 외부 벤치마크는 데이터셋의 정답과 정확히 맞추는 방식을 사용할 수 있으며, 기억에 올바른 내용을 저장했는지처럼 의미적 판단이 필요한 경우에는 언어모델 심판을 사용할 수 있다. 여러 모델이 이 기준을 통과하면 그다음에는 효율성을 본다. 같은 문제를 맞게 풀어도 불필요한 턴, 과도한 도구 호출, 느린 진행은 실제 서비스에서 지연 시간과 비용 증가, 나쁜 사용자 경험으로 나타나기 때문이다.

7. 이상적 궤적으로 성공 방식까지 측정한다

정확히 답했는지만으로는 모델 비교가 충분히 실행 가능해지지 않기 때문에, 글은 모델이 어떻게 성공하고 실패하는지도 본다고 설명한다. 이를 위해 사용하는 개념이 이상적 궤적이다. 이상적 궤적은 불필요한 행동 없이 올바른 결과에 도달하는 단계들의 순서로, 단순하고 범위가 명확한 작업에서는 최적 경로를 비교적 분명하게 정의할 수 있다. 더 열린 과제에서는 현재까지 가장 잘 수행한 모델의 궤적을 기준으로 삼고, 모델과 하네스가 개선되면 그 기준을 다시 검토한다. 현재 시간과 날씨를 묻는 예시에서는 사용자 확인, 위치 확인, 시간과 날씨 조회를 최소 도구 호출로 수행하고 독립적인 호출은 병렬화하는 경로가 이상적 실행으로 제시된다. 반대로 정답은 맞지만 단계와 도구 호출이 늘고 병렬화를 하지 않는 실행은 더 느리고 비싸며 실패 가능성도 더 높다.

8. 실행 환경은 재현성과 표적 실험을 중시한다

딥 에이전트 팀은 평가를 파이테스트와 깃허브 액션에서 실행해 깨끗하고 재현 가능한 환경에서 변경 사항을 검증한다. 각 평가는 특정 모델로 딥 에이전트 인스턴스를 만들고 과제를 입력한 뒤, 정확성과 효율성 지표를 계산하는 방식으로 구성된다. 전체 평가를 항상 모두 돌리는 대신 태그를 사용해 일부 평가만 실행할 수 있으며, 이는 비용을 줄이고 특정 실험의 효과를 더 직접적으로 측정하는 데 도움이 된다. 예를 들어 로컬 파일 처리와 종합이 중요한 에이전트를 만들 때는 파일 작업과 도구 사용 범주에 집중할 수 있다. 글은 이러한 평가 구조와 구현이 오픈소스 저장소에 공개되어 있다고 설명하며, 앞으로는 평가 세트 확장, 오픈소스 모델 비교, 에이전트의 실시간 자동 개선, 평가의 유지·축소·확장 방식 공유를 이어가겠다고 말한다.

🧾 핵심 주장 / 시사점

• 좋은 에이전트 평가는 벤치마크를 많이 모으는 작업이 아니라, 제품에서 반복적으로 문제가 되는 행동을 관찰하고 그 행동을 재현 가능한 측정 단위로 바꾸는 작업에 가깝다.
• 정확성과 효율성을 분리해 보면, 같은 정답을 내는 모델 사이에서도 실제 운영 비용과 사용자 경험을 크게 가르는 차이를 더 선명하게 볼 수 있다.
• 평가에 문서화, 태그, 추적 로그, 재현 가능한 실행 환경을 결합하면 평가 세트가 일회성 테스트 묶음이 아니라 팀이 함께 관리하는 행동 설계 도구가 된다.

✅ 액션 아이템

• 핵심 행동은 파일 탐색·도구 호출·검색·기억·대화 유지로 정의하고, 이를 직접 측정하는 표적 평가군부터 우선 설계한다.
• 모델 후보는 정확도를 통과한 뒤 단계 수, 도구 호출 수, 지연 시간, 비용을 함께 비교해 효율 우위를 판별한다.
• 실패 사례·추적 로그·외부 벤치마크 수정본·수작업 행동평가를 결합해 반복 개선용 평가 데이터셋을 정비한다.

❓ 열린 질문

• 현재 제품에서 가장 큰 품질 압력을 주는 핵심 행동은 무엇이며 우선순위는 어떤 기준으로 결정할 것인가?
• 평가를 태그/분류할 때 실행 범위는 줄이면서도 실패 패턴과 회귀를 놓치지 않으려면 어떤 설계가 가능한가?
• 정확도 임계 통과 후 단계 수·도구 호출 수·지연·비용을 결합할 때 모델 교체 판단 기준은 어떤 방식이 적절할까?