README는 프로토콜이었다. 엔트리포인트(Entrypoint)는 여전히 선택 사항이었다.

용어 사전: 이 글에서 사용된 용어 🔸 MICA (Memory Invocation & Context Archive): AI 컨텍스트 관리를 위한 거버넌스 스키마 (Governance Schema). 컨텍스트가 세션 전반에 걸쳐 어떻게 구조화되고, 신뢰되며, 점수가 매겨지고, 전달되어야 하는지를 정의합니다. 🔸 인보케이션 계층 구조 (Invocation Hierarchy): MICA가 실제 라이브 세션에 도달하는 방식을 결정하는 운영 사다리 — 자연적 (natural), 유도된 (guided), 강제된 (forced) — 입니다. 🔸 활성화 패킷 (Activation Packet): 읽기 대상, 로드 상태, 자체 테스트 태세, 드리프트 (drift) 상태 및 게이트 결과를 선언하는 컴파일된 세션 시작 객체입니다. 🔸 세션 보고서 (Session Report): 무엇이 로드되었는지, 자체 테스트에서 무엇이 발견되었는지, 그리고 세션 게이트가 열려 있는지 여부를 선언하는 구조화된 시작 출력물입니다. 🔸 README-as-Protocol: 모델이 README를 먼저 읽으려는 자연스러운 경향을 선언된 인보케이션 메커니즘으로 공식화한 패턴입니다. v0.1.8에서 도입되었습니다.

1. 파트 6이 끝난 지점
   파트 6에서는 단일 유지보수 에이전트 내부의 MICA가 어떻게 보이는지 — 세션 보고서, 드리프트 탐지, 설계 불변량 (design invariants), 편차 로그 — 를 보여주었습니다. 구조는 유지되었습니다. 프로토콜은 실행되었습니다. 파트 6은 더 어려운 질문과 함께 끝났습니다: 누적된 세션 지식이 다음 세션을 제어해야 할 때 — 그 자체로 AI 워크플로 내에서 실행되는 도구 내부에서 — 어떤 일이 벌어질까요? 그 답은 이전 질문에 달려 있습니다: 다음 세션이 실제로 누적된 내용을 로드할까요? 그것은 스키마 (schema)의 문제가 아닙니다. 그것은 엔트리포인트 (entrypoint)의 문제입니다.

2. README-as-Protocol이 남겨둔 간극
   파트 4는 특정한 가정을 했습니다: 많은 리포지토리 기반 AI 워크플로에서 README는 이미 모델의 첫 번째 오리엔테이션 표면입니다. 그 관찰이 README-as-Protocol이 되었습니다. 새로운 설치 메커니즘을 발명하는 대신, MICA는 기존의 동작을 공식화했습니다: 모델이 README를 읽고, README가 아카이브를 가리키며, 작업이 시작되기 전에 세션이 컨텍스트를 로드하고, 체크를 실행하며, 준비 상태를 보고할 것으로 기대하는 것입니다. 그 가정은 유용했습니다. 그것은 플러그인, 서비스 또는 커스텀 호스트 인프라를 요구하지 않고도 MICA가 세션으로 진입할 수 있는 경로를 제공했습니다. 하지만 프로토콜은 엔트리포인트가 아닙니다.

README는 아카이브(archive)의 위치, 중요한 불변량(invariants), 세션 보고서(session report)에 포함되어야 할 내용 등을 선언할 수 있습니다. 하지만 이 중 어느 것도 순서(sequencing)를 보장하지는 않습니다. 모델은 여전히 README를 훑어보고 바로 코드로 뛰어들거나, 자신의 로드 상태(load state)를 선언하기 전에 작업을 시작할 수 있습니다. 결과(consequence)가 따르지 않는 게이트(gate)는 여전히 단순한 에티켓(etiquette)에 불과합니다. 이것이 이번 버전이 메워야 했던 간극입니다.

3. 해답: 호출 계층 구조 (An Invocation Hierarchy)
   MICA는 마법처럼 자동으로 호출되지 않습니다. 인간, 호스트(host), 래퍼(wrapper), 또는 런처(launcher)가 메모리 계약(memory contract)을 호출하지 않는다면, 아카이브는 아무것도 제어하지 못한 채 존재할 뿐입니다. 이는 Part 2에서 확인했던 것과 동일한 진실입니다. 즉, 구조는 존재할 수 있지만, 모델은 그것이 존재한다는 것을 알 수 있는 신뢰할 수 있는 방법을 여전히 갖지 못할 수 있다는 점입니다. 해답은 명시적인 계층 구조에 있습니다.

• 자연적 (Natural) — 모델이 프로젝트 표면(README, mica.yaml, archive JSON, playbook)을 자발적으로 읽습니다. 별도의 개입이 필요하지 않습니다.
• 유도된 (Guided) — 호스트 에이전트(host agent)가 작업 시작 전에 활성화 패킷(activation packet)을 요청합니다. 이 패킷은 읽기 대상(read targets), 자체 테스트 태세(self-test posture), 드리프트 상태(drift state), 그리고 게이트 결과(gate outcome)를 선언합니다. 호스트는 이를 사용하여 세션을 사전 점검(preflight)합니다.
• 강제된 (Forced) — 런처가 세션 보고서가 통과될 때까지 리포지토리(repository) 작업을 차단합니다. 이것은 가장 강력한 경로이자 가장 우아하지 않은 경로입니다. 하지만 동시에 소음이 많은 실제 터미널 워크플로(terminal workflows)에서도 살아남는 방식이기도 합니다.

4. 코드에서 변경된 사항
   세 가지 구체적인 조치가 이를 실행 가능하게 만들었습니다. 세션 보고서(Session report)가 실제 런타임 출력(runtime output)이 되었습니다.

parser.add_argument("--format", choices = ["text", "json", "hook", "session-report"], default = "text")

이제 시작 보고서는 프로토콜에 대한 기대나 산문 형태의 설명이 아닌, 컴파일된 객체(compiled object)입니다. 호스트는 이를 직접 소비할 수 있습니다. 호출(Invocation)은 이제 설명되는 것이 아니라 컴파일됩니다.

mica_invoke.py는 읽기 대상(read targets)과 세션 보고서(session report)를 하나의 활성화 패킷(activation packet)으로 컴파일합니다:

packet = { "mode": mode, "entry_strategy": mode, "read_targets": _layer_targets(project_root), "session_report": report, }

이것이 문서 우선 시작(documentation-first startup)에서 패킷 우선 시작(packet-first startup)으로의 전환입니다.

호스트는 더 이상 산문(prose)으로부터 시퀀스(sequence)를 추론할 필요가 없습니다. 가이드 모드(guided mode)에서 출력은 이미 호스트가 소비할 수 있는 형태로 구성되어 있습니다: { "mode" : "guided" , "entry_strategy" : "guided" , "read_targets" : [ { "name" : "readme" , "..." : "..." }, { "name" : "mica_yaml" , "..." : "..." }, { "name" : "archive" , "..." : "..." }, { "name" : "playbook" , "..." : "..." }, { "name" : "lessons" , "..." : "..." } ], "session_report" : { "archive_version" : "1.7.8" , "self_test" : { "pct" : "CLOSED" , "closed_contract" : true }, "drift_status" : { "status" : "NO_DRIFT" }, "gate" : "PASS" }, "directive" : "Host agent should load declared MICA surfaces first and use the session report as opening state." } 강제 모드(forced mode)는 이제 결과(consequence)를 수반합니다. if args . mode == " forced " and packet [ " session_report " ]. get ( " gate " ) == " BLOCKED " : sys . exit ( 1 ) 가장 단순한 엔트리 서피스(entry surface): @echo off python " %~dp0 tools\mica_invoke.py" % * 해당 래퍼(wrapper)는 MICA가 선의에 의존하는 대신, 강제할 수 있는 터미널 엔트리포인트(terminal entrypoint)를 갖게 해줍니다. 5. STEM-BIO-AI: 더 깨끗한 사례 STEM-BIO-AI는 이미 성숙한 MICA 메모리 계층(memory layer) — 아카이브(archive), 플레이북(playbook), 레슨(lessons), 호출 프로토콜(invocation protocol), 드리프트 프로필(drift profile)을 갖추고 있었습니다. 변한 것은 메모리 모델이 아니었습니다. 변한 것은 그 모델이 작업이 시작되기 전에 어떻게 작동(operative)하게 되는가였습니다. 그 차이는 세 가지 호출 모드(invocation modes) 모두에서 명확히 드러납니다. 내추럴 모드(natural mode)에서 헬퍼(helper)는 README 우선 경로를 유지하며 예상되는 읽기 순서를 명시적으로 만듭니다: [MICA INVOKE] mode=natural Gate : PASS State : INVOCATION_MODE PCT : CLOSED ... Directive: Prefer reading README first, then load mica.yaml, archive, and playbook before scan work.

가이드 모드(guided mode)에서는 동일한 시작 과정이 호스트가 소비할 수 있는 패킷이 됩니다: { "mode" : "guided" , "read_targets" : [ "readme" , "mica_yaml" , "archive" , "playbook" , "lessons" ], "session_report" : { "archive_version" : "1.7.8" , "self_test" : { "pct" : "CLOSED" , "closed_contract" : true }, "drift_status" : { "status" : "NO_DRIFT" }, "gate" : "PASS" } } 강제 모드(forced mode)에서 런처(launcher)는 게이트(gate)로서 동일한 계약(contract)을 사용합니다: [MICA INVOKE] mode=forced Gate : PASS State : INVOCATION_MODE PCT : CLOSED ... 지침(Directive): 세션 보고서(session report)의 게이트가 BLOCKED 상태가 아닐 때까지 작업을 차단합니다. 이제 세션 보고서는 다음과 같은 형태를 띱니다: [SESSION READY] Archive: 1.7.8 Load: {"state": "INVOCATION_MODE", "mica_yaml": "memory\mica.yaml"} Self-test: {"pct": "CLOSED", "closed_contract": true} Drift: {"status": "NO_DRIFT"} Active invariants: {"critical_count": 15, "high_count": 3} Gate: PASS 이전에는 패키지가 운영자에게 올바르게 시작하는 방법을 알려주었습니다. 이제는 세션이 실제로 올바르게 수행되었는지를 선언합니다. 이 버전 이전에는 STEM-BIO-AI 세션을 올바르게 시작하는 것이 여전히 운영자가 적절한 메모리 표면(memory surfaces)을 올바른 순서로 로드하는 것을 기억하는지에 달려 있었습니다. 이제 그 의존성은 상위 단계로 이동할 수 있습니다: 가이드 모드에서는 호스트로, 강제 모드에서는 런처로 이동합니다.

6. CCGE: 더 어려운 사례
   CCGE는 더 어렵기 때문에 정확히 더 중요합니다. 이는 이미 거버넌스(governance) 비중이 높은 런타임(runtime)입니다. 만약 MICA의 정체성이 약했다면, 더 큰 프레임워크 속으로 사라져 버렸을 것입니다. 여기서 CCGE는 Care Chain Governance Engine을 의미합니다: 자체 실행 코어(execution core), 아티팩트 생성(artifact generation), 정책 계층(policy layers) 및 승인 로직(approval logic)을 갖춘, 페일 클로즈(fail-closed) 방식의 임상 거버넌스 런타임입니다. 이것이 바로 CCGE가 더 어려운 사례인 이유입니다. MICA는 고립된 상태에서 테스트되는 것이 아닙니다. MICA를 삼켜버릴 수 있을 만큼 밀도가 높은 시스템 내부에서 테스트되고 있습니다. 하지만 MICA는 삼켜지지 않았습니다. 경계는 명확하게 유지되었습니다: MICA = 호출(invocation), 메모리(memory), 불변량(invariants), 드리프트 제어(drift control); CCGE 코어 = 페일 클로즈 런타임 및 아티팩트 생성; STEM-AI = 신뢰 재감사(trust re-audit) 및 분류(classification). 이것이 중요한 아키텍처적 결과입니다.

STEM-BIO-AI에서 MICA는 이미 도구의 운영적 정체성(operational identity)의 중심에 가깝게 위치해 있습니다. CCGE에서 MICA는 훨씬 더 큰 런타임(runtime) 내부에서 자신의 정체성을 유지해야 합니다. MICA는 호출(invocation), 메모리(memory), 불변성(invariants), 그리고 드리프트 제어(drift control)에 대한 책임을 유지함으로써 이를 수행하며, CCGE Core는 페일 클로즈드 실행(fail-closed execution) 및 아티팩트 로직(artifact logic)에 대한 책임을 유지합니다. CCGE의 현재 세션 보고서: [SESSION READY] Archive: None Load: {"state": "INVOCATION_MODE", "mica_yaml": "mica.yaml"} Self-test: {"pct": "CLOSED", "closed_contract": true} Drift: {"status": "NO_DRIFT"} Active invariants: {"critical_count": 0, "high_count": 0} Gate: PASS Archive: None with Gate: PASS는 모순이 아닙니다. 베이스라인 아카이브(baseline archive)는 아직 project.version 필드를 노출하지 않습니다. MICA는 해당 격차를 감지하고 작업이 시작되기 전에 이를 보고했습니다. 자신의 불완전함을 숨기는 시스템은 거버넌스(governance)를 받지 못합니다. 세션 시작 시점에 이를 드러내는 시스템은 거버넌스를 받습니다. 그 이유는 구체적입니다: 활성 아카이브는 아직 완전히 타겟에 바인딩된(target-bound) 아카이브가 아니라, 여전히 베이스라인 통합 메모리 객체(baseline integration memory object)이기 때문입니다. 해당 프로젝트 블록은 여전히 다음과 같은 플레이스홀더(placeholder)를 포함하고 있습니다: "project" : { "name" : "<target-repo-name>" , "path" : "<absolute-or-repo-relative-path>" , "owner" : "<org-or-maintainer>" , "integration_program" : "CCGE Unified Model" , "target_status" : "phase_1_candidate" }. 따라서 현재 보고서는 존재하는 것에 대해 진실을 말하고 있습니다: 즉, 여전히 베이스라인인 아카이브를 중심으로 결합된 일관된 MICA 패키지라는 점입니다. README가 있었다면 그 격차를 보이지 않는 상태로 두었을지도 모릅니다. 세션 보고서는 이를 즉시 드러냈습니다. 이것이 아카이브가 완전히 채워지기 전, 정직한 거버넌스가 보여주는 모습입니다. 7. 에이전트 워크플로우(Agent Workflows)를 구축하는 모든 이들에게 이것이 의미하는 바. 두 개의 서로 다른 프로젝트에 대해 이를 실행하며 얻은 세 가지 교훈. 사람이 읽을 수 있는 스타트업(startup)만으로는 충분하지 않습니다. 만약 유효한 경로가 오직 README에만 존재한다면, 해당 프로토콜은 부분적인 읽기(partial reading)와 호스트 가변성(host variance)에 취약해집니다.

STEM-BIO-AI가 바로 그 명확한 사례입니다. 메모리 레이어(memory layer)는 이미 성숙한 상태였지만, 올바른 시작(startup)은 여전히 운영자가 이를 로드하는 것을 기억해야 하는 것에 너무 많이 의존하고 있었습니다. 세션 시작 상태(Session-start state)는 반드시 기계가 사용 가능(machine-usable)해야 합니다. 만약 호스트 에이전트(host agent)가 시작 선언(startup declaration)을 구조화된 객체(structured object)로 소비할 수 없다면, 세션을 신뢰성 있게 사전 점검(preflight)할 수 없습니다. 이것이 바로 가이드 모드(guided mode)가 또 다른 설명 문서보다 더 중요한 이유입니다. 가이드 모드는 호스트에게 단순히 해석해야 할 지침(instructions)을 주는 것이 아니라, 실행할 수 있는 객체(object)를 제공하기 때문입니다. 게이트(gate)에는 엔트리포인트(entrypoint)가 필요합니다. 세션 보고서(session report)는 개념적인 하드 게이트(hard gate)가 될 수 있지만, 런처(launcher)나 호스트가 이를 진입 조건(entry condition)으로 사용하기 전까지는 관습(convention)으로 남을 뿐입니다. CCGE는 그 점을 더 강력하게 증명하는데, 왜냐하면 해당 환경은 이미 거버넌스 로직(governance logic)으로 밀집되어 있기 때문입니다. 명시적인 진입 표면(entry surface)이 없었다면, MICA는 독자적인 시작 레이어(startup layer)로 남는 대신 주변 프레임워크 속으로 쉽게 흐릿해졌을 것입니다.

8. 이것이 주장하지 않는 것
   MICA가 모든 환경에서 자동으로 자기 호출(self-invoke)을 수행한다고 주장하는 것은 아닙니다. LLM 세션이 거버넌스 아카이브(governed archive)를 먼저 로드하도록 강제하는 자연 법칙은 여전히 존재하지 않습니다. 실제 주장은 더 좁은 범위입니다: MICA는 이제 자연스럽게 읽힐 수 있고, MICA는 이제 의도적으로 요청될 수 있으며, MICA는 이제 기계적으로 강제될 수 있다는 것입니다. 완전한 자동화가 아닙니다. 강제 가능한 시작(enforceable startup)으로 가는 현실적인 경로입니다.

9. 8부에서 다룰 내용
   시작 경로(startup path)는 이제 훨씬 강력해졌습니다. 하지만 한 가지 질문이 남아 있습니다: 세션 시작 계약(session-start contract) 중 얼마만큼이 아카이브 자체에 의해 소유되어야 하며, 얼마만큼이 런타임 기본값(runtime default)으로 남아 있어야 하는가? 현재의 라인(line)은 session-report를 방출하고, 가이드 패킷(guided packets)을 컴파일하며, 강제 모드(forced mode)에서 차단할 수 있습니다. 다음 단계는 더 엄격한 아카이브 소유권(archive ownership)입니다 — 더 풍부한 session_report_format, 명시적인 아카이브별 session_gate_policy, 더 나은 드리프트 계약(drift contracts)이 그것입니다. 8부는 MICA가 시작을 거버넌스해야 하는지에 관한 것이 아닙니다. 그것은 이미 수행하고 있습니다. 8부는 그러한 동작 중 얼마만큼이 런타임에 의해 추론되는 대신 아카이브에 의해 선언되어야 하는지에 관한 것입니다. 이 시리즈는 명시, 테스트 또는 수정할 구체적인 대상이 있는 곳에서만 계속됩니다.

이 포스트로부터 도출된 명시적 결정: 프로토콜 (Protocol)은 아직 엔트리포인트 (Entrypoint)가 아닙니다. MICA는 호출 (Invocation)이 자연스럽거나 (natural), 유도되거나 (guided), 또는 강제될 (forced) 때 비로소 작동합니다. 그리고 세션은 막연한 기대가 아닌, 선언된 활성화 패킷 (Activation packet)으로부터 시작됩니다. MICA는 Flamehaven의 거버넌스 우선 (Governance-first) AI 시스템 관행의 일부입니다. 스키마 (Schema), 기술 보고서 (Technical report), 그리고 프로덕션 인스턴스 (Production instance): flamehaven.space . 오픈 소스 툴링 (Open-source tooling): AI-SLOP-Detector . 모든 스키마 참조는 특정 이전 버전이 명시되지 않는 한 v0.1.8.1 유니버설 표준 (Universal standard)을 따릅니다.