JupyterLab 화면이 열렸다면 셀을 실행할 Python도 확인해야 한다. 필요한 모듈이 어느 환경에 설치됐는지까지 같아지는 것은 아니기 때문이다. 작업 폴더, 화면 서버와 셀 실행기를 따로 살핀 이유다.
기존 노트북과 모듈을 실제 주피터 환경에서 쓰고 싶다는 요청을 따라 작업실의 안내문과 서버 시작·커널 등록 코드를 살폈다. 아래는 그 코드가 환경을 선택하는 방법이다. 사용자의 노트북이나 실행 중인 커널을 새로 열어 시험한 결과는 아니다.
화면 서버와 셀의 실행기를 따로 연결했다
읽은 서비스는 앱 전용 Jupyter 환경의 Python으로 JupyterLab 서버를 시작한다. 셀의 커널 명세에는 프로젝트에서 선택한 Python을 넣는다. 서버를 실행하는 Python과 실제 셀을 실행하는 Python의 역할을 나눈 구성이다.
기본값을 쓰면 두 역할이 같은 환경을 가리킬 수 있다. 기존 가상환경의 실행기를 지정하면 화면 서버는 앱 환경에 두고 셀은 선택한 환경에서 실행하도록 연결한다. 따라서 앱에 어떤 패키지가 설치됐다는 사실만으로 프로젝트 셀에서도 그 패키지를 쓸 수 있다고 판단할 수 없다.
IPython 공식 안내도 Jupyter를 실행하는 환경과 다른 Python·가상환경의 커널을 연결하는 방법을 설명한다. 이번 작업실의 구체적인 선택은 서버 실행 인자와 커널 명세를 읽어 확인했다. 일반 문서를 읽은 것을 이 PC에서 실제 연결을 실행한 증거로 쓰지 않았다.
출처: IPython 공식 문서, Installing the IPython kernel — 다른 Python 환경의 커널.
커널 환경을 따로 지정할 수 있다는 공식 설명. 이번 집필에서 환경을 설치하거나 등록하지 않았다.
커널을 시작할 수 있는지와 업무 모듈이 있는지는 다르다
프로젝트 등록은 작업 루트와 Python 실행기 경로를 기록한다. 선택한 Python으로 시작하기 전에는 ipykernel을 가져올 수 있는지 확인하는 별도 경로가 있다. 이것은 커널 시작에 필요한 준비를 확인하는 조건이다. 노트북이 쓰는 모든 모듈을 가져와 본 검사로 확대할 수는 없다.
기본 Jupyter 환경의 준비 스크립트는 선언된 런타임 의존성을 설치한다. 프로젝트를 연결하는 동작이 그 폴더의 임의 requirements 파일을 읽어 모두 설치하는 구조는 아니다. 기존 환경의 실행기를 선택하더라도 필요한 업무 패키지와 버전은 그 환경에서 따로 확인해야 한다.
연결 기록에는 실행기 경로, 커널 준비 상태와 실제 노트북의 의존성 확인을 따로 남긴다. 모듈이 빠졌다면 어느 Python에 필요한지부터 찾는다. 이번 집필에서 패키지를 설치하거나 환경을 바꾸지는 않았다.
작업 폴더와 실행 환경을 구분했다
서버 시작 코드는 프로젝트 루트를 파일 탐색기의 시작점과 작업 디렉터리로 사용하고, 앱과 프로젝트 소스 경로를 Python 검색 경로에 보탠다. 소스 파일을 찾게 하는 연결이지 다른 환경에 설치된 패키지를 통째로 옮기는 작업은 아니다. 등록한 루트도 Python의 운영체제 접근 전체를 가두는 샌드박스라는 뜻은 아니다.
커널 명세는 프로젝트별 자료 폴더 아래에 만들고 전역 커널 등록을 바꾸지 않는 구성을 택했다. 서버 쪽에는 그 프로젝트의 커널 디렉터리와 기본 커널 이름을 지정한다. 화면에 보이는 이름과 실제 선택한 실행기 인자를 함께 읽어야 어떤 환경을 고르는지 설명할 수 있다.
원래 노트북이 기억한 커널 이름이 현재 프로젝트의 이름과 다를 수도 있다. 작업실 안내는 이때 프로젝트용 커널을 선택하도록 설명한다. 문서를 복사하거나 폴더를 연결했다는 이유만으로 저장된 커널 정보와 현재 실행이 자동으로 일치한다고 가정하지 않았다.
선택한 환경의 확인은 노트북 안에서 남긴다
다음 진단 셀은 실행 파일 경로와 Python 환경의 기준 경로를 읽는다. 이번 집필에서는 실행하지 않았고 실제 출력도 붙이지 않았다. 값에 개인 경로가 포함될 수 있어 운영자가 내부에서 선택한 환경을 대조할 때 쓰는 예시다.
Python 문서에서 sys.executable은 실행기 경로를 뜻하며, 경로를 얻지 못하는 환경에서는 비어 있거나 None일 수 있다. sys.prefix는 가상환경이 적용되면 그 환경을 가리킨다. 이 값들은 어떤 실행기를 읽었는지 확인하는 단서이지 필요한 패키지의 존재나 모든 코드의 성공을 보증하는 값은 아니다.
환경을 확인한 뒤에는 필요한 모듈 가져오기와 셀 사이 상태 유지도 서로 다른 질문으로 확인할 수 있다. 실행기 경로가 기대와 맞는 일과 앞 셀의 변수가 다음 셀에 남는 일은 구분된다. 아래 관련 글은 프로젝트별 변수 격리의 기존 사례이며 이번 작업실의 새 실행 시험은 아니다.
출처: Python 공식 문서, sys — System-specific parameters and functions, sys.executable·sys.prefix 절.
sys.executable과 sys.prefix의 뜻과 한계를 확인했다.
코드와 구현 살펴보기
Read-only diagnostic cell example; not executed for this article
import sys
print(sys.executable)
print(sys.prefix)노트북처럼 보이는 화면에도 실행 방식은 달랐다
과거 대화의 초기 설명은 코드 블록마다 별도 Python 프로세스를 쓰고, 앞 셀의 전역 변수를 다음 셀에 그대로 남기지 않는 구조였다. 현재 작업실 안내는 그 블록·워크플로 경로와 실제 JupyterLab 경로를 구분한다. 이전 블록의 JSON 결과를 입력으로 넘기는 절차와 살아 있는 IPython 커널의 변수 상태는 같은 약속이 아니다.
기존 코드 블록을 주피터처럼 보이게 배치했다고 실행 방식까지 바뀌는 것은 아니다. 반대로 현재 소스에 실제 JupyterLab 경로가 있다는 사실을 근거로 예전 블록 실행이 모두 바뀌었다고 설명하지 않았다. 어떤 화면의 어느 실행 버튼을 누르는지부터 연결해야 했다.
JupyterLab 공식 문서는 기존 .ipynb 문서 형식을 지원한다고 설명한다. 하지만 문서를 열 수 있다는 호환성과 그 문서가 요구하는 패키지를 실행할 수 있다는 호환성은 구분해야 한다. 파일을 연결하는 단계 뒤에도 환경 확인이 남는다.
출처: JupyterLab 공식 문서, Notebooks — 기존 노트북 문서 형식 지원.
문서 형식 지원을 확인한 공식 자료다. 이 작업실의 모든 기존 노트북을 시험했다는 뜻은 아니다.
서버가 준비됐다는 응답 다음에도 확인할 것이 남았다
시작 코드는 서버 상태 응답을 받으면 running으로 바꾼다. 이는 JupyterLab 서버가 준비됐다는 상태다. 업무 노트북의 셀 실행, 패키지, 자료 경로, 저장·재열람은 별도로 확인해야 한다.
이번 글은 안내문과 시작·등록 코드, 런타임 의존성 선언을 읽고 공식 문서와 대조한 기록이다. 원래 프로그램을 import하거나 서버·커널·노트북을 시작하지 않았고, 관련 시험이나 빌드도 새로 실행하지 않았다. 진단 예시는 구문만 검사하며 현재 사용자의 환경 결과를 만들지 않는다.
다른 작업실에 적용할 때도 서버용 Python, 프로젝트용 Python과 작업 루트를 따로 기록할 수 있다. 그다음 필요한 의존성과 작은 셀 실행을 확인하고 저장한 문서를 다시 열어 본다. 문서를 이어받은 사람이 어떤 환경을 선택하고 무엇을 다시 확인할지 알 수 있게 남기는 순서다.