01 · SRE는 운영 문제를 어떻게 엔지니어링으로 푸는가

영어 위키백과 Site reliability engineering 항목의 2026-10-04 판을 바탕으로 구성했습니다. 용어와 실무 설명은 Google SRE 책을 참고해 보충했습니다.

SRE도 서비스를 운영합니다. 사이트 신뢰성 엔지니어링(SRE)은 그 운영을 소프트웨어 공학의 문제로 다루는 방식입니다. 배포가 이어지고 장비가 고장 나며 예상하지 못한 트래픽이 몰리는 환경에서 변경 관리, 모니터링, 장애 대응, 용량 계획을 맡습니다. 서비스의 가용성·지연 시간·성능·효율을 살피면서, 장애 복구에 같은 수작업이 반복된다면 코드와 설계를 바꿔 사람의 개입을 줄입니다.

Google SRE 책은 개발과 운영의 협업, 자동화, 운영 업무에 공학적 방법을 적용한다는 점에서 DevOps와 SRE의 원칙이 겹친다고 설명합니다. DevOps가 협업 문화와 소프트웨어 전달 방식까지 넓게 다룬다면, SRE는 신뢰성을 측정하고 지키는 지표와 운영 원칙을 구체화합니다. 영어 위키백과는 SRE를 DevOps의 구체적인 구현으로 설명하며, Google SRE 책도 같은 관점으로 볼 수 있다고 설명합니다.

반복 업무가 하루를 채우면 개선은 멈춘다

SRE 팀은 반복되는 운영 문제를 고칠 시간을 확보해야 합니다. Google SRE 책은 서비스를 맡은 팀이 코드를 작성해 운영 업무를 줄이지 않으면 늘어나는 업무 부담을 감당할 수 없게 된다고 설명합니다.

Google SRE 책은 이런 운영 부담을 다룰 때 토일(toil)이라는 말을 씁니다. 수작업으로 반복되고, 자동화할 수 있으며, 끝내도 서비스에 지속적인 개선을 남기지 않는 일이 대표적입니다. 서비스 규모가 커질수록 업무량도 함께 늘어나는 성격을 띱니다. 경보를 확인한 뒤 정해진 명령을 실행하거나, 같은 설정을 여러 곳에 손으로 반영하는 일이 여기에 해당합니다.

자동화 스크립트를 만들었다고 토일이 모두 사라지지는 않습니다. Google SRE 책은 사람이 매번 그 스크립트를 실행하는 데 쓰는 시간도 토일로 봅니다. 실행 절차 일부를 코드로 옮겼어도 사람의 반복적인 개입은 남아 있기 때문입니다. 자동화 코드를 작성해 지속적인 개선을 남기는 일은 엔지니어링이고, 그 코드를 매번 손으로 실행하는 일은 토일입니다.

Google은 개선할 시간을 업무 배분으로 확보합니다. SRE 책의 Introduction에 나오는 원칙은 티켓 처리, 온콜, 수작업 등을 포함한 운영 업무에 50% 상한을 두고, 나머지 50%를 개발에 쓰는 것입니다. 책에 따르면 개발 시간이 지속해서 이 기준에 못 미치면 흔히 일부 운영 부담을 개발팀에 돌려주거나, 추가 운영 업무를 맡기지 않은 채 인력을 보강합니다.

실행 절차를 코드로 옮기고 안전장치와 검증을 붙여 토일을 줄입니다. 자주 발생하는 문제를 시스템이 스스로 복구하게 만들면 사람은 더 어려운 문제에 집중할 수 있습니다.

자동화에도 운영 책임은 남습니다. 실패하면 멈출 조건, 사람이 개입할 지점, 실행 결과를 확인할 방법까지 설계에 포함해야 합니다. 동작을 파악하기 어려운 자동화는 새로운 장애 원인이 될 수 있습니다.

배포를 계속할지 판단할 기준

개선할 시간을 확보한 다음에는 신뢰성을 어디까지 높일지 정합니다. 안정성만 좇으면 변경을 과도하게 제한하기 쉽고, 출시 속도만 좇으면 장애 위험이 커집니다.

Google SRE 책의 서비스 수준 목표 장은 SLO를 항상 충족하라는 요구가 혁신과 배포 속도를 늦출 수 있다고 설명하며, 오류 예산을 두고 목표를 벗어나는 비율을 추적하도록 권합니다.

출발점은 사용자가 기대하는 서비스 수준입니다. Google SRE 책은 수집하기 쉬운 지표를 그대로 목표로 삼기보다, 사용자가 중요하게 여기는 것부터 생각하고 이를 측정할 값을 고르도록 권합니다. 성공한 요청의 비율이나 응답 지연 시간처럼 서비스 수준을 나타내는 측정값이 SLI, 즉 서비스 수준 지표입니다.

가상의 목표를 “최근 30일 동안 요청의 99.9%가 성공한다”로 잡아 보겠습니다. 성공률이라는 SLI에 기간과 목표값을 붙인 이 문장이 서비스 수준 목표인 SLO입니다. 목표를 정할 때는 사용자의 기대와 함께 서비스 비용, 변경 속도를 고려합니다.

이 목표에서 허용하는 실패는 같은 기간 요청의 0.1%입니다. 이를 오류 예산이라고 부릅니다. 성공률 목표 99.9%를 지키면서 감당할 수 있는 실패의 범위가 정해진 것입니다.

오류 예산은 작업의 우선순위를 판단하는 근거로 쓰입니다. 예산이 남아 있으면 변경을 이어 갈 여지가 있고, 다 썼다면 안정화 작업을 우선할 근거가 생깁니다.

복구 뒤에 남겨야 할 변화

서비스를 복구해도 일은 남습니다. 장애 중에는 고객 영향을 줄이고 정상 상태를 되찾는 데 집중하지만, 복구 뒤에는 같은 문제가 반복되지 않도록 시스템과 운영 절차를 고칩니다. Google SRE 책은 주요 장애를 사후 분석하고, 문제를 바로잡거나 다음 대응을 개선할 작업을 정하도록 설명합니다.

그 작업에는 조사할 근거가 필요합니다. 관측성은 미리 준비한 대시보드를 확인하는 범위보다 넓으며, 예상하지 못한 질문도 메트릭·로그·트레이스를 바탕으로 조사하는 능력입니다. 장애 중 가설을 세우고 원인을 좁히는 데 쓰입니다. 인시던트 관리 절차는 누가 상황을 지휘하고 어떻게 소통하며 무엇을 기록할지 정해 긴급한 순간의 혼선을 줄입니다.

아래 도식은 앞서 설명한 장애 조사와 사후 분석에서 찾은 문제를 신뢰성 개선으로 이어 가는 과정을 보여 줍니다.

개선의 대상에는 변경·릴리스 관리도 포함됩니다. 배포 단위를 줄이고 검증과 롤백을 자동화하면 변경 위험을 낮출 수 있습니다. 카오스 엔지니어링에서는 통제된 조건에서 실패를 일으켜 시스템의 회복 능력과 대응 절차를 확인합니다.

서비스가 커질 때의 한계도 미리 살핍니다. 용량 계획은 트래픽과 자원 사용량이 늘어날 때 어디에서 한계가 나타날지 다루는 작업입니다. 대규모 시스템 설계에서는 추상적인 원칙에 머물지 않고 실제 용량, 장애 지점, 운영 비용을 함께 따져야 합니다.

SRE 팀의 경계는 어디까지인가

영어 위키백과에 따르면 Google의 SRE는 2003년 Benjamin Treynor Sloss가 프로덕션 엔지니어(production engineer) 7명으로 팀을 꾸리면서 시작됐습니다. Airbnb, Dropbox, IBM, LinkedIn, Netflix, Wikimedia 등이 이 개념을 도입했습니다. Meta에서는 프로덕션 엔지니어(production engineer)가 비슷한 일을 수행합니다.

SRE 팀이 있다고 답한 비율은 응답자가 속한 조직의 규모에 따라 달랐습니다. 위키백과가 인용한 2020년 개발·운영 전문가 572명 설문에서, 직원이 10,000명 이상인 조직의 응답자 중 64%가 SRE 팀이 있다고 답했습니다. 직원 101~1,000명 조직에서는 44%, 100명 이하 조직에서는 32%였습니다.

팀이 있다는 사실만으로 담당 업무까지 알 수는 없습니다. SRE 팀은 조직에 따라 제품·인프라·컨설팅 등 여러 형태로 발전했으며, 책임지는 서비스와 개발팀에 참여하는 방식이 다릅니다. 위키백과는 SRE 팀을 여러 모델로 나누어 소개합니다.

큰 조직에서는 제품별 SRE 팀과 Infrastructure SRE 팀을 함께 두기도 합니다. 각 제품의 SLO를 맡는 팀과 공통 기반의 신뢰성을 맡는 팀을 나누는 식입니다. 어떤 형태를 택하든 먼저 서비스 소유권과 의사결정 권한을 분명히 해야 합니다. 출시 속도를 조절하거나 시스템을 개선할 권한 없이 장애 대응만 맡긴다면, SRE라는 이름과 실제 역할이 어긋납니다.

무엇으로 신뢰성을 측정할지, 목표를 벗어나면 작업의 우선순위를 어떻게 바꿀지, 장애에서 배운 내용을 누가 시스템 개선으로 이어 갈지 정해야 합니다. 이 질문에 답할 지표와 권한, 엔지니어링 시간이 마련될 때 SRE는 운영 문제를 코드와 시스템 설계로 해결할 수 있습니다.

더 읽을 자료

• Site Reliability Engineering — Google의 SRE 원칙과 운영 경험
• The Site Reliability Workbook — SLO, 모니터링, 장애 대응 등을 도입하는 실무 방법
• What is Toil in SRE? — 토일을 구분하는 기준과 줄이는 이유
• Non-Abstract Large System Design — 현실의 제약을 반영하는 대규모 시스템 설계 연습
• SREcon — 여러 조직의 SRE 경험을 공유하는 USENIX 콘퍼런스
• Awesome Site Reliability Engineering · How they SRE — SRE 사례와 자료 모음