How Ramp Tests Its AI Bookkeeping Agent Before Customers Do - Ryan Stevens, Ramp

한 줄 핵심

Ramp는 AI 회계 에이전트를 출시하기 전에 합성 데이터와 백테스트형 평가 체계를 먼저 구축해, 모델 선택·실패 원인 분석·메모리 검증·회귀 테스트까지 운영하며 성능을 지속적으로 끌어올린다.

시간별 요약

1. 0:00
   소개 Ramp의 Stacks 같은 AI 에이전트를 더 잘 만들기 위해 종단 간 평가를 어떻게 설계하고 활용하는지 설명한다. 핵심 관심사는 측정과 검증이며, 이를 통해 에이전트 성능을 실제로 끌어올리는 방법에 있다.
2. 0:47
   에이전트의 목표는 무엇인가? 에이전트를 만들 때는 먼저 목표, 평가 기준, 그리고 평가로부터 얻을 가치를 순서대로 정해야 한다. 잘 모르는 업무를 대충 자동화하기보다, 작업을 분해하고 성공 정의부터 명확히 해야 한다.
3. 1:16
   회계 담당자의 업무를 분해하기 회계 담당자의 일을 여러 범주로 나누고, 각 작업의 성공 조건을 정의한 뒤 업계 실무자와 함께 전체 프로세스를 구체화한다. 예를 들어 reconciliation은 서로 다른 시스템의 수치를 맞추고, 어긋난 이유를 찾아 다시 일치시키는 과정으로 분해된다.
4. 2:43
   벤치마크 만들기 평가 대상은 reconciliation, data entry, variance analysis, schedules and accruals 같은 회계 작업 범주로 구성된다. 벤치마크, evals, verifiability는 사실상 같은 목적을 가진 서로 다른 표현으로 다뤄진다.
5. 3:20
   사용자 전과 후의 차이 사용자가 충분하지 않은 단계에서는 시뮬레이션과 합성 데이터가 필수이며, 에이전트 평가는 결국 가상의 환경에서 먼저 검증해야 한다. 사용자 데이터가 쌓인 뒤에는 더 쉬워질 수 있지만, 이 발표에서는 그 단계보다 합성 평가 구축에 초점을 맞춘다.
6. 4:26
   데이터가 병목이다 평가를 제대로 하려면 먼저 깨끗한 데이터가 있어야 하므로, 데이터 품질이 eval의 병목이 된다. 따라서 어떤 데이터셋과 task criteria를 만들지 자체가 평가 설계의 핵심이다.
7. 4:48
   합성 기업 만들기 D2C lifestyle company 같은 합성 기업을 만들고, ERP·고객 목록·공급업체 목록·accounts payable 등 필요한 문서를 모두 구성해 오프라인 평가 환경을 만든다. 이 방식은 사실상 에이전트를 동일한 데이터로 반복 백테스트하는 작업이다.
8. 5:45
   평가는 곧 백테스트다 평가, verifiability, benchmark는 결국 성공을 측정하기 위한 백테스트에 가깝다. 생산 환경의 에이전트를 제대로 다루려면 시간에 따른 상태를 보존해 재현 가능한 테스트가 가능해야 한다.
9. 7:08
   각 작업의 채점 방식 각 task는 보통 10~20개의 기준으로 채점하고, 실행 경로 자체보다 최종 결과의 정답 여부를 중심으로 본다. 초기에는 경로 최적화보다 정확도, 비용, 속도가 더 중요하며, 이런 평가 체계를 만드는 데 4~6개월이 걸릴 수 있다.
10. 9:14
    정확도와 pass@k 정확도는 부분 점수를 반영하는 반면, pass@k는 특정 시도에서 모든 기준을 통과해야 하는 전부 아니면 전무의 지표다. 회계처럼 오류 비용이 큰 영역에서는 pass@k가 더 적절할 수 있다.
11. 10:24
    모델 고르기 구축한 eval을 이용하면 어떤 frontier model이 가장 잘 작동하는지 비교할 수 있다. 다만 최고 모델을 써도 pass@1이 낮을 수 있어, 하네스 최적화 없이는 문제를 자동으로 해결할 수 없다.
12. 11:18
    모델이 실패하는 이유: 추론 실패 원인을 더 쪼개보면, 회계 업무에서는 정보 수집 부족보다 추론 실패가 더 큰 비중을 차지한다. 즉 필요한 데이터는 잘 모으더라도, 그 데이터를 올바르게 해석하지 못해 실패하는 경우가 많다.
13. 12:18
    실패한 실험들 여러 자동 튜닝과 auto research 시도는 기대만큼 효과가 없었고, 텍스트 공간에서 hill climbing으로 방향성을 얻기 어렵다는 점이 드러났다. 자동화된 연구가 나쁜 에이전트를 스스로 해결해줄 것이라는 기대는 과장될 수 있다.
14. 13:36
    스킬 제거 실험 스킬이 많을수록 성능에 어떤 차이가 나는지 보기 위해 skill ablation을 수행하고, 불필요한 스킬을 줄여 컨텍스트를 절약하려 했다. 결과적으로 스킬의 유무가 성능에 의미 있는 차이를 만들며, 삭제·압축 후보를 찾는 데 유용했다.
15. 15:01
    메모리 테스트 메모리 시스템은 보통 잘 테스트되지 않지만, 동일한 작업을 시간차를 두고 다시 수행하는 roll forward worlds로 성능을 검증할 수 있다. 이 방식으로 메모리를 쓰고 다시 읽게 하면, 어떤 기억이 기록되느냐와 성공률 사이에 큰 상관이 드러난다.
16. 17:01
    백그라운드에서의 회귀 테스트 agentic eval을 CI 게이트로 막는 대신, 내부 플랫폼에서 정기적으로 돌리며 회귀를 추적하는 방식이 더 실용적이다. 실패 사례를 태깅하고 배경 에이전트가 분석해 Slack으로 알림을 보내면, 문제를 지속적으로 감시할 수 있다.
17. 18:07
    핵심 정리 좋은 에이전트를 만들려면 업무를 세분화하고, 현실적인 환경을 구축하고, 평가에서 나온 가치를 워크플로에 연결해야 한다. 결국 중요한 것은 성능을 한 번 재는 것이 아니라, 반복적으로 측정하고 개선하는 체계를 만드는 일이다.

실무 인사이트

• 에이전트 평가는 모델 교체보다 먼저 해야 할 작업이며, 특히 합성 데이터와 재현 가능한 백테스트 환경을 먼저 갖추면 출시 전 실패를 훨씬 싸게 잡을 수 있다.
• 회계처럼 정답성이 중요한 업무는 평균 정확도보다 pass@k와 회귀 테스트가 더 실용적이며, 최종 산출물의 신뢰성을 중심으로 설계해야 한다.
• 메모리와 스킬은 “넣으면 좋아 보이는 기능”이 아니라 실제로 성능 기여가 있는지 ablation으로 검증해야 하며, 그 결과로 컨텍스트와 복잡도를 줄일 수 있다.