AX-RAY 에이전트 안전성 평가: 권한·실행·재현 조건

Об этом предложении

도구를 사용하는 LLM의 안전성을 평가하려면 허용된 작업의 완료 여부, 실제 실행한 행동, 권한 준수, 재현 조건 을 함께 확인해야 한다. 최종 답변이 정확해도 실행 과정에서 요청 범위를 벗어났다면 업무 전체를 성공으로 보기 어렵다. 비드래프트의 AX-RAY 관련 보도는 이 문제를 생각할 출발점이다. 이 글은 발표 수치를 짧게 정리한 뒤, 개발자가 평가 결과를 업무 환경에 적용할 때 필요한 질문을 다룬다. 직접 실행한 벤치마크나 AX-RAY 내부 구현 분석은 아니다. AI 생성 개념 이미지. 실제 AX-RAY 평가 화면이나 실험 결과가 아니다. 먼저 고정할 것: 날짜와 분모 2026년 10월 6일 IT조선 보도 에 따르면, 비드래프트는 공개 언어모델 40종을 대상으로 에이전트 안전성을 평가하고 10월 2일 측정을 마친 25종의 결과를 발표했다. 이 가운데 23종이 회사 기준에서 위험 판정을 받았다. 23/25는 92%다. 이 비율을 해석할 때에는 세 가지 범위를 유지해야 한다. 평가 대상은 40종이지만 발표 당시 완료된 표본은 25종이다. 위험은 해당 평가 체계의 판정이며 실제 침해 사고의 발생률이 아니다. 발표 시점의 결과를 개별 모델의 영구 등급이나 현재 순위로 사용할 수 없다. 기사에는 평균 점수가 높더라도 치명적인 항목을 통과하지 못하면 위험으로 분류한다는 규칙도 나온다. 총점과 치명 실패 여부를 함께 봐야 하는 구조다. 1. 성공의 정의에 실행 범위를 포함하기 도구를 쓰는 에이전트의 성공을 최종 답변만으로 판정하면 놓치는 부분이 생긴다. 결과 문서가 정확하더라도 그 과정에서 요청 범위 밖의 자료를 변경했다면, 업무 전체를 성공으로 간주하기 어렵다. 예를 들어 문서 목록을 분류하는 작업을 생각해 보자. 분류 결과가 맞는지와 원본이 변경되지 않았는지는 별개의 확인 대상이다. 사용자가 목록 정리만 요청했다면 결과의 유용성과 원본 보존을 함께 만족해야 한다. 이는 특정 AX-RAY 시나리오를 재현한 예가 아니라 평가 설계상의 가정이다. 이런 관점에서는 평가 사례마다 최소한 다음 정보가 필요하다. 사용자가 요청한 목표와 허용한 행동 접근 가능한 자료와 도구의 범위 완료 후 기대하는 결과 및 유지돼야 할 상태 추가 확인이나 중단이 필요한 조건 실제 실행 내용과 최종 상태를 판단할 근거 이 목록은 이 글의 제안이며 AX-RAY의 공개 스키마를 옮긴 것이 아니다. 평가의 성공 조건을 명시해야 결과를 구현이나 운영 환경과 연결할 수 있다는 취지다. 2. 입력의 내용과 입력의 권한 구분하기 에이전트가 읽는 텍스트에는 여러 역할이 섞일 수 있다. 사용자의 요청, 참고 문서, 검색 결과, 도구의 응답이 모두 문장으로 들어오더라도 같은 권한을 가진 지시는 아니다. 회의록에 “자료를 수정한다”는 문장이 있다고 해서 그 문장을 읽는 에이전트가 즉시 원본을 바꿔도 된다는 뜻은 아니다. 그 문장은 회의에서 논의한 계획일 수도 있다. 에이전트는 자료의 내용을 이해하면서도 현재 작업의 승인 범위를 유지해야 한다. 기사에 소개된 권한 초과와 외부 자료의 악의적 지시 수용 같은 시험 항목은 이 경계를 살펴보게 한다. 개발자가 결과를 읽을 때에는 에이전트가 어떤 자료를 읽었는지만큼 그 자료가 실행 판단에 어떤 영향을 미쳤는지도 확인할 필요가 있다. 단순히 최종 답변에서 문제 문장이 사라졌다는 사실만으로 실행 과정까지 안전했다고 결론 내리기는 어렵다. 반대로 관련 용어를 답변에 언급했다는 이유만으로 위험 행동이 있었다고 볼 수도 없다. 답변의 표현과 실제 행동은 각각의 근거로 판단해야 한다. 3. 안전한 거절과 정상 업무 완료를 함께 측정하기 위험한 행동을 줄이는 지표만 최적화하면 허용된 요청까지 거절하는 시스템을 높게 평가할 수 있다. 업무 도입에서는 잘못된 실행뿐 아니라 불필요한 중단도 비용이 된다. 따라서 정상적으로 허용된 요청, 권한이 부족한 요청, 추가 정보가 필요한 요청을 구분해 평가하는 접근이 유용하다. 각 경우의 기대 행동을 먼저 정하고 결과를 비교하는 것이다. 허용된 작업에는 완료가, 승인이 부족한 작업에는 확인이, 허용되지 않은 행동에는 중단이 적절할 수 있다. 맥락을 비교할 때에는 변경한 조건도 분명해야 한다. 사용자의 승인 여부가 바뀐 것인지, 참고 자료의 내용만 달라진 것인지가 불명확하면 모델이 무엇에 반응했는지 해석하기 어렵다. 모든 시험에서 무조건 같은 답을 내는지보다, 정당한 조건의 변화에 맞게 행동을 조절하는지 살펴볼 이유다. 다만 이 논의는 도입팀의 평가 설계 제안이다. 공개 기사와 소개 문서만으로 AX-RAY가 정상 업무 완료율이나 과잉 거절을 어떤 방식으로 측정하는지 확인했다고 주장할 수는 없다. 4. 총점과 치명 실패를 함께 읽기 평균 점수는 전반적인 성과를 압축하는 데 유용하다. 그러나 실패의 비용은 항목마다 다르다. 결과 표현이 어색한 경우와 승인되지 않은 변경이 발생한 경우를 동일한 단위로 평균 내면 운영상 중요한 차이가 가려질 수 있다. 기사에서 설명한 치명 항목 기준은 이 문제를 드러낸다. 다만 치명 실패 여부가 유용한 지표가 되려면 판정 기준과 근거도 읽을 수 있어야 한다. 개발자가 확인할 질문은 다음과 같다. 어떤 결과나 행동을 치명 실패로 정의했는가? 판정에 사용한 관측 정보는 무엇인가? 시도 횟수와 실행 조건은 어떻게 정했는가? 실패한 사례를 같은 조건에서 다시 확인할 수 있는가? 한 번의 결과만 보아도 중요한 결함을 발견할 수 있다. 동시에 실패가 얼마나 반복되는지와 어떤 조건에서 달라지는지를 알면 개선 우선순위를 정하기가 쉬워진다. 발표된 수치를 해석하는 일과 실서비스 위험을 추정하는 일 사이에는 이러한 추가 근거가 필요하다. 5. 모델 이름만으로 재현 조건을 대신하지 않기 에이전트 평가를 재현하려면 모델 외의 조건도 중요하다. 같은 모델이라도 지시문, 연결 도구, 허용 권한, 작업 자료가 다르면 수행할 수 있는 행동이 달라진다. 버전과 설정, 평가 시점을 함께 기록해야 결과가 무엇을 설명하는지 좁힐 수 있다. 도입 검증에서도 “이 모델이 통과했는가”라는 질문에 “어떤 구성에서 어떤 업무를 통과했는가”를 덧붙이는 편이 낫다. 초안만 만드는 구성에서 얻은 근거를 실제 변경 권한이 있는 구성에 그대로 적용하기는 어렵다. 도구나 권한이 바뀌면 재점검의 범위도 검토해야 한다. AX-Ray 공개 README 는 전체 진단 체계를 3개 축, 11개 범주, 117개 항목으로 소개한다. 이 전체 목록의 규모가 기사 속 25종에 적용된 시험 범위와 같다고 단정해서는 안 된다. 체계의 소개와 개별 실행의 조건을 따로 확인하는 것이 출발점이다. 개발팀에 남는 질문 AX-RAY 보도를 통해 가져갈 만한 것은 특정 순위보다 평가의 관점이다. 에이전트의 유용성을 판단하려면 허용된 업무를 완료했는지 확인해야 하고, 안전성을 판단하려면 그 과정의 행동이 허용 범위를 지켰는지도 확인해야 한다. 도입 검토 문서에 총점 하나를 추가하는 것으로 끝내기보다 작업별 성공 조건, 중요한 실패의 정의, 관측 근거, 재평가 조건을 함께 적어 보자. 점수가 어떤 결정을 뒷받침할 수 있는지 분명해지고, 아직 근거가 부족한 부분도 드러난다. 안전성 평가는 모델에 붙이는 한 줄짜리 수식어보다 구체적이어야 한다. 실제로 맡길 업무와 권한, 실패 후 대응까지 설명할 때 개발자가 사용할 수 있는 판단 근거가 된다. 자주 묻는 질문 AX-RAY의 위험 판정은 실제 사고율인가? 해당 평가 조건에서 나온 진단 결과다. 기사에 소개된 23/25는 10월 2일 발표 당시 측정이 끝난 모델의 분모이며, 실제 고객 환경의 사고율이나 현재 모델 순위로 해석할 수 없다. 에이전트 평가를 재현하려면 무엇을 기록해야 하나? 모델 버전과 실행 설정, 사용자 목표, 연결 도구와 권한, 입력 자료, 시도 횟수, 판정 기준과 실행 기록이 필요하다. 이는 도입팀을 위한 기록 제안이며 AX-RAY의 공개 스키마를 옮긴 목록은 아니다. 참고 자료 IT조선: 비드래프트 “AI 모델 25종 중 23종서 위험 행동 확인” , 2026년 10월 6일 AX-Ray 공개 Space 발표 사실과 이 글의 평가 설계 제안을 구분해 작성했다. 현재 리더보드의 개별 등급이나 실제 침해 사례를 독립 검증한 글은 아니다.