AI는 코드다, 프롬프트만으론 안전해지지 않는다

jqwik 사건이 보여준 불편한 진실

The Register 보도는 Java 속성 기반 테스트 도구 jqwik을 둘러싼 논란을 다뤘다. jqwik 저자는 AI 코딩 에이전트가 자신의 프로젝트를 사용하지 않기를 원했고, 프로젝트 문서와 릴리스 노트에 이를 명시했다. 더 나아가 도구 출력에 AI 에이전트가 읽을 수 있는 지시문을 넣었고, 일부 에이전트 워크플로가 이를 실제 명령처럼 받아들인 것으로 알려졌다.

이 사건을 장난이나 라이선스 논쟁으로만 보면 핵심을 놓친다. 코딩 에이전트는 README, 로그, 테스트 출력, 코드 주석, 이슈 본문을 모두 작업 맥락으로 읽는다. 그 안에 악의적이거나 장난스러운 문장이 있으면 모델은 이를 사용자 명령, 시스템 힌트, 정책 경고와 섞어 해석한다. ChatGPT Sheets 유출, 사무용 AI의 보안 경고가 사무 문서의 주입 위험을 보여줬다면, jqwik 논란은 개발 도구 출력도 공격면이라는 사실을 드러낸다.

프롬프트는 보안 경계가 아니다

The Register는 같은 글에서 Shai-Hulud 계열 공급망 공격과 LLM 스캐너 교란 사례도 언급했다. 보안 업체 Socket은 악성 패키지 분석에서 대형 주석이 LLM 기반 스캐너의 거절 반응을 유도할 수 있다고 설명해 왔다. 코드 주석은 런타임에는 실행되지 않지만, AI 분석기에는 실행 계획처럼 작동할 수 있다. 이것이 에이전트 시대의 새로운 공급망 표면이다.

OWASP Top 10 for LLM Applications는 프롬프트 인젝션과 과도한 에이전시를 주요 위험으로 다룬다. 코딩 에이전트는 여기에 파일 시스템, 패키지 매니저, CI 토큰, 배포 권한까지 붙는다. 따라서 "이 지시를 무시하라"는 프롬프트만으로는 부족하다.

개발팀은 에이전트를 사용자 계정처럼 다뤄야 한다

한국 개발 조직도 Cursor, Claude Code, Copilot, 사내 에이전트로 테스트 작성과 리팩터링을 자동화하고 있다. 처음에는 편하다. 그러나 에이전트가 npm 패키지를 설치하고, 테스트를 실행하고, 실패 로그를 읽고, 코드를 고치는 순간 권한 모델이 필요하다. TDD 스킬, 코딩 에이전트 검증의 기본 단위는 검증 루프를 강조했지만, 이제는 그 검증 루프 자체도 공격받을 수 있다.

가장 현실적인 조치는 단순하다. 에이전트가 읽은 외부 텍스트와 사용자가 준 지시를 분리하고, 파일 삭제와 네트워크 호출, 패키지 배포 같은 행위는 별도 승인으로 묶어야 한다. 테스트 로그는 모델에게 "명령"이 아니라 "데이터"로 전달되어야 한다. Model Context Protocol 같은 표준도 유용하지만, 도구 연결이 많아질수록 권한 범위가 더 중요해진다.

공급망 보안의 기준이 바뀐다

기존 공급망 보안은 악성 코드 실행, 취약한 의존성, 토큰 탈취를 중심으로 돌아갔다. 에이전트 시대에는 여기에 "모델이 읽는 텍스트"가 더해진다. 패키지의 postinstall 스크립트가 위험하듯, README와 로그의 지시문도 위험해진다. 물론 둘의 위험 수준은 다르다. 하지만 코딩 에이전트가 텍스트를 바탕으로 실제 명령을 실행한다면 텍스트도 통제 대상이다.

Pytorch Lightning Shai-Hulud 공급망 공격에서 보았듯 AI 개발 생태계는 패키지와 토큰이 촘촘히 연결되어 있다. 여기에 에이전트가 자동 수정과 배포까지 맡으면 사고 속도도 빨라진다. SLSA 공급망 프레임워크처럼 빌드 출처와 무결성을 확인하는 접근은 이제 에이전트 입력 추적까지 확장돼야 한다.

"AI는 코드"라는 말의 실무적 의미

AI를 사람처럼 설득하려는 습관은 위험하다. 코딩 에이전트는 동료가 아니라 확률적 판단을 하는 소프트웨어 시스템이다. 좋은 말투와 안전 문구가 있어도, 외부 입력과 내부 정책이 충돌하면 예측하기 어렵다. 따라서 안전은 말이 아니라 구조다. 샌드박스, 최소 권한, 변경 diff 검토, 테스트 격리, 비밀값 차단, 패키지 설치 승인, CI 분리 같은 오래된 보안 원칙이 다시 중요해진다.

Runtime Team, 샌드박스 코딩 에이전트의 운영 단위는 에이전트 실행 환경을 별도 운영 단위로 보자고 했다. jqwik와 Shai-Hulud 사례는 그 주장을 강화한다. 에이전트를 안전하게 쓰려면 더 똑똑한 프롬프트보다 더 좁은 권한이 먼저다.

자주 묻는 질문

Q1: jqwik 사건은 실제 악성코드인가요?

A: 논쟁적이다. 핵심은 법적 평가보다 AI 에이전트가 도구 출력의 지시문을 위험하게 해석할 수 있다는 점이다.

Q2: 프롬프트 인젝션은 웹앱 문제 아닌가요?

A: 아니다. README, 로그, 코드 주석, 이슈, 패키지 설명처럼 모델이 읽는 모든 텍스트가 입력 표면이 된다.

Q3: 코딩 에이전트 사용을 중단해야 하나요?

A: 그럴 필요는 없다. 다만 파일 삭제, 네트워크, 배포, 비밀값 접근은 최소 권한과 승인 절차로 제한해야 한다.

Q4: 한국 팀이 바로 할 수 있는 조치는 무엇인가요?

A: 에이전트 전용 샌드박스, 변경 diff 리뷰, 의존성 설치 승인, 로그를 데이터로 처리하는 규칙, 토큰 차단을 먼저 적용하면 된다.

Q5: 좋은 모델이면 이런 문제가 줄어드나요?

A: 일부 줄 수는 있지만 사라지지 않는다. 외부 텍스트와 권한이 연결되는 구조적 문제이기 때문에 시스템 설계가 필요하다.