티스토리 뷰
Obsidian으로 AWS 자격증 취득하기 4편 - 느낌표 하나의 차이 — 강의 슬라이드 PDF를 내 정리 노트 안에 펼쳐 두기
ebson 2026. 6. 12. 10:06들어가며 — 강의 따로, 내 노트 따로 놀 때
자격증 공부를 강의로 하면, 자료가 두 갈래로 흩어지기 쉽습니다. 한쪽에는 강의 슬라이드 PDF가 있습니다. 강사가 짜 둔 순서대로, 처음부터 끝까지 선형으로 흐르는 자료입니다. 다른 한쪽에는 내가 직접 쓴 정리 노트가 있습니다. 앞 글들에서 잡은 대로, 서비스별로 한 노트씩 두고 시험별 관점과 도메인 속성을 얹어 둔 노트들입니다. 문제는 이 둘이 자꾸 따로 논다는 데 있습니다. 강의를 듣다가 "이건 내 S3 노트에 적어 둬야지" 싶은 대목이 나와도, 슬라이드는 PDF 뷰어에 떠 있고 내 노트는 Obsidian에 떠 있어서, 둘을 오가며 베껴 적게 됩니다. 그러다 보면 강의의 어느 페이지가 내 노트의 어느 대목과 이어지는지가 금세 흐려집니다.
강의는 입력이고 내 노트는 정리입니다. 이 둘이 끊겨 있으면, 나중에 복습할 때 "이 내용을 강의에서 어떻게 설명했더라" 하고 다시 PDF를 처음부터 뒤지게 됩니다. 입력과 정리가 한자리에 있으면 그럴 일이 줄어듭니다. 내 정리 노트를 읽다가 근거가 된 강의 페이지를 바로 그 자리에서 펼쳐 볼 수 있다면, 두 자료를 오가는 마찰이 사라집니다.
이 글은 그 잇는 방법을 정리하는 글입니다. 내가 보유한 강의 슬라이드 PDF를 Vault에 넣고, 내 정리 노트 안에서 특정 페이지를 바로 띄우는 워크플로를 다룹니다. 다만 시작하기 전에 한 가지는 분명히 해 두겠습니다. 이건 어디까지나 내 Vault 안에서의 개인 학습 활용이고, 그 PDF를 공개된 곳에 올리는 것과는 전혀 다른 이야기입니다. 그 경계는 글 뒤쪽에서 따로 짚겠습니다. 기술적인 사실은 Obsidian 공식 문서에서 확인되는 범위 안에서만 적겠습니다.
Obsidian의 첨부 — 어떤 형식을 받고 어디에 저장되나
먼저 Obsidian이 PDF를 다룰 수 있는지부터 확인해야 합니다. 공식 문서의 허용 파일 형식 목록에는 마크다운(.md)뿐 아니라 이미지, 오디오, 비디오와 함께 PDF(.pdf)가 들어 있습니다. 그리고 문서는 한 문장으로 분명히 합니다. "Many file types — including images, audio, video, and PDFs — can be embedded directly into your notes." 이미지·오디오·비디오·PDF 같은 여러 형식을 노트 안에 직접 끼워 넣을 수 있다는 뜻입니다. PDF가 단순히 Vault에 보관만 되는 게 아니라 노트 본문에 펼쳐진다는 점이 핵심입니다.
이런 파일들을 Obsidian은 첨부(attachment)라고 부릅니다. 공식 문서는 첨부를 두고 "Attachments are regular files that you can access using your file system"라고 설명합니다. 첨부가 무슨 특별한 객체가 아니라, 파일 시스템에서 그대로 접근할 수 있는 평범한 파일이라는 것입니다. 이 설명은 첫 글에서 본 Obsidian의 성질과 그대로 이어집니다. 노트가 평문 마크다운 파일이듯, 첨부도 내 폴더에 놓인 그냥 파일입니다. PDF를 Vault에 넣는다는 것은 어떤 데이터베이스에 업로드하는 게 아니라, 내 디스크의 폴더에 파일 하나를 두는 일입니다.
저장 위치도 짚어 둘 만합니다. 공식 문서에 따르면 기본값은 "By default, attachments are added to the root of your vault", 즉 첨부가 Vault 루트에 들어갑니다. 그런데 이 위치는 바꿀 수 있습니다. 설정의 Files & Links에서 새 첨부의 기본 위치를 네 가지 중에서 고를 수 있다고 문서는 안내합니다. Vault 루트에 두는 방식, 지정한 폴더 한 곳에 모으는 방식, 지금 보고 있는 노트와 같은 폴더에 두는 방식, 그리고 그 노트 옆 하위 폴더에 두는 방식입니다. 자격증 공부처럼 PDF 자료가 여러 개 쌓이는 경우라면, 지정한 폴더 한 곳으로 모으는 방식이 깔끔합니다. 앞 글에서 첨부를 둘 폴더 하나를 비워 두자고 했던 것이 여기서 쓰입니다. 강의 PDF가 서비스 노트들 사이에 섞여 들지 않도록, 첨부는 한곳으로 몰아 둡니다.
PDF를 Vault에 넣고 페이지로 임베드하기
PDF를 Vault에 넣었다면, 이제 그걸 노트 안에 펼쳐 넣을 차례입니다. 여기서 첫 글의 위키링크와 한 글자 차이가 나는 문법이 등장합니다. 노트를 가리키기만 할 때는 대괄호 두 개로 [[노트 이름]]이라고 적었습니다. 그 자리에 무언가를 펼쳐 넣고 싶을 때는 앞에 느낌표를 하나 붙입니다. 공식 문서가 보여 주는 임베드의 기본 형태는 ![[Internal links]]처럼 느낌표로 시작합니다. 링크가 "저기로 가는 문"이라면, 임베드는 "그 내용을 여기에 펼쳐 놓기"입니다. 이 느낌표 하나의 차이가 강의 자료를 노트에 끌어오는 출발점입니다.
PDF를 통째로 펼치는 문법은 단순합니다. 공식 문서의 예시 그대로, ![[Document.pdf]]라고 적으면 그 PDF가 노트 안에 펼쳐집니다. 그런데 강의 슬라이드는 보통 수백 페이지에 이르기 때문에, 통째로 펼치는 것은 실용적이지 않습니다. 필요한 것은 특정 페이지 하나입니다. 공식 문서는 이를 위한 문법을 분명히 적어 두었습니다. "You can also open a specific page in the PDF by adding #page=N to the link destination, where N is the number of the page", 즉 링크 뒤에 #page=N을 붙이면 N번 페이지를 열 수 있고, 예시는 ![[Document.pdf#page=3]]입니다. 강의 슬라이드의 12쪽을 띄우고 싶다면 ![[슬라이드.pdf#page=12]]라고 적으면 됩니다.
높이를 조절하는 옵션도 공식 문서에 나와 있습니다. ![[Document.pdf#height=400]]처럼 #height 값을 주면 임베드되는 영역의 높이를 정할 수 있습니다. 이미지의 경우에는 크기를 다르게 주는 문법이 따로 있어서, 문서의 예시 ![[Engelbart.jpg|100x145]]처럼 세로줄 뒤에 너비와 높이를 적습니다. 여기서 한 가지 선을 분명히 해 두겠습니다. 이 글에서 적는 임베드 옵션은 모두 공식 문서에서 확인한 것들뿐입니다. PDF에 주석을 달거나 형광펜으로 칠하는 것 같은 기능은 공식 임베드 문법만으로 되는 일인지 이 글에서 단정하지 않겠습니다. 그런 확장은 플러그인의 영역일 수 있고, 그건 해당 문서를 따로 확인해야 합니다. 이 시리즈에서는 복습·암기와 관련된 그 이야기를 다음 글로 미뤄 두었습니다.
강의 페이지와 내 서비스 노트를 잇기
문법을 알았으니, 이제 이걸 공부 흐름에 어떻게 녹이는지로 넘어가겠습니다. 핵심은 임베드를 "노트 맨 아래에 PDF를 통째로 붙이는 일"로 쓰지 않는 데 있습니다. 그렇게 쓰면 강의를 그냥 PDF 뷰어로 보는 것과 다를 게 없습니다. 임베드의 진짜 쓸모는, 내 정리 노트의 특정 맥락에 강의의 특정 페이지를 짝지어 두는 데서 나옵니다.
앞 글들에서 잡은 구조를 떠올려 보겠습니다. 서비스마다 노트를 하나 두고, 그 안에 설계·개발·운영 같은 시험별 관점을 절로 나눠 두었습니다. 예를 들어 S3 노트 안에 "운영 관점" 절이 있다고 합시다. 강의에서 S3의 수명 주기 정책을 운영 측면에서 설명하는 페이지가 12쪽이었다면, 그 "운영 관점" 절 안에 ![[슬라이드.pdf#page=12]]를 적어 둡니다. 그러면 내가 쓴 정리 바로 옆에 강의의 해당 페이지가 펼쳐집니다. 내 말로 요약한 내용과, 그 근거가 된 강의 화면이 한자리에 놓이는 것입니다. 나중에 이 노트를 다시 펼치면, 정리와 출처가 같은 화면에 함께 보입니다. 강의를 처음부터 다시 뒤질 필요가 없습니다.

이 방식이 앞 글에서 만든 도메인 진도표와도 맞물립니다. 노트마다 시험·도메인·진도 상태를 속성으로 박아 두면, 어느 도메인이 아직 비었는지 한눈에 보입니다. 비어 있는 노트를 채울 때, 그 자리에 해당 강의 페이지를 임베드해 입력과 정리를 같이 끌어오면, 진도표의 빈칸을 메우는 일과 강의 자료를 잇는 일이 한 번에 이뤄집니다. 구조를 먼저 세워 두고 그 위에 자료를 끌어오는 순서라, 자료가 구조 없이 쌓이기만 하는 상황을 피할 수 있습니다.


여기서 임베드와 링크를 둘 다 쓰는 감각이 생깁니다. 강의 페이지처럼 "지금 이 자리에서 같이 보고 싶은 것"은 느낌표를 붙여 임베드하고, 다른 서비스 노트처럼 "필요할 때 건너가면 되는 것"은 느낌표 없이 링크합니다. 같은 대괄호 문법인데 느낌표 하나로 "펼칠지, 가리킬지"가 갈립니다. 이 둘을 상황에 맞게 섞으면, 노트 하나가 정리이자 출처 모음이자 다른 노트로 가는 이정표 노릇을 동시에 합니다.
저작권 경계 — 개인 Vault와 공개는 다른 이야기
여기까지가 기술이고, 이제 기술만큼 중요한 선을 짚어야 합니다. 강의 슬라이드를 Vault에 넣어 쓴다는 것은, 그 자료가 내가 정당하게 보유한 자료라는 전제 위에서만 성립합니다. 그리고 더 중요한 것은, 내 Vault에 넣어 개인적으로 보는 것과 그 내용을 바깥에 공개하는 것이 전혀 다른 행위라는 점입니다.
제가 참고한 강의 슬라이드에는 저작권 고지가 분명히 적혀 있습니다. 이 슬라이드는 저작권이 있으며 개인 사용으로만 한정되고, 이 문서를 공유하지 말라는 취지의 문구입니다(원문은 강의 슬라이드의 고지를 따릅니다). 이 고지는 두 가지를 가릅니다. 내가 강의를 듣고 시험을 준비하려고 그 PDF를 내 디스크의 Vault에 넣어 보는 것은 개인 사용의 범위 안에 있습니다. 반면 그 PDF나 그 안의 슬라이드 내용을 블로그에 옮기거나, 공유 드라이브에 올리거나, 남에게 전달하는 것은 공유에 해당하고, 고지가 분명히 막고 있는 행위입니다. 이 글 자체도 그 경계를 지키느라 슬라이드의 실제 내용을 한 줄도 싣지 않았습니다. 다루는 것은 "어떻게 임베드하는가"라는 도구 사용법이지, 슬라이드에 무엇이 적혀 있는가가 아닙니다.
흥미로운 점은, 첫 글에서 Obsidian의 장점으로 꼽았던 성질이 여기서는 거꾸로 주의할 지점이 된다는 것입니다. 노트와 첨부가 평문·로컬 파일이라는 사실은, 데이터를 내가 소유하고 어디로든 옮길 수 있다는 자유를 줍니다. 그런데 바로 그 자유 때문에, Vault 폴더를 통째로 어딘가에 동기화하거나 git 저장소로 올리는 순간, 그 안에 든 강의 PDF도 함께 따라 올라갈 수 있습니다. 평문이라 옮기기 쉽다는 성질이 "개인 Vault"와 "공개"의 경계를 흐리기 쉽게 만든다는 뜻입니다. 그래서 Vault를 외부에 동기화하거나 저장소에 올릴 계획이라면, 저작권이 걸린 첨부가 그 범위에 섞여 들지 않는지 한 번 더 확인하는 습관이 필요합니다. 개인 학습용으로 가진 자료가 의도치 않게 공개 저장소에 올라가는 일은, 기술적으로는 너무 쉽게 일어나기 때문입니다.
정리하면 이렇습니다. 임베드라는 기능은 내 학습을 편하게 하려고 있는 것이지, 남의 자료를 퍼뜨리라고 있는 것이 아닙니다. 개인 Vault 안에서의 활용까지가 이 글이 권하는 범위이고, 그 선을 넘는 공유는 자료에 적힌 고지와 저작권의 영역으로 넘어갑니다. 도구가 무엇을 가능하게 하는지와, 무엇을 해도 되는지는 다른 질문입니다.
마무리 — 자료를 모았으니, 이제 복습으로
이 글에서 정리한 내용을 한 줄로 줄이면, "강의라는 입력과 내 노트라는 정리를, 느낌표 하나로 같은 자리에 펼쳐 두는 법"입니다. PDF가 Obsidian의 첨부로 들어가고, ![[파일.pdf#page=N]]으로 특정 페이지를 내 서비스 노트의 맥락에 임베드하면, 두 자료를 오가던 마찰이 줄어듭니다. 그리고 그 편리함은 어디까지나 개인 Vault 안에서의 활용이라는 선 안에서만 성립합니다.
개인적으로 이 워크플로를 정리하면서 남은 인상은, 임베드가 결국 첫 글에서 본 "링크로 생각하기"의 연장이라는 점이었습니다. 링크가 노트를 가리키는 일이라면, 임베드는 그 가리킨 것을 지금 이 자리에 펼쳐 두는 일입니다. 느낌표 하나의 차이일 뿐인데, 이 차이가 흩어진 자료를 한 화면으로 모아 줍니다. 강의를 듣는 시간과 정리하는 시간이 따로 놀던 것이, 정리 노트 안에 강의 페이지가 함께 놓이면서 한 흐름으로 이어졌습니다. 도구가 대단한 기능을 더해 준 게 아니라, 원래 따로 보던 두 자료를 같은 자리에 두게 해 준 것에 가깝습니다.
또 하나 남는 것은, 편리한 기능일수록 그 경계를 같이 생각해야 한다는 점입니다. 평문·로컬이라는 성질은 자료를 자유롭게 다루게 해 주지만, 그 자유가 저작권의 선까지 지워 주지는 않습니다. 무엇을 할 수 있는가와 무엇을 해도 되는가를 나눠서 보는 습관은, 노트 앱을 쓸 때도 코드를 다룰 때와 다르지 않았습니다. 자료가 노트 안으로 다 모였으니, 다음 글에서는 이렇게 쌓인 노트를 시험 직전에 어떻게 복습하고 약점만 골라 도는지를 다루려 합니다. 그래프와 태그를 복습의 도구로 다시 보는 이야기가 그 출발점이 됩니다. 비슷한 자리에서 강의와 노트 사이를 오가며 헤매는 분들에게 이 글이 작은 참고가 되기를 바라며 마무리합니다.
Github repository link
- Obsidian Vault 공유 링크 — https://github.com/thswlsqls/AWS-Certifications
참고한 공식 문서
- Obsidian Help — Accepted file formats — https://help.obsidian.md/file-formats
- Obsidian Help — Embed files — https://help.obsidian.md/embeds
- Obsidian Help — Attachments — https://help.obsidian.md/attachments
- Obsidian Help — Internal links — https://help.obsidian.md/links
'STUDY' 카테고리의 다른 글
- Total
- Today
- Yesterday
- InterruptedException
- mybatis
- 트래픽 처리
- Cache Penetration
- DB 인덱스 성능
- 백엔드 성능
- TTL 설계
- Double-Checked Locking
- 스레드 생명주기
- Cache Avalanche
- Cache Aside
- 트랜잭션 관리
- 캐시와 인덱스
- 캐시 성능 비교
- Hot Key 문제
- 동시성처리
- Enum 기반 싱글톤
- spring batch 5
- 캐시 장애
- DB 트랜잭션
- Redis 캐시 전략
- Eager Initialization
- 백엔드 아키텍처
- 백엔드 성능 튜닝
- Java Performance
- 백엔드 성능 설계
- Redis vs DB
- Spring Batch
- Redis 성능 개선
- Initialization-on-Demand Holder Idiom
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
