Lovable·Bolt가 버그 수정 무한 루프에 빠졌다면? MVP를 끝까지 완성하는 방법

빌더에게 로그인을 고쳐 달라고 요청합니다. 로그인은 되는데 이번엔 대시보드가 비어 있습니다. 다른 프롬프트로 대시보드를 복구하자 다시 로그인이 깨집니다. Lovable이나 Bolt가 같은 버그만 계속 고치고 있다면, 다음에 할 일은 실패 하나에 대한 증거를 더 탄탄하게 모으는 것입니다. 변경이 많아진다고 저절로 진전이 생기지는 않습니다.

AI로 만든 앱은 왜 수정 루프에 빠질까?

수정 루프는 변경이 눈에 보이는 증상만 다루고, 근본 원인을 밝혀내고 검증하지 않을 때 생깁니다. 서로 다른 여러 결함이 같은 화면을 만들어 낼 수 있기 때문에, 포괄적인 요청은 빌더에게 고칠 만해 보이는 후보를 너무 많이 줍니다.

대시보드가 비어 있다는 건 요청 실패, 권한 정책, 잘못된 데이터베이스, 혹은 실제로 데이터가 없는 것일 수 있습니다. 컴포넌트를 바꾸면 메시지는 사라질지 몰라도 실패한 요청은 그대로 남을 수 있습니다. 목표는 어느 경계에서 실패했는지, 즉 브라우저, 서버, 인증 제공자, 데이터베이스, 외부 연동 중 어디인지를 찾아내는 것입니다.

실용적인 중단 규칙을 정하세요. 범위를 좁힌 수정을 시도한 뒤에도 같은 증상이 다시 나타나면, 같은 프롬프트를 반복하지 말고 다른 종류의 증거를 모으세요. 이는 문서화된 플랫폼 제한이 아니라 작업 습관입니다. 무엇이 실패하는지 아무도 설명하지 못하는 상태에서 소규모 프로젝트에 관련 없는 변경이 쌓이는 것을 막아 줍니다.

빌더 미리보기가 깨진 걸까, 앱이 깨진 걸까?

코드를 다시 작성하기 전에 빌더 환경과 애플리케이션을 따로 점검하세요. 플랫폼 장애나 미리보기 연결 문제는 제품 아키텍처를 갈아엎어야 한다는 증거가 아닙니다.

Bolt의 현재 미리보기 문제 해결 가이드는 서비스 상태 확인, 브라우저 콘솔 오류 수집, 프로덕션 빌드 시도, 누락된 환경 변수 검토를 권장합니다. 또한 첫 시도가 실패한 뒤 같은 미리보기 수정 프롬프트를 반복해서 보내는 것은 도움이 되지 않을 가능성이 높다고 설명합니다.

이 표는 다음 조사 대상을 고르는 데 쓰고, 진단을 확정하는 데 쓰지 마세요. 네트워크 요청 실패도 애플리케이션 코드에서 비롯될 수 있고, 흰 화면에는 여러 원인이 있을 수 있습니다. 이후의 실패에 묻히기 전에 처음 나타난 의미 있는 오류를 기록해 두세요.

다음 수정을 시도하기 전에 무엇을 저장해야 할까?

가장 최근의 쓸모 있는 코드 상태를 보존하고, 수정이 영향을 줄 수 있는 데이터를 파악하세요. 코드 이력과 데이터베이스 백업은 서로 다른 복구 문제를 해결합니다.

Lovable의 버전 이력 문서는 코드 버전을 미리보기, 북마크, 되돌리는 방법을 설명합니다. 그리고 코드를 되돌려도 데이터베이스 데이터는 롤백되지 않는다고 명시합니다. 버전을 복원하기 전에, 이후 작업에서 레코드, 권한, 또는 이전 코드가 전제하는 스키마가 바뀌었는지 확인하세요.

1. 핵심 사용자 여정이 마지막으로 정상 동작한 상태를 타임스탬프나 커밋 식별자와 함께 기록하세요.
2. 현재 실패를 기록하고, 커밋하지 않은 쓸모 있는 작업은 프로젝트가 지원하는 워크플로로 저장하세요.
3. 데이터나 스키마를 바꾸는 작업 전에는 적절한 데이터베이스 백업이나 안전한 테스트용 사본을 만드세요.
4. 실사용자가 있는 프로젝트와 환경을 적어 두어, 수정을 그들과 분리된 곳에서 테스트할 수 있게 하세요.

쓸모 있는 수정 프롬프트는 어떤 모습일까?

쓸모 있는 수정 프롬프트는 재현 가능한 실패 하나를 지목하고, 관련 증거를 제공하며, 제안할 변경의 범위를 제한합니다. 스스로 판단할 수 없는 구현을 승인하기 전에 먼저 원인 설명을 요청하세요.

Investigate one issue: a signed-in customer cannot save a booking.
Steps: create a fresh customer account, open /bookings/new, choose a date, and select Save.
Expected: one booking is saved and appears after refresh.
Actual: the request returns 403 and no booking is saved.
Evidence: [sanitized error, request path, and timestamp].
First explain the likely cause and the files or policies involved.
Do not change roles, remove access checks, redesign screens, or rewrite unrelated features.
Propose the smallest fix and how to test it with two ordinary accounts.

이 예시는 가상의 사례입니다. 세부 내용은 실제로 관찰한 내용으로 바꾸세요. 403 응답은 접근 실패에 대한 단서일 뿐, 권한 검사를 제거해도 된다는 허락이 아닙니다. 비밀번호, 토큰, 연결 문자열, 고객 레코드는 프롬프트와 스크린샷에 넣지 마세요.

Lovable 프로젝트라면 백엔드 로그 가이드에서 프로젝트에서 사용할 수 있는 서비스 전반의 요청과 오류를 확인하는 방법을 설명합니다. 오류를 해당 동작이 일어난 시각과 환경에 맞춰 대조하세요. 필터링하지 않은 방대한 로그 덤프보다, 민감 정보를 제거한 관련 항목 하나가 더 유용합니다.

수정이 실제로 효과가 있었는지 어떻게 알 수 있을까?

원래의 재현 단계가 기대한 결과를 내고, 중요한 인접 흐름도 여전히 올바르게 동작하면 수정이 성공한 것입니다. 일시적인 성공 메시지만 보지 말고, 새로고침한 뒤 저장된 상태를 테스트하세요.

1. 새 계정과 같은 입력으로 원래의 실패를 다시 재현해 보세요.
2. 앱을 새로고침하거나 다시 열어 결과가 올바르게 저장되었는지 확인하세요.
3. 두 번째 일반 계정으로 반복해 의도한 소유권 경계가 지켜지는지 검증하세요.
4. 안전한 테스트 환경에서 잘못된 입력이나 중단된 요청 같은 실패 사례를 하나 시도해 보세요.
5. 변경된 코드를 공유하는 인접 흐름을 확인한 다음, 프로젝트의 관련 검사와 프로덕션 빌드를 실행하세요.

언제 개발자를 투입해야 할까?

핵심 경로의 변경을 자신 있게 설명하거나 검증할 수 없을 때, 또는 범위를 좁혀 조사해도 원인을 격리하지 못할 때 개발자를 투입하세요. 결제 접근, 계정 간 데이터 노출, 반복적인 데이터베이스 변경은 특히 주의가 필요합니다.

범위가 정해진 검토로 문제가 설정 문제인지, 작은 구현 결함인지, 더 큰 설계 문제인지 판단할 수 있습니다. 진단 결과, 변경할 파일이나 서비스, 인수 테스트, 롤백 방안을 요청하세요. 재구축에 동의하기 전에 이런 검토부터 의뢰할 수 있습니다.

좋은 인계 자료에는 앱 URL, 지원되는 방식의 프로젝트 또는 저장소 접근 권한, 재현 단계, 짧은 화면 녹화, 민감 정보를 제거한 오류, 마지막 정상 버전이 포함됩니다. 다음 고객 마일스톤과 건드리면 안 되는 기능도 함께 적으세요. 자격 증명은 적절한 비밀 공유 방식이나 계정 접근 절차를 통해서만 공유하세요.

다음 릴리스에는 무엇을 담아야 할까?

다음 릴리스에서는 깨진 사용자 여정 중 작고 측정 가능한 범위를 해결해야 합니다. 그 여정들이 배포된 앱에서 테스트를 통과할 때까지 기능 요청은 따로 관리하세요.

수정 후에는 12가지 MVP 출시 점검 계획으로 인접한 빈틈을 찾아보세요. 미리보기에서는 되는데 Replit에 배포하면 깨진다면 Replit 배포 체크리스트를 참고하세요. 직접적인 도움이 필요하다면 Lovable 또는 Bolt 페이지에서 시작점을 고르고 상담을 예약하세요. 실패하는 흐름을 가져오시면, 첫 대화에서 쓸모 있는 다음 단계를 함께 정할 수 있습니다.