만들기배포

에러 메시지로 AI와 디버깅하기 — 요약하지 말고 통째로

오일기 · 한국이러닝인재개발원 원장 · 2026-09-23

빨간 글씨는 협박문이 아니라 "여기가 문제"라는 안내문입니다. 어디서 보이고, 뭘 가져가고, 어떻게 시키는지. 오류 설명 공식 네 칸.

온라인으로 배우다 포기하는 지점은 대부분 첫 번째 에러입니다. 영어로 된 빨간 글씨가 뜨면 "나는 안 되나 보다" 하고 닫습니다. 그런데 에러 메시지는 협박문이 아니라 "여기가 문제"라는 안내문입니다. 영어라서 못 읽어도 됩니다. 읽는 건 AI가 하고, 우리는 통째로 전달하고 결과를 확인합니다.

세 군데만 봅니다

• ① Error·failed·not found 같은 단어가 있는 줄 — 무슨 문제인지
• ② 파일 이름과 줄 번호 (예: index.html:42) — 어디서 났는지
• ③ 방금 내가 한 행동 — 무엇을 눌렀더니·무엇을 시켰더니

나머지 긴 글은 몰라도 됩니다. 그리고 요약하지 말고 통째로 복사. 내가 요약하면 중요한 단서가 빠집니다. 전부 복사가 가장 빠른 길입니다.

오류가 보이는 곳 네 군데

브라우저에서 F12 → Console 탭의 빨간 줄도 통째로 가져가면 좋습니다. 메시지가 없는 "화면 문제"는 캡처가 유일한 증거입니다.

오류 설명 공식 — 네 칸

[어디서] Vercel 배포에서
[무엇을 했더니] GitHub에 올리고 나서
[무슨 일이] 배포가 실패로 떴어.
[기대한 것] 새 버전이 공개돼야 해.
아래가 오류 메시지 전체야:
(여기에 통째로 붙여넣기)
원인을 쉬운 말로 먼저 설명하고,
네가 찾아서 고친 다음, 되는지 확인까지 해줘.

네 칸만 채우면 AI가 헤매지 않습니다. 화면 없이 말로만 물으면 답도 추측이 됩니다.

찾아 고치게 하는 3단계

1. 붙여넣기 — 오류 전체 + 상황 한 줄 → "원인 설명하고 고쳐줘"
2. 확인까지 시키기 — "고친 뒤 네가 직접 확인하고 결과를 보고해줘"
3. 세 번 고쳐도 같으면 — "이 방법은 막혔어. 다른 방법으로. 요구사항은 그대로"

AI가 "고쳤다"고 말하는 것과 실제로 되는 것은 다릅니다. 열어 보기 전에는 믿지 않습니다. 같은 자리를 네 번째 파는 것보다 '다른 방법으로'가 보통 빠릅니다.

로그를 남겨 두면 다음이 쉽습니다

배포한 서비스에서 문제가 생겼는데 화면에 아무 메시지가 없으면 막막합니다. 만들 때 이렇게 한 줄 붙여 두세요. "오류가 나면 언제·어디서·무엇을 하다가 났는지 콘솔에 기록해줘." 나중에 F12 → Console에서 그 기록을 복사해 붙이면 됩니다. 기록이 없으면 추측이고, 있으면 사실입니다.

대화가 꼬였을 때

같은 문제를 두 번 넘게 고쳤는데 계속 이상하면 대화에 실패한 시도가 쌓인 것입니다. 둘 중 하나입니다.

• 되감기 — "마지막으로 잘 되던 상태로 되돌려줘". 무엇이 사라지는지 먼저 설명받기
• 새 대화 — 배운 것을 넣어 더 나은 첫 요청으로. 폴더의 파일과 CLAUDE.md는 그대로

일부러 한 번 겪어 두기

진짜 오류가 오기 전에 연습합니다. "연습용으로 상담 신청 버튼 연결을 일부러 망가뜨려줘. 어떻게 했는지는 말하지 말고." 버튼이 안 되는 걸 확인하고, 공식대로 설명하고, 고치게 합니다. 한 번 겪어 두면 진짜가 와도 손이 먼저 움직입니다.

5분 넘게 혼자 씨름하지 않습니다. 통째로 복사 → 설명 → 고치게 → 내가 확인. 이 순서가 전부입니다.

같이 읽기

• 내 업무에서 바이브코딩 프로젝트 아이디어 찾는 법"만들고 싶은 게 없다"는 분이 절반입니다. 신기한 것 말고 귀찮은 것을 찾습니다. 질문 네 개와 기준 세 가지.만들기
• 바이브코딩 프로젝트가 중간에 멈추는 이유 — 그리고 욕심 신호 네 가지AI가 못 만들어서가 아닙니다. 처음부터 너무 많이 만들고 있어서입니다. 멈추는 패턴과, 첫 버전에서 일부러 빼야 할 것.만들기
• 기능은 얼마나 작게 잘라서 시켜야 하나한 번에 하나. 확인할 수 있는 크기. "현상 + 기대"로 고치고, "추가할 것·누르면·지킬 것" 세 줄로 붙입니다.만들기