← 블로그 목록

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 프로젝트를 수정하다 망가졌을 때는 바로 전체 되돌리기부터 하지 마세요.

  1. 깨진 범위를 먼저 적는다
  2. 정상 상태였던 화면을 찾는다
  3. Lovable 기록, GitHub 커밋, 배포 기록을 나눠 본다
  4. 데이터 변경이 있었는지 확인한다
  5. 필요한 부분만 되돌릴지, 전체를 되돌릴지 결정한다

AI가 만든 프로젝트는 처음 만들 때 빠르지만, 되돌릴 때는 사람이 기준을 잡아줘야 합니다. 되돌리기는 버튼 하나가 아니라 운영 판단입니다.

관련 글: Lovable로 만든 사이트 수정이 안 될 때, AI가 만든 코드가 점점 복잡해질 때 멈춰야 하는 신호, AI로 만든 서비스를 개발자에게 맡기기 전 준비할 것

LastFix 무료 진단

AI·바이브코딩으로 해결되지 않는 개발 이슈가 있다면 원인부터 확인하세요

배포 오류, UI 깨짐, 결제·예약 연동, 작은 기능 수정을 단건으로 진단하고 필요한 범위만 정리합니다.

무료 진단 신청