SRE 란 사이트 신뢰성 엔지니어링 입문
요약
SRE 는 운영을 측정 가능한 목표와 소프트웨어로 다루는 방식입니다. 99.9% 같은 SLO 를 정하고, 목표를 놓친 시간을 세고, 그 숫자로 배포와 수정 중 무엇을 할지 고릅니다. 혼자 만든 사이드 프로젝트라면 SLI 하나, SLO 하나, 헬스 체크 하나로 저녁 한 번이면 시작할 수 있어요.
SRE 란 사이트 신뢰성 엔지니어링(site reliability engineering)을 한 줄로 줄이면, 운영을 소프트웨어 문제처럼 다루는 방식입니다. 측정할 수 있는 신뢰성 목표를 정하고, 그 목표를 얼마나 자주 놓치는지 추적하고, 그 숫자로 기능을 출시할지 장애부터 고칠지 정하죠. Google이 이 용어를 만들었지만 아이디어 자체는 어떤 규모에서도 통해요. 앱 하나에 사용자가 몇 명뿐인 1인 개발자에게는 미리 "얼마나 멈춰도 괜찮은가"를 정해 두는 일이 됩니다.
문제는 대부분의 사이드 프로젝트에 이런 숫자가 없다는 점이에요. 누군가 메일을 보내기 전까지는 "잘 돌아가는 중"이라고 믿고 지냅니다. 이 글은 SRE 를 쉬운 말로 설명한 뒤, 주말 하루면 혼자서도 돌릴 수 있는 크기로 줄여 보겠습니다.
SRE 란 정확히 무엇인가요?
짧게 말하면 SRE 는 운영팀을 설계할 때 소프트웨어 엔지니어에게 맡기면 생기는 결과물입니다. 사람이 손으로 서버를 재시작하는 대신 그 일을 하는 코드를 쓰고, 결과를 측정하죠. Google의 SRE 책 도입부가 이 관점의 출발점이에요.
핵심 아이디어는 세 가지로 요약됩니다. 신뢰성은 분위기가 아니라 목표가 있는 기능이에요. 반복적인 수작업(책에서는 toil 이라고 부릅니다)은 자동화해서 없애야 할 버그예요. 그리고 실패는 생긴다고 가정하고, 누구 탓을 할지보다 무엇을 배울지를 고민합니다.
DevOps 와 SRE 는 많이 겹쳐요. 차이를 굳이 나누자면 DevOps 는 코드를 함께 배포하고 운영하는 문화이고, SRE 는 그 문화를 숫자로 이야기할 수 있는 구체적인 도구를 줍니다. 그 숫자를 쓰는 데 진영을 고를 필요는 없어요.
대기업에서 SRE 엔지니어는 온콜, 장애 대응, 용량 계획, 자동화 작업으로 시간을 나눠 씁니다. Google 책은 운영 업무가 엔지니어 시간의 약 절반을 넘지 않도록 상한을 두라고 말해요. 이 상한은 있으면 좋은 옵션이 아니라 설계 제약입니다.
반복되는 일은 대략 이런 모습이에요.
제품팀과 함께 SLO 를 정하고, 예산이 줄어드는 속도에 맞춰 알림을 설정하기
온콜 순번을 돌리고, 새벽 3시에 울린 호출에도 체크리스트가 있도록 런북 작성하기
장애 대응을 이끌고, 책임을 묻지 않는 사후 분석을 쓰기
수작업을 몇 번 이상 반복했다면 자동화하기
출시 전에 신뢰성 위험을 검토하기
기능 플래그는 이 사고방식을 잘 보여 줘요. 플래그 하나로 나쁜 릴리스를 재배포 없이 몇 초 만에 끌 수 있고, 그만큼 예산을 지키죠. 플래그가 몇 개뿐이라면 환경 변수로도 충분하고, 호스팅 도구가 필요할지는 플래그 개수에 달려 있어요.
SLI, SLO, SLA: 세 용어, 각각 한 가지 뜻
SLI(service level indicator)는 측정하는 값이에요. 웹 앱이라면 보통 요청이 성공한 비율이나 300ms 안에 응답한 비율이죠. 한두 개만 고르세요. 열두 개를 고르면 아무것도 보지 않게 됩니다.
SLO(service level objective)는 그 측정값에 거는 목표예요. 예를 들어 "30일 동안 요청의 99.9%가 성공한다" 같은 문장입니다. 내부용이고, 나 자신과 한 약속에 가깝습니다.
SLA(service level agreement)는 고객과 맺는 계약이고, 보통 목표를 놓치면 환불이 따라옵니다. 가동률을 돈 주고 사는 고객이 아직 없다면 SLA 는 아직 없는 거예요. 가격 페이지 문구에 실수로 적어 넣지는 마세요.
오류 예산: 일하는 방식을 바꾸는 부분
오류 예산은 100%에서 SLO 를 뺀 값입니다. 30일 동안 99.9% 목표라면 약 43분의 실패를 허용한다는 뜻이에요. 이 예산이 위험한 배포, 마이그레이션, 실험에 쓸 수 있는 몫입니다.
핵심은 여기에 붙는 규칙이에요. 예산이 남아 있으면 배포합니다. 예산이 바닥나면 기능 개발을 멈추고 신뢰성을 고쳐서 예산이 회복될 때까지 기다리죠. 책의 리스크 장은 "빨리 가자"와 "깨뜨리지 말자"의 논쟁을 협상이 아니라 공유된 숫자로 정리하는 방법으로 이 규칙을 설명해요.
한 가지 짚고 넘어갈 점이 있어요. 100%는 거의 올바른 목표가 아닙니다. 불안정한 모바일 네트워크를 쓰는 사용자는 99.99%와 99.9%를 구분하지 못하고, 9를 하나 더 붙일 때마다 비용은 앞의 것보다 훨씬 커져요. 완벽한 목표는 아니지만 실제로 굴러가는 목표예요.
지표를 고르고 첫 목표를 적는 구체적인 방법이 궁금하다면 SRE 워크북의 SLO 장이 가장 실용적이고 분량도 짧아요.
혼자 만드는데도 SRE 가 필요할까요?
이유는 세 가지, 하지 않을 이유는 한 가지예요.
하는 이유는 이렇습니다. 언젠가 내 프로젝트가 나를 호출하게 됩니다. 목표를 글로 적어 두면 과하게 설계하는 걸 막아 줘요. 그리고 "SLO 로 운영하고 있다"는 말은 누군가 나를 채용할지 믿을지 고민할 때 꽤 설득력이 있죠. 하지 않을 이유는 아직 사용자가 없다면 오지 않은 문제를 미리 연습하는 셈이라는 점이에요. 먼저 만들고, 누군가 기대기 시작하면 그때 측정하세요.
그래서 전체 장비를 갖출 필요는 없어요. 취미 앱에 호출 서비스를 붙일 필요도 없고, 진지해 보이려고 쿠버네티스를 올릴 필요도 없으며, 10쪽짜리 장애 템플릿을 쓸 필요도 없습니다. 실제 사용자가 열 명만 넘어도 헬스 체크, SLO 하나, 그리고 장애가 나면 들여다볼 곳 하나는 가질 만해요.
하루 저녁으로 끝내는 사이드 프로젝트 SRE 설정
여기 나오는 최소 설정은 사용자 10,000명 규모에서도 버틸 만한 편이에요. 저녁 한 번이면 끝나요. 검증은 했지만 최적은 아닙니다. 그래도 이렇게 하는 이유는 지루하기 때문이고, 지루한 것이 살아남거든요.
첫째, SLI 하나만 고르세요. 5xx 가 아닌 HTTP 응답의 비율입니다. 둘째, SLO 는 30일 기준 99.5%로 잡으세요. 예산은 약 3.6시간이에요. 처음엔 느슨하게 두고 나중에 조입니다. 셋째, 실제로 깨지는 것을 확인하는 헬스 엔드포인트에 외부 업타임 체크를 붙이세요. 프로세스가 살아 있는지만 보는 것으로는 부족합니다.
// GET /healthz
app.get("/healthz", async (req, res) => {
try {
await db.query("select 1"); // 데이터베이스 연결 확인
await cache.ping(); // 캐시 연결 확인
res.status(200).json({ ok: true });
} catch (err) {
res.status(503).json({ ok: false });
}
});넷째, 알림은 받은 편지함이 아니라 폰 푸시처럼 바로 눈에 띄는 곳으로 보내세요. 다섯째, postmortems.md 라는 일반 텍스트 파일을 만들고 장애가 날 때마다 네 줄을 적으세요. 무엇이 일어났는지, 왜, 얼마나 오래, 무엇을 바꿀지요. 이 파일이 여러분이 가질 가장 과소평가된 신뢰성 도구일 거예요.
초보자가 자주 하는 실수는 요청 하나가 실패할 때마다 나를 깨우게 만드는 거예요. 일주일이면 채널을 음소거하게 됩니다. 더 나은 신호는 번 레이트(burn rate)예요. 오류 예산을 얼마나 빠르게 쓰고 있는지를 보는 값이고, 기준은 지금 속도로 가면 측정 기간이 끝날 때 예산이 정확히 0이 되는 속도입니다.
사이드 프로젝트라면 방식을 단순하게 가져가세요. 최근 10분 오류율이 5%를 넘으면 푸시 알림을 보내고, 주간 오류율이 SLO 를 놓칠 방향으로 가면 이메일 요약을 보내는 식이에요. 이 두 단계만 있으면 지금 깨어날지, 월요일에 볼지를 정할 수 있습니다. 더 정교한 기능은 첫 번째 단계에 대해 사용자가 불평하기 시작하면 그때 붙여도 늦지 않아요.
사후 분석은 아무도 끝까지 읽게 쓰는 법
짧고 책임을 묻지 않게 쓰세요. 책임을 묻지 않는다는 말은 아무도 책임지지 않는다는 뜻이 아니에요. 누가 실수했는지보다 시스템의 어떤 부분이 그 실수를 허용했는지를 묻는다는 뜻입니다. 팀에 나 혼자뿐이라면 이게 생각보다 더 중요해요. 자책하고 글쓰기를 건너뛰고 싶은 유혹이 그만큼 크니까요.
제목은 네 개면 충분해요. 무엇이 일어났는지, 왜 일어났는지, 사용자가 얼마나 오래 영향을 받았는지, 무엇이 바뀌는지. 마지막 항목은 실제로 할 행동을 날짜와 함께 적어야 해요. "더 조심하자"는 행동이 아니에요. "다음 릴리스 전에 마이그레이션 스테이징 체크 추가"가 행동이죠.
1년쯤 쌓이면 이 파일은 내 약점 지도가 됩니다. 저는 같은 원인이 두 번 나오면 자동화한다는 규칙을 만들었는데, 만료된 인증서 때문에 장애가 세 번 난 뒤에야 만들었어요. 갱신 모니터링을 붙이는 데 저녁 하나면 충분했고, 그 뒤로 같은 장애는 다시 나지 않았습니다.
AI 도구는 어디까지 믿어도 될까요?
어시스턴트는 수작업 영역에서 꽤 쓸만해요. 헬스 체크 코드, 업타임 모니터용 Terraform, 런북 초안, 로그에서 5xx 비율을 뽑는 스크립트 같은 것들이죠. 반면 SLO 를 정하는 일은 잘 못해요. 사용자가 무엇을 참을 수 있는지에 대한 제품 판단이라서요.
장애 중에는 조심하세요. 그럴듯한 수정안을 받고 제대로 읽지도 않은 채 새벽 2시에 운영에 적용하기 쉬워요. 스택 트레이스를 설명받거나 사후 분석 초안을 쓰는 데 쓰고, 롤백 결정은 깨어 있는 사람이 쥐고 있어야 합니다.
코드 품질 게이트도 이 그림의 일부예요. 많은 장애가 리뷰에서는 무해해 보였던 변경에서 시작하거든요. CI 의 정적 분석이 신뢰성을 주지는 않지만, 비용이 드는 단순한 실수의 한 부류를 배포 전에 걸러 줍니다.
다음에 무엇을 만들까요?
SRE 가 나에게 맞는 진로인지는 취향 문제예요. 시스템, 장애 패턴, 자동화를 좋아하는 사람에게 잘 맞고, 호출 알림을 조용하게 만드는 일에서 만족을 느낀다면 즐길 가능성이 높아요. 새 기능을 사용자가 클릭하는 걸 보는 게 제일 신난다면 아마 그렇지 않을 거예요.
보통은 백엔드나 인프라 작업을 거쳐 들어가요. 서비스의 배포와 알림을 맡기 시작하고, 점점 그 서비스의 신뢰성까지 맡게 되는 식이죠. 그때 필요한 기술은 리눅스 기초, 네트워킹, 클라우드 한 곳, 모니터링 스택, 그리고 무언가를 글로 남기는 습관이에요. 사이드 프로젝트는 이걸 전부 쌓기에 좋은 곳입니다. 팀 전체가 나 하나니까요.
지금 운영 중인 것 하나를 고르세요. 무료 티어 앱이어도 괜찮아요. 그 앱의 SLI 와 SLO, 그리고 예산이 바닥났을 때 정확히 무엇을 멈출지를 적어 보세요. 멈출 것이 떠오르지 않는다면 그 숫자는 장식일 뿐이에요. 여러분의 프로젝트 중에서 사용자가 말해 주기 전에 다운된 걸 알아챌 수 있는 건 어떤 것인가요?