앤트로픽이 공식 엔지니어링 블로그에 흥미로운 글을 올렸다.
AI가 혼자 코드를 짜고, 다른 AI가 그걸 테스트하고, 기준 미달이면 돌려보내는 구조. 사람은 방향을 잡고 최종 결과를 승인한다.
하네스(Harness)라고 부른다. 한마디로 말하면, AI가 혼자 일하면 실수한다. 그래서 AI끼리 견제하게 만든 구조다.
말에 채우는 마구
하네스는 원래 말에 채우는 마구를 뜻한다. AI에게 채우는 마구라고 생각하면 된다.
AI에게 "앱 만들어줘"라고 하면 알아서 뭔가를 만든다. 근데 혼자 하다 보면 길을 잃는다. 다 됐다고 착각한다. 버그를 못 잡는다. 잡았는데 다른 데를 망가뜨린다.
이걸 막기 위해 역할을 나누고, 서로 견제하게 만든 구조가 하네스다.
세 명이 일한다. 전부 같은 클로드다.
앤트로픽이 공식 블로그에서 공개한 구조다. 3개의 역할이 있다.
Planner (기획자)
사용자의 요청을 받아서 구체적인 작업 목록으로 쪼갠다. "채팅 앱 만들어줘" 한 마디를 200개 이상의 세부 항목으로 분해한다.
"새 채팅 버튼을 누르면 새 대화가 생성된다", "메시지 입력 후 엔터를 치면 AI 응답이 표시된다" 같은 식으로. 모든 항목은 처음에 "미완료" 상태로 시작한다.
Generator (생성자)
Planner가 만든 목록에서 하나씩 꺼내서 실제 코드로 구현한다. 핵심 규칙이 있다. 한 번에 하나만. 구현하고 나서 직접 브라우저를 열어 테스트한다. 통과했을 때만 "완료"로 바꾸고 다음으로 넘어간다.
Evaluator (평가자)
Generator가 만든 것을 독립적으로 검증한다. 코드를 보는 게 아니라 실제 실행 중인 앱에 접속해서 버튼을 클릭하고, API를 호출하고, 화면이 제대로 나오는지 직접 확인한다. 기준 미달이면 Generator에게 다시 돌려보낸다. 구체적인 이유와 함께.
세 명 다 같은 클로드다. 역할만 다르다. 각자 다른 지시문을 받았을 뿐이다.
왜 Evaluator를 따로 뒀는가
여기가 핵심이다.
앤트로픽이 실험을 해봤다. AI에게 자기가 만든 것을 평가하라고 했더니, 품질이 명백히 떨어져도 칭찬했다.
사람이랑 똑같다.
그래서 만드는 쪽과 평가하는 쪽을 완전히 분리했다. Evaluator는 Generator의 코드를 본 적이 없다. 오직 실행 결과만 보고 판단한다. 이게 GAN(생성적 적대 신경망)에서 영감받은 구조다.
생성자: 평가자를 만족시키려 한다
평가자: 결함을 찾으려 한다
서로 적대적으로 경쟁하면서 품질이 올라간다.
앤트로픽이 실제로 잡아낸 버그들:
- 사각형 채우기 도구로 드래그했더니 시작점과 끝점만 채워지고 중간이 비었다
- API 라우트 순서 버그로 422 에러가 났다
- 삭제 핸들러 조건문이 잘못됐다
Generator 혼자 테스트했으면 발견하지 못했을 것들이다.
각자의 지시서 — MD 파일 구조
각 에이전트는 자기만의 지시 파일을 가진다.
CLAUDE.md는 프로젝트 전체 맥락을 담는다. 기술 스택, 코딩 규칙, 아키텍처 결정 사항. 마스터 프롬프트다.
각 역할별 MD 파일에는 해당 에이전트가 어떻게 판단하고 행동해야 하는지가 담긴다. planner.md, generator.md, evaluator.md. 그리고 feature_list.json에 기능 목록과 완료 여부가 기록된다.
중요한 사실 하나. 이 세 에이전트는 서로 다른 모델이 아니다. 전부 같은 클로드다.
같은 클로드 + 다른 지시문 = 다른 역할. 모델을 바꾸는 게 아니라 역할을 나누는 것이다.
비용은 22배. 차이는 "작동"과 "고장" 사이.
앤트로픽이 같은 과제(레트로 게임 메이커 제작)로 비교한 결과다.
| 하네스 없이 | 하네스 적용 | |
|---|---|---|
| 시간 | 20분 | 6시간 |
| 비용 | $9 | $200 |
| 결과 | 핵심 기능 고장 | 실제 플레이 가능 |
$9짜리는 빠르다. 근데 안 된다. $200짜리는 느리다. 근데 된다.
비용이 22배 들었다. 하지만 "작동하는 제품"과 "작동하지 않는 제품"의 차이다.
모델이 똑똑해지면 구조는 단순해진다
앤트로픽이 Opus 4.6으로 업그레이드하자 흥미로운 일이 일어났다. 기획자의 역할이 줄었다. 모델이 혼자서도 일관되게 작업할 수 있게 됐기 때문이다.
하지만 평가자는 사라지지 않았다.
모델이 아무리 좋아져도, 자기가 만든 것을 객관적으로 보는 건 여전히 못한다. 사람도 마찬가지다.
앤트로픽이 내린 결론이 있다. "하네스의 모든 구성요소는 '모델이 혼자서는 못 하는 것'에 대한 가정을 담고 있다. 모델이 발전하면 그 가정을 다시 테스트해야 한다." 하네스는 영구적인 구조가 아니다. 모델과 함께 진화한다.
AI는 자기가 만든 것을 칭찬한다. 그래서 다른 AI가 검증해야 한다.
이게 바이브코딩과 무슨 상관인가
지금 대부분의 바이브코더는 AI 하나와 대화한다. 만들어달라고 하고, 고쳐달라고 하고, 또 만들어달라고 한다.
하네스는 그 다음 단계다. AI를 하나가 아니라 팀으로 쓰는 것. 기획하는 AI, 만드는 AI, 검증하는 AI.
아직은 설정이 복잡하다. 하지만 방향은 명확하다. 바이브코딩은 "AI에게 시키는 것"에서 "AI 팀을 운영하는 것"으로 진화하고 있다.
만드는 법을 모르는 건 더 이상 문제가 아니다. 관리하는 법을 아는 게 다음 문제다.