Claude Code에서 정리한 작업 규칙을 Codex에도 다시 설명해야 할까? Hermes가 기억한 사용자 선호를 Aside는 어디에서 찾아야 할까? 에이전트를 바꾸는 순간 이런 질문이 생깁니다. 모델과 도구는 달라져도 사용자와 프로젝트는 그대로인데 지식은 각 제품의 메모리 안에서 따로 자라기 쉽기 때문입니다.
제 작업 환경에는 Hermes, Claude Code, Codex, Aside라는 네 개의 에이전트 런타임이 있습니다. 각 제품에 같은 지식을 복사하면 당장은 편해 보이지만 한쪽만 수정되는 순간 어느 사본이 최신인지 확인해야 합니다. 그래서 공통 지식과 운영 규칙은 AKM(Agent Knowledge Management) 한 곳에 뒀습니다. 각 런타임에는 그 정본을 읽는 얇은 어댑터만 남겼습니다.
이 구조를 한 문장으로 줄이면 “one body, pointers everywhere else”, 즉 본체는 하나만 두고 나머지는 모두 포인터로 연결한다입니다.
에이전트보다 먼저, 지식이 돌아갈 자리를 정했습니다
AKM은 순수 Markdown으로 구성한 지식 운영체계입니다. 데이터베이스도 아니고 도구를 직접 호출하는 실행 엔진도 아닙니다. 원본, 재사용 지식, 사용자·프로젝트 맥락, 세션 시작 포인터, 반복 절차, 실행 기록, 실패 패턴을 서로 다른 레이어에 저장합니다. 그리고 새 지식을 어디에 둘지, 세션을 시작할 때 무엇을 먼저 읽을지, 실패를 어느 레이어의 수정으로 되돌릴지를 공통 규칙으로 정합니다.
제가 운영하는 구조에서 AKM의 역할은 공통 지식·운영 컨트롤 플레인(control plane)입니다. 실제 모델 호출과 파일 수정, 도구 실행, 권한 적용은 Hermes·Claude Code·Codex·Aside 각각의 네이티브 런타임(native runtime)이 담당합니다.
구분
담당하는 일
AKM 공통 컨트롤 플레인
지식의 정본, 저장 위치 분류, 세션 시작 포인터, 공통 절차, 실패 기록과 Learn Back 규칙
제품별 네이티브 런타임
모델 선택, 도구 호출, 파일·네트워크 접근, 권한, 세션 실행, 제품 고유 기능
얇은 어댑터
런타임이 AKM 정본을 어디서 읽고 어떻게 저장·환류할지 알려 주는 진입점
이 경계를 분명히 해야 합니다. AKM이 네 제품을 대신 실행하는 것이 아닙니다. 네 제품이 각자의 실행 능력을 유지한 채 같은 지식 운영 규칙을 참조하는 구조입니다.
공통 정본은 무엇을 담고 있나
AKM은 지식을 일곱 레이어로 나눕니다.
Source: 수정하지 않을 원본
Knowledge: 여러 작업에서 다시 쓸 수 있는 지식
Context: 특정 사용자·프로젝트에만 해당하는 맥락
Operational Memory: 매 세션 먼저 읽을 짧은 포인터
Procedural: 반복 실행 절차와 검증법
Action: 재현·검증·인수인계에 필요한 실행 기록
Evaluation: 실패 패턴과 품질 기준
실제 시작점은 더 작습니다. 네 런타임은 공통 99-system 인덱스와 고정된 네 개의 40-memory 시작 포인터를 먼저 봅니다. 40-memory에는 긴 본문을 넣지 않습니다. “사용자 선호의 본체는 어디에 있다”, “이 작업의 안전 규칙은 무엇을 참조한다”처럼 세션 초기에 필요한 짧은 길잡이만 둡니다.
지식이 새로 생기면 공통 라우터가 저장 위치를 정합니다. 반복 가능한 절차는 절차 레이어로, 사용자에게만 해당하는 선호는 맥락 레이어로, 반복될 수 있는 실패는 평가 레이어로 보냅니다. 실행 중 문제가 드러나면 기록만 남기고 끝내지 않습니다. Ingest → Classify → Compile → Contextualize → Execute → Verify → Learn Back 루프를 따라 원인이 있는 규칙이나 레이어까지 고칩니다.
어댑터는 네 가지 질문만 확실히 답합니다
각 런타임의 어댑터는 공통 규칙을 복사하지 않습니다. 다음 네 가지에만 답합니다.
AKM 정본의 루트는 어디인가?
세션 시작 때 어떤 인덱스와 포인터를 읽는가?
저장 전 분류 규칙은 어디에 있는가?
실패하거나 같은 실수를 반복할 때 Learn Back은 어떻게 시작하는가?
규칙 본문은 AKM에 있습니다. 제품별 진입 파일에는 이 규칙을 읽으라는 짧은 안내만 있습니다. 공통 규칙이 바뀌어도 네 사본을 각각 고칠 필요가 없는 이유입니다.
네 런타임은 같은 AKM을 서로 다르게 사용합니다
공통 정본을 쓴다고 해서 제품 차이까지 없애지는 않습니다. 오히려 제품 고유 기능과 공통 지식의 경계를 명확히 나눕니다.
Hermes: 여러 프로필을 쓰되 지식 본체는 하나로
Hermes는 여러 프로필과 네이티브 메모리, 사용자 정보 저장소, 스킬을 운영할 수 있습니다. 하지만 다른 런타임도 알아야 할 사용자 맥락과 절차의 본체는 AKM에 둡니다. Hermes의 네이티브 메모리에는 세션에 꼭 필요한 짧은 포인터만 남깁니다. 도구 고유 스킬과 프로필 정체성·설정은 Hermes 안에 유지합니다.
여러 프로필이 있다고 AKM을 프로필별로 복제하지도 않습니다. 프로필마다 필요한 맥락은 AKM의 프로젝트 맥락으로 구분합니다. 공통 시작 포인터는 함께 읽습니다.
Claude Code: 자동 메모리는 포인터, 공유 절차는 AKM
Claude Code는 CLAUDE.md를 진입점으로 씁니다. 자동 메모리에는 세션이나 프로젝트에만 필요한 휘발성 포인터를 둡니다. 다른 런타임도 알아야 할 지식과 규칙은 AKM에 저장합니다. Claude Code 스킬도 공통 절차의 본문을 복사하기보다 해당 AKM 절차를 읽고 실행하는 트리거 역할을 맡습니다.
Codex: 장기 기억이 필요하면 AKM으로 라우팅
Codex는 AGENTS.md에서 어댑터를 읽습니다. 이 운영안에서는 Codex에 네이티브 장기 메모리가 없다고 봅니다. 세션을 넘어 기억해야 할 내용은 모두 공통 라우터를 거쳐 AKM에 저장합니다. Codex를 하위 작업 에이전트로 호출해 진입 파일을 읽지 못하는 환경에서는 호출자가 AKM 위치와 라우팅 규칙을 작업 지시에 명시해야 합니다.
Aside: 실제 설치 지점에도 본문 대신 포인터만
Aside에는 AGENTS.md의 상시 어댑터 규칙, 세션 시작용 MEMORY.md, 사용자 포인터용 USER.md, 검색을 돕는 에이전트·프로젝트 포인터 페이지가 실제 진입점으로 기록되어 있습니다. 이 파일들은 AKM 본문을 대량 복사하지 않습니다. Aside에 필요한 짧은 의미 포인터만 유지합니다. 공통 지식·맥락·절차·실패 기록의 본체는 AKM에 남깁니다.
“연결했다”에서 끝내지 않고 블라인드 테스트를 해봤습니다
어댑터 문서를 만들어 두는 것과 런타임이 실제로 규칙을 따르는 것은 다릅니다. 그래서 2026년 6월 12일, 사전 지식을 차단한 에이전트에 Claude Code 어댑터 스니펫만 주고 세 가지 작업을 시켰습니다.
반복 실수를 어디에서 조회해야 하는지 찾기
사용자 선호를 올바른 위치에 저장하기
반복 절차를 검증 가능한 형식으로 저장하기
세 작업은 모두 통과했습니다. 반복 실수는 평가 레이어의 본체와 세션 시작 포인터로 연결했습니다. 사용자 선호는 사용자 맥락의 본체와 짧은 메모리 포인터로 나눴습니다. 반복 절차는 승격 조건을 확인한 뒤 절차 레이어에 저장했습니다. 새 노트에 맞춰 인덱스와 변경 로그를 갱신했으며 메타데이터 규칙도 지켰습니다.
더 중요한 결과는 “통과” 다음에 나왔습니다. 테스트 과정에서 다섯 가지 모호성이 드러났습니다.
시작 포인터 파일을 누적형으로 쓸지 개별 파일로 쓸지 불명확함
메모리 노트에 맞는 역할 메타데이터 규칙이 없음
사용자 맥락 파일의 이름 규칙이 없음
변경 로그 기록 의무가 어댑터 진입점에 드러나지 않음
절차 안의 팁과 별도 재사용 지식을 나누는 기준이 모호함
이 다섯 항목은 같은 날 스키마, 라우터, 어댑터 규칙 수정에 반영했습니다. 테스트 결과를 보고서로만 남기지 않고 원인 레이어를 고친 첫 Learn Back 사례였습니다.
네 런타임의 공통 정본 참조도 다시 확인했습니다
2026년 7월 19일 독립 재평가에서는 실제 사용하는 네 런타임인 Claude Code, Codex, Hermes, Aside가 모두 같은 99-system 규칙과 40-memory 포인터 정본을 참조하는지 점검했습니다. 네 런타임 모두 “one body, pointers everywhere else” 패턴으로 연결되어 있음을 확인했습니다. Aside는 문서상 설계만 있는 것이 아니라, 앞서 설명한 네이티브 진입점에 어댑터와 포인터가 설치된 상태도 기록되어 있었습니다.
다만 여기서 증거의 범위를 넘겨 말하면 안 됩니다. 네 런타임이 같은 정본을 참조한다는 사실은 확인했지만 동일한 블라인드 테스트를 네 런타임 모두에서 반복한 것은 아닙니다. 현재 직접 통과가 기록된 블라인드 테스트는 Claude Code 어댑터입니다. 연결 확인은 곧 전 런타임의 지속적인 규칙 준수 증명이 아닙니다.
직접 적용하려면 이 순서로 확인해보세요
아래 체크리스트는 특정 제품에 종속되지 않습니다. 파일을 읽을 수 있고 시작 지시를 둘 수 있는 에이전트라면 같은 방식으로 시험할 수 있습니다.
1. 정본을 하나로 정합니다
공통 지식, 사용자·프로젝트 맥락, 반복 절차, 실패 패턴을 둘 저장소를 하나 정합니다.
제품별 메모리에는 공통 본문을 복사하지 않는다고 먼저 선언합니다.
세션 시작용 메모리는 짧은 포인터 표면으로 제한합니다.
2. 어댑터의 네 칸을 채웁니다
정본의 위치
시작 때 읽을 인덱스와 포인터
저장 전 분류 규칙
실패 후 Learn Back 규칙
한 칸이라도 비어 있으면 아직 어댑터가 아닙니다.
3. 제품 고유 기능과 공통 지식을 분리합니다
모델, 도구, 권한, 세션 설정, 제품 고유 스킬은 네이티브 런타임에 둡니다.
여러 런타임이 함께 알아야 할 지식과 절차는 공통 정본에 둡니다.
네이티브 메모리에는 “무엇을 기억할지”보다 “어디를 읽을지”를 남깁니다.
4. 새 세션에서 세 가지를 블라인드 테스트합니다
다음과 같이 요청해보세요.
“내가 반복하는 실수는 어디에서 찾아야 하나요?”
“이 사용자 선호를 다음 세션에도 기억하도록 저장해 주세요.”
“이 반복 절차를 실패 지점과 검증법까지 포함해 저장해 주세요.”
정답 문장만 보지 말고 실제 저장 위치, 인덱스 갱신, 변경 로그, 메타데이터를 확인해야 합니다.
5. 실패를 평가 기록에서 끝내지 않습니다
실패 원인이 분류 규칙이면 라우터를, 메타데이터가 모호하면 스키마를, 시작 지시가 약하면 어댑터를 수정합니다. Learn Back이 원인 레이어의 변화로 닫혀야 다음 런타임도 같은 개선을 얻습니다.
6. 드리프트 점검을 일정에 넣습니다
네이티브 메모리에 본문 사본이 생기지 않았는가?
시작 파일이 여전히 같은 정본을 가리키는가?
이름이 바뀐 포인터나 끊어진 링크가 없는가?
새 런타임도 같은 블라인드 테스트를 통과하는가?
이 점검은 설치 직후 한 번으로 끝낼 일이 아닙니다.
마무리: 최고의 에이전트보다 먼저 정할 것
에이전트를 여러 개 쓰기 시작하면 “어느 모델이 더 좋은가”만큼 중요한 질문이 생깁니다.
이 에이전트들이 같은 사용자와 프로젝트를 어떤 정본으로 이해할 것인가?
저는 네 런타임의 기억을 합치는 거대한 통합 메모리 대신, 공통 지식의 본체를 하나로 유지하고 각 제품에는 그 본체로 들어가는 얇은 진입점만 두었습니다. 제품은 각자의 모델·도구·권한을 그대로 씁니다. 공유해야 할 지식과 절차는 한 곳에서 수정할 수 있습니다.
에이전트가 바뀔 때마다 지식이 끊긴다면, 새 모델을 고르기 전에 먼저 사본의 수를 세어볼 만합니다. 본체가 여러 개라면 연결보다 정본부터 정해야 합니다.
One body, pointers everywhere else.
