AI 코딩 에이전트에게 몇 시간짜리 작업을 맡겼는데, 초반에는 잘 따라오다가 어느 순간 엉뚱한 방향으로 빠져버린 경험, 여러분도 있으시죠? 프롬프트를 아무리 다듬어도 긴 작업에서는 품질이 들쭉날쭉하고, 직접 만든 코드를 스스로 평가하라고 하면 항상 "잘 했다"고만 하는 AI. 이런 문제를 근본적으로 해결하기 위해 등장한 개념이 바로 하네스 엔지니어링이에요. 2025년이 AI 에이전트를 '만드는 것'에 집중했다면, 2026년의 핵심은 에이전트를 안전하고 안정적으로 '운용하는 구조를 설계하는 것'으로 이동하고 있어요. Anthropic Labs 팀이 실제로 멀티 시간 자율 코딩 세션에서 검증한 이 접근법, 지금부터 하나씩 파헤쳐볼게요.

하네스 엔지니어링이란? 하네스 뜻과 핵심 개념 정리

하네스 엔지니어링은 특정 AI 모델에 상관없이, AI 에이전트가 생성하는 코드의 품질과 유지보수성을 확보하기 위해 컨텍스트, 아키텍처 제약, 피드백 루프 등의 통제 구조를 설계하고 반복적으로 개선해 나가는 것을 의미합니다.

프롬프트 엔지니어링과 하네스 엔지니어링의 차이점

프롬프트 엔지니어링(2023) → 컨텍스트 엔지니어링(2025) → 하네스 엔지니어링(2026)으로 이어지는 흐름에서, 관심은 "모델에게 뭘 말할까"에서 "모델을 둘러싼 시스템을 어떻게 설계할까"로 이동하고 있어요. 프롬프트는 한 번의 입력이고, 컨텍스트는 한 세션의 배경이고, 하네스는 영구적인 시스템이에요. 단발성 질의·응답이라면 프롬프트 엔지니어링으로 충분하지만, 에이전트가 장기간 복잡한 작업을 수행해야 한다면 반드시 하네스 엔지니어링이 필요해요.

컨텍스트 엔지니어링과 AI 하네스 엔지니어링의 관계

컨텍스트 엔지니어링이란?

컨텍스트 엔지니어링은 단순히 AI 모델에 명령을 전달하는 것을 넘어, AI가 작업을 수행하는 데 필요한 모든 정보를 적시에 제공하는 시스템을 설계하는 것을 의미해요. 프롬프트 엔지니어링이 AI에게 '질문을 잘 던지는 기술'에 집중했다면, 컨텍스트 엔지니어링은 그보다 한 걸음 더 나아간 개념이에요.

하네스 설계가 컨텍스트 관리에 미치는 영향

HumanLayer 팀은 하네스 엔지니어링을 컨텍스트 엔지니어링의 하위 집합(subset)으로 보기도 해요. 프롬프트는 하네스의 한 구성 요소일 뿐이며, 하네스는 프롬프트를 포함한 더 넓은 시스템 설계를 다뤄요. 즉, 하네스가 잘 설계되면 컨텍스트도 자연스럽게 효과적으로 관리되는 셈이죠.

장기 실행 에이전트에서 컨텍스트 전달이 중요한 이유

Anthropic 엔지니어링 블로그에 따르면, 모델은 긴 작업을 수행하면서 컨텍스트 윈도우가 채워지면 일관성을 잃는 경향이 있어요. 심지어 "컨텍스트 불안(context anxiety)"이라는 현상도 관찰되는데요. 이는 모델이 컨텍스트 한계에 가까워지면 작업을 성급하게 마무리하려는 행동을 보이는 것이에요. Sonnet 4.5에서는 컨텍스트 불안 경향이 강하게 나타나서, 컨텍스트 리셋이 하네스 설계의 핵심 요소였어요.

단순 구현이 실패하는 이유: 하네스 없는 AI 코딩의 한계

기본 프롬프트만으로 부딪히는 성능 천장

Anthropic Labs의 Prithvi Rajasekaran은 프론트엔드 디자인 품질 향상과 인간 개입 없는 완전한 애플리케이션 구축이라는 두 가지 문제를 연구했는데, 프롬프트 엔지니어링과 하네스 설계로 베이스라인 이상의 성능 향상을 이끌었지만 결국 천장에 부딪혔어요. 일부 문제는 지속적으로 남았는데, 특히 복잡한 작업에서 에이전트는 시간이 지남에 따라 궤도를 벗어나는 경향을 보였고, 두 가지 공통 실패 모드가 관찰되었어요.

Anthropic의 실험이 보여준 하네스 설계의 임팩트

Anthropic은 "인프라 설정(configuration)이 에이전틱 코딩 벤치마크를 수 퍼센트포인트씩 좌우할 수 있으며, 이는 때때로 상위 모델 간 리더보드 격차보다 크다"고 밝혔어요. 같은 모델이라도 하네스를 어떻게 설계하느냐에 따라 결과가 판이하게 달라진다는 뜻이죠. 실제로 LangChain은 같은 모델로 하네스만 바꿔 벤치마크 점수를 52.8%에서 66.5%로 끌어올린 사례도 있어요.

주관적 품질과 객관적 정확성을 동시에 잡아야 하는 과제

에이전트에게 자기 결과물을 평가하도록 하면 문제가 생겨요. AI는 자기가 만든 작업물을 자신 있게 칭찬하는 경향이 있거든요. 품질이 분명히 떨어지더라도 말이죠. 특히 디자인처럼 주관적인 영역에서는 "이진 검증(binary check)"이 불가능하기 때문에 이 문제가 더 두드러져요. 이 자기 평가 편향을 극복하는 것이 하네스 엔지니어링의 핵심 과제 중 하나예요.

AI 하네스 엔지니어링 핵심 원리 3가지

작업 분해(Task Decomposition): 복잡한 빌드를 다루기 쉬운 단위로 나누기

Anthropic은 이전 실험에서 이니셜라이저 에이전트가 제품 스펙을 태스크 리스트로 분해하고, 코딩 에이전트가 한 번에 하나의 기능을 구현하는 방식으로 장기 실행 에이전틱 코딩의 효과를 크게 높였어요. 복잡한 작업을 한꺼번에 맡기지 말고, 관리 가능한 단위로 쪼개는 것이 첫 번째 원리예요.

구조화된 아티팩트(Structured Artifacts): 세션 간 맥락 전달 장치

핵심 인사이트는 에이전트가 새로운 컨텍스트 윈도우로 시작할 때 작업 상태를 빠르게 파악할 수 있는 방법을 찾는 것이었는데, 이는 claude-progress.txt 파일과 git 히스토리를 통해 달성했어요. 하네스 엔지니어링의 산출물(CLAUDE.md, 스킬 파일, 훅 스크립트)은 전부 코드 리포지토리에 커밋되는 파일이라, 팀원이 바뀌어도, 모델이 바뀌어도, 축적된 하네스는 그대로 남아요.

멀티 에이전트 아키텍처: 생성자-평가자-계획자 역할 분리

멀티 에이전트 시스템의 핵심은 단순히 에이전트 수를 늘리는 것이 아니라, 각 에이전트가 명확하게 정의된 역할을 맡아 해당 역할에만 집중하도록 하는 것이에요. 작업을 하는 에이전트와 판단하는 에이전트를 분리하는 것만으로도 품질이 크게 개선돼요.

하네스 엔지니어링 실전 설계법: 3-에이전트 아키텍처

기획(Planner) 에이전트: 제품 스펙을 태스크 리스트로 변환

Planner는 사용자의 제품 요구사항을 분석해 구체적인 기능 단위 태스크 리스트로 변환하는 역할을 해요. 이니셜라이저 에이전트는 사용자의 초기 프롬프트를 기반으로 기능 요구사항을 포괄적으로 정리한 파일을 작성해요. 이 과정이 없으면 에이전트가 앱을 한 번에 만들어버리거나 프로젝트를 조기에 완료 처리하는 문제가 발생하죠.

생성(Generator) 에이전트: 기능 단위 코드 생성과 구현

Generator는 Planner가 만든 태스크 리스트에서 한 번에 하나의 기능을 구현해요. 각 세션에서 목표를 향해 점진적 진행을 이루면서, 세션 종료 시 환경을 깨끗한 상태로 남기는 것이 핵심이에요. 깨끗한 상태란 메인 브랜치에 머지하기 적절한 수준의 코드를 말해요.

평가(Evaluator) 에이전트: GAN에서 영감 받은 품질 평가 체계

Anthropic의 Prithvi Rajasekaran은 GAN(생성적 적대 신경망)에서 영감을 받아 생성자와 평가자를 분리하는 구조를 설계했어요. 이 GAN 영감 패턴을 풀스택 개발에 적용했는데, 생성자-평가자 루프가 코드 리뷰와 QA가 동일한 구조적 역할을 하는 소프트웨어 개발 라이프사이클에 자연스럽게 매핑되었어요.

세 에이전트가 협업하는 전체 워크플로우

Opus 4.5에서는 컨텍스트 불안이 크게 해소되어 컨텍스트 리셋 없이 전체 빌드를 하나의 연속 세션으로 실행할 수 있게 되었고, Claude Agent SDK의 자동 압축(compaction)이 컨텍스트 증가를 처리했어요. Planner → Generator → Evaluator의 피드백 루프가 멀티 시간 자율 코딩 세션 동안 반복되며 풍부한 풀스택 애플리케이션을 만들어내는 구조예요.

클로드 하네스 엔지니어링 프론트엔드 디자인 적용 예시

주관적 디자인 품질을 구체적 평가 기준으로 전환하는 방법

Anthropic의 실험에서 채점 기준은 단순한 평가 도구가 아니라, 결과물의 성격을 결정하는 스티어링 메커니즘으로 작동했어요. Prithvi는 네 가지 채점 기준을 설계했는데요:

디자인 품질과 독창성에 더 높은 가중치를 두어 미적 리스크 테이킹을 유도한 것이 핵심이에요.

프론트엔드 디자인 스킬(Skill) 플러그인 활용 팁

스킬(Skills)은 원래 Anthropic이 Claude Code용으로 도입했지만, 이후 Codex와 OpenCode 등 다른 하네스에서도 지원하는 오픈 표준이 되었어요. 프론트엔드 디자인 스킬은 Evaluator에게 Playwright MCP를 제공해 실제 라이브 페이지를 직접 탐색하고 스크린샷을 캡처한 뒤 평가하는 방식으로 작동해요. 다만 하네스를 과하게 쌓으면 역효과가 나기 때문에, "최소한의 규칙으로 최대 효과"를 내는 것이 진짜 기술이에요.

멀티 시간 자율 코딩 세션에서의 실제 성과

5~15회 반복(iteration)을 거치며 매 반복마다 Generator가 Evaluator의 피드백을 바탕으로 더 독특한 방향으로 발전해요. 전체 실행 시간이 최대 4시간까지 걸리기도 하지만, 반복을 거듭할수록 평가 점수가 개선되는 패턴이 확인되었어요.

하네스 엔지니어링 시작을 위한 실무 체크리스트

하네스 설계 전 확인해야 할 5가지 질문

하네스 엔지니어링의 첫 번째 단계는 반드시 베이스라인 측정이에요. 하네스 없이, 단일 에이전트에게 과제를 그대로 맡겨보고, 결과물을 실제 사용자 관점에서 평가해 보세요.

1. 현재 단일 에이전트로 작업했을 때 주요 실패 모드는 무엇인가?
2. 실패가 방향(Direction), 실행(Execution), 품질(Quality) 중 어디서 발생하는가?
3. 작업이 장기 실행이 필요한가, 아니면 단발성인가?
4. 주관적 품질 평가가 필요한 영역이 있는가?
5. 세션 간 맥락 전달이 필요한 구조인가?

Claude Code에서 바로 적용할 수 있는 단계별 가이드

Anthropic의 Claude Code는 권한 모델과 훅(hooks) 시스템으로 하네스를 구현하며, 훅은 에이전트 라이프사이클의 중요 시점에 보안 스캔, 린팅, 정책 적용 등의 스크립트를 주입할 수 있게 해줘요. CLAUDE.md 파일을 통해 코드베이스, 컨벤션, 워크플로우에 대한 지속적인 프로젝트 컨텍스트도 제공하죠.

Step 1: 프로젝트 루트에 CLAUDE.md를 생성하고 기술 스택, 코딩 규칙, 금지 사항 기록 

Step 2: 단일 에이전트로 작업 실행 후 로그를 분석하여 실패 패턴 분류

Step 3: 실패 패턴별 해결책을 하네스 구성 요소(스킬, 훅, 역할 분리 등)로 설계

흔한 실수와 해결 방법

가장 흔한 실수는 처음부터 멀티 에이전트 시스템을 설계하려는 것이에요. 플래너, 제너레이터, 이밸류에이터를 바로 만들면 거의 확실하게 실패하는데, 문제가 무엇인지도 모르는 상태에서 해법을 설계하는 것이기 때문이에요.

Anthropic의 Prithvi Rajasekaran은 자신의 블로그에서 "the space of interesting harness combinations doesn't shrink as models improve. Instead, it moves"라고 밝히며, 모델이 발전해도 하네스 설계의 중요성은 사라지지 않는다고 강조했어요.

자주 묻는 질문 (FAQ)

Q1. 하네스 엔지니어링과 프롬프트 엔지니어링은 어떻게 다른가요?

프롬프트는 한 번의 입력이고, 컨텍스트는 한 세션의 배경이고, 하네스는 영구적인 시스템이에요. 프롬프트 엔지니어링이 "무엇을 물어볼까"에 집중한다면, 하네스 엔지니어링은 에이전트가 작업하는 전체 환경—도구, 규칙, 피드백 루프, 메모리—을 설계하는 거예요.

Q2. 컨텍스트 엔지니어링 없이 하네스 엔지니어링만으로 충분한가요?

두 개념은 별개가 아니에요. 하네스 엔지니어링은 AI 모델 하나를 잘 다루는 기술이 아니라, 여러 에이전트와 툴, 데이터, 메모리까지 연결해 전체 작업 흐름을 설계하는 방식이에요. 컨텍스트 엔지니어링은 그 안에서 "올바른 정보를 올바른 시점에 제공"하는 핵심 역할을 하기 때문에, 둘은 함께 가야 해요.

Q3. AI 하네스 엔지니어링을 학습하려면 어디서부터 시작해야 하나요?

먼저 단일 에이전트로 돌리고, 결과물을 직접 사용하고 평가한 뒤, 로그를 읽고 실패 모드를 분류하세요. 각 실패 모드에 대한 구체적 해법을 설계하면, 그 해법이 곧 하네스의 구성 요소가 돼요. Anthropic 엔지니어링 블로그의 하네스 관련 글들이 가장 좋은 출발점이에요.

Q4. 클로드 외 다른 AI 모델에도 하네스 엔지니어링을 적용할 수 있나요?

물론이에요. 하네스 엔지니어링은 엔지니어의 역할이 직접 코드를 작성하는 것에서 환경을 설계하고, 의도를 명확히 명시하고, 에이전트가 자율적으로 작업할 수 있는 피드백 루프를 구축하는 것으로 전환되는 것을 의미해요. Claude Code, Cursor, Codex 등 어떤 에이전트에든 적용 가능한 보편적 원리예요.

Q5. 멀티 에이전트 구조 없이 단일 에이전트로도 효과가 있나요?

모델을 대상으로 실험하고, 현실적인 문제에서의 실행 추적(trace)을 읽고, 원하는 결과를 달성하도록 성능을 튜닝하는 것은 항상 좋은 관행이에요. 더 복잡한 작업에서는 작업을 분해하고 각 측면에 특화된 에이전트를 적용하는 것으로 추가적인 여지를 확보할 수 있어요. 처음부터 복잡한 구조를 만들기보다, 실패 패턴을 먼저 파악한 뒤 필요에 따라 점진적으로 확장하는 것을 추천드려요.

모델은 이제 상품(commodity)이고, 하네스가 곧 경쟁의 해자(moat)가 되는 시대예요. 하네스 엔지니어링은 단순히 프롬프트를 잘 쓰는 것을 넘어, AI가 실제로 일을 완수할 수 있는 구조를 만드는 것이에요. 지금 바로 CLAUDE.md 파일 하나를 만드는 것부터 시작해 보세요. 단일 에이전트의 실패를 관찰하고, 그 실패를 시스템으로 해결하는 순간, 여러분의 여러분의 AI 활용 수준은 완전히 다른 차원으로 올라갈 거예요. 하네스 엔지니어링의 세계에 첫 발을 내딛어 보시길 바랍니다!

• 참고 ​자료

Harness design for long-running application development

Anthropic is an AI safety and research company that’s working to build reliable, interpretable, and steerable AI systems.