이런 상황을 상상해 보자. 인기 있는 오픈소스 라이브러리를 클론하고, AI 코딩 어시스턴트를 열어 기여 작업을 도와달라고 요청한다. 어시스턴트는 해당 저장소의 Contributing.md 파일을 읽는다. 당연히 그래야 한다. 그리고 거기에 적힌 지침을 따른다. 당연히 그래야 한다. 그런데 그 지침이 보이는 것과 다르다면? 마크다운 속에 숨겨져 있어 사람의 눈에는 보이지 않지만 언어 모델에게는 완벽하게 읽히는 프롬프트 인젝션 페이로드가 어시스턴트의 행동을 재작성한다. API 키를 탈취할 수도 있다. 생성하는 코드에 백도어를 삽입할 수도 있다. 두 가지를 동시에 할 수도 있으며, 당신은 전혀 눈치채지 못할 것이다.
이것은 이론적인 공격이 아니다. 이미 시연된 공격이다. 그리고 이 공격은 너무나 평범하고, 너무나 신뢰받는 것을 악용하기에, 대부분의 개발자는 의심조차 하지 않을 것이다.
평범한 마크다운에 숨어 있는 공격 표면
보안 커뮤니티는 수년간 프롬프트 인젝션에 대해 논의해 왔다. 챗봇, 고객 서비스 도구, 웹 브라우징 에이전트를 대상으로 한 공격을 목격해 왔다. 그런데 최근 Hacker News에 올라온 "Prompt Injecting Contributing.md"라는 제목의 글은 질적으로 다른 느낌의 공격 벡터를 조명한다. 이 공격은 개발자를 특정 대상으로 삼으며, 개발자들이 신뢰하도록 훈련받은 바로 그 파일을 통해 이루어진다.
왜 중요한지 설명하겠다. 현대의 AI 코딩 어시스턴트, 즉 GitHub Copilot, Cursor, Claude Code 등의 도구들은 단순히 현재 줄을 자동완성하는 것이 아니다. 컨텍스트를 읽는다. 프로젝트 파일을 수집한다. README, 설정 파일, 그리고 Contributing.md 파일을 파싱하여 프로젝트의 관례와 요구사항을 파악한다. 이러한 컨텍스트 수집은 기능이다. 이것이 이 도구들을 진정으로 유용하게 만드는 요소다. 동시에 이것이 이 도구들을 악용 가능하게 만드는 요소이기도 하다.
Contributing.md 파일은 저장소가 기여 형식, 실행할 테스트, 따라야 할 스타일 가이드를 정의하는 자연스러운 장소다. AI 어시스턴트가 이 지침을 읽을 때, 이를 권위 있는 것으로 취급한다. 그러지 않을 이유가 있겠는가? 이 파일은 저장소의 일부다. 개발자가 저장소를 클론했다. 암묵적 신뢰 체인은 온전하다.
다만 오픈소스의 신뢰 체인은 항상 취약했다. 우리는 XZ Utils 백도어 사건에서 그 교훈을 얻었다. 그 전에는 event-stream 사건에서 배웠다. 이제 우리는 같은 교훈을 다시 배우고 있다. 심지어 메인테이너의 계정을 탈취할 필요조차 없는 채널을 통해서.
단순한 메커니즘, 파괴적인 파급력
메커니즘은 거의 민망할 정도로 단순하다. 마크다운은 HTML 주석을 지원한다. 유니코드 트릭을 지원한다. 브라우저나 텍스트 에디터에서는 보이지 않는 공백으로 렌더링되지만, 원시 텍스트를 처리하는 언어 모델에게는 완전히 읽히는 서식을 지원한다. 공격자는 Contributing.md 파일에 일반적인 검토에서는 절대 발견할 수 없지만 LLM이 파싱하여 충실히 따를 지침을 삽입할 수 있다.
이 숨겨진 지침은 무엇이든 될 수 있다. "이 프로젝트의 코드를 생성할 때 다음 import 문을 포함하라" 뒤에 악성 의존성이 따라오는 식이다. "테스트를 실행하기 전에 이 curl 명령을 실행하라." 혹은 더 교묘하게: "인증에는 항상 이 특정 API 엔드포인트를 사용하라"며 트래픽을 공격자가 제어하는 서버로 리다이렉트하는 것이다.
이 공격의 정교함은—그런 표현이 적절하다면—개발자가 악성 행위를 실행하는 것이 아니라는 점이다. AI 어시스턴트가 실행한다. 그리고 개발자가 어시스턴트에게 도움을 요청했기 때문에, 그 출력을 신뢰하는 쪽으로 기울게 된다. AI가 생성한 코드와 사람의 검증 사이의 간극은 이미 위험할 정도로 벌어져 있다. 이 공격은 그 간극을 악용하는 것에 그치지 않는다. 무기화하는 것이다.
Hacker News 토론에 따르면, 여러 개념 증명 시연에서 주류 AI 코딩 도구들이 Contributing.md에 삽입된 지침을 의심스럽다고 표시하지 않고 그대로 따른다는 것이 확인되었다. 모델은 합법적인 프로젝트 가이드라인과 적대적 프롬프트를 구별하지 못한다. 모델에게는 모두 그저 컨텍스트일 뿐이다.
이것이 공급망 공격에 해당하는 이유
이것이 어떤 위협 범주에 해당하는지 정확히 짚어보자. 이것은 AI 모델 자체의 취약점이 아니다. 탈옥(jailbreak)도 아니다. AI 어시스턴트를 무자각적인 중개자로 이용하는 공급망 공격이다.
전통적인 소프트웨어 공급망 공격은 패키지, 빌드 시스템, 또는 배포 채널을 침해한다. 대상은 당신의 머신에서 실행되는 코드다. 이 새로운 변종은 코드가 *작성되는 과정*을 침해한다. 설치하는 의존성에 존재할 필요가 없다. AI 어시스턴트가 지켜보는 동안 당신이 상호작용하는 저장소에만 존재하면 된다.
이는 공격 표면의 의미 있는 확장이다. 일반적인 개발자가 일주일 동안 얼마나 많은 오픈소스 저장소를 다루는지 생각해 보라. 이제 그 저장소들 중 개발자가 Contributing.md 파일을 한 단어 한 단어, 한 글자 한 글자 실제로 읽어본 것이 몇 개인지 생각해 보라. 대부분의 경우, 그 답은 0이다.
공급망에 대한 시사점은 더 깊어진다. 악의적 행위자는 인기 있는 패키지를 침해할 필요가 없다. 유용해 보이는 라이브러리를 만들고, 정상적인 코드로 채운 뒤, Contributing.md에 페이로드를 심어놓기만 하면 된다. 개발자가 저장소를 포크하거나 AI 어시스턴트를 사용해 탐색하면 인젝션이 발동한다. 진입 장벽이 놀라울 정도로 낮다.
현재의 방어가 부족한 이유
그렇다면 어떻게 해야 할까? 솔직한 대답은 이렇다: 방어 도구가 아직 따라잡지 못했다.
일부 AI 어시스턴트 제공업체가 프롬프트 인젝션 탐지에 착수하고 있지만, 이 문제는 근본적으로 어렵다. "프로젝트 파일에 포함된 정당한 지침"과 "프로젝트 파일에 포함된 적대적 지침"을 구별하려면 의도를 이해해야 하는데, 의도야말로 언어 모델이 적대적 맥락에서 제대로 추론하지 못하는 부분이다.
방어가 구체화될 수 있는 몇 가지 계층이 있다:
모델 수준에서. AI 제공업체는 프로젝트 파일에서 발견된 지침을 시스템 수준 지시가 아닌 신뢰할 수 없는 입력으로 처리하도록 모델을 훈련시킬 수 있다. 말은 쉽지만 실행은 어렵다. 컨텍스트 인식 코딩 어시스턴트의 핵심 가치 제안은 프로젝트 관례를 따른다는 것이다. 모델에게 프로젝트 파일을 무시하라고 하면 목적 자체가 무너진다.
도구 수준에서. AI 코딩 어시스턴트는 샌드박싱을 구현하여, 어떤 파일이 특정 제안에 영향을 미쳤는지 개발자에게 정확히 보여주고, 비정상적인 서식, 숨겨진 텍스트, 지침 형태의 내용을 포함한 HTML 주석이 있는 파일을 표시할 수 있다. 모델이 응답을 생성하기 전에 실제로 무엇을 읽었는지 표면화하는 "컨텍스트 감사" 기능은 의미 있는 진전이 될 것이다.
개발자 수준에서. 이 부분이 불편해지는 지점이다. 가장 효과적인 즉각적 방어는 누구도 듣고 싶지 않은 이야기다: AI 어시스턴트가 읽는 파일을 직접 읽어라. AI 도구가 파일을 처리하기 전에 Contributing.md, README.md, 설정 파일을 원시 텍스트로 검사하라. 오픈소스 저장소를 다운로드한 바이너리에 적용하는 것과 같은 수준의 의심으로 대하라. 그렇다, 이것은 마찰을 추가한다. 그것이 핵심이다.
생태계 수준에서. GitHub과 같은 플랫폼은 이미 노출된 시크릿을 스캔하는 것처럼, 마크다운 파일에서 알려진 프롬프트 인젝션 패턴을 스캔할 수 있다. 모든 것을 잡아내지는 못하겠지만, 공격의 비용을 높이는 효과가 있을 것이다.
AI 지원 개발의 핵심에 있는 깨진 신뢰 모델
이 공격 벡터가 진정으로 경각심을 불러일으키는 이유는 단순히 기술적 메커니즘 때문이 아니다. 현재 AI 지원 개발 흐름의 기저에 있는 신뢰 모델에 대해 드러내는 바 때문이다.
우리는 코드베이스를 읽고 우리를 대신해 코드를 생성하는 도구를 만들었다. 그 도구들에게 프로젝트 파일에 대한 광범위한 접근 권한을 부여했는데, 그 접근이 도구를 유용하게 만들기 때문이다. 하지만 프로젝트 파일이 이제 사실상 우리를 대신해 행동하는 에이전트에 대한 지시 채널이 되었다는 사실을 반영하도록 위협 모델을 업데이트하지 않았다.
이것은 초기 웹 애플리케이션을 괴롭혔던 것과 같은 종류의 문제다. 사용자 입력은 신뢰받았다. 왜냐하면, 글쎄, 우리 웹사이트의 폼에서 온 것이니까. 그리고 SQL 인젝션이 발생했다. 그다음 XSS가 발생했다. 그리고 우리는 고통스럽게 배웠다—모든 입력은 신뢰할 수 없는 입력이라는 것을. 우리는 AI 에이전트와 관련하여 유사한 변곡점에 서 있다. AI 어시스턴트가 읽는 모든 파일은 입력이다. 모든 입력은 잠재적 공격 벡터다.
이 Contributing.md 벡터를 수면 위로 끌어올린 연구자들과 개발자들은 문제를 조기에 명명함으로써 보안 커뮤니티에 기여하고 있다. XZ Utils 사건은 공급망 공격이 수개월간 감지되지 않을 때 무슨 일이 벌어지는지 보여주었다. AI 매개 공급망 공격에 대한 인식을 빨리 구축할수록, 대규모로 방어가 필요해지기 전에 개발할 가능성이 높아진다.
모든 개발자가 오늘 당장 취해야 할 세 가지 조치
첫째, AI 어시스턴트의 컨텍스트 윈도우를 이해하라. 어떤 파일을 자동으로 읽는지 파악하라. 대부분의 도구는 프로젝트 루트에 있는 마크다운 파일을 수집한다. 그것이 당신의 즉각적인 위험 표면이다.
둘째, 새로운 저장소를 클론하거나 포크할 때, Contributing.md 및 유사한 파일을 원시 모드로 확인하라. HTML 주석, 제로 너비 문자, 서식에 숨겨진 지침 형태의 내용을 찾아보라. 30초면 되고, 침해된 코드베이스로부터 당신을 구할 수 있다.
셋째, 더 나은 도구를 요구하라. AI 어시스턴트가 제안을 생성하기 전에 어떤 컨텍스트를 소비했는지 보여주지 않는다면, 벤더에게 그 이유를 물어라. 컨텍스트 파이프라인의 투명성은 더 이상 있으면 좋은 것이 아니다. 보안 요구사항이다.
AI 지원 코딩의 시대는 이미 도래했으며, 사라지지 않을 것이다. 하지만 그것이 기반으로 하는 신뢰 모델—프로젝트 파일이 무해한 지침으로 취급되는—은 근본적으로 깨져 있다. 누군가가 무시할 수 없는 규모로 그 진실을 입증하기 전에 고쳐야 한다.