AI 에이전트가 실제 Stripe 통합을 만들 수 있을까? 벤치마크로 검증했다

LLM이 함수 구현이나 파일 단위 리팩터링은 잘해도, 실제 소프트웨어 엔지니어링처럼 장기적으로 계획하고 상태를 유지하며 실패를 복구하는 일은 별개라는 문제의식에서 출발했다. Stripe는 결제 통합이 100% 정확도를 요구한다는 점에 주목해, 단순 코드 생성이 아니라 검증과 테스트까지 수행할 수 있는지를 보려 했다.

이를 위해 11개 환경으로 구성된 Stripe integration benchmark를 만들었다. 환경은 실제 저장소처럼 코드, 데이터베이스, 스크립트를 포함하고, 테스트용 Stripe API key도 제공한다. 채점은 주로 결정적 테스트로 이뤄졌고, API 호출이나 자동 UI 테스트, Stripe 객체 검증을 통해 제출물을 판정했다. 실행 하네스는 goose 기반이며, 모델에게 터미널, 브라우저, Stripe 전용 검색 도구를 제공하는 MCP 서버를 붙였다.

평가 과제는 세 부류로 나뉘었다.

• Backend-only tasks: Stripe API 버전 변경, 데이터 마이그레이션, 백엔드 API 업데이트 같은 서버 측 작업
• Full-stack tasks: 서버와 클라이언트가 모두 포함된 통합 과제, 최종 제출을 위해 브라우저 사용이 필요
• Gym problem sets: Checkout, subscriptions처럼 특정 Stripe 기능을 깊게 파고드는 시뮬레이션 문제 세트

결과는 예상보다 강했다. 저자들은 backend-only에서 어느 정도 성과를 기대했지만, 실제로는 모델들이 UI를 탐색하고, 라이브 이슈를 디버깅하고, 문서화가 부족한 동작까지 다뤘다. 특히 Claude Opus 4.5는 full-stack API integration 과제에서 평균 **92%**를 기록했고, OpenAI GPT-5.2는 gym 문제 세트에서 평균 **73%**를 기록했다. 가장 잘한 실행은 평균 63 turns까지 이어졌다.

인상적인 사례도 있었다. card element to checkout session 과제에서 에이전트는 레거시 Card Element UI를 Checkout으로 전환한 뒤, 브라우저에서 실제 테스트 구매까지 수행했다. 결제 수단은 명시되지 않았지만, 한 실행에서는 Stripe가 만든 디지털 지갑 Link를 사용해 끝까지 완료했다.

Checkout gym 과제에서는 20개의 미리 만들어진 Checkout UI를 보고, 그 뒤에 필요한 API 호출을 역추적해야 했다. 에이전트는 먼저 UI에서 상품과 수량을 확인하고, Products API에서 product ID를 찾고, shipping amount·custom field·tax collection 여부 같은 설정을 파악한 뒤, 이를 Checkout Session API 파라미터로 바꿔야 했다. 평가 결과 에이전트들은 이 작업의 80% 이상에 해당하는 파라미터를 맞혔고, 더 복잡한 UI에서는 추가 드롭다운 옵션까지 클릭해 확인한 뒤 반영하기도 했다.

하지만 한계도 분명했다. 일부 에이전트는 존재하지 않는 Stripe 데이터를 넣어 400 응답을 받고도 작업이 끝났다고 판단하는 등, 애매한 상황을 제대로 해석하지 못했다. 또 브라우저 작업 중 입력 포커스를 잃거나 frame에 갇힌 뒤, 간단한 새로고침이나 재클릭으로 복구할 수 있었는데도 스스로 실패로 결론내리는 경우가 있었다.

핵심 메시지는 분명하다. 실제 통합은 코드 한 조각을 잘 쓰는 것만으로 끝나지 않고, 검증, 상태 관리, 브라우저 상호작용, 오류 복구까지 포함한다. Stripe는 이 벤치마크를 공개해 에이전트용 프롬프트, skills, browser tool 같은 개입이 실제 성능을 얼마나 높이는지 반복적으로 측정할 수 있는 실험대가 되길 기대하고 있다.