CD, EKS 운영을 캐묻기

August 5, 2026 10 분 소요

🧭 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

2편의 아키텍트가 만드는 사람이라면, 이번 편의 DevOps·플랫폼 엔지니어는 굴리는 사람이에요. 이미 있는 환경이 매일 안정적으로 돌아가게 하고, 개발자들이 하루에 몇 번씩 배포해도 사고가 안 나게 만드는 게 일입니다.

이 갈래는 면접에서 판별하기가 오히려 쉬운 편이에요. 운영은 흔적이 남거든요. 자동화를 어디까지 했는지, 알람이 몇 개인지, 새벽에 몇 번 깼는지는 다 숫자로 답할 수 있는 것들입니다. 그리고 이 숫자들은 지어내기가 어려워요. 하나를 지어내면 다른 숫자와 앞뒤가 안 맞거든요.

한 가지만 미리 말씀드리면, 이 갈래에서 가장 위험한 후보자는 “다 자동화돼 있었습니다” 라고만 말하는 사람이에요. 완벽하게 자동화된 환경은 없어요. 어딘가는 반드시 손이 갑니다. 그 손 가는 곳을 아는 사람이 실제로 운영한 사람이에요.

💡 이 글에서 다루는 것

인프라를 코드로 관리한다는 게 뭔지 — 상태 파일과 드리프트

배포 파이프라인 — CI/CD 와 배포 전략 3가지

쿠버네티스(EKS) — 왜 어렵고 뭐가 부담인가

관측성 — 로그·지표·추적, 그리고 알람 피로

온콜과 장애 회고 문화

질문 10개 + 채점 포인트

면접 직전 5분 요약

1. 배경 — 인프라를 코드로 관리한다는 것

왜 코드로 하나요

옛날 방식은 AWS 웹 콘솔에서 마우스로 클릭해서 서버를 만드는 거였어요. 문제는 세 가지예요. 똑같이 다시 못 만들고, 누가 뭘 바꿨는지 모르고, 개발 환경과 운영 환경이 미묘하게 달라집니다.

그래서 요즘은 인프라를 코드 파일로 적어두고, 그 파일을 실행해서 실제 자원을 만들어요. 이걸 IaC(Infrastructure as Code) 라고 합니다. 코드니까 깃에 올라가고, 리뷰를 받고, 되돌릴 수 있어요.

도구	성격
Terraform	가장 널리 쓰임. AWS 외 다른 곳도 관리 가능
CloudFormation	AWS 가 만든 것. AWS 안에서만
CDK	파이썬·타입스크립트 같은 프로그래밍 언어로 작성

셋 중 뭘 쓰든 상관없어요. 중요한 건 쓰긴 쓰는가, 그리고 얼마나 일관되게 쓰는가입니다.

상태 파일 — 이 단어 하나만 알면 돼요

Terraform 을 쓰면 상태 파일(state) 이라는 게 생겨요. “내가 만든 자원이 실제로 뭐가 있는지” 를 기록해둔 장부예요. 다음에 코드를 고쳐서 실행하면, Terraform 은 이 장부와 코드를 비교해서 차이만큼만 바꿉니다.

그래서 이 장부가 팀 운영의 급소예요.

이 파일이 개인 노트북에만 있으면 그 사람 말고는 아무도 인프라를 못 바꿔요.
두 사람이 동시에 실행하면 장부가 꼬여서 자원이 이상해집니다. 그래서 잠금(lock) 이 필요해요.
이 파일에는 비밀번호 같은 게 평문으로 들어갈 수 있어요. 그래서 암호화된 곳에 둬야 합니다.

실무 정답은 대체로 S3 에 상태 파일을 두고, 잠금을 걸고, 암호화하는 것이에요. 후보자가 이걸 술술 말하면 팀 단위로 운영해본 사람입니다.

💡 이게 이 편에서 가장 가성비 좋은 질문이에요. “Terraform 상태 파일은 어디에 두셨나요?” 한 줄로, 혼자 했는지 팀으로 했는지가 거의 다 드러납니다.

드리프트 — 코드와 실제가 어긋나는 것

급할 때는 결국 사람이 콘솔에 들어가서 손으로 고쳐요. 장애 중이면 당연한 일이고요. 문제는 그러고 나서 코드에 반영을 안 하면 코드와 실제가 어긋난다는 거예요. 이걸 드리프트라고 합니다.

다음번에 누가 코드를 실행하는 순간, Terraform 이 “어? 이거 코드에 없네” 하고 손으로 고친 걸 되돌려버려요. 새벽에 겨우 살려놓은 설정이 낮에 배포하면서 사라지는, 실제로 자주 있는 사고예요.

그래서 이 질문이 좋습니다.

“콘솔에서 급하게 고친 적 있으세요? 그다음엔 어떻게 하셨어요?”

“없습니다” 는 거짓말이거나 책임을 안 져본 거예요. “있죠. 그다음 날 코드에 반영했어요” 가 정답이고, 여기에 “그걸 놓쳐서 사고 난 적도 있어요” 까지 붙으면 진짜입니다.

2. 배경 — 배포 파이프라인

CI 와 CD

CI(지속적 통합) — 개발자가 코드를 합칠 때마다 자동으로 빌드하고 테스트하는 것.
CD(지속적 배포) — 그게 통과하면 자동으로 서버에 올리는 것.

AWS 안에서는 CodeBuild / CodePipeline 을 쓰기도 하고, 요즘은 GitHub Actions 를 쓰는 곳도 많아요. 어느 쪽이든 상관없고, 봐야 할 건 파이프라인 한 번 도는 데 몇 분 걸리는지와 몇 단계에 사람 승인이 끼는지입니다.

📎 AWS 도구 조합으로 실제 구성한 기록이 블로그에 있어요. CodeCommit·CodeBuild·ECR·EKS 자동 빌드와 CodeBuild 에서 kubectl 로 EKS 자동 배포 편을 훑어보면 후보자가 무슨 이야기를 할지 감이 잡힙니다.

배포 전략 3가지

새 버전을 어떻게 올리냐에 따라 위험도가 달라져요.

전략	방식	특징
롤링	서버를 몇 대씩 순차 교체	가장 흔함. 중간에 두 버전 공존
블루/그린	새 환경을 통째로 띄우고 트래픽을 한 번에 전환	롤백이 즉시. 비용이 잠깐 두 배
카나리	일부 트래픽만 새 버전으로 보내고 관찰	가장 안전. 지표 자동 판정이 필요

여기서도 정답은 없어요. 다만 “우리는 롤링만 씁니다” 인데 배포 사고가 잦다면 뭔가 안 맞는 거고, “카나리를 씁니다” 인데 판정 지표가 뭔지 못 말한다면 이름만 아는 거예요.

롤백이 진짜 실력이에요

배포는 다들 합니다. 되돌리는 게 어려워요. 특히 데이터베이스 스키마가 함께 바뀌었으면 코드만 되돌린다고 해결이 안 돼요.

💡 “배포하고 나서 문제가 생기면 되돌리는 데 몇 분 걸리나요?” — 이 질문에 숫자가 나오면 실제로 되돌려본 사람이에요. “되돌릴 일이 없었습니다” 는 좋은 답이 아닙니다.

3. 배경 — 쿠버네티스(EKS)

왜 쓰고 뭐가 부담인가

컨테이너를 여러 대 서버에 알아서 배치하고, 죽으면 다시 띄우고, 트래픽을 나눠주는 도구예요. AWS 의 관리형 버전이 EKS 입니다.

강력하지만 운영 부담이 실제로 큽니다. 면접에서 이 부담을 감당해본 사람인지 보려면 아래 세 가지를 물으면 돼요.

① 버전 업그레이드
쿠버네티스는 새 버전이 자주 나오고, 지원 기간이 지나면 강제로 올려야 해요. 이게 평범한 운영 팀에게 가장 아픈 일입니다. 업그레이드하면서 쓰던 기능이 없어지기도 하고, 부가 도구들도 같이 맞춰야 하거든요. 업그레이드를 몇 번 해봤는지가 EKS 경험의 진짜 척도예요.

② 오토스케일링이 두 층이라는 것
헷갈리기 쉬운데 층이 두 개예요.

층	무엇을 늘리나	도구
위층	컨테이너(파드) 개수	HPA
아래층	서버(노드) 개수	Cluster Autoscaler, Karpenter

컨테이너를 늘리랬는데 그걸 얹을 서버가 없으면 아무 일도 안 일어나요. 그래서 두 층을 같이 봐야 하고, 이 얘기를 자연스럽게 하는 후보자는 실제로 스케일 사고를 겪은 사람입니다.

③ 네트워크가 어렵다는 것
쿠버네티스 안의 네트워크는 AWS 네트워크 위에 한 겹 더 얹혀 있어서 헷갈립니다. IP 가 모자라는 사고도 흔해요.

📎 EKS 를 실제로 굴리며 부딪힌 기록으로는 EKS 파드 고정 IP 와 NLB 서비스 편이 있어요. “왜 파드 IP 가 계속 바뀌는데 방화벽은 고정 IP 를 요구하나” 같은 현실 문제를 볼 수 있습니다.

⚠️ 그리고 이 질문을 꼭 해보세요. “팀 인원이 몇 명인데 EKS 를 쓰셨나요?” 인원이 적은데 쿠버네티스를 굴리고 있다면, 그럴 만한 이유를 설명할 수 있어야 해요. 못 하면 유행을 따라간 것이고, 그건 앞으로도 반복될 판단 습관이에요.

4. 배경 — 관측성

“모니터링” 을 요즘은 관측성(observability) 이라고 부르는데, 실무에서는 세 가지 데이터를 말해요.

종류	답하는 질문	대표 도구
로그	무슨 일이 있었나	CloudWatch Logs, OpenSearch
지표	얼마나 많이, 얼마나 느리게	CloudWatch, Prometheus · Grafana
추적	요청 하나가 어디서 느려졌나	X-Ray, OpenTelemetry

세 가지를 다 갖춘 조직은 생각보다 적어요. 특히 추적은 없는 데가 많습니다. 없다고 감점할 일은 아니고, 없다는 걸 아는지가 중요해요.

알람 피로 — 여기가 진짜 판별 지점이에요

알람은 많이 거는 게 좋은 게 아니에요. 너무 많으면 아무도 안 봅니다. 매일 밤 20번 울리는 알람은 그냥 배경 소음이 되고, 진짜 중요한 하나가 그 안에 묻혀요.

그래서 잘 운영하는 팀은 알람을 줄이는 방향으로 관리합니다. 사람이 조치할 게 없는 알람은 지우고, 자동 복구가 되면 알람 대신 기록만 남기고요.

💡 “알람이 몇 개고, 지난달에 새벽에 몇 번 울렸나요?” — 이 질문이 이 갈래 최고의 질문 중 하나예요. 숫자가 바로 나오면 진짜 온콜을 선 사람이고, “많아서 좀 정리했어요” 라는 답이 나오면 아주 좋은 신호입니다.

SLI · SLO 는 알아두면 좋아요

SLI — 측정하는 지표. “성공한 요청 비율”
SLO — 목표치. “성공률 99.9% 를 유지한다”

목표를 정해두면 “이 정도면 대응할 일인가?” 를 감정이 아니라 숫자로 판단할 수 있어요. 이걸 도입해본 후보자는 대체로 성숙한 조직 경험이 있습니다. 다만 없다고 감점하진 마세요. 국내 조직 중에 SLO 를 제대로 운영하는 곳은 많지 않아요.

5. 배경 — 온콜과 장애 회고

온콜은 당직이에요. 정해진 기간 동안 알람을 받고 대응하는 역할이요. 이게 굴러가려면 세 가지가 필요합니다.

로테이션 — 한 사람에게 몰리면 그 사람이 나갑니다.
런북 — “이 알람이 오면 이걸 확인하세요” 문서. 없으면 그 사람만 대응 가능해요.
포스트모템(장애 회고) — 사고 후에 원인과 개선책을 정리하는 문서.

회고에서 중요한 건 비난하지 않는 것이에요. 사람을 탓하면 다음부터 아무도 사고를 보고하지 않고, 그러면 조직이 배우질 못합니다. 후보자가 이 문화를 알고 있는지는 말투에서 드러나요. 장애 이야기를 하면서 특정 인물을 계속 탓하면 좋은 신호가 아닙니다.

6. 질문 10개 + 채점 포인트

Q1. 인프라를 바꿔야 할 때, 실제로 어떤 절차를 거치나요

왜 묻나 — 자동화 수준을 한 번에 봅니다. 콘솔에서 바로 고치는 조직인지, 코드 리뷰를 거치는 조직인지요.
👍 좋은 답 — 코드 수정 → 리뷰 → 계획 확인 → 적용의 흐름이 나와요. 위험한 변경은 어떻게 다르게 다루는지도 말합니다.
⚠️ 걸리는 답 — “필요하면 콘솔에서 바꿉니다” 가 기본 절차예요.

Q2. Terraform 상태 파일은 어디에 두고, 잠금은 어떻게 하셨나요

왜 묻나 — 앞서 말한 그 질문이에요. 혼자 했는지 팀으로 했는지가 이 한 줄로 갈립니다.
👍 좋은 답 — 공유 저장소(S3 등)에 두고, 잠금을 걸고, 암호화했다고 답해요. 환경별로 상태를 분리한 이야기가 나오면 더 좋습니다.
⚠️ 걸리는 답 — 로컬에 뒀다고 하거나, 상태 파일이 뭔지 모릅니다. 후자면 IaC 경험이 실질적으로 없는 거예요.

Q3. 급해서 콘솔에서 손으로 고친 적 있으세요? 그다음엔요?

왜 묻나 — 드리프트 인식과 정직함을 같이 봅니다. 이 질문은 “없다” 는 답이 오히려 나쁜 드문 질문이에요.
👍 좋은 답 — “있죠” 로 시작해서, 사후에 코드에 반영하는 절차를 말해요. 그걸 놓쳐서 사고 났던 이야기가 나오면 최고입니다.
⚠️ 걸리는 답 — “저희는 그런 일이 없습니다.” 규모가 있는 환경이라면 사실이기 어려워요.

Q4. 배포 파이프라인이 한 번 도는 데 몇 분 걸리나요

왜 묻나 — 구체적 숫자는 실제로 매일 본 사람만 압니다. 그리고 이 숫자가 팀의 개발 속도를 직접 결정해요.
👍 좋은 답 — 단계별로 나눠 말합니다. “빌드 4분, 테스트 6분, 배포 3분 정도요.” 느린 구간을 줄이려고 했던 시도까지 나오면 좋아요.
⚠️ 걸리는 답 — 모른다고 하거나, “금방 됩니다” 로 답합니다.

Q5. 배포 후 문제가 생기면 되돌리는 데 몇 분 걸리나요

왜 묻나 — 롤백 경로가 실제로 있는지 봅니다. 데이터베이스가 얽힌 경우까지 생각해봤는지도요.
👍 좋은 답 — 숫자가 나오고, 실제로 되돌려본 경험이 있어요. “스키마가 바뀐 배포는 되돌리기가 어려워서 별도로 다룬다” 는 말이 나오면 아주 좋은 신호입니다.
⚠️ 걸리는 답 — “롤백할 일이 없었습니다” 또는 방법을 생각해본 적이 없어요.

Q6. EKS(또는 쿠버네티스) 버전 업그레이드를 해보셨나요

왜 묻나 — 쿠버네티스 경험의 진짜 깊이를 재는 질문이에요. 만드는 건 튜토리얼로도 되지만, 업그레이드는 운영해야만 겪습니다.
👍 좋은 답 — 몇 번 했는지 말하고, 그때 깨진 것들을 이야기해요. 미리 검증한 절차나 부가 도구 호환성 확인 이야기가 나오면 확실합니다.
⚠️ 걸리는 답 — 클러스터를 만들어봤다는 얘기만 반복해요. 또는 업그레이드는 다른 팀이 했다고 하는데, 본인 역할이 플랫폼 담당이었다고 합니다.

Q7. 오토스케일링은 어떻게 걸었고, 잘못 걸려서 문제 된 적 있나요

왜 묻나 — 자동 스케일링은 잘못 걸면 비용 폭탄이나 장애 확산으로 이어져요. 그 경험이 있는지 봅니다.
👍 좋은 답 — 파드와 노드 두 층을 나눠서 설명해요. 스케일이 안 붙어서 지연이 났거나, 반대로 과하게 붙어서 비용이 튄 이야기를 합니다.
⚠️ 걸리는 답 — “기본값으로 켜뒀습니다” 로 끝나거나, 두 층 구분을 모릅니다.

Q8. 운영 중인 알람이 몇 개고, 지난달에 새벽에 몇 번 울렸나요

왜 묻나 — 온콜을 실제로 섰는지, 그리고 알람 위생을 관리하는지 봅니다.
👍 좋은 답 — 대략의 숫자가 나오고, 줄이려고 뭘 했는지가 이어져요. “조치할 게 없는 알람은 지웠어요” 가 나오면 성숙한 운영자입니다.
⚠️ 걸리는 답 — 알람이 수백 개인데 그게 문제라고 생각하지 않아요. 또는 알람은 다른 팀이 본다고 합니다.

Q9. 온콜 로테이션과 장애 회고는 어떻게 하셨나요

왜 묻나 — 팀 문화와 협업 성향을 봅니다. 시니어는 자기 손만 빠른 사람이 아니라 팀이 굴러가게 만드는 사람이어야 해요.
👍 좋은 답 — 로테이션 주기, 런북 관리, 회고 문서 이야기를 합니다. 신입이 온콜을 설 수 있게 만든 경험이 있으면 아주 좋아요.
⚠️ 걸리는 답 — 전부 본인이 대응했다고 합니다. 영웅적으로 들리지만 조직 관점에서는 위험 신호예요. 그 사람이 나가면 아무도 못 합니다.

Q10. 지금 팀에서 아직 자동화 안 된 수동 작업은 뭔가요

왜 묻나 — 이 편의 마무리 질문이에요. 완벽한 자동화는 없다는 걸 아는지, 그리고 남은 부채를 파악하고 있는지 봅니다. 정직함도 같이 재요.
👍 좋은 답 — 바로 몇 개 나옵니다. “인증서 갱신이랑 특정 배치 재실행은 아직 손으로 해요. 우선순위에서 밀렸어요.” 왜 안 했는지 판단까지 있으면 최고예요.
⚠️ 걸리는 답 — “다 자동화돼 있습니다.” 거의 확실히 사실이 아니에요. 한 번 더 편하게 물어보면 대개 나옵니다.

7. 면접 직전 5분 요약

꼭 물을 것 3개

Terraform 상태 파일은 어디에 두셨나요 (Q2)
콘솔에서 급하게 고친 적 있나요, 그다음엔요 (Q3)
알람 개수와 새벽 호출 횟수 (Q8)

좋은 신호로 기억할 단어
상태 파일을 공유 저장소에 두고 잠금 · 사후에 코드로 반영 · 롤백 소요 시간을 숫자로 · 스키마 변경 배포는 따로 다룸 · 업그레이드하며 깨진 것 · 파드와 노드 두 층 · 조치할 게 없는 알람은 지웠다 · 신입도 온콜을 설 수 있게

레드 플래그
상태 파일이 개인 노트북에 · 콘솔 수정이 기본 절차 · 롤백을 생각해본 적 없음 · 모든 장애를 혼자 처리했다고 자랑 · “전부 자동화돼 있습니다” · 장애 이야기에서 특정 인물을 계속 탓함

일단 오늘은 여기까지…..
다음 글에서는 보안·거버넌스로 넘어갑니다. IAM 이 왜 그렇게 어려운지부터, 금융권이라면 반드시 물어야 할 규제 대응 경험까지 정리해볼게요.

← 이전 글: (2/5) 클라우드 인프라·아키텍트 면접 ｜ 다음 글 →: (4/5) 보안·거버넌스 면접

X Facebook LinkedIn Bluesky