Cisco Cloud Control 공개, Codex로 만드는 네트워크 운영 앱

Cisco가 2026년 6월 2일 Las Vegas의 Cisco Live US에서 Cisco Cloud Control을 공개했습니다. Cisco 공식 발표는 이 제품을 네트워크, 보안, compute, observability, collaboration을 한 환경에 모으는 관리면으로 설명합니다. 이 발표가 devlery 독자에게 걸리는 지점은 Cloud Control Studio 안에 들어가는 App Builder입니다. Cisco는 App Builder가 OpenAI Codex를 직접 내장해 자연어 prompt에서 Cloud Control용 앱과 워크플로를 만들고, 그 결과물을 Cloud Control Marketplace로 발행할 수 있다고 밝혔습니다.

이 소식은 또 하나의 엔터프라이즈 대시보드 발표로 읽으면 놓치는 부분이 많습니다. Cisco의 설명에서 Codex는 IDE나 터미널에서 코드를 만드는 도구가 아니라, 인프라 운영 플랫폼 안에서 앱을 생성하는 엔진으로 들어갑니다. Cisco App Builder 블로그는 이를 “born deployed”라고 표현했습니다. 사용자가 설명을 넣으면 앱이 만들어지고, Cisco identity, service, hosting, distribution이 처음부터 붙는다는 뜻입니다.

Cloud Control은 2026년 6월 2일 미국에서 Controlled Availability로 시작했습니다. Cisco는 Global Availability가 뒤따를 것이라고만 적었고, 모든 기능의 일반 제공일을 한 번에 공개하지는 않았습니다. 같은 발표에서 Cloud Control은 AWS, Linear, Microsoft, PagerDuty, ServiceNow, Slack, Google Cloud와 연결되는 ecosystem을 언급했습니다. Google Cloud 항목에는 Wiz가 포함된다고 적혀 있습니다. 개발자가 봐야 할 수치는 Agent Builder 쪽입니다. Cisco는 고객이 native connector나 open Model Context Protocol, 즉 MCP를 통해 50개 이상 third-party platform과 tool에 연결할 수 있다고 설명했습니다.

Cloud Control Studio는 두 갈래로 나뉩니다. Agent Builder는 운영 정책과 workflow에 맞춘 agent를 만드는 환경입니다. App Builder는 Cloud Control 안에서 실행될 앱과 workflow를 만드는 환경입니다. App Builder 설명에는 OpenAI Codex가 명시됩니다. Cisco는 App Builder로 만든 것과 Cisco ecosystem의 agent와 app이 Cloud Control Marketplace에 올라갈 수 있다고 밝혔습니다. 이 구조에서는 코딩 에이전트가 만든 결과물을 별도 저장소, 별도 배포 파이프라인, 별도 인증 설정으로 옮기는 과정이 줄어듭니다.

Cisco가 이런 방향을 잡은 이유는 Cloud Control 발표의 보안 문단에 나옵니다. 발표문은 AI가 취약점 발견과 exploit 사이의 시간을 “weeks to minutes”로 줄인다고 설명했습니다. 이 표현은 마케팅 문장처럼 보일 수 있지만, Cisco가 같이 내놓은 기능 목록은 운영 절차를 기계 속도에 맞추려는 쪽에 가깝습니다. Cloud Control은 사람과 agent가 같은 telemetry를 보고, 같은 action surface에서 조치하며, 사람이 통제권을 갖는 구조를 목표로 합니다.

Cisco의 The Agentic Workplace Runs on Cisco 글은 이 운영 루프를 더 구체적으로 쪼갭니다. Cisco가 공개한 Autonomous Agentic Loop는 장애 신호 감지, 원인 진단, 문제 remediation, 변경 검증, fix 배포를 단계로 둡니다. Agentic Actions for networking은 2026년 6월 beta로 제공됩니다. 이 기능은 incident, recommendation, reasoning, evidence, confidence score, risk score, next steps를 보여주는 mission control이라고 설명됐습니다. Expanded Experience Metrics와 Deep Reasoning도 2026년 6월 beta입니다. Digital Twin은 2026년 7월 alpha로 예고됐고, device, connectivity, topology, configuration을 에뮬레이션해 production 변경 전에 검증하는 용도입니다.

개발자 입장에서 이 발표의 실무 질문은 “Codex가 코드를 얼마나 잘 쓰는가”보다 “운영 앱을 누가 승인하고 어디에 배포하는가”입니다. App Builder는 Codex SDK를 기반으로 Cloud Control 안에서 작동합니다. Cisco 블로그는 코딩 에이전트만 단독으로 쓰면 Cisco identity, service, hosting, distribution을 모른다고 지적했습니다. App Builder 안에서는 그 배경이 이미 붙어 있으므로 결과물이 “끝내야 할 프로젝트”가 아니라 “작동하는 앱”에 가깝다는 주장입니다.

이 주장은 Cisco 내부 사례와 연결됩니다. OpenAI가 2026년 1월 공개한 Cisco 사례는 Cisco가 Codex의 초기 design partner였고, AI Defense 개발과 여러 엔지니어링 workflow에 Codex를 썼다고 적었습니다. OpenAI 글에 따르면 Cisco는 15개 이상 연결 저장소의 build log와 dependency graph를 Codex로 분석해 약 20% build time reduction과 월 1500시간 이상 절감을 얻었다고 밝혔습니다. C/C++ defect remediation에서는 Codex CLI 기반 반복 실행으로 defect resolution throughput이 10-15배 늘었다는 수치도 제시했습니다.

이 내부 사례는 App Builder 발표를 뒷받침하는 근거로 쓰입니다. Cisco는 Codex가 실제 대규모 저장소, compliance, long-running task, 기존 개발 pipeline에서 어떤 제약을 만나는지 OpenAI에 피드백했다고 설명했습니다. App Builder는 그 피드백을 개발 도구 바깥의 운영 제품으로 옮긴 결과에 가깝습니다. 코딩 에이전트가 저장소 안에서 끝나는 것이 아니라, 네트워크 운영자가 쓰는 화면과 workflow를 생성하는 쪽으로 이동합니다.

시장 비교는 GitHub Copilot, Microsoft Foundry, ServiceNow, Google Cloud, AWS 운영 도구와 나뉩니다. GitHub Copilot의 강점은 저장소와 PR workflow입니다. Microsoft Foundry와 Agent 365는 M365, Azure, 보안 stack과 묶입니다. ServiceNow는 ITSM workflow가 중심입니다. Cisco의 차별점은 network device, security enforcement, observability, ThousandEyes, Splunk 자산을 운영 데이터로 잡고 있다는 점입니다. 네트워크와 보안 장비가 실제 조치 지점이 되는 조직에서는 Cloud Control의 권한 모델과 audit trail이 코딩 에이전트 선택만큼 중요해집니다.

보조 보도도 같은 지점을 다르게 해석했습니다. TechTarget은 Cloud Control을 기존에 분리됐던 tool의 convergence로 봤습니다. 기사에는 AI Assistant, telemetry dashboard, third-party agent management, MCP tool, API support가 한 제품군으로 묶였다는 설명이 들어갔습니다. Reuters 계열 보도는 Cisco가 기업이 AI agent를 만들어 IT infrastructure를 보호하도록 하는 software tool을 공개했고, Codex가 Cloud Control platform에 직접 embedded된다고 전했습니다. 이 보도들은 Cisco 발표의 중심이 단일 모델 성능이 아니라 agent 운영 위치라는 점을 확인해줍니다.

보안팀이 읽어야 할 문단도 있습니다. Cisco는 Cloud Control 발표와 함께 Live Protect 확대를 내세웠습니다. 발표 기준 Live Protect는 N9000 series switches에서 제공되고 Nexus One entitlement에 포함됩니다. Cisco는 campus와 branch smart switches, 이후 secure routers로 확대한다고 밝혔습니다. 같은 발표에는 Hybrid Mesh Firewall, AI Defense, Zero Trust for agents, Agentic SOC, Resilient Infrastructure Services, Cisco IQ도 함께 나옵니다. Quantum Ready Assessments는 Cisco IQ를 통해 2026년 7월 Global Availability를 계획합니다.

이 묶음은 개발팀에 부담도 줍니다. App Builder가 앱을 “바로 배포”한다면, 개발팀은 코드 리뷰만으로 충분하지 않습니다. 누가 어떤 Cloud Control data에 접근하는지, 어떤 action을 실행할 수 있는지, Marketplace에 발행된 앱을 어느 조직 단위가 사용할 수 있는지 확인해야 합니다. 자연어 prompt가 앱을 만들었다는 사실은 감사 기준을 낮추지 않습니다. 오히려 prompt, 생성된 code, 연결된 connector, 실행된 action, rollback 경로를 같은 변경 기록 안에 남겨야 합니다.

운영팀에는 다른 부담이 있습니다. Agentic Actions가 confidence score와 risk score를 보여준다고 해도, 점수의 출처와 calibration이 명확해야 합니다. Deep Reasoning이 competing hypotheses와 supporting evidence를 제시한다면, 근거 telemetry가 어떤 제품에서 왔는지와 stale data가 섞였는지 확인할 수 있어야 합니다. Digital Twin이 production 변경 전 검증을 맡는다면, twin이 실제 topology와 configuration drift를 얼마나 반영하는지가 장애 회피의 기준이 됩니다. 이 질문들은 제품 발표 이후 실제 도입 평가에서 빠질 수 없습니다.

개발자에게 가장 직접적인 변화는 내부 도구의 제작 단위입니다. 지금까지 많은 팀은 운영 대시보드나 승인 workflow를 만들 때 Jira, Slack, GitHub, monitoring API, cloud provider SDK를 이어 붙이고, 별도 웹앱을 배포했습니다. Cloud Control App Builder는 이 작업을 Cisco 환경 안에서 시작하게 만듭니다. 네트워크 운영팀이 “outage 중 반복 확인하는 alert, device health, fix action을 한 화면에 묶어 달라”고 설명하면, Codex가 Cloud Control용 앱을 만들고 플랫폼이 identity와 hosting을 처리한다는 약속입니다.

이 약속이 실무에서 통하려면 세 가지 확인이 필요합니다. 첫째, App Builder가 만든 앱의 소스와 변경 이력을 팀이 검토할 수 있어야 합니다. 둘째, Cloud Control Marketplace 발행 전에 권한, data access, action scope를 정책으로 제한할 수 있어야 합니다. 셋째, Codex가 만든 workflow가 외부 connector와 MCP tool을 호출할 때 parameter 수준의 감사가 가능해야 합니다. 최근 MCP 보안 논의에서 tool을 숨기거나 허용하는 수준만으로는 충분하지 않다는 지적이 반복됐습니다. Cisco의 Agent Builder가 50개 이상 연결과 MCP를 전면에 세운 만큼, 이 지점은 제품 평가 항목이 됩니다.

Cloud Control은 아직 모든 기능이 완전히 열린 제품은 아닙니다. Cisco App Builder 글 하단에는 일부 product나 feature가 개발 단계일 수 있고, availability가 조건부일 수 있다는 고지가 있습니다. Controlled Availability와 beta, alpha 일정이 섞여 있으므로 구매나 아키텍처 결정에서는 기능별 제공 상태를 따로 확인해야 합니다. 발표 당일 바로 쓸 수 있는 범위, 2026년 6월 beta 범위, 2026년 7월 alpha 범위를 섞어 읽으면 도입 기대치가 어긋납니다.

그래도 이번 발표의 방향은 분명합니다. 코딩 에이전트 경쟁은 IDE 안의 자동완성이나 PR 생성에서 멈추지 않습니다. Cisco는 Codex를 네트워크와 보안 운영 제품의 앱 생성 엔진으로 넣었습니다. 이 선택은 “에이전트를 어디서 실행할 것인가”라는 질문을 “에이전트 산출물이 어느 운영 시스템 안에서 승인되고 배포될 것인가”로 바꿉니다. AI 개발팀과 플랫폼팀은 모델 이름뿐 아니라 identity, connector, marketplace, audit, rollback을 함께 비교해야 합니다.

한국 독자에게 이 발표가 의미 있는 이유는 Cisco가 가진 설치 기반 때문입니다. 많은 기업의 네트워크와 보안 운영은 이미 Cisco 장비, Splunk, ThousandEyes, Webex, ServiceNow 같은 도구와 얽혀 있습니다. 이 환경에 Codex가 들어가면, AI 코딩 도구는 개발자 개인의 생산성 도구가 아니라 운영 조직의 변경 생산 도구가 됩니다. 성공 조건은 생성 속도가 아니라, 운영 권한과 검증 절차가 생성 속도를 따라갈 수 있는지에 있습니다.