디버그 사고방식

버그를 찾고 고치는 과학적 접근법

⏱ 예상 ~8분

01 · 읽기

코드는 망가져요. 모든 엔지니어의 코드가 망가져요. 초보와 프로의 차이는 프로가 버그 없는 코드를 쓴다는 게 아니에요. 프로는 체계적으로 버그를 찾고 고치는 법을 안다는 거예요.

디버깅은 무작위 시행착오가 아니에요. 이것저것 바꾸면서 잘되길 비는 게 아니에요. 과학적 방법이에요. 관찰, 가설, 테스트, 결론.

디버그 마법사처럼 보이는 엔지니어가 더 똑똑한 건 아니에요. 그저 당황하지 않고 프로세스를 따를 뿐이에요.

💡 상상해 봐요디버깅은 탐정 일과 같아요. 범죄(버그)가 일어났어요. 증거(에러 메시지, 로그)를 모으고, 이론(가설)을 세우고, 테스트(하나만 바꿔보기)하고, 사건을 해결하거나 새 이론을 세워요. 무작위로 사람을 잡아넣고 잘되길 빌지 않죠.

디버그 프로세스 — 버그를 만날 때마다 이 단계를 따라가세요

버그를 일관되게 발생시킬 수 있나요? 무작위로 나타난다면 타이밍이나 상태 문제일 거예요. 재현할 수 없으면 자신 있게 고칠 수도 없어요. 버그를 일으키는 정확한 단계를 적어두세요.

정확히 어디서 잘못됐나요? 특정 파일, 함수, 줄까지 좁히세요. console.log나 에러 메시지로 위치를 짚으세요. 조사 영역이 작을수록 문제를 더 빨리 찾을 수 있어요.

원인이 뭐라고 생각하나요? 뭔가 바꾸기 전에 이론을 세우세요. '배열이 비었을 때 index 0에 접근해서 버그가 나는 것 같아.' 이론이 있으면 조사가 한 방향으로 집중돼요.

한 번에 하나씩만 바꾸면서 가설을 테스트하세요. 한 번에 여러 개 바꾸지 마세요. 세 개를 바꿨는데 버그가 사라지면, 뭘 고친 건지 모르거든요. 이때의 규율이 나중에 몇 시간을 아껴줘요.

알아낸 걸 바탕으로 수정을 적용하세요. 좋은 수정은 증상이 아니라 근본 원인을 다뤄요. 배열이 비었을 때 사용자가 크래시 난다면, 에러를 그냥 숨기지 말고 빈 배열을 제대로 처리하세요.

원래 버그가 아직 발생하나요? 다른 걸 망가뜨리진 않았나요? 수정을 테스트하고, 주변도 테스트하세요. 새 버그를 만드는 수정은 진짜 수정이 아니에요.

프로세스를 실제로 적용해 볼게요. 버그가 있는 앱을 물려받았어요. 방문자 카운트 API예요. 사용자가 /api/stats 엔드포인트를 호출하면 크래시 나요. 할 일은: 디버그 프로세스를 따라 버그를 찾는 거예요.

1단계: REPRODUCE — 에러 로그를 읽고 뭐가 잘못됐는지 파악하세요. 에러 메시지가 가장 좋은 친구예요. 보통 정확히 무슨 일이 일어났고 어디서 일어났는지 알려줘요.

(이 섹션은 인터랙티브해요 — JavaScript를 켜 주세요.)

2단계: ISOLATE — 에러가 7번째 줄의 count가 undefined라고 가리켜요. 그 값은 getVisitorCount()에서 와요. 코드를 읽고 함수를 찾아 뭐가 잘못됐는지 보세요.

(이 섹션은 인터랙티브해요 — JavaScript를 켜 주세요.)

아래는 헤아릴 수 없이 많은 시간을 아껴줄 디버그 황금률이에요. 필요하면 모니터에 붙여두세요.

핵심 정리

디버그의 첫 단계는 버그를 일관되게 _____ 하는 거예요.

디버그의 첫 단계는?

⚠ 전체 인터랙티브 경험에는 JavaScript가 필요해요. JavaScript를 켜고 새로 고침해 주세요.

※ 이 사이트는 독립 운영되는 교육 프로젝트로, Anthropic의 공식 제품이 아니에요. Claude™ 는 Anthropic, PBC 의 상표예요.