프로덕션에서 살아남는 DevOps/SRE 면접 질문 20가지
면접관이 정말 보고 싶어 하는 것
최근 몇 년간 DevOps/SRE 면접을 보면서 느낀 건데, 면접관들이 정말 알고 싶어 하는 건 용어 정의가 아니더라고요. "Kubernetes가 뭔가요?"보다는 "Pod가 Running인데 503 에러가 나면 어떻게 접근하시겠어요?"에서 진짜 실력이 드러나거든요.
프로덕션 환경에서는 정답보다 사고 순서가 훨씬 중요합니다. 문제를 어떻게 레이어별로 나누고, 어디서부터 확인하며, 사용자 영향을 어떻게 최소화하면서 원인을 찾아가는가가 핵심이죠.
오늘은 실제 면접에서 자주 나오는 20가지 실전 질문을 정리해봤습니다. 각 답변은 암기용이 아니라, 실제 운영자가 생각하는 방식에 맞춰 구성했어요.
네트워크와 트래픽 문제 해결
1. Pod는 Running인데 503 오류가 발생합니다. 어떻게 디버깅하겠습니까?
503은 보통 애플리케이션이 죽었다는 의미가 아니라, 정상 백엔드를 찾지 못했다는 신호입니다. 요청 경로를 레이어별로 나눠서 접근해야 해요.
Pod 레벨 확인
kubectl get pod -o wide로 상태 확인kubectl logs <pod>와kubectl describe pod <pod>로 상세 정보 파악- readiness/liveness probe 실패 여부
- 애플리케이션 포트와 컨테이너 포트 일치 여부
Service 레벨 확인
kubectl get endpoints로 Service가 Pod를 제대로 찾고 있는지- Service selector와 Pod label 매칭 확인
- targetPort가 실제 컨테이너 포트와 일치하는지
Ingress/Gateway 레벨 확인
- Ingress Controller 로그
- host, path, TLS 설정
- Backend Service 연결 상태
가장 흔한 원인은 readiness probe 실패로 Pod가 Service Endpoint에서 제외되는 경우예요. 운영 환경에서는 "트래픽이 어느 지점까지 도달했는가"를 기준으로 역추적하는 게 중요합니다.
2. CNI 플러그인은 어떻게 동작합니까?
CNI(Container Network Interface)는 Pod에 네트워크를 붙이는 표준 인터페이스입니다. Kubernetes는 직접 네트워킹을 구현하지 않고, CNI 플러그인에 위임하죠.
주요 역할은 다음과 같습니다:
- Pod IP 할당 및 veth pair 생성
- Pod network namespace 연결
- Node 간 Pod 통신을 위한 라우팅 구성
- NetworkPolicy 적용
- overlay/underlay 네트워크 구성
Calico는 BGP 기반 라우팅과 NetworkPolicy에 강점이 있고, Cilium은 eBPF 기반으로 보안과 관측성 기능이 뛰어나요.
운영 관점에서 중요한 건, CNI 장애가 발생하면 Pod 간 통신, DNS, Service 통신, NetworkPolicy까지 연쇄적으로 영향받을 수 있다는 점입니다.
스케줄링과 배포 전략
3. Kubernetes 스케줄링 동작 방식
Kubernetes Scheduler는 Filtering과 Scoring 두 단계로 동작합니다.
Filtering 단계에서는 Pod를 실행할 수 없는 Node를 제외해요:
- CPU/Memory 부족
- taint/toleration 불일치
- nodeSelector, node affinity 조건 불일치
- PV zone 제약
Scoring 단계에서는 남은 Node 중 가장 적합한 곳을 선택합니다:
- 리소스 여유도
- Pod 분산 정책
- affinity 선호 조건
- topology spread constraints
Pod가 Pending이라면 kubectl describe pod의 Events를 먼저 봐야 해요. 추측하지 말고 스케줄러가 왜 못 올렸는지 이벤트 메시지에서 확인하는 게 핵심입니다.
4. Stateful 애플리케이션 무중단 배포
Stateful 애플리케이션은 단순히 Pod만 교체한다고 무중단이 보장되지 않아요. 애플리케이션 버전, 데이터, 스키마, 복제 구조를 함께 고려해야 합니다.
기본 접근법:
- StatefulSet으로 Pod 순서와 안정적인 네트워크 ID 유지
- RollingUpdate로 한 번에 하나씩 교체
- readiness probe로 준비되지 않은 Pod 트래픽 차단
- replica/standby 구조 활용
- backward compatible 스키마 설계
- 배포 전 백업과 롤백 경로 확보
핵심은 "애플리케이션 배포"와 "데이터 변경"을 분리해서 생각하는 것입니다. DB 스키마 변경은 expand → deploy → contract 방식으로 접근하는 게 안전해요.
디버깅과 문제 해결
5. 로그 없이 간헐적 Pod 재시작
로그가 없다면 애플리케이션 로그 이전 단계에서 종료되었거나, 종료 시 로그를 남길 시간이 없었을 가능성이 있어요.
확인 순서:
kubectl describe pod로 Events 확인kubectl get pod -o yaml에서 lastState 확인- OOMKilled 여부와 liveness probe 실패 확인
- Node의 CPU, Memory, DiskPressure 상태
- 컨테이너 exit code 확인
kubectl logs <pod> --previous로 이전 컨테이너 로그
자주 보는 원인:
- 메모리 limit 초과로 인한 OOMKilled
- liveness probe timeout 또는 path 오류
- node resource pressure
- 애플리케이션 초기화 실패
- 외부 의존성 지연으로 인한 probe 실패
로그가 없을 때는 애플리케이션만 보지 말고 Kubernetes 이벤트, 컨테이너 상태, 노드 상태를 함께 봐야 합니다.
6. 60초마다 latency 급증 디버깅
주기적인 latency 증가는 예약 작업이나 주기적 리소스 사용을 의심해볼 수 있어요.
확인 항목:
- cron job 또는 scheduled task
- JVM GC 또는 런타임 GC
- DB checkpoint, vacuum, backup
- 로그 flush/rotate, metrics scraping
- batch job, cache refresh
- autoscaling metric 수집 주기
- 외부 API rate limit
디버깅 방법:
- latency spike 시점과 인프라 지표를 시간축으로 맞춰 비교
- trace에서 느려지는 구간 확인
- DB slow query, GC log 확인
- cron/scheduler 실행 시간 확인
"60초마다"라는 패턴 자체가 중요한 단서입니다. 시간 주기를 기준으로 애플리케이션, DB, 런타임, 인프라 작업을 대조해봐야 해요.
CI/CD와 배포 최적화
7. 50개 이미지 빌드 시간 단축 (20분 → 5분)
핵심은 **"모든 이미지를 매번 순차적으로 다시 빌드하지 않는 것"**입니다.
개선 방향:
- 변경된 서비스만 빌드하도록 path 기반 change detection
- 빌드 병렬화
- Docker layer cache 활용
- BuildKit, Kaniko, Buildx 등 최신 빌드 도구
- base image 표준화로 캐시 적중률 향상
- dependency install과 app copy 단계 분리
- remote cache 또는 registry cache 사용
- 테스트와 빌드 병렬 실행
가장 큰 효과는 병렬화와 캐싱에서 나와요. 다만 무작정 병렬화하면 runner 비용과 registry 부하가 증가할 수 있으니 병목이 어디인지 먼저 측정해야 합니다.
8. 안전한 CI/CD 파이프라인 설계
보안은 배포 직전 한 번 검사가 아니라 파이프라인 전체에 포함되어야 해요.
주요 설계 요소:
- Secret을 코드/이미지/로그에 남기지 않고 전용 저장소 사용
- CI runner 권한 최소화
- branch protection과 approval gate
- 이미지 취약점 스캔과 IaC 스캔
- SAST/DAST 적용
- 아티팩트 서명 및 검증
- SBOM 생성
- 배포 권한과 빌드 권한 분리
- 감사 로그 유지
운영 관점에서 중요한 건 "누가, 어떤 코드와 아티팩트를, 어떤 권한으로, 어느 환경에 배포했는지" 추적 가능해야 한다는 점입니다.
인프라 관리와 고가용성
9. 다중 리전 고가용성 시스템 설계
다중 리전 설계의 핵심은 단순히 여러 리전에 배포하는 게 아니라, 장애 시 트래픽과 데이터 정합성을 어떻게 처리할지 결정하는 것입니다.
설계 요소:
- Active-Active 또는 Active-Passive 구조 선택
- 글로벌 로드밸런서 또는 DNS 기반 라우팅
- 리전 간 데이터 복제와 RTO/RPO 정의
- 장애 감지와 failover 자동화
- 리전별 독립 배포 가능성
- 공통 의존성 제거
- 운영 Runbook과 DR 훈련
Active-Active는 가용성은 높지만 데이터 정합성 관리가 어려워요. Active-Passive는 구조가 단순하지만 전환 시간과 복구 절차가 중요하죠.
면접에서는 "다중 리전으로 하겠습니다"보다 **"가용성, 비용, 정합성, 운영 복잡도 사이의 trade-off를 어떻게 선택하겠습니다"**라고 답하는 게 좋아요.
10. Terraform drift 관리
Terraform drift는 코드와 실제 클라우드 인프라가 달라진 상태예요.
관리 방법:
- remote backend와 state locking 적용
- PR 기반 변경 프로세스
- CI에서 terraform plan 실행
- 수동 콘솔 변경 제한
- drift detection 주기적 수행
- 환경별 state 분리
- state 파일 접근 권한 제한
중요한 건 Terraform을 **"한 번 실행하는 도구"가 아니라 "인프라의 기준 정보"**로 운영하는 것입니다. 수동 변경이 불가피했다면 반드시 코드에 반영하거나 state를 정리해야 해요.
보안과 관측성
11. 대규모 Secret 관리
대규모 환경에서는 Secret을 안전하게 저장하는 것뿐 아니라, 접근·교체·감사까지 관리해야 합니다.
핵심 원칙:
- Secret을 Git, 이미지, CI 로그에 저장 금지
- 중앙 Secret Manager 사용
- 역할 기반 접근 제어
- 환경별 Secret 분리
- 정기적 rotation 적용
- Secret 접근 로그 감사
- short-lived credential 사용
- 애플리케이션에는 필요한 Secret만 주입
Secret 관리의 목표는 "숨기는 것"이 아니라 **"누가 언제 어떤 Secret에 접근했는지 통제하고 추적하는 것"**입니다.
12. Observability 설계
Observability는 단순히 로그를 많이 쌓는 게 아니라, 장애 시 원인을 빠르게 좁힐 수 있도록 신호를 설계하는 것이에요.
기본 구성 (Metrics, Logs, Traces):
- Metrics: 시스템 상태와 성능 추세
- Logs: 개별 이벤트와 에러 상세
- Traces: 서비스 간 요청 흐름
운영 관점 설계 요소:
- 표준 로그 포맷과 correlation ID
- 서비스별 RED 지표 (Rate, Errors, Duration)
- 인프라별 USE 지표 (Utilization, Saturation, Errors)
- 대시보드와 알림 기준
좋은 Observability는 장애 후 로그를 뒤지는 게 아니라, 장애 시작점을 빠르게 좁혀주는 구조입니다.
장애 대응과 SRE 실무
13. SLO 기반 노이즈 없는 알림 설계
좋은 알림은 "시끄러운 알림"이 아니라 **"조치가 필요한 알림"**이에요.
설계 순서:
- 사용자 관점의 SLI 정의 (성공률, 지연시간, 가용성)
- SLO 정의 (예: 99.9% 요청 성공률, p95 latency 300ms 이하)
- Error Budget 설정
- Error Budget 빠른 소진 시 알림 발생
- 내부 지표는 보조 알림으로 분리
CPU 90% 자체가 장애는 아닐 수 있어요. 하지만 사용자 요청 실패율이 증가하거나 지연시간이 SLO를 위협하면 알림 대상입니다.
14. 프로덕션 장애 대응 첫 5단계
장애 대응의 첫 목표는 완벽한 원인 분석이 아니라 사용자 영향 최소화입니다.
- 영향 범위 확인: 전체/일부/특정 리전인지
- 장애 선언 및 커뮤니케이션: 담당자/의사결정자/커뮤니케이션 분리
- 최근 변경사항 확인: 배포/설정/인프라/외부 의존성
- 즉시 완화 조치: rollback/traffic shift/feature flag off/scale out/circuit breaker
- 타임라인 기록: 언제 무엇을 확인했고 어떤 조치를 했는지
운영 사고 대응에서 중요한 건 침착함과 구조화예요. 원인 분석은 중요하지만, 사용자 영향이 계속되는 상황에서는 복구와 완화가 먼저입니다.
15. Graceful Degradation 설계
Graceful Degradation은 일부 기능이 실패해도 전체 서비스가 함께 죽지 않도록 설계하는 방식이에요.
예시:
- 추천 API 장애 → 기본 추천 목록 제공
- 결제 부가기능 장애 → 핵심 결제만 유지
- 외부 API 장애 → 캐시 데이터 사용
- 검색 장애 → 인기상품 또는 최근 데이터 제공
- 비핵심 기능을 feature flag로 차단
- circuit breaker로 장애 전파 차단
- timeout/retry 정책 적용
주의할 점은 retry를 무작정 늘리면 장애를 더 키울 수 있다는 것. retry에는 timeout, backoff, circuit breaker, bulkhead 패턴이 함께 있어야 해요.
비용과 업그레이드 관리
16. AWS 비용 3배 급증 대응
먼저 비용 증가 원인을 서비스, 리전, 계정, 태그 기준으로 분해합니다.
확인 순서:
- Cost Explorer에서 서비스별 증가 항목
- 리전별 비용 증가와 최근 생성 리소스
- Auto Scaling, NAT Gateway, 데이터 전송, 로그 저장 비용
- 비정상 트래픽 또는 배치 작업 실패
- 태그 미적용 리소스
- 예산 알림과 Cost Anomaly Detection 설정
자주 발생하는 원인:
- Auto Scaling 오작동
- 대량 로그 적재
- NAT Gateway/Data Transfer 비용 폭증
- 잘못된 인스턴스 타입
- 종료되지 않은 테스트 리소스
- 배치 작업 재시도 루프
운영에서는 비용도 장애의 한 종류로 봐야 해요. 비용 알림, 예산 정책, 태그 정책, 리소스 TTL 정책이 없으면 문제를 늦게 발견하게 됩니다.
17. Kubernetes 무중단 업그레이드
Kubernetes 업그레이드는 컨트롤 플레인, 노드, 애플리케이션 가용성을 모두 고려해야 해요.
기본 절차:
- 현재-목표 버전 호환성과 API deprecation 확인
- 애드온 호환성 확인 (CNI, CSI, Ingress Controller, Monitoring Agent)
- 컨트롤 플레인 업그레이드
- 워커 노드를 순차적으로 cordon/drain
- 노드 업그레이드 후 uncordon
- PodDisruptionBudget으로 최소 가용성 보장
- readiness probe로 준비된 Pod만 트래픽 수신
- 주요 서비스 smoke test
주의할 점은 PDB가 잘못 설정되면 drain이 막히거나, 반대로 너무 느슨하면 업그레이드 중 서비스 가용성이 깨질 수 있다는 점이에요.
실전에서 통하는 사고방식
DevOps/SRE 면접에서 좋은 답변은 특정 명령어를 많이 아는 답변이 아닙니다. 문제를 레이어별로 나누고, 사용자 영향도를 먼저 판단하며, 최근 변경사항과 운영 리스크를 함께 보는 답변이에요.
프로덕션 환경에서 중요한 사고방식:
- 추측보다 증거를 먼저 본다
- 원인 분석보다 영향 완화를 먼저 한다
- 단일 컴포넌트가 아니라 요청 경로 전체를 본다
- 배포, 인프라, 네트워크, 권한, 데이터 변경을 함께 본다
- 장애 후에는 재발 방지까지 설계한다
결국 DevOps/SRE 면접은 지식 테스트가 아니라 운영 사고방식 테스트입니다. 실제 장애를 다뤄본 사람은 답변에서 순서, 근거, 리스크 통제 방식이 자연스럽게 드러나더라고요.
문제가 생겼을 때 어디서부터 보고, 무엇을 우선 처리하며, 어떤 근거로 판단하는가. 그게 프로덕션에서 정말 필요한 능력이니까요.