'하네스 엔지니어링'이 뜨는 이유

[작은소나무]

하네스 엔지니어링이 뜨는 이유

같은 Claude로 실패율을 0으로 만든 방법

AI가 우리의 삶에 정착을 하면서 많이 듣는 단어가 있습니다.

'에이전트', '자동화', 'AI가 알아서 일한다' 같은 말들입니다.

그런데 그 에이전트를 실제로 작동하게 만드는 진짜 단어는 따로 있습니다.

바로 하네스(Harness) 엔지니어링 입니다.

낯선 단어지만 구조는 단순합니다.

사람이 모델에 주는 지시(프롬프트)가 가장 안쪽에 있고, 그 위에 모델이 참고할 맥락(컨텍스트)이 얹히고, 다시 그 바깥을 시스템 전체(하네스)가 감쌉니다.

아래 그림 한 장이 오늘 글의 절반입니다.

AI 활용

그래서 뭐가 달라지냐고요?

더 똑똑한 모델로 바꾸면 에이전트가 더 잘 작동할 줄 알았는데, 실제로는 모델은 그대로 두고 '감싸는 구조'만 바꿨더니 성공률이 80%에서 100%로 올랐습니다.

---

AI 활용

Vercel이 공개한 실측이다.

텍스트-투-SQL 에이전트의 툴을 80% 삭제했더니 속도는 3.5배 빨라지고, 토큰은 37% 줄었으며, 실패하던 작업이 성공으로 돌아섰다.

모델은 한 글자도 안 바꿨다.

이게 하네스 엔지니어링(Harness Engineering)이다.

2026년 들어 'AI 경쟁력은 모델이 아니라 모델을 감싼 인프라에서 갈린다'는 명제가 데이터로 증명되기 시작했다.

엔터프라이즈 AI 에이전트 프로젝트의 88%가 production에 도달하지 못하는데, 그 이유가 모델이 멍청해서가 아니라 하네스가 없어서라는 진단이 굳어지고 있다.

아래에서 하네스가 정확히 무엇인지, 왜 '툴을 더 넣을수록 성능이 떨어지는지', 그리고 1인 개발자·기업이 무엇부터 손대야 하는지를 구체적 수치와 3가지 시나리오로 정리했다.

---

🔧 하네스란 무엇인가 — 프롬프트에서 하네스까지 4년의 이동

💡 이 섹션 핵심

당신이 지금까지 만진 건 '프롬프트' 한 겹뿐이었을 가능성이 높다.

그 위에 두 겹이 더 있다.

용어부터 정리한다.

뉴스가 잘 안 짚는 부분이다.

▶️ 프롬프트 — 모델에게 "무엇을 하라"고 지시하는 한 번의 명령.

▶️ 컨텍스트 — 모델이 답하기 전에 어떤 배경 정보를 보여줄지 설계하는 것.

▶️ 하네스 — 이 모든 게 안전하고 반복적으로 작동하도록 감싸는 시스템 전체.

루프, 툴 호출, 메모리, 가드레일, 추적(tracing)까지.

자동차로 비유하면 프롬프트는 운전대 조작, 컨텍스트는 내비게이션 정보, 하네스는 차체·브레이크·안전벨트 전체다.

핵심은 포함 관계다.

하네스 ⊃ 컨텍스트 ⊃ 프롬프트.

하네스가 가장 바깥의 상위 개념이다.

무게중심은 4년에 걸쳐 이동했다.

프롬프트 엔지니어링(2022~2024) → 컨텍스트 엔지니어링(2025) → 하네스 엔지니어링(2025~2026).

"프롬프트 엔지니어링은 죽었다"는 자극적 제목이 한국 개발 블로그에도 도는 이유가 여기 있다.

프롬프트가 쓸모없어진 게 아니라, 승부처가 한 단계 바깥으로 밀려난 것 이다.

여기서 뉴스에 잘 안 나오는 정의 하나.

Claude Code는 Claude를 감싼 에이전트 하네스(agentic harness)다.

Anthropic은 자사 문서에서 이렇게 못 박았다

여기서 하네스란 '모델이 아닌 모든 것' 을 뜻한다.

즉 우리가 매일 쓰는 Claude Code, Cursor, Codex 같은 도구의 정체는 'AI'가 아니라 ​AI를 감싼 하네스다.

같은 모델을 써도 하네스가 다르면 완전히 다른 제품이 된다.

production 수준의 하네스는 보통 9개 구성요소로 이뤄진다.

모델 인터페이스, 툴 레지스트리, 컨텍스트 매니저, 플래닝 모듈, 실행 엔진, 메모리 시스템, 피드백 루프, 안전 가드레일, 오케스트레이션 레이어.

AI 활용

한 분야의 기술이 아니다.

하네스 엔지니어링은 ​분산 시스템 + 메모리 아키텍처 + 보안 공학 + LLM 내부 동작이 교차하는 자리다.

"프롬프트 잘 쓰는 법"과는 난이도 자체가 다르다.

왜 하필 2026년에 이 개념이 떠올랐을까.

두 가지가 동시에 일어났다.

첫째

모델 성능이 상향 평준화 됐다.

프런티어 모델 간 벤치마크 격차가 한 자릿수%로 좁혀지면서, 모델 선택만으로는 더 이상 차별화가 안 된다.

둘째

에이전트가 실험실을 벗어나 production에 투입

되기 시작했다.

데모는 잘 되는데 실제 업무에 넣으면 깨지는 경험이 쌓이면서, '모델이 아니라 그 주변이 문제'라는 진단이 업계 공통 인식이 됐다.

모델이 상수가 되는 순간, 변수는 하네스로 옮겨간다.

이게 2026년 하네스 엔지니어링이 별도 직무로 분화되는 배경이다.

---

📊 툴을 80% 지웠더니 성능이 올랐다 — 반직관의 증거

💡 이 섹션 핵심

'기능을 더 넣으면 좋아진다'는 소프트웨어의 상식이 에이전트에선 거꾸로 작동한다.

이 블로그에서만 수치로 분해한다.

이 섹션이 핵심이다.

결론에서 필자의 판단을 내리기 위한 근거를 여기 깐다.

Vercel은 내부 텍스트-투-SQL 에이전트 'd0'를 만들면서 16개의 특화 툴을 붙였다.

스키마 조회, 쿼리 검증, 에러 복구, 의도 명확화, 조인 경로 탐색, 구문 검증, 분석 플래너, 결과 포매터…

정석대로였다.

그런데 결과는 느리고, 잘 깨지고, 유지보수가 끝없이 드는 에이전트였다.

그래서 반대로 갔다.

툴의 80%를 삭제하고, 단 하나의 능력으로 대체했다 — "bash 명령을 실행하라."

구성은 Claude + YAML 파일 디렉터리 + grep, 그게 전부였다.

결과를 수치로 보면 충격적이다.

📌 성공률: 80% → 100%

📌 속도: 3.5배 향상, 토큰 37% 감소

📌 최악 케이스 비교: 기존 구조는 724초 / 100스텝 / 145,463토큰을 쓰고도 실패했다. 새 구조는 141초 / 19스텝 / 67,483토큰으로 성공했다.

AI 활용

이 수치가 의미하는 바는 명확하다.

같은 모델(Claude)에, 같은 문제에, 하네스만 바꿨는데 실패가 성공이 됐다.

어쩌면 최고의 에이전트 아키텍처는 거의 아키텍처가 없는 것이다.

Vercel이 내린 결론은 한 문장이다

툴을 많이 다는 건 '친절'이 아니라 ​모델의 컨텍스트를 어지럽혀 판단을 흐리는 노이즈였던 것이다.

왜 툴이 많으면 나빠질까.

사람의 직관과 정반대라 짚고 넘어가야 한다.

LLM은 호출할 수 있는 툴 목록 전체를 매 순간 컨텍스트에 올려놓고 그중 하나를 고른다.

툴이 16개면 매 스텝마다 16개의 설명을 읽고, 비슷비슷한 후보 사이에서 망설인다.

선택지가 많을수록 잘못 고를 확률이 오르고, 한 번 잘못 고르면 다음 스텝이 전부 어긋난다.

토큰은 토큰대로 먹고, 판단은 흐려진다.

툴을 줄인다는 건 기능을 버리는 게 아니라 모델의 인지 부하를 덜어 정확도를 사는 것이다.

Vercel의 724초→141초는 바로 이 '망설임의 누적'이 사라진 결과다.

Vercel만의 우연이 아니다.

LangChain 의 코딩 에이전트는 Terminal Bench 2.0에서 52.8%에서 66.5%로 점수를 끌어올려 바닥권에서 상위 5위로 진입했는데, 바꾼 건 오직 하네스뿐이었다.

모델도, 문제도 그대로였다.

여기서 한국 기업·개발자가 새겨야 할 지점이 나온다.

대부분은 에이전트가 잘 안 되면 "더 좋은 모델로 바꾸자" 또는 "툴을 더 붙이자" 로 간다.

둘 다 비용이 든다.

그런데 위 사례들이 말하는 건 정반대다.

모델 교체비 0원, 툴 추가 0개로, 하네스 설계만 다듬어 결과를 뒤집을 수 있다.

엔터프라이즈 에이전트의 88%가 production에 못 가는 'production gap'의 진짜 원인은 모델 성능이 아니라 하네스의 부재 또는 과설계다.

해외 빅테크는 이걸 '제어 평면(control plane)'이라 부르며 별도 엔지니어링 분야로 분리하기 시작했다.

모델을 키우는 데만 몇 년을 쏟고, 정작 그 모델이 현실과 상호작용할 '신경계와 외골격' 을 방치했다는 자성이다.

한국은 아직 이 분리가 거의 안 돼 있다.

기회이자 격차다.

---

💡 무엇부터 손댈 것인가 — 1인부터 기업까지 3가지 시나리오

💡 이 섹션 핵심

9개 요소를 다 만들 필요는 없다.

깨지는 순서대로 막으면 된다.

결론에서 우선순위를 못 박는다.

하네스를 처음부터 9개 다 짜려 들면 시작도 못 한다.

현실에서 깨지는 순서는 정해져 있다.

📌 시나리오 A — 1인 개발자/사이드프로젝트 (가장 흔함)

가장 먼저 깨지는 건 툴 과설계다.

Vercel의 교훈을 그대로 적용한다.

툴을 늘리지 말고, ​bash + 파일시스템 + grep 같은 범용 능력 한 줌으로 시작한다.

그다음 막을 것은 컨텍스트 관리다 — 대화가 길어지면 모델이 앞을 잊는다.

핵심 규칙을 `CLAUDE.md` 같은 상시 컨텍스트 파일에 박아두는 것만으로도 안정성이 크게 오른다.

1인에게 메모리 시스템·오케스트레이션은 아직 사치다.

오늘 당장 할 수 있는 건 세 가지다.

① 지금 쓰는 에이전트의 툴 목록을 펼쳐 절반을 지워본다.

성능이 떨어지지 않으면 그 절반은 노이즈였다.

② 매번 반복하는 지시(톤, 규칙, 금지사항)를 컨텍스트 파일 한 장으로 고정한다.

③ 에이전트가 틀린 케이스를 3개만 기록해 둔다.

이게 나중에 평가 하네스의 씨앗이 된다.

돈도 코드도 거의 안 드는데, 효과는 모델 교체보다 크다.

📌 시나리오 B — 팀/스타트업 (성장통 구간)

여기서 진짜 문제는 가드레일과 권한이다.

Anthropic이 Claude Code에서 쓰는 방식이 모범 답안이다.

'모델이 무엇을 시도할지'와 '시스템이 무엇을 허용할지'를 아키텍처 레벨에서 분리 한다.

Claude Code는 약 40개 툴 권한을

① 프로젝트 로드 시 신뢰 설정,

② 매 호출 전 권한 검사

③ 고위험 작업엔 사용자 확인

이렇게 3단계로 독립 게이팅한다.

권한을 모델의 '판단'에 맡기지 않는 게 핵심이다.

팀 단위에서 에이전트가 사고를 치는 대부분은 이 분리가 없어서다.

AI 활용

📌 시나리오 C — 엔터프라이즈 (production gap 구간)

88%가 멈추는 바로 그 지점.

여기선 오케스트레이션·관측(observability)·평가 하네스(eval‎ harness)가 승부를 가른다.

'Reasoning Sandwich'처럼 비싼 추론 모델은 계획·검증에만 쓰고 중간 단계는 싸고 빠른 모델로 돌려 비용을 깎거나, 반복 쿼리에 시맨틱 캐싱을 거는 식의 설계가 들어간다.

핵심은 '에이전트가 잘 돌아가는지'를 측정할 수 있는 평가 회로를 먼저 만드는 것이다.

측정이 안 되면 개선도 없고, production도 없다.

엔터프라이즈가 자주 놓치는 함정이 하나 더 있다.

하네스 과설계 다.

시나리오 A의 1인이 '툴을 안 줄여서' 실패한다면, 대기업은 거꾸로 '거버넌스·승인·로깅을 과하게 얹어서' 에이전트가 한 발도 못 떼게 만든다.

Vercel이 16개 툴을 1개로 줄인 교훈은 규모가 커질수록 더 중요해진다.

하네스는 두껍게 쌓는 게 아니라, 깨지는 지점에만 얇게 까는 것 이다.

9개 요소를 전부 구현한 하네스가 좋은 하네스가 아니라, 자기 문제에 필요한 3~4개만 정확히 구현한 하네스가 production에 간다.

사실 이 블로그를 굴리는 파이프라인 자체가 작은 하네스다.

주제를 뽑는 `daily-blog`, 글을 쓰는 `blog-writer`, 트렌드 장표를 만드는 `daily-trend`가 스킬 체이닝으로 연결돼 있고, `CLAUDE.md`가 상시 컨텍스트로 톤·금지표현·SEO 규칙을 모델에 강제한다.

모델(Claude)은 하나지만, 이 하네스가 있느냐 없느냐가 '매번 처음부터 지시하는 것'과 '한 줄 명령으로 완성본이 나오는 것'의 차이를 만든다.

하네스 엔지니어링은 대기업만의 얘기가 아니라, 1인 콘텐츠 운영자에게 이미 작동 중인 현실​이다.

세 시나리오를 관통하는 실무 원칙은 하나다.

모델을 바꾸기 전에 하네스를 의심하라.

에이전트가 느리거나 틀리면 "GPT를 Claude로 바꿔볼까"가 아니라 "툴이 너무 많지 않나, 컨텍스트가 새지 않나, 권한이 모델 판단에 맡겨져 있지 않나"를 먼저 본다.

비용 0원으로 가장 큰 개선이 나오는 곳이 거기다.

---

✍️ 마무리 — 모델은 상수, 하네스는 변수다

2026년의 현실은 분명하다.

프런티어 모델의 성능 차이는 빠르게 좁혀지는 반면, ​같은 모델을 누가 어떻게 감싸느냐의 차이는 오히려 벌어지고 있다.

Vercel은 툴을 80% 지워 실패를 성공으로 바꿨고, LangChain은 하네스만 바꿔 벤치마크 순위를 뒤집었다.

둘 다 모델은 손대지 않았다.

결론적으로

2026년 말이면 'AI를 쓰는 팀'의 경쟁력은 모델 선택이 아니라

하네스 설계 능력에서 갈린다.

더 좋은 모델을 기다리는 팀은 지고,

가진 모델을 더 잘 감싸는 팀이 이긴다.

모델은 누구나 같은 걸 쓰는 상수가 됐고, 하네스가 유일하게 통제 가능한 변수다.

그러니 다음에 에이전트가 말을 안 들으면, 모델 탓을 하기 전에 하네스를 열어보자.

툴을 빼고, 컨텍스트를 정리하고, 권한을 분리하는 것 — 돈 안 드는 이 세 가지가 대부분의 문제를 해결한다.

AI 활용

⚠️ 이 글은 특정 제품·기업에 대한 투자 권유가 아니며,

AI 엔지니어링 개념과 공개 사례를 정리한 정보성 콘텐츠입니다.

[출처] 하네스 엔지니어링이 뜬 이유 — 같은 Claude로 실패율을 0으로 만든 방법|작성자 LEO