매일 아침 개발자들은 더 똑똑한 AI 모델이 나오기를 기다리며 벤치마크 점수를 확인한다. 하지만 정작 실무에서는 최신 모델을 도입해도 기대만큼의 성과가 나오지 않아 당황하는 경우가 많다. 최근 애디 오스마니(Addy Osmani)는 이러한 현상을 두고 모델의 지능 탓만 할 것이 아니라, 모델을 감싸고 있는 시스템인 하네스(Harness)를 살펴봐야 한다고 지적했다. 하네스는 모델을 제외한 모든 주변 장치를 뜻한다. 쉽게 말하면, 모델이 아무리 똑똑한 요리사라도 주방 도구가 엉망이거나 재료를 가져다줄 동선이 꼬여 있다면 맛있는 요리를 낼 수 없는 것과 같은 이치다.

하네스 엔지니어링의 핵심 구성 요소

하네스 엔지니어링은 모델이 일을 끝낼 수 있도록 돕는 모든 기술적 장치를 설계하는 분야다. 여기에는 시스템 프롬프트(AI에게 역할을 부여하는 지시문), 도구 연결, 컨텍스트(AI가 한 번에 기억하는 정보량) 관리, 샌드박스(외부 영향 없이 안전하게 코드를 실행하는 공간), 그리고 작업 중 오류를 잡아내는 훅(Hook, 특정 시점에 자동으로 실행되는 감시 장치)이 포함된다. 비브 트리베디(Viv Trivedy)는 이를 AI 에이전트 = 모델 + 하네스라는 공식으로 정리했다. Claude Code, Cursor, Aider, Cline 같은 도구들이 바로 이 하네스의 대표적인 사례다. 이들은 내부 모델이 달라도 사용자가 체감하는 성능은 하네스가 어떻게 설계되었느냐에 따라 크게 갈린다.

모델 탓이 아닌 설정 문제로 보는 관점

예전에는 AI가 엉뚱한 코드를 짜면 모델의 한계로 치부하고 다음 업데이트를 기다렸다. 이제는 하네스 엔지니어링을 통해 같은 모델이라도 성능을 극적으로 끌어올릴 수 있다는 사실이 증명되고 있다. 실제로 비브의 팀은 같은 모델을 사용하더라도 하네스 설정을 최적화하는 것만으로 벤치마크 순위를 30위권에서 5위권으로 끌어올렸다. 이는 모델의 잠재력을 하네스가 제대로 활용하지 못하고 있었음을 의미한다. 특히 실수를 규칙으로 굳히는 래칫(Ratchet, 한 번 발생한 실수를 방지하기 위해 규칙을 추가하고 자동 차단 장치를 붙이는 방식) 원칙은 하네스를 단순한 설정 파일이 아닌, 실패 이력을 바탕으로 진화하는 살아 있는 시스템으로 만든다.

하네스 엔지니어링이 가져올 변화

개발자가 바로 체감하는 변화는 모델 선택에 쏟던 에너지를 하네스 설계로 돌려야 한다는 점이다. 이제는 원하는 행동을 먼저 정의하고, 그 행동을 가능하게 하는 부품을 거꾸로 설계하는 방식이 필요하다. MCP(Model Context Protocol, AI 모델과 외부 데이터를 연결하는 표준 규격)과 같은 도구들이 표준화되면서, 이제는 밑바닥부터 만드는 대신 검증된 하네스 프레임워크를 활용해 자신의 도메인 지식을 입히는 것이 중요해졌다. 모델이 발전할수록 과거의 하네스 부품은 사라지겠지만, 그 자리는 모델이 새로 도달한 영역의 약점을 보완하는 더 정교한 하네스가 채우게 될 것이다. 결국 AI의 경쟁력은 모델을 갈아 끼우는 속도가 아니라, 자신의 작업 환경에 맞는 하네스를 얼마나 정교하게 다듬느냐에 달려 있다.