(2/5) 클라우드 인프라·아키텍트 면접 — VPC 부터 비용까지 뭘 물어볼까
🧭 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
인프라·아키텍트 갈래는 “어떻게 배치할지 결정하는 사람” 이에요. 서버를 몇 대 어디에 두고, 죽으면 어떻게 살리고, 그 결과 청구서가 얼마가 되는지를 책임집니다.
이 갈래는 면접에서 가장 판단하기 어려워요. 설계는 눈에 안 보이고, 잘된 설계는 조용히 잘 돌아가서 티가 안 나거든요. 그래서 결과 대신 판단의 흔적을 봐야 합니다. 무엇을 고민했고, 무엇을 포기했고, 지금 다시 하면 뭘 바꿀지요.
그 판단을 알아들으려면 배경 지식이 조금 필요해요. 이 글의 절반은 그 배경 설명이고, 나머지 절반이 질문입니다. 배경 부분은 후보자와 같은 수준으로 아는 게 목표가 아니라 후보자가 하는 말을 알아듣고 되물을 수 있을 정도가 목표예요.
💡 이 글에서 다루는 것
- VPC · 서브넷 · 보안 그룹 — 네트워크 기본기를 5분에
- 이중화와 재해복구 — 멀티 AZ, RTO/RPO, DR 4단계
- 컴퓨트 선택지 — EC2 · 컨테이너 · 서버리스의 진짜 차이
- 데이터베이스와 마이그레이션 — 컷오버가 왜 어려운가
- 돈이 새는 3대 구멍 — NAT · 데이터 전송료 · 잊힌 리소스
- 질문 10개 + 채점 포인트
- 면접 직전 5분 요약
1. 배경 — VPC 는 회사가 빌린 땅이에요
AWS 에 서버를 띄우려면 먼저 네트워크가 있어야 해요. 그게 VPC(Virtual Private Cloud) 입니다. 남의 데이터센터 안에 우리 회사만 쓰는 사설 네트워크를 그어놓은 거예요.
이 땅을 다시 구획으로 나눈 게 서브넷이고, 서브넷은 크게 두 종류예요.
| 구분 | 인터넷과의 관계 | 여기 두는 것 |
|---|---|---|
| 퍼블릭 서브넷 | 인터넷에서 직접 들어올 수 있음 |
로드밸런서, 외부 접점 |
| 프라이빗 서브넷 | 인터넷에서 직접 못 들어옴 |
애플리케이션 서버, 데이터베이스 |
여기서 면접에 바로 쓸 수 있는 규칙이 하나 나와요.
🚨 데이터베이스는 프라이빗 서브넷에 있어야 합니다. 이건 취향이 아니라 기본기예요. 후보자가 “DB 를 퍼블릭에 뒀다” 고 하면 반드시 이유를 물어보세요. 정당한 이유가 있는 경우도 아주 드물게 있지만, 대부분은 그냥 편해서 그렇게 한 겁니다.
그럼 프라이빗 서브넷에 있는 서버는 인터넷을 아예 못 쓰냐면, 그건 아니에요. NAT 게이트웨이라는 걸 통해 나가기만 할 수 있습니다. 나가는 건 되고 들어오는 건 안 되는 일방통행 문이에요. 이 NAT 게이트웨이는 뒤에 비용 이야기에서 다시 나옵니다. 조용히 돈을 많이 먹는 물건이거든요.
방화벽 역할을 하는 건 두 가지예요.
| 이름 | 붙는 위치 | 성격 |
|---|---|---|
| 보안 그룹 (Security Group) |
서버 한 대 한 대에 | 허용만 적음. 나간 요청의 응답은 자동 허용 |
| 네트워크 ACL (NACL) |
서브넷 전체에 | 거부도 적을 수 있음. 응답도 따로 열어야 함 |
실무에서는 보안 그룹을 주로 쓰고 NACL 은 거의 안 건드려요. 그래서 후보자가 NACL 이야기를 길게 하면 오히려 살짝 갸웃할 수 있습니다. 물론 규제 환경에서는 NACL 로 이중 방어를 요구하기도 해서, 그 맥락이면 정상이에요.
2. 배경 — 이중화와 재해복구
여기가 인프라 면접의 핵심이에요. “죽으면 어떻게 되나” 를 어디까지 생각해뒀는지가 실력이거든요.
멀티 AZ 와 멀티 리전
1편에서 가용영역(AZ)은 “같은 리전 안의 다른 건물” 이라고 했어요. 그래서 이중화에는 두 단계가 있습니다.
| 단계 | 막아주는 것 | 비용과 난이도 |
|---|---|---|
| 멀티 AZ (건물 두 곳) |
정전, 화재, 장비 고장 |
거의 필수. 비용 부담 적음 |
| 멀티 리전 (도시 두 곳) |
리전 전체 장애, 지역 재해 |
비용·복잡도가 확 뜁니다 |
대부분의 회사는 멀티 AZ 면 충분해요. 후보자가 멀티 리전을 당연하게 이야기하면 “그게 정말 필요한 요구사항이었나요?” 라고 물어보세요. 필요 없는데 한 거면 돈을 태운 거고, 필요해서 한 거면 이유를 잘 설명할 겁니다.
RTO 와 RPO — 이 두 단어만 알면 돼요
재해복구 이야기에 반드시 나오는 약어예요. 뜻은 아주 단순합니다.
| 약어 | 뜻 | 예시 |
|---|---|---|
| RTO (복구 목표 시간) |
얼마 만에 다시 켜야 하나 |
“4시간 안에 서비스 재개” |
| RPO (복구 목표 시점) |
데이터를 얼마까지 잃어도 되나 |
“최대 15분 치 데이터 손실 허용” |
이 두 숫자가 정해지면 설계가 자동으로 따라와요. RPO 가 0 에 가까우면 실시간 복제가 필요하고, 그러면 돈이 많이 듭니다. RTO 가 하루여도 되면 백업에서 복원해도 돼요.
그래서 후보자에게 RTO/RPO 를 물었을 때 숫자가 바로 나오는지가 좋은 판별기예요. 진짜 설계해본 사람은 이 숫자를 사업부와 협의한 기억이 있습니다.
재해복구 4단계
DR 전략은 보통 네 가지로 나눠요. 오른쪽으로 갈수록 빠르고 비쌉니다.
| 전략 | 평소 상태 | RTO 감각 |
|---|---|---|
| 백업 & 복구 | 백업만 있음 | 몇 시간 ~ 하루 |
| 파일럿 라이트 | 최소한만 켜둠 (DB 복제 정도) |
몇십 분 ~ 몇 시간 |
| 웜 스탠바이 | 축소판이 항상 돌아감 |
몇 분 ~ 몇십 분 |
| 액티브-액티브 | 양쪽 다 실서비스 중 |
거의 0 |
💡 면접 팁 — “어떤 전략을 썼나요?” 보다 “그걸 실제로 훈련해본 적 있나요?” 가 훨씬 좋은 질문이에요. 문서상 DR 계획은 다들 있어요. 실제로 전환 훈련을 돌려본 조직은 훨씬 적습니다. 해본 사람은 반드시 “해보니까 안 되던 게 있었다” 는 이야기를 갖고 있어요.
3. 배경 — 컴퓨트, 뭘 골랐고 왜 골랐나
코드가 돌아갈 곳을 고르는 문제예요. 크게 세 가지고, 오른쪽으로 갈수록 AWS 가 더 많이 대신 해줍니다.
| 방식 | 대표 | 우리가 하는 일 | 잘 맞는 경우 |
|---|---|---|---|
| 가상 서버 | EC2 | OS 패치, 스케일링, 모니터링 전부 |
기존 시스템 그대로 옮길 때 |
| 컨테이너 | ECS, EKS | 클러스터 운영, 배포 파이프라인 |
서비스가 여러 개고 배포가 잦을 때 |
| 서버리스 | Lambda | 코드만 | 이벤트성 작업, 트래픽 기복이 클 때 |
여기서 중요한 건 “뭐가 제일 좋냐” 에 답이 없다는 거예요. 조직 인력과 시스템 성격에 따라 다릅니다. 그래서 이 영역의 질문은 항상 이 형태여야 해요.
“왜 그걸 골랐나요? 다른 선택지는 뭐였고, 왜 접었나요?”
특히 EKS(쿠버네티스) 를 쓴다고 하면 한 번 더 파세요. 쿠버네티스는 강력하지만 운영 인력을 꽤 먹는 물건이에요. 3명짜리 팀이 EKS 를 굴리고 있다면 그럴 만한 이유가 있어야 합니다. “요즘 다들 쓰니까” 로 도입한 조직이 실제로 많아요.
4. 배경 — 데이터베이스와 마이그레이션
관리형이 기본이에요
AWS 에서 DB 를 쓰는 방법은 두 가지예요. EC2 에 직접 설치하거나, RDS/Aurora 같은 관리형 서비스를 쓰거나.
요즘은 특별한 이유가 없으면 관리형입니다. 백업·패치·장애 조치를 AWS 가 해주거든요. 그래서 후보자가 “EC2 에 직접 DB 를 올려서 운영했다” 고 하면 이유를 물어보세요. 라이선스나 특수 설정 때문인 정당한 경우도 있고, 그냥 예전 방식을 그대로 가져온 경우도 있어요.
알아둘 개념은 두 개예요.
- 장애 조치(Failover) — 주 DB 가 죽으면 대기 중이던 복제본이 승격돼서 서비스를 이어받는 것. 멀티 AZ 로 깔면 이게 자동으로 됩니다.
- 읽기 복제본(Read Replica) — 읽기 전용 사본. 조회 부하를 분산할 때 씁니다. 쓰기는 못 해요.
마이그레이션 — 컷오버가 진짜 어려운 부분
온프렘 DB 를 AWS 로 옮기는 일은 인프라 아키텍트의 대표 과제예요. 그런데 데이터를 복사하는 건 쉬운 편이고, 어려운 건 “언제 스위치를 넘기냐” 입니다.
서비스를 멈추고 옮기면 간단하지만 중단 시간이 생기고, 안 멈추고 옮기려면 옮기는 동안 계속 쌓이는 변경분을 따라잡아야 해요. AWS 에서는 보통 DMS(Database Migration Service) 로 초기 복사 후 변경분을 계속 따라 붙이는 방식(CDC)을 씁니다.
📎 이 주제를 실제로 해본 기록이 블로그에 있어요. 내부망 MSSQL 을 AWS RDS 로 옮기기와 DMS CDC 무중단 컷오버 편을 보시면, 면접에서 후보자가 무슨 이야기를 할지 미리 감을 잡을 수 있습니다. 컷오버 당일에 뭘 확인하고 뭘 되돌릴 준비를 해두는지가 경험의 밀도예요.
5. 배경 — 돈이 새는 3대 구멍
클라우드는 낭비가 그대로 매달 청구되는 구조라서, 비용 감각은 아키텍트 실력의 일부예요. 후보자가 이 셋 중 하나라도 자연스럽게 언급하면 실제로 청구서를 뜯어본 사람입니다.
① NAT 게이트웨이
프라이빗 서브넷에서 인터넷으로 나가는 문이라고 했죠. 이게 켜둔 시간에 따라 돈을 받고, 통과한 데이터 양에 따라 또 받아요. 트래픽이 많은 시스템에서는 조용히 월 수백만 원이 되기도 합니다.
줄이는 방법은 있어요. AWS 내부 서비스(S3 등)로 가는 트래픽은 VPC 엔드포인트를 두면 NAT 를 안 거치게 할 수 있습니다. 후보자가 이 단어를 쓰면 좋은 신호예요.
② 데이터 전송료
AWS 는 데이터가 나가고 건너갈 때 돈을 받아요. 세 종류를 구분하면 됩니다.
| 종류 | 요금 감각 |
|---|---|
| 같은 가용영역 안 | 대체로 무료 |
| 가용영역을 건너갈 때 | 유료. 티끌 모아 태산 |
| 인터넷으로 나갈 때 | 가장 비쌈 |
가용영역 간 전송료는 특히 함정이에요. 이중화하겠다고 서버를 나눠 뒀는데, 그것들이 서로 계속 통신하면 그게 전부 과금됩니다. 그래서 CDN(CloudFront)을 앞에 두는 것도 성능뿐 아니라 비용 대책이에요.
📎 CDN 이 뭔지 배경이 필요하면 CDN이란 — CloudFront 와 엣지 캐싱 편이 도움이 될 거예요.
③ 잊힌 리소스
아무도 안 쓰는데 돈은 나가는 것들이에요. 안 붙은 EBS 볼륨, 몇 년 치 쌓인 스냅샷, 아무 데도 안 붙은 탄력적 IP, 트래픽 없는 로드밸런서, 개발자가 테스트하고 안 지운 인스턴스. 정리 프로세스가 있는 조직인지 물어볼 만합니다.
할인 수단
마지막으로 요금 자체를 깎는 방법이에요. 이름만 알아두세요.
| 수단 | 개념 | 감각 |
|---|---|---|
| 온디맨드 | 그냥 쓰는 만큼 | 기준 가격 |
| RI / Savings Plans | 1~3년 쓰겠다고 약정하고 할인 |
상시 켜둘 워크로드에 필수 |
| 스팟 | AWS 의 남는 자원을 싸게. 갑자기 회수됨 |
배치·테스트 등 끊겨도 되는 일에 |
6. 질문 10개 + 채점 포인트
이제 질문이에요. 앞의 배경만 읽었으면 답을 다 알아들을 수 있습니다. 시니어 기준이고, 보통 이 중 5~6개면 60분 면접의 기술 파트가 채워져요.
Q1. 지금(또는 최근) 담당하신 시스템의 구조를 말로 설명해 주세요
화이트보드 없이, 저처럼 잘 모르는 사람에게 설명한다고 생각하고요.
- 왜 묻나 — 두 가지를 동시에 봅니다. 전체 구조를 머릿속에 갖고 있는지, 그리고 모르는 사람 눈높이로 번역할 수 있는지. 후자는 실무에서 매일 필요한 능력이에요.
- 👍 좋은 답 — 위에서 아래로 순서 있게 설명해요. “사용자 요청이 들어오면 → 어디를 거쳐서 → 어디에 저장됩니다.” 중간에 “여기는 좀 복잡한데 간단히 말하면” 처럼 눈높이를 조절합니다.
- ⚠️ 걸리는 답 — 서비스 이름만 나열해요. 또는 자기가 맡은 조각만 말하고 앞뒤를 모릅니다.
Q2. 서브넷을 어떻게 나누셨고, 데이터베이스는 어디에 뒀나요
- 왜 묻나 — 기본기 확인이에요. 그리고 이 답에서 그 조직의 보안 수준이 같이 드러납니다.
- 👍 좋은 답 — 퍼블릭/프라이빗을 나눈 이유를 말하고, DB 는 프라이빗에 있어요. 관리자 접속을 어떻게 하는지(배스천, 세션 매니저 등)까지 자연스럽게 이어집니다.
- ⚠️ 걸리는 답 — “다 퍼블릭에 뒀는데 보안 그룹으로 막았어요.” 안 되는 건 아니지만, 왜 그렇게 했는지 설명을 못 하면 그냥 편해서 그런 거예요.
Q3. 가용영역 하나가 통째로 죽으면 그 시스템은 어떻게 되나요
- 왜 묻나 — 이중화를 설계했는지와 검증했는지는 다른 문제예요. 이 질문은 후자를 겨냥합니다.
- 👍 좋은 답 — 구성요소별로 나눠서 답해요. “웹은 자동으로 남은 쪽이 받고, DB 는 페일오버에 1~2분 걸리고, 이 배치 작업은 수동 조치가 필요합니다.” 약한 고리를 스스로 아는 게 핵심 신호예요.
- ⚠️ 걸리는 답 — “멀티 AZ 라 괜찮습니다” 한 줄로 끝냅니다. 진짜 겪어본 사람은 절대 이렇게 짧게 답하지 않아요.
💡 꼬리 질문 — “그거 실제로 꺼보신 적 있나요?” 이 한마디에 답이 갈립니다.
Q4. RTO 와 RPO 목표가 얼마였고, 누가 정했나요
- 왜 묻나 — 숫자를 아는지, 그리고 그 숫자가 사업 요구에서 나왔는지 엔지니어가 임의로 정했는지를 봅니다. 후자면 시니어 레벨의 협업 경험이 부족한 거예요.
- 👍 좋은 답 — 숫자가 나오고, 그게 어디서 왔는지 말합니다. “결제는 RPO 0 을 요구받아서 동기 복제로 갔고, 로그성 데이터는 하루까지 허용됐어요” 처럼 데이터 종류별로 다르게 잡았으면 아주 좋아요.
- ⚠️ 걸리는 답 — 용어 자체가 낯설거나, “최대한 빨리요” 로 답합니다.
Q5. EC2 · 컨테이너 · 서버리스 중 무엇을 골랐고, 나머지는 왜 접었나요
- 왜 묻나 — 트레이드오프 축을 정면으로 겨냥하는 질문이에요.
- 👍 좋은 답 — 조직 상황을 근거로 댑니다. “운영 인력이 2명이라 EKS 는 부담이라고 판단했어요” 나 “배포가 하루 10번이라 컨테이너가 맞았습니다” 같은. 포기한 것을 같이 말하면 최고 점수예요.
- ⚠️ 걸리는 답 — “요즘 표준이라서”, “성능이 제일 좋아서” 처럼 근거가 일반론입니다.
Q6. 온프렘에서 옮겨본 경험이 있으면, 컷오버 당일 이야기를 해주세요
- 왜 묻나 — 마이그레이션은 계획보다 당일 대응이 실력이에요. 그리고 되돌릴 계획(롤백)을 준비했는지가 시니어의 표식입니다.
- 👍 좋은 답 — 시간 단위 계획이 있었고, 검증 항목이 있었고, 되돌릴 기준선(언제까지 안 되면 되돌린다) 이 정해져 있었어요. 실제로 예상 못 한 문제가 하나쯤 나왔다고 말합니다.
- ⚠️ 걸리는 답 — “깔끔하게 끝났습니다” 로만 답해요. 롤백 계획을 물었는데 생각해본 적 없다고 하면 큰 시스템은 못 맡깁니다.
Q7. 그 환경 청구서에서 큰 항목 세 개와, 줄이려고 하신 일을 말씀해 주세요
- 왜 묻나 — 1편의 공통 질문을 인프라 버전으로 심화한 거예요. 아키텍트에게 비용은 설계 결과물입니다.
- 👍 좋은 답 — 항목과 대략적 비중이 나오고, 줄인 결과를 숫자로 말해요. NAT 게이트웨이, 데이터 전송료, VPC 엔드포인트, Savings Plans 중 하나라도 나오면 진짜입니다.
- ⚠️ 걸리는 답 — “인스턴스 타입을 낮췄어요” 만 말합니다. 그것도 방법이긴 한데, 그것만 아는 건 얕아요.
Q8. 인스턴스 타입과 크기는 어떻게 정하셨나요
- 왜 묻나 — 클라우드에서 가장 흔한 낭비가 과다 할당이에요. 감으로 정하는지 데이터로 정하는지를 봅니다.
- 👍 좋은 답 — 처음엔 넉넉히 잡고, 지표(CPU·메모리·네트워크)를 보고 조정했다고 합니다. 부하 테스트를 언급하면 더 좋아요.
- ⚠️ 걸리는 답 — “기존 온프렘 스펙 그대로 옮겼습니다.” 실제로 아주 흔하고, 그래서 돈이 샙니다. 그걸 인지하고 있는지가 갈림길이에요.
Q9. 계정을 몇 개로 나눴고, 기준이 뭐였나요
- 왜 묻나 — 조직 성숙도를 재는 질문이에요. 계정 하나에 개발·운영을 다 넣는 건 작은 조직에선 자연스럽지만, 규모가 커지면 사고와 비용 추적 문제가 생깁니다.
- 👍 좋은 답 — 환경별(개발/스테이징/운영) 또는 조직별로 나눈 기준을 말하고, 그 이유(권한 사고 격리, 비용 귀속, 한도 관리)를 댑니다. Organizations, Control Tower, 랜딩 존 같은 단어가 나오면 큰 조직 경험이 있는 거예요.
- ⚠️ 걸리는 답 — “하나로 썼습니다” 인데 규모는 크다고 합니다. 앞의 규모 답변과 앞뒤가 안 맞는 신호예요.
Q10. 지금 그 시스템을 처음부터 다시 설계한다면 뭘 바꾸시겠어요
- 왜 묻나 — 이 시리즈에서 가장 좋은 질문 중 하나예요. 트레이드오프 축, 회고 습관, 최신 감각을 한 번에 봅니다. 그리고 외운 답으로는 절대 대응이 안 돼요.
- 👍 좋은 답 — 구체적인 후회가 있고, 왜 그때는 그렇게 했는지도 설명합니다. “그때는 급해서 이렇게 갔는데, 그게 나중에 이런 부채가 됐어요.”
- ⚠️ 걸리는 답 — “특별히 없습니다, 잘 설계했다고 생각해요.” 모든 시스템에는 후회가 있어요. 없다면 오래 운영해보지 않았거나 돌아보지 않는 겁니다.
7. 면접 직전 5분 요약
시간이 없을 때 이것만 들고 들어가세요.
꼭 물을 것 3개
- 담당 시스템 구조를 쉬운 말로 설명 (Q1)
- 가용영역 하나가 죽으면 어떻게 되나 + 실제로 꺼봤나 (Q3)
- 청구서 3대 항목과 줄인 방법 (Q7)
어떤 답에도 붙일 수 있는 세 마디
- “그걸 안 했으면 어떻게 됐을까요?”
- “그때 다른 선택지는 뭐였나요?”
- “지금 다시 하면 똑같이 하실 건가요?”
좋은 신호로 기억할 단어
NAT 게이트웨이 처리료 · 가용영역 간 데이터 전송료 · VPC 엔드포인트 · Savings Plans · RTO/RPO 를 데이터 종류별로 다르게 · 롤백 기준선 · 전환 훈련을 실제로 돌려봤다
레드 플래그
DB 가 퍼블릭 서브넷에 있는데 이유를 설명 못 함 · 규모를 형용사로만 말함 · 모든 과거 결정이 옳았음 · 롤백 계획을 생각해본 적 없음
일단 오늘은 여기까지…..
다음 글에서는 DevOps·플랫폼 엔지니어 갈래로 넘어갈게요. 만드는 사람이 아니라 굴리는 사람을 보는 눈이라, 질문의 결이 꽤 달라집니다.
← 이전 글: (1/5) AWS 전문가 면접, 뭘 물어야 하나 ｜ 다음 글 →: (3/5) DevOps·플랫폼 엔지니어 면접
