프로젝트 A의 노트북에서 만든 변수가 B에서도 보이면 편리한 공유가 아니라 업무 혼선일 수 있다. 나는 프로젝트별 NotebookService와 커널을 두고 같은 변수 이름을 동시에 써도 각자의 값으로 남게 했다. 문서가 나뉘었다는 표시보다 실제 실행 결과로 확인해야 했다.
노트북 문서와 살아 있는 변수를 나눈다
ipynb에는 코드와 출력이 남아도 실행 중 Python 메모리 전체가 저장되는 것은 아니다. 파일 두 개를 만든다고 커널도 자동 분리되지 않으며 파일을 복사했다고 변수까지 복제되는 것도 아니다. 나는 문서 위치와 실행 프로세스의 소속을 따로 정했다.
프로젝트 runtime은 자신의 NotebookService를 만들고 문맥 키에 프로젝트를 포함한다. 해당 서비스가 가진 커널의 상태와 실행 ID를 관리한다. 같은 브라우저 안에서 노트북을 여러 개 본다는 표현보다 어느 서비스와 Python이 실제로 실행하는지가 중요한 구조였다.
출력과 대기 응답에도 실행 소속을 붙인다
커널에는 key와 child, 연결 소켓과 ready Promise, 현재 execution 같은 상태가 있다. 다른 키를 쓸 때 이전 실행을 그대로 같은 것으로 취급하지 않는다. 커널 응답의 ID와 실제 현재 실행을 대조하는 경로도 있다.
이름이 같은 셀을 눌렀다는 사실로 출력의 소속을 추측하지 않는다. 늦은 응답과 중지, 재시작이 섞이면 이전 실행의 결과가 새 화면으로 들어올 수 있다. 나는 코드 문서와 결과를 구분하면서도 어느 실행에서 나온 것인지 이어 읽을 수 있어야 한다고 봤다. 표시된 텍스트가 곧 현재 실행의 성공이라는 가정은 피한다.
환경 분리와 변수 분리는 각각 확인한다
NotebookService는 프로젝트의 Python 실행기를 받아 커널을 시작한다. sys.prefix가 다른 것은 환경의 근거이고 project_value가 A와 B로 나뉜 것은 메모리 상태의 근거다. 패키지와 변수는 서로 다른 자원이라 한 값으로 모든 분리를 설명하지 않는다.
같은 저장 로그인 프로필을 쓴다고 커널을 공유할 이유도 없다. 로그인 세션은 웹 서비스의 인증이고 Python 변수는 로컬 업무 실행 상태다. 필요한 세션 공유와 불필요한 실행 공유를 나눠야 같은 계정으로 여러 프로젝트를 쓰면서도 자료가 섞이지 않는다.
한 프로젝트를 멈춰도 다른 커널은 남긴다
기존 격리 시험은 두 커널에 같은 이름의 변수를 만들고 동시에 실행한다. 이어 A에 긴 셀을 실행해 중지하고 B에서는 이전 project_value를 읽어 결과를 내는지 본다. 중지 요청이 다른 프로젝트의 메모리와 실행까지 끊지 않는지 확인하는 것이다.
이 시험의 성공을 모든 임의 코드의 즉시 중단 보장으로 바꾸지 않는다. 커널과 외부 프로세스, 이미 처리된 서버 변경은 수명이 다르다. 실제로 무엇을 중지했고 다른 쪽이 어떤 값을 유지했는지 설명해야 한다. 중지 버튼의 색보다 남은 실행의 결과가 중요한 근거였다.
유휴 해제는 출력 보존과 변수 초기화를 나눈다
현재 NotebookService에는 바쁘지 않은 커널을 정한 유휴 시간 뒤 해제하는 경로가 있다. 문서와 출력은 남기고 변수는 다시 실행해야 한다는 문구를 남긴다. 환경의 메모리를 줄이면서 살아 있던 변수가 그대로 있다고 오해하지 않게 하려는 처리다.
그러므로 이전 출력이 보이는 것만으로 지금 커널에 같은 변수가 있다고 말할 수 없다. 이 글에서는 현재 서비스와 프로젝트 연결, 기존 실제 fixture 시험 코드를 읽었다. 사용자의 노트북 셀을 새로 실행하거나 커널을 중단한 검수는 아니다. 유휴 해제의 모든 시간 조합을 새로 시험했다고도 쓰지 않는다.
이어 실행할 수 있는 설명을 남긴다
고객에게 노트북이 저장됐다고 알릴 때 코드와 출력이 저장된 것인지 살아 있는 실행까지 유지된 것인지 구별해야 한다. 프로젝트 복사와 앱 재시작에서도 같은 질문이 반복된다. 무엇을 다시 실행해야 하는지 알 수 있어야 문서를 열고 바로 업무를 이어갈 수 있다.
나는 변수 이름을 바꾸어 충돌을 피하라고 요구하는 대신 실행 소속을 분리했다. 이름을 편하게 쓰면서도 결과가 어느 프로젝트의 것인지 분명하게 남기는 구조다. 이 기준은 여러 고객의 보고서와 자료 처리에도 적용할 수 있다. 공유하면 편한 자산과 공유하면 안 되는 실행 메모리를 먼저 나누는 것이 출발점이었다.