AI 모델만 좋으면 될까? 2026년 가장 뜨거운 개념 "모델-하네스 적합성"

"같은 모델인데 왜 결과가 이렇게 달라?" 이 질문에서 시작됩니다

AI 에이전트를 써본 분이라면 한 번쯤 이런 경험이 있으실 거예요. 분명히 같은 Claude를 쓰는데, 어떤 도구에서 쓰면 빠릿빠릿하게 잘 되고, 어떤 환경에서 쓰면 자꾸 헤매고 오류가 납니다.

처음엔 제가 프롬프트를 잘못 썼나 싶었는데요. 알고 보니 원인이 전혀 다른 곳에 있었어요.

GPT-4를 OpenAI의 기본 환경에서 실행하면 기능 테스트 점수가 61.5%인데, 같은 모델을 Cursor에 올리면 87.2%로 뛰었다는 실험 결과가 공개됐습니다. 모델 업그레이드도, 파인튜닝도 없었어요. 오직 실행 환경만 바꿨을 뿐인데 25.7퍼센트포인트 차이가 났습니다.

이게 바로 2026년 AI 업계가 가장 주목하는 개념, 모델-하네스 적합성(Model-Harness Fit)의 핵심이에요.

하네스(Harness)가 뭔지 먼저 알고 가야 해요

'하네스'라는 단어, 낯설게 느껴지는 분도 있으실 거예요. 개발자들 사이에서도 이 단어가 본격적으로 쓰이기 시작한 건 2026년 초 무렵이거든요.

쉽게 말하면 이렇습니다. AI 모델(LLM)은 본질적으로 텍스트를 읽고 텍스트를 뱉는 엔진이에요. 그런데 현실에서 AI가 일을 하려면 파일을 읽고, 인터넷을 검색하고, 코드를 실행하고, 이전 대화를 기억해야 하잖아요.

이런 것들을 모델 대신 처리해 주는 소프트웨어 인프라가 바로 하네스입니다.

로봇으로 치면, 모델은 뇌고 하네스는 팔다리와 신경계 전체예요. 뇌가 아무리 좋아도 팔다리가 신호를 제대로 받아서 움직여주지 않으면 소용이 없죠.

하네스가 담당하는 것들을 정리하면 이렇습니다. 어떤 도구(파일 읽기, 웹 검색, 코드 실행)를 쓸 수 있는지 정의하고, 과거 대화와 메모리를 어떻게 저장하고 불러오는지 관리합니다. 멀티 에이전트(여러 AI가 협력)를 어떻게 조율할지도 하네스가 결정해요. AI가 만든 결과물을 어떻게 검증하는지도 마찬가지입니다.

결국 하네스는 모델이 현실 세계와 소통하는 방식을 통째로 정의하는 실행 환경입니다.

사람들이 가장 많이 하는 오해, "모델만 업그레이드하면 된다"

AI 성능이 기대에 못 미치면 가장 먼저 드는 생각이 있어요. "더 좋은 모델로 바꾸면 되겠지."

근데 데이터가 다른 이야기를 하고 있습니다.

Terminal-Bench 2.0이라는 AI 에이전트 성능 벤치마크 결과를 보면 충격적인 사실이 드러나요. Claude Opus 4.6이라는 동일한 모델을 두 가지 하네스에 올렸을 때, ForgeCode 하네스에서는 79.8점이 나왔고 Capy 하네스에서는 75.3점이 나왔습니다.

4.5점 차이가 작아 보일 수 있는데, 모델 세대 업그레이드 한 번에 보통 1~2점 오르는 리더보드에서 하네스 하나 바꿨더니 세대 교체 두 번치 효과가 난 거예요.

더 극단적인 사례도 있어요. Cursor를 만드는 팀이 "모델은 그대로 두고 하네스만 바꿔서 Terminal Bench 2.0 순위를 30위권에서 5위권으로 올렸다"고 공유했습니다. 25개 순위 점프를 모델 교체 없이 이뤄낸 거예요.

2026년 2월에 OpenAI Codex 팀도 비슷한 사례를 공개했습니다. 엔지니어 3명이 5개월간 코드를 단 한 줄도 직접 타이핑하지 않고, 100만 줄 규모의 프로덕션 애플리케이션을 만들어냈는데요. 핵심은 더 좋은 모델이 아니라 에이전트가 실수하지 않도록 감싸는 하네스 설계였다고 합니다.

모델 버전을 올리는 것보다 하네스 최적화가 더 큰 성능 향상을 가져올 수 있다는 게 점점 상식이 되어가고 있어요.

왜 이런 일이 벌어질까요, 포스트 트레이닝의 비밀

조금 기술적인 이야기인데, 최대한 쉽게 풀어볼게요.

AI 모델은 처음 학습이 끝난 뒤에 포스트 트레이닝(post-training)이라는 추가 훈련 과정을 거칩니다. 이 과정에서 모델은 자기가 실제로 동작할 하네스의 방식에 맞게 세밀하게 조정돼요.

예를 들면 이렇습니다. "파일을 수정할 때 어떤 도구 이름을 써야 하는가?"라는 질문에 Claude는 Edit이라고, Codex는 apply_patch라고 서로 다르게 학습해요. 메모리를 저장할 때도 Claude는 특정 폴더에 마크다운 파일로 저장하는 방식을, Codex는 SQLite 데이터베이스에 JSON 형태로 저장하는 방식을 학습합니다.

Cursor 팀이 이걸 아주 명쾌하게 설명했어요. "OpenAI 모델은 패치 형식으로 파일을 수정하도록 훈련받았고, Anthropic 모델은 문자열 교체 방식으로 훈련받았다. 둘 다 상대방 도구를 쓸 수는 있지만, 익숙하지 않은 도구를 쓰면 추론 토큰을 더 많이 소모하고 오류도 늘어난다."

모델을 뽑아서 다른 하네스에 꽂으면, 겉으로는 작동하는 것처럼 보이지만 속으로는 계속 삐걱거리는 거예요. 이게 바로 조용한 성능 저하입니다.

Claude Code, Codex CLI, GitHub Copilot CLI의 도구 구조가 이렇게 다릅니다

세 가지 대표적인 AI 코딩 에이전트가 얼마나 다르게 설계됐는지 구체적으로 살펴볼게요.

Claude Code는 파일 읽기(Read), 쓰기(Write), 수정(Edit)을 기본 도구로 씁니다. 파일을 수정할 때는 "여기서부터 여기까지 이 문자열을 저 문자열로 바꿔라"는 방식(old_string/new_string)이에요. 서브 에이전트를 여러 개 돌릴 때는 Agent라는 단일 도구 하나로 처리합니다.

Codex CLI는 apply_patch라는 자체 형식으로 파일을 수정해요. 서브 에이전트를 제어하는 동사가 spawn, wait, send_message, close 등 8개나 됩니다. Claude Code가 Agent 하나로 처리하는 걸, Codex는 8가지 동작으로 세분화해서 다루는 거예요.

GitHub Copilot CLI는 더 흥미로워요. 파일 읽기에 범위 지정(view_range)을 지원하고, 쉘 명령어를 read_bash, write_bash, stop_bash 세 단계로 나눠 제어합니다. 그리고 특이하게, Codex 계열 모델한테는 apply_patch 도구를 제공하고 Claude 계열 모델한테는 Edit 도구를 따로 제공해요. 모델별로 다른 도구 세트를 서빙하는 겁니다.

형식은 같아 보여도 약속 자체가 다른 거예요. 그러니 하네스가 달라지면 당연히 성능도 달라집니다.

메모리 저장 방식도 완전히 다르고, 이게 어긋나면 기억이 조용히 사라져요

AI 에이전트가 이전 대화나 프로젝트 정보를 기억하는 방식도 하네스마다 크게 달라요.

Claude Code는 세션이 시작될 때마다 MEMORY.md라는 파일을 자동으로 불러옵니다. 기억 하나하나가 별도 파일로 저장되고, 언제 생성된 기억인지 날짜 정보와 함께 표시돼요. "이 기억은 오래됐으니 맹신하지 말고 검증하고 써라"는 안내 문구도 함께 주입됩니다.

Codex는 6시간 이상 쉬는 시간이 있을 때 배치로 메모리를 정리합니다. 저렴한 모델이 1차로 추출하고, 더 강한 모델이 2차로 정리해요. 그리고 기억을 썼을 때 oai-mem-citation이라는 태그를 붙이는데, 이게 있어야 "이 기억이 실제로 쓰였다"는 신호가 쌓여서 오래된 기억을 버릴지 말지를 결정합니다.

GitHub Copilot CLI는 아예 서버에 기억을 저장해요. store_memory라는 도구로 원격 서버에 저장하고, 다음에 꺼낼 때도 서버에서 검색해서 가져옵니다.

만약 Claude로 훈련된 모델을 Codex 하네스에서 쓰면 어떻게 될까요? 모델이 기억을 써도 인용 태그를 붙이지 않아요. Codex 하네스는 "이 기억은 아무도 안 썼네"라고 판단해서 멀쩡한 기억을 버리기 시작합니다. 조용히, 그리고 꾸준히 성능이 떨어지는 거예요.

메모리 저장 방식과 인용 태그는 하네스에 종속된 약속이에요. 이게 어긋나면 기억 시스템 전체가 조용히 무너집니다.

모델 교체가 생각보다 훨씬 복잡한 이유

"AI 플랫폼을 만드는데 모델 선택지를 여러 개 주고 싶다." 아주 합리적인 요구예요. 근데 실제로 구현해 보면 생각보다 훨씬 복잡합니다.

모델을 바꾸면 함께 바꿔야 하는 게 한둘이 아니에요. 도구 이름과 입력 스키마, 메모리 저장 형식과 불러오기 방식, 인용 태그 형식, 시스템 프롬프트 구조, 멀티 에이전트 조율 방식, 스킬 파일 안의 도구 호출 규칙까지 연쇄적으로 영향을 받아요.

LangChain의 한 엔지니어가 이 문제를 딱 한 줄로 요약했어요. "에이전트 = 모델 + 하네스. 당신이 모델을 만드는 회사가 아니라면, 당신은 하네스를 만드는 것이다."

현실적인 해법은 두 가지입니다. 모든 모델에 공통 분모를 쓰면 모든 모델에서 다 아쉬운 중간 정도 성능이 나와요. 반대로 모델마다 별도 하네스를 유지하면 엔지니어링 비용은 높아지지만 각 모델에서 최고 성능을 뽑을 수 있습니다.

GitHub Copilot CLI가 두 번째 방법을 실제로 구현했어요. Claude 계열 모델에게는 Claude 방식의 도구를, OpenAI 계열 모델에게는 OpenAI 방식의 도구를 따로 서빙합니다. 복잡하지만 성능면에서는 가장 정직한 방식이에요.

모델이 성숙하면 하네스도 달라져야 합니다

재미있는 관찰이 하나 있어요. Anthropic에서 일하는 한 연구자가 긴 세션에서 AI 에이전트를 테스트했는데, Claude Sonnet 4.5로 작업할 때는 컨텍스트(대화 창)가 길어지면 에이전트가 불안해하는 현상이 있어서 "컨텍스트 초기화" 기능을 별도로 만들어야 했어요.

그런데 Claude Opus 4.6으로 업그레이드했더니, 그 현상이 거의 사라졌습니다. 2시간 넘게 한 세션을 연속으로 돌려도 안정적이었어요. 결국 그 "컨텍스트 초기화" 기능은 쓸모없어진 코드가 되어버렸습니다.

이게 바로 하네스의 생명주기예요. 모델이 못 하는 걸 보완하려고 하네스에 기능을 추가했다가, 모델이 그걸 자체적으로 잘 하게 되면 하네스의 해당 기능을 걷어내야 해요. 걷어내지 않으면 불필요한 레이어가 쌓여서 오히려 방해가 됩니다.

Cursor 팀이 이걸 한 문장으로 정리했어요. "하네스의 모든 구성요소는 모델이 스스로 못 하는 것에 대한 가정을 담고 있다. 그 가정은 낡아간다."

새 모델이 나올 때마다 기존 하네스 코드 중 어떤 게 이제 필요 없어졌는지 검토하는 것이 하네스 엔지니어링의 핵심 루틴입니다.

2026년 AI 선택의 기준이 바뀌고 있어요

맥킨지 조사에 따르면 전체 응답 기업의 39%가 AI 에이전트를 실험 중이지만, 단일 비즈니스 기능 내에서라도 본격적으로 확장한 기업은 23%에 그쳤습니다. 이 격차를 만드는 원인 중 하나가 바로 모델과 하네스의 미스매치예요.

2026년 흐름을 보면 방향이 어느 정도 보입니다.

모델과 하네스의 쌍이 실질적인 제품 단위가 됩니다. "Claude 씁니다"가 아니라 "Claude Code 씁니다", "Cursor 씁니다"가 실질적인 선택지가 되는 거예요. 하네스 없는 모델 단독 비교는 점점 의미를 잃어가고 있습니다.

하네스 경쟁도 치열해집니다. AI 에이전트 도입 경쟁의 핵심이 모델 성능보다 하네스 품질로 무게중심이 옮겨가고 있어요. 멀티 모델 전략은 반드시 하네스 전략과 함께 설계되어야 합니다. 여러 AI 회사 모델을 동시에 쓰고 싶다면, 각 모델에 맞는 도구 표면을 따로 관리하는 라우터를 설계해야 해요. "API 키만 바꾸면 되겠지"라는 접근은 조용한 성능 저하를 불러옵니다.

포브스코리아가 2026 AI 트렌드로 꼽은 추론 경제성(Inference Economics)도 결국 같은 맥락이에요. 모든 업무에 고비용 모델을 적용하는 게 아니라, 과업 특성에 따라 적합한 모델을 하네스 레이어에서 라우팅하는 것이 기업 경쟁력의 핵심이 됩니다.

마무리

AI 에이전트를 쓰거나 만드는 분이라면 이것만 기억하세요.

모델은 엔진입니다. 하네스는 자동차 전체예요. 엔진이 좋아도 차체, 변속기, 제어 시스템이 맞지 않으면 최고 성능이 나오지 않아요. 같은 모델도 어떤 하네스에 올라타느냐에 따라 성능이 몇 세대 차이 날 수 있다는 게 2026년 가장 뜨거운 AI 업계의 교훈입니다.

"모델만 바꾸면 된다"는 생각 대신, "이 모델은 어떤 환경에서 가장 잘 작동하는가"를 먼저 물어보는 습관. 그게 지금 AI를 제대로 쓰는 첫걸음입니다.