AI Agent Fast Learning · 평가 설계
두 AI를 비교할 때는 같은 문제를 주는 것만으로 부족하다. 한쪽은 오전에 몰아서 실행하고 다른 쪽은 오후에 실행했다면, 점수 차이에 버전 차이와 시간대 차이가 함께 들어갈 수 있다. 이런 비교에서는 조건을 맞춰 묶고, 묶음 안의 실행 순서를 사전에 무작위로 정하는 설계가 도움이 된다.
앞선 글에서는 필요한 표본 수를 정하는 조건을 살폈다. 이번에는 확보한 사례를 어떤 순서로 실행할지 다룬다. 표본이 많아도 A와 B가 서로 다른 조건에서만 평가되었다면, 무엇이 결과를 바꿨는지 구분하기 어렵다.
A는 오전, B는 오후에 실행하면 생기는 문제
가상의 문서 요약 평가를 생각해 보자. 기존 버전 A를 오전에 모두 실행하고, 개선 버전 B를 오후에 모두 실행한다. 그 사이 검색 자료가 갱신되거나 서버 혼잡도가 달라졌다고 가정하면, 관측된 차이를 프롬프트 수정만의 효과로 해석하기 어렵다. 지연 시간을 비교한다면 혼잡도가, 답변의 사실성을 비교한다면 검색 자료의 변경이 특히 문제가 될 수 있다.
이것은 실제 서비스에서 확인한 사건이 아니라 설계상 가능한 상황이다. 핵심은 ‘오후가 더 나쁘다’가 아니다. 버전과 실행 시점이 함께 바뀌면 두 요인의 영향을 분리하기 어려워진다는 데 있다.
비슷한 조건끼리 묶고, 묶음 안에서 비교한다
블록(block)은 비교에 영향을 줄 수 있는 조건을 비슷하게 맞춘 묶음이다. NIST는 통제할 수 있는 주요 방해 요인을 블록으로 다루고, 나머지 요인의 영향을 줄이기 위해 무작위화를 활용하는 원칙을 설명한다. 블록을 만들었다면 분석에서도 그 구조를 반영해야 한다. NIST: Randomized block designs, 확인 2026-10-16.
이를 문서 평가에 적용하는 한 가지 설계 제안은 다음과 같다. 동일한 문서 사본을 A와 B에 각각 제공하고, 두 실행을 가능한 한 가까운 시간에 배치한다. 문서마다 A를 먼저 실행할지 B를 먼저 실행할지는 결과를 보기 전에 무작위로 정한다. 이렇게 하면 문서의 난이도는 짝 안에서 맞추고, 특정 버전이 늘 먼저 실행되는 상황도 피할 수 있다. 다만 가까운 시간에 실행했다는 이유만으로 모든 환경 조건이 같아지는 것은 아니다.
NIST의 완전 무작위 설계 설명에서도 실행 순서를 무작위로 정하는 방법을 다룬다. 무작위화는 유리한 순서를 결과에 맞춰 골라 쓰는 절차가 아니다. 실행 전의 배정 규칙이며, 한 번의 작은 평가에서 환경 차이가 완벽하게 균형 잡힌다는 보장도 아니다. NIST: Completely randomized designs, 확인 2026-10-16.
순서 섞기 전에 실행 상태부터 분리한다
A가 먼저 처리한 결과를 B가 읽을 수 있다면 순서를 바꾸는 것만으로 공정해지지 않는다. 같은 대화 기록, 수정된 파일, 검색 인덱스나 캐시가 다음 실행에 영향을 줄 수 있기 때문이다. 비교 대상 외의 입력과 초기 상태를 같게 맞추되, 서로의 결과가 섞이지 않는 실행 공간을 준비한다.
파일을 수정하거나 외부 시스템에 쓰는 에이전트라면 특히 주의해야 한다. 실제 고객 데이터에 A와 B를 차례로 적용하는 대신, 허가된 시험 환경의 동일한 초기 사본에서 각각 시작하는 편이 낫다. 초기 상태를 복구할 수 없거나 두 실행이 서로 영향을 주는 구조라면 이 글의 단순한 짝 비교를 그대로 적용하지 않는다. 사용자·조직·시간 구간 등 더 큰 배정 단위가 필요할 수 있다.
실행 순서표에 남길 최소 항목
아래는 성능 결과가 아닌 기록 양식 제안이다. 성공률이나 개선 폭은 아직 적지 않는다.
• 사례 ID와 입력 버전: 같은 문서를 비교했는가?
• 블록 또는 묶음 ID: 문서, 시간 구간 등 무엇을 맞췄는가?
• 배정된 순서: A→B인가, B→A인가?
• 실제 시작·종료 시각: 계획과 달라진 부분은 무엇인가?
• 모델·프롬프트·도구·검색 자료 버전: 비교 도중 바뀌었는가?
• 초기 상태와 격리 여부: 앞선 실행의 결과를 읽을 수 있었는가?
• 결과·실패·미확인 및 사유: 빠진 실행도 남겼는가?
순서를 만드는 난수 시드만 저장하면 충분하다고 생각하기 쉽다. 실제 배정표도 함께 보존하자. 시드가 같아도 생성 코드나 입력 목록이 달라지면 같은 계획을 복원하지 못할 수 있다. 기록에는 재현에 필요한 설정만 남기고 비밀번호·키·불필요한 원문 개인정보는 넣지 않는다.
간단한 실습: 실행 없이 순서표 만들기
서로 다른 문서 네 개를 가정하고, 각 문서에 A와 B를 한 번씩 배치해 보자. 각 문서에서 동전 앞면이면 A→B, 뒷면이면 B→A로 순서를 정하고 결과를 적는다. 이때 문서 네 개는 순서표를 배우기 위한 수일 뿐, 충분한 평가 표본이라는 뜻이 아니다. 우연히 A가 먼저인 경우만 나올 수도 있다.
작은 계획에서도 먼저 실행하는 버전의 수를 같게 맞추고 싶다면, A→B 카드 두 장과 B→A 카드 두 장을 만들어 섞은 뒤 문서에 배정할 수 있다. 이것은 균형을 제한 조건으로 둔 무작위 배정의 교육용 예다. 결과가 마음에 들 때까지 다시 섞지 않고, 채택한 규칙과 표를 실행 전에 확정한다. 문서의 실행 순서도 별도로 정해 둔다.
실습 점검: 문서마다 A와 B가 모두 있는가? 각 실행의 초기 상태가 분리되어 있는가? 계획한 순서와 실제 순서를 구분해 기록할 수 있는가? 실패한 실행을 지우지 않고 남길 칸이 있는가? 네 질문에 답할 수 있으면 API를 호출하지 않고도 비교 계획의 기본 형태를 갖춘 것이다.
순서표를 잘 만들었다고 결론까지 보장되지는 않는다
분석할 때는 같은 문서의 A·B 결과를 짝지어 다룬다. 같은 문서를 여러 번 실행했다면 반복 수를 독립 문서 수로 세지 않는다. 시간 블록이나 고객별 묶음이 추가되었다면 그 구조에 맞는 분석이 필요하다. 성공 여부와 지연 시간은 자료의 성격이 다르므로 하나의 검정법을 무조건 적용하지 않는다.
무작위 실행 순서는 평가 대상 문서가 실제 업무를 대표한다는 보장도 하지 않는다. 쉬운 문서만 골랐다면 순서를 아무리 공정하게 정해도 어려운 업무의 성능은 알 수 없다. 표본을 고르는 일, 실행 조건을 맞추는 일, 결과의 불확실성을 계산하는 일은 각각 확인해야 한다.
평가를 시작하기 전, 순서표에서 A만 있는 시간대와 B만 있는 시간대가 길게 갈라져 있는지 살펴보자. 그 구간에서 환경이 달라졌다면 무엇을 근거로 버전의 효과라고 말할 수 있을지 답해 보는 것이다. 답이 없다면 실행 횟수를 늘리기 전에 배치를 고치는 편이 먼저다.
이어 읽기와 자료의 범위
검정력과 최소 탐지 효과로 표본 수 정하기
반복 실행과 독립 평가 단위
이 글은 NIST의 실험 설계 원칙을 AI 비교 평가에 적용한 교육용 제안이다. 문서 평가 상황과 순서표는 가상 예시이며, 모델 실행·서비스 성능 측정·통계 검정을 수행한 결과가 아니다. 공식 자료 확인일은 2026-10-16이다.