예전 글의 틀린 문장을 고쳤는데, 독자에게 남은 건 「9월 갱신」 한 줄이었습니다

예전에 쓴 글을 다시 읽다가 틀린 문장을 몇 군데 고쳤습니다. 고치고 나서 그 글을 열어 보니 제목 아래에 이렇게만 나와 있었습니다.

birchholt · 2026년 9월 · 2026년 9월 갱신

무엇을 고쳤는지는 어디에도 없습니다. 예전에 이 글을 읽고 틀린 내용을 그대로 가져간 사람이 다시 와도 「9월에 뭔가 바뀌었다」 이상은 알 수 없습니다. 구조화 데이터와 sitemap이 검색엔진에 따로 알려 주는 것도 고친 날짜뿐입니다.

그래서 이번에는 두 가지를 했습니다. 첫째, 고친 사실이 남는 세 곳을 라이브 사이트에서 글마다 맞춰 봤습니다. 둘째, 정정 내역을 글에 남기는 틀을 사본에서 만들어 날짜가 어긋나는 경우를 일부러 만들어 봤습니다. 2026-10-06에 Hugo v0.165.0으로 한 작업입니다.

고친 사실이 남는 세 곳을 글마다 맞춰 봤습니다

글을 고치면 그 사실이 세 군데에 남습니다.

• 화면의 갱신 표시 — 제목 아래 줄(byline)에 붙는 「○월 갱신」
• 구조화 데이터의 dateModified — 페이지 안에 검색엔진이 읽으라고 넣어 두는 JSON(ld+json)의 수정일
• sitemap의 lastmod — 사이트 주소 목록 파일에 주소마다 적는 마지막 수정 시각

라이브 사이트의 글 18편을 하나씩 받아서 이 셋을 뽑았습니다. 읽기만 하는 요청입니다.

curl -s https://birchholt.com/sitemap.xml -o sitemap.xml
curl -s https://birchholt.com/posts/soft-404-on-pages/ \
  | grep -o '"dateModified":"[^"]*"'

공개한 뒤에 고친 12편은 dateModified와 sitemap lastmod가 12편 모두 초 단위까지 같았습니다. 둘 다 git의 마지막 커밋 작성자 시각(author date)에서 나오기 때문입니다. 저장소에서 git log -1 --format=%aI -- <파일>로 뽑은 값과도 18편 전부 일치했습니다. 이 값이 어디서 오는지는 sitemap lastmod를 git에 맞춘 글에 따로 적었습니다.

기계가 읽는 날짜는 맞았습니다. 걸린 건 사람이 읽는 쪽이었습니다.

• 화면은 달까지만 보여 줍니다. 12편 중 6편은 「9월 · 9월 갱신」처럼 같은 달이 두 번 찍힙니다. 공개 직후에 고친 건지 3주 뒤에 고친 건지 독자는 알 수 없습니다.
• 12편은 파일마다 커밋이 6~9개 쌓여 있는데 화면에는 마지막 한 번만 남습니다.
• 본문에 「정정」 상자를 손으로 써 둔 글은 18편 중 2편뿐이었습니다. 그 두 편도 상자 날짜는 09-20인데 byline은 「9월 갱신」, dateModified는 09-22입니다. 정정 날짜와 갱신 날짜가 서로 다른 날을 가리키고 갱신 표시에서 정정 상자로 가는 연결도 없습니다.

10월에 공개한 6편은 화면에 갱신 표시가 없고 dateModified도 없습니다. 템플릿이 「수정일이 공개일보다 뒤일 때만」 넣기 때문입니다. 그런데 sitemap 쪽에는 그 조건이 없어서 lastmod(10-04 01:21, 파일을 마지막으로 커밋한 시각)가 공개일(최대 10-06 21:54)보다 앞서 있었습니다. 이 글에서는 관찰만 적어 둡니다.

날짜는 「바뀌었다」까지만 말해 줍니다

Google의 byline 날짜 안내가 권하는 것은 날짜를 잘 보이게 두고 「Last updated」 같은 이름표를 달고 구조화 데이터에 datePublished·dateModified를 넣는 것입니다. 그리고 화면의 날짜와 구조화 데이터의 날짜가 맞아야 한다고 적습니다.

원문 — 「Label your dates appropriately with text like “Publish” or “Last updated”」, 「Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values. Time and timezone are optional in user-visible data even if provided in structured data.」 2026-10-06에 열어 확인했습니다. 시각과 시간대는 화면에서 빼도 된다고 하지만 날짜 자체는 빼도 된다는 말이 없습니다. 그래서 「2026년 9월」만 보이는 지금 화면이 이 조건을 채운다고 자신하기는 어렵다고 봤습니다(제 해석입니다).

같은 페이지에서 정정을 뜻하는 correction을 찾아보면 0건입니다. 날짜를 어떻게 보일지만 다루고, 무엇을 고쳤는지 남기는 방법은 다루지 않습니다.

sitemap 쪽 안내는 한 걸음 더 나갑니다. sitemap 만들기 문서는 lastmod가 「마지막으로 의미 있게 고친 시각」이어야 한다며 그 예로 본문, 구조화 데이터, 그리고 페이지 안의 링크를 고친 것을 듭니다.

제 글로 보면 이렇습니다. cf-analytics-tistory의 마지막 커밋은 다른 글로 가던 링크가 든 문장 하나를 지운 것뿐입니다. 지침대로라면 날짜를 올리는 게 맞고, 실제로 화면에 「2026년 10월 갱신」이 붙었습니다. 그런데 같은 파일의 앞선 커밋에는 출처를 붙이고 사실 설명을 바로잡은 수정이 있습니다. 링크 문장 하나를 지운 것과 사실 설명을 고친 것이 화면에서는 똑같은 「갱신」으로 보입니다. 날짜만으로는 둘을 구분할 수 없습니다.

Hugo 포럼에도 갱신일 표시 질문이 있습니다. 한 스레드는 「고친 글에만 Last updated를 띄우고 싶다」는 질문이고 답은 compare.Gt .Lastmod .Date 같은 비교문입니다. 다른 스레드도 .Date.Equal .Lastmod로 날짜를 보일지 말지 정하는 데서 끝납니다. 제 템플릿도 같은 수준이었습니다. 날짜를 언제 보일지는 다들 풀어 놨는데, 무엇을 고쳤는지는 비어 있었습니다.

정정 내역을 프론트매터에 한 줄씩 적게 했습니다

운영 저장소는 건드리지 않고 사본을 떠서 만들었습니다. 고친 내용은 글 맨 위 프론트매터(제목·날짜 같은 설정값을 적는 곳)에 목록으로 적습니다.

corrections:
  - date: 2026-10-11
    text: "「A라서 B」라고 적었는데 틀렸습니다. 실제 원인은 C였습니다."

본문에 손으로 상자를 쓰면 글마다 형식이 달라지고 몇 건인지 셀 수도 없습니다. 목록으로 두면 템플릿이 글 끝에 같은 모양으로 모아 보여 주고 건수도 셀 수 있습니다.

{{- /* layouts/_partials/corrections.html (발췌) */ -}}
{{- with .Params.corrections }}
{{- $page := $ }}
<aside class="note corrections" id="corrections">
  <p><strong>정정 내역</strong></p>
  <ul>
  {{- range sort . "date" "desc" }}
    {{- $d := time.AsTime .date }}
    {{- if gt ($d.Format "2006-01-02") ($page.Lastmod.Format "2006-01-02") }}
      {{- warnf "%s: 정정 날짜 %s 가 lastmod %s 보다 늦습니다" $page.File.Path ($d.Format "2006-01-02") ($page.Lastmod.Format "2006-01-02") }}
    {{- end }}
    <li><time datetime="{{ $d.Format "2006-01-02" }}">{{ $d.Format "2006년 1월 2일" }}</time> — {{ .text | markdownify }}</li>
  {{- end }}
  </ul>
</aside>
{{- end }}

제목 아래 줄은 두 군데를 바꿨습니다. 날짜를 일 단위로 보이게 했고 정정이 있으면 건수를 링크로 붙여 글 끝 목록으로 보냅니다.

<time datetime="{{ .Date.Format "2006-01-02" }}">{{ .Date.Format "2006년 1월 2일" }}</time>
…
{{ with .Params.corrections }}
  <span class="dot">·</span>
  <a href="#corrections">정정 {{ len . }}건</a>
{{ end }}

빌드한 결과입니다.

birchholt · 2026년 8월 31일 · 2026년 10월 14일 갱신 · 정정 2건

정정이 없는 글은 날짜 단위만 바뀌고 나머지는 그대로입니다(2026년 9월 4일 · 2026년 9월 22일 갱신). 「갱신」은 날짜를, 「정정」은 내용을 맡습니다. 둘을 한 단어에 몰지 않았습니다.

schema.org에는 correction이라는 속성도 있습니다. 설명은 「Indicates a correction to a CreativeWork」이고 같은 페이지에 사용 도메인이 「< 1K」로 나옵니다(schema.org/correction). Google의 날짜 안내와 Article 구조화 데이터 문서에는 이 단어가 없어서 ld+json에는 넣지 않았습니다. 넣었을 때 검색 결과가 달라지는지는 확인하지 못했습니다.

처음 만든 「정정」 라벨은 자정을 넘기자 조용히 바뀌었습니다

처음에는 다르게 만들었습니다. 마지막 커밋 날짜와 가장 최근 정정 날짜가 같으면 byline 단어를 「갱신」 대신 「정정」으로 바꾸는 방식입니다. 그럴듯해 보여서 사본 저장소에서 커밋 시각을 정해 가며 경우를 나눠 봤습니다.

GIT_AUTHOR_DATE='2026-10-13T00:10:00+09:00' \
GIT_COMMITTER_DATE='2026-10-13T00:10:00+09:00' \
  git commit -am "정정 추가"

둘째 줄이 문제입니다. 밤에 정정을 적고 자정을 넘겨 커밋하면 날짜가 하루 어긋나고 경고 없이 라벨이 「갱신」으로 떨어집니다. 셋째 줄처럼 정정 뒤에 오탈자를 고쳐도 「정정」이 사라집니다. 날짜 두 개를 비교해 단어를 고르는 방식은 이렇게 조용히 틀립니다. 그래서 앞에서 본 것처럼 갱신일은 그대로 두고 정정 건수를 따로 붙이는 방식으로 바꿨습니다. 이렇게 하면 커밋을 언제 하든 정정이 화면에서 사라지지 않습니다.

남은 경고는 두 가지입니다. 이건 일부러 틀리게 넣어서 실제로 걸리는 것까지 봤습니다.

# 정정을 적고 커밋하기 전에 빌드
WARN  posts/soft-404-on-pages.md: 정정 날짜 2026-10-06 가 lastmod 2026-09-22 보다 늦습니다

# 정정 날짜를 공개일보다 앞으로 잘못 적음
WARN  posts/soft-404-on-pages.md: 정정 날짜 2026-08-01 가 공개일 2026-08-31 보다 이릅니다

첫 번째 경고가 중요합니다. 갱신일은 커밋해야 움직입니다. 커밋 전 로컬 빌드에서는 화면·dateModified·sitemap 셋 다 예전 날짜(09-22)였고 정정 목록만 새 날짜였습니다. 같은 커밋에 정정 한 줄과 본문 수정을 함께 넣으면 그 커밋 시각이 세 곳에 똑같이 들어갑니다. 실제로 커밋하고 다시 빌드하니 dateModified와 sitemap이 둘 다 2026-10-06T23:56:26+09:00, 화면이 「2026년 10월 6일」이 됐습니다.

Hugo가 쓰는 git 시각은 커밋한 시각이 아니라 작성자 시각입니다. 작성자 10-09, 커밋 10-10으로 넣으니 dateModified는 10-09가 됐습니다. 문서 문장은 「The Git author date for the file’s last revision」입니다 (Hugo · Front matter 설정).

어디까지를 정정으로 적을지 기준을 정했습니다

모든 수정을 목록에 올리면 목록이 커밋 로그가 되고 아무도 안 읽습니다. 그래서 제 기준은 독자가 이 글을 믿고 한 행동이 달라질 수 있는가입니다.

갱신일은 git이 알아서 올리니 손댈 게 없습니다. 사람이 정해야 하는 건 왼쪽 열 하나뿐입니다. 정정 문장은 「무엇이라고 적었는데 → 실제로는 무엇이었다」 순서로 한두 문장만 씁니다. 본문의 틀린 문장은 고쳐 두고 옛 문장은 정정 목록에만 남깁니다. 예전 진단 과정 자체가 글의 내용이라 지우면 안 되는 경우에만 본문에 상자를 따로 둡니다. 그때도 프론트매터에 한 줄을 같이 적어야 byline에서 글 끝 목록을 거쳐 그 상자 이야기로 갈 수 있습니다.

관리 화면(CMS)으로 프론트매터를 고친다면 이 목록을 목록 위젯으로 선언해야 합니다. 태그 목록을 글자 한 칸짜리(string) 위젯으로 잘못 선언했을 때 두 번째 태그가 사라지는 것을 Sveltia CMS에서 재 본 적이 있습니다 — Sveltia CMS 글. 지금 이 블로그에는 관리 화면이 없어서 이 정정 목록으로는 시험하지 못했습니다.

글을 고칠 때마다 손에 남기는 순서

이 틀은 아직 사본에서만 돌려 봤고 운영 사이트에 넣을지는 따로 정합니다. 틀과 상관없이 글을 고칠 때 지키기로 한 순서는 이렇습니다.

1. 고친 것이 사실인지 문장인지 먼저 가릅니다. 사실이면 정정 한 줄을 씁니다.
2. 정정 한 줄과 본문 수정을 같은 커밋에 넣습니다. 그래야 세 곳의 날짜가 한 값이 됩니다.
3. 빌드 출력에 날짜 경고가 없는지 봅니다. 제가 본 첫 번째 경고는 커밋 전에 빌드했을 때 떴습니다.
4. 배포 뒤 세 곳을 대조합니다.

P=soft-404-on-pages
curl -s https://birchholt.com/posts/$P/ | grep -o '"dateModified":"[^"]*"'
curl -s https://birchholt.com/sitemap.xml \
  | grep -o "<loc>https://birchholt.com/posts/$P/</loc><lastmod>[^<]*"
git log -1 --format=%aI -- content/posts/$P.md

셋이 같은 값이면 날짜는 끝입니다. 그다음은 화면을 직접 열어 byline의 「정정 N건」이 글 끝 목록으로 이어지는지만 봅니다. 날짜는 기계가 맞춰 주지만 무엇을 고쳤는지는 제가 적지 않으면 어디에도 안 남습니다.