하네스 엔지니어링, AI 에이전트의 진짜 레버

"메일 발송 기능 만들어줘"라고 AI에게 시켰더니, SMTP 설정부터 재시도 로직까지 포함된 거대한 시스템이 돌아온 경험 없으세요? 동작은 하는데 원했던 건 함수 하나였거든요. 더 좋은 프롬프트, 더 정교한 컨텍스트, 더 똑똑한 모델로 바꿔봐도 같은 문제가 반복돼요. 2025년 후반부터 업계가 도달한 결론은 이거예요. 문제는 모델이 아니라 모델을 감싸는 구조라는 것. 그 구조에 하네스 엔지니어링(Harness Engineering)이라는 이름이 붙었어요.

하네스 엔지니어링이란 무엇인가요?

하네스(harness)는 원래 말에게 씌우는 마구예요. 강력한 힘을 가진 말이 마차를 끌려면 그 힘을 올바른 방향으로 전달하는 마구가 필요하잖아요. 마구 없는 말의 힘은 쓸모없는 원시 에너지에 불과합니다. AI 에이전트도 마찬가지예요.

이 개념을 공식 담론으로 끌어올린 건 OpenAI입니다. 2025년 11월 공개된 「Harness engineering: leveraging Codex in an agent-first world」에서 핵심 공식이 제시됐어요. Agent = Model + Harness. 모델이 지능을 제공한다면 하네스는 제어를 제공하며, 하네스란 모델을 제외한 모든 것 — 도구 접근 제어, 가드레일, 피드백 루프, 메모리, 오케스트레이션 로직, AGENTS.md 같은 프로젝트 지침 파일까지 — 을 의미해요.

OpenAI Codex 팀은 어떻게 코드 0줄로 100만 줄을 만들었을까?

OpenAI 내부에서 2025년 8월 말 빈 git 저장소에서 시작된 실험이에요. 3명에서 7명으로 늘어난 작은 팀이 5개월간 Codex만으로 내부 베타 제품을 만들었고, 약 1,500개의 PR이 머지되었으며 코드 규모는 약 100만 줄에 달했어요. 핵심 원칙은 단 하나, 수동으로 작성된 코드 0줄이었습니다(OpenAI, 2025-11).

이게 가능했던 이유는 더 좋은 모델 덕분이 아니에요. 그들이 만든 건 코드가 아니라 환경이었거든요. 맞춤형 린터, 구조 테스트, 계층화된 아키텍처를 기계적으로 강제하는 도구, 그리고 정기적으로 코드베이스를 스캔해 오래된 패턴을 정리하는 "doc-gardening 에이전트"까지. 흥미로운 점은 이 도구들 역시 Codex가 직접 작성했다는 거예요.

OpenAI는 이 경험을 이렇게 요약해요. "Humans steer. Agents execute." — 인간은 방향을 잡고, 에이전트는 실행한다. 엔지니어의 역할이 재정의된 거예요. 코드를 직접 쓰는 게 아니라 에이전트가 신뢰할 수 있게 일할 수 있는 환경과 피드백 루프를 설계하는 것이 새로운 업무가 됐어요.

가이드와 센서 — 마틴 파울러의 프레임워크

이 흐름을 체계적으로 정리한 사람은 마틴 파울러예요. 「Harness engineering for coding agent users」에서 그는 하네스의 구성 요소를 두 축으로 나눠요.

가이드(Guides, Feedforward Controls)는 에이전트가 행동하기 전에 올바른 방향으로 유도하는 메커니즘이에요. CLAUDE.md, AGENTS.md 같은 프로젝트 지침 파일이 대표적이죠. "요청하지 않은 리팩토링 금지", "snake_case 사용", "새 패키지 추가 전 사용자 확인 필수" — 이런 규칙들이 첫 번째 행동부터 방향을 잡아줘요. 목적은 단순해요. 첫 시도부터 좋은 결과가 나올 확률을 높이는 것.

센서(Sensors, Feedback Controls)는 에이전트가 행동한 후 자동으로 수정을 돕는 메커니즘이에요. 린터, 타입 체커, 테스트 러너가 대표적인 센서이고, 에이전트가 코드를 생성하면 센서가 즉시 검증해서 문제가 인간의 눈에 도달하기 전에 교정되는 구조예요.

파울러는 센서를 다시 두 종류로 구분해요. 계산적(computational) 센서는 결정론적이고 밀리초 단위로 실행되며 비용이 낮아서 모든 변경마다 돌릴 수 있어요. 추론적(inferential) 센서는 AI 기반이라 느리고 비싸지만, "이 코드가 프로젝트의 설계 의도에 맞는가?" 같은 의미론적 검증을 수행해요. 좋은 하네스는 이 둘을 계층적으로 배치합니다. 빠르고 싼 계산적 센서로 기본 품질을 확보하고, 느리지만 깊은 추론적 센서로 의미적 일관성을 검증하는 식이에요.

같은 모델인데 13.7점이 올랐다고요? — LangChain 사례

하네스가 진짜 레버라는 걸 가장 극적으로 보여준 건 LangChain이에요. 코딩 에이전트 벤치마크인 Terminal Bench 2.0에서 자체 에이전트 deepagents-cli를 Top 30 밖에서 Top 5로 끌어올렸거든요. 점수로는 52.8%에서 66.5%로 13.7점 상승. 모델은 gpt-5.2-codex로 고정한 채 하네스만 바꾼 결과예요(LangChain, 2026).

그들이 조정한 건 시스템 프롬프트, 도구, 그리고 미들웨어(모델·도구 호출 주변의 훅) 세 가지였어요. 특히 효과적이었던 변경은 자기 검증(self-verification) 루프의 도입이었습니다. 에이전트는 코드를 작성한 뒤 자기 코드를 다시 읽고 "괜찮아 보인다"며 끝내는 경향이 있는데, PreCompletionChecklistMiddleware로 에이전트가 종료 전 반드시 작업 명세에 대해 검증 패스를 돌리도록 강제했어요. 또한 LoopDetectionMiddleware로 같은 파일에 반복 편집이 발생하면 접근 방식을 재고하라고 알려서 "doom loop"을 차단했고요.

Stripe Minions는 피드백을 어떻게 왼쪽으로 옮겼을까?

Stripe의 Minions 팀도 같은 결론에 도달했어요. 그들이 채택한 전략은 "피드백을 왼쪽으로 이동(shift feedback left)" — 가능한 한 빨리, 가능한 한 자동으로 에이전트의 출력을 검증한다는 의미예요.

구체적으로 Stripe는 pre-push 훅으로 가장 흔한 lint 이슈를 자동 수정하고, 백그라운드 데몬으로 lint 규칙 휴리스틱을 미리 계산해뒀어요. 에이전트가 CI에 잘못된 코드를 push하고 → CI 에러를 읽고 → 다시 고치는 비효율적인 루프를 피하는 게 핵심이거든요. 또한 블루프린트(blueprint)라는 워크플로 프리미티브로 결정론적 노드("린터 실행", "변경 사항 push")와 에이전트 노드("태스크 구현", "CI 실패 수정")를 혼합해서, 예측 가능한 작업은 LLM을 거치지 않고 코드로 처리해요(Stripe Engineering, 2026-02-19).

그 결과 Stripe는 주당 약 1,300개의 AI 작성 PR을 머지하는 수준에 도달했어요. 인간이 작성한 코드는 0줄이고, 인간은 리뷰만 합니다.

"Harness"라는 단어에 담긴 두 가지 의미

"Harness"는 명사로는 마구(馬具)이지만, 동사로는 "힘을 유용하게 활용하다"라는 뜻이에요. "Harness solar energy" — 태양 에너지를 활용하다. 이 동사적 의미가 하네스 엔지니어링의 본질을 정확히 담고 있어요.

전기 하네스(wire harness)는 수백 개의 전선을 묶어 올바른 신호가 올바른 장치에 전달되도록 경로를 구조화하고, 안전 하네스(safety harness)는 작업자가 자유롭게 움직이되 치명적 영역에 진입하면 잡아줘요. 테스트 하네스(test harness)는 코드를 격리된 환경에서 실행하고 입력을 넣고 출력을 검증하고요. 모든 하네스의 공통점은 명확해요. 어떤 하네스도 힘 자체를 만들지 않는다는 것. 힘은 이미 존재하고, 하네스는 그것을 유용하게 만드는 구조일 뿐이에요.

GPT, Claude, Gemini — 2026년 현재 프론티어 모델의 코드 생성 능력은 이미 놀라울 정도로 강력해요. 그러나 그 지능이 프로젝트의 목적지에 도달하려면 방향을 잡아주는 가이드와 이탈을 교정하는 센서가 필요해요. LangChain의 13.7점 점프, OpenAI Codex 팀의 100만 줄 코드, Stripe의 주 1,300 PR — 이 사례들이 가리키는 건 하나예요. 진짜 레버는 모델이 아니라 하네스에 있다는 것. AI 에이전트의 결과물이 만족스럽지 않다면, 모델을 바꾸기 전에 먼저 이 질문을 해보세요. "내 에이전트에게는 어떤 가이드가 주어져 있는가? 어떤 센서가 출력을 검증하고 있는가?" 하네스 엔지니어링의 최신 트렌드와 AI 활용 인사이트는 휴미즈에서 확인할 수 있어요.

자주 묻는 질문 (FAQ)

하네스 엔지니어링이란 무엇인가요?

AI 에이전트에서 모델을 제외한 모든 제어 구조 — 도구 접근 제어, 가드레일, 피드백 루프, 메모리, 오케스트레이션 로직, 프로젝트 지침 파일 등 — 를 설계하고 최적화하는 엔지니어링 분야입니다. OpenAI가 2025년 11월 공식 용어로 제시했으며, Agent = Model + Harness라는 공식으로 정의됩니다(OpenAI, 2025-11).

가이드(Guides)와 센서(Sensors)는 어떻게 다른가요?

가이드(Feedforward Controls)는 에이전트가 행동하기 전에 방향을 잡아주는 메커니즘으로, AGENTS.md 같은 지침 파일이 대표적입니다. 센서(Feedback Controls)는 에이전트가 행동한 후 자동으로 검증하고 수정을 돕는 메커니즘으로, 린터·타입 체커·테스트 러너 등이 해당합니다. 마틴 파울러는 센서를 다시 계산적(결정론적, 빠름)과 추론적(AI 기반, 의미론적)으로 구분합니다(martinfowler.com).

하네스만 바꿔도 AI 에이전트 성능이 달라지나요?

네. LangChain은 모델을 gpt-5.2-codex로 고정한 채 시스템 프롬프트, 도구, 미들웨어만 조정해서 Terminal Bench 2.0 점수를 52.8%에서 66.5%로 13.7점 끌어올렸습니다. 자기 검증 루프(PreCompletionChecklistMiddleware)와 반복 편집 감지(LoopDetectionMiddleware)가 핵심 변경이었습니다(LangChain, 2026).

하네스 엔지니어링과 프롬프트 엔지니어링은 어떻게 다른가요?

프롬프트 엔지니어링은 모델에 전달하는 입력 텍스트를 최적화하는 데 집중하지만, 하네스 엔지니어링은 프롬프트를 포함해 도구 접근 제어, 자동 검증 루프, 아키텍처 강제, 메모리, 오케스트레이션 로직 등 에이전트를 둘러싼 전체 시스템을 설계합니다. 프롬프트는 하네스의 한 구성 요소(가이드)에 해당합니다.

하네스 엔지니어링을 시작하려면 무엇부터 해야 하나요?

먼저 가이드를 정비하세요. AGENTS.md나 CLAUDE.md에 코딩 컨벤션, 금지 규칙, 기술 스택을 명시하면 에이전트의 첫 시도 품질이 높아집니다. 다음으로 센서를 배치하세요. 린터, 타입 체커, 테스트 러너를 에이전트 워크플로에 통합해 출력을 자동 검증하게 하면 됩니다. Stripe처럼 pre-push 훅으로 피드백을 왼쪽으로 옮기는 것도 효과적입니다.

이 글은 기업 데이터 관리 및 AI 트렌드 전문 기업 휴미즈가 공개된 외부 보도와 공식 문서를 기반으로 작성했습니다. 인용된 수치와 사례는 각 출처 기준이며, 실제 환경에 따라 결과가 다를 수 있습니다.

댓글