ChatGPT 및 기타 LLM에서 "숨겨진 코드"를 제거하는 방법

대규모 언어 모델(LLM)이 점점 더 작동 코드를 생성하고 개발 파이프라인 및 에이전트 스택에 통합됨에 따라 다음과 같은 위험이 증가하고 있습니다. 숨겨진 or 악의있는 모델 출력에 내장되어 있거나, 웹 페이지나 타사 플러그인을 통해 삽입되었거나, 모델 학습 중에 도입된 지침은 해당 코드가 실행될 때 안전하지 않은 동작을 일으킬 수 있습니다.

개발자 커뮤니티에 유포된 사용자 보고서에 따르면 소프트웨어 개발자는 대략 다음과 같은 치명적인 데이터 손실을 경험했습니다. 800GB의 파일이 삭제되었습니다.,를 포함하여 CursorAI 애플리케이션 전체 — 다음으로부터의 도움으로 생성된 코드를 실행한 후 쌍둥이 자리 3 내부에서 작업하는 동안 커서AI IDE개발자들이 코드 생성을 위해 LLM에 점점 더 의존하게 되면서 검토되지 않거나 안전하지 않은 스크립트의 결과는 더욱 심각해지고 있습니다.

따라서 LLM에서 생성된 위험한 코드를 감지하고 제거하는 방법을 아는 것이 매우 중요합니다.

ChatGPT와 LLM의 맥락에서 "숨겨진 코드"란 무엇입니까?

사람들은 "숨겨진 코드"란 무엇을 의미할까요?

"숨겨진 코드"는 개발자가 LLM이 수집하거나 내보내는 텍스트(또는 파일) 내에 포함된 모든 내장된 명령어나 실행 가능한 콘텐츠를 설명하는 데 사용하는 포괄적인 용어입니다. 여기에는 다음이 포함됩니다.

프롬프트 스타일 지침 사용자 콘텐츠 내부에 내장됨(예: PDF에 숨겨진 "이전 지침 무시...").
보이지 않는 문자들 또는 토큰을 숨기거나 토큰화 가정을 깨는 데 사용되는 너비가 0인 공백입니다.
인코딩된 페이로드 (base64, URL 인코딩, 이미지나 문서 내부의 스테가노그래피 임베딩).
숨겨진 HTML/JS 또는 다운스트림 렌더러에서 해석될 수 있는 포맷된 콘텐츠에 포함된 스크립트 블록입니다.
메타데이터 또는 주석 (파일 주석, PDF의 숨겨진 레이어) 검색 시스템이나 모델에 지침을 제공합니다.
암묵적 행동 위험한 API를 사용하는 생성된 코드에서 발생하는 경우(예: eval, exec, subprocess, 또는 네트워크/시스템 호출) — 의도가 명백히 악의적이지 않더라도 마찬가지입니다.
즉시 주입되는 지침 공격자가 프롬프트나 컨텍스트를 조작했기 때문에 모델이 숨겨진 명령이나 백도어와 유사한 논리를 포함하는 코드를 생성하게 됩니다.

이러한 공격 벡터는 종종 다음과 같이 불립니다. 즉각적인 주사 or 간접적 즉각 주입 목표가 모델 동작을 변경하는 것일 때. 보안 커뮤니티는 이제 프롬프트 인젝션을 핵심 LLM 취약점으로 취급하고 있으며, OWASP는 이를 LLM 위험 범주로 공식화했습니다.

이것이 일반 맬웨어나 XSS와 어떻게 다릅니까?

차이점은 시맨틱 계층: 프롬프트 인젝션은 호스트 OS나 브라우저 렌더링 엔진이 아닌 모델의 명령어 수행 동작을 표적으로 삼습니다. 하지만 웹 렌더러에서 실행되는 숨겨진 HTML이나 스크립트는 여전히 실행 가능한 공격(XSS 유사)입니다. 따라서 의미 계층과 실행 계층 모두 방어해야 합니다. 업계 리더와 연구자들은 프롬프트 인젝션을 "최전선 보안 과제"라고 부르며, 지속적으로 완화 전략을 발표하고 있습니다.

LLM이 숨겨진 코드나 위험한 코드를 생성할 수 있는 이유는 무엇입니까?

모델 동작, 훈련 데이터 및 지침 컨텍스트

LLM은 주어진 맥락과 지시에 따라 그럴듯한 연속 동작을 생성하도록 훈련됩니다. 맥락에 적대적인 단서가 포함되어 있거나 사용자가 모델에 강력한 동작을 수행하는 코드를 요청하는 경우, 모델은 미묘하거나 능동적인 동작을 포함하는 코드를 출력할 수 있습니다.

LLM은 타당하지만 안전하지 않은 코드를 생성합니다.

LLM은 유해한 부작용이 있는 상황에서의 안전성보다는 유창성과 유용성에 최적화되어 있습니다. LLM은 간결한 rm -rf /path/to/dir or shutil.rmtree() "정리해 달라고" 요청했을 때 전화를 걸고, 답변이 자신감 넘치는 경우가 많기 때문에 사용자는 충분한 검토 없이 무단으로 복사할 수 있습니다. 이러한 "자신감에 대한 환각" 문제 때문에 겉보기에 무해해 보이는 요청이 위험해질 수 있습니다.

난독화 워크플로 자동화

위협 행위자들은 이제 LLM 호출을 연쇄적으로 연결하여 코드 난독화를 자동화하고 있습니다. 한 모델은 페이로드를 생성하고, 다른 모델은 시그니처 탐지를 피하기 위해 페이로드를 수정하는 식으로 진행됩니다. 2025년 업계 위협 보고서와 공급업체 분석에서는 이러한 "AI 지원 난독화"가 새로운 기술로 등장할 것이라고 보고하고 있습니다.

모델 출력 내부에 숨겨진 코드를 어떻게 감지할 수 있나요?

빠른 응급처치 체크리스트

보이지 않거나 비정상적인 유니코드를 검색합니다. (너비가 0인 조인어, 너비가 0인 공백, 바이트 순서 표시, 비 ASCII 동형문자).
정적 분석/AST 구문 분석 실행 강력한 API 사용을 식별하려면 (eval, exec, subprocess, os.system, 성찰적 호출).
인코딩된 페이로드를 찾으세요 (base64, 16진수 블롭, 반복되는 긴 문자열 또는 압축된 콘텐츠).
난독화 패턴을 확인하세요 (API 이름, 문자 산술을 구성하는 문자열 연결) chr() 쇠사슬).
의미 분석을 사용하세요 코드가 실제로 I/O, 네트워킹 또는 파일 시스템 변형을 수행하는지 확인합니다.

정적 패턴 감지(빠름, 첫 번째 줄)

언어 인식 파싱 및 린팅. 생성된 출력을 산문이 아닌 코드 블록으로 즉시 파싱합니다. 포매터와 린터(Black/Prettier, pylint, eslint)를 실행합니다. 린트 규칙은 다음 사용에 플래그를 지정해야 합니다. eval, exec, rm -rf, 원시 하위 프로세스 호출 또는 명령을 동적으로 구성하는 셸 파이프.
토큰 및 문자열 패턴 스캐너. 고위험 토큰과 패턴을 검색하세요: sudo, 절대 경로와 같은 /home/, C:\, rm -rf, shutil.rmtree, subprocess.Popen, 인라인 base64 블롭, 해석할 수 없는 긴 문자열, 인터프리터 컨텍스트를 전환하는 셰뱅.
비밀 스캐닝 및 출처 확인. 하드코딩된 자격 증명, 신뢰할 수 없는 레지스트리를 가리키는 URL 또는 임의의 소스에서 동적으로 패키지를 가져오는 코드를 감지합니다.

정적 분석은 많은 명백한 문제를 빠르게 포착하고 CI 게이트의 일부로 실행하는 데 비용이 저렴합니다.

의미론적 및 맥락적 감지(심층적)

의도 분석. 보조 모델이나 규칙 엔진을 사용하여 생성된 코드의 의도를 분류합니다. "읽기", "쓰기", "삭제", "네트워크", "설치" 중 어떤 용도인가요? 삭제/쓰기로 분류된 모든 항목은 에스컬레이션을 트리거해야 합니다.
데이터 흐름 분석. 검증되지 않았거나 사용자가 제공한 경로가 유해한 API에 접근할 수 있는지 확인하기 위해 코드를 분석합니다. 예를 들어, LLM 출력이나 원격 파일에서 파생된 변수가 나중에 셸 명령에 연결되는 경우 플래그를 지정합니다.
출처 상관관계. 대화, 시스템 프롬프트, 컨텍스트 페이지를 모두 기록해 두세요. 의심스러운 출력이 특정 외부 문서 또는 플러그인 호출과 연관되어 있는 경우, 프롬프트 인젝션 또는 오염된 컨텍스트를 나타낼 수 있습니다.

동적 및 행동 감지(가장 안정적)

모니터링을 통한 샌드박스 실행. 네트워크, 호스트 마운트 및 시스템 호출 필터링(seccomp)이 없는 엄격하게 제한된 임시 환경에서 생성된 코드를 실행합니다. 파일 시스템 활동, 시도된 네트워크 호출, 프로세스 생성 및 비정상적인 I/O를 모니터링합니다.
카나리아 테스트. 실제 데이터에서 실행하기 전에 센티넬 파일이 포함된 합성 디렉토리에 대해 코드를 실행하고 삭제나 덮어쓰기를 모니터링합니다.
행동적 휴리스틱. 부모 디렉터리를 탐색하는 루프, 깊이 검사가 없는 재귀적 작업, 여러 파일에 손상을 줄 수 있는 이름 바꾸기 패턴(예: 동일한 파일 이름을 반복해서 쓰는 것)을 찾아보세요.
동적 분석은 난독화되거나 지연되거나 런타임에만 트리거되는 페이로드를 감지하는 유일한 방법입니다.

LLM 출력을 실행하기 전에 숨겨진 코드를 제거하거나 무력화하려면 어떻게 해야 합니까?

방어적 제거 대 의미 변경

"숨겨진 코드 제거"에는 두 가지 목표가 있습니다.

위생 — 코드가 아니거나 의심스러운 콘텐츠(보이지 않는 유니코드, 너비가 0인 문자, 추가된 base64 페이로드)를 제거합니다. 이는 의도된 무해한 로직을 변경하지 않습니다.
중립화 — 외부 서비스를 실행하거나 호출하는 모든 항목에 대해 해당 호출을 비활성화하거나 검증될 때까지 아무 작업도 수행하지 않도록 설정합니다.

항상 선호합니다 중화 + 검토 맹목적인 삭제: 코드의 일부를 임의로 제거하면 손상되거나 예상치 못한 동작이 발생할 수 있습니다. 대신, 의심스러운 구문을 안전하게 실패하는 명시적이고 로깅된 스텁(예외 발생 또는 안전한 기본값 반환)으로 대체하세요.

1단계 - 생성된 코드를 신뢰할 수 없는 데이터로 처리

제거 및 강화 파이프라인을 거치지 않고 ChatGPT(또는 LLM)에서 직접 코드를 실행하지 마십시오. 해당 파이프라인은 정책으로 적용되어야 하며 CI/CD에서 자동화되어야 합니다.

2단계 - 코드 추출 및 표준화

텍스트를 정규화하고 너비가 0인 문자를 제거합니다.: U+200B, U+200C, U+200D, U+FEFF 및 기타 너비가 0인 코드 포인트/포맷 코드 포인트와 같은 문자를 제거합니다. 감사를 위해 제거된 내용을 기록합니다. 이 단계를 통해 시각적 은폐를 위해 사용되는 많은 "숨겨진" 인코딩이 제거됩니다.
모든 비코드 컨텍스트 제거: 내러티브, 숨겨진 주석 및 모든 HTML/마크다운 래퍼를 제거합니다. 언어 포매터(Black, Prettier)를 사용하여 코드를 표준 형식으로 변환하여 난독화된 공백이나 제어 문자가 정규화되도록 합니다.
이러한 구성으로 코드를 거부하거나 격리합니다.: 동적 eval, 원시 하위 프로세스 호출(os.system, subprocess.Popen), 실행으로 디코딩된 인라인 base64 블롭 또는 내장됨 #! 인터프리터 컨텍스트를 바꾸려는 지시어. 텍스트를 정규화하고 너비가 0인 문자를 제거합니다.
U+200B, U+200C, U+200D, U+FEFF 및 기타 너비가 0인 코드 포인트/포맷 코드 포인트와 같은 문자를 제거합니다. 감사를 위해 제거된 내용을 기록합니다. 이 단계를 통해 시각적 은폐를 위해 사용되는 많은 "숨겨진" 인코딩이 제거됩니다.

3단계 - AST로 구문 분석하고 위험한 노드를 교체합니다.

AST로 구문 분석된 코드를 사용하여 동적 실행을 호출하는 노드를 찾습니다(예: exec), 또는 프로그래밍 방식으로 함수 이름을 빌드합니다. 이러한 함수를 "안전하지 않은 동적 동작이 차단됨"을 나타내는 제어된 예외를 발생시키는 안전한 스텁으로 대체합니다. 검토를 위해 AST 지원 소스의 정제된 사본을 생성합니다. 보안 패턴 검사(사용자 환경에 맞는 사용자 지정 semgrep 규칙)를 실행합니다. 일치하는 항목이 발견되면 표시하고 무효화합니다.

4단계 - 정적 강화 및 재작성

자동 재작성: 위험한 호출을 안전한 래퍼로 대체하는 자동화된 살균기를 통해 코드를 전달합니다. 예: os.system() / subprocess 시간 초과 및 네트워크 차단을 시행하는 승인된 샌드박스 실행기를 사용합니다.
기능 게이팅: API 키, 토큰 또는 권한 있는 엔드포인트에 대한 호출을 수정하거나 제거하고, 로컬 테스트를 위해 모의 어댑터로 대체합니다. 실수로 비밀이나 URL이 포함되는 것을 방지합니다.
종속성 다시 작성: 블록 동적 pip / npm 코드로 생성된 설치. 레지스트리를 통해 종속성을 선언하고 승인해야 합니다.

5단계 - 공격적인 샌드박스 내부에서 실행

임시 컨테이너/microVM: 네트워크, 호스트 자격 증명, 파일 시스템 접근 권한이 없는 컨테이너/VM에서 코드를 실행합니다. gVisor, Firecracker 또는 전용 임시 실행 서비스와 같은 기술이 적합합니다. 코드가 I/O에 액세스해야 하는 경우 정책을 적용하는 프록시를 사용하세요.
시스템 호출 필터 및 seccomp: 허용되는 시스템 호출을 제한합니다. 임시 디렉터리 외부의 파일 쓰기는 차단해야 합니다.
자원/시간 제한: 논리적 폭탄조차 무한정 실행되지 않도록 CPU/메모리/시간 제한을 설정합니다.

샌드박스 실행과 모니터링을 통해 정적 검사에서 놓치는 페이로드를 발견하는 경우가 많습니다. 업계 지침과 최근 백서에서는 샌드박싱을 핵심 완화책으로 권장합니다.

파이프라인에는 어떤 자동화 도구와 규칙이 필요할까요?

권장되는 툴체인 구성 요소

유니코드 위생 모듈 (사용자 지정 또는 기존 라이브러리). 정규화된 문자를 기록해야 합니다.
파서 + AST 분석기 각 대상 언어(Python)에 대해 ast, typed-ast, JavaScript 파서, Java 파서).
정적 분석기 / SAST: Bandit(Python), Semgrep(다중 언어, 사용자 정의 가능), 보안 플러그인이 포함된 ESLint.
엔트로피와 디코더 휴리스틱: base64/hex/gzip을 감지하고 검사로 전달합니다.
샌드박스 런타임: 엄격한 seccomp/AppArmor 프로필이 있는 최소 컨테이너 또는 비활성화된 syscall이 있는 언어 수준 인터프리터.
정책 집행자: 허용된 모듈, 허용된 엔드포인트, 안전한 API 래퍼를 결정하는 구성 요소입니다.
감사 추적: 원본 출력, 정리된 출력, 차이점 및 결정을 기록하는 변경 불가능한 로그입니다.

semgrep 패턴 예시(개념적)

위험한 함수 사용을 표시하는 짧고 보수적인 규칙을 사용하세요. 예를 들면 다음과 같습니다.

플래그 eval, exec, Function 생성자(JS), 동적 가져오기 또는 문자열로 작성된 API 이름.
허용 목록 외부의 플래그 네트워크 호출(예: requests.get 알 수 없는 호스트로).
플래그는 민감한 경로에 기록됩니다(/etc, 시스템 폴더) 또는 프로세스 생성.

(이것을 조직별 구성 항목으로 유지하고 시간이 지남에 따라 강화합니다.)

실용적인 살균 스니펫(안전한 예)은 무엇입니까?

다음은 위험하지 않고 방어적인 예시입니다. 살균 및 감지 스니펫은 악용 지침이 아닙니다.

예: 너비가 0인 문자 제거(Python, 방어적)

import re
ZERO_WIDTH_RE = re.compile(r'')
def strip_zero_width(s: str) -> str:
    cleaned = ZERO_WIDTH_RE.sub('', s)
    return cleaned

이렇게 하면 공격자가 눈에 보이는 텍스트에 코드를 숨기는 데 자주 사용하는 문자가 제거됩니다. 제거된 내용은 항상 기록하고, 제거를 감사 추적의 일부로 처리하세요.

예: AST 구문 분석 및 검사(Python, 개념적)

import ast

def has_dynamic_exec(source: str) -> bool:
    tree = ast.parse(source)
    for node in ast.walk(tree):
        if isinstance(node, ast.Call):
            if getattr(node.func, 'id', '') in ('eval', 'exec',):
                return True
        if isinstance(node, ast.Attribute):
            if getattr(node, 'attr', '') in ('popen', 'system'):
                return True
    return False

If has_dynamic_exec True를 반환하면 코드를 실행하지 마세요. 대신 동적 노드를 안전한 스텁으로 바꾸고 검토를 요구하세요.

참고: 이 예시는 방어적인 성격을 지닙니다. 파이프라인에서 로깅, 감사 또는 인적 검토 기능을 제거하지 마세요.

마무리 생각: LLM 출력을 항상 신뢰할 수 없는 코드처럼 취급하세요.

LM은 강력한 생산성 도구입니다. 세련된 코드를 생성하고, 초안 작성 속도를 높이고, 일상적인 작업을 자동화할 수 있습니다. 하지만 실행 과정에서 보안 규칙이 변경됩니다. **모델 출력은 신뢰할 수 없는 아티팩트로 처리되어야 합니다.**지난 18~30개월 동안 신속한 주입, 백도어 조사, 실제 취약점 공개를 통해 분명한 사실이 드러났습니다. 위험 영역이 확대되었고 앞으로도 계속 진화할 것입니다.

파싱, 정적 분석, 샌드박스 동적 테스트, 거버넌스, 그리고 지속적인 레드팀 구성을 결합한 실용적인 방어책은 대부분의 공격을 차단할 수 있습니다. 하지만 팀은 최소 권한, 출처, 그리고 LLM 결과물에 대한 검증이 필요하다는 것을 전제로 하는 문화 등 조직적 통제에도 투자해야 합니다. 업계는 이러한 패턴을 더욱 쉽게 만드는 도구와 프레임워크를 구축하고 있으며, 위 체크리스트를 채택하면 숨겨진 페이로드가 유출될 가능성을 줄일 수 있습니다.

개발자는 다음과 같은 최신 LLM API에 액세스할 수 있습니다. 클로드 소네 4.5 API 및 Gemini 3 Pro 미리보기 CometAPI를 통한 등 최신 모델 버전 공식 웹사이트에서 항상 업데이트됩니다. 시작하려면 모델의 기능을 살펴보세요. 운동장 그리고 상담하십시오 API 가이드 자세한 내용은 CometAPI를 참조하세요. 접속하기 전에 CometAPI에 로그인하고 API 키를 발급받았는지 확인하세요. 코멧API 공식 가격보다 훨씬 낮은 가격을 제공하여 통합을 돕습니다.

출발 준비 되셨나요?→ 지금 CometAPI에 가입하세요 !

AI에 대한 더 많은 팁, 가이드 및 뉴스를 알고 싶다면 저희를 팔로우하세요. VK, X 및 디스코드!