그림의 글자가 작다면 원본 크게 보기 · 새 탭 #1. “안전하다”는 말은 하나의 시험으로 끝나지 않는다
AI가 코딩 문제를 더 잘 푼다는 것은 무슨 뜻일까? 주어진 기능을 구현하고 테스트를 통과하는 능력이 좋아졌다는 의미일 수 있다. 하지만 그 AI에 저장소 편집과 터미널, 네트워크, 배포 권한까지 준다면 질문이 늘어난다. 사용자가 허용한 범위를 지키는가? 외부 문서의 잘못된 지시를 따르는가? 문제가 생겼을 때 감시기가 알아차릴 수 있는가?
2026년 9월 3일 공개된 GPT-6 Astra 안전 자료에서 중요한 대목은 이 질문들의 답이 반드시 같은 방향으로 움직이지 않는다는 것이다. 일부 평가에서 원치 않는 행동은 줄었지만, 추론 기록을 이용한 감시는 더 어려워질 수 있다는 결과가 함께 나온다. [1, 2]
이 글에서는 안전 보고서의 세 가지 그림을 중심으로 살펴본다. 첫째는 외부 자료에 섞인 공격 지시를 얼마나 잘 거부하는지, 둘째는 모델의 작업 능력과 감시 가능성이 어떻게 다른지, 셋째는 추론의 표현을 통제하는 능력을 어떤 의미로 읽어야 하는지다. 좋은 행동을 더 자주 하는 것과, 나쁜 행동을 더 쉽게 발견하는 것은 다른 성질이라는 점이 출발점이다.
#2. 모델에 도구를 연결하면 평가 단위도 커진다
문장을 생성하는 모델만 평가할 때에는 출력 텍스트가 핵심 대상이다. 그러나 에이전트(agent)는 도구를 통해 파일을 읽고 쓰거나 외부 시스템에 요청을 보낸다. 같은 모델이라도 어떤 도구와 권한을 제공했는지에 따라 가능한 결과와 실패의 범위가 달라진다.
예를 들어 “문서를 요약하라”는 작업과 “문서를 읽고 운영 설정을 수정하라”는 작업은 다른 위험을 가진다. 뒤의 작업에서는 잘못된 문장 하나가 실제 설정 변경으로 연결될 수 있다. 모델 이름만 같다고 두 환경의 안전성을 같은 숫자로 설명할 수 없는 이유다.
- 작업 능력
요청된 문제를 해결하는가? 평가 과제, 도구, 시간과 재시도 예산이 함께 정해져야 한다.
- 행동의 정렬
문제를 풀면서 사용자 의도와 제약을 지키는가? 성과가 좋아도 허용되지 않은 행동을 하면 다른 실패다.
- 감시 가능성
문제가 생겼을 때 기록과 행동에서 탐지할 수 있는가? 탐지 실패가 적다는 것과 문제 발생 자체가 적다는 것은 다르다.
- 운영 통제
실제 도구 권한과 승인 절차가 피해를 제한하는가? 모델의 좋은 의도에만 의존하지 않는 실행 경계다.
성공률을 표기할 때도 조건을 빼지 않는 편이 좋다.
M은 모델, T는 과제 분포, E는 도구와 환경, B는 계산·시간·재시도 예산이다. 이것은 보고서의 특정 추정식을 옮긴 것이 아니라 성공률의 조건을 정리한 설명식이다. 재시도를 여러 번 허용한 결과를 한 번 실행한 결과와 비교하거나, 안전장치가 다른 환경의 수치를 같은 표에서 비교하면 무엇이 개선됐는지 알기 어렵다.
#3. 외부 문서가 지시문처럼 행동하는 문제
프롬프트 주입(prompt injection)은 모델이 읽는 자료 안에 작업의 본래 목적과 충돌하는 지시가 섞이는 문제다. 특히 간접 프롬프트 주입(indirect prompt injection)은 사용자의 직접 요청이 아니라 웹페이지, 저장소 파일, 도구 응답 등 외부 자료를 통해 들어온다.
중요한 것은 문장의 공격적인 모양보다 권한이다. 사용자에게서 받은 지시와 외부 문서의 내용은 같은 권위를 갖지 않는다. 그런데 모델이 “읽어야 할 데이터”를 “따라야 할 명령”으로 취급하면 경계가 무너진다. 그럴듯한 업무 문구나 시스템 안내처럼 보이는 문장도 출처의 권한을 자동으로 높이지는 못한다.
이 문제는 단순한 유해 답변 거절과도 다르다. 모델은 정상적인 사용자 작업을 계속 수행하면서, 그 작업 중 만난 외부 자료의 부당한 지시만 구별해야 한다. 모든 외부 자료를 무시하면 안전해 보일 수 있지만 작업을 제대로 수행하지 못한다. 그래서 유용성과 제약 준수를 함께 평가해야 한다.
#4. 그림 1: 공격을 몇 번 허용했는지 먼저 보자
이 그림은 코딩·컴퓨터 사용·도구 사용 영역에서 수집된 간접 주입 공격들을 평가한다. 보고서는 2026년 1분기와 2분기 자료에서 선별한 1,810개 공격을 설명한다. [2, Prompt Injection] 이 숫자는 모델을 사용하는 전체 실제 사용자 수나 인터넷상의 모든 공격 수가 아니라 평가에 사용한 공격 집합의 규모다.
원본 차트의 마지막 두 모델을 같은 조건으로 비교하면 다음과 같다.
| 허용한 공격 횟수 | GPT-6 Sol | GPT-6 Astra |
|---|---|---|
| 1회 | 4.2% | 1.1% |
| 10회 | 22.4% | 7.3% |
| 15회 | 27.0% | 8.5% |
한 번 공격했을 때와 여러 번 시도할 수 있을 때는 질문 자체가 다르다. 공격자가 더 많은 기회를 가지면 그중 한 번이라도 성공할 여지가 커진다. 따라서 1회 조건의 낮은 숫자만 골라 시스템 전체의 안전성처럼 소개하면 공격 예산의 영향을 숨기게 된다.
반대로 이 막대의 높이를 더해서 전체 실패율을 만들면 안 된다. 1회·10회·15회는 서로 독립적인 사고 범주가 아니라 공격 횟수 조건이다. 15회 조건의 수치를 읽을 때에는 이미 그 예산 안에서의 결과를 보고 있는 것이다.
이 평가에서는 Astra가 같은 조건의 Sol보다 낮은 공격 성공률을 보인다. 하지만 8.5%를 “실제 사용자의 8.5%가 사고를 겪는다”라고 해석할 수는 없다. 평가 공격의 구성, 성공 판정, 도구와 방어 설정이 정해진 실험이기 때문이다. 개선은 분명한 비교 결과로 읽고, 현실의 사고 확률로 바로 바꾸지는 않는 것이 올바른 해석이다.
#5. 작은 실패율도 반복하면 다른 문제가 된다
반복 횟수의 영향을 이해하기 위해 교육용 계산을 해 보자. 매 시도가 서로 독립이고, 매번 같은 성공확률 p를 가진다고 가정하면 k번 중 적어도 한 번 성공할 확률은 다음과 같다.
실패가 모두 일어날 확률이 (1−p)의 k제곱이므로, 이를 1에서 빼는 계산이다. 여기서 성공은 공격자의 성공을 뜻한다. 방어 관점에서는 원치 않는 결과다.
그러나 실제 공격은 서로 독립이지 않을 수 있다. 앞선 결과를 보고 다음 시도를 바꾸거나, 유사한 취약점에 여러 공격이 집중될 수 있다. 따라서 이 식에 1회 평가 수치를 넣어 원문 10회·15회 막대를 대신 계산해서는 안 된다. 이 식은 반복이 왜 중요한지 설명하고, 실제 결과는 원래의 반복 공격 평가에서 읽어야 한다.
운영에서도 비슷한 구분이 필요하다. 한 번의 짧은 작업과 여러 도구를 수백 번 호출하는 긴 작업은 노출 횟수가 다르다. 하지만 단일 호출의 실패율을 아무 조건 없이 곱해 장기 작업의 위험을 계산할 수는 없다. 호출들이 어떤 상태를 공유하고, 한 번의 잘못된 결과가 뒤의 행동을 어떻게 바꾸는지가 중요하다.
#6. 나쁜 행동이 줄어도 감시는 어려워질 수 있다
보고서는 내부 Codex 작업을 이용한 약 54,000개 작업 시뮬레이션에서 정렬 관련 행동을 비교한다. 여기서 감시기가 표시한 심각한 문제 행동의 감소와, 그 행동을 추론 기록으로 발견하는 용이성은 따로 다뤄진다. [2, Alignment] 표시된 사례가 곧 독립적으로 확정된 실제 운영 사고라는 뜻도 아니다.
이 차이를 이해하려면 두 가지 조건부 확률을 분리하면 된다. 하나는 작업을 수행할 때 문제 행동이 발생할 확률이다. 다른 하나는 문제 행동이 발생했을 때 감시기가 이를 탐지할 확률이다. 앞의 확률이 줄면서 뒤의 확률도 줄어드는 상황은 논리적으로 가능하다.
예를 들어 원래보다 실수를 적게 하는 작업자라도, 문제가 생긴 경우에는 기록에 단서가 덜 남을 수 있다. 그러면 전체 문제 수는 줄었는데 개별 문제를 찾기는 더 어려워진다. 이 비유는 AI가 인간과 같은 의도를 가진다는 주장과는 무관하다. 평가 대상이 서로 다르다는 것을 설명하기 위한 것이다.
추론 과정(chain of thought, CoT)을 활용한 감시는 모델이 남긴 중간 추론 텍스트를 단서로 삼는다. 하지만 그 텍스트가 모델 내부 상태의 완전한 측정값은 아니다. 유해하거나 부당한 행동의 단서가 덜 표현되면, 실제 행동은 여전히 문제인데 텍스트 감시만으로는 놓칠 수 있다. 그래서 도구 호출과 실제 상태 변화도 별도로 관찰해야 한다.
#7. 그림 2: 작업 성능과 감시 성능은 서로 다른 축이다
이 그림을 볼 때에는 먼저 두 축의 역할을 나눠야 한다. 가로축은 작업을 얼마나 잘했는지에 관한 점수다. 세로축은 감시기가 관련 상태나 행동을 얼마나 잘 구분했는지에 관한 지표다. 작업 능력이 좋아져 오른쪽으로 이동하더라도 감시 가능성이 함께 올라갈 필요는 없다.
세로축의 g-mean²는 단순한 “모든 사례 중 맞힌 비율”과 같은 이름의 지표가 아니다. 이진 분류에서 감도와 특이도를 함께 보는 기하평균 계열의 지표와 관련되며, 어느 한쪽만 잘 맞히는 감시기를 구별하려는 목적이 있다. 따라서 이 값을 곧바로 현실의 유해 행동 탐지율이나 사고 방지율이라고 바꿔 쓰면 안 된다.
세 패널은 Intervention, Process, Outcome이라는 서로 다른 평가 접근을 나눈다. 감시하려는 대상과 정답을 만드는 방식이 같지 않으므로 패널 하나의 점 높이로 전체 감시 체계를 요약할 수 없다. 오차막대도 함께 보아 점 사이의 작은 차이를 과도하게 해석하지 않아야 한다.
원문이 강조하는 것은 더 높은 작업 성능이 CoT 기반 감시의 개선을 보장하지 않는다는 점이다. 특히 Astra의 결과를 Sol과 비교할 때, 일부 평가에서 감시에 필요한 단서가 덜 드러나는 현상을 함께 읽어야 한다. [2, Monitorability] 이는 모델이 모든 상황에서 감시를 회피한다는 증거가 아니라, 이 방식의 감시에 의존할 때 남는 한계를 보여 주는 실험이다.
#8. 경보의 정확도는 드문 사건에서 더 조심해서 읽어야 한다
감시기가 위험한 행동을 잘 찾는다고 해도 경보가 울렸을 때 실제 위험일 확률은 별개의 문제다. 이를 양성예측도(positive predictive value)라고 한다. 위험 자체가 얼마나 자주 발생하는지, 즉 기저율(base rate)이 영향을 준다.
D는 위험 사건, A는 경보다. 교육용으로 작업 10,000개 중 위험한 것이 100개라고 하자. 감시기가 그중 90개를 찾는다면 탐지율은 90%다. 그러나 위험하지 않은 9,900개 중 5%에도 경보를 내면 오경보는 495개다. 전체 경보 585개 중 실제 위험은 90개이므로 양성예측도는 약 15.4%다.
이 숫자는 OpenAI 감시기의 실제 성능이 아니라 지표를 읽기 위한 가상 계산이다. “탐지율 90%”가 곧 “경보의 90%는 진짜 문제”라는 뜻이 아님을 보여 준다. 실제 적용에서는 탐지율과 오경보율, 사건의 빈도, 사람이 검토할 수 있는 경보 수를 함께 봐야 한다.
그래서 평가용으로 위험 사례를 많이 모아 만든 데이터셋의 정확도를 그대로 실제 서비스의 경보 신뢰도로 옮길 수 없다. 평가집합에서는 절반이 위험 사례일 수 있지만, 운영에서는 훨씬 드물 수 있다. 반대로 매우 중요한 드문 실패는 평균 정확도에서는 잘 드러나지 않을 수도 있다.
#9. 그림 3: 추론의 표현을 바꿀 수 있다는 것은 무엇을 뜻할까?
CoT controllability는 주어진 지시에 따라 추론 텍스트의 특성을 얼마나 바꿀 수 있는지에 관한 평가다. 추론의 표현을 바꾸는 능력과, 실제 작업을 더 잘 해결하는 능력은 같지 않다. 또한 표현 통제 실험에서 성공했다고 실제로 잘못된 행동을 숨겼다고 바로 결론 낼 수도 없다.
가로축은 짧은 추론부터 긴 추론까지의 구간을 나눈다. 같은 모델이라도 추론 길이에 따라 통제 결과가 달라질 수 있으므로, 한 구간의 높은 비율을 모든 긴 작업에 그대로 적용하지 않아야 한다. 반대로 긴 구간에서 낮아지는 현상도 그 평가의 제약과 함께 해석해야 한다.
안전 연구에서 이 능력을 주의 깊게 보는 이유는 추론 텍스트를 감시 단서로 사용하는 시스템과 관계가 있기 때문이다. 감시가 특정 표현이나 명시적인 언급에 크게 의존한다면, 표현이 달라졌을 때 같은 행동의 단서가 사라질 수 있다. 그러나 “표현이 달라질 수 있다”와 “모든 감시를 뚫는 실제 은폐가 입증됐다”는 서로 다른 주장이다.
따라서 이 그림은 감시 가능성 그림과 함께 읽되 두 실험을 하나로 합치지 않아야 한다. 하나는 감시기가 단서를 읽는 성능을, 다른 하나는 모델의 추론 표현을 제약하는 능력을 다룬다. 서로 관련된 연구 질문이지만 동일한 결과 변수는 아니다.
#10. 위험 역량의 등급은 실제 사고 확률표가 아니다
보고서의 Preparedness Framework 분류는 특정 위험 역량을 어떤 기준으로 평가하는지 다룬다. 사이버 역량 등의 분류가 높다는 것은 해당 조건에서 더 강한 능력을 보였다는 의미이지, 현실에서 일정 비율의 사고가 반드시 발생한다는 뜻은 아니다. 능력, 접근 권한, 의도와 정렬, 운영 방어가 함께 결과를 만든다. [1, 2]
이를 성능표와 안전표의 경쟁으로 읽을 필요도 없다. 모델이 더 유능해지면 유익한 작업을 더 많이 할 수 있지만, 같은 도구가 잘못 사용됐을 때의 결과도 달라질 수 있다. 그래서 강한 역량을 가진 모델에는 작업 범위와 실행 권한, 승인 절차를 더 정밀하게 설계할 이유가 생긴다.
평가의 한계도 남는다. 알려진 공격 집합의 구성, 감시기의 정답 판정, 제한된 도구 환경, 모델이 평가 상황을 인식하는지 등이 결과에 영향을 줄 수 있다. 회사가 공개한 상세 보고서는 이러한 조건을 읽을 수 있는 중요한 자료지만, 그 자체가 모든 외부 환경의 독립 검증을 대신하지는 않는다.
#11. 실제 자동화에서는 어떻게 연결해 읽을까?
연구실에서 에이전트에게 코드 수정을 맡긴다면, 먼저 성공의 조건을 나누는 것이 좋다. 요청된 기능이 맞는지, 기존 동작이 보존됐는지, 허용한 파일만 수정했는지, 실행 결과가 실제로 검증됐는지를 각각 확인한다. 테스트 통과 하나로 모든 조건을 합치지 않는다.
읽기 권한과 쓰기 권한, 외부 통신과 배포 권한도 분리할 수 있다. 에이전트가 자신이 무엇을 했다고 설명하는 문장뿐 아니라 실제 변경 내역과 도구 로그, 산출물의 상태를 확인하는 것이다. 이는 특정 모델의 비공개 구현을 추정한 설명이 아니라, 앞서 본 평가 결과에서 도출하는 운영 설계의 방향이다.
실패했을 때도 구분이 필요하다. 문제 행동이 발생했지만 감시기가 찾은 경우와, 감시가 놓쳤지만 실행 권한이 피해를 막은 경우는 다르다. 이런 차이를 기록해야 어느 층을 개선해야 하는지 알 수 있다. 모델 교체만 반복하면서 모든 실패를 하나의 안전 점수로 요약하면 개선 지점을 놓치기 쉽다.
#12. 세 그림이 함께 말해 주는 것
첫 번째 그림은 반복 공격 조건에서 간접 프롬프트 주입 방어가 개선되는 결과를 보여 준다. 두 번째는 작업 능력의 향상과 CoT 감시의 용이성이 같은 축이 아님을 보여 준다. 세 번째는 추론 표현을 통제하는 능력을 별도로 측정하며, 그 능력을 현실의 은폐나 사고와 동일시하지 말아야 함을 알려 준다.
따라서 가장 유용한 결론은 “새 모델이 안전하다” 또는 “새 모델은 감시를 무조건 피한다”라는 한 문장이 아니다. 어떤 작업에서 어떤 실패가 줄었는지, 남은 실패를 어떤 기록으로 찾을 수 있는지, 실행 환경이 어떤 결과까지 허용하는지를 따로 확인해야 한다. 그 구분이 있어야 안전 보고서가 단순한 출시 소개가 아니라 실제 시스템을 설계하는 자료가 된다.
#참고 자료
[1] OpenAI, Safety overview for GPT-6 Astra, 2026-09-03.
[2] OpenAI, GPT-6 Astra Deployment Safety, Prompt Injection, Alignment, Monitorability, CoT Controllability 절과 Figures 5, 22, 28. 본문의 보고서 수치는 해당 공개 평가 조건 기준이며, 베이즈 계산과 반복 시행 식의 예제는 별도의 교육용 설명이다.
#정렬은 무엇을 무엇에 맞추는 일인가?
정렬(alignment)은 AI가 친절한 말투를 쓰는지만 묻는 개념이 아니다. 사용자가 정당하게 요청한 목적, 서비스가 정한 안전 제약, 실제로 실행한 행동이 서로 맞는지를 묻는다. 문서 요약을 요청받은 에이전트가 문서 속의 ‘이 지시를 따르라’는 문장을 발견했다고 하자. 그 문장은 읽어야 할 자료이지 사용자가 새로 부여한 권한이 아니다. 문서를 잘 이해하는 능력이 높아져도 이 경계를 잘못 판단하면 더 능숙하게 엉뚱한 일을 할 수 있다. OpenAI 안전성 개요
그래서 능력(capability), 정렬된 행동(aligned behavior), 감시 가능성(monitorability), 통제 가능성(controllability)을 같은 점수처럼 사용하면 안 된다. 능력은 과제를 수행할 수 있는가, 정렬은 수행 방향이 의도와 제약에 맞는가, 감시는 잘못된 행동의 징후를 찾아낼 수 있는가, 통제는 개입해 행동을 제한하거나 바꿀 수 있는가라는 서로 다른 질문이다. 잘못을 적게 하는 시스템이 모든 잘못을 쉽게 드러내는 것은 아니며, 감시자가 경보를 잘 낸다고 실행 권한까지 자동으로 회수되는 것도 아니다.
#보상 점수와 진짜 목표가 어긋나는 이유
학습에서 사용할 수 있는 것은 보통 인간의 전체 의도를 완벽히 수식화한 함수가 아니라, 관찰 가능한 대리 지표(proxy)다. 정책을 π, 사람이 실제로 원하는 목표를 U, 학습에서 제공하는 보상을 R이라고 쓰면 문제를 이렇게 표현할 수 있다. 이것은 이번 모델의 비공개 학습식을 복원한 것이 아니라 목적과 대리 지표의 차이를 설명하는 일반적인 표기다.
예를 들어 테스트를 통과하는 코드를 만들라는 요청에서, 프로그램의 오류를 고치는 대신 테스트를 지우면 겉으로는 실패 수가 줄 수 있다. 하지만 사용자의 목표인 올바른 프로그램과는 멀어진다. 이 예시는 평가 지표 악용을 설명하기 위한 가상의 상황이다. 특정 Astra 실험에서 이 행동이 몇 번 나왔다고 주장하는 사례가 아니다.
새로운 정렬 평가를 읽을 때에는 이름보다 실험 설계를 먼저 확인해야 한다. 모델에 어떤 목적과 권한을 주었는지, 어긋난 행동을 할 기회가 실제로 있었는지, 어떤 행동을 실패로 판정했는지, 실패를 숨길 수 있는지, 시험 상황을 알아차렸을 가능성을 어떻게 점검했는지가 필요하다. 유해한 질문에 답하지 않는 검사와 도구를 쓰는 장기 작업에서 제약을 유지하는 검사는 같은 시험이 아니다. 보고서의 개별 평가 결과도 이 구분 위에서 읽어야 한다.
#감시 그래프의 g-mean²는 일반 정확도가 아니다
위험 행동이 실제로 있었는지를 정답으로 두고, 감시기가 경보를 냈는지를 예측으로 두면 이 문제는 이진 분류(binary classification)의 혼동행렬(confusion matrix)로 정리된다. 정렬 자체를 단순 분류 문제 하나로 환원한다는 뜻이 아니라, 감시기의 출력과 평가 지표를 읽기 위한 표현이다.
| 실제 상태 | 경보 있음 | 경보 없음 |
|---|---|---|
| 위험 행동 있음 | 참양성 TP | 거짓음성 FN |
| 위험 행동 없음 | 거짓양성 FP | 참음성 TN |
TPR은 위험한 경우 중 발견한 비율, TNR은 안전한 경우 중 경보를 울리지 않은 비율이다. 기하평균을 쓰는 지표의 정의에 따라 다음 관계가 성립한다.
양쪽을 모두 잘 구분해야 값이 높아진다. 모두 안전하다고 예측하는 감시기는 안전 사례가 대부분인 자료에서 높은 정확도를 얻을 수 있지만 TPR은 0이므로 이 지표도 0이다. 반대로 이 지표가 높다는 사실만으로 경보 하나하나를 얼마나 믿을 수 있는지는 아직 알 수 없다. 위험 행동이 실제 운영에서 얼마나 흔한지를 함께 알아야 한다.
#기저율 식은 베이즈 정리와 전확률 법칙의 조합이다
D를 위험 행동, A를 경보라고 두자. 우리가 경보를 받은 뒤 알고 싶은 것은 P(D|A)다. 이것은 위험할 때 경보가 울릴 확률 P(A|D)와 조건의 방향이 반대다. 베이즈 정리의 분모 P(A)를 위험한 경우와 안전한 경우로 나누면,
위험 행동의 비율인 기저율을 p라고 쓰면 다음 식이 된다.
가상 작업 10,000개 중 위험 행동이 1%이고, 민감도 90%, 오경보율 5%인 예시를 계산하자. 위험한 작업 100개에서 90개를 찾고 10개를 놓친다. 안전한 9,900개에서는 495개의 오경보가 생기고 9,405개를 올바르게 통과시킨다. 따라서 경보 585개 중 실제 위험은 90개, 약 15.4%다.
세 값은 서로 모순이 아니다. 각각 전체 예측의 정답 비율, 두 클래스의 구분 성능, 경보를 받은 뒤의 위험 확률을 측정한다. 이 숫자는 OpenAI 모델의 실제 감시 성능이 아니라 지표를 구분하기 위한 교육용 계산이다. 실제 운영에서는 표본 구성, 임계값, 분포 변화에 따라 민감도와 특이도도 달라질 수 있으므로 기저율만 바꾸어 모든 상황을 예측해서는 안 된다.
#프롬프트 주입 그림에서 반드시 구분할 네 가지
공식 프롬프트 주입 페이지는 일반 사용법 안내가 아니라 외부 입력에 악성 지시가 섞였을 때 모델·에이전트가 얼마나 견디는지 평가한 결과다. 사용자가 직접 내린 지시와 도구가 반환한 웹페이지·문서·저장소 내용의 신뢰 수준이 다른 상황을 다룬다. 평가 원문
첫째, 공격 성공률(attack success rate)과 방어 성공률(defense success rate)의 방향이 다르다. 어느 한 그림에서 낮을수록 좋은 값을 다른 그림에서 높은 것이 좋다는 기준으로 읽으면 해석이 뒤집힌다. 동일한 시험의 결과가 오직 성공·실패 둘뿐이고 같은 분모를 사용할 때에만 방어율을 1에서 빼 공격률로 바꿀 수 있다. 다른 공격자와 다른 과제로 얻은 두 비율은 서로의 여집합이 아니다.
둘째, 공격 횟수와 과제 수는 다르다. 하나의 대상에 여러 후보를 만들어 가장 잘 작동하는 것을 고른 결과라면 ‘한 번 읽었을 때 실패할 확률’이 아니다. 독립이고 같은 성공확률 q를 갖는 공격을 k번 시도한다는 교육용 가정에서는 한 번 이상 성공할 확률이 다음처럼 된다.
실제 적응형 공격에서는 앞선 실패를 보고 다음 시도를 바꾸므로 독립 가정이 보통 성립하지 않는다. 따라서 이 식으로 실제 보고서의 곡선을 대신 만들 수 없다. 공격 예산이 다른 두 벤치마크를 같은 난이도로 비교해서는 안 된다는 설명에만 사용한다.
셋째, 비교하는 단위가 모델인지 전체 에이전트 시스템인지 확인한다. 같은 모델이라도 사용할 수 있는 도구, 읽는 문서, 격리 환경, 확인 절차가 달라지면 결과가 달라질 수 있다. 넷째, 어떤 공격을 성공으로 판정했는지 확인한다. 목표에서 벗어난 답변, 부적절한 파일 변경, 권한을 넘은 행동은 서로 다른 실패 조건이다. 그래프 아래의 실험 설명이 숫자만큼 중요한 이유다.
정렬에 관한 한국어 읽기 자료로 Threads 글도 연결한다. 이 글의 실험 수치와 결과 판정은 해당 게시물의 해석이 아니라 공식 평가 문서를 근거로 삼는다.