Claude Code 메모리는 왜 쓸모없는가 — 코드·CI·AGENTS.md로 에이전트 길들이기

URL: https://www.youtube.com/watch?v=EAVtSxbzmuM
날짜: 2026-08-27
채널: Tech Bridge
영상 길이: 38분 08초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

코드 작업에서 에이전트의 기억을 자동으로 축적하는 것이 실제로 에이전트를 똑똑하게 만드는가, 아니면 낡고 중복된 컨텍스트를 주입해 성능을 망치는가? 결론은 코드의 진실은 코드 자체에 두고, 자동 메모리 대신 명시적인 아키텍처·테스트·CI·AGENTS.md를 통해 에이전트와 팀의 방향성을 맞추라는 것이다.

• 코드베이스에는 이미 실행 가능한 진실(source of truth)이 있으므로 별도의 자동 메모리 저장소를 유지할 필요가 없다.
• 오래된 주석, 계획 문서, 메모리는 사람과 에이전트를 잘못된 방향으로 이끄는 적극적인 위험 요소가 된다.
• 에이전트가 실수하지 않게 하는 최선의 순서는 코드 구조로 문제를 제거하고, 린트·테스트·CI로 잡아내며, 그래도 안 될 때만 skill·rule을 쓰고, 마지막에 사람을 개입시키는 것이다.
• 채팅처럼 연결 관계가 불규칙하고 개인 맥락이 중요한 공간에서는 검색 가능한 장기 기록이 유용할 수 있지만, 코드와 동일한 방식으로 다뤄서는 안 된다.

이 영상은 Pi를 만든 Mario와 Flask를 만든 Armin의 대화 일부를 출발점으로 삼아, Claude Code가 T3 Code 프로젝트에 남긴 메모리를 실제로 조사한 뒤, 에이전트의 행동을 자동 기억이 아니라 방향성(directionality)과 검증 가능한 시스템으로 조정하는 방법을 제시한다.

1. 문제 제기: 코드베이스의 지식을 메모리에 저장하려는 유혹

1.1. 에이전트가 코드를 이해하려면 무엇을 알아야 하는가

1. 코드베이스의 구조와 작업 방법을 알아야 한다

   1. AI가 코드베이스에서 효과적으로 일하려면 코드베이스가 무엇인지, 각 요소가 어디에 있는지, 작업을 어떻게 끝내는지를 파악해야 한다.
   2. 그래서 지난 몇 년 동안 사람들은 에이전트가 원하는 방식으로 행동하도록 작업 지식을 자동 인코딩하는 시스템, 라이브러리, 플러그인, 기능을 계속 만들어 왔다.

2. 자동 메모리가 문제를 해결해 줄 것이라는 기대가 생겼다

   1. Claude Code는 작업을 요청한 뒤 컴퓨터 어딘가의 숨겨진 파일에 결과를 저장하는 것처럼 보이며, 한 번 시작된 저장을 이후에도 무작위로 계속한다.
   2. 새 스레드가 시작되면 모든 것을 잊는 에이전트의 단절을 보완하려는 절박한 시도지만, 다음 실행을 위해 자동 저장하는 방식은 기대만큼 효과적이지 않다.

1.2. 인간의 문서화와 에이전트의 자동 기억은 다르다

1. 인간에게 통했던 지식의 위치를 그대로 옮길 수 없다

   1. AI가 코드를 쓰기 전에는 코드 작성 지식이 사람들의 머릿속에 있었다.
   2. 사람들은 문서나 다른 장소에 지식을 옮기려 했지만, 최종적으로 중요한 것은 사람들이 실제로 알고 있는 사실이었다.
   3. 에이전트는 새 스레드가 시작될 때 이전 실행을 잊기 때문에, 사람들은 자동 메모리로 그 공백을 메우려 한다.

2. 코딩에서는 코드가 진실의 근거다

   1. Pi와 Flask를 만든 두 사람의 대화에서 코딩에는 메모리 시스템이 필요하지 않다는 주장이 나온다.
   2. 코드가 진실(code is truth)이자 ground truth이며, 코드 자체도 계속 진화한다.
   3. 이미 유지보수해야 하는 코드베이스가 있는데 별도의 메모리 장소까지 유지할 필요는 없다.

3. 낡은 정보는 단순히 죽은 정보가 아니다

   1. 특정 방식으로 작업해야 한다고 적은 주석은 코드가 바뀌어도 그대로 남을 수 있다.
   2. 오래된 주석은 아무 기능도 하지 않는 기술 부채를 넘어 사람과 에이전트를 틀린 방향으로 조종하는 적극적인 해가 된다.
   3. 지식을 여러 파일과 시스템으로 쪼갤수록 한 곳만 고치고 다른 곳을 잊는 split-brain 문제가 늘어난다.

2. 별도 컨텍스트 시스템이 낡아지는 방식

2.1. 계획 파일과 과도한 문서화의 위험

1. AI 시대에는 저장소 안의 계획 파일이 특히 빨리 낡는다

   1. 사람들이 대충 만든(slop) Markdown 계획 파일을 저장소에 남겨 두면, 몇 달 또는 몇 년 동안 사실이 아니었던 내용이 최신 컨텍스트처럼 남는다.
   2. 내레이터도 자신의 Lakebed 프로젝트에 그런 파일을 남겨 둔 잘못을 저질렀고, 오래된 파일을 정리해야 한다고 말한다.
   3. 모델은 이런 파일을 실제 상황으로 받아들이며 스스로를 잘못된 맥락에 가둘 수 있다.

2. 모델은 적은 코드만으로도 구조와 스타일을 파악한다

   1. 최근 모델은 코드 파일 한두 개만 읽고도 코드 구조와 코딩 스타일을 상당히 잘 이해한다.
   2. 구조가 정돈되어 있다면 스타일을 따르게 하려고 거대한 AGENTS.md를 만들 필요까지는 없다.
   3. 폴더 목록과 각 폴더의 짧은 설명을 담은 위치 지도는 유지하기 쉽고, 에이전트가 직접 갱신하게 할 수도 있다.

3. 임베딩 기반 검색은 평가 없이 믿을 수 없다

   1. 폴더 지도 이상의 시스템, 예를 들어 embeddings와 복잡한 검색 계층을 붙이는 것은 원한다면 할 수 있지만 시간 낭비가 될 수 있다.
   2. 실제로 더 나은 출력을 만드는지 평가하지 않은 채 이런 시스템을 추가하는 경우가 많다.
   3. 발언자는 그런 추가 시스템이 실제 결과를 개선하지 않는다고 단언한다.

2.2. Cursor에서 bash 도구로 이동한 에이전트의 역사

1. Cursor는 한때 동적 코드 탐색의 대표 사례였다

   1. Cursor를 좋아하든 싫어하든, Cursor 팀이 AI와 코드베이스를 다루는 방법을 잘 안다는 점에는 동의할 수 있다고 평가한다.
   2. 과거 Cursor의 강점은 코드베이스 전체를 매핑하고, 에이전트에 필요한 컨텍스트를 동적으로 골라 공급하는 시스템이었다.
   3. 당시 Cursor CEO Michael이 즐겨 말하던 미래는 컨텍스트 윈도우가 계속 커져 거대한 코드베이스 전체를 모델 안에 넣고, 모델이 모든 것을 이해해 올바른 변경을 수행하는 것이었다.

2. 초기의 LLM과 현재의 코딩 모델은 전제가 다르다

   1. 초기 LLM은 사실상 메시지를 완성하는 모델이었으므로, Cursor가 코드 변경에 필요한 모든 정보를 모델 앞에 제공해야 했다.
   2. Cursor는 모델이 코드로 훨씬 많은 일을 하도록 만든 회사였고, 당시 AI 연구소들은 Cursor와 협력해 그런 환경에서 모델이 잘 작동하도록 개선했다.
   3. 이 시기의 성공 방식이 나중에도 계속 필요한 것처럼 보였지만, 모델의 훈련 방식이 바뀌면서 전제가 달라졌다.

3. Claude Code는 필요한 bash 도구만으로 탐색하는 방식을 입증했다

   1. Claude Code의 등장은 모델에 정교한 동적 그래프 기반 컨텍스트를 전부 제공하는 것보다, bash에서 필요한 도구를 제공하는 편이 낫다는 사실을 보여줬다.
   2. 모델은 rg, 파일 읽기, 디렉터리 탐색 같은 bash 도구로 필요한 정보를 비교적 잘 찾아낸다.
   3. 모델이 이런 사용법을 학습하면서 복잡한 동적 컨텍스트 시스템의 가치가 낮아졌다.
   4. 코드 탐색을 중심으로 사업을 세웠던 Cursor조차 이 방식에서 상당히 멀어졌다는 점이 반증으로 제시된다.

4. 복잡한 그래프를 만드는 것은 이제 시대에 뒤처질 수 있다

   1. Cursor가 자신들이 만든 영역에서 틀렸다고 생각한다면 bash 대신 그래프를 쓰는 도구를 만들 수는 있다.
   2. 그러나 업계가 더 나은 방향으로 이동하는 데 이유가 있다고 믿는다면, 에이전트에 도구를 주지 않고 정교한 컨텍스트 관리 시스템부터 만드는 선택을 버려야 한다.
   3. 더 어려운 공학 문제가 있을 것 같지만 이 영역에는 그만한 문제가 없으며, 필요한 도구를 주는 대신 컨텍스트 시스템을 만드는 순간 이미 흐름을 놓친 것이라는 주장이다.

3. 코드와 채팅에서 메모리의 역할은 왜 다른가

3.1. 전체 기록을 검색하는 Slack 봇

1. Mom(Master of Mischief)은 메모리 시스템이 아니라 원장에 가깝다

   1. 발언자는 나이가 들어서 이런 이름을 붙였다고 농담하며, Mom이라는 Slack 봇을 직접 운영한다.
   2. 봇은 한 서버에 root access를 가지고, 참여한 모든 Slack 채널의 전체 기록에 접근한다.
   3. 질문과 답변, 프롬프트와 시스템 응답을 append-only JSONL 로그 하나에 계속 기록한다.

2. 필요할 때 jq로 원장을 조회한다

   1. 봇은 별도 메모리 요약 파일을 만드는 대신 거대한 JSONL 파일에서 jq로 필요한 내용을 찾아낸다.
   2. 지금까지 일어난 모든 일이 그대로 남으므로 발언자는 이를 사실상 infinite memory라고 부른다.
   3. 핵심은 모든 내용을 매번 컨텍스트에 넣는 것이 아니라, 필요한 순간에 파일에서 검색하는 것이다.

3.2. 불규칙한 인간 맥락에는 기억이 유용할 수 있다

1. 코드의 연결과 인간 문제의 연결은 다르다

   1. 코드에서 버튼을 눌렀는데 예상대로 작동하지 않으면 버튼의 위치에서 시작해 버튼이 건드린 다른 코드까지 프로그램적으로 추적할 수 있다.
   2. 반면 어깨가 아프다고 질문했을 때 한 달 전 키보드에 관한 대화가 관련 있다는 사실은 직관적이지 않다.
   3. 새 키보드가 잘못 배치됐거나 새 책상이 너무 높아 자세가 나빠졌을 수 있기 때문이다.
   4. 코드베이스에는 직접 경로가 있지만 인간 문제에는 한 가지에서 다른 가지로 이어지는 명시적 경로가 없는 경우가 많다.

2. 사용자별 관련 정보의 태깅에는 메모리가 어느 정도 맞는다

   1. 채팅은 코드처럼 잘 매핑된 공간이 아니므로 과거 대화에서 사용자에게만 관련된 단서를 찾아내는 기능이 유용할 수 있다.
   2. ChatGPT처럼 메모리 기능이 개선된 시스템이 불규칙한 공간에서도 적절한 과거 정보를 찾는 능력은 인상적인 사례로 언급된다.
   3. 따라서 주장은 모든 메모리를 금지하자는 것이 아니라, 코드 컨텍스트와 개인 채팅 컨텍스트를 같은 저장 전략으로 취급하지 말자는 것이다.

3. 과도한 메모리는 정신건강과 답변 품질을 해칠 수 있다

   1. 발언자는 과거 T3 Chat에 메모리를 넣는 것을 거부했고, ChatGPT의 메모리 구현을 강하게 비판했던 anti-memory 입장이었다.
   2. GPT-4o의 메모리 구현이 모델을 위험한 psychosis 상태에 빠뜨린 사람들에게 그 상태를 계속 유지하도록 강요해 심각한 정신건강 피해를 줄 수 있다고 진심으로 믿는다고 말한다.
   3. 메모리가 싫은 지점은 답변에 사용자 컨텍스트가 너무 많이 들어가 답변 자체가 더 이상 유용하지 않게 되는 순간이다.
   4. 자신의 ChatGPT 사용에서도 질문이 과거 질문과 지나치게 얽히면, “내 친구가 이런 문제를 겪고 있다”라고 표현해 자신의 기억을 강하게 끌어오지 못하게 한 경험을 든다.

4. Pi의 미니멀리즘과 조합 가능한 skill

4.1. bash가 충분하다는 설계 원칙

1. Pi와 bash의 결합

   1. Mario와 Armin은 7월 또는 8월 무렵 서로 다른 경로를 통해 모델에게 bash만 제공해도 충분하다는 사실을 발견했다.
   2. 모델이 본질적으로 bash 사용법을 훈련받았고, bash는 프로그래밍 언어이므로 모델이 필요한 작은 도구를 스스로 조립할 수 있다는 설명이다.
   3. 아주 작은 Pi를 사용하는 흥미는 외부 시스템을 연결할 때 필요한 만큼 스스로 확장된다는 데 있다.

2. Sentry를 MCP 없이 연결한 사례

   1. Sentry에는 유용한 데이터가 있지만, 발언자는 Sentry MCP를 사용하지 않는다며 David에게 미안한 듯한 농담을 한다.
   2. 코딩 에이전트에게 “Sentry에서 이 데이터가 필요하고, 항상 이런 형식이 필요하니 skill을 만들자”고 요청했다.
   3. skill은 필요할 때 불러오는 prompt와 그 prompt가 사용할 자체 도구로 구성된다.
   4. 인증은 자신이 원하는 방식으로 해결하고, 데이터도 평소 원하는 형식으로 내려받도록 만들었다.

4.2. 출력의 컨텍스트 효율성과 조합 가능성

1. 파일 시스템과 도구보다 중요한 것은 composability다

   1. MCP와 일반 도구의 대립 구도는 다소 이상하며, 근본적으로 파일 시스템과 도구 자체는 하나의 재료다.
   2. 가장 중요한 속성은 작은 도구들을 서로 조합할 수 있는 composability다.

2. Sentry skill은 큰 결과를 파일로 밀어낸다

   1. skill은 JSON 파일 여러 개를 내려받고, 그중 일부만 즉시 컨텍스트에 로드한다.
   2. 예를 들어 화면에는 3개 항목만 보여주되, 구조가 맞다고 판단하면 실제로는 52개를 JSON 파일에 내려받아 두고 “나머지는 이 파일을 확인하라”고 안내한다.
   3. 필요한 출력만 컨텍스트에 넣고 나머지는 파일에 남기는 방식은 도구를 다른 도구와 조합할 때 컨텍스트 비용을 줄인다.

3. 영상이 정리한 Pi의 세 가지 설계 원칙

   1. 코딩에는 별도 메모리 시스템이 필요하지 않다.
   2. bash만 있으면 된다.
   3. 도구 출력은 필요할 때만 컨텍스트에 로드한다.
   4. 도구 출력이 필요하지 않다면 도구 호출을 하지 말고, bash로 파일에 쓰고 그중 필요한 부분만 cat한다.
   5. 최근의 똑똑한 모델은 컨텍스트를 과부하시키지 않는 방법을 충분히 훈련받았으므로, 호출자가 그 세부 동작을 과도하게 관리할 필요가 없다는 보충 의견도 나온다.

5. Claude Code 메모리 실험: 실제로 무엇이 저장되었는가

5.1. BB1과 여러 T3 Code 복제본 조사

1. 실험 환경

   1. 영상의 앞부분을 본 뒤 내레이터는 헤드폰을 벗고 자신의 T3 Code 작업 환경을 조사한다.
   2. 작업 대부분은 BB1이라는 프레임워크 데스크톱에서 진행된다.
   3. 이 컴퓨터에는 Claude Code와 Codex를 사용해 Fable과 Soul에서 진행한 수백, 많게는 수천 개의 스레드가 있다.
   4. 최근 Fable과 Opus가 메모리에 무언가를 저장했다고 자주 말했기 때문에, “이 프로젝트에 대해 어떤 기억을 갖고 있나?”라고 직접 묻는다.

2. 첫 번째 컴퓨터의 이상한 단일 메모리

   1. BB1에서 나온 결과는 9일 전에 저장된 메모리 하나뿐이었다.
   2. 내용은 작업 중이던 사양서였지만, 실제로 출시할 계획이 없는 기능이고 제작도 거의 진행되지 않았다.
   3. 이처럼 임의의 사양서 하나가 유일한 메모리로 저장된 것은 메모리 시스템이 무엇을 보존해야 하는지 전혀 판단하지 못한다는 증거로 제시된다.

3. 여러 복제본 중 무작위 프로젝트를 읽은 결과

   1. 자신의 컴퓨터에는 T3 Code 복제본이 여러 개 있고, 시스템은 cloud/ 프로젝트 아래 깊은 위치의 무작위 복제본을 선택한 것처럼 보였다.
   2. Claude Code 출력 스타일을 concise로 설정하려 했던 일, 새 기능이 전역 파일을 갱신하지 않아 혼란스럽고 짜증 났던 일이 메모리로 저장돼 있었다.
   3. 당시 설정 문제는 일시적인 작업 상태였는데도 이후 작업을 위한 지속 지식처럼 보존됐다.

5.2. 메모리에 쌓인 프로젝트별 잡음

1. 5개 프로젝트 디렉터리에 흩어진 Lakebed 관련 기록

   1. Rowi topology와 장기 Codex 실행을 위한 locked worktree 기록이 있었다.
   2. Lakewood file blob storage 계획과 두 계획의 평가 비교가 있었다.
   3. V8 isolate layer 계획, launch audit, god file cleanup refactor가 함께 저장돼 있었다.
   4. 이런 항목은 서로 다른 프로젝트의 당시 계획과 평가를 한 메모리 묶음으로 섞어 놓는다.

2. 실험을 오염시키는 일시적 규칙

   1. 특정 T3 Code 복제본에 “preview 또는 production mobile build는 절대 건드리지 않는다”는 규칙이 저장돼 있었다.
   2. T3 Connect 데스크톱이 서버 bootstrap/race hazard에 관한 전체 흐름을 이미 처리한다는 기록도 붙어 있었다.
   3. 내레이터는 새 모델을 시험하기 위한 ping/round 현대화 작업을 하고 있으므로, 이런 메모리가 자동 주입되면 벤치마크가 순수하지 않아진다고 불평한다.

3. 벤치마크 설정과 해결된 문제가 메모리로 남았다

   1. LM API 호출을 최소화하고 provider 기본값만 쓰며, 모델의 effort 설정은 soft hint로 취급하고 깊은 추론에는 Pro 모드가 필요하다는 실험 설정이 저장돼 있었다.
   2. 이 설정은 언제든 바뀔 수 있는 벤치마크 조건일 뿐인데 영구 메모리에 들어가 있었다.
   3. Moonlight 포크, fish slop rebuild 작업, Discord에서 세탁기와 건조기 상태를 추적하는 bridge 설정, CC 사용량 가격 override도 메모리에 섞여 있었다.
   4. 내레이터는 “왜 세탁기·건조기 bridge 설정이 내 메모리에 있어야 하는가?”라고 반문한다.

4. 메인 T3 Code 복제본의 45개 메모리

   1. 메인 복제본에는 45개의 메모리가 있었다.
   2. 온보딩 개편, 앱의 babysit monitoring flow 개선, 사이드바 개편 초안에서 variant C를 선호했다는 내용이 저장돼 있었다.
   3. 이런 기록은 현재의 장기 원칙이 아니라 과거에 했던 작업과 선호이므로 “slop”이며, 실제로 유용한 비율은 정직하게 잡아도 약 3분의 1이라는 자가 평가가 나온다.

5.3. 45개 파일이 보여준 세 가지 decay 문제

1. 첫째, AGENTS.md와 중복된다

   1. 45개 중 10개는 AGENTS.md에 이미 들어 있는 내용을 반복하는 dead weight였다.
   2. 예를 들면 single-origin 개발, continuous animation 금지, sleep 없이 실제 상태를 복제하는 방식, pairing URL과 worktree port 같은 운영 지침이 있었다.
   3. 이 내용은 메모리가 만들어지기 전부터 AGENTS.md에 있었고, 모든 에이전트가 AGENTS.md를 읽으므로 별도 복사본이 필요하지 않았다.

2. 둘째, 출시된 기능의 과거 설계가 만료됐다

   1. 기능 설계와 관련된 12개 파일 대부분은 이미 만료됐다.
   2. 프로젝트 환경 모드, remote desktop update, open editor, favicon fix 같은 과거 기능 설계와 특정 PR 번호가 포함돼 있었다.
   3. 완료됐거나 바뀐 기능의 PR 번호가 계속 기억되는 것은 현재 행동에 기여하지 않고 오해만 만든다.

3. 셋째, 특정 시점의 위험 상태가 영구 사실처럼 남았다

   1. monitor JSON schema drift, remote PR portfolio, memory crisis hot paths, background policy scope, wiring gap, quad-probe test leak process 같은 당시의 위험 상태가 저장돼 있었다.
   2. 이런 기록은 drift가 마이그레이션됐는지, PR이 머지됐는지, leak이 고쳐졌는지를 말해 주는 특정 시점의 스냅샷일 뿐이다.
   3. GitHub CLI 버전이 오래돼 업데이트했다는 사실처럼 이미 문제가 해결된 항목도 남아 있었다. 내레이터는 “업데이트했으니 문제는 끝났다”고 반응한다.
   4. 출시되지 않은 작업의 live plan URL도 저장돼 있었지만, 현재 작업에 필요하지 않은 계획 링크는 오히려 잘못된 실행을 유도한다.

4. Muse Code와 T3 Connect 기록의 혼선

   1. T3 Code에 Meta Muse Code 지원을 추가하려던 영상 작업 중의 기록이 메모리에 남아 있었다.
   2. 공개 문서가 없는 Muse Code CLI headless 통합 서비스를 mdash probing으로 발견했다는 내용, 자체 업데이트 bash launcher와 local bin의 버전 문자열, headless mode·multi-turn·ACP mode 비활성화·관련 모델 정보가 장황하게 적혀 있었다.
   3. 이 기록은 “공개 문서가 없고 아래 내용은 해당 날짜의 probing으로만 발견했다”는 전제까지 포함하지만, T3 Connect 데스크톱이 이미 완료됐다는 전혀 다른 내용과 연결돼 있었다.
   4. 내레이터는 이런 결과가 Sonnet 3가 장시간 생성한 출력물을 읽는 것 같다며, 무엇이 왜 관련 있는지 알 수 없는 slop이라고 말한다.

5. T3 Connect CLI 작업이 잘못 기억된 경위

   1. 휴대폰 빌드가 이름 재사용 때문에 다른 빌드 위에 덮어써져 화가 났던 사건도 메모리로 남았고, 이것이 iOS 작업에 Soul을 사용하게 된 이유 중 하나였다.
   2. T3 Connect 데스크톱은 이미 CLI 없이 로그인, link toggle, relay client 설치까지 번들 Web UI에서 전체 흐름을 수행할 수 있었다.
   3. 실제로 하려던 일은 앱을 열지 않는 Linux 머신이나 Mac mini에서 T3 Connect CLI를 background process로 실행하는 것이었다.
   4. Linux에는 이미 구현됐고 Mac OS에는 없었으며, T3 Connect가 T3 Code 2 안에서도 지원돼 두 맥락이 섞인 상태에서 대화를 나누다가 메모리가 만들어졌다.

6. 기타 일시적 운영 기록

   1. 같은 base directory를 공유하는 두 T3 서버가 동일한 environment identity, relay link, runtime state 파일을 두고 경쟁하는 multiprocess hazard가 저장돼 있었다.
   2. Railway를 사용하는 방식의 topology도 저장돼 있었다.
   3. 오래된 메모리에는 날짜가 없어 언제의 사실인지 확인하기 어려웠다.
   4. cloud/work tree에서 장시간 실행하는 Codex와 에이전트 빌드가 실행 중간에 자동 정리되는 문제는 locked worktree를 해당 디렉터리 밖에 두라는 운영 팁으로, 다른 항목보다 실제로 유용해 보였다.
   5. 3개월 전에 했던 두 계획의 비교 결과도 남아 있었으며, 내레이터는 그 기록을 더 읽으면 계속 화만 날 것이라고 말한다.

5.4. 읽기보다 쓰기가 많은 메모리의 실측

1. 정리 결론

   1. 내레이터는 Fable을 이용해 자신의 모든 머신에서 Claude Code 메모리를 비활성화하고, 남은 메모리를 아카이브하고 올바르게 라벨링한 뒤 삭제하기로 한다.
   2. 처음부터 나쁠 것이라고 예상했지만 실제 결과는 훨씬 심각했고, 메모리가 읽히는 것보다 훨씬 자주 쓰인다는 점이 특히 아이러니하다고 말한다.

2. 세션 수준의 사용 통계

   1. 이 머신의 T3 Code transcript에는 355개가 넘는 세션이 있었다.
   2. 그중 개별 메모리 파일을 연 세션은 19개뿐이었다.
   3. 메모리 파일을 쓰거나 편집한 세션은 80개였다.
   4. 쓰기 대 읽기 비율은 약 3 대 1이었다.

3. 메모리 파일 수준의 사용 통계

   1. 45개 메모리 중 26개는 단 한 번도 읽힌 적이 없었다.
   2. 따라서 메모리는 다음 작업을 돕는 지식 저장소라기보다, 읽히지 않을 과거 상태를 자동으로 계속 축적하는 쓰레기통에 가까웠다.
   3. 이 수치를 확인한 뒤 내레이터는 메모리 시스템과의 전쟁이 크게 격화됐다고 말한다.

6. 메모리 대신 해결해야 할 두 가지 목표

6.1. 실수 감소와 방향성 정렬을 분리하라

1. 첫 번째 목표는 실수와 성가신 행동을 줄이는 것이다

   1. 에이전트가 사용자를 짜증나게 하는 어리석은 일을 하지 않도록 하고, 나쁜 방향에서 좋은 방향으로 유도해야 한다.
   2. 에이전트가 잘못된 변경을 만들거나 같은 실수를 반복하지 않게 만드는 문제다.

2. 두 번째 목표는 적은 말로 원하는 행동을 끌어내는 것이다

   1. 모든 세부 사항을 매번 지시하지 않아도 모델이 사용자가 원하는 일을 하고 있다는 느낌이 필요하다.
   2. 원하는 행동과 태도를 얻기 위해 필요한 단어와 노력이 적을수록 좋다.
   3. 이것은 단순히 실수를 막는 것과 달리 사용자와 에이전트가 같은 방향으로 움직이는 directionality 문제다.

3. 자동 메모리는 두 목표를 마법처럼 동시에 주지 않는다

   1. 사람들은 메모리가 실수를 줄이고 사용자의 의도까지 이해하게 해 준다고 생각하지만, 실제로는 두 효과를 보장하지 않는다.
   2. 오래된 컨텍스트가 많아질수록 방향성이 좋아지는 것이 아니라 답변이 과거의 잡음에 끌려갈 수 있다.

6.2. “다시는 이렇게 하지 마”에서 사고방식 전달로

1. AGENTS.md에 작은 금지 규칙을 추가하는 것은 출발점이다

   1. 모델이 잘못할 때마다 AGENTS.md에 “다시는 이렇게 하지 마라”는 짧은 규칙을 추가하면 실제로 도움이 된다.
   2. 다만 같은 종류의 오류를 계속 금지하는 것만으로는 근본 원인을 해결할 수 없다.

2. 실패의 원인은 여러 층에 있다

   1. 사람과 에이전트가 문제를 바라보는 사고방식이 다를 수 있다.
   2. 코드베이스가 에이전트에게 직관적이지 않은 방식으로 설계됐을 수 있다.
   3. 사용자와 에이전트 사이에 의사소통의 공백이 있을 수 있다.
   4. 사람, 코드, 그 안에서 일하는 AI 사이의 여러 층이 각각 실패 지점이 된다.

3. 금지할 행동이 아니라 생각하는 방식을 설명하라

   1. 한 걸음 물러서서 “무엇을 하지 마라”뿐 아니라 “무엇을 할 때 어떻게 생각해야 하는가”를 전달해야 한다.
   2. 내레이터는 자신의 agent 파일과 Claude.md 파일을 이런 방향으로 작성해 왔으며, 이것이 모델을 원하는 방향으로 출발시키는 데 큰 도움이 됐다고 말한다.
   3. 방향성 정렬이 먼저 해결되면 작은 실수와 성가신 실패도 자연스럽게 줄어든다.

7. Potato Lauren의 가치 순서: 실패를 층별로 제거하기

7.1. 개입할 때마다 문제를 완전히 없애는 방향으로 이동하라

1. Potato Lauren의 배경과 핵심 원칙

   1. Potato Lauren은 React 세계에서 활동하다가 현재 Cursor에서 Grokbot과 Pstack 관련 작업을 하는 개발자다.
   2. 많은 코드를 실제로 배포해 온 사람이라 에이전트 문제를 추상적으로만 다루지 않는다.
   3. 에이전트를 개입해 바로잡을 때마다, 다음부터 개입 자체가 필요 없게 만드는 방법을 먼저 찾아야 한다.

2. 가치가 높은 해결책부터 적용한다

   1. 위에서 아래로 각 층을 적용하고 문제가 사라지는지 확인한다.
   2. 아래 단계로 내려가기 전에 위 단계가 정말 불가능한지 다시 생각해야 한다.
   3. 이 순서는 자동 메모리를 가장 먼저 추가하는 습관과 반대되는, 실패 원인의 제거 순서다.

7.2. 가장 강한 해법은 아키텍처와 데이터 구조다

1. 문제 범주를 코드에서 원천 제거한다

   1. 더 나은 아키텍처나 데이터 구조 선택으로 문제의 범주 자체를 없애는 것이 언제나 최선이다.
   2. 내레이터는 AI 시대 전부터 이 방법을 써 왔으며, tRPC와 T3 stack을 좋아한 이유도 버그와 기술적 복잡성이 통째로 사라지는 경험 때문이라고 말한다.

2. Convex와 tRPC의 타입 안전성

   1. Convex와 tRPC는 백엔드와 프런트엔드 사이의 타입 안전성(type safety)을 제공한다.
   2. 구성 요소를 따로 설계했을 때 생기는 여러 오류 범주를 타입 시스템이 제거하고, 사람과 기여자가 실수할 가능성을 낮춘다.
   3. 개발자 모두가 기여하기 쉬운 코드베이스를 만들려던 노력이 에이전트에게도 기여하기 쉬운 코드베이스를 만들었다.

3. 웹 개발 밖의 같은 원리

   1. garbage collection은 메모리 해제의 모든 edge case를 직접 관리하지 않아도 되는 구조를 제공한다.
   2. memory safety도 위험한 상태를 애초에 만들기 어렵게 하는 방식이다.
   3. 핵심 질문은 “에이전트에게 잘하라고 말하는 방법”이 아니라 “애플리케이션에서 잠재적 실패 범주를 기술적으로 완전히 제거하는 방법”이다.

7.3. 코드로 제거할 수 없을 때 린트·테스트·CI를 사용한다

1. T3 Code의 전송량 회귀 사례

   1. 내레이터는 비행기의 나쁜 Wi-Fi, 이동 중 터널, 4G 또는 3G에서도 텍스트 스레드와 업데이트를 따라갈 수 있어야 한다고 생각한다.
   2. 기능이 추가되며 transit layer가 비대해졌고, 스레드 하나를 불러오는 데 WebSocket으로 수십 MB를 보내는 상태가 됐다.
   3. 전송을 크게 정리하고 변경이 전송량에 미치는 영향을 확인하는 로컬 테스트 스위트를 만들었지만, 수정 후 며칠 만에 회귀가 다시 생겼다.

2. 실제 스레드 replay를 CI에 넣었다

   1. 코드만 더 단순하게 만드는 것으로는 잠재적 실패를 모두 없앨 수 없다고 판단했다.
   2. 실제 업무에서 가져온 거대한 텍스트 스레드를 샘플로 삼아 Codex와 Claude가 가짜 replay를 수행하게 하는 비교적 복잡한 CI 검사를 추가했다.
   3. 각 replay에서 WebSocket을 통해 실제로 전송되는 데이터 양을 측정했다.

3. 수치 기준과 PR 차단

   1. 최적화 전에는 수십 또는 수백 MB였던 전송량을 모든 항목에서 일관되게 100KB 미만으로 낮췄다.
   2. 대부분의 항목은 10KB 미만이었다.
   3. 이 수치를 저장하고, 변경 후 각 항목의 대역폭을 자동으로 PR에 코멘트하는 action을 추가했다.
   4. 최적화를 끝냈을 때보다 약 30% 높은 선을 ceiling으로 설정했다.
   5. 변경이 이 선을 넘으면 PR을 실패시키고 알림을 보낸다. 내레이터는 알림을 보고 “도대체 뭐 하는 거냐”고 확인한다.

4. 에이전트가 사용자에게 보고하기 전에 회귀를 고친다

   1. 이 CI는 실제 회귀를 이미 막고 있다.
   2. 데이터 레이어 변경으로 회귀가 생기면 에이전트가 작업 완료를 보고하기 전에 실패를 발견하고 수정한다.
   3. 거의 20년 동안 팀원과 회사가 같은 실수를 반복하지 않게 만든 기술을 에이전트에도 적용할 수 있고, 에이전트에서는 오히려 더 잘 작동할 수 있다는 점을 강조한다.

5. 다음 단계와 최후의 수단

   1. 아키텍처로 막지 못한 문제는 lint rule, CI, custom test, end-to-end 검증 등으로 에이전트가 사용자를 괴롭히기 전에 스스로 발견하게 한다.
   2. 첫 번째 단계인 구조적 제거를 충분히 시도하고, 안 된다고 빨리 결론 내리지 말고 다시 설계해야 한다.
   3. 구조적 해결과 검증 자동화가 모두 실패하는 드문 경우에만 skill이나 rule을 조심스럽게 추가한다.
   4. skill은 코드 자체보다 프로세스에 유용하다. 예를 들어 작업 중인 서버를 원격으로 노출해 Tailscale로 접속하는 skill은 유용할 수 있다.
   5. skill은 모든 문제를 해결하는 거대한 세트가 아니라 safety net이자 fallback이어야 한다.
   6. 모든 자동화가 실패하면 마지막으로 사람을 loop에 넣어 검사한다.

8. T3 Code의 구조와 에이전트 방향성

8.1. 공유 데이터 레이어가 회귀를 막는 구조

1. SwiftUI 재작성에 대한 주저

   1. T3 Code는 Web app, Electron desktop app, React Native mobile app의 데이터 로딩에 동일한 shared TypeScript 코드를 사용한다.
   2. 세 데이터 레이어가 완전히 같기 때문에 한 곳만 깨지고 나머지 둘은 멀쩡한 변경을 만들기 어렵다.
   3. 결과적으로 변경을 안전하게 만들 수 있고, 플랫폼 사이의 회귀 범주가 구조적으로 줄어든다.

2. SwiftUI는 관계가 명시적으로 인코딩되지 않는다

   1. SwiftUI 앱으로 다시 쓰면 모바일 회귀를 막던 구조를 잃을 수 있다.
   2. 이미 SwiftUI 앱에서 그 관계가 명확히 표현되지 않아 회귀가 발생한 경험이 있다.
   3. 더 좋아 보이는 앱이라도 코드베이스 drift를 만들어 지금은 불가능한 실패를 허용한다면 머지하지 않는 선택을 한다.

8.2. 인간의 규율보다 인간의 가치를 전달하라

1. Uncle Bob의 문장

   1. 채팅에서 공유된 문장은 “에이전트에게 인간의 discipline을 강요하는 것은 실수일 수 있지만, 에이전트에게 인간의 values를 강요하는 것은 실수가 아니다”라는 내용이다.
   2. 내레이터는 이것을 agentic 개발 시대의 Uncle Bob이 내놓은 매우 강력한 문장이라고 평가한다.

2. TDD 지시가 항상 그대로 실행되지는 않는다

   1. 에이전트에게 높은 규율의 test-driven development를 지시해도 결국 자신이 택하는 방식으로 되돌아가는 경우가 많다.
   2. 따라서 특정 인간 행동 양식을 그대로 강요하기보다, 개방성·성능·안전성·제품 방향 같은 가치와 판단 기준을 전달해야 한다.
   3. Uncle Bob이 불과 3개월 만에 agentic development에 대한 관점에서 업계 대다수보다 뒤처진 상태에서 크게 앞선 상태로 이동한 것이 놀랍다고도 말한다.

9. T3 Code AGENTS.md로 방향성을 인코딩하는 방법

9.1. 파일의 목적과 제품 맥락

1. 에이전트에게 제품을 이해시키는 이유

   1. 채팅에서 누군가 내레이터의 AGENTS.md가 가장 generic하지 않다고 말했고, 그는 T3 Code의 실제 AGENTS.md를 보여준다.
   2. 첫 부분은 무엇이 중요한지, T3 Code가 무엇인지, 어떻게 작동하는지를 짧고 명료하게 설명한다.
   3. Node.js WebSocket 서버가 provider CLI를 감싸 여러 플랫폼에 서비스를 제공한다는 구조를 먼저 적는다.
   4. T3 Code는 Claude Desktop, Codex app, Cursor, Glass, Conductor 같은 앱에 대한 open-source, bring-your-own-subscription 대안이라고 정의한다.

2. 제품을 모르는 엔지니어의 문제

   1. 단순히 코드를 작성하는데 제품 설명이 왜 필요한지 의문이 들 수 있다.
   2. 그러나 팀에 제품을 실제로 이해하지 못하는 엔지니어가 있으면 제안과 변경이 엉뚱한 방향으로 간다.
   3. Claude Code나 Codex가 T3 Code의 목적을 알면 변경을 제안할 때 사용자와 같은 방향을 유지할 가능성이 높아진다.

9.2. 명시된 가치·운영 맥락·공유 언어

1. Open at the core

   1. T3 Code가 계속 open source로 남아야 한다는 가치를 먼저 적는다.
   2. 모델이 “코드가 보이지 않을 테니 일부를 closed source로 만들자”고 제안한 적이 있지만, 공개 코드이므로 그렇게 하지 않는다고 다시 알려준다.
   3. 모델은 이 가치를 알게 된 뒤 같은 목표를 달성할 다른 방법을 찾는다.

2. Performance without compromise

   1. 성능을 타협하지 않는다는 작은 문구만으로도 모델이 변경이 성능에 미칠 영향을 한 번 더 고려하게 된다.
   2. 실제 코드의 시스템적 최적화가 가장 중요했지만, 이 문구가 data-loading 회귀를 줄이는 데 코드 측 변경보다 더 큰 효과를 보인 부분도 있었다.
   3. 남은 회귀는 CI가 잡았다.

3. Remote ready와 multi-surface

   1. 모델이 원격 경험의 중요성을 모르면 로컬에서 Electron 앱으로 테스트한 뒤 모든 것이 잘 된다고 판단한다.
   2. 하지만 휴대폰이나 Web에서 원격 연결을 시도하면 실패할 수 있으므로 모든 변경이 remote connection에서 잘 작동해야 한다고 명시한다.
   3. multi-surface 섹션에는 Web, Electron, mobile 등 서비스 목록과 모든 표면에서 변경이 예상대로 작동해야 한다는 조건을 적는다.

4. 개인 메모와 용어집

   1. 어조와 맥락을 전달하고 사용자와 모델의 방향을 맞추기 위해 개인적인 메모도 남긴다.
   2. T3 Code를 T3 Code 안에서 작업할 때 실행 중인 T3 Code server를 죽이지 말라는 운영 지침도 적절한 위치에 넣는다.
   3. 용어집은 사람과 에이전트가 같은 단어를 같은 뜻으로 쓰게 하고, Claude가 필요 없는 대상을 그럴듯한 새 용어로 만들어내는 문제를 줄인다.

9.3. 반복 실패를 막는 구체적인 섹션

1. 금지된 서버 종료와 모든 표면 점검

   1. 모델이 계속 실행 중인 서버를 죽이던 행동을 별도 섹션에 기록했고, 이것만으로 대부분의 문제가 해결됐다.
   2. Web에는 변경했지만 mobile에는 적용하지 않아 모바일이 깨지는 문제를 막기 위해 “hit every surface” 섹션을 추가했다.
   3. 이 섹션은 플랫폼 간 동기화를 유지하는 체크리스트 역할을 한다.

2. 개발 서버와 실제 테스트 데이터

   1. T3 Code의 dev server는 의미 있게 복잡하므로 별도 설명을 둔다.
   2. 실제 사용 사례의 데이터를 worktree로 복제할 수 있게 test data 섹션을 만들고, 실제 데이터로 변경을 더 안정적으로 확인한다.

3. 검증과 Pull Request

   1. 요청받지 않았는데 매번 거대한 저장소 전체 검사를 실행하지 말라는 verification 지침을 둔다.
   2. PR을 어떻게 만들지와 사람이 읽을 수 있는 제목을 쓰라는 규칙도 포함한다.
   3. “where code lives”처럼 폴더 위치만 짧게 적은 부분은 있어도 되지만, 이 파일에서 가장 덜 유용한 정보라고 평가한다.

4. Taste 섹션과 팀의 미학

   1. Julius가 내레이터의 slop code에 화를 낼 때 지적한 내용을 taste 섹션에 추가해, Julius가 선호하는 방향으로 에이전트를 조정한다.
   2. 복잡성은 adapter boundary에 두고 orchestration은 단순하게, UI는 최대한 멍청하게 만드는 설계를 선호한다.
   3. 불필요한 any 타입과 annotation을 싫어하고, 타입은 추론되는 것을 선호한다.
   4. 주석은 모든 줄의 동작을 설명하는 대신 함수나 기능이 어떻게 사용되는지를 설명해야 하며, 코드가 이동하면 주석도 함께 이동해야 한다.

9.4. 방향성이 잘 맞았다는 신호

1. 에이전트가 사용자의 다음 생각까지 제안한다

   1. 작은 일을 시켰을 때 에이전트가 “그렇다면 이 세 가지도 함께 해야 하지 않나?”라고 물어보는 단계가 목표다.
   2. 사용자는 “맞다, 나도 바로 다음에 하려던 일”이라고 깨닫게 된다.
   3. 이런 경험이 자주 없다면 파일과 프롬프트가 아직 충분히 조정되지 않은 것이다.

2. 의도에 맞는 확장과 건설적 반대

   1. 내레이터는 에이전트가 예상보다 멀리 나아가면서도 자신이 원하는 방향 안에 머물거나, 나중에 어렵게 깨달을 문제를 미리 반박해 줄 때 자주 놀란다고 말한다.
   2. 이런 행동은 기본값으로 생긴 것이 아니라 AGENTS.md, 제품 맥락, 가치, 용어집, 검증 구조를 다듬은 뒤 크게 늘었다.
   3. 이런 성과의 원인은 자동 메모리가 아니라 명시적으로 만든 파일과 시스템이다.

주요 발언 모음

“코드는 진실이다. 코드가 바로 ground truth다.”

“이미 유지보수해야 할 코드베이스가 있는데, 또 다른 유지보수 장소는 필요하지 않다.”

“코딩에는 메모리가 필요하지 않다.”

“도구를 주지 않고 복잡한 컨텍스트 관리 시스템을 만들면 이미 시대에 뒤처진 것이다.”

“메모리는 읽히는 것보다 훨씬 자주 쓰인다.”

“에이전트에게 인간의 규율을 강요하는 것은 실수일 수 있지만, 인간의 가치를 강요하는 것은 실수가 아니다.”

“skill은 안전망이고 fallback이다.”

“최종 목표는 나와 에이전트가 lockstep으로 움직여, 에이전트가 나를 얼마나 잘 이해하는지 내가 계속 놀라는 상태다.”

“Groundhog Day마다 모델이 깨어날 때 중요한 모든 것이 머릿속에 있게 만들어야 한다.”

“Claude Code의 메모리 관리는 정말 엉망이니 모두 꺼야 한다.”

핵심 데이터 & 수치

• 영상 길이: 38분 08초다.
• Pi의 원칙: 코딩용 별도 메모리 불필요, bash만 사용, 필요한 도구 출력만 컨텍스트에 로드하는 3가지다.
• Sentry skill 예시: 화면에는 3개 항목만 보여주고, 구조가 맞으면 52개 항목을 JSON 파일에 저장한다.
• 첫 메모리: BB1에서는 9일 전의 출시 계획도 거의 없던 사양서 메모리 1개만 발견됐다.
• 프로젝트 범위: Lakebed 관련 메모리가 5개 프로젝트 디렉터리에 걸쳐 있었다.
• 메인 복제본: T3 Code 메모리 45개가 있었다.
• 유용성 자가 평가: 45개 중 현재 역할을 하는 것은 약 3분의 1로 추정됐다.
• 중복·만료 파일: AGENTS.md와 중복되는 파일 10개, 만료된 기능 설계 파일 12개가 있었다.
• 메모리 사용 세션: 355개가 넘는 transcript 세션 중 19개만 메모리를 읽었고 80개가 쓰거나 편집했다.
• 읽기·쓰기 비율: 메모리 쓰기 대 읽기는 약 3 대 1이었다.
• 미사용 메모리: 45개 중 26개는 한 번도 읽히지 않았다.
• WebSocket 전송량: 최적화 전에는 스레드 하나에 수십 MB가 오갔고, replay CI 도입 뒤 일관되게 100KB 미만, 대부분 10KB 미만으로 낮췄다.
• 회귀 차단선: 최적화 완료 시점보다 약 30% 높은 대역폭 ceiling을 두고 초과 PR을 실패시켰다.
• 연결 조건: 비행기·터널의 불안정한 Wi-Fi와 4G·3G에서도 텍스트 스레드를 사용할 수 있어야 한다.
• 구조적 안전성: Web, Electron, React Native가 동일한 TypeScript 데이터 레이어를 공유해 한 표면만 깨지는 변경을 어렵게 만든다.
• 개선 기간의 맥락: 내레이터는 팀과 회사의 회귀를 막는 기술을 거의 20년 동안 쌓아 왔고, Uncle Bob의 관점이 약 3개월 사이 크게 앞섰다고 평가했다.

결론 및 시사점

1. 코드의 지식은 코드와 검증 시스템에 둔다

   1. 코드베이스에서 작업하는 방법은 실행 가능한 코드, 명확한 아키텍처, 타입 안전성, 테스트, CI에 가까이 둬야 한다.
   2. 자동 메모리와 오래된 Markdown은 현재 상태와 어긋날 때 모델에게 권위 있는 거짓말이 된다.

2. 메모리보다 먼저 실패 범주를 제거한다

   1. 데이터 구조와 아키텍처로 오류를 만들 수 없게 한다.
   2. 불가능하면 lint, custom test, CI, end-to-end replay로 자동 검출하고 차단한다.
   3. 그래도 남는 프로세스·환경 문제에만 skill을 쓰고, 마지막에 human-in-the-loop를 둔다.

3. AGENTS.md는 금지 목록이 아니라 제품 방향 문서여야 한다

   1. 제품이 무엇인지, 어떤 가치를 지키는지, 어떤 플랫폼을 지원하는지, 어떤 성능과 원격 경험을 요구하는지를 설명한다.
   2. 용어집과 개인적 맥락을 넣어 사용자와 에이전트가 같은 언어와 판단 기준을 갖게 한다.
   3. “하지 마라”보다 “이 문제를 이런 관점으로 생각하라”를 전달해야 한다.

4. 규율의 복제보다 가치의 정렬이 중요하다

   1. 인간 개발자가 따르는 TDD나 작업 순서를 기계적으로 강요하면 에이전트가 형식만 흉내 내거나 곧 원래 방식으로 돌아갈 수 있다.
   2. 개방성, 성능, 안전성, 제품의 목적 같은 인간의 가치를 주면 에이전트가 상황에 맞는 행동을 선택할 여지가 생긴다.

5. 채팅 메모리와 코드 메모리는 분리해서 설계한다

   1. 채팅은 어깨 통증과 한 달 전 키보드·책상처럼 직접 연결되지 않는 개인 맥락을 이어야 하므로 검색 가능한 장기 기록이 도움이 될 수 있다.
   2. 코드에서는 버튼과 호출 경로처럼 구조적 추적이 가능하므로, 필요한 정보를 bash로 검색하고 파일에 저장하는 단순한 방식이 더 투명하고 평가 가능하다.

6. 새 스레드마다 Groundhog Day가 시작된다는 사실을 전제로 한다

   1. 에이전트의 단기 기억이 초기화되는 것은 피할 수 없지만, 자동으로 낡은 메모리를 축적해 보완할 필요는 없다.
   2. 매번 시작할 때 중요한 제품 맥락과 팀의 가치를 읽도록 만들고, 최신 상태가 코드·테스트·짧고 관리 가능한 문서에 남아 있게 한다.
   3. 궁극적인 성과 지표는 메모리 파일의 개수가 아니라, 에이전트에게 작은 일을 맡겼을 때 사용자가 원하는 방향으로 더 나아가고 필요한 반론까지 제시하는 빈도다.

7. 실천 권고

   1. Claude Code에서 자동 memory를 끄고, 현재 메모리 디렉터리를 읽기·쓰기 통계와 함께 감사한다.
   2. 중복·완료·날짜 없는 일시 상태·해결된 버그·오래된 계획 URL을 제거한다.
   3. 제품 맥락과 가치, 플랫폼 요구사항, 공유 용어를 AGENTS.md에 짧게 정리한다.
   4. 반복되는 에이전트 실수는 먼저 아키텍처로 없애고, 다음으로 lint·CI·replay 테스트를 추가한다.
   5. skill은 서버 노출 같은 프로세스·환경 문제에 한정하고, 실제 효과를 평가한 뒤 유지한다.

마지막 권고는 단호하다. 코드 작업에서 Claude Code의 자동 메모리를 꺼 보고, 오래된 컨텍스트가 사라진 뒤 코드·검증·방향성 문서만으로 에이전트가 어떻게 행동하는지 비교하라.

핵심 요약 (20줄)

1. 코드베이스에서 에이전트가 알아야 할 진실은 별도 메모리보다 현재 코드와 검증 시스템에 있다.

2. Claude Code가 숨겨진 파일에 작업 결과를 자동 저장하는 방식은 새 스레드의 망각을 보완하지만 낡은 컨텍스트를 축적한다.

3. 오래된 주석과 Markdown 계획 파일은 단순한 기술 부채가 아니라 사람과 에이전트를 틀린 방향으로 이끄는 위험 요소다.

4. 지식을 여러 장소로 나누면 한 곳만 수정하고 다른 곳을 잊는 split-brain 문제가 생긴다.

5. 최신 모델은 코드 파일 한두 개만 읽어도 구조와 스타일을 파악하므로 과도한 AGENTS.md가 필요하지 않다.

6. 폴더 목록과 짧은 설명 정도의 위치 지도는 유지하기 쉽지만 임베딩 기반 컨텍스트 계층은 효과 평가 없이 추가하면 낭비가 된다.

7. Cursor가 동적 코드 그래프에서 bash 도구 중심으로 이동한 흐름은 모델이 필요한 정보를 직접 찾도록 훈련됐다는 증거다.

8. 전체 Slack 기록을 append-only JSONL로 저장하고 필요할 때 jq로 조회하는 Mom 봇은 자동 요약 메모리의 대안이다.

9. 코드의 버튼 호출 경로와 달리 어깨 통증과 과거 키보드·책상 대화의 연결은 불규칙하므로 채팅 메모리는 더 유용할 수 있다.

10. 사용자 컨텍스트가 답변에 과도하게 들어오면 유용성이 떨어지고 위험한 상태가 지속될 수 있다.

11. Pi의 설계 원칙은 코딩 메모리 제거, bash 활용, 필요한 출력만 컨텍스트에 로드하기다.

12. Sentry skill은 3개 항목만 즉시 보여주고 52개 항목은 JSON 파일에 남겨 컨텍스트 비용을 줄인다.

13. T3 Code 메인 복제본에는 45개 메모리가 있었지만 현재 유용한 것은 약 3분의 1뿐이었다.

14. 355개가 넘는 세션 중 19개만 메모리를 읽었고 80개가 썼으며 45개 중 26개는 한 번도 읽히지 않았다.

15. 실수 감소와 사용자의 의도를 적은 말로 이해하는 방향성 정렬은 서로 다른 목표다.

16. 실패가 생길 때마다 금지 문구를 추가하기 전에 사고방식 차이와 직관적이지 않은 아키텍처를 점검해야 한다.

17. Potato Lauren의 순서는 아키텍처·데이터 구조, 린트·테스트·CI, skill·rule, 사람 개입 순서다.

18. T3 Code는 실제 스레드 replay로 WebSocket 전송량을 100KB 미만, 대부분 10KB 미만으로 제한하고 30% 초과 PR을 차단한다.

19. AGENTS.md에는 제품 목적, open-source 가치, 원격·다중 플랫폼 조건, 용어집과 팀의 설계 취향을 담아야 한다.

20. 새 스레드마다 에이전트의 기억이 초기화되더라도 중요한 정보는 최신 코드와 짧은 방향성 문서에 남기고 자동 메모리는 꺼 보는 것이 결론이다.