에이전트가 코드를 짜는 속도는 이제 팀이 검토하는 속도를 훨씬 앞지른다. 문제는 에이전트의 '완료' 기준과 팀의 '완료' 기준이 근본적으로 다르다는 데 있다. 에이전트는 컴파일이 되고 테스트가 통과하면 태스크를 닫는다. 팀은 유지보수 가능성, 보안, 아키텍처 정합성까지 요구한다. 이 간극을 사람의 리뷰로 메우려 하면 결국 병목이 된다. 세 개의 기사가 각각 다른 각도에서 같은 결론을 가리킨다. 팀이 명시적으로 설계해야 할 품질 게이트는 세 단계로 구성된다.
1단계: 에이전트가 진입하기 전 — 하네스(Harness) 구조 설계
dev.to에 공개된 Harness Engineering 가이드는 에이전트의 할루시네이션이 왜 발생하는지를 먼저 짚는다. 원인은 단순하다. 경계가 없는 저장소에 에이전트를 투입하면 컨텍스트 윈도우 오염, 에이전트 기억 상실, 범위 이탈이 동시에 일어난다. 간단한 버그 수정 요청이 6시간짜리 루프로 변하면서 관련 없는 테스트를 삭제하고 모듈 절반을 재배선하는 일이 실제로 일어난다.
해법은 복잡한 시스템 프롬프트가 아니다. 저장소 안에 경량 제어 레이어를 박아두는 것이다. AGENTS.md로 에이전트의 진입 규칙을 정의하고, CODEX_CODING_GUIDELINES.md로 '필요한 줄만 건드린다'는 외과적 변경 원칙을 강제하고, SESSION_HANDOFF_RULES.md로 세션 간 컨텍스트 이전 방식을 명시한다. Andrej Karpathy의 autoresearch 프로젝트가 증명한 것처럼, 핵심은 단일 제어 매뉴얼과 엄격한 keep/discard 기준이다. 에이전트가 어떤 변경을 했다면 반드시 로컬 스크립트를 실행해 원본 대비 결과를 물리적 증거로 첨부해야 한다는 규칙이 이 레이어의 핵심이다.
실무 판단: 하네스 설계는 일회성 작업이 아니다. 모델이 스마트해질수록 불필요해진 규칙을 주기적으로 제거하는 '하네스 경량화' 사이클이 필요하다. 규칙이 많을수록 좋다는 착각이 오히려 에이전트 성능을 떨어뜨린다.
2단계: 에이전트가 파일을 쓴 직후 — 정적 분석 게이트 자동화
하네스가 에이전트의 행동 범위를 제한한다면, 두 번째 레이어는 산출물의 품질을 실시간으로 측정한다. dev.to의 LucidShark + MCP 연동 가이드가 제시하는 구조는 간단하지만 강력하다. Claude Code가 파일을 수정하는 즉시 MCP 서버를 통해 정적 분석 도구를 호출하고, 결과를 에이전트의 컨텍스트에 돌려주는 것이다. 에이전트가 스스로 수정하고, 통과할 때까지 반복한다. 사람은 최종 결과만 본다.
이 구조가 필요한 이유는 명확하다. 순환 복잡도 28짜리 함수는 테스트를 통과한다. 340줄짜리 중복 로직 모듈은 컴파일된다. 크리티컬 에러 경로의 브랜치 커버리지가 0%여도 PR이 열린다. AI가 최적화하는 것은 자신이 받는 피드백 신호뿐이다. 컴파일 성공과 테스트 통과만 신호로 주면 그것만 충족하는 코드가 나온다.
CLAUDE.md에 품질 게이트 규칙을 박아두는 것이 핵심이다. 단순히 프롬프트에 요청하는 것으로는 부족하다. 장시간 에이전트 세션에서 컨텍스트 압박이 쌓이면 에이전트는 기본값인 '기능 동작=완료' 판단으로 돌아간다. CLAUDE.md 앵커가 이 퇴행을 막는다. 복잡도 임계값은 10으로 낮게 잡는 것이 현실적이다. AI 에이전트는 문제를 분해하지 않고 즉각 해결하는 경향이 있어 15~25 범위의 복잡도를 자주 생산한다.
3단계: 에이전트가 외부 도구를 호출할 때 — 접근 제어 정책 레이어
세 번째 레이어는 코드 품질이 아니라 에이전트의 행동 반경을 통제한다. X(트위터)가 공개한 공식 MCP 서버 분석 기사가 이 필요성을 적나라하게 드러낸다. xmcp는 X API v2 전체를 131개 도구로 래핑해 에이전트에게 노출한다. createPosts, sendChatMessage, followUser, deletePosts가 모두 포함된다. 권한 모델도, 범위 제한도, MCP 레이어 수준의 레이트 리밋도 없다.
이게 GitHub이나 Stripe 서버와 다른 이유가 있다. GitHub 서버에서 에이전트가 실수하면 내부 저장소가 영향받는다. X 서버에서 에이전트가 루프에 빠져 할루시네이션 상태로 createPosts를 호출하면 당신의 이름으로 공개 트윗이 나간다. 피해 반경이 인프라가 아니라 평판이다. 삭제(deletePosts, deleteDirectMessagesEvents)는 되돌릴 수 없다.
해법은 에이전트와 MCP 서버 사이에 정책 프록시를 두는 것이다. 파괴적 도구는 전면 차단, 공개 행동(게시, 리포스트, DM)은 시간당 호출 횟수 제한, 전체 세션에 글로벌 캡을 적용한다. 코드 기반 도구도 마찬가지다. 에이전트에게 파일시스템, 데이터베이스, 외부 API 접근 권한을 줄 때 반드시 이 레이어를 먼저 설계해야 한다.
세 레이어를 순서대로 쌓아야 하는 이유
하네스 없이 정적 분석 게이트만 넣으면 에이전트가 범위를 이탈한 상태에서 품질 체크를 통과한 코드를 대량 생산한다. 정적 분석 게이트 없이 접근 제어만 넣으면 구조적으로 썩은 코드가 안전하게 배포된다. 접근 제어 없이 앞의 두 레이어만 갖추면 에이전트가 외부 시스템에 통제되지 않은 채 연결된다. 세 레이어는 독립적으로 작동하지 않는다. 하나를 건너뛰면 다른 두 개의 효과가 반감된다.
현실적인 도입 순서는 이렇다. 첫 주는 AGENTS.md와 CLAUDE.md로 하네스를 만든다. 두 번째 주는 MCP 기반 정적 분석 게이트를 연결한다. 세 번째 주부터 에이전트가 접근하는 외부 도구마다 정책 레이어를 적용한다. 세 단계를 한 번에 설계하려 하면 아무것도 배포되지 않는다. 순서가 중요하다.