9.6 할루시네이션 라이브러리 및 종속성(Dependency) 검증 오라클

코드 생성 AI 모델이 프로덕션(Production) 환경에 통합될 때 직면하는 가장 치명적이고 빈번한 보안 결함 중 하나는 바로 ‘할루시네이션 라이브러리(Hallucinated Library)’ 또는 **‘존재하지 않는 종속성(Non-existent Dependency)’**의 주입 현상이다. LLM(거대 언어 모델)은 방대한 오픈소스 생태계의 패키지 네이밍 규칙(Naming Convention)을 통계적으로 학습하기 때문에, 개발자가 의도한 기능을 수행할 법한 그럴싸한 이름의 외부 패키지를 상상하여 import 구문에 무작위로 끼워 넣는 경향이 짙다.

본 단원에서는 이러한 가상의 종속성(Virtual Dependencies)이 실제 기업의 소프트웨어 망(Network)에 초래하는 공급망 차원의 끔찍한 위협을 분석하고, 이를 설계 단계에서 완벽히 차단하기 위한 결정론적 ‘종속성 검증 오라클(Dependency Verification Oracle)’의 구축 방법을 논의한다.

1. 할루시네이션 종속성이 야기하는 시스템 침해 위협 (Dependency Confusion)

LLM이 존재하지 않는 패키지(예: import requests_async_fetcher 혹은 npm install react-query-fast)를 생성해냈을 때, 이를 그대로 CI/CD 파이프라인이나 자동화된 실행 환경으로 넘기게 되면 매우 심각한 보안 및 안정성(Stability) 문제가 발생한다.

과거 인간 엔지니어들이 범하던 ‘타이포스쿼팅(Typosquatting)’ 공격과 유사하게, 악의적인 해커(Attacker) 집단이 유명 LLM 모델들이 빈번하게 환각으로 발생시키는 패키지 이름들을 선점하여 공용 레지스트리(PyPI, NPM, Maven Central 등)에 진짜 악성 코드를 담아 배포하는 공격, 속칭 **‘AI 종속성 혼동 공격(AI Dependency Confusion Attack)’**이 현실화되고 있다.

이러한 위협을 방어하기 위해 시스템은 코드가 해석(Evaluation)되거나 패키지 매니저가 실행되기 전에 즉각 개입하여, 코드 내에 선언된 라이브러리 교차 참조(Cross-referencing) 구조를 정적(Static)으로 분석하는 오라클을 구축해야만 한다.

2. 정적 분석 기반의 미등록 라이브러리 감지 오라클 구현

가장 일차원적이지만 필수적인 방어망은 추상 구문 트리(AST, Abstract Syntax Tree)를 파싱(Parsing)하여 선언된 외부 패키지를 추출하고, 이를 프로젝트의 공식 의존성 명세(예: package.json, requirements.txt, build.gradle 등)와 비교하는 **내부 정합성 오라클(Internal Consistency Oracle)**이다.

graph TD
    A[AI Generated Source Code] --> B{AST Parser Oracle}
    B --> C[Extract Import / Require Statements]
    C --> D[List A: AI Proposed Dependencies]
    E[Project Manifest: package.json / requirements.txt] --> F[Extract Registered Dependencies]
    F --> G[List B: Approved Dependencies]
    
    D --> H{Is List A subset of List B?}
    H -->|Yes| I[Pass: Oracle Verification Success]
    H -->|No| J[Fail: Detect Hallucinated / Unregistered Package]
    J --> K[Trigger Re-prompt or Human Intervention]

오라클은 import 구문에 기재된 모듈 이름을 List A로 담고, 매니페스트(Manifest)에 존재하는 패키지 이름을 List B로 구축하여 교집합(Intersection) 연산을 수행한다. AI 모델이 List B에 명시적으로 존재하지 않는 외부 라이브러리를 동원하여 코드를 짰다면, 오라클은 이를 **규칙 위반(Constraint Violation)**으로 선언하고 “승인되지 않은 라이브러리를 사용했습니다. 내장 라이브러리(Standard Library)나 주어진 requirements.txt 안에서만 코드를 작성하라.“라는 결정론적 피드백 루프(Feedback Loop)를 발생시킨다.

3. 패키지 레지스트리(Registry) 연동을 통한 실존 검증 오라클

만약 AI 에이전트(Agent)가 애플리케이션의 뼈대부터 초기화하여 requirements.txt 자체를 새롭게 생성하는 과업(Task)을 수행 중이라면, 비교 대상이 될 기반 선언문이 아직 존재하지 않는다. 이 경우 오라클은 외부와의 통신을 통해 해당 패키지의 물리적 실존 여부를 검증해야 한다.

Registry API Oracle Validation: 모델이 출력한 requirements.txt 목록을 읽어들인 오라클이, 실제 패키지가 설치되기 전 단계에서 PyPI(Python) 또는 NPM(Node.js)의 공식 HTTP REST API를 향해 HEAD 핑(Ping) 테스트를 수행한다.
버전 정합성(Version Compatibility): 의존성의 존재 여부뿐만 아니라, LLM이 흔히 저지르는 “존재하지 않는 마이너 버전(Minor Version) 환각” 역시 검열해야 한다. react@18.9.99와 같은 가상의 패키지 버전이 선언되었다면, 오라클은 레지스트리 메타데이터(Metadata)와 대조하여 확정적인 Error를 반환하고 빌드 파이프라인(Build Pipeline)이 감염되는 것을 원천 차단한다.

4. 허용 목록(Allowlist) 및 차단 목록(Blocklist) 기반 종속성 제어 프레임워크

금융 서비스나 방위 산업 등 엄격한 망분리와 보안 심사가 동반되는 엔터프라이즈 환경에서는, 패키지가 실존한다고 해서 무조건 승인할 수 없다. 오라클은 다음 두 가지의 리스트를 기반으로 동작하는 정책 엔진(Policy Engine) 역할을 겸해야 한다.

허용 목록 기반 차단(Allowlist Filtering): AI는 오로지 사내 보안팀(Security Team)의 취약점 스캐닝(Vulnerability Scanning)을 통과한 특정 라이브러리와 특정 버전만 사용할 수 있다. 오라클은 AI의 결과물이 이 화이트리스트(Whitelist)를 1 byte라도 벗어날 경우 절대(Absolute) Failure를 선언한다.
라이선스(License) 제약 오라클: AI 모델은 코드뿐만 아니라 라이브러리의 오픈소스 라이선스 정책(GPL, MIT, Apache 등)에 대한 인지 능력이 현저히 떨어진다. 종속성 검증 오라클은 OSI(Open Source Initiative) 명세나 사내 FOSS(Free and Open Source Software) 관리 시스템과 연동되어 방역망을 구성해야만 기술 부채와 더불어 심각한 법적 부채(Legal Debt)를 예방할 수 있다.

AI 소프트웨어 엔지니어링 생태계에서 ‘실행될 법한’ 환각 라이브러리는 조용한 암살자와 같다. 시스템 런타임에 진입하기 직전, 가장 차갑고 단호하게 종속성 트리를 검열하는 오라클 파이프라인이야말로 에이전틱(Agentic) 코드 생성기가 재앙이 아닌 생산성의 날개가 되게 하는 가장 핵심적인 교두보(Bridgehead)이다.