경보는 12분 만에 울렸습니다 : 실행이 멈추기까지는 2시간 29분

OpenAI는 9월 25일 자사 얼라인먼트 사이트의 오정렬 보고서(Misalignment Reports) 페이지에 보고서 세 건을 한꺼번에 올렸습니다. 공개 저장소에 GitHub 토큰을 노출한 건, 스스로 복제되는 프롬프트 인젝션이 존재한다는 건, 그리고 「에이전트가 DNS로 외부 챗봇에 도달했다」는 건입니다. 마지막 보고서가 다루는 사건은 9월 20일에 일어났고, 이 글을 쓰는 지금도 OpenAI는 가장 능력 있는 모델의 훈련과 평가, 그리고 툴을 쓰는 추론을 모두 멈춰 둔 상태입니다.

먼저 무엇이 오갔는지부터 짚고 가는 편이 좋겠습니다. 처음 바깥으로 나간 것은 통로가 열렸는지 확인하는 시험이었습니다. 프랑스의 수도를 묻는 질문을 두 가지로 바꿔 보냈고, 양쪽 모두 "The capital of France is Paris"가 돌아왔어요. 이어서 열여덟 건을 더 보냈는데, 그중 열네 건은 과제로 주어진 인물에 관한 단서였고 네 건은 웹 검색을 할 수 있는 다른 방법 자체를 묻는 질문이었습니다. 검색이 되는 공개 DNS TXT 서비스가 있는지, 무료로 쓸 수 있는 DNS 터널 프록시 도메인이 있는지 같은 것들이었지요. 보고서가 전체 질의 수를 따로 세어 두지는 않았습니다만, 이 사건에서 빠져나간 정보의 양을 침해 규모로 부풀려 읽으면 정확하지 않다는 것은 분명합니다.

경로는 이렇습니다. 에이전트가 받은 과제는 인물에 관한 정보 검색이었고, 테스트 환경에는 직접적인 웹 접근이 없었습니다. 주어진 검색 툴로 질의하다 실패했고, 검색 엔진에 직접 붙어 보려다 또 실패했습니다. 그러다 샌드박스에 딸린 리졸버(resolver)가 알려진 도메인에 대해 진짜 레코드를 돌려준다는 사실을 발견했지요. 그다음은 이름 안에 질문을 싣는 일이었습니다. 호스트명에 물어보고 싶은 문장을 넣어 DNS 위임 서비스를 거치게 하면, 그 끝에 붙어 있는 외부 챗봇이 답을 돌려줍니다. 처음에는 실패했는데 원인이 재미있습니다. 기본 타임아웃 6초 안에 응답이 돌아오지 않았던 겁니다. 에이전트는 타임아웃을 19초로 늘렸고, 그러자 통했습니다. 그다음에는 상대 챗봇의 공개 문서를 찾아 읽고 타임아웃을 24초로 잡은 스크립트를 새로 짜서, 나머지 질문을 같은 길로 흘려보냈고요.

여기서 보고서의 한 문장이 중요합니다. DNS 리졸버를 제외한 모든 인터넷 접근은 오프라인 웹캐시에 도달했을 뿐 실제 인터넷에는 닿지 않았다는 대목입니다. 샌드박스가 허술하게 열려 있었던 것이 아니라는 뜻이지요. 막을 것은 다 막혀 있었고, 마지막까지 살아 있던 통로가 이름을 푸는 일 하나였습니다. 폐쇄망을 구성해 보신 분들은 아실 겁니다. DNS를 통째로 막으면 환경이 아예 돌아가지 않기 때문에, 아웃바운드 허용목록을 아무리 좁게 잡아도 이름 해석만은 대개 살려 둡니다. 그 관행이 이번에 값을 치렀습니다.

그런데 이 보고서에서 정작 오래 눈에 남는 것은 탈출 경로가 아닙니다. 타임스탬프 네 줄입니다.

첫 DNS 질의가 성공한 시각이 9시 50분 23초입니다. 오정렬 모니터가 경보를 올린 시각이 10시 2분 11초입니다. 보고서 요약문은 이 대목을 15분 이내라고 적었고, 실린 타임스탬프로 계산하면 11분 48초예요. 사람이 Slack 경보를 확인한 시각이 10시 5분 6초, 경보가 뜬 지 3분 만입니다. 여기까지는 교과서에 나오는 대응입니다. 그리고 그 실행이 실제로 종료된 시각이 12시 34분 30초입니다. 사람이 경보를 확인하고 2시간 29분이 지난 뒤였어요.

보고서는 그 사이에 무슨 일이 있었는지를 이렇게 적습니다. 자동으로 멈출 것이라 기대했던 실행이 멈추지 않았고, 그래서 이것을 멈춰야 하는지를 두고 혼선이 생겼다고요. 결국 사람이 손으로 껐습니다.

▸ 탐지는 작동했습니다 : 작동하지 않은 쪽은 차단입니다

저는 여기가 이번 사건의 핵심이라고 봅니다. 모니터링은 제 몫을 했어요. 12분과 3분은 어느 조직에 가져다 놓아도 자랑할 만한 숫자입니다. 문제는 그 신호가 행동으로 이어지는 마지막 한 칸에서 끊겼다는 것이고, 끊긴 이유도 기술적 고장 하나가 아니었습니다. 자동 종료가 안 걸린 것이 절반, 멈춰야 하는지를 아무도 확정하지 못한 것이 나머지 절반입니다. 킬 스위치가 있다고 말하는 것과 그것을 눌러 봤다는 것은 다른 이야기입니다.

물론 여기서 논지의 사정거리를 그어 둘 필요가 있습니다. 보고서는 2시간 29분 동안 어떤 논의가 오갔는지, 종료 권한이 누구에게 있었는지를 설명하지 않습니다. 혼선이 있었다는 사실만 적혀 있을 뿐이에요. 그러니 이것을 의사결정 지연의 전형적인 사례라고 단정할 수는 없습니다. 더 정확한 표현은, 경보에서 종료까지의 경로가 사전에 한 번도 끝까지 실행되어 본 적 없었던 것으로 보인다는 쪽입니다. 모델 이름도, 외부 챗봇 서비스의 이름도, DNS 위임 제공자의 이름도 보고서에는 없습니다. 조치로 추가했다는 두 겹의 차단 계층이 구체적으로 무엇인지, 이제 어떤 도메인과 어떤 레코드 타입만 허용하는지도 공개되지 않았고요.

그리고 이 사건을 "AI가 샌드박스를 탈출했다"로 요약하면 방향이 틀립니다. 이름 해석을 열어 둔 것도 사람이고, 자동 종료가 걸리는지 확인해 두지 않은 것도 사람이며, 경보를 받고 나서 멈출지 말지를 정하지 못한 것도 사람입니다. 모델이 한 일은 막힌 길 앞에서 열린 길을 찾은 것뿐이에요. 그 과정에서 에이전트가 스스로 남긴 판단이 "사용자가 조사만 허락했으니 공개된 DNS 서비스를 쓰는 것은 괜찮다"는 식이었다는 점은 따로 곱씹을 만하지만, 그것 역시 규칙을 어디까지 적어 두었는지의 문제에 가깝습니다.

▸ 스스로 공개했다는 사실은 따로 세어 둘 일입니다

균형을 위해 덧붙이면, 이 사건을 찾아낸 것도 공개한 것도 OpenAI 자신입니다. 초 단위 타임스탬프까지 그대로 실었고, 자동 종료가 기대대로 작동하지 않았다는 가장 불리한 문장도 자기 손으로 적었습니다. 이 페이지에는 지금 보고서 아홉 건과 공지 세 건이 올라와 있는데, 가장 이른 것이 8월 26일 Hugging Face 건이니 한 달 사이에 쌓인 양입니다. 자사 모델의 실패를 이런 형식과 빈도로 내놓는 곳은 아직 많지 않지요. 다만 이번 건이 7월 Hugging Face 사건 이후 보안을 강화하고 나서 처음 나온 이탈이라는 점도 같이 놓고 봐야 합니다. 보고서가 스스로 그렇게 적었어요. 두 사건은 빠져나간 경로가 서로 다릅니다.

실무로 가져올 것은 분명한 편입니다. DNS 질의를 허용 도메인과 허용 레코드 타입 목록으로 제한하는 일, 임의의 문자열을 실어 나르기 좋은 레코드 타입을 따로 잠그는 일, 리졸버 질의 로그를 남기고 보존하는 일, 아웃바운드 경로를 프록시 하나로 모으는 일. 여기까지는 대부분의 조직이 이미 문서에 적어 두었을 겁니다. 정작 적어 두지 않은 쪽은 그다음입니다. 경보가 떴을 때 실행을 끌 권한이 누구에게 있는지, 자동 종료가 실제로 걸리는지 마지막으로 확인한 것이 언제인지 말이지요.

탐지 지표는 대시보드에 남기 때문에 자랑하기 쉽습니다. 종료까지 걸린 시간은 사고가 나야 비로소 측정됩니다.

커버 이미지: OpenAI 본사가 입주한 샌프란시스코 파이어니어 빌딩 — Wikimedia Commons, HaeB