하나의 AI에게 질문하던 시대는 끝났다.
여러 AI 에이전트로 구성된 팀을 설계하고 조율하는
하네스 엔지니어링이 핵심 역량이다.
AI를 활용하는 방식은 3년 만에 세 번의 패러다임 전환을 겪었습니다. 당신이 영화감독이라고 가정합시다. 아무리 뛰어난 배우 한 명이 있어도, 대본도 없고 조명도 없고 촬영 순서도 정해지지 않았다면 좋은 영화를 만들 수 있을까요? 감독의 진짜 능력은 연기를 직접 하는 것이 아니라 -- 배우에게 역할을 부여하고, 스태프를 배치하고, 촬영 순서를 설계하고, 최종 편집까지 전체 과정을 지휘하는 데 있습니다.
하네스 엔지니어링(Harness Engineering)은 AI 에이전트를 감싸는 전체 환경 -- 제약 조건, 도구 접근 권한, 피드백 루프, 에이전트 간 협업 구조 -- 을 설계하는 엔지니어링 분야입니다. 2026년 2월, OpenAI는 Codex 팀이 100만 줄 이상의 프로덕션 애플리케이션을 인간이 단 한 줄의 코드도 직접 작성하지 않고 구축한 사례를 공개하면서, "하네스 엔지니어링"이라는 용어를 공식적으로 사용했습니다.
Anthropic 역시 "Effective Harnesses for Long-Running Agents" 블로그를 통해 장시간 실행되는 에이전트를 위한 하네스 설계 원칙을 발표했습니다.
네 가지 변화가 동시에 일어나면서, "좋은 질문 하나"로는 더 이상 충분하지 않게 되었습니다.
| 변화 | 이전 | 현재 | 결과 |
|---|---|---|---|
| 모델 능력 | 간단한 Q&A | 복잡한 코딩, 분석, 의사결정 | 더 큰 작업 위임 가능 |
| 작업 복잡도 | 단일 질문 | 수시간~수일 걸리는 프로젝트 | 단일 에이전트로 불충분 |
| 도구 통합 | 텍스트만 | 파일시스템, Git, API, DB | 에이전트 행동 범위 확대 |
| 품질 요구 | "괜찮은 답변" | 프로덕션 수준 코드 | 검증 시스템 필요 |
주목할 숫자가 하나 있습니다.
LangChain 코딩 에이전트, Terminal Bench 2.0 -- 모델 변경 없이 하네스만 개선하여 +26% 성능 향상
오케스트라를 떠올려보세요. 바이올리니스트, 첼리스트, 플루티스트가 각자 악보를 보며 연주하고, 지휘자가 전체를 조율합니다. 하네스의 구조도 이와 똑같이 세 가지 요소로 이루어져 있습니다.
작업 분배 · 진행 관리 · 결과 통합 -- 지휘자
여러 에이전트가 어떤 순서와 방식으로 협업하는지를 정의합니다. 교향곡의 악장이 정해져 있듯이, 에이전트들의 실행 순서와 데이터 흐름을 설계하는 것입니다.
| 역할 | 누가 언제 무엇을 연주(실행)할지 조율 |
| 방식 | 파이프라인, 팬아웃/팬인, 전문가풀, 생성-검증, 계층적 위임 |
| 비유 | 교향곡의 지휘자 |
특정 역할을 수행하는 AI 단위입니다. 팀원 한 명을 채용할 때 직무기술서(JD)를 쓰듯이, 에이전트도 세 가지로 정의합니다.
| 역할 | 에이전트의 전문 분야와 페르소나 (예: "프론트엔드 개발 전문가") |
| 도구 | 파일 읽기/쓰기, Git, 웹 검색, API 호출 |
| 권한 | "src/ 디렉토리만 수정 가능", "main 브랜치 push 불가" |
에이전트가 특정 작업을 수행할 때 따라야 하는 작업 절차와 출력 규칙입니다. 누군가에게 "알아서 해"라고 하면 결과가 들쭉날쭉하듯이, 에이전트에게도 명확한 절차서가 필요합니다.
| 워크플로우 | "1. 조사 -> 2. 분석 -> 3. 작성 -> 4. 검토" |
| 입력 규칙 | 대상 독자, 주제, 분량, 형식 |
| 출력 규칙 | 마크다운 형식, 출처 명시, 7000자 이상 |
| 제약 조건 | 추측 금지, 검증되지 않은 정보 사용 금지 |
각 요소를 클릭하면 상세 설명이 표시됩니다
전쟁에서 장군이 병력을 배치하는 진형이 있듯이, 에이전트 시스템에도 검증된 디자인 패턴이 있습니다. 상황에 따라 적절한 패턴을 선택하는 것이 하네스 엔지니어의 핵심 역량입니다.
| 패턴 | 구조 | 병렬성 | 복잡도 | 대표 사례 |
|---|---|---|---|---|
| 파이프라인 | A -> B -> C | 없음 | 낮음 | CI/CD 파이프라인 |
| 팬아웃/팬인 | 병렬 실행 -> 통합 | 높음 | 중간 | 동시 리서치 |
| 전문가 풀 | 라우팅 기반 선택 | 가변 | 중간 | 고객 지원 챗봇 |
| 생성-검증 | 생성 <-> 검증 루프 | 없음 | 중간 | 코드 리뷰 |
| 계층적 위임 | 트리 구조 위임 | 높음 | 높음 | 대규모 프로젝트 |
실전에서는 이 패턴들을 조합해서 씁니다. 이 교육 자료 자체가 "팬아웃 -> 팬인 -> 생성-검증"을 결합한 사례입니다.
이론은 충분합니다. 이제 직접 하네스를 만들어봅시다. Claude Code의 .claude/ 디렉토리 구조를 활용한 실전 예제를 따라해보겠습니다.
하네스의 뼈대는 디렉토리 구조에서 시작합니다. 각 폴더의 역할은 명확합니다. agents/에는 "누가" 일하는지, skills/에는 "어떻게" 일하는지, CLAUDE.md에는 프로젝트 전체의 규칙이 들어갑니다.
에이전트는 마크다운 파일로 정의합니다. 팀원에게 주는 역할 설명서라고 생각하면 됩니다. 핵심은 구체적인 역할과 제약을 명시하는 것입니다.
스킬은 에이전트가 수행하는 작업 절차를 정의합니다. 업무 매뉴얼이라고 생각하면 됩니다.
오케스트레이터는 전체 워크플로우를 정의합니다. 프로젝트 관리자가 만드는 실행 계획서와 같습니다.
이론을 실제로 적용한 사례를 보는 것만큼 좋은 공부는 없습니다. 사실, 지금 읽고 있는 이 교육 자료 자체가 하네스 엔지니어링으로 제작되었습니다.
6명의 전문 에이전트가 각자의 역할을 맡았습니다.
이 프로젝트는 팬아웃, 팬인, 생성-검증 세 가지 패턴을 조합하여 사용했습니다. 각 Phase를 클릭해 상세 흐름을 확인하세요.
4개 전문 에이전트가 동시에 각자의 챕터를 집필합니다. 한 사람이 순차적으로 네 챕터를 쓰면 4배의 시간이 걸리지만, 병렬 실행으로 시간을 1/4로 단축했습니다.
content-assembler가 4개 산출물을 하나로 통합합니다. 용어 통일, 날짜/수치 일관성, 중복 내용 제거를 체크합니다.
별도의 fact-checker가 전체 문서를 검증합니다. 각 에이전트가 생성한 정보의 정확성을 이중으로 확인했습니다.
2026년 현재, 에이전트 시스템을 구축하기 위한 다양한 프레임워크가 경쟁하고 있습니다.
에이전트가 외부 도구와 소통하려면 표준 인터페이스가 필요합니다. 그것이 바로 MCP(Model Context Protocol)입니다. USB-C처럼 하나의 표준 커넥터를 제공합니다.
대형 기술 기업들도 앞다투어 에이전트 플랫폼을 출시하고 있습니다.
2026년, 하네스 엔지니어(Harness Engineer)라는 새로운 직무가 등장하고 있습니다. 코드를 직접 작성하던 개발자가 AI 팀의 감독으로 역할을 전환하는 것입니다.
가장 중요한 것은 "코딩 실력"이 아니라 "설계와 조율 능력"입니다. 코드를 10년간 짠 시니어 개발자와 같은 출발선에서 시작할 수 있는 새로운 분야입니다.
에이전트 간 협업 구조를 설계하는 아키텍처 능력
에이전트의 역할과 제약을 명확히 정의하는 능력
생성-검증 루프, CI/CD 파이프라인 설계
에이전트가 작업할 분야에 대한 깊은 이해
에이전트가 실패했을 때 하네스의 어떤 부분이 문제인지 파악
| 개념 | 핵심 정의 | 기억할 키워드 |
|---|---|---|
| 하네스 엔지니어링 | AI 에이전트 팀을 감싸는 환경을 설계하는 기술 | 에이전트, 스킬, 오케스트레이션, 피드백 루프 |
| 에이전트 | 특정 역할을 수행하는 AI 단위 (역할 + 도구 + 권한) | 팀원 |
| 스킬 | 에이전트의 작업 절차와 출력 규칙 | 업무 매뉴얼 |
| 오케스트레이션 | 에이전트 간 협업 순서와 방식 | 지휘 |
| MCP | AI와 외부 도구를 연결하는 표준 프로토콜 | USB-C |
| 하네스 엔지니어 | 에이전트 팀의 환경과 워크플로우를 설계하는 직무 | AI 감독 |
같은 모델이라도 하네스 설계에 따라 성능이 52.8%에서 66.5%로 뛸 수 있습니다.
다섯 가지 디자인 패턴은 단독으로 쓰기보다 상황에 맞게 조합할 때 진가를 발휘합니다.
하네스 엔지니어의 핵심 역량은 코딩이 아니라 시스템 설계와 조율 능력입니다.