모델 업그레이드보다 54포인트 높은 숫자가 나왔다
최근 Claw-SWE-Bench 연구에서 흥미로운 실험 결과가 나왔다. GLM 5.1 모델을 고정한 채 에이전트 하네스만 바꿨더니 Pass@1이 19.1%에서 73.4%로 뛰었다. 54.3포인트 차이다. 모델 선택이 가져다주는 효과(29.4pp)와 하네스 선택이 가져다주는 효과(27.4pp)가 거의 동일하다는 결론도 함께 나왔다. 더 비싼 모델로 갈아타는 것과 어댑터 설계를 정교하게 다듬는 것이 같은 무게를 지닌다는 뜻이다.
이 수치가 불편한 이유는, 많은 팀이 지금 정반대의 우선순위로 움직이고 있기 때문이다. 모델 비교 벤치마크를 살피고, 최신 LLM으로 마이그레이션하는 데 스프린트를 쏟아붓는다. 하네스는 '고정된 배관'처럼 취급한다. 이 연구는 그 직관이 틀렸다고 말한다.
하네스를 설계한다는 것의 실체
하네스 설계가 중요하다는 말은 추상적으로 들린다. 구체적으로는 세 가지 설계 개념이 맞물린다.
첫 번째는 Loop Engineering이다. dev.to에 올라온 글(quickstrats)에서 정리한 개념인데, AI가 목표를 받은 뒤 스스로 결과를 검증하고, 고치고, 다시 검증하는 반복 구조를 설계하는 것이다. 공식은 단순하다: Goal → Action → Self-check → Evaluate → Fix → Check again → Done. 핵심은 사람이 매 루프를 드라이브하지 않아도 AI가 스스로 멈출 조건을 알고 있다는 것이다. "10라운드 이내", "테스트 전통과", "오류율 1% 미만" 같은 하드 스탑이 없으면 루프는 토큰을 태우는 블랙홀이 된다.
두 번째는 검증 가능한 목표다. 루프가 자체 평가를 하려면 평가 기준이 기계가 읽을 수 있는 형태여야 한다. "더 좋게 만들어"는 루프를 설계할 수 없다. "src/ 디렉터리로 이동 후 모든 임포트 통과 확인"은 설계할 수 있다. 루프 엔지니어링이 버그 픽스·리팩터링·테스트 통과에는 강하고, 아키텍처 결정·UX 판단에는 약한 이유가 여기 있다.
프로덕션에서 터지는 이유는 모델이 아니다
18개월간 AI 워크플로우를 운영한 경험을 정리한 echonerve의 Agent Stack 프레임워크는 더 직접적이다. 프로덕션에서 에이전트가 실패하는 원인을 5개 레이어로 분해했는데, 모델(Layer 1)은 "가장 많이 논의되지만, 신뢰성 문제에서 가장 덜 중요한 레이어"로 규정한다.
프런티어 모델들 사이의 벤치마크 격차는 3~5%다. 반면 같은 모델에 프롬프트를 일관성 없이 쓸 때 생기는 행동 분산은 그 격차를 가볍게 뛰어넘는다. 더 무서운 경고는 이것이다: 더 유능한 모델을 망가진 아키텍처에 넣으면, 더 빠르고 더 설득력 있는 틀린 답이 나온다.
5레이어 중 현장에서 가장 자주 빠뜨리는 것은 메모리(Layer 2)와 행동(Layer 4)이다. 대부분의 팀이 모델(Layer 1)과 툴(Layer 3)만 세팅하고 에이전트를 켠다. 결과는 예측 가능하다. 매 세션마다 컨텍스트를 재설명해야 하고, 에이전트는 어제 내린 결정을 모른 채 다시 같은 실수를 한다. "AI가 아직 프로덕션에 쓸 수준이 아니다"는 결론이 나오지만, 실제 진단은 다르다. 스택이 설계되지 않은 것이다.
행동 레이어 한 시간이 모델 업그레이드를 이긴다
Agent Stack에서 "레버리지가 가장 높지만 가장 자주 건너뛰는" 레이어는 행동(Layer 4)이다. Andrej Karpathy가 1월에 문서화한 문제—에이전트가 조용히 잘못된 가정을 하고, 단순한 문제를 과도하게 복잡하게 풀고, 전체 범위를 이해하지 못한 채 코드를 수정한다—를 65줄짜리 마크다운 파일로 해결한 사례가 GitHub에서 22만 스타를 넘겼다. 그 파일을 본 개발자들이 "내 에이전트 얘기다"라고 공감했기 때문이다.
행동 레이어의 내용은 간단하다. 범위가 모호하면 질문하라. 되돌릴 수 없는 작업 전에 의도를 확인하라. 현재 태스크 범위 밖의 파일을 수정하지 마라. 불확실할 때 진행하지 말고 플래그를 세워라. 이것을 시스템 프롬프트에 한 번만 박아두면, 이후 모든 세션에서 일관된 행동이 나온다. 이 작업에 한 시간을 쓰는 것이 모델 업그레이드보다 신뢰성 향상에 더 직접적이라는 게 현장 결론이다.
팀에게 실질적으로 의미하는 것
세 연구가 공통적으로 가리키는 시사점을 팀 관점에서 정리하면 이렇다.
먼저 스택 감사부터다. 지금 운영 중인 에이전트가 5레이어 중 몇 개를 설계했는지 확인하라. 모델과 툴만 있고 메모리·행동·휴먼 레이어가 없다면, 모델을 바꾸기 전에 이 세 레이어를 먼저 채워야 한다.
루프를 설계할 수 있는 태스크를 분리하라. 명확한 검증 기준이 있는 작업(테스트 통과, 빌드 성공, 린트 오류 수 등)은 Loop Engineering으로 자동화할 수 있다. 판단이 필요한 작업(아키텍처 결정, UX 리뷰)은 루프가 아니라 사람 개입 체크포인트를 설계해야 한다.
SWE-Bench 류 벤치마크를 읽는 방식을 바꿔야 한다. 하네스 정보 없이 모델 점수만 비교하는 리더보드는 절반짜리 정보다. 팀에서 특정 에이전트 도구를 평가할 때도 같은 원칙이 적용된다. 도구가 어떤 하네스 구조 위에서 그 성능을 냈는지를 확인하지 않으면, 도입 후 결과가 다를 수 있다.
전망: 설계 역량이 AI 생산성의 진짜 병목이 된다
Loop Engineering이 확산되면 프롬프트 엔지니어링은 전제 조건으로 내려앉는다. 좋은 루프를 만들려면 AI에게 무엇을 시킬지 정확히 표현할 수 있어야 하니까. 하지만 그것만으로는 부족하다. 루프 구조·메모리 설계·행동 가이드라인·휴먼 체크포인트까지 전체 스택을 설계하는 역량이 팀의 AI 생산성을 결정하게 된다.
6개월 후에는 "어떤 모델 쓰세요?"보다 "하네스를 어떻게 설계했어요?"가 AI-First 팀을 구별하는 질문이 될 것이다. 모델은 모두가 동일하게 API로 쓴다. 하네스는 팀마다 다르게 설계한다. 그 차이가 성능 격차를 만든다.