AI 에이전트 하네스 vs 모델: 초심자는 무엇부터 사야 하나
지금 쓰는 시스템이 업무를 정의하고, 권한을 제한하고, 진행 상태를 보존하고, 결과를 검사하고, 실패를 중단하고, 실행 기록을 남길 수 있을 때만 더 좋은 모델을 사세요. 이 부분이 빠져 있다면 현재 모델을 둘러싼 하네스·템플릿·운영 절차를 먼저 개선하는 편이 합리적입니다. 강한 모델은 한 번의 결과를 개선할 수 있지만, 하네스는 반복 실행을 검수 가능하게 만듭니다.
짧은 답
AI 모델은 다음 응답을 만듭니다. 에이전트 하네스는 모델이 받을 맥락, 사용할 수 있는 도구, 남겨야 할 상태, 사람 승인이 필요한 시점, 결과 검사 방법, 실패 후 경로를 결정합니다.
초심자의 기본 순서는 다음과 같습니다.
- 완료 결과가 보이는 반복 업무 하나를 고릅니다.
- 안전하게 실행할 수 있는 최소 하네스를 만듭니다.
- 같은 업무를 세 번 반복하고 실패를 기록합니다.
- 같은 모델 능력 한계가 반복 실행을 막을 때만 모델을 업그레이드합니다.
이것은 구매 판단 규칙이지 모델 벤치마크가 아닙니다. 특정 하네스·모델·상품이 시간이나 매출을 만든다고 주장하지 않습니다.
왜 지금 이 질문인가
빌더로그는 2026-07-29 최근 Reddit 대화에서 주제를 찾은 뒤 살아남은 후보를 GitHub·Hacker News·YouTube 근거로 확장했습니다. ‘모델보다 에이전트 하네스’ 묶음에는 4개 출처 유형의 근거 17개와 기록된 네이티브 상호작용 34,269건이 포함됐습니다. 2026-07-22 올라온 시작 게시물은 하네스가 모델보다 중요하다는 주장을 담았고, 수집 시점에 댓글 42개가 있었습니다.
이 숫자는 방향성 신호이지 시장 조사 결과가 아닙니다. 상호작용은 순 구매자 수가 아니고, 최초 발견 피드는 Reddit이었으며, 해당 조사에서 X 발견 기능은 사용할 수 없었습니다. 지금 다룰 만한 질문이라는 근거는 되지만 구매 의도나 보편 법칙을 증명하지는 않습니다.
기술적 근거는 더 오래 적용할 수 있습니다.
- Addy Osmani의 2026년 4월 글은 하네스를 모델 주변의 프롬프트·도구·맥락 정책·훅·샌드박스·오케스트레이션·관찰·복구로 설명합니다.
- Anthropic의 2026년 3월 하네스 보고서는 기획자·생성자·평가자 역할, 구조화된 인계, 브라우저 기반 검증, 명시적인 스프린트 계약을 설명합니다. 공개된 한 실험에서 전체 하네스는 단일 에이전트보다 훨씬 기능적인 결과를 만들었지만 비용도 20배 이상이었습니다.
- Harness Handbook 프로젝트와 2026년 7월 논문은 실제 행동이 프롬프트·도구 래퍼·권한·상태·샌드박스 실행·대체 경로에 나뉘어 있다고 설명합니다. 모델 이름만으로는 파일 삭제 전 확인하는지, 예외 뒤 복구하는지 알 수 없습니다.
중립적인 결론은 ‘하네스가 항상 모델보다 낫다’가 아닙니다. 비용·업무·도구·상태·검증·권한을 보이지 않게 두면 비교 자체가 불완전하다는 뜻입니다.
모델 구매와 하네스 구매는 다르다
| 구매 대상 | 개선할 수 있는 것 | 혼자서는 제공하지 못하는 것 |
|---|---|---|
| 더 좋은 모델 | 추론, 지시 준수, 코딩, 글쓰기, 인식, 더 긴 유효 작업 | 업무 정의, 계정 권한, 승인 출처, 합격 기준, 복구, 담당자 |
| 더 좋은 하네스 | 맥락 전달, 도구, 상태, 승인, 검사, 로그, 재시도, 복구 | 기본 모델에 실제로 없는 능력 |
| 더 많은 에이전트 | 필요한 경우 역할 분리와 병렬 작업 | 명확한 목표, 신뢰할 수 있는 인계, 독립 평가 |
| 더 많은 자동화 | 경로가 안정된 뒤의 반복 | 그 경로가 정확하고 안전하며 반복할 가치가 있다는 증거 |
가장 싼 모델도 정의되지 않은 워크플로 안에서는 나쁜 구매가 될 수 있습니다. 반대로 단순 채팅과 점검표로 끝날 일에 복잡한 하네스를 붙이는 것도 낭비입니다.
14점 하네스 점검표
각 항목에 0점, 1점, 2점을 줍니다.
| 하네스 점검 | 0점 | 1점 | 2점 |
|---|---|---|---|
| 업무 | “사업을 도와줘” | 업무 이름은 있지만 완료가 모호함 | 트리거 하나와 완료 결과 하나가 명확함 |
| 맥락 | 채팅·오래된 메모·불명확한 출처가 섞임 | 일부 승인 자료가 분리됨 | 정확한 출처·버전·제외 범위를 기록함 |
| 권한 | 보내기·결제·삭제·접근 변경이 가능함 | 승인이 있지만 범위가 넓음 | 모든 외부·특권 행동에 정확한 승인 지점이 있음 |
| 상태 | 진행 상황이 채팅에만 남음 | 파일은 있지만 이어받기 규칙이 모호함 | 상태·다음 단계·담당자·버전이 재시작 뒤에도 남음 |
| 검증 | 만든 에이전트가 스스로 괜찮다고 평가함 | 사람이 비공식적으로 확인함 | 합격 기준이나 독립 평가자가 결과를 실패 처리할 수 있음 |
| 복구 | 될 때까지 재시도함 | 수동 대체 경로가 있음 | 재시도 한도·중단 조건·복구·담당자가 명시됨 |
| 기록 | 지속되는 기록이 없음 | 결정 맥락이 빠진 로그만 있음 | 입력 참조·행동·결과·검토자·비용·예외가 기록됨 |
점수는 보수적으로 해석합니다.
- 0-5점: 이 업무를 위해 다른 모델을 사지 말고 수동 절차부터 정의합니다.
- 6-10점: 실패한 하네스 항목을 한 번에 하나씩 개선합니다.
- 11-14점: 모델 업그레이드를 고민하기 전에 비교 가능한 실행을 세 번 합니다.
이 기준은 빌더로그의 구매 판단 규칙입니다. 품질·안전·수익을 예측하는 기준으로 검증되지 않았습니다.
결제 전에 같은 업무를 실행한다
승인된 비민감 업무 중 초안이나 로컬 파일을 만드는 일을 고릅니다. 외부 행동 없이 끝낼 수 있는 주간 조사 요약이 적당한 예입니다.
다음 실행 계약을 작성합니다.
트리거:
승인된 출처:
완료 결과:
합격 기준:
허용된 외부 행동: 없음
사람 검토자:
최대 시도 횟수:
최대 비용:
중단 조건:
수동 대체 경로:
결과 기록 위치:현재 모델과 하네스로 같은 업무를 세 번 실행하고 아래를 기록합니다.
- 같은 실패가 반복됐는지
- 모델에 지식이나 능력이 실제로 부족했는지
- 맥락이나 지시가 잘못됐는지
- 도구·권한·환경이 실패했는지
- 독립 검사를 통과했는지
- 정한 한도 안에서 중단했는지
한 번에 변수 하나만 바꿉니다. 모델·프롬프트·도구·평가자를 모두 바꾸면 무엇이 실패를 해결했는지 알 수 없습니다.
실제 병목을 찾는 법
모델이 진짜 병목인 경우
다음 조건을 모두 만족할 때 더 강한 모델에 비용을 씁니다.
- 업무·입력·완료 기준·검토자가 안정적입니다.
- 비교 가능한 실행에서 같은 능력 실패가 반복됩니다.
- 하네스가 올바른 맥락과 도구 결과를 전달했습니다.
- 더 단순한 결정 규칙이나 수동 단계로 해결할 수 없습니다.
- 장기 결제 전에 같은 사례로 강한 모델을 시험할 수 있습니다.
- 추가 비용이 기록된 실행 한도 안에 들어옵니다.
예를 들어 승인된 긴 문서에서 관계를 반복해서 놓치거나, 저장소 맥락과 테스트가 정확한데도 코딩 업무를 실패하거나, 구체적인 평가표를 줬는데도 시각 결과가 계속 사용할 수 없는 경우입니다.
“답이 약해 보였다”는 근거로 부족합니다. 실패한 합격 기준을 이름으로 적어야 합니다.
하네스가 병목인 경우
다음과 같다면 하네스를 먼저 고칩니다.
- 요청이 실행할 때마다 달라집니다.
- 오래되거나 서로 충돌하는 출처를 받습니다.
- 도구 설명이 겹치거나 권한 범위가 넓습니다.
- 맥락이 초기화되면 진행 상태가 사라집니다.
- 제작자가 자기 결과를 직접 평가합니다.
- 재시도 횟수에 한도가 없습니다.
- 실제 미리보기를 확인하지 않고 외부 행동이 가능합니다.
- 최종 결과만 보고 무슨 일이 있었는지 재구성할 수 없습니다.
이런 문제는 모델과 무관한 부분이 많아서 구독 업그레이드는 실패를 더 빠르게 만들 수 있습니다.
초심자용 최소 하네스
첫 하네스에는 에이전트 열 명이 필요하지 않습니다. 보이는 구성 일곱 개면 됩니다.
1. 업무 계약 하나
2. 승인 출처 폴더 하나
3. 실행자 하나
4. 사람 승인 지점 하나
5. 합격 점검표 하나
6. 재시도·중단 규칙 하나
7. 완료 기록 하나실제 분기나 담당자가 여러 명일 때만 오케스트레이터를 추가합니다. 결과가 비싸거나 주관적이거나 제작자가 과대평가하기 쉬울 때 독립 평가자를 추가합니다. 독립 작업을 합치고 검사할 수 있을 때만 병렬 에이전트를 추가합니다.
복잡성도 비용입니다. Anthropic의 공개 사례는 풍부한 하네스가 더 강한 결과를 만들 수 있는 동시에 훨씬 많은 시간과 비용을 쓸 수 있음을 보여줍니다. 따라서 구매 판단은 추상적인 모델 대 하네스가 아닙니다. 가치 있는 업무 하나를 반복할 만큼 신뢰성 있게 끝내는 가장 작은 시스템을 고르는 일입니다.
실패 가능성과 한계
현재 가장 강하게 검증할 수 있는 하네스 근거가 에이전트형 지식 업무와 코딩에 몰려 있어 이 가이드도 그쪽에 가중돼 있습니다. 고객지원·재무·의료·법률·물리 세계 업무에는 이 점검표 밖의 분야별 통제가 필요합니다.
커뮤니티 근거는 감사된 구매자 조사가 아닙니다. GitHub 활동·댓글·조회·포인트는 관심을 측정할 뿐 사업 가치를 측정하지 않습니다. Anthropic 비교는 문서화된 실험이지 독립 벤치마크가 아니고, 더 좋은 결과를 만든 하네스는 비용도 훨씬 컸습니다. Harness Handbook은 구현 행동을 추적하지만 특정 시스템의 안전을 인증하지 않습니다.
이 결정을 시험하려고 실제 계정 권한을 주지 마세요. 공개·가상·삭제 처리된 자료나 명시적으로 승인된 데이터만 사용합니다.
최종 판단
초심자라면 워크플로가 업무·맥락·권한·상태·검증·복구·결과 기록을 설명하지 못할 때 모델보다 하네스를 먼저 삽니다. 안정된 하네스에서 같은 능력 한계가 비교 가능한 실행에 반복될 때만 모델을 삽니다.
실전 순서는 다음과 같습니다.
수동 업무 → 최소 하네스 → 기록된 실행 3회 → 변수 하나 비교 → 구매 판단
충동적으로 구독하는 것보다는 느리지만, 나중에 모델이 병목이 아니었다는 사실을 발견하는 것보다는 빠릅니다.