🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

스트라이프는 실제 결제 통합에 필요한 장기 계획, 전체 스택 구현, 브라우저 검증과 실패 복구 능력을 평가하기 위해 운영 환경에 가까운 에이전트 벤치마크를 구축했다.

📌 핵심 요약

• 스트라이프는 제한된 코딩 문제 해결 능력과 실제 소프트웨어 프로젝트를 자율적으로 완수하는 능력 사이의 격차를 측정하기 위해 통합 벤치마크를 만들었다.
• 벤치마크는 코드베이스, 데이터베이스, 스크립트와 테스트용 API 키를 갖춘 11개 환경으로 구성됐으며, 결정론적 API·UI 테스트와 스트라이프 객체 검사를 통해 결과를 채점했다.
• 클로드 오퍼스 4.5는 4개 전체 스택 과제에서 평균 92%, GPT-5.2는 2개 짐 문제 세트에서 평균 73%를 기록했고, 최고 성능 실행들은 평균 63턴 동안 작업했다.
• 에이전트들은 레거시 결제 화면을 체크아웃으로 전환하고 브라우저에서 구매를 완료하거나, 20개 체크아웃 화면을 분석해 필요한 API 매개변수의 80% 이상을 맞히는 성과를 보였다.
• 반면 유효하지 않은 테스트 데이터로 발생한 오류를 정상 검증으로 오인하거나 브라우저 조작 실패에서 복구하지 못하는 문제가 나타나, 완전한 검증과 상황 판단이 여전히 핵심 과제로 남았다.

🧩 주요 포인트

1. 결제 통합은 코드 생성만으로 끝나지 않으며 패키지 변경, 데이터 상태 관리, 프런트엔드 조작과 실제 결제 결과 확인까지 연결해야 하므로 장기 실행 능력이 성패를 좌우한다.
2. 모델들은 예상보다 높은 전체 스택 작업 능력과 문서화가 부족한 동작을 탐색하는 능력을 보였지만, 모호한 성공 조건과 복구 가능한 도구 오류를 적절히 판단하는 데에는 불안정성을 드러냈다.
3. 재현 가능한 환경과 명확한 채점기는 프롬프트, 기술 지침, 브라우저 도구 등의 개선 효과를 반복 측정하고 실제 통합 정확도를 높이는 실험 기반으로 활용될 수 있다.

🧠 상세 정리

1. 제한된 코딩 능력과 실제 프로젝트 수행의 격차

최신 대형 언어 모델은 함수 구현이나 파일 단위 리팩터링처럼 범위가 제한된 코딩 문제의 상당수를 해결할 수 있지만, 전체 소프트웨어 프로젝트를 자율적으로 관리하는 능력은 충분히 측정되지 않았다. 실제 소프트웨어 개발은 장기간의 계획, 지속적인 상태 관리, 여러 단계의 실행과 실패 후 복구를 함께 요구한다. 사용 편의성을 중시한 스트라이프 API를 통합할 때도 새로운 API 처리, 프런트엔드 테스트, 데이터베이스 마이그레이션처럼 서로 다른 영역을 잇는 작업이 필요하다. 특히 결제 시스템에서는 대체로 맞는 구현만으로는 부족하므로, 에이전트가 코드를 작성하는 능력뿐 아니라 인간 엔지니어 수준의 엄격함으로 결과를 검증하고 테스트할 수 있는지가 핵심 평가 대상이 됐다.

2. 벤치마크가 검증하려는 세 가지 능력

연구진은 먼저 모델이 스트라이프 API의 개념과 사용 방식을 얼마나 정확히 이해하는지 확인하려 했다. 다음으로 서버 측 로직과 클라이언트 측 화면을 포함한 여러 구성 요소에 걸쳐 올바른 코드를 작성할 수 있는지를 평가 대상으로 삼았다. 마지막으로 패키지 갱신, 데이터베이스 상태 관리, 스크립트 실행, 문서 검색과 브라우저 확인을 하나의 흐름으로 연결해 실제로 작동하는 통합을 완성할 수 있는지를 살폈다. 이러한 질문을 평가하기 위해 단편적인 코드 생성 시험이 아니라 전체 코드베이스 안에서 실행하고 오류를 수정하며 최종 결과까지 제출해야 하는 운영 환경에 가까운 과제가 설계됐다.

3. 11개 환경과 자동 채점 구조

스트라이프의 제품 및 기술 지원 엔지니어들은 체크아웃 흐름 이전이나 빌링 API를 이용한 사업 모델 구현처럼 실제 고객이 마주칠 수 있는 사례를 바탕으로 과제를 구상했고, 총 11개의 서로 다른 실행 환경을 만들었다. 각 환경에는 일반적인 통합 프로젝트의 출발점을 나타내는 코드, 데이터베이스와 스크립트가 포함됐으며, 에이전트가 시험과 제출 검증에 사용할 수 있는 테스트용 스트라이프 API 키도 제공됐다. 채점기는 완성된 소프트웨어를 API 호출이나 자동화된 사용자 인터페이스 테스트로 실행하는 결정론적 검사로 구현됐고, 일부 과제에서는 실행 중 생성된 스트라이프 API 객체까지 확인했다. 예를 들어 화면에서 결제를 완료한 과제라면 테스트 모드에서 성공한 체크아웃 세션 객체가 실제로 존재하는지 검사해, 코드 모양이 아니라 실행 결과를 기준으로 평가했다.

4. 일관된 도구 환경과 세 가지 과제 유형

모든 모델은 구스 기반의 동일한 에이전트 하네스에서 평가됐으며, 모델 문맥 프로토콜 서버를 통해 터미널, 브라우저와 스트라이프 전용 검색 도구를 사용할 수 있었다. 과제는 서버 측 데이터 마이그레이션, API 버전 변경과 백엔드 API 갱신을 다루는 백엔드 전용 작업으로 구성됐다. 서버와 클라이언트 통합을 함께 수정하고 최종 제출 과정에서 브라우저를 사용해야 하는 전체 스택 작업도 별도 범주로 마련됐다. 체크아웃이나 구독의 특정 기능을 깊이 평가하는 짐 문제 세트에서는 배송 요금 맞춤 설정이나 무료 체험 동작 변경처럼 더 고급인 구성을 다뤘으며, 환경의 현실성과 반복 가능한 명확한 채점 기준을 동시에 확보하는 데 실제 소프트웨어 개발에 준하는 기술 작업이 필요했다.

5. 예상을 넘어선 전체 스택 수행 결과

연구진은 2025년 중반의 초기 모델 평가를 바탕으로 백엔드 전용 과제에서는 준수한 결과가 나오지만 전체 스택을 조율하는 작업에서는 모델이 어려움을 겪을 것으로 예상했다. 그러나 실제 평가에서는 모델들이 사용자 인터페이스를 탐색하고 실행 중인 문제를 디버깅했으며, 문서화가 충분하지 않은 동작까지 처리하는 모습을 보였다. 클로드 오퍼스 4.5는 전체 스택 과제 4개에서 평균 92%를 기록했고, GPT-5.2는 짐 문제 세트 2개에서 평균 73%를 기록했다. 평가된 모든 모델은 긴 시간 동안 생산적으로 작업할 수 있었고 최고 성능 실행들은 평균 63턴에 이르러, 단발성 코드 응답을 넘어 여러 단계의 작업을 지속하는 능력을 보여줬다.

6. 레거시 결제 화면 전환과 브라우저 자체 검증

카드 엘리먼트를 체크아웃 세션으로 전환하는 과제에서 에이전트들은 먼저 기존의 레거시 카드 엘리먼트 사용자 인터페이스를 스트라이프 체크아웃 기반 통합으로 업그레이드했다. 이후 변경 사항을 자체 검증하기 위해 브라우저에서 테스트 구매를 실제로 완료하도록 요구받았으며, 이는 코드 수정뿐 아니라 실행 중인 웹 애플리케이션과 외부 결제 화면을 연결해 다뤄야 하는 단계였다. 연구진이 사용할 결제 수단을 구체적으로 지정하지 않았음에도 한 실행에서는 에이전트가 스트라이프의 디지털 지갑인 링크를 선택해 결제를 처음부터 끝까지 성공시켰다. 이 사례는 일부 실행에서 에이전트가 주어진 목표와 화면 상태를 해석하고, 명시되지 않은 세부 선택을 수행하면서 전체 결제 흐름을 완결할 수 있었음을 보여준다.

7. 20개 체크아웃 화면을 API 호출로 역설계

체크아웃 짐 과제에서는 미리 구성된 20개의 체크아웃 화면을 탐색하고, 각 화면을 생성하는 데 사용된 API 호출과 매개변수를 역으로 찾아내도록 했다. 에이전트는 화면에 표시된 상품과 수량을 확인한 뒤 제품 API의 카탈로그에서 올바른 제품 식별자를 찾고, 배송 금액, 사용자 지정 필드와 세금 징수 여부 등의 설정을 구분해야 했다. 이어서 화면에서 발견한 상품 및 기능을 체크아웃 세션 API의 정확한 매개변수로 변환해야 했으며, 평가 결과 에이전트들은 필요한 매개변수의 80% 이상을 맞혔다. 복잡한 사례에서는 화면만 보고 알 수 없던 사용자 지정 색상 선택 항목을 에이전트가 직접 클릭해 추가 옵션을 확인한 뒤 매개변수에 반영함으로써, 단순 시각 확인보다 더 깊은 상호작용과 재검증을 수행했다.

8. 모호한 검증과 브라우저 복구에서 드러난 한계

대표적인 실패 유형은 모호한 상황에서 합리적인 검증 기준을 세우지 못하는 것이었다. 스트라이프 SDK를 호환성이 깨지는 버전으로 갱신하는 과제에서 일부 에이전트는 존재하지 않는 고객 데이터를 보내 400 오류가 발생한 것을 보고, 잘못된 고객 식별자에 대해 적절한 오류가 반환됐다는 이유로 작업이 완료됐다고 판단했다. 더 성공적인 실행은 테스트 데이터를 생성하는 스크립트를 작성하고 그 유효한 데이터로 변경된 동작을 검사해, 핵심 기능이 유지됐는지를 더 직접적으로 확인했다. 브라우저 작업에서도 한 에이전트가 여러 조작을 한 번에 수행하다 체크아웃 화면의 프레임을 선택해 입력란의 초점을 잃었고, 새로고침이나 외부 영역 클릭으로 복구할 수 있었지만 이를 시도하지 않은 채 진행 불가로 결론 내리면서 최종 테스트에 실패했다.

9. 재현 가능한 벤치마크를 통한 반복 개선

스트라이프 고객의 결제 통합은 각 사업 요구에 맞게 완전하고 정확해야 하므로, 벤치마크의 궁극적인 과제는 에이전트가 그 기준에 도달하고 실패 시 경로를 수정하도록 돕는 것이다. 재실행 가능한 환경과 명확한 과제를 결합하면 새로운 프롬프트, 기술 지침, 브라우저 도구나 다른 개입 방법을 시험하고 실제 성능 향상 여부를 비교할 수 있다. 프로젝트 초기 평가에서는 모델이 스트라이프 문서와 모델 문맥 프로토콜 도구를 실제로 조회하는 방식이 드러났으며, 그 과정에서 발견된 여러 문서 오류도 수정됐다. 스트라이프는 초기 벤치마크를 자사의 인공지능 도구 모음에 공개하고 향후 더 많은 통합 사례로 확장해 모델 역량의 변화를 추적할 계획이며, 소프트웨어 공동체의 피드백과 협업 및 후속 과제 제안을 요청했다.

🧾 핵심 주장 / 시사점

• 실제 API 통합 역량은 코드의 문법적 정확성보다 유효한 테스트 데이터를 만들고, 사용자 인터페이스와 외부 API 객체를 대조해 성공을 입증하는 능력에서 더 엄격하게 드러난다.
• 모델은 복잡한 화면 탐색과 장시간 작업을 수행할 수 있지만, 오류가 기대된 결과인지 불완전한 시험의 산물인지 판단하는 검증 전략에서는 실행별 편차가 나타났다.
• 도구 조작 중 발생한 작은 상태 오류도 복구 판단이 없으면 전체 과제 실패로 이어지므로, 벤치마크는 구현 능력뿐 아니라 실패 인식과 경로 수정 능력을 측정해야 한다.

✅ 액션 아이템

• 결제 통합 벤치마크 범위를 장기 계획, 전체 스택 구현, 브라우저 검증, 실패 복구까지 포함해 정의한다.
• 채점 기준에 결정론적 API·UI 테스트와 스트라이프 객체 검사를 넣어 성공·실패를 모호하지 않게 판정한다.
• 유효하지 않은 테스트 데이터 오판과 브라우저 조작 실패 복구를 별도 과제로 두고 반복 측정한다.

❓ 열린 질문

• 11개 환경에서 장기 실행 능력을 가를 핵심 병목은 코드 생성, 상태 관리, 브라우저 검증 중 어디인가?
• 클로드 오퍼스 4.5의 92%와 GPT-5.2의 73% 격차를 어떤 과제 조건으로 설명할 것인가?
• 오류를 정상 검증으로 오인하지 않으려면 에이전트에 어떤 상황 판단 기준이 필요한가?