엔드투엔드 평가로 더 나은 에이전트 만들기 (Building Better Agents through End-to-End Evals)

Building Better Agents through End-to-End Evals

Deeply understand the task at hand The biggest mistake teams make with agents is...

Ryan Stevens2026-10-14

개요 #

Ramp 팀은 회계 업무를 자동화하는 에이전트 'Ramp Stack'을 만들면서 엔드투엔드 평가(end-to-end eval)를 개발 과정의 중심에 뒀습니다. 이 평가로 어떤 기능을 남기고 어떤 기능을 뺄지 정했습니다.

결과도 숫자로 나왔습니다. 스킬을 8개에서 4개로 줄였더니 평균 점수가 2.8점 올랐습니다. 가장 큰 스킬의 분량을 61% 줄였을 때는 품질이 거의 그대로였고 비용은 매달 약 3만 달러 줄었습니다. 반면 자동 프롬프트 최적화나 높은 추론 강도(reasoning effort)처럼 많이 알려진 방법은 효과가 없었다고 합니다.

한마디로, 에이전트를 만들 때도 ML 모델을 만들 때만큼 엄격해야 한다는 얘기입니다.

본문 #

자동화하기 전에 사람이 일하는 방식부터 이해하기 #

글쓴이는 팀들이 가장 많이 하는 실수로 잘 모르는 업무를 자동화하려는 것을 꼽습니다. 코드를 쓰기 전에 사람이 그 일을 어떻게 하는지 정확히 설명할 수 있어야 한다는 얘기입니다.

Ramp 팀은 자동화할 부기(bookkeeping) 업무를 네 가지로 나눴습니다.

대사(reconciliation)
데이터 입력
차이 분석(variance analysis)
스케줄 및 발생주의 처리(schedules and accruals)

이렇게 나눠 두면 평가 항목이 실제 업무 전반에 고르게 퍼집니다. 나중에는 에이전트가 어느 영역에서 약한지도 바로 보입니다.

다음으로 업무 하나하나를 단계로 쪼갭니다. 매입채무(AP) 대사를 예로 들면, 회계 담당자는 미지급 청구서와 AP 원장을 가져와 스프레드시트에 나란히 놓고 맞지 않는 부분을 조사합니다. 청구서 합계가 3,500달러인데 원장에는 3,000달러로 적혀 있다면 빠진 500달러짜리 청구서를 찾아 정정을 기록해야 합니다. 이 단계 하나하나가 에이전트가 해야 할 일이고, 평가에서 확인해야 할 항목입니다.

데이터가 병목이다 #

엔드투엔드 평가는 어느 단계에서든 구조가 같습니다. 비즈니스 데이터를 데이터베이스에 채우고, 에이전트가 도구로 그 상태를 다루게 한 뒤, 결과물을 채점합니다. 문제는 출시 전에는 쓸 데이터가 없다는 점입니다. 그래서 데이터를 시뮬레이션해야 합니다.

Ramp 팀은 가상의 회사를 만들었고, 이를 '월드(world)'라고 부릅니다. 예를 들어 한 월드는 Shopify, Amazon, 도매로 판매하는 D2C 홈 굿즈 브랜드입니다. 장부 일체와 현실적인 거래 내역, 지저분한 엑셀 파일까지 갖추고 있습니다.

핵심은 이 '지저분함'입니다. 많은 팀이 지나치게 깨끗한 데이터를 만듭니다. 그러면 오프라인 평가에서는 결과가 좋아 보여도 실제 사용자 앞에서는 버티지 못합니다.

평가 케이스는 네 가지로 구성된다 #

평가 케이스 하나는 다음 네 요소로 이뤄집니다.

과제(Task): "2025년 4분기 AP 채무와 청구서를 대사해 줘" 같은 요청
월드(World): 에이전트가 접근하는 합성 ERP와 비즈니스 데이터
궤적(Trajectory): 청구서 읽기, 지급 내역 매칭, 차이 조사처럼 에이전트가 밟는 단계
점수(Score): 회계 담당자가 작성한 기준으로 만든 루브릭. 최종 결과물을 LLM 심사자(LLM judge)가 채점

평가를 쓸모 있게 만드는 건 루브릭입니다. 통과/실패만 보면 부분적인 진전이 드러나지 않습니다. "4분기 AP 잔액이 정확한가", "중복 항목을 표시했는가" 같은 기준을 여섯 개 두면 에이전트가 6개 중 4개를 맞혔고 어떤 두 개를 놓쳤는지까지 알 수 있습니다. 글쓴이는 기준을 도메인 전문가가 쓰게 하라고 권합니다. 검토자가 실제로 무엇을 반려할지는 그들이 가장 잘 알기 때문입니다.

평가 결과로 의사결정하기 #

평가는 실제 의사결정을 바꿀 때 제값을 합니다. 첫 번째 결정은 모델 선택이었습니다. 다만 가장 큰 이득은 하네스(harness) 튜닝에서 나왔다고 합니다. 스킬과 도구, 인프라를 다듬어 낮은 비용과 지연 시간으로 좋은 결과를 내는 작업입니다.

효과가 없었던 방법

자동 튜닝 스킬(GEPA 방식 autoresearch): 학습 데이터에서 얻은 성능 향상이 일반화되지 않았습니다. 글쓴이는 자동 프롬프트 최적화가 효과 있다는 좋은 근거를 아직 보지 못했다고 밝혔습니다.
높은 추론 강도: 정확도는 같은데 비용만 올라갔습니다.

효과가 있었던 방법

Ramp 팀은 에이전트를 ML 모델처럼, 컨텍스트를 피처(feature)처럼 다뤘습니다.

스킬 제거 실험(ablation): 스킬이 없는 기준선과 비교하며 스킬을 하나씩 따로 측정했습니다. 그 결과 스킬을 8개에서 4개로 줄였고, 월드 6개에서 평균 점수가 2.8점 올랐습니다. 오히려 성능을 떨어뜨리는 스킬이 여럿 있었고, 모든 월드에서 가장 좋은 스킬은 하나도 없었습니다.
스킬 압축: 가장 큰 스킬인 스프레드시트 스킬을 61% 줄였습니다. 품질은 사실상 그대로였고 비용은 매달 약 3만 달러 줄었습니다.

정리하면, 모든 변경을 고정된 기준선과 비교하고 여러 월드에서 측정한 뒤 점수를 올리는 것만 남기는 방식입니다.

다들 건너뛰는 영역, 메모리 평가 #

메모리는 시간이 지나야 확인할 수 있어서 평가하는 팀이 드뭅니다. Ramp 팀은 '롤포워드(roll-forward) 월드'를 만들었습니다. 같은 회사를 한 달 뒤로 진행시킨 월드입니다. 에이전트가 이번 달 결산을 마치고 배운 내용을 기록하면, 다음 달 과제로 채점합니다.

여기서 얻은 원칙은 "회사가 돌아가는 방식은 기억하되, 숫자는 새로 쓴다"입니다.

이전 궤적에서 뽑아낸 메모리에서 특정 기간의 금액을 지웠더니, 스킬만 쓸 때보다 평균 점수가 5.7점 높았습니다.
재사용할 수 있는 작업 흐름을 담은 메모리 하나로 어떤 과제는 0%에서 100%가 됐습니다.
반대로 지난달의 구체적인 처리 방법을 그대로 끌어온 메모리 때문에 다른 과제는 75%에서 25%로 떨어졌습니다.

결론 #

글쓴이는 에이전트 개발에도 ML 개발과 같은 규율이 필요하다고 말합니다. 먼저 업무 과정을 이해해야 합니다. 그다음 의미 있을 만큼 어렵고, 실행 결과를 비교할 수 있을 만큼 안정적인 데이터셋을 만들어야 합니다. 무엇을 출시할지는 직관이 아니라 그 데이터셋으로 정하라는 것이 글의 결론입니다.

이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.