Codex User-Scope에 Loopy-Harness 관제탑을 얹었다

Report map

One-line verdict
Evidence stack
Target level
Requirements
User-scope inventory
Control-plane structure
Runtime contract
Adoption plan
Verification
Next moves

Verdict

필요한 건 지시문 한 줄이 아니라 운영체계다

당신이 원하는 것은 좋은 답변을 하는 에이전트가 아니다. 실패할 때마다 그 실패를 신호로 받아, 규칙과 검사기를 스스로 고쳐 나가는 개인 공통 설정 층의 하네스(user-scope harness)다.

결론부터 말하면 이렇다. 이 시스템이 도달해야 할 수준은 Practical L6+ / L7-oriented Personal AI Work OS Harness, 우리말로 풀면 '실패를 스스로 고쳐 나가는 개인용 일 운영체계'다. 영문 이름 속 6단계 이상과 7단계 지향은 앞서 말한 성숙도 사다리의 칸 번호다. 스킬 몇 개를 모아 둔 묶음이나 문서에만 적힌 지시문으로는 거기에 닿지 못한다. 내 작업 원칙이 실제 실행 시점(runtime)에 규칙·스킬·자동 검사 스크립트(훅)·검사기로 굳어져야 한다. 작업이 실패하면 그 실패가 자가개선(self-improve, 실패를 신호로 받아 규칙을 고치는 절차) 신호로 회수돼 다시 규칙을 고친다. 이렇게 한 바퀴 도는 순환 구조가 곧 폐루프다.

Evidence Stack

근거는 기억 창고와 작업 기록 사이트 양쪽에서 가져왔다

Research

Autoresearch

.omx/specs/autoresearch-harness-loopy-era-analysis라는 폴더에 쌓인 자동 실험 기록(autoresearch, AI가 스스로 실험을 돌리고 결과가 나아졌는지 자동으로 판정하는 자율 실험 루프)에서, 이미 검토를 마친 보고서와 결과물을 기준 근거로 삼았다.

Memory

Memory Bank

기억 창고(Memory Bank)는 지난 대화 기록과 장기 기억 구조, 그리고 사실을 저장·검색·다시 불러오는 계층이다. 이것을 이 시스템이 딛고 설 바탕으로 봤다.

Site Archive

`claude-code-site`

start-harness, codex-harness, loopy-era 세 문서, 그리고 대규모(기업용) 복잡도 문서(회사 규모에서 하네스가 얼마나 복잡해지는지 따진 글)까지 이 사이트에서 한데 모았다.

Kind	Representative path
Autoresearch	`/Users/jung-wankim/.omx/specs/autoresearch-harness-loopy-era-analysis/report.md`
Codex Harness	`/Users/jung-wankim/Project/Claude/claude-code-site/codex-harness-system.html`
Loopy-Era	`/Users/jung-wankim/Project/Claude/claude-code-site/loopy-era-architecture.html`
Memory Bank	`/Users/jung-wankim/Project/Claude/claude-code-site/memory-bank-analysis.html`
Enterprise Boundary	`/Users/jung-wankim/Project/Claude/claude-code-site/docs/enterprise-harness-complexity-analysis.md`

Target Level

6단계는 스스로 도는 순환이고 7단계는 통합 운영체계다

L3

Evidence gate

L4

Memory-grounded

L5

HARD gates

L6+

Closed loop

Level	Meaning	판정
`L0-L2`	잘 만든 지시문과 스킬에 약간의 자동화를 더한 단계	아직 부족하다. 작업이 끝나면 배운 것이 저장되지 않고 사라진다.
`L3`	'다 했다'는 주장을 증거로 확인하는 단계	여기서부터가 최소 합격선이다.
`L4`	기억 창고로 같은 실수 반복을 막는 단계	반드시 있어야 할 바탕이다.
`L5`	말뿐인 권고 규칙을 검사 가능한 강제 규칙으로 승격하는 단계	핵심 운영 원칙이다.
`L6`	signal → patch → verify → ack/rollback	목표로 삼은 최소선이다. 왼쪽 칸의 영문은 신호 감지 → 수정 → 검증 → 반영 또는 되돌리기가 스스로 도는 순서를 뜻한다.
`L7`	개인 공통 설정·프로젝트·플러그인·외부도구 연결(MCP)·외부 트렌드까지 하나의 운영체계로 묶는 단계	궁극적으로 지향하는 지점이다.

Requirements

지켜야 할 운영 규칙을 13개 요구사항으로 못 박았고, 그중 8개를 아래에 실었다

`REQ-AUTO-001`

자율 실행 규칙이다. 지시가 분명하고 되돌릴 수 없는 위험이 없는 작업은, 사용자에게 되묻지 않고 '살펴보기 → 실행 → 검증'까지 스스로 끝낸다.

`REQ-EVID-001`

증거 규칙이다. '완료'는 말로 선언하지 않는다. 실제 산출물, 테스트 통과, 검사 스크립트(validator, 산출물이 계약대로인지 자동으로 확인하는 프로그램), 점검 기록(audit, 무엇을 확인했는지 남긴 장부) 같은 증거가 있을 때만 완료로 인정한다.

`REQ-LOOP-001`

순환 규칙이다. 작업 중 겪은 마찰과 실패는 그냥 넘기지 않는다. 자가개선(self-improve)으로 규칙을 고치고, 그 수정을 반영하거나 문제가 있으면 되돌리는 것까지 마무리한다.

`REQ-HARD-001`

강제 규칙이다. 중요한 규칙은 문서에 적어 둔 권고로 두지 않는다. 특정 시점에 자동으로 검사하는 스크립트(훅·검사기)로 승격해 실제로 가로막게 만든다.

`REQ-MEM-001`

기억 규칙이다. 기억 창고(Memory Bank)는 보기 좋은 회상 기능에 그치지 않는다. 실제 작업이 딛고 도는 바탕이다.

`REQ-SCOPE-001`

범위 규칙이다. 무언가를 바꾸기 전에, 그 변경이 개인 공통 설정·특정 프로젝트·플러그인·외부도구 연결(MCP) 중 어디에 해당하는지부터 분류한다.

`REQ-DRIFT-001`

어긋남 추적 규칙이다. 설정·훅·스킬·플러그인·외부도구가 시간이 지나며 원래와 어긋나는 것(drift)을, 목록으로 계속 추적한다.

`REQ-VERIFY-001`

완료 점검 규칙이다. 완료를 선언하기 전에, '지시한 것이 실제 산출물로 나왔는가'를 확인하는 점검표를 반드시 통과해야 한다.

Inventory

이미 깔려 있는 개인 공통 설정만 해도 거대한 실행 기반이다. 아래는 그 설정 폴더 안에 든 것들의 개수다

2522

skills files

workflow capsules

157

rules files

soft / trend / hard rules

134

hooks files

event-time guards

122

scripts files

validators & supervisors

agents

native role surfaces

prompts

role execution prompts

MCP servers

state/memory/code/trace/wiki

plugins

browser/docs/sheets/decks

Structure

해법은 파일을 옮기지 않고 그 위에 관제탑을 얹는 것이다

이미 쓰고 있는 설정 폴더 ~/.codex(Codex가 개인 공통 설정을 읽어 가는 홈 폴더) 안에는 필요한 실행 도구가 이미 충분히 들어 있다. 그래서 안전한 방법은 이 파일들을 옮기거나 크게 뜯어고치지 않는 것이다. 대신 새 폴더 ~/.codex/harness를 만들어, 요구사항·지켜야 할 계약·변경 범위 분류기(scope classifier, 변경이 어느 범위에 속하는지 가르는 도구)·연결 명세(manifest, 무엇이 무엇에 연결돼 있는지 적은 목록)·점검 기록(audit, 무엇을 확인했는지 남긴 장부)을 한곳에서 관장하는 '관제탑(control plane)'으로 추가하는 것이다. 아래 나무 그림이 그 폴더 구조이고, 맨 아랫줄이 새로 얹은 관제탑이다.

~/.codex/
  AGENTS.md              # 모든 작업 공통 행동 규칙
  config.toml            # model/MCP/plugin binding
  hooks.json             # hook activation map
  skills/                # workflow capsules
  agents/                # native agent TOML
  prompts/               # role prompt surfaces
  rules/                 # soft/checkable/HARD rules
  hooks/                 # event-time guards
  scripts/               # validators/supervisors
  state/ reports/        # runtime evidence
  trend-harvest/         # external signal loop
  harness/               # NEW control plane

Runtime Contract

루프 방식은 실패를 버리지 않고 자산으로 바꾸는 순환 구조다

Signal
Intake

Scope
Classify

Patch
Proposal

Safety
Drift

Apply
Verify

Ack
Rollback

Persist
Inject

위 그림의 7단계는 이렇게 돈다. 먼저 실패나 마찰 같은 신호를 받아들인다(01). 그 변경이 어떤 범위에 속하는지 분류한다(02). 고칠 안을 만든다(03). 안전한지, 설정이 원래와 어긋나지 않았는지 확인한다(04). 적용하고 검증한다(05). 문제없으면 반영하고 문제가 있으면 되돌린다(06). 마지막으로 기록해 두었다가 다음 작업에 다시 불러온다(07). 이 순환 규칙은 loopy-era-runtime-contract.md라는 계약 문서(실행 시점에 지켜야 할 약속을 적어 둔 파일)에 못 박아 뒀다. 여기서 핵심은, 중요한 규칙을 'AI가 알아서 기억하겠지' 수준에 맡기면 안 된다는 것이다. 규칙은 자동 검사 스크립트(hook)·실행 스크립트·검사기(validator)·완료 점검(completion audit) 중 하나로 눈에 보이게 관측될 때에만, 실제로 가로막는 강제 관문(hard gate, 이 글의 표와 목록에서는 대문자로 적었다)이 된다.

Adoption Plan

적용은 9단계이고, 지금은 1~2단계까지 완료했다

baseline-freeze-inventory

기준선 동결과 목록 작성 단계다. 지금의 개인 공통 설정 상태와 핵심 파일의 지문(hash, 파일 내용을 요약한 짧은 고유 값)을 목록으로 찍어 기준점으로 고정한다. 오른쪽의 landed 는 이미 마쳤다는 뜻이고 planned 는 예정이라는 뜻이다.

landed

requirements-control-plane-landing

요구사항과 관제탑을 자리 잡게 하는 단계다. 요구사항·구조·계약·변경 범위 표·연결 명세를 실제로 자리 잡게 한다.

landed

skill-application

스킬 적용 단계다. 중요한 스킬들을 '입력·출력·증거·실패 처리·되돌리기' 형식으로 통일한다.

planned

rule-hard-gate-application

규칙의 강제 관문 적용 단계다. 말뿐인 권고 규칙을, 검사할 수 있는 강제 관문으로 승격한다.

planned

agent-prompt-application

에이전트 프롬프트(각 에이전트에게 주는 역할 지시문) 적용 단계다. 각 에이전트의 역할 경계와, 누가 검증을 책임지는지를 분명히 한다.

planned

plugin-application

플러그인 적용 단계다. 플러그인 원본을 직접 건드리지 않고, 실행 조건과 증거 규약으로만 연결한다.

planned

mcp-application

외부 연결 적용 단계다. 상태·기억·코드 분석·실행 기록·위키 역할을 하는 외부 연결(MCP)을 연결 명세에 묶는다.

planned

runtime-verification-expansion

실행 시점 검증 확장 단계다. 단어를 찾아 확인하는 수준(grep, 파일에서 글자를 찾는 명령)의 검증을, 실제 동작 시나리오로 확인하는 방식으로 넓힌다.

planned

operating-loop

운영 루프 단계다. 세션 시작·종료 처리, 외부 트렌드 수집, 설정 어긋남 점검, 자가개선 반영을 정기적으로 돌린다.

planned

Verification

완료 선언은 검사 53개를 모두 통과시켜 마무리했고, 판정은 통과(pass)다

PASS

verification status

checks

failed

prompt mappings

verification file
/Users/jung-wankim/.codex/harness/reports/completion-verification.json

status: pass
checks: 53
failed: 0
audit: /Users/jung-wankim/.codex/harness/reports/completion-audit.md

Next Moves

다음은 실제 실행 동작을 더 단단하게 만드는 일이다

#	Next patch	Why it matters
01	`completion-audit` validator script	완료 점검 검사 스크립트를 만드는 일이다. 완료 전에 '지시가 실제 산출물이 됐는가'를 점검하고, 통과 못 하면 무조건 막도록(fail-closed, 판정이 불확실하면 열어 주지 않고 닫아 두는 방식) 만든다.
02	`scope-classifier` `CLI`	변경 범위 분류기를 명령줄 도구(터미널에서 명령을 쳐서 실행하는 프로그램)로 만드는 일이다. 변경이 엉뚱한 범위(개인 공통·프로젝트·플러그인·외부도구 연결)로 새어 섞이는 것을 막는다.
03	critical skills audit	핵심 스킬 점검이다. 스킬을 '검증할 수 있는 작업 단위'로 승격한다.
04	MCP/plugin drift checker	외부 연결과 플러그인의 어긋남 검사기다. 실행 중인 것과 원본이 어긋나는(drift) 것을 눈에 보이게 만든다.
05	behavior scenario eval	동작 시나리오 평가다. 지금 검증은 파일에서 단어를 찾는 명령으로 100점을 받은 상태인데, 단어만 찾아 매기는 점수(grep 100점)의 한계를 넘어선다.
06	soft → checkable → `HARD` promotion	권고(soft)에서 검사 가능(checkable)으로, 다시 강제 관문으로 올리는 승격 사다리다. 되풀이되는 실수를, 실제로 가로막는 관문으로 바꾼다.

기준점은 이미 자리 잡았다. 이제 남은 일은 이 기준점을, 실행 중에 실제로 강제되는 규칙으로 천천히, 검증하면서 한 단계씩 끌어올리는 것이다.