---
task_id: task-1837_5.3
type: context
scope: task
created: 2026-04-17
updated: 2026-04-17
status: completed
---

# 맥락 노트: task-1837_5.3

**task**: task-1837_5.3

---

## 결정 근거

### task-timers.json 기반 수집 설계
- task-timers.json이 이미 1444개 task의 완료 시간, 팀 ID, 토큰 사용량을 보유
- 별도 DB 없이 JSON 파일 기반으로 M-3(생산성), M-7(비용) 수집 가능
- 대안: SQLite DB → 기각 (기존 생태계와 불일치, 마이그레이션 비용)

### git log subprocess 방식 선택
- Python gitpython 라이브러리 대신 subprocess로 git log 직접 실행
- 이유: 추가 의존성 없음, WORKSPACE_ROOT cwd 지정으로 충분
- shell=False로 명령어 인젝션 방지

### M-4 제외 결정
- 레벨 자동 추정 정확도는 task 파일의 YAML frontmatter level 필드와 task-timers.json의 work_level 비교 필요
- 현재 work_level이 빈 문자열인 task가 많아 의미 있는 데이터 수집 불가
- 운영 데이터 축적 후 별도 Phase에서 구현

## 3 Step Why

### 1st Why: "왜 이 설계가 필요한가?"
→ 시스템 개선의 효과를 정량적으로 측정할 프레임워크가 없으면, 투입 비용 대비 가치를 판단할 수 없다.

### 2nd Why: "왜 지금 미리 지표 정의 + 수집 스크립트를 만드는가?"
→ 운영 후 데이터가 쌓이기 전에 수집 기반을 갖춰야 비교 기준(baseline)이 생긴다. 사후 측정은 기준선 부재로 효과 판별 불가.

### 3rd Why: "왜 JSON 파일 저장 + weekly-report.py 호출 가능 인터페이스인가?"
→ 기존 weekly-report.py 생태계와 일관되고, memory/daily/ 디렉토리에 일별 스냅샷이 쌓여 시계열 분석 가능. 대시보드/분석 도구에서도 JSON을 쉽게 소비 가능.

**A-B-C 일관성 확인**: 정량 측정 필요(A) → 기준선 확보를 위한 선제 구축(B) → 기존 인프라 호환 JSON 인터페이스(C). 논리적으로 일관됨.

## 참조 자료

- task 지시서: `/home/jay/workspace/memory/tasks/task-1837_5.3.md`
- weekly-report.py: `/home/jay/workspace/scripts/weekly-report.py`
- task-timers.json 구조: `/home/jay/workspace/memory/task-timers.json`

## 주의사항

- token_usage 필드가 없는 task가 다수 존재 → .get() 안전 접근 필수
- work_level 빈 문자열 task 다수 → M-4 구현 시 필터링 필요
- git log 실행 시 cwd=WORKSPACE_ROOT 지정 필수 (현재 디렉토리가 다를 수 있음)