(1/5) AWS 전문가 면접, 뭘 물어야 하나 — 면접관을 위한 전체 그림과 전략
🧭 AWS 전문가 면접 가이드 — 면접관을 위한 배경 지식과 질문 5부작 — “AWS 시니어를 뽑아야 하는데 정작 내가 AWS 를 잘 모른다.” 꽤 흔한 상황이에요. 서비스 이름을 200 개 외운다고 면접이 되는 것도 아니고요. 이 시리즈는 면접관 입장에서 필요한 것만 골라 담았습니다. 각 편은 ① 5분이면 따라오는 배경 설명 → ② 실제로 던질 질문 → ③ 답을 못 알아들어도 쓸 수 있는 채점 포인트 순서로 이어져요. 전체 그림과 면접 전략을 먼저 잡고(1편), 인프라·아키텍트(2편), DevOps·플랫폼(3편), 보안·거버넌스와 금융권 규제(4편), 데이터·AI 플랫폼과 60분 진행 시나리오(5편)까지 갑니다. 전체 5편.
- 뭘 물어야 하나 — 전체 그림과 면접 전략 ← 지금 글
- 클라우드 인프라·아키텍트 — VPC 부터 비용까지
- DevOps·플랫폼 엔지니어 — IaC, CI/CD, EKS 운영
- 보안·거버넌스 — IAM 부터 금융권 규제까지
- 데이터·AI 플랫폼 + 60분 면접 진행 시나리오
Summary
“AWS 전문가를 뽑아야 하는데, 정작 면접에 들어가는 내가 AWS 를 잘 몰라요.”
생각보다 흔한 상황이에요. 조직에서 클라우드를 처음 들이거나, 팀장이 인프라 출신이 아니거나, 아니면 그냥 인력이 급하거나. 그런데 이 상태로 면접에 들어가면 보통 두 가지 중 하나가 벌어집니다. 후보자가 자신 있게 말하는 걸 다 믿거나, 반대로 아무 말도 못 알아들어서 “인상이 좋았다” 로 결론을 내거나요.
둘 다 위험해요. 클라우드 인력은 잘못 뽑았을 때 비용이 늦게, 크게 터지는 직군이거든요. 설계가 틀어져도 3개월은 잘 돌아가고, 권한이 헐거워도 사고 나기 전까진 조용하고, 청구서는 그냥 매달 조금씩 늘어납니다.
다행인 건, 면접관이 AWS 를 잘할 필요는 없다는 거예요. 필요한 건 “이 사람이 진짜 해봤는지” 를 가려내는 도구고, 그건 기술 지식 없이도 꽤 정확하게 됩니다. 이 시리즈는 그 도구를 만드는 글이에요.
💡 이 글에서 다루는 것
- 15분이면 되는 AWS 지도 — 계정 · 리전 · 가용영역 · 서비스 6칸
- “AWS 잘하는 사람” 이라는 말이 의미 없는 이유 — 네 갈래로 먼저 가르기
- 경력기술서 읽는 법 — 동사를 보세요
- 자격증이 증명하는 것과 절대 증명하지 못하는 것
- 시니어를 가르는 3축 — 규모 · 장애 · 트레이드오프
- 어느 포지션에나 통하는 공통 오프닝 질문 5개 + 채점 포인트
- 면접관이 하면 안 되는 것 (특히 AWS 를 모를 때)
1. 15분이면 되는 AWS 지도
후보자의 말을 알아들으려면 최소한의 지형은 필요해요. 딱 이만큼이면 됩니다.
클라우드가 뭐냐면
남의 데이터센터를 API 로 빌려 쓰는 것이에요. 예전엔 서버를 사서 전산실에 넣고 전원을 꽂았다면, 이제는 “서버 하나 주세요” 를 코드 한 줄로 요청하고 분 단위로 돈을 냅니다. AWS 는 그걸 파는 가게 중 가장 큰 곳이고요.
이 한 문장에서 면접에 쓸 만한 게 두 개 나와요. 빌리는 거니까 언제든 반납할 수 있어야 하고(그래서 자동화가 중요), 쓴 만큼 내는 거니까 낭비가 그대로 돈(그래서 비용 감각이 실력의 일부)입니다.
계정 · 리전 · 가용영역
이 세 단어는 후보자가 무조건 씁니다. 뜻만 알아두세요.
| 용어 | 쉽게 말하면 | 면접에서 의미 |
|---|---|---|
| 계정 (Account) |
청구서와 권한의 최상위 울타리 | 회사가 계정을 몇 개 쓰는지가 조직 성숙도의 지표 |
| 리전 (Region) |
지리적 위치. 서울은 ap-northeast-2 |
어느 리전을 왜 골랐는지에 규제·지연시간 판단이 담김 |
| 가용영역 (AZ) |
리전 안의 물리적으로 떨어진 데이터센터 묶음 |
“멀티 AZ” 는 이중화의 최소 기본기 |
한 가지만 기억하세요. 가용영역이 다르면 건물이 다르고 전원이 다릅니다. 그래서 서버를 두 대 띄우더라도 같은 가용영역에 두면 정전 한 번에 같이 죽어요. 후보자가 “멀티 AZ 로 깔았다” 고 하면 그건 “건물 두 곳에 나눠 뒀다” 는 뜻이에요.
서비스는 6칸으로 충분해요
AWS 서비스는 200 개가 넘지만, 면접에서 실제로 등장하는 건 대부분 이 표 안에 있어요.
| 칸 | 대표 서비스 | 하는 일 |
|---|---|---|
| 컴퓨트 | EC2, Lambda, ECS, EKS, Fargate |
코드가 실제로 돌아가는 곳 |
| 네트워크 | VPC, ALB/NLB, Route 53, CloudFront |
트래픽이 오가는 길과 울타리 |
| 스토리지 | S3, EBS, EFS | 파일과 디스크 |
| 데이터베이스 | RDS, Aurora, DynamoDB, Redshift |
정형 데이터 보관 |
| 보안 · 관리 | IAM, KMS, CloudTrail, CloudWatch |
누가 뭘 할 수 있나, 무슨 일이 있었나 |
| 데이터 · AI | Glue, Athena, Kinesis, Bedrock |
데이터 가공과 모델 호출 |
💡 후보자가 이 표에 없는 이름을 대도 당황하지 마세요. 오히려 좋은 기회예요. “그건 이 중에 어느 역할에 해당하나요?” 라고 물으면, 설명을 잘하는 사람인지 아닌지가 바로 드러납니다. 시니어는 모르는 사람 눈높이로 번역하는 걸 잘해요. 그게 실제 업무에서 매일 하는 일이거든요.
2. “AWS 잘하는 사람” 은 존재하지 않아요
이게 이 시리즈의 출발점이에요. AWS 는 너무 넓어서 한 사람이 전 영역을 다루지 않습니다. 자기소개서에 “AWS 전문가” 라고 쓰여 있어도, 실제로는 아래 네 갈래 중 하나에 무게중심이 있어요.
| 갈래 | 이 사람이 매일 하는 일 | 자주 쓰는 것 | 이 시리즈 |
|---|---|---|---|
| 인프라 · 아키텍트 |
어떻게 배치할지 설계, 마이그레이션, 용량·비용 |
VPC, EC2, RDS, ELB |
2편 |
| DevOps · 플랫폼 |
배포 자동화, 클러스터 운영, 장애 대응 |
Terraform, EKS, CI/CD, 관측성 |
3편 |
| 보안 · 거버넌스 |
권한 설계, 키 관리, 로그·탐지, 규제 대응 |
IAM, KMS, CloudTrail, Config |
4편 |
| 데이터 · AI 플랫폼 |
파이프라인, 분석 환경, 모델 서빙 |
S3, Glue, Redshift, Bedrock |
5편 |
물론 시니어는 두세 갈래를 걸칩니다. 하지만 깊이가 있는 건 보통 하나예요. 그래서 면접 초반 10분은 “이 사람의 무게중심이 어디인지” 를 가르는 데 쓰는 게 효율적이에요.
이걸 가르는 가장 간단한 질문은 이거예요.
“최근 1년 동안 가장 시간을 많이 쓴 일이 뭐였나요? 하루 일과를 기준으로 말씀해 주세요.”
“설계 리뷰와 문서 작업” 이면 아키텍트, “배포 파이프라인이랑 알람 대응” 이면 DevOps, “권한 요청 처리랑 감사 준비” 면 보안, “파이프라인 실패 잡고 쿼리 최적화” 면 데이터예요. 자기소개서 문구보다 하루 일과가 훨씬 정직합니다.
⚠️ 채용 공고에 네 갈래를 다 적어놓고 “다 되는 사람” 을 찾는 조직이 많아요. 그런 사람은 거의 없고, 있다고 주장하면 오히려 의심해야 합니다. 공고 단계에서 무게중심을 정하고 들어가세요. 나머지는 “협업 가능한 수준” 이면 충분해요.
3. 경력기술서 읽는 법 — 동사를 보세요
기술을 몰라도 이력서에서 신호를 꽤 뽑을 수 있어요. 명사(서비스 이름)가 아니라 동사를 보면 됩니다.
| 이력서 문구 | 실제로는 | 되물어야 할 질문 |
|---|---|---|
| “AWS 환경 구축” | 범위가 완전히 불명확. 계정 하나 만든 것도 구축이라고 씁니다 |
“구축 시작 시점과 완료 시점에 각각 서버가 몇 대였나요?” |
| “인프라 운영” | 유지보수만 했을 수도, 설계까지 했을 수도 |
“그 기간에 직접 바꾼 것 중 가장 큰 게 뭐였나요?” |
| “클라우드 전환 참여” | 참여의 폭이 0 에서 100 까지 |
“본인이 없었으면 안 됐을 일 하나만 꼽아주세요” |
| “비용 최적화 수행” | 인스턴스 하나 줄인 것도 최적화라고 씁니다 |
“월 얼마에서 얼마가 됐나요?” |
| “대용량 트래픽 처리” | 대용량의 기준이 없음 | “피크 기준 초당 요청 수가 얼마였나요?” |
패턴이 보이시죠. 되물음은 전부 숫자를 요구하는 형태예요. 기술 지식이 없어도 숫자는 검증할 수 있고, 진짜 해본 사람은 숫자를 기억합니다.
한 가지 더 체크할 게 있어요. 이력서에 실패나 사고가 한 줄도 없으면 이상한 겁니다. 5년, 10년 인프라를 만졌는데 아무 일도 없었을 리 없어요. 없다면 (a) 실제로 책임 있는 자리에 없었거나 (b) 실패를 학습으로 정리하는 습관이 없거나 둘 중 하나입니다. 둘 다 시니어로는 곤란해요.
4. 자격증 — 뭘 증명하고 뭘 증명 못 하나
AWS 자격증은 종류가 많아서 헷갈리는데, 면접에서 실제로 의미 있는 건 몇 개 안 돼요.
| 자격증 | 흔한 표기 | 증명하는 것 |
|---|---|---|
| Solutions Architect Associate |
SAA | 서비스 이름과 기본 조합을 안다 |
| Solutions Architect Professional |
SAP | 복잡한 조합·제약을 문서 수준으로 안다 |
| DevOps Engineer Professional |
DOP | 배포·자동화 영역의 어휘를 안다 |
| Security Specialty |
SCS | 권한·암호화·감사 영역의 어휘를 안다 |
그리고 이게 핵심이에요.
✅ 자격증이 증명하는 것 — 어휘를 안다. 문서를 읽고 시험을 통과할 성실함이 있다. 팀에서 대화가 통한다.
🚨 자격증이 증명하지 못하는 것 — 새벽 3시에 서비스가 죽었을 때 뭘 하는지. 청구서를 보고 낭비를 찾아내는지. 팀을 설득해 설계를 바꿔본 적이 있는지.
실전 감각으로 두 가지만 기억하세요.
- 시니어인데 자격증이 없다 → 전혀 문제 없어요. 오히려 흔합니다. 현업이 바쁘면 시험 볼 시간이 없어요.
- 자격증은 많은데 규모 숫자를 못 댄다 → 이건 위험 신호예요. 지식은 있는데 책임져 본 적이 없을 가능성이 큽니다.
5. 시니어를 가르는 3축
AWS 를 몰라도 채점할 수 있는 축이 딱 세 개 있어요. 이 시리즈 전체가 이 세 축 위에서 굴러갑니다.
축 1 — 규모: 숫자로 말하는가
진짜 운영해본 사람은 자기 환경을 숫자로 기억해요. 계정 몇 개, 서버 몇 대, 월 비용 얼마, 피크 트래픽 얼마. 물어보지 않아도 자연스럽게 나옵니다.
| 👍 좋은 신호 | ⚠️ 걸리는 신호 |
|---|---|
| “계정 12개, EC2 는 상시 80대쯤, 월 청구서가 4천만 원 언저리였어요” |
“꽤 컸어요”, “엔터프라이즈 규모였습니다” |
| 숫자가 애매할 때 “정확히는 기억 안 나는데 대략 이 정도” 라고 범위를 말함 |
물어봐도 계속 형용사로만 답함 |
축 2 — 장애: 아프게 배운 게 있는가
인프라 시니어의 실력은 대부분 사고에서 만들어져요. 그래서 장애 이야기를 시켜보면 경력의 진짜 밀도가 드러납니다.
| 👍 좋은 신호 | ⚠️ 걸리는 신호 |
|---|---|
| 시간 순서대로 이야기함. “몇 시에 알람이 왔고, 처음엔 X 를 의심했는데 아니었고” |
원인부터 결론으로 바로 감. 탐색 과정이 없음 |
| 자기 실수를 담담히 인정함 | 전부 남 탓 또는 “AWS 장애였어요” |
| 그 후에 뭘 바꿨는지가 있음 | 복구했다는 얘기로 끝 |
💡 여기서 면접관이 AWS 를 몰라도 되는 이유가 나와요. 이야기의 구조만 보면 되거든요. 진짜 겪은 사람의 장애 회고에는 막다른 골목과 잘못된 가설이 반드시 들어 있습니다. 매끄럽게 정리된 이야기는 오히려 책에서 읽은 것일 확률이 높아요.
축 3 — 트레이드오프: 포기한 것을 말하는가
시니어와 미들의 가장 큰 차이예요. 미들은 “이게 좋아서 이걸 썼습니다” 라고 말하고, 시니어는 “이걸 얻는 대신 저걸 포기했습니다” 라고 말합니다.
| 👍 좋은 신호 | ⚠️ 걸리는 신호 |
|---|---|
| “관리형을 써서 운영 부담은 줄었는데, 세부 튜닝을 못 하는 건 감수했어요” |
“가장 좋은 방법이라 그렇게 했습니다” |
| “지금 다시 하면 다르게 할 것 같아요” 가 자연스럽게 나옴 |
모든 과거 결정이 옳았음 |
| 비용·시간·인력 제약을 언급 | 기술적 우수성만 이야기 |
6. 공통 오프닝 질문 5개
네 갈래 어디든 통하는 질문이에요. 면접 앞부분 15~20분에 쓰세요. 각 질문마다 왜 묻는지와 채점 포인트를 같이 적었습니다.
Q1. 지금까지 다룬 AWS 환경 중 가장 컸던 걸 숫자로 설명해 주세요
계정 수, 서버 대수, 월 비용, 사용자 수 아무거나 좋아요.
- 왜 묻나 — 축 1(규모)을 바로 재는 질문이에요. 그리고 이 답이 이후 모든 질문의 기준선이 됩니다. 서버 5대 환경에서 온 사람에게 500대 운영 질문을 하는 건 의미가 없어요.
- 👍 좋은 답 — 숫자가 여러 종류로 나오고, 그 숫자들이 서로 앞뒤가 맞아요. 서버 80대인데 월 비용이 4천만 원대라면 자연스럽습니다.
- ⚠️ 걸리는 답 — “대규모였습니다” 로 끝나거나, 숫자가 이상하게 큽니다. 서버 5대인데 월 3억이라고 하면 뭔가 잘못 기억하는 거예요.
Q2. 그중에서 본인이 직접 손댄 부분과 팀이 한 부분을 나눠주세요
- 왜 묻나 — 이력서에서 가장 자주 부풀려지는 지점이에요. 팀 성과를 개인 이력에 그대로 옮기는 건 흔한 일이라 나쁜 의도라고 볼 것까진 없지만, 구분은 해야 합니다.
- 👍 좋은 답 — 경계를 스스로 명확히 그어요. “네트워크 설계는 제가 했고, 애플리케이션 쪽 배포는 다른 팀이었습니다.” 남의 공을 자기 것으로 가져가지 않는 사람은 대체로 팀에서도 안전해요.
- ⚠️ 걸리는 답 — 모든 걸 “제가 주도했습니다” 로 답합니다. 또는 반대로 계속 “저희 팀이” 라고만 말해서 본인 기여가 끝까지 안 보여요.
Q3. 그 환경의 AWS 청구서에서 가장 큰 항목 세 개는 뭐였나요
- 왜 묻나 — 이게 제가 생각하는 가장 가성비 좋은 질문이에요. 청구서를 실제로 열어본 사람만 답할 수 있거든요. 그리고 클라우드에서 비용은 설계의 결과라서, 이 답 하나에 아키텍처가 통째로 딸려 나옵니다.
- 👍 좋은 답 — 즉답이 나오고, 순위와 대략적인 비중까지 말해요. “EC2 가 절반 넘고, 그다음이 RDS, 세 번째가 의외로 데이터 전송료였어요” 같은. 특히 데이터 전송료나 NAT 게이트웨이를 언급하면 좋은 신호예요. 실제로 청구서를 뜯어본 사람만 아는 항목이거든요.
- ⚠️ 걸리는 답 — “비용은 다른 팀에서 봤습니다” 로 끝냅니다. 시니어라면 최소한 관심은 있어야 해요.
Q4. 새벽에 깨서 대응한 장애 하나만 처음부터 끝까지 이야기해 주세요
- 왜 묻나 — 축 2(장애). 그리고 이 질문은 후보자가 이야기를 얼마나 잘 구성하는지도 같이 봅니다. 장애 회고는 실무에서 계속 써야 하는 문서예요.
- 👍 좋은 답 — 시간 순서, 잘못 짚었던 가설, 최종 원인, 그리고 재발 방지로 뭘 바꿨는지가 다 들어 있어요. 자기 실수를 말하는 데 방어적이지 않습니다.
- ⚠️ 걸리는 답 — 겪은 장애가 없다고 합니다. 또는 원인이 항상 외부(AWS, 다른 팀, 벤더)예요.
💡 꼬리 질문 하나만 준비하세요. — “그걸 미리 막을 수 있었을까요?” 이 질문에 “네, 사실 그 알람을 진작 걸었어야 했어요” 라고 답하는 사람이 시니어예요. “아뇨, 예측 불가능한 일이었습니다” 만 반복하면 회고 습관이 없는 겁니다.
Q5. AWS 를 쓰면서 가장 불편했던 점 / 후회한 선택은 뭔가요
- 왜 묻나 — 축 3(트레이드오프). 도구에 대한 비판적 거리감이 있는지 봅니다. 오래 쓴 사람은 반드시 불만이 있어요.
- 👍 좋은 답 — 구체적인 불편을 대고, 그걸 어떻게 우회했는지까지 말해요. “그 서비스는 리전 간 복제가 늦어서 결국 직접 짰습니다” 같은.
- ⚠️ 걸리는 답 — “딱히 없습니다, AWS 는 다 좋아요.” 이건 깊게 안 써봤다는 뜻이거나, 면접에서 부정적으로 보일까 봐 방어하는 거예요. 후자면 한 번 더 편하게 물어봐 주세요.
7. 면접관이 하면 안 되는 것
AWS 를 모르는 면접관이 특히 빠지기 쉬운 함정들이에요.
① 서비스 이름 퀴즈
“S3 의 스토리지 클래스 종류를 다 말해보세요” 같은 질문은 검색하면 나오는 걸 묻는 거예요. 후보자가 못 맞혀도 실력과 상관없고, 맞혀도 아무것도 증명하지 못합니다. 게다가 이런 질문을 하면 좋은 후보자가 회사를 낮게 평가해요. 면접은 양방향이에요.
② 준비한 정답지에 맞춰 채점하기
어디서 받은 질문지에 모범답안이 붙어 있으면, 후보자가 그것과 다르게 답할 때 틀렸다고 판단하기 쉬워요. 그런데 인프라 설계는 정답이 하나가 아닙니다. 제약 조건이 다르면 답이 달라져요. 그래서 이 시리즈는 모범답안 대신 채점 포인트로 씁니다.
③ 못 알아들었는데 고개만 끄덕이기
가장 흔하고 가장 아까운 실수예요. 모르는 답이 나오면 이렇게 되물으면 됩니다.
- “그걸 안 했다면 어떤 문제가 생겼을까요?” — 필요성을 스스로 설명하게 만듭니다.
- “그때 다른 선택지는 뭐가 있었나요?” — 대안을 검토했는지 드러납니다.
- “지금 다시 한다면 똑같이 하실 건가요?” — 축 3 을 정면으로 겨냥해요.
이 세 마디는 어떤 기술 답변 뒤에도 붙일 수 있고, 셋 다 AWS 지식이 없어도 답의 질을 판단할 수 있게 해줍니다. 진짜 해본 사람은 세 질문 모두에 구체적으로 답하고, 외운 사람은 세 번째에서 반드시 막혀요.
④ 면접관이 아는 척하기
후보자는 금방 알아챕니다. 차라리 “저는 AWS 를 깊게 알지는 못해요. 팀에 필요한 걸 판단하려는 거라, 최대한 쉽게 설명해 주시면 좋겠습니다” 라고 먼저 말하는 게 훨씬 낫습니다. 그러면 설명 능력까지 덤으로 볼 수 있어요. 실제 업무에서 이 사람은 비개발자 임원에게 클라우드 예산을 설명해야 할 겁니다.
8. 다음 편부터의 로드맵
여기까지가 공통 도구예요. 이제 갈래별로 들어갑니다. 각 편은 똑같이 배경 설명 → 질문 → 채점 포인트 순서로 되어 있어서, 면접 직전에 해당 편 하나만 읽고 들어가도 됩니다.
| 편 | 다루는 것 | 이럴 때 읽으세요 |
|---|---|---|
| 2편 | VPC · 이중화 · 마이그레이션 · 비용 최적화 |
시스템을 새로 설계하거나 온프렘에서 옮겨야 할 때 |
| 3편 | IaC · CI/CD · EKS 운영 · 관측성 · 온콜 |
이미 있는 환경을 안정적으로 굴려야 할 때 |
| 4편 | IAM · 키 관리 · 감사 로그 · 금융권 규제 |
규제 산업이거나 보안 리뷰를 통과해야 할 때 |
| 5편 | 데이터 레이크 · 분석 · Bedrock + 60분 진행 시나리오 |
데이터/AI 조직이거나 면접 진행표가 필요할 때 |
마지막 편 끝에 60분 면접 시간 배분표와 레드 플래그 정리를 붙여뒀어요. 시리즈를 다 읽을 시간이 없으면 1편(지금 글)과 5편 뒷부분만 봐도 면접은 굴러갑니다.
일단 오늘은 여기까지…..
다음 글에서는 인프라·아키텍트 갈래를 파볼게요. VPC 가 뭔지부터 시작해서, 이중화 설계와 비용 함정까지 면접관 눈높이로 정리해 보겠습니다.
