Harness² — 반복 작업 하네싱은(는) 무엇을 하나요?

Harness²: Recursive Agent Harnessing for an Open World를 각색한 것으로, 한 번의 실행이 이미 수락되었고, 이를 반복하는 것이 목표인 경우에 맞게 축소되었습니다.

개요

한 번 성공하는 것과 반복 가능한 것은 다릅니다. 수락된 실행은 유일하게 신뢰할 수 있는 참조점입니다. 실제 산출물, 실제 궤적, 그리고 사용자가 직접 편집한 부분이 모두 포함되어 있습니다.

최적화의 대상은 다음 실행의 프로세스이지, 현재 실행의 산출물이 아닙니다. 따라서 출력은 더 나은 보고서가 아니라 하네스, SOP, 회귀 테스트 체크리스트입니다.

사용 시점

사용자가 "이제 매주 이 작업을 할 거예요" 또는 "이 프로세스를 고정합시다"라고 말할 때
동일한 종류의 작업이 최소 한 번 수행되었고, 그 결과가 수락되었을 때
프로세스가 누군가의 머릿속에만 존재할 때: 어떤 스크립트를 먼저 실행하는지, 어떤 단계에서 사람의 확인이 필요한지, 함정이 어디 있는지 등
동일한 유형의 작업이 동일한 방식으로 계속 실패할 때: 출처 누락, 일관되지 않은 정의, 지속적인 재작업

사용하지 말아야 할 때

일회성 작업 → 그냥 수행하세요
실제 평가자, 단위 테스트, 또는 계산 가능한 수락 기준이 존재하는 경우 → 그것을 사용하세요. 행동 대비(behavioral contrast)보다 훨씬 뛰어납니다.
사용자가 형식이나 정의 변경만 원하고, 무엇을 바꿀지 이미 말한 경우 → 하네스를 직접 편집하고, 대비 루프를 건너뛰세요.
프로세스가 이미 안정적이고, 비용이나 지연 시간이 중요한 경우

하네스란 무엇인가

모델 주변에서 편집 가능한 모든 것입니다. 최소 4개면 실행 가능하며, 전체는 8개입니다:

구성 요소	역할	최소
시스템 프롬프트	역할, 출력 계약	✅
도구 지침	각 데이터 소스를 사용할 시기, 인수 채우는 방법	✅
스킬	재사용 가능한 판단 및 절차	✅
가드레일	하드 제약 (숫자 절대 지어내지 않기, 출처 항상 인용)	✅
메모리	인스턴스 간에 전달되는 도메인 노트
스크립트	결정론적 작업 (변환, 중복 제거, 집계)
서브 에이전트	분할된 검증 또는 병렬 검색
플러그인	미들웨어 (매 N 단계마다 자체 점검 강제)

하네스는 비교(diff) 및 재사용이 가능하도록 파일로 존재해야 합니다. 채팅 내에 "우리는 보통 이렇게 해요"라고 남겨두는 것으로는 견고해질 수 없습니다.

루프: 제안 → 탐침 → 구성 (Propose → Probe → Compose)

0. 기준선 고정

마지막 실행을 전체 보관합니다: 하네스 스냅샷, 전체 궤적 (도구 호출 시퀀스 + 중간 산출물), 최종 산출물, 사용자의 편집 diff, 수락 기준, 데이터 스냅샷 또는 시간 창.

사용자가 직접 편집한 부분은 신뢰도가 높은 결함 위치입니다 — 어떤 추측보다 신뢰할 수 있습니다.

1. 제안 (Propose)

기준선을 읽은 후, 각각 결함을 대상으로 하는 한 문장의 이름을 붙여 두 개의 후보를 제안합니다:

불변 (invariant): 프로세스 결함 — 교차 검증 없음, 중간 결과 미보존, 실패 시 재시도 없음, 출처 미표시, 컨텍스트 과다
도메인 (domain): 이 작업 클래스의 전문적 제약 — 일관된 정의, 통화 또는 단위 변환, 정렬된 시간 창

두 가지 모두 필요합니다. "일반적인 문제"와 "이 작업 클래스 특화 문제"를 분리하기 위해서입니다. 단일 후보로는 결과를 귀인할 수 없습니다.

2. 탐침 (Probe)

동일한 입력으로 재실행하며, 변수를 제어합니다: 동일한 모델, 동일한 도구 세트, 동일한 데이터 스냅샷. 하네스만 변경됩니다.

두 가지를 비교합니다:

기준선 대비 행동 변화 (Behavioral delta): 도구 세트 및 순서, 단계 수, 반복 호출, 오류 및 재시도, 사람이 패치하던 지점이 사라졌는지, 중간 결과가 보존되었는지, 출처가 완전히 표시되었는지
재실행 일관성 (Replay consistency): 다시 실행했을 때 구조가 동일한가? 견고화의 핵심 지표는 단일 실행 최고 성능이 아닌 안정성입니다.

대비(contrast)는 "행동이 변했다"를 보여줍니다. "결과가 옳다"는 보여주지 않습니다. 둘을 혼동하지 마십시오.

3. 구성 (Compose)

(a) 재실행 후에도 여전히 수락 기준을 충족하고 (b) 재작업이나 사람의 패치를 줄이는 변경 사항만 유지합니다. 원본을 유지하는 것도 허용됩니다 — 증거 없는 변경은 노이즈일 뿐입니다.

모든 결정을 한 줄로 기록합니다: 변경 | 대상 결함 | 관찰된 증거 | 채택 / 수정 / 폐기.

4. 견고화 (Solidify)

세 가지 산출물; 하나라도 없으면 견고화되지 않은 것입니다:

harness/ — 편집 가능한 파일
SOP.md — 단계, 체크포인트, 사람에게 물어봐야 할 때, 알려진 함정 (항목이 10개가 넘으면 아무도 읽지 않습니다)
REGRESSION.md — 다음 실행 후 확인할 수락 체크리스트

변경 사항이 여러 라운드에 걸쳐 채택되면, 독립형 스크립트나 스킬로 승격하세요.

증거 계층

사용자 편집 diff > 수락된 산출물과의 비교 > 재실행 일관성 > 궤적 변화 > 직관

증거가 아닌 것: 더 길거나 상세한 보고서, "이번에는 사용자가 불평하지 않았다", 모델이 더 잘했다고 주장하는 것

예산

기본값 k=1에 한 번의 재실행을 더합니다. 견고화는 시간이 지남에 따라 효과가 나타나므로, 라운드에 걸쳐 분할 상환하세요: 모든 병렬 분기를 한 번에 3배 비용을 들여 실행하는 대신, 각 반복 실행 중에 한 후보씩 탐침하세요.

위험 신호 — 발견 시 중단

사용자의 편집 diff를 읽지 않고 이전 하네스를 전부 그대로 가져오는 경우
다른 입력, 모델, 또는 데이터 스냅샷으로 재실행하고 여전히 "더 낫다"고 주장하는 경우
단 한 번의 재실행만으로 무작위성을 배제하지 않고 결론을 내리는 경우
다섯 가지 구성 요소를 동시에 변경하여 귀인이 불가능한 경우
다음 번에 아무도 따르지 않을 20개 항목의 SOP
일회성 행운의 트릭을 불변 항목에 기록하는 경우

일반적인 실수

실수	결과	수정
아카이빙 전에 최적화	기준선 손실, 변경 사항 귀인 불가	먼저 기준선을 고정하세요
"읽기 더 좋다"를 증거로 사용	프로세스가 아닌 선호도를 견고화	구체적인 관찰과 연결하세요
프롬프트만 변경, 체크포인트 없음	다음 번에도 사람이 수동 패치	모든 결함을 체크포인트와 짝지으세요
여행기 형식의 SOP	아무도 읽지 않으므로 견고화되지 않음	의사 결정 지점과 함정만 작성하세요

Harness² — 반복 작업 하네싱