# cleanup-large-audio.sh 정기 실행 보고 (2026-08-28 00:31 KST)

- **스케줄**: `0BCB9FBD` — `30 */6 * * *` (6시간마다)
- **실행 스크립트**: `/home/jay/workspace/scripts/cleanup-large-audio.sh`
- **팀**: dev8 (라)

## 1. 실행 결과

| 항목 | 값 |
|---|---|
| DRY-RUN 선행 검증 | 삭제 예정 0건 |
| 실제 실행 | 삭제 완료 **0건** |
| 보호(스킵) | 0건 |
| 보호 대상 running task | task-3025, task-3034 |
| 종료 상태 | 정상 (에러 없음) |

정상 종료했고 지울 대상이 없었습니다. 디스크 여유: 179G free / 466G (61% 사용).

## 2. 독립 실측 (스크립트 자체 보고를 신뢰하지 않고 별도 확인)

- `/home/jay/workspace` 오디오 파일: **0건**
- `/home/jay/projects` 오디오 파일: **0건**
- `/tmp` (스크립트 미검색 영역) 오디오 파일: **0건**

즉 "0건 삭제"는 스크립트 오작동이 아니라 **대상 자체가 존재하지 않음**이 원인입니다.

## 3. ★ 발견 — 이 스케줄은 사실상 no-op 상태

로그(`memory/logs/audio-cleanup.log`) 전수 분석 결과:

- 누적 삭제 이력: **34건**, 전부 `2026-03-25 ~ 2026-03-27` 구간
- 마지막 실제 삭제: **2026-03-27 18:31** → **약 5개월간 삭제 0건**
- 삭제된 34건의 크기 분포: **34건 전부 1MB**
- 대상: 전부 `projects/ThreadAuto/.worktrees/*/output/*.mp3` (TTS 음성)

### 3-1. "대용량" 규칙은 한 번도 발동한 적이 없음
스크립트의 삭제 조건은 두 개입니다.
1. 크기 ≥ 50MB
2. 경과 ≥ 24시간 (크기 무관)

실제 삭제된 34건은 **전부 1MB** 이므로 조건 1(50MB)에 걸린 파일은 **역사적으로 0건**입니다.
지금까지의 정리는 100% 조건 2(24시간 경과)로 이루어졌습니다.
→ 스케줄 이름·프롬프트의 "대용량 오디오 파일 정리"는 실제 동작과 어긋납니다.

### 3-2. ThreadAuto worktree 소멸로 공급원이 끊김
34건 전량의 출처였던 ThreadAuto worktree 산출물이 3월 이후 생성되지 않아
현재 검색 경로 두 곳에 오디오 파일이 물리적으로 존재하지 않습니다.

### 3-3. Whisper 오디오는 이 스크립트 사정권 밖 (기존 기억과 일치)
Whisper 계열은 `/tmp/whisper_yt_*` 에 받고 전사 후 자체 `os.unlink` 하며,
스크립트 `SEARCH_DIRS` 에 `/tmp` 가 없어 애초에 대상이 아닙니다.
이번 실측에서도 `/tmp` 오디오 0건으로 재확인했습니다.

## 4. 판단 필요 (ANU/회장 판단 — 본 실행 범위 밖)

이번 실행은 지시대로 스크립트를 돌린 것이 전부이며, 아래는 **건의만** 하고 손대지 않았습니다.

1. **스케줄 존치 여부** — 5개월째 대상 0건. 6시간마다 전체 워크스페이스를 `find` 스캔하는 비용만 발생.
   유지하려면 최소한 실행 주기 완화(예: 1일 1회) 검토.
2. **명칭/조건 불일치 정정** — "대용량(50MB)" 규칙은 실발동 이력 0. 실제로 도는 건 24시간 규칙뿐.
3. **검색 경로 재검토** — 실제 오디오가 쌓일 수 있는 경로(`/tmp` 등)가 빠져 있어,
   "정리되고 있다"는 안심이 실제 보호와 연결되지 않을 수 있음.

## 5. 결론

- 지시받은 실행: **완료, 정상 종료, 삭제 0건**
- 시스템 이상 아님 (대상 부재)
- 다만 이 스케줄은 현재 **구조적 no-op** 이며, 존치·조건 조정은 판단 대기