KimYx0207/Meta_Kim

Meta_Kim은 단순한 또 다른 AI 코딩 도구가 아닙니다. 이는 AI 코딩 어시스턴트(AI coding assistants)에게 두뇌를 부여하는 거버넌스 시스템(governance system)입니다.

Claude Code, Codex, OpenClaw, 그리고 Cursor는 모두 '손'에 해당합니다. 즉, 코드를 작성하고 파일을 변경할 수 있습니다. 하지만 어떤 파일을 먼저 변경할지 결정하는 것은 누구인가요? 결과를 검토하는 것은 누구인가요? 발생하는 문제들을 수정하는 것은 누구인가요? 그리고 동일한 실수가 다음에 반복되지 않도록 어떻게 보장할 수 있을까요?

Meta_Kim은 바로 그 목적을 위해 구축되었습니다. 이것은 **AI 위의 AI (AI above AI)**입니다. 복잡한 작업이 혼란으로 변하지 않도록 유지하는 통합 거버넌스 계층(unified governance layer)입니다.

먼저 무엇이 일어나야 하는지 명확히 하고 -> 그다음 누가 그것을 수행해야 할지 결정하고 -> 실행 후 검토하며 -> 학습된 내용을 보존하고 -> 이를 다음 실행에 다시 반영합니다.

이것은 새로운 개념이 아닙니다. 성숙한 엔지니어링 팀들은 이미 이렇게 하고 있습니다. Meta_Kim은 인간의 규율에만 의존하는 대신, 이를 실행 가능한 시스템으로 전환합니다.

빠르게 실행해보고 싶다면 다음을 실행하세요:

npx --yes github:KimYx0207/Meta_Kim meta-kim

또는 전통적인 방식으로 설치하세요:

git clone https://github.com/KimYx0207/Meta_Kim.git
cd Meta_Kim
npm install
...

💡

설치 후: setup.mjs는

모든 아티팩트(artifact)가 어디에 있는지 출력합니다. 언제든지 해당 요약을 다시 확인하거나(또는 이전 설치와 비교하려면), 설치한 디렉토리에서 npm run meta:status를 실행하세요.

저장소(repository)를 유지 관리할 계획이라면, 먼저 정식 소스(canonical sources)를 편집하세요: canonical/agents/, canonical/skills/meta-theory/, config/contracts/, 그리고 config/capability-index/.

그 다음 실행하세요 (Node.js >= 22.13.0 필요):

npm run meta:sync
npm run meta:validate

권장 읽기 순서:

• 이 파일,
  README.md

AGENTS.md

docs/runtime-capability-matrix.md

글로벌 설치(node setup.mjs 또는 npx) 후, 어디에서 무엇이 작동하는지:

현재 위치	자동으로 작동하는 것	명시적 트리거가 필요한 것
Claude Code가 포함된 Meta_Kim 리포지토리	CLAUDE.md를 통한 완전한 거버넌스 (8단계 스파인 (spine), 게이트 (gates), 디스패치 규칙 (dispatch rules))	—
Claude Code가 포함된 기타 모든 프로젝트	훅 (Hooks) (안전성 (safety), 포맷 (format), 메모리 저장 (memory save)) + /meta-theory 기술	"run meta theory"라고 말하거나 /meta-theory 입력
Codex	AGENTS.md 규칙 + 9개의 커스텀 에이전트 (agents) + /meta-theory 명령	"run meta theory" 또는 /meta-theory 입력
OpenClaw	워크스페이스 에이전트 (Workspace agents) + 플러그인 SDK 훅 (Plugin SDK hooks) (28개 이벤트)	auth.json 설정 필요
Cursor	에이전트 프로젝션 (Agent projections) + 기술 미러 (skill mirrors) + 훅 (hooks) + MCP	가벼움; 주로 읽기 + 검토

GitHub KimYx0207 |
X @KimYx0207 |
Website aiking.dev |
WeChat 공식 계정: Lao Jin Guides You Through AI

Feishu 지식 베이스: 장기 업데이트

Meta_Kim이 유용했다면, 커피 한 잔으로 프로젝트를 후원해 주세요.

WeChat Pay	Alipay

Meta_Kim의 방법론적 토대는 이 프로젝트의 유지 관리자(KimYx0207)가 작성한 메타 기반 의도 증폭 (meta-based intent amplification) 연구에서 비롯되었습니다:

• 논문: https://zenodo.org/records/18957649
• DOI: 10.5281/zenodo.18957649

아키텍처: 숨겨진 골격 + 동적 처리 (Hidden Skeleton + Dynamic Dealing)

이것이 Meta_Kim의 핵심 설계 아이디어입니다. 만약 단 하나의 섹션만 읽어야 한다면, 바로 이 섹션을 읽으십시오.

개념 (Concept)	정의 (What it is)	정의가 아닌 것 (What it is not)
Hidden skeleton (숨겨진 골격)	가시적인 워크플로우(workflow) 아래에 항상 존재하는 백엔드 프레임워크	사전에 작성된 고정된 책임 목록
8-stage workflow (8단계 워크플로우)	Hidden skeleton에 의해 노출되는, 사람이 읽을 수 있는 실행 중추	전체 거버넌스 로직
11-phase business workflow (11단계 비즈니스 워크플로우)	분류 후 8단계 위에 계층화된 실행-패키징 진행 과정	8단계를 대체하는 것
Dealing (딜링)	8단계 워크플로우와 에이전트 단위(agent units)를 중심으로 구축된 동적 제어	단순한 작업 할당
Gate (게이트)	통과/실패 조건	단계(stage) 그 자체
Contract (컨트랙트)	노드가 반드시 생성해야 하는 구조화된 출력물	슬로건이나 추상적인 값
Agent-unit governance (에이전트 단위 거버넌스)	경계, 역량, 업그레이드 및 롤백(rollback)을 관리하는 실질적인 방법	역할 메뉴
Three-layer memory (3계층 메모리)	memory / graphify / SQL로 분할된 장기 메모리	하나의 혼합된 노트북

단 한 문장만 기억해야 한다면:

8단계 워크플로우는 실행을 진행시키고, 게이트(gate)는 단계 통과 여부를 결정하며, 컨트랙트(contract)는 요구되는 출력을 정의하고, 딜링(dealing)은 동적인 개입을 추가합니다.

8 stages = the hidden skeleton (8단계 = 숨겨진 골격)

Meta_Kim에는 8개의 고정된 실행 단계가 있습니다. 이것이 바로 **hidden skeleton (숨겨진 골격)**입니다:

flowchart LR
C[Critical<br/>요청 명확화] --> F[Fetch<br/>역량 검색]
F --> T[Thinking<br/>접근 방식 계획]
...

Critical - 먼저 진짜 문제를 확정하십시오

요청이 모호할 때는 추측하는 대신 명확하게 하는 질문을 던지십시오. 이 단계는 실제 사용자의 의도, 성공 기준 및 제외 사항을 확정하는 intentPacket을 생성합니다. 만약 요청이 이미 명확하다면, 시스템은 조용히 건너뛰는 대신 명시적인 스킵 사유를 기록합니다.

Fetch - 새로운 것을 만들어내기 전에 기존 역량을 먼저 검색하십시오

기존의 에이전트(Agents), 기술(Skills), 도구(Tools), 또는 MCP 통합(Integrations)이 이미 해당 요구사항을 충족하는지 검색하십시오. 여기서 핵심 아이디어는 **역량 우선 (capability-first)**입니다. 즉, 역량을 먼저 정의한 다음, 해당 역량을 선언하는 소유자(Owner)를 검색하고, 가장 적합한 대상에게 작업을 할당(Dispatch)하는 것입니다. 역량 인덱스(Capability-index) 조회는 config/capability-index/ -> 런타임 미러(runtime mirror) -> 로컬 인벤토리(local inventory) -> 폴백(fallback) 순으로 진행됩니다. 특정 에이전트의 이름을 하드코딩하는 것으로 시작하지 마십시오.

Thinking - 경계, 소유자, 순서, 산출물, 리스크 및 중단 조건 정의

작업을 하위 작업(Subtasks)으로 나누고, 소유자를 할당하며, 의존성(Dependencies)과 병렬 그룹(Parallel groups)을 명시적으로 만듭니다. 이 단계에서는 dispatchBoard가 생성됩니다.

: 누가 무엇을 하는지, 무엇이 병렬로 실행될 수 있는지, 그리고 결과물을 병합(Merging)할 책임은 누구에게 있는지를 나타냅니다. 최소 두 가지 이상의 해결 경로(Solution paths)를 탐색해야 하며, 너무 일찍 단일 경로로 고정하지 마십시오.

Execution - 거버넌스(Governance) 하에 실제 작업 수행

하위 작업을 전문 에이전트(Specialist agents)에게 할당합니다. 각 하위 작업은 파일 컨텍스트(File context), 제약 사항(Constraints), 리뷰 소유자(Review owner), 검증 소유자(Verification owner)를 포함하는 workerTaskPacket에 담겨 전달됩니다. 독립적인 하위 작업은 가능한 경우 병렬로 실행되어야 합니다. 실행(Execution)이 곧 완료(Completion)는 아닙 - 출력물은 여전히 리뷰와 검증을 통과해야 합니다.

Review - 품질 및 경계 준수 여부 확인

코드 품질, 보안, 아키텍처 준수 여부 및 경계 위반 사항을 검사합니다. 발견 사항(Findings)을 포함한 구조화된 reviewPacket을 생성합니다. 각 발견 사항은 CRITICAL(심각)부터 LOW(낮음)까지의 심각도(Severity)를 가집니다. 이는 형식적인 절차가 아닙니다 - 해결되지 않은 발견 사항은 다음 단계로 넘어갈 수 없습니다.

Meta-Review - 리뷰 표준 자체가 편향되었거나 너무 느슨한지 검사

리뷰를 리뷰합니다. 만약 리뷰 표준이 너무 약하다면, 시스템은 실제로 리뷰를 하고 있는 것이 아닙니다. 만약 편향되어 있다면, 잘못된 것을 리뷰하고 있는 것입니다. 이 단계는 리뷰 시스템 자체의 품질을 보호합니다.

Verification - 실제 결과가 주장과 일치하는지 확인

수정 사항이 리뷰에서 발견된 문제점들을 실제로 해결했는지 확인합니다. 이 단계에서는 verificationResult와 closeFindings가 생성됩니다.

만약 수정 사항이 실제로 발견된 문제점을 해결하지 못했다면, 다시 돌아가서 재검증하기 전에 이를 수리해야 합니다. 이것은 시스템 내에서 가장 정직한 관문(gate)입니다.

Evolution (진화) - 역량 격차와 재사용 가능한 패턴을 시스템에 다시 기록하기

경험을 구조적 업그레이드로 전환합니다: 재사용 가능한 패턴은 메모리(memory)로 들어가고, 실패는 학습 산출물(learning artifacts)이 되며, 역량 격차(capability gaps)는 Scout에게 전달되고, 에이전트 경계(agent boundaries)는 정전(canonical) 소스에 다시 기록됩니다. 모든 실행은 반드시 writebackDecision으로 끝나야 합니다.

: 구체적인 무언가를 다시 기록하거나, 영구적으로 보존할 것이 없는 이유를 명시적으로 설명해야 합니다. 학습을 보존하지 못하는 실행은 낭비된 작업입니다.

8단계가 모여 실행의 중추(execution spine)를 형성합니다.

왜 이 단계들이

계약 산출물 (Contract artifact)	단계 (Stage)	목적 (Purpose)
intentPacket	핵심 (Critical)	실제 의도 (intent)를 고정하고 드리프트 (drift) 방지
dispatchBoard	사고 (Thinking)	소유자, 의존성 및 병렬 그룹 정의
workerTaskPacket	실행 (Execution)	각 하위 작업 (subtask)을 위한 전체 컨텍스트 (context) 전달
reviewPacket	검토 (Review)	구조화된 결과 (findings) 기록
revisionResponse	수정 (Revision)	각 검토 결과 (review finding)에 대해 응답
verificationResult	검증 (Verification)	이슈가 실제로 종료되었는지 확인
summaryPacket	요약 (Summary)	공개 배포 전 최종 요약
evolutionWriteback	진화 (Evolution)	다시 기록 (write back)되어야 할 내용 정의

flowchart LR
subgraph packets["계약 산출물 흐름 (Contract artifact flow)"]
direction LR
...

이 산출물들은 선택적인 문서가 아닙니다. 이것들은 시스템의 신뢰할 수 있는 단일 원천 (source of truth)입니다. 계약 (contracts)이 없다면, 다음 노드는 작업을 "인계 (handing off)"하는 것이 아니라, 이전 노드가 무엇을 의미했는지 추측하게 됩니다. 이것이 복잡한 작업에서 많은 AI 협업이 무너지는 이유입니다.

현재 구현체는 이러한 산출물들을 명시적으로 포함하고 있습니다: 실행 전 taskClassification, 처리 전 cardPlanPacket, 배포 전 dispatchEnvelopePacket, 검토 후 reviewPacket.findings, 수정과 검증 사이의 revisionResponses + verificationResults + closeFindings, 외부 게시 전 summaryPacket, 그리고 진화 전 writebackDecision.

npm run meta:validate:run은 이러한 산출물 체인이 완전히 닫히는지(close) 확인합니다.

계약 (Contracts)은 각 노드가 무엇을 전달해야 하는지를 정의합니다. 게이트 (Gates)는 그 전달물이 앞으로 나아가기에 충분히 좋은지를 정의합니다.

한 문장으로 요약하자면:

단계 (stage)는 당신이 어디에 있는지를 알려주고, 게이트 (gate)는 당신이 다음으로 넘어갈 수 있는지를 알려줍니다.

flowchart LR
A["단계 도달 (Reach a stage)"] --> B{"게이트 결정 (Gate decision)"}
B -->|통과 (Pass)| C["릴리스: 앞으로 이동 (Release: move forward)"]
...

시스템의 주요 게이트 (Key gates):

게이트 (Gate)	차단 항목 (What it blocks)	통과 조건 (Pass condition)
planning gate (계획 게이트)	계획 단계에서 실행 단계로의 이동	경계(Boundaries), 소유자(Owners), 산출물(Deliverables) 및 리스크(Risks)가 정의됨
metaReview gate (메타 리뷰 게이트)	메타 리뷰(meta-review)가 충분히 강력한지 여부	리뷰 표준 자체가 편향되거나, 누락되거나, 너무 느슨하지 않음
verify gate (검증 게이트)	수정 사항이 실제로 이슈를 해결했는지 여부	finding (발견) -> revision (수정) -> verification (검증) 과정이 깔끔하게 종료됨
summary gate (요약 게이트)	결과를 게시할 수 있는지 여부	검증(Verification) 통과 + 요약(Summary) 완료
publicDisplay gate (공개 표시 게이트)	시스템이 "완료"를 주장할 수 있는지 여부	verifyPassed (검증 통과) + summaryClosed (요약 종료) + singleDeliverableMaintained (단일 산출물 유지) + deliverableChainClosed (산출물 체인 종료)

가장 중요한 것은 **publicDisplay gate (공개 표시 게이트)**입니다. 만약 검증(Verification)이 통과되지 않았거나, 요약(Summary)이 종료되지 않았거나, 산출물 체인(Deliverable chain)이 끊어져 있다면, 시스템은 작업이 완료된 것처럼 가장할 수 없습니다.

게이트(Gates)와 계약(Contracts)의 관계:

• **계약 (Contracts)**은 "이 노드가 무엇을 전달해야 하는가"에 답합니다. 즉, 인도 의무(Delivery obligations)에 관한 것입니다.
• **게이트 (Gates)**는 "다음 단계로 넘어가기에 충분히 좋은가"에 답합니다. 즉, 릴리스 결정(Release decisions)에 관한 것입니다.
• 계약이 없다면 게이트는 판단할 근거가 없습니다.
• 게이트가 없다면 계약은 단순한 형식(Ceremony)에 불과합니다.

8단계 골격(8-stage skeleton)은 비교적 고정되어 있지만, 실제 작업은 하나의 경직된 경로로 처리하기에는 변동성이 너무 큽니다. 이것이 바로 Meta_Kim이 **동적 처리 (Dynamic dealing)**를 도입한 이유입니다.

처리(Dealing)는 8단계에 대응하지만, 단순한 1:1 매핑은 아닙니다. 10개의 카드는 다음과 같습니다: