워드 프로세서 파일 형식의 역사, .doc와 .docx의 복잡성, 그리고 결국 마크다운이 가장 실용적인 글쓰기 형식으로 자리 잡게 된 이유를 살펴본다.
저는 언제나 단어를 타이핑하고 그것이 화면에 나타나는 행위를 즐겨 왔습니다. 제가 가장 좋아하는 워드 프로세서는 아마도 WordPerfect일지도 모릅니다(여기). 하지만 저는 그중 거의 전부를 써 봤습니다. 이런 프로그램들은 컴퓨터의 전체 가치 제안을 저에게 납득시켜 준 것들이었습니다. 학교에서 써 본 타자기와 비슷했지만, 모든 면에서 훨씬 더 쉬웠습니다. 지울 수 있었고, 문단을 이리저리 옮길 수도 있었습니다. 반칙처럼 느껴졌고, 저는 그게 너무 좋았습니다.
시간이 지나면서 워드 프로세싱에서 말하는 "문서"를 구성하는 요소는 점점 더 복잡해졌습니다. 이는 워드 프로세서가 타자기의 대리물에서 출발해 출판 도구 모음에 더 가까운 무언가로 발전하면서 커졌습니다. 처음에는 WordPerfect, WordStar, MultiMate 같은 프로그램들이 독점적인 서식 코드가 박혀 있는 평평한 바이너리 파일을 사용했습니다.
워드 프로세서가 그저 타자기의 대리물이던 시절에는 이것이 매우 합리적이었습니다. 하지만 Microsoft Word가 인기를 끌며 빠르게 지배적인 워드 프로세서로 자리 잡자, 우리는 .doc 파일 형식의 부상을 보게 됩니다. 이것은 이전 것들에 비해 복잡성이 기하급수적으로 증가한 것이었고, 그럴 만도 했습니다. 갑자기 워드 프로세서는 "만능 도구"가 되어 가고 있었기 때문입니다. 단순한 타이핑이 아니라 레이아웃, 이미지, 수정 추적, 임베드 객체, 그리고 Microsoft가 집어넣을 수 있는 온갖 것들이 다 들어갔습니다.
기본적으로 .doc는 Compound File Binary Format인데, 이는 사실상 파일을 섹터로 쪼개고 File Allocation Table로 연결해 놓은 FAT 파일시스템과 같습니다.
흥미로운 설계입니다. 일반적인 파일시스템이라면 .doc에 들어 있는 모든 것을 담기 위해 파일들이 꽤 난잡하게 흩어졌을 텐데, 그 모든 것을 하나의 파일 안에 들어 있는 단순화된 파일시스템 내부에 저장하면 성능을 최적화하고, 평평한 파일 안에 별도 객체를 저장할 때 따라오는 오버헤드를 줄일 수 있었습니다. 쓰기 작업도 최적화되는데, 객체를 하나 추가할 때 파일 전체를 다시 쓸 필요가 없고 수정 이력을 유지하는 것도 단순하게 만들 수 있기 때문입니다. 하지만 사용자 관점에서는 "그냥" 하나의 파일만 다루는 셈이었습니다. (Reference)
.doc는 폭발적으로 퍼졌고, 빠르게 인류의 문서 출력물에 대한 기본 파일 형식이 되었습니다. 학교 리포트, 사무실 메모, 이력서, 그리고 우리 삼촌이 분명히 완성할 거라고 하던 위대한 미국 소설까지, 전부 .doc 파일이었습니다. 하지만 이 파일들에는 문제가 있었습니다.
정말 지독할 정도로 자주 손상되었습니다.
기억해 보세요. 이것들은 현대 컴퓨터와 비교하면 끊임없이 멈추고 충돌하던 기계의 회전식 하드디스크 위를 오가던 중요한 문서들이었습니다. 흔히 플로피 디스크에 복사되었고, 나중에는 컨퍼런스에서 아무 업체나 뿌리던 싸구려 USB 메모리로 옮겨졌습니다. 그리고는 배낭이나 코트 주머니에 들어간 채 다른 컴퓨터로 운반되었습니다. 전체 작업 흐름의 구조적 안정성은 수프가 가득 든 샌드위치 봉지와 다를 바 없었습니다.
당신의 하드 드라이브 파일시스템 -> 당신의 .doc 파일(파일 자체로 손상될 수 있음) -> 그 안에 미니 파일시스템을 담고 있음(이것도 내부적으로 손상될 수 있음) -> 실제 문서 내용을 관리함
Word가 중요한 파일을 저장할 때는 실제로 여러 가지 작업을 하고 있었습니다. 즉 다음을 수행했습니다.
이것들은 원자적 연산이 아니었기 때문에, 컴퓨터가 늘 충돌하거나 문제를 일으키던 시대에는 어떤 구조는 갱신되고 다른 구조는 갱신되지 않는 상황이 아주 쉽게 벌어졌습니다. .txt 파일과 비교해 보면, 거기서는 보통 이전 버전이 남거나 잘린 새 버전이 생길 뿐입니다. 내용 일부를 잃을 수는 있어도 읽을 수 없는 파일이 되는 일은 거의 없습니다. 하지만 .doc의 경우 헬프데스크 IT 일을 하는 사람 입장에서는, 읽을 수 없게 손상된 파일을 들고 오는 사람들을 끊임없이 보게 되었습니다.
그리고 정말 더 잔인한 부분은 이겁니다. 같은 파일을 오래 작업할수록 그 파일은 대개 더 중요해집니다. 그런데 Word는 뒤처리를 하지 않았습니다. .doc 파일에 이미지, 변경 추적, 수정 이력이 쌓일수록 내부 구조는 더 복잡해지고 파일은 더 커졌습니다. 하지만 문서에서 내용을 삭제해도 데이터가 파일에서 실제로 제거되지는 않았습니다. 내부적으로는 빈 공간으로 표시되지만 그대로 남아 있었죠. 마치 길가에 내다 놓은 가구가 아무도 가져가지 않아 계속 거기 있는 것처럼 말입니다.
파일은 점점 비대해졌습니다. 내부 단편화는 심해졌습니다. 그리고 손상될 확률은 그 내용에 얼마나 애착이 있는지에 정비례하여 증가했습니다.
사용자들은 파일을 자주 저장해야 했고(AutoRecover는 충분히 믿을 만하지 않았으니까요), Word가 처음부터 깨끗한 버전을 다시 쓰도록 주기적으로 다른 이름으로 저장("Save As")해야 한다는 교육까지 받아야 했습니다. 이것은 디지털 세계에서 "차는 잘 굴러가는데 정기 점검으로 500마일마다 엔진을 재조립하면 됩니다"라고 듣는 것과 같았습니다.
결과적으로 Microsoft Word는 기술자들 사이에서 금세 다루기 끔찍한 프로그램이라는 평판을 얻게 되었습니다. 워드 프로세서로서 나빴기 때문이 아닙니다. 사실 워드 프로세싱 자체는 꽤 잘했습니다. 문제는 사용자가 눈물을 글썽이며 헬프데스크에 찾아왔을 때, 제가 그들을 도와줄 수 있는 도구가 대부분 쓸모없었다는 점이었습니다.
저는 원시 파일에서 텍스트 패턴을 스캔할 수 있었고, 그러면 종종 내용은 끌어낼 수 있었습니다. 하지만 서식이 없으니 그것은 진짜 복구된 파일이라기보다 토네이도가 지나간 뒤 들판에 흩어진 소지품을 발견하는 것에 가까웠습니다. 기술적으로는 당신 물건이 맞지만, 어떤 쓸모 있는 배치도 아닌 상태인 셈입니다. 때로는 FAT를 재구성하거나 다른 디렉터리 엔트리를 시도해 약간 더 오래된 버전을 복구할 수도 있었습니다. 하지만 대체로 .doc가 구조적 오류를 만나면, 그 파일은 끝장이었고 당신의 작업물은 영원히 사라졌습니다.
그 결과 헬프데스크에서는 끝이 없는 상담이 이어졌습니다. 저는 사람들에게, 네, 몇 달 동안 이 파일에 작업하신 건 이해하지만, 이건 사라졌고 누구도 도와드릴 수 없다고 설명해야 했습니다. 저는 파일시스템을 좀 아는 애도 상담사가 되어 버렸습니다. 다행히 사람들은 금세 강박적으로 파일을 여러 위치에 서로 다른 이름으로 복사하는 법을 익혔습니다. thesis_final.doc, thesis_final_v2.doc, thesis_FINAL_FINAL_REAL.doc 같은 식으로요. 하지만 이건 적어도 한 번은 데어 봐야 배우는 일이었는데, 그건 마치 차의 브레이크가 안 듣는다는 걸 버스에 들이받고 나서 배웠다고 말하는 것과 비슷합니다.
그래서 2007년 무렵 .doc에서 .docx로의 전환이 일어납니다. 여기에는 .doc의 문제에서 얻은 뼈아픈 교훈이 많이 반영되었습니다. 우선 이것은 그냥 번들, 구체적으로는 ZIP 아카이브입니다.
my_document.docx (renamed to .zip)
├── [Content_Types].xml
├── _rels/
│ └── .rels
├── word/
│ ├── document.xml ← the actual text content
│ ├── styles.xml ← formatting/styles
│ ├── fontTable.xml
│ ├── settings.xml
│ └── media/
│ ├── image1.png ← embedded images
│ └── image2.jpg
└── docProps/
├── app.xml
└── core.xml ← metadata
이제 이론적으로는 아주 훌륭합니다. 내용은 사람이 읽을 수 있는 XML입니다. 이미지는 그냥 이미지 파일입니다. 무언가 잘못되더라도 파일 이름을 .zip으로 바꾸고 압축을 푼 뒤, document.xml을 Notepad에서 열어서 최소한 텍스트만큼은 복구할 수 있습니다. 불투명한 바이너리 덩어리를 바라보며 기도하던 시대는 끝날 예정이었습니다.
하지만 실제로는 끔찍한 일이 벌어졌습니다. Microsoft는 somehow 인류 역사상 최악의 XML을 만들어 내는 데 성공했습니다.
제가 평생 이런 건 본 적이 없기 때문에, 이 복잡성이 어느 정도인지 짚고 넘어가겠습니다.
여기가 ECMA-376 표준 웹사이트입니다. 그리고 다음과 같은 4부 다운로드를 보는 순간, 당신은 이미 곤란해졌다는 걸 알아야 합니다.
Part 1을 다운로드하면 다음과 같은 것을 받게 됩니다.
이제 그 PDF를 열어 보세요. 각오해야 합니다. 무려 5039페이지짜리 PDF입니다.
저는 이렇게까지 복잡한 무언가를 상상해 본 적이 없습니다. 게다가 사실상 읽을 수도 없습니다. 그리고 이 말은, 인생에서 여러 번 심심하다는 이유만으로 자동차 수리 매뉴얼을 처음부터 끝까지 읽어 본 사람으로서 하는 말입니다. 저는 한때 1994 Honda Civic용 Haynes 매뉴얼을 마치 해변 소설처럼 읽은 적도 있습니다. 하지만 이건 그런 게 아닙니다. 이건 표준 위원회에 케이터링 예산은 주고 마감일은 주지 않았을 때 벌어지는 일입니다.
잠들기 전 가볍게 읽기 좋은 자료
당시 Microsoft가 OOXML을 의도적으로 필요 이상으로 복잡하게 만들고 있다는 비난이 있었습니다. 즉 이것을 "개방형 표준"이라고 주장하면서도, 그 표준을 너무나 방대하고 난해하게 만들어 다른 누군가가 구현하려면 영웅적인 노력이 필요하게 하려는 목적이었다는 것입니다. 저는 이게 의심의 여지 없이 사실이라고 생각합니다. LibreOffice에는 이에 대한 훌륭한 블로그 글이 있는데, 거기에는 인상적인 비교가 실려 있습니다.
document.xml과 content.xml 파일의 길이를 비교해 보면 복잡성의 차이는 두드러집니다. content.xml 파일은 6,802줄인 반면, document.xml 파일은 60,245줄이며, 비교 대상인 텍스트 문서는 5,566줄입니다.
즉 ODF 형식과 OOXML 형식의 차이는 XML 파일을 기하급수적으로 덜 복잡하게 만듭니다. 당신은 이 악몽 같은 명세와 호환되기 위해 엄청난 양의 작업을 하거나, 아니면 사실상 워드 프로세싱 생태계 전체에서 밀려나는 처지가 될 수 있었습니다.
이건 의심할 여지 없이 Microsoft가 두 마리 토끼를 모두 잡기 위해 한 일이었습니다. 규제 기관과 고객에게 이것이 독점 형식이 아니며, 문서 생산을 위해 누구도 Microsoft Office 생태계에 묶여 있지 않다고 말할 수 있게 되는 것입니다. 그 무렵 미국 밖 여러 나라에서는 정부 문서와 기록물이 사실상 Microsoft 사용에 종속되는 것에 대한 우려가 커지고 있었습니다. 하지만 다소 아이러니하게도, 결국 이것은 그리 중요하지 않게 되었습니다. 머지않아 유일하게 중요해질 데스크톱 애플리케이션은 브라우저였기 때문입니다.
워드 프로세서의 파일 형식 자체도 문제였지만, 더 근본적으로는 사람들이 콘텐츠를 소비하는 방식 자체가 바뀌고 있었습니다. 2010년 이후 데스크톱 기반 애플리케이션은 점점 덜 중요해졌고, 사용자는 Microsoft Word와 전통적인 파일들을 끝없이 이메일로 주고받거나 파일 공유를 통해 작업하는 믿기 어려울 만큼 투박한 방식에 점점 더 짜증을 내기 시작했습니다.
그래서 .docx는 "파일을 열었더니 손상되는 문제"의 관점에서는 더 나은 형식이었지만, 동시에 스마트폰 시대와는 근본적으로 맞지 않았습니다. 이런 파일을 열 수는 있었지만, 얼마 지나지 않아 사람들이 소비하길 원하는 콘텐츠는 무엇이든 브라우저를 통해 볼 수 있어야 한다는 기대가 생겼기 때문입니다.
"소프트웨어 회사에서 일한다"는 것이 틈새 직업에서, 만나는 사람마다 다 하는 것처럼 보이는 일이 되어 가면서, 이슈, 진행 상황 추적, 토론 등의 사실상 표준 플랫폼은 GitHub로 옮겨갔습니다. 저를 포함한 많은 사람들이 처음 Markdown을 접하고 정기적으로 쓰기 시작한 곳이 바로 여기였습니다.
Markdown의 공동 창시자인 John Gruber는 "표준" Markdown에 대한 훌륭한 설명을 제공했고, 이후 여러 갈래의 변형이 생겨났습니다. 그것은 여기에서 볼 수 있습니다. 하지만 중요한 점은 이것입니다. 거의 외울 것 없이도 매우 빠르게, 지구상의 거의 모든 브라우저에서 동작하는 웹페이지를 만들어 낼 수 있다는 점입니다. 그리고 대체로 같은 문법이 GitHub, Slack, Confluence 등에서도 그대로 통합니다. 이제 더 이상 내가 보내는 상대가 내가 쓴 것을 올바른 형식으로 보려면 적절한 라이선스를 가지고 있는지 고민할 필요가 없어졌습니다.
여기에 Google Docs, Slides 등을 포함한 Google Workspace의 부상이 더해지면서, 기술 인력은 Markdown 페이지를 통해 대화를 나누고, 덜 기술적인 인력은 완전히 클라우드에서 작업하게 되었습니다. Google은 Word가 늘 쓰이던 종류의 일, 즉 수정 이력 추적, 피드백 처리, 안전한 공유 같은 부분에서 Microsoft보다 더 나았습니다. 전체 기능 집합의 일부만 갖고 있었지만, 결국 우리 모두가 알게 되었듯 Word의 고급 기능을 아는 사람은 어차피 거의 없었습니다.
2015년쯤 되면 상황은 이미 분명했습니다. 회사들은 더 이상 기본적으로 저에게 Office 라이선스를 주지 않았고, "원하면 요청할 수 있음"으로 바꾸었습니다. 대기업에서 일해 본 사람이라면 누구나 알겠지만, 이것은 사망 선고입니다. 제가 작업 중인 파일을 당신이 성공적으로 열 수 있는지 확신할 수 없다면, 그 플랫폼 안에서 문서를 작성할 이유가 전혀 없습니다. 여기에 회사에서 이메일이 사실상 죽고 Slack/Teams로 대체된 변화까지 더해지면서, 전체 작업 흐름은 큰 소란도 없이 사라졌습니다.
그리고 LLM의 부상과, 그들이 Markdown을 사용하고 또 어쩌면 과용하면서, 우리는 .md의 정점에 도달했습니다. Markdown은 이제 우리의 도움말 문서 형식이고, 많은 웹사이트가 전적으로 Markdown으로부터 생성됩니다. 이제 제가 무엇이든 쓸 때 가장 흔히 사용하는 형식이 되었습니다. 이 글도 원래 Vim 안에서 Markdown으로 작성되었습니다.
Markdown이 결국 승리한 이유는 많다고 생각합니다. 무엇보다도, 이해하기 쉬운 방식으로 실제 문제를 해결했기 때문입니다. HTML을 쓰는 것은 괴롭고, 대부분의 작업에는 과합니다. Markdown은 그럴 필요를 없애 주었고, 결과물은 사용자에게 웹 브라우저 접근권만 있으면 되는 보편적이고 매우 성능 좋은 방식으로 소비될 수 있었습니다.
하지만 저는 이것이 형식에 대한 흥미로운 교훈도 보여 준다고 생각합니다. .doc, .docx, 그리고 ODF는 현대 워드 프로세싱이 할 수 있는 복잡한 일들을 처리하기 위해 설계된 상당히 고도로 특화된 것들입니다. LibreOffice는 가능한 요구사항의 매우 넓은 범위를 아우르는 정말 놀라운 일들을 할 수 있게 해 줍니다.
Markdown은 그런 형식들이 하는 대부분의 일을 하지 못합니다. 여백을 설정할 수도 없고, 단을 나눌 수도 없습니다. 피벗 테이블을 임베드할 수도 없고, 변경 내용을 추적할 수도 없으며, 모든 페이지에 45도 회색 Calibri로 DRAFT 워터마크를 넣을 수도 없습니다. Markdown에는 글꼴 색상을 바꾸는 기본 방식조차 없습니다.
그런데도 그 어떤 것도 중요하지 않았습니다. 알고 보니 대부분의 글쓰기는 그런 것들과 관련이 없기 때문입니다. 대부분의 글쓰기는 말이 되는 구조 속에 단어를 적어 넣고, 그 단어들을 다른 사람들 앞에 가져다 놓는 일입니다. Markdown은 지금까지 만들어진 그 어떤 것보다도 적은 마찰로 그 일을 해냅니다. 10분이면 배울 수 있고, 어떤 기기에서든 어떤 텍스트 편집기로든 작성할 수 있으며, 렌더링하지 않고도 원본 파일을 읽을 수 있고, 버전 관리에서 diff를 볼 수 있으며, 사실상 어떤 출력 형식으로도 변환할 수 있습니다.
파일은 평범한 일반 텍스트입니다. 그것들은 지금 이를 렌더링하는 모든 애플리케이션보다 더 오래 살아남을 것입니다. 어느 회사의 것도 아닙니다. 의미 있는 방식으로 손상될 수도 없습니다. Markdown 파일에 일어날 수 있는 최악의 일은 일부 문자가 사라지는 것뿐이고, 그 경우에도 파일의 나머지는 멀쩡합니다. 수십 년 동안 .doc 파일을 마치 자동차 지붕에 묶어 조심스럽게 집에 실어 와야 하는 연약한 꽃처럼 돌봐 온 뒤에, 구조적으로 실패할 수 없는 형식이라는 발상은 단지 편리한 것을 넘어섭니다. 그것은 일종의 해방입니다.
가끔 저는 한밤중에 Vim으로 글을 쓰면서 이것을 생각합니다. 깜빡이는 커서 하나와, 제가 죽은 뒤에도 여전히 읽을 수 있을 평범한 텍스트 파일, 그리고 저뿐인 상태에서 말입니다. 파일시스템 안의 파일시스템도 없습니다. 섹터 할당 테이블도 없습니다. 5,039페이지짜리 명세도 없습니다. 그저 단어 몇 개와 해시 기호 몇 개, 그리고 다시는 그 문제를 생각하지 않아도 된다는 사실만 있을 뿐입니다.