Red Hat AI 3.4 업데이트: AgentOps, MCP Gateway, Eval Hub가 중요한 이유

 

Red Hat AI 3.4 업데이트: AgentOps, MCP Gateway, Eval Hub가 중요한 이유

모델 서빙 다음에는 평가 기록, 도구 권한, 추적성이 남습니다.

 

Red Hat AI 3.4 업데이트 한 줄 요약

 

Red Hat AI 3.4 AgentOps MCP gateway eval hub 업데이트는 모델을 띄우는 문제보다 에이전트가 어떤 도구를 호출했고, 어떤 평가를 통과했으며, 그 기록을 어떻게 남길지를 다루는 발표입니다.

Red Hat은 2026년 5월 12일 Red Hat Summit 주간 흐름 속에서 Red Hat AI 3.4 관련 업데이트를 공개했습니다. 2026년 5월 15일 기준으로 보면 공식 블로그가 나온 지 72시간 안팎의 발표라, 오늘 다루는 이유도 '새 기능 나열'보다는 이번 주 엔터프라이즈 AI 운영 방향을 보여주는 신호에 있습니다.

공식 블로그와 보도자료는 Red Hat AI 3.4를 2026년 5월 말 제공 예정으로 설명합니다. 그래서 이 글에서도 모든 고객에게 이미 완전한 운영 배포가 끝났다고 말하지 않습니다. 실제로 확인할 부분은 기능 이름보다 제공 시점, 기능 성숙도, 그리고 운영팀이 책임져야 할 범위입니다.

제가 보기에는 실무 포인트가 세 갈래로 나뉩니다. 추론 속도와 하드웨어 선택지 같은 모델 서빙 개선이 있고, MLflow 기반 추적성, EvalHub, Garak red teaming처럼 평가와 안전성 흐름이 제품 안으로 들어옵니다. 여기에 MCP catalog, MCP lifecycle operator, MCP gateway가 붙으면서 에이전트의 외부 도구 호출을 중앙에서 다루려는 방향이 보입니다.

그래서 Red Hat AI 3.4 AgentOps MCP gateway eval hub라는 긴 키워드는 단순한 기능 묶음이 아닙니다. 기업 AI가 RAG 데모나 챗봇 배포를 지나, 누가 어떤 도구에 접근했는지와 어떤 변경이 배포 기준을 통과했는지를 설명해야 하는 단계로 이동했다는 신호에 가깝습니다.

 

 

발표 타임라인: 2026년 5월 12일부터 문서 공개까지

 

이 흐름은 하루짜리 제품 블로그 하나로 끝나지 않고 Red Hat Summit 발표, 공식 제품 블로그, MCP catalog 글, EvalHub 기술 글, OpenShift AI 3.4 문서로 이어집니다.

2026년 5월 12일에는 Red Hat Newsroom의 공식 발표와 Red Hat AI 3.4 제품 블로그가 함께 나왔습니다. 같은 날짜에 MCP catalog를 설명하는 글, EvalHub의 Kubernetes 기반 구조를 다룬 Red Hat Developer 글도 공개됐습니다.

이틀 뒤인 2026년 5월 14일에는 OpenShift AI 3.4의 Models-as-a-Service와 AutoML, AutoRAG 관련 글이 이어졌습니다. 2026년 5월 15일 기준 문서에서는 OpenShift AI Self-Managed 3.4 release notes도 확인됩니다. 다만 문서가 보인다는 사실과 모든 기능을 일반 운영 환경에 바로 넣어도 된다는 말은 다릅니다.

한국 사용자 입장에서는 날짜만큼 기능 성숙도를 같이 봐야 합니다. 같은 Red Hat AI 3.4 안에서도 GA, TP, DP가 섞여 있기 때문입니다. 운영팀이 먼저 물을 질문은 '이 기능이 있나'보다 '어느 환경에서, 어떤 책임 범위로 써도 되나'에 가깝습니다.

 

무엇이 바뀌었나: AgentOps, MCP, 평가, 추론 최적화

 

Red Hat AI 3.4의 변화는 추론 성능, 에이전트 추적성, MCP 도구 통제, EvalHub 평가, red teaming, AutoRAG 실험 지원으로 나눠 읽으면 덜 헷갈립니다.

공식 발표에서 눈에 띄는 기술 항목은 speculative decoding, NVIDIA Blackwell과 AMD MI325X 지원, MLflow 기반 실험 추적, AutoRAG, EvalHub, agent traceability, MCP catalog와 MCP gateway, Garak 기반 red teaming입니다.

여기서 볼 부분은 성숙도입니다. Red Hat이 표시한 기준을 보면 agent traceability via MLflow는 GA로 언급되지만, prompt management와 MCP gateway는 TP입니다. identity management와 Kagenti lifecycle management, MCP catalog, MCP lifecycle operator는 DP로 분류됩니다.

영역	기능	상태 해석
AgentOps	MLflow 기반 agent traceability	GA로 소개된 추적성 축
AgentOps	prompt management	TP, 운영 적용 전 검증 필요
AgentOps	SPIFFE/SPIRE 기반 identity management	DP, 실험적 검토 범위
MCP	MCP catalog, lifecycle operator	DP, 생태계와 배포 흐름 검토용
MCP	MCP gateway	TP, 중앙 연결 통제의 초기 운영 검토 대상
평가/안전	EvalHub, Garak red teaming	평가와 안전성 자동화 흐름의 주요 축

Red Hat AI 3.4 AgentOps MCP gateway eval hub를 검색하는 독자라면 이 표부터 보는 편이 낫습니다. 발표의 크기보다 중요한 것은 어떤 항목을 운영 체크리스트에 넣고, 어떤 항목은 PoC나 샌드박스에 남겨둘지 구분하는 일입니다.

 

 

왜 중요한가: AI 운영의 초점이 모델에서 에이전트 통제로 이동합니다

 

기업 AI의 병목은 이제 모델 호출 자체보다 도구 호출 권한, 평가 기록, 장애 추적, 비용과 사용량 관리로 옮겨가고 있습니다.

초기 AI 서비스는 '어떤 모델을 쓸 것인가'가 중심이었습니다. 하지만 내부 업무 에이전트가 파일, 티켓, 코드 저장소, 데이터베이스, SaaS API를 호출하기 시작하면 질문이 달라집니다. 누가 어떤 도구를 허용했는지, 실패한 호출은 어디서 확인하는지, 평가를 통과하지 못한 프롬프트가 배포되지 않도록 막을 수 있는지가 중요해집니다.

MCP gateway는 이 문제의 한 부분을 맡습니다. 문서상 MCP gateway는 여러 MCP server를 하나의 접근 지점 뒤에 모으고, 인증과 도구 단위 접근 제어, 관측성을 제공하는 레이어로 설명됩니다. 다만 gateway가 있다고 외부 도구가 자동으로 안전해지는 것은 아닙니다. gateway는 통제 지점이고, 보안은 AuthPolicy, Secret, 라우팅 정책, 로그, 감사 절차가 함께 있어야 맞물립니다.

EvalHub는 다른 축입니다. 평가 스크립트를 사람이 노트북에서 한 번 돌리는 방식은 변경 추적에 약합니다. EvalHub처럼 Kubernetes 작업, PostgreSQL 상태, MLflow 기록, 여러 평가 executor를 묶는 구조는 모델 버전, 프롬프트 버전, 데이터셋 버전, evaluator 버전을 남기는 쪽에 가깝습니다.

이 발표의 무게는 '더 똑똑한 모델'보다 '더 설명 가능한 운영'에 있습니다. 규제 산업, 내부 AI 플랫폼팀, 하이브리드 클라우드 조직에는 이 차이가 작지 않습니다.

 

 

도입 시뮬레이션: 설치 첫 테스트부터 운영 보류 조건까지

 

첫 테스트는 운영 클러스터가 아니라 비프로덕션 OpenShift AI 3.4 호환 환경에서 read-only MCP server 하나를 MCP gateway 뒤에 붙이고, 제한된 에이전트 호출과 로그를 확인하는 방식이 현실적입니다.

실제로 확인할 부분은 'MCP가 된다'가 아닙니다. ServiceEntry, DestinationRule, HTTPRoute, Secret, AuthPolicy, MCPServerRegistration 같은 객체가 기대한 대로 연결되고, `oc get mcpsr -A`에서 등록 상태가 보이며, gateway 로그와 trace에 어떤 도구가 호출됐는지 남는지를 봐야 합니다.

작은 테스트 흐름은 이렇습니다. 먼저 OpenShift AI 3.4 호환 test cluster와 Red Hat Connectivity Link MCP gateway 문서를 전제로 합니다. 그다음 파일 조회, 이슈 조회, 내부 문서 검색처럼 쓰기 권한이 없는 MCP server를 하나 고릅니다. MCP catalog 또는 lifecycle operator 경로로 배포 흐름을 검토하고, MCP gateway 뒤에 연결한 뒤 특정 namespace나 service account만 호출할 수 있게 AuthPolicy를 둡니다.

그다음 gen AI studio나 내부 에이전트 클라이언트에서 읽기 전용 질문 하나를 던져봅니다. 성공 여부만 보면 부족합니다. `service.name="mcp-gateway"`, `mcp.session.id`, tool-call metric, 실패 trace가 남아야 운영 관측성이 생깁니다.

Red Hat AI 3.4 AgentOps MCP gateway eval hub를 실무 도입 후보로 보는 팀이라면, 첫 주에는 기능 데모보다 '도구 호출 감사 로그를 팀이 이해할 수 있는가'를 보는 편이 낫습니다. 에이전트가 외부 도구를 쓰는 순간부터 AI 프로젝트는 모델팀만의 일이 아니라 플랫폼, 보안, 데이터 거버넌스의 공동 작업이 됩니다.

 

EvalHub는 평가를 일회성 스크립트에서 운영 게이트로 바꿉니다

 

EvalHub는 모델, RAG, 프롬프트, 에이전트 변경을 배포 전에 반복 평가하고 결과를 추적하기 위한 control plane으로 이해하는 편이 좋습니다.

RAG나 에이전트 프로젝트에서 자주 놓치는 부분은 평가 기록입니다. 어떤 데이터셋으로, 어떤 프롬프트를, 어떤 모델 버전에 대해, 어떤 evaluator로 돌렸는지 남지 않으면 다음 변경에서 비교가 어렵습니다.

EvalHub 관련 Red Hat Developer 글은 이를 Kubernetes 작업과 평가 executor, PostgreSQL 상태 관리, MLflow 기록으로 다룹니다. lm-evaluation-harness, LightEval, GuideLLM, Garak, custom BYOF framework 같은 도구가 언급되는 이유도 여기에 있습니다. 평가 도구 하나를 고르는 발표라기보다 여러 평가 실행 방식을 플랫폼 안에서 반복 가능하게 만들려는 쪽입니다.

한국 기업에서 내부 RAG를 운영한다면 최소 필드는 `dataset_version`, `model_version`, `prompt_version`, `retriever_config`, `evaluator_version`, `mlflow_run_id`, `approval_status` 정도가 됩니다. 이 정도가 남아야 '지난주보다 좋아졌다'는 말을 팀 밖의 사람에게 설명할 근거가 생깁니다.

> 배포 전 평가는 점수 하나가 아니라 변경 이력의 일부가 되어야 합니다.

이 관점에서 Red Hat AI 3.4 AgentOps MCP gateway eval hub 업데이트는 평가와 에이전트 도구 통제를 따로 보지 말라는 신호입니다. 에이전트가 더 많은 도구를 쓸수록, 평가와 추적은 더 운영적인 문제가 됩니다.

 

 

 

주의할 점: TP/DP 기능, 보안 과장, AutoRAG 오해

 

Red Hat AI 3.4에서 가장 조심할 부분은 TP/DP 기능을 운영 안정 기능처럼 과장하거나, MCP gateway를 모든 도구 보안의 자동 해결책처럼 보는 것입니다.

MCP gateway는 중요하지만 만능 보안 장치가 아닙니다. 연결 지점을 중앙화하고 접근 제어와 관측성을 붙이는 데 의미가 있지만, 실제 위험은 도구별 권한, secret 관리, 외부 API의 데이터 보존 정책, 에이전트 프롬프트 주입 대응, 감사 로그 보관 기간에서 생깁니다.

AutoRAG도 비슷합니다. Red Hat은 AutoRAG를 parsing, chunking, query expansion, retrieval strategy, reranking, end-to-end evaluation을 자동화하는 기술 프리뷰로 설명합니다. 하지만 데이터 품질, 평가셋 설계, 보안 정책, 운영 비용을 대신 책임지지는 않습니다.

운영 보류 조건은 분명합니다. MCP server가 쓰기 권한을 갖는데 AuthPolicy가 충분히 검토되지 않았다면 보류해야 합니다. EvalHub 결과가 MLflow run과 승인 이력으로 남지 않는다면 배포 게이트로 보기 어렵습니다. TP/DP 기능을 규제 산업의 핵심 운영 경로에 바로 넣으려는 계획이라면 별도 리스크 리뷰가 필요합니다.

이 업데이트는 '지금 당장 모든 것을 바꾸라'는 신호라기보다, 2026년에 AI 플랫폼팀이 갖춰야 할 운영 언어를 보여주는 체크리스트에 가깝습니다.

 

실무 takeaway: OpenShift 사용자와 비사용자가 다르게 읽어야 합니다

 

OpenShift AI를 쓰는 팀은 기능 검증 대상으로, 쓰지 않는 팀은 AgentOps와 MCP 거버넌스 설계 패턴으로 읽는 것이 좋습니다.

OpenShift AI를 이미 쓰는 플랫폼팀이라면 Red Hat AI 3.4는 구체적인 검토 대상입니다. 비프로덕션 클러스터에서 MCP gateway, EvalHub, MLflow 추적성, Models-as-a-Service의 token rate limiting과 API key self-service를 나눠 확인할 수 있습니다.

반대로 OpenShift를 쓰지 않는 팀이라도 배울 점은 있습니다. 에이전트가 외부 도구를 호출하는 구조에서는 catalog, lifecycle, gateway, observability가 분리되어야 합니다. 평가도 notebook 결과가 아니라 배포 승인 기록으로 남아야 합니다.

Red Hat AI 3.4 AgentOps MCP gateway eval hub를 오늘의 AI 업데이트로 볼 이유는 여기에 있습니다. 신제품 이름보다 중요한 것은 엔터프라이즈 AI가 '모델 성능'에서 '운영 증명'으로 이동하고 있다는 점입니다.

 

자주 묻는 질문

 

Q. Red Hat AI 3.4는 무엇이 바뀐 업데이트입니까?
A. Red Hat AI 3.4는 추론 최적화만이 아니라 AgentOps, MCP gateway, eval hub, MLflow 추적성, Garak red teaming을 함께 묶은 엔터프라이즈 AI 운영 업데이트입니다. 공식 발표 기준 공개일은 2026년 5월 12일이며, Red Hat은 2026년 5월 말 제공 예정이라고 설명했습니다.

Q. AgentOps 기능 중 바로 운영에 넣어도 되는 항목은 무엇입니까?
A. 공식 블로그의 성숙도 표기를 기준으로 agent traceability via MLflow는 GA로 소개됐지만, prompt management는 TP, identity management와 Kagenti lifecycle management는 DP입니다. 따라서 운영 적용 전에는 기능별 상태를 분리해 검토해야 합니다.

Q. MCP catalog, MCP lifecycle operator, MCP gateway는 각각 무엇을 맡습니까?
A. MCP catalog는 MCP server를 발견하고 고르는 입구에 가깝고, MCP lifecycle operator는 배포와 생명주기 관리를 맡습니다. MCP gateway는 여러 MCP server 접근을 중앙 엔드포인트와 정책, 관측성 뒤에 두는 역할로 이해하면 됩니다.

Q. MCP gateway가 있으면 에이전트 보안이 자동으로 해결됩니까?
A. 아닙니다. MCP gateway는 인증, 도구 단위 접근 제어, 라우팅, 관측성을 제공하는 통제 지점입니다. 실제 보안은 AuthPolicy, Secret 관리, tool permission, 로그 감사, prompt injection 테스트를 함께 설계해야 합니다.

Q. Eval hub는 기존 평가 스크립트와 무엇이 다릅니까?
A. EvalHub는 평가를 개인 노트북이나 일회성 스크립트가 아니라 Kubernetes 기반 작업, PostgreSQL 상태, MLflow 기록, 여러 executor로 관리하는 control plane에 가깝습니다. 모델, 프롬프트, 데이터셋, evaluator 버전을 남겨 배포 전 회귀 평가로 쓰는 데 의미가 있습니다.

Q. OpenShift를 쓰지 않는 팀도 이 업데이트를 읽을 필요가 있습니까?
A. 제품 도입 대상은 아닐 수 있지만 운영 패턴은 참고할 만합니다. 에이전트 도구 호출에는 catalog, lifecycle, gateway, observability가 필요하고, RAG와 에이전트 변경에는 반복 가능한 eval hub 방식의 평가 게이트가 필요하다는 점이 이번 업데이트의 실무 메시지입니다.

함께 읽으면 좋은 글

 

• Claude Code Agent View와 /goal: 코딩 에이전트가 '끝날 때까지' 일하는 방식 — AI UPDATES
• Claude for Legal 업데이트: 법률 AI가 플러그인과 MCP로 바뀌는 이유 — AI UPDATES
• Bing Copilot Answer API 등장: AI 검색 결과를 JSON으로 분석하는 방법 — AI UPDATES

참조 링크

 

• From inference to agents: Scaling AI in the enterprise with Red Hat AI 3.4 — Red Hat AI 3.4의 AgentOps, MCP, EvalHub, maturity label, 제공 예정 시점을 확인한 핵심 공식 업데이트
• Red Hat Unites Builders and Operators on the Agentic Future with Major Advancements to Red Hat AI — 2026년 5월 12일 발표일, Red Hat Summit 맥락, speculative decoding과 하드웨어 지원을 확인한 공식 보도자료
• The MCP catalog is here: Discover, deploy, and connect on Red Hat OpenShift AI — MCP catalog, lifecycle operator, MCP gateway, gen AI studio 연결 흐름을 설명한 공식 업데이트
• How EvalHub manages two-layer Kubernetes control planes — EvalHub의 Kubernetes, PostgreSQL, MLflow, evaluation executor 구조를 확인한 기술 설명
• Red Hat OpenShift AI Self-Managed 3.4 Release Notes — OpenShift AI 3.4 기능 상태와 release-note 수준 세부 항목을 대조한 공식 문서
• MCP gateway — MCP gateway의 단일 엔드포인트, 접근 제어, 보안, 관측성 역할을 확인한 문서
• Registering external MCP servers — ServiceEntry, DestinationRule, HTTPRoute, AuthPolicy, MCPServerRegistration, oc get mcpsr -A 등 운영 객체와 점검 명령 근거
• Observing MCP gateway connections — MCP gateway logs, traces, tool-call metrics, mcp.session.id 관측성 설명을 확인한 문서
• Scaling enterprise AI: Delivering Models-as-a-Service with Red Hat OpenShift AI 3.4 — API governance, token rate limiting, API key self-service, token consumption visibility를 확인한 보조 공식 업데이트
• Introducing AutoML and AutoRAG: Guided experience for AI engineers in Red Hat OpenShift AI — AutoRAG의 기술 프리뷰 성격과 자동화 범위를 확인한 공식 업데이트
• kubernetes-sigs/mcp-lifecycle-operator — MCP lifecycle operator 생태계와 구현 방향을 참고하기 위한 보조 GitHub 출처
• Kuadrant/mcp-gateway — MCP gateway 관련 오픈소스 구현 흐름을 이해하기 위한 보조 GitHub 출처