글자 하나 'j'가 저녁을 통째로 날렸다 — 한 글자 버그가 무서운 이유

글자 하나가 저녁 시간을 통째로 날렸다

개발하다 보면 누구나 한 번쯤 겪는 일이 있어요. 분명 어제까지 잘 돌던 코드가 갑자기 안 되는데, 몇 시간을 헤매고 나서야 원인이 '오타 한 글자'였던 경험 말이에요. 이번에 풀어볼 이야기도 딱 그런 종류예요. 길 잃은 'j' 한 글자가 한 개발자의 평화로운 저녁을 통째로 망쳐버린 디버깅 분투기인데요. 사연 자체보다도, 왜 이런 사소한 한 글자가 그렇게까지 사람을 괴롭히는지, 그리고 어떻게 빨리 잡아낼지를 같이 들여다보면 누구에게나 도움이 될 거예요.

한 글자 버그가 유독 잔인한 이유

사실 오타가 문법 오류(syntax error)를 내주면 차라리 고마운 거예요. 컴파일러나 인터프리터가 '여기 이상해요!'하고 빨간 줄을 그어주니까 바로 찾거든요. 진짜 무서운 건, 오타가 났는데도 코드가 '문법적으로는 멀쩡한' 경우예요.

예를 들어볼게요. 비교하려고 ==를 써야 하는데 실수로 =(대입) 하나만 쓰면, 많은 언어에서 에러 없이 그냥 돌아가버려요. 의도와는 정반대로요. 마찬가지로 변수 이름이나 식 끝에 엉뚱한 글자(이를테면 'j')가 슬쩍 끼어들었는데 그게 우연히 다른 유효한 이름이거나 유효한 토큰이 되어버리면, 프로그램은 아무 불평 없이 '틀린 동작'을 조용히 수행해요. 에러 메시지가 안 뜨니까 우리는 엉뚱한 곳만 몇 시간씩 들여다보게 되죠. 저녁이 날아가는 전형적인 시나리오예요.

여기에 더 음험한 친구들도 있어요. 눈에 안 보이는 문자들이에요. 웹페이지에서 코드를 복사했더니 따라온 제로폭 공백(zero-width space), 한글 입력 중에 섞여 들어간 전각 공백, 자동완성이 멋대로 바꿔놓은 스마트 따옴표(' ' 같은 둥근 따옴표) 같은 것들이죠. 화면엔 멀쩡해 보이는데 컴퓨터한테는 전혀 다른 글자라, 눈으로 아무리 째려봐도 안 보여요.

그래서 어떻게 잡느냐면요

경험 많은 선배들이 쓰는 방법은 의외로 단순해요. 첫째, '의심 범위를 절반씩 좁히기'예요. 코드의 절반을 잠시 주석 처리해서 문제가 사라지는지 보고, 사라지면 나머지 절반에 범인이 있는 거죠. 이걸 반복하면 수십 줄도 금방 한두 줄로 좁혀져요. 둘째, git을 쓴다면 git diff로 '내가 마지막에 뭘 건드렸나'부터 보세요. 잘 되던 게 안 되면 십중팔구 최근에 바꾼 곳에 답이 있어요. 더 오래 묵은 버그는 git bisect로 '언제부터 깨졌는지'를 이진 탐색으로 추적할 수 있고요. 셋째, 보이지 않는 문자가 의심되면 에디터의 '공백·특수문자 표시' 기능을 켜거나, 해당 줄을 통째로 지우고 직접 타이핑해서 다시 써보세요. 복사 과정에서 묻은 유령 문자를 가장 확실하게 털어내는 방법이에요.

한국 개발자에게

이런 한 글자 버그는 언어를 가리지 않아요. 다만 우리에겐 한글·전각 문자 환경이라는 변수가 하나 더 있어서, 전각 공백이나 한영 전환 실수가 만드는 함정이 영어권보다 잦은 편이에요. 그래서 평소에 린터(linter, 코드 잠재 오류를 자동으로 잡아주는 도구)와 포매터를 켜두고, 의미 없는 한 글자 차이도 걸러내도록 세팅해두는 게 결국 가장 싼 예방책이에요. 코드 리뷰 때 '왜 됐는지보다 왜 안 됐는지'를 함께 보는 습관도 큰 도움이 되고요.

마무리

핵심은 이거예요. 큰 장애의 원인이 거창할 거라는 선입견을 버리고, 가장 사소한 것부터 의심하라는 것. 버그 잡느라 날린 저녁이 가장 기억에 남는 법이죠. 여러분의 '한 글자 때문에 밤새운' 무용담은 무엇이었나요? 댓글로 풀어놓으면 누군가에겐 내일의 시간을 아껴줄 거예요.