티스토리 뷰

들어가며 — 비중을 모르면 엉뚱한 데 시간을 씁니다

자격증 공부를 시작할 때 가장 흔한 실수는 흥미가 가는 주제부터 파는 것입니다. VPC 라우팅이 재미있어서 며칠을 붙잡고, 정작 출제 비중이 큰 보안 설계는 시험 직전에야 훑습니다. 시험은 공부한 시간에 비례해 점수를 주지 않습니다. 출제 비중에 비례해 점수를 줍니다. 그래서 공부 순서를 정하는 가장 정직한 기준은 "내가 재미있어하는 것"이 아니라 "공식 가이드가 몇 퍼센트를 배정했는가"입니다.

다행히 AWS는 각 시험의 도메인과 비중을 공식 시험 가이드에 그대로 적어 둡니다. 이 비중은 추측이나 학원 자료가 아니라 AWS가 공개한 1차 정보입니다. 그렇다면 남는 일은 이 비중을 공부 도구 안으로 끌고 들어오는 것입니다. 앞 글에서 한 서비스 노트에 시험별 관점을 태그로 얹는 방법까지 잡았다면, 이번 글은 그 관점을 공식 도메인이라는 뼈대 위에 올려놓고, 어느 도메인이 비었는지를 노트 도구가 스스로 보여 주게 만드는 이야기입니다.


이 글에서 다루는 시험 비중은 모두 AWS 공식 시험 가이드에서 직접 확인한 값이고, Obsidian의 기능은 Obsidian 공식 문서에서 확인한 범위 안에서만 적었습니다. 끝까지 확인하지 못한 부분은 단정하지 않고 그 점을 분명히 밝히겠습니다.


세 시험의 공식 도메인과 비중

먼저 세 자격증의 공식 도메인을 비중과 함께 펼쳐 봅니다. 각주처럼 외우는 대신, 어느 도메인이 무겁고 어느 도메인이 가벼운지를 한눈에 보는 것이 목적입니다.

Solutions Architect – Associate(SAA-C03)는 네 개의 도메인으로 이뤄집니다. 공식 가이드 기준으로 안전한 아키텍처 설계가 30%, 복원력 있는 아키텍처 설계가 26%, 고성능 아키텍처 설계가 24%, 비용 최적화 아키텍처 설계가 20%입니다. 가장 무거운 쪽이 보안이고, 나머지 셋이 비교적 고르게 나뉩니다. SAA는 "설계"라는 동사가 네 도메인 이름에 모두 들어간다는 점이 인상적입니다. 무엇을 고를지가 아니라 어떻게 엮을지를 묻는 시험이라는 성격이 도메인 이름에 그대로 드러납니다.

 

SAA-C03 시험 노트 — 도메인 비중 표와 domains 속성 값


Developer – Associate(DVA-C02) 역시 네 개의 도메인입니다. AWS 서비스를 이용한 개발이 32%, 보안이 26%, 배포가 24%, 트러블슈팅과 최적화가 18%입니다. 개발 도메인 하나가 3분의 1에 가까운 비중을 차지합니다. SDK와 API로 직접 코드를 짜는 능력을 가장 크게 보겠다는 뜻으로 읽힙니다. 흥미로운 건 보안이 26%로 두 번째로 무겁다는 점입니다. 개발자 시험이라고 해서 보안을 가볍게 보면 안 된다는 신호입니다.

DVA-C02 시험 노트 — 도메인 비중 표와 domains 속성 값

 

CloudOps Engineer – Associate(SOA-C03)는 다섯 개의 도메인으로 나뉩니다. 모니터링·로깅·분석·조치·성능 최적화가 22%, 신뢰성과 업무 연속성이 22%, 배포·프로비저닝·자동화가 22%, 보안과 규정 준수가 16%, 네트워킹과 콘텐츠 전송이 18%입니다. 앞의 세 도메인이 똑같이 22%로 묶여 있고, 나머지 둘이 그보다 조금 낮습니다. 운영 시험답게 "장애를 감지하고 되돌리는 일"과 "끊기지 않게 유지하는 일"이 같은 무게로 맨 앞에 섭니다.

SysOps→CloudOps 개명 안내와 다섯 도메인의 비중 표

 

표로 정리하면 세 시험의 무게중심이 한눈에 들어옵니다.

시험 도메인 비중
SAA-C03 안전한 아키텍처 설계 30%
  복원력 있는 아키텍처 설계 26%
  고성능 아키텍처 설계 24%
  비용 최적화 아키텍처 설계 20%
DVA-C02 AWS 서비스를 이용한 개발 32%
  보안 26%
  배포 24%
  트러블슈팅과 최적화 18%
SOA-C03 모니터링·로깅·분석·조치·성능 최적화 22%
  신뢰성과 업무 연속성 22%
  배포·프로비저닝·자동화 22%
  보안과 규정 준수 16%
  네트워킹과 콘텐츠 전송 18%


도메인 이름만 훑어도 세 시험이 같은 서비스를 다른 각도에서 본다는 점이 보입니다. 보안은 세 시험 모두에 들어가지만 SAA는 "안전하게 설계하는" 쪽, DVA는 "애플리케이션 코드와 데이터를 지키는" 쪽, CloudOps는 "운영하면서 규정을 지키는" 쪽으로 강조점이 옮겨 갑니다. 배포도 마찬가지입니다. DVA에서는 CI/CD로 애플리케이션을 내보내는 일이고, CloudOps에서는 프로비저닝과 자동화를 포함한 운영 배포입니다. 같은 S3, 같은 IAM을 공부하더라도 어느 시험의 어느 도메인 관점에서 보는지에 따라 정리할 내용이 달라진다는 뜻입니다.

세 시험의 채점 구조는 같습니다. 공식 가이드 기준으로 점수에 반영되는 문항이 50개이고, 채점에 들어가지 않는 평가용 문항이 15개 더 섞입니다. 점수는 100에서 1,000 사이의 척도 점수로 나오고 합격선은 720입니다. 한 가지 유의할 점은, 이 채점 방식은 보상형이라 도메인별로 따로 합격선을 넘을 필요가 없다는 것입니다. 전체 합계로 720을 넘기면 됩니다. 그래서 비중이 큰 도메인에서 점수를 확보하는 전략이 합격에 더 직접적으로 작동합니다. 다만 문항 수나 시험 시간 같은 정책은 바뀔 수 있으니, 실제 응시 전에는 각 시험의 공식 페이지를 한 번 더 확인하시길 권합니다.


SysOps에서 CloudOps로 — 무엇이 바뀌었나

운영 자격증을 준비한다면 한 가지를 먼저 확인하고 시작해야 합니다. 이 시험은 2025년에 이름과 코드가 모두 바뀌었습니다. AWS 공식 안내에 따르면 기존 "SysOps Administrator – Associate"가 "CloudOps Engineer – Associate"로 개명되었고, 새 시험 코드는 SOA-C03입니다. 새 시험 가이드는 2025년 9월 9일에 공개되었고, 직전 시험인 SOA-C02를 치를 수 있는 마지막 날은 2025년 9월 29일이었습니다. 지금 이 시험을 준비한다면 사실상 SOA-C03 기준으로 공부하게 됩니다.

이름만 바뀐 것이 아닙니다. AWS 공식 안내는 SOA-C03에서 컨테이너가 출제 범위에 새로 들어왔다고 분명히 적습니다. 여기에 더해 더 현대적인 서비스와 기능, 멀티 계정·멀티 리전 아키텍처에 대한 강조, 자동화와 IaC(Infrastructure as Code)에 대한 비중 확대가 함께 반영되었습니다. 실제로 새 가이드의 대상 응시자 설명에는 컨테이너화와 오케스트레이션 기본 지식, ECS 같은 컨테이너 서비스, CloudFormation 같은 IaC 도구가 권장 지식으로 올라와 있습니다. 운영 엔지니어에게 요구하는 그림이 "서버를 관리하는 사람"에서 "코드로 인프라를 다루는 사람"으로 옮겨 간 셈입니다.

여기서 실질적인 주의가 하나 나옵니다. 인터넷에 떠도는 SOA-C02 시절 자료로 공부하면 도메인 구성부터 어긋납니다. SOA-C03는 위에서 본 다섯 개 도메인 구조이고, 이 비중에 맞춰 공부 순서를 잡아야 합니다. 옛 코드 기준의 요약본이나 덤프 성격의 자료는 도메인 비중도, 출제 범위도 지금과 다를 수 있습니다. 노트를 만들 때 시험 코드를 SOA-C03로 분명히 박아 두는 것이 그래서 중요합니다. 나중에 다시 봤을 때 이 노트가 어느 버전 기준으로 정리한 것인지 헷갈리지 않게 하기 위해서입니다.


속성으로 노트에 시험·도메인·진도를 박기

도메인 비중을 확인했으니, 이제 이 정보를 노트 안으로 끌고 들어올 차례입니다. Obsidian에서 노트에 구조화된 정보를 붙이는 표준 방법이 속성(Properties)입니다.

Obsidian 공식 문서에 따르면 속성은 노트 맨 위에 YAML 형식으로 저장됩니다. 노트 본문 위에 세 개의 대시(---)로 감싼 블록을 두고, 그 안에 이름: 값 형태로 적습니다. 자바 개발자에게는 클래스에 붙이는 애너테이션이나, 객체 위에 얹는 메타데이터에 가까운 감각입니다. 본문은 사람이 읽는 내용이고, 속성은 도구가 읽는 내용입니다.


속성에는 타입이 있습니다. Obsidian 공식 문서가 설명하는 타입은 텍스트(Text), 리스트(List), 숫자(Number), 체크박스(Checkbox), 날짜(Date), 날짜·시각(Date & time)입니다. 여기에 더해 tags 속성에만 쓰는 전용 타입이 따로 있습니다. 그래서 "정확히 몇 종"이라고 딱 잘라 세기보다는, 진도 관리에 필요한 타입이 이미 충분히 갖춰져 있다고 보는 편이 정확합니다. 자격증 노트에서는 이 가운데 리스트와 텍스트, 숫자, 체크박스 정도면 대부분 해결됩니다.


서비스 노트 하나에 시험과 도메인, 진도를 박으면 다음과 같은 모습이 됩니다. 앞 글에서 S3 노트 하나에 세 시험의 관점을 얹기로 했으니, 그 노트의 프런트매터에 속성을 더해 봅니다.

---
service: S3
exams: [saa, dva, cloudops]
domains:
  - saa/secure-architectures
  - dva/security
  - cloudops/security-compliance
status: reviewing
confidence: 3
---


exams는 이 서비스 노트가 어느 시험들에 걸리는지를 리스트 타입으로 적은 것입니다. domains는 각 시험의 어느 도메인에 닿는지를 적습니다. 시험 코드와 도메인을 슬래시로 묶어 적어 두면 나중에 "CloudOps의 보안 도메인에 걸린 노트"만 골라 보기 좋습니다. status는 텍스트로 진도를 표시합니다. 처음 만들 때는 todo, 한 번 정리하면 learning, 복습 단계면 reviewing, 다 됐으면 done 정도로 단계를 정해 두면 됩니다. confidence는 숫자 타입으로, 이 주제에 얼마나 자신 있는지를 1에서 5 사이로 매긴 것입니다.

고급 ID 관리 노트 — service·exams·domains·status·confidence 속성이 채워져 있다

 

여기서 굳이 속성을 더 늘리지 않는 편이 좋습니다. 시작 단계에서는 exams와 status 둘만 있어도 진도 관리는 굴러갑니다. 도메인까지 세밀하게 추적하고 싶을 때 domains를 더하고, 약점 복습을 본격적으로 할 때 confidence를 더하는 식으로, 필요해질 때 한 칸씩 늘리면 충분합니다. 처음부터 열 개짜리 속성 틀을 짜 두면 채우는 일 자체가 부담이 되어 노트를 안 만들게 됩니다. 미리 일반화하지 않고 정말 반복되는 것만 구조로 올린다는 원칙은 노트 설계에도 그대로 통합니다.


Bases로 도메인별 진도표 만들기

속성을 박아 두면 이제 그 속성을 기준으로 노트들을 한 표에 모아 볼 수 있습니다. 이 일을 하는 것이 Bases입니다.

Obsidian 공식 문서는 Bases를 "노트를 데이터베이스처럼 보여 주는 뷰를 만드는 코어 플러그인"이라고 설명합니다. 코어 플러그인이라는 점이 중요합니다. 따로 설치하거나 외부 의존성을 들일 필요 없이, Obsidian 설정에서 켜기만 하면 쓸 수 있다는 뜻입니다. 자격증 노트처럼 오래 들고 갈 자료에는 외부 플러그인보다 코어 기능이 안전합니다. 도구가 사라지거나 호환이 깨질 걱정이 적기 때문입니다.

Bases는 같은 노트 묶음을 여러 형태의 뷰로 보여 줍니다. 공식 문서 기준으로 표(Table), 리스트(List), 카드(Cards), 지도(Map) 뷰가 있습니다. 진도 관리에는 표 뷰가 가장 잘 맞습니다. 각 노트가 한 행이 되고, 속성이 열이 됩니다. service, status, confidence를 열로 세워 두면 어느 서비스가 어느 단계에 있는지가 한 화면에 들어옵니다. 카드 뷰는 이미지가 있는 노트를 갤러리처럼 볼 때 어울리니, 진도표보다는 아키텍처 다이어그램을 모아 볼 때 더 쓸모가 있습니다.


Bases의 핵심은 속성으로 거르고 정렬한다는 점입니다. 예를 들어 exams에 cloudops가 들어간 노트만 추려서 status별로 정렬하면, CloudOps 시험을 기준으로 어디까지 진도가 나갔는지가 한 표에 정리됩니다. 도메인 비중이 큰 쪽부터 노트가 채워졌는지, 비중이 22%인 모니터링 도메인이 비어 있지는 않은지를 눈으로 바로 확인할 수 있습니다. 이것이 도입에서 말한 "비중을 모르면 엉뚱한 데 시간 쓴다"의 해독제입니다. 비중 큰 도메인의 칸이 비어 있으면, 그 칸을 먼저 채우면 됩니다.

Bases 진도표 — 서비스 노트가 행, status·exams·domains 속성이 열로 선 표 뷰

 

다만 솔직하게 적자면, Bases가 거르고 정렬하는 데 쓰는 정확한 문법(필터 식의 구체적인 표기)은 이 글을 쓰는 시점에 공식 문서에서 끝까지 확인하지 못했습니다. Bases의 뷰는 별도 문법으로 정의되어 .base 파일로 저장하거나 노트 안의 코드 블록으로 끼워 넣는다는 점까지는 공식 문서에서 확인했지만, 필터 표현식의 세부 문법은 버전에 따라 달라질 수 있어 단정하지 않겠습니다. 실제로 뷰를 만들 때는 Obsidian 공식 Bases 문서의 문법 페이지를 한 번 보고 그대로 따라 하시길 권합니다. 개념은 분명합니다. 속성을 조건으로 노트를 걸러 표로 세운다는 것입니다. 구체적인 표기만 공식 문서에서 확인하면 됩니다.

진도표를 만들 때도 과하게 설계하지 않는 편이 낫습니다. 시험 하나당 표 하나, 그 표를 status로 정렬하는 정도면 시작으로 충분합니다. 도메인별로 표를 더 잘게 쪼개는 일은 정말 필요해졌을 때, 즉 한 시험의 노트가 수십 개로 불어나 한 표에 다 안 들어올 때 해도 늦지 않습니다.


마무리 — 구조가 섰으니 자료를 끌어옵니다

이 글에서 한 일을 한 줄로 줄이면, 공식 시험 도메인이라는 검증된 뼈대를 노트의 속성으로 옮겨 적고, 그 속성을 Bases로 모아 진도표를 세운 것입니다. 도메인 비중은 AWS 공식 가이드에서, 속성과 Bases는 Obsidian 공식 문서에서 확인했습니다. 둘 다 추측이 아니라 1차 정보에 기댄다는 점이, 이 구조를 오래 믿고 쓸 수 있게 만드는 근거라고 생각합니다.

개인적으로 이 작업을 정리하면서 가장 또렷해진 기준은, 노트 도구의 가치는 "쓸 때"가 아니라 "안 쓴 칸을 보여 줄 때" 나온다는 것이었습니다. 노트를 예쁘게 쓰는 일은 누구나 합니다. 정작 어려운 건 "내가 보안 도메인만 붙잡고 모니터링 도메인은 손도 안 댔다"는 사실을 스스로 알아차리는 일입니다. 속성으로 도메인을 박고 Bases로 진도표를 띄우면, 그 빈칸이 표 위에 그대로 드러납니다. 도구가 나 대신 약점을 가리켜 주는 셈입니다. 개발할 때 테스트 커버리지 표가 "안 덮인 코드"를 빨갛게 보여 주는 것과 비슷한 감각이었습니다.

또 하나 남는 인상은, 구조를 먼저 세우면 자료를 끌어오는 일이 쉬워진다는 점입니다. 도메인별 칸이 정해져 있으면 강의 슬라이드든 공식 문서든 "이건 어느 칸에 들어갈 자료인가"를 묻게 되고, 그 질문 자체가 자료를 분류해 줍니다. 다음 글에서는 이렇게 세운 구조 위에 강의 슬라이드 PDF를 노트로 끌어와 붙이는 이야기로 이어 가려 합니다. 진도표의 빈칸을 실제 학습 자료로 채우는 단계입니다. 비슷한 자리에서 노트와 진도를 어떻게 엮을지 고민하는 분들에게 이 글이 작은 참고가 되기를 바라며 마무리합니다.

 


Github repository link

 



참고한 공식 문서