Obsidian으로 AWS 자격증 취득하기 2편 - AWS 자격증 3개를 한 Obsidian Vault로 — 서비스 노트 하나로 SAA·DVA·CloudOps 동시 대비하기

들어가며

AWS 자격증을 두 개 이상 같이 준비하기로 마음먹은 순간, 정리 방식에서 한 번은 갈림길을 만납니다. Solutions Architect Associate(SAA-C03), Developer Associate(DVA-C02), CloudOps Engineer Associate(SOA-C03)를 같이 보기로 했다고 해 보겠습니다. 폴더 트리에 익숙한 개발자라면 손이 먼저 움직여서 SAA/, DVA/, CloudOps/ 폴더부터 만들기 쉽습니다. 그리고 각 폴더 안에 S3.md를 하나씩 둡니다. 깔끔해 보입니다. 시험별로 칸이 나뉘어 있으니, 어느 시험을 공부하든 그 폴더만 열면 될 것 같습니다.

그런데 막상 이 구조로 한 달쯤 공부하고 나면 문제가 드러납니다. S3의 스토리지 클래스나 버킷 정책 같은 핵심 개념은 세 시험에 모두 나옵니다. 그래서 SAA/S3.md에 정리한 내용이 DVA/S3.md에도 거의 그대로 들어가고, CloudOps/S3.md에도 또 들어갑니다. 같은 내용을 세 번 적은 셈입니다. 더 큰 문제는 그다음입니다. S3 수명 주기 규칙에 대한 이해가 한 번 깊어졌을 때, 그 깨달음을 세 파일에 모두 반영해야 합니다. 한 곳만 고치고 두 곳을 잊으면, 노트 세 개가 서로 다른 말을 하기 시작합니다.

이 글은 그 갈림길에서 폴더로 시험을 쪼개는 대신, 서비스 노트는 하나만 두고 시험별 관점을 태그와 속성으로 얹는 방식을 정리하는 글입니다. 앞 글에서 잡은 "폴더가 아니라 링크로 생각하기"라는 멘탈 모델을 전제로 합니다. 기술적인 사실은 Obsidian 공식 문서에서 확인되는 범위 안에서만 적겠습니다. 정답을 제시한다기보다, 여러 자격증을 한 Vault에서 준비하면서 왜 이 구조에 다다랐는지를 공유하는 정도로 읽어 주시면 좋겠습니다.

---

같은 노트를 세 번 쓰면 무엇이 깨지나

폴더로 시험을 나눈 구조의 진짜 비용은 디스크 용량이 아니라 유지보수입니다. 코드를 다뤄 본 사람이라면 익숙한 이름이 하나 떠오릅니다. 중복입니다. 같은 지식이 세 파일에 복사되어 있다는 것은, 그 지식이 바뀔 때마다 세 곳을 같이 고쳐야 한다는 뜻입니다. 한 곳만 고치고 나머지를 잊는 순간, 어느 것이 최신인지 알 수 없게 됩니다.

소프트웨어에서 이런 상황을 피하려고 우리가 따르는 원칙이 있습니다. 하나의 지식은 한 곳에만 두고, 필요한 곳에서는 그것을 참조하라는 것입니다. 같은 내용을 여러 군데 복사해 두면 언젠가 서로 어긋나기 때문입니다. 자격증 노트도 다르지 않습니다. S3가 무엇이고 스토리지 클래스가 어떻게 나뉘는지는 어느 시험에서나 같은 사실입니다. 시험이 세 개라고 해서 S3라는 서비스가 세 개가 되는 것은 아닙니다.

그렇다면 시험마다 다른 부분은 무엇일까요. 다른 것은 S3 자체가 아니라, S3를 바라보는 각도입니다. 같은 버킷 정책을 두고도 어떤 시험은 "이 정책으로 어떻게 안전한 아키텍처를 설계하나"를 묻고, 어떤 시험은 "애플리케이션 코드에서 이 권한을 어떻게 다루나"를 묻고, 어떤 시험은 "운영 중에 이 설정이 틀어졌을 때 어떻게 찾아내나"를 묻습니다. 서비스는 하나인데 질문의 방향이 셋입니다. 그러니 노트를 셋으로 쪼갤 게 아니라, 노트는 하나로 두고 그 위에 세 방향의 질문을 얹는 편이 구조에 더 맞습니다.

---

세 시험은 같은 서비스를 다른 각도로 본다

SAA·DVA·CloudOps를 한 줄로 거칠게 구분하면 이렇게 말할 수 있습니다. SAA는 설계의 시험이고, DVA는 개발의 시험이고, CloudOps는 운영의 시험입니다. 강조점이 각각 설계·개발·운영으로 다릅니다. 그런데 이 세 시험이 다루는 대상 서비스 자체는 크게 겹칩니다. IAM, EC2, S3, RDS, Route 53, VPC, CloudFront, Lambda 같은 핵심 서비스는 어느 시험에서나 등장합니다. 보안, 배포, 모니터링 같은 영역도 세 시험에 걸쳐 반복됩니다.

겹치는 정도가 구체적으로 얼마인지는 AWS가 공개하는 공식 시험 가이드의 도메인 비중을 보면 숫자로 확인할 수 있습니다. 다만 그 비중을 노트 구조와 진도 관리에 어떻게 반영하는지는 이 시리즈의 다음 글에서 따로 다룹니다. 여기서는 "대상 서비스는 크게 겹치고, 시험마다 그것을 보는 각도가 다르다"는 사실까지만 잡고 가겠습니다. 정확한 도메인별 비중은 SAA-C03·DVA-C02·SOA-C03 공식 시험 가이드에 적힌 그대로를 기준으로 삼으면 됩니다.

이 구분을 S3 한 서비스에 대입해 보면 그림이 또렷해집니다. 설계 관점에서 S3를 볼 때는 내구성과 가용성, 스토리지 클래스 선택, 정적 웹 호스팅, 다른 서비스와의 연계 같은 것이 중심에 옵니다. 개발 관점에서는 SDK로 객체를 올리고 내리는 방법, presigned URL, 멀티파트 업로드, 이벤트 알림으로 Lambda를 트리거하는 흐름이 중심입니다. 운영 관점에서는 액세스 로깅, 버전 관리와 복제, 수명 주기로 비용을 줄이는 설정, 권한이 틀어졌을 때의 조치가 중심이 됩니다. 같은 S3인데 시험마다 무게가 실리는 자리가 다릅니다. 노트를 세 파일로 나누면 이 "다른 무게"를 표현하려다 "같은 본문"까지 세 번 복사하게 되는 것입니다.

---

강의 자료도 공유 모듈로 짜여 있다

이 "한 서비스, 여러 관점" 구조가 노트를 정리하는 한 사람의 취향만은 아닙니다. 자격증 강의가 실제로 비슷한 구조로 짜여 있는 사례를 하나 참고할 수 있습니다. 마렉(Stéphane Maarek)의 AWS 강의 슬라이드 세 덱(SAA-C03, DVA-C02, CloudOps SOA-C03)을 구조 수준에서 보면, 세 강의가 공통 영상을 재사용하고 그 위에 시험별 특화 영상만 얹는 방식으로 구성돼 있습니다.

조금 더 들어가면, SAA 강의의 도입부는 이 강의가 Cloud Practitioner, Developer, SysOps 과정과 지식을 공유한다는 점을 밝힙니다. CloudOps 강의는 [CCP], [SAA], [DVA] 같은 표시가 붙은 재사용 영상과 CloudOps 전용 영상을 함께 묶어 구성합니다. 세 덱의 목차를 나란히 놓고 보면, IAM·EC2·S3·RDS·Route 53·VPC·CloudFront·Lambda 같은 공통 섹션이 반복되고, 그 위에 각 시험에 특화된 섹션이 더해지는 형태입니다.

여기서 분명히 해 둘 것이 있습니다. 이 강의 슬라이드는 저작권이 있는 개인 학습용 자료입니다. 그래서 이 글에서는 강의의 구조, 즉 목차 수준의 구성 사실만 참고했고, 슬라이드 본문이나 문구를 옮기지 않았습니다. "어느 강의가 더 낫다"는 평가도 이 글의 관심사가 아닙니다. 다만 한 가지는 짚을 만합니다. 노트를 시험별 폴더로 쪼개지 않고 공통 지식을 한 번만 정리한 뒤 시험별 관점을 얹는 방식은, 적어도 한 강의가 자료를 실제로 그렇게 구성하고 있다는 점에서 무리한 발상은 아니라는 것입니다.

---

서비스 노트 하나에 관점을 얹는다 — 태그

이제 구조를 실제 노트로 옮겨 보겠습니다. 출발점은 단순합니다. S3는 S3.md 한 노트로 둡니다. 그 안에 본문은 한 번만 정리하고, 시험마다 다른 부분은 "관점"이라는 이름의 절로 구분합니다. 설계 관점, 개발 관점, 운영 관점을 노트 안의 소제목으로 나누는 식입니다.

각 관점이 어느 시험에 걸리는지는 태그로 표시합니다. Obsidian에서 태그는 본문에 # 뒤에 키워드를 붙여 만듭니다. 공식 문서는 태그를 "원하는 노트를 빠르게 찾도록 돕는 키워드나 주제"라고 설명합니다. 그래서 설계 관점 절 아래에는 #saa를, 개발 관점 절에는 #dva를, 운영 관점 절에는 #cloudops를 붙여 둡니다. 나중에 SAA만 집중해서 보고 싶을 때 #saa로 검색하면, S3든 EC2든 SAA 관점이 달린 노트만 모아 볼 수 있습니다. 폴더로 나누지 않고도 시험별로 노트를 모으는 효과를 얻는 것입니다. 

서비스 노트 템플릿1/2 — 설계 관점 절 옆에 #saa 태그가 붙어 있다

 

서비스 노트 템플릿2/2 — (개발 관점 생략) 설계 관점 절 옆에 #cloudops 태그가 붙어 있다

 

태그를 한 단계 더 쓰면 분류를 더 잘게 나눌 수 있습니다. 공식 문서에 따르면 슬래시(/)로 중첩 태그를 만들 수 있어서, #saa/storage처럼 적으면 SAA 안에서도 스토리지 주제만 따로 묶을 수 있습니다. 더 좋은 점은, 부모 태그로 검색하면 그 아래 중첩 태그까지 함께 잡힌다는 것입니다. 공식 문서의 예를 빌리면 tag:inbox로 검색했을 때 #inbox와 #inbox/to-read가 모두 걸립니다. 같은 원리로 #saa로 검색하면 #saa/storage, #saa/network까지 한 번에 모입니다. 시험이라는 큰 분류와 도메인이라는 작은 분류를 태그 하나로 같이 표현할 수 있는 셈입니다.

태그를 쓸 때 한 가지 규칙은 미리 알아 두는 편이 좋습니다. 태그에는 공백을 넣을 수 없습니다. 공식 문서는 알파벳, 숫자, 밑줄(_), 하이픈(-), 슬래시(/)와 흔히 쓰이는 유니코드 문자를 허용하되, 띄어쓰기 대신 camelCase나 kebab-case 같은 방식을 쓰라고 안내합니다. 그래서 "비용 최적화"를 태그로 만들 때는 #cost-optimization처럼 적습니다. 태그가 대소문자를 구분하지 않지만 처음 만든 표기로 표시된다는 점도 함께 기억해 두면, 같은 개념에 표기가 제각각인 태그가 흩어지는 일을 줄일 수 있습니다.

여기에 앞 글에서 잡은 링크가 더해지면 노트들이 자연스럽게 이어집니다. S3 노트 안에서 IAM을 언급할 때 [[IAM]]으로 걸어 두면, 권한이라는 주제로 두 노트가 연결됩니다. 특정 관점만 가리키고 싶을 때는 소제목 링크를 쓸 수 있습니다. 공식 문서에 따르면 [[S3#운영 관점]]처럼 적으면 S3 노트의 운영 관점 절로 바로 이동합니다. 표시되는 글자를 바꾸고 싶다면 [[S3|S3 운영 시 주의점]]처럼 세로 막대로 별칭을 줄 수도 있습니다. 폴더로 칸을 나누지 않아도, 태그로 묶고 링크로 잇는 것만으로 노트 사이의 관계가 드러납니다.

---

속성으로 노트가 걸리는 시험을 표시한다

태그가 노트 본문 안에서 관점을 표시하는 도구라면, 노트 전체가 어느 시험에 걸리는지는 속성으로 적어 두는 편이 깔끔합니다. Obsidian의 속성은 노트 맨 위 YAML 프런트매터에 적는 구조화된 정보입니다. 공식 문서는 속성을 노트의 메타데이터로 설명하며, ---로 둘러싸인 영역 안에 이름: 값 형식으로 적는다고 안내합니다.

S3 노트라면 프런트매터를 이렇게 둘 수 있습니다.

---
service: S3
exams: [saa, dva, cloudops]
tags:
  - saa/storage
  - dva/storage
  - cloudops/storage
---

exams는 이 노트가 세 시험 모두에 걸린다는 사실을 한눈에 보여 줍니다. 여러 값을 담아야 하니 리스트 타입을 씁니다. 공식 문서는 속성 타입으로 텍스트, 리스트, 숫자, 체크박스, 날짜, 날짜·시간을 지원한다고 설명합니다. exams처럼 여러 값을 담을 때는 리스트가 맞고, "이 노트를 다 정리했는가" 같은 표시가 필요하면 체크박스 타입이 어울립니다.

tags는 조금 특별합니다. 공식 문서에 따르면 tags는 Obsidian이 기본으로 제공하는 속성 가운데 하나이고, 태그 전용 타입을 가집니다. 그래서 본문에 #saa라고 적든, 프런트매터의 tags 리스트에 saa를 넣든 같은 태그로 취급됩니다. 노트 전체에 걸리는 시험·도메인 태그는 프런트매터에 모아 두고, 본문 특정 절에만 해당하는 관점은 그 절 옆에 # 태그로 붙이는 식으로 역할을 나누면, 노트의 머리만 봐도 이 노트가 어디에 속하는지 파악됩니다.

이렇게 속성으로 시험을 박아 두면, 나중에 노트들을 시험·도메인 기준으로 자동으로 모아 보는 길이 열립니다. 다만 그 자동화를 어떻게 구성하는지, 그리고 공식 도메인 비중을 속성에 어떻게 반영해 진도표로 만드는지는 다음 글의 몫입니다. 이 글에서는 "노트마다 어느 시험에 걸리는지를 속성으로 적어 둔다"는 데까지만 잡아 두겠습니다.

---

마무리 — 폴더가 아니라 관점으로 나눈다

이 글을 한 줄로 줄이면, "세 시험은 같은 서비스를 다른 각도로 볼 뿐이므로, 서비스 노트는 하나만 두고 시험별 관점을 태그와 속성으로 얹는다"가 됩니다. 폴더로 시험을 쪼개면 같은 본문을 세 번 복사하게 되고, 그 복사본이 시간이 지나면서 서로 어긋납니다. 노트를 하나로 두고 그 위에 관점을 얹으면, 지식은 한 곳에서만 관리하면서도 시험별로 모아 보는 효과를 같이 얻습니다.

개인적으로 이 구조를 정리하면서 남은 인상은, 자격증 노트를 정리하는 일이 코드를 정리하는 일과 닮았다는 점이었습니다. 같은 지식을 여러 곳에 복사하지 않고 한 곳에만 두는 것, 분류를 폴더라는 단일 축이 아니라 태그라는 여러 축으로 표현하는 것은 모두 개발하면서 익힌 감각과 같은 자리에 있습니다. Obsidian이 폴더 대신 링크와 태그를 권하는 이유가, 결국 한 노트가 여러 맥락에 동시에 속할 수 있다는 사실을 인정하는 데 있다는 것도 이 정리를 거치며 분명해졌습니다. AWS 서비스 지식이 여러 시험에 걸치는 것처럼 말입니다.

한 가지 더 남는 것은, 관점을 얹는 것만으로는 아직 절반이라는 점입니다. 태그와 속성으로 "이 노트가 어느 시험에 걸리는지"는 표시했지만, "그래서 무엇부터 공부해야 하는지"는 아직 정하지 못했습니다. 시험은 공식 가이드의 도메인 비중대로 출제되므로, 비중이 큰 도메인부터 채우는 편이 합리적입니다. 그 비중을 속성에 반영해 노트와 진도를 구조화하는 방법은 이 시리즈의 다음 글에서 이어 가겠습니다. 비슷하게 여러 자격증을 한 번에 준비하며 노트 구조를 고민하는 분들에게 이 글이 작은 참고가 되기를 바라며 마무리합니다.

 

---

Github repository link

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

 

---

참고한 공식 문서

• Obsidian Help — Internal links — https://help.obsidian.md/links
• Obsidian Help — Tags — https://help.obsidian.md/tags
• Obsidian Help — Properties — https://help.obsidian.md/properties
• AWS Certified Solutions Architect – Associate (SAA-C03) Exam Guide — https://docs.aws.amazon.com/aws-certification/latest/solutions-architect-associate-03/solutions-architect-associate-03.html
• AWS Certified Developer – Associate (DVA-C02) Exam Guide — https://docs.aws.amazon.com/aws-certification/latest/developer-associate-02/developer-associate-02.html
• AWS Certified CloudOps Engineer – Associate (SOA-C03) Exam Guide — https://docs.aws.amazon.com/aws-certification/latest/sysops-administrator-associate-03/sysops-administrator-associate-03.html