1. OpenAI가 던진 충격, 100만 줄의 코드를 0줄로 쓰기

2026년 2월 11일, OpenAI의 Ryan Lopopolo는 Harness engineering: leveraging Codex in an agent-first world라는 글을 발표하며 새로운 흐름의 시작을 알렸습니다. 이 글이 화제가 된 이유는 단순합니다. 발표된 수치가 비현실적으로 들렸기 때문입니다.

1.1 다섯 달 동안의 실험

OpenAI 내부에서 다섯 달 동안 진행된 한 실험의 결과는 다음과 같습니다.

• 3명에서 시작해 7명으로 늘어난 소규모 팀
• 그 사이에 작성된 약 100만 줄의 코드, 그중 사람이 직접 친 코드는 0줄
• 약 1,500개의 풀 리퀘스트, 엔지니어 한 명당 하루 평균 3.5개의 PR (이후 모델 업그레이드와 함께 5~10개로 증가)
• 사람이 직접 했을 때 대비 약 1/10의 시간으로 베타 제품 출시
• 매일 약 10억 토큰(하루 토큰 비용 약 $2,000~$3,000)을 사용

요약하자면, 사람이 코드를 쓰지 않았는데도 100만 줄짜리 제품이 만들어졌다는 이야기입니다. 핵심 철학은 한 문장으로 요약됩니다.

"Humans steer. Agents execute." (인간은 방향을 잡는다. 에이전트가 실행한다.)

1.2 핵심 질문의 전환

OpenAI 팀이 이 실험에서 던진 질문은 다음과 같았습니다.

"소프트웨어 엔지니어링 팀의 주된 일이 더 이상 코드를 짜는 것이 아니라, 에이전트가 일할 환경을 설계하고, 의도를 명시하고, 피드백 루프를 만드는 것이라면 무엇이 달라지는가?"

이 발상의 전환에서 가장 중요한 부분은 에이전트가 실수했을 때의 대응 방식입니다.

"우리는 그것을 신호로 받아들입니다. 무엇이 빠져 있는가, 도구인가, 가드레일인가, 문서인가를 찾아내고 다시 채워 넣습니다."

즉, 실수한 에이전트를 야단치는 게 아니라 환경을 손본다는 접근입니다. 이 한 문장이 사실상 하네스 엔지니어링의 핵심 정신입니다.

2. 하네스 엔지니어링이란

업계에서 점차 자리잡은 정의는 단순합니다.

에이전트 = LLM + 하네스

LLM이 두뇌라면, 하네스는 두뇌가 일할 책상, 공구함, 안전 장비, 작업 절차 같은 주변 환경 전체입니다. 모델이 무엇을 할지 결정한다면, 하네스는 모델이 무엇을 볼 수 있는지, 어떤 도구를 쓸 수 있는지, 실수했을 때 어떻게 되돌아오는지를 결정합니다.

2.1 OpenAI의 5가지 핵심 원칙

OpenAI 글이 정리한 하네스 엔지니어링의 5가지 원칙은 다음과 같습니다. 이름이 어려워 보이지만 한 줄씩 풀면 이해가 됩니다.

이 5가지가 결국 한 가지를 말합니다. 에이전트 한 명을 똑똑하게 만드는 게 아니라, 에이전트가 일할 환경 전체를 똑똑하게 만들자.

3. ThoughtWorks의 분석, Birgitta Bockeler

2026년 2월 17일, OpenAI 발표 6일 뒤에 ThoughtWorks의 Distinguished Engineer Birgitta Bockeler가 Martin Fowler 사이트에 Harness Engineering, first thoughts라는 글을 올렸습니다. 그녀는 OpenAI가 제시한 하네스 구성요소를 세 가지 카테고리로 정리해 보여줬습니다.

특히 흥미로운 게 가비지 컬렉션 개념입니다. 프로그래밍 언어의 가비지 컬렉터처럼, 에이전트가 주기적으로 코드베이스를 훑으며 일관성이 깨진 곳, 안 쓰는 코드, 규칙 위반을 자동으로 찾아 치워줍니다. 사람이 시키지 않아도 청소가 일어나는 환경을 짠다는 발상입니다.

Bockeler는 이후 Harness Engineering for coding agent users라는 더 발전된 글에서, 하네스의 구성을 가이드(guides)와 센서(sensors) 라는 두 축으로 정리하기도 했습니다. 가이드는 에이전트가 행동하기 전에 방향을 주는 시스템 프롬프트와 AGENTS.md 같은 문서, 센서는 행동 뒤에 결과를 검증하는 평가 도구와 출력 파서입니다. 두 글이 합쳐지면서 하네스 엔지니어링이 단순한 키워드를 넘어 공통 어휘로 자리 잡았습니다.

3.1 Mitchell Hashimoto의 실용적 정의

HashiCorp 공동창립자이자 Terraform 창시자인 Mitchell Hashimoto는 하네스 엔지니어링을 한 문장으로 요약했습니다.

"Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."

"에이전트가 실수하는 걸 발견할 때마다, 그 실수를 다시는 못 하도록 해결책을 환경에 박아 넣는다."

핵심은 개별 실수를 손으로 고치지 않는다입니다. 그 실수가 구조적으로 일어날 수 없도록 환경을 손본다는 뜻이고, OpenAI가 말한 "신호로 받아들이고 환경을 보완한다"와 같은 정신입니다.

4. 세 시대의 종합 비교

지금까지 본 세 시대를 한 그림에 놓고 보면 진화의 방향이 분명해집니다.

5. 우리에게 의미하는 것

세 시대의 진화는 단순한 트렌드 변화가 아닙니다. 우리가 AI를 대하는 자세가 어떻게 바뀌어야 하는지 알려줍니다.

첫째, 세 기술은 대체 관계가 아니라 포함 관계입니다. 하네스 엔지니어링을 한다고 프롬프트가 폐기되는 것이 아닙니다. 오히려 좋은 프롬프트가 더 큰 시스템 안에서 정확히 작동하도록 짜이는 식입니다.

둘째, 기초가 탄탄해야 다음 단계가 작동합니다. 프롬프트를 잘 못 쓰는 사람이 컨텍스트만 잘 챙긴다고 결과가 좋아지지 않고, 컨텍스트를 잘 챙길 줄 모르는 사람이 하네스를 짠다고 자율 에이전트가 잘 굴러가지 않습니다.

셋째, 모든 사람이 모든 단계를 다 할 필요는 없습니다. 하루에 한두 번 ChatGPT를 쓰는 직장인에게 필요한 건 프롬프트입니다. 사내 위키와 AI를 연결하려는 기획자에게 필요한 건 컨텍스트입니다. AI 에이전트를 프로덕션에 배포하려는 팀에게 필요한 건 하네스입니다.

실제로 등장하고 있는 하네스 도구

하네스 엔지니어링은 이론에만 머물지 않습니다. 이미 도구 형태로 구현되어 사용자들이 직접 적용할 수 있는 단계에 들어섰습니다. 대표적인 예가 카카오 황민호 리더가 작성해 공개한 revfactory/harness입니다. Claude Code에서 동작하는 플러그인으로, "이 프로젝트용 하네스 짜줘"라고 부탁하면 도메인에 맞는 전문 에이전트 팀과 스킬을 자동으로 생성해줍니다. 현재 가장 많이 사용되는 하네스이며, 이 하네스 하나만으로도 수업을 더이상 진행하지 않아도 될 정도로 완성도가 높습니다.

이 도구는 파이프라인, 팬아웃/팬인, 전문가 풀, 생성-검증 같은 6가지 아키텍처 패턴을 지원하며, 저자가 직접 진행한 A/B 테스트(15개 작업)에서 평균 품질 점수가 49.5에서 79.3으로 약 60% 향상되었다고 보고합니다. 다만 저자 본인이 측정한 결과로, 제3자 재현은 아직 진행 중이라는 점도 README에 명시되어 있습니다. 어쨌든 같은 모델이라도 환경 설계에 따라 결과가 크게 달라진다는 OpenAI의 관찰이 도구 형태로도 재현되고 있다는 의미입니다.

다음 장부터는 이 세 가지 기술을 차례로 깊이 들어갑니다. 그 전에 이 책을 쓰는 사이에 새로 등장한 네 번째 용어인 루프 엔지니어링을 짧게 소개하고 넘어가겠습니다.