AI 자동화의 완료는 왜 API 응답이 아니라 실제 결과인가

AI 자동화에서 가장 위험한 성공은 실패가 아니라 ‘접수’를 ‘완료’로 착각하는 것이다. 요청이 시스템에 들어갔다는 사실과 사용자가 최종 결과를 볼 수 있다는 사실 사이에는 상태, 재시도, 권한, 렌더링, 실패가 남아 있다.

TL;DR

202 Accepted는 작업이 접수됐다는 뜻이지, 외부 세계의 결과가 만들어졌다는 뜻이 아니다.
자동화 제품은 accepted → queued → publishing → published/failed → verified 같은 상태를 분리해야 한다.
실제 실패는 다음 릴리스의 평가 케이스가 되고, 최종 결과의 증거는 제품의 신뢰 표면이 된다.
가장 작은 검증기는 URL이나 작업 ID를 받아 최종 결과를 확인하고, 실패 증거를 내보내는 도구다.

AI가 콘텐츠를 만들고 여러 외부 서비스를 호출하는 흐름이 빠르게 늘고 있다. 한 번의 API 호출로 끝나는 작업보다 큐, 비동기 처리, 검토, 재시도, 플랫폼별 제한을 거치는 작업이 많아진다.

이때 “API가 200을 반환했다”는 문장은 너무 약하다. 요청을 받았다는 뜻일 수는 있지만, 게시물이 공개됐는지, 올바른 계정에 올라갔는지, 본문과 이미지가 깨지지 않았는지까지 말해주지는 않는다.

자동화의 양이 늘수록 사람은 모든 결과를 직접 확인할 수 없다. 그래서 완료의 정의를 응답 코드가 아니라 관찰 가능한 결과로 옮겨야 한다.

GeekNews에 소개된 ANKK는 외부 AI 결과를 여러 SNS에 예약할 때 API 응답과 실제 발행 시점이 다르다는 문제에서 출발했다. 이 문제를 해결하려면 자동화의 상태를 한 덩어리의 success로 뭉개지 않아야 한다.

accepted → queued → publishing → published / failed → verified

각 상태는 서로 다른 질문에 답한다.

마지막 verified가 없으면 운영자는 성공을 추정할 뿐이다. 상태를 나누는 이유는 화면을 복잡하게 만들기 위해서가 아니라, 재시도할 지점과 멈출 지점을 구분하기 위해서다.

ANKK 사례의 핵심은 예약 발행 기능 자체가 아니다. 이미 많은 도구가 예약과 전송을 제공한다. 차별점은 실제 게시 상태를 추적하고, accepted와 published 사이의 간극을 운영 문제로 다룬다는 데 있다.

이 관점은 AI 에이전트에도 그대로 적용된다. 에이전트가 파일을 수정했다고 보고하는 것과, 테스트가 통과하고 배포된 페이지에서 사용자가 변경을 확인하는 것은 다른 사건이다. 외부 결과를 확인하지 않는 에이전트는 실행기는 될 수 있어도 운영 시스템은 되기 어렵다.

평가 주도 개발은 비결정적 출력과 검색·추론·도구 호출의 연쇄 실패를 사후 검수로만 다루지 않는다. 실제 오류를 평가 기준으로 만들고 지속적으로 검사한다.

상태 검증도 같은 방식으로 설계할 수 있다.

그러면 운영 로그는 단순한 사후 기록이 아니라 제품 품질을 올리는 데이터셋이 된다. 한 번의 실패가 다음 실행의 계약으로 바뀌는 순간, 자동화는 반복 작업을 줄이는 도구에서 학습하는 시스템으로 발전한다.

자동화 작업을 만들 때 “게시해줘”라고 쓰는 대신 다음처럼 쓴다.

지정한 페이지가 404 없이 열리고, 목록에 카드가 표시되며, 본문에 기대한 제목과 출처 링크가 존재할 때만 완료로 판정한다.

좋은 완료 계약에는 네 가지가 들어간다.

이 계약이 있으면 “작업을 실행했다”와 “작업이 끝났다”를 구분할 수 있다. 또한 자동화가 실패했을 때 원인을 추적할 수 있어 재시도와 롤백도 안전해진다.

가장 작은 verifier는 거창한 에이전트가 아니다.

먼저 콘텐츠 발행 하나에만 붙여도 된다. 일주일 동안 accepted 이후 실제 공개까지 걸린 시간, 거짓 성공의 수, 재시도 뒤 중복 결과의 수를 기록한다. 그 숫자가 다음 제품 개선의 우선순위를 알려준다.

이 구조는 배포, 결제 승인 후 영수증 생성, 데이터 변환, 이메일 전송에도 적용할 수 있다. 외부 세계에 영향을 주는 작업일수록 “응답을 받았다”보다 “결과를 관찰했다”가 강한 완료 기준이다.

모든 결과를 브라우저에서 다시 확인하는 방식은 비용과 지연을 늘린다. 내부 시스템이 강한 완료 보장을 제공하는 경우에는 중복 검증이 과할 수 있다.

따라서 모든 단계에 같은 검증을 붙이기보다 위험도에 따라 레인을 나누는 편이 낫다. 돈, 공개 콘텐츠, 삭제, 권한 변경처럼 되돌리기 어려운 결과는 독립 검증을 우선하고, 저위험 내부 작업은 가벼운 상태 확인으로 충분할 수 있다.

또한 verified가 있다고 해서 결과가 반드시 올바른 것은 아니다. 검증기는 기대한 제목·slug·상태를 확인할 뿐, 내용의 진실성까지 보장하지 않는다. 검증 범위와 검증기가 확인하지 못하는 영역도 함께 명시해야 한다.

AI 자동화의 다음 경쟁력은 더 많은 요청을 보내는 능력이 아니다. 요청이 실제 결과로 이어졌는지, 실패하면 어디에서 멈췄는지, 다음 실행에서 같은 실패를 막았는지를 설명하는 능력이다.

API 응답은 시작의 증거다. 제품의 신뢰는 최종 결과와 검증 기록에서 만들어진다. 다음 자동화를 설계할 때는 “무엇을 호출할까?”보다 먼저 “무엇이 실제로 끝났다고 말할 수 있을까?”를 정의해야 한다.