← 평가·검증

27일에 커밋일은 10일, 세션 인덱스에는 하루만 잡혔다

한 프로젝트의 27일 구간을 커밋 원장과 세션 인덱스 두 집계기로 각각 세어 보고, 밀도 수치에 집계 범위 라벨을 붙이지 않으면 무엇이 사라지는지 실측으로 확인한 기록

목차
  1. 문제
  2. 27일, 커밋이 찍힌 날은 10일
  3. 9일 공백에 남은 세 날
  4. 세션 인덱스는 하루만 봤다
  5. 다른 프로젝트에서는 0이 나왔다
  6. 결론
  7. 한계·재검토 트리거

27일 동안 굴린 프로젝트에 커밋은 29건 남았고, 그 커밋이 찍힌 날은 10일이다.
같은 구간을 세션 로그로 다시 재면 세션은 4건이고 전부 하루에 몰려 있다.

문제

활동이 얼마나 있었는지 말해야 할 때 가장 먼저 손에 잡히는 것이 커밋 그래프다.
날짜별로 칸이 차거나 비고, 세는 데 비용이 들지 않는다.
세션 로그도 그 옆에 놓인다. 언제 몇 번 붙었는지가 파일로 남는다.
둘 다 기계가 남긴 기록이라 사람 손을 타지 않은 것처럼 보인다.

기계가 정직한 것과 기계가 전부를 보는 것은 다른 문제다.
집계기마다 시야가 있고, 그 시야는 수치 옆에 적히지 않는다.
커밋 원장은 리포에 커밋이 만들어졌을 때만 칸을 채우고, 세션 인덱스는 자기 런타임이 연 세션만 줄로 남긴다.
그래서 한 프로젝트를 두 집계기로 각각 세어 봤다. 같은 27일을 두고 값이 얼마나 벌어지는지, 벌어진 구간에 무엇이 있었는지를 본다.

27일, 커밋이 찍힌 날은 10일

이 리포의 생애는 첫 커밋에서 마지막 커밋까지 27일이고 커밋은 29건이다.
커밋이 찍힌 날은 10일뿐이다.
자정이 아니라 오전 6시를 작업일 경계로 잡는 규칙을 적용해도 날짜 목록의 일부만 바뀌고 합계는 10일로 같다.
경계 규칙을 바꿔도 값이 움직이지 않는다는 것은 이 10이 새벽 작업이 만든 착시가 아니라는 신호다.

그 10일도 균등하지 않다.
첫 사흘에 상품 전체가 만들어졌다. 3계층 전략, 프롬프트 라이브러리 배포 두 벌, 45엔트리짜리 킷, 티저, 커리큘럼, 4시간 덱 26장, 감사 3기까지 72시간 안에 끝났다.
남은 24일은 검증과 마감이었다. QR 디코드 확인, 2시간 덱, 무료 티어 한도 실측, 고객용 GPT, 결함 QA.
커밋 29건을 27일로 나눈 평균은 이 프로젝트의 어느 하루도 설명하지 못한다.

구간의 끝도 커밋이 정했다.
내용 작업의 마지막 날은 08-11이고, 08-18에 찍힌 것은 에이전트 세션 부산물을 추적 대상에서 빼는 위생 커밋 하나다.
27일이라는 폭의 마지막 한 주를 그 한 건이 끌고 있다.
구간을 커밋으로 여닫으면 시작과 끝이 둘 다 커밋의 성격에 좌우된다.

9일 공백에 남은 세 날

커밋 기준으로 07-24와 08-02 사이에 9일 공백이 있다.
그 구간의 기록에는 세 날이 남아 있다. 07-25에 인수인계 문서의 깨진 경로를 고치고 리포 전수를 재검증했고, 07-27에 미커밋분을 전수 정리했고, 07-31에 세션을 다시 열어 인수인계 준비를 했다.
커밋 원장이 이 아흐레를 비워 둔 이유는 단순하다. 셋 중 어느 것도 리포의 파일을 바꾸지 않았다.
검증은 상태를 확인하는 일이고, 정리는 이미 추적 대상에서 빠진 파일을 확인하는 일이었다.
원장에 흔적을 남기려면 파일이 바뀌어야 하는데, 확인하는 작업은 파일을 바꾸지 않는다.
커밋 그래프에서 이 아흐레는 완전한 빈칸이고, 그 빈칸을 만든 것은 그 사흘에 한 작업의 종류다.

세션 인덱스는 하루만 봤다

커밋이 못 세는 것을 세션 로그가 대신 세줄 것 같다.
이 프로젝트에서 Claude Code 세션 인덱스에 잡힌 세션은 4건이고, 전부 2026-08-04 하루에 몰려 있으며 크기도 25~28KB에 12줄짜리다.
같은 리포 안에는 다른 코딩 에이전트 런타임 두 종(GJC와 senpi)이 남긴 세션 디렉터리가 33개 있고, 그 디렉터리들의 갱신 시각은 07-31부터 08-10까지 열흘에 걸친다.
이 트랙의 주 런타임은 인덱스에 집계되지 않는 쪽이었다.

집계기무엇을 세는가이 구간의 값시야 밖
커밋 원장리포에 커밋이 만들어진 사건27일 중 커밋일 10일, 커밋 29건파일을 바꾸지 않은 검증·정리·인수인계 준비
Claude Code 세션 인덱스그 런타임이 연 세션의 메타데이터세션 4건, 전부 2026-08-04다른 런타임의 세션 디렉터리 33개(갱신 시각 07-31 ~ 08-10)

세션 히스토그램을 그리면 이 프로젝트는 8월 4일에 하루 반짝했다가 사라진 트랙으로 보인다.
같은 구간을 리포 안쪽에서 세면 열흘에 걸친 33개가 나온다.
한 집계기가 4를, 다른 집계기가 33을 내놓는데 둘 다 정확하다.
서로 다른 모집단을 세고 있기 때문이다.
히스토그램은 자기가 4만 볼 수 있다는 사실을 그래프 안에 적지 않는다. 그 사실은 리포 안쪽을 따로 열어 봐야 나온다.

다른 프로젝트에서는 0이 나왔다

같은 편향을 다른 프로젝트에서도 봤다.
그쪽은 사업 라인 둘을 각각 다른 런타임에서 굴렸고, 그래서 세션 인덱스에 한 건도 잡히지 않는다.
그 프로젝트의 세션 사료는 리포 안의 런타임별 세션 디렉터리뿐이다.
0은 일이 없었다는 뜻으로 읽히기 가장 쉬운 숫자인데, 여기서 그 0이 말하는 것은 집계기가 그 런타임을 보지 못한다는 사실 하나다.
기록 체계가 시작되기 전에 끝난 프로젝트의 빈칸은 또 다른 종류의 빈칸이고, 이 글은 그쪽까지 다루지 않는다.

결론

커밋 밀도와 세션 밀도는 두 집계기가 각각 볼 수 있었던 것의 밀도다.
커밋 원장은 커밋을 세고, 세션 인덱스는 특정 런타임의 세션을 센다. 둘 다 활동을 세지 않는다.
그러니 밀도를 주장할 때는 숫자보다 먼저 집계 범위를 적는다. 무엇을 세는 원장인지, 어느 구간인지, 어느 런타임까지 시야에 들어오는지.
라벨이 붙지 않은 밀도 수치는 하한값 프록시로만 읽는다.

라벨은 길 필요가 없다. 이 리포의 커밋 원장 기준, Claude Code 세션 인덱스 기준이면 족하다.
붙이는 비용이 괄호 한 쌍인데, 빼먹으면 27일이 10일로 줄고 열흘이 하루로 줄어든다.

한계·재검토 트리거

2026-09 기준 / 재검토 트리거: 세션 인덱스가 다른 런타임의 세션까지 집계하도록 바뀌거나, 같은 리포를 커밋 원장과 런타임별 세션 디렉터리로 다시 세어 커밋일 10일 또는 세션 디렉터리 33개라는 값이 달라지면 이 글의 판정을 다시 잰다.