하네스 엔지니어링에 대한 오해

최근 하네스 엔지니어링에 대한 관심이 높아지면서 유튜브나 블로그에서 관련된 내용들을 많이 접하게 된다. 하네스 엔지니어링이 개념적이고, 그 실체를 제각각 다르게 받아들이다 보니 혼란스러운 부분이 있는 것 같다.

내가 이해하고 있는 하네스 엔지니어링은 AI를 가두기보다는 AI 에이전트들이 협업할 수 있는 구조를 설계하는 데 초점을 맞춘다. 그리고 그 에이전트들의 기능을 확장할 수 있도록 에이전트만을 위한 스킬을 제공하는 것을 목표로 한다.

최근 잘 읽은 글이 하나 있었다. 다만 세 가지 오해는 바로잡고 싶었다.

1. “하네스 = 테스트 감옥”이라는 오해

하네스의 본래 뜻은 “마구”, 즉 말을 조종하는 도구다. AI를 가두는 것이 아니라 방향을 잡아주는 것이다. 테스트 하네스는 그 수단 중 하나일 뿐이다.

2. “토큰 낭비”라는 오해

지적된 토큰 낭비는 “Mock + 테스트 전체를 매번 로드”하는 방식의 문제다. 하네스 엔지니어링은 오히려 Progressive Disclosure(필요한 정보만 단계적 로딩)로 토큰 효율을 높이는 것을 핵심 원칙으로 삼는다. 여러 에이전트가 동시다발적으로 서로 협력하며 동작하기 때문에 기존보다 더 빠르게 소진되는 것일 뿐, 견고하게 설계된 하네스는 토큰을 낭비하지 않는다.

3. “설계 부재”라는 오해

하네스를 구성해주는 메타 스킬의 경우, Phase 1~2가 바로 도메인 분석과 아키텍처 설계다. 테스트부터 시작하는 것이 아니라 설계부터 시작한다. 나는 사용자의 요청에 따라 도메인을 이해하고, 그 도메인을 가장 잘 이해하는 에이전트와 관련된 스킬을 만들고, 어떻게 작업을 할지 설계하는 것을 목표로 한다.

어디서 갈라졌을까

아마도 하네스와 함께 언급되고 있는 “테스트 주도 반복 루프”라는 좁은 기법을 하네스 엔지니어링 전체와 동일시한 데서 비롯된 오해가 아닐까 생각한다. 그리고 아이러니하게도, 대안으로 제시된 문서 기반 워크플로우는 내가 이해하는 하네스 엔지니어링의 철학과 상당 부분 일치한다.

• CLAUDE.md로 컨텍스트를 앵커링 → 하네스의 에이전트 정의와 동일한 목적
• 문서 순서대로 복기 → 파이프라인 패턴의 데이터 흐름
• 설계 문서로 AI의 판단 일관성 유지 → 스킬의 Progressive Disclosure

Mock 데이터와 테스트 케이스를 촘촘히 짜놓고 AI에게 “통과할 때까지 무한 반복하라”고 시키는 패턴은 테스트를 목적으로 하는 한 가지 기법일 뿐, 하네스 엔지니어링 전체가 아니다.