플랫폼 엔지니어 면접 질문
성숙한 플랫폼 팀을 가진 회사의 채용 관리자에 따르면, 후보자의 60%가 기술 면접에서 도구별 지식이 아닌 시스템 설계 사고와 인프라 결정을 비즈니스 용어로 설명하는 능력에서 탈락합니다 [1]. 플랫폼 엔지니어링 면접은 일반 DevOps 면접과 한 가지 중요한 점에서 다릅니다: 면접관은 인프라를 내부 제품으로 생각하는지 평가합니다.
핵심 요점
- 3단계 면접 예상: 행동/문화 적합성, 기술 심층, 시스템 설계
- 행동 질문은 플랫폼-제품 사고에 초점: 개발자 공감, 크로스팀 협업, 인시던트 리더십
- 기술 질문은 Kubernetes 내부, IaC 설계, 관측성 아키텍처를 테스트합니다
- 상황 시나리오는 여러 팀의 경쟁 요구를 어떻게 우선순위화하는지 평가합니다
- 플랫폼 영향, 인시던트 대응, 개발자 경험 개선을 다루는 4-5개 STAR 스토리를 준비하세요
행동 질문 (STAR 형식)
1. 개발자가 처음에 저항했던 플랫폼 기능을 만든 경험을 설명해 주세요. 채택을 어떻게 이끌었나요?
**출제 이유**: 플랫폼 엔지니어는 내부 제품을 만듭니다. 채택이 궁극적인 지표입니다. **STAR 프레임워크**: 상황 — 개발자가 DB 프로비저닝을 위해 주당 50+ 티켓 제출, 평균 4시간 대기. 과제 — 플랫폼 포털을 통한 셀프서비스 시스템 제안, 보안과 신뢰성에 회의적인 팀. 행동 — 개발자 인터뷰, 파일럿 구축, 보안 기준 충족 입증, 채택 지표 공개. 결과 — 3개월 만에 1팀에서 12팀으로 채택 확대, 인프라 티켓 67% 감소, 개발자 만족도 3.2/10에서 8.4/10으로 향상.
2. 인시던트 커맨더로서 이끈 가장 복잡한 프로덕션 인시던트에 대해 말씀해 주세요.
**STAR 프레임워크**: 상황 — 피크 트래픽 중 3개 EKS 클러스터에서 간헐적 서비스간 통신 장애. 행동 — Istio 프록시 에러 로그와 2시간 전 배포된 Calico NetworkPolicy 변경 상관분석, 크로스 네임스페이스 트래픽 차단 정책 식별, 롤백, 사전 배포 네트워크 정책 테스트 프레임워크 구현. 결과 — MTTR 23분(SLO 내). 사후: 네트워크 정책 관련 인시던트 분기 4건에서 6개월 간 0건으로 감소.
3. 두 제품 팀의 상충하는 플랫폼 요구사항이 있었던 상황을 설명해 주세요.
**프레임워크**: 한 팀은 ML 워크로드용 GPU 노드 풀, 다른 팀은 같은 예산으로 범용 컴퓨팅 용량을 원함. 사용 패턴 분석, 프리엠프터블 인스턴스와 큐 기반 스케줄링이 있는 공유 GPU 노드 풀을 제안하여 합산 비용의 60%로 양쪽 수요 충족, 향후 리소스 거버넌스 프레임워크 수립.
4. 기능 개발 대신 플랫폼 인프라 투자를 경영진에게 설득한 경험.
**프레임워크**: 투자하지 않을 비용 정량화: 수동 프로비저닝에 손실된 개발자 시간, 설정 드리프트로 인한 인시던트 빈도, 신규 엔지니어 온보딩 시간. 플랫폼 투자를 포스 멀티플라이어로 제시: "$400K 투자로 연간 8,000 개발자-시간의 인프라 토일을 제거, 풀타임 엔지니어 4명에 해당."
5. 플랫폼 성공을 어떻게 측정했나요? 어떤 메트릭을 추적했나요?
**프레임워크**: DORA 메트릭(배포 빈도, 리드 타임, 변경 실패율, MTTR), 개발자 만족도 설문, 셀프서비스 채택률, 신규 엔지니어의 첫 배포까지 시간, 플랫폼 업타임 SLO, 배포당 인프라 비용.
기술 질문
1. Kubernetes에서 Deployment 매니페스트를 적용하는 순간부터 컨테이너가 실행될 때까지 무슨 일이 일어나는지 설명해 주세요.
**평가 요소**: Kubernetes 내부 지식의 깊이. kubectl → API 서버(인증, 인가, 어드미션 컨트롤러) → etcd 저장 → 스케줄러(필터링, 스코어링, 바인딩) → 선택된 노드의 kubelet → CRI 호출(containerd) → CNI 플러그인 네트워킹 → readiness 프로브 통과 → 엔드포인트 등록.
2. 15개 제품 팀이 있는 조직의 Terraform 모듈 전략을 설계해야 합니다. 모듈, 상태, 권한을 어떻게 구성하나요?
**평가 요소**: IaC 아키텍처 사고. 모듈 구성, 상태 격리(팀별, 환경별, 서비스별), 원격 백엔드 설정, RBAC, 모듈 버전 관리, 드리프트 감지 전략.
3. 30개 네임스페이스에 500+ 파드를 실행하는 클러스터의 무중단 Kubernetes 업그레이드를 어떻게 구현하나요?
**평가 요소**: 운영 성숙도. PodDisruptionBudget, 노드 풀 롤링 업데이트, API 서버 버전 스큐 정책, 사전 업그레이드 검증, 카나리 클러스터 전략, 업그레이드 중 모니터링, 롤백 절차.
4. 50개 마이크로서비스를 서빙하는 플랫폼을 위한 관측성 스택을 어떻게 설계하나요?
**평가 요소**: 관측성 아키텍처. 메트릭(Prometheus + Thanos), 로그(Fluent Bit → Loki), 트레이스(OpenTelemetry → Tempo/Jaeger), 상관관계(exemplar, 로그 내 trace ID), SLO 기반 알림, 셀프서비스 Grafana 대시보드.
5. 개발자가 배포에 45분 걸린다고 보고합니다. 어떻게 진단하고 최적화하나요?
**평가 요소**: 체계적 디버깅. 파이프라인 추적: 체크아웃, 의존성(캐싱), 빌드(다단계 Docker), 테스트(병렬), 이미지 푸시, ArgoCD 싱크, 파드 스케줄링. 최적화 전에 병목 식별.
6. Kyverno와 OPA/Gatekeeper의 차이점. 각각 언제 선택하나요?
**평가 요소**: OPA/Gatekeeper는 Rego 정책 언어(강력하지만 학습 곡선 가파름), Kyverno는 Kubernetes 네이티브 YAML 정책(낮은 채택 장벽). Kyverno는 검증, 변형, 생성 정책 지원. 기존 Rego 전문 지식이 있거나 복잡한 정책이 필요하면 Gatekeeper, 그렇지 않으면 Kyverno.
상황 질문
1. 5명의 플랫폼 팀이 8개 제품 팀의 요청을 동시에 받습니다. 어떻게 우선순위를 정하나요?
**프레임워크**: 영향(영향받는 개발자 수 × 심각도), 긴급도(배포 차단 vs 있으면 좋은), 전략적 정렬. 투명한 인테이크 프로세스: 주간 우선순위 미팅, 공개 로드맵, 요청 유형별 SLA.
2. 새 CTO가 6개월 내에 전체 인프라를 AWS에서 GCP로 마이그레이션하길 원합니다.
**프레임워크**: 영향 평가부터: AWS 서비스 인벤토리, GCP 동등 서비스 식별, 데이터 전송 비용 추정. 단계적 접근: Terraform 모듈로 클라우드 결합 추상화, 비프로덕션 POC, 롤백 가능한 프로덕션 마이그레이션. 6개월 타임라인이 비현실적이면 근거와 함께 반박.
3. Kubernetes 클러스터에서 업무 시간 중 간헐적 파드 축출이 발생합니다.
**프레임워크**: 노드 레벨 리소스 압박 확인(메모리, 디스크, PID). 리소스 요청 vs 실제 사용량 검토 — 요청 없는 파드가 먼저 축출됨. 노이지 네이버 효과 확인. 오토스케일러 로그 확인. ResourceQuota와 LimitRange 구현.
4. Terraform 상태 파일의 40%가 6개월간 적용되지 않아 드리프트가 축적됐습니다.
**프레임워크**: 맹목적으로 terraform apply 하지 않음. 각 상태 파일에 terraform plan 실행, 드리프트 분류: 의도적 변경, 비의도적 드리프트, 방치된 리소스. 지속적 드리프트 감지 구현. 거버넌스 정책 수립: 모든 인프라 변경은 Terraform PR을 통해야 함.
5. VP 엔지니어링이 자기 팀에 프로덕션 Kubernetes 클러스터 직접 접근을 요청합니다.
**프레임워크**: 직접 클러스터 접근은 보안 및 감사 리스크. 대안 제안: RBAC으로 범위가 제한된 읽기 전용 kubectl 접근, Grafana 대시보드, 임시 디버그 컨테이너, 로그 집계. 고집하면 감사 로깅과 자동 만료가 있는 시간 제한 접근 구현.
면접관 평가 기준
**기술 깊이 (40%)**: 시스템이 컴포넌트 수준에서 어떻게 작동하는지 설명할 수 있는가? **시스템 설계 (25%)**: 여러 팀에 대규모로 서빙하는 플랫폼 컴포넌트를 설계할 수 있는가? **제품 및 커뮤니케이션 (20%)**: 인프라 결정을 비즈니스 용어로 설명할 수 있는가? **인시던트 및 운영 (15%)**: 프로덕션 문제를 체계적으로 진단하고 재발을 방지할 수 있는가?
면접관에게 할 질문
- "플랫폼 팀이 성공을 어떻게 측정하나요? 어떤 KPI나 SLO를 추적하나요?"
- "플랫폼 팀이 우선순위화하고 있는 현재 개발자 경험의 페인 포인트는 무엇인가요?"
- "플랫폼 팀이 제품 팀 대비 어떻게 구성되어 있나요? Team Topologies 모델을 따르나요?"
- "현재 배포 빈도와 병목은 어디에 있나요?"
- "팀이 최근 내린 가장 논쟁적인 인프라 결정은 무엇인가요?"
- "플랫폼 팀의 온콜은 어떤 모습인가요?"
- "주요 플랫폼 변경에 대한 아키텍처 리뷰나 RFC 프로세스가 있나요?"
최종 요점
플랫폼 엔지니어링 면접은 세 가지 차원을 평가합니다: Kubernetes, IaC, 클라우드 인프라의 기술적 깊이; 개발자 경험과 플랫폼 채택에 대한 제품 사고; 인시던트 대응과 시스템 디버깅의 운영 성숙도. 도구 사용이 아닌 측정 가능한 플랫폼 성과 중심의 STAR 스토리를 준비하세요.
자주 묻는 질문
플랫폼 엔지니어 면접은 몇 라운드인가요?
보통 4-5라운드: 리크루터 스크린(30분), 채용 관리자 행동(45-60분), 시니어 엔지니어 기술 심층(60-90분), 스태프+ 시스템 설계(60분), 팀/문화 패널(45-60분).
스타트업과 대기업 면접 준비를 다르게 해야 하나요?
네. 스타트업은 폭넓은 역량과 속도를 강조하고, 대기업은 특정 도메인의 깊이와 규모에서의 패턴 작업을 강조합니다.
Go 프로그래밍 능력이 중요한가요?
중급 이상에서 점점 중요해지고 있습니다. 회사가 커스텀 Kubernetes 오퍼레이터나 Terraform 프로바이더를 만든다면 Go는 사실상 필수입니다.
회사가 사용하는 특정 도구 경험이 없다면?
전이 가능한 개념에 집중하세요. ArgoCD를 알지만 Flux를 사용하는 회사라면 GitOps 원칙을 설명하세요 — 개념은 동일합니다.
**인용:** [1] DORA / Google Cloud, "2024 Accelerate State of DevOps Report," dora.dev, 2024.
