풀스택 관점에서 본 SRE: AI 구동으로 변경이 빨라질수록, SLO 옆에 '복구 시간'을 설정해야 하는 이유

1. 핵심 요약

SRE는 DevOps의 구현체입니다. DevOps가 이념이라면, SRE는 이를 역할과 구체적인 실천 방안으로 녹여낸 것입니다. Google 스스로도 class SRE implements interface DevOps 라고 정의하고 있습니다.

• SLO와 에러 버짓은 관계자들의 시선을 숫자로 남기는 도구입니다. 평소에 '어느 정도의 불안정성은 허용할 수 있는지'를 합의해 두고, 출시 기한이나 장애 압박 속에서도 판단이 흔들리지 않게 합니다.
• SLO만으로는 부족합니다. SLO 옆에 '복구 시간'을 두어야 합니다. SLO는 사용자 관점의 결과이고, 복구 시간은 팀의 능력입니다. 에러 버짓 감소량은 '장애 빈도 × (감지 + 복구 시간)'으로 결정되므로, 후자를 줄이면 출시를 계속할 여지가 늘어납니다.
• 복구 시간은 평균(MTTR)으로 측정하지 않습니다. Google의 보고서에 따르면, MTTR 계열 통계는 판단이나 경향 분석에 적합하지 않다고 결론지었습니다. 심각도별 상한선과 Runbook을 갖추어야 합니다.
• AI 구동 개발에서는 변경량이 늘어납니다. 장애 빈도를 줄이는 것보다, 감지와 복구를 빠르게 하는 것이 개발팀이 개입하기 더 쉽습니다. 풀스택 관점에서 SRE를 배울 의미는 여기에 있습니다.

2. SRE란 무엇인가

SRE 책의 Introduction(‘SRE’라는 용어를 만든 Benjamin Treynor Sloss가 작성한 장)에 정의된 내용은 다음과 같습니다.

SRE is what happens when you ask a software engineer to design an operations team.

운영을 엔지니어링 문제로 다룬다는 것이 핵심입니다. 주요 생각은 4가지가 있습니다.

2.1 DevOps와의 관계

SRE Workbook의 'How SRE Relates to DevOps'는 두 가지 관계를 class SRE implements interface DevOps 로 표현하고 있습니다. DevOps는 개발과 운영의 협조라는 이념이고, SRE는 이를 구현한 위치로 정의됩니다.

DevOps는 받아들이기 쉽지만, SRE는 규칙이 많아 '누군가가 개발을 막는 시스템'처럼 보이기 쉽습니다. 이는 권한만 가지고 대화하지 않는 '문지기형(門番型)' 운영을 봤을 때 생기는 이질감이며, 본래의 SRE 생각과는 거리가 있습니다.

3. SLO는 시선 맞추기의 도구

에러 버짓은 SRE가 일방적으로 개발을 제약하기 위한 틀이 아닙니다. 개발·운영·사업 측이 사전에 '어느 정도의 불안정성은 허용할지'를 결정하는 합의로 사용합니다.

시선이 맞춰져 있을 때는 규칙이 거의 필요 없습니다. 시선이 어긋나는 경우는 다음과 같습니다.

• 출시 기한이 임박했을 때
• 장애 대응 중, 누군가를 탓하고 싶을 때
• 조직이 커지면서 관계자 모두가 대화할 수 없을 때

숫자로 만들어 놓으면, 이런 상황에서도 판단이 감정 논리에 흐르기 어렵습니다. SLO는 평소의 합의를 혼란한 상황에서도 사용할 수 있도록 남겨두는 보험이라고 할 수 있습니다.

4. SLO 옆에 복구 시간을 두기

압박을 받는 상황에서 판단 자료로 삼으려면, SLO(결과)만으로는 부족합니다. 팀이 얼마나 빨리 재정비할 수 있는지(능력)도 정해두어야 합니다.

4.1 에러 버짓과 복구 시간의 관계

Google Cloud의 SRE팀 기사는 사용자가 불만을 느끼는 시간을 감지까지 걸리는 시간(ETTD)과 복구까지 걸리는 시간(ETTR)의 합으로 다루며, 장애 빈도(장애 간격 ETTF의 역수)가 여기에 영향을 미친다고 합니다. 요약하면 다음과 같은 형태가 됩니다.

이 공식에서 알 수 있는 것은, 복구를 빠르게 하면 버짓 감소 속도가 느려지고, 그만큼 출시를 계속할 수 있다는 것입니다. '복구 절차가 갖춰져 있으니 어느 정도의 리스크는 감수할 수 있다'고 말할 수 있는 것이 이 관계가 있기 때문입니다.

4.2 자주 사용되는 지표

4.3 평균으로 추적하지 않기

MTTR을 '평균 ○분'이라는 목표로 관리하면 제대로 작동하는 경우가 적다. 장애별 복구 시간의 편차가 크고, 평균이 실제 상황을 반영하지 못하기 때문이다.

Google의 Incident Metrics in SRE (Štěpán Davidovič, 2021년 3월)는 몬테카를로 시뮬레이션(Monte Carlo Simulation)을 사용하여, MTTR이나 MTTM 같은 통계가 실제 장애 상황에서는 판단이나 경향 분석에 적합하지 않다고 결론지었다.

실무에서 효과적인 것은 평균이 아니라 다음 두 가지다.

• 심각도별 상한: 'SEV1은 초기 대응 ○분 이내, 임시 복구 ○분 이내'와 같이, 평균이 아닌 상한으로 결정한다. -
  Runbook: '누가・무엇을・어떤 순서로' 할지 미리 작성해 둔다.

둘 다 사용자에게 약속하는 SLO(Service Level Objective)라기보다는, 사내 운영 목표로서 가지는 것이 일반적이다.

5. AI 구동 개발에서 왜 중요한가

5.1 변경량이 늘어나면서 안정성이 먼저 무너진다

코딩 에이전트(Coding Agent)를 사용하면, 한 사람이 만들어낼 수 있는 변경량(change volume)이 증가한다. DORA의 2024년 보고서는 AI 도입이 개인의 생산성을 높이는 반면, 소프트웨어 배포의 안정성 및 처리량(throughput)에는 부정적인 영향을 미치고 있다고 보고했다.

4.1의 공식에 대입해 보면, 변경량이 늘어나면 장애 빈도 항(frequency term)이 커지기 쉽다. 이 빈도를 리뷰만으로 억제하려고 하면, AI로 높아진 속도를 스스로 상쇄하는 결과를 초래하게 된다.

5.2 개발 측에서 개입하기 쉬운 것은 감지와 복구

풀스택(Full-stack) 입장에서 보면, 공식의 나머지 항에 손을 대기 쉽다.

5.3 Runbook은 에이전트도 읽을 수 있다

심각도별 상한과 Runbook을 문서로 가지고 있으면, 인간뿐만 아니라 에이전트에게도 전달할 수 있다. '이 SLI가 이 임계값을 벗어나면, 이 순서대로 확인하고, 이 조치로 되돌린다'라고 작성되어 있다면, 초기 대응의 분기(troubleshooting)를 에이전트에게 맡길 범위를 정할 수 있다. 반대로, 절차가 머릿속에만 있는 팀이라면, 에이전트에게 맡길 수 있는 것은 코드를 작성하는 부분까지만이며, 복구 측면은 빨라지지 않는다.

5.4 에러 버짓을 AI 속도의 브레이크로 삼기

AI로 변경 속도가 올라가면, '어디까지 빠르게 내보낼 수 있을지'에 대한 판단이 매일 필요하게 된다. 에러 버짓(Error Budget)은 이 판단을 그대로 숫자로 돌려준다. 여유분이 남아있으면 에이전트가 내보내는 변경을 계속 넣고, 소진되면 안정화 작업(감지・복구・테스트 강화)에 에이전트를 투입한다. 속도의 높낮이를 사람의 감각이 아닌 합의된 숫자로 결정할 수 있게 된다.

6. 요약

• SRE는 DevOps의 이념을 역할과 실천 방안(practices)으로 구체화한 것이다. SLO와 에러 버짓은 시선을 숫자에 남겨두는 합의다.
• SLO(결과) 옆에 복구 시간(능력)을 배치한다. 에러 버짓의 소모는 '빈도 × (감지 + 복구) × 영향 범위'로 결정된다.
• 복구 시간은 평균으로 추적하지 않고, 심각도별 상한과 Runbook으로 관리한다.
• AI 구동 개발에서는 변경량이 증가한다. 빈도를 억제하기보다, 감지・복구・영향 범위를 개발 설계 단계에서 줄이는 것이 속도를 늦추지 않는 방법이다.