무언가 깨졌을 때 초보자는 보통 이렇게 합니다. AI에게 '안 돼요, 고쳐줘'라고 말하고, AI가 아무 데나 손대고, 다른 곳이 또 깨지고, 다시 '이것도 안 돼요'… 이 악순환의 원인은 하나입니다. '어디가 왜 잘못됐는지'를 건너뛴 채 '고치기'부터 하는 것입니다.
좋은 디버깅의 절반은 '찾기'입니다. 위치와 원인을 먼저 특정하면, 고치기는 오히려 쉬운 뒷부분입니다.
디버깅 루프
디버깅 루프 — 찾고, 넘기고, 고치고, 다시 확인
- 문제 발생 에러 메시지 · 화면 깨짐
- 찾기 — 어디서·무엇이 잘못됐나 에러 메시지 전문 + 깨진 화면 스크린샷 확보
- AI에게 맥락째 넘기기 '이 에러 전문 + 이 화면 + 이 파일을 봐 줘'
- 후보 수정안 적용 대개는 그대로 수락
- 고쳐졌나? — 되면 완료, 안 되면 반복 여러 번 반복 — 인내심
핵심은 순서입니다. 먼저 위치와 원인을 특정하고(①), 정보를 통째로 넘긴 뒤(②), 고치고(③), 될 때까지 침착하게 반복합니다.
디버깅 실전 순서
- 에러 메시지를 '일부'가 아니라 '전문'을 그대로 복사합니다.
- 화면이 이상하면 스크린샷을 함께 첨부합니다 (백 마디 설명보다 강력합니다).
- 짐작 가는 파일·화면이 있으면 'OO 파일/이 부분을 봐 줘'라고 위치를 알려 줍니다.
- AI가 제시한 수정안을 적용합니다. 대개는 내용을 그대로 수락하면 됩니다.
- 한 번에 안 되면 결과를 다시 설명하며 반복합니다. 몇 번의 왕복은 정상입니다.
맥락을 최대한 넘겨라
- 에러 메시지 전문 — 빨간 글씨 전체. 가장 중요한 단서입니다.
- 깨진 화면의 스크린샷 — 무엇이 어떻게 잘못 보이는지.
- 무엇을 하려다 그렇게 됐는지 — '버튼을 눌렀더니', '새로고침했더니'.
- 관련 있어 보이는 파일·부분의 이름 — 범위를 좁혀 줍니다.
나쁜 수정 vs 좋은 수정 — 하드코딩 함정
AI가 문제를 '땜질'로 덮는 대표적인 실수가 있습니다. 예를 들어 두 요소가 겹쳐 보이는 문제를, AI가 특정 크기 숫자를 코드에 콕 박아(하드코딩) 그 화면에서만 안 겹치게 만드는 경우입니다. 이러면 큰 화면·작은 화면·가로·세로로 바뀌는 순간 다시 겹쳐 버립니다. 근본 해결이 아니라 그 순간만 가린 것이죠.
| 구분 | 나쁜 수정(하드코딩) | 좋은 수정(반응형) |
|---|---|---|
| 방식 | 특정 크기 숫자를 고정 | 화면 크기에 맞춰 자동 조정 |
| 결과 | 이 화면에서만 OK | 어떤 화면·방향에서도 OK |
| 다른 화면 | 다시 깨짐 | 안 깨짐 |
프롬프트 — 하드코딩 대신 반응형으로
지금 이 겹침 문제를 특정 크기 숫자를 고정해서(하드코딩) 해결하지 말아 줘.
화면 크기나 방향(가로·세로)이 어떻게 바뀌어도 요소들이 절대 겹치지 않도록,
레이아웃을 화면에 맞춰 자동으로 조정되는 '반응형(responsive)'으로 만들어 줘.디버깅은 한 방에 끝나지 않는 경우가 많습니다. 서너 번 왕복하는 것은 실패가 아니라 정상입니다. 조급해져서 여러 문제를 한꺼번에 쏟아내면 AI가 오히려 헷갈립니다. 한 번에 하나씩, 침착하게 좁혀 가세요.
AI가 같은 자리에서 계속 헤맬 때, 당신이 '파일 구조'를 대충이라도 알고 있으면 판이 바뀝니다. '이건 화면 담당 파일이니 거기 말고, 데이터 담당 부분을 봐 줘'처럼 정확한 위치를 짚어 주면 AI가 단번에 방향을 잡습니다. 그래서 앞 레슨의 '구조' 감각이 여기서 빛을 발합니다.
지금까지 디버깅에서 반복해 강조한 것은 결국 '정보를 충분히 주라'였습니다. 이건 디버깅만의 이야기가 아닙니다. 다음 레슨에서 다섯 번째 손가락 '맥락'을 정면으로 다루고, 지금 내가 '구현 모드'인지 '디버깅 모드'인지 아는 것이 왜 결정적인지, 그리고 왜 항상 MVP부터 시작해야 하는지 배웁니다.