# AKM Index v1.0
## Agentic Knowledge Management Index — 에이전트 지식관리 평가 프레임워크

> **한 줄 요약**
> 개인 또는 조직의 지식관리 시스템이 **AI 에이전트와 함께 굴러가도록 얼마나 잘 설계·운영되고 있는가**를 5개 필러 × 25개 기준, 100점 만점으로 측정하는 범용 평가 척도. 모든 점수는 아티팩트(파일·설정·로그) 증거를 요구한다.

---

## 1. 목적과 적용 범위

### 1.1 무엇을 측정하는가

AKM Index는 "노트를 얼마나 잘 쓰는가"를 측정하지 않는다. **AI 에이전트가 그 지식 기반을 읽고, 쓰고, 유지보수하는 시스템이 얼마나 성숙한가**를 측정한다. 좋은 Zettelkasten이라도 에이전트가 접근할 수 없으면 AKM 점수는 낮고, 노트가 거칠어도 에이전트 파이프라인이 견고하면 점수는 높을 수 있다.

측정 단위는 **시스템**(사람 + 지식 저장소 + 에이전트 런타임 + 운영 루프)이며, 개별 도구나 개별 노트가 아니다.

### 1.2 평가 대상의 최소 요건

다음 세 가지가 존재해야 평가 대상이 된다. 하나라도 없으면 "평가 불가(Pre-Level)"로 기록한다.

1. **지식 저장소** — 파일·노트·문서가 축적되는 지속적 장소 (Obsidian 볼트, 노션, 리포지토리, 위키 등 형식 무관)
2. **에이전트 런타임 1개 이상** — 그 저장소에 접근하는 LLM 에이전트 환경 (Claude Code, Codex, Gemini CLI/Antigravity, Cursor, OpenClaw, Hermes, 자체 구축 등)
3. **반복 사용 의도** — 일회성 실험이 아니라 지속 운영 중일 것 (최근 30일 내 사용 흔적)

### 1.3 설계 원칙

- **행동 앵커(BARS)**: 모든 기준은 "느낌"이 아니라 관찰 가능한 행동·아티팩트로 레벨을 구분한다.
- **증거 필수**: 점수 1점 이상을 주려면 기준마다 최소 1개의 아티팩트 증거(파일 경로, 설정 내용, 로그, 날짜 있는 산출물)를 인용해야 한다. 자기보고("저는 매주 리뷰해요")만으로는 최대 1점.
- **도구 중립**: 특정 제품(Obsidian, Claude 등)을 전제하지 않는다. 앵커의 예시는 예시일 뿐이다.
- **재현 가능**: 다른 평가자가 같은 증거를 보면 ±1레벨 이내로 같은 점수가 나와야 한다.

---

## 2. 프레임워크 구조

### 2.1 5개 필러와 가중치

| 필러 | 이름 | 핵심 질문 | 가중치 |
|---|---|---|---|
| **P** | Prompt Engineering (프롬프트 층위) | 에이전트에게 주는 지시가 자산으로 관리되는가? | 20% |
| **C** | Context Engineering (컨텍스트 층위) | 에이전트가 "맞는 지식"을 "적정 분량"으로 찾을 수 있는가? | 25% |
| **H** | Harness Engineering (하네스 층위) | 런타임 도구·권한·메모리·오케스트레이션이 정비되어 있는가? | 20% |
| **L** | Loop Engineering (루프 층위) | 사람+에이전트의 반복 사이클이 실제로 돌고, 복리로 쌓이는가? | 20% |
| **X** | Interop & Governance (이식성·거버넌스) | 여러 런타임·기기에서 이식되고, 복구·보안이 담보되는가? | 15% |

> **가중치 근거**
> C(컨텍스트)가 25%로 가장 높은 이유: 지식관리 시스템의 존재 이유가 컨텍스트 공급이며, 나머지 필러는 C가 있어야 의미를 갖는다. X가 15%로 가장 낮은 이유: 단일 환경만 쓰는 개인에게도 공정하도록 — 단, X를 0점 처리하면 총점 85점이 상한이 되므로 "멀티 환경은 보너스가 아니라 감점 방어"로 작동한다. 가중치는 v1.0의 기본값이며, 평가 목적에 따라 조정 가능하되 조정 시 리포트에 명시해야 한다.

### 2.2 공통 성숙도 사다리 (모든 기준에 동일 적용)

| 레벨 | 이름 | 일반 정의 |
|---|---|---|
| **0** | 부재 (Absent) | 해당 개념이 존재하지 않거나 인지되지 않음 |
| **1** | 임시 (Ad-hoc) | 존재하지만 문서화되지 않음. 그때그때 손으로 함. 재현 불가 |
| **2** | 문서화 (Documented) | 규칙·구조가 문서로 존재하나, 준수는 사람 의지에 의존. 부분적 적용 |
| **3** | 시스템화 (Systematized) | 도구·자동화·훅이 규칙을 **강제하거나 기본값으로 만듦**. 어기기가 지키기보다 어려움 |
| **4** | 자가개선 (Self-improving) | 시스템 자신이 측정되고, 그 피드백이 규칙·프롬프트·구조 갱신으로 이어진 **기록된 사례**가 있음 |

> **레벨 4의 증거 기준**
> 레벨 4는 "자동화가 많다"가 아니다. **"시스템이 시스템을 고친 흔적"** — 예: 회고 결과로 CLAUDE.md가 수정된 커밋, 에이전트 실패 로그가 훅 추가로 이어진 기록, 분기별 프롬프트 감사 문서 — 가 있어야 한다. 흔적이 없으면 아무리 정교해도 3점이 상한이다.

### 2.3 점수 계산

- 기준별 점수: 0–4
- 기준별 배점: 필러 가중치 ÷ 5 (P·H·L 각 기준 4점 만점 = 4.0%, C 각 기준 = 5.0%, X 각 기준 = 3.0%)
- 기준 환산점수 = (레벨 ÷ 4) × 기준 배점
- **총점 = Σ 기준 환산점수 (0–100)**

| 총점 | 성숙도 밴드 | 특징 |
|---|---|---|
| 0–20 | **M0 수동 (Manual)** | 에이전트를 검색창처럼 씀. 시스템 없음 |
| 21–40 | **M1 도구화 (Tooling)** | 개별 자동화는 있으나 서로 연결 안 됨 |
| 41–60 | **M2 체계화 (Structured)** | 문서화된 스키마 + 에이전트 접근 경로 존재 |
| 61–80 | **M3 오케스트레이션 (Orchestrated)** | 멀티 에이전트·훅·루프가 실제 가동, 강제 장치 있음 |
| 81–100 | **M4 복리형 (Compounding)** | 시스템이 스스로를 측정·개선. 세션마다 기준선 상승 |

---

## 3. 필러 P — Prompt Engineering (20%)

**정의**: 에이전트에게 주는 지시문(시스템 지침, 스킬, 커맨드, 페르소나)이 일회성 채팅이 아니라 **버전 관리되는 자산**으로 설계·운영되는 정도.

### P1. 지시 계층화 (Instruction Layering & Scoping)

핵심 질문: 지시가 전역/프로젝트/폴더 스코프로 나뉘어, 맞는 지시가 맞는 자리에서 로드되는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 매 세션 지시를 채팅에 다시 타이핑 |
| 1 | 재사용 프롬프트 모음(메모장, 스니펫)이 있으나 수동 복붙 |
| 2 | 지시 파일(CLAUDE.md/AGENTS.md/GEMINI.md 등)이 1개 이상 존재하나 단일 거대 파일이거나 스코프 구분 없음 |
| 3 | 전역 ↔ 프로젝트 ↔ 디렉토리 스코프가 분리되고 우선순위가 명확. 도메인별 지시는 스킬/커맨드로 분리되어 필요할 때만 로드 |
| 4 | 지시 계층의 중복·충돌을 점검하는 절차(감사 스킬, 정기 리뷰)가 있고 실행 기록이 있음 |

증거 예시: 지시 파일 목록과 각 파일의 스코프, 스킬 디렉토리 구조, 지시 감사 기록.

### P2. 작업 계약 명세 (Task Contracts)

핵심 질문: 반복 작업의 지시가 입력·출력·저장 위치·포맷·톤을 계약 수준으로 명세하는가?

| 레벨 | 앵커 |
|---|---|
| 0 | "알아서 잘 정리해줘" 수준의 지시만 사용 |
| 1 | 일부 지시에 출력 형식 언급이 있으나 산발적 |
| 2 | 주요 반복 작업에 출력 포맷·저장 경로가 문서화됨 (예: "결과는 X 폴더에 frontmatter 포함 저장") |
| 3 | 스킬/커맨드가 입력 조건, 출력 스키마(frontmatter 필드, 어미·톤, 파일명 규칙), 저장 경로, 실패 처리까지 명세. 템플릿 파일 동봉 |
| 4 | 계약 위반을 검출하는 검증 단계(포맷 린터, 검수 에이전트)가 파이프라인에 내장되고 위반→계약 개정 사례가 있음 |

증거 예시: SKILL.md의 출력 명세 섹션, 템플릿 파일, 포맷 검증 훅.

### P3. 트리거·라우팅 설계 (Trigger & Routing Design)

핵심 질문: 수십 개의 지시 자산 중 맞는 것이 맞는 순간에 자동 선택되도록 트리거가 설계되어 있는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 지시 자산이 1~2개뿐이라 라우팅 개념 자체가 불필요 |
| 1 | 자산은 여럿이나 사용자가 매번 이름을 기억해 직접 호출 |
| 2 | 자산 설명(description)에 용도가 적혀 있으나 트리거 문구·반례 없음. 오발동/미발동 잦음 |
| 3 | 설명이 기계 라우팅용으로 작성됨: 트리거 문구(한/영), "언제 쓰지 말라"(negative trigger), 유사 자산과의 구분(differentiator) 명시 |
| 4 | 라우팅 실패(엉뚱한 스킬 발동, 미발동)가 기록·수집되고 description 개정으로 이어진 사례가 있음 |

증거 예시: 스킬 description의 트리거 문구, "For X use Y instead" 류의 구분 문구.

### P4. 예시·반례 코퍼스 (Exemplars & Counter-examples)

핵심 질문: 지시가 추상 규칙만이 아니라 실제 예시(자기 문체 코퍼스, 좋은/나쁜 출력 예)로 뒷받침되는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 예시 없음 |
| 1 | 채팅에서 즉석으로 "이런 식으로" 예시를 주지만 저장 안 됨 |
| 2 | 대표 예시가 지시 파일에 1~2개 포함 |
| 3 | 스타일 코퍼스(발행 글 모음, 보이스 가이드), 좋은 출력/나쁜 출력 쌍, 엣지케이스 예시가 자산으로 관리되고 지시에서 참조됨 |
| 4 | 새 산출물이 코퍼스에 편입되는 절차가 있고(발행 글이 자동으로 문체 참조에 추가 등), 코퍼스 기반 산출물 품질 비교 기록이 있음 |

증거 예시: 문체 스킬이 참조하는 발행물 코퍼스, few-shot 예시 파일.

### P5. 프롬프트 자산 수명주기 (Prompt Asset Lifecycle)

핵심 질문: 지시 자산이 코드처럼 버전·변경이력·중복제거·폐기 관리되는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 수명주기 없음. 쌓이기만 함 |
| 1 | 오래된 프롬프트가 뒤섞여 있고 어느 것이 현행인지 불명확 |
| 2 | 파일명·날짜로 버전을 구분하나 변경 이유 기록 없음 |
| 3 | git 등 VCS로 이력 관리, CHANGELOG 또는 커밋 메시지로 변경 이유 추적, 단일 정본(SSOT) 원칙과 동기화 절차 존재 |
| 4 | 정기 감사(미사용 자산 폐기, 중복 통합)가 스케줄로 돌고 감사 리포트가 남음 |

증거 예시: 지시 파일 git 이력, CHANGELOG, 시스템 문서 동기화 스킬.

---

## 4. 필러 C — Context Engineering (25%)

**정의**: 에이전트가 필요한 지식을 **찾을 수 있고(검색), 이해할 수 있고(구조), 감당할 수 있는 분량으로(예산)** 공급받도록 지식 기반이 설계된 정도.

### C1. 지식 주소체계 (Taxonomy & Addressability)

핵심 질문: 에이전트가 경로를 "추측"할 수 있을 만큼 분류·명명이 안정적이고 예측 가능한가?

| 레벨 | 앵커 |
|---|---|
| 0 | 폴더 없음 또는 의미 없는 잡동사니 |
| 1 | 폴더는 있으나 명명이 일관되지 않고 같은 주제가 여러 곳에 흩어짐 |
| 2 | 넘버링·명명 규칙이 문서화됨 (Johnny Decimal, PARA, 자체 체계 등). 예외가 자주 발생 |
| 3 | 규칙이 안정적으로 지켜지고, 에이전트 지시 파일에 "무엇이 어디 있는지" 지도가 포함되어 에이전트가 탐색 없이 경로를 특정 가능 |
| 4 | 구조 변경 시 지도·지시 파일이 함께 갱신되는 절차가 있고(동기화 스킬·훅), 구조 위반을 탐지하는 점검이 돎 |

### C2. 기계가독 메타데이터 (Machine-readable Metadata)

핵심 질문: frontmatter·링크·타입이 스키마로 정의되고 실제로 일관 적용되는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 메타데이터 없음 |
| 1 | 태그·속성을 쓰지만 표기가 제각각 (같은 개념에 3가지 태그) |
| 2 | frontmatter 스키마·태그 사전이 문서화됨. 신규 노트엔 적용되나 구작은 방치 |
| 3 | 템플릿·스킬이 스키마를 자동 주입, 노트 타입별 필수 필드 정의, 링크 규칙(위키링크 대상 우선순위) 명시 |
| 4 | 스키마 위반 검출(린터·감사 에이전트)이 주기적으로 돌고, 스키마 자체가 사용 데이터 기반으로 개정된 기록이 있음 |

### C3. 검색 인프라 (Retrieval Infrastructure)

핵심 질문: 에이전트가 렉시컬+시맨틱 검색으로 지식 기반 전체를 조회할 수 있는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 에이전트가 지식 기반을 검색할 방법이 없음 (파일 직접 열기만 가능) |
| 1 | 파일시스템 grep/글롭 수준의 검색만 가능 |
| 2 | 앱 내 검색(Obsidian 검색 등)은 강하지만 에이전트에게 노출 안 됨, 또는 에이전트용 검색이 일부 폴더만 커버 |
| 3 | 렉시컬+시맨틱(벡터) 하이브리드 검색이 MCP/CLI로 에이전트에 노출, 지식 기반의 대부분(80%+)을 커버, 인덱스 자동 갱신 |
| 4 | 검색 품질이 측정되고(실패 쿼리 수집, 리콜 점검) 인덱싱 전략·컬렉션 구성이 그에 따라 개정된 기록이 있음 |

### C4. 점진 공개·컨텍스트 예산 (Progressive Disclosure & Context Budget)

핵심 질문: 에이전트가 "전부"가 아니라 "필요한 만큼"만 읽도록 계층화되어 있는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 에이전트에게 통짜 문서·전체 덤프를 먹임 |
| 1 | 큰 문서를 수동으로 잘라서 제공 |
| 2 | 인덱스/요약 문서가 존재하나 에이전트 워크플로우와 연결 안 됨 |
| 3 | 인덱스 → 코어 요약 → 상세 원문의 계층이 설계되고, 지시·스킬이 이 순서로 읽도록 명시 (예: 사람용 문서와 별개의 LLM용 증류 컨텍스트 유지) |
| 4 | 컨텍스트 소비량·정확도를 근거로 계층이 재설계된 기록 (요약 갱신 주기, 토큰 예산 문서화) |

### C5. 출처·신선도 관리 (Provenance & Freshness)

핵심 질문: 원본과 파생물이 구분되고, 무엇이 최신 정본인지 에이전트가 알 수 있는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 원본·요약·복사본이 뒤섞여 어느 것이 정본인지 사람도 모름 |
| 1 | 사람 머릿속에만 정본 정보가 있음 |
| 2 | 불변 원본층과 파생층의 구분이 문서화됨. 날짜 필드 존재 |
| 3 | 파생물이 원본을 `source:` 등으로 역참조, 다중 사본 충돌 시 우선순위 규칙(어느 쪽이 winner) 명문화, 갱신 일자가 메타데이터로 추적 |
| 4 | 스테일 탐지(오래된 파생물 플래그, 원본 변경 시 파생물 갱신 알림)가 자동화된 기록 |

---

## 5. 필러 H — Harness Engineering (20%)

**정의**: 에이전트 런타임(도구, 권한, 메모리, 오케스트레이션)이 지식 기반과 결합되어 **안전하고 강력하게** 작동하도록 정비된 정도.

### H1. 도구 표면 (Tool Surface)

핵심 질문: 에이전트가 지식 기반을 읽기+쓰기+조작할 수 있는 도구(MCP/CLI/API)가 정비되어 있는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 에이전트와 지식 기반이 분리됨 (복붙으로만 연결) |
| 1 | 파일시스템 접근만 가능 |
| 2 | 범용 도구(파일 접근 + 앱 CLI 일부) 사용, 그러나 지식 기반 특화 조작(속성 수정, 링크 조회)은 불가 |
| 3 | 지식 기반 특화 도구(전용 MCP 서버, 앱 CLI 전체 기능)로 읽기·쓰기·메타데이터 조작·링크 그래프 조회 가능. 갭이 있으면 자체 도구를 만들어 메움 |
| 4 | 도구 사용 통계·실패가 관찰되고 도구 표면이 그에 따라 확장·폐기된 기록 |

### H2. 스킬·자동화 라이브러리 (Skill & Automation Library)

핵심 질문: 반복 워크플로우가 재사용 가능한 스킬·커맨드로 축적되고, 지식 기반에 결과를 되쓰는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 스킬 없음 |
| 1 | 1~5개의 단순 스크립트/커맨드 |
| 2 | 여러 스킬이 있으나 지식 기반과 무관한 범용 유틸 위주, 출력이 아무 데나 저장됨 |
| 3 | 도메인 스킬 라이브러리(10개+)가 지식 기반의 규칙·경로·스키마를 알고 결과를 정위치에 되씀. 스킬을 만드는 메타 스킬 존재 |
| 4 | 스킬 사용 빈도·성공률이 관찰되고 통합·폐기·개정이 이뤄진 기록. 새 워크플로우 발생 시 스킬화가 기본 반사 |

### H3. 권한·가드레일 (Guardrails & Permissions)

핵심 질문: 에이전트의 파괴적 행동이 훅·권한·샌드박스로 방어되는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 전권 허용(YOLO 모드 상시) + 백업 없음 |
| 1 | 매 작업 수동 승인에만 의존 (피로로 인한 무지성 승인 상태) |
| 2 | allow/deny 목록이 설정됨. 위험 작업 목록이 문서화됨 |
| 3 | 수명주기 훅(파괴적 명령 차단, 보호 경로, 포맷 강제)이 실제 설정되어 규칙을 코드로 강제. 공격 표면 문서화 |
| 4 | 사고·니어미스가 기록되고 가드레일 갱신으로 이어진 사례. 정기 보안 점검 스케줄 |

### H4. 지속 메모리·상태 (Persistent Memory & State)

핵심 질문: 세션이 끝나도 학습·맥락이 남고, 다음 세션이 그 위에서 시작하는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 매 세션 백지 시작 |
| 1 | 사용자가 매번 이전 맥락을 수동 요약해 붙임 |
| 2 | 메모리 파일이 존재하나 구조 없이 잡다하게 쌓임 (스테일 메모리 방치) |
| 3 | 구조화된 메모리(인덱스 + 항목별 파일, 타입 구분), 세션 핸드오프 절차, 잘못된 메모리 수정·삭제 규칙 존재 |
| 4 | 메모리 히트율·스테일 항목이 점검되고 정리가 주기적으로 실행된 기록 |

### H5. 오케스트레이션·관측성 (Orchestration & Observability)

핵심 질문: 서브에이전트·백그라운드 작업·스케줄이 활용되고, 무슨 일이 있었는지 추적 가능한가?

| 레벨 | 앵커 |
|---|---|
| 0 | 단일 채팅 스레드만 사용 |
| 1 | 가끔 병렬 채팅 창을 띄우는 수준 |
| 2 | 서브에이전트/백그라운드 실행을 쓰지만 임의적, 로그 확인 안 함 |
| 3 | 역할 분화된 에이전트 정의(리서처·리뷰어 등), 워크플로우/파이프라인 구성, 스케줄 실행, 세션 로그·산출물 추적 경로 존재 |
| 4 | 오케스트레이션 비용·성과가 기록·비교되고 구성이 개정된 사례 (예: 특정 파이프라인 폐기·교체 기록) |

---

## 6. 필러 L — Loop Engineering (20%)

**정의**: 캡처→처리→발전→발행→회고의 사이클이 사람+에이전트 분업으로 **실제로 반복**되며, 산출물이 다시 시스템을 강화하는(복리) 정도.

> **이 필러만은 "설계"보다 "가동 증거"를 본다**
> L 필러의 레벨 3 이상은 반드시 **최근 30일 내 날짜가 찍힌 반복 아티팩트**(데일리 노트, 위클리 리뷰, 처리 로그)를 요구한다. 아름다운 파이프라인 문서가 있어도 최근 가동 흔적이 없으면 2점이 상한.

### L1. 파이프라인 정의 (Defined Pipeline)

핵심 질문: 지식이 들어와서 나가는 단계가 명시되고, 단계마다 담당(사람/에이전트)이 정해져 있는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 들어오기만 하고 나가는 경로 없음 |
| 1 | 암묵적 흐름은 있으나 문서화 없음 |
| 2 | 단계(수집→정리→발행 등)가 문서로 정의됨 |
| 3 | 단계별 폴더·상태 필드가 구조에 반영되고, 단계 전환을 수행하는 스킬·커맨드가 존재하며, 사람/에이전트 역할 분담이 명시됨 |
| 4 | 단계별 체류 시간·전환율이 측정되고 병목 개선이 이뤄진 기록 |

### L2. 주기 리뷰 (Cadenced Reviews)

핵심 질문: 일간·주간·월간 회고가 실제로 반복되고 에이전트가 보조하는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 회고 없음 |
| 1 | 불규칙하게 가끔 함 |
| 2 | 템플릿·주기가 정의되어 있으나 최근 30일 실행률 50% 미만 |
| 3 | 최근 30일 실행률 50% 이상 + 에이전트가 회고 초안·집계를 생성 (아티팩트로 확인) |
| 4 | 회고 결과가 시스템 변경(규칙·스킬·구조 개정)으로 이어진 추적 가능한 사례 다수 |

### L3. 적체·흐름 관리 (Backlog & Flow Control)

핵심 질문: 인박스가 통제되는가 — 캡처 대비 처리 비율을 알고 관리하는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 인박스 개념 없음, 전부 뒤섞임 |
| 1 | 인박스는 있으나 무한 적체, 규모 파악 안 됨 |
| 2 | 적체 규모를 인지하고 간헐적 정리. 처리 기준(무엇을 남기고 버릴지) 문서화 |
| 3 | 트리아지 자동화(에이전트 분류·라우팅)가 있고, 적체량이 주기 리뷰에서 추적됨 |
| 4 | 캡처:처리 비율이 측정·관리되고, 유입 자체를 조절한(캡처 규칙 개정) 기록 |

### L4. 복리 환류 (Compounding Write-back)

핵심 질문: 에이전트 세션의 산출물이 1급 지식으로 편입되어 다음 세션의 기준선을 높이는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 에이전트 대화가 휘발됨 |
| 1 | 좋은 결과를 가끔 수동 복사해 저장 |
| 2 | 에이전트 출력 전용 저장 위치가 있으나 산출물이 덤프로 쌓일 뿐 재참조 구조 없음 |
| 3 | 산출물이 타입별 정식 노트로 편입되는 스킬·절차가 있고(질의 결과→위키 문서화 등), 이후 세션이 실제로 이를 검색·재사용 |
| 4 | 환류율(세션 산출물 중 편입 비율)이나 재사용 빈도가 관찰되고, 환류 파이프라인이 개정된 기록 |

### L5. 자기교정 루프 (Self-correction Loop)

핵심 질문: 실패·피드백이 지시·구조·가드레일 갱신으로 이어지는 닫힌 회로가 있는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 같은 실수를 에이전트가 반복해도 방치 |
| 1 | 그때그때 채팅으로 교정하나 세션이 끝나면 증발 |
| 2 | 교정 사항을 지시 파일·메모리에 기록하는 습관이 있음 (비정기) |
| 3 | 피드백→메모리/지시 갱신이 절차화되고(교정 시 즉시 기록 규칙), 시스템 자체에 대한 감사(결정 감사, 성숙도 평가)가 실행된 적 있음 |
| 4 | 감사→백로그→실행→재감사의 사이클이 2회 이상 돈 기록 (권고사항 이행률 추적 포함) |

---

## 7. 필러 X — Interop & Governance (15%)

**정의**: 시스템이 특정 런타임·기기에 종속되지 않고 이식되며, 유실·유출로부터 방어되고, 타인에게 전수 가능한 정도.

### X1. 런타임 이식성 (Cross-runtime Portability)

핵심 질문: 하나의 컨텍스트 정본이 여러 에이전트 런타임(Claude Code, Codex, Gemini, Cursor, OpenClaw 등)에서 재사용되는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 단일 런타임 종속, 이식 개념 없음 |
| 1 | 런타임마다 지시를 따로 작성해 내용이 갈라짐(drift) |
| 2 | AGENTS.md 등 공용 표준 파일이 존재하나 일부 런타임은 미연결(빈 파일, 미참조) |
| 3 | 공용 정본 + 런타임별 어댑터(심링크, 참조, 변환 스크립트) 구조로 주요 런타임 전부가 같은 컨텍스트를 봄. 런타임별 기능 차이가 문서화됨 |
| 4 | 새 런타임 추가 시의 온보딩 절차가 문서화·검증되었고, 런타임 간 드리프트 점검이 주기적으로 돎 |

### X2. 기기·에이전트 토폴로지 (Device & Agent Topology)

핵심 질문: 여러 기기·에이전트의 역할과 산출물 경로가 정의되고 동기화 충돌이 관리되는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 단일 기기이거나, 다중 기기인데 동일 파일을 무질서하게 수정 |
| 1 | 다중 기기 사용하나 역할 구분·충돌 대책 없음 (동기화 충돌 잦음) |
| 2 | 기기·에이전트별 역할이 문서화됨. 산출물 경로가 에이전트별로 구분됨 |
| 3 | 역할·경로 분리가 구조로 강제되고(에이전트별 전용 출력 폴더), 동기화 방식과 충돌 이력·대응책이 문서화됨 |
| 4 | 토폴로지 변화(기기 추가·제거)가 절차대로 반영된 기록, 충돌 재발 방지책의 효과 검증 |

### X3. 복구 가능성 (Recoverability)

핵심 질문: 지식과 설정이 버전 관리·백업되고, 복구가 실제로 가능한가?

| 레벨 | 앵커 |
|---|---|
| 0 | 백업 없음 |
| 1 | 클라우드 동기화(Dropbox 등)를 백업으로 착각하는 상태 (삭제·오염이 그대로 전파) |
| 2 | 핵심 자산 일부만 git/백업 커버. 커버리지가 문서화되지 않음 |
| 3 | 지식 기반·에이전트 설정·스킬이 모두 VCS 또는 스냅샷 백업으로 커버되고 커버리지 목록이 문서화됨 |
| 4 | 복구 리허설(실제 restore 테스트) 기록이 있고 백업 갭 발견→해소 이력 존재 |

### X4. 보안·프라이버시 (Security & Privacy)

핵심 질문: 시크릿·PII가 지식 기반과 공개 산출물에서 통제되는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 비밀번호·키가 노트에 평문 산재, 인지 없음 |
| 1 | 위험을 인지하나 목록화·조치 없음 |
| 2 | 공격 표면·민감정보 위치가 문서화됨(인벤토리 존재). 일부 미조치 항목 잔존 |
| 3 | 시크릿 관리 도구 사용, 공개 배포물 PII 스트리핑 절차, 에이전트의 민감 경로 접근 제한이 실제 설정됨 |
| 4 | 정기 보안 감사가 스케줄로 돌고 발견→조치 완료율이 추적됨 |

### X5. 전수·표준화 (Shareability & Standardization)

핵심 질문: 시스템이 본인 머릿속이 아니라 문서·킷으로 존재해서 타인이 채택할 수 있는가?

| 레벨 | 앵커 |
|---|---|
| 0 | 시스템이 암묵지로만 존재 |
| 1 | 남에게 설명은 가능하나 문서 없음 |
| 2 | 시스템 문서는 있으나 자기 환경 전제가 강해 타인 적용 불가 |
| 3 | 스타터 킷·공개 문서·템플릿으로 배포되고 버전·릴리스 관리됨. 실제 외부 채택 또는 강의·컨설팅 활용 사례 존재 |
| 4 | 채택자 피드백이 킷 개정으로 이어진 기록, 커뮤니티/수강생의 개선 기여 수용 사례 |

---

## 8. 채점 프로토콜 (평가 절차)

### 8.1 증거 수집 (Evidence Collection) — 60~90분

평가 대상에게서 다음을 수집하거나 직접 열람한다. 원격 평가 시 스크린샷·파일 사본으로 대체 가능.

**필수 아티팩트 체크리스트**

| # | 아티팩트 | 관련 기준 |
|---|---|---|
| 1 | 에이전트 지시 파일 전부 (CLAUDE.md/AGENTS.md/GEMINI.md/.cursorrules 등) + 스코프 배치 | P1, P2, X1 |
| 2 | 스킬·커맨드·훅 디렉토리 목록 + 대표 3개 본문 | P2, P3, H2, H3 |
| 3 | 지식 저장소 최상위 구조 + 분류 규칙 문서 | C1 |
| 4 | 노트 타입별 템플릿·frontmatter 스키마 | C2 |
| 5 | 검색 도구 설정 + 인덱스 상태 (문서 수, 최종 갱신일) | C3 |
| 6 | 최근 30일 내 데일리/위클리 리뷰 실물 3개 | L2 |
| 7 | 인박스 규모 (파일 수) + 전체 대비 비율 | L3 |
| 8 | 에이전트 산출물 저장 위치 + 환류(정식 편입) 사례 2개 | L4 |
| 9 | 메모리 파일·설정 파일 (permissions, hooks, MCP 목록) | H1, H3, H4 |
| 10 | 사용 중인 런타임 목록 + 각 런타임의 컨텍스트 연결 상태 | X1, X2 |
| 11 | git/백업 커버리지 (뭐가 되고 뭐가 안 되는지) | X3 |
| 12 | 보안 인벤토리·시크릿 처리 방식 | X4 |
| 13 | 공개 배포물(스타터킷, 문서 사이트) 유무 | X5 |
| 14 | "시스템이 시스템을 고친" 사례 — 감사·회고→개정 기록 | 모든 레벨 4 판정 |

### 8.2 채점 규칙

1. **기준별 독립 채점**: 후광 효과 방지를 위해 필러 순서를 섞어 채점해도 된다.
2. **증거 없으면 상한 1점**: 자기보고만 있는 기준은 최대 1점.
3. **최근성 규칙**: L 필러는 30일, 나머지는 90일 내 사용·갱신 흔적이 없으면 "존재하나 사장됨"으로 1레벨 감점.
4. **보수적 판정**: 두 레벨 사이에서 애매하면 낮은 쪽. 레벨 4는 "개선의 기록"이 없으면 절대 부여하지 않는다.
5. **N/A 처리**: 정당한 N/A(예: 1인 단일기기 사용자의 X2)는 해당 기준을 제외하고 필러 배점을 잔여 기준에 재분배한다. N/A 남발 방지를 위해 시스템 전체에서 최대 3개까지만 허용.

### 8.3 산출물

- 기준별: 레벨(0–4) + 증거 인용 1줄 + 감점 사유 1줄
- 필러별 소계와 총점, 성숙도 밴드
- 상위 강점 3개 / 최우선 개선 3개 (예상 점수 상승폭 포함)
- (멀티 환경 사용자) 런타임별 현재 상태·방향 매트릭스

### 8.4 안티게이밍 주의사항

- **문서만 만들면 3점?** 아니다. 레벨 3은 "도구가 강제/기본값화"가 조건 — 문서만으로는 2점.
- **평가 직전 벼락치기**: 아티팩트 날짜를 확인한다. 평가 7일 전 일괄 생성된 리뷰·로그는 L 필러 증거로 인정하지 않는다.
- **도구 수집가**: MCP 서버 20개 설치는 H1의 증거가 아니다. 지식 기반과 결합되어 "사용된" 흔적이 증거다.
- **평가자 이해충돌**: 자기 시스템을 자기가 평가할 때는 반드시 감점 사유를 기준마다 1개 이상 기록하게 한다 (강제 결점 탐색).

---

## 9. 부속 평가 — 런타임 매트릭스 (점수 외 프로파일)

멀티 런타임 사용자는 총점과 별개로 아래 매트릭스를 작성한다. X1 채점의 근거 자료이자 로드맵 도출용이다.

| 런타임 | 컨텍스트 연결 | 스킬/자동화 | 역할 | 가동 상태 | 방향 |
|---|---|---|---|---|---|
| (예: Claude Code) | 정본 직결 / 어댑터 / 별도 사본 / 미연결 | 있음(n개) / 없음 | 주력 / 특화 / 실험 / 휴면 | 일상 / 간헐 / 중단 | 유지 / 확대 / 통합 / 폐기 |

---

## 10. 버전·라이선스

- **v1.0.0** (2026-07-16): 최초 공개. 5필러 × 25기준. 기준 케이스: CMDS(구요한) 시스템 실측 평가와 함께 발행.
- 개정 원칙: 기준 추가·삭제는 마이너 버전, 앵커 문구 수정은 패치. 실측 사례 5건 누적 시 가중치 재검토.
- 활용: 자유 사용·개작 가능. 평가 리포트에 "AKM Index v1.0 기반" 표기 권장.