하네스(harness, AI가 일을 대충 끝내지 못하게 증거를 강제하는 검사 규칙과 자동화 장치)는 오래 쓸수록 공개하기 어려워진다. 이 글은 왜 그런지를 따져 본 기록이다. 코드 파일은 내려받으면 그대로 복사된다. 그런데 그 코드가 왜 그렇게 생겼는지는 내 실수 기록과 판단에서 나왔고, 그 부분은 파일에 담기지 않는다. 그래서 공개할 수 있는 것과 없는 것을 갈라 보고, 공개의 손익을 계산했다. 결론은 코드 대신 철학을 공유하는 쪽이다. 시스템을 실제로 작동하게 만드는 건 도구를 쓰는 사람의 철학이기 때문이다.
DNA~/.claude/
├── hooks/ ← 33개. 반복한 실수에서 태어난 자동 검사 규칙(hook, 작업 사이에 끼어들어 검사하고 막는 장치)
├── skills/ ← 45개. 프로젝트마다 정해 둔 작업 절차서(스킬)
├── rules/ ← 15개. 글로 적어 둔 개인의 개발 철학
├── agents/ ← 13개. 역할을 나눠 둔 AI 일꾼, 곧 개인의 작업 흐름
├── logs/
│ ├── self-improve.jsonl ← 실수 51건의 이력. 자가개선이 읽는 원료
│ └── feedback.jsonl ← 사용자 불만이 쌓이는 기록
└── skills/*-scaffold/ ← 프로젝트별 '하지 말 것' 목록API 키(비밀번호 같은 접속 열쇠)를 지워도 이 폴더는 남이 쓸 수 있는 물건이 되지 않는다. 예를 들어 scaffold 규칙(프로젝트마다 반복한 실수를 모아 둔 '하지 말 것' 목록)이 그렇다. 그 규칙은 "이 프로젝트에서 날짜 입력창 설정을 빠뜨려 같은 버그를 세 번이나 고쳤다"는 개인의 경험에서 나온 것이다. 남에게는 아무 의미 없는 규칙이다.
떼어내기도 어렵다. 대부분의 기능 조각과 작업 흐름이 서로 얽혀 있어서 코드 저장소 하나로 딱 잘라 낼 수 없다. 게다가 나만의 방향과 철학이 배어 있다. 그래서 공개할수록 관리할 거리만 늘어난다.
scaffold-violation-check.shfeedback-detector.shself-improve SKILL.mdexit 2 패턴qa-gate-before-push.shsoft-to-hard-promoter.shSOFT 규칙(말로만 부탁하는 약한 규칙)은 안 지켜진다는 깨달음HARD 규칙(검사에 걸리면 작업을 강제로 멈춰 세우는 규칙. 멈추라는 신호가 종료 코드 exit 2다)이 왜 필요한지에 대한 경험왼쪽은 git clone 명령으로 코드를 통째로 내려받아 그대로 복사할 수 있다. 왼쪽 목록은 전부 파일과 패턴의 이름이다. 위에서부터 규칙 위반을 잡는 검사 스크립트, 사용자 불만을 감지하는 스크립트, 자가개선 절차서, 검사에 걸리면 멈춰 세우는 hook 패턴, 배포(push) 전 품질 검사 관문, 약한 규칙을 강한 규칙으로 올리는 승격기다. 오른쪽은 복사할 수 없다. 그리고 시스템을 작동하게 만드는 건 오른쪽이다.
scaffold-violation-check.sh(규칙 위반을 자동으로 막는 검사 스크립트)를 그대로 복사해도, 왜 이 패턴을 차단해야 하는지 를 모른다. 자기 프로젝트에는 다른 패턴이 필요한데, 그걸 어떻게 뽑아내야 할지 모른다.
결국 문의(issue)를 올린다: "설치가 안 돼요", "우리 프로젝트에는 안 맞아요", "이 규칙 왜 필요해요?"
"실수에서 규칙이 태어나야 한다"를 이해하면, bash든 Python이든 Cursor Rules든 자기 도구로 같은 루프를 만든다.
원리를 가져갔기 때문에 어떤 환경에서든 재현할 수 있다. 코드는 그 원리를 담는 그릇 하나일 뿐이다.
이것이 "도구를 쓰는 사람" vs "도구를 만드는 사람"의 차이다. 바이브코딩은 도구 사용법을 배우는 일이다. 하네스 엔지니어링(검사 규칙과 자동화 장치 자체를 설계하는 일)은 도구 자체를 자기 문제에 맞게 진화시키는 일이다. 역사적으로 후자가 항상 이겼다.
모든 사람이 "AI한테 만들어달라고 하면 된다"를 배우고 있다. YouTube 튜토리얼, 트위터 쓰레드, 블로그가 전부 같은 내용이다. 프롬프트(AI에게 건네는 요청 문장) 한 줄로 만든 앱은 프롬프트 한 줄로 만든 다른 앱과 경쟁할 수 없다. 둘 다 같은 수준이니까.
| 바이브코딩 | 폐루프 시스템 |
|---|---|
| 프롬프트 → 결과 → 끝 | HARD 강제로 도는 고리: 실수 → 규칙 → 강제 → 효과 측정 → 강화 |
| 세션마다 리셋 | 세션이 바뀌어도 기억 유지, 51건 자동 개선 축적 |
| AI에게 "만들어줘" | AI 시스템 자체를 설계하고 진화시킴 |
| 결과물에 집중 | 프로세스에 집중 |
| 누구나 복제 가능 | 축적된 scaffold, hook, 규칙은 복제 불가 |
| 1년 후에도 같은 수준 | 1년 후 '하지 말 것' 규칙 500개, 강제 차단 hook 50개 축적 |
바이브코더(AI에게 말로 시켜 만드는 사람)는 입력(프롬프트) → 출력(코드) → 끝이다. 피드백이 시스템으로 돌아오지 않는다. 폐루프 시스템은 다르다. 실수가 규칙이 되고, 규칙이 hook이 되고, hook이 차단이 되고, 차단의 효과가 측정된다. 사용할수록 강해진다. 이 차이가 시간이 지날수록 복리로 벌어진다.
ROI공개해서 얻는 것은 GitHub 스타(좋아요 수, 허영 지표)와 커뮤니티 기여(실제로는 거의 없다)뿐이다. 비공개로 두어서 잃는 것은 없다. 결국 AI 활용법에 도가 트고, 사고가 유연하고, 질문을 할 줄 알고, 문제 해결 능력이 있으며, 자기만의 AI 시스템을 구축하고 발전시켜 나가는 소수의 사람과 조직이 대부분의 시장과 일거리를 가져간다. 비슷한 상황의 사람들이 점점 늘어갈 것이다.
코드 대신 개념을 공유한다. 이해하는 사람은 자기 시스템을 만든다. 이해 못 하는 사람은 어차피 코드를 줘도 못 쓴다.
"폐루프 자가개선이란 무엇인가"
"말로 된 규칙과 강제로 막는 규칙의 차이", 등급 이름으로는 SOFT / HARD
"실수에서 규칙이 태어나는 구조"
"프로젝트별 독립 진화가 필요한 이유"
"세션이 바뀌어도 기억이 이어질 때 달라지는 것"
5개월간 축적된 33개 hook의 개별 맥락
4개 프로젝트마다 쌓인 '하지 말 것' 규칙들. 규칙 파일에 적힌 표제는 NEVER DO
51건의 자동 개선이 만든 고유한 규칙 체계
사용자 불만이 쌓인 기록 파일의 패턴
이 모든 것을 잇는 개인만의 작업 흐름
하네스 시스템은 진화할수록 개인의 경험, 실수, 철학이 코드에 각인된다. 그래서 진화할수록 공개하기 어려워진다. 코드를 공개하는 건 쉽다. 그 코드가 작동하는 이유인 철학까지는 전달할 수 없다.
도구는 복제 가능하다. 철학은 복제 불가능하다.
그리고 시스템을 작동하게 만드는 건 도구가 아니라 철학이다.
HARD 강제 12개, Hook 33개, 자동 개선 51건이 도는 폐루프 구조 전체.
AI가 일을 다 안 하고도 "끝났다"고 여기는 문제, 대화가 길어질수록 맥락을 잃는 문제 등 5가지 한계와 대응.
HARD 체크 36개, 스킬(정해진 작업 절차서) 7개, hook 41개로 이루어진 하네스 인프라 분석.
여러 AI를 지휘하는 플랫폼과 스스로 진화하는 파이프라인(작업이 정해진 순서로 흐르는 자동 처리 줄)을 6가지 축으로 비교.