SageMaker AI Spaces: EKS 내 IDE 통합으로 GPU 활용률을 높이다

Standalone JupyterHub 구축에 3~5일 걸리던 작업이 SageMaker AI Spaces 애드온을 사용하면 약 5분으로 단축된다. 기존 워크플로에서는 파이프라인이 구동되는 Amazon EKS(Amazon Elastic Kubernetes Service) 클러스터를 떠나 별도의 JupyterHub를 구축하거나 개인 로컬 노트북을 사용해야 했다. 이 과정에서 데이터 사이언티스트는 파이프라인이 의존하던 GPU 노드, 공유 스토리지, AWS IAM(Identity and Access Management) 역할에 접근할 수 없는 제약이 발생했다.

SageMaker AI Spaces는 관리형 JupyterLab과 Code Editor 환경을 EKS 클러스터 내부에 직접 실행하여 이 간극을 제거한다. 사용자는 익숙한 IDE 도구를 사용하면서 클러스터 내부의 컴퓨팅 자원과 보안 설정을 그대로 이어받는다. 또한 파이프라인 실행 환경과 개발 환경이 동일한 EKS 클러스터 내에 존재하므로, 환경 차이로 인한 런타임 오류를 방지하고 모델링과 파이프라인 검증을 동시에 수행할 수 있다.

자원 효율성 면에서는 전용 노트북 플릿을 운영하는 방식보다 GPU 활용률을 최대 30%까지 향상시킨다. 전용 플릿 방식은 개별 사용자를 위해 자원을 미리 할당해 유휴 자원이 많이 발생하지만, EKS 통합 환경은 클러스터의 유연한 스케줄링으로 자원을 분배한다. 이는 상시 가동되는 GPU 환경에서 발생하는 불필요한 비용을 직접적으로 절감하는 결과로 이어진다.

클래식 EC2 노드와 서브넷 태깅: 설치 전 필수 전제 조건

EKS Auto Mode를 비활성화하고 Kubernetes 1.30 이상의 버전에서 클래식 EC2 기반 노드를 구성해야 한다. Helm v3와 kubectl 1.30 이상의 도구가 로컬 환경에 준비되어야 하며, 이는 애드온이 노드 레벨의 세밀한 제어와 특정 런타임 환경을 필요로 하기 때문이다.

네트워크는 2개 이상의 가용 영역(AZ)에 퍼블릭과 프라이빗 서브넷을 모두 가진 VPC(가상 프라이빗 클라우드) 환경이 필요하다. 프라이빗 서브넷에는 NAT 게이트웨이가 연결되어야 하며, 클러스터 엔드포인트 액세스는 퍼블릭과 프라이빗 모두 허용으로 설정한다.

VPC 내의 모든 서브넷에는 적절한 태그 설정이 필수적이다. AWS Load Balancer Controller가 서브넷의 성격을 식별하여 ALB(애플리케이션 로드 밸런서)를 올바른 위치에 배치하기 위함이다. 태그 설정 없이 Spaces 애드온을 설치하면 컨트롤러가 ALB를 프라이빗 서브넷에 배치하여 외부 사용자의 접속이 차단된다.

클러스터 생성 단계에서는 EKS Pod Identity Agent, Amazon EBS CSI Driver, Cert manager, External DNS 애드온을 우선 설치한다. 관리형 노드 그룹은 Amazon Linux 2023 운영체제를 기반으로 하며, 인스턴스 타입은 m5.xlarge 이상의 사양으로 최소 2개의 노드를 구성해 서비스 안정성을 확보한다.

기존 방식과 달라진 지점

인프라 전제 조건이 갖춰지면 Helm을 통해 자동화된 설치 과정을 진행한다. Spaces 애드온은 0.1.4 버전 이상을 설치해야 일반 EKS 클러스터에서 사용할 수 있으며, 이전 버전은 Amazon SageMaker HyperPod만 지원했다. 특히 Spaces UI의 진입점이 되는 ALB를 자동으로 프로비저닝하기 위해 AWS Load Balancer Controller를 먼저 설치해야 한다.

helm install aws-load-balancer-controller

보안 및 인증 체계는 수동 구성에서 서비스 연동 방식으로 변경되었다. ACM(AWS Certificate Manager)으로 TLS 인증서를 발행해 ARN을 확보하고, JWT(JSON Web Token) 암호화를 위해 AWS KMS(Key Management System)에서 전용 암호화 키를 생성한다. 여기에 Spaces 컨트롤러와 인증 미들웨어가 클러스터 외부 리소스에 접근할 수 있도록 전용 IAM 역할과 정책을 연결한다.

이 구성 요소들은 하나의 파이프라인으로 연결된다. ACM 인증서와 KMS 키가 준비된 상태에서 IAM 역할이 부여된 Spaces 애드온이 설치되면, 시스템은 사용자의 요청에 따라 암호화된 토큰이 담긴 단기 URL을 즉시 발행한다. 과거처럼 인증 서버를 별도로 구축하고 로드밸런서 리스너 규칙을 수동으로 수정할 필요 없이 정의된 정책에 따라 인프라가 구성된다. 관련한 EKS의 기본 아키텍처와 상세 설정은 Amazon EKS 공식 페이지에서 확인할 수 있다.

프라이빗 URL과 SSM 터널: 보안 접속 및 VS Code 연동

EKS access entry를 활용해 사용자 권한을 네임스페이스 단위로 제한하여 할당 영역 밖의 리소스 수정을 차단한다. Space Pod는 약 4GB 규모의 SageMaker Distribution 이미지를 기반으로 구동되며, 첫 실행 시 이미지를 풀(pull)하고 SSM(AWS Systems Manager)에 포드를 등록하는 과정까지 약 5분이 소요된다.

브라우저 접속을 위한 Presigned URL은 KMS로 암호화된 JWT를 포함하며 5분의 만료 기간이 설정된다. 이 유효 기간은 토큰 탈취 시 발생할 수 있는 보안 사고의 노출 시간을 제한한다. 아래 명령어로 워크스페이스 연결 URL을 확인할 수 있다.

kubectl get workspace -o jsonpath='{.status.workspaceConnectionUrl}'

지속적인 접속 환경이 필요하다면 VS Code 원격 접속 방식을 사용한다. VS Code는 SSH-over-SSM 연결 방식을 통해 Space Pod에 직접 연결하므로 외부로 노출되는 도메인이나 ALB를 별도로 구성할 필요가 없다. 개발자는 로컬 VS Code의 플러그인과 단축키 설정을 그대로 사용하면서 포드에 할당된 GPU 자원으로 모델을 학습시킨다. 네트워크 경로를 SSM 내부 터널로 한정해 외부 공격 표면을 제거한 구조다.

보안 강화를 위해 컨트롤러가 사용하는 SSM 액션 권한과 인증 미들웨어가 사용하는 KMS 암호화 및 복호화 권한을 두 개의 역할로 분리하는 것이 권장된다. 와일드카드 대신 명시적인 리소스 ARN을 지정해 권한 남용을 막아야 보안 사고 없는 원격 개발 환경을 완성할 수 있다.

기업용 OIDC 인증 도입과 실무적 비용 판단 기준

인증 방식은 OIDC(OpenID Connect) 제공자를 클러스터에 등록하고 Kubernetes RBAC(Role-Based Access Control)를 ID 제공자 그룹에 바인딩하는 구조로 전환된다. ID 제공자가 인증한 그룹 멤버십을 기반으로 Kubernetes가 권한을 부여하므로, 인사 이동이나 팀 변경 시 그룹 설정만으로 즉각적인 접근 제어가 가능하다.

인증 구현 시 Dex 커넥터를 활용해 외부 ID 제공자와 클러스터를 연결한다. Amazon Cognito를 연동할 때는 Cognito의 특정 속성을 `preferred_username`으로 매핑하는 설정이 필수적이다. EKS는 해당 클레임에서 사용자 이름을 읽어오지만 Cognito는 이를 기본으로 발행하지 않기 때문에, 매핑이 누락되면 사용자 식별 오류가 발생한다.

인프라 운영 비용은 인터넷 연결 ALB, EBS 볼륨, EKS 클러스터 기본 유지비로 구성된다. 특히 SSM advanced-instances 티어를 사용하면 Space Pod 하나당 시간당 약 $0.00695의 추가 비용이 발생한다. 이는 Pod 개수와 가동 시간에 비례하므로, 사용자가 노트북을 종료했을 때 리소스가 적절히 회수되는지 확인하는 것이 비용 최적화의 핵심이다. 예산 산정 시 EBS 볼륨 크기와 네트워크 트래픽 비용을 함께 고려해야 한다.

학습과 인터랙티브 작업을 하나의 클러스터로 통합해 GPU 유휴 시간을 줄이고 비용을 절감하는 것이 실무적인 도입 기준이다.