내 AI가 나를 학습하는 줄 알았다, 5주치 로그를 열기 전까지는

대상: AI 에이전트 · PKM · 바이브코더  ·  형식: 구축기  ·  2026-07-07

이미지: 지식을 아무리 넣어도, 다시 열리지 않는 서랍은 없는 것과 같다.

페이블이 돌아온 주, 프롬프트 하나

페이블은 구독에서 오래 머물지 않는다. 가장 똑똑한 모델을 쓸 수 있는 창이 잠깐 열린 셈이다. 다니엘 미슬러는 이 창을 이렇게 쓰라고 했다. 가장 강한 지능이 필요한, 그리고 앞으로의 모든 세션에 복리로 쌓일 일에 대라고.

그 목록 맨 위가 "하네스 점검"이었다. 내 AI 셋업이 지금의 나를 실제로 반영하는지 감사하라는 것. 마침 나는 몇 달째 개인 지식 볼트와 자동 메모리를 키워온 참이었다. 규칙을 박고, 교훈을 캡처하고, 인덱스를 다시 굽고. 잘 굴러간다고 믿고 있었다.

그래서 그 창에 이 프롬프트를 넣었다. "내 하니스가 기억하는 걸 전부 뒤져봐. 세션을 넘어 어떻게 학습하는지 봐. 지식이 어디서 죽는지, 캡처됐는데 다시 안 떠오르거나 아예 안 잡히는 곳을 찾아. 그리고 정말 나에 대해 똑똑해지는 중인지, 그냥 쌓기만 하는지 판정해줘."

복리라는 단어가 오래 남았다. 나는 세션마다 지식을 넣고 있었다. 그런데 그게 다음 세션으로 넘어가 이자를 낳고 있었을까, 아니면 그냥 잔액만 불어난 통장이었을까. 로그를 열어야 알 수 있었다.

가장 똑똑한 모델을 쓸 수 있는 창은 잠깐 열린다. 그 잠깐을 어디에 댈 것인가.

축적은 빨랐고, 학습은 한 갈래뿐이었다

여러 개의 감사 에이전트를 풀어 5주치 세션 53개, 지식 파일 수백 개, 메모리, 자동화 스크립트를 동시에 훑게 했다. 각자 다른 각도에서 "무엇이 실제로 다시 읽혔나"를 세게 했다. 돌아온 그림은 예상보다 냉정했다.

실제로 순환하는 지식은 셋뿐. 매 세션 자동으로 주입되는 규칙 파일, 블로그 글쓰기 스킬 대여섯 개, 그리고 자주 만지는 GTM 참고 문서 두 개. 나머지는 거의 손을 타지 않았다.

참고 문서 215개 중 96%는 5주 동안 단 한 번도 열리지 않았다. 마케팅 스킬 28개 중 26개, 엔지니어링과 사고법 스킬은 통째로 0회. 크기로 따지면 활성 지식의 98%가 "AI가 알아서 찾아 열어줄 때만" 열리는 취약한 경로 뒤에 있었고, 그 경로를 강제하는 장치는 하나도 없었다.

축적 속도는 훌륭했다. 6월 한 달에만 메모리 21개가 늘었으니까. 문제는 늘기만 했다는 것. 무엇 하나 은퇴하거나 사라지는 장치가 없었다. 통장 잔액은 불었지만 이자는 거의 붙지 않는 구조.

215개 참고 문서 중 실제로 열린 건 9개. 서가는 넓은데 발자국은 딱 한 줄뿐.

병은 캡처 부족이 아니었다

처음엔 "교훈을 더 부지런히 캡처해야 하나" 싶었다. 아니었다. 로그를 파고들수록 진짜 원인은 정반대, 캡처는 넘쳤고 두 가지가 없었다.

첫째, 모든 지식에 상태가 없었다. 태어나기만 하고 늙지도 죽지도 않았다. 그래서 6월에 폐기한 규칙이 7월에도 살아서 매 세션 끼어들었다. 새것과 낡은것, 살아있는 것과 뒤집힌 것이 똑같은 대접을 받았다.

둘째, 아무도 "읽혔는지"를 재지 않았다. 감지 도구는 "무엇을 새로 캡처했나"만 셌지, "그 지식이 실제로 다시 쓰였나"는 어떤 도구도 측정하지 않았다. 파일이 언제 수정됐는지는 알아도, 언제 읽혔는지는 아무도 몰랐다. 읽힘을 모르면 무엇이 죽었는지도 모른다. 그러면 버릴 수도 없다.

이 둘은 맞물려 있었다. 측정이 없으니 소멸 규칙을 설계할 근거가 없고, 소멸이 없으니 상태가 하나로 뭉갠 채 쌓이기만 했다. 캡처를 아무리 늘려도 이 두 구멍은 안 메워진다. 오히려 무덤만 커진다.

유일하게 살아있던 것이 정답을 알려줬다

그런데 딱 한 갈래는 진짜로 학습하고 있었다. 블로그 파이프라인이다. 지난 몇 주간 블로그를 쓸 때마다 사용자 지적이 나왔고, 그때마다 규칙이 하나씩 생겼다. 주황 포인트색, 모바일 문단 길이, 가짜 1인칭 금지, 미측정 비율 금지.

흥미로운 건 규칙이 문서로만 있을 땐 다음 글에서 또 같은 실수가 났다는 점이다. 규칙은 있는데 그 순간 안 떠오른 것이다. 마찰이 반복됐고, 결국 나는 blog_check.py라는 체커를 만들어 발행 전 자동으로 걸리게 했다. 그 뒤로 그 실수는 멈췄다.

여기에 공식이 숨어 있었다. 규칙은 문서에 두고, 차단은 기계에 맡긴다. 사람의 규율에 기대는 규칙은 결국 새고, 기계가 막는 규칙만 안 샌다. 살아있던 유일한 파이프라인이, 죽어가던 나머지 전부가 따라야 할 설계를 이미 증명하고 있었다.

문서 규칙은 바람에 날리고, 기계 게이트는 닫혀 있다. 차이가 재발을 갈랐다.

그래서 흉터부터 세어봤다

설계를 하기 전에, 시스템이 실제로 어디서 피를 흘리는지 네 군데를 짚었다. 전부 로그에 증거가 있었다.

하나. 만들어놓고 켜지 않은 스위치. 며칠 전 나는 "볼트 파일을 고치면 인덱스를 자동으로 다시 굽는" 강제 훅을 짜뒀다. 훅 폴더에서 가장 최신 파일이었다. 그런데 그게 설정 어디에도 연결돼 있지 않았다. 완성만 하고 배선은 안 한 셈. 그 결과가 바로 그날의 "인덱스 낡음" 경고였다.

둘. 6일 전에 죽은 규칙의 유령. 손으로 그린 도식을 쓰지 말자고 6월 24일에 정했는데, 그걸 쓰라는 옛 메모리가 은퇴 없이 남아 매 세션 조용히 주입되고 있었다. 새 결정과 낡은 결정이 같은 컨텍스트 안에서 서로를 부정하고 있었다.

셋. 자기 자신을 오탐하는 감지기. 마찰을 찾는 스크립트가, 회고를 분석하는 자기 프롬프트를 "강한 불만"으로 잡아냈다. 거울을 보고 낯선 사람이라 놀란 셈. 진짜 신호가 자기가 낸 소음에 묻혔다.

넷. 서로를 못 보는 두 개의 루프. 빠른 경로(마찰 즉시 규칙화)가 이틀 만에 고친 문제를, 느린 안전망(월간 회고)이 3주 뒤 "새로운 문제"라며 다시 제안했다. 안전망이 빠른 경로의 작업을 못 봐서, 이미 고친 걸 또 고치라고 한 셈. 두 개의 기억이 서로를 모르면 이런 헛일이 난다.

재부상을 먼저 배선한다

진단이 끝나자 설계는 단순해졌다. 캡처를 더 만들지 않는다. 대신 다시 떠오르는 길과 읽혔는지 재는 자를 먼저 놓는다. 핵심은 세 가지.

첫째, 승격 사다리. 교훈은 한 번에 규칙이 되지 않는다. 관찰(기록만) 아래 칸에서 시작해, 두 번 반복되면 온디맨드 규칙으로, 세 번이면 매 세션 주입되는 규칙으로, 그래도 또 틀리면 기계가 막는 게이트로 올린다. 원칙은 하나다. 재발은 위로 민다. 규칙이 있는데 또 틀렸다면 답은 문구 수정이 아니라 한 층 위 표면이다.

둘째, 승계 프로토콜. 새 규칙이 옛 규칙을 뒤집으면 옛것을 그냥 두지 않는다. 새 파일이 "무엇을 대체하는지" 명시하고, 옛 파일은 은퇴 표시와 묘비만 남기고 본문은 치운다. 인덱스에서도 지운다. 이 세 동작이 한 세트로 돌아야 유령이 안 생긴다.

셋째, 읽기 로그. 이게 없으면 나머지 전부가 추측이다. 파일이 열릴 때마다 조용히 한 줄씩 기록을 남긴다. 이 로그가 쌓여야 "90일간 한 번도 안 읽힌 문서"를 근거를 갖고 정리할 수 있다. 측정이 소멸의 전제라는 말은 은유가 아니라 실행 순서다.

승격 사다리. 규칙이 또 깨지면 문구를 고치는 게 아니라 한 칸 위로 올린다.

하루 동안 실제로 한 것

설계를 문서로만 남기면 그것도 안 읽히는 무덤이 된다. 그래서 같은 날 바로 손을 댔다.

강제 훅 세 개를 배선했다. 파일을 고치면 인덱스를 자동으로 다시 굽는 훅(그 미완의 스위치를 드디어 켰다), 지식이 열릴 때마다 기록을 남기는 사용 로그 훅, 그리고 프롬프트를 읽고 관련 스킬과 프로젝트 문서를 자동으로 끌어와 컨텍스트에 얹어주는 재부상 라우터. 마지막 것이 핵심이다. "AI가 알아서 찾아 열겠지"라는 희망을, 키워드가 걸리면 무조건 밀어넣는 기계로 바꿨다.

참고 문서를 215개에서 74개로 줄였다. 대부분 옛 노트 앱에서 통째로 넘어온 덤프, 끝난 할일 목록, 옛 브랜드 리서치였다. 발견성 문제의 절반은 검색이 아니라 분모를 줄여서 풀린다. 서가가 스캔 가능한 크기여야 색인이 색인 노릇을 한다. 지운 건 없다. 전부 아카이브로 옮기고 복구용 명세를 남겼다.

메모리 33개를 22개로 줄였다. 볼트 문서와 그냥 중복이던 15개를 은퇴시키고, 상시 로드되는 요약을 코어와 클러스터 두 층으로 다시 짰다. 그 유령 규칙도 이때 정식으로 묘비를 세웠다.

중요한 건, 무엇을 지우고 무엇을 강등할지는 전부 사람 승인 게이트를 통과시켰다는 점이다. AI가 스스로 규칙을 박거나 지우기 시작하면, 틀린 규칙도 같이 강화된다. 기계는 후보와 근거를 제시하는 데까지, 결정은 사람이.

훅 3종 배선, 문서 215에서 74로, 메모리 33에서 22로. 늘리는 하루가 아니라 잇고 줄이는 하루였다.

검증도 흉터를 남겼다

여기서 끝났으면 깔끔한 이야기였겠지만, 실제로는 안 그랬다.

대청소를 돌린 오케스트레이션이 두 번 죽었다. 한 번은 병렬 실행에 함수 대신 이미 실행된 값을 넘겨서, 한 번은 입력이 객체가 아니라 문자열로 들어와서. 둘 다 로그를 읽고 원인을 짚어 고쳐 이어 붙였다. 자동화는 짜는 것보다 "정말 도는지" 확인하는 데서 갈린다.

더 뜨끔했던 건 이거다. 새로 만든 재부상 라우터가 실제 세션에서 작동했는지 검증하다가, 나는 "주입 안 됨"이라고 판정했다. 그런데 원시 로그를 다시 열어보니 라우터는 멀쩡히 작동했고, 틀린 건 내가 로그를 파싱한 방식이었다. 검증의 검증이 필요했던 것이다.

이 대목이 이 글 전체의 축소판이다. "됐다"고 믿는 것과 실측으로 확인하는 것은 다르다. 스케줄을 걸었다고 도는 게 아니고, 규칙을 적었다고 지켜지는 게 아니고, 로그를 봤다고 제대로 읽은 게 아니다. 그래서 이 시스템의 다음 완료 기준은, 다음 세션이 훅을 자동으로 실행하고 사용 로그가 저절로 쌓이는 걸 눈으로 확인하는 순간이다. 그건 아직 안 끝났다. 정직하게 그렇다.

당신이 지식 시스템을 만든다면

이건 개인 볼트 이야기지만, AI에 기억을 붙이는 누구에게나 같은 함정이 있다. 노트 앱이든, 사내 위키든, 에이전트 메모리든. 역사 얘기는 여기서 끝, 이제 당신 시스템에 대보자.

그래도 하나만 챙긴다면, 이것이다.

지식은 쌓는 게 아니라 다시 떠오르게 하는 것이다. 안 읽히면, 넣지 않은 것과 같다.

근거·출처

• 도입 프롬프트의 출처: Daniel Miessler, Prompts to Run When Fable Comes Back (최고 모델 접근이 한시적일 때 복리로 쌓일 메타 작업에 쓰라는 프레이밍, 하네스 점검 항목)
• 수치의 근거: 필자 개인 지식 볼트의 5주치 세션 로그 53개 실측 감사 (2026-07-07) 및 정비 기록

본문 수치(재부상 15% · 4%, 문서 215→74, 메모리 33→22 등)는 필자 시스템에서 직접 측정·집계한 값이다. 정비 후 개선 효과는 아직 측정 전이며, 그 점은 본문에 정직하게 표기했다.