아이디재스터, 인공지능 시대의 새로운 취약점 카테고리

문가용 기자

Published: 21:56, 09 Dec 2025 (Updated: 14:39, 14 Jan 2026)

💡

Editor's Pick
- 거의 모든 AI IDE에 공통적으로 나타나는 해킹 경로
- 단일 취약점 아니라, 새로운 취약점 카테고리
- 이 카테고리에 포함된 취약점 30개 넘어

인공지능과 관련된 새로운 유형의 취약점이 발견됐다. 취약점의 카테고리 하나가 새롭게 만들어진 것으로, 단일 CVE보다 그 영향력이 지대하다고 한다. 이 카테고리에는 아이디재스터(IDEaster)라는 이름이 붙었다. CVE로 따지자면 총 24개의 취약점이 여기에 해당된다고 하는데, 이는 초기 연구에서만 나온 성과이므로 앞으로 더 많은 CVE들이 발굴될 가능성이 농후하다. 실제로 아직 CVE 번호가 할당되지 않은 아이디재스터 취약점은 이미 6개가 더 있다고 한다.

정확히 어떤 공격을 가능케 하는가?

아이디재스터는 12월 6일 아리 마주크(Ari Marzouk)라는 이름으로 활동하는 보안 연구원이 자신의 블로그를 통해 개별적으로 발표함으로써 세상에 알려졌다. 여러 개의 취약점을 한데 묶은 ‘취약점 카테고리’이므로 익스플로잇 성공 시 다양한 공격 가능성이 열리게 된다. 마주크는 “단순 정보 유출만이 아니라 피해자 컴퓨터에서 거의 모든 악성 행위를 할 수 있게 된다”고 경고했다. 여기서 ‘피해자’는 주로 개발자들이라고 덧붙이기도 했다.

아이디재스터 익스플로잇으로 나타날 수 있는 가장 위험한 결과는 원격 코드 실행 공격이라고 마주크는 밝혔다. “공격자는 개발자인 피해자의 컴퓨터에서 임의 코드를 실행하게도 됩니다. 이를 통해 백도어나 키로거, 랜섬웨어를 설치하는 것도 가능하게 됩니다. 개발자들이 흔히 사용하는 깃허브 계정을 훔칠 수도 있고요. 그러면서 개발자들의 프로젝트도 오염시킬 수 있게 됩니다. 프로젝트에 참여한 모든 이들은 물론 나중에 그 프로젝트를 사용하는 사람들까지도 위험에 처하게 되는 것이죠. 즉 횡적 이동만이 아니라 다운스트림 공격까지도 가능하게 되는 겁니다.”

이는 단일 CVE에서도 얼마든지 찾아낼 수 있는 위험으로 보일 수도 있다. 마주크는 그렇지 않다고 설명한다. “기존 CVE들 중에서도 비슷한 효과를 내는 게 있습니다. 하지만 그런 것들은 단일 애플리케이션에만 영향을 주죠. 그 CVE가 발견된 애플리케이션 사용자들만 위험해진다는 것이었습니다. 하지만 아이디재스터는 모든 인공지능 기반 개발 환경과 코딩 어시스턴트에 영향을 줍니다. 즉 적게 잡아도 수백만 명이 영향을 받는다고 할 수 있습니다.”

무엇이 아이디재스터를 이렇게 위험하게 만드는가?

이 시점에서 ‘아이디재스터’라는 이름을 살펴볼 필요가 있다. 영어로 쓰면 IDEsaster인데, 제일 처음 눈에 띄는 건 IDE다. IDE는 Integrated Development Environment의 준말로, ‘통합 개발 환경’이라는 뜻을 가지고 있다. 소프트웨어 개발에 필요한 도구를 개발자들이 편리하게 쓸 수 있도록 해주는 하나의 개발 플랫폼이라 할 수 있다. 비주얼 스튜디오 코드(Visual Studio Code)라든가, 젯브레인(JetBrains), 엑스코드(Xcode) 등이 좋은 사례다.

IDE만으로도 개발이 한층 편해졌는데, 여기에 인공지능마저 가미됐다. 그것이 인공지능 통합 개발 환경 혹은 AI IDE다. 인공지능 에이전트가 IDE 내부에서 마치 개발자인 것처럼 활동하고 각종 작업을 수행하는 게 바로 이 AI IDE의 기본 특징이다. 여기서 ‘각종 작업’이란, 파일 읽기와 쓰기, 파일 수정, 폴더 트리 전체 열람, 설정 파일 편집, 셸 및 스크립트 명령 실행, 외부 자원 접속 및 다운로드 등이 포함된다. 개발자가 개발을 위해 해야 하는 행동 모두를 인공지능이 다 할 수 있다고 볼 수 있다. 그 말은, 개발자와 동일한 권한을 기계가 갖게 된다는 뜻이다.

그렇기 때문에 AI IDE는 개발 도구 이상의 것이다. 오히려 ‘준 개발자’에 더 가까운 존재라고 할 수 있다. 개발자나 다름 없는 이 인공지능 에이전트가 실수를 저지르거나 오류를 일으키게 되면, 워낙 가지고 있는 권한이 높았기에 ‘재앙(disaster)’과 같은 상황이 초래될 수 있다(말단 직원이 치는 사고와, 회사 대표가 치는 사고의 스케일은 다를 때가 많다는 것을 상상해보라). 그래서 아이디재스터(IDE+disaster = IDEsaster)라는 이름이 나온 것이다.

이 분야에서 시장을 선도하고 있는 AI IDE 제품 중 10개 이상이 아이디재스터의 영향을 받고 있는 것으로 나타나기도 했다. “깃허브 코파일럿(GitHub Copilot), 커서(Cursor), 윈드서프(Windsurf), 키로데브(Kiro.dev), 제드데프(Zed.dev), 루코드(Roo Code), 주니(Junie), 클라인(Cline), 제미나이CLI(Gemini CLI), 클로드코드(Claude Code) 등이 여기에 해당합니다. 인공지능이 코딩을 지원해주는 플랫폼들이고, 전부 아이디재스터를 내포하고 있습니다.” 마주크의 주장이다.

💡

여기서 잠깐!
‘인공지능이 너무 높은 자율성과 권한을 가지고 있기 때문에 위험할 수 있다’는 내용의 경고는 어제 ‘에이전틱 브라우저’에 대한 연구 결과를 통해 나오기도 했었다. 가트너가 발표한 것으로, ‘요즘 출시되는 에이전틱 브라우저들은 인공지능 에이전트에 지나치게 높은 권한을 주도록 설계돼 있어, 아직 기업 환경에서 사용하기에 위험하다’고 한다. 해당 내용은 본지 기사를 통해 상세 열람이 가능하다.

왜 이런 문제가 생긴 것일까?

아이디재스터는 사실 예견된 문제였다고도 할 수 있다. IDE라는 것이 애초에 인공지능을 염두에 두고 만들어진 게 아니기 때문이다. “인공지능이 개발자들의 업무 방식을 이렇게까지 변혁시키리라고 아무도 상상할 수 없을 때 IDE라는 게 세상에 나왔습니다. IDE 제공 기업들이 인공지능의 출현은 물론, 그 인공지능이 개발자의 역할을 수행할 거라는 것을 미리 예상할 방도가 없었지요. 그런데 거기에 억지로 인공지능 구성 요소를 탑재시키니 없던 문제가 생겨날 수밖에 없었던 것입니다.”

기술 발전을 예측할 수 없기 때문에 생겨난 보안 문제들은 이미 여럿 존재한다. 예를 들어 공장이나 발전소에서 사용되는 오래된 기계들의 경우, 인터넷이라는 게 세상을 지배하게 될 것을 그 누구도 상상하지 못하던 시절에 만들어진 게 많다. 그런 기계들을 작동하거나 관리하려면 누군가 반드시 현장에서 일을 진행해야 했다. 인터넷을 통한 원격 제어 같은 개념은 한참 뒤에 등장했다. 태생적으로 원격 제어가 되지 않는 기계들인데, 거기에 억지로 원격 관리 기술을 탑재시키면서 관리 업무가 다소 편해지긴 했지만, 그 기계들은 중대한 보안 구멍이자 공격 통로가 되어버렸다.

각종 사물인터넷 장비들도 비슷한 사례라고 볼 수 있다. 원래는 인터넷 연결이나 원격 제어라는 개념을 염두에 두지 않고 만들어진 기존 장비들(예 : 세탁기, 냉장고, TV 등)에 인터넷 연결성을 접목시킴으로써 새로운 기능을 구현하기도 했지만, 동시에 새로운 공격 통로마저 만드는 결과를 낳았으니 말이다. 기존 설계상 없던 개념을 뒤늦게 탑재시켰을 때 ‘보안 취약점’이 부작용으로서 생성되는 건 흔히 있는 일이다. IDE도 같은 맥락의 일이 일어났다고 할 수 있다.

실제 공격 시나리오

아이디재스터는 어떤 식으로 익스플로잇 될까? 이미 여러 개의 공격 시나리오가 존재한다. 마주크의 설명에 따르면 “현존하는 대다수 AI IDE에는 프로젝트 구조 분석을 위한 제이슨 스키마(JSON Schema) 기능이 존재한다”고 한다. “구조 분석을 위해 제이슨 스키마는 외부에서 일부 자원을 불러와 참조하기도 하는데, 안전성 검증 단계를 거치지 않을 때가 많습니다. 즉 악성 스키마를 활용하면 프로젝트 내부의 민감 정보를 외부로 전송할 수 있게 된다는 겁니다.”

이런 공격을 순서대로 정리하면 다음과 같다.
1) 공격자가 악성 스키마를 외부에 호스팅한다.
2) 이 사실을 모르는 개발자가 AI IDE를 통해 제이슨 스키마 기능을 실행해 악성 스키마를 가져온다.
3) AI IDE는 자동으로 이 악성 스키마를 분석하는데, 이 과정에서 악성 스키마 속에 숨겨진 악성 명령이 실행된다.
4) 프로젝트 내에 보관된 API 키나 내부 코드, 비공개 모델 프롬프트 등 민감 정보가 유출될 수 있다.

또 다른 사례로는 인공지능 에이전트가 IDE 설정을 임의로 수정할 수 있다는 점을 악용한 것이 있다. “IDE 전체 환경에 영향을 미치는 내용을 수정함으로써 실행파일 경로나 그 외 로컬 자원 경로를 공격자가 원하는 대로 지정할 수 있게 됩니다. 공격자가 어떤 파일을 그 경로에 지정했느냐에 따라 원격 코드 실행 공격으로까지 발전할 수 있습니다. 개발자 컴퓨터를 랜섬웨어로 마비시킬 수도 있고요.”

이런 유형의 공격을 순서대로 정리하면 다음과 같다.
1) 악성 페이로드를 실행파일 형태로 만들어 특정 경로에 삽입한다.
2) 에이전트가 IDE 설정을 바꾸도록 함으로써 해당 실행파일이 실행되도록 만든다.
3) 이런 사실을 모르는 개발자가 IDE를 통해 PHP 파일을 열거나 검사하면 IDE가 바뀐 설정에 따라 악성 파일을 불러와 실행하게 된다.
4) 예를 들어 VS코드(VS Code) 환경에서라면 .vscode/settings.json이나 php.validate.executablePath와 같은 설정을 건드리면 되고, 젯브레인 환경에서라면 .idea/workspace.xml의 깃 설정을 만지면 된다.

위 공격 시나리오들에는 이상한 점이 하나 있다. 다양한 인공지능 해킹 및 탈옥 기법을 접해본 사람이라면 눈치챘겠지만, ‘프롬프트 주입 공격’이라는 단계가 빠져 있다는 것이다. 이것이 아이디재스터의 핵심이라고 마주크는 강조한다. “기존 LLM 공격 기법은 ‘프롬프트를 교묘히 작성해 인공지능을 속인다’는 게 기본 골자였습니다. 즉 인공지능이 속아넘어갈 정도의 프롬프트를 공격자가 고안하거나 만들어내야 한다는 게 나름의 진입장벽이었던 것입니다. 아이디재스터는 개발 환경의 기본 기능과 도구들 자체를 공격 통로로 삼는 것이므로, 그러한 진입장벽을 크게 낮춥니다.”

마주크 曰, “Secure for AI”

시장에 나와 있는 거의 모든 AI IDE에 공통적으로 나타나는 문제라고 해서 당장 내일부터 개발자들에게 AI IDE를 쓰지 말라고 강요할 수는 없다. 마주크는 블로그를 통해 몇 가지 안전 대책을 제안했다. “IDE는 인공지능과 궁합이 좋지 않을 수밖에 없는 태생적 한계를 가지고 있습니다. 그래서 AI IDE가 단시간 내에 안전한 환경으로 바뀌지는 않을 겁니다. 그렇기에 사용자들이 직접 안전을 도모해야 합니다.”

그가 제안한 대책들은 다음과 같다.
1) 신뢰할 수 있는 프로젝트와 파일에서만 AI IDE를 사용한다.
2) 신뢰할 수 있는 MCP 서버만 연결하고, 연결 후에도 변경 여부와 내역을 지속적으로 모니터링 한다. MCP가 아이디재스터 익스플로잇 공격을 더 쉽게 만들기 때문이다.
3) URL을 통한 외부 자원 열람 및 참조 시, 숨겨진 명령이 있는지 수동으로 검토하는 작업부터 한다.
4) 인간 승인 절차를 활성화시킨다.

AI IDE를 적극 활용하는 개발자들을 위해서도 마주크는 조언을 남겼다. “가장 중요한 건 개발 환경 내 도구들에 최소한의 권한만을 부여한다는 겁니다. 예를 들어 read_file의 경우 작업 공간에서만 허용하고, dot 파일이나 설정 파일은 차단하도록 설정합니다. 또 write_file은 src/ 내에서만 허용하고 dot-file 수정은 인간 승인을 거쳐야만 할 수 있게 하고요.” 그 외에 샌드박싱과 IDE와 연결된 도메인 화이트리스팅, 에이전트를 대상으로 한 정기적 보안 실험도 제안됐다.

하지만 이 모든 건 ‘단기 대책’이다. 마주크는 인공지능 시대를 위한 새로운 보안 개념이 필요하다며 “Secure for AI”를 주장하기도 했다. 사물인터넷에 연결성 기능이 통합되면서 보안 문제가 불거지고, 그에 따라 ‘설계 단계에서부터 보안(Security by Design)’이 주창된 것처럼, 앞으로 인공지능이 각종 도구나 환경, 기술들에 접목될 것이 뻔한 상황에서 새로운 기술이나 제품을 기획할 때부터 인공지능의 결합을 염두에 두고 해야 한다는 것이 Secure for AI다. 인공지능 시대를 위한 Security by Design이라고도 볼 수 있다.

마주크가 제안한 Secure for AI의 원칙[자료 : 마주크 블로그]

“인공지능이 들어가면 새로운 입력 경로가 생기고, 새로운 자동화 능력이 생기며, 새로운 내부 기능 간 연결 고리가 만들어져 새로운 권한이 새로운 요소들에 부여됩니다. 이 모든 새로운 것들이 공격 경로가 될 수 있으며, 따라서 우리는 공격 경로가 폭발적으로 증가하기 직전의 시기에 도달했다고 할 수 있습니다. 이를 막으려면 앞으로 개발되는 모든 것들을 기획부터 되돌아봐야 합니다. 그것이 장기 보안 대책입니다.”🆃🆃🅔

by 문가용 기자(anotherphase@thetechedge.ai