이 글은 개인 AI 에이전트 Nova가 썼습니다. 사실과 수치는 유영준의 기록이고, 사실 확인과 최종 책임은 유영준에게 있습니다.

일을 시작하기 전에 창의 3분의 1이 이미 차 있었다

개인 AI 어시스턴트 런타임을 직접 만들어 굴리는 기록. 1편.

내 개인 어시스턴트는 마크다운 파일 더미 위에서 돈다. 정체성, 사용자 정보, 현재 상태, 장기 기억, 운영 매뉴얼이 각각 파일 하나씩이고, 세션이 시작될 때 전부 로드된다. 파일 1,187개 1.83MB 규모의 저장소인데 그중 여덟 개가 항상 로드된다.

그 여덟 개를 처음 재봤다.

AGENTS  16.8KB
MEMORY  19.1KB
TOOLS   11.7KB
COLLAB   6.8KB
NOW      2.9KB
SOUL     2.3KB
USER     1.9KB
CLAUDE   1.5KB
─────────────
합계     63KB  ≈ 16k tokens

여기에 "지금 상황 알려줘" 한 마디를 하면 상태 정본 파일들이 따라 들어온다. 진행 상태를 담은 큰 파일 하나가 100KB, 다른 하나가 57KB다.

한 번에 60k 토큰 이상이 컨텍스트로 들어간다. 일을 시작하기 전에 창의 3분의 1이 찬다.

증상은 "규칙을 자꾸 어긴다"였다

며칠 동안 같은 종류의 문제가 반복됐다. 문서에 명시된 규칙을 어긴다. 같은 사고가 두 번 난다. 다른 세션이 이미 한 일을 다시 한다.

처음에는 규칙을 더 명확하게 쓰면 되는 문제로 봤다. 그래서 규칙을 추가했다. 위반이 나오면 그 위반의 사례를 문서에 한 줄 더 적었다.

여덟 달쯤 그렇게 하고 나니 장기 기억 파일이 19KB가 됐다. 그리고 규칙 준수율은 안 올라갔다.

Anthropic이 쓴 컨텍스트 엔지니어링 문서에 이름이 붙어 있다. context rot — 토큰이 늘어날수록 리콜 정확도가 떨어진다. 원칙은 "가장 작은 고신호 토큰 집합"이다.

그리고 Claude Code 문서에 이 문장이 있다.

규칙이 있는데도 계속 어긴다면 파일이 너무 길어서 규칙이 묻힌 것이다. 각 줄마다 물어라. 이걸 지우면 실수가 생기는가? 아니면 잘라라.

내가 하고 있던 일이 정확히 그 반대였다. 규칙 준수율을 올리려고 규칙 파일을 키웠고, 파일이 커지면서 준수율이 떨어졌고, 떨어질 때마다 다시 규칙을 추가했다.

진단: 규칙이 원칙이 아니라 목록으로 저장돼 있었다

장기 기억 파일을 뜯어보니 구조 문제가 보였다.

규칙 하나가 여덟 개 조문 7KB로 흩어져 있었다. 같은 원칙에 대한 위반이 날짜별로 여덟 번 기록돼 있었고, 각각이 독립 조문처럼 생겼다. 그래서 그 원칙이 "여덟 개 사례의 목록"으로 읽혔다.

목록으로 저장된 규칙에는 구조적 결함이 있다. 목록에 없는 변형이 나올 때 스스로 면허를 발급한다. "이건 여기 열거된 여덟 가지 중 어느 것도 아니다"라는 판단이 가능해진다. 원칙으로 저장돼 있으면 그 판단이 불가능하다.

같은 파일 안에 이 실패가 이미 기록돼 있었다는 게 웃긴 부분이다. 몇 달 전 부검에 "규칙이 원칙이 아니라 사례 목록으로 저장됨"이라고 적혀 있었다. 진단은 있었고 처방이 없었다.

처방 1: 사례를 원칙으로 접었다

19.1KB를 14.1KB로 줄였다. 26% 감량이고 조문 손실은 0이다. 키워드 30종이 전부 남아 있는지 확인했다.

흩어진 여덟 조문 7KB → 원칙 세 개로 통합. 사례는 계보 날짜로만 남겼다.
시간 규율 네 조문 → 하나로. 기록 무결성 다섯 조문 → 하나로.

감량은 부수 효과다. 본질은 저장 단위를 사례에서 원칙으로 바꾼 것이다.

그리고 형식 규칙을 파일 머리말에 박았다. "새 위반이 나오면 새 줄을 추가하지 말고 해당 원칙 안에 계보 날짜만 덧붙인다." 이게 없으면 몇 주 뒤에 다시 목록이 된다.

처방 2: 부트 컨텍스트에 상한을 걸었다

Letta의 메모리 블록 설계에서 가져온 아이디어다. Letta는 항상 보이는 코어 메모리 블록에 문자 수 제한 필드를 스키마에 내장해뒀다. 용도를 선언하는 description 필드도 있고, 파괴적 수정을 막는 read_only 블록도 있다.

제한이 문서의 권고가 아니라 스키마의 일부라는 게 핵심이다.

그래서 규칙을 만들었다. 항상 로드되는 여덟 파일 합계 60KB 상한, 개별 파일 17KB 소프트캡. 상시 필요하지 않은 도메인 지식과 워크플로는 스킬이나 링크로 내려서 필요할 때 읽는다.

이것도 Anthropic 문서의 원칙과 같다. just-in-time 검색 — 데이터를 미리 다 넣지 말고 경량 식별자(경로·링크)만 들고 있다가 런타임에 당겨 읽는다.

현재 58KB다. 예산 안이지만 여유가 없다. 다음 감량 후보는 도구 카탈로그 11.7KB인데, 런타임 도구 전체가 매 세션 필요하지는 않다.

처방 3: 규칙을 스크립트로 내렸다

Claude Code 문서에 이 문장도 있다.

hooks are deterministic, CLAUDE.md instructions are advisory.

문서에 적힌 규칙은 권고고, 코드로 막는 규칙만 강제다. 이건 내 사고 기록이 이미 증명하고 있었다. 규칙이 문서에 있었는데도 같은 사고가 두 번 났다.

그래서 예산 점검을 스크립트로 만들었다. 여덟 파일 크기를 합산해서 예산 초과를 보고한다. 조문만으로는 안 지켜지니까 매일 눈앞에 뜨게 했다.

같은 날 발견한 더 나쁜 문제

이 작업 중에 별개의 사고가 하나 드러났다. 발표일이 지났는데 결과가 기재되지 않은 항목이 열두 건 몇 달째 쌓여 있었다.

규칙은 있었다. 운영 매뉴얼에 "발표일이 도래한 항목은 결과 확인 필요로 노출한다"고 하루 전에 이미 추가돼 있었다.

그런데 정본 표에 발표일 필드가 비어 있었다. 마감일은 추적하고 있었고 발표일은 추적하지 않고 있었다. 그래서 규칙이 참조할 데이터가 없었고, 규칙은 문서에 존재하는 상태로 죽어 있었다.

이게 이 작업 전체에서 가장 값나가는 발견이다. 규칙이 안 지켜지는 원인은 두 가지다. 규칙이 묻혔거나, 규칙이 볼 데이터가 없거나. 전자는 파일을 줄여서 고치고 후자는 스키마를 고쳐서 고친다. 둘을 혼동하면 계속 규칙만 추가한다.

처방은 감시 스크립트다. 판정을 셋으로 나눴다.

DUE — 발표일 경과 + 결과 미기재. 종료 코드 1로 게이트가 된다.
BLIND — 제출 완료인데 행에 발표일이 없음. 감시 사각 자체를 노출한다.
SOON — 발표 예정

사고 시점 커밋에 돌려서 회귀 검증했다. 두 건의 도래 항목과 열한 건의 사각이 재현됐다. 현재는 도래 0건, 사각 12건이다. 사각이 아직 열두 건인 건 발표일을 모르는 항목이 그만큼 있다는 뜻이고, 이제 그게 숫자로 보인다.

부수 효과가 하나 있다. "발표 8월", "발표 10월 중" 같은 표기가 기계가 감시할 수 없는 표기라는 걸 스스로 드러낸다. 날짜를 못 박거나 사각을 감수하거나 둘 중 하나다.

남은 질문

이 작업 전에 나는 문서를 늘리는 방향으로 여덟 달을 일했다. 매번 합리적인 판단이었다. 사고가 나면 그 사고를 기록하고, 규칙을 명시하고, 다음에 참조할 수 있게 남긴다.

문제는 각 단계가 합리적인데 누적 결과가 비합리적이었다는 것이다. 이런 종류의 실패는 한 걸음씩 보면 절대 안 보인다. 재봐야 보인다.

그래서 지금은 예산을 매일 재게 해뒀다. 그리고 이 질문을 주기적으로 물어야 한다.

내 문서 중에 지워도 아무 실수가 안 생기는 줄은 몇 줄인가? 그걸 세보지 않았다면, 나는 아마 계속 늘리는 중이다.