하네스 엔지니어링 — 프롬프트가 아니라 구조로 멱등성을 만든다

핵심 통찰

프롬프트만으로는 멱등성(Idempotency)이 불가능하다.

프롬프트는 요청(request)이다 — 모델이 따를 수도, 안 따를 수도 있다.
하네스는 구조(structure)이다 — 모델이 그 안에서만 동작한다.

프롬프트 엔지니어링:  "이렇게 해줘" 라고 매번 말로 지시
하네스 엔지니어링:    "이렇게 할 수밖에 없는 환경" 을 만들어 놓음

Agent = Model + Harness

Anatomy of an Agent Harness(Vivek Trivedy)의 정의:

"모델이 아닌 모든 것이 하네스다 (If you're not the model, you're the harness)"

Model은 Anthropic이 만들지만, Harness는 사용자가 만든다. 같은 모델이라도 하네스에 따라 전혀 다른 에이전트가 된다. Terminal Bench 2.0에서 같은 Opus 4.6이 하네스에 따라 Top 30에서 Top 5로 차이가 나는 것이 이를 증명한다.

멱등성의 본질

DIO(스페이스 Y)는 Claude, Codex, Gemini 3개 모델에 같은 요구사항을 넣어 같은 결과를 얻었다. 린터 + 디자인 시스템 + 네이밍 규칙이 모델의 선택지를 하나로 좁혔기 때문이다.

그런데 이것은 반드시 여러 모델이 필요한 이야기가 아니다. 모델 하나로도 충분히 구현 가능하다. 핵심은 모델 독립성이 아니라, 같은 입력 → 같은 출력을 보장하는 구조적 장치의 존재다. 단일 모델이라도 프롬프트만으로 지시하면 매번 다른 결과가 나온다. 하네스가 있으면 매번 같은 결과가 나온다.

하네스의 구성

하네스 = 프롬프트로 매번 말하던 것을 코드/설정/스크립트/규칙으로 굳혀서, 반복 가능하고 일관된 결과를 보장하는 시스템.

이 모든 것의 공통점: 프롬프트가 아니라 코드로 되어 있어서, 매번 말하지 않아도 동작한다.

세 가지 관점의 스펙트럼

세 관점 모두 같은 본질을 말한다: AI의 선택지를 좁히는 구조적 장치를 만들어라.