MOC(Map of Content)는 한 주제에 관련된 노트들의 링크를 모아두고, 그 사이의 관계를 정리하는 노트다. 2020년 무렵 옵시디언 커뮤니티에서 Nick Milo가 이름 붙이고 퍼뜨렸다.
MOC 개념
MOC는 자기 내용보다 다른 노트로 가는 링크가 중심인 노트다.
예를 들어 「습관」에 관한 노트가 열 개쯤 흩어져 있다면, 그 열 개의 링크를 한 문서에 모아두고 어떤 순서로 읽으면 되는지, 서로 어떻게 이어지는지를 적어둔 것이 습관 MOC다.
폴더와 다른 점은 한 노트가 여러 MOC에 동시에 들어갈 수 있다는 것이다. 「아침 루틴」 노트는 습관 MOC에도, 건강 MOC에도 링크될 수 있다. Nick Milo는 MOC를 두고 "관련 노트를 모아두고, 그걸 들여다보며 생각하는 노트"라고 설명한다. 링크 목록으로 끝나는 게 아니라, 모아놓고 보면서 노트 사이의 관계나 빠진 부분을 알아차리는 데 쓰인다는 뜻이다. 그래서 그는 MOC도 결국 하나의 노트이며, 다른 노트들처럼 계속 자란다고 본다.
MOC가 폴더나 태그를 없애자는 건 아니다. Nick Milo는 노트를 서로 잇는 방법을 일곱 가지로 정리한다. 노트 사이의 직접 링크, 폴더, 태그, 여러 태그의 조합 검색, 저장해둔 검색, 이름순·날짜순 같은 배치, 그리고 MOC나 Home note 같은 상위 노트다. 그의 결론은 한 가지 방법만 고집하지 말라는 것이다. 폴더는 한 노트가 한 곳에만 속하므로 경계가 분명한 곳, 예를 들어 진행 중인 프로젝트, 임시 inbox, 민감한 정보에 적합하다. 태그는 여러 개를 붙일 수 있지만 태그가 많아지면 어떤 태그가 무슨 뜻인지 따로 기억해야 한다. MOC는 링크와 설명이 문서 안에 그대로 보이므로 따로 외울 것이 없다.
근원
MOC라는 이름은 옵시디언 커뮤니티에서 나왔지만, 비슷한 역할은 그 전부터 있었다. 루만의 지텔카스텐(Zettelkasten)에는 두 종류의 상위 노트가 있다.
hub note는 어떤 생각의 흐름이 어디에 있는지를 가리키는 노트다. 특정 주제를 다시 찾아갈 때 출발점이 된다. structure note는 그렇게 찾은 노트들을 하나의 논리 순서로 다시 배치하고, 부족한 부분을 채워가며 생각을 발전시키는 노트다. 앞의 것은 찾는 용도, 뒤의 것은 만드는 용도에 가깝다.
MOC는 이 둘의 역할을 함께 가진다. 다만 structure note와 완전히 같은 것은 아니다. MOC는 보통 큰 주제 단위에서 쓰이는 반면, structure note는 몇 개 안 되는 작은 노트 묶음에도 쓰인다. 2020년 옵시디언 포럼의 「A case for MOCs」 토론에서 이 개념이 "특정 주제의 노트를 묶는 중앙 색인 노드"로 정리됐고, 이후 Nick Milo의 LYT(Linking Your Thinking)가 체계화했다.
MOC 사용 목적
LYT는 MOC가 하는 일을 세 가지로 나눈다.
첫째는 모으기다. 여기저기 흩어진 관련 노트를 한 문서에 링크로 불러온다.
둘째는 발전시키기. 모아둔 링크를 묶거나 순서를 바꾸다 보면 노트끼리의 관계가 보이고, 아직 쓰지 않은 노트가 무엇인지도 드러난다. 새 생각은 주로 이 단계에서 나온다.
셋째는 길찾기다. 몇 달 뒤 같은 주제로 돌아왔을 때, 어디서부터 읽어야 할지 알려주는 입구 역할을 한다.
셋 중 원래 개념에서 가장 강조하는 것은 두 번째다. 단순히 찾기 쉽게 만드는 색인이라면 검색으로도 충분하다. MOC가 따로 필요한 이유는 모아놓고 들여다보는 과정 자체가 생각을 정리하는 작업이기 때문이다.
만드는 시점
MOC는 미리 만들어두는 문서가 아니다. LYT는 mental squeeze point, 즉 한 주제의 노트가 쌓여서 머릿속으로 다 붙잡고 있기 버거워지는 순간을 만드는 신호로 삼는다.
개수가 정해져 있는 건 아니다. LYT는 "흩어진 노트 20개"를 예로 들고, 어떤 사용자는 '5개 이상이면서 복잡해질 때'를 기준으로 쓴다. 필자의 경우 MOC의 개념을 알기 전에 이미 스스로의 규칙을 10개로 잡았다. 이처럼 숫자가 다른 이유는 개인이 느끼는 부담감의 기준이 사람마다 다르기 때문이다. LYT FAQ는 아예 "맵을 하나도 만들지 않아도 된다"고 적어두었다. 스스로 필요를 느끼기 전에 만든 MOC는 한 두줄만 담긴 빈 목록으로 남기 쉽다.
물론 만든 뒤에는 단계적으로 키워나가야 한다. 처음에는 관련 노트의 링크를 나열하기만 한다. 다음 단계에서는 링크를 묶음으로 나누고, 각 링크 옆에 이 노트가 왜 여기 있는지, 무엇과 연결되는지를 짧게 적는다. MOC가 여러 개 생기면 또다시 그 MOC들을 묶는 상위 MOC를 만든다.
만약 MOC 안에서 한 묶음이 너무 커지면, 그 묶음을 떼어내 별도의 MOC로 독립시킨다. 예를 들어, 습관 MOC 안의 「아침 루틴」 항목이 스무 개로 불어나면 아침 루틴용 MOC를 따로 만드는 식이다. 반대로 더 이상 쓰지 않는 MOC는 지우거나 합쳐도 된다. MOC는 한 번 정한 구조를 지킬 필요 없이, 지금 필요한 만큼만 유지하는 문서다.
목차(TOC)와의 차이점
MOC와 목차(TOC)는 둘 다 링크 목록처럼 보이지만 역할이 다르다.
목차는 특정 결과물의 순서를 고정한 것이다. 책이나 보고서처럼 끝이 정해진 작업에 쓰이고, 한번 정하면 잘 바뀌지 않는다.
반대로, MOC는 아직 정리되지 않은 주제를 탐색하는 공간이라 계속 순서가 바뀐다.
둘은 함께 쓰인다. MOC에서 노트를 이리저리 옮겨보며 생각을 정리하다가, 글이나 프로젝트의 방향이 정해지면 그 부분이 자연스럽게 목차로 굳어질 것이다.
LYT의 확장 (Home note, ACE)
LYT는 이후 MOC를 볼트 전체 구조로 확장했다. 가장 위에 있는 상위 MOC를 Home note라고 부르고, 거기서 주요 MOC들로 내려가게 한다.
폴더는 세 개로 나눈다. 지식을 담는 Atlas, 일지와 회고처럼 날짜가 기준인 Calendar, 프로젝트처럼 실행이 중심인 Efforts다. 앞글자를 따서 ACE라고 부른다. MOC는 Atlas에 두지만 Calendar나 Efforts의 노트와도 링크로 이어진다.
노트의 frontmatter에 up: 필드를 두고 그 노트가 속한 상위 MOC를 적는 방식도 LYT 사용자들 사이에서 흔히 쓰인다.
사용 예시
같은 MOC라도 쓰는 사람에 따라 모습이 꽤 다르다. 각자 참고할만한 것이 있는 지 살펴보길 바란다.
필자의 경우 MOC를 알기 전에 뭣모르고 스스로 '허브 노트'라 명명하여 사용하고 있으며, 자세한 방법은 [옵시디언 세컨드브레인 만들기 (7)] 에서 소개하고자 한다.
Aidan Helfant: MOC를 만드는 과정을 Dump → Lump → Jump 세 단계로 설명한다. 관련 노트를 일단 전부 끌어오고(Dump), 비슷한 것끼리 묶은 뒤(Lump), 시간을 두고 다시 보면서 새로운 연결을 찾는다(Jump).
Jamie Todd Rubin: MOC를 특정 대상 하나를 정리하는 데 쓴다. SF 단편 선집을 읽으면서 단편마다 노트를 만들고, 그 노트들을 선집 MOC 하나에 모았다. 가족의 각종 서류 정보를 찾아볼 수 있게 관련 문서 링크를 모아둔 MOC도 있다.
Steph Ango(Obsidian CEO): MOC라는 이름을 쓰지 않지만 같은 역할을 속성으로 구현한다. 노트마다 categories 속성을 붙이고, Categories 폴더에 카테고리별 개요 노트(책, 영화, 팟캐스트 등)를 둔다. 개요 노트는 해당 카테고리 속성을 가진 노트들을 Bases로 모아 보여준다. 폴더는 최소한만 쓰고, 아직 없는 노트로 가는 링크도 적극적으로 걸어둔다.
Sam Hogarth: 비슷하게 자동화했다. 각 노트의 maps 속성에 소속 MOC를 적어두면, MOC 쪽의 Bases 파일이 그 MOC를 가리키는 노트를 찾아 목록을 만든다. 사람은 노트에 소속만 표시하고, 목록 정리는 자동으로 맡기는 방식이다.
seqis/ObsidianMOC 저장소: 규칙을 가장 엄격하게 정한 사례다. 파일명 끝에 MOC를 붙이고(Philosophy MOC), MOC 안을 제목 계층으로 나눈 뒤 각 계층에 Dataview 쿼리를 둔다. 각 노트 상단에는 MapOfContent: [[Philosophy MOC#Stoicism]]처럼 소속을 적는다.
Obsidian Rocks의 저자: 분류하지 못한 노트를 임시로 모아두는 「Fleeting MOC」를 쓴다. 새 노트는 일단 여기에 링크되고, 나중에 알맞은 MOC로 옮겨진다.
정리하면 사용 방식은 두 방향으로 나뉜다. 링크와 설명을 손으로 직접 쓰는 쪽(Helfant, Rubin)과, 노트에 소속을 표시하고 목록은 자동으로 만드는 쪽(Ango, Hogarth, seqis)이다. 원래 개념에서 강조한 "모아놓고 들여다보며 생각하기"는 앞쪽에 가깝고, 뒤쪽은 관리 부담을 줄이는 데 무게를 둔다. 나는 후자에 가까우면서도 전자를 조금 반영한 느낌인 것 같다. (AI 자동화 짱!)
단점
가장 먼저 꼽히는 단점은 손이 많이 간다는 것이다. 태그는 노트에 한 단어만 붙이면 되지만, MOC는 새 노트가 생길 때마다 해당 MOC를 열어 링크를 추가하고, 묶음이 커지면 다시 정리해야 한다. MOC가 많아질수록 관리 대상도 늘어난다.
LYT 에서는 MOC가 (태그나 폴더를 대체하는 게 아니라) 필요한 곳에만 덧붙이는 도구라고 말한다. 특히 맥락 설명이 중요한 큰 프로젝트나 여러 분야를 오가는 공부에서는 얻는 것이 크다고 본다. 앞의 사용 예시에서 속성과 Bases로 목록을 자동화한 사람들이 있는 것도 이 부담 때문이다.
두 번째는 백링크와 겹친다는 지적이다. 옵시디언은 어떤 노트를 가리키는 노트들을 백링크 패널에 자동으로 보여주므로, 목록을 따로 만들 필요가 없어 보인다. 다만 백링크 목록은 순서가 없고 왜 연결됐는지 설명도 없다. MOC는 순서를 정하고, 묶고, 설명을 붙일 수 있다는 점에서 역할이 다르다는 것이 반론에 대한 답이다.
Ideaverse Lite
개요
Ideaverse Lite는 LYT가 무료로 배포하는 예시 볼트다. 예전에 LYT Kit이라고 부르던 것이 이름을 바꾼 것으로, 내려받아 옵시디언에서 열면 300개가 넘는 노트가 1,000번 넘게 서로 링크된 상태로 들어 있다. 이메일 강의와 사용법 영상이 함께 제공된다. 유료판인 Ideaverse Pro는 같은 틀에 더 많은 템플릿과 강의를 얹은 제품이다.
Lite는 설명서라기보다 완성된 샘플 볼트다. 앞에서 정리한 MOC, Home note, ACE 폴더가 실제로 어떻게 맞물리는지 직접 열어보며 확인하는 용도이고, 제작자도 그대로 쓰기보다 들여다보고 필요한 부분을 골라 쓰라고 안내한다.
구성
폴더는 ACE 세 개에 보조 폴더 하나를 더한 형태다. 각 폴더는 질문 하나로 구분된다.
Atlas는 "내가 무엇을 알고 있나"에 답하는 곳이다. 한 가지 생각을 담은 개념 노트(Ideaverse에서는 dot이라고 부른다), 그 노트들을 묶는 MOC, 책·영상·웹 자료를 정리한 출처 노트가 들어간다.
Calendar는 "이것이 언제 일어났나"에 답한다. 일일 노트와 기록(log)처럼 날짜가 기준인 노트가 연·월·일 순으로 쌓인다.
Efforts는 "내가 지금 무엇을 하고 있나"에 답한다. 프로젝트와 계속 챙기는 일이 들어가는데, 이를 진행 강도로 나눈다 — 지금 가장 활발한 On, 꾸준히 이어가는 Ongoing, 가끔 들여다보는 Simmering, 당분간 쉬는 Sleeping. 우선순위가 바뀌면 문서를 이 칸 사이에서 옮긴다. 보조 폴더에는 템플릿과 첨부파일처럼 시스템을 받치는 파일을 둔다.
가장 위에는 Home note가 있어 세 폴더와 주요 MOC로 내려가는 입구가 된다. 노트끼리의 관계는 frontmatter의 up(상위 노트), related(관련 노트) 속성으로 표시한다.
노트를 다루는 흐름은 ARC로 요약된다. 새 생각을 붙잡고(Add), 기존 노트와 잇고(Relate), 글이나 결과물로 내보낸다(Communicate). MOC는 이 중 Relate 단계의 도구이고, 관련 노트가 구조 없이 여럿 쌓였을 때(개수는 본인 마음) 만든다.
흡수할 만한 개념과 구조
Ideaverse는 폴더 구조 자체가 PARA와 다르다. 볼트를 통째로 ACE로 바꾸는 건 이미 자리 잡은 PARA 전체를 다시 짜는 일이라 굳이 불필요한 작업이다. 대신 설치하지 않고 쓸만한 개념만 가져올 수 있는 것을 후보로 정리해본다.
아래 예시는 모두 필자의 PARA 구조를 바탕으로 작성하였다. [옵시디언 세컨드브레인 만들기 (1)편 중 폴더 체계 참고]
폴더를 나누는 질문
「무엇을 아는가 / 언제 일어났나 / 무엇을 하는가」라는 세 질문은 폴더 이름과 상관없이 쓸 수 있다. 이 볼트에 대면 각각 [400_Resources, 301_Daily, 100_Projects] 폴더들에 대응한다. Inbox 문서를 어디로 보낼지 망설여질 때의 판단 질문으로 쓸 수 있다.
Efforts의 강도 구분
프로젝트를 "진행 중/완료" 두 상태로만 보지 않고, On·Ongoing·Simmering·Sleeping으로 나누는 방식이다. 100_Projects 안에도 성격이 다른 프로젝트가 섞여 있다 — 기한이 있는 일, 계속 굴러가는 일, 임시로 멈춘 일. 폴더는 그대로 두고 허브 문서나 속성에 이러한 강도만 표시하는 식으로 반영해볼 수 있겠다.
up·related 속성
필자의 볼트는 본문 첫 줄에 분류 링크(ex. [[Work]] [[Work › 회의]])를 거는 방식으로 같은 일을 하고 있었다. 이를 frontmatter 속성으로 옮기면 Bases나 Dataview로 목록을 자동으로 뽑기 쉬워지지만, 대신 본문에서 링크가 보이지 않게 된다. 방식을 바꿀지는 고민해 보아야겠다.
Home note
사람이 볼트를 열었을 때 처음 보는 입구 문서. 지금은 폴더 목록과 _Project·_Resource 같은 PARA의 허브가 그 역할을 나눠 맡고 있다.
ARC 흐름
Add → Relate → Communicate는 내 볼트의 [000_Inbox] → 분류·링크 → draft·발행 흐름과 거의 같은 순서다. 새로 들일 것은 없지만, 각 단계의 이름을 짧게 부를 수 있다는 점에서 글이나 지침에서 설명할 때 참고할 만 할 수도 있겠다.
보조 폴더
템플릿·첨부파일을 한곳에 두는 방식은 [900_Obsidian]이 이미 같은 역할을 하고 있어 따로 가져올 것이 없다.
참고 자료
- MOCs Overview — LYT Kit — 정의, mental squeeze point
- LYT FAQ — LYT Kit — 세 가지 목적, MOC와 TOC의 차이
- In what ways can we form useful relationships between notes? — Nick Milo — 노트를 잇는 일곱 가지 방법
- A case for MOCs — Obsidian Forum — 커뮤니티 기원, 반론과 답
- The Difference Between Hub Notes and Structure Notes Explained — Bob Doto — 지텔카스텐의 두 상위 노트
- Structure Notes — Nicole van der Hoeven — structure note와 MOC의 차이
- Obsidian PKM Guide: LYT Note-Taking System — WenHao Yu — ACE 구조, up: 필드
- 5 Simple Levels To Supercharging Your Learning With MOCs — Aidan Helfant — Dump·Lump·Jump, Home note
- Practically Paperless with Obsidian, Episode 4 — Jamie Todd Rubin — 선집 MOC, 서류 정보 MOC
- How I use Obsidian — Steph Ango — categories 속성과 개요 노트
- Maps of Content with Obsidian Bases — Sam Hogarth — maps 속성과 자동 목록
- seqis/ObsidianMOC — 엄격한 명명·계층 규칙
- Maps of Content: Effortless organization for notes — Obsidian Rocks — Fleeting MOC
- Ideaverse for Obsidian — Product Hunt — 무료 배포, 300+ 노트 구성
- Ideaverse for Obsidian: Vault Setup & Guide — obsidianmate — Home·Atlas·Calendar·Efforts 역할
- The Ideaverse Methodology Skill — agent-skills.md — 폴더별 질문, up·related, ARC
- Rethinking work: "efforts" matter more than projects — Hannah Swain Løvik — Efforts 강도 구분
'Life Contents > Workflow' 카테고리의 다른 글
| 옵시디언 세컨드브레인 만들기 (6) — 운영 지침 자동화 (0) | 2026.09.22 |
|---|---|
| 옵시디언 세컨드브레인 만들기 (5) — CLAUDE.md 설계 (0) | 2026.09.18 |
| 옵시디언 세컨드브레인 만들기 (4) — 태그 최소화, 허브 문서 만들기 (0) | 2026.09.18 |
| 옵시디언 세컨드브레인 만들기 (3) — AI 연동 (Claude, Gemini, MCP) (0) | 2026.09.18 |
| 옵시디언 세컨드브레인 만들기 (2) — Ticktick과 노션에서 자료 옮겨오기 (0) | 2026.09.18 |