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

URL: https://www.youtube.com/watch?v=EAVtSxbzmuM 날짜: 2026-08-28 채널: Tech Bridge

---

메타데이터

• 원본 발행일: 2026-08-27
• 영상 ID: EAVtSxbzmuM
• 재생 시간: 38분 8초
• 자막: 영어 자동 생성 자막(한국어 자동 자막은 요청 시 HTTP 429로 실패)
• 핵심 주제: Claude Code의 자동 메모리보다 코드·구조·테스트·CI·명시적 프로젝트 컨텍스트가 에이전트의 품질을 더 안정적으로 만든다.

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

==코딩 에이전트가 매 새 스레드에서 기억을 잃는 문제를 자동 메모리로 덧대기보다, 코드가 진실의 원천이 되도록 설계하고 에이전트가 따라야 할 가치와 방향을 명시해야 한다.==

• 코드는 이미 실행되는 시스템의 ground truth이며, 별도의 메모리 파일은 갱신되지 않을 때 코드와 충돌하는 또 하나의 진실 공급원이 된다.
• Claude Code가 저장한 메모리는 45개 중 26개가 한 번도 읽히지 않았고, 355개가 넘는 세션에서 19개 세션만 개별 메모리 파일을 읽은 반면 80개 세션이 메모리를 작성하거나 수정했다.
• 실패를 줄이는 가장 높은 가치의 해법은 더 좋은 아키텍처와 자료구조로 실패 범주 자체를 제거하는 것이며, 그다음이 lint·CI·테스트, 그다음이 skill과 사람의 검토다.
• 에이전트에게 인간의 절차적 규율을 억지로 강제하기보다, 오픈소스·성능·원격 사용성 같은 인간의 가치를 명시해 방향성을 맞추는 편이 효과적이다.

코딩 맥락의 지식은 변경되는 코드와 함께 변경되어야 한다. 자동 메모리가 과거의 계획, 일시적인 디버깅 상태, 이미 해결한 문제를 다시 주입하면 에이전트가 현재의 코드와 어긋난 결정을 내린다. 프로젝트의 목적, 불변의 원칙, 용어, 플랫폼 간 계약은 AGENTS.md 또는 CLAUDE.md에 짧고 의도적으로 적고, 나머지는 bash 도구와 검증 시스템이 다루게 하는 것이 핵심이다.

1. 코딩에서 자동 메모리가 만드는 문제

코딩 에이전트의 지속적인 기억은 유용한 지식 저장소라기보다 낡은 컨텍스트를 자동으로 재주입하는 위험 요소가 되기 쉽다.

1.1. 코드가 유일한 진실의 원천이어야 하는 이유

1. 별도 메모리 시스템이 추가하는 유지보수 부담

   1. Mario(Alpine/Pi의 창시자)는 코딩에는 메모리 시스템이 필요 없다고 말한다. 코드는 진실의 원천(code is truth, ground truth)이고 계속 진화하므로, 이미 유지보수해야 하는 코드베이스 옆에 또 다른 갱신 대상을 둘 이유가 없다.
   2. 사람이 코드를 작성하던 때에도 지식은 사람의 머릿속에 주로 있었고 문서로 옮기려는 시도가 있었다. 에이전트 시대에는 새 스레드가 시작될 때마다 에이전트의 기억이 초기화되므로, 사람들은 다음 실행을 위해 지식을 자동 저장하려고 한다.
   3. 자동 저장은 “다음 실행에 남겨야 할 지식”과 “방금 대화에서 잠깐 필요했던 상태”를 안정적으로 구분하지 못한다. 결과적으로 현재 코드와 별개로 오래된 메모리가 행동을 지시하는 구조가 된다.

2. 메모리와 코드의 분열이 만드는 split-brain 문제

   1. 주석도 코드가 변한 뒤 남아 있으면 독성 정보가 된다. 과거에는 특정 방식으로 해야 했다는 주석이 코드 변경 후에도 남아 있으면 사람과 에이전트를 잘못된 방향으로 유도한다.
   2. 코드, 주석, 계획 문서, 자동 메모리가 같은 개념을 각각 표현하면 한 곳을 바꾼 뒤 다른 곳을 놓칠 가능성이 커진다. 지식이 여러 장소로 나뉠수록 split-brain 상태가 증가한다.
   3. AI 시대에는 에이전트가 만들어 둔 조잡한 Markdown 계획 파일이 저장소에 남아 수개월 또는 수년 동안 사실인 것처럼 읽힐 수 있다. 발표자도 Lakebed에 남아 있는 오래된 계획 파일을 정리해야 한다고 인정한다.

1.2. 코딩용 메모리와 대화용 메모리의 차이

1. 코드베이스에는 직접 추적할 경로가 있다

   1. 버튼을 눌렀는데 기대한 동작이 나오지 않으면, 버튼에서 호출된 코드와 데이터 흐름을 프로그램으로 추적할 수 있다.
   2. 모델은 파일 한두 개를 읽는 것만으로도 코드 구조와 코드 스타일을 상당히 잘 파악한다. 폴더 목록과 짧은 설명으로 구성한 간단한 지도는 유지하기 쉽고 도움이 되지만, 그 이상을 자동 메모리나 임베딩으로 쌓는 것은 평가 없이 효과를 가정하기 쉽다.

2. 사람의 생활 맥락에는 직접 경로가 없다

   1. “어깨가 아프다”는 질문과 한 달 전의 키보드 질문은 직접적인 코드 호출 경로로 연결되지 않는다. 새 키보드의 세팅, 높은 책상, 나쁜 자세가 함께 원인일 수 있다.
   2. 사용자별로 흩어진 사실 사이의 관련성을 태그하는 메모리는 대화에서 조금 유용할 수 있다. 코드와 달리 어떤 과거 정보가 현재 질문과 관련 있는지 사람이 매번 명시하기 어렵기 때문이다.
   3. 다만 관련성 검색이 과도하면 대화의 품질이 떨어진다. 발표자는 ChatGPT가 과거 질문을 지나치게 끌어와 답을 자기 맥락에 맞추는 경우 “친구에게 이런 문제가 있다”고 표현을 바꿔 메모리 주입을 피한다고 말한다.

3. 과도한 개인화의 정신건강 위험

   1. 발표자는 GPT-4o 시기의 메모리 구현이 모델이 위험한 정신병적 상태에 들어갔을 때 그 상태를 계속 고정해 많은 사람에게 심각한 정신건강 피해를 줬다고 강하게 비판한다.
   2. 과거 맥락이 답변을 더 정확하게 만들지 않고, 오히려 답을 자기 이야기로 가득 채워 쓸모없게 만들 수 있다는 점이 핵심 우려다.

2. Pi의 세 가지 설계 원칙과 “bash면 충분하다”는 주장

작은 도구와 모델의 탐색 능력을 신뢰하면 거대한 컨텍스트 관리 계층의 필요성이 줄어든다.

2.1. Mario와 Armin이 제시한 세 원칙

1. 코딩에는 별도 메모리가 필요 없다

   1. 코드가 계속 변하는 시스템의 현재 상태를 직접 나타내므로, 메모리에 저장된 과거의 설명보다 코드와 실행 결과가 우선해야 한다.
   2. 에이전트가 새 스레드에서 다시 탐색하더라도 도구로 현재 상태를 확인하면 된다. 과거의 임시 결론을 무조건 전달하는 방식은 현재 상태 확인을 건너뛰게 만들 수 있다.

2. bash가 필요한 도구의 기반이다

   1. bash는 사실상 하나의 프로그래밍 언어이고, 현대 모델은 bash를 사용하도록 충분히 훈련되어 있다.
   2. 에이전트가 grep, find, jq, cat 같은 기본 도구를 조합하면 별도의 그래프 인덱스나 메모리 데이터베이스 없이 저장소와 로그를 직접 탐색할 수 있다.
   3. 모델이 도구를 호출해 얻은 출력이 현재 컨텍스트에 필요하지 않다면, 거대한 결과를 바로 대화에 넣지 말고 파일에 기록한 뒤 필요한 부분만 읽는다. 필요한 출력만 컨텍스트에 적재하는 방식이 핵심이다.

3. 도구 출력은 필요할 때만 컨텍스트에 넣는다

   1. 필요한 결과만 로드하면 모델의 컨텍스트가 불필요한 데이터로 포화되지 않는다.
   2. 출력이 필요하지 않은 작업은 대화에 도구 결과를 반환하는 전용 호출보다 bash 명령이 파일을 만들고 모델이 그 일부를 cat하는 흐름으로 처리할 수 있다.
   3. 최근의 똑똑한 모델은 컨텍스트를 과도하게 불리지 않는 방법을 이미 학습했으므로, 사용자가 모든 세부적인 컨텍스트 관리를 대신 설계할 필요가 줄어들었다.

2.2. Cursor의 컨텍스트 전략이 바뀐 과정

1. 초기 Cursor의 동적 코드 탐색

   1. Cursor 팀은 코드베이스 안에서 모델이 잘 행동하도록 만드는 능력이 뛰어났고, 초기에는 저장소 전체를 매핑한 뒤 적절한 컨텍스트를 동적으로 모델에 공급하는 시스템을 사용했다.
   2. 당시 Cursor CEO Michael은 컨텍스트 윈도우가 계속 커져 거대한 코드베이스 전체를 모델 안에 넣으면 모델이 모든 것을 알고 올바른 변경을 할 것이라고 자주 말했다.
   3. 초기 LLM은 메시지를 완성하는 수준이었기 때문에 Cursor는 코드베이스를 탐색하고 변경하는 데 필요한 정보를 모델 앞에 제공하는 중요한 역할을 했다. 모델 연구소들도 이런 사용 방식에 맞춰 모델을 개선했다.

2. Claude Code가 보여준 전환

   1. Claude Code는 화려한 동적 그래프 기반 컨텍스트 시스템 대신 모델에게 필요한 bash 도구를 제공하는 방식을 택했다.
   2. bash를 사용해 필요한 파일을 찾아가는 방식이 생각보다 잘 작동했고, 모델이 이 흐름을 학습하자 과거의 동적 컨텍스트 시스템은 설계 비용에 비해 의미가 작아졌다.
   3. 코드 순회 시스템을 사업의 중요한 부분으로 만들었던 Cursor조차 이 방향으로 이동했고, 과거 방식에 더 이상 큰 관심을 두지 않는다.
   4. 모델이 직접 bash로 저장소를 탐색하는 흐름보다 더 복잡한 그래프 시스템이 낫다고 주장하려면 실제 평가로 산출물 개선을 입증해야 한다. 평가 없이 임베딩, 플러그인, 그래프를 추가하는 것은 시간 낭비가 될 수 있다.

2.3. Slack 챗봇의 “무한 기억” 구현

1. 단일 append-only 로그

   1. Mario는 오래된 방식이라며 자신이 만든 Slack 봇 Mom(Master of Mischief)을 소개한다. 봇은 서버에 root access를 갖고 Slack에서 참여한 모든 채널의 기록에 접근한다.
   2. 질문과 답변, 프롬프트와 시스템 응답을 JSONL 형식의 하나의 거대한 append-only 로그에 계속 기록한다.
   3. 봇은 jq로 그 로그에서 필요한 기록을 조회한다. 과거의 대화를 별도 메모리 항목으로 요약해 재저장하지 않고, 일어난 일을 그대로 보존한 뒤 필요할 때 검색한다는 발상이다.

2. 대화와 코드의 검색 모델 차이

   1. 발표자는 채팅 공간은 코드보다 덜 구조화되어 있어도 적절한 과거 정보를 찾아내는 ChatGPT의 능력이 인상적이라고 평가한다.
   2. 코드에서는 이름, 호출 관계, 파일 구조처럼 직접적인 연결이 있지만, 인간의 문제에서는 키보드·책상·자세처럼 간접 연결을 추론해야 한다.
   3. 따라서 대화용 기억은 사용자별 관련성 태깅이 어느 정도 이득을 줄 수 있지만, 코딩용 기억을 같은 방식으로 설계하면 현재 코드와 오래된 추론을 혼합하기 쉽다.

3. Claude Code의 실제 메모리 감사

자동 메모리는 “무엇을 기억하느냐”뿐 아니라 “얼마나 자주 읽히고 실제로 행동을 개선하느냐”로 평가해야 한다.

3.1. BB1에서 발견한 무작위 메모리

1. 프로젝트에서 무엇을 기억하는지 직접 질문하기

   1. 발표자는 T3 Code 작업에 주로 사용하는 프레임워크 데스크톱 BB1을 점검했다. 이 컴퓨터에는 Fable(Claude Code)과 Soul(Codex)로 만든 수백에서 수천 개의 스레드가 있다.
   2. Claude Code가 최근 메모리를 자주 저장하고 언급하는 것을 보고, 프로젝트에 관해 어떤 메모리를 보유했는지 직접 물었다.
   3. BB1에는 9일 전에 작업한 사양(spec) 하나만 메모리로 남아 있었다. 실제 출시할 계획도 없고 구현도 거의 진행하지 않은 기능의 사양이 유일한 메모리였다는 점이 문제였다.

2. 다른 머신과 여러 clone에서 늘어난 메모리

   1. 다른 컴퓨터에서는 여러 T3 Code clone 중 cloud/ 프로젝트 아래 깊숙한 곳의 무작위 clone이 선택됐다. Claude Code는 그 clone의 메모리를 모두 요약했다.
   2. 새로 추가된 concise output style을 전역 파일에 반영하지 못해 혼란스러웠던 사건이 메모리로 저장되어 있었다. 일시적인 설정 문제와 불쾌한 디버깅 경험이 durable knowledge처럼 취급된 셈이다.
   3. Lakebed에는 다섯 개 프로젝트 디렉터리에 걸쳐 work tree topology, 파일 blob storage 계획과 비교, V8 isolate 계층 계획, launch audit, god file cleanup refactor가 메모리로 축적되어 있었다.

3.2. 실제 메모리 내용의 유형과 문제

1. 이미 AGENTS.md에 있는 중복 정보

   1. T3 Code가 preview 또는 production mobile build를 절대 건드리지 않는다는 규칙이 저장되어 있었다.
   2. T3 Connect 데스크톱이 server-side relay의 전체 흐름을 처리한다는 사실도 저장되어 있었다.
   3. 이 규칙들은 원래 AGENTS.md에 이미 있었으므로, 메모리는 정보를 보강하지 않고 중복된 두 번째 진실 공급원을 만들었다.

2. 벤치마크를 오염시키는 상태 기억

   1. 발표자는 새 모델을 시험하기 위해 ping/round modernizations 같은 벤치마크를 수행한다. 메모리가 실험 당시의 설정과 판단을 다시 주입하면 새 모델의 순수한 성능 비교가 오염된다.
   2. LM API 호출을 최소 설정하고 provider defaults만 사용한다는 규칙, GBD56 effort가 soft hint라는 정보, 깊은 추론에 dash pro 모드가 필요하다는 정보가 저장되어 있었다.
   3. 이런 설정은 언제든 바뀔 수 있으므로 장기 메모리에 남기면 벤치마크가 현재 의도와 달라질 수 있다.

3. 해결된 문제와 임시 계획의 잔존

   1. GitHub CLI 버전이 오래되어 업데이트했다는 사실처럼 이미 해결된 문제가 메모리로 남았다. 문제를 해결한 뒤에도 “업데이트해야 한다”는 지시가 재등장할 수 있다.
   2. 실제로 출시하지 않은 기능의 live plan URL, 특정 PR 번호, 당시의 remote desktop update와 editor favicon 수정이 저장되어 있었다.
   3. Monitor JSON schema drift, remote PR portfolio, memory crisis hot paths, background policy scope wiring gap, quad probe test leak 같은 항목은 특정 시점에 drift가 있었는지, PR이 merge됐는지, leak이 고쳐졌는지를 설명할 뿐 지속적인 규칙이 아니다.

4. 맥락과 무관한 잡음

   1. Meta Muse Code CLI의 headless 통합을 공개 문서 없이 probing으로 알아낸 기록, 자체 갱신 bash launcher, 모델·모드 정보가 저장되어 있었다.
   2. T3 Connect CLI를 macOS 백그라운드 프로세스로 만들던 작업의 혼동, 이미 데스크톱 앱에서 지원되는 기능, Linux에는 있고 macOS에는 없던 CLI 계획도 저장됐다.
   3. 두 T3 서버가 같은 base directory에서 환경 identity·relay link·runtime state 파일을 두고 경쟁하는 multiprocess hazard의 topology도 남았다. 발표자는 “누가 신경 쓰는가”라는 반응을 보이며 현재 작업에 불필요한 세부사항이라고 평가한다.
   4. Railway 사용 topology, 3개월 전 두 계획의 비교, 세탁기와 건조기 상태를 Discord에서 추적하는 bridge 설정, CC usage pricing override, Moonlight fork와 fish slop rebuild 정보도 메모리에 섞였다.

3.3. 45개 메모리와 사용 통계

1. 메인 clone의 규모와 내용

   1. 메인 T3 Code clone에는 메모리 45개가 있었다. onboarding overhaul, 앱의 babysit monitoring flow, sidebar overhaul 초안과 선호 variant C 등이 포함됐다.
   2. 발표자는 이 중 상당수를 “slop”과 “garbage”라고 부른다. 특정 기능 계획이나 개인 취향이 현재 모든 세션에 주입될 만큼 중요한지 검증되지 않았기 때문이다.

2. 읽기보다 쓰기가 훨씬 많은 구조

   1. 해당 컴퓨터의 T3 Code transcript는 355개가 넘는 세션을 포함한다.
   2. 그중 개별 메모리 파일을 연 세션은 19개뿐이었고, 메모리를 쓰거나 수정한 세션은 80개였다.
   3. 메모리 파일은 읽기보다 약 3 대 1 비율로 더 많이 쓰였다. 45개 메모리 중 26개는 단 한 번도 읽히지 않았다.
   4. 이 수치는 메모리가 실제 행동을 개선하는 지식층이라기보다 세션이 남기는 부산물에 가깝다는 판단의 근거다.

3. 즉각적인 조치

   1. 발표자는 Claude Code가 모든 머신에서 메모리를 사용하지 않도록 끄고, 기존 메모리를 올바르게 라벨링하고 archive한 뒤 삭제하기로 했다.
   2. 삭제 판단은 단순한 취향이 아니라, 중복·일시 상태·해결된 문제·실험 오염·무관한 프로젝트 정보가 현재 에이전트의 방향을 흐린다는 관찰에서 나왔다.

4. 메모리 대신 실패를 제거하는 우선순위

에이전트의 실수를 줄이는 시스템은 과거 지식을 자동 주입하는 시스템이 아니라 실패가 발생할 수 있는 경로를 단계적으로 없애는 시스템이다.

4.1. 에이전트 컨텍스트의 두 가지 목표를 분리하기

1. 실수와 짜증나는 행동 줄이기

   1. 에이전트가 하면 안 되는 일을 하지 않도록 유도하고, 나쁜 방향에서 좋은 방향으로 돌리는 것이 첫 번째 목표다.
   2. 작은 회귀(regression)나 반복되는 실수를 줄이면 사용자가 결과를 다시 확인하고 지시하는 비용이 줄어든다.

2. 방향성 정렬과 설명 비용 줄이기

   1. 사용자가 모든 세부사항을 일일이 말하지 않아도 모델이 원하는 방식으로 행동하게 하는 것이 두 번째 목표다.
   2. 사용자가 작은 작업을 지시했을 때 에이전트가 관련된 세 가지 작업까지 먼저 제안하고, 사용자가 “맞다, 나중에 내가 바로 했을 일이다”라고 느끼는 상태가 방향성 정렬이다.
   3. 두 목표는 비슷해 보이지만 다르다. 메모리 하나로 두 문제를 동시에 해결할 수 있다는 믿음은 실패한다.

4.2. 최상위 해법: 아키텍처와 자료구조로 실패 범주 제거

1. 실패를 애초에 표현할 수 없게 만들기

   1. 에이전트가 잘못된 일을 했을 때 AGENTS.md에 “다시는 하지 말 것”을 한 줄 추가하는 방식은 효과가 있지만, 근본 원인을 남겨 둔다.
   2. 사람과 에이전트가 시스템을 이해하는 방식이 다르거나, 코드베이스 구조가 직관적이지 않거나, 요구사항 전달에 공백이 있는지 먼저 돌아봐야 한다.
   3. 더 나은 아키텍처와 자료구조를 선택해 오류 범주를 통째로 제거하는 것이 가장 높은 가치의 개입이다.

2. tRPC와 Convex가 주는 구조적 이점

   1. tRPC와 Convex처럼 백엔드와 프론트엔드 사이에 type safety를 제공하는 도구는 각 계층을 따로 설계했을 때 생기는 불일치 오류를 제거한다.
   2. 개발자와 에이전트가 동일한 계약을 따라야 하므로, 데이터 형태가 어긋나는 종류의 실수가 애초에 발생하기 어려워진다.
   3. 발표자가 T3 stack을 만들 때 사람의 기여 난도를 낮추려고 선택한 구조가 에이전트에도 좋은 구조가 됐다. AI 전용 요령이 아니라 좋은 소프트웨어 구조가 양쪽 모두에게 이롭다는 뜻이다.

3. 웹 개발 밖의 동일한 원리

   1. Garbage collection은 수동 메모리 해제 누락이라는 오류 범주를 줄인다.
   2. Memory safety는 경계 조건을 개발자와 에이전트가 매번 직접 관리해야 하는 부담을 낮춘다.
   3. 공통 원리는 “실수하지 말라”고 지시하는 것이 아니라, 실수가 일어날 수 있는 표현과 경로를 시스템에서 제거하는 것이다.

4.3. 두 번째 해법: lint·CI·테스트로 남은 오류 차단

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

   1. 발표자는 비행기의 불안정한 Wi-Fi, 터널의 3G, 이동 중 휴대폰에서도 스레드를 따라갈 수 있도록 데이터 전송량을 중요하게 여긴다.
   2. 기능이 늘면서 transit layer가 비대해졌고, 스레드 하나를 로드하는 데 WebSocket으로 수십 MB를 보내는 상태가 됐다.
   3. 코드를 정리해 전송량을 줄인 뒤에도 며칠 안에 회귀가 발생했다. 코드가 단순하고 좋아졌다는 사실만으로 미래의 회귀가 막히지는 않았다.

2. 실제 스레드 replay와 정량적 기준

   1. 발표자는 실제 업무에서 나온 거대한 텍스트 덩어리인 sample thread를 CI에 넣고, Codex와 Claude가 이 스레드를 가짜 replay하도록 구성했다.
   2. replay 중 WebSocket을 통해 전송되는 데이터량을 측정해, 최적화 전 수십 또는 수백 MB였던 값을 전체 기준 100KB 미만, 대부분의 경우 10KB 미만으로 낮췄다.
   3. 최적화가 유지되는지 확인할 수 있도록 수치를 저장하고, 변경 후 각 샘플이 사용하는 bandwidth를 PR에 자동 댓글로 남기는 action을 추가했다.
   4. 최적화가 완료된 시점보다 30% 높은 ceiling을 설정했다. 변경이 그 경계를 넘으면 PR이 실패하고 발표자에게 알림이 간다.

3. 검증이 에이전트의 작업 완료 조건이 되기

   1. 이 검사는 실제 회귀를 이미 여러 번 막았다.
   2. 데이터 계층 변경으로 전송량이 기준을 넘으면 에이전트가 사용자에게 “완료했다”고 알리기 전에 회귀를 감지하고 고친다.
   3. lint rule, CI, custom test, end-to-end test 중 적절한 수단을 사용해 에이전트가 문제가 사용자에게 도달하기 전에 스스로 발견하도록 만드는 것이 목표다.

4.4. 세 번째 이후의 해법: skill과 사람의 검토

1. skill은 기본값이 아닌 fallback이다

   1. 코드 구조와 자료구조로 해결할 수 없으면 lint·CI·테스트로 규칙화한다.
   2. 그 단계까지 시도했는데도 남는 작은 문제만 skill이나 규칙으로 다룬다.
   3. 예를 들어 개발 서버를 원격으로 노출해 Tailscale로 접속하는 절차처럼 코드베이스 자체가 해결할 수 없는 운영 프로세스에는 skill이 유용하다.
   4. 모든 문제를 해결할 거대한 skill 묶음을 상시 구축하는 것은 메모리 시스템과 같은 과잉 설계가 될 수 있다. skill은 안전망이자 fallback으로 취급해야 한다.

2. 마지막 안전망은 사람이다

   1. 아키텍처, lint·CI·테스트, skill과 규칙이 모두 실패하는 드문 경우에만 human-in-the-loop 검토를 둔다.
   2. 사람의 검토가 첫 단계가 되면 자동화가 실패할 때마다 사용자가 직접 같은 판단을 반복한다.
   3. 각 단계에서 멈추기보다, 문제가 사라질 때까지 더 낮은 비용의 구조적 해법을 되돌아보고 적용해야 한다.

5. 인간의 규율 대신 인간의 가치를 에이전트에 전달하기

에이전트가 사용자의 생각 방식과 프로젝트의 목적을 이해하면 작은 금지 목록을 계속 추가하지 않아도 실패가 줄어든다.

5.1. Uncle Bob의 원칙

1. 규율과 가치의 구분

   1. Robert C. Martin(Uncle Bob)은 “에이전트에 인간의 규율을 부과하는 것은 실수일 수 있지만, 인간의 가치를 부과하는 것은 실수가 아니다”라는 취지의 문장을 제시했다.
   2. 발표자는 이를 매우 강력한 표현이라고 평가하며, 최근 몇 달 사이 Uncle Bob이 agentic development에 관해 업계 다수보다 앞선 관점을 갖게 된 변화를 흥미롭게 본다.

2. 절차를 강제하기보다 목표를 공유하기

   1. 테스트 주도 개발(Test-Driven Development)을 높은 규율로 지시해도 에이전트는 자기 방식으로 돌아갈 수 있다. 절차적 행동을 억지로 고정하는 것은 지속성이 낮다.
   2. 반대로 오픈소스 유지, 성능 저하 금지, 원격 연결 지원, 모든 플랫폼 동기화 같은 가치는 에이전트의 판단 기준이 된다.
   3. 가치가 방향을 정하면 에이전트가 세부 절차를 스스로 선택해도 결과는 팀이 원하는 쪽에 가까워진다.

5.2. T3 Code의 AGENTS.md가 제공하는 방향성

1. 제품의 정체성과 작업 맥락

   1. T3 Code는 Node WebSocket 서버가 provider CLI를 감싸 여러 플랫폼에 제공하는 구조라고 짧게 설명한다.
   2. 동시에 Cloud Desktop, Codex App, Cursor, Glass, Conductor 같은 앱을 대체하는 “오픈소스이며 사용자가 자신의 구독을 가져오는(BYOS) 대안”이라는 제품 맥락을 적는다.
   3. 코드를 수정하는 에이전트도 제품을 이해해야 한다. 제품을 이해하지 못하는 엔지니어가 팀에 있을 때 제안과 변경이 엉뚱해지는 것처럼, 에이전트가 정체성을 모르면 방향성 정렬이 어렵다.

2. What makes T3 Code special의 가치

   1. Open at the core: T3 Code는 핵심부터 오픈소스로 남아야 한다. 모델이 보지 못할 코드라며 일부를 closed source로 만들자는 제안을 하면 이 가치에 어긋난다.
   2. Performance without compromise: 사소해 보이는 문장도 모델이 변경의 성능 영향을 한 번 더 생각하게 만들었다. 데이터 로딩 회귀는 실제 코드 최적화보다 에이전트의 반복 회귀 때문에 발생했는데, 이 문장이 많은 회귀를 줄였고 CI가 나머지를 잡았다.
   3. Remote ready: 로컬 Electron 앱에서 잘 작동하는 것만으로 충분하지 않다. 휴대폰 또는 웹으로 원격 접속했을 때도 동작해야 한다.
   4. Multi-surface: 웹, Electron 데스크톱, React Native 모바일 등 서비스를 명시하고 모든 표면에서 예상대로 변경이 작동해야 한다고 적는다.

3. 실행 안전성과 협업 문맥

   1. T3 Code 안에서 T3 Code를 작업할 때 실행 중인 T3 Code 서버를 죽이지 말라는 개인 메모를 둔다.
   2. Glossary는 에이전트와 사람이 공통 언어를 갖게 한다. Claude가 필요하지 않은 멋진 용어를 만들어내는 경향도 줄어든다.
   3. 에이전트가 계속 실행하던 서버 종료 패턴을 별도 섹션에 적자 대부분의 문제가 사라졌다.
   4. 웹에만 변경하고 모바일에는 반영하지 않는 문제를 막기 위해 hit every surface 섹션을 두고, dev server와 test data, verification, pull request 작성 규칙을 각각 설명한다.

5.3. “취향(taste)”과 방향성의 구체화

1. 팀의 설계 취향을 기록하기

   1. Julius가 불만을 제기했던 slop code의 패턴을 taste 섹션에 적어 에이전트가 팀의 선호 방향을 계속 유지하게 한다.
   2. 복잡성은 adapter boundary에 두고 orchestration은 단순하게 만들며 UI는 멍청하게 유지하는 설계를 선호한다.
   3. 불필요한 any 타입과 annotation을 싫어하고, 타입 추론을 활용한다.
   4. 주석은 모든 줄의 행동을 설명하기보다 함수가 어떻게 사용되는지 설명해야 하며, 코드가 이동하면 주석도 함께 이동해야 한다.

2. 플랫폼 간 구조 보존

   1. 웹 앱, Electron 데스크톱 앱, React Native 모바일 앱은 동일한 공유 TypeScript 데이터 로딩 코드를 사용한다.
   2. 세 데이터 계층이 같으면 한 플랫폼만 깨지는 변경이 어렵고, 변경 안전성이 높아진다.
   3. SwiftUI rewrite는 이 구조적 보호를 잃을 수 있어 바로 병합하지 않는다. 실제로 SwiftUI 앱에서는 관계가 명확하게 코드에 표현되지 않아 이미 회귀가 발생했다.
   4. 더 좋아 보이는 앱이라도 codebase drift를 허용해 회귀 범주를 열면 병합하지 않는 것이 장기적으로 더 안전하다.

3. 에이전트가 기대 이상으로 생각하게 되는 기준

   1. 사용자가 작은 작업을 요청했을 때 에이전트가 관련된 다른 표면과 후속 작업을 먼저 짚어야 한다.
   2. 에이전트가 사용자가 원했을 방향으로 더 나아가거나, 나중에 드러날 문제를 미리 지적하면 방향성 정렬이 작동하는 신호다.
   3. 이런 행동은 기본값으로 자연스럽게 생기지 않는다. 제품 맥락, 가치, 용어, 플랫폼 규칙, 팀의 taste를 꾸준히 제공한 결과다.

6. 결론 및 실용적 시사점

1. 코딩 메모리의 기본값을 끄고 현재 상태를 우선하라

   1. Claude Code의 자동 메모리는 중복된 AGENTS.md 규칙, 이미 해결된 사건, 만료된 계획, 벤치마크를 오염시키는 설정을 한데 섞을 수 있다.
   2. 메모리의 read/write 통계를 측정해 실제로 읽히고 행동을 개선하는지 확인하며, 읽히지 않는 파일은 지식이 아니라 저장 비용과 혼란일 가능성이 높다.

2. 실패를 단계별로 제거하라

   1. 먼저 더 나은 아키텍처와 자료구조로 실패 범주를 없앤다.
   2. 제거할 수 없는 실패는 lint, CI, custom test, replay, end-to-end test로 자동 검출한다.
   3. 코드로 해결할 수 없는 운영 절차에만 skill을 추가하고, 마지막에만 사람 검토를 둔다.

3. 간결한 명시적 프로젝트 컨텍스트를 작성하라

   1. AGENTS.md 또는 CLAUDE.md에는 제품이 무엇인지, 지켜야 할 가치, 중요한 플랫폼 표면, 공통 용어, 반복되는 위험 패턴, 검증과 PR 규칙을 적는다.
   2. 과거의 사건과 임시 계획을 영구 규칙처럼 쌓지 않는다. 설명이 현재 코드와 함께 갱신되지 않는다면 제거하거나 코드·테스트로 옮긴다.

4. 절차보다 목표를 정렬하라

   1. “항상 이 순서로 작업하라”는 인간의 규율보다 “오픈소스를 유지하고, 성능을 지키고, 모든 표면에서 작동하게 하라”는 인간의 가치가 더 오래 지속되는 방향 지침이 된다.
   2. 목표가 공유되면 에이전트가 작업 방법을 바꾸더라도 사용자가 원하는 방향으로 판단할 가능성이 높아진다.

5. 새 스레드마다 다시 시작해도 좋은 상태를 만들라

   1. Groundhog Day처럼 모델의 뇌가 매 스레드 시작 때 초기화된다고 해도, 최신 코드와 짧은 가치 문서, 자동 검증이 있으면 안전하게 다시 출발할 수 있다.
   2. 자동 메모리로 낡은 맥락을 보존하는 대신, 에이전트가 현재 저장소를 탐색하고 검증 결과를 통과하며 팀의 목표에 맞춰 추론하도록 설계한다.
   3. 최종 목표는 에이전트가 사용자의 의도를 너무 잘 이해해 예상보다 한 걸음 더 나아가되, 그 방향이 정확히 원하는 방향인 상태다.

주요 발언 모음

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

“코딩에는 메모리 시스템이 필요 없다.”

“bash가 필요한 전부다.”

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

“메모리는 쓰이는 것보다 훨씬 더 많이 작성된다.”

“끝까지 남는 결론은 그 메모리를 불태우라는 것이다.”

핵심 데이터 & 수치

• 38분 8초: Tech Bridge 콘텐츠의 재생 시간이다.
• 9일 전: BB1에서 발견된 유일한 Claude Code 메모리가 생성된 시점이다.
• 45개: 메인 T3 Code clone에 저장된 메모리 수다.
• 26개: 45개 중 단 한 번도 읽히지 않은 메모리 수다.
• 355개 이상: 해당 컴퓨터의 T3 Code transcript 세션 수다.
• 19개 세션: 개별 메모리 파일을 연 세션 수다.
• 80개 세션: 메모리를 작성하거나 수정한 세션 수다.
• 약 3 대 1: 메모리 read보다 write/edit가 많았던 비율이다.
• 수십 MB: 최적화 전 T3 Code 스레드 하나를 WebSocket으로 로드할 때 전송되던 데이터 규모다.
• 100KB 미만 / 대부분 10KB 미만: replay 기반 최적화 후 스레드 전송량 목표와 일반적인 결과다.
• 30%: 최적화 완료 기준보다 높게 설정한 CI bandwidth ceiling의 여유 폭이다.

핵심 요약 (20줄)

1. 코딩 에이전트의 현재 행동은 자동 메모리보다 실행되는 코드와 테스트를 진실의 원천으로 삼아야 한다.

2. 별도 메모리 파일은 코드가 변한 뒤 갱신되지 않으면 두 번째 진실 공급원이 되어 에이전트를 오도한다.

3. 오래된 주석과 조잡한 Markdown 계획 파일도 현재 코드와 충돌하면 적극적으로 해로운 컨텍스트가 된다.

4. 코드는 호출 관계와 파일 구조를 직접 추적할 수 있지만 인간의 생활 문제는 간접적인 관련성을 검색해야 한다.

5. 사용자별 과거 정보 태깅은 대화에서 유용할 수 있어 코딩 메모리와 대화 메모리를 같은 방식으로 취급하면 안 된다.

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

7. 현대 모델은 bash 도구로 저장소를 직접 탐색할 만큼 훈련되어 복잡한 그래프 기반 컨텍스트 계층의 필요성이 줄었다.

8. Cursor도 과거의 동적 코드 매핑 중심 접근에서 모델의 직접 탐색을 활용하는 방향으로 이동했다.

9. Slack 봇은 질문과 답변을 하나의 append-only JSONL 로그에 남기고 jq로 필요한 기록을 찾아 무한 기억을 구현할 수 있다.

10. Claude Code가 T3 Code에 남긴 45개 메모리 중 26개는 한 번도 읽히지 않았고, 읽기보다 쓰기가 약 세 배 많았다.

11. 저장된 내용에는 이미 AGENTS.md에 있는 규칙, 해결된 문제, 만료된 계획, 벤치마크 설정, 무관한 프로젝트 잡음이 섞여 있었다.

12. 메모리의 첫 번째 실패는 에이전트가 무엇을 기억했는지가 아니라 그 기억이 현재 작업에 실제로 쓰이는지 검증하지 않는 것이다.

13. 에이전트 품질을 높이는 첫 단계는 더 나은 아키텍처와 자료구조로 실패 범주를 없애는 것이다.

14. tRPC와 Convex의 타입 안전성은 백엔드와 프론트엔드 불일치 오류를 구조적으로 줄여 사람과 에이전트 모두의 실수를 낮춘다.

15. 구조로 제거하지 못한 오류는 lint, CI, custom test, replay, end-to-end test로 사용자에게 도달하기 전에 차단해야 한다.

16. T3 Code는 실제 대형 스레드를 replay해 WebSocket 전송량을 대부분 10KB 미만으로 유지하고 30% 초과 시 PR을 실패시킨다.

17. skill은 코드와 CI가 해결할 수 없는 원격 서버 노출 같은 프로세스 문제에만 쓰는 안전망이어야 한다.

18. 에이전트에 인간의 절차적 규율을 강제하기보다 오픈소스, 성능, 원격 사용성 같은 인간의 가치를 전달하는 편이 오래 간다.

19. AGENTS.md에는 제품 맥락, 가치, 용어, 플랫폼 규칙, 검증 방법, 팀의 설계 취향을 최신 상태로 간결하게 기록해야 한다.

20. 최종 목표는 매번 새 스레드가 시작돼도 에이전트가 사용자의 방향을 이해해 예상보다 한 걸음 더 나아가는 상태다.