AI 에이전트 정기 작업, ‘성공’인데 결과가 없다면?

핵심 요약

• 스케줄러 health는 실행기가 살아 있는지에 관한 신호이지, 특정 업무 결과가 만들어졌다는 증거는 아닙니다.
• run/attempt 성공은 한 번의 실행이 끝났다는 뜻입니다. 하지만 대기열, 잘못된 입력, 후속 전달 실패까지 대신 설명해 주지는 않습니다.
• business receipt는 초안 ID, 검증된 리포트 URL, 명시적 skip 사유처럼 다른 사람이 다시 확인할 수 있는 업무 결과입니다.
• 읽기 전용 작업은 대상 상태를 확인한 뒤 최대 한 번 보충 실행을 검토할 수 있습니다. 발행·권한 변경·결제처럼 외부에 흔적을 남기는 작업은 결과가 불명확하면 사람에게 넘겨야 합니다.

‘성공’ 로그만으로는 왜 부족할까요?

정기 자동화는 보통 세 가지 사건을 지나갑니다. 먼저 정해진 시각에 slot이 열리고, 실행기가 작업을 시작합니다. 그다음 run 또는 attempt가 끝납니다. 마지막으로 독자가 읽을 초안, 팀이 보는 리포트, 승인된 변경 기록처럼 실제 업무 결과가 남습니다.

이 흐름을 하나의 성공 표시로 묶으면 문제가 생깁니다. 예를 들어 GitHub Actions의 schedule은 workflow를 시작시키는 트리거 정의입니다. n8n은 오류 처리와 재시도 흐름을 별도로 다루고, 동시성 제한으로 실행이 대기할 수도 있습니다. Airflow의 health check 역시 구성 요소가 응답하는지 확인하는 도구입니다. 어느 하나도 특정 downstream 결과물이 존재한다는 보편적 보장은 아닙니다.

누락을 잡는 3층 판정표

표의 핵심은 도구를 비교하는 데 있지 않습니다. 어떤 실행기를 쓰든 업무 완료에 필요한 증거가 무엇인지를 slot마다 미리 정하는 데 있습니다. 이 기준이 없으면 장애가 났을 때 로그를 더 많이 보는 데 시간만 쓰고, 중복 발행이나 중복 변경을 부를 수 있습니다.

FLOWIT식 6칸 business receipt 카드

각 정기 작업에 아래 여섯 칸을 남겨 두면, 누락을 발견했을 때 담당자가 같은 순서로 판단할 수 있습니다. 카드 자체는 특정 플랫폼의 기능이 아니라 운영 기록 형식입니다.

1. 예정 slot·owner: “매일 09:00 KST 리포트”처럼 시각, 시간대, 책임자를 적습니다.
2. 입력 기준: 어느 기간의 데이터, 어떤 승인된 브리프, 어떤 버전을 쓰는지 적습니다. 입력이 없으면 실패가 아니라 명시적 skip receipt가 될 수 있습니다.
3. Health: 스케줄러·큐·필수 연결의 관측 상태를 기록합니다. health가 좋아도 다음 칸을 건너뛰지 않습니다.
4. Run/attempt ID: slot과 실행 시도를 연결하는 식별자, 시작·종료 시각, 오류 유형을 남깁니다.
5. Receipt: 생성된 초안 ID, 검증된 파일 경로, 전송 확인, 또는 조건 미충족에 따른 skip 사유를 남깁니다.
6. Idempotency·recovery: 같은 slot을 다시 실행해도 되는지, 대상 상태를 어디서 확인하는지, 사람 전환 조건이 무엇인지 적습니다.

신뢰성은 “자동으로 많이 재시도하는 것”이 아니라, 같은 일을 두 번 하지 않으면서 누락을 설명할 수 있는 것에 가깝습니다. 따라서 idempotency key나 대상 상태 조회가 없다면 보충 실행은 기본값이 아니라 예외로 두는 편이 낫습니다.

예시: 매일 콘텐츠 초안 slot에서 결과가 없을 때

가령 매일 하나의 콘텐츠 초안 패키지를 준비하는 작업을 생각해 보겠습니다. 09:00 slot의 입력은 “승인된 편집 브리프 1개”, receipt는 “날짜별 폴더의 article.html·metadata.json·이미지 3개·QC 파일”로 정합니다. 이때 스케줄러가 정상이고 run이 성공이어도, 패키지 파일이 없으면 완료로 처리하지 않습니다.

여기서 실패 조건도 구체적으로 정해야 합니다. 브리프는 있는데 이미지가 두 개뿐이거나, 메타데이터의 slug가 비어 있거나, 출처 링크를 검증할 수 없다면 receipt는 불완전합니다. 이 경우 읽기 전용 보완으로 해결되는지 확인할 수 있지만, 이미 외부 시스템에 초안을 만들었을 가능성이 있으면 먼저 대상 상태를 조회해야 합니다.

보충 실행·보류·사람 전환을 나누는 결정표

비용·권한·운영 관점에서 카드가 필요한 이유

정기 작업의 비용은 모델 호출 비용만이 아닙니다. 중복된 콘텐츠 초안, 두 번 실행된 변경, 누락 여부를 사람이 다시 조사하는 시간도 비용입니다. receipt를 먼저 정의하면 “무엇을 만들었는지”와 “누가 다시 확인할 수 있는지”가 분명해져, 조사 범위를 줄일 수 있습니다.

권한이 큰 작업일수록 기준은 더 엄격해야 합니다. 읽기 전용 수집은 결과 파일이 없을 때 비교적 안전하게 다시 시도할 여지가 있지만, 권한 변경이나 외부 발행은 동일한 요청이 두 번 적용될 수 있습니다. 이런 작업은 요청 식별자와 대상의 현재 상태를 함께 보관하고, 불명확하면 사람이 마지막 결정을 맡는 구조가 신뢰성을 높입니다.

마감 전에 쓰는 slot 점검표

• 오늘의 각 slot에 예정 시각, 시간대, owner가 적혀 있나요?
• 입력의 유효 기간과 승인 상태를 확인했나요?
• health, run/attempt, receipt를 서로 다른 칸에서 확인했나요?
• receipt가 URL·ID·파일 검증·명시적 skip 사유처럼 재확인 가능한 형태인가요?
• 보충 실행 전 대상 상태와 idempotency 규칙을 확인했나요?
• 외부 쓰기 결과가 불명확할 때 담당자에게 넘길 증거 묶음이 준비되어 있나요?

마감 감사에서 receipt가 없다면, 원인을 trigger → queue → tool → write → verification 순서로 분류해 보세요. 이 순서는 누락을 한 번에 해결하는 만능 절차가 아니라, 관측 신호와 업무 결과를 섞지 않기 위한 조사 지도입니다.

자주 묻는 질문

스케줄러가 healthy이면 정기 작업은 성공한 것 아닌가요?

아닙니다. healthy 상태는 구성 요소가 응답한다는 유용한 신호이지만, 특정 slot의 실행과 최종 결과물을 대신 증명하지는 않습니다. run과 receipt를 별도로 확인해 주세요.

모든 작업에 idempotency key가 꼭 필요한가요?

모든 읽기 작업에 같은 방식으로 필요하지는 않습니다. 다만 동일 요청이 두 번 적용되면 문제가 되는 발행·변경·전송 작업이라면, 중복을 판단할 수 있는 요청 식별자나 대상 상태 확인 규칙을 설계하는 편이 안전합니다.

결과 파일이 없으면 무조건 재실행하면 되나요?

먼저 그 작업이 외부에 흔적을 남겼을 가능성이 있는지 확인해야 합니다. 읽기 전용 작업은 조건이 맞으면 한 번의 보충 실행을 검토할 수 있지만, 쓰기 결과가 불명확하면 대상 상태를 조사하고 사람에게 넘겨야 합니다.

skip도 receipt로 인정할 수 있나요?

가능합니다. 다만 “입력이 없음”, “승인 브리프가 없음”처럼 조건과 확인 시각, 확인 범위가 분명해야 합니다. 아무 기록 없이 결과만 없는 상태와는 다릅니다.

참고 자료

• GitHub Actions 공식 문서 — schedule 이벤트: schedule이 workflow를 시작시키는 트리거로 정의되는 방식을 확인할 수 있습니다.
• n8n 공식 문서 — 오류 처리: 오류 workflow와 재시도 처리를 실행 결과와 분리해 설계하는 데 참고할 수 있습니다.
• n8n 공식 문서 — 동시성 제어: 실행이 대기할 수 있는 운영 조건을 확인할 수 있습니다.
• Apache Airflow 공식 문서 — health status: 구성 요소 health 확인이 무엇을 보여 주는지 살펴볼 수 있습니다.