01 / 15
SESSION 17 · Part 4 개발 환경

디버깅 기초

에러는 적이 아니다 — 친절한 길잡이다

02 / 15
🎯

이 세션에서
배우는 것

📖
에러 메시지 읽기
에러 타입과 위치를 파악해 문제를 찾는다
🔎
로그로 추적
console.log로 변수 값을 확인해 흐름을 파악한다
⏸️
브레이크포인트
코드 실행을 멈추고 상태를 실시간 검사한다
03 / 15
💭

에러는 적이 아니다

초보자는 빨간 에러 메시지를 보면 당황한다. 그러나 에러는
"이 줄에 이런 문제가 있어요" 라고 알려주는 친절한 길잡이다.

코딩 실력의 절반은 디버깅이다.
AI에게 질문할 때도 에러 메시지를 그대로 복사해주면 훨씬 정확한 답을 얻는다.

04 / 15

에러 메시지를 해독하기

모든 에러 메시지는 3가지 정보를 담고 있다.

🏷️
에러 타입
TypeError, SyntaxError, ReferenceError… 어떤 종류의 문제인지
📍
위치
app.js:24:10 — 파일명, 줄번호, 컬럼까지 알려준다
💬
설명
Cannot read property 'name' of undefined — 무엇이 문제인지

💡 Tip: 스택 트레이스는 가장 아래부터 위로 읽으면 원인을 찾기 쉽다.

05 / 15
🐛

버그의 종류 —
더 깊게 이해하기

모든 버그가 같은 종류가 아니다. 어떤 버그인지 알면 해결 방법도 달라진다.

1
문법 오류 (Syntax Error)
괄호를 빠뜨리거나 철자를 틀린 경우. 가장 발견하기 쉬운 버그 — 실행 전에 에디터가 표시해 준다.
2
런타임 오류 (Runtime Error)
코드는 맞지만 실행 중 문제가 생기는 경우. null인 변수에 접근하거나 0으로 나누는 등의 상황.
3
논리 오류 (Logic Error)
에러는 없지만 결과가 기대와 다른 경우. 가장 찾기 어렵다. "왜 숫자가 이상하게 나오지?"
+
현실에서 가장 흔한 버그는?
논리 오류다. "이 변수가 null인 줄 몰랐어요"가 런타임, "조건식을 거꾸로 썼어요"가 논리 오류다.
06 / 15
🛠️

디버깅 도구 3종

📝
console.log
가장 기본이자 강력한 방법. 의심되는 변수를 출력해 실제 값과 예상을 비교.
⏸️
브레이크포인트
VS Code에서 줄 번호 옆을 클릭. 그 줄에서 멈추고 모든 변수 상태를 검사.
🤖
AI에게 묻기
에러 메시지 + 코드를 그대로 붙여 "이 에러 왜 나요?" 질문. 놀랍도록 정확하다.
07 / 15
🔍

크롬 개발자도구 —
실제로는 어떻게?

F12 하나로 웹페이지의 모든 에러를 추적하는 과정.

❗ 화면에 버그 발생
→
F12 콘솔 열기
→
🔴 에러 메시지 확인
→
📍 파일:줄 클릭 → 수정

핵심: 브라우저 콘솔은 웹 개발자의 가장 기본 디버깅 도구 — 항상 열어두는 습관을 만들자

08 / 15

디버깅 — 5단계 프로세스

막막할 때 따라가는 체크리스트.

1
에러 메시지 정확히 읽기
타입, 위치, 설명 세 가지를 먼저 확인. 절대 건너뛰지 말 것.
2
재현 조건 파악
어떤 입력·어떤 상황에서 발생하는지 특정. 재현되지 않으면 고칠 수도 없다.
3
가설 세우기 — "아마 이것 때문일 거야"
변수가 undefined라서? 타입이 달라서? 가장 의심되는 후보부터.
4
검증 — console.log / 브레이크포인트
가설이 맞는지 실제 값을 확인. 예상과 다르면 그곳이 원인에 가까운 지점.
5
수정 & 재실행
문제를 고치고 처음부터 같은 시나리오로 재실행. 같은 에러가 안 나는지 확인.
09 / 15
📱

실생활에서
이렇게 쓰여요

우리가 매일 사용하는 앱과 서비스 속에 이 개념이 녹아 있다.

🌐
크롬 개발자도구 콘솔
F12를 누르면 현재 웹페이지의 모든 에러와 로그가 보인다. 모든 웹 개발자가 매일 사용한다
⏸️
VS Code 브레이크포인트
줄 번호 옆을 클릭해 빨간 점을 찍으면 그 줄에서 코드가 멈추고 모든 변수를 검사할 수 있다
🤖
AI에게 에러 붙여넣기
에러 메시지를 그대로 Claude나 ChatGPT에 붙여넣으면 원인과 해결책을 즉시 알려준다

💡 이 개념이 없다면 에러가 날 때마다 모든 코드를 처음부터 다시 읽어야 한다

10 / 15
💡

자주 하는
오해 바로잡기

이렇게 생각하기 쉽지만, 실제로는 조금 다릅니다.

❌ 흔한 오해
  • 버그=오타다
  • 디버깅은 오래 걸린다
  • 에러=실패다, 창피한 일이다
✓ 실제로는
  • 논리 오류가 더 흔하다. 철자는 맞는데 동작이 틀린 경우가 대부분이다
  • 방법론이 있다. 5단계 프로세스를 따르면 체계적으로 빠르게 찾을 수 있다
  • 에러는 정보다. "여기가 문제야"라고 알려주는 친절한 신호다
11 / 15
🩺

디버깅은 의사의 진단

증상만 없애지 말고 근본 원인을 찾아 치료한다.

🏥 진료 비유
환자의 증상
=
에러 메시지 — "여기가 아픕니다"
문진·검사
=
console.log — 실제 상태 확인
정밀 검진
=
브레이크포인트 — 한 걸음씩 멈추고 살피기
처방·수술
=
코드 수정 — 근본 원인을 고치기
12 / 15
🤖

이걸 알면
AI와 이렇게 대화해요

이 개념을 이해하면 Claude나 ChatGPT를 훨씬 잘 활용할 수 있다.

👤
이 에러가 뭔지 모르겠어요.
🤖
에러 메시지와 관련 코드를 알려주시면 도움드릴게요.
👤
TypeError: Cannot read properties of undefined (reading 'map') — 이 에러의 원인과 수정 방법 알려줘. 코드: const items = data.results.map(item => item.name)
🤖
data.results가 undefined입니다. API 응답 전에 map을 호출하거나, data가 null인 경우예요. const items = data?.results?.map(item => item.name) ?? [] 처럼 옵셔널 체이닝으로 방어하세요.
13 / 15
✅

이렇게
이해하셨나요?

✅
맞게 이해하셨어요
console.log는 디버깅의 기본 도구이며, 변수의 실제 값을 확인해 예상과 비교하는 데 사용한다
❌
이렇게는 아니에요
에러가 없으면 버그도 없다 — 논리 오류는 에러 없이도 발생하며 오히려 찾기가 더 어렵다
✅
맞게 이해하셨어요
에러 메시지는 타입·위치·설명 세 가지 정보를 담고 있으며, 읽는 방법을 알면 해결이 빨라진다
❌
이렇게는 아니에요
버그=오타다 — 논리 오류와 런타임 오류가 더 흔하며, 오타(문법 오류)는 에디터가 먼저 잡아준다

💪 에러를 두려워하지 마세요. 에러는 문제가 어디 있는지 알려주는 친절한 신호입니다!

14 / 15
📌

핵심 정리

🚨
에러 메시지
타입 + 위치 +
설명 3종 세트
📚
스택 트레이스
호출 경로 —
아래부터 읽기
📝
console.log
가장 기본,
가장 강력한 도구
⏸️
브레이크포인트
실행을 멈추고
상태 검사
🔍
5단계
읽기 → 재현 → 가설 →
검증 → 수정
🧠
근본 원인
증상이 아닌
원인을 고치기
15 / 15
🚀

다음 Part 5 · HTML 기초

언어를 알고, 에디터·Git·패키지·디버깅까지 — 개발 환경이 갖춰졌다.
이제 진짜 웹의 언어를 배울 시간. HTML로 첫 페이지를 만들어본다.

💡 기억할 것: 에러는 적이 아니라 길잡이다.

슬라이드 목록