# 노트에게 "결정"을 시켰다 — 22:45 취침 원칙에서 Weekly 의사결정 시스템까지, 6일간의 PKM 3층 개편

- 작성자: [느낌표](https://community.clauders.ai/member/imported-member-mTrfUN0iC1)
- 공간: [에이전트 / 노코드 자동화](https://community.clauders.ai/automation)
- 게시: 2026-08-08
- 연재: [나만의 반려 AI 에이전트](https://community.clauders.ai/series/personal-companion-agent-setup) 2/2편
- 태그: #반려에이전트
- 주소: https://community.clauders.ai/automation/post/%EB%85%B8%ED%8A%B8%EC%97%90%EA%B2%8C-%EA%B2%B0%EC%A0%95-%EC%9D%84-%EC%8B%9C%EC%BC%B0%EB%8B%A4-22-45-%EC%B7%A8%EC%B9%A8-%EC%9B%90%EC%B9%99%EC%97%90%EC%84%9C-weekly-%EC%9D%98%EC%82%AC%EA%B2%B0%EC%A0%95-%EC%8B%9C%EC%8A%A4%ED%85%9C%EA%B9%8C%EC%A7%80-6%EC%9D%BC%EA%B0%84%EC%9D%98-pkm-3%EC%B8%B5-%EA%B0%9C%ED%8E%B8-53dcd060-1264-8c77-9e35-aa3299ee36ca

---

> **요약**: 2026년 8월 2일부터 7일까지 엿새 동안, 내 PKM(개인 지식관리) 시스템을 세 번에 걸쳐 다시 지었다. ① 하루의 기준값을 **22:45 취침 제1원칙**으로 확정하고, ② 매일 여는 데일리 노트를 **말로 조작하는 4블록 구조**로 바꾸고, ③ 주간 노트를 활동 보고서에서 **다음 주를 결정하는 시스템**으로 바꿨다. 세 작업을 관통한 교훈은 하나였다 — **"기록했다"와 "작동한다"는 완전히 다른 상태다.** 프로필 4곳에 완벽히 적어놓고도, 그 값을 읽는 스크립트를 안 고쳤다면 매일 아침 옛 기준이 찍힌 노트를 받았을 것이다.

### **사용한 도구**

- **Claude Code** (내 에이전트 "심클코") — 설계 대화, 코드 수정, 서브에이전트 일괄 검토
- **Hermes** (분석 에이전트 "심프로") + `weekly-note-review` 스킬 — 계산된 사실의 _해석_ 담당
- **Python 자동화 3종** — `create_week_notes.py`(템플릿 단일 원천), `daily-note-morning/update.py`(매일 05:55), `weekly-review/update.py`(주간 집계)
- **Gmail API** (`gmail.py`) — 메일 다이제스트·다중 휴지통 이동
- **Telegram 봇** — 주간 결정을 번호로 회신받는 채널
- **Obsidian + 위키링크** — 노트 저장소, `<!-- -->` 숨은 주석을 데이터 채널로 활용
- **pytest / py_compile / grep** — 18개 테스트, 문법 검증, 옛 기준값 전수 수색

### **엿새의 흐름 (3막)**

```
[8/2 일 오전]  1막 — 기준 확정
  "새벽 루틴 좀 적어줘" → 대화가 하루 전체 설계로 번짐
  22:45 취침(제1원칙) / 05:55 기상 / 22:25 화면 하드 스톱 확정
  "이게 정상 작동하냐?"는 질문 하나 → 3개 층 10개 파일 동기화

[8/2 일 오후]  2막 — 화면 개편 (동시 세션)
  데일리 노트 14개 섹션 → 4블록 구조
  넘버링 좌표계 + 메일 다이제스트 도입
  자동화 6종 + 스킬·커맨드 14개, 총 20개 파일 동기화

[8/7 금 밤]   3막 — 결정 시스템
  Weekly Note를 "활동 보고서"에서 "다음 주 결정 시스템"으로 재설계
  결정론적 집계 엔진 + 18개 테스트 통과
  ★ 그러나 Telegram 전달·운영 전환은 완료로 기록하지 않음 (검증 정지)
```

### **시스템 구조 — 4개 층이 같은 기준값을 읽는다**

```
[① 선언 층]  ~/.claude/CLAUDE.md · Hermes USER.md · daily-routine.md
                   │  기준값: 22:45 취침 / 7시간 10분 / 풀업 월·수·금
                   ▼
[② 실행 층]  create_week_notes.py  (템플릿 단일 원천 · 주 1회 7개 노트 생성)
             daily-note-morning/update.py  (매일 05:55 자동 실행)
                   │  기준값을 읽어 노트를 만들고 채운다
                   ▼
[③ 화면 층]  Daily Note v2
             🎯 핵심 표 → ✅ 넘버링 할 일 → 📧 메일 정리 → 📝 로그·회고
                   │  7일치 사실이 쌓인다
                   ▼
[④ 결정 층]  weekly-review/update.py  (계산: 결정론적 집계)
             Hermes weekly-note-review  (해석: Big 3 초안 작성)
                   │  Telegram 번호 응답 → 확정 / 변경 / 보류
                   ▼
             다음 주 Daily 할 일로 주입 → 다음 Weekly에서 실제 수행을 검증
```

### **핵심 1 — 번호는 목록의 장식이 아니라 대화의 좌표다**

"할 일에 넘버링을 붙여줘"라는 요청의 본질은 예쁜 목록이 아니었다. 나는 주로 **음성으로** 에이전트에게 지시한다. 그러니 필요한 건 **짧게 발음할 수 있는 주소**였다.

**자릿수 = 계층 깊이**, 구분자 없음:

```
1 ✍️ 글쓰기
  11 구례의 봄길 3부작
     111 3편 초고 다듬기
2 🤖 AI 프로젝트
  21 Weekly Note v2
     211 Telegram 시험 발송 1회
3 📖 책읽기
  31 『코스모스』 (p.0/719 · 일일 25쪽)
4 📌 일반
```

- **"이일일 완료"** → 체크 + 로그에 `- 21:05 ✅ (211) Telegram 시험 발송 1회` 자동 기록
- **"이일 맨 위로"** → 그룹 내 재정렬 + 프로젝트 README의 `priority` 필드까지 갱신

마지막 한 줄이 중요하다. 그날 노트만 바꾸면 **다음 날 아침 자동 생성 때 씻겨나간다.** 우선순위를 영속시키려면 생성기가 읽는 곳에 써야 한다.

그리고 **카테고리 번호를 1·2·3·4로 고정**했다(매일 같아야 근육기억이 된다). **한 계층 최대 9개** 제한도 걸었다. 이건 모호성 제거 장치인 동시에 **"오늘 할 일은 유한하다"는 강제 선언**이다 — 제한이 곧 기능이다.

### **핵심 2 — 좋은 습관 설계는 "뒤에 무엇이 오는가"를 정하는 일**

확정한 규칙 중 잘 작동하는 것들의 공통점은 **뒤에 물리적 다음 일정이 버티고 있다**는 점이었다.

블록

강제 종료 장치

20:00~21:00 AI 공부

21:00 집안 정리

19:00~20:00 저녁식사

20:00 간헐적 단식 시작

22:00~22:25 마무리

**22:25 화면 하드 스톱(예외 없음)**

반대로 그 전날 블로그 작업이 새벽 2시 반까지 무너진 이유는 **뒤에 아무것도 없었기 때문**이다. 블로그·AI 공부 같은 **열린 결말형 작업은 끝나는 시각을 작업이 정한다.** 그래서 블로그를 화·목 저녁과 주말 오전으로 옮기고 **22시 이후 전면 금지**로 못 박았다.

한 가지 더. 22:00~22:25에 **종이책**을 배치한 건 독서량 확보인 동시에 수면 유도 장치다. 같은 시간에 화면 공부를 넣으면 하드 스톱을 지켜도 뇌가 각성된 채 침대에 들어간다. **무엇을 하느냐보다 어디에 넣느냐가 중요할 때가 있다.**

### **핵심 3 — 기록 없음과 실패는 다르다**

Weekly 집계 엔진에서 가장 신경 쓴 규칙이다. Daily에 수면 값이 없다고 0으로 집계하면 **실제보다 나쁜 주간**이 만들어진다.

```
# 결측을 0으로 만들지 않는다 — 사실의 부재와 실패는 다른 상태다
def summarize_sleep(minutes_list):
    if not minutes_list:
        return "기록 없음"          # ← 0분이 아니다
    return f"{sum(minutes_list) // len(minutes_list)}분"
```

이렇게 해야 **"실제로 못 잔 것"과 "기록을 안 한 것"**을 구분할 수 있다. 실제로 W32 dry-run에서 취침 기록 5일 / 수면시간 기록 3일이 나왔는데, 이 구분이 없었으면 "수면 붕괴"라는 잘못된 결론이 나왔을 것이다.

### **핵심 4 — 자동 영역과 사용자 영역을 물리적으로 나눴다**

Weekly 노트에서 자동화가 관리하는 부분은 `<!-- AUTO:... -->` 마커로 감쌌고, `## ✍️ 나의 주간 회고`**는 마커 밖의 사용자 소유 영역**으로 뒀다. 같은 입력으로 재실행하면 결과가 `unchanged`로 뜨고, 내가 중간에 끼워 넣은 회고 문장은 그대로 보존된다 — 이걸 테스트로 못 박았다.

같은 아이디어를 데일리에도 썼다. 주간 러닝 표를 지우면서 자동 동기화가 깨질 뻔했는데, `<!-- PLAN:easy-5k -->` 같은 **숨은 HTML 주석**으로 해결했다. Obsidian 화면에는 안 보이지만 자동화는 읽는다. 메일 다이제스트의 `<!--gm:메시지ID-->`도 같은 원리다 — 그래서 **"M3 삭제"** 한마디로 정확한 메일이 휴지통으로 간다.

### **정량 결과**

항목

전

후

데일리 노트 섹션 수

14개 안팎

**4블록 + 접힌 콜아웃 1개**

할 일 위치

4곳 분산

**1곳** (카테고리 4개 · 전 항목 번호 보유)

메일

숫자 1개("106개")

**중요/삭제 후보 분류 리스트 + 번호 조작**

취침 기준값

`22~23시` / `7~8시간`

**22:45 / 7시간 10분**

발견한 옛 기준값

—

**10곳** (1차 grep 7 + 2차 대조 3)

동기화한 파일

—

루틴 **10개** + 데일리 v2 **20개**

Weekly 자동 테스트

0

**18개 작성·전부 통과**

Weekly 구조

활동 나열

**11개 섹션 + Big 3 · 하지 않을 일 · 내가 결정할 것**

**Weekly Big 3에는 번호와 제약조건을 붙였다.** Big 3는 `51·52·53`, 하지 않을 일은 `61·62`, 내가 결정할 것은 `71·72`. 그리고 Big 3 하나하나가 이 다섯 항목을 갖도록 강제했다.

```
51 Weekly v2 운영 전환 완료
   목적       : 주간 결정이 Daily 실행으로 실제 연결되는지 확인
   완료 조건   : 일요일 20:00 cron이 노트 생성 + Telegram 전달 성공 로그 1건
   첫 행동     : 종료되지 않은 격리 cron 실행 정리 (한 동작)
   실행 시점   : 8/9(토) 20:00~21:00
   축소안      : 수면·가족과 충돌 시 "Telegram 시험 발송 1회"까지만
```

특히 **22:45 취침은 Big 3와 같은 순위의 목표가 아니라, 다른 계획을 제한하는 선행 조건**으로 뒀다. 생산성 목표와 수면을 같은 줄에 놓으면 언제나 수면이 진다.

### **배운 점 (5가지)**

**1. "기록했다"와 "작동한다"는 다른 상태다 — 선언은 프로필에, 실행은 코드에 산다**

이번 엿새의 핵심 교훈. 프로필 4곳에 새 루틴을 완벽하게 적어놓고 "다 기록했습니다"라고 보고했다. 그런데 `create_week_notes.py`(데일리 노트 템플릿의 단일 원천)를 열어보니 목표값이 `22:45 (22~23시)` / `7~8시간`으로 남아 있었다.

**그대로 뒀다면 내가 새 루틴을 지켜도 노트는 옛 기준으로 판정했을 것이다.** 매주 자동 생성되는 노트가 매주 옛 목표를 되살렸을 테니, 노트를 손으로 고치는 건 증상 치료였고 생성기를 고치는 게 원인 치료였다.

**2. "0건 확인"은 언제나 "내가 쓴 패턴에 대해 0건"이다**

1차 grep으로 7곳을 고치고 "잔여 0건"이라 보고했다. 회고를 쓰며 2차 대조를 하니 **3곳이 더 나왔다.** 1차 패턴은 시각(`22~23`, `06:20`)만 잡았는데, 같은 사실이 **빈도**(`점심 후 영어`)·**설명문**·**섹션 이름**으로도 흩어져 있었기 때문이다. 검색 패턴은 "무엇이 바뀌었는지 내가 안다"고 가정하지만, 실제로 바뀐 값은 표현마다 얼굴이 다르다.

**3. 구조 개편의 진짜 비용은 템플릿이 아니라 생태계다**

노트 틀을 바꾸는 데는 10분이 걸렸다. 본작업은 **그 틀을 읽고 쓰는 자동화 6종과 스킬 13개를 전부 찾아 맞추는 일**이었다(총 20개 파일). 스킬 정리는 서브에이전트에게 1회 일괄 검토를 시키고 grep으로 전수 검증했다 — 잔여 구형 참조 0건, 의도적 폴백 2건만 남았다. 이걸 안 했다면 스킬 13개가 조용히 옛 구조를 계속 만들어냈을 것이다.

**4. 파일 생성 · 모델 완료 · 스케줄러 성공 · 전달 성공은 전부 다른 상태다**

Weekly v2에서 임시 노트는 생성됐고 구조 검증도 통과했다. 그런데 마지막 확인에서도 cron 실행은 여전히 `running` 상태였다. **산출물이 존재한다는 이유로 "전체 경로 완료"라고 말하면 안 된다.** 실제로 기존 자동화에도 같은 함정이 있었다 — 산출물을 만든 뒤 셸 변수 오류로 종료코드 1이 나던 경로가 있었다.

**5. 프로필은 삶을 따라오지 못한다 — 설계가 아니라 정렬이 필요할 때가 있다**

가장 뜻밖의 발견. 5개월 전(3월)에 쓴 옛 루틴 파일을 열어보니 **오늘 "새로" 정한 두 가지가 이미 적혀 있었다.**

- `출근 차량에서 영어 학습` — 프로필엔 여전히 `점심 후`로 남아 있었다
- `풀업 주3회(월/수/금) 25회 — 늑간근 피로 누적 방지` — 프로필엔 `매일 25회`가 남아 있었다

심지어 7월 운동 분석은 격일 전환 후 골격근이 31.3 → 31.9로 반등했다는 **데이터까지 갖고 있었다.** 몸이 이미 증명한 처방이 프로필에만 반영되지 않았던 것이다. 오늘 한 일은 새로운 설계가 아니라 **실제 삶과 기록의 어긋남을 걷어낸 정렬 작업**에 가까웠다. **새 루틴을 만들기 전에 이미 있는 기록부터 확인하라.**

### **시행착오 (숨기지 않고)**

**시행착오 1 — 완료를 밀어붙이지 않고 멈췄다 (그리고 그게 옳았다)** 8월 7일 밤, Weekly v2의 마지막 관문에서 격리 cron이 끝나지 않았다. 여기서 기존 launchd를 먼저 내리고 새 cron을 등록했다면 **정상 경로까지 잃을 뻔했다.** 그래서 Telegram 시험 전달·운영 cron 등록·기존 경로 비활성화를 전부 **완료로 기록하지 않고** 남은 작업 목록으로 넘겼다. 새 경로가 끝까지 검증되기 전에 옛 경로를 제거하지 않는다 — 이건 원칙으로 굳혔다.

**시행착오 2 — 수면 시스템을 만들면서 정작 22:45를 넘겼다** 아이러니의 정점. 자동화가 수면을 선행 제약조건으로 다루도록 설계하는 그 작업이 22:45 원칙을 침해했다. 기능을 더 붙이는 대신 **현재 상태와 재개 지점을 회고로 남기고 멈추는 것**이 일관된 선택이었다.

**시행착오 3 — Gmail **`category:primary`** 검색을 믿었다가 틀렸다** 프로모션 메일이 primary 검색 결과에 섞여 나왔다. 해결은 검색 쿼리 개선이 아니라 `labelIds`** 직접 분류**였다. API의 편의 기능보다 원시 데이터가 정직하다.

**시행착오 4 — 앞당긴 자동화가 더 늦은 데이터를 기다리게 만들었다** Weekly를 일요일 20시로 앞당겼는데, 그 노트가 21시에 생성되는 달리기 주간 리포트를 참조하고 있었다. 의존성 순서가 뒤집힌 것이다. 리포트가 없으면 **그 주 일일 기록에서 횟수와 거리만 집계**하도록 폴백을 넣어 해결했다. **실행 시각을 바꾸면 데이터 원천도 함께 재설계해야 한다.**

**시행착오 5 — 같은 파일을 동시에 두 세션이 만졌다** 8월 2일 오후, 루틴 기준을 확정하는 세션과 데일리 v2를 개편하는 세션이 같은 시간에 같은 파일들을 건드렸다. 동시 변경 감지 덕에 충돌 없이 두 결정이 한 노트로 합류했지만, 이건 운이 좋았던 쪽에 가깝다.

### **앞으로의 계획**

**단기 (1주)** — 종료되지 않은 cron 원인 규명 후 안전하게 정리 / 테스트임을 명시한 Telegram 시험 브리핑 1회 전달 / 첫 실제 실행에서 `파일 생성`·`모델 완료`·`cron 종료`·`Telegram 전달`을 **각각 따로** 확인

**중기 (1개월)** — 새 경로가 성공한 뒤에만 기존 launchd 비활성화(plist는 롤백용 보존) / Telegram에서 확정된 `51·52·53`을 다음 주 Daily 할 일로 연결하고, **다음 Weekly에서 실제 수행 여부를 다시 검증** / 계층 9개 제한이 실제로 과부하를 걸러내는지 관찰

**장기 (3개월)** — 8월 수면 월평균이 7월(6.52h)·6월(7.13h) 대비 어떻게 변했는지 확인 / 22:25 하드 스톱·22:45 취침 알림을 세션 밖 자동화로 뺄지 결정 / 핵심 표 판정 데이터를 월간 리포트로 연동

## **< 4 > 엿새가 끝나고 남은 것**

가장 중요한 성과는 cron 등록도, 파일 20개 동기화도 아니었다. **경계를 명확히 한 것**이었다.

- **계산과 해석의 분리** — 사실 집계는 결정론적 코드가, 패턴 해석과 Big 3 초안은 모델이
- **자동 영역과 사용자 영역의 분리** — 내 회고 문장은 어떤 재실행에도 지워지지 않는다
- **구현 완료와 운영 완료의 분리** — 테스트 18개 통과는 운영 전환이 아니다
- **선언과 실행의 분리** — 프로필에 적는 것과 스크립트가 읽는 것은 다른 파일에 산다

그리고 마지막 하나. 이 구조에서 **AI는 계획을 일방적으로 제안하지 않는다.** 사실을 모으고, 패턴을 짚고, 선택지를 번호로 정리해서 내민다. 확정·변경·보류는 내가 텔레그램에 숫자 하나로 답한다. 시스템은 그 결정을 **기억하고, 실행에 꽂고, 다음 주에 실제로 했는지 검증한다.**

노트가 나를 설명하는 문서에서, 나에게 결정을 요구하는 장치로 바뀐 지점이 여기다.

## **< 5> 도움 받은 글 / 참고**

- 내 회고 3편 (`30-knowledge/31-reflections/2026/08/`) — 8/2 루틴 재설계, 8/2 데일리 v2 개편, 8/7 Weekly v2 구현
- 선행 사례: **역할별 개인 AI 팀 만들기**(2026-08-02), **승인 버튼 1,029번 — 울타리형 YOLO**(2026-08-04)
- 클로더즈 「나만의 반려 에이전트 만들기」 스터디 — "인간이 병목이다"라는 문제의식이 이 시리즈 전체의 배경

_"기록했다고 작동하는 것은 아니다. 그 값을 읽는 곳까지 따라가야 비로소 시스템이 된다."_ 🌙

## **< 6 > 관련 노트**

- [[260808-노트를-결정장치로-바꾼-6일-데일리v2-위클리v2-전체본]] — 이 글의 전체본 (엔진 설계·테스트 목록·검증 로그 포함)
- [[260807(금)-3-Weekly-Note-v2-의사결정-시스템-구현과-운영전환-전-검증정지]]
- [[260802(일)-2-데일리-노트-v2-개편-넘버링-좌표계와-메일-다이제스트]]
- [[260802(일)-1-하루-루틴-재설계-22시45분-취침-기준-3개층-10개파일-동기화]]
- [[260804-승인버튼-1029번-AI에이전트-울타리형-YOLO-3일-축약본]] — 같은 시기, 에이전트 권한 울타리를 다룬 선행 클로더즈 사례