hugh-kim.space / tech deep dive
Ecosystem Map

기술 축으로 해석한 AI Work OS

수집한 페이지들은 개별 블로그라기보다 하나의 운영체계를 서로 다른 각도에서 설명한다. 핵심은 컨텍스트를 아끼고, 작업을 분해하고, 기억을 남기고, 증거로 검증하고, 실패를 다음 규칙으로 되돌리는 구조다.

Token Economy

4축 토큰 압축 생태계

첨부 이미지의 다이어그램을 더 풀어쓴 구조다. 네 축은 모두 LLM context window를 덜 낭비하게 만드는 다른 경로다.

4축 토큰 압축 생태계 Input, CLI output, tool output, semantic code search가 중앙 LLM context window를 압축하는 구조 LLM Context Window 토큰 80-95% 절감 4축 동시 적용 시 AXIS 1 · INPUT Input Compression claw-compactor 파일 입력 · 긴 문서 · raw context -15~82% AXIS 2 · CLI OUTPUT CLI Output Compression RTK ← 여기 bash/test/build 출력 후처리 -80% AXIS 3 · TOOL OUTPUT Tool Output Sandboxing context-mode 도구 출력 격리 · 필요 시 회수 -98% AXIS 4 · CODE SEARCH Semantic Code Search semble_rs ← 여기 grep/cat/read 대체 · 관련 코드만 -40~93% RTK · semble_rs는 4축 중 2축에 해당, 나머지 2축은 별도 rule/도구로 활성
Axis 1

Input Compression

원본 문서와 파일을 LLM에 넣기 전에 압축한다. 질문 전에 재료를 정리하는 층이다.

Axis 2

CLI Output Compression

테스트, 빌드, bash 로그가 컨텍스트를 덮지 않도록 실행 결과를 압축한다.

Axis 3

Tool Output Sandboxing

모든 도구 결과를 대화 컨텍스트에 흘리지 않고 격리한다. 필요할 때만 핵심 결과를 회수한다.

Axis 4

Semantic Code Search

무작정 파일을 읽는 대신 의미 기반으로 관련 코드만 찾는다. 탐색 단계의 낭비를 줄인다.

AI Work OS

사이트 전체의 5대 기술 축

토큰 압축은 하위 생태계이고, hugh-kim.space 전체는 더 큰 작업 운영체계의 다섯 축으로 반복 수렴한다.

5대 기술 축으로 본 AI Work OS Personal AI Work OS 작업 · 기억 · 검증 · 개선을 묶는 운영체계 Claude Code → Codex/OMX 이식 AXIS A · HARNESS RUNTIME commands · skills · hooks 작업 방식을 파일과 규칙으로 고정 AXIS B · ORCHESTRATION manager · team · specialists 역할별 에이전트로 책임 분리 AXIS C · MEMORY / RETRIEVAL memory-bank · facts · recall 세션 기억을 장기 지식으로 전환 AXIS D · QA EVIDENCE GATE browser · expect · Codex review 완료 선언을 실제 증거로 검증 AXIS E · SELF-IMPROVEMENT loopy-era · self-improve 실패를 다음 실행 규칙으로 환류
Closed Loop

Loopy-Era 폐루프

이 사이트의 반복 메시지는 “실패를 기록하고, 규칙으로 바꾸고, 검증으로 닫는다”다.

1. 관측tool failure, QA fail, 사용자 correction, retry를 hook과 로그로 잡는다.
2. 신호화반복 가능한 문제를 pending self-improve signal로 변환한다.
3. 패치rules, skills, scaffold, validators를 수정한다.
4. 검증harness-report, loopy-era-eval, smoke, browser QA를 통과시킨다.
5. 유지/롤백개선이면 keep, 악화면 rollback 또는 discard한다.
Blog Pages

블로그 페이지별 상세 해설

각 카드는 페이지의 역할, 읽어야 하는 이유, 핵심 내용을 요약한다. 열어서 보면 더 자세한 설명이 나온다.

A. 전체 지도와 Claude Code 하네스

전체 허브index.html

사이트 전체 목차이자 Claude Code setup 인덱스.

  • 에이전트, 스킬, 플러그인, 훅, 저장소를 한곳에 모은다.
  • `Filesystem = Truth`, `Contract-First QA`, `Auto-Select` 같은 운영 철학을 전면에 둔다.
  • 처음 읽을 때 전체 지도를 잡는 페이지다.
Claude Code Harness Systemclaude-code-harness-system.html

Claude Code 위에 구축된 하네스 구조.

  • hook 이벤트와 self-improve pending 구조를 설명한다.
  • `loopy-era-eval`, `harness-report`, `qa-cycle` 연결을 보여준다.
  • false convergence 사례를 통해 “올바른 질문을 안 하면 100%도 거짓”이라는 메시지를 강조한다.
cc-sync Evolutioncc-sync-evolution.html

설정 백업 도구가 에이전트 운영체계로 확장된 기록.

  • 5개월, 536커밋의 진화 흐름을 다룬다.
  • agents, skills, hooks, memory-bank, user-proxy, self-improve가 누적된다.
  • `cc-sync-template`, `memory-bank`, `cc-sync` GitHub 링크가 핵심 근거다.
Orchestrator Evolutionorchestrator-evolution.html

manager-orchestrator가 어떻게 진화했는지 설명.

  • v1에서 v5까지 phase와 specialist 구조가 커진다.
  • 단순 지시문이 아니라 작업 프로토콜로 변해가는 과정을 보여준다.
  • 에스컬레이션과 역할 분리가 핵심이다.
/init-project 분석init-project-analysis.html

프로젝트 고유 패턴을 추출하는 초기화 스킬.

  • generic template 금지, 기존 `.claude/` 보존, 빌드/테스트 명령 검증을 강조한다.
  • 프로젝트마다 다른 DNA를 추출해 하네스에 주입하는 단계다.
  • 일반 `/init`보다 훨씬 깊은 코드베이스 분석을 목표로 한다.

B. Loopy-Era와 자가개선

Loopy-Era Architectureloopy-era-architecture.html

사이트의 철학적 중심.

  • 실수가 규칙으로 바뀌는 루프를 설명한다.
  • self-improve, HARD Gates, user-proxy QA가 맞물린다.
  • 프롬프트보다 운영 가능한 검증 루프가 중요하다는 메시지다.
Self-Evolving Systemself-evolving-system.html

자가진화 시스템의 구현 결과 요약.

  • hook, HARD 강제, 자동 개선 건수를 보여준다.
  • 사용자 불만과 실수 패턴을 규칙으로 바꾸는 흐름을 다룬다.
  • cross-session 학습이 핵심이다.
공개하기 어려운 이유self-evolving-analysis.html

하네스가 개인의 판단 기준으로 진화한다는 주장.

  • 도구는 복제 가능하지만 철학과 판단 기준은 복제하기 어렵다고 본다.
  • AI에게 “만들어줘”가 아니라 AI 시스템 자체를 설계해야 한다는 논지다.
  • 개인화된 하네스가 왜 DNA처럼 되는지 설명한다.
Loopy V2 Surface Gaploopy-v2-surface-gap.html

Loopy 명령어 표면 계층 보완 로드맵.

  • `/loopy:start`, `/loopy:resume`, `/loopy:status`, `/loopy:measure` 같은 명령 표면을 다룬다.
  • 기존 엔진과 겹치는 기능을 alias/표면 레이어로 정리하려 한다.
  • 사용자 경험 계층의 갭 분석이다.

C. Codex/OMX 이식과 실행 파이프라인

Codex Harness Systemcodex-harness-system.html

Codex-native 하네스의 실행 구조.

  • `start-harness.sh`부터 15단계 loop-era 파이프라인까지 다룬다.
  • `init-project`, `qa-scenario-gen`, `team-runtime`, `self-improve-worker`가 연결된다.
  • 프로젝트 프로파일이 QA 시나리오를 제어한다.
Codex Team x Init-Projectcodex-team-init-project-harness.html

Claude Code 하네스를 Codex/OMX로 옮기는 구조.

  • commands/hooks/agents/plugins와 skills/team/state/mailbox를 대응시킨다.
  • Memory Bank와 QA Evidence Gate가 이식 구조에서 어디에 위치하는지 보여준다.
  • “generic template 0개”라는 방향성을 강조한다.
Codex Loop Era L6codex-loop-era-l6.html

Codex 쪽 Practical L6 달성 조건.

  • 로그와 도구 사용이 구조화 이벤트로 남아야 한다.
  • project boundary와 global boundary 분리를 강조한다.
  • acceptance plane을 통과해야 성공으로 본다.
Start-Harness 분석start-harness-analysis.html

Codex 하네스 실행 진입점 분석.

  • start command chain, ralph-loop, team-runtime, self-improve-worker를 연결해 설명한다.
  • 14단계 파이프라인과 smoke test가 핵심이다.
  • 실제 실행 흐름을 이해하려면 가장 중요한 문서 중 하나다.
Codex QA Integrationcodex-integration.html

Codex를 별도 검증자로 붙이는 구조.

  • 단일 모델 blind spot을 다른 모델로 보완한다.
  • `.codex-review-passed` 같은 gate 파일을 사용한다.
  • 3중 강제 게이트와 에러 복구 전략을 다룬다.
User-Scope Loopy Harnesscodex-user-scope-loopy-harness.html

Codex user-scope 운영 계약.

  • Practical L6+ / L7-oriented 개인 AI Work OS를 목표로 한다.
  • memory-bank와 claude-code-site를 근거로 요구사항을 고정한다.
  • runtime contract 문서 성격이 강하다.

D. Memory Bank와 지식 시스템

Memory Bank Analysismemory-bank-analysis.html

장기 기억 시스템 분석.

  • archive, retrieval, fact, ontology, recall surface 계층으로 나눈다.
  • 세션 기억을 검색 가능한 장기 지식으로 바꾸는 구조다.
  • 단순 로그 저장보다 훨씬 적극적인 지식 운영을 지향한다.
Onboarding Guidecc-sync-onboarding.html

90일 사용 기록 기반 팀원 온보딩.

  • 작업 유형 분포, 자주 쓰는 스킬, MCP 서버를 정리한다.
  • Memory Bank 교차 분석 결과를 사람이 이해할 수 있게 바꾼 문서다.
  • 운영 기록이 온보딩 자료로 바뀌는 사례다.
Novel Builder × Memory-Banknovel-builder-memory-bank.html

장기 창작 컨텍스트 유지 구조.

  • manuscript, context folder, MCP runtime을 분리한다.
  • canon, persona, world, visual seed를 유지한다.
  • 장기 연재의 persona/visual drift를 막는 목적이다.
AX-Wikiax-wiki-analysis.html

LLM Knowledge Base 플랫폼 분석.

  • Raw 문서를 Wiki로 자동 컴파일한다.
  • Claude 멀티모델 Q&A와 위키링크 자동 생성을 다룬다.
  • Memory Bank와 비슷하게 “문서를 AI가 읽을 수 있는 구조”로 바꾸는 축이다.
LKB Case Studylkb-harness-case-study.html

Karpathy LKB 아이디어 구현 사례.

  • 글 한 편에서 요구사항을 추출해 CLI 도구로 구현한다.
  • self-improve가 누락 기능을 재발견하는 흐름이 중요하다.
  • 아이디어 → 하네스 → 구현 → 검증의 사례다.

E. QA, 완성 문제, 조직 확장

서비스 완성 문제service-completion-problem.html

AI가 끝에서 서비스를 완성하지 못하는 이유.

  • 요구사항 하향, 기능 삭제, 세부사항 누락, 에러 회피, 완성 선언 편향을 다룬다.
  • QA 게이트가 왜 필요한지 설명하는 문제 정의 문서다.
  • 하네스의 존재 이유를 가장 실용적으로 보여준다.
Harsh Criticharsh-critic.html

사용자 분노 패턴 기반 사전 검증.

  • 결과물을 사용자에게 보여주기 전에 가혹하게 검사한다.
  • Hook, Harsh Critic, Codex review의 3중 방어 구조다.
  • 품질 기준을 “친절한 리뷰”가 아니라 “사용자 분노 예방”으로 둔다.
Enterprise Complexityenterprise-harness-complexity.html

개인 하네스의 조직 확장 한계.

  • 50+ rules, 15+ hooks, 14단계 파이프라인의 복잡도를 다룬다.
  • 개인 기준의 user-proxy를 조직에서 누가 정하느냐가 핵심 문제다.
  • 기술보다 governance 문제가 커진다.
개인 하네스 복잡성enterprise-harness-personal.html

개인 하네스도 이미 복잡하다는 분석.

  • rules, hooks, pipeline inventory를 정량적으로 다룬다.
  • self-improve의 누적이 scaffold bloat를 만들 수 있음을 지적한다.
  • curation 단계가 필요하다는 문제의식이다.
분산 프로토콜 복잡도enterprise-harness-distributed.html

worker/task state가 추가하는 복잡도.

  • task state machine과 worker state machine을 다룬다.
  • heartbeat, stale state, network boundary가 문제를 키운다.
  • 개인 작업 루프가 분산 시스템으로 바뀔 때의 비용을 설명한다.
조직 확장 한계enterprise-harness-scaling.html

기술 문제가 조직 정치 문제로 바뀌는 지점.

  • self-improve가 다른 팀원의 워크플로우를 깨뜨릴 수 있다.
  • QA PASS 기준을 누가 정하는지가 핵심이다.
  • 개인 loopy-era를 조직으로 확장하는 것은 열린 문제라고 본다.

F. 외부 트렌드, 비교 분석, 사례

Trend Harvestertrend-harvester-analysis.html

외부 AI 트렌드를 하네스에 반영하는 엔진.

  • GitHub Trending, RSS, AI 구루 GitHub 프로필을 수집한다.
  • Phase 3.5 autoresearch judge와 harness-report keep/discard가 핵심이다.
  • 외부 세계를 시스템 개선 신호로 바꾸는 구조다.
Trend Harvest Logtrend-harvest-log.html

trend-harvester 적용 기록.

  • 110회차 누적, 1310건 스캔, 211건 적용 기록이 담긴다.
  • 외부 repo와 개념이 어떤 식으로 규칙화되는지 보여준다.
  • 가장 실증 데이터가 많은 페이지다.
Autoresearch 비교autoresearch-comparison.html

세 가지 자율 최적화 접근 비교.

  • Karpathy ML autoresearch, 범용 `/autoresearch`, autoresearch-skill을 비교한다.
  • 평가 메트릭, 인프라 의존성, 최적화 대상 범위가 핵심 비교축이다.
  • 실험 루프 설계의 차이를 이해하기 좋다.
Paperclip vs Loopy-Erapaperclip-vs-loop-era.html

AI 회사 모델과 자가개선 모델 비교.

  • 여러 AI를 회사처럼 조직하는 접근과 실수에서 학습하는 접근을 비교한다.
  • 오케스트레이션과 자가개선은 다른 문제라는 점을 강조한다.
  • Loopy-Era의 차별점을 이해하는 비교 문서다.
RTK vs semble_rsrtk-semble-rs-comparison.html

4축 토큰 압축 생태계의 원본 페이지.

  • Input, CLI output, Tool output, Semantic search 네 축을 설명한다.
  • RTK와 semble_rs는 이미 하네스에 흡수한 개념으로 해석한다.
  • 도구 설치보다 컨셉을 규칙으로 결정화하는 방향이다.
AI Agencyai-agency-analysis.html

AI 에이전시 플랫폼 아이디어 분석.

  • Next.js, Supabase, Anthropic Claude를 기반으로 한다.
  • AI가 견적, 미팅, 개발, 배포를 처리하는 흐름을 설명한다.
  • 하네스가 실제 서비스 자동화로 이어지는 예시다.
Claude Code Reverse Engineeringreverse-engineering.html

Claude Code CLI 구조 분석 시각화.

  • TypeScript/Bun/ESM 구조, 세션 메모리, MCP metadata를 다룬다.
  • 도구 내부 구조를 이해하려는 리버스 엔지니어링 문서다.
  • 하네스를 만드는 기반 지식으로 볼 수 있다.

G. 콘텐츠/생성 결과물

Blood Inheritanceblood-inheritance.html

장편소설 콘텐츠 페이지.

  • 하네스 설명보다는 생성/관리 대상 콘텐츠에 가깝다.
  • `novel-builder-memory-bank.html`과 연결하면 장기 컨텍스트 관리 필요성을 이해할 수 있다.
  • 스토리 원본을 AI 작업 체계가 다룰 수 있는 대상으로 보는 예시다.
OutBeck Landingoutbeck-landing.html

레스토랑 랜딩 페이지 생성물.

  • 핵심 하네스 문서라기보다 생성 결과물 샘플이다.
  • `__bundler/manifest`, `__bundler/template`, `text/babel`, ReactDOM 흔적이 있다.
  • 별도 웹 아티팩트 번들 결과물로 보인다.
Reading Strategy

어떻게 읽으면 좋은가

처음에는 모든 페이지를 순서대로 읽기보다, 축별로 묶어 읽는 게 낫다.

추천 순서: `index.html`로 전체 지도 → `loopy-era-architecture.html`로 철학 → `claude-code-harness-system.html`로 Claude Code 구현 → `memory-bank-analysis.html`로 장기 기억 → `codex-team-init-project-harness.html`로 Codex 이식 → `service-completion-problem.html`로 왜 필요한지 → `enterprise-harness-complexity.html`로 확장 한계.

핵심 질문은 “어떤 도구를 썼나?”가 아니라 “실패가 다음 규칙으로 회수되는가?”다.