FetchSandbox

샌드박스는 호출 사이에 상태를 보존한다. 그래서 네가 만든 고객은 청구할 때도 남아 있고, Webhook은 실제 서비스처럼 발화한다. 이게 중요하다. 통합 버그 대부분은 단일 요청이 아니라 순서에 산다. 운영은 그대로 두고 실제 API처럼 동작한다. 개발 중에 진짜 키도, 진짜 청구도 없다.

FetchSandbox는 단순한 API 테스트 도구가 아니라 검증 엔진으로 자신을 규정한다. 에이전트가 뭔가 고쳤다고 주장할 때, 도구는 같은 시나리오를 옛 코드와 새 코드에 대해 실행한다. 수정은 실행 전에 실패하고 실행 후에 통과할 때만 의미가 있으며, 이는 모호한 "괜찮아 보인다"를 종료 코드로 바꾼다. 회사가 내건 목표는 자동화할 수 있는 판정이며, 동료의 의견이 아니다.

MCP 서버는 샌드박스를 널리 쓰이는 AI 코딩 어시스턴트에 연결하고, CLI는 터미널 기반 워크플로를 담당한다. 둘 다 MIT 라이선스의 오픈 소스다. 호스팅 엔진, 샌드박스, Webhook 시뮬레이션이 돈을 내는 부분이다. 저장소를 맡기기 전에 통합 코드를 읽고 싶다면 이 구분이 유용하다.

Webhook은 대부분의 테스트 구성이 건너뛰는 부분이고, FetchSandbox가 힘을 쏟는 곳이기도 하다. Webhook을 복제하고, 이벤트를 순서 없이 전달하고, 오래된 이벤트를 발화해 핸들러가 어떻게 반응하는지 볼 수 있다. 각 워크플로는 필수 Webhook 이벤트와 불변 조건을 명세의 일부로 나열한다. "정말 됐나"에 마침내 답이 생긴다.

실행할 때마다 누구나 열고 재생할 수 있는 영수증 URL이 만들어진다. 이게 신뢰의 조각이다. 풀 리퀘스트나 Slack 스레드에 붙이면 리뷰어가 스크린샷을 믿지 않고 무슨 일이 있었는지 감사할 수 있다. 각 단계는 메서드, 경로, 응답 코드, 소요 시간을 갖고, 각 Webhook은 서명 검증 결과를 갖는다. 더는 추측할 필요가 없다.

카탈로그에는 Stripe, Twilio, Resend, Clerk, Privy, AgentMail, Surge, Kulipa, WorkOS 같은 공급자에 대한 기성 지원이 들어 있다. 하나를 고르면 빈 모의 서버가 아니라 몇 분 만에 동작하는 샌드박스가 나온다. 상위 요금제에서는 명세에서 자기 API를 최대 다섯 개까지 추가할 수 있고, 내부 서비스를 가진 팀이 결국 여기로 온다.

이미 통합이 하나 있는 저장소에 두 번째를 추가하면 도구는 둘 다 읽고 연결하며, 세 번째를 추가하면 셋 다 읽는다. 문서화된 한 사례에서 Clerk가 설정한 사용자 ID가 Stripe 결제 메타데이터로 흘러 들어가고, 다시 Resend 조회로 이어졌다. 고립된 모의 서버는 이걸 못 한다. 실제 코드베이스가 실제로 배선되는 방식에 이 제품이 가장 가까이 다가가는 지점이다.

요청한 시나리오가 성립하지 않으면 도구는 거짓 통과를 보고하는 대신 그렇다고 말하고 이유를 설명한다. 공개된 Stripe 세션에서 거절된 결제 시나리오가 실행되지 않았다고 짚었다. 선별된 워크플로의 해피 패스 테스트 카드가 그것을 덮어썼기 때문이며, 그 뒤 그 분기를 연습할 정확한 명령을 나열했다. 도구의 한계를 아는 것이 믿을 수 없는 초록 체크보다 유용하다.