「나중에 사람이 한다」고 적어둔 단계는 아무도 안 한다

워크플로가 초록불인데 결과물이 없는 상황을 겪어본 적이 있다면, 아마 나처럼 로그부터 뒤졌을 것이다. 8/3에 블로그를 보니 마지막 글이 8/2였다. 자동 발행 워크플로는 그날 아침에도 돌았고 결과는 **「성공」**이었다. 실패한 게 아니라 할 일이 없어서 성공한 것이었다 — 소재 큐가 비어 있었다.

큐를 채우는 것도 자동화해뒀다고 생각했다. content/queue/README.md 마지막 줄에 이렇게 적혀 있었다.

"GitHub Actions 는 클라우드에서 돌아 볼트를 볼 수 없기 때문에, 자동으로 채워지지 않는다 — 이건 의도된 설계다."

벽은 처음부터 없었다

여기서 "구조상 안 되는 거였네"로 끝낼 수 있었다. 7/30에 내가 직접 적은 문장이니 의심할 이유도 없었다.

확인해보니 볼트는 이미 GitHub private 저장소에 올라가 있었다. 마크다운 162개, 수익화 문서와 클라이언트 문서까지 전부. 자산 파일(pptx·이미지·영상)만 .gitignore 로 빠져 있어서 저장소 크기가 22MB밖에 안 됐다.

"Actions 가 볼트를 못 본다" 는 벽은 없었다. 문장을 쓴 시점엔 참이었는지 모르지만, 확인하지 않은 채 3일을 사실로 굴렸다.

여기서 한 번 더 헛디뎠다. git ls-files | grep 수익화 를 돌렸더니 0건이 나와서 "수익화 폴더는 추적 안 하나 보다" 하고 넘어갈 뻔했다. git 은 한글 파일명을 8진수로 escape 해서 출력한다(\354\210\230...). 리터럴 한글로 grep 하면 절대 안 맞는다. 다시 물었더니 5건이었다.

git ls-files -z | tr '\0' '\n' | grep 수익화

도구가 0을 답했다는 것과 실제로 0개라는 것은 다른 사실이다.

벽을 치웠는데 그 너머에 길이 없었다

전제가 깨졌으니 다음 수는 명백해 보였다. Actions 에서 볼트 저장소를 같이 checkout 하면 소재를 자동으로 뽑을 수 있다.

그 전에 실제로 발행된 글의 원자료를 봤다. 큐 파일은 발행되면서 지워지므로 git 이력에서 꺼내야 했다. 8/2 글의 원자료는 47줄이었고 frontmatter 출처가 이랬다.

source: "2026-07-30 블로그 도메인 확인 작업 (실시간)"

내용은 whois 로 도메인 5개를 확인했는데 전부 「등록됨」이 나왔고, 원문을 열어보니 도메인 등록 정보가 아니라 IANA 의 TLD 정보를 답하고 있었다는 이야기였다. RDAP 로 다시 물으니 결과가 정반대였다.

그 내용은 어디에도 없다. 커밋 메시지엔 "도메인 확인"까지만 남고, 볼트 작업로그엔 결론만 남는다. 판단이 갈린 대목 — "처음엔 다 등록된 줄 알았다" — 은 그 세션 대화 안에만 있었다.

볼트를 checkout 해도 이 소재는 안 나온다. 벽은 치웠는데 그 너머에 길이 없었다.

적립하는 자리를 옮겼다

병목이 「볼트 접근」이 아니라 **「세션에서 있었던 판단이 어디에도 안 남는 것」**이었다. 그러면 적립하는 자리도 달라진다. 나중에 긁어오는 게 아니라 겪는 그 자리여야 한다.

• checkpoint 스킬에 2단계(소재 적립)를 넣었다. 작업 구간이 마무리될 때마다 ① 실제로 일어난 일 ② 판단이 갈린 지점 ③ 그래서 뭘 바꿨나 가 다 있으면 큐에 적고 푸시한다. 셋 중 하나라도 비면 적지 않는다.
• 워크플로에 「큐 잔량 점검」을 붙였다. 2개 이하로 떨어지면 GitHub 이슈를 열고, 회복되면 자동으로 닫는다. 성공으로 끝나는 침묵을 메우는 게 목적이다.
• 낡은 문장 세 곳을 취소선으로 남기고 정정했다. 지우면 "왜 그렇게 정했더라" 에 답할 수 없어서 같은 판단이 되살아난다.

담당이 「사람」이면 담당이 없는 것이다

원래 문장은 "사람이 있는 세션에서 배치로 채운다 — 의도된 설계다" 였다. 설계로서 틀린 말은 아니다. 그런데 그 「사람이 있는 세션」이 언제인지가 아무 데도 안 적혀 있었다.

자동화의 반대말은 수동이 아니라 아무도 안 함에 가깝다. 붙일 자리를 정하지 않은 수동 단계는, 문서에 아무리 정확하게 적어놔도 실행되지 않는다.