에러 로그를 보지 않는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-08-01

터미널이나 콘솔에 빨간색 에러 메시지가 뜨는 순간, 화면을 닫거나 프롬프트 창으로 코드를 복사해서 붙여넣는 주니어들을 수없이 만납니다. 200명이 넘는 백엔드 멘티들을 보면서 가장 흔하게 목격한 장면에 속합니다.

에러가 나면 마음이 조급해집니다. 당장 해결해서 빨간 글씨를 없애고 싶기 때문입니다. 하지만 스택 트레이스 첫 줄도 읽지 않은 채 검색창으로 직행하면, 디버깅 실력은 제자리에 멈춥니다.

에러 로그는 질책이 아니라 안내서입니다

멘토링 중에 3년 차 개발자 한 분이 널 포인터 예외 때문에 2시간 동안 고생했다며 질문을 가져왔습니다. 코드 전체를 헤매고 계시길래 로그를 보여 달라고 했습니다.

로그 세 번째 줄에 정확히 몇 번째 라인의 어떤 객체가 null인지 적혀 있었습니다. 그 문장을 읽는 데 5초도 걸리지 않았습니다. 에러 메시지는 개발자를 비난하는 경고문이 아니라, 어디서 문제가 시작되었는지 알려주는 지지도입니다.

첫 번째 줄보다 밑에서 다섯 번째 줄을 보세요

많은 주니어가 Framework internal Exception이라는 길고 복잡한 프레임워크 에러 명칭에 압도됩니다. 그러나 수십 줄의 로그 속에서 우리가 찾아야 할 것은 딱 하나입니다.

내가 직접 작성한 패키지 이름과 파일명이 등장하는 지점입니다. 프레임워크 내부 깊은 곳이 아니라, 내 코드가 프레임워크와 만나는 교차점에서 문제의 원인이 드러납니다.

NullPointerException이라는 결과에만 집착하면 원인을 놓칩니다. 그 값이 어디서부터 null로 넘어왔는지 역추적하는 것이 진짜 디버깅입니다.

로그를 끝까지 읽는 사람만 성장합니다

AI 도구가 대신 에러를 읽고 해결책을 제시해 주는 시대입니다. 그러나 로그가 전달하는 맥락을 스스로 읽어내지 못하면, AI가 제시한 코드도 검증할 수 없습니다.

오늘부터 터미널에 빨간 글씨가 뜨면 30초 동안 손을 키보드에서 떼 보세요. 가장 먼저 뜬 예외의 이름과 파일명, 그리고 라인 번호를 천천히 소리 내어 읽어보시기 바랍니다. 원인을 읽어내는 30초가 3시간의 헛수고를 줄여줍니다.