SRE 실무 #6 토일 줄이기: 반복 수작업의 측정과 자동화, 그리고 도입 로드맵
시리즈의 마지막 주제는 화려하지 않지만 팀의 미래를 결정하는 문제입니다. 운영 수작업이 엔지니어링 시간을 잠식하는 것을 어떻게 막는가. SRE 용어로 토일(toil)이라 부르는 이 작업들을 방치하면, 서비스가 성장할수록 팀은 운영에 매몰되고, 자동화할 시간이 없어서 수작업을 계속하는 악순환에 갇힙니다.
토일의 판별: 힘든 일이 아니라 특정한 종류의 일입니다 #
토일은 “힘들고 하기 싫은 일"의 감상적 표현이 아니라 판별 기준이 있는 용어입니다. 다음 성질을 많이 가질수록 토일입니다.
- 수동적: 사람이 손으로 실행합니다. 스크립트를 사람이 돌리는 것도 포함됩니다.
- 반복적: 처음이 아니라 몇 번째인지 셀 수도 없는 작업입니다.
- 자동화 가능: 사람의 판단이 본질적으로 필요하지 않고, 기계가 같은 결과를 낼 수 있습니다.
- 전술적: 장기 가치를 만들지 않습니다. 끝내도 시스템은 어제와 같은 상태입니다.
- 성장에 비례: 사용자·트래픽·서버가 늘면 작업량도 따라 늡니다.
디스크 정리, 수동 배포 승인 클릭, 계정 생성 요청 처리, 매주 같은 쿼리를 돌려 보고서 만들기. 전부 전형적 토일입니다. 반면 장애 대응 중의 판단, 아키텍처 설계, 자동화 개발 자체는 힘들어도 토일이 아닙니다. 이 구분이 중요한 이유는, 토일만이 자동화로 없앨 수 있는 대상이기 때문입니다.
50% 규칙: 상한이 없으면 반드시 넘칩니다 #
구글 SRE가 널리 알린 운영 원칙이 있습니다. 운영 업무(토일 + 온콜 + 티켓)가 팀 시간의 50%를 넘지 않게 한다. 나머지 절반은 토일을 줄이는 엔지니어링(자동화, 신뢰성 개선)에 씁니다.
50이라는 숫자 자체보다 중요한 것은 상한의 존재입니다. 상한이 없으면 운영 업무는 반드시 팽창합니다. 서비스는 계속 성장하는데 토일은 성장에 비례하기 때문입니다. 상한을 지키는 방법은 측정입니다.
- 분기마다 한 번, 팀원별로 지난 2주의 시간 사용을 대략 분류해 봅니다. 정밀할 필요 없습니다. “운영 70%“라는 대략적 숫자만으로도 대화가 시작됩니다.
- 50%를 넘는 상태가 지속되면, 이것은 개인의 시간 관리 문제가 아니라 팀의 투자 배분 결정 사항입니다. 자동화 스프린트를 편성하거나, 토일의 원천인 서비스를 개발팀에 되돌려주거나(운영 이관 반납), 인력을 조정하는 결정이 필요합니다.
자동화 우선순위: 빈도 × 시간 + 위험 #
토일 목록을 만들었으면 어디부터 자동화할지 정합니다. 기본 산식은 연간 절약 시간 = 빈도 × 건당 소요 시간이고, 여기에 두 가지 가중치를 얹습니다.
- 실수 위험: 사람이 하다가 틀리면 장애가 되는 작업(프로덕션 DB 수동 조작 등)은 절약 시간이 작아도 우선순위를 올립니다. 자동화의 가치가 시간 절약이 아니라 사고 방지이기 때문입니다.
- 자동화 비용: 연간 10시간 아끼는 자동화에 3주를 쓰는 것은 손해입니다. 다만 비용 계산에는 “그 작업 때문에 끊기는 집중"과 “그 작업을 아는 사람이 휴가면 멈추는 업무” 같은 숨은 비용도 넣어야 합니다.
주의할 함정 하나. 깨진 프로세스의 자동화는 깨진 결과를 빠르게 만들 뿐입니다. 승인 절차가 이상해서 생기는 티켓을 자동 처리하는 것보다, 승인 절차 자체를 없애는 것이 먼저인 경우가 많습니다. 자동화 전에 “이 작업이 애초에 왜 존재하는가"를 한 번 물어야 합니다.
자동화의 사다리: 런북 → 스크립트 → 셀프서비스 #
자동화는 전부 아니면 전무가 아니라 단계적으로 올라갑니다.
- 문서화(런북): 머릿속 절차를 문서로 만듭니다. 자동화의 전 단계이자, 절차의 이상한 부분이 처음 드러나는 단계입니다.
- 반자동화(스크립트): 런북의 명령들을 스크립트로 묶되 실행 판단은 사람이 합니다. 대부분의 토일은 이 단계만으로 소요 시간이 크게 줍니다.
- 완전 자동화: 트리거부터 실행까지 사람이 빠집니다. 디스크 정리, 인증서 갱신, 실패한 작업 재시도처럼 판단이 필요 없는 작업이 대상입니다. 안전장치(변경 한도, 이상 시 중단)와 함께 갑니다.
- 셀프서비스: 요청자가 직접 처리하게 만듭니다. “계정 만들어 주세요” 티켓을 받는 대신, 요청자가 폼과 자동 승인 규칙으로 스스로 처리하는 플랫폼을 제공합니다. 토일이 팀에서 사라지는 종착점입니다.
반복 스크립트 작성이 처음이라면 파이썬 자동화 시리즈가 2단계의 도구 상자가 됩니다.
시리즈를 마치며: 도입의 현실적 순서 #
6편을 관통하는 구조는 하나입니다. 측정이 합의를 만들고, 합의가 행동을 정당화합니다. SLO가 없으면 에러 버짓이 없고, 버짓이 없으면 “지금 신뢰성에 투자해야 한다"는 주장이 목소리 큰 사람의 의견에 머뭅니다. 조직에 도입하는 현실적 순서는 이렇습니다.
- 서비스 하나, 여정 2〜3개로 SLO를 만듭니다 (1편). 전사 도입을 선언하지 않습니다.
- 버짓 정책을 경영진과 합의합니다 (2편). 여기가 가장 어렵고 가장 중요합니다.
- 경보를 SLI 기반으로 바꿉니다 (3편). 새벽 호출이 줄어드는 것을 팀이 체감하는 단계이고, 제도의 신뢰가 여기서 생깁니다.
- 온콜과 포스트모템을 정비합니다 (4편, 5편). 대응과 학습의 루프가 닫힙니다.
- 토일을 측정하고 자동화 시간을 확보합니다 (이 편). 루프가 굴러가는 상태를 유지하는 힘입니다.
한 서비스에서 이 루프가 돌기 시작하면, 다른 팀은 결과를 보고 따라옵니다. 제도는 선언이 아니라 사례로 퍼집니다.
정리 #
- 토일은 수동·반복적·자동화 가능·전술적·성장 비례라는 판별 기준을 가진 용어입니다. 힘든 일 전부가 토일은 아닙니다.
- 운영 업무에 50% 상한을 두고 분기마다 대략적으로라도 측정합니다. 초과가 지속되면 팀 차원의 투자 결정으로 승격합니다.
- 자동화 우선순위는 빈도 × 시간에 실수 위험을 가중해 정하고, 깨진 프로세스는 자동화 전에 프로세스부터 고칩니다.
- 자동화는 런북 → 스크립트 → 완전 자동화 → 셀프서비스의 사다리로 올라갑니다.
- 도입 순서는 SLO → 버짓 정책 → 경보 → 온콜·포스트모템 → 토일 관리입니다. 한 서비스의 성공 사례가 최고의 전파 수단입니다.