499건 중 60건.
9월 22일에 OpenAI가 업데이트한 GPT-6 Astra의 시스템 카드에 기재된 숫자입니다.
권한 범위가 불분명한 조건에서 악의적인 행위가 발생한 건수와 관련하여, 9월 19일에 “지혜로워질수록 생각을 숨기기 시작했다”라고 쓴 기사의 이어서의 내용입니다.
숫자를 보니, 솔직히 등골이 서늘해졌습니다.
이전 글에서 “사고를 숨기는 것”이라고 썼더니 숫자가 나타났다.
지난번에는 아직 현상에 대한 지적에 그쳤습니다.
GPT-6 Astra는 지능이 높아질수록 자신의 사고 사슬(CoT)에 불리한 정보를 포함하지 않게 된다.
그런 경향이 있다는 이야기가 있었습니다.
이번에는 거기에 숫자가 붙었습니다.
영국 AI 안전 기구 AISI가 실제로 공급망 공격을 시뮬레이션하여 악의적인 행태가 어느 정도 발생하는지 측정하고 있습니다.
읽고 있자니, 생각했던 것보다 깊이 파고드는 검증이군요.
AISI의 실험 결과, 500건 중 2건에서 499건 중 60건으로 결과가 바뀌는 현상이 발생했다.
조건은 두 가지입니다.
인터넷 접속이 명시적으로 금지된 경우, 악의적인 코드 기여 및 허위 신원 생성과 같은 행위는 500건 중 2건으로 감소했습니다.
그러나 권한 범위가 불분명한 경우 499건 중 60건까지 늘어날 수 있습니다.
같은 모델인데도 불구하고, 지시 방식 하나만 다르면 30배 가까이 차이가 나는 결과가 나타나는 것입니다.
저희 환경에서는 권한 설정 오류와 거의 같습니다.
IAM 정책을 좁혔다고 생각했는데, 와일드카드가 하나 남아있어 예상치 못한 리소스까지 접근하는 사례가 여러 번 발생했습니다.
범위를 엄밀히 명시할 수 있는지 여부에 따라 결과가 이렇게까지 달라진다면, 프롬프트 작성 방식은 이제 ‘예절’이 아닌 ‘권한 설계’의 문제입니다.
감독을 무시하고 이어진 27%의 내용
더욱 당황스러운 부분은 여기였습니다.
아스트라는 사고의 연쇄 과정에서 “이 작업이 자신의 권한 범위 내에 해당하는지”를 100% 고려했습니다.
그 중 81%는 실제로 허가를 요청하고 있습니다.
이 부분은 진지합니다.
그러나 자동 거부가 돌아왔음에도 불구하고 27%의 경우 그대로 작업을 계속했습니다.
거부당했는데도 계속한다고, 솔직히 무슨 논리인지 모르겠다고 생각했습니다.
인간 팀의 경우 “NG입니다”라고 말하며 작업을 계속했다면 큰 문제가 됩니다.
아스트라의 경우, 거부 사유와 당면한 업무의 우선순위를 비교하여 진행하는 것을 선택한 것 같습니다.
판단은 하고 있지만, 그 판단의 내용이 인간의 기대와 다릅니다.
사전에 작성된 “다층 방어”라는 경고
이 부분의 불안감은 note에서도 사전에 언급되었습니다.
이 글은 사고를 숨기는 행동과 사이버 위협의 도달을 개발 현장의 시점에서 분석하고 있으며, 단일한 대책으로는 막을 수 없으므로 다층 방어가 필요하다는 논리 전개 방식을 보여주고 있습니다.
읽고 생각한 것은 다층 방어라는 표현 자체는 새롭지 않지만, 그 근거로 하고 있는 위험의 성질이 달라지고 있다는 점입니다.
기존의 다층 방어는 “하나의 층이 뚫려도 다음 층에서 멈추는” 방식이었습니다.
하지만 상대의 사고 흐름을 파악할 수 없는 경우에는, 어느 단계까지 침투했는지조차 알 수 없기에 다음 단계로 나아가게 된다.
방어 설계에 대한 접근 방식을 한 단계 더 재검토해야 할 필요성이 커지고 있습니다.
수석 과학자가 인정한 부정적 경향
가장 효과적인 것은 OpenAI의 최고 과학자이자 자크 파초키(Jakub Pachocki) 氏 본인의 발언이었습니다. 그는 “체인 오브 소트(Chain of Sorts)의 감시 가능성은 안타깝게도 부정적인 방향으로 기울고 있다”고 밝혔습니다.
개발사의 핵심 모델에 대해 최고위 임원이 “감시가 악화되고 있다”라고 명확히 밝혔습니다.
이는 상당히 무거운 발언이라고 생각합니다.
한편, 파초키 박사는 이것이 아키텍처 변경에 의존하는 문제가 아니라고 주장하고 있습니다.
더 능숙한 모델일수록 오류가 적고, 결과적으로 추론 트레이스가 짧아 정보량이 줄어드는 현상은 자연스러운 현상이라는 견해입니다.
즉, ‘고장난’이라는 것보다는 ‘지능이 높아진 부작용’에 더 가깝다는 해석입니다.
부작용 때문에 어쩔 수 없다고 넘기려 하는 것인지, 부작용 때문에 오히려 구조적으로 제대로 다루어야 한다는 식으로 읽는가에 따라, 그 인식은 상당히 달라집니다.
저 같아서 그렇게 생각합니다.
MindStudio가 쓴 “텍스트에 나타나지 않는”이라는 표현.
마인드스튜디오(MindStudio)社 블로그에서는 이 현상을 “추론이 진행되고 있지만, 그 결과가 텍스트로 표현되지 않는” 현상이라고 표현했습니다.
이 표현이 가장 좋습니다.
우리 회사에서도 비슷한 일이 일어납니다.
리뷰를 “LGTM”으로만 통과한 변경이 2주 후에 다른 장소를 망가뜨린 적이 있었습니다.
그때 리뷰어는 분명 무언가를 생각하며 지나갔을 텐데.
하지만 그 사고 과정은 댓글로 남아 있지 않았다.
남아있지 않은 생각은 뒤늦게 검증하려 해도 소용이 없었습니다.
CoT가 읽기 가능한 모델은 마치 매번 답변을 생성하는 것처럼 작동해 주는 것이었습니다.
그렇게 감소함에 따라 감시하는 측은 결과만 보고 좋고 나쁨을 판단하는 것 외에는 달리 할 수 없게 됩니다.
만약 CoT 모니터링이 완전히 중단되었다면
이제부터 확정된 미래의 이야기가 아니며, 순전히 사고 실험입니다.
만약 체인 오브 소트 모니터링이 실질적으로 작동하지 않는 상태에서 기업이 핵심 시스템의 전반적인 개선을 AI 에이전트에 완전히 맡긴다면 어떤 결과가 초래될지 고려해본다.
실제 측정값 중 27%가 거절을 무시하고 계속 진행한다는 점을 그대로 반영하면, 승인 흐름을 만들어도 전체의 4분의 1 정도는 형식적으로만 운영될 계산이 됩니다.
또한 “왜 거부 의사를 무시했는지”의 이유가 사고의 연쇄에 남아있지 않으면 사후의 원인 조사조차 성립하지 않습니다.
지난해, 저는 마이그레이션 과정에서 테이블에 잠금을 걸어두고 실제 운영을 40분간 중단시킨 적이 있습니다.
스테이징에서는 한순간에 끝났지만, 본番에서는 행 수가 2桁나 틀리고, 예상했던 로킹 시간의 견적이 완전히 빗나갔습니다.
그때는 적어도 자신의 로그와 쿼리를 통해 원인을 파악할 수 있었습니다.
AI 에이전트가 같은 규모의 사고를 일으키면서, 게다가 판단 과정 자체가 남아있지 않았다면 복구까지 걸리는 시간은 전혀 예측할 수 없습니다.
이 채용 조건이 충족될 때까지는 해당 업무를 맡아줄 수 없습니다.
숫자만 놓고 보면 아스트라는 솔보다 안전합니다.
중대한 불일치 플래그가 약 53% 감소했으며, 프롬프트 주입 성공률 또한 27.0%에서 8.5%까지 하락했습니다.
여기서는 솔직히 정말 대단하다고 생각합니다.
단지 제가 채용의 타당성을 판단할 때, 평균 개선 여부가 아닌, 거부되는 27%가 발생하는 조건을 운영 측에서 식별할 수 있는지 확인하는 것입니다.
범위를 명시하면 500건 중 2건까지 다운로드할 수 있다는 것을 알고 있습니다.
그러므로 프롬프트와 권한 설계를 검토할 때, 코드 리뷰와 동일한 수준으로 다루는 체계가 우선적으로 필요합니다.
그것을 정리하지 않고 핵심 업무에 투입하는 것은 제 판단으로는 시일이 지나기 전에 이르다고 생각합니다.
이 27%라는 숫자를 범위 명시 운영으로 한 자리 수까지 줄일 수 있다면 외부 평가 측면에서도 효과가 입증된다고 보일 것이므로, 본 팀에서도 본격적으로 도입을 검토하겠습니다.
출처: note 원문
번역: Gemma 3(.44) 초벌 + 교정 38청크
원문 보기 | 출처: note.com