---
task_id: task-3035
scope: task
team: dev8
title: anu-system-spec.md 정기 백업 (backup-spec.sh) — 2026-08-27 12:00 회차
date: 2026-08-27
result: success
level: Lv.1
---

# task-3035 — anu-system-spec.md 정기 백업

## 결론

**성공.** 2026-08-27 12:00 KST 회차 백업이 정상 생성됐고 원본과 sha256 완전 일치.
실패 알림 조건에 해당하지 않으므로 회장 장애 알림은 발송하지 않았다.

부수적으로 **보존 구간 내 결번 3건의 원인을 규명**했다 (아래 §3).

## 1. 실행 결과

- 명령: `bash /home/jay/workspace/scripts/backup-spec.sh`
- exit code: **0**
- 산출물: `memory/backups/system-spec/2026-08-27_12/anu-system-spec.md`
- 크기: **34,615 bytes** (원본과 동일)
- 생성 시각: 2026-08-27 12:00:39 KST

### 무결성 검증 (sha256)

원본과 백업본이 **동일 해시**:

```
b264567ad9eb8cd1a4d597da9a98eb8516e059ace8522e0cdc325575ded42259  memory/specs/anu-system-spec.md
b264567ad9eb8cd1a4d597da9a98eb8516e059ace8522e0cdc325575ded42259  memory/backups/system-spec/2026-08-27_12/anu-system-spec.md
```

원본 mtime 은 06:15:43 으로 직전 06:00 백업 **이후** 갱신됐다. 즉 이번 12:00 백업이
그 갱신분(task-3032 의 `update-system-spec.py` 7회차 결과)을 처음 담은 스냅샷이다.

### 보존 정책

`find -mtime +7 -exec rm -rf` 동작. 실행 후 잔존 버킷 **29개**, 디스크 여유 179G (61% 사용).
git status 의 대량 `D memory/backups/system-spec/2026-04-*` 는 사고가 아니라 이 정책의 정상 결과다.

## 2. 스케줄 연속성 점검

6시간 간격(00/06/12/18) 기대 슬롯 대비 실측:

- 보존 구간(08-20 ~ 08-27) 내 **결번 3건**: `2026-08-21_18`, `2026-08-22_00`, `2026-08-26_12`
- (`2026-08-27_18` 은 미래 슬롯이므로 결번 아님)

## 3. ★ 결번 원인 규명 — 두 가지 서로 다른 고장 모드

본 스케줄의 정본 ID 는 **`EE825F5E`** 로 확정했다 (prompt 문자열 완전 일치).
`schedule_history/EE825F5E.log` 전수 분석 결과 (2026-05-06 이래 **442회**, ok 402 / error 40):

### 모드 A — 에이전트 기동 실패 (기록은 남음, status=error)

`2026-08-21T18:00` · `2026-08-22T00:00` 두 건 모두:

```
Error: You've hit your weekly limit · resets 2am (Asia/Seoul)
```

duration 7,083ms / 7,080ms 로 **스크립트에 도달조차 못 했다**. 주간 사용량 한도가
02:00 KST 에 리셋된 뒤 08-22 06:00 회차부터 정상 복구.

### 모드 B — 스케줄 자체 미발사 (기록 없음)

`2026-08-26_12` 은 로그에 **레코드가 아예 없다.** 06:01 → 18:02 로 건너뛴다.
모드 A 와 달리 error 조차 남지 않으므로 로그만 봐서는 무증상이다.
(같은 시각 별개 감시 스케줄 `8C2B2814` 가 12:21 에 "ok" 로 이 부재를 관측한 것이
task-3027 기록의 근거였다. `8C2B2814` 는 감시자이지 실행자가 아니다.)

### 실패 40건 전체 원인 분포

| 원인 | 건수 |
|---|---|
| 401 Invalid authentication credentials | 30 |
| 529 Overloaded | 3 |
| No space left on device (os error 28) | 2 |
| 조직의 Claude 구독 접근 비활성화 | 2 |
| 주간 한도 초과 | 2 |
| 401 socket connection closed | 1 |

월별: 05월 1/103 · 06월 4/113 · **07월 33/124** · 08월 2/102.
7월 급증은 401 인증 실패가 몰린 결과이며 현재는 진정됐다.

## 4. ★ 구조적 관찰 (ANU/회장 판단 몫)

**원인 40건 중 백업 로직에서 비롯된 것은 0건이다.** 전부 인증·쿼터·디스크 등
LLM 에이전트 기동 조건이다. 즉 순수 `cp` 한 줄인 작업이 에이전트 호출 뒤에 놓여
있어, 백업과 무관한 사유로 **9.05% (40/442)** 확률로 스냅샷이 유실된다.

스펙 갱신(`update-system-spec.py`)과 백업(`backup-spec.sh`)은 **독립 스케줄**이라
백업만 조용히 멈춰도 갱신은 정상 동작한다 → 백업 없이 스펙이 덮어써질 수 있다.

판단 대기 사항 (본 작업 범위 밖, 임의 실행하지 않음):
- 백업을 에이전트 경유가 아닌 **시스템 cron/systemd timer 로 승격**할지
- 모드 B(미발사) 를 탐지할 **결번 감시**를 둘지

## 5. 준수 사항

- 결번 버킷(`2026-08-21_18` 등)을 **사후 임의 생성하지 않았다.** 갱신 이후 내용이
  담기면 "실행 전 상태"라는 의미가 뒤집히고 스케줄러 장애를 은폐하기 때문.
- 타 팀 디렉터리 미접근. 코드 변경 0줄 (실행·검증·분석 전용).