Blog system notes 3. 발행 전에는 queue를 나눠 봅니다

1편에서는 글쓰기 원본과 사이트 결과물을 분리했습니다. 2편에서는 검색 노출 작업이 코드와 문장 수정에서 끝나지 않고, 제출 기록과 재시도 queue까지 가야 운영으로 닫힌다고 정리했습니다.

그 다음에 남은 질문은 발행 직전의 판단이었습니다.

글이 준비됐는지, 사이트가 빌드되는지, 공개 사이트에 반영해도 되는지, 문제가 생기면 무엇을 되돌릴지까지 한 번에 묻기 시작하면 질문이 너무 커집니다. 그래서 발행 전 질문을 content queue, build queue, deploy queue로 나눴습니다.

이번 글은 자동 배포 시스템을 만든 기록이 아닙니다. 사용자가 raw diff, test log, build output을 모두 직접 해석하지 않아도 되도록, 기술 근거 앞에 쉬운 한글 설명을 붙인 운영 표면을 만든 기록입니다.

발행 전 질문은 생각보다 큽니다

처음에는 "발행해도 될까요"라는 질문이 하나처럼 보였습니다.

하지만 실제로는 여러 질문이 섞여 있었습니다. 글 4개가 들어왔는지, frontmatter가 맞는지, 이미지 경로가 살아 있는지, 관련 글 링크가 적절한지 확인해야 했습니다. 그 다음에는 테스트와 빌드가 통과하는지, generated state diff가 예상 범위인지 봐야 했습니다. 마지막으로 public site에 반영해도 되는지, rollback note가 있는지, owner decision이 필요한지도 따로 봐야 했습니다.

이 질문들을 한 문장으로 묶으면 사용자가 너무 많은 상태를 한 번에 받아야 합니다.

그래서 발행 전 판단을 세 줄로 나눴습니다. content queue는 글과 자산을 보고, build queue는 사이트가 깨지지 않는지 보고, deploy queue는 공개 반영 권한을 봅니다.

하나의 release queue로 묶으면 판단이 흐려졌습니다

처음에는 release queue라는 말이 편해 보였습니다.

하지만 이 표현은 너무 넓었습니다. content가 준비된 것과 build가 통과한 것과 public deploy를 해도 되는 것은 서로 다른 권한입니다. 글 폴더에 post가 들어온 것만으로 사이트 배포를 허가한 것이 아니고, npm run build가 통과했다고 해서 공개 URL 반영까지 자동으로 허가된 것도 아닙니다.

이 구분은 Peter Steinberger식 maintainer loop를 보면서 더 선명해졌습니다. 핵심은 AI worker를 더 많이 돌리는 것이 아니라, owner에게 올라오는 질문의 모양을 줄이는 데 있었습니다.

그래서 queue의 목적도 자동 실행이 아니라 판단 분리로 잡았습니다.

권한은 계단식으로 봅니다.

조회
-> 수정
-> 푸시
-> 머지
-> 배포 또는 외부 적용

한 단계의 허가는 다음 단계의 허가가 아닙니다. 이 원칙을 발행 흐름에 적용하면 build pass와 deploy approval을 분리해야 합니다.

content queue는 글과 자산을 봅니다

content queue는 글이 공개 글로 들어갈 기본 상태인지 보는 줄입니다.

여기서 중요한 것은 글의 문장 취향만이 아닙니다. frontmatter, series metadata, image path, related links, upstream publishing contract가 같이 맞아야 합니다. 이 줄이 막히면 build가 통과해도 독자에게 보여 줄 글로 보기는 어렵습니다.

예시는 이런 형태입니다.

Content queue

쉬운 설명:
- 글 4개가 사이트 글 폴더에 들어왔고, 공개 글로 필요한 기본 정보는 갖춘 상태입니다.
- 이미지 경로와 관련 글 링크도 확인했습니다.

상태:
- 4 posts added
- frontmatter valid
- image paths present
- related links checked

판정: pass

이렇게 쓰면 사용자는 frontmatter valid라는 기술 bullet을 먼저 해석하지 않아도 됩니다. 먼저 "공개 글로 필요한 기본 정보는 갖춘 상태"라는 판단을 읽고, 그 뒤에 근거를 확인할 수 있습니다.

build queue는 사이트가 깨지지 않는지 봅니다

build queue는 글이 들어간 뒤 사이트가 실제로 깨지지 않는지 확인하는 줄입니다.

여기서는 테스트와 빌드가 핵심입니다. 다만 테스트와 빌드가 통과해도 generated state diff가 생겼다면 사람이 한 번 봐야 할 수 있습니다. 특히 output/state 같은 파일은 source-of-truth가 아니라 파생 결과물이지만, downstream consumer가 읽는 표면일 수 있기 때문입니다.

예시는 이렇게 둡니다.

Build queue

쉬운 설명:
- 사이트가 깨지지 않고 빌드되는지 확인하는 줄입니다.
- 테스트와 빌드는 통과했고, 생성된 상태 파일 변경도 확인했습니다.

상태:
- npm test pass
- npm run build pass
- state regenerated
- output/state diff reviewed

판정: pass

이 queue가 하는 일은 "이제 배포해도 된다"가 아닙니다. "사이트가 깨지는 상태는 아닌 것으로 확인했다"에 가깝습니다.

그래서 build queue가 pass여도 deploy queue는 따로 남깁니다.

deploy queue는 공개 반영 권한을 봅니다

deploy queue는 public site에 반영해도 되는지 보는 줄입니다.

이 줄에서는 기술 통과 여부보다 권한과 책임이 중요합니다. target commit이 맞는지, rollback note가 있는지, public smoke가 필요한지, owner decision이 필요한지 봅니다.

예시는 이런 형태입니다.

Deploy queue

쉬운 설명:
- 이제 실제 공개 사이트에 올릴지 결정하는 줄입니다.
- 아직 rollback note가 없어서, 지금 바로 배포하기보다 rollback note를 먼저 남기는 편이 안전합니다.

상태:
- public deploy pending
- rollback note missing
- owner decision needed

판정: needs owner

추천:
- rollback note를 남긴 뒤 배포 결재를 받는 것을 추천합니다.

이 줄이 있으면 사용자의 선택이 선명해집니다.

배포를 결재할 수도 있고, 보류할 수도 있습니다. rollback note만 하나 제공하라고 할 수도 있고, 여러 대안 중 하나를 고를 수도 있습니다. 중요한 것은 raw status를 길게 읽고 의미를 추측하는 일이 줄어든다는 점입니다.

쉬운 설명을 먼저 두면 사용자의 일이 줄어듭니다

이 queue 형식에서 가장 중요한 규칙은 기술 bullet보다 쉬운 한글 설명을 먼저 두는 것입니다.

나쁜 요약은 이런 모양입니다.

Build queue:
- npm test pass
- npm run build pass
- state regenerated

이 문장은 틀리지는 않았습니다. 하지만 사용자는 이 bullet이 무엇을 뜻하는지, 무엇을 결정해야 하는지 다시 해석해야 합니다.

그래서 좋은 요약은 먼저 뜻을 말합니다.

Build queue

쉬운 설명:
- 사이트가 실제로 깨지지 않고 빌드되는지 확인하는 줄입니다.
- 테스트와 빌드는 통과했지만, 생성된 상태 파일 변경은 사람이 한 번 봐야 합니다.

상태:
- npm test pass
- npm run build pass
- state regenerated
- output/state diff review required

이 차이는 작아 보이지만 운영 감각은 크게 달라집니다. 기술 evidence는 그대로 두되, 사용자가 먼저 읽는 문장은 decision-ready 상태가 됩니다.

queue는 자동 배포가 아니라 권한 분리였습니다

이 방식은 자동화를 더 세게 거는 장치가 아닙니다.

오히려 자동화가 할 수 있는 일과 사람이 결정해야 하는 일을 분리하는 장치입니다. content queue와 build queue는 agent가 현재 권한 안에서 확인할 수 있는 경우가 많습니다. 하지만 deploy queue는 public site에 영향을 주므로 별도 결재가 필요할 수 있습니다.

그래서 queue의 판정도 단순한 성공과 실패로만 두지 않았습니다.

판정	의미
pass	현재 줄의 조건은 통과했습니다
warn	진행은 가능하지만 주의나 후속 보완이 필요합니다
needs owner	사람의 결정, 권한, missing input이 필요합니다
block	계약이나 검증이 깨져 다음 단계로 갈 수 없습니다
not applicable	이번 작업에는 해당 queue가 필요하지 않습니다

이 표가 있으면 사용자는 무엇을 해야 하는지 더 빨리 볼 수 있습니다.

needs owner는 실패가 아닙니다. 사람이 결정해야 하는 지점이 드러난 상태입니다. 오히려 이 상태를 숨기지 않는 것이 안전합니다.

다음 글에서는 글쓰기 기준을 닫습니다

이제 공개 순서에서 남은 것은 글쓰기 기준입니다.

1편에서는 원본과 결과물을 나눴습니다. 2편에서는 검색 제출과 ledger를 다뤘습니다. 3편에서는 발행 직전 판단을 content, build, deploy queue로 나눴습니다.

이 세 가지가 있으면 마지막 질문이 남습니다. 실제 글은 어떤 기준으로 고칠 것인가.

그래서 4편에서는 두 가지 글쓰기 기준을 다룹니다. AI 시대 감각을 해석하는 성찰형 에세이와, 프로젝트 상태와 검증을 설명하는 정보전달형 기록을 나누고, 제목과 소제목의 기호 규칙까지 하네스로 고정한 이유를 정리합니다.

발행 시스템은 글을 사이트에 올리는 장치만이 아닙니다. 원본을 지키고, 검색 제출을 기록하고, 발행 전 판단을 작게 나누고, 마지막에는 글 자체의 독자 약속까지 고정하는 일에 가깝습니다.