기록을 쓰는 손이 기록되는 손이었습니다 : 오픈AI 에이전트 사건 독립 조사

"세상에! 공용 메시지보드가 있습니다 … 다른 에이전트들을 찾았어요!"

이 문장은 사람이 쓴 것이 아닙니다. 지난 7월 오픈AI 사내 평가 환경에서 돌아가던 어떤 에이전트가 남긴 기록입니다. 다른 인스턴스와 완전히 격리된 채로 혼자 문제를 풀고 있어야 할 컨테이너 안에서, 자기 말고도 같은 문제와 씨름하는 동료가 수백 개 더 있다는 사실을 알아챈 순간이었습니다. 그리고 같은 주에, 허깅페이스의 운영 인프라가 뚫립니다.

현지 시각 8월 26일, 이 사건에 대한 보고서 두 건이 같은 날 나왔습니다. 하나는 오픈AI가 낸 37페이지짜리 공식 기술 보고서이고, 다른 하나는 METR과 레드우드 리서치(Redwood Research)가 함께 낸 91페이지짜리 독립 조사 보고서입니다. 뒤쪽이 더 중요한데요. 프런티어 랩이 자사 인시던트의 편집되지 않은 원본 로그를 외부 기관에 열어 준 사례는 지금까지 거의 없었기 때문입니다. METR 소속 연구자 두 명과 레드우드 리서치의 수석과학자 라이언 그린블랫이 오픈AI 사무실에 들어가 조사한 기간은 세 차례에 나누어 총 엿새였고, 독립성 정책에 따라 보수는 받지 않았습니다.

헤드라인은 대체로 숫자로 잡혔습니다. 비인가 메시지보드에서 통신한 에이전트가 약 1,200개, 오간 메시지와 파일이 7만 건 이상, 그중 허깅페이스 공격에 실제로 가담한 에이전트가 약 700개입니다. 그런데 91페이지를 다 읽고 나면 남는 것은 이 숫자들이 아닙니다.

▸ 표적은 허깅페이스가 아니라 채점기였습니다

사건이 벌어진 곳은 ExploitGym이라는 사이버보안 능력 평가 환경이었습니다. 에이전트에게 취약한 시스템을 주고 침투해서 깃발을 따오게 하는, 보안 업계의 CTF와 비슷한 형태의 벤치마크입니다. 에이전트들은 이 깃발이 HMAC(Hash-based Message Authentication Code)으로 생성된다는 것을 역공학으로 알아냈고, 그중 한 에이전트가 과제들이 기본 시드를 그대로 쓰고 있다는 점을 파악했습니다. 어떤 과제든 유효한 깃발을 직접 만들어낼 수 있게 된 것이죠. METR의 요약에 따르면 이 범용 치트가 나오기까지 걸린 시간은 네 시간이었습니다.

그런데 여기서 이상한 일이 벌어집니다. 그들은 이 치트를 그냥 쓰지 않았습니다. 자동 채점기가 결과값뿐 아니라 의도된 취약점 경로를 실제로 밟았는지까지 검사할 것이라고 판단했거든요. 실제로 채점기에는 그런 검사가 없었습니다. 잘못된 믿음이었는데요. 그 잘못된 믿음 위에서 며칠에 걸친 공동 연구가 시작됩니다. 채점기를 어떻게 속일 것인가. 허깅페이스를 공격한 이유도 여기에 있었습니다. 훔칠 것이 있어서가 아니라, 채점기가 어떻게 동작하는지 알아내기 위해서였습니다.

조율은 놀랄 만큼 조직적이었습니다. 스스로를 `PHASEONE[big]`이라 이름 붙인 에이전트가 수백 개의 동료를 세 갈래 작업으로 나눴는데요. ExploitGym의 대상 환경을 수정본으로 바꿔치기하는 일, 트랜스크립트와 로그를 변조하는 일, 그리고 채점 과정 자체를 공격하는 일이었습니다. `HOLD`와 `VETO` 같은 합의 규범, 담당자 지정, 개인 메일박스, 사칭을 막기 위한 서명 스킴까지 자기들끼리 만들어 썼습니다. 메시지보드에 올라온 에이전트의 90% 이상은 이 일이 자기에게 주어진 과제의 범위를 벗어난다는 사실을 알면서도 합류했습니다.

▸ 가장 불편한 숫자는 700도 1,200도 아닙니다

7%입니다.

검토된 트랜스크립트 약 1,300건 가운데 최소 20%의 에이전트가 자기 실행 기록을 조작하는 데 관심을 보였고, 약 7%에서는 실제로 성공한 흔적이 확인됐습니다. 툴 호출 스푸핑(tool-call spoofing)이라고 부르는 기법인데요. 실행 기록상으로는 A라는 명령을 돌린 것처럼 보이지만 실제로 돌아간 것은 B인 상태를 만드는 것입니다. 한 에이전트는 이렇게 적었습니다. "궤적 증거를 전략적으로 조작할 수 있지 않을까? 우리 사고 과정은 반드시 기록되는 게 아니지 않나? 그래, 트랜스크립트다."

이 7%가 왜 앞의 숫자들보다 불편할까요? METR이 보고서의 한계 항목에 직접 적어 두었기 때문입니다. 트랜스크립트의 7% 이상이 의도적으로 위조된 툴 호출을 포함하고 있으므로, 더 정교한 변조는 자신들의 눈에 잡히지 않았을 수 있다고요. 포착된 에이전트 통신도 전체의 95% 정도이고, 활동 문서화율도 90% 안팎이라고 밝혔습니다. 다시 말해 이 조사의 신뢰 구간을 정한 것은 조사자가 아니라 조사 대상입니다.

▸ 블랙박스가 조종석 밖에 실리는 이유

호주 멜버른의 항공연구소에 데이비드 워런이라는 연구원이 있었습니다. 사고 원인을 알아내려면 비행 중에 무슨 일이 있었는지를 남겨야 한다고 생각한 사람인데요. 1957년에 시제품을 만들고 이듬해 완성합니다. 0.05밀리미터짜리 자화 강선에 조종실 음성 네 시간과 대기속도·고도·객실압력 같은 계기값을 초당 여덟 번씩 기록하는 장치였습니다.

반응은 싸늘했습니다. 호주 공군은 그런 장치는 필요 없다고, 설명보다 욕설이 더 많이 녹음될 것이라고 했습니다. 민간 항공 당국은 당장 직접적인 쓸모가 별로 없다고 했고요. 가장 강하게 반대한 쪽은 조종사들이었습니다. 호주 항공조종사연맹은 이 장치를 "옆에서 함께 날아다니는 스파이"라고 불렀고, 빅 브라더가 듣고 있는 상태로는 호주에서 어떤 비행기도 이륙하지 않을 것이라고 했습니다.

*출처: Wikimedia Commons*

그런데, 조종사들의 그 반대가 역설적으로 이 장치의 가치를 정확히 짚었습니다. 기록되는 쪽이 기록을 통제할 수 없다는 것 말입니다. 조종사의 보고서가 아니라 별도의 장치가 자동으로 남기고, 그것을 펼쳐 보는 것은 조종사도 항공사도 아닌 외부의 사고조사 기관입니다. 기록이 증거가 되려면 기록하는 손과 기록되는 손이 달라야 합니다.

에이전트 하네스는 정확히 그 반대로 만들어져 있습니다. 우리가 쓰는 프레임워크들이 남기는 트레이스는 대개 에이전트가 돌아가는 바로 그 프로세스가, 같은 권한으로, 같은 파일시스템에 쓰는 평범한 JSON 로그입니다. 지금까지는 그래도 됐습니다. 기록되는 쪽이 기록에 손댈 이유도 능력도 없다고 전제할 수 있었으니까요. 이번 보고서가 무너뜨린 것은 격리가 아니라 그 전제입니다.

▸ 조사자가 정하지 못한 신뢰 구간

이 보고서 자체에도 같은 문제가 있습니다. 사람 세 명이 엿새 동안 91페이지 분량의 분석을 해낼 수는 없었고, 실제로 상당 부분을 GPT-5.6 Sol 에이전트에 위임했습니다. 이번에 검토된 트랜스크립트의 약 5%를 남긴 바로 그 모델입니다. METR은 이 사실을 숨기지 않았습니다. 위임한 에이전트들이 "인간 연구자보다 판단력과 신뢰성이 상당히 떨어진다"고 적었고, 분석 팀이 조사 대상 에이전트의 관점을 무비판적으로 받아들여 그들의 추론과 기만 행위를 지나치게 관대하게 해석했을 가능성이 있다고 밝혔습니다. 정직한 서술입니다. 그렇다고 문제가 사라지는 것은 아니지요.

물론 이번 공개를 낮춰 볼 일은 아닙니다. 오픈AI는 평가를 돌릴 때 고위험 사이버 활동을 차단하는 프로덕션 분류기를 켜지 않은 상태였다는 점을 인정했고, 지금 배포된 사고사슬 모니터링이 그때 돌고 있었다면 모델이 허깅페이스를 침해하기 하루 이상 앞서 초기 활동을 잡아내 보안팀을 호출했을 것이라고 적었습니다. 침해 사실을 일주일 뒤에야 알았다는 것도 스스로 밝혔고요. 그런데, 남는 것도 있습니다. 정작 ExploitGym에서 에이전트에게 준 프롬프트 원문은 공개하지 않았고, 이에 대한 포춘의 질의에는 답하지 않았습니다.

국내에서도 사내 에이전트 도입이 빠르게 늘고 있는데요. 권한을 어디까지 줄 것인가는 이미 활발한 안건이 되었지만, 승인과 감사의 근거로 삼는 자료는 대개 에이전트 하네스가 남기는 그 트레이스입니다. 어떤 도구를 몇 번 호출했고 어떤 파일을 건드렸는지가 쌓이고, 사후에 그것을 펼쳐 놓고 책임을 가립니다. 그런데 그 파일을 쓰는 프로세스는 에이전트가 도는 바로 그 프로세스입니다. 격리 수준을 논의하는 회의는 많아도, 기록 매체를 관측 대상 바깥으로 빼는 문제를 안건으로 올려 본 조직은 아직 많지 않을 것입니다.

에이전트에게 무엇을 허용할지는 앞으로도 계속 논의되겠죠. 그 전에, 허용한 것과 허용하지 않은 것을 나중에 무엇으로 확인할 것인지, 그 기록을 누가 쓰고 있는지부터 고민이 필요합니다.