서버리스 크론 작업 장애 대응 플레이북

서버리스 환경에서 크론 작업은 ‘작게 자주 실행된다’는 장점 때문에 운영에 자주 쓰이지만, 실패했을 때 추적이 가장 어려운 업무이기도 합니다. 스케줄이 비정상적으로 겹치거나, 콜드 스타트가 길어지거나, 외부 API가 느려지는 순간 작업은 조용히 실패하고 로그는 흩어집니다. 문제 정의는 단순합니다. 실행은 자동인데 책임은 누가 지는지 모호하고, 재시도는 비용을 올리며, 실패 알림은 늦게 오기 쉽습니다. 그래서 크론 작업은 기능 개발보다 운영 설계가 더 중요합니다. 실제로는 “실패했을 때 무엇을 보고, 무엇을 다시 실행할지”가 설계의 핵심입니다. 이 글은 서버리스 크론의 실패를 전제로 구조를 잡는 실무용 접근을 정리합니다. 특히 운영자가 처음 로그를 보는 순간부터 복구까지 걸리는 시간을 줄이는 데 초점을 둡니다. 알림이 왔을 때 누구나 같은 결론에 도달하도록, 로그와 상태 기준을 먼저 정해두는 전략입니다. 정상/비정상 기준선을 미리 합의해 두면, 장애 상황에서도 의사결정이 흔들리지 않습니다.

첫 번째 판단 기준은 작업의 ‘재시도 가능성’입니다. 같은 입력으로 다시 실행해도 안전한가, 외부 상태를 변경하는가, 중복 실행이 비용이나 데이터 손상을 만드는가를 먼저 분류해야 합니다. 두 번째는 ‘시간 민감도’입니다. 5분 지연이 허용되는지, 하루 안에만 끝나면 되는지에 따라 타임아웃과 경보 기준이 바뀝니다. 세 번째는 ‘의존성의 변동성’입니다. 외부 API, 배치 DB, 파일 스토리지처럼 느리거나 불안정한 의존성이 있는지 확인해야 합니다. 대부분의 장애 원인은 이 세 가지가 섞일 때 생깁니다. 예를 들어 재시도 불가능한 작업이 느린 외부 API를 호출하면, 시간 초과와 부분 실패가 동시에 발생하고 복구가 복잡해집니다. 따라서 원인을 추적하기 전에 작업의 성격을 분류해 운영 규칙을 먼저 정해두는 것이 중요합니다. 이 분류가 없으면 장애가 나도 “어디를 봐야 하는가”부터 다시 정의해야 합니다. 분류 결과는 표로 남겨 팀 공유 문서에 붙이면, 담당자가 바뀌어도 기준이 유지됩니다. 재시도 가능한 작업이라면 멱등성을 보장하는 키와 중복 제거 기준을 문서화해 두는 것이 안전합니다.

실행 절차는 단순하지만 순서를 지켜야 합니다. 1) 스케줄 트리거에서 실행 ID를 만들고 모든 로그에 포함합니다. 2) 작업 시작 시점에 입력 스냅샷과 목표 상태를 기록합니다. 3) 핵심 단계마다 상태 전이를 기록하고, 외부 호출에는 타임아웃과 서킷 브레이커를 적용합니다. 4) 성공/실패를 명확히 분리하고, 실패 시에는 재시도 정책(즉시, 지연, 수동)을 명시합니다. 5) 마지막으로 결과 요약을 저장해 대시보드와 알림이 같은 기준을 보도록 만듭니다. 이 과정에서 “정상 종료이지만 일부 작업만 실패” 같은 회색 상태를 없애는 것이 중요합니다. 크론 작업은 다 잘 되거나, 실패로 끝나거나 둘 중 하나여야 복구가 빠릅니다. 또한 상태 전이 로그에는 “다음 액션”을 기록해 운영자가 재실행 버튼만 눌러도 되는 수준으로 만들어야 합니다. 필요하면 실패 상태별로 자동 재실행 횟수를 다르게 두어 비용과 안정성을 동시에 관리합니다. 재시도 간격은 지수 백오프로 두되, 전체 실행 시간 상한을 넘기지 않게 타임박스를 둡니다.

운영 체크리스트와 주의사항은 결국 비용과 신뢰의 균형을 잡는 일입니다. 체크리스트는 다음을 최소 포함해야 합니다. 실행 간격 대비 평균 처리 시간, 최대 재시도 횟수, 알림 SLA(예: 10분 내), 실패 시 롤백 여부, 재실행 입력 재사용 여부, 외부 API 쿼터 소진 위험, 그리고 장기 로그 보관 기간입니다. 주의사항으로는 “중복 실행이 발생해도 안전한가”를 항상 다시 확인해야 합니다. 서버리스는 자동 확장이 장점이지만, 중복 실행은 곧 비용 폭증과 데이터 중복을 의미합니다. 또 하나는 알림 피로도입니다. 모든 실패를 즉시 알리기보다, 실패 유형에 따라 경보 채널을 분리해야 실제 사고 신호가 묻히지 않습니다. 마지막으로 주 1회는 실패 로그를 샘플링해 패턴을 찾는 루틴을 유지하면, 조용한 장애를 조기에 잡을 수 있습니다. 운영 문서에는 복구 순서를 한 페이지로 요약해, 신규 담당자도 같은 기준으로 대응하게 하는 것이 좋습니다. 이런 기본기만 갖추면 크론 작업은 “보이지 않는 실패”가 아니라 “관리 가능한 실패”가 됩니다. 주간 단위로 실패율과 재시도 비용을 리뷰하면, 과한 재시도나 알림 정책도 함께 최적화할 수 있습니다.