SRE란 무엇인가: 운영을 엔지니어링으로 바꾸는 구글의 철학

1. 서비스를 운영한다는 것

서비스를 운영하다 보면 장애는 피할 수 없다는 걸 알게 된다. 트래픽이 몰리면 DB Connection Pool이 터지고, 메모리가 부족해서 Redis가 죽고, 배포하고 나면 예상 못한 에러가 튀어나온다.

이런 상황을 처음 공부하면서 든 의문이 있었다.

"Critical Alert: API Response Time > 5000ms"

이런 알림을 받으면 어떻게 해야 하지? 서버 재시작? 스케일 아웃? 그게 반복되면 어디서부터 근본적으로 고쳐야 할까?

단순히 장애를 끄는 게 아니라, 장애가 덜 나는 시스템을 만드는 방법이 있을 것 같았다. 그러다 구글이 만든 SRE (Site Reliability Engineering) 책을 읽고 머리를 한 대 맞은 것 같았다.

2. 운영은 '노가다'가 아니다

구글은 이렇게 정의한다. "SRE는 운영 문제를 소프트웨어 엔지니어링으로 해결하는 것이다."

반복적인 장애 대응, 수동 배포 같은 작업은 SRE 용어로 Toil(노가다)이다. 훌륭한 SRE 팀은 이 Toil을 50% 이하로 줄이고, 나머지 50%는 '시스템을 개선하는 코딩'에 쓴다.

"운영팀은 개발팀이 싸지른 똥을 치우는 팀이 아니다. 시스템의 신뢰성을 코드로 보장하는 팀이다." 이 문장이 운영에 대한 시각을 바꿔줬다.

3. 핵심 개념 3형제: SLI, SLO, Error Budget

SRE를 이해하려면 이 3가지만 알면 됩니다.

3.1. SLI (Service Level Indicator): 측정기

"우리 서버 건강해요?"라고 물으면 대답하기 어렵습니다. 대신 숫자로 말해야 합니다.

요청 성공률 (Availability): 전체 요청 중 200 OK 비율
지연 시간 (Latency): 상위 99% 요청이 얼마나 빠른가 (P99)
처리량 (Throughput): 초당 처리 요청 수 (RPS)

이 측정값들이 바로 SLI다. 모니터링 대시보드(Grafana)에 이 3가지를 가장 잘 보이는 곳에 배치하는 게 시작이다.

3.2. SLO (Service Level Objective): 목표

SLI를 측정했으면 목표를 정해야 한다. "가용성 100%를 목표로 하자!" ...라고 말하고 싶지만, SRE 관점에서 이건 잘못된 목표다.

가용성 100%는 불가능할뿐더러, 비용이 기하급수적으로 든다. 99.9%면 충분하다. (월 다운타임 43분 허용) 99.99%면 훌륭하다. (월 다운타임 4분 허용)

서비스 특성에 맞게 "응답 시간 P95 < 500ms" 같은 구체적인 SLO를 세우는 게 핵심이다.

3.3. Error Budget (에러 예산) - 실패할 권리

이게 가장 재밌는 개념이다. SLO가 99.9%라면, 나머지 0.1%는 "실패해도 되는 여유분"이다. 이를 Error Budget이라고 부른다.

한 달에 43분은 서버가 죽어도 된다.
이 예산이 남아있다면? -> 공격적으로 배포하고, 실험적인 기능을 출시한다.
이 예산을 다 썼다면? -> 모든 배포를 중단(Freeze)하고, 안정화에만 집중한다.

이 규칙이 생기면 개발팀과 운영팀의 우선순위 다툼이 줄어든다는 걸 구글 SRE 사례에서 볼 수 있다. "예산 남았으니 배포하시죠." "예산 다 썼으니 이번 주는 배포 금지입니다. 리팩터링 합시다."

4. 소방관에서 건축가로

SRE 철학을 이해하고 나면, 운영에 대한 접근 방식이 달라진다.

자동화: 서버 재시작 스크립트를 짜서, 특정 임계치(Threshold)를 넘으면 알아서 재시작하게 한다. (Self-Healing)
포스트모템 (Postmortem): 장애가 나면 "누가 실수했어!"를 따지는 대신, "왜 시스템이 그 실수를 막지 못했나?"를 분석하는 보고서를 쓴다.
카나리 배포 (Canary Deployment): 전체 사용자에게 한 번에 배포하지 않고, 5% 사용자에게만 먼저 배포해서 위험을 검증한다.

불을 끄러 다니는 소방관이 아니라, 불이 잘 안 나는 건물을 짓고 불이 나도 스프링클러가 바로 터지는 시스템을 설계하는 건축가. SRE가 지향하는 롤이 이거다.

5. 카오스 엔지니어링 (Chaos Engineering) - 불 끄는 연습

여기서 한 발짝 더 나아가면, "일부러 불을 질러보는" 단계에 도달한다. 넷플릭스의 '카오스 몽키(Chaos Monkey)'가 유명하다. 멀쩡히 돌아가는 서버를 랜덤하게 꺼버리는 툴이다.

"무모한 거 아니야?" 라고 생각할 수 있지만, 논리는 간단하다. "어차피 장애는 난다. 그렇다면 우리가 통제 가능한 상황(업무 시간)에 일부러 내보고, 시스템이 자동으로 복구되는지 확인하자."

예를 들어 업무 시간 중에 웹 서버 하나를 강제로 종료하는 테스트를 해보면, 로드 밸런서가 죽은 서버를 제외하고 트래픽을 자동으로 분산하는지 확인할 수 있다. 이 과정을 통제된 환경에서 먼저 경험해보는 게 카오스 엔지니어링의 핵심이다.

6. SRE를 위한 도구 상자 (Toolbox)

SRE를 시작하고 싶은데 뭘 써야 할지 모르는 분들을 위한 추천 도구들입니다.

6.1. 모니터링 & 시각화

Prometheus: 시계열 데이터(Metric) 수집의 표준. "CPU 사용률", "메모리 사용량" 등을 긁어옵니다.
Grafana: 수집한 데이터를 예쁜 그래프로 보여줍니다. 개발자들이 가장 사랑하는 대시보드 툴입니다.

6.2. 로그 분석

ELK Stack (Elasticsearch, Logstash, Kibana): 로그를 수집하고 검색합니다. "어떤 에러 로그가 가장 많이 떴지?"를 찾을 때 씁니다.
Loki: 그라파나 랩스에서 만든 가벼운 로그 시스템. Prometheus와 궁합이 좋습니다.

6.3. 알림 (Alerting)

PagerDuty: 장애 발생 시 담당자에게 전화/문자를 날려주는 온콜 알림 서비스다. 새벽에 담당자를 깨우는 바로 그 알림이다.
Slack Webhook: 덜 긴급한 알림은 슬랙 채널로 보냅니다.

7. 자주 묻는 질문 (FAQ)

Q. 데브옵스(DevOps)랑 뭐가 다른가요? A. 구글은 이렇게 말합니다. "DevOps는 인터페이스(철학)이고, SRE는 클래스(구현)이다." DevOps가 "개발팀과 운영팀이 협력해야 한다"는 문화적 운동이라면, SRE는 "그걸 어떻게 할 건데?"에 대한 구체적인 방법론(SLO, Error Budget 등)을 제시합니다.

Q. 작은 스타트업에도 필요한가요? A. 전담 팀을 꾸릴 필요는 없지만, '마인드셋'은 필요합니다. 개발자 3명인 회사라도 "로그는 어디에 남기지?", "서버 죽으면 누가 알림 받지?"는 정해야 하니까요. 그게 바로 SRE의 시작입니다.

Q. 수학을 잘해야 하나요? A. 기본 통계는 알면 좋습니다. 평균(Average)보다는 백분위수(Percentile, P95, P99)를 훨씬 많이 씁니다. 평균은 튀는 값(Outlier)에 왜곡되기 쉽기 때문입니다.

8. 마무리 - "희망은 전략이 아니다"

구글 SRE 책에 나오는 유명한 말입니다. "Hope is not a strategy."

"제발 이번 배포 때는 에러 안 나게 해주세요"라고 기도하는 건 엔지니어링이 아닙니다. 실패를 가정하고, 측정하고, 허용 범위를 합의하는 것이 엔지니어링입니다.

여러분의 서비스는 어떤가요? "서버가 느려요"라는 사용자의 불평에 "기분 탓입니다"라고 대답하고 있진 않나요? 지금 바로 Grafana를 켜고 여러분의 SLI를 확인해 보세요.