CI가 초록색이어도 글이 공개된 것은 아니다

새 study 글을 쓰고, 포맷을 맞추고, lint와 build를 통과시키고, GitHub Actions까지 초록색으로 끝났다. 여기까지만 보면 발행은 성공한 것처럼 보인다. 그런데 실제 글 URL은 404였다.

이 지점이 중요했다. CI가 통과했다는 말은 repository와 build pipeline이 깨지지 않았다는 뜻이지, 사용자가 읽는 route가 실제로 글을 돌려준다는 뜻은 아니었다. 오케이징은 이 차이를 운영 기준으로 분리해야 했다.

이번 경우 새 글 MDX는 main에 있었고 deploy도 끝났다. 하지만 study route는 backend article API가 가진 publish 상태와 맞물려 있었다. 그래서 MDX 파일만 추가되어서는 충분하지 않았다. backend DB에 해당 글이 publish 상태로 들어가야 public API와 canonical page가 같이 살아난다.

결국 복구는 단순했다. 새 Day 7 글 두 개를 pnpm mdx:ingest --write-db --publish 경로로 backend DB에 반영하고, 그 다음 API와 페이지를 다시 읽었다. 그제야 route readback이 통과했다.

이 순서에서 마지막 세 단계가 빠지면, GitHub Actions가 성공해도 실제 독자는 글을 못 읽을 수 있다.

예전에는 "build 성공"이 꽤 강한 신호였다. 정적 페이지 중심이라면 그럴 수 있다. 하지만 SEOJing은 이제 콘텐츠, Worker, backend article API, public route가 같이 움직인다. 그러면 검증도 하나의 초록불로 묶으면 안 된다.

오케이징 입장에서는 이 표가 포스트 발행 workflow의 checklist가 된다. 어느 경계가 실패했는지 알아야 다음 행동도 달라진다. build가 깨졌으면 MDX나 코드 문제고, deploy가 실패했으면 Worker나 Cloudflare 문제고, API readback만 실패하면 ingest 문제일 가능성이 높다.

이번 dual-study workflow는 반복 trace가 쌓였다. 하지만 trace가 늘었다는 이유만으로 더 과감하게 자동화하면 안 된다. 오히려 Day 6에는 Worker size limit이 있었고, Day 7에는 backend ingest 누락으로 404가 났다. 반복되고 있다는 사실보다 더 중요한 것은 실패 모양이 구체화되고 있다는 점이다.

그래서 다음 단계는 모델 학습이나 더 큰 자율성이 아니다. 먼저 publish checklist와 regression eval을 만들어야 한다.

이 정도가 되어야 "발행했다"고 말할 수 있다. 오케이징의 Hermes Report도 같은 기준을 따라야 한다. commit과 CI만 보고 끝내면, 실제 공개 상태를 과장하게 된다.

이 사건은 작은 배포 장애처럼 보이지만, 오케이징의 진화 그래프에서는 꽤 명확한 노드다.

이 노드는 "CI가 통과했다"와 "사용자가 읽을 수 있다"를 분리한다. 개인 AI 운영체계가 실제 작업을 맡으려면 이런 경계를 계속 세분화해야 한다. 초록색 로그 하나에 기대는 대신, 사용자가 받는 결과물의 경계까지 읽어야 한다.

오늘의 결론은 단순하다. 오케이징은 글을 쓸 수 있게 된 것이 아니라, 글이 정말 공개됐는지 의심하고 확인하는 쪽으로 조금 더 성숙했다.