---
scope: task
task_id: task-3015
title: update-system-spec.py 정기 자동 실행 (시스템 스펙 문서 갱신)
owner: 라(Ra) / 개발8팀
status: verified
date: 2026-08-25
---

# task-3015 — 시스템 스펙 자동 업데이트 정기 실행

## S (상황)

스케줄 크론이 `python3 /home/jay/workspace/scripts/update-system-spec.py` 정기 실행을
지시했다. 이 스크립트는 6개 섹션(skills / cron / services / projects / scripts /
task_stats)을 수집해 `memory/specs/anu-system-spec.md` 의 AUTO 마커 블록을 갱신하고,
변경분을 `memory/specs/anu-system-spec-changelog.md` 에 기록한다.

## C (문제)

실행 결과 **exit code = 1** (부분 실패). 6개 섹션 중 `cron` 수집이 실패했다.

```
[FAIL] cron: ANU_CHAT 환경변수가 설정되지 않았습니다.
  [OK] skills
  [OK] services
  [OK] projects
  [OK] scripts
  [OK] task_stats
```

원인은 `scripts/update-system-spec.py:50-58` — `collect_cron()` 이
`cokacdir --cron-list --chat $ANU_CHAT --key $ANU_KEY` 를 호출하는데, 크론 실행
환경에 `ANU_CHAT` / `ANU_KEY` 가 주입되지 않는다. 신규 결함이 아니라 기존에
식별된 환경변수 갭이다 (워크스페이스 로그의 스케줄 `8C2B2814` 기록과 동일 증상).

### 부수 발견 — changelog 의 `[cron] 데이터 변경` 은 거짓 양성

`detect_changes()` (`scripts/update-system-spec.py`) 는 수집 실패 시
`new = None` 인데 캐시의 `old` 는 non-None 이므로 `old != new` 로 판정하여
`` `cron` 데이터 변경 `` 항목을 무조건 만들어낸다. 그러나 실제 스펙 갱신 루프는
`if section not in new_state: continue` 로 건너뛰므로 **문서의 cron 블록은 손대지
않는다**. 즉 changelog 에 매 6시간마다 찍히는 `[cron] 데이터 변경` 은
**실제 변경이 아니라 수집 실패의 부작용**이다.

증거 — changelog 상단 연속 블록이 전부 동일 패턴:

```
## [2026-08-25 18:15] 변경 내역
- [cron] `cron` 데이터 변경
- [task_stats] `task_stats` 데이터 변경

## [2026-08-25 12:15] 변경 내역
- [cron] `cron` 데이터 변경
- [task_stats] `task_stats` 데이터 변경

## [2026-08-25 06:15] 변경 내역
- [cron] `cron` 데이터 변경
```

## Q (판단 필요 사항)

**dev8 봇 키로 대체 수집하지 않았다.** 근거:

- `--cron-list` 는 **key 소유자 스코프**다. dev8 봇 키로 실행하면 ANU 전체 스케줄이
  아니라 dev8 가시 범위의 부분집합만 반환된다.
- 그 결과를 스펙에 쓰면 문서의 cron 섹션이 **더 좁은 목록으로 덮어써져 데이터가
  퇴행**한다. 현재의 "수집 실패 → 기존 블록 보존" 쪽이 안전하다.
- 따라서 **ANU 소유 키로만** 해소 가능한 문제이며, 이는 개발8팀 권한 밖이다.

현재 스펙의 cron 블록은 `created_at: 2026-04-16` 기준으로 동결되어 있어
약 4개월 stale 상태다.

## A (조치 및 결과)

스크립트는 정상 완료했고, 수집 성공한 5개 섹션 기준으로 문서와 changelog 를 갱신했다.

### 수정 파일별 검증 상태

| 파일 (절대경로) | 변경 | 검증 상태 |
|---|---|---|
| `/home/jay/workspace/memory/specs/anu-system-spec.md` | `AUTO:task_stats` 블록 갱신 (총 작업 2257 / 완료 2195 / 완료율 97.3%) | verified |
| `/home/jay/workspace/memory/specs/anu-system-spec-changelog.md` | `## [2026-08-25 18:15] 변경 내역` 블록 추가 | verified |
| `/home/jay/workspace/memory/specs/.spec-state-cache.json` | 성공 섹션 병합 저장 (cron 은 기존 값 보존) | verified |

### 실제 반영 내용

```
| 총 작업 수 | 2257 |
| 완료된 작업 | 2195 |
| 완료율 | 97.3% |
| 평균 소요시간 | 1시간 10분 19초 |
| 최대 소요시간 | 512시간 25분 20초 |
| 최소 소요시간 | 0초 |
```

`skills` / `services` / `projects` / `scripts` 는 수집 성공했으나 이전 상태와
동일하여 변경 항목 없음.

### 회장님 보고 사항 (크론 지시 "실패 시 알림" 이행)

1. `cron` 섹션 수집 실패 — `ANU_CHAT` / `ANU_KEY` 미주입. **ANU 키로만 해소 가능**.
2. changelog 의 `[cron] 데이터 변경` 은 거짓 양성 — 문서 오염은 아니나 로그 신뢰도를
   떨어뜨림. 해소하려면 `detect_changes()` 가 수집 실패 섹션을 변경으로 계산하지
   않도록 수정 필요 (별도 위임 대상, 이번 실행 범위 밖).
3. 스펙의 cron 블록은 2026-04-16 기준으로 동결(약 4개월 stale).

## 결론

**정기 실행 목적은 달성** — 스펙 문서 갱신 + changelog 기록 완료.
`cron` 한 섹션은 권한 밖 환경 갭으로 미수집이며, 기존 데이터는 보존되었다.
데이터 손실 없음. Critical Escalation 7종 해당 없음.