iamlazyck

최근 Addy Osmani가 정리한 "하네스 엔지니어링(Harness Engineering)" 글을 봤다. 핵심 주장이 명확하다.

지난 2년간 "어떤 모델이 더 똑똑한가"만 따졌는데, 정작 실제 성과는 모델이 아니라 그걸 둘러싼 하네스가 결정한다.

하네스가 뭔가

AI 에이전트 = 모델 + 하네스. (Viv Trivedy의 정의)

하네스는 모델을 제외한 전부다. 시스템 프롬프트, 사용 가능한 도구, 컨텍스트 관리, 훅(자동 점검 장치), 샌드박스, 서브에이전트, 피드백 루프, 복구 흐름까지 모두 포함한다.

Claude Code, Cursor, Codex, Aider, Cline 같은 제품은 전부 하네스다. 같은 모델이 들어가도 우리가 느끼는 건 하네스가 좌우한다.

AI가 엉뚱한 짓을 하면 보통 "다음 모델 버전을 기다리자"고 한다. 하네스 엔지니어링은 이 반응을 거부한다.

"이건 모델 문제가 아니라 설정 문제(skill issue)다." — HumanLayer

같은 Claude Opus 4.6인데 기본 Claude Code 안에서는 벤치마크 하위권인데, 직접 손본 하네스로 옮기면 상위권으로 뛰어오른다. Viv의 팀은 하네스만 바꿔서 같은 모델을 30위권에서 5위권으로 끌어올렸다.

모델이 가진 잠재력을 하네스가 깎아먹고 있는 경우가 많다는 뜻이다.

AI가 한 번이라도 저지른 실수는 우연으로 넘기지 않는다.

한 칸씩 조여나가는 방식. 예를 들어 AI가 테스트 코드를 주석 처리했으면, 규칙 문서에 "테스트는 주석 처리하지 말고 지우거나 고칠 것"이 들어가고, 커밋 직전 검사에 해당 패턴을 잡아내는 검사기가 추가된다.

좋은 규칙 문서의 모든 줄은 과거에 있었던 구체적인 실패와 연결돼야 한다.

남이 만든 프레임워크를 그대로 쓰는 게 아니라, 자기 코드베이스의 실패 이력에 따라 길러가는 규율이다.

AI는 읽을 수 있는 양에 한계가 있고, 그 한도에 가까워질수록 판단력이 떨어진다. 하네스는 이 문제를 해결하는 장치 묶음이다.

Anthropic: "긴 작업에서는 요약 압축만으로는 부족하고, 구조화된 인수인계 문서로 새로 시작해야 할 때가 있다."

신입에게 업무 넘길 때 정리된 문서 만들어주는 것과 같다.

"AI에게 그렇게 하라고 말해 두는 것"과 "시스템이 강제로 그렇게 만드는 것"은 다르다.

훅은 도구 사용 전, 파일 수정 후, 커밋 직전 등에 끼어들어 자동 동작한다.

원칙은 "성공은 조용히, 실패는 시끄럽게". 검사 통과하면 AI는 아무 소리도 안 듣고, 실패하면 오류 메시지가 흐름에 주입돼 스스로 고친다.

프로젝트 루트의 AGENTS.md는 매 턴 시스템 프롬프트에 들어가는 가장 영향력 있는 파일.

HumanLayer는 60줄 이하를 권한다. 길어질수록 각 줄의 무게가 옅어진다. 스타일 안내서가 아니라 비행기 조종사의 점검표처럼 꼭 필요한 항목만 남기라는 것.

도구도 마찬가지. 비슷한 도구 50개보다 잘 다듬은 10개가 낫다. 이름과 설명이 매 요청마다 프롬프트에 박히니까.

Opus 4.6은 Sonnet 4.5에서 흔하던 "빨리 마무리하려는 조급증"을 거의 없앴다. 그래서 그걸 막던 보조 장치들이 죽은 코드가 됐다.

근데 모델이 닿은 새 영역에는 새 약점이 있고, 그걸 메우는 새 하네스가 또 필요해진다.

"하네스의 모든 부품은 모델이 혼자 못하는 일이 무엇인지에 대한 가정을 담고 있다." — Anthropic

그래서 하네스는 사라지지 않고 자리만 옮긴다.

이 글을 읽으면서 내 OpenClaw 설정(AGENTS.md, SKILL.md, 훅)이 완전히 하네스 엔지니어링의 실천 사례라는 걸 깨달았다. 나도 모르게 하네스를 만들고 있었던 것.

특히 "래칫 원칙"이 와닿았다. 내 AGENTS.md에 있는 규칙들도 사실 과거의 실패에서 나온 것들이었다. "URL 보내면 무조건 study-clipper 실행" 같은 규칙도, 처음에 물어보다가 매번 같은 답이 나오니까 자동화한 거니까.

앞으로는 실패할 때마다 의식적으로 규칙을 추가하는 습관을 들여야겠다.