디버깅 프롬프트
Plan mode를 사용하여 오류를 조사하고, 코드베이스 감사를 실행하고, 민감한 업데이트를 안전하게 처리하고, 지속적인 문제를 체계적으로 해결하세요.
AI로 빌드하는 것은 빠르고 재미있습니다 – 무언가 잘못될 때까지. 오류, 예상치 못한 동작 또는 "AI가 이상한 짓을 했다" 순간은 과정의 일부입니다. 이 가이드는 Lovable에서 AI 기반 디버깅 워크플로우를 탐색하는 데 도움이 됩니다. 간단한 문제를 빠르게 수정하는 방법, 더 어려운 버그에 대한 전략, 디버깅을 위한 Lovable의 채팅 사용, 그리고 체계적으로 버그를 잡는 프롬프트 레시피까지 다룹니다. AI 어시스턴트와 디버깅하는 것은 새로운 기술이지만, 구조와 올바른 프롬프트로 문제를 효율적으로 해결하고 학습 기회로 전환할 수 있습니다.
고급 디버깅 프롬프트
때로는 문제를 깊이 파고들거나 프로젝트 상태를 검토하기 위해 강력한 프롬프트가 필요합니다. 다음은 심층 디버깅 또는 최적화 시나리오를 위한 구조화된 프롬프트 예시입니다. Plan mode에서 사용하여 코드를 즉시 변경하지 않고 철저한 분석을 얻을 수 있습니다.
전체 시스템 검토 (코드베이스 감사)
프로젝트가 커졌거나 구조적 문제가 있다고 의심되는 경우, 전체 코드베이스 감사 프롬프트가 유용할 수 있습니다. AI에게 전체 프로젝트를 분석하여 깔끔함, 올바른 아키텍처, 잘못 배치된 코드를 확인하도록 요청합니다. "모든 것이 있어야 할 곳에 정리되어 있나요?"라고 묻는 것과 같습니다.
예시 프롬프트 – 코드베이스 감사:
아키텍처가 깔끔하고, 모듈식이고, 최적화되어 있는지 확인하기 위해 <strong>전체 코드베이스의 포괄적인 감사</strong>를 수행하세요:
- 잘못된 위치에 있거나 더 잘 구성될 수 있는 파일, 컴포넌트 또는 로직을 식별하세요. 현재 파일에 속하지 않는 코드 인스턴스(잘못 배치된 로직)가 있나요?
- 관심사의 명확한 분리가 있는지 평가하세요 (예: 데이터 처리 vs UI vs 상태 관리). 지나치게 결합된 코드 섹션을 지적하세요.
- 지나치게 복잡하거나 모범 사례를 따르지 않는 코드 영역을 강조하세요.
- **아직 코드를 변경하지 않고** 구조와 유지 관리성을 개선하기 위한 구체적인 권장 사항이 포함된 보고서를 제공하세요.
가장 중요한 것부터 선택적 개선 사항까지 순서가 지정된 단계 목록으로 제안을 분류하세요.
*(이것은 읽기 전용 분석입니다; 이 감사 중에 코드를 수정하지 마세요.)*이 프롬프트는 길지만, AI가 코드 리뷰어나 아키텍트처럼 행동하도록 지시합니다. 잘못 배치된 코드를 찾고, 모듈성을 확인하고, 수정 사항의 우선순위를 정하도록 요청했습니다. AI는 다음과 같이 응답할 수 있습니다:
- _"1. API 호출을 컴포넌트에서 분리:** _
ProjectList컴포넌트가 직접 데이터를 가져오고 있습니다. 제안: 컴포넌트를 순수 UI로 유지하기 위해 데이터 가져오기를 전용 hook 또는 context로 이동하세요.
- Task 로직의 결합 줄이기: task 완료 토글이 상태를 업데이트하고 localStorage에 직접 쓰고 있습니다. 단일 진실 소스를 갖도록 리팩토링해야 합니다.
- 유틸리티 함수 정리:
App.tsx에utils폴더에 더 잘 배치될 유틸리티 함수가 있습니다 (예: 날짜 포맷팅 함수). - ..."*
각 포인트에는 설명과 특정 파일에 대한 참조가 포함될 수 있습니다. 이러한 보고서는 전체를 보는 데 도움이 됩니다. 한 번에 하나의 기능에 집중하고 전체 구조를 한동안 보지 않았다면 특히 유용합니다.
일반적이고 광범위한 프롬프트를 피하세요
아무것도 작동하지 않아요, 고쳐주세요!프롬프트를 더 상세하고 구체적으로 만드세요
지금 화면이 비어 있고 더 이상 편집할 수 없습니다.
무슨 일이 일어났는지 확인해 주시겠어요?이 출력을 받은 후, 어떤 리팩토링 작업을 수행할지 결정할 수 있습니다 (AI에게 해당 권장 사항 중 일부를 하나씩 구현하도록 프롬프트할 수도 있습니다).
민감한 업데이트를 위한 안전한 접근 방식
변경하려는 영역이 민감하다는 것을 알고 있을 때 (복잡한 인증 흐름이나 핵심 알고리즘 등), 프롬프트에 주의 사항 가이드라인을 앞에 추가하는 것이 현명합니다. 이것은 버그를 찾는 것이 아니라, AI에게 특히 조심하라고 말함으로써 버그를 예방하는 데 도움이 됩니다. 파일 잠금에 대한 프롬프트 라이브러리 섹션에서 비슷한 패턴을 보았습니다. 여기 망가뜨리지 않는 것에 초점을 맞춘 비슷한 패턴이 있습니다.
예시 프롬프트 – 민감한 업데이트 가이드:
다음 변경은 <strong>앱의 중요한 부분</strong>에 있으므로 **극도로 조심해서** 진행하세요.
- 변경하기 *전에* 모든 관련 코드와 종속성을 주의 깊게 검토하세요.
- 관련 없는 컴포넌트나 파일에 대한 **어떠한 수정도 피하세요**.
- 불확실한 점이 있으면 계속하기 전에 사고 과정을 멈추고 설명하세요.
- 다른 것에 영향을 미치지 않았는지 확인하기 위해 변경 후 철저한 테스트를 보장하세요.
**작업:** 기존 이메일/비밀번호를 망가뜨리지 않고 Google을 통한 OAuth 로그인을 지원하도록 사용자 인증 로직을 업데이트하세요.
*(구현 중 각 단계를 극도로 조심하고 다시 확인하세요.)*기울임꼴 가이드라인과 굵은 경고를 포함함으로써, AI의 "마음가짐"을 조심스럽게 설정하는 것입니다. 그러면 AI는 먼저 무엇을 할지 설명하거나, 이메일/비밀번호를 그대로 두었음을 명시적으로 언급하면서 OAuth 추가를 구현하는 등 더 신중한 접근 방식을 취할 수 있습니다. 이 프롬프트는 즉시 솔루션을 출력하지 않습니다; 오히려, AI가 새로운 버그를 도입하는 것을 최소화하기 위해 작업을 어떻게 수행할지에 영향을 미칩니다.
이 전략은 민감한 섹션에 유용합니다: 인증, 결제 처리, 데이터 마이그레이션 – 작은 실수가 많은 것을 망가뜨릴 수 있는 모든 것. 이것은 선제적 디버깅 조치입니다.
성능 최적화 검사
앱이 올바르게 작동하지만 느리거나 리소스를 많이 사용하는 경우, AI에게 성능을 분석하도록 프롬프트할 수 있습니다. 이것은 데이터 가져오기 패턴 검토, 렌더링 비효율성 확인 또는 최적화 제안 (캐싱, 메모이제이션 등)을 포함할 수 있습니다. "어떻게 하면 더 빠르고 부드럽게 만들 수 있을까요?"라고 묻는 것과 같습니다.
예시 프롬프트 – 성능 감사:
우리 앱은 기능적이지만 **느린** 것 같습니다. <strong>프로젝트의 성능 병목 현상을 분석</strong>하고 최적화를 제안해 주세요:
- 불필요한 데이터베이스 또는 네트워크 호출을 확인하세요 (예: 중복 가져오기 또는 N+1 쿼리 패턴).
- 너무 자주 다시 렌더링되거나 메인 스레드에서 무거운 작업을 수행하는 컴포넌트를 식별하세요.
- 에셋 사용을 확인하세요 (이미지, 스크립트): 로드 시간에 영향을 미치는 큰 번들이나 최적화되지 않은 에셋이 있나요?
- 자주 사용되는 데이터 캐싱, 적절한 곳에 React memo 또는 lazy loading 사용 등 앱 속도를 높이는 다른 방법을 제안하세요.
목록으로 분석과 권장 사항을 제공하세요. 아직 코드를 변경하지 마세요 – 더 나은 성능을 위해 무엇을 개선할지만 알려주세요.Plan mode에서 이것을 실행하면 진단 보고서를 얻을 수 있습니다. AI는 예를 들어 다음과 같이 말할 수 있습니다:
- "데이터 가져오기:
ProjectList컴포넌트가 모든 렌더링에서 데이터를 가져옵니다. 캐싱하거나 불필요하게 반복되지 않도록 가져오기를 더 높은 context로 이동하여 개선할 수 있습니다. 한 번 가져온 프로젝트를 저장하기 위해 상태나 context를 사용하는 것을 고려하세요. - 다시 렌더링:
TaskItem컴포넌트가 메모이제이션되지 않아 부모 상태가 변경될 때마다 다시 렌더링됩니다. 작업이 많으면 인터랙션이 느려질 수 있습니다. 제안: 불필요한 다시 렌더링을 방지하기 위해TaskItem에React.memo를 사용하세요. - 에셋: 2MB인 이미지(로고)가 있습니다. 꽤 큽니다; 더 빠른 로딩을 위해 압축하거나 더 작은 해상도를 사용하세요.
- 번들 크기: 모든 페이지가 하나의 번들에 있습니다. 초기 로드가 더 빠르도록 코드 분할 (큰 모듈에 대한 동적
import())을 고려하세요. - ..."*
각 제안은 일반적인 성능 모범 사례에서 나옵니다. 그런 다음 어떤 것을 구현할지 결정할 수 있습니다. Lovable에게 그 중 하나를 적용하도록 프롬프트할 수 있습니다: "제안대로 context를 사용하여 프로젝트 데이터에 대한 캐싱을 구현하세요." 이것들을 해결함으로써 사용자 경험을 개선하고 비용을 줄일 수 있습니다 (더 적은 호출, 더 적은 계산).
지속적인 오류 처리
사라지지 않거나 약간의 변형으로 계속 돌아오는 오류는 어떻게 해야 할까요? 이것은 근본 원인이 해결되지 않은 경우 발생할 수 있습니다. 예를 들어, 한 가지를 수정하지만 기본 문제가 다른 곳에서 새로운 오류로 나타납니다. 이에 대한 전략이 있습니다:
- AI에게 이미 시도한 것을 물어보세요. 몇 번의 "Try to Fix" 시도나 수동 프롬프트 후에 무엇이 변경되었는지 불분명할 때가 있습니다. 다음을 사용하세요: _"이 오류에 대해 지금까지 어떤 솔루션을 시도했나요?"_. AI는 시도를 나열할 수 있으며, 같은 수정을 반복하는 것을 피하는 데 도움이 됩니다.
- AI에게 오류를 간단한 용어로 설명하게 하세요. "이 오류가 왜 발생하는지 간단한 용어로 설명해 주세요." 이것은 AI(와 당신)가 진정으로 이해하고 있는지 드러낼 수 있습니다. 여기서 오해를 잡을 수 있습니다.
- 대안적 접근 방식을 고려하세요. 물어보세요: _"이 오류가 계속 발생하는 것을 감안할 때, 목표를 달성하기 위해 다른 접근 방식을 시도할 수 있을까요?"_. AI는 문제가 있는 영역을 우회하는 다른 구현 전략을 제안할 수 있습니다.
- 되돌리고 다시 시작하세요. 최악의 경우, 몇 단계를 롤백해야 할 수 있습니다. Lovable은 이전 버전으로 되돌리고 과거 메시지를 편집하고 다른 접근 방식을 취하기 위해 되돌릴 수 있게 합니다. 그런 다음 더 작은 변경으로 진행하세요.
마지막으로, 특정 컴포넌트가 "죽은" 경우 (무엇을 해도 전혀 작동하지 않는 경우), 격리하세요. 프롬프트를 통해 해당 컴포넌트의 새로운 최소 버전을 만들어 작동하는지 확인한 다음 프로젝트에 천천히 다시 통합하세요. 이것은 전원을 끄고 켜는 것과 비슷하지만 코드로 – 때때로 지나치게 망가진 것을 패치하려고 하는 것보다 조각을 새로 시작하는 것이 더 쉽습니다.
이 모든 과정에서 AI와 대화를 유지하세요. 협력자처럼 대하세요: "X를 수정했지만 이제 Y가 이상하게 작동합니다. X와 Y의 관계는 무엇인가요? 수정이 Y의 문제를 일으킬 수 있었나요?" AI는 당신이 보지 못한 연결을 만들 수 있습니다.
샘플 디버깅 흐름
이러한 아이디어를 확고히 하기 위해 예시 흐름과 함께 두 가지 일반적인 디버깅 시나리오를 살펴보겠습니다:
"오류 루프에 갇힌" 경우
복잡한 것을 프롬프트했고, 이제 앱이 빌드되지 않고 Try to Fix가 두 번 실패했습니다.
흐름:
Plan mode로 전환합니다.
'이 빌드 오류의 근본 원인은 무엇인가요?'라고 물어봅니다.
AI가 API 호출의 타입 불일치라고 설명합니다.
그런 다음 '관련 코드와 예상 타입을 보여주세요.'라고 말합니다.
AI가 함수가 ID 숫자를 예상했지만 객체를 받았다고 보여줍니다.
이제 이것을 보았으니, '전체 객체가 아닌 숫자 ID만 함수에 전달하도록 코드를 조정하세요.'라고 프롬프트합니다.
Default로 전환하고, 해당 프롬프트를 실행하면, 빌드가 성공합니다.
그렇지 않다면, 돌아가서 '이것을 일으킬 수 있는 다른 것은 무엇인가요?' 등을 물어볼 것입니다.
전체 과정에서 오류를 구체적으로 설명하고 AI가 이해했는지 확인했습니다. 무작정 수정을 반복적으로 누르는 것이 아니라.
"기능이 제대로 작동하지 않는" 경우
알림 기능을 추가했지만 이메일이 전송되지 않습니다.
흐름:
오류가 표시되지 않으므로 채팅에서 '이메일 알림이 작동하지 않습니다 – 작업이 기한이 지났을 때 이메일을 예상했는데 아무것도 없습니다. 이것을 어떻게 디버그할 수 있나요?'라고 물어봅니다.
AI가 서버 함수가 트리거되었는지와 이메일 서비스 응답에 오류가 있었는지 확인하라고 제안합니다.
서버 로그 (아마도 Supabase에서)를 가져와서 권한 오류를 확인합니다.
이것을 AI에게 보여줍니다: '로그에 '이메일을 보내려고 할 때 권한 거부'라고 나옵니다.'
AI가 이메일 서비스의 API 키가 설정되지 않았거나 서비스가 차단했을 수 있다고 파악합니다.
그런 다음 설정에서 API 키를 수정하거나 (Lovable 외부에서) 다른 방법을 사용하도록 함수를 조정하라고 프롬프트합니다.
본질적으로, 예상한 것 (이메일)과 일어난 것 (아무것도, 로그 스니펫과 함께)을 설명함으로써 AI가 조사를 안내할 수 있었습니다.
"UI 요소가 사라진" 경우
무언가를 리팩토링했고 이제 UI의 전체 섹션이 사라졌습니다 ("죽은 컴포넌트").
흐름:
AI에게 '프로젝트 목록 섹션이 더 이상 전혀 표시되지 않습니다. 마지막 편집 전에는 작동했습니다.'라고 말합니다.
AI가 컴포넌트가 여전히 렌더링되고 있는지 또는 return 문이 누락되었는지 확인할 수 있습니다.
아마도 리팩토링이 부모의 JSX에서 ProjectList를 제거했다는 것을 인식합니다. 다시 import하고 포함하라고 제안합니다. 또는 부모의 상태 변경으로 인해 목록이 의도치 않게 필터링되었을 수 있습니다.
AI가 가능성을 검토할 수 있습니다: '데이터가 여전히 가져와지고 있나요? 컴포넌트가 데이터를 받고 있나요? props를 받고 있는지 확인하기 위해 렌더링에 console.log를 추가해 봅시다.'
그렇게 하면 (또는 AI가 프롬프트를 통해), 아무것도 로그되지 않습니다 – 컴포넌트가 마운트되지 않았다는 의미입니다.
아하\! 그래서 _"Dashboard 페이지 JSX에서 _<ProjectList>*를 복원하세요 (실수로 제거되었습니다)."*라고 프롬프트합니다. 문제 해결.
이 흐름에서 핵심은 컴포넌트가 완전히 사라졌다는 것을 인식하고 전달하는 것이었습니다. AI가 왜 그런지 (렌더링되지 않음 vs 렌더링되었지만 비어 있음 등)를 정확히 파악하는 데 도움이 되었습니다.
Dev tools와 console logs 사용
앱이 더 이상 작동하지 않고 화면이 비어 있습니다.
Dev tools 콘솔에서 복사/붙여넣기한 내용입니다. 문제를 수정해 주시겠어요?
Error occurred:
TypeError: Q9() is undefined at https://example.lovable.app/assets/index-DWQbrtrQQj.js
: 435 : 39117 index-DWQbrtrQQj.js:435:35112
onerror https://example.lovable.app/assets/index-DWQbrtrQQj.js:435이 모든 경우에서 커뮤니케이션과 점진적 단계가 친구입니다. AI가 세부 사항을 기억하고 (이전에 무엇을 했는지처럼) 로그나 오류를 분석하는 강점을 사용하세요. 그리고 프로세스를 조종하는 당신의 강점을 사용하세요 – 높은 수준의 목표를 이해하고 다른 각도를 시도할 시기를 결정할 수 있습니다.
근본 원인 분석, 롤백 및 점진적 개선
몇 가지 마지막 조언:
근본 원인 vs. 증상
항상 "왜 이런 일이 일어났나요?"라고 물어보세요. "지금 무엇을 해야 하나요?"가 아니라. AI는 무언가를 수정할 때 수정된 상태로 유지되도록 근본 원인을 찾는 데 도움이 될 수 있습니다. 예를 들어, AI의 빠른 수정이 오류를 침묵시키지만 기본 로직 버그를 해결하지 않을 수 있습니다. 그것이 의심된다면 더 깊이 파고드세요:
검사를 추가하여 null 포인터 오류를 수정한 것을 보았는데, 애초에 왜 null이었나요? 그 원인을 해결할 수 있나요?
이것은 더 강력한 솔루션으로 이어집니다.
현명하게 롤백하기:
Lovable은 이전 버전으로 롤백할 수 있게 합니다. 일련의 나쁜 수정으로 코드가 너무 엉켜졌다면 사용하는 것을 망설이지 마세요. 되감고 다른 접근 방식을 시도하는 것이 종종 더 빠릅니다. 롤백하면 AI에게 무엇을 하고 있는지 알려주세요 (갑자기 다른 코드로 혼란스럽지 않도록). 예를 들어:
프로젝트를 알림 기능 이전으로 되돌렸습니다. 이번에는 더 조심해서 다시 구현해 봅시다.
이렇게 하면 AI가 일부 변경 사항을 취소하고 다시 시도한다는 컨텍스트를 갖게 됩니다.
점진적 개선:
새로운 기능을 추가할 때 (특히 복잡한 것), 작고 테스트 가능한 증분으로 빌드하세요. 이것은 단지 프롬프팅 팁이 아닙니다 – AI와 잘 어울리는 개발 철학입니다. 무언가 망가지면 어떤 작은 단계가 원인인지 정확히 알 수 있습니다. 프롬프트별로 앱을 개선하면 프롬프트별로 격리하여 디버그할 수도 있습니다. 여러 기능 변경이 포함된 긴 프롬프트를 작성하고 있다면 여러 프롬프트로 분할하는 것을 고려하세요. 나중에 문제 해결이 필요할 때 감사할 것입니다.
- 실패하는 테스트 케이스를 추가하세요.
- 문제를 격리하고 종속성을 분석하세요.
- 수정을 적용하기 전에 발견 사항을 문서화하세요.
여기 실패하는 콘솔 로그가 있습니다. 테스트 케이스를 분석하고, auth 흐름의 오류를 조사하고, 종속성을 이해한 후 솔루션을 제안하세요.진행하면서 문서화하기:
노트를 유지하는 것이 도움이 됩니다 (또는 세션 후 AI에게 수행한 작업을 요약하도록 요청하세요). 이것은 역 메타 프롬프팅과 비슷합니다 – 수정 기록을 만듭니다. 예를 들어, 어려운 버그를 해결한 후 다음과 같이 프롬프트할 수 있습니다:
문제가 무엇이었고 어떻게 수정했는지 요약해 주세요.
AI의 요약은 README나 로그에 저장할 수 있습니다. 이것은 미래의 당신이나 프로젝트의 다른 사람이 무슨 일이 일어났는지 이해하는 데 좋습니다.
언제 사람의 도움을 요청해야 하는지 알기:
때때로, 모든 노력에도 불구하고 벽에 부딪힐 수 있습니다 (Lovable 플랫폼의 진정한 버그이거나 당신/AI의 통제 밖의 무언가). Lovable 커뮤니티와 지원이 있습니다. Discord나 포럼에서 질문하는 것을 부끄러워하지 마세요. 종종 다른 사람들도 비슷한 문제에 직면했습니다. 먼저 AI를 사용하여 가능한 많은 정보를 수집하고 (세부 정보를 제공할 수 있도록), 필요하면 커뮤니티에 물어보세요.
커뮤니티 디버깅 가이드북
이 가이드북은 커뮤니티 Discord에서 공유되었습니다 — 프로젝트 디버깅에 유용할 수 있습니다: