메이커 에반은 같은 모델을 써도 결과가 크게 갈리는 이유를 ‘하니스’라는 단어로 풀어낸다. 반나절 만에 끝낸 대규모 마이그레이션, 커서의 실험, 스탠포드 연구, 그리고 본인이 회사를 나온 이유까지 이어지면서 결국 중요한 건 모델 교체보다 모델 주변 시스템 설계라는 이야기에 힘이 실린다.
flowchart LR A[같은 모델인데 결과 차이가 큼] --> B[모델보다 주변 시스템이 더 크게 작동] B --> C[스펙 리뷰·워크플로우·스킬·도메인 매뉴얼·자동 검사 구축] C --> D[같은 모델로 더 안정적이고 반복 가능한 결과 확보]
핵심 요약
- 같은 클로드 모델과 같은 벤치마크라도 주변 시스템을 어떻게 짜느냐에 따라 점수가 46점에서 80점까지 달라졌다는 커서의 실험을 소개한다.
- 발표자는 하니스를 AI 주변의 모든 장치로 설명한다. 도구, 매뉴얼, 검증, 작업 상태, 권한, 개입 기록 같은 요소가 여기에 포함된다.
- 작년 6월 대규모 코드 마이그레이션에서 소넷 모델로도 반나절 만에 작업을 끝냈고 버그는 사소한 것 1개뿐이었다고 말한다.
- 그 결과를 만든 건 모델 교체가 아니라 스펙 리뷰 강제, 파일 읽기-변경-테스트-커밋 워크플로우, 빌드 실패 알림 같은 시스템이었다.
- 실전 루틴으로는 계획 먼저 쓰게 하기, 반복 작업을 스킬로 옮기기, 도메인 단위 구조 만들기, 빌드·테스트·린트 자동 검사를 깔기를 제안한다.
왜 지금 중요한가
영상은 새 모델 이름과 벤치마크 점수에 시선이 몰린 시점에서, 정작 결과를 바꾸는 건 모델 위에 깔린 운영 체계라고 짚는다. 발표자가 직접 같은 소넷 모델로 며칠씩 헤매던 작업을 반나절로 줄였다고 말하는 만큼, 이 이야기는 도구 비교를 넘어서 팀의 작업 방식과 유지보수 루틴을 다시 보게 만든다.
주요 내용
1. 같은 모델인데 왜 누구는 잘 쓰고 누구는 막힐까
발표자는 한때 자신도 새 모델이 나오면 바로 갈아타고 벤치마크 점수를 확인하던 쪽이었다고 말한다. 그런데 어느 순간 같은 클로드를 쓰는데도 어떤 사람은 막힘 없이 잘 쓰고, 어떤 사람은 여전히 AI가 멀었다고 한탄하는 장면이 이상하게 보이기 시작했다고 한다.
여기서 가져온 근거가 커서의 실험이다. 같은 클로드 모델, 같은 벤치마크인데도 주변 시스템 설계에 따라 점수가 46점에서 80점까지 오갔다고 한다. 발표자는 이 차이를 “같은 F1 드라이버에게 경운기를 주느냐, 레이싱카를 주느냐”의 차이로 비유한다.
2. 하니스는 모델 주변에 두르는 작업 시스템이다
하니스는 AI에게 일을 시킬 때 함께 주는 모든 장치다. 어떤 도구를 쓸지, 어떤 매뉴얼을 읽힐지, 실수는 어떻게 잡을지, 다음 행동은 어떻게 정할지 같은 것들이 전부 포함된다고 설명한다.
연구자들이 분석한 11가지 요소도 구체적으로 나온다. 작업 명세, 컨텍스트 선택, 도구 접근, 프로젝트 메모리, 작업 상태, 관찰성, 실패 원인 분석, 검증, 권한, 엔트로픽 감사, 개입 기록이다. 발표자는 이걸 신입 직원 비유로 다시 풀어낸다. 매뉴얼도 없고 코드 리뷰도 없는 회사와, 온보딩 문서와 스펙 검토, PR 자동 검사, 빌드 알람이 있는 회사를 비교하면 결과가 같을 수 없다는 얘기다.
여기에 스탠포드 연구도 덧붙인다. 하니스를 잘 짜면 결과물 품질이 28%에서 47%까지 올라가지만, 프롬프트만 다듬으면 3%도 안 올라간다고 한다. 모델은 그중 하나일 뿐이고, 나머지 열 가지를 어떻게 설계하느냐가 결과 대부분을 결정한다는 주장이다.
3. 반나절 마이그레이션을 만든 건 모델이 아니라 순서였다
작년 6월 회사에서 큰 마이그레이션이 잡혔을 때, 발표자는 한 달 전부터 하니스를 진지하게 짜고 있었다고 말한다. 먼저 작업에 들어가기 전에 스펙 리뷰를 강제로 거치게 했고, AI에게 바로 수정 지시를 내리지 않고 무엇을 어떻게 고칠지 계획부터 세우게 했다.
그다음에는 파일 읽기, 변경, 테스트, 커밋이 매번 같은 순서로 흘러가게 워크플로우를 만들었다. 마지막으로 빌드가 한 번이라도 깨지면 바로 신호가 오도록 자동 검사도 깔았다. 그 결과 마이그레이션 당일에는 오전에 시작해서 점심 전에 거의 끝났고, 오후에는 검수만 했으며, 버그는 사소한 것 한 개뿐이었다고 설명한다.
발표자는 이 성과를 모델 덕분으로 돌리지 않는다. 같은 소넷 모델로도 예전에는 비슷한 작업에서 며칠씩 헤맸고, 달라진 건 “주변에 깐 시스템” 하나였다고 선을 긋는다.
4. 실전은 4단계로 시작하라고 정리한다
실행 루틴은 꽤 명확하다. 첫 단계는 작업 전에 계획부터 쓰게 하는 것이다. 바로 코드를 짜라고 하지 말고 어떻게 고칠지 정리시키면 결과물 품질이 확 달라진다고 말한다.
둘째는 자주 하는 일을 스킬로 옮기는 것이다. 같은 종류의 리팩토링을 세 번 이상 했다면 스킬로 옮길 신호라고 한다. 언제 발동하는지, 어떤 순서로 가는지, 끝나고 무엇을 확인할지만 적어도 한 페이지면 충분하다고 설명한다. 하나의 스킬을 여러 섹션으로 나눠 멀티 섹션으로 만들면 그 자체가 자산이 된다고도 덧붙인다.
셋째는 코드를 도메인 단위로 묶는 것이다. 파일 종류 기준으로 나뉜 코드베이스를 한 번에 다 바꾸지 말고, 새 기능부터 도메인 폴더를 만들고 그 안에 규칙과 짧은 컨텍스트를 넣으라고 한다. 넷째는 자동 검사다. 작업이 끝나면 빌드, 테스트, 린트가 자동으로 돌게 해서 사람이 전부 눈으로 거르지 않게 해야 앞선 세 단계도 흔들리지 않는다고 정리한다.
원문 발화 하이라이트
- [01:19-01:23] “주변 시스템을 어떻게 짜느냐에 따라 점수가 46점에서 80점까지 왔다 갔다 했어요. 34점 차이예요.”
- [02:29-02:34] “하니를 잘 짜면 결과물 품질이 28%에서 47%까지 올라간대요. 프롬프트만 다듬으면 3%도 안 올라가요.”
- [04:02-04:08] “오전에 시작했어요. 점심 먹기 전에 거의 다 끝나 있었어요. 오후엔 검수만 했어요. 반나절 버그는 딱 한 개.”
- [10:46-10:59] “작업 들어가기 전에 AI한테 계획부터 쓰게 해 보세요. 바로 코드자라고 하지 마시고 어떻게 고칠 건지 한번 정리시켜요. 그거 한 줄 추가했을 뿐인데 결과물 품질이 확 달라져요.”
- [13:27-13:32] “모델은 천장이지만 하니스는 사다리라는 거예요. 그 사다리를 직접 짜기 시작한 순간 천장은 더 이상 한계가 아니더라고요.”
바로 실행해 보기
- 다음 작업부터는 AI에게 바로 수정을 맡기지 말고, 먼저 어떻게 고칠지 계획을 쓰게 한 뒤 그 계획을 한 번 검토한다.
- 최근 세 번 이상 반복한 리팩토링이 있다면 한 페이지짜리 스킬로 옮긴다. 언제 발동하는지, 어떤 순서로 진행하는지, 끝나고 무엇을 확인할지만 먼저 적는다.
- 새 기능 하나를 도메인 폴더로 만들고 그 안에 지켜야 할 규칙과 짧은 컨텍스트를 넣은 뒤, 작업이 끝나면 빌드·테스트·린트가 자동으로 돌게 연결한다.
참고
영상 메타
- 채널: 메이커 에반 | Maker Evan
- 제목: 모델보다 중요한건 하니스 입니다.
- 게시 시각(원문): 2026-05-19T23:06:38+00:00
- 영상: https://www.youtube.com/watch?v=8DySHAuAmts
- 썸네일: https://i1.ytimg.com/vi/8DySHAuAmts/hqdefault.jpg
수집 품질
- 자막 세그먼트: 421개
- 자막 문자수: 7628자
- 챕터 추출: 8개
- 콘텐츠 생성: Subagent 기반
AI 생성 도구를 활용해 초안을 구성했고, 원영상 발화와 공개 자료를 교차 확인해 정리했습니다.