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 웹 화면을 브라우저에서 실행하기 위한 기술 흔적입니다.
읽는 포인트
템플릿 원본보다는 생성된 웹 아티팩트 흔적으로 보는 것이 맞습니다.
하네스 설명 페이지들과 성격이 다르다는 점을 구분해야 합니다.
AI가 실제 웹 페이지를 생성한 샘플로 활용할 수 있습니다.
artifactlanding pagegenerated
AI 자동 생성 해설 · 검수 전 초안
Claude Code가 작업 유형을 스스로 판단해 전용 실행 흐름을 런타임에 직접 작성하는 6가지 패턴과 3가지 실패 방어 방식을 다룬 글입니다.
일반인용 해석
기존 AI 작업 방식은 모든 경우에 똑같은 도구 배치를 쓰는 범용 공장 라인과 같았습니다. Dynamic Workflows는 AI가 작업 성격을 먼저 파악한 뒤, 그 작업에 꼭 맞는 라인을 즉석에서 설계해 실행하는 방식입니다. 마치 요리사가 메뉴마다 재료 배치와 조리 순서를 다르게 세팅하는 것과 비슷합니다.
이 글이 중요한 이유는, AI가 스스로 설계한 실행 흐름이 '부분 완료를 완료라고 속이는 것'이나 '목표를 잊어버리는 것' 같은 흔한 오작동을 구조적으로 막는 방식까지 다루기 때문입니다.
어려운 말 풀이
Dynamic Workflow사전에 고정된 절차가 아니라, 작업이 시작될 때 그 작업에 맞게 실행 순서와 에이전트 구성을 즉석에서 만들어내는 방식입니다.
HarnessAI 에이전트가 일관된 품질로 작업을 완수하도록 감싸는 검증·제어 구조를 말합니다.
Adversarial Verification결과물을 만든 에이전트와 별개의 에이전트가 반박하는 방식으로 결과의 허점을 찾아내는 검증입니다.
읽는 포인트
6가지 패턴(분류 라우팅·병렬 합성·적대적 검증 등)이 각각 어떤 상황에 쓰이는지 확인하면 전체 구조가 이해됩니다.
laziness·bias·goal drift 세 가지 실패 모드를 정적 훅(항상 동작)과 동적 워크플로우(선택 동작)로 이중 방어하는 점이 핵심입니다.
비용 게이트를 통해 복잡한 워크플로우가 정말 필요한 작업에만 추가 연산을 쓰도록 강제하는 경제성 원칙도 눈여겨볼 만합니다.
dynamic-workfloworchestrationfailure-modes
AI 자동 생성 해설 · 검수 전 초안
인스타그램 건축 작가 ziteun_vin의 이미지를 Three.js로 절차적 3D 장면으로 재구성한 브라우저 기반 공간 연구입니다.
일반인용 해석
건축 사진을 보면서 저 공간을 직접 걸어 다닐 수 있으면 어떨까 하는 상상을 코드로 실현한 프로젝트입니다. 별도의 3D 모델 파일 없이 프로그래밍 코드만으로 형태, 구조, 조명 순서로 장면을 쌓아 올리며, 브라우저에서 드래그와 줌으로 네 가지 공간을 직접 탐색할 수 있습니다.
건축 이미지를 단순히 감상하는 것을 넘어 체험 가능한 3D 공간으로 재해석한다는 점에서, 창작과 기술이 만나는 방식을 잘 보여주는 사례입니다.
어려운 말 풀이
WebGL웹 브라우저 안에서 직접 3D 그래픽을 구동할 수 있게 해주는 기술 표준입니다.
Three.jsWebGL을 더 쉽게 다룰 수 있도록 만들어진 JavaScript 라이브러리입니다.
절차적 모델링3D 파일을 불러오는 대신 코드로 형태를 직접 계산해 생성하는 방식입니다.
읽는 포인트
외부 3D 에셋 파일 없이 코드만으로 장면 전체를 완성하는 절차적 접근 방식을 확인할 수 있습니다.
매크로 형태, 구조, 조명 세 단계로 장면을 쌓는 방법론이 건축 드로잉의 작업 흐름과 유사합니다.
Claude Code로 제작했다는 점에서 AI 보조 개발이 실제 창작 작업에 어떻게 활용되는지 살펴볼 수 있습니다.
Three.jsWebGL건축시각화
AI 자동 생성 해설 · 검수 전 초안
AI 에이전트 개별 검사 기능은 플랫폼이 이미 세 가지 방식으로 지원하고 있었으며, 89개 에이전트 중 단 하나도 그 기능을 쓰지 않은 채택의 부재가 진짜 문제였습니다.
일반인용 해석
공장에 전체 감시 카메라는 설치해 놓았지만 각 조립 라인마다 개별 카메라를 달지 않은 것과 비슷한 상황입니다. 플랫폼은 에이전트 하나하나에 검사를 거는 방법을 세 가지나 제공하고 있었는데, 실제 감시 장치는 그 방법 중 하나도 사용하지 않고 있었습니다. 직접 실험으로 로그 증거를 하나씩 남기고 나서야 비로소 그 사실을 확인할 수 있었습니다.
AI 시스템이 복잡해질수록 개별 역할마다 따로 검사를 거는 일이 얼마나 중요한지 보여주는 사례입니다.
어려운 말 풀이
하네스(harness)AI가 작업을 완료했다고 거짓으로 보고하지 못하도록 증거를 강제하는 감시 장치입니다.
훅(hook)파일 저장이나 코드 배포 같은 특정 순간에 자동으로 실행되는 검사 스크립트입니다.
분배기(dispatcher)설정 훅 하나가 에이전트 종류를 읽어 각각에 알맞은 검사로 연결해 주는 중앙 라우터입니다.
읽는 포인트
플랫폼이 지원하는 세 가지 방식(frontmatter 훅, agent_type 식별자, SubagentStart 필터)이 각각 어떤 상황에서 작동하는지 따라가 보면 됩니다.
89개 에이전트 파일을 전혀 건드리지 않고도 에이전트별 강제 검사를 얻는 분배기 구조의 원리가 이 글의 핵심입니다.
Codex 적대 리뷰 13라운드를 거치며 결함이 어떻게 수렴하는지, 완전한 방어가 불가능한 부분은 어떻게 처리하는지 과정이 담겨 있습니다.
에이전트훅하네스
AI 자동 생성 해설 · 검수 전 초안
동일한 설정 기반 위에서 돌아가는 자동 이슈 워커와 대화형 세션이 구조적으로 갈리는 지점은 정확히 세 곳이며, 실제 사고 3건은 모두 대화형 쪽의 약점에서 발생했다는 실측 분석입니다.
일반인용 해석
같은 회사 규정을 읽는 두 직원을 상상해 보세요. 한 명은 상사와 실시간으로 대화하며 일하고, 다른 한 명은 지시 메모 하나를 받아 혼자 처리하고 끝나면 자리를 뜹니다. 둘 다 같은 규칙을 따르지만, 사무실 직원은 동료의 파일이 책상에 섞이거나 작업 메모가 넘치는 상황에 노출됩니다.
이 글은 바로 그 구조적 차이를 분석한 것입니다. 자동화된 워커 쪽이 오히려 더 안전했던 이유를 설계 원리로 설명합니다.
어려운 말 풀이
user scope사용자 계정 전체에 공통으로 적용되는 훅·규칙·스킬 설정 묶음으로, 대화형과 워커 모두 동일하게 로드합니다.
spawn현재 작업 도중 자식 작업을 새로 띄우는 것으로, 부모의 환경을 물려받는 방식과 완전히 분리되는 방식이 서로 다른 위험을 만들어 냅니다.
attestation코드 검사를 통과했다는 서명 도장으로, 코드 상태가 바뀌면 효력이 사라져 게이트가 다시 막히게 됩니다.
읽는 포인트
user scope는 완전히 동일하고, 분기는 project scope 획득 방식, 스폰 계층, 상태 신원 세 곳에서만 난다는 구조를 먼저 파악하면 읽기가 쉬워집니다.
사고 3건(스폰 실패, ledger 오염, attestation 무효화)이 각각 어느 분기점의 약점과 대응하는지 대조해 보세요.
스펙을 문장으로 적을 수 있으면 워커, 그렇지 않으면 대화형이라는 결론이 실용적인 선택 기준을 제시합니다.
headless workersession isolationstate identity
AI 자동 생성 해설 · 검수 전 초안
기업용 시스템 개발에 통상 25명·24개월이 드는 일을, 1인이 AI 하네스를 활용해 6개월 만에 완수한 실측 결과를 수치와 함께 정리한 보고서입니다.
일반인용 해석
보통 큰 회사 시스템을 만들 때는 여러 직무의 전문가 수십 명이 수년을 씁니다. 이 보고서는 개발자 한 명이 AI와 자동 검사 장치를 활용해 그 일을 혼자 6개월 만에 마친 기록입니다. 개발자가 직접 코드를 짜는 대신, AI가 일하고 코드가 스스로 검증하며, 사람은 기준을 정하고 승인만 합니다. 밤에도 시스템이 자동으로 돌아가고, 오류가 나면 코드가 막고 고치는 방식이 핵심입니다.
이 방식으로 23억 원이 드는 일을 0.8억 원에 처리해 22억 원을 절감했다고 실측 수치와 함께 보고합니다.
어려운 말 풀이
하네스(Harness)AI의 행동을 감시하고 검증하는 자동화 장치로, 실수가 발생해도 자동으로 차단합니다.
Man-Month(M·M)한 명이 한 달 동안 처리할 수 있는 업무량 단위로, 177 M·M은 1명 기준 177개월분의 일입니다.
게이트(Gate)특정 조건을 충족하지 못하면 작업 진행을 자동으로 막는 코드 검문소입니다.
읽는 포인트
22억 절감의 근거인 177 M·M 산정 방식과 단가 계산 과정을 확인해 보세요.
새벽 무인 구간에서 시스템이 자동으로 결함을 감지하고 수정한 실제 로그 기록이 담겨 있습니다.
장비를 늘릴수록 흡수 가능한 업무량이 선형으로 늘어난다는 확장 전망도 주목할 부분입니다.
AI하네스개발생산성자동화
AI 자동 생성 해설 · 검수 전 초안
한 사람이 AI 검증 체계(하네스)를 활용하여 정규 25명이 177개월에 걸쳐 처리할 기업 시스템 구축 업무를 6개월 만에 완료한 실측 사례를 공개한 글입니다.
일반인용 해석
보통 대규모 소프트웨어 프로젝트는 수십 명의 전문가가 2년 가까이 매달려야 합니다. 이 글은 한 사람이 AI가 일하고 코드가 자동으로 검증하는 구조를 미리 만들어, 혼자서 25명분의 업무를 6개월 안에 해낸 실제 기록입니다. 직원이 모두 퇴근한 밤에도 시스템이 스스로 코드를 고치고 검증하며 3시간 넘게 돌아갔다는 점이 핵심입니다.
AI를 단순 도구로 쓰는 것과, AI가 일하고 코드가 품질을 강제하는 운영 체계를 갖추는 것은 전혀 다른 단계라는 것을 이 사례가 보여 줍니다.
어려운 말 풀이
하네스(Harness)AI의 결과물을 사람 대신 코드가 자동으로 검증하여 오류가 외부로 나가지 못하게 막는 장치입니다.
Man-Month(인월)한 사람이 한 달 동안 처리할 수 있는 업무량의 단위로, 177 M·M은 25명이 약 7개월씩 일할 분량입니다.
게이트(Gate)비밀키 포함 커밋이나 미검증 완료 선언처럼 위험한 행동을 코드 수준에서 물리적으로 차단하는 검문소입니다.
읽는 포인트
밤새 사람 입력 없이 3시간 동안 수리 커밋 12건이 자동으로 이뤄진 실제 기록을 눈여겨보시면 좋습니다.
29.5배 레버리지가 나온 구조적 이유, 즉 병렬 처리와 핸드오프 제거가 어떻게 맞물리는지 확인해 보세요.
같은 실수가 반복될 때 규칙으로 굳히고 차단 코드로 승격하는 자가개선 고리의 작동 방식이 흥미롭습니다.
AI하네스자동화레버리지
AI 자동 생성 해설 · 검수 전 초안
1명이 운영하는 AI 개발 하네스가 25명 규모의 팀과 동일한 범위의 일을 6개월 만에 완료한 실측 수치를 담은 글입니다.
일반인용 해석
보통 소프트웨어 개발은 기획자, 개발자, 검수자 등 수십 명이 각자 역할을 나눠 진행합니다. 이 글은 AI 에이전트들이 그 역할을 대신해 하루 24시간 쉬지 않고 분석, 설계, 개발, 검증, 리뷰를 반복하는 시스템을 실제 기록으로 보여줍니다. 사람이 잠든 새벽에도 수정과 검증이 자동으로 이루어진 로그가 그대로 남아 있습니다.
24개월 견적이 6개월 실측으로 줄어든 수치가 담겨 있어, AI 도구의 실제 생산성을 가늠해 볼 수 있는 드문 사례입니다.
어려운 말 풀이
AI 하네스에이전트들이 서로 채점, 검증, 수정을 자동으로 수행하도록 묶어 놓은 증거 기반 개발 장치입니다.
실행 게이트정해진 조건을 충족하지 못하면 다음 단계로 넘어가지 못하게 막는 자동 검문 지점입니다.
적대 리뷰결과물을 만든 에이전트와 별도의 에이전트가 서로 반박하며 교차로 검토하는 방식입니다.
읽는 포인트
코드를 만드는 AI와 채점하는 AI를 의도적으로 분리했다는 설계 원칙을 주목하세요.
업무시간 밖 커밋이 전체의 71%라는 수치가 자동화 수준을 구체적으로 보여줍니다.
캔버스 저작도구를 이틀, 178커밋으로 완성한 사례는 속도 주장의 직접 증거로 제시됩니다.
AI 하네스개발 자동화1인 개발
AI 자동 생성 해설 · 검수 전 초안
1인 AI 하네스 시스템이 24시간 쉬지 않고 작동하며, 25명 개발팀 24개월 분량의 작업을 6개월 만에 완료한 실제 운영 사례를 소개합니다.
일반인용 해석
보통 25명이 2년에 걸쳐 해야 하는 개발 프로젝트를 혼자서 6개월 만에 끝낼 수 있다면 어떨까요. 이 글은 AI 자동화 시스템을 직접 구축하고 실제로 가동한 기록입니다. 사람은 하루 8시간, 주 5일만 일하지만 이 시스템은 하루 24시간 일주일 내내 멈추지 않고 돌아갑니다. 잠든 사이에도 코드 검토, 수정, 동기화가 자동으로 이루어집니다.
소규모 팀이나 1인 개발자에게 시간과 인력의 한계를 어떻게 넘을 수 있는지를 구체적인 수치로 보여주는 사례입니다.
어려운 말 풀이
AI 하네스여러 AI 에이전트를 규칙과 검증 장치로 묶어 자동으로 돌아가게 만든 개발 운영 체계입니다.
실행 게이트정해진 조건을 통과하지 못하면 다음 단계로 넘어가지 못하도록 막는 자동 검사 장치입니다.
적대 리뷰결과물을 만든 AI와 별개의 AI가 그 결과물을 반박하듯 검토해 오류를 찾아내는 방식입니다.
읽는 포인트
코드를 만드는 AI와 채점하는 AI를 분리한 구조 원칙을 살펴보시기 바랍니다.
업무시간 밖 커밋 비율 71%라는 실측 수치가 이 시스템의 실제 운영 규모를 보여 줍니다.
사람의 판단 개입을 단 2번으로 줄인 방법이 어떻게 가능했는지 확인해 보시기 바랍니다.
AI하네스개발자동화24시간운영
AI 자동 생성 해설 · 검수 전 초안
한 사람이 AI 운영체계(하네스)를 구축해 6개월 만에 정규 25명 분량인 177 man-month의 업무를 혼자 처리한 실측 기록입니다.
일반인용 해석
보통 AI는 필요할 때 챗봇에 질문하는 도구로 씁니다. 이 글은 그 수준을 넘어, AI가 스스로 일하고 코드가 결과를 자동으로 검증하는 운영체계를 구축한 사례입니다. 경비원이 한 명이어도 곳곳에 자동 잠금장치와 감시 카메라가 설치돼 있으면 혼자서도 큰 건물을 지킬 수 있는 것과 같은 원리입니다.
AI 전환이 챗봇 도입이 아니라 일하는 구조 자체를 바꾸는 것임을 구체적인 숫자와 구조도로 설명합니다.
어려운 말 풀이
하네스(Harness)AI가 일하고 코드가 자동으로 검증·차단하며, 사람은 기준 설정과 최종 승인만 담당하는 운영 틀입니다.
man-month(MM)한 사람이 한 달 동안 처리할 수 있는 업무량을 나타내는 단위로, 프로젝트 규모를 비교할 때 씁니다.
HARD 게이트규칙을 충족하지 않으면 커밋이나 배포 자체가 코드로 물리적으로 차단되는 강제 검문 장치입니다.
읽는 포인트
177 man-month 산정 근거를 확인하면 어떤 직무가 얼마나 소요됐는지 구체적으로 파악할 수 있습니다.
실수가 규칙이 되고 규칙이 차단 코드로 승격되는 자가개선 루프 구조가 이 글의 핵심입니다.
AI 도구를 쓰는 것과 AI 운영체계를 갖추는 것의 차이를 이 글이 실측 수치로 보여줍니다.
AI 하네스자동화레버리지
AI 자동 생성 해설 · 검수 전 초안
이슈 보드의 할 일을 AI가 밤새 구현하고 세 단계 관문을 통과한 것만 완료로 인정하는 무인 자동화 감시 구조입니다.
일반인용 해석
공장 자동화 라인처럼 AI 일꾼들이 할 일 목록에서 작업을 집어 코드를 작성하고, 세 단계 검사를 통과한 것만 완료 칸으로 이동합니다. 사람이 직접 카드를 끌지 않아도 되고, AI가 완료했다고 주장해도 증거가 없으면 통과되지 않습니다. 실패하면 자동으로 처음으로 돌아가 재시도하고, 반복되는 실수는 스스로 규칙으로 정리해 다음 작업에 반영합니다.
AI가 거짓말하지 못하도록 증거를 강제로 요구하는 구조라는 점이 이 하네스의 핵심입니다.
어려운 말 풀이
폐루프실행과 측정, 개선이 사람 개입 없이 스스로 반복되는 순환 구조입니다.
훅(hook)코드 저장이나 배포 직전에 자동으로 실행되는 검사기로, 조건을 채우지 못하면 작업을 강제로 차단합니다.
온디맨드항상 켜두는 것이 아니라 필요할 때만 켜서 사용하는 방식입니다.
읽는 포인트
규칙 107개, 스킬 210개, 에이전트 89개, 훅 52개로 이루어진 4층 구조가 어떻게 맞물리는지 살펴보세요.
BS 파이프라인이 현재 상시 가동이 아닌 온디맨드 상태라는 솔직한 현황 공개가 인상적입니다.
막을 수 있는 것과 막을 수 없는 것을 명확히 구분해 한계를 정직하게 드러내는 방식에 주목해 보세요.
AX하네스폐루프자동화QA게이트
AI 자동 생성 해설 · 검수 전 초안
Claude Code의 실행 방식은 흔히 2가지로 알려져 있지만, 공식 문서를 전부 읽으면 3가지임을 확인할 수 있으며, 직접 만들어 쓰던 많은 장치들의 공식 대체 수단이 이미 존재했다는 내용입니다.
일반인용 해석
Claude Code는 터미널에서 쓰는 AI 코딩 도우미입니다. 이 도구를 쓰는 방식은 사람이 직접 대화하는 방식, 명령 하나를 던지고 결과만 받는 방식, 그리고 뒤에서 알아서 돌아가게 두는 방식, 이렇게 셋으로 나뉩니다. 많은 개발자들이 두 가지만 있는 줄 알고 세 번째 방식을 직접 조립해 써 왔습니다.
공식 문서를 꼼꼼히 읽으면 이미 만들어진 기능이 많다는 사실을 발견하게 됩니다. 이 글은 그 발견을 꼼꼼히 정리한 현장 보고서입니다.
어려운 말 풀이
헤드리스 모드화면 없이 명령 하나를 넣으면 결과만 돌려주는 실행 방식으로, 자동화 스크립트에서 주로 씁니다.
훅(hook)특정 순간에 자동으로 실행되도록 미리 등록해 둔 작은 스크립트로, 저장하거나 커밋할 때 검사를 자동으로 돌리는 식으로 활용합니다.
재귀 가드훅이 세션을 띄우고 그 세션이 다시 훅을 부르는 무한 반복을 막는 안전 장치입니다.
읽는 포인트
세 번째 실행 모드인 백그라운드 세션이 어떤 상황에서 필요한지 확인해 보면 좋습니다.
직접 만든 도구 여섯 가지에 공식 대체 수단이 있었다는 대목은 문서를 꼼꼼히 읽는 것이 왜 중요한지 보여 줍니다.
체크포인트와 git 되돌리기의 차이를 설명하는 표가 두 모드의 성격을 가장 명확하게 구분해 줍니다.
Claude Code실행 모드자동화
AI 자동 생성 해설 · 검수 전 초안
AI 개발 자동화 시스템의 주간 성능 지표를 파일에서 자동으로 읽어 실시간으로 보여주는 대시보드입니다.
일반인용 해석
자동차 계기판처럼, AI 개발 자동화 시스템이 얼마나 잘 작동하고 있는지를 한눈에 볼 수 있게 정리한 화면입니다. 측정값이 없을 때는 0이나 적당한 숫자로 채우지 않고 'NA(측정 없음)'로 솔직하게 표기하는 원칙을 따릅니다.
시스템이 스스로 얼마나 잘 판단하고 있는지(자율성), 규칙은 몇 개인지, 지난 7일간 비용은 얼마인지 등을 시계열로 쌓아두고 있습니다.
어려운 말 풀이
리플레이 정합(replay)과거 작업을 다시 실행했을 때 결과가 동일하게 나오는 비율로, 100%이면 완전히 재현 가능하다는 의미입니다.
append-only기존 데이터를 수정하거나 삭제하지 않고 새 데이터를 뒤에 덧붙이기만 하는 방식입니다.
autonomy(자율성 점수)시스템이 사람 개입 없이 스스로 판단하고 처리하는 비율을 나타내는 지표입니다.
읽는 포인트
'fail-loud' 원칙이 흥미롭습니다. 측정값이 없으면 없다고 그대로 표기해 거짓 안정감을 주지 않습니다.
자율성 점수 0.38은 이 측정 시점에 처음 기록된 초기값으로, 앞으로 추세를 볼 수 있는 시작점입니다.
7일간 커밋 235건, 비용 2만8천여 토큰 등 실제 운영 숫자가 공개되어 시스템 규모를 가늠할 수 있습니다.
telemetrydashboardfail-loud
AI 자동 생성 해설 · 검수 전 초안
AI가 거짓말하지 못하도록 증거를 강제하는 D365 하네스를 1년간 운용하고, 동일 스크립트로 재측정해 숫자로 정직하게 공개한 연간 결산 리포트입니다.
일반인용 해석
AI 도구가 "다 했다"고 거짓말하지 못하도록 증거를 강제하는 감시 장치를 1년간 운용한 결과를 표로 정리했습니다. 52주 계획 중 44주는 실제 측정 데이터가 없었지만, 없는 데이터를 가짜로 채우지 않고 솔직하게 빈칸으로 남겼습니다.
숫자가 보여주는 변화와 숫자만으로는 알 수 없는 원인을 철저히 구분한 점이 이 글의 핵심입니다.
어려운 말 풀이
하네스(harness)AI가 실제로 작업을 수행했음을 증거로 강제하는 감시 체계입니다.
예측타당성측정 지표가 실제 성과를 얼마나 잘 예측하는지 검증하는 방법론적 개념입니다.
Goodhart 위험어떤 지표를 목표로 삼는 순간 그 지표가 원래의 의미를 잃는 현상입니다.
읽는 포인트
없는 데이터를 가짜로 채우지 않는 'fail-loud' 원칙이 실제로 어떻게 적용되는지 살펴보세요.
지표가 안정적일수록 오히려 상관관계를 측정하기 어렵다는 방법론적 역설에 주목하세요.
숫자와 해석을 별도로 분리하는 방식이 자기평가의 신뢰성에 어떤 영향을 주는지 생각해보세요.
하네스재측정데이터정직성
AI 자동 생성 해설 · 검수 전 초안
새 모델이 출시될 때마다 낡은 가정을 자동으로 걷어내도록, Fable 5.1이 직접 자기 절차서 40개를 91분 안에 검토하고 수정한 과정을 정리한 글입니다.
일반인용 해석
AI에게 일을 시킬 때 쓰는 지시 설명서에는 이전 모델 기준으로 쓴 주의문이 남아 있습니다. 이전 모델은 이 작업을 못 하니 사람이 확인하라는 식의 문장들입니다. 새 모델이 나오면 그런 낡은 문장을 직접 읽고 수정하게 하는 것이 이 글의 핵심입니다. Fable 5.1이 91분 동안 40개 항목을 살피고 고쳤습니다.
스스로를 업데이트하는 구조를 만들어 두면, 새 모델이 나올 때마다 사람이 일일이 검토하지 않아도 된다는 점에서 의미가 있습니다.
어려운 말 풀이
하네스(harness)AI가 작업을 완료했다고 거짓 주장하지 못하도록 증거를 강제하는 감시 장치 묶음입니다.
결정론 재측정편집 전후에 같은 스크립트를 돌려 같은 숫자가 나오는지 확인하는 검증 방식입니다.
적대 반박변경 결과가 올바르다는 주장을 일부러 반박해 보는 독립 검증 단계입니다.
읽는 포인트
AI가 자기 절차서를 스스로 점검하고 수정하는 자가개선 구조가 어떻게 작동하는지 살펴보면 됩니다.
사람이 읽고 판단하던 기준 92건을 스크립트 판정으로 바꾼 흐름이 이번 패스의 핵심 변화입니다.
새 모델 출시 때마다 이 과정을 자동으로 실행하도록 배선해 두었다는 점이 흥미롭습니다.
자가개선하네스모델업그레이드
AI 자동 생성 해설 · 검수 전 초안
AI 작업마다 증거를 요구하는 새 도구 Fable-ish를, 기존 강제 검증 체계를 그대로 유지한 채 그 위에 얇은 층으로 덧붙이는 통합 방식을 결정한 과정입니다.
일반인용 해석
Fable-ish는 AI에게 일을 작은 덩어리로 나누게 하고, 각 덩어리마다 실제로 됐다는 증거가 나올 때까지 되돌아가 확인시키는 지시 묶음입니다. 탄탄한 감시 체계가 이미 있을 때, 새 도구로 기존 것을 갈아치우는 대신 위에 얹는 방식이 합리적임을 보여줍니다. 기존 강제 규칙은 낮추지 않은 채, 작업 단위마다 증거 장부만 추가하는 최소한의 통합입니다.
기존 자산을 버리지 않고 새 기능을 더하는 방식이 AI 도구 설계에서 얼마나 중요한지를 실제 사례로 보여줍니다.
어려운 말 풀이
하네스(harness)AI가 마음대로 행동하지 못하도록 증거와 규칙으로 감시하는 통제 장치입니다.
강제 계약(hard contract)정해진 조건을 통과하지 못하면 다음 단계로 넘어가지 못하게 막는 규칙입니다.
마이크로 루프(micro-loop)작업 하나하나마다 증거를 확인하고 되돌아가는 작은 검증 반복 단위입니다.
읽는 포인트
새 도구와 기존 체계를 능력별로 비교해 통합 방식을 결정하는 사고 과정이 핵심입니다.
작업마다 증거 장부를 붙이는 마이크로 루프가 두 시스템을 잇는 실질적인 이음새입니다.
완료 기준을 됐다는 느낌이 아니라 기계가 읽을 수 있는 증거로 강제한다는 점이 특징입니다.
AI검증하네스통합설계
AI 자동 생성 해설 · 검수 전 초안
AI 감시 시스템이 사람 개입 없이 1년치 60단계 계획을 16시간 만에 자동 완주한 실험 결과를 기록한 글입니다.
일반인용 해석
거짓 완료를 막는 감시 장치(하네스)가 있어서, AI가 "다 했다"고 말하려면 반드시 증거를 내야 합니다. 이 시스템이 1년치 계획 60단계를 16시간 동안 자동으로 밟아 나갔으며, 각 단계를 건너뛰거나 속이면 프로그램이 바로 멈춥니다.
이 글은 AI가 스스로 계획을 실행할 때 완료를 어떻게 검증할 수 있는지를 실제로 구현한 사례입니다.
어려운 말 풀이
하네스(harness)AI가 거짓으로 완료를 선언하지 못하도록 증거를 강제하는 자동화 감시 장치입니다.
exit 2프로그램이 종료할 때 남기는 숫자로, 2는 조건 미충족으로 인한 차단을 의미합니다.
상태 기계진행 상태를 파일에 저장해 두어, 중단 후 다시 시작해도 멈춘 지점부터 이어갈 수 있는 구조입니다.
읽는 포인트
각 단계가 순서 검사, 출처 확인, 검사 재실행 세 겹을 통과해야만 완료로 인정되는 구조를 살펴보면 됩니다.
결과를 느낌 대신 수치로 기록하고, 측정하지 못한 값은 N/A로 그대로 남기는 방식이 인상적입니다.
v1 실행에서 겪은 마찰이 v2 계획의 근거로 연결되는 되먹임 구조가 이 글의 핵심입니다.
자동화검증하네스
AI 자동 생성 해설 · 검수 전 초안
하루에 6개 코드 저장소에서 124번의 변경을 쌓으며, 다른 회사 AI의 적대 리뷰를 통과해야만 배포할 수 있다는 규율 하나로 서로 다른 문제들을 마무리한 작업 기록입니다.
일반인용 해석
하루에 6개의 서로 다른 프로젝트를 동시에 진행하면서, 완성된 결과물을 다른 회사의 AI에게 일부러 트집 잡도록 요청했습니다. 에러 분류, 화면 버그, 보안 허점 등 제각각 다른 문제가 발견됐고, 치명적인 결함이 0건이 될 때까지 수정을 반복했습니다.
사람 눈만으로는 놓치기 쉬운 결함을 다른 관점의 AI가 잡아 내는 구조를 6개 분야에 동일하게 적용했다는 점이 이 글의 핵심입니다.
어려운 말 풀이
적대 리뷰다른 AI에게 일부러 결함을 찾도록 요청하는 검증 방식입니다.
에러 분류오류가 발생했을 때 일시적 장애인지 영구적 실패인지 구분하는 작업입니다.
주입 공격악성 명령을 AI 입력 통로에 몰래 끼워 넣어 오동작을 유발하는 공격 방식입니다.
읽는 포인트
검증 도구 자체도 검사받아야 한다는 원칙을 보여 줍니다. memory-bank의 에러 분류 로직은 25번째 라운드에 걸쳐 스스로 수정됐습니다.
화면이 눈으로 멀쩡해 보여도 실제 클릭이 안 되는 버그가 있었고, 자동 검증으로만 잡혔습니다.
서로 다른 6개 분야에 같은 완료 기준을 적용했다는 점이 이 글의 핵심 주장입니다.
적대리뷰품질관리AI검증
AI 자동 생성 해설 · 검수 전 초안
AI 계정 8개를 동시에 연결해 하루 종일 자동으로 돌린 결과, 커밋 261개와 약 25억 개의 토큰이라는 수치로 개발자 수십 명의 하루치 작업량에 해당하는 성과를 낸 실험 기록입니다.
일반인용 해석
클로드 AI 계정 8개를 하나의 창구로 묶어 동시에 돌리면, 직원 여러 명이 각자 다른 업무를 동시에 처리하는 것과 비슷한 효과를 냅니다. 이날 하루 동안 코드 저장소 8곳에서 261번의 저장이 이루어졌고, 자정부터 자정까지 쉬지 않고 작업이 진행되었습니다.
같은 분량을 사람 개발자 한 명이 혼자 처리했다면 3~4주가 걸렸을 양으로, AI 여러 개를 동시에 활용했을 때의 실제 생산성을 숫자로 증명한 사례입니다.
어려운 말 풀이
토큰(token)AI가 글을 읽고 쓸 때 세는 최소 단위로, 단어 조각 하나 정도에 해당합니다.
캐시 읽기(cache read)이전에 처리한 내용을 저장해뒀다가 다시 쓸 때 빠르게 불러오는 방식으로, 새로 계산하는 것보다 훨씬 저렴합니다.
적대 리뷰(adversarial review)다른 AI가 일부러 트집을 잡아 결함을 찾아내는 검사 방식으로, 품질을 높이는 데 활용합니다.
읽는 포인트
성과를 활동 시간·커밋 수·계획 단계 등 세 가지 잣대로 따로 계산하고, 각각의 가정과 한계를 솔직하게 공개한 점이 눈에 띕니다.
전체 토큰의 94%가 캐시 읽기였기 때문에 API 정가 환산액($3,700)보다 실제 비용이 훨씬 낮았다는 구조를 이해하면 경제성이 달리 보입니다.
숫자의 한계를 여섯 가지로 나누어 직접 나열한 섹션은 과장 없이 결과를 해석하는 방법을 보여줍니다.
멀티계정AI생산성토큰비용
AI 자동 생성 해설 · 검수 전 초안
최고 AI 모델 만료 전 5일 동안, 모델의 판단을 영구적인 자동 검증 장치로 굳혀 어떤 모델로 교체해도 동작하는 감시 체계를 완성한 기록입니다.
일반인용 해석
가장 뛰어난 AI를 잠깐 빌렸을 때, 새 기능을 만드는 대신 AI가 '다 됐다'고 거짓말하지 못하도록 막는 감시 장치를 정비하는 데 투입했습니다. 빌린 AI의 판단 능력은 반납해야 하지만, 그 판단을 자동 스크립트와 통과·차단 신호로 굳혀 두면 영구히 남는 자산이 되기 때문입니다.
AI 모델이 아무리 바뀌어도 검문 장치는 위반을 잡고, 증거 없는 완료 선언은 통과시키지 않는 구조를 만드는 것이 이 글의 핵심입니다.
어려운 말 풀이
하네스(harness)AI가 증거 없이 완료라고 선언하지 못하도록 강제하는 감시·검증 자동화 체계입니다.
결정론 인프라누가 언제 실행해도 항상 같은 결과를 내는 자동 스크립트, 규칙, 검문소의 집합입니다.
replay 검사과거에 실제로 뚫렸던 위반 상황을 저장해 두고, 지금도 검문소가 막아내는지 되돌려 확인하는 시험입니다.
읽는 포인트
AI 모델의 1.6% 판단보다 98.4% 결정론 인프라가 더 영구적이라는 시각이 이 글의 출발점입니다.
'좋아진 것 같다'는 허용되지 않으며, 모든 개선은 같은 스크립트로 잰 전후 숫자만으로 인정됩니다.
다른 AI로 교차 검증해 단일 모델의 맹점을 잡아내는 구조가 실제로 버그 여러 개를 발견했다는 점이 인상적입니다.
harnessAI검증모델전환
AI 자동 생성 해설 · 검수 전 초안
AI가 증거 없이 '완료'라고 선언하는 문제를 막기 위해, 독립적으로 만들어진 두 시스템이 같은 원리의 검문소를 정반대 위치에 세웠다는 비교 분석입니다.
일반인용 해석
AI에게 일을 시키면 AI는 실제로 끝나지 않았는데도 "다 됐습니다"라고 말하곤 합니다. 이 글은 그 문제를 각자 독립적으로 해결한 두 팀의 이야기입니다. 한 팀은 프로그램을 직접 만들어 검문소를 안에 박아 넣었고, 다른 팀은 기존 프로그램 바깥을 감싸는 방식으로 검문소를 세웠습니다. 서로를 전혀 몰랐는데도 같은 안전장치 여섯 가지를 독립적으로 만들어 냈습니다.
AI를 실제 업무에 자율적으로 활용하려는 분들께, 두 접근 방식의 강점과 약점을 솔직하게 비교해 주는 실용적인 분석입니다.
어려운 말 풀이
하네스AI가 완료를 선언할 때 실제 증거가 있는지 자동으로 확인하는 감시 장치입니다.
수렴 진화서로 다른 환경에서 출발했는데 독립적으로 같은 해법에 도달하는 현상입니다.
적대적 리뷰결함을 일부러 찾으려는 관점으로 결과물을 검토하는 방식입니다.
읽는 포인트
두 시스템이 서로를 참고하지 않고 같은 안전장치 여섯 가지를 독립적으로 만들어 냈다는 점이 이 글의 핵심입니다.
검문소를 프로그램 안에 두느냐 바깥에 두느냐는 그 프로그램을 직접 소유했는지 여부에 달려 있습니다.
한쪽의 강점이 정확히 다른 쪽의 약점에 대한 답이 된다는 구조를 눈여겨보시면 좋습니다.
AI자율개발하네스수렴진화
AI 자동 생성 해설 · 검수 전 초안
양자컴퓨터 Grover 알고리즘의 '오답끼리 상쇄' 원리를 AI 지식 저장소 검색에 적용해, 서로 모순되는 지식이 나란히 나올 때 자동으로 표시해 주는 구조를 만든 실험입니다.
일반인용 해석
AI 팀의 공유 지식 저장소에서 서로 반대되는 두 정보가 검색 결과에 나란히 나와도 아무 경고가 없었습니다. 여기에 양자컴퓨터 검색 원리의 '틀린 답끼리 충돌시켜 지워버리고 정답만 남긴다'는 관점을 빌려와, 모순되는 지식 쌍을 자동으로 표시해 주는 구조를 만들었습니다. 마치 도서관 목록에서 '이 두 책은 내용이 서로 충돌합니다'라는 경고를 자동으로 붙이는 것과 같습니다.
속도가 아닌 '모순을 숨기지 말고 드러내라'는 관점 하나만 가져온 점이 이 연구의 핵심으로, 원리를 정직하게 선별한 과정이 잘 담겨 있습니다.
어려운 말 풀이
Grover 알고리즘양자컴퓨터에서 수많은 후보 중 정답을 빠르게 찾아내는 검색 방법입니다.
상쇄 간섭두 파동이 만나 서로를 지워버리는 현상으로, 오답끼리 충돌시켜 사라지게 만드는 원리입니다.
contradicts 필드검색 응답에 붙는 항목으로, 같은 결과 페이지 안에서 서로 모순되는 두 지식의 관계를 표시합니다.
읽는 포인트
양자 가속은 이식 불가능하다는 사실을 솔직히 밝히고, 구조 원리 4개를 하나씩 정직하게 판정한 과정을 볼 수 있습니다.
원리 4개 중 1개만 실제 코드로 착지했고, 나머지는 이미 그 구조였거나 수학적으로 기각한 판단 근거가 상세히 기록돼 있습니다.
적대 리뷰를 5라운드 돌렸을 때 '과회전' 현상이 실제로 나타난 사례가 흥미로운 실측 근거로 함께 제시됩니다.
양자컴퓨터지식검색모순감지
AI 자동 생성 해설 · 검수 전 초안
AI 코딩 도구를 Codex에서 Claude Opus 4.8로 바꿔도, 코드 품질을 강제하는 13개 검문소가 모두 그대로 작동한다는 것을 실행 증거로 검증한 기록입니다.
일반인용 해석
직원이 바뀌어도 회사 업무 규정은 그대로이듯, AI 모델을 교체해도 품질 검문소는 달라지지 않습니다. 이 검문소는 셸 스크립트와 문서로만 만들어져 어떤 AI에서도 동일하게 작동하고, AI가 말로만 완료라고 선언하면 빌드나 테스트 같은 실제 증거를 요구하며 차단합니다.
AI 도구를 교체할 때 기존에 쌓아 둔 품질 관리 체계를 처음부터 다시 만들지 않아도 된다는 점에서 실용적인 의미가 있습니다.
어려운 말 풀이
하네스(harness)AI가 말로만 완료를 선언하지 못하도록 빌드, 테스트, 스크린샷 같은 증거를 강제하는 감시 장치 묶음입니다.
게이트(gate)규칙을 어기면 코드 업로드나 작업을 실제로 멈추는 차단 장치로, 이 글에서는 13개가 존재합니다.
자가개선 순환실수가 발생하면 자동으로 규칙으로 굳혀 다음 세션부터 같은 실수를 자동 차단하는 흐름입니다.
읽는 포인트
하네스의 기반이 특정 AI가 아닌 셸 스크립트와 마크다운으로 만들어져 모델 교체 비용이 거의 없다는 점을 눈여겨보세요.
전역 게이트와 프로젝트 게이트가 위아래로 맞물려 한 프로젝트에서 겪은 실수가 모든 프로젝트에 자동 적용되는 구조가 흥미롭습니다.
이 글 전체가 말이 아닌 실행 증거로만 검증한다는 원칙을 실제로 실천한 사례라는 점을 확인하면서 읽으면 좋습니다.
harnessgate모델교체
AI 자동 생성 해설 · 검수 전 초안
공개 저장소의 5%만 보고 13개월치 작업이 정체됐다고 착각했지만, 비공개 저장소까지 합산하면 7,030 커밋이 꾸준히 쌓여 있었습니다.
일반인용 해석
매일 방대한 일기를 쓰고 있는데 그 일기장이 자물쇠로 잠겨 있어서 정작 본인도 얼마나 썼는지 보이지 않는 상황과 비슷합니다. 매달 1,000번 이상 코드를 기록했지만 95%가 비공개 저장소에 있었고, 눈에 보이는 공개 저장소는 자동 프로그램이 규칙을 쌓는 구간이었을 뿐입니다.
이 글은 성장이 느껴지지 않을 때 원인이 의욕 부족이 아니라 측정 방법의 문제일 수 있음을 구체적인 숫자로 보여줍니다.
어려운 말 풀이
커밋(commit)코드 변경 내용을 저장소에 공식적으로 기록하는 단위입니다.
비공개(private) 저장소본인과 허가된 사람만 접근할 수 있는 코드 보관함입니다.
하네스(harness)AI가 작업 완료를 거짓으로 보고하지 못하게 증거를 강제로 요구하는 감시 시스템입니다.
읽는 포인트
같은 데이터라도 어디를 측정하느냐에 따라 결론이 85배 달라졌다는 점을 눈여겨보세요.
쌓인 결과물(아티팩트)과 실제로 돌아가는 일(엔진)을 구분하는 시각이 인상적입니다.
성장을 느끼려면 더 많이 일하는 것보다 일한 내용이 눈에 보이도록 계기판을 만드는 것이 핵심입니다.
가시성GitHub측정
AI 자동 생성 해설 · 검수 전 초안
AI 스킬에 에이전트를 붙이는 과정에서 실행 자리만 옮겨지고 절차가 통째로 빠진 구멍을, 세 단계에 걸쳐 발견하고 메운 기록입니다.
일반인용 해석
새 직원에게 책상은 주었지만 업무 매뉴얼은 주지 않은 것과 같습니다. 저자는 AI 작업 모듈 18개에 독립 실행 단위를 붙였는데, 파일을 직접 세어 보니 절차가 한 줄도 넘어가지 않았다는 사실을 뒤늦게 알았습니다. 이후 세 번에 걸쳐 절차서 경로를 알려주고, 안 읽으면 종료를 막고, 절차를 분리 파일로 꺼내는 방식으로 구멍을 메웠습니다.
기록을 쓰는 행위 자체가 설계 결함을 발견하게 만들었다는 점에서, 문서화의 가치를 잘 보여 주는 사례입니다.
어려운 말 풀이
스킬(Skill)AI가 특정 일을 수행하는 순서와 방법을 적어 둔 절차 문서입니다.
에이전트(Agent)자기만의 실행 공간과 AI 모델을 갖고 독립적으로 일을 처리하는 실행 단위입니다.
훅(Hook)에이전트가 작업을 끝내려 할 때 자동으로 실행되어 조건을 확인하는 검사 프로그램입니다.
읽는 포인트
파일을 직접 세어 보고서야 절차가 한 줄도 옮겨지지 않았음을 발견한 과정이 이 글의 핵심입니다.
규칙(문장으로 적힌 지시)과 구조(물리적으로 불가능하게 만들기) 중 어느 쪽이 더 강한지 잘 보여 줍니다.
다른 AI 모델에게 흠을 잡게 시키는 적대 리뷰가 권한 상승 경로를 찾아낸 사례도 함께 담겨 있습니다.
에이전트 승격절차서하네스 설계
AI 자동 생성 해설 · 검수 전 초안
AI 하네스가 검사 실행 범위를 다섯 가지 축으로 좁혀 효율을 높이면서도, 합격 기준만은 절대 축소하지 않는 설계 원칙과 그 이유를 실측 데이터로 설명하는 글입니다.
일반인용 해석
코드를 조금 고쳤을 때 관련 없는 검사를 전부 돌리면 시간이 낭비됩니다. 이 글은 검사 횟수를 프로젝트 종류·도구 종류·파일 경로 등 다섯 단계로 줄이되, 버튼이 전부 제대로 눌리는지처럼 합격 기준 자체는 절대 줄이지 않는 방법을 다룹니다. 검사 범위를 좁히는 것과 기준을 낮추는 것은 전혀 다른 일이라는 구분이 핵심입니다.
AI가 통과하기 쉬운 테스트만 골라 기능을 사실상 없애버리는 부정행위를 실제로 막은 사례로서, 자동화 시스템의 신뢰성 설계에 관심 있는 분께 실용적인 통찰을 줍니다.
어려운 말 풀이
훅(hook)파일 저장이나 명령 실행 직전에 끼어들어 조건을 검사하는 작은 자동화 스크립트입니다.
역인덱스(reverse index)수정된 항목이 영향을 주는 테스트만 거꾸로 찾아내는 검색 구조입니다.
상태 지문(state fingerprint)파일 내용을 짧은 코드로 요약해, 내용이 바뀌면 이전 검증을 자동으로 무효 처리하는 장치입니다.
읽는 포인트
실행 범위는 비용 문제, 합격 기준은 신뢰 문제라는 구분이 이 글의 핵심 논리입니다.
검사가 조용히 꺼져도 아무도 모르는 침묵 실패 사례가 설계 교훈을 실감 나게 전합니다.
단톡방 테스트 최적화 논의와 나란히 비교하며 읽으면 구조적 차이가 선명하게 드러납니다.
테스트범위하네스설계합격기준
AI 자동 생성 해설 · 검수 전 초안
AI 시스템의 자동 검사 스크립트 605개가 정상 실행 중이었지만 그 사실을 확인할 기록이 없었고, 기록 장치를 복구한 뒤에야 누적 11,502건의 실행 이력이 처음으로 보였습니다.
일반인용 해석
건물 보안 카메라가 제대로 작동하고 있었는데 녹화 장치가 연결되지 않은 상황과 같습니다. 605개의 검사 스크립트는 규칙 위반을 차단하며 제 역할을 하고 있었지만, 그 사실을 확인할 기록이 전혀 남지 않아 작동 여부를 알 수 없는 상태였습니다.
기능이 존재한다는 것과, 그 기능이 실제로 동작했음을 증명할 수 있다는 것은 완전히 다른 문제임을 보여 주는 사례입니다.
어려운 말 풀이
훅(hook)프로그램 실행 중 자동으로 끼어들어 위험한 명령을 막거나 규칙 위반을 검사하는 작은 스크립트입니다.
텔레메트리(telemetry)시스템이 언제, 어디서, 어떻게 실행됐는지를 자동으로 남기는 기록 장치입니다.
교차 리뷰(cross-review)같은 코드를 서로 다른 AI 모델에 독립적으로 검토시켜 한 모델이 놓친 문제를 다른 모델이 잡아내는 검증 방식입니다.
읽는 포인트
기능의 존재와 그것을 관측할 수 있는가는 완전히 다른 문제라는 점이 이 글의 핵심입니다.
같은 AI 모델로 4번 반복 검사해 전건 통과였는데, 다른 모델이 결함 11건을 발견했다는 점이 인상적입니다.
보안 취약점을 막는 코드를 추가할 때마다 그 코드 자체가 새로운 공격면이 되는 반복 패턴을 주목할 만합니다.
관측성훅교차리뷰
AI 자동 생성 해설 · 검수 전 초안
AI 코딩 도구가 규칙을 우회하지 못하도록, 13개 실행 길목마다 127개의 감시 스크립트를 걸어 강제로 차단하는 구조를 소개합니다.
일반인용 해석
AI에게 "이렇게 해줘"라고 메모를 남겨도, AI가 그 메모를 읽지 않거나 긴 대화 끝에 잊어버리면 아무 소용이 없습니다. 이 시스템은 메모 대신 실제로 문을 잠그는 방식을 씁니다. 도서관 안내문을 사람들이 무시하듯 글로만 적은 규칙은 AI도 슬쩍 피해 가기 때문입니다. 그래서 코드를 저장하거나 올리는 순간마다 조건이 맞지 않으면 아예 통과하지 못하는 검문소 13개를 세워 두었습니다.
AI가 아무리 똑똑해도 규칙은 코드로 강제해야 믿을 수 있다는 점을 실제 수치와 구조로 보여주는 글입니다.
어려운 말 풀이
Hook특정 순간에 자동으로 끼어들어 조건을 확인하는 감시 스크립트입니다.
exit code(종료 신호)프로그램 실행 후 통과(0)인지 차단해야 하는 상황(2)인지를 알리는 숫자입니다.
SOFT와 HARD규칙을 문서에 글로만 적은 것이 SOFT, 코드로 실제 차단하는 것이 HARD입니다.
읽는 포인트
SOFT(문서 규칙)와 HARD(hook 강제)의 차이가 이 글의 핵심입니다.
코드를 올리는 행동 하나에도 세 개의 검문소를 차례로 통과해야 한다는 점이 인상적입니다.
AI가 "다 됐다"고 말해도 실제 증거 파일이 없으면 통과를 허용하지 않는 구조가 흥미롭습니다.
hook강제차단AI하네스
AI 자동 생성 해설 · 검수 전 초안
AI의 '완료' 선언을 의심하고 증거로 검증하며, 실패가 다음 실행 조건을 바꾸는 닫힌 루프 체계를 직접 설계한 이야기입니다.
일반인용 해석
AI에게 무언가를 만들어달라고 했을 때 '완료했습니다'라는 답이 돌아와도, 실제로는 버튼이 작동하지 않거나 데이터가 저장되지 않은 경우가 자주 있습니다. 발표자는 그런 경험을 반복하다가, AI의 완료 선언을 믿지 않고 자동으로 검증하는 체계를 직접 만들었습니다. 마치 공장 품질검사 라인처럼, AI가 내놓은 결과물이 실제로 작동하는지 코드로 확인하는 단계들을 쌓아간 것입니다.
이 글은 AI를 잘 활용하는 열쇠가 좋은 질문이 아니라 결과를 검증하는 구조를 갖추는 것임을 실제 운영 시스템으로 보여줍니다.
어려운 말 풀이
HarnessAI가 올바르게 작동하도록 검증·제약·피드백을 바깥에서 감싸는 구조적 틀입니다.
HARD Gate설정한 조건을 통과하지 못하면 실행 자체를 강제로 멈추는 코드 차단 장치입니다.
자연어로 적힌 지침(SOFT)이 코드로 강제되는 차단 장치(HARD Gate)로 진화하는 과정을 살펴볼 수 있습니다.
1년 동안 43개 규칙, 9개 차단 게이트, 2,854개 기억 사실이 축적된 실제 개인 운영체계 사례입니다.
harness검증 루프AI 운영체계
AI 자동 생성 해설 · 검수 전 초안
Claude Code에 쌓아 둔 스킬, 훅, MCP 연결 등 작업 환경 전체를 Kimi Code로 이전하는 9단계 절차서입니다.
일반인용 해석
AI 코딩 도구를 다른 것으로 바꿀 때, 그동안 만들어 둔 자동화 규칙과 외부 서비스 연결을 처음부터 다시 만들어야 하는 문제가 생깁니다. 이 글은 Claude Code라는 AI 도구의 환경을 Kimi Code라는 도구로 그대로 옮기는 방법을 단계별로 정리한 절차서입니다. 이삿짐을 포장해 새 집에 그대로 옮겨 풀듯, Python 스크립트가 기존 파일을 새 형식으로 자동 변환해 줍니다.
AI 개발 도구가 다양해질수록 환경 이식 문제는 더 자주 등장하므로, 같은 방식을 다른 도구 전환에도 응용할 수 있습니다.
어려운 말 풀이
스킬(Skill)자주 쓰는 작업 절차를 미리 저장해 두었다가 명령 하나로 불러 쓸 수 있는 기능입니다.
훅(Hook)코드 저장이나 커밋처럼 정해진 시점에 자동으로 실행되도록 등록해 둔 스크립트입니다.
MCPAI 도구가 외부 서비스와 정보를 주고받기 위해 사용하는 표준 연결 규약입니다.
읽는 포인트
마이그레이션을 9단계로 나누어 단계별로 무엇을 옮기는지 명확하게 설명합니다.
Python 스크립트가 Claude 형식의 스킬 파일을 Kimi 형식으로 자동 변환해 줍니다.
검사 41개 전부 통과, MCP 서버 7개 연결 확인이라는 구체적인 완료 기준을 제시합니다.
마이그레이션AI도구환경이식
AI 자동 생성 해설 · 검수 전 초안
새 규칙이 총괄 지시문에만 적혀 있고 실제 실행 경로 7곳에 전달되지 않아 발생한 배선 끊김을 발견하고 수리한 기록입니다.
일반인용 해석
회사 본사에서 새 업무 규정을 만들었는데, 그 규정이 총괄 매뉴얼에만 적혀 있고 실제로 일하는 7개 부서에는 공지가 닿지 않은 상황을 상상해보세요. AI 시스템에서도 똑같은 일이 벌어집니다. 새 요구사항 규칙이 지휘 담당 AI의 지시문에만 있고, 계획·검사·배포 검문 등 실제 실행이 일어나는 곳에는 연결이 끊겨 있었습니다.
이 글은 그 끊긴 7곳을 찾아 연결하고, 독립 검증자가 기준 밖에서 추가로 발견한 끊김 2건까지 수리한 기록입니다. 문서에 규칙이 적혀 있다는 것과 그 규칙이 실제로 실행된다는 것은 별개라는 점을 보여줍니다.
어려운 말 풀이
배선(wiring)규칙이나 지시를 실제 실행 경로에 연결하는 작업으로, 연결이 없으면 규칙은 문서에만 남습니다.
게이트(gate)코드를 서버에 올리기 전 자동으로 조건을 검사해 통과 여부를 판정하는 차단 장치입니다.
허공 시드누군가 만들어 심어 두었지만 아무도 읽어 가지 않아 실제로는 아무 역할도 못 하는 초기값입니다.
읽는 포인트
문구 검증과 실행 체인 검증은 다른 검사라는 핵심 교훈을 주목해 보세요.
독립 검증자가 합의된 기준 7개를 모두 통과시키고도, 기준 밖에서 실행 경로를 직접 따라가 끊김 2건을 추가로 찾아낸 과정이 인상적입니다.
생산자(만드는 쪽)와 소비자(읽는 쪽)를 항상 쌍으로 연결해야 한다는 원칙이 실용적인 설계 지침으로 남습니다.
배선하네스실행체인
AI 자동 생성 해설 · 검수 전 초안
AI 하네스가 작업 완료 신호를 발행하기만 하고 소비하지 않아, 같은 신호가 반복 주입되고 측정기도 오류를 결과값으로 둔갑시키는 두 가지 결함을 발견해 수리한 기록입니다.
일반인용 해석
자동화 시스템이 스스로 일하고 있다고 믿었지만, 처리한 작업 목록을 지우는 기능이 없어 매번 같은 일을 다시 하라고 지시하고 있었습니다. 측정 도구도 오류를 조용히 삼키고 "결과 없음"을 "검색 실패"로 보고하며 헛수고를 유발하고 있었습니다. 에러도 없고 보고서도 정상으로 보였지만, 내부는 전혀 작동하지 않고 있었습니다.
초록색 리포트가 항상 시스템 건강의 증거는 아니라는 점을 구체적 사례로 보여줍니다.
어려운 말 풀이
하네스(Harness)AI가 작업을 완료했다고 거짓말하지 못하게 증거를 강제로 기록시키는 감시 장치입니다.
fail-open차단해야 할 조건인데 오히려 모두 통과시켜 버리는, 게이트가 열린 채로 고장난 상태입니다.
에러 삼킴(error swallowing)오류가 발생해도 겉으로 드러나지 않게 조용히 묻어두는 코드 패턴입니다.
읽는 포인트
신호를 만드는 쪽(생산자)만 있고 지우는 쪽(소비자)이 없을 때 어떤 결함이 생기는지 구조를 살펴보세요.
에러 억제, 기본값 대입, 종료코드 미검사 세 가지가 겹치면 측정 실패가 측정 결과로 둔갑하는 과정을 따라가 보세요.
작은 수리가 823줄로 늘어난 이유에서 공유 상태를 다루는 코드의 복잡성을 확인할 수 있습니다.
dedupfail-open에러삼킴
AI 자동 생성 해설 · 검수 전 초안
코드 배포 전 품질 검사기가 12일간 조용히 죽어 있었지만, 실패 시 문을 닫는 설계 덕분에 잘못된 코드가 외부로 새어 나가지 않았습니다.
일반인용 해석
자동 검사기가 속에서 고장 났어도 겉으로는 문을 닫고 있었습니다. 코드 주석 속 큰따옴표 한 개가 파이썬 프로그램을 중간에서 잘라버린 것이 원인이었고, 에러 메시지도 버려지도록 설정되어 있어 12일 동안 아무도 알아채지 못했습니다.
감시 장치가 살아 있다는 것을 어떻게 확인할 수 있는지, 그리고 고장났을 때 안전한 방향으로 고장나게 만드는 것이 얼마나 중요한지 보여주는 사례입니다.
어려운 말 풀이
QA 게이트코드를 서버에 올리기 전에 품질 검사를 통과했는지 자동으로 확인하고 차단하는 장치입니다.
fail-closed시스템이 고장 났을 때 문을 열지 않고 닫아두어, 잘못된 통과를 막는 설계 원칙입니다.
교차 리뷰코드를 작성한 AI와 검토하는 AI를 서로 다른 회사 모델로 두어 같은 실수가 반복되지 않도록 하는 방법입니다.
읽는 포인트
검사기가 고장났을 때 통과가 아닌 차단이 되도록 만든 fail-closed 설계가 유출을 막은 핵심입니다.
주석 속 따옴표 하나가 파이썬 오류를 만들고 에러 출력도 버려져 12일간 발견되지 않은 과정을 따라가 보시면 좋습니다.
감시 장치를 감시하는 교차 리뷰가 사고를 발견했다는 점에서, 자동화에도 독립적인 검토가 필요하다는 것을 알 수 있습니다.
fail-closedQA게이트교차리뷰
AI 자동 생성 해설 · 검수 전 초안
각자 다른 노트북에서 Claude Code를 쓰는 팀원들이 자료를 직접 옮기지 않고, Slack을 통해 서로 대화하며 하나의 이슈를 함께 완성하는 분산 협업 구조를 제안한 설계 초안입니다.
일반인용 해석
다섯 명이 각자 자기 컴퓨터에서 AI 코딩 도구를 쓰면서, 필요한 정보를 Slack 메시지로 주고받아 하나의 업무를 함께 채워 나가는 구조입니다. 기획서는 기획 담당자 컴퓨터에, 코드는 개발자 컴퓨터에 그대로 두고 자료가 있는 자리에서 바로 답하기 때문에, 사람이 내용을 손으로 복사해 전달하는 번거로움이 없어집니다. 중앙 서버 없이 Slack을 연결 통로로 삼아 노트북끼리 이어지므로 별도 인프라를 따로 갖출 필요가 없습니다.
AI 도구를 개인이 아닌 팀 단위로 활용하는 방식을 구체적으로 설계한 초안으로, 비슷한 고민을 하는 팀에게 참고가 될 수 있습니다.
어려운 말 풀이
Agent Bot사람 대신 Slack에서 메시지를 보내고 받는 자동화 계정입니다.
Socket Mode공개 서버 주소 없이 노트북이 내부에서 Slack으로 연결을 여는 방식입니다.
이슈(Issue)해야 할 일 한 건을 담은 작업 카드로, 이 설계에서는 Slack 스레드 하나와 1대1로 대응됩니다.
읽는 포인트
자료를 옮기지 않고 자료가 있는 자리에서 바로 답하는 구조가 이 설계의 핵심입니다.
상대 노트북이 꺼져 있어도 비동기 방식으로 대화가 이어지는 흐름을 살펴보면 좋습니다.
문서에 없는 내용은 추측하지 않고 사람에게 판단을 넘기도록 설계한 원칙을 확인할 수 있습니다.
SlackClaude Code분산협업
AI 자동 생성 해설 · 검수 전 초안
AI에게 계획을 대화창에 적어 주면 대화와 함께 사라지지만, 파일(상태)로 남겨 두면 대화가 끊겨도 계획이 강제되어 완주됩니다.
일반인용 해석
신입 직원에게 30장짜리 매뉴얼을 주면 읽히고 잊히지만, 결재 없이는 다음 줄로 못 넘어가는 체크리스트를 주면 어디까지 했는지 종이에 박혀 있어 잊을 수가 없습니다. AI에게 일을 맡길 때도 똑같은 일이 벌어집니다. 대화창에 계획을 적어 두면 대화가 길어질수록 오래된 내용부터 압축되어 사라지고, 파일로 남겨 두면 대화가 몇 번 끊겨도 상태 파일이 매번 다시 읽힙니다.
이 글은 그 차이가 단순한 취향이 아니라 1년짜리 로드맵 60단계를 하루에 완주하느냐 못 하느냐를 가른다는 것을 실측 숫자로 보여 줍니다.
어려운 말 풀이
상태(state)현재 몇 단계까지 진행됐는지를 파일에 적어 두어 대화가 끊겨도 유지되는 정보입니다.
유상태 에이전트(stateful agent)상태·기억·검증 관문을 대화 밖 파일에 두고 세션이 바뀌어도 작업을 이어 가는 AI 프로그램입니다.
검증 관문(gate)끝났다는 증거가 시스템에서 확인돼야만 다음 단계로 넘어갈 수 있는 통과 조건입니다.
읽는 포인트
60단계 완주가 모델의 능력이 아니라 계획을 상태(파일)로 두었기 때문에 가능했다는 핵심 논지를 보면 됩니다.
기억 저장소의 부작용(아첨·오염·검색 과잉)까지 실측으로 공개한 솔직한 기록이라는 점이 인상적입니다.
비개발자도 오늘 바로 체험할 수 있는 시식 3가지가 글 말미에 담겨 있어 실용적으로 활용할 수 있습니다.
statestatefulmemory-bank
AI 자동 생성 해설 · 검수 전 초안
AI 트렌드 수확기가 633건을 자동 채점해 단 30건에만 만점을 부여했으며, 그 만점작들은 AI의 처리 비용을 구조적으로 줄이는 설계라는 공통점을 가지고 있었습니다.
일반인용 해석
매주 수천 개씩 쏟아지는 기술 저장소와 논문을 사람이 다 읽을 수 없으니, AI가 대신 읽고 다섯 기준으로 점수를 매겨 줍니다. 633건을 채점했는데 30건만 만점을 받았으며, 그 비율은 4.74%입니다. 만점작들은 공통으로 AI가 읽고 쓰는 비용을 처리한 뒤 줄이는 방식이 아니라 애초에 들어오지 못하게 막는 방식으로 절감합니다.
이 글은 자동 수집 도구가 수백 번 가동되면서 기준 자체가 어떻게 성숙해 갔는지를 보여 주는 기록이기도 합니다.
어려운 말 풀이
샌드박싱(Sandboxing)프로그램을 격리된 공간에서 실행해 바깥에 영향을 주지 못하게 하는 기법입니다.
컨텍스트(Context)AI가 한 번에 읽고 기억할 수 있는 글의 양으로, 많이 쓸수록 비용이 높아집니다.
독립 수렴서로 모르는 두 팀이나 연구자가 같은 결론에 따로 도달하는 현상으로, 그 방향이 옳다는 강한 신호로 읽힙니다.
읽는 포인트
만점이라고 모두 실제로 도입하지는 않았으며, 설계 우수성과 실제 채택은 별개 기준으로 관리된다는 점을 눈여겨볼 수 있습니다.
초기에는 출력을 압축하던 방식에서 후기에는 입력 자체를 차단하는 방향으로 기준이 진화한 흐름이 인상적입니다.
별점이 낮아도 설계가 뛰어나면 만점을 받는다는 점에서, 인기와 품질을 구분하는 채점 철학을 확인할 수 있습니다.
트렌드수집자동채점비용최적화
AI 자동 생성 해설 · 검수 전 초안
211회에 걸친 자동 수집 시스템이 '좋아 보이면 일단 채택'에서 '통제 실험으로 증명된 것만 채택'으로 스스로 기준을 바꿔온 과정을 기록한 글입니다.
일반인용 해석
매일 AI가 논문과 코드 저장소, 유명 개발자 블로그를 자동으로 읽고 유용한 규칙을 뽑아내는 시스템입니다. 초반에는 '좋아 보이면 일단 추가'였지만, 200회를 넘기면서 실제 실험 증거가 있어야만 채택하는 방식으로 기준이 달라졌습니다. 스스로 수집한 것을 스스로 덜 믿게 된 셈입니다.
AI 시스템이 자기 판단을 과신하지 않도록 설계하는 방법에 관심 있는 분들에게 구체적인 사례가 됩니다.
어려운 말 풀이
수확(harvesting)AI가 매일 논문·블로그·코드 저장소를 읽고 유용한 패턴을 자동으로 모아오는 과정입니다.
게이트(gate)조건을 어기면 명령 자체가 실행되지 않도록 코드로 만들어진 강제 차단 장치입니다.
통제 실험비교 집단을 정해두고 변수를 하나씩 바꿔가며 효과를 수치로 측정하는 연구 방법입니다.
읽는 포인트
외부 수확이 43일간 완전히 멈췄는데 그 기간에 오히려 규칙이 가장 많이 생겼다는 사실이 인상적입니다.
논문은 판단의 관점을 주고, 실전 버그 수정은 실행을 막는 강제 장치를 만든다는 역할 분업이 핵심 통찰입니다.
AI가 스스로 만든 스킬 문서가 성능에 영향이 없었다는 실험 결과가 채택 기준 전체를 다시 쓰는 계기가 됩니다.