핵심 이슈: 모델을 바꿔도 안 되는 이유가 따로 있다
팀에서 AI 코딩 에이전트를 도입한 뒤 "기대만큼 안 나온다"는 말이 나온다면, 먼저 의심해야 할 것은 모델 선택이 아니다. dev.to의 두 글—AI-Agent-Dev-WBS-OS 개발기(codebay88)와 하네스 아키텍처 분석(octoooo)—을 나란히 읽으면, 에이전트 성능의 진짜 변수가 어디에 있는지 선명하게 드러난다.
하네스 분석 글에서 저자는 동일한 Kimi K3 모델을 Moonshot 자체 CLI와 Claude Code에 각각 물려서 운용했다. 체감 품질 차이가 있었고, 공식 벤치마크 수치도 Claude Code 환경이 0.8포인트 높았다. 이 수치 자체보다 중요한 건 Moonshot이 하네스를 '측정 조건'으로 공식 명시했다는 사실이다. 하네스는 성능의 배경이 아니라 성능의 일부다.
더 거친 숫자가 있다. Stop Comparing LLM Agents Without Disclosing the Harness 포지션 페이퍼에 따르면, 모델을 고정하고 하네스만 교체했을 때 SWE-bench Verified 점수가 최대 15포인트 이동하고, Verified Mini 서브셋에서는 단일 모델 기준 48포인트까지 흔들린다. 반면 연구 논문이 '의미 있는 모델 개선'으로 제시하는 수치는 보통 2~4포인트다. 우리가 모델 릴리스 주간마다 벤치마크를 비교하는 그 차이보다, 하네스 설계 차이가 훨씬 크게 결과를 바꾼다는 뜻이다.
맥락 해석: 두 기둥 프레임으로 읽기
하네스 분석 글은 에이전트를 두 기둥이 같은 하중을 받치는 구조로 설명한다. 첫 번째 기둥은 모델—판단의 천장을 결정한다. 두 번째 기둥은 하네스—컨텍스트 선택, 툴 노출, 권한 강제, 메모리, 멀티에이전트 조율, 그리고 결과 검증을 담당한다. 작업이 가벼울 때는 얇은 하네스도 버티지만, 리포지토리 전체 리팩터나 프로덕션 릴리스처럼 하중이 커지면 얇은 기둥이 먼저 무너진다.
저자는 하네스의 여섯 가지 기능을 제시한다: 컨텍스트 엔지니어링, 툴 사용과 안전 경계, 인간 개입, 메모리, 멀티에이전트 조율, 그리고 인수 검증과 평가 루프. 현존하는 코딩 에이전트들이 앞 다섯 가지에서는 제각각 강점이 있지만, 공통적으로 가장 얇은 기둥이 바로 여섯 번째—독립적인 인수 검증이다. 에이전트가 "완료"라고 보고해도, 실제 워크스페이스를 재검증하고 릴리스를 블로킹하는 독립 심판이 없다는 것이다.
이 맥락에서 AI-Agent-Dev-WBS-OS 개발기가 흥미롭다. 저자는 Claude Code로 두 종류의 에이전트를 조합했다. 목표를 구조화하는 프로토콜형 에이전트와, 9단계 파이프라인으로 WBS를 생성하는 코드형 에이전트다. 여기서 설계 결정이 돋보인다. F10(목표 구조화) 단계만 외부 API를 호출하고, F20부터 F90까지는 표준 라이브러리만으로 오프라인 결정론적으로 실행된다. MECE 체크는 코사인 유사도로 직접 구현했고, 계층 생성은 Union-Find를 손수 짰다. 모호한 표현이 감지되면 HITL(Human-in-the-Loop)이 작동한다. 하네스 설계를 의식적으로 통제한 결과물이다.
자기검증 루프: 실용적인 품질 투명성 확보 방법
이 프로젝트에서 가장 주목할 것은 자기 리뷰 워크플로우다. 저자는 개발 완료 후 Claude에게 동일 코드베이스를 독립적으로 리뷰하게 했다. 결과는 공개 README에 그대로 올렸다—긍정적 평가와 함께 실제 한계도 함께. Phase 8~10의 배포·자율운영 액션이 프로덕션 인프라를 실제로 건드리지 않는 시뮬레이션임을 코드 주석에 명시했고, 자기최적화 지수가 측정 학습이 아니라 고정 룰 기반 분류 점수임을 드러냈다. 리뷰 과정에서 환경 변수 이름 불일치로 인증이 무음 실패하는 실제 버그도 발견해 수정했다.
이 워크플로우의 핵심은 자기 리뷰가 완전한 독립 감사는 아니라는 점을 저자 스스로 인정한다는 것이다. 샘플링 리뷰고 망라적 검증이 아니다. 하지만 "같은 AI가 만든 코드를 다시 읽고 실행해보는 것"은 품질 주장을 솔직하게 만드는 실용적 레이어가 된다. 하네스 분석 글의 언어로 표현하면, 에이전트 보고를 그대로 납품으로 처리하지 않는 간단한 인수 게이트다.
저자의 멀티에이전트 시스템에서 코디네이터는 실행자의 완료 보고를 납품으로 취급하지 않는다. 작업 시작 시 완료 기준(Definition of Done)을 작성하고, 납품 후 코디네이터가 독립적으로 테스트를 재실행하며, 변경 규모와 민감 작업 신호를 리뷰하고, 인간 리뷰 필요 여부를 판단한다. 기계적 절반(테스트 재실행, 고정 기준 비교)은 모델과 무관하게 작동하고, 판단적 절반(실패 해석, 리스크 에스컬레이션)은 리뷰어 포지션에 앉힌 모델에 의존한다. 이 두 가지를 분리하는 것이 핵심이다.
시사점: 테크 리드가 지금 당장 바꿔야 할 것
실무적으로 이 두 글이 동시에 가리키는 것은 하나다. 에이전트 투자의 우선순위를 재배열하라. 모델 업그레이드는 벤더가 알아서 해준다. 하네스 신뢰성은 팀이 직접 쌓는 것이다. 지금 당장 체크해볼 질문 세 가지:
- 에이전트가 "완료"라고 보고했을 때, 그것을 독립적으로 검증하는 게이트가 파이프라인에 있는가?
- WBS나 스펙 문서를 AI가 생성했을 때, 그 결과물의 한계를 명시적으로 드러내는 리뷰 단계가 있는가?
- 모델을 교체했을 때 마이그레이션 비용은 환경 변수 하나지만, 하네스를 교체했을 때 비용은 "주말"임을 팀이 이해하고 있는가?
하네스의 가장 얇은 기둥이 어디인지 파악하는 것이 먼저다. 컨텍스트 엔지니어링, 툴 안전 경계, HITL 설계, 메모리 관리, 멀티에이전트 조율—다섯 가지는 지금도 많은 팀이 어느 정도 신경 쓴다. 하지만 인수 검증 루프, 즉 에이전트 출력물을 독립적으로 재검증하고 릴리스를 판단하는 게이트는 여전히 대부분의 팀에서 가장 얇다.
전망: 검증 레이어가 에이전트 역량의 다음 격전지
모델 성능은 계속 올라간다. 하네스 설계 역량은 팀마다 차이가 벌어진다. 벤더가 모델 기둥을 두껍게 만들어주는 속도보다, 우리가 하네스 기둥을 두껍게 만드는 속도가 더 느리다면—더 강한 모델 위에 더 무거운 작업을 올렸을 때 먼저 무너지는 건 결국 우리 쪽이다.
자기검증 루프는 거창한 인프라 없이 시작할 수 있다. 에이전트가 만든 코드를 동일 모델이 다시 읽게 하고, 그 결과를 편집 없이 공개하는 것. 작은 시작이지만, 품질 투명성을 확보하는 가장 실용적인 첫 걸음이다. 인수 게이트는 완벽하지 않아도 된다—"완료"가 통과하기 더 어려워지는 것만으로도 충분히 의미 있다.