자동화가 성공했다고 믿기 전에 확인할 한 가지

API 응답이 정상이어도 자동화가 완료된 것은 아닙니다. 요청 방식, 응답의 의미, 외부 상태를 분리해 확인하는 완료 증명 프레임을 실제 자동화 실패 사례로 정리했습니다.

자동화 작업에서 가장 위험한 순간은 오류가 날 때가 아닙니다. 오류 없이 끝났다고 믿는 순간입니다. 쿠팡 파트너스 상품을 Threads에 올리는 자동화를 만들다가, 겉으로는 정상처럼 보이는데 결국은 실패했던 기록을 공유하려고 합니다.

많은 분들이 AI를 사용하면서 업무적으로나 일상생활에서 자동화를 하는 시도를 이것저것 하고 있죠. 저도 AI를 사용하면서 구독료 정도는 벌어서 써야되지 않을까 라는 생각이 들어서 바이브 코딩으로 할 수 있는 것들을 찾다가 Threads에 올릴 쿠팡 파트너스 아이템을 자동으로 올리는 방식을 고민해봤습니다. (여기저기서 한다는 사람도 많았고요)

코드는 정상인데 게시물이 없다

게시글을 만드는 API를 호출했고, 응답도 JSON으로 돌아왔습니다. 쉘 스크립트도 에러 코드 없이 끝났습니다. 처음에는 "게시됐겠네"라고 판단했습니다.

하지만 실제로는 게시가 하나도 되지 않았습니다.

원인은 심플했는데요. curl 호출에 붙어 있던 -G 옵션이었습니다. 이 옵션은 요청을 GET(서버에서 데이터를 조회만 하는 방식)으로 보냅니다. 제가 기대한 것은 Threads API의 POST(서버에 새 데이터를 생성하는 방식) 요청, 즉 "게시물 생성"이었습니다. 그런데 실제로는 GET 요청이 되어 "기존 게시물 목록 조회"가 실행됐습니다.

응답에는 기존 게시물 데이터가 들어 있었습니다. JSON도 정상이고 HTTP 오류도 없었습니다. "이정도면 자동화가 된건가?" 다만 제가 원한 작업을 하지 않았을 뿐입니다.

이후 자동화의 성공 여부를 세 단계로 나눠 보기 시작했습니다.

1단계 — 의도한 방식인지

자동화에서는 "어떤 주소를 호출했는가"만 보면 부족합니다. 메서드, 헤더, 본문, 인증 방식까지 함께 봐야 합니다.

같은 주소라도 GET은 조회이고 POST는 생성일 수 있습니다. PATCH는 일부 수정이고 PUT은 전체 교체일 수 있습니다. 개발 중에 주소만 맞다고 안심하면, 시스템은 조용히 다른 일을 하고도 정상 응답을 돌려줄 수 있습니다. (AI의 응답을 무조건적으로 믿으면 안되는 이유입니다)

특히 curl은 짧은 옵션 하나가 요청의 의미를 바꿉니다. -G처럼 쿼리스트링을 붙이는 옵션은 편하지만, POST 본문을 보내야 하는 API에 들어가면 작업을 전혀 다르게 만들 수 있습니다.

그래서 자동화 코드에는 "성공 요청"이 아니라 "의도한 요청"을 확인하는 로그가 필요합니다.

HTTP 메서드는 무엇이었는가
요청 본문에는 필요한 값이 실제로 들어갔는가
인증 헤더는 정상적으로 전달됐는가
API 문서가 요구한 호출 순서를 지켰는가

이 네 가지는 에러가 난 뒤에 보는 디버깅 항목이 아닙니다. 처음부터 성공 조건에 넣어야 합니다.

2단계 — 응답이 전부?

HTTP 200이나 201은 서버가 요청을 처리했다는 뜻일 뿐, 원하는 결과가 생겼다는 보증은 아닙니다.

Threads 사례에서는 응답 JSON이 있었습니다. 문제는 그 JSON의 의미였습니다. "새 게시물 ID"가 아니라 "기존 게시물 목록"이었습니다. 응답이 비어 있지 않았기 때문에 더 쉽게 속았습니다.

자동화를 만들 때는 응답에서 반드시 확인할 값을 먼저 정하는 편이 좋습니다.

게시 자동화라면 새 게시물 ID가 있어야 합니다.
상품 등록이라면 새 레코드 ID와 공개 상태가 있어야 합니다.
결제라면 결제 승인 번호와 최종 상태가 있어야 합니다.
파일 업로드라면 저장된 파일 URL과 접근 가능 여부가 있어야 합니다.

"응답이 왔다"는 검증이 아니라, "응답 안에 성공을 증명하는 값이 있다"는 검증으로 바뀌어야 합니다.

쿠팡 상품 등록 흐름도 같은 기준으로 확인합니다. 등록 API가 레코드 ID를 돌려주더라도 끝이 아닙니다. Airtable에서 해당 레코드를 다시 읽고, 상품명·가격·제휴 링크·이미지 URL·공개 여부가 맞는지 확인합니다. (저는 제가 등록하려는 상품을 Airtable에 정리해놓고 있습니다) 이어서 실제 공개 페이지에서 그 상품과 이미지가 렌더링되는지 봅니다. 등록 요청 한 번으로는 부족합니다. 저장소와 소비자 화면은 별개의 상태이기 때문입니다.

3단계 — 외부에 남은 결과

자동화의 완료는 호출한 쪽이 아니라, 바뀐 대상이 있어야 합니다.

게시 API를 호출했다면 실제 계정의 게시물 목록에서 확인합니다.
데이터베이스를 수정했다면 해당 레코드를 다시 조회합니다.
공개 사이트를 갱신했다면 브라우저가 읽는 페이지에서 확인합니다.
이미지 파일을 올렸다면 파일 URL의 응답과 화면상 구성을 함께 확인합니다.
메일을 보냈다면 발송 요청이 아니라 발신함 또는 수신 결과를 확인합니다.

여기서 중요한 점은 "읽기"가 원래 작업과 다른 관점이어야 한다는 것입니다. 같은 API의 응답만 다시 보면 같은 오해를 반복할 수 있습니다.

Threads 게시라면 생성 API 응답 뒤에 게시물 조회 API를 확인합니다. 상품 등록이라면 Airtable 레코드 조회 뒤에 공개 웹페이지를 확인합니다. 이미지라면 파일 크기나 200 응답만 보지 않고 실제 픽셀을 확인합니다. 정사각형 WebP가 만들어졌다고 해서 카드에 쓸 만한 상품 이미지라는 뜻은 아닙니다. 추천 상품이나 가격 영역이 같이 잘렸을 수도 있습니다.

완료를 판단하는 최소 프레임

자동화를 새로 만들거나 수정할 때는 아래 네 문장을 채워보면 됩니다.

무엇을 바꾸려는가? 예: Threads에 새 게시물을 만들거나, 상품을 공개 목록에 추가한다.
성공을 증명하는 식별자는 무엇인가? 예: 게시물 ID, 레코드 ID, 주문 번호, 공개 URL.
그 식별자를 어디에서 다시 읽을 수 있는가? 예: 조회 API, 데이터베이스, 관리자 화면, 실제 서비스 화면.
사용자가 보는 최종 상태는 무엇인가? 예: 게시물이 계정 타임라인에 보이는가, 상품이 공개 사이트에 표시되는가.

이 네 번째 질문이 빠지면 자동화는 내부적으로만 성공할 수 있습니다. 시스템은 값을 저장했는데 캐시 때문에 사이트에는 안 보일 수 있고, 데이터는 갱신됐는데 이미지가 잘못 잘려 있을 수도 있습니다. 사용자가 기대한 완료 상태와 시스템의 내부 상태가 다를 수 있다는 뜻입니다.

"실행"보다 "완료 증명"이 어렵다

자동화를 만들다 보면 요청을 보내는 부분에 가장 많은 시간을 씁니다. API 키를 연결하고, 인증을 처리하고, 데이터 형식을 맞추고, 스케줄러를 붙입니다. 하지만 운영에서 더 오래 남는 문제는 대개 그다음에 생깁니다.

"실행됐다"와 "완료됐다"는 다릅니다.

앞으로는 자동화가 성공했다는 보고를 받을 때도 두 가지를 구분해서 보려고 합니다. 첫째는 요청이 정상 실행됐다는 로그입니다. 둘째는 외부 상태가 실제로 바뀌었다는 증거입니다. 둘 중 하나만 있으면 아직 완료라고 부르기 어렵습니다.

FAQ

Q1. HTTP 200이면 성공 아닌가요?
아닙니다. 서버가 요청을 처리했다는 뜻일 뿐입니다. 조회가 실행됐는데 생성이 실행됐다고 착각하는 경우도 200 응답으로 나타날 수 있습니다.

Q2. POST 요청인데 왜 다른 동작을 하나요?
라이브러리 옵션, 프록시, 리다이렉트, 잘못된 헤더 또는 스크립트 구현 때문에 실제 전송 방식이 달라질 수 있습니다. 요청 로그에서 메서드와 본문을 확인해야 합니다.

Q3. API 응답만 검증하면 안 되나요?
응답은 첫 번째 검증으로는 충분하지만 마지막 검증으로는 부족합니다. 변경된 대상에서 다시 읽고, 가능하면 사용자가 보는 화면까지 확인해야 합니다.

Q4. 모든 자동화에 화면 검증이 필요한가요?
항상 브라우저 화면이 필요한 것은 아닙니다. 다만 결과가 사용자 화면에 노출되는 작업이라면, API 재조회와 렌더링 결과를 분리해 확인하는 편이 안전합니다.

Q5. 검증 단계를 추가하면 자동화가 느려지지 않나요?
검증 단계가 추가되므로 조금 느려질 수 있습니다. 그러나 잘못된 게시, 중복 발송, 깨진 상품 카드처럼 나중에 더 큰 비용이 드는 문제를 줄일 수 있습니다.