Mar 30, 2026

Harness Engineering 가이드: 프롬프트보다 eval이 더 중요해지는 이유

코딩 에이전트와 추론 모델이 강해질수록 덜 믿을 수 있게 되는 습관이 하나 있습니다. 프롬프트를 조금 바꾸고, 데모가 그럴듯해 보이면 시스템이 좋아졌다고 느끼는 방식입니다.

바로 이 지점에서 harness engineering이 중요해집니다. 목표는 한 번의 데모를 더 좋아 보이게 만드는 것이 아닙니다. 여러 실제 작업에서 변화를 테스트하고, 비교하고, 신뢰할 수 있는 환경을 만드는 것입니다.

이 글은 아래 질문을 실전 기준으로 정리합니다.

harness engineering은 무엇인가
왜 모델이 강해질수록 더 중요해지는가
작은 제품 팀은 무엇부터 만들어야 하는가

짧게 말하면 프롬프팅도 여전히 중요하지만, harness는 프롬프트와 도구와 워크플로가 실제로 좋아졌는지 알려주는 시스템입니다.

harness engineering이란 무엇인가

harness engineering은 LLM 시스템 바깥쪽의 테스트 루프를 만드는 작업입니다.

보통 harness에는 아래가 들어갑니다.

대표적인 작업 집합
입력과 기대 결과
반복 가능한 실행 환경
점수화 또는 평가 규칙
실행 후 확인할 수 있는 로그

쉽게 말하면 팀이 “이 변경이 시스템을 정말 더 좋게 만들었나?”라고 물을 수 있게 해주는 장치입니다.

왜 프롬프트 수정만으로는 부족해지나

워크플로가 단순할 때는 직접 프롬프트를 고치고 몇 번 수동 확인하는 것만으로도 충분할 수 있습니다.

하지만 시스템이 아래처럼 바뀌면 그 방식이 무너지기 시작합니다.

여러 단계를 거치고
도구를 호출하고
코드를 수정하고
부분적으로 자율적으로 움직일 때

이 시점에는 그럴듯한 한두 개 예시가 강한 증거가 아닙니다. 작은 프롬프트 개선처럼 보여도 신뢰성, 안전성, 지연 시간, 출력 품질에서 regressions가 숨어 있을 수 있습니다.

그래서 모델이 더 강해질수록 harness engineering은 오히려 더 중요해집니다.

OpenAI 글이 짚은 핵심

OpenAI의 harness engineering 글이 강조하는 핵심은 실용적인 방향 전환입니다. 모델이 더 많은 일을 할 수 있게 되면, 병목은 종종 모델이 아니라 그것을 검증하는 환경으로 이동합니다.

이 포인트는 의외로 놓치기 쉽습니다. 많은 팀이 모델이 강해질수록 평가가 덜 필요하다고 생각하지만, 실제로는 반대인 경우가 많습니다.

더 강한 모델은 더 어려운 작업을 시도하고
더 어려운 작업은 더 많은 실패 경로를 만들고
더 많은 실패 경로는 더 좋은 eval coverage를 요구합니다

즉 진짜 병목은 “프롬프트를 어떻게 쓰지?”에서 “이 시스템이 정말 좋아지고 있다는 걸 어떻게 아나?”로 이동합니다.

원문: OpenAI - Harness engineering

좋은 harness에는 무엇이 들어가나

처음부터 거대한 플랫폼이 필요한 것은 아닙니다. 시작에 유용한 harness는 몇 가지 요소만 있어도 됩니다.

1. 실제 작업을 반영하는 task set

task set은 사용자가 실제로 중요하게 여기는 작업과 닮아 있어야 합니다. 보기 좋은 데모만 모아두면 도움이 적습니다.

좋은 task set에는 보통 아래가 들어갑니다.

일반적인 작업
귀찮은 edge case
실패가 잘 나는 case
비슷해 보여도 다른 행동이 필요한 작업

2. 분명한 pass/fail 기준

평가 기준이 흐리면 결과도 흐려집니다.

어떤 시스템은 정답 일치가 기준일 수 있고, 다른 시스템은 아래처럼 볼 수 있습니다.

테스트가 통과했는가
답변에 필요한 필드가 들어갔는가
금지된 행동을 하지 않았는가
최종 출력이 요청한 형식을 지켰는가

3. 재현 가능한 실행

실행 환경이 매번 바뀌면 harness의 가치도 크게 떨어집니다.

입력 데이터가 안정적이고, 사용 가능한 도구가 명시적이며, 결과 기록이 남아야 합니다.

4. 실패 분석 가능성

팀은 전체 점수 하나보다 “왜 실패했는지”를 볼 수 있을 때 훨씬 빨리 개선합니다.

그래서 아래 기록이 중요합니다.

raw output
필요하면 tool trace
timing 정보
사용한 prompt, tool policy, workflow 버전

코딩/에이전트 워크플로를 위한 간단한 harness 예시

많은 개발 팀에게 첫 harness는 생각보다 단순할 수 있습니다.

[
  {
    "task": "실패하는 unit test 고치기",
    "input": "repo snapshot + failing test output",
    "success": "다른 테스트를 깨지 않고 테스트 통과"
  },
  {
    "task": "pull request 위험 요약",
    "input": "git diff",
    "success": "고위험 이슈를 분명하게 짚음"
  }
]

중요한 것은 포맷이 아닙니다. 프롬프트, 도구 접근, 정책을 바꾼 뒤 같은 작업을 다시 돌려서 결과를 정직하게 비교할 수 있느냐가 중요합니다.

팀이 처음 많이 실패하는 지점

1. 쉬운 예시만 벤치마크함

harness가 깔끔한 데모 과제만 담고 있다면 실제 운영 행동을 거의 알려주지 못합니다.

2. 하나의 점수만 보고 failure shape를 놓침

평균 성능은 좋아져도 중요한 edge case에서는 더 나빠질 수 있습니다.

3. 실패를 어떤 변경과 연결해야 하는지 모름

어떤 프롬프트, 도구 접근, 정책 버전에서 나온 실패인지 기록하지 않으면 디버깅이 어렵습니다.

4. 검증 전에 과하게 시스템을 만듦

작고 실제적인 task set으로 시작하기보다 완벽한 eval 플랫폼을 먼저 설계하려는 경우가 많습니다.

작은 팀이라면 무엇부터 만들어야 하나

초기에는 신뢰를 만드는 가장 작은 루프부터 만드는 것이 좋습니다.

보통은 아래 정도면 충분합니다.

실제 작업 20개에서 50개 모으기
단순한 성공 규칙 정하기
큰 변경 뒤마다 같은 케이스 다시 돌리기
실패 케이스는 사람이 직접 검토하기
반복되는 고통을 줄이는 지점만 자동화하기

실제 실패 패턴도 모른 채 몇 주 동안 일반 프레임워크를 만드는 것보다 이 방식이 훨씬 낫습니다.

harness engineering과 prompt engineering의 관계

prompt engineering과 harness engineering은 서로 대체 관계가 아닙니다.

관계를 단순하게 보면 이렇습니다.

prompt engineering은 행동을 바꾸고
harness engineering은 그 행동을 측정합니다

프롬프트가 없으면 시스템을 개선하기 어렵고, harness가 없으면 개선이 진짜인지 알기 어렵습니다.

그래서 더 강한 agent 시스템일수록 둘 다 필요해집니다.

왜 agent 제품에서 더 중요해지나

이 주제는 단일 턴 채팅보다 agent 제품에서 훨씬 더 중요합니다.

agent 제품은 보통 아래를 포함합니다.

tool call
retry
분기 결정
여러 단계 계획
긴 execution trace

이런 시스템은 단순 Q&A보다 실패 지점이 훨씬 많습니다. harness는 최종 답변 한 문장만 보는 대신 전체 루프를 테스트할 수 있게 해줍니다.

에이전트 워크플로를 더 운영적으로 보고 싶다면 AI Agent Guide와 AI Agent Skills Guide를 같이 보면 좋습니다.

FAQ

Q. harness engineering은 그냥 eval의 다른 이름인가요?

완전히 같지는 않습니다. eval이 중심이지만, harness engineering은 보통 그 주변의 테스트 환경, task setup, scoring, failure inspection 루프까지 함께 포함합니다.

Q. 팀은 언제 harness를 만들기 시작해야 하나요?

모델 사용이 “프롬프트 하나, 답변 하나”에서 벗어나 반복적으로 개선할 시스템이 되기 시작할 때입니다.

Q. 작은 팀도 이런 게 필요한가요?

네. 규모만 작으면 됩니다. 스프레드시트와 반복 가능한 task set만 있어도 정직한 비교가 가능하면 그것도 충분히 harness입니다.

Q. 가장 큰 실수는 무엇인가요?

변경할 때마다 안정적인 비교 작업을 돌리지 않고, 직감과 몇 개의 데모만 보고 좋아졌다고 판단하는 것입니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.