메이커 에반 | 2026-05-21

모델보다 중요한 건
'하니스(Harness)'입니다

반나절 만에 끝낸 대규모 마이그레이션, 그리고 회사를 나온 이유
영상 보기
+34점
같은 모델, 시스템에 따라 46→80점(커서 실험)
28~47%
하니스 개선 시 품질 향상 (프롬프트는 3% 미만)
반나절
소형 모델로 끝낸 대규모 마이그레이션(버그 1개)
주 1,300+
미니언즈 에이전트가 자동 머지하는 PR
01
하니스란 무엇인가
00:00
정의하니스(harness) = AI에게 일을 시킬 때 모델 주변에 두르는 '마구(장치) 전체'. 어떤 도구·매뉴얼을 줄지, 실수를 어떻게 잡을지, 다음에 뭘 할지 정하는 모든 장치
핵심 주장"모델은 천장을 정하고, 하니스는 그 천장에 얼마나 가까이 갈지를 정한다"
증거커서 실험: 같은 클로드·같은 벤치마크인데 주변 시스템에 따라 46→80점(34점 차)

용어풀이 — 하니스: 원래 말·낙하산을 몸에 매는 '안전 장구'. 여기선 AI 모델을 감싸 성능을 끌어내는 시스템 일체를 뜻함.

02
모델은 IQ, 하니스는 회사 시스템
02:09
같은 IQ의 신입이라도…
A 회사: 매뉴얼·리뷰 없이 "알아서 해" IQ 200도 헤맴
B 회사: 온보딩 문서 + 스펙 검토 + 자동 검사기 + 빌드 알람 6개월 뒤 결과 천지차이

핵심: IQ 130 + 좋은 시스템IQ 200 + 방치보다 결과가 낫다. 스탠퍼드 연구 — 하니스를 잘 짜면 품질 28~47%↑, 프롬프트만 다듬으면 3% 미만.

03
하니스의 11가지 요소 + 반나절 마이그레이션
02:54

연구자들은 하니스를 11가지 요소로 분석: 작업 명세, 컨텍스트 선택, 도구 접근, 프로젝트 메모리, 작업 상태, 관찰성, 실패 분석, 검증, 권한, 감사, 개입 기록. 모델은 이 중 하나일 뿐이며, 가장 변동이 적은 부분이다.

발표자의 작년 6월 사례(모델: 구형 소네트)
한 달 전부터 하니스 준비 ① 스펙 리뷰 강제(계획부터 검토) ② 워크플로우 고정(읽기·변경·테스트·커밋) ③ 자동 검사(빌드 깨지면 알람)
결과: 며칠 걸릴 작업을 반나절에, 버그 단 1개
04
스킬 기반 리팩토링 — 결과를 일정하게
04:43

AI에게 매번 "리팩토링 해줘"라고 하면 매번 결과가 다름(셰프 기분 따라 바뀌는 음식). 자주 하는 패턴을 '스킬' 단위로 정리하면 레시피 카드처럼 결과가 일정해진다.

05
도메인 기반 유지보수 — 컨텍스트를 깨끗하게
05:55
구분파일 종류별(기존)도메인 단위(권장)
구조컴포넌트/훅/유틸 폴더로 분리결제·인증 등 기능 단위로 관련 코드·문서를 한 폴더에
작업 시기능 하나 고치려 여러 폴더에서 파일 수집"결제 폴더 안에서만 작업해" — 범위를 좁혀 실수↓
매뉴얼없음도메인 전용 짧은 규칙 문서를 함께 둠. 새 결정마다 한 줄씩 누적

비유 — 신발은 신발장이 아니라 '아침에 쓰는 건 현관 옆'처럼 쓰임새별로 모으면 일상이 빨라진다. 신입·AI 모두 그 폴더만 읽으면 이해.

06
왜 회사를 나왔나 — 전략적 의미
08:49
07
지금 시작할 수 있는 실전 4단계
10:42
1. 계획부터 쓰게

"바로 코딩해" 대신 "어떻게 고칠지 정리해" — 한 줄로 품질이 확 달라짐

2. 스킬로 옮기기

같은 리팩토링 3번 이상 했다면 한 페이지 스킬로(언제·순서·확인사항)

3. 도메인 단위로

한 번에 다 바꾸지 말고 새 기능부터 도메인 폴더+규칙 문서

4. 자동 검사

빌드·테스트·린트를 자동 실행. 없으면 위 3단계도 흔들림

결론: "모델은 천장, 하니스는 사다리." 새 모델 기다리는 시간에 스킬 한 줄·매뉴얼 한 줄을 깔면 같은 모델로 두 배 일할 수 있다.