← 블로그 목록

AI로 만든 서비스를 개발자에게 맡기기 전 준비할 것

Cursor, Lovable, Bolt로 만든 서비스를 개발자에게 넘기기 전에 준비하면 좋은 저장소, 배포 계정, 에러 기록, 원하는 완료 상태를 정리했습니다.

AI로 서비스를 만들다가 어느 순간 이런 생각이 듭니다.

"이제 누가 한 번 봐줘야 할 것 같은데, 뭘 보내야 하지?"

개발자가 아닌 상태에서 Cursor, Lovable, Bolt 같은 도구로 만든 프로젝트를 누군가에게 넘기는 일은 생각보다 막막합니다. 코드는 어디 있는지, 배포는 어디서 되는지, 에러는 어떤 걸 보여줘야 하는지부터 헷갈립니다.

다행히 처음부터 완벽하게 정리할 필요는 없습니다. 개발자가 보고 싶은 정보는 대단한 기획서가 아니라, 지금 서비스가 어떤 상태이고 어디서 막히는지 알 수 있는 단서입니다. 아래 항목만 준비해도 진단 속도가 꽤 달라집니다.

1. 코드가 어디에 있는지 먼저 확인하기

가장 먼저 볼 것은 코드 저장소입니다. GitHub 저장소가 있으면 좋고, 없다면 현재 프로젝트를 내려받을 수 있는 방법이라도 있어야 합니다.

AI 빌더 안에서만 프로젝트를 수정해온 경우에는 "공유 링크만 있으면 되겠지"라고 생각하기 쉽습니다. 하지만 개발자가 실제로 수정하려면 파일 전체와 변경 이력이 필요합니다. 어떤 파일이 언제 바뀌었는지 알 수 있어야 위험한 수정을 피할 수 있습니다.

확인하면 좋은 것:

  • GitHub 저장소가 있는가
  • 최신 코드가 올라가 있는가
  • 배포 서비스가 이 저장소와 연결되어 있는가
  • AI가 최근에 크게 수정한 시점이 남아 있는가

저장소가 없다고 해서 수정이 불가능한 것은 아닙니다. 다만 처음 보는 프로젝트라면 코드를 확보하고 구조를 파악하는 시간이 더 필요합니다.

2. 배포 계정과 도메인 위치 적어두기

운영 중인 서비스는 코드만 봐서는 해결되지 않는 문제가 많습니다. 특히 "로컬에서는 되는데 배포하면 안 된다"는 문제는 배포 계정에서 로그와 환경 변수를 봐야 합니다.

많이 쓰는 조합은 Vercel, Netlify, Cloudflare, Replit, Supabase, 가비아, 카페24 같은 서비스입니다. 정확한 설정을 몰라도 괜찮습니다. 어디에 로그인하면 배포 상태를 볼 수 있는지만 알아도 출발점이 됩니다.

개발자에게 바로 비밀번호를 넘길 필요는 없습니다. 먼저 어떤 계정에 무엇이 있는지 목록으로만 정리해도 됩니다. 실제 작업이 필요해지면 초대 권한을 주거나 화면 공유로 확인하는 방식도 가능합니다.

특히 환경 변수는 중요합니다. .env 파일에 있던 값이 배포 서비스에 빠져 있으면, 코드는 멀쩡한데 운영에서만 깨지는 일이 흔합니다.

3. 외부 서비스 목록 만들기

AI로 만든 서비스는 겉보기보다 많은 외부 서비스에 기대고 있습니다. 로그인은 Clerk나 Supabase Auth, 데이터베이스는 Supabase나 Firebase, 결제는 토스페이먼츠나 Stripe, 이메일은 Resend 같은 식입니다.

문제가 생겼을 때 개발자는 코드와 함께 외부 서비스 설정을 봅니다. 예를 들어 결제 완료 후 화면이 비어 있다면 결제 코드만 볼 일이 아닙니다. 결제사의 성공 콜백 주소, 주문 저장 로직, 배포 환경 변수, 실제 결제 로그까지 이어서 확인해야 합니다.

정리할 때는 복잡하게 쓰지 않아도 됩니다.

  • 데이터 저장: Supabase
  • 로그인: Clerk
  • 결제: 토스페이먼츠
  • 배포: Vercel
  • 도메인: Cloudflare

이 정도만 있어도 충분합니다. 어떤 서비스를 쓰는지 모르면, 개발자는 코드 안에서 하나씩 추적해야 합니다.

4. 증상을 한 문장으로 쓰기

개발자가 가장 빨리 이해하는 설명은 긴 배경 설명보다 정확한 한 문장입니다.

좋은 예시는 이런 식입니다.

  • 결제는 성공하지만 주문 완료 페이지에 주문 정보가 뜨지 않습니다.
  • 관리자에서 상품을 등록하면 저장됐다고 나오는데 새로고침하면 사라집니다.
  • Lovable에서는 잘 보이는데 실제 도메인에서는 모바일 화면이 깨집니다.
  • Cursor가 수정한 뒤 로그인은 되지만 대시보드로 이동하지 않습니다.

여기에 "언제부터", "어떤 버튼을 눌렀을 때", "로컬과 배포 중 어디서"를 붙이면 더 좋습니다. 개발자는 이 정보를 바탕으로 재현부터 합니다. 재현이 되면 문제의 절반은 이미 좁혀진 셈입니다.

5. 원하는 완료 상태를 정하기

의외로 많이 빠지는 것이 "어디까지 되면 끝인지"입니다.

"결제 오류를 고쳐주세요"보다 "테스트 결제 후 주문이 저장되고, 사용자가 주문 완료 페이지에서 결제 금액과 상품명을 확인하면 됩니다"가 훨씬 좋습니다.

완료 상태가 분명하면 작업 범위도 작아집니다. 개발자는 결제 페이지 전체를 새로 만들지 않고, 결제 후 데이터 저장과 화면 표시 흐름만 확인하면 됩니다. 반대로 완료 상태가 모호하면 견적도 넓어지고, 서로 생각한 결과물이 달라질 수 있습니다.

AI로 만든 서비스일수록 범위를 작게 자르는 것이 중요합니다. 지금 필요한 것은 전체 리뉴얼이 아니라 고객이 막히는 한 흐름을 다시 움직이게 만드는 일일 때가 많습니다.

보내면 도움이 되는 자료

처음 문의할 때 아래 자료 중 가능한 것만 보내면 됩니다.

  • 서비스 주소
  • GitHub 저장소 주소
  • 배포 서비스 이름
  • 사용한 AI 도구: Cursor, Lovable, Bolt, Replit 등
  • 에러 메시지나 화면 캡처
  • 문제가 발생하는 순서
  • 외부 서비스 목록: Supabase, Firebase, 결제, 이메일 등
  • 원하는 완료 상태

비밀번호나 API 키를 처음부터 보내지 않아도 됩니다. 민감한 값은 실제 작업 범위가 정해진 뒤 안전한 방식으로 공유하는 편이 좋습니다.

정리

AI로 만든 서비스를 개발자에게 맡길 때 필요한 것은 완벽한 문서가 아닙니다. 개발자가 현재 상태를 재현하고, 원인을 좁히고, 수정 범위를 정할 수 있는 단서입니다.

핵심은 네 가지입니다.

  1. 코드가 어디 있는지
  2. 배포와 외부 서비스가 어디에 연결되어 있는지
  3. 어떤 증상이 어떤 순서로 발생하는지
  4. 어디까지 되면 해결인지

이 정도만 정리해도 "이거 고칠 수 있나요?"라는 막막한 문의가 "이 흐름을 고쳐주세요"라는 구체적인 요청으로 바뀝니다. LastFix도 보통 이 정보들을 바탕으로 먼저 무료 진단 범위를 잡습니다.

관련 글: AI로 만든 서비스 유지보수 맡기기 전 확인할 것, 개발자 없이 서비스 운영하는 현실적인 방법

AI·바이브코딩으로 해결되지 않는 개발 이슈, 먼저 원인부터 확인하세요

Cursor 에러, Vercel·Next.js 배포 실패, 결제·예약 연동 오류, 소규모 기능 개발을 단건 중심으로 진단합니다. 월 구독 파트너는 정식 상품을 준비 중입니다.