지난 날을 반성하는 AWS Solutions Architect Associate 시험 후기

2024년 7월 24일

5–8분

무려 5년 가까이 AWS 에서 서비스를 하고 있었지만 부끄럽게도 이제야 AWS Solutions Architect Associate (이하 SAA)시험을 치렀다. SAA 시험의 내용이나 난이도, 합격 방법 같은 글은 무수히 많기도 하고, 공부 방법이 까다롭거나 한 시험도 아니기 때문에 나는 좀 다른 글을 써볼까 한다. 우물 안 개구리의 반성문이랄까?

나는 왜 5년 동안 SAA test를 보지 않았는가? – Platform Lock-in 이라는 핑계

내가 맡은 서비스는 대략 5년 가까이 AWS에서 운영중이다. 5년이면 AWS의 무수한 운영 노하우나 비용 최적화 방안, 아키텍처 설계에 대해 빠삭하게 알만도 한데, 부끄럽게도 1~2년 전 까지는 AWS를 그리 잘 알지 못했다.

AWS를 잘 몰라도 되는 핑계는 여럿 있었다. 운영 부서가 따로 존재하기 때문에 직접 AWS 콘솔에 들어가 무언가를 할 일이 별로 없었기도 하고, k8s 클러스터를 EC2에 구성해 두었기 때문에 AWS를 잘 몰라도 서비스 운영이 가능했다.
돌이켜볼 때, 가장 고약한 핑계는 “Platform Lock-in 을 경계하는 아키텍처”였다. AWS 특정 서비스에 Lock-in이 되어 버리면 나중에 다른 클라우드 제공자로 넘어가고 싶어도 넘어갈 수가 없다. Lambda 나 SQS 대신 클라우드 네이티브 스택 만으로 서비스를 구성해야 언제든 AWS를 버리고 Azure 나 GCP 로 사뿐히 넘어갈 수 있다. 플랫폼 중립적인 기술만으로 클라우드를 사용한다니 얼핏 생각해보면 꽤나 일리있는 말인 것 같다.

AWS나 GCP 혹은 Azure 에 플랫폼 중립적으로 구성, 수 년째 운영중인 서비스가 있다고 가정해보자. 클라우드 락인 요소가 없는 서비스라고 해서 IDC나 혹은 다른 클라우드에 마이그레이션을 하는 작업이 정말로 간단한 일일까?
아무리 플랫폼 중립적인 기술로 서비스를 구성하였더라도 운영중인 서비스, 더우기 수 년간 쌓인 데이터가 고이 보관된 서비스의 클라우드 제공자를 특별한 이유 없이 손바닥 뒤집듯 바꾸는 것은 굳이 해서는 안될 일에 가깝다. 잘되어야 본전이고 실수라도 하면 일어나지 않았을 장애를 유발하는, 리스크의 상방이 열려있는 행위를 굳이 시간과 비용을 들여 한다는건 그리 좋은 선택지가 아니다. 지나고 나서야 드는 생각이지만 “Platform Lock-in”을 핑계로 사용중인 클라우드만의 우수한 기능을 사용하지 않는다는건 바보같은 짓이다. 어차피 당신은 지금 쓰고 있는 클라우드를 떠날 수 없다.(정확히는 굳이 떠날 필요가 없다.)

eks와 karpenter를 도입하고 클라우드 비용 20% 절감한 건에 관하여

위에서 잠깐 언급했지만 1년 전만 해도 우리 서비스는 eks 대신 EC2에 클러스터를 직접 구성하는 방식이었다. 어느 정도 규모 있는 회사라면 관리부서에서 직접 인프라를 관리하기 마련이기에, k8s 클러스터 관리도 인프라 부서에서 한다. 보통은 표준화된 방법으로 관리를 하다보니 말 그대로 AWS에서 EC2 VM만 가져다 쓴 셈이지 AWS 클라우드만의 솔루션이나 기능은 왠만해선 잘 쓰지 않았다.
그러다 우연한 기회에 EC2에 구성한 클러스터를 eks로 전환할 일이 있었는데, 기왕 전환하는 김에 karpenter 도 함께 도입하였다. AWS에서 야심차게 내놓은 오픈소스 클러스터 오토스케일러가 어떤지 궁금하기도 했다.
놀랍게도!! karpenter 도입 이후 클라우드 비용이 20%가 넘게 줄어들었다. 데이터 저장구조나 코드, 아키텍처를 최적화하지 않고도 이렇게 간단히 클라우드 비용을 낮출 수 있다니! 맛난 공짜점심을 먹으며 어렴풋이 이런 생각이 들었다.

“내가 AWS를 너무 몰랐구나.”

마음 한 켠이 내키지 않는 농심 라면 스펙 외우기

플랫폼 중립적인 기술만으로 서비스를 구성한다는 회사의 방침도 방침이지만, 얼마 전까지는 나 역시도 이런 플랫폼 중립적인 아키텍처에 동의하는 바였다. 특히 AWS 특유의 촌스러운 서비스 명칭을 별도로 시간내서 공부해야 한다는게 마음 한 켠이 내키지 않았다. 내가 왜 굳이 SageMaker 나 OpenSearch, SQS, CloudFormation 같은 고유명사를 외워가며 이 서비스의 역할이 무엇인지 알아야 하나. 이건 마치 슈퍼에 진열된 라면의 특징을 외우는 것과 다를 바 없지 않나. 나는 나만의 라면 제조사 브랜드 중립적인 라면 끓이기 레시피를 선호한다고.
농심 사리곰탕면의 나트륨 함량은 16g 이고 우윳빛 사골국 맛이 난다던지, 콕콕 스파게티의 열량은 284kcal 이라 한 사발만으로 부족하니 1.5사발을 해야 한다던지 등의 지식을 외우는 사람은 없잖아?

사실 이 글을 쓰는 이유는 혹시라도 AWS 서비스를 알아가는 것에 대해 나와 같은 이유로 거부감을 가지는 사람이 있다면 지금이라도 생각을 바꾸기 바라는 마음에서다. 수십 년 째 클라우드 서비스 제공자 업계 부동의 1위인 업체에서 만든 서비스의 기능과 목적, 활용 사례를 알아보는 것 만으로도 많은 공부가 된다. 교만했던 나는 이 사실을 SAA 를 준비하면서 알게 되었다.
그러니까 S3 라던지 SQS, Lambda 같은 것들은 사리곰탕면 같은 고유명사가 아니라 대일밴드나 에스컬레이터처럼 보통명사화 된 제품들이라는거다.

다음은 AWS 에서 발간한 백서 “AWS Well-Architected Framework”의 링크다. 무려 910 페이지나 되는 글이라 쉽지 않겠지만 클라우드 환경에서의 설계 원칙이 무엇인지, AWS는 어떤 요소들을 중요하게 생각하는지 알 수 있는 글이기에 클라우드를 사용하여 서비스를 개발하는 아키텍트거나, 아키텍트를 꿈꾸는 사람, 그리고 SAA를 준비하는 사람이라면 일독을 권한다. 꼼꼼히 정독한다기보단 AWS에서 중요하게 여기는 설계 원칙과 모범 사례가 무엇인지 훑는 정도로 참고하면 적당할 듯 하다.
https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/wellarchitected-framework.pdf#welcome

ChatGPT vs Claude – LLM과 함께 공부하는 SAA

SAA를 준비한 기간은 대략 2주 정도이다. 아무래도 직장생활을 하면서 시험을 준비하다보니 많은 시간을 쏟기는 어렵다. 때문에 내가 선택한 공부 방법은 비용을 지불하면서라도 공부를 편하게 하는 것이었다.

AWS Skill Builder 를 구독하면($29/월) 60문항 짜리 연습문제를 풀어볼 수 있는데, 이런 식으로 문제를 풀어봐야 SAA 시험이 어떤 식으로 출제되는지 감을 잡을 수 있다.
Exam Prep Enhanced Course: AWS Certified Solutions Architect – Associate(SAA-C03) 가 유료 강의이고 대부분의 내용이 유사하나 연습문제 갯수가 다르다(무료: 15문제 vs 유료: 60문제)
실제 시험이 75문제(이중 15문제는 점수에 미포함, 실제론 60문제)이므로 60문제 짜리를 풀어봐야 시험에 가깝게 대비를 해볼 수가 있다.

결정적으로 많은 도움을 받았던 도구는 ChatGPT와 Claude 였다. 처음에는 GPT로 학습을 하다 가끔씩 결정적인 오류를 자연스럽게 설명하는 만행(?)을 저지르는 바람에 Claude로 변경하였지만…
내가 주로 활용했던 방식은 다음과 같다.

문제를 풀다 모르는 서비스나 용어가 나오면 해당 단어에 대한 설명을 질의
범용적인 기술 혹은 오픈소스 중에 유사한 기술이 있다면 비교
실질적인 사용 사례

문제를 풀 때 Kinesis Firehose 라는게 나왔는데 이 서비스가 어떤 것인지 사용을 해보지 않아서 설명만으로는 감이 잘 오지 않았다. 찾아보니 스트리밍 데이터에 대한 분석에 활용된다길래 Apache Spark 와 유사한 서비스인지 질문하였다.

몇 번의 질의를 거치니 logstash와 같은 데이터 파이프라인 도구라는 것을 알 수 있었다. 특히 이런 시험문제의 요점 정리를 할 때는 매우 유용하다. – 사실 LLM 시대에 외워서 따는 자격증이 무슨 큰 의미가 있겠냐마는 어쨋든 공부에 도움이 되는건 맞다.

특히 인프라 운영 부서가 나뉘어져 있는 회사에서는 보안이나 인증, 설정 관련한 솔루션 – WAF, Cognito 나 Config 등 – 은 써볼 기회가 잘 없을텐데, 이런 경우 해당 서비스에 대한 대략적인 개념을 파악할 때 도움이 된다.

CloudFront + ECS + Lambda + Fargate + SQS + S3 = 가장 효율적인 아키텍처라는 가스라이팅

SAA를 준비하다보면서 느낀 점을 말해보자면, 자꾸 AWS 솔루션이 클라우드 아키텍처에서 구성할 수 있는 최고로 효율적인 방안이라는 가스라이팅을 당하게 된다는거다. 이런 문제가 자꾸 나온다.

‘다음 중 관리 코스트가 가장 낮은 아키텍처는?’
‘다음 중 비용 효율적인 아키텍처는?’
‘처리시간이 오래 소요되는 요청을 효과적으로 해결하는 아키텍처는?’

이때 전가의 보도처럼 등장하는 솔루션이 Lambda + SQS + S3 이다. 문제에 따라 가끔 CloudFront, ECS와 Fargate 를 곁들이기도 한다. 이런 문제풀이를 계속하다보면 어느새 비동기 처리 문제 = Lambda + SQS 가 떠오른다. 비용 효율적인 Fargate나 빠른 응답성을 제공하는 CloudFront + S3 조합도 있다.

사실 같은 AWS 솔루션을 쓰더라도 1가지 문제를 풀기 위한 다양한 방법이 존재한다. 이를테면 이 글의 서두에서 언급한 eks + Karpenter 를 사용하면 EC2를 쓰더라도 ECS 나 Fargate 보다 비용 효율적으로 동작시킬 수 있다. 하지만 이런 객관식 문제들은 모든 아키텍처 구성과 트레이드 오프를 다룰 수 없기에 어쩔 수 없이 특정 솔루션에 편향되어 있는 측면이 있다.

비대면 시험의 주의점 – OnVue 는 iPhone의 연속성 카메라를 지원하지 않는다.

만일 당신이 SAA를 비대면으로 치를 마음이 있고, 맥북과 보조 모니터 환경을 구성해 시험을 볼 예정이라면 당신은 매우 운이 좋은 사람이다. SAA 비대면 시험 솔루션인 OnVue 는 맥북 + 아이폰 연속성 카메라 구성을 제대로 지원하지 않는다. 별도의 웹캠을 구하던가 아니면 보조 모니터 대신 맥북 내장 모니터와 내장 웹캠을 써라.

나는 OnVue 와 맥북-iPhone 의 연속성 카메라 호환성 문제로 첫번째 시험은 15분 쯤 경과한 시점에 더이상 진행을 하지 못하고 종료되었다. 시험을 치르기 전에 OnVue는 나의 시험 환경에 문제가 없는지 체크를 한다. 브라우저가 떠있다던가, 모니터가 2대 이상이라던가, 웹캠이나 마이크가 제대로 설치되지 않았다던가 하는 문제들을 차례로 검사하는데, 이때 아이폰 연속성 카메라에 대해서는 별다른 문제를 삼지 않는다. 다만 시험 시작 후 약 15분 쯤 경과하면 커서가 무지개로 변하고 아무 것도 할 수 없게 된다.

몇 문제 풀어보지도 못하고 Fail할 뻔 했지만, 다행히 OnVue 측에서 다시 시험을 볼 수 있도록 조치해 주었다.

요약

SAA 시험 준비하는데 2주 걸림. 경력이 좀 된다면 2주면 충분하겠지만 주니어 직장인이라면 2주가 부족할 수도 있음.
AWS Skill Builder 에서 $29/월 하는 구독을 해서 연습문제와 동영상 강의를 보는 것이 도움이 됨.
덤프는 절반 이상이 오답임. 문제만 참고하고 스스로 풀어야 함.
LLM 은 모르는 개념이나 용어, 서비스를 요약, 비교, 설명해주는 훌륭한 도구임.
맥북 + 아이폰 연속성 카메라는 비대면 테스트와 호환되지 않음.