바이브코딩 6편: 오류가 났을 때 어디부터 봐야 할까 ::REFUGE HUB

바이브코딩을 조금만 해보면 꼭 한 번은 이런 순간이 옵니다. 버튼을 눌렀는데 아무 일도 안 일어나고, 분명 AI가 고쳐준 코드 같은데 화면은 그대로고, 브라우저를 보니 영어 오류 문장이 뜹니다. 이때 초보자는 보통 두 가지 반응 중 하나를 보입니다. 하나는 "내가 뭘 잘못 건드렸나 보다" 하고 얼어붙는 반응이고, 다른 하나는 AI에게 다시 "안 돼, 다시 고쳐줘"를 반복하는 반응입니다.

그런데 오류를 다루는 데 정말 필요한 건 겁먹지 않는 태도보다 보는 순서입니다. 어디부터 봐야 하는지만 정해져 있어도, 막연한 불안이 훨씬 줄어듭니다. 오류 문장을 처음부터 완벽하게 해석할 필요도 없습니다. 지금 단계에서는 어디서 문제가 보이는지, 어떤 파일을 먼저 의심해야 하는지, AI에게 어떻게 질문해야 하는지만 잡혀도 충분합니다.

이번 글에서는 지난 실습 흐름을 이어서, HTML/CSS/JavaScript로 만든 작은 페이지에서 오류가 났을 때 브라우저 화면 -> 브라우저 콘솔 -> VS Code -> Codex 순서로 어떻게 확인하면 좋은지 정리해보겠습니다. 이번 버전에서는 설명만 하지 않고, 직접 따라치면서 console.log()를 익힐 수 있는 짧은 실습까지 넣겠습니다.

이번 글에서 먼저 잡아둘 핵심
초보자가 자주 하는 반응	더 좋은 첫 반응	왜 이쪽이 낫나
코드를 다시 전부 갈아엎는다	증상부터 한 줄로 적고 확인 순서를 좁힌다	원인과 새 문제를 섞지 않게 됩니다
콘솔 메시지가 무서워서 그냥 닫아버린다	핵심 단어만 읽고 어느 파일을 먼저 볼지 정한다	오류 문장을 전부 번역하지 않아도 방향은 잡을 수 있습니다
console.log()를 아무 데나 많이 찍는다	이벤트, 입력값, 최종 결과 순서로 최소한만 찍는다	로그가 시끄러워지지 않고 흐름이 보입니다

이번 글의 핵심 한 줄
오류를 잘 본다는 건 영어 메시지를 완벽하게 해석하는 일이 아니라, 지금 무엇이 안 되는지 좁혀가면서 브라우저 화면, 콘솔, VS Code, Codex 순서로 단서를 모으는 일에 가깝습니다.

오류가 났을 때 먼저 해야 할 일

오류가 뜨면 바로 고치고 싶어집니다. 그런데 초보자일수록 이때 한 박자만 늦추는 편이 좋습니다. 바로 수정부터 들어가면 원인을 보기도 전에 여러 줄을 한꺼번에 건드리게 되고, 그러면 원래 문제와 새로 만든 문제가 섞이기 쉽습니다.

먼저 해야 할 일은 아주 단순합니다. 지금 무슨 행동을 했을 때, 어떤 문제가 생겼는지 한 줄로 적는 것입니다. 예를 들면 이런 식입니다.

버튼을 눌렀는데 미리보기 문구가 바뀌지 않는다.
페이지를 열자마자 아무 반응이 없고 콘솔에 빨간 오류가 뜬다.
입력은 되는데, 상태 문구만 이상하게 남아 있다.

이 한 줄 정리가 왜 중요하냐면, 여기서부터 "화면 구조 문제인지", "스타일 문제인지", "JavaScript 동작 문제인지"를 조금씩 나눠볼 수 있기 때문입니다. 실제로 초보자가 많이 헤매는 이유는 코드를 몰라서가 아니라, 문제를 너무 크게 한 덩어리로 보기 때문인 경우가 많습니다.

그리고 지금 단계에서는 오류를 크게 두 부류로만 나눠도 충분합니다.

문법 오류 : 코드 자체가 잘못 써져서 아예 실행이 막히는 경우
동작 오류 : 실행은 되지만 결과가 기대와 다르게 나오는 경우

문법 오류는 보통 콘솔이나 에디터에서 비교적 빨리 잡히고, 동작 오류는 console.log()나 작은 테스트로 흐름을 확인하면서 찾는 경우가 많습니다. 이 차이만 알아도 처음 오류를 볼 때 방향 감각이 조금 생깁니다.

핵심 포인트
오류를 만나면 바로 해결하려 들기보다, 먼저 어떤 행동을 했을 때 무엇이 안 되는지를 한 줄로 적어두는 편이 훨씬 좋습니다.

가장 먼저 볼 곳은 세 군데다

오류가 났을 때는 전체를 다 보려 하지 말고, 먼저 세 군데만 확인하면 됩니다. 초보자에게는 이 순서가 꽤 중요합니다.

1) 브라우저 화면

가장 먼저 봐야 하는 건 화면에서 실제로 무엇이 안 되는지입니다. 버튼을 눌렀는데 아무 변화가 없는지, 글자만 안 바뀌는지, 입력창은 비워졌는데 상태 문구는 그대로인지, 이런 식으로 겉으로 드러나는 증상을 먼저 확인합니다.

이때는 아직 원인을 단정하지 않는 편이 좋습니다. "JavaScript가 완전히 안 된다"처럼 크게 말하기보다, "버튼 클릭 뒤 미리보기 카드만 안 바뀐다"처럼 관찰한 사실만 남기는 쪽이 훨씬 도움이 됩니다.

2) 브라우저 콘솔

다음은 브라우저 개발자 도구의 콘솔입니다. 처음 보면 빨간 글씨가 부담스럽지만, 실제로는 가장 빨리 단서를 주는 곳 중 하나입니다. 페이지가 열릴 때 생긴 오류, 버튼을 눌렀을 때 발생한 오류, 내가 넣어둔 console.log() 출력이 여기 모입니다.

콘솔은 "뭔가 잘못됐다"는 사실만 말하는 게 아니라, 어떤 종류의 문제인지와 어느 쪽을 먼저 봐야 하는지를 같이 알려주는 경우가 많습니다. 지금은 문장을 완벽하게 번역하려고 하기보다, 핵심 단어만 읽어도 충분합니다.

특히 실습할 때는 콘솔을 그냥 오류만 뜨는 창처럼 보지 않는 편이 좋습니다. 정상 동작일 때 어떤 로그가 찍히고, 일부러 한 줄을 틀렸을 때 어떤 메시지로 바뀌는지를 비교해보면 훨씬 빠르게 익숙해집니다.

3) VS Code 에디터와 Problems 패널

VS Code 쪽도 같이 봐야 합니다. 편집기에서 빨간 밑줄이나 경고 표시가 먼저 보일 때가 있고, Problems 패널에 현재 파일의 문제 목록이 정리되어 있을 때도 있습니다. 브라우저에서 실행하기 전에 이미 에디터가 힌트를 주는 경우도 생각보다 많습니다.

특히 괄호가 하나 덜 닫혔다거나, 따옴표가 끝나지 않았다거나, 이름을 잘못 적은 경우처럼 비교적 단순한 실수는 VS Code가 먼저 눈에 띄게 보여주는 편입니다. 그래서 초보자는 콘솔만 보지 말고, 에디터 안의 빨간 표시도 같이 보는 습관을 들이면 좋습니다.

오류가 났을 때 먼저 보는 세 곳
보는 곳	무엇을 확인하나	가장 잘 잡히는 문제
브라우저 화면	어떤 행동 뒤에 무엇이 안 바뀌는지	겉으로 드러나는 동작 문제
브라우저 콘솔	오류 메시지와 로그	문법 오류, null 참조, 이벤트 연결 문제
VS Code 에디터	빨간 밑줄, Problems 패널	괄호, 따옴표, 이름 오타 같은 기본 실수

핵심 포인트
오류를 볼 때는 "브라우저 화면, 브라우저 콘솔, VS Code 표시" 이 세 곳을 같이 보는 편이 좋습니다. 한 군데만 보면 힌트가 반쯤만 보이는 경우가 많습니다.

5분 실습으로 오류와 console.log 직접 보기

지금부터는 아주 작은 예제로 직접 확인해보겠습니다. 이 구간이 들어가야 독자가 "오류를 읽는 법"을 머리로만 이해하는 데서 끝나지 않고, 실제로 브라우저와 콘솔을 같이 보는 감각까지 가져갈 수 있습니다.

실습은 어렵지 않습니다. 파일 두 개만 만들고, 정상 동작을 먼저 확인한 뒤, 일부러 오류를 하나씩 만들어보면 됩니다. 이 순서가 중요한 이유는, 초보자가 처음부터 오류만 보면 무엇이 정상이고 무엇이 비정상인지 비교 기준이 없기 때문입니다.

1) 실습용 파일 두 개 만들기

먼저 아래처럼 아주 작은 HTML과 JavaScript 파일을 만듭니다.

<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="UTF-8">
  <meta
    name="viewport"
    content="width=device-width, initial-scale=1.0"
  >
  <title>console.log 실습</title>
  <script defer src="script.js"></script>
</head>
<body>
  <main>
    <h1>console.log 실습</h1>
    <input
      id="nameInput"
      type="text"
      placeholder="이름을 입력해보세요"
    >
    <button
      id="checkButton"
      type="button"
    >
      확인
    </button>
    <p id="resultText">아직 입력 없음</p>
  </main>
</body>
</html>

const nameInput = document.querySelector("#nameInput");
const checkButton = document.querySelector("#checkButton");
const resultText = document.querySelector("#resultText");

console.log("script loaded");

checkButton.addEventListener("click", function () {
  console.log("button clicked");
  console.log("current input:", nameInput.value);

  const nextText =
    nameInput.value || "값이 비어 있습니다.";

  console.log("result text:", nextText);

  resultText.textContent = nextText;
});

이제 HTML 파일을 브라우저에서 열고, 개발자 도구 콘솔을 같이 열어둡니다. 여기서 중요한 건 코드를 읽는 것보다, 화면과 콘솔이 같이 어떻게 반응하는지를 보는 것입니다.

2) 정상 동작부터 먼저 확인하기

페이지를 열자마자 콘솔에 "script loaded"가 보이는지 확인합니다.
입력창에 아무것도 안 넣고 확인 버튼을 누릅니다.
그다음 이름을 하나 입력하고 다시 버튼을 눌러봅니다.

이 단계에서 봐야 할 건 세 가지입니다.

페이지가 열릴 때 스크립트가 실제로 로드되는가
버튼 클릭이 콘솔에 찍히는가
입력값과 결과 문구가 콘솔과 화면에서 같이 바뀌는가

여기까지가 정상 기준입니다. 이제부터는 일부러 한 줄씩 틀려보면서, 콘솔 메시지가 어떻게 달라지는지 비교해보면 됩니다.

3) 일부러 오류 만들기 1: id 이름 다르게 적기

HTML의 버튼 id를 아래처럼 바꿔봅니다.

<button id="checkBtn" type="button">확인</button>

이제 다시 새로고침해보면, JavaScript는 여전히 "#checkButton"을 찾고 있기 때문에 버튼 요소를 못 찾습니다. 이때는 보통 "Cannot read properties of null" 같은 오류가 콘솔에 뜹니다.

여기서 읽어야 할 핵심은 이겁니다.

null이 보이면 요소를 못 찾았을 가능성이 큽니다.
addEventListener가 같이 보이면 이벤트를 붙이던 자리에서 문제가 난 겁니다.
즉, HTML의 id와 JavaScript 선택자를 먼저 맞춰봐야 합니다.

4) 일부러 오류 만들기 2: 변수 이름 오타 내기

이번에는 JavaScript의 마지막 줄을 아래처럼 바꿔봅니다.

resltText.textContent = nextText;

여기서는 resultText가 아니라 resltText로 오타를 냈습니다. 이 경우 콘솔에는 보통 "resltText is not defined" 같은 메시지가 뜹니다.

이 오류에서 핵심은 더 단순합니다. 요소를 못 찾은 게 아니라, 내가 선언하지 않은 이름을 쓰고 있다는 뜻입니다. 이때는 HTML보다 먼저 JavaScript 변수 이름을 다시 봐야 합니다.

5) 일부러 오류 만들기 3: 문법 오류 만들기

이번에는 아래 줄의 닫는 괄호를 하나 빼봅니다.

console.log("button clicked"

이렇게 하면 보통 "Unexpected token", "missing ) after argument list" 같은 문법 오류가 뜹니다. 이런 경우는 로직을 의심할 게 아니라, 방금 수정한 줄의 괄호와 따옴표부터 다시 맞춰보는 편이 가장 빠릅니다.

핵심 포인트
이 실습에서 중요한 건 오류를 많이 보는 게 아니라, 정상 상태를 먼저 확인하고, 한 줄만 일부러 틀린 뒤 콘솔 메시지가 어떻게 달라지는지 비교하는 것입니다.

console.log()는 이렇게 찍어야 진짜 도움이 된다

동작 오류는 에디터나 콘솔 메시지만으로 바로 안 보일 때가 있습니다. 이럴 때 console.log()가 왜 중요한지 초보자는 종종 잘 못 느낍니다. 그냥 값을 찍는 도구라고만 이해하면, 실제로 어디에 찍어야 할지 감이 안 오기 때문입니다.

그래서 console.log()는 "무슨 값이 있나?"보다 "지금 코드가 어디까지 왔는가"를 확인하는 도구로 먼저 이해하는 편이 좋습니다. 초보자 실습에서는 보통 아래 세 가지 용도로 나눠서 찍으면 훨씬 덜 헷갈립니다.

1) 이벤트가 실제로 들어오는지 확인하는 로그

가장 먼저 찍는 로그는 클릭이나 입력이 진짜 들어오는지 보는 로그입니다.

checkButton.addEventListener("click", function () {
  console.log("button clicked");
});

이 로그가 안 찍히면, 아직 값 문제를 볼 단계가 아닙니다. 버튼이 눌린 게 맞는지, 이벤트가 연결된 게 맞는지부터 다시 봐야 합니다.

2) 지금 값이 실제로 어떻게 들어오는지 확인하는 로그

이벤트가 들어온다는 게 확인되면, 그다음에는 값 자체를 봅니다.

checkButton.addEventListener("click", function () {
  console.log("current input:", nameInput.value);
});

여기서 볼 건 많지 않습니다.

값이 비어 있는가
생각한 값이 아니라 공백만 들어가는가
아예 다른 값이 들어가는가

즉, 이 단계는 "이벤트는 왔는데 결과가 이상하다" 싶을 때 값을 좁혀보는 단계입니다.

3) 화면에 넣기 직전 값을 확인하는 로그

입력값을 그대로 쓰지 않고, 비어 있을 때 대체 문구를 넣는 경우도 많습니다. 이럴 때는 최종적으로 화면에 넣을 값을 한 번 더 찍어보는 편이 좋습니다.

checkButton.addEventListener("click", function () {
  console.log("button clicked");
  console.log("current input:", nameInput.value);

  const nextText =
    nameInput.value || "값이 비어 있습니다.";

  console.log("result text:", nextText);

  resultText.textContent = nextText;
});

이렇게 보면 흐름이 훨씬 또렷해집니다.

클릭이 들어왔는지 본다
원래 입력값이 뭔지 본다
최종적으로 화면에 넣을 값이 뭔지 본다

즉, console.log()는 아무 데나 찍는 게 아니라 이벤트 -> 원본 값 -> 최종 결과 순서로 찍으면 훨씬 읽기 쉬워집니다.

핵심 포인트
console.log()는 "값 하나 찍어보기"가 아니라, 내 코드가 지금 어느 단계까지 정상적으로 도착했는지 확인하는 도구라고 생각하는 편이 훨씬 좋습니다.

VS Code에서는 여기부터 확인하면 된다

브라우저 쪽만 보다 보면 놓치는 신호가 있습니다. VS Code는 실행 전부터 문제를 조금씩 보여주기도 하고, 실행 중에 한 줄씩 멈춰보는 흐름도 도와줍니다. 하지만 처음부터 모든 디버깅 기능을 다 쓰려고 할 필요는 없습니다. 순서를 정해두는 편이 더 낫습니다.

1) 빨간 밑줄과 경고 표시를 먼저 본다

가장 먼저 볼 건 편집기 안의 표시입니다. 괄호가 빠졌거나 이름이 이상하면 밑줄이나 경고가 먼저 보이는 경우가 많습니다. 이때는 오류 문장을 외우려 하기보다, 어느 줄에 표시가 생겼는지와 마우스를 올렸을 때 어떤 안내가 뜨는지만 확인해도 충분합니다.

2) Problems 패널에서 현재 문제를 모아본다

파일 여러 개를 왔다 갔다 하다 보면, 어느 파일에 무슨 문제가 있었는지 흐려질 수 있습니다. 이럴 때 Problems 패널을 보면 현재 잡히는 오류와 경고를 한곳에서 모아볼 수 있습니다. 초보자에게는 이 기능이 생각보다 유용합니다. 전체 상황을 좁게 다시 볼 수 있기 때문입니다.

3) 그래도 흐름이 안 보이면 한 줄 멈춰본다

여기서 한 단계 더 가면 브레이크포인트를 찍고 코드 실행을 잠깐 멈춰보는 방식도 있습니다. 지금은 이걸 깊게 들어가기보다, "코드가 지나가는 중간 지점에서 멈춰서 변수 상태를 볼 수 있다" 정도만 알아두면 충분합니다.

VS Code에서 먼저 보는 순서
순서	무엇을 보나	언제 특히 유용한가
1	빨간 밑줄, 경고 표시	괄호, 따옴표, 이름 오타 같은 기본 실수
2	Problems 패널	파일 여러 개를 오갈 때 전체 문제를 다시 좁혀볼 때
3	브레이크포인트, 디버거	console.log()만으로 흐름이 안 보일 때

핵심 포인트
VS Code의 디버깅 기능은 처음부터 다 쓰는 것보다, 빨간 표시 -> Problems 패널 -> 필요할 때 디버거 순서로 좁혀보는 편이 훨씬 좋습니다.

Codex에게 오류를 물을 때는 이렇게 좁혀서 말하자

오류가 났을 때 Codex를 쓰는 건 좋습니다. 다만 여기서도 방식이 중요합니다. "안 돼, 왜 안 되지?"라고만 던지면 AI도 넓게 추측할 수밖에 없습니다. 반대로 어느 파일에서, 어떤 행동을 했을 때, 콘솔에 어떤 메시지가 떴는지를 같이 주면 답이 훨씬 또렷해집니다.

좋은 요청은 대체로 세 가지를 포함합니다.

관련 파일
문제가 나는 행동
콘솔 메시지나 현재 증상

예를 들어 이런 식으로 물으면 좋습니다.

@index.html @script.js
버튼을 눌러도 미리보기 카드가 바뀌지 않아.
브라우저 콘솔에는 Cannot read properties of null (reading 'addEventListener')가 떠.
바로 고치기 전에, 가능한 원인 후보를 3개만 좁혀서 설명해줘.
내가 먼저 확인할 항목도 같이 적어줘.

이 요청이 좋은 이유는 AI가 처음부터 전체 리팩터링으로 튀지 않고, 원인 후보를 좁히는 방향으로 답하게 만들기 때문입니다. 초보자에게는 이 차이가 꽤 큽니다.

흐름 확인용으로는 이런 식도 괜찮습니다.

@script.js
지금 코드에서 이벤트가 들어오는지,
입력값이 제대로 들어오는지,
화면에 넣기 직전 값이 맞는지 확인할 수 있게
console.log()를 최소한으로 3개만 넣어줘.
각 로그를 왜 그 위치에 넣는지도 같이 설명해줘.

그리고 수정 요청을 하기 전에는 아래 한 줄을 같이 붙여두는 편이 좋습니다.

수정 전에 무엇이 문제라고 보는지 짧게 먼저 설명해줘.
파일 전체를 크게 바꾸지 말고, 필요한 부분만 최소한으로 고쳐줘.

이 한 줄이 있으면 결과가 훨씬 안정적입니다. 초보자는 "정답 코드"보다 "왜 이렇게 고쳤는지"를 같이 받아야 다음에 덜 흔들리기 때문입니다.

핵심 포인트
오류를 AI에게 물을 때는 "왜 안 되지?"보다 어느 파일에서, 어떤 행동을 했고, 어떤 메시지가 떴는지를 같이 주는 편이 훨씬 좋습니다.

저작자표시 비영리 변경금지 (새창열림)

'바이브코딩 > 실습' 카테고리의 다른 글

바이브코딩 8편: 할 일 체크리스트 앱 하나를 끝까지 만들어보자 (0)	2026.03.18
바이브코딩 7편: Git은 버전 관리보다 체크포인트라고 이해하면 편하다 (0)	2026.03.16
바이브코딩 5편: AI가 고친 코드를 어디부터 읽어야 할까 (0)	2026.03.14
바이브코딩 4편: JavaScript로 버튼 클릭과 입력 반응 붙이기 (0)	2026.03.13
바이브코딩 3편: VS Code와 Codex로 자기소개 페이지 만들기 (1)	2026.03.12