에러 메시지를 검색부터 하는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-08-09

에러 창이 빨갛게 물들면, 습관적으로 메시지를 복사해 구글이나 클로드에 붙여넣습니다. 당장 눈앞의 문제를 치우는 가장 빠른 방법이라고 생각합니다. 그렇지 않습니다.

에러의 진짜 원인은 내 코드에 있습니다

멘토링을 하며 200명 가까운 주니어 개발자들의 문제 해결 과정을 지켜봤습니다. 절반 이상은 에러 로그를 마주하자마자 첫 줄의 NullPointerException이나 Cannot read property만 긁어서 브라우저를 켭니다. 정작 세 번째 줄에 자신이 작성한 UserService.java의 42번째 줄에서 문제가 시작되었다는 단서가 있는데도 말입니다.

자신이 작성한 코드의 맥락은 로컬 환경에만 존재합니다. 그런데 전 세계 누군가가 겪은 '비슷해 보이는' 상황에서 답을 찾으려 합니다. 내 코드의 문제를 남의 코드에서 찾으려는 모순에 빠지는 순간, 디버깅의 방향은 완전히 어긋납니다.

해결된 것이 아니라 덮어둔 것입니다

검색 결과 최상단에 뜬 스택오버플로우의 답변이나, AI가 뱉어낸 코드를 그대로 복붙합니다. 운 좋게 에러가 사라지면 가슴을 쓸어내립니다. 하지만 왜 그 코드가 문제를 해결했는지는 설명하지 못합니다.

3주 뒤, 기획이 약간 바뀌어 새로운 기능이 추가되면 정확히 같은 에러가 다시 터집니다. 그러면 또다시 검색창을 헤매거나 프롬프트를 길게 다듬기 시작합니다. 이건 문제를 해결한 게 아닙니다. 당장의 붉은 글씨를 임시로 덮어둔 것뿐입니다. 왜 에러가 발생했는지 내 코드의 논리적 결함을 진단하지 못하면 실력은 그 자리에 머뭅니다. 1년 차에도, 3년 차에도 똑같은 에러를 복붙하는 코더로 남게 됩니다.

번역기를 돌려도 좋습니다

영어로 된 수십 줄의 에러 콜스택이 두려울 수 있습니다. 그럴 때는 차라리 그 메시지 전체를 번역기에 넣고 한국어로 읽으세요. 검색창에 에러명을 검색해 남의 상황을 훔쳐보는 것보다, 시스템이 내 코드에 대해 보내는 피드백을 직접 마주하는 것이 훨씬 낫습니다.

에러 메시지는 컴퓨터가 당신에게 보내는 가장 정확한 진단서입니다. 브라우저를 켜기 전, 딱 3분만 로그를 처음부터 끝까지 추적해 보세요. 그 3분이 검색창에서 낭비하는 3시간을 훌륭하게 아껴줍니다.