Reliability Engineering & SRE Foundations

1. Overview

신뢰성 공학 및 SRE 기초(Reliability Engineering & SRE Foundations, SRE)는 구글이 제창한 "운영(Operations) 작업을 소프트웨어 공학의 문제로 취급한다"는 철학 아래, 시스템의 가용성(Availability)을 수학적으로 계산하고 통제하는 방법을 다룹니다.

과거의 운영자는 서버가 죽으면 밤을 새워 재부팅을 했지만, 현대의 사이트 신뢰성 엔지니어(SRE)는 "이 시스템은 한 달에 43분까지만 죽어도 된다"는 목표(SLO)를 정량적으로 합의합니다. 학습자는 100% 무결점이라는 환상을 버리고, 에러 예산(Error Budget)을 소모하며 혁신 속도와 안정성 사이의 트레이드오프를 통제합니다. 또한 시계열 메트릭(Metrics), 로그(Logs), 분산 트레이싱(Traces)이라는 3대 관측성(Observability) 무기를 장착하여 칠흑같이 어두운 마이크로서비스의 내부를 훤히 꿰뚫어 보는 통찰력을 확보합니다.

2. Scope & Boundaries

In-Scope

• 안정성 지표 모델 (Reliability Math): SLI(지표), SLO(목표), SLA(계약)의 수식적 정의와 에러 예산(Error Budget) 소진 거동.
• 관측성 스택 (Observability 3 Pillars): 시계열 메트릭(Prometheus), 구조화된 로그(Structured Logging), 분산 분산 트레이싱(OpenTelemetry, Jaeger).
• 자동화와 토일 관리 (Toil & Automation): 인간의 개입이 필요한 단순 반복 작업(Toil) 식별, 자가 치유(Self-healing) 스크립팅, 골든 시그널(Golden Signals) 4요소.
• 포스트모텀과 장애 대응 (Incident Management): 비난 없는(Blameless) 사후 분석 회고(Post-mortem), MTTR(복구 시간) 단축 전략.

Out-of-Scope

• DevOps 파이프라인(CI/CD) 구축: 젠킨스(Jenkins)나 깃허브 액션(GitHub Actions)을 이용한 코드 배포 자동화 → 09-03. DevOps & CI/CD 영역으로 위임.
• 단일 서버의 OS 커널 튜닝: 리눅스 커널 패닉 분석이나 메모리 페이징 최적화 → 03-02. Process & Concurrency 영역으로 위임.

Boundaries

• SRE vs. DevOps (09-03): DevOps가 "개발팀과 운영팀의 담장을 허물고 코드를 빨리 배포하자(CI/CD)"는 문화와 파이프라인에 가깝다면, SRE는 "빠르게 배포하되, 시스템이 정해진 예산 이상으로 불안정해지면 배포 파이프라인을 기계적으로 차단해라"라는 소프트웨어적 통제 메커니즘을 규정하는 역할(DevOps의 구체적 구현체)을 합니다.

3. Counterexample

• "100% 가동률 보장"이라는 허구 (SLO Fallacy): 비즈니스 부서에서 "우리 서비스는 절대 1초도 죽으면 안 됩니다"라고 요구할 때, 인프라 팀이 이에 동의하고 모든 예산을 서버 다중화에 쏟아붓는 행위. 스마트폰의 네트워크가 가끔 끊기는 사용자 환경을 고려하면 100%는 물리적으로 불가능할 뿐더러, 99.9%에서 99.99%로 올리는 데 드는 비용은 기하급수적입니다. SRE는 "비즈니스에 치명적이지 않은 적절한 불안정성(에러 예산)"을 합의하고, 남는 리소스를 속도(Feature Development)에 투자하지 않는 조직은 도태됩니다.
• 경보 피로와 무의미한 대시보드 (Alert Fatigue): CPU가 80%를 넘었다고 메일이 오고, 램이 90%를 넘었다고 슬랙 알림이 울려, 하루에 1,000개의 경보가 쏟아지는 모니터링 세팅. 결국 엔지니어는 알림을 '모두 읽음' 처리(경보 무감각)해 버리고 진짜 장애를 놓치게 됩니다. SRE의 모니터링은 "CPU가 높은 것"이 아니라 **"유저가 에러를 보았는가(사용자 체감)"**라는 증상(Symptom) 기반으로만 자다 깨서 대응(Page)해야 한다는 대원칙을 어긴 안티패턴입니다.

4. Prerequisites

• 네트워크 및 운영체제 기초 (Basic): 레이턴시(Latency), 트래픽(Traffic), 에러(Error), 포화도(Saturation)라는 SRE의 4대 골든 시그널을 이해하려면 네트워크 I/O와 OS 자원 모델에 대한 지식이 필수입니다. (03. OS, 08. Network)
• 고가용성 및 확장성 아키텍처 (Recommended): 장애 복구(Failover) 메커니즘을 알아야 에러 예산 방어 전략을 세울 수 있습니다. (07-03. SHA)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 안정성의 수학화 (SLI, SLO, SLA, Error Budget)

• Why to Learn: 개발자는 빨리 배포하고 싶어 하고 운영자는 변경을 막고 싶어 하는 영원한 갈등을, '숫자'라는 객관적 심판을 통해 기계적으로 통제하기 위함입니다.
• What to Learn:
  • Concepts: SLI(서비스 수준 지표), SLO(서비스 수준 목표), SLA(서비스 수준 계약).
  • Skills: 가용성(Availability) 수학 계산, 에러 예산(Error Budget) 산출 물리, 에러 예산 소진 정책(Freeze).
  • Tools: 예산 번다운 차트(Burn-down Chart).
  • Trade-offs: "99.999%(한 달 다운타임 26초)"를 지키려다 아무런 신기능도 배포하지 못하는 보수적 운영 vs "99%(한 달 다운타임 7시간)"로 타협하여 엄청난 개발 속도를 얻지만 고객 이탈률이 높아지는 비즈니스 리스크.
• How to Learn:
  • 1단계: 어떤 서비스의 SLI를 (HTTP 200 응답 수) / (전체 HTTP 요청 수)로 정의하고, 한 달에 100만 건의 요청이 올 때 99.9% SLO를 만족하려면 최대 1,000건의 에러(에러 예산)까지만 허용됨을 계산합니다.
  • 2단계: 셋째 주에 에러가 900건이 나버려 예산이 100건밖에 남지 않았을 때, 개발팀의 신규 배포 파이프라인이 자동 잠금(Freeze)되고 전원이 버그 수정(Reliability)에 투입되는 프로세스를 도식화합니다.
• Implement: 현재 진행 중인 토이 프로젝트의 메인 API에 대해 SLI(예: 0.2초 이내 응답 비율)를 정의하고, 99.5% SLO 달성을 위한 월간/주간 에러 허용치(Budget) 명세서 작성.

Recommended

Core Topic 02: 분산 관측성과 골든 시그널 (Observability Stack)

• Why to Learn: "서버가 느려요"라는 사용자의 막연한 불평을 들었을 때, 10초 만에 "A 서비스에서 DB를 찌르는 쿼리가 평소 10ms에서 300ms로 느려졌기 때문"이라는 물증을 잡아내기 위해서입니다.
• What to Learn:
  • Concepts: 관측성 3본주(Metrics, Logs, Traces), 카디널리티(Cardinality), 구글의 4대 골든 시그널(Latency, Traffic, Errors, Saturation).
  • Skills: 구조화된 로깅(JSON 형식), 분산 트레이싱(Trace ID, Span ID) 전파 메커니즘, 프롬퀄(PromQL) 기초.
  • Tools: Prometheus (Metrics), ELK/Loki (Logs), Jaeger/OpenTelemetry (Traces).
  • Trade-offs: 모든 함수의 실행 시간을 다 기록(Tracing)하여 디버깅이 완벽해지는 쾌감 vs 트레이싱 데이터가 애플리케이션 실제 데이터보다 10배나 커져버려 스토리지 파산(Storage Bankruptcy)을 초래하는 모니터링 과금 폭탄(샘플링으로 타협 필요).
• How to Learn:
  • 1단계: CPU가 95%를 쳤다는 메트릭(Metric) 알림을 받고 대시보드를 켭니다. 어느 시간대인지 확인 후, 해당 시간의 에러 로그(Log)를 검색하여 'PaymentTimeout'을 발견합니다.
  • 2단계: 그 에러 로그에 박혀 있는 TraceID: 1234abcd를 복사해 분산 트레이서(Jaeger)에 검색하여, 사용자의 클릭 한 번이 [웹 → 주문 → 결제 → 외부 은행 API]로 흘러가다가 정확히 은행 API에서 5초 지연이 발생했음을 시각적으로 짚어냅니다.
• Implement: 2개의 파이썬 API 서버(A가 B를 호출)를 띄우고, 첫 번째 서버에서 UUID(Trace ID)를 발급해 HTTP 헤더로 두 번째 서버에 넘겨주어, 중앙 로그 파일에 두 서버의 로그가 동일한 ID로 남도록 하는 Trace ID 전파 실험.

Practical

Core Topic 03: 반복 작업(Toil) 제거와 자동화 (Toil Engineering)

• Why to Learn: 엔지니어가 수동으로 재부팅 버튼을 누르거나 DB 용량을 늘려주느라 '엔지니어링(개선 작업)'을 할 시간을 뺏기는 악순환을 끊어내기 위함입니다.
• What to Learn:
  • Concepts: 토일(Toil)의 정의(수동, 반복, 자동화 가능, 전술적, O(N)으로 확장됨), SRE 업무 비율(운영 50%, 엔지니어링 50%).
  • Skills: 런북(Runbook/Playbook) 작성, 크론(Cron) 및 웹훅(Webhook) 기반 자가 치유(Self-healing) 스크립트 작성, 티켓 자동화.
  • Tools: Ansible, Python 스크립팅, Slack ChatOps.
  • Trade-offs: "서버 꽉 차면 지워주세요"라는 알람을 슬랙봇이 자동으로 처리하게 만드는 1주일의 개발 투자 vs 당장 5분 만에 수동으로 지우고 다른 일을 하는 유혹(하지만 1년 뒤에는 알람이 하루 100개씩 울림).
• How to Learn:
  • 1단계: 최근 1주일간 자신이 한 작업 목록을 적고, "새로운 가치 창출(Engineering)"과 "단순 유지보수(Toil)"를 분류하여 Toil이 50%를 넘지 않는지 분석합니다.
  • 2단계: "디스크 사용률 85% 알림 → SSH 접속 → /tmp 폴더 삭제 → 확인"이라는 수동 런북 절차를, 알림 시스템이 웹훅으로 람다(Lambda) 함수를 찔러 자동 삭제하게 만드는 자동화 파이프라인으로 전환합니다.
• Implement: 가상의 장애 상황("웹 서버의 특정 스레드가 교착 상태에 빠짐") 알람이 울리면, 모니터링 도구가 파이썬 스크립트를 자동 호출하여 덤프(Dump)를 뜬 뒤 해당 컨테이너만 재시작(Restart)하고 슬랙에 결과를 보고하는 치유 봇 모형.

Advanced

Core Topic 04: 블레임리스 포스트모텀과 장애 분석 (Blameless Post-mortem)

• Why to Learn: 장애를 낸 개발자를 해고해 버리면 시스템의 구조적 결함은 그대로 남아 다음 신입사원이 똑같은 장애를 내는 비극을 물리적으로 끊어내기 위함입니다.
• What to Learn:
  • Concepts: 비난 없는 사후 분석(Blameless Post-mortem), 심리적 안전감(Psychological Safety).
  • Skills: 타임라인 재구성, 근본 원인 분석(Root Cause Analysis, 5 Whys), 실행 가능한 액션 아이템(Action Item) 도출.
  • Tools: 포스트모텀 문서 템플릿.
  • Trade-offs: "담당자 철저 교육" 같은 정신론적 처방으로 회의를 빨리 끝내는 관료주의 vs "rm -rf를 치더라도 프로덕션 디렉토리에서는 거부되게끔 커널 레벨 권한을 회수한다"는 시스템적 방어 코드를 짜넣는 고비용 엔지니어링.
• How to Learn:
  • 1단계: 대규모 DB 날림 장애 시나리오를 놓고, "김 대리가 쿼리를 잘못 짰다"가 아니라 "왜 테스트 DB에 날려야 할 쿼리가 프로덕션 DB로 들어갈 수 있는 구조였나?"(5 Whys)를 집요하게 추궁합니다.
  • 2단계: 그 결과, '개발망과 운영망의 터미널 배경색이 똑같았다'는 인지적 오류를 발견하고, 접속 환경별 프롬프트 색상 자동 변경 쉘 스크립트 강제화라는 시스템적 해결책(Action Item)을 도출합니다.
• Implement: 과거 본인이 겪은 치명적인 코드 버그나 깃(Git) 실수 하나를 골라, SRE 표준 포스트모텀 양식(장애 발생 일지, 영향도, 근본 원인 분석 5 Whys, 재발 방지 엔지니어링 티켓 3개)으로 정리한 문서 발행.

7. Terminology

8. References

Primary References

• [P5] SFIA - System Management / Service Level Management — Industry standard roles.
• [P2] SWEBOK v4.0 - Software Construction / Maintenance — Reliability and operational lifecycle.

Secondary References

• [Site Reliability Engineering (The SRE Book)] Google — Foundational implementation.
• [Observability Engineering] Charity Majors et al. — Modern observability depth.

Industry References

• [Google SRE Workbook] — Practical checklists and case studies.
• [AWS Reliability Pillar - Well-Architected] — Cloud native reliability patterns.

9. Final Checklist

Primary Checklist

• 시스템의 현재 '가용성'을 5가지 핵심 SLI(예: Error rate, Latency)를 통해 수치로 리포팅할 수 있는가? (P5)
• 에러 예산이 소진되었을 때, 신규 기능 배포를 멈추어야 하는 이유를 물리적 안정성 관점에서 변론 가능한가? (P5)

Secondary Checklist

• 단순 모니터링만으로 해결되지 않는 복잡한 장애를 '분산 트레이싱'을 통해 어떻게 물리적 근본 원인(Root Cause)을 찾는지 인지하는가?
• 재시도(Retry) 전략이 시스템 전체에 '재시도 폭풍(Retry Storm)'을 일으켜 상황을 악화시킬 수 있는 리스크를 예측하는가?

Industry Checklist

• 프로덕션 환경에 카오스 엔지니어링 도구를 도입하여 장애 전파 방지 장치(서킷 브레이커 등)의 유효성을 실증 가능한가? (SFIA)
• 장애 발생 시 포스트모텀(Post-mortem)을 통해 인적 오류가 아닌 시스템의 구조적 결함을 찾아내고 자동화 개선안을 도출할 수 있는가?