기술 · 실용 가이드
Python “Can’t pickle local object”? serializer를 바꾸기 전에 process 경계를 증명하세요
예외는 worker가 재구성하지 못한 object를 가리킵니다. start method, callable, argument graph, import path를 먼저 기록하세요.
process 경계를 넘는 object를 직렬화하거나 이름으로 다시 찾지 못한 상태다. nested function, lambda, closure, bound method, lock, socket 또는 이를 가진 instance가 원인일 수 있다.
실제 production launcher에서 Python/library version, start method, module, qualified name, argument type, fresh child import를 한 ledger에 기록한다.
1. 실제 launcher와 start method 고정
같은 script, test runner, notebook, IDE, service 또는 framework로 재현하고 python -VV, sys.executable, context, get_start_method()를 기록한다.
traceback 전체를 보존하고 start, map, submit, queue, result, worker startup 중 첫 실패 지점을 표시한다.
2. 정확한 callable과 object graph 확인
type(fn), __module__, __qualname__을 기록한다. <locals>나 <lambda>는 module attribute로 해석할 수 없다는 직접 증거다.
callable과 각 argument를 따로 시험하고 secret 대신 첫 실패 type과 안전한 구조 path만 기록한다.
3. fresh interpreter에서 import 증명
최소 worker entrypoint를 module top level로 옮기고 process creation을 main guard 아래에 두며 production package path에서 import 가능하게 한다.
같은 interpreter와 working directory의 새 process에서 module과 qualified name을 해석한다.
4. parent resource와 plain task data 분리
bound method는 instance 전체를 포함할 수 있다. lock, file, socket, client, connection은 child에서 만들거나 small config로 바꾼다.
argument가 실패하면 plain record로 줄이고 initializer나 worker 안에서 resource를 재구성한다.
5. start method와 serializer 변경을 범위 결정으로 취급
fork로 Linux test 하나가 통과해도 portable contract는 아니며 threaded library에서 위험할 수 있다.
cloudpickle과 dill은 dependency, compatibility, deserialization trust를 바꾸므로 명시적 요구에서만 사용한다.
6. fresh-worker exit test
같은 production launcher와 start method로 작은 deterministic task를 실행해 import, input, result, clean exit를 검증한다.
interpreter, start method, qualified name, input schema, worker PID, result checksum, exit status를 기록한다.
