Python 3.14 브레이킹 체인지를 둘러싼 HN 격론 — "왜 또 깨뜨리냐" vs "원래 이래야 했다"

불이 붙은 주제: multiprocessing 기본값 변경

• Python 3.14에서 multiprocessing의 기본 시작 메서드가 POSIX에서 fork에서 forkserver로 변경됨
• fork는 99%는 되다가 1% 확률로 "미스터리하게 깨지는" 문제가 있었음 — 모듈 레벨 전역변수 복사, 로깅 꼬임, 스레드가 fork를 못 살아남는 등. 이 논의가 2020년부터 있었음
• 반발하는 쪽은 "30년 된 C/bash 코드는 아직도 돌아가는데 파이썬은 왜 계속 깨뜨리냐"는 입장
• 옹호하는 쪽은 "기본값은 대다수 사용자가 원하는 것을 반영해야 하고, 그게 바뀌면 기본값도 바뀌는 게 맞다. multiprocessing.set_start_method('fork') 한 줄이면 되는 거 아니냐"는 반론

2→3 전환의 상처가 아직도

• "Python 2→3 대전환 때 더 많은 문제를 고쳤어야 했다"는 의견에 대해, 반대편은 "오히려 2.x를 다른 사람에게 맡기고 완전히 갈라섰어야 했다. 결국 2.7을 만들고, 2.8 안 만들겠다고 구걸하고, 연장 지원까지 해줘야 했다"고 함
• Python 2→3 전환이 대규모 재작성이 필요했다는 통념에 대해 "마이너한 수정이었고 CPython이 제공한 도구로 자동화 가능했다"면서, UnicodeDecodeError가 인코딩 시 발생하는 미친 상황이 사라진 것만으로도 "논쟁의 여지 없이, 압도적으로 더 나은 파이썬이 됐다"고 반박

패키징 생태계에 대한 뼈 있는 지적

• venv에 대한 불만의 99%는 pip 탓이지 venv 탓이 아니라는 주장. venv는 그냥 패키지 놓는 장소 + Python이 그 장소를 인식하는 스킴일 뿐임
• pyproject.toml이 늦게 나왔다는 비판에 대해, Java의 Maven과 비교하는 건 불공평함 — Maven은 Java만 걱정하면 되지만 Python 패키징은 C, C++, FORTRAN, Rust까지 다뤄야 함
• 아직도 Flit으로 충분한 순수 Python 프로젝트가 레거시 setup.py 빌드를 쓰고 있는 현실. PyPI 톱10인 Requests조차 pyproject.toml이 있으면서도 빌드 설정은 setup.cfg에 넣어두고, 올해 소스 빌드가 깨진 적이 있음
• "사람들은 deprecation 경고를 안 읽고, 셋업을 깨뜨려야 비로소 움직인다. 그러면 움직이는 대신 불평하고 원래대로 되돌려 달라고 한다"는 Setuptools 메인테이너의 한탄이 와닿음