필요한 건 지시문 한 줄이 아니라 운영체계다
결론부터 말하면 이렇다. 이 시스템이 도달해야 할 수준은 Practical L6+ / L7-oriented Personal AI Work OS Harness, 우리말로 풀면 '실패를 스스로 고쳐 나가는 개인용 일 운영체계'다. 스킬 몇 개를 모아 둔 묶음이나 문서에만 적힌 지시문이 아니다. 내 작업 원칙이 실제 실행 시점(runtime)의 규칙·스킬·자동 검사 스크립트(훅)·검사기로 굳어지고, 작업이 실패하면 그 실패가 자가개선(self-improve) 신호로 회수돼 다시 규칙을 고치는 순환 구조, 즉 폐루프다.
근거는 기억 창고와 작업 기록 사이트 양쪽에서 가져왔다
Autoresearch
.omx/specs/autoresearch-harness-loopy-era-analysis라는 자동 실험 기록에서, 이미 검토를 마친 보고서와 결과물을 기준 근거로 삼았다.
Memory Bank
지난 대화 기록과 장기 기억 구조, 그리고 사실을 저장·검색·다시 불러오는 계층을, 이 시스템이 딛고 설 바탕으로 봤다.
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 |
L6은 스스로 도는 순환, L7은 통합 운영체계
| Level | Meaning | 판정 |
|---|---|---|
| L0-L2 | 잘 만든 지시문과 스킬, 약간의 자동화 | 아직 부족하다. 작업이 끝나면 배운 것이 저장되지 않고 사라진다. |
| L3 | '다 했다'는 주장을 증거로 확인하는 단계 | 여기서부터가 최소 합격선. |
| L4 | 기억 창고로 같은 실수 반복을 막는 단계 | 반드시 있어야 할 바탕. |
| L5 | 말뿐인 권고 규칙을 검사 가능한 강제 규칙으로 승격 | 핵심 운영 원칙. |
| L6 | signal → patch → verify → ack/rollback | 목표로 삼은 최소선. (신호 감지 → 수정 → 검증 → 반영 또는 되돌리기가 스스로 도는 단계) |
| L7 | 개인·프로젝트·플러그인·외부도구 연결(MCP)·외부 트렌드까지 하나의 운영체계로 | 궁극적으로 지향하는 지점. |
지켜야 할 운영 규칙을 13개 요구사항으로 못 박았다
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
완료를 선언하기 전에, '지시한 것이 실제 산출물로 나왔는가'를 확인하는 점검표를 반드시 통과해야 한다.
이미 깔려 있는 개인 공통 설정만 해도 거대한 실행 기반이다
workflow capsules
soft / trend / hard rules
event-time guards
validators & supervisors
native role surfaces
role execution prompts
state/memory/code/trace/wiki
browser/docs/sheets/decks
해법은 파일을 옮기는 게 아니라 관제탑을 얹는 것이다
이미 쓰고 있는 설정 폴더 ~/.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
루프 방식은 실패를 버리지 않고 자산으로 바꾸는 순환 구조다
Intake
Classify
Proposal
Drift
Verify
Rollback
Inject
위 7단계는 이렇게 돈다. 신호를 받아들이고(01), 어떤 범위의 변경인지 분류하고(02), 고칠 안을 만들고(03), 안전한지·설정이 어긋나지 않았는지 확인하고(04), 적용해 검증하고(05), 문제없으면 반영하고 문제가 있으면 되돌리고(06), 마지막으로 기록해 다음 작업에 다시 불러온다(07). 이 순환 규칙은 loopy-era-runtime-contract.md라는 계약 문서에 못 박아 뒀다. 여기서 핵심은, 중요한 규칙을 'AI가 알아서 기억하겠지' 수준에 맡기면 안 된다는 것이다. 규칙은 자동 검사 스크립트(hook)·실행 스크립트·검사기(validator)·완료 점검(completion audit) 중 하나로 눈에 보이게 관측될 때에만, 실제로 가로막는 강제 관문(HARD gate)이 된다.
적용은 9단계, 지금은 1~2단계까지 완료
완료 선언은 53개 검사를 모두 통과시켜 마무리했다
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 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 | 단어만 찾아 매기는 점수(grep 100점)의 한계를 넘어선다. |
| 06 | soft → checkable → HARD promotion | 되풀이되는 실수를, 실제로 가로막는 관문으로 바꾼다. |