SRE는 최고의 존재다
Source: Dev.to
If you don’t know what SRE is, don’t worry… I’ve got you.
SRE가 뭔지 모른다고 해도 걱정 마세요… 제가 알려드릴게요.
I’m Jairo Jr., Software Engineer at Mercado Livre, based in Brazil, and over the last few months I’ve been studying SRE.
저는 브라질에 기반을 둔 Mercado Livre의 소프트웨어 엔지니어 **Jairo Jr.**이며, 지난 몇 달 동안 SRE를 공부하고 있습니다.
SRE changed the way I see production.
Before SRE, production for me was:
SRE 이전에, 제가 보는 프로덕션은 다음과 같았습니다:
- ✅ “deploy is done”
- ✅ “feature is working”
- ✅ “let’s move to the next ticket”
After diving deeper into SRE, I started to see production as:
SRE를 더 깊이 파고들면서, 저는 프로덕션을 다음과 같이 보기 시작했습니다:
“Ok… but what if this breaks at 3 AM?”
“음… 그런데 만약 새벽 3시에 문제가 생기면 어떡하지?”
그래서… SRE란?
SRE는 Site Reliability Engineering의 약자입니다. Google에서 2003년경에 제품이 성장하면 문제도 함께 성장한다는 단순한 진실을 깨달으며 시작되었습니다.
제품이 성장하면 문제도 함께 성장한다.
- 매주 발생하는 문제
- 깨진 사용자 경험
- 스트레스를 받는 사람들
- 온콜이 악몽으로 변함
- 로그를 탐정처럼 디버깅하면서 회사가 손해를 보는 상황 🕵️♂️
SRE는 소프트웨어를 다음과 같이 만들기 위한 접근 방식입니다:
- ✅ 확장 가능
- ✅ 신뢰성
- ✅ 측정 가능
- ✅ 덜 “무작위적”
SRE는 단순히 멋진 이름의 DevOps가 아니다
많은 사람들이 “SRE는 DevOps, 맞죠?”라고 생각합니다. 정확히는 그렇지 않습니다. SRE는 DevOps 목표와 엔지니어링 사고방식을 결합합니다.
문제를 영원히 수동으로 해결하는 대신, SRE는 다음을 묻습니다:
- “이걸 자동화할 수 있을까?”
- “이걸 예측할 수 있을까?”
- “고객이 인지하기 전에 이를 감지할 수 있을까?”
- “더 빠르게 복구할 수 있을까?”
이렇게 해서 분야를 반응형에서 능동형으로 전환합니다.
일상적인 예시 (실제 사례)
다음과 같은 전형적인 상황을 상상해 보세요:
- 새로운 기능을 배포합니다.
- 모든 것이 정상적으로 보입니다.
- 10분 후:
- 지연 시간이 급증합니다 📈
- 일부 요청이 실패하기 시작합니다
- 메트릭 대시보드가 크리스마스 트리처럼 보입니다 🎄
아마도 “제게는 잘 작동하고 있어요…” 같은 마법 같은 말을 들을 수 있지만, 사용자에게는:
❌ 그렇지 않습니다.
SRE는 빠르게 답을 찾도록 도와줍니다:
- 무엇이 고장났나요?
- 언제 시작됐나요?
- 모두에게 영향을 미치나요, 아니면 일부 고객에게만인가요?
- 실패가 내 서비스에 있나요, 아니면 의존성에 있나요?
- 무엇이 바뀌었나요?
- 얼마나 빨리 롤백할 수 있나요?
SRE 문화가 없으면 보통 다음을 통해 문제를 발견합니다:
- Slack 메시지
- 고객 불만
- “무슨 일인가요?” 라고 묻는 매니저 😭
SRE는 신뢰성을 측정하도록 가르칩니다
SRE는 숫자에 기반합니다. 다음과 같이 말하는 대신:
❌ “우리 서비스는 매우 안정적이다”
라고 말합니다:
✅ “우리 서비스는 SLO가 99.9 %이고 오류 예산 내에 있기 때문에 안정적이다.”
이렇게 하면 신뢰성을 구체적인 대화로 만들 수 있습니다:
- 엔지니어
- 제품 팀
- 매니저
- 비즈니스 이해관계자
모두가 이해합니다.
SLO와 오류 예산 (다르게 작용하는 부분)
If your SLO is 99.9 % availability per month, you can afford roughly 43 minutes of downtime per month. This is your error budget.
Rule of thumb:
- ✅ Inside the budget → you can deploy more.
- ❌ Budget exhausted → stop pushing risky changes and focus on reliability.
In other words, SRE says: “Move fast… but not stupid fast.”
SRE가 당신이 영웅이 되는 것을 멈추게 하는 이유
SRE가 없으면 흔히 다음과 같은 문화가 형성됩니다:
- 뭔가가 고장난다.
- 한 사람이 일어나서 모든 것을 고치고 “영웅”이 된다.
그 함정은 시스템을 인간에게 의존하게 만듭니다. 인간은:
- 피곤해지고
- 실수를 하고
- 아프고
- 휴가를 가고
- 직장을 옮깁니다
SRE는 영웅이 필요 없는 시스템을 만들도록 독려합니다. 이것은 “누가 더 빨리 고칠 수 있느냐”가 아니라 다음에 관한 것입니다:
- ✅ 왜 이런 일이 발생했는지
- ✅ 무엇을 개선할지
- ✅ 어떻게 다시는 같은 일이 일어나지 않게 할지
- ✅ 다음 번에 영향을 어떻게 줄일지
On‑call is not the problem (bad on‑call is)
On‑call은 게임의 일부이지만 bad on‑call은 팀을 망칩니다. 나쁜 on‑call은 다음과 같습니다:
- 계속 페이지를 울리는 쓸모없는 알림
- 런북이 없음
- 명확한 대시보드가 없음
- 롤백 계획이 없음
- 소유권이 없음
- 모든 사고가 처음인 것처럼 느껴진다
좋은 SRE는 팀이 다음을 구축하도록 강제함으로써 on‑call을 더 쉽게 만듭니다:
- 명확한 모니터링
- 의미 있는 알림
- 빠른 복구 절차
- 견고한 사고 처리 프로세스
그 결과 팀은 “패닉 모드”에서 “프로세스 모드”로 전환합니다.
진정한 목표: 사용자를 보호하기
결국, 사용자는 다음에 신경 쓰지 않는다:
- Kubernetes, Kafka, retries, p95 latency, cache invalidation
그들이 신경 쓰는 것은:
- ✅ 앱이 정상 작동한다
- ✅ 결제가 정상 처리된다
- ✅ 화면이 빠르게 로드된다
- ✅ 주문이 확인된다
SRE는 로컬 머신에서만이 아니라 매일 이를 제공하도록 도와준다.
Why I think SRE is the BEST thing ever
Because it changes your mindset.
SRE makes you stop thinking only about:
🧩 “이 기능을 어떻게 구축할지”
and start thinking about:
🔥 “이 기능을 수백만 사용자를 위해 프로덕션에서 어떻게 지속시킬지”
And that’s a different level of engineering.