에이전트 하네스가 모델보다 중요해지고 있다

모델 스펙보다 모델을 묶어두는 고삐(하네스)가 열 배는 더 중요해졌다.

Anthropic이 온갖 거창한 마케팅 문구로 새 모델을 자랑할 때, 레딧에선 “현실 vs Anthropic의 주장”을 대놓고 비꼬는 풍자글이 올라와 폭풍 공감을 얻었다(점수가 300점이 넘었다). 모델은 더 똑똑해졌다고 외치는데, 실전 개발자들의 체감은 왜 제자리걸음이거나 오히려 퇴보했을까?

답은 모델 자체의 지능이 아니라, 모델을 감싸고 제어하는 하네스(Harness) 시스템에 있다.

똑똑한 모델이 바보짓을 하는 이유

아무리 천재적인 LLM이라도 터미널에 덩그러니 풀어놓으면 길 잃은 어린아이가 된다. 컨텍스트가 조금만 길어져도 앞서 내린 지시를 까먹고, 테스트가 깨지면 공포에 질려 멀쩡한 코드를 난도질한다.

이건 모델 파라미터가 모자라서가 아니다.

• 현재 작업의 상태(State)가 어디까지 진행됐는지
• 어떤 파일을 건드려야 하고 어떤 파일은 절대 열면 안 되는지
• 에러가 터졌을 때 즉시 멈춰 서서 사람에게 보고해야 하는지

이런 가드레일이 없기 때문이다. 아무리 엔진 출력이 좋아도 핸들과 브레이크가 없으면 그냥 흉기일 뿐이다.

하네스가 성능의 80%를 결정한다

결국 에이전트의 완성도는 프롬프트 하네스를 어떻게 짜느냐에 달렸다.

• PLAN.md로 파일 기반 상태를 동기화하고
• .claudesignore로 불필요한 노이즈 컨텍스트를 차단하며
• 단계별 마이크로 청킹과 브레이크 프롬프트로 급발진을 막는 것

이 하네스 구조가 탄탄하면 8B짜리 소형 오픈소스 모델로도 깔끔한 코드를 뽑아낼 수 있다. 반대로 하네스가 엉망이면 수천억 파라미터짜리 Opus 4.7을 가져와도 프로젝트 전체를 쓰레기통으로 만든다.

이제 개발자의 경쟁력은 좋은 모델을 구독하는 게 아니라, 내 워크플로우에 딱 맞는 단단한 프롬프트 하네스를 설계하는 엔지니어링 능력에 있다.