AI 모델 자체가 아니라, 모델을 감싸는 구조를 설계하는 규율. 같은 모델이라도 주변 하네스를 어떻게 짜느냐에 따라 결과물 품질이 크게 달라진다.

하네스 엔지니어링이란

AI 에이전트에게 일을 시켜 보면, 같은 모델인데도 어떤 프로젝트에서는 잘 되고 어떤 프로젝트에서는 엉망인 경우가 있다. 차이는 모델이 아니라 모델 주위의 구조 — 어떤 맥락을 주는지, 어떤 도구를 쓸 수 있게 하는지, 에러가 나면 어떻게 복구하는지 — 에서 갈린다. 이 "감싸는 구조"를 체계적으로 설계하는 게 하네스 엔지니어링이다.

사용 예시

Claude Code에서 하네스 엔지니어링은 이미 일상적으로 쓰이고 있다. CLAUDE.md에 프로젝트 규칙과 코딩 컨벤션을 적어 두면 에이전트가 매 세션마다 그 맥락을 읽고 시작한다. 훅으로 파일 수정 후 자동 린트를 걸거나, 위험한 명령을 차단하는 가드레일을 만든다. 스킬로 반복 워크플로우를 정의하고, MCP로 외부 도구 접근 범위를 통제한다. 이 모든 게 모델을 감싸는 하네스의 구성 요소다.

직접 에이전트를 만들 때도 마찬가지다. 시스템 프롬프트로 역할과 제약을 잡고, 도구 정의로 에이전트가 할 수 있는 일의 범위를 정하고, 출력 검증 루프로 잘못된 결과를 걸러내는 구조를 짠다. 모델을 바꾸지 않고도 이 구조만 다시 설계하면 성능이 눈에 띄게 올라가는 경우가 많다.

주의할 점

하네스를 너무 빡빡하게 짜면 에이전트가 유연하게 대응하지 못하고, 너무 느슨하면 엉뚱한 방향으로 간다. 처음에는 최소한의 제약만 걸고, 실제로 문제가 생기는 지점에 하나씩 가드레일을 추가하는 방식이 실용적이다.