23장. 에러가 나도 당황하지 않는 대화법

개발을 하다 보면 반드시 마주치는 순간이 있습니다. 어제까지 되던 버튼이 갑자기 안 눌리고, 저장이 되는 줄 알았는데 데이터가 안 들어가고, 화면은 멀쩡한데 콘솔은 빨갛게 울부짖는 순간입니다.

초보자는 여기서 흔히 두 가지 반응을 보입니다. 하나는 얼어붙는 것이고, 다른 하나는 다급해지는 것입니다.

"망한 것 같은데요." "갑자기 안 돼요." "뭐가 문제인지 모르겠어요."

마음은 이해됩니다. 그런데 이상하게도, 이런 말만으로는 AI도 제대로 도와주기 어렵습니다. 반대로 코드를 많이 몰라도 문제를 정확히 설명하면, 의외로 아주 빨리 고쳐질 때가 많습니다.

이번 장의 핵심은 단순합니다.

에러를 잘 고치는 사람은 처음부터 원인을 아는 사람이 아니라, 지금 벌어진 일을 분명하게 설명하는 사람입니다.

Claude Code든 Codex든, AI는 마술사가 아닙니다. 하지만 단서가 선명하면 꽤 뛰어난 디버깅 파트너가 됩니다. 에러 메시지, 콘솔 로그, 재현 절차, 내가 기대한 동작과 실제 동작의 차이. 이 네 가지만 정리돼도 대화의 품질이 확 달라집니다.

에러는 실패가 아니라 단서다

처음 개발을 하는 사람에게 에러는 마치 "넌 아직 준비가 안 됐어"라고 말하는 벽처럼 느껴집니다. 하지만 실제로는 반대입니다. 에러는 프로젝트가 말을 걸어오는 방식에 가깝습니다.

물론 그 말투는 전혀 친절하지 않습니다. undefined가 떴다느니, cannot read properties of null이라느니, 모르는 영어로 한참 떠들어댑니다. 그래도 좋은 소식이 하나 있습니다. 에러는 대개 힌트가 있는 문제입니다. 아무 단서 없이 완전히 사라지는 문제가 아니라, 어디선가 흔적을 남깁니다.

그래서 에러를 만났을 때 가장 먼저 해야 할 일은 자책이 아니라 관찰입니다.

지금 깨진 것이 무엇인지, 언제 깨지는지, 어떤 메시지가 뜨는지부터 보는 것입니다.

이 감각이 생기면 개발은 덜 무서워집니다. 에러가 나도 "끝났다"가 아니라 "좋아, 단서가 생겼네"라고 생각할 수 있기 때문입니다.

초보자가 가장 많이 하는 말은 대개 너무 넓다

AI에게 에러를 물어볼 때 초보자가 가장 자주 하는 문장은 이런 형태입니다.

"안 돼요." "에러가 나요." "로그인이 안 됩니다." "저장 버튼이 먹통이에요."

이 말들이 틀린 것은 아닙니다. 다만 너무 넓습니다. 의사가 "어디가 아파요?"라고 물었는데 "그냥 아파요"라고 답하는 것과 비슷합니다. 아픈 건 맞지만, 어디가 어떻게 아픈지 알아야 처방이 가능하겠죠.

개발에서도 똑같습니다. "로그인이 안 된다"는 증상일 뿐입니다. 비밀번호가 틀렸을 때만 안 되는지, 버튼을 눌러도 아무 반응이 없는지, 콘솔에 에러가 뜨는지, 서버 요청은 갔는지, 로그인은 됐는데 다음 화면으로 이동이 안 되는지에 따라 원인은 완전히 달라집니다.

즉, 좋은 디버깅 대화는 막연한 불만에서 시작하지 않고, 관찰된 사실에서 시작합니다.

디버깅 대화에는 네 가지 재료가 필요하다

AI와 에러를 이야기할 때는 아래 네 가지를 준비하면 좋습니다.

• 어떤 행동을 했는가

• 실제로 무슨 일이 일어났는가

• 원래는 어떻게 되길 기대했는가

• 그때 보인 에러 메시지나 로그는 무엇인가

이 네 가지가 있으면, AI는 단순 추측이 아니라 꽤 구체적인 진단을 시작할 수 있습니다.

예를 들어 이런 식입니다.

"글 작성 페이지에서 제목과 내용을 입력하고 저장 버튼을 눌렀어요. 원래는 글 목록으로 이동하면서 새 글이 보여야 합니다. 그런데 아무 이동도 없고, 브라우저 콘솔에는 Failed to fetch가 뜹니다."

이 문장은 초보자가 쓴 것이어도 충분히 좋습니다. 행동, 기대, 실제 결과, 로그가 다 들어 있기 때문입니다.

에러를 설명할 때는 '원인 추측'보다 '증상 기록'이 먼저다

사람은 불안하면 빨리 결론을 내리고 싶어집니다. 그래서 디버깅 대화에서도 이런 말을 자주 합니다.

"아마 Supabase가 문제인 것 같아요." "라우터가 꼬인 것 같아요." "상태 관리가 잘못된 것 같아요."

가능성은 있습니다. 하지만 초보자의 첫 추측은 자주 빗나갑니다. 그리고 문제는, 잘못된 추측을 너무 세게 붙잡으면 AI도 그 방향으로 끌려가기 쉽다는 것입니다.

그래서 처음에는 원인보다 증상을 먼저 정리하는 편이 좋습니다.

예를 들어 이렇게 말하는 쪽이 훨씬 낫습니다.

"원인은 모르겠지만, 저장 버튼을 눌렀을 때 네트워크 요청이 가는지 모르겠고 브라우저 콘솔에는 401 Unauthorized가 뜹니다."

이 문장은 모르는 것을 모른다고 인정하면서도, 필요한 단서는 분명히 줍니다. 디버깅에서는 이런 태도가 강합니다. 괜히 똑똑해 보이려고 추측을 늘어놓기보다, 내가 본 사실을 또렷하게 전달하는 것이 더 중요합니다.

에러 메시지는 무서운 문장이 아니라 주소표다

처음 보는 에러 메시지는 겁이 납니다. 영어도 많고, 코드도 많고, 파일 경로도 길고, 숫자도 잔뜩 붙어 있습니다. 하지만 에러 메시지를 전부 이해할 필요는 없습니다. 초보자에게 필요한 것은 메시지를 해석하는 능력보다, 먼저 쪼개서 보는 습관입니다.

대부분의 에러 메시지에서 먼저 봐야 할 것은 세 가지입니다.

• 어떤 종류의 문제인지

• 어느 파일이나 어느 줄 근처에서 생겼는지

• 무엇을 찾지 못했거나, 무엇을 잘못 다뤘는지

예를 들어 Cannot read properties of undefined가 보인다면, "어떤 값을 읽으려 했는데 그 값이 비어 있구나" 정도만 알아도 첫걸음은 충분합니다. Module not found라면 파일이나 패키지를 못 찾는 상황일 가능성이 높고, 401 Unauthorized라면 권한이나 로그인 문제가 의심됩니다.

즉, 에러 메시지를 사전처럼 완벽히 번역할 필요는 없습니다. 문제의 방향을 알려주는 표지판으로 보면 됩니다.

어디에서 난 에러인지 먼저 구분하자

초보자는 로그를 볼 때 브라우저 콘솔, 터미널, 네트워크 탭이 다 비슷하게 느껴질 수 있습니다. 하지만 어디에 보인 에러인지 구분하면 대화가 훨씬 정확해집니다.

브라우저 콘솔 에러는 대개 화면 쪽, 즉 프론트엔드에서 벌어진 문제를 많이 보여줍니다. 버튼 클릭 후 자바스크립트가 깨졌는지, 컴포넌트 렌더링이 꼬였는지, 클라이언트에서 요청을 보내는 과정에 문제가 있는지 볼 때 자주 등장합니다.

터미널 로그는 서버 실행 과정, 빌드 문제, API 라우트 처리, 환경변수 누락 같은 문제를 더 자주 알려줍니다. 로컬 개발 서버를 켰을 때 뜨는 빨간 글씨는 대개 이쪽입니다.

그리고 네트워크 탭은 아주 실전적입니다. 요청이 실제로 갔는지, 응답 코드가 200인지 401인지 500인지, 응답 데이터가 비어 있는지를 볼 수 있습니다.

초보자가 이 셋을 완벽하게 나눌 필요는 없습니다. 대신 최소한 이렇게는 말할 수 있어야 합니다.

"브라우저 콘솔에 떴어요." "터미널에서 떴어요." "네트워크 탭에서 요청은 갔는데 500이 나와요."

이 차이만 알아도 AI는 훨씬 덜 헤맵니다.

가장 강력한 단서는 '재현 절차'다

디버깅에서 정말 강한 정보는 의외로 화려한 로그가 아닙니다. 바로 재현 절차입니다.

재현 절차는 문제를 다시 발생시키는 순서입니다. 쉽게 말해, "어떻게 하면 이 문제가 또 생기는지"를 적는 것입니다. 이게 왜 중요할까요? 문제를 다시 만들 수 있으면, 고친 뒤에 다시 검증할 수도 있기 때문입니다.

좋은 재현 절차는 길 필요가 없습니다. 짧아도 됩니다. 대신 순서가 분명해야 합니다.

예를 들면 이런 식입니다.

• 로그인된 상태로 글 작성 페이지에 들어간다.

• 제목과 내용 입력 후 저장 버튼을 누른다.

• 버튼 로딩은 잠깐 보이지만 페이지 이동이 일어나지 않는다.

• 브라우저 콘솔에 Failed to fetch가 뜬다.

이 정도만 되어도 아주 좋습니다. 이제 AI는 "무엇을 했더니 무엇이 벌어졌다"를 따라갈 수 있습니다.

반대로 "가끔 저장이 안 돼요"라는 말은 너무 어렵습니다. 가끔이 언제인지, 어떤 순서에서 그런지, 항상 재현되는지 알 수 없기 때문입니다.

기대한 동작과 실제 동작을 나란히 적어라

디버깅 대화에서 자주 빠지는 요소가 하나 있습니다. 바로 내가 원한 결과입니다.

개발자는 문제를 너무 오래 보고 있으면, 원래 무엇을 만들고 있었는지 잊어버릴 때가 있습니다. 그러면 AI도 "무엇을 고치면 해결이라고 볼지" 판단하기 어려워집니다.

그래서 좋은 설명은 늘 이 두 가지가 같이 들어갑니다.

기대한 동작, 그리고 실제 동작.

예를 들어 이런 식입니다.

"기대한 동작은 회원가입 후 자동으로 로그인 화면으로 이동하는 것입니다. 실제로는 버튼을 누르면 아무 반응이 없고 콘솔에 email is required 에러가 뜹니다."

이 문장에는 목표와 문제 사이의 차이가 선명하게 드러납니다. 디버깅은 결국 이 간격을 좁히는 일이기 때문에, 이 정보가 빠지면 대화가 자꾸 헛돌게 됩니다.

스크린샷보다 텍스트 정리가 더 중요할 때가 많다

물론 화면 캡처는 도움이 됩니다. 하지만 초보자가 자주 놓치는 점이 있습니다. 보이는 것만 보내고 설명은 빼먹는 것입니다.

예를 들어 빨간 에러 화면을 캡처해서 보내는 것만으로는 충분하지 않을 수 있습니다. 언제 그 화면이 나왔는지, 어떤 행동 직후였는지, 항상 그런지 가끔 그런지, 직전에 어떤 파일을 바꿨는지까지 있어야 대화가 살아납니다.

그래서 스크린샷은 보조 자료로 생각하고, 핵심은 텍스트로 정리하는 편이 좋습니다.

아주 짧아도 괜찮습니다.

"로그인 버튼 클릭 직후 이 화면이 뜹니다. 새로고침하면 사라지지 않고 계속 유지됩니다. 직전에 handleLogin 함수 이름을 바꿨습니다."

이런 설명은 AI에게 훨씬 큰 힘이 됩니다.

좋은 첫 질문은 길지 않아도 된다

에러가 났을 때 AI에게 처음 보내는 메시지는 거창할 필요가 없습니다. 오히려 아래 순서만 지켜도 훨씬 좋아집니다.

먼저 무엇을 하려 했는지 말합니다. 그다음 실제로 무슨 일이 생겼는지 적습니다. 그다음 에러 메시지나 로그를 붙입니다. 마지막으로 관련 파일이나 최근 변경점을 덧붙입니다.

이 틀로 쓰면 대체로 이런 모양이 됩니다.

"Next.js 글 작성 페이지에서 저장 기능을 붙이는 중입니다. 저장 버튼을 누르면 원래는 Supabase에 글이 저장되고 목록 페이지로 이동해야 합니다. 그런데 아무 이동이 없고 브라우저 콘솔에 Failed to fetch가 뜹니다. 방금 createPost 함수를 lib/posts.ts에 추가한 뒤부터 이 문제가 생겼습니다. 원인 후보를 좁혀서 점검 순서를 제안해 주세요."

보세요. 코드를 길게 몰라도 충분히 좋은 질문이 됩니다.

막히면 '원인 분석'보다 '다음 확인 한 단계'를 요청하라

AI와 디버깅 대화를 하다 보면 이런 순간이 옵니다. 답을 읽어도 어렵고, 가능한 원인이 너무 많아 보여서 더 막막해지는 순간입니다.

이럴 때 초보자가 자주 하는 실수는 다시 이렇게 묻는 것입니다.

"그래서 뭐가 문제죠?"

하지만 디버깅은 한 번에 정답 맞히기 게임이 아닙니다. 좋은 접근은 원인을 전부 다 맞히려 하기보다, 다음 확인 한 단계를 좁혀가는 것입니다.

이럴 때는 이렇게 물으면 좋습니다.

• 가장 가능성 높은 원인 2개만 좁혀 주세요.

• 초보자가 지금 바로 확인할 수 있는 첫 번째 점검만 알려 주세요.

• 코드 수정 없이 먼저 볼 수 있는 부분부터 순서대로 알려 주세요.

• 브라우저 콘솔, 네트워크 탭, 터미널 중 어디를 먼저 봐야 하는지 알려 주세요.

이런 질문은 디버깅을 실전적으로 만듭니다. 머릿속은 덜 복잡해지고, 지금 당장 할 수 있는 행동이 생깁니다.

로그를 더 추가하면 대화가 갑자기 쉬워진다

에러 메시지가 부족할 때가 있습니다. 그럴 때는 AI에게 "로그를 어디에 넣어야 할지"부터 물어보는 것도 좋은 방법입니다.

초보자는 종종 로그를 보는 것은 알지만, 어디에 어떤 로그를 찍어야 하는지 몰라서 막힙니다. 그런데 이건 아주 자연스러운 일입니다. 디버깅은 답을 외우는 일이 아니라, 흐름을 관찰하는 위치를 잡는 일이기 때문입니다.

예를 들어 이렇게 물어볼 수 있습니다.

"저장 버튼 클릭부터 API 호출 직전까지 어느 값이 비어 있는지 확인하고 싶어요. 초보자 기준으로 console.log를 어디에 넣으면 좋을지 알려 주세요."

이 질문은 정말 강합니다. 이제 AI는 추상적인 설명 대신, 실제 코드 흐름에서 관찰 지점을 짚어줄 수 있습니다.

로그를 찍을 때는 욕심내서 모든 값을 다 뿌리기보다, 갈림길이 되는 지점만 보는 편이 좋습니다. 버튼 클릭이 실제로 실행됐는지, 함수 인자가 들어왔는지, 요청 직전 데이터가 맞는지, 응답이 왔는지. 이런 포인트만 잡아도 문제 범위가 빠르게 줄어듭니다.

한 번에 너무 많이 고치지 말고, 하나의 가설만 검증하자

에러가 오래 안 풀리면 마음이 급해집니다. 그래서 이것도 바꾸고 저것도 바꾸고, import도 고치고 함수 이름도 바꾸고 환경변수도 다시 넣고 싶어집니다.

하지만 디버깅에서 이 방식은 자주 상황을 더 흐립니다. 왜냐하면 무엇이 문제였는지 알기 전에 여러 군데를 건드리면, 나중에 "어떤 수정이 실제 해결이었는지" 알 수 없기 때문입니다.

그래서 AI와 대화할 때도 이런 식이 좋습니다.

"가설을 하나씩 검증하고 싶어요. 먼저 환경변수 누락 가능성부터 확인해봅시다." "지금은 요청이 실제로 나가는지만 보겠습니다. 응답 처리 수정은 그다음으로 미루죠."

이 태도는 느려 보이지만 결과적으로 빠릅니다. 원인을 좁혀가며 고치면 다시 같은 문제가 생겼을 때도 훨씬 덜 흔들리기 때문입니다.

실전 예시: 저장 버튼이 안 될 때의 대화

이제 실제로 많이 겪는 상황을 하나 보겠습니다. 글 작성 기능을 붙였는데 저장이 안 되는 경우입니다.

초보자가 자주 하는 질문은 이렇습니다.

"저장 버튼이 안 됩니다. 고쳐 주세요."

이 문장만으로는 정보가 너무 적습니다. 대신 이렇게 바꾸면 훨씬 좋아집니다.

나쁜 질문보다 좋은 질문

"글 작성 페이지에서 제목과 내용을 입력하고 저장 버튼을 누르면 원래는 posts 테이블에 저장된 뒤 목록 페이지로 이동해야 합니다. 그런데 버튼을 눌러도 페이지 이동이 없고, 브라우저 콘솔에는 Failed to fetch가 뜹니다. 터미널에는 별다른 에러가 없습니다. 방금 createPost 함수를 app/posts/new/page.tsx에서 호출하도록 바꾼 뒤부터 생겼습니다. 가장 먼저 확인할 점 3가지를 알려 주세요."

이 질문이 좋은 이유는 분명합니다. 기능, 기대 결과, 실제 결과, 로그 위치, 최근 변경점, 요청 형태가 다 들어 있기 때문입니다.

AI의 답도 훨씬 실용적으로 바뀔 가능성이 큽니다. 예를 들어 네트워크 요청이 실제로 나가는지 확인하라고 하거나, 호출 URL이 잘못됐는지 보라고 하거나, 환경변수가 클라이언트에서 접근 가능한 형태인지 점검하라고 제안할 수 있습니다.

즉, 좋은 질문은 AI를 더 똑똑하게 만드는 것이 아니라, AI가 똑똑하게 답할 수 있게 만드는 것입니다.

재현이 안 되는 문제는 먼저 조건을 찾아야 한다

어떤 문제는 항상 생기지 않습니다. 가끔만 생깁니다. 이럴 때는 더 답답합니다.

하지만 "가끔"이라는 말은 디버깅에 별 도움이 되지 않습니다. 가끔을 더 구체적인 조건으로 바꿔야 합니다.

예를 들어 이렇게 좁혀볼 수 있습니다.

• 로그인 직후에만 생기는가

• 모바일 화면에서만 생기는가

• 첫 클릭 때만 생기는가

• 새로고침 후에는 사라지는가

• 특정 입력값일 때만 생기는가

즉, 재현이 안 되는 문제를 만났을 때는 원인을 맞히기보다 발생 조건을 찾는 탐정 놀이를 하는 편이 좋습니다. AI에게도 이렇게 말해보세요.

"항상 생기지는 않고, 로그인 직후 첫 저장에서만 자주 생깁니다. 이런 조건이면 어디를 의심해야 할까요?"

이렇게 되면 대화가 훨씬 현실적으로 변합니다.

AI가 제안한 수정은 바로 끝으로 보지 말자

AI가 수정안을 제안하고, 실제로 에러가 사라졌다고 합시다. 여기서 끝내고 싶어집니다. 하지만 이 장에서 꼭 기억해야 할 것이 있습니다.

에러가 안 보인다는 것과 문제가 해결됐다는 것은 다를 수 있습니다.

예를 들어 콘솔 에러는 사라졌는데 저장이 여전히 안 될 수도 있습니다. 혹은 저장은 되지만 잘못된 사용자 데이터로 들어갈 수도 있습니다. 에러 메시지를 숨겨서 조용해진 것뿐일 수도 있습니다.

그래서 AI가 "이렇게 고치면 됩니다"라고 했을 때는 꼭 다시 물어보는 습관이 좋습니다.

• 이 수정으로 무엇이 해결되었는지 설명해 주세요.

• 같은 문제가 다시 생기지 않으려면 어떤 조건을 확인해야 하나요?

• 제가 직접 검증할 체크리스트를 짧게 만들어 주세요.

• 이 수정이 다른 기능에 영향을 줄 수 있는 곳이 있나요?

이 질문들은 해결을 더 단단하게 만듭니다.

감정 대신 사실로 말하면 대화가 빨라진다

디버깅이 길어지면 마음이 흔들립니다. 그래서 "계속 안 돼요", "진짜 미치겠어요", "왜 자꾸 이래요" 같은 말이 튀어나오기도 합니다. 이해됩니다. 개발은 정말 그런 순간이 있습니다.

하지만 AI와의 대화에서는 감정 표현보다 사실 정리가 훨씬 강합니다.

예를 들어 이렇게 바꾸는 것입니다.

"세 번째 시도까지 같은 에러가 납니다." "제안한 수정 후에도 브라우저 콘솔 메시지는 바뀌지 않았습니다." "이번에는 500 에러는 사라졌지만, 저장 후 이동이 여전히 일어나지 않습니다."

이런 문장은 차갑게 보일 수 있지만, 실제로는 문제 해결에 훨씬 따뜻합니다. 다음 행동을 결정할 수 있게 해주기 때문입니다.

초보자에게 특히 유용한 디버깅 질문들

아래 질문들은 막힐 때 거의 만능처럼 쓸 수 있습니다.

• 지금 정보만으로 가장 가능성 높은 원인 2가지를 좁혀 주세요.

• 원인을 바로 고치지 말고, 먼저 확인할 순서를 알려 주세요.

• 제가 초보자라서 코드를 다 이해하지 못합니다. 어디 로그를 보면 되는지부터 알려 주세요.

• 이 에러 메시지에서 제가 읽어야 할 핵심 부분만 쉬운 말로 설명해 주세요.

• 수정 전에 재현 절차와 검증 절차를 먼저 정리해 주세요.

• 이 문제를 프론트엔드, 백엔드, 데이터베이스 중 어느 쪽에서 먼저 의심해야 할지 알려 주세요.

이 질문들의 공통점은 단순합니다. 막연한 구조 개선이 아니라, 지금 눈앞의 문제를 풀기 위한 다음 한 걸음을 요청한다는 점입니다.

디버깅 대화 템플릿

막힐 때마다 매번 새로 생각하려 하면 더 힘듭니다. 그래서 아래 템플릿을 복붙해서 상황에 맞게 바꿔 쓰면 좋습니다.

기본 템플릿

무엇을 하려 했는지:

기대한 동작:

실제 동작:

에러 메시지 또는 로그:

에러가 보인 위치: 브라우저 콘솔 / 터미널 / 네트워크 탭

재현 절차:

직전에 바꾼 파일 또는 코드:

원인 추측이 아니라, 먼저 확인할 순서를 알려 주세요.

이 템플릿은 단순하지만 강력합니다. 초보자일수록 감에 기대지 않고 형식에 기대는 편이 좋습니다. 형식이 있으면 당황한 상태에서도 중요한 정보를 놓치지 않게 됩니다.

짧은 실전 대화 예시

아래처럼 대화를 시작하면 흐름이 꽤 안정적입니다.

사용자: 글 수정 페이지에서 저장 버튼을 누르면 원래는 수정이 반영되고 상세 페이지로 이동해야 합니다. 그런데 버튼을 누르면 아무 반응이 없고, 브라우저 콘솔에 Unexpected token < in JSON 에러가 뜹니다. 네트워크 탭에서는 요청이 500으로 보입니다. 방금 API 응답 형식을 바꾼 뒤부터 생겼습니다. 먼저 어디를 확인해야 할까요?

AI: 좋습니다. 우선 세 가지를 확인해봅시다. 첫째, API가 JSON이 아니라 HTML 에러 페이지를 반환하는지 확인하세요. 둘째, 프론트엔드에서 response.json()을 호출하기 전에 응답 상태 코드를 확인하고 있는지 보세요. 셋째, 서버 쪽 터미널 로그에서 500 에러 원문을 확인하세요.

사용자: 터미널을 보니 column updated_at does not exist가 나옵니다. 이 경우 다음엔 무엇을 보면 좋을까요?

AI: 좋습니다. 이제 원인이 많이 좁혀졌습니다. 데이터베이스 컬럼명과 코드에서 사용하는 필드명이 다를 가능성이 큽니다. 수정 전에는 posts 테이블 스키마와 업데이트 쿼리에서 어떤 필드를 보내는지 먼저 비교해보세요.

이 예시에서 중요한 것은 정답 그 자체보다 흐름입니다. 한 번에 다 해결하려 하지 않고, 새 단서가 생길 때마다 범위를 좁혀가고 있습니다.

고친 뒤에는 반드시 '같은 방법으로' 다시 확인하자

문제를 고쳤다면, 처음에 적어둔 재현 절차로 다시 테스트해야 합니다. 이것이 정말 중요합니다.

왜냐하면 개발자는 고친 뒤에 기분이 좋아져서 대충 넘어가기 쉽기 때문입니다. 하지만 디버깅의 진짜 마침표는 "수정했다"가 아니라 "같은 조건에서 다시 해봤더니 해결됐다"입니다.

처음에 이렇게 적어두었다면,

• 글 작성 페이지 진입

• 제목과 내용 입력

• 저장 버튼 클릭

• 목록 페이지 이동 확인

고친 뒤에도 똑같이 이 순서로 다시 해봐야 합니다. 그리고 가능하면 실패 상황도 함께 봐야 합니다. 빈 제목일 때는 어떻게 되는지, 로그인되지 않은 상태에서는 어떤 반응인지까지 짧게 확인하면 더 좋습니다.

디버깅은 실력 시험이 아니라 관찰 훈련이다

이 장을 읽고 나면, 개발을 잘하는 사람은 원래부터 에러를 무서워하지 않는 사람처럼 보일 수도 있습니다. 하지만 사실은 조금 다릅니다.

익숙한 사람도 에러는 여전히 짜증납니다. 다만 다른 점이 있다면, 당황하는 시간을 줄이고 관찰하는 시간을 늘린다는 것입니다. 무엇을 했는지, 어디서 깨졌는지, 어떤 로그가 있는지, 재현이 되는지. 이런 것들을 차분히 모아갑니다.

초보자도 이 훈련은 충분히 할 수 있습니다. 아니, 오히려 지금부터 이 습관을 들이면 훨씬 유리합니다. 개발을 잘하게 되는 과정은 화려한 문법을 외우는 것보다, 문제를 다루는 태도를 몸에 익히는 것과 더 가까울 때가 많기 때문입니다.

이번 장의 핵심 문장

에러 앞에서 중요한 것은 빨리 똑똑해 보이는 것이 아니라, 지금 벌어진 일을 정확히 말하는 것입니다.

에러 메시지를 읽고, 콘솔 로그를 구분하고, 재현 절차를 적고, 기대한 동작과 실제 동작의 차이를 말할 수 있으면 초보자도 디버깅 대화를 훨씬 잘 이끌 수 있습니다. 그러면 AI는 막연한 위로가 아니라, 실제로 문제를 좁혀가는 파트너가 됩니다.

개발에서 무서운 사람은 에러를 안 만나는 사람이 아닙니다.

에러가 나도 "잠깐, 무슨 일이 일어났는지부터 정리해보자"라고 말할 수 있는 사람입니다.

다음 장부터는 이제 본격적으로 화면을 만들기 시작합니다. 그리고 그 과정에서도 분명 작은 에러들이 계속 나올 것입니다. 하지만 이제는 알게 되었습니다. 에러는 나를 멈추게 하는 벽이 아니라, 다음 질문을 던지게 만드는 단서라는 것을.