AI 도구는 신뢰할 수 있게 되기 훨씬 전부터 그럴듯해 보일 수 있습니다. 잘 다듬어진 결과는 한 입력이 한 번 수용 가능한 출력을 만들었다는 사실만 증명합니다. 자동화에는 작업 경계가 안정적이고, 실패가 보이며, 잘못된 결과가 후속 작업을 오염시키지 않은 채 복구될 수 있다는 더 강한 근거가 필요합니다.
평가는 모델 비교 전에 시작해야 합니다. 먼저 도구가 무엇을 해도 되는지 정의하세요.
작업 계약 고정하기
네 가지를 적습니다.
- 도구가 사용할 수 있는 입력 사실
- 반드시 반환해야 하는 출력 필드
- 만들어 내면 안 되는 주장이나 변환
- 검토자가 결과를 승인하는 조건
제품 설명 도구는 제공된 사실을 재구성할 수 있지만 소재, 인증, 성능 주장, 고객 결과를 지어내면 안 됩니다. SQL 디버거는 가능성 있는 정확성·성능 문제를 설명할 수 있지만 Schema가 없다면 Schema 의존 주장을 조건부로 유지해야 합니다.
이 경계가 없으면 평가는 취향 테스트가 됩니다. 도구가 다른 작업을 해결했는데도 유창한 출력이 높은 점수를 받게 됩니다.
경계 사례보다 대표 입력을 먼저 테스트하기
실제 사용을 대표하는 소수의 일반 사례로 시작합니다. 목적은 계약이 일관적인지 확인하는 것이지, 처음부터 희귀한 오류를 찾는 것이 아닙니다.
출력 요구사항은 유지하고 입력 사실만 바꿉니다. 필수 필드 존재, 제공 사실 보존, 근거 없는 주장 부재, 요청 형식 준수처럼 직접 관찰할 수 있는 항목을 확인합니다.
일반 사례가 통과한 뒤 누락 필드, 모순, 매우 긴 입력, 모호한 지시, 거절해야 할 내용을 추가합니다.
결정적 검사와 판단을 분리하기
필수 제목 존재 여부, JSON Schema 통과 여부, 제품 주장이 원본 사실에 있는지는 정확하게 확인할 수 있습니다. 반면 요약이 핵심 주의사항을 보존하는지, 시각 Brief가 의도한 분위기인지, 설명이 대상 독자에게 유용한지는 검토자의 판단이 필요합니다.
결정적 실패는 자동으로 승인을 막아야 합니다. 주관적 점수는 검토자, 루브릭, 증거를 남겨 다른 사람이 판단을 이해할 수 있게 합니다.
성공뿐 아니라 실패 동작 테스트하기
AI 도구가 워크플로에 들어가기 전에 알려진 실패를 최소 한 번 강제로 만들고, 부분 출력이 완성된 것처럼 후속 단계로 전달되지 않는지 확인합니다.
안전한 실패는 세 질문에 답해야 합니다.
- 무엇이 실패했는가?
- 어떤 승인된 입력이나 결과물이 여전히 유효한가?
- 다시 시도하기 위한 최소 행동은 무엇인가?
유일한 복구 방식이 “전부 다시 실행”이라면 아직 워크플로 노드로 사용할 준비가 되지 않았습니다.
자신감이 아니라 증거를 승격하기
공개된 주장이 실제 수집한 증거와 일치할 때만 도구를 Demo에서 평가 완료 상태로 옮겨야 합니다. 소수의 통제된 사례는 좁은 작업 주장을 뒷받침할 수 있지만 보편적 정확도, 공급자 가동 시간, 서로 다른 작업 간 순위까지 증명하지는 않습니다.
이 절제는 제품 설계입니다. 사용자가 의존할 수 있는 범위를 알려 주고, 개발자가 관찰해야 할 상태를 알려 주며, 다음 단계에 적합한지 검증되지 않은 출력을 자동화가 증폭하는 것을 막습니다.