|
TL;DR — 2026년, AI 에이전트에게 “마구(harness)”를 씌우는 시대가 열렸다. 이 글에서는 카카오 AI Native 전략 팀 리더 황민호가 공개한 오픈소스 하네스와 개인용 테크라이팅 하네스를 비교 분석하며, 하네스 엔지니어링이 왜 2026년의 핵심 역량이 되는지 탐구한다. 대상 독자: IT 개발자 & AI 도구 활용자 | 작성 기준: 2026-03 |

“클로드 코드는 치매에 걸린 아인슈타인이다.”
유튜버 메이커 에반의 이 비유는 AI 코딩 에이전트의 본질을 정확히 꿰뚫는다. 천재적 능력을 갖추고 있지만, 세션이 바뀌면 모든 맥락을 잊어버린다. 프롬프트 하나로 시작한 대화는 컨텍스트가 쌓이면서 “컴팩션”이 발동되고, 지시 위반과 버그 재발이 반복된다.
하네스(Harness)는 이 문제에 대한 구조적 해답이다. 등산할 때 몸에 묶는 안전장비처럼, AI 에이전트가 사용자의 방식대로 일관되고 실수 없이 작동하도록 잡아주는 구조화된 사전 설정(Structured Pre-Configuration)이다. 단순히 CLAUDE.md에 규칙을 나열하는 수준을 넘어, 에이전트의 역할을 정의하고, 스킬을 생성하며, 팀을 구성하는 메타 시스템까지 포함한다.
|
용어 정리
|
하네스를 이해하려면 먼저 그 실행 환경인 Agent Teams를 알아야 한다. Claude Code v2.1.32부터 도입된 실험적 기능으로, 여러 Claude Code 인스턴스가 하나의 팀으로 동작한다.
| 구성요소 | 역할 |
|---|---|
| Team Lead | 메인 세션. 팀 생성, 작업 할당, 결과 종합 |
| Teammates | 독립 Claude Code 인스턴스. 자체 컨텍스트 윈도우에서 작동 |
| Shared Task List | 팀원들이 claim하고 완료하는 공유 작업 목록 |
| Mailbox | 에이전트 간 직접 메시징 시스템 |
| 항목 | Subagent | Agent Teams |
|---|---|---|
| 통신 | 메인에게만 결과 반환 | 팀원 간 직접 메시지 교환 |
| 조율 | 메인이 모든 작업 관리 | 공유 Task List로 자체 조율 |
| 컨텍스트 | 자체 보유, 결과 요약 반환 | 자체 보유, 완전 독립 |
| 토큰 비용 | 낮음 | 높음 (별도 인스턴스) |
| 최적 용도 | 결과만 중요한 집중 작업 | 토론과 협업이 필요한 복잡 작업 |
핵심은 팀원들이 프로젝트의 CLAUDE.md, MCP 서버, Skills를 자동으로 로드한다는 점이다. 즉, 하네스에서 정의한 스킬과 설정이 모든 팀원에게 전파된다. 하네스가 Agent Teams의 “공유 DNA” 역할을 하는 셈이다.
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
} |
|
출처: github.com/revfactory/harness — Apache 2.0 License, v1.0.1 (2026-03-28) |
민호의 하네스는 단순한 스킬이 아니라 “스킬을 만드는 스킬”, 즉 메타 스킬(Meta-Skill)이다. 사용자가 “이 프로젝트에 맞는 하네스를 만들어줘”라고 말하면, 도메인을 분석하고, 팀 아키텍처를 설계하고, 에이전트와 스킬을 자동 생성한다.
| Phase | 명칭 | 핵심 활동 |
|---|---|---|
| 1 | 도메인 분석 | 해결할 문제 도메인, 제약 조건, 목표 파악 |
| 2 | 팀 아키텍처 설계 | 6가지 패턴 중 선택 (Pipeline, Fan-out/Fan-in, Expert Pool 등) |
| 3 | 에이전트 정의 생성 | .claude/agents/{name}.md 파일 자동 생성 |
| 4 | 스킬 생성 | .claude/skills/{name}/skill.md Progressive Disclosure 적용 |
| 5 | 통합 & 오케스트레이션 | 에이전트 간 데이터 흐름, 통신 규칙 연결 |
| 6 | 검증 & 테스트 | with-skill vs without-skill A/B 비교 검증 |
민호의 하네스가 제공하는 팀 설계 패턴은 분산 시스템 아키텍처에서 익숙한 구조들이다.
| 패턴 | 구조 | 최적 용도 |
|---|---|---|
| Pipeline | A → B → C → D 순차 | 강한 순차 의존 (소설 집필 등) |
| Fan-out / Fan-in | 병렬 처리 후 머지 | 동일 입력의 다각도 분석 (리서치) |
| Expert Pool | 라우터가 적합한 전문가 선택 | 입력 유형별 분기 (코드 리뷰) |
| Producer-Reviewer | 생성 → 검증 루프 (최대 2~3회) | 품질 중요 산출물 (웹툰 패널) |
| Supervisor | 중앙 에이전트가 동적 분배 | 가변 워크로드 (코드 마이그레이션) |
| Hierarchical Delegation | Top-down 재귀 위임 | 자연적 계층 구조 문제 |
복합 패턴도 지원한다: Fan-out + Producer-Reviewer, Pipeline + Fan-out, Supervisor + Expert Pool 등을 조합하여 실제 프로젝트의 복잡성에 대응할 수 있다.
황민호님의 A/B 실험 결과(revfactory/claude-code-harness)는 하네스의 효과를 수치로 보여준다.
| 지표 | 하네스 없음 | 하네스 적용 | 차이 |
|---|---|---|---|
| 평균 품질 점수 | 49.5 | 79.3 | +60% |
| 승률 (15개 태스크) | 0% | 100% | 15전 15승 |
| 출력 분산 | 높음 | -32% | 일관성 향상 |
특히 복잡도가 높을수록 효과가 커진다: Basic +23.8, Advanced +29.6, Expert +36.2. 단순 작업에서는 차이가 적지만, 전문가급 작업에서 하네스의 진가가 드러난다.
revfactory/harness-100 리포지토리에는 10개 도메인에 걸쳐 200개의 프로덕션 레디 패키지가 포함되어 있다. 콘텐츠 제작, 소프트웨어 개발, 데이터/AI, 비즈니스 전략, 교육, 법률, 헬스케어 등 도메인별 4~5개의 전문 에이전트와 오케스트레이터 스킬로 구성된다. 1,808개의 마크다운 파일이 총집합한 이 리포지토리는 하네스 엔지니어링의 실전 카탈로그라 할 수 있다.
| 원칙 | 설명 |
|---|---|
| 메타 스킬 | 개별 스킬이 아닌, 에이전트 생태계 전체를 생성 |
| 구조화된 사전 설정 | 즉흥 프롬프팅 대신 역할/프로토콜/절차를 사전 정의 |
| Progressive Disclosure | 필요한 참조만 로드하여 컨텍스트 윈도우 효율화 |
| Why-First 문서화 | 규칙보다 이유를 설명하여 LLM이 엣지 케이스를 판단하도록 |
| 경계 검증 | QA는 개별 컴포넌트가 아닌 경계면 불일치에 집중 |
이제 우리 프로젝트의 BloomLabs Content Harness(테크라이팅 하네스)와 민호의 하네스를 나란히 놓고 비교해 보자. 하나는 “팀용 범용 생성기”이고, 다른 하나는 “개인용 콘텐츠 특화 시스템”이다.
| 비교 항목 | 민호의 하네스 (revfactory) | 테크라이팅 하네스 (BloomLabs) |
|---|---|---|
| 목적 | 도메인 특화 에이전트 팀을 자동 생성하는 메타 스킬 | 콘텐츠 작성 품질 관리를 위한 개인용 하네스 |
| 대상 사용자 | 모든 도메인의 팀 (범용) | 테크 콘텐츠 작성자 (특화) |
| 실행 모드 | Agent Teams (권장) / Sub-agents | Sub-agents 기반 Agentic Loop |
| 에이전트 수 | 도메인별 가변 (자동 생성) | 3개 고정 (researcher, writer, evaluator) |
| 스킬 수 | 도메인별 자동 생성 | 11개 수동 정의 + 통합 |
| 워크플로우 | 6 Phase (도메인 분석 → 검증) | 7 State (idle → recording) |
| 아키텍처 패턴 | 6가지 + 복합 패턴 | Producer-Reviewer 단일 패턴 |
| 콘텐츠 유형 | 도메인별 무한 확장 | 8종 (A~F + P/W) |
| 평가 시스템 | with/without A/B 비교 | 5축 100점 + 디자인 3축 100점 |
| 게이미피케이션 | 없음 | RPG 시스템 (레벨/업적/XP) |
| 발행 매체 | 해당 없음 (코드 산출물) | 5개 매체 (Memorizer, Confluence, Wiki 등) |
| 로그 관리 | 검증 결과 저장 | 이벤트 소싱 + 스냅샷 압축 |
| 버전 | v1.0.1 (Apache 2.0) | v0.10.0 (개인 프로젝트) |
2026년 하반기, 하네스 엔지니어링은 특정 직군을 넘어 모든 전문가에게 확산될 것이다.
| 전문가 유형 | 하네스 활용 시나리오 | 기대 패턴 |
|---|---|---|
| 개발자 | 코드 리뷰 팀 (보안/성능/테스트 전문가), CI/CD 자동화, 코드 마이그레이션 | Fan-out + Expert Pool |
| PM/기획자 | 요구사항 분석, 스프린트 계획, 이해관계자별 보고서 자동 생성 | Supervisor + Pipeline |
| 콘텐츠 제작자 | 리서치 → 작성 → 평가 → 발행 자동화, 다중 매체 동시 게시 | Producer-Reviewer + Fan-out |
| QA 엔지니어 | 경계면 검증 자동화, 테스트 시나리오 생성, 회귀 테스트 관리 | Expert Pool + Pipeline |
| 데이터 분석가 | 다각도 데이터 분석, 시각화 자동 생성, 인사이트 리포트 | Fan-out/Fan-in |
| 교육자 | 수준별 교육 콘텐츠 생성, 퀴즈 자동 생성, 학습 경로 설계 | Hierarchical Delegation |
민호의 Harness 100이 이미 10개 도메인에 200개 패키지를 제공하고 있다는 사실은, 이 확산이 이미 시작되었음을 보여준다.
돌이켜보면, AI 에이전트 활용의 진화 단계가 선명하게 보인다.
| 시기 | 핵심 역량 | 특징 |
|---|---|---|
| 2024 | 프롬프트 엔지니어링 | 좋은 질문을 던지는 기술 |
| 2025 | 컨텍스트 엔지니어링 | 올바른 맥락을 전달하는 기술 |
| 2026 | 하네스 엔지니어링 | AI 팀의 구조를 설계하는 기술 |
프롬프트 엔지니어링이 “한 마디를 잘 하는 것”이었다면, 컨텍스트 엔지니어링은 “기억을 잘 관리하는 것”이었다. 하네스 엔지니어링은 한 단계 더 올라간다 — “팀을 설계하는 것”이다.
하지만 이것은 동시에 우리에게 새로운 숙제를 안겨준다.
|
우리의 숙제
메이커 에반의 10단계 로드맵에서 하네스가 마지막 10단계에 위치한 이유가 있다. 1~9단계의 기초 없이 하네스를 도입하면 도구만 쌓이고 이해는 따라가지 못한다. 기초를 쌓고, 경험을 축적하고, 그 위에 하네스를 올려야 한다. |
|
About this article 이 글은 Nori(AI Writer)가 BloomLabs Content Harness(테크라이팅 하네스)를 활용하여 작성하였습니다. 작성 도구: Claude Code (Opus 4.6) + BloomLabs Content Harness v0.10.0 |