Hugh Kim의 Claude Code 작업 환경 전체를 한 장의 지도처럼 보여주는 시작 페이지입니다.
일반인용 해석
이 페이지는 “내 AI 개발 작업실에는 어떤 도구들이 놓여 있는가”를 보여줍니다. 에이전트, 스킬, 플러그인, 훅 같은 말이 많이 나오지만, 쉽게 말하면 AI가 혼자 막 움직이지 않게 역할표, 작업 절차, 검사 규칙을 세팅해 둔 것입니다.
핵심은 대화창에서 즉흥적으로 지시하는 방식에서 벗어나, 파일과 규칙으로 반복 가능한 작업 환경을 만든다는 점입니다.
어려운 말 풀이
Agent특정 역할을 맡은 AI 작업자입니다. 예: 리뷰 담당, 프론트엔드 담당.
Skill반복 작업을 처리하는 사용 설명서나 절차서입니다.
Hook저장, 실행, 완료 같은 순간에 자동으로 작동하는 검사 장치입니다.
읽는 포인트
이 사이트를 처음 볼 때는 이 페이지에서 전체 도구 이름을 먼저 익히면 좋습니다.
`Filesystem = Truth`는 말보다 파일 상태를 기준으로 삼겠다는 뜻입니다.
`Contract-First QA`는 만들기 전에 합격 기준을 먼저 고정하겠다는 뜻입니다.
mapharnessclaude code
Claude Code를 단순한 코딩 채팅창이 아니라, 검사와 개선이 붙은 작업 시스템으로 만든 구조를 설명합니다.
일반인용 해석
보통 AI 코딩은 “이거 만들어줘”라고 말하고 결과를 확인하는 식입니다. 이 페이지는 그 사이에 자동 검사대와 기록 장치를 끼워 넣습니다. AI가 뭔가 만들면 훅이 보고, QA가 검사하고, 실패하면 다음 규칙으로 되돌립니다.
즉, AI를 더 똑똑하게 만드는 문서라기보다 AI가 허술하게 끝내지 못하게 주변 환경을 강하게 만드는 문서입니다.
어려운 말 풀이
HarnessAI 작업을 잡아주는 프레임입니다. 실행, 검사, 기록을 묶습니다.
False convergence겉으로는 성공처럼 보이지만 실제로는 잘못된 결론에 모인 상태입니다.
HARD check실패하면 그냥 경고가 아니라 작업을 막는 강한 검사입니다.
읽는 포인트
7개 스킬, 41개 hook, 36개 HARD 체크 같은 숫자는 시스템이 꽤 복잡하다는 신호입니다.
핵심 질문은 “AI가 답을 했는가”가 아니라 “검증 가능한 증거가 있는가”입니다.
이 페이지는 이후 Loopy-Era 문서들의 기술적 기반입니다.
qahooksself-improve
처음에는 설정을 백업하는 도구였던 `cc-sync`가 점점 개인 AI 운영체계로 커진 과정을 기록합니다.
일반인용 해석
처음에는 컴퓨터 설정을 동기화하는 작은 도구였는데, 쓰다 보니 작업 방식, 규칙, 기억, 검증 방식까지 같이 옮겨야 한다는 문제가 생겼습니다. 그래서 단순 백업 도구가 아니라 “내 AI 작업 습관 전체를 옮기는 시스템”으로 확장된 것입니다.
5개월 536커밋이라는 숫자는 한 번에 설계한 제품이 아니라 실제 사용 중 불편을 해결하며 자라난 시스템이라는 뜻입니다.
어려운 말 풀이
Sync여러 컴퓨터나 환경에 같은 설정을 맞추는 일입니다.
Template새 환경을 만들 때 출발점으로 쓰는 기본 세트입니다.
Cross-session한 번의 대화가 끝난 뒤 다음 대화까지 이어지는 흐름입니다.
읽는 포인트
`cc-sync`는 시각 템플릿 원본이 아니라 작업환경 동기화 계열의 근거로 보는 것이 맞습니다.
설정 백업에서 에이전트 시스템으로 확장된 흐름을 확인할 수 있습니다.
사이트 전체가 “도구보다 운영 체계”를 중시한다는 증거입니다.
evolutionsyncworkflow
AI 작업을 누가 나누고, 어떤 순서로 처리하게 할지 정하는 조율자 시스템의 진화 기록입니다.
일반인용 해석
복잡한 프로젝트를 한 AI에게 통째로 맡기면 자주 놓칩니다. 그래서 팀장 역할의 오케스트레이터가 작업을 나누고, 각 담당자에게 보내고, 위험하면 에스컬레이션합니다. 사람 조직의 PM 또는 테크리드 역할을 AI 작업에 넣은 것입니다.
이 페이지는 v1에서 v5로 갈수록 단순 지시문이 실제 작업 프로토콜로 변해가는 모습을 보여줍니다.
어려운 말 풀이
Orchestrator작업을 분배하고 순서를 정하는 조율자입니다.
Specialist프론트엔드, 백엔드, QA처럼 특정 분야만 맡는 담당자입니다.
Escalation현재 담당자가 해결하기 어려우면 더 높은 판단 단계로 넘기는 일입니다.
읽는 포인트
AI를 한 명의 천재로 보는 대신 여러 역할로 나눈다는 관점이 중요합니다.
역할이 많아질수록 조율 비용도 늘어난다는 점을 함께 봐야 합니다.
나중의 기업 확장 한계 문서와 연결됩니다.
orchestrationagentsroles
새 프로젝트를 시작할 때 AI가 그 프로젝트의 구조와 관습을 먼저 배우게 하는 초기화 절차입니다.
일반인용 해석
신입 개발자가 회사에 들어오면 먼저 코드 구조, 빌드 방법, 테스트 방법, 금지 규칙을 배웁니다. `/init-project`는 AI에게 그 온보딩을 시키는 명령입니다. 아무 프로젝트에나 맞는 일반 템플릿을 덮어씌우지 말고, 현재 프로젝트의 성격을 먼저 읽으라는 뜻입니다.
그래서 이 페이지의 핵심은 “AI가 멋대로 일반적인 방식으로 만들지 않게 하는 것”입니다.
어려운 말 풀이
Project DNA그 프로젝트만의 폴더 구조, 코딩 스타일, 테스트 관습입니다.
Generic template어디에나 맞는 척하지만 실제 프로젝트와 안 맞을 수 있는 기본 양식입니다.
Pipeline여러 작업을 정해진 순서로 통과시키는 절차입니다.
읽는 포인트
이 페이지는 “처음 분석을 잘해야 뒤 작업이 덜 망가진다”는 주장입니다.
기존 `.claude/` 보존, 빌드/테스트 명령 검증 같은 실무 장치가 중요합니다.
Codex 쪽 `init-project` 이식 문서와 함께 읽으면 좋습니다.
onboardingproject scantemplates
실패를 그냥 넘기지 않고, 다음 실행을 고치는 규칙으로 되돌리는 자가개선 철학의 중심 문서입니다.
일반인용 해석
사람도 실수한 뒤 체크리스트를 고치면 다음에는 덜 실수합니다. Loopy-Era는 AI 작업에도 그 구조를 넣자는 생각입니다. AI가 실패하면 그 실패를 기록하고, 반복 가능한 문제인지 판단하고, 규칙이나 검사 도구를 바꿉니다.
중요한 점은 “AI가 알아서 더 똑똑해진다”가 아니라 “시스템이 실수를 놓치지 않고 되먹임한다”입니다.
어려운 말 풀이
Closed loop결과가 다시 원인 쪽으로 돌아가 다음 행동을 바꾸는 구조입니다.
Self-improve실패나 불만을 다음 규칙 개선으로 바꾸는 작업입니다.
User-proxy QA실제 사용자의 기준을 흉내 내서 결과물을 먼저 검사하는 역할입니다.
읽는 포인트
이 문서는 사이트의 철학적 중심입니다.
프롬프트보다 운영 가능한 검증 루프가 중요하다는 메시지를 봐야 합니다.
HARD Gates, self-improve, user-proxy QA가 함께 돌아가야 의미가 있습니다.
loopy-eraclosed loopself-improve
Loopy-Era 철학이 실제 hook, HARD 규칙, 자동 개선 기록으로 구현된 상태를 보여줍니다.
일반인용 해석
이 페이지는 “좋은 생각” 수준을 넘어 실제로 몇 개의 검사 장치와 개선 기록이 있는지 보여주는 운영 리포트입니다. 사용자가 화냈던 패턴, AI가 자주 빼먹는 행동, 반복되는 실수를 규칙으로 바꾸는 구조가 핵심입니다.
쉽게 말해 AI 작업실에 붙어 있는 경고문과 자동 체크리스트가 계속 늘어나고 있다는 내용입니다.
어려운 말 풀이
Hook특정 순간에 자동 실행되는 감시 또는 검사 코드입니다.
HARD enforcement지키지 않으면 진행을 막는 강제 규칙입니다.
Cross-session learning이번 대화에서 배운 것을 다음 대화에도 적용하는 구조입니다.
읽는 포인트
숫자 자체보다 “불만이 규칙으로 변환된다”는 흐름을 봐야 합니다.
실패 학습과 효과 검증이 함께 있어야 자가개선이라고 부를 수 있습니다.
하네스가 개인화될수록 공개하기 어려운 이유와 연결됩니다.
hooksautomationlearning
도구 코드는 공유할 수 있어도, 그 도구가 담고 있는 개인의 판단 기준은 쉽게 복제되지 않는다는 글입니다.
일반인용 해석
요리 도구를 똑같이 사도 같은 맛이 안 나는 것처럼, AI 하네스도 코드만 복사한다고 같은 결과가 나오지 않습니다. 왜냐하면 좋은 결과와 나쁜 결과를 가르는 기준, 반복해서 화났던 부분, 선호하는 작업 방식이 개인마다 다르기 때문입니다.
이 페이지는 하네스가 시간이 지날수록 사용자의 습관과 판단을 담은 개인 시스템이 된다는 점을 설명합니다.
어려운 말 풀이
Personal DNA사용자만의 품질 기준, 싫어하는 실수, 선호하는 작업 흐름입니다.
Philosophy무엇을 좋은 결과로 볼지에 대한 판단 기준입니다.
Git clone problem코드를 복사했지만 사용 맥락이 없어 제대로 작동하지 않는 문제입니다.
읽는 포인트
“공개 가능한 것은 코드, 공개하기 어려운 것은 판단 기준”이라는 구분이 핵심입니다.
하네스는 도구라기보다 오랜 사용 기록의 결정체로 보는 것이 맞습니다.
팀이나 기업으로 확장할 때 왜 어려워지는지도 이 관점에서 이해됩니다.
personalizationjudgmentsystem design
이미 있는 Loopy 엔진 위에 사용자가 다루기 쉬운 명령어 표면을 보강하려는 로드맵입니다.
일반인용 해석
엔진은 있는데 운전대와 계기판이 부족한 상황에 가깝습니다. 내부적으로는 self-improve 루프가 돌아가지만, 사용자가 `/loopy:start`, `/loopy:status` 같은 명령으로 쉽게 시작하고 확인하려면 표면 계층이 필요합니다.
이 문서는 새 엔진을 만들기보다 이미 있는 기능을 더 잘 보이게 정리하는 작업에 가깝습니다.
어려운 말 풀이
Surface layer내부 기능을 사용자가 쉽게 쓰도록 만든 버튼, 명령어, 화면입니다.
Alias복잡한 명령을 짧고 기억하기 쉬운 이름으로 부르는 방식입니다.
Gap analysis현재 상태와 원하는 상태 사이의 빈틈을 찾는 작업입니다.
읽는 포인트
기능 자체보다 사용자가 어떻게 조작하고 상태를 볼지가 핵심입니다.
엔진과 UX 표면은 다른 문제라는 점을 보여줍니다.
하네스가 커질수록 명령 체계 정리가 중요해집니다.
ux layercommandsroadmap
Claude Code에서 하던 하네스 구조를 Codex 환경에서도 돌릴 수 있게 만든 실행 구조입니다.
일반인용 해석
Claude Code용으로 만든 작업 공장을 Codex라는 다른 환경으로 옮기는 문서입니다. 단순히 명령어 이름만 바꾸는 것이 아니라, 시작 명령, 팀 실행, QA 시나리오, self-improve worker까지 다시 연결합니다.
이 페이지를 보면 “AI 작업 운영체계”가 특정 도구 하나에만 묶이지 않게 하려는 방향을 볼 수 있습니다.
어려운 말 풀이
Codex-nativeCodex 환경의 방식에 맞게 직접 구현했다는 뜻입니다.
start-harness.sh하네스 전체를 시작하는 셸 스크립트 진입점입니다.
QA scenario기능이 제대로 되는지 확인하는 사용자 흐름 테스트입니다.
읽는 포인트
15단계 파이프라인은 Codex 쪽 작업 흐름의 뼈대입니다.
`init-project`, `qa-scenario-gen`, `team-runtime`이 어떻게 연결되는지 봐야 합니다.
이 문서는 Codex/OMX 계열 문서들의 중심입니다.
codexpipelineruntime
Claude Code의 commands, hooks, agents, plugins를 Codex/OMX의 skills, team, state 구조로 대응시키는 이식 설계입니다.
일반인용 해석
한 회사의 업무 매뉴얼을 다른 회사 시스템으로 옮기는 일과 비슷합니다. 원래 있던 부서명, 결재선, 체크리스트를 새 회사의 용어와 도구에 맞춰 다시 배치해야 합니다.
여기서 중요한 것은 “기능 이름이 같나”가 아니라, 기억, 검증, 역할 분배, 프로젝트 초기화가 새 환경에서도 같은 역할을 하느냐입니다.
어려운 말 풀이
Migration기존 시스템을 다른 환경으로 옮기는 작업입니다.
State현재 작업이 어디까지 진행됐는지 나타내는 상태 정보입니다.
Mailbox여러 에이전트가 주고받는 메시지 큐 또는 전달함입니다.
읽는 포인트
Claude Code와 Codex의 장단점을 비교하는 부분이 중요합니다.
`generic template 0개`는 프로젝트별 맞춤 분석을 중시한다는 뜻입니다.
Memory Bank와 QA Gate가 새 구조에서 어디에 놓이는지 확인하면 됩니다.
migrationomxinit-project
Codex 하네스가 어느 정도 성숙한 자가개선 시스템 수준에 도달했는지 평가하는 문서입니다.
일반인용 해석
L6라는 말은 성숙도 등급처럼 보면 됩니다. 이 페이지는 Codex 쪽 하네스가 단순 자동화가 아니라, 로그를 남기고, 프로젝트 경계를 지키고, 강제 규칙을 적용하고, 개선 worker를 돌리는 수준까지 왔다고 주장합니다.
쉽게 말하면 “그냥 편리한 스크립트 모음”에서 “자기 상태를 알고 검사까지 하는 작업 시스템”으로 올라갔다는 평가입니다.
어려운 말 풀이
L6자가개선 하네스의 성숙도를 나타내는 내부 등급 표현입니다.
Structured log나중에 분석하기 좋게 정해진 형식으로 남긴 기록입니다.
Acceptance plane작업이 합격했는지 판단하는 최종 검증 층입니다.
읽는 포인트
경고만 하는 규칙과 실제로 차단하는 규칙의 차이를 봐야 합니다.
프로젝트별 경계와 전역 설정 경계를 나누는 점이 실무적으로 중요합니다.
L6 주장이 실제 검증 절차와 연결되어 있는지 확인하며 읽으면 됩니다.
maturityl6codex
Codex 하네스가 실제로 어떻게 시작되고 어떤 단계를 통과하는지 보는 실행 입구 문서입니다.
일반인용 해석
하네스 전체가 복잡하다면 `start-harness.sh`는 전원 버튼과 같습니다. 이 스크립트를 통해 어떤 명령이 켜지고, 어떤 루프가 돌고, 어떤 smoke test가 실행되는지 확인할 수 있습니다.
이 페이지는 철학보다 실제 배선도에 가깝습니다. 어떤 순서로 일이 흘러가는지 보고 싶을 때 중요합니다.
어려운 말 풀이
Shell script터미널에서 여러 명령을 순서대로 실행하는 파일입니다.
Smoke test큰 테스트 전에 시스템이 최소한 켜지는지 보는 빠른 검사입니다.
Worker백그라운드에서 특정 작업을 계속 처리하는 실행자입니다.
읽는 포인트
14단계 파이프라인은 실제 운영 순서를 이해하는 데 중요합니다.
신호 수집, LLM 패치 적용, 검증이 한 흐름으로 묶입니다.
추상 문서가 아니라 실행 진입점 분석이라는 점에서 가치가 있습니다.
entrypointshellsmoke test
Claude Code 작업 결과를 Codex가 다시 검토하게 해서 한 모델의 blind spot을 줄이는 구조입니다.
일반인용 해석
한 사람이 만든 보고서를 다른 사람이 검토하면 놓친 부분을 잡을 수 있습니다. 이 페이지는 Claude Code가 만든 결과를 Codex가 별도로 검토하는 식의 이중 검증을 설명합니다.
같은 AI라도 모델이 다르면 잘 보는 부분과 못 보는 부분이 다르기 때문에, 두 번째 눈으로 쓰는 것입니다.
어려운 말 풀이
Blind spot한 모델이 반복해서 놓치는 약점입니다.
Gate file검증을 통과했음을 파일로 남겨 다음 단계 진행을 허용하는 장치입니다.
Cross review다른 모델이나 역할이 결과를 다시 검사하는 방식입니다.
읽는 포인트
`.codex-review-passed` 같은 파일은 말뿐인 승인보다 강한 증거입니다.
3중 강제 게이트는 AI가 검증을 건너뛰지 못하게 하는 장치입니다.
단일 모델 의존의 위험을 줄이는 실용적 문서입니다.
qacodex reviewgate
사용자 전체 환경에 걸쳐 Codex 하네스를 개인 AI Work OS로 맞추려는 요구사항 문서입니다.
일반인용 해석
프로젝트 하나에서만 잘 작동하는 자동화가 아니라, 사용자의 여러 프로젝트와 장기 기억을 모두 아우르는 개인 작업 시스템을 만들겠다는 문서입니다. 그래서 단순 기능 목록보다 운영 계약과 요구사항 ID가 중요하게 나옵니다.
쉽게 말해 “내 모든 개발 작업에서 같은 품질 기준과 기억 체계를 쓰자”는 방향입니다.
어려운 말 풀이
User-scope특정 프로젝트가 아니라 사용자 전체 환경에 적용되는 범위입니다.
Runtime contract실행 중 반드시 지켜야 하는 규칙과 기대 동작의 계약입니다.
Requirement ID요구사항을 추적하기 위해 붙이는 고유 번호입니다.
읽는 포인트
프롬프트가 아니라 운영체계라는 문구가 핵심입니다.
Memory Bank와 claude-code-site를 근거 자료로 삼는 점을 봐야 합니다.
개인용 시스템을 장기 운영하려면 요구사항 추적이 필요하다는 주장입니다.
user scoperequirementswork os
AI 작업에서 사라지기 쉬운 세션 기억을 장기 지식으로 바꾸는 구조를 설명합니다.
일반인용 해석
AI와 대화하다 보면 앞에서 결정한 내용을 다음 세션에서 잊어버립니다. Memory Bank는 중요한 결정, 프로젝트 사실, 반복 실수, 문맥을 저장해 다음 작업에서 다시 꺼내 쓰게 만드는 지식 창고입니다.
단순히 대화 로그를 쌓는 것이 아니라, 나중에 검색하고 연결해서 쓸 수 있도록 정리하는 것이 핵심입니다.
어려운 말 풀이
Archive원본 기록을 보존하는 저장소입니다.
Retrieval필요한 기억을 다시 찾아오는 과정입니다.
Ontology지식 사이의 관계를 정리한 구조입니다.
읽는 포인트
이 페이지는 “AI가 기억하지 못한다”는 문제에 대한 답입니다.
archive, fact, recall surface 같은 계층을 구분해서 봐야 합니다.
Loopy-Era가 실패를 규칙으로 바꾸려면 이런 기억층이 필요합니다.
memoryretrievalknowledge
최근 90일 작업 기록을 바탕으로 새로운 사람이 Hugh의 작업 환경을 이해하도록 만든 온보딩 가이드입니다.
일반인용 해석
새 팀원이 들어왔을 때 “우리는 어떤 프로젝트를 하고, 어떤 도구를 자주 쓰고, 어떤 흐름으로 일하는가”를 설명하는 문서입니다. 흥미로운 점은 사람이 손으로 쓴 소개서가 아니라 작업 기록과 Memory Bank를 분석해 만든 가이드라는 점입니다.
즉, 운영 기록이 곧 교육 자료가 되는 사례입니다.
어려운 말 풀이
Onboarding새 사람이 환경과 규칙에 적응하도록 돕는 과정입니다.
MCPAI가 외부 도구나 데이터에 연결되는 표준 인터페이스 계열입니다.
Usage history실제로 어떤 작업을 많이 했는지 남은 사용 기록입니다.
읽는 포인트
Memory Bank가 단순 저장소를 넘어 설명 자료까지 만든다는 점을 봐야 합니다.
작업 유형 분포와 자주 쓰는 스킬은 실제 운영 습관의 증거입니다.
팀 확장 시 문서화 비용을 줄이는 방식으로 볼 수 있습니다.
onboardingmemory bankstudio
장편소설처럼 긴 창작물의 세계관, 인물, 시각적 기준을 Memory Bank로 유지하는 구조입니다.
일반인용 해석
긴 소설이나 웹툰을 만들 때는 인물 성격, 세계관, 사건, 그림체가 중간에 흔들리면 안 됩니다. 이 페이지는 원고, 컨텍스트 폴더, 실행 런타임을 분리해서 AI가 긴 창작 작업에서도 같은 설정을 유지하게 하는 방법을 설명합니다.
개발뿐 아니라 창작에서도 장기 기억이 중요하다는 사례입니다.
어려운 말 풀이
Canon작품 안에서 공식으로 인정되는 설정입니다.
Persona drift인물 성격이 시간이 지나며 흔들리는 현상입니다.
Visual seed이미지 스타일을 유지하기 위한 기준 정보입니다.
읽는 포인트
Memory Bank가 코드 프로젝트뿐 아니라 창작 프로젝트에도 적용됩니다.
원고와 컨텍스트와 런타임을 분리하는 3계층 구조를 보면 됩니다.
`Blood Inheritance` 페이지와 연결해 읽으면 사례가 분명해집니다.
creativememorylong context
원본 문서를 AI가 읽고 연결하기 쉬운 위키형 지식 베이스로 자동 변환하는 플랫폼 분석입니다.
일반인용 해석
회사 문서나 연구 노트가 여기저기 흩어져 있으면 AI도 사람도 찾기 어렵습니다. AX-Wiki는 원본 문서를 위키 페이지처럼 정리하고, 관련 링크를 만들고, 질문 답변이 가능하게 만드는 구조입니다.
쉽게 말하면 “AI가 읽기 좋은 사내 위키를 자동으로 만드는 도구”에 가깝습니다.
어려운 말 풀이
LKBLLM Knowledge Base, AI가 사용할 수 있게 정리된 지식 베이스입니다.
Wiki link문서끼리 서로 연결되는 내부 링크입니다.
Lint문서나 코드의 형식 문제를 자동으로 검사하는 일입니다.
읽는 포인트
Memory Bank와 비슷하지만, 더 문서 플랫폼에 가까운 성격입니다.
Raw 문서가 Wiki로 컴파일되는 흐름을 보면 됩니다.
AI Q&A가 문서 구조화와 연결되는 점이 핵심입니다.
wikilkbknowledge base
Karpathy의 LLM Knowledge Base 아이디어를 실제 CLI 도구로 구현한 과정을 보여주는 사례 연구입니다.
일반인용 해석
좋은 아이디어를 읽고 “괜찮네”에서 끝나는 것이 아니라, 요구사항을 뽑고, 도구를 만들고, 테스트하고, 빠진 기능을 다시 찾아내는 과정을 보여줍니다. 이 사이트가 말하는 하네스가 실제 구현까지 어떻게 이어지는지 보여주는 좋은 사례입니다.
핵심은 아이디어가 실행 가능한 체크리스트와 코드로 바뀌는 과정입니다.
어려운 말 풀이
Case study실제 사례를 통해 방법을 설명하는 문서입니다.
CLI tool터미널에서 명령어로 쓰는 도구입니다.
Coverage테스트가 코드나 기능을 얼마나 검증하는지 나타내는 지표입니다.
읽는 포인트
아이디어 추출에서 구현, 검증까지 한 흐름으로 봐야 합니다.
self-improve가 누락 기능을 재발견하는 부분이 중요합니다.
하네스가 추상 철학이 아니라 생산 파이프라인이라는 증거입니다.
case studyimplementationlkb
AI가 데모는 잘 만들지만 실제 서비스 완성 단계에서 자주 실패하는 이유를 정리합니다.
일반인용 해석
AI는 처음 80%를 빠르게 만들지만, 마지막 20%에서 요구사항을 빼먹거나, 기능을 조용히 삭제하거나, 에러를 우회하고, 스스로 완료했다고 말하는 문제가 생깁니다. 이 페이지는 바로 그 문제를 정면으로 다룹니다.
그래서 하네스와 QA 게이트가 필요한 이유를 가장 실용적으로 보여주는 문서입니다.
어려운 말 풀이
Requirement lock처음 정한 요구사항을 중간에 마음대로 줄이지 못하게 잠그는 장치입니다.
Feature deletion detector기능이 몰래 사라졌는지 감지하는 검사입니다.
Completion bias실제로 덜 끝났는데 끝났다고 말하려는 경향입니다.
읽는 포인트
이 문서를 읽으면 QA Gate가 왜 필요한지 바로 이해됩니다.
AI 개발의 위험은 코딩 능력 부족보다 완료 판단의 약함에서 자주 나옵니다.
실제 서비스 작업을 맡길 때 가장 먼저 참고할 페이지입니다.
completionqarequirements
결과물을 사용자에게 보여주기 전에, 실제 사용자의 엄격한 반응을 흉내 내서 사전 검사하는 구조입니다.
일반인용 해석
친절한 리뷰는 놓치는 게 많습니다. Harsh Critic은 사용자가 실제로 불만을 가질 법한 부분을 미리 세게 검사하는 역할입니다. 버튼이 안 맞거나, 요구사항이 빠졌거나, 대충 끝낸 흔적이 있으면 사용자가 보기 전에 잡아내려는 장치입니다.
품질 기준을 “괜찮아 보임”이 아니라 “사용자가 화낼 일을 줄임”으로 둡니다.
어려운 말 풀이
User feedback simulator실제 사용자의 반응을 미리 흉내 내는 검사자입니다.
SOFT to HARD처음엔 권고였던 검사를 나중에는 강제 차단으로 바꾸는 흐름입니다.
Pre-flight check결과 공개 전에 하는 사전 점검입니다.
읽는 포인트
Hook, Harsh Critic, Codex Review의 3중 방어 구조를 보면 됩니다.
이 문서는 사용자의 불만을 시스템 설계 입력으로 쓰는 예시입니다.
자가개선이 감정적 피드백까지 규칙화한다는 점이 흥미롭습니다.
criticqualityprecheck
개인에게 잘 맞는 하네스를 기업 조직으로 확장할 때 왜 근본적으로 어려워지는지 설명합니다.
일반인용 해석
혼자 쓰는 작업 규칙은 내 기준에 맞추면 됩니다. 하지만 회사에서는 여러 사람, 여러 팀, 서로 다른 품질 기준이 충돌합니다. 하네스가 강력할수록 누가 규칙을 정하고 누가 예외를 허용할지 문제가 커집니다.
이 페이지는 기술 문제가 어느 순간 조직 운영 문제로 바뀐다는 점을 강조합니다.
어려운 말 풀이
N² complexity사람이나 팀이 늘어날수록 관계와 충돌이 훨씬 빠르게 늘어나는 현상입니다.
Governance규칙을 누가 정하고 어떻게 관리할지에 관한 운영 체계입니다.
Enterprise개인이나 작은 팀이 아니라 조직 규모의 환경입니다.
읽는 포인트
개인 하네스와 기업 하네스는 같은 문제처럼 보여도 본질이 다릅니다.
규칙 수가 많아질수록 규칙 간 충돌도 커집니다.
기술보다 의사결정 구조가 병목이 될 수 있습니다.
enterprisegovernancescaling
개인용 하네스조차 이미 규칙, 훅, 파이프라인이 많아져 복잡해진다는 분석입니다.
일반인용 해석
처음에는 작은 체크리스트였지만, 실수를 막기 위해 규칙을 계속 추가하면 어느새 규칙끼리 부딪히고 관리가 어려워집니다. 개인용 시스템도 방치하면 너무 무거워질 수 있다는 경고입니다.
즉, 자가개선은 무조건 많이 쌓는 것이 아니라 주기적으로 정리해야 합니다.
어려운 말 풀이
Scaffold bloat초기 세팅이나 보조 구조가 과도하게 커져 오히려 부담이 되는 상태입니다.
O(n²) interaction규칙이 늘수록 규칙끼리 영향을 주는 조합이 급격히 늘어나는 문제입니다.
Curation쌓인 규칙을 골라내고 정리하는 관리 작업입니다.
읽는 포인트
자가개선에는 축적만큼 정리도 필요하다는 점이 핵심입니다.
개인 시스템의 복잡도를 정량적으로 보려는 시도가 있습니다.
하네스가 성공할수록 새로운 관리 문제가 생깁니다.
complexitycurationrules
여러 worker와 task가 네트워크 경계를 넘어 움직이면 상태 관리가 급격히 어려워진다는 분석입니다.
일반인용 해석
혼자 일할 때는 내 머릿속 상태만 알면 됩니다. 하지만 여러 작업자와 여러 작업이 동시에 움직이면 누가 무엇을 맡았고, 어디서 멈췄고, 죽은 작업인지 기다리는 작업인지 계속 추적해야 합니다.
이 페이지는 AI 에이전트 시스템이 커지면 결국 분산 시스템 문제가 된다는 점을 설명합니다.
어려운 말 풀이
State machine작업이 가질 수 있는 상태와 상태 이동 규칙입니다.
Heartbeat작업자가 살아 있는지 주기적으로 보내는 신호입니다.
Stale state실제 상황과 맞지 않게 오래된 상태 정보입니다.
읽는 포인트
worker와 task의 상태가 따로 움직이면 조합이 복잡해집니다.
네트워크 경계는 실패 가능성을 크게 늘립니다.
에이전트 마켓플레이스나 분산 팀 런타임을 생각할 때 중요한 경고입니다.
distributedstateworkers
개인 Loopy-Era를 조직으로 확장할 때 user-proxy와 QA 기준이 충돌한다는 문서입니다.
일반인용 해석
개인 시스템에서는 “내가 싫어하는 결과”를 기준으로 harsh critic을 만들 수 있습니다. 하지만 조직에서는 사용자, 디자이너, 개발자, PM, 경영진의 기준이 다를 수 있습니다. 누구의 기준을 AI가 대변해야 하는지가 어려워집니다.
이 페이지는 AI 시스템 확장의 끝에는 결국 사람들의 합의 문제가 남는다고 봅니다.
어려운 말 풀이
User-proxy사용자의 기준을 대신 적용하는 검사자 역할입니다.
Brook's Law사람을 더 넣는다고 프로젝트가 꼭 빨라지지 않는다는 소프트웨어 프로젝트 법칙입니다.
QA PASS 기준무엇을 통과로 볼지 정하는 합격선입니다.
읽는 포인트
기술적 자동화가 조직적 합의를 대신할 수 없다는 점이 핵심입니다.
Self-improve가 다른 사람의 업무 흐름을 깨뜨릴 수 있습니다.
기업용 하네스는 사람과 권한 설계까지 포함해야 합니다.
organizationqa criterialimits
외부 AI 트렌드를 수집하고, Loopy-Era 철학에 맞는 것만 시스템 개선 후보로 걸러내는 엔진입니다.
일반인용 해석
새로운 AI 도구와 아이디어가 계속 나오지만 다 따라가면 산만해집니다. Trend Harvester는 GitHub Trending, RSS, 주요 개발자 프로필을 보면서 쓸 만한 것만 후보로 뽑고, 하네스에 반영할지 판단하는 구조입니다.
쉽게 말해 “외부 세상의 좋은 아이디어를 내 작업 시스템으로 가져오는 필터”입니다.
어려운 말 풀이
Harvester외부 자료를 주기적으로 수집하는 도구입니다.
Autoresearch judge수집한 아이디어가 쓸 만한지 평가하는 자동 판단 단계입니다.
Keep/discard반영할지 버릴지 결정하는 판정입니다.
읽는 포인트
수집보다 필터링과 검증이 더 중요합니다.
외부 트렌드가 바로 도입되지 않고 하네스 철학 필터를 통과합니다.
자가개선이 내부 실패뿐 아니라 외부 변화까지 먹는 구조입니다.
trendresearchfilter
Trend Harvester가 실제로 무엇을 수집하고 무엇을 반영했는지 보여주는 누적 기록입니다.
일반인용 해석
앞의 Trend Harvester가 엔진 설명이라면, 이 페이지는 운행 기록입니다. 몇 번 수집했고, 몇 건을 스캔했고, 몇 건을 적용했는지 숫자로 남깁니다. 그래서 주장만이 아니라 실제 반복 실행의 흔적을 볼 수 있습니다.
이 사이트에서 가장 실증 데이터가 강한 페이지 중 하나입니다.
어려운 말 풀이
Run log반복 실행마다 남긴 기록입니다.
PASS정해진 검증 기준을 통과했다는 표시입니다.
Approval pending자동 반영 전 사람 또는 추가 판단을 기다리는 상태입니다.
읽는 포인트
1310건 스캔, 211건 적용 같은 수치는 시스템이 실제로 돌았다는 근거입니다.
어떤 외부 repo가 어떤 규칙이나 아이디어로 바뀌었는지 보면 됩니다.
자동화의 신뢰성은 로그와 검증 기록에서 나옵니다.
logevidenceevolution
자율 최적화 또는 자동 연구를 구현하는 세 가지 접근을 비교합니다.
일반인용 해석
Autoresearch는 AI가 스스로 실험하고 더 나은 방법을 찾게 하는 접근입니다. 하지만 대상이 머신러닝 모델인지, 범용 작업인지, 특정 스킬 개선인지에 따라 설계가 달라집니다. 이 페이지는 그 차이를 비교표처럼 정리합니다.
즉, “자동 연구”라는 같은 말 안에도 서로 다른 종류가 있다는 점을 설명합니다.
어려운 말 풀이
AutoresearchAI가 후보를 만들고 실험하고 평가하며 개선을 찾는 흐름입니다.
Metric좋아졌는지 나빠졌는지 판단하는 숫자 기준입니다.
Optimization target무엇을 개선하려는지에 해당하는 대상입니다.
읽는 포인트
Karpathy식 ML autoresearch와 범용 작업 autoresearch는 목적이 다릅니다.
자동 개선에는 반드시 평가 지표가 필요합니다.
Loopy-Era의 self-improve와 비교해 읽으면 차이가 분명해집니다.
autoresearchcomparisonoptimization
여러 AI를 회사처럼 조직하는 접근과, 실수에서 학습하는 Loopy-Era 접근을 비교합니다.
일반인용 해석
Paperclip식 접근은 AI들을 부서처럼 나눠 일을 시키는 쪽에 가깝고, Loopy-Era는 작업 중 생긴 실수를 다음 규칙으로 고치는 쪽에 가깝습니다. 둘 다 자동화를 말하지만 초점이 다릅니다.
이 페이지는 “에이전트를 많이 둔다”와 “실패에서 배운다”가 같은 문제가 아니라는 점을 보여줍니다.
어려운 말 풀이
Zero-human company사람 개입을 최소화하고 AI들이 회사처럼 일하는 모델입니다.
Orchestration여러 역할을 나누고 조율하는 일입니다.
Feedback loop결과를 보고 다음 행동을 바꾸는 되먹임 구조입니다.
읽는 포인트
AI를 많이 배치하는 것과 품질이 누적 개선되는 것은 별개입니다.
Loopy-Era의 차별점은 에이전트 수가 아니라 실패 학습입니다.
오케스트레이션 문서들과 함께 읽으면 좋습니다.
comparisonorchestrationloopy-era
첨부 이미지의 원본 맥락입니다. RTK와 semble_rs를 4축 토큰 압축 생태계 안에서 해석합니다.
일반인용 해석
AI에게 일을 시키면 파일, 로그, 검색 결과가 너무 많이 쌓여 중요한 내용을 놓칩니다. 이 페이지는 그 낭비를 네 방향에서 줄이는 방법을 설명합니다. RTK는 터미널 출력 줄이기에 가깝고, semble_rs는 관련 코드만 찾는 의미 검색에 가깝습니다.
중요한 점은 도구를 설치하는 것보다 그 도구가 가진 원리를 하네스 규칙으로 흡수하는 쪽에 있습니다.
어려운 말 풀이
TokenAI가 읽고 처리하는 글자 조각 단위입니다. 많을수록 비용과 혼란이 늘어납니다.
Context windowAI가 한 번에 참고할 수 있는 작업 공간입니다.
Semantic search단어 일치가 아니라 의미가 가까운 코드를 찾는 방식입니다.
읽는 포인트
4축 다이어그램은 이 페이지를 이해하기 위한 핵심 그림입니다.
RTK와 semble_rs는 전체 생태계 중 2축에 해당합니다.
토큰 절감은 비용 절감뿐 아니라 판단 품질 유지와도 연결됩니다.
tokenrtksemble_rs
AI가 견적, 미팅, 개발, 배포까지 처리하는 소프트웨어 에이전시 플랫폼 아이디어를 설명합니다.
일반인용 해석
고객이 아이디어를 내면 AI가 요구사항을 정리하고, 견적을 만들고, 개발하고, 배포까지 돕는 서비스 모델입니다. 하네스가 내부 개발 도구라면, 이 페이지는 그 자동화 능력을 실제 비즈니스 서비스로 바꾸는 상상도에 가깝습니다.
Next.js, Supabase, Claude 같은 기술 이름은 이 서비스를 만들기 위한 재료입니다.
어려운 말 풀이
Next.js웹사이트와 웹앱을 만드는 프레임워크입니다.
Supabase로그인, 데이터베이스, 저장소 기능을 제공하는 백엔드 플랫폼입니다.
Deployment만든 서비스를 실제 인터넷에서 쓸 수 있게 올리는 일입니다.
읽는 포인트
이 페이지는 하네스 자체보다 하네스가 만들 수 있는 서비스 방향입니다.
견적부터 배포까지 전 과정 자동화가 핵심 흐름입니다.
실제 제품화 가능성과 검증 장치가 함께 필요하다는 점을 생각하며 읽으면 됩니다.
serviceagencyproduct
Claude Code CLI의 내부 구조를 분석하고 시각화한 기술 문서입니다.
일반인용 해석
사용자는 보통 Claude Code를 겉에서만 씁니다. 이 페이지는 안쪽 구조를 뜯어보며 세션, 도구 호출, 메모리, MCP 연결이 어떻게 움직이는지 이해하려는 문서입니다.
하네스를 잘 만들려면 기반 도구가 어떤 구조로 작동하는지 알아야 하므로, 이 문서는 배경 기술 지식에 해당합니다.
어려운 말 풀이
Reverse engineering이미 만들어진 도구의 내부 작동 방식을 분석하는 일입니다.
CLI마우스 화면 대신 터미널 명령으로 쓰는 프로그램입니다.
ESM/Bun자바스크립트 실행과 모듈 구조에 관련된 기술입니다.
읽는 포인트
하네스를 만드는 사람에게 필요한 내부 구조 이해 문서입니다.
MCP metadata와 세션 메모리 같은 연결 지점을 보면 됩니다.
일반 독자는 세부 구현보다 “기반 도구를 이해하고 확장하려는 시도”로 읽으면 충분합니다.
reverse engineeringclaude codearchitecture
하네스 기술 문서가 아니라 장편소설 콘텐츠 페이지입니다.
일반인용 해석
이 페이지는 AI 작업 시스템을 설명하기보다, 그 시스템이 다룰 수 있는 창작 콘텐츠의 예시로 보는 편이 맞습니다. 장편소설은 인물, 사건, 세계관이 길게 이어지기 때문에 Memory Bank 같은 장기 기억 구조가 왜 필요한지 보여주는 좋은 대상입니다.
`Novel Builder x Memory-Bank`와 연결해서 읽으면 기술적 의미가 생깁니다.
어려운 말 풀이
Long-form content한 번에 끝나지 않고 장기간 이어지는 긴 콘텐츠입니다.
Continuity앞뒤 설정과 사건이 모순 없이 이어지는 성질입니다.
Context management긴 작업에서 필요한 배경 정보를 유지하는 일입니다.
읽는 포인트
기술축으로 보면 Memory Bank의 사용 사례입니다.
긴 창작물에서는 persona drift와 설정 누락이 큰 문제입니다.
하네스가 코드뿐 아니라 콘텐츠 제작에도 적용될 수 있음을 보여줍니다.
contentnovelmemory
레스토랑 랜딩 페이지 형태의 생성 결과물입니다. 핵심 하네스 문서라기보다 산출물 샘플에 가깝습니다.
일반인용 해석
이 페이지는 Hugh Kim Space의 하네스 철학을 설명하는 글이라기보다, AI 또는 번들러로 생성한 웹 페이지 결과물로 보입니다. 원문 안에 ReactDOM, Babel, bundler manifest 같은 흔적이 있어, 별도 웹 아티팩트 생성 과정을 거친 페이지로 해석됩니다.
사이트 안에 포함된 “만들어진 결과물” 예시로 보면 됩니다.
어려운 말 풀이
Landing page제품이나 장소를 소개하고 예약, 문의 같은 행동을 유도하는 첫 페이지입니다.
Bundler여러 코드 파일을 브라우저가 읽을 수 있는 하나의 결과물로 묶는 도구입니다.
ReactDOM/BabelReact 웹 화면을 브라우저에서 실행하기 위한 기술 흔적입니다.