알리의 접근성 연구소 로고알리의 접근성 연구소

방문자 카운터

접근성 브리핑 제26호

79 min read

들어가며

같은 한글을 담은 텍스트 파일을 Windows 메모장에서 열었습니다. 화면 읽기 프로그램인 센스리더로 들어 보니 하나는 별일 없이 읽어 주는데, 다른 하나는 초성·중성·종성으로 나뉘어 읽어 주었고, 또 다른 파일은 글자 자체가 깨졌습니다. 센스리더는 메모장이 해석해 화면에 내놓은 결과를 그대로 읽었을 뿐입니다.

흔히 ‘자소 분리’라고 부르는 현상과 글자 자체가 깨진 경우는 다른 문제입니다. 초성·중성·종성으로 따로 읽어 준 파일에는 한글을 이루는 정보가 그대로 남아 있었습니다. 다만 메모장과 센스리더를 거치는 동안 한 음절로 묶이지 못했습니다. 글자 자체가 깨진 파일은 저장된 값을 풀이하는 단계부터 어긋나 다른 문자열이 됐습니다.

하지만 사용자가 마주하는 상황은 비슷합니다. 익숙한 한글이 더는 익숙하게 들리지 않습니다. 우리는 자소 분리나 깨진 글자들을 둘 다 흔히 ‘한글 깨짐’이라고 부릅니다.

컴퓨터에서 한글이 나타난다고 해서 컴퓨터가 그 한글을 제대로 다루고 있는 것은 아닙니다. 한 음절을 어떤 값으로 저장했는지, 여는 프로그램이 어느 문자표를 골랐는지, 초성·중성·종성을 한 글자로 묶는지에 따라 검색과 정렬, 커서 이동과 삭제, 음성 출력과 점역 결과가 달라집니다. 화면에는 똑같이 ‘한글’로 나타나도 컴퓨터 안에서는 서로 다른 값일 수 있습니다.

지난 제25호에서는 같은 점자처럼 보여도 파일 형식과 문서 구조가 다르면 기기와 프로그램 사이에서 온전히 내용을 보존하기 어렵다는 문제를 다뤘습니다. 이번에는 그보다 한 층 아래로, 좀 더 ‘기계에 가까운’ 내용으로 내려갑니다.

컴퓨터는 한글을 화면에 그리는 데서 그치지 않고, 같은 문자로 알아보고 끝까지 전달하고 있을까요?

제26호 - 2026년 8월 25일(화)

브리핑 1. 영어의 문자표에 한글을 싣다 — 한글 코드의 춘추전국시대

오늘날 컴퓨터에서 한글을 입력하면 글자가 자연스럽게 모아집니다. 자음과 모음을 차례로 눌러도 화면에는 네모난 음절 하나가 나타납니다. ‘모아쓰기’가 이루어지는 이 익숙한 장면이 처음부터 가능했던 것은 아닙니다.

초기 컴퓨터의 문자 환경은 영어를 중심으로 만들어졌습니다. ASCII에는 한글이 들어갈 자리가 없었습니다.1 한 바이트가 나타낼 수 있는 값만으로는 현대 한글의 모든 음절 조합을 담기 어려웠습니다.2 자음과 모음을 이어 쓰는 데서 끝나지 않고 초성·중성·종성을 한 음절 덩어리로 모아 보여 주어야 했습니다.

1970년대 초에는 한글 자모를 ASCII 문자에 대응시킨 여러 N바이트 코드가 등장했습니다. 한글 구간의 시작과 끝은 제어 문자로 표시하고, 초성·중성·종성에 해당하는 바이트는 차례로 보냈습니다. 7비트 통신망에서도 한글을 주고받을 수 있었지만 업체마다 자모에 배정한 값이 달랐습니다. 당시 한글 부호계가 27종류까지 난립했다는 것이 국립국어원의 회고 자료에 나온 설명입니다.3

같은 글자를 입력해도 어느 회사의 컴퓨터에서 입력했느냐에 따라 저장된 값이 달라졌습니다. A 회사에서 작성한 문서를 B 회사의 컴퓨터로 옮기면 다른 글자가 나오거나 아예 읽지 못했습니다. 음절마다 필요한 바이트 수가 달랐고 어디까지가 한 글자인지 알아내는 규칙도 프로그램마다 제각각이었습니다.

3바이트 조합형은 초성·중성·종성에 한 바이트씩을 배정했습니다. 뒤이어 나온 2바이트 조합형은 한 값 안에 초성·중성·종성 비트 영역을 나누어 넣었습니다. 한글의 짜임을 코드에서 바로 읽을 수 있었고 현대 한글을 폭넓게 표현할 수 있었습니다. 하지만 ‘조합형’이라는 이름만 같다고 같은 문자표였던 것은 아닙니다. 제조사마다 비트 배열과 세부 값이 다르면 다른 컴퓨터에서 다시 읽을 수 없었습니다.

여기에는 한글을 컴퓨터에 올리기 위한 치열한 창의성이 있었습니다. 운영체제와 글꼴, 입력기와 출력 장치가 한글을 기본으로 지원하지 않던 때에 개발자들은 문자표부터 화면에 음절을 그리는 방식까지 밑바닥부터 직접 만들었습니다. 아래아를 포함한 옛한글과 한자를 다루고, 프린터에 한국어 문서를 출력하기 위한 기반도 이 과정에서 쌓였습니다.

하지만 접근성의 관점에서 보면 한 단계가 더 필요했습니다. 글자를 화면에 띄우는 것만으로는 부족했습니다. 화면에 나온 글자를 음성으로 읽거나 점자로 바꾸려면 보조공학기술도 그 프로그램의 한글 코드를 알아야 했습니다. 문자의 값과 음절 경계를 모르면 화면 읽기 프로그램은 어느 부분이 한 글자인지, 점역 프로그램은 어느 자모가 한 음절을 이루는지 판단하기 어렵습니다.

초기 한글 코드의 역사는 ‘표현할 수 있음’과 ‘함께 읽을 수 있음’이 다르다는 사실을 먼저 보여 줍니다. 한글을 화면에 띄우는 데 성공한 다음에야 다른 컴퓨터와 다른 프로그램에서도 같은 한글로 읽히는가 하는 ‘호환성’ 문제가 보이기 시작했습니다.

브리핑 2. ‘똠양꿍’, ‘펲시’를 못 쓰는 표준? — 조합형과 완성형의 갈등

회사마다 다른 한글 코드를 쓰는 상황에서 공통 표준은 꼭 필요했습니다. 서로 다른 컴퓨터가 같은 문자표를 보고 한글을 주고받을 수 있어야 행정망도, 교육용 컴퓨터도, 통신 서비스도 넓어질 수 있었습니다.

1987년 KS C 5601 완성형은 2바이트 문자 영역에 자주 쓰는 한글 2,350자와 한자 4,888자, 특수문자를 배치했습니다. ISO 2022 계열의 정보 교환 구조와 호환하면서 한글과 한자를 함께 싣는 방식이었습니다. 행정전산망과 교육용 컴퓨터, 운영체제가 이 표준을 채택하면서 서로 다른 시스템 사이에 문서를 주고받을 공통 기반이 마련된 것입니다.4

그런데 표준이 생겼는데도 모든 한글을 쓸 수는 없었습니다.

현대 한글 음절의 가능한 조합은 11,172개인데 완성형 표에는 2,350자만 들어갔습니다. ‘똠’, ‘펲’, ‘찦’처럼 표에 없는 글자는 바로 저장할 수 없었습니다. 이름과 방언, 사전과 문학 작품, 형태소 분석처럼 표준이 예상한 사용 빈도 바깥의 글자를 다루는 사람은 다시 예외를 감당해야 했습니다. 표준을 만든 쪽도 문자 수 부족과 자소 분석의 어려움을 당시부터 인정했습니다.5

조합형은 이 빈자리를 비판했습니다. 초성·중성·종성의 조합 원리를 코드에 담으면 2,350자 목록에 없는 음절도 표현할 수 있었습니다. 한글을 글자 목록이 아니라 자모가 결합하는 문자 체계로 다룬다는 점에서도 설득력이 있었습니다. 그렇다고 조합형 하나가 모든 호환성 문제를 해결한 것은 아닙니다. 기존 완성형 문서와 바이트 배열이 달랐고, 여러 상용 조합형 사이에도 차이가 남았습니다.6

여기서 역사를 ‘조합형은 한글을 지켰고 완성형은 한글을 망쳤다’는 대결로만 읽으면 중요한 부분을 놓치고 맙니다. 완성형은 표현 범위를 줄이는 대가를 치르면서 정보 교환과 국제 규격 안의 공통 자리를 어떻게든 만들어 보려 했습니다. 조합형은 한글의 구성 원리와 넓은 표현 범위를 살렸지만 이미 쌓인 문서와 다른 시스템 사이의 호환을 따로 풀어야 했습니다.

갈등의 중심에 있었던 것은 악의가 아니라 표현력, 상호운용성, 기존 문서의 보존이었습니다.7

조합형 한글이 1992년에 갑자기 등장한 것은 아닙니다. 표준이 제정되기 전부터 조합형 방식은 이미 쓰이고 있었습니다. 1982년판 부속서부터 조합형 부호계가 있었고, 1992년판에서는 그 비트 배열을 당시 널리 쓰이던 상용 조합형에 맞게 바꿨습니다. 본문의 완성형 부호표와 나란한 두 번째 본표준이라기보다 부속서의 보조 부호계였습니다.8

Windows 95에서 사용한 통합형 한글 코드 UHC, 곧 코드 페이지 949는 다른 방식으로 빈자리를 메웠습니다. 기존 완성형 2,350자의 바이트 위치는 유지하면서 비어 있는 2바이트 영역에 나머지 현대 한글 음절을 끼워 넣어 기존 문서를 버리지 않고 표현 범위를 넓히려 했습니다. Microsoft의 현재 코드 페이지 표에도 949는 ‘Unified Hangul Code’, 1361은 ‘Johab’으로 따로 남아 있습니다.9

EUC-KR과 CP949를 같은 말처럼 쓰는 경우가 많지만 둘의 범위는 다릅니다. EUC-KR의 기본 한글 집합은 KS X 1001의 2,350음절이고 CP949는 그 호환 영역을 유지하면서 나머지 현대 한글을 더합니다. 웹 브라우저는 오래된 페이지를 실제로 열기 위해 레이블을 느슨하게 처리하기도 합니다. WHATWG 인코딩 표준이 오래된 명칭과 브라우저의 실제 동작을 한데 정의하면서도 새 문서와 새 프로토콜에는 UTF-8을 요구하는 이유입니다.10

우리가 마주하는 텍스트 파일이 깨지는 현상은 이 역사가 현재까지 남아 있다는 증거입니다. 텍스트 파일에는 글자 자체가 들어 있는 것이 아니라 바이트열이 들어 있습니다. 프로그램이 CP949 바이트를 UTF-8로 읽으면 올바른 조합을 찾지 못해 대체문자 �를 내놓거나 파일을 열지 못합니다. UTF-8 바이트를 CP949로 읽으면 전혀 다른 한글·한자·기호로 바뀐 모지바케가 생깁니다.11

저 알리는 화면 읽기 프로그램과 점역 프로그램 등 보조공학기술이 다양한 한글 코드가 들어 있는 문서를 어떻게 인식하고 반응하는지 시험해 보았습니다. 이번 시험에서도 Johab 코드 페이지 1361로 만든 파일을 Windows 메모장에서 열자 글자가 깨졌습니다. 센스리더도 그 깨진 화면 내용을 읽었습니다. 같은 파일을 아래아한글에서 KSSM으로 지정해 열었을 때는 원문이 나타났습니다. 바이트가 손상된 것이 아니라 어느 문자표로 해석하느냐가 달랐습니다.

파일을 열었을 때 깨진 텍스트를 마주한 사용자가 해야 할 일은 결코 가볍지 않습니다.

파일이 어느 시기에 어느 프로그램에서 만들어졌는지 추정해 여러 인코딩으로 열어 보고, 올바른 문자열이 나타나면 다시 저장해야 합니다. 잘못 해석한 상태로 덮어쓰면 원래 바이트를 되살리기 더 어려워집니다. 오래된 한글 문서의 접근성은 ‘최신 프로그램으로 열린다’는 한 문장이 아니라 원래 문자표를 알아내고, 손실 없이 변환하고, 변환 결과를 확인할 수 있는가로 판단해야 합니다.

브리핑 3. 한글을 가장 잘 쓰던 프로그램의 그림자 — 아래아한글과 HWP

문자표가 같아져도 그 한글을 담은 문서가 특정 프로그램 안에만 있으면 같은 문제가 반복됩니다. 한글 코드를 말할 때 아래아한글을 빼놓기 어려운 이유입니다. 당시 영어권 워드프로세서는 한국어 입력과 조판을 충분히 다루지 못했습니다. 아래아한글은 자모 조합과 한자, 옛한글, 세로쓰기와 한국식 문서 편집을 제품 안에서 해결했습니다. 운영체제보다 먼저 한글 사용자의 필요를 읽고 현실적인 작업장을 만든 셈입니다.

저도 이 역사를 단순히 ‘폐쇄형 포맷의 시작’이라 말하고 싶지는 않습니다. 한글을 입력하고 인쇄하고 보존하는 일이 당연하지 않았던 그 시기에, 아래아한글이 해낸 일은 절대로 과소평가해서는 안 된다고 생각합니다. 공공기관과 학교, 출판과 연구 현장에 HWP 문서가 깊이 들어간 데에는 한글을 제대로 다룰 수 있다는 실무자들의 경험이 큰 역할을 했습니다. 그렇게 아래아한글과 HWP는 몇 번의 위기를 지나오며 대한민국 워드프로세서 시장을 공고하게 지켰습니다.12

기존 HWP는 바이너리 복합 문서 형식입니다. 문서 내용과 서식, 개체가 사람이 바로 읽기 어려운 구조로 들어 있습니다. 세부 명세도 한동안 공개되지 않다가 2010년에야 공개됐습니다. 한컴의 포맷 설명 역시 HWP가 특정 소프트웨어에 의존하는 방식으로 설계됐다는 점을 밝힙니다.13 명세가 공개되면 다른 프로그램이 파일을 분석할 길은 열리지만 다른 운영체제의 편집기와 화면 읽기 프로그램이 한컴오피스와 같은 수준으로 읽고 고칠 수 있게 되는 것은 또 다른 일입니다.

화면 읽기 접근성도 일반적인 Windows 접근성 인터페이스 하나로 해결되지 않았습니다. 한컴은 센스리더 개발사와 협업해 HncAA라는 별도의 접근성 인터페이스를 제공했고, 문서 내부의 글자와 개체, 편집 정보를 화면 읽기 프로그램에 전달했습니다.14 이 협업 덕분에 시각장애인은 HWP 문서를 읽고 작성하며 국내 문서 업무에 참여할 수 있었습니다. 한국어 문서 환경과 국내 화면 읽기 프로그램 사이에 오랫동안 쌓인 중요한 자산입니다.

하지만 대대로 물려받은 이 자산에는 그림자도 있습니다. 특정 프로그램과 버전, 접근성 모듈의 조합에 기대는 구조이기도 합니다. 제22호에서 살펴본 것처럼 본문을 읽을 수 있어도 대화상자의 현재 값이나 편집 상태를 확인하지 못하면 사용자는 작업을 끝낼 수 없습니다. 파일을 여는 데 성공해도 서식을 확인하고 표와 개체를 편집하고 오류 없이 다시 저장할 수 없다면 문서 업무의 일부만 열린 셈입니다.

HWPX는 이 문제를 다른 방향에서 풉니다. HWPX는 KS X 6101 OWPML을 따르는 XML 기반 개방형 형식입니다. ZIP 패키지 안에 문서 내용과 구조, 설정과 리소스를 나누어 담습니다.15 특정 프로그램의 내부 메모리에만 있던 문서 정보를 공개된 구조로 표현하면 다른 프로그램과 변환 도구가 내용을 분석할 가능성이 커집니다. 지난 제10호에서 HWPX 전환을 접근성의 시작이라고 표현한 이유입니다.

하지만 확장자가 HWPX라는 사실만으로 문서가 접근 가능해지지는 않습니다.

제목을 큰 글씨와 굵은 글꼴로만 만들고 제목 구조를 넣지 않았다면 화면 읽기 프로그램 사용자는 제목 목록으로 이동할 수 없습니다. 표에 머리글 관계가 없고 그림에 대체 텍스트가 없다면 XML 파일 안에 구조가 많다 해도 정작 필요한 의미는 전달되지 않습니다. HWP에서 HWPX로 변환할 때는 옛한글과 수식, 개체와 접근성 속성이 빠지지 않는지도 확인해야 합니다.

무엇보다 Windows와 macOS, Linux의 여러 편집기와 화면 읽기 프로그램에서 실제 과업을 마칠 수 있어야 합니다.

한글을 잘 표현하는 것, 문서 구조를 공개하는 것, 보조공학기술로 사용할 수 있는 것은 서로 연결되지만 같은 말은 아닙니다. 아래아한글은 한글 표현력을 제품 안에서 먼저 해결했습니다. 그 성공은 한국어 문서 작성의 문턱을 낮췄지만 문서와 접근성 지원이 특정 생태계에 오랫동안 종속되는 결과도 낳았습니다.

이제 필요한 질문은 아래아한글을 없앨 것인가가 아닙니다. HWP에 쌓인 문서를 손실 없이 읽고 HWPX 같은 개방형 구조로 옮길 수 있는가, 그 구조가 다른 편집기와 보조공학기술에도 실제로 열리는가입니다. 한글을 가장 잘 표현한 도구가 모든 사용자에게 가장 열린 도구였던 것은 아닙니다. 앞으로는 표현력과 개방성, 접근성을 한 문서 안에서 함께 요구해야 합니다.

브리핑 4. 완성형과 조합형을 함께 품다 — 유니코드에서 한글의 자리

유니코드라는 말이 등장하기 시작했을 때 흔히 ‘전 세계 문자를 두 바이트로 표현하는 코드’라고 설명됐습니다. 초기 Windows와 UTF-16의 경험이 섞인 설명이지만 정확하지는 않습니다. 유니코드의 핵심은 모든 문자를 두 바이트로 저장하는 데 있지 않습니다. 문자를 전 세계가 공유하는 하나의 코드 포인트 공간에 배치하고, UTF-8·UTF-16·UTF-32 같은 다양한 방식으로 저장하고 전송할 수 있게 한 데 있습니다.16

여기서 문자와 인코딩을 나누어 보아야 합니다.17 유니코드는 문자에 번호를 붙입니다. 미리 조합된 한글 음절 ‘가’의 코드 포인트는 U+AC00입니다. UTF-8은 이 번호를 파일에 저장할 바이트열 EA B0 80으로 바꿉니다. UTF-16과 UTF-32는 같은 U+AC00을 다른 바이트열로 저장합니다. 따라서 “UTF-8은 조합형인가, 완성형인가”라는 질문은 서로 다른 층을 섞습니다.

현대 한글 음절은 초성 19개, 중성 21개, 종성이 없는 경우를 포함한 종성 28개를 조합해 만들 수 있으며, 19 × 21 × 28로 모두 11,172개입니다. 유니코드는 이 음절들을 U+AC00부터 U+D7A3까지 규칙적으로 배치했습니다. ‘가’에서 얼마나 떨어져 있는지 계산하면 초성·중성·종성을 다시 알아낼 수 있습니다.18

동시에 초성·중성·종성 자모에도 각각 코드 포인트를 부여했습니다. 그래서 ‘가’를 U+AC00 하나로 저장할 수도 있고, 초성 기역 U+1100과 중성 아 U+1161을 이어서 저장할 수도 있습니다. 미리 만들어 둔 음절 코드가 없는 옛한글은 확장 자모를 결합해 표현합니다.

이 때문에 유니코드를 과거의 완성형이라고만 부르기도, 옛 2바이트 조합형의 연장이라고만 부르기도 어렵습니다. 과거 2바이트 조합형은 한 값 안의 비트 영역에 초성·중성·종성을 나누어 넣었습니다. 유니코드의 결합 자모열은 각 자모가 별도의 코드 포인트입니다. KS 완성형 2,350자는 선택한 음절 목록에 번호를 붙였지만 유니코드의 미리 조합된 11,172음절은 현대 한글 전체를 규칙적으로 배치했습니다.

유니코드는 조합형과 완성형 가운데 하나를 고르기보다, 미리 조합된 음절과 결합 자모열을 같은 문자로 다룰 규칙을 만들었습니다.

그 규칙이 정규화입니다. 미리 조합된 가와 ᄀ+ᅡ는 코드 포인트열이 다르지만 유니코드에서는 같은 문자로 인정합니다. 프로그램은 필요에 따라 분해형인 NFD나 결합형인 NFC로 정규화해 둘을 비교할 수 있습니다.19

유니코드에 한글 11,172음절이 처음부터 지금 위치에 있었던 것은 아닙니다. Unicode 1.0과 1.1에 들어간 KS C 5601 계열 음절은 Unicode 2.0에서 11,172음절 전체를 담는 새 영역으로 이동해 다시 배열됐습니다. 이미 정해진 문자 위치가 바뀌자 이전 버전의 문서와 구현도 영향을 받았습니다.

이는 당시 유니코드 관계자가 이 사건을 ‘Korean mess’라고 부를 만큼 큰 호환성 문제였습니다.20 Unicode 2.0에서 이러한 혼란을 겪은 뒤에는 한 번 배정한 문자를 옮기거나 없애지 않는 인코딩 안정성 정책이 자리 잡았습니다. 한글은 전 세계 문자 체계 안에서 넓고 규칙적인 자리를 얻었지만, 그 과정은 문자표의 정확성만큼 이미 만들어진 문서와 프로그램의 호환성이 중요하다는 교훈도 남겼습니다.

유니코드는 한글 코드의 춘추전국시대를 끝내는 데 결정적인 역할을 했습니다. 비로소 한글과 영문, 한자와 수학 기호, 여러 언어를 한 문서에 함께 담을 수 있게 했습니다. 현대 한글 전체와 옛한글 자모를 같은 체계 안에서 표현할 길도 열었습니다. 30년 전처럼 ‘한글 Windows’에서 일본어를 쓰기 위해 ‘일본어 Windows’를 따로 깔았던 번거로움은 이제 겪지 않아도 됩니다.

그런데 표현할 수 있다는 말이 언제나 같은 문자로 처리한다는 뜻은 아닙니다. 코드 포인트열은 달라도 같은 문자로 인정되는 한글을 검색과 정렬, 파일 이름과 커서 이동에서도 동등하게 다루려면 프로그램이 유니코드의 정규화와 문자 경계 규칙을 실제로 적용해야 합니다. 표준이 마련한 가능성을 사용자가 누리게 만드는 일은 다시 운영체제와 앱, 화면 읽기 프로그램과 점역기의 몫으로 돌아옵니다.

브리핑 5. 같은 글자인데 왜 찾지 못하나 — NFC·NFD와 보조공학기술

유니코드에서 같은 한글을 여러 코드 포인트열로 나타낼 수 있다는 말은 기술 사양서 속 정의처럼 들립니다. 하지만 컴퓨터를 직접 사용하면서 파일 이름을 찾고 한 글자씩 읽는 순간에는 아주 구체적인 문제가 됩니다.

‘가’를 다시 보겠습니다.

보이는 문자열정규화 형태코드 포인트UTF-8 바이트 수
가NFCU+AC003
가NFDU+1100 U+11616

‘한글’은 NFC에서 코드 포인트 2개, UTF-8 6바이트입니다. NFD에서는 초성·중성·종성 자모 6개, UTF-8 18바이트가 됩니다. 화면의 글꼴이 자모를 음절 덩어리로 잘 모아 그리면 눈에는 둘 다 똑같이 보입니다. 그러나 원시 코드 포인트열을 그대로 비교하면 서로 다릅니다. 복사한 검색어는 NFC인데 문서 안에 저장된 문자열이 NFD라면 정규화하지 않는 검색 기능은 같은 단어를 찾지 못할 수 있습니다.

유니코드 텍스트 분할 규칙은 결합 자모열을 사용자가 느끼는 한 글자 단위로 묶어 다룰 수 있게 합니다.21 그런데 모든 프로그램이 이를 같은 단계에서 적용하지는 않습니다. 문자 단위로 오른쪽 화살표를 한 번 눌렀을 때 음절 전체를 지나가는지 자모 사이에 멈추는지, 백스페이스 한 번에 음절이 지워지는지 종성 하나만 지워지는지는 앱의 편집 모델에 따라 달라집니다.

파일 이름의 자음과 모음이 따로 보이는 현상을 흔히 ‘자소 분리’라고 부릅니다. 이를 “Mac은 NFD를 쓰기 때문”이라고만 설명하기도 하지만 현재 macOS 전체의 동작을 그렇게 단순화하면 정확하지 않습니다. macOS가 사용하는 파일 시스템인 HFS+는 파일과 폴더 이름의 한글 음절을 결합 자모열로 분해해 저장했습니다. 반면 APFS는 입력된 정규화 형태를 보존하면서도 정규화가 다른 동등한 이름을 같은 이름으로 찾도록 비교합니다.22 다만 파일 이름이 ZIP, 클라우드, 네트워크를 거쳐 Apple의 비교 계층 밖으로 나가면 분해된 코드 포인트열이 그대로 드러날 수 있습니다.

파일 이름이 웹이나 압축 파일을 거치면 또 다른 문제가 겹칩니다. URL의 %ED%95%9C%EA%B8%80은 UTF-8로 저장한 ‘한글’의 바이트를 인터넷 주소에서 쓸 수 있도록 나타낸 정상적인 표현입니다. 그러나 서버나 프로그램이 내려받을 이름을 제대로 전달하고 해석하지 못하면 퍼센트열이나 깨진 이름이 실제 파일 이름으로 남습니다.23 ZIP도 파일 이름 바이트의 문자표와 정규화 형태를 함께 다루어야 합니다. CP949 바이트를 다른 문자표로 읽으면 이름이 깨집니다. 프로그램이 분해된 자모열을 음절 덩어리로 조합해 표시하지 못하면 자음과 모음이 분해되어 따로 보일 수 있습니다. NFC와 NFD를 같은 문자로 비교하지 않으면 같은 이름을 서로 다른 문자열로 판단할 수도 있습니다.24

이번에 저 알리가 한 시험에서는 Windows와 macOS의 기본 압축 해제 기능이 두 ZIP을 모두 정상적으로 풀었습니다. 하나는 UTF-8 파일 이름 표시가 있었고, 다른 레거시 ZIP은 그 표시 없이 CP949 바이트로 이름을 기록했습니다. Windows에서는 센스리더도 추출된 한글 이름을 정상적으로 읽었습니다. 현재 운영체제의 기본 도구가 흔한 두 표본을 실용적으로 처리한 결과입니다. 다만 이 결과를 모든 언어와 모든 오래된 ZIP으로 넓힐 수는 없습니다. 압축이 풀렸다는 것, 원래 NFC·NFD 코드 포인트열이 보존됐다는 것, 보조공학기술이 같은 방식으로 읽었다는 것도 각각 다른 판정입니다.

보조공학기술에서 한글은 다음과 같은 변환 흐름을 지나갑니다.

파일의 바이트 → 인코딩 판별 → 유니코드 코드 포인트 → 정규화 → 글자·단어·문장 분할 → 앱의 접근성 정보 → 음성 합성 또는 점역 → 점자 표시 장치

앞 단계에서 값이 틀어지면 뒤 단계는 그 틀어진 결과를 전달합니다. Johab 파일을 메모장이 해석하지 못했을 때 센스리더가 원래 한글을 되살릴 수 없었던 이유도 이것입니다. 반대로 앱이 파일 이름 바이트를 올바르게 해석하면 화면 읽기 프로그램도 정상적인 한글을 읽을 수 있습니다.

정규화는 점역25 결과도 바꿨습니다. 점사랑 7.0에서 UTF-8 NFC 파일은 정상적으로 열리고 점역됐습니다. 같은 내용을 NFD로 저장한 파일도 열리기는 했지만 결과가 일관되지 않았습니다. NFD 문은 ‘문’이라는 음절로 묶이지 않아 미음·우·니은이 자모별 정자로 점역됐고, ‘운’ 약자도 적용되지 않았습니다. 반면 NFD 각에는 ‘가’ 약자와 받침 기역이 적용됐습니다.26

NFD 지원은 ‘된다’와 ‘안 된다’로만 나눌 수 없습니다. 파일을 여는 것, 자모를 한 음절로 표시하는 것, 커서를 한 글자씩 옮기는 것, 약자 규칙을 일관되게 적용하는 것, 역점역 뒤 원문이 남는 것은 서로 다른 과업입니다. 같은 문서 안에서 어떤 규칙은 적용되고 다른 규칙은 빠지면 점역 결과 전체를 다시 확인하는 부담은 사용자에게 돌아갑니다.

점사랑의 도움말은 텍스트 문서 완성형, 텍스트 문서 조합형, 유니코드 텍스트 문서를 지원한다고 구분합니다. 그런데 이번 Johab 코드 페이지 1361 표본은 파일 형식을 ‘조합형’으로 직접 골라도 깨졌습니다. 반면 같은 파일을 아래아한글에서 KSSM으로 지정하면 정상적으로 열렸습니다. 점사랑이 도움말에서 말하는 조합형이 다른 세부 부호계라면 지원 범위와 코드 페이지를 더 정확히 밝혀야 합니다. Johab을 포함하려 한 것이라면 이번 결과는 실제 구현을 점검해야 할 근거가 됩니다.27

혼합 유니코드 문서에서는 문제의 층이 더 늘어났습니다. 점사랑 7.0은 공백으로 나눈 낱글자형 자모를 단독 자모 규칙에 따라 점역했고, 결합용 자모로 쓴 옛한글과 방점은 관찰한 범위에서 처리했습니다.28 악센트를 글자 하나에 함께 담은 라틴 문자도 제대로 읽었습니다. 반면 음악 기호·한자·이모지는 유니코드의 기본 영역 밖에 있었고, 유니코드 점자는 점형 자체를 문자로 기록한 표본이었습니다. 여기서는 깨진 결과가 나타났습니다. 여러 문자 종류가 섞인 표본이어서 직접 원인을 가리려면 문자와 처리 단계를 더 나누어 시험해야 하는데, 일단 확인된 범위는 ‘유니코드 문서 지원’이라는 한 문장만으로 혼합 문서의 편집과 점역 품질을 보장할 수 없다는 데까지입니다.

같은 NFD 파일을 한소네 6 버전 2.8에서 열었을 때는 다른 결과가 나왔습니다. 단순 NFD 문서는 음성과 점자로 정상 출력됐고 점역도 음절과 약자 단위로 처리됐습니다. 파일 탐색기에서도 NFC와 NFD로 만든 한글 이름을 모두 같은 한글 음절로 읽었습니다. 내부에서 NFC로 바꿨는지, 원시 자모열을 유지한 채 음성·점자 출력 단계에서 묶었는지는 이번 시험만으로 알 수는 없었지만 사용자에게 도달한 결과는 분명했습니다. Windows 메모장·센스리더와 점사랑 7.0에서 자모 단위로 분해되어 읽혔던 NFD 한글이 한소네 6에서는 제대로 된 음절로 읽혔습니다.

그런데 여기서 반전이 있습니다. 한소네 6이 모든 유니코드 문서를 문제없이 처리한 것은 아닙니다. UTF-8 NFC·NFD, BOM 포함 UTF-8, CP949, KS X 1001 범위의 EUC-KR과 기본 점역 시험 문서는 정상 출력됐습니다. 일부 혼합 문서에는 Johab과 옛한글, 악센트가 붙은 문자, 유니코드 기본 영역 밖의 문자와 이모지가 한데 들어 있었습니다. 이 문서들은 음성과 점자 모두 깨졌습니다. 단순 NFD는 정상이고 NFC 혼합 문서는 깨졌으므로 원인을 NFD 하나에 돌릴 수도 없습니다.29

이 비교에서 저는 세 가지를 깨달았습니다.

첫째, 화면 읽기 프로그램만 떼어 놓고 책임을 물어서는 원인을 찾기 어렵습니다. 시험 범위에는 바이트를 문자로 바꾸는 앱, 문자를 한 글자로 나누는 편집기, 접근성 정보를 건네는 인터페이스, 음성과 점자로 바꾸는 보조공학기술이 모두 들어가야 합니다.

둘째, 제품 설명의 ‘UTF-8 지원’, ‘유니코드 지원’, ‘조합형 지원’은 출발점일 뿐입니다. 자동으로 인코딩을 찾는지, 사용자가 수동으로 고를 수 있는지, NFC와 NFD를 같은 문자열로 검색하는지, 문자 단위 이동과 삭제가 음절을 보존하는지, 점역과 역점역 뒤 원문이 남는지까지 나누어 알려 주어야 합니다.

셋째, 레거시 문서를 버리지 않는 변환 경로가 반드시 필요합니다. 새 문서에는 UTF-8과 명시적인 정규화 정책을 기본으로 삼더라도 30년이 훌쩍 넘는 시간 동안 CP949·EUC-KR·Johab으로 쌓인 자료는 남아 있습니다. 변환 경로는 원본을 보존하고, 감지한 인코딩과 바꿀 형식을 사용자에게 보여 주며, 변환 뒤 검색·음성·점자 결과를 비교할 수 있어야 합니다.

한글 접근성은 글꼴이 한글을 화면에 그리는 순간에 끝나지 않습니다. 파일을 찾고, 같은 글자로 검색하고, 한 음절씩 읽고 지우고, 음성과 점자로 옮긴 뒤 다른 기기에서도 다시 여는 데까지 이어져야 합니다.

마치며

한글 코드의 역사를 따라가다 보면 기술이 해결한 문제가 차례로 보입니다.

처음에는 컴퓨터 화면에 한글을 띄울 수 있는지가 문제였습니다. 그다음에는 다른 회사의 컴퓨터에서도 같은 한글로 읽히는지가 문제가 됐습니다. 표준이 생긴 뒤에는 표준에서 빠진 글자를 누가 감당할지가 남았습니다. 유니코드는 현대 한글 11,172음절과 옛한글 자모를 전 세계 문자 체계 안에 놓았습니다.

그런데 같은 글자를 같은 문자로 다루는 일은 아직 끝나지 않았습니다.

NFC와 NFD의 코드 포인트열은 다르지만 유니코드에서는 같은 ‘한글’로 인정합니다. 하지만 어떤 프로그램에서는 음절로 읽히고, 어떤 프로그램에서는 초성·중성·종성으로 분해되어 읽힙니다. 같은 NFD 문서 안에서도 한 점역 프로그램은 어떤 약자를 적용하고 다른 약자는 풀어 버렸습니다. Johab 파일은 바이트가 남아 있어도 해석할 문자표를 찾지 못하면 깨져 버립니다. HWPX는 구조가 열린 형식이어도 문서 작성과 변환, 편집기의 보조공학 지원이 따라오지 않으면 접근 가능한 문서에서 멀어집니다.

그래서 이번 호의 결론을 “이제 UTF-8을 쓰면 됩니다”로 끝낼 수 없습니다. 새 문서에 UTF-8을 쓰는 것은 중요한 기본값입니다. 하지만 이미 남아 있는 CP949·EUC-KR·Johab 문서를 안전하게 읽고 바꾸는 일, NFC와 NFD를 같은 문자로 검색하고 편집하는 일, HWP와 HWPX 사이에서 문서 구조와 접근성 정보를 보존하는 일도 함께 살펴야 합니다. 화면 읽기 프로그램과 점역 프로그램, 점자 정보 단말기에서 실제 과업을 시험하는 일도 빠질 수 없습니다.

문자가 화면에 보이는 것은 시작에 불과합니다.

같은 문자를 찾을 수 있어야 합니다. 한 글자씩 읽고 고칠 수 있어야 합니다. 다른 컴퓨터로 옮겨도 이름을 잃지 않아야 합니다. 음성과 점자로 바뀐 뒤에도 원래 문장과 구조를 따라갈 수 있어야 합니다.

그때 비로소 한글은 정보가 되어 사람에게 닿습니다.

다음 주 화요일에 뵙겠습니다.

Footnotes

  1. ASCII는 7비트로 0부터 127까지 128개의 값을 사용하는 문자 코드입니다. 영문자·숫자·문장부호뿐 아니라 통신 제어 문자도 포함하므로 128개를 모두 ‘글자’라고 부르기보다 128개의 값 또는 코드 위치라고 쓰는 편이 정확합니다. | RFC Editor, 「RFC 20: ASCII Format for Network Interchange」(1969) ↩

  2. 비트는 0과 1 가운데 하나를 담는 가장 작은 정보 단위이며, 바이트는 일반적으로 8비트를 묶은 단위입니다. 8비트로는 256개의 서로 다른 값을 나타낼 수 있습니다. 이 값의 수와 어떤 값을 어느 문자에 대응할지는 별개의 문제입니다. | NIST Computer Security Resource Center, 「bit」, NIST Computer Security Resource Center, 「Byte」 ↩

  3. N바이트 부호계는 한글 한 음절을 초성·중성·종성에 해당하는 여러 바이트로 풀어 나타내는 초기 방식입니다. SI와 SO는 뒤따르는 값을 어떤 문자 집합으로 해석할지 바꾸는 통신 제어 값으로 쓰였습니다. 국립국어원에 공개된 회고 자료는 1970년대 초 이 부호계가 업체별로 달라 27종까지 난립했고, SI·SO와 자모 대응표의 차이 때문에 정보 교환이 어려웠다고 설명합니다. 다만 이 자료는 1987년 완성형 표준 제정에 참여한 관점에서 작성됐으므로 조합형·완성형 논쟁 전체를 대표하는 중립적 연대기라기보다 당시 표준화 논리와 문제 인식을 확인하는 자료로 읽어야 합니다. | 국립국어원, 「완성형 한글 부호의 제정 배경과 보완 방안」 ↩

  4. KS C 5601은 이후 KS X 1001로 표준명이 바뀌었습니다. 94×94 구조는 제어 문자와 충돌하지 않는 94개의 행과 94개의 열을 조합해 문자 위치를 정하는 방식입니다. ISO 2022는 7비트 또는 8비트 데이터 흐름에서 제어 문자와 이스케이프 시퀀스를 이용해 등록된 문자 집합을 불러오고 전환하는 부호화 틀입니다. RFC 1557은 인터넷 메시지용 한국어 부호화에서 KS C 5601 문자 집합을 ISO 2022 방식으로 쓰는 절차를 설명합니다. | 국가표준인증 통합정보시스템, 「KS X 1001」, IETF, 「RFC 1557: Korean Character Encoding for Internet Messages」(1993), ECMA, 「ECMA-35: Character Code Structure and Extension Techniques」 ↩

  5. 형태소 분석은 단어를 어근·어간·접사 같은 구성 요소로 나누어 문법적 구조를 알아내는 처리입니다. 표현할 수 있는 음절이 제한되면 이름·방언뿐 아니라 이런 언어 처리에도 예외가 생길 수 있습니다. | 국립국어원, 「국어 연감: 국어정보학」 ↩

  6. 1980년대의 2바이트 조합형은 대우·삼보 등 여러 업체가 저마다 다른 방식을 제안해 사용했고, 이후에는 삼보컴퓨터가 주도한 KSSM이 ‘상용 조합형’으로 널리 쓰였습니다. 당시 보도도 업체별 조합형을 상용 조합형으로 통일해야 하드웨어와 소프트웨어의 호환 문제를 줄일 수 있다고 설명했습니다. 따라서 ‘조합형’이라는 범주가 같아도 세부 배열이 다르면 같은 바이트를 서로 다른 자모나 기호로 해석할 수 있었고, 문서를 옮길 때는 어느 조합형으로 작성했는지 알아야 했습니다. | NAVER D2, 「한글 인코딩의 이해 1편: 한글 인코딩의 역사와 유니코드」(2012), 중앙일보, 「한글표준코드 조합형도 공식 채택｜완성형과의 마찰 일단락」 ↩

  7. 상호운용성은 서로 다른 컴퓨터·프로그램·기관이 데이터를 주고받고, 받은 쪽에서도 그 뜻과 구조를 유지한 채 사용할 수 있는 성질입니다. NIST 용어집은 이를 한 개체가 다른 개체와 통신할 수 있는 능력으로 정의합니다. 함께 읽기: 제25호 ‘전자점자 파일 형식과 개방형 교환’. | NIST Computer Security Resource Center, 「Interoperability」 ↩

  8. KS X 1001:2004 해설은 1982년판 부속서의 16비트 조합형과 1992년 개정 때 상용 조합형에 맞춰 바꾼 부속서 배열을 구분합니다. 따라서 ‘조합형은 1992년에 처음 표준화됐다’고 쓰는 것은 정확하지 않습니다. | 국가표준인증 통합정보시스템, 「KS X 1001:2004 정보 교환용 부호계 해설」 ↩

  9. 코드 페이지는 운영체제나 프로그램이 바이트값을 어떤 문자로 해석할지 정한 문자표에 붙인 식별 번호입니다. Johab은 초성·중성·종성 정보를 2바이트 안의 비트 영역에 나누어 담는 한글 조합형 부호계입니다. KSSM은 널리 쓰인 상용 2바이트 조합형 배열을 가리키는 이름으로 사용돼 왔습니다. 다만 ‘조합형’이라는 범주 안에도 세부 배열이 달랐으므로 두 이름을 모든 환경에서 무조건 같은 값으로 바꾸어 써서는 안 됩니다. 이 글의 시험 파일은 코드 페이지 1361로 만든 Johab 파일이며, 아래아한글에서 이를 열 때 선택한 메뉴 이름이 KSSM이었습니다. Microsoft의 식별자 표는 949를 Unified Hangul Code, 1361을 Johab 및 Korean (Johab)으로 구분합니다. 파일 자체에 코드 페이지 번호가 반드시 저장되는 것은 아니어서, 인코딩 표지가 없는 TXT에서는 프로그램이 자동 추정하거나 사용자가 직접 골라야 할 수 있습니다. | Microsoft Learn, 「Code Page Identifiers」, 국립국어원, 「완성형 한글 부호의 제정 배경과 보완 방안」 ↩

  10. EUC-KR은 KS X 1001의 한글·한자·기호를 8비트 환경에서 교환하기 위해 쓰인 인코딩이고, CP949는 그 기존 영역을 유지하면서 나머지 현대 한글 음절을 더한 Windows 코드 페이지입니다. UTF-8은 유니코드 코드 포인트를 1~4바이트로 저장합니다. ASCII 범위 문자는 같은 1바이트 값을 유지하고 현대 한글 음절은 보통 3바이트로 저장합니다. WHATWG 인코딩 표준은 오래된 웹 문서를 열 수 있도록 euc-kr 같은 이름을 브라우저가 실제로 사용해 온 확장 해석 규칙과 연결하지만, 새 형식과 새 통신 규약에는 UTF-8을 요구합니다. | IETF, 「RFC 3629: UTF-8, a Transformation Format of ISO 10646」(2003), WHATWG, 「Encoding Standard」 ↩

  11. 바이트열을 선택한 인코딩으로 올바르게 해석하지 못하면 디코더가 오류를 내거나 대체문자 �(U+FFFD)를 표시할 수 있습니다. 저장할 때 사용한 문자표와 다른 문자표로 해석해 전혀 다른 문자나 읽기 어려운 문자열이 된 현상을 흔히 모지바케라고 부릅니다. | Unicode Consortium, 「Glossary of Unicode Terms」, WHATWG, 「Encoding Standard」 ↩

  12. 1998년 6월 한글과컴퓨터는 MS가 최대 2천만 달러를 투자하고 지분을 취득하는 대신 아래아한글 사업과 후속 개발을 중단하는 투자 유치 합의를 발표했습니다. 제품 자체를 MS가 곧바로 인수한 사건이라기보다 MS의 투자와 아래아한글 개발 중단을 묶은 합의였습니다. 한글과컴퓨터는 7월 20일 아래아한글지키기운동본부의 100억 원 투자 제안을 받아들여 MS와의 협상을 중단했고, 8월 15일에는 연회비 1만 원으로 쓸 수 있는 ‘아래아한글 815 특별판’을 출시했습니다. 출시 사흘 뒤에는 약 9만 4천 건의 주문과 약 4만 3천 장의 판매가 집계됐고, 3개월여 뒤에는 65만 장 이상이 판매됐다는 보도가 나왔습니다. 1998년의 위기는 HWP 생태계가 제품의 기술력만이 아니라 사용자 기반과 정품 구매 운동, 시장의 선택에 의해서도 유지됐음을 보여 줍니다. | 중앙일보, 「한글과컴퓨터 ‘아래아 한글’ 사라진다」(1998.6.15.), 연합뉴스, 「아래아한글 ‘기사회생’…운동본부 한컴인수키로」(1998.7.20.), 연합뉴스, 「한컴, 아래아한글815특별판 판매 개시」(1998.8.14.), 연합뉴스, 「아래아한글 판매호조, 한글윈도98 판매부진」(1998.8.19.), 전자신문, 「한글과컴퓨터 ‘한글815’」(1998.12.3.) ↩

  13. 바이너리 문서는 사람이 글자로 바로 읽는 텍스트 파일과 달리, 프로그램이 정한 바이트 구조 안에 내용을 저장한 파일입니다. OLE 복합 파일은 한 파일 안을 저장소와 스트림이라는 여러 영역으로 나누어 문서 내용·서식·개체를 함께 담는 Windows 구조입니다. 한컴은 HWP를 이 OLE 복합 파일을 바탕으로 한 바이너리 문서 형식으로 설명하고, 내부 구조를 알지 못하면 내용을 직접 읽기 어려우며 특정 소프트웨어에 의존하게 된다고 밝힙니다. 한컴은 2010년 HWP 포맷 명세를 공개했습니다. 명세 공개는 분석과 변환 도구 개발의 전제이지만 다른 편집기와 보조공학기술의 동등한 사용성을 자동으로 보장하지는 않습니다. 함께 읽기: 제10호 ‘rHWP와 HOP’. | Microsoft Learn, 「Structured Storage」, 한컴테크, 「한/글 문서 파일 형식: HWP 포맷 구조 살펴보기」 ↩

  14. 접근성 인터페이스는 앱이 화면의 텍스트·컨트롤·이름·역할·상태·편집 정보를 보조공학기술에 기계가 읽을 수 있는 방식으로 전달하기 위한 규칙입니다. MSAA는 Windows 95부터 쓰인 Microsoft의 접근성 기술이고, IAccessible2는 문서·표·하이퍼텍스트·편집 가능한 텍스트 같은 정보를 더 세분해 전달하는 인터페이스입니다. 한컴은 이 두 인터페이스뿐 아니라 센스리더 개발사와 협력한 HncAA로 한컴오피스 문서 정보를 전달한다고 설명합니다. 이는 국내 사용 환경에 맞춘 접근성 협업의 성과인 동시에 실제 사용성이 한컴오피스·HncAA·화면 읽기 프로그램의 버전 조합에 영향을 받을 수 있음을 보여 줍니다. 함께 읽기: 제22호 ‘센스리더와 HncAA’. | Microsoft Learn, 「Accessibility and automation for Windows developers」, Linux Foundation, 「IAccessible2 API」, 한컴테크, 「소프트웨어 접근성과 한컴오피스」 ↩

  15. XML(Extensible Markup Language)은 문서의 내용과 구조를 태그로 구분해 텍스트로 표현하는 마크업 형식입니다. OWPML은 한글 문서의 본문·문단·표·개체·서식을 XML로 표현하기 위한 개방형 문서 규격이고, HWPX는 이를 따르는 여러 XML 파일과 그림 같은 자원을 ZIP 컨테이너 하나에 묶은 패키지 형식입니다. 여기서 개방형이라는 말은 공개된 규격을 바탕으로 다른 프로그램도 내용을 분석하고 변환할 길이 있다는 뜻이지, 모든 HWPX 문서가 자동으로 접근 가능하다는 뜻은 아닙니다. 제목·표 머리글·대체 텍스트 같은 접근성 정보가 실제 문서에 올바르게 들어 있어야 합니다. 함께 읽기: 제10호 ‘HWPX 포맷 전환’. | W3C, 「Extensible Markup Language (XML) 1.0 (Fifth Edition)」, 한컴테크, 「HWPX 포맷 구조 살펴보기」 ↩

  16. 코드 포인트는 유니코드가 문자나 기호를 식별하려고 부여한 정수값이며 보통 U+와 16진수로 적습니다. 16진수는 09와 AF를 써서 값을 나타내는 방식이고, 코드 포인트열은 이 값들이 놓인 순서입니다. | Unicode Consortium, 「Glossary of Unicode Terms」, Unicode Consortium, 「The Unicode Standard, Chapter 2: General Structure」 ↩

  17. 문자 집합은 어떤 문자를 다룰지와 각 문자에 대응하는 값을 정한 표이고, 문자 인코딩은 그 값을 파일이나 통신에서 어떤 바이트열로 나타낼지 정한 방식입니다. 코드 단위는 UTF-8·UTF-16·UTF-32가 코드 포인트를 실제 데이터로 나타낼 때 사용하는 기본 크기입니다. UTF-8은 1~4개의 8비트 코드 단위를, UTF-16은 하나 또는 두 개의 16비트 코드 단위를 사용하고, UTF-32는 하나의 32비트 코드 단위를 사용합니다. | Unicode Consortium, 「The Unicode Standard, Chapter 2: General Structure」, Unicode Consortium, 「UTF-8, UTF-16, UTF-32 & BOM」 ↩

  18. Unicode 16.0 핵심 사양은 현대 한글 11,172음절을 U+AC00부터 U+D7A3까지 규칙적으로 배치합니다. 음절의 코드 포인트가 U+AC00에서 얼마나 떨어져 있는지 계산하면 초성·중성·종성을 알아낼 수 있으며, 별도의 한글 자모와 확장 자모 영역도 정의합니다. | Unicode Consortium, 「The Unicode Standard, Version 16.0, Chapter 18: East Asia」 ↩

  19. 정규화는 같은 문자 내용을 여러 코드 포인트열로 나타낼 수 있을 때 비교하거나 저장하기 쉬운 일정한 형태로 바꾸는 절차입니다. 유니코드 표준 부속서 제15호(UAX #15)는 NFD를 정준 분해(canonical decomposition), NFC를 정준 분해 뒤 **정준 결합(canonical composition)**한 형태로 정의합니다. 미리 조합된 가와 결합용 자모 ᄀ+ᅡ처럼 코드 포인트열은 달라도 같은 추상 문자를 나타내는 관계를 **정준 동등성(canonical equivalence)**이라고 합니다. NFC와 NFD는 이 관계에 있어도 실제 코드 포인트열과 바이트열은 다릅니다. | Unicode Consortium, 「Unicode Normalization Forms」 ↩

  20. Unicode 1.0·1.1의 한글 음절이 Unicode 2.0에서 새 영역으로 옮겨진 일은 유니코드 메일링리스트에서 이른바 ‘Korean mess’로 회고됐습니다. 이후 안정성 정책은 일단 배정한 문자를 이동하거나 제거하지 않는 원칙을 명시합니다. | Unicode Mail Archive, 「Korean mess history」, Unicode Consortium, 「Unicode Character Encoding Stability Policies」 ↩

  21. 유니코드 표준 부속서 제29호(UAX #29)는 텍스트를 글자·단어·문장 단위로 나누는 기본 규칙을 정합니다. 그래핌 클러스터는 코드 포인트가 하나 이상이어도 사용자가 한 글자로 느끼는 묶음입니다. 확장 그래핌 클러스터 규칙은 한글 자모 결합열 안에서 함부로 경계를 나누지 않도록 합니다. 본문에서 말하는 편집 모델은 앱이 커서 이동과 삭제의 한 단위를 코드 포인트, 자모, 음절 가운데 무엇으로 다룰지 정한 내부 처리 방식입니다. 실제 커서 이동·삭제·음성·점자 출력은 운영체제와 앱, 보조공학기술이 이 규칙을 어떻게 구현했는지에 따라 달라집니다. | Unicode Consortium, 「Unicode Text Segmentation」 ↩

  22. 파일 시스템은 저장 장치에서 파일과 폴더의 이름·위치·속성을 기록하고 찾는 운영체제의 구조입니다. HFS+는 과거 Mac에서 널리 쓰인 파일 시스템으로, 파일 이름을 특정 유니코드 버전에 기반한 Apple식 분해 형태로 저장하며 한글 음절 U+AC00~U+D7A3을 결합 자모열로 분해합니다. APFS는 현재 Apple 기기의 주된 파일 시스템으로, 입력된 정규화 형태를 보존하되 정규화가 다른 동등한 이름을 같은 이름으로 찾도록 비교합니다. 따라서 현재 macOS 전체가 파일 이름을 무조건 NFD로 저장한다고 설명해서는 안 됩니다. | Apple, 「HFS Plus Volume Format」, Apple, 「Apple File System FAQ」 ↩

  23. URI는 인터넷에서 자원을 식별하는 표기 전체를, URL은 그중 자원의 위치와 접근 방법을 나타내는 주소를 가리킵니다. 퍼센트 인코딩은 주소에 그대로 쓰기 어려운 바이트를 %와 두 자리 16진수로 적는 방식입니다. HTTP는 웹에서 서버와 프로그램이 요청과 응답을 주고받는 통신 규칙이며, Content-Disposition은 응답 내용을 화면에 바로 보일지 파일로 받을지와 파일 이름을 알리는 머리글입니다. filename*에는 UTF-8 같은 문자 인코딩과 언어 정보를 포함한 파일 이름을 보낼 수 있습니다. 퍼센트열이 URL에 있는 것과 다운로드 뒤 실제 파일 이름으로 남은 것은 구분해야 합니다. | RFC Editor, 「RFC 3986: Uniform Resource Identifier」, IETF, 「RFC 6266: Content-Disposition in HTTP」 ↩

  24. ZIP은 여러 파일과 폴더를 하나로 묶고 압축하는 파일 형식입니다. ZIP 사양은 일반 목적 비트 11이 켜지면 항목 이름과 주석을 UTF-8로 저장하도록 정하고, 유니코드 이름을 위한 추가 필드도 정의합니다. 여기서 비트 11은 ZIP 항목의 인코딩 상태를 알리는 표지 가운데 하나입니다. 레거시는 현재도 남아 있는 오래된 형식·프로그램·데이터를 가리키는 말입니다. 오래된 도구가 CP949 같은 지역 문자표로 이름을 썼지만 UTF-8 표시를 남기지 않으면 다른 도구가 바이트를 다르게 해석할 수 있습니다. | PKWARE, 「ZIP File Format Specification」 ↩

  25. 묵자는 점자와 구분해 눈으로 읽는 일반 문자를, 점역은 묵자를 점자로 바꾸는 작업을, 역점역은 점자를 다시 묵자로 바꾸는 작업을 뜻합니다. 한글 점자의 약자는 자주 쓰는 글자나 말을 정해진 짧은 점형으로 나타내는 규칙입니다. 이 글에서 자모별 정자는 약자를 적용하지 않고 미음·우·니은 같은 글자 요소를 각각 풀어 적은 결과를 가리킵니다. 함께 읽기: 제25호 ‘역점역할 수 있는 전자점자’. | 국립국어원, 「2024 개정 한국 점자 규정」 ↩

  26. 2024 개정 한국 점자 규정에서 가 계열 한 칸 약자는 제13항에, 운 계열 약자는 제15항과 붙임에 규정돼 있습니다. 점사랑 7.0 시험에서는 NFD 각에 ‘가’ 약자와 받침 기역이 적용됐지만 NFD 문에는 ‘운’ 약자가 적용되지 않았습니다. 같은 자모 결합열 안에서도 규칙별로 처리 결과가 달랐으므로 전면 지원이나 전면 미지원보다 부분적이고 불일치한 처리로 보는 편이 안전합니다. 이 결과는 점사랑 7.0 한 제품과 이번 시험 파일에 한정합니다. | 사용자 실기(점사랑 7.0), 국립국어원, 「2024 개정 한국 점자 규정」 ↩

  27. 점사랑 7.0 도움말은 텍스트 완성형·조합형·유니코드 문서와 HWP·HWPX·DOCX·PDF 등의 열기를 안내하지만, ‘조합형’의 코드 페이지와 바이트 배열, .txt 자동 판별 기준은 밝히지 않습니다. 이번 시험에서 CP1361/Johab 파일은 조합형을 직접 선택해도 깨졌고 아래아한글에서 KSSM으로 지정하면 정상적으로 열렸습니다. 점사랑이 다른 조합형만 지원한다면 세부 범위를 문서에 밝혀야 하며, CP1361을 포함하도록 의도했다면 구현을 점검할 필요가 있습니다. 함께 읽기: 제19호 ‘점사랑 7.0과 한소네 7’. | 점사랑 7.0 도움말 BrailleLove.chm, Microsoft Learn, 「Code Page Identifiers」, 국립국어원 점자 종합 정보 누리집, 「점사랑 내려받기」 ↩

  28. 호환 자모는 ㄱ, ㅏ처럼 기존 문자표와의 호환을 위해 따로 배정한 자모이고, 결합용 자모는 초성·중성·종성 역할에 따라 이어 놓으면 한 음절 블록으로 표시할 수 있는 유니코드 자모입니다. 방점은 중세 한국어에서 음절의 소리 높낮이를 나타내려고 글자 옆에 찍은 점입니다. | Unicode Consortium, 「The Unicode Standard, Version 16.0, Chapter 18: East Asia」 ↩

  29. 한소네 6 버전 2.8 실기에서는 UTF-8 NFC·NFD, BOM 포함 UTF-8, CP949, KS X 1001 범위 EUC-KR, Johab과 여러 혼합 유니코드 표본의 1차 음성·점자 출력을 비교했습니다. BOM은 파일 시작 부분에서 유니코드 인코딩이나 바이트 순서를 알리는 단서로 쓰이지만 UTF-8에서는 필수가 아닙니다. 단순 NFD와 기본 점역 문서는 정상 출력됐고 Johab 및 일부 혼합 문서는 깨졌습니다. 혼합 표본에는 옛한글, 악센트 같은 부호가 붙은 문자, 유니코드 기본 영역 밖의 문자, 이모지, 점형을 기록한 유니코드 점자가 함께 있으므로 특정 문자 하나를 원인으로 단정하지 않습니다. 제품 페이지는 현재 한소네 6을 Android 12 기반으로 안내하지만, 정상 출력의 원인을 운영체제 하나로 환원할 수도 없습니다. 함께 읽기: 제25호 ‘기기를 바꾸어도 문서는 살아남는가’. | 사용자 실기(한소네 6 버전 2.8), Unicode Consortium, 「UTF-8, UTF-16, UTF-32 & BOM」, 힘스인터내셔널, 「한소네 6」 ↩

그래프 뷰

백링크