노트북 환경과 개발 워크스페이스
구성 방법
Amazon SageMaker Studio는 SageMaker에서 모델 개발과 실험을 시작하는 기본 워크스페이스입니다. 이 글은 Studio를 처음 구성하는 개발자와 인프라 엔지니어를 위해 Domain, User Profile, Space, Application, Execution Role의 관계를 정리하고 첫 ML 실험을 시작하기 전 확인해야 할 기준을 설명합니다.
SageMaker Studio를 처음 만들 때 가장 자주 헷갈리는 부분은 노트북 자체가 아니라 Domain, User Profile, Space, App, IAM Role의 관계입니다. 이 글을 읽으면 Studio 개발 워크스페이스가 어떤 구조로 만들어지고, 어떤 권한과 비용 포인트를 먼저 확인해야 하는지 알 수 있습니다.
SageMaker Studio란 무엇인가
Amazon SageMaker Studio는 SageMaker에서 모델 개발, 실험, 학습, 배포 작업을 수행하는 웹 기반 개발 환경입니다. JupyterLab, Code Editor, RStudio, Studio Classic 같은 앱을 통해 노트북 기반 실험이나 코드 기반 개발을 시작할 수 있습니다.
1편에서 SageMaker 전체 흐름을 봤다면, 2편은 그중 개발자가 처음 접하는 작업 공간에 해당합니다. SageMaker 전체 개념이 필요하면 Amazon SageMaker란 무엇인가 글을 먼저 보면 흐름을 잡기 쉽습니다.
Studio는 단순 노트북이 아니라 SageMaker 리소스를 사용하는 개발 워크스페이스입니다. 따라서 노트북 UI보다 Domain, 사용자, 권한, 실행 리소스를 함께 이해해야 합니다.
Studio를 만들기 전에 알아야 할 구성요소
Studio를 구성할 때는 여러 리소스가 함께 만들어집니다. 화면에서는 개발 환경처럼 보이지만 내부적으로는 Domain, User Profile, Space, Application, Execution Role이 연결됩니다.
| 구성요소 | 역할 | 처음 볼 때의 기준 |
|---|---|---|
| Domain | Studio 사용자를 묶는 최상위 환경 | 팀 또는 계정 단위 워크스페이스 |
| User Profile | Domain 안의 개별 사용자 설정 | 사용자별 홈 디렉터리와 실행 역할 |
| Space | 일부 Studio 앱의 저장소와 리소스 관리 단위 | 개인 또는 공유 작업 공간 |
| Application | JupyterLab, Code Editor 같은 실제 실행 앱 | 개발자가 접속하는 IDE/노트북 |
| Execution Role | Studio가 AWS 리소스에 접근할 때 사용하는 IAM Role | S3, Training Job, Endpoint 권한의 기준 |
Domain, User Profile, Space의 관계
Domain은 Studio 환경의 최상위 경계입니다. 하나의 Domain 안에 여러 User Profile이 존재하고, 각 사용자는 Studio 앱을 실행해 작업합니다. AWS 공식 문서 기준으로 User Profile은 Domain 안의 단일 사용자를 나타냅니다.
Space는 Studio 앱의 저장소와 리소스 요구사항을 관리하는 단위로 볼 수 있습니다. 개인 작업 공간으로 사용할 수도 있고, 팀이 공유하는 작업 공간으로 사용할 수도 있습니다.
SageMaker Domain
- User Profile: developer-a
- JupyterLab App
- Code Editor App
- User Profile: engineer-b
- JupyterLab App
- Shared Space
- 팀 공용 작업 공간처음 구성할 때는 “누가 어떤 Domain에 속하고, 어떤 Execution Role로 어떤 리소스에 접근하는가”를 먼저 정리하는 것이 중요합니다.
Execution Role이 중요한 이유
Execution Role은 Studio에서 실행되는 코드가 AWS 리소스에 접근할 때 사용하는 IAM Role입니다. 사용자가 노트북에서 S3 데이터를 읽거나, Training Job을 만들거나, Endpoint를 배포할 때 이 역할의 권한이 사용됩니다.
처음에는 편의상 넓은 권한을 붙이고 싶지만, 운영 환경에서는 최소 권한 원칙을 적용해야 합니다. 특히 S3 버킷 접근, SageMaker Training Job 생성, Endpoint 배포, iam:PassRole 권한은 별도로 검토해야 합니다.
| 작업 | 필요한 권한 관점 |
|---|---|
| S3 데이터 읽기 | 학습 데이터 버킷에 대한 s3:GetObject |
| 학습 작업 실행 | sagemaker:CreateTrainingJob, iam:PassRole |
| 모델 배포 | sagemaker:CreateModel, CreateEndpointConfig, CreateEndpoint |
| 로그 확인 | CloudWatch Logs 조회 권한 |
Studio에서 사용할 수 있는 개발 앱
현재 Studio에서는 JupyterLab, Code Editor, RStudio, Studio Classic 같은 앱을 사용할 수 있습니다. 개발자는 작업 방식에 따라 노트북 중심 또는 코드 에디터 중심으로 환경을 선택할 수 있습니다.
노트북 환경에서 첫 ML 실험을 시작하는 흐름
Studio에서 첫 실험을 시작할 때는 복잡한 모델보다 작은 데이터와 간단한 학습 흐름을 먼저 확인하는 것이 좋습니다. 목표는 정확도보다 Studio가 S3와 SageMaker 리소스에 정상 접근하는지 확인하는 것입니다.
1. Studio Domain 접속
2. User Profile 선택
3. JupyterLab 또는 Code Editor 실행
4. 작은 샘플 데이터 준비
5. S3 접근 테스트
6. 간단한 Python ML 코드 실행
7. 다음 단계에서 Training Job으로 분리2편에서는 개발 워크스페이스 구성에 집중하고, 실제 S3 데이터로 Training Job을 실행하는 구조는 SageMaker Training Job 사용법 글에서 이어서 다루겠습니다.
S3 데이터 접근과 권한 확인 기준
Studio에서 가장 먼저 확인할 것은 S3 접근입니다. 대부분의 SageMaker 학습 데이터와 모델 artifact는 S3를 기준으로 오가기 때문에, Studio의 Execution Role이 필요한 버킷에 접근할 수 있어야 합니다.
권한을 확인할 때는 전체 S3 권한을 열기보다 실습용 버킷이나 프로젝트 버킷을 지정하는 방식이 좋습니다. 개발 계정이라도 운영 데이터 버킷과 섞이지 않게 분리해야 합니다.
Studio 비용이 발생하는 지점
Studio는 관리형 개발 환경이지만 실행 중인 앱과 인스턴스에 따라 비용이 발생할 수 있습니다. 특히 JupyterLab이나 Code Editor 같은 앱을 실행한 뒤 정리하지 않으면 불필요한 비용이 생길 수 있습니다.
처음 실습하는 경우에는 큰 인스턴스를 선택하지 말고, 작업이 끝나면 실행 중인 앱과 공간을 확인하는 습관을 들이는 것이 좋습니다. AWS 공식 문서에도 Studio에서 실행 중인 instances, applications, spaces를 확인하는 절차가 별도로 제공됩니다.
| 비용 지점 | 확인 기준 |
|---|---|
| 실행 중인 앱 | JupyterLab, Code Editor 등 앱이 계속 실행 중인지 확인 |
| 인스턴스 타입 | 실험 규모에 비해 큰 인스턴스를 사용하지 않는지 확인 |
| 스토리지 | 공간과 파일이 계속 누적되는지 확인 |
| 후속 리소스 | Training Job, Endpoint 생성 여부를 함께 확인 |
개발자와 인프라 엔지니어 역할 분리
Studio는 개발자와 인프라 엔지니어가 함께 사용하는 환경입니다. 개발자는 노트북, 코드, 데이터 실험에 집중하고, 인프라 엔지니어는 Domain, IAM Role, 네트워크, 비용 정책을 관리하는 식으로 역할을 나누면 운영이 안정적입니다.
| 역할 | 주요 관심사 | 확인 항목 |
|---|---|---|
| 개발자 | 실험과 모델 코드 | 노트북, 라이브러리, S3 데이터, 학습 스크립트 |
| ML 엔지니어 | 학습과 배포 흐름 | Training Job, 모델 artifact, Endpoint, Pipeline |
| 인프라 엔지니어 | 권한과 운영 기준 | Domain, User Profile, Execution Role, VPC, 비용 |
처음 구성할 때 체크리스트
Studio를 처음 구성할 때는 노트북이 열리는지보다 운영 기준을 먼저 확인해야 합니다. 나중에 Training Job, Endpoint, Pipeline으로 확장할 때도 이 기준이 그대로 이어집니다.
SUMMARY
SageMaker Studio는 ML 실험을 시작하는 개발 워크스페이스이지만, 내부적으로는 Domain, User Profile, Space, App, Execution Role이 연결된 구조입니다. 처음부터 이 구조를 이해하면 이후 Training Job과 Endpoint 실습이 훨씬 명확해집니다.
SUMMARY. SageMaker Studio 시작 핵심
SageMaker Studio를 시작할 때 중요한 것은 노트북 화면을 여는 것보다 개발 워크스페이스의 구조를 이해하는 것입니다. Domain, User Profile, Space, App, Execution Role이 어떻게 연결되는지 알아야 이후 학습과 배포 단계에서 권한 문제를 줄일 수 있습니다.
개발자는 Studio에서 실험을 시작하지만, 인프라 엔지니어는 이 환경이 어떤 IAM Role로 S3와 SageMaker 리소스에 접근하는지 확인해야 합니다. 이 역할 분리가 제대로 되어야 팀 단위 SageMaker 운영이 안정적입니다.
다음 글에서는 Studio에서 준비한 코드와 데이터를 SageMaker Training Job으로 분리해, S3 데이터 기반으로 모델을 학습시키는 기본 구조를 다룹니다.
SageMaker Studio is not just a notebook UI. It is a managed ML workspace built around domains, user profiles, applications, spaces, and execution roles.
'AWS Guides' 카테고리의 다른 글
| SageMaker Endpoint 배포 방법: 학습한 모델을 실시간 추론 API로 서비스하기 (0) | 2026.05.29 |
|---|---|
| SageMaker Training Job 사용법: S3 데이터로 모델을 학습시키는 기본 구조 (0) | 2026.05.29 |
| Amazon SageMaker란 무엇인가: ML 모델 개발부터 학습, 배포, MLOps까지 한 번에 이해하기 (1) | 2026.05.28 |
| Amazon Bedrock 토큰 사용량 모니터링: Lambda로 입력·출력 토큰을 계산하고 기록하는 방법 (0) | 2026.05.27 |
| EKS Manifest 검사 방법: Kubernetes YAML 보안·리소스 문제를 배포 전에 찾는 Python CLI 활용법 (0) | 2026.05.25 |