9.6.3 사용 금지된 라이브러리(Blacklisted Libraries) 및 라이선스 위반 모듈 차단

9.6.3 사용 금지된 라이브러리(Blacklisted Libraries) 및 라이선스 위반 모듈 차단

AI 모델은 ’코드가 동작하는가’에만 관심이 있을 뿐, ‘이 코드를 상업적으로 사용할 권리가 있는가’ 혹은 ’이 패키지가 우리 회사의 보안 정책에 부합하는가’에 대한 윤리적, 법률적 분별력이 전혀 없다.

LLM이 생성한 코드가 비즈니스 로직을 완벽하게 수행한다 하더라도, 그 이면에 GNU GPL(General Public License) v3 라이선스가 걸린 카피레프트(Copyleft) 라이브러리가 단 하나라도 포함되어 있다면, 엔터프라이즈 코드베이스 전체의 소스코드를 강제로 공개해야 하는 법적 재앙(Legal Disaster)이 발생할 수 있다.

따라서 컴플라이언스(Compliance) 중심의 개발 파이프라인에서 오라클 시스템은 단순한 문법 검사기를 넘어, **블랙리스트(Blacklist)**와 **라이선스 폴리시(License Policy)**를 강제하는 가장 강력한 사내 법무팀의 역할을 수행해야 한다.

1. 정적 블랙리스트(Static Blacklist) 필터링 아키텍처

사내 보안팀은 프로젝트 워크스페이스 내에 forbidden_packages.json 혹은 .devcontainer/policies.yaml과 같은 형태로 **‘절대 사용해서는 안 될 라이브러리 목록’**을 유지 관리해야 한다.

  • 성능 저하 및 레거시 모듈: Python의 os.system (보안 취약점), JavaScript의 request (유지보수 중단), Java의 오래된 log4j (CVE-2021-44228 등) 구버전.
  • 오라클 미들웨어는 LLM이 코드를 생성하여 파이프라인에 진입시킨 직후, import 구문을 AST(Abstract Syntax Tree)로 파싱하여 이 블랙리스트와 이중 매칭(Cross-matching)을 수행한다.
  • 만약 LLM이 블랙리스트에 등재된 모듈을 호출했다면, 오라클은 즉시 *“당신이 사용한 requests 모듈은 사내 보안 정책에 의해 금지되었습니다. 대신 인가된 httpx 비동기 라이브러리를 사용하여 로직을 재작성하십시오”*라는 명시적인 강제 수정(Forced Refactoring) 프롬프트를 주입한다.

2. 라이선스 무결성(License Integrity) 실시간 스캐닝

가장 까다로운 부분은 이름도 멀쩡하고 보안 취약점도 없는 ’정상적인 패키지’이지만 라이선스가 문제 되는 경우다. 오픈소스 생태계는 MIT, Apache 2.0과 같은 허용적인 라이선스와 GPL, AGPL과 같은 바이러스성 라이선스가 혼재되어 있다.

오라클은 AI가 생성한 종속성 메니페스트(package.json, pom.xml 등)를 가로챈 뒤, FOSSA나 Black Duck, 혹은 오픈소스 도구인 License Finder와 같은 라이선스 스캐닝 툴을 헤드리스(Headless) 모드로 연동해야 한다.

  1. 동적 쿼리: 라이브러리가 식별되면 오라클은 SPDX(Software Package Data Exchange) 데이터베이스에 쿼리를 날려 해당 패키지(및 그 하위 종속성 전체)의 라이선스 구조를 JSON 형태로 응답받는다.
  2. 정책반영(Policy Evaluation): 사내 ’License Policy’에 위배되는 AGPL/GPL 라이브러리가 하나라도 트리에 섞여 있다면 프로세스를 정지(Halt)시킨다.
  3. LLM 피드백 루프: AI에게 “생성된 종속성 트리에 GPL v3 라이선스를 가진 모듈 X가 포함되어 상업적 배포가 불가능합니다. MIT 또는 Apache 2.0 라이선스를 가진 대체 모듈을 찾아 코드를 재생성하라“라는 컨텍스트를 주입한다.

3. 사내 래퍼(Wrapper) 라이브러리 사용의 강제

고도화된 엔터프라이즈 환경에서는 LLM이 오픈소스 원본(Raw Open-source) 라이브러리를 직접 호출하는 것조차 금지하기도 한다. 가령 외부 HTTP 요청을 보낼 때 axios를 직접 쓰면 안 되고, 반드시 사내 인증 토큰(Auth Token) 매커니즘이 강제된 company-internal-http-client라는 래퍼 모듈을 통하도록 룰을 세운다.

  • 이 경우 오라클은 단순한 ’블랙리스트’를 넘어, **‘특정 도메인에서는 오직 이 라이브러리만 써라’**는 화이트리스트(Whitelist) 방식을 채택한다.
  • AI가 fetch()나 axios.get()을 생성하면, 정적 분석 오라클은 이를 AST 레벨에서 적발하고 *“보안 정책에 따라 모든 외부 API 호출은 @company/auth-fetch를 통해서만 이루어져야 합니다.”*라고 제재한다.

라이브러리와 종속성의 무결성을 검증하는 오라클은 AI가 내뿜는 광활한 오픈소스의 파도를 통제 가능한 사내 규정이라는 작은 댐 안으로 가두는 수문장이다. 이 문을 지키지 못하면 아무리 세련된 코드를 짜는 AI 파이프라인이라 할지라도 언제 터질지 모르는 치명적인 법무적/보안적 시한폭탄을 양산하는 공장에 불과하다.