코딩을 처음 배우면 누구나 에러 메시지를 만나게 됩니다. 분명 강의에서 본 대로 코드를 작성한 것 같은데 갑자기 빨간 글씨가 길게 나오고, 프로그램은 실행되지 않습니다. 이 순간 많은 입문자가 당황합니다. “내가 뭘 잘못한 거지?”, “이거 고칠 수 있는 건가?”, “역시 나는 코딩이 안 맞나?” 같은 생각이 들기도 합니다.
저도 처음 코딩을 공부할 때 에러 메시지가 나오면 거의 멈춰버렸습니다. 영어로 된 문장이 길게 나오면 읽어볼 생각도 하지 않고, 코드 전체를 지웠다가 다시 따라 치곤 했습니다. 그런데 이상하게도 같은 에러가 또 나왔습니다. 나중에 알고 보니 에러 메시지는 겁먹으라고 나오는 것이 아니라, 문제의 위치와 원인을 알려주는 안내문에 가까웠습니다.
코딩 실력은 에러를 한 번도 안 내는 능력이 아닙니다. 오히려 에러를 만나도 차분하게 원인을 찾고 해결하는 능력이 중요합니다. 현업 개발자도 매일 에러를 만납니다. 차이가 있다면 에러를 대하는 태도와 해결하는 순서입니다.
에러 메시지는 실패가 아니라 힌트다
처음에는 에러 메시지가 무섭게 느껴집니다. 빨간 글씨, 긴 영어 문장, 낯선 파일 경로가 한꺼번에 나오기 때문입니다. 하지만 에러 메시지는 코드가 틀렸다고 혼내는 문장이 아니라, 어디에서 어떤 문제가 생겼는지 알려주는 힌트입니다.
예를 들어 파이썬에서 괄호를 닫지 않았거나, 따옴표를 빠뜨렸거나, 들여쓰기가 잘못되면 에러가 나옵니다. JavaScript에서도 변수 이름을 잘못 쓰거나, 함수 이름을 틀리거나, 괄호 위치가 맞지 않으면 에러가 발생합니다. 대부분의 초보자 에러는 아주 작은 실수에서 시작됩니다.
저도 처음에는 에러가 나면 코드 전체가 잘못된 줄 알았습니다. 그런데 자세히 보니 대부분은 한 줄에서 생긴 오타였습니다. 변수 이름을 userName이라고 만들어놓고 아래에서는 username이라고 쓴 경우도 있었고, 문자열 따옴표 하나를 빼먹은 적도 있었습니다. 이런 경험을 몇 번 하다 보면 에러 메시지를 조금씩 읽게 됩니다.
에러를 만났다는 것은 코딩을 못한다는 뜻이 아닙니다. 오히려 직접 실행해보고 있다는 증거입니다. 코드를 작성하지 않는 사람은 에러도 만나지 않습니다. 그러니 에러가 나왔다고 바로 실망하기보다 “컴퓨터가 어디를 고치라고 알려주고 있구나”라고 생각하는 편이 좋습니다.
가장 먼저 마지막 줄을 확인하기
에러 메시지가 길게 나올 때는 처음부터 끝까지 전부 읽으려고 하면 더 혼란스럽습니다. 입문자라면 먼저 마지막 줄을 확인하는 습관을 들이는 것이 좋습니다. 많은 경우 마지막 줄에 에러의 종류와 핵심 원인이 적혀 있습니다.
예를 들어 파이썬에서는 SyntaxError, NameError, IndentationError, TypeError 같은 에러 이름이 마지막에 보이는 경우가 많습니다. JavaScript에서는 브라우저 콘솔에 ReferenceError, TypeError, SyntaxError 같은 메시지가 나타날 수 있습니다.
처음에는 에러 이름이 어렵게 느껴지지만, 자주 보는 것부터 익히면 됩니다. SyntaxError는 문법이 잘못됐다는 뜻이고, NameError나 ReferenceError는 존재하지 않는 이름을 사용했을 가능성이 큽니다. TypeError는 데이터의 종류가 맞지 않을 때 자주 발생합니다.
저는 처음에 에러 메시지를 위에서부터 읽다가 금방 포기했습니다. 그런데 누군가 “마지막 줄부터 보라”고 알려준 뒤로 훨씬 편해졌습니다. 마지막 줄에서 에러 이름을 확인하고, 그 위쪽에서 몇 번째 줄에 문제가 있는지 찾는 방식으로 바꾸니 해결 속도가 빨라졌습니다.
파일명과 줄 번호를 찾는 습관
에러 메시지에는 보통 문제가 발생한 파일명과 줄 번호가 함께 나옵니다. 이 정보는 정말 중요합니다. 입문자 때는 에러 메시지 전체를 무서워하면서도 정작 줄 번호는 놓치는 경우가 많습니다.
예를 들어 “main.py 15번째 줄” 또는 “app.js 23번째 줄”처럼 표시된다면, 먼저 해당 파일의 그 줄로 가서 코드를 확인해야 합니다. 물론 실제 원인이 그 줄 바로 위에 있을 때도 있습니다. 괄호를 이전 줄에서 닫지 않았거나, 들여쓰기가 앞부분에서 잘못된 경우에는 에러가 표시된 줄보다 위쪽을 봐야 할 수도 있습니다.
그래도 줄 번호는 문제를 찾는 출발점입니다. 코드 전체를 처음부터 다시 보는 것보다 훨씬 효율적입니다.
저도 처음에는 에러가 나면 파일 전체를 훑어보며 어디가 틀렸는지 감으로 찾았습니다. 그러다 보니 시간이 오래 걸렸습니다. 나중에는 에러 메시지에서 파일명과 줄 번호를 먼저 찾는 습관을 들였고, 단순한 오타나 문법 실수는 훨씬 빨리 고칠 수 있었습니다.
자주 만나는 에러부터 익히기
코딩 초보자가 만나는 에러는 생각보다 반복됩니다. 매번 새로운 문제가 나오는 것 같지만, 자주 보면 비슷한 유형이 많습니다.
파이썬에서는 들여쓰기 실수로 IndentationError가 자주 나옵니다. 파이썬은 중괄호 대신 들여쓰기로 코드 범위를 구분하기 때문에 공백 하나도 중요합니다. 조건문이나 반복문 아래 코드가 제대로 들여쓰기되어 있지 않으면 바로 에러가 발생합니다.
NameError는 정의하지 않은 변수를 사용할 때 나올 수 있습니다. 변수 이름에 오타가 있거나, 변수를 만들기 전에 사용했을 때 자주 보입니다. TypeError는 숫자와 문자열을 잘못 더하려고 하거나, 함수에 맞지 않는 값을 넣었을 때 발생할 수 있습니다.
JavaScript에서는 ReferenceError가 자주 보입니다. 존재하지 않는 변수를 사용했을 때 나오는 경우가 많습니다. TypeError는 값이 예상한 형태가 아닐 때 자주 발생합니다. 예를 들어 배열이라고 생각하고 .map()을 사용했는데 실제로는 배열이 아닌 경우에 문제가 생길 수 있습니다.
처음부터 모든 에러를 외울 필요는 없습니다. 자주 만나는 에러 이름을 메모해두고, 어떤 상황에서 발생했는지 함께 적어두면 됩니다. 같은 에러를 두세 번만 정리해도 다음에는 덜 당황하게 됩니다.
에러가 나기 직전에 바꾼 부분을 보기
코드를 작성하다 보면 어느 순간 갑자기 에러가 생깁니다. 이때 가장 먼저 확인해야 할 것은 방금 수정한 부분입니다. 대부분의 에러는 최근에 건드린 코드에서 발생합니다.
초보자일수록 에러가 나면 전체 코드가 망가졌다고 생각하기 쉽습니다. 하지만 실제로는 방금 추가한 함수, 방금 바꾼 변수 이름, 방금 옮긴 파일 경로에서 문제가 생긴 경우가 많습니다.
저는 예전에 버튼 클릭 기능을 추가하다가 화면 전체가 작동하지 않는 문제를 만난 적이 있습니다. 처음에는 HTML 구조가 잘못됐나, CSS 때문인가 하면서 엉뚱한 곳을 계속 봤습니다. 그런데 결국 문제는 JavaScript에서 버튼 선택자 이름을 잘못 적은 것이었습니다. HTML에서는 submitBtn이라고 해놓고 JavaScript에서는 sumbitBtn처럼 오타를 낸 것입니다.
에러가 발생하면 “내가 마지막으로 바꾼 곳이 어디지?”라고 먼저 생각해보는 것이 좋습니다. 이 습관 하나만으로도 문제를 찾는 시간이 많이 줄어듭니다.
코드를 작게 나눠서 확인하기
에러 해결이 어려운 이유 중 하나는 한 번에 너무 많은 코드를 작성하기 때문입니다. 긴 코드를 한꺼번에 쓰고 실행하면 어디에서 문제가 생겼는지 찾기 어렵습니다. 그래서 코딩 초보일수록 조금씩 작성하고 자주 실행해보는 습관이 중요합니다.
예를 들어 Todo 리스트를 만든다고 했을 때, 입력창 만들기, 버튼 클릭 확인하기, 입력값 가져오기, 목록에 추가하기, 삭제 기능 만들기를 한 번에 다 작성하면 에러가 났을 때 원인을 찾기 어렵습니다. 반대로 한 단계씩 만들고 실행해보면 어느 부분에서 문제가 생겼는지 바로 알 수 있습니다.
저도 처음에는 강의 코드를 한 번에 길게 따라 치고 마지막에 실행했습니다. 그러면 에러가 한꺼번에 여러 개 나왔고, 어디부터 고쳐야 할지 막막했습니다. 이후에는 코드 몇 줄을 쓰고 바로 실행해보는 방식으로 바꿨습니다. 그러니 에러가 나도 방금 작성한 부분만 보면 돼서 훨씬 편했습니다.
코드는 작게 만들고 자주 확인하는 것이 좋습니다. 이 습관은 초보자뿐 아니라 실무에서도 중요합니다. 작은 단위로 확인하면 문제를 빨리 찾고, 수정하기도 쉽습니다.
검색할 때는 에러 메시지를 그대로 활용하기
에러를 해결할 때 검색은 매우 중요한 도구입니다. 하지만 검색도 요령이 있습니다. 단순히 “코딩 에러”, “파이썬 안 됨”, “자바스크립트 오류”처럼 검색하면 원하는 답을 찾기 어렵습니다.
가장 좋은 방법은 에러 메시지의 핵심 문장을 그대로 검색하는 것입니다. 예를 들어 TypeError: can only concatenate str and int처럼 에러 메시지의 중요한 부분을 복사해서 검색하면 비슷한 문제를 겪은 사람들의 해결 방법을 찾기 쉽습니다.
단, 파일 경로나 개인 프로젝트 이름처럼 내 컴퓨터에만 해당하는 부분은 빼고 검색하는 것이 좋습니다. 에러 이름과 핵심 문장 중심으로 검색하면 됩니다.
검색 결과를 볼 때는 무작정 복사해서 붙여넣기보다, 왜 그런 해결 방법이 나왔는지 이해하려고 해야 합니다. 당장 에러가 사라져도 원인을 모르면 다음에 같은 문제를 또 만납니다. 처음에는 느리더라도 “이 에러는 왜 생겼고, 이 코드는 왜 해결이 되는지” 한 문장으로 정리해보는 것이 좋습니다.
에러 해결 기록을 남기기
에러를 해결하고 나면 그냥 넘어가기 쉽습니다. 하지만 초보자일수록 에러 해결 기록을 남기는 것이 좋습니다. 같은 에러는 생각보다 자주 다시 만납니다. 그때 예전에 정리한 기록이 있으면 훨씬 빠르게 해결할 수 있습니다.
기록은 거창할 필요가 없습니다. 블로그, 노션, 메모장, GitHub README 어디든 괜찮습니다. “어떤 에러가 났는지”, “원인이 무엇이었는지”, “어떻게 해결했는지” 정도만 적어도 충분합니다.
예를 들어 “IndentationError가 발생했다. if문 아래 코드 들여쓰기가 맞지 않았다. 공백을 맞춰서 해결했다”처럼 짧게 쓰면 됩니다. 나중에 비슷한 에러를 만났을 때 큰 도움이 됩니다.
저도 처음에는 에러를 해결하면 기분이 좋아서 바로 다음 공부로 넘어갔습니다. 그런데 며칠 뒤 같은 에러를 다시 만나고 또 검색했습니다. 그때부터 에러 노트를 만들기 시작했습니다. 신기하게도 기록을 남긴 에러는 다시 만났을 때 훨씬 덜 당황했습니다.
질문할 때는 상황을 함께 정리하기
혼자 해결이 안 될 때는 다른 사람에게 질문하는 것도 좋은 방법입니다. 다만 질문할 때는 “이거 왜 안 돼요?”라고만 하면 답변을 받기 어렵습니다. 어떤 코드를 작성했고, 어떤 에러 메시지가 나왔고, 무엇을 시도해봤는지 함께 정리해야 합니다.
질문을 잘 정리하는 과정 자체가 문제 해결에 도움이 되기도 합니다. 에러 메시지를 붙이고, 내가 작성한 코드를 다시 읽고, 어디까지 시도했는지 적다 보면 스스로 원인을 발견하는 경우도 많습니다.
좋은 질문에는 최소한 세 가지가 들어가면 좋습니다. 첫째, 어떤 작업을 하려 했는지입니다. 둘째, 어떤 에러 메시지가 나왔는지입니다. 셋째, 이미 시도해본 해결 방법입니다. 이렇게 적으면 답변하는 사람도 훨씬 정확하게 도와줄 수 있습니다.
개발 공부에서는 질문도 실력입니다. 질문을 잘한다는 것은 문제를 잘게 나누고, 상황을 정리할 수 있다는 뜻이기 때문입니다.
에러를 피하려고 하지 말고 익숙해지기
코딩 에러 메시지를 잘 읽는 법은 특별한 비법이 아닙니다. 마지막 줄을 확인하고, 파일명과 줄 번호를 찾고, 에러 이름을 보고, 방금 수정한 부분을 살펴보고, 필요한 경우 검색하고 기록하는 습관을 반복하는 것입니다.
처음에는 에러 하나 해결하는 데 30분, 1시간이 걸릴 수 있습니다. 하지만 괜찮습니다. 그 과정에서 문법을 더 깊게 이해하게 되고, 문제를 분석하는 힘이 생깁니다. 에러 없이 지나간 공부보다 직접 막히고 해결한 경험이 훨씬 오래 남습니다.
저도 처음에는 에러 메시지만 보면 겁이 났습니다. 그런데 이제는 에러가 나오면 먼저 마지막 줄을 보고, 어느 파일의 몇 번째 줄인지 확인합니다. 여전히 모르는 에러도 많지만, 적어도 당황해서 코드를 전부 지우지는 않게 됐습니다.
코딩을 공부하는 동안 에러는 계속 나옵니다. 중요한 것은 에러를 없애는 것이 아니라, 에러와 친해지는 것입니다. 에러 메시지는 개발자를 괴롭히는 적이 아니라, 문제를 찾게 도와주는 신호입니다. 오늘 만난 에러 하나를 해결했다면, 그만큼 실력이 쌓인 것입니다. 그러니 빨간 글씨가 나왔다고 멈추지 말고, 차분히 읽어보세요. 그 안에 해결의 힌트가 들어 있습니다.