시니어 DevOps / SRE 면접 질문

시니어 레벨에서 기대되는 것

신뢰성 아키텍처, SLO 전략, 조직 전반의 운영 리더십이 요구됩니다.

DevOps / SRE 면접 질문 예시

• 기술 면접어떤 서비스가 느립니다. OS 수준부터 차례로 어떻게 디버깅할지 설명하세요.
  좋은 답변이 다루는 것

  • top-down debugging 순서: OS 수준 → 네트워크 → 애플리케이션
  • CPU, 메모리, 디스크 I/O, 네트워크 병목 확인 도구 사용
  • strace/perf를 활용한 시스템 콜 분석
  • 공통 병목: I/O wait, swap, 컨텍스트 스위칭, 락 경합

  샘플 답변 보기

  서비스가 느릴 때는 OS 수준에서부터 체계적으로 원인을 좁혀가야 합니다. 먼저 `uptime`으로 시스템 부하를 확인하고, `top`/`htop`으로 CPU 사용률과 메모리 사용량을 점검합니다. CPU가 높다면 특정 프로세스가 CPU를 독점하는지 확인하고, 메모리 부족 시 swap 사용량을 `vmstat`으로 확인합니다. 디스크 I/O는 `iostat`으로, 네트워크는 `netstat`/`ss`로 연결 상태와 대기열을 봅니다. `strace`를 사용해 느린 시스템 콜을 추적하거나 `perf`로 CPU 프로파일링을 수행할 수 있습니다. 이후 애플리케이션 레벨로 진입해, jstack(Java), pprof(Go) 등의 프로파일러로 병목 지점을 찾습니다. 흔한 실수는 OS 지표를 확인하지 않고 바로 애플리케이션 코드를 분석하는 것입니다. 예를 들어, I/O wait이 높은데 디스크 문제를 무시하면 근본 원인을 놓칠 수 있습니다.

• 기술 면접URL을 입력하고 엔터를 누르면 단계별로 무슨 일이 일어나나요?
  좋은 답변이 다루는 것

  • DNS 조회 (캐시, 재귀 쿼리)
  • TCP 3-way handshake
  • TLS 핸드셰이크 (1.3 기준 1-RTT)
  • HTTP 요청/응답, 브라우저 렌더링
  • TCP 연결 재사용 (Keep-Alive)

  샘플 답변 보기

  URL을 입력하고 엔터를 누르면 첫 단계는 브라우저 캐시에서 DNS 레코드를 확인하고, 없다면 OS 캐시, 로컬 DNS 서버로 재귀 쿼리를 보내 IP를 얻습니다. 이후 브라우저는 대상 IP와 포트(80/443)로 TCP 3-way handshake(SYN, SYN-ACK, ACK)를 수행합니다. HTTPS라면 TLS 핸드셰이크가 추가되어 암호화 협상 및 인증서 검증이 이루어집니다 (TLS 1.3은 1-RTT). 그 다음 HTTP GET 요청을 전송하고 서버는 응답(HTML 등)을 반환합니다. 브라우저는 HTML을 파싱하여 DOM 트리를 구성하고, 추가 리소스(CSS, JS, 이미지)를 병렬로 요청합니다. 각 리소스는 이미 맺어진 TCP 연결을 재사용(Keep-Alive)할 수 있습니다. 마지막으로 브라우저는 렌더링 트리를 생성해 화면에 페이지를 표시합니다. 전체 과정에서 네트워크 지연, DNS 해상도, TLS 오버헤드가 주요 레이턴시 요소입니다.

• 기술 면접Kubernetes의 liveness와 readiness 프로브는 어떻게 다른가요?
  좋은 답변이 다루는 것

  • liveness: 컨테이너 재시작 여부 결정
  • readiness: 트래픽 수신 여부 결정
  • 실패 시 동작 차이: 재시작 vs 서비스에서 제외
  • 프로브 타입: HTTP, TCP, exec
  • startup probe: 초기화 지연 대응

  샘플 답변 보기

  Kubernetes에서 liveness 프로브는 컨테이너가 정상 동작하는지 확인하고, 실패 시 kubelet이 컨테이너를 재시작합니다. 반면 readiness 프로브는 컨테이너가 트래픽을 받을 준비가 되었는지 확인하며, 실패 시 해당 파드는 서비스 엔드포인트에서 제외되어 트래픽을 받지 않습니다. 둘 다 HTTP GET, TCP 소켓, exec 명령 등 동일한 방식으로 설정할 수 있지만, 목적이 다릅니다. 일반적인 실수는 liveness와 readiness에 동일한 엔드포인트를 사용하는 것입니다. 예를 들어, 읽기 전용 상태에서 readiness만 실패해야 하는데 liveness도 실패하면 불필요한 재시작이 발생합니다. 또한, 초기화 시간이 긴 애플리케이션은 startup 프로브를 사용해 liveness/readiness 검사를 지연시켜야 합니다.

• 코딩로그를 파싱해 상위 에러율을 보고하는 스크립트를 작성하세요.
  좋은 답변이 다루는 것

  • 정규식 기반 로그 파싱
  • 에러 타입별 카운트 집계
  • 전체 로그 대비 에러율 계산
  • 상위 N개 에러 타입 정렬 출력
  • 잘못된 라인 처리 (try/except)

  샘플 답변 보기

  다음 Python 스크립트는 로그 파일을 읽어 정규식으로 에러 메시지를 추출하고, 에러 타입별로 카운트를 집계한 후 전체 대비 에러율을 계산해 상위 5개를 출력합니다. 시간 복잡도는 O(n + m log m)이며, n은 로그 라인 수, m은 고유 에러 타입 수입니다. 공간 복잡도는 O(m)입니다.

  #!/usr/bin/env python3
  """
  로그 파일을 파싱하여 에러 타입별 상위 에러율을 출력합니다.
  사용법: python parse_logs.py <logfile>
  """
  import sys
  import re
  from collections import defaultdict
  
  def main():
      if len(sys.argv) < 2:
          print("Usage: python parse_logs.py <logfile>")
          sys.exit(1)
      
      logfile = sys.argv[1]
      
      # 예시 정규식: "ERROR: <error_type>" 패턴
      error_pattern = re.compile(r'ERROR:\s*(\S+)')
      
      total_lines = 0
      error_counts = defaultdict(int)
      
      with open(logfile, 'r', encoding='utf-8') as f:
          for line in f:
              total_lines += 1
              match = error_pattern.search(line)
              if match:
                  error_type = match.group(1)
                  error_counts[error_type] += 1
      
      if total_lines == 0:
          print("No log lines found.")
          return
      
      # 에러율 계산 및 정렬 (내림차순)
      error_rates = []
      for err_type, count in error_counts.items():
          rate = count / total_lines * 100
          error_rates.append((rate, err_type, count))
      
      error_rates.sort(reverse=True)
      
      # 상위 5개 출력
      print(f"Top 5 errors (total lines: {total_lines}):")
      for rate, err_type, count in error_rates[:5]:
          print(f"{err_type}: {rate:.2f}% ({count} occurrences)")
  
  if __name__ == "__main__":
      main()

• 시스템 설계안전하고 점진적인 프로덕션 롤아웃을 갖춘 CI/CD 파이프라인을 설계하세요.
  좋은 답변이 다루는 것

  • CI: 빌드, 테스트, 정적 분석, 보안 스캔 자동화
  • CD: 아티팩트 승격, 스테이징 배포, 카나리 배포
  • 점진적 롤아웃: 트래픽 비율 증가, 자동 롤백
  • 모니터링 메트릭 (에러율, 레이턴시, 트래픽) 기반 결정
  • 도구 예시: Jenkins/GitLab CI, Spinnaker/ArgoCD, Istio

  샘플 답변 보기

  안전한 CI/CD 파이프라인은 크게 CI와 CD 단계로 나뉩니다. CI 단계에서는 커밋이 푸시될 때마다 코드 빌드, 유닛 테스트, 정적 분석, 보안 스캔을 자동 실행하고, 성공 시 도커 이미지를 레지스트리에 푸시합니다. CD 단계에서는 먼저 스테이징 환경에 배포하여 통합 테스트를 수행한 후, 프로덕션에는 점진적으로 배포합니다. 점진적 롤아웃은 카나리 배포나 블루-그린 배포를 사용하는데, 예를 들어 Spinnaker나 Argo Rollouts을 활용해 5% 트래픽을 먼저 보내고, 에러율과 레이턴시를 모니터링한 후 자동으로 25%, 50%, 100%로 확장합니다. 에러율이 임계치를 초과하면 즉시 롤백합니다. 또한, 기능 플래그를 사용해 특정 기능을 동적으로 활성화/비활성화할 수 있습니다. 자주 간과되는 점은 롤아웃 전에 세부 메트릭(예: p99 레이턴시)에 대한 명확한 SLO를 정의하고, 롤백 자동화를 철저히 테스트하는 것입니다. Istio 같은 서비스 메시를 사용하면 트래픽 분할과 메트릭 수집이 더 용이합니다.

• 시스템 설계멀티 리전 서비스의 모니터링과 알림을 설계하세요.
  좋은 답변이 다루는 것

  • 리전별 대시보드 + 글로벌 통합 뷰 (Thanos, Grafana)
  • 레이턴시(p99), 에러율, 포화도, 트래픽 지표
  • 합성 모니터링 (CloudWatch Synthetics, Pingdom)
  • 알림 규칙: 리전 이상 감지 + 글로벌 SLO 위반
  • 알림 중복 방지 및 에스컬레이션 정책

  샘플 답변 보기

  멀티 리전 모니터링은 각 리전의 메트릭을 개별적으로 수집하면서 글로벌 통합 뷰를 제공해야 합니다. Prometheus를 리전별로 운영하고 Thanos를 사용해 글로벌 쿼리와 장기 저장소를 구현합니다. 대시보드에는 각 리전의 p99 레이턴시, 에러율, 처리량을 한눈에 볼 수 있도록 하고, 글로벌 집계 지표도 표시합니다. 합성 모니터링을 통해 사용자 관점의 가용성을 리전별로 체크합니다. 알림은 각 리전의 임계치 기반 알림과 함께 글로벌 SLO(예: 5분 내 가용성 99.9%) 위반을 감지하는 규칙을 설정합니다. 예를 들어 한 리전의 에러율이 5%를 넘으면 경고를 보내지만, 전체 글로벌 가용성이 SLO 이하일 때만 페이지를 발송하도록 합니다. 또한 알림 피로를 줄이기 위해 리전 간 연관성을 고려한 집계 알림(RBAC, deduplication)을 적용하고, 장애 시 리전 장애 대응 runbook을 준비합니다.

• 행동 면접주도한 인시던트와 포스트모템 조치를 설명해 주세요.
  좋은 답변이 다루는 것

  • Situation: 데이터베이스 복제 지연으로 읽기 장애 발생
  • Task: 장애 복구 및 재발 방지 조치
  • Action: 인시던트 커맨더 역할, Read Replica 승격, 커뮤니케이션
  • Result: 복구 시간 단축, 장애 영향 최소화
  • Postmortem: 근본 원인 분석 (장기 실행 쿼리), 모니터링 개선, 쿼리 최적화

  샘플 답변 보기

  제가 리드한 주요 인시던트는 데이터베이스 복제 지연으로 인해 읽기 요청에 오래된 데이터를 반환하는 문제였습니다. 상황은 서비스가 읽기 복제본에서 데이터를 읽도록 설계되어 있었는데, 특정 배치 작업이 긴 트랜잭션을 발생시켜 복제가 5분 이상 지연되었습니다. 인시던트 커맨더로서 먼저 장애 등급을 정의하고(SEV-2), 관련 팀에 상태를 공유했습니다. 조치로는 읽기 작업을 마스터로 전환하는 설정을 변경하고, 해당 배치 작업을 중단했습니다. 약 15분 만에 서비스가 정상화되었습니다. 포스트모템에서는 타임라인을 작성하고, 근본 원인인 장기 실행 쿼리를 식별했습니다. 행동 항목으로는 복제 지연 메트릭에 임계치 기반 알림 추가, 장기 실행 쿼리 워닝 시스템 구축, 배치 작업을 비즈니스 시간 외로 조정, 그리고 읽기 복제본 장애 시 자동 페일오버 runbook을 작성했습니다. 이 경험을 통해 모니터링의 중요성과 사전 예방적 조치의 가치를 배웠습니다.

• 행동 면접신뢰성 작업과 기능 요청을 어떻게 균형 잡나요?
  좋은 답변이 다루는 것

  • Error budget 기반 우선순위 (SLO 초과 시 기능 중단)
  • 데이터 기반 의사결정 (장애 비용 vs 기능 가치)
  • 정기적 신뢰성 스프린트/버킷 할당 (예: 20%)
  • 이해관계자 커뮤니케이션 (SLO, 장애 영향 공유)
  • 신뢰성 문화 구축: 온콜 보상, 포스트모템 공유

  샘플 답변 보기

  신뢰성 작업과 기능 요청의 균형은 Error Budget을 통해 관리합니다. 서비스에 SLO(예: 가용성 99.9%)를 정의하고, 초과분을 Error Budget으로 축적합니다. Budget이 남아 있으면 기능 개발을 허용하고, 소진되면 기능 출시를 중단하고 신뢰성 개선에 집중합니다. 예를 들어, 한 분기 동안 장애가 많아 Budget이 바닥나면, 다음 스프린트는 전적으로 안정성 작업(예: 모니터링 강화, 용량 계획)에 할당합니다. 제품 관리자와의 협의 시에는 장애로 인한 사용자 이탈 비용과 기능의 예상 이익을 비교해 우선순위를 정합니다. 또한 정기적으로 20%의 시간을 기술 부채와 신뢰성 개선에 투자하고, 포스트모템을 통해 배운 점을 팀 전체와 공유합니다. 중요한 것은 신뢰성 작업을 단순히 '비용'으로 보지 않고 장기적 제품 가치의 일부로 인식하는 문화를 만드는 것입니다.

면접관이 평가하는 것

준비 방법

• 제1원리에서 디버깅하세요 — 면접관은 체계적이고 계층적인 접근을 원합니다.
• 답변을 SLO, 에러 버짓, 비난 없는 포스트모템을 중심으로 구성하세요.
• 답변에서 모든 것을 자동화하세요. 수동 단계는 위험 신호로 읽힙니다.

자주 묻는 질문