🔧 AI 100배 생산성의 진짜 비밀, 모델이 아니라 '하네스'였다

 

같은 AI인데 왜 누군 100배, 누군 2배일까요?

요즘 Claude나 GPT 쓰는 개발자들 사이에서 이상한 현상이 하나 있어요.

분명히 같은 모델을 쓰는데 누군 업무 속도가 10배 빨라졌다고 하고, 누군 "그냥 좀 편한 것 같기도 하고"에서 멈춰요. 모델 성능 차이가 아니에요. 구독 티어 차이도 아니고요. 그렇다면 뭐가 다른 걸까요?

2026년 현재, AI 개발 업계에서 가장 뜨거운 답이 나왔습니다. 바로 하네스(Harness)입니다.

와이콤비네이터 AI 교육 프로그램 운영자 Steve Yegge는 "AI 코딩 에이전트를 제대로 쓰는 사람은 Cursor 채팅 유저보다 10~100배 생산적"이라고 말했어요. 그 비결이 더 좋은 모델이 아니라, 모델을 감싸는 아키텍처, 즉 하네스에 있다고요.

이 글에서는 하네스가 정확히 무엇인지, 왜 2026년 AI 개발의 핵심이 됐는지, 실무에서 어떻게 적용할 수 있는지 풀어드릴게요.

하네스(Harness)가 뭔지 모르면 AI를 반만 쓰는 겁니다

하네스는 AI 모델을 감싸는 실행 환경 전체를 말해요.

말(馬)에 비유하면 딱 맞아요. 아무리 좋은 경주마라도 고삐, 안장, 마구 없이는 원하는 방향으로 달리지 못하잖아요. AI 모델도 마찬가지입니다. 모델이 아무리 똑똑해도, 그 주변을 감싸는 시스템이 없으면 엉뚱한 방향으로 달립니다.

Terraform 창시자 Mitchell Hashimoto는 2026년 2월 이 개념에 처음 이름을 붙이면서 이렇게 정의했어요. "에이전트가 실수할 때마다, 그 실수가 다시는 발생하지 않도록 엔지니어링하는 것." 단순히 프롬프트를 고치는 게 아니라, 구조적으로 재발을 막는 시스템을 만드는 거예요.

하네스가 하는 일은 네 가지로 정리돼요. 모델을 루프 안에서 실행하는 것, 파일을 읽고 쓰는 것, 컨텍스트를 관리하는 것, 안전을 보장하는 것. 여기서 핵심은 하네스를 얇게(thin) 유지하는 거예요. 하네스 안에 넣는 것보다 밖에서 별도로 만드는 스킬 파일에 진짜 가치가 담기거든요. 이걸 Thin Harness, Fat Skills라고 부릅니다.

수치로 증명됐습니다 — 하네스만 바꿔도 30위에서 5위로

하네스 엔지니어링이 이제야 주목받는 건 2026년 2월에 충격적인 실험들이 연달아 공개됐기 때문이에요.

먼저 OpenAI Codex 팀의 사례예요. 엔지니어 3명이 코드를 단 한 줄도 직접 타이핑하지 않고, 5개월 만에 100만 줄짜리 프로덕션 애플리케이션을 완성했어요. 1,500개의 PR이 머지됐고, 엔지니어 1인당 하루 평균 3.5개의 PR을 처리했습니다. 엔지니어들은 코드를 짠 게 아니라, 에이전트가 일할 수 있는 환경, 즉 하네스를 설계한 거예요.

LangChain의 사례는 더 직접적이에요. 그들의 코딩 에이전트는 모델을 전혀 바꾸지 않고 하네스만 개선했더니, Terminal Bench 2.0 벤치마크 성적이 52.8%에서 66.5%로 뛰었어요. 순위는 30위권에서 5위권으로 급등했습니다. 같은 모델, 다른 하네스. 결과는 완전히 달라졌어요.

보안 연구자 Can Boluk의 Hashline 실험도 있어요. 16개 LLM 모델에 에디트 방식 하나만 바꿨는데, Grok Code Fast 1 모델 점수가 6.7%에서 68.3%로 뛰었고, 전체 출력 토큰도 평균 20% 줄었어요. 모델 가중치는 건드리지도 않았어요. 하네스만 바꾼 결과입니다.

CLAUDE.md — 매 세션마다 읽히는 '불변 규칙집'

하네스를 구성하는 핵심 파일 중 첫 번째가 CLAUDE.md예요.

프로젝트 루트에 두는 마크다운 파일로, AI 에이전트가 매 세션 시작 시 자동으로 읽어요. 기술 스택, 코딩 컨벤션, 금지 규칙, 테스트 명령어 같은 것들을 담아요. 프롬프트에 매번 반복하지 않아도 되는 불변 규칙들이 여기 들어가는 거예요.

주의할 점이 하나 있어요. CLAUDE.md를 2만 줄로 만들면 모델의 주의력이 분산된다는 거예요. 실제로 Claude Code가 직접 "줄이라"고 말해줬다는 사례도 있어요. 200줄 안쪽으로 유지하고, 세부 내용은 별도 문서로 분리해서 필요할 때만 로드하는 게 정답이에요. CLAUDE.md는 얇게, 스킬 파일은 두텁게.

OpenAI는 이 파일을 '진실의 원천(System of Record)'으로 삼아야 한다고 강조합니다. 팀원이 바뀌어도, 모델이 바뀌어도, CLAUDE.md에 담긴 규칙은 코드베이스에 커밋된 파일로 영구히 남아요.

스킬 파일 — 마크다운이 새로운 프로그래밍 언어입니다

하네스 아키텍처에서 가장 중요한 개념이 스킬 파일(Skill File)이에요.

스킬 파일은 모델에게 '무엇을 할지'가 아니라 '어떻게 할지'를 알려주는 재사용 가능한 마크다운 문서예요. 핵심은 이게 함수(Function)처럼 동작한다는 거예요. 파라미터를 받아서 실행됩니다.

예를 들어 /investigate라는 스킬 파일을 만든다고 해요. 7단계로 구성되고, 파라미터로 TARGET, QUESTION, DATASET을 받아요. 여기에 "내부고발자와 210만 건의 이메일"을 넣으면 의학 연구 분석가가 됩니다. 같은 스킬에 "페이퍼컴퍼니와 선거자금 신고서"를 넣으면 법무 조사관이 되고요. 같은 마크다운 파일, 파라미터만 달라졌을 뿐인데 완전히 다른 전문가가 나오는 거예요.

스킬 파일의 또 다른 강점은 업그레이드 효과예요. 모델이 더 좋아지면 같은 스킬 파일을 쓰는 모든 작업이 자동으로 더 좋아집니다. 코드를 수정할 필요가 없어요. 스킬은 영구적인 업그레이드예요.

사람들이 가장 많이 하는 실수 — 하네스를 뚱뚱하게 만드는 것

하네스 엔지니어링에서 자주 보이는 안티패턴이 있어요. 하네스를 뚱뚱하게 만드는 거예요.

도구 정의를 40개 이상 넣어서 컨텍스트 윈도우 절반을 잡아먹거나, MCP 라운드트립에 2~5초씩 걸리는 범용 도구를 쓰거나, 모든 REST API 엔드포인트를 도구로 만들어버리는 식이에요. 결과는 토큰 3배 낭비, 지연시간 3배, 실패율 3배입니다.

반대로 좋은 하네스는 목적에 맞게 좁고 빠른 도구를 써요. 브라우저 자동화를 할 때, Chrome MCP로 스크린샷-클릭-대기를 하면 15초가 걸리는데, Playwright CLI로 각 동작을 100밀리초 안에 처리하도록 만들면 75배 빠릅니다. 소프트웨어는 더 이상 귀한 게 아니에요. 딱 필요한 것만, 정확하게 만들면 됩니다.

또 처음부터 멀티 에이전트 시스템을 설계하려는 것도 흔한 실수예요. 플래너, 제너레이터, 이밸류에이터를 바로 만들면 거의 확실하게 실패해요. 문제가 뭔지도 모르는 상태에서 해법을 설계하는 셈이거든요. 단일 에이전트로 먼저 실행하고 실패 패턴을 분류한 다음, 그때 하네스 구성 요소를 설계하는 게 맞는 순서예요.

컨텍스트 부패를 막아야 합니다 — 리졸버와 컴팩션

AI 에이전트를 오래 쓰다 보면 이상한 현상이 생겨요. 초반엔 멀쩡하게 따라오다가, 어느 순간부터 엉뚱한 방향으로 빠지는 거예요.

LangChain이 이걸 컨텍스트 부패(Context Rot)라고 이름 붙였어요. Chroma의 연구에 따르면, 모델은 컨텍스트 길이가 길어질수록 추론 능력이 떨어져요. 컨텍스트 윈도우가 채워질수록 에이전트가 점점 멍청해지는 거예요.

이에 대응하는 하네스 전략 두 가지가 있어요. 컴팩션(Compaction)은 컨텍스트가 한계에 다다르면 기존 내용을 요약하고 덜어내 에이전트가 계속 작업할 수 있게 해줘요. 리졸버(Resolver)는 어떤 작업 유형이 들어오면 어떤 문서를 먼저 불러올지 정하는 라우팅 테이블이에요. 스킬은 어떻게 할지를 알려주고, 리졸버는 무엇을 언제 로드할지 알려줘요. 둘은 한 팀이에요.

AI 역할이 아니라 인간 역할이 바뀌고 있습니다

이 개념을 실무에 적용하는 가장 직접적인 방법이 있어요.

에이전트에게 이런 규칙을 주세요. "일회성 작업은 하지 마라. 반복될 성격의 일이라면 3~10개를 먼저 수동으로 해라. 결과를 보여줘라. 내가 승인하면 스킬 파일로 만들어라. 같은 걸 두 번 부탁하게 만들면 실패한 거다." 스킬 파일 하나를 만들 때마다 시스템이 영구적으로 업그레이드돼요.

하네스 엔지니어링이 확산되면서 소프트웨어 엔지니어의 역할도 바뀌고 있어요. 직접 공을 차는 선수에서, 팀의 전술을 짜고 시스템을 운영하는 감독으로요. 오타나 컨벤션 체크에 시간을 쓰는 대신, 아키텍처 설계와 비즈니스 로직 검증에 집중하게 되는 거예요.

하네스 엔지니어링은 개발자 전용 개념도 아니에요. 비개발자도 충분히 적용할 수 있어요. 마케팅 담당자라면 채널별 콘텐츠 작성 스킬을 분리해두고 상황에 맞는 스킬을 호출하면 돼요. 기획팀이라면 신규사업 제안서 스킬, 시장 분석 스킬, 경쟁사 벤치마킹 스킬을 분리 설계하면 돼요. 원리를 이해하면 코딩 지식 없이도 충분히 적용 가능합니다.

마무리 — 프롬프트는 부탁이고, 하네스는 시스템입니다

2026년의 AI 개발 격차는 더 좋은 모델을 쓰는 것에서 오지 않아요.

같은 모델을 얼마나 잘 감싸느냐, 즉 하네스를 얼마나 잘 설계하느냐에서 나옵니다. Anthropic의 엔지니어 Prithvi Rajasekaran은 "모델이 발전해도 하네스 설계의 중요성은 사라지지 않는다"고 했어요. 모델이 좋아질수록 하네스로 할 수 있는 것도 같이 커지기 때문이에요.

Thin Harness, Fat Skills. 하네스는 얇게, 스킬은 두텁게. 이 원칙 하나가 2배 사용자와 100배 사용자를 가릅니다.

당장 오늘 반복하고 있는 작업 하나를 스킬 파일로 만들어 보세요. 그것이 여러분의 AI 시스템이 복리로 성장하는 첫 번째 발걸음입니다.