Harness Engineering의 진화 방향

모델은 빠르게 발전한다

2022년의 GPT-3는 단순한 텍스트 완성 도구였습니다. 2024년의 Claude 3 Opus는 복잡한 추론이 가능했습니다. 2026년 현재의 모델들은 수백 줄의 코드를 문맥 없이도 올바르게 생성합니다.

이 변화 속도는 중요한 함의를 갖습니다. 오늘 복잡하게 작성한 하네스 로직이 내년에는 불필요해질 수 있습니다.

2022: 모델이 단순한 작업도 실수 → 세밀한 step-by-step 지침 필요
2024: 모델이 대부분 올바르게 동작 → 가드레일 중심 설계
2026: 모델이 복잡한 추론 가능 → 제약 최소화, 목표 명세 중심
2028 (예측): 모델이 스스로 하네스 최적화 제안

자율성 스펙트럼

현재 에이전트 시스템은 완전 수동과 완전 자율 사이 어딘가에 위치합니다.

| 수준 | 설명 | 현재 사례 | |---|---|---| | 수동 (0%) | 인간이 모든 결정 | 단순 코드 자동완성 | | 보조 (25%) | 제안, 인간 승인 | GitHub Copilot | | 반자율 (50%) | 작업 실행, 주요 결정에 인간 | Claude Code (현재) | | 고자율 (75%) | 대부분 자율, 예외만 에스컬레이션 | Stripe Minions | | 완전 자율 (100%) | 완전 독립 실행 | 아직 프로덕션 미검증 |

산업 트렌드 분석

자율성 스펙트럼의 이동은 특정 도메인에서 먼저, 더 빠르게 일어나고 있습니다.

도메인별 자율성 채택 속도

| 도메인 | 현재 자율성 수준 | 3년 후 예측 | 주요 근거 | |---|---|---|---| | 소프트웨어 테스트 | 50~60% | 80%+ | 실패 기준이 명확, 롤백 용이 | | 코드 리뷰 | 40~50% | 70%+ | 규칙 기반 판단, 정량화 가능 | | 문서 생성 | 60~70% | 90%+ | 저위험, 인간 검토 부담 낮음 | | 인프라 변경 | 20~30% | 50% | 장애 영향 범위가 커 신중 | | 보안 결정 | 10~20% | 30% | 오판 시 비용이 극히 높음 |

소프트웨어 테스트와 문서 생성은 실패의 비용이 낮고 자동화된 검증이 가능하기 때문에 자율성이 빠르게 올라가고 있습니다. 반면 인프라 변경이나 보안 결정은 오판의 결과가 심각하기 때문에 인간 감독이 오랫동안 유지될 것입니다.

멀티에이전트 시스템의 부상

단일 에이전트에서 협력하는 에이전트 네트워크로 전환이 가속화되고 있습니다.

현재 (2026): 단일 에이전트 + 툴
  User → MainAgent → [tools]

근미래 (2027~2028): 전문화된 에이전트 팀
  User → OrchestratorAgent
            ├── ResearchAgent
            ├── CodeAgent
            ├── ReviewAgent
            └── DeployAgent

이 전환은 harness 설계에 중요한 시사점을 줍니다. 에이전트 간 통신 프로토콜, 역할 경계 정의, 분산 상태 관리가 새로운 핵심 과제가 됩니다.

적응형 하네스

정적 하네스는 모델 발전과 함께 점점 현실과 괴리됩니다. 미래의 하네스는 모델 성능을 지속적으로 측정하고 스스로 조정합니다.

적응 사이클

측정 → 분석 → 조정 → 재측정
  ↑                        |
  └────────────────────────┘

자동 제약 완화 예시

interface ConstraintLevel {
  scaffoldingDetail: 'verbose' | 'standard' | 'minimal'
  verificationSteps: number
  humanCheckpoints: string[]
  retryPolicy: { maxAttempts: number; backoffMs: number }
}

async function calibrateConstraints(
  weeklyMetrics: WeeklyMetrics
): Promise<ConstraintLevel> {
  const { successRate, errorRate, humanInterventionRate } = weeklyMetrics

  if (successRate > 0.95 && humanInterventionRate < 0.05) {
    // 모델이 충분히 안정적 → 제약 완화
    return {
      scaffoldingDetail: 'minimal',
      verificationSteps: 1,
      humanCheckpoints: ['deploy-to-production'],
      retryPolicy: { maxAttempts: 2, backoffMs: 1000 }
    }
  }

  if (successRate < 0.7 || errorRate > 0.3) {
    // 모델이 불안정 → 제약 강화
    return {
      scaffoldingDetail: 'verbose',
      verificationSteps: 5,
      humanCheckpoints: ['code-review', 'test-review', 'deploy-approval'],
      retryPolicy: { maxAttempts: 5, backoffMs: 5000 }
    }
  }

  // 기본값 유지
  return DEFAULT_CONSTRAINT_LEVEL
}

적응형 하네스 구현 시 주의사항

적응형 하네스가 잘못 설계되면 오히려 불안정성을 증폭시킬 수 있습니다.

피해야 할 패턴:
  단기 성능 급등 → 즉시 제약 대폭 완화
  → 다음 작업 실패 → 즉시 제약 강화
  → 제약 수준이 지속적으로 요동침

올바른 패턴:
  최소 1주일 이상의 이동 평균 사용
  제약 변경폭을 단계당 10~20%로 제한
  변경 후 최소 3일 안정화 대기

뽑기 쉬운 하네스 설계

“Rippable Harness”는 미래 모델 개선에 따라 손쉽게 제거하거나 교체할 수 있는 하네스를 의미합니다.

설계 원칙

1. 레이어 분리: 비즈니스 로직과 제어 로직을 분리
2. 명시적 의존성: 하네스 컴포넌트가 서로를 암묵적으로 의존하지 않음
3. 기능 플래그: 각 제약을 독립적으로 켜고 끌 수 있음
4. 성능 기준: 각 하네스 컴포넌트의 존재 이유를 메트릭으로 정의

기능 플래그로 제약 관리

interface HarnessFlags {
  // 각 플래그는 독립적으로 비활성화 가능
  enableStepByStepScaffolding: boolean
  enableOutputValidation: boolean
  enableContextCompression: boolean
  enableHumanCheckpoints: boolean
  enableRetryOnFailure: boolean
}

// 실험: 새 모델에서 scaffolding 없이도 동작하는지 확인
const EXPERIMENT_FLAGS: HarnessFlags = {
  enableStepByStepScaffolding: false, // A/B 테스트 중
  enableOutputValidation: true,
  enableContextCompression: true,
  enableHumanCheckpoints: true,
  enableRetryOnFailure: true
}

컴포넌트 존재 이유 문서화

각 하네스 컴포넌트는 “이 컴포넌트가 없으면 어떤 일이 발생하는가”를 문서화해야 합니다. 이 기록이 없으면 나중에 컴포넌트를 제거해도 안전한지 판단할 수 없습니다.

// 각 컴포넌트에 존재 이유(rationale)를 메타데이터로 추가
const stepByStepScaffolding: HarnessComponent = {
  name: 'StepByStepScaffolding',
  rationale: '모델이 복잡한 작업을 단계별로 분해하지 못할 때 오류 발생률이 45% 높아짐 (2024-Q3 측정)',
  successMetric: '작업 완료율 > 85%',
  removeCondition: '3개월 연속 작업 완료율 > 95% 유지 시',
  lastEvaluated: '2026-01-15'
}

이 메타데이터를 유지하면 모델이 발전했을 때 어떤 컴포넌트를 제거해도 안전한지 데이터 기반으로 판단할 수 있습니다.

모델 발전에 따른 하네스 변화 예측

| 하네스 구성요소 | 현재 필요성 | 2년 후 예측 | 이유 | |---|---|---|---| | 단계별 작업 분해 | 높음 | 낮음 | 모델이 스스로 분해 | | 출력 형식 파서 | 높음 | 중간 | 구조화 출력 개선 | | 에러 복구 로직 | 중간 | 낮음 | 모델의 자체 수정 능력 향상 | | 컨텍스트 압축 | 높음 | 높음 | 컨텍스트 한도는 여전히 존재 | | 보안 가드레일 | 높음 | 높음 | 신뢰는 항상 검증이 필요 | | 비용 관리 | 높음 | 중간 | API 비용 하락 추세 |

지금 준비해야 할 것

미래 변화에 대비하기 위해 오늘 취할 수 있는 구체적인 행동이 있습니다.

단기 (6개월 이내)

메트릭 수집 시작: 아직 측정하지 않고 있다면, 지금 당장 에이전트 성공률과 실패 유형을 기록하기 시작하세요. 나중에 하네스를 최적화할 때 이 데이터가 근거가 됩니다.

컴포넌트 존재 이유 문서화: 기존 하네스 컴포넌트 각각에 대해 “이것이 없으면 무슨 일이 생기는가”를 기록하세요. 막연하게 “필요할 것 같아서” 추가된 컴포넌트가 있다면 이미 제거 대상입니다.

중기 (6~18개월)

기능 플래그 도입: 각 하네스 제약을 독립적으로 켜고 끌 수 있는 구조로 전환하세요. 새 모델 버전이 출시될 때마다 A/B 테스트를 통해 어떤 제약을 완화할 수 있는지 검증할 수 있습니다.

멀티에이전트 프로토콜 실험: 현재 단일 에이전트로 처리하는 복잡한 작업 중 일부를 전문화된 서브에이전트로 분리하는 실험을 시작하세요. 역할 경계 정의와 에이전트 간 컨텍스트 전달 방식이 핵심 설계 과제입니다.

장기 (18개월 이상)

적응형 하네스 구축: 충분한 메트릭 데이터가 쌓이면, 주기적으로 제약 수준을 자동 조정하는 시스템을 구축할 수 있습니다. 이때 사람이 검토할 수 있는 변경 이력과 롤백 메커니즘이 반드시 필요합니다.

요약

Harness Engineering은 모델 발전과 함께 진화합니다. 오늘의 복잡한 제어 로직이 내년의 불필요한 기술 부채가 될 수 있습니다. 적응형 하네스와 뽑기 쉬운 설계 원칙을 통해 모델 발전에 민첩하게 대응하는 구조를 만드세요. 하네스의 목표는 복잡성 구축이 아니라 에이전트가 올바른 결과를 낼 수 있는 최소한의 구조를 제공하는 것입니다.