배울 내용

이 가이드는 Harness Engineering의 기본 원리부터 실제 구현까지 다룹니다. Harness Engineering이 무엇인지, 왜 OpenAI가 가장 큰 내부 프로젝트의 명운을 여기에 걸었는지, 이를 가능하게 하는 구체적인 아키텍처 패턴은 무엇인지, 그리고 Codex, Claude Code, OpenCode 또는 기타 Agent 시스템을 사용하든 상관없이 이러한 원칙을 자신의 AI Agent 워크플로우에 어떻게 적용할 수 있는지 이해하게 될 것입니다.

Harness Engineering: 2026년 AI Agent 개발을 위한 완벽 가이드

2025년이 AI Agent가 코드를 작성할 수 있음을 증명한 해였다면, 2026년은 Agent 자체가 어려운 것이 아니라 Harness가 핵심이라는 사실을 깨달은 해입니다.

OpenAI의 Codex 팀은 2026년 2월, 사람이 단 한 줄의 코드도 작성하지 않고 약 1,000,000 라인의 코드로 구성된 프로덕션 애플리케이션을 구축한 과정을 설명하는 획기적인 블로그 포스트를 게시했습니다. 그 비결은 더 나은 모델이나 더 똑똑한 프롬프트가 아니었습니다. 그것은 바로 Agent를 둘러싸고 구축한 시스템, 즉 Harness였습니다. 출처

이 가이드는 해당 실험과 그로부터 생겨난 광범위한 Harness Engineering 운동의 모든 원칙, 패턴 및 실제 기술을 분석합니다.

파트 1: Harness Engineering이란 무엇인가?

정의

Harness Engineering은 AI 코딩 Agent가 사람의 개입을 최소화하면서 대규모로 안정적이고 고품질의 작업을 수행할 수 있도록 하는 전체 환경(스캐폴딩, 피드백 루프, 문서화, 아키텍처 제약 조건 및 기계 읽기 가능한 아티팩트)을 설계하는 학문입니다.

"Harness"라는 용어는 고삐, 안장, 재갈 등 강력하지만 예측 불가능한 동물을 올바른 방향으로 이끄는 데 필요한 전체 장비 세트인 '마구'에서 유래했습니다. 통제되지 않은 말은 위험합니다. 하지만 Harness를 갖춘 말은 문명을 건설했습니다. AI Agent도 마찬가지입니다. 출처

왜 지금 등장했는가

프롬프트 엔지니어링에서 Harness Engineering으로의 전환은 AI 개발 환경의 성숙을 반영합니다.

출처

이러한 전환을 이끈 핵심 통찰은 Agent가 충분히 유능해짐에 따라 병목 현상이 모델 품질에서 환경 품질로 옮겨갔다는 것입니다. 구조가 빈약한 저장소에서 작동하는 최첨단 모델은 잘 구축된 Harness 환경에서 작동하는 평범한 모델보다 더 나쁜 결과를 냅니다.

파트 2: OpenAI Codex 실험

규모

5개월간의 내부 실험에서 OpenAI 엔지니어들은 약 1,000,000 라인의 코드가 포함된 베타 제품을 구축하여 출시했습니다. 저장소에는 애플리케이션 로직, 인프라, 툴링, 문서 및 내부 개발자 유틸리티가 포함되어 있습니다. 시스템의 기반이 되는 사람이 작성한 기존 코드는 전혀 없었습니다. 출처

팀

프로젝트는 Codex를 운영하는 단 3명의 엔지니어로 시작되었습니다. 5개월 동안 약 1,500개의 pull requests가 생성되고 병합되었습니다. 팀이 7명의 엔지니어로 늘어남에 따라 처리량도 증가했습니다. 이는 개별 기술이 아니라 Harness 자체가 주요 생산성 승수였음을 시사하는 직관에 반하는 결과였습니다.

OpenAI는 코드를 직접 손으로 작성했을 때보다 약 1/10의 시간 만에 시스템을 구축한 것으로 추정합니다. 출처

초기 스캐폴딩

프로젝트는 Codex CLI가 소수의 기존 템플릿을 가이드 삼아 GPT-5를 사용하여 초기 스캐폴딩을 생성하는 것으로 시작되었습니다.

• 저장소 구조 및 디렉토리 규칙
• CI/CD 구성
• 코드 포맷팅 및 린팅 규칙
• 패키지 매니저 설정
• 애플리케이션 프레임워크 상용구(boilerplate)

이 씨앗으로부터 다른 모든 것들이 Agent 주도 개발을 통해 성장했습니다.

금요일의 문제

실험 초기, 팀은 심각한 문제를 발견했습니다. 매주 금요일, 즉 엔지니어링 시간의 20%를 그들이 "AI slop(AI 쓰레기)"이라고 부르는 것을 정리하는 데 소비하고 있었던 것입니다. 여기에는 일관성 없는 패턴, 중복된 로직, 잘못 명명된 변수, 아키텍처의 변질 등이 포함되었습니다.

이것은 확장 가능하지 않았습니다. 해결책은 표준을 Harness 자체에 인코딩하여 Agent가 처음부터 더 깨끗한 결과물을 생성하도록 하고, 잔류하는 변질에 대해 자동화된 정리 시스템을 구축하는 것이었습니다.

파트 3: 5가지 핵심 원칙

원칙 1: 저장소 우선 지식 (Repository-First Knowledge)

Agent의 관점에서 실행 중에 컨텍스트 내에서 액세스할 수 없는 것은 사실상 존재하지 않는 것과 같습니다. Google Docs, 채팅 스레드, Slack 메시지 또는 사람의 머릿속에 있는 지식은 시스템에 보이지 않습니다.

이는 모든 지식이 저장소 로컬의 버전 관리되는 아티팩트로 존재해야 함을 의미합니다.

• 코드 — 기본 아티팩트
• Markdown 문서 — 아키텍처 결정, 컨벤션, 온보딩 가이드
• Schemas — API 계약, 데이터베이스 스키마, 타입 정의
• 실행 가능한 계획 — Agent가 따를 수 있는 단계별 작업 분석
• Configuration — linter 규칙, CI 파이프라인, 포맷팅 표준

팀은 시간이 지남에 따라 점점 더 많은 컨텍스트를 저장소에 넣어야 한다는 것을 배웠습니다. Agent가 컨텍스트 부족으로 실수를 할 때마다 해결책은 더 나은 프롬프트가 아니라 저장소에 해당 컨텍스트를 추가하는 것이었습니다. 출처

실제 구현 예시:

# ARCHITECTURE.md (저장소 루트에 위치)

## 의존성 규칙
- UI 컴포넌트는 Service 레이어에서 import할 수 있지만 Repo 레이어에서는 절대 불가
- Service 레이어는 Runtime 레이어에서 import 불가
- 모든 도메인 간 통신은 타입이 지정된 이벤트 버스를 통해 수행

## 명명 규칙
- React 컴포넌트: PascalCase, 목적을 접미사로 사용 (UserListPage, UserCard)
- Services: camelCase, Service를 접미사로 사용 (userService, authService)
- Types: PascalCase, 도메인을 접두사로 사용 (UserProfile, OrderItem)

## 테스트 요구 사항
- 모든 Service 함수는 유닛 테스트 필수
- 모든 API 엔드포인트는 통합 테스트 필수
- 커버리지 임계값: 패키지당 80%

원칙 2: 황금 원칙 (Golden Principles)

황금 원칙은 향후 Agent 실행 시 코드베이스를 읽기 쉽고 일관되게 유지하기 위해 저장소에 직접 인코딩된 독단적이고 기계적인 규칙입니다. 이는 단순한 권장 가이드라인이 아니라 강제되는 제약 조건입니다.

OpenAI 실험의 예시:

1. 직접 만든 헬퍼보다 공유 유틸리티 패키지를 선호할 것 — 불변성을 중앙 집중화하여 동작을 변경해야 할 때 한 곳에서 변경되도록 함
2. 데이터를 무작정(YOLO-style) 탐색하지 말 것 — 경계를 검증하거나 타입이 지정된 SDK에 의존하여 Agent가 추측된 데이터 형태를 기반으로 코드를 작성하지 않도록 함
3. 하나의 개념, 하나의 파일 — 각 파일은 하나의 개념만 나타내야 하며, Agent가 올바른 위치를 찾고 수정하기 쉽게 함
4. 암시적인 것보다 명시적인 것 — Agent가 이해하기 위해 암묵적인 지식이 필요한 마법 같은 동작을 피함

출처

이러한 원칙은 단순한 문서가 아닙니다. 다음을 통해 강제됩니다.

• Linter 규칙 — 위반 사항을 표시하는 커스텀 linter (이 또한 Codex가 생성함)
• 구조적 테스트 — 아키텍처 준수 여부를 검증하는 테스트
• CI 게이트 — 황금 원칙을 위반하는 pull requests는 자동으로 거부됨

원칙 3: 기계적 강제가 포함된 계층형 아키텍처

OpenAI 프로젝트의 각 비즈니스 도메인은 엄격하게 검증된 의존성 방향을 가진 고정된 레이어 세트로 나뉩니다.

Types → Config → Repo → Service → Runtime → UI

의존성은 한 방향으로만 흐릅니다. UI 컴포넌트는 Runtime 및 Service에 의존할 수 있지만, Service는 절대 UI에서 import할 수 없습니다. Repo는 Config 및 Types에 의존할 수 있지만 Service에는 절대 의존할 수 없습니다. 출처

이러한 제약 조건은 기계적으로 강제됩니다.

// structural-test.ts — 의존성 경계 강제
import { analyzeImports } from './tools/import-analyzer';

describe('Dependency Layer Enforcement', () => {
  it('Service 레이어는 Runtime에서 import할 수 없음', () => {
    const violations = analyzeImports({
      sourceLayer: 'service',
      forbiddenLayers: ['runtime', 'ui'],
    });
    expect(violations).toEqual([]);
  });

  it('Repo 레이어는 Service에서 import할 수 없음', () => {
    const violations = analyzeImports({
      sourceLayer: 'repo',
      forbiddenLayers: ['service', 'runtime', 'ui'],
    });
    expect(violations).toEqual([]);
  });
});

구조적 테스트는 준수 여부를 검증하고 모듈식 계층 구조 위반을 방지합니다. 이는 제안이 아니라 CI에 의해 강제되는 사항입니다. 사람이 만들었든 Agent가 만들었든 모든 pull request는 이러한 테스트를 통과해야 합니다.

원칙 4: 자동화된 가비지 컬렉션 (Automated Garbage Collection)

황금 원칙과 구조적 강제가 있더라도 Agent가 생성한 코드는 시간이 지남에 따라 변질됩니다. OpenAI 팀은 자동화된 가비지 컬렉션을 구현하여 이를 해결했습니다. 이는 주기적으로 실행되는 백그라운드 작업으로 다음을 수행합니다.

1. 전체 코드베이스에서 황금 원칙에서의 이탈을 스캔
2. 준수 점수에 따라 각 모듈의 품질 등급을 업데이트
3. 특정 범주의 변질을 수정하는 타겟팅된 리팩토링 pull requests 생성

이를 통해 수동 "금요일 정리"를 지속적으로 실행되는 시스템으로 대체했습니다. 가비지 컬렉터 자체도 Codex Agent에 의해 구동되어 자가 유지 루프를 생성합니다. 출처

# .github/workflows/garbage-collection.yml
name: Codebase Garbage Collection
on:
  schedule:
    - cron: '0 2 * * *'  # 매일 새벽 2시에 실행

jobs:
  gc-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run golden principle scanner
        run: npx codex-gc scan --principles ./GOLDEN_PRINCIPLES.md
      - name: Generate refactoring PRs
        run: npx codex-gc fix --auto-pr --max-prs 5

원칙 5: 실행 가능한 계획 (Executable Plans)

Agent는 코드를 작성하기 전에 계획을 작성합니다. 이 계획은 비공식적인 메모가 아니라 다음을 지정하는 구조화되고 실행 가능한 문서입니다.

• 목표 (Objective): 작업이 달성하려는 것
• 수정할 파일 (Files to modify): Agent가 수정할 구체적인 파일 목록
• 의존성 (Dependencies): 이 작업이 의존하는 다른 작업이나 모듈
• 수락 기준 (Acceptance criteria): 작업 완료를 확인하는 방법
• 제약 조건 (Constraints): 위반해서는 안 되는 아키텍처 규칙

# 계획: 사용자 알림 기본 설정 추가

## 목표
사용자가 이메일, SMS, 푸시 중 어떤 알림 채널을 받을지 카테고리별로 구성할 수 있도록 함.

## 수정할 파일
- src/types/user.ts — NotificationPreferences 타입 추가
- src/repo/userRepo.ts — getPreferences/setPreferences 메서드 추가
- src/service/notificationService.ts — 기본 설정에 따라 알림 필터링
- src/ui/pages/SettingsPage.tsx — 설정 UI 섹션 추가

## 제약 조건
- Types → Repo → Service → UI 의존성 흐름을 따라야 함
- NotificationPreferences 타입은 중복되지 않고 공유되어야 함
- 모든 새 메서드에는 유닛 테스트가 필요함

## 수락 기준
- [ ] 사용자가 알림 카테고리별로 이메일/SMS/푸시를 토글할 수 있음
- [ ] 설정이 세션 간에 유지됨
- [ ] 채널을 끄면 30초 이내에 해당 채널의 알림이 중단됨

계획은 저장소에 markdown 파일로 저장되고 버전 관리되며 실행 전에 검토될 수 있습니다. 이는 사람에게 의도와 구현 사이의 체크포인트를 제공합니다.

파트 4: Codex Agent 루프

Harness 내에서 Codex Agent 루프가 어떻게 작동하는지 이해하는 것은 효과적인 Harness Engineering을 위해 필수적입니다.

루프 아키텍처

OpenAI는 동반 블로그 포스트 "Unrolling the Codex agent loop"에서 Codex Agent 루프에 대한 자세한 분석을 발표했습니다. 출처 루프는 다음 사이클을 따릅니다.

컨텍스트 읽기 → 계획 → 실행 → 검증 → 커밋 (또는 재시도)

각 반복 단계:

1. 컨텍스트 읽기 (Read Context): Agent는 저장소에서 관련 파일, 문서, 스키마 및 작업 계획을 읽습니다.
2. 계획 (Plan): 컨텍스트를 바탕으로 Agent는 어떤 변경을 할지 결정합니다.
3. 실행 (Execute): Agent가 코드를 작성하거나 수정합니다.
4. 검증 (Validate): Harness가 변경 사항에 대해 테스트, linter 및 구조적 체크를 실행합니다.
5. 커밋 또는 재시도 (Commit or Retry): 검증이 통과되면 Agent가 커밋합니다. 실패하면 Agent는 에러 출력을 읽고 다시 시도합니다.

Harness의 역할은 1단계와 4단계를 최대한 정보가 풍부하게 만드는 것입니다. Agent가 더 많은 컨텍스트를 읽을수록 더 나은 계획을 세울 수 있습니다. 검증 피드백이 구체적일수록 작동하는 솔루션에 더 빨리 도달합니다.

App Server Harness

"Unlocking the Codex harness: how we built the App Server" 포스트에서 OpenAI는 Agent 루프를 구동하는 구체적인 인프라를 설명합니다. 출처 App Server는 다음을 제공합니다.

• 각 Agent 작업을 위한 샌드박스 실행 환경
• 사전 구성된 도구 액세스 (파일 시스템, 터미널, 브라우저)
• 저장소 아티팩트로부터의 자동 컨텍스트 주입
• Agent가 실시간으로 테스트 실패를 볼 수 있는 스트리밍 검증 피드백

파트 5: 팀에 Harness Engineering 적용하기

시작하기: 최소 기능 Harness (Minimum Viable Harness)

Harness Engineering의 이점을 얻기 위해 OpenAI의 전체 인프라를 복제할 필요는 없습니다. 다음과 같은 기초적인 요소부터 시작하십시오.

1단계: ARCHITECTURE.md 생성

저장소 루트에 기계 읽기 가능한 형식으로 프로젝트의 아키텍처 규칙을 문서화하십시오. 다음을 포함하십시오.

• 모듈 경계 및 허용된 의존성
• 명명 규칙
• 파일 조직 규칙
• 테스트 요구 사항

이 파일 하나만으로도 Agent가 변경을 수행하기 전에 읽기 때문에 결과물의 품질이 비약적으로 향상됩니다.

2단계: 구조적 테스트 추가

아키텍처 규칙을 검증하는 테스트를 작성하십시오. 이 테스트는 비즈니스 로직을 확인하는 것이 아니라 코드가 올바르게 조직되었는지 확인합니다.

// service 파일은 UI 모듈에서 import하면 안 됨
test('service 레이어 격리', () => {
  const serviceFiles = glob('src/services/**/*.ts');
  for (const file of serviceFiles) {
    const imports = extractImports(file);
    const uiImports = imports.filter(i => i.startsWith('../ui/'));
    expect(uiImports).toHaveLength(0);
  }
});

3단계: CI 검증 구성

CI 파이프라인이 Agent가 생성한 것을 포함하여 모든 pull request에 대해 구조적 테스트, linter 및 타입 체크를 실행하도록 하십시오. Agent는 인간 개발자가 보는 것과 동일한 검증 출력을 보아야 합니다.

4단계: Agent 실행 전 작업 계획 작성

Agent에게 기능을 구현하도록 요청하기 전에 수정할 파일, 준수해야 할 제약 조건 및 수락 기준을 지정하는 구조화된 계획 문서를 작성하십시오. 이러한 계획을 저장소에 저장하십시오.

5단계: 자동화된 정리 설정

문서화된 표준에서 벗어난 코드를 스캔하고 집중 리팩토링 PR을 생성하는 주간 또는 야간 CI 작업을 구현하십시오.

Agent 시스템 선택

어떤 Agent를 사용하든 Harness Engineering 원칙은 적용됩니다.

Harness는 Agent가 아니라 저장소에 있습니다. 즉, Harness에 대한 투자를 잃지 않고 Agent를 교체할 수 있습니다.

한 명의 Agent에서 다수로 확장하기

OpenAI 실험은 Harness Engineering이 병렬 Agent 실행을 가능하게 함을 보여주었습니다. Harness가 아키텍처 경계를 강제하기 때문에 여러 Agent가 충돌 없이 코드베이스의 서로 다른 부분에서 동시에 작업할 수 있습니다.

병렬 Agent 실행을 위한 주요 요구 사항:

1. 명확한 모듈 소유권 — 각 Agent는 정의된 경계 내에서 작업함
2. 모듈 간 타입 지정 인터페이스 — Agent는 구현 세부 사항을 몰라도 인터페이스에 맞춰 코딩할 수 있음
3. 병합 충돌 방지 — 파일 중첩을 최소화하도록 작업 범위를 조정함
4. 중앙 집중식 검증 — 모든 Agent가 동일한 CI 파이프라인에 제출함

파트 6: 일반적인 함정과 안티 패턴

안티 패턴 1: Agent를 Harness로 취급하기

Agent는 Harness가 아닙니다. Harness는 Agent가 작동하는 환경입니다. 구조가 나쁜 저장소를 보완하기 위해 더 똑똑한 모델을 요청하는 것은 잘못된 접근 방식입니다. 프롬프트가 아니라 환경을 고치십시오.

안티 패턴 2: 잘못된 위치의 문서화

아키텍처 결정이 Confluence, Notion 또는 Google Docs에 있다면 Agent는 그것을 볼 수 없습니다. 해결책은 간단하지만 규율이 필요합니다. 개발과 관련된 모든 문서를 저장소로 옮기십시오.

안티 패턴 3: 자동화된 강제 대신 수동 정리

Agent가 생성한 코드를 정리하는 데 상당한 시간을 쓰고 있다면 더 나은 강제 수단이 필요한 것이지 더 많은 정리 세션이 필요한 것이 아닙니다. 반복되는 모든 정리 작업은 linter 규칙, 구조적 테스트 또는 자동화된 리팩토링 작업이 되어야 합니다.

안티 패턴 4: 과도한 제약

너무 경직된 Harness는 Agent가 창의적인 솔루션을 찾는 것을 방해합니다. 목표는 구현이 아니라 아키텍처를 제약하는 것입니다. Agent에게 어떤 모듈을 수정할 수 있고 어떤 의존성이 허용되는지 알려주되, 해당 경계 내에서 로직을 구현하는 방법은 Agent가 결정하게 하십시오.

안티 패턴 5: Agent 피드백 무시

Agent가 특정 작업에서 반복적으로 실패할 경우, 그 실패는 대개 Agent의 한계가 아니라 Harness의 격차를 나타냅니다. 실패 패턴을 추적하고 이를 사용하여 문서, 구조적 테스트 또는 아키텍처 제약 조건을 개선하십시오.

파트 7: Harness Engineering의 미래

Martin Fowler의 관점

Martin Fowler는 자신의 블로그에 Harness Engineering 분석을 게시하며, 이것이 소프트웨어 팀의 운영 방식에서 근본적인 변화를 나타낸다고 언급했습니다. 이 학문은 지속적 통합, 아키텍처 결정 기록, 의존성 주입과 같이 수십 년 된 소프트웨어 엔지니어링 모범 사례를 차용하지만, 이를 Agent 주도 세계에 맞게 재구성합니다. 출처

HumanLayer 프레임워크

HumanLayer 팀은 Harness Engineering을 "스킬 이슈(skill issue)"라고 부르는 분석을 발표했습니다. 효과적인 Harness를 설계하는 능력이 성과가 높은 엔지니어링 팀과 고전하는 팀을 가르는 주요 차별화 요소가 될 것이라고 주장합니다. 출처

이것이 개발자에게 의미하는 바

Harness Engineering은 개발자의 기술을 대체하는 것이 아니라 재지향시킵니다. 시니어 엔지니어는 코드를 작성하는 대신 Agent가 코드를 잘 작성할 수 있게 해주는 시스템을 설계합니다. 중요한 기술은 구현에서 아키텍처로, 코딩에서 시스템 설계로, 테스트 작성에서 테스트 프레임워크 설계로 옮겨갑니다.

애플리케이션을 구축하는 팀의 경우, ZBuild와 같은 플랫폼은 이미 앱 빌더 워크플로우에 Harness Engineering 원칙을 통합하고 있습니다. 개발자가 처음부터 직접 Harness를 설계하도록 요구하는 대신, ZBuild는 AI Agent가 고품질 결과물을 낼 수 있도록 가이드하는 사전 구성된 아키텍처 패턴, 의존성 관리 및 검증 시스템을 제공합니다. 이를 통해 개발자는 인프라가 아닌 제품 결정에 집중할 수 있습니다.

세 가지 지평

미래를 내다볼 때, Harness Engineering은 세 단계를 거쳐 진화할 가능성이 높습니다.

1. 단기 (2026): 팀들이 저장소 우선 문서화, 구조적 테스트 및 황금 원칙을 채택합니다. Harness가 잘 구축된 프로젝트에서 Agent 보조 개발이 표준 관행이 됩니다.

2. 중기 (2027): Harness 생성 자체가 Agent 주도로 이루어집니다. Agent가 기존 코드베이스를 분석하고 관찰된 패턴을 기반으로 linter 규칙, 구조적 테스트, 의존성 경계와 같은 Harness 구성을 제안합니다.

3. 장기 (2028+): Harness가 적응형으로 변합니다. 정적인 규칙 대신 Agent가 생성한 코드의 결과에 따라 진화하며, Agent가 자주 에러를 내는 영역에서는 제약을 자동으로 강화하고 일관되게 성공하는 영역에서는 제약을 완화합니다.

파트 8: 실무 체크리스트

이 체크리스트를 사용하여 팀의 Harness Engineering 성숙도를 평가하십시오.

기초 (여기서 시작)

• 저장소 루트에 ARCHITECTURE.md가 존재함
• 코드 포맷팅이 자동화됨 (Prettier, Black, gofmt)
• 모든 pull request에서 린팅이 실행됨
• 타입 체크가 강제됨 (TypeScript strict, mypy 등)

중급

• 구조적 테스트가 의존성 경계를 검증함
• 황금 원칙이 문서화되고 기계적으로 강제 가능함
• Agent 실행 전에 작업 계획을 작성함
• Agent가 생성한 PR이 인간의 PR과 동일한 CI를 거침

고급

• 자동화된 가비지 컬렉션이 스케줄에 따라 실행됨
• 여러 Agent가 충돌 없이 병렬로 작업할 수 있음
• Agent 실패 패턴이 추적되고 Harness 개선에 사용됨
• Harness 자체도 코드처럼 버전 관리되고 검토됨

전문가

• Agent가 Harness의 일부(linter 규칙, 구조적 테스트)를 생성함
• 각 모듈에 품질 등급이 자동으로 할당됨
• Agent 성공률에 기반한 데이터 주도적인 Harness 개선이 이루어짐
• 팀이 Agent를 도입하기 전보다 엔지니어당 주간 코드 배포량이 증가함

결론

Harness Engineering은 일시적인 유행이 아닙니다. AI Agent가 프로덕션 코드를 작성할 수 있을 만큼 유능해졌지만, 이를 잘 수행하기 위해 구조화된 환경이 필요한 시대에서 소프트웨어 엔지니어링의 자연스러운 진화입니다. OpenAI의 백만 라인 실험은 대규모 프로젝트에서 이 개념을 입증했으며, 그들이 명시한 원칙인 저장소 우선 지식, 황금 원칙, 계층형 아키텍처, 자동화된 가비지 컬렉션, 실행 가능한 계획은 모든 규모의 팀에 적용 가능합니다.

2026년에 Harness Engineering을 마스터하는 팀은 AI Agent를 단순히 똑똑한 자동 완성 도구로 취급하는 팀보다 더 빠르게 제품을 출시하고, 더 높은 코드 품질을 유지하며, 더 효과적으로 확장해 나갈 것입니다. Agent는 말입니다. Harness는 그 말을 유용하게 만드는 장구입니다.

출처

• Harness Engineering: Leveraging Codex in an Agent-First World — OpenAI
• Unlocking the Codex Harness: How We Built the App Server — OpenAI
• Unrolling the Codex Agent Loop — OpenAI
• OpenAI Introduces Harness Engineering — InfoQ
• Harness Engineering — Martin Fowler
• Skill Issue: Harness Engineering for Coding Agents — HumanLayer
• From Prompt Engineering to Harness Engineering — SoftmaxData
• How to Build an Agent Harness — Study Notes
• Harness Engineering — GTCode
• OpenAI Harness Engineering: Ship 1M Lines of Code — The Neuron
• How OpenAI Built 1M Lines of Code Using Only Agents — TonyLee
• Harness Engineering — The New Discipline — CodeNote