AI의 기억을 4개월 키우니 '관리자'가 필요했다 - 에이전트에게 맡기면 조합되는 키트를 공개합니다

연재 「외부 컨텍스트로 기억을 보완하려는 시도」의 다음 편입니다.

첫 번째 글에서는 AI의 기억을 담는 '상자'를 만들었고, 두 번째 글에서는 그 상자를 키우다 보면 반드시 어질러진다는 이야기를 했습니다.

이번에는 그 이후 4개월 동안 완성된 시스템 전체를 통째로 전달할 수 있는 형태로 공개합니다.

서론: 상자는 자랐지만, 관리가 따라가지 못했다

첫 번째 기사에서 만든 것은 부품이 단 3개뿐인 작은 상자였습니다. 지시서인 CLAUDE.md, 자신에 대한 내용을 적는 master_profile.md, 그리고 주제별 domains/ 폴더입니다.

그 이후로 4개월 동안 매일 사용했습니다. 커밋은 1,400회를 넘었고, 상담 상대도 Claude Code뿐만 아니라 Codex까지 추가되었습니다. AI가 확실히 자신에 대해 기억하고 어제 이야기의 다음 부분부터 대화할 수 있다는 점은 기대대로였습니다.

기대와 달랐던 것은 그 이후였습니다.

• 기록이 늘어날수록 AI가 처음 읽는 양이 늘어나서, 대화를 시작하기까지 시간이 오래 걸렸습니다.
• 「다음부터 이렇게 해줘」라고 부탁한 것이 다음 세션에서 지켜지지 않았습니다.
• 같은 종류의 실수를 날짜를 달리하여 여러 번 지적해야 했습니다.
• 「반영했습니다」라고 들었지만, 실제로는 저장되지 않은 경우가 있었습니다.

상자 안의 내용은 자라고 있지만, 상자의 관리(世話)가 따라가지 못하는 상태였습니다. 식물에 비유하자면, 화분은 커졌는데 물 주기나 분갈이까지 모두 우리가 기억해야 하는 상황입니다.

그래서 4개월 동안 관리 자체를 시스템으로 만들었습니다. 이 글에서는 그 시스템을 소개하고, 마지막에는 당신의 AI 에이전트에게 단 한 문장만 부탁하면 같은 것이 조합되는 키트를 전달합니다.

이 기사에서 할 수 있는 것들

• 4개월 동안 사용하며 필요했던 시스템이 무엇을 해결하는지 알 수 있습니다.
• Claude Code나 Codex에 한 문장을 요청하여 그 시스템을 자신의 리포지토리에 조합할 수 있습니다.
• 한 달에 한 번, 점검과 정리를 에이전트에게 맡길 수 있습니다.

첫 번째 상자를 아직 만들지 않았어도 괜찮습니다. 빈 리포지토리부터 시작할 수 있습니다. 이미 상자를 키우고 있는 분들은 현재의 기록을 남긴 채 시스템만 추가할 수 있습니다.

1. 지금은 어떻게 되었는가

먼저 전체를 살펴보겠습니다. 첫 번째 상자와 현재의 형태를 나란히 비교합니다.

【첫 번째 상자】 【현재의 형태】
CLAUDE.md CLAUDE.md / AGENTS.md 진입점 (몇 줄만)
master_profile.md OPERATING_RULES.md 공통 규칙과 '규율'
...

파일은 늘어났습니다. 하지만 생각하는 방식은 단 4가지밖에 없습니다. 도서관에 비유하면 이해하기 쉽습니다.

AI에게 '다음부터는 반드시 확인하고 저장해'라고 부탁한다. AI는 '알겠습니다'라고 답하며 규칙으로 기록한다. 하지만 다음 세션에서는 그 규칙을 읽고 있어도, 그 순간에는 기억하지 못한다. 인간도 마찬가지다. 규정집에 쓰여 있는 것과, 현장에서 몸이 움직이는 것은 별개의 문제다.

실제로 같은 종류의 실수에 대해 '규칙 추가'를 두 번 했더니, 세 번째 실수가 발생했다. 그래서 방법을 바꿨다. 반복된 실수는 문장으로 적지 않고 검사(check)로 만든다.

[pre-push] running check_references.py ...
[check_references] 1 problem(s):
domains/work.md:27: `domains/does_not_exist.md` — file not found
...

AI가 잊거나, 방심하더라도 멈춘다. 내가 기억할 필요가 없다. 이것이 '돌봄을 시스템화하는 것'이라는 의미다.

개선 루프: 같은 일을 두 번 말하게 하지 않기

AI의 움직임이 신경 쓰이면 그 자리에서 말한다. '결론부터 말해', '그거 전에 이야기했잖아'.

지적을 받은 AI는 다음 작업으로 넘어가기 전에, 그 말을 단 한 줄만 기록한다. 원인 분석은 나중에 해도 좋다. 일단 놓치지 않는 것을 우선한다.

| 날짜 | 카테고리 | 지적받은 내용 (직접 인용에 가까움) | 문맥 | 상태 |
|---|---|---|---|
| 2026-10-16 | `참조 오류` `재확인 요청` | '그거 전에 이야기했잖아' | 업무 상담 중 | `raw` |

raw (미처리) 상태로 남아 있으면, 다음에 대화를 시작할 때 감시자가 알려준다.

【⚠️ 미처리 피드백이 있습니다】
| 2026-10-16 | `참조 오류` `재확인 요청` | '그거 전에 이야기했잖아' | 업무 상담 중 | `raw` |
→ 다른 작업보다 먼저, 원인을 고치고 상태를 반영 완료 / 미채택으로 진행

원인을 고치는 순서도 정해져 있다.

• 기계로 막을 수 있는지 (감시자를 추가)
• 사용할 때 눈에 띄는 곳에 둘 수 있는지 (그 작업에서 반드시 열리는 템플릿)
• 현재 있는 규칙을 고치는 것으로 충분한지
• 그래도 부족할 때만, 문장 규칙을 추가한다

문장 규칙이 마지막인 이유는, 아까 적었듯이 가장 효과가 떨어지기 때문이다.

이 글을 쓰고 있다는 시점에서, 4개월 동안 받은 지적은 118건, 원인까지 파고든 실패 기록은 113건이다. 거기서 '이것만은 항상 지킨다'라는 규칙(掟)을 14가지로 정제하여 공통 규칙의 맨 앞에 배치하고 있다. 예를 들면 이런 것이다.

규칙 예시 (14가지 중 5가지)

• 완료 보고는 차이점이나 검사 결과 등의 확인과 함께 진행한다. 실행하지 않은 것을 실행한 것으로 보고하지 않는다.
• 저장(save)을 보낸 것만으로는 완료가 아니다. 본류에 들어간 것을 확인할 때까지가 완료다.
• 파일의 정보를, 본인에게 다시 묻지 않는다. 묻기 전에 읽는다.
• 반복된 실수는 규칙 추가로 막지 않고, 기계로 막는다.
• 규칙의 총량은 예산제다. 추가하기 전에, 모으는 것과 줄이는 것을 생각한다.

이 모든 것은 실제로 아픈 경험을 한 후에 작성한 것이다. 키트에는 이 14가지 항목을 출발점으로 넣었지만, 당신의 규칙은 당신의 리포지토리에서 발생한 실패로부터 자라난다.

2. 그래도 커진다. 그래서 '예산'을 정했다

시스템을 추가할수록, 이제는 그 시스템 자체가 커진다.

얼마 전, 모아서 측정해 봤다. AI가 대화를 시작하기 전에 반드시 읽어야 하는 파일이 추정으로 약 14,000 토큰. 지적이나 실패를 기록하는 로그 3개는 합계로 약 101,000 토큰이었다. 로그는 추가할 때마다 열리는 파일인데, 처리가 끝난 오래된 기록이 그대로 남아있었던 것이다.

'오래된 기록은 분기별로 정리한다'라는 규칙은 제대로 쓰여 있었다. 그리고 정한 후 처음 온 기한에서 이미 실행되지 않았다. 정리하기 전에 '교훈을 놓치지 않았는지 확인하는' 무거운 작업을 조건으로 했기 때문에, 아무도 손대지 않은 것이다.

여기서도 답은 같았다. 문장이 아니라, 수치와 검사로 만든다.

• 매번 읽는 파일과 3개의 로그에,
  크기의 상한선을 정한다 - 상한선을 초과하면, 감시자가 저장 전송을 멈춘다
• 로그는, 명령어 하나로 오래된 기록을 다른 파일로 옮긴다. 옮기기 전후로 한 건도 빠지지 않았는지 자동으로 확인한다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

[rotate_ops_logs] incident log: 45765 → 7415 토큰 (총 74건 중 61건 보관: 2026년 Q3 55건, 2026년 Q4 6건)

결과는 이렇다.

숫자는 영문/숫자 4글자와 일본어 1글자를 각각 1토큰으로 계산한 근사치다. 정확한 값은 아니지만, 같은 자로 늘거나 줄었는지를 비교하기에는 충분하다.

중요한 것은 이것이 단 한 번의 대청소로 끝나지 않는다는 것이다. 상한선이 있는 한, 커지면 다시 멈춘다. 정리하는 방법을 배울 필요가 없다.

3. 손을 움직이다: 에이전트에게 문장 하나 부탁하기

여기부터가 본론이다. 이 시스템을 개인의 내용을 빼고 기록하여 키트로 공개했다.

준비물

• GitHub의 private 리포지토리 (비어 있어도, 첫 번째 상자여도 좋다) - Claude Code 또는 Codex
• Git 및 Python 3.9 이상 (추가 설치는 필요 없다)

부탁하는 방법

자신의 리포지토리를 에이전트로 열고 다음 문장을 그대로 보낸다.

https://github.com/hobomokha/ai-secretary-kit 을 가져와, SETUP.md의 절차에 따라 이 리포지토리를 비서 리포지토리로 구축해 주세요.

이것만 있으면 된다. 키트 안의 SETUP.md는 사람을 위한 것이 아니라 에이전트가 읽기 위한 매뉴얼로 작성되어 있다. 에이전트는 다음 순서로 진행한다.

• 리포지토리가 private인지 확인한다 (public이면 거기서 멈춘다)
• 키트를 임시 장소에서 가져와, 그 버전이 작동하는지 스스로 검사한다
• 당신에게 단 4가지 질문을 한다 (자주 상담하는 영역, 사용할 에이전트, 시간대, GitHub Actions 사용 여부)
• 파일을 배치한다.
  이미 존재하는 기록은 남긴다 - 영역에 맞춰 지도와 읽지 않을 것 목록을 작성한다
• 검사를 모두 통과시킨다
• 저장하고, 작동하는 부분을 당신과 함께 확인한다.

잘 되었는지 확인하는 방법

에이전트가

존재하지 않는 Markdown 파일 이름(예: domains/nothing.md)을, 어느 파일에 백틱으로 감싸서 작성하고 저장 전송해 본다. 감시자가 막아야 한다. 멈춘다면, 시스템은 살아있는 것이다. 확인이 끝나면, 그 한 줄은 지워두자.

5. 키우는 방법: 월 1회 점검 요청하기

넣고 끝나는 것이 아니다. 하지만 할 일은 적다.

매일은 지금까지와 같다. 상담하고, 구획별로 “지금 이야기, 기억해 줘”라고 부탁한다. 궁금한 것이 있으면, 그 자리에서 말한다.

월 1회는 점검을 요청한다. 요청 문구는 키트의 prompts/maintenance_request_prompt.md에 들어 있다. 요청하면 에이전트는 세 가지 숫자를 본다.

python3 tools/repo_ops/session_report.py --full # 방치된 것, 오래된 정보
python3 tools/repo_ops/pdca_report.py # 반복되는 지적
python3 tools/repo_ops/context_budget.py --report # 너무 커진 파일

바로 고칠 수 있는 것은 고치고, 당신의 판단이 필요한 것은 선택지를 붙여 가져온다. 잊고 있어도, 주간 점검이 “1개월 이상 점검하지 않았다”고 Issue로 알려준다.

무거워졌다면, 같은 파일에 있는 ‘분기별 설계 리뷰’ 요청 문구를 사용한다. 2장에서 쓴 대청소는 바로 이 요청에서 시작되었다. AI에게 측정부터 부탁하고, 수치로 현황을 내게 하고, 고칠 수 있는 곳은 고치게 하고, 판단이 필요한 것만 가져오게 한다.

키트도, 우리가 시스템을 고친 후 업데이트할 생각이다. 새로운 버전을 적용하는 절차도 에이전트를 위해 작성되어 있다.

6. 어려움을 겪기 쉬운 점과 한계

감시자를 너무 많이 만들지 않는다. 검사는 추가할 때마다 조금씩 비좁아진다. 추가하는 것은 “같은 실수가 두 번 일어났을 때”에만 한다. 첫 번째는, 기록하고 지켜본다.

항상 울리는 경보는 아무것도 아니다. 해결할 수 없는 경고를 계속 내보내는 검사는 다른 경고까지 읽히지 않게 한다. 실제로 어느 세션에서도 대처할 수 없는 목록을 매번 표시하여, 월별 점검에서만 보는 곳으로 옮겼다.

검사가 보는 것은 형태일 뿐이다. 참조가 끊어지지 않았는지, 너무 커지지는 않았는지는 보지만, 적혀 있는 내용이 올바른지는 보지 않는다. 오래된 정보에 [FLOW] 표시를 하고, 월 1회 재점검하는 것은 여전히 사람과 AI의 일이다.

에이전트는 그럼에도 절차를 건너뛴다. 감시자는 만능이 아니다. 빠진 것이 있으면 지적하고, 개선 루프에 넣는다. 완벽한 시스템을 처음에 만드는 것이 아니라, 빠질 때마다 하나씩 막아간다. 4개월이 걸린 것은 그 때문이다.

안전의 기본은 첫 번째와 같다. 리포지토리는 반드시 private으로 하고, GitHub에는 2단계 인증을 설정한다. 비밀번호나 카드 번호는 어떤 이유로든 적지 않는다. 근무지나 고객 상세 정보도 필요 없다. “제조사 마케팅 직무” 정도의 수준이면 충분히 유용하다.

요약

AI에게 기억을 갖게 하는 상자는 하루 만에 만들 수 있다. 어려운 것은, 키운 후의 보살핌이었다.

지도로 어디를 읽고 어디에 쓸지 한 곳으로 정한다 -
읽지 않는 것 목록으로 읽는 양을 지킨다 -
감시자로 글쓰기의 약속을 기계에게 지키게 한다 -
개선 루프로 같은 것을 두 번 말하지 않게 한다 -
예산으로 시스템 자체가 커지는 것을 막는다

이 모든 것은, 잘되지 않았던 것들을 하나씩 막아나간 결과다. 처음부터 설계할 수 있었던 것은 단 하나도 없다.

첫 번째 글의 마지막에, Δ를 느끼고 싶다는 이야기를 썼다. 변화를 느껴서, 그 차이분을 관측하는 즐거움. 4개월이 지나서 생각하는 것은, 차이분을 관측하는 상대가 늘어났다는 것이다. AI가 자신을 얼마나 이해했는지뿐만 아니라, 자신과 AI의 상호작용 자체가 지난달보다 얼마나 좋아졌는지도 셀 수 있게 되었다.

키트는, 그 4개월 분량의 차이분(Δ)을 담은 것이다. 거기서부터의 Δ는, 당신의 리포지토리에서 키워보길 바란다.

이 키트는 필자가 실제로 운영하는 리포지토리에서 개인적인 내용을 제외하고 옮겨 적은 것입니다. 기사 중 수치는 필자의 리포지토리 실측(토큰은 개략치)입니다.

토론