마크다운은 장기적인 일기 작성에 적합한 포맷일까?

마크다운이 보존할 수 있는 것과 그렇지 못한 것

마크다운은 제목, 강조, 목록, 링크 등의 구조를 위한 간단한 규칙을 갖춘 플레인 텍스트입니다. 작성 당시 사용한 앱을 더 이상 쓸 수 없더라도 기본 텍스트 에디터에서 `2026-09-27.md`와 같은 파일을 읽을 수 있습니다. [CommonMark 0.31.2 사양](https://spec.commonmark.org/0.31.2/)은 표준화된 마크다운 문법과 렌더링 규칙을 설명하지만, 모든 프로그램이 마크다운의 온갖 변형 문법을 동일하게 해석한다고 보장하지는 않습니다.

이러한 차이가 중요한 이유는 '마크다운'이 하나의 통일된 기능 세트가 아니기 때문입니다. CommonMark는 제목, 문단, 목록, 링크, 이미지와 같이 친숙한 구조를 다룹니다. 앱에 따라 표, 각주, 체크박스, 콜아웃 등의 문법을 추가할 수 있습니다. 하지만 다른 앱에서는 이러한 추가 문법이 문자 그대로 노출되거나, 생략되거나, 다르게 렌더링될 수 있습니다. 일기 앱을 선택할 때는 원본 마크다운 파일을 내보낼 수 있는지, 그리고 앱 전용 서식을 어떻게 처리하는지 확인해야 합니다.

마크다운의 이미지 문법은 이미지 파일을 가리킬 뿐, 텍스트 문서 내에 이미지를 포함하거나 보존하지 않습니다. 음성 녹음 파일 역시 별도의 파일로 존재해야 합니다. 첨부 파일이 누락되거나, 이름이 바뀌거나, 새 앱이 접근할 수 없는 위치에 저장되면 일기 안의 링크는 깨질 수 있습니다. 첨부 파일은 항상 일기와 함께 보관하고, 도구가 지원하는 경우 안정적인 상대 경로를 사용하며, 미디어 파일을 열 수 없더라도 문맥을 이해할 수 있도록 일기 안에 간단한 설명을 덧붙이세요.

간단한 일기 폴더 구조

날짜 기반의 폴더 구조를 사용하면 원본 앱 밖에서도 내용을 쉽게 탐색할 수 있습니다. 예를 들어, `Journal/` 폴더 안에 `README.txt`와 `Entries/`, `Media/` 폴더를 둡니다. 날짜가 적힌 일기는 `Entries/2026/2026-09-27.md`에 저장하고, 해당 사진은 `Media/2026-09-27-garden.jpg`에 저장합니다. 해당 일기에서 사진으로 연결되는 상대 링크는 `../../Media/2026-09-27-garden.jpg`가 되며, 이 파일은 아카이브와 함께 이동해야 합니다.

일기는 `# 2026-09-27`로 시작한 뒤 짧은 생각과 함께 `[비 온 뒤의 정원](../../Media/2026-09-27-garden.jpg)`과 같은 링크를 덧붙여 구성할 수 있습니다.

`README.txt`에는 폴더 구성, 파일명 명명 규칙, 마크다운 종류, 첨부 파일 이름 및 확장 문법 등을 설명해둘 수 있습니다. [미국 의회도서관의 개인 디지털 기록 조언](https://digitalpreservation.gov/personalarchiving/records.html)에서는 설명이 명확한 이름, 이해하기 쉬운 폴더 구조, 간단한 설명을 남길 것을 권장합니다. 이는 일반적인 보존 원칙이며, 마크다운만을 특정해 지지하는 것은 아닙니다.

플레인 텍스트를 신중하게 선택하고, 문자 인코딩을 명시하세요

애플리케이션에서 인코딩 선택이 가능하다면 일기를 UTF-8로 작성하고 내보내세요. UTF-8은 유니코드 텍스트를 인코딩하는 표준화된 방식입니다. [RFC 3629 사양](https://www.rfc-editor.org/rfc/rfc3629.html)은 유니코드와의 관계 및 ASCII 기반 소프트웨어와의 호환성을 설명합니다. 메모에 인코딩 방식을 적어두면, 특히 여러 언어, 악센트 기호, 특수 기호가 포함된 경우 미래의 독자가 깨진 문자의 원인을 파악하는 데 도움이 됩니다. 다만 이것이 데이터 손상을 방지하거나 모든 프로그램이 텍스트를 올바르게 처리하도록 보장하는 것은 아닙니다.

파일명은 단순하고 일관되게 유지하세요. `YYYY-MM-DD`와 같이 정렬 가능한 날짜 형식이 유용한 규칙입니다. 특정 앱의 숨겨진 정리 체계나 태그에만 의존하여 일기를 식별하는 방식은 피하세요. 태그는 파일 내부에서 여전히 유용할 수 있지만, 파일이 다른 곳으로 이동하더라도 유지되어야 할 핵심 맥락은 일반 텍스트로 적어두는 것이 좋습니다.

앱 전용 특수 기능을 항상 염두에 두세요

특정 앱의 워크플로에 수년간의 기록을 맡기기 전에, 실제로 사용하는 기능들을 담은 샘플 일기를 작성해보세요. 제목, 링크, 표나 체크박스(해당하는 경우), 사진이나 음성 첨부 파일 등을 포함해 테스트합니다. 이를 내보낸 다음, 마크다운을 지원하는 다른 에디터와 일반 텍스트 에디터에서 열어보세요. 글 내용, 날짜, 서식 기호, 첨부 파일 참조 링크가 제대로 유지되는지 확인해야 합니다.

앱에서 독자적인 문법을 사용하는 경우, 해당 기능이 마이그레이션 비용을 감수할 만큼 가치 있는지 판단하세요. 예를 들어, 앱 전용 콜아웃은 시각적으로 보기 좋을 수 있지만, 표준 제목과 문단 형식이 다른 환경에서 해석하기 훨씬 쉽습니다. 확장 문법을 계속 사용할 생각이라면 `README.txt`에 이를 기록해 두고, 가능한 경우 원본 앱에서 내보낸 결과물을 함께 보관하세요. 화면에 렌더링된 모습과 그 바탕이 되는 원본 텍스트는 구분해서 점검해야 합니다.

백업과 개인정보 보호는 별개의 요구사항입니다

읽기 쉬운 포맷이라고 해서 그것이 곧 백업 전략이 될 수는 없습니다. 최소 두 개 이상의 사본을 유지하고, 로컬 기기와 별도의 드라이브나 저장 위치 등 서로 다른 장소에 보관하세요. [미국 의회도서관의 개인 디지털 기록 지침](https://digitalpreservation.gov/personalarchiving/records.html)에서는 여러 사본을 만들어 서로 다른 장소에 보관하고, 최소 1년에 한 번씩 파일을 점검하며, 필요할 때 새로운 사본을 만들 것을 제안합니다. 이는 일반적인 개인 기록 보존 권장사항이며, 마크다운이 독보적인 보존성을 지녔다는 의미는 아닙니다.

마찬가지로 마크다운 파일이 플레인 텍스트이거나 특정 폴더에 저장되어 있다고 해서 저절로 암호화되는 것은 아닙니다. 기기, 백업 저장소, 연동된 동기화 서비스에 누가 접근할 수 있는지 고려하세요. 암호화를 사용할 경우 복구 키나 비밀번호를 반드시 찾아낼 수 있도록 하고, 백업을 정상적으로 열 수 있는지 테스트해보아야 합니다. 그렇지 않으면 데이터가 온전히 남아 있어도 암호화 때문에 사용할 수 없게 될 수 있습니다. 개인정보 보호 조치와 실제로 실행 가능한 복구 계획 사이에서 균형을 잡으세요.

아카이브를 신뢰하기 전에 마이그레이션 연습을 해보세요

마이그레이션 연습은 일기가 현재 앱을 벗어나서도 온전히 의미를 유지할 수 있는지 확인하는 과정입니다. 새로운 작업 방식을 도입하기 전에 몇 개의 샘플 일기로 테스트해보고, 이후 백업본을 이용해 정기적으로 이를 반복할 수 있습니다.

**테스트 세트를 만드세요.** 외국어나 악센트가 들어간 텍스트, 평소 사용하는 서식, 최소 하나의 이미지 또는 음성 첨부 파일을 포함하세요. 자주 사용하는 앱 고유 기능이 있다면 이 역시 포함합니다.

**파일을 내보내세요.** 마크다운 일기와 미디어 파일을 유지하려는 폴더 구조에 맞게 저장합니다. 내보내기 안내 사항이나 README를 확인하여 인코딩, 문법 확장 기능, 첨부 파일 명명 방식이 명시되어 있는지 확인하세요.

**폴더를 다른 곳으로 복사하세요.** 같은 앱 라이브러리의 다른 뷰가 아닌, 완전히 별도의 저장 위치를 사용하세요. 사본을 확인할 때까지 원본은 그대로 둡니다.

**사본을 독립적으로 열어보세요.** 가능하다면 다른 에디터나 컴퓨터를 사용해 보세요. 텍스트를 직접 읽어보고, 내보낸 파일을 점검하며, 각 미디어 링크를 열어봅니다. 문자가 깨지지 않았는지, 첨부 파일이 잘 열리는지 확인하세요.

**복원을 시도해보세요.** 이전하려는 대체 도구가 있다면 복사한 폴더를 가져오거나 열어봅니다. 손실된 서식이나 기능이 있는지 확인하세요. 파일이 암호화되어 있다면 저장해 둔 복구 정보를 통해 복원된 사본의 잠금을 해제할 수 있는지 확인합니다.

**작동한 방식을 기록하세요.** 내보내기 단계, 종속성, 변환이 필요한 앱 전용 기능 등을 `README.txt`에 업데이트하세요. 앱에 큰 변화가 생겼을 때나, 미국 의회도서관이 제안하는 연례 파일 점검과 같이 정기적인 일정에 맞춰 이 연습을 반복하세요.

실패한 단계는 유용한 단서가 됩니다. 누락된 첨부 파일은 내보내기가 불완전했거나 경로에 문제가 있음을 나타내며, 깨진 문자는 인코딩 점검이 필요하다는 뜻입니다. 사라진 콜아웃이나 표는 앱 고유의 확장 기능 때문일 수 있습니다. 워크플로를 수정한 뒤 다시 연습을 진행하고, 그 이후에야 내보낸 결과물을 신뢰할 수 있는 사본으로 취급하세요.

그렇다면 마크다운은 좋은 선택일까요?

일기의 대부분이 텍스트이고, 원본 앱 없이도 읽을 수 있는 파일을 중요하게 생각하며, 첨부 파일과 백업을 별도로 관리할 의향이 있다면 마크다운을 선택하세요. 다양한 미디어, 독자적인 서식, 특정 앱의 비공개 라이브러리에 저장되는 기능에 크게 의존한다면 내보내기 기능이 철저히 검증된 워크플로를 선택하세요. 어느 쪽이든 간단한 테스트를 통해 시스템을 판단할 수 있습니다. 별도의 사본에서 일기를 찾고, 텍스트를 읽고, 구조를 이해하며, 첨부 파일을 정상적으로 열 수 있습니까? 마크다운은 텍스트에 대해 이 테스트를 더 쉽게 만들어 주며, 그 외의 모든 것은 주변 아카이빙 습관에 달려 있습니다.

이 주제 더 살펴보기