Claude Code를 도입한 팀이 한 달 안에 두 갈래로 나뉜다. 한 쪽은 "AI가 생각보다 별로"라며 사용 빈도를 줄이고, 다른 쪽은 에이전트를 실제 개발 파이프라인에 엮어 속도를 올린다. 차이는 모델 품질이 아니다. 도구 주변에 무엇을 설계했느냐다.
최근 세 가지 흐름이 같은 질문을 다른 각도에서 겨냥하고 있다. Claude Code 도구 호출 거버넌스, 엔지니어링 표준 기반 AI 오케스트레이션, 하네스 설계를 통한 에이전트 정확도 개선. 각각은 독립적인 기술 주제처럼 보이지만, 묶어서 읽으면 하나의 메시지가 나온다. 도구 도입보다 도구 운용 설계가 훨씬 어렵고, 훨씬 중요하다.
1. 거버넌스 레이어: 에이전트가 실행하기 전에 멈추는 지점을 만들어라
에이전트가 결정한 것과 에이전트가 실행한 것 사이에는 틈이 있다. 그 틈이 거버넌스가 살아야 할 자리다. dev.to에 공개된 SidClaw의 Claude Code 후크 구현 사례는 이 틈을 구체적으로 설계하는 방법을 보여준다.
핵심 메커니즘은 PreToolUse 후크다. Claude Code가 도구를 호출하기 직전에 정책 평가 레이어를 삽입해, allow / approval_required / deny 세 가지 경로 중 하나로 분기시킨다. Bash의 rm -rf, .env 파일 편집, /etc/ 경로 쓰기, 50개 파일 이상 멀티에디트 같은 고위험 액션은 사람이 승인하거나 거부할 때까지 실행이 보류된다. 결정 하나하나는 SHA-256 해시 체인으로 봉인된 감사 로그에 남는다.
팀 리드 관점에서 이 설계가 실질적인 이유는 두 가지다. 첫째, 에이전트 실수의 복구 비용이 비대칭적이다. 스테이징 DB를 날리거나 잘못된 배포 브랜치에 force push하는 사고는 몇 분 만에 일어나지만 복구는 몇 시간이다. 사전 인터셉션은 이 비대칭을 구조적으로 해소한다. 둘째, 컴플라이언스 요건이 현실화되고 있다. FINRA 2026 Rule 3110, EU AI Act Article 14, SOC 2 CC7.2 등 AI 액션에 대한 인간 체크포인트를 요구하는 규제들이 구체적인 시행 일정을 갖기 시작했다. 감사 체인은 나중에 붙이는 게 아니라 처음부터 설계해야 하는 인프라다.
한 가지 냉정하게 짚을 점: 이 후크는 에이전트가 무엇을 실행할지는 통제하지만, 무엇을 생각했는지는 통제하지 않는다. 프롬프트 필터링이나 모델 응답 검열이 필요하다면 별도 레이어가 필요하다. 거버넌스 후크는 실행 레이어의 안전망이지, 전체 에이전트 런타임의 대체물이 아니다.
2. 오케스트레이션 레이어: AI에게 답을 구하지 말고 시스템을 먹여라
"AI를 구글처럼 쓴다"는 표현이 정확히 맞는다. 질문을 던지고, 결과를 받고, 수정하고, 다시 던진다. 이 패턴은 선형으로 스케일한다. 프롬프트 하나에 결과물 하나, 편집 하나. 개인 생산성은 조금 오를 수 있지만 팀 레벨의 레버리지는 생기지 않는다.
dev.to에 공개된 Jono Herrington의 사례는 다른 전환점을 보여준다. Copilot이 스타일 가이드를 무시하고 변수명을 R, T로 짓고, 이미 추상화된 로직을 세 번 복붙하는 상황에서, 그는 재프롬프팅 대신 AI가 참조하는 소스 자체를 바꿨다. 엔지니어링 표준을 마크다운 파일로 인코딩하고, 요구사항 작성 방식, 트레이드오프 판단 기준, "클린"의 정의, 추상화 vs 중복 선택 기준을 AI가 읽을 수 있는 형태로 만들었다.
결과는 달랐다. 에이전트가 즉흥적으로 코드를 생성하는 게 아니라, 팀이 이미 정의한 패턴을 실행하기 시작했다. 이게 오케스트레이션과 단순 프롬프팅의 차이다. 전자는 시스템을 정의하고 에이전트를 그 위에서 실행시킨다. 후자는 매번 에이전트를 설득하려 한다.
이 사례에서 주목할 패턴이 있다. 아키텍트와 시니어 엔지니어들이 AI 도구를 더 깊이, 더 빠르게 흡수하는 이유가 "더 기술적이어서"가 아니라는 것이다. 이들은 이미 시스템 단위로 사고하는 데 익숙하다. 패턴을 정의하고, 제약을 인코딩하고, 시스템이 실행하게 두는 방식이 낯설지 않다. 반대로 AI 도구와 씨름하는 미드레벨 엔지니어들은 대부분 더 나은 프롬프트를 찾고 있다. 재프롬프팅이 아니라 재아키텍팅이 필요한 순간을 구분하는 능력, 이게 AI-First 팀에서 실질적으로 차별화되는 역량이다.
3. 하네스 레이어: 모델을 바꾸기 전에 환경을 먼저 바꿔라
92%의 개발자가 AI 코딩 도구를 매일 쓰는데, AI 생성 코드에 대한 신뢰도는 77%에서 60%로 떨어졌다. 모델은 계속 좋아지는데 신뢰는 오히려 하락한다. dev.to의 하네스 엔지니어링 가이드가 이 역설을 정면으로 다룬다.
핵심 공식은 단순하다. Agent = Model + Harness. 모델은 생각하는 부분이고, 하네스는 그 외 모든 것이다. 모델이 받는 컨텍스트, 접근할 수 있는 도구, 출력을 제약하는 스키마, 결과를 검증하는 체크. LangChain이 하네스만 바꾸고 모델과 프롬프트를 그대로 유지했을 때 에이전트 정확도가 52.8%에서 66.5%로 올랐다. 14포인트 상승, 모델 업그레이드 없이.
하네스는 두 가지 제어 유형으로 구성된다. 가이드(Guides)는 에이전트가 작업을 시작하기 전에 작동한다. AGENTS.md, CLAUDE.md, .cursorrules, TypeScript 스키마, 프로젝트 템플릿이 여기 해당한다. 에이전트가 참조할 컨텍스트를 사전에 결정한다. 센서(Sensors)는 에이전트가 출력을 생성한 후에 작동한다. 자동화 테스트, 타입 체킹, 린팅, 보안 스캔, AI 코드 리뷰가 여기 해당한다. 가이드는 오류율을 낮추고, 센서는 빠져나간 오류를 잡는다. 둘 다 없으면 안 된다.
실무적으로 이 설계가 중요한 지점은 패턴 드리프트 문제다. AI 지원 개발이 스케일할수록 가장 먼저 표면화되는 건 모델 품질이 아니라 코드베이스 일관성 붕괴다. 에이전트마다 다른 에러 핸들링, 컨벤션을 무시하는 네이밍, 이미 존재하는 유틸리티를 모르고 다시 짜는 중복. 이걸 PR 리뷰에서 잡으려 하면 리뷰 비용이 선형으로 늘어난다. 하네스는 이 문제를 인프라 레벨에서 해결한다.
세 레이어를 하나로 엮으면
거버넌스 후크, 엔지니어링 표준 인코딩, 하네스 설계는 각각 독립적으로 작동하지만 함께 설계될 때 시너지가 난다. 하네스의 가이드 레이어(CLAUDE.md, AGENTS.md)가 에이전트에게 "무엇을 해야 하는지"를 알려주고, 표준 인코딩이 "어떻게 해야 하는지"의 판단 기준을 제공하고, 거버넌스 후크가 "실행 전 마지막 체크포인트"를 제공한다. 모델은 이 세 레이어 위에서 실행된다.
팀 리빌딩 관점에서 이 설계의 함의는 역할 변화다. 에이전트를 프롬프트로 조종하는 사람과 에이전트가 실행될 환경을 설계하는 사람은 다른 역할이다. 전자는 선형으로 스케일하고, 후자는 지수적으로 스케일한다. AI-First 팀에서 높은 레버리지를 만드는 역할은 점점 후자로 이동하고 있다.
내일 당장 팀에 적용 가능한 순서를 제안하자면 이렇다. 먼저 CLAUDE.md에 팀 컨벤션을 인코딩한다(오케스트레이션 레이어). 그 다음 린터, 타입 체커, 테스트를 에이전트 워크플로우에 묶는다(하네스 센서). 마지막으로 고위험 도구 호출에 대한 사전 인터셉션을 추가한다(거버넌스 레이어). 세 단계 모두 모델 업그레이드보다 비용이 낮고, 효과는 더 오래 지속된다.