휴대폰으로 글 목록을 열었다가 이상한 걸 봤습니다. 최신순이어야 할 목록에서 순서가 맞지 않았습니다.

정렬 메뉴를 눌러 다시 최신순을 골라도 그대로였습니다. 날짜가 아예 안 보이는 줄도 있었고요.

편집 도구 문제인 줄 알았습니다. 아니었습니다.

파일을 열어보니 형식이 둘이었습니다

처음에 템플릿으로 받은 글은 이랬습니다.

pubDate: Aug 30 2026

CMS로 쓴 글은 이랬고요.

pubDate: 2026-09-01T04:51:00

같은 칸인데 모양이 다릅니다. 한 파일 안에서 섞여 있는 것도 있었습니다.

title: RyuMa Space를 시작하며
pubDate: Aug 30 2026
updatedDate: 2026-08-31T06:30:00

작성일은 템플릿 형식, 수정일은 CMS 형식입니다. 처음 글을 템플릿 상태로 두고 나중에 CMS에서 한 번 저장했더니 이렇게 됐습니다.

사이트는 멀쩡했습니다

여기가 오래 못 알아챈 이유입니다.

블로그 목록은 정상이었습니다. 날짜도 제대로 찍혔고 순서도 맞았습니다. 깨진 건 글 쓰는 화면뿐이었습니다.

읽는 쪽이 둘이기 때문입니다.

Astro 쪽은 빌드할 때 스키마가 날짜로 바꿔줍니다.

pubDate: z.coerce.date(),

coerce는 “가능하면 바꿔보라”는 뜻입니다. Aug 30 2026도 자바스크립트가 날짜로 읽어주니 그냥 통과합니다. 그래서 사이트는 아무 문제가 없었습니다.

CMS 쪽은 브라우저에서 파일 목록을 읽어 정렬합니다. 여기서는 형식이 제각각이면 어떤 값은 날짜로 읽히고 어떤 값은 안 읽힙니다. 안 읽힌 값은 정렬에서 제자리를 못 찾고요.

이번엔 소스를 안 열었습니다. 양쪽 파일을 나란히 놓는 순간 원인이 분명했거든요. 남의 코드를 여는 건 내 쪽에서 설명이 안 될 때 하는 일입니다.

관대한 파서가 문제를 감춥니다

z.coerce.date()는 편하라고 쓴 건데, 이번엔 그게 문제를 덮었습니다.

빌드가 한 번이라도 터졌으면 첫날 알았을 겁니다. 그런데 통과해버리니까 형식이 섞인 채로 계속 쌓였습니다. 제가 알아챈 건 글이 열 편 넘어가서 목록이 눈에 띄게 어지러워진 뒤였습니다.

“되니까 괜찮다”가 제일 오래 가는 함정입니다. 되는 건 맞는데, 한 군데서만 되고 있었던 거죠.

형식을 고정했습니다

CMS 설정에서 저장 형식을 박아뒀습니다.

- label: 작성일
  name: pubDate
  widget: datetime
  format: 'YYYY-MM-DDTHH:mm:ss'
  date_format: 'YYYY-MM-DD'
  time_format: 'HH:mm'

세 줄이 비슷하게 생겼는데 역할이 다릅니다.

• format — 파일에 적히는 모양. 이게 진짜입니다.
• date_format / time_format — Netlify·Decap CMS와 맞추려고 남아 있는 옛 옵션입니다. format이 없을 때만 파일에 적히는 모양을 정하고, format을 적어두면 무시됩니다. 제 설정에서는 사실상 아무 일도 안 하는 줄입니다.

저는 처음에 이 둘을 헷갈려서 date_format만 고쳐놓고 “고쳤다”고 생각했습니다. format이 이미 있었으니 파일은 그대로였습니다.

그리고 새 규칙을 정한다고 과거 글이 따라오지 않습니다. 이미 있는 글의 날짜를 전부 같은 형식으로 고쳤습니다. 열 몇 개라 손으로 했습니다.

목록을 읽을 수 있게 만든 것

설정 파일을 연 김에 세 가지를 더 넣었습니다.

sortable_fields:
  fields: [pubDate, updatedDate, title]
  default:
    field: pubDate
    direction: descending

summary: "{{title}} · {{pubDate | date('YYYY-MM-DD')}}"

view_groups:
  - label: 연도
    field: pubDate
    pattern: '\d{4}'

기본 정렬을 최신순으로, 목록 한 줄에 제목과 날짜를 같이, 연도별로 묶어 보는 메뉴를.

이 세 개는 형식을 고정했기 때문에 비로소 동작합니다. 특히 summary의 date('YYYY-MM-DD')는 값이 날짜로 읽혀야 먹습니다. 안 읽히면 그 자리가 그냥 비거나 원본 문자열이 튀어나옵니다.

그 김에 찾은 것: 주소에 박힌 오타

파일 목록을 훑다가 이런 이름을 봤습니다.

astro-블로그를-cloudflare에-올리며-막한-다섯-곳.md

‘막힌’이 ‘막한’으로 되어 있습니다. 제목을 적을 때 오타를 냈고, CMS가 그 제목을 그대로 파일 이름으로 썼습니다.

slug: '{{slug}}'

제목에서 슬러그를 만들라는 설정입니다. 그리고 이 블로그에서 파일 이름은 곧 주소입니다.

제목의 오타는 고쳤습니다. 그런데 파일 이름은 그대로였습니다. 슬러그는 글을 만드는 순간 정해지고, 그 뒤에 제목을 고쳐도 따라오지 않습니다.

여기까지 쓰고 “그럼 방법이 없구나” 하고 넘어가려다가, 문서를 한 번 찾아봤습니다. 있었습니다.

In a saved entry, the pencil button renames the entry.

편집 화면의 슬러그 칸에 연필 버튼이 있고, 여기서 바꾸면 파일을 옮기고 참조도 같이 고쳐준다고 합니다. 제가 안 찾아본 거였습니다.

다만 기능이 있다고 해서 공짜는 아닙니다. 주소를 바꾸면 리디렉션을 따로 걸지 않는 한 이미 검색에 잡힌 주소가 죽습니다. 얼마 전에 색인 문제로 한참 헤맨 참이라 이건 감이 옵니다. 그래서 이번엔 아직 색인이 얕을 때 영문 이름으로 옮겨뒀습니다.

지금은 글을 만들 때 제목과 별개로 파일 이름을 영문으로 정합니다. 한글 슬러그가 나쁘다는 게 아니라, 고치기 어려운 자리에 오타가 남는 게 싫어서입니다.

정리

관대한 파서는 편한 만큼 늦게 알려줍니다. 한쪽이 다 받아주면 다른 쪽이 깨질 때까지 모릅니다. 같은 값을 읽는 쪽이 둘 이상이면, 둘 다 통과하는 형식 하나로 좁혀두는 게 낫습니다.

형식은 만들어질 때 정해야 합니다. 나중에 규칙을 정해도 과거 데이터는 안 따라옵니다. 손으로 고칠 수 있는 규모일 때 고쳐두는 게 쌉니다.

자동으로 만들어지는 이름은 만들어지는 순간이 거의 유일한 기회입니다. 파일명, 슬러그, ID 같은 것들요. 바꿀 방법이 아예 없진 않지만 대가가 붙습니다.

설정 파일에는 값만 적지 말고 이유를 같이 적어둡니다. 제 config.yml에는 형식을 박아둔 줄 위에 “여기 시간대를 붙이면 9시간 어긋난다”는 주석이 달려 있습니다. 반년 뒤의 제가 이걸 안 지우게 하려고요.

고친 곳

2026년 9월 29일, 글에 붙일 참고 문서를 하나씩 다시 열어보다가 본문과 어긋나는 곳을 찾아 고쳤습니다.

• date_format / time_format 설명을 고쳤습니다. 처음엔 “화면에 보이는 모양”이라고 적었는데, 문서상 이 둘도 저장 형식이고 format이 있으면 무시됩니다.
• 슬러그 바꾸는 방법의 인용문을 지금 문서 문장으로 바꿨습니다. 지금은 점 세 개 메뉴가 아니라 슬러그 칸의 연필 버튼입니다.

참고한 문서

• Sveltia CMS 문서 — DateTime 필드 — format, date_format, time_format의 차이
• Sveltia CMS 문서 — 목록 보기 (정렬·그룹) — sortable_fields, view_groups 설정
• Sveltia CMS 문서 — 슬러그와 파일 경로 — 저장된 글의 이름 바꾸기, 주소가 바뀌는 문제
• Zod 문서 — Coercion — z.coerce.date()가 new Date()로 읽는다는 것