Philosophy

Harness로 진화할수록
공개하기 어려운 이유

코드를 공개해도 "왜 이렇게 만들었는지"를 이해하는 사람은 극소수다. 도구가 핵심이 아니라 도구를 쓰는 사람의 철학이 핵심이기 때문이다.

Section 01
시스템이 곧 개인의 DNA
~/.claude/ ├── hooks/ ← 33개. 개인의 실수 패턴에서 태어난 규칙들 ├── skills/ ← 45개. 프로젝트별 컨벤션 ├── rules/ ← 15개. 개인의 개발 철학 ├── agents/ ← 13개. 개인의 워크플로우 ├── logs/ │ ├── self-improve.jsonl ← 51건의 실수 이력 │ └── feedback.jsonl ← 불만 패턴 └── skills/*-scaffold/ ← 프로젝트별 NEVER DO
공개 경계 복제 가능 — 코드 hooks/ · skills/ · scripts/ scaffold-violation-check.sh · exit 2 패턴 복제 불가능 — 철학 "SOFT 규칙은 무의미하다"는 깨달음 "실수에서 규칙이 태어나야 한다"는 설계 5개월간 축적된 실수·불만·판단의 맥락 프로젝트별 고유 경험 (다른 사람에게 무의미) 시스템을 작동하게 만드는 건 여기

API 키를 제거해도, scaffold 규칙은 "특정 프로젝트에서 DatePicker에 fluid를 빼먹어서 3번 fix 커밋을 했다"라는 개인의 경험에서 나온 것이다. 다른 사람에게는 의미 없는 규칙이다.

대부분의 모듈과 워크플로우가 서로 연결되어 있어서 특정 레포 하나로 분리하기 어렵고, 방향성과 철학이 녹아져 있어 공개할수록 관리 포인트만 늘어난다.

Section 02
공개할 수 있는 것과 없는 것
공개 가능한 것 — 코드
scaffold-violation-check.sh
feedback-detector.sh
self-improve SKILL.md
hook exit 2 패턴
qa-gate-before-push.sh
soft-to-hard-promoter.sh
공개 불가능한 것 — 철학
"SOFT 규칙은 무의미하다"는 깨달음
"사용자 불만에서 규칙을 추출한다"는 발상
"실수 → 규칙 → 강제 → 검증" 폐루프 설계
"왜 exit 2여야 하는가"에 대한 경험
"프로젝트마다 독립 진화해야 한다"는 판단
"바이브코딩은 천장이 있다"는 관찰
핵심

왼쪽은 git clone으로 복사할 수 있다. 오른쪽은 복사할 수 없다. 그리고 시스템을 작동하게 만드는 건 오른쪽이다.

Section 03
도구가 아니라 사람이 핵심인 이유
같은 망치를 들어도 집을 짓는 사람이 있고 못을 휘게 박는 사람이 있다. 도구의 차이가 아니라 도구를 쓰는 사람의 의도와 경험의 차이다.
오픈소스 코드 공개 코드를 받은 사람 git clone → 실행 → "안 되는데요?" "이 규칙 왜 필요해요?" "우리 프로젝트에는 안 맞아요" 철학을 이해한 사람 원리 이해 → 자기 도구로 구축 bash든 Python이든 Cursor든 같은 폐루프를 스스로 만든다
코드를 받은 사람

git clone → "안 되는데요?"

scaffold-violation-check.sh를 복사해도, 왜 이 패턴을 차단해야 하는지 모른다. 자기 프로젝트에는 다른 패턴이 필요한데, 그걸 어떻게 추출해야 하는지 모른다.

결국 issue를 올린다: "설치가 안 돼요", "우리 프로젝트에는 안 맞아요", "이 규칙 왜 필요해요?"

철학을 이해한 사람

폐루프 설계 → 자기 시스템 구축

"실수에서 규칙이 태어나야 한다"를 이해하면, bashPython이든 Cursor Rules자기 도구로 같은 루프를 만든다.

코드가 아니라 원리를 가져갔기 때문에, 어떤 환경에서든 재현할 수 있다.

이것이 "도구를 쓰는 사람" vs "도구를 만드는 사람"의 차이다. 바이브코딩은 도구 사용법을 배우는 것이고, 하네스 엔지니어링은 도구 자체를 자기 문제에 맞게 진화시키는 것이다. 역사적으로 후자가 항상 이겼다.

Section 04
바이브코딩은 천장이 있다

모든 사람이 "AI한테 만들어달라고 하면 된다"를 배우고 있다. YouTube 튜토리얼, 트위터 쓰레드, 블로그 — 전부 같은 내용이다. 프롬프트 한 줄로 만든 앱은 프롬프트 한 줄로 만든 다른 앱과 경쟁할 수 없다 — 둘 다 같은 수준이니까.

시간 역량 바이브코딩 천장 — 모두 같은 수준 폐루프 복리 격차 Day 1 1개월 6개월 1년
바이브코딩폐루프 시스템
프롬프트 → 결과 → 끝실수 → 규칙 → HARD 강제 → 효과 측정 → 강화
세션마다 리셋크로스세션 메모리, 51건 자동 개선 축적
AI에게 "만들어줘"AI 시스템 자체를 설계하고 진화시킴
결과물에 집중프로세스에 집중
누구나 복제 가능축적된 scaffold, hook, 규칙은 복제 불가
1년 후에도 같은 수준1년 후 NEVER DO 500개, HARD hook 50개 축적
개방 루프 vs 폐루프

바이브코더는 입력(프롬프트) → 출력(코드) → 끝. 피드백이 시스템으로 돌아오지 않는다. 폐루프 시스템은 실수가 규칙이 되고, 규칙이 hook이 되고, hook이 차단이 되고, 차단의 효과가 측정된다. 사용할수록 강해진다. 이 차이가 시간이 지날수록 복리로 벌어진다.

Section 05
공개의 ROI
공개 시 비용
issue 관리 (대부분 "설치가 안 돼요")
개인정보 분리 작업
범용화를 위한 추상화
문서 작성 / 유지
PR 리뷰
비공개 시 이득
시스템 진화에 100% 집중
경쟁 우위 유지
자신의 문제만 해결
관리 포인트 제로
철학을 글로 공유 (이것으로 충분)

공개 시 이득은 GitHub 스타(허영 지표)와 커뮤니티 기여(실제로는 거의 없음). 비공개 시 비용은 없음. 결국 AI 활용법에 도가 트고, 사고가 유연하고, 질문을 할 줄 알고, 문제해결능력이 있으며, 자기만의 AI 시스템을 구축하고 발전시켜나가는 소수의 사람과 조직이 대부분의 시장과 일거리를 가져간다. 비슷한 상황의 사람들이 점점 늘어갈 것이다.

Section 06
대안: 철학을 공유하되,
코드는 비공개

코드 대신 개념을 공유한다. 이해하는 사람은 자기 시스템을 만들 것이고, 이해 못 하는 사람은 어차피 코드를 줘도 못 쓴다.

공유할 수 있는 개념

"폐루프 자가개선이란 무엇인가"
"SOFT vs HARD 강제의 차이"
"실수에서 규칙이 태어나는 구조"
"프로젝트별 독립 진화가 필요한 이유"
"크로스세션 메모리가 바꾸는 것"

공유할 수 없는 것

5개월간 축적된 33개 hook의 개별 맥락
4개 프로젝트 scaffold의 NEVER DO 규칙들
51건의 자동 개선이 만든 고유한 규칙 체계
feedback.jsonl에 쌓인 불만 패턴
이 모든 것을 연결하는 개인의 워크플로우

결론

하네스 시스템은 진화할수록 개인의 경험, 실수, 철학이 코드에 각인된다. 그래서 진화할수록 공개하기 어려워진다 — 코드를 공개하는 건 쉽지만, 그 코드가 작동하는 이유인 철학까지는 전달할 수 없기 때문이다.

도구는 복제 가능하다. 철학은 복제 불가능하다.
그리고 시스템을 작동하게 만드는 건 도구가 아니라 철학이다.

Related Docs
함께 읽으면 좋은 문서