OpenAI는 인간이 단 한 줄의 코드도 작성하지 않는 내부 제품을 구축하는 데 5개월을 소비했으며, 해당 팀의 엔지니어들은 그 어느 때보다 바빴습니다. 약 100만 줄의 코드가 1,500개 이상의 풀 리퀘스트 (pull requests)를 통해 배포되었으며, 그 모든 과정은 에이전트 (agents)에 의해 작성, 검토 및 병합되었습니다. 작업이 사라진 것은 아니었습니다. 그것은 팀이 '하네스 (harness)'라고 부르는 무언가로 이동했습니다. 그리고 그 후 4개월 동안, 이 아이디어는 내부적인 습관에서 공식적인 규율로 그 궤적을 완성했습니다. 이제 에이전트는 단지 모델에 하네스를 더한 것에 불과하며, 하네스가 바로 당신이 엔지니어링해야 하는 부분이라는 전제를 가진 오픈 소스 프레임워크 AutoHarness가 존재합니다.

테스트해 볼 가치가 있는 주장은 다음과 같습니다: 에이전트로부터 프로덕션급 (production-grade) 결과물을 얻어내는 빌더들을 구분 짓는 것은 그들이 선택한 모델이나 작성한 프롬프트 (prompts)가 아닙니다. 그것은 그들이 에이전트 주변의 환경을 구축했는지 여부입니다. 그리고 이 주장 안에는 훨씬 더 중요한 두 번째 주장이 숨어 있습니다. 왜냐하면 하네스는 그 강력한 능력에도 불구하고, 스스로 가장 중요한 입력값을 생성할 수는 없기 때문입니다.

Harness Engineering의 실체

이 용어에는 정확한 기원 이야기가 있습니다. Terraform과 Vagrant의 제작자인 Mitchell Hashimoto는 2026년 2월 초 자신의 AI 도입 여정에서, 에이전트 사용이 더 이상 좌절감을 주지 않고 복리로 작용하기 시작하는 단계로서 이 관행을 설명했습니다:

에이전트가 실수를 하는 것을 발견할 때마다, 에이전트가 다시는 그 실수를 하지 않도록 솔루션을 엔지니어링하는 데 시간을 투자하십시오.

Mitchell Hashimoto, "My AI Adoption Journey"

6일 후, OpenAI는 이 분야에 공식 명칭을 부여했습니다. Ryan Lopopolo의 포스트는 그들의 에이전트 우선(agent-first) 팀이 어떻게 운영되는지 설명했습니다. 엔지니어는 코드를 작성하는 것이 아니라, 에이전트가 궤도를 벗어나지 않도록 유지하는 구조, 문서화, 그리고 자동화된 체크(automated checks)를 구축합니다. 이 포스트의 핵심 원칙은 네 단어로 요약됩니다: 인간은 조종하고, 에이전트는 실행한다(humans steer, agents execute). 이 비유는 의도적입니다. Harness(하네스/마구)는 본래 의미로, 강력한 동물의 힘을 유용한 방향으로 유도하는 장비를 뜻합니다. 하네스 자체가 말을 더 강하게 만드는 것은 아닙니다. 그 힘이 어딘가로 향하게 만들 뿐입니다.

따라서 작동 가능한 정의를 내리자면 다음과 같습니다: 하네스 엔지니어링(harness engineering)은 AI 코딩 에이전트 주변의 환경, 즉 에이전트가 읽는 컨텍스트(context), 호출할 수 있는 도구(tools), 그리고 에이전트의 출력을 포착하는 체크(checks)를 설계하는 관행입니다. 이를 통해 에이전트가 그럴듯한(plausible) 결과가 아닌 올바른(right) 결과를 생성하도록 합니다. 에이전트의 가공되지 않은 능력(raw capability)은 모델 제공업체로부터 빌려온 것이며, 이는 다른 모든 사람이 빌려 쓰는 것과 동일한 능력입니다. 하네스는 당신이 소유하는 부분입니다.

하네스의 구성 요소

martinfowler.com에서 이 주제에 대해 가장 엄격한 논문을 작성한 Birgitta Böckeler는 하네스를 모델 자체를 제외한 에이전트 내의 모든 것으로 정의하며, 그 구성 요소를 두 가지 계열로 분류합니다. 가이드(Guides)는 에이전트가 행동하기 전에 작동합니다: 당신의 컨벤션(conventions)을 담은 AGENTS.md 파일, 아키텍처 노트(architecture notes), 작동 환경을 설정하는 부트스트랩 스크립트(bootstrap scripts) 등이 이에 해당합니다. 센서(Sensors)는 행동 후에 작동합니다: 린터(linters), 타입 체커(type checkers), 테스트 스위트(test suites), 그리고 출력물을 검사하여 문제를 다시 피드백하는 리뷰 에이전트(review agents)가 있습니다.

이 전체 관행은 끊임없이 적용되는 단 하나의 동작으로 귀결됩니다. 에이전트가 무언가 잘못했을 때, 채팅창에서 이를 수정하지 마십시오. 향후 모든 실행 시에 적용될 수 있는 곳에 그 수정 사항을 인코딩(encode)하십시오.

그 차이는 나란히 놓고 보면 쉽게 알 수 있습니다. 채팅 수정(Chat correction)의 경우, "아니요, 생(raw) Date()를 쓰지 말고 우리의 날짜 헬퍼(date helper)를 사용하세요"라고 말하면 에이전트가 따르지만, 그 지식은 세션이 종료되는 순간 증발합니다. Harness 수정(Harness correction)의 경우, 생 Date()를 플래그(flag)하는 린트 규칙(lint rule) 하나와 AGENTS.md에 해당 헬퍼를 설명하는 한 줄을 추가하면, 향후 어떤 세션에서도 에이전트가 그 실수를 다시 저지르지 않습니다. 첫 번째는 대화(conversation)이지만, 두 번째는 자산(asset)입니다. 최상위 에이전트 엔지니어(agentic engineers)는 자신의 리포지토리(repo)에 8개월 동안 축적된 수정 사항들을 보유하고 있으며, 이것이 바로 그들의 에이전트는 기이할 정도로 신뢰할 수 있는 반면 당신의 에이전트는 건망증이 심해 보이는 이유입니다. 동일한 모델(model)이지만, Harness가 다를 뿐입니다.

flowchart LR
    S[수락 기준이 포함된 명세(Spec)] --> A[에이전트 실행(Agent run)]
    G[가이드: AGENTS.md, 컨벤션(conventions), 스크립트(scripts)] --> A
...

Harness는 '어떻게(how)'를 제어합니다. '무엇을(what)' 할지는 결정할 수 없습니다.

이제 Harness 설명가들이 생략하는 부분, 그리고 위 다이어그램이 왜 그 지점에서 시작하는지에 대한 이유를 살펴보겠습니다. Harness의 모든 구성 요소는 한 가지 속성을 공유합니다. 바로 누군가가 이미 기록해 둔 표준(standard)에 따라 에이전트의 출력(output)을 평가한다는 점입니다. 린터(linter)는 당신의 포맷팅 규칙을 알고 있습니다. 타입 체커(type checker)는 당신의 인터페이스(interface)를 알고 있습니다. 테스트 스위트(test suite)는 누군가가 지정한 동작(behavior)을 알고 있습니다. Harness에 모호한 목표를 입력하면, Harness는 에이전트가 깨끗한 타입(types), 스스로 작성한 통과된 테스트, 그리고 유지된 컨벤션(conventions)을 갖춘 채로 '잘못된 것'을 '올바르게' 만들도록 기꺼이 도와줄 것입니다.

Böckeler는 정확히 이 한계점에 도달하며, 그녀의 결론은 당신의 노력을 어디에 쏟아야 할지를 바꿔놓을 재정의(reframe)를 제시합니다:

좋은 Harness는 반드시 인간의 입력을 완전히 제거하는 것을 목표로 삼아서는 안 되며, 우리의 입력이 가장 중요한 곳으로 입력을 유도하는 것을 목표로 삼아야 합니다.

Birgitta Böckeler, "Harness engineering for coding agent users"

당신의 입력이 가장 중요한 곳은 어디일까요? 린트 규칙 (lint rules)이 아닙니다. 에이전트가 그것들을 초안할 수 있습니다. 테스트 스캐폴딩 (test scaffolding)도 아닙니다. 에이전트가 그것 또한 작성하며, 하네스 (harness)가 이를 검증합니다. 하네스가 생성하거나, 검증하거나, 심지어 부재를 감지조차 할 수 없는 단 하나의 입력은, 당신이 무엇을 만들고 있는지에 대한 정의와 그것이 올바른지 어떻게 알 것인지에 대한 정의입니다. 명세 (spec)가 없는 하네스는 빈 공터 주변에 세워진 스캐폴딩 (scaffolding)과 같습니다. 이것이 또한 하네스를 그 형제 격인 유행어(buzzword)와 구분 짓는 요소입니다. 루프 (loop)는 에이전트를 스케줄링하고 재실행하지만, 하네스는 각 실행을 형성하고 검증하며, 명세 (spec)는 이 둘 모두에게 '완료'가 무엇을 의미하는지 알려줍니다. 우리는 What Is Loop Engineering?에서 루프 계층 (loop layer)을 다루었습니다. 거기서의 핵심은 루프의 검증기 (verifier)에는 표준 (standard)이 필요하다는 것이었습니다. 하네스가 바로 그 검증기이며, 하네스 역시 그 표준을 절실히 필요로 합니다.

이것이 바로 BrainGrid가 채우는 간극입니다. BrainGrid는 아이디어를 당신이 신뢰할 수 있는 라이브 제품으로 만들어주는 시스템이며, 하네스에 결여된 입력값 바로 그 위치에 자리 잡고 있습니다. 당신이 평이한 언어로 기능을 설명하면, 플래닝 에이전트 (Planning Agent)가 시니어 엔지니어처럼 이를 심문하여, 엣지 케이스 (edge cases)를 드러내고 의도를 명시적인 수락 기준 (acceptance criteria)을 가진 요구사항으로 전환합니다. 그 요구사항은 하네스의 참조점 (reference point)이 됩니다. 빌드를 어떤 방식으로든 실행하십시오. 당신의 하네스 내부에서 MCP를 통해 Claude Code, Cursor, 또는 Codex에 범위가 지정된 작업 (scoped tasks)을 전달하거나, 빌더 에이전트 (Builder Agent)가 라이브 프리뷰가 포함된 관리형 샌드박스 (managed sandbox)에서 빌드하고 PR을 열도록 하십시오. 그런 다음 검증 (verification) 단계가 린터 (linter)는 결코 할 수 없는 방식으로 루프를 닫습니다. 각 수락 기준 (acceptance criterion)에 따라 결과를 확인하고, 증거가 당신이 의도한 대로 작동한다고 말할 때까지 해당 기능이 '완료' 상태에 도달하지 못하도록 붙잡아 둡니다. 코드 리뷰 (Code review)는 코드가 잘 작성되었음을 알려줍니다. 검증 (Verification)은 코드가 당신이 의도한 대로 작동함을 알려줍니다.

정직한 비용

이 분야에는 두 가지 트레이드오프 (Trade-offs)가 존재합니다. 첫째, 하네스 (Harness)는 두 번째 코드베이스입니다. Hashimoto의 규칙은 가볍게 들릴지 모르지만, 모든 실수에 대해 영구적인 해결책을 엔지니어링하는 것은 실제적이고 지속적인 작업이며, 수년간 기록되지 않은 관습이 쌓인 레거시 코드베이스 (Legacy codebase)에서는 그 보완 작업 (Backfill)의 비용이 매우 큽니다. 이것은 인프라와 같으므로, 인프라처럼 예산을 책정하십시오.

둘째, 하네스에는 한계점이 있으며, 당신은 그 위치를 알고 있어야 합니다. Böckeler의 경고는 기계 기반이든 모델 기반이든 현재의 어떤 체크 (Check)도 과제를 오해한 에이전트 (Agent)를 신뢰성 있게 잡아내지 못한다는 것입니다. 빌더 (Builders)들을 실제로 괴롭히는 실패 모드 (Failure mode)는 잘못된 형식의 코드가 아닙니다. 그것은 잘못된 문제를 해결하는 '잘 작성된 코드'입니다. 그러한 실패는 '무엇이 올바른 문제였는지'에 대한 서술된 문장을 제외한 하네스의 모든 센서 (Sensor)에 보이지 않습니다. 에이전트가 더 똑똑해질수록 이 원칙은 더욱 유효해집니다. 왜냐하면 더 유능한 에이전트는 당신의 주의력 단위당 더 많은 결과물을 만들어내며, 아무도 명시하지 않은 모든 결과물 단위는 아무도 내리지 않은 결정이기 때문입니다.

만약 당신이 오늘날 Claude Code나 Cursor를 사용하여 빌드하고 있다면, 이것이 구체적으로 의미하는 바는 다음과 같습니다: 당신의 경쟁 우위는 더 이상 프롬프트 박스 (Prompt box)에 있지 않습니다. 영리한 프롬프트를 하나 더 작성하는 데 쓰는 한 시간은, 린트 규칙 (Lint rule), AGENTS.md 항목, 그리고 다음 백 개의 프롬프트가 제대로 안착하게 만드는 수락 기준 (Acceptance criteria)을 추가하는 데 쓰는 한 시간보다 가치가 낮습니다. 현재 앞서 나가고 있는 빌더들은 프롬프트를 더 잘 작성하는 사람들이 아닙니다. 그들은 하네스를 축적하고 있으며, 그곳에 사양 (Specs)을 입력하고 있습니다.

이번 주에 당신의 하네스를 시작하십시오:

1. AGENTS.md 파일을 생성하고, 에이전트가 두 번 이상 저지른 모든 실수에 대해 항목을 하나씩 추가하십시오. (Claude Code 기술은 이와 동일한 움직임을 구조화한 버전입니다.)
2. 테스트 (Tests), 린터 (Linter), 타입 체커 (Type checker)와 같은 기존의 체크 항목들을 에이전트의 경로에 연결하여, 실패가 자동으로 피드백되도록 하십시오.
3. 다음 기능을 구현하기 전에, BrainGrid나 다른 어디에서든 수락 기준 (Acceptance criteria)을 먼저 작성하십시오. 그래야 하네스가 검증할 수 있는 실질적인 대상이 생깁니다.

OpenAI 게시물, GitHub 스타 개수, 새로운 어휘를 모두 걷어내도 주장은 여전히 유효합니다. 에이전트의 출력은 그것을 검사하는 환경만큼만 신뢰할 수 있으며, 그 환경은 당신이 작성한 의도만큼만 좋을 수 있습니다. 하네스(harness)는 에이전트가 실수를 반복하는 것을 멈추게 하는 방법입니다. 그리고 스펙(spec)은 비싼 실수를 저지르는 것을 막아주는 방법입니다.

FAQ

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

하네스 엔지니어링은 AI 코딩 에이전트 주변의 환경을 설계하여 신뢰할 수 있는 결과를 생성하도록 하는 관행입니다. 여기에는 에이전트가 읽는 컨텍스트 파일(예: AGENTS.md), 호출할 수 있는 도구 및 스크립트, 그리고 그 출력을 포착하고 문제를 다시 전달하는 자동화된 검사(테스트, 린터, 리뷰 에이전트)가 포함됩니다. 핵심은 모든 수정 사항을 채팅에서 반복하는 대신 환경에 영구적으로 인코딩하는 것입니다.

하네스 엔지니어링이라는 용어는 누가 만들었나요?

Terraform의 창시자인 Mitchell Hashimoto가 2026년 2월 5일 '나의 AI 도입 여정(My AI Adoption Journey)' 게시물에서 '하네스를 설계하는 것(engineering the harness)'을 설명했습니다. OpenAI는 그로부터 6일 뒤, Ryan Lopopolo가 인간이 작성한 코드가 전혀 없는 내부 제품 구축에 대해 올린 2월 11일 게시물에서 이 용어를 공식화했습니다. 근본적인 단어 자체는 더 오래되었는데, 하네스는 오랫동안 모델 주변의 지지대(scaffolding)를 의미해 왔으며, 힘을 안내하는 장비라는 승마 비유는 의도적입니다.

하네스 엔지니어링과 스펙 기반 개발의 차이점은 무엇인가요?

두 가지는 동일한 문제의 정반대 측면을 다룹니다. 스펙 기반 개발은 에이전트가 시작하기 전에 무엇을 구축할지 정의합니다: 요구 사항, 동작 방식, 수락 기준(acceptance criteria). 하네스 엔지니어링은 에이전트가 어떻게 작동하고 무엇을 생성했는지 검사하는 방식을 형성합니다: 규칙(conventions), 도구, 테스트, 그리고 피드백. 하네스는 표준에 맞춰 출력을 검증하며, 스펙은 그 표준 자체입니다. 따라서 각 관행은 다른 하나 없이는 불완전합니다.

하네스와 루프의 차이점은 무엇인가요?

하네스(Harness)는 단일 에이전트 실행(agent run)을 둘러싼 환경입니다. 즉, 에이전트가 무엇을 알고, 무엇을 건드릴 수 있으며, 무엇이 에이전트의 작업을 검증하는지를 의미합니다. 루프(Loop)는 그 상위의 오케스트레이션(Orchestration)입니다. 작업을 찾아내고, 에이전트를 반복해서 실행하며, 언제 멈출지를 결정하는 스케줄러(Scheduler)가 바로 루프입니다. 루프는 에이전트를 재실행하고, 하네스는 각 실행을 신뢰할 수 있게 만듭니다. 두 요소 모두 '완료'가 무엇을 의미하는지 정의하기 위해 스펙(Spec)에 의존합니다.

하네스 엔지니어링(Harness Engineering)의 혜택을 받으려면 엔지니어여야 하나요?

린트 규칙(Lint rule)을 한 번도 작성하지 않더라도 이 원칙은 적용됩니다. 어떤 빌더(Builder)든 에이전트가 따라야 할 수정 사항들을 기록한 파일을 유지할 수 있으며, 어떤 빌더든 에이전트가 시작하기 전에 수락 기준(Acceptance criteria)을 정의할 수 있습니다. 나머지는 도구가 처리합니다. BrainGrid의 플래닝 에이전트(Planning Agent)는 평이한 언어로 된 아이디어를 테스트 가능한 기준을 갖춘 요구사항으로 변환하며, 그 검증(Verification) 과정은 인프라 작업 없이도 각 기준에 따라 빌드를 확인하는 하네스의 피드백 레이어(Feedback layer) 역할을 수행합니다.

BrainGrid는 여러분의 하네스가 스스로 생성할 수 없는 단 하나의 입력값, 즉 모든 빌드를 검증할 수 있는 수락 기준이 포함된 스펙(Spec)을 제공하는 AI 제품 플래너(AI Product Planner)입니다. braingrid.ai에서 체험해 보세요.

원문은 BrainGrid 블로그에 게시되었습니다.