하네스 엔지니어링(Harness Engineering)

🏷️ 정보 Headliner

결론부터 말하면

2026년 2월, AI 에이전트 분야에서 새로운 키워드가 등장했습니다. 하네스 엔지니어링(Harness Engineering). 모델을 바꾸지 않고도, 모델을 둘러싼 시스템만 바꿔서 성능을 끌어올리는 방법입니다.

LangChain은 GPT-5.2-Codex를 그대로 두고 하네스만 개선해서 Terminal Bench 2.0에서 30위권 밖에서 5위권으로 올라갔습니다. 13.7포인트 상승. Can Bölük은 편집 포맷 하나만 바꿔서 Grok Code Fast 1의 점수를 6.7%에서 68.3%로 10배 끌어올렸습니다. 모델 가중치는 건드리지 않았습니다.

엔지니어의 역할이 코드를 쓰는 사람에서, 에이전트가 코드를 잘 쓸 수 있는 환경을 설계하는 사람으로 바뀌고 있습니다.

하네스란 무엇인가

하네스(Harness)의 원래 뜻은 말에 채우는 마구(馬具)입니다. 고삐, 안장, 재갈 같은 장비 일체를 말합니다. 강력하지만 어디로 갈지 모르는 동물을 원하는 방향으로 이끄는 도구라는 비유입니다.

AI 에이전트 맥락에서 하네스는 모델 자체를 제외한 모든 것을 의미합니다. 시스템 프롬프트, 도구 선택, 실행 흐름, 피드백 루프, 아키텍처 제약, 린터, CI 파이프라인, 프로젝트 지침 파일(AGENTS.md, CLAUDE.md 같은 것들) 등이 모두 하네스의 구성요소입니다.

LangChain의 정의가 깔끔합니다. "모델이 아닌 모든 코드, 설정, 실행 로직이 하네스다." 모델은 지능을 담고 있고, 하네스는 그 지능을 쓸모있게 만드는 시스템입니다.

용어의 탄생과 확산

"하네스"라는 표현 자체는 새로운 게 아닙니다. 소프트웨어 엔지니어링에서 "테스트 하네스", "평가 하네스"는 오래된 용어입니다. EleutherAI의 Language Model Evaluation Harness는 2020년부터 쓰이고 있었죠.

하지만 "하네스 엔지니어링"이라는 이름이 결정적으로 굳어진 건 2026년 2월입니다. 타임라인을 정리하면 이렇습니다.

불과 2주 만에 개인 블로그에서 업계 공식 용어로 자리 잡은 겁니다.

프롬프트 → 컨텍스트 → 하네스: 진화의 흐름

세 개념의 관계를 이해하면 하네스 엔지니어링의 위치가 명확해집니다.

프롬프트 엔지니어링 (2023~2024)

한 번의 질문, 한 번의 답변 구조에서 지시를 최적화하는 방법입니다. "잘 물어보면 잘 대답한다"는 접근이죠. 범위가 단일 추론 호출에 한정됩니다.

컨텍스트 엔지니어링 (2025 중반~)

Andrej Karpathy가 주목을 끌고, LangChain과 Anthropic이 공식적으로 정의하면서 부상했습니다. RAG, MCP, 메모리 등을 활용한 시스템 수준의 컨텍스트 설계입니다. "LLM에 주입되는 모든 토큰의 설계와 관리"가 범위입니다.

하네스 엔지니어링 (2026년 2월~)

컨텍스트 엔지니어링의 범위를 넘어, LLM "바깥"에서 설계해야 하는 모든 것을 포함합니다. 린터, CI 파이프라인, 병렬 에이전트 간 충돌 방지, 아키텍처 제약의 기계적 강제, 엔트로피 관리 등입니다.

중요한 건, 이 세 가지가 대체 관계가 아니라 포함 관계라는 점입니다. 하네스 엔지니어링 안에 컨텍스트 엔지니어링이 있고, 컨텍스트 엔지니어링 안에 프롬프트 엔지니어링이 있습니다. 각각의 영역이 계속 유효하면서, 더 넓은 범위로 확장된 것입니다.

핵심 사례

사례 1: OpenAI Codex — 수동 코드 0줄로 100만 줄 생성

OpenAI Codex 팀은 2025년 8월부터 약 5개월간 실험을 진행했습니다.

핵심 교훈은 몇 가지로 요약됩니다.

첫째, 리포지토리 자체가 진실의 원천이어야 합니다. 에이전트 관점에서 컨텍스트 윈도우 안에서 접근할 수 없는 정보는 존재하지 않는 것과 같습니다. Slack 토론이나 사람 머릿속에 있는 아키텍처 결정? 에이전트에겐 없는 것과 마찬가지입니다. 처음에는 팀이 매주 금요일(근무 시간의 20%)을 "AI 슬롭 정리"에 썼는데, 이건 당연히 확장이 안 됐습니다. 대신 "골든 프린시플"을 리포지토리에 직접 인코딩하고, 주기적으로 위반 사항을 스캔하는 백그라운드 Codex 태스크를 만들었습니다.

둘째, 엄격한 아키텍처 제약이 속도를 만듭니다. 고정된 레이어 시퀀스와 의존성 방향을 린터와 구조적 테스트로 기계적으로 강제했습니다. 보통 엔지니어 수백 명이 되어야 도입하는 수준의 아키텍처 규칙을 에이전트 개발에서는 초기 필수 조건으로 넣은 겁니다. 역설적이지만, 제약이 엄격할수록 에이전트의 출력은 더 안정적이었습니다.

셋째, AGENTS.md는 백과사전이 아니라 목차여야 합니다. 거대한 하나의 지침 파일은 컨텍스트를 잡아먹어서 실패합니다. 대신 작은 AGENTS.md가 더 깊은 진실의 원천(설계 문서, 아키텍처 맵, 실행 계획, 품질 등급)을 가리키는 구조가 효과적이었습니다.

사례 2: Can Bölük의 Hashline 실험 — 편집 포맷 하나의 힘

2026년 2월, 보안 연구자 Can Bölük이 발표한 실험은 하네스의 힘을 가장 극적으로 보여줍니다.

기존 코딩 에이전트들이 사용하는 편집 포맷은 크게 두 가지였습니다.

Bölük이 제안한 Hashline은 각 줄에 2~3자리 해시를 붙이는 방식입니다.

1:a3|function hello() {
2:f1|  return "world";
3:0e|}

"2:f1번 줄을 교체하라"고 말하면 되니, 모델이 정확한 문자열을 재현할 필요가 없습니다.

결과는 극적이었습니다. 16개 모델, 3가지 편집 도구로 테스트한 결과:

Bölük의 표현이 인상적입니다. "모델이 불안정한 게 아니라, 자기 표현이 불안정한 것이다. 착륙 장치 탓을 조종사에게 돌리고 있는 셈이다."

벤치마크 비용은 약 300달러. 학습 컴퓨트 비용은 0. 이 정도 수치는 대부분의 모델 업그레이드가 가져오는 개선폭보다 큽니다.

사례 3: LangChain — 30위권 밖에서 5위권으로

LangChain은 코딩 에이전트 deepagents-cli의 하네스만 개선해서 Terminal Bench 2.0에서 52.8%에서 66.5%로 13.7포인트를 끌어올렸습니다. 모델은 GPT-5.2-Codex로 고정했습니다.

최적화 대상은 세 가지였습니다.

1. 시스템 프롬프트: 자기 검증(self-verification) 루프를 강조했습니다. 에이전트가 코드를 쓰고, 자기 코드를 다시 읽고, "괜찮아 보인다"며 멈추는 패턴이 가장 흔한 실패 모드였습니다. 원래 스펙 대비 검증하도록 프롬프트를 바꾸니 확연히 달라졌습니다.

2. 도구와 컨텍스트 주입: LocalContextMiddleware가 에이전트 시작 시 작업 디렉토리를 매핑하고 사용 가능한 도구(Python 설치 등)를 찾아 주입합니다. 에이전트가 환경을 파악하느라 헤매는 시간과 오류를 크게 줄였습니다.

3. 미들웨어: LoopDetectionMiddleware가 파일 편집을 추적해서, 같은 코드를 반복적으로 미세 수정하는 "둠 루프"를 감지하고 접근 방식을 재고하도록 유도합니다. 시간 예산 경고도 주입해서, 에이전트가 끝없이 반복하는 대신 마무리와 검증에 집중하도록 했습니다.

흥미로운 발견도 있었습니다. 추론 예산을 최대(xhigh)로 설정하면 오히려 점수가 53.9%로 떨어졌습니다. 타임아웃 때문입니다. high 설정에서 63.6%가 나왔습니다. 더 많이 생각한다고 항상 좋은 건 아니라는 뜻이죠.

사례 4: Anthropic — 장기 실행 에이전트를 위한 이중 에이전트 하네스

Anthropic은 2025년 11월에 발표한 연구에서 장기 실행 에이전트의 핵심 문제를 정면으로 다뤘습니다. 문제는 이렇습니다: 에이전트는 이산적인 세션으로 작동하고, 새 세션은 이전 세션의 기억 없이 시작합니다. 교대 근무에서 매번 새 엔지니어가 이전 근무자의 기억 없이 출근하는 상황과 같습니다.

Claude Agent SDK에 컨텍스트 관리 기능(컴팩션 등)이 있어서 이론적으로는 무한히 작업할 수 있어야 합니다. 하지만 현실은 달랐습니다. 단순히 "claude.ai 클론을 만들어라" 같은 고수준 프롬프트로는 Opus 4.5조차 프로덕션 품질의 웹앱을 만들지 못했습니다.

실패 패턴은 두 가지였습니다.

  1. 원샷 시도: 한 번에 너무 많은 것을 하려다 컨텍스트가 고갈됨
  2. 조기 완료 선언: 프로젝트가 끝나지 않았는데 완료라고 판단

해결책은 이중 에이전트 구조였습니다.

핵심 통찰은 인간 엔지니어의 행동에서 영감을 얻었다는 점입니다. 새 컨텍스트 윈도우에서 작업 상태를 빠르게 파악할 수 있게 하는 것, git 히스토리와 진행 파일을 통해 이전 세션의 맥락을 전달하는 것. 이것이 하네스의 역할입니다.

하네스의 구성요소

여러 사례를 종합하면, 하네스의 핵심 구성요소는 네 가지로 정리됩니다.

1. 프로젝트 지침 파일 (AGENTS.md, CLAUDE.md 등)

에이전트가 작업 시작 시 읽는 문서입니다. 프로젝트 구조, 코딩 규칙, 네이밍 컨벤션 등을 담습니다. OpenAI는 이것이 "기록 시스템(system of record)" 역할을 해야 한다고 강조합니다.

Mitchell Hashimoto의 핵심 원칙: 에이전트가 실수할 때마다 그 실수를 방지하는 규칙을 추가하라. Ghostty의 AGENTS.md에서 각 줄은 과거의 구체적인 에이전트 실패에 대응합니다. 한 번 쓰고 잊는 문서가 아니라, 실패에서 학습하는 피드백 루프입니다.

2. 아키텍처 제약

의존성 방향, 파일 크기 제한, 네이밍 규칙 등을 커스텀 린터와 구조적 테스트로 기계적으로 강제합니다. LLM 기반 에이전트만으로 모니터링하는 게 아니라, 결정론적(deterministic)인 도구가 함께 작동합니다.

3. 피드백 루프와 검증

에이전트가 자기 작업을 검증하도록 하는 메커니즘입니다. 테스트 실행, 린터 결과 피드백, 자가 리뷰 루프 등이 포함됩니다. LangChain의 경우 LangSmith 트레이싱으로 에이전트의 모든 행동을 기록하고, 실패 모드를 체계적으로 분석해서 하네스를 개선했습니다.

4. 가비지 컬렉션

주기적으로 실행되면서 문서의 비일관성이나 아키텍처 제약 위반을 찾아내는 에이전트입니다. Martin Fowler의 분류에 따르면, 이것은 시간이 지남에 따라 발생하는 엔트로피와 부패(decay)에 맞서는 메커니즘입니다. OpenAI의 경우 백그라운드 Codex 태스크가 정기적으로 코드베이스를 스캔하고, 대부분 1분 이내에 리뷰할 수 있는 리팩토링 PR을 열었습니다.

하네스 엔지니어링의 실천적 시작점

개인 프로젝트나 팀 프로젝트에서 하네스 엔지니어링을 시작하려면 어떻게 해야 할까요? 여러 사례에서 공통적으로 나타나는 실천 방법을 정리합니다.

  1. AGENTS.md(또는 CLAUDE.md) 만들기: 프로젝트 컨벤션, 금지 패턴, 테스트 절차를 문서화합니다. 에이전트가 실수할 때마다 즉시 업데이트합니다.
  2. pre-commit 훅 점검하기: 린터, 포매터, 타입 체크가 로컬에서 실행되는지 확인합니다. CI에서만 돌리면 에이전트에게 즉각적인 피드백이 안 됩니다.
  3. 테스트 커버리지에 투자하기: 테스트는 에이전트가 자기 작업의 정확성을 검증하는 기반입니다. 테스트 없이는 에이전트가 스스로 검증할 수 없습니다.
  4. 아키텍처 제약을 기계적으로 강제하기: 커스텀 린터나 스크립트로 의존성 방향, 파일 크기 제한, 네이밍 규칙을 자동 검증합니다.
  5. 점진적 커밋 강제하기: "완료"될 때까지 기다리지 말고, 각 작업 단위가 완료될 때마다 체크포인트를 만듭니다.

비판적 고찰

용어의 수명에 대한 의문

하네스 엔지니어링이라는 용어가 겨우 몇 주 된 개념이라는 점은 인식할 필요가 있습니다. Martin Fowler조차 "글 본문에서는 'harness'가 한 번만 등장한다. Mitchell Hashimoto의 블로그에서 영감을 받은 사후적 명명일 수 있다"고 지적했습니다. 용어 자체가 살아남을지는 아직 불확실합니다.

다만, 용어가 사라지더라도 문제의식 자체는 유효할 것 같습니다. "컨텍스트 설계만으로는 커버할 수 없는, 에이전트 시스템의 제약·피드백·개선 설계 영역"이라는 인식은 이미 자리를 잡았습니다.

비유의 한계

"하네스"라는 비유에 대한 건설적인 비판도 있습니다. 이 비유는 인간이 통제하고 AI가 실행한다는 깔끔한 분리를 전제합니다. 하지만 에이전트가 점점 더 자율적으로 판단하는 상황에서, "마구를 채운 말" 비유가 적절한가에 대한 의문은 제기될 수 있습니다.

또한 이 비유는 "모델에서 유용한 작업을 추출하되, 그 과정에서 사용자 자신은 변하지 않는다"는 전제를 갖고 있습니다. 하지만 실제로 AI 도구를 깊이 사용하면 개발자의 사고방식과 기술 스택 선호도가 바뀌기도 합니다. Mitchell Hashimoto도 인정했듯이, 위임한 영역에서는 스킬을 쌓지 못하는 트레이드오프가 있습니다.

사례의 편향

현재까지 가장 극적인 사례들은 대부분 코딩 에이전트 영역에 집중되어 있습니다. 코딩은 검증이 비교적 명확한 도메인입니다. 테스트를 통과하는가, 린터를 통과하는가 같은 기계적 검증이 가능하죠. 과학 연구, 금융 모델링, 창작 같은 영역에서 하네스 엔지니어링이 같은 수준의 효과를 낼 수 있을지는 아직 검증되지 않았습니다.

모델의 진화와 하네스의 미래

모델이 계획, 자기 검증, 장기 일관성을 네이티브로 더 잘 해내게 되면 하네스의 중요성이 줄어들 수 있습니다. LangChain도 "하네스에 있던 것 중 일부는 모델에 흡수될 것"이라고 인정합니다. 하지만 프롬프트 엔지니어링이 여전히 유효하듯, 하네스 엔지니어링도 한동안은 유효할 것으로 보입니다.

Rich Sutton의 "쓴 교훈(Bitter Lesson)"을 떠올리게 합니다. 범용적인 계산 방법이 수작업 지식을 매번 이깁니다. 하네스에 너무 많은 "스마트한 로직"을 넣으면, 다음 모델 업데이트에서 시스템이 깨질 수 있습니다. 하네스는 가벼워야 합니다.

정리

하네스 엔지니어링의 핵심 메시지는 의외로 단순합니다. "어떤 모델을 쓰느냐"보다 "그 모델을 어떤 시스템 안에서 작동하게 하느냐"가 더 중요할 수 있다.

이건 AI 에이전트에만 해당되는 이야기가 아닙니다. 어떤 강력한 도구든, 그 도구가 작동하는 환경과 제약의 설계가 결과를 결정합니다. 하네스 엔지니어링은 그 오래된 교훈의 AI 에이전트 버전이라고 할 수 있습니다.

용어가 살아남을지는 모르겠지만, "모델보다 시스템"이라는 인식의 전환은 이미 일어났습니다. 그리고 그 전환이 데이터로 뒷받침되고 있다는 점에서, 단순한 유행어가 아니라 실질적인 엔지니어링 방향이 될 가능성이 높습니다.

참고 자료