Toil

Toil이 뭔가

한 줄 정의

"자동화할 수 있는데 사람이 손으로 반복하고 있는 작업"

단순히 귀찮은 일이 아니다. Toil로 분류되려면 6가지를 만족해야 한다.

특징	설명
수동적	사람이 직접 해야 한다
반복적	같은 작업이 계속 발생한다
자동화 가능	기계가 대신할 수 있다
전술적	당장은 해결되지만 장기적 가치가 없다
비례 증가	서비스가 커질수록 작업량도 같이 늘어난다
방치하면 쌓임	줄이려는 노력 없이는 계속 늘어난다

---

뭐가 Toil이고 뭐가 아닌가

처음에 헷갈렸던 부분이다.

✅ Toil 맞음

• 서버 추가할 때마다 설정 파일 직접 수정
• 배포할 때마다 같은 체크리스트 수동 확인
• 매월 서버 100대에 직접 SSH 접속해서 패치 적용

❌ Toil 아님

• 장애 원인 분석 (매번 다른 문제, 판단 필요)

• 코드 리뷰 (판단 필요)

• 아키텍처 설계 (창의적 작업)

  장애 원인 분석을 Toil로 착각하기 쉬운데,
  매번 다른 원인을 다루고 판단이 필요하기 때문에 Toil이 아니다.

  ---

  50% 규칙

  Google SRE에서 정한 기준이다.

  SRE는 업무 시간의 50% 이상을 Toil에 써서는 안 된다

  Toil 비율	상태
  50% 미만	정상. 나머지를 자동화·개선에 사용
  50~70%	경고. 자동화 계획 즉시 수립 필요
  70% 초과	위험. SRE가 아니라 그냥 운영 인력이 된 상태

  ---

  "10분밖에 안 걸리니까 괜찮다"는 착각

  Toil을 방치하는 가장 흔한 이유다.

  10분 × 365일 = 연 60시간이다.
  팀원 5명이면 연 300시간이다.
  그리고 서비스가 커지면 10분이 20분, 30분이 된다.

  지금 작다고 방치하면 나중에 더 크게 돌아온다.

  ---

  자동화 투자 판단법

  Toil을 발견했다고 무조건 자동화하는 게 아니다.

  작업 시간 × 발생 빈도 > 자동화 개발 시간이면 해야 한다

  매주 3시간짜리 Toil이 있고 자동화 개발에 20시간이 걸린다면,
  7주 후부터 이득이고 1년 기준 136시간을 절약한다. 해야 한다.

  반대로 1년에 한 번 있는 작업을 자동화하는 데 40시간을 쓰면
  본전 뽑는 데 40년이 걸린다. 이건 하지 않는 게 낫다.

  ---

  정리

  Toil을 완전히 없애는 게 목표가 아니다.
  현실적으로 제로는 불가능하고, 자동화 자체도 비용이 든다.

  목표는 50% 이하로 유지하면서 남은 시간을 진짜 엔지니어링에 쓰는 것이다.