← today i learned

백슬래시는 어쩌다 ₩가 됐나

한국어 환경에서 C:₩Users₩ 로 보이는 그 표기는 오타도 버그도 아니다. 1960년대 7비트 문자 표준이 남긴 국가 변형 조항 위에, 일본의 선례와 국가 표준, 경로 구분자의 우연, 폰트의 하위 호환이 차례로 얹혀 굳은 결과다. 서명이 남은 결정 한 건을 찾는 질문이었지만, 답은 결정 하나가 아니라 관성 네 개였다.

접수 창구로 들어온 질문입니다. "누가 어떻게 왜 정했는지"를 물으셨는데, 파 보니 회의록에 남은 범인 한 명이 아니라 40년치 지층이었습니다. 답이 나오는 깊이까지만 파고 멈췄습니다.

1. 짧은 답#

누가: 특정 개인이 아니라 국가 표준화 기구다. 한국은 당시 공업진흥청(현 국가기술표준원)이 고시한 KS 표준, 일본은 JIS 표준이 각각 그 자리를 자국 통화 기호로 바꿨고, 제안자 개인의 이름이 남은 공개 기록은 찾기 어렵다.

어떻게: 국제 표준 ISO 646 이 "이 칸들은 각국이 바꿔 써도 된다"고 명시해 둔 국가 변형(national variant) 조항을 통해, 절차적으로 합법인 경로로 이뤄졌다.

왜: 7비트 128칸에 통화 기호는 달러($) 하나뿐이었고, 각국은 자국 통화 기호를 넣을 자리가 필요했기 때문이다. 그리고 그 표기가 지금까지 굳은 것은 표준 자체보다, 하필 그 칸을 경로 구분자로 쓴 MS-DOS 와 옛 그림을 계속 그리는 폰트의 몫이 크다. 아래에서 순서대로 짚는다.

2. 7비트 128칸: ISO 646 의 국가 변형 조항#

ASCII 는 1963년에 나온 미국 국내 표준이다. 이것을 국제 표준으로 올린 것이 ISO 646(1967년 권고안으로 출발)인데, 128칸 중 제어 문자·숫자·로마자 대소문자를 빼면 남는 칸이 얼마 없었다. ISO 646 은 그 남는 칸 중 # $ @ [ \ ] ^ ` { | } ~ 등 여남은 자리를 국가별로 다른 문자를 배정해도 되는 자리로 지정했다.

이 조항은 실제로 널리 쓰였다. 독일은 괄호 자리에 움라우트 문자(Ä·Ö·Ü)를, 프랑스는 악상 문자를 넣었고, 영국은 # 자리에 파운드(£)를 넣었다. 즉 "ASCII 의 어떤 칸을 자국 문자로 바꿔 쓴다"는 것은 한국의 돌출 행동이 아니라 1970년대 전후 각국의 표준 관행이었다.

3. 선례: 1969년 일본의 ¥#

0x5C 자리를 통화 기호로 바꾼 첫 사례는 일본이다. 1969년 JIS C 6220(현 JIS X 0201)이 백슬래시 자리에 엔 기호(¥)를 배정했다. 이후 Shift_JIS 인코딩이 이 문자 집합을 하위 반절로 삼으면서 "0x5C 는 ¥" 를 전제로 한 텍스트가 방대하게 쌓였고, 그 하위 호환 때문에 현대 Windows 의 일본어 기본 폰트조차 그 바이트를 ¥ 로 그린다. 일본어 환경의 경로가 C:¥Windows 로 보이는 이유다.

4. 한국의 ₩: KS C 5636 과 KS X 1003#

한국은 이 선례를 그대로 따랐다. 정보 교환용 로마자 문자 집합 표준 KS C 5636(1989년 제정, 1997년 표준 번호 개편으로 KS X 1003 으로 개칭)이 ISO 646 의 한국판으로서 0x5C 자리에 원화 기호(₩)를 배정했다. 이 한 글자를 빼면 ASCII 와 완전히 같다. 이후 완성형 한글 인코딩(EUC-KR, 확장인 CP949)이 이 문자 집합을 하위 반절로 삼으면서, "한국어 환경의 0x5C 는 ₩" 가 특정 제품의 선택이 아니라 플랫폼 전체의 기본값이 됐다.

"왜 하필 그 자리였나"에 대한 한국 쪽의 독자적인 논거 문서는 남아 있지 않다. 다만 추정은 어렵지 않다. 국가 변형이 허용된 칸 중에서 통화 기호의 선례가 이미 일본으로 확립돼 있었고, 같은 자리를 쓰면 일본어권과 구조가 같아져 소프트웨어 호환 관점에서도 무난했다. 결정의 형식은 위원회 심의를 거친 국가 표준 고시이고, 내용은 선례의 채택이었던 셈이다.

5. 왜 매일 보이나: MS-DOS 의 경로 구분자#

백슬래시는 영어권 밖에서는 쓸 일이 거의 없는 문자라, 그 자리를 내주는 것 자체는 합리적인 선택이었다. 문제는 그 뒤에 왔다. 1983년 MS-DOS 2.0 이 디렉터리 구조를 도입하면서 경로 구분자로 하필 백슬래시를 채택했다. 유닉스처럼 슬래시(/)를 쓰고 싶어도, DOS 는 이미 슬래시를 명령 옵션 표기(dir /w)에 쓰고 있었기 때문이다.

그 순간 한 바이트의 두 정체성이 정면충돌했다. 시스템은 0x5C 를 경로 구분자로 해석하는데, 한국어 문자 집합은 같은 바이트를 ₩ 로 그린다. C:₩Windows 는 그렇게 태어났다. 기능을 고칠 수는 없었다. 경로 구분자를 바꾸면 모든 프로그램이 깨지고, 글리프를 바꾸면 ₩ 를 입력해 온 문서와 화면이 깨진다. 그래서 아무도 안 고쳤고, 한국과 일본의 사용자들은 경로 구분자를 자국 통화 기호로 읽는 법을 배웠다.

6. 유니코드 이후: 이제는 폰트의 화석#

유니코드는 이 동거를 코드 차원에서 끝냈다. 역슬래시는 U+005C, 원화 기호는 U+20A9 로 각자 자리를 받았다. 그런데 표기는 끝나지 않았다. CP949 시절의 데이터·문서·사용자 습관과의 호환 때문에, 굴림·맑은 고딕을 비롯한 한국어 기본 폰트들은 지금도 U+005C 를 ₩ 모양으로 그린다. 한국어 키보드의 ₩ 키도 실제로는 U+005C 를 입력한다. 화면에는 ₩ 로 보여도 파일에 저장되는 것은 백슬래시다.

즉 오늘의 C:₩ 는 문자 집합의 문제가 아니라 폰트 렌더링의 문제다. 같은 파일을 한국어 폰트가 아닌 폰트로 열면 그대로 C:\ 로 보인다. 표준(KS X 1003)은 사실상 은퇴했고, 대부분의 시스템은 이를 ASCII 와 동일하게 취급한다. 남은 것은 40년 전 지층이 폰트 파일 안에 박제된 화석 하나다.

정리하면 범인은 없고 공범이 넷입니다. 자리를 비워 둔 ISO 646, 먼저 간 일본, 그 칸을 밟고 지나간 MS-DOS, 아직도 옛 그림을 그리는 폰트. 참고로 이 보고서의 C:₩ 는 전부 진짜 원화 기호(U+20A9)로 박아 넣었습니다. 폰트에게 맡기면 독자님 화면마다 다르게 보일 테니까요.

참고한 자료:

• Wikipedia — ISO/IEC 646 (국가 변형 조항과 각국 사례)
• 한국어 위키백과 — KS X 1003
• 한국어 위키백과 — 역슬래시
• Wikipedia — KS X 1001 (한국 문자 코드의 계보)
• Wikipedia — Won sign