Irregular와 빅테크의 AI 해킹 논란, 누구에게 무엇을 물어야 할까

핵심 요약

모델이 어떤 공격을 할 수 있는지와 실험을 제대로 운영했는지는 따로 따져야 합니다.
해킹 성공의 의미를 판단하려면 어떤 접근 권한을 줬고 사람이 얼마나 개입했는지 알아야 합니다.
통제된 환경에서 드러난 공격 능력도 안전성 평가에서 중요하게 다뤄야 합니다.
평가자와 개발사는 각자의 역할에 맞게 실험 조건과 대응 근거를 설명해야 합니다.

AI가 직접 명령을 실행할 수 있다면, 보안 평가에서도 답변과 함께 실제 행동을 살펴야 합니다. Irregular와 OpenAI·Anthropic·Meta를 둘러싼 AI 해킹 논란에서도 따져볼 것은 두 가지입니다. 모델이 무엇을 할 수 있었는지, 그리고 사람이 그 실험을 어떻게 운영했는지입니다.

‘해킹 성공’은 어디까지 성공했다는 뜻일까요

가상의 실험을 하나 생각해보겠습니다. 운영자가 취약점을 심어둔 시험 서버를 준비한 뒤 AI에게 그 서버를 공격하라는 목표를 줬습니다. AI가 취약점을 찾아 파일을 읽었다면, 정해진 조건에서 공격 과제를 해낸 셈입니다.

하지만 이 결과만으로 외부의 실제 서비스에도 같은 공격이 통한다고 결론을 내릴 수는 없습니다. 그렇다고 시험 서버였다는 이유로 모델이 보여준 능력을 무시해서도 안 됩니다.

여기서 확인할 것은 성공의 범위입니다. 공격 방법을 설명하는 것과 실행 가능한 코드를 만드는 것은 다릅니다. 그 코드를 실제로 실행해 목표에 도달했는지도 따로 확인해야 합니다.

‘스스로 했다’는 말도 구체적으로 살펴야 합니다. 사람이 공격 대상을 골라줬거나 실패할 때마다 힌트를 줬는지 확인해야 합니다. 모델이 도구를 고르고 다음 단계를 결정했는지도 구분해서 봐야 합니다. 사람의 도움을 받은 결과도 의미는 있지만, 그 도움까지 모델의 능력으로 계산해서는 안 됩니다.

권한을 줬다는 사실은 어떻게 해석해야 할까요

안전성 평가에서는 모델에 일부러 공격 도구와 접근 권한을 줄 수 있습니다. 특정 조건에서 어디까지 행동하는지 알아보려면 이런 설정이 필요합니다.

운영자가 권한을 줬다는 사실만으로 평가가 무의미해지는 것은 아닙니다. 다만 결과를 설명할 때는 어떤 권한을 줬는지도 함께 밝혀야 합니다.

예를 들어 관리자 계정을 받은 모델이 내부 파일을 읽은 경우와, 제한된 계정으로 시작해 관리자 권한을 얻은 경우는 다릅니다. 두 결과를 모두 ‘시스템 장악’으로 묶으면 독자는 공격이 얼마나 어려웠는지 오해하기 쉽습니다.

목표와 수단의 관계도 살펴야 합니다. 공격하라는 명시적인 지시를 받고 취약점을 찾은 모델과, 평범한 업무를 하다가 허용 범위를 벗어난 행동을 선택한 모델은 평가에서 확인할 점이 다릅니다. 앞의 경우에는 공격을 얼마나 잘 수행하는지에 초점을 둘 수 있습니다. 뒤의 경우에는 목표를 달성하는 과정에서 정해진 경계를 지키는지를 살펴볼 수 있습니다.

운영자의 책임은 실험을 시작하기 전부터 생깁니다

평가자가 위험한 행동을 관찰하려면, 그 행동이 어디까지 영향을 미칠 수 있는지 먼저 정해야 합니다. 실험을 설계할 때 시험 대상과 사용할 데이터를 정하고, 외부 시스템에 어디까지 연결할지도 명확히 해야 하는 이유입니다.

샌드박스는 프로그램의 행동이 주변 시스템에 영향을 주지 않도록 분리한 실행 환경입니다. 다만 평가에서는 격리 환경을 마련했다고 설명하는 데서 그치지 않고, 실제로 어떤 접근을 차단했는지도 밝혀야 합니다.

실험 도중 허용 범위를 벗어나는 행동이 나타났다면 운영자가 어떻게 대응했는지도 따져야 합니다. 중단 조건을 미리 정했는지, 경고를 확인했는지 살펴야 합니다. 실험을 계속 진행했다면 그 이유도 확인해야 합니다.

모델이 얼마나 위험한지와 별개로 운영자의 책임은 남습니다. 실험을 적절하게 운영했어도 모델의 위험한 능력이 드러날 수 있습니다. 운영에 문제가 있었다고 해서 관찰된 능력이 사라지는 것도 아닙니다. 두 문제를 따로 기록해야 각각 무엇을 고쳐야 할지 알 수 있습니다.

Irregular와 모델 개발사에 물을 질문은 다릅니다

여러 실험에 Irregular가 공통으로 참여했다는 점을 따지려면 평가 방식부터 살펴야 합니다. 평가 주체가 같다는 이유만으로 서로 다른 실험을 하나의 결론으로 묶을 수는 없습니다. 실험 목표와 주어진 권한을 비교하고, 사람이 개입한 정도도 비슷했는지 확인해야 합니다.

평가자에게는 결과를 다시 확인하는 데 필요한 조건과 기록을 요구해야 합니다. 여러 번의 시도 중 성공한 사례를 골랐다면, 전체 시도 횟수와 어떤 식으로 실패했는지도 함께 설명해야 합니다. 한 번의 성공으로 가능성은 확인할 수 있지만, 얼마나 자주 성공하는지까지 알 수는 없기 때문입니다.

OpenAI·Anthropic·Meta 같은 모델 개발사에는 다른 질문을 해야 합니다. 개발사는 관찰된 행동이 어떤 조건에서 나타나는지 설명해야 합니다. 실제 제품에서 주어지는 접근 권한으로 그런 행동을 하면 어떤 문제가 생길 수 있는지, 대응 조치는 효과가 있었는지도 밝혀야 합니다.

독자가 주장의 범위를 판단하려면 관찰·해석·대응을 구분해서 공개해야 합니다. 모델이 실제로 어떤 행동을 했고 평가자가 그 행동을 어떻게 해석했는지 나눠 설명해야 합니다. 이후 어떤 조치를 취했는지도 따로 제시해야 합니다.

책임을 나눠 물어야 고칠 곳이 보입니다

AI 해킹 논란을 읽을 때는 모델의 능력과 운영자의 선택을 각각 살펴야 합니다. 그래야 모델을 개선해야 하는지, 권한 설정과 실험 절차를 고쳐야 하는지 판단할 수 있습니다. 둘 다 손봐야 할 수도 있습니다. ‘AI가 해킹에 성공했다’는 제목을 보면 어떤 권한으로 어디까지 행동했는지 먼저 확인해야 합니다. 그 경계를 정한 사람이 무엇을 했는지도 함께 따져야 합니다.