사이트 신뢰성 엔지니어 면접 질문 — 30개 이상의 질문 및 전문가 답변

Glassdoor에 따르면 SRE의 평균 연봉은 $169,680이며, 75번째 백분위는 연간 $213,000을 넘습니다 [1]. 2003년 Google에서 탄생하여 현재 모든 주요 기술 기업에서 채택된 이 역할은 소프트웨어 엔지니어링과 시스템 운영의 교차점에 있으며, 면접 과정도 그 이중성을 반영합니다 [2]. SRE 면접은 신뢰성 제약이 있는 시스템 설계, 자동화를 위한 코딩, 압박 상황에서의 인시던트 관리, SLO와 오류 예산을 통해 신뢰성을 정량화하는 특정 사고방식을 테스트합니다.

핵심 요약

• SRE 면접은 일반적으로 4~6라운드를 포함합니다: 코딩, 시스템 설계, 문제 해결, 인시던트 관리, 행동 — 하루 전체 또는 여러 세션에 걸쳐 진행 [3].
• 핵심 SRE 면접 차별화 요소는 신뢰성 중심 시스템 설계입니다 — 단순히 확장하는 시스템이 아니라 우아하게 성능이 저하되는 시스템을 설계해야 합니다 [2].
• SLO, SLI, 오류 예산, 수고(toil) 감소는 면접관이 유창하게 사용하기를 기대하는 SRE 전용 어휘입니다.
• SRE 역할의 코딩 질문은 순수한 알고리즘 퍼즐보다 자동화, 인프라 도구, 운영 스크립팅을 강조합니다 [3].

행동 질문

1. 관리한 가장 영향력 있는 인시던트에 대해 말씀해 주세요. 어떤 역할이었으며, 사후 분석에서 무엇이 밝혀졌나요?

전문가 답변: "기본 인증 서비스를 중단시킨 연쇄 장애의 인시던트 커맨더였습니다. 230만 명의 활성 사용자에게 47분 동안 영향을 미쳤습니다. 속도 제한기에 대한 일상적인 설정 변경이 실수로 임계값을 초당 10,000이 아닌 10으로 설정했습니다. 인증 서비스가 한도에 도달하여 429를 반환했고, 클라이언트의 재시도 폭풍이 부하를 50배 증폭시켰습니다. P1을 선언하고, 인시던트 채널을 설정하며, 역할을 배정하고, 대응을 조율했습니다. 수정은 설정 변경을 되돌리는 것이었지만, 재시도 백로그를 소진하기 위해 임시로 용량을 늘려야 했습니다. 사후 분석에서 세 가지 근본 원인을 식별했습니다: 속도 제한기 설정 값에 대한 유효성 검사 없음, 설정 변경에 대한 카나리아 배포 없음, 클라이언트 재시도에 대한 서킷 브레이커 없음. 세 가지 수정 사항을 모두 구현하고 30초마다 인증 흐름을 테스트하는 합성 카나리아를 추가했습니다."

2. 중요한 수고(toil) 원인을 제거한 경험을 설명해 주세요.

전문가 답변: "온콜 엔지니어들이 트래픽 급증 시 데이터베이스 읽기 레플리카를 수동으로 확장하는 데 주당 평균 6시간을 소비했습니다. 이것은 전형적인 수고였습니다: 수동, 반복적, 자동화 가능, 서비스 성장에 비례하여 선형 증가. 과거 트래픽 패턴에 기반한 예측 모델을 사용하여 CPU와 쿼리 대기시간 지표를 모니터링하고, 레플리카를 자동으로 확대/축소하는 맞춤형 Kubernetes 오퍼레이터를 구축했습니다. 배포 후 수동 확장 개입이 주당 6시간에서 0으로 감소했고, 온콜 부담이 30% 줄었습니다. 이 프로젝트는 자동 확장이 사람보다 빠르게 응답하여 P99 쿼리 대기시간도 15% 개선했습니다."

3. 너무 공격적이라고 생각한 신뢰성 요구사항에 반대한 사례를 들어 주세요.

전문가 답변: "제품 팀이 새로운 알림 서비스에 99.999% 가용성(파이브 나인)을 요청했습니다. 파이브 나인이 실제로 무엇을 의미하는지 계산했습니다: 연간 5.26분의 다운타임. 엔지니어링 비용은 6개월과 $400K의 추가 인프라로 추정되었습니다. 그런 다음 제품 팀에 물었습니다: '알림이 5분 지연되면 사용자에게 무슨 일이 일어나나요?' 답은 '아무것도 — 알림은 시간에 민감하지 않다'였습니다. 기존 인프라에서 약간의 개선으로 달성할 수 있는 99.9%(연간 8.76시간의 다운타임)를 제안했습니다. 제품 팀은 비용-신뢰성 트레이드오프 곡선을 보고 동의했습니다. 이것이 SRE 원칙입니다: 신뢰성은 기능이며, 모든 기능과 마찬가지로 사용자 영향으로 정당화되어야 하는 비용이 있습니다 [2]."

기술 질문

1. SLO, SLI, 오류 예산을 설명하세요. 어떻게 서로 관련되나요?

전문가 답변: "SLI(서비스 수준 지표)는 서비스 품질의 특정 측면을 측정하는 정량적 지표입니다. SLO(서비스 수준 목표)는 SLI의 목표값입니다 — 예를 들어, 30일 롤링 윈도우에서 요청의 99.9%가 200ms 이내에 성공해야 합니다. 오류 예산은 SLO의 역수입니다: SLO가 99.9%이면 오류 예산은 0.1%입니다. 오류 예산은 SRE와 제품 팀 간의 공유 언어를 만듭니다: 예산 내에 있으면 공격적으로 기능을 배포하고, 예산이 소진되면 신뢰성에 투자합니다 [2]."

2. 50개 서비스의 마이크로서비스 아키텍처에 대한 모니터링 및 경고 시스템을 설계하세요.

전문가 답변: "세 계층으로 시스템을 구축하겠습니다. 데이터 수집: 각 서비스에 Prometheus 클라이언트 라이브러리로 RED 지표(Rate, Errors, Duration)와 맞춤 비즈니스 지표를 계측합니다. 장기 저장을 위한 Thanos 또는 Mimir이 있는 Prometheus 연합 계층을 사용합니다. Loki 또는 Elasticsearch를 통한 로그 집계. Jaeger 또는 Tempo를 통한 분산 트레이싱. 경고: 개별 엔드포인트가 아닌 각 서비스의 중요 사용자 여정에 대한 SLO를 정의합니다. 다중 윈도우 번율 경고를 구현합니다. 핵심 설계 원칙: 원인(CPU 높음)이 아닌 증상(사용자 영향)에 대해 경고하고, 모든 경고에 런북이 메타데이터에 링크되어 있도록 합니다."

3. 서비스가 느리게 응답합니다. 문제 해결 접근법을 설명해 주세요.

전문가 답변: "사용자 영향부터 시작합니다: P50/P99 대기시간이 정상 대비 어떤지, 영향받는 사용자 비율은? 그런 다음 USE 방법(Utilization, Saturation, Errors)과 RED 방법(Rate, Errors, Duration)을 체계적으로 따릅니다. 첫째, 서비스 자체: CPU, 메모리, GC 일시정지, 스레드 풀 포화, 연결 풀 고갈. 둘째, 다운스트림 종속성: 데이터베이스 쿼리 대기시간, 캐시 히트율, 외부 API 대기시간. 셋째, 네트워크: 패킷 손실, DNS 해석 지연, TLS 핸드셰이크 오버헤드. 분산 트레이싱을 사용하여 요청 경로에서 가장 많은 대기시간을 기여하는 스팬을 식별합니다."

4. 여러 리전에서 99.99% 가용성을 달성하는 시스템을 어떻게 설계하시겠습니까?

전문가 답변: "99.99% 가용성은 연간 52.6분의 다운타임을 허용합니다. 아키텍처: 최소 3개 리전에 액티브-액티브 배포. 헬스체크 기반 트래픽 전환이 가능한 글로벌 로드 밸런싱. 데이터 레이어: 리전 내 일관성을 위한 동기식 복제, 리전 간 비동기식 복제와 충돌 해결. 배포: 리전별 카나리아 배포 — 한 리전에 배포하고 30분 관찰 후 나머지 리전에 롤아웃. 테스트: Gremlin이나 Litmus 같은 도구를 사용하여 매월 정기적인 카오스 엔지니어링으로 장애 조치가 설계대로 작동하는지 확인."

5. 인프라스트럭처 코드(IaC)를 설명하고 신뢰성 개선에 어떻게 활용했는지 말씀해 주세요.

전문가 답변: "인프라스트럭처 코드는 인프라 구성을 소프트웨어처럼 취급합니다: 버전 관리, 검토, 테스트, 재현 가능. 클라우드 리소스 프로비저닝에 Terraform을, 인스턴스 내 구성 관리에 Ansible을 사용합니다. 신뢰성 이점: 재현성(몇 분 내에 어떤 환경이든 코드에서 재구축 가능), 감사 가능성(git log가 누가 무엇을 언제 왜 변경했는지 표시), 테스트 가능성(CI에서 terraform plan을 실행하여 적용 전 중단 변경 포착)."

상황 질문

1. 서비스의 오류 예산이 분기 2주를 남기고 소진되었습니다. 제품 팀이 주요 기능을 배포하고 싶어합니다. 어떻게 하시겠습니까?

전문가 답변: "오류 예산 정책에 따르면 예산 소진은 신뢰성 동결을 촉발합니다 — 예산이 회복되거나 분기가 재설정될 때까지 기능 배포 없음. 데이터를 제품 팀에 제시합니다. 대안을 제안합니다: 폭발 반경을 최소화하기 위해 기능 플래그 뒤에서 점진적 롤아웃(1% -> 10% -> 100%)으로 배포할 수 있는지? 예산 회복을 빠르게 할 특정 신뢰성 개선에 우선순위를 둘 수 있는지? 오류 예산 정책은 정확히 이런 상황을 위해 존재합니다 [2]."

2. 주니어 엔지니어의 변경이 프로덕션 장애를 일으켰습니다. 사후 분석을 어떻게 처리하시겠습니까?

전문가 답변: "근본 원칙은 비난하지 않는 것입니다 — 사후 분석은 무엇이 왜 일어났는지를 검토하며, 누가 잘못했는지가 아닙니다 [2]. 타임라인 사실을 확인합니다. 그런 다음 체계적 원인에 집중합니다: 변경 관리 프로세스가 왜 안전하지 않은 변경을 허용했는가? 조치 항목은 엔지니어를 처벌하는 것이 아니라 시스템을 개선해야 합니다. 사후 분석 문서에 명시합니다: '엔지니어는 문서화된 프로세스를 따랐습니다. 프로세스가 불충분했으며, 이러한 개선이 재발을 방지할 것입니다.'"

3. 모니터링, 문서, 테스트가 없는 레거시 시스템을 상속받았습니다. 어디서 시작하시겠습니까?

전문가 답변: "폭발 반경으로 우선순위를 정합니다. 1주차: 기본 헬스 모니터링 추가. 2-4주차: 코드 읽기, 요청 흐름 추적, 종속성 매핑으로 시스템 아키텍처 문서화. 2개월차: 중요 경로에 대한 통합 테스트 추가. 3개월차: CI/CD 구현. 핵심 원칙은: 재작성하지 말고 안정화하라. 수년간 운영된 레거시 시스템은 수많은 엣지 케이스에서 살아남았습니다 — 교체하면 새로운 위험이 도입됩니다."

면접관에게 할 질문

1. "이 팀이 소유한 서비스의 SLO는 무엇이며, 오류 예산은 어떻게 관리되나요?" 팀이 SRE 원칙을 실천하는지 아니면 단지 직함만 사용하는지를 드러냅니다.

2. "온콜 로테이션은 어떻게 되나요 — 엔지니어 수, 페이지 양, 에스컬레이션 정책은?" 삶의 질에 직접 영향을 미치며 팀의 운영 건전성을 나타냅니다.

3. "팀은 프로젝트 작업(신뢰성 개선)과 운영 작업(인시던트 대응, 수고) 사이의 균형을 어떻게 맞추나요?" 팀이 엔지니어링 작업을 위한 여력이 있는지 아니면 화재 진압에 갇혀 있는지를 보여줍니다.

4. "팀의 사후 분석 접근법은 어떤가요 — 비난하지 않는 방식이며, 조치 항목의 완료율은 어떻습니까?" 팀의 인시던트 학습 문화를 드러냅니다.

5. "팀이 현재 직면한 가장 큰 신뢰성 과제는 무엇인가요?" 해결할 문제와 그것이 흥미로운지에 대한 통찰을 제공합니다.

핵심 요약

• SRE 면접은 특정 엔지니어링 사고방식을 테스트합니다: 신뢰성 정량화, 데이터 기반 트레이드오프, 운영을 소프트웨어 엔지니어링 문제로 취급.
• SLO, SLI, 오류 예산, 수고는 SRE의 어휘입니다 — 유창하게 사용하고 각각에 대한 실무 경험을 보여주세요.
• 진단 방법론, 의사소통 능력, 체계적 개선 사고를 보여주는 상세한 인시던트 이야기를 준비하세요.
• 시스템 설계 답변에는 명시적인 장애 모드, 우아한 성능 저하 전략, 가용성 목표가 포함되어야 합니다.

면접 단계에 이르기 위해 이력서가 준비되어 있는지 확인하고 싶으신가요? ResumeGeni의 무료 ATS 점수 확인 도구로 지원하기 전에 사이트 신뢰성 엔지니어 이력서를 최적화하세요.

자주 묻는 질문

SRE와 DevOps의 차이는 무엇인가요?

SRE는 규범적 실천을 가진 DevOps 원칙의 구체적 구현입니다: SLO, 오류 예산, 수고 예산, 개발 팀과의 정의된 참여 모델. DevOps는 개발과 운영 간 협업을 강조하는 더 넓은 문화적 운동입니다 [2].

SRE 면접에 어떤 프로그래밍 언어를 알아야 하나요?

Python과 Go가 SRE에서 가장 일반적으로 사용되는 언어입니다. Python은 스크립팅, 자동화, 운영 도구용. Go는 성능이 중요한 시스템 도구용 [3].

사이트 신뢰성 엔지니어로서 어떤 연봉을 기대해야 하나요?

연봉은 $128,842(PayScale 평균)에서 $169,680(Glassdoor 평균)까지이며, 75번째 백분위는 $213,272입니다 [1]. FAANG 기업의 시니어 SRE는 주식 보상을 포함하여 $300,000-$500,000+을 벌 수 있습니다.

면접 준비에 Google SRE 책은 얼마나 중요한가요?

매우 중요합니다. Google SRE 책은 대부분의 SRE 면접이 테스트하는 개념을 정의합니다: SLO, 오류 예산, 수고, 인시던트 관리, SRE 참여 모델 [2].

SRE 역할을 얻으려면 온콜 경험이 필요한가요?

온콜 경험이 강력히 선호되지만 입문 수준 SRE 직위에서 항상 요구되지는 않습니다. 동등한 기술을 보여주세요: 구축한 모니터링 시스템, 대응한 인시던트, 수동 운영을 줄이기 위해 만든 자동화.