Obsidian으로 AWS 자격증 취득하기 1편 - 폴더가 아니라 링크로 — 개발자가 Obsidian에서 처음 바꿔야 하는 건 사고방식입니다

들어가며 — 개발자가 노트 앱에서 처음 헷갈리는 것

코드를 다루는 사람은 폴더로 생각하는 습관이 몸에 배어 있습니다. 새 프로젝트를 시작하면 가장 먼저 디렉터리 구조부터 잡습니다. controller, service, repository로 나누고, 그 아래에 도메인별로 또 나눕니다. 무언가를 정리한다는 것은 곧 "어느 폴더에 넣을지 정하는 일"이고, 이 방식은 대체로 잘 작동합니다. 파일 하나는 한곳에 있어야 하고, 경로를 따라가면 반드시 찾을 수 있으니까요.

그래서 Obsidian 같은 노트 앱을 처음 열면, 우리는 똑같이 합니다. 폴더부터 만듭니다. AWS 자격증을 준비한다면 자연스럽게 SAA, DVA, SysOps 폴더를 만들고 그 안에 노트를 채워 넣으려 합니다. 그런데 며칠 지나지 않아 이상한 지점에 부딪힙니다. S3라는 서비스는 세 시험에 모두 나옵니다. 그러면 S3 노트는 어느 폴더에 넣어야 할까요. 세 폴더에 똑같이 세 번 만들어야 할까요. 아니면 한 곳에 두고 나머지에서는 어떻게든 찾아가야 할까요. 폴더로 분류하려는 순간, 한 노트가 여러 맥락에 동시에 속한다는 사실이 발목을 잡습니다.

이 글은 그 막히는 지점을 정리하는 글입니다. Obsidian의 기능을 하나하나 소개하기보다는, 노트 앱을 폴더 트리로만 쓰던 개발자가 Obsidian 앞에서 처음 넘어야 할 벽이 단축키나 플러그인이 아니라 사고의 방향이라는 점을 짚어 보려 합니다. 정리를 폴더가 아니라 노트 사이의 링크로 한다는 감각, 그것부터 잡지 못하면 뒤에 나오는 태그나 속성 같은 기능이 전부 겉돕니다. 그래서 이 시리즈의 출발점을 여기에 두었습니다.

기술적인 사실은 가능한 한 Obsidian 공식 문서에서 확인되는 범위 안에서만 적겠습니다. 정답을 제시하기보다는, 자격증 공부를 시작하면서 Vault를 어떻게 잡았고 그 과정에서 무엇을 확인했는지를 공유하는 정도로 읽어 주시면 좋겠습니다. 

 

Vault 전역 그래프 — 시험 노트와 Home이 큰 노드로 보이고 서비스 노트들이 그 사이를 잇는다

---

Vault는 내 디스크의 폴더입니다

Obsidian을 처음 켜면 가장 먼저 만나는 단어가 Vault입니다. 이름만 보면 무슨 특별한 데이터베이스나 클라우드 저장소처럼 들리지만, 공식 문서의 정의는 훨씬 담백합니다. Obsidian 도움말은 Vault를 두고 "a folder on your local file system where Obsidian stores your notes", 즉 Obsidian이 노트를 저장하는, 내 로컬 파일 시스템의 폴더라고 적고 있습니다. 데이터를 저장하는 방식을 설명하는 문서에서는 한 걸음 더 들어가, "Obsidian stores your notes as Markdown-formatted plain text files in a vault. A vault is a folder on your local file system, including any subfolders"라고 분명히 합니다. 노트는 마크다운 형식의 평문 텍스트 파일이고, Vault는 그 파일들이 든 폴더와 하위 폴더라는 뜻입니다.

이 정의가 개발자에게 주는 인상은 생각보다 큽니다. 노트가 특별한 바이너리 포맷이 아니라 그냥 .md 텍스트 파일이라는 것은, 내 노트를 Obsidian이 아닌 다른 도구로도 열 수 있다는 뜻이기 때문입니다. 공식 문서도 같은 점을 짚습니다. "notes are plain text files, you can use other text editors and file managers to edit and manage notes." 평문이니까 VS Code로 열어 고칠 수도 있고, 터미널에서 grep으로 뒤질 수도 있고, 파일 탐색기에서 그대로 옮기거나 백업할 수도 있습니다. 노트의 형식과 위치를 내가 완전히 통제한다는 감각은, 특정 서비스에 데이터를 맡겨 두던 경험과는 결이 다릅니다.

또 하나 눈에 띄는 점은 기본 동작이 로컬이라는 것입니다. Obsidian은 인터넷 연결 없이도 동작합니다. 외부 서비스와의 동기화는 선택 사항입니다. 공식 문서는 Obsidian Sync, Dropbox, iCloud, OneDrive, Git 같은 수단으로 동기화할 수 있다고 안내하지만, 이것들은 어디까지나 추가로 얹는 것이지 핵심 기능이 동기화에 의존하지는 않습니다. 핵심은 내 디스크에 평문으로 놓여 있고, 그걸 어디로 어떻게 옮길지는 내가 정한다는 데 있습니다.

여기서 개발자라면 한 가지가 곧장 떠오를 겁니다. 평문 파일이고 폴더 단위라면, git으로 버전 관리를 할 수 있지 않을까. 실제로 공식 문서가 동기화 수단의 하나로 Git을 언급하기도 합니다. 다만 이 부분은 조심해서 말해야 합니다. Obsidian이 git을 내장하고 있어서 켜는 즉시 커밋이 되는 것은 아닙니다. Vault가 평문 폴더라는 성질 덕분에 git 저장소로 만들 수 있는 것이지, 버전 관리 자체는 별도의 도구와 설정으로 직접 붙여야 합니다. "평문이라 git이 된다"는 가능성과 "Obsidian이 git을 해 준다"는 기능은 다른 이야기입니다. 이 차이를 흐리면 나중에 "왜 자동으로 커밋이 안 되지" 하고 헤매게 됩니다.

정리하면 Vault에 대해 처음 잡아 둘 사실은 세 가지입니다. 내 로컬 폴더라는 것, 노트가 평문 마크다운이라 다른 도구로도 다룰 수 있다는 것, 그래서 데이터를 내가 소유하고 통제한다는 것입니다. 이 출발점이 단단해야, 그 위에 폴더가 아닌 링크로 정리한다는 다음 이야기가 얹힙니다.

---

폴더 트리와 링크 그래프는 무엇이 다른가

파일 시스템의 폴더는 트리 구조입니다. 트리에서는 한 노드가 부모를 하나만 가집니다. 그래서 한 파일은 정확히 한 경로에 존재합니다. SAA/S3.md에 둔 파일은 SAA 폴더 아래에만 있고, 동시에 DVA 폴더 아래에 있을 수는 없습니다. 같은 내용을 두 곳에 두려면 파일을 복제하는 수밖에 없습니다. 폴더의 이 단순함은 분명한 장점이지만, 동시에 한계이기도 합니다. 현실의 지식은 깔끔한 트리로 떨어지지 않을 때가 많기 때문입니다.

AWS 자격증 공부가 정확히 그런 경우입니다. S3, EC2, IAM, VPC 같은 핵심 서비스는 솔루션스 아키텍트 시험에도, 개발자 시험에도, 시스템 운영 시험에도 모두 등장합니다. 세 시험은 같은 서비스를 다른 각도에서 볼 뿐입니다. 아키텍트 관점에서는 어떻게 설계할지를 묻고, 개발자 관점에서는 어떻게 코드로 다룰지를 묻고, 운영 관점에서는 어떻게 모니터링하고 장애에 대응할지를 묻습니다. 대상 서비스는 크게 겹치는데, 폴더로 시험을 나누면 이 겹치는 지식을 어디에 둘지가 매번 문제가 됩니다.

Obsidian이 권하는 방식은 폴더가 아니라 링크입니다. 링크로 노트를 이으면 구조가 트리가 아니라 그래프가 됩니다. 그래프에서는 한 노드가 여러 노드와 동시에 연결될 수 있습니다. S3 노트는 하나만 두되, 그 노트가 세 시험 노트와 모두 이어질 수 있다는 뜻입니다. 한 노트가 여러 맥락에 동시에 속하는 것, 이것이 폴더로는 표현하기 어렵고 링크로는 자연스러운 일입니다. 개발자에게 빗대자면, 폴더가 한 행이 한 위치에만 들어가는 단순한 분류라면, 링크는 여러 엔티티가 관계로 얽히는 그래프 모델에 가깝습니다. 우리가 데이터를 다룰 때 다대다 관계를 폴더가 아니라 연결로 풀듯이, 지식도 그렇게 연결로 풀 수 있습니다.

오해를 막기 위해 한 가지는 분명히 해 두겠습니다. 링크로 정리한다는 말이 폴더를 절대 쓰지 말라는 뜻은 아닙니다. Vault 자체가 폴더이고 하위 폴더를 둘 수 있다고 공식 문서도 적고 있습니다. 폴더는 여전히 쓸모가 있습니다. 다만 폴더에 모든 분류를 떠맡기지 말고, 분류의 무게 중심을 링크로 옮긴다는 균형이 핵심입니다. 폴더는 거칠게 큰 묶음만 잡고, 노트 사이의 실제 관계는 링크가 표현하게 둡니다.

---

첫 링크 — [[EC2]] 한 줄로 노트를 잇습니다

링크로 생각한다는 말이 추상적으로 들린다면, 문법은 의외로 단순합니다. Obsidian의 내부 링크, 이른바 위키링크는 노트 이름을 대괄호 두 개로 감싸는 것이 전부입니다. 공식 문서가 적어 둔 기본 문법은 [[Note name]]입니다. 확장자를 붙여 [[Note name.md]]로 쓸 수도 있고, 문서의 예시는 [[Three laws of motion]]처럼 보여 줍니다. EC2를 정리한 노트로 잇고 싶다면 본문 어디에든 [[EC2]]라고 적으면 됩니다. 그러면 그 자리가 EC2 노트로 가는 링크가 됩니다.

링크는 노트 전체만이 아니라 더 좁은 위치도 가리킬 수 있습니다. 공식 문서에 따르면 특정 제목으로 잇고 싶으면 [[Note name#Heading]]처럼 #로 제목을 지정하고, 특정 블록으로 잇고 싶으면 [[Note name#^block-id]]처럼 ^로 블록을 지정합니다. 자격증 공부에 대입하면 이렇게 쓸 수 있습니다. S3 노트 안에 "버전 관리", "수명 주기 정책", "스토리지 클래스" 같은 제목을 두고, 다른 노트에서 그중 한 대목만 정확히 가리키고 싶을 때 [[S3#스토리지 클래스]]로 잇는 식입니다. 노트를 통째로 보내는 대신, 지금 이야기하는 맥락에 딱 맞는 지점으로 독자를 데려갈 수 있습니다.

위키링크가 공부에 잘 맞는 또 다른 이유는 글을 쓰는 흐름을 끊지 않는다는 데 있습니다. 강의를 듣다가 EC2를 설명하는 대목에서 IAM 역할 이야기가 나왔다고 합시다. 지금 만들고 있는 노트는 EC2이고, IAM은 아직 따로 정리하지 않았습니다. 이럴 때 EC2 노트 안에 [[IAM]]이라고 한 줄 적어 두면, 지금은 EC2에 집중하면서도 "여기서 IAM과 이어진다"는 연결만 미리 걸어 둘 수 있습니다. 나중에 IAM을 본격적으로 정리할 때, 이미 걸어 둔 연결들이 거꾸로 "어디서 나를 참조하고 있었는지"를 보여 주는 단서가 됩니다. 링크를 먼저 걸고 노트를 나중에 채우는 이 순서는, 공부하면서 떠오른 연결을 그 자리에서 잡아 두기에 잘 맞습니다. (다만 클릭했을 때 노트가 자동으로 만들어지는지 같은 세부 동작은 버전과 설정에 따라 다를 수 있으니, 이 글에서는 "연결을 미리 걸어 둘 수 있다"는 정도로만 적어 두겠습니다.)

여기서 한 가지 감각이 생깁니다. 폴더는 노트를 "어디에 둘지" 정하는 일이고, 링크는 노트를 "무엇과 이을지" 정하는 일입니다. 공부를 하다 보면 후자가 훨씬 자주, 자연스럽게 떠오릅니다. "이건 저것과 관련 있다"는 생각이 "이건 이 폴더에 속한다"는 생각보다 먼저 오기 때문입니다. 링크는 그 떠오른 관계를 그대로 받아 적게 해 줍니다.

---

자격증 공부 Vault 첫 세팅 — 폴더는 최소로

그럼 실제로 첫 Vault를 어떻게 잡으면 좋을지로 넘어가겠습니다. 결론부터 적으면, 처음에는 폴더를 최소로 두고 시작하는 편이 낫습니다. 구체적으로는 서비스 노트를 둘 곳 하나, 강의 캡처나 이미지 같은 첨부 파일을 둘 곳 하나 정도면 충분합니다. 예를 들어 노트는 Vault 루트나 notes 한 곳에 모으고, 첨부는 attachments 한 곳에 모으는 식입니다. 첨부를 한곳으로 모으는 건 실용적인 이유가 있습니다. 공식 문서가 밝히듯 Obsidian은 마크다운만이 아니라 이미지(.png, .jpg, .webp 등), PDF(.pdf), 오디오, 비디오 같은 여러 형식을 Vault 안에 담을 수 있습니다. 강의 슬라이드 캡처나 PDF 자료가 노트 폴더에 섞여 들면 금세 지저분해지므로, 첨부는 한 폴더로 몰아 두는 편이 깔끔합니다.

눈여겨볼 대목은, 이 첫 세팅에서 시험별 폴더를 만들지 않는다는 점입니다. SAA, DVA, SysOps 폴더를 만들고 싶은 충동이 가장 클 때가 바로 시작하는 시점인데, 여기서 그 충동을 한 번 누릅니다. 이유는 앞에서 본 그대로입니다. 세 시험이 같은 서비스를 공유하는데 폴더로 시험을 나누면, 공유되는 서비스 노트를 어디에 둘지가 영원히 풀리지 않는 숙제로 남기 때문입니다. 서비스 노트는 시험과 무관하게 하나만 두고, "이 노트가 어느 시험에 걸리는지"는 폴더가 아닌 다른 수단으로 표시하는 것이 더 잘 맞습니다. 그 다른 수단이 무엇인지는 이 글의 범위를 넘어가므로, 다음 편으로 넘기겠습니다.

처음부터 완벽한 구조를 설계하려 들지 않는 것도 중요합니다. 폴더 구조는 코드의 패키지 구조처럼 한 번 정하면 바꾸기 어려운 것이 아닙니다. 평문 파일이고 내 폴더이니, 나중에 노트가 쌓이고 나서 패턴이 보일 때 옮기고 묶으면 됩니다. 오히려 처음부터 빈 폴더를 잔뜩 만들어 두면, 그 폴더들을 채워야 한다는 압박만 생기고 정작 링크로 잇는 습관은 안 생깁니다. 시작은 노트 한두 개를 쓰고 그 사이에 링크 하나를 거는 것으로 충분합니다.

이 첫 세팅을 한 문장으로 줄이면 이렇습니다. 폴더는 거친 묶음으로만 최소한 두고, 시험과 서비스의 관계는 링크와 표시로 풀 자리를 비워 둔다. 비워 둔 그 자리를 무엇으로 채우는지가 이 시리즈가 앞으로 다룰 내용입니다.

---

마무리 — 문법보다 먼저 넘어야 할 건 "링크로 생각하기"

이 글에서 정리한 내용을 한 줄로 줄이면, "Obsidian을 처음 잡을 때 진짜 벽은 위키링크 문법이 아니라, 지식을 폴더에 넣는 사고에서 링크로 잇는 사고로 넘어가는 전환"입니다. Vault가 내 로컬 폴더이고 노트가 평문 마크다운이라는 사실, 폴더 트리와 링크 그래프가 무엇이 다른지, [[ ]] 한 줄로 노트를 잇는 법, 그리고 시험별 폴더 대신 최소한의 폴더로 시작하는 첫 세팅까지, 모두 그 전환을 위한 발판이었습니다. 

개인적으로 이 전환을 정리하면서 남은 인상은, Obsidian이 강제하는 것이 사실은 새로운 도구 사용법이라기보다 익숙한 개발 감각을 노트로 옮겨 놓은 것에 가깝다는 점이었습니다. 평문 파일을 내 폴더에 두고 데이터를 직접 소유한다는 것은, 데이터를 특정 서비스에 묶어 두지 않으려는 습관과 같은 자리에 있습니다. 한 노트를 여러 맥락에 링크로 잇는다는 것은, 다대다 관계를 복제가 아니라 연결로 푸는 데이터 모델링 감각과 다르지 않습니다. 폴더로 모든 걸 분류하려다 막혔던 지점이, 사실은 트리로 그래프를 표현하려다 막힌 것이었다는 걸 알고 나니, 도구가 한결 단순하게 보였습니다.

한 가지 더 남는 것은, 링크로 정리한다는 것이 "폴더를 안 만들어도 되는 편함"만은 아니라는 점입니다. 분류를 폴더에 맡기는 대신, 우리는 "이 노트가 무엇과 이어지는가"를 더 또렷하게 알고 있어야 합니다. 연결이 흐릿하면 링크는 오히려 어수선해집니다. 그래서 다음 편에서는, 세 시험이 공유하는 서비스 노트 하나에 시험별 관점을 어떻게 얹는지를 다루려 합니다. 이 글에서는 "서비스 노트는 하나만 두고 시험은 다른 수단으로 표시한다"고만 적어 두었는데, 그 다른 수단이 무엇이고 어떻게 쓰는지가 다음 글의 출발점이 됩니다. 비슷한 자리에서 폴더 강박과 씨름하는 분들에게 이 글이 작은 참고가 되기를 바라며 마무리합니다.

 

---

Github repository link

• Obsidian Vault 공유 링크 —  https://github.com/thswlsqls/AWS-Certifications

 

---

참고한 공식 문서

• Obsidian Help — Vault — https://help.obsidian.md/vault
• Obsidian Help — How Obsidian stores data — https://help.obsidian.md/data-storage
• Obsidian Help — Internal links — https://help.obsidian.md/links
• Obsidian Help — Accepted file formats — https://help.obsidian.md/file-formats
• Obsidian 공식 홈페이지 — https://obsidian.md/