하네스 엔지니어링 공부 정리 | 에이전트보다 환경이 어렵다

pxd Story 블로그에서 “하네스 엔지니어링”이라는 개념을 다룬 글을 읽었다. 처음엔 낯선 단어였는데, 읽어보니 AI 에이전트를 다루는 방식에 대한 꽤 다른 관점이었다.

“AI 에이전트가 코드를 엉망으로 짠다”는 문제의 해결책으로 더 좋은 모델을 먼저 떠올리기 쉬운데, 이 글은 그 방향이 아니었다. “어려운 건 AI 에이전트 자체가 아니라 에이전트가 일할 환경(harness)”이라는 것. 이 지점이 흥미로워서 공부해봤다.

1️⃣ 이게 뭐냐?

하네스 엔지니어링은 AI 에이전트 자체가 아니라 에이전트가 일하는 환경과 제약을 설계하는 분야에 가깝다. 글에 나오는 비유가 “말에게 씌우는 마구(馬具)”인데, 아무리 강한 말도 고삐 없이는 방향을 잡기 어렵다는 얘기였다. AI 에이전트도 마찬가지라는 논리.

글에서는 3가지 핵심 기둥을 이야기했다.

첫 번째는 컨텍스트 엔지니어링이다. 에이전트가 규칙을 추측하지 않고 직접 읽을 수 있도록, 아키텍처 규칙이나 코딩 컨벤션을 AGENTS.md 같은 파일에 구조화해두는 것. “사람에게 온보딩 문서를 주듯, 에이전트에게도 입사 첫날 읽어야 할 문서를 준다”는 표현이 인상에 남았다.

두 번째는 아키텍처 제약이다. 규칙을 “부탁”이 아니라 “강제”로 만드는 것. 프롬프트에 “코딩 컨벤션 지켜줘”라고 쓰는 건 부탁이지만, 위반하면 빌드가 실패하도록 설계하는 건 강제다. 린터나 pre-commit 훅이 그 역할을 맡는다.

세 번째는 엔트로피 관리다. 시간이 지나면서 쌓이는 중복 코드나 스타일 불일치를 정리 에이전트가 주기적으로 탐지하고 복구하는 것이다.

2️⃣ 내가 든 생각

이 개념에서 흥미로웠던 건, 에이전트를 개선하는 게 아니라는 점이었다. 에이전트를 믿되, 그 믿음은 환경이 뒷받침될 때만 유효하다는 논리가 깔려 있다.

디자이너로서 이게 낯설지 않았던 이유가 있었다. 디자인 시스템도 결국 비슷한 구조 아닐까 싶어서다. 좋은 컴포넌트를 만드는 게 목표라기보다, 누가 쓰든 틀리기 어려운 환경을 만드는 일에 가깝다. 에이전트에게 제약을 주는 것과 디자이너에게 가이드라인을 주는 것이 구조적으로 꽤 닮아 있다는 생각이 들었다.

👉🏻 글에서 프롬프트 엔지니어링과 하네스 엔지니어링을 대비시키는 부분이 핵심이었다. 프롬프트는 “부탁”이고 하네스는 “강제”다. 개인 스킬에 기대는 방식에서 시스템 전체에 적용되는 환경 설계 쪽으로 넘어가는 관점이랄까.

💡 여기서 드는 질문 CLAUDE.md나 AGENTS.md 같은 파일이 이 “컨텍스트 엔지니어링”의 실제 구현이라면, 이 파일을 어떻게 쓰느냐 자체가 이미 하네스 설계의 일부인 걸까?

문서로만 공부한 입장에서는, 이 질문이 꽤 현실적으로 다가왔다. 에이전트 환경을 직접 구축하는 게 아니더라도, 컨텍스트 파일 설계가 결과물의 일관성에 영향을 준다는 건 이미 감지되는 부분이라서.

⭐️ 마지막으로, 프론트 공부하는 디자이너 입장에서 느낀 점

정리해보니 하네스 엔지니어링은 에이전트를 더 잘 쓰는 개인 스킬보다, 에이전트가 일하는 판을 잘 짜는 구조 문제에 가까운 일이었다. 공부 끝에 남은 건 “모델보다 환경이 먼저”라는 한 줄짜리 인상이다.

---

참고 원문: 하네스 엔지니어링