작업일지 사이트(laborverified.com)의 글은 밤마다 AI 에이전트가 그날 원자료를 읽고 쓴 뒤, 빌드와 배포까지 사람 없이 돈다. 회사를 그만두고 혼자 사업을 준비하면서 손을 뺀 자리다. 9월 23일 아침에 “이번에 잘 돌아갔는가?“라고 물어보니 전날 치 글이 사이트에 올라가지 못한 채였다.
에러 줄은 글만 가리켰다
배포 로그에 남은 줄은 [InvalidContentEntryDataError] guide → 2026-09-22 data does not match collection schema.였다. 이 사이트는 빌드(astro build) 때 글마다 frontmatter를 미리 정한 스키마에 대어 보고, 하나라도 안 맞으면 빌드 전체를 멈춘다.
이 줄이 알려주는 건 guide 묶음의 2026-09-22 글이 스키마와 안 맞는다는 데까지다. 어느 필드가 빠졌는지, 어느 값이 틀렸는지는 없다. 발행된 글 전부에서 slug 줄을 뽑아 slug가 없는 파일을 찾고, 스키마 파일을 열었다.
스키마는 먼저 바뀌어 있었다
스키마 파일(site/src/content.config.ts)에서 slug 칸의 정의는 이랬다.
z.string().regex(/^[a-z0-9]+(?:-[a-z0-9]+)*$/)뒤에 .optional()이 없다. 빠지면 빌드가 멈추는 필수 필드이고, 있어도 영문 소문자·숫자·하이픈 모양이 아니면 통과하지 못한다. 이 줄은 9월 21일 14시 37분 커밋에서 들어왔다.
글을 쓰는 쪽은 따라오지 않았다. 에이전트에게 주는 규칙 파일과 스킬 문서, 블로그 명령 파일을 slug로 검색했더니 글쓴이 규칙에는 slug를 쓰라는 단계가 없었다. 스키마는 사이트 저장소에서 필수로 바뀌었고 에이전트가 읽는 규칙은 그 전 모양 그대로였으니, 밤 배치가 9월 22일 글을 slug 없이 쓴 것은 규칙대로 한 일이었고 빌드는 그 글 하나 때문에 그날 배포 전체를 세웠다.
규칙 파일에 slug 단계를 넣었다
9월 23일 아침 커밋으로 에이전트 규칙에 “3.5단계: slug — 이 글의 URL”을 넣었다. 첫 문장은 “frontmatter에 slug 한 줄을 반드시 쓴다. 없으면 빌드가 죽는다”다. 9월 22일 글의 frontmatter 4행에는 지금 slug: find-which-command-needs-approval이 들어가 있다.
9월 23일 배포 로그는 Deployment complete!와 배포 기록: 23편으로 끝났다.
사이트 스키마에서 필드를 필수로 바꿨다면, 같은 날 그 frontmatter를 채우는 AI의 규칙 파일에도 그 필드와 “없으면 빌드가 멈춘다”를 적어 두세요.
9월 25일에 https://laborverified.com/guide/find-which-command-needs-approval/를 curl로 열었을 때 HTTP 200이 돌아왔다.