Claude와 Next.js로 주말 만에 SaaS를 만든 솔직한 후기

AI 요약

글쓴이는 Claude와 Next.js를 활용해 주말 동안 SaaS의 첫 작동 버전을 만들었습니다. 다만 코드 입력이 빨라졌다고 사업까지 완성되는 것은 아니라고 강조합니다. 주말에 만든 결과물은 핵심 기능의 흐름을 확인하는 프로토타입이며, 오류와 빈 상태 처리, 결제 예외, 악용 방지, 온보딩, 다른 사용자의 요구, 운영 안정성은 여전히 남아 있습니다.

빨라진 것은 초기 구현입니다

금요일에는 create-next-app과 App Router, Tailwind, PostgreSQL, 인증, 핵심 데이터베이스 스키마를 구성했습니다. Claude가 대부분의 기초 코드를 작성했고 글쓴이가 방향을 잡았습니다. 반복적인 설정과 보일러플레이트 작업은 몇 시간으로 줄었습니다.

토요일에는 제품의 핵심 기능을 구현했습니다. 글쓴이는 기능 단위로 요청하고 생성된 코드를 읽고 검토했습니다. 코드는 대체로 잘 짜였지만, 깔끔하고 그럴듯한 코드가 올바른 코드라는 보장은 없었습니다. 글쓴이가 특히 위험한 점으로 꼽은 것은 코드 생성 모델이 자신이 만든 결과물도 자신감 있는 어조로 검토한다는 점입니다.

결제 웹훅에서 드러난 순서 오류

일요일에는 결제 제공업체의 웹훅을 받아 계정 정보를 갱신하는 핸들러를 만들었습니다. 생성된 코드는 타입이 맞고 관용적인 구조를 따랐으며 오류 처리와 재시도 의미를 설명하는 주석도 있었습니다. 컴파일과 모델이 작성한 테스트도 통과했습니다. 하지만 핸들러는 데이터베이스에 기록하기 전에 결제 제공업체에 200 응답을 보냈습니다.

제공업체는 빠른 200 응답을 받으면 재시도하지 않습니다. 응답은 성공했지만 데이터베이스 기록이 실패하거나 지연되면 결제 사실이 저장되지 않을 수 있습니다. 고객은 돈을 냈는데 구매한 서비스에 접근하지 못하고, 로그에도 결제 기록이 남지 않는 상황입니다. 글쓴이는 과거에도 비슷한 버그를 배포해 고객의 항의를 받은 경험이 있어 문제를 알아챘다고 합니다. 수정은 두 줄의 순서를 바꾸는 일이었지만, 코드를 꼼꼼히 읽는 것만으로 다음 종류의 버그까지 잡는다는 보장은 없다고 짚습니다.

생성과 검토, 승인을 분리합니다

글쓴이는 코드를 작성한 모델이 자기 결과물을 승인하지 않도록 작업 흐름을 바꿨습니다. 첫 단계에서는 생성 모델이 빠르게 코드를 만듭니다. 다음 단계에서는 별도의 검토 모델이 코드를 칭찬하거나 전반적인 품질을 묻는 대신, 손실을 일으킬 입력과 실패 상황을 찾습니다. 마지막으로 사람이 병합을 결정하고 결과에 책임을 집니다. 글쓴이는 생성 모델을 작성자, 검토 모델을 회의론자, 사람을 승인자로 설명합니다.

이 분업은 글쓴이가 개발 중인 에이전트 플랫폼 xenition의 구조로 이어졌습니다. 글쓴이는 코드 생성 속도보다 생성된 코드의 위험을 찾아내는 검토 과정이 부족하다고 봅니다. 주말 프로젝트는 작동하는 시제품을 만드는 데는 유용했지만, 실제 상품을 운영하는 데 필요한 예외 처리와 사용성, 운영 준비까지 끝내지는 못했습니다.

dev.to 반응

• @sgaggjhkjh — 웹훅에서 저장 전에 200 응답을 보내고, 두 줄 순서를 바꿔 고친 사례는 최근 읽은 버그 이야기 중 가장 섬뜩하면서도 깔끔합니다. 작성자와 회의론자, 사람을 나누는 방식은 제 코드 리뷰에도 가져가겠습니다.
  • @infoinlet1 — 가져가셔도 좋습니다. 별도 단계로 두니 회의론자 검토가 거의 지연을 만들지 않는다는 점이 가장 놀라웠습니다. 어려웠던 부분은 방금 감탄한 모델을 결과물 승인까지 맡기지 않겠다고 인정하는 심리적인 문제였습니다. "재시도되면 어떻게 되나요?"라는 질문 하나가 생각보다 큰 효과를 냅니다. 실제 리뷰에서 어떻게 작동하는지 듣고 싶습니다.
  • @sgaggjhkjh — 재시도 질문을 오늘부터 리뷰 체크리스트에 넣겠습니다. 회의론자 검토가 놓친 것을 처음 잡아내면 알려드리겠습니다.
• @contentclips_st — 솔직한 분석이라는 구성이 좋습니다. 촉박한 일정에 고객 작업물을 납품해 본 경험으로는 주말 개발의 병목이 코드보다 환경 설정, 배포 구성, 문서화 같은 전환 작업인 경우가 많습니다. Claude는 코드 생성은 잘하지만, 실제로 배포할 수 있게 만드는 CI와 쓸 만한 랜딩 페이지, 검색 가능한 문서에 나머지 시간의 20%를 배정해 왔습니다. 구매자는 로컬에서 실행되는 코드보다 직접 눌러볼 수 있는 결과물로 출시 여부를 판단합니다.
• @mudassirworks — 저장 전에 응답하는 순서 오류는 누구나 한 번쯤 당하는 문제입니다. 고친 직후에는 느린 저장 중 제공업체가 재시도해 결제 이벤트가 두 번 처리되는 반대쪽 문제를 겪었습니다. 이벤트 ID에 고유 제약 조건을 걸자 핸들러 로직보다 그 제약이 더 많은 일을 했습니다. 코드 차이만 보면 잘못이 드러나지 않고 실패 추적을 봐야 알 수 있는 종류라 모델이 놓칠 수 있다는 말에도 동의합니다. 회의론자 검토에 실패 시나리오를 입력했나요, 아니면 코드 차이만 넣었나요?
  • @parsaaftabi — 고유 제약 조건이 실제 핸들러 역할을 한다는 점이 특히 와닿습니다. 저장이 재시도를 일으킬 만큼 느려지면 그 삽입 작업 하나가 전체 흐름을 막는 관문이 됩니다.
• @ascendra_ventures_92c21f2 — 저장 전에 응답하는 핸들러는 좋은 예입니다. 컴파일되고, 사려 깊은 주석이 있고, 같은 모델이 작성한 테스트도 통과하지만, 하룻밤의 실패로 유료 고객을 잃을 수 있습니다. "코드를 쓰는 것이 그 코드에 승인 도장을 찍게 해서는 안 된다"는 문장을 기억하고 싶습니다. 고객 작업에도 작성자와 회의론자, 사람을 나누는 방식을 적용할 수 있습니다. 다만 회의론자가 검증할 기준을 먼저 정해야 합니다. 예를 들어 결제 단계의 완료 조건을 빌드 전에 정하면 실패한 저장에서 제공업체가 재시도하는지, 모든 결제 고객에게 기록이 남는지를 기준으로 검토할 수 있습니다. 주말 작업으로 빈 상태와 결제 예외, 두 번째 사용자를 위한 처리가 생기지 않는다는 대목은 창업자들이 일정부터 묻기 전에 읽어야 합니다. 작성자에게 그저 동의하지 않도록 회의론자에게 어떤 프롬프트를 주나요?
• @julianneagu — 결제가 누락되는 문제만큼 중복 결제도 중요합니다. 이벤트 ID에 데이터베이스 수준의 고유 제약 조건을 두겠습니다. 핸들러가 모든 재시도를 제대로 처리한다고 믿기보다 데이터베이스가 보장하게 하는 편이 낫습니다.

원문: dev.to / 번역·요약: Trawling