2026년 2월, OpenAI의 소규모 팀이 100만 줄의 프로덕션 코드 (production code)를 출시했습니다.

그들은 단 한 줄의 코드도 직접 작성하지 않았습니다.
AI 에이전트 (AI agents)가 작성했습니다.

인간은 에이전트가 신뢰할 수 있도록 만드는 시스템을 설계했습니다.

그 시스템에는 이제 이름이 있습니다.
하네스 엔지니어링 (Harness Engineering).

몇 주 만에 Anthropic은 이에 관한 3편의 논문을 발표했습니다.

ThoughtWorks는 프레임워크를 공식화했습니다.

Hugging Face의 Philipp Schmid는 이를 "2026년 가장 중요한 분야"라고 불렀습니다.

새로운 엔지니어링 분야가 90일 만에 구체화되었습니다.

그리고 AI 인프라 팀 외부에서는 아직 거의 아무도 이를 이해하지 못하고 있습니다.

이 글은 모든 것을 설명합니다.

미사여구는 없습니다. 학술적 전문 용어도 없습니다. 그저 이를 실제로 사용하는 데 필요한 멘탈 모델 (mental models)뿐입니다.

이 글을 저장해 두세요. 두 번 읽게 될 것입니다.

PART 1: 하네스 (HARNESS)란 실제로 무엇인가

(AI를 생각하는 방식을 바꾸는 개념)

1. 하네스의 정의

가장 간단한 정의는 ThoughtWorks에서 가져왔습니다:

→ 에이전트 (Agent) = 모델 (Model) + 하네스 (Harness)

하네스는 모델이 아닌 모든 것을 의미합니다.

에이전트가 경로를 벗어나지 않게 유지하는 제약 조건 (constraints). 실수를 잡아내는 피드백 루프 (feedback loops). 에이전트에게 현재 위치를 알려주는 문서화 (documentation). 에이전트가 사용할 권한을 가진 도구들 (tools).

하네스를 제거하면 → 코드베이스 (codebase)를 통해 추측하며 나아가는 가공되지 않은 언어 모델 (raw language model)이 됩니다.

적절한 하네스를 추가하면 → 프로덕션 코드 (production code)를 출시하는 시스템이 됩니다.

이 이름은 말의 마구 (horse tack)에서 유래되었습니다.

하네스는 강력하지만 예측 불가능한 동물을 유용한 방향으로 유도하는 고삐 (reins), 안장 (saddle), 재갈 (bit)을 의미합니다.

당신은 말을 더 똑똑하게 만드는 것이 아닙니다. 말의 힘을 유용하게 만드는 장비를 설계하는 것입니다.

2. OS 비유

Philipp Schmid는 가장 훌륭한 기술적 프레임워크 (framing)를 제시했습니다:
컴퓨터와 같다고 생각해보세요.

→ Model = CPU (원시 연산 능력)
→ Context window = RAM (제한적이고 휘발적인 작업 메모리)
→ Harness = 운영 체제 (OS) (CPU가 무엇을 언제 볼지 관리)
→ Agent = 그 위에서 실행되는 애플리케이션

여러분의 모델은 강력합니다.

하지만 메모리를 관리하고, 작업을 스케줄링하며, 규칙을 집행하는 운영 체제 (OS)가 없다면, 그것은 단지 실리콘 덩어리에 불과합니다.

대부분의 사람들은 운영 체제 없이 앱을 실행하고 있습니다.

그것이 그들의 에이전트 (agent)가 프로덕션 (production) 환경에서 실패하는 이유입니다.

3. 2026년에 변화된 것

LangChain은 Terminal Bench 2.0에서 동일한 모델을 두 번 실행했습니다.
동일한 모델. 다른 하네스 (harness).

→ 기존 하네스: 52.8% 점수
→ 새로운 하네스: 66.5% 점수

Vercel은 정반대의 방향으로 갔습니다.

그들은 에이전트 도구의 80%를 제거했습니다.

결과는? 더 나은 성능.

더 나빠진 것이 아닙니다.

2026년의 불편한 진실:

→ 에이전트 (agent)는 결코 어려운 부분이 아니었습니다.
→ 하네스 (harness)가 어려운 부분입니다.

2025년이 AI 에이전트가 코드를 작성할 수 있음을 증명한 해였다면,

2026년은 환경 (environment)이 모델 (model)보다 더 중요하다는 것을 발견한 해입니다.

PART 2: 5가지 하네스 아티팩트 (HARNESS ARTIFACTS)

(하네스가 실제로 실무에서 어떤 모습인지)

4. AGENT.md / CLAUDE.md 파일

가장 보편적인 하네스 아티팩트 (artifact).

코드베이스 전반에 분산되어 있는 마크다운 (Markdown) 파일들입니다.

에이전트는 팀에 합류하는 신입 엔지니어를 위한 온보딩 문서 (onboarding docs)처럼, 매 세션이 시작될 때 이 파일들을 읽습니다.

포함되는 내용:
→ 프로젝트 컨텍스트 (Project context)
→ 코딩 컨벤션 (Coding conventions)
→ 아키텍처 결정 사항 (Architecture decisions)
→ "우리가 여기서 일하는 방식"에 대한 가이드라인
→ 현재 진행 중인 작업 사항

OpenAI는 이를 AGENT.md라고 부릅니다.
Anthropic은 이를 CLAUDE.md라고 부릅니다.
Cursor는 .cursorrules를 사용합니다.

이름은 다르지만, 원칙은 같습니다.
주요 모듈당 하나의 파일을 생성하며, 프로젝트가 발전함에 따라 업데이트됩니다.

이것들이 없다면: 에이전트(Agent)는 매 세션마다 아무런 정보 없이 시작합니다.
이것들이 있다면: 에이전트는 매 세션마다 정보를 갖춘 상태로 시작합니다.

5. JSON 기능 목록 (진행 상황 추적기 (The Progress Tracker))

에이전트가 여러 세션에 걸쳐 전체 앱을 구축할 때, 각 세션은 빈 컨텍스트 창(Context window)으로 시작됩니다.
이미 완료된 작업이 무엇인지 어떻게 알 수 있을까요?

바로 JSON 파일입니다.

각 항목은 다음을 정의합니다:
→ 기능 (Feature)
→ 작동 여부를 검증하는 방법
→ 통과(Pass) / 실패(Fail) 상태

에이전트는 세션 시작 시 이 파일을 읽습니다. 우선순위가 가장 높은 실패한 기능을 선택합니다. 이를 구현합니다. 통과로 표시합니다. 커밋(Commit)합니다. 반복합니다.

왜 Markdown이 아닌 JSON인가요?
Anthropic은 에이전트가 Markdown보다 JSON을 실수로 덮어쓸 가능성이 더 낮다는 것을 발견했습니다.
작은 디테일이지만, 6시간 동안 지속되는 자율 실행(Autonomous runs)에서는 매우 중요합니다.

6. 세션 초기화 루틴 (Session Initialization Routines)

모든 세션은 동일한 방식으로 시작됩니다.
매.번. 말입니다.

Anthropic의 7단계 부트 시퀀스 (Boot sequence):
→ 작업 디렉토리(Working directory) 확인
→ git 로그 및 진행 상황 파일 읽기
→ 기능 목록에서 우선순위가 가장 높은 미완료 항목 확인
→ 개발 서버(Dev server) 시작
→ 기본적인 엔드-투-엔드(End-to-end) 검증 실행
→ 기능 하나 구현
→ 설명이 포함된 메시지와 함께 커밋 + 진행 상황 업데이트

이것이 없다면:
에이전트는 이미 무엇이 존재하는지 파악하는 데 첫 20분을 허비합니다.
매 세션마다 바퀴를 다시 발명(Reinventing the wheel)하게 됩니다.

이것이 있다면:
에이전트는 즉시 정보를 갖춘 상태로 시작하여 곧바로 작업에 착수합니다.

7. 스프린트 계약 (Sprint Contracts)

에이전트가 단 한 줄의 코드를 작성하기 전에:
두 에이전트가 협상합니다.

생성 에이전트 (Generator agent)가 제안합니다:
→ 무엇을 구축할 것인지
→ 성공을 어떻게 검증할 것인지

평가 에이전트 (Evaluator agent)가 검토합니다:
→ 제안이 완전한가?
→ 성공 기준이 명확한가?

양측이 합의한 후에야 구현이 시작됩니다.
이것은 디자인 리뷰 (Design review)입니다.
다만 참여자 모두가 AI라는 점이 다를 뿐입니다.

이것이 왜 중요할까요?
계획과 실행을 동일한 패스 (Pass)에서 수행하는 에이전트는 신뢰할 수 없는 결과물을 생성합니다.
계획 단계는 AI가 수행하더라도 결과물의 품질을 극적으로 향상시킵니다.

8. 구조화된 작업 템플릿 (Structured Task Templates)

어떠한 코딩을 하기 전에:
하네스 (Harness)가 실제 코드베이스 (Codebase)를 분석합니다.

하네스는 근거에 기반한 영향력 지도 (Grounded impact map)를 생성합니다:
→ 실제 파일 경로 (환각 (Hallucination)된 경로가 아닌)
→ 실제로 존재하는 실제 심볼 이름 (Symbol names)
→ 따라야 할 기존 패턴
→ 구체적인 수락 기준 (Acceptance criteria)

그다음에 구현이 시작됩니다.
당연한 소리처럼 들릴 것입니다.
하지만 대부분의 팀은 이 단계를 건너뜁니다.

에이전트는 파일 구조를 추측합니다. 존재하지 않는 API 엔드포인트 (API endpoints)를 만들어냅니다. 코드베이스에 맞지 않는 무언가를 구축합니다.

실행 전의 근거 있는 컨텍스트 (Grounded context) → 압도적으로 더 나은 결과물.

PART 3: 세 개의 진영 (THE THREE CAMPS)

(세 팀이 동일한 벽에 부딪혔고, 서로 다른 세 개의 사다리를 만들었습니다)

9. OpenAI: 환경 우선 (Environment-First)

OpenAI의 Codex 팀은 황당한 문제에 직면했습니다.
100만 줄의 프로덕션 코드(production code). 그중 손으로 직접 작성한 코드는 단 한 줄도 없었습니다.
그 정도 규모라면 모든 코드를 코드 리뷰 (code-review) 할 수 없습니다.
그래서 그들은 하지 않았습니다.

대신:
그들은 에이전트 (agents)가 처음부터 리뷰 가능한 결과물을 생성할 수 있도록 환경을 매우 철저하게 설계했습니다.

그들의 접근 방식:
→ 엄격한 의존성 흐름 (Types → Config → Repo → Service → Runtime → UI)
→ 코드베이스 전반에 걸친 AGENT.md 파일 배치
→ 에이전트를 CI/CD 파이프라인에 직접 연결

철학: 환경을 설계하라. 그다음 에이전트를 풀어 놓아라.

증거: Sora Android 앱. 엔지니어 4명. 28일. Play Store 1위. 99.9% 크래시 프리 (crash-free).
Codex는 매주 내부 풀 리퀘스트 (pull requests)의 70%를 처리했습니다.

10. Anthropic: 실행자와 심판자를 분리하라

Anthropic은 다른 문제를 겪었습니다.
에이전트에게 자신의 결과물을 스스로 평가하도록 요청했을 때:
에이전트는 자신 있게 자신의 작업을 찬양했습니다.
인간 관찰자가 보기에는 품질이 분명히 평범함에도 불구하고 말입니다.

자기 평가 (Self-evaluation)는 작동하지 않습니다.
에이전트가 학생이자 동시에 교사였기 때문입니다.
그리고 에이전트는 스스로에게 A 학점을 주고 있었습니다.

그들의 해결책: 세 가지 특화된 에이전트.
→ Planner (기획자): 2문장의 프롬프트 (prompt)를 전체 제품 사양 (product spec)으로 변환
→ Generator (생성자): 한 번의 스프린트 (sprint) 단위로 기능을 구현
→ Evaluator (평가자): 브라우저 자동화 (browser automation)를 사용하여 실제 사용자처럼 실행 중인 앱을 테스트

통찰: 독립적인 평가자를 회의적으로 만드는 것이, 생성자가 자신의 작업에 대해 비판적으로 만들게 하는 것보다 훨씬 쉽습니다.

결과:
단독 에이전트 (하네스 없음): $9, 20분 → 망가진 앱
전체 하네스 (Full harness): $200, 6시간 → 세련된 UI를 갖춘 작동하는 소프트웨어

11. ThoughtWorks: 2×2 프레임워크 (Framework)

ThoughtWorks는 다른 관점에서 접근했습니다.
그들은 제품을 만들고 있었던 것이 아닙니다.
그들은 50개 이상의 엔지니어링 팀이 동일한 문제로 실패하는 것을 지켜보고 있었습니다.

그들의 통찰: 모든 하네스 제어 (harness control)를 두 개의 축을 따라 분류하는 것입니다.

축 1: 언제 실행되는가?
→ Feedforward (피드포워드) = 에이전트가 행동하기 전 (가이드 역할)
→ Feedback (피드백) = 에이전트가 행동한 후 (센서 역할)