구현

이 면은 판 2의 표기를 화면과 파일에 옮기는 조건을 적는다. 쓰는 꼴의 코드포인트, 국가표준 KS X 1026-1이 정한 저장 형식, 표준 정규화(NFC)가 만드는 어긋남, 글꼴과 웹폰트, 내려받을 데이터다. 글꼴과 웹폰트 수치는 2026년 10월 28일 이 연구가 Windows 11 PC에서 직접 잰 값이다. 재지 않은 환경은 지원표에 빈 칸으로 둔다.

1. 코드포인트 표 — 닫힌 목록

아래 표는 판 2가 쓰는 옛 꼴과 방점, 채움 문자를 모두 모은 것이다. 이름은 유니코드 문자 데이터베이스의 이름 그대로다(16.0판, Python unicodedata 로 대조). 「조작」은 표기 체계 면의 O1~O6 코드다. O1 연서, O2 각자병서, O3 합용병서, O5 방점, O6 치두·정치 획 늘이기이고, 「재배정」은 해례에 이미 있는 글자를 다른 소리에 다시 쓰는 것이다. 출처층은 그 꼴이 처음 나오는 층이다. H는 해례, E는 언해본과 15~16세기 운서, M은 역학서와 근대안이다.

ㅃ ㄸ ㄲ(무기 p t k)도 O2의 산물이지만 현대 자모라 완성형 음절로 적히므로 이 표에서 뺐다. 3성은 점을 찍지 않는다.

표기 체계 면의 닫힌 목록은 조작 여섯이 낳는 32꼴과 재배정 4꼴, 모두 36꼴이다. O1 다섯(ᄫ ᅗ ᄝ ᄬ ᄛ), O2 여덟(ㄲ ㄸ ㅃ ㅆ ㅉ ᅘ ᅇ ᄙ), O3 다섯(ᅂ ᅈ ᅋ ᅄ — 『아학편』의 꼴 — 과 그 방식을 ㅌ 에 적용한 ᅊ), O4 둘(ᆝ ᆜ), O5 둘(〮 〯), O6 열(ᅎ ᅔ ᅏ ᄼ ᄽ · ᅐ ᅕ ᅑ ᄾ ᄿ), 재배정 넷(ᅀ ᅙ ᅌ ㆍ)이다. 판 2는 이 밖의 꼴을 쓰지 않는다. ꥢ 은 θ 를 정할 때 견준 대안이라 글자별 해설에만 보이고 목록에 넣지 않았다. 목록을 더 늘려야 하면 이 연구가 새로 만든 꼴로 표시하고 「남은 문제」 면에 먼저 올린다.

2. KS X 1026-1 요지

KS X 1026-1:2007 「정보 교환용 한글 처리 지침」은 유니코드의 한글을 어떤 형식으로 주고받을지 정한 국가표준이다. 아래는 김경석이 2008년 국제 표준화 작업반(ISO/IEC JTC1/SC2/WG2)에 낸 소개 문서 N3422R3에 붙은 영역본에서 읽은 것이다. 영역본은 국가표준 자체가 아니고 한국어판이 우선한다는 단서가 붙어 있다(Kim 2008: 5). 쪽은 PDF 면이다.

표준은 유니코드에 이미 있는 자모로 적는 형식만 정한다. 유니코드에 없는 꼴은 이 지침 안에서 텍스트로 적을 길이 없다. 판 2가 새 글자를 텍스트로 쓰지 않고 그림으로만 보이는 까닭이다(6절).

6절에는 유니코드 쪽의 반대가 있었다. 미국 국가기관과 유니코드 컨소시엄이 2009년 이 정규화 조항을 문제 삼아, ISO/IEC 10646에 이 표준을 인용하는 문구를 넣자는 제안에 의견을 낸 문서가 있다(US National Body · Unicode Consortium 2009, 확인 중). 방점에 대해서는 일반 범주를 바꾸자는 제안이 2011년에 나왔다(Constable 외 2011, 확인 중). 현재 문자 데이터베이스에서 두 방점의 일반 범주는 Mc(간격 있는 결합 부호), 결합 클래스는 224다(16.0판, Python unicodedata 로 대조). 해례의 조합 원리에 비추어 이 표준을 평가한 국내 발표도 있다(권기홍·변정용 2013, 확인 중).

3. NFC 함정

NFC는 웹과 대부분의 프로그램이 기본으로 쓰는 정규화다. 첫가끝 자모열 가운데 완성형으로 바꿀 수 있는 앞부분을 완성형으로 묶는다. 옛 초성으로 시작하는 음절은 완성형이 없으므로 건드리지 않는다.

셋째 줄이 함정이다. NFC가 내놓는 「완성형 + 종성 낱자」는 KS X 1026-1 5.3(2)가 틀린 형식의 보기로 든 바로 그 열이다(가ᇫ U+AC00 U+11EB, Kim 2008: 13). 표준 6절은 이 경우 L V T를 지키라고 권한다(Kim 2008: 14). 판 2의 표기에서 옛 꼴은 거의 모두 초성 자리에 오므로 이 경우는 드물다. 판 2는 NFC를 기본으로 두고, 이런 음절이 생기면 NFC 결과를 그대로 받아들인다. 웹 문서와 검색 엔진이 어차피 NFC로 바꾸기 때문이다. 그 대신 그 열이 표준과 어긋난다는 사실을 여기 적어 둔다.

정리하면 판 2의 저장 규약은 셋이다. 현대 음절은 완성형으로 쓴다. 옛 꼴이 든 음절만 첫가끝으로 쓴다. 저장 직전에 NFC를 걸고 그 결과를 정본으로 삼는다.

이 규약에서 생기는 일은 다음과 같다.

• 검색. 정본이 NFC이므로 「마」를 치면 「마〮」 가 걸린다. 방점은 별개의 결합 부호라서, 방점까지 넣어 찾으려면 U+302E를 함께 넣어야 한다. 옛 꼴로 시작하는 음절은 그 꼴을 입력할 수단이 있어야 찾을 수 있다.
• 복사. 화면에서 복사하면 코드포인트가 그대로 옮겨진다. 붙여 넣은 쪽의 글꼴이 조합을 지원하지 않으면 ᄼ ᅡ ᆫ 이 낱낱이 흩어져 보인다. 글자가 바뀐 것이 아니라 그려지지 않은 것이다.
• NFKC. 호환 자모 ㅸ(U+3178)은 NFKC에서 채움 문자 없는 ᄫ(U+112B)이 되어 앞뒤 음절에 달라붙을 수 있다(Kim 2008: 14의 경고, Python unicodedata 로 재현). 판 2는 NFKC를 쓰지 않는다.
• 정렬. 코드포인트 순으로 정렬하면 첫가끝 자모(U+1100~)로 시작하는 음절이 완성형 음절(U+AC00~) 앞에 모두 몰린다. KS X 1026-1 8절은 옛 자모를 넣은 자형 기준 정렬 순서를 따로 정한다(Kim 2008: 18–20). 판 2의 표는 원래 순서(언어 자습서의 표제어 순)를 쓰고 한글로 정렬하지 않는다.

4. 글꼴 지원표와 웹폰트

옛 음절이 한 칸에 모여 보이려면 두 가지가 다 있어야 한다. 글꼴에 그 자모의 글리프가 있어야 하고, 자모를 자리에 맞게 바꿔 그리는 OpenType 기능(ljmo · vjmo · tjmo)이 있어야 한다. 아래는 이 연구가 2026년 10월 28일 Windows 11 PC의 설치 글꼴을 fontTools 4.65로 검사한 결과다. 「판 2 꼴」은 1절 표의 20개 코드포인트(ꥢ 포함) 가운데 글꼴에 있는 수다.

같은 맑은 고딕 가족 안에서도 Semilight는 조합이 안 된다. 브라우저가 본문 굵기에 따라 이 파일을 고르면 옛 음절이 흩어진다.

웹폰트에는 다른 함정이 있다. Google Fonts의 기본 CSS(css2?family=Noto+Sans+KR:wght@400)는 글꼴을 124조각으로 나눠 보낸다. 조각들의 unicode-range를 모두 합쳐도 첫가끝 자모 U+1100–11FF는 0/256, 확장 A U+A960–A97F는 0/32, 확장 B U+D7B0–D7FF는 0/80, 방점 U+302E–302F는 0/2다. 호환 자모 U+3131–318E는 94/94 다 있다. 같은 API에 text= 로 ᄫ안〮 을 넘기면 그 글자들의 글리프와 ljmo · vjmo · tjmo 기능이 든 부분집합이 온다. 원본 글꼴에는 옛한글이 있고, 기본 분할에서만 빠진 것이다(두 결과 모두 같은 날 다시 받아 확인).

그래서 판 2는 글꼴을 직접 싣는다. 방법은 이렇다.

1. 원본은 Noto Sans KR · Noto Serif KR 데스크톱판이다. 라이선스는 SIL Open Font License 1.1이다(두 파일의 이름 표 라이선스 칸에서 확인). 라이선스 사본을 글꼴 파일과 함께 둔다. 부분집합도 고친 글꼴에 해당하므로, 예약 글꼴 이름 조항(Noto Sans KR에는 「Source」가 적혀 있다)에 걸리지 않는지 게시 전에 다시 본다.
2. 빌드 때 사이트 전 면에 실제로 쓰인 글자를 모아 pyftsubset 으로 woff2 부분집합을 만든다. --layout-features='*' 로 jmo · ccmp · calt 기능을 남긴다.
3. 옛 음절은 글꼴 안의 조합 규칙으로 그려지므로, 사이트에 나오지 않더라도 첫가끝 자모 전 범위(U+1100–11FF, U+A960–A97F, U+D7B0–D7FF)와 방점, U+1160을 넣는다.
4. Google의 text= 동적 호출은 외부 서비스에 기대므로 쓰지 않는다.

지원표(게시 전 실측). 아래 시험 문자열을 고정해 두고 환경마다 같은 것을 띄운다.

• 꼴: ᄫᅡ ᅗᅡ ᅊᅡ ᅂᅡ ᅀᅡ ᄼᅡ ᄾᅡ ᄿᅡ ᅎᅡ ᅔᅡ ᅐᅡ ᅕᅡ ᄙᅡ ꥢᅡ
• 옛 초성 + 현대 종성: ᄼᅡᆫ
• 방점: 마〮 · 마〯 · ᄼᅡᆫ〮 · ᅎᅵ〯
• 작은 낱자: ᄼ+U+1160, ᄙ+U+1160

빈 칸은 아직 재지 않았다는 뜻이다. Windows 11 의 Chrome · Edge 칸은 2026년 10월 28일 이 사이트의 웹폰트로 시험 문자열을 띄워 확인했고, Android 칸은 2026년 10월 29일, iOS 칸은 10월 30일 게시된 이 면에서 확인했다. 「웹폰트를 끈 상태」는 사이트 글꼴 파일을 뺀 사본을 띄워 기기 글꼴로 본 결과다. Windows 기본 글꼴인 맑은 고딕은 네 줄을 모두 바르게 보였고, 굴림 · 바탕은 옛 음절을 낱자로 흩어 보였다. 나머지 칸은 게시 뒤 실제 주소에서 재서 채운다. 스크린리더가 옛 음절과 방점을 어떻게 읽는지 다룬 문헌은 찾지 못했다(검색 범위: 한국어·영어 웹 일반).

웹폰트가 실패하는 기기를 위해 면마다 1층 보기 단추를 둔다. 누르면 옛 꼴 자리에 현대 한글 근사(ᅊ → ㅅ, ᄙ → ㄹ 등, 대응표의 1층 열)가 나온다. 기본은 2층이다.

5. 입력기

옛한글 입력 방법을 견주어 평가한 문헌 가운데 이 연구가 원문을 확인한 것은 없다. 그래서 이 사이트는 입력기를 권하지 않는다. 판 2의 표기는 엔진이 코드포인트를 직접 만들어 내므로 입력기가 필요 없다. 글자를 손으로 옮겨 써야 하면 데이터 파일(7절)이나 1절 표의 코드포인트를 복사해 쓴다.

6. 신자는 그림으로 — SVG

유니코드에 없는 꼴(신자)을 화면에 보이는 길은 셋이다.

판 2의 표기 표에 들어간 신자는 0개다. 신자는 글자별 해설과 이 면에서 후보를 설명하는 그림으로만 나온다. 데이터 파일에는 코드포인트 대신 꼴 ID 문자열(보기: R:ㅋ연서)로 적는다.

치두·정치 꼴(ᅎ ᅐ 등)의 해설 그림도 SVG로 그린다. 이 꼴들은 유니코드에 있지만, 웹폰트가 실패한 기기에서도 획 길이의 차이는 보여야 하기 때문이다. 영인본 사진은 싣지 않는다.

7. 데이터와 엔진 내려받기

모든 대응표와 엔진은 같은 데이터 파일을 읽는다. 표와 엔진이 어긋날 수 없게 하려는 것이다. 파일은 저장소의 sejong/data/ 에 있다.

mapping.csv — 자질 대응표. 한 행이 한 배정(언어 · 소리 · 환경 → 글자)이다.

bib-public.json — 참고문헌. CSL-JSON이다. 표준 필드 밖의 이 연구 칸(등급 · 분류 · 원문 링크 · 해제 · 이 사이트에서 쓰는 곳)은 custom 객체에 둔다. 이 목록에 싣지 않은 C 등급 문헌은 파일에도 없다.

표본·대립쌍 파일. 실증 면의 세 지표를 계산하기 전에 고정한 표본(sample-*.tsv)·최소대립쌍(pairs-*.tsv) 목록이다.

metrics-v2.json. 세 지표의 결과를 층 · 언어 · 유형별로 구간과 함께 담는다.

rules.md 와 m3-inventory-{es,ru,zh}.tsv. 대응표만으로는 정해지지 않는 규칙(언어별 음절 나누기, 받침 허용 목록과 작은 글자 조건, 러시아어 경·연자음과 모음의 결합, 중국어 운모 허용표와 변조 범위, 비교 전 정규화, M3 복호기의 분절 규칙과 빈도표, 렌더 오류 판정)을 선언형으로 적은 명세와, 확장 표본에서 센 분절음 빈도표다. 엔진 코드 없이 이 둘과 대응표·사전 등록 파일만으로 2층·1층 표기와 M1 · M2 · M3 를 다시 낼 수 있어야 하고, 다시 내어 맞지 않으면 명세의 오류로 본다. 2026년 10월 28일 독립 재현 검증에서 이 명세가 없어 재현이 갈린 것이 계기다.

엔진. 대응표를 읽어 한 낱말의 IPA에서 2층 · 1층 · 0층 표기를 내는 파이썬 모듈이다. 공통 부분(첫가끝 조합, NFC 규약, 작은 낱자, 방점 붙이기, 역변환)과 언어별 부분(IPA 나누기, 음절 나누기, 언어별 조건)으로 나뉘고, 배정 값은 코드에 두지 않고 mapping.csv 에서 읽는다. 저장소의 sejong/code/ 에 있다(hangul_core.py 와 lang/ 의 es_hangul.py · ru_hangul.py · zh_hangul.py · zh_ipa.py). 표준 라이브러리만 쓰며, 대응표는 sejong/data/mapping.csv 를 읽는다.