에러와 버그는 무엇이 다를까요

무언가를 만들다 보면 에러와 버그라는 두 단어를 자주 듣게 됩니다. 둘 다 무언가 잘못됐다는 느낌이라 흔히 섞어 쓰지만, 사실은 다른 것을 가리킵니다. 그리고 이 둘을 구분할 줄 알면, 문제가 생겼을 때 무엇부터 해야 할지가 훨씬 또렷해집니다.

여기서는 에러와 버그가 어떻게 다른지, 어떤 종류가 있는지, 그리고 각각을 AI에게 어떻게 물어 고치는지를 프롬프트와 함께 정리해보겠습니다. 코드를 몰라도 이해할 수 있도록 일상의 비유를 곁들이겠습니다.

에러와 버그는 다릅니다

가장 쉬운 구분은 이렇습니다. 에러는 프로그램이 멈추면서 무언가 잘못됐다고 대놓고 알려주는 것입니다. 화면에 빨간 메시지가 뜨고 진행이 막힙니다. 반면 버그는 프로그램이 멈추지는 않는데, 결과가 내 의도와 다르게 나오는 것입니다. 아무 메시지도 없이 그냥 엉뚱하게 동작합니다.

둘의 관계를 한 문장으로 정리하면, 에러는 겉으로 드러난 신호이고 버그는 코드 속에 숨어 있는 원인입니다. 버그가 있어서 에러가 날 때도 있지만, 모든 버그가 에러를 내는 것은 아닙니다. 오히려 조용히 잘못된 결과만 내놓는 버그가 더 다루기 까다롭습니다. 멈추지 않으니, 무언가 잘못됐다는 사실조차 늦게 알게 되기 때문입니다.

에러는 세 가지 얼굴이 있습니다

에러처럼 보이는 것들도 성격이 조금씩 다릅니다. 요리에 비유하면 이해하기 쉽습니다.

앞의 두 가지는 그나마 다행입니다. 빨간 메시지가 떠서 어디가 문제인지 단서를 주니까요. 정작 골치 아픈 것은 세 번째, 논리 오류입니다. 아무 경고 없이 그저 틀린 답을 내놓기 때문에, 사람이 결과를 보고 어딘가 이상하다고 알아차려야만 발견됩니다.

흔히 만나는 에러와 버그

초보자가 자주 마주치는 것들을 일상의 비유로 묶어 보면 이렇습니다. 대부분 사소한 데서 비롯됩니다.

• 괄호나 따옴표를 안 닫음. 문장에 여는 괄호만 있고 닫는 괄호가 없는 것과 같아서, 컴퓨터가 어디까지가 한 덩어리인지 몰라 멈춥니다.
• 이름의 철자를 틀림. 전화번호부에서 살짝 틀린 이름으로 찾으면 못 찾듯이, 컴퓨터도 그런 것은 모른다고 합니다.
• 0으로 나누기. 케이크를 0명이서 나눠 먹으려는 것과 같아 질문 자체가 성립하지 않습니다.
• 하나 차이 실수. 10미터 울타리에 1미터 간격 기둥은 10개가 아니라 11개가 필요하듯, 시작과 끝을 하나 어긋나게 세는 흔한 실수입니다.
• 빈 것을 열어보기. 빈 택배 상자를 열어 물건을 꺼내려는 것처럼, 아무것도 없는 자리에서 무언가를 꺼내려다 멈춥니다.
• 끝나지 않는 반복. 고장 난 신호등이 영원히 빨간불이라 계속 기다리는 것처럼, 멈출 조건을 빠뜨려 같은 일을 끝없이 반복합니다.

버그라는 말은 진짜 벌레에서 왔습니다

버그가 영어로 벌레라는 것을 알고 나면, 왜 하필 벌레일까 궁금해집니다. 자주 회자되는 일화가 있습니다. 1947년, 초기 컴퓨터 안에서 진짜 나방 한 마리가 부품 사이에 끼어 오작동을 일으킨 일이 있었습니다. 당시 기록에는 그 나방을 테이프로 붙여두고 벌레가 발견된 실제 첫 사례라고 적어두었습니다.

부품에서 나방 발견. 벌레가 발견된 실제 첫 사례. (1947년, 초기 컴퓨터 작업 기록)

다만 흔한 오해 하나는 짚고 가야겠습니다. 이 나방 사건으로 버그라는 말이 처음 생긴 것은 아닙니다. 그 표현은 이미 한참 전부터 기계의 결함을 가리키는 말로 쓰이고 있었고, 발명가 에디슨도 1870년대 편지에서 같은 뜻으로 썼습니다. 1947년의 기록은 오히려 이미 쓰던 말에 진짜 벌레를 빗댄 농담에 가깝습니다. 어쨌든 결함을 벌레라 부르니, 그 벌레를 잡는 일을 디버그라고 부르게 됐습니다.

에러가 났을 때 쓰는 프롬프트

이제 실전입니다. 에러는 빨간 메시지라는 단서가 있으니, 그 단서를 최대한 살려 AI에게 물으면 됩니다. 메시지만 툭 던지기보다, 상황을 함께 적어주면 답이 훨씬 정확해집니다. 아래 프롬프트의 괄호를 내 상황으로 채워 쓰세요.

코드를 실행하다가 에러가 났습니다. 함께 원인을 찾아 고쳐 주세요.

[에러 메시지] (빨간 글씨를 처음부터 끝까지 그대로 붙여넣기)

[무엇을 하려던 중이었나] (예: 저장 버튼을 눌렀을 때)
[방금 무엇을 바꿨나] (예: 직전에 버튼 색을 바꿔달라고 요청함)
[원하는 결과] (예: 버튼을 누르면 글이 저장되는 것)

다음 순서로 도와 주세요.
1. 이 에러가 무슨 뜻인지 코드를 모르는 사람도 알 수 있게 한두 문장으로
   풀어 설명해 주세요.
2. 가장 가능성이 높은 원인이 무엇인지 짚어 주세요.
3. 어디를 어떻게 고치면 되는지 알려주고, 한 번에 한 군데만 고치도록
   안내해 주세요.
4. 고친 뒤 제가 무엇을 확인하면 해결됐는지 알 수 있는지도 알려 주세요.

핵심은 에러 메시지를 일부만 옮기지 말고 처음부터 끝까지 그대로 붙여넣는 것입니다. 사람 눈에는 암호 같아도 AI는 그 문장을 아주 잘 읽습니다. 그리고 무엇을 하려다 났는지, 방금 무엇을 바꿨는지를 함께 적으면 원인을 좁히는 데 큰 도움이 됩니다.

버그를 잡을 때 쓰는 프롬프트

버그는 다릅니다. 멈추지도 않고 메시지도 없으니, 붙여넣을 단서가 없습니다. 그래서 내가 직접 증상을 자세히 설명해줘야 합니다. 핵심은 기대한 동작과 실제 동작을 나란히 적고, 그 일이 어떻게 다시 일어나는지 알려주는 것입니다.

프로그램이 멈추지는 않는데, 결과가 제가 원한 대로 나오지 않습니다.
에러 메시지는 뜨지 않습니다. 함께 원인을 찾아 주세요.

[기대한 동작] (예: 할 일을 추가하면 목록 맨 위에 보여야 함)
[실제 동작] (예: 추가하면 목록에 안 보이고, 새로고침해야 보임)
[다시 일으키는 방법] (예: 1. 할 일 입력  2. 추가 버튼 클릭  3. 목록 확인)
[언제부터 이랬나] (예: 정렬 기능을 추가해달라고 한 뒤부터)

다음 순서로 도와 주세요.
1. 한꺼번에 고치지 말고, 원인일 만한 것을 가능성이 높은 순서로
   하나씩 짚어 주세요.
2. 각 원인이 맞는지 확인할 방법을 알려 주세요. 필요하면 특정 값을
   화면에 출력해보게 해서, 어디서부터 어긋나는지 같이 좁혀 갑시다.
3. 원인이 확인되기 전에는 코드를 고치지 말고, 먼저 원인을 함께
   특정한 다음 고쳐 주세요.
4. 추측만으로 여러 곳을 동시에 바꾸지 말아 주세요.

버그 프롬프트의 비결은 두 가지입니다. 첫째, 기대와 실제를 나란히 보여주면 AI가 어디서 어긋났는지 가늠하기 쉽습니다. 둘째, 곧장 고치게 하지 말고 원인부터 함께 특정하게 하는 것입니다. 버그는 추측으로 여기저기 고치다 보면 오히려 더 꼬이기 쉬운데, 원인을 먼저 좁히면 그런 헛수고를 줄일 수 있습니다.

한 번에 안 잡힐 때

한 번에 풀리지 않을 때도 많습니다. 그럴 때 지켜야 할 원칙은 단순합니다. 한 번에 한 가지만 바꾸고, 바꾼 뒤 같은 동작을 다시 해보며 효과를 확인하는 것입니다. 여러 군데를 동시에 손대면 무엇이 효과가 있었는지 알 수 없게 되어 더 헷갈립니다.

고칠수록 더 꼬인다면, 잘 되던 시점으로 되돌린 뒤 다시 시작하는 것이 빠를 때가 많습니다. 에러 메시지가 다른 내용으로 바뀌었다면 오히려 한 걸음 나아간 신호이니, 새 메시지를 다시 가져다 물으면 됩니다. 막혔을 때 빠져나오는 흐름은 따로 정리한 글이 있으니 함께 보시면 좋겠습니다.

정리하며

에러는 멈추면서 빨간 메시지로 알려주는 것이고, 버그는 멈추지 않으면서 결과만 틀리게 하는 것입니다. 에러는 메시지라는 단서를 그대로 살려 묻고, 버그는 기대와 실제를 나란히 적어 원인부터 함께 좁혀가면 됩니다. 둘을 구분하는 것만으로도 무엇부터 해야 할지가 분명해집니다.

무언가를 만드는 사람이라면 에러와 버그는 매일 마주하는 과정의 일부입니다. 숙련된 사람이라고 안 만나는 것이 아니라, 만났을 때 침착하게 다루는 데 익숙할 뿐입니다. 빨간 글씨가 떠도, 결과가 이상해도, 단서를 모아 차근차근 물으면 대부분은 결국 넘어갑니다.

참고한 글

• 에러의 종류, 문법·실행·논리 오류의 차이 (Khan Academy, LaunchCode Education)
• 에러와 버그, 결함의 관계 (IEEE/ISO 24765 기반 해설, Wikipedia Software bug)
• 버그라는 말의 유래와 1947년 나방 일화, 통념 바로잡기 (Smithsonian, IEEE Spectrum, JSTOR Daily)
• 디버깅의 기본 사고방식, 원인 가설 세우기 (MIT 6.005, freeCodeCamp)