Claude Code 팀 운영, 모델보다 하네스 설계가 먼저다

Claude Code 팀 운영, 모델보다 하네스 설계가 먼저다

CLAUDE.md 토큰 예산 관리, MCP 서버 40% 비용 절감, 하네스 한 세대 점프 효과—세 가지 증거가 가리키는 방향은 같다

Claude Code 하네스 엔지니어링 CLAUDE.md 토큰 최적화 MCP 서버 컨텍스트 엔지니어링 AI-First 팀
광고

새 모델이 나올 때마다 팀 슬랙에 링크가 올라온다. "이번엔 진짜 다르다"는 기대와 함께. 하지만 솔직히 말하면, 모델 스펙을 비교하는 데 쓴 시간의 절반만 하네스 설계에 썼어도 팀 생산성은 이미 달라져 있었을 거다. 최근 세 가지 사례가 같은 결론을 서로 다른 각도에서 증명하고 있다.

핵심 이슈: 세 가지 증거, 하나의 방향

첫 번째는 CLAUDE.md 파일이다. dev.to의 분석에 따르면 대부분의 팀이 이 파일을 점점 불려가며 문서처럼 쓰고 있다. 문제는 이게 문서가 아니라 시스템 프롬프트라는 점이다. 매 턴마다 컨텍스트에 로드되고, 라인이 늘어날수록 정작 중요한 규칙이 노이즈에 묻힌다. 500줄이 넘어가면 신호가 의미 있게 저하된다는 게 실무 관찰이다.

두 번째는 MCP 서버를 통한 토큰 비용 절감이다. Parecode라는 MCP 서버의 A/B 테스트 결과, TypeScript 레포에서 비용 43% 절감, 어시스턴트 턴 83% 감소를 기록했다. Unity/C# 레포에서도 비용 41%, 턴 76% 감소다. 핵심 메커니즘은 단순하다. 코딩 에이전트는 기본적으로 파일 전체를 읽어 세 줄을 찾는다. Parecode는 그 루프를 끊고 필요한 컨텍스트 슬라이스만 돌려준다. 모델은 그대로, 환경만 바꿨을 뿐이다.

세 번째는 학술 레벨의 검증이다. METR의 공식 결론은 단호하다. "scaffolding 격차가 모델 한 세대 점프와 같은 수준이다." arXiv에 올라온 AHE(Automated Harness Evolution) 논문은 같은 모델로 하네스만 자동 진화시켰더니 Terminal-Bench 점수가 47.2에서 77.0으로 뛰었다고 보고한다. 30점 차이다. 모델을 갈아끼운 게 아니다.

맥락 해석: 토큰은 예산이고, 환경은 설계다

이 세 사례의 공통 언어는 예산이다. Anthropic Engineering 블로그가 KV 캐시를 "한정 자원, attention budget"이라 부른 것도 같은 맥락이다. 토큰은 쓰면 없어지는 자원이고, CLAUDE.md는 그 예산을 세션마다 소비하는 청구서다. 문서처럼 쓰면 청구서가 불어나고, 예산처럼 관리하면 신호 밀도가 올라간다.

CLAUDE.md 감사 도구(claudemd-audit)의 분석 결과를 보면 현실이 보인다. 일반적인 파일 구성은 결정론적 규칙 61%, 확률론적 규칙 25%, 모호한 규칙 15% 수준이다. "좋은 코드를 써라", "신중해라" 같은 문장들이 예산을 갉아먹는다. 더 큰 문제는 "마이그레이션 파일은 절대 수정하지 마라" 같은 결정론적 규칙이 텍스트로 적혀 있다는 것이다. 텍스트 규칙은 권고다. Claude가 놓치는 날이 반드시 온다.

해법은 구조 분리다. 결정론적으로 감지할 수 있는 규칙은 Hook으로 강제층을 만든다. rm -rf를 막는 PreToolUse Hook은 확률이 없다. 실행되거나 차단되거나 둘 중 하나다. 판단이 필요한 규칙만 CLAUDE.md에 남긴다. 그러면 파일은 50~150줄로 줄어들고, 남은 라인 하나하나가 실제로 주의를 끌 수 있는 밀도를 갖는다.

시사점: 팀이 내일 당장 할 수 있는 것

실행 순서를 구체적으로 짚으면 이렇다. 첫째, CLAUDE.md를 세 버킷으로 분류한다. 결정론적 규칙, 확률론적 규칙, 모호한 규칙. claudemd-audit 도구를 .claude/skills/에 넣으면 자동 분류 리포트를 뽑아준다. 모호한 라인부터 지우는 게 가장 쉬운 첫 번째 승리다. 둘째, 상위 10개 결정론적 규칙을 Hook으로 옮긴다. 한 시간이면 가능하다. 셋째, 대규모 멀티파일 작업이 많은 팀이라면 Parecode 같은 MCP 서버 도입을 검토한다. 단, 단일 파일 작업 위주라면 효과가 없다는 점을 솔직히 인정해야 한다.

팀 리빌딩 관점에서 이 변화가 의미하는 건 역할 재정의다. 예전엔 "프롬프트를 잘 쓰는 사람"이 AI-First 팀의 핵심 역량이었다. 지금은 하네스를 설계하는 사람이 그 자리를 대체하고 있다. CLAUDE.md를 어떻게 구조화할지, Hook으로 어떤 강제층을 쌓을지, 멀티에이전트 구조에서 KV를 어떻게 격리할지—이게 2026년 AI-First 팀의 실질적 역량 기준이다.

전망: 하네스 경쟁이 모델 경쟁을 추월하는 시점

다만 냉정하게 짚어야 할 결함도 있다. Context Rot 논문은 컨텍스트를 길게 채울수록 어느 지점에서 정확도가 절벽처럼 떨어진다고 보고했다. 하네스가 강해질수록 개발자 본인의 판단력이 무뎌질 수 있다는 역설도 arXiv 논문이 수치로 보여줬다. 멀티에이전트 구조가 지나치게 쪼개지면 의도가 분산된다는 Cognition AI의 비판도 현장에서 유효하다. 하네스 설계가 답이지만, 과잉 설계가 새로운 문제를 만든다는 걸 팀이 같이 인식하고 있어야 한다.

시장은 이미 방향을 잡았다. 모델 단일 비교에서 작업 환경 전체를 묶는 회사들이 빠르게 자리를 잡고 있다. GPT-5를 기다리는 시간보다, 지금 팀이 운영하는 CLAUDE.md를 감사하고 Hook 10개를 만드는 한 주가 실질적으로 더 빠른 세대 점프다. METR이 측정한 숫자가 그 명분이고, Parecode의 A/B 테스트가 그 방법론이다. 모델 비교에 쓰던 시간을 하네스 다듬는 시간으로 옮기는 것—그게 AI-First 팀이 지금 해야 할 일이다.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요