Claude Code·Codex·웹 챗 메모리 하나로 합치기: dhaa 세이브포인트 이식 실험

Claude 앱에서 정리한 요구사항을 Claude Code는 모르고, Claude Code가 배운 교훈을 Codex는 모른다. 도구를 하나만 쓰는 개발자가 드물어진 지금, 계정과 도구를 가로질러 메모리를 하나로 합칠 수 있느냐는 질문이 클코단에서 나왔다. 이 기사는 각 도구의 메모리가 지금 어디에 갇혀 있는지, 세이브포인트를 다른 벤더로 옮기려는 실험 저장소 dhaa가 무엇을 하는지, 오늘 당장 두 도구를 이어 쓰려면 무엇을 설치해야 하는지에 답한다.

각 도구의 메모리는 지금 어디에 갇혀 있나

Claude Code 공식 문서는 메모리를 두 층으로 나눈다. 사용자가 쓰는 CLAUDE.md와, Claude가 스스로 적는 자동 메모리다. 자동 메모리는 저장소별로 ~/.claude/projects 아래 폴더에 쌓이고, 색인 파일 MEMORY.md의 앞 200줄 또는 25KB만 세션 시작 때 읽힌다.

문서는 이 폴더가 기기 로컬이며 다른 기기나 클라우드 환경과 공유되지 않는다고 못 박는다. 저장 위치를 바꾸는 설정은 있지만 동기화 기능은 없다.

Codex도 구조가 비슷하다. OpenAI 개발자 문서에 따르면 Codex는 지시 파일 AGENTS.md와 별도로, 끝난 대화를 배경에서 요약해 ~/.codex/memories 아래에 생성 상태로 저장한다. 요약은 대화가 충분히 쉬어야 시작되는데, 설정 항목의 기본값은 6시간이다. 연달아 작업하는 사람은 요약이 한 번도 돌지 않을 수 있다. 이 파일 역시 기기 하나에 묶여 있고, 손으로 고치는 것은 지원 경로가 아니다.

웹과 앱 쪽 Claude 메모리는 Anthropic 서버에 있다. Claude 고객지원 문서는 다른 AI에서 내보낸 메모리 텍스트를 붙여 넣어 가져오는 방법과, 반대로 Claude 메모리를 텍스트로 내보내는 방법을 안내한다. 다만 가져오기는 실험 단계이고 업무 관련 내용 위주로 남는다고 밝힌다. 한 번 복사하는 것이지, 한쪽을 고치면 다른 쪽이 따라오는 공유 메모리는 아니다.

방에서 나온 요구는 이 네 개의 섬을 하나로 잇자는 것이었다. 앱, 웹, Claude Code, Codex를 오갈 때마다 같은 맥락을 다시 설명하는 일을 줄이고 싶다는 요구다.

장애가 워크플로 장애가 되지 않게 만드는 세이브포인트 이식 실험

방에서 소개된 dhaa 저장소는 이 문제를 메모리 공유보다 장애 대비로 접근한다. 계기는 API 오류였다. 작업 도중 응답이 끊기면 진행 중이던 목표, 태스크 상태, 세션 메모리, CLAUDE.md 같은 지시 파일, 에이전트 역할 정의까지 한꺼번에 멈춘다는 것이 README의 문제 제기다.

장애는 드문 일이 아니다. Anthropic 상태 페이지 기준으로 2026년 8월 24일에는 Claude API와 Claude Code, 여러 모델이 동시에 영향을 받는 대규모 장애가 있었다. 529 overloaded_error는 API가 일시적으로 과부하 상태라는 뜻이다.

dhaa는 Domain, Harness & Agent-Agnostic의 약자다. 핵심 발상은 워크플로와 컨텍스트의 소유권을 하네스에서 떼어내는 것이다. Claude Code나 Codex는 잠시 빌려 쓰는 실행기로 두고, 진짜 상태는 dhaa가 관리하는 Continuity Bundle에 둔다. 번들은 네 조각이다. 규칙과 원칙을 담은 Constitution, 결정과 학습된 제약을 담은 Durable Memory가 앞의 둘이다. 현재 목표와 태스크와 git 상태를 담은 Execution State, 요약과 미해결 질문과 이어갈 지시를 담은 Session Handoff가 나머지다.

어댑터 패턴은 여기서 등장한다. CLAUDE.md를 정본으로 삼지 않고, 상위 Constitution을 Claude 어댑터는 CLAUDE.md로, Codex 어댑터는 AGENTS.md로 투영한다. 방에서 세이브포인트라 부른 것은 README 용어로 체크포인트다. 장애 처리 흐름은 일시 오류 감지, 지터를 섞은 지수 백오프, 재시도 예산 소진, 체크포인트 저장, 다른 공급자로 전환, 상태 복원 후 재개 순서다.

다만 README가 스스로 밝히듯 아직 실험 단계다. 실제로 동작하는 참조 구현은 Claude Code와 MoAI-ADK 조합뿐이고, Codex와 OpenCode는 목표로만 적혀 있다. 설계도에 나오는 .dhaa 디렉터리 구조도 아직 저장소 파일 목록에 없다.

써보려면 Node.js, pnpm, gh CLI, moai 바이너리, Claude Code CLI가 필요하다. 저장소를 클론한 뒤 moai init으로 앱 폴더를 만들고, moai cc로 세션을 띄운다. 그 안에서 /moai plan, run, sync 순서로 SPEC 단위 작업을 돌린다. MoAI-ADK는 modu-ai가 만든 Go 바이너리 하네스로, SPEC 단위 계획·실행·동기화와 품질 게이트를 Claude Code 바깥에서 관리한다.

오늘 당장 두 도구를 이어 쓰는 방법

dhaa가 익기를 기다리지 않아도 부분 통합은 가능하다. 가장 값싼 층은 지시 파일이다.

AGENTS.md는 OpenAI가 2025년 8월에 공개한 형식으로, 같은 해 12월 MCP·goose와 함께 리눅스 재단 산하 Agentic AI Foundation에 기증됐다. OpenAI 집계로 6만 개 넘는 공개 저장소가 이 파일을 두고 있다. 그런데 Claude Code 공식 문서는 CLAUDE.md만 읽고 AGENTS.md는 읽지 않는다고 분명히 적는다. 대신 CLAUDE.md 첫 줄에 @AGENTS.md 한 줄을 적으면 세션 시작 때 그 파일을 펼쳐 넣고, 아래에 Claude 전용 지시를 덧붙일 수 있다. 심볼릭 링크로 두 파일을 하나로 묶는 방법도 문서에 있다. 반대 방향으로는 Codex 설정 파일 config.toml에 project_doc_fallback_filenames 항목을 두면 AGENTS.md가 없는 폴더에서 CLAUDE.md를 읽게 할 수 있다.

v2.1.213 이후 Claude Code에는 /import 명령이 생겨, 다른 코딩 에이전트의 AGENTS.md와 MCP 서버, 명령, 서브에이전트, 스킬을 한 번에 옮겨온다. 단 일회성 복사다.

지시가 아니라 지난 세션에서 무엇을 결정했는지를 공유하려면 MCP 메모리 서버를 활용할 수 있다. 방에서도 MCP로 에이전트별 연결을 추상화하자는 제안이 나왔는데, 이미 그렇게 만든 도구들이 있다. akitaonrails/ai-memory는 Rust로 짠 로컬 서버로, Markdown과 SQLite FTS5에 기록을 쌓는다. 서버를 띄운 뒤 ai-memory install-mcp --client claude-code --apply와 ai-memory install-hooks --agent claude-code --apply 두 명령을 실행한다. 그러면 Claude Code의 프롬프트와 도구 호출이 훅으로 기록되고, 다음 세션은 어디서 멈췄는지 인계받은 채 시작한다. 같은 명령을 각각 --client codex와 --agent codex로 반복하면 Codex도 같은 메모리를 읽고 쓴다. 기존 프로젝트는 bootstrap 명령이 git 로그, README, CLAUDE.md와 AGENTS.md를 긁어 초기 위키를 만든다.

종료 안내가 게시된 mem0의 구형 OpenMemory MCP는 Qdrant 벡터 저장소와 대시보드를 로컬에 띄우고, Claude Desktop·Cursor·Windsurf 같은 MCP 클라이언트가 add_memories와 search_memory로 같은 창고를 쓰게 했다. 다만 기기 간 동기화는 없다.

범용 플랫폼을 만들 것인가, 기간을 정해 실험할 것인가

방의 논쟁은 여기서 갈렸다. 모든 도메인·하네스·에이전트에 무관한 층을 만들겠다는 목표는 사실상 AGI급 문제라는 우려가 있었다. 반대편에선 목표를 줄이라는 대신 기간을 정해 실험하고 무엇이 안 되는지 교훈을 챙기라는 조언이 이어졌다. dhaa README도 P0 과제를 이식 가능한 Constitution·메모리·상태, 하네스 경계, 장애 감지와 전환 세 가지로 좁혀 놓았다.

써본 사람들 사이의 반응도 두 갈래다. 한쪽에서는 각 벤더의 메모리가 제품 잠금장치 노릇을 한다는 불만이 크다. 쌓인 맥락 때문에 도구를 못 바꾸는 상황이 품질 경쟁을 대신한다는 지적이다. 다른 쪽에서는 MCP 메모리 서버가 명시적 호출에 의존해 모델이 검색을 자주 빼먹는다는 경험담이 있다. 기록이 수천 건으로 불어나면 검색 정확도가 떨어져 무효화가 안 되는 캐시처럼 된다는 말도 나온다. 메모리 도구를 파는 쪽이 쓴 글이 많다는 점도 감안해야 한다.

남는 질문은 이렇다. 메모리를 합치는 층을 내가 소유할 것인가, 벤더가 언젠가 열어줄 가져오기 기능을 기다릴 것인가. 전자를 택한다면 dhaa처럼 기간과 범위를 먼저 잘라 두는 편이 낫다. 기록이 쌓일수록 검색이 흐려진다는 경험담이 맞다면, 합친 메모리를 누가 정리할지가 다음 실험의 주제가 된다.