하네스 엔지니어링(Harness Engineering): 에이전트 시대의 새로운 소프트웨어 개발 패러다임
참고 자료
- Ryan Lopopolo, Harness Engineering: Leveraging Codex in an Agent-First World (OpenAI, 2026년 2월 11일)
- Birgitta Böckeler, Harness Engineering (martinfowler.com, 2026년 2월 17일)
- Daniel, Harness Engineering: The Skill That Will Define 2026 for Solo Devs (YouTube, 2026년 2월 24일)
- 기타 최신 자료 보강 (InfoQ, philschmid.de, ignorance.ai, arxiv.org, 2026년 3월 기준)
1. 하네스(Harness)라는 단어가 갑자기 등장한 이유
2026년 초, AI 소프트웨어 개발 커뮤니티에서 “하네스 엔지니어링(Harness Engineering)”이라는 용어가 급격히 부상하기 시작했다. 이 단어의 기원을 추적하면 몇 가지 흥미로운 경로가 교차한다. 먼저 Mitchell Hashimoto가 자신의 블로그에서 AI 코딩 워크플로에서 에이전트를 제어하는 일련의 도구와 관행을 “하네스(harness)”라고 표현했고, 그 직후 OpenAI의 기술 스태프 멤버 Ryan Lopopolo가 2026년 2월 11일 “하네스 엔지니어링: 에이전트 우선 세계에서 Codex 활용하기”라는 제목의 블로그 포스트를 발행했다. 아이러니하게도 그 글에서 “harness”라는 단어는 본문에 단 한 번만 등장한다. 그럼에도 불구하고 Thoughtworks의 Distinguished Engineer이자 AI 보조 개발 전문가인 Birgitta Böckeler가 같은 달 17일 Martin Fowler의 사이트에서 이 용어를 본격적으로 이론화하며 개념의 틀을 잡아주었다.
“하네스”라는 단어는 본래 말(horse)을 다루기 위한 장구(마구)를 의미한다. 고삐, 안장, 재갈 등 강력하지만 방향성이 없는 동물의 힘을 올바른 방향으로 이끌기 위한 장비 일체를 가리킨다. AI 에이전트에 이 은유를 적용하면, AI 모델은 강력하지만 스스로 어디로 가야 할지 모르는 말이고, 하네스는 그 말이 올바른 방향으로 달릴 수 있도록 설계된 모든 인프라와 제약 시스템이다. Böckeler는 이 용어를 “AI 에이전트를 제어하는 데 사용하는 도구와 관행”을 기술하는 말로써 마음에 든다고 명확히 밝혔다. 이처럼 하네스 엔지니어링은 단순한 유행어가 아니라, AI 코딩 에이전트 시대가 열리면서 필연적으로 등장할 수밖에 없었던 개념이다.
2. OpenAI의 실험: 수동 코드 한 줄도 없이 백만 줄 코드베이스 구축
이 논의의 중심에는 OpenAI 팀이 실제로 수행한 극단적인 실험이 있다. 2025년 8월 말, 팀은 빈 Git 리포지터리에 첫 번째 커밋을 올리며 하나의 원칙을 세웠다. “수동으로 작성된 코드는 단 한 줄도 없다(no manually typed code at all).” 이것은 단순한 목표가 아니라 팀 전체를 다른 종류의 엔지니어링으로 강제로 밀어넣기 위한 장치였다.
5개월이 지난 시점에서 그 결과는 놀라웠다. 리포지터리에는 애플리케이션 로직, 인프라, 툴링, 문서화, 내부 개발자 유틸리티 등 다양한 영역에 걸쳐 약 백만 줄의 코드가 쌓였다. 처음 세 명의 엔지니어가 Codex 에이전트를 이끌었고, 그 기간 동안 약 1,500개의 pull request가 열리고 병합되었다. 이는 엔지니어 한 명이 하루에 평균 3.5개의 PR을 처리한 것과 같으며, 팀이 7명으로 성장한 이후에도 처리량은 지속적으로 증가했다. 이 제품은 단순히 코드를 쏟아내기 위한 출력이 아니었다. 수백 명의 내부 사용자가 매일 실제로 활용하는 제품으로서 내부 베타와 외부 알파 테스트 단계를 성공적으로 통과했다.
가장 주목할 만한 점은 초기 스캐폴드(리포지터리 구조, CI 구성, 서식 규칙, 패키지 관리자 설정, 애플리케이션 프레임워크)부터 에이전트에게 리포지터리에서 작업하는 방법을 알려주는 초기 AGENTS.md 파일까지, 모든 것이 처음부터 Codex에 의해 작성되었다는 것이다. 사람이 만들어둔 코드가 전혀 없는 상태에서 시작한 것이다. 이 실험이 의미하는 바는 단순히 “AI가 코드를 잘 쓴다”가 아니다. “AI 에이전트가 대규모 소프트웨어를 안정적으로 유지관리하게 만드는 것이 가능하다”는 것이다. 그리고 그것을 가능하게 한 핵심은 모델 자체의 역량이 아니라, 에이전트를 둘러싼 환경, 즉 하네스였다.
3. 엔지니어의 역할이 어떻게 바뀌었는가
이 실험에서 가장 혁명적인 변화는 소프트웨어 엔지니어가 하는 일의 본질이 바뀌었다는 것이다. 사람이 직접 코드를 작성하는 대신, 엔지니어들은 완전히 다른 종류의 작업에 집중해야 했다. 시스템을 설계하고, 의도를 명시하며, 에이전트가 안정적인 작업을 수행할 수 있도록 피드백 루프를 구축하는 것이 핵심 업무가 되었다.
OpenAI 팀이 직접 고백하듯, 초기 진행 속도는 예상보다 훨씬 더뎠다. 그것이 Codex의 역량 부족 때문이 아니었다는 점이 중요하다. 환경이 제대로 갖춰져 있지 않았기 때문이었다. 에이전트가 상위 목표를 달성하기 위한 도구, 추상화, 내부 구조가 부족했던 것이다. 결국 엔지니어들의 주요 업무는 “에이전트가 유용한 업무를 수행할 수 있도록 지원하는 것”으로 바뀌었다. 실패했을 때 “더욱 열심히 하라”는 식으로 에이전트를 몰아붙이는 것으로는 문제를 해결할 수 없었다. 대신 엔지니어들은 항상 이 질문을 던졌다. “어떤 기능이 누락되어 있으며, 에이전트가 읽기 쉽고 실행 가능하게 만들려면 어떻게 해야 할까?”
사람은 거의 전적으로 프롬프트를 통해 시스템과 상호작용한다. 엔지니어가 작업을 설명하고, 에이전트를 실행하고, pull request를 열도록 허용한다. PR 완료를 위해 Codex에게는 자체적으로 변경사항을 검토하고, 로컬과 클라우드 양쪽에서 에이전트 리뷰를 요청하고, 피드백에 응답하며, 모든 에이전트 리뷰어가 만족할 때까지 반복하도록 지시한다. 이것이 사실상 Ralph Wiggum Loop라 불리는 에이전트 자기 검증 루프다. Codex는 사람이 CLI에 일일이 복사하여 붙여넣지 않아도 GitHub CLI(gh), 로컬 스크립트, 리포지터리 내장 스킬 같은 표준 개발 도구를 직접 사용하여 컨텍스트를 수집한다.
시간이 지나면서 거의 모든 리뷰 작업이 에이전트 간에 처리되도록 전환되었다. 하나의 Codex 실행이 6시간 이상 지속되는 경우도 많으며, 종종 개발자가 자는 동안 에이전트가 홀로 작업을 이어나간다.
4. 하네스의 세 가지 핵심 구성 요소
Birgitta Böckeler는 OpenAI 팀의 하네스 구성 요소를 분석하여 세 가지 카테고리로 체계화했다. 이것은 결정론적 접근과 LLM 기반 접근이 혼합된 형태로, 서로 다른 역할을 맡으며 전체 시스템의 신뢰성을 만들어낸다.
4-1. 컨텍스트 엔지니어링(Context Engineering)
컨텍스트 관리는 에이전트가 크고 복잡한 작업을 효과적으로 수행하는 데 있어 가장 큰 과제 중 하나다. OpenAI 팀이 초기에 배운 핵심 교훈은 단순하면서도 강력했다. “Codex에게 1,000페이지의 설명서가 아닌 지도(map)를 제공해야 한다.”
처음에는 “하나의 거대한 AGENTS.md” 접근 방식을 시도했지만 예측 가능한 방식으로 실패했다. 거대한 지침 파일은 컨텍스트라는 희소 자원을 낭비했고, 에이전트는 주요 제약 조건을 놓치거나 잘못된 제약 조건에 최적화되기 시작했다. 모든 것이 “중요”하면 정작 중요한 것은 아무것도 없다는 원칙이 여기서도 작동했다. 게다가 거대한 단일 매뉴얼은 금세 낡은 규칙들의 무덤으로 변했다.
그 대신 팀은 AGENTS.md를 백과사전이 아닌 목차로 취급하는 방향으로 전환했다. 약 100줄 남짓의 짧은 AGENTS.md가 컨텍스트에 삽입되어 주로 지도 역할을 하며, 실제 깊이 있는 정보는 구조화된 docs/ 디렉터리에 있는 별도 문서들이 담당한다. 이 지식 베이스는 기록 시스템(system of record)으로 취급된다.
특히 중요한 것은 동적 컨텍스트다. 팀은 git worktree별로 앱을 부팅할 수 있게 하여 Codex가 변경사항마다 하나의 인스턴스를 실행하고 제어할 수 있도록 했다. Chrome DevTools Protocol을 에이전트 런타임에 연결하고 DOM 스냅샷, 스크린샷, 탐색 작업을 위한 스킬을 만들어, Codex가 버그를 직접 재현하고 수정사항을 검증하며 UI 동작에 대해 직접 추론할 수 있게 했다. 관측 가능성(observability) 측면에서도 로그, 메트릭, 추적이 각 워크트리에 대해 일시적으로 유지되는 로컬 스택을 통해 에이전트에 노출된다. 에이전트는 LogQL로 로그를 쿼리하고 PromQL로 메트릭을 쿼리할 수 있다. 이런 환경이 갖춰지면 “서비스 시작이 800ms 이내에 완료”되도록 하거나 “이 네 가지 핵심 사용자 여정에서 어떤 스팬도 2초를 초과하지 않도록”이라는 식의 구체적인 프롬프트가 실행 가능해진다.
에이전트 관점에서 보면 실행 중에 컨텍스트 내에서 액세스할 수 없는 것은 사실상 존재하지 않는 것과 같다. Google Docs, Slack 스레드, 또는 사람들의 머릿속에 있는 지식은 에이전트 시스템 입장에서는 없는 것이다. 리포지터리 내의 버전 관리되는 아티팩트, 즉 코드, 마크다운, 스키마, 실행 계획에만 접근할 수 있다. 이 사실이 팀으로 하여금 모든 아키텍처 결정, 팀 문화, 운영 원칙을 리포지터리 내에 마크다운으로 문서화하도록 강제했다.
4-2. 아키텍처 제약(Architectural Constraints)
문서화만으로는 에이전트가 생성한 코드베이스를 완전히 일관되게 유지할 수 없다. OpenAI 팀은 구현을 세세하게 관리하는 대신 불변 조건(invariants)을 강제 적용하는 방식을 선택했다.
핵심은 엄격한 아키텍처 모델이다. 각 비즈니스 도메인은 엄격하게 검증된 의존성 방향과 제한된 허용 엣지 집합을 사용하여 고정된 계층 집합으로 나뉜다. 의존성은 Types → Config → Repo → Service → Runtime → UI 순서로만 흐를 수 있으며, 인증, 커넥터, 텔레메트리, 기능 플래그 같은 횡단 관심사(cross-cutting concerns)는 오직 Providers라는 하나의 명시적 인터페이스를 통해서만 유입된다. 그 외의 모든 의존성 패턴은 허용되지 않으며, 이것은 기계적으로 강제된다.
이러한 제약의 실행은 두 가지 방식으로 이루어진다. 첫째, Codex가 직접 작성한 맞춤형 린터(custom linter)가 구조화된 로깅, 스키마 및 유형의 명명 규칙, 파일 크기 제한, 플랫폼별 안정성 요구사항을 정적으로 검사한다. 맞춤형 린터이기 때문에 에러 메시지 자체에 수정 지침을 담아 에이전트 컨텍스트에 주입할 수 있다는 장점이 있다. 둘째, 구조적 테스트(structural tests)가 의존성 레이어 위반 여부를 검증한다.
Böckeler는 이 점에서 중요한 통찰을 제시한다. 이러한 종류의 아키텍처 규율은 보통 수백 명의 엔지니어가 확보될 때까지 미루는 경우가 많다. 그러나 코딩 에이전트에게는 이것이 초기 전제 조건이다. 제약 조건이 있어야만 아키텍처 드리프트 없이 속도를 낼 수 있기 때문이다. 사람 중심의 워크플로에서는 이런 규칙들이 지나치게 세세하거나 제한적으로 느껴질 수 있다. 하지만 에이전트를 사용하면 이 효과를 몇 배로 늘릴 수 있다. 일단 인코딩되면 한 번에 어디에나 적용된다.
4-3. 가비지 컬렉션(Garbage Collection)
에이전트의 완전한 자율성은 새로운 문제를 야기한다. Codex는 리포지터리에 이미 존재하는 패턴을, 심지어 최적 상태가 아닌 패턴도 복제하는 경향이 있다. 따라서 시간이 지나면 필연적으로 드리프트(drift)가 발생하며, 코드베이스의 일관성이 서서히 무너진다.
초기에 OpenAI 팀은 이 문제를 수동으로 처리했다. 매주 금요일, 팀 전체 시간의 20%를 “AI 슬럼프”를 정리하는 데 썼다. 예상대로 그 방식은 확장되지 않았다. 대신 팀은 “황금 원칙(golden principles)”을 리포지터리에 직접 인코딩하고, 이를 주기적으로 검증하는 정기적인 정리 프로세스를 구축했다. 예를 들어, 불변 조건을 중앙에서 관리하기 위해 직접 만든 헬퍼보다 공유 유틸리티 패키지를 선호하는 원칙, 그리고 경계를 검증하거나 타입이 지정된 SDK에 의존하여 에이전트가 실수로 잘못된 형태를 기반으로 구축하지 못하도록 하는 원칙 등이 그것이다.
정기적으로 편차를 검사하고, 품질 등급을 업데이트하며, 대상 리팩터링 pull request를 생성하는 Codex 백그라운드 작업도 운영된다. “doc-gardening” 에이전트가 실제 코드 동작을 반영하지 않는 오래되거나 더 이상 유효하지 않은 문서화를 검토하여 수정용 pull request를 열기도 한다. 이것은 가비지 컬렉션처럼 작동한다. 기술 부채를 마치 고금리 대출처럼 다루어, 이자가 쌓여 한꺼번에 갚는 고통을 피하고 조금씩 꾸준히 갚아나가는 방식이다.
5. 모델이 아니라 하네스가 병목이다: 실증적 증거들
YouTube 채널 Crafter’s Lab의 Daniel이 소개한 데이터와 사례들은 이 논점을 강렬하게 뒷받침한다. 핵심 주장은 하나다. 에이전트가 실패하는 이유는 모델이 멍청해서가 아니라, 모델을 둘러싼 하네스가 제대로 설계되어 있지 않기 때문이다.
5-1. Epics 에이전트 벤치마크: 최고의 모델도 24%밖에 못 한다
연구자들이 발표한 Epics 에이전트 벤치마크는 기존 벤치마크들과 근본적으로 다르다. 코딩 퍼즐이나 객관식 문제가 아니라, 컨설턴트, 변호사, 분석가가 실제 업무에서 수행하는 작업들을 테스트한다. 각 작업을 완료하는 데 사람이 보통 1~2시간 걸린다.
모든 주요 프론티어 모델을 이 벤치마크에서 실행한 결과, 가장 성능이 좋은 모델조차 과제를 약 24% 완료했다. 4번 중 1번 정도만 성공한 것이다. 같은 모델로 8번 시도해도 약 40%까지밖에 오르지 않았다. 이 모델들이 다른 벤치마크에서 90% 이상을 기록하는 것들이라는 점을 상기하면, 기존 벤치마크가 실제 작업 수행 능력과는 괴리가 크다는 것을 알 수 있다.
연구자들이 실패 원인을 분석한 결과, 문제는 모델의 지능이 아니었다. 모델들은 충분한 지식을 보유하고 있었고 문제를 추론하는 능력도 있었다. 실패는 거의 전적으로 실행과 오케스트레이션 문제였다. 에이전트는 너무 많은 단계를 거치면서 길을 잃었고, 이미 실패한 접근법을 반복했으며, 그 과정에서 처음에 무엇을 해야 했는지를 잊어버렸다. 이것이 바로 하네스의 문제다.
5-2. Vercel의 역설: 도구를 80% 줄였더니 정확도가 100%가 되다
Vercel이 구축한 텍스트-to-SQL 에이전트 사례는 더욱 강렬한 역설을 보여준다. 처음에 팀은 대부분의 개발자들이 에이전트를 만드는 방식으로 시스템을 구축했다. 데이터베이스 스키마 이해용 도구, 쿼리 작성 도구, 결과 검증 도구, 그리고 그것을 감싸는 오류 처리 로직까지 갖추었다. 이 시스템은 약 80%의 정확도를 보였다.
그런 다음 팀은 다소 급진적인 시도를 했다. 도구의 80%를 제거했다. bash 명령 실행, 파일 읽기, grep과 cat 같은 표준 커맨드라인 도구들, 즉 실제 개발자가 사용하는 기본적인 도구만 남겼다. 결과는 놀라웠다. 정확도가 80%에서 100%로 향상되었고, 토큰 사용량은 40% 줄었으며, 속도는 3.5배 빨라졌다. 이 실험을 진행한 엔지니어는 다음과 같이 말했다. “모델은 점점 똑똑해지고 컨텍스트 창은 점점 커지고 있습니다. 그렇다면 최고의 에이전트 아키텍처는 아키텍처가 거의 없는 것일지도 모릅니다.”
이 결과는 직관에 반하지만 논리적으로 이해할 수 있다. 특화된 도구들이 모델을 돕는 게 아니라 방해하고 있었던 것이다. 모델은 어떤 도구를 언제 써야 할지 결정하는 것 자체에 인지적 부하가 걸렸고, 그 과정에서 실수가 발생했다. 단순한 도구 세트를 주었을 때 모델의 고유한 추론 능력이 더 잘 발휘되었다.
5-3. Manus의 다섯 번 재작성: 단순화할수록 더 나아졌다
Meta가 인수한 AI 회사 Manus의 사례도 같은 교훈을 가리킨다. 이 팀은 6개월 동안 에이전트 프레임워크를 무려 다섯 번 전면 재작성했다. 같은 모델을 사용했다. 다섯 가지 아키텍처를 시도했다. 그리고 재작성할 때마다 성능이 향상되었다. 모델은 변하지 않았다. 하네스가 변한 것이다.
Manus가 발견한 가장 큰 성능 향상은 기능을 추가하는 데서 오지 않았다. 기능을 제거하는 데서 왔다. 복잡한 문서 검색 시스템을 제거했고, 복잡한 라우팅 로직을 없앴으며, 관리 에이전트를 단순한 구조화된 핸드오프로 대체했다. 반복할수록 시스템은 단순해졌고 더 나아졌다.
특히 중요한 발견이 있었다. Manus의 에이전트는 작업당 평균 약 50번의 도구 호출을 한다. 엄청난 단계 수다. 거대한 컨텍스트 창을 기술적으로 지원하는 모델이라도, 어느 시점을 넘어서면 성능이 저하되기 시작한다. 모델이 갑자기 모든 것을 잊는 게 아니라, 초기에 주어진 중요한 지침이 수백 개의 중간 결과물 아래 묻혀버리는 것이다. Manus의 해결책은 단순했다. 파일 시스템을 모델의 외부 메모리로 활용하는 것이다. 컨텍스트 창에 모든 것을 욱여넣는 대신, 에이전트가 핵심 정보를 파일에 기록하고 필요할 때 다시 읽는다. Claude Code의 claude.md 파일, 할 일 목록, 진행 상황 추적이 바로 이 패턴이 실제로 작동하는 모습이다.
6. 세 가지 주요 에이전트 시스템의 하네스 철학 비교
세계 최고의 에이전트 시스템들은 서로 완전히 다른 방향에서 출발했지만, 결국 같은 장소에 도달했다.
OpenAI Codex의 접근 방식은 계층화된 구조다. 계획을 수립하는 오케스트레이터, 개별 작업을 처리하는 실행자, 실패를 감지하고 복구하는 레이어로 구성된다. 작업을 맡기고 자리를 떠나도 된다는 신뢰도가 높다.
Anthropic Claude Code는 최소주의 철학을 극단까지 밀어붙였다. 핵심 도구는 단 네 가지다. 파일 읽기, 파일 쓰기, 파일 편집, bash 명령 실행. 대부분의 지능이 모델 자체에 담겨 있고, 하네스는 최소한으로 유지된다. 확장성이 필요할 때는 MCP와 에이전트가 필요에 따라 습득하는 스킬을 통해 제공된다. Anthropic은 Claude Agent SDK를 “일반 목적 에이전트 하네스”로 명시적으로 정의하고 있으며, 대화 기록의 자동 압축 같은 내장 컨텍스트 관리 기능을 포함한다.
Manus는 “축소-오프로드-격리(Reduce-Offload-Isolate)” 전략에 도달했다. 컨텍스트를 능동적으로 줄이고, 파일 시스템을 메모리로 활용하며, 무거운 작업은 서브 에이전트에게 위임하고 요약만 받아온다.
세 접근 방식이 완전히 다르지만, 이들이 도달한 핵심 인사이트는 동일하다. 하네스가 모델보다 더 중요하다.
7. Birgitta Böckeler의 더 넓은 시각: 하네스가 불러올 미래
Böckeler는 단순히 OpenAI의 사례를 정리하는 것을 넘어, 하네스 엔지니어링이 소프트웨어 산업 전체에 미칠 파급효과를 여러 가설로 제시한다.
하네스가 미래의 서비스 템플릿이 될 것인가? 대부분의 조직은 두세 가지의 주요 기술 스택만 사용한다. 모든 애플리케이션이 독자적인 구조를 가지지는 않는다. Böckeler는 미래에 팀이 일반적인 애플리케이션 토폴로지를 위한 하네스 세트 중에서 선택하여 시작하는 날이 올 수 있다고 상상한다. 오늘날의 서비스 템플릿이 새로운 서비스를 “황금 경로”에 따라 인스턴스화하는 데 도움을 주는 것처럼, 맞춤형 린터, 구조적 테스트, 기본 컨텍스트 문서, 추가 컨텍스트 공급자를 갖춘 하네스가 새로운 서비스 템플릿이 될 수 있다.
더 많은 AI 자율성을 위해 런타임을 제약해야 한다는 역설. 초기 AI 코딩 열기는 LLM이 무한한 유연성을 제공한다고 가정했다. 어떤 언어로든, 어떤 패턴으로든, 제약 없이 생성할 수 있다는 것이었다. 하지만 하네스 엔지니어링의 실천 결과는 반대를 가리킨다. 신뢰할 수 있고 유지관리 가능한 AI 생성 코드를 위해서는 해결 공간을 제약해야 한다. 특정 아키텍처 패턴, 강제된 경계, 표준화된 구조가 필요하다는 것이다. “무엇이든 생성한다”는 유연성을 포기하는 대신, 기술적 구체성으로 가득 찬 규칙과 하네스를 얻는 교환이다.
더 적은 수의 기술 스택과 토폴로지로의 수렴. 코딩이 코드를 직접 타이핑하는 것에서 생성을 조종하는 것으로 변화하면서, AI는 우리를 더 적은 수의 기술 스택으로 몰아갈 수 있다. 프레임워크와 SDK의 사용성은 여전히 중요하다. 사람에게 좋은 것이 AI에게도 좋다는 사실이 반복적으로 증명되고 있기 때문이다. 하지만 개발자 취향은 예전만큼 중요하지 않게 될 것이다. 인터페이스의 작은 비효율성이나 독특함은, 우리가 그것을 직접 다루지 않게 되면서 덜 성가신 것이 될 것이다. 우리는 좋은 하네스가 있는 스택을 선택하고 “AI 친화성”을 우선시하게 될 것이다.
기존 코드베이스와 새로운 코드베이스 사이의 단절. AI 자율성을 극한까지 올릴 수 있는 좋은 하네스 기법이 개발된다면, 그 기법 중 어느 것이 기존 애플리케이션에 적용 가능하고, 어느 것은 처음부터 하네스를 염두에 두고 구축된 애플리케이션에만 작동할까? 오래된 코드베이스에 하네스를 소급 적용하는 것은, 정적 코드 분석 도구를 한 번도 사용한 적 없는 코드베이스에 처음 적용할 때 수많은 경보에 압도되는 것과 비슷한 경험이 될 수 있다.
8. 리처드 서튼의 “쓴 교훈”과 하네스의 미래 방향
강화학습의 창시자 중 한 명인 리처드 서튼(Richard Sutton)의 “쓴 교훈(The Bitter Lesson)”은 이 논의에 중요한 시사점을 준다. 핵심 주장은 컴퓨팅과 함께 확장되는 접근 방식이 항상 수작업으로 설계된 지식에 의존하는 접근 방식을 결국 이긴다는 것이다.
이것을 하네스 엔지니어링에 적용하면 구체적인 의미가 생긴다. 모델이 더 똑똑해짐에 따라, 하네스는 더 단순해져야지 더 복잡해져서는 안 된다. 모델 업그레이드마다 수작업으로 코딩한 로직과 커스텀 파이프라인을 추가하고 있다면, 흐름을 거슬러 수영하는 것이다. 그 과잉 엔지니어링이 오히려 에이전트를 계속 망가뜨리는 원인일 가능성이 높다.
이것은 LangChain이 실증적으로 증명한 바이기도 하다. 모델은 전혀 변경하지 않고 하네스 아키텍처만 개선함으로써 Terminal Bench 2.0에서 52.8%에서 66.5%로 성능을 올리고 상위 30위에서 상위 5위로 뛰어올랐다.
9. 실무자를 위한 현재의 하네스 구축 원칙
이러한 논의를 종합하면, 오늘 당장 적용할 수 있는 실무적 원칙들이 도출된다.
첫째, Vercel 실험을 직접 해보라. 에이전트 설정이 있다면 벗겨내라. 특화된 도구를 제거하고, bash 터미널과 기본 파일 접근만 남기고 무슨 일이 일어나는지 보라. 모델은 당신이 그것을 위해 구축한 도구 파이프라인보다 이미 더 똑똑할 가능성이 높다.
둘째, 진행 상황 파일을 추가하라. 에이전트가 각 단계 이후 업데이트하는 실시간 할 일 목록을 유지하게 하라. 각 행동의 시작에 파일을 읽고 끝에 쓰게 하라. Claude Code가 마크다운 파일로 하는 것이 정확히 이 패턴이고, Manus가 다섯 번의 전면 재작성 끝에 도달한 것도 같은 패턴이다.
셋째, MCP와 스킬을 배우기 시작하라. 이것들은 모델이 외부 도구와 협력하는 깨끗하고 표준화된 방법을 제공한다. 모든 통합을 하드코딩할 필요 없이 확장성이 생긴다.
넷째, 아키텍처 제약을 조기에 설정하라. 에이전트가 수백 명의 엔지니어 규모에서나 적용하는 아키텍처 규율을 요구한다는 사실을 받아들이고, 초기부터 의존성 방향, 모듈 경계, 명명 규칙을 기계적으로 강제하는 린터와 구조적 테스트를 구축하라.
다섯째, 엔트로피와 싸우는 자동화된 가비지 컬렉션을 만들라. 주기적으로 코드베이스를 검사하고 낡은 패턴을 찾아내어 리팩터링 PR을 여는 백그라운드 에이전트를 운영하라. 기술 부채는 조금씩 꾸준히 갚는 것이 훨씬 낫다.
10. 비판적 시각: 무엇이 여전히 빠져 있는가
Böckeler는 OpenAI의 글에서 중요한 공백 하나를 지적한다. 모든 설명된 조치들이 장기적인 내부 품질과 유지관리성을 높이는 데 초점을 맞추고 있다는 점에서는 인상적이지만, 기능과 행동의 검증(verification of functionality and behaviour)이 빠져 있다. 코드가 아키텍처적으로 일관성 있고 문서가 최신 상태이며 모듈 경계가 지켜진다는 것을 보장하는 것과, 그 코드가 실제로 사용자가 기대하는 대로 작동한다는 것을 보장하는 것은 다른 문제다.
또한 OpenAI는 이 실험의 성공을 대외적으로 설명할 때 분명한 이해충돌이 있다. 자사의 Codex 제품에 대한 신뢰를 높이는 것이 회사의 이해관계와 일치하기 때문이다. 이 점을 감안하고 이 사례를 평가해야 한다.
11. 결론: 2026년은 하네스의 해
2025년이 에이전트(agents)의 해였다면, 2026년은 하네스(harnesses)의 해라는 것이 이 분야의 공통된 전망이다. 같은 모델이 Claude Code, Cursor, Codex에서 완전히 다른 방식으로 작동한다는 사실이 이것을 방증한다. 차이를 만드는 것은 모델이 아니라 하네스다.
소프트웨어를 구축하는 데는 여전히 규율이 필요하다. 하지만 그 규율은 코드보다 스캐폴딩에서 더 많이 드러나게 되었다. 코드베이스의 일관성을 유지하는 툴링, 추상화, 피드백 루프가 점점 더 중요한 엔지니어링 자산이 되고 있다. OpenAI 팀의 마지막 말이 이것을 잘 요약한다. “현재 우리의 가장 어려운 과제는 에이전트가 복잡하고 안정적인 소프트웨어를 대규모로 구축하고 유지관리하는 데 도움이 되는 환경, 피드백 루프, 제어 시스템을 설계하는 것입니다.”
모델 경쟁의 소음에 흔들리지 말고, 하네스를 구축하라. 그것이 2026년에 실질적인 경쟁 우위가 생기는 곳이다. 그리고 하네스를 더 잘 구축하는 것은 다음 모델 출시를 기다리지 않고도 오늘 당장 시작할 수 있는 일이다.
작성 일자: 2026-03-09