자동화가 실패했을 때 사람이 복구할 수 있게 만들기

자동화 워크플로우 시리즈 8/8

자동화의 목표는 사람이 하지 않아도 되는 일을 줄이는 것이다.

하지만 좋은 자동화는 사람을 완전히 배제하지 않는다.

오히려 실패했을 때 사람이 어디를 보고, 무엇을 다시 실행하고, 어떤 상태로 되돌릴 수 있는지 준비해둔다.

자동화는 언젠가 실패한다. 네트워크가 끊길 수 있고, API가 실패할 수 있고, 스크립트 제한에 걸릴 수 있고, 원천 데이터가 잘못될 수도 있다.

그래서 자동화 시스템에는 수동 복구 경로가 필요하다.

문제 상황

스프레드시트 기반 자동화 흐름은 여러 계층을 지난다.

폼 제출
-> 스프레드시트 기록
-> Apps Script 실행
-> API 호출
-> Lambda 처리
-> S3 JSON 저장
-> 화면 반영

이 중 하나만 실패해도 화면 데이터가 갱신되지 않거나, 공개 데이터가 오래된 상태로 남을 수 있다.

자동화가 정상일 때는 흐름이 단순해 보인다.

하지만 실패했을 때는 "어디까지 성공했고 어디서 멈췄는가"를 알아야 한다.

복구 가능한 자동화의 조건

복구 가능한 자동화에는 몇 가지 조건이 있다.

• 원천 데이터가 보존되어 있다.
• 동기화를 다시 실행할 수 있다.
• 이전 결과를 확인할 수 있다.
• 로그가 남아 있다.
• 실패 지점이 구분된다.
• 수동으로 실행할 수 있는 메뉴나 명령이 있다.
• 덮어쓰기 전에 백업이 남는다.

이 조건이 없으면 자동화 실패는 곧 데이터 손실이나 긴 장애로 이어진다.

원천 데이터는 건드리지 않는다

가장 중요한 원칙은 원천 데이터를 보존하는 것이다.

예를 들어 Google Forms와 Sheets를 쓰는 구조라면 원천 데이터는 Sheets에 남아 있어야 한다.

S3 JSON 생성이 실패해도 원천 데이터가 남아 있으면 다시 생성할 수 있다.

반대로 자동화 과정에서 원천 데이터를 덮어쓰거나 삭제하면 복구가 어려워진다.

자동화 스크립트는 가능하면 원천 입력을 직접 파괴하지 않고, 상태 컬럼이나 파생 데이터만 갱신하는 것이 좋다.

수동 재동기화 버튼 만들기

자동 trigger만 믿지 않는다.

운영자가 직접 실행할 수 있는 수동 동기화 경로가 필요하다.

예를 들어 Apps Script 메뉴에 다음 기능을 둘 수 있다.

운영 도구
├── 최신 데이터 동기화
├── 공개 데이터 재생성
├── 월별 스냅샷 생성
└── 동기화 상태 확인

이런 메뉴는 자동화 실패 시 복구 수단이 된다.

수동 실행 기능은 운영자가 이해할 수 있는 이름이어야 한다. 함수명 그대로 노출하기보다 업무 흐름에 맞춘 이름이 좋다.

감사 백업 남기기

동기화할 때 최신 파일만 덮어쓰면 이전 상태를 잃는다.

그래서 audit 경로를 둔다.

audit/YYYY-MM/YYYY-MM-DD/sync-HHMMSS.json

이 백업은 평소에는 쓰지 않는다.

하지만 문제가 생겼을 때 다음을 확인할 수 있다.

• 마지막 정상 동기화 데이터는 무엇인가
• 잘못된 데이터가 언제부터 생성되었는가
• 현재 latest와 이전 백업의 차이는 무엇인가
• 공개 데이터가 어떤 시점에 바뀌었는가

감사 백업은 작은 시스템에서 가장 단순한 복구 장치다.

로그 위치를 문서화하기

복구하려면 로그를 봐야 한다.

하지만 장애 중에 로그 위치를 찾는 것은 시간 낭비다.

문서에는 다음 위치를 적어야 한다.

계층	로그 위치
Apps Script	실행 로그
API Gateway	access log
Lambda	CloudWatch Logs
S3	저장된 객체와 timestamp
CloudFront	access log 또는 cache 상태
브라우저	DevTools Network

내부 문서에는 실제 리소스명을 적는다.

블로그 글로 바꿀 때는 일반화한다.

실패 상태를 사용자에게 보여주기

운영자 화면이 있다면 동기화 상태를 보여주는 것이 좋다.

예를 들어 다음 정보를 표시할 수 있다.

• 마지막 동기화 시각
• 마지막 동기화 결과
• 현재 데이터 기준 월
• 공개 데이터 생성 여부
• 오류 메시지 요약

이 정보가 없으면 운영자는 화면 데이터가 최신인지 알기 어렵다.

자동화는 백그라운드에서 조용히 돌아가지만, 운영자는 그 상태를 확인할 수 있어야 한다.

재시도는 조심해서 설계한다

실패하면 자동 재시도하면 되지 않을까?

부분적으로 맞다.

하지만 재시도는 멱등성과 함께 설계해야 한다.

같은 동기화를 여러 번 실행해도 결과가 같아야 한다.

예를 들어 latest JSON을 덮어쓰는 작업은 비교적 멱등하게 만들기 쉽다.

하지만 신청 상태를 변경하거나 알림을 보내는 작업은 중복 실행 시 문제가 생길 수 있다.

따라서 재시도 전에 다음을 확인한다.

• 같은 요청을 여러 번 보내도 안전한가
• 중복 파일이 생겨도 괜찮은가
• 상태 변경이 두 번 일어나지 않는가
• 알림이나 외부 호출이 중복되지 않는가

작은 자동화에서는 자동 재시도보다 수동 재실행이 더 안전할 때도 있다.

운영 문서에 복구 절차를 적기

복구 절차는 머릿속에 있으면 안 된다.

문서에 적어야 한다.

예시:

데이터가 화면에 반영되지 않을 때

1. 원천 시트에 최신 데이터가 있는지 확인한다.
2. Apps Script 실행 로그에서 마지막 sync 결과를 확인한다.
3. S3 latest 파일의 수정 시간을 확인한다.
4. public JSON이 생성되었는지 확인한다.
5. CloudFront 캐시 문제인지 확인한다.
6. 필요하면 수동 동기화를 실행한다.

이런 절차가 있으면 운영자가 혼자 대응할 수 있다.

자동화의 완성도는 실패 처리에서 드러난다

정상 흐름만 보면 자동화는 쉽게 보인다.

하지만 실제 완성도는 실패했을 때 드러난다.

• 실패를 감지할 수 있는가
• 실패 지점을 좁힐 수 있는가
• 원천 데이터가 남아 있는가
• 다시 실행할 수 있는가
• 이전 상태를 확인할 수 있는가
• 운영자가 절차를 이해할 수 있는가

이 질문에 답할 수 있어야 운영 가능한 자동화다.

정리

자동화는 사람이 아예 필요 없는 시스템을 만드는 일이 아니다.

반복 작업은 시스템이 처리하고, 예외와 복구는 사람이 판단할 수 있게 만드는 일이다.

그래서 좋은 자동화에는 다음이 필요하다.

• 원천 데이터 보존
• 수동 재동기화 경로
• 감사 백업
• 로그 위치 문서화
• 실패 상태 표시
• 멱등한 재실행 구조
• 복구 절차 문서

자동화는 언젠가 실패한다.

그때 사람이 다시 흐름을 이어갈 수 있다면, 그 자동화는 충분히 잘 설계된 것이다.

함께 볼 GitHub 저장소

• workflow-automation-samples