status=success인데 게시가 안 됐다 — false-green 잡는 법

자동화 대시보드는 온통 초록불인데, 막상 올라갔어야 할 글이 없던 적 없나요? 로그엔 분명 status=success라고 찍혀 있어요. 저도 1분마다 도는 게시 워크플로우를 붙여 봤더니 며칠간 조용히 아무것도 안 올라가 있었어요.

성공이라는 거짓말

이런 걸 false-green이라고 불러요. 실행은 끝났고 상태값은 성공인데, 실제 결과물은 없는 상태요. AI 자동화에서 특히 자주 나와요. 모델을 부르는 노드, 결과를 어딘가로 보내는 노드가 줄줄이 이어져 있으면, 중간 한 곳이 조용히 헛돌아도 마지막 상태는 성공으로 남거든요.

원인을 뜯어 보니 대부분 두 가지였어요. 하나는 HTTP 200만 보고 성공으로 친 경우예요. 서버가 요청은 받았지만 게시를 안 했을 수 있는데, 200이라는 응답 코드 하나로 넘어간 거죠. 다른 하나는 노드가 실행됐다는 사실만 확인한 경우고요.

• ✓실행됨
• ✓응답 200
• ✓상태 success — 셋 다여도 게시는 안 됐을 수 있어요

surface check: 결과가 나온 자리를 다시 본다

핵심은 간단해요. 상태값 말고, 결과물이 실제로 나와 있어야 할 자리를 다시 조회하는 단계를 붙이는 거예요. 게시했으면 그 게시물을, 저장했으면 그 레코드를 다시 읽어 오는 거죠.

제가 쓰는 방식은 3단계예요.

게시 요청→30초~1분 대기→게시된 자리 재조회 후 없으면 error 강제

먼저 게시 요청을 보내요. 그다음 30초에서 1분쯤 뜸을 들여요. 반영에 시간이 걸리는 서비스가 많아서, 바로 조회하면 아직 없다고 나오거든요. 마지막으로 게시됐어야 할 페이지나 API를 다시 조회해서, 방금 그 항목이 실제로 있는지 확인해요. 없으면 워크플로우를 일부러 error로 떨어뜨리고요.

이 마지막 한 줄이 중요해요. 많은 자동화 도구가 수동 실행이나 조건 실패로는 에러 알림을 안 보내요. success로 조용히 지나가죠. 그래서 재조회 결과가 비면 알림 노드가 반드시 울리도록 실패를 직접 만들어 줘야 해요.

붙여 보고 나서

라이프케어로그에서 플랜엘(plan-l) 같은 서비스를 혼자 운영하다 보면 이런 게시·수집 자동화가 여럿이에요. surface check를 붙여 보니, 조용히 실패하던 게 그날 바로 알림으로 잡히더라고요. 초록불을 세는 대신 결과물이 있는 자리를 직접 보게 된 거죠.

자동화를 믿는 기준을 상태값에서 실제 결과물로 옮겨 보세요. 대시보드는 거짓말을 해도, 결과가 나와야 할 자리는 거짓말을 못 하니까요.