소개
시도하고자 했던 것과 그 이유를 알려주세요.
1편에서 리서치→검증→Learn Back 루프를, 2편에서 온톨로지 5부작 인테이크를 다뤘습니다. 2편은 "인박스 8건이 쌓였는데 한 건도 승격 못 했다"는 병목 고백과 4개짜리 계획으로 끝났는데, 이번 3편(7/30~8/3)은 그 계획을 실제로 청산한 기록입니다.
그리고 한 가지가 더해졌습니다. 지금까지는 리서치 프로젝트만 돌려서 30-context/(내 환경), 60-actions/(실행 기록) 레이어가 계속 비어 있었습니다. 이번에 Hermes Agent + OpenClaw를 2016년형 맥북에 설치하는 실행 프로젝트를 AKM 위에서 진행하면서, 처음으로 7개 레이어가 전부 채워졌습니다. 리서치는 지식 레이어만 쓰지만, 실행은 컨텍스트·메모리·액션 레이어까지 요구한다는 걸 몸으로 확인한 주간입니다.
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
도구: Claude Cowork(로컬 폴더 연결) + AKM 저장소 + 웹 검색/문서 스냅샷
📅 7월 30일 — 2편 계획 4건 전부 실행 ("빚 갚는 날")
2편 말미의 계획이 이날 전부 소화됐습니다.
인박스 8건 전량 트리아지: 원본 6건 →
10-sources/, 켈리 공식 분석 →20-knowledge/techniques/, 사례글 →80-outputs/. 인박스 0건 달성.온톨로지 5부작 컴파일: 소스 5개 → 지식 노트 5개(개념 1 + 비교 1 + 기법 2 + 엔티티 1)로 재구성하고, 기존
llm-wiki노트군과 위키링크 연결. 2편에서 고민하던 입도(granularity) 문제를 "소스 파일 단위가 아니라 지식 유형(concept/comparison/technique/entity) 단위로 쪼갠다"로 일단 정리했습니다.index.mjs↔lint.mjs충돌 근본 수정: lint에isGeneratedIndex()를 추가해 생성 인덱스를 스키마·중복 검사에서 제외. 회귀 테스트 8/8 통과, 7/23에 열어둔 감사 건 종결.프로시저 승격: 반복하던 "유튜브 자막→노트", "단계별 리서치 인테이크"를
50-procedures/에 저장. 이제 매번 긴 프롬프트를 다시 쓰지 않습니다.
이날의 진짜 하이라이트는 따로 있습니다. 감사 노트의 검증 규칙을 40-memory/verification-rules.md로 승격한 것.
- 지명·수치·날짜는 1차 출처를 최소 1건 열어 대조한 뒤 기재한다.
- 사용자 요청문 속 전제도 검증 대상이다.
- 복수 출처의 수치가 상충하면 병기하고 상충을 표시한다. 한쪽 선택 금지.
- 근거가 약하면 trustLevel을 낮게 두고 nextAction: verify로 남긴다.2편에서 "Learn Back은 쌓인 규칙을 내가 다음 명령에 태울 때 완성된다"고 썼는데, 그건 수동 재투입이었습니다. 40-memory/는 CLAUDE.md가 매 세션 강제로 읽게 하는 층이라, 승격한 순간부터 이 규칙은 자동 적용됩니다. 같은 규칙의 신분이 "내가 기억해야 하는 것"에서 "시스템이 기억하는 것"으로 바뀐 거죠.
📅 8월 1일 — 새 프로젝트 착수, 그런데 계획 노트부터 감사받다
Hermes + OpenClaw 설치 프로젝트를 시작하며 인박스에 계획 노트 2건을 넣었습니다(기기 진단·설치 절차 / AKM 레이어별 지식 축적 프롬프트 세트 P1~P11).
여기서 예상 못 한 전개: 계획 노트에 Tier 1 감사를 걸었더니 계획 자체의 구멍이 나왔습니다. 검증 프롬프트가 없고(P12 추가), 지식 최신화 주기가 없고(P13), 콜드스타트 시나리오가 없다(P14)는 지적. 산출물만 검증 대상인 줄 알았는데, 계획도 노트인 이상 감사 대상이었습니다. 그렇게 v1 → v2.
📅 8월 2일 — 배치 재설계, 수집→컴파일→검증, 그리고 설치 준비
v2 → v3: 프롬프트 14개를 낱개로 돌리는 건 비효율이라, 병합 기준 3가지(① 같은 시점에 트리거되는가 ② 단계 간 판단 의존성이 없는가 ③ 작성과 검증이 분리 유지되는가)로 6개 실행 단위(B1~B6)로 묶었습니다. 핵심 안전 규칙 하나:
P12(검증)는 어떤 배치에도 합치지 않는다 — 작성과 같은 턴의 검증은 형식화된다. 각 배치 완료 후 별도 턴에서 실행.
이날 실제로 돌린 것들:
B1 수집: OpenClaw 공식 문서 3건 + Hermes 문서 3건 + 트러블·보안 자료 3건(설치 실패 이슈 21464, macOS 12 Node 스레드, 게이트웨이 RCE 권고 GHSA-gv46-4xfq-jv58) = 스냅샷 9건 →
10-sources/. 요약 금지·원문 보존, 수집 시점 버전(openclaw 2026.6.10 / hermes-agent 0.13.0)을 본문 첫 줄에 기록.B2 컴파일: 소스에서
openclaw-install-requirements,hermes-install-requirements(기법 2건) +agent-install-common-pitfalls(패턴 1건)를 합성. 전부trustLevel: unverified로 시작.별도 턴에서 P12 검증: Tier 1을 걸었더니 과대 주장 5건이 걸렸습니다. 예를 들어 "sudo npm install로 해결" → 알고 보니 공식 문서가 아닌 커뮤니티 해법이라 그렇게 표기, "uv venv라 안전" → 소스에 직접 언급이 없어 추정 표시. 약화 후 3건 모두 unverified → reviewed 승격. 문서 간 Node 버전 요구가 달랐던 건 40-memory 규칙대로 한쪽을 고르지 않고 상충 그대로 병기했습니다.
당일 Learn Back 1건: 소스 인덱스 항목 8건을 공용
INDEX.md에 넣었다가 "인스턴스 노트는INDEX.local.md" 규칙 위반을 발견, 당일 정정하고 LOG에 남겼습니다.설치 준비: 기기 제약(MBP 2016, macOS 12 EOL, Intel이라 로컬 LLM 불가)을
30-context/constraints/에, 매 세션 필요한 1줄은40-memory/포인터로. API 키는 값이 아니라 이름/보관 위치만 기록. 그리고60-actions/runs/에 설치 run을 열고 비표준 결정 5건(D1~D5)을 사전 기록했습니다 — nvm으로 Homebrew node@22 우회(D1), install.sh 대신 npm 직접 설치(D2), 호스티드 API만 사용(D4), 게이트웨이 루프백 유지·외부 노출 금지(D5) 등. 각 결정에 근거 소스가 위키링크로 달려 있어서, 나중에 "왜 표준 경로를 안 썼지?"를 다시 조사할 필요가 없습니다.
📅 8월 3일 — 시스템의 규칙으로 시스템 발표자료를 감사하다
스터디 발표용 덱 3종(pptx/HTML/스크립트)에 전체 점검 감사를 돌렸습니다. 결과: 사례 ② 날짜 오기(7/27→7/25), "파일 4개"→6개, "승격 예정"→승격 완료 등 사실 오류 7건 정정. 그리고 "인박스 0건", "lint 0/0" 같은 숫자에는 전부 "7/30 시점" 표기를 달았습니다 — 살아있는 저장소라 숫자가 계속 낡기 때문입니다. 1편에 썼던 Karpathy 출처도 블로그 루트가 아니라 원본 Gist로 교정됐습니다.
"지명·수치·날짜는 1차 출처 대조" 규칙이 지식 노트를 넘어 발표자료라는 산출물에까지 적용된 날입니 다. 재미있는 디테일 하나: 감사 중 과거 프롬프트 인용문을 고칠 때, 70-evaluation/ 감사 노트와 10-sources/ 인테이크 메모의 원문은 일부러 건드리지 않았습니다. 기록 계층은 정정 대상이 아니라는 원칙 — 틀린 채로 보존돼야 "무엇이 왜 틀렸었는지"가 남습니다.
결과와 배운 점
배운 점과 나만의 꿀팁:
계획도 감사 대상입니다. 계획 노트에 Tier 1을 걸었더니 검증·최신화·콜드스타트가 빠진 게 나왔고, v1→v3을 거치며 계획의 품질 자체가 올라갔습니다. "실행 전 산출물"이라고 검증을 면제하면 구멍 난 계획대로 실행하게 됩니다.
작성과 검증은 같은 턴에 두지 마세요. 방금 쓴 글을 같은 호흡으로 검증하면 요식행위가 됩니다. 배치 규칙에 "P12는 어떤 배치에도 합치지 않는다"를 박아두니, 별도 턴 검증에서 실제로 과대 주장 5건이 걸렸습니다.
수동 재투입(감사 노트)과 자동 적용(40-memory)은 다른 단계입니다. 2편까지는 규칙을 다음 프롬프트에 손으로 태웠는데, 40-memory로 승격한 뒤로는 세션이 바뀌어도 규칙이 저절로 적용됩니다. 감사 노트에서 반복 검증된 규칙만 골라 승격하는 게 요령입니다.
실행 프로젝트가 레이어를 채웁니다. 리서치만 할 때는 30-context와 60-actions가 계속 비어 있었습니다. "이 기기에서, 이 제약으로, 이 결정을 내려 실행했다"는 정보는 리서치에서는 나올 수 없는 종류의 지식입니다.
trustLevel 수명주기가 실제로 돌아갑니다. draft(계획) → unverified(컴파일 직후) → reviewed(Tier 1 통과)로 올라가는 걸 이번에 처음 끝까지 봤습니다. 노트를 열면 "이 정보를 얼마나 믿어도 되는가"가 프론트매터 한 줄로 보입니다.
시행착오:
인박스 제로는 상태가 아니라 반복 작업입니다. 7/30에 0건을 만들었는데 8/1에 계획 노트 2건이 다시 쌓였습니다(트리아지 기한 8/8). 비우는 게 목표가 아니라 흐르게 하는 게 목표라는 걸 받아들였습니다.
규칙을 40-memory에 승격해 놓고도 당일 인덱스 배치 실수(INDEX.md vs INDEX.local.md)를 했습니다. 메모리는 "덜 틀리게" 해주지 "안 틀리게" 해주진 않습니다. 다만 당일 발견·당일 정정·LOG 기록까지의 시간이 확실히 짧아졌습니다.
설치는 아직 "진행 중"입니다. 에이전트의 셸은 격리 Linux라 제 맥에서 직접 실행할 수 없어서, 에이전트가 명령 시퀀스를 만들고 제가 로컬 터미널에서 실행해 결과를 되먹이는 분업 구조입니다. run 노트가 "대기" 상태로 이 분업의 경계를 기록하고 있습니다.
도움이 필요한 부분:
EOL 기기(macOS 12)를 상시 서버로 쓰는 보안 기준을 고민 중입니다. 루프백 바인딩 + 외부 포트 미개방까지는 정했는데, 이 정도로 충분한지 감이 없습니다. 비슷한 구성으로 운영 중인 분의 기준이 궁금합니다.
배치 크기의 기준도 아직 감입니다. 노트 6개를 한 번에 합성시키면 후반부 품질이 떨어져서 2회로 쪼갰는데, "몇 개까지 한 턴에 맡겨도 되는가"에 대한 경험칙이 있다면 듣고 싶습니다.
앞으로의 계획:
설치 run 완료 → smoke check(
openclaw gateway status,hermes doctor) → run 노트 마감설치 경험을 B4(절차 승격)로: 반복 가능해진 작업만 골라
50-procedures/에B6 월간 유지보수 첫 회 — 소스 스냅샷 최신화(P13), 콜드스타트 리허설(P14)
lint 커밋 훅 자동화, 컴파일 입도 기준 SCHEMA 명문화 (2편부터 이월된 숙제)
도움 받은 글 (옵션)
deck6ix, AKM 저장소 (README,
99-system/문서 일체)OpenClaw 공식 문서 (Getting started / Gateway on macOS / Chat channels) 및 보안 권고 GHSA-gv46-4xfq-jv58
NousResearch, Hermes Agent — https://github.com/NousResearch/hermes-agent
1편: AKM으로 리서치→검증→학습 루프 돌려보기 / 2편: 온톨로지 5부작 리서치
스터디 단톡방 피드백 감사합니다!
