에이전트 시대의 인프라는 네 겹이다: KubeCon, IBM, Commvault의 발표를 한 장으로 겹쳐 보면
카테고리: Infra Insight 타겟 독자: CIO, 플랫폼·인프라 아키텍트, 보안·운영 책임자
지난 3주 동안 이 블로그가 다룬 발표들은 서로 다른 회사의 소식이었지만 같은 방향을 가리킨다. AI 에이전트를 돌리는 인프라에는 서버와 쿠버네티스 위에 최소 네 개의 층이 더 필요하다는 것이다. 이번 주 KubeCon North America와 Commvault SHIFT 2026이 마지막 퍼즐 조각을 놓았다. 이 글은 그 네 겹을 한 장으로 정리하고, 어디가 이미 제품이고 어디가 아직 계획인지 구분한다.
첫 번째 겹은 격리다. 에이전트가 파일과 도구를 직접 다루기 시작하면, 에이전트를 가두는 실행 환경이 필요하다. 레드햇은 KubeCon 첫 주요 세션으로 11월 10일 오전 “Sandbox Your Agents” 기조 발표를 배치했고, 같은 날 엔비디아 OpenShell로 에이전트를 오픈시프트에서 제한하는 시연을 예고했다(레드햇 KubeCon 행사 페이지). 오픈시프트 5에 들어간 레드햇 에이전트 샌드박스는 기술 프리뷰로 보도됐다. 즉, 격리 층은 방향이 정해졌지만 운영에 쓸 수 있는 상태는 아니다. 오픈시프트 5의 GA·기술 프리뷰 구분은 「레드햇 오픈시프트 5 정식 출시」 기사에서 자세히 다뤘다.
두 번째 겹은 추론 경로다. 에이전트가 모델을 호출하는 길목을 표준화하는 작업이다. llm-d는 쿠버네티스 위의 분산 LLM 추론 프레임워크로, IBM 리서치, 레드햇, 구글 클라우드, 코어위브, 엔비디아가 함께 관리하고 있고 10월 20일 1.0이 나왔다(테크타임즈). 1.0은 라우팅, 프리필·디코드 분리, KV 캐시 관리, 흐름 제어, 오토스케일링을 담은 제어부가 운영 수준의 안정성에 도달했다는 선언이다. 여기에 레드햇이 9월 CNCF에 기부한 러스트 기반 AI 게이트웨이 프레임워크 프락시스(Praxis)가 더해졌다. 레드햇은 두 프로젝트를 써서 내부 개발자 작업을 오픈 웨이트 모델로 옮기고 AI 추론 비용을 줄였다고 밝혔다. 감소 폭은 공개되지 않았다. 확인되지 않음.
세 번째 겹은 신원과 권한이다. 지난 호에서 다룬 IBM Agent Identity와 HashiCorp Vault 2.2가 이 층에 해당한다. 에이전트마다 소유자와 위험 등급을 등록하고, 짧게 쓰는 자격증명을 발급하고, 권한을 넘으면 회수한다. 같은 층에서 오픈시프트 5의 MCP 서버도 쿠버네티스 RBAC를 따르는 읽기 전용 기본 설정이라고 레드햇 블로그가 설명한다. 다만 이 설명은 블로그 기준이고 MCP 서버의 현재 출시 상태는 문서 간 표시가 달라 확인되지 않음.
네 번째 겹은 복구다. 이 층은 가장 늦게 눈에 띄지만 가장 현실적이다. 에이전트가 설정을 바꾸거나 데이터를 지웠을 때 되돌릴 수단이 없으면 앞의 세 겹은 사고 후에 아무 소용이 없다. Commvault는 SHIFT 2026에서 AgentRecover의 새 기능을 내놓았다. 에이전트 활동을 감사하고, 에이전트를 복원하고, 에이전트가 건드린 데이터와 시스템을 되돌린다는 것이다. 지원 대상으로 Amazon Bedrock AgentCore와 Microsoft Foundry가 명시됐다. 출시 시점과 가격은 공개 페이지에 없다. 확인되지 않음.
| 층 | 대표 발표 | 상태 |
|---|---|---|
| 격리 | 레드햇 에이전트 샌드박스, 엔비디아 OpenShell | 기술 프리뷰(보도 기준) |
| 추론 경로 | llm-d 1.0, 프락시스(CNCF) | llm-d 1.0 출시, 프락시스는 오픈소스 공개 |
| 신원·권한 | IBM Agent Identity, Vault 2.2, 오픈시프트 MCP 서버 | IBM GA, MCP 서버는 상태 확인 필요 |
| 복구 | Commvault AgentRecover | 출시 일정 확인되지 않음 |
이 표에서 읽어야 할 것은 층마다 성숙도가 다르다는 점이다. 신원과 추론 경로는 이미 제품이 있고, 격리와 복구는 아직 발표와 시연 단계에 가깝다. 한 벤더가 네 겹을 모두 파는 구조도 아니다. 그러므로 CIO가 먼저 정할 것은 제품이 아니라 책임의 경계다. 격리는 플랫폼 팀, 신원은 보안 팀, 추론 경로는 AI 플랫폼 팀, 복구는 백업·DR 팀이 맡는다고 보면, 네 팀이 같은 에이전트 목록을 보고 있는지부터 점검해야 한다. 이 책임 분담은 필자의 제안이며 확인되지 않음.
국내에서는 에이전트를 도입하는 속도에 비해 이 네 겹의 점검 체계가 뒤처질 가능성이 크다. 시스코 코리아 조사에서 국내 기업의 AI 보안 준비도가 58점으로 나온 것이 간접 근거다. 다만 이 네 겹 구조가 국내 사업자의 실제 도입 단계와 얼마나 맞는지는 별도 조사가 필요하며 확인되지 않음.
함께 읽기
- AI 에이전트에 신분증을 발급하는 시대: IBM의 에이전트 신원 발표: 세 번째 겹의 상세
- 가상화·클라우드·AI 전환의 다음 질문은 ‘어디서 돌리나’가 아니라 ‘누가 통제하나’다: 이 시리즈의 출발점
- “에이전트용 쿠버네티스”가 나왔다: 에이전트 제어 평면의 첫 발표
- 시스코가 한국에 던진 AI 보안 진단: 방어 역량 58점: 국내 준비도 비교 자료
출처
- Red Hat, “Red Hat at KubeCon + CloudNativeCon North America 2026” 행사 페이지
- Tech Times, KubeCon NA 2026 개막 기사(2026.11.9), OpenShift 5 기사(2026.11.10)
- SMB Tech, 레드햇 KubeCon 발표 정리(2026.11.10)
- Commvault 블로그, “Commvault Announces AI Recovery for AI Vulnerabilities” (2026.11.9)
- IBM TechXchange 2026 관련 보도(앞선 호 w8_1 출처 참조)