개인 사이트 다시 만들기 (5) — 버전을 0.0.1 에서 26.8.3 으로 바꾼 이유Rebuilding My Personal Site (5) — Why I Switched Versioning from 0.0.1 to 26.8.3

이 저장소에는 커밋이 125개 있다. 메시지를 시간순으로 늘어놓으면 버전을 어떻게 붙였는지가 그대로 보인다. 세 번 바뀌었고, 지금은 26.8.3 처럼 날짜를 쓴다.

This repository has 125 commits. Lining up the commit messages in chronological order shows how I numbered versions over the years. The convention changed three times, settling on date-based versions like 26.8.3.

1기 — semver 를 흉내 냈다Era 1 — Imitating Semver

2021년 1월 한 달 동안 버전 번호가 붙은 커밋이 38개 있다. 그런데 서로 다른 번호는 27개뿐이다. 11번은 앞에 쓴 번호를 다시 썼다는 뜻이다.

In January 2021 alone, there were 38 commits with version numbers. Only 27 of those numbers were unique, meaning 11 commits reused a version number that had already been used earlier.

0.0.1 → 0.0.2 → 0.0.3 → 0.0.1 → 0.0.2 → 0.0.3 → 0.0.4 → 0.0.5 → 0.0.6
0.1.0 → 0.1.4 → 0.1.5 → 0.1.6 → 0.1.0 → 0.1.0 → 0.1.1 → 0.1.2
0.2.0 → 0.2.0 → 0.2.0 → 0.2.5 → 0.2.5 → 0.3.0 → 0.3.0
0.5.0 → 0.6.0 → 0.5.5 → 1.0.0 → 1.0.1
1.1.0 → 1.1.0 → 1.1.1 → 1.1.2 → 1.1.3 → 1.1.5 → 1.1.5 → 1.2.0 → 1.5.0

세 종류의 사고가 한꺼번에 보인다.

Three kinds of mistakes show up at once:

• 같은 번호를 다시 쓴다 — 0.2.0 이 세 번, 0.0.1~0.0.3 은 한 바퀴 통째로 반복된다
• 번호를 건너뛴다 — 0.1.0 다음이 0.1.4 다. 0.1.1~0.1.3 은 없다. 1.1.3 다음도 1.1.5 다
• 뒤로 간다 — 0.1.6 다음에 0.1.0, 0.6.0 다음에 0.5.5 가 나온다

• Reusing the same number — 0.2.0 appears three times in a row, and 0.0.1–0.0.3 repeats an entire cycle
• Skipping numbers — 0.1.0 jumps straight to 0.1.4 with no 0.1.1–0.1.3, and 1.1.3 jumps to 1.1.5
• Moving backward — 0.1.6 is followed by 0.1.0, and 0.6.0 is followed by 0.5.5

표기도 흔들린다. My Web - 1.1.0 · My Web-1.1.1(하이픈 앞뒤 공백이 없다) · My web - 1.1.5(w 가 소문자다) 가 같은 주 안에 섞여 있다.

Formatting drifted too: My Web - 1.1.0, My Web-1.1.1 (no spaces around the hyphen), and My web - 1.1.5 (lowercase w) all appeared within the same week.

2기 — 번호를 버렸다Era 2 — Dropping Numbers Altogether

2021년 2월부터 번호가 사라진다. 그 뒤 4년 동안 쌓인 커밋이 열 개다. 중복을 빼면 메시지는 이게 전부다.

Starting in February 2021, version numbers disappeared. Across the next four years, only ten commits accumulated. Removing duplicates leaves just these messages:

My WebSite
my web site
My web site
gain

Create CNAME
Delete CNAME
Update CNAME

위 네 줄은 같은 말을 네 가지로 적은 것이다. 아래 세 줄은 GitHub 웹 편집기에서 파일을 만들거나 지울 때 자동으로 채워 주는 기본 메시지다. 즉 직접 쓴 메시지가 아니다.

The first four lines are the same phrase typed four different ways. The bottom three are default messages auto-generated by the GitHub web editor when creating or deleting a file—meaning I didn't even type them.

번호를 버린 게 후퇴처럼 보이지만, 여기서 힌트가 하나 나온다. 이 시기 커밋을 다시 찾을 때 실제로 쓴 단서는 메시지가 아니라 날짜였다. 그리고 2025년 6월 커밋의 메시지가 25_06 이다. 처음으로 날짜가 버전 자리에 들어왔다.

Dropping numbers looks like a step backward, but it revealed a clue: whenever I needed to look up a commit from this period, the handle I actually used wasn't the message—it was the commit date. Then in June 2025, a commit message read 25_06. For the first time, the date stepped into the version slot.

3기 — 날짜를 쓴다Era 3 — Using the Date as the Version

2026년 1월 재시작 직후에는 아직 과도기였다. 26.0.1 ~ 26.0.8 처럼 연도 뒤에 일련번호를 붙였고, 2월에는 26.2.5.2 · 26.2.6.1 ~ 26.2.6.7 처럼 자리가 네 개까지 늘어난다. 하루에 열 번 커밋하면서 번호가 감당이 안 된 것이다.

Right after restarting the site in January 2026, there was a brief transition: 26.0.1 through 26.0.8 paired the year with a sequence number, and in February it expanded to four segments like 26.2.5.2 and 26.2.6.1–26.2.6.7. Committing ten times a day made arbitrary counters unmanageable.

2026년 3월 7일부터 연.월.일 로 고정했다.

Starting March 7, 2026, I locked the format to YY.M.D.

규칙은 두 줄이면 끝난다. 메시지는 그날 날짜다. 같은 날 또 커밋하면 뒤에 순번을 붙인다. 외울 것도, 판단할 것도 없다.

The entire rule fits in two lines: the commit message is today's date, and additional commits on the same day append .2, .3, and so on. There is nothing to memorize or judge.

어긋난 두 건, 그리고 이 방식의 한계Two Mismatches, and the Limits of This Approach

규칙을 정한 뒤의 커밋 29개를 전부 검사해 봤다. 메시지의 날짜와 실제 커밋 날짜를 비교하는 것이다. 두 건이 어긋난다.

I audited all 29 commits made after adopting the YY.M.D rule by comparing the date in the commit message against the Git commit timestamp. Two commits didn't match:

커밋일 2026-07-26   메시지 26.7.27
커밋일 2026-08-02   메시지 26.8.1

Commit date 2026-07-26   Message 26.7.27
Commit date 2026-08-02   Message 26.8.1

둘 다 자정 언저리에서 생긴 것이다. 자정 직전에 커밋하면서 다음 날 날짜로 적기도 했고, 반대로 자정을 넘겨 커밋하면서 작업한 날짜를 그대로 적기도 했다. 날짜는 하나인데 "작업한 날"과 "커밋이 찍힌 날"이 갈리는 구간이 있고, 거기서는 결국 사람이 판단하게 된다.

Both happened right around midnight—once typing the next day's date just before midnight, and once typing the workday's date just after passing midnight. Whenever "the day I worked" and "the timestamp on the commit" straddle midnight, human judgment still enters the picture.

그래서 이 방식이 모든 경우를 막아 주는 건 아니다. 다만 어긋났다는 사실 자체가 드러난다는 게 다르다. 메시지가 날짜라서 커밋 메타데이터와 나란히 놓기만 하면 차이가 보이고, 보이면 이유를 설명할 수 있다. 1.4.2 를 1.4.3 으로 잘못 적었다면 대조할 바깥 사실이 없어서 어긋났는지조차 알 수 없다.

So this scheme does not prevent every discrepancy. What changes is that any discrepancy becomes immediately visible. Because the message encodes a date, placing it next to the Git timestamp exposes any mismatch at a glance. If you accidentally type 1.4.3 instead of 1.4.2, there is no external ground truth to compare it against.

버전은 어떤 질문에 답해야 하나What Question Should a Version Answer?

마지막 줄이 중요하다. 날짜 방식이 semver 보다 나은 게 아니다. 라이브러리를 배포한다면 semver 가 유일한 답이다. 쓰는 쪽이 "올려도 되나"를 판단해야 하고, 그 판단을 번호로 전달하는 게 semver 의 일이기 때문이다.

That last row is the key: date versioning is not universally better than semver. If you publish a library or package, semver is mandatory because downstream users need to know whether an upgrade is safe.

이 저장소는 그 상황이 아니다. 여기서 버전을 보고 실제로 하는 일은 하나뿐이다 — "지금 라이브에 올라간 게 언제 것인가." 배포가 반영됐는지 확인할 때도, 어디로 되돌릴지 고를 때도 이 질문 하나를 한다.

This repository is a deployed website, not a library. The only question I actually ask a version string here is: "Which day's build is currently live?" Whether verifying a deploy or picking a rollback point, that is the only question that matters.

커밋 간격도 이 방식과 맞는다. 2026년 3월 7일부터 지금까지 커밋 29개, 간격 중앙값이 5일이다. 하루에 여러 번 몰아치던 1월·2월과 다르다. 닷새에 한 번씩 손대는 저장소에서 날짜는 충분히 촘촘한 식별자다.

The commit cadence fits this granularity too. Across the 29 commits since March 7, 2026, the median interval between commits is 5 days—a natural match for a date-based identifier.

정리Takeaways

2021년에 번호를 안 지킨 걸 오래 게으름으로 기억하고 있었다. 로그를 다시 읽어 보니 그게 아니었다. 지킬 근거가 없는 규칙을 가져다 쓴 것이고, 근거가 없으면 규칙은 반드시 흐트러진다. 0.6.0 다음에 0.5.5 가 나온 건 실수가 아니라 그 규칙이 아무 역할도 안 하고 있었다는 증거다.

For years, I remembered my messy 2021 version numbers as simple laziness. Re-reading the commit log showed otherwise: I had adopted a rule whose underlying question didn't apply to my project. Seeing 0.5.5 right after 0.6.0 wasn't a typo—it was proof that the number wasn't doing any real work.