여는 글 — ???만 남은 이력서
이런 경험, 한 번쯤 있으시죠? 공들여 쓴 이력서를 메일로 보냈는데, 상대방이 이렇게
답장을 합니다. “혹시 파일이 깨져서 왔는데요?” 열어보니 이름도, 경력도, 자기소개도
전부 ???와 � 같은 이상한 기호로 뒤덮여 있어요.
분명 내 화면에선 멀쩡했습니다. 한 글자도 안 틀렸어요. 그런데 상대 화면에선 글자가 증발했습니다. 대체 그 사이에서 무슨 일이 벌어진 걸까요?
개발자라면 이 장면을 코드에서도 만납니다. DB에 잘 저장한 한글이 조회하면 ???로
나오고, 잘 되던 API가 이모지 하나에 터지고, 로그에 밸린 같은 외계어가 찍혀요.
우리는 이 현상에 이름까지 붙여놨습니다. 모지바케(mojibake), 깨진 글자.
여기서 근본적인 질문이 하나 나옵니다. 컴퓨터는 0과 1밖에 모르는데, 대체 ‘가’나
‘A’나 ’😀’ 같은 글자를 어떻게 담고 있는 걸까요? 그리고 왜, 멀쩡하던 글자가 남의
화면에서 깨지는 걸까요?
답은 하나예요. 글자를 숫자로 바꾸는 약속(인코딩)이, 보내는 쪽과 받는 쪽에서 달랐기 때문입니다. 내가 “이 숫자는 ‘가’야”라고 저장했는데, 상대는 그 숫자를 다른 글자로 읽은 거죠. 같은 바이트를 서로 다른 사투리로 해석한 겁니다.
이 책은 그 약속의 역사입니다. 봉화와 모스 부호처럼 글자를 신호로 나르던 시절부터,
미국이 128칸으로 정한 ASCII, 각 나라가 제 글자를 욱여넣으며 벌어진 “사투리 전쟁”,
그리고 마침내 온 세상의 글자를 하나의 표에 담은 유니코드와, 인터넷을 정복한 UTF-8까지.
나아가 그 약속들이 현장에서 어떻게 어긋나 무엇을 터뜨리는지 — String.length가
거짓말하고 MySQL의 utf8이 진짜 UTF-8이 아닌 이유까지 — 이야기로 따라갑니다.
마지막 장을 덮을 때, ???로 깨진 글자를 봐도 더 이상 막막하지 않을 거예요. 어느
단계에서 어떤 약속이 어긋났는지 짚어낼 수 있을 테니까요. 글자가 깨지는 건 미스터리가
아니라, 알고 나면 당연한 일입니다.
자, 컴퓨터가 글자라는 걸 아예 몰랐던 시절부터 가봅시다.