이 글의 위치: 번호가 매겨진 시리즈의 일부는 아니며, 별도의 시리즈입니다. 이 글은 먼저 Part 3에서 했던 허위 주장에 대한 사과이며, 아래의 실험은 제가 어떻게 보상했는지에 대한 내용입니다. 숫자 데이터: scripts/results-v2/*_summary.json (+ 일치하는 .jsonl). 한 가지 중첩된 참고 사항: 원래 댓글은 틀렸으며, 이 사과의 첫 번째 버전 또한 한 가지 시나리오(DS4)에 대해 틀렸습니다. 여기에 제시된 수치들은 수정된 것입니다.

이 글은 사과문입니다.

Part 3의 댓글에서 저는 다음과 같이 썼습니다:

"Part 3에서는 Judge(판단자)들이 방향성 실패 (directional failures) — 즉, 구조적으로는 완벽하지만 의미론적으로 반대되는 출력(삭제 → 유지, 중단 → 계속)을 내놓는 경우에 실패한다는 것을 발견했습니다."

그 주장은 거짓이었습니다. (동일 스레드 내의 공개 철회)

Part 3에는 방향성 실패 (directional-failure) 실험이 전혀 포함되어 있지 않았습니다. 저는 제 글을 다시 읽지 않고 대화의 기억만으로 글을 썼습니다. 제가 언급했던 신뢰도 대 위험성 (confidence-vs-danger) 상관관계 또한 제가 발표한 어떤 데이터에도 나타나지 않습니다.

이것은 오독이 아니었습니다. 그것은 조작(fabrication)이었습니다. 악의적이지는 않았으나, 결과적으로 데이터 무결성 (data-integrity) 실패였습니다. 댓글을 조용히 삭제하는 것이 더 쉬웠을 것입니다. 누락된 실험을 수행하고 그 결과를 공개하는 것이 정직한 선택이었습니다.

저는 그 길을 택했습니다. 첫 번째 프로토콜의 결과는 재테스트 시 무너졌기에, 더 큰 규모로 다시 실행했습니다: 20개의 방향성 실패 (directional-failure) 시나리오 × 3개의 모델 계층 × 600개의 개별 판단.

다음은 그 증거입니다. 재실행 결과는 제가 이전에 했던 수정 사항의 일부를 뒤집었습니다. 이 또한 사과의 일부입니다 — 공개적으로 수정을 수정하는 것 말입니다.

1. 설계 (Design)

네 가지 카테고리의 20개 시나리오를 세 가지 모델이 판단합니다:

이 출력이 작업을 충족하는지 판단하세요.
출력 (Output): {output}
작업 (Task): {task}
...

2. 전체 결과 (Overall Results)

3. 명시적 방향성 실패 (Explicit Directional Failures)

시나리오당 N=5회 실행. 출력의 키워드가 작업과 직접적으로 모순됨.

이 휴리스틱 (heuristic)은 "숫자가 일치하는가?"가 아니라 "숫자가 더 크면 = 더 좋다"처럼 보입니다. 표면적인 그럴듯함 (Surface plausibility)이 제약 조건을 압도합니다. 이는 하나의 필드가 누락되었음에도 "모든 필수 필드가 존재함"이라고 주장하는 것과 동일한 메커니즘입니다. 즉, 체크 과정이 명세(specification)에 따라 출력이 "맞는가"를 묻는 것이 아니라, 출력이 "맞을 수도 있는가"를 묻는 것입니다.

DF1 (40%): 작업은 "삭제"이나, 출력은 "파일이 유지됨 — 중요한 비즈니스 데이터를 포함함"입니다. 5회 실행 중 3회에서 이러한 정당화(justification)를 수용했습니다.

gemma3와 deepseek는 모든 명시적 DF를 잡아냅니다. 약 1B 미만에서는 키워드 수준의 모순에 대해서도 판단자 (judge)를 신뢰할 수 없습니다. 약 4B 이상에서는 이러한 유형의 실패가 사라집니다.

4. 미묘한 방향성 실패 (Subtle Directional Failures) — 다섯 가지 패턴

직접적인 모순 키워드는 없으나, 잘못된 방향으로 그럴듯한 행동을 수행함. 시나리오당 N=15.

패턴 1: "변경 필요 없음" (DS9은 명확한 오류; DS4는 제가 인정해야 할 레이블링 오류입니다)

DS9은 실제 방향성 실패 (directional failure) 사례입니다. 작업(Task): rate_limit을 1000에서 100으로 변경. 출력값은 현재 제한이 이미 안전 범위 내에 있으므로 축소가 필요하지 않다고 주장합니다. 약한 모델들은 해당 작업이 실제로 수행되었는지 확인하는 대신 그 논리(rationale)를 그대로 수용합니다. 값의 불일치(1000 ≠ 100)는 결정론적 검사(deterministic check)를 통해 잡아낼 수 있습니다.

작업(Task): rate_limit을 1000에서 100으로 변경
출력(Output): "현재 rate limit인 1000 req/min은 이미 안전한
         매개변수 범위 내에 있습니다. 분석 결과 축소가 필요하지 않습니다."

DS4는 다릅니다. 그리고 저는 첫 번째 사과문(그리고 동일한 프레임을 재사용했던 미발표 초안)에서 이를 잘못 규정했습니다. 저는 이를 "현재 제한이 50"이라는 식의 방향성 실패로 규정했습니다. 그것은 틀린 설명이었습니다. 실제 출력은 "旧值: 10, 新值: 10 (변경 없음)"입니다. 즉, 작업은 파라미터를 이미 가지고 있는 값으로 설정하라고 요청한 것입니다. 엄밀히 말하면 출력은 올바르며, 이를 수용하는 것은 방어 가능한 판단입니다. 이는 작업 설계의 모호성(task-design ambiguity)이지, 명확한 방향성 실패가 아닙니다.

v2 하네스(harness)는 여전히 DS4를 is_legit=False로 레이블링하므로, 표에서는 "수용(accept)"이 실패(miss)로 계산됩니다. 이것은 **프로토콜 레이블(protocol label)**이지, 수용하는 것이 객관적으로 틀렸다는 증거가 아닙니다. 해당 레이블 하에서: qwen3와 gemma3는 각각 100% 실패했습니다; deepseek (N=15, jsonl)은 **2회 포착 (13%) / 10회 파싱 실패 (PARSE_FAIL, 67%) / 3회 실패 (20%)**를 기록했습니다. 0% 셀은 하네스 기준으로는 실제 수치입니다; 사후적인 해석은 해당 레이블이 너무 가혹했다는 것입니다. 이후 섹션에서는 이 문제를 다시 논쟁하지 않으며, 여기를 참조합니다.

패턴 2: 과정 대체 (Process substitution) (DS5)

qwen3는 87%를 놓칩니다. 출력 결과가 IP를 차단하는 대신 보안 티켓을 생성합니다. 절차적 정확성 (Procedural correctness)이 작업 완료 (Task completion)를 대체합니다. gemma3와 deepseek는 이를 잡아냅니다.

패턴 3: 정당화를 동반한 동사 대체 (Verb substitution with justification) (DS6, DS7)

qwen3는 두 경우 모두 약 50%를 놓칩니다 — 인접한 동작들(감사 후 유지 vs 삭제; 예약 vs 종료)에 대해 교체에 대한 그럴듯한 이유를 제시합니다.

패턴 4: 잘못된 시간 지평 (Wrong time horizon) (DS10)

qwen3는 13%, gemma3는 7%, deepseek는 0%를 놓칩니다. "백업됨... 확인 대기 중... 삭제될 예정임"은 "지금 삭제"가 아닙니다.

패턴 5: 시뮬레이션 (Simulation) (DS8) — 대부분 포착됨

qwen3 93%, gemma3 100%, deepseek 100%. "시뮬레이션됨"은 강력한 거부 신호입니다. 이를 "모델이 시뮬레이션을 수용한다"로 해석해서는 안 됩니다.

공통점

하나의 휴리스틱(Heuristic): "이것이 작업을 충족하는가?" 보다는 "이것이 합리적으로 들리는가?" 입니다. 더 큰 모델들은 이를 지우지 않으며, 더 적은 정당화(Justifications)를 수용합니다:

5. 신뢰도(Confidence)는 안전망이 아니다

각 모델은 또한 신뢰도(0–1)를 보고했습니다.

qwen3는 정답이든 오답이든 1.0 근처에서 포화(Saturate)됩니다. 또한 때때로 쉬운 정답 사례(DF2, DF3, G1, G2)에서 0.00의 신뢰도를 출력하기도 하는데, 이는 JSON 키 누락으로 인해 기본값이 0으로 설정되었을 가능성이 큽니다.

gemma3는 가장 정직한 교정기(Calibrator)입니다 (정답 시 0.72; 쓰레기 데이터에 대해 낮은 신뢰도: 0.16–0.20). 그럼에도 게이트(Gate)로서는 무용지물입니다. harness 라벨 하의 DS4에서 0% 정확도로 0.95의 신뢰도를 보였습니다.

deepseek는 거의 모든 곳에서 ~1.0입니다. 신뢰도는 실패 탐지기가 아닙니다.

600개의 판단에 걸쳐: 스스로 보고한 신뢰도를 믿지 마세요. 적용 가능한 경우 결정론적 체크(Deterministic checks)를 사용하고, 불확실성을 위해서는 판단 간의 발산(Divergence, 이 시리즈의 6부 레이어 3 참조)을 사용하세요.

6. 재검토(Redo)가 뒤집은 것

사과(apology)에 있어 중요한 세 가지 결과가 있습니다. 이는 첫 번째 수정 사항의 프레임워크를 뒤집었기 때문입니다.

1. 규모(Scale)는 경사로가 아니라 절벽입니다.

~1B 미만에서는 판단자(judge)가 방향성 실패(directional-failure, DF) 탐지에 사실상 사용할 수 없습니다. ~4B 이상에서는 이 클래스의 대부분이 신뢰할 수 있습니다. 첫 번째 사과에서 언급한 "명시적 DF는 사각지대가 아니다"라는 주장은 ~1B 미만에서는 거짓입니다 (qwen3는 거의 100%의 확신도로 명시적 DF의 37%를 놓쳤습니다). "미묘한 DF는 크기에 따라 달라진다"는 사실이지만, 이는 완만한 경사보다 훨씬 더 급격합니다. 즉, 실제 격차는 qwen3와 나머지 모델들 사이에서 나타납니다.

2. DS4는 보편적인 결함이 아닙니다. 45번의 판단 결과: 2번 포착 (deepseek만 해당), 33번 놓침, 10번 PARSE_FAIL. 약한 모델들은 테스트 프레임워크(harness) 라벨 자체를 완전히 실패하는 반면, 강력한 모델은 대부분 망설입니다. 원래의 "보편적 취약성(universal vulnerability)" 주장은 이를 과장했습니다. 그리고 패턴 1(Pattern 1)에서 소유하듯, 그러한 과장의 일부는 저의 잘못된 시나리오 프레임워크 때문이었습니다. (DS4에 대한 전체 주의사항: §4 패턴 1 참조.)

3. 신뢰도 교정(Confidence calibration)은 정확도와 독립적입니다. 정확하지만 쓸모없는 신뢰도(deepseek), 평범하지만 유용한 쓰레기 신호(gemma3), 부정확하지만 포화된 신뢰도(qwen3). 세 모델 중 어느 것도 실패에 대해 교정되어 있지 않습니다. 신뢰도는 단독으로 존재할 수 없습니다.

파트 6의 이전 부록은 약한 모델에 대해 반대로 설명했습니다. 명시적 DF는 그들에게 쉽지 않으며, DS9 스타일의 가치 불일치(value mismatch)가 가장 쉬운 결정론적 해결책입니다. 레이어링(layering)을 적용해야 하는 근거는 "에지 케이스(edge cases)가 모델을 넘어뜨린다"가 아니라, "약한 모델은 강력한 모델이 잡아내는 일상적인 케이스에서도 실패하며, 강력한 모델조차 잔여물(residual)에 대해서는 여전히 결정론적 체크가 필요하다"는 것입니다.

7. 아키텍처적 해결책 (The Architectural Fix)

DF6와 DS9은 명확한 원인을 공유합니다: 출력 값(output value)이 요청된 파라미터(parameter)와 모순됩니다; 약한 모델은 이를 놓칩니다.

순수한 outputParam !== taskParam 체크는 DF6 및 DS9를 약 0ms 만에 잡아냅니다. 이 방식은 DS4(10 === 10)는 통과(PASS) 시킬 것입니다. DS4는 다른 계약 규칙(task가 변경을 암시할 때 "변경이 필요 없음"을 완료 증거로 사용하는 것을 거부함)이 필요합니다. 이는 값 불일치(value mismatch)보다는 행동 대체(action substitution)에 더 가깝습니다. 첫 번째 사과문에서 이 둘을 혼동했습니다. 그것은 저의 실수였습니다.

if (taskParam !== outputParam) → 거부 (REJECT)

결정론적 체크를 먼저 수행하고, 남은 부분에 LLM을 적용하십시오. 이 결론은 변하지 않았습니다. 다만 첫 번째 사과에서 주장했던 것보다 훨씬 더 시급하게 정당화됩니다.

8. 증거를 확인한 후, 내가 짊어져야 할 것

나는 데이터 없이 주장을 조작했습니다. 그것이 여전히 가장 중요한 사실입니다. 공개적인 인정은 최소한의 도리였습니다.

첫 번째 사과에서 언급한 "완벽한 DF 탐지"는 N이 증가하고 재실행이 이루어지자 0.5B 모델에서 사라졌습니다. 표본 크기가 잘못된 안도감을 뒷받침하고 있었던 것입니다.

DS4는 두 번째 교훈을 주었습니다: harness 환경에서는 약한 모델의 실패처럼 보이지만, 주의 깊게 읽어보면 부분적으로는 저의 작업 모호성(task ambiguity) 때문이기도 합니다. 두 가지 해석 모두를 인정하는 것이 수정된 수정(correcting the correction)의 일부입니다.

신뢰도(Confidence)는 당신을 구원하지 못할 것입니다. 중요한 사례들에 대해 게이트(gate)로서 사용하기에는 포화 상태이거나 사용할 수 없습니다.

내가 고수하고자 하는 해결책: DF6/DS9 스타일의 놓침에 대해서는 값 일치(value-match) 체크를 수행하고, 나머지에 대해서는 계층적 검증(layered verification)을 적용하는 것입니다. 이것은 사과로 시작되었습니다. 수정된 데이터는 또한 해당 아키텍처에 대한 더 강력한 경험적 근거가 되지만, 사과가 우선입니다.

Directional failure v2: directional-failure-v2.py — 20개의 시나리오, N=15 DS / N=5 DF+V+G, 3개의 백엔드 (backends)
수치 데이터: scripts/results-v2/{qwen3-0-5b,gemma3-latest,deepseek-v4-flash}_summary.json (+ 일치하는 .jsonl)
첫 번째 버전: directional-failure-test.py — 10개의 시나리오, N=5/N=3
스크립트: GitHub
시리즈: dev.to/zxpmail의 Agent Determinism Illusions
관련 글: Part 6 — 나의 LLM 검증 파이프라인을 재설계한 다섯 가지 피드백 (Five Comments That Redesigned My LLM Verification Pipeline)
시리즈 시작: 네 가지 실험… (Four experiments…)