Lovable 프로젝트 되돌리기: 수정하다 망가졌을 때 먼저 볼 것
Lovable로 만든 프로젝트를 수정하다가 화면이나 기능이 망가졌을 때, 되돌리기 전에 확인해야 할 버전 기록, GitHub, 배포 상태, 데이터 변경 기준을 정리했습니다.
Lovable로 사이트를 만들다 보면 어느 순간 이런 생각이 듭니다.
"아까 상태가 더 나았는데."
AI에게 계속 수정 요청을 하다 보면 버튼 하나를 고치려다 전체 간격이 바뀌고, 모바일만 손보려다 데스크톱이 깨지고, 잘 되던 로그인이나 데이터 저장까지 이상해질 때가 있습니다. 이때 무작정 "이전으로 되돌려줘"라고 말하면 더 꼬일 수 있습니다.
되돌리기는 단순히 시간을 되감는 일이 아닙니다. 어떤 상태로 돌아가야 하는지, 코드만 돌아가면 되는지, 데이터나 배포까지 영향을 받는지 먼저 봐야 합니다.
먼저 지금 망가진 범위를 적는다
되돌리기 전에 가장 먼저 할 일은 증상을 좁히는 것입니다.
- 특정 화면만 깨졌는가
- 모바일에서만 문제인가
- 로그인, 결제, 저장 같은 기능도 깨졌는가
- 배포된 사이트가 깨졌는가, Lovable 미리보기만 깨졌는가
- 마지막으로 정상 동작하던 시점이 언제인가
이 질문에 답하지 않고 전체를 되돌리면, 실제로는 멀쩡한 수정까지 같이 사라질 수 있습니다. 예를 들어 어제 UI는 망가졌지만 오늘 추가한 문의 폼 저장 기능은 정상일 수 있습니다. 전체 되돌리기를 하면 그 기능도 함께 사라집니다.
버전 기록과 GitHub는 다르게 봐야 한다
Lovable은 코드 소유와 GitHub 연동을 중요하게 설명합니다. 공식 문서에서도 프로젝트가 실제 코드베이스를 만들고 GitHub와 연결될 수 있다고 안내합니다. 다만 Lovable 안의 작업 기록과 GitHub 커밋은 같은 개념이 아닐 수 있습니다.
비개발자 입장에서는 이렇게 나눠보면 됩니다.
- Lovable 안의 이전 상태: 화면과 작업 흐름을 빠르게 되돌리는 데 유용
- GitHub 커밋: 어떤 파일이 어떻게 바뀌었는지 추적하는 데 유용
- 배포 기록: 실제 사용자에게 어떤 버전이 공개됐는지 확인하는 데 유용
가능하면 큰 수정 전에는 GitHub에 커밋이 남아 있는지 확인하세요. 개발자가 도와줄 때도 "언제부터 망가졌는지"를 커밋 단위로 볼 수 있으면 훨씬 빠릅니다.
되돌리기 전에 데이터 변경 여부를 확인한다
화면만 만든 프로젝트라면 되돌리기가 비교적 단순합니다. 하지만 Supabase, Firebase, 결제, 회원가입이 들어간 프로젝트라면 조심해야 합니다.
코드를 이전으로 돌려도 데이터베이스는 그대로일 수 있습니다. 반대로 AI가 테이블 구조나 저장 형식을 바꿨다면, 이전 코드가 현재 데이터와 맞지 않을 수도 있습니다.
아래에 해당하면 전체 되돌리기보다 부분 수정이 안전합니다.
- 테이블이나 컬럼을 새로 만들었다
- 로그인 방식이나 권한 정책을 바꿨다
- 결제 성공 URL이나 주문 저장 흐름을 수정했다
- 관리자에서 실제 데이터를 입력했다
- 이미 고객이 사용한 뒤 문제가 생겼다
운영 중인 서비스라면 "되돌리면 끝"이 아니라 "되돌린 뒤 현재 데이터와 맞는지"까지 확인해야 합니다.
AI에게 이렇게 요청하면 덜 위험하다
Lovable이나 다른 AI 도구에 되돌리기를 요청할 때는 구체적으로 말하는 편이 좋습니다.
나쁜 요청은 이렇습니다.
- 이전으로 되돌려줘
- 망가진 거 고쳐줘
- 아까처럼 해줘
조금 더 나은 요청은 이렇습니다.
- 모바일 카드 레이아웃만 마지막 정상 상태로 되돌리고, 로그인과 데이터 저장 코드는 유지해줘.
- 어제 오후 수정 이후 변경된 UI 관련 파일만 비교해줘. 바로 되돌리지 말고 어떤 파일이 바뀌었는지 먼저 알려줘.
- 현재 배포된 버전과 Lovable 미리보기의 차이를 정리해줘.
- 전체 되돌리기 전에 사라질 수 있는 기능 목록을 먼저 알려줘.
핵심은 "바로 되돌려"가 아니라 "무엇이 바뀌었는지 먼저 보여줘"입니다.
개발자에게 맡길 때 준비하면 좋은 것
Lovable 프로젝트가 망가져서 외부 개발자에게 맡긴다면 아래 자료가 있으면 좋습니다.
- 정상 상태였던 화면 캡처
- 현재 깨진 화면 캡처나 영상
- 마지막으로 요청한 프롬프트
- GitHub 저장소 주소
- 배포된 사이트 주소
- 문제가 시작된 대략적인 시간
- 데이터베이스나 결제 같은 외부 서비스 변경 여부
저장소가 있다면 개발자는 Git diff로 변경 범위를 볼 수 있습니다. 이게 있으면 "감으로 되돌리기"보다 훨씬 안전합니다.
정리
Lovable 프로젝트를 수정하다 망가졌을 때는 바로 전체 되돌리기부터 하지 마세요.
- 깨진 범위를 먼저 적는다
- 정상 상태였던 화면을 찾는다
- Lovable 기록, GitHub 커밋, 배포 기록을 나눠 본다
- 데이터 변경이 있었는지 확인한다
- 필요한 부분만 되돌릴지, 전체를 되돌릴지 결정한다
AI가 만든 프로젝트는 처음 만들 때 빠르지만, 되돌릴 때는 사람이 기준을 잡아줘야 합니다. 되돌리기는 버튼 하나가 아니라 운영 판단입니다.
관련 글: Lovable로 만든 사이트 수정이 안 될 때, AI가 만든 코드가 점점 복잡해질 때 멈춰야 하는 신호, AI로 만든 서비스를 개발자에게 맡기기 전 준비할 것
LastFix 무료 진단
AI·바이브코딩으로 해결되지 않는 개발 이슈가 있다면 원인부터 확인하세요
배포 오류, UI 깨짐, 결제·예약 연동, 작은 기능 수정을 단건으로 진단하고 필요한 범위만 정리합니다.