매번 같은 프롬프트를 복사해 붙여넣고, 조금씩 다듬고, 또 다른 도구에 같은 맥락을 다시 설명하는 작업을 반복하고 있다면 이 글이 도움이 될 것입니다. 2026년 현재, AI 자동화의 핵심은 모델 자체의 성능이 아니라 그 모델을 감싸는 하네스(harness) 설계에 달려 있습니다. 이 가이드에서는 하네스의 개념부터 실전 구축까지 Claude Code + CLAUDE.md 구조를 중심으로 단계별로 살펴봅니다.
AI 하네스란 무엇인가
AI 하네스(harness)는 원래 마차에서 말을 제어하기 위해 장착하는 장비입니다. AI 맥락에서도 의미가 같습니다. 거대언어모델(LLM)은 매 요청이 독립된 무상태(stateless) 시스템입니다. 하네스는 이 무상태 모델에 역할·기억·도구·검증을 덧씌워 지속적으로 작동하는 자동화 파이프라인으로 만들어줍니다.
2025년 발표된 논문 "Building Effective AI Coding Agents for the Terminal"은 하네스를 이렇게 정의합니다. "The runtime behavior is governed by the agent harness, the orchestration infrastructure that turns a stateless LLM into a persistent agent." 결국 하네스는 모델의 지능을 일관된 워크플로우로 묶어주는 오케스트레이션 인프라입니다.
프롬프트는 단일 요청에 대한 지시문입니다.
하네스는 여러 프롬프트·도구·컨텍스트·검증 단계를 하나의 재사용 가능한 파이프라인으로 연결한 시스템입니다.
프롬프트가 한 번의 대화라면, 하네스는 그 대화가 항상 같은 방식으로 이뤄지도록 만드는 구조입니다.
개발자 도구(Claude Code), 콘텐츠 자동화 파이프라인, 고객 지원 봇까지 실제로 쓸 만한 AI 시스템은 모두 어떤 형태로든 하네스를 갖추고 있습니다. 하네스 없이 AI를 사용하면 매번 맥락을 처음부터 설명해야 하고, 결과의 품질이 요청마다 제각각이 됩니다.
하네스의 핵심 구성 요소
잘 설계된 하네스는 네 개의 레이어로 이뤄집니다. 각 레이어는 독립적으로 설계하고 교체할 수 있습니다. 아래에서 각 레이어의 역할과 실전 적용 방법을 살펴봅니다.
프롬프트 레이어
AI의 역할, 페르소나, 작업 지시를 정의합니다. 시스템 프롬프트와 작업 프롬프트로 나뉩니다.
컨텍스트 레이어
프로젝트 규칙, 과거 작업 히스토리, 외부 문서를 AI의 컨텍스트 창에 주입합니다.
도구/Action 레이어
웹 검색, 파일 읽기, API 호출 등 AI가 실제로 수행할 수 있는 행동을 정의합니다.
검증/출력 레이어
AI 출력의 형식, 정확성, 안전성을 검사하고 발행 전 품질 게이트를 통과시킵니다.
프롬프트 레이어
프롬프트 레이어는 AI에게 "당신은 누구이고 무엇을 해야 하는가"를 알려주는 레이어입니다. 시스템 프롬프트에서 역할과 제약을 선언하고, 작업 프롬프트에서 구체적인 요청을 전달합니다. 잘 작성된 시스템 프롬프트 하나가 수십 번의 반복 프롬프팅을 대체합니다.
컨텍스트 레이어
컨텍스트 레이어는 AI가 작업에 필요한 배경 지식을 갖출 수 있도록 정보를 주입하는 레이어입니다. CLAUDE.md 같은 프로젝트 설정 파일, 과거 작업 메모리, 외부 API 문서 등이 여기에 해당합니다. 컨텍스트가 풍부할수록 AI는 매번 처음부터 설명받지 않아도 됩니다.
도구/Action 레이어
도구 레이어는 AI가 실제 세계와 상호작용할 수 있게 해줍니다. 파일 읽기·쓰기, 웹 검색, API 호출, 터미널 명령 실행이 모두 여기에 포함됩니다. MCP(Model Context Protocol)는 도구 정의의 표준 인터페이스로, 한 번 구현하면 여러 AI 클라이언트에서 재사용할 수 있습니다.
검증/출력 레이어
검증 레이어는 AI 출력이 기대한 형식과 품질을 충족하는지 확인하는 레이어입니다. JSON 스키마 검사, 사실 확인 단계, 발행 전 사용자 승인 등이 여기에 포함됩니다. 검증 레이어가 없으면 AI가 잘못된 형식으로 출력을 내보내도 파이프라인이 그대로 진행됩니다.
프롬프팅 전략 설계
좋은 하네스는 좋은 프롬프팅 전략에서 시작합니다. 단순히 요청을 잘 쓰는 것이 아니라, 반복 사용 가능하고 AI가 자율적으로 판단할 수 있는 구조를 만드는 것이 목표입니다.
역할과 페르소나 정의
시스템 프롬프트의 첫 번째 역할은 AI에게 전문가 정체성을 부여하는 것입니다. "당신은 한국어 콘텐츠 에디터입니다"처럼 역할을 명확히 선언하면, AI는 그 역할에 맞는 판단 기준으로 모든 요청을 처리합니다. 역할이 모호하면 AI는 매 요청마다 다른 톤과 형식으로 응답합니다.
역할 정의에는 다음 세 가지를 포함하는 것이 좋습니다. 첫째, 전문 분야("성공지식백과의 한국어 AI 콘텐츠 에디터"). 둘째, 핵심 행동 원칙("사실 확인 후 작성, 추측 금지"). 셋째, 금지 행동("사용자 승인 없이 발행하지 않는다"). 이 세 가지가 갖춰지면 AI는 지시받지 않은 상황에서도 일관되게 행동합니다.
다음 주제로 블로그 글을 써주세요.
당신은 성공지식백과의 한국어 AI 콘텐츠 에디터입니다. 핵심 규칙: - 리서치 먼저, 추측으로 쓰지 않는다 - docs/writing-style.md 문체 준수 - 발행 전 반드시 사용자 확인 다음 주제로 guide 타입 아티클을 작성하세요.
작업 분해와 위임
복잡한 작업을 하나의 프롬프트에 모두 담으면 품질이 떨어집니다. 하네스에서는 큰 작업을 독립 단계로 분해하고, 각 단계를 별도 AI 인스턴스(서브에이전트)에 위임하는 패턴을 사용합니다. 예를 들어 콘텐츠 자동화 파이프라인에서는 리서치 에이전트 → 작성 에이전트 → 검증 에이전트 → 발행 에이전트로 역할을 나눕니다.
서브에이전트 위임의 핵심 이점은 격리된 컨텍스트 창입니다. 각 서브에이전트는 자신의 작업에 필요한 도구와 지시만 갖고 시작합니다. 중간 과정의 토큰(검색 결과, 중간 추론 등)은 서브에이전트 안에서 소비되고, 메인 에이전트에는 최종 결과만 전달됩니다. 덕분에 메인 에이전트의 컨텍스트가 불필요하게 오염되지 않습니다.
출력 형식 명세
AI 출력을 다음 단계에서 자동으로 처리하려면 출력 형식을 미리 명세해야 합니다. "JSON으로 출력하라"는 것만으로는 부족합니다. 구체적인 스키마, 필드 이름, 배열 구조까지 예시로 보여주어야 합니다. 하네스 안에서 형식 명세가 명확할수록 파이프라인의 다음 단계가 안정적으로 실행됩니다.
출력 형식 예시를 프롬프트에 직접 포함하세요.
예시 없이 "JSON으로 출력하라"고만 하면 AI는 자의적으로 구조를 결정합니다.
예시를 넣으면 AI가 그 패턴을 그대로 따라 출력합니다.
컨텍스트 엔지니어링 적용
컨텍스트 엔지니어링은 AI가 요청을 처리할 때 참조하는 정보를 의도적으로 설계하는 작업입니다. 어떤 정보를 언제, 어떤 방식으로 AI에게 전달할지 결정하는 것이 핵심입니다. 모델의 성능이 같더라도 컨텍스트 설계가 좋으면 출력 품질이 크게 달라집니다.
CLAUDE.md — 프로젝트 컨텍스트 파일
CLAUDE.md는 Claude Code가 프로젝트 루트에서 자동으로 읽는 영구 컨텍스트 파일입니다. 아키텍처 결정, 코딩 규칙, 금지 패턴, 워크플로우 지시를 이 파일에 적어두면 매 세션마다 반복 설명 없이 AI가 프로젝트 문맥을 이해하고 시작합니다.
Claude Code 공식 문서는 CLAUDE.md에 코딩 스타일, 워크플로우 선호도, 자주 사용하는 명령 등을 기록할 것을 권장합니다. 프로젝트에 새로운 팀원이 합류했을 때 온보딩 문서처럼 작동하기도 합니다. 실제로 CLAUDE.md를 잘 작성해두면 AI에게 매번 "우리 프로젝트에서는 이렇게 합니다"라고 설명하는 시간이 사라집니다.
# [프로젝트명] [프로젝트 한 줄 설명] ## 나의 역할 [AI에게 부여할 역할과 책임] 예: - 주제를 받으면 웹 리서치 → 작성 → 검증 → 발행 순으로 처리 - 사용자 확인 없이 외부 API를 호출하지 않는다 ## 도구 - **[MCP 도구명]** — [용도 설명] ## 핵심 규칙 1. **[규칙1]** — [설명] 2. **[규칙2]** — [설명] 3. **환경변수** — `$[변수명]`을 코드에 하드코딩하지 않는다 ## 문서 참조 가이드 | 작업 | 읽을 문서 | |------|----------| | [작업명] | `docs/[파일명].md` |
작업 히스토리 관리
AI는 세션이 끊기면 이전 작업을 기억하지 못합니다. 하네스에서는 메모리 파일을 통해 이 문제를 해결합니다. 서브에이전트가 코드를 리뷰하면서 발견한 패턴과 규칙을 메모리 디렉터리에 축적하고, 다음 세션에서 그 내용을 참조합니다. Claude Code의 서브에이전트 시스템은 이 패턴을 지원합니다. 서브에이전트의 시스템 프롬프트에는 메모리 디렉터리의 MEMORY.md 첫 200줄이 자동으로 포함됩니다.
메모리 파일 관리의 핵심 원칙은 범위 지정입니다. 전체 프로젝트에 적용되는 규칙은 루트 CLAUDE.md에, 특정 서브에이전트에만 필요한 메모리는 해당 에이전트의 메모리 디렉터리에 분리해서 관리합니다. 범위가 넓을수록 컨텍스트 오염 위험도 커집니다.
외부 문서 주입
AI가 항상 최신 정보를 참조하려면 외부 문서를 컨텍스트에 동적으로 주입하는 메커니즘이 필요합니다. Context7 같은 MCP 도구는 라이브러리 공식 문서를 쿼리해서 현재 세션의 컨텍스트에 주입합니다. 직접 docs/ 디렉터리를 운영하면서 참조 가이드 파일을 관리하는 방식도 효과적입니다.
외부 문서를 너무 많이 주입하면 컨텍스트 창이 가득 차 오히려 품질이 떨어집니다.
하나의 작업에 필요한 문서만 선택적으로 주입하는 것이 좋습니다. 32,000토큰 분량의 MCP 도구 메타데이터가 모든 메시지에 들어가면 불필요한 비용과 지연이 발생합니다.
검증과 품질 관리
하네스에서 가장 자주 생략되는 레이어가 검증입니다. AI 출력을 그대로 파이프라인 다음 단계로 넘기면, 형식 오류 하나가 전체 워크플로우를 망가뜨립니다. 검증 레이어를 갖춘 하네스는 오류를 발행 전에 잡아냅니다.
검증은 세 단계로 구성하는 것이 좋습니다. 첫째, 형식 검증 — JSON 스키마 또는 스크립트로 필수 필드·타입을 확인합니다. 둘째, 사실 검증 — 부정 주장이나 중요 수치는 소스를 교차 확인합니다. 셋째, 사용자 승인 — 외부 API 호출이나 영구 변경 전에 최종 확인을 받습니다.
| 단계 | 방법 | 적용 시점 |
|---|---|---|
| 형식 검증 | JSON 스키마 검사, 스크립트 실행 | AI 출력 직후 |
| 사실 검증 | 웹 검색 교차 확인, GitHub Issues 확인 | 초안 작성 후 |
| 사용자 승인 | 결과물 미리보기 + 확인 요청 | 발행/API 호출 전 |
자동화 파이프라인이라도 사용자 승인 단계를 없애지 않는 것이 중요합니다. 완전 자동화는 매력적으로 보이지만, 한 번의 AI 오류가 실제 서비스에 영향을 미칠 수 있습니다. 중요한 행동(발행, 삭제, 외부 API 호출) 직전에 항상 사람이 개입하는 게이트를 유지해야 합니다.
Context Reset vs Compaction
에이전트가 오래 실행될수록 컨텍스트 창이 가득 차는 문제가 발생합니다. 이를 처리하는 두 가지 전략이 있습니다.
Compaction은 이전 대화를 요약해서 같은 에이전트가 계속 작업하는 방식입니다. 연속성은 유지되지만, 에이전트가 자신의 이전 실수나 편향을 그대로 이어받는 "context anxiety" 문제가 발생할 수 있습니다. 요약 과정에서 중요한 세부사항이 누락되면 품질이 점진적으로 하락합니다.
Context Reset은 컨텍스트를 완전히 초기화하고 새 에이전트 인스턴스를 시작하는 방식입니다. 이전 에이전트의 상태는 구조화된 핸드오프 파일(진행 상황, 완료된 항목, 남은 작업 목록)로 전달합니다. 새 에이전트는 깨끗한 컨텍스트에서 핸드오프 파일만 읽고 작업을 이어가므로, 이전 에이전트의 편향이 전파되지 않습니다.
Opus 4.6에서는 Compaction만으로도 충분히 안정적인 결과를 얻을 수 있게 되었습니다. context anxiety가 크게 줄어들었기 때문입니다. 다만 작업이 수십 단계를 넘어가거나, 이전 단계의 오류가 누적되는 패턴이 보이면 여전히 Context Reset이 더 효과적입니다.
Evaluator 튜닝 루프 상세
검증 품질을 지속적으로 높이려면 Evaluator 자체를 개선하는 루프가 필요합니다. 이 루프는 세 단계로 작동합니다. 첫째, Evaluator가 판단한 로그(통과/실패 이유, 점수)를 수집합니다. 둘째, 사람이 같은 결과물을 보고 내린 판단과 Evaluator의 판단을 비교합니다. 셋째, 판단이 다른 지점을 분석하여 Evaluator의 프롬프트나 채점 기준을 업데이트합니다.
이 과정에서 자주 발견되는 패턴은 Evaluator가 너무 관대하거나 너무 엄격한 방향으로 편향되는 것입니다. 관대하면 품질 미달 결과물이 통과되고, 엄격하면 Generator가 불필요한 수정을 반복합니다. 실제 사용자 피드백이나 운영 데이터를 기준으로 Evaluator의 임계값을 조정해야 합니다.
실전 하네스 예시 — 성공지식백과 콘텐츠 자동화
지금까지 설명한 네 개 레이어를 실제 프로젝트에 적용한 예시로, 성공지식백과 콘텐츠 자동화 하네스를 살펴봅니다. 이 하네스는 주제를 받으면 웹 리서치 → 한국어 콘텐츠 작성 → JSON 변환 → 검증 → Sanity API 발행까지 전 과정을 처리합니다.
성공지식백과 자동화 하네스 디렉터리 구조
📁successwiki_automation
📁docs
📁scripts
📁output
📁.claude
📁commands
📁skills
이 구조의 핵심은 docs/ 디렉터리입니다. CLAUDE.md에서 각 작업 단계마다 참조할 문서를 명시해두면, AI는 필요한 순간에 해당 파일을 읽어 컨텍스트를 업데이트합니다. 모든 규칙을 CLAUDE.md 하나에 넣지 않고 docs/로 분산해서 컨텍스트 창의 효율을 유지합니다.
하네스 구축 단계
1단계: 역할 정의 — CLAUDE.md 작성
AI의 역할, 핵심 규칙, 참조 문서 목록을 CLAUDE.md에 작성합니다. 구체적인 금지 행동("사용자 확인 없이 발행 금지")까지 명시합니다.
# 프로젝트명 나의 역할: 주제 → 리서치 → 작성 → 발행 핵심 규칙: 1. 리서치 먼저 — 추측으로 쓰지 않는다 2. 발행 전 확인 — 사용자 승인 후 API 호출
2단계: 문서 레이어 구성 — docs/ 디렉터리
문체 가이드(writing-style.md), 출력 스키마(blocks.md), API 레퍼런스(sanity-api.md) 등 작업별 참조 문서를 분리해서 관리합니다.
3단계: 도구 레이어 설정 — MCP + 권한
필요한 MCP 도구를 등록하고, .claude/settings.json에서 허용/금지 도구를 명시합니다. 불필요한 도구는 제외해서 컨텍스트 과부하를 방지합니다.
claude mcp add open-websearch npx @open-websearch/mcp-server claude mcp add context7 npx @context7/mcp-server
4단계: 검증 스크립트 작성
AI 출력(JSON)을 발행 전에 자동으로 검사하는 validate.py 스크립트를 작성합니다. 에러 0건일 때만 발행 단계로 진행하도록 파이프라인을 구성합니다.
python3 scripts/validate.py output/draft.json # 에러 0건 → 발행 진행 # 에러 있음 → AI에게 수정 요청
5단계: 워크플로우 테스트 — 첫 실행
간단한 주제로 하네스를 처음 실행해봅니다. 각 단계에서 AI가 예상한 대로 동작하는지 확인하고, CLAUDE.md와 docs/를 조금씩 다듬어 나갑니다.
6단계: 반복 개선 — 패턴 누적
실제 운영하면서 자주 발생하는 오류 패턴을 CLAUDE.md 규칙으로 추가합니다. 하네스는 처음부터 완벽하지 않습니다. 사용할수록 규칙이 쌓이고 품질이 올라갑니다.
이 하네스를 운영하면서 배운 가장 중요한 교훈은, 하네스가 AI를 "제어"하는 도구가 아니라 AI와의 협업 계약서라는 점입니다. 규칙을 구체적으로 쓸수록 AI는 더 자율적으로, 더 예측 가능하게 행동합니다.
하네스 구축 완료 체크리스트
0/6 완료
멀티에이전트 패턴으로 확장
단일 에이전트 하네스를 충분히 익혔다면, 다음 단계는 멀티에이전트 패턴입니다. 복잡한 작업을 병렬로 처리하거나, 모델을 역할별로 다르게 라우팅하는 구조입니다.
Anthropic의 멀티에이전트 연구 시스템은 이 패턴을 실전에서 사용합니다. Claude Opus 4.6이 오케스트레이터로 전략을 세우고, Claude Sonnet 4.6 서브에이전트들이 병렬로 실행합니다. 비싼 프론티어 모델은 계획과 판단을, 작고 빠른 모델은 실행을 담당합니다. 덕분에 전체 비용을 낮추면서도 출력 품질을 유지합니다.
| 에이전트 | 역할 | 모델 선택 기준 |
|---|---|---|
| 오케스트레이터 | 작업 분해, 서브에이전트 위임, 결과 통합 | 고성능 모델 (Opus) |
| 리서치 에이전트 | 웹 검색, 문서 수집, 사실 확인 | 빠른 모델 (Sonnet) |
| 작성 에이전트 | 콘텐츠 초안 생성, 형식 변환 | 균형 모델 (Sonnet) |
| 검증 에이전트 | 스키마 확인, 품질 검사 | 빠른 모델 (Sonnet) |
여러 에이전트가 같은 파일이나 데이터를 동시에 수정하면 충돌이 발생합니다.
병렬화는 읽기 전용 작업(리서치, 분석)에는 안전하지만, 쓰기 작업에는 신중하게 설계해야 합니다.
공유 상태를 건드리는 에이전트는 순차 실행을 유지하거나 명시적인 잠금 메커니즘이 필요합니다.
Anthropic 공식 3-에이전트 아키텍처
Anthropic의 엔지니어링 블로그 "Harness design for long-running application development"에서는 장시간 실행되는 애플리케이션 개발에 최적화된 3-에이전트 아키텍처를 제시합니다. 이 구조는 각 에이전트가 명확한 역할 하나만 담당하도록 설계되어, 단일 에이전트의 컨텍스트 과부하 문제를 근본적으로 해결합니다.
| 에이전트 | 역할 | 핵심 동작 |
|---|---|---|
| Planner | 요구사항을 제품 스펙으로 확장 | 사용자의 1-4문장 프롬프트를 상세한 제품 스펙 문서로 변환합니다. 기능 목록, UI 구조, 기술 요구사항을 명시합니다. |
| Generator | 스펙에 따라 기능 구현 | Planner가 작성한 스펙을 받아 한 번에 하나의 기능을 구현합니다. 전체를 한꺼번에 만들지 않고 기능 단위로 반복합니다. |
| Evaluator | 결과물을 테스트하고 채점 | Playwright MCP 등의 도구로 실제 앱을 구동하여 테스트합니다. 스펙 충족 여부를 점수로 평가하고, 미달 시 Generator에게 수정을 요청합니다. |
Sprint Contract 패턴
3-에이전트 아키텍처에서 특히 주목할 부분은 Sprint Contract 패턴입니다. Generator와 Evaluator가 작업을 시작하기 전에 "완료"의 기준을 먼저 합의합니다. 예를 들어 "로그인 폼이 동작하고, 잘못된 이메일에 에러 메시지가 표시되면 완료"처럼 구체적인 조건을 정합니다. 이 계약이 없으면 Generator는 자기 기준으로 "됐다"고 판단하고, Evaluator는 다른 기준으로 "안 됐다"고 판단하면서 불필요한 반복이 발생합니다.
자기 평가의 한계와 Evaluator 분리
Claude는 자신이 생성한 코드나 텍스트를 평가할 때 관대해지는 경향이 있습니다. 같은 에이전트가 생성과 평가를 모두 담당하면, 자신의 출력에 대한 비판적 거리가 부족해집니다. 이 문제를 해결하려면 생성(Generator)과 평가(Evaluator)를 반드시 별도의 에이전트 인스턴스로 분리해야 합니다. 각 에이전트는 독립된 컨텍스트에서 작동하므로, Evaluator는 Generator의 의도나 과정에 영향받지 않고 결과물만 객관적으로 판단할 수 있습니다.
Evaluator의 판단 기준도 시간이 지나면 보정이 필요합니다. 튜닝 루프는 다음과 같습니다. Evaluator의 로그를 읽고, 사람의 판단과 Evaluator의 판단이 다른 지점을 찾아 Evaluator 프롬프트를 업데이트합니다. 이 과정을 반복하면 Evaluator의 채점 기준이 실제 품질 기대치에 수렴합니다.
GAN 영감 패턴: Generator-Evaluator 루프
Generator-Evaluator 루프는 딥러닝의 GAN(Generative Adversarial Network) 구조와 본질적으로 유사합니다. GAN에서 Generator가 이미지를 만들고 Discriminator가 진위를 판별하듯, AI 하네스에서도 Generator가 결과물을 만들고 Evaluator가 품질을 판별합니다. 두 에이전트가 반복적으로 서로를 개선하면서 전체 출력 품질이 상승합니다.
다만 GAN과 다른 점도 있습니다. GAN은 역전파를 통해 자동으로 학습하지만, AI 하네스의 Generator-Evaluator 루프는 프롬프트와 컨텍스트를 수동으로 조정하여 개선합니다. 따라서 Evaluator의 피드백이 Generator에게 실질적으로 유용한 정보를 제공하도록 프롬프트를 설계하는 것이 핵심입니다.
하네스 설계 원칙
하네스를 설계하고 운영할 때 다음 세 가지 원칙을 기억해야 합니다. 이 원칙들은 Anthropic의 "Building Effective Agents" 연구와 실전 하네스 운영 경험에서 도출된 것입니다.
| 원칙 | 핵심 내용 | 실전 적용 |
|---|---|---|
| 단순함 우선 | 가장 단순한 솔루션부터 시작하고, 필요할 때만 복잡도를 높입니다. 모든 구성 요소가 정말 필요한지 검증해야 합니다. | 모델이 혼자 할 수 있는 일에 하네스를 씌우면 오히려 느려집니다. 단일 프롬프트로 해결되는 작업에 멀티에이전트 파이프라인을 적용하지 않습니다. |
| 가정 재검증 | 하네스의 모든 구성 요소는 모델이 혼자 못하는 것에 대한 가정을 인코딩한 것입니다. 새 모델이 나오면 그 가정을 재검증해야 합니다. | Opus 4.5에서 필수였던 Sprint 분해가 Opus 4.6에서는 불필요해진 사례가 있습니다. 모델이 업그레이드될 때마다 하네스의 각 레이어가 여전히 가치를 더하는지 확인합니다. |
| 경계 이동 | 모델이 좋아지면 하네스가 필요 없어지는 것이 아니라, 하네스로 달성할 수 있는 것의 경계가 이동합니다. 흥미로운 하네스 조합의 공간은 줄어들지 않습니다. | 과거에 불가능했던 작업(수십 파일 동시 리팩터링, 장시간 자율 에이전트)이 새 모델 + 하네스 조합으로 가능해집니다. 하네스 설계의 가능성은 모델과 함께 확장됩니다. |
자주 묻는 질문
CLAUDE.md가 너무 길어지면 어떻게 하나요?
MCP와 Skills의 차이점은 무엇인가요?
서브에이전트를 언제 써야 하나요?
하네스를 처음 만들 때 어디서 시작해야 하나요?
AI가 규칙을 계속 어기면 어떻게 해야 하나요?
Claude Code 없이도 이 하네스 패턴을 적용할 수 있나요?
AI 하네스 설계는 한 번에 완성되지 않습니다. 처음에는 간단한 CLAUDE.md 하나로 시작하고, 실제 사용하면서 규칙을 추가하고, 반복되는 오류 패턴을 발견할 때마다 개선해 나가는 과정입니다. 하네스가 성숙해질수록 AI는 더 자율적으로, 더 일관되게 작동합니다.
2026년 현재, 모델의 성능 차이보다 하네스 설계의 차이가 실제 AI 활용 결과를 더 크게 좌우합니다. 더 나은 모델을 기다리는 시간에 지금 있는 모델로 더 나은 하네스를 만드는 것이 훨씬 빠른 길입니다.
관련 가이드
컨텍스트 엔지니어링 완전 가이드 (2026년 3월 기준)
프롬프트 엔지니어링의 시대는 저물고, 컨텍스트 엔지니어링의 시대가 열렸습니다. LLM에 무엇을, 언제, 어떻게 전달할지를 설계하는 컨텍스트 엔지니어링의 핵심 개념부터 실전 패턴까지 2026년 기준으로 정리했습니다.
프롬프팅 완전 가이드 (2026년 3월 기준)
Zero-shot부터 Chain-of-Thought, 역할 부여, 구조화 출력까지 — 2026년 현재 검증된 LLM 프롬프팅 기법을 모두 정리했습니다. Claude, GPT, Gemini에 즉시 적용할 수 있는 실전 템플릿과 좋은/나쁜 예시를 함께 담았습니다.
CLAUDE.md 작성법 — AI 에이전트를 내 프로젝트에 맞추는 방법
Claude Code가 모든 세션에서 읽는 프로젝트 지침 파일 CLAUDE.md의 위치 계층, 작성 전략, 실전 예시, 팀 공유 패턴, AGENTS.md·GEMINI.md와의 차이를 한 문서에 정리했습니다.
AI 자동화 뉴스레터 구독
매주 실전 AI 워크플로우 팁과 최신 도구 정보를 받아보세요.