Claude로 만든 getrequest, 첫 MVP에서 실패한 요청은 어디에 남겨야 할까요?

핵심 요약 (TL;DR)

getrequest 제작자는 2023년부터 만들고 싶었던 서비스를 Claude로 몇 주 동안 구현했다고 소개했습니다.[1] 공개 사이트가 제시하는 핵심은 API 요청을 중계하고 기록한 뒤, 실패한 요청을 다시 보내는 흐름입니다.[2] 첫 MVP를 만드는 분에게 이 사례는 ‘화면에서 저장을 눌렀다’와 ‘서버가 실제로 처리했다’ 사이를 어떻게 확인할지 묻습니다.

오래 품었던 아이디어는 무엇으로 구현됐나요?

한국 시간 10월 9일 오전 9시 50분, 제작자는 Hacker News에 서비스를 소개했습니다. 이는 확인된 소개 시점이며 최초 출시일을 뜻하지는 않습니다. 제작 기간과 Claude 활용은 작성자의 자기보고이고, 개발 과정을 별도로 감사한 결과는 아닙니다.[1]

공개 사이트는 서비스가 백엔드 앞에서 요청을 받아 헤더·본문·상태·지연 시간을 기록하고, 보관한 요청을 원래 내용으로 재전송할 수 있다고 설명합니다. 동기 전달과 비동기 전달을 구분하며, 비동기 방식은 호출자에게 먼저 응답한 뒤 백엔드에 전달한다고 안내합니다.[2] 여기서 확인한 것은 공개 기능 설명이지 실제 장애 복구 성능이 아닙니다.

저장 버튼을 눌렀는데 왜 확인할 것이 남을까요?

문의 접수 앱을 예로 들어 보겠습니다. 사용자가 제출한 뒤 화면에 완료 문구가 보이더라도, 연결된 업무 시스템에 기록이 남았는지는 다른 질문입니다. 특히 중간 서비스가 요청을 받아 두었다가 나중에 전달한다면 접수와 최종 처리는 같은 순간에 끝나지 않을 수 있습니다.

따라서 첫 앱부터 복잡한 관제 화면을 만들 필요는 없지만, 어떤 요청을 언제 받았고 처리가 어디까지 진행됐는지는 구분해 두시면 좋습니다. 접수됨·처리 대기·처리 완료·확인 필요 같은 상태는 설계 예시이며 getrequest가 제공하는 실제 상태 이름은 아닙니다. 작은 기록 하나가 있어야 실패했을 때 사용자의 설명에만 의존하지 않을 수 있습니다.

재전송 버튼은 언제 눌러야 할까요?

재전송은 놓친 일을 복구할 수 있지만, 이미 처리된 일을 다시 실행할 가능성도 있습니다. 가령 같은 문의가 중복 등록되거나 알림이 두 번 보내질 수 있습니다. 이는 이 제품에서 확인한 결함이 아니라, 요청을 다시 보내는 앱이라면 점검할 조건입니다.

첫 프롬프트에 ‘같은 요청을 다시 보내도 업무 기록은 중복되지 않아야 한다’는 조건을 넣어 보세요. 이후 무해한 샘플 요청을 반복해 보내고, 화면의 성공 표시와 최종 저장 건수가 맞는지 확인하면 됩니다. 재전송 기능이 있다는 사실만으로 중복 방지까지 해결됐다고 판단해서는 안 됩니다.

기록을 많이 남기면 무조건 좋을까요?

사이트는 요청의 헤더와 본문을 보관하고, 공유 링크로 요청·응답 내용을 볼 수 있다고 설명합니다.[2] 이런 자료에는 연락처나 인증 정보가 섞일 수 있습니다. 실제 고객 정보를 연결하기 전에 저장 항목, 가림 처리, 보관 기간과 공유 범위를 확인해야 합니다.

제작자는 아직 첫 버전이라며 현실에서 어디가 깨지는지 알려 줄 개발자를 찾는다고 덧붙였습니다.[1] 완성도를 과장하기보다 검증할 사용자를 찾는 태도가 눈에 띕니다. 여러분의 MVP도 ‘잘 됩니다’라는 소개보다 어떤 실패 상황을 함께 확인하고 싶은지 말할 수 있을 때 다음 개선이 구체적이 됩니다.

FAQ: 무료로 재전송까지 사용할 수 있나요?

공개 요금표는 무료 플랜을 제공하지만 Request replay와 공유 디버그 링크는 Pro 항목으로 표시합니다.[2] 무료 시작 문구만 보고 모든 기능이 포함된다고 생각하지 말고 현재 요금표를 확인하세요.

FAQ: 첫 앱에 반드시 이 서비스를 붙여야 하나요?

아닙니다. 이 글은 도입 권유나 사용 후기가 아닙니다. 먼저 앱 자체에 필요한 최소 처리 기록을 남기고, 장애 재현과 복구가 어려워졌을 때 외부 서비스를 비교하셔도 됩니다.

출처
[1] https://news.ycombinator.com/item?id=50014590
[2] https://www.getrequest.io/