이 저장소에는 커밋이 125개 있다. 메시지를 시간순으로 늘어놓으면 버전을 어떻게 붙였는지가 그대로 보인다. 세 번 바뀌었고, 지금은 26.8.3 처럼 날짜를 쓴다.
| 시기 | 방식 | 예 |
|---|---|---|
| 2021-01 | semver 흉내 | 0.0.1 · 1.1.5 |
| 2021-02 ~ 2025 | 번호 없음 | My WebSite · gain |
| 2026-03-07 ~ | 연.월.일 | 26.3.7 · 26.8.3.3 |
1기 — semver 를 흉내 냈다
2021년 1월 한 달 동안 버전 번호가 붙은 커밋이 38개 있다. 그런데 서로 다른 번호는 27개뿐이다. 11번은 앞에 쓴 번호를 다시 썼다는 뜻이다.
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세 종류의 사고가 한꺼번에 보인다.
- 같은 번호를 다시 쓴다 —
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가 나온다
표기도 흔들린다. My Web - 1.1.0 · My Web-1.1.1(하이픈 앞뒤 공백이 없다) · My web - 1.1.5(w 가 소문자다) 가 같은 주 안에 섞여 있다.
2기 — 번호를 버렸다
2021년 2월부터 번호가 사라진다. 그 뒤 4년 동안 쌓인 커밋이 열 개다. 중복을 빼면 메시지는 이게 전부다.
My WebSite
my web site
My web site
gain
Create CNAME
Delete CNAME
Update CNAME위 네 줄은 같은 말을 네 가지로 적은 것이다. 아래 세 줄은 GitHub 웹 편집기에서 파일을 만들거나 지울 때 자동으로 채워 주는 기본 메시지다. 즉 직접 쓴 메시지가 아니다.
번호를 버린 게 후퇴처럼 보이지만, 여기서 힌트가 하나 나온다. 이 시기 커밋을 다시 찾을 때 실제로 쓴 단서는 메시지가 아니라 날짜였다. 그리고 2025년 6월 커밋의 메시지가 25_06 이다. 처음으로 날짜가 버전 자리에 들어왔다.
3기 — 날짜를 쓴다
2026년 1월 재시작 직후에는 아직 과도기였다. 26.0.1 ~ 26.0.8 처럼 연도 뒤에 일련번호를 붙였고, 2월에는 26.2.5.2 · 26.2.6.1 ~ 26.2.6.7 처럼 자리가 네 개까지 늘어난다. 하루에 열 번 커밋하면서 번호가 감당이 안 된 것이다.
2026년 3월 7일부터 연.월.일 로 고정했다.
| 메시지 | 뜻 |
|---|---|
26.3.7 | 2026년 3월 7일 |
26.4.4 | 2026년 4월 4일 |
26.4.28.2 | 4월 28일의 두 번째 커밋 |
26.8.3.3 | 8월 3일의 세 번째 커밋 |
규칙은 두 줄이면 끝난다. 메시지는 그날 날짜다. 같은 날 또 커밋하면 뒤에 순번을 붙인다. 외울 것도, 판단할 것도 없다.
어긋난 두 건, 그리고 이 방식의 한계
규칙을 정한 뒤의 커밋 29개를 전부 검사해 봤다. 메시지의 날짜와 실제 커밋 날짜를 비교하는 것이다. 두 건이 어긋난다.
커밋일 2026-07-26 메시지 26.7.27
커밋일 2026-08-02 메시지 26.8.1둘 다 자정 언저리에서 생긴 것이다. 자정 직전에 커밋하면서 다음 날 날짜로 적기도 했고, 반대로 자정을 넘겨 커밋하면서 작업한 날짜를 그대로 적기도 했다. 날짜는 하나인데 "작업한 날"과 "커밋이 찍힌 날"이 갈리는 구간이 있고, 거기서는 결국 사람이 판단하게 된다.
그래서 이 방식이 완벽한 건 아니다. 다만 어긋났다는 사실 자체가 드러난다는 게 다르다. 메시지가 날짜라서 커밋 메타데이터와 나란히 놓기만 하면 차이가 보이고, 보이면 이유를 설명할 수 있다. 1.4.2 를 1.4.3 으로 잘못 적었다면 대조할 바깥 사실이 없어서 어긋났는지조차 알 수 없다.
버전은 어떤 질문에 답해야 하나
| 묻고 싶은 것 | semver 로 | 날짜로 |
|---|---|---|
| 이 배포가 언제 것인가 | 모른다 | 메시지가 곧 답 |
| 라이브가 최신인가 | 번호를 어딘가와 대조 | 오늘 날짜와 비교 |
| 어디까지 되돌릴까 | 번호 순서만 | 그날 무엇을 했는지와 함께 |
| 업그레이드해도 안 깨지나 | 이게 semver 의 목적 | 답 못 함 |
마지막 줄이 중요하다. 날짜 방식이 semver 보다 나은 게 아니다. 라이브러리를 배포한다면 semver 가 유일한 답이다. 쓰는 쪽이 "올려도 되나"를 판단해야 하고, 그 판단을 번호로 전달하는 게 semver 의 일이기 때문이다.
이 저장소는 그 상황이 아니다. 여기서 버전을 보고 실제로 하는 일은 하나뿐이다 — "지금 라이브에 올라간 게 언제 것인가." 배포가 반영됐는지 확인할 때도, 어디로 되돌릴지 고를 때도 이 질문 하나를 한다.
커밋 간격도 이 방식과 맞는다. 2026년 3월 7일부터 지금까지 커밋 29개, 간격 중앙값이 5일이다. 하루에 여러 번 몰아치던 1월·2월과 다르다. 닷새에 한 번씩 손대는 저장소에서 날짜는 충분히 촘촘한 식별자다.
정리
2021년에 번호를 안 지킨 걸 오래 게으름으로 기억하고 있었다. 로그를 다시 읽어 보니 그게 아니었다. 지킬 근거가 없는 규칙을 가져다 쓴 것이고, 근거가 없으면 규칙은 반드시 흐트러진다. 0.6.0 다음에 0.5.5 가 나온 건 실수가 아니라 그 규칙이 아무 역할도 안 하고 있었다는 증거다.