AX와 쿠버네티스는 어떤 관계인가요? 구글의 새로운 AI 에이전트 기반 시설은 어떤 문제를 해결하나요

장시간 에이전트 작업을 기존 쿠버네티스 환경에 붙이려는데, 실행과 복구를 어디서 맡겨야 할지 막막하신가요?

결론부터 말하면 AX는 쿠버네티스를 대체하지 않습니다. 에이전트 작업의 선언과 실행을 조율하는 계층으로 검토하고, 실제 배포 환경과 기반 자원은 쿠버네티스 등 기존 실행 환경이 맡는다고 구분하세요.

쿠버네티스 클러스터에서 장시간 에이전트 작업을 시험하는 플랫폼 엔지니어라면 AX와 현재 실행 계층의 경계를 판단할 수 있습니다.
에이전트 격리와 복구, 워크스페이스 관리를 맡은 설계자는 필요한 운영 조건을 점검할 수 있습니다.
동기식 호출만 운영한다면 새 실행 계층을 더하지 않아도 되는지 확인할 수 있습니다.

마지막 검토: 2026년 9월 26일. AX의 기능과 배포 전제는 공식 저장소와 배포 안내, 핵심 개념 문서, 쿠버네티스 공식 문서를 기준으로 확인해야 합니다. 프로젝트는 빠르게 바뀔 수 있으므로, 여기서 말하는 설계 방향을 운영 환경에서 검증된 안정성이나 보장된 성능으로 받아들이면 안 됩니다.

구글 AX는 쿠버네티스를 대체하나요?

아닙니다. AX를 쿠버네티스와 같은 클러스터 관리자로 이해하면 역할을 혼동하게 됩니다. AX는 에이전트 작업을 표현하고 실행을 조율하는 층이고, 쿠버네티스는 컨테이너화된 워크로드를 클러스터에서 배포하고 관리하는 기반입니다. AX 저장소와 쿠버네티스 워크로드 컨트롤러 문서를 함께 보면, 두 도구가 같은 층의 대체재가 아니라는 점을 확인할 수 있습니다.

운영 관점에서는 다음처럼 나눠 생각하면 됩니다.

• AX는 에이전트가 수행할 작업과 그 실행에 필요한 맥락을 다루는 후보입니다.
• 쿠버네티스는 노드와 파드 같은 실행 자원, 배포, 네트워크 정책 등 클러스터 운영을 계속 맡습니다.
• 클러스터 배포를 포함한 AX 실행 방식과 선행 조건은 현재 제공되는 공식 매니페스트와 문서에서 확인해야 합니다. 문서에 없는 통합이나 안정성은 있다고 가정하지 마세요.

따라서 이미 쿠버네티스를 운영 중이더라도 AX가 자동으로 필요한 것은 아닙니다. 에이전트 작업의 격리나 재개처럼 기존 애플리케이션 배포만으로 표현하기 불편한 요구가 있는지가 먼저입니다.

에이전트 작업과 쿠버네티스는 어떻게 나뉘나요?

작업별 격리 요구부터 확인하세요

에이전트는 작업에 따라 파일을 다루거나 도구를 실행하고, 외부 네트워크에 접근할 수 있습니다. 모든 작업을 같은 권한과 실행 공간에서 돌리면 파일 접근 범위, 자격 증명 노출, 네트워크 통신 경계를 따로 검토해야 합니다. 격리된 워크스페이스를 선언하고 실행 맥락을 분리하려는 설계는 이런 문제를 다루기 위한 것입니다. AX의 개념 문서는 공식 객체와 역할을 이해하는 출발점이지만, 실제 환경에서 격리가 어떻게 적용되는지는 배포한 뒤 확인해야 합니다.

쿠버네티스 쪽에서는 NetworkPolicy 문서에 정의된 네트워크 정책이 파드 간 통신의 경계를 설정하는 데 쓰입니다. AX의 작업 단위 격리가 이를 대신한다고 단정하지 마세요. 작업마다 사용할 자격 증명, 저장 공간, 네트워크 접근을 누가 만들고 회수하는지 각각 확인해야 합니다.

멈춘 작업을 어떻게 이어갈지 정하세요

장시간 에이전트 작업은 사람의 확인을 기다리거나, 외부 작업이 끝날 때까지 멈춰 있어야 할 수 있습니다. 요청을 받고 응답하는 무상태 서비스와 달리, 이 경우에는 진행 상태와 재개 조건을 다뤄야 합니다. AX가 상태 관리나 복구 흐름을 어떤 방식으로 지원한다고 문서화했는지 확인하되, 그것만으로 장애 후 복구 시간이나 작업 성공률이 보장된다고 해석하지 마세요.

시험 환경에서는 작업을 일시 중지한 뒤 다시 시작하는 경우뿐 아니라, 실행 환경이 사라지거나 접근 권한이 만료되는 경우도 검증하세요. 상태가 어디에 남는지, 재시작 후 무엇이 복원되는지, 중복 실행을 막는 책임은 어디에 있는지가 확인되지 않으면 운영 도입 판단을 미루는 편이 안전합니다.

작업 설정을 반복 가능하게 만드세요

작업, 워크스페이스, 모델 관련 설정을 선언적으로 관리하면 실행 요구를 코드나 관리 가능한 설정으로 검토할 수 있습니다. 팀원마다 수동으로 환경을 준비하는 방식보다 차이를 비교하기 쉽고, 변경 검토나 재현 절차를 만들기에도 유리합니다. 단, 선언형 설정이 있다는 사실만으로 모든 실행 결과가 동일하게 재현되거나 비밀 정보가 안전하게 관리된다는 뜻은 아닙니다.

쿠버네티스의 Deployment 문서는 선언된 상태에 맞춰 워크로드를 관리하는 역할을 설명합니다. AX의 작업 정의는 에이전트 실행 요구를 표현하는 층으로 검토하고, 파드 배포와 클러스터의 원하는 상태를 관리하는 Deployment와 같은 쿠버네티스 객체의 책임은 별도로 남겨 두세요. 설정 예시는 복사하기 전에 공식 저장소의 최신 문서와 대상 버전을 대조해야 합니다.

어떤 에이전트 작업부터 AX를 평가해야 하나요?

다음 조건이 실제로 있다면 제한된 시험을 검토할 이유가 있습니다.

• 작업마다 파일, 도구, 네트워크 접근을 나눠야 합니다.
• 사람의 승인이나 외부 작업을 기다리는 장시간 실행이 있습니다.
• 실행 설정과 워크스페이스를 팀 단위로 관리하고 싶습니다.
• 현재 방식에서 상태 유실, 재시도, 권한 관리 중 어떤 문제가 생기는지 관찰할 수 있습니다.

반대로 간단한 동기식 호출만 필요하거나, 클러스터 운영과 자격 증명 관리를 맡을 인력이 없다면 AX를 서둘러 도입할 이유가 약합니다. 새로운 조율 계층은 학습과 유지보수 항목을 늘립니다. 기능이 빠르게 바뀌는 초기 프로젝트라면 공식 문서의 지원 범위, 배포 방식, 제한 사항을 검토할 담당자도 필요합니다.

기존 쿠버네티스 클러스터에도 AX가 필요한가요?

클러스터가 있다는 이유만으로 AX를 추가할 필요는 없습니다. 먼저 기존 워크로드와 에이전트 작업의 차이를 분명히 하세요. 아래 순서로 확인하면 시험 범위가 불필요하게 커지는 것을 막을 수 있습니다.

• 문제를 기록합니다. 격리, 상태 복구, 설정 반복 중 현재 방식에서 해결되지 않는 항목을 고릅니다. 문제가 관찰되지 않았다면 도입을 보류합니다.
• 공식 전제 조건을 맞춥니다. AX 저장소의 최신 안내에서 요구 환경과 기능 상태를 확인합니다. 현재 클러스터에 필요한 배포 경로나 권한 설정이 맞지 않으면 시험을 진행하지 않습니다.
• 민감 정보와 통신 경계를 설계합니다. 쿠버네티스 Secret 문서를 참고해 자격 증명 저장과 접근 주체를 검토하고, NetworkPolicy 등 기존 네트워크 통제가 AX 작업에도 적용되는지 확인합니다. Secret을 사용한다는 사실만으로 접근 통제가 완성되는 것은 아닙니다.
• 작은 범위에서 작업을 실행합니다. 민감하지 않은 작업 하나로 워크스페이스 준비, 일시 중지, 재개, 실패 시 정리 과정을 확인합니다. 재현하지 못한 동작은 기능으로 간주하지 않습니다.
• 성공 기준과 되돌림 조건을 정합니다. 작업 상태를 추적할 수 있는지, 권한을 필요한 범위로 제한할 수 있는지, 기존 방식으로 복귀할 수 있는지를 기록합니다. 기준을 충족하지 못하면 AX를 제거하고 현행 실행 경로를 유지합니다.

시험 중에는 실행 로그와 담당 주체도 확인하세요. 기반 클러스터, 저장 공간, 신원과 자격 증명, 네트워크 접근, 모니터링은 여전히 팀이 평가해야 합니다. 도구가 작업을 표현해 준다고 해서 운영 책임까지 사라지는 것은 아닙니다. 쿠버네티스 경험이 있는 팀이라도 에이전트 실행 모델에 맞춰 관측과 사고 대응 절차를 따로 검증해야 합니다.

검토 과정에서 배포 전제나 지원 범위를 확인하기 어렵다면 ZavCloud 도움말 센터에서 환경 점검에 필요한 항목을 정리하고, 구체적인 조건은 ZavCloud 문의 안내를 참고해 확인할 수 있습니다.

현재 실행 환경을 그대로 확장하면 클러스터 권한과 에이전트 작업이 뒤섞이거나, 중단된 작업을 수동으로 추적하거나, 설정 차이를 팀이 직접 맞춰야 할 수 있습니다. AX는 이런 요구가 확인된 경우에만 시험할 가치가 있으며, 쿠버네티스 운영을 대신하지 않습니다. 반면 맥 전용 도구나 맥에서의 개발 흐름을 검증해야 하는 일시적 테스트라면 ZavCloud의 맥 미니 대여 환경을 비교할 수 있습니다. 다만 맥 미니는 쿠버네티스 클러스터를 대체하는 수단이 아니므로, AX의 클러스터 배포 검증이 목적이라면 먼저 기존 클러스터에서 격리된 시험을 설계하세요.