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

방문자 카운터

접근성 브리핑 제25호

70 min read

들어가며

지난 제24호에서 금융기관과 병원이 전자점자 서비스를 도입했다는 소식을 다뤘습니다. 화면에서 전자점자 버튼을 누르면 파일 하나가 다운로드됩니다. 점자 정보 단말기로 옮겨 읽거나 점자 프린터로 찍을 수 있다고 합니다.

그런데 그 파일은 대체 무엇일까요?

묵자 문서에는 TXT, DOCX, HWPX, PDF, EPUB 같은 다양한 형식이 있습니다. 파일 이름 끝에 붙은 확장자만 보아도 어느 프로그램으로 열지, 편집할 수 있는지, 다른 사람에게 보내도 되는지를 어느 정도 짐작합니다. 전자점자에도 BRL, BRF, BBF, HBL 같은 여러 형식이 있습니다. 점역 프로그램마다 따로 쓰는 작업 파일도 있고, 점자 정보 단말기에서만 익숙하게 보던 형식도 있습니다.

파일이 열리기만 하면 같은 점자라고 생각하기 쉽습니다. 그러나 어느 점자 규정으로 점역했는지, 한 줄에 몇 칸을 넣었는지, 제목과 표와 페이지 정보가 남아 있는지, 다른 기기로 옮겼을 때 다시 배치할 수 있는지는 파일마다 다릅니다. 내가 점자로 쓴 문서를 묵자로 되돌려 비시각장애인과 함께 고칠 수 있는지도 또 다른 문제입니다.

점자를 파일로 만들 수 있다는 말과, 그 파일을 읽고 고치고 보관하고 묵자로 되돌릴 수 있다는 말은 같지 않습니다.

이번 접근성 브리핑 제25호에서는 종이 점자를 찍기 위한 파일에서 출발해 점자 정보 단말기의 문서 형식, 국내외 점역 프로그램의 작업 파일, 2006년 국내에서 제정된 BrailleML, 그리고 2025년 공개된 eBraille 1.0까지 살펴보려 합니다. 전자점자가 기기와 프로그램에 관계없이 살아남으려면 무엇을 보존해야 하는지 묻기 위해서입니다.

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

브리핑 1. 점자는 언제 파일이 되었나 — 아연판에서 점자 정보 단말기까지

종이에 점자를 대량으로 인쇄하는 대표적인 방식 가운데 하나는 아연판이나 알루미늄판으로 점자 원판을 만드는 제판 인쇄였습니다. 점자제판기로 한 쌍의 금속판에 서로 맞물리는 점형을 새긴 다음 두 판 사이에 종이를 넣어 압축 롤러를 통과시키면 종이가 눌리면서 점이 솟아오릅니다. 국내 자료에서는 이를 원판 인쇄 방식, 압입 방식, 아연판 압착식 등으로 부릅니다. 이 글에서는 금속 원판을 쓰는 방식을 ‘원판 인쇄’라고 하겠습니다.1

우리나라에서는 제생원 맹아부가 1913년 점자제판기와 인쇄기를 들여와 같은 해 한국 최초의 점자 교과서를 만들었습니다. 송암 박두성 선생이 사용한 제판기와 점자인쇄기(롤러), 점자 원판은 오늘날 국가등록문화유산으로 남아 있습니다. 이 방식에서는 점자의 배치가 금속판 위에 물리적으로 고정됩니다. 교정본에서 점 하나를 잘못 찍은 것을 발견하면 원판을 손보거나 다시 만들어야 했고, 책의 판형과 한 줄의 칸 수, 한 면의 줄 수도 제판 단계에서 이미 정해졌습니다.1

점자 프린터는 금속 원판을 만들고 같은 판으로 여러 장을 찍는 단계를 건너뜁니다. 컴퓨터가 점역과 조판을 마친 점자 데이터를 프린터로 보내면 프린터가 종이에 직접 점을 올립니다. 그래서 제판 인쇄는 같은 책을 많이 찍을 때, 점자 프린터는 종류가 많고 수량이 적은 문서를 만들 때 주로 쓰였습니다. 어느 쪽이든 자동 제판기나 점자 프린터를 사용하려면 기계가 읽을 수 있는 점자 데이터가 필요합니다.1

점자 정보 단말기의 등장은 전자점자의 역할을 한 번 더 바꾸었습니다. 이제 점자 파일은 종이에 찍기 위한 중간 산출물에 머물지 않습니다. 파일을 열면 점자 표시장치의 핀이 올라오고, 사용자는 한 줄씩 읽으며 문서를 찾고 편집합니다. 같은 파일을 보관했다가 다시 열 수도 있고 다른 사람에게 보낼 수도 있습니다. 「점자법」이 전자점자를 “점자정보단말기 등에서 활용 가능하도록 전자적으로 생성된 점자”라고 정의한 것도 이런 사용 환경을 반영합니다.2

여기서 구분해야 할 것이 있습니다. 화면 읽기 프로그램과 점자 표시장치를 연결하면 일반 텍스트도 점자로 읽을 수 있습니다. 이때 점역은 화면 읽기 프로그램이나 운영체제, 단말기의 점역표가 실시간으로 처리합니다. 반면 전자점자 파일은 누군가가 미리 점역하고 조판하거나 특정 규칙에 따라 만들어 둔 점자 자체를 담을 수 있습니다. 둘 다 점자이기는 한데 만들어지는 과정은 다릅니다.

실시간 점역은 화면에 있는 묵자 원문을 그때그때 점자로 바꿉니다. 원문이 바뀌거나 커서가 이동하면 점자 표시도 함께 바뀝니다. 보조공학기술이 화면의 제목과 링크, 표 같은 구조에 접근할 수 있다면 점자 사용자도 이를 탐색에 활용할 수 있습니다. 그러나 결과는 기기와 점역표의 버전에 따라 달라질 수 있습니다. 미리 만든 점자 파일은 점역자와 교정사가 확인한 결과를 같은 형태로 전달하는 데 유리합니다. 대신 최종 점형만 남고 원문의 구조와 점역 과정이 사라지면 나중에 고치거나 다른 크기의 기기에 맞추기가 어려워집니다.

전자점자는 종이 점자를 없앤 형식이 아닙니다. 종이와 점자 표시장치 사이를 오가며 점자를 만들고 읽고 보관하게 한 새로운 층입니다. 그래서 파일 형식은 단순한 기술 문제가 아닙니다. 누가 점자를 만들 수 있는지, 어느 기기로 읽을 수 있는지, 문서를 얼마나 오래 보존할 수 있는지를 정하는 조건입니다.

브리핑 2. BRL·BRF·점자 ASCII — 오래 버틴 공용어와 납작해진 문서

전자점자 파일을 언급할 때 가장 자주 등장하는 이름이 BRL과 BRF입니다. 두 형식을 이해하려면 먼저 점자 ASCII를 알아야 합니다.

6점 점자는 아무 점도 없는 빈칸을 포함해 64개의 점형을 만들 수 있습니다. 점자 ASCII는 이 64개 점형을 컴퓨터 키보드에서 쓰는 출력 가능한 ASCII 문자 64개에 대응시킵니다. 화면에는 알파벳과 숫자와 문장부호처럼 보이지만, 점자 프로그램과 단말기는 그것을 문자 그대로 읽지 않고 대응하는 점형으로 해석합니다. 오해하지 말아야 할 지점이 있는데, 점자 ASCII는 점자 규정이 아니라는 것입니다. 한글 점자나 통일영어점자처럼 무엇을 어떤 점자로 적을지 정하는 규칙과 만들어진 점형을 컴퓨터 파일 안에 어떤 값으로 담을지는 서로 다른 층입니다.3

BRF(Braille Ready Format)는 이 점자 ASCII를 이용해 완성된 점자 페이지를 저장하는 대표적인 형식입니다. 전형적인 BRF에서는 공백이 들여쓰기와 정렬을, 줄바꿈이 한 줄의 끝을, 폼 피드(Form Feed)가 한 페이지의 끝을 나타냅니다. 다만 실제 구현은 더 느슨해서 페이지 경계가 없는 BRF도 있습니다. 점자 프린터에 보내면 이미 조판된 페이지가 그대로 나오는 ‘인쇄 준비 파일’에 가깝지만, 모든 BRF가 같은 수준으로 조판돼 있다고 장담할 수는 없습니다.4

BRF의 장점은 단순함입니다. 특별한 데이터베이스가 없어도 복사하고 내려받을 수 있으며 오래된 점자 프린터와 단말기도 비교적 쉽게 처리합니다. 하지만 단순한 만큼 잃는 것도 큽니다.

예를 들어 한 줄이 가운데 정렬돼 있어도 그것이 제목인지 알 수 없습니다. 페이지 맨 위의 글자가 머리말인지 본문인지, 빈칸 여러 개가 표의 열을 나눈 것인지 단순 들여쓰기인지도 파일에는 명시돼 있지 않습니다. Duxbury는 BRF를 다시 편집 가능한 문서로 불러올 때 머리말과 꼬리말, 페이지 번호, 줄 수와 칸 수를 사용자가 알려 줘야 한다고 설명합니다. BRF에는 조판 결과만 있을 뿐 “왜 그 자리에 놓였는지에 대한 기억”이 없기 때문입니다.4

그 한계는 기기를 바꿀 때 바로 드러납니다. 40칸으로 만든 한 줄을 20칸 점자 표시장치에서 읽으면 줄이 중간에서 끊어집니다. 표와 수식처럼 공간 배치가 의미를 이루는 내용은 더 쉽게 흐트러집니다. 종이에 다시 찍을 때도 원래 파일이 가정한 칸 수와 줄 수가 프린터 설정과 맞지 않으면 페이지가 밀릴 수 있습니다.

오늘날 여러 단말기에서 BRL은 점역된 점자를 담으면서도 BRF처럼 페이지 조판을 강하게 고정하지 않은 파일로 다뤄집니다. 그러나 기기와 프로그램에 따라 문단 저장과 줄바꿈 방식이 다르고, BRF와 내용이 같고 확장자만 다른 경우도 있습니다. 결국 book.brl이라는 이름만 보고 문서 구조와 점자 규정, 인코딩을 알 수는 없습니다.5

BRF와 BRL이 오랫동안 쓰인 데에는 단순함이 큰 몫을 했습니다. 점자 프린터로 보내기 쉬웠고, 저장 공간이 작은 점자 정보 단말기에서도 빠르게 열렸습니다. 문제는 이 형식에 책과 표, 수식과 그림, 제목 탐색과 기기별 재배치까지 모두 맡기려 할 때 생깁니다. 완성된 점형을 안전하게 전달하는 일과 문서의 의미 구조를 오래 보존하는 일은 같은 과제가 아닙니다.

브리핑 3. 한국의 전자점자는 왜 여러 형식으로 갈라졌나 — BBF·HBL과 BrailleML

국립장애인도서관은 전자점자도서의 파일 형식으로 BBF, BRF, BRL을 안내합니다.6 BBF는 Braille Best File이라는 이름에서 출발했으며 국내 DOS용 점역 프로그램 브레일베스트와 연결된 형식입니다. 그러나 지금의 BBF를 브레일베스트만의 전용 형식이라고 부르기는 어렵습니다. 실로암브레일도 출력용 BBF를 만들고 국립장애인도서관도 이를 배포해 왔기 때문입니다. 점자도서관에서 내려받은 BBF 파일을 한소네로 읽던 경험이 있는 독자도 적지 않을 것입니다.

점자 정보 단말기에는 기기 제조사가 만든 문서 형식도 있었습니다. 한소네·BrailleSense 계열의 기본 문서 형식은 HBL입니다. 한소네 6은 새 문서를 HBL로 저장하고 BRL로 내보낼 수 있습니다. 하지만 그 파일을 다른 제조사의 단말이나 일반 컴퓨터 프로그램에서 같은 수준으로 열 수 있는지는 별개의 문제입니다.7

점역 프로그램도 저마다 작업 파일을 가집니다. Duxbury Braille Translator는 DXP와 DXB를, 점사랑은 BLT와 BLB를, 실로암브레일은 SBF와 BBF를 사용합니다. 하상브레일을 비롯한 다른 국내 프로그램에도 각자의 편집 형식과 변환 절차가 있습니다.8

점역 프로그램별로 전용 파일 형식이 나쁘다고 할 수는 없습니다. 점역 중인 문서에는 최종 점형보다 훨씬 많은 정보가 필요한데, 이를테면 어느 문장이 제목인지, 어떤 부분에 외국어·수학·음악 점자 규칙을 적용할지, 묵자 페이지 번호와 점자 페이지 번호는 어떻게 대응하는지, 점역자가 어디를 고쳤는지를 저장해야 하기 때문입니다. BRF처럼 최종 페이지를 납작하게 저장한 파일보다 프로그램의 작업 파일이 더 풍부한 정보를 담는 것은 자연스럽습니다.

문제는 프로그램이 더 이상 개발되지 않거나 특정 기기가 단종돼 사용할 수 없게 될 때입니다. 그래서 파일 규격이 공개돼 있는지, 다른 프로그램으로 옮길 변환기가 있는지, 묵자 원문과 점자 결과를 함께 얻을 수 있는지가 중요합니다. 오래된 프로그램을 실행할 수 없다는 이유로 수십 년간 만든 점자 자료의 편집 가능성까지 잃어버린다는 건 있을 수 없는 일입니다.

저 알리도 20년 전 같은 문제로 고민하고 있었습니다. 당시 점사랑 1.0 프로젝트를 맡아 개방형 확장 표준을 연구했고, 그 성과를 토대로 2006년에 TTA에 「점역 및 역점역을 위한 XML 기반 기술 언어(BrailleML) 정의 1.0」을 제안했습니다. 표준 검토 과정에도 연구 성과를 반영했습니다. 이 표준은 점자 파일을 한 프로그램의 내부 형식에 가두지 않고, XML이라는 공개된 구조로 묵자와 점자의 문서 요소를 표현하려는 시도였습니다. TTA 표준번호는 TTAS.KO-09.0039이며 현재 표준 페이지에도 유효한 표준으로 남아 있습니다.9

당시 예제 파일을 다시 열어 보니 문제의식이 더 선명했습니다. 묵자 예제와 점자 결과 예제에는 제목, 문단, 순서 있는 목록과 순서 없는 목록, 강조, 묵자·점자 페이지 번호, 언어와 점자 등급이 공통 요소로 남아 있습니다. 점형만 저장하지 않고 점역 전후의 문서 구조까지 남기려 했던 것입니다. 다만 당시 스키마가 오늘날 필요한 묵자·점자 병렬 저장, 표·수식·촉각 그래픽, 기기별 재배치를 모두 해결했다고 볼 수는 없습니다. 실제 생태계로 널리 이어지지도 못했습니다.

그래도 BrailleML이 던진 질문은 낡은 것이 아닙니다. 오히려 지금 다시 필요합니다.

완성된 점자만 보관할 것인가, 그 점자를 다시 읽고 고칠 수 있는 구조까지 보관할 것인가?

BBF와 HBL, SBF와 BLB, DXP와 DXB 같은 이름은 한국 전자점자의 역사를 보여 줍니다. 이제 필요한 것은 하나를 골라 나머지를 없애는 일이 아닙니다. 각 작업 형식이 가진 풍부한 정보를 개방형 교환 형식으로 내보내고, 오래된 파일도 새 도구로 옮길 수 있는 다리를 만드는 일입니다.10

브리핑 4. 기기를 바꾸어도 문서는 살아남는가 — 한 줄에서 촉각 화면으로

파일 형식의 차이는 기기를 바꾸는 순간 더 분명해집니다.

국내에서 익숙한 한소네 6부터 살펴보겠습니다. 기본 편집 문서는 HBL이지만 DOCX·TXT·BRL·HWP 문서도 만들 수 있고 파일을 TXT·BRL·HBL로 변환할 수 있습니다. BRL로 내보내 점자 파일을 다른 환경에 건넬 수도 있습니다. 여러 형식을 열고 바꿀 수 있다는 것은 편리하지만 원래 문서의 구조와 편집 정보가 변환 뒤에도 그대로 보존된다는 뜻은 아닙니다.11

해외 단말도 사정은 비슷합니다. Brailliant BI X와 Mantis Q40 같은 단일 행 단말, Orbit Reader 40 같은 점자 리더, Canute 360과 Monarch처럼 여러 줄을 표시하는 장치가 같은 파일을 지원한다고 적혀 있어도 저장 형식과 탐색 방법, 줄과 페이지를 처리하는 방식은 저마다 다릅니다. 일반 문서를 여는 편집기와 BRF·BRL을 다루는 점자 편집기, eBraille·EPUB·DAISY를 읽는 도서 앱이 따로 움직이기도 합니다.12

이 사례들은 ‘BRF 지원’이라는 한 문장이 얼마나 많은 조건을 감추는지 보여 줍니다. 파일을 열 수 있다는 것과 읽기 좋은 모양으로 나타난다는 것은 다릅니다. 25줄짜리 종이 점자 페이지를 9줄 화면에 띄울 때 어디에서 화면을 나눌지, 40칸 표를 20칸 단말에서 어떻게 읽을지, 머리말과 페이지 번호를 계속 보여 줄지도 정해야 합니다.

여러 줄의 점자와 촉각 그래픽을 표시하는 장치에서는 이 차이가 더 커집니다. 문장을 한 줄씩 보내는 데서 그치지 않고 표의 행과 열, 수식의 공간 관계, 그래프와 설명의 연결을 화면 전체에 배치해야 하기 때문입니다.13

가현욱 KAIST 교수는 8월 7일 한국시각장애교육·재활학회 발표에서 이 변화를 ‘점자 파일’에서 ‘촉각 지식 시스템’으로의 이동이라고 설명했습니다. 기존 파일이 점형을 순서대로 저장해 고정된 페이지에 출력했다면 앞으로의 시스템은 문서의 의미와 구조를 가진 콘텐츠를 기기에 맞게 재배치해야 한다는 제안입니다. 사용자는 공간을 탐색하며 필요한 내용을 선택하고 확대하거나 질의할 수 있어야 합니다.13

이런 변화가 새로운 비싼 기기에만 머물러서는 안 됩니다. 한 줄 점자 정보 단말기에서도 제목으로 이동하고 표를 목록형으로 바꾸어 읽으며 각주와 본문을 오갈 수 있다면 구조화된 파일의 이점을 누릴 수 있습니다. 여러 줄을 표시하는 장치에서는 같은 표와 수식을 공간 배치와 촉각 그래픽으로 펼쳐 볼 수 있습니다. 기기마다 파일을 따로 만들 것이 아니라, 제목·목록·표 같은 문서 구조를 하나의 파일에 담아 두어야 합니다. 그러면 각 기기가 화면 크기와 기능에 맞게 같은 문서를 보여 줄 수 있습니다.

그러려면 제조사가 ‘지원 파일 형식’ 목록을 내놓는 데서 그치지 말고 수정한 뒤 원래 형식으로 저장되는지, 점역된 파일을 그대로 읽는지 다시 점역하는지, 제목·목록·표·링크를 탐색할 수 있는지, 오래된 파일을 새 형식으로 변환할 수 있는지도 함께 알려 주어야 합니다. 사용자가 기기를 바꾸었다는 이유로 자신의 문서와 독서 기록을 버리는 일이 있어서는 안 됩니다.

브리핑 5. eBraille 1.0 다음의 질문 — 역점역할 수 있는 전자점자

2025년 8월 14일 DAISY Consortium은 eBraille 1.0을 공개했습니다. eBraille은 EPUB 3와 호환되는 웹 기술을 바탕으로 검수된 점자와 문서 구조를 함께 담는 형식입니다. 확장자는 .ebrl이며 점형은 유니코드 점자 패턴으로 기록합니다.14

BRF에서 사라졌던 제목, 문단, 목록, 표, 링크와 목차가 문서 구조로 돌아옵니다. 줄 수와 칸 수도 기기에 맞게 다시 배치할 수 있습니다. 점자와 촉각 그래픽, 대체 설명은 한 묶음으로 전달할 수 있습니다. 어떤 점자 체계와 셀 유형을 썼는지, 어느 원전을 옮겼는지도 메타데이터로 남깁니다.

그러나 eBraille 1.0이 모든 문제의 종착점은 아닙니다. 이미 점역하고 검수한 점자를 잘 전달하는 데 무게를 둔 형식이며, 종이 점자 인쇄와 복잡한 전문점자 지원은 앞으로 보완할 과제로 남아 있습니다.15 역점역도 저절로 해결되지 않습니다. 하나의 점형이 문장부호와 수학 기호, 약자 가운데 무엇인지 문맥에 따라 달라지고 점역 과정에서 원문의 일부 정보가 생략될 수 있기 때문입니다.16

점자를 주매체로 쓰는 사람이라면 “왜 굳이 묵자로 되돌려야 하는가”라고 물을 수 있습니다. 타당한 질문입니다. 혼자 읽고 쓰는 일이라면 점자는 그 자체로 완결된 문자입니다. 역점역을 점자를 보완하거나 완성하는 절차처럼 말해서는 안 됩니다.

역점역의 가치가 커지는 곳은 점자와 묵자를 쓰는 사람과 프로그램이 만나는 자리입니다. 점자 정보 단말기의 한 점형에 커서를 놓았을 때 대응하는 묵자가 강조되고, 교사가 묵자의 한 단어나 수식을 선택했을 때 학생의 점자 표시장치에서도 해당 점형이 선택된다면 두 사람은 같은 위치를 가리킬 수 있습니다. 이 방향의 일부는 한소네 6의 묵자·시각 점자 화면, 점역 엔진의 위치 대응 정보, 화면 읽기 프로그램의 점자 보기 창과 원격 점자 수업 도구에서 이미 나타나고 있습니다.17

이런 양방향 정렬은 줄글의 철자와 문장부호를 함께 확인하는 데서 시작해 표와 목록의 행·열, 수식과 그래프의 요소, 음악 점자의 음표·리듬·악상 기호를 함께 짚는 데까지 쓰일 수 있습니다. 점자를 묵자로 바꾸어 없애는 기술이 아니라, 점자를 주매체로 유지하면서 교수·학습과 공동 작업의 통로를 넓히는 기술입니다.

메타데이터 없는 오래된 점자 ASCII 파일도 포기할 필요는 없습니다. 규칙·통계 기반 기계번역이 신경망과 대규모 언어 모델을 만나 문맥을 더 잘 다루게 된 것처럼 앞으로 AI도 긴 점자 문맥에서 언어와 점자 체계, 약자와 기호의 쓰임을 추정할 수 있게 될 것입니다. 점자 ASCII를 직접 묵자로 바꾸거나 일부 표지가 사라진 점자를 문맥으로 복원하는 연구도 시작됐습니다.18

다만 이는 원문을 그대로 꺼내는 ‘복원’보다 문맥상 가장 그럴듯한 원문을 만드는 ‘추론’에 가깝습니다. 서로 다른 원문이 같은 점자로 줄어든 경우에는 AI도 원래 표현을 증명할 수 없습니다. 그래서 AI 역점역 기술이 발전해도 원문·점자 규정·점역 이력을 보존해야 할 이유는 사라지지 않습니다.

한글 점자에서는 점자 규정 자체의 구조도 함께 살펴야 합니다. 노영관 이사는 한글 점자의 약자·약어와 문맥 의존적 예외, 초성·종성의 비대칭이 자동 역점역의 모호성을 키운다고 분석했습니다. 알고리즘의 발전만으로는 부족하고 점자 규정의 정밀화가 함께 필요하다는 제안입니다.19

가현욱 교수의 제안은 구조화된 원문에서 시작합니다. 원문을 분석해 K-Braille로 점역한 다음 자동 규정 검사와 전문가 감수를 거칩니다. 그 결과를 eBraille로 포장해 기기별로 출력하는 흐름입니다. AI는 점역 전문가를 없애는 대신 초안을 만들고 구조를 분석하며 오류를 찾는 역할을 맡습니다.20

이 흐름을 보며 저는 2006년 BrailleML을 다시 생각했습니다. 당시에도 표준 이름에 점역과 역점역을 함께 넣고 묵자와 점자의 문서 구조를 공통 요소로 표현하려 했습니다. 20년이 흐른 지금 eBraille과 K-Braille은 그 질문을 더 넓은 기술과 생태계 안에서 다시 꺼내고 있습니다.

앞으로 필요한 포맷과 제작 체계에는 최소한 다섯 가지가 들어가야 한다고 봅니다.

  1. 원문과 검수된 점자의 연결: 점자만 남기지 않고 어느 원문 구간이 어느 점자 구간으로 옮겨졌는지 추적할 수 있어야 합니다. 이 대응 정보로 묵자와 점자의 커서·선택 영역도 함께 움직일 수 있어야 합니다.
  2. 의미 구조의 보존: 제목, 문단, 목록, 표, 수식, 그림 설명에 공통 식별자를 두어 기기가 바뀌어도 관계를 잃지 않아야 합니다.
  3. 점역 조건의 기록: 언어, 점자 규정과 버전, 약자 수준, 6점·8점 여부, 수학·음악·컴퓨터 점자 같은 전문 영역, 점역 엔진과 교정 정보를 남겨야 합니다. 여러 점자 체계가 섞인 문서에서는 이 정보를 문서 전체가 아니라 해당 구간에 연결해야 합니다.
  4. 공개된 변환 경로: 전용 작업 파일에서 개방형 교환 형식으로 내보내고 다시 불러올 수 있어야 하며, 오래된 BBF·HBL·BLB 같은 자료도 옮길 도구가 필요합니다.
  5. 점역·역점역 결과 비교: 묵자를 점자로 옮긴 결과만 평가하지 말고, 그 점자를 다시 묵자로 되돌려 원문과 비교해야 합니다. 이때 무엇이 보존되고 무엇이 모호해지는지도 함께 확인해야 합니다.

정확한 역점역을 원한다면 점자 결과만 더 잘 저장해서는 부족합니다. 원문과 구조는 물론 적용한 규칙과 사람이 교정한 판단까지 함께 보존해야 합니다. 파일 형식은 그 정보를 담는 그릇입니다. 점자 규정과 점역 엔진, 검수 절차와 읽기 기기까지 함께 갖춰져야 점역한 결과를 다시 묵자로 되돌려 확인할 수 있습니다.

마치며

전자점자 버튼을 누르면 파일 하나가 다운로드됩니다.

예전에는 그 파일을 열 수 있는지만 확인하면 됐습니다. 한소네에서 읽히는지, 점자 프린터로 찍히는지, 글자가 깨지지 않는지가 중요했습니다. 물론 이런 것들은 지금도 중요합니다. 파일이 아예 열리지 않으면 그다음 질문은 시작할 수도 없기 때문입니다.

하지만 이제는 한 걸음 더 나가야 합니다.

그 파일에서 제목으로 이동할 수 있습니까? 표와 수식의 구조를 잃지 않고 읽을 수 있습니까? 20칸 단말과 40칸 단말, 여러 줄의 촉각 화면에서 각자 알맞게 출력됩니까? 다른 제조사의 기기로 옮겨도 살아남습니까? 사용자가 점자로 고친 문서를 묵자로 되돌려 동료와 함께 검토할 수 있습니까? 10년 뒤 지금의 프로그램이 사라져도 다시 열 수 있습니까?

BRF가 오랫동안 전자점자의 공용어가 된 데에는 이유가 있습니다. 단순했고, 작았고, 여러 기기에서 읽혔습니다. BBF와 HBL, 점역 프로그램의 전용 형식도 각자의 환경에서 필요한 일을 해왔습니다. 그 역사를 케케묵은 과거지사로 치부할 수는 없습니다. 다만 전자점자가 책 한 권을 종이에 인쇄하는 파일에서 학습과 업무, 표와 수식, 촉각 그래픽을 오가는 문서로 넓어졌다면 이를 담는 그릇도 달라져야 합니다.

eBraille 1.0은 그 변화를 향한 중요한 출발점입니다. 그러나 새 확장자 하나만으로 오래된 파일이 저절로 살아나거나 한글 역점역의 모호성이 사라지지는 않습니다. 20년 전 BrailleML이 묻던 구조와 역점역의 문제, 오늘 K-Braille과 학술대회 발표가 묻는 규정·검증·기기 생태계의 문제를 함께 이어 가야 합니다.

저는 전자점자의 미래를 ‘더 많은 점자 파일’이라는 말로만 그려서는 부족하다고 생각합니다. 필요한 것은 다른 기기에서도 읽히고, 다른 사람과 함께 고칠 수 있고, 시간이 흘러도 다시 되읽을 수 있는 점자 문서입니다.

점자는 손끝에 나타났다가 사라지는 핀의 배열만이 아닙니다. 읽고 쓰고 고치고 남기는 문자입니다. 전자점자 파일도 그 문자의 시간을 끝까지 품을 수 있어야 합니다.

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

Footnotes

  1. 점자 제판 인쇄는 한 쌍의 금속판에 점형을 타각한 뒤 판 사이에 종이를 넣고 압축 롤러를 통과시켜 종이에 점을 올리는 방식입니다. KTV는 송암박두성기념관의 제판기를 아연판에 점을 찍어 원판을 만드는 기계로 소개하고, 원판 사이에 종이를 넣어 롤러로 미는 과정을 보여 줍니다. 국가유산 디지털 서비스에도 점자원판, 제판기, 점자인쇄기(로울러)가 「훈맹정음」 제작·보급 유물로 등록돼 있습니다. 한국시각장애인연합회 자료에 따르면 제생원 맹아부는 1913년 점자제판기와 인쇄기를 구입해 한국 최초의 점자 교과서를 만들었고, 당시에는 점자키와 발 페달로 아연판을 찍고 손으로 롤러를 돌렸습니다. 2006년 인쇄 현장 취재와 점자제판기 특허 문헌은 예전에는 아연판, 이후에는 알루미늄판을 많이 썼으며, 원판 인쇄는 주로 다량 제작에, 컴퓨터 점자 프린터는 소량 제작에 사용됐다고 설명합니다. 자동 점자제판기도 점역 프로그램의 데이터를 받아 금속판을 타각할 수 있으므로, 아날로그 제판과 전자 파일의 경계가 언제나 장비 이름만으로 갈리는 것은 아닙니다. 이 글에서 ‘원판 인쇄’는 금속 원판 사이에 종이를 넣고 압축 롤러를 통과시켜 종이에 점을 올리는 방식을 가리킵니다. 자료에 따라 압입 방식, 아연판 압착식 등의 이름도 사용합니다. 함께 읽기: 제19호 ‘훈맹정음 100주년’. | KTV 국민방송, 「한글점자 ‘훈맹정음’···시각장애인 첫 문화유산 등록」(2021.1.25.), 국가유산 디지털 서비스, 「한글점자 『훈맹정음』 제작 및 보급 유물」, 한국시각장애인연합회, 「점자교과서는 언제부터 만들어졌을까?」, 프린팅코리아, 「점자출판인쇄, 여섯 개의 점으로 세상을 열다」(2006.6.), Google Patents, 「점자제판기」, 통인, 「점자인쇄방식」 ↩ ↩2 ↩3

  2. 「점자법」 제3조는 전자점자를 “점자정보단말기 등에서 활용 가능하도록 전자적으로 생성된 점자”로 정의합니다. 이 정의는 특정 확장자나 인코딩을 지정하지 않으므로, 전자점자라는 법적 범주와 BRF·BRL·BBF 같은 개별 파일 형식은 구분해야 합니다. 함께 읽기: 제19호 ‘점자법 10년’. | 국가법령정보센터, 「점자법」 제3조 ↩

  3. Braille Authority of North America는 점자 ASCII를 점자 규정과 구분해, 6점 점자의 모든 점 조합을 출력 가능한 ASCII 문자 64개로 표현하는 디지털 대응 방식으로 설명합니다. 예를 들어 표준 대응표에서 A는 1점, J는 2-4-5점, 숫자 1은 2점, 등호 =은 여섯 점을 모두 올린 온점인 1-2-3-4-5-6점을 나타냅니다. 이때 A가 묵자 알파벳 A를 뜻하는 것은 아닙니다. 화면에서는 일반 ASCII 문자처럼 보이지만, 점자 프로그램과 단말기는 대응하는 점형으로 해석합니다. NewJumja 같은 점자 글꼴을 적용하면 저장된 ASCII 문자값은 바꾸지 않은 채 화면이나 인쇄물에서 대응하는 6점 점형으로 확인할 수 있습니다. 일반 글꼴을 적용하면 같은 데이터가 다시 A, J, 1, = 같은 ASCII 문자로 보입니다. 따라서 이런 글꼴은 점자 ASCII를 유니코드 점자로 변환하는 도구가 아니라, 점형으로 보여 주는 표현 방식입니다. 한컴오피스 도움말도 6점 점자 ASCII에는 NewJumja와 같은 특정 점자 글꼴이 필요하지만, 8점 유니코드 점자는 글꼴에 관계없이 점형으로 표시된다고 구분합니다. | Braille Authority of North America, 「BANA Positions on Computer Braille Code and Braille ASCII」(2020), 한컴오피스 도움말, 「점자로 바꾸기 설정」 ↩

  4. 미국 의회도서관의 포맷 설명은 BRF를 점자 ASCII와 공백·캐리지 리턴·줄바꿈·폼 피드로 완성된 점자 페이지를 나타내는 단순 텍스트 파일로 정리하면서도, 권위 있는 단일 공식 표준은 없다고 밝힙니다. 실제 구현은 더 느슨합니다. Orbit Reader 40은 편집 결과를 BRF로 저장하지만 페이지 이동 시 다음 폼 피드 또는 약 1,000자 가운데 먼저 만나는 지점으로 이동하고, 폼 피드가 없는 파일은 약 1,000자씩 나눕니다. 따라서 BRF에 줄바꿈만 있고 명시적인 페이지 경계가 없을 수도 있습니다. Duxbury는 페이지가 조판된 BRF라도 결과 ‘페이지 이미지’만 보존하므로 재편집·재배치·역점역 과정에서 제목, 머리말, 페이지 번호 같은 구조를 다시 추정해야 한다고 설명합니다. | Library of Congress, 「Braille Ready Format」, Orbit Research, 「Orbit Reader 40 Support」, Duxbury Systems, 「BRF Files」 ↩ ↩2

  5. BRL은 MicroBraille 파일 확장자로 출발한 역사가 있지만 하나의 엄밀한 공통 규격으로 굳지 않았습니다. Duxbury는 점자 정보 단말기의 BRL이 보통 문단 하나를 한 줄로 길게 저장한다고 설명합니다. Braillists Foundation은 어떤 BRL은 BRF와 확장자만 다르고, 다른 BRL은 같은 점자 ASCII를 쓰되 조판 정보가 적다고 정리합니다. Orbit Reader 40은 BRF를 ‘서식 있는 점자’, BRL을 ‘비서식 점자’라고 구분하면서도 두 파일이 기기에서는 비슷하게 동작한다고 안내합니다. 따라서 확장자만으로 줄바꿈·페이지 구조·인코딩·점자 규정을 확정할 수 없습니다. | Duxbury Systems, 「What Was New in Previous Versions?」, Braillists Foundation, 「BRF Files」, Orbit Research, 「Orbit Reader 40 Support」 ↩

  6. 국립장애인도서관은 전자점자도서와 전자점자악보를 한국 점자 규정에 따라 점역한 파일로 설명하고, 이용 가능한 파일 형식으로 BBF·BRF·BRL을 안내합니다. 이 안내는 국내 도서관 서비스에서 세 형식이 실제 유통돼 왔음을 보여 주지만, 각 형식의 내부 명세까지 설명하지는 않습니다. | 국립장애인도서관, 「대체자료 이용안내」 ↩

  7. 미국 의회도서관은 BrailleSense File Format의 확장자를 HBL로 기록하고, 한소네·BrailleSense 워드프로세서에서 사용하는 폐쇄형 점자 텍스트 형식으로 설명합니다. 공개된 내부 구조도 없습니다. 국립국어원의 2025년 점역 소프트웨어 기능 개선 보고서에는 점사랑 7.0의 BLB·BRF·BRL 문서 열기와 한소네 연동이 나오지만 HBL 직접 열기는 확인되지 않습니다. 여기서 한소네 연동은 글자·단어·줄·문단 이동, 커서 확인, 입력·삭제처럼 한소네를 점자 표시 장치와 입력 장치로 사용하는 기능입니다. 실로암브레일의 공개 제품 정보도 한소네 연동과 브레일서울·브레일베스트 문서 활용을 안내하지만 HBL 직접 열기는 밝히지 않습니다. 따라서 현재 공개 자료만으로는 점사랑이나 다른 국내 점역 프로그램이 HBL을 직접 읽는다고 단정하기 어렵습니다. 한소네 6에서 HBL을 BRL·TXT 같은 형식으로 변환한 뒤 가져오는 경로가 현실적이지만, 이 과정에서 HBL의 서식과 편집 정보가 손실될 수 있습니다. HBF는 일부 과거 HIMS 자료에 등장하지만 한소네 워드프로세서의 공식 기본 확장자라는 근거를 확인하지 못했습니다. | Library of Congress, 「BrailleSense File Format」, 국립국어원, 「2025년 점역 소프트웨어 기능 개선」 최종보고서, 한국장애인고용공단 보조공학기기 전용몰, 「실로암브레일 프로페셔널」, 셀바스헬스케어, 「한소네 6 사용자 설명서」 ↩

  8. Duxbury DBT는 묵자 작업 파일 DXP와 점자 작업 파일 DXB를 사용합니다. 점사랑은 점역 전 묵자와 점역 코드를 편집하는 BLT, 점역 결과를 편집하는 BLB를 사용합니다. 실로암브레일 프로페셔널은 편집용 SBF와 출력용 BBF를 만들며, 브레일서울·브레일베스트 문서는 문서 최적화 뒤 활용합니다. 하상브레일의 HSB는 국내 전자점자 변환 특허 문헌에 편집용 형식으로 나타나지만 하상 측 공식 명세에서는 재확인하지 못했습니다. 이런 작업 파일은 최종 배포 파일보다 점역 코드와 편집 정보를 더 많이 담을 수 있으나 공개 명세와 변환 경로는 별도로 확인해야 합니다. 함께 읽기: 제19호 ‘점사랑 7.0과 한소네 7’. | Duxbury Systems, 「DBT File Import」, 국립국어원 점자 종합 정보 누리집, 한국장애인고용공단 보조공학기기 전용몰, 「실로암브레일 프로페셔널」, Google Patents, 「전자문서의 점자 변환 시스템」 ↩

  9. TTA는 2006년 12월 27일 TTAS.KO-09.0039 「점역 및 역점역을 위한 XML 기반 기술 언어(BrailleML) 정의 1.0」을 제정했습니다. 공개 페이지는 표준의 개념·요소·속성·용례·XML 스키마를 다룬다고 설명하며 현재 유효 표준으로 표시합니다. 필자가 보관한 당시 XSD와 예제에는 묵자·점자 문서의 제목, 문단, 목록, 언어·점자 등급, 페이지 정보를 표현하는 요소가 남아 있습니다. 다만 그 스키마가 오늘날의 모든 병렬 말뭉치·표·수식·촉각 그래픽 요구를 충족한다는 뜻은 아닙니다. | TTA, 「점역 및 역점역을 위한 XML 기반 기술 언어(BrailleML) 정의 1.0」 ↩

  10. ODF(OpenDocument Format)는 개방형 교환 형식의 선례를 보여 줍니다. OASIS의 ODF 1.3은 특정 응용프로그램이나 운영체제에 종속되지 않는 XML 기반 문서 형식과 이를 읽고 쓰고 처리하는 소프트웨어의 동작을 규정합니다. ODF 1.2의 문서 스키마는 ISO/IEC 26300-1:2015로 채택되었습니다. 다만 ODF가 검수된 점자를 직접 담거나 BBF·HBL·BLB를 변환한다는 뜻은 아닙니다. 이 사례가 보여 주는 것은 공개 명세와 패키지 구조, 읽기·쓰기 규칙이 여러 구현과 변환 도구가 만들어질 토대가 된다는 점입니다. 전자점자에도 이에 해당하는 공개 명세와 오래된 형식을 옮길 도구가 필요합니다. 함께 읽기: 제10호 ‘HWPX와 개방형 포맷’, 제10호 ‘rHWP와 HOP, 문서 도구가 열릴 때’. | OASIS, 「Open Document Format for Office Applications (OpenDocument) Version 1.3」, ISO, 「ISO/IEC 26300-1:2015」 ↩

  11. 한소네 6 사용자 설명서는 파일 관리자에서 DOCX·TXT·BRL·HBL·HWP 새 문서를 만들고, 선택한 문서를 TXT·BRL·HBL로 변환할 수 있다고 안내합니다. 워드프로세서의 기본 저장 이름은 noname.hbl이며, 내보내기 기능은 현재 문서를 BRL로 저장합니다. 미국 의회도서관은 HBL을 한소네·BrailleSense의 기본 폐쇄형 문서 형식으로 분류하고 내부 구조에 관한 공개 정보가 없다고 설명합니다. 따라서 HBL·BRL·일반 문서 사이의 변환은 가능해도 문서 구조와 편집 정보가 무손실로 왕복한다고 단정할 수 없습니다. | 셀바스헬스케어, 「한소네 6 2.0 버전 사용자 매뉴얼」, 사용자 매뉴얼 직접 내려받기, Library of Congress, 「BrailleSense File Format」 ↩

  12. Brailliant BI X·Mantis Q40·Chameleon 20의 v2.6 설명서는 일반 편집기, 점자 편집기, 도서 읽기 프로그램의 지원 형식을 따로 제시합니다. 일반 편집기는 DOCX·BRF·BRL 등을 열 수 있지만 수정본은 TXT로 저장하고, 점자 편집기는 BRF·BRL을 열어 BRF로 저장합니다. 도서 앱은 eBraille의 eBRL도 읽습니다. 반면 Orbit Reader 40은 TXT·BRF·BRL 중심의 단순한 읽기·편집 환경이고, Canute 360은 40칸 9줄에서 BRF·PEF를 읽되 BRF를 한 면 9줄·한 줄 40칸에 맞추도록 권합니다. | HumanWare, 「Brailliant BI X Series User Guide v2.6」, APH, 「Mantis Q40 User Guide v2.6」, APH, 「Chameleon 20 User Guide v2.6」, Orbit Research, 「Orbit Reader 40 Support」, Bristol Braille Technology, 「Canute 360 User Manual」 ↩

  13. 가현욱 교수는 2026년 8월 7일 발행된 제45차 한국시각장애교육·재활학회 학술대회 자료집 수록 원고에서 한 줄 점자 정보 단말기와 ‘다행·공간적 촉각 디스플레이’를 비교하고, 구조화된 원문·의미 분석·K-Braille 점역·규정 검사·전문가 감수·eBraille 패키징·기기별 출력을 잇는 ‘지능형 촉각 인터페이스’ 구조를 제안했습니다. 발표 자료에서 ‘다행’은 점자를 여러 행으로 표시한다는 뜻으로 쓰였습니다. Monarch v1.4 설명서는 eBraille 텍스트·촉각 그래픽·목차 탐색을 베타 기능으로 안내합니다. 기기 사양과 지원 현황은 제품 업데이트에 따라 달라질 수 있습니다. 함께 읽기: 제3호 ‘LG전자 × Dot Inc. 접근성 키오스크’. | 가현욱. (2026.8.7.). 「인공지능·디지털 전환 시대의 점자: 읽고 쓰는 문자를 넘어 지능형 촉각 인터페이스와 권리 인프라로」. 『제45차 한국시각장애교육·재활학회 학술대회 자료집』. 학술대회 안내, APH, 「Monarch User Guide v1.4」 ↩ ↩2

  14. eBraille 1.0은 EPUB 3 호환 파일 집합과 XHTML·CSS 등 개방형 웹 기술을 사용하며, 패키지 확장자는 .ebrl입니다. 본문은 ASCII 점자 대응 문자가 아니라 유니코드 점자 패턴 U+2800~U+28FF를 사용하도록 권고합니다. 제목·목록·표·링크 같은 의미 구조와 목차 탐색, 기기별 재배치를 지원하며 JPG·PNG·SVG·PDF 그래픽 리소스와 대체 설명을 같은 패키지 안에 전달할 수 있습니다. 이는 촉각 도형 자체의 새 범용 인코딩을 정의했다는 뜻은 아닙니다. 함께 읽기: 제20호 ‘책은 언제 접근 가능해지는가’. | DAISY Consortium, 「eBraille 1.0」(2025.8.14.) ↩

  15. eBraille 1.0 사양은 전자 점자 표시장치, 특히 서로 다른 줄 길이에 적응하는 독서 경험을 우선합니다. 사양의 향후 과제에는 복잡한 형식 지원, CSS 확장, 종이 점자 압인 지원이 포함돼 있습니다. DAISY의 2025년 말 프로젝트 현황은 DAISY Pipeline, 검사기, BRF 변환기, 일부 단말 지원이 개발·시험 단계에 있음을 보여 줍니다. 따라서 표준 공개와 국내외 전체 생태계의 정착은 구분해야 합니다. | DAISY Consortium, 「eBraille 1.0」, DAISY Consortium, 「eBraille Project Update」 ↩

  16. Liblouis는 역점역을 점자에서 묵자로 되돌리는 과정으로 정의하며, 많은 점자 규정이 원문의 일부 정보를 생략하거나 한 점형을 문장부호·수학 기호·약자로 함께 사용하기 때문에 점역보다 역점역이 어렵다고 설명합니다. 모든 글을 점역한 뒤 원문과 완전히 같게 되돌리는 것은 이상적인 목표지만 실제로는 보장하기 어렵고, 역점역을 중시하는 점자와 읽기 좋은 문학 점자에 서로 다른 규칙이 필요할 수도 있다고 지적합니다. | Liblouis, 「Notes on Back-Translation」 ↩

  17. 묵자와 점자의 양방향 위치 대응은 전혀 새로운 발상만은 아닙니다. 한소네 6은 점자 키보드로 입력하거나 단말기에 표시한 내용을 내장 LCD와 USB-C 외부 화면에서 묵자로 볼 수 있습니다. 설명서의 ‘HDMI에 가상 점자 표시’ 옵션은 외부 화면 아래쪽에 점자 표시장치의 시각적 점형과 그 묵자 번역을 함께 보여 줍니다. Liblouis의 lou_translate 함수는 화면 읽기 프로그램에서 쓰도록 원문의 각 위치에 대응하는 점자 출력 위치(outputPos), 각 점자 위치에 대응하는 원문 위치(inputPos), 입력과 출력의 커서 위치(cursorPos)를 돌려줍니다. NVDA의 Braille Viewer는 점자 표시장치에 나오는 내용을 묵자와 시각적 점자로 동시에 보여 주어 교사가 학생의 출력을 확인할 수 있게 합니다. Orbit Teacher는 학생이 읽거나 쓰는 점자를 실시간 묵자로 보여 주고 교사가 입력한 내용을 학생의 점자 표시장치로 보냅니다. Monarch는 외부 화면에 사용자가 촉각 화면에서 보는 내용을 묵자 또는 시각적 점자로 나타내며, 수학 수식을 Nemeth·UEB 수학 점자로 표시하고 교사와 학생이 같은 내용을 확인하는 사례를 제시합니다. 다만 이 기능들이 모든 전자점자 문서에서 문자·수식·표·음악 기호의 선택 영역을 완전하게 양방향 동기화하는 공통 표준을 이룬 것은 아닙니다. | 셀바스헬스케어, 「한소네 6 사용자 설명서」, HIMS International, 「BrailleSense 6」, Liblouis, 「lou_translate」, PRCVI, 「New NVDA Features for Teachers」, Perkins School for the Blind, 「Introducing the Orbit Teacher Platform」, APH, 「Building Connections with Monarch and Visual Outputs」, APH, 「Using the Monarch in High Level Courses」 ↩

  18. 번역 기술의 발전은 이 전망을 뒷받침하는 비유입니다. Google의 2016년 GNMT 연구는 고립된 단문에 대한 사람 평가에서 신경망 번역이 당시 구문 기반 상용 시스템보다 번역 오류를 평균 60% 줄였다고 보고했습니다. 2024년 GPT-4 비교 연구에서는 고자원 언어에서 초급 인간 번역가와 비슷한 오류 수준을 보였지만 중급·고급 번역가와 저자원 언어에는 격차가 남았습니다. 점자 분야에서는 2025년 BrailleLLM이 점자 ASCII가 문자·영단어·문장부호·수학 기호 등으로 중의적으로 해석되는 문제를 문맥 학습 과제로 다루고, 자체 중국어·영어 혼합 점자 자료에서 기존 미세조정 모델보다 높은 역점역 성능을 보고했습니다. 중국 점자를 대상으로 한 2026년 Vision-Braille 연구는 성조 표지의 90%를 제거한 문단 단위 입력에서 BLEU-4 83.28을, 중국 점자도서관 전문가가 만든 짧은 문단 세 개에서는 후처리 뒤 평균 83.95를 보고했습니다. 다만 두 점자 연구는 현재 arXiv에 공개된 사전 공개 논문이며, 중국어·영어의 특정 자료와 점자 규칙으로 학습·평가했습니다. 언어와 점자 체계조차 알려지지 않은 임의의 오래된 BRF·BRL 파일을 자동 판별한 결과는 아닙니다. BLEU 점수도 원문의 철자와 기호가 한 글자도 다르지 않게 복원됐다는 뜻은 아닙니다. | Wu et al., 「Google’s Neural Machine Translation System」(2016), Yan et al., 「GPT-4 vs. Human Translators」(2024), Huang et al., 「BrailleLLM」(2025), Wu et al., 「Vision-Braille」(2026) ↩

  19. 노영관 이사는 제45차 한국시각장애교육·재활학회 발행 자료집에 수록된 정보접근 분과 원고에서 현대 한글 11,172음절 매핑을 바탕으로 남한 점자의 약자·약어와 예외 규정, 음절별 칸 수의 불균일성이 자동 역점역의 모호성과 조건문 복잡성을 키운다고 주장했습니다. 남북 점자의 평균 칸 수와 최대 칸 수 비교는 저자의 분석 결과이며, 이 글은 규정의 구조도 역점역 정확도에 영향을 줄 수 있다는 문제 제기로 인용합니다. | 노영관. (2026.8.7.). 「왜 한글 점역과 역점역은 완벽할 수 없는가? — 11,172자 완전 점역·역점역을 위한 한글 점자 규정 개선 방안」. 『제45차 한국시각장애교육·재활학회 학술대회 자료집』. 학술대회 안내 ↩

  20. KAIST 공식 발표에 따르면 K-Braille은 형태소 분석과 추상 구문 트리(AST)를 이용해 문장 구조와 맥락을 분석한 뒤 점역합니다. 국립국어원 묵자-점자 병렬 말뭉치에서 추출한 17,943문장 평가 결과로 실질 점역 규정 준수율 100.0%, 점역 형태소 구조 유사도 평균 99.81%를 제시했습니다. 제45차 학술대회 발행 원고는 이 수치가 특정 평가 자료에서의 규정 준수 결과이며 모든 실제 문서와 전문점자 영역의 무오류를 뜻하지 않는다고 명시하고, 규정 검증·전문가 검증·사용자 검증을 구분했습니다. 연구팀은 기존 BRF의 한계를 넘는 .brfx 생태계 구상도 밝혔으나 공개 사양은 이번 조사에서 확인하지 못했습니다. 함께 읽기: 제3호 ‘K-Braille 점역 엔진’. | KAIST, 「시각장애인 위한 점자 번역 엔진 K-Braille 개발」(2026.3.13.), 가현욱. (2026.8.7.). 「인공지능·디지털 전환 시대의 점자: 읽고 쓰는 문자를 넘어 지능형 촉각 인터페이스와 권리 인프라로」. 『제45차 한국시각장애교육·재활학회 학술대회 자료집』. 학술대회 안내 ↩

그래프 뷰

백링크