들여쓴 목록은 그 자체로 트리입니다. 마인드맵은 그 트리를 다르게 그린 것입니다. 그래서 이 작업은 사실 변환이 아니라 보는 방식을 바꾸는 일이고, 이를 지원하는 도구는 모두 같은 방식으로 동작합니다. 들여쓰기 한 단계가 깊이 한 단계가 됩니다.
# Product launch
## Positioning
- Who it is for
- What it replaces
## Channels
- App Store
- Newsletter
이것을 가져오면 중심 노드에 가지 두 개, 가지마다 자식 두 개가 생깁니다. 드래그도, 배치 결정도 필요 없습니다. 그래서 개요를 직접 입력하는 것이 마인드맵을 만드는 가장 빠른 방법입니다. 그리는 것보다 빠르고, 노드를 끌어서 배치하는 것보다 훨씬 빠릅니다.
알아 둘 두 가지 형식
마크다운(Markdown)은 이미 가지고 있는 형식입니다. 메모, 회의록, AI의 출력, README 같은 것들입니다. 무언가를 가져올 수 있는 마인드맵 앱이라면 마크다운은 모두 가져옵니다.
OPML은 개요를 위해 만든 XML이며, 편의성보다 구조가 중요할 때 쓰는 형식입니다. 왕복해도 구조가 유지됩니다. OPML로 내보내 다른 곳에서 편집하고 다시 가져와도 트리는 그대로입니다. 마크다운에는 둘 곳이 없는 노드별 메모도 담을 수 있습니다. 거의 모든 아웃라이너가 OPML로 내보내므로 도구 사이의 교환 형식이기도 합니다.
실용적인 규칙은 이렇습니다. 개요를 맵으로 만들 때는 마크다운, 맵을 앱 사이에서 옮길 때는 OPML.
깔끔하게 가져와지는 개요 쓰기
가져오기 문제는 거의 다음 네 가지 규칙으로 해결됩니다.
들여쓰기 방식을 하나 정해서 끝까지 지키세요. 한 문서에서 제목(#, ##)과 목록 들여쓰기를 섞으면 가져오기 도구마다 해석이 달라집니다. 처음부터 끝까지 제목만 쓰거나 중첩 글머리 기호만 쓰세요. 꼭 섞어야 한다면 위쪽 두 단계는 제목, 그 아래는 글머리 기호로 하는 조합이 가장 일관되게 해석됩니다.
공백은 두 칸이나 네 칸, 둘을 함께 쓰지 마세요. 공백으로 된 파일에 탭이 하나 있으면 존재하지 않는 단계가 생기고, 눈에도 보이지 않습니다. 가지가 한 단계 더 깊게 가져와졌다면 이것이 원인입니다.
한 줄에 아이디어 하나, 세 단어에서 다섯 단어. 줄이 길면 문단으로 가득 찬 맵이 되고, 이는 단계만 늘어난 문서일 뿐입니다. 개요를 읽기 좋은 맵으로 가져오게 해 주는 원칙은 맵을 쓸모 있게 만드는 원칙과 같습니다. 라벨은 아이디어를 가리킬 뿐, 서술하지 않습니다.
네 단계에서 멈추세요. 그보다 깊으면 방사형 배치에서 읽을 수 없고 곧바로 접어야 합니다. 개요가 정말 여섯 단계라면 세 단계 이하는 별도의 맵으로 나누고 서로 링크하는 편이 좋습니다.
AI로 맵 만들기
가장 효과가 큰 방법입니다. 맵이 아니라 개요를 요청하세요. 어떤 모델이든 마크다운은 잘 쓰지만, 열 수 있는 마인드맵 파일은 만들지 못합니다.
Produce a Markdown outline of <topic>. Use "#" for the centre, "##" for
top-level branches, and "-" bullets below that, indented two spaces per
level. Maximum four levels. Each line is three to five words, no
sentences, no punctuation at the end. No preamble and no closing text.
마지막 문장은 제 몫을 합니다. 모델은 출력을 "개요를 준비했습니다!" 같은 인사와 마무리 문단으로 감싸려는 경향이 있고, 둘 다 가져올 때 엉뚱한 노드가 되기 때문입니다.
가져오기 전에 세 가지를 확인하세요. 모델이 꾸준히 틀리는 부분입니다. 자식이어야 하는데 형제로 놓인 단계(나란히 있는 항목이 한 단계 높게 올라간 경우), 균형이 맞지 않는 트리(한 가지에 자식 열두 개, 나머지 셋에는 둘씩. 주제가 그런 모양이라기보다 모델의 지식이 바닥났다는 뜻인 경우가 많습니다), 그리고 지어낸 세부 내용입니다. 이는 다른 모든 용도에 해당하는 주의 사항과 같습니다.
마크다운과 OPML을 가져오며, 개요 보기는 양방향으로 동작합니다. 목록을 입력하면 맵이 보이고, 맵을 편집하면 개요가 따라옵니다. 마크다운, OPML, PDF, PNG, HTML, 일반 텍스트로 내보낼 수 있어 가져온 내용이 갇히지 않습니다.
기능반대 방향: 맵에서 개요로
맵을 마크다운으로 내보내면 앱 밖에서도 맵을 쓸 수 있게 되므로, 정기적으로 해 둘 만합니다.
- 맵이 문서 초안이 됩니다. 개요가 곧 섹션 구조이고, 순서도 이미 맞춰져 있습니다.
- 맵이 할 일 목록이 됩니다. 마크다운 체크박스는 대부분의 할 일 도구가 가져오는 형식입니다.
- 맵을 옮길 수 있게 됩니다. 마크다운 파일은 50년 뒤에도 읽을 수 있지만, 독자 형식의 맵 파일은 그 앱이 존재하는 동안만 읽을 수 있습니다.
마지막 점이 이 문제에 신경 써야 하는 진짜 이유입니다. 마크다운과 OPML로 내보낼 수 있는지가 그 마인드맵 앱이 생각하는 곳인지, 자료를 잃는 곳인지를 가릅니다. 본격적으로 만들기 전에 확인해 두세요.
개요의 모양이 맞지 않을 때
가져오면 맵이 엉망이 되고, 해결책이 그 앞 단계에 있는 경우가 두 가지 있습니다.
메모가 구조가 아니라 산문입니다. 문장으로 가득한 페이지를 가져오면 모든 노드가 문단인 맵이 됩니다. 먼저 추출하세요. 주장, 결정, 질문을 뽑아내고 그것을 개요로 만드세요. 실제 작업은 추출이고, 가져오기는 공짜입니다.
내용이 계층이 아니라 순서입니다. 절차, 연표, 레시피 같은 것입니다. 가져오기는 잘 되지만 어색해 보입니다. 방사형 배치가 핵심이던 순서를 없애 버리기 때문입니다. 고칠 곳은 개요가 아니라 배치입니다. 선형이나 타임라인 보기로 바꾸면 같은 트리가 제대로 읽힙니다.
교차 링크에 관하여
마크다운도 OPML도 두 가지 사이의 링크를 표현하지 못하고, 맵의 가치 상당 부분은 교차 링크에 있습니다. 그래서 가져오기로는 계층까지만 얻고, 연결은 나중에 직접 추가합니다.
이것은 피해 가야 할 한계가 아닙니다. 합리적인 역할 분담입니다. 계층은 기계적인 부분이므로 입력하면 됩니다. 교차 링크는 내용을 이해해야 그을 수 있는 부분이고, 직접 그어 보면 이해했는지 알게 됩니다.