하네스 엔지니어링 활용편 — 내 프로젝트에 당장 적용하는 법
개념을 이해했고(3편), Anthropic의 구현을 살펴봤다(4편). 이제 남은 질문은 하나다. 내 프로젝트에 어떻게 적용하는가? 이 글에서는 하네스 엔지니어링을 실무에 활용하는 구체적인 방법과, 이 패러다임이 가져올 개발자 역할의 변화를 다룬다. 원칙 1: 실패에서 시작하라 Mitchell Hashimoto의 원칙이자, HumanLayer 팀이 독립적으로 같은 결론에 도달한 것. 이상적인 하네스를 미리 설계하려 하지 마라. 에이전트가 실패할 때마다, 그 실패를 구조적으로 방지하는 장치를 추가하라. HumanLayer 팀의 표현: "출하 편향을 가져라. 에이전트가 실제로 실패한 경우에만 하네스를 건드려라." 이것은 TDD(Test-Driven Development)의 사고방식과 닮아 있다. 실패하는 테스트를 먼저 만들고, 그것을 통과시키는 코드를 작성하는 것처럼 — 에이전트가 실패하는 패턴을 관찰하고, 그것을 방지하는 하네스 요소를 추가한다. ETH Zurich의 연구가 이 원칙을 뒷받침한다. 138개 에이전트 설정 파일을 테스트한 결과: LLM이 생성한 설정 파일: 성능 저하 + 비용 20% 이상 증가 사람이 작성한 설정 파일: 겨우 4% 개선 코드베이스 개요, 디렉터리 목록: 아무 도움도 안 됨 에이전트는 저장소 구조를 스스로 충분히 탐색한다. 핵심은 보편적으로 적용되는 최소한의 지침만 투입하는 것이다. 원칙 2: 적게 넣어라 하네스 엔지니어링에서 가장 반직관적인 원칙이다. 더 많은 규칙, 더 많은 도구, 더 많은 에이전트가 항상 더 나은 결과를 만들지 않는다. Vercel의 사례: 초기에 모든 도구를 제공했지만, 도구를 줄이자 오히려 성능이 향상됐다. MCP 서버를 많이 연결하면? 도구 정의 자체가 시스템 프롬프트의 토큰을 소비한다. 200K 컨텍스트 윈도우가 MCP 도구가 너무 많으면 실제로는 70K밖에 안 될 수 있다. HumanLayer의 해결책: Linear MCP 서버 대신 핵심 기능만 감싼 경량 CLI...