🤖 [연구AX] 토큰이 녹아내려서 만든 AI 메모리 시스템 — 박사논문 집필기

📝 한줄 요약

박사논문 집필 중 매번 원고 전체를 읽히느라 토큰이 녹아내리는 문제를, 오마이오픈코드에서 클로드와 "메모리 레이어"를 설계·구축해서 해결했습니다. 이제 Claude는 지도 한 장만 읽고도 필요한 원고를 정확히 찾아옵니다.

😫 문제: 같은 파일을 또 읽고 있다

박사논문 집필이 중반을 넘어서면서, 앞 챕터의 내용을 지금 쓰는 부분으로 옮기거나, 예전 학회 원고를 재활용해야 하는 일이 잦아졌습니다. Claude(오마이오픈코드)로 기존 원고를 검색하면 정확하고 누락 없이 찾아왔습니다.

문제는 토큰이었습니다. 논점을 이동할 때마다 장별 논증 문서를 통째로 읽어야 하고, 세션이 바뀔 때마다 같은 파일을 또 읽습니다. 20 Max를 구독하는데도 일주일치 리밋에 걸렸습니다. 급기야 Claude가 원고를 읽는 걸 중간에 끊고 직접 뒤져서 찾기도 했습니다.

프로메테우스(플랜 수립 에이전트)에게 고민을 털어놓았습니다.

원고들을 바탕으로 논문에 대한 나의 대화 상대가 되어주면 좋겠어. 근데 원고를 매번 읽히면 토큰이 너무 들고, 안 읽히면 대화 상대로서의 가치가 떨어져. 어떻게 하면 좋을까.

🧭 핵심 아이디어: 전부 기억시키지 말고, 지도를 줘라

Oracle(고품질 상담 에이전트)이 _memory/ 메모리 레이어를 제안했습니다. 정본 문서는 건드리지 않고, 요약과 변화(delta)만 모아둔 얇은 레이어를 별도로 만드는 것. Claude는 세션 시작 시 이것만 읽으면 논문 전체 상태를 파악하고, 실제 원고가 필요할 때만 해당 파일을 읽으러 갑니다. Progressive Disclosure(점진적 노출) — 지도를 먼저 주고, 상세는 필요할 때 로딩하는 방식입니다.

그런데 Oracle의 초기 플랜은 논증 구조를 요약·정리하는 데 치중해 있었습니다. 제가 원하는 건 달랐습니다.

내가 원하는 건, "이 논점 예전에 어디선가 썼는데" 할 때 네가 기존 원고를 뒤져서 어디에 있는지 찾아오는 거야. 그걸 그대로 가져오든, 지금 논증 구조에 맞게 일부만 발췌하든.

논문의 구조를 이해하는 것과, 원고에서 필요한 내용을 찾아서 가져오는 것은 다릅니다. 이 피드백으로 방향이 전환됐습니다 — 메모리 시스템의 핵심은 콘텐츠의 "압축"이 아니라 "지도".

한 단계 더 나아갔습니다. 어떤 원고에 관련 내용이 있다는 걸 안다 해도, 그걸 통째로 읽으면 토큰은 여전히 낭비됩니다. 그래서 장/절/소절 기준 라인 정보까지 포인터로 기록하기로 했습니다. "어떤 파일"이 아니라 "어떤 파일의 몇 번째 줄"까지. 지도의 해상도를 최대한 높인 겁니다.

🗺️ 인덱스와 역인덱스

메모리 레이어 위에 원고 인덱싱 체제를 설계했습니다. Claude가 역인덱스를 제안했는데 구조가 인상적이었습니다:

• 원고별 인덱스 (원고 → 논점): 핵심 원고는 단락 수준까지, 보조 원고는 파일 수준 요약만.

• Quick Map (논점 → 원고): 절 단위로, 어떤 파일의 몇 번째 줄을 읽으면 되는지 역인덱스.

• Keyword Index: 핵심 키워드 20~30개별 관련 원고 매핑.

기존에는 "이 원고에 뭐가 있지?" 순서로 탐색했다면, 이제는 "이 논점은 어디에 있지?" → 해당 파일·해당 줄로 바로 점프. 포맷은 JSON 대신 토큰 효율이 좋은(약 30% 절감) YAML-in-Markdown 하이브리드를 채택했습니다.

🔍 중간 개입이 품질을 결정한다

설계 과정에서 직접 개입이 필요했던 순간들이 있었습니다.

자동 트리거 혼선. 메모리 업데이트를 수동 호출로 결정했는데, 플랜 상세에 자동 트리거처럼 읽히는 표현이 남아 있었습니다. 이런 모호함을 그대로 두면 시지푸스(실행 에이전트)가 서브에이전트에게 태스크를 넘길 때 문제가 생길 수 있습니다. 직접 짚어서 "자동 판단 안 함, 수동 호출만"으로 못 박았습니다.

용어 정의 교정. 메티스(사전 분석 에이전트)가 "아키텍처의 조작적 정의가 필요하다"고 지적하고, 프로메테우스가 정의를 플랜에 반영해뒀는데, 가서 확인해보니 마음에 안 들어서 직접 교정했습니다.

아키텍처란 장별 논증 문서에 구현된 논증의 구조를 말해. 장/절/소절별 주장과 논증 전략, 논점별·단락별 내용, 참조 사료와 연구까지 정리되어 있어. 사실상 논문이란, 이 소스를 글의 형태로 렌더링한 결과야.

이 정의가 이후 작업의 정밀도에 영향을 주었습니다. "논점별·단락별"이라는 구조를 명확히 전달했기 때문에, 이후 인덱스 설계에서 Claude가 논점·단락 단위의 정교한 포인터 체제를 제안할 수 있었습니다. AI에게 내 맥락을 정확히 주는 것 — 이것이 정교한 결과물을 끌어내는 전제조건입니다.

에이전트가 잘 하더라도, 중요한 결정은 직접 확인하고 개입해야 결과물의 품질이 달라집니다.

✅ Before → After

최종 산출물: BRIEF.md(아키텍처 요약), INDEX.md(Quick Map + 키워드 역인덱스 + 원고 인덱싱), LOG.md(미해결 질문), GLOSSARY.md(용어 정의), 부팅/업데이트 스킬 2종.

💡 핵심 교훈

1. AI에게 전체를 기억시키지 말고, 지도를 줘라. 인덱스 + 역인덱스 + Progressive Disclosure. 논문뿐 아니라 책 집필, 문헌 검토, 대규모 문서 관리 등 AI에게 방대한 자료를 다루게 하는 모든 장기 프로젝트에 적용 가능합니다.

2. 에이전트 파이프라인을 적극 활용해라. 오마이오픈코드에서는 시지푸스(실행 에이전트)가 기본적으로 오케스트레이션을 담당하지만, 중요한 과업이면 사용자가 적극적으로 파이프라인을 끌어다 쓸 수 있습니다.

• 플랜 수립 시 프로메테우스를 거쳐 인터뷰로 니즈를 구체화 — 바로 플랜해보라고 하지 않고, 먼저 제가 "뭘 원하는지"를 대화로 정리하는 단계를 거칩니다.

• 설계 상담이 필요하면 Oracle에게 직접 다녀오라고 요청 — 그냥 두면 상담 없이 넘어갈 때가 있어서, 명시적으로 시킵니다.

• 높은 정확도가 필요하면 모무스(검증)에게도 보내보라고 지시 — 플랜에 참조 오류나 모순이 없는지 별도 에이전트가 검증합니다.

• 실행 단계에서 기본 셋팅 대신 시지푸스로 전환해서 ultra work loop — 기본 실행 에이전트보다 강력한 모델이 완료될 때까지 자율 반복 실행합니다.

토큰은 좀 들더라도, 이 파이프라인을 돌렸을 때 실패나 빈틈이 거의 없었습니다.

3. 에이전트의 대화를 지켜보고, 중요한 결정에는 직접 개입하라. 에이전트 오케스트레이션의 시대라고 하지만, 에이전트들이 주고받는 대화를 주의 깊게 살펴보면 도움이 됩니다. 플랜 문서가 태스크/투두까지 포함되어 꽤 길긴 하지만, 적어도 앞부분의 핵심 설계 결정은 꼼꼼히 확인할 필요가 있습니다. 모호한 표현, 기저 니즈 미반영, 용어 정의 부정확 — 이런 건 사람이 직접 잡아야 합니다.

(물론 눈 깜빡할 사이에 이런 개입도 필요 없어지겠죠. 그래도 AI가 일하는 과정을 블랙박스로 두기보다, 대략이라도 워크플로우를 아는 게 저는 좋더라구요. 이런 앎이 AI랑 어떻게 협업할지, 어디까지 같이 해볼지 상상하는 데 도움이 되는 것 같습니다.)

📋 재사용 가능한 프롬프트

메모리 레이어 설계:

나는 [프로젝트 종류]를 진행 중인데, 매 세션마다 [주요 문서들]을 전부 읽히느라 토큰 소모가 큽니다. 세션 간 맥락을 유지하면서 토큰을 절약할 수 있는 메모리 레이어를 설계해주세요. 핵심: 전체를 기억시키는 게 아니라, 어디에 뭐가 있는지 지도를 만들어주세요.

인덱스 + 역인덱스 구축:

[대상 파일 목록]에 대해 인덱스를 구축해주세요. 1) 파일별 인덱스: 각 파일이 어떤 주제를 다루는지 요약 2) 역인덱스: 주제/키워드별로 어떤 파일의 어느 부분을 읽어야 하는지 매핑. Progressive disclosure 방식으로 설계해주세요.