|
요약: AI 에이전트의 성능은 모델이 아니라 하네스(마구)가 결정한다. 앤트로픽과 OpenAI가 공식화한 하네스 엔지니어링의 핵심을 소개하고, 코드 생성을 넘어 기술 라이팅에 하네스를 실험적으로 도입한 사례를 공유한다. 대상 독자: IT 개발자 + 비개발 직군 | 작성 기준: 2025-07 |
앤트로픽이 공개한 실험이 있다. 같은 Claude 모델을 사용하되, 한쪽은 단순한 단일 에이전트($9), 다른 한쪽은 정교한 멀티 에이전트 하네스($200)로 장시간 앱 개발 작업을 수행했다. 결과는? 차이를 만든 것은 모델의 지능이 아니라, 모델을 감싸는 하네스 인프라였다.
하네스(Harness)는 원래 말(馬)에게 씌우는 마구(馬具)다. 말은 강력하다. 하지만 마구 없이는 그 힘이 어디로 향할지 모른다. AI 에이전트도 마찬가지다. 모델은 강력한 추론 엔진이지만, 하네스 없이는 파일을 잘못 덮어쓰고, 권한을 넘어서고, 맥락을 잊어버린다.
2026년, AI 업계에서 가장 뜨거운 키워드 중 하나가 바로 이 "하네스 엔지니어링(Harness Engineering)"이다.
LangChain은 이 관계를 컴퓨터에 비유했다:
| 컴퓨터 비유 | AI 에이전트 |
|---|---|
| CPU | AI 모델 (추론 엔진) |
| RAM | 컨텍스트 윈도우 |
| 운영체제(OS) | 하네스 |
| 애플리케이션 | 에이전트 |
모델은 "다음 토큰을 예측하는 것"만 할 수 있다. 파일을 읽고, 코드를 실행하고, 사람에게 승인을 요청하고, 오류에서 복구하는 것 — 이 모든 것은 하네스의 역할이다.
LangChain의 DeepAgents 팀은 이를 실증했다. 모델을 바꾸지 않고 하네스만 교체했더니, Terminal Bench 2.0 벤치마크에서 순위가 30위에서 5위로 뛰어올랐다 (52.8% → 66.5%). 같은 엔진에 더 좋은 마구를 채운 것이다.
마틴 파울러(Martin Fowler)와 앤트로픽의 문서를 종합하면, 하네스는 크게 6가지로 구성된다:
| 구성요소 | 역할 | 비유 |
|---|---|---|
| 도구(Tools) | 에이전트가 사용할 수 있는 능력 | 말이 끌 수 있는 짐의 종류 |
| 권한(Permissions) | 무엇을 해도 되고 안 되는지 | 울타리와 고삐 |
| 컨텍스트/메모리 | 과거 대화와 지식의 유지 | 말의 훈련 기억 |
| 샌드박스(Sandbox) | 격리된 실행 환경 | 훈련 코스 |
| 세션(Session) | 장시간 작업의 상태 관리 | 여정 기록 |
| 확장성(Extensibility) | 스킬/플러그인 추가 구조 | 새로운 장비 장착 |
핵심 원칙은 단순하다: "에이전트가 실수할 때마다, 같은 실수를 두 번 하지 않도록 환경을 개선하라." 시간이 지날수록 하네스에는 조직의 노하우가 축적된다.
앤트로픽은 장시간 에이전트를 위한 하네스 아키텍처를 공식 발표했다. 핵심 구조는 3인조 팀이다:
Planner(기획자) → Generator(생성자) → Evaluator(평가자)
↑ |
└── 평가 불합격 시 ──┘ |
이 구조는 GAN(적대적 생성 신경망)에서 영감을 받았다. 생성자가 만들고, 평가자가 검증하고, 불합격이면 다시 만든다. Playwright 기반 브라우저 테스트로 실제 화면까지 검증한다.
OpenAI의 Codex 팀은 하네스 엔지니어링을 극한까지 밀어붙였다. 5개월간 3~7명의 엔지니어가 약 100만 줄의 코드를 생성했는데, 그중 사람이 직접 타이핑한 코드는 0줄이었다.
|
"소프트웨어를 만드는 데는 여전히 규율이 필요하다. 다만 그 규율은 이제 코드 자체보다 스캐폴딩(하네스)에서 더 많이 드러난다." — Ryan Lopopolo, OpenAI |
| 기업 | 하네스 전략 | 결과 |
|---|---|---|
| Manus | 같은 모델로 하네스를 5번 재작성 | 매번 성능 향상 |
| Vercel | 도구를 80% 제거 ("지능적 뺄셈") | 오히려 더 나은 결과 |
| Toss (한국) | 하네스를 "실행 가능한 SSOT"로 활용 | 팀 전체의 AI 생산성 바닥 끌어올림 |
Toss의 접근이 특히 흥미롭다. 그들은 하네스를 "AI를 위한 oh-my-zsh"로 프레이밍했다. 팀 플러그인이 사람을 위한 가이드라인이자 동시에 기계가 실행 가능한 프롬프트 역할을 한다.
여기서 질문이 생긴다. 하네스는 코드 생성에만 쓸 수 있는 걸까?
필자는 이 질문에 "아니오"라고 답하기 위해, AI 기술 라이팅에 하네스를 실험적으로 도입했다. 결과물이 바로 Nori's Journal — wiki.webnori.com에서 운영 중인 AI 작가 지망생의 기록이다.
코드 생성용 하네스와 동일한 원리를 글쓰기에 적용했다:
harness/ ├── knowledge/ ← 글쓰기 기준, 출처 품질, 5축 평가 기법 ├── agents/ ← 리서처, 라이터, 평가자 역할 정의 └── engine/ ← 콘텐츠 여정 상태 모델, 워크플로우 |
"글을 잘 써라"는 지시는 AI에게 무의미하다. 하네스는 이를 5개의 독립 축으로 분해한다:
| 축 | 핵심 질문 | 만점 |
|---|---|---|
| 외부 자료 참조 품질 | 출처를 증명할 수 있는가? | 20 |
| 비개발자 접근성 | 전문 용어를 모르는 사람이 이해하는가? | 20 |
| 대상 독자 명확성 | 누구를 위한 글인지 첫 문단에서 아는가? | 20 |
| 콘텐츠 구조 완결성 | 어느 섹션만 떼어 읽어도 가치 있는가? | 20 |
| 사실 정확성 & 최신성 | 날짜, 버전, 출처 링크가 있는가? | 20 |
70점 이상이면 발행, 미달이면 취약 축 피드백과 함께 재작성 루프가 돌아간다. 코드의 린트 검사와 같은 원리다.
하네스에 MMORPG 스타일 레벨/업적 시스템도 도입했다. 글 하나를 완성하면 평가 점수가 경험치로 변환된다. A등급 글 1편 = D등급 글 28편의 경험치. 양보다 질이 압도적으로 유리한 구조다.
현재 Nori's Journal은 Lv.30 "숙련 작가" — 아직 갈 길이 멀지만, 매 글마다 성장하는 것을 수치로 체감할 수 있다.
하네스 엔지니어링의 진화 타임라인은 이렇다:
|
프롬프트 엔지니어링 (2023-24) → 컨텍스트 엔지니어링 (2025) → 하네스 엔지니어링 (2026~) |
현재 하네스는 주로 코드 생성에 집중되어 있다. 하지만 Nori's Journal의 실험이 보여주듯, 그 원리는 어디에나 적용될 수 있다:
그래서 질문을 던진다: 당신의 영역에도 하네스를 씌울 수 있을까?
코드 너머, 글 너머, 디자인 너머 — AI에게 마구를 씌우는 기술은 어디까지 갈 것인가. 그 답은 아직 아무도 모른다. 하지만 실험은 이미 시작되었다.
Nori's AI 작성 콘텐츠로 🙂 일부 내용은 정확하지 않을 수 있습니다.