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

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

< 1 > 소개 — 무엇을 시도했고, 왜 했나

7월 한 달, 내 습관 지표는 이상했다. 달리기·영어·간헐적 단식·풀업은 전부 정상 궤도인데 최우선 항목인 수면만 역행하고 있었다. 7월 평균 6.52시간, 6월(7.13시간)보다 0.6시간이 줄었다. 8월 1일 밤엔 블로그 발행 작업이 늘어져 새벽 02:30에 잤다.

원인을 찾다 보니 문제는 의지가 아니었다. 구조가 없었다.

• 취침·영어·달리기 기록이 노트 곳곳에 흩어져 있었다 (영어는 맨 아래 Notes에 처박혀 있었다)

• 할 일이 4곳에 분산돼 "몇 번 먼저 해"라는 지시 자체가 불가능했다

• Gmail은 "읽지 않은 메일 106개"라는 숫자 하나만 보여줬다 — 관리 불능 상태

• 주간 노트는 길고 성실했지만, 읽고 나서 다음 주에 무엇을 할지가 정해지지 않았다

그래서 "노트를 예쁘게 만들자"가 아니라 "노트가 내 대신 판정하고, 나에게 결정을 요구하게 만들자"로 목표를 잡았다. 매일 여는 파일은 하나뿐이고, 그 화면의 질이 하루의 실행 질을 결정하기 때문이다.

< 2 > 진행 방법 — 도구와 3막의 흐름

사용한 도구

• 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 — 좋은 습관 설계는 "뒤에 무엇이 오는가"를 정하는 일

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

반대로 그 전날 블로그 작업이 새벽 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 삭제" 한마디로 정확한 메일이 휴지통으로 간다.

< 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)

• 지피터스 23기 「나만의 반려 에이전트 만들기」 스터디 — "인간이 병목이다"라는 문제의식이 이 시리즈 전체의 배경

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

< 6 > 관련 노트

• [[260808-노트를-결정장치로-바꾼-6일-데일리v2-위클리v2-전체본]] — 이 글의 전체본 (엔진 설계·테스트 목록·검증 로그 포함)

• [[260807(금)-3-Weekly-Note-v2-의사결정-시스템-구현과-운영전환-전-검증정지]]

• [[260802(일)-2-데일리-노트-v2-개편-넘버링-좌표계와-메일-다이제스트]]

• [[260802(일)-1-하루-루틴-재설계-22시45분-취침-기준-3개층-10개파일-동기화]]

• [[260804-승인버튼-1029번-AI에이전트-울타리형-YOLO-3일-축약본]] — 같은 시기, 에이전트 권한 울타리를 다룬 선행 지피터스 사례