Claude Code의 메모리를 꺼라

URL: https://www.youtube.com/watch?v=Jf54k7tFeEc 날짜: 2026-08-26 채널: t3dotgg (Theo - t3․gg) 원제: Turn off Claude Code's Memory

---

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

==코드 작업에서 에이전트의 기억을 자동으로 축적하는 것보다, 코드 자체를 진실의 원천으로 만들고 아키텍처·Agent MD·Lint·CI로 실패를 구조적으로 제거하는 편이 훨씬 낫다.==

• Claude Code의 메모리는 T3 Code의 메인 clone에 45개나 쌓였지만 26개는 단 한 번도 읽히지 않았고, 메모리를 읽은 세션보다 쓴 세션이 약 세 배 많았다.
• 코드베이스는 파일 간 직접 연결과 실행 가능한 검증 절차를 갖고 있으므로, 일반 대화처럼 불투명한 장기 기억에 의존할 이유가 적다.
• 에이전트가 바람직한 방향으로 움직이게 하려면 “다시는 하지 마라”를 계속 덧붙이기보다, 구조적으로 실수를 불가능하게 만들고, 그래도 남는 문제를 Agent MD와 테스트·CI로 포착해야 한다.
• 좋은 최종 상태는 새 스레드를 시작할 때도 모델이 사용자의 제품·가치·설계 취향을 이해해, 사용자가 예상하지 못한 좋은 제안까지 같은 방향으로 내놓는 상태다.

Theo는 자동 메모리를 끄고, 오래된 메모리를 분류·보관한 뒤 삭제하기로 한다. 필요한 맥락은 코드·문서·구조·검증 시스템에 명시하고, 모델이 매번 현재 상태를 도구로 탐색하게 해야 한다는 결론이다.

1. 코드베이스에 기억을 저장하려는 발상에 대한 문제 제기

AI가 코드에서 제대로 일하려면 코드베이스가 무엇인지, 각 요소가 어디 있는지, 일을 완료하는 방법이 무엇인지 알아야 한다. 그러나 그 정보를 별도의 자동 기억 시스템으로 쌓는 방식은 최신성과 책임 소재를 훼손한다.

1.1. AI용 기억 시스템이 만드는 두 번째 진실의 원천

1. 코드베이스의 지식을 자동 인코딩하려는 흐름

   1. 사람들은 에이전트가 알아서 따를 수 있도록 저장 규칙·라이브러리·플러그인·기능을 만든다.
   2. 이 시스템들은 지난 몇 년 동안 코드베이스에서 사람이 하는 일을 자동으로 기록하려는 목적으로 계속 늘어났다.
   3. Claude Code는 질문을 받은 뒤 컴퓨터 어딘가의 숨겨진 파일에 내용을 저장하고, 이후에도 그 내용을 계속 무작위로 재사용하는 방식으로 보인다.

2. Theo가 기억 시스템을 싫어하는 이유

   1. 사람 중심 개발에서는 지식이 주로 사람의 머릿속에 있었고, 문서가 낡더라도 결국 무엇이 진짜인지 판단하는 주체가 있었다.
   2. 새 스레드가 시작될 때마다 모든 것을 잊는 에이전트의 문제를 해결하려고 자동 저장을 덧붙였지만, 자동 저장 내용은 최신인지·중요한지·일반화 가능한지 보장되지 않는다.
   3. 코드가 어떻게 동작해야 하는지에 대한 정보를 코드 외부의 기억에 두면, 코드와 기억이 서로 다른 주장을 하는 두 개의 진실 원천이 된다.

1.2. 낡은 맥락과 split-brain 문제

1. 주석도 오래되면 해롭다

   1. 어떤 코드를 특정 방식으로 작성해야 해서 남긴 주석이 코드는 바뀐 뒤에도 그대로 남을 수 있다.
   2. 그 주석은 단순히 쓸모없는 사체가 아니라 사람과 에이전트를 잘못된 방향으로 유도하는 적극적인 위험 요소가 된다.

2. 정보를 나눌수록 불일치가 늘어난다

   1. 한 지식을 여러 파일·메모리·계획 문서·플러그인에 나누면, 한 곳만 바꾸고 나머지를 잊는 split-brain 문제가 생긴다.
   2. AI 시대에는 에이전트가 작성한 낡은 Markdown 계획 파일이 저장소에 남아 몇 달 또는 몇 년 동안 모델을 오도하기도 한다.
   3. Theo도 Lakebed 프로젝트에서 이런 계획 파일을 정리하지 못한 사례가 있다고 인정한다.

3. 코드 자체가 제공하는 더 좋은 맥락

   1. 최신 모델은 파일 한두 개만 읽어도 코드의 구조와 스타일을 상당히 잘 파악한다.
   2. 폴더 목록과 짧은 설명으로 구성한 지도(map)는 유지하기 쉽고 실제 위치를 찾는 데 유용하다.
   3. 그 이상으로 Embedding이나 복잡한 그래프를 덧붙이려면, 실제 출력 품질이 좋아졌는지 평가해야 한다. Theo는 그런 평가를 해본 사람이 많지 않으며, 평가해도 개선되지 않을 가능성이 높다고 주장한다.

1.3. WorkOS 협찬: 소비자·엔터프라이즈·에이전트 인증

1. 협찬으로 제시된 공통점

   1. Theo는 OpenAI, Anthropic, Cursor, Thinking Machines가 모델을 만드는 것만이 아니라 WorkOS를 사용한다는 점을 협찬 도입부의 공통점으로 든다.
   2. 에이전트가 로그인 페이지와 기본 OAuth 흐름을 만들 수는 있지만, 실제 기업이 애플리케이션에 로그인하는 엔터프라이즈 수준의 인증은 더 복잡하다고 설명한다.

2. WorkOS의 사용자 유형별 지원

   1. WorkOS의 관리자 포털은 기업에 가입 링크를 보내고, 기업이 선호하는 Identity Provider를 선택해 서비스에 온보딩하도록 만든다.
   2. 전통적인 소비자 인증에는 OAuth와 Google 로그인 같은 흐름을 제공한다.
   3. 에이전트도 사용자를 대신해 서비스에 가입하고 로그인해야 하므로, WorkOS는 Cloudflare·Firecrawl·Resend·Monday·Kernel 등 여러 기업과 함께 에이전트용 인증·가입 기능을 준비했다고 소개된다.
   4. Theo는 소비자·엔터프라이즈·에이전트 모두가 사용할 애플리케이션을 만들려면 WorkOS를 살펴보라고 안내하며 협찬 링크를 제시한다: https://soydev.link/workos

2. Pi와 Armen의 논의: 코딩에는 메모리 대신 Bash와 도구가 필요하다

Theo는 Pi의 창시자 Mario와 Flask의 창시자 Armen이 현재 AI 도구를 함께 만드는 대화에서 특히 날카로운 의견을 발견하고 전체 영상을 시청한다.

2.1. “코드가 진실이다”라는 출발점

1. 코딩에는 별도 메모리가 필요하지 않다

   1. Mario는 “코드가 진실(code is truth), 코드가 ground truth”라고 말한다.
   2. 코드는 계속 진화하므로, 이미 유지해야 하는 코드베이스 외에 또 하나의 기억 저장소를 유지할 이유가 없다.

2. Cursor 사례가 보여주는 업계의 이동

   1. 초기 Cursor는 코드베이스 전체를 매핑하고 필요한 맥락을 동적으로 주입하는 그래프 기반 시스템으로 모델의 코드 작업을 도왔다.
   2. 당시에는 모델이 메시지를 완성하는 수준이어서, Cursor가 모델에게 변경에 필요한 정보를 모두 제공하는 일이 핵심이었다.
   3. Cursor의 대표 인사들은 컨텍스트 윈도(Context Window)가 커져 거대한 코드베이스 전체를 모델 안에 넣는 미래를 이야기했다.
   4. 그러나 모델이 Bash와 도구를 사용하도록 학습되면서 상황이 반대로 바뀌었다.

2.2. 동적 컨텍스트 그래프에서 Bash 탐색으로

1. 도구를 주고 직접 찾게 하는 방식

   1. Claude Code는 필요한 도구와 Bash만 주어도 코드베이스에서 필요한 대상을 비교적 잘 찾아간다.
   2. 모델이 이런 탐색을 잘하도록 훈련되자, 화려한 동적 컨텍스트 시스템은 비용과 복잡성만 남기는 선택이 됐다.
   3. Cursor조차 자신들이 만들었던 코드 순회 시스템에서 상당히 멀어졌으므로, 업계 전체의 이동을 무시하고 그래프 기반 탐색을 새로 만드는 것은 시대에 뒤처진다.

2. Pi의 세 가지 설계 원칙

   1. 코딩에는 별도의 메모리 시스템이 필요하지 않다.
   2. Bash만으로도 충분하다. Bash는 사실상 모델이 프로그램을 조립하고 실행하는 공용 언어가 된다.
   3. 도구 출력은 필요할 때만 컨텍스트로 불러온다. 결과가 필요하지 않다면 도구 호출 자체를 하지 말고, Bash로 파일에 써 둔 뒤 필요한 일부만 cat한다.

3. 모델의 컨텍스트 사용을 모델에게 맡겨야 한다

   1. 최근 모델은 컨텍스트를 과도하게 채우지 않는 방법을 충분히 학습했다.
   2. 사용자가 매번 출력 크기와 로딩 시점을 별도의 기억 시스템으로 통제할 필요는 없다.
   3. 에이전트가 파일에 결과를 기록하고 필요한 부분을 다시 읽게 하면, 모든 정보를 미리 로딩하지 않고도 긴 작업을 처리할 수 있다.

3. 메모리는 대화에는 유용할 수 있지만 코드와는 다르다

3.1. Mom Slack 봇의 append-only 기억

1. Theo의 개인 Slack 봇

   1. Theo는 “Mom(Master of Mischief)”이라는 Slack 봇을 운영하며, 봇은 서버에 root access를 갖고 참여한 모든 채널의 전체 기록을 볼 수 있다.
   2. 봇은 질문과 답변, 프롬프트와 시스템 응답을 하나의 거대한 append-only JSONL 파일에 계속 기록한다.
   3. jq로 그 JSONL 파일을 검색하므로, 별도의 요약·임베딩·기억 DB 없이도 사실상 무한한 대화 기록을 갖는다.

2. 대화 맥락과 코드 맥락의 차이

   1. 코드에서 버튼을 클릭했는데 기대와 다르게 동작하면, 버튼에서 시작해 영향을 받은 모든 코드까지 프로그램적으로 추적할 수 있다.
   2. 사람의 문제는 직접 연결이 훨씬 약하다. 어깨 통증을 묻는 질문과 한 달 전의 키보드 질문은 새 키보드의 설치 상태, 너무 높은 책상, 나쁜 자세를 통해 연결될 수 있다.
   3. 이런 인간적 문제에서는 어떤 과거 정보가 관련 있는지 직관적으로 알기 어렵기 때문에 사용자별 관련 정보를 태그하는 메모리가 유용할 수 있다.

3.2. 과도한 개인화의 위험

1. ChatGPT 메모리에 대한 입장 변화

   1. Theo는 한때 T3 Chat에 메모리를 넣지 않았고, ChatGPT가 메모리를 사용하는 방식을 강하게 비판했다.
   2. 그는 GPT-4o의 메모리 구현이 사용자의 맥락을 너무 강하게 끌어와 일부 사용자에게 심각한 정신건강 문제를 일으킬 수 있다고 우려했다.
   3. 질문에 답하지 않고 과거 대화의 세부사항에 지나치게 파고들면, 답변은 유용성을 잃고 “내 맥락”으로 가득 차게 된다.

2. 메모리가 질문을 오염시키는 상황

   1. Theo도 ChatGPT에 질문할 때 과거 자신이 요청했던 내용이 지나치게 많이 끼어드는 경험을 했다.
   2. 그는 모델이 자신의 과거 메모리를 공격적으로 끌어오지 않도록 “내 친구가 이런 문제를 겪고 있다”고 표현하는 우회 방법을 쓴다.
   3. 따라서 대화에서는 append-only 전체 기록을 필요할 때 검색하는 방식이 개인화 메모리보다 더 예측 가능할 수 있다.

4. Skills와 MCP보다 중요한 것은 조합 가능한 작은 도구다

4.1. Sentry를 직접 쓰는 Skill

1. MCP를 그대로 쓰지 않은 이유

   1. Armen은 Sentry에 유용한 데이터가 있지만, Sentry MCP를 사용하지 않는다.
   2. 대신 코딩 에이전트에게 자신이 늘 원하는 데이터의 형태와 인증 방식을 설명하고, 그 요구에 맞는 Skill을 직접 만들게 했다.

2. Skill의 실제 구성

   1. Skill은 필요할 때 로드할 수 있는 프롬프트와 자신이 사용할 도구를 함께 담는다.
   2. 인증을 자신이 선호하는 방식으로 해결하고, Sentry 데이터를 평소 원하는 형태로 내려받는다.
   3. 이 접근은 거대한 통합 계층보다 작은 도구의 조합(composability)을 중심에 둔다.

4.2. 컨텍스트 효율적인 도구 출력

1. 파일을 먼저 내려받고 일부만 읽기

   1. Sentry Skill은 여러 JSON 파일을 내려받지만, 처음부터 전체를 컨텍스트에 넣지 않는다.
   2. 예를 들어 세 항목만 보여주고 실제로는 52개 항목을 JSON 파일에 저장한 뒤, 구조가 맞아 보이면 그 파일을 직접 확인하라고 안내한다.
   3. 모델은 필요한 시점에 필요한 파일의 필요한 부분만 읽으므로 컨텍스트가 불필요하게 커지지 않는다.

2. Theo의 제한적 동의

   1. Theo는 컨텍스트 효율과 조합 가능성이라는 층위에는 동의하지만, 사람들이 너무 공격적으로 Skill을 만들고 있다고 본다.
   2. 모든 문제를 Skill로 해결하려는 습관은 코드베이스와 모델의 기본 능력을 활용하지 못하게 한다.
   3. 그는 논의에서 Agent MD와 CLAUDE.md 파일을 더 깊게 다뤄야 한다고 지적한다.

5. Claude Code 메모리를 실제로 감사하다

Theo는 논의를 마친 뒤 자신의 프레임워크 데스크톱 BB1에서 Claude Code 메모리가 실제로 얼마나 문제를 일으켰는지 확인한다.

5.1. BB1과 T3 Code의 작업 맥락

1. 감사 대상

   1. BB1은 Theo가 T3 Code 작업을 대부분 수행하는 프레임워크 데스크톱이다.
   2. 이 컴퓨터에는 Fable과 Soul을 통해 Claude Code와 Codex로 작업한 스레드가 수백, 많게는 수천 개 있다.
   3. 최근 두 에이전트가 메모리를 저장하고 있다는 메시지를 자주 표시했기 때문에, 먼저 프로젝트에 대해 어떤 기억을 갖고 있는지 질문한다.

2. 첫 번째 메모리의 이상함

   1. 한 clone에서 메모리는 9일 전에 작성한 사양(spec) 하나뿐이었다.
   2. 그 사양은 실제로 출시할 계획도 없었고, 구현도 거의 진행하지 않은 기능이었다.
   3. 저장된 유일한 내용이 왜 하필 이 임시 문서인지, 그리고 그것이 메모리에 들어간 것 자체가 왜 필요한지 설명되지 않았다.

5.2. 여러 clone과 프로젝트에 흩어진 낡은 기억

1. 다섯 프로젝트 디렉터리의 메모리

   1. 메모리는 Railway topology, 장시간 Codex 실행용 locked worktree, Lakebed 파일 Blob storage 계획과 비교, V8 isolate layer 계획, launch audit, god file cleanup refactor 등에 걸쳐 저장돼 있었다.
   2. 이런 이름들은 작업 중간의 설계 논의나 특정 시점의 계획이지, 앞으로 모든 세션이 따라야 할 지속적인 규칙이 아니다.
   3. 오래된 메모리에는 날짜조차 없어 모델이 현재 상태인지 과거 상태인지 구분하기 어렵다.

2. 실험과 운영 설정이 메모리가 된 사례

   1. T3 Code는 preview나 production mobile build를 절대 건드리지 않아야 한다는 규칙을 저장하고 있었다.
   2. T3 Connect Desktop이 server-side race hazard까지 전체 흐름을 처리한다는 내용도 저장돼 있었다.
   3. 새 모델을 시험하는 benchmark에서 LM API 호출과 provider default, effort, deep reasoning 설정을 최소화한다는 내용도 메모리가 됐다.
   4. 벤치마크 설정은 언제든 바뀌어야 하므로, 이런 내용이 메모리에 남으면 실험의 순수성을 오염시킨다.

3. 사소하고 무관한 개인 프로젝트 정보

   1. Moonlight fork의 Fish shell 재구축과 관련한 내용이 메모리에 저장됐다.
   2. 세탁기와 건조기의 상태를 Discord로 추적하는 bridge 설정도 메모리가 됐다.
   3. Claude Code 사용량 가격 override도 저장됐지만, T3 Code 작업의 일반 규칙과 아무 관계가 없다.

5.3. 메인 clone의 45개 메모리와 세 가지 decay 문제

1. 계획·기능 메모리의 무분별한 저장

   1. 메인 T3 Code clone에는 총 45개의 메모리가 있었다.
   2. 온보딩 개편, 앱의 babysit monitoring flow, 사이드바 개편 초안과 선호한 variant C 등이 저장돼 있었다.
   3. Theo는 이런 내용 대부분을 “slop”이라고 부르며, 현재 지속되는 규칙이 아니라 작업 중간 상태라고 평가한다.

2. 첫 번째 decay 문제: Agent MD와 중복

   1. 45개 중 10개는 이미 AGENTS.md에 적혀 있어 중복된 dead weight였다.
   2. 단일 개발 원천(single origin of dev), 연속 애니메이션 금지, sleep 금지, 실제 상태를 복제해 pairing URL·worktree port로 가져오는 방법 등이 그 예다.
   3. 일부 내용은 메모리가 만들어지기 전부터 Agent MD에 있었는데도, 에이전트가 동일한 내용을 다시 메모리로 복사했다.

3. 두 번째 decay 문제: 끝난 기능과 만료된 설계

   1. 기능 설계 관련 메모리 12개는 대부분 프로젝트 환경에 따라 이미 만료됐다.
   2. remote desktop 업데이트, editor 변경, favicon 수정처럼 이미 끝난 작업의 세부사항과 특정 PR 번호까지 저장돼 있었다.
   3. 완료된 문제의 해결 과정이 미래의 모든 작업에 필요한 규칙인 것처럼 남는 것은 기억이 아니라 잡음이다.

4. 세 번째 decay 문제: 위험한 point-in-time 상태

   1. Monitor JSON schema drift, remote PR portfolio, crisis hut path, background policy scope, wiring gap, CLI probe와 test-leak process 등은 특정 시점의 상태를 묘사한다.
   2. 그 상태는 drift가 이미 migration 됐는지, PR이 merge됐는지, leak이 고쳐졌는지에 따라 바뀐다.
   3. 오래된 GitHub CLI 버전이 낡아 업데이트했다는 내용이나, 출시되지 않은 작업의 live plan URL도 해결이 끝난 뒤에는 메모리에 둘 이유가 없다.
   4. 이런 기억은 모델이 이미 해결된 문제를 다시 고치거나, 더 이상 존재하지 않는 경로와 정책을 따르게 만들 수 있다.

5.4. Muse Code와 T3 Connect 사례가 보여준 맥락 붕괴

1. Muse Code 조사 기록

   1. Theo가 영상에서 Muse Code 지원을 추가하던 때의 메모리에는 Meta Muse Code CLI의 headless 통합 표면이 기록돼 있었다.
   2. 공개 문서가 없어 CLI를 직접 probing해 알아낸 내용, self-updating Bash launcher, local bin version string, headless multi-turn mode, ACP mode와 모델 관련 설정이 길게 들어갔다.
   3. 그 메모리는 특정 날짜의 탐색 결과였고, 나중에 T3 Connect Desktop이 이미 완성됐다는 메모리와 연결돼 있었지만 두 내용의 관계는 불분명했다.

2. 분노와 빌드 충돌의 기록

   1. 한 메모리는 빌드 이름이 재사용돼 에이전트가 휴대전화의 기존 build를 덮어쓴 사건에 대한 Theo의 분노에서 만들어졌다.
   2. Theo는 그 사건을 계기로 iOS 작업에 Soul을 사용하기 시작했지만, 분노의 원인이 영구적인 코드 규칙은 아니다.
   3. 또 다른 메모리는 T3 Connect CLI를 Mac의 background process로 만들던 중의 혼란을 기록했다.
   4. T3 Connect Desktop은 이미 로그인·link toggle·relay client 설치를 bundled web UI에서 처리하므로, 특정 시점의 CLI 계획을 계속 기억할 필요가 없다.

3. 다중 프로세스와 인프라 계획

   1. 두 T3 서버가 하나의 base directory를 공유해 같은 environment identity와 relay link, runtime state file을 놓고 race를 일으킬 수 있다는 topology가 저장돼 있었다.
   2. Railway 사용 topology와 3개월 전 두 Blob plan의 비교도 메모리에 남아 있었다.
   3. 이런 정보는 현재 코드와 테스트가 보여주는 사실보다 우선할 수 없고, 날짜 없는 자동 메모리로는 현재성을 보장할 수 없다.

6. 실제 사용률이 드러낸 메모리의 실패

6.1. 45개 중 26개가 한 번도 읽히지 않았다

1. Theo의 결론

   1. Claude Code에 메인 clone의 메모리 중 실제로 유용한 것이 얼마나 되는지 묻자, 대략 3분의 1만 오늘날 제 역할을 한다는 답이 돌아왔다.
   2. Theo는 이 답을 보고 모든 머신에서 Claude Code 메모리를 끄기로 결심한다.

2. 읽기와 쓰기의 불균형

   1. BB1의 T3 Code 관련 transcript는 355개가 넘는 세션을 포함한다.
   2. 그중 개별 메모리 파일을 연 세션은 19개뿐이었다.
   3. 80개 세션은 메모리를 새로 쓰거나 편집했다.
   4. 메모리를 읽는 행동보다 쓰는 행동이 대략 3배 많았고, 45개 메모리 중 26개는 단 한 번도 읽히지 않았다.

3. 저장 비용이 사용 가치보다 크다

   1. 메모리 시스템은 계속 파일과 내용을 생성해 관리 비용을 만든다.
   2. 대부분의 파일이 실제 의사결정에 호출되지 않으면서도 잘못된 맥락을 주입할 가능성은 남긴다.
   3. Theo는 Fable에게 전체 머신을 순회해 메모리를 비활성화하고, 기존 메모리를 올바르게 분류해 보관한 뒤 삭제하도록 시킨다.

7. 메모리 대신 달성해야 할 두 가지 목표

7.1. 실수 감소와 방향성 정렬은 서로 다르다

1. 첫 번째 목표: 실수를 줄인다

   1. 에이전트가 사용자를 짜증나게 하는 멍청한 행동을 반복하지 않게 해야 한다.
   2. 나쁜 선택에서 멀어지고 좋은 선택으로 향하도록 실패 원인을 제거하거나 차단해야 한다.

2. 두 번째 목표: 방향을 맞춘다

   1. 사용자가 모든 세부사항을 매번 설명하지 않아도 모델이 자신이 원하는 방식으로 행동하게 해야 한다.
   2. 필요한 단어와 노력이 줄어들수록 같은 작업을 더 적은 설명으로 완료할 수 있다.
   3. 실수하지 않는 것과 사용자가 원하는 방향으로 함께 움직이는 것은 비슷해 보여도 별개의 목표다.

3. 자동 메모리가 해결하지 못하는 이유

   1. 사람들은 메모리가 이 두 목표를 모두 마법처럼 해결해 줄 것이라 기대하지만, 메모리는 어느 것도 안정적으로 보장하지 않는다.
   2. 낡은 메모리는 실수를 줄이기는커녕 이미 고쳐진 문제를 되살린다.
   3. 개인적 취향과 제품의 가치를 방향성으로 전달하려면, 자동 생성된 사실 조각이 아니라 의도적으로 작성한 맥락이 필요하다.

7.2. “다시는 하지 마”에서 “어떻게 생각할지”로

1. Agent MD에 작은 금지 규칙을 추가하는 방법

   1. 에이전트가 잘못할 때마다 AGENTS.md나 CLAUDE.md에 다시 하지 말라는 짧은 규칙을 하나씩 추가하면 실제로 도움이 된다.
   2. 그러나 이 방법을 무한히 반복하기 전에 실패 원인이 더 깊은 층에 있는지 돌아봐야 한다.

2. 실패의 여러 층

   1. 사용자와 에이전트가 문제를 바라보는 방식이 다를 수 있다.
   2. 코드베이스의 아키텍처가 에이전트에게 직관적이지 않을 수 있다.
   3. 사용자·코드·AI 사이에 커뮤니케이션 단절이 있을 수 있다.
   4. 이런 경우에는 “이것을 하지 마라”만 쓰기보다, 에이전트가 무엇을 변경하기 전에 어떤 관점으로 문제를 생각해야 하는지 설명하는 편이 효과적이다.

3. 방향성 정렬의 결과

   1. Theo는 Agent MD에 금지 사항만 나열하지 않고 자신과 팀이 T3 Code를 어떤 방향으로 발전시키려는지 적는다.
   2. 방향성이 맞으면 작은 실수도 자연스럽게 줄어든다.
   3. 결국 가장 좋은 기억은 자동으로 뽑힌 과거 사건이 아니라 현재의 제품 가치와 설계 원칙을 설명하는 짧고 관리 가능한 문서다.

8. Lauren의 개입 가치 순서와 실패 제거 사다리

Theo는 React 생태계에서 활동했고 현재 Cursor·Grokbot·Pstack 쪽에서 많은 코드를 출하하는 Potato Lauren의 사고방식을 소개한다.

8.1. 개입할 때마다 문제를 한 단계 위에서 없애라

1. 개입을 반복하지 않는 질문

   1. 에이전트를 고칠 때마다 “다음에도 내가 이 문제를 직접 고쳐야 하는가?”라고 물어야 한다.
   2. 한 번의 교정을 미래의 반복 개입을 없애는 설계 변경으로 전환해야 한다.

2. 가치가 높은 순서

   1. 첫 번째이자 가장 좋은 선택은 더 나은 아키텍처나 자료구조로 문제를 범주 자체에서 제거하는 것이다.
   2. 구조적으로 제거할 수 없다면 Lint rule, 테스트, CI로 실패를 자동 감지한다.
   3. 그것도 불가능한 소수의 경우에만 Skill이나 명시적 Rule을 사용한다.
   4. 모든 층이 실패하면 사람을 loop에 넣어 확인하지만, 이 단계에 자주 의존해서는 안 된다.

8.2. 아키텍처로 실패 범주를 제거하는 사례

1. T3 Stack과 tRPC

   1. Theo가 T3 Stack과 tRPC를 좋아한 이유는 이들이 오류가 발생할 수 있는 복잡한 범주 자체를 없애기 때문이다.
   2. tRPC의 백엔드·프론트엔드 간 타입 안전성(type safety)은 서로 분리된 데이터 계층에서 생길 수 있는 여러 실수를 제거한다.
   3. Convex도 인간 개발자와 에이전트 모두에게 좋은 이유가 같은 방식으로 구조를 단순화하기 때문이라고 본다.

2. 웹 개발 밖의 예시

   1. Garbage collection과 memory safety는 개발자가 모든 메모리 가장자리 조건을 직접 기억하지 않아도 더 안전한 코드를 쓰게 한다.
   2. 구조가 실패를 허용하지 않도록 만들면, 사람과 에이전트가 기억해야 할 규칙이 줄고 결과적으로 회귀도 줄어든다.

8.3. T3 Code의 WebSocket 데이터 전송 회귀를 CI로 막다

1. 문제의 발생

   1. Theo는 비행기에서 불안정한 Wi-Fi를 쓰거나 이동 중 4G·3G로도 스레드를 따라갈 수 있도록, 텍스트 데이터 전송량을 작게 유지하는 것을 중요하게 여긴다.
   2. 기능이 추가되면서 transit layer가 부풀었고, 스레드 하나를 로드하는 데 WebSocket으로 수십 MB를 전송하는 상황까지 갔다.
   3. 그는 전송 계층을 대대적으로 정리하고 데이터 사용량을 측정하는 로컬 테스트 스위트를 만들었다.

2. 수동 개선만으로는 회귀를 막지 못했다

   1. 최적화한 지 며칠 지나지 않아 regression이 다시 발생했다.
   2. 코드베이스를 단순하고 효율적으로 만드는 작업만으로는 이후 변경이 같은 문제를 되풀이하는 것을 막을 수 없었다.
   3. 따라서 그는 실제 업무에서 나온 거대한 텍스트 스레드를 샘플로 저장하고, Codex와 Claude가 그 스레드를 fake replay하도록 CI에 비교적 복잡한 검사를 추가했다.

3. 자동 검증과 에이전트의 자기 수정

   1. CI는 각 replay에서 WebSocket으로 실제 얼마의 데이터가 전송되는지 측정한다.
   2. 최적화 이후 목표는 모든 작업에서 100KB 미만, 대부분 10KB 미만으로 맞춰졌다.
   3. 각 변경 후 전송량을 자동으로 PR comment에 남기고, 최적화 당시 수치보다 약 30% 높은 ceiling을 넘으면 PR을 실패시키고 Theo에게 알린다.
   4. 이 장치는 이미 실제 회귀를 여러 번 막았고, 에이전트는 Theo에게 완료를 알리기 전에 실패한 검사를 고친다.
   5. Theo는 지난 20년 가까이 팀과 회사의 회귀를 막기 위해 만든 기법을 에이전트에도 적용했으며, 에이전트 환경에서는 오히려 더 잘 작동한다고 말한다.

8.4. Skill은 코드와 CI가 해결하지 못한 잔여 영역이다

1. Skill을 도입할 조건

   1. 아키텍처로 범주를 제거하고, Lint·테스트·CI로 남은 실패를 잡는 과정을 먼저 거쳐야 한다.
   2. 그 모든 시도가 실패하고 코드베이스가 스스로 문제를 해결할 방법이 없을 때만 Skill이나 Rule을 도입해야 한다.
   3. Skill은 코드 동작 자체보다 원격 서버 노출처럼 주변 프로세스를 다루는 일에 더 유용하다.

2. Skill을 만능 도구로 만들지 말아야 한다

   1. Skill은 모든 문제를 해결하는 거대한 자동화 묶음이 아니라 안전망(safety net)과 fallback이다.
   2. Skill을 항상 먼저 꺼내 쓰면 구조적 해결을 탐색하지 않게 되고, 저장해야 할 규칙과 맥락만 또 늘어난다.
   3. 모든 층이 실패하면 최종적으로 사람이 검토해야 하지만, 정상적인 코드 작업은 이 단계까지 내려오지 않아야 한다.

9. 공유 구조가 플랫폼 회귀를 막는다

9.1. 여러 표면에서 같은 데이터 계층을 공유하기

1. T3 Code의 공통 TypeScript 계층

   1. T3 Code는 Web app, Electron desktop app, React Native mobile app의 데이터 로딩에 같은 공유 TypeScript 코드를 사용한다.
   2. 세 플랫폼의 데이터 계층이 동일하므로 하나를 깨뜨리는 변경을 하고 다른 둘만 남기는 일이 구조적으로 어렵다.
   3. 이 공통 구조가 안전한 변경을 쉽게 만들고, 모델이 여러 플랫폼을 잊는 실수를 줄인다.

2. SwiftUI 재작성의 비용

   1. T3 Code SwiftUI rewrite가 망설여지는 이유는 기존 공통 구조를 잃기 때문이다.
   2. SwiftUI 앱은 이 관계가 코드에 명확히 표현되지 않아 이미 regression이 발생했다.
   3. 더 나은 앱처럼 보여도 codebase drift를 허용해 과거에는 불가능했던 실패가 생기면 merge하지 않는 것이 더 안전한 선택일 수 있다.

9.2. 인간의 규율보다 인간의 가치를 전달하기

1. Uncle Bob의 문장

   1. Theo가 인용한 문장은 “에이전트에게 인간의 규율(human discipline)을 강요하는 것은 실수일 수 있지만, 인간의 가치(human values)를 강요하는 것은 실수가 아니다”라는 내용이다.
   2. Theo는 이 문장을 에이전트 개발에 관한 최근 Uncle Bob의 발언 중 최고라고 평가한다.

2. TDD 사례와 의미

   1. Theo는 에이전트에게 높은 수준의 Test-Driven Development(TDD)를 지시해도 에이전트가 결국 자신이 편한 방식으로 돌아가는 것을 반복해서 봤다.
   2. 따라서 사람이 따르는 개발 의식과 절차를 그대로 강제하기보다, 오픈소스 유지·성능·원격 사용성·플랫폼 일관성 같은 결과의 가치를 명시하는 편이 현명하다.
   3. 필요한 임계값(threshold)은 바꿀 수 있지만, 인간의 모든 규율과 행동 순서를 에이전트에게 그대로 이식할 필요는 없다.

10. 실제 T3 Code Agent MD가 담는 것

Theo는 자신이 “가장 덜 일반적인 Agent MD”를 쓴다고 말하며 T3 Code의 AGENTS.md에 담은 내용을 직접 보여준다.

10.1. 제품 맥락과 방향성

1. 제품을 먼저 설명하기

   1. 문서는 Node WebSocket server가 provider CLI를 감싸 여러 플랫폼에 제공한다는 구조를 짧고 명확하게 설명한다.
   2. T3 Code를 Claude Desktop, Codex app, Cursor, Glass, Conductor 같은 앱의 오픈소스·Bring Your Own Subscription 대안으로 정의한다.
   3. 이 제품 맥락이 있으면 에이전트는 단순히 파일을 고치는 사람이 아니라 제품을 이해하는 팀원처럼 제안할 수 있다.

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

   1. Theo는 제품을 이해하지 못하는 엔지니어가 팀에 있었고, 그런 엔지니어와 일하는 것이 즐겁지 않았다고 말한다.
   2. Claude Code와 Codex가 T3 Code를 이해하면 제안과 변경이 Theo의 방향에 맞을 가능성이 높아진다.

3. T3 Code를 특별하게 만드는 가치

   1. T3 Code는 핵심적으로 open이어야 하므로, 모델이 보이지 않는 코드 일부를 close source로 만들자고 제안하면 거부해야 한다.
   2. “Performance without compromise”라는 항목은 모델이 변경이 성능에 미치는 영향을 생각하게 한다.
   3. “Remote ready”는 로컬에서만 잘 되는 기능을 허용하지 않고 전화기나 웹을 통한 원격 연결에서도 작동해야 한다는 기준이다.
   4. “Multi-surface”는 Web, Electron, Mobile 등 모든 서비스와 표면에 변경이 반영돼야 한다는 기준이다.

10.2. 반복 실수를 막는 운영 규칙

1. 서버와 개발 환경

   1. T3 Code 작업 중 실행 중인 T3 Code server를 죽이지 말라는 규칙을 별도 섹션에 둔다.
   2. Dev server가 의미 있게 복잡하므로 에이전트가 그 구조를 무시하고 임의로 재시작하지 않도록 한다.

2. 공유 언어를 만드는 Glossary

   1. Glossary는 에이전트와 사람이 같은 용어를 쓰게 해 왕복 대화를 쉽게 만든다.
   2. Claude가 필요하지 않은 일에 그럴듯한 용어를 만들어내는 습관도 줄여 준다.

3. 모델이 반복하던 나쁜 행동 기록

   1. 모델이 계속 실행 중인 서버를 종료하는 등 아무리 말해도 반복하던 행동을 문서에 구체적으로 적었다.
   2. 이런 목록은 자동 메모리처럼 과거 사건을 무작정 저장하는 것이 아니라, 현재에도 유효한 예방 규칙으로 정제한 것이다.

4. 모든 표면에서 확인하기

   1. 웹에서 적용한 변경이 모바일에 반영되지 않아 모바일이 깨지는 문제가 반복됐기 때문에 “hit every surface” 섹션을 만들었다.
   2. 에이전트가 변경을 완료하기 전에 모든 플랫폼에서 동작하는지 확인하도록 하며, 플랫폼 동기화를 유지하는 데 큰 도움이 됐다.

10.3. 검증과 협업의 구체적 기준

1. 현실적인 테스트 데이터

   1. 실제 사용 사례의 데이터를 worktree로 복제하기 쉽게 해 에이전트가 진짜 데이터로 변경을 확인하게 한다.
   2. 이 방식은 추상적인 fixture만 보고 통과한 코드가 실제 상황에서 깨지는 위험을 줄인다.

2. 검증 범위와 Pull Request

   1. 항상 거대한 저장소 전체 검사를 실행하지 말고 요청받았을 때 실행하라는 verification 규칙을 둔다.
   2. Pull Request를 어떻게 열고 제목을 읽기 쉽게 쓰는지도 설명한다.
   3. 코드가 어디에 사는지 적은 짧은 섹션은 존재하지만, 실제로는 문서에서 가장 덜 유용한 부분이라고 Theo는 평가한다.

3. 취향(Taste)을 명시하기

   1. Julius가 Theo의 “slop code”에 화내는 지점을 문서에 적어, 에이전트가 팀의 설계 취향을 따르게 한다.
   2. 복잡성은 adapter boundary에 모으고 orchestration은 단순하게, UI는 멍청하게(stupid) 유지하는 것을 선호한다.
   3. 불필요한 any 타입과 annotation을 싫어하고, 가능한 경우 타입 추론(inference)을 선호한다.
   4. 주석은 모든 줄의 동작을 설명하는 대신 함수 사용법을 설명해야 하며, 코드가 이동하면 주석도 함께 이동해야 한다.

10.4. 좋은 Agent MD가 만들어내는 에이전트 행동

1. 방향을 맞춘 확장

   1. 에이전트에게 작은 작업 하나를 시켰을 때 관련된 다른 세 가지 작업까지 제안하고, “이것도 원한 것 아닌가?”라고 되묻는다면 제품 맥락을 이해하고 있다는 신호다.
   2. Theo는 이런 확장이 과거에는 기본적으로 일어나지 않았지만, 문서와 방향성 규칙을 다듬은 뒤 자주 일어난다고 말한다.

2. 예상 밖의 좋은 제안

   1. Theo는 에이전트가 자신이 예상한 범위를 넘어가면서도 완전히 같은 방향으로 움직이는 것에 정기적으로 놀란다.
   2. 에이전트가 나중에야 알게 될 문제를 미리 지적하거나, Theo가 직접 찾았어야 할 설계상의 반론을 제기하는 경우도 생겼다.
   3. 이런 능력은 자동 메모리에서 나온 것이 아니라, 제품 가치·구조·취향을 설명하는 파일에서 나온다.

11. 결론: Groundhog Day마다 올바른 맥락으로 시작하라

11.1. 자동 메모리보다 의도적인 맥락

1. 최종 목표

   1. 사용자와 에이전트가 lockstep으로 협력해, 사용자가 에이전트의 이해 수준에 정기적으로 놀라는 상태를 만들어야 한다.
   2. 이것은 자동으로 생기지 않으며, 매번 프롬프트와 코드베이스의 맥락을 설계해야 얻을 수 있다.

2. 새 스레드의 기억 상실을 다루는 방식

   1. 새 스레드가 시작되면 에이전트의 두뇌가 지워지는 것은 사실이다.
   2. 그렇다고 최신성 없는 자동 메모리를 계속 쌓아 신선함을 유지하려 하면 안 된다.
   3. Groundhog Day처럼 모델이 매번 깨어날 때, 중요한 가치와 현재 구조를 머릿속에 넣어 주는 것이 핵심이다.

11.2. 실행 가능한 시사점

1. 코드와 구조를 먼저 고친다

   1. 에이전트가 실수하기 어려운 아키텍처와 자료구조를 선택한다.
   2. 타입 안전성, 공유 데이터 계층, garbage collection, memory safety처럼 실패 범주를 없애는 기술을 우선한다.

2. 검증을 자동화한다

   1. 구조로 제거하지 못한 실패는 Lint·테스트·CI의 실패 조건으로 바꾼다.
   2. 에이전트가 사용자에게 완료를 알리기 전에 회귀를 발견하고 스스로 고치게 만든다.

3. 문서로 가치와 사고방식을 전달한다

   1. Agent MD에는 오래된 작업 기록 대신 제품의 목적, 개방성, 성능, 원격성, 플랫폼 일관성, 용어, 설계 취향을 적는다.
   2. 금지 규칙만 나열하지 말고 에이전트가 변경을 검토할 때 어떤 방향으로 생각해야 하는지 설명한다.

4. 메모리는 마지막 fallback으로 취급한다

   1. 코드와 CI가 해결할 수 없는 주변 프로세스에만 작은 Skill이나 Rule을 사용한다.
   2. 메모리를 켜 두기 전에 실제로 읽히는지, 최신인지, 현재의 단일 진실 원천과 중복되지 않는지 평가한다.
   3. Theo의 최종 권고는 명확하다. Claude Code의 메모리를 끄고, 유용한 맥락은 의도적으로 관리하라.

주요 발언 모음

“코딩에는 메모리 시스템이 필요하지 않다. 코드는 진실이고, 코드가 ground truth다.” — Mario

“나는 코드에 메모리 시스템을 원하지 않는다. 이미 유지해야 할 코드베이스가 있는데 또 유지해야 할 곳을 만들 필요가 없다.” — Mario

“코드베이스를 Bash 도구가 아니라 화려한 그래프로 순회하게 만드는 데 모든 신뢰를 걸고 있다면, 이제 그 복잡성을 버려야 한다.” — Theo의 Cursor 사례 해설

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

“개입할 때마다 미래에 그 개입 자체를 없애려면 어떻게 해야 할지 생각하라.” — Potato Lauren의 원칙

“당신의 최종 목표는 당신과 에이전트가 lockstep으로 움직여, 에이전트가 당신을 얼마나 잘 이해하는지 정기적으로 놀라게 되는 것이다.” — Theo

“자동 메모리가 최신 상태를 유지하게 해 주는 것이 아니다. 오히려 상황을 더 나쁘게 만든다.” — Theo

핵심 데이터 & 수치

• 영상 길이: 39분 28초다.
• T3 Code 메인 clone 메모리: 45개가 저장돼 있었다.
• 미사용 메모리: 45개 중 26개가 단 한 번도 읽히지 않았다.
• 감사 대상 세션: BB1에서 355개가 넘는 T3 Code transcript 세션을 확인했다.
• 메모리를 읽은 세션: 개별 메모리 파일을 연 세션은 19개였다.
• 메모리를 쓴 세션: 메모리를 쓰거나 편집한 세션은 80개였다.
• 쓰기 대 읽기 비율: 메모리 쓰기가 읽기보다 약 3배 많았다.
• 유용한 메모리 비율: Claude Code의 자체 평가는 오늘날 제 역할을 하는 메모리가 대략 3분의 1이었다.
• 중복 Agent MD 메모리: 10개가 이미 Agent MD에 있던 내용과 중복됐다.
• 만료된 기능 설계 메모리: 12개가 프로젝트 환경에 따라 이미 만료된 설계였다.
• WebSocket 최적화 목표: replay 후 전체 전송량을 100KB 미만으로 유지했고, 대부분은 10KB 미만이었다.
• CI 회귀 허용 한도: 최적화가 끝난 기준 수치보다 약 30% 높은 ceiling을 설정했다.
• 네트워크 사례: 기능이 쌓이기 전에는 텍스트 스레드 하나에 수십 MB를 보내는 문제까지 발생했다.
• 플랫폼 범위: T3 Code는 Web, Electron desktop, React Native mobile의 데이터 로딩에 공유 TypeScript 계층을 사용한다.

결론 및 시사점

1. Claude Code 메모리를 기본값으로 신뢰하지 마라: 자동 생성된 45개 중 26개가 읽히지 않았고, 날짜 없는 과거 상태와 임시 작업이 현재 규칙처럼 섞였다.
2. 코드가 단일 진실 원천이 되게 하라: 실행 가능한 구조와 현재 코드가 별도 기억보다 정확하며, 폴더 지도처럼 작고 명시적인 문서만 보조적으로 둬라.
3. 실수를 아키텍처로 제거하라: tRPC·Convex·공유 데이터 계층·타입 안전성처럼 실패 범주를 없애는 선택이 에이전트에게 금지 문장을 주입하는 것보다 강하다.
4. 남은 회귀는 CI가 잡게 하라: 실제 데이터 replay, 성능 수치, PR 실패 조건을 만들면 에이전트가 사용자를 괴롭히기 전에 문제를 스스로 수정한다.
5. Agent MD에는 과거 사건이 아니라 방향을 적어라: 제품 정체성, 인간의 가치, 플랫폼 범위, 용어와 취향을 설명하면 새 스레드도 같은 방향으로 출발한다.
6. Skill과 메모리는 fallback이다: 코드와 CI로 풀 수 없는 프로세스 문제에만 작은 Skill을 쓰고, 자동 메모리는 실제 읽기·최신성·중복 여부를 검증한 뒤 필요하면 꺼라.
7. 인간의 의식을 복제하지 말고 가치를 전달하라: TDD 같은 인간 규율을 그대로 강제하기보다 오픈소스·성능·원격 사용성·플랫폼 일관성처럼 원하는 결과를 명시하라.
8. 에이전트와의 협업 품질은 의도적으로 만들어진다: 사용자가 세부사항을 매번 설명하지 않아도 에이전트가 올바른 추가 작업과 반론을 제시하는 상태가 좋은 Agent MD와 구조의 성과다.
9. 최종 행동: 지금 Claude Code의 메모리가 어떤 파일을 쓰고 어떤 세션에서 읽혔는지 감사하고, 오래된 기억을 보관·삭제한 뒤 현재의 진실을 코드·문서·검증 시스템에 다시 정리하라.

핵심 요약 (20줄)

Claude Code의 자동 메모리는 T3 Code 메인 clone에 45개가 쌓였지만 26개가 한 번도 읽히지 않았다.

BB1의 355개가 넘는 작업 세션에서는 메모리를 읽은 세션보다 쓰거나 편집한 세션이 약 세 배 많았다.

코드는 계속 변하는 ground truth이므로 코드 외부의 낡은 기억은 두 번째 진실 원천이 될 위험이 있다.

오래된 주석과 Markdown 계획 파일은 코드와 어긋나면 사람과 에이전트를 적극적으로 잘못된 방향으로 이끈다.

Cursor가 복잡한 코드 그래프에서 Bash와 도구 기반 탐색으로 이동한 흐름은 단순한 탐색의 힘을 보여준다.

Mario와 Armen은 코딩에 별도 메모리가 필요 없고 Bash만으로도 충분하다는 설계 원칙을 제시했다.

대화 영역에서는 append-only JSONL과 jq 검색이 불투명한 개인화 메모리보다 예측 가능한 기억이 될 수 있다.

Sentry Skill은 필요한 데이터를 JSON 파일에 내려받고 컨텍스트에는 일부만 로드해 도구 출력을 효율적으로 관리한다.

에이전트 개선의 목표는 반복 실수를 줄이는 일과 사용자의 방향에 맞춰 행동하는 일을 구분하는 데서 시작한다.

Agent MD에는 금지 목록보다 제품의 목적과 에이전트가 문제를 생각해야 할 방향을 적는 편이 효과적이다.

Potato Lauren의 우선순위는 아키텍처로 문제를 없애고, 불가능하면 Lint·테스트·CI를 적용한 뒤 Skill을 쓰는 것이다.

tRPC와 Convex의 타입 안전성은 사람과 에이전트가 저지를 수 있는 백엔드·프론트엔드 오류의 범주를 구조적으로 줄인다.

T3 Code는 WebSocket 전송량을 수십 MB에서 전체 100KB 미만, 대부분 10KB 미만으로 낮춘 뒤 실제 스레드 replay를 CI에 넣었다.

전송량 기준보다 30% 이상 커지는 PR은 실패하도록 만들어 에이전트가 완료 보고 전에 회귀를 고치게 했다.

Web·Electron·React Native가 공유 TypeScript 데이터 계층을 사용하면 한 플랫폼만 깨지는 변경이 어려워진다.

Uncle Bob의 원칙은 에이전트에게 인간의 규율보다 인간의 가치를 전달해야 한다는 것이다.

T3 Code의 Agent MD는 오픈소스, 성능, 원격 연결, 다중 표면, Glossary, 테스트 데이터와 팀의 코드 취향을 설명한다.

좋은 에이전트는 작은 작업 뒤에 관련된 세 가지 작업을 제안하고 사용자가 놓친 방향성 문제를 미리 반박한다.

새 스레드마다 에이전트의 기억이 지워져도 중요한 맥락을 의도적인 문서와 코드 구조로 다시 제공할 수 있다.

Theo는 Claude Code 메모리를 끄고 자동 기록 대신 코드·Agent MD·검증 시스템을 현재의 진실 원천으로 삼으라고 권한다.