2주차 컨텍스트 엔지니어링 + 3주차 루프

[JoyDaheeCha]

민창님 안녕하세요!
2주차와 3주차 과제 함께 리뷰 요청 드립니다
1주차와 달리 좀 많이 헤맸지만..! 덕분에 단순 채팅형을 벗어나서 좀 더 똑똑하게 ai 사용 과정을 설계할 수 있게 되어 기쁩니다!

skill 이 느려서 고민이었는데 랄프 루프로 속도 개선이 많이 되었습니다!

1. 컨텍스트 엔지니어링

1.1 고민한 사항 : 도메인 컨텍스트 주입 고민 -> 사용자마다 다양해질것 같아 일단 보류

• 본 OS 는 "할일을 (1) AI가 자동으로 알맞은 카테고리에 넣어준다 (2) 계획을 세부적으로 짜고 수행을 잊지 않도록 리마인드해준다 (3)할 일을 너무 크게 잡았을 경우 잘게 쪼개도록 AI가 제안해준다"가 처음 컨셉이었습니다. 도메인관점에서는 컨텍스트로 주면 좋을 부분이 잘 떠오르지 않더라

1.2 본 과제에서 적용한 사항: 스킬에서 반복적으로 시간을 잡아먹는 부분을 컨텍스트로 분리

• 일단은 할일메모(plan), 할일 완료처리(done), 할일 리스트업(list)에서 todo의 구조를 하나의 파일을 바라보도록 하여, 매번 각 스킬이 일일히 todo 구조를 분석하지 않도록 개선했습니다.
• OS 로딩시 기본 컨텍스트가 3%, done 스킬 수행시 6% 였는데, 컨텍스트 최적화 후 5%로 줄었습니다 (이 부분은 기존에 OS가 너무 작아서 비교가 어려운게 아닐까 생각했습니다)

2. 루프

2.1 추후 추가로 구현할 루프

시스템 루프는 "반복할수록 시스템을 견고하게 만들어준다"라는 부분이 인상적이었습니다!

• 제 OS는 사용자의 행동 패턴을 분석하여, 사용자가 실행하기 쉬운 단위로 TODO를 기록해주는게 목표이기때문에 추후 이 부분을 시스템 루프로 추가 에정입니다. (예를 들어 사용자가 집청소 라고 적어놓은 부분은 자꾸 미룬다면, 거실, 부엌, 서재 등 각 방별로 청소 todo를 분리)

2.2 본 과제 내 루프 구현사항

• 단순루프

  • 사용자에게 특정 시각에 알럿을 줘서 OS에 할 일 기록하도록 촉진
  • TODO 현황 루프
  • 텔레그램 메시지 감지 루프

• 탐지형 루프: notion 동기화 루프 , 텔레그램 리스너 health 체크,

• 축적형 루프 - 스킬 로그 분석하여 OS 개발시 더 나은 방향 제안

3. 루프 다이어그램

세션 밖에서 스스로 도는 루프들의 동작 순서. 이 OS의 자동화는 설계 원칙
§7의 축으로 갈린다.

• 탐지형(조정) 루프 — "이상·미처리 있나?"를 주기적으로 감지하고 반응 후 잊는다. 잘 돌수록 조용하다.
• 축적형 루프 — 매 반복이 저장소에 한 겹씩 쌓고 나중에 회수한다. write 절반과 read 절반이 쌍을 이룬다.

노드 색상 범례 — 🔵 트리거/진입 · 🟢 정상·성공 · ⚪ 무소음·종료 · 🔴 경보·실패 · 🟡 축적 저장소

---

A · 탐지형(조정) 루프 — crontab 4종

주기 감지 → 반응 → 잊기. 버퍼를 0으로 드레인하거나 데몬을 지킨다. 평상시엔 로그도
알림도 없이 조용하고, 이상이 잡힐 때만 소리를 낸다.

flush-cron — outbox 재동기 · 15분마다

capture가 백그라운드로 던진 Notion 반영이 실패해 outbox에 남으면, 이 루프가 재전송해
"모두 동기" 상태로 수렴시킨다.

flowchart TD
  T(["cron · 15분마다"]):::trig --> R["capture-flush.sh 실행"]
  R --> Q{"outbox 비었나?"}
  Q -->|비었음| Z(["즉시 종료 · 무소음"]):::quiet
  Q -->|잔여 있음| S["Notion 재전송 시도"]
  S --> C{"flushed 있음?"}
  C -->|예| L["flush-cron.log 기록 (건수만)"]:::ok
  C -->|아니오| Z
  L --> Z
  classDef trig fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f;
  classDef quiet fill:#eef2f6,stroke:#94a3b8,color:#475569;
  classDef ok fill:#dcfce7,stroke:#22c55e,color:#14532d;

Loading

watchdog-cron — 데몬 감시 · 10분마다

telegram-listener가 언로드·비정상이면 KeepAlive만으론 조용히 죽는다. 다운을 감지해
폰에 알리고 자동 재시작한다(상태 전이에만 알림 — 디바운스).

flowchart TD
  T(["cron · 10분마다"]):::trig --> H{"state = running?"}
  H -->|healthy| RC{"직전이 down?"}
  RC -->|예 · 복구| N1["복구 통지 발송"]:::ok
  RC -->|아니오| SV["state 저장"]:::quiet
  N1 --> SV
  H -->|down| DB{"down 신규 전이?"}
  DB -->|예| N2["다운 경보 · 디바운스"]:::alert
  DB -->|아니오| RS["kickstart / bootstrap 재시작"]
  N2 --> RS
  RS --> OK{"재시작 성공?"}
  OK -->|예| SV
  OK -->|아니오| LG["로그 · 다음 주기 재시도"]:::alert
  LG --> SV
  classDef trig fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f;
  classDef quiet fill:#eef2f6,stroke:#94a3b8,color:#475569;
  classDef ok fill:#dcfce7,stroke:#22c55e,color:#14532d;
  classDef alert fill:#fee2e2,stroke:#ef4444,color:#7f1d1d;

Loading

digest-cron — 주간 집계 · 매주 일 20:00

할일 현황(상태 분포·카테고리·방치 draft)을 주 1회 요약해 폰으로 보낸다.
집계(결정론)와 발송(부작용)을 분리한다.

flowchart TD
  T(["cron · 매주 일 20:00"]):::trig --> A["digest-report.sh 집계"]
  A --> B{"요약 텍스트 있나?"}
  B -->|없음| Z(["스킵"]):::quiet
  B -->|있음| S["telegram-send.sh 발송"]
  S --> R{"발송 성공?"}
  R -->|성공| L1["digest-cron.log · 성공"]:::ok
  R -->|실패| L2["로그 · 스킵 (자격/네트워크)"]:::alert
  classDef trig fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f;
  classDef quiet fill:#eef2f6,stroke:#94a3b8,color:#475569;
  classDef ok fill:#dcfce7,stroke:#22c55e,color:#14532d;
  classDef alert fill:#fee2e2,stroke:#ef4444,color:#7f1d1d;

Loading

remind-cron — draft 재촉 · 매일 17:00

미처리 draft가 남아 있으면 매일 저녁 폰으로 리마인더를 쏜다. 세션 안 스킬(/remind)을
세션 밖 cron이 대신 호출한다.

flowchart TD
  T(["cron · 매일 17:00"]):::trig --> C["claude -p /remind"]
  C --> D["draft 항목 조회"]
  D --> Q{"미처리 draft 있나?"}
  Q -->|있음| S["telegram 리마인더 알럿"]:::ok
  Q -->|없음| Z(["조용히 종료"]):::quiet
  classDef trig fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f;
  classDef quiet fill:#eef2f6,stroke:#94a3b8,color:#475569;
  classDef ok fill:#dcfce7,stroke:#22c55e,color:#14532d;

Loading

---

B · 상시 데몬 루프 — launchd

cron처럼 깨었다 자는 게 아니라 launchd가 상시 띄워 둔다. getUpdates를 long-poll로 걸어
폰 명령이 오는 즉시 처리하고, 보안 3종(chat_id 화이트리스트 · 명령 화이트리스트 ·
eval 미사용)을 통과한 것만 실행한다.

telegram-listener — 인바운드 long-poll · 상시(KeepAlive)

flowchart LR
  B(["launchd 상시 데몬"]):::trig --> P["getUpdates long-poll · 25초"]
  P --> M{"메시지 도착?"}
  M -->|타임아웃| P
  M -->|도착| W1{"chat_id 화이트리스트?"}
  W1 -->|불일치| SK["스킵"]:::alert
  W1 -->|일치| W2{"허용 명령? (/capture /list /plan)"}
  W2 -->|아니오| RJ["거절 안내"]:::alert
  W2 -->|예| EX["로컬 스킬 실행 · eval 미사용"]:::ok
  EX --> RE["응답 발송"]
  RE --> OF["offset 전진 · 저장"]
  SK --> OF
  RJ --> OF
  OF --> P
  classDef trig fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f;
  classDef ok fill:#dcfce7,stroke:#22c55e,color:#14532d;
  classDef alert fill:#fee2e2,stroke:#ef4444,color:#7f1d1d;

Loading

---

C · 축적형 루프 — 자기 관찰

이 레포의 유일한 순수 축적형 루프. 스킬을 부를 때마다 append-only 로그에 한 겹 쌓고(write),
나중에 /usage가 그 축적물을 회수해 사용 패턴을 낸다(read). 저장소는 커질수록 가치가 있어
드레인하지 않는다.

self-observation — PostToolUse 훅 → /usage

flowchart LR
  K["Skill 툴 실행"]:::trig --> HK["PostToolUse 훅 (log-skill-invocation)"]
  HK --> AP["한 줄 append · 시각 · #N · 스킬명"]
  AP --> LOG[("skill-invocations.log · append-only")]:::store
  LOG --> RD["/usage 호출"]:::trig
  RD --> AN["로그 분석"]
  AN --> OUT["자주쓰는 · 연쇄 · 유휴 스킬 표시"]:::ok
  classDef trig fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f;
  classDef ok fill:#dcfce7,stroke:#22c55e,color:#14532d;
  classDef store fill:#fef3c7,stroke:#f59e0b,color:#78350f;

Loading

---

출처 · .claude/hooks/{flush,watchdog,digest,remind}-cron.sh · telegram-listener.sh ·
log-skill-invocation.sh · 스케줄 launchd/install.sh · 분류 축 context/design-principles.md §7

[MinCha]

@JoyDaheeCha

2,3주차 과제 잘 보았습니다! 또한, 구조를 잡으며 긍정적인 부분을 보고 계신 것 같아 강사로서 기쁘네요. 랄프 루프로 성과도 내셨다니 보기 좋습니다.

1. 금주부터 과제 평가는 AI가 담당하고 있어 평가 테이블을 공유드리오니 참고 부탁드려요. (2,3주차 모두)

완료기준	시도 ★	달성 ★★	품질 ★★★	평가 사유
2주차 필수1 · 컨텍스트 3개+ 자동 주입			●	필수는 컨텍스트 세 개인데 여섯 개를 만들어 여유 있게 넘기셨고, 매 세션 항상 올리는 방식과 필요할 때만 올리는 방식을 나눠 배선하셨습니다. grep으로 소비자에서 정본으로 이어지는 연결이 15~16개 실제로 잡혀서, 주입이 문서상 약속이 아니라 진짜로 걸려 있음이 확인됩니다.
2주차 필수2 · 주입 전/후 동작 비교			●	지정된 /skill-creator 대신 같은 입력을 72번 돌린 통제 A/B 실험으로 주입 전후를 비교해, 정확도가 50%에서 97.2%로 오르는 것을 숫자로 보여주셨습니다. 도구는 달랐지만 '주입이 동작을 바꾸는가'라는 취지를 오히려 더 엄밀하게 넘어서서, 다섯 명 중 세 명이 품질로 봤습니다.
2주차 필수3 · 컨텍스트 체계 도식화			●	컨텍스트 주입이 언제·무엇이·어느 창에 들어오는지를 세 관점의 도식으로 나눠 그리고 색으로 구분해, 그림만 봐도 체계가 한눈에 읽힙니다. 리포트가 이 파일 경로를 옛 위치로 잘못 적은 자잘한 흠은 있지만 도식 자체의 완성도는 높습니다.
2주차 도전1 · 주입 검증 테스트			●	주입이 조용히 끊기는 걸 막으려고 아홉 가지를 검사하는 테스트를 만들고, 이걸 CI에 걸어 push·PR마다 자동으로 돌게 하셨습니다. 도식과 실제 참조가 서로 어긋나는지 양방향으로 보는 검사까지 있어 회귀를 잘 막습니다.
2주차 도전2 · 최적화+정량 비교			●	큰 스캔을 서브에이전트로 넘겨 메인 흡수를 89% 줄이고 총 토큰을 절반으로 낮춘 뒤, 상주 컨텍스트가 다시 커지지 않게 예산 게이트까지 두셨습니다. grep만 하는 스킬은 위임이 오히려 손해라 일부러 안 넘긴 손익분기 판단이 특히 좋았습니다.
3주차 필수1 · 개선/자산축적 루프 1개			●	스킬을 부를 때마다 로그에 쌓고 /usage가 그 로그를 되읽는 자산축적 루프를, 같은 파일을 쓰고 읽는 코드 경로 수준에서 실제로 닫으셨습니다. 여기에 동기화·감시·집계 같은 자율탐지 루프 네 종까지 더해져 단계 분해와 연결이 탄탄합니다.
3주차 필수2 · 루프 1P 문서화			●	루프를 탐지형·데몬·축적형 세 갈래로 나누고 각각을 도식·색 범례·출처와 함께 한 장에 담아, 자동으로 도는 장치가 한눈에 들어옵니다. 설계원칙 문서의 저장소 분류와도 이어져 문서만 봐도 구조가 이해됩니다.
3주차 도전1 · 나아지는지 정량 지표		●		빈도·연쇄·유휴를 보는 /usage와 네 개 지표를 내는 A/B처럼 정량 지표를 갖춘 점은 분명합니다. 다만 이 지표들은 사용 패턴과 주입 효과를 재는 것이라, '루프가 회를 거듭할수록 나아지는가'를 직접 재는 데까지는 닿지 못해 다섯 명 모두 달성으로 봤습니다.
3주차 도전2 · 5차원+랄프 2h+ 스냅샷	●			PR 본문의 랄프 루프 회고와 코드 주석의 측정법 언급으로 시도한 흔적은 보입니다. 그러나 5차원 루브릭 문서도, 두 시간 넘게 돌린 회차별 스냅샷 기록도 트리에 없어서 다섯 명 모두 아직 시도 단계로 봤습니다.

• 과제별로 5개 독립 에이전트가 다수결로 평가합니다.

2. 여러 작은 루프를 만드셨는데요. 언급하신대로 이후에는 이 OS의 핵심 목표를 달성하기 위한 방향으로 가치 있는 무엇인가를 남기고, 남긴 것을 토대로 그 다음에는 0.1%라도 더 나아질 수 있는 시스템 루프를 구성해보시면 좋을 것 같습니다. 결국은 무엇을 남기고, 남긴 것을 어떻게 활용할지에 대한 고민이 될 것 같습니다. 또한, 시스템 루프가 더 커진다면 사람과 AI의 역할이 각각 무엇인지, 최상의 협력은 무엇인지도, 주요 화두가 될 것 같습니다.

3. 현재 트리거 장치(cron)가 여러개인데요. 테스트가 불가능하지는 않겠지만 cron은 상대적으로 테스트하기 어렵고, 많아지다 보면 관리가 어려울 수 있습니다. 따라서 1분 짜리 cron 하나만 유지하고, 1분에 한 번 실행될 때마다 시간 기반 매칭 로직 등으로 트리거되어야 하는 작업들을 선택해 수행하는 구조도 검토해볼만 한 것 같습니다. 테스트가 쉬워지고, 트리거 되는 모든 작업에 대한 공통 로직을 적용하기도 쉬워져 결국 유지보수 하기가 편해질 것 같다는 생각입니다.

---

바쁘신 와중에 세 번의 과제를 진행하시느라 고생 많으셨습니다. 회사에서는 여러 복잡한 이슈로 AI의 잠재력을 100% 활용하기 어려울텐데요, 개인 OS의 장점은 100% 이상의 잠재력을 제한 없이 이끌어낼 수 있다는 점인 것 같습니다. 본인의 필요에 의한 OS인 만큼 내 필요를 더 탁월하게 채워주는 OS로 계속 발전하면 좋겠습니다.

고맙습니다!