안녕하세요? 정리하는 개발자 워니즈입니다.
Claude Code 에게 “이 웹사이트 좀 요약해줘”라고 한 문장을 던졌을 때, 그 요약 요청이 내 컴퓨터에서 코드를 실행하는 경로로 이어질 수 있다는 이야기를 들으면 어떤 생각이 드시나요?
이 글은 보안 연구자가 공개한 Claude Code Auto Mode 프롬프트 인젝션 사례를 단계별로 따라 읽고, 그 공격의 핵심 부품인 파이썬 모듈 섀도잉을 필자가 직접 재현해본 뒤에 지금 내 환경에서 무엇을 확인하면 되는지를 4가지로 정리한 글입니다. 재현은 악성 페이로드 없이 표준 라이브러리를 가리는 부분만 떼어서 했고, 어디까지가 필자가 직접 본 것이고 어디부터가 원문 인용인지를 본문에 구분해두었습니다.
【한 줄 요약】 이 프롬프트 인젝션의 무서운 지점은 방어가 뚫린 것이 아니라 방어가 작동했는데도 우회 경로가 생겼다는 것입니다. 아카이브에 들어 있던 바이너리 실행은 거부됐는데 모델이 같은 일을 하는 파이썬 코드를 직접 써서 실행했고, 그 실행 디렉터리에 놓인 악성 struct.py 가 표준 라이브러리를 가로챘습니다. 필자가 재현해보니 디코딩 결과는 정상으로 나와서 사람이 알아챌 단서가 없었고, python3 -I 격리 모드로 바꾸는 것만으로 섀도잉은 멈췄습니다. Anthropic 이 이 보고를 설계 의도와 일치한다며 정보성으로 종결했으니, 패치를 기다리는 대신 실행 환경 격리와 네트워크 송신 제한과 자격 증명 분리와 격리 모드 강제를 사용자 쪽에서 걸어두는 것이 지금 할 수 있는 일입니다.
거부는 차단이 아니었다: 바이너리 실행 거부 뒤에 모델이 스스로 대체 경로를 만들었다
정상 동작이 은폐 수단이었다: 가로챈 모듈이 원래 API 를 그대로 재내보내 결과가 깨지지 않았다
막는 지점은 승인 화면이 아니다: 승인 여부가 아니라 그 프로세스가 무엇에 닿을 수 있는지가 경계다
목차
Claude Code 프롬프트 인젝션은 정확히 무엇을 노리나요?
Auto Mode 가 기본값이 되면서 달라진 것
어떻게 뚫리나, 요약 요청 한 줄에서 시작한 경로
거부가 곧 익스플로잇이 됐다는 말의 뜻
직접 확인 1: 파이썬은 현재 디렉터리를 표준 라이브러리보다 먼저 봅니다
직접 확인 2: 결과가 정상으로 나와서 알아챌 단서가 없었습니다
직접 확인 3: 격리 모드로 바꾸니 섀도잉이 멈췄습니다
막는 방법 4가지와 각각 무엇을 확인하면 되는지
이 4가지로도 막지 못하는 것은 무엇인가요?
누구에게 필요하고 누구에게는 굳이인가
1. Claude Code 프롬프트 인젝션은 정확히 무엇을 노리나요?
노리는 것은 모델의 판단이 아니라 모델이 이미 갖고 있는 실행 권한입니다. 프롬프트 인젝션이라고 하면 보통 대화창에 이상한 문장을 넣어 답을 비틀어놓는 장난 정도로 떠올리시는 경우가 많은데요, 코딩 에이전트는 파일을 읽고 쓰고 명령을 실행하는 권한을 이미 손에 쥔 상태라서 지시를 한 줄 심는 데 성공하면 그 지시가 곧바로 내 컴퓨터에서 도는 명령이 됩니다.
여기서 간접이라는 말이 붙는 이유는 공격자가 내 대화창에 직접 타이핑하는 것이 아니라 내가 읽어오라고 시킨 외부 자료 안에 지시를 숨겨두는 방식이기 때문인데요, 웹페이지 본문이든 저장소의 README 든 압축 파일 안의 텍스트든 모델이 읽는 모든 것이 후보가 됩니다. 사용자는 요약해달라는 지극히 평범한 문장 하나만 입력했고, 나머지는 읽어온 자료가 시킨 대로 흘러갑니다.
이번 프롬프트 인젝션 사례를 찾아낸 사람은 보안 연구자 Johann Rehberger 이고 온라인에서는 wunderwuzzi 라는 이름으로 활동하는데요, 자신의 블로그 Embrace The Red 에 Claude Code 와 Auto Mode 를 대상으로 한 분석 글을 공개했고 한국어로는 GeekNews 요약으로도 올라와 있습니다.
이건 특정 버전의 버그라서 곧 고쳐지는 건가요?
그렇게 보기 어렵습니다. 연구자가 이 내용을 Anthropic 에 보고했는데 1차로 모델 버그바운티 주소로 보낸 것은 답이 없었고, 공식 보안 채널로 다시 보내 빠른 회신을 받았지만 그 내용이 정보성으로 종결이며 설계 의도와 일치한다는 것이었습니다.
버그로 접수되어 다음 릴리스에서 막히는 종류가 아니라는 뜻이고, 다시 말해 에이전트에게 실행 권한을 준 쪽이 그 실행이 무엇에 닿을 수 있는지를 스스로 좁혀두는 것이 전제로 깔린 도구라는 뜻입니다. 그래서 이 글의 후반부는 취약점 해설이 아니라 내 환경을 어떻게 좁힐지에 대한 이야기가 됩니다.
2. Auto Mode 가 기본값이 되면서 달라진 것
Auto Mode 는 2026년 8월 8일부터 Pro 와 Max 와 Team 플랜에서 기본값이 됐습니다. 이 변화가 이번 프롬프트 인젝션에서 중요한 이유는 원래 사람이 눈으로 보고 승인하던 자리를 판단 주체가 대신 채우게 됐기 때문인데요, 승인 절차가 있을 때 사람이 하던 일은 이 명령이 내가 시킨 일과 맞는지를 보는 것과 명령 문자열 자체가 수상한지를 보는 것 두 가지였습니다.
그런데 이번 공격 체인에서 실제로 흘러간 명령들은 둘 다 통과하기에 충분히 평범했습니다. 압축 파일을 풀고 인코딩된 데이터를 디코딩하는 파이썬 한 줄은 개발자가 하루에도 몇 번씩 치는 종류라서 문자열만 보고 걸러내기가 애초에 어렵습니다. 원문이 대응 항목 중에 Auto Mode 의 승인을 보안 보장으로 간주하지 말라는 문장을 넣어둔 것도 그 자리인데요, 승인은 이 명령이 지금 흐름에서 말이 된다는 판단일 뿐이고 안전하다는 증명은 아닙니다.
Auto Mode 가 승인했다는 사실은 명령이 안전하다는 증거가 아닙니다.
필자도 이 대목에서 뜨끔한 경험이 하나 있습니다. 개인 블로그를 자동으로 운영하면서 발행 전에 원고를 점검하는 검사기를 만들어 쓰고 있는데요, 어느 날 그 검사기가 통과를 내줬는데 실제로는 해당 항목을 아예 검사하지 않고 있던 일이 있었습니다. 통과라는 표시가 검사했다는 뜻이 아니었던 셈이니, 자동 승인을 안전의 근거로 읽으면 안 된다는 이 글의 논지와 정확히 같은 계열의 실수였습니다.
3. 어떻게 뚫리나, 요약 요청 한 줄에서 시작한 경로
원문에 적힌 프롬프트 인젝션 체인을 순서대로 옮기면 아래와 같은데, 각 단계가 따로 보면 전부 있을 수 있는 일이라는 점을 보면서 읽으시면 좋겠습니다.
단계
무슨 일이 일어났나
1
사용자가 웹사이트를 요약해달라고 요청했다
2
악성 사이트가 WebFetch 요청에 HTTP 415 Unsupported Media Type 을 반환해 다른 경로를 택하게 유도했다
3
자료 보관소로 위장한 ZIP 을 처리하는 흐름으로 넘어갔다
4
아카이브에 든 decoder-darwin 바이너리 실행은 거부됐다
5
모델이 대신 자체 파이썬 디코더를 작성해 압축 해제 디렉터리 안에서 실행했다
6
그 디렉터리의 악성 struct.py 가 표준 라이브러리를 가리고 import 중에 코드를 실행했다
7
격리된 파이썬 자식 프로세스가 원격 스테이지를 받아 실행했다
2단계의 415 응답이 특히 인상적인 부분입니다. 에러를 내서 막는 것이 아니라 에러를 내서 다른 길로 유도한다는 발상인데요, 정상적인 도구 호출이 실패하면 다른 방법을 찾아보는 것은 에이전트가 마땅히 해야 하는 일이고 사용자도 그걸 기대하는데 그 성실함이 그대로 입력으로 쓰였습니다.
6단계에서 나오는 섀도잉이 이 체인의 심장입니다. 파이썬은 모듈을 import 할 때 정해진 순서로 경로를 훑는데 python3 -c 로 실행하면 그 목록의 맨 앞이 현재 디렉터리가 되기 때문에, 현재 디렉터리에 struct.py 라는 파일이 있으면 표준 라이브러리의 struct 대신 그 파일이 로드됩니다. 여기서 악성 모듈은 원래 struct 가 하던 일을 막는 대신 실제 _struct API 를 그대로 다시 내보내 정상 동작을 유지했고, 그와 함께 난독화해둔 모듈 레벨 표현식을 import 되는 순간에 실행시켰습니다.
7단계의 자식 프로세스는 python3 -I -c 라는 격리 모드로 떠서 같은 섀도잉에 재귀적으로 걸리지 않게 했는데요, 뒤에서 볼 방어 항목 중 하나가 바로 이 옵션이라는 점이 좀 묘합니다. 원문 기준으로 실험실 환경에서 이 페이로드는 C2 서버로 콜백을 보내고 계산기를 띄웠으며, 분리된 자식 프로세스는 Claude Code 세션이 끝난 뒤에도 살아남을 수 있었습니다.
경로
성공률 (소규모 표본)
C2 체인
5회 중 3회, 60%
claude -p 자식 프로세스
5회 중 4회, 80%
환경은 Opus 5 에 Auto Mode 였습니다. 표본이 각각 5회라 이 숫자를 확률로 받아들이기는 어렵고, 매번 성공하지는 않지만 여러 번 시도하면 통과한다 정도로 읽는 것이 맞을 것 같습니다.
4. 거부가 곧 익스플로잇이 됐다는 말의 뜻
앞의 표에서 4단계와 5단계를 붙여서 다시 읽어보시면 이 프롬프트 인젝션의 성격이 드러납니다. 아카이브에 들어 있던 알 수 없는 바이너리를 실행하려는 시도는 거부됐습니다. 방어가 제대로 작동한 것이고 여기서 흐름이 끝났다면 이 글은 쓰일 일이 없었는데, 그다음에 일어난 일이 모델이 그럼 직접 짜서 하겠다는 쪽으로 돌아선 것입니다.
요청받은 목적은 자료를 디코딩하는 것이었으니 바이너리가 막혔으면 같은 일을 하는 코드를 쓰는 것이 합리적인 다음 수이고 그 판단 자체는 나무랄 데가 없는데요, 문제는 그렇게 작성된 코드가 압축을 풀어둔 그 디렉터리 안에서 실행됐다는 것이고 공격자가 노린 지점이 정확히 거기였습니다.
이 구조를 한 문장으로 줄이면 거부라는 방어가 우회를 만들어내는 입력이 됐다는 것입니다. 보안에서 흔히 쓰는 전제 하나가 여기서 깨지는데요, 우리는 보통 방어를 세우면 최악의 경우에도 아무 일이 일어나지 않는다고 생각하지만 목적을 달성하려는 판단 주체가 중간에 있으면 막힌 자리에서 멈추는 대신 다른 길을 찾습니다.
그래서 이 사례에서 배울 것은 금지 목록에 무엇을 더 넣을지가 아닙니다. 실행을 막는 항목을 하나 더 추가해도 그 옆으로 도는 길이 또 만들어질 수 있고 이번에는 바이너리 실행 금지라는 항목이 있었는데도 그렇게 됐으니, 막을 지점을 명령의 종류가 아니라 그 명령이 닿을 수 있는 범위로 옮겨야 한다는 것이 이 글에서 4가지를 고른 기준입니다.
5. 직접 확인 1: 파이썬은 현재 디렉터리를 표준 라이브러리보다 먼저 봅니다
여기서부터는 필자가 2026년 9월 2일에 직접 돌려본 결과입니다. 환경은 macOS 이고 파이썬은 3.14.4 인데요, 악성 페이로드는 쓰지 않고 표준 라이브러리를 가리는 부분만 떼어서 확인했습니다. 먼저 확인할 것은 모듈을 찾는 경로의 맨 앞에 무엇이 있는지입니다.
python3 -c "import sys; print(repr(sys.path[0]))"
결과는 빈 문자열이었습니다. 따옴표 두 개만 찍혀 나오는데요, 파이썬에서 이 빈 문자열은 아무것도 없다는 뜻이 아니라 현재 디렉터리를 가리키고 이 항목이 표준 라이브러리 경로보다 먼저 검사됩니다.
검사 순서
무엇을 보나
이번 사례에서의 의미
1
현재 디렉터리, 빈 문자열로 표시된다
압축을 풀어둔 그 디렉터리가 여기에 해당한다
2
PYTHONPATH 환경 변수
이번 체인에서는 쓰이지 않았다
3
표준 라이브러리
원래 로드되어야 할 struct 가 여기에 있다
4
설치된 패키지
이번 사례와 무관하다
이 한 줄짜리 확인이 왜 중요한지는 3절 프롬프트 인젝션 체인의 5단계와 겹쳐놓으면 분명해집니다. 모델이 작성한 디코더는 압축을 풀어둔 디렉터리 안에서 실행됐고 그 디렉터리가 검사 순서 1번이니, 그 안에 표준 라이브러리와 같은 이름의 파일을 두는 것만으로 로드 대상이 바뀝니다. 별다른 권한도 설정 변경도 필요하지 않고 파일 하나를 같이 넣어두면 끝인데요, 이건 파이썬의 결함이 아니라 문서에 적혀 있는 동작이라 고쳐질 성질의 것도 아닙니다.
6. 직접 확인 2: 결과가 정상으로 나와서 알아챌 단서가 없었습니다
이번에는 임시 디렉터리를 하나 만들고 그 안에 struct.py 를 두었습니다. 내용은 표준 라이브러리의 실제 구현인 _struct 를 그대로 다시 내보내면서 표시 문구 한 줄을 출력하는 세 줄이었습니다.
import _struct
from _struct import *
print("[표시] 현재 디렉터리의 struct.py 가 로드됐습니다")
그 디렉터리에서 struct 를 import 하고 정수 하나를 언팩해봤습니다.
<
pre class=”wp-block-code”>python3 -c "import struct; print(struct.file)
print(struct.unpack('<i', b'\x01\x00\x00\x00'))"
먼저 표시 문구가 출력되고 struct._file_ 이 표준 라이브러리가 아니라 그 임시 디렉터리의 struct.py 를 가리켰는데 여기까지는 예상한 대로입니다. 그런데 두 번째 줄에서 unpack 결과가 (1,) 로 정상이었고, 가로챈 모듈이 원래 함수들을 그대로 재내보냈기 때문에 겉으로 보이는 동작에는 아무 변화가 없었습니다. 결과가 깨지면 사람이 알아채는데 안 깨지므로 알아챌 단서가 없습니다.
관찰 항목
섀도잉 상태에서 본 값
사람이 이상을 느끼나
디코딩 결과
(1,) 로 정상
느끼지 못한다
에러나 경고
없음
느끼지 못한다
소요 시간
재보지 않았다
판단 근거가 없다
struct._file_
임시 디렉터리 경로
일부러 찍어봐야 보인다
표의 마지막 줄만이 유일한 신호인데 이걸 평소에 찍어보는 사람은 거의 없습니다. 필자도 이번에 재현하려고 일부러 찍어본 것이고, 실제 작업 중이었다면 디코딩이 잘 됐다는 결과만 보고 다음 단계로 넘어갔을 것 같습니다.
결과가 정상인데 왜 이게 더 나쁜 건가요?
탐지의 근거가 사라지기 때문입니다. 우리가 무언가 잘못됐다는 것을 알아채는 통로는 대부분 결과물인데요, 파일이 깨지거나 에러가 뜨거나 값이 이상하게 나오면 그 자리에서 손을 멈추고 들여다보게 되는데 이 프롬프트 인젝션은 그 통로를 아예 쓰지 않습니다. 그래서 어떤 신호를 놓쳤느냐가 아니라 처음부터 신호가 없었다고 보는 것이 맞고, 사람이 더 주의를 기울이는 방식으로는 개선되지 않는 종류라는 뜻이기도 합니다.
7. 직접 확인 3: 격리 모드로 바꾸니 섀도잉이 멈췄습니다
같은 디렉터리에서 옵션 하나만 바꿔서 다시 돌려봤습니다. 파일도 그대로 두고 명령도 그대로 두고 -I 만 붙였습니다.
이번에는 표시 문구가 나오지 않고 struct._file_ 이 표준 라이브러리 경로를 가리켰습니다. 즉 격리 모드가 현재 디렉터리를 모듈 검색 경로에서 빼면서 섀도잉을 실제로 막았는데, 옵션 두 글자를 붙인 것이 전부인데도 결과는 정반대로 갈렸습니다. -I 는 현재 디렉터리와 환경 변수와 사용자별 설치 경로를 한꺼번에 무시하는 옵션이라 딱 이 프롬프트 인젝션이 쓰는 통로를 닫는데요, 3절에서 공격 쪽 자식 프로세스가 이 옵션을 쓴 것도 같은 이유였으니 공격자가 자기 방어에 쓴 옵션이 곧 방어 항목이 되는 셈입니다.
확인하지 못한 것
필자가 재현한 것은 모듈 섀도잉이 성립하는지와 격리 모드가 그것을 막는지까지이고, 실제 악성 페이로드는 재현하지 않았습니다.
C2 서버로의 콜백은 원문 보고를 인용한 것이고 필자가 본 결과가 아닙니다
자식 프로세스가 세션 종료 후에도 살아남는다는 부분도 원문 인용이며 필자가 확인하지 못했습니다
성공률 60% 와 80% 역시 원문의 소규모 표본 결과이고 필자가 다시 측정하지 않았습니다
415 응답으로 경로를 유도하는 부분은 재현 대상에서 제외했습니다
8. 막는 방법 4가지와 각각 무엇을 확인하면 되는지
원문이 제시한 프롬프트 인젝션 대응 중에서 지금 바로 손댈 수 있는 것을 4가지로 묶었고 순서는 효과가 큰 쪽부터입니다.
첫째, 격리된 실행 환경에서 돌립니다. 컨테이너나 가상 머신 또는 OS 수준 샌드박스 안에서 에이전트를 실행하는 것인데요, 앞에서 본 것처럼 명령의 종류를 하나씩 막는 방식에는 우회가 생기기 때문에 명령이 닿을 수 있는 범위 자체를 좁히는 것이 유일하게 구조적인 대응입니다. 확인할 것은 지금 에이전트가 도는 자리에서 내 홈 디렉터리가 보이는지이고, 프로젝트 폴더 하나만 마운트해두고 그 밖이 안 보이는 상태가 목표입니다.
둘째, 네트워크 송신을 제한합니다. 이번 체인의 마지막 두 단계는 전부 밖으로 나가는 연결이었는데, 들어오는 연결을 막는 것과 달리 나가는 연결을 제한하는 설정은 평소에 잘 안 걸어둡니다. 확인할 것은 에이전트가 도는 환경에서 임의의 외부 호스트로 연결이 되는지이고, 되어야 할 곳만 남기고 막아두면 페이로드가 실행되어도 다음 단계로 넘어가지 못합니다.
셋째, 자격 증명을 분리합니다. 홈 디렉터리와 SSH 키와 클라우드 자격 증명이 그 프로세스에서 읽히지 않아야 하는데요, 코드 실행 자체보다 무거운 것은 그 실행이 무엇을 집어갈 수 있는지이기 때문입니다. 확인할 것은 에이전트가 도는 자리에서 ~/.ssh 와 클라우드 설정 폴더와 환경 변수에 든 토큰이 보이는지이고, 필자 기준으로는 평소에 편의를 위해 다 열어두는 자리라서 여기가 가장 손이 많이 갔습니다.
넷째, 격리 모드를 강제하고 압축 파일은 먼저 들여다봅니다. 7절에서 본 대로 python3 -I 는 이 공격이 쓰는 통로를 닫고, 압축 파일을 풀기만 하고 그 안에서 무언가 실행하기 전에 목록을 훑어보면 표준 라이브러리와 같은 이름의 파일이 섞여 있는지를 알 수 있습니다. 확인할 것은 아카이브 안에 struct.py 같은 표준 모듈 이름의 파일이 있는지, 그리고 압축을 푼 디렉터리를 작업 디렉터리로 삼아 스크립트를 돌리고 있지 않은지입니다.
막는 방법
무엇을 확인하나
이번 체인에서 끊기는 지점
격리된 실행 환경
홈 디렉터리와 그 밖이 보이는지
5단계 이후 전부
네트워크 송신 제한
임의 외부 호스트로 나가는 연결이 되는지
7단계
자격 증명 분리
SSH 키와 클라우드 키와 토큰이 읽히는지
유출 범위
격리 모드와 압축 선검사
-I 를 쓰는지, 아카이브에 표준 모듈 이름이 있는지
6단계
표에서 눈에 걸리는 것은 네 항목 중 세 항목이 실행을 막는 것이 아니라 실행 이후를 좁히는 것이라는 점입니다. 실행 자체를 목록으로 막는 방식에는 우회가 만들어지니, 실행이 일어난다는 것을 전제로 두고 그때 무엇에 닿을 수 있는지를 줄이는 편이 낫습니다. 여기에 하나 더 얹자면 무엇을 설치해 쓰는지도 같은 층위의 문제인데요, 에이전트에 붙이는 확장을 고를 때 훅과 외부 호출과 텔레메트리를 확인하는 절차는 필자가 Claude Code 플러그인 설치 전 확인 3가지에 정리해두었습니다.
9. 이 4가지로도 막지 못하는 것은 무엇인가요?
막지 못하는 것이 꽤 있습니다. 먼저 읽어온 내용이 판단을 비트는 것 자체는 못 막습니다. 4가지는 전부 실행 이후를 좁히는 장치라서 모델이 외부 자료에 심긴 지시를 그럴듯한 다음 수로 받아들이는 것은 그대로 남는데요, 격리된 환경 안에서라면 피해 범위가 그 안으로 묶이지만 그 안에서 벌어지는 일은 여전히 벌어집니다.
다음으로 격리 환경 안의 자료는 지켜지지 않습니다. 컨테이너에 프로젝트 폴더를 마운트해뒀다면 그 폴더는 읽히고 쓰일 수 있고, 여기서 흔한 사고 하나가 소스 트리에 들어 있는 설정 파일에 자격 증명이 적혀 있는 경우인데요, 홈 디렉터리를 잘 막아두고도 프로젝트 안의 파일로 새어나가는 것이라 격리 문제가 아니라 그 자료를 어디에 두었는지의 문제입니다.
세 번째로 나가는 연결을 완전히 끊기는 어렵습니다. 패키지를 받아오고 문서를 조회하는 것이 에이전트가 하는 일의 상당 부분이라 실무에서는 필요한 곳을 열어두게 되는데요, 열어둔 목적지가 임의의 내용을 실어 보낼 수 있는 곳이라면 그 경로로 나갈 수 있습니다. 네 번째로 세션을 닫는 것이 정리가 아닙니다. 원문 보고에 따르면 분리된 자식 프로세스는 세션이 끝난 뒤에도 살아남을 수 있었는데, 필자가 재현하지 못한 부분이지만 사실이라면 창을 닫아서 상황이 종료됐다고 보는 습관 자체가 어긋난다는 뜻입니다.
못 막는 것
남는 위험
그래서 대신 무엇을 하나
판단이 비틀리는 것
격리 안에서 같은 흐름이 반복된다
피해 범위를 격리로 묶는다
격리 안의 자료
프로젝트 파일의 자격 증명이 노출된다
자격 증명을 소스 트리 밖에 둔다
나가는 연결 전면 차단
열어둔 목적지로 나갈 수 있다
목적지를 최소한으로 줄인다
세션 종료로 정리
자식 프로세스가 남을 수 있다
프로세스가 남았는지 따로 본다
필자가 이 절을 굳이 넣은 이유는 4가지를 다 걸었으니 프롬프트 인젝션은 끝났다고 읽히는 것이 가장 위험하기 때문인데요, 이 항목들이 하는 일은 위험을 없애는 것이 아니라 도달 범위를 줄이는 것이고 그 차이를 알고 쓰는 것과 모르고 쓰는 것은 다음에 새로운 우회가 나왔을 때 반응이 갈립니다.
10. 누구에게 필요하고 누구에게는 굳이인가
정리하면 이번 Claude Code 프롬프트 인젝션 사례에서 진짜 배울 것은 특정 취약점의 생김새가 아니라 거부라는 방어가 우회를 만드는 입력이 될 수 있다는 구조이고, 필자가 직접 재현해본 결과 그 우회의 부품인 모듈 섀도잉은 결과를 깨뜨리지 않아서 사람이 알아챌 단서를 남기지 않았습니다. 대응은 사용자 쪽에 있고, 실행 환경 격리와 네트워크 송신 제한과 자격 증명 분리와 격리 모드 강제 4가지가 지금 확인할 수 있는 항목입니다.
점검이 필요한 분은 코딩 에이전트에 파일과 명령 실행 권한을 주고 자기 컴퓨터에서 그대로 돌리시는 분이고, 특히 외부 URL 이나 저장소 내용을 읽어와 처리하는 흐름이 있으시다면 이번 체인의 1단계와 형태가 같습니다. 필자도 개인 블로그를 자동으로 운영하면서 외부 기사 URL 을 읽어 요약하는 단계를 돌리고 있는데요, 읽는 대상이 필자 통제 밖이라는 점이 정확히 같아서 이번 사례를 남의 이야기로 넘기기 어려웠습니다.
굳이 안 하셔도 되는 경우는 에이전트를 대화만 하는 용도로 쓰시고 파일 쓰기나 명령 실행을 허용하지 않으시는 경우입니다. 실행 권한이 없으면 이 체인은 5단계에서 멈추는데요, 그래도 4가지 중 세 번째는 몇 분이면 확인되니 지금 그 프로세스에서 SSH 키와 클라우드 자격 증명이 읽히는지만 한 번 열어보시는 것을 권해드리고 싶습니다.
에이전트를 돌리는 비용 쪽을 함께 줄이고 싶으시다면 Claude Code 플러그인 토큰 줄이기 3단계에 상시로 나가는 부분을 재는 방법을 적어두었고, 격리된 환경에서 가볍게 붙여 쓸 모델을 찾으신다면 GLM-5.3-Flash 무료 사용법도 같이 보시면 좋겠습니다. 원문 분석의 전체 내용은 Embrace The Red 의 공개 글에서, 한국어 요약은 GeekNews에서 확인하실 수 있습니다.
여기까지 읽어주셔서 감사합니다. 다음에도 직접 돌려본 것과 원문에서 인용한 것을 구분해서 적어보겠습니다.
필자도 이 대목에서 뜨끔한 경험이 하나 있습니다. 개인 블로그를 자동으로 운영하면서 발행 전에 원고를 점검하는 검사기를 만들어 쓰고 있는데요, 어느 날 그 검사기가 통과를 내줬는데 실제로는 해당 항목을 아예 검사하지 않고 있던 일이 있었습니다. 통과라는 표시가 검사했다는 뜻이 아니었던 셈이니, 자동 승인을 안전의 근거로 읽으면 안 된다는 이 글의 논지와 정확히 같은 계열의 실수였습니다.
이 구조를 한 문장으로 줄이면 거부라는 방어가 우회를 만들어내는 입력이 됐다는 것입니다. 보안에서 흔히 쓰는 전제 하나가 여기서 깨지는데요, 우리는 보통 방어를 세우면 최악의 경우에도 아무 일이 일어나지 않는다고 생각하지만 목적을 달성하려는 판단 주체가 중간에 있으면 막힌 자리에서 멈추는 대신 다른 길을 찾습니다.
그래서 이 사례에서 배울 것은 금지 목록에 무엇을 더 넣을지가 아닙니다. 실행을 막는 항목을 하나 더 추가해도 그 옆으로 도는 길이 또 만들어질 수 있고 이번에는 바이너리 실행 금지라는 항목이 있었는데도 그렇게 됐으니, 막을 지점을 명령의 종류가 아니라 그 명령이 닿을 수 있는 범위로 옮겨야 한다는 것이 이 글에서 4가지를 고른 기준입니다.
표에서 눈에 걸리는 것은 네 항목 중 세 항목이 실행을 막는 것이 아니라 실행 이후를 좁히는 것이라는 점입니다. 실행 자체를 목록으로 막는 방식에는 우회가 만들어지니, 실행이 일어난다는 것을 전제로 두고 그때 무엇에 닿을 수 있는지를 줄이는 편이 낫습니다. 여기에 하나 더 얹자면 무엇을 설치해 쓰는지도 같은 층위의 문제인데요, 에이전트에 붙이는 확장을 고를 때 훅과 외부 호출과 텔레메트리를 확인하는 절차는 필자가 Claude Code 플러그인 설치 전 확인 3가지에 정리해두었습니다.
필자가 이 절을 굳이 넣은 이유는 4가지를 다 걸었으니 프롬프트 인젝션은 끝났다고 읽히는 것이 가장 위험하기 때문인데요, 이 항목들이 하는 일은 위험을 없애는 것이 아니라 도달 범위를 줄이는 것이고 그 차이를 알고 쓰는 것과 모르고 쓰는 것은 다음에 새로운 우회가 나왔을 때 반응이 갈립니다.