하네스 엔지니어링이란 — 말(馬)과 AI의 공통점

하네스(Harness)는 원래 말을 통제하기 위해 장착하는 고삐·안장·줄 등의 장비를 뜻합니다. 아무리 빠른 말도 하네스 없이는 수레를 끌지 못하는 것처럼, 아무리 뛰어난 AI 모델도 실행 환경이 갖춰지지 않으면 복잡한 실무 작업을 끝까지 완수하지 못합니다. 하네스 엔지니어링은 AI 에이전트가 효율적으로 작업할 수 있도록 도구, 메모리, 피드백 루프, 제약 조건 등을 설계하고 구축하는 엔지니어링 분야입니다.

OpenAI는 2026년 2월 11일 공식 블로그에 “하네스 엔지니어링: 에이전트 우선 세계에서 Codex 활용하기”를 발표하면서 이 개념을 처음 공식화했습니다. (출처: OpenAI 공식 블로그, 2026.02.11) 앞으로 개발자의 주된 역할은 코드를 직접 작성하는 것이 아니라, AI가 일을 제대로 할 수 있는 환경을 설계하는 것으로 이동한다는 주장입니다.

조선일보(2026.03.16)도 이를 보도하며 앤트로픽의 시각을 함께 소개했는데, 앤트로픽 측은 “AI 에이전트가 실패하는 흔한 이유는 덜 똑똑해서가 아니라 도구를 제대로 사용하지 못하거나 긴 작업에서 목표를 잃어버려서”라고 했습니다. 모델 성능보다 환경 설계가 먼저라는 뜻입니다.

100만 줄 실험의 공식 수치 — 진짜 숫자만 추렸습니다

OpenAI 공식 문서에 직접 나온 수치만 정리했습니다. 2025년 8월 말 빈 저장소에서 시작해, 수동으로 작성한 코드 한 줄 없이 다음 결과가 나왔습니다. (출처: openai.com/harness-engineering, 2026.02.11)

1인당 하루 3.5건의 PR은 일반적인 시니어 개발자가 코드를 직접 작성할 때 가능한 수준보다 수 배 높습니다. 팀 규모가 3명에서 7명으로 늘었을 때 처리량이 줄지 않고 오히려 늘었다는 점이 더 흥미롭습니다. 보통 팀이 커지면 커뮤니케이션 비용이 늘어 개인 생산성이 떨어지는데, 에이전트 중심 체계에서는 이 관계가 역전됩니다.

초반이 느렸던 이유 — 모델 탓이 아니었습니다

OpenAI 공식 문서에는 이렇게 나옵니다. “초기 진행이 예상보다 느렸던 것은 Codex의 능력 부족 때문이 아니라, 환경 명세가 부족했기 때문이었다(the environment was underspecified).” (출처: openai.com/index/harness-engineering, 2026.02.11) AI가 작업을 완수하려면 목표만 주어지면 되는 게 아닙니다. 도구, 추상화 구조, 내부 레이아웃이 먼저 갖춰져야 합니다.

뭔가 실패했을 때 팀의 접근 방식이 특이했습니다. “더 열심히 해봐”가 아니라 “어떤 능력이 빠져 있고, 에이전트가 인식할 수 있는 형태로 어떻게 만들 수 있나?”를 질문했습니다. 실패를 모델 한계가 아닌 환경 설계 문제로 봤다는 뜻입니다. 이 프레임 하나가 팀의 속도를 결정했습니다.

실제로 팀이 한 일의 대부분은 코드 작성이 아니라 에이전트가 인식할 수 있는 구조 만들기였습니다. Chrome DevTools Protocol을 에이전트 런타임에 연결하고, 로그·메트릭·트레이스를 에이전트가 직접 조회할 수 있게 만들고, 서비스 부팅을 git worktree 단위로 격리했습니다. 800ms 안에 서비스를 기동하라는 프롬프트가 실행 가능해진 건 이 구조가 완성된 다음이었습니다.

AGENTS.md가 두꺼울수록 AI가 느려지는 구조

보통 AI 에이전트를 처음 써보면 AGENTS.md(또는 CLAUDE.md, .cursorrules 등)를 최대한 빼곡히 채우고 싶어집니다. 더 많이 알수록 더 잘할 거라는 직관 때문입니다. OpenAI 팀이 이 직관을 직접 부숴준 대목이 있습니다.

대신 팀이 채택한 구조는 AGENTS.md를 목차로만 쓰는 것이었습니다. 100줄 이내의 짧은 진입점에는 더 깊은 정보가 어디 있는지 포인터만 담고, 실제 지식은 구조화된 docs/ 디렉터리에 분산 보관했습니다. 에이전트가 압도당하지 않고도 필요한 정보를 점진적으로 꺼내 쓸 수 있는 구조, 이것이 팀이 말하는 “점진적 공개(progressive disclosure)”입니다.

이 원칙은 사람 신입사원 온보딩과 놀랍도록 닮아 있습니다. 첫날에 회사 전체 프로세스 매뉴얼 500페이지를 건네면 아무것도 흡수하지 못합니다. 핵심 원칙 몇 가지와 “자세한 건 여기 있어”라는 지도를 주는 게 훨씬 효과적입니다.

금요일의 20% — AI 슬롭 청소가 왜 스케일 안 됐나

에이전트가 코드 전체를 생산하면 새로운 문제가 생깁니다. 에이전트는 이미 저장소에 존재하는 패턴을 그대로 복제합니다. 좋은 패턴뿐 아니라 불완전한 패턴까지. 팀은 이것을 “AI 슬롭(AI slop)”이라고 불렀습니다. OpenAI 공식 문서에는 이런 문장이 나옵니다. “우리 팀은 매주 금요일(주간의 20%)을 AI가 만든 엉망진창을 청소하는 데 썼다. 당연히 이것은 스케일되지 않았다(that didn’t scale).” (출처: openai.com/index/harness-engineering, 2026.02.11)

주 1회 사람이 직접 청소하는 방식은 사람 시간을 비선형으로 잡아먹었습니다. 팀이 선택한 해법은 황금 원칙(golden principles)을 저장소에 직접 인코딩하고, 배경에서 상시 실행되는 Codex 작업이 품질 이탈을 탐지해 자동으로 PR을 여는 구조였습니다. 기술 부채를 한 번에 몰아서 갚는 대신, 매일 조금씩 계속 갚는 가비지 컬렉션 개념을 코드베이스에 도입한 것입니다.

이 대목은 하네스 엔지니어링이 “AI에게 일 시키기”로 끝나는 게 아님을 보여줍니다. 에이전트가 오래 실행될수록 코드베이스가 일관성을 잃어갈 수 있고, 그것을 막는 것 역시 하네스 설계의 일부입니다. 사람이 개입하는 빈도를 줄이면서도 품질을 유지하려면 청소 역할 자체를 또 다른 에이전트에게 위임해야 합니다.

앤트로픽도 같은 말을 했습니다 — 실패 원인의 공통점

OpenAI만의 시각이 아닙니다. 앤트로픽도 공식 입장으로 “에이전트가 실패하는 가장 흔한 이유는 모델이 덜 똑똑해서가 아니라, 도구를 제대로 사용하지 못하거나 긴 작업에서 목표를 잃어버리기 때문”이라고 밝혔습니다. (출처: 조선일보, 2026.03.16 — 앤트로픽 공식 입장 인용) 두 회사가 서로 독립적으로 같은 진단을 내린 셈입니다.

여기서 주목할 만한 지점이 있습니다. 개발자 커뮤니티에서 Reddit 스레드 등을 통해 확인되는 하네스 관련 실패 경험들을 보면, 공통적으로 “하네스를 만들기 전에 에이전트에게 너무 많은 걸 기대했다”는 패턴이 반복됩니다. 에이전트 품질을 모델 선택의 문제로만 접근할 때 발생하는 오류입니다.

흥미로운 건 앤트로픽이 서드파티 하네스 도구에 대해 민감한 입장을 가진다는 점입니다. 2026년 1~2월에 Claude Max를 서드파티 하네스(Roo Code, OpenCode 등)로 접속하던 계정들이 정책 위반으로 제한된 사례가 보고됐고, 앤트로픽은 “맞춤형 에이전트 하네스” 영역에 대해 별도 가이드라인을 명확히 공개하지 않은 상태입니다. 직접 API를 쓰는 경우와 서비스를 통한 경우의 하네스 설계는 접근 방식이 달라야 한다는 점을 염두에 둘 필요가 있습니다.

Q&A — 자주 묻는 5가지

마치며 — 하네스가 모델보다 먼저입니다

OpenAI의 실험이 증명한 건 “AI가 코드를 잘 짠다”가 아닙니다. 잘 설계된 환경이 있을 때 AI가 코드를 잘 짠다는 것입니다. 초반이 느렸던 것도, AGENTS.md가 두꺼울수록 역효과가 났던 것도, 금요일 청소가 스케일되지 않았던 것도 모두 환경 설계 문제였습니다.

솔직히 말하면, 하네스 엔지니어링이라는 개념 자체가 아직 성숙하지 않았습니다. OpenAI도 “몇 년간 완전 에이전트 생성 시스템에서 아키텍처 일관성이 어떻게 진화하는지는 아직 모른다”고 공식 문서에 적었습니다. 지금은 초기 성과를 보고한 것이지, 검증이 끝난 방법론이 아닙니다. 그래서 이 접근법을 도입하려면 공식 사례만 보는 게 아니라 저장소 구조, 피드백 루프, 품질 자동화 각각에 얼마나 투자할 수 있는지를 먼저 따져봐야 합니다.

그럼에도 방향 자체는 분명합니다. 앞으로 개발자의 경쟁력은 코드 작성 속도가 아니라, 에이전트가 안전하게 달릴 수 있는 레일을 얼마나 잘 깔 수 있느냐에서 갈릴 것 같습니다.

📎 본 포스팅 참고 자료

1. OpenAI 공식 블로그 — 하네스 엔지니어링: 에이전트 우선 세계에서 Codex 활용하기 (2026.02.11)
   https://openai.com/ko-KR/index/harness-engineering/
2. OpenAI 공식 블로그 — Codex App Server 공개 (2026.02.04)
   https://openai.com/ko-KR/index/unlocking-the-codex-harness/
3. 조선일보 — “AI가 100% 코딩하는 시대, 사람 역할은 하네스 엔지니어링” (2026.03.16)
   https://www.chosun.com/economy/tech_it/2026/03/16/N6DM6IKF7NFHHCVB7OMSSDUWBU/
4. OpenAI Codex 공식 페이지
   https://openai.com/codex/