작업 타임라인 기록법
“오늘 하루 종일 뭐 했지?”가 저녁마다 떠오른다면, 대부분은 실제로 안 한 게 아니라 기록을 안 한 것이다. 나도 그랬다. 스탠드업에서 어제 한 일을 말하려는데 기억이 안 나서 커밋 로그를 뒤지는 게 일상이었다. 그래서 작업 타임라인을 짧게라도 남기는 습관을 들였고, 이 글은 그 방법 노트다.
거창한 도구는 필요 없다. 텍스트 파일 하나면 된다. 핵심은 “언제”가 아니라 “무엇을·왜”를 남기는 것.
왜 타임라인인가
할 일 목록(todo)과 타임라인은 다르다.
- todo: 앞으로 할 것. 미래 지향. 끝나면 지운다 → 흔적이 안 남는다.
- 타임라인: 실제로 일어난 것. 과거 지향. 지우지 않고 쌓는다 → 회고의 재료가 된다.
todo만 쓰면 “무엇을 하려 했는가”는 남지만 “실제로 무슨 일이 있었는가”는 사라진다. 막힌 지점, 삽질, 우회했던 결정 — 나중에 가장 값진 이 정보들이 todo에는 안 남는다. 타임라인은 이걸 잡는다.
형식: 한 줄이면 충분
무겁게 만들면 안 쓰게 된다. 나는 이 정도로 유지한다.
## 2026-08-21
- 10:20 GP-xxx 시작. 로그인 하단 약관 링크 추가 요청
- 11:05 링크는 붙였는데 클릭이 안 먹음 → 부모 요소 pointer-events 때문
- 11:40 해결. 근데 왜 부모에 그게 걸려있는지 아직 모름 (TODO 확인)
- 14:00 리뷰 코멘트 반영: 상수로 분리
- 15:30 배포 확인 완료
규칙은 세 개뿐이다.
- 시각 + 무엇을 + (막혔으면) 왜. 세 요소면 나중에 복원된다.
- 막힌 순간을 반드시 남긴다. 잘 풀린 건 커밋에 남지만, 막혔다 우회한 건 어디에도 안 남는다. 그게 제일 아깝다.
- 다듬지 말고 그때그때. 나중에 몰아 쓰면 이미 다 까먹었다. 말투가 거칠어도 상관없다.
💡 “왜”가 기억 안 나면 그냥 물음표를 남긴다. “왜 부모에 pointer-events가 걸려있지?” 같은 물음표 하나가 다음날 헤매는 시간을 줄여준다.
어디에 남기나
거창한 노트 앱보다 작업 컨텍스트에 가까운 곳이 유지가 잘 된다.
- 저장소 안에 gitignore 된
WORKLOG.md하나. 코드 옆이라 손이 간다. - 아니면 그날 날짜의 텍스트 파일.
daily/2026-08-21.md. - 커밋 메시지를 성실하게 쓰는 것도 타임라인의 일부다. 실제로 나중에 “이거 언제 왜 바꿨지”를 커밋 로그로 되짚는 일이 많다.
중요한 건 도구가 아니라 문턱을 낮추는 것이다. 열기 귀찮으면 안 쓴다.
이걸로 뭘 하나 — 회고
쌓인 타임라인은 세 군데서 값을 한다.
- 데일리 스탠드업: 어제치 타임라인을 그대로 읽으면 끝. 기억을 쥐어짜지 않는다.
- 주간 회고: 한 주치를 훑으면 “어디서 시간이 샜나”가 보인다. 막힘 표시(→, TODO, ?)가 몰린 지점이 개선 후보다.
- 반복 문제 발견: 같은 종류의 삽질이 여러 날 반복되면 타임라인에서만 드러난다. 커밋 로그는 성공만 남기니까 안 보인다.
특히 회고할 때 나는 “막힘” 표시만 따로 훑는다. 잘 된 건 봐도 배울 게 별로 없고, 막힌 지점에 다음에 아낄 시간이 들어있다.
정리
정리하면 세 가지다.
- todo 말고 실제로 일어난 일을 쌓는다. 안 지운다.
- 막힌 지점과 이유를 남긴다. 모르면 물음표라도. 나중에 제일 자주 들춰보는 게 이거다.
- 형식은 코드 옆 텍스트 파일 한 줄이면 된다. 무거우면 안 쓰게 되니까.
대단한 방법론은 아니다. 안 까먹으려고 몇 줄 적어두는 것뿐인데, “이거 왜 이랬더라” 뒤질 때 이 몇 줄이 커밋 로그보다 빠르다.