> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/ko/more-topics/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md).

# 태그가 있는 PDF 파일 소개: 내부 구조와 접근성의 과제

## 업데이트: 2026년 1월

다음을 참조하세요 [태그가 지정된 PDF를 만드는 방법에 대한 Overleaf의 안내](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs).

다음 [LaTeX 팀](https://latex-project.org/) 은 PDF 접근성의 핵심 요구사항인 PDF 자동 태깅을 가능하게 하는 새로운 기능을 출시했습니다. 이 새로운 기능은 Overleaf의 [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), 그리고 더 최근의 업데이트는 순환 TeX Live 릴리스에서 확인할 수 있습니다. [Overleaf Labs](https://www.overleaf.com/labs/participate).

이제 다음을 따르면 WCAG 2.1 레벨 AA를 준수하는 태그가 지정된 PDF를 LaTeX 소스에서 생성할 수 있습니다. [사용자 문서](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) 를 Overleaf에서 제공되는 TeX Live 릴리스를 사용하여.

아래의 2020년 기사에는 LaTeX 접근성에 대한 최신 정보는 반영되어 있지 않지만, 관심용 및 PDF 태깅에 대한 배경 정보로 계속 읽어볼 수 있습니다.

***

## 이 글은 무엇을 다루나요?

이 글의 목적은 태그가 지정된 PDF에 대한 소개와 함께, 태그가 지정되고 접근 가능한 PDF 파일을 생성하는 것을 목표로 하는 TeX 엔진과 LaTeX를 포함한 소프트웨어가 직면하는 몇 가지 기술적 과제의 개요를 제공하는 것입니다. PDF, 특히 PDF의 접근성은 폭넓고 복잡한 주제로, 접근 가능한 방식으로 PDF 안에 복잡한 수학을 표현하는 방법처럼 항상 하나의 보편적으로 합의되거나 받아들여진 해법이 없는 기술적 과제도 있습니다. MathML을 사용할까요, 아니면 LaTeX 코드를 사용할까요?

모든 주제를 깊이 있게 다룰 수는 없고 많은 세부 사항을 단순화해야 하지만, PDF 내부를 살펴보며 PDF를 태깅한다는 것이 실제로 무엇을 의미하는지 보여줄 수 있습니다. Overleaf는 이 글이 유용한 입문서가 되어, 독자들이 기술적 과제를 더 잘 이해하고 태그가 지정된 PDF와 접근성에 대해 더 읽고 탐구할 수 있도록 충분한 배경지식을 제공하기를 바랍니다. 이 글에 포함된 자료는 다음과 같습니다:

* [8분짜리 동영상](#video-showing-the-logical-structure-of-a-tagged-pdf) LaTeX로 생성된 태그가 지정된 PDF를 살펴보기;
* [Overleaf 프로젝트](#using-luatex-an-example-in-the-overleaf-gallery) LuaTeX에서 공백 문자의 사용을 살펴보기 위해;
* [사운드 녹음](#tagged-yes-but-the-reading-order-is-incorrect) PDF 접근성 문제를 보여주는.

## 소개

디지털 콘텐츠의 접근성을 보장하는 것은 콘텐츠 제작과 배포의 중요한 측면으로 정당하게 인정받고 있습니다. 더 나아가, [영국](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) 와 [미국](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf)을 포함한 정부들은 자국 관할 아래에서 제작된 콘텐츠가 정의된 접근성 기준을 준수하도록 요구하는 법률을 제정하고 있습니다. HTML 형식으로 콘텐츠를 배포하면 준수하기가 지나치게 부담스럽지는 않지만, PDF 형식으로 배포되는 문서의 필요한 수준의 접근성을 보장하는 것은 상당한 기술적 과제가 될 수 있습니다. 이는 PDF 파일로 출력될 콘텐츠를 작성하는 데 사용된 소프트웨어에 따라 달라집니다.

PDF는 신뢰할 수 있는 문서 전송 문제를 해결하기 위한 방안으로 1990년대 초에 등장했으며, 역사는 그것이 대단히 성공적이었음을 보여줍니다. 그러나 PDF는 문서 내용의 접근성을 지원할 필요가 광범위하게 인식되고 받아들여지기 전에 등장한 복잡한 파일 형식이기도 합니다. 그럼에도 시간이 지나면서 PDF 사양은, Adobe가 다음과 같이 부르는 PDF의 “양식화된” 변형을 사용하여 접근 가능한 PDF 문서의 제작을 가능하게 하고 지원하는 기능들을 제공하도록 발전해 왔습니다. *태그가 지정된 PDF*.

실제로 태그가 지정된*그리고 완전히 접근 가능한*PDF 파일을 만드는 일은 PDF를 출력하는 소프트웨어—여기에는 TeX 엔진과 LaTeX 매크로 및 추가 LaTeX 패키지 생태계도 포함됩니다—에 상당한 추가 기술 요구사항을 부과합니다.

## 최종 형태의 디지털 종이로서의 PDF의 탄생

다음 [휴대용 문서 형식(PDF)의 탄생](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) 는 문서를 컴퓨터 간에 전송하는 일이 어려움으로 가득했던 시대에서 비롯되었는데, 이는 종종 파일 변환으로 인해 페이지 재흐름과 기타 불일치가 발생했고, 서로 다른 운영체제(특히 Windows와 Macintosh)에서 사용된 호환되지 않는 글꼴과 텍스트 인코딩으로 인해 문제가 더 심해졌습니다. 이 문서의 저자는 당시 출판 업계에서 일하고 있었고, 그러한 어려움을 처리하던 생생한 기억을 가지고 있습니다!

PDF는 글꼴을 함께 포함한 독립형 문서를 원활하게 전송할 수 있도록, 보편적이고 최종 형태의(수정 불가능한) 디지털 종이를 도입하여 파일 공유 문제를 해결하도록 설계되었습니다. 사용자는 결국 수신자가 어떤 컴퓨터 플랫폼을 쓰든 문서를 열고 읽을 수 있으리라는 상당한 확신을 가지고 온갖 종류의 문서를 전송할 수 있게 되었습니다. 문서의 충실성이 보존되었고, 지저분한 페이지 재흐름과 글꼴 호환성/가용성 문제는 과거의 일이 되었습니다.

### 모든 사용자에게 좋은 디지털 종이?

디지털 종이의 한 형태로서 PDF의 계보는 자연스럽게 화면이나 종이 위에서 내용을 시각적으로 탐색할 때 인쇄된 페이지 번호, 타이포그래피 또는 디자인 요소를 단서로 사용하는 것을 전제로 했습니다. 그러나 이러한 시각적 단서/메커니즘은 물론 심각한 시각장애가 있는 사람들에게는 아무런 의미가 없습니다. 오늘날 디지털 콘텐츠의 접근성 향상은 콘텐츠 제작과 배포의 중요한 측면으로 정당하게 인정받고 있습니다. PDF의 과제는 원래 인쇄된 페이지라는 시각 매체를 재현하도록 설계된 “컨테이너” 안에 갇힌 콘텐츠에 비시각적 접근을 가능하게 하는 메커니즘을 제공하는 것이었습니다.

PDF 사양의 첫 번째 버전(PDF 1.0)은 [1993년 6월 15일에 공식 발표되었고](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) 이후 업데이트된 새 버전들이 뒤따랐으며, 2001년(PDF 1.4)에는 [“...보조 기술 사용자가”](https://www.adobe.com/accessibility/pdf.html) 사용할 수 있게 한 “태그가 지정된 PDF”의 도입이 포함되었습니다. PDF 사양의 후속 릴리스들은 PDF의 기능을 확장하고 향상시켜 왔고, 그 정점은 최신 릴리스(PDF 2.0)로 이어졌습니다. 보고서에 따르면 [보고서](https://www.pdfa.org/tagged-pdf-2-0/), 접근성 기능이 상당히 개편되었지만, PDF 2.0은 TeX 엔진에서 아직 잘 지원되지 않습니다.

## PDF 내부의 콘텐츠

관련된 문제를 이해하려면 PDF 파일이 실제로 포함하는 페이지 콘텐츠를 어떻게 표현하는지 살펴볼 가치가 있습니다. PDF 파일 깊숙한 곳에서 각 페이지의 콘텐츠는 해당 페이지의 *콘텐츠 스트림*에 저장됩니다: 이는 PDF 연산자(“명령”)의 연속으로, 렌더링(표시)할 때 텍스트나 그래픽을 특정 페이지 위치에 배치하는 역할을 하며, 이를 *보기 위해* 사용되는 소프트웨어가 PDF를 표시합니다. 사실상 콘텐츠 스트림은 PDF 보기 애플리케이션에 각 페이지를 어떻게 “그릴지”를 알려 주는 그래픽 설명 또는 “조리법”을 제공하며, 페이지에 무엇을 어디에 표시할지 정의합니다. 당연히 이러한 연산자들의 집합에는 특정 크기의 특정 글꼴 선택, 색상 선택, 선 너비 정의, 선과 곡선 그리기 등 페이지의 시각적 표현을 위한 완전한 그래픽 설명을 제공하는 데 필요한 모든 지침이 포함됩니다.

파일 크기를 줄이기 위해 PDF 콘텐츠 스트림은 압축되어 간결한 이진 형식으로 저장되지만, Adobe Acrobat Pro DC와 같은 적절한 소프트웨어에 접근할 수 있다면 이를 사용해 페이지 콘텐츠 스트림의 “압축 해제된” 일반 텍스트 버전을 볼 수 있습니다.

PDF 연산자가 표를 어떻게 “그릴” 수 있는지 생각해 봅시다. PDF 콘텐츠 스트림에는 가로/세로 선을 만들고, 서로 다른 글꼴을 선택하고, 페이지의 여러 위치에 텍스트를 배치하여 표 내용을 만드는 데 적절한 연산자 순서가 포함될 것입니다. 이를 보여주기 위해, 아주 단순한 태그가 없는 PDF 문서를 생각해 보겠습니다. 여기에는 나중에 이 글에서 이유가 밝혀질 Microsoft Word로 만든 기본적인 표와 텍스트 몇 줄만 들어 있습니다. 다음은 우리의 간단한 PDF를 보여주는 스크린샷입니다:

![Microsoft Word로 만든 표](/files/9810815919e56d3c5adad99209b1a42f77989157)

이 파일의 (압축 해제된) 페이지 콘텐츠 스트림을 추출해 처음 몇 줄을 텍스트 편집기에 붙여넣으면, PDF 파일이 이 페이지에 표시된 콘텐츠를 어떻게 “설명”하는지에 대한 “감각”을 얻기 위해 몇몇 PDF 연산자를 요약할 수 있습니다.

![PDF 파일의 콘텐츠 스트림 이미지](/files/e1bd40bc9bb2d2bc2ca9fd6dbaebf39b701210ab)

Adobe Acrobat Pro DC에 접근할 수 있다면 이를 사용해 PDF 페이지 콘텐츠 스트림에 포함된 연산자들을 나열할 수 있습니다. 다음은 Acrobat의 *내부 PDF 구조* 동일한 PDF의 보기로, 기본적인 표를 포함한 단일 페이지를 “그리는” 데 사용된 모든 연산자에 대한 한 줄 설명을 친절하게 제공합니다—이 짧은 설명들은 Adobe Acrobat Pro DC가 제공한 것이며, PDF 파일 자체에는 *작동하지* 포함되어 있지 않습니다:

![Adobe Acrobat Pro DC에서 본 PDF 콘텐츠 스트림 이미지](/files/25c2060c08f8bf2927a19e38f9d1d1a7f8d54f9f)

그러나 이러한 그리기 지침(연산자)에는 실제로 무엇을 만들어 내는지에 대한 “의미”나 “설명”이 저장되어 있지 않다는 점에 주목하십시오. 그것들은 단지 그래픽 연산자들의 집합일 뿐이며, 그 결과 PDF 콘텐츠 스트림에 있는 그래픽 연산자가 만들어 내는 것을 *시각적으로 보는 사람이 인식하는* 표 형태로 구성할 뿐입니다. 분명히, 심각한 시각장애가 있는 사람들에게는 PDF의 콘텐츠 스트림에 있는 이러한 그래픽 연산자들이 만들어 낸 표를 표시하는 것은 그 콘텐츠에 접근하는 실행 가능한 방법이 아닙니다. 필요한 것은 PDF 파일이 그 표에 대한 적절한 비시각적(기계 판독 가능) 설명을, 그리고 물론 PDF 파일의 페이지 안에 포함된 다른 모든 콘텐츠 항목에 대한 설명을 포함하는 메커니즘입니다.

비시각적 접근을 가능하게 하려면, PDF 파일에는 특정 콘텐츠 조각을 “그리는” 데 사용되는 연산자들의 집합이나 그룹에 “의미” 또는 의미론을 부여하는 추가 데이터가 포함되어야 합니다. 필연적으로 이런 “의미”를 할당하거나 제공하는 원리는 PDF에 포함된 모든 형태의 콘텐츠로 확장되어야 합니다. 그 메커니즘이 바로 *태깅* 이며, PDF를 놀랍게도 *태그가 지정된 PDF*.

## 태그가 지정된 PDF 소개

태그가 지정된 PDF는 태그가 없는 PDF 파일에는 없는 추가 데이터(및 데이터 구조)를 포함하는 특정 유형의 PDF 파일을 가리키는 이름입니다. 태그가 지정된 PDF의 원리/아이디어는 개략적으로 설명할 수 있지만, 전체 세부 사항은 복잡하며 공식 PDF 사양의 많은 페이지를 차지합니다.

Adobe는 시각장애가 있는 사용자가 콘텐츠에 접근할 수 있게 하는 것을 포함한 여러 목표를 달성하기 위해 태그가 지정된 PDF를 설계했지만, 이는 다음에 있는 목록도 포함합니다. [Adobe의 PDF 1.7 사양](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf):

* 다른 응용 프로그램에 붙여넣기 위한 텍스트와 그래픽의 간단한 추출;
* 원래 레이아웃에서 가정한 것과 다른 크기의 페이지에 맞도록 텍스트와 관련 그래픽을 자동 재배치;
* 검색, 색인, 맞춤법 검사와 같은 목적으로 텍스트 처리;
* 문서 구조와 기본 스타일 정보를 유지한 채 다른 일반적인 파일 형식(HTML, XML, RTF 등)으로 변환.

또한 태그가 지정된 PDF는 다음도 요구합니다:

* PDF 콘텐츠 내의 텍스트는 유니코드로 변환할 수 있는 형식으로 표현되어야 하며;
* 단어 경계는 명시적으로 표현되어야 합니다—TeX 엔진은 단어를 구분하기 위해 공백 문자를 사용하지 않고, 대신 glue라고 하는 TeX의 유연한 간격을 사용한다는 점에 유의하세요(아래 참조);
* 실제(“진짜”) 콘텐츠는 레이아웃과 페이지 매김의 산물인 장식적 요소와 구분되어야 합니다.

태그가 지정된 PDF의 기반에는 우리가 살펴볼 두 가지 핵심 개념이 있습니다:

* PDF 파일에서 콘텐츠의 논리적 구조를 정의하는 것;
* 표준 콘텐츠 유형 집합으로 PDF 콘텐츠에 마크업(태깅)하는 것.

## 논리적 구조

긴 문서에서는 콘텐츠가 일반적으로 더 작은 콘텐츠 항목들의 연속으로 분할됩니다. 예를 들어, 책은 보통 장으로 나뉘고, 장은 다시 단락, 표, 그림/차트, 글머리표 또는 번호 매기기 목록, 각주, 참고문헌 등을 포함하는 절과 하위 절로 나뉩니다. 이러한 책이나 다른 어떤 문서 유형에서든 콘텐츠의 구조와 조직을 그 문서의 *논리적 구조*.

문서의 논리적 구조라는 개념은 PDF 접근성에서 중요한 역할을 하지만, 개념으로서는 다소 모호하고 이해하기 까다롭게 느껴질 수 있습니다. 다음은 [데이터베이스 시스템 백과사전](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) 에서 발췌한 유용한 설명입니다:

> “논리적 구조는 문서에서 정보가 조직되는 방식을 말하며, 정보의 계층과 문서의 여러 부분 사이의 관계를 정의한다. 논리적 구조는 문서가 무엇을 담고 있는지와는 달리, 문서가 어떻게 구성되는지를 나타낸다.”

이 논리적 구조의 정의는 정확히 *어떻게* 그 구조 정보가 물리적으로 어디에 저장되는지를 전혀 언급하지 않습니다. 단지 그것이 문서의 구조와 조직을 나타낸다는 것만을 말합니다. 문서의 논리적 구조가 어떻게 저장되거나 표현되는지에 대한 정확한 세부 사항은 구현에 따라 달라지며, 이를 생성하고 처리하는 데 사용되는 소프트웨어의 기능입니다.

### PDF에서의 논리적 구조

PDF 사양은 문서의 논리적 구조를 PDF 파일 안에 기록할 수 있는 메커니즘을 제공합니다. 이는 예를 들어 PDF의 콘텐츠를 XML, HTML 또는 Microsoft Word 같은 다른 형식으로 내보내고자 하는 소프트웨어가 사용할 수 있습니다. 그런 내보내기 과정은 대상 내보내기 파일 형식의 규칙을 따르는 올바른 구조의 텍스트 문서를 생성해야 하며, 이는 PDF 내부에 제공된 논리적 구조 정보의 안내를 받을 때 가장 잘 달성됩니다.

또한 PDF 파일의 논리적 구조는 예를 들어 시각장애가 있는 사람에게 내용을 소리 내어 읽어 주는 텍스트-음성 변환 작업을 수행하고자 하는 접근성 소프트웨어에 필수적입니다. 텍스트-음성 변환 과정은 내용이 올바른 순서/시퀀스로 읽히고 있는지 확인해야 하며, 그렇지 않으면 말도 안 되는 결과가 나올 수 있습니다. 또, 페이지라는 개념 자체는 PDF의 콘텐츠와 문서 구조에만 관심이 있고, 페이지 크기의 덩어리로 나뉜 시각적 분할과 표현에는 관심이 없는 접근성 응용 프로그램에는 의미가 없을 수도 있습니다.

#### 콘텐츠 항목에 이름 붙이기

PDF 문서의 논리적 구조를 기록(저장)하려면, 일반적인 PDF 문서에서 발견될 가능성이 있는 여러 *유형* 의 콘텐츠 항목에 의미 있는 이름 집합을 부여해야 합니다—즉, 제목, 단락, 표, 목록 등과 같은 콘텐츠 구역을 식별해야 합니다. 또한 목차, 번호/글머리표 목록, 표 형식 자료와 같은 일부 콘텐츠 항목은 자체적으로 상당히 복잡한 구조를 가지므로, 그런 더 복잡한 콘텐츠 항목이 어떻게 구성되는지—그 하위 구조—를 지정하는 안내/규칙도 필요합니다. 또 다른 요구사항은 PDF를 처리하는 보조 소프트웨어가 무시해야 할 PDF 콘텐츠를 명확히 식별하는 것입니다. 예를 들어 페이지 머리글과 바닥글은 페이지 매김의 산물로, 심각한 시각장애가 있는 사람들에게는 불필요한 텍스트를 담고 있으므로 그 콘텐츠는 무시되어야 합니다.

문서의 논리적 구조를 정의하기 위해 PDF가 사용하는 메커니즘은 유연하도록 설계되어 있어, 원칙적으로 PDF 파일을 생성하고 처리하는 서로 다른 응용 프로그램이 각자의 관례에 따라 콘텐츠 유형 이름을 사용할 수 있습니다. 그러나 문서 교환성을 극대화하고 서로 다른 PDF 처리 응용 프로그램이 일관된 결과를 제공하도록 하기 위해, Adobe는 PDF 생성 소프트웨어가 준수해야 할 콘텐츠 항목 유형에 대한 표준 이름 집합을 정의했습니다. PDF 사양에서는 이러한 표준 이름을 태그라고 하며, 여기서 *태그가 지정된* PDF라는 개념이 생겨납니다.

### PDF 콘텐츠의 마크업: “내부 구조” 살펴보기

논의를 조금 덜 추상적으로 만들기 위해 태그가 지정된 PDF 파일의 내부를 잠시 살펴보겠습니다—비록 태그가 지정된 PDF가 매우 크고 복잡한 주제이므로 모든 세부 사항을 다룰 수는 없지만요.

#### 표시된 콘텐츠 시퀀스: 태그가 지정된 PDF의 구성 요소

가장 낮은 수준에서, PDF 페이지 안에 포함된 콘텐츠(즉, 콘텐츠 스트림 안의 콘텐츠)의 의미를 기록하는 과정은 *표시된 콘텐츠 시퀀스* 에서 시작되며, 이는 PDF 연산자들의 묶음이나 그룹을 식별(“의미 부여”)하는 데 사용됩니다. 표시된 콘텐츠 시퀀스에는 `MCID` (*(marked content identifier*)라는 숫자 식별자가 부여되며, 이는 각 페이지에서 0부터 어떤 최대 N까지 이어지는 정수입니다. 이러한 `MCID` 값은 특정 페이지의 콘텐츠 스트림 안에 포함된 연산자 시퀀스를 고유하게 식별하는 방법을 제공합니다. 분명히 하기 위해, 각 페이지에서 `MCID` 식별자는 0에서 시작해 특정 페이지의 콘텐츠 스트림에 몇 개의 표시된 콘텐츠 시퀀스가 포함되어 있는지에 따라 결정되는 최대값까지 순차적으로 증가합니다.

표시된 콘텐츠 시퀀스는 사실상 더 높은 수준의 데이터 구조를 구성하는 데 사용되는 기본 “구성 요소”이며, 그런 데이터 구조를 *구조 요소*라고 합니다. 이러한 구조 요소에는 태그가 포함되어 있는데, 이는 그들이 나타내는 콘텐츠 항목의 유형을 식별하는 이름입니다.

#### 구조 요소의 예

여기서는 약간 앞서가지만, 예시를 살펴보는 것이 유익합니다. 페이지 콘텐츠의 작은 텍스트 조각 3개가 있고, 각각이 콘텐츠 스트림에서 서로 다른 표시된 콘텐츠 시퀀스로 식별된다고 가정해 봅시다. 이 3개의 텍스트 조각은 각각 태그가 붙은 자체 구조 요소로 패키징할 수 있으며, 세 개를 모두 다른 구조 요소를 사용해 “연결”하면 목차의 한 줄과 같은 더 높은 수준의 콘텐츠 항목을 나타낼 수 있습니다.

![구조 요소와 표시된 콘텐츠 시퀀스를 설명하는 이미지](/files/7a5f032986e3db94ba70f9afeb691d9d941851b8)

일종의 부모–자식 데이터 관계를 통해 구조 요소의 집합이 결합되어 번호 매기기 목록이나 글머리표 목록, 표, 수학식 등과 같은 더 복잡한 데이터 항목을 나타내는 연결된 데이터 구조를 만듭니다. 궁극적으로 전체 PDF 파일에 포함된 모든 구조 요소의 집합은 서로 더 연결되고 결합되어 PDF 문서의 논리적 구조를 형성합니다—이 부분은 나중에 다시 살펴보겠습니다.

### 표시된 콘텐츠 시퀀스란 무엇인가요?

위의 논의에서는 표를 포함한 단순한 태그 없는 PDF 문서(Microsoft Word로 작성)를 사용했지만, Word에 태그가 지정된 PDF를 만들도록 지시하면 페이지 콘텐츠 스트림에 추가 마크업이 나타나는 것을 볼 수 있습니다. 여기서는 콘텐츠 스트림의 처음 몇 줄만 살펴보고 있지만(수백 줄이 있습니다), 다음과 같은 추가 연산자의 존재에 주목하세요. `/P <</MCID 0>> BDC` 및 `EMC` 이는 표시된 콘텐츠 시퀀스를 식별하는 데 사용됩니다. 표시된 콘텐츠 시퀀스의 전체 구문을 모두 살펴보지는 않겠지만, 독자께서는 다음의 862페이지를 참고하시기 바랍니다. [Adobe의 공식 PDF 1.7 사양](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf).

![태그가 지정된 PDF 콘텐츠 스트림에서 표시된 콘텐츠 시퀀스를 보여주는 이미지](/files/2b56e38e0f7dba8b79e00b0b06246294961b9f44)

참고하기 쉽도록, 다시 태그 없는 버전을 보여드립니다:

![PDF 콘텐츠 스트림을 보여주는 이미지](/files/e1bd40bc9bb2d2bc2ca9fd6dbaebf39b701210ab)

다음에서 *태그 없는* PDF에서는 다음과 같은 연산자 `/P <</MCID 0>> BDC` 및 `EMC` 는 없지만 나머지 연산자는 변하지 않습니다: 태그 없는 PDF에는 특정 연산자 시퀀스/집합을 식별하는 데 사용되는 추가 마크업이 없습니다. 다시 한번 Adobe Acrobat의 *내부 PDF 구조* 기능을 사용하여 콘텐츠 스트림 내의 표시된 콘텐츠 시퀀스를 볼 수 있습니다—여기서는 녹색 테두리로 강조 표시했습니다:

![Adobe Acrobat Pro DC에서 본 태그가 지정된 PDF 콘텐츠 스트림의 표시된 콘텐츠 시퀀스 이미지](/files/a68953a497d1ad9bd56c22d98d8107e72db80928)

일부 콘텐츠 조각에는 다음과 같은 태그가 지정되어 있음을 유의하세요 `/Artifact` 이는 PDF 페이지에서 *무시되어야 할* 자료를 식별하며, 예를 들어 시각장애인에게 소리 내어 읽어 주는 보조 소프트웨어 응용 프로그램이 그러합니다.

다음 스크린샷은 첫 번째 표시된 콘텐츠 시퀀스의 확장된 보기를 보여줍니다—즉, `MCID` 값을 가진 `0`. 표시된 콘텐츠 시퀀스의 끝은 PDF 연산자 `EMC`.

![표시된 콘텐츠 스트림에 포함된 연산자 세부 정보를 보여주는 이미지](/files/ec787c4ce615afc61dfa507d8d8b0b83f129273c)

### 논리적 구조 저장

지적했듯이, 개별 콘텐츠 항목(단락, 목록, 표 등)에 대한 설명을 제공하는 것 외에도 접근 가능한 PDF에는 전체 문서를 그 논리적 구조의 형태로 표현한 것이 포함되어야 합니다. 개별 접근 가능한 콘텐츠 조각은 서로 연결되어 완전하고 탐색 가능한 접근 가능한 문서를 만들어야 하며—이는 단일 HTML 문서가 단락과 그래픽, 표로 구성되어 웹 페이지를 만드는 방식과 유사합니다. 더 나아가 PDF 문서의 논리적 구조는 모든 콘텐츠가 올바른 *읽기 순서*로 탐색될 수 있도록 보장해야 하며, 이는 페이지 콘텐츠가 PDF 페이지 콘텐츠 스트림에 기록된 순서와는 무관합니다. 읽기 순서는 아래에서 더 자세히 살펴보겠습니다.

#### 논리적 구조: 구조 요소의 “트리”

앞서 PDF가 *구조 요소* 라는 것을 사용해 개별 콘텐츠 항목을 표현하며, 구조 요소에는 어떤 콘텐츠 유형을 나타내는지 식별하는 태그가 포함된다고 언급했습니다. 문서의 논리적 구조를 표현하기 위해 모든 구조 요소는 부모—자식 관계를 사용해 서로 연결되고 “구조 트리”로 조직됩니다. 내부적으로 태그가 지정된 PDF 파일에는 `StructTreeRoot` 라는 객체가 포함되어 있으며, 이 객체는 문서의 논리적 구조 트리의 시작점 또는 “루트” 역할을 하는 구조 요소를 포함(가리킵니다). 보통 구조 트리의 “루트”는 태그가 붙은 단일 구조 요소로 시작합니다 `문서` 로, 이는 수많은 *자식* 구조 요소를 포함하며, 이들이 합쳐져 문서 전체 내용을 나타냅니다. 접근 가능한 PDF를 태깅을 통해 생성하도록 설계된 모든 소프트웨어는 이 매우 복잡한 데이터 구조(그리고 다른 구조들도!)를 만들어야 하며—여기에는 TeX 엔진과 LaTeX도 포함됩니다.

그러한 문서 구조 트리(`StructTreeRoot`)은 Adobe Acrobat Pro DC에서 연 태그가 지정된 PDF의 다음 스크린샷에 나와 있습니다:

![태그가 지정된 PDF의 StructTreeRoot를 보여주는 이미지](/files/1308577b1ffb42888439e82eb1f44f8a83b40027)

위의 구조를 태그 없는 PDF 버전과 비교해 보세요:

![태그 없는 PDF에서 StructTreeRoot가 없는 것을 보여주는 이미지](/files/71c2a0d8e74719a43602d434a24a7d3a6f5c7820)

### PDF의 논리적 구조 살펴보기

지금까지 다룬 내용을 요약하는 몇 가지 그래픽으로 시작하고, Adobe Acrobat Pro DC를 사용하여 태그가 지정된 PDF 파일의 논리적 구조를 더 자세히 보여주는 동영상으로 마무리하겠습니다. 먼저, 일반 원리를 보여주는 도식으로 시작해 보겠습니다. 즉, 표시된 콘텐츠 시퀀스(MCS)로 마크업된 콘텐츠 스트림을 가진 PDF 페이지입니다.

![PDF 문서 페이지에서 표시된 콘텐츠 시퀀스 개념을 보여주는 그래픽](/files/ae043ac19eeb53c5fdab337331268c28c0019b0e)

그러한 MCS는 이후 *구조 요소* 으로 결합되며, 이들은 더 큰 콘텐츠 유형의 기반을 형성하고, 그 자체도 다시 서로 연결되어 `StructTreeRoot`.

![태그가 지정된 PDF 파일의 논리적 구조를 보여주는 그래픽](/files/f7c449b0ba385b526e08a097e1ea2d0c640b0f66)

#### 태그가 지정된 PDF의 논리적 구조를 보여주는 동영상

다음 동영상(8분)은 Adobe Acrobat Pro DC를 사용해 LaTeX로 생성된 태그가 지정된 PDF 파일의 논리적 구조 세부 사항을 살펴보는 “가이드 투어”를 제공합니다. 동영상에서 사용된 태그가 지정된 PDF 파일의 이름은 `tagpdf.pdf`, 그리고 실험적 LaTeX 패키지 [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en)에 대한 문서가 포함된 훌륭한 예제입니다. 이 `tagpdf` 패키지

{% embed url="<https://videos.ctfassets.net/nrgyaltdicpt/2rD5DE49Ae27ENZ2bbnQhw/db5818f642afc48e78598ccd9b979a21/AcrobatPro.mp4>" %}

### 태깅과 유연성에 대한 메모

HTML 사양은 웹 페이지를 구성하는 데 사용할 수 있는 미리 정의된 태그를 매우 많이 제공하지만, 이를 결합해 원하는 HTML 문서를 만드는 방식에는 유연성도 허용합니다. 마찬가지로 Adobe의 태그가 지정된 PDF 사양도 미리 정의된 태그 이름 집합을 제공하지만, PDF 안에서 복잡한 콘텐츠 항목을 표현하기 위해 그 태그들을 어떻게 결합할지에 대해서는 매우 적은 제한만 둡니다—설계상 상당한 유연성이 있습니다. 또한 PDF처럼 크고 복잡한 사양에서는, 작성된 사양에 어떤 모호함이나 명확성 문제들이 스며드는 것은 피할 수 없습니다. 이러한 복잡한 사양을 구현해야 하는 소프트웨어 개발자들은 작성된 설명을 실제 코드로 바꾸는 과정에서 해석상 “판단”을 내려야 할 수도 있습니다.

태그가 지정된 PDF의 본질적인 유연성과 사양(또는 접근성 표준)의 해석은 문서 작성 응용 프로그램의 개발자에게 자연스럽게 영향을 미칩니다. 사용자가 만든 콘텐츠를 태그가 지정된 PDF 파일로 출력할 때 어떤 태그 조합을 사용해 표현해야 할까요? 문서 작성 소프트웨어의 기능을 활용해 사용자가 온갖 종류의 콘텐츠를 만들어 낼 수 있는 무한한 능력을 고려하면, 접근 가능한 태그가 지정된 PDF를 자동으로 생성하는 일은 꽤 큰 도전임을 알 수 있습니다!

완전히 접근성 표준을 준수하는 태그가 지정된 PDF를 만드는 데 따르는 불가피한 복잡성을 반영하듯, 웹에는 Adobe InDesign이나 Microsoft Word 같은 소프트웨어를 통해 태그가 지정된 PDF를 만드는 방법에 대한 “방법”, “팁”, “모범 사례” 조언이 넘쳐납니다. 또한 PDF Association은 다음이라는 유용한 문서를 발행했습니다 [태그가 지정된 PDF 모범 사례 가이드](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) 태그가 지정된 PDF와 PDF/UA 구현의 과제에 직면한 개발자들을 돕기 위해 작성되었습니다.

## PDF가 있는데, 접근 가능한가요?

주어진 PDF 파일이 PDF/A 또는 PDF/UA 같은 필요한 접근성 표준을 준수하는지 판단하려면(아래 참조) 반드시 *검증되어야 합니다* 합의된 검증 절차나 소프트웨어 도구를 사용하여. 그러나 검증은 일반적으로 문서가 완성된 후에 이루어지지만, 그 과정은 문서 작성자가 아니라 준수를 요청한 조직이나 기관의 접근성 전문가가 수행할 수도 있습니다. PDF가 검증에 실패하면, 태깅을 수정하기 위해 Adobe Acrobat Pro DC를 통한 숙련된 수동 개입이 필요할 수 있습니다(가능한 경우). 또는 원래 문서를 수정하기 위해 작성자에게 되돌려 보내야 할 수도 있으며, 문제를 일으킨 작성 소프트웨어 기능의 사용을 피하는 방식이 필요할 수도 있습니다. 이는 작성자의 통제를 벗어날 수 있어 달성하기 매우 어려울 수 있습니다.

### 읽기 순서와 콘텐츠 순서

지적했듯이, 진정으로 접근 가능한 PDF를 만드는 데는 작성 소프트웨어에 추가적인 기술 요구사항이 부과되며, 잠재적으로는 작성 소프트웨어의 기능을 어떻게 사용/적용하는지에 대해 “작성 규율”을 강제함으로써 문서 작성자에게도 요구가 됩니다. 태그가 지정된 PDF는 *가능하게 하는* 메커니즘이지만, PDF가 태그되어 있다는 사실만으로 *작동하지* 그 PDF가 자동으로 완전히 접근 가능하다는 의미는 아닙니다. 아래 예에서 보게 될 것입니다.

완전히 접근 가능한 PDF를 만들려면, PDF 안의 모든 콘텐츠 항목이 태그되어 논리적 구조를 생성해야 하며, 이를 통해 콘텐츠를 올바른 순서로 접근하고 읽을 수 있어야 합니다. 이를 *읽기 순서*읽기 순서 *읽기 순서* 의:

1. text
2. table
3. 그래픽

PDF로 작성될 때, 해당 페이지의 콘텐츠 스트림을 생성하는 소프트웨어는 표를 그리는 연산자로 시작한 다음 그래픽을 생성하는 연산자를 출력하고, 이어서 텍스트를 위한 연산자를 출력할 수 있으며, 이 경우 콘텐츠 스트림 내에서 하나의 *콘텐츠 순서* 의:

1. table
2. 그래픽
3. text

물론, 해당 페이지를 볼 때는 모든 것이 올바른 위치에 배치됩니다. 충분히 시력이 좋은 독자에게는 이러한 항목들이 페이지의 콘텐츠 스트림 안에 저장된 순서는 중요하지 않습니다. 그들은 모든 것이 올바른 위치에 있는 완전히 렌더링된 페이지를 보게 됩니다.

그러나 보조 소프트웨어가 콘텐츠 스트림의 항목 순서(콘텐츠 순서)에 의존해야 한다면, 콘텐츠 순서가 자연스러운 읽기 순서와 다를 경우 어려움을 겪게 됩니다. 예를 들어, 소리 내어 읽는 도구는 자료를 잘못된 순서로 읽게 될 것입니다. 다행히 보조 소프트웨어는 태그가 지정된 PDF의 논리적 순서(구조)를 사용할 수 있으며, 이는 콘텐츠가 읽혀야 하는 순서를 반영하도록 조직되어야 합니다. 이러한 이유로 문서의 논리적 구조를 나타내는 데이터는 실제로 눈에 보이는 페이지에 표시되는 콘텐츠와는 별도로 저장되어

> “... 논리적 콘텐츠 요소의 순서와 중첩이 문서 페이지의 그래픽 객체의 순서와 위치로부터 완전히 독립적일 수 있다.”(의 856페이지 [The PDF Reference, 제6판, 2006년 11월](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf))

실제로 읽기 순서를 보존하는 논리적 순서를 보장하는 일은 보이는 것보다 훨씬 더 어렵기 때문에, 관련된 문제를 보여 주는 단순하지만 다소 인위적인 예를 사용해 보겠습니다.

#### 잘못된 읽기 순서: Microsoft Word를 사용한 예

문서 작성자는 특정 시각적 효과를 얻기 위해 선택한 작성 소프트웨어의 기능을 사용할 수 있습니다—예를 들어, 테이블을 사용해 특정 텍스트 레이아웃을 만드는 것처럼요. 예를 들어, 다음 스크린샷은 앞선 예제들에서 사용된 Microsoft Word 문서를 보여줍니다. 이 문서에는 나란히 배치된 번호 매기기 단락 세트를 만들기 위해 사용된 표가 들어 있습니다. 그러나 이 콘텐츠를 태깅할 때는 표로 태그해야 할까요, 아니면 번호 매기기 목록으로 태그해야 할까요? 이 두 콘텐츠 유형 모두 이를 올바르게 표현하기 위해 복잡한 태깅 구조를 필요로 합니다. 다음 이미지에서 번호 매기기 단락이 읽히도록 의도된 순서를 주의하세요: 행 순서가 아니라 열 순서입니다.

![Microsoft Word로 만든 표 이미지](/files/3f04871fe9aa707c72498818f19bd61f5126f9a0)

Word에게 Acrobat PDFMaker 플러그인이 아니라 내장 내보내기 기능을 사용하여 이 문서를 PDF로 저장하도록 요청하면, 태그가 지정된 PDF를 만들도록 지시할 수 있습니다:

![Microsoft Word 내보내기 과정의 옵션 대화 상자](/files/b86a299d03c9b60e5bec9b9921c27186d5d9aa78)

그렇다면 Word는 이 레이아웃에 어떻게 태그를 지정할까요? 다음의 아주 짧은 비디오(14초)에서는 Microsoft Word가 생성한 태깅 구조를 검사하기 위해 Adobe Acrobat Pro DC를 사용합니다.

{% embed url="<https://videos.ctfassets.net/nrgyaltdicpt/1PXPgk2ZL8mgO00cKpVzGe/a704d6bcefd808713cd80febee867a58/WordTable.mp4>" %}

이 문서에서 Word는 다음을 사용하는 태그가 지정된 PDF 문서를 만들었습니다: `Table` 태그가 포함된 두 개의 하위 태그: `THead` 표 머리글 행 그룹을 위한 `TBody` 표 본문의 행 그룹을 나타냅니다. `THead` 및 `TBody` 둘 다 다음을 포함합니다: `TR` 콘텐츠의 개별 행을 나타내는 태그입니다.  `TR` 태그 안에는 각 셀에 있는 번호 매기기 목록 항목을 나타내는 추가 태그가 들어 있습니다. 다음 화면 이미지는 이 극도로 기본적인 문서를 표현하는 데 필요한, 매우 중첩된 태깅 구조와 그에 상응하는 복잡한 논리 구조를 보여 줍니다!

![Microsoft Word에서 만든 간단한 표의 매우 중첩된 태깅 구조와 논리 구조를 보여 주는 이미지](/files/c2f9d6e9606da497af677566a656ced3627250a0)

TeX와 LaTeX로 생성된 PDF와 비교하면, 이 Word 예시는 극히 단순한 문서이지만, 그것을 표현하려면 여전히 복잡한 논리 구조가 필요합니다. 복잡한 수학과 표를 포함한 LaTeX 생성 PDF를 표현하는 데 필요한 태깅 복잡성 수준을 상상해 보세요!

#### 태그는 지정되었지만, 읽기 순서가 올바르지 않습니다

Word가 실제로 다음을 생성하더라도 [태그가 지정된 PDF](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) 이는 완전히 접근 가능한 PDF를 생성하려는 모든 애플리케이션이 직면하는 근본적인 과제 중 하나, 즉 콘텐츠의 의도된 읽기 순서를 올바르게 표현하는 문제를 보여 줍니다. 태그가 지정된 PDF를 만들 때 Word의 내부 처리 과정은 해당 콘텐츠 스트림을 열 단위가 아니라 행 단위로 출력하여 표를 작성하기로 결정했습니다. PDF를 보는 완전한 시각 능력이 있는 독자에게는 이러한 낮은 수준의 세부 사항이 아무런 차이를 만들지 않습니다. 표는 올바르게 표시되기 때문입니다. 그러나 시각 장애가 있는 사람들에게는 Word의 논리적 문서 구조가 잘못된 결과를 낳습니다. 원하는 읽기 순서(열 단위)가 보존되지 않기 때문에 콘텐츠가 잘못된 순서로 읽히기 때문입니다.

다음 오디오 녹음은 Adobe Reader DC의 “Read Out Loud” 기능을 사용하여 제작되었습니다. 보시다시피 텍스트가 잘못된 순서로, 즉 열 단위가 아니라 행 단위로 읽혀집니다:

![Microsoft Word에서 만든 표](/files/75fa1ef8cac86c82dabdf923d15b506bc5707952)

위에서 언급한 대로, 이 예시는 다소 인위적이지만 접근성 문제를 유발하는 소프트웨어 기능 조합을 적용하는 것이 얼마나 쉬운지를 보여 줍니다. 그러나 문서 작성자가 이를 사전에 어떻게 알 수 있을까요? 아마도 이 문제는 결과 PDF가 보조 소프트웨어를 사용하는 등 실제 접근성 사용성 테스트를 거쳤을 때에만 발견될 것입니다. 잠재적으로 이러한 문서는 PDF/A 적합성/검증 테스트는 통과하지만 “실제 환경” 사용에서는 실패할 수 있습니다. 이와 같은 PDF 파일의 올바른 읽기 순서를 보장하려면 Adobe Acrobat Pro DC와 같은 고급 PDF 편집 도구를 사용한 숙련된 수작업 개입이 필요합니다. 이는 시간도 많이 들고 비용도 많이 드는 과정입니다. 또는 문서 작성자가 이런 특정한 형태의 콘텐츠 표현이나 레이아웃 사용을 삼갈 수도 있지만, 그것이 문제가 된다는 사실을 알고 있을 때만 가능합니다!

### 단어를 구분하기 위해 공백 문자 사용

워드 프로세서나 텍스트 편집기에 텍스트를 입력할 때는 공백 문자를 사용하여 한 단어의 끝과 다음 단어의 시작을 표시합니다. 이후 그러한 문서에서 PDF를 만들면, 입력한 공백 문자는 물론 출력되어 PDF에 저장된 텍스트의 일부가 됩니다. 그러나 TeX 엔진은 조판된 텍스트에서 단어를 구분하는 데 공백 문자를 사용하지 않습니다. 대신 공백 문자를 glue라고 하는 유연한 간격 형식으로 변환합니다(자세한 내용은 이 [Overleaf 글](/latex/ko/in-depth-articles/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) 에서 TeX 박스와 glue에 대한 자세한 내용을 참조하세요).

TeX 엔진이 만든 PDF 페이지의 콘텐츠 스트림에서는, 개별 단어의 구분이 공백 문자를 출력하는 방식이 아니라 페이지의 다른 위치로 이동하여 다음 단어의 텍스트를 시작하는 방식으로 이루어집니다. 또한 TeX 엔진이 조판한 텍스트 문단에서 단어 사이의 간격은 TeX의 줄바꿈 알고리즘 때문에 줄마다 달라집니다. 그 변화는 PDF 페이지의 콘텐츠 스트림에 기록된 위치 데이터에 반영됩니다.

TeX 조판의 이러한 측면은 TeX의 PDF에서 텍스트를 복사/붙여넣기하는 데, 그리고 TeX 엔진이 생성한 PDF에서 조판된 텍스트를 소리 내어 읽으려는 보조 소프트웨어에 영향을 미칩니다. 보조 소프트웨어는 처리해야 할 텍스트를 추출하기 위해 PDF 페이지의 콘텐츠 스트림을 구문 분석해야 합니다. 분명히 그런 소프트웨어는 단어의 시작과 끝을 감지할 메커니즘이 필요합니다. 가장 분명한 해결책은 공백 문자를 사용하는 것입니다. 이를 염두에 두고 접근성 표준은 개별 단어가 명확하게 종료되어야 한다고 요구하는데(예: 공백 문자로), TeX 엔진은 단어 사이 glue를 사용하기 때문에 이것이 문제가 됩니다.

#### 하지만 아직 희망은 있습니다!

2014년에 pdfTeX는 출력하는 PDF에서 단어 사이에 공백 문자를 사용할 수 있도록 하여 접근성 지원을 개선하기 위한 2개의 새로운 primitive를 도입했습니다:

* `\pdfinterwordspaceon`
* `\pdfinterwordspaceoff`

이 명령은 공백 글리프만 포함하는 “더미 폰트”를 사용합니다. 자세한 내용과 예시는 다음 자료의 29쪽에서 확인할 수 있습니다: [pdfTeX 사용자 매뉴얼](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf).

#### LuaTeX 사용하기: Overleaf 갤러리의 예제

LuaTeX는 이러한 pdfTeX primitive를 지원하지 않지만, LuaTeX의 이른바 콜백 메커니즘을 사용하여 pdfTeX와 매우 유사한 결과를 얻도록 프로그래밍할 수 있습니다. glue를 공백 문자로 변환하는 Overleaf 프로젝트는 Overleaf 갤러리에서 다음 제목으로 제공됩니다: [LuaTeX를 사용하여 단어 사이 glue를 공백과 kern으로 변환하기](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv).

LuaTeX(즉, Overleaf의 LuaLaTeX 컴파일러 옵션)를 사용하여 LaTeX 코드를 조판하면, Lua 코드를 통해 조판된 문단을 후처리하여 단어 사이 glue를 찾아 공백 문자와 적절한 kern으로 바꿀 수 있습니다. 공백 문자의 폭이 제공하는 간격은 적절한 kern 값을 계산하여 더하거나(또는 줄일 수) 있으며, 이를 통해 단어 사이 glue가 제공하던 간격을 보존하므로 조판 결과의 시각적 차이는 없습니다.

이것이 접근성 소프트웨어 사용자에게 어떤 차이를 만드는지 이해하려면, Adobe Reader DC의 다음 오디오 녹음을 들어 보세요: *Read Out Loud* 기능입니다. 이 녹음은 해당 프로젝트의 두 줄 텍스트가 glue를 공백으로 변환하기 전후에 소리 내어 읽히는 모습을 기록합니다. 공백을 사용하는 두 번째 줄 읽기가 단어 사이 glue를 사용하는 줄보다 훨씬 빠르고 유려하게 읽히는 점에 주목하세요.

Overleaf 프로젝트는 LuaTeX로 컴파일되는 일반 TeX 파일이며 시험용으로만 제공됩니다. 완전한 프로덕션 수준의 해결책을 의도한 것은 아닙니다. 주로 접근 가능한 PDF와 관련된 기술적 문제를 이해하는 데 도움을 주기 위해 설계되었습니다. 해당 프로젝트에서 사용된 Lua 코드는 훨씬 이전의 Overleaf 글에 담긴 작업을 기반으로 합니다 [LuaTeX를 사용한 간략하지만 시각적인 소개: 박스와 글루](/latex/ko/in-depth-articles/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md).

참고: 단순화를 위해 이 프로젝트는 다음 코드에서 파생된 자체의 매우 최소한의 OpenType 글꼴 로더를 사용합니다: <http://wiki.luatex.org/index.php/Use_a_TrueType_font>.

### 기타 접근성 문제와 태그가 지정된 PDF

태깅을 통해 PDF 안에 존재하는 콘텐츠 항목을 식별할 수 있지만, 그래픽이나 복잡한 수학 같은 일부 유형의 콘텐츠는 시각 장애인을 지원하도록 설계된 소프트웨어를 통해 접근 가능하게 하려면 추가 데이터나 정보가 필요합니다. 다양한 콘텐츠 유형에 대한 접근성을 제공하고 지원하기 위해 PDF 사양은 콘텐츠 항목에 “대체 설명” 또는 “ActualText”를 첨부할 수 있는 기능을 제공하여, 적절한 텍스트 설명이나 기타 기계 판독 가능한 표현을 제공합니다. 예를 들어 PDF 2.0 사양에서는 이러한 목적을 위해 MathML이 지정되었습니다.

#### “실제 콘텐츠”인가요, 아니면 단지 아티팩트인가요?

시각 장애인에게는 콘텐츠를 직사각형의 페이지 크기 조각으로 분할하고 표시하는 과정이 단어 하이픈 처리와 같은 원치 않는 부작용을 낳습니다. 또한 시각적 표현을 향상시키기 위해 사용되는 페이지 디자인이나 레이아웃의 측면은 그것을 볼 수 없는 사람들에게는 전혀 의미가 없습니다. 이러한 이유로 PDF 콘텐츠 태깅은 PDF 안의 일부 콘텐츠를 *아티팩트* 시각적 표현 또는 페이지 나눔의 아티팩트로 취급해야 함을 인식해야 합니다. 예를 들어 페이지 번호, 페이지 머리글과 바닥글, 음영 배경 또는 기타 디자인 요소는 접근성 소프트웨어가 해당 콘텐츠를 처리할 때 이를 무시해야 함을 알 수 있도록 식별되어야 합니다.

## PDF/A 표준 개요

접근 가능한 PDF를 만들기 위한 요청에서는 보통 [ISO 19005](https://www.iso.org/standard/38920.html)보통 PDF/A로 더 많이 알려진 ISO 표준을 언급합니다. 그러나 PDF/A는 *표준의* 버전이 있으며, 각각은 정식 PDF 사양의 특정 버전(PDF 1.4, 1.7, 2.0)을 반영합니다. 또한 다양한 [PDF Association 웹사이트](https://www.pdfa.org/resource/iso-19005-pdfa/) (2020년 5월 21일 접속)에서 다음과 같이 ISO 19005(PDF/A)를 설명하는 개요부터 시작해 보겠습니다:

> “ISO 19005의 주요 목적은 PDF를 기반으로 하는 파일 형식, 즉 PDF/A를 정의하는 것입니다. 이는 파일을 만들고, 저장하고, 렌더링하는 데 사용된 도구와 시스템과 무관하게 시간이 지나도 정적인 시각적 외관을 보존하는 방식으로 전자 문서를 표현할 수 있는 메커니즘을 제공합니다.
>
> ISO 19005의 부차적 목적은 적합한 파일 안에서 전자 문서의 논리 구조와 기타 의미 정보를 표현하기 위한 프레임워크를 정의하는 것입니다.
>
> ISO 19005의 또 다른 목적은 적합한 파일 안의 메타데이터에 전자 문서의 맥락과 이력을 기록하기 위한 프레임워크를 제공하는 것입니다.”

분명히 PDF/A에는 몇 가지 핵심 목표가 있습니다.

### PDF의 진화와 확장

다음 [PDF 1.0 사양](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) 은 1993년에 출판되었고 고작 230쪽이었습니다. 그러나 13년 후 [Adobe의 PDF 버전 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) 사양은 1000쪽을 훨씬 넘습니다! 시간이 지나면서 PDF 사양의 크기와 복잡성은 지원되는 기능 집합이 확장되면서 커졌습니다. 여기에는 새로운 기술과 점점 더 정교해지는 PDF 기반 워크플로 및 다양한 시장과 커뮤니티의 사용 사례 요구가 포함됩니다. 그러나 어떤 사용자나 사용자 집단도 그 모든 가능성을 전부 활용하는 일은 없을 것입니다. PDF는 가능한 가장 넓은 시장의 요구를 충족할 수 있도록 “모든 경우를 다 커버”해야 합니다. 예를 들어, 고급 상업 인쇄를 지원하기 위해 설계된 많은 PDF 기능은 문서 저장이나 공유 형식으로서의 일반적인 일상 업무에는 필요하지 않습니다.

### PDF/A: PDF의 “기초로 돌아가기”

PDF/A의 핵심 목표는 적합한 PDF가 장기 보관에 적합하도록 하거나, 다양한 보조 기술을 사용하는 사람들이 그 PDF를 “이용”할 수 있도록 접근 가능한 콘텐츠를 포함하도록 하는 것입니다. 이러한 목표를 달성하기 위해 PDF/A는 적합한 PDF 파일에서 허용되는 PDF 기능 집합을 제한하여, 보존 가능성이나 접근성을 해칠 수 있는 기능의 사용을 금지합니다. PDF/A는 적합한 PDF 파일이 장기 보관에 적합하거나 내용의 접근성을 보장하는 파일을 만들기 위해 전체 PDF 사양의 *부분집합* 일부를 어떻게 사용하는지를 규정하는 표준 집합으로 생각할 수 있습니다. PDF/A의 제한은 PDF를 PDF 읽기 기술과 무관한 “보관용 디지털 종이”로 사용할 수 있게 해 주며, 그 내용에 접근하는 데 사용되는 컴퓨팅 환경과도 독립적입니다. 적합한 PDF에는 동작이 “구현 종속적”인 것, 즉 그것들을 보거나 처리하는 데 사용되는 특정 소프트웨어나 운영체제에 의존하는 어떤 것도 포함되어서는 안 됩니다. PDF는 또한 *완전해야 합니다*: 글꼴이나 색상 프로필 같은 핵심 문서 자산은 파일에 포함되어 있어야 합니다.

### PDF/A 버전과 적합성 수준

다양한 *버전은* PDF/A 표준의 버전이 있으며, 각각은 정식 PDF 사양의 특정 버전(PDF 1.4, 1.7, 2.0)을 반영합니다. 또한 다양한 *적합성 수준* 이 있어 PDF 파일이 PDF/A 표준의 어떤 측면에 적합한지를 지정합니다. 따라서 “PDF/A 적합성”을 주장하거나 요구할 때는 다음에 적합한 PDF 파일을 생각해야 합니다:

**PDF/A-**

예를 들면

* PDF/A-1a: PDF/A 버전 1, 적합성 수준 a를 의미합니다
* PDF/A-2b: PDF/A 버전 2, 적합성 수준 b를 의미합니다

이에 대해 조금 더 자세히 살펴보겠습니다.

#### PDF/A 버전

PDF/A 표준은 ISO의 관할 아래 있으며, ISO 19005라는 표준으로 출판되었습니다. 앞서 언급했듯이 PDF 사양은 시간이 지나며 발전했고, 그에 따라 ISO 19005도 업데이트가 필요했으며, 그 결과 아래 표가 만들어졌습니다:

|              |                  |                       |
| ------------ | ---------------- | --------------------- |
| **PDF/A 버전** | **ISO 표준**       | **기반 PDF 버전**         |
| PDF/A-1      | ISO 19005-1:2005 | PDF 1.4               |
| PDF/A-2      | ISO 19005-2:2011 | PDF 1.7               |
| PDF/A-3      | ISO 19005-3:2012 | IS0 32000-1 (PDF 1.7) |

이 글을 쓰는 시점(2020년 4/5월)에는 업데이트된 PDF/A-4(ISO 19005-4)가 [준비 중입니다](https://www.iso.org/standard/71832.html).

#### PDF/A 적합성 수준

세 가지 PDF/A 버전(PDF/A-1, PDF/A-2, PDF/A-3) 외에도 세 가지 *적합성 수준*:

* Level A (접근 가능): 접근성용(레벨 B의 보관 요구 사항 포함)
* Level B (기본): 보관용
* Level U (Unicode) (= 보관 + 텍스트에 Unicode 사용)

다음은 이러한 적합성 수준에 대한 간단한 설명입니다:

* **Level B (기본)** 은 PDF/A 준수를 위한 최소 요구 사항입니다. 이는 적합한 PDF 문서가 장기 보관에 적합하도록 보장하는 요구 사항을 정의합니다. 즉, 특정 소프트웨어, 도구 또는 운영체제와 무관하게 언제나 안정적으로 볼 수 있고 인쇄할 수 있어야 합니다.
* **Level A (접근 가능)** 는 Level B 적합성의 요구 사항을 포함하며, 추가로 논리 구조와 읽기 순서 정보를 제공하기 위한 태그가 지정된 PDF의 사용과, 문서의 텍스트에 접근할 수 있도록 Unicode의 사용을 요구합니다.
* **Level U (Unicode)** 적합성은 PDF/A-2에 추가된 수준으로, 문서 텍스트에 Unicode를 사용하도록 추가로 요구함으로써 Level B를 기반으로 하지만 구조 정보를 의무화하는 Level A만큼 나아가지는 않습니다.

PDF/A 버전과 적합성 수준은 표로 요약할 수 있습니다:

|                   |                     |          |          |
| ----------------- | ------------------- | -------- | -------- |
| **적합성 수준**        | **PDF/A-**          |          |          |
| Level A (접근 가능)   | PDF/A-1a            | PDF/A-2a | PDF/A-3a |
| Level B (기본)      | PDF/A-1b            | PDF/A-2b | PDF/A-3b |
| Level U (Unicode) | 해당 없음(PDF/A-1에는 없음) | PDF/A-2u | PDF/A-3u |

### PDF/UA(“Universal Accessibility”)

PDF/A 표준의 Level A 준수는 접근 가능한 PDF에 대한 요구 사항을 어느 정도 정의하지만, [ISO 14289](https://www.iso.org/standard/64599.html)PDF/UA라고 불리는 또 다른 ISO 표준인 ISO 14289는 더 나아갑니다. PDF/UA는 접근성 요구 사항을 강화하고 PDF/A 표준에 포함된 지침을 더 명확히 하며, 접근 가능한 PDF의 선호 표준이 되었습니다.

#### Matterhorn 프로토콜

PDF/UA 적합성에 대해 더 깊이 알고 싶은 독자라면 [Matterhorn Protocol](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) “PDF/UA 적합성을 충족하지 못하는 가능한 모든 방법의 목록”인 것을 흥미로워할 수 있습니다.

### 검증 소프트웨어

PDF 파일이 특정 표준을 준수하는지 확인하려면 *검증되어야 합니다* 해당 PDF를 훑어보며 내용과 구조가 그 표준의 요구 사항—예를 들어 PDF/UA 또는 PDF/A-*x*a(여기서 *x* = 1, 2 또는 3)와 일치하는지 확인하는 적합성 소프트웨어를 사용해야 합니다. PDF 검증—선호하는 검증 도구로 처리하는 것—은 비전문 사용자에게는 꽤 난해할 수 있는 진단 메시지나 경고를 생성할 수 있습니다. 아마도 일부 저수준 PDF 데이터(또는 구조)가 관련 표준을 충족하지 못하기 때문일 것입니다. 많은 작성자에게는 이러한 경고를 해석하고 이를 문서에 대한 실행 가능한 수정으로 바꾸는 일이 상당한 도전이 될 수 있습니다.

#### 무료 검증 소프트웨어

* [veraPDF](https://verapdf.org/) 는 해당 웹사이트(2020년 5월 28일 접속)를 인용하면, “모든 PDF/A 부분과 적합성 수준을 포괄하는, 목적에 맞게 설계된 오픈 소스 파일 형식 검증 도구”입니다.
* (Windows 전용) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) 는 “...2010년부터 시험과 검증을 거친 무료 PDF 접근성 검사 도구”입니다.

#### 상용 검증 소프트웨어

* [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) 은 적합하지 않은 PDF 파일의 태그를 편집하고 수정할 수 있는 도구들과 함께 PDF 검증 테스트 모음을 제공합니다.

### PDF Association: 훌륭한 정보의 원천

다음 [PDF Association](https://www.pdfa.org/) 은 많은 *훌륭한* PDF/A, PDF/UA 및 기타 많은 PDF 관련 주제에 대한 자료를 제공합니다. 여기에는 다음에 있는 비디오도 포함됩니다: [YouTube 채널](https://www.youtube.com/user/ThePDFAssociation/playlists) 웹사이트에서 이용할 수 있는 기사와 무료 기술 간행물도 함께 제공합니다. 그러한 간행물 중 하나가 [PDF/UA in a Nutshell](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) 로, PDF/UA 표준과 그 요구 사항에 대한 매우 유용한 입문서를 제공합니다.

## TeX 엔진과 LaTeX로 만든 접근 가능한 PDF

앞선 논의가 완전하게 접근 가능하고 올바르게 태그된 PDF 파일을 만드는 일이 까다로운 기술적 과제임을 보여 주었기를 바랍니다. 또한 앞서 본 간단한 Microsoft Word 예제만 보아도 작성자가 접근성 기준을 충족하지 못하는 태그 PDF 문서를 초래하는 소프트웨어 기능 조합을 너무 쉽게 사용할 수 있음을 알 수 있었습니다.

작성 도구로서 LaTeX는 작성자가 만들 수 있는 문서의 범위와 복잡성에 대해 거의 무제한의 유연성을 제공합니다. 이는 애초에 LaTeX를 선택한 바로 그 이유일 수도 있습니다. LaTeX는 또한 작성자가 문서의 일부로 사용할 수 있는 수천 개의 추가 패키지를 통해 확장성을 지원합니다. 게다가 작성자는 새 TeX 또는 LaTeX 매크로를 작성하거나 기존 매크로를 재정의하여 특정 효과를 구현할 자유도 있습니다. 그러나 아마도 이러한 자유와 유연성에는 대가가 있는지도 모릅니다. LaTeX가 올바르게 태그되고 접근 가능한 PDF 출력을 자동으로 생성하려면, 수많은 LaTeX 패키지와 매크로의 상호작용으로 생성되는 콘텐츠를 “어떻게든” 조율해야 하기 때문입니다.

실제로 LaTeX가 제공하는 확장성, 강력함, 다용도성 및 저작 “자유”는 PDF/UA 또는 PDF/A-{1|2|3}a 표준을 준수하는 완전히 접근 가능하고 태그가 지정된 PDF 문서를 원활하고 투명하게(“자동으로”) 생성하는 데 기술적 과제를 제기합니다. 더 넓은 TeX 및 LaTeX 커뮤니티는 이러한 과제를 해결하기 위해 열심히 노력하고 있으며, TeX User Group(TUG)은 PDF 접근성 및 PDF 표준 [작업 그룹](https://www.tug.org/twg/accessibility/). 이를 통해 연구 및 개발 노력을 조정하고 있습니다. 또한 [토론 목록](https://tug.org/mailman/listinfo/accessibility) 관심 있는 사람들이 TeX와 LaTeX를 사용한 태그 PDF 파일 생성에 대해 논의할 수 있는 방법을 제공합니다.

이러한 논의에서 기억할 가치가 있는 점은 LaTeX가 실제로는 실행 가능한 조판 프로그램이 아니라 TeX라고 하는 하위 수준 언어로 작성된 정교한 매크로(명령)들의 방대한 집합이라는 것입니다. 여러분이 정성껏 만든 LaTeX 문서와 최종 조판된 PDF 사이에는 TeX 엔진이라는 소프트웨어가 자리하고 있으며, 그 임무는 문서를 작성하고 구성하는 데 사용된 LaTeX 명령(즉, 매크로) 집합을 “실행”하여 그것들을 문서의 조판 표현으로 변환하고 이를 PDF 파일로 저장하는 것입니다. TeX/LaTeX 생태계에 처음 입문한 사람들은 TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX, LuaLaTeX 같은 여러 난해해 보이는 이름들에 종종, 그리고 당연히, 당황하곤 합니다. 여러분도 그렇다면, 다음 Overleaf 글이 도움이 될 것입니다 [이름에 담긴 것: TeX의 여러 변형에 대한 안내](/latex/ko/in-depth-articles/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) 이 글은 그런 용어들의 기원과 의미를 설명합니다.

pdfTeX, XeTeX 또는 LuaTeX 같은 TeX 엔진은 다음과 같은 소프트웨어 범주에 속합니다: *문서 컴파일러*: 이들은 LaTeX 코드를 가져와 LaTeX 매크로(명령)를 더 낮은 수준의 TeX 언어 지시로 “변환”한 뒤 이를 “실행”하여 조판 결과를 만들어 내는 방식으로 코드의 조판 형태로 컴파일합니다. TeX 기반 조판 시스템은 고도로 복잡한 콘텐츠—고급 수학, 악보, 화학 구조식, 그래픽, 정교한 다국어 조판 텍스트를 포함—를 생성할 수 있습니다. 이러한 복잡한 문서가 접근성 표준과 규정을 준수하도록 하려면, TeX 엔진과 LaTeX 매크로 모음 및 LaTeX 패키지는 생성하는 PDF 파일에 상당한 양의 추가 데이터를 포함시켜 적절하게 태그된 PDF 파일을 생성해야 합니다.

TeX 엔진은 극도로 복잡한 PDF 파일을 생성할 수 있지만, 그 내부 처리, 알고리즘 및 함수에는 *내장된* 기능 *특별히 설계된* 대신 태깅과 접근성 지원은 복잡한 매크로 프로그래밍을 통해 이루어져야 하며, 이는 TeX 엔진이 생성한 PDF에 추가 데이터를 “주입”하여 marked content sequence, 구조 요소, 그리고 논리 구조 데이터 구조를 저장합니다. `StructTreeRoot`여기서 그 “조율”이 분명히 드러납니다. LaTeX 핵심(kernel) 내부의 코드와 수천 개 패키지, 수많은 작성자 생성 매크로의 코드가 매우 주의 깊게 협력해야 매크로 실행이 결과 문서 콘텐츠의 올바른 태깅으로 이어질 수 있습니다. 그 “조율”은 작성자가 LaTeX의 기능, 명령, 기능성과 패키지 시스템, TeX 매크로의 힘을 어떻게 조합하고 사용하든 신뢰할 수 있어야 합니다.

### 작성자의 요구

대부분의 사람들에게 LaTeX는 원하는 결과를 얻기 위해 패키지를 선택하고 조합할 자유를 주는, 아름답게 조판된 문서를 만들 수 있게 해 주는 도구일 뿐입니다. 대다수의 LaTeX 작성자는 단지 문서가 “잘 작동”하길 바랍니다. 오류 없이 조판되어 논문, 기사, 보고서를 제출하거나 오래 기다린 그 책을 완성할 수 있어야 하기 때문입니다. 무리한 요구가 아니듯, LaTeX 사용자는 선택한 LaTeX 패키지 집합이 평화롭고 매끄럽게 공존하며 투명하게 상호 운용되어 문서를 만드는 데 필요한 명령과 기능을 제공하기를 기대합니다. LaTeX에서 태그된 PDF를 만들어야 하는 요구도 마찬가지일 것입니다. 즉, 투명하게, 그리고 작성자의 개입을 최소화한 채 “그냥 잘 작동”해야 합니다. 불행히도 우리는 아직 “짜잔! 내가 얼마나 이상한 짓을 하든 태깅은 그냥 알아서 된다”는 경험과는 거리가 있습니다. 접근성의 기술적 요구와 태그 PDF를 LaTeX 및 저작 자유와 결합하는 것은 본질적으로 복잡하며, 기술적 과제가 실제 구현과 해결에 적합해지려면 어떤 형태의 “작성 규율”이 필요할 수 있다는 점은 어쩌면 피할 수 없을지도 모릅니다.

별개의, 하지만 관련된 문제로는 잘못된 태깅이 최종 PDF의 시각적 결과에 아무런 영향을 미치지 않을 수 있다는 점이 있습니다. 겉으로는 완벽해 보이고 인쇄도 문제없이 될 가능성이 높지만, 작성자가 알지 못하는 사이 태깅은 “망가져” 있을 수 있으며, 나중에 PDF/A 적합성/검증 검사 실패나 화면 판독기 같은 접근성 소프트웨어를 통한 추가 실제 테스트를 거쳐서야 발견될 수 있습니다.

### Overleaf에서 생성된 PDF 파일

Overleaf는 사용자 커뮤니티에 브라우저 기반 LaTeX 편집기와 협업 저작을 지원하는 프로젝트 및 문서 관리 도구를 제공합니다. 이 모든 것은 표준 TeX Live 설치 위에 구축되어 있습니다. 사실상 Overleaf는 사용자가 웹 브라우저를 통해 “원격으로 LaTeX를 실행”할 수 있게 해 주며, 전체 TeX Live 시스템을 관리하고 유지하는 복잡성으로부터 한 층 보호해 줍니다.

Overleaf가 표준 TeX/LaTeX 설치를 사용하기 때문에, Overleaf 편집기에서 작성한 LaTeX 코드로부터 생성되는 PDF는 사용자가 자신의 로컬 장치에 설치한 설정을 포함하여, 동일한 버전의 다른 TeX Live 설치에 존재하는 것과 정확히 같은 기술을 사용하여 만들어집니다. 유일한 차이는 Overleaf의 LaTeX 코드를 컴파일하고 처리하는 TeX 엔진이 로컬 컴퓨터가 아니라 원격 서버에서 실행된다는 점입니다. Overleaf는 브라우저에서 효율적으로 다운로드/표시할 수 있도록 TeX가 생성한 PDF를 선형화하지만, 그 과정은 PDF 콘텐츠 자체의 접근성과는 관련이 없습니다.

Overleaf를 통한 접근 가능한 PDF 생성은 표준 TeX 엔진에 내장된 기능과, 사용자가 문서의 일부로 사용할 수 있는 적절한 LaTeX 매크로 패키지의 가용성에 달려 있습니다. Overleaf를 사용해 만든 LaTeX 문서는 다른 TeX 및 LaTeX 설치와 호환성을 유지해야 합니다. 사용자는 종종 제출을 위해 Overleaf의 LaTeX 프로젝트를 다양한 출판사 저널 시스템으로 내보내야 하기 때문입니다. Overleaf 전용 기능을 LaTeX 문서나 기반 TeX 엔진에 도입하면, 사용자가 자신의 작업을 다른 곳에서 사용하는 자유가 심각하게 제한될 것입니다.

Overleaf는 TeX/LaTeX 저작 시스템에서 생성되는 완전히 접근 가능한 PDF의 필요성을 인식하고 지원합니다. 우리는 접근성 문제를 연구하고, 태그 PDF를 지원하는 TeX 엔진과 실험적 LaTeX 패키지의 최신 발전을 탐구하는 데 시간을 투자합니다. 궁극적으로, 이 글을 쓰는 시점에는 LaTeX 작성자가 ( `\usepackage`)를 통해 일반 LaTeX 문서에서 완전히 접근 가능하고 PDF/UA를 준수하는 PDF를 원활하고 투명하게 생성하는 데 사용할 수 있는 “즉시 사용 가능한” 솔루션은 없습니다. 그러한 솔루션이 TeX Live 업데이트를 통해 제공되면, 물론 Overleaf 사용자 커뮤니티에서도 사용할 수 있게 될 것입니다.

### 태깅과 접근성을 살펴보기 위한 일부 LaTeX 패키지

많은 사람들에게, [tex.stackexchage](https://tex.stackexchange.com/) 는 TeX, LaTeX 또는 ConTeXt 관련 도움을 구할 때 가장 먼저 찾는 곳입니다. 이곳은 놀라운 자원이며, 다음 주제에 관한 질문도 많이 있습니다: [접근성](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) 와 LaTeX를 통한 접근 가능한 PDF 생성입니다. 이러한 질문들과 그 뒤를 잇는 답변과 댓글들을 읽고 살펴보면, 단 하나의 결론만이 불가피합니다. 현재로서는 모든 유형의 LaTeX 문서에서 완전히 접근 가능하고 표준을 준수하는 태그 PDF를 자동으로 만드는 완전한 프로덕션 수준의 해결책은 없습니다. 그러나 태깅을 지원하는 몇몇 패키지는 있는데, 아마도 제한된 범위의 사용 사례와 문서 유형 내에서만 그렇습니다. 다음 목록은 LaTeX 기반 PDF 태깅을 탐구하려는 독자를 위해 제공됩니다:

* [`tagpdf` 패키지](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): PDF 태깅 실험을 위해 설계된 매우 뛰어난 기능의 패키지입니다. pdfTeX와 LuaTeX를 지원하며, TeX 엔진을 통해 태그 PDF를 만드는 기술적 과제에 대한 훌륭한 주석을 포함한 매우 유용하고 흥미로운 문서를 제공합니다. 관련 문제를 더 잘 이해하고 싶은 사람이라면 반드시 읽어볼 만합니다. 향후 방향의 중심은 LuaTeX가 될 가능성이 큽니다.
* [`axessibility` 패키지](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov 및 Turin 대학교): 보조 기술이 PDF 파일의 수식에 접근할 수 있도록 합니다.
* [`접근성` 패키지](https://ctan.org/pkg/accessibility) (Andy Clifton): 태그가 지정되고 구조화된 PDF 파일을 만듭니다. CTAN 노트에 따르면 이 패키지는 “KOMA-Script 문서 클래스 사용자를 대상으로 함”이라고 합니다.
* [`accsupp` 패키지](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): PDF 파일에 대한 더 나은 접근성 지원을 제공하기 위한 실험용 패키지입니다.

추가로 주목할 만한 참고문헌은 2018년 논문 [수학 출판을 위한 PDF 표준 구현](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) 매쿼리 대학교 수학과의 Ross Moore 박사입니다. 그 논문에서 Moore 박사는 LaTeX에서 PDF를 태깅하는 과제에 대한 간단한 개요를 포함합니다:

> “어려움의 주요 원인은 서로 다른 환경들이 서로 상호작용하는 방식에 있습니다. LaTeX에는 한 환경이나 구조가 다음 환경이 시작되기 전까지는 वास्तव적으로 완성되지 않는 상황이 많이 있습니다. 따라서 공급된 콘텐츠 각각에 시작 태그와 종료 태그를 단순히 둘러 씌우는 것만으로는 충분하지 않습니다. 대신 주변 자료가 형성하는 맥락 안에서, 서로 다른 환경과 다른 구조가 실제로 어떻게 시작하고 끝나는지의 미묘함을 이해해야 합니다.”

Moore 박사는 또한 현재 [`pdfx`](https://ctan.org/pkg/pdfx) 패키지의 유지 관리 담당자이자 TeX/LaTeX를 사용한 태그 PDF의 전문가이자 선구자입니다. 그의 작업은 찾아볼 가치가 충분합니다. 여기에는 흥미로운 통찰을 제공하는 YouTube의 이 영상도 포함됩니다:

{% embed url="<https://www.youtube.com/embed/mPBtkCsChJw>" %}

#### pdfx 패키지에 대한 참고

다음 [`pdfx`](https://ctan.org/pkg/pdfx) 패키지(Ross Moore 외)는 PDF/A-1|2|3b(보관) 및 기타 옵션에 대한 뛰어난 지원을 제공하지만, 아직 태그가 지정된 PDF는 생성하지 않습니다.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/latex/ko/more-topics/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.