Philosophy

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

하네스는 AI가 일을 대충 끝내지 못하도록 내가 만들어 둔 검사 규칙과 자동화 장치를 말한다. 이 장치는 오래 쓸수록 공개하기 어려워진다. 코드를 공개해도 "왜 이렇게 만들었는지"까지 이해하는 사람은 극소수이기 때문이다. 도구가 핵심이 아니라, 그 도구를 쓰는 사람의 철학이 핵심이다.

Section 01
시스템이 곧 개인의 DNA
~/.claude/ ├── hooks/ ← 33개. 반복한 실수에서 태어난 자동 검사 규칙 ├── skills/ ← 45개. 프로젝트마다 정해둔 작업 규칙 ├── rules/ ← 15개. 개인의 개발 철학 ├── agents/ ← 13개. 개인의 작업 흐름 ├── logs/ │ ├── self-improve.jsonl ← 51건의 실수 이력 │ └── feedback.jsonl ← 불만 패턴 └── skills/*-scaffold/ ← 프로젝트별 '하지 말 것' 목록
공개 경계 복제 가능 — 코드 hooks/ · skills/ · scripts/ scaffold-violation-check.sh · exit 2 패턴 복제 불가능 — 철학 "말로만 부탁하는 규칙은 안 지켜진다"는 깨달음 "실수에서 규칙이 태어나야 한다"는 설계 5개월간 축적된 실수·불만·판단의 맥락 프로젝트별 고유 경험 (다른 사람에게 무의미) 시스템을 작동하게 만드는 건 여기

API 키(비밀번호 같은 접속 열쇠)를 지워도, scaffold 규칙 — 프로젝트마다 반복한 실수를 모아 둔 '하지 말 것' 목록 — 은 "이 프로젝트에서 날짜 입력창 설정을 빠뜨려 같은 버그를 세 번이나 고쳤다"는 개인의 경험에서 나온 것이다. 남에게는 아무 의미 없는 규칙이다.

대부분의 기능 조각과 작업 흐름이 서로 얽혀 있어서, 코드 저장소 하나로 딱 떼어내기 어렵다. 게다가 나만의 방향과 철학이 배어 있어, 공개할수록 관리할 거리만 늘어난다.

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) 세워야 하는가"에 대한 경험
"프로젝트마다 독립적으로 진화해야 한다"는 판단
"AI에게 말로 시켜 만드는 방식(바이브코딩)은 한계가 있다"는 관찰
핵심

왼쪽은 git clone 명령으로 코드를 통째로 내려받아 그대로 복사할 수 있다. 오른쪽은 복사할 수 없다. 그리고 시스템을 작동하게 만드는 건 오른쪽이다.

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

그대로 복사 → "안 되는데요?"

scaffold-violation-check.sh(규칙 위반을 자동으로 막는 검사 스크립트)를 그대로 복사해도, 왜 이 패턴을 차단해야 하는지 를 모른다. 자기 프로젝트에는 다른 패턴이 필요한데, 그걸 어떻게 뽑아내야 할지 모른다.

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

철학을 이해한 사람

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

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

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

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

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

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

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

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

Section 05
공개의 손익 계산 (ROI)
공개 시 비용
문의 관리 (대부분 "설치가 안 돼요")
개인정보 분리 작업
누구나 쓰게 만드는 일반화 작업
문서 작성 / 유지
코드 수정 요청(PR) 검토
비공개 시 이득
시스템 진화에 100% 집중
경쟁 우위 유지
자신의 문제만 해결
관리할 거리 제로
철학을 글로 공유 (이것으로 충분)

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

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

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

공유할 수 있는 개념

"폐루프 자가개선이란 무엇인가"
"말로 된 규칙(SOFT)과 강제로 막는 규칙(HARD)의 차이"
"실수에서 규칙이 태어나는 구조"
"프로젝트별 독립 진화가 필요한 이유"
"세션이 바뀌어도 기억이 이어질 때 달라지는 것"

공유할 수 없는 것

5개월간 축적된 33개 hook의 개별 맥락
4개 프로젝트마다 쌓인 '하지 말 것(NEVER DO)' 규칙들
51건의 자동 개선이 만든 고유한 규칙 체계
사용자 불만이 쌓인 기록 파일의 패턴
이 모든 것을 잇는 개인만의 작업 흐름

결론

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

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

Related Docs
함께 읽으면 좋은 문서