이미 SageMaker HyperPod EKS 클러스터를 운영하는 팀은 개발 환경을 만들고 켜고 끄는 일상 작업을 Studio 화면에서 처리할 수 있습니다. AWS가 안내한 HyperPod Spaces의 Studio 통합입니다. 데이터 과학자는 HyperPod CLI나 kubectl 대신 화면에서 작업합니다. 그에 앞서 관리자가 애드온과 접근 권한을 준비합니다. (AWS 공식 발표)

한눈에 보기

궁금한 점 이번 발표의 핵심
누구에게 유용합니까? HyperPod EKS 클러스터에서 노트북·개발 환경을 함께 운영하는 팀입니다.
무엇이 바뀝니까? Studio에서 Spaces 생성·설정·시작·중지·열기를 처리합니다.
어디로 들어갑니까? Studio의 Compute → HyperPod → 클러스터 → IDE and Notebooks입니다.
어떤 IDE를 씁니까? 브라우저의 JupyterLab·Code Editor 또는 로컬 VS Code 원격 접속입니다.
관리자는 무엇을 준비합니까? Spaces 애드온·EKS 접근 항목·IAM 역할과 필요한 경우 사용자별 ID 전달 설정입니다.
브라우저 접근도 바로 됩니까? Custom install과 로드 밸런서·DNS·인증서 등의 구성이 안내됩니다.
한국에서 쓸 수 있습니까? HyperPod 리전 목록에 서울이 포함됩니다. 이번 Studio 통합의 기능별 롤아웃 범위는 별도 확인 대상입니다.
비용은 얼마입니까? 애드온 자체는 추가 요금이 없고 컴퓨트·저장소·접속 구성 비용은 계속 발생합니다.

기능과 조건은 공식 발표·설치·IDE 문서에 따른 설명입니다. 시작 시간은 AWS가 공개한 구성과 측정값입니다. (공식 발표 · IDE 문서)

HyperPod와 Spaces는 각각 무엇입니까?

HyperPod는 대규모 모델 학습·추론용 컴퓨트 클러스터를 운영하는 SageMaker 기반 인프라입니다. 장애가 난 인스턴스를 감지하고 교체하는 복구 기능을 갖추며, 작업을 배치하는 방식으로 Slurm과 Amazon EKS를 지원합니다. EKS는 Kubernetes 컨테이너 작업을 관리하는 서비스입니다. 이번 안내의 대상은 그중 EKS 클러스터입니다. (HyperPod 개요)

Spaces는 이 클러스터 위에 개발자별 노트북·IDE 작업 공간을 만드는 애드온입니다. 개발 환경이 학습·추론 인프라와 같은 클러스터의 자원을 사용할 수 있어, 코드를 준비하고 시험하는 작업을 그 안에서 이어 가는 용도입니다. 이번 변화는 Spaces 자체를 처음 제공하는 발표보다 기존 Spaces 운영을 Studio 화면에 통합하는 기능에 초점이 있습니다. 관리자는 기존 CLI·Kubernetes 도구를 계속 활용할 수 있고, 사용자는 일상 작업에 화면을 선택할 수 있습니다. (배경과 변경점)

Studio 화면에서 어떤 작업을 합니까?

Studio의 Compute → HyperPod에서 클러스터를 열고 IDE and Notebooks 탭으로 들어갑니다. Spaces 생성 양식에서 컴퓨트, 네임스페이스, 저장소, 이미지와 Task Governance 설정을 선택합니다. 네임스페이스는 팀·작업별 자원과 권한을 나누는 Kubernetes 단위이며, Task Governance는 할당량·대기열·우선순위를 관리하는 기능입니다. 화면에서 환경을 만드는 선택이 실제 클러스터 자원 배분으로 이어집니다. (생성·관리 화면 안내)

목록에는 이름·앱 종류·상태·접근 방식·저장소·GPU·vCPU 할당이 표시됩니다. 검색 가능한 표에서 필요한 Space를 찾고 시작하거나 중지할 수 있습니다. 상태가 Running이 되면 Open으로 브라우저 환경을 열거나 Open in VS Code로 로컬 편집기에 연결합니다. 사용하지 않는 Space를 중지하는 버튼은 개발 환경의 컴퓨트 사용을 줄이는 운영 수단입니다. 클러스터와 저장소가 남아 있는 비용은 아래 요금 절에서 따로 봅니다. (상태와 실행 버튼)

제공 범위와 이용 조건은 무엇입니까?

관리자는 HyperPod 클러스터의 IDE and Notebooks 탭에서 Spaces 애드온을 설치합니다. Quick install은 애드온용 IAM 역할 생성, Systems Manager 역할을 포함한 원격 접근 모드 활성화, 애드온 설치와 Pod Identity 연결을 자동으로 처리하는 경로이고, 브라우저 접근을 활성화하려면 Custom install이 안내됩니다. 설치 문서는 Kubernetes 1.30 이상에서 실행 중인 워커 노드가 있는 활성 HyperPod 클러스터를 전제로 합니다. Pod Identity Agent·인증서 관리·EBS CSI 드라이버 등 의존성도 문서에서 확인할 수 있습니다. (애드온 설치 문서)

데이터 과학자가 쓰는 IAM 역할에는 EKS 접근 항목을 구성하고, 발표가 안내하는 AmazonSagemakerHyperpodSpacePolicy, AmazonSagemakerHyperpodUserClusterPolicy, AmazonSagemakerHyperpodSpaceTemplatePolicy 세 관리형 정책을 연결합니다. 이 준비가 끝나면 데이터 과학자가 자신의 환경을 생성하고 열 수 있습니다. 팀별 템플릿을 만들면 이미지·컴퓨트·저장소·초기화 스크립트의 기본값을 공유할 수 있어 매번 같은 설정을 입력하는 수고를 줄입니다. (권한과 템플릿 안내)

통합 이전에 만든 Studio 도메인은 사용자별 ID 전달을 켜는 설정이 필요할 수 있습니다. 발표의 설정 이름은 StudioWebPortalSettings.ExecutionRoleSessionNameMode이고 값은 USER_IDENTITY입니다. 각 사용자의 생성·중지·삭제 작업을 EKS 접근 항목과 CloudTrail에서 사용자 프로필에 연결하며 Space의 소유권·공유 구분에도 사용합니다. AWS 안내는 실행 중인 앱은 그대로 유지되고 사용자는 다음 로그인에서 새 설정을 받는다고 설명합니다. (기존 도메인 설정)

한국 적용에서 확인된 것은 HyperPod 공식 리전 목록의 서울 ap-northeast-2 포함입니다. 발표 글은 이번 Studio 통합을 사용할 수 있는 리전을 별도로 열거하지 않았습니다. 서울 HyperPod를 운영하는 팀은 클러스터의 탭·애드온 상태와 도메인 설정을 확인하는 방식으로 접근할 수 있습니다. HyperPod 서비스의 리전 지원과 새 기능의 계정별 제공 상태는 구분해 읽을 항목입니다. (공식 리전 목록 · Studio 통합 발표)

브라우저와 로컬 VS Code 연결은 무엇이 다릅니까?

브라우저의 JupyterLab은 노트북·커널·터미널·파일 탐색기 중심의 환경입니다. 작업은 연결된 EBS 볼륨에 보관돼 Space를 중지했다가 다시 열어 이어 갈 수 있다고 안내합니다. Code Editor는 VS Code 스타일의 웹 IDE로 코드 편집·터미널·확장·Git 작업을 지원하고 클러스터 파일 시스템과 마운트된 FSx에 접근합니다. 노트북 중심 실험과 코드 저장소 중심 개발에서 익숙한 도구를 선택할 수 있습니다. (IDE별 기능)

브라우저 접속 구성에는 AWS Load Balancer Controller, Route 53 호스팅 영역과 DNS, ACM 인증서, 토큰 서명용 KMS 비대칭 키 등이 안내됩니다. 인증서는 Space별 주소를 위한 와일드카드 하위 도메인도 포함하는 조건입니다. 사용자 도메인을 쓰면 Route 53 레코드를 자동 관리하는 External DNS 애드온도 필요합니다. 애드온이 만드는 웹 UI용 로드 밸런서는 기본값이 인터넷에 공개되는 internet-facing이며, 사내망에서만 열려면 설정에서 scheme을 internal로 바꿉니다. 보안 검토가 필요한 팀은 이 기본값을 설치 전에 확인해야 합니다. 사용자는 Studio에서 접속하지만 주소·인증·네트워크 준비는 관리자가 맡습니다. (Custom install의 웹 접근 조건)

로컬 VS Code는 SSH-over-SSM 터널로 Space에 연결합니다. 발표는 SSH 키 관리나 22번 포트 노출 없이 연결하는 경로로 소개합니다. 로컬 확장·테마·단축키를 유지하고 코드는 HyperPod 컴퓨트에서 실행합니다. AWS Toolkit에서도 SageMaker AI > HyperPod의 Spaces를 보고 시작·중지·연결할 수 있습니다. 웹 접근용 DNS 구성과 원격 IDE용 SSM 구성을 각각 준비하는 이유입니다. (원격 IDE 안내)

시작 시간을 줄이려면 어떤 선택이 있습니까?

AWS는 Karpenter로 노드를 자동 조절하는 클러스터에서 첫 Space를 만들 때 EC2 실행·노드 등록·이미지 다운로드 때문에 5~7분이 걸리는 콜드 스타트 예시를 제시합니다. Karpenter는 필요에 따라 Kubernetes 노드를 늘리고 줄이는 도구입니다. 웜 노드는 미리 켜 놓고 필요한 이미지를 받아 둔 노드입니다. 여기에 Space를 배치하면 발표 예시의 시작 시간은 약 30~40초로 줄어듭니다. (웜 노드 설명)

구현 예시는 우선순위가 낮은 임시 Pod가 자원을 잡아 노드를 유지하고, 실제 Space가 들어오면 그 자리를 넘겨주는 방식입니다. 공식 측정 표는 ml.m5.12xlarge와 약 3.5GB CPU 이미지에서 임시 Pod와 함께 배치될 때 약 14초, 임시 Pod를 밀어낼 때 약 35초를 제시합니다. CPU 전용 수치입니다. GPU Space에는 GPU 자원 요청과 GPU 이미지 사전 다운로드를 갖춘 별도 준비가 안내됩니다. (측정 조건)

자주 개발 환경을 여는 팀은 대기 시간을 줄이는 이점과 대기 노드를 유지하는 비용을 비교할 수 있습니다. 사용 간격이 긴 팀은 노드를 줄여 두는 방식이 더 맞을 수 있습니다. 시작 지연을 줄이는 구성, 유휴 Space 종료, 팀별 할당량은 서로 다른 문제를 해결하는 선택입니다. 발표는 EFS·FSx 공유 저장소, ECR 사용자 이미지, 유휴 종료, A100/H100의 NVIDIA MIG 분할 GPU 할당도 선택 기능으로 안내합니다. 모두 기본으로 켜진 조건으로 읽기보다 팀 구성에 필요한 항목을 고를 수 있습니다. (선택 기능 목록)

비용과 요금은 무엇이 계속 발생합니까?

Spaces 애드온·Operator 자체에는 추가 요금이 없다고 공식 문서는 설명합니다. 실제 HyperPod 클러스터의 컴퓨트와 저장소 요금은 별도입니다. Space를 중지해도 저장된 작업과 볼륨을 유지하는 구성이라면 저장소 항목을 예산에 남겨 둡니다. 컴퓨트 요금은 리전·인스턴스·실행 시간·가격 방식에 따라 계산하며 단일 월 구독료로 묶는 기능과는 구조가 다릅니다. (IDE 요금 안내 · SageMaker AI 가격표)

항목 비용 조건
Spaces 애드온 자체 추가 요금 없음
HyperPod 컴퓨트·저장소 사용하는 자원과 실행·보관 조건에 따른 비용
원격 IDE 연결 SSH-over-SSM용 관리 인스턴스가 SSM 고급 온프레미스 인스턴스로 등록돼 컴퓨트 시간당 과금
웜 노드 EC2 인스턴스를 Running으로 유지하는 추가 비용
웹 접속 구성 Route 53 호스팅 영역·DNS 질의 등 관련 서비스 요금

원격 접속용 관리 인스턴스는 IDE 문서가 별도로 짚는 항목입니다. 애드온의 무료 조건을 확인할 때 함께 읽으면 접속 기능의 비용을 놓치지 않게 됩니다. 설치 문서도 원격 접근 활성화가 SSM advanced-instances 등급의 추가 인스턴스 요금을 발생시킨다고 설명합니다. 정확한 단가는 자신의 리전·구성과 가격표에서 확인하는 범위로 남겼습니다. (SSM 과금 설명 · 설치 문서)

웜 노드 비용은 “노드 한 대의 적용 시간당 단가 × 유지 시간 × 노드 수”로 잡을 수 있습니다. 24시간씩 30일 유지한다면 노드당 720시간이라는 산술 예시입니다. Space 시작을 기다리는 시간을 줄이는 대신 아무 작업이 없는 시간에도 실행 중인 EC2를 유지하는 선택이 됩니다. 여기에 저장소·접속·네트워크 비용을 더하면 전체 예산을 잡을 수 있습니다. (웜 노드의 비용 조건)

반응 (2026년 10월 7일 확인 기준)

공개된 사용자 반응은 아직 확인되지 않았습니다.

팀에서 어떤 순서로 도입하면 좋습니까?

관리자가 기존 클러스터의 애드온·권한·도메인 ID 전달을 확인한 뒤, 사용자가 작은 Space 하나를 생성하고 중지·재시작·파일 유지·접속을 살펴보는 순서로 시작할 수 있습니다. 화면 통합의 이점은 작업 공간 관리의 접근성이므로, 먼저 팀원이 반복하는 생성·시작·중지 작업이 원하는 권한 안에서 동작하는지 확인하는 데 맞습니다. (시작 안내)

그다음 웹 IDE와 로컬 VS Code 중 필요한 경로를 고르고, 작업별 이미지와 저장소를 템플릿으로 정리할 수 있습니다. 웜 노드는 실제 시작 대기 시간이 문제인 경우에 비용을 비교하며 추가할 수 있습니다. 이미 HyperPod EKS를 쓰는 팀에는 운영 경로가 하나 늘어나는 변화입니다. 개발 환경 화면만 필요한 팀이라면 기존 IDE나 더 작은 컴퓨팅 환경부터 비교할 수 있습니다.

참고한 자료

자료 확인일은 2026년 10월 7일입니다. 클러스터 설치·접속을 직접 시험한 결과는 포함하지 않았습니다.