AI 모델 비교 실험 설계 — 같은 프롬프트만으로 부족한 이유

두 AI에 같은 질문을 입력했다고 해서 공정한 비교가 끝나는 것은 아닙니다. 한쪽은 웹 검색과 터미널을 사용할 수 있고 다른 쪽은 대화만 했다면 모델보다 실행 환경의 차이를 측정한 셈입니다. 수정 기회를 한쪽에만 더 주거나 결과 형식을 다르게 요구해도 결론이 흔들립니다.

실제 업무를 작은 평가 세트로 만들고, 비교 중 바꿀 변수는 모델 하나로 제한하세요. 최종 결과가 승인될 때까지 필요한 시간과 비용을 기록하면 내 업무에 맞는 모델을 선택하는 근거가 됩니다.

결론 — 프롬프트보다 비교 계약을 먼저 고정하세요

비교 전에 다음 여섯 항목을 한 문서에 적습니다.

1. 입력: 질문, 파일, 이전 대화와 기준 문서
2. 환경: 모델 버전, reasoning effort, 도구, 권한
3. 산출물: 파일 형식, 길이, 저장 위치, 필수 항목
4. 시간: 시작·종료 기준과 마감
5. 수정: 추가 지시 횟수와 허용 범위
6. 평가: 통과 조건, 치명적 실패, 사람 검수 방법

아래 값과 사례는 실제 모델 실행 결과가 아니라 비교 설계 예시입니다. 독자는 자신의 업무 자료와 보안 정책에 맞춰 항목을 바꿔야 합니다.

같은 프롬프트가 공정성을 보장하지 않는 이유

이 보고서를 요약해 줘라는 문장은 같아도 제공된 PDF 버전, 검색 가능 여부, 출력 길이, 표 추출 방식이 다르면 결과는 비교할 수 없습니다. 코딩 작업도 저장소 상태와 설치된 의존성, 실행한 테스트가 다르면 모델 차이인지 환경 차이인지 알기 어렵습니다.

숨은 변수	비교가 흔들리는 예	고정 방법
모델 설정	한쪽은 높은 추론, 다른 쪽은 기본값	모델 ID와 effort 기록
대화 이력	한쪽에 이전 오류 설명이 남아 있음	질문별 새 세션 사용
자료 버전	정책 문서 개정일이 다름	파일 해시·버전 기록
도구	한쪽만 검색·터미널 사용	동일 도구 또는 도구 없음
권한	한쪽만 전체 저장소 읽기 가능	허용 경로 동일화
수정 기회	한쪽에만 재요청 세 번	최대 횟수와 시간 고정
완료 정의	한쪽은 초안, 다른 쪽은 테스트 통과	동일 완료 증거 요구

달라지는 조건을 알고 기록하세요. 제품마다 제공 도구가 달라 동일화할 수 없다면 모델 단독 비교와 제품 전체 경험 비교를 별도 실험으로 나눕니다.

비교할 업무를 여섯 종류로 구성하세요

좋아하는 예제 하나만 사용하면 그 유형에만 맞는 결론이 나옵니다. 작은 팀이 시작하기 좋은 평가 세트는 다음처럼 구성할 수 있습니다.

업무 유형	예시	확인할 실패
명확한 변환	JSON을 지정 표로 변환	필드 누락·형식 위반
근거 요약	정책 문서의 예외 조건 정리	원문에 없는 내용 추가
단일 파일 코드	입력 검증 함수 추가	테스트 실패·범위 밖 수정
다중 파일 코드	새 기능과 타입 연결	인터페이스 불일치·회귀
시각 산출물	반응형 랜딩 페이지	모바일 넘침·접근성 누락
장기 작업	자료 조사→분류→보고서	중간 결과 소실·무한 반복

각 업무에는 정상 입력뿐 아니라 정보가 부족한 입력, 충돌하는 요구, 도구 실패를 하나씩 포함합니다. 이런 상황에서 모를 때 멈추고 필요한 질문을 하는지도 확인하세요.

비교 실행표 만들기

다음 양식을 질문마다 복사합니다.

experiment_id=model-choice-20260925
case_id=multi-file-feature-01
model=[모델 ID]
model_mode=[reasoning/effort/fast 여부]
input_version=task-brief-v1
source_version=repo-commit-or-file-hash
tools=[허용 도구]
permissions=[읽기/쓰기 허용 경로]
time_limit_minutes=30
revision_limit=1

required=[반드시 충족할 조건]
forbidden=[하지 말아야 할 행동]
completion_evidence=[테스트/파일/URL/원문 위치]

started_at=
first_result_at=
finished_at=
input_tokens=
output_tokens=
tool_calls=
retries=
human_review_minutes=
result=pass|partial|fail|unknown
fatal_failure=
review_note=

unknown 상태가 중요합니다. 도구 호출이 시간 초과됐는데 실제 외부 작업이 실행됐는지 알 수 없다면 실패로 단순 처리하지 말고 결과 불명으로 남깁니다. 결제·메일·게시 작업은 결과 불명 상태에서 자동 재시도하면 중복 실행이 발생할 수 있습니다.

점수 전에 통과 조건을 확인하세요

평균 점수가 높아도 개인정보를 노출하거나 범위 밖 파일을 수정했다면 선택하기 어렵습니다. 먼저 통과·실패를 가른 뒤 통과한 결과끼리 품질을 비교합니다.

1단계: 치명적 실패

• 사실과 다른 핵심 결론
• 허용하지 않은 외부 발송·게시·결제
• 비밀키·개인정보 출력
• 범위 밖 파일 삭제 또는 대규모 변경
• 테스트 실패를 성공으로 보고

2단계: 요구 충족

• 필수 항목 포함
• 금지 항목 제외
• 결과 형식 준수
• 실행 또는 원문 대조 가능
• 완료 증거 제공

3단계: 운영 비용

• 최종 완료 시간
• 수정 요청 횟수
• 사람 검수 시간
• 토큰과 도구 비용
• 다음 사람이 이해하기 위한 정리 시간

세부 평가표가 필요하면 AI 답변 평가표 만들기의 정확성·근거성·완전성·형식 준수 기준을 연결해 사용할 수 있습니다.

반복 실행과 블라인드 검토

생성형 AI는 같은 입력에도 결과가 달라질 수 있습니다. 중요한 업무라면 질문당 한 번만 실행하지 말고 최소한 여러 번 실행해 흔들림을 확인합니다. 반복 횟수는 통계적 보장을 의미하는 고정 정답이 아니라 시작 규모입니다.

사람이 품질을 평가할 때는 가능하면 모델 이름을 A와 B로 바꾸고 결과 순서를 섞습니다. 브랜드 선호가 점수에 영향을 주는 것을 줄일 수 있습니다. 다만 도구 로그와 파일 경로처럼 모델을 추측하게 하는 정보까지 억지로 숨기지는 않습니다.

[블라인드 검토표]
case_id:
result_label: A | B
필수 조건 통과: yes | no
치명적 실패: none | 내용
근거 추적 가능: yes | partial | no
수정 없이 사용 가능: yes | no
검토자 메모:

시간을 네 구간으로 나눠 기록하세요

빠르다는 말에는 여러 시간이 섞여 있습니다.

1. 요청을 보낸 뒤 첫 출력까지
2. 전체 답변이 끝날 때까지
3. 도구와 테스트 실행이 끝날 때까지
4. 사람이 검수하고 최종 승인할 때까지

짧은 첫 응답이 나와도 테스트 수정에 오래 걸리면 최종 완료는 느립니다. 반대로 처음 계획에 시간이 들더라도 재작업이 적으면 전체 업무 시간은 줄 수 있습니다. 따라서 모델 선택에는 네 번째 시간인 승인 가능한 결과까지의 시간을 우선 사용합니다.

비교를 중단해야 할 때

• 두 모델의 도구와 권한을 같은 수준으로 맞출 수 없을 때
• 입력 자료에 개인정보나 영업 비밀이 포함됐지만 처리 조건을 확인하지 못했을 때
• 평가자가 무엇을 통과로 볼지 합의하지 못했을 때
• 모델 버전이나 제품 설정이 실행 중 바뀌었을 때
• 예산 상한이나 도구 호출 상한을 넘었을 때

조건이 바뀌면 기존 결과와 새 결과를 한 표에 이어 붙이지 말고 실험 버전을 나눕니다. 모델 또는 프롬프트 변경 전후를 운영 중 계속 확인하려면 AI 변경 전후 회귀 테스트의 질문 세트와 버전 기록 방식을 참고하세요.

실행 전 체크리스트

• 해결할 실제 업무 질문을 한 문장으로 적었다.
• 비교할 모델 ID와 모드를 기록했다.
• 자료·도구·권한·대화 이력을 동일하게 맞췄다.
• 필수·금지·완료 증거를 정의했다.
• 수정 기회와 시간·비용 상한을 정했다.
• 치명적 실패를 평균 점수와 별도로 본다.
• 실제 결과와 교육용 예시를 구분해 저장한다.

핵심 정리

평가할 업무 하나를 골라 입력·자료·도구·권한과 완료 기준부터 기록하세요. 실제 실행 전의 비교표는 검증할 가설과 실행 양식으로 구분해 공개하고, 실행 뒤에는 치명적 실패·요구 충족·검수 시간·최종 완료 비용을 채웁니다.