LLM API 키 보안을 위한 게이트웨이 아키텍처
- •애플리케이션 프로세스 내 LLM API 키 저장은 모든 의존성 패키지에 자격 증명을 노출한다.
- •네트워크 프록시를 도입하면 핵심 API 키를 격리하여 공급망 공격의 피해를 최소화할 수 있다.
- •프록시 아키텍처의 게이트웨이 토큰은 애플리케이션 재배포 없이 중앙화된 폐기 및 갱신을 가능하게 한다.
LLM 애플리케이션이 의존성 패키지 결함으로 공격받을 때, 그 피해 수준은 API 키를 애플리케이션 프로세스 내부에 직접 저장하는지 여부에 따라 크게 달라진다. 키가 애플리케이션 환경에 포함되어 있으면, 같은 프로세스 내에서 실행되는 악성 코드가 즉시 자격 증명을 탈취할 수 있기 때문이다. 반면, 네트워크 프록시를 활용하는 아키텍처는 모델 공급자의 API 키를 애플리케이션과 분리한다. 이 방식에서는 애플리케이션이 제한된 권한의 게이트웨이 토큰만 처리하고, 실제 인증 과정은 독립된 프록시 프로세스가 관리한다.
현재 대부분의 AI 애플리케이션은 환경 변수에서 API 키를 읽어 SDK를 초기화하는 인프로세스 패턴을 사용한다. 구현은 간편하지만, 프로세스 환경 내에서 실행되는 모든 라이브러리와 의존성 패키지가 동일한 접근 권한을 공유한다는 위험이 있다. 공급망 공격으로 의존성 패키지가 오염될 경우, 악성 코드는 애플리케이션 로직과 동일한 수준으로 API 키에 접근한다. 특히 많은 의존성 패키지는 설치나 임포트 시점에 실행되므로, 애플리케이션이 본격적으로 동작하기 전부터 비밀 정보가 노출될 수 있다.
네트워크 프록시는 이러한 인증 계층을 분리한다. 애플리케이션은 프록시에 요청을 보내고, 프록시가 공급자의 API 키를 주입하는 구조다. 프록시 프로세스가 별도로 존재하므로 애플리케이션은 민감한 자격 증명을 직접 보유하지 않는다. 따라서 패키지 보안 사고가 발생해도 공격자는 실제 API 키가 아닌 게이트웨이 토큰만 탈취할 수 있다. 게이트웨이 토큰은 특정 작업으로 권한 범위가 제한될 뿐만 아니라, 중앙에서 즉시 폐기하거나 교체할 수 있어 애플리케이션 재배포 없이 대응이 가능하다.
2026년 3월 발생한 LiteLLM 공급망 공격 사례는 이러한 보안 설계의 중요성을 부각했다. AI 애플리케이션이 오케스트레이션 프레임워크나 플러그인 등 복잡한 의존성 체인에 의존하게 되면서, 보안 침해 시 영향 범위는 더욱 커지고 있다. 생산 환경의 AI 인프라를 운영하는 팀들은 이제 핵심 자격 증명을 애플리케이션 프로세스에서 제거하고, 침해 사고 시 피해를 격리하는 방향으로 인프라 보안 전략을 전환하고 있다.