며칠 전 기술 그룹에서 누군가 불평하는 것을 봤다. 요즘 AI가 코드를 이렇게 강력하게 작성하는데, Copilot, Cursor를 켜면 코드가 수도꼭지처럼 쏟아져 나오는데, 왜 아직도 베테랑 프로그래머가 거기서 ASCII 코드표를 뒤지고 있냐고? 이거 고대 시대의 물건 아니냐고? 그룹은 즉시 폭발했다. 맞장구치는 사람도 있었고, 어떤 노형은 담담하게 한마디 했다. "언젠가 새벽 3시까지 디버깅을 해보면, 왜 그런지 알게 될 거야."
솔직히 말해서, ASCII 코드표라는 것은 보기에는 정말 별것 아니다. 표 하나, 128개 문자, 0부터 127까지, 각 숫자가 하나의 문자에 대응한다. 스페이스를 치면 32, 줄바꿈을 치면 10, 대문자 A는 65, 소문자 a는 97. 이게 전부다. 초등학교 정보 수업에서 아마 다 배웠을 것이다. 하지만 문제는, 실제로 일할 때, 그것이 생각보다 훨씬 중요하다는 것이다.
AI가 코드를 작성하는 것은 정말 대단하다. 정렬 알고리즘을 생성하라고 하면 1초 만에 주석까지 붙여서 써준다. REST API를 작성하라고 하면 에러 처리까지 추가해준다. 하지만 AI에게는 문제가 하나 있다. 때때로 '지어낸다'는 것이다. 특히 문자 인코딩을 처리할 때, 겉보기에는 문제없어 보이는 코드를 생성할 수 있고, 실행해도 오류가 나지 않지만, 결과가 틀릴 수 있다. 예를 들어 텍스트 파일을 처리하라고 하면, 줄바꿈 문자를 \n으로 매칭하는데, 실제 파일에는 \r\n이 들어있다. 이 코드는 Linux에서는 잘 돌아가지만, Windows에서는 문제가 생긴다. 이때 어떻게 할까? ASCII 코드표를 뒤진다. 13은 캐리지 리턴, 10은 라인 피드, 16진수 편집기에서 0D 0A라는 문자열을 보면 즉시 문제가 어디인지 알 수 있다.
더 숨겨진 경우도 있다. 예를 들어 오래된 시스템을 디버깅할 때, 인터페이스가 반환하는 JSON에 필드가 있는데, 분명히 비어 보이지만 프로그램은 비어 있지 않다고 판단한다. 출력해보면 \u00A0이 들어있다. 이것은 줄 바꿈 없는 공백(Non-breaking space)이라고 하며, ASCII 코드표에서 160에 해당한다. 육안으로는 전혀 알 수 없지만, 코드 로직이 이것 때문에 막힌다. 이때 ASCII 코드표를 꺼내서 확인해보면, 아, 160이지 32가 아니구나. 판단 조건을 수정하면 문제 해결. AI에만 의존하면, 아마 큰 우회로를 돌려줄 것이고, 결국에는 스스로 표를 찾아야 한다.
베테랑 프로그래머가 ASCII 코드표를 뒤지는 것은 AI를 못 써서가 아니라, 어떤 것들은 AI를 믿을 수 없다는 것을 알기 때문이다. AI가 잘하는 것은 패턴 인식과 코드 생성이지만, 저수준 세부 사항을 파악하는 능력은 때때로 표 하나만 못하다. ASCII 코드표는 프로그래머의 구구단과 같다. 보기에는 간단하지만, 결정적인 순간에 목숨을 구할 수 있다. 코드를 오래 작성하다 보면, 많은 이상한 문제들이 결국 문자 인코딩으로 귀결된다는 것을 알게 될 것이다. 깨진 문자, 잘림, 비교 실패, 정규식 불일치, 십중팔구 ASCII 코드와 관련이 있다.
그리고 표를 뒤지는 일 자체도 그렇게 힘들지 않다. 브라우저를 열고 ASCII 코드표 조회를 검색하면 1초면 된다. 아니면 그냥 몇 가지 자주 쓰는 것을 외워두자: 32는 공백, 48에서 57은 숫자 0에서 9, 65에서 90은 대문자, 97에서 122는 소문자. 이것들을 기억하면, 평소 16진수 데이터를 볼 때 마음이 든든하다. 베테랑 프로그래머는 새로운 도구를 배척하는 것이 아니라, 어떤 기본기가 버려져서는 안 된다는 것을 알 뿐이다. AI가 아무리 강력해도 그것은 도구일 뿐이며, 진정한 판단은 사람이 해야 한다. 문자 인코딩도 제대로 파악하지 못하는데, AI가 생성한 코드를 감히 프로덕션 환경에 바로 올릴 수 있겠는가?
그러니 베테랑 프로그래머가 ASCII 코드표를 뒤진다고 비웃지 마라. 그들이 뒤지는 것은 표가 아니라, 경험이고, 자신감이다. 언젠가 숨겨진 \r이나 \u00A0 때문에 인생을 의심할 정도로 고생하게 되면, 당신도 조용히 그 표를 열게 될 것이다.