기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# (선택 사항) 사용자 지정 이미지 및 수명 주기 구성 마이그레이션
Amazon SageMaker Studio에서 간소화된 로컬 실행 모델로 작업하려면 사용자 지정 이미지 및 수명 주기 구성(LCC) 스크립트를 업데이트해야 합니다. 도메인에서 사용자 지정 이미지 또는 수명 주기 구성을 생성하지 않은 경우 이 단계를 건너뜁니다.
Amazon SageMaker Studio Classic은 다음과 같은 분할 환경에서 작동합니다.
+ Jupyter Server를 실행하는 `JupyterServer` 애플리케이션입니다.
+ 하나 이상의 `KernelGateway` 애플리케이션에서 실행되는 Studio Classic 노트북입니다.
Studio가 분할 환경에서 전환되었습니다. Studio는 로컬 런타임 모델의 Code-OSS, Visual Studio Code - 오픈 소스 애플리케이션을 기반으로 JupyterLab 및 Code Editor를 실행합니다. 아키텍처 변경에 대한 자세한 내용은 [ Amazon SageMaker Studio의 생산성 향상](https://aws.amazon.com/blogs//machine-learning/boost-productivity-on-amazon-sagemaker-studio-introducing-jupyterlab-spaces-and-generative-ai-tools/)을 참조하세요.
## 사용자 지정 이미지 마이그레이션
기존 Studio Classic 사용자 지정 이미지는 Studio에서 작동하지 않을 수 있습니다. Studio에서 사용하기 위한 요구 사항을 충족하는 새 사용자 지정 이미지를 생성하는 것이 좋습니다. Studio 릴리스는 [SageMaker Studio 이미지 지원 정책](sagemaker-distribution.md)을 제공하여 사용자 지정 이미지를 빌드하는 프로세스를 간소화합니다. SageMaker AI 배포 이미지에는 기계 학습, 데이터 과학 및 데이터 분석 시각화를 위한 인기 있는 라이브러리 및 패키지가 포함됩니다. 기본 SageMaker 배포 이미지 및 Amazon Elastic Container Registry 계정 정보 목록은 [Studio Classic 노트북에 사용할 수 있는 Amazon SageMaker 이미지](notebooks-available-images.md) 섹션을 참조하세요.
사용자 지정 이미지를 빌드하려면 다음 중 하나를 수행합니다.
+ 사용자 지정 패키지 및 모듈을 사용하여 SageMaker 배포 이미지를 확장합니다. 이러한 이미지는 Code-OSS, Visual Studio Code - Open Source를 기반으로 JupyterLab 및 Code Editor로 사전 구성됩니다.
+ [기존 보유 이미지 사용(BYOI)](studio-updated-byoi.md)의 지침에 따라 사용자 지정 Dockerfile 파일을 빌드합니다. Studio와 호환되도록 이미지에 JupyterLab 및 오픈 소스 CodeServer을 설치해야 합니다.
## 수명 주기 구성 마이그레이션
Studio의 간소화된 로컬 런타임 모델로 인해 기존 Studio Classic LCCs의 구조를 마이그레이션하는 것이 좋습니다. Studio Classic에서는 종종 KernelGateway 및 JupyterServer 애플리케이션 모두에 대해 별도의 수명 주기 구성을 생성해야 합니다. JupyterServer 및 KernelGateway 애플리케이션은 Studio Classic 내의 별도의 컴퓨팅 리소스에서 실행되므로 Studio Classic LCCs 다음 유형 중 하나일 수 있습니다.
+ JupyterServer LCC: 이러한 LCC는 대부분 프록시 설정, 환경 변수 생성, 리소스 자동 종료 등 사용자의 홈 작업을 제어합니다.
+ KernelGateway LCC: 이러한 LCC는 Studio Classic 노트북 환경 최적화를 관리합니다. 여기에는 `Data Science 3.0` 커널에서 무감각한 패키지 버전 업데이트 및 `Pytorch 2.0 GPU` 커널에 snowflake 패키지 설치가 포함됩니다.
간소화된 Studio 아키텍처에서는 애플리케이션 시작 시 실행되는 LCC 스크립트가 하나만 필요합니다. LCC 스크립트의 마이그레이션은 개발 환경에 따라 다르지만 JupyterServer 및 KernelGateway LCC를 결합하여 결합된 LCC를 구축하는 것이 좋습니다.
Studio의 LCC는 다음 애플리케이션 중 하나와 연결할 수 있습니다.
+ JupyterLab
+ 코드 편집기
사용자는 공백을 생성할 때 각 애플리케이션 유형에 대한 LCC를 선택하거나 관리자가 설정한 기본 LCC를 사용할 수 있습니다.
**참고**
기존 Studio Classic 자동 종료 스크립트는 Studio에서 작동하지 않습니다. Studio 자동 종료 스크립트 예제는 [SageMaker Studio 수명 주기 구성 예제](https://github.com/aws-samples/sagemaker-studio-apps-lifecycle-config-examples)를 참조하세요.
### LCC 리팩터링 시 고려 사항
LCC를 리팩터링할 때 Studio Classic과 Studio의 다음과 같은 차이점을 고려하세요.
+ JupyterLab 및 Code Editor 애플리케이션은 생성 시 `UID:1001` 및 `GID:101`과 함께 `sagemaker-user`로 실행됩니다. 기본적으로 `sagemaker-user`에는 sudo/root 권한을 맡을 수 있는 권한이 있습니다. KernelGateway 애플리케이션은 기본적으로 `root`로 실행됩니다.
+ JupyterLab 및 Code Editor 앱 내에서 실행되는 SageMaker 배포 이미지는 Debian 기반 패키지 관리자인 `apt-get`를 사용합니다.
+ Studio JupyterLab 및 Code Editor 애플리케이션은 Conda 패키지 관리자를 사용합니다. SageMaker AI는 Studio 애플리케이션이 시작될 때 단일 기본 Python3 Conda 환경을 생성합니다. 기본 Conda 환경에서 패키지를 업데이트하고 새 Conda 환경을 생성하는 방법에 대한 자세한 내용은 [JupyterLab 사용 설명서](studio-updated-jl-user-guide.md) 섹션을 참조하세요. 반면 모든 KernelGateway 애플리케이션이 패키지 관리자로 Conda를 사용하는 것은 아닙니다.
+ Studio JupyterLab 애플리케이션은 `JupyterLab 4.0`를 사용하는 반면 Studio Classic은 `JupyterLab 3.0`을 사용합니다. 사용하는 모든 JupyterLab 확장이 `JupyterLab 4.0`과 호환되는지 확인합니다. 확장에 대한 자세한 내용은 [JupyterLab 4.0과의 확장 호환성](https://github.com/jupyterlab/jupyterlab/issues/14590)을 참조하세요.