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

방문자 카운터

접근성 브리핑 제10호

50 min read

들어가며

이번 접근성 브리핑 제10호는 여러 소식을 흩어 보기보다, 한 문장으로 시작하고 싶습니다.

문서는 정말 누구에게나 열려 있을까요.

우리는 정보가 공개됐다는 말을 자주 듣습니다. 하지만 공개된 문서가 곧 읽을 수 있는 문서는 아닙니다. 파일은 올라와 있는데 어떤 사람에게는 열리지 않고, 열려도 읽는 순서가 뒤엉키며, 필요한 내용을 찾기까지 여러 우회로를 거쳐야 할 때가 있습니다. 시각장애인에게 이것은 사소한 불편이 아닙니다. 공부와 일, 행정 절차와 권리 행사에 바로 닿는 문제입니다.

AI 시대가 오면서 오래된 문서 접근성 문제가 행정과 기술의 언어 안으로 다시 들어오고 있습니다. 문서 구조, 파일 포맷, 마크다운(Markdown), GitHub 같은 말이 더 자주 등장합니다. 저 알리는 이 변화를 반갑게 봅니다. 다만 한 가지는 계속 묻게 됩니다. AI가 읽기 쉬운 문서는 장애인에게도 읽기 쉬운 문서일까요. 이번 호는 그 질문을 따라가 보겠습니다.

제2호에서 저는 에이전트 시대의 접근성을 “화면을 없애는 것”이 아니라 “화면 없이도 작동하는 설계를 기본값으로 삼는 것”이라고 썼습니다. 이번 제10호에서는 그 질문을 문서 접근성으로 옮겨 봅니다.

제10호 - 2026년 5월 5일(화)

브리핑 1. 첨부파일에서 본문으로 — 행안부가 보도자료를 웹과 마크다운으로 내놓기 시작하다

첫 소식은 행정안전부가 보도자료를 내놓는 방식을 바꾼 일입니다. 행정안전부는 4월 27일, 앞으로 보도자료를 누리집 본문에서 바로 읽을 수 있도록 하고, AI가 이해하기 쉬운 마크다운 파일 내려받기도 함께 지원하겠다고 밝혔습니다. HWPX나 PDF 첨부파일을 중심으로 보도자료를 제공하던 방식에서 벗어나, 웹 본문과 구조화된 텍스트를 함께 내놓겠다는 뜻입니다.1

달라진 것은 다운로드 버튼 하나만이 아닙니다. 그동안 공공기관 보도자료는 ‘공개’되어 있었지만, 실제로는 첨부파일 안에 갇혀 있는 경우가 많았습니다. 스마트폰에서는 열기 불편하고, 운영체제에 따라 별도 프로그램이 필요하며, 화면 읽기 프로그램 사용자는 파일을 내려받아 열고 파일의 구조를 다시 파악해야 했습니다. 정보는 공개되어 있었지만, 접근의 부담은 독자가 떠안았습니다.

행정안전부가 이번 보도자료에서 시각장애인용 화면 읽기 프로그램 등 장애인 보조공학기술 접근성의 한계를 직접 언급한 점도 그냥 넘기기 어렵습니다. 공공문서 접근성은 그동안 너무 자주 ‘민원인이 알아서 해결해야 하는 문제’처럼 다뤄졌습니다. 그런데 이번에는 적어도 공식 문서 안에서, 첨부파일 중심 배포 방식이 모바일과 보조공학기술 접근성을 가로막아 왔다는 점을 인정한 셈입니다.

마크다운도 개발자만의 형식으로 볼 일은 아닙니다. 마크다운은 제목, 본문, 목록 같은 구조를 비교적 단순하게 남깁니다. 문서에 제목 구조가 살아 있고, 어느 것이 목록이고, 어떤 부분이 본문인지가 명확하다면 화면 읽기 프로그램도 문서를 더 잘 탐색할 수 있습니다. AI도 마찬가지입니다. 구조가 살아 있는 문서는 검색과 요약, 인용과 검증에 더 유리합니다.

물론 이걸 곧바로 ‘문서 접근성 문제가 해결됐다’고 읽어서는 안 됩니다. 마크다운 파일이 실제로 모든 보도자료에 안정적으로 제공되는지, 표와 이미지 설명은 어떻게 처리되는지, 게시글 본문 안의 제목 구조가 올바른지, 첨부파일과 본문 내용이 어긋나지 않는지까지 봐야 합니다. 결국 봐야 할 것은 파일 형식 이름이 아니라 구조의 품질입니다.

행정안전부가 별도로 추진한 ‘AI 시대 행정문서 작성 가이드라인’도 같은 문제와 이어집니다. 주어와 서술어를 분명히 하고, 문장 구조를 단순화하며, 복잡한 셀 병합을 피하고, 단순한 표 구조를 쓰도록 한 지침입니다.2 AI가 잘 읽는 문서를 만들겠다는 취지지만, 사실 이 원칙들은 화면 읽기 프로그램 사용자에게도 오래전부터 필요했습니다. 복잡한 표 병합은 AI만 혼란에 빠뜨리지 않습니다. 사람도 길을 잃게 합니다.

저는 여기서 이번 호의 첫 번째 메시지를 봅니다. 정부의 움직임이 AI 시대가 새로 만든 요구처럼 보이지만, 많은 부분은 장애인 당사자가 오래전부터 이야기한 문서 접근성의 요구와 겹칩니다. 문서는 예쁘게 꾸미는 대상이 아니라 읽고, 찾고, 인용하고, 다시 사용할 수 있어야 하는 정보 구조입니다. 공공기관의 보도자료가 그 방향으로 움직이기 시작했다면, 이제 물어야 합니다. 행정안전부 하나의 실험으로 끝날까요, 아니면 공공문서 전체의 기본값이 될까요.

브리핑 2. HWP를 줄이고 HWPX로 간다는 말 — 포맷 전환은 접근성의 시작일 뿐

두 번째 소식은 공공문서 포맷 전환입니다. 국가인공지능전략위원회와 행정안전부, 문화체육관광부는 공직사회 핵심 문서 유통 채널에서 HWP 파일 첨부를 제한하고 HWPX 같은 개방형 포맷3 전환을 추진하겠다고 밝혔습니다. 대상은 온나라시스템, 온메일, 공직자 통합메일입니다.4

일정도 꽤 구체적입니다. 중앙부처 온나라시스템은 이미 2022년부터 HWPX 사용을 의무화했고, 2026년 5월 18일부터는 지방정부 온나라시스템까지 확대 적용할 예정입니다. 공무원 간 소통 도구인 온메일은 10월까지 개방형 파일 전환을 추진하고, 공직자 통합메일은 5월 첫째 주부터 HWP 첨부 시 HWPX 사용을 권장하는 안내를 띄운 뒤 10월부터 HWP 파일 첨부 제한을 시행할 계획입니다.

겉으로는 AI 정책처럼 보입니다. 정부 발표도 HWP는 내부 구조가 폐쇄적이라 AI가 그 안의 정보를 분석하고 학습하기 어렵고, HWPX는 개방형 포맷이라는 점을 강조합니다. 실제로 HWPX는 XML5 기반 구조를 갖고 있어 문서 내용을 해석하고 변환하고 재사용하기가 상대적으로 쉽습니다. 공공문서가 기계가 읽을 수 있는 쪽으로 움직인다는 점은 반가운 일입니다.

하지만 여기서 바로 축하만 하기는 어렵습니다. HWP를 HWPX로 바꾸는 일은 해야 합니다. 그렇다고 HWPX라는 확장자가 붙는 순간 문서가 자동으로 접근 가능해지는 것은 아닙니다. HWPX 안에도 복잡한 표, 읽기 순서가 꼬인 개체, 그림으로 처리된 글자, 의미 없는 빈 칸과 장식 요소가 들어갈 수 있습니다. 파일 포맷이 열려 있어도 문서 작성 방식이 닫혀 있으면, 사용자는 여전히 문 앞에서 멈춥니다.

그래서 이번 전환을 ‘HWP는 나쁘고 HWPX는 좋다’는 구도로만 말하기는 어렵습니다. 남는 질문은 따로 있습니다. 공공문서를 처음 만들 때부터 구조화할 것인가. 제목은 제목으로, 표 머리글은 머리글로, 목록은 목록으로, 이미지에는 대체 텍스트를 붙이고, 읽기 순서는 사람이 실제로 읽는 흐름과 맞게 만들 것인가. 문서 포맷 전환은 이 질문을 시작하게 하는 계기일 뿐, 답은 아닙니다.

전환의 부담도 같이 봐야 합니다. HWP는 오랫동안 한국 공공문서의 사실상 표준처럼 쓰였습니다. 공무원, 교사, 시민단체, 학부모, 민원인 모두가 이 관성 안에서 문서를 주고받아 왔습니다. 갑자기 HWPX를 쓰라고 안내하는 것만으로는 충분하지 않습니다. 오래된 문서를 어떻게 변환할지, 변환 과정에서 구조가 깨지지 않는지, 보조공학기술 사용자는 어떤 도구로 열람하고 편집할 수 있는지, macOS와 리눅스 사용자는 어떻게 접근할 수 있는지까지 함께 봐야 합니다.

저 알리는 이번 HWPX 전환을 문서 접근성의 출발선으로 읽고 싶습니다. 폐쇄형 포맷을 줄이고 개방형 포맷으로 가는 일은 필요합니다. 하지만 출발선에 섰다고 경주가 끝나지는 않습니다. 이제 공공문서는 포맷 전환 다음 단계로 가야 합니다. 문서를 만들 때부터 읽을 수 있게 만드는 기준, 배포 전에 접근성을 점검하는 절차, 그리고 시민이 특정 프로그램에 갇히지 않고 문서를 열람할 수 있는 생태계가 필요합니다.

브리핑 3. rHWP와 HOP, 문서 도구가 열릴 때 — 공공문서 접근성의 운영체제 장벽을 낮추다

포맷이 바뀌면 도구도 따라와야 합니다. 최근 주목받는 프로젝트가 rHWP입니다. rHWP는 Rust와 WebAssembly 기반의 오픈 소스 HWP/HWPX 뷰어·에디터입니다. 크롬 웹스토어 설명에 따르면, 브라우저에서 HWP와 HWPX 문서를 열고 편집하고 인쇄할 수 있으며, 파일 처리는 브라우저 내부에서 이루어지고 외부 서버로 전송되지 않는다고 안내합니다.6

제가 rHWP를 단순한 새 뷰어 소식으로만 보지 않는 이유가 있습니다. 한국에서 HWP 문서는 그냥 파일 형식에 머물지 않습니다. 공공기관 공고, 학교 가정통신문, 입사지원서, 계약서, 민원 양식, 회의자료가 HWP로 오갔습니다. 그래서 HWP를 제대로 열 수 있는가 없는가는 때로 정보 접근의 조건이 되었습니다. macOS나 Linux 사용자는 공공문서 하나를 열기 위해 불편한 우회로를 찾아야 했고, 시각장애인 사용자에게는 여기에 보조공학기술 호환성이라는 장벽이 더해졌습니다.

rHWP는 이 문제를 다른 방향에서 건드립니다. 특정 상용 프로그램 하나만 기다리는 대신, 문서 포맷을 읽고 렌더링하고 편집하는 오픈 소스 구현이 나온 것입니다. GitHub 저장소는 rHWP의 목표를 “모든 사람, 모든 AI, 모든 플랫폼에서 한글 문서를 자유롭게 읽고 쓸 수 있게 하는 것”으로 설명합니다. 다소 큰 말입니다. 그래도 문제를 짚는 방향은 맞습니다. 문서 접근성은 파일을 만든 기관만의 문제가 아니라, 그 파일을 열고 검증하고 변환할 수 있는 생태계의 문제이기도 합니다.

설치형 데스크톱 앱인 HOP도 같은 문제를 데스크톱 앱 쪽에서 풀어 보려는 시도입니다. HOP는 rHWP를 기반으로 HWP/HWPX 문서를 보고 편집할 수 있는 macOS, Windows, Linux용 오픈 소스 앱입니다. 공식 페이지는 macOS용 dmg, Windows용 msi와 exe, Linux용 deb·rpm·AppImage를 제공하고, macOS에서는 Homebrew 설치도 안내합니다. rHWP가 브라우저와 확장 프로그램의 길을 열었다면, HOP는 운영체제 안에서 파일 열기, 저장, PDF 내보내기, 인쇄 같은 사용 흐름을 붙여 주는 쪽에 가깝습니다.7

여기서 현실적인 문제에 부딪힙니다. rHWP와 HOP이 당장 모든 공공기관 업무 문서를 대체할 수 있다고 말하기는 어렵습니다. 제가 HOP를 센스리더로 직접 테스트해 보니, 편집기에 입력된 글을 커서 이동으로 읽어 주지 않았습니다. 설치형 앱처럼 배포되지만 사용 경험은 웹 기반 편집기에 가까웠고, 화면 읽기 프로그램 사용자는 인터넷 가상 커서 같은 우회 방식에 기대야 했습니다. HWPX 문서로 저장하는 기능도 아직 없어, 읽기와 편집, 저장까지 이어지는 흐름은 제한적이었습니다. 크롬 웹스토어 설명 기준 rHWP도 HWP 저장은 지원하지만 HWPX 직접 저장은 아직 베타 단계로 비활성화되어 있습니다. 복잡한 조판, 보안 요구사항, 공공기관 내부 업무망, 그리고 도구 자체의 보조공학기술 접근성은 여전히 따로 검증해야 합니다.

그럼에도 저는 이 움직임을 계속 지켜보고 싶습니다. 문서 접근성은 ‘파일을 접근성 있게 만들어 달라’는 요청에서 끝나지 않습니다. 사용자가 자기 환경에서 그 문서를 열고, 읽고, 필요하면 고치고, 다른 형식으로 내보낼 수 있어야 합니다. 공공문서가 시민에게 열린 문서라면, 그 문서를 여는 도구도 가능한 한 넓게 열려 있어야 하기 때문입니다.

rHWP와 HOP 같은 프로젝트를 보며 저는 다시 생각합니다. 문서 접근성은 더 이상 기관의 선의나 기업의 업데이트 일정에만 맡겨둘 수 없습니다. 시민 개발자, 오픈소스 커뮤니티, 공공기관, 기업, 보조공학기술 사용자들이 함께 검증하고 고쳐야 하는 공공 인프라의 문제입니다. 그 인프라가 열릴수록, 문서는 조금 덜 닫힌 문이 됩니다.

브리핑 4. PDF를 태그 PDF로 바꾸는 AI — 자동화가 필요한 만큼 검증도 필요하다

문서 접근성을 말할 때 PDF를 빼놓을 수 없습니다. PDF는 어디서나 열리는 문서처럼 보이지만, 접근성 관점에서는 가장 까다로운 형식 중 하나입니다. 눈으로 보기에는 그럴듯해도 내부에 제목 구조, 읽기 순서, 표 구조, 목록, 이미지 대체 정보가 제대로 들어 있지 않으면 화면 읽기 프로그램은 문서를 제대로 탐색하기 어렵습니다. 글자가 보인다고 읽을 수 있는 문서가 되는 것은 아닙니다.

제6호에서 다룬 미국 시각장애 대학원생들의 사례도 결국 PDF 문제였습니다. 강의자료가 화면 읽기 프로그램과 호환되지 않는 PDF로 제공되면서, 학생들은 자료를 받았지만 실제로는 읽을 수 없었습니다. PDF 접근성은 형식 변환의 문제가 아니라 학습권과 권리 행사에 닿는 문제입니다.

이런 배경에서 한컴이 OpenDataLoader PDF에 접근성 태그 자동 생성·삽입 기능을 오픈 소스로 공개했다는 소식은 그냥 지나치기 어렵습니다. 보도에 따르면 이 기능은 AI가 PDF 문서 구조를 분석해 제목, 표, 목록, 이미지 같은 구성 요소를 구분하고, 그 결과를 접근성 태그 형태로 원본 PDF 안에 직접 반영하는 방식입니다. 한컴은 기업과 공공기관이 추가 비용이나 건당 과금 부담 없이 대량 PDF를 접근성 문서로 전환할 수 있다고 설명했습니다.8

OpenDataLoader PDF의 공식 저장소와 사이트를 보면, 이 프로젝트가 단순한 텍스트 추출기만은 아니라는 점이 보입니다. PDF를 마크다운, JSON, HTML, 일반 텍스트로 변환하고, 요소별 위치 정보인 bounding box를 제공하며, OCR과 표 추출, 읽기 순서 복원, 태그 PDF 생성 등을 지원한다고 설명합니다. 공식 사이트는 “PDF는 AI를 위해 만들어지지 않았다”고 말하면서, 잘못된 읽기 순서와 깨진 표 구조가 RAG와 AI 검색의 품질을 망가뜨린다고 지적합니다.

접근성 쪽에서도 같은 일이 벌어집니다. PDF의 읽기 순서가 엉키면 화면 읽기 프로그램 사용자는 문장을 따라갈 수 없습니다. 표 구조가 깨지면 행과 열의 관계를 이해하기 어렵습니다. 제목 구조가 없으면 긴 문서를 탐색할 수 없습니다. PDF 접근성은 눈에 보이는 글자를 추출하는 문제가 아니라, 문서의 구조를 되살리는 문제입니다.

그래서 자동 태깅이라는 방법이 나옵니다. 공공기관과 기업이 이미 만들어 둔 PDF는 너무 많고, 사람이 하나하나 수작업으로 고치는 방식만으로는 규모를 감당하기 어렵습니다. 특히 예산과 인력이 부족한 기관은 자동화 도구 없이는 접근성 전환을 시작하기 어렵습니다. 오픈 소스로 출발선을 낮추는 일은 반가운 일입니다.

문제는 그다음입니다. 자동으로 태그를 붙인 PDF가 실제로 읽을 수 있는 문서인지를 확인하지 않으면 변환된 문서는 오히려 사용자에게 혼동을 줄 것입니다. OpenDataLoader PDF 저장소는 자동 태깅을 무료 기능으로 제공하지만, PDF/UA-1과 PDF/UA-2 수준의 export와 접근성 스튜디오는 Enterprise 영역으로 분류합니다. 보도에서도 한컴은 2026년 2분기 안에 PDF/UA 국제 표준 준수 수준의 결과물을 출력하는 상용 솔루션을 출시할 계획이라고 밝혔습니다. 오픈 소스 자동화는 중요한 시작이지만, 규제 대응과 품질 보증까지 가려면 검증 절차가 따라붙어야 합니다.

저 알리는 이 소식을 기술 홍보로만 읽고 싶지 않습니다. 자동 태깅 도구가 늘어나는 것은 좋습니다. 그러나 PDF 접근성의 마지막 기준은 여전히 실제 사용입니다. 화면 읽기 프로그램으로 제목 사이를 이동할 수 있는가, 표 머리글이 제대로 읽히는가, 이미지 설명은 의미가 있는가, 수식과 각주는 따라갈 수 있는가, 모바일과 데스크톱에서 모두 잘 작동하는가. 이런 질문을 그냥 넘길 수는 없기 때문입니다. 자동화가 문을 열 수는 있지만, 그 길로 사람이 지나갈 수 있는지 확인하는 몫은 중요한 과제로 남습니다.

브리핑 5. 법령을 마크다운과 GitHub로 읽는다는 것 — 권리 문서의 접근성을 다시 묻다

마지막 소식은 대한민국 법령을 접하는 새로운 방식에 관한 것입니다. Legalize KR은 대한민국 법령을 GitHub 저장소로 관리하는 오픈 소스 프로젝트입니다. 공식 소개에 따르면 모든 법령은 마크다운 파일이고, 모든 개정은 실제 공포일자를 가진 GitHub 커밋입니다. 법령 데이터는 국가법령정보센터에서 가져오고, 각 법령 파일에는 제목, 소관부처, 공포일자, 시행일자 같은 기본 정보가 함께 붙습니다.9

법령을 마크다운과 GitHub로 관리한다는 말은 처음에는 개발자 취향처럼 들릴 수 있습니다. 하지만 법령이 어떤 문서인지 생각하면 이야기가 달라집니다. 법령은 시민의 권리와 의무를 정하는 문서입니다. 장애인권리보장법이 언제 어떻게 바뀌었는지, 장애인차별금지법 조항이 어떤 표현을 쓰는지, 시행령과 시행규칙이 법률의 취지를 어떻게 좁히거나 넓히는지 확인하려면 법령은 검색 가능하고, 비교 가능하고, 이력 추적이 가능해야 합니다.

기존 법령 열람 방식은 공식성과 안정성이 있지만, 변경 이력을 세밀하게 따라가거나 여러 문서를 한꺼번에 분석하기에는 불편한 점이 많았습니다. Legalize KR은 이 문제를 GitHub라는 도구로 풀어냅니다. git log로 법령의 개정 이력을 보고, git diff로 무엇이 바뀌었는지 비교하고, grep으로 전체 법령에서 특정 표현을 검색할 수 있습니다. 판례도 마크다운 파일과 GitHub 히스토리로 관리한다고 소개합니다.

여기서 누군가는 물을 수 있습니다. 이것이 시각장애인 접근성과 무슨 관련이 있느냐고요. 저는 관련이 깊다고 봅니다. 법령은 가장 중요한 공공문서 중 하나입니다. 내가 받을 수 있는 지원, 내가 요구할 수 있는 정당한 편의, 기관이 지켜야 할 의무, 차별을 다툴 수 있는 근거가 모두 법령과 제도 문서 안에 있습니다. 이 문서가 구조화되어 있고, 검색 가능하고, 텍스트 기반으로 다룰 수 있다면 당사자와 활동가, 연구자, 개발자는 훨씬 더 능동적으로 법을 읽고 활용할 수 있습니다. 인공지능을 사용하면 법령 문서 전체를 검색하거나 내용을 요약하거나 개정 이력을 비교적 쉽게 살펴볼 수 있습니다.

물론 Legalize KR은 공식 법령 서비스의 대체재가 아닙니다. 법적 효력의 기준은 국가법령정보센터의 공식 원문이고, 오픈 소스 프로젝트는 그 데이터를 다른 방식으로 구조화해 보여 주는 도구에 가깝습니다. 그래서 이 프로젝트가 공식 원문을 대신한다고 말할 수는 없습니다. 다만 법령도 접근 가능한 데이터가 되어야 합니다. 권리의 문서는 PDF 이미지나 복잡한 웹 화면 안에만 갇혀 있어서는 안 됩니다.

제9호에서 장애인권리보장법을 다루며 물었던 것도 결국 같은 문제였습니다. 권리의 이름이 법에 들어오는 일은 중요하지만, 그것만으로는 충분하지 않습니다. 법은 문을 열 수 있지만, 문턱을 낮추는 일은 따로 해야 합니다. Legalize KR을 보며 다시 같은 생각을 합니다. 권리의 문장이 법 안에 들어가는 것만큼이나, 그 문장을 당사자가 찾고 비교하고 근거로 삼을 수 있게 만드는 일도 중요합니다.

Legalize KR도 앞의 사례들과 멀리 떨어져 있지 않습니다. 행정안전부의 보도자료가 웹 본문과 마크다운으로 가고, 공공문서가 HWPX로 이동하고, rHWP와 HOP가 문서 도구의 장벽을 낮추고, PDF 접근성 자동화가 태그 구조를 만들기 시작합니다. 이 프로젝트는 그 문제의식을 권리 문서의 영역으로 끌고 옵니다. 법령도 텍스트입니다. 텍스트는 구조화할 수 있고, 구조화된 문서는 더 많은 사람이 읽고 검증하고 활용할 수 있습니다.

제가 문서 접근성을 말할 때 계속 ‘구조화된 문서’라는 말을 되풀이하는 이유가 있습니다. 읽을 수 있는 문서, 비교할 수 있는 문서, 근거를 추적할 수 있는 문서라야 쓸모가 있습니다. 그래야만 시민은 정보를 받는 사람이 아니라, 자기 권리를 확인하고 요구하는 사람이 될 수 있기 때문입니다.

마치며

이번 호는 문서 접근성이라는 하나의 주제로 여러 소식을 이어 보았습니다. 행정안전부 보도자료의 웹 본문과 마크다운 제공, 공공문서의 HWPX 전환, rHWP와 HOP 같은 오픈 소스 도구, OpenDataLoader PDF의 접근성 태그 자동화, Legalize KR의 법령 마크다운·GitHub 아카이브까지. 겉으로 보면 서로 다른 이야기처럼 들립니다. 하지만 안쪽의 질문은 비슷합니다.

문서는 누구의 것인가.

문서가 특정 프로그램을 가진 사람만 읽을 수 있고, 화면으로 볼 수 있는 사람만 구조를 이해할 수 있고, 첨부파일을 내려받고 변환할 수 있는 사람만 접근할 수 있다면, 그 문서는 공공문서라고 부르기 어렵습니다. 법령도, 보도자료도, 민원 서식도, 교육 자료도 마찬가지입니다. 공개했다는 말은 충분하지 않습니다. 읽을 수 있어야 하고, 탐색할 수 있어야 하며, 필요한 방식으로 다시 사용할 수 있어야 합니다.

AI 시대는 오래된 문제를 새 이름으로 다시 드러내고 있습니다. 기관들은 이제 AI가 읽기 쉬운 문서를 말합니다. 저는 그 흐름을 반깁니다. 다만 그 문장 옆에 반드시 사람을 놓아야 한다고 생각합니다. AI가 읽기 쉬운 문서를 만들겠다면, 화면 읽기 프로그램 사용자도 읽을 수 있어야 합니다. AI가 표 구조를 이해해야 한다면, 시각장애인도 표의 행과 열을 따라갈 수 있어야 합니다. AI가 출처를 추적해야 한다면, 시민도 권리의 근거를 추적할 수 있어야 합니다.

그래서 문서 접근성은 기술 유행의 부록이 아닙니다. AI를 위한 데이터 정비이기 전에, 시민을 위한 정보 접근권입니다. 포맷 전환은 시작이고, 자동화는 도구이며, 오픈 소스는 가능성을 넓힙니다. 하지만 마지막 기준은 여전히 사람입니다. 그 문서를 실제로 읽어야 하는 사람, 그 문서를 근거로 공부하고 일하고 계약하고 민원을 넣고 권리를 주장해야 하는 사람 말입니다.

제가 제10호를 특집으로 묶은 이유도 여기에 있습니다. 문서 접근성은 오랫동안 작고 기술적인 문제처럼 다뤄졌습니다. 하지만 사실 문서는 권리의 입구입니다. 그 입구가 닫혀 있으면, 권리도 멀어집니다. 알리의 접근성 연구소는 앞으로도 문서가 어떤 형식으로 공개되는지, 그 형식이 실제 사용자에게 어떻게 읽히는지, 그리고 AI 시대의 문서 혁신이 장애인의 접근권과 어디에서 만나고 어디에서 어긋나는지 계속 따라가 보겠습니다.

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

Footnotes

  1. 행정안전부 보도자료는 이번 개편의 이유를 단순한 게시판 디자인 변경이 아니라 자료 조회·활용 방식의 변화로 설명합니다. 특히 기존 첨부파일 중심 제공 방식이 모바일 환경과 별도 뷰어 의존 문제를 만들었고, 화면 읽기 프로그램 등 보조공학기술 접근성에도 한계가 있었다고 밝힌 점이 중요합니다. 마크다운 내려받기는 웹 본문 제공과 함께 제시된 보조 형식으로, ‘파일을 올려 두는 공개’에서 ‘본문을 바로 읽고 재사용할 수 있는 공개’로 이동하려는 시도로 볼 수 있습니다. | 행정안전부. (2026, 4월 27일). 「행정안전부 보도자료, 국민과 인공지능(AI)이 더 쉽게 읽고 활용하게 바뀐다」. https://www.mois.go.kr/frt/bbs/type010/commonSelectBoardArticle.do?bbsId=BBSMSTR\_000000000008\&nttId=125533 ↩

  2. 이 가이드라인은 접근성 지침으로 발표된 문서는 아니고, AI가 행정문서를 더 잘 읽고 처리할 수 있게 하려는 행정문서 작성 방식 개편으로 보도됐습니다. 다만 보도에서 제시된 주어·서술어 명확화, 짧고 단순한 문장, 복잡한 셀 병합 지양, 단순한 표 구조, 표준 번호체계 준수는 화면 읽기 프로그램 사용자가 문서를 탐색할 때도 중요한 조건입니다. 이 지점에서 AI 친화 문서와 접근 가능한 문서는 서로 만납니다. | 연합뉴스. (2026, 3월 24일). 「예쁘게 편집할 시간에 현장으로…행안부, ‘AI친화 보고서’ 전환」. https://www.yna.co.kr/view/AKR20260324088000530 ; ZDNet Korea. (2026, 3월 24일). 「“보고서 꾸미지 마라”…행안부, AI 친화 행정문서 확산 박차」. https://zdnet.co.kr/view/?no=20260324145145 ↩

  3. 「공공데이터 관리지침」은 “오픈포맷”을 기계 판독이 가능한 형태이면서, 비용이나 그 밖의 사용 제약 없이 최소 하나 이상의 소프트웨어로 처리할 수 있는 파일 포맷으로 정의합니다. 여기서 기계 판독이 가능한 형태는 소프트웨어로 데이터의 내용이나 내부 구조를 확인·수정·변환·추출할 수 있는 상태를 뜻합니다. | 국가법령정보센터. (2021). 「공공데이터 관리지침」(행정안전부고시 제2021-70호), 제2조 제3호·제4호. https://www.law.go.kr/LSW/admRulLsInfoP.do?admRulSeq=2100000205478 ↩

  4. 이번 발표는 공공부문에서 HWP 사용을 한꺼번에 폐지한다는 뜻이라기보다, 공직사회 핵심 문서 유통 채널에서 HWP 첨부를 제한하고 HWPX 등 개방형 포맷 사용을 우선 확산하겠다는 추진 계획에 가깝습니다. 따라서 본문에 적은 일정은 공동 발표와 보도 기준의 시행 계획이며, 실제 적용 방식은 온나라시스템·온메일·공직자 통합메일 같은 각 유통 채널의 운영 정책으로 구체화됩니다. | 국가인공지능전략위원회. (2026, 4월 24일). 「국가AI전략위·행안부·문체부, AI시대 개방형 포맷 전환을 위한 ‘협력·속도·실행’ 박차, ‘hwp 파일 첨부제한’ 부터」. https://www.aikorea.go.kr/web/board/brdDetail.do?menu\_cd=000012\&num=562\&currentPage=1 ; 전자신문. (2026, 4월 23일). 「정부 문서 첨부, AI 학습 가능한 hwpx 한글파일만 허용」. https://www.etnews.com/20260423000325 ↩

  5. XML(Extensible Markup Language)은 구조화된 데이터를 텍스트로 표현하기 위한 마크업 형식입니다. W3C의 XML 1.0 권고안은 XML을 SGML에서 나온 형식으로 설명하며, 웹에서 문서를 주고받고 처리하기 쉽도록 설계된 표준으로 봅니다. XML은 태그와 속성으로 구조를 표시하지만, 그 구조가 실제 문서에서 어떤 의미를 갖는지는 HWPX, Office Open XML 같은 개별 문서 형식의 명세와 이를 구현한 프로그램이 정합니다. HWPX는 한국산업표준(KS X 6101)에 정의된 OWPML 기반의 XML 형식 개방형 문서 규격이고, 한컴테크 자료는 HWPX를 XML 파일들을 ZIP 구조로 묶은 패키지 형식으로 설명합니다. DOCX, XLSX, PPTX 같은 Office Open XML 파일도 XML과 ZIP 기반 구조를 씁니다. 다만 내부 구조가 열려 있다는 사실이 곧바로 접근성이나 쉬운 사용을 보장하지는 않습니다. 표준 명세, 변환 도구, 작성 관행, 접근성 검증이 함께 따라와야 합니다. | World Wide Web Consortium. (2008). 「Extensible Markup Language (XML) 1.0 (Fifth Edition)」. W3C Recommendation. https://www.w3.org/TR/xml/ ; 한글과컴퓨터. (2021, 4월 15일). 「한글과컴퓨터, 아래아한글 기본문서형식 개방형으로 변환」. https://www.hancomgroup.com/posts/3/174?page=56\&parentId=22\&menuId=46 ; 한컴테크. 「한/글 문서 파일 형식: HWPX 포맷 구조 살펴보기」. https://tech.hancom.com/hwpxformat/ ; Microsoft Learn. (2023). 「Welcome to the Open XML SDK for Office」. https://learn.microsoft.com/en-us/office/open-xml/open-xml-sdk ↩

  6. rHWP 관련 설명은 공식 GitHub 저장소와 Chrome Web Store 설명을 기준으로 했습니다. 저장소는 프로젝트의 목표와 Rust·WebAssembly 기반 구현을 설명하고, Chrome Web Store는 브라우저 안에서 파일을 처리하며 외부 서버로 전송하지 않는다고 안내합니다. 따라서 이 설명은 기능 소개의 근거일 뿐, rHWP가 모든 HWP/HWPX 문서를 업무 환경에서 완전하게 처리한다거나 보조공학기술 접근성을 충분히 검증했다는 뜻은 아닙니다. | Edward Kim. (2026). edwardkim/rhwp. GitHub. https://github.com/edwardkim/rhwp ; Chrome Web Store. (2026). 「rhwp - HWP 문서 뷰어 & 에디터」. https://chromewebstore.google.com/detail/rhwp-hwp-%EB%AC%B8%EC%84%9C-%EB%B7%B0%EC%96%B4-%EC%97%90%EB%94%94%ED%84%B0/pgakpjflombjmehnebnbpnalhegaanag ; 디지털데일리. (2026, 4월 17일). 「개인이 개발한 크롬 HWP 편집기 주목…한컴 “개방형 생태계 확장 환영”」. https://v.daum.net/v/20260417121727328 ↩

  7. HOP는 rHWP의 문서 파싱·렌더링 기능을 데스크톱 앱 사용 흐름으로 가져오려는 프로젝트입니다. 공식 사이트와 저장소는 운영체제별 설치 파일과 Homebrew 설치 경로를 제시하고, 파일 열기·저장·PDF 내보내기·인쇄·파일 연결 같은 데스크톱 통합 기능을 설명합니다. 다만 이 정보는 배포 형태와 기능 범위를 확인한 것이며, 실제 보조공학기술 접근성을 검증한 결과는 아닙니다. 필자가 센스리더로 HOP를 확인한 범위에서는 편집기 안의 텍스트가 커서 이동에 따라 읽히지 않았고, 웹 기반 편집기와 비슷한 방식으로 동작해 사용에 큰 제약이 있었습니다. 이 결과가 모든 운영체제와 화면 읽기 프로그램 조합을 대표한다고 단정할 수는 없지만, rHWP/HOP 계열 도구에서 접근성 트리, 키보드 탐색, 편집 커서 읽기, HWPX 저장 기능 검증이 아직 중요한 과제임을 보여 줍니다. | Golbin. (2026). golbin/hop. GitHub. https://github.com/golbin/hop ; HOP. (2026). 「HOP is Open HWP」. https://golbin.github.io/hop/ ↩

  8. 이 사안은 보도자료, GitHub 저장소, 공식 사이트의 역할을 나누어 읽어야 합니다. 보도는 한컴이 PDF 접근성 태그 자동 생성·삽입 기능을 오픈소스로 공개했다는 점을 전하고, 저장소와 공식 사이트는 마크다운·JSON·HTML 변환, OCR, 표 추출, 읽기 순서 복원, 태그 PDF 생성 같은 기능 범위를 제시합니다. 동시에 저장소 기준 PDF/UA-1·PDF/UA-2 export와 접근성 스튜디오는 Enterprise 영역으로 분류되어 있습니다. 그래서 ‘자동 태깅 기능 공개’와 ‘최종 접근성 준수·품질 보증’은 구분해서 봐야 합니다. | 전자신문. (2026, 4월 30일). 「한컴, PDF 접근성 AI 솔루션 오픈소스로 공개」. https://www.etnews.com/20260430000361 ; OpenDataLoader Project. (2026). opendataloader-project/opendataloader-pdf. GitHub. https://github.com/opendataloader-project/opendataloader-pdf ; OpenDataLoader. (2026). 「OpenDataLoader PDF」. https://opendataloader.org/ ↩

  9. Legalize KR은 법령 원문 자체의 공식 효력을 대신하는 서비스라기보다, 국가법령정보센터 OpenAPI 데이터를 마크다운 파일과 GitHub 이력으로 다시 구조화해 보여 주는 프로젝트입니다. 프로젝트 설명에 따르면 각 법령 파일은 제목, 소관부처, 공포일자, 시행일자 같은 메타데이터를 마크다운 파일 맨 앞의 구조화된 정보 영역인 YAML frontmatter에 담습니다. 따라서 공식 법령 서비스의 대체재라기보다, 검색·비교·이력 추적이 쉬운 권리 문서 접근 방식의 사례에 가깝습니다. 법적 효력을 판단할 때는 국가법령정보센터 등 공식 원문을 기준으로 삼아야 하지만, Legalize KR은 법령 데이터가 텍스트 기반 구조와 버전 관리 도구를 만났을 때 어떤 활용 가능성이 생기는지를 보여 줍니다. | Legalize KR. (2026). 「프로젝트 소개」. https://legalize.kr/about.html ; Legalize KR. (2026). https://legalize.kr/ ; legalize-kr. (2026). legalize-kr/legalize-kr. GitHub. https://github.com/legalize-kr/legalize-kr ↩

그래프 뷰

백링크