Karpathy의 LLM-OS 비유는 LLM을 컴퓨터의 CPU 자리에 둡니다. GEODE는 그 비유를 운영체제처럼 계층화했고, 지금의 답은 다섯입니다. 각 계층은 한 가지만 책임집니다.
다섯 계층
| 계층 | OS 비유 | 책임 | 대표 코드 |
|---|---|---|---|
| Model | 커널 / CPU | LLM 자체. 프로바이더 라우팅과 추론 | core/llm/providers/, core/llm/router/ |
| Runtime | 시스템콜 + 드라이버 | 도구, MCP, 메모리, 스킬. LLM이 외부와 닿는 모든 경로 | core/tools/, core/mcp/, core/memory/ |
| Harness | 셸 + init | CLI, serve, 훅, 게이트웨이, 레인. 사용자와 메신저가 시스템에 닿는 경로 | core/cli/, core/server/, core/hooks/, core/orchestration/ |
| Agent | 실행 루프 | while(tool_use). 항상 도는 실행 단위와 서브에이전트 | core/agent/loop/, core/agent/sub_agent.py |
| Self-Improving | 패키지 매니저 + 업데이트 채널 | 에이전트가 도는 스캐폴드 자체를 변이하고, 감사로 선택하고, 계보를 보존 | core/self_improving/ |
왜 다섯 번째 계층이 명시적이 되었나
S-5 구조 스프린트(v0.99.163) 전까지 GEODE는 4계층으로 서술됐고, 자기개선 코드는 다이어그램에 자리가 없었습니다. 코드 인구조사 결과는 반대였습니다. 자기개선 모듈의 절반가량이 4계층 어디에도 매핑되지 않았습니다. 코드가 아니라 다이어그램이 틀렸던 것입니다.
경계의 근거는 의존 방향입니다. 자기개선 계층은 Agent 계층을 측정 대상으로 호출하지만(감사 서브프로세스가 같은 AgenticLoop를 돌림), Agent 계층은 자기개선 계층을 모릅니다. 주입은 GEODE_WRAPPER_OVERRIDE 환경 변수와 SoT 파일이라는 좁은 인터페이스 하나로만 일어납니다 (core/agent/system_prompt.py가 소비자). 한 방향으로만 의존하고 인터페이스가 좁으면, 그것은 같은 계층이 아니라 위 계층입니다.
경계는 변경 비용으로도 강제됩니다. program.md 계약상 자기개선 에이전트는 측정 모듈 4개(measure.py, fitness.py, gate.py, ledger.py)를 수정할 수 없습니다. 측정 장비를 바꾸면 측정 대상이 아니라 자가 기준이 바뀌기 때문입니다. 이 불변 조건은 계층이 분리되어 있어야만 선언할 수 있습니다.
왜 3, 4, 6이 아닌가
- 3계층(Model + Runtime + Agent)이면 훅, 게이트웨이, serve, 레인이 갈 곳이 없습니다.
- 4계층은 자기개선 코드를 숨깁니다. 위에 쓴 대로 실측이 반증했습니다.
- 6계층(예: Runtime을 Tools와 Memory로 분리)은 그 사이 응집이 강해 분리 비용이 이득을 넘습니다. 도구 결과가 곧 컨텍스트가 되는 구조에서 둘은 함께 움직입니다.
경계가 진짜라는 증거
경계가 장식이 아니라면 교체 실험이 통과해야 합니다. 모델 교체 (/model)는 Model 계층만 바꿉니다. 메신저 추가는 Harness의 폴러 하나를 추가합니다. 스캐폴드 변이가 reject되면 Self-Improving 계층의 되돌림이 SoT를 복원할 뿐, 아래 계층 코드는 건드리지 않습니다. 세 실험 모두 현재 코드에서 단일 계층 변경입니다.