모델을 바꾸지 않았다. 모델이 일하는 환경을 바꿨을 뿐이다
같은 AI를 돌렸다.
한쪽은 78점을 찍었고, 다른 쪽은 42점에 머물렀다. 모델도, 설정도, 질문도 똑같았다. 바뀐 건 딱 하나. AI가 일하는 환경이었다.
이 이야기가 지금 개발자 커뮤니티를 뒤흔들고 있다. "Same Model, 78% vs 42%: The Harness Made the Difference." 뉴스레터 하나가 불을 지폈고, 비슷한 발견이 곳곳에서 쏟아졌다. 15개 LLM의 코딩 성능을 하루 만에 개선한 사람도, 바꾼 건 하네스뿐이었다고 했다.
2025년이 "에이전트의 해"였다면, 2026년은 그 에이전트를 감싸는 구조의 해다. 모델의 성능이 아니라, 모델이 앉아 있는 작업대가 결과를 가른다는 걸 업계가 숫자로 증명하기 시작했다.
수십 개의 프로젝트와 수백 개의 에이전트 세션을 거치면서 사람들이 도달한 결론은 일관됐다. 이건 모델 문제가 아니라 설정 문제다.
하네스(Harness)라는 개념이 있다.
AI 에이전트가 일하는 환경 전체를 말한다. 비유하자면 에이전트의 운영체제다. 어떤 정보를 메모리에 올릴지 결정하고, 어떻게 시작할지 정의하고, 뭘 할 수 있는지 알려준다.
좀 더 쉽게 말하면 이렇다. 목수에게 망치만 쥐어주는 것과, 정리된 작업대 위에 도면과 공구를 세팅해주는 것의 차이다. 망치의 성능은 같다. 하지만 결과물은 완전히 다르다.
구체적으로 보면 네 가지 요소로 구성된다.
첫째, 프로젝트의 규칙과 구조를 정의하는 청사진. CLAUDE.md라는 파일이 이 역할을 한다. 모든 세션이 시작될 때 자동으로 읽히는, 에이전트를 위한 README다. "이 프로젝트는 이런 구조이고, 이런 규칙을 따라야 한다"는 최소한의 약속.
둘째, 필요할 때만 꺼내 쓰는 전문 지식. Skills라고 부른다. 모든 걸 한꺼번에 에이전트에게 쏟아붓지 않고, 특정 작업이 필요할 때만 관련 지식을 로드한다. 요리사가 지금 볶을 재료만 꺼내고 나머지는 냉장고에 두는 것과 같다.
셋째, 역할별로 나뉜 서브에이전트. Agents다. 리서처는 조사하고, 라이터는 글을 쓰고, 리뷰어는 검수한다. 한 명이 다 하는 게 아니라, 전문가 팀을 구성하는 것이다.
넷째, 이 모든 걸 묶어서 실행하는 자동화 커맨드. Commands다. "글을 써줘"라는 한 마디에 리서치부터 작성, 검수, 변환까지 파이프라인이 돌아간다.
이 네 가지가 하네스의 뼈대다.
이 개념을 한국 개발자가 실험으로 증명했다.
Minho Hwang이라는 개발자가 Claude Code Harness라는 프로젝트를 공개했다. 15개의 실제 코딩 과제를 준비하고, 동일한 모델에 하네스 유무만 달리해서 돌렸다. 10개 품질 차원으로 채점했다. 아키텍처, 테스트 커버리지, 에러 처리 같은 것들이다.
결과는 압도적이었다.
하네스 없이 돌리면 평균 49.5점. 하네스를 적용하면 평균 79.3점. 60% 향상. 15개 과제에서 15전 15승이었다. 단 한 번도 하네스 없는 쪽이 이긴 적이 없다.
더 흥미로운 건 난이도별 차이다. 쉬운 문제에서는 약 24점 차이였다. 중간 난이도에서는 약 30점. 그런데 전문가 수준에서는 36점 넘게 벌어졌다. 복잡한 문제일수록 하네스의 효과가 커졌다.
이유는 직관적이다. AI 혼자서도 쉬운 건 어느 정도 해낸다. 하지만 복잡한 문제 앞에서는 "이 프로젝트가 어떤 구조여야 하는지", "테스트를 어떻게 작성해야 하는지"라는 가이드라인 없이는 품질이 곤두박질친다. 초보 목수가 간단한 선반은 만들 수 있어도, 복잡한 가구는 도면 없이 엄두도 못 내는 것과 같다.
가장 큰 개선이 일어난 영역도 의미심장하다. 테스트 커버리지와 아키텍처였다. 하네스 없이 돌리면 모놀리식 단일 파일에 테스트도 거의 없는 코드가 나온다. 하지만 하네스가 "이 프로젝트는 이런 구조여야 한다"는 청사진을 사전에 제공하니 결과물이 완전히 달라졌다.
Anthropic도 같은 결론에 도달했다. 공식 엔지니어링 블로그에서 이렇게 썼다. 시니어 엔지니어가 새 프로젝트에 투입되면 가장 먼저 하는 일이 뭔가. README를 읽고, 아키텍처를 파악하고, 진행 상황을 확인한다. 에이전트도 마찬가지여야 한다고.
인간 엔지니어에게서 영감을 받았다는 말이 인상적이었다. 결국 좋은 하네스란, 시니어 엔지니어가 주니어에게 해주는 온보딩을 AI에게도 해주는 것이다.
그런데 여기서 반전이 있다.
ETH 취리히 연구진이 "정보를 많이 줄수록 좋다"는 통념을 정면으로 뒤집었다. AGENTS.md라는 컨텍스트 파일이 실제로 도움이 되는지 실험한 것이다.
결과는 놀라웠다. AI가 자동 생성한 컨텍스트 파일을 넣으면 오히려 성공률이 3% 떨어지고, 추론 비용은 20% 이상 올라갔다. 인간이 직접 쓴 것도 효과는 고작 4% 정도로 미미했다.
핵심은 "뭘 넣느냐"가 아니라 "뭘 빼느냐"였다.
연구진의 권고는 명확했다. LLM이 생성한 컨텍스트 파일은 아예 빼라. 인간이 쓰는 것도 "AI가 코드를 읽으면 스스로 파악할 수 있는 정보"는 제외하고, 특수한 빌드 명령어나 커스텀 도구 같은 "추론 불가능한 정보"만 남겨라.
실무적으로 유명한 권고도 같은 맥락이다. "CLAUDE.md는 가능한 한 적은 지시만 담아야 한다. 이상적으로는 60줄 미만."
모순처럼 보이지만, 사실 같은 원리를 가리킨다. 컨텍스트 윈도우는 유한하다. 100만 토큰이라 해도, 불필요한 정보로 채우면 정작 중요한 게 밀려난다. 모든 걸 한꺼번에 넣으니까 에이전트가 관련 없는 정보에 주의를 빼앗기는 것이다.
답은 "점진적 공개"라는 개념에 있었다. 항상 필요한 최소한의 규칙만 기본으로 깔고, 전문 지식은 필요한 순간에만 꺼내 쓴다. 작업이 끝나면 다시 내린다. 이 분리가 하네스 설계의 핵심이다.
직접 경험해보니 이 원리가 맞았다. 블로그 프로젝트에 하네스를 적용하면서, CLAUDE.md에는 파일 네이밍 규칙과 프론트매터 스펙 같은 보편적 규칙만 넣었다. 플랫폼별 변환 규칙(브런치는 50-60% 축약, 링크드인은 25-30%)은 별도의 스킬 파일에 분리했다. 에이전트가 변환 작업을 할 때만 해당 규칙을 로드한다.
적용 전에는 "브런치 스타일로 써줘"라고 해도 매번 결과가 달랐다. 적용 후에는 일관됐다. 그리고 실행하면서 교훈도 쌓였다. 변환본에서 볼드 마크다운을 쓰면 복사 붙여넣기할 때 깨진다는 것. 미디엄에서 구분선이 이상하게 렌더링된다는 것. 이런 발견을 규칙에 반영하고, 다음 실행에 적용했다.
하네스는 한 번 만들고 끝나는 게 아니다. 실행하면서 계속 다듬어야 한다. 이 자기개선의 루프 자체가 하네스의 생명력이다.
이 이야기에서 기억할 건 세 가지다.
모델 업그레이드를 기다리는 건 비효율적이다. 같은 모델로도 환경만 세팅하면 60% 품질 향상이 가능하다. 다음 버전의 GPT나 Claude를 기다리기 전에, 지금 쓰는 모델의 작업대부터 점검하라. 투자 대비 효과가 압도적이다.
컨텍스트 관리가 곧 경쟁력이다. 적절한 순간에, 적절한 정보를, 적절한 양만큼 주는 능력. 이건 소프트웨어 엔지니어링의 근본 원칙과 닮아 있다. 관심사의 분리. 추상화. 캡슐화. 결국 좋은 엔지니어링의 원칙은 AI를 다룰 때도 유효하다.
그리고 하네스 엔지니어링은 새로운 엔지니어링 분야다. 프롬프트 엔지니어링이 2023년의 키워드였다면, 하네스 엔지니어링은 2026년의 키워드다. Anthropic이 공식 가이드를 내고, LangChain이 프레임워크를 만들고, 커뮤니티에서 베스트 프랙티스가 쏟아지고 있다. 이건 프롬프트보다 훨씬 넓은 범위를 다룬다. 파일 구조, 메모리 관리, 권한 제어, 워크플로우까지.
AI가 엉망인 코드를 뱉어낼 때, 대부분은 모델 탓을 한다. 하지만 같은 모델이 환경만 바꿨더니 전혀 다른 결과를 냈다. 15전 15승으로.
도구를 탓하기 전에, 작업대를 점검하라.