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