요약

  • 2016년 3월 발행된 IETF 정보 문서 RFC 7763은 text/markdown 미디어 유형을 등록했다. 등록에는 charset가 필요하고, 선택적 variant로 작성자가 의도한 문법을 밝힐 수 있다.
  • variant는 수신 측을 위한 힌트다. 수신 프로그램은 그 문법을 따를 수 있지만 다른 방식으로 읽을 수도 있다. RFC 7764는 Original, GFM, CommonMark, Pandoc 등 여러 Markdown 변형을 기록했다.
  • IANA는 미디어 유형 목록과 Markdown 변형 목록을 따로 관리한다. 두 목록은 이름을 공유하게 해 주지만 화면은 실제 파서가 만든다.

복사는 성공했고 표는 사라졌다

Markdown 파일은 원문 그대로도 읽을 만하다. 제목의 샵 기호, 목록의 별표, 코드 주변의 표시가 눈에 보인다. 이 편리함 덕분에 서비스마다 필요한 기능을 덧붙였다. 어떤 편집기는 세로줄을 표의 열로 바꾸고, 다른 편집기는 그냥 문장 속 문자로 둔다. 한 서비스 안에서만 글을 쓰고 읽을 때는 차이가 드러나지 않는다. 문서를 옮기는 순간 작성자가 맡겨 둔 해석 규칙도 함께 옮겨야 한다.

운영 지침의 담당자와 날짜가 표에 들어 있다고 해 보자. 새 시스템으로 보낸 뒤 해시를 비교하면 완벽하게 일치한다. 그런데 화면에서는 표 대신 세로줄이 남은 여러 줄이 보인다. 날짜가 어느 담당자의 것인지 독자가 다시 맞춰야 한다. 저장과 전송은 성공했다. 이용자가 의존하던 구조가 렌더링 단계에서 무너졌다. 파일 보존 보고서는 이 비용을 잡아내지 못한다.

RFC 7764는 이런 차이가 생긴 경로를 보여 준다. 2004년 John Gruber와 Aaron Swartz의 작업에서 출발한 Markdown은 Original, GFM, CommonMark, Pandoc 등 여러 변형으로 넓어졌다. 문서는 GFM의 기능으로 표, 울타리형 코드 블록, 자동 URL 링크 등을 적는다. 변형 이름은 장식이 아니다. 같은 표시가 제목인지, 표인지, 일반 글자인지를 정하는 동작 규칙이다.

전송용 이름표의 두 줄

RFC 7763은 먼저 문서의 종류를 정리했다. HTTP 응답이나 메일 첨부 파일에 text/markdown이라고 적으면 수신 측은 이 텍스트가 Markdown 계열임을 알 수 있다. 등록에는 charset가 필수다. 프로그램이 바이트를 문자로 읽어야 샵이나 세로줄을 문법으로 해석할 수 있기 때문이다. 이 유형에 정해진 기본 문자 집합은 없다.

다음 줄은 선택 사항인 variant다. Content-Type: text/markdown; charset=UTF-8; variant=Original은 종류와 인코딩에 더해 작성자가 생각한 문법을 알려 준다. 이 값이 없으면 수신 프로그램과 맥락이 읽는 법을 고른다. 값이 있어도 RFC는 그것을 힌트로 취급한다. 받는 쪽은 지정된 변형을 적용할 수 있지만, 그 선택과 실제 구현은 받는 쪽 몫이다.

여기서 이름과 기능의 거리가 보인다. 작성자는 올바른 변형 이름을 보냈어도 상대방의 프로그램이 그 문법을 구현하지 않았을 수 있다. 헤더에 단어를 더 쓴다고 표 기능이 설치되지는 않는다. RFC는 작성 의도를 지키려면 수신자가 아는 변형을 쓰라고 권한다. 호환성은 양쪽 프로그램이 같은 구조를 만들어 냈을 때 입증된다.

이름표는 저장 과정에서 떨어질 수도 있다. RFC 7764는 미디어 유형과 매개변수를 싣는 통신 환경을 벗어난 뒤 그 정보를 보관하는 방법을 논한다. 단독 .md 파일에는 원래의 variant 값이 남지 않을 수 있다. RFC 7763은 변형 정보와 관련 매개변수를 콘텐츠와 함께 기록하라고 권한다. 본문을 온전히 보관해도 읽는 법을 잃으면 다음 발행자는 추측으로 문서를 재구성하게 된다.

등록부에 파서는 없다

IANA의 미디어 유형 등록부에는 text/markdown이 있다. 별도 Markdown 변형 등록부에는 Original, GFM, CommonMark, Pandoc 같은 이름이 있고, 등록 절차는 선착순이다. 공통 이름을 갖추면 서로 다른 시스템이 무엇을 주고받는지 더 정확히 말할 수 있다. 각 프로그램이 그 이름의 문법을 어느 범위까지 실행하는지는 별도로 확인해야 한다.

문서 저장소를 옮길 때는 두 가지 검사가 필요하다. 해시는 글자가 빠지지 않았는지 알려 준다. 기존 화면과 새 화면의 비교는 표, 링크, 제목, 코드가 같은 의미로 남았는지 알려 준다. 프로그램 이름과 버전까지 남겨야 나중에 출력이 바뀌었을 때 원인을 찾을 수 있다. “Markdown 지원”이라는 문구만으로는 운영 판단을 끝낼 수 없다.

여기서 쓴 네 건의 공식 자료는 등록과 문법의 경계를 입증한다. 어느 제품이 특정 시기에 variant를 보냈고 실제로 따랐는지 알려면 날짜가 있는 설명서, 소스 코드 배포판 또는 보관된 응답이 필요하다. 2016년의 확실한 변화는 더 단순하다. 파일은 네트워크에서 공통 이름을 얻었고, 페이지의 형태는 여전히 수신 프로그램이 정했다.