4. 바이브코딩에서 오류가 나면 어디부터 볼까: 초보자를 위한 콘솔 입문 ::REFUGE HUB

바이브코딩으로 앱이나 웹페이지를 만들다 보면, 처음 막히는 순간은 의외로 비슷합니다. 버튼을 눌렀는데 아무 반응이 없거나, 분명 AI가 코드를 다시 고쳐줬는데 여전히 같은 문제가 반복되는 경우입니다. 초보자 입장에서는 여기서 갑자기 자신감이 꺾이기 쉽습니다. 무엇이 잘못된 건지 모르겠고, 코드 전체가 한꺼번에 낯설어지기 때문입니다.

그런데 많은 경우 해결의 시작은 코드 전체를 해석하는 데 있지 않습니다. 오히려 콘솔에 남은 한 줄을 읽는 것에서 출발합니다. 콘솔은 개발자만 보는 어려운 공간이라기보다, 브라우저가 지금 어떤 일이 벌어졌는지 알려주는 작업 메모장에 가깝습니다. 여기에 오류가 적히고, 경고가 보이고, 내가 직접 값을 찍어볼 수도 있습니다.

즉, 초보자가 콘솔을 본다는 것은 대단한 기술을 쓰는 일이 아닙니다. 막연하게 “안 된다”에서 멈추지 않고, 왜 안 되는지 단서를 하나 더 얻는 과정에 가깝습니다. 이번 글에서는 콘솔을 처음 보는 사람도 따라갈 수 있게, 어디를 먼저 보면 되는지부터 자주 만나는 오류, 그리고 AI에게 다시 어떻게 전달하면 되는지까지 차근차근 정리해보겠습니다.

이번 글의 핵심
바이브코딩에서 콘솔은 겁내야 할 창이 아니라, 문제를 더 작게 나눠서 볼 수 있게 도와주는 단서 창에 가깝다.

왜 콘솔이 필요한가

초보자가 바이브코딩에서 가장 흔하게 하는 반응은 이것입니다. “버튼이 안 되네. 그럼 AI에게 다시 전체를 짜달라고 해야겠다.” 물론 경우에 따라 그렇게 해도 됩니다. 하지만 매번 전체를 다시 생성하면, 문제 원인을 모르고 덮어버리는 일이 반복되기 쉽습니다. 그러면 비슷한 오류를 계속 만나게 됩니다.

여기서 콘솔이 필요한 이유가 분명해집니다. 콘솔은 지금 벌어진 문제를 조금 더 구체적인 문장으로 바꿔주는 곳입니다. 내가 보기에는 그냥 “아무 반응 없음”일 수 있지만, 콘솔에는 “특정 요소를 찾지 못했다”, “변수 이름이 정의되지 않았다”, “괄호가 잘못 닫혔다” 같은 식으로 단서가 남아 있을 수 있습니다.

이 과정을 보통 디버깅이라고 부릅니다. 처음 들으면 어렵게 느껴질 수 있지만, 뜻은 의외로 단순합니다. 문제가 생긴 이유를 한 번에 맞히는 게 아니라, 가능한 원인을 조금씩 좁혀 가는 과정입니다.

상황	초보자가 흔히 느끼는 것	콘솔이 주는 도움
버튼을 눌렀는데 아무 일도 안 일어남	도대체 어디가 문제인지 모르겠다	클릭 이벤트가 연결되지 않았는지, 실행 중 오류가 났는지 단서를 남길 수 있다
화면은 뜨는데 일부 기능만 안 됨	겉보기엔 멀쩡해서 더 헷갈린다	어떤 줄에서 실행이 끊겼는지 확인할 수 있다
AI가 수정해준 뒤 다른 기능이 깨짐	무엇이 바뀌었는지 모르겠다	새로 생긴 오류 메시지를 기준으로 수정 범위를 좁힐 수 있다
에러는 모르겠고 결과만 이상함	감으로만 다시 요청하게 된다	값을 직접 찍어보면서 어느 지점에서 예상과 달라지는지 볼 수 있다

중요한 점은, 콘솔을 본다고 해서 갑자기 개발자가 되어야 한다는 뜻이 아니라는 것입니다. 초보자에게 필요한 건 오류를 완벽하게 해석하는 능력보다 문제를 설명할 수 있는 한 줄을 더 확보하는 것입니다. 그 한 줄이 있어야 AI에게도 훨씬 정확하게 다시 요청할 수 있습니다.

오해하면 안 되는 부분
콘솔은 모든 문제를 자동으로 해결해주는 도구는 아니다. 다만 “왜 안 되는지 전혀 모르겠다”를 “이 부분이 수상하다” 수준까지 끌어올려 준다는 점에서 매우 유용하다.

콘솔 화면에서 무엇을 보면 되는가

콘솔을 처음 열면 글자가 여러 줄 보이고, 색도 다르고, 영어 메시지도 섞여 있어서 괜히 겁이 날 수 있습니다. 하지만 처음부터 모든 걸 읽을 필요는 없습니다. 초보자라면 우선 이 줄이 오류인지, 경고인지, 내가 직접 찍은 값인지 정도만 구분해도 충분합니다.

브라우저와 운영체제에 따라 여는 방식은 조금 다르지만, 보통 개발자 도구를 연 뒤 Console 탭을 보면 됩니다. 일부 환경에서는 F12나 마우스 오른쪽 메뉴의 검사 기능으로 들어갈 수 있습니다. 세부 위치는 조금 달라도, 핵심은 같습니다. 문제 상황이 발생했을 때 그 기록이 모이는 곳이 콘솔입니다.

콘솔에 보이는 것	쉽게 말하면	초보자가 어떻게 받아들이면 되는가
오류(Error)	실행이 멈췄거나 중요한 문제가 생긴 상태	가장 먼저 봐야 한다. 기능이 안 되는 직접 원인일 수 있다
경고(Warning)	당장 멈추진 않았지만 어색하거나 위험할 수 있는 상태	무시할 수도 있지만, 반복되면 확인하는 편이 좋다
로그(Log)	내가 직접 찍어본 값이나 실행 흔적	문제가 어디까지 진행됐는지 파악할 때 쓴다
파일명과 줄 번호	문제가 난 위치에 대한 힌트	코드 전체가 아니라 그 줄 주변부터 보면 된다

여기서 하나 기억해둘 만한 점이 있습니다. 콘솔에 무언가 많이 뜬다고 해서 전부 내 코드 문제는 아닐 수 있습니다. 브라우저 확장 프로그램, 외부 스크립트, 심지어 현재 페이지와 직접 관련 없는 경고도 섞여 보일 수 있습니다. 그래서 초보자는 특히 내가 방금 실행한 동작 직후 생긴 메시지, 그리고 내 파일명이나 내가 만든 코드와 연결된 줄 번호를 우선해서 보는 편이 좋습니다.

예를 들어 이런 흐름으로 보면 된다.

페이지를 새로 연다

콘솔을 연다

버튼을 눌러 본다

바로 그 직후 새로 뜬 메시지를 본다

파일명과 줄 번호가 보이면 그 주변을 먼저 본다

즉, 콘솔을 읽는 첫 단계는 “모든 문장을 이해하기”가 아니라, 지금 막 한 행동과 바로 이어진 메시지를 연결해 보는 것입니다. 이 감각만 생겨도 디버깅이 훨씬 덜 막막해집니다.

오류 메시지를 읽을 때 먼저 볼 4가지

오류 메시지는 길어 보일 수 있지만, 사실 초보자가 먼저 볼 핵심은 몇 가지로 줄일 수 있습니다. 아래 예시는 아주 자주 보는 형태입니다.

Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
at script.js:12

이 메시지를 처음 보면 당황스럽지만, 실제로는 네 가지 정도만 먼저 보면 됩니다.

먼저 볼 부분	예시에서 해당하는 부분	쉽게 이해하면
오류 종류	`TypeError`	값의 형태나 상태가 예상과 달라서 생긴 문제일 가능성이 크다
핵심 설명	`Cannot read properties of null`	무언가를 찾았다고 생각했는데 실제로는 비어 있거나 존재하지 않는 상태일 수 있다
문제가 난 대상	`addEventListener`	이 기능을 붙이려던 대상이 제대로 잡히지 않았을 가능성이 있다
위치	`script.js:12`	우선 12번째 줄 근처를 보면 된다

이 네 가지를 조금 더 실전적으로 풀어보면 아래 순서로 읽으면 됩니다.

오류 종류를 본다.
SyntaxError인지, ReferenceError인지, TypeError인지에 따라 문제 성격이 조금씩 다릅니다. 처음에는 완벽히 외울 필요 없고, “문법 문제인지”, “이름 문제인지”, “값 상태 문제인지” 정도만 구분해도 충분합니다.
메시지 가운데서 반복되는 핵심 단어를 본다.
null, undefined, not defined, Unexpected token 같은 표현은 꽤 자주 나옵니다. 이 단어들이 어디를 의심해야 할지 방향을 줍니다.
파일명과 줄 번호를 본다.
코드가 길어도 전부 읽지 말고, 해당 줄 주변부터 보는 편이 훨씬 낫습니다. 특히 AI가 한 번에 길게 코드를 준 경우에는 이 방식이 거의 필수에 가깝습니다.
오류가 난 직전 행동을 같이 기억한다.
페이지를 열자마자 뜨는지, 버튼을 눌렀을 때 뜨는지, 입력 후 저장할 때 뜨는지에 따라 원인 추정이 쉬워집니다.

중요한 감각
오류 메시지는 번역해야 할 외국어 문장이 아니라, “문제 유형 + 어디서 + 무엇 때문에”를 알려주는 짧은 보고서처럼 보는 편이 이해하기 쉽다.

여기서 초보자가 자주 하는 실수가 하나 있습니다. 오류 메시지를 앞부분만 보고 바로 AI에게 “고쳐줘”라고 보내는 것입니다. 가능하면 오류 전체 문장과 어떤 행동을 했을 때 떴는지를 같이 전달하는 편이 좋습니다. 같은 TypeError라도 상황이 전혀 다를 수 있기 때문입니다.

초보자가 자주 만나는 오류 5가지

처음 바이브코딩을 할 때 반복해서 마주치는 오류는 생각보다 비슷합니다. 아래 다섯 가지는 초보자가 웹 기반 프로젝트를 만들 때 꽤 자주 보는 편입니다. 문장을 통째로 외우는 것보다, 이 오류가 대충 어떤 상황을 뜻하는지 감을 잡아두는 쪽이 더 중요합니다.

오류 메시지 예시	쉽게 말하면	자주 생기는 이유	AI에게 다시 말할 때의 표현
`SyntaxError: Unexpected token`	문법이 깨져서 아예 읽히지 않는 상태	괄호, 따옴표, 쉼표, 중괄호가 잘못 닫혔거나 빠진 경우	문법 오류가 나서 실행이 안 돼. 괄호나 따옴표가 잘못된 부분부터 찾아서 최소 수정해줘
`ReferenceError: todoList is not defined`	그 이름의 변수를 찾지 못한 상태	변수 이름 오타, 선언 위치 문제, 이름 변경 후 일부만 수정된 경우	`todoList`가 정의되지 않았다고 떠. 변수명 불일치나 선언 위치를 먼저 확인해줘
`TypeError: Cannot read properties of null`	있다고 생각한 요소나 값이 실제로는 비어 있는 상태	HTML의 id와 JS 선택자가 다르거나, 요소가 만들어지기 전에 접근한 경우	요소를 찾지 못하는 것 같아. HTML id와 JS 선택자, 실행 시점을 먼저 점검해줘
`TypeError: something is not a function`	함수처럼 실행했는데 실제로는 함수가 아닌 상태	메서드 이름 오타, 값 형태 오해, 잘못된 객체에 함수 호출	이 값을 함수처럼 호출했는데 아니라고 떠. 어떤 값이 들어있는지 먼저 설명하고 최소 수정해줘
`Identifier 'items' has already been declared`	같은 이름을 두 번 선언한 상태	수정 과정에서 같은 변수를 중복 선언하거나 코드가 합쳐진 경우	같은 변수명이 중복 선언된 것 같아. 기존 구조를 크게 바꾸지 말고 중복만 정리해줘

이 다섯 가지를 보면 공통점이 있습니다. 아주 복잡한 알고리즘 문제라기보다, 이름이 안 맞거나, 순서가 어긋나거나, 구조가 조금 깨진 경우가 많다는 점입니다. 특히 AI가 코드를 여러 번 수정하면서 일부 이름만 바뀌거나, HTML과 JavaScript가 서로 다른 id를 가리키는 상황은 정말 자주 생깁니다.

그래서 초보자라면 오류를 만났을 때 바로 “나는 코딩을 몰라서 못 하겠네”라고 생각하기보다, 아래처럼 받아들이는 편이 더 현실적입니다.

SyntaxError는 대개 문장 부호를 먼저 의심한다.
ReferenceError는 이름이 맞는지 먼저 본다.
null 관련 TypeError는 요소를 제대로 찾았는지 본다.
not a function은 내가 함수라고 착각한 값이 무엇인지 본다.
already been declared는 중복 선언을 의심한다.

초보자에게 특히 중요한 점
오류 문장을 모두 해석하지 못해도 괜찮다. 지금 단계에서는 “문법 문제인지, 이름 문제인지, 요소를 못 찾는 문제인지” 정도만 구분해도 충분히 진전이 생긴다.

에러가 없어도 `console.log`가 필요한 이유

가끔 더 곤란한 경우가 있습니다. 분명 기능이 안 되는데, 콘솔에 빨간 오류가 뜨지 않는 상황입니다. 초보자는 이때 더 막막해집니다. “오류도 안 뜨는데 뭐가 문제지?” 싶은 순간입니다. 이럴 때 쓰는 가장 단순한 도구가 console.log입니다.

console.log는 지금 어떤 값이 들어 있는지, 어떤 함수가 실제로 실행됐는지 직접 찍어보는 방법입니다. 어렵게 생각할 필요 없이, 코드 안에 작은 메모를 잠깐 남겨서 브라우저에 보여달라고 하는 것에 가깝습니다.

궁금한 것	찍어볼 코드	알 수 있는 것
버튼 클릭이 실제로 연결됐는가	`console.log('버튼 클릭됨')`	클릭 이벤트가 시작되었는지 확인할 수 있다
요소를 제대로 찾았는가	`console.log(addBtn)`	요소가 잡혔는지, `null`인지 볼 수 있다
입력값이 실제로 들어오는가	`console.log(input.value)`	사용자가 입력한 값이 비어 있는지 확인할 수 있다
배열이나 목록 상태가 어떤가	`console.log(items)`	추가나 삭제 후 데이터가 예상대로 바뀌는지 볼 수 있다

예를 들어 할 일 추가 기능이 안 된다고 해보겠습니다. 아래처럼 아주 단순하게 찍어볼 수 있습니다.

function addTodo() {

console.log('addTodo 실행됨');
console.log('현재 입력값:', input.value);

if (!input.value.trim()) {
console.log('빈 입력이라 추가하지 않음');
return;
}

console.log('이제 항목을 추가할 차례');
}

이렇게 찍어보면 적어도 몇 가지는 바로 알 수 있습니다. 함수 자체가 실행되지 않는지, 실행은 되는데 입력값이 비어 있는지, 중간에서 조건문 때문에 멈추는지 같은 흐름이 드러납니다. 이건 초보자에게 꽤 중요합니다. 문제가 “전혀 모르겠는 상태”에서 “여기까지는 온다”로 바뀌기 때문입니다.

다만 console.log도 아무 데나 너무 많이 넣으면 오히려 더 헷갈릴 수 있습니다. 그래서 보통은 아래처럼 최소한으로 쓰는 편이 좋습니다.

문제가 의심되는 함수 맨 앞에 하나
조건문 직전에 하나
화면에 반영하기 직전에 하나

실전 팁
에러가 없는데 기능이 안 될 때는 “문제가 없는 것”이 아니라 “브라우저가 멈출 정도의 오류는 없지만 흐름이 어딘가에서 어긋난 것”일 수 있다. 이때 console.log가 가장 단순한 확인 도구가 된다.

AI에게 다시 요청할 때 이렇게 전달하면 된다

콘솔을 본 이유는 결국 다시 잘 요청하기 위해서이기도 합니다. 초보자가 AI에게 “안 돼”, “오류가 나”, “콘솔이 이상해” 정도만 말하면, AI는 다시 넓게 추측하기 시작합니다. 반대로 오류 메시지와 상황을 함께 주면 수정 범위를 훨씬 좁힐 수 있습니다.

특히 아래 정보는 가능한 한 같이 전달하는 편이 좋습니다.

전달하면 좋은 정보	왜 필요한가	예시
오류 메시지 전체	문제 유형을 정확히 파악하는 데 가장 직접적이다	`TypeError: Cannot read properties of null`
언제 발생하는지	페이지 로드 시점 문제인지, 클릭 후 문제인지 구분할 수 있다	추가 버튼을 누를 때만 뜬다
기대한 동작	무엇이 정상인지 알아야 수정 방향이 정해진다	빈칸이면 추가되지 않아야 한다
유지하고 싶은 부분	괜찮은 부분까지 다시 뒤엎는 일을 줄일 수 있다	기존 레이아웃과 한국어 문구는 유지해줘
최소 수정 요청	전체 재작성보다 안정적인 수정이 쉬워진다	문제가 되는 부분만 최소 수정해줘

이걸 실제 프롬프트 형태로 바꾸면 아래처럼 쓸 수 있습니다.

지금 체크리스트 코드에서 추가 버튼을 누를 때

콘솔에 아래 오류가 떠.

TypeError: Cannot read properties of null (reading 'addEventListener')

내가 기대한 동작은 버튼 클릭 시 할 일이 추가되는 거야.
기존 레이아웃과 한국어 문구는 유지하고,
HTML id와 JS 선택자 불일치나 실행 시점 문제를 먼저 확인해줘.
바로 전체를 다시 쓰기보다, 원인을 짧게 설명한 뒤
문제가 되는 부분만 최소 수정해서 보여줘.

에러가 없는 경우에도 비슷한 방식으로 요청할 수 있습니다.

콘솔에 빨간 오류는 없는데,

추가 버튼을 눌러도 목록이 생기지 않아.

내가 console.log로 확인해보니
버튼 클릭은 잡히는데 input.value가 비어 있어.
입력값을 읽는 부분과 이벤트 연결 흐름을 먼저 점검해줘.
기존 UI는 그대로 두고 로직만 최소 수정해줘.

이런 요청이 좋은 이유는 분명합니다. AI가 “어디가 문제인지 모를 때 전체를 다시 짜는 방향”이 아니라, 현재 구조를 유지한 채 원인을 좁혀 보는 방향으로 답하기 쉬워지기 때문입니다. 바이브코딩에서는 이 차이가 꽤 큽니다. 이미 잘 되던 부분을 덜 흔들면서 수정할 수 있기 때문입니다.

정리하면
콘솔을 보는 이유는 직접 모든 문제를 풀기 위해서만이 아니다. 문제를 더 구체적으로 설명해서, AI가 덜 엉뚱하게 수정하도록 만드는 데도 큰 도움이 된다.

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

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

6. 삭제는 되는데 왜 다른 항목이 지워질까: 바이브코딩에서 id가 필요한 이유 (0)	2026.03.12
5. 왜 새로고침하면 데이터가 사라질까: 바이브코딩 초보를 위한 localStorage 입문 (0)	2026.03.11
3. AI가 짜준 코드는 어디부터 확인할까: 바이브코딩 초보 점검 순서 (0)	2026.03.09
2. 바이브코딩에서 AI에게 잘 말하는 법: 초보자 프롬프트 작성 가이드 (0)	2026.03.09
1. 바이브코딩 처음이라면 무엇부터 만들까: 첫 프로젝트가 중요한 이유 (1)	2026.03.09