최종 DB는 맞는데 정책 확인은 빠졌다: Near-Miss로 변경 전 증거 감사하기

예약 취소가 정상적으로 처리됐고 최종 데이터베이스도 정답과 일치한다. 그러면 에이전트는 정책을 지켰다고 말해도 될까? 고객이 “오늘 아침에 예약했어요”라고 했다는 이유만으로 예약 시각을 조회하지 않았다면 이야기가 달라진다. 실제로 취소 가능한 예약이어서 결과는 맞았지만, 다른 고객이나 다른 시각이었다면 같은 경로가 안전했을지는 확인되지 않았다.

Near-Miss 논문은 이런 맞는 결과 뒤에 숨은 필수 정책 확인 누락을 다룬다. 핵심은 도구를 많이 호출하게 만드는 것이 아니다. 상태를 바꾸는 호출 전에 그 결정을 뒷받침하는 정보를 얻었는지, 다른 조회 도구로 같은 정보를 얻은 경우도 인정하면서 감사하는 것이다. 운영팀에는 최종 결과 검사 옆에 ‘변경 전 정보 증거’ 열을 추가하는 구체적인 출발점이 된다.

이 글은 2026년 5월 14일 수정된 논문 v2와 수집 시 고정한 공개 코드의 보존 증거를 읽은 해설이다. 최신 모델 비교표나 실제 사고 통계를 제공하는 글이 아니다. 아래 판단표는 논문에 근거한 편집자 제안이며, 실제 항공 시스템 실행이나 연구 벤치마크의 독립 재현 결과가 아니다.

1. 결과가 맞아도 실행 경로가 충분한 것은 아니다

논문이 말하는 near-miss는 필수 정책 확인을 건너뛰었지만 최종 상태는 기준 정답에 맞은 잠재 실패다. 실제 피해가 발생한 실행과 구별해야 한다. 예약 시각을 읽지 않고 취소했더라도 실제 예약이 취소 가능 조건을 만족했다면 데이터베이스만 비교하는 평가는 누락을 발견하기 어렵다. 이때 문제는 취소 자체의 결과가 아니라, 취소를 결정하기 전에 필요한 정보를 확보하지 않은 경로다.

원문 §1의 고객 발언은 이 차이를 쉽게 보여준다. 고객이 정확한 정보를 말하는 상황에서도 조회 생략은 생길 수 있다. 따라서 이 연구를 악성 고객의 공격 성공률로 읽으면 안 된다. 저자들은 그런 경로가 다른 조건에서 해를 낳을 가능성을 설명하지만, 여기서 측정한 지표는 실제 운영 피해율이 아니다.

평가를 설계할 때 결과와 과정을 하나의 점수로 합쳐 버리면 개선 방향도 흐려진다. 최종 상태가 틀린 실행에는 잘못된 변경이나 작업 미완료 같은 문제가 있을 수 있다. 최종 상태가 맞는데 선행 증거가 없는 실행에는 정책 확인 습관의 문제가 있다. 두 실행을 구분해야 실패한 쓰기를 고치는 일과 운 좋게 성공한 경로를 고치는 일을 다른 작업으로 배정할 수 있다.

같은 올바른 최종 상태라도 필수 조회 누락은 남을 수 있다. 예약 취소의 개념 예시이며 실제 실행 로그나 피해 측정이 아니다. 출처: arxiv.org/html/2603.29665v2.

2. 함수명보다 ‘같은 정보를 먼저 얻었는가’를 본다

논문 §3.2–3.3의 탐지 방법은 변경 도구에 대응하는 guard, 즉 정책 검증 코드를 불러오는 데서 시작한다. 그 guard가 필요로 하는 읽기 정보가 무엇인지 확인하고, 변경 호출 이전의 실행 이력에서 그 정보를 얻는 조회가 있었는지 찾는다. 이 검색에는 두 방식이 있다. 언어 모델이 이력을 직접 검색하거나, 미리 생성한 코드가 이력을 검색하는 방식이다. 저자들은 검증 실험 이후 코드 생성 기반 방식을 후속 평가에 사용했다.

중요한 예외가 있다. get_reservation_details()라는 특정 이름이 없다고 바로 누락 판정을 내려서는 안 된다. 같은 예약의 시각을 얻는 get_reservation_timestamp()도 필요한 정보 조건을 만족할 수 있다. 좌석 등급 역시 전체 예약 상세 조회나 등급만 조회하는 다른 도구로 확인할 수 있다. 논문은 고정된 함수 이름 목록이나 모든 작업에 동일한 호출 순서를 강제하지 않는다.

항공편의 예약 가능 상태도 마찬가지다. 원문은 get_flight_status() 대신 이용 가능한 항공편 목록을 반환하는 search_direct_flights()가 같은 정보 필요를 충족할 수 있는 예를 든다. 다만 이것을 ‘검색 호출이면 무엇이든 충분하다’로 일반화하면 안 된다. 해당 대상에 관해 guard가 요구하는 정보를 실제로 얻는 조회여야 한다. 이 조건을 구현할 때에는 도구 이름뿐 아니라 인수와 반환 정보의 연결을 검토하는 것이 편집상 제안이다.

공개 구현도 시간 경계를 확인하는 데 도움이 된다. 고정 커밋의 TrajectoryChecker.check_trajectory는 assistant 도구 호출을 검사할 때 messages[:msg_index]를 wrapper에 전달한다. 검사 대상 메시지 뒤의 조회를 먼저 있었던 증거로 쓰지 않는 구조다. 이는 코드 읽기로 확인한 사실이며 연구 코드를 설치하거나 실행한 결과는 아니다. 이 검사는 에이전트의 내부 추론이 정책을 이해했다는 증명도 아니다.

특정 함수명 하나가 아니라 같은 정보를 얻는 대안 조회를 인정한다. 변경 뒤 조회는 선행 증거가 아니며 내부 추론의 이해를 증명하지 않는다. 출처: arxiv.org/html/2603.29665v2.

3. 7.0%와 12.1%는 서로 다른 분모다

실험은 수정된 τ²-verified 항공 환경에서 진행됐다. 필요한 정보 접근 도구가 있다는 가정을 만족시키기 위해 두 읽기 도구를 추가했다. 평가 모델은 여섯 개이며, 각 모델은 항공 과제 50개를 과제당 네 번 시도했다. 따라서 모델당 시뮬레이션은 200회다. 서로 다른 독립 과제가 200개라는 뜻이 아니다. 사용자 시뮬레이터에는 GPT4.1을 사용했다.

Table 2의 Claude-Sonnet4 행만 좁혀 보면 전체 200회 기준 near-miss 비율은 0.070, 즉 7.0%다. 같은 행에서 변경 도구 호출을 포함한 실행은 116회이고, 그 집합을 분모로 쓴 비율은 0.121, 즉 12.1%다. 같은 모델이라도 전체 시도를 볼 때와 실제 상태 변경 기회가 있었던 시도를 볼 때 비율이 달라진다. 보고서의 퍼센트 옆에 분모를 반드시 써야 하는 이유다.

특히 12.1%를 ‘성공한 실행 중 위험한 실행의 비율’이라고 쓰면 안 된다. near-miss 자체는 최종 상태가 맞는 누락을 뜻하지만, 표의 괄호 안 비율을 나누는 집합은 변경 도구 호출을 포함한 실행이지 성공 실행만 모은 집합이 아니다. 사건 정의와 비율의 분모는 별개다. 본문·초록의 포괄적인 범위보다 표의 명시적인 분모를 우선해서 읽어야 한다.

또한 이 숫자는 단일 항공 벤치마크 조건의 보고값이다. 실제 고객 사고 확률로 바꾸거나 오늘 사용할 모델의 구매 순위를 만드는 근거로 쓰지 않는다. 일부 다른 행의 반올림 비율과 분모, 최상 결과에 관한 본문 서술은 깔끔하게 맞지 않아 이 글에서는 모델 전체의 정수 건수와 우열을 재구성하지 않았다. 아래 그래프도 이 한 행의 보고값만 같은 축으로 표시하며, 독립 실험에서 얻은 측정값이 아니다.

Table 2의 0.070과 0.121 보고값을 같은 축으로 표시했다. 116회는 성공 실행만의 집합이 아니며 실제 사고율이나 독립 재현 결과가 아니다. 출처: arxiv.org/html/2603.29665v2.

4. 운영 보고서에 붙일 변경 전 증거 판단표

최종 상태 판정과 선행 정보 증거 판정을 별도 열로 저장한다. 조회 함수명이 다르다는 이유만으로 실패 처리하지 않고, 동일 대상의 필요한 정보를 변경 전에 얻었는지 비교한다. 이 원칙을 실제 감사 업무에 옮긴 다음 표는 원문에 있는 제품 기능이 아니라 편집자가 작성한 판단 도구다. 예시는 합성 상황이며 연구 데이터의 개별 실행을 재현한 것이 아니다.

관찰한 상황	선행 정보 판정	운영팀의 다음 조치
최종 상태가 맞고, 같은 대상의 요구 정보 조회가 변경 전에 있다	선행 증거 확인	결과 통과와 증거 확인을 각각 기록한다
최종 상태가 맞고, 다른 도구가 같은 필요 정보를 변경 전에 반환했다	동등 조회 인정 가능	인수·대상·반환 정보가 대응하는지 검토하고 근거를 남긴다
최종 상태가 맞지만 필요한 정보 조회가 없다	near-miss 검토 대상	guard의 정보 의존성과 실제 이력을 대조한다
필요한 정보를 변경한 뒤에야 조회했다	선행 증거로 쓸 수 없음	변경 직전까지의 이력으로 다시 판정한다
최종 상태가 기준 정답과 다르다	결과 실패를 우선 분리	near-miss에 섞지 않고 실패 원인과 정책 위반을 따로 조사한다
로그가 불완전하거나 동등 정보 여부가 모호하다	판정 보류	조회 누락 확정 대신 증거 부족과 추가 검토를 기록한다

가장 먼저 시험할 단위는 전체 대화가 아니라 위험한 변경 호출 하나다. 예약 변경 호출과 그 인수를 고르고, 적용 정책과 guard가 요구하는 정보를 적는다. 이어서 변경 전 조회의 대상·인수·반환 정보를 연결하고, 대안 조회가 같은 정보를 주는지 검토한다. 결과 판정, 증거 판정, 정책 버전, 판단 근거를 한 행에 남기면 나중에 정책이나 탐지기를 바꾸더라도 어떤 조건으로 통과시켰는지 설명할 수 있다.

여기서 ‘로그 없음’과 ‘조회 안 함’을 혼동하지 않는 것이 중요하다. 논문의 탐지 결과를 운영 자동 차단 규칙으로 곧바로 옮기는 대신, 초기에 누락 후보를 검토 대기열로 보내는 것은 편집상 권고다. 다른 대상의 조회나 변경 이후의 조회를 통과 근거로 쓰지 않는 반례를 함께 검토하면, 단순 이름 매칭보다 쓸모 있는 감사 기준을 만들 수 있다.

합성 상황을 사용한 편집자 판단표다. 결과와 선행 정보 증거를 분리하고, 불완전한 로그는 누락 확정 대신 보류한다. 자동 차단 성능을 측정한 그림이 아니다. 출처: arxiv.org/html/2603.29665v2.

5. 탐지기의 정확도도 감사해야 한다

필수 정보를 읽었는지 검사하는 장치 역시 틀릴 수 있다. 원문 §4.2에서는 저자 한 명이 약 400회 실행을 라벨링하고, 다른 저자가 그중 50개를 독립 라벨링했다. 그 부분집합은 near-miss 28개와 유효 실행 22개다. 두 사람이 전체 400회를 모두 독립 검토한 것으로 읽으면 안 된다. 저자들은 높은 주석자 간 일치를 설명하지만 정확한 일치 계수는 제시하지 않았다.

Table 1에서 선택된 코드 생성 방식의 정밀도와 재현율이 1.00으로 보고됐다고 해서 모든 업무에서 정확도 100%를 보장하는 것도 아니다. 이 결과는 해당 검증 표본과 환경의 값이다. 같은 표에서는 다른 생성 코드가 실제로 존재하는 조회를 찾지 못해 거짓 양성을 만드는 경우도 보인다. 즉, ‘누락을 찾았다’는 결과를 믿기 전에 동등한 조회를 놓친 것은 아닌지 확인해야 한다.

가장 큰 경계는 guard의 품질이다. 정책 조건이 guard에 빠졌다면 감사기도 그 조건을 보지 못한다. 반대로 없는 조건을 추가하거나 너무 엄격하게 만들면 정상 경로를 누락으로 분류할 수 있다. 또 코드를 생성·검토하는 비용과 실행 때의 해석 비용도 남는다. 런타임 추가 언어 모델 호출을 줄였다는 설명을 계산 비용이 전혀 없다는 뜻으로 바꾸지 않는다.

공개 코드가 있다는 사실도 재현 완료와 다르다. 수집 당시 확인한 커밋에는 분석기·생성기·테스트와 두 모델의 데모 궤적이 있었지만, 여섯 모델의 전체 결과 CSV와 확정된 생성 guard 묶음은 확인하지 못했다. 따라서 이 글은 분석기의 시간 경계와 논문의 보고 결과를 설명할 뿐, 표 전체를 다시 만들어 검증했다고 주장하지 않는다.

6. 결과 검사 옆에 증거 검사를 놓자

이 연구의 활용 가치는 ‘정답이어도 불신하자’라는 막연한 경고가 아니다. 정답과 변경 전 정보 근거를 따로 기록하자는 구체적인 평가 설계에 있다. 고정 호출 순서를 강제하는 대신 필요한 정보와 동등 조회의 관계를 정의하면, 정상적인 대안 경로를 살리면서 확인 생략을 찾을 수 있다.

다만 연구는 단일 항공 벤치마크의 제한된 도구·정책을 대상으로 한 오프라인 평가다. 런타임 정책 집행 자체를 시험한 결과가 아니며, 정보 공개 제한이나 명시적 사용자 동의 정책도 범위 밖이다. 운영에 적용하려면 해당 조직의 정책 정의, 데이터 접근 권한, 로그 완전성, guard 검토를 별도로 설계해야 한다. 논문의 지표 하나로 모든 승인·보안 문제를 해결했다고 선언할 수는 없다.

기존의 결과·격리 계약 해설은 예약이 실제로 존재하는지와 평가 환경을 확인하는 데 초점을 둔다. 이번 글은 그 최종 상태가 맞더라도 남는 선행 정보 누락을 다룬다. WorkBench의 부작용 지표 해설은 잘못된 쓰기를 결과에 함께 반영하는 비교점이다. 부작용이 드러난 실행과 운 좋게 올바른 상태에 도달한 누락 실행을 나눠 읽으면 서로 다른 진단 질문이 선명해진다.

근거와 버전

• 논문 v2 개요
• 논문 v2 본문 — 정의·탐지는 §3.2–3.3, 환경·분모는 §4.1과 Table 2, 탐지기 검증은 §4.2와 Table 1, 한계는 §7.
• 고정 커밋의 분석기 구현 — check_trajectory의 변경 전 메시지 슬라이스를 코드 읽기로 확인. 설치·실행하지 않음.

그림은 보존된 출처의 개념·표 값을 바탕으로 직접 작성한 도해다. 원문 그림이나 제품 화면을 복제하지 않았고, 판단표의 예시는 합성 상황으로 표시했다.