자동화의 목표는 사람이 개입하는 횟수를 줄이는 것이다. 그러나 자동화가 스스로 처리하지 못하는 상황은 반드시 발생한다. 이때 사람이 얼마나 빠르고 정확하게 개입하느냐에 따라 장애의 영향 범위가 결정된다.
Jurin을 운영하면서 정리한, 사람이 반드시 직접 개입해야 하는 상황과 그때 따르는 실제 루틴을 공개한다.
자동화가 스스로 처리하지 못하는 상황은 어떤 경우인가
자동화가 멈추는 경우는 크게 세 가지로 나뉜다.
첫째, 외부 서비스 장애다. 자동화가 의존하는 API나 서비스가 내려가면 파이프라인 전체가 중단된다. 이 경우 에이전트가 할 수 있는 것이 없다. 사람이 상황을 확인하고, 서비스가 복구될 때까지 대기하거나 수동으로 처리해야 한다.
둘째, 규칙에 없는 예외 상황이다. 에이전트는 사전에 정의된 규칙 안에서 작동한다. 규칙 밖의 상황이 발생하면 에이전트는 추측으로 처리하거나 멈춘다. 추측으로 처리했을 경우 결과가 맞는지 사람이 검토해야 한다.
셋째, 실패를 감지했지만 해결 방법을 모르는 경우다. 에이전트가 오류를 인식하고 알림을 보냈지만, 원인이 규칙 밖이라 다음 단계를 결정하지 못하는 상황이다. 이때는 원인 분석부터 사람이 진행한다.
장애가 발생했을 때 따르는 5단계 대응 루틴
장애 감지부터 복구까지 Jurin 운영에서 실제로 따르는 단계다.
1단계: 알림 수신 확인 (목표: 1분 이내) 자동화 장애 알림이 텔레그램으로 수신된다. 알림에는 어떤 작업이 실패했는지, 오류 코드는 무엇인지, 마지막 성공 시각은 언제인지가 포함된다. 알림 내용만으로 영향 규모를 첫 판단할 수 있도록 포맷을 표준화했다.
2단계: 영향 범위 파악 (목표: 5분 이내) 이 장애로 인해 오늘 예정된 작업 중 어떤 것이 영향을 받는지 확인한다. 영향받는 작업이 외부에 드러나는 작업(발행, 발송)인지, 내부 작업(저장, 분석)인지를 구분한다. 외부에 드러나는 작업일수록 더 빠른 대응이 필요하다.
3단계: 원인 분류 (목표: 10분 이내) 외부 서비스 장애인지, 코드 오류인지, 설정 문제인지를 파악한다. 외부 서비스 장애라면 해당 서비스의 상태 페이지를 확인한다. 코드나 설정 문제라면 에러 로그를 직접 읽는다. 원인 분류가 끝나야 다음 단계를 결정할 수 있다.
4단계: 수동 처리 또는 대기 결정 외부 서비스 장애의 경우 복구 예상 시간을 확인하고, 기다리는 것과 수동 처리 중 어느 쪽이 빠른지 판단한다. 직접 수정 가능한 오류의 경우 원인을 수정하고 파이프라인을 수동으로 재실행한다. 대기를 선택했다면 다음 확인 시각을 미리 정해두는 것이 좋다.
5단계: 재발 방지 조치 장애 처리 후에는 원인을 한 줄로 기록하고, 동일 유형의 장애가 다시 발생했을 때 더 빠르게 감지할 수 있는 조건을 추가한다. Jurin의 경우 이 단계에서 누적된 점검 조건이 현재 약 11개다. 매 장애마다 시스템이 조금씩 더 촘촘해지는 구조다.
사람 개입을 줄이는 설계 원칙은 무엇인가
장애 대응 루틴을 운영하면서 알게 된 것은, 개입이 필요한 상황의 약 70%가 사전에 예측 가능하다는 것이다. 외부 서비스 장애, 컨텍스트 초과, 규칙 미정의 케이스는 패턴이 있다.
사람 개입을 줄이는 가장 효과적인 방법은 두 가지다. 첫째, 자동화가 실패하는 패턴을 누적해서 기록한다. 둘째, 기록된 패턴에서 "다음에는 자동화가 처리할 수 있는 케이스"와 "항상 사람이 처리해야 하는 케이스"를 구분한다.
Jurin 직접 운영 기준, 자동화 도입 초기에는 월평균 약 8회 장애 대응이 필요했다. 루틴과 재발 방지 조치를 3개월 누적한 결과 월평균 약 2회로 줄었다. 장애 자체를 없애는 것은 어렵지만, 같은 장애를 반복하지 않는 것은 가능하다. 그 차이를 만드는 것이 5단계 루틴이다.