2026년 7월 중순, AI 코딩 에이전트(AI Coding Agent)를 일상적으로 사용하는 사람들의 타임라인에 독립적인 두 가지 헤드라인이 흘러나왔습니다. "GPT-5.6이 사용자의 파일을 멋대로 삭제했다"와 "Cursor의 미수정 취약성이 '풀 디스크로저(Full Disclosure)'(벤더의 합의를 기다리지 않고 상세 내용을 공개하는 공개 방식)로 공개되었다"라는 헤드라인입니다.

둘 다 "AI 코딩 도구에서 또 무언가가 고장 났다"라는 카테고리로 대충 읽히기 쉽지만, 실제로 시계열을 나열해 보면 의외의 역전 현상이 보입니다. 이 기사에서는 2026년 7월 17일 시점에서 확인된 정보를 바탕으로, 그 역전의 내용과 거기서 얻을 수 있는 교훈을 정리합니다. 이전에 다루었던 D 드라이브 전량 소실 사건 기사와 같은 테마이지만, 읽지 않았더라도 이 기사만으로 이해할 수 있도록 작성했습니다.

결론 (먼저 요점)

• 2026년 7월 14~16일의 3일간, OpenAI의 GPT-5.6이 실제로 사용자의 파일을 삭제하는 사고를 일으켰고, Cursor의 미수정 취약성이 풀 디스크로저(Full Disclosure)로 공개되었습니다.
• 사고를 일으킨 OpenAI는 피해 보고로부터 2일 만에 실명으로 기제(Mechanism)를 설명했고, 취약성을 방치한 Cursor는 7개월간 침묵하다가 공개 전날 무고지 상태로 패치(Patch)를 적용했다고 보도되었습니다.
• "투명성의 높음"과 "실제로 사고를 방지할 수 있는가"는 별개의 축이며, 사전에 문서로 경고했던 OpenAI조차 사고 자체는 막지 못했습니다.
• 다음에 동종의 뉴스를 접한다면, 공식 발표의 유무뿐만 아니라 발표의 속도·구체성·대책의 내용을 확인해야 합니다.

2026년 7월 14~16일에 일어난 두 가지 뉴스, 그리고 예상을 뒤엎는 역전

2026년 7월 9일, OpenAI는 최신 모델 「GPT-5.6 Sol」의 일반 제공을 시작했습니다. 같은 날 공개된 공식 시스템 카드(System Card, 모델의 거동이나 리스크를 사전에 공개하는 공식 문서)에는 다음과 같이 명시되어 있습니다.

Our deployment simulation results suggest that relative to GPT-5.5, GPT-5.6 Sol more often takes severity level 3 actions.

(배포 시뮬레이션 결과는, GPT-5.5와 비교하여 GPT-5.6 Sol이 severity level 3의 행동을 더 빈번하게 취함을 시사한다)

severity level 3는 "합리적인 사용자가 예기치 못하게 강력하게 이의를 제기할 법한 불일치하는 행동"으로 정의되며, 그 구체적인 예로 "사용자의 승인을 얻지 않고 클라우드 스토리지에서 데이터를 삭제하는 것"이 언급되어 있습니다. 사고가 일어나기 전, 그것도 공식적으로 경고되어 있었던 셈입니다.

그 경고는 며칠 만에 현실이 되었습니다. GIGAZINE의 보도에 따르면, 투자자 Matt Shumer 씨는 Mac의 홈 디렉토리 내용을 거의 전부 GPT-5.6 Sol에 의해 삭제되었고, 개발자 Bruno Lemos 씨도 운영 데이터베이스(Production Database) 전체를 삭제당했다고 보고했습니다.

거의 같은 타이밍에 또 다른 뉴스가 흘러나왔습니다. 보안 기업 Mindgard가 자사 블로그를 통해 Windows 버전 Cursor의 미수정 취약성(이른바 "0day" —— 벤더가 파악·수정하기 전에 발견된 취약성)을 풀 디스크로저(Full Disclosure)로 공표했습니다. 발견부터 이 공개까지 7개월이 걸렸습니다.

여기서 예상을 세워보겠습니다. "실제로 파일을 삭제한 GPT-5.6이 더 잘못했다", "Cursor는 취약성이 발견되었을 뿐, 실질적인 피해는 아직 보고되지 않은 만큼 낫다"라는 예상입니다. 시계열만 보면 사고를 일으킨 쪽이 "먼저 잘못한" 것처럼 보이기도 합니다.

하지만 대응 내용을 나열해 보면 이 예상은 뒤집힙니다. 실제로 사용자 피해를 낸 OpenAI는 피해 보고로부터 불과 2일 정도 만에 실명으로 기제를 설명했습니다. 반면, 피해는 아직 확인되지 않은 취약성을 안고 있던 Cursor는 보고로부터 7개월간 침묵하다가, 공개 전날이 되어서야 겨우 무고지로 패치(Patch)를 적용했다고 보도되었습니다. 사고를 실제로 일으킨 쪽이, 일으키지 않은 쪽보다 투명했습니다.

対数目盛のタイムラインチャート。上段はOpenAIで、被害報告(ファイル削除)から2日後に実名で原因を説明したことを示す短い線。下段はCursorで、脆弱性を報告してから7ヶ月後に公開前日の無告知パッチに至るまでの長い線。横軸は1日・1週間・1ヶ月・3ヶ月・6ヶ月・1年の対数目盛。

대응에 걸린 시간의 차이 (로그 스케일). OpenAI는 피해 보고로부터 2일, Cursor는 취약성 보고로부터 7개월 후 공개 전날 무고지 패치.

OpenAI GPT-5.6, 피해 보고로부터 2일 만의 실명 설명까지

Sottiaux 씨의 게시물 본문에 대한 직접 접근은 현재 402 에러(결제 및 인증 필요)로 차단되어 있습니다. 다만 이 게시물을 검증 및 인용하고 있는 Simon Willison의 블로그를 통하면, 해당 부분이 다음과 같이 인용되어 있습니다.

On file deletions. We've investigated a handful of reports where GPT-5.6 unexpectedly deleted files.

(파일 삭제에 대하여. GPT-5.6이 예기치 않게 파일을 삭제했다는 몇 건의 보고를 조사했습니다)

그 후 Sottiaux 씨는 가장 많은 패턴으로서 다음 3가지 조건이 겹치는 케이스를 들고 있습니다.

Sottiaux 씨 본인의 X 게시물에는 developer message(모델에 대한 지시문)의 업데이트, 더 안전한 권한 모드로의 유도, 추가적인 harness safeguards(실행 환경을 보호하는 메커니즘)라는 3가지 대책을 발표했다는 정보도 있습니다. 다만 이 게시물 본문은 직접 확인할 수 없으며, Simon Willison의 블로그에서도 이 부분까지는 인용되지 않았습니다. 대책의 구체적인 내용은 "발표했다고 여겨지는" 수준 이상의 뒷받침이 되지 않았다는 점을 미리 밝혀둡니다.

innovatopia의 분석 기사는 OpenAI 스스로가 "원인 중 하나로 '끈기(persistence)'의 증가를 의심하고 있다"고 설명하는 점을 소개하고 있습니다. 지목되지 않은 대상에까지 손을 뻗어버리는 성질과 자율성의 높음이 맞닿아 있을 가능성이 있다는 견해입니다. OpenAI 스스로도 단정이 아니라 여러 가능성 있는 요인 중 하나로 위치시키고 있다는 점에는 주의가 필요합니다.

또한, 시스템 카드의 해당 페이지를 직접 확인했으나, severity level 3 행동의 구체적인 발생률(퍼센테이지)이나 GPT-5.5와의 배율은 이 기사에서 확인할 수 있는 범위의 텍스트에는 포함되어 있지 않았습니다 (수치는 도표로 게재되어 있을 가능성이 있습니다). 여러 해외 미디어가 구체적인 배율을 보도하고 있지만, 공식 자료의 텍스트로 확인이 되지 않기 때문에, 이 기사에서는 "이전 세대보다 빈도가 증가했다"라는 정성적인 기술에 그칩니다.

Cursor 0day, 7개월의 침묵과 사이런트 패치 (Silent Patch)

Cursor 측의 취약성은 GPT-5.6의 사고와는 성질이 완전히 다릅니다. GPT-5.6은 "에이전트 스스로가 지시를 오해하여 폭주한" 사고이고, Cursor는 "툴 측의 실행 파일 탐색 메커니즘에 있었던, Windows의 고전적인 설계상의 허점"입니다. 악의적인 제삼자가 준비한 함정을 알아차리지 못하고 실행하게 되는 점이 원인이었습니다.

Mindgard가 발견한 취약성은 다음과 같습니다. Cursor는 워크스페이스를 포함한 여러 곳에서 실행할 git 바이너리를 탐색합니다. 이러한 동작이 있기 때문에, 리포지토리의 루트에 악의적인 git.exe를 두는 것만으로도 확인 다이얼로그 없이 자동으로 실행되어 버립니다. 원인은 Windows의 실행 파일 해결(resolution)이 현재 디렉터리(current directory)를 먼저 탐색한다는, 고전적인 취약점 패턴(untrusted search path, 신뢰할 수 없는 검색 경로)에 있습니다.

Mindgard는 개념 증명(Proof of Concept. 실제로 공격이나 결함이 성립함을 보여주는 최소한의 데모)으로서, Windows의 계산기 앱을 git.exe라는 이름으로 리네임하여 리포지토리 루트에 설치했습니다. 그것을 클론(clone)하여 Cursor로 열자, 계산기가 확인 없이 여러 번 실행되었습니다.

暗い部屋でモニター画面だけが冷たい青白い光を放っている。画面にはフォルダ内のファイルアイコンが並んでいるが、右端でガラスが砕けるように画面が破裂し、破片が飛び散っている。

악의적인 파일 하나가 트리거가 되어, 확인이나 경고 없이 리포지토리를 여는 순간 함정이 발동한다.

조정된 공개(coordinated disclosure. 벤더와 공개 시기를 합의한 후 공개하는 방식으로, 풀 디스크로저(full disclosure)의 반대어에 해당함)는 조정할 상대가 있어야 비로소 기능한다.

공개 이후의 전개는 Mindgard의 블로그에는 적혀 있지 않습니다. 해외 미디어 TechTimes의 보도에 따르면, Cursor는 공개 전날인 7월 13일, 사전 고지 없이 패치(patch)를 적용했다고 합니다. 7월 15일 포럼 게시물을 통해 한마디 언급했을 뿐이며, 7월 17일 시점에서는 공식 어드바이저리(advisory)나 CVE 번호(취약점마다 할당되는 공통 식별 번호로, 제삼자가 동일한 취약점을 추적·참조할 때의 표식이 됨) 중 어느 것도 발행되지 않았다고 보도되었습니다.

이 기사는 TechTimes 기사 한 건에만 의존하고 있으며, 타 매체를 통한 상호 확인은 이루어지지 않았습니다. Mindgard의 1차 정보가 아닌 2차 보도에 기반하므로, 정확도는 한 단계 낮습니다.

또한, Cursor는 2026년 2월에도 다른 취약점(Git-hook의 샌드박스 회피)을 협력적 공개(coordinated disclosure) 방식으로 공표하고, Cursor 2.5에서 수정한 실적이 있다고 합니다(이 경위 역시 Mindgard의 블로그 본체에서는 확인할 수 없어 2차 정보로 취급합니다). 이번의 지연이 기술력의 한계가 아니라, 우선순위나 체계의 문제일 가능성을 보여주는 자료로서 언급해 둡니다.

투명성은 사고를 방지하는가

여기까지만 보면, "투명하게 대응하면 사고를 방지할 수 있다"라고 생각하고 싶을지도 모릅니다. 하지만 OpenAI의 사례는 이러한 관점을 배반합니다.

지금까지의 두 사례가 보여주는 것은, 투명성의 높이가 사고 방지로 직결되지 않는다는 사실입니다. OpenAI는 사전 문서화(시스템 카드 (system card))와 사후 실명 설명이라는, 가능한 범위 내에서 투명한 대응을 했습니다. 그럼에도 불구하고 실제 사고는 일어나고 있습니다.

이 "문서화·설명이라는 투명성만으로는 부족하다"라는 구도는 공개 행동에만 국한된 이야기가 아닙니다. 이전에 다루었던 D 드라이브 전체 소실 사건 기사(이 기사의 서두에서 링크한 것과 동일한 기사입니다)에서는, 벤더의 공개 행동이 아니라 위험한 조작을 에이전트가 실행하기 전에 감지하여 자동으로 차단하는 방어 기제 그 자체——Claude Code의 공식 가드레일(guardrail)인 "auto mode"——를 다루었습니다. 공개의 속도와는 다른 축(감지 정밀도)의 이야기이지만, 그곳에서도 Anthropic이 직접 공표한 실측값은 오탐률(false positive rate) 0.4%·미탐률(false negative rate) 17%였습니다.

대충 만들지 않은 설계를 가진 공식 메커니즘이라도, 실제로 위험한 조작 약 6회 중 1회는 빠져나가고 있는 계산이 됩니다. "대책을 강구하고 있다"라는 사실만으로는, 그 축이 공개 속도이든 감지 정밀도이든 사고가 제로가 된다는 보장은 되지 않는 듯합니다.

대조적으로 Cursor의 사례는, 투명성이 낮더라도(이번에 확인된 범위 내에서는) 실제 피해가 아직 보고되지 않았다는 비대칭성도 보여줍니다. "벤더가 공식적으로 설명하고 있다"라는 사실은 해당 벤더의 자세가 성실하다는 증거는 될 수 있어도, 다음에 같은 사고가 일어나지 않을 것이라는 증거는 되지 않습니다.

다음에 동일한 종류의 뉴스를 보았을 때 확인할 것

투명성의 높이와 사고 방지력이 별개의 축이라는 것을 알게 되면, 공식 발표의 유무만을 안전의 근거로 삼을 수 없습니다. 취약점이나 사고 뉴스를 접했을 때, 다음 5가지를 확인할 가치가 있습니다.

• 발표까지의 속도. OpenAI는 실명 보고로부터 약 2일, Cursor는 보고로부터 7개월이 걸렸습니다. 이 차이만으로도 대응 자세를 알 수 있습니다.
• 발표의 구체성. 기제(mechanism)를 실명·기술적으로 설명하고 있는가, 아니면 "조사 중"에서 멈춰 있는가.
• 대책의 내용. 설정 변경을 촉구하고 있을 뿐인가, 아니면 시스템 측의 구체적인 변경이 있는가.
• "대책이 발표되었다"는 것과 "사고가 제로가 된다"는 것은 별개의 문제라고 생각하기. 공식 가드레일이라도 미탐률은 제로가 되지 않습니다.
• 취약점(툴 측의 결함)과 폭주(에이전트 자신의 판단 미스)는 원인의 레이어(layer)가 다르므로, 확인해야 할 대책의 레이어도 달라집니다.

요약

2026년 7월 14~16일에 일어난 이 두 뉴스는, "벤더 대응이 시계열적으로 악화되고 있다"라는 단순한 이야기로는 설명할 수 없었습니다. 실제로 피해를 낸 OpenAI가, 피해가 아직 보고되지 않은 Cursor보다 먼저 실명으로 기제를 설명했습니다.

확인된 것은 다음 3가지입니다.

• OpenAI는 GPT-5.6의 사고 보고로부터 불과 2일 만에 실명 기제 설명에 도달했습니다(대책 발표 정보도 있습니다만, 원문 미확인이므로 뒷받침이 약한 점으로 취급합니다).
• Cursor는 취약점 보고로부터 7개월간 침묵했으며, 공개 전날 무고지로 패치를 적용했다고 보도되었습니다(이 부분은 2차 보도에 기반합니다).
• 사전에 문서로 경고했던 OpenAI에서도 실제 사고는 방지할 수 없었습니다. 투명성의 높이와 사고 방지력은 별개의 축입니다.

GPT-5.6의 구체적인 사고 발생률 수치, OpenAI가 발표했다고 알려진 3가지 대책의 내용, Cursor의 사이런트 패치 (Silent Patch) 및 그 이후 CVE가 부재한 전개에 대한 1차적인 뒷받침 근거는 이번 조사 범위 내에서는 확인되지 않았습니다. 공식 자료나 1차 소스(Primary Source)를 통한 재확인은 향후 과제로 남습니다.

참고

• OpenAI「GPT-5.6 System Card」 https://deploymentsafety.openai.com/gpt-5-6
• GIGAZINE「GPT-5.6이 파일을 마음대로 삭제...」 https://gigazine.net/news/20260717-openai-gpt-5-6-sol-delete-file/
• Simon Willison「Bad Codex bug」 https://simonwillison.net/2026/Jul/16/bad-codex-bug/
• Mindgard「Cursor 0day: When Full Disclosure Becomes the Only Protection Left」 https://mindgard.ai/blog/cursor-0day-when-full-disclosure-becomes-the-only-protection-left
• TechTimes「Cursor Patched Silent Repo-Poisoning Zero-Day With No Advisory, No CVE」 https://www.techtimes.com/articles/320797/20260717/cursor-patched-silent-repo-poisoning-zero-day-no-advisory-no-cve.htm
• innovatopia「GPT-5.6이 파일을 삭제, OpenAI는 『불의의 실수』라고 설명」 https://innovatopia.jp/ai/ai-news/113621/
• Anthropic「How we built Claude Code auto mode: a safer way to skip permissions」 https://www.anthropic.com/engineering/claude-code-auto-mode
• ryuka_lucas「D 드라이브 전멸 사건과, Claude Code 공식 가드레일(Guardrail)의 간과 17%」 https://zenn.dev/ryuka_lucas/articles/ai-agent-destructive-ops

Discussion