AI 코딩 에이전트의 메모리 파이프라인 설계

원문 제목: [한영자막] AI 코딩 에이전트에 메모리 파이프라인이 왜 필요할까요? URL: https://www.youtube.com/watch?v=Yhck-x6VuLs 날짜: 2026-10-14 처리일: 2026-10-15 채널: Tech Bridge 길이: 53분 29초

---

📌 핵심 질문 / 핵심 논점

==코딩 에이전트가 여러 세션에서 발견한 사실, 사람이 에이전트를 수정한 내용, 에이전트가 반복해서 조사한 질문을 어떻게 검증 가능한 메모리로 바꾸고, 오래된 메모리를 정리하면서도 낮은 비용으로 지속 개선할 것인가?==

• 한 세션 안에서 에이전트가 학습하거나 사용자가 얻은 지식은 새 컨텍스트 윈도우가 열리면 사라진다.
• 유용한 메모리는 일반적인 조언이나 코드만 읽어도 알 수 있는 사실이 아니라, 여러 세션에서 반복되고 코드베이스의 맥락에 연결된 팀의 고유 지식이어야 한다.
• 원시 로그 전체를 강한 모델에 매번 넣는 대신, 값싼 분류·필터링과 강한 모델의 심사를 섞고, 캐시·재생·관찰 도구로 파이프라인을 빠르게 개선해야 한다.
• 메모리 승인·거부 피드백을 다음 실행의 입력으로 넣고, 메모리의 건강 상태와 최신성을 별도로 평가해야 지속 가능한 시스템이 된다.

Dex Horthy(Human Layer CEO·공동창업자)와 Aaron(BAML 공동창업자·CTO)은 Human Layer 팀과 Boundary 팀이 에이전트 trace에서 context shard를 생성한 사례를 따라간다. 결과물은 특정 코드 영역에 연결된 Markdown 파일, 반복 질문 보고서, 사람이 승인하거나 수정할 수 있는 초안이다. BAML은 구조화된 LLM 함수, 입력·출력 캐시, 재생(replay), BAML Query 기반 프로그램 데이터베이스를 이용해 이 과정을 빠르게 실험할 수 있게 한다.

1. 세션 사이에서 사라지는 코딩 지식

한 번의 코딩 세션에서 얻은 팀의 암묵지와 수정 이력을 다음 세션으로 옮기는 일이 메모리 파이프라인의 출발점이다.

1.1. 에이전트의 학습과 망각

1. 세션 안의 반복적 학습

   1. 초기 요청과 도구 사용: 사용자는 시스템 프롬프트와 도구가 주어진 에이전트에 작업을 요청하고, 에이전트는 파일을 읽고 쓰고 편집하며 명령을 실행한다.
   2. 피드백을 통한 수정: 에이전트가 작업을 끝냈다고 말한 뒤 사용자가 “이건 이유 1과 이유 2 때문에 좋지 않다”라고 지적하면, 에이전트는 수정하고 추가 피드백을 받는다.
   3. 서로 다른 학습: 사용자는 세션에서 코드베이스에 대해 새로 배우고, 에이전트는 사용자의 선호·금지사항·코드 구조를 배운다. 이 학습은 현재 컨텍스트 윈도우가 끝나면 사라진다.

2. 반복 비용의 구체적 모습

   1. 같은 실수 반복: 사용자가 “제발 그 명령을 다시 실행하지 마”라고 말했는데도 다음 세션에서 에이전트가 같은 명령을 다시 시도할 수 있다.
   2. 숨은 지식의 재발견: 에이전트가 특정 사실을 알아내기 위해 500번의 tool call을 써야 했다면, 작은 snippet·diagram·architecture flow를 남겨 다음 세션의 탐색을 줄일 수 있다.
   3. 기억할 대상의 선별: 모든 대화나 tool call을 CLAUDE.md, AGENTS.md, skill 파일에 넣는 것은 메모리가 아니며, 조건에 따라 불러올 수 있는 지식 조각을 골라야 한다.

1.2. Context shard라는 단위

1. 초기 명칭과 목적

   1. Context shard: “memory”라는 말이 너무 포괄적이어서, 특정 작업이나 세션에서 조건부로 활성화할 지식 조각을 context shard라고 부른다.
   2. 구성 요소: shard의 내용, 왜 기억할 가치가 있는지에 대한 reasoning, 근거가 된 세션과 메시지의 citation을 함께 저장한다.
   3. 추적성: session ID, message ID, user ID를 보존해 실제 대화 이벤트까지 되돌아갈 수 있게 한다. 여러 사람이 같은 조직에서 에이전트를 쓰면 누가 어떤 사실을 말했는지도 구분한다.

2. 초기 접근의 한계

   1. 단순한 입력: 한 컨텍스트 윈도우에서 user·assistant 메시지만 추출하고 tool call을 효율성 때문에 제거한 뒤, Haiku의 단일 structured output 호출로 finding을 만들었다.
   2. 초안 품질: 방향은 맞았지만 결과가 “매우 나빴다”. 일부 finding은 유용했으나 prompt를 계속 조정해야 했고, shard를 task나 session에 enable하는 기능만으로는 실전 품질을 보장하지 못했다.
   3. 낡은 메모리 문제: 메모리는 시간이 지나면 out-of-date가 된다. Compounding Engineering이나 Matt Pocock의 retro skill처럼 과거 세션의 실패를 찾아 재발을 막는 접근은 있었지만, 어떤 정보를 기억으로 승격할지와 어떻게 계속 정제할지는 남는 문제였다.

2. 실제 산출물과 메모리의 세 가지 종류

일주일치 BAML 팀 세션을 분석해 특정 코드 영역에 연결된 세 개의 Markdown 파일과 보고서를 만들었다.

2.1. 특정 코드 영역에 묶인 Markdown 결과

1. 코드 위치를 아는 메모리

   1. 영역별 파일: BAML compiler나 BAML built-ins 같은 코드 영역에 맞춰 MD 파일을 생성한다.
   2. Where to find: 에이전트가 저장소를 탐색할 때 어디를 읽어야 하는지, 일반적인 아키텍처가 무엇인지 안내한다.
   3. 한 줄 설명의 한계: BAML compiler가 하는 일을 한 줄로 설명한 결과처럼 너무 일반적인 산출물도 있어 계속 조정한다.

2. Rules와 information

   1. Rules: 사람이 에이전트의 행동 방식이나 접근 방법을 직접 교정한 규칙이다. “이걸 망치지 말고 이렇게 하라”는 발화를 찾아 반복 여부를 확인한다.
   2. Information: 저장소를 직접 읽어서는 쉽게 알기 힘든 참인 사실이다. 예를 들어 BAML에서 명시적인 첫 self parameter는 instance method를 표시하고 receiver가 되며, self가 없는 method는 static이다.
   3. 근거와 반복성: 이 BAML 언어 사실은 세 세션에서 두 사람이 마주친 내용으로 기록됐다. 여러 session의 사실을 합쳐 shard 하나를 만들고 모든 근거 세션을 연결한다.

3. 실제 팀 지식

   1. tribal knowledge: BAML built-ins에서 @add internal syntax를 사용하지 말라는 식의 지식은 코드만 훑어서는 명확하지 않고 팀 경험에 가깝다.
   2. 조건부 검색: 에이전트가 어느 영역에서 작업하는지에 따라 관련 shard를 보여 주므로, 200개의 무관한 지침을 항상 컨텍스트에 넣지 않는다.
   3. 승인 전 초안: 결과가 모두 완벽하지 않으므로 사람이 보고 code에 추가할지 판단할 수 있는 초안·보고서로 제공한다.

2.2. 반복 질문과 코드 지도

1. 세션만으로 먼저 찾는 문제

   1. 반복 질문: BAML standard library의 선언 방식이나 현재 built-in 파일 조직처럼 에이전트가 계속 묻는 질문을 집계한다.
   2. 11세션·2명 사례: 한 질문이 11개 세션에서 두 사람에 의해 반복됐다. 이는 단순한 개인 실수보다 저장소 자체의 발견성(discoverability) 문제에 가깝다.
   3. 저장소를 붙인 뒤 달라진 결론: 세션 로그만 보면 사실을 Cloud MD에 넣어야 할 것 같지만, 저장소를 함께 주면 에이전트가 architecture.md를 읽지 않고 있다는 원인을 찾을 수 있다.

2. 정보를 더 넣는 대신 참조를 고치는 선택

   1. 과잉 주입 회피: Cloud MD에 사실을 잔뜩 복사하는 대신 에이전트가 문제를 조사하게 할 보고서를 저장소에 두는 방식이 가능하다.
   2. 참조 파일 연결: CLAUDE.md에 architecture.md를 읽으라는 참조만 추가하면 반복 질문의 원인을 해결할 수 있다.
   3. 핵심 원칙: 메모리 파이프라인의 목표는 지식을 무조건 늘리는 것이 아니라 에이전트가 이미 가진 코드·문서와 중복되지 않는 지식을 정확한 위치에서 찾게 하는 것이다.

3. 코드베이스 heat map

   1. 경로 수집: 에이전트가 읽고 탐색한 모든 경로를 수집해 저장소의 code map을 만든다.
   2. 범위 판단: 여러 파일·여러 영역에 걸친 사실은 context shard 후보로 올리고, 특정 파일의 단순한 문법 사실은 낮은 우선순위로 둔다.
   3. 반복 사실 그룹화: 서로 다른 세션에서 추출한 사실 중 같은 내용을 묶고, 반복 횟수와 근거 세션을 기록해 “충분히 자주 나타나 기억해야 하는가”를 판단한다.

3. 빠르고 저렴하게 개선하는 파이프라인 개발법

메모리 추출 품질보다 먼저 로그를 이해할 수 있는 도구와 빠른 반복 루프를 만들고, 가장 지능적인 접근에서 출발해 비용·지연을 줄이는 방식으로 구체화한다.

3.1. 도구를 먼저 만들고 가장 강한 모델로 기준선을 세우기

1. 대시보드 중심의 탐색

   1. 많은 화면의 필요성: 결과를 이해하려고 대시보드를 약 10개 만들었고, 시연한 것은 버전 10이다.
   2. 세션 화면: 각 세션의 메시지를 순서대로 읽는 기본 화면은 유지했다.
   3. 필터·시각화: tool call만 또는 human message만 필터링하고, 어떤 세션에서 어떤 정보가 추출되어 어떤 결과가 되었는지 Sankey diagram으로 연결했다.

2. Claude Code를 탐색 도구로 사용

   1. 보고서 자동 조사: Claude Code가 모든 데이터를 읽고 중요한 것과 중요하지 않은 것을 판단하게 해, 사람이 직접 전 세션을 읽지 않아도 되는 초기 보고서를 만든다.
   2. 관찰을 통한 설계 발견: 에이전트가 어떤 메시지를 걸러내고 어떤 데이터를 보는지 관찰하면서 실제로 필요한 workflow를 역설계한다.
   3. 스마트한 기준선에서 시작: 처음에는 가장 똑똑한 모델과 열린 형태의 pipeline으로 가능한 품질을 확인한 뒤, 효과가 입증된 패턴을 더 저렴하고 빠른 모델·더 구체적인 workflow로 distill한다.

3. 비용의 기준선

   1. 탐색 비용: 같은 보고서를 Claude Code로 만들 때 API 사용료가 약 100달러까지 들 수 있었다.
   2. 최적화 후 비용: 한 번의 보고서를 약 50센트 수준으로 낮췄고, 일주일치 coding data를 분석하는 workflow 설명 중에는 “2달러”라고 말했다가 곧 “세션당 2센트($0.02)”로 정정했다.
   3. 설계 시사점: 세션당 수많은 token을 쓰는 것과 비교하면 $0.02 분석비는 반복 실행 가능한 수준이며, 값싼 선별 모델과 강한 모델의 역할 분담이 중요하다.

3.2. BAML 함수와 캐시·재생

1. 구조화된 LLM 함수

   1. 입력·출력 중심 설계: BAML에서 message scoring 같은 LLM function을 정의하고 workflow의 입력과 출력을 명확히 한다.
   2. 확률 점수: 함수는 0~1 범위의 단일 float를 출력하며, BAML은 이를 설명과 일치할 확률로 다룬다.
   3. 분류 예시: 에이전트가 media를 보며 무언가를 발견하려는지, human reply가 실제 correction인지 단순히 “다음 단계인 phase six를 진행하라”는 요청인지 분류한다.

2. 입력 hash와 disk cache

   1. 문제: workflow 중간의 prompt 하나를 바꿀 때마다 전체 workflow를 처음부터 실행하면 정답을 찾는 데 너무 오래 걸린다.
   2. 해결: request input을 hash하고 결과를 JSON 파일로 disk에 캐시한다.
   3. 아이디어의 확장: Bun의 Jared Sumner가 fetch 요청·응답을 SQLite에 쉽게 cache하면 좋겠다고 말한 사례에서 영감을 얻어, 메시지와 전체 pipeline을 replay할 수 있는 기능을 핵심 도구로 삼는다.

3. 길이 제한과 prompt 관찰

   1. 잘못된 pruning: 긴 human·agent message를 통째로 자르면 중요한 맥락이 사라진다.
   2. 중간 자르기: 메시지의 처음과 끝은 보존하고 중간을 잘라 summary와 핵심 지시를 남긴다. 끝에 붙은 무작위 design document를 그대로 넣지 않아 token도 줄인다.
   3. prompt를 직접 읽기: 코드 전체를 읽지 않더라도 각 단계의 prompt를 출력해 실제 pipeline이 무슨 일을 하는지 확인해야 한다. 모델이 자동으로 만든 prompt에는 이미 모델 weight에 있던 상투적인 “항상 테스트를 실행하라”, “코드를 간결하게 유지하라” 같은 문구가 들어가기 쉬워 새 정보가 되지 않는다.

3.3. 평가 기준과 사람의 피드백

1. Golden run 비교

   1. 기준 데이터: 초기 Claude Code 실행으로 얻은 좋은 context shard를 golden data set으로 삼는다.
   2. Recall 우선: 새 prompt가 유용한 메시지를 놓치지 않는지 확인한다.
   3. 60% 보존·100% 유용 데이터 유지: 전체 text의 60%만 남겼지만 가치 있는 데이터는 100% 유지한 결과를 얻어, “이 정도면 충분히 좋다”고 판단했다.

2. Jev 기반 분류

   1. 최신 분류 모델의 활용: 프로젝트를 작업하는 동안 Jev가 출시되어, discovery score처럼 “무언가를 찾으려는 메시지인가”를 분류하는 데 사용했다.
   2. 대체 모델: Jev가 없었다면 작은 모델을 사용했을 것이며, Luna도 대안이지만 Jev보다 비싸다고 판단했다.
   3. 비용 절감: 분류는 어떤 AI pipeline에서도 흔한 문제이므로, 강력한 분류 모델로 처리할 데이터 양을 먼저 줄이면 전체 비용을 크게 낮출 수 있다.

3. 사람이 쓸 결과인지 확인

   1. 핵심 질문: 팀에 결과를 보여 줄 때 “이것을 실제 code에 추가하겠는가?”를 묻는다.
   2. 초기의 미온적 반응: 처음에는 “될 수도 있고 안 될 수도 있다”는 반응이 많았다.
   3. 구체화의 효과: 최상위 repository용, BAML built-ins용처럼 context shard의 적용 범위를 구체화하자 결과가 실제로 더 유용해졌다.
   4. 947개에서 분해: 처음에는 memory 후보가 947개에 달했지만, 사실·human correction·반복 research 질문의 세 pipeline으로 나누면서 검토 가능한 단위가 되었다.

4. 세 갈래 추출·정제 파이프라인

세 입력을 분리하면 일반 사실, 사람의 교정, 에이전트가 막혀 반복 조사한 질문을 각각의 기준으로 판단할 수 있다.

4.1. 코드베이스 사실(what agents found out)

1. 사실 후보 추출

   1. 범위: transcript에서 코드베이스에 관한 작은 사실을 찾는다. 이는 에이전트가 반복해서 research한 것보다 넓은 범주다.
   2. 단순 사실과 광범위한 사실: “BAML은 이 위치에 decorator가 필요하다” 같은 사실부터 17개 파일에 걸쳐 있는 구조적 사실까지 모두 후보가 된다.
   3. 코드 지도 연결: 에이전트가 방문한 모든 path를 code map과 heat map에 연결해 사실의 영향 범위를 파악한다.

2. 반복 그룹화와 기억 승격

   1. 동일성 판정: 별도 coding session에서 추출된 사실 중 같은 내용을 찾는다.
   2. 근거 묶기: 같은 사실이 10~11개 세션에서 반복되면 하나의 context shard로 묶고 모든 세션을 citation으로 남긴다.
   3. 축적 의미: 한 번 우연히 나온 정보보다 여러 사람이 반복해서 발견한 정보가 팀이 기억해야 할 가능성이 높다.

3. 중복·상식 제거

   1. tribal knowledge 여부: 팀만 아는 운영 규칙인지 판단한다.
   2. 코드로 충분한지 여부: 파일이나 함수를 읽는 즉시 알 수 있는 내용이면 메모리로 다시 쓰지 않는다.
   3. 탐색 비용 기준: 10개 파일을 읽어야 알 수 있는 관계처럼 코드만 읽어서는 명확하지 않은 정보를 남긴다.

4.2. 사람의 교정(what humans corrected agents)

1. 교정 메시지 보존

   1. 강한 신호: 사람이 에이전트의 결정을 직접 고친 message는 generic fact 추출기가 놓칠 수 있으므로 별도 sub-pipeline에서 찾는다.
   2. 구체적 사례: 사람이 “relative namespace가 없으므로 root namespace여야 한다. 모든 이름은 namespace에 local하다”라고 말한 경우는 명백한 correction이다.
   3. 목적: 사람이 직접 수정한 지식을 잃지 않고 다음 agent가 같은 실수를 피하도록 저장한다.

2. Correction과 단순 지시 구분

   1. 오탐 방지: 사람이 “phase six를 진행하라”고 말한 것은 이전 결과의 오류를 교정한 것이 아니라 다음 단계를 지시한 것이다.
   2. 분류 모델: Jev가 reply가 correction인지 아닌지를 분류해 이 둘을 나눈다.
   3. 그룹화: correction 후보를 Opus로 다시 묶고, 최종 draft writer가 사람이 읽을 보고서로 만든다.

3. 규칙 분류와 보고서

   1. enum 분류: defect·internals 같은 유형을 enum으로 정의하고 BAML이 모델에 전달한 뒤 가장 적합한 값을 선택한다.
   2. 보고서 예시: “first built-in pipeline을 고쳐라”, “compiler to state를 677 tool call로 조사했다” 같은 결과를 보고서에 남긴다.
   3. 실행 가능성: 단순히 교정 문장을 쌓는 대신 어느 code 영역에 어떤 행동 규칙이 필요한지 연결한다.

4.3. 반복 연구 질문(what agents kept researching)

1. 반복 질문의 원천

   1. sub-agent 입력: parent model이 sub-agent에 전달한 첫 user message, 즉 “무엇을 찾아오라”는 지시를 질문 후보로 사용한다.
   2. path 추출: tool call에 정규식(regex)을 적용해 directory name·file path 등을 뽑고, 같은 directory가 몇 번 방문됐는지 센다.
   3. 반복성 기준: 서로 다른 사람과 서로 다른 세션이 저장소 작동 방식을 묻는 질문을 반복하는지 확인한다.

2. 질문에 답하는 파일 찾기

   1. 전체 파일 대상: Markdown 파일만 보지 않고 에이전트가 실제로 read tool로 읽은 모든 파일을 대상으로 삼는다.
   2. Opus의 역할: sub-agent의 최초 질문과 trajectory에서 읽은 파일 내용(documents)을 함께 주고, 어떤 문서가 질문에 가장 잘 답하는지 Opus가 판단한다.
   3. 답변의 근거: 단순히 “이 파일을 읽어라”가 아니라 질문, 실제 읽은 파일, 파일 내용의 관계를 보존한다.

3. Code map 보고서 검증

   1. 구조 요약: sub-agent가 무엇을 했는지, 어떤 component가 관여했고 어디에 있으며 어떻게 연결되는지 요약한다.
   2. 답변성 판정: Jev에게 보고서가 최초 질문에 답했는지 다시 묻는다.
   3. 최종 연결: 검증된 보고서에서 draft와 실제 memory report를 만들며, 한 질문이 네다섯 세션에서 되풀이된 사례처럼 재발 비용이 높은 항목을 앞세운다.

5. BAML Query로 만드는 관찰·개발 도구

AI observability의 범용 화면만 기다리지 않고, 파이프라인의 실제 의사결정에 맞는 UI를 에이전트가 직접 만들 수 있도록 실행 데이터를 프로그램 데이터베이스로 보존한다.

5.1. 수동 instrumentation의 한계

1. 일반적인 tracing 절차

   1. span 생성: 보통 코드는 start active span을 호출하고, response를 열고, error를 잡고, span의 error와 status를 설정해야 한다.
   2. 반복 부담: LLM function이 많아질수록 각 지점에 이런 계측 코드를 넣는 일이 번거롭다.
   3. 데이터 손실 위험: 필요한 입력·출력·token 정보를 빠뜨리면 pipeline을 재현하거나 prompt를 비교하기 어렵다.

2. BAML의 자동 기록

   1. 자동 span: BAML은 특정 함수, 특히 감지된 LLM function에 대해 span과 실행 정보를 자동으로 만든다.
   2. 실행 데이터 보존: LLM call의 input·output·output token 같은 데이터를 프로그램 실행과 함께 저장한다.
   3. CLI query: 실행 후 BAML query를 호출해 프로그램이 어떻게 동작했는지 질의하고, 그 결과를 다시 모델이 보고서로 만들 수 있다.

5.2. 프로그램 데이터베이스와 맞춤형 UI

1. BAML Query의 구조

   1. 자동 생성 DB: 프로그램을 실행하면 내부 실행 정보를 담은 program database가 자동으로 생성된다.
   2. SQL 접근: agent가 이해하고 사용할 수 있는 SQL을 질의 언어로 제공해 원하는 표·관계·실행 trace를 조회한다.
   3. 로컬 실행: 클라우드 플랫폼에서도 쓸 수 있고 로컬에서도 실행할 수 있다.

2. 범용 observability보다 맞춤형 화면

   1. BAML Playground의 한계: 예전 playground만으로는 실제 팀이 내리는 구체적인 판단을 모두 지원하기 어렵다.
   2. 직접 만드는 화면: 대시보드·diagram·세션 기록·입력·출력 화면을 실행 데이터 위에 직접 만들고, 각 recording을 열어 결과를 비교한다.
   3. 범용 서비스의 한계: 일반 AI observability dashboard가 특정 repository의 context shard 품질과 반복 질문을 보여 주는 UI까지 만들어 주지는 않는다.

3. 에이전트가 UI를 만드는 방식

   1. 코드 우선 접근: 사용자가 복잡한 화면을 클릭하고 드래그하기보다 모델에게 데이터 위에 필요한 UI를 작성하게 한다.
   2. Web server: 백그라운드 web server가 shell command로 BAML Query를 실행하며, 원하면 native binding도 사용할 수 있다.
   3. 내부 상태 API: BAML은 Turing-complete language이므로 server를 작성할 수 있고, Go처럼 실행 중인 프로그램의 내부 상태를 API route로 노출하는 방식도 가능하다.

6. 메모리 건강 상태와 최신성

승인된 메모리를 계속 컨텍스트에 넣으면 모델이 이미 아는 일을 다시 지시받아 오히려 방해받을 수 있으므로, 저장 방식과 별개로 memory health를 평가해야 한다.

6.1. Stale memory와 과도한 skills

1. 메모리의 역효과

   1. 중복 지시: 과거에는 매번 알려줘야 했던 규칙이 현재 모델에 이미 내재화됐는데도 계속 전달하면 모델을 “hobble”할 수 있다.
   2. 대규모 skill stack: 사실 하나당 skill 하나를 만들어 200개 skill을 모델이 필요할 때 호출하게 하면 user message가 쌓이고 attention이 약해질 수 있다.
   3. 평가 공백: skill이 몇 개까지 잘 쌓이는지, 어떤 skill이 stale해지는지, 이를 측정할 public benchmark가 아직 충분하지 않다.

2. Cognition의 Devon 사례

   1. memory graph: Cognition은 여러 세션에 걸친 “dreaming”으로 사용자가 일하는 방식을 memory graph에 쌓는 접근을 공개했다.
   2. 저장 구조와 추출 pipeline의 차이: repository layout, entries, metadata, composability처럼 저장·참조 방식은 보여 주지만, 무엇이 memory가 될 자격을 얻는지의 추출 과정은 충분히 드러나지 않는다.
   3. 단일 세션의 한계: CLAUDE.md에 “memory 후보를 발견하면 파일에 써라”라고 지시하는 방식은 한 세션 안에서는 작동할 수 있지만 여러 세션의 상관관계를 보기 어렵다.

6.2. 정리·검증 전략

1. 라벨과 재구성

   1. 폴더보다 label: Gmail이 folder 대신 label을 택한 것처럼, 하나의 memory가 여러 맥락에 속할 수 있게 해야 한다.
   2. 주기적 consolidation: 주기적인 cron job이 전체 memory를 훑고 compact·coalesce·deduplicate한다.
   3. 재배치 가능성: 특정 위치에 한 번 넣으면 다른 곳에서 못 쓰는 계층보다, 여러 repository 영역과 task에서 재조합할 수 있는 구조가 유리하다.

2. Staleness 판정의 어려움

   1. 메모리 없이 일부 실행: stale 여부를 확실히 보려면 일정 비율의 세션을 memory 없이 실행해 성능을 비교해야 한다.
   2. 현실적인 저항: 사용자는 memory가 더 이상 필요하지 않을지도 모른다는 이유로 에이전트가 느려지고 혼란스러워지는 실험을 원하지 않을 수 있다.
   3. Backtest: 새 모델에 과거 trace를 넣고 같은 initial prompt에서 memory가 필요한지 비교할 수 있지만, long-horizon trace의 초반 100개 message 중 하나가 달라지면 뒤의 user message·tool call을 같은 입력으로 볼 수 없다.

3. 코드 영역에 연결한 건강 검사

   1. 위치 기반 연결: 각 memory를 codebase의 특정 region이나 code map에 연결하면 해당 파일이 바뀌었을 때 검토할 범위를 좁힐 수 있다.
   2. 현재 작업과의 비교: 에이전트에게 현재 context와 방금 작업한 파일을 보고 memory가 outdated인지 묻게 할 수 있다.
   3. 사후 분석: 세션을 다시 분석해 “그건 틀렸고 지금 고치겠다”라고 말한 message를 찾아 memory health의 오류 신호로 삼을 수 있다.
   4. 사람의 판정: 자동 판정이 애매한 경우 사람이 memory를 승인·거부·수정하게 한다.

7. 승인·거부 피드백을 다음 파이프라인으로 되돌리기

메모리를 한 번 생성하고 끝내지 않고, 사람의 선택을 incremental input으로 넣어 추출 기준과 최종 보고서를 함께 진화시킨다.

7.1. 네 번째 입력으로 기존 메모리 전달

1. 증분 실행

   1. 기존 승인 메모리: 동일한 세션을 다시 넣어도 같은 결과가 반복 생성되지 않도록, 이미 승인되어 저장된 memory·현재 CLAUDE.md·skill을 네 번째 input으로 final draft/report 단계에 넣는다.
   2. 승격 상태: user가 승인한 memory는 후보가 아니라 approved memory로 취급한다.
   3. 중복 방지: 기존 승인 항목을 알고 있으면 최종 단계가 이미 유통 중인 항목에 대한 새 report를 만들지 않는다.

2. 거부와 이유

   1. dismissed memory: user가 “이건 나쁘다”, “이미 다른 곳에서 처리됐다”, “관련 없다”고 거부한 항목도 다음 실행에 전달한다.
   2. 제거 제안: 최종 보고서는 추가할 memory뿐 아니라 memory system에서 제거해야 할 항목도 제안할 수 있다.
   3. 최종 단계부터 개선: 사람이 직접 보는 final report 단계가 가장 쉽게 수정되므로, 먼저 이 단계에 feedback을 넣고 점차 앞단으로 확장한다.

7.2. 전체 파이프라인의 eval loop

1. 앞단 기준 수정

   1. 반복해서 거부되는 후보를 모으면 fact·correction·research 질문을 찾는 기준이 잘못됐는지 알 수 있다.
   2. agent나 별도의 feedback engine이 user의 거부 이유를 분류해 초기 filtering과 grouping prompt를 조정한다.
   3. 승인·거부·수정 결과를 누적하면 파이프라인 자체가 팀의 메모리 기준을 학습하는 eval climb를 형성한다.

2. 운영 주기

   1. 매일 또는 매주 새 세션을 분석해 후보를 만든다.
   2. 사람이 최종 draft를 검토해 add·keep·remove를 선택한다.
   3. 다음 실행은 기존 승인·거부 메모리와 새 trace를 함께 사용해 중복을 줄이고 품질을 높인다.

주요 발언 모음

“새 세션을 시작하면 그 학습은 새로운 컨텍스트 윈도우에서 사라진다.”

“코드만 읽어도 알 수 있는 내용은 다시 적고 싶지 않다. 코드에서 명확하지 않은 것을 남기고 싶다.”

“가장 똑똑한 모델과 가장 열린 pipeline 형태로 시작해 무엇이 가능한지 본 다음, 패턴을 찾으면 latency와 price를 최적화하도록 distill하라.”

“프롬프트를 읽어라. 코드를 읽지 않더라도 적어도 프롬프트는 읽어라.”

“전체 텍스트의 60%만 남겼지만 가치 있는 데이터는 100% 보존했다.”

“메모리 하나당 skill 하나를 200개 만들고 모델이 필요할 때 호출하게 하는 방식이 얼마나 잘 작동할지 모르겠다.”

“사람에게 여섯 개의 테이블과 사용 설명서, 프로그램을 만드는 100페이지짜리 PDF를 주는 대신 에이전트에게 데이터베이스 접근 권한과 실행할 SQL을 주면 된다.”

핵심 데이터 & 수치

• 영상 길이: 53분 29초다.
• 분석 범위: BAML 팀의 약 1주일 coding session을 분석했다.
• 초기 산출물: 코드 영역에 연결된 MD 파일 3개와 보고서·초안 UI를 만들었다.
• 반복 질문 사례: BAML built-in 파일 조직에 관한 질문이 11개 세션, 2명의 사용자에게서 반복됐다.
• 반복 연구 사례: 일부 질문은 4~5개 세션마다 다시 나타났고, 특정 compiler-to-state 조사는 677 tool call을 사용했다.
• 분석 비용: 설명 중 일주일 데이터 비용이 $2로 잘못 언급됐다가 세션당 $0.02로 정정됐다. 별도 비교에서 Claude Code로 같은 보고서를 만드는 비용은 약 $100, 최적화된 보고서는 약 $0.50 수준이었다.
• 대시보드 반복: 데이터 이해를 위해 약 10개의 dashboard를 만들었고 시연 화면은 version 10이었다.
• 초기 후보 수: 단순 pipeline에서 약 947개의 memory 후보가 나왔다.
• 토큰 절감 평가: text의 60%만 유지하면서 golden data set의 가치 있는 항목은 100% 유지했다.
• 메모리 규모 우려: 사실 하나당 skill 하나를 만들면 200개 skill이 생길 수 있으며 attention과 invocation 품질 문제가 생긴다.
• 메모리 분류 축: 사실(what agents found out), 사람의 교정(what humans corrected agents), 반복 연구(what agents kept researching)의 세 갈래로 분리했다.

결론 및 시사점

1. 코딩 에이전트의 지속 메모리는 대화 전문을 저장하는 기능이 아니라, 여러 세션의 trace에서 재발 비용이 높은 지식을 추출·검증·참조하는 pipeline이어야 한다.
2. 사실·교정·반복 연구 질문을 처음부터 분리하면 각 신호에 맞는 모델과 평가 기준을 적용할 수 있다.
3. 여러 세션에서 반복되고 코드만 읽어서는 알기 힘든 tribal knowledge만 남기고, 일반 조언과 코드에 이미 적힌 내용을 제거해야 컨텍스트 오염을 막을 수 있다.
4. 저장소의 code map과 실제 읽은 파일을 연결하면 “사실을 더 넣어야 한다”와 “에이전트가 기존 architecture 문서를 읽지 않는다”를 구분할 수 있다.
5. 가장 강한 모델로 가능한 품질을 먼저 확인한 뒤 Jev 같은 값싼 분류 모델, enum, 점수 함수, 캐시·replay로 비용을 낮추는 순서가 효율적이다.
6. Prompt를 직접 읽고 입력·출력·중간 pruning을 관찰해야 모델이 만든 상투적인 지침을 팀 고유 지식으로 착각하지 않는다.
7. BAML Query처럼 실행 데이터를 자동으로 저장하고 SQL로 질의하면, 범용 observability dashboard가 제공하지 못하는 repository별 UI를 에이전트가 직접 만들 수 있다.
8. 승인된 memory도 영구 진리가 아니다. 코드 위치, 현재 작업, 사후 correction, memory 없이 실행한 backtest를 조합해 stale 여부를 계속 확인해야 한다.
9. 승인·거부·거부 이유를 네 번째 입력으로 넣으면 동일 후보의 재생성을 막고, 최종 보고서에서 add와 remove를 함께 제안할 수 있다.
10. 최종적으로 메모리 파이프라인은 추출기 하나가 아니라, 관찰 도구·증분 저장소·사람의 검토·장기 평가가 결합된 feedback engine으로 진화해야 한다.