AWS 프로페셔널 자격증 3개 두 달 취득기 — 기출 복기 공부법과 한계
목차
TL;DR
- 딴 것: 프로페셔널 3개(아키텍트·데브옵스·생성형 AI 개발자) + 기초 1개(AI Practitioner), 두 달
- 공부법: 강의 통독 안 함. 기출 문제를 Claude에 던지고 “왜 이게 정답이고 나머지는 왜 틀렸는지”를 한국어로 설명받는 식
- 가장 짧았던 케이스: AI Practitioner는 3일, 교재 0권, 65문항 중 오답 5개 미만
- 먹힌 이유: 공부법보다, 평소에 굴리던 사이드 프로젝트가 그대로 시험 답이었던 게 큽니다
- 한계: 멀티 리전 운영이나 대규모 무중단 배포는 시험만 통과했지 굴려본 적이 없습니다
두 달에 네 개, 강의는 한 편도 안 봤습니다
올해 두 달 사이에 AWS 프로페셔널 자격증 세 개를 몰아 땄습니다. 아키텍트, 데브옵스, 생성형 AI 개발자. 그 앞에 기초인 AI Practitioner까지 넣으면 네 개입니다.
두꺼운 강의를 처음부터 끝까지 본 적은 한 번도 없습니다. 자랑이 아니라, 요즘 시험 준비 방식이 예전과 완전히 달라졌다는 이야기입니다.
공부 동선 — 기출을 먼저 던지고 개념은 뒤따라오게
예전 방식은 순서가 이랬습니다. 강의나 책을 통독하고, 정리하고, 그다음에 문제를 풉니다. 저는 이 순서를 뒤집어서 기출 문제를 먼저 AI에 던지고 개념이 뒤따라오게 뒀습니다. 인강 0시간, 교재 0권, 노트 0장으로 네 개를 다 봤습니다.
구체적인 틀은 AI Practitioner 합격기에 적어뒀습니다. 기출을 묶어서 던지고, 정답 이유와 오답 이유와 실무 비유를 한꺼번에 받아서, 못 푼 것만 다시 도는 식입니다. 그 글 맨 아래에 제가 쓴 프롬프트를 그대로 붙여뒀으니 필요하시면 복사해 쓰시면 됩니다. 프로페셔널 세 개도 이 틀을 그대로 늘려 썼습니다.
왜 이게 먹히나 — 셋을 한 번에 받아서
문제집 해설은 보통 “정답은 C입니다”에서 끝납니다. 왜 A·B·D가 아닌지는 안 알려줍니다.
AWS 시험은 바로 그 지점을 파고듭니다. 보기 네 개가 전부 그럴듯한 서비스 조합으로 나옵니다. SageMaker냐 Bedrock이냐 Comprehend냐 하는 식입니다. 개념을 알아도 답이 바로 안 나옵니다.
AI한테 물으면 세 가지가 한 번에 나옵니다.
- 정답인 이유를 서비스 동작 원리로 설명해줍니다
- 다른 보기가 틀린 이유를 비슷한 서비스와의 차이로 짚어줍니다
- 실무에서 어떤 상황에 쓰는지 시나리오로 비유해줍니다
이 세 개가 붙어 있는 학습 자료를 사려면 비싸고, 만들려면 시간이 오래 걸립니다. 그 자리에서 만들어진다는 게 이 방식의 전부입니다.
3일 만에 92%가 나온 진짜 이유
솔직히 말하면 공부 방법 덕은 절반쯤입니다. 나머지 절반은 시험 보기 전부터 쌓여 있었습니다.
시험 보기 반년 전부터 Jarvis를 붙잡고 있었습니다. 혼자 쓰는 물건이라 규모는 작지만, 검색이든 배포든 남이 만들어준 게 없어서 전부 제 손으로 짜야 했습니다.
그래서 시험 문제가 이렇게 읽혔습니다.
- “벡터 DB가 뭐냐” → 내가 짠 코드
- “임베딩 모델 선택 기준” → 한 번 갈아끼워본 경험
- “죽은 인스턴스를 자동 교체하려면” → 밤에 혼자 되살아나는 내 봇
보기 네 개를 놓고 고민한 게 아니라, 제 코드에서 그 답을 이미 봤기 때문에 골랐습니다.
그래서 이 공부법만 따로 떼어 가면 같은 결과가 안 나옵니다. 만들어본 게 없으면 AI가 아무리 잘 설명해줘도 “그렇구나” 하고 넘어가게 됩니다. 기출 복기는 이미 손에 있는 걸 빨리 정리해주는 도구입니다.
이 방법으로 안 되는 자리
멀티 리전 운영과 대규모 무중단 배포는 객관식으로 통과했지만 실제로 굴려본 적이 없습니다.
이런 건 문제를 아무리 복기해도 감각이 안 생깁니다. 트래픽이 몰려서 복제가 밀리고, 그 사이 요금이 튀는 걸 직접 봐야 알게 되는 것들이라 그렇습니다. 제 경우 리전을 넘길 일 자체가 아직 없었습니다.
자격증이 실무 깊이를 보장하지는 않습니다. 시험이 쉬워진 만큼, 자격증만 있고 실무가 안 받쳐주면 대화 두세 번에 바닥이 드러납니다. 이어지는 세 편에서는 제가 직접 해본 범위와 안 해본 범위를 매번 분리해서 밝히겠습니다.
이어지는 세 편에서 가져가실 것
시험 개념을 제가 실제로 만든 시스템 옆에 하나씩 놓아봤습니다. 각 편에서 남는 건 이렇습니다.
- 1편 — 자작 RAG vs Bedrock: 관리형을 살지 직접 만들지 저울질할 때 짚어볼 다섯 가지. 임베딩 비용, 데이터 반출 여부, 청크 단위, 날짜 검색 정확도, 가드레일 필요성
- 2편 — Multi-AZ와 재해 복구: 시험이 목표값으로 주는 RTO·RPO가 실제 운영에서 어떤 설정으로 내려앉는지. 커넥션 풀 재시도, 헬스체크 주기, 페일오버 중 쌓이는 요청
- 3편 — 자동 복구: 서버 한 대에서 자동 복구를 흉내 낸 방법. 프로세스는 살아 있는데 응답을 못 하는 좀비 상태를 어떻게 잡았는지
마무리
세 개를 다 따고 나서 실제로 바뀐 건 하나였습니다. 흩어져 있던 제 경험에 AWS가 쓰는 이름이 붙었습니다. “그거 있잖아, 검색이 자꾸 엉뚱한 날짜 가져오는 거”라고 설명하던 걸 이제 “하이브리드 검색”이라고 한 단어로 말합니다.
남한테 설명할 때 이게 꽤 편합니다. 딱 거기까지입니다.
다음 편은 반년 전에 직접 만든 RAG와, 시험이 정답이라고 한 관리형 RAG를 나란히 놓는 이야기입니다.
읽어주셔서 감사합니다.🖐
