SRE 란? 에러 예산으로 운영을 소프트웨어처럼 다루는 법
요약
SRE 란 운영 업무를 소프트웨어 엔지니어링으로 처리하는 방식입니다. 팀은 SLO라는 신뢰성 목표를 숫자로 정하고, 에러 예산으로 배포 속도와 안정성의 균형을 맞추며, 반복적인 수작업인 톨을 50% 아래로 줄입니다.
새벽 3시에 같은 디스크 경고로 호출기가 울린다면, 매달 똑같은 일을 손으로 반복하고 있는 겁니다. SRE 란 운영 업무를 수작업이 아니라 소프트웨어 엔지니어링으로 처리하는 방식입니다. SRE 팀은 서비스가 지켜야 할 신뢰성 목표를 숫자로 정하고, 그 숫자를 측정하고, 서비스를 유지하는 반복 작업을 자동화합니다.
Google이 이 개념을 정리한 것은 2003년 무렵입니다. 지금은 Google 밖에서도 널리 쓰여서, 직원 20명 규모의 스타트업부터 은행까지 도입하고 있습니다. 규모는 달라도 핵심 원리는 같습니다.
SRE 엔지니어는 실제로 무엇을 하나요?
Google SRE 팀을 시작한 Ben Treynor Sloss는 Google SRE 책의 첫 장에서 이렇게 말합니다. SRE는 소프트웨어 엔지니어에게 운영 팀을 설계하라고 했을 때 나오는 결과물이라고요. 운영 업무를 코드로 하는 일이라는 뜻입니다.
평범한 한 주에도 할 일은 네 가지입니다. 서비스에서 '정상'이 무엇인지 정의합니다. 그 상태가 깨졌을 때 알려 주는 모니터링을 만듭니다. 장애가 나면 대응하고, 같은 일로 다시 호출되지 않도록 수정안을 만듭니다.
두 가지 예를 보면 감이 옵니다. 매주 목요일마다 손으로 배포하는 팀은 자동 롤백이 있는 파이프라인을 만듭니다. 매일 밤 누수가 있는 서비스를 재시작하는 팀은 누수 원인을 찾아 고칩니다. 둘 다 반복되는 잡일을 한 번만 하면 되는 프로젝트로 바꾸는 작업입니다. 그게 핵심입니다.
많은 팀이 건너뛰는 네 번째 일이 있습니다. 장애 대응만 하는 SRE는 직함만 바뀐 운영 엔지니어입니다. 엔지니어링 업무가 있어야 역할이 달라집니다.
SRE와 DevOps는 어떻게 다른가요?
DevOps는 문화입니다. 개발자와 운영자가 무엇을 배포하고 어떻게 운영할지 함께 책임진다는 생각이죠. 팀 사이의 벽이 문제라고 알려 주지만, 얼마만큼의 다운타임이 허용되는지나 언제 배포를 멈춰야 하는지는 알려 주지 않습니다.
SRE는 그 숫자를 제공합니다. SLO, 에러 예산, 수작업 상한선을 줍니다. Google도 SRE를 DevOps 아이디어를 구현하는 구체적인 방법 중 하나로 설명합니다.
어느 쪽이 더 낫냐는 논쟁은 건너뛰어도 됩니다. 8명 팀이라면 두 가지를 모두 빌려 쓰게 됩니다. 중요한 질문은 이것입니다. 이 서비스가 얼마나 안정적이어야 하는지를 팀이 한 문장으로 말할 수 있는가요?
SLI, SLO, SLA는 무엇이고 왜 중요한가요?
SRE에서 중요한 용어는 세 가지인데, 사람들이 자주 헷갈립니다.
SLI (서비스 수준 지표): 측정값입니다. 예를 들어 HTTP 요청 중 300ms 안에 5xx가 아닌 응답을 받은 비율입니다.
SLO (서비스 수준 목표): 그 측정값의 목표입니다. 예를 들어 최근 28일 동안 요청의 99.9%가 이 조건을 만족하는 것입니다.
SLA (서비스 수준 협약): 목표를 놓치면 환불 같은 결과가 따르는 계약입니다. SLA는 SLO보다 느슨해야 합니다.
"서비스는 빠르고 안정적이어야 한다"는 문장은 테스트할 수 없습니다. "결제 요청의 99.9%가 500ms 안에 성공한다"는 목표는 테스트할 수 있고, 논쟁을 끝내는 데도 쓸 수 있습니다.
서비스마다 SLI는 두세 개로 시작하세요. 그보다 많으면 아무도 기억하지 못합니다. 사용자가 체감하는 SLI를 고르세요. CPU 사용률은 원인이지 증상이 아닙니다. 결제 실패, 느린 페이지 로드, 오래된 데이터가 고객이 실제로 느끼는 문제입니다.
에러 예산은 어떻게 작동하나요?
에러 예산은 SLO가 허용하는 불안정성입니다. 1에서 SLO를 뺀 값이죠. 가용성 목표가 99.9%라면 남는 0.1%가 있고, 이는 30일 기준으로 약 43분의 다운타임입니다.
산술이 전부인 개념이라 짧은 코드로 보면 이렇습니다.
slo = 0.999
window_minutes = 30 * 24 * 60 # 43,200분
budget = (1 - slo) * window_minutes # 43.2분
spent = 31 # 지금까지 나쁜 상태였던 시간(분)
print(f"{budget - spent:.1f} minutes left") # 12.2 minutes left예산이 남아 있는 동안 팀은 빠르게 배포합니다. 예산이 바닥나면 기능 배포를 멈추고 신뢰성 작업으로 옮깁니다. SRE Workbook의 에러 예산 정책 예시가 이 규칙을 문서로 어떻게 정리하는지 보여 줍니다.
목적은 처벌이 아닙니다. 배포하고 싶은 개발자와 안정성을 원하는 운영자가 오래 해 온 싸움을, 양쪽이 함께 읽을 수 있는 숫자로 바꾸는 겁니다. 다만 경영진이 사전에 중단 결정을 존중하기로 해야 작동합니다. 분기마다 뒤집히는 예산 정책은 장식일 뿐입니다.
톨 50% 규칙은 왜 있나요?
톨(toil)은 수작업으로 하는 반복 업무이고, 서비스가 커질수록 늘어나면서 아무것도 남기지 않습니다. 멈춘 워커를 손으로 재시작하는 것이 톨입니다. 재시작을 자동으로 해 주는 헬스 체크를 만드는 것이 엔지니어링입니다.
Google의 SRE 조직은 각 엔지니어의 업무 시간 중 톨을 50% 아래로 유지하는 것을 목표로 합니다. 톨 제거 장에 나온 내용입니다. 나머지 시간은 미래의 톨을 줄이는 프로젝트나 기능 개발에 씁니다. 이유는 단순합니다. 아무도 멈추지 않으면 톨이 모든 사람의 시간 100%를 채우기 때문입니다.
50%는 목표가 아니라 상한선으로 생각하세요. 성숙한 서비스를 운영하는 건강한 팀은 그보다 훨씬 낮습니다. 한 분기 내내 넘고 있다면 SRE를 하는 게 아니라 운영 대기열을 처리하고 있는 겁니다.
시작은 간단합니다. 2주 동안 모든 티켓과 호출을 톨 또는 프로젝트로 표시하세요. 그다음 톨을 시간 기준으로 정렬합니다. 상위 세 개가 자동화 백로그가 됩니다.
블레임리스 포스트모텀은 무엇을 바꾸나요?
장애가 나면 블레임리스 포스트모텀은 누가 실수했는지보다 시스템이 그 실수를 어떻게 허용했는지를 묻습니다. 비난은 사람들이 정보를 숨기게 만듭니다. 블레임리스 리뷰는 정보를 기록하게 만듭니다.
유용한 포스트모텀은 짧고 네 부분으로 나뉩니다. 타임라인, 기여 원인, 잘 된 점, 담당자와 기한이 있는 후속 조치입니다. 담당자 없는 후속 조치는 바람일 뿐입니다.
가치는 후속 관리에서 나옵니다. 열린 후속 조치를 매달 검토하세요. 같은 원인이 6개월 안에 두 번 나온다면, 문서가 뭐라고 했든 첫 번째 포스트모텀은 실패한 겁니다.
SRE 팀에 처음 필요한 도구는 무엇인가요?
많지 않습니다. 신호부터 시작하고, 그다음에 호출 체계와 자동화를 더하세요.
메트릭과 대시보드. SLI를 계산할 수 있을 만큼이면 충분합니다. Grafana와 Prometheus는 흔한 오픈소스 조합이고, Datadog과 New Relic은 호스팅 방식입니다.
SLO에 연결된 알림. 호스트 하나가 튈 때가 아니라 예산이 빠르게 줄 때 알리세요. 호출은 줄고, 남는 호출은 더 좋아집니다.
기능 플래그와 점진적 배포. 대부분의 장애는 변경 뒤에 따라옵니다. 그래서 가장 저렴한 신뢰성 개선은 변경을 되돌릴 수 있게 만드는 것입니다. LaunchDarkly와 Statsig가 이 영역을 다룹니다.
호출마다 런북 작성. 런북이 없는 알림은 런북을 쓰거나 알림을 삭제하세요.
구매든 구축이든 이 순서를 지키세요. SLO 없이 도구부터 사는 팀은 아무것도 설명하지 못하는 멋진 대시보드를 얻게 됩니다.
낯선 코드 읽기는 SRE의 어디에 들어가나요?
직무 설명에는 거의 들어가지 않는 부분입니다. 장애 중에 SRE는 직접 쓰지 않은 서비스를, 몇 달 동안 열어 보지 않은 저장소에서 이해해야 할 때가 많습니다. 질문도 대개 추상적이지 않습니다. "이 재시도 루프는 어디에 있고, 타임아웃이 나면 무엇을 하지?"처럼 구체적입니다.
이미 해 보셨을 겁니다. grep, blame, 그리고 마지막으로 파일을 건드린 사람에게 메시지 보내기입니다. 8만 줄짜리 저장소에서는 이 방식이 통합니다. 하지만 6개 팀이 맡은 12개 서비스에서는 장애 첫 20분을 먹어 버리고, 그 시간은 에러 예산에서 빠져나갑니다.
여기서 자기 저장소에 대해 질문하면 답해 주는 코드 검색 도구가 쓸모를 찾습니다. 예를 들어 어떤 서비스가 타임아웃을 어디서 설정하는지, 어떤 호출자가 그 값에 의존하는지를 묻는 식입니다. 장애를 고쳐 주지는 않습니다. 행동하기 전에 코드를 읽는 시간을 줄여 줄 뿐이고, 그 시간은 측정할 수 있습니다.
SRE는 우리 팀에 과한가요, 어떻게 시작하나요?
서비스가 하나뿐이고 엔지니어가 몇 명이며 사용자가 가끔 나쁜 시간을 참아 준다면 전담 SRE 팀은 필요 없습니다. 필요한 건 SLO 하나, 괜찮은 알림 하나, 호출을 책임지는 사람 한 명입니다.
다음 중 하나라도 해당하면 검토할 때입니다. 장애가 실제 매출 손실로 이어지거나, 호출 때문에 사람들이 지치거나, 임시 운영 요청 때문에 개발자가 느려지는 경우입니다. 많은 회사는 엔지니어 한두 명을 파트타임 SRE로 지정해 보면서 시작합니다.
흔한 실수는 운영 팀 이름만 'SRE'로 바꾸고 일하는 방식은 그대로 두는 것입니다. 팀이 여전히 티켓, 수작업 배포, 에러 예산 없음을 안고 있다면 직함만 바뀐 겁니다.
다음 주부터 시작하는 방법
재편성은 필요하지 않습니다. 사용자에게 가장 아픈 서비스 하나를 골라 다섯 가지를 하면 됩니다.
SLI 하나와 SLO 하나를 정하세요. 단순하게 유지하세요.
에러 예산을 계산해서 팀 전체가 보는 대시보드에 올리세요.
2주 동안 톨을 기록하고, 자동화할 상위 항목 하나를 고르세요.
다음 장애에 대해 담당자가 정해진 후속 조치를 포함한 블레임리스 포스트모텀을 여세요.
예산이 0이 되면 무슨 일이 일어날지 문서로 합의하세요.
한 달 뒤 팀이 배포 여부를 두고 덜 다투고, 숫자가 말하는 내용을 더 이야기하게 된다면 잘 되고 있는 겁니다. 목표가 너무 느슨해서 예산이 전혀 움직이지 않는다면 SLO를 더 조이세요.