디지털 가든

사이트 버전 대장기: 십일 페이지의 바이트 단위 일치와 오해된 배포 체인

2026-10-16 · 약 9분 · qaqmin · 사이트 버전 · 배포 체인 · Astro · 바이트급 대장

매일 사이트에 글을 발표하는 사람이, 반드시 글이 어떻게 방문자의 화면에 닿는지를 알고 있는 것은 아니다. 이번에 「사이트의 작업 내용을 찾아줘」라는 한 개의 요청이, 자기 강산의 전면적인 측량과, 한 개의 배포 체인의 정본 청원으로 발전했다.

1. 근본을 찾다: my-portal-v19이 곧 qaqmin

작업 공간에는 디렉터리가 산더미이고, qaqmin 사이트의 참모습은 한눈에 구분됐다——my-portal-v19——Astro 사이트 프로젝트, 공식 주소 https://qaqmin.com(Cloudflare Pages 커스텀 도메인), 저자 QAQMin, 부제 「남길 가치가 있는 소프트웨어와 도구를 만든다」. 기능 목록이 깔렸다——WebGL 입자 장면(구천 입자, 모바일은 사천오백의 피보나치 행성, 스크롤 시 행성⇄이름에 모임⇄은하⇄파 메시 사이에서 변형하고, 마우스 시차 포함), 건站点年轮의 궤도 링, 푸터의 split-flap flip clock(초급의 반전과 Web Audio의 기계음), 실시간 온라인 인원과 방문자 성운(WebSocket로 portal-backend의 Durable Object에 연결, 온라인 방문자가 각각 유성이 된다), 행성에의 별 남기기 메시지(삼중 여과——키워드 블랙리스트와 Workers AI의 독 판정과 인공 심사 페이지, IP 쿨다운, 최신 삼백 개만 유지), 별의 반응(금성을 클릭 +일, 전 온라인 방문자가 실시간 동기), 방문자 성도(국가별로 집계한 세계 점 지도, IP는 SHA-256 지문만 저장), 마일스톤 이스터 에그(백/삼백육십오/오백이십/천/천삼백십사/만 일, 원단, 삼·일오 사장 생일, 제야 카운트다운). 사언어(중영일한, 중문이 기본 루트 경로), Pages Functions가 방문자의 IP 국가에 따라 자동 전환하고, 수동 선택은 cookie로 우선.

2. 대장: 십일 페이지의 바이트 단위 일치

온라인 비교는 익숙한 옛 적에 맞닥뜨렸다——본机的 TUN 프록시가 qaqmin.com을 198.18.x.x의 가짜 IP로 해결해 TLS 실패; 프록시를 돌아 직결하면 온라인은 200을 반환했다. 십일 페이지를 한 페이지씩 비교한 결과는 안심시키는 것이었다——홈페이지(49,830 바이트), /about/, /en/, /rss.xml(856,667 바이트), /sitemap-0.xml(636,878 바이트), /garden/tag/qaqmin/, /works/tiebalite/, /sponsor/, /wrapped/, /search/, /404.html——모두 바이트 단위로 일치. 이상해 보이는 두 점은 정상으로 설명됐다——/works/(하위 경로 없음)이 온라인에서 404를 반환하는 것은, 로컬의 dist의 works 디렉터리에 본래 index.html이 없기 때문; 꼬리 슬래시 없는 태그 페이지가 308을 반환하는 것은 Astro의 표준 리다이렉트. rss와 sitemap은 전사의 페이지와 글의 완전한 목차로서, 이 두 개가 일치하면 기본적으로 전 페이지 집합에 빠짐이 없다고 확인할 수 있다. 로컬 쪽의 신선도도 확인됐다——git 작업 트리는 클린, HEAD는 오늘 아침의 화원 글의 커밋, 마지막으로 커밋된 새 글은 이미 dist의 rss와 sitemap에 있고, 어떤 소스 파일도 dist의 빌드 산출물보다 새롭지 않고, .wrangler/tmp의 타임스탬프는 dist의 빌드 시간과 일치——빌드 후 즉시 배포의 흐름의 흔적이 선명. 유일하게 완전히 검증할 수 없던 것은 portal-backend의 온라인상의 배포 버전(WebSocket 주소는 정적인 페이지에 없고, 서비스 binding을 통한다); 정적 사이트 자체는 안심할 수 있다——온라인은 바로 로컬의 이 코드이다.

3. 정본 청원: commit은 온라인에 푸시하지 않는다

사용자가 한 개의 요채의 물음을 냈다——「내가 직접 한 커밋 변경은 그대로 온라인에 푸시되는 거지?」답은 아니오이고, 글을 발표하는 모든 사람이 기억해 둘 가치가 있다——git commit은 순수히 로컬의 아카이브이고, 저장소에는 remote가 일절 설정되지 않았다(git remote -v는 비어 있음), 커밋은 빌드도 배포도 이끌어내지 않는다. 온라인을 바꾸는 것은 한 개의 중간 단계뿐——npx wrangler pages deploy dist. 완전한 체인은——집필/번역→검증→npm run build로 dist를 생성→wrangler 배포(이 단계만이 Cloudflare에 푸시된다)→curl로 온라인을 스팟 체크해 편수를 확인→git commit으로 맺는다. 이번 비교가 전면적으로 일치한 것은, 십육 일의 이른 아침에 일체를 연속으로 돌렸기 때문이다(dist는 00:14에 빌드, 즉시 배포, 커밋은 00:17), 빌드와 배포는 커밋 전에 일어난다——이것은 「흐름을 다 돌린」상태이지, 「커밋이 자동 배포한다」는 메커니즘이 아니다. 주의해야 할 리스크도 선명해진다——만약 어느 날 소스나 글을 바꾸고 커밋만 하고 build와 deploy를 잊으면, 온라인은 변하지 않고 로컬의 HEAD가 앞서간다——매일의 흐름의 「배포 전에 온라인 버전을 확인, 배포 후에 편수를 확인」은 바로 이것을 막기 위한 것이다.

실제 좌표

qaqmin 사이트 버전 배포 체인 Astro 바이트급 대장

댓글

← 디지털 가든