박논 관련 원고가 쌓이면서, AI에게 기존 원고를 찾아달라고 할 때마다 같은 파일을 처음부터 다시 읽히는 일이 반복됐다. 세션이 바뀔 때마다 맥락이 초기화되니, 읽기 비용이 과도하게 들었다.
이 글은 Claude(Opus)와 ‘메모리 레이어’를 설계해 이 문제를 해결한 과정이다. 이 과정에서 확인한 것: 콘텐츠를 압축해서 주기보다, 그에 대한 정밀한 지도를 주는 게 유용하다는 것, 그리고 에이전트 파이프라인이 복잡해질수록 사람의 개입이 결과의 질을 가른다는 것.
딜레마: 읽히면 토큰이 녹고, 안 읽히면 쓸모가 없다
박사 논문 집필이 중반을 넘어서면서, 앞 챕터의 논점을 지금 쓰는 부분으로 옮기거나 예전 학회 원고를 재활용해야 하는 일이 잦아졌다. Claude로 기존 원고를 검색하면 정확하고 누락 없이 찾아왔고, 그러한 협업이 만족스러웠다·
다만, 문제가 있었다. 원고를 충분히 읽히지 않으면, Claude는 고맥락적 대화 상대가 되지 못한다. grep 수준으로 훑어서는 논증의 흐름을 이해하지 못하고, 정확한 내용을 가져오지도 못한다. 그런데 고맥락을 유지하려고 원고를 제대로 읽히면 토큰이 과도하게 든다. 20 Max를 구독하는데도 일주일치 한도에 걸렸다. 급기야 Claude가 원고를 읽는 걸 중간에 끊고 직접 뒤져서 찾기도 했다.
세션이 바뀌면 이 비용이 반복적으로 발생한다. Claude는 이전 세션에서 읽은 원고를 기억하지 못하니, 오늘도 어제와 같은 파일을 처음부터 다시 읽는다.
전부 기억시키는 대신, 지도를 만들기로 했다
프로메테우스(플랜 수립 에이전트)에게 고민을 말했다.
너가 내 원고들을 읽고, 논문과 관련해서 나의 대화 상대가 되어주면 좋겠어. 근데 너에게 원고를 매번 읽히면 토큰이 너무 들고, 안 읽히면 대화 상대로서의 너의 가치가 떨어져. 어떻게 하면 좋을까.
Oracle(고품질 상담 에이전트)이 _memory/ 메모리 레이어를 제안했다. 정본 문서는 건드리지 않고, 요약과 변화(delta)만 모아둔 얇은 레이어를 별도로 만드는 것이다. Claude는 세션 시작 시 이것만 읽으면 논문 전체 상태를 파악하고, 실제 원고가 필요할 때만 해당 파일을 읽으러 간다.
Progressive Disclosure — 지도를 먼저 주고, 상세는 필요할 때 로딩하는 방식이다.
방향 전환 — “압축이 아니라 지도”
그런데 Oracle의 초기 플랜은 논증 구조를 요약·정리하는 데 치중해 있었다. 내가 원하는 건 달랐다.
내가 원하는 건, “이 논점 예전에 어디선가 썼는데” 할 때 네가 기존 원고를 뒤져서 어디에 있는지 찾아오는 거야. 그걸 그대로 가져오든, 지금 논증 구조에 맞게 일부만 발췌하든.
논문의 구조를 이해하는 것과, 원고에서 필요한 내용을 찾아서 가져오는 것은 다르다. 이 피드백으로 방향이 전환됐다 — 메모리 시스템의 핵심은 **콘텐츠의 “압축”이 아니라 “지도”**다.
해상도를 높이다 — 라인 수준 포인터
한 단계 더 나아갔다. 어떤 원고에 관련 내용이 있다는 걸 안다 해도, 그 원고를 매번 통째로 읽으면 토큰은 여전히 낭비된다. 그래서 장/절/소절 기준 라인 정보까지 포인터로 기록하기로 했다. “어떤 파일”이 아니라 **“어떤 파일의 몇 번째 줄”**까지. 지도의 해상도를 최대한 높인 것이다.
인덱스와 역인덱스
포인터 개념을 바탕으로 원고 인덱싱/역인덱싱 체제를 설계했다:
- 원고별 인덱스 (원고 → 논점): 핵심 원고는 단락 수준까지, 보조 원고는 파일 수준 요약만.
- Quick Map (논점 → 원고): 절 단위로, 어떤 파일의 몇 번째 줄을 읽으면 되는지 역인덱스.
- Keyword Index: 핵심 키워드 20~30개별 관련 원고 매핑.
특정 원고를 바탕으로 대화할 때는 “이 원고에 뭐가 있지?” 방식으로 탐색하도록 하고, 특정 논점/키워드을 여러 원고로부터 찾아오게 할 때는 “이 논점은 어디에 있지?” → 해당 파일·해당 줄로 점프하는 식으로 탐색하게 한다.
포맷은 오라클 추천대로 JSON 대신 YAML-in-Markdown 하이브리드를 채택했다.
결과
Claude가 파일을 읽는 방식이 달라졌다.
| 항목 | BEFORE | AFTER |
|---|---|---|
| 세션 시작 | 원고 전체 읽기 (수천 줄) | BRIEF 330줄만 읽기 |
| 원고 검색 | 관련 원고 전부 읽기 | 역인덱스로 해당 줄만 로딩 |
| 세션 간 맥락 | 매번 소실 | LOG + GLOSSARY로 유지 |
| 토큰 사용 | 동일 파일 반복 읽기 | 포인터 기반 on-demand |
최종 산출물: BRIEF.md(아키텍처 요약), INDEX.md(Quick Map + 키워드 역인덱스 + 원고 인덱싱), LOG.md(미해결 질문), GLOSSARY.md(용어 정의), 부팅/업데이트 스킬 2종.
협업 관찰
이 작업은 설계부터 구축까지 에이전트 파이프라인을 적극 활용한 사례다. 오마이오픈코드에서는 시지푸스(실행 에이전트)가 오케스트레이션을 담당하지만, 중요한 과업이면 사용자가 직접 파이프라인을 끌어다 쓸 수 있다.
이번에 활용한 흐름:
- 플랜 수립 시 프로메테우스를 거쳐 인터뷰로 니즈를 구체화했다. 바로 플랜하라고 하지 않고, “내가 뭘 원하는지”를 대화로 먼저 정리했다.
- 설계 상담이 필요한 시점에서 Oracle에게 직접 다녀오라고 요청했다. 명시적으로 시키지 않으면 상담 없이 넘어갈 때가 있다.
- 높은 정확도가 필요해 모무스(검증 에이전트)에게 플랜의 참조 오류나 모순을 검증하게 했다.
- 실행 단계에서는 시지푸스(Opus)로 전환해 ultra work loop를 돌렸다. 이 루프는 ‘될 때까지 일한다’라는 자율 반복 실행 루프로 알려져 있는데, 구체적으로 ulw 프롬프트를 살펴보니 긴 호흡의 작업을 할 때 AI가 자율적으로 판단해서 중간에 플랜에서 벗어나는 일이 없도록 관리하는 데에 초점이 맞추어져 있음을 발견했다. 그래서 중요한 일을 할 때나, 플랜에 태스크/투두가 잔뜩 있을 때, 나는 ulw를 켠다.
토큰은 좀 들더라도, 이 파이프라인을 돌렸을 때 실패나 빈틈이 거의 없었다.
그런데 에이전트에게 키를 넘긴 구간에서도, 사람이 직접 개입해야 하는 순간들이 있었다.
자동 트리거 혼선. 메모리 업데이트를 수동 호출로 결정했는데, 플랜 상세에 자동 트리거처럼 읽히는 표현이 남아 있었다. 이런 모호함을 그대로 두면 시지푸스가 서브에이전트에게 태스크를 넘겼을 때 그 친구가 맥락 파악을 못하고 에러를 낼 수 있다. 직접 짚어서 “자동 판단 안 함, 수동 호출만”으로 못 박았다.
용어 정의 교정. 메티스(사전 분석 에이전트)가 “아키텍처의 조작적 정의가 필요하다”고 지적하고, 프로메테우스가 정의를 플랜에 반영해뒀는데, 확인해보니 마음에 안 들어서 직접 교정했다.
아키텍처란 장별 논증 문서에 구현된 논증의 구조를 말해. 장/절/소절별 주장과 논증 전략, 논점별·단락별 내용, 참조 사료와 연구까지 정리되어 있어. 사실상 논문이란, 이 소스를 글의 형태로 렌더링한 결과야.
이 정의가 이후 작업의 정밀도에 영향을 주었다. “논점별·단락별”이라는 구조를 명확히 전달했기 때문에, 이후 인덱스 설계에서 Claude가 논점·단락 단위의 정교한 포인터 체제를 제안할 수 있었다.
배움 포인트
AI에게 전체를 기억시키지 말고, 지도를 줘라. 인덱스 + 역인덱스 + Progressive Disclosure. 이 구조는 논문뿐 아니라, AI에게 방대한 자료를 다루게 하는 모든 장기 프로젝트에 적용 가능하다. 중요한 건 콘텐츠를 압축하는 게 아니라, 어디에 뭐가 있는지 정밀하게 가리키는 것이다. 지도의 해상도가 높을수록 불필요한 읽기가 줄어든다.
에이전트 파이프라인을 오케스트레이터에게만 맡기지 말고, 적극적으로 활용하라. 언제 어떤 에이전트를 부를지 직접 판단하는 것만으로도 결과가 달라진다. 이번 작업에서는 플랜 수립, 설계 상담, 검증, 실행을 각각 다른 에이전트에게 맡겼고, 그 조합이 효과적이었다.
중요한 작업이라면, 에이전트들의 대화를 지켜보고 필요할 때 개입하라. 오마이오픈코드에서는 에이전트들이 주고받는 대화를 살펴볼 수 있다. 모호한 표현, 빠진 맥락, 부정확한 정의 같은 것은 사람이 직접 잡아야 한다. 이 개입이 결과물의 정밀도를 결정한다.