Skip to content

ghost alice os design_ko

Jump to bottom
garlicvread edited this page Jun 6, 2026 · 1 revision

Ghost-ALICE OS: 설계 철학과 런타임 동작

언어: 🇺🇸 English | 🇰🇷 한국어

Contents

개요

이 문서는 로컬 ghost-alice 저장소에 정의된 Ghost-ALICE OS의 설계 철학, 구현 구조, 런타임 동작 방식을 설명하는 Wiki 해설이다. 실행 계약의 normative SSOT는 메인 리포의 README.md, AGENTS.md, skill-catalog/session-gates.json, docs/policies/, official-docs/derived/에 둔다.

이 시스템은 단순한 프롬프트 모음이 아니다. 더 정확히는 작업 품질 하한을 보장하기 위한 agent governance operating layer이다.

Ghost-ALICE OS는 expert의 상한을 더 높이는 도구가 아니다. 익숙하지 않은 작업자, 숙련도가 낮은 작업자, 또는 컨디션 나쁜 LLM도 acceptable output 아래로 떨어지지 않도록 floor를 보장하는 시스템이다. 그래서 이 시스템의 핵심 질문은 "에이전트가 얼마나 창의적인가"가 아니라 "작업이 틀릴 때 어떤 지점에서 멈추고 다시 검증되는가"이다.

그 목적을 위해 다음 원칙으로 움직인다.

  • 작업을 verification burden 기준의 semantic atom으로 분해한다
  • 각 atom과 결합 결과를 schema·SSOT·evidence·source-locator에 반복 대조한다
  • 에이전트가 혼자 확정할 수 없는 claim에는 실제 source locator를 남긴다
  • 사용자 상호작용과 mismatch 위치에 따라 micro·meso·macro·meta focus를 왕복 조절한다
  • session-intent ledger와 io-trace를 기록물에 머물게 하지 않고 다음 판단의 입력으로 되먹인다
  • 완료 선언 전에는 반드시 증거 기반 게이트를 통과시킨다

Ghost-ALICE OS의 정체성은 개별 스킬 목록이 아니라 어떤 capability도 floor-governance loop를 우회하지 못하게 하는 운영층에 있다. core 설명은 task-router, session-intent-analyzer, boundary-contract, merge-companion, compact-handoff, 보안 스캔, skill-evolution, jailbreak-detector, tool-checkpoint 같은 시스템 거버넌스·운영 역할에 집중한다.

분류상 task-router, session-intent-analyzer, boundary-contract는 모든 작업 앞단의 코어 진입·의도·경계 게이트이다. compact-handoff, 보안 스캔, skill-evolution은 런타임 자체를 점검·운영하는 시스템 운영 스킬이다. jailbreak-detector는 session-intent-analyzer가 만든 current intent를 소비하고 current-lineage block을 downstream-gates.json으로 전달할 수 있는 보안 판정 스킬이다. tool-checkpoint는 user-input intake가 아니라 tool-stage retry checkpoint이다. merge-companion, necessity-gate, verification-before-completion처럼 특정 시점에 gate로 작동하는 스킬은 라이프사이클·거버넌스 역할로 분리해서 설명한다.

현재 Wiki 설명은 packaging 형식 설명이 아니라 core performance 설명에 맞춘다. 핵심 업데이트 축은 semantic-atoms, focus-layer, claim-evidence-map, source-locator, intent/trace feedback, hook parity이다. 이 축은 packaging 형식 업데이트와 분리된 core governance loop 성능 향상 방향이다.

핵심 철학을 한 문장으로 압축하면 이렇다.

Ghost-ALICE OS는 의심 많은 작업자의 검증 습관을 에이전트 런타임에 이식해 작업 품질 하한을 보장한다.

이 문장이 시스템 전체의 중심축이다.

운영상으로 풀어 쓰면 다음 문장도 같은 축에 있다.

복잡한 작업은 "툴이 많이 필요한 작업"이 아니다. 복잡한 작업은 중간 상태를 외부 기준과 반복 비교하지 않으면 쉽게 틀리는 작업이다.

따라서 Ghost-ALICE OS에서 도메인 스킬은 정체성의 중심이 아니라 capability pack이다. 문서 자동화, 코딩 컨벤션, 디자인, 애플리케이션 개발, 모델 구축 같은 기능은 모두 이 governance layer 위에서 실행된다. 중요한 것은 어떤 capability가 호출되더라도 작업 경계, 근거, 검증, 완료 판단을 우회하지 못한다는 점이다.

설계 철학

1. 원샷 추론보다 폐루프 추론을 우선한다

저장소는 복잡한 작업을 closed-loop reasoning으로 정의한다. 즉, 한 번 생각해서 끝내는 방식이 아니라 다음 여섯 단계를 반복하는 방식이다.

  1. 임시 상태를 만든다
  2. 참조 기준이나 제약을 꺼낸다
  3. 현재 상태와 비교한다
  4. mismatch를 찾는다
  5. 수정하거나 에스컬레이션한다
  6. 멈춤 조건까지 반복한다

즉, 검증은 후처리가 아니다. 검증은 작업 방식 자체이다.

이 폐루프는 에이전트의 창발성을 없애기 위한 장치가 아니다. 창발성이 검증되지 않은 실행 권한, 완료 주장, 새 작업 생성, scope 확장으로 바로 점프하지 못하게 만드는 장치이다. 작은 단위에서는 맞아 보였던 작업도 macro 정합성에서 깨질 수 있고, 그러면 구조가 틀렸는지 micro 작업이 틀렸는지 다시 확인한 뒤 하위 단위 재작업이나 구조 재설계로 되돌아간다. 따라서 "에이전트는 root가 아니다"라는 표현은 출발점이 아니라 작업 품질 하한 보장에서 나온 런타임 귀결이다.

1-1. focus aperture는 단조 확대가 아니다

Ghost-ALICE OS의 포커스 조절은 micro에서 시작해 meta로 점점 커지는 선형 절차가 아니다. 작업자는 사용자와 상호작용하면서 micro·meso·macro·meta를 계속 오간다.

예를 들어 작은 파일 수정 하나는 micro layer에서 맞아 보일 수 있다. 그러나 전체 문서 구조나 설치 계약을 보면 그 수정이 macro layer에서 틀릴 수 있다. 이때 시스템은 "더 큰 범위를 봤으니 이제 앞으로만 간다"고 판단하지 않는다. 다시 micro 작업이 틀렸는지, meso grouping이 잘못됐는지, macro 구조를 바꿔야 하는지 확인한다.

이 왕복 조절이 focus aperture이다. aperture는 넓어지기만 하는 값이 아니라, mismatch 위치와 verification burden에 따라 좁아지고 넓어지는 작업 초점이다.

2. 진짜 복잡도는 툴 수가 아니라 verification burden이다

이 시스템은 툴 수를 복잡도의 본질로 보지 않는다. 대신 verification burden을 실제 복잡도 축으로 본다.

그래서 겉보기에는 단순한 "값 복사" 작업도 아래 요소가 있으면 복잡한 일로 취급된다.

  • 어떤 소스를 쓸지 선택해야 한다
  • 스키마나 양식을 해석해야 한다
  • 어느 슬롯에 넣을지 매핑해야 한다
  • 정합성과 규정을 다시 확인해야 한다
  • 틀렸을 때 회복 비용이 크다

이건 상당히 강한 설계 선택이다. 겉보기 단계 수가 짧다는 이유로 작업 난도를 과소평가하는 실패를 막아 준다.

3. 정적 라우팅과 런타임 루프를 분리한다

시스템은 두 가지를 명확히 분리한다.

  • 정적 스킬 그래프
  • 런타임 피드백 루프

정적 calls는 의도적으로 드물고 안정적인 관계만 담는다. 예를 들면:

  • hard prerequisite
  • meta entrypoint
  • 안정적인 의존 관계
  • union-choice 스타일의 분기
  • session-intent-analyzer처럼 다른 스킬이 소비하는 세션 semantic context

반대로 다음은 정적 calls에 넣지 않고 런타임 절차로 둔다.

  • 반복 재검토
  • 다시 읽기
  • mismatch 기반 수정
  • 다회 검증 라운드

이 분리는 중요하다. 그래프는 읽기 쉽게 유지하면서도, 실제 실행에서는 필요한 만큼 공격적인 검증 루프를 돌릴 수 있기 때문이다.

4. 거버넌스를 도메인 옵션이 아니라 횡단 계층으로 둔다

이 시스템은 몇몇 동작을 도메인 스킬의 취향이 아니라 거버넌스 계층으로 본다.

대표적으로:

  • task-router는 전체 시스템의 글로벌 라우팅 레이어이다
  • session-intent-analyzer는 사용자 입력마다 세션별 intent ledger를 갱신하고, raw prompt 없이 목표·제약·결정·non-goal을 압축한다
  • boundary-contract는 수정·검증·외부 side effect 작업의 경계를 먼저 고정한다
  • using-coding-convention은 코딩 도메인 내부 라우팅 레이어이다
  • adversarial-verification은 횡단 검증 엔진이다
  • verification-before-completion은 종료 게이트이다
  • merge-companion은 설치 후 사용자 로컬 변경분을 보호하고 머지 결정을 돕는다
  • compact-handoff는 긴 작업의 context 압축 전후 상태·증거·rollback을 보존한다
  • 보안 스캔 스킬은 hooks, settings, skills, MCP config의 보안 표면을 report-only로 점검한다
  • skill-evolution은 io-trace에서 반복 workflow 후보를 찾되 자동 변경은 하지 않는다
  • jailbreak-detector는 current intent와 현재 입력 요약을 비교해 instruction override, credential reveal, scope 탈선 신호를 판정한다

즉, 어떤 도메인 스킬이 "검증을 쓸까 말까"를 결정하는 구조가 아니다. claim 성격, verification burden, 라이프사이클 단계에 따라 거버넌스가 검증을 주입한다.

5. 합리화 방지를 운영 모델에 내장한다

이 시스템의 가장 독특한 성격 중 하나는, 에이전트의 자기합리화를 설계상 위험으로 본다는 점이다.

스킬들은 반복적으로 이런 규칙을 강제한다.

  • 라우팅 전에 실행하지 않는다
  • "이건 쉬워 보인다"는 이유로 스킬을 건너뛰지 않는다
  • 스킬 확인 전에 질문부터 던지지 않는다
  • 새 검증 증거 없이 성공을 선언하지 않는다

이건 단순한 말투가 아니다. 드리프트, 게으른 지름길, 조기 수렴을 막기 위한 제어 전략이다.

6. Progressive Disclosure로 컨텍스트를 통제한다

각 스킬은 의도적으로 층을 나눠서 설계되어 있다.

  • SKILL.md: 짧고 핵심적인 운영 지침
  • references/: 필요할 때만 여는 상세 지식
  • prompts/: 단계별 생성 자산
  • scripts/: 반복 절차를 코드화한 실행 로직
  • templates/: 출력 구조를 안정화하는 템플릿

이 구조는 실용적이다. 첫 로딩의 컨텍스트 부하는 작게 유지하면서, 깊이가 필요한 순간에만 확장할 수 있게 해 준다.

7. 멀티플랫폼 적응을 1급 요구사항으로 본다

이 시스템은 한 환경에서만 쓰이는 스킬 묶음이 아니다. semantic workflow는 하나로 유지하되, 각 호스트 런타임의 툴 표면에 맞게 governance contract를 배치하는 방식으로 설계되어 있다.

현재 사용자 안내의 중심은 Claude Code와 Codex이다. Gemini CLI는 제거된 legacy target이며 현재 신규 사용자 설치 흐름에 포함하지 않는다. 이 문서는 실제 지원이 확인된 호스트만 설치 대상으로 안내한다.

철학은 "한 번 쓰고 아무 데서나 되길 바란다"가 아니다. 더 정확히는 "semantic workflow는 하나로 유지하되, 툴 표면은 런타임별로 매핑한다"에 가깝다.

그래서 플랫폼별 도구 매핑과 설치 로직이 도메인 스킬과 분리되어 있다.

구현 철학

저장소 구조

저장소는 단순한 주제별 분류가 아니라 실행 역할 중심으로 정리되어 있다.

  • task-router/
    • 전 작업 공통 진입점
  • session-intent-analyzer/
    • 세션별 사용자 의도 ledger. raw prompt 없이 current intent를 유지하고 skill-evolution과 jailbreak-detector가 소비하는 semantic context를 제공
  • boundary-contract/
    • 작업 경계 계약. allowed/prohibited surface와 stop condition 선언
  • 사용자 변경 보호 라이프사이클 게이트
    • merge-companion
  • 시스템 운영 스킬
    • compact-handoff, 보안 스캔, skill-evolution
  • 보안 판정 스킬
    • jailbreak-detector
  • coding-convention/
    • 코딩 도메인용 거버넌스 패밀리
  • 도메인 스킬
    • 문서 자동화, 논리적 글쓰기, 애플리케이션 개발, 모델 구축, 엣지 배포 등 공개 capability pack
  • 횡단 검증
    • adversarial-verification
  • 라이프사이클 게이트
    • verification-before-completion, necessity-gate
  • 공용 지원
    • _shared/, 설치 스크립트, secrets helper, MCP 설치기

이 구조는 다음과 같은 계층형 아키텍처를 반영한다.

  1. 작업 유형 식별
  2. 실행 스킬 선택
  3. 거버넌스 적용
  4. 도메인 작업 수행
  5. 완료 전 검증

스킬 패키징 모델

각 스킬은 커다란 프롬프트 덩어리가 아니라 작은 운영 패키지처럼 구현되어 있다.

  • SKILL.md는 트리거, 워크플로우, 제약을 정의한다
  • references/는 메인 스킬을 비대하게 만들지 않고 상세 지식을 담는다
  • scripts/는 반복적이거나 깨지기 쉬운 절차를 실행 코드로 만든다
  • templates/는 결과물 구조를 안정화한다
  • prompts/는 단계별 생성 동작을 분리한다

이 방식은 순수 프롬프트 시스템보다 유지보수성이 높다.

  • 프롬프트 크기가 통제된다
  • 반복 절차를 코드로 검증할 수 있다
  • 도메인 지식이 커져도 메인 스킬이 붕괴하지 않는다

라우팅 모델

README 기준으로 보면 전체 시스템의 1차 진입점은 task-router이다.

이 라우터의 역할은 사용자 요청을 다음 세 가지로 분류하는 것이다.

  • output skill
  • verification skill
  • lifecycle skill

코딩 작업이면 task-router가 using-coding-convention으로 넘기고, 그 안에서 coding-convention 패밀리 내부의 2차 라우팅이 일어난다.

즉, 전체 구조는 2단계 라우팅 모델이다.

  1. 전체 스킬 카탈로그를 대상으로 한 글로벌 라우팅
  2. 코딩 도메인 내부에서의 세부 프로세스 라우팅

검증 모델

구현 철학에서 가장 강하게 드러나는 부분은 검증 스택이다.

adversarial-verification

이 스킬은 친절한 reviewer가 아니라 구조화된 공격 엔진이다.

주요 설계 특징은 다음과 같다.

  • 최소 5라운드 이전에는 수렴 금지
  • 쉬운 합의 금지
  • 다수결이 아니라 만장일치 요구
  • "맞는 것 같다" 식의 수동적 양보 금지
  • deadlock에서만 meta-judge 등장
  • 최종 판단 권한은 여전히 사람에게 남는다

즉, 이 스킬은 고검증 부담 claim을 위한 거버넌스 엔진이지, 가벼운 보조 도구가 아니다.

verification-before-completion

이 스킬은 종료 게이트이다.

다음과 같은 말을 새 증거 없이 못 하게 막는다.

  • "끝났다"
  • "통과했다"
  • "고쳐졌다"
  • "이제 된다"

즉, 앞단 라우팅이 조금 흔들려도 마지막 단계에서 정직성을 강제하는 역할을 한다.

런타임 동작

Hook runtime guard layer

런타임에서는 스킬 본문과 별개로 hook이 최소 안전선을 유지한다.

  • 모든 사용자 입력은 session-intent-analyzer ledger에 반영된다. hook은 raw prompt를 저장하지 않고 digest와 압축 의도 요약만 남기며, 에이전트는 목표·제약·결정·non-goal 변화가 있으면 intent-state.json을 갱신한다.
  • skill-evolution은 같은 session intent와 io-trace context를 report-only branch로 소비한다. task-router로 이어지지 않는다.
  • jailbreak-detector는 이 current intent와 현재 입력 요약을 비교해 instruction override, credential reveal, scope 탈선을 allow / ask-confirm / block으로 판정한다. current-lineage block decision만 downstream-gates.json으로 전달한다.
  • task-router는 session-intent intake와 jailbreak downstream gate가 current-lineage block을 먼저 열 기회를 가진 뒤 실행된다. block이 없으면 downstream-gates.json 부재는 silent allow이다.
  • pending merge precheck는 현재 플랫폼 manifest만 본다. hook이 clean contract를 제공한 경우에는 같은 manifest를 다시 shell로 읽지 않고 merge-companion-precheck: clean (hook-verified)로 기록한다.
  • tool-checkpoint는 tool-stage PreToolUse retry checkpoint이다. intent, boundary, rejected alternatives, unverified premises, failure mode를 설명하는 closed-loop fields를 사용한다. routine checkpoint는 별도의 recovery-cost 또는 recovery-note fields를 요구하지 않는다. recovery-action은 mismatch, scope reopen, external side effect, hard-to-recover action에 concrete next step이 필요할 때만 나타난다.
  • 완료·추천·선택·성공 판정 전에는 verification-before-completion을 실제로 적용한다. Claude Code처럼 visible Skill surface가 있으면 실제 Skill 호출 이후에만 skill-call을 적고, Codex hookless 환경에서는 해당 SKILL.md를 이번 턴에 읽고 절차를 따른 경우에만 적는다.
  • 최종 응답에서 skill-call: verification-before-completion (this turn)을 주장하면 [io-trace]의 skills-loaded에도 같은 스킬을 포함한다.

플랫폼별 설치기는 이 layer를 각 런타임의 표면에 맞게 배치한다. Claude Code는 settings.json hook과 permissions.allow에 설치된 Skill(<name>) 권한을 반영한다. Codex는 visible Skill surface가 없으므로 hook, AGENTS.md bootstrap, SKILL.md read 계약을 함께 쓴다. 설치되는 runtime 표면은 pending merge precheck, task-router reminder, session-intent-analyzer ledger, web-search reminder, tool-checkpoint, completion-reminder, io-trace audit이다. install-time visibility는 --visibility strict|dynamic|minimal이 primary flag다. --agent-visibility는 compatibility alias로 유지한다. 이 profile은 user-facing governance message volume만 바꾸며 hook execution이나 strict logs를 줄이지 않는다.

Work-Impact Projection은 hook-internal value가 next work decision에 중요한지 판단한다. value는 work boundary, focus layer, verification burden, recovery path를 바꿀 수 있을 때 중요하다. routine/debug values는 strict logs에는 남지만 task quality를 바꾸지 않으면 model hint나 user surface에 올릴 필요가 없다.

운영 중 hook payload가 현재 설치기 계약과 어긋난 것으로 보고되면 해당 플랫폼 설치기를 다시 실행해 관리 entry를 갱신한다. pending-merge entry가 남으면 merge-companion 기준으로 merged / discarded / deferred 중 하나로 결정한 뒤 pending-merge: clean 상태를 확인한다.

의도된 런타임 흐름

저장소 설계가 의도하는 런타임 흐름은 아래와 같다.

flowchart TD
    A[사용자 입력] --> PM{pending-merge precheck}
    PM -->|undecided entry| MC[merge-companion]
    PM -->|clean 또는 none| SI[session-intent-analyzer]
    MC --> SI

    SI --> SE[skill-evolution report-only]
    SI --> JD[jailbreak-detector]
    JD --> DG{downstream-gates current-lineage block?}
    DG -->|block| STOP[stop or ask-confirm]
    DG -->|silent allow| TR[task-router]
    TR --> AT[semantic atoms + provisional skill match]
    AT --> BC{boundary-contract required?}
    BC -->|yes| BCS[boundary-contract]
    BC -->|no| TC[tool-checkpoint]
    BCS --> TC

    TC --> EX[governed tool or skill action]
    EX --> EV{verification burden / claim risk}
    EV -->|task-complexity-level-1| VBC[verification-before-completion]
    EV -->|task-complexity-level-2 or task-complexity-level-3| AV[adversarial-verification or evidence loop]
    AV --> EM[claim-evidence-map + source-locator]
    EM --> VBC

    VBC --> OUT[final response]
    OUT --> IO[io-trace]
    IO --> FB[intent and trace feedback]
    FB -. next turn .-> PM
Loading

hook이 있는 런타임에서는 일부 gate가 reminder나 precheck payload로 먼저 관찰된다. 그러나 hook evidence만으로 gate completion을 주장하지 않는다. Codex처럼 visible Skill surface가 없거나 hookless/manual 환경이면 해당 SKILL.md를 실제로 읽고 workflow를 수행해야 skill-call로 기록할 수 있다.

레이어별 제어 논리

레이어 0: 세션 의도 ledger

session-intent-analyzer는 현재 세션의 사용자 목표, 제약, 결정, non-goal, 열린 질문을 압축 상태로 유지한다. hook이 digest-only event를 남겼다는 사실만으로는 done이 아니며, agent가 semantic delta를 반영했거나 반영하지 않는 이유를 설명해야 한다.

이 ledger는 세 방향으로 쓰인다.

  • skill-evolution이 io-trace의 tool sequence를 사용자 의도 변화와 함께 해석한다
  • jailbreak-detector가 현재 입력이 기존 의도와 충돌하거나 instruction hierarchy를 우회하려는지 판정한다
  • task-router는 jailbreak downstream gate가 먼저 block할 기회를 가진 뒤 열린 intent context를 소비한다
  • tool-checkpoint는 tool-stage action 전에 current-lineage block gate와 boundary 또는 recovery contract를 확인한다

raw prompt, 전체 대화, tool output, secret 원문은 이 ledger에 넣지 않는다.

레이어 1: 글로벌 라우팅

task-router는 단순 skill match 이전에 작업의 semantic atoms와 verification burden을 드러내야 한다. skill 선택은 확정이 아니라 revise 가능한 provisional routing으로 다룬다.

현재 설명 기준의 라우팅 산출은 다음 축을 포함한다.

  • semantic-atoms: 목표, source dependency, target surface, verification burden, fallback layer
  • provisional skill match: output / verification / lifecycle 후보
  • boundary-contract: required | n/a
  • next-required: 다음 gate 또는 없음

레이어 2: 도메인 내부 라우팅

코딩 작업에서는 using-coding-convention이 다음 프로세스 스킬을 고른다.

예를 들면:

  • brainstorming
  • writing-plans
  • systematic-debugging
  • test-driven-development
  • verification-before-completion

레이어 3: 도메인 실행

도메인 스킬은 자신의 reference, script, template를 사용해 실제 작업을 수행한다. 단, 실행 직전에는 tool-checkpoint가 current-lineage downstream gate, boundary contract, focus layer, 그리고 next work decision을 바꾸는 conditional recovery action을 확인한다.

예를 들면:

  • 문서 자동화: 구조화 문서 추출 및 생성
  • 논리적 글쓰기: 특허·논문형 구조 문서 작성
  • 애플리케이션 개발: 구현 작업 수행
  • 모델 개발·배포: 모델 구축과 edge deployment 작업 수행

레이어 4: 횡단 검증

claim burden이 높으면 adversarial-verification 또는 별도 evidence loop가 런타임에 주입된다.

이건 정적 always-on edge가 아니라 런타임 거버넌스이다. 수치·원본 source·표·그림·외부 도구 동작 같은 claim은 source-locator 없이 통과하지 않는다.

레이어 5: 완료 게이트

어떤 "완료" 주장도 verification-before-completion 없이 통과시키지 않는다. 완료 증거는 테스트 통과 같은 단일 신호가 아니라 claim이 요구하는 fresh evidence와 locator를 기준으로 본다.

Adversarial Verification 런타임

검증 엔진의 내부 루프는 아래처럼 볼 수 있다.

flowchart TD
    A[claim candidate] --> G{Step 0 entry gate}
    G -->|verification-complexity-level-1 또는 자명 claim| VerificationLevel1[Step 1 evidence precheck only]
    G -->|verification-complexity-level-2| A3[3-agent Free-For-All]
    G -->|verification-complexity-level-3| A5[5-agent Free-For-All]

    VerificationLevel1 --> Level1Evidence{evidence / locator present?}
    Level1Evidence -->|yes| Level1Accept[accept with rounds-log 0]
    Level1Evidence -->|no| Level1Reject[reject or escalate]

    A3 --> CC[claim-card normalization]
    A5 --> CC
    CC --> EC{evidence-list + source-locator valid?}
    EC -->|no| ER[reject or escalate before rounds]
    EC -->|yes| R[round 1-4 forced attack]

    R --> CP[round 5+ checkpoint]
    CP --> SSOT{claim-card and SSOT still match?}
    SSOT -->|critical mismatch| ES[escalate]
    SSOT -->|match| CV{convergence condition met?}
    CV -->|unanimous accept| OK[surviving claim + guarantee boundary]
    CV -->|repeated unresolved attack| RJ[reject]
    CV -->|deadlock or round 50| MJ[meta-judge deadlock report]
    CV -->|no| CP
    MJ --> H[human decision]
Loading

이 다이어그램이 보여주는 핵심은 분명하다.

  • verification-complexity-level-1은 라운드 비용을 쓰지 않고 evidence precheck에서 처리한다
  • verification-complexity-level-2/3는 agent 수와 공격 축을 달리한다
  • source-locator가 없으면 라운드 전에 막는다
  • 수렴은 늦게 일어나고, accept도 surviving claim과 guarantee boundary를 남긴다
  • deadlock의 최종 결정권은 사람에게 둔다

왜 이 시스템이 일반적인 스킬 시스템과 다르게 느껴지는가

대부분의 스킬 시스템은 사실상 카테고리형 프롬프트 라이브러리이다.

반면 이 시스템은 다음 성격이 훨씬 강하다.

  • entrypoint routing
  • layered governance
  • lifecycle gate
  • runtime verification loop
  • progressive disclosure 기반 지식 로딩
  • 플랫폼 적응 계층

그래서 이 시스템은 일반적인 재사용 프롬프트보다 훨씬 엄격하게 느껴진다. 문장을 잘 쓰게 만드는 데서 끝나는 게 아니라, 에이전트의 행동 자체를 구조화하려 하기 때문이다.

실무적으로 읽으면 어떤 시스템인가

한 문장으로 압축하면 다음과 같다.

Ghost-ALICE OS는 사용자 의도를 semantic atoms로 나누고, focus layer와 boundary를 잠근 뒤, governed action의 결과를 claim-evidence-map과 source-locator로 닫고, io-trace와 session-intent를 다음 판단으로 되먹이는 계층형 에이전트 거버넌스 프레임워크이다.

세 가지 운영 규칙으로 줄이면 이렇다.

  1. 실행부터 시작하지 않고 semantic atom과 boundary부터 잡는다
  2. mismatch 위치에 따라 micro·meso·macro·meta focus를 왕복한다
  3. 새 증거와 locator 없이는 완료를 말하지 않는다

강점

  • 조기 실행을 강하게 억제한다
  • 정적 라우팅과 동적 검증 루프의 분리가 잘 되어 있다
  • Progressive Disclosure 덕분에 컨텍스트 관리가 좋다
  • 여러 AI 런타임으로 이식하기 쉽다
  • 고검증 작업에서 sycophancy 방어가 강하다
  • 도메인 작업과 거버넌스 역할 구분이 명확하다
  • session-intent와 io-trace feedback으로 다음 턴의 판단 재료가 남는다

트레이드오프

  • 느슨하고 즉흥적인 상호작용을 선호하는 사용자에게는 무겁게 느껴질 수 있다
  • 호스트 런타임이 네이티브 스킬 호출을 깔끔하게 노출하지 않으면 규율이 다소 거칠게 체감될 수 있다
  • 멀티플랫폼 지원 때문에 저장소 설계와 실제 노출 동작 사이에 차이가 생길 수 있다
  • 라이프사이클 게이트를 런타임이 우회하면 시스템 품질이 곧바로 떨어질 수 있다

실제 런타임 표면과 설계 문서의 관계

저장소 설계상 글로벌 진입점은 task-router이고, 코딩 도메인은 그다음 using-coding-convention으로 들어간다. 다만 호스트 런타임마다 visible Skill surface, hook 지원 수준, 설정 파일 위치가 다르기 때문에 사용자에게 보이는 표면은 조금씩 다를 수 있다.

이 차이는 설계 자체를 무효화하지 않는다. 중요한 기준은 각 런타임에서 같은 의미론적 governance loop가 관찰되는지이다. 즉, 사용자 입력이 semantic atoms로 분해되고, 세션 의도가 유지되고, 경계가 잠기고, claim-evidence-map과 source-locator 없이 완료가 선언되지 않는다면 런타임 표면이 달라도 같은 운영 철학을 공유한다고 볼 수 있다.

추천하는 정신 모델

시스템을 가장 짧게 이해하려면 아래 다이어그램으로 보면 된다.

graph LR
    A[사용자 의도] --> B[semantic atoms]
    B --> C[focus-layer contract]
    C --> D[governed action]
    D --> E[claim-evidence-map]
    E --> F{mismatch?}
    F -->|yes| G[micro meso macro meta fallback]
    G --> B
    F -->|no| H[completion gate]
    H --> I[io-trace + intent feedback]
Loading

이 다이어그램이 현재 Wiki에서 기준으로 삼는 정신 모델이다. 핵심은 단순히 스킬을 고르는 것이 아니라, 작업을 검증 부담 단위로 쪼개고, focus layer를 잠근 뒤, evidence map과 trace를 다음 판단으로 되먹이는 것이다.

AidALL/ghost-alice | This wiki stores design documents only. Runtime files live in the main repository.

Home / 홈

🇺🇸 English

🇰🇷 한국어

Main repo

Clone this wiki locally