오류가 났을 때 당황하지 않는 디버깅 습관

2026-05-15Views 80약 11분생성형 AI 활용

Summary

오류는 실패가 아니라, 앱이 보내는 신호다

러버블로 웹페이지를 만들다 보면 어느 순간 이런 장면을 만나게 됩니다.

버튼을 눌렀는데 아무 일도 일어나지 않습니다. 방금 전까지 멀쩡하던 화면이 갑자기 하얗게 비어 있습니다. 문의 폼을 만들었더니 "Failed to fetch" 같은 낯선 문장이 뜹니다. 상담 신청 페이지를 조금 고쳐 달라고 했을 뿐인데, 헤더 색상도 바뀌고 카드 간격도 이상해졌습니다.

이때 초보자가 가장 많이 하는 행동은 바로 이것입니다.

"고쳐줘."

그리고 다시 한 번.

"아직 안 돼. 다시 고쳐줘."

문제는 이 짧은 말이 러버블에게 꽤 넓은 권한을 준다는 데 있습니다. 러버블은 선의로 고치려고 하지만, 원인을 정확히 모르는 상태에서 여러 파일을 건드릴 수 있습니다. 그러면 작은 오류 하나가 더 큰 꼬임으로 번지기도 합니다. AI가 만든 앱도 틀릴 수 있습니다. 아니, 정확히 말하면 AI가 만든 앱이기 때문에 더더욱 "차분한 복구 절차"가 필요합니다.

다행히 디버깅은 천재 개발자만 하는 일이 아닙니다. 여기서 말하는 디버깅은 코드를 줄줄 읽는 기술이 아니라, 문제를 좁히고, 증거를 모으고, 되돌아갈 지점을 확보하는 습관입니다. 러버블 공식 문서도 문제가 생겼을 때 Plan mode로 단계별 도움을 받거나, UI나 기능 문제가 생기면 안정적인 상태로 되돌리는 방식을 권합니다.¹

이 장의 목표는 단순합니다. 오류가 났을 때 "망했다"가 아니라 "좋아, 순서대로 보자"라고 말할 수 있게 만드는 것입니다.

오류가 났을 때 당황하지 않는 디버깅 습관

먼저 손을 멈추는 사람이 크레딧을 아낀다

오류가 보이면 본능적으로 바로 수정하고 싶어집니다. 특히 무료 사용자라면 마음이 더 급해집니다. 크레딧은 적고, 만든 페이지는 아직 완성되지 않았고, 빨리 결과물을 보고 싶기 때문입니다.

하지만 크레딧을 아끼는 디버깅의 첫 번째 원칙은 "수정 전에 멈추기"입니다.

앱이 깨졌을 때 곧바로 러버블에게 "전체를 고쳐줘"라고 요청하면, 러버블은 넓은 범위를 다시 해석합니다. 그 과정에서 원래 잘 작동하던 부분까지 손댈 수 있습니다. 반대로, 먼저 증상을 정리하고 원인을 추정한 다음 필요한 부분만 고치면 요청 횟수도 줄고, 변경 범위도 줄어듭니다.

초보자에게 필요한 첫 행동은 코드가 아니라 기록입니다. 아래 네 가지를 메모장에 적어 두세요.

어떤 페이지에서 문제가 생겼는가
어떤 행동을 했을 때 문제가 나타나는가
기대한 결과와 실제 결과가 어떻게 다른가
오류 메시지나 화면 캡처가 있는가

예를 들어 "문의 폼이 안 돼요"라고 쓰면 너무 넓습니다. "포트폴리오 페이지의 문의 폼에서 이름, 이메일, 메시지를 입력하고 '문의 보내기' 버튼을 눌렀는데 성공 메시지가 나오지 않고 버튼만 계속 로딩 상태입니다"라고 쓰면 훨씬 좋습니다.

이 한 문장 차이가 디버깅 비용을 갈라놓습니다.

오류 메시지는 외계어가 아니라 단서다

초보자에게 오류 메시지는 무섭게 보입니다. TypeError, undefined, Failed to fetch, 404, 500, CORS 같은 단어가 튀어나오면 "이건 개발자 영역인데?"라는 생각이 듭니다.

하지만 오류 메시지는 혼내는 문장이 아니라 힌트입니다. 앱이 "여기쯤에서 일이 꼬였어요"라고 알려 주는 신호입니다. 우리가 할 일은 그 신호를 그대로 복사해 외부 AI에게 먼저 설명시키는 것입니다.

여기서 중요한 점이 있습니다. 러버블 안에서 바로 원인 분석을 오래 주고받으면 크레딧을 소모할 수 있습니다. 그러니 처음 해석은 ChatGPT나 Gemini 같은 외부 AI 도구에서 하는 편이 좋습니다. 외부 AI에게 오류 메시지를 붙여 넣고, 초보자도 이해할 수 있게 설명해 달라고 요청하세요. 코드 해결책을 바로 적용하라는 뜻이 아닙니다. 먼저 "이 오류가 대충 어떤 종류의 문제인지" 알아내는 단계입니다.

다음 프롬프트를 그대로 복사해 사용해도 좋습니다.

나는 코딩을 잘 모르는 초보자이고, Lovable에서 웹페이지를 만들고 있어.
아래 오류 메시지와 상황을 초보자도 이해할 수 있게 설명해줘.

1. 내가 만든 페이지: [예: 프리랜서 포트폴리오 문의 페이지]
2. 문제가 생긴 기능: [예: 문의 폼 제출]
3. 내가 한 행동: [예: 이름, 이메일, 메시지를 입력하고 버튼을 눌렀다]
4. 기대한 결과: [예: 성공 메시지가 나오고 폼이 초기화되어야 한다]
5. 실제 결과: [예: 버튼이 계속 로딩 중이고 아무 메시지도 안 나온다]
6. 오류 메시지:
[여기에 오류 메시지를 그대로 붙여넣기]

요청:
- 이 오류가 무슨 뜻인지 쉬운 말로 설명해줘.
- 가능한 원인을 3가지로 추정해줘.
- Lovable에 바로 수정 요청하기 전에 확인해야 할 것을 알려줘.
- Lovable에 붙여 넣을 '원인 분석용 프롬프트'를 만들어줘.
단, 아직 코드를 고치라는 프롬프트는 만들지 말고 분석용으로만 만들어줘.

이 프롬프트의 핵심은 "고쳐줘"가 아니라 "설명해줘"입니다. 외부 AI를 해결사로 쓰기 전에 통역사로 쓰는 것입니다. ChatGPT 같은 도구를 디버깅에 사용할 때도 문제 상황, 오류 메시지, 기대 결과와 실제 결과를 함께 제공해야 더 정확한 도움을 받을 수 있습니다.²

단, 외부 AI에 붙여 넣기 전에 개인정보와 비밀 키는 지워야 합니다. 이메일 주소, 전화번호, 고객 이름, API 키처럼 노출되면 곤란한 정보는 홍길동@example.com, 010-0000-0000, API_KEY_숨김처럼 바꿔 주세요.

러버블에게는 "분석만 하고 아직 수정하지 마"라고 말한다

외부 AI에게 오류의 대략적인 의미를 확인했다면, 이제 러버블에게 물어볼 차례입니다. 그런데 이때도 바로 "고쳐줘"라고 말하지 않습니다. 먼저 원인 분석만 시킵니다.

러버블에는 Plan mode가 있습니다. Plan mode는 기능을 기획하거나 문제를 이해하고, 실제 코드를 쓰거나 바꾸기 전에 변경 방향을 검토하는 데 유용한 모드입니다. 러버블의 디버깅 문서에서도 전체 코드베이스 점검이나 성능 분석처럼 큰 검토를 할 때 "아직 코드 변경은 하지 말고 분석만 하라"는 식의 읽기 전용 요청을 예시로 제시합니다.³

초보자에게 이 습관은 정말 중요합니다. 러버블에게 분석과 수정을 동시에 맡기면, 원인을 정확히 모르는 상태에서 앱이 다시 바뀔 수 있습니다. 분석만 먼저 받으면, 어떤 파일이나 기능이 문제인지 좁힌 뒤 필요한 부분만 고칠 수 있습니다.

러버블에 다음처럼 요청해 보세요.

아직 코드를 수정하지 마세요.
먼저 원인 분석만 해주세요.

문제 상황:
[예: 예약 상담 신청 페이지에서 폼 제출 버튼을 누르면 성공 메시지가 나오지 않습니다.]

기대 동작:
[예: 필수 항목이 모두 입력되면 성공 메시지를 보여주고 폼을 초기화해야 합니다.]

실제 동작:
[예: 버튼이 로딩 상태로 멈추거나 아무 반응이 없습니다.]

오류 메시지:
[있다면 그대로 붙여넣기]

요청:
1. 이 문제가 발생할 수 있는 원인 후보를 알려주세요.
2. 관련된 페이지, 컴포넌트, 함수만 확인해주세요.
3. 아직 수정하지 말고, 어떤 파일을 어떻게 확인했는지 설명해주세요.
4. 수정이 필요하다면 최소 변경 범위로 고치는 계획만 제안해주세요.
5. 관련 없는 디자인, 문구, 레이아웃은 절대 바꾸지 마세요.

여기서 "관련 없는 디자인, 문구, 레이아웃은 절대 바꾸지 마세요"라는 문장이 매우 중요합니다. AI는 친절하게 개선하려다가 원하지 않은 변경을 하기도 합니다. 우리는 지금 리디자인을 원하는 것이 아닙니다. 버그 하나를 잡고 싶은 것입니다.

Try-to-fix 버튼은 만능 버튼이 아니다

러버블에서 빌드 오류가 나면 Try-to-fix 같은 자동 수정 옵션을 볼 수 있습니다. 공식 FAQ에 따르면 Try-to-fix 옵션은 오류를 자동으로 해결하려고 시도하며, 이 버튼 사용 자체는 크레딧을 차감하지 않는다고 안내되어 있습니다.⁴ 무료 사용자에게는 꽤 반가운 기능입니다.

그렇다고 해서 이 버튼을 무한정 눌러도 된다는 뜻은 아닙니다. 단순한 빌드 오류, 예를 들어 괄호가 빠졌거나 가져와야 할 파일 이름이 맞지 않는 정도라면 Try-to-fix가 빠르게 해결해 줄 수 있습니다. 하지만 같은 문제가 반복되거나, 버튼을 누를 때마다 다른 문제가 생긴다면 멈춰야 합니다.

디버깅에서 가장 위험한 순간은 "이번 한 번만 더"입니다. 한 번 더 누르면 될 것 같아서 계속 시도하다가, 어느 순간 원래 어떤 상태가 정상인지 기억이 나지 않게 됩니다.

Try-to-fix는 이렇게 사용하세요. 첫 번째 시도는 괜찮습니다. 두 번째까지도 상황에 따라 괜찮습니다. 그러나 두 번 시도해도 같은 오류가 남아 있거나, 새로운 오류가 계속 생긴다면 즉시 중단합니다. 그다음에는 Plan mode로 원인을 분석하거나, 마지막 정상 버전으로 되돌리는 쪽이 더 안전합니다.

디버깅의 6단계 루프

오류를 만났을 때마다 아래 순서로 움직이면 됩니다. 이 순서는 초보자용 안전벨트입니다.

재현한다
기록한다
외부 AI에게 설명시킨다
러버블에게 분석만 시킨다
좁은 범위로 수정한다
다시 테스트한다

"재현한다"는 말은 같은 문제를 다시 일으킬 수 있는지 확인한다는 뜻입니다. 예를 들어 문의 폼 오류라면, 어떤 값을 입력했을 때 오류가 나는지 한 번 더 확인합니다. 이름을 비워도 나는지, 이메일 형식이 틀렸을 때만 나는지, 모든 값을 채워도 나는지 살펴봅니다.

"기록한다"는 말은 오류 메시지, 캡처, 마지막으로 입력한 프롬프트를 남긴다는 뜻입니다. 나중에 되돌릴 때 "어느 요청 이후에 망가졌는지"를 알아야 합니다.

"외부 AI에게 설명시킨다"는 단계에서는 아직 러버블 크레딧을 쓰지 않습니다. "이게 무슨 오류인지"를 먼저 이해합니다.

"러버블에게 분석만 시킨다"는 단계에서는 앱 내부 상태를 러버블이 확인하게 합니다. 이때도 아직 수정하지 말라고 말합니다.

"좁은 범위로 수정한다"는 단계에서야 비로소 수정 요청을 합니다. 마지막으로 "다시 테스트한다"에서 원래 문제가 해결됐는지, 다른 부분이 새로 망가지지 않았는지 확인합니다.

이 루프를 지키면 디버깅이 감정 싸움이 아니라 절차가 됩니다.

한 번에 전체 앱을 고치지 않는다

러버블에서 가장 피해야 할 프롬프트 중 하나는 이것입니다.

앱 전체를 확인해서 오류를 다 고쳐줘.

물론 듣기에는 좋아 보입니다. 하지만 이 요청은 너무 넓습니다. 특히 초보자의 작은 사업형 웹사이트에서는 대부분 "전체 앱"을 고칠 필요가 없습니다. 문제가 생긴 곳은 대개 특정 페이지, 특정 버튼, 특정 폼, 특정 데이터 연결입니다.

예를 들어 전자책 랜딩 페이지의 결제 버튼 링크가 잘못된 경우, 헤더와 푸터와 후기 섹션까지 볼 필요가 없습니다. 예약 상담 페이지의 날짜 선택이 안 되는 경우, 소개 문구와 가격표를 바꿀 필요가 없습니다.

수정 프롬프트는 이렇게 좁혀야 합니다.

아래 문제만 수정해주세요.

대상 페이지:
[예: /consultation 예약 상담 신청 페이지]

문제가 있는 기능:
[예: 상담 신청 폼 제출]

문제 증상:
[예: 필수 항목을 모두 입력하고 제출해도 성공 메시지가 나오지 않습니다.]

수정 범위:
- 상담 신청 폼 제출 로직과 관련된 파일만 확인하고 수정해주세요.
- 헤더, 푸터, 색상, 폰트, 다른 페이지는 변경하지 마세요.
- 기존 입력 필드 이름과 화면 문구는 유지해주세요.
- 데이터 저장 방식이 필요하면 기존 Supabase 연결 방식을 유지해주세요.

수정 후 확인:
- 빈 값 제출 시 오류 메시지가 보여야 합니다.
- 정상 제출 시 성공 메시지가 보여야 합니다.
- 제출 후 폼이 초기화되어야 합니다.

먼저 어떤 파일을 수정할지 짧게 설명한 뒤, 최소 변경으로 진행해주세요.

좋은 디버깅 프롬프트는 "무엇을 할지"뿐 아니라 "무엇을 하지 말아야 할지"도 알려 줍니다. 이 제한선이 있어야 러버블이 불필요한 변경을 줄입니다.

되돌릴 수 있으면 덜 무섭다

디버깅에서 초보자가 가장 무서워하는 것은 "더 망가질까 봐"입니다. 그래서 오히려 아무것도 못 하거나, 반대로 무작정 수정 버튼을 누르게 됩니다. 이 두 가지 모두 좋지 않습니다.

해결책은 체크포인트입니다.

체크포인트는 "여기까지는 정상"이라고 표시해 두는 지점입니다. 러버블은 프로젝트 히스토리를 통해 이전 버전을 확인하고 복원할 수 있습니다. 공식 FAQ에서도 채팅을 위로 스크롤하거나 히스토리 아이콘을 눌러 프로젝트 기록을 볼 수 있고, 이전 버전을 미리 본 뒤 복원할 수 있다고 설명합니다.⁵

큰 수정을 하기 전에는 채팅에 이런 메시지를 남겨 두세요.

체크포인트: 현재 버전은 정상 작동합니다.
정상 확인 항목:
- 홈 화면 표시 정상
- 문의 버튼 이동 정상
- 문의 폼 UI 표시 정상
- 모바일 화면 깨짐 없음

이후 변경은 이 상태를 기준으로 진행합니다.

이 메시지는 코드 변경을 요구하는 프롬프트가 아닙니다. 하지만 나중에 히스토리를 볼 때 "아, 이 지점까지는 괜찮았구나"라고 알아보는 표지판이 됩니다.

중요한 기능을 추가하기 전에는 프로젝트를 복제하거나, 가능하다면 GitHub 연동을 해 두는 것도 좋습니다. 자세한 개발자식 버전 관리는 이 책의 뒤쪽 확장 도구 장에서 더 다루겠지만, 지금 단계에서는 최소한 러버블의 히스토리만 제대로 써도 많은 사고를 막을 수 있습니다.

버전 히스토리로 돌아오는 법

화면이 깨졌거나 기능이 완전히 망가졌다면, 무조건 계속 고치려고 하지 마세요. 마지막 정상 버전으로 돌아가는 편이 더 빠를 수 있습니다.

러버블에서 이전 버전으로 돌아갈 때의 흐름은 간단합니다. 채팅 패널을 위로 올리거나 히스토리 아이콘을 눌러 이전 변경 기록을 확인합니다. 문제가 생기기 직전의 버전을 찾습니다. 그 버전을 미리 보기로 확인합니다. 정상이라면 Restore 또는 복원 버튼으로 되돌립니다. 복원하더라도 이후 기록이 전부 사라지는 것이 아니라, 나중에 다시 참고할 수 있는 형태로 남아 있다는 점도 알아 두면 마음이 편합니다.⁶

복원할 때는 반드시 미리 보기를 확인하세요. 초보자는 "아마 이쯤이겠지" 하고 바로 되돌리기 쉽습니다. 그런데 문제는 생각보다 더 이전에 시작됐을 수도 있습니다. 예를 들어 예약 폼이 오늘 망가진 것처럼 보였지만, 사실 어제 추가한 Supabase 필드 이름 변경부터 꼬였을 수 있습니다.

복원 버튼이 비활성화되어 있다면 당황하지 마세요. 프로젝트가 아직 작업을 처리 중이거나 GitHub 동기화 충돌 같은 상태일 수 있습니다. 이럴 때는 진행 중인 작업이 끝날 때까지 기다리고, 필요하면 브라우저를 새로고침한 뒤 다시 확인하는 식으로 접근합니다.⁶

되돌리기는 실패가 아닙니다. 되돌리기는 디버깅에서 가장 강력한 절약 기술입니다.

이전 메시지를 고치는 것도 되돌리기의 한 방식이다

러버블에서는 이전에 보낸 메시지를 수정하고, 그 지점으로 돌아가 다른 방향을 시도할 수 있습니다. 예를 들어 처음에 이렇게 요청했다고 해 봅시다.

상담 신청 페이지를 더 예쁘고 전문적으로 바꿔줘.

결과가 마음에 들지 않습니다. 버튼도 바뀌고, 문구도 바뀌고, 폼 위치도 바뀌었습니다. 이때 다음 메시지로 "아니야, 원래대로 돌리고 버튼만 바꿔줘"라고 계속 이어 가면 꼬일 수 있습니다.

차라리 처음 메시지를 더 정확하게 고치는 편이 좋습니다.

상담 신청 페이지의 전체 구조는 유지하고,
상단 CTA 버튼 색상만 브랜드 컬러 #2563EB로 변경해주세요.
문구, 폼 항목, 섹션 순서, 모바일 레이아웃은 변경하지 마세요.

이 방식은 "그때의 잘못된 요청" 자체를 더 나은 요청으로 바꾸는 것입니다. 초보자에게는 마치 타임머신처럼 느껴질 수 있습니다. 중요한 것은 같은 실수를 반복하지 않는 것입니다. 넓은 요청을 좁은 요청으로 바꾸세요.

화면이 이상할 때와 기능이 안 될 때는 다르게 본다

모든 오류를 같은 방식으로 다루면 안 됩니다. 화면이 이상한 문제와 기능이 안 되는 문제는 확인해야 할 지점이 다릅니다.

화면이 이상한 문제는 주로 UI 문제입니다. 예를 들어 모바일에서 버튼이 잘리거나, 카드가 겹치거나, 글자가 배경과 비슷해서 안 보이는 경우입니다. 이때는 스크린샷이 매우 강력한 증거가 됩니다. 러버블에 이미지를 함께 넣을 수 있다면 화면 캡처를 첨부하고, 어느 부분이 어떻게 이상한지 표시해 주세요.

이런 식으로 말하면 좋습니다.

첨부한 스크린샷의 모바일 화면에서 가격 카드 3개가 서로 겹칩니다.
이 문제는 가격 섹션의 모바일 반응형 레이아웃에서만 발생합니다.
데스크톱 레이아웃과 다른 섹션은 변경하지 말고,
가격 카드가 모바일에서 세로로 자연스럽게 쌓이도록 수정해주세요.

반면 기능이 안 되는 문제는 동작의 흐름을 설명해야 합니다. 버튼을 눌렀는지, 폼을 제출했는지, 페이지 이동이 안 되는지, 데이터가 저장되지 않는지 구체적으로 말해야 합니다.

문의 폼에서 이름, 이메일, 메시지를 모두 입력한 뒤 제출 버튼을 눌렀습니다.
기대 동작은 성공 메시지를 보여주는 것입니다.
현재는 아무 메시지도 나오지 않고 폼 내용도 그대로 남아 있습니다.
문의 폼 제출 기능만 확인하고 수정해주세요.

화면 문제에는 "어디가 어떻게 보이는지"가 중요하고, 기능 문제에는 "무엇을 했고 어떤 결과가 나왔는지"가 중요합니다.

데이터/API 오류는 브라우저가 많은 힌트를 준다

14장에서 Supabase를 아주 쉽게 살펴봤습니다. 이제 데이터가 들어가면 오류의 종류도 조금 달라집니다. 문의 폼, 예약 신청, 견적 요청처럼 데이터를 저장하거나 불러오는 기능에서는 화면이 멀쩡해 보여도 내부 연결이 실패할 수 있습니다.

대표적인 메시지는 Failed to fetch, 401, 403, 404, 500, CORS, undefined 같은 것들입니다. 겁먹을 필요는 없습니다. 대략 이렇게 이해하면 됩니다.

401 또는 403은 권한이나 인증 문제일 가능성이 큽니다.
404는 요청한 주소나 경로가 없다는 뜻일 가능성이 큽니다.
500은 서버 쪽에서 처리하다가 문제가 생겼다는 뜻일 가능성이 큽니다.
CORS는 브라우저 보안 정책 때문에 다른 주소의 데이터를 바로 가져오지 못하는 상황일 수 있습니다.
undefined가 주소에 섞여 있으면 필요한 환경 변수나 값이 비어 있을 가능성이 있습니다.

API 요청이 실패할 때는 브라우저 개발자 도구의 Network 탭에서 실제 요청 주소, 상태 코드, 응답 내용을 확인하는 방식이 도움이 됩니다. Lovable 앱도 브라우저에서 실행되므로 실패한 요청이 Network 탭에 표시될 수 있고, 이 정보가 원인을 좁히는 데 큰 단서가 됩니다.⁷

물론 이 책은 개발자 도구를 깊게 다루는 책은 아닙니다. 그래도 다음 정도는 알아 두면 좋습니다. 러버블 미리보기 화면에서 마우스 오른쪽 버튼을 누르고 검사 또는 Inspect를 선택합니다. Network 탭을 엽니다. 문제가 되는 버튼을 다시 눌러 봅니다. 빨간색으로 표시된 요청이나 400번대, 500번대 상태 코드를 찾습니다. 그 내용을 복사해 외부 AI나 러버블 Plan mode에 전달합니다.

이때도 비밀 키는 절대 붙여 넣지 마세요. 러버블 FAQ도 API 키 같은 민감한 값은 직접 입력하지 말고 Secrets나 Supabase Edge Functions 같은 안전한 방식을 사용하라고 안내합니다.⁴

Supabase 연결 오류를 말할 때의 프롬프트

데이터 저장 오류는 "안 돼요"라고 말하면 너무 막연합니다. Supabase와 연결된 폼이 실패할 때는 테이블 이름, 저장하려는 데이터, 기대 동작을 함께 말해야 합니다.

예를 들어 견적 요청 페이지에서 quote_requests 테이블에 데이터가 저장되지 않는 상황이라면 이렇게 요청할 수 있습니다.

아직 수정하지 말고 원인 분석만 해주세요.

상황:
견적 요청 페이지의 폼 제출 데이터가 Supabase의 quote_requests 테이블에 저장되어야 합니다.

기대 동작:
사용자가 이름, 이메일, 프로젝트 유형, 예산, 메시지를 입력하고 제출하면
quote_requests 테이블에 새 행이 추가되고 성공 메시지가 떠야 합니다.

실제 동작:
폼 제출 후 성공 메시지가 나오지 않거나 데이터가 저장되지 않습니다.

확인 요청:
1. 폼 필드 이름과 Supabase 테이블 컬럼 이름이 맞는지 확인해주세요.
2. insert 로직이 올바른지 확인해주세요.
3. 에러 처리와 성공 메시지 표시 로직이 있는지 확인해주세요.
4. RLS 정책이나 권한 문제가 의심된다면 그 가능성만 설명해주세요.
5. 아직 코드는 수정하지 말고, 최소 수정 계획만 제안해주세요.

주의:
다른 페이지, 디자인, 기존 문구는 변경하지 마세요.

이 프롬프트는 러버블에게 "데이터 저장 흐름만 봐 달라"고 말합니다. 테이블 권한이나 보안 정책은 초보자에게 낯설 수 있지만, 적어도 "권한 문제인지, 필드 이름 문제인지, 제출 로직 문제인지"를 나누어 볼 수 있게 됩니다.

라이브 사이트가 망가졌는지 먼저 확인한다

러버블에서 작업하다 보면 미리보기 화면이 깨져서 심장이 철렁할 때가 있습니다. 특히 이미 고객에게 링크를 보낸 사이트라면 더 무섭습니다.

이때 먼저 확인할 것은 "실제 배포된 사이트도 망가졌는가?"입니다. 러버블로 배포한 사이트는 보통 마지막으로 Publish한 상태를 기준으로 사용자에게 보입니다. 즉, 편집기 안에서 현재 작업 중인 버전이 깨졌다고 해서 이미 배포된 사이트까지 반드시 동시에 깨졌다는 뜻은 아닙니다. 관련 안내 자료에서도 게시된 앱은 스냅샷처럼 동작하므로, 라이브 앱은 마지막으로 게시한 버전이 유지될 수 있다고 설명합니다.⁸

확인 방법은 간단합니다. 배포된 주소를 시크릿 창이나 다른 브라우저에서 열어 봅니다. 고객이 보는 페이지가 정상이라면 일단 한숨 돌려도 됩니다. 지금 망가진 것은 작업 중인 편집기 버전일 가능성이 큽니다. 그러면 급하게 Publish를 누르지 말고, 편집기 안에서 복원하거나 수정하면 됩니다.

반대로 라이브 사이트도 망가졌다면 우선순위가 달라집니다. 이때는 새 기능 개발을 멈추고, 마지막 정상 배포 상태로 되돌리는 것을 먼저 생각해야 합니다. 부업이나 프리랜서용 페이지에서는 신뢰가 중요합니다. 멋진 새 기능보다 "문의 버튼이 정상 작동하는 것"이 먼저입니다.

디버깅이 길어질 때는 기준을 정해야 한다

가끔은 고치려고 할수록 더 꼬입니다. 오류 하나를 고쳤더니 다른 오류가 나고, 다시 고쳤더니 화면이 깨지고, 또 고쳤더니 데이터 저장이 안 됩니다. 이때 계속 붙잡고 있으면 크레딧도, 시간도, 의욕도 같이 사라집니다.

그래서 기준이 필요합니다. 저는 초보자에게 "세 번 규칙"을 권합니다.

같은 문제를 해결하려고 세 번 이상 러버블에게 수정 요청했는데도 해결되지 않았다면, 잠시 멈춥니다. 그리고 아래 중 하나를 선택합니다.

마지막 정상 버전으로 되돌린다.
문제 기능을 빼고 MVP 범위로 축소한다.
새 프로젝트로 다시 만드는 편이 싼지 판단한다.

특히 무료 사용자라면 세 번째 판단이 중요합니다. 러버블에서는 새 프로젝트를 만드는 것이 심리적으로 아깝게 느껴질 수 있습니다. "여기까지 만들었는데 어떻게 버려?"라는 생각이 듭니다. 하지만 초반 MVP라면, 꼬인 프로젝트를 계속 고치는 것보다 기획서와 스케치를 바탕으로 새로 만드는 편이 더 빠를 때가 많습니다.

새 프로젝트로 다시 만드는 편이 더 싼 경우

새 프로젝트로 다시 시작해도 되는 대표적인 상황이 있습니다.

첫째, 아직 실제 고객이나 사용자가 없습니다. 배포 링크를 널리 공유하지 않았고, 문의나 예약 데이터도 쌓이지 않았다면 부담이 적습니다.

둘째, 외부 AI에서 만든 PRD와 IA, 화면 스케치가 남아 있습니다. 이 책에서 계속 강조한 것처럼 기획을 러버블 밖에서 해 두었다면 재시작 비용이 크게 줄어듭니다. 처음부터 다시 생각할 필요 없이, 이미 정리한 구현 지시서를 다시 쓰면 됩니다.

셋째, 오류가 특정 한 곳이 아니라 프로젝트 전반에 퍼져 있습니다. 예를 들어 라우팅, 폼, 디자인 시스템, Supabase 연결이 동시에 꼬였고 어떤 요청 이후부터 문제가 시작됐는지도 불분명하다면 복구보다 재구축이 나을 수 있습니다.

넷째, 원래 만들려던 범위보다 너무 커졌습니다. 처음에는 프리랜서 포트폴리오와 문의 폼만 만들려 했는데, 로그인, 관리자 페이지, 결제, 대시보드까지 한 번에 넣다가 망가졌다면 새 프로젝트에서 MVP로 줄여 다시 시작하는 편이 좋습니다.

다섯째, "정상 버전"을 찾기 어렵습니다. 히스토리를 여러 단계 돌아가도 계속 이상하고, 어디까지가 안정적인 상태인지 판단이 안 된다면 새 출발이 더 저렴할 수 있습니다.

반대로 새 프로젝트로 쉽게 갈아타면 안 되는 경우도 있습니다. 이미 고객 데이터가 Supabase에 쌓여 있거나, 유료 고객이 사용 중이거나, 결제·로그인·권한 기능이 복잡하게 연결되어 있거나, 커스텀 도메인과 SEO 설정을 꽤 많이 해 둔 경우입니다. 이런 경우에는 무작정 새로 만들기보다 백업, 복원, GitHub 연동, 전문가 도움까지 고려해야 합니다.

새 프로젝트로 갈아탈 때의 안전한 프롬프트

새 프로젝트로 다시 만들기로 결정했다면, 절대 이렇게 시작하지 마세요.

이전 프로젝트처럼 똑같이 만들어줘.

러버블은 이전 프로젝트의 모든 맥락을 완벽히 알지 못합니다. 그리고 "똑같이"라는 말은 모호합니다. 대신 이전 프로젝트에서 배운 점을 반영해 더 작고 명확한 프롬프트로 시작해야 합니다.

다음 기획서를 바탕으로 새 Lovable 프로젝트를 만들어주세요.
이번 버전은 MVP이므로 범위를 작게 유지합니다.

목표:
프리랜서 [직무]가 잠재 고객에게 작업 사례를 보여주고 문의를 받을 수 있는 단일 페이지 웹사이트를 만든다.

포함할 섹션:
1. 히어로 섹션: 한 문장 소개, CTA 버튼
2. 서비스 소개: 3개 카드
3. 작업 사례: 3개 카드
4. 진행 방식: 상담 → 제안 → 제작 → 전달
5. 문의 섹션: 이름, 이메일, 메시지 입력 폼
6. 푸터: 이메일과 SNS 링크

제외할 기능:
- 로그인 없음
- 결제 없음
- 관리자 페이지 없음
- 복잡한 데이터 대시보드 없음

디자인:
깔끔하고 신뢰감 있는 프리랜서 포트폴리오 스타일.
모바일에서 먼저 보기 좋게 구성.

중요:
첫 버전에서는 화면과 기본 폼 UI만 만듭니다.
Supabase 저장 연결은 다음 단계에서 별도로 추가합니다.

이 프롬프트는 재시작용입니다. 중요한 것은 "이번에는 어디까지 만들지"를 더 엄격하게 제한하는 것입니다. 이전 프로젝트가 망가진 이유가 범위 확장이었다면, 새 프로젝트의 첫 프롬프트는 작아야 합니다.

디버깅 일지를 남기면 다음 오류가 쉬워진다

문제를 해결하고 나면 바로 다음 기능을 만들고 싶어집니다. 하지만 2분만 더 써서 디버깅 일지를 남기세요. 이 습관은 나중에 큰 차이를 만듭니다.

러버블에게 이렇게 요청할 수 있습니다.

이번 오류에 대해 초보자도 이해할 수 있게 디버깅 요약을 작성해주세요.
다음 내용을 포함해주세요.

1. 어떤 문제가 있었는지
2. 원인이 무엇이었는지
3. 어떤 파일 또는 기능을 수정했는지
4. 다시 같은 문제가 생기면 무엇을 확인해야 하는지
5. 이번 수정에서 건드리지 않은 범위는 무엇인지

코드는 길게 쓰지 말고, 작업 기록용으로 짧게 정리해주세요.

이 요약을 프로젝트 메모나 별도 문서에 붙여 두면 좋습니다. 나중에 "아, 예전에 폼 저장이 안 됐던 게 필드 이름 문제였지" 하고 빠르게 떠올릴 수 있습니다.

프리랜서나 개인 사업자에게 디버깅 일지는 기술 문서이기도 하지만 운영 기록이기도 합니다. 어떤 오류가 있었고 어떻게 복구했는지 남겨 두면, 클라이언트에게 설명해야 할 때도 당황하지 않습니다.

실전 예시: 예약 신청 버튼이 멈췄을 때

상황을 하나 가정해 보겠습니다. 당신은 11장에서 만든 예약·상담 신청 페이지를 다듬고 있습니다. 날짜 선택, 이름, 이메일, 상담 내용을 입력하고 "상담 신청하기" 버튼을 누르면 성공 메시지가 떠야 합니다. 그런데 버튼을 누르면 로딩 표시만 돌고 아무 일도 일어나지 않습니다.

초보자의 나쁜 대응은 이렇습니다.

예약 페이지가 안 돼. 전체적으로 확인해서 고쳐줘.

좋은 대응은 순서가 다릅니다.

먼저 직접 재현합니다. 이름, 이메일, 날짜, 상담 내용을 모두 채우고 버튼을 누릅니다. 같은 문제가 반복되는지 봅니다. 그다음 오류 메시지가 있으면 복사합니다. 개발자 도구를 열 수 있다면 Console이나 Network 탭에서 빨간 메시지를 확인합니다.

그리고 외부 AI에게 설명시킵니다.

Lovable에서 만든 예약 상담 페이지의 폼 제출이 멈춥니다.
버튼을 누르면 로딩 상태가 계속되고 성공 메시지가 나오지 않습니다.
오류 메시지는 다음과 같습니다.
[오류 붙여넣기]

초보자도 이해할 수 있게 가능한 원인을 설명하고,
Lovable에 분석만 요청할 프롬프트를 만들어주세요.

외부 AI가 "Supabase 저장 요청 실패일 수 있다", "필수 값이 비어 있을 수 있다", "에러 처리가 없어 화면에 표시되지 않을 수 있다" 같은 후보를 알려줄 수 있습니다.

이제 러버블에 분석만 요청합니다.

아직 수정하지 마세요.
예약 상담 신청 페이지의 폼 제출 오류 원인만 분석해주세요.

증상:
사용자가 모든 필드를 입력하고 제출 버튼을 누르면 로딩 상태가 계속되고 성공 메시지가 나오지 않습니다.

확인할 범위:
- 예약 상담 신청 폼 컴포넌트
- 제출 핸들러
- Supabase insert 또는 저장 로직
- 로딩 상태와 에러 상태 처리

요청:
1. 가능한 원인을 설명해주세요.
2. 어떤 파일을 확인해야 하는지 알려주세요.
3. 최소 수정 계획을 제안해주세요.
4. 아직 코드는 변경하지 마세요.
5. 헤더, 푸터, 다른 섹션 디자인은 변경하지 마세요.

러버블이 원인을 분석한 뒤 "제출 실패 시 로딩 상태를 false로 되돌리지 않는다"거나 "성공·실패 메시지 처리가 빠져 있다"는 식으로 알려줄 수 있습니다. 그다음에야 수정 요청을 합니다.

분석한 원인 중 폼 제출 후 로딩 상태와 성공/실패 메시지 처리 문제만 수정해주세요.

수정 범위:
- 예약 상담 신청 폼 제출 로직
- 로딩 상태 종료 처리
- 성공 메시지와 실패 메시지 표시

변경 금지:
- 페이지 디자인 변경 금지
- 폼 필드 추가/삭제 금지
- 다른 페이지 수정 금지
- Supabase 테이블 구조 변경 금지

수정 후 다음 동작을 확인해주세요.
1. 정상 제출 시 성공 메시지가 보인다.
2. 실패 시 사용자가 이해할 수 있는 오류 메시지가 보인다.
3. 제출 완료 후 버튼 로딩 상태가 풀린다.

이렇게 하면 러버블이 고쳐야 할 범위가 명확해집니다. 디버깅은 "똑똑한 한 방"이 아니라 "범위를 줄이는 기술"입니다.

오류 유형별 첫 질문

초보자는 오류를 만났을 때 어떤 질문부터 해야 할지 막막합니다. 아래 문장들을 상황에 맞게 바꿔 쓰면 됩니다.

화면이 하얗게 비었을 때는 이렇게 묻습니다.

아직 수정하지 말고 원인만 분석해주세요.
현재 미리보기 화면이 빈 화면으로 표시됩니다.
마지막으로 요청한 변경은 [마지막 요청 내용]입니다.
Console 오류는 다음과 같습니다.
[오류 메시지]
어떤 변경이 빈 화면을 만들었을 가능성이 큰지 설명하고,
최소 수정 계획만 제안해주세요.

버튼이 작동하지 않을 때는 이렇게 묻습니다.

[페이지 이름]의 [버튼 이름] 버튼이 작동하지 않습니다.
버튼을 클릭하면 [현재 결과]가 나타나고,
기대 결과는 [기대 결과]입니다.
이 버튼의 클릭 동작과 연결된 코드만 분석해주세요.
아직 수정하지 말고 원인 후보와 확인할 파일을 알려주세요.

디자인이 이상해졌을 때는 이렇게 묻습니다.

마지막 변경 이후 [섹션 이름]의 레이아웃이 깨졌습니다.
문제는 [모바일/데스크톱] 화면에서 발생합니다.
다른 섹션은 정상입니다.
[섹션 이름]의 반응형 레이아웃만 확인하고,
다른 디자인 요소는 변경하지 않는 수정 계획을 제안해주세요.
아직 코드는 수정하지 마세요.

Supabase 저장이 안 될 때는 이렇게 묻습니다.

[폼 이름] 제출 데이터가 Supabase의 [테이블 이름] 테이블에 저장되지 않습니다.
폼 제출 UI는 보이지만 데이터가 추가되지 않습니다.
폼 필드 이름, insert 로직, 에러 처리, 권한 문제 가능성만 분석해주세요.
테이블 구조 변경은 아직 하지 말고,
최소 수정 계획만 알려주세요.

이 문장들의 공통점은 분명합니다. 모두 "아직 수정하지 말라"고 말합니다. 그리고 "어디만 보라"고 범위를 좁힙니다.

AI에게도 잠깐 의심의 눈을 가져야 한다

러버블이 제안하는 해결책이 항상 맞지는 않습니다. 외부 AI의 설명도 항상 맞지는 않습니다. AI는 그럴듯한 설명을 할 수 있지만, 실제 프로젝트의 상태를 완벽히 이해하지 못할 수 있습니다.

그래서 수정 전에는 항상 이렇게 물어보는 습관을 들이세요.

이 수정이 기존 기능에 줄 수 있는 부작용은 무엇인가요?
수정 범위를 더 줄일 수 있나요?
이 문제를 해결하는 더 단순한 방법이 있나요?

특히 로그인, 결제, 데이터 저장, 권한 설정처럼 민감한 기능에서는 더 조심해야 합니다. 작은 변경이 사용자의 접근 권한이나 데이터 저장 방식에 영향을 줄 수 있기 때문입니다. 러버블의 디버깅 가이드에서도 오래 지속되는 오류는 원인을 설명하게 하고, 기존에 시도한 방법을 확인하고, 필요하면 되돌린 뒤 더 작은 단위로 다시 진행하는 접근을 제안합니다.³

초보자에게 필요한 태도는 "AI를 믿지 말자"가 아닙니다. "AI를 좋은 동료로 쓰되, 작업 범위와 검증 기준은 내가 정하자"입니다.