이 글은 2025년 SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링) 트렌드 4가지를 소개합니다. SRE는 시스템 관리와 애플리케이션 모니터링, 인시던트 대응 등 IT 인프라 작업을 자동화하죠. 이로써 소프트웨어 배포 속도와 안정성을 크게 향상할 수 있습니다.

IT 업계에는 SRE 트렌드 보고서가 꾸준히 나옵니다. 특히 미국 인터넷 신뢰성 기업인 Catchpoint는 SRE 보고서를 7년 연속 발행해 눈길을 끄는데요. 이들은 설문조사를 토대로 매년 SRE 동향을 넓고 깊게 보여주죠. 연도별 SRE 변화상을 빠짐없이 파악하는 데 도움이 됩니다.

2025년 1월 ‘Catchpoint의 SRE Report 2025’*가 나왔습니다. SRE 최신 보고서라 업계에서 자주 회자되고 있는데요. 이 보고서는 2025년 SRE 트렌드 7가지를 다뤘습니다.

저는 이중 SLO, Toil, 옵저버빌리티, 인시던트 관리 - 4가지 트렌드를 소개하고자 하는데요. DevOps, 옵저버빌리티 등 여러 유관 분야 전문 기업 관계자들의 분석을 더해 각 트렌드의 상세 현황과 등장 배경, 유의 사항을 정리했습니다.

*전 세계 기술 플랫폼, 금융 서비스, 소매업, 고등 교육, 정부 기관 등에 종사하는 모든 유형의 신뢰성 역할과 직급 담당자 301명이 설문조사에 응답함

1. SLO, 엔지니어링 과제 우선순위

조직이 앞으로 12개월 동안 우선으로 도입할 엔지니어링 과제 응답 현황. 출처=Catchpoint | 인포그랩 GitLab
조직이 앞으로 12개월 동안 우선으로 도입할 엔지니어링 과제 응답 현황. 출처=Catchpoint

서비스 수준 목표(SLO)가 조직의 엔지니어링 과제에서 높은 우선순위를 차지하고 있습니다. SLO는 일정 기간 특정 서비스에 합의된 성능 목표인데요. IBM에 따르면, “서비스 안정성이 사용자 만족으로 이어져 더 큰 사업 기회를 제공한다”는 게 SLO의 핵심 논리죠. Catchpoint의 설문조사에 따르면, 응답자 40%가 ‘조직이 앞으로 12개월 동안 우선으로 도입할 엔지니어링 과제’로 SLO와 경험 수준 목표(XLO)를 꼽았는데요. 이는 SRE(41%)에 이어 두 번째로 높은 응답률이었습니다. 또 응답자 44%가 “성능을 SLO와 비교해 추적해야 한다”고 답변했고요.

조직이 SLO를 중시하는 이유는 성능을 개선해 서비스 안정성과 신뢰성을 높이고, 비즈니스 가치를 향상하기 위함입니다. IT 업계에 “느림은 새로운 다운이다(Slow is the new down)”이라는 말이 있는데요. 이는 ‘성능 저하가 완전한 다운타임만큼 심각한 문제’라는 의미죠. Catchpoint의 설문조사에 따르면, 응답자 53%가 “이 표현에 일반적으로 동의한다”라고 답변했습니다. 오늘날 사용자는 우수한 성능과 빠른 속도에 익숙하죠. 성능 판단 기준도 엄격합니다. 구글에 따르면, 페이지 로딩 시간이 1 ~ 3초 늘어날 때 이탈률은 32% 증가하는데요. 성능이 비즈니스 성과에 큰 영향을 주죠. SLO를 설정하고 준수하면 성능 개선, 장애 예방, 사용자 경험 향상, 비즈니스 가치 창출에 도움이 됩니다.

성능을 향상하고, SLO를 준수하려면 다음 작업이 필요합니다. 성능과 동작을 모니터링하고 최적화하는 건 당연하고요. 상호 연결된 컴포넌트와 API, 의존성을 문서화하고 내용을 이해하면 문제를 더 빨리 해결하고, 팀이 원활하게 협업할 수 있죠. 성능 지표와 목표, 오류 예산*을 시각화하는 것도 중요합니다. 번다운 차트로 시각화하면 지표의 목표 달성 여부, 위험 요소를 한눈에 파악할 수 있고요. SLO를 준수하며 애자일리티와 안정성의 균형을 맞추는 데 이를 참고할 수 있죠. 평가 자동화와 현실적인 SLO 수립도 신속한 문제 해결과 원만한 비즈니스 운영에 필수입니다.

*오류 예산: SLO를 기준으로 산출한 장애, 서비스 안정성 저하의 허용 한도. SLO에서 가동 시간을 99.95%로 설정하면, ‘0.05%의 가동 중지 시간이 허용됨’을 뜻함

2. AI 도입에도 운영 Toil 증가

2020 ~ 2025년 응답자 업무 가운데 Toil 평균 비중. 출처=Catchpoint  | 인포그랩 GitLab
2020 ~ 2025년 응답자 업무 가운데 Toil 평균 비중. 출처=Catchpoint

SRE 담당자 업무의 Toil 비중이 최근 5년 새 처음으로 증가했습니다. Toil은 프로덕션 서비스 운영과 관련된 작업으로, 수동적이고 반복적이며 자동화할 수 있고, 전략적이며 지속적 가치가 없고, 서비스 성장에 따라 확장되죠*. Catchpoint의 설문조사에 따르면, 응답자 업무의 Toil 비중 중앙값(p50)은 20%로, 지난해(14%)보다 6%p 늘었는데요. Toil 비중은 2020 ~ 2024년 꾸준히 줄었지만, 2025년에 다시 증가해 2023년 수준으로 회귀했습니다. p25(10%), p75(30%) 값도 마찬가지로 늘었죠. 특히 응답자의 운영 활동 중앙값은 30%로, 지난해(25%)보다 5%p 증가했는데요. 이는 엔지니어링 활동의 중앙값(50%)이 지난해와 동일한 것과 대조됐습니다.

Catchpoint에서는 ‘AI가 중요한 작업을 신속히 처리하면서 생긴 자유 시간이 번거로운 업무로 채워질 수 있다’고 분석합니다. SRE의 핵심 원칙은 ‘모든 것을 자동화해야 한다’는 거죠. AI는 오늘날 자동화 핵심 기술로, 업무 수행 방식을 혁신하고 있습니다. SRE에서도 마찬가지죠. 이제 쿼리 작성, 인시던트 보고서 요약, 문제 해결 방안 수립 등에 AI를 활용하는데요. 그 결과, 줄어든 Toil도 있지만 모든 Toil이 그런 건 아닙니다. AI의 불완전성이 Toil을 늘리기도 하죠. AI는 대체로 정확하지만, 미묘하고 예측하기 어려운 오류도 일으킵니다. AI가 1차로 작업을 수행해도, 사람이 2차로 그 결과를 검수하고 수정해야 하죠. Datadog의 시니어 스태프 엔지니어인 Laura de Vesine은 “AI 시스템을 수동으로 감독하면 일상 업무와 인시던트 모두에 팀의 운영 부담이 쉽게 증가할 수 있다”고 지적합니다.

Toil을 줄이려면 정확한 현황 파악이 우선입니다. 증가, 감소, 신규 발생한 Toil을 살펴보고요. 특히 증가했거나, 새로 생긴 Toil과 AI 관련성도 확인해야 하죠. Laura de Vesine은 “AI 도입을 추진하는 팀과 기업은 기계의 결과물을 감독하는 데 쓰이는 시간과 노력을 명확히 살펴봐야 한다”고 제언합니다. 단, ‘모든 걸 AI로 해결할 수 없음’을 기억해야 하는데요. 필수적인 AI 유지보수 부담은 받아들여야 하죠**. 물론 검수·수정 속도와 정확성은 높여야 합니다. 다양한 AI로 특정 AI의 결과물을 교차 검증하는 건 한 방법이죠. Catchpoint는 “운영 업무 부담이 커지면 사전 예방적 엔지니어링 노력에 투자할 시간이 잠식된다”고 지적하는데요. 서비스 안정성과 신뢰성 향상, 비즈니스 가치 증대를 위해 Toil 개선 과제는 여전히 남아있습니다.

*구글의 Toil 개념 정의

**구글은 “Toil이 항상 나쁜 건 아니며, ’SRE 역할과 대부분의 엔지니어링 역할에서 일정 수준의 Toil은 피할 수 없음’을 모두가 분명히 인식해야 한다”고 설명함. 또 “소량이면 괜찮고, 그 소량에 만족하면 Toil이 문제가 되지 않는다”고 밝힘. 그러나 Toil을 대량으로 겪으면 독이 됨

3. 옵저버빌리티 도구 개수와 수준의 상관관계

조직의 모니터링/옵저버빌리티 도구 개수별 옵저버빌리티 수준. 출처=Catchpoint | 인포그랩 GitLab
조직의 모니터링/옵저버빌리티 도구 개수별 옵저버빌리티 수준. 출처=Catchpoint

오늘날 조직은 모니터링/옵저버빌리티 도구를 평균 2개 이상 사용합니다. Catchpoint 설문조사에서 응답자 94%가 이같이 답변했는데요. 가장 많은 조직(61%)이 2 ~ 5개의 도구를 사용하고요. 도구를 6 ~ 10개 사용하는 조직도 전체 25%를 차지했죠. 특히 모니터링/옵저버빌리티 도구를 많이 사용할수록 조직의 옵저버빌리티 수준을 높게 인식하는 경향이 나타났습니다. 도구를 6 ~ 10개 사용하는 조직(48%)에서 “옵저버빌리티 수준이 적당하다”는 응답이 가장 많았고요. “보통 이상”이라는 응답은 도구를 10개 이상 사용하는 조직(31%)에서 가장 많이 나왔죠. 반면에 “부족하다”는 응답은 도구를 1개만 사용하는 조직(77%)이 가장 많았습니다.

많은 조직이 모니터링/옵저버빌리티에 여러 도구를 활용하는 건 당연한 행보인데요. 애플리케이션 스택, 인터넷 스택 등 다양한 기술 스택에는 서로 다른 도구가 필요하기 때문이죠. Catchpoint에서는 “’도구 하나로 모든 걸 효과적으로 모니터링할 수 있다’는 생각은 비현실적”이라고 지적합니다. 많은 도구가 특정 시나리오를 처리하도록 설계됐고요. 글로벌 시장조사기관 Dimensional Research에 따르면, 적절한 도구 개수는 조직의 특정 요구사항, 모니터링 대상 시스템 특성, 효과적인 도구 관리·활용 방식, 도구 간 통합에 따라 달라지죠. 또 다양한 도구를 사용하면, 더 많은 기능을 이용할 수 있고요. 사용자는 그만큼 옵저버빌리티 가치를 폭넓게 누린다고 느낄 수 있습니다.

모니터링/옵저버빌리티 도구를 몇 개 쓰든, ‘조직에 적합한 도구’를 선택하는 게 중요합니다. New Relic의 제품 마케팅 디렉터인 Yoram Mireles는 다음 선택 기준을 제안하는데요. 첫째, 다양한 오픈 소스와 상용 도구 중 선택할 때 언어, 프레임워크, 하드웨어, 소프트웨어 등 전체 스택과 신중히 통합해야 합니다. 둘째, 사용하기 편리해야 하죠. 셋째, 실시간 데이터가 지능적인 분석, 통찰과 함께 풍부하고 직관적인 대시보드에 표시돼야 하고요. 넷째, 대시보드는 사용자가 문제를 명확히 이해하도록 데이터의 컨텍스트를 보여줘야 합니다. 다섯째, 트러블슈팅 자동화와 예측 분석 제공을 지원하도록 머신러닝 도구도 기본으로 제공돼야 하고요.

4. 인시던트 대응 후 스트레스 증가

응답자가 지난 한 달 간 대응한 인시던트 수. 출처=Catchpoint | 인포그랩 GitLab
응답자가 지난 한 달 간 대응한 인시던트 수. 출처=Catchpoint

SRE 담당자는 한 달에 인시던트를 최소 1건 이상 대응하고 있습니다. Catchpoint의 설문조사에 따르면, 응답자 40%가 ‘지난 한 달간 1 ~ 5건의 인시던트에 대응했다’고 밝혔고요. 6 ~ 10건(23%), 0건(14%), 11 ~ 20건(13%), 21 ~ 50건(6%), 50건 이상(4%)이 그 뒤를 이었죠. 인시던트에 대응하면서 담당자의 스트레스 수준은 높아지는데요. 설문조사에서 응답자 83%가 ‘인시던트가 발생하는 동안 스트레스 수준이 올라간다(가끔, 종종, 항상)’고 답변했고요. 응답자 59%는 ‘인시던트 이후에도 스트레스 수준이 더 높아진다’고 답했습니다. 인시던트가 발생할 때 ‘스트레스를 좀처럼 받지 않는다’는 응답자 중 14%도 ‘인시던트 이후에는 스트레스가 증가했다’고 밝혔고요.

인시던트를 한 달에 1 ~ 5건 처리하면, 비교적 관리 가능한 수준으로 볼 수도 있는데요. 그러나 Catchpoint에서는 ‘인시던트를 한 달에 6 ~ 10건 처리한 사람은 다른 책임이 가중될 때, 업무 부담이 훨씬 더 클 수 있다’고 지적합니다. 인시던트 발생 당시보다 이후에 스트레스가 증가하는 이유는 다음과 같이 해석됩니다. 완전히 해결되지 않은 인시던트가 계속 영향을 미칠 수도 있고요. ‘비난하지 않는 사후 관행’이 부족한 환경에서 ‘장애로부터 교훈을 얻어야 한다’는 압박감이 한몫했을 수도 있습니다.

인시던트 여파를 효과적으로 관리하려면 종합적 대처가 필요합니다. 시스템 복원력과 안정성을 향상하는 게 우선이고요. 인시던트가 발생하지 않더라도 모니터링과 알림 체계를 점검해 ‘중요한 신호를 포착하지 못한 건 아닌지’ 점검해야 하죠. 사후 검토를 올바로 수행하는 것도 중요합니다. FanDuel의 엔지니어링 디렉터인 Jonathan Word는 사후 검토 회의 시 유의 사항을 이렇게 제언하는데요. 첫째, 대화를 적절히 제어하고요. 둘째, 사람이 아닌 프로세스를 지적합니다. 셋째, 책임감을 느끼고 배우고요. 넷째, 서면 피드백을 수집합니다. 다섯째, 행동에 집중하고요. 여섯째, 검토의 반복 가능성을 기억합니다.

맺음말

지금까지 2025년 SRE 트렌드 4가지를 알아봤습니다. 이 글의 요점은 다음과 같은데요.

  1. 서비스 수준 목표(SLO)가 조직의 엔지니어링 과제에서 높은 우선순위를 차지하고 있습니다. SLO는 일정 기간 특정 서비스에 합의된 성능 목표인데요. Catchpoint의 설문조사에서 응답자 40%가 ‘조직이 앞으로 12개월 동안 우선으로 도입할 엔지니어링 과제’로 SLO와 경험 수준 목표(XLO)를 꼽았습니다. 조직은 성능을 개선해 서비스 안정성과 신뢰성을 높이고, 비즈니스 가치를 향상하고자 SLO에 가치를 두고 있습니다.
  2. SRE 담당자 업무의 Toil 비중이 최근 5년 새 처음으로 증가했습니다. Toil은 프로덕션 서비스 운영과 관련된 작업으로, 수동적이고 반복적이며 자동화할 수 있는 일이죠. Catchpoint의 설문조사에 따르면, 응답자 업무의 Toil 비중 중앙값(p50)은 20%로, 지난해(14%)보다 6%p 늘었습니다. 이는 AI 작업 검수와 유지보수 부담이 증가한 영향으로 분석됩니다.
  3. 오늘날 조직은 모니터링/옵저버빌리티 도구를 평균 2개 이상 사용합니다. Catchpoint 설문조사에서 응답자 94%가 이같이 답변했고요. 특히 모니터링/옵저버빌리티 도구를 많이 사용할수록 조직의 옵저버빌리티 수준을 높게 인식하는 경향이 나타났습니다. 애플리케이션 스택, 인터넷 스택 등 다양한 기술 스택에는 서로 다른 도구가 필요하고요. 다양한 도구를 사용하면, 더 많은 기능과 혜택을 누릴 수 있습니다.
  4. SRE 담당자는 한 달에 인시던트를 최소 1건 이상 대응하고 있습니다. Catchpoint의 설문조사에 따르면, 응답자 40%가 ‘지난 한 달간 1 ~ 5건의 인시던트에 대응했다’고 밝혔고요. 인시던트 대응 이후에도 높은 스트레스를 경험합니다. 비난하지 않는 사후 검토 문화, 프로세스 개선, 피드백 체계 구축이 인시던트와 스트레스 개선에 필수적입니다.

참고 자료

  1. “SRE Report 2025”, Catchpoint, 2025, https://www.catchpoint.com/asset/2025-sre-report
  2. “서비스 수준 목표(SLO)란 무엇인가요?”, IBM, https://www.ibm.com/kr-ko/topics/service-level-objective
  3. “Slow is the new Down”, F5, 2020-09-14, https://www.f5.com/company/blog/slow-is-the-new-down
  4. “Page load time statistics”, Think with Google, https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/page-load-time-statistics/
  5. 어다희·천기철, “신뢰성 향상을 위한 SLI/SLO 도입 1편 - 소개와 필요성”, LY Corporation Tech Blog, 2025-02-21, https://techblog.lycorp.co.jp/ko/sli-and-slo-for-improving-reliability-1
  6. “사이트 신뢰성 엔지니어링(SRE)이란 무엇인가요?”, AWS, https://aws.amazon.com/ko/what-is/sre/
  7. Wuji Zhu, “Summarizing Post Incident Reviews with GPT-4”, Canva, 2023-11-14, https://www.canva.dev/blog/engineering/summarise-post-incident-reviews-with-gpt4/
  8. “Site reliability engineering book”, Google, https://sre.google/sre-book/table-of-contents/
  9. Yoram Mireles, “옵저버빌리티(Observability)란?”, New Relic, 2024-01-24, https://newrelic.com/kr/blog/best-practices/what-is-observability
  10. Grace(박민영), “지금 주목해야 할 옵저버빌리티 트렌드 5가지”, 인포그랩 기술 블로그, 2024-06-05, https://insight.infograb.net/blog/2024/06/05/011y-trends/
  11. Jonathan Word, “How to conduct a postmortem review meeting”, Medium, 2024-01-04, https://argoday.medium.com/how-to-conduct-a-postmortem-review-meeting-8cb5d2d2b303

우리 회사에 딱 맞는 DevSecOps 관행과 프레임워크를 찾고 계시나요? DevOps 전문가, 인포그랩과 상담하세요!