Harness Engineering의 진화 방향

모델은 빠르게 발전한다

모델이 발전하면 특정 약점을 보완하던 제어 로직을 줄일 수 있습니다. 하지만 새 모델이 이전 모델보다 모든 작업에서 낫거나, 검증·권한 검사가 불필요해진다고 가정하지 않습니다. 변경할 때는 동일 작업·예산의 평가로 어떤 구성요소가 여전히 필요한지 확인합니다.

자율성 스펙트럼

다음 수준은 설계상 구분이며 업계 채택률이나 제품별 고정 점수가 아닙니다.

수준	실행 범위	확인할 정책
수동	사람이 매 행동을 선택	제안과 실제 실행 구분
보조	에이전트가 변경을 제안	사람 검토 후 적용
제한적 자율	승인된 범위에서 구현·테스트	경로·도구·예산 경계
예외 중심 감독	사전 정의된 정책으로 반복 작업	중단·에스컬레이션·감사

도메인별 자율도는 되돌릴 수 있는지, 피해 범위와 결과를 검증할 수 있는지로 결정합니다. “2026년 대부분의 팀이 50~75% 자율화됐다”는 식의 수치는 조사 방법과 표본이 없으면 인용하지 않습니다.

작업	자율화 전 확인할 근거
소프트웨어 테스트	테스트가 요구사항과 실패 조건을 검사하는지
코드 리뷰	탐지율·오탐률과 사람이 놓친 결함
문서 생성	출처 충실성·최신성·검토 비용
인프라 변경	대상·조건·복구 경로와 승인
보안 결정	독립 평가와 강제 가능한 권한 경계

단일·멀티에이전트의 선택

단일 에이전트와 전문화된 팀은 현재 모두 사용하는 패턴입니다. 멀티에이전트가 미래의 필수 단계라고 보지 않고, 독립적인 병렬 작업과 컨텍스트 분리가 실제로 도움이 되는지 측정합니다. 추가 에이전트는 통신·검증·추론 비용도 늘립니다.

단일 실행: User → MainAgent → tools
분업 실행: User → Coordinator → Research / Code / Review

에이전트 수가 늘어날 때는 역할·파일 소유권·완료 기준과 결과 전달 형식을 명시합니다. 공유 파일이나 상태를 동시에 수정하는 비용까지 비교합니다.

적응형 하네스

모델·업무가 바뀌면 성능을 다시 측정하고 프롬프트 상세도·재시도·압축 정책을 조정할 수 있습니다. 아래는 실험 정책의 예시이며 접근 권한과 필수 승인을 자동 완화하는 기능이 아닙니다.

적응 사이클

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

자동 제약 완화 예시

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: DEFAULT_CONSTRAINT_LEVEL.humanCheckpoints,
      retryPolicy: { maxAttempts: 2, backoffMs: 1000 }
    }
  }

  if (successRate < 0.7 || errorRate > 0.3) {
    // 모델이 불안정 → 제약 강화
    return {
      scaffoldingDetail: 'verbose',
      verificationSteps: 5,
      humanCheckpoints: [...new Set([
        ...DEFAULT_CONSTRAINT_LEVEL.humanCheckpoints, 'code-review', 'test-review',
      ])],
      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: '예시: 기준 과제에서 단계별 분해 유무에 따른 실패를 비교한다',
  successMetric: '작업 완료율 > 85%',
  removeCondition: '3개월 연속 작업 완료율 > 95% 유지 시',
  lastEvaluated: '2026-01-15'
}

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

모델 변경 때 검증할 가설

다음 표는 확정된 미래나 채택률 전망이 아니라 자체 평가에서 확인할 가설입니다.

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

지금 준비해야 할 것

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

단기 (6개월 이내)

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

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

중기 (6~18개월)

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

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

장기 (18개월 이상)

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

요약

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