회사에 성과관리 플랫폼이 있다.
월마다 프로젝트별로 무슨 일을 했는지 실적을 적어 넣는다. 정해진 계층과 기호 규칙이 있는 양식이다.
처음엔 당연히 그 양식에 맞춰 바로 썼다.
그런데 몇 달 지나서 다시 열어보니 내가 쓴 걸 내가 못 읽겠더라.
양식에 최적화된 글은 사람이 읽으라고 쓴 글이 아니었다. 시스템에 넣으려고 쓴 글이었다.
그리고 더 큰 문제가 있었다. 연말에 한 해를 정리하려고 하니, 재료가 그 양식 안에만 흩어져 있었다.
원본과 출력을 나눴다
프론트엔드에서 하던 걸 그대로 가져왔다.
출력 포맷에 맞춰 원본을 쓰지 않는다. 원본은 사람이 읽기 좋게 쓰고, 출력은 변환한다.
entries/YYYY-MM.md ← 원본. 사람이 읽기 좋은 형식. 상시 적립
│ 변환 (정해둔 규칙에 따라)
▼
sgate/YYYY-MM.md ← 회사 양식 변환본. 그대로 복붙
원본은 내가 읽으려고 쓴다. 무슨 일을 왜 했고 어떻게 됐는지를 문장으로 쓴다.
출력은 시스템에 넣으려고 만든다. 기호와 계층이 회사 양식 그대로다.
이렇게 나누고 나니 두 가지가 동시에 해결됐다.
- 나중에 내가 읽을 수 있다 (원본이 사람 언어니까)
- 회사 양식이 바뀌어도 원본은 그대로다 (변환 규칙만 고치면 되니까)
같은 정보를 두 번 쓰는 게 아니라, 한 번 쓰고 두 가지로 꺼내는 것이다.
블로그가 MDX 하나에서 목록·상세·RSS·사이트맵을 만들어내는 것과 정확히 같은 구조다.
시간축 말고 프로젝트축도 만들었다
월별 파일만 있으면 부족했다.
"이번 달에 뭐 했지"는 답할 수 있는데, **"이 프로젝트를 지금까지 어떻게 끌고 왔지"**는 답할 수 없다.
그건 열두 개 파일에 흩어져 있으니까.
그래서 축을 하나 더 만들었다.
entries/ ← 시간축. 2026-01.md, 2026-02.md, ...
by-project/ ← 프로젝트축. 공과장.md, 불법주정차 통합플랫폼.md, ...
같은 사건이 두 축에 다 들어간다. 중복 같지만 답할 수 있는 질문이 다르다.
- 시간축은 "언제 무엇을" — 월별 보고에 쓴다
- 프로젝트축은 "이 프로젝트가 어떻게 흘러왔나" — 회고나 인수인계에 쓴다
DB로 치면 인덱스를 두 개 건 셈이다.
읽는 패턴이 두 가지면 인덱스도 두 개 있어야 한다는 걸, 문서에서도 똑같이 적용했다.
재료는 이미 있었다 — git
여기서 제일 편해진 부분이다.
월말에 "이번 달에 뭐 했더라"를 기억으로 복원하는 건 어렵다. 그리고 기억으로 쓰면 인상적인 것만 남고 꾸준히 한 건 빠진다.
그런데 재료는 이미 다 있었다. 커밋 로그다.
주 단위로 각 저장소의 변경 이력을 모아오는 스크립트를 만들어서, 그걸 원본 작성의 출발점으로 삼았다.
물론 커밋 로그가 그대로 실적이 되지는 않는다.
fix: 오타 수정 같은 게 성과일 리 없다. 그래서 로그를 그대로 옮기는 게 아니라 주제별로 합치는 단계를 뒀다.
커밋 스무 개가 "검수 보드에서 드래그로 재배정하는 기능 구현" 한 줄이 된다.
그리고 git에 안 남는 일 — 회의, 협의, 문서 작업, 다른 사람 도와준 것 — 은 따로 물어서 채운다.
자동으로 모을 수 있는 건 자동으로, 그 자리에 없는 것만 사람이.
전부 자동화하려고 하면 실패하고, 전부 손으로 하면 안 하게 된다. 그 사이 어딘가가 맞았다.
의외의 이득 — 협상 자료가 저절로 쌓였다
이 구조를 만들 때는 그냥 매달 하는 일을 편하게 하려던 거였다.
그런데 예상하지 못한 이득이 있었다.
연봉 협상 시즌에, 준비할 게 없었다.
이미 프로젝트축 파일에 내가 무엇을 언제 어떻게 했는지가 문장으로 쌓여 있었다.
기억을 쥐어짜서 "제가 이런 걸 했습니다"를 만들어내는 게 아니라, 있는 걸 정리하기만 하면 됐다.
이게 생각보다 큰 차이였다.
기억에 의존하면 최근 두세 달이 과대평가되고 연초에 한 일은 통째로 빠진다.
그리고 사람은 자기가 한 일을 과소평가하는 쪽으로 잊어버린다. 힘들었던 건 기억나는데, 그게 얼마나 많은 양이었는지는 기억이 안 난다.
기록은 그 왜곡을 막아준다.
정리하면
- 출력 포맷에 맞춰 원본을 쓰지 않는다. 원본은 사람 언어로, 출력은 변환으로
- 읽는 패턴이 두 가지면 축도 두 개. 시간축과 프로젝트축
- 자동으로 모을 수 있는 건 자동으로. git 로그를 출발점으로, 없는 것만 사람이
- 로그를 그대로 옮기지 않는다. 커밋 스무 개를 한 줄로 합치는 단계가 필요하다
돌이켜보면 이건 개발에서 쓰던 원칙을 업무 기록에 그대로 옮긴 것뿐이다.
단일 진실원천을 두고, 나머지는 파생시키는 것.
보고를 위해 기록하는 게 아니라, 기록에서 보고를 꺼내는 방향으로 바꾼 것이 핵심이었다.
그리고 이건 회사가 시켜서 하는 일이 아니라 내가 나를 위해 하는 일이라서, 회사를 옮겨도 그대로 남는다.