[MLOps] 머신러닝 플랫폼 엔지니어링: Evidently와 Kubeflow Notebooks - 7.1.4. 세션 회수 정책: 데이터 보존, 판정 기준, 의도 표시

서종호(가시다)님의 Machine Learning Platform Engineering Study 3주차 학습 내용을 기반으로 합니다.

TL;DR

• 유휴 세션을 회수하는 일, 세션을 정지하는 동작 자체는 기술적으로 구현할 수 있다. 앞 세 편에서 구조와 도구의 상태, 판정 신호를 봤다
• 데이터 보존과 회수 기준은 구현보다 정책의 문제여서 민감하게 설계해야 한다. 보존, 판정 기준, 의도 표시는 함께 정해야 한다
• 보존은 홈이 남는 것으로 끝나지 않는다. 프로세스와 임시 파일, GPU 메모리의 상태가 사라진다. 다시 시작할 때 GPU가 있다는 보장도 없다
• 기준은 사람의 행동을 바꿀 수 있다. 공개 문서에 자동 취소를 우회하는 사용자를 관리자에게 알리는 대목이 있다. 같은 곳에서 기준을 0%에서 9%로 올렸다가 반발로 이틀 만에 되돌린 사례도 있다
• 세션을 계속 쓸 생각인지는 지표만으로 증명되지 않는다고 본다. 사용자가 의도를 밝힐 장치를 정책과 함께 설계해야 한다
• 공개된 두 곳은 취소 전에 경고를 보낸다. Princeton이 만든 도구에는 실제로 취소하지 않고 시험하는 옵션이 있다. 시행 순서도 정책의 일부다

구현 뒤에 남는 결정

7.1.1편에서 세션을 정지하는 구조를, 7.1.2편에서 도구의 상태를, 7.1.3편에서 판정 신호를 다뤘다. 유휴 세션을 회수하는 일, 세션을 정지하는 동작 자체는 기술적으로 구현할 수 있다.

구현이 끝나도 무엇을 지켜 줄지, 무엇을 사용으로 볼지, 사용자의 말을 어디까지 믿을지는 정해지지 않는다. 보존 약속 없이 판정만 엄격해지면 세션을 놓기가 어려워진다고 본다. 그래서 데이터 보존, 판정 기준, 의도 표시는 함께 정해야 한다. 측정 없이 공개 자료를 바탕으로 썼고 자료를 찾고 읽는 데 AI의 도움을 받았다.

데이터 보존

회수는 세션을 멈추고 데이터는 지우지 않는다. 다만 남는 범위와 기간은 따로 적어야 한다. GitHub Codespaces 문서는 무엇이 남는지와 얼마나 남는지를 함께 적는다. 정지하면 실행 중인 프로세스가 멈추고 저장한 변경은 다음에 시작할 때 남아 있다. 비활성 코드스페이스는 기본 30일 뒤에 삭제된다.

PVC 홈과 emptyDir /tmp로 만든 세션을 정지하면 사용자가 잃는 것은 이렇다. 홈, /tmp, GPU 대기는 7.1.1편의 실험 결과이고 나머지는 쿠버네티스 동작으로 따진 것이다.

대상	정지 뒤	사용자에게 뜻하는 것	줄이는 수단
PVC 홈의 파일	남는다	코드와 저장한 결과는 그대로다	저장 위치를 알린다
실행 중인 프로세스	사라진다	돌던 작업이 끝난다	종료 유예 안에 체크포인트(학습 중간 상태 파일)를 홈에 쓴다
터미널 세션, Jupyter 노트북의 메모리 상태	사라진다	셀과 명령을 다시 돌린다	예고를 앞서 준다
GPU 메모리의 모델	사라진다	다시 올리는 시간이 든다	예고를 앞서 준다
/tmp에 받은 파일	사라진다	다시 받는다	캐시를 영속 볼륨에 둔다
세션 안에서 홈 밖에 설치한 패키지	사라진다	환경을 다시 만든다. 이미지에 든 패키지는 남는다	환경을 홈이나 이미지에 둔다
다시 시작할 때의 GPU	보장되지 않는다	다른 파드가 쓰는 중이면 기다린다	재개 우선권을 둘지 정한다

7.1.1편에서 회수된 세션은 다시 올렸을 때 대기 상태가 됐다.

구현은 어느 쪽이든 할 수 있고 보관 기간이나 재개 순서 같은 값은 코드가 정하지 못한다.

판정 기준

같은 신호도 사람의 활동 쪽에서 보면 판단이 갈린다. 창만 열린 세션과 코드를 고치는 세션은 신호가 같다.

판단은 GPU가 얼마나 모자라는지에 달리기도 한다. 기다리는 사람이 없으면 내버려 둘 수 있다. 대기열이 길면 GPU 없는 세션으로 옮기라고 안내할 수 있다. 대기하는 파드가 있을 때만 회수하는 방법도 있다. 잘못 정지하는 일은 줄지만 같은 세션의 처리가 날마다 달라진다.

기준 시간도 곳마다 다르다. 공유 GPU를 오래 운영해 온 곳이 연구용 HPC(고성능 컴퓨팅) 클러스터다. 사용자가 잡을 제출해 GPU를 받는 구조라 공개된 정책이 있다. 두 곳의 정책은 이렇다.

기관	대상	경고와 취소
Princeton	사용률 0%인 GPU 잡	2시간 뒤 취소, 그 전에 경고 메일 두 번
Yale(Bouchet 클러스터)	GPU를 한 번도 쓰지 않은 잡	30분 뒤 경고, 1시간 뒤 취소
Yale(Bouchet 클러스터)	잡 중간에 GPU가 유휴	1시간 뒤 경고, 2시간 뒤 취소

표의 내용은 2026년 11월에 각 문서에서 확인했다. 이 값을 세션에 그대로 옮기기는 어렵다. Princeton과 다른 대학 저자들이 쓴 PEARC ‘26 논문은 GPU가 노는 배치 잡(제출해 두면 끝날 때까지 혼자 도는 잡)은 시작하면 되살릴 수 없고 대화형 잡(사람이 들어가 쓰는 잡)은 간헐적인 사용이 흔하다고 구분한다.

This is in contrast to interactive jobs where intermittent usage is common.

Princeton Research Computing이 만든 Job Defense Shield에는 대화형 잡을 취소에서 빼는 옵션이 있다. 시간 제한과 GPU 수가 설정값 이하인 잡만 뺀다. 시간 제한이 긴 대화형 잡은 이 조건에 들지 않는다. 잡에는 시간 제한이 있지만 끝이 없는 세션에는 그마저 없다. 그래서 세션의 기준은 이 표보다 7.1.1편의 개발 환경 제품 쪽에 가깝다고 본다.

기준과 사람의 반응

회수 기준이 알려지면 사람이 거기에 맞춰 움직일 수 있다고 본다.

세션을 다시 만드는 시간, 돌아왔을 때의 GPU, 남는 것의 범위는 기준과 별개로 세션 사용에 영향을 준다.

공개 자료에 사례가 둘 있다. Job Defense Shield 문서는 자동 취소를 우회하는 사용자가 있다고 관리자에게 알린다. 문서는 왜 그러는지, 얼마나 흔한지는 적지 않는다. 기준이 생기면 사람의 행동도 달라질 수 있다는 예로 볼 수 있다.

다른 하나는 앞의 PEARC ‘26 논문이다. 논문에 따르면 Princeton이 2024년 초에 도입했을 때는 사용자 반응이 거의 없었다. 2025년에 사용자 1000명이 넘는 클러스터에서 제외 목록에 넣은 사람은 2명이었다. 그런데 취소 기준을 0%에서 9% 이하로 올리자 큰 반발이 있었고 이틀 만에 되돌렸다.

0%는 저항 없이 받아들여졌고 9%는 그렇지 않았다. 기준을 어디에 긋느냐가 사람의 반응을 가른다는 뜻으로 읽힌다. 판정 기준만 조이는 것으로는 부족하고 앞 절의 잃는 것도 함께 줄여야 한다고 본다. 재개할 때 GPU를 받을 수 있고 무엇이 남는지 분명하면 세션을 놓기가 쉬워질 것이다.

의도 표시

의도는 사용자가 이 세션을 계속 쓸 생각이 있는지다. 7.1.3편의 끝에서 올려 두고 떠난 경우와 결과를 내일 볼 예정인 경우는 신호로는 같았다.

시스템은 흔적까지만 볼 수 있다. 체크포인트, 실험 기록, 코드 변경, 데이터 읽기가 쌓이는지는 일이 진척되는지를 어느 정도 알려 준다. 그래도 사람이 돌아올 생각인지는 어떤 지표로도 증명되지 않는다고 본다. 지표로 추정하는 대신 사용자가 의도를 밝힐 경로를 둘 수 있다. 아래는 공개된 제품에서 볼 수 있는 방식이다.

방식	볼 수 있는 곳	얻는 것	한계
사용 기간을 먼저 적음	HPC 대화형 잡의 시간 제한	긴 작업을 미리 구분한다	넉넉히 적을 수 있다
연장	7.1.2편의 마감 연장	쓰는 사람에게 쉬운 경로가 된다	상한이 없으면 회수를 보장하지 못한다
회수 전 경고	앞 표의 경고 메일	알림을 받은 사람이 저장하거나 응답한다	학습을 돌려 두고 자리를 뜬 사람은 응답하지 못한다. 무응답일 때의 기본값을 정해야 한다
활동과 무관한 시간 상한	Codespaces의 12시간 최대 수명	지표 없이도 끝이 정해진다	긴 작업이 끊긴다

시험 운영

정책을 정해도 처음부터 세션을 정지하는 것은 위험하다. 판정이 얼마나 틀리는지는 실제로 대 보기 전에는 모르기 때문이다. Job Defense Shield의 설정에는 실제로 취소하지 않고 시험하는 do_not_cancel 옵션이 있다. 문서의 예시값은 잡 시작 기준 60분과 105분에 경고를 보낸 뒤 120분에 취소한다.

정리

유휴 세션 회수는 구현이 불가능한 일이 아니다. 앞 세 편에서 구조와 상태, 신호를 각각 확인했다.

데이터 보존과 회수 기준은 그다음 문제다. 무엇을 남기고 얼마나 둘지, 무엇을 사용으로 볼지, 돌아왔을 때 GPU를 줄지는 사람의 일에 닿는 결정이라 민감하게 설계해야 한다. 기준만 세게 잡으면 사용자는 세션을 놓기 어려워질 수 있다. 사용자의 의도는 지표로 증명되지 않으므로 의도를 밝힐 장치도 정책을 설계할 때 함께 고려해야 한다.

7.1.1편의 책 문장은 노트북에 유휴 시 파드를 종료하는 수명주기 규칙을 반드시 설정해야 한다고 했다. 그 규칙에는 설정값보다 이런 결정이 더 많이 들어 있다.

참고 링크

• Getting the Most Out of Your GPUs (PEARC ‘26)
• Princeton Research Computing: Utilization Policies
• Job Defense Shield: Cancel GPU Jobs
• Yale Center for Research Computing: Automated Detection of Idle Resources
• GitHub Codespaces: 수명주기