지금 팀에서 일어나고 있는 일
에이전트가 코드를 짜고, 테스트를 생성하고, PR까지 올리는 시대가 됐다. 그런데 이상하게도 팀의 '신뢰도'는 오히려 떨어지고 있다. 테스트 커버리지 숫자는 올라가는데 "이거 믿어도 되나?"라는 물음이 사라지지 않는다. AI가 만든 Playwright 스크립트는 읽기 어렵고, 유지보수는 더 어렵다. 에이전트가 패키지 설치하다 엉뚱한 파일을 건드리고, 누가 언제 어떤 권한으로 무엇을 실행했는지 추적이 안 된다.
이 문제들은 모델이 부족해서 생기는 게 아니다. 하네스가 없거나, 있어도 잘못 설계되어 있어서 생긴다.
패러다임 전환의 실체: 프롬프트 → 컨텍스트 → 하네스
GeekNews에 소개된 4년의 기록은 이 변화를 세 시대로 정리한다. 2022~2024년의 프롬프트 엔지니어링 시대에는 "단계별로 생각하라"는 주문이 전부였다. 그런데 아무리 정교한 프롬프트도 컨텍스트 윈도우 밖의 파일은 모른다는 한계에 부딪혔다. 2025년 컨텍스트 엔지니어링이 등장하면서 "어떤 말을 해야 하나"에서 "어떤 정보를 넣어야 하나"로 무게중심이 이동했다. 하지만 완벽한 컨텍스트를 구성해도, 그걸 소비하는 루프 자체가 잘못 설계되면 여전히 실패했다.
2026년 현재의 화두는 하네스 엔지니어링이다. 핵심 명제는 단순하다: "에이전트가 실수하면 에이전트가 아니라 하네스를 고쳐라." 주목할 점은 이 전환이 이전 시대를 대체하지 않는다는 것이다. 프롬프트 엔지니어링은 죽은 게 아니라 하네스의 서브모듈이 됐고, 컨텍스트 설계는 하네스가 에이전트에게 무엇을 보여줄지 결정하는 레이어로 흡수됐다.
Claude Code의 확장 시스템이 하네스를 어떻게 구현하는가
dev.to에 게재된 Claude Code 확장 아키텍처 분석은 이 하네스 개념을 가장 구체적으로 구현한 사례를 보여준다. 핵심 설계 원칙은 계층형 신뢰(layered trust)와 fail-closed 기본값이다.
확장 시스템을 하나로 통일하지 않고 네 가지로 분리한 이유가 여기에 있다. 팀 컨벤션 같은 수동 지시문은 텍스트로만 주입된다—실행 권한이 없으니 샌드박스도 필요 없다. 파일 저장 후 린터를 돌리는 훅은 워크스페이스 신뢰 확인 후에만 실행된다. 리서치를 위임받은 서브 에이전트는 격리된 대화와 스코프가 제한된 툴 접근만 갖는다. 외부 MCP 서버는 별도 프로세스에서 네임스페이스 통제 하에 돈다.
특히 훅(Hooks) 시스템의 설계 배경이 흥미롭다. 초기 개발 과정에서 .claude/settings.json이 사용자가 워크스페이스 신뢰를 거부했을 때도 SessionEnd 훅을 실행하는 취약점이 발견됐다. "신뢰하지 않겠다"고 했는데 그 프로젝트의 코드가 실행되는 상황이다. 이 사건 하나가 "모든 훅은 워크스페이스 신뢰 확인 없이 실행되지 않는다"는 강제 규칙을 만들었다. 하네스 설계에서 보안은 나중에 붙이는 게 아니라 아키텍처에 박혀 있어야 한다는 교훈이다.
에이전트 결과물을 어떻게 검증할 것인가
하네스 설계의 다른 축은 검증이다. 에이전트가 아무리 잘 작동해도 그 결과물을 믿을 수 없으면 의미가 없다.
Shiplight의 1년 실전 경험이 여기서 의미 있는 신호를 준다. "AI 에이전트가 테스트 스크립트를 빠르게 생성하지만, 결과물은 리뷰하기 어렵고 유지보수 비용이 크다. 테스트 볼륨은 늘어나는데 신뢰도는 늘지 않는다." 정확히 많은 팀이 겪는 문제다.
이들이 찾은 해법은 두 가지 방향의 전환이다. 첫째, 테스트 포맷을 코드가 아닌 자연어 YAML로 바꿨다. Playwright 스크립트 대신 intent: Enter email address처럼 의도를 서술한다. 같은 기능을 기획한 PM이 코드를 모르고도 리뷰할 수 있다. PR 리뷰가 가능해지고, diff가 명확해진다. 둘째, 검증 시점을 배포 후에서 개발 중으로 당겼다. MCP 서버를 통해 AI 에이전트가 코드를 수정하는 즉시 실제 브라우저에서 UI를 검증한다. 코드 리뷰 전에 버그를 잡는다.
자가 치유(self-healing) 메커니즘도 하네스 설계 관점에서 읽으면 더 명확하다. UI가 바뀌어도 의도(intent)가 동일하면 테스트가 살아남는다. 에이전트가 실수했을 때 테스트를 다 고치는 게 아니라 하네스(테스트 실행 레이어)가 스스로 복구한다.
지금 팀에서 당장 적용할 수 있는 것
이 세 가지 관점을 하나로 엮으면 실행 가능한 원칙이 나온다.
첫째, 신뢰 경계를 명시적으로 설계하라. CLAUDE.md로 컨벤션을 관리하고, 훅으로 린터·포매터를 강제하고, MCP로 외부 도구를 연결하는 세 레이어를 혼용하지 말 것. 각 레이어가 어디까지 신뢰받는지 팀 내에서 명시적으로 합의해야 한다. 암묵적 신뢰가 공격 반경이 된다.
둘째, 테스트를 코드가 아닌 스펙으로 작성하라. AI가 생성한 Playwright 스크립트를 그대로 레포에 커밋하는 건 기술 부채를 적립하는 것이다. 의도 기반 자연어 포맷으로 전환하면 AI 생성 테스트도 사람이 리뷰할 수 있는 수준이 된다.
셋째, 하네스는 뜯어낼 수 있게 만들어라. 모델이 발전하면 기존 에러 복구 로직의 절반이 불필요해진다. 특정 모델의 약점을 보완하기 위해 만든 워크어라운드가 새 모델에서 오히려 독이 되는 경우가 생긴다. 하네스 컴포넌트는 교체 가능한 단위로 분리해 두는 것이 원칙이다.
다음 이동 방향
하네스 엔지니어링 시대의 핵심 메트릭은 프롬프트 품질이 아니라 KV-cache hit rate와 하네스 복잡도로 이미 이동했다. 다음 전선은 세 곳이다. 에이전트가 실시간으로 스스로를 감시하는 Guardian Agent 레이어, 벤치마크가 아닌 실제 행동으로 에이전트를 평가하는 평가 엔지니어링, 그리고 코드 그래프·커밋 히스토리·메모리를 결합한 지식 엔진이다.
솔직히 말하면, 지금 대부분의 팀은 아직 컨텍스트 엔지니어링과 하네스 엔지니어링 사이 어딘가에 있다. 도구 선택보다 중요한 건 "에이전트가 실수했을 때 어디를 고칠 것인가"를 팀 전체가 알고 있느냐다. 그 답이 항상 프롬프트를 수정하는 것이라면, 아직 하네스 설계를 시작하지 않은 것이다.