하네스 엔지니어링 — *매주 앱 하나* 를 찍어내는 스킬 파이프라인 설계
“AI 가 앱 을 만들 수 있다” 는 건 이제 놀랍지 않다. 진짜 문제 는 그 다음이다 — 한 번 이 아니라, 매주 신뢰 가능하게 반복 할 수 있는가. 일회성 마법 을 지속 생산 으로 바꾸는 것, 그게 하네스 엔지니어링 이다. 아래 그림 은 그 하네스 를 한 장 에 담은 설계다.
0. 하네스 란 — AI 가 아니라 AI 를 감싼 구조
하네스(harness) 는 말(馬) 에 씌우는 마구 다. 말 의 힘 을 일 로 바꾸는 장치. AI 에서도 같다 — 하네스 는 모델 이 아니라, 모델 의 출력 을 신뢰 가능 하고 반복 가능 하게 만드는 구조 다. 루프, 게이트, 피드백, 기억.
같은 GPT/Claude 를 써도, 하네스 가 있으면 “가끔 되는 데모” 가 “매주 나오는 제품” 이 된다. 이 그림 은 정확히 그 변환기 다.
1. 그림 읽기 — 주간 사이클 의 6 단계
한 바퀴 를 따라가 보자:
Input
→ [개발 하는 스킬] 모듈·모듈·모듈 을 조립
→ [배포 하는 스킬] dry run
→ [트래킹 하는 스킬] 4 주 관찰
→ [리포트 뽑는 스킬]
→ [회고 하는 스킬]
→ (52 주 루프) 다시 Input 으로
개발 스킬 ↕ [에셋 보관함 관리 스킬] 모듈·모듈·모듈 (축적·재사용)
각 상자 가 스킬(skill) — 재사용 가능한 능력 단위 다. 그리고 이 상자 들 을 어떤 순서 로, 어떤 게이트 로, 어떤 피드백 으로 엮었는가 — 그게 하네스 다.
2. 각 단계 를 하네스 부품 으로 뜯기
🔧 개발 스킬 = 조립 가능한 능력 (composability)
“모듈 3 개” 로 그려진 게 핵심 이다. 앱 을 통째로 만드는 게 아니라, 재사용 가능한 모듈 을 조립 한다. 이게 하네스 의 1 원칙 — 좁고 깊은 스킬 을 조합 한다. (내 서브에이전트 들 이 정확히 이 구조 — outbox-reviewer, 멱등체커 처럼.)
🚦 dry run = 되돌릴 수 있는 게이트
배포 스킬 이 곧장 프로덕션 이 아니라 dry run 을 거친다. 실제 반영 전 에 검증 하는 관문. 설계 세 축 의 가역성 그대로 — 되돌리기 쉬운 상태 에서 먼저 확인 하고, 진짜 배포 는 그 뒤. 하네스 는 실패 를 안전 하게 만든다.
👁 4 주 트래킹 = 관찰 창(observation window)
배포 하고 끝 이 아니라 4 주 를 지켜본다. 하네스 의 핵심 은 “돌려놓고 잊지 않는 것” — 관측 없는 자동화 는 폭주 한다. 이건 내가 운영 회고 에서 “hang 은 침묵 한다” 며 타임아웃·로그 를 심은 것 과 같은 원리.
📊 리포트 = 보이지 않는 걸 측정 가능 하게
트래킹 데이터 를 리포트 로 압축 한다. 하네스 는 결과 를 사람 이 판단 가능한 형태 로 만들어야 한다. 숫자 없는 반복 은 개선 이 아니라 그냥 반복.
🔁 회고 = 학습 루프 (feedback)
그림 에서 가장 중요한 화살표 — 회고 → (52주 루프) → 개발 로 되돌아간다. 이 피드백 이 없으면 매주 같은 실수 를 반복 한다. 회고 가 붙어야 사이클 이 나선(spiral) 이 된다. (내 금요일 10분 복기 를 시스템 화 한 것.)
🗄 에셋 보관함 = 영속 기억 (state/memory)
개발 스킬 과 양방향 으로 연결 된 보관함. 만든 모듈 을 버리지 않고 축적 하고, 다음 주 에 다시 꺼내 쓴다. 하네스 에 기억 이 없으면 매주 백지 에서 시작 한다 — 복리 가 안 붙는다. 자율 에이전트 의 memories/ 와 같은 역할.
♾ 52 주 루프 = 복리 의 바깥 고리
가장 바깥 화살표. 이 사이클 이 1 년(52 주) 돈다. 한 주 의 산출 은 작아도, 회고 로 개선 되고 에셋 으로 축적 되며 52 번 돌면 완전히 다른 결과 가 된다. 하네스 의 존재 이유 는 바로 이 복리 다.
3. 이 하네스 가 설계 로서 좋은 이유
이 그림 은 단순한 순서도 가 아니라 잘 설계된 하네스 의 조건 을 거의 다 갖췄다:
| 하네스 조건 | 그림 의 대응 | 없으면 |
|---|---|---|
| 조합 가능성 | 개발/에셋 의 모듈 | 매번 통짜 로 만듦, 재사용 0 |
| 안전 게이트 | dry run | 실패 가 곧 프로덕션 사고 |
| 관측 | 4 주 트래킹 | 폭주 를 못 잡음 |
| 측정 | 리포트 | 개선 근거 없음 |
| 피드백 | 회고 → 개발 | 같은 실수 반복 |
| 기억 | 에셋 보관함 | 복리 안 붙음 |
| 장기 루프 | 52 주 | 일회성 으로 끝남 |
빠진 걸 굳이 꼽자면 — 회고 가 에셋 보관함 도 갱신 하면(무엇 을 버릴지 결정) 더 완결 된다. 지금 은 회고 가 개발 로만 피드백 하는데, “안 쓰는 모듈 아카이브” 까지 회고 가 관장 하면 보관함 이 무한 증식 하지 않는다.
4. 하네스 엔지니어링 의 원칙 (이 그림 이 말하는 것)
- AI 를 늘리지 말고, AI 를 감싼 구조 를 늘려라 — 더 똑똑한 모델 보다, 게이트·피드백·기억 이 있는 하네스 가 결과 를 바꾼다.
- 일회성 을 루프 로 — “한 번 만들기” 가 아니라 “매주 만들고 개선 하기”. 루프 가 복리 를 만든다.
- 실패 를 안전 하게 — dry run 같은 게이트 로, 실패 가 사고 가 되지 않게.
- 관측 없는 자동화 는 없다 — 돌려놓고 잊으면 폭주 한다. 트래킹·리포트 는 옵션 이 아니다.
- 기억 을 축적 하라 — 에셋 보관함 없이 는 매주 백지. 복리 는 기억 에서 나온다.
맺으며
모델 은 이제 상향 평준화 되고 있다. 차이 를 만드는 건 그 모델 을 어떤 하네스 에 태우는가 다. 이 그림 처럼 — 개발 을 모듈 로 쪼개고, dry run 으로 막고, 4 주 지켜보고, 리포트 로 재고, 회고 로 배우고, 에셋 으로 쌓고, 52 번 반복 하는 구조.
하네스 엔지니어링 은 “AI 로 무엇 을 만드나” 가 아니라 “AI 가 반복 적 으로 잘 하게 만드는 구조 를 어떻게 짜나” 다. 그리고 그 구조 는, 이 블로그 에서 반복해 온 원칙 들 과 정확히 같다 — 경계, 게이트, 피드백, 기억. 백엔드 든 에이전트 든, 신뢰 가능한 시스템 의 뼈대 는 결국 하나 였다.
좋은 하네스 는 평범한 모델 로도 비범한 결과 를 반복 하게 만든다.