179. 토일 (Toil - SRE 운영 노동)

핵심 인사이트 (3줄 요약)

본질: 토일(Toil)은 서비스 유지에는 필요하지만 사람 손으로 반복되고 자동화 가능하며 장기 자산을 남기지 않는 SRE (Site Reliability Engineering) 운영 노동이다.

가치: 토일을 계량하고 줄이면 SRE는 티켓 처리반이 아니라 SLO (Service Level Objective), 자동 복구, 플랫폼 개선 같은 신뢰성 엔지니어링에 시간을 쓸 수 있다.

판단 포인트: 자주 발생하고, 규칙이 분명하며, 서비스 규모와 함께 늘어나는 작업이라면 "열심히 더 하자"가 아니라 자동화 백로그로 전환해야 한다.

Ⅰ. 개요 및 필요성

토일은 "운영에 필요하지만 사람의 시간을 계속 먹는 반복 수동 작업"이다. 서버 증설 승인, 인증서 갱신, 반복 알람 확인, 같은 명령 재실행처럼 서비스를 굴리기 위해 수행하지만, 끝나고 나면 재사용 가능한 제품 기능이나 플랫폼 자산이 남지 않는 일이 여기에 속한다. 즉 서비스는 잠시 유지되지만 조직의 운영 체력은 오히려 소모된다.

문제가 되는 이유는 토일이 서비스 성장과 거의 선형적으로 함께 커지기 때문이다. 사용자가 늘고 배포가 잦아지면 점검, 대응, 복구, 권한 변경, 스케일 조정도 함께 늘어난다. 이때 자동화보다 사람 대응에 의존하면 팀은 하루를 "불 끄기"에 쓰고, 정작 같은 문제가 다시 일어나지 않게 만드는 개선 작업은 뒤로 밀린다.

아래 그림은 토일이 왜 단순한 귀찮은 일이 아니라 운영 병목이 되는지 보여준다. 핵심은 토일이 많아질수록 개선 시간이 줄고, 개선 시간이 줄수록 다시 토일이 늘어나는 악순환이 생긴다는 점이다.

┌──────────────────────────────────────────────────────────────┐
│ 서비스 성장과 토일의 증폭                                    │
├──────────────────────────────────────────────────────────────┤
│ 사용자·트래픽 증가                                            │
│        │                                                      │
│        ▼                                                      │
│ 배포·알람·복구·증설 요청 증가                                 │
│        │                                                      │
│        ▼                                                      │
│ 사람이 매번 수행하는 수동 절차                                │
│        │                                                      │
│        ├─▶ 실수 증가 · 대응 편차 증가                         │
│        └─▶ 개선 시간 감소                                     │
│                     │                                         │
│                     ▼                                         │
│              자동화 지연 → 다시 토일 증가                     │
└──────────────────────────────────────────────────────────────┘

따라서 SRE에서 토일은 "성실함의 증거"가 아니라 "자동화되지 않은 운영 부채의 신호"로 봐야 한다. 토일을 줄이지 못하면 서비스 신뢰성은 사람 숙련도와 야근에 의존하게 되고, 결국 장애 대응 속도와 배포 속도 모두 떨어진다.

📢 섹션 요약 비유: 토일은 비가 올 때마다 사람이 양동이로 물을 퍼내는 일과 같다. 당장은 필요하지만, 배수 펌프를 만들지 않으면 비가 많이 올수록 사람만 더 지치게 된다.

Ⅱ. 아키텍처 및 핵심 원리

토일 관리는 단순히 "귀찮은 일을 자동화하자"가 아니라, 탐지 → 계량 → 우선순위화 → 자동화 → 가드레일 정착의 루프로 운영해야 한다. 그래야 팀이 느낌이 아니라 데이터로 토일을 논의하고, 반복되는 작업을 플랫폼 기능으로 승격시킬 수 있다.

토일 판단 기준	의미	대표 예시
수동적	사람이 직접 실행하거나 승인해야 끝남	수동 스케일 조정, 수동 롤백
반복적	같은 절차가 계속 되풀이됨	매주 같은 알람 확인, 로그 정리
자동화 가능	규칙과 입력이 비교적 명확함	인증서 갱신, 백업 검증, 재기동
전술적	당장 운영을 이어 가기 위한 임시 대응 중심	급한 증설, 임시 패치 반영
장기 가치 부족	끝나고 나면 재사용 가능한 자산이 남지 않음	같은 보고서 수작업 작성
규모 비례 증가	서비스 성장과 함께 시간 소모가 커짐	사용자 증가에 따른 수동 승인 증가

실무에서는 토일 비율을 수치로 관리하는 것이 중요하다. 흔히 토일 비율 = 토일 시간 / 전체 엔지니어링 시간 × 100으로 본다. "50% 미만" 규칙은 절대 법칙이라기보다, 엔지니어가 자동화보다 반복 대응에 더 많은 시간을 쓰기 시작하면 이미 구조가 기울고 있음을 알리는 경고선에 가깝다.

토일을 줄이는 과정은 보통 아래처럼 성숙한다. 중요한 점은 문서화만으로는 토일이 사라지지 않고, 실행 권한이 사람에서 시스템으로 넘어가야 비로소 운영 비용이 줄어든다는 점이다.

┌──────────────────────────────────────────────────────────────┐
│ 토일 제거 성숙도                                              │
├──────────────────────────────────────────────────────────────┤
│ 수동 실행                                                     │
│   │                                                           │
│   ▼                                                           │
│ 문서화된 Runbook                                              │
│   │                                                           │
│   ▼                                                           │
│ 스크립트 / 예약 작업                                          │
│   │                                                           │
│   ▼                                                           │
│ 이벤트 기반 자동화                                            │
│   │                                                           │
│   ▼                                                           │
│ Self-Service Platform / Auto Remediation                      │
└──────────────────────────────────────────────────────────────┘

예를 들어 인증서 갱신을 사람이 캘린더 보고 처리하면 토일이지만, 만료일을 감지해 자동 발급·배포·검증까지 이어지면 플랫폼 기능이 된다. 알람도 마찬가지다. 사람이 같은 경고를 매일 확인하고 "문제 없음"으로 닫는다면, 그 알람은 운영 가시성이 아니라 토일 생성기다.

결국 토일의 핵심 원리는 "사람이 규칙을 기억하는 구조를 시스템이 규칙을 실행하는 구조로 바꾸는 것"이다. 이 전환이 일어나야 SRE는 반복 작업을 줄이고 신뢰성 설계에 시간을 재투자할 수 있다.

📢 섹션 요약 비유: 토일 제거는 매일 손으로 문을 열어 주는 경비원을 더 뽑는 일이 아니라, 출입 규칙을 읽고 자동으로 열리는 출입 시스템을 만드는 일과 같다.

Ⅲ. 비교 및 연결

토일을 제대로 다루려면 "운영 업무 = 모두 토일"이라는 오해부터 버려야 한다. 운영에는 토일도 있지만, 토일이 아닌 중요한 엔지니어링 작업도 많다. 장애 회고, 배포 안전장치 설계, SLI (Service Level Indicator) 정의, 자동 복구 로직 개발은 운영과 관련 있지만 장기 자산을 남기므로 토일로 분류하면 안 된다.

항목	토일	비토일 운영 업무	엔지니어링 투자
반복성	높음	중간	상황에 따라 다름
사람 의존도	높음	필요 시 존재	줄이는 방향이 목표
장기 자산	거의 남지 않음	일부 남음	명확히 남음
성장 시 비용	선형 또는 그 이상 증가	증가 가능	오히려 향후 비용 감소
예시	수동 재기동, 반복 알람 확인	대규모 장애 조정, 훈련	자동 롤백, 셀프서비스 배포

같은 "수동 작업"이라도 모두 토일은 아니다. 드물게 일어나는 대형 장애에서 여러 팀을 조정하는 일은 자동화하기 어렵고, 사업 영향 판단이 필요하므로 토일보다는 고난도 운영 의사결정에 가깝다. 반대로 하루에도 수십 번 발생하는 재기동, 파일 정리, 권한 승인, 반복 알람 닫기는 규칙화 가능성이 높으므로 토일 후보가 된다.

토일은 SLO와도 직접 연결된다. 토일이 많으면 알람 품질 개선, 배포 안정화, 관측성 정비 같은 예방적 작업이 밀려 Error Budget을 더 빠르게 소모하게 된다. 그래서 토일 관리는 단순 효율화가 아니라, 신뢰성 목표를 지키기 위한 선행 조건이다.

또한 Platform Engineering과의 연결도 중요하다. 여러 서비스 팀이 같은 운영 절차를 반복한다면, 개별 팀이 각자 스크립트를 만드는 것보다 공통 플랫폼 기능으로 흡수하는 편이 효과가 크다. 이때 토일은 개인의 일상 문제가 아니라, 플랫폼 제품화 우선순위를 알려 주는 데이터가 된다.

📢 섹션 요약 비유: 토일과 엔지니어링의 차이는 매일 우편을 손으로 분류하는 일과 자동 분류기를 설계하는 일의 차이와 같다. 둘 다 우편 업무지만, 하나는 시간을 계속 쓰고 다른 하나는 앞으로의 시간을 아낀다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 중요한 것은 "무조건 자동화"가 아니라 "자동화 가치가 높은 토일부터 제거"하는 것이다. 빈도는 낮지만 위험이 큰 작업, 빈도는 높지만 절차가 완전히 정형화된 작업, 규칙은 명확하지만 아직 관측 지표가 부족한 작업을 구분해야 한다. 즉 빈도·소요 시간·사람 실수 위험·자동화 난도를 함께 봐야 한다.

후보 작업	권장 판단	이유
매일 반복되는 로그 정리	즉시 예약 작업 또는 정책화	규칙이 명확하고 사람 가치가 거의 없음
잦은 수동 스케일 조정	메트릭 기반 오토스케일링 도입	서비스 증가와 함께 계속 비용이 커짐
인증서 수동 갱신	자동 발급·검증·배포 체계 구축	만료 사고 위험이 크고 주기성이 분명함
반복 알람 확인 후 무조치 종료	알람 기준 재설계 또는 제거	알람이 토일을 만들고 있음
연 1회 복구 훈련	반자동 + 절차 검증 유지	훈련과 의사결정 요소가 남아 완전 자동화 대상은 아님

실무 체크리스트는 다음과 같다.

입력 조건과 종료 조건을 시스템이 판별할 수 있는가?
자동화 실패 시 안전한 롤백 또는 사람 개입 경로가 있는가?
자동화 전후 효과를 볼 지표가 있는가?
한 팀만의 문제가 아니라 여러 서비스의 공통 패턴인가?
해당 작업을 없애면 SRE 시간이 실제로 어떤 개선 작업으로 이동하는가?

흔한 안티패턴도 분명하다. 첫째, 나쁜 절차를 그대로 코드로 옮겨 "자동화된 혼란"을 만드는 경우다. 둘째, 토일을 개인 성실성 문제로 보고 측정조차 하지 않는 경우다. 셋째, 자동화 성공 뒤에도 운영 환경에서 수동 예외 처리를 허용해 드리프트를 만드는 경우다.

기술사 답안에서는 "토일 = 반복 수동 작업" 정의로 끝내지 말고, 어떤 작업이 토일인지 분류하고 왜 그 작업을 플랫폼 기능으로 승격해야 하는지까지 설명해야 완성도가 높다. 즉 토일은 분류 개념이면서 동시에 자동화 투자 우선순위를 정하는 관리 도구다.

📢 섹션 요약 비유: 토일 자동화 판단은 손설거지를 식기세척기로 바꿀지, 셰프의 최종 간 맞추기까지 기계에 맡길지를 구분하는 일과 같다. 반복 규칙 작업은 기계가 잘하지만, 상황 판단은 여전히 사람이 맡아야 할 수도 있다.

Ⅴ. 기대효과 및 결론

토일을 줄이면 가장 먼저 SRE의 시간이 되돌아온다. 그 시간은 알람 정비, 배포 안전장치, 셀프서비스 플랫폼, 복구 자동화처럼 다시 토일을 줄이는 선순환 투자로 이어질 수 있다. 결과적으로 장애 편차가 줄고, 대응 절차가 표준화되며, Mean Time To Recovery (MTTR)도 개선되기 쉬워진다.

물론 토일을 0으로 만드는 것은 현실적이지 않다. 드문 예외 상황, 고위험 승인, 규정 준수 검토처럼 사람 판단이 남아야 하는 영역은 계속 존재한다. 또 너무 이른 자동화는 관측 불충분 상태에서 실패를 더 크게 확산시킬 수 있으므로, 토일 제거는 단계적 관측·검증 체계와 함께 가야 한다.

그래도 기억해야 할 핵심은 분명하다. 토일은 "운영팀이 바쁘다"는 사실의 다른 표현이 아니라, 아직 제품화되지 않은 운영 지점이 어디인지 알려 주는 지도다. SRE는 그 지도를 따라 반복 노동을 플랫폼 기능으로 바꾸는 역할을 수행할 때 가장 큰 가치를 만든다.

📢 섹션 요약 비유: 토일 관리는 청소를 더 자주 하는 일이 아니라, 먼지가 계속 쌓이는 구조를 바꾸는 일과 같다. 구조가 바뀌면 같은 노력으로도 집이 훨씬 오래 깨끗하게 유지된다.

📌 관련 개념 맵

개념	연결 포인트
SRE (Site Reliability Engineering)	토일을 줄여 신뢰성 엔지니어링 시간을 확보하려는 운영 모델
SLI (Service Level Indicator) / SLO (Service Level Objective)	토일 감소로 확보한 시간을 어디에 재투자할지 결정하는 신뢰성 기준
Runbook	수동 절차를 표준화해 자동화 가능한 형태로 바꾸는 중간 단계
Auto Remediation	토일을 사람이 아니라 시스템이 직접 처리하게 만드는 자동 복구 계층
Platform Engineering	반복 운영 절차를 공통 제품 기능으로 흡수하는 조직적 확장 방식
Alerting Hygiene	반복 확인만 강요하는 알람을 줄여 토일 발생 자체를 억제하는 활동

📈 관련 키워드 및 발전 흐름도

수동 운영 요청
    │
    ▼
토일 분류 · 시간 측정
    │
    ▼
Runbook 표준화
    │
    ▼
스크립트 · 워크플로 자동화
    │
    ▼
Auto Remediation · Self-Service Platform
    │
    ▼
SRE의 신뢰성 개선 시간 확보

이 흐름은 반복 수동 작업을 단순 기록으로 끝내지 않고, 플랫폼 기능으로 승격시키는 성숙 경로를 보여준다.

👶 어린이를 위한 3줄 비유 설명

토일은 매일 똑같은 버튼을 사람이 대신 눌러 주는 귀찮은 일이에요.
버튼 누르는 규칙이 똑같다면 기계가 대신 누르게 만드는 게 더 좋아요.
그러면 사람은 버튼만 누르지 않고, 기계를 더 똑똑하게 만드는 일을 할 수 있어요.