🛡️
시니어 백엔드 면접 질문 2편 - 운영/안정성 (5~10년차)
April 27, 2023
시니어 개발자에게 운영 경험은 필수입니다. 장애가 났을 때 어떻게 대응하는지, 시스템을 얼마나 안정적으로 운영할 수 있는지가 핵심입니다.
시리즈 구성:
- 1편: 인프라/스케일링 - 트래픽, DB, 분산시스템
- 2편 (현재): 운영/안정성 - 장애대응, 이벤트 아키텍처, 배포
- 3편: 설계/리더십 - 의사결정, 시스템디자인, 코드리뷰
1. 장애 대응과 복원력
Q1. 외부 API 호출하는 서비스가 느려지면 전체 시스템에 어떤 영향이 있나요?
기대 답변: 스레드 풀이 고갈되어 다른 요청도 처리 못하게 됩니다. 연쇄적으로 전체 시스템이 멈출 수 있습니다 (Cascading Failure).
🔄 꼬리질문 1: 서킷 브레이커(Circuit Breaker)가 뭔가요?
기대 답변: 외부 호출 실패가 임계치를 넘으면 회로를 열어 빠르게 실패 처리합니다.
- Closed: 정상 호출
- Open: 호출 차단, 즉시 fallback 반환
- Half-Open: 일정 시간 후 테스트 호출
Resilience4j, Hystrix(deprecated) 등으로 구현합니다.
🔄 꼬리질문 2: Fallback은 어떻게 설계하시겠어요?
기대 답변:
- 캐시된 이전 데이터 반환
- 기본값 반환
- 기능 제한 (추천 기능 비활성화 등)
- 에러 메시지와 함께 graceful degradation
🔄 꼬리질문 3: Timeout은 어떻게 설정하시나요?
기대 답변:
- 외부 API의 P99 응답시간 기준으로 설정 (보통 2~3초)
- Connection Timeout과 Read Timeout 분리
- 너무 길면 스레드 점유, 너무 짧으면 정상 응답도 실패 처리
- 실제 트래픽 기반으로 지속 튜닝
2. 이벤트 기반 아키텍처
Q2. 동기 API 대신 이벤트 기반 아키텍처를 선택하는 기준은?
기대 답변:
- 즉각적인 응답이 필요 없는 경우
- 서비스 간 결합도를 낮추고 싶을 때
- 데이터 일관성보다 가용성이 중요할 때 (Eventual Consistency 허용)
- 처리량이 급증해도 버퍼링이 필요할 때
🔄 꼬리질문 1: Kafka를 쓴다면 Consumer 장애 시 메시지 유실은 어떻게 방지하나요?
기대 답변:
- Auto Commit 비활성화: 처리 완료 후 수동 커밋
- At-least-once: 중복 허용, 멱등 처리로 보완
- Dead Letter Queue: 재처리 불가 메시지 별도 보관
- Consumer Group 리밸런싱 전략 설정
🔄 꼬리질문 2: 메시지 순서 보장은 어떻게 하나요?
기대 답변: Kafka에서 같은 파티션 내에서만 순서 보장됩니다.
- 순서가 중요한 데이터는 같은 키(예: 사용자 ID)로 같은 파티션에 보냄
- 파티션 수 늘리면 순서 보장 범위도 고려해야 함
🔄 꼬리질문 3: 이벤트 소싱(Event Sourcing)과 CQRS를 설명해주세요.
기대 답변:
- Event Sourcing: 상태 대신 이벤트(변경 이력)를 저장. 현재 상태는 이벤트 리플레이로 복원.
- CQRS: Command(쓰기)와 Query(읽기) 모델 분리. 각각 최적화 가능.
- 복잡도가 높아 모든 상황에 적합하지 않음. 감사 로그 필수, 복잡한 도메인에서 고려.
3. 배포와 운영
Q3. 무중단 배포는 어떻게 하시나요?
기대 답변:
- Rolling Update: 점진적 교체. K8s 기본 전략.
- Blue-Green: 두 환경 준비 후 트래픽 스위칭.
- Canary: 일부 트래픽만 새 버전으로. 문제 발견 시 빠른 롤백.
🔄 꼬리질문 1: DB 스키마 변경이 있을 때는 어떻게 하나요?
기대 답변:
- Backward Compatible 변경 유지: 컬럼 추가는 OK, 삭제/이름변경은 위험
- Expand-Contract 패턴:
- 새 컬럼 추가 (기존 코드 영향 없음)
- 새 코드 배포 (새 컬럼 사용)
- 기존 컬럼 삭제 (완전히 전환 후)
- Flyway, Liquibase로 마이그레이션 버전 관리
🔄 꼬리질문 2: Feature Flag는 왜 쓰나요?
기대 답변:
- 배포와 릴리스 분리: 코드는 배포하되 기능은 비활성화
- A/B 테스트, 점진적 롤아웃
- 장애 시 빠른 기능 비활성화
- LaunchDarkly, Unleash 같은 도구 활용
🔄 꼬리질문 3: 롤백 기준은 어떻게 정하시나요?
기대 답변:
- Error Rate: 특정 임계치 초과 시 (예: 1% 이상)
- Latency: P99 응답시간 급증
- Business Metrics: 전환율, 결제 성공률 등 핵심 지표 이상
- 자동화된 롤백(Automated Rollback)과 알림 설정
4. 모니터링과 옵저버빌리티
Q4. 모니터링과 옵저버빌리티의 차이는 뭔가요?
기대 답변:
- 모니터링: 미리 정의한 지표를 수집하고 대시보드로 확인. “알고 있는 문제” 감지.
- 옵저버빌리티: 로그, 메트릭, 트레이스를 통해 “모르는 문제”도 추적 가능. 시스템 내부 상태를 외부에서 파악.
🔄 꼬리질문 1: 옵저버빌리티의 세 가지 축(Pillar)은 뭔가요?
기대 답변:
- Logs: 개별 이벤트 기록. 디버깅에 필수.
- Metrics: 집계된 수치. 트렌드 파악, 알림 설정.
- Traces: 요청의 전체 흐름 추적. 분산 시스템 디버깅.
🔄 꼬리질문 2: 분산 트레이싱을 어떻게 구현하나요?
기대 답변:
- Trace ID: 요청마다 고유 ID 부여, 모든 서비스에 전파
- Span: 각 서비스에서의 작업 단위
- 도구: Jaeger, Zipkin, OpenTelemetry
- 로그에 Trace ID 포함하여 연관 검색 가능
🔄 꼬리질문 3: 알림 피로(Alert Fatigue)는 어떻게 방지하나요?
기대 답변:
- 알림 우선순위: P1(즉시 대응), P2(업무시간), P3(모니터링)
- 그룹핑: 동일 이슈 알림 묶기
- Runbook: 알림별 대응 절차 문서화
- 주기적 리뷰: 의미 없는 알림 제거
5. 장애 복구와 포스트모템
Q5. 장애가 발생하면 어떤 순서로 대응하시나요?
기대 답변:
- 탐지: 알림 또는 모니터링으로 인지
- 완화: 롤백, 스케일업, 트래픽 차단 등 즉각 조치
- 원인 분석: 로그, 메트릭, 트레이스 분석
- 해결: 근본 원인 수정
- 포스트모템: 재발 방지책 수립
🔄 꼬리질문 1: 포스트모템에는 어떤 내용이 들어가나요?
기대 답변:
- 타임라인: 언제 발생, 언제 인지, 언제 해결
- 영향 범위: 영향받은 사용자 수, 시간
- 근본 원인: 왜 발생했는지
- 재발 방지: 어떻게 막을 것인지 (액션 아이템)
- Blame-free: 개인 탓 아닌 시스템 개선 관점
🔄 꼬리질문 2: RTO와 RPO가 뭔가요?
기대 답변:
- RTO (Recovery Time Objective): 복구 목표 시간. 장애 후 얼마 안에 복구해야 하는가.
- RPO (Recovery Point Objective): 복구 목표 시점. 얼마만큼의 데이터 손실을 허용하는가.
- 비즈니스 요구사항에 따라 백업 주기, 복제 전략 결정
🔄 꼬리질문 3: Chaos Engineering 해보신 적 있나요?
기대 답변: 의도적으로 장애를 주입하여 시스템 복원력을 테스트하는 방법입니다.
- Netflix Chaos Monkey: 랜덤 인스턴스 종료
- Gremlin, LitmusChaos 등 도구 활용
- 프로덕션 적용 전 스테이징에서 충분히 테스트
마무리: 2편 핵심 정리
- 장애 대응: 서킷 브레이커, Fallback, Timeout 전략
- 이벤트 아키텍처: Kafka 유실 방지, 순서 보장, CQRS
- 배포: 무중단 배포, DB 스키마 변경, Feature Flag
- 옵저버빌리티: Logs/Metrics/Traces, 분산 트레이싱
- 복구: 포스트모템 문화, RTO/RPO, Chaos Engineering
다음 편에서는 설계 의사결정, 시스템 디자인, 코드 리뷰를 다룹니다.