CMS가 어디까지 됐는지 확인하려고 제 메모를 열었어요. 그리고 한 달 뒤처진 기록을 봤습니다.

하나씩 보면 이래요.

할 일 문서 머리말: "마지막 정리: 2026-10-01" — 실제 마지막 작업은 10-16
로드맵: "백엔드·API 계약 없음, mock 상태" — 그 뒤로 Spring 백엔드가 계약 동작을 전부 구현했고 실서버 계약 검사까지 돌아갑니다
할 일 문서: "공개 저장소 만들기 — 미완료" — 이미 1.0.0 첫 공개 커밋이 있어요

코드는 멀쩡해요. 틀린 건 기록뿐입니다. 그런데 이게 더 위험해요. 다음에 작업을 이어갈 때 제가 읽는 건 코드가 아니라 그 메모니까요.

커밋은 왜 안 썩나

같은 기간의 커밋 로그는 정확했어요. 당연하죠 — 커밋은 작업의 부산물이니까요. 코드를 바꾸면 커밋이 생깁니다. 안 쓰면 작업이 안 끝나요.

상태 문서는 반대예요. 작업이 끝난 뒤에 따로 해야 하는 일입니다. 안 써도 코드는 돌아가고, 테스트는 통과하고, 아무도 안 막혀요. 그래서 안 씁니다.

AI와 작업하면 이 격차가 더 벌어져요. 하루에 끝나는 일의 양이 늘어나는데, 문서 갱신은 여전히 사람이 "지금 해야겠다"고 판단해야 하거든요. 작업 열 개를 한 세션에 끝내면 열 개를 다 기록해야 하고, 그러면 안 합니다.

결과가 이래요. 상태를 커밋 메시지에서 역산해야 하는 구조. 실제로 제가 그걸 했어요. "어디까지 됐지?"를 알려고 커밋 91개를 읽었습니다.

더 아까운 건 다른 거였어요

기록이 뒤처진 건 고치면 됩니다. 그런데 훑다가 알게 된 게 있어요.

커밋은 "무엇을 바꿨는지"는 남기지만 "무엇을 시도했다가 틀렸는지"는 안 남깁니다.

예를 들어 모달 첫 초점을 고칠 때, 저는 KRDS 원본이 왜 350ms를 기다리는지 모른 채 그 줄을 지워봤어요. 초점이 안 들어갔고, 그래서 CSS visibility 전환 때문이라는 걸 알았습니다. 최종 커밋에는 결과 코드만 남아 있어요. "지워봤더니 안 됐다"는 어디에도 없습니다.

그런데 글이 되는 건 그쪽이에요. 결과 코드는 읽으면 알 수 있고, 왜 그 길을 골랐는지는 그때 그 사람만 압니다.

제가 이걸 어떻게 알았냐면 — 블로그 계획을 세우면서 이런 문장을 적게 됐어요.

6~9편은 감사 문서에 없고 컴포넌트 헤더 주석에만 기록돼 있던 소재다.

글감 네 편이 코드 주석에서 발굴됐다는 뜻이에요. 기록하려고 쓴 게 아니라 다음 사람을 위해 쓴 주석이, 두 달 뒤에 글감 창고가 돼 있었습니다. 운이 좋았던 거고, 주석을 안 달았으면 사라졌어요.

그래서 추가한 것 — 작업 기록

문서를 하나 더 만들었어요. 역할을 이렇게 나눴습니다.

문서	담는 것	시점
기술 선택 기록	확정된 선택과 근거	결정했을 때
할 일	할 일과 완료·검증 상태	진행하며
작업 기록	과정·증상·버린 길·수치·개선점	작업하며 (날것)

앞의 둘은 정리된 결과를 담아요. 그래서 "정리할 시간"이 필요하고, 그 시간이 안 나서 썩었습니다.

작업 기록은 반대로 다듬지 않는 걸 규칙으로 했어요. 항목 형식이 이렇습니다.

핵심은 두 줄이에요.

버린 길과 수치·근거가 글을 만듭니다. 이 둘이 비면 아직 글감이 아니에요. 커밋이 절대 안 담아주는 것이 정확히 이 둘이고요.

그리고 지어내지 않는다를 규칙에 박았어요. 수치는 실제로 돌린 결과만 적고, 안 돌렸으면 "미측정"이라고 씁니다. 이건 제가 이미 당해본 거예요 — 예전 기록에 "테스트 91개"라고 적었는데 실제로는 97개였고, "계약 테스트가 요청·응답을 모두 검사한다"고 썼는데 과장이었습니다(호출 안 한 동작·404·405가 빠져 있었어요). 둘 다 나중에 정정 기록을 남겨야 했습니다.

버린 길 — 세션 종료 훅으로 자동 수집

처음엔 자동화를 생각했어요. Claude Code의 세션 종료 훅으로 그 세션에서 한 일을 자동으로 붙이는 방식이요. 사람이 판단할 필요가 없으니 안 썩겠죠.

안 했습니다. 글감이 아닌 작업까지 전부 쌓이니까요. 오타 수정, 의존성 올리기, 빌드 깨진 것 고치기 — 이런 게 섞여 들어오면 나중에 걸러내는 비용이 쓰는 비용보다 커집니다. 100개 중 3개를 찾는 일이 돼요.

그래서 커맨드(/worklog)와 규칙으로 했어요. 쓸 만한 걸 만났을 때 사람이 한 번 판단합니다. 자동이 아니라서 빠뜨릴 수 있는데, 그건 받아들였어요 — 전부 모으고 못 쓰는 것보다 일부 모으고 다 쓰는 게 낫다고 봤습니다.

수치

할 일 문서 체크 항목: 완료 95 · 미완료 28
CMS 마지막 커밋 2026-10-16 14:02, 공개 저장소 첫 커밋 2026-10-16 14:03 — 1분 차이인데 할 일 문서에는 한쪽만 반영돼 있었어요
블로그 계획 문서의 링크 3개가 깨져 있었습니다. 워크스페이스 docs/project-notes/에 있는 노트를 repos/hanui/docs/에서 찾는 경로로 적었더라고요

마지막 건 사소해 보이지만 성격이 같아요. 문서가 가리키는 곳과 실제 위치가 어긋나는데, 아무도 안 막히니까 안 고쳐집니다. 깨진 링크는 빌드를 깨지 않아요.

남은 것

정직하게 적으면, 아직 다 안 고쳤어요. 할 일 문서 머리말과 로드맵의 "백엔드 없음"은 이 글을 쓰는 지금도 옛 상태입니다. 작업 기록을 만들어둔 것과 뒤처진 문서를 따라잡는 건 다른 일이고, 후자는 아직 남아 있어요.

적어두는 이유는 하나예요. "체계를 만들었다"로 끝내면 그게 또 한 달 뒤에 썩습니다.

오늘 정리

커밋은 작업의 부산물이라 안 썩고, 상태 문서는 별도 작업이라 썩어요. AI와 일하면 하루 작업량이 늘어서 격차가 더 벌어집니다.
커밋이 절대 안 담는 두 가지 — 버린 길과 수치. 그게 정확히 나중에 가장 아까운 것이고, 글이 되는 것도 그쪽이에요.
자동 수집은 거르는 비용이 더 클 수 있어요. 전부 모으고 못 쓰는 것보다, 판단해서 일부 모으고 다 쓰는 쪽을 골랐습니다.

본인 프로젝트에서 확인해보실 거라면 하나만 해보세요. 상태 문서 머리말의 날짜와 마지막 커밋 날짜를 비교하세요. 그 차이가 기록이 썩은 기간이에요.

시리즈: 공공 CMS 납품·운영

1편: AI와 한 달 작업하면 기록이 먼저 썩어요 ← 현재 글
2편: GS인증 기능 리스트 147개를 쓰다가 제품을 고쳤어요 (예정)

AI와 한 달 작업하면 기록이 먼저 썩어요 — 커밋은 남는데 상태 문서는 안 남는 이유

공공 CMS 납품·운영 시리즈