토일(Toil) 제거와 자동화: SRE의 핵심 효율화 원칙
운영팀이 항상 바쁜 이유
인프라가 커질수록 운영팀이 더 바빠진다. 서버가 2배 늘면 배포 확인 시간도 2배, 인증서 갱신 건수도 2배, 온콜 알림도 2배다. 팀 규모는 그대로인데 서비스는 커졌으니 항상 뒤처지는 기분이다. 야근을 해도 내일 아침이면 티켓이 쌓여 있다.
Google SRE는 이 현상에 이름을 붙였다. 토일(Toil)이다. 그리고 토일이 전체 업무의 50%를 넘으면 구조적으로 손봐야 한다는 원칙을 세웠다.
토일을 이해하면 운영팀이 왜 항상 바쁜지, 무엇을 자동화하면 그 악순환을 끊을 수 있는지 알 수 있다.
토일이란 무엇인가
토일(Toil)은 다음 여섯 가지 속성을 모두 갖는 운영 업무다.
1. 수동(Manual): 사람이 직접 수행해야 한다. 스크립트가 있더라도 사람이 그 스크립트를 실행해야 하는 단계가 있다면 수동 요소가 남아 있다.
2. 반복(Repetitive): 같은 작업을 계속 반복한다. 처음 해결하는 새로운 문제는 토일이 아니다. 어제와 똑같이 또 해야 하는 것이 토일이다.
3. 자동화 가능(Automatable): 기계가 대신할 수 있다. 사람만이 판단할 수 있는 복잡한 의사결정이 필요한 업무는 토일이 아니다.
4. 전술적(Tactical): 장기 개선이 아닌 즉각 대응이다. 지금 당장 응답해야 하지만 끝나고 나면 팀의 역량이 향상되지 않는 작업이다.
5. 지속적 가치 없음(No Enduring Value): 완료해도 서비스 상태가 개선되지 않는다. 같은 일을 다음 주에 또 해야 한다.
6. 서비스 성장에 비례(Scales with Service): 서비스가 커질수록 작업량도 선형으로 늘어난다. 반면 진정한 엔지니어링 작업은 한 번 구축하면 서비스 규모가 늘어도 추가 작업이 적다.
토일과 혼동하기 쉬운 것들
장애 대응 중 수행하는 작업은 판단과 적응이 필요하므로 토일이 아니다. 오히려 그 장애가 반복 발생하는 패턴을 처리하는 루틴이 토일이다.
소프트웨어 개발 자체도 토일이 아니다. 코드 리뷰, 아키텍처 설계, 신기술 학습은 장기적 가치를 만드는 엔지니어링 작업이다.
행정 업무(회의, 채용 인터뷰, 보고서 작성)는 토일이 아니다. 이를 "업무 오버헤드"라고 별도로 구분하여 관리한다.
토일의 실제 예시
운영 현장에서 자주 만나는 토일의 예는 다음과 같다.
| 작업 | 토일인 이유 | 자동화 방향 |
|---|---|---|
| 배포 전 체크리스트 수동 확인 | 반복, 자동화 가능 | CI/CD 파이프라인 게이트 |
| 인증서 만료 전 수동 갱신 | 반복, 규칙 기반 | cert-manager, Let's Encrypt 자동화 |
| 같은 유형 온콜 알림 반복 처리 | 반복, 동일 절차 | 자동 완화 스크립트, 런북 봇 |
| 임시 용량 추가 요청 처리 | 반복, 규칙 기반 | 오토스케일링 정책 |
| 매주 같은 SQL 보고서 수동 생성 | 반복, 자동화 가능 | 정기 쿼리 자동화 |
| 사용자 권한 수동 부여 | 반복, 승인 흐름 | IDP + RBAC 자동화 |
| 배포 후 수동 smoke test | 반복, 자동화 가능 | 자동화 e2e 테스트 |
토일 측정하기
토일을 줄이려면 먼저 측정해야 한다. 막연히 "많다"는 느낌으로는 우선순위를 정할 수 없다.
토일 비율
토일 비율 = 토일에 쓴 시간 / 전체 업무 시간 × 100
Google 권고 기준: 토일 비율 < 50%
이상적 목표: 토일 비율 < 30%측정 방법은 팀마다 다양하다. 가장 간단한 방법은 2주 스프린트 동안 각자 업무를 토일/엔지니어링/오버헤드로 분류하여 추적하는 것이다.
토일 인벤토리 작성
각 토일 항목에 대해 다음을 기록한다.
| 필드 | 내용 |
|---|---|
| 이름 | 작업 이름 |
| 빈도 | 주 1회, 월 1회, 이벤트 트리거 등 |
| 소요 시간 | 회당 분/시간 |
| 월간 총 시간 | 빈도 × 소요 시간 |
| 자동화 난이도 | 쉬움/보통/어려움 |
| 자동화 예상 절감 시간 | 월간 |
이 인벤토리를 만들면 "어디를 먼저 자동화해야 하는가"를 데이터로 판단할 수 있다.
자동화 ROI 계산
자동화 ROI = 월간 절감 시간 / 자동화 구현 시간
예:
월간 인증서 갱신 작업: 4시간/월
자동화 구현: 8시간 (once)
ROI = 4시간/월 기준 2개월이면 회수, 이후 매월 4시간 절감
목표 ROI: 6개월 이내 회수 가능한 항목 우선토일 제거 전략
전략 1: 자동화(Automation)
토일 제거의 첫 번째 선택지다. 반복 작업을 스크립트, CI/CD 파이프라인, 오토스케일링 정책, API 호출로 대체한다.
자동화의 함정은 자동화 자체가 새로운 토일을 만드는 경우다. 스크립트가 깨지면 고쳐야 하고, 파이프라인이 실패하면 재실행해야 한다. 자동화 코드도 유지보수 비용이 있으므로, 낮은 빈도의 토일보다 높은 빈도의 토일을 먼저 자동화해야 한다.
좋은 자동화의 기준:
- 사람 없이 완전히 실행된다
- 실패 시 명확한 오류 메시지를 남긴다
- 재실행이 안전하다(idempotent)
- 로그와 알림이 붙어 있다
전략 2: 위임과 플랫폼화(Delegation and Self-Service)
운영팀이 모든 요청을 직접 처리하지 않고, 요청자가 셀프서비스로 처리할 수 있는 플랫폼을 만든다.
예: 개발팀이 직접 배포할 수 있는 내부 플랫폼 → 운영팀의 배포 지원 토일 제거
이 접근이 성공하려면 플랫폼이 충분히 안전하고 사용하기 쉬워야 한다. 복잡한 플랫폼은 오히려 "플랫폼 도입 지원" 토일을 만든다.
전략 3: 운영 부채 상환(Operational Debt Reduction)
토일이 반복되는 이유는 종종 시스템 설계상의 문제다. 매주 같은 쿼리를 수동으로 최적화해야 한다면 인덱스 설계나 쿼리 패턴이 문제일 수 있다. 매달 같은 서버가 메모리 부족으로 재시작된다면 메모리 누수를 고쳐야 한다.
근본 원인 없이 증상만 처리하는 것은 토일의 재생산이다.
전략 4: 제거(Elimination)
자동화하지 않고 그냥 없애는 것이 최선인 경우도 있다. 아무도 보지 않는 보고서를 매주 만들고 있다면 먼저 수신자에게 필요한지 물어봐야 한다. 불필요한 알림을 조용히 끄는 것이 자동화 스크립트보다 빠른 해결책이다.
50% 규칙과 토일 예산
Google SRE의 핵심 원칙 중 하나는 SRE가 토일에 쓰는 시간이 전체의 50%를 넘으면 안 된다는 것이다.
이 규칙의 의미는 세 가지다.
첫째, 토일이 50%를 넘으면 팀 리더십이 원인을 파악하고 개선해야 할 책임이 있다. "원래 그런 것"으로 넘어가지 않는다.
둘째, 50% 이상의 시간을 엔지니어링 작업에 써야 한다. 엔지니어링 작업은 자동화 구현, 신뢰성 개선, 플랫폼 구축이다. 이것이 다음 분기의 토일 비율을 낮추는 투자다.
셋째, 신규 서비스가 팀에 온보딩될 때 토일도 함께 온다. 팀이 추가 토일을 흡수할 여력이 없으면 온보딩을 거부하거나 자동화가 먼저라는 협상을 해야 한다.
토일 예산 관리 예시:
팀 인원: 6명, 총 월 업무 시간: 6 × 160 = 960시간
허용 토일 예산 (50%): 480시간/월
현재 토일: 측정 결과 550시간/월 → 예산 초과
개선 액션:
1. 인증서 갱신 자동화 → -40시간/월
2. 배포 smoke test 자동화 → -30시간/월
3. 온콜 자동 완화 스크립트 → -20시간/월
예상 절감: -90시간/월 → 460시간/월 (예산 이내)온콜과 토일의 관계
온콜 알림은 토일의 주요 원천이다. 알림이 반복해서 울리고, 매번 같은 절차로 처리하고, 자동화하지 않으면 그것 자체가 토일이다.
좋은 온콜 알림의 기준:
- 즉각적인 사람 행동이 필요하다
- 행동 방법이 런북에 정의되어 있다
- 알림 빈도가 주 1회 미만이다
반복 알림을 그냥 처리하는 팀과, 반복 알림을 자동 완화 → 근본 원인 수정 → 알림 제거 사이클로 처리하는 팀의 차이가 1~2년 후 온콜 부담 차이를 만든다.
알림 피로(Alert Fatigue) 지표:
알림 처리율이 낮다 → "항상 울려서 무시한다"는 신호
온콜 담당자가 알림 중 50% 이상을 즉시 닫는다 → 노이즈가 많다는 신호
같은 알림이 주 5회 이상 → 근본 원인 수정 필요 또는 자동화 필요데이터베이스 운영의 토일 예시
DBA와 데이터 플랫폼 엔지니어의 실제 토일 목록을 구체적으로 보면 다음과 같다.
| 토일 | 빈도 | 자동화 방향 |
|---|---|---|
| 슬로우 쿼리 분류 및 담당자 전달 | 매일 | slow_log 자동 파싱 + Jira 티켓 생성 |
| 복제 지연 초과 시 수동 확인 | 부정기 | Prometheus 알림 + 자동 점검 스크립트 |
| 백업 완료 여부 수동 확인 | 매일 | 백업 결과 자동 검증 + 알림 |
| 임시 분석 쿼리 환경 프로비저닝 | 요청 시 | 셀프서비스 분석 환경 플랫폼 |
| 디스크 사용량 수동 모니터링 | 주기적 | 용량 예측 알림 자동화 |
| 파티션 추가 작업 | 월별 | 파티션 관리 자동화 스크립트 |
| 사용자 권한 부여/회수 요청 처리 | 수시 | IDP 연동 + RBAC 자동화 |
토일 제거의 조직 효과
토일 비율을 30% 이하로 유지하는 팀에서 나타나는 패턴은 다음과 같다.
엔지니어링 역량이 향상된다. 반복 업무 대신 시스템 개선에 시간을 쓰므로 기술 역량이 쌓인다.
온콜 부담이 줄어든다. 자동화로 처리된 알림이 많을수록 사람이 받는 야간 호출이 적어진다.
신규 서비스 온보딩이 빨라진다. 플랫폼이 잘 되어 있으면 새 서비스가 추가되어도 운영 부담이 선형으로 증가하지 않는다.
번아웃이 줄어든다. 반복 업무는 동기 부여를 빠르게 소진한다. 자동화가 늘면 엔지니어가 더 의미 있는 문제에 집중할 수 있다.
실무 체크리스트
- 팀의 토일 비율을 측정하고 있는가? (스프린트 단위 분류 등)
- 토일 인벤토리가 문서화되어 있는가?
- 고빈도 온콜 알림 중 자동화 또는 제거 계획이 있는 것이 있는가?
- 마지막 반기에 토일 비율이 개선되었는가?
- 신규 서비스 온보딩 시 추가 토일 예산을 검토하는 절차가 있는가?
- 자동화 코드의 유지보수 비용도 토일로 추적하고 있는가?
- 플랫폼 셀프서비스화로 운영팀 없이 처리 가능한 작업이 늘고 있는가?
- 엔지니어가 토일 식별 → 자동화 → 검증 사이클을 독립적으로 진행할 수 있는가?
토일은 완전히 제거할 수 없다. 서비스가 살아 있는 한 어느 정도 운영 수작업은 남는다. 목표는 토일 비율을 관리 가능한 수준으로 유지하고, 그 속에서도 엔지니어링 역량을 지속적으로 성장시키는 구조를 만드는 것이다.
References
- Google SRE Book, "Eliminating Toil," https://sre.google/sre-book/eliminating-toil/
- Google SRE Workbook, "Eliminating Toil," https://sre.google/workbook/eliminating-toil/
- Google SRE Book, "Being On-Call," https://sre.google/sre-book/being-on-call/
- Upstat, "Toil in SRE: Identification and Reduction," https://upstat.io/blog/toil-reduction
- Pragmatic SRE, "Reducing Toil," https://www.pragmaticsre.com/psre-guide/2-reliability-engineering/reducing-toil
- Novel Vista, "SRE Toil Explained," https://www.novelvista.com/blogs/devops/sre-toil-explained
- DevSeat IT, "Toil Reduction: Strategies and Automation Priorities," https://devseatit.com/sre-practices/toil-reduction/
- Segfault, "SRE: Toil Reduction and Automation," https://segfault.pw/en/blog/sre-toil-reduction-and-automation