인사이트리포트

들어가며

생성형 AI 경쟁의 초점은 바뀌고 있다. 초기에는 더 강력한 모델, 더 긴 컨텍스트, 더 낮은 추론 비용이 핵심이었다. 하지만 AI가 실제 업무 시스템에 들어오면서 기업의 관심은 모델 성능 자체보다 AI를 안전하게 통제하고, 관측하며, 운영하는 방법으로 이동했다.

이 변화의 중심에는 AI Agent가 있다. Agent는 단순 챗봇이 아니라 문서 검색, 코드 작성, API 호출, 티켓 생성 등 권한을 가진 디지털 행위자로 동작한다.

운영 영역에서는 Kubernetes와 CNCF의 움직임이 중요하다. Kubernetes는 더 이상 일반 컨테이너 워크로드만을 위한 플랫폼이 아니다. LLM inference, RAG pipeline, Agent runtime, MCP server, Vector DB, AI Gateway가 Kubernetes 위에서 운영되는 새로운 AI 워크로드로 부상하고 있다. CNCF의 Kubernetes AI Conformance Program, Kubernetes Gateway API Inference Extension, Dynamic Resource Allocation, OpenTelemetry GenAI semantic conventions, 그리고 llm-d는 이 변화를 구체적으로 보여주는 사례다.

오픈소스 경쟁의 축은 모델에서, 안전하게 통제·관측·운영 가능한 AI 인프라 계층으로 이동하고 있다.

모델 경쟁 이후, 오픈소스의 새로운 질문

생성형 AI의 첫 국면은 모델 경쟁이었다. 더 높은 벤치마크, 더 긴 컨텍스트, 더 빠른 응답, 더 낮은 API 비용이 비교 기준이었다. 하지만 AI가 PoC를 넘어 실제 업무 시스템에 적용되면서 질문은 달라지고 있다.

기업이 묻는 핵심은 다음과 같다.

• 데이터: AI는 어떤 내부 데이터에 접근하고, 무엇이 외부 LLM로 전송되는가?
• 권한: Agent가 어떤 도구/시스템 권한을 갖고, 어떤 승인 흐름이 필요한가?
• 검증: AI가 생성한 코드변경은 어떻게 검증되는가?
• 관측/비용: 프롬프트모델 호출·툴 호출 이력과 token 사용량은 어떻게 추적/관리되는가?
• 종속성: 특정 모델클라우드·플랫폼에 과도하게 잠기지 않도록 설계할 수 있는가?

이 질문들은 모델 성능만으로 해결되지 않는다. AI를 도입하는 것과 AI를 운영하는 것은 다르기 때문이다.

AI Agent는 새로운 권한 주체다

기존 챗봇은 답변을 제공하는 인터페이스에 가깝다. 반면 AI Agent는 시스템 안에서 행동한다. 사내 문서·코드에 접근하고, 변경을 만들며(예: PR/티켓 생성), 필요 시 도구를 호출해 작업을 수행한다.

즉 Agent는 단순한 기능이 아니라 조직 시스템에서 실행 권한을 행사하는 주체다. 그래서 OWASP가 prompt injection, 민감정보 노출, excessive agency 등을 주요 위험으로 제시한다[1]. Agent가 외부에 영향을 주는 순간 위험 범위가 넓어지기 때문이다[2].

오픈소스의 무게중심은 모델에서 인프라로 이동한다

오픈소스는 Linux와 Kubernetes를 통해 기업 IT 인프라의 공통 기반을 만들어왔다. AI 시대에도 유사한 흐름이 나타나고 있다. 다만 이번에는 모델 자체보다 AI를 실행, 통제, 관측, 연결, 표준화하는 인프라 계층이 중요해지고 있다.

Part 1에서는 이 중 보안과 운영에 집중한다. Agent가 권한을 갖는 순간 보안의 기준선이 바뀌고, LLM과 Agent가 실제 서비스로 운영되는 순간 Kubernetes는 새로운 AI 워크로드 플랫폼으로 확장된다.

보안: AI가 오픈소스 보안의 기준선을 바꾼다

AI는 오픈소스 보안의 양쪽 속도를 동시에 끌어올린다. 방어자는 분석·수정을 더 빠르게 하고, 공격자도 자동화 수준을 높인다. 따라서 보안 관리 범위는 “취약한 컴포넌트”에서 AI가 생성·전송·실행하는 전체 흐름으로 확장된다.

[그림 1] GitHub Copilot의 보안 자동 수정[3]

반대로 공격자도 AI를 활용할 수 있다. 취약한 패키지를 빠르게 찾고, 익스플로잇 코드를 변형하며, 피싱 메시지나 악성 스크립트를 자동 생성할 수 있다. AI는 방어자의 생산성을 높이지만, 공격자의 자동화 수준도 함께 끌어올린다.

따라서 AI 시대의 오픈소스 보안은 기존의 CVE 관리나 dependency scan만으로 충분하지 않다. AI 시대의 보안 대상은 대체로 다음 4가지로 묶인다.

• 생성/변경: AI가 만든 코드PR/설정 변경
• 데이터 이동: 외부 LLM로 전송되는 프롬프트컨텍스트
• 실행/권한: Agent가 호출하는 Tool/API와 권한승인 흐름
• 관측/증적: 전체 실행 이력(프롬프트콜·토큰 사용)과 감사 로그

OpenSSF AI/ML Security WG이 LLM·GenAI 시스템과 공급망 리스크를 다루는 것도 같은 이유다[4]. 보안의 대상이 “취약한 소프트웨어 컴포넌트”에서 “AI가 만들고 호출하고 실행하는 전체 흐름”으로 확장되고 있는 것이다.

Agent 권한 통제: 서비스 계정처럼, 그러나 더 정교하게

Agent는 사실상 자동화된 사용자 또는 서비스 계정처럼 동작한다. 다만 일반 서비스 계정과 달리, 실행 경로가 프롬프트·검색 컨텍스트·외부 도구 응답에 따라 달라질 수 있다. 따라서 Agent 권한 관리는 단순 API key 발급보다 정교해야 한다. 이 Agent는 사실상 자동화된 사용자 또는 서비스 계정이다. 그러나 일반 서비스 계정과 다른 점이 있다. Agent는 LLM의 판단, 프롬프트 입력, 검색된 컨텍스트, 외부 도구 응답에 따라 실행 경로가 달라질 수 있다. 즉 실행 흐름이 완전히 결정적이지 않다.

핵심은 Agent를 “AI 기능”이 아니라 권한 주체(Identity/Permission/Policy/Audit)로 등록·관리하는 것이다. 특히 쓰기·삭제·배포·권한 변경은 사람 승인(human-in-the-loop)이 필요하다.

AI 생성 코드는 더 빠르게 만들어지지만, 더 엄격하게 검증되어야 한다

AI가 코드를 빠르게 생성하더라도 항상 안전한 것은 아니다. 권한 검증 누락, 입력 검증 부재, 오래된 API 사용 같은 문제가 섞일 수 있다.

GitHub Copilot Autofix와 같은 도구는 AI가 보안 수정에도 활용될 수 있음을 보여준다 [24]. 다만 GitHub 문서 역시 Autofix 결과에 대한 검토와 책임 있는 사용이 필요하다는 점을 명확히 한다[5]. 이는 AI 보안 자동화가 유용하지만, 무제한 자동 수정이 아니라 기존 code scanning, CodeQL, review 프로세스와 함께 작동해야 함을 의미한다.

AI가 코드를 빠르게 생성하더라도 항상 안전한 것은 아니다. 권한 검증 누락, 입력 검증 부재, 오래된 API 사용 같은 문제가 섞일 수 있다.

외부 LLM 데이터 전송은 새로운 유출 경로다

AI 보안에서 특히 중요한 지점은 외부 LLM으로 전송되는 데이터다. 개발자나 Agent가 사내 문서, 고객 정보, 소스코드, 장애 로그, 보안 이벤트를 외부 모델 API에 전달하면, 이는 새로운 데이터 이동 경로가 된다. 특히 RAG·Agent 환경에서는 검색 결과, 내부 API 응답, 로그 일부 등이 프롬프트에 함께 들어갈 수 있어 위험이 커진다. OWASP가 설명하는 prompt injection이 그 예다[6].

기업은 외부 LLM 전송을 다음처럼 관리해야 한다.

• 외부로 나갈 수 있는 데이터 범위와 금지 항목 정의
• 개인정보·인증정보·내부 기밀 자동 탐지 및 차단
• 프롬프트/검색 결과에 대한 필터링(허용 목록 기반)
• 모델 제공자별 데이터 보관학습 정책 확인
• 호출 로그감사 기록 보관 및 Agent별 전송 정책 분리

AI 보안은 “안전한 답변”만의 문제가 아니라, 어떤 데이터가 어떤 모델로 이동하는지의 통제 문제다.

Project Glasswing과 OpenSSF가 보여주는 방향

Project Glasswing[7]과 OpenSSF의 흐름은 AI 시대에도 오픈소스 보안 부담을 줄이려는 시도다. maintainer는 대규모 전담 보안팀만큼의 리소스를 갖기 어렵지만, AI가 취약점 탐지와 패치 제안을 보조하면 방어 역량을 끌어올릴 수 있다[8]. 다만 AI가 대신하는 것은 검증이 아니라 검증 가능한 보조여야 한다. AI의 탐지·패치·조치 모두 검토 및 책임 체계 안에서 운영되어야 한다.

운영: LLM과 Agent는 Kubernetes 위의 워크로드가 된다

AI가 서비스로 운영되기 시작하면 모델 호출은 API 사용을 넘어 플랫폼 운영 문제가 된다. LLM inference, RAG, Agent runtime, Vector DB, AI Gateway는 배포·확장·장애 대응·비용 관리·관측성의 대상이 된다. 이에 맞춰 CNCF 쪽에서도 Kubernetes의 AI/ML 운영 역량을 표준화하려는 움직임이 나온다. AI Conformance[9], Gateway API Inference Extension[10], DRA[11], OpenTelemetry GenAI Semantic Conventions 등이 그 예다.

AI 워크로드는 일반 애플리케이션처럼 운영할 수 없다

기존 웹 애플리케이션 운영에서는 CPU, 메모리, 요청 수, 평균 latency, error rate가 핵심 지표였다. 그러나 LLM과 Agent는 운영 특성이 다르다. LLM inference는 GPU/TPU 같은 accelerator에 의존한다. 요청마다 prompt 길이, output token 수, KV cache 사용량이 달라진다. 동일한 QPS라도 긴 컨텍스트 요청이 많으면 GPU 메모리와 연산 부하가 급격히 증가할 수 있다.

Agent runtime은 더 복잡하다. Agent는 모델을 한 번 호출하고 끝나는 것이 아니라, 검색, API 호출, 코드 실행, Tool Call, 재시도, 최종 응답 생성을 반복한다. 장애 지점도 모델 서버, Vector DB, 내부 API, 인증 시스템, 외부 SaaS로 분산된다.

즉, AI 운영은 모델 서버를 Kubernetes에 배포하는 수준을 넘어, scheduling/routing/cache/ 가시성/가격 정책까지 포함한다.

Kubernetes와 CNCF의 방향성: AI 워크로드 표준 운영 계층

Kubernetes와 CNCF 생태계에서 최근 나타나는 흐름은 크게 네 가지로 정리할 수 있다.

1) AI Conformance: AI 워크로드를 위한 Kubernetes 기준선 제시

CNCF의 Kubernetes AI Conformance Program은 AI/ML 워크로드를 안정적으로 실행하기 위한 Kubernetes 기능·검증 기준을 표준화하려는 시도다. GPU/가속기 관리, 관측성, 워크로드 격리 등 AI 운영에 필요한 요소까지 함께 검증하려는 흐름으로 볼 수 있다[12].

2) Dynamic Resource Allocation: GPU를 더 세밀하게 다루기 위한 기반 기술

DRA는 Pod가 GPU/accelerator 같은 장치 리소스를 더 유연하게 요청·공유하도록 돕는다. GPU는 비용이 크고 부족하므로, 모델 크기·latency 목표·배치 특성에 맞춰 더 세밀하게 배분하는 것이 중요하다[13].

3) Gateway API Inference Extension: LLM-aware routing

기존 로드밸런서는 LLM 요청 특성(prompt 길이, 예상 output token 수, 캐시 상태)에 따른 비용·지연 변화를 충분히 반영하지 못한다. Inference Extension은 inference-specific routing을 제공해 Kubernetes 기반 서빙의 지연/처리량을 개선하는 것을 목표로 한다[14].

이는 AI Gateway가 단순 API gateway가 아니라 모델 요청을 이해하는 운영 제어 지점으로 진화하고 있음을 보여준다.

4) OpenTelemetry GenAI: AI 운영 관측성의 표준화

AI 관측성은 latency/error뿐 아니라 호출된 모델, token 사용량, Tool Call, 그리고 프롬프트·응답 관계까지 추적해야 한다. OpenTelemetry의 GenAI Semantic Conventions은 벤더 도구에 종속되지 않도록 telemetry 구조를 표준화하려는 작업이다[15].

llm-d: Kubernetes-native 분산 LLM 추론 스택

[그림 2] llm-d의 아키텍처 – K8s 네이티브 분산 LLM 추론

llm-d는 AI 운영 관점에서 주목할 만한 CNCF Sandbox 프로젝트다[16]. vLLM 기반의 Kubernetes-native 분산 LLM inference를 목표로 하며, intelligent scheduling과 KV-cache 최적화 등 성능·운영 효율을 강조한다[17].

핵심은 단순히 “모델 서버를 늘리는 것”이 아니라, Kubernetes 위에서 대규모 추론을 운영 가능한 분산 시스템으로 만드는 것이다. 또한 플랫폼·인프라 계층에서 병렬화/자원 효율을 끌어올려 운영 복잡도를 낮추는 방향을 함께 지향한다.

llm-d가 해결하려는 문제

LLM inference는 일반적인 stateless API 서버 운영과 다르다. llm inference에서는 다음 문제들이 중요하다.

• 모델 크기로 인한 cold start/scale-out 비용
• prefill vs decode의 서로 다른 리소스 특성과 KV cache 민감도
• 요청 길이output token 수 변동에 따른 지연/처리량 예측 어려움
• 다양한 accelerator/클라우드/서빙 환경을 일관되게 운영

[그림 3] llm-d 분산 추론의 AS-IS 와 TO-BE

llm-d는 이러한 문제를 Kubernetes-native 방식으로 다루려 한다. Red Hat은 llm-d를 Kubernetes-native distributed inferencing으로 설명하며, 지연시간을 줄이고 throughput을 극대화하기 위한 고급 최적화가 핵심이라고 소개한다[18]. Solo.io 역시 llm-d가 vLLM, Kubernetes, Inference Gateway, kgateway 생태계와 연결되는 오픈소스 분산 inference serving 플랫폼이라는 점을 강조한다[19].

llm-d의 아키텍처

다음은 llm-d의 전체적인 아키텍처를 보여주는 다이어그램이다.

[그림 4] llm-d의 상세 아키텍처[20]

llm-d 아키텍처는 vLLM(추론 엔진) 위에 추론 세션의 흐름을 운영 관점에서 제어하는 레이어를 얹고, Kubernetes가 실행/확장을 담당하는 구조로 이해할 수 있다.

• Inference Gateway(IGW) + EPP(Endpoint Picker Protocol): 운영 신호(SLA/부하/KV 상태 등)를 바탕으로 적합한 replica를 선택한다.
• vLLM 모델 서버: 실제 추론을 수행하며, disaggregated serving(필요 시 prefill/decode 분리)과 KV-cache 확장 구성을 지원한다.
• Kubernetes: 워크로드 제어스케줄링을 통해 분산 추론 운영을 클러스터 단위로 일관되게 만든다.

정리하면, llm-d의 아키텍처는 모델을 서빙하는 엔진(vLLM)보다 한 단계 위에서 추론 세션의 흐름을 운영 관점에서 제어하는 레이어 (IGW/EPP + KV-aware scheduling)를 중심에 두고, 그 위에서 Kubernetes가 실행과 확장을 맡는 구조로 이해할 수 있다.

llm-d의 운영적 의미

llm-d가 중요한 이유는 AI 운영의 무게중심이 단순 모델 구동 서버에서 inference control(요청 라우팅/캐시/스케줄링)로 이동하고 있음을 보여주기 때문이다.

1. 모델/엔드포인트 선택: 다중 모델다중 accelerator 환경에서 요청 라우팅과 캐시 활용을 결정하는 control plane 필요
2. GPU 효율 최적화: 배치prefill/decode·TTFT/TPOT·KV locality를 함께 최적화
3. 이식 가능한 운영 계층: Kubernetes-native 접근으로 특정 클라우드/가속기에 대한 의존 완화
4. 성능-비용 동시 제어: GPU 시간과 token usage를 운영 관점에서 관리

실무 AI 운영 아키텍처: 모델 서버가 아니라 실행 체계 전체를 봐야 한다

실제 기업 환경에서 AI 서비스는 단일 모델 서버로 끝나지 않는다. 일반적으로 다음 계층이 함께 운영된다.

[그림 5] K8s 기반의 AI 서비스·추론 아키텍처

이 구조에서 Kubernetes는 단순 배포 환경이 아니라 AI workload의 공통 운영 계층이 된다. 요청은 AI Gateway가 라우팅하고, Agent runtime·RAG pipeline은 내부 API/도구와 지식 소스를 연동해 실행을 만든다. LLM serving layer는 GPU/TPU에서 추론을 수행하며, OpenTelemetry 기반 관측성은 token usage·latency·model/tool 호출을 수집한다 [23].

또한 Kubernetes Gateway API Inference Extension은 inference-aware routing 구성요소(예: inference pool/endpoint picker)를 제공하고[21], OpenTelemetry GenAI metrics는 token·요청 단위 관측성 항목을 표준화한다[22].

관측성: Prompt, Model Call, Tool Call까지 추적해야 한다

LLM 사용자가 답변이 이상하다고 느낄 때 원인은 모델 자체가 아닐 수 있다. 이제는 아래와 같은 요소까지 확인해야 한다.

• 검색/컨텍스트 품질 문제(부정확한 RAG 결과, 검색 최신성 부족)
• Agent의 도구 호출 문제(잘못된 Tool Call 또는 필요한 데이터 접근 실패)
• 모델 라우팅 문제(부적절한 모델 호출)
• 실행 반복으로 인한 비용/지연 문제(반복 Tool Call 등)

따라서 AI 운영 관측성은 기존 로그·메트릭·트레이스를 넘어선 영역까지 확인해야 한다.

TTFT는 첫 토큰까지의 시간, TPOT는 이후 토큰 생성 속도다. 따라서 기존처럼 평균 latency만으로는 LLM 서비스의 체감 성능을 설명하기 어렵다. 이 외에도 여러 사용자에게 안정적으로 AI 서비스를 제공하기 위해서는 더 넓은 영역에 걸쳐 관측할 수 있어야 한다.

비용 관리는 GPU와 token을 함께 봐야 한다

AI 운영 비용은 크게 두 축에서 발생한다.

• 인프라 비용: GPU/TPU 사용률, idle GPU, batch 효율, 캐시 활용
• 토큰 비용: prompt/completion 토큰, 모델별 단가, Agent의 반복 호출

자체 모델과 외부 API를 함께 쓰는 경우가 많으므로 비용 관리 단위도 분리해야 한다.

• 팀별 GPU 사용량
• 서비스/Agent별 token usage 및 호출량
• 모델/서빙별 cost per request
• RAG 검색Vector DB 운영 비용

비용 최적화는 더 싼 모델을 고르는 문제가 아니라, 운영 정책으로 어떤 요청을 어떤 모델/에이전트로 보낼지와 반복 호출을 어떻게 제한할지, 캐시를 어떻게 활용할지까지 관리하는 일이다.

플랫폼팀이 준비해야 할 운영 기준

따라서 AI 플랫폼팀은 AI를 별도 실험이 아니라 운영 범주로 정의하고 기준을 마련해야 한다.

이 기준이 없으면 AI 도입은 빨라질 수 있지만, 보안·비용·운영 리스크는 플랫폼팀이 뒤늦게 흡수하게 된다. 반대로 기준을 갖춘 조직은 모델 선택의 자유도를 유지하면서도 AI를 엔터프라이즈 워크로드로 안정적으로 운영할 수 있다.

AI는 새로운 운영 워크로드이며, Agent는 새로운 권한 주체다

AI Agent가 등장하면서 기업이 마주하는 과제는 성능 향상 자체가 아니다. AI가 실제 업무 시스템에서 실행되기 시작하면서, 오픈소스 인프라는 안전한 운영 기준과 권한 구조를 정의하는 역할로 중심이 이동하고 있다.

변화는 두 가지로 요약된다.

• 보안 기준선의 변화: AI 생성 코드, 외부 LLM 전송 데이터, Agent 권한, Tool call, 감사 로그가 이전과 다른 결합을 만든다. Agent는 단순 기능이 아니라 행위를 수행하는 주체이므로, 권한을 최소화하고 실행 이력을 감사 가능하게 남기는 기준이 필요하다.
• 운영 기준선의 변화: LLM inference와 RAG, Agent runtime, MCP server, Vector DB는 더 이상 주변 요소가 아니라 Kubernetes 위에서 관리해야 하는 새로운 워크로드가 된다. GPU/TPU 배치, token·TTFT/TPOT·KV cache 같은 성능 지표, Tool call trace, 비용 관리, 관측성은 AI 운영의 핵심이 된다.

기업은 AI를 만드는 것에서 끝내지 않고, 안전하게 굴릴 수 있는 운영 범주로 받아들여야 한다. 에스코어는 오픈소스를 단순 선정이 아니라 거버넌스 컨설팅과 도입/아키텍팅, 상용 전환, 시스템 구축, 기술 지원까지 연결하는 ‘오픈소스 원스톱 서비스’로 이 전환을 돕는다.

이어지는 Part 2에서는 이 운영 기반 위에서 Agent가 사내 도구·데이터·다른 Agent와 어떻게 연결되는지 살펴본다. MCP, A2A, AGNTCY, agentgateway 흐름을 중심으로 연동과 표준화의 필요성, 그리고 주요 기업들이 모델보다 실행 환경과 거버넌스 계층을 장악하려는 이유를 분석하고 AI 도입을 위해 기업 혹은 관계자들이 어떤 점을 유념해야 하는지 정리한다.

============================================================================================================

[1] (https://owasp.org/www-project-top-10-for-large-language-model-applications/), LLM 애플리케이션의 주요 보안 위험으로 prompt injection, sensitive information disclosure, excessive agency 등이 제시된다.

[2] (https://genai.owasp.org/llmrisk/llm06-excessive-agency/), Agentic LLM이 과도한 권한을 가질 경우 예상치 못한 작업을 수행할 수 있다.

[3] (https://docs.github.com/en/code-security/concepts/code-scanning/copilot-autofix-for-code-scanning), Copilot Autofix가 code scanning alert에 대해 AI 기반 수정 제안을 제공한다.

[4] (https://openssf.org/groups/ai-ml-security/), OpenSSF가 AI/ML, LLM, GenAI 보안 리스크와 오픈소스 공급망 보안을 다룬다.

[5] (https://docs.github.com/en/code-security/responsible-use/responsible-use-autofix-code-scanning), Copilot Autofix 결과에 대한 검토와 책임 있는 사용이 필요하다.

[6] (https://genai.owasp.org/llmrisk/llm01-prompt-injection/), 사용자 입력이나 외부 콘텐츠가 LLM 동작을 의도치 않게 변경할 수 있다는 prompt injection 설명.

[7] (https://www.anthropic.com/glasswing), AI 시대의 핵심 소프트웨어 보안을 강화하기 위한 Project Glasswing의 취지와 내용 확인용.

[8] (https://www.linuxfoundation.org/blog/project-glasswing-gives-maintainers-advanced-ai-to-secure-open-source), Project Glasswing이 오픈소스 maintainer에게 AI 기반 보안 역량을 제공하려는 흐름.

[9] (https://www.cncf.io/announcements/2025/11/11/cncf-launches-certified-kubernetes-ai-conformance-program-to-standardize-ai-workloads-on-kubernetes/), CNCF가 Kubernetes 기반 AI 워크로드 운영 표준화를 위해 Kubernetes AI Conformance Program을 출범했다.

[10] (https://kubernetes.io/blog/2025/06/05/introducing-gateway-api-inference-extension/), Gateway API Inference Extension이 Gateway API 위에 inference-specific routing 기능을 추가한다.

[11] (https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/), Kubernetes DRA가 GPU, accelerator 등 특수 장치 리소스를 Pod에서 유연하게 요청·공유할 수 있게 하는 기능.

[12] (https://github.com/cncf/k8s-ai-conformance), Kubernetes AI Conformance Program의 공식 저장소. AI/ML 워크로드를 위한 Kubernetes 플랫폼 역량과 테스트 기준 확인.

[13] https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-device-management-with-dra-dynamic-resource-allocation), DRA가 Kubernetes에서 GPU와 accelerator 자원 관리를 개선하는 방향.

[14] (https://gateway-api-inference-extension.sigs.k8s.io/), Kubernetes에서 self-hosted generative model serving을 최적화하기 위한 Gateway API Inference Extension 공식 문서.

[15] (https://opentelemetry.io/docs/specs/semconv/gen-ai/), GenAI operation, LLM 호출, token usage 등 AI 운영 관측성 표준화 흐름.

[16] (https://llm-d.ai/), llm-d가 vLLM 기반의 Kubernetes-native 분산 LLM inference 스택이며, intelligent scheduling, KV-cache optimization, accelerator 성능 최적화를 지향한다.

[17] (https://cloud.google.com/blog/products/ai-machine-learning/enhancing-vllm-for-distributed-inference-with-llm-d), llm-d가 vLLM을 Kubernetes-native distributed and disaggregated inference 방향으로 확장한다.

[18] (https://developers.redhat.com/articles/2025/05/20/llm-d-kubernetes-native-distributed-inferencing), llm-d가 Kubernetes-native distributed inference를 통해 latency를 줄이고 throughput을 극대화하려 한다.

[19] (https://www.solo.io/blog/llm-d-distributed-inference-serving-on-kubernetes), llm-d가 vLLM, Kubernetes, Inference Gateway, kgateway 생태계와 연결되는 분산 inference serving 플랫폼.

[20] (https://llm-d.ai/docs/architecture), llm-d의 공식 문서 아키텍처 설명.

[21] (https://github.com/kubernetes-sigs/gateway-api-inference-extension), InferencePool, InferenceModel, endpoint picker 등 inference-aware routing 관련 CRD와 구현.

[22] (https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-metrics/), GenAI 관련 metric, token 사용량, model request 관측성 항목.