AI 검수 로직을 붙였더니 오히려 작업이 멈춘 이유

안녕하세요. 파이선생 AI 자동화랩의 파이선생입니다.

지금까지 블로그 포스팅부터 유튜브 쇼츠 영상까지 다양한 콘텐츠를 자동으로 만들어 내는 파이프라인을 구축해 왔습니다. 처음에는 스크립트가 알아서 글을 쓰고 이미지를 올리는 것만으로도 신기하고 기뻤지만, 횟수가 거듭될수록 예상치 못한 문제들이 터지기 시작했습니다. 자동화 코드가 과장된 광고성 문구를 쓰기도 하고, H1 태그를 남발하여 블로그 글 양식을 깨뜨리기도 했으며, 본문에 들어가야 할 이미지가 엑스박스로 누락되는 등 수많은 오류가 발생했죠.

그래서 저는 이 문제를 해결하기 위해 파이프라인 중간에 자동화 검수 스크립트 모듈을 투입하기로 결심했습니다.

[자동화 시스템의 검수 모니터링 체제] 끊임없이 발생하는 에러와 품질 저하를 막기 위해, 파이프라인을 철저히 통제하고 모니터링하는 새로운 자체 검증 로직의 투입을 결정했습니다.

---

기존 파이선생 캐릭터 기반 검수 콘셉트 이미지로, 한층 더 깐깐하고 엄격해진 검수 모듈들의 활동 무대(컨트롤 룸)를 시각화했습니다.

검수 로직만 붙이면 실수가 사라질 줄 알았습니다

제가 설계한 아이디어는 꽤 합리적으로 보였습니다. 코드가 글을 다 쓰면 곧바로 티스토리에 올리는 것이 아니라, 중간에 여러 유효성 검사 스크립트를 거치도록 파이프라인을 개선한 것이죠.

H1 태그가 남아있거나 본문 길이가 너무 짧으면 형식 검사 모듈이 차단하고, 프롬프트나 이미지 경로에 문제가 있으면 미디어 검증 로직이 경고를 보내며, 과도한 키워드 반복을 막아주는 구조를 짰습니다. 이 깐깐한 조건들을 거쳐서 모든 항목이 PASS를 받아야만 티스토리 발행 스크립트가 작동하도록 만들었습니다.

처음 이 시스템을 붙였을 때는 마음이 아주 든든했습니다. 기계적인 실수가 원천 차단될 테니 이제 안심하고 자동화를 돌려도 되겠다고 기대했으니까요.

검수 기준이 많아지니 오히려 작업이 멈춰버렸습니다

하지만 현실은 제 기대와 정반대로 흘러갔습니다. 엄격한 검수 스크립트들을 붙이고 났더니, 역설적이게도 자동화 작업이 완전히 멈춰버리는 현상이 발생한 것입니다.

가장 큰 원인은 늘어난 검수 기준이었습니다. "본문 안에 H1을 쓰지 말 것", "이미지 경로가 살아있는지 검사할 것", "기존 글을 덮어쓰는지 신규 글인지 Post ID를 확인할 것" 등등 지켜야 할 규칙이 너무나도 빡빡했습니다. 이 중 단 하나라도 어긋나면 상태가 PENDING이나 FAIL로 떨어졌고, 그러면 전체 파이프라인이 그대로 마비되어 버렸습니다.

[검수 체계를 강화하면 품질이 좋아질 것이라고 생각했다] 가혹한 기준을 세워 자동화 스크립트들의 실수를 원천 차단하려 했던 야심 찬 기획이, 역설적이게도 전체 파이프라인을 멈춰 세운 무한 대기 현상으로 이어졌습니다.

---

실제 검수 로직이 승인 조건을 충족하지 못해 publish가 차단된 터미널 화면입니다. 검수 시스템이 지나치게 엄격해지면서 QA_PENDING 상태가 해제되지 않았고, 결국 발행 파이프라인 전체가 정지했습니다. 이 경험을 통해 검증 단계는 차단자가 아니라 보조자여야 한다는 교훈을 얻었습니다.

검수 로직들이 너무 많은 것을 체크하려다 보니, 정작 가장 중요한 "빠르고 꾸준한 발행"이라는 자동화 본연의 목적이 무너져 내린 셈입니다. 작은 오류 하나를 잡기 위해 파이프라인 전체가 스톱되는 이 무한 루프 속에서 깊은 딜레마에 빠졌습니다.

자동 검수 로직은 허가자가 아니라 위험을 알리는 보조자입니다

이 뼈아픈 실패를 겪으며 한 가지 중요한 사실을 깨달았습니다. 바로 자동화 검수 스크립트는 최종 발행을 허가하는 '결정권자'가 아니라, 위험 신호를 미리 알려주는 '보조자'여야 한다는 것입니다.

그동안 저는 검수 로직이 PASS를 주면 자동으로 티스토리 발행까지 이어지도록 모든 권한을 위임했습니다. 그러나 시스템이 아무리 고도화되더라도 예상치 못한 예외 상황은 반드시 생깁니다. 이때 프로그램끼리 서로 룰을 지켰는지 충돌하며 파이프라인을 멈추게 두는 것이 아니라, 시스템은 단지 검증 리포트만 생성하고 대기해야 합니다.

결국 가장 결정적인 순간, 즉 "티스토리 실서버에 수정/발행 버튼을 누르는 작업"이나 "결제 비용이 발생하는 작업"과 같은 고위험 액션은 기계가 아닌 사람, 즉 제가 직접 판단하고 승인해야만 비로소 파이프라인이 안정적으로 돌아갈 수 있다는 것을 배웠습니다.

사람의 최종 승인(Human in the loop)을 도입하다

그래서 저는 이 난장판이 된 검수 구조를 통제하기 위해 파이프라인 마지막 단계에 최종 관리자 수동 승인 절차를 새롭게 도입했습니다.

이제 파이선생 AI 자동화랩의 모든 작업은 철저하게 분리됩니다. 기획, 조사, 집필, 이미지 생성, SEO 점검 등은 각각의 스크립트들이 담당하여 결과를 만들어 냅니다. 하지만 그 결과물들은 곧장 발행으로 이어지지 않습니다. 통합 모니터링 시스템이 모든 검증 결과의 dry-run 리포트를 취합한 뒤, 어떤 부분에 위험 요소가 있는지 일목요연하게 정리해 저에게 일일 보고를 올립니다.

그리고 제가 최종적으로 그 리포트를 확인하고 수동으로 승인(APPROVED) 코드를 주입했을 때에만, 비로소 티스토리에 글이 발행되는 구조로 전면 개편했습니다.

다음 포스팅부터는 이렇게 재편된 단계별 검증 스크립트들이 어떻게 유기적으로 움직여서 안전하고 훌륭한 글을 발행해 내는지, 그 구체적인 실전 코드와 작동 과정을 자세히 공유해 드리겠습니다. 감사합니다.