모델 탓이 아니다 — 대부분은 하네스 문제

AI가 이상하게 답한다는 말의 상당수는 모델이 아니라 그 바깥 껍데기 이야기다. 개발자 조 재그(JoeJag)가 8월 23일 블로그에 올린 글은 에이전트 시스템을 세 개 층으로 나눠 정의하고, 문제가 생겼을 때 어느 층을 열어봐야 하는지를 표로 정리했다. 요지는 단순하다. 층을 이름 붙일 수 있어야 그 층을 고칠 수 있다.

무슨 일인가 / 배경

글쓴이는 사람들이 에이전트와 모델을 같은 말처럼 섞어 쓰는 상황을 문제로 짚는다. 클로드(Claude)를 두고 어떤 사람은 모델을, 어떤 사람은 자기가 쓰는 명령줄 도구를 가리킨다. 대화가 어긋나면 원인 진단도 어긋난다.

그가 제시한 구분은 세 층이다. 맨 아래가 모델이다. 소네트(Sonnet), 오푸스(Opus), 제미나이(Gemini) 같은 것으로, 방대한 데이터로 학습된 숫자 덩어리이며 하는 일은 입력 토큰을 출력 토큰으로 바꾸는 것뿐이다. 가운데가 추론 서비스다. AWS 베드록(Bedrock)이나 앤스로픽(Anthropic) API처럼 호출을 받아 모델을 돌리고 사용량과 비용을 계산하는 층이다. 맨 위가 하네스다. 입력을 어떻게 조립해 넣을지, 출력을 어떻게 해석할지, 바깥 세상을 어떻게 건드릴지를 담당한다. 이 셋이 합쳐진 것이 에이전트 시스템이다.

핵심 짚어보기

실무에서 가장 중요한 대목은 여기다. MCP와 스킬(Skills) 같은 기능은 주로 하네스 층의 것이며, 모델은 MCP 서버나 스킬의 존재를 본래 알지 못한다. 무엇을 보여주고 무엇을 감출지는 하네스가 정한다. 그래서 같은 모델이라도 어떤 도구에 얹느냐에 따라 전혀 다르게 행동한다.

글쓴이는 건축 현장에 빗댄다. 땅을 만지고 못을 박는 시공팀이 하네스, 일정과 청구를 처리하는 소속 회사가 추론 서비스, 설계도만 그려주는 건축가가 모델이다. 건축가는 도면 외에는 아무것도 내놓지 않고 시공팀과 직접 통화하지도 않는다.

증상별 진단표도 함께 제시됐다. 추론이나 지식이 엉망이면 모델 자체이거나 하네스가 넘긴 맥락 문제다. 맥락이 빠졌다면 하네스다. 도구가 아예 안 보이거나 호출 형식이 깨졌다면 하네스와 연동 쪽을 본다. 도구가 잘못 실행됐다면 도구 자체이고, 응답이 느리면 추론 인프라, 비용이 과하면 모델 선택과 서비스 요금 구조다. 같은 모델인데 결과가 다르다면 원인은 거의 언제나 하네스다.

1인기업 실전 적용 포인트

• 장애를 발견하면 30초짜리 3문항부터 돌린다. 맥락을 제대로 넣었나, 도구가 노출돼 있나, 요금제나 서비스 상태가 바뀌었나. 이걸 건너뛰고 모델을 바꾸면 원인은 그대로 남는다.
• 어제 잘 되던 자동화가 오늘 이상하면 프롬프트 조립 코드부터 확인한다. 문서 요약본이 길어져 앞부분이 잘렸거나 참조 파일이 빠진 경우가 흔하다. 모델은 그대로다.
• 비용이 튀면 프롬프트를 줄이기 전에 층을 먼저 나눈다. 상위 모델을 습관적으로 쓰고 있는지, 같은 작업을 저가 등급으로 내려도 되는지가 실제 절감 지점이다.
• 자동화 문서에 세 층을 명시해둔다. 어떤 하네스에서 어떤 서비스로 어떤 모델을 부르는지 한 줄로 적어두면, 몇 달 뒤 문제를 남에게 설명할 때 시간이 절반으로 준다.

전망 / 주의점

글쓴이는 흥미로운 전망을 덧붙인다. 모델이 똑똑해질수록 오늘의 하네스 로직, 즉 스킬이나 MCP 같은 장치는 쓸모가 줄어들 수 있으며 지금 방식으로 만든 하네스는 오래 못 갈 수 있다는 것이다. 자동화 자산을 하네스 쪽 규칙으로만 잔뜩 쌓아두는 방식은 감가상각을 각오해야 한다는 뜻으로 읽힌다.

다만 이 글은 벤치마크나 실험이 아니라 용어를 정리한 개념 글이다. 층 구분은 진단의 출발점이지 해결책 자체는 아니다. 실제로는 하나의 증상이 두 층에 걸쳐 있는 경우가 많고, 그때도 어느 층부터 확인할지 순서를 정해주는 것이 이 표의 값어치다.

출처: JoeJag - Just Another Dev (https://code.joejag.com/2026/your-agent-is-not-the-model.html)