har_eval

증거-게이트 역량 결정 하네스 — “X를 만들·도입·유지할까?”를 의견·열정이 아니라 측정과 적대 감사로 결정한다.

개요

무엇을 푸는가

대부분의 AI 코딩 실패는 출력이 아니라 입력에서 일어난다 — 만들 필요가 없는 것을 만들기로 결정하는 순간이다. har_eval의 첫 임무는 “만들 이유를 찾는 것”이 아니라 “안 만들어도 되는지를 싸게 확인하는 것”이다.

흔한 정직한 결과는 두 가지다.

• 현재로 충분 — 빌드 없이 기존 스택으로 해결된다
• 기성 도구 채택 — 직접 만들지 않고 best-in-class를 가져온다

빌드는 데이터가 갭을 입증할 때만 정당화된다.

언제 쓰나

“도구·기능·시스템 X를 만들·도입할까?” 결정 — 특히 정직한 답이 “현재로 충분”일 수 있고, 잘못된 yes 가 실제 빌드 시간을 태우는 경우.

7단계 요약

1. Frame — 질문 1줄 + 잘못된 yes의 비용 명시
2. Inventory — 현재 시스템 실측 (active/dead/idle), 문서·기억 대신 확인
3. Design — 제안 설계 (옵션 2~3 + 추천)
4. Adversarial audit — 자기감사 → 교차모델(Codex) 검증 → 반증가능 게이트를 가진 de-risked plan
5. Buy-before-build — 만들기 전 축별 기성 best-in-class를 현재 스택에 붙여 테스트
6. Measure — 골든셋(실 태스크 + ground-truth) → Control vs 후보 arm(모델 고정) → 토큰·정답률
7. Decide(싼것부터) + Cleanup — 현재충분/채택/빌드 + 평가가 만든 고아 제거

산출물

판정 1건 + 신뢰도 라벨(measured-n / inferred / mechanism-backed) + 측정 수치 + 메커니즘 + 청소 내역. 안 돌린 arm의 결론은 inferred(저신뢰) 로 별표 분리한다.

주의: 측정하지 않은 후보를 “효과 없음”으로 단정하지 않는다. 안 돌렸으면 추론일 뿐, 측정이 아니다.

더 보기

• 방법론 — 7단계 상세 + 가드레일 10개
• 실전 사례 — 데이터로 “안 만든다”를 낸 결정들