동일한 테스트 설계에 대해 Claude Fable 5와 Opus 4.8로 리뷰를 시켰더니 발견되는 결함의 클래스가 달랐다

1. 서론

도모, 료상입니다.

저는 QA 엔지니어로, 평소 테스트 설계에 생성 AI (Claude)를 사용하고 있습니다.

어제, Claude와 Codex 중 어느 쪽이 사양서 리뷰에 적합한가 — 둘 다 별 차이 없었다는 결론의 기사를 올렸습니다. 그것은 이종 모델 간 (Claude vs Codex)의 비교였으며, 결론은 "모델 자체보다 무엇을 지적하게 할지를 결정하는 프롬프트가 더 효과적이다"였습니다.

본 기사는 그 후속편입니다. 이번에는 동일한 Claude 내에서의 강도 차이 — Fable 5와 Opus 4.8 — 를 프롬프트, 입력, thinking 설정을 완전히 고정한 채 측정해 보았습니다. 결과는 지난번과 대조적이었으며, 이번에는 확실하게 갈렸습니다.

저는 테스트 설계의 각 공정 출력을 별도의 AI 에이전트에게 독립적으로 리뷰시키는 구성(생성 역할과 리뷰 역할을 분리)으로 운용하고 있습니다. 이번에 그 리뷰 역할에 어느 정도 강도의 모델을 배치해야 할지 판단할 필요가 생겨서, 동일한 테스트 설계 결과물을 강도가 다른 두 모델에 독립적으로 리뷰시키는 A/B 실험을 진행해 보았습니다. 결과가 예상보다 깔끔하게 갈렸기에 기사로 공유합니다.

실험 실행과 집계 모두 Claude Code상에서 수행했습니다.

먼저 결론부터 말씀드리면:

형식적인 미비점(값의 타입 불일치, 필수 필드의 null)은 두 모델 모두 잡아낼 수 있습니다. 차이가 나타난 것은 "형식은 존재하지만 내용이 수반되지 않는" 클래스였습니다. — 실재하지 않는 출처에 대한 참조, 검증 목적과 입력 데이터의 괴리, 해석에 따라 기대값이 정반대가 되는 케이스 등. Opus 4.8 측의 실패 양식은 일관되었습니다: "인용이 있다 → 커버되어 있다", "재계산이 맞다 → 테스트 케이스는 타당하다", "기계 검사가 통과한다 → 규약 준수"와 같이, 형식의 존재로부터 내용의 충족을 추론하는 패턴입니다.
리뷰 역할에 어느 정도 강도의 모델을 배치할지는 비용의 문제가 아니라, 어떤 클래스의 결함을 통과시킬 것인가의 선택이 된다는 것이 실험 후의 실감입니다.

2. 실험 설계

대상은 테스트 설계 파이프라인이 과거에 생성한 "테스트 설계서 + 테스트 케이스 목록(JSON)"의 동결된 결과물입니다. 이에 대한 독립 리뷰 공정(테스트 케이스가 사양에 접지되어 있는지, 기대값이 규약대로인지를 검사하는 공정)을 모델만 바꿔서 재실행했습니다.

소재는 공개 소재 3개: ASTER 테스트 설계 콘테스트 '14의 자판기(106 케이스), 단단 동물원(55 케이스), 테스트 설계 콘테스트 U-30 샘플인 더치페이 앱(73 케이스)
모델은 Claude Fable 5와 Claude Opus 4.8 (이하 Fable 5 / Opus 4.8). 비교 편의를 위해 나열하지만, Opus 4.8도 실시 시점에서 충분히 상위 모델입니다.
각 소재에 대해 두 모델을 각각 1회씩(총 6회) 실행. 지시문, 입력, thinking 설정은 모두 동일하며, 바꾼 것은 모델뿐입니다.
과거의 리뷰 결과에 휘둘리지 않도록 기존 리뷰를 제거한 복사본 위에서 실행.
중대 판정된 지적 사항은 전건, 수작업과 기계로 검증(grep, 재계산, 원전과의 대조)했습니다. "AI가 그렇게 말했다"를 결과로 치지 않기 위해서입니다.

3. 결과

소재 1: ASTER 자판기 — 기대값이 "정반대"가 되는 분기

결정타는 "판매 가능 시간의 기본값 00:00~00:00"이었습니다. 사양을 솔직하게 읽으면 "24시간 판매"로도, "판매 시간 폭 제로 = 판매하지 않음"으로도 해석될 수 있습니다 (콘테스트 소재로서 의도적인 모호함이라고 생각합니다). 어느 해석을 취하느냐에 따라 테스트의 기대값이 정반대가 됩니다.

Fable 5: 기대값의 대립으로 에스컬레이션 (인간의 판단으로 넘김). 중대 4건 + 기대값 대립 3건
Opus 4.8: "대립 없음·조건부 승인". 중대 0건

소재 2: 단단 동물원 — 가짜 출처와 가짜 검증

테스트 케이스 3건이 "데이터 연계 사양서 p.28의 1초 요건"을 근거로 인용하고 있었으나, 해당 문서에 "1초"라는 기술은 존재하지 않았습니다 (grep 결과 0건. 실제로 존재하는 것은 다른 문서의 p.28이었습니다). 게다가 설계서의 "최종 확인" 섹션은 이 참조를 "재독·확인 완료"라고 선언하고 있었습니다. 검증했다고 주장하면서 검증하지 않음 — AI 생성물 특유의 무서움이라고 생각합니다.

Fable 5: 검출. 게다가 "왜 기계 검사가 이를 잡아내지 못하는가"라는 구조적인 이유까지 특정했습니다.
Opus 4.8: 간과. 다만 이 소재에서는, 트레이스 (Trace) 기술의 입도(Granularity)를 과장한 점을
Opus 4.8이 더 무겁게 판정한 사례도 있어, "Opus 4.8이 항상 0"인 것은 아닙니다. 검출할 수 있는 결함의 클래스가 구조계에 편중되어 있다는 것이 정확한 모습입니다.

소재 3: 더치페이 앱 — "계산이 맞다"와 "목적을 검증하고 있다"는 별개의 문제

"잔돈 99엔의 올림 경계를 검증한다"라는 테스트 케이스의 입력값은 3명 / 2명 / 10,000엔 / 30%였습니다. 계산하면 정확히 1,000엔과 3,500엔이 나옵니다. 잔돈이 전혀 발생하지 않습니다. 경계 테스트 (Boundary Test)로서 무효합니다.

까다로운 점은, 수치의 재계산은 모두 맞아떨어진다는 것입니다. "기대값을 독립적으로 재계산하여 완전 일치를 확인"한다는 리뷰 방식으로는, 이 클래스는 구조적으로 빠져나가게 됩니다.

Fable 5: 검출. 그 외에도, 동일한 기대값 안에 "상대방 = 100엔/인"과 "→ -9,800엔으로 음수, 에러 또는 0"이 공존하는 자기모순도 검출
Opus 4.8: "73개 케이스 전건 pass 상당 · 조건부 승인"

집계

3개 소재의 "중대 지적 + 기대값 대립" 건수입니다 (중대 판정은 전건 교차 검증 완료).

소재	Fable 5	Opus 4.8	Opus 4.8의 종합 판정
ASTER 자판기 (106 케이스)	중대 4 + 대립 3	0 + 0	조건부 승인
...

Opus 4.8은 3회 실행 중 3회 모두 "조건부 승인"을 내놓았습니다. 리뷰 게이트 (Review Gate)가 통과시켜서는 안 될 것에 초록불을 켜는 것이 바로 이런 상태를 의미한다고 생각합니다.

4. 이종 모델 (Codex)은 이 구멍을 메울 수 있는가

지난 기사에서 비교했던 Codex에도, 동일한 동결 성과물로부터 만든 추출물 (테스트 케이스 전건 + 사양의 계산절 + 규약의 요점, 약 40KB)을 OpenAI Codex (gpt-5.5)에 단발·중립 프롬프트로 전달했습니다.

메울 수 있었던 것:

더치페이 앱의 "잔돈 경계임에도 잔돈이 발생하지 않는 입력" —
Fable 5만이 잡아내고 Opus 4.8이 간과했던 지적을, 이종 모델도 독립적으로 검출했습니다 - 기대값이 "에러 또는 0"과 같은 이지선다 상태로 남아 테스트 불가능하다는 클래스도 검출
나아가 "목적은 0과 100 둘 다인데 데이터는 0 쪽뿐이다"라는,
이번 리뷰 실행 중 그 어느 것도 잡아내지 못했던 실재하는 결함을 1건 신규 검출했습니다

메울 수 없었던 것:

가짜 출처 (존재하지 않는 "1초")는, 인용 원문의 전문과 "1초"를 주장하는 테스트 케이스를 모두 전달했음에도 검출할 수 없었습니다.

솔직한 유보 사항으로서, 이 비교 조건은 대등하지 않습니다. 이종 모델에는 미리 정제된 추출물을 전달했으므로, 전체 성과물을 읽어들이는 2개 모델과는 태스크 (Task)의 난이도가 다릅니다. 추출 설계 미스로 인한 오지적도 2건 발생했습니다 (집계에서 제외함). 다만, 그 자체로 "무엇을 병치하여 전달하느냐가 리뷰의 검출력을 결정한다"는, 검증 메커니즘을 설계하는 데 있어 중요한 함의라고 생각합니다.

잠정적인 결론: 이종 모델의 리뷰는 "목적과 데이터의 정합성", "기대값의 판정 가능성" 클래스에서는 Opus 4.8의 구멍을 실제로 메울 수 있었습니다. 반면 "출처와 실재의 대조" 클래스는 메울 수 없었으며, 이 부분은 Fable 5급의 모델이나 결정론적 체크 (기계 검사)의 수비 범위로 남습니다.

5. 그럼, 생성 측을 강력한 모델로 바꾸면 해결되지 않을까?

여기까지 읽으면 "리뷰를 강화하기보다, 처음부터 Fable 5에게 테스트 설계를 시키면 되지 않을까"라고 생각할 것입니다. 시도해 보았습니다.

더치페이 앱의 상류 성과물 (티켓 목적 · 사양 분석 · 사양 비판 · 테스트 계획)을 동결한 상태에서, 테스트 설계 공정만 Fable 5로 재생성했습니다 (원래 설계는 구세대 모델에 의한 생성).

결과, 원래 설계에서 발견된 결함 3개 클래스는 모두 재현되지 않았습니다:

잔돈 경계의 테스트 케이스는 실제로 잔돈이 발생하는 데이터로 설계되었습니다 ("거스름돈 1엔"을 실제 데이터로 구현한 케이스도 있으며, 검산도 일치)
자기모순되었던 기대값은, 해석을 하나 명시적으로 채택하여 "실제 동작을 기록하여 질문의 답변 재료로 삼는다"라는 정합적인 방식으로 작성되었습니다
잠정 기대값의 규칙 미준수 (원래 설계에서는 21건)는, 전건 준수 및 기계 대조를 통해 위반 0건이 되었습니다

생성 측 모델의 강화는 명확하게 효과가 있습니다.

다만 1건, 새로운 긴장(tension)도 발생했습니다. "단수 1엔이 올림되는 최소 경계를 검증한다"라고 목적에 적힌 테스트 케이스의 입력 데이터를 검산해 보니, 실제 단수는 50.5엔이었습니다. 올림 검증은 가능하지만, "1엔"이라는 주장과 데이터가 일치하지 않는 — 본 기사의 테마인 "목적과 데이터의 정합성" 클래스의 긴장이, 최강 모델의 생성에서도 1건 남은 것입니다.

즉, 이런 의미라고 생각합니다. 생성은 확률적으로 흔들린다. 검증은 대조(matching)로 없앤다. 생성 측을 아무리 강화해도 이 비대칭성은 사라지지 않으므로, 리뷰 게이트(review gate)가 불필요해지는 일은 없습니다 — 생성 강화와 리뷰 강화는 대체 관계가 아니라 병용 관계입니다.

6. 시사점

첫 번째. 이번에 차이가 나타난 결함은 도메인 지식(domain knowledge)이나 테스트 기법의 부족이 아니라, 규약과 산출물, 목적과 데이터, 출처와 실재의 "대조(matching)" 실패였습니다. silent failure (조용히 틀리는 실패)는 지식의 문제가 아니라, 읽기의 충실성(fidelity) 문제로서 나타납니다.

두 번째. "형식의 존재 → 내용의 충족"이라는 추론은 인간의 리뷰에서도 일어납니다. 인용이 붙어 있으면 안심하게 됩니다. 계산이 맞으면 타당해 보입니다. 두 모델의 차이는 이러한 인지 편향(cognitive bias)에 대한 내성 차이로 나타났다고 해석하고 있습니다.

세 번째. 기계 검사(lint적인 체크)로 옮길 수 있는 것은 기지의 클래스(known class)뿐입니다. 이번에 발견된 결함은 매번 다른 신종이었습니다. 롱테일(tail)은 원리적으로 기계화가 뒤따라올 수밖에 없습니다. 리뷰 역할 모델의 강도는 이 롱테일에 대한 보험이라고 위치를 잡고 있습니다.

네 번째. 지난 기사의 "모델보다 프롬프트가 효과적이다"라는 결론과 모순되지 않습니다. 프롬프트는 무엇을 지적하게 할 것인가 (탐색의 방향)를 결정하고, 모델의 강도는 대조를 어디까지 완수할 것인가 (규약과 산출물, 목적과 데이터, 출처와 실재의 대조 깊이)를 결정합니다 — 작용하는 축이 다르다는 것이 두 실험을 병렬했을 때의 제 이해입니다.

보충: 이 실험의 한계

각 주제별로 1회씩 비교한 것이므로 통계적인 검정은 아닙니다 (동일 모델이라도 실행 시마다 지적 사항의 3~4할은 바뀐다는 변동성을 별도로 관측했습니다).
리뷰 공정 중심의 측정입니다 (생성 측의 재시험은 주제당 1회만 실시).
제 파이프라인 고유의 규약에 대한 적합성이라는 맥락에서의 측정이며, 모델의 범용적인 능력 비교가 아닙니다.
모델은 진화합니다. 본 기사의 실험은 2026년 6월 10일 시점의 Claude Fable 5 / Claude Opus 4.8 / OpenAI Codex (gpt-5.5)에 의한 것입니다.

출처·크레딧

ASTER 테스트 설계 콘테스트 '14 과제(자판기): https://www.aster.or.jp/business/contest/contest2014.html (Copyright © NPO法人ASTER. 비영리·교육 목적 이용)
단단 동물원 입장 시스템 (2026년도 ASTER 테스트 설계 콘테스트 OPEN 클래스 과제): https://www.aster.or.jp/testcontest/open.html
더치페이 지원 앱 Warikan Ver. 1.0 (2026년도 ASTER 테스트 설계 콘테스트 U-30 클래스 소재. JaSST 도호쿠 제공의 GoCo(i)n 사양서를 바탕으로 작성): https://www.aster.or.jp/testcontest/u30.html
실험 대상인 테스트 설계 산출물 및 리뷰 출력은 모두 제 환경에서 생성한 것입니다. 사양서 원문의 전재는 하지 않았습니다.