Show GN: buttonmasher – 중복 결제와 재시도 버그를 찾아보는 Claude Code 스킬

결제 API에서 orders(cart_id)에 unique 제약을 걸어두면 이중 결제가 막힐까요? 결제 API를 먼저 호출하고 주문을 저장하는 구조라면 막히지 않습니다. 결제 버튼을 두 번 눌렀을 때 두 요청 모두 주문이 저장되기 전에 결제 API를 호출할 수 있기 때문입니다. unique 제약은 이후의 INSERT만 막습니다. 결과적으로 주문은 1건인데 결제는 2번 발생할 수 있습니다. 백엔드 개발을 하다 보면 이런 문제를 반복해서 만나게 됩니다. 웹훅이 재전송되면서 주문이 중복 생성되거나, 이미 취소된 예약에 다시 처리가 들어가는 경우도 있습니다. 일반적인 코드 리뷰에서는 이런 버그를 놓치기 쉽습니다. 코드 한 줄이 잘못됐다기보다 요청이 들어오는 순서와 시점에 따라 문제가 발생하기 때문입니다. 코드를 함수 단위로 읽는 것보다, 같은 요청을 두 번 보내거나 처리 중에 다시 요청이 들어오는 상황을 확인하고 싶었습니다. 그래서 이런 실행 순서를 집중적으로 점검하는 buttonmasher라는 Claude Code 스킬을 만들었습니다. 제출 버튼 연타, 타임아웃 후 재시도, 뒤로가기 후 재진입, 여러 탭에서의 동시 요청, 웹훅 재전송 등을 가정하고 코드를 분석합니다. 실행 환경이 준비되어 있으면 실제 요청으로 확인하고, 그렇지 않으면 코드 추적 결과라는 점을 구분합니다. 별도의 실행 프로그램은 아니고, 에이전트가 참고하는 마크다운 프롬프트 모음입니다. 주로 확인하는 문제는 두 가지입니다. 한 번만 실행돼야 하는 작업이 중복 실행되는 경우 이미 완료된 작업이 다시 실행되는 경우 직접 확인해 보기 앞서 설명한 unique 제약 사례는 저장소의 demo/에 넣어뒀습니다. 외부 패키지 설치 없이 Node.js로 실행할 수 있고, 터미널 하나에서 서버를 띄운 뒤 다른 터미널에서 스크립트로 동시 요청 두 개를 보내 재현할 수 있습니다. 수정 없음: 주문 2건, 결제 2건 unique 제약만 적용: 주문 1건, 결제 2건 unique 제약 + 결제 API 멱등성 키 적용: 주문 1건, 결제 1건 마지막 결과는 데모의 구현과 요청 조건에서 확인한 것입니다. 실제 서비스에서는 멱등성 키를 생성하고 보관하는 방식, 결제 API의 멱등성 지원 여부까지 고려해야 합니다. 일반 프롬프트와 비교 실제로 얼마나 도움이 되는지 확인하려고 일반적인 버그 탐색 프롬프트와 비교해 봤습니다. Claude Fable 5를 Claude Code에서 사용했...