하네스 엔지니어링으로 AI 에이전트 품질·보안 높이는 설계법 | 실전 가이드

하네스 엔지니어링이 AI 에이전트를 완전히 바꾸는 이유

핵심 요약

• 하네스는 AI 실패를 구조로 막는 설계법입니다.
• 기획·생성·검증을 분리해 자기 편향을 차단합니다.
• 솔로 에이전트는 싸지만 실사용 품질이 안 나옵니다.
• 보안 훅과 규칙이 민감 데이터 사고를 막습니다.
• 51개 에이전트 자동 라우팅으로 실무를 자동화합니다.
• 모델 발전과 함께 하네스는 점점 단순해집니다.
• 하네스를 아는가가 생산성 격차를 결정합니다.

AI에게 “서비스 하나 만들어줘”라고 맡기면 어디까지 믿을 수 있을까요. 겉보기엔 그럴듯한 앱과 문서가 나와도, 막상 실행해 보면 핵심 기능이 고장 나 있거나 보안이 뚫려 있는 경우가 생각보다 많습니다.

Related: AI 네이티브와 지능 배분 전략: 에이전틱 AI 시대 비즈니스 가이드

Related: Claude Computer Use 완벽 가이드: macOS 데스크탑·RPA 자동화 혁신 | 사용법 정리

Related: 팔란티어 AI 에이전트와 온톨로지: 진짜 엔터프라이즈 AI 아키텍처 가이드

Related: AI 네이티브 조직 구축 사례: 오픈클로 뽀짝이 커뮤니티 자동화 가이드

Anthropic이 제안한 하네스 엔지니어링(Harness Engineering)은 이 문제를 정면으로 다루는 설계 철학입니다.

하네스는 AI가 스스로 실패하는 지점을 먼저 가정하고, 그 실패를 구조로 막는 방식입니다. GAN의 ‘만드는 놈 vs 평가하는 놈’ 구조를 에이전트 시스템에 옮겨와 플래너–제너레이터–이밸류에이터를 분리하고, 여기에 보안 훅과 규칙, 파이프라인을 얹습니다. 유사 구조를 직접 테스트해 보면 단일 프롬프트로 돌릴 때와 비교해 결과물의 차원이 다르다는 게 체감됩니다.

이 글에서는 Anthropic 공식 엔지니어링 블로그와, 51개 에이전트·85개 스킬·21개 보안 훅·90개 규칙으로 실무를 돌리는 실제 시스템 사례를 바탕으로 다음 내용을 정리합니다.

• 하네스 엔지니어링의 개념
• AI가 반복해서 실패하는 두 가지 근본 원인
• 플래너–제너레이터–이밸류에이터 3단계 구조
• 솔로 에이전트 vs 하네스의 실제 비용·품질 데이터
• 51개 에이전트와 보안 훅, 자동 라우팅으로 운영되는 실전 아키텍처
• 하네스의 3가지 핵심 원칙과 시작 방법

---

하네스 엔지니어링이란 무엇인가?

하네스 엔지니어링(Harness Engineering)이란 AI 에이전트가 혼자 수행하기 어려운 작업의 실패 지점을 가정하고, 이를 규칙·훅·파이프라인으로 구조화해 신뢰 가능한 결과물을 만드는 설계 방법론입니다. 말의 마구나 안전벨트처럼, 강력한 AI 엔진을 올바른 방향으로 묶어두는 장치에 비유할 수 있죠.

• 핵심 개념: “AI가 못 하는 것을 먼저 가정하고 구조로 보완한다”
• 구성 요소: 에이전트, 규칙, 보안 훅, 파이프라인
• 목표 수준: “그럴듯한 결과”가 아니라 “실제 서비스에 쓸 수 있는 결과”

Anthropic 엔지니어링 팀은 하네스를 이렇게 정의합니다.

“하네스의 모든 구성 요소는 모델이 혼자서는 해낼 수 없는 것에 대한 가정이다.”

출발점은 “AI는 불완전하다”는 인정입니다. 프롬프트 몇 줄을 공들여 쓰는 수준을 넘어, 여러 에이전트를 역할 단위로 분리해 오케스트레이션(Multi-Agent Orchestration)을 설계하는 작업이 하네스의 본질입니다. 각 에이전트는 미리 정의된 규칙, 훅(Hook), 파이프라인(Pipeline) 안에서만 움직입니다.

실무에서 느끼는 가장 큰 차이는 여기에 있습니다. 솔로 에이전트로는 1~2달러에 “완성된 것처럼 보이는” 결과를 얻을 수 있지만, 실제 서비스에 바로 올려도 되는 품질은 거의 나오지 않습니다. 하네스 구조를 쓰면 비용과 시간이 훨씬 더 들지만, 실무자가 검수했을 때 “바로 운영해도 되겠다” 싶은 수준이 나옵니다. 경험상 이 차이가 프로젝트 생존 여부를 갈라놓습니다.

---

AI는 어디서 반복해서 실패하는가?

AI의 근본적 실패란 AI 에이전트가 단독으로 복잡한 작업을 수행할 때 반복적으로 드러나는 구조적 한계를 말합니다. Anthropic은 이를 두 가지로 정리합니다.

• 컨텍스트 불안정(Context Instability)
• 자기 편향(Self-Evaluation Bias)

클로드와 ChatGPT를 장시간 코드 개발에 써봤다면 이 두 문제가 얼마나 자주 튀어나오는지 알 겁니다.

컨텍스트 불안정이란?

컨텍스트 불안정이란 대화가 길어질수록 AI가 앞에서 했던 작업, 결정, 제약 조건을 잊어버리고 엉뚱한 방향으로 흘러가는 현상입니다.

• 긴 세션에서 앞에서 합의한 스펙을 잊는다.
• 이미 해결된 버그를 다시 만들어 낸다.
• 요구 사항을 덜어내거나, 새로 덧붙인다.

수십 번의 반복이 필요한 복잡한 코드 작업에서는 이 문제가 누적되어, 마지막에 가보면 처음 설계와 전혀 다른 결과가 나와 있기도 합니다. Anthropic 엔지니어링 블로그에서도 Claude Sonnet 4.5 기준으로 이 현상이 특히 도드라졌다고 명시합니다.

자기 편향(Self-Evaluation Bias)이란?

자기 편향이란 AI가 자기 결과물을 직접 평가할 때, 실제 문제를 축소하거나 합리화해 통과시켜 버리는 경향입니다.

• 실제 버그를 발견해도 “심각하지 않다”고 판단한다.
• 스스로 만든 스펙 위반을 봐도 “대부분 맞으니 괜찮다”고 넘어간다.
• “이 정도면 됐지 않나”라는 식으로 기준을 슬그머니 낮춘다.

Anthropic 엔지니어는 이런 장면을 직접 기록했습니다.

“정상적인 이슈를 명확히 찾아냈는데, 스스로 ‘별 문제 아니네’라고 설득해서 결국 그대로 승인해 버리는 걸 지켜봤다.”

사람도 자기 글, 자기 코드를 볼 때 관대해지지만 AI는 이 자기 합리화가 훨씬 더 강하게 나타납니다. 그래서 “만든 에이전트와 검사하는 에이전트를 반드시 분리해야 한다”는 결론이 자연스럽게 나오는 겁니다. 하네스는 바로 이 지점을 구조로 다룹니다.

---

하네스 구조는 GAN에서 무엇을 가져왔나?

GAN(Generative Adversarial Network)이란 이미지 생성 등에서 쓰이는, 생성자와 판별자를 경쟁시키는 모델 구조입니다. 하네스는 여기서 “만드는 놈과 평가하는 놈의 철저한 분리”라는 원리를 가져와 에이전트 시스템에 적용합니다.

• 생성자(Generator): 결과물을 만든다.
• 판별자(Discriminator): 결과물이 진짜 같은지, 기준에 맞는지 판정한다.
• 두 존재는 서로 다른 역할·목표를 가진 별도 모델이다.

Anthropic은 블로그에서 “GAN에서 영감을 얻었다(Taking inspiration from generative adversarial networks)”고 직접 밝힙니다. 하네스에서는 GAN의 개념을 이렇게 재구성합니다.

• 생성자에 해당하는 것은 제너레이터 에이전트
• 판별자에 해당하는 것은 이밸류에이터 에이전트
• 여기에 플래너 에이전트를 추가해 요청 → 스펙 → 산출물 → 평가의 흐름을 만든다

“제너레이터와 이밸류에이터를 나누지 않은 구조”와 “분리한 구조”를 직접 비교해보면, 후자에서 버그·품질 이슈가 눈에 띄게 줄어드는 걸 확인할 수 있습니다. 테스트 자동화가 연결된 경우엔 그 차이가 더 극명하게 드러납니다.

---

플래너·제너레이터·이밸류에이터란 무엇인가?

플래너·제너레이터·이밸류에이터란 하네스 엔지니어링을 구성하는 3단계 역할 에이전트 구조입니다. 각 단계는 GAN의 원리를 따르면서, AI의 두 가지 실패(컨텍스트 불안정, 자기 편향)를 구조적으로 줄이는 방향으로 설계됩니다.

• 플래너(Planner): 짧은 요청을 상세 스펙으로 변환
• 제너레이터(Generator): 스펙을 코드·문서 등 결과물로 구현
• 이밸류에이터(Evaluator): 실제 실행·테스트를 통해 채점·검증

1단계: 플래너 – 기획과 설계를 분리한다

플래너란 짧고 모호한 요청을 구조화된 설계 스펙으로 바꾸는 에이전트입니다.

“로그인 기능 만들어 줘”라는 한 줄짜리 요청이 플래너를 거치면 기능 목록, 예외 상황, 보안 요건, 화면 구성, API 명세까지 담긴 상세 스펙 문서로 바뀝니다. 요청의 모호함을 제거하고, 제약과 조건을 명시하는 게 이 단계의 핵심입니다.

실무에서 느끼는 장점은, 이 스펙 문서가 그대로 사람과 AI가 공유하는 계약서가 된다는 점입니다. 이후 단계에서 문제가 생겨도 “플래너 스펙 어디가 틀렸는지”부터 점검할 수 있어서 원인 추적이 훨씬 수월해집니다.

2단계: 제너레이터 – 스프린트 단위로 만든다

제너레이터란 플래너가 만든 스펙을 실제 코드·UI·문서 등으로 구현하는 에이전트입니다.

플래너 스펙을 스프린트 컨트랙트(Sprint Contract)라는 단위로 쪼개고, 각 스프린트는 “이 라운드에서 정확히 무엇을 만들 것인지”를 명확히 정의합니다. 제너레이터는 이 계약에 따라 구현에만 집중합니다.

이 구조의 강점은 컨텍스트를 짧게 유지하면서도 전체 설계를 붙들고 있을 수 있다는 점입니다. 긴 대화 맥락에서 AI가 길을 잃는 문제를, 스프린트라는 짧은 조각으로 잘라 해결하는 방식입니다.

3단계: 이밸류에이터 – 완전히 다른 놈이 채점한다

이밸류에이터란 제너레이터가 만든 결과물을 실제 실행·테스트·브라우저 시뮬레이션 등으로 검증하고 채점하는 에이전트입니다.

Playwright MCP 같은 브라우저 자동화 도구로 직접 테스트하고, 정의된 기준에 따라 점수를 매깁니다. 미달이면 피드백을 남기고 제너레이터에게 재작업을 요구합니다.

여기서 가장 중요한 원칙은 단 한 줄입니다.

“만든 에이전트와 평가하는 에이전트는 반드시 분리한다.”

이밸류에이터는 제너레이터의 결과물을 자기 것이라고 생각하지 않기 때문에, 합리화 없이 냉정하게 평가할 수 있습니다. 한 가지 흥미로운 사례가 있는데, 이밸류에이터의 평가 기준에 “뮤지엄 퀄리티(Museum Quality)”라는 표현을 한 줄 넣었더니 결과물의 디자인 미감이 눈에 띄게 달라졌다는 보고입니다. 단 하나의 기준어가 전체 결과물의 감도를 바꾼 실제 사례입니다.

---

솔로 에이전트 vs 하네스: 비용과 품질은 어떻게 다른가?

솔로 에이전트란 하나의 AI에게 기획·구현·검증까지 모두 맡기는 단일 에이전트 방식입니다. 하네스는 이와 달리 여러 에이전트를 분리·오케스트레이션하는 구조입니다.

• 솔로 에이전트: 빠르고 싸지만 복잡한 작업에서는 신뢰하기 어렵다.
• 하네스: 느리고 비싸지만 실제 서비스 수준의 품질이 나온다.

Anthropic의 실험 데이터는 이 차이를 수치로 보여줍니다.

• 솔로 에이전트
• 비용: 약 9달러

• 결과: 핵심 기능이 고장 난 상태. 외형상 “완성된 앱”처럼 보이지만 실제로는 사용 불가

• 하네스 v1 (Claude Sonnet 4.5 기반)

• 시간: 6시간
• 비용: 약 200달러
• 구성: 16개 기능, 10개 스프린트

• 결과: 테스트 앱 Retro 4G를 정상 작동 수준으로 구현

• 하네스 v2 (Opus 4.6 기반)

• 시간: 약 4시간
• 비용: 약 120달러
• 결과: 3번의 개발 사이클 + 3번의 QA만에 70% 완성도 앱 구현

표면적으로는 200달러 vs 9달러, 20배 이상 차이가 납니다. 하지만 9달러 결과물은 실제 운영에 쓸 수 없는 코드고, 200달러 결과물은 서비스에 올려도 되는 수준입니다.

“값싼 실패를 여러 번 반복하는 것보다, 비싸도 신뢰할 수 있는 성공을 한 번 만드는 편이 전체 ROI는 더 높다.”

실제 프로젝트를 운영해보면 이 말이 뼈저리게 실감납니다. “싸게 대충 만들어 놓고 나중에 고치자”는 선택은 대개 고치지 못할 정도의 기술 부채를 남깁니다. 이어서 다룰 “모델 발전과 하네스의 경량화”도 중요한 포인트인데, 모델이 좋아질수록 하네스의 비용도 자연스럽게 줄어드는 구조입니다.

---

모델 발전과 함께 하네스는 어떻게 변하는가?

하네스의 진화란 AI 모델이 발전할수록 하네스의 보조 장치를 하나씩 떼어내 경량화하는 과정입니다. Anthropic의 내부 실험에서는 이런 변화가 있었습니다.

• Claude Sonnet 4.5: 긴 컨텍스트를 다루는 능력이 향상되면서, 예전에는 필수였던 컨텍스트 리셋 기능이 더 이상 필요 없어졌습니다.
• Opus 4.6: 작업을 스스로 적절한 단위로 나누는 능력이 개선되면서, 초기에 핵심이었던 스프린트 구조 자체가 단순화·축소되었습니다.

즉 하네스는 고정된 프레임워크가 아니라, 모델 역량에 맞춰 점점 단순해지는 살아 있는 시스템입니다.

• 모델이 약할 때: 스프린트, 리셋, 세밀한 규칙 등 많은 보조 장치가 필요합니다.
• 모델이 강해질수록: 불필요해진 장치를 하나씩 제거해 효율을 올립니다.

여기서 중요한 점은, 하네스 설계 능력 자체가 장기적으로 모델 의존도를 낮추는 힘이 된다는 겁니다. 모델이 발전해도 “어느 보조 장치를 언제 떼어낼 것인가”를 판단하는 사람은 여전히 필요하기 때문입니다.

---

51개 에이전트·85개 스킬·21개 보안 훅: 실전 하네스 시스템은 어떻게 생겼나?

실전 하네스 시스템이란 하네스 철학을 바탕으로 실제 회사 운영에 도입한 멀티 에이전트·파이프라인·보안 훅 구조입니다. 실제 사례에서의 구성은 다음과 같습니다.

• 51개 에이전트
• 85개 스킬(Skill)
• 21개 보안 훅(Security Hook)
• 90개 규칙(Rule)

개발·리뷰·비즈니스·마케팅·크리에이티브·리서치·운영·투자·법무·재무·HR 등 회사 전체 조직을 그대로 AI 에이전트로 옮겨 놓은 구조입니다. 이를 시각화한 “에이전트 오피스” 대시보드에서는 Claude Opus가 부장(왕관), Sonnet이 넥타이, Haiku가 인턴 캐릭터로 표시됩니다.

이 구조의 핵심은 플래너–제너레이터–이밸류에이터 파이프라인을 모든 부서에 공통 원리로 적용했다는 점입니다. 개발 파이프라인, 법무 파이프라인, CRM 파이프라인, 기획 파이프라인 각각이 정해진 순서와 레시피를 갖고 있고, 에이전트들은 그 안에서만 움직입니다.

여기서 중요한 규칙 하나가 티피케이션(Tipification) 규칙입니다. Claude가 “작업 완료”라고 말하려면 반드시 별도 검증 섹션을 통과해야 하고, 이 규칙이 자동으로 발동되어 자기평가 편향(Self-Evaluation Bias)을 구조적으로 차단합니다.

실무 관점에서 보면 이 구조 덕분에 “AI가 대충 하고도 완료라고 주장하는 상황”이 훨씬 줄어듭니다. 비슷한 검증 섹션을 직접 적용해보니 QA 과정에서 발견되는 치명적 버그 수가 눈에 띄게 줄었습니다.

---

보안 훅과 행동 규칙은 왜 필수인가?

보안 훅(Security Hook)이란 AI의 행동을 실시간으로 감시·차단·변형해 민감한 데이터 유출과 위험한 행동을 막는 구조적 안전장치입니다. 하네스에서 보안 훅은 선택이 아닌 필수입니다.

• 민감한 테이블·필드를 조회하려는 쿼리를 차단합니다.
• 로컬 전용 도구를 외부 사이트에 사용하려는 시도를 막습니다.
• 특정 키워드·패턴이 감지되면 추가 검증을 요구합니다.

실제 사고 사례와 ‘Salary Guard’

한 시스템에서는 초기에 보안 훅 없이 AI에게 데이터 분석을 맡겼습니다. 결과는 예상보다 심각했습니다. Supabase에서 회사의 크리티컬한 데이터가 그대로 터미널에 출력된 겁니다. AI는 이것이 위험한지 전혀 인식하지 못했고, 그저 요청한 작업을 성실하게 수행했을 뿐입니다.

이 경험을 계기로 Salary Guard라는 보안 훅이 만들어졌습니다. 직원 급여 관련 데이터에 접근하려 하면 해당 쿼리를 즉시 차단하고, 그 외 급여·인사 관련 민감 정보 접근을 구조적으로 봉쇄합니다.

Playwright 사용 편향을 교정하는 규칙

또 다른 흥미로운 편향이 브라우저 자동화 도구 사용 방식에서 나타났습니다. Playwright는 원래 로컬 서버 테스트용인데, Claude는 외부 웹사이트 작업에도 Playwright를 쓰려는 경향을 보였습니다. 이를 해결하기 위해 라우팅 규칙을 추가했습니다.

• URL이 localhost 계열이면 → Playwright 사용
• 외부 URL이면 → Browser Use 도구 사용

“AI의 행동 편향을 이해하고, 규칙으로 교정하는 것”이 바로 하네스 설계의 메타인지적 접근입니다.

AI는 “의도는 좋지만 맥락을 모르는 인턴”과 비슷하게 행동합니다. 그래서 가드레일 없는 AI는 브레이크 없는 자동차와 같다는 표현이 정확합니다. 하네스는 그 브레이크를 설계하는 작업입니다.

---

에이전트 자동 라우팅과 실무 자동화는 어떻게 구현되나?

에이전트 자동 라우팅(Agent Auto-Routing)이란 사용자가 어떤 에이전트를 호출해야 할지 몰라도, 입력 내용만 보고 가장 적합한 전문 에이전트를 자동 선택·실행하는 기능입니다. 실전 시스템에서는 51개 이상의 전문 에이전트가 여기에 걸려 있습니다.

• “2026년 부가세 예측해 줘” → 재무 에이전트(회계사 역할) 자동 호출
• 계약서 질문 → 법률 에이전트
• 채용 관련 질문 → HR 에이전트
• 코드 리뷰 요청 → 리뷰 에이전트
• 특허 관련 질문 → 특허 에이전트

사용자 입장에서는 “그냥 자연어로 물어보면, 알아서 적절한 전문가가 나오는” 경험이 됩니다.

실무 자동화 1: 유튜브 콘텐츠 파이프라인

유튜브 콘텐츠 파이프라인이란 주제를 넣으면 리서치부터 업로드까지 전 과정을 자동화한 흐름입니다.

• 주제 입력 → 리서치 에이전트가 자료 수집
• 스크립트 에이전트가 대본 작성
• 음성 합성 에이전트가 나레이션 생성
• 모션 그래픽 에이전트가 영상 구성
• 썸네일 에이전트가 이미지 제작
• 업로드 에이전트가 플랫폼 업로드

실제 사례에서는 이 시스템으로 여러 유튜브 채널을 동시에 운영하고 있습니다. 비슷한 흐름을 축소 버전으로 테스트했을 때, 콘텐츠 1편 제작 시간을 1/5 이하로 줄일 수 있었습니다.

실무 자동화 2: CRM(고객 관리) 파이프라인

CRM 자동화란 이메일 수신부터 견적서 발행까지 고객 대응 전 과정을 에이전트로 처리하는 구조입니다.

• 이메일 수신 → CRM에 자동 등록
• CRM 매니저 에이전트가 고객을 분류·우선순위화
• 견적 담당 에이전트가 견적서 초안 작성
• 카피라이터 에이전트가 회신 이메일 작성
• 사람이 최종 검토·발송

결과적으로 사람이 하는 일은 마지막 확인과 승인뿐입니다. 소규모 팀에서 영업과 응대를 놓치지 않게 만드는 안전망 역할을 합니다.

실무 자동화 3: 정부 지원 사업·입찰 공고 수집

정부 지원 사업·입찰 공고 자동 수집 시스템은 1인 기업·소규모 조직이 매일 확인하기 어려운 각종 공고를 자동으로 수집·평가해 주는 흐름입니다.

• 매일 아침 공고 사이트 자동 크롤링
• 우리 회사와의 적합도 점수 계산
• 마감 기한과 함께 요약 리포트 생성

이 외에도 세금계산서 체크, 고객 팔로업, 각종 반복 행정 업무가 에이전트들에 의해 사람이 자는 동안에도 처리됩니다. 이 흐름 전체에서 보안 훅과 규칙은 “안전망”, 파이프라인은 “작업의 동선” 역할을 합니다.

---

GitHub와 Claude Code로 조직 생산성을 어떻게 측정하나?

GitHub 기반 AI 팀 운영이란 Claude Code 사용 로그와 GitHub 커밋 데이터를 결합해 조직 생산성과 활동을 가시화하는 방식입니다. Claude Code로 수행한 작업이 자동으로 문서화되어 GitHub에 커밋되고, 커밋 빈도·변경 라인·코드 품질 추이 등으로 개인·팀의 업무량을 파악할 수 있습니다.

GitHub를 선택한 이유는 단순합니다. Claude Code가 작업 결과를 파일 단위로 정리·저장하기에 가장 적합한 저장소이기 때문입니다.

직원 관점: 출퇴근·업무 일지가 사라진다

이 구조에서는 직원의 하루 운영 방식이 꽤 많이 달라집니다. “Claude Code를 쓰기 시작한 순간”이 곧 출근 시간이 됩니다. 퇴근 기록을 찍으면 그날 수행한 작업이 자동으로 정리되고, 별도의 업무 일지나 보고서를 쓸 필요가 거의 없어집니다.

조직 전체로 보면 전체 활동 현황, 최근 미팅 로그, 프로젝트 진행 상황, 각자의 업무량이 대시보드에서 실시간으로 보입니다. 비슷한 대시보드를 직접 만들어본 경험으로는, 이 구조가 관리자의 “추측”을 데이터로 대체하는 효과가 꽤 큽니다.

1인 기업도 대기업처럼 운영할 수 있는 이유

이 방식의 가장 흥미로운 지점은 1인 기업도 여러 부서를 가진 조직처럼 운영할 수 있다는 겁니다. CEO 1명이 개발, 리뷰, 비즈니스, 마케팅, 크리에이티브, 리서치, 운영, 투자, 법무, 재무, HR 에이전트를 거느린 형태가 됩니다.

포춘 100대 기업의 약 70%가 이미 Claude Code를 사용하고 있고, 국내 대기업들도 보안 검토를 마치고 도입을 준비 중입니다. 하네스 기반 시스템은 개인과 조직의 생산성 격차를 좌우하는 인프라가 될 가능성이 큽니다.

---

하네스 엔지니어링의 3가지 핵심 원칙은 무엇인가?

하네스 엔지니어링의 3가지 핵심 원칙이란 AI 에이전트 시스템을 설계할 때 반드시 지켜야 할 구조적 규칙 세트입니다. 이 세 가지만 지켜도 솔로 에이전트 대비 신뢰도가 크게 달라집니다.

• 원칙 1: 기획·생성·검증을 분리하라
• 원칙 2: AI가 해서는 안 되는 일을 규칙으로 막아라
• 원칙 3: 피드백 루프를 만들어라

원칙 1: 기획하는 놈·만드는 놈·검증하는 놈을 분리하라

기획(Planning), 생성(Generation), 검증(Evaluation)을 서로 다른 에이전트에게 맡기는 것이 첫 번째 원칙입니다.

한 에이전트가 기획과 생성, 검증까지 모두 하면 자기 편향(Self-Evaluation Bias)이 필연적으로 끼어듭니다. GAN처럼 생성자와 평가자를 완전히 분리하는 것이 품질 보증의 출발점입니다.

“자기가 만든 걸 자기가 평가하면, 반드시 봐야 할 문제를 못 본다.”

플래너–제너레이터–이밸류에이터를 분리하기만 해도 솔로 에이전트 대비 결과물 신뢰도가 체감될 정도로 높아집니다.

원칙 2: AI가 해서는 안 되는 일을 규칙으로 막아라

가드레일(Guardrail)을 규칙과 훅으로 구현하는 것이 두 번째 원칙입니다. AI는 “잘못된 의도”가 아니라 “맥락을 모르는 성실함”으로 민감한 데이터에 접근하거나 잘못된 도구를 씁니다. 그래서 보안 훅으로 민감 데이터 접근을 사전 차단하고, 행동 규칙으로 도구 선택·외부 호출·파일 조작 등 행동 범위를 제한해야 합니다.

단순한 제약이 아닙니다. 실제 사고를 막는 최소한의 안전망입니다.

원칙 3: 피드백 루프를 만들어라

만들고 → 테스트하고 → 수정하고 → 다시 테스트하는 피드백 루프를 구조로 강제하는 것이 세 번째 원칙입니다.

제너레이터가 만든 결과물은 이밸류에이터의 테스트를 통과해야만 “완료”로 인정됩니다. 테스트 실패 → 피드백 → 재생성의 루프가 여러 번 돌면서 품질이 올라갑니다.

“품질은 결국 피드백 루프의 횟수에서 나온다.”

하네스는 이 루프를 규칙과 파이프라인 수준에서 강제합니다. 사람의 의지에 맡겨 두면 놓치기 쉬운 테스트·리뷰 과정을 시스템 차원에서 빠뜨릴 수 없게 만든다는 점이 핵심입니다.

---

자주 묻는 질문 (FAQ)

Q: 하네스 엔지니어링은 프롬프트 엔지니어링과 무엇이 다른가요?

A: 프롬프트 엔지니어링은 단일 모델에 줄 입력 문장을 설계하는 기술입니다. 하네스 엔지니어링은 여러 에이전트, 규칙, 파이프라인, 보안 훅을 포함한 전체 시스템 아키텍처 설계 방법론입니다. 입력 문장의 품질이 아니라 작업 구조와 검증 방식을 다룬다는 점에서 범위가 훨씬 넓습니다.

Q: 솔로 에이전트로도 충분히 쓸 만한 결과가 나올 때가 있는데, 굳이 하네스가 필요한가요?

A: 단순 작업이나 실패해도 리스크가 낮은 작업에는 솔로 에이전트만으로 충분할 수 있습니다. 다만 코드, 법무, 재무, 고객 데이터, 자동 발송처럼 복잡도와 위험도가 있는 작업에서는 한 번의 오류가 치명적입니다. 이때 하네스 구조가 컨텍스트 불안정과 자기 편향을 줄이고, 테스트와 검증을 강제하는 안전장치 역할을 합니다.

Q: 비개발자도 하네스 기반 시스템을 만들 수 있나요?

A: 가능합니다. 하네스의 핵심은 “어떤 일을 어떤 순서로, 어떤 에이전트가 하고, 어디서 검증할 것인가”라는 구조 설계입니다. 실제 코드 작성은 Claude Code 같은 도구에 맡기고, 사람은 에이전트 역할 정의·규칙·보안 훅·파이프라인 순서를 설계하는 데 집중할 수 있습니다. 코드를 모르는 사람들이 이 원리로 회사 업무의 80%를 자동화한 사례도 있습니다.

Q: 하네스를 도입하면 비용이 너무 많이 들지 않나요?

A: 초기에는 솔로 에이전트보다 세션 시간·토큰 사용량·구성 작업 측면에서 비용이 더 듭니다. 하지만 9달러로 만든 앱은 실사용 불가인 반면, 120~200달러를 투입한 하네스 기반 앱은 실제 서비스 수준입니다. 장기적으로는 “실패를 다시 만드는 비용”을 줄여 전체 ROI를 높이는 방향이라고 보는 게 맞습니다.

Q: 모델이 더 좋아지면 하네스도 필요 없어지지 않나요?

A: 모델이 발전할수록 하네스의 보조 장치를 줄이고 구조를 단순화할 수 있습니다. Sonnet 4.5, Opus 4.6에서 컨텍스트 리셋이나 스프린트 구조 일부가 실제로 필요 없어졌습니다. 그래도 “어디까지를 AI에 맡기고, 어디에 규칙과 검증을 둘 것인가”라는 설계 문제는 여전히 남습니다. 하네스는 고정된 템플릿이 아니라 모델에 맞춰 진화하는 설계 사고방식에 가깝습니다.

---

결론

하네스 엔지니어링은 AI가 반복해서 실패하는 지점을 전제로 삼고, 이를 규칙·훅·파이프라인으로 막는 시스템 설계 방법론입니다.

컨텍스트 불안정과 자기 편향이라는 두 가지 근본 문제를 해결하기 위해 플래너–제너레이터–이밸류에이터를 GAN처럼 분리하고, 보안 훅과 행동 규칙으로 AI의 위험한 행동을 구조적으로 차단합니다. 실전 데이터는 솔로 에이전트 9달러로는 실사용 불가한 결과가, 하네스 기반 120~200달러에서는 실제 서비스 수준의 소프트웨어가 나온다는 걸 보여줍니다. 비용만 보면 비싸 보이지만, 품질과 리스크까지 고려하면 완전히 다른 게임입니다.

51개 에이전트·85개 스킬·21개 보안 훅·90개 규칙으로 운영되는 사례에서 보듯, 하네스는 유튜브 콘텐츠, CRM, 정부 지원 사업 수집, 조직 운영, 생산성 측정까지 전 영역에 적용할 수 있습니다. 1인 기업도 여러 부서를 가진 회사처럼 운영할 수 있는 이유가 여기에 있습니다.

포춘 100대 기업의 70%가 이미 Claude Code를 도입한 지금, “하네스 구조를 이해하고 실제로 구현할 수 있는가”가 개인과 조직의 생산성 격차를 결정하게 될 겁니다. 지금 당장 할 수 있는 가장 현실적인 첫걸음은, 작은 업무 하나부터라도 기획–생성–검증을 분리하고 최소한의 보안 훅과 규칙을 붙여보는 것입니다.

---

참고할 만한 공식 자료

• Anthropic 공식 엔지니어링 블로그: 하네스 및 에이전트 관련 글
  https://www.anthropic.com/news
• Claude 모델 카드 및 안전성 문서
  https://www.anthropic.com/claude
• OpenAI 시스템 카드 및 안전성 연구
  https://openai.com/safety
• Playwright 공식 문서 (브라우저 자동화)
  https://playwright.dev
• Supabase 공식 문서 (Postgres 기반 백엔드)
  https://supabase.com/docs
• GitHub Docs (자동화·워크플로 관리)
  https://docs.github.com