기능을 새로 붙일 때보다 더 자주 찾아오는 순간이 있습니다. 화면은 어딘가 이상하고, 버튼은 눌리는 것 같기도 한데 결과가 다르고, 콘솔에는 에러가 뜰 때도 있고 안 뜰 때도 있는 순간입니다. 이때 초보자가 가장 쉽게 하는 말은 보통 비슷합니다. “왜 안 돼요?”

문제는 그 질문이 틀렸다는 데 있지 않습니다. 너무 자연스러운 질문이기 때문입니다. 다만 디버깅에서는 그 한마디만으로는 범위가 너무 넓습니다. 같은 “안 된다”는 말 안에도 클릭 이벤트가 안 붙은 경우, 상태값은 바뀌는데 화면만 안 바뀌는 경우, 필터나 검색 같은 조건이 겹치면서 결과가 이상해지는 경우, 아예 다른 파일에서 터지는 경우까지 섞여 있기 때문입니다.

이번 편에서는 바로 그 지점을 정리해보겠습니다. 핵심은 디버깅을 잘한다는 게 어려운 용어를 많이 아는 것이 아니라, 문제를 재현 가능한 형태로 좁히고, AI가 어디부터 확인해야 할지 따라갈 수 있게 질문을 정리하는 것이라는 점입니다. 이 감각이 붙기 시작하면, 막힐 때마다 무작정 전체 코드를 다시 받는 흐름에서 조금씩 벗어날 수 있습니다.

이번 글에서 먼저 잡아둘 핵심
내가 보는 문제 디버깅 질문으로 바꾸면 가장 먼저 확인할 것
버튼이 안 된다 어느 버튼인지, 클릭 후 무엇이 기대와 다른지, 콘솔 에러가 있는지 선택자, 이벤트 연결, 비활성 상태 여부
검색이 이상하다 어떤 필터 상태에서, 어떤 검색어로, 어떤 결과가 보여야 하는지 재현 순서와 상태값 흐름
에러가 난다 에러 원문, 파일명, 줄 번호, 언제 뜨는지 최근에 바꾼 코드와 발생 시점

이번 글의 핵심 한 줄
좋은 디버깅 질문은 “왜 안 되죠?”에서 멈추지 않고, “어떤 상태에서 무엇을 했을 때 기대와 다르게 어떻게 보였는가”까지 같이 넘기는 질문입니다.

왜 디버깅 질문이 따로 중요한가

기능 요청과 디버깅 요청은 겉으로 비슷해 보여도 성격이 다릅니다. 기능 요청은 “무엇을 만들 것인가”를 중심으로 움직입니다. 반면 디버깅 요청은 지금 무엇이 어긋났는가를 좁혀가는 과정입니다. 그래서 질문 방식도 달라져야 합니다.

예를 들어 “검색 기능 추가해줘”는 만들고 싶은 결과가 중심인 요청입니다. 하지만 “검색어를 입력하면 목록이 줄어들어야 하는데 전체 목록이 그대로 보인다”는 디버깅 요청입니다. 앞쪽은 구현 범위를 정하는 말이고, 뒤쪽은 이미 있는 흐름 안에서 어떤 연결이 빠졌는지 찾는 말입니다.

  • 기능 요청은 결과를 앞으로 끌어오는 질문입니다.
  • 디버깅 요청은 현재 어긋난 지점을 뒤에서 좁혀가는 질문입니다.
  • 그래서 디버깅에서는 전체 코드보다 재현 순서와 현재 상태가 더 중요할 때가 많습니다.
  • 무엇을 새로 만들지보다, 어느 부분이 기대와 다르게 움직였는지가 더 중요합니다.

초보자가 디버깅에서 특히 막히는 이유도 여기 있습니다. 기능을 추가할 때는 어느 정도 감으로도 갈 수 있지만, 디버깅은 감으로 설명하면 범위가 너무 넓어집니다. “이상하다”, “뭔가 꼬였다”, “분명 방금까지 됐는데 안 된다” 같은 표현은 실제로 맞는 말이지만, AI가 바로 다루기에는 아직 정보가 부족합니다.

핵심 포인트
디버깅 질문의 목적은 답을 빨리 받는 데만 있지 않습니다. 문제를 작게 잘라서, 내가 지금 무엇부터 확인해야 하는지 보이게 만드는 데 더 가깝습니다.

이번 편에서는 어디까지 다룰 것인가

이번 글에서는 디버깅 요청의 기본을 다룹니다. 즉, 막혔을 때 AI에게 어떤 정보를 어떤 순서로 넘기면 좋은지, 그리고 질문을 어떻게 좁혀야 하는지를 중심으로 보겠습니다.

이번 편에서 다룰 내용은 아래와 같습니다.

  • 문제를 “증상”에서 “재현 가능한 질문”으로 바꾸는 법
  • 에러가 있을 때와 없을 때 각각 무엇을 보여줘야 하는지
  • 현재 상태와 재현 순서를 함께 정리하는 법
  • AI에게 원인 추정, 확인 순서, 최소 수정안을 요청하는 방법

반대로 이번 글에서는 아래 내용은 깊게 다루지 않겠습니다.

  • 브라우저 개발자 도구의 세부 기능 설명
  • 네트워크 요청 분석
  • 복잡한 프레임워크 전용 디버깅 방식
  • 서버 로그와 배포 환경 문제

지금 단계에서 중요한 것은 디버깅 툴을 많이 아는 일이 아닙니다. 지금 보이는 문제를 말로 정리해서 AI가 따라갈 수 있게 만드는 구조를 익히는 편이 먼저입니다. 그 기본이 잡혀야, 나중에 도구를 더 배워도 훨씬 덜 흔들립니다.

디버깅 질문은 이 순서로 정리하면 된다

디버깅 요청은 길게 쓰는 것보다 순서 있게 쓰는 것이 중요합니다. 초보자라면 아래 여섯 가지를 순서대로 적는 습관만 들여도 훨씬 좋아집니다.

디버깅 질문을 정리할 때 기본 순서
순서 무엇을 적나 왜 필요한가
1 현재 작업과 정상 동작하는 범위 이미 되는 기능을 AI가 다시 설명하지 않게 해준다
2 현재 문제를 한두 문장으로 요약 이번 질문의 초점을 잡아준다
3 재현 순서 같은 문제를 다시 일으키는 방법을 분명히 한다
4 기대한 결과와 실제 결과 무엇이 어긋났는지 정확히 보이게 한다
5 관련 코드와 에러 메시지 추정이 아니라 실제 단서를 보고 답하게 만든다
6 원하는 답변 방식 전체 재작성 대신 원인 분석과 최소 수정으로 답을 좁힐 수 있다

1. 현재 작업과 정상 동작 범위를 먼저 적는다

예를 들어 “할 일 앱에서 추가, 삭제, 완료 체크, 필터까지는 정상 동작하고, 오늘은 검색 기능을 붙이는 중”이라고 먼저 써두면 좋습니다. 이 한 줄만 있어도 AI는 이미 동작하는 부분을 처음부터 다시 설명할 가능성이 줄어듭니다.

2. 현재 문제를 짧게 요약한다

문제 설명은 길어질수록 좋은 게 아니라, 현재 증상을 한 줄로 붙잡아두는 것이 중요합니다. “검색어를 입력해도 목록이 줄어들지 않는다”, “삭제 후 summary 문구가 갱신되지 않는다” 같은 식이면 충분합니다.

3. 재현 순서를 적는다

재현 순서는 디버깅에서 가장 자주 빠지는 정보입니다. 같은 문제를 다시 만들 수 있는 순서를 적어두면, AI도 어떤 흐름에서 상태가 꼬였는지 더 좁혀갈 수 있습니다.

[재현 순서]

완료 보기 필터를 누른다

검색창에 "회의"를 입력한다

보이는 항목의 삭제 버튼을 누른다

4. 기대한 결과와 실제 결과를 나눠 쓴다

디버깅에서 정말 중요한 포인트입니다. “이상하다”보다 “원래는 이렇게 되어야 하는데 실제로는 이렇게 보인다”가 훨씬 좋습니다. 이 차이가 있어야 AI도 무엇이 빠졌는지 정확히 볼 수 있습니다.

5. 관련 코드와 에러 메시지를 붙인다

코드를 전부 던지는 대신 문제와 연결된 부분을 먼저 붙이는 편이 좋습니다. 그리고 에러가 있다면, 내 말로 요약하지 말고 원문 그대로 넣는 것이 낫습니다. 줄 번호와 함수 이름은 생각보다 큰 힌트가 됩니다.

6. 원하는 답변 방식까지 적는다

이 부분도 의외로 중요합니다. 초보자에게는 전체 구조를 싹 다시 짜는 답보다, 가장 가능성 큰 원인 몇 개와 확인 순서, 최소 수정 코드가 더 도움이 되는 경우가 많기 때문입니다.

핵심 정리
디버깅 질문은 “문제 설명”이 아니라 “문제 재현 문서”에 가깝게 정리할수록 답이 더 좋아집니다.

할 일 앱 예시로 보는 디버깅 요청

이제 실제 예시로 보겠습니다. 가정은 이렇습니다. 검색 기능은 이미 붙였는데, 완료 보기 상태에서 검색 후 항목을 삭제하면 목록은 비는데 summary 문구가 그대로 남아 있는 상황입니다. 초보자라면 보통 “삭제는 되는데 뭔가 화면이 이상해요”라고 말하기 쉽습니다. 하지만 디버깅 요청으로는 조금 더 정리할 수 있습니다.

[현재 작업]

HTML, CSS, JavaScript로 할 일 앱을 만드는 중

추가, 삭제, 완료 체크, 전체 삭제, 필터, 검색 기능까지 들어간 상태

오늘은 검색과 필터가 같이 동작하는 부분을 점검 중

[현재 문제]

완료 보기 상태에서 검색 후 마지막 항목을 삭제하면
목록은 비는데 summary 문구가 바로 갱신되지 않음

[재현 순서]

완료 보기 필터를 누른다

검색창에 "회의"를 입력한다

검색 결과로 보이는 마지막 항목을 삭제한다

[기대한 결과]

목록이 비면 summary가 0개로 바뀌어야 함

빈 상태 메시지도 같이 보여야 함

[실제 결과]

목록은 비어 있는데 summary 문구는 이전 숫자가 남아 있음

빈 상태 메시지도 바로 바뀌지 않음

[에러 메시지]

콘솔 에러 없음

[관련 코드]

updateSummary()

getFilteredTodos()

renderTodos()

createDeleteButton() 안에서 renderTodos를 다시 호출하는 부분

[원하는 답변]

가장 가능성 큰 원인 3개

먼저 어떤 함수 흐름을 확인하면 좋을지

전체 재작성 없이 필요한 수정 포인트만 제안

이 질문이 좋은 이유는 분명합니다. 증상만 던진 것이 아니라, 어떤 상태에서 어떤 순서로 문제가 보이는지, 에러가 없는지, 어느 함수가 관련 있는지까지 같이 줬기 때문입니다. 이렇게 되면 AI도 “삭제 기능을 처음부터 다시 만들까?”가 아니라, “삭제 후 summary 갱신 흐름에서 어떤 업데이트가 빠졌을까?”로 사고를 좁히게 됩니다.

반대로 아래처럼 물으면 답이 훨씬 퍼질 수 있습니다.

삭제가 되긴 되는데 뭔가 이상해.

검색 기능 넣은 뒤부터 화면이 잘 안 맞아.
왜 그런지 고쳐줘.

이 문장은 틀린 말은 아니지만, 디버깅에는 아직 범위가 너무 넓습니다. 검색이 문제인지, 삭제가 문제인지, 화면 렌더링이 문제인지, summary 업데이트가 문제인지 AI가 다시 넓게 추정해야 하기 때문입니다.

AI에게는 이렇게 단계별로 물어보면 된다

디버깅 요청은 한 번에 해결책만 받으려 하기보다, 원인 추정 → 확인 순서 → 최소 수정으로 나눠서 물어보는 편이 좋습니다. 특히 초보자에게는 이 방식이 훨씬 배우기 좋습니다.

1. 먼저 원인 후보를 좁혀달라고 요청하기

처음부터 바로 코드를 다시 써달라고 하지 말고, 어떤 가능성이 큰지 먼저 묻는 방식입니다. 이 단계가 있으면 문제를 보는 눈이 조금씩 붙기 시작합니다.

아래 증상을 보고 가장 가능성 큰 원인 3개만 먼저 좁혀줘.

완료 보기 상태에서 검색 후 마지막 항목 삭제

목록은 비지만 summary 숫자는 그대로 남음

콘솔 에러 없음

관련 흐름은 renderTodos, updateSummary, getFilteredTodos야.
전체 수정 코드는 아직 주지 말고,
먼저 어디를 의심하면 좋은지 설명해줘.

2. 다음에는 확인 순서를 요청하기

원인 후보를 들은 뒤에는 무엇부터 확인해야 하는지 순서를 요청하면 좋습니다. 디버깅은 특히 순서가 중요합니다. 무작정 코드를 여러 군데 건드리기 시작하면 오히려 더 헷갈릴 수 있기 때문입니다.

좋아. 그럼 이 문제를 초보자 기준으로 어떤 순서로 확인하면 좋은지 알려줘.

어떤 함수부터 볼지

각 함수에서 어떤 값이 달라져야 하는지

콘솔로 찍어보면 좋은 값이 있다면 무엇인지

답변은 체크리스트처럼 짧게 정리해줘.

3. 그다음 최소 수정 코드만 요청하기

원인과 확인 순서가 잡히면, 그때 필요한 수정만 받는 편이 좋습니다. 전체를 다시 받는 것보다 지금 코드 위에 이어서 수정할 수 있기 때문입니다.

이제 최소 수정으로 고쳐줘.

조건은 아래와 같아.

현재 구조는 유지할 것

함수 이름은 가능하면 유지할 것

summary 갱신과 빈 상태 메시지 문제만 수정할 것

전체 코드 재작성은 하지 말 것

바뀌는 함수만 보여주고,
왜 그 수정이 필요한지도 한 문단으로 설명해줘.

4. 마지막에는 테스트 순서까지 요청하기

디버깅은 수정으로 끝나지 않습니다. 방금 고친 부분이 실제로 해결됐는지, 그리고 다른 기능은 안 깨졌는지도 같이 확인해야 합니다. 그래서 테스트 순서를 요청하는 습관이 좋습니다.

마지막으로 내가 직접 눌러볼 테스트 순서를 5단계 안으로 정리해줘.

특히 아래를 포함해줘.

완료 보기에서 검색 후 삭제

전체 보기에서 검색 후 삭제

검색어를 지운 뒤 summary가 정상인지

기존 추가, 삭제, 필터 기능이 유지되는지

이 흐름의 장점은 분명합니다. AI가 준 답을 한 번에 믿고 통째로 적용하는 방식보다, 문제를 좁히고 확인하고 수정하고 다시 점검하는 과정을 내 쪽에서도 같이 따라갈 수 있게 됩니다. 입문자에게는 이 흐름이 훨씬 중요합니다.

핵심 포인트
디버깅에서 좋은 질문은 “정답 코드”를 바로 얻는 질문이 아니라, 원인을 좁히고 수정 범위를 작게 유지하게 도와주는 질문입니다.

자주 하는 실수와 디버깅 체크리스트

디버깅 요청에서 초보자가 자주 하는 실수는 몇 가지 패턴으로 모입니다. 이 부분만 조심해도 AI 답변의 품질이 꽤 달라집니다.

디버깅 질문에서 자주 하는 실수
실수 왜 문제가 되나 어떻게 바꾸면 좋은가
“왜 안 돼요?”만 적는다 증상 범위가 너무 넓어서 AI가 추정을 많이 하게 된다 재현 순서, 기대 결과, 실제 결과를 같이 적는다
에러를 내 말로 요약한다 줄 번호, 함수 이름, 정확한 원문 정보가 빠질 수 있다 에러 메시지는 복사해서 그대로 붙인다
전체 코드를 무조건 다시 달라고 한다 문제가 더 커지고 기존 맥락도 흐려질 수 있다 원인 후보, 확인 순서, 최소 수정부터 요청한다
관련 없는 코드까지 한꺼번에 붙인다 문제와 관계없는 정보가 섞여 초점이 흐려진다 문제와 연결된 함수와 요소부터 먼저 보여준다
수정 후 테스트를 안 한다 고친 줄 알았는데 다른 기능이 같이 깨질 수 있다 테스트 순서를 같이 받아서 바로 확인한다

실제로는 아래 체크리스트만 기억해도 꽤 도움이 됩니다.

  • 현재 작업과 정상 동작 범위를 먼저 적었는가
  • 문제를 한 줄로 요약했는가
  • 재현 순서를 적었는가
  • 기대한 결과와 실제 결과를 나눠 적었는가
  • 에러가 있으면 원문 그대로 붙였는가
  • 관련 코드만 먼저 골라서 보여줬는가
  • 원인 분석, 확인 순서, 최소 수정 순서로 요청했는가
  • 수정 뒤 테스트 항목도 같이 확인했는가

이 체크리스트는 거창해 보일 수 있지만, 실제로는 디버깅 질문을 조금 더 선명하게 만들기 위한 최소한의 틀에 가깝습니다. 한두 번 익숙해지기 시작하면, 막혔을 때도 훨씬 덜 당황하게 됩니다.

마무리

이번 편까지 오면, 이 기초 연재의 흐름이 꽤 또렷해집니다. AI에게 어떤 역할로 답하게 할지 정했고, 좋은 요청의 기본 구조를 잡았고, 큰 작업을 작은 단계로 나누는 법을 봤고, 현재 상태를 넘기는 법과 AI가 준 코드를 검토하고 다시 요청하는 법까지 정리했습니다. 그리고 이번 편에서는 그 모든 흐름이 실제로 가장 많이 모이는 지점인 디버깅 질문의 기본을 다뤘습니다.

입문자에게 중요한 것은 AI가 한 번에 완벽한 답을 주느냐가 아닙니다. 내가 지금 무엇이 문제인지 좁혀서 묻고, 답을 확인하고, 다시 수정 요청으로 이어갈 수 있느냐가 더 중요합니다. 이 감각이 생기면, 바이브 코딩은 막연히 운에 기대는 방식이 아니라 점점 다룰 수 있는 작업처럼 보이기 시작합니다.


이제는 기초편 다음 단계로 자주 쓰는 프롬프트 템플릿 모음이나 대화 맥락 관리와 반복 지침 정리법 같은 확장편으로 찾아뵙겠습니다.

'바이브코딩 > 기초' 카테고리의 다른 글

[번외-1] 매번 다시 설명하지 마세요: 대화 맥락 관리와 반복 지침 정리법  (0) 2026.04.28
[번외-0] 매번 처음부터 쓰지 마세요: 바이브 코딩에 바로 쓰는 프롬프트 템플릿 모음  (0) 2026.04.21
[기초-4] 돌아간다고 끝은 아니다: AI 코드 검토와 다시 요청하는 법  (0) 2026.04.07
[기초-3] AI가 엉뚱하게 답하는 이유: 코드·에러·화면 상태를 제대로 전달하는 법  (0) 2026.03.31
[기초-2] 한 번에 다 시키지 마세요: 바이브 코딩에서 큰 요청을 잘게 나누는 법  (0) 2026.03.24