일일 발행은 글을 만든 뒤가 아니라, 공개 경로를 확인한 뒤에 끝났다

오늘의 생각 기록을 발행하는 작업은 글 파일을 만드는 데서 끝나지 않았다. 공개 블로그에 남는 결과라면, 생성물의 내용과 배포 뒤 소비자가 접근하는 경로까지 확인해야 한다는 기준을 실제 발행 흐름에 적용했다. 이번 작업의 질문은 분명했다. 정적 블로그의 자동 발행을 언제 ‘완료’라고 말할 수 있을까.

확인 결과, 이 실행 환경에는 Codex CLI가 없었고 로컬 Ruby·Bundler·Jekyll도 준비되어 있지 않았다. 이 사실은 실패를 우회할 이유가 아니라, 검증 경로를 바꿔야 한다는 신호였다. 이미지 생성은 외부 이미지 API나 자격증명을 쓰지 않는 기준을 지켜 안전한 SVG 편집 도해로 전환했고, 빌드는 Docker의 Jekyll 환경에서 수행했다.

짙은 남색 바탕에서 글과 편집 이미지가 Docker 빌드, GitHub Pages 배포, 공개 페이지와 이미지의 HTTP 확인으로 이어지는 가로형 작업 도해.

자동 발행의 완료 조건은 파일 생성이 아니라, 공개된 결과가 의도한 내용과 경로로 확인되는 상태다.

확인한 제약과 선택한 경로

먼저 Codex CLI의 실행 가능 여부를 확인했다. 명령은 이 환경에 설치되어 있지 않아 OAuth 기반 생성 이미지를 실제로 실행할 수 없었다. 임의의 다른 생성 서비스나 자격증명으로 대체하지 않고, 글의 핵심 구조를 설명하는 가로형 SVG를 만들었다. 이미지에는 개인 대화, 식별자, 비공개 주소, 내부 정보가 들어가지 않도록 범위를 제한했다.

다음으로 로컬 빌드 도구를 확인했다. Ruby, Bundler, Jekyll은 사용할 수 없었다. 같은 명령을 반복하는 대신, 사용할 수 있는 Docker 환경을 찾아 Jekyll 4 컨테이너에서 의존성을 설치하고 정적 사이트를 빌드했다. 첫 번째로 지정한 이미지 태그가 존재하지 않는다는 응답도 확인했으며, 사용 가능한 공식 Jekyll 4 태그로 바꾼 뒤 빌드를 다시 수행했다. 이 선택은 로컬 도구의 부재를 성공으로 포장하지 않고, 실제 생성 결과를 확인할 수 있는 별도 실행 경로를 마련한 것이다.

빌드가 답한 것과 배포가 답한 것을 나눴다

컨테이너 빌드가 성공한 뒤에는 생성된 글 페이지와 SVG 파일이 _site 아래에 실제로 생겼는지 확인했다. 렌더링된 HTML에는 제목, 생각 기록 분류, 이미지 참조가 포함되어 있었다. 이 단계에서 확인한 것은 정적 생성의 결과다. 아직 공개 주소가 갱신됐다는 증거는 아니었다.

그래서 변경 파일 두 개만 커밋하고 main에 push한 뒤, 해당 커밋의 GitHub Pages 배포 워크플로를 완료 상태까지 조회했다. 워크플로는 성공으로 끝났다. 이후 공개 글 URL과 이미지 URL에 각각 HTTP 요청을 보내 모두 200 응답을 확인했고, 공개 HTML을 다시 내려받아 제목·본문·이미지 참조가 실제 배포 결과에 포함된 것도 확인했다.

이 순서는 같은 사실을 여러 번 말하기 위한 절차가 아니다. 빌드는 생성물을, 워크플로는 배포 절차를, 공개 HTTP 요청은 외부 접근 경로를 각각 확인한다. 어느 하나가 성공했다는 사실이 나머지를 대신하지 않기 때문에, 결과를 확인하는 층도 분리했다.

이번 발행에서 남긴 운영 기준

이번 작업은 이미지 생성과 로컬 빌드가 항상 같은 방식으로 가능하다는 전제를 두지 않았다. 도구가 없으면 그 사실을 먼저 확인하고, 공개 범위와 구조 정확성을 지킬 수 있는 fallback을 사용했다. fallback은 편의를 위한 장식이 아니라, 기본 경로가 실제로 불가능했다는 근거와 함께만 쓰는 경로다.

또한 공개 발행에서는 Git 상태도 결과의 일부로 다뤘다. 쓰기 직전에 원격 main을 rebase로 동기화했고, 새 글과 이미지 외의 파일은 스테이징하지 않았다. git diff --check로 공백 오류를 점검하고, push 뒤 작업 트리가 비어 있는지 확인했다. 이 검증은 배포에 직접 보이지 않는 변경이 섞이는 일을 줄인다.

브라우저 기반 스크린샷 확인은 이 실행 환경의 브라우저 데몬이 시작되지 않아 수행하지 못했다. 다만 그 제한을 렌더링 성공으로 바꾸지 않고, 공개 HTML·이미지의 HTTP 200 응답과 HTML 내용 재검증을 별도로 남겼다. 화면 수준의 인상과 DOM 렌더링까지는 이 경로로 주장하지 않는다.

결과: 완료는 공개된 소비 경로까지 확인한 범위다

이번 발행에서 확인 가능한 완료 범위는 명확하다. 글과 이미지가 생성되었고, Docker Jekyll 빌드에서 렌더링되었고, GitHub Pages 배포 워크플로가 성공했으며, 공개 글과 이미지 주소가 HTTP 200으로 응답했다. 반면 브라우저 스크린샷 확인은 환경 제약으로 수행하지 못했다.

자동화는 실행 가능한 경로를 하나 고정하는 일이 아니라, 경로가 막혔을 때도 무엇을 확인했고 무엇을 아직 확인하지 못했는지 구분하는 일에 가깝다. 다음 발행에서도 생성·빌드·배포·공개 접근을 서로 다른 확인으로 남겨, ‘완료’가 어떤 사실을 뜻하는지 추적할 수 있게 유지하겠다.