기본 콘텐츠로 건너뛰기

AArch64 JIT Relocation Fix

CPython AArch64 JIT 패치 노트 읽는 법: ‘관측되지 않은’ 버그라도 운영팀이 신경 써야 하는 이유 meta_description: CPython PR #148198(GH-146128)은 AArch64에서 JIT 코드의 상수 값이 부분적으로 손상될 수 있는 이론적 버그를 수정하기 위해, 문제 소지가 있던 “33rx” 릴로케이션 최적화(폴딩)를 제거했다. 관측 사례가 없어도 이런 패치가 중요한 이유(무증상 데이터 오염 가능성), 어떤 환경에서 의미가 커지는지(AArch64 + JIT 사용), 그리고 서비스 운영자가 지금 바로 할 수 있는 점검/롤백/테스트 체크리스트를 실무 관점에서 정리한다. meta_keywords: python,cpython,jit,aarch64,arm64,relocation,constant corruption,patch,stencil,optimizer,performance,stability,regression testing,release engineering,build,production,observability,risk meta_robots: index,follow 파이썬 릴리즈 노트나 PR을 보면 가끔 이런 문장이 나온다. “이 이슈는 theoretical이며, unmodified Python 인터프리터에서는 관측되지 않았다.” 대부분의 개발자는 여기서 스크롤을 내린다. “그럼 우리랑 상관 없겠네.” 근데 운영 관점에서는 오히려 반대로 읽는 게 맞다. 관측되지 않았다는 건, 관측이 어려운 종류 일 수도 있다 특히 이번 PR #148198(GH-146128)은 표현이 꽤 무섭다. AArch64 JIT 코드에서 상수 값이 “부분적으로 손상(partially corrupted)”될 수 있음 크래시가 아니라, 값이 조용히 틀어지는 유형은 재현이 어렵고 로그가 남기 힘들고 버그 티켓이 “가끔 결과가 이상함”으로 올라온다 그래서 이 글은 코어 구현 해설이 ...
최근 글

Base64 Padding Policy in Python 3.15

Python 3.15의 base64 ‘패딩 옵션’이 반가운 이유: URL-safe 토큰/서명 검증에서 자주 깨지는 지점 정리 meta_description: CPython PR #147974(gh-73613)는 Python 3.15에서 base64/base32 인코딩·디코딩에 padded 옵션을 추가해, ‘=’ 패딩이 없는 입력도 더 명확하게 처리할 수 있게 했다. 이 글은 왜 패딩이 문제를 만드는지(웹 토큰, URL-safe, 로그/전달 과정의 손실), 어떤 함수가 어떻게 바뀌는지(padded 기본값/strict 모드와의 관계), 그리고 서비스 코드에서 안전하게 마이그레이션하는 체크리스트를 정리한다. meta_keywords: python,base64,binascii,base32,padding,urlsafe,token,encoding,decoding,validation,strict_mode,ignorechars,migration,backward compatibility,security,web,jwt,cookie,api,python 3.15 meta_robots: index,follow 운영하다 보면 base64는 “그냥 인코딩”이 아니다. 토큰 쿠키 URL 파라미터 서명/검증용 바이트 이런 데서 base64가 슬쩍 끼고, 그 순간부터 장애가 ‘간헐적’으로 보이기 시작한다. 특히 자주 깨지는 패턴이 이거다. 어떤 환경에서는 잘 디코딩되는데 어떤 환경에서는 Incorrect padding 류 에러가 난다 대부분 원인은 같다. ’=’ 패딩이 중간 전달 과정에서 잘리거나, 아예 없는 형태로 들어오기 때문 최근 CPython에 들어간 PR 하나가 이 문제를 꽤 깔끔하게 정리했다. CPython PR #147974 (gh-73613): Base32/Base64 without padding 지원 핵심은 새로운 옵션 한 단어다. padded= 이번...

Constant Folding Guardrails

CPython 옵티마이저가 “컨테이너는 건드리지 말자”로 돌아선 이유: 상수 폴딩(constant folding) 안정화 포인트 meta_description: CPython PR #148090(gh-148083)은 옵티마이저가 특정 연산을 “순수(pure) 평가”로 상수 폴딩할 때, 좌변/키가 컨테이너(list/dict/set 등)일 수 있는 경우엔 더 보수적으로 동작하도록 바꾼 패치다. 이 글은 왜 이런 변경이 필요한지(운영 관점), 어떤 코드에서 차이가 날 수 있는지(멤버십/서브스크립트/해시 가능성), 그리고 팀이 지금 당장 할 수 있는 실전 체크리스트(테스트/릴리즈 노트/성능 기대치 관리)를 정리한다. meta_keywords: python,cpython,optimizer,constant folding,bytecode,jit,profiling,performance,semantics,container,hashable,frozenset,frozendict,membership,guardrails,regression tests meta_robots: index,follow 파이썬 성능 얘기에서 “옵티마이저가 알아서 해주겠지”라는 말이 종종 나온다. 그런데 실무에서 진짜 중요한 건 성능 자체보다 예측 가능성 이다. 빨라졌는데 결과가 달라 보이면(혹은 예외 타이밍이 달라지면) 팀은 결국 그 최적화를 꺼버리거나 업그레이드를 미루게 된다 최근 CPython 쪽에 “최적화는 하되, 컨테이너는 조심하자”라는 톤의 패치가 하나 들어갔다. CPython PR #148090 (gh-148083) 요지: 좌변(lhs)이 컨테이너 타입일 수 있는 경우엔 상수 폴딩을 더 보수적으로 이 글은 코어 개발자용 해설이 아니라, 왜 이런 결정이 실무적으로 좋은지 어떤 코드에서 영향을 받을 수 있는지 팀이 업그레이드/테스트를 어떻게 가져가면 좋은지 를 정리한다. 1) 상수 폴딩(constant folding)은 “빨...

Zoneinfo Security Patch

CPython `_zoneinfo` 힙 버퍼 오버플로우 수정(gh-145883): “시간대 파싱은 라이브러리에게 맡기고, 우리는 업데이트를 자동화하자” meta_description: CPython은 PR #148087(gh-145883)로 _zoneinfo 에서 발견된 두 가지 heap-buffer-overflow를 수정했고(3.14 백포트), 테스트도 함께 보강했다. zoneinfo는 PEP 615 기반으로 시스템 tzdata 또는 PyPI tzdata를 사용하므로, 서비스는 ‘시간대 데이터+파서’ 조합을 안전하게 운영해야 한다. 이 글은 무엇이 바뀌었는지(개념), 운영자가 지금 당장 할 일(업데이트/검증/컨테이너/CI), 그리고 zoneinfo를 안전하게 쓰는 실전 체크리스트를 정리한다. meta_keywords: python,zoneinfo,security,heap-buffer-overflow,timezone,tzdata,iana,pep 615,cpython,patch,upgrade,container,linux,windows,validation,CI,dependency meta_robots: index,follow “시간대 처리는 늘 골치 아프다”는 말이 있다. 그런데 더 골치 아픈 건, 시간대는 그냥 기능 문제가 아니라 보안/안정성 문제로도 번진다는 점이다. 이번에 CPython 쪽에서 그걸 상징적으로 보여주는 변경이 하나 들어갔다. gh-145883: _zoneinfo 의 두 가지 heap-buffer-overflow 수정 CPython PR #148087 (3.14 백포트, merged 2026-04-04) 여기서 중요한 건 “내가 zoneinfo를 직접 건드릴 일이 있냐”가 아니다. 대부분의 서비스는 zoneinfo를 이렇게 쓴다. 사용자/외부 데이터에 들어있는 time zone을 읽고 서버에서 datetime을 만들고 저장/표시/정렬/스케줄링에 쓴다 즉, 입력이 엮이는 순간부터 운영 ...

Base64 Without Padding in Python 3.15

Python 3.15에서 Base64/32 패딩 없이도 더 잘 된다: “len%4==0” 지옥을 끝내는 실전 디코딩 패턴 meta_description: Base64/32 디코딩에서 가장 흔한 실수는 패딩(=) 누락 처리다. CPython은 PR #147974(gh-73613)로 Base32/Base64의 “패딩 없는 입력”을 더 잘 다루도록 개선했고, 문서/테스트도 함께 보강됐다(3.15 WhatsNew 포함). 이 글은 패딩이 왜 생기는지, 어디서 깨지는지, 그리고 지금 당장(3.11~) 안전하게 운영하는 호환 디코딩 함수까지 실전 관점으로 정리한다. meta_keywords: python,base64,base32,padding,urlsafe,decode,encoding,binascii,token,jwt,webhook,compat,python 3.15,whatsnew,security,validation,error handling meta_robots: index,follow Base64 디코딩하다가 한 번쯤은 이런 코드가 나왔을 거다. s += "=" * (-len(s) % 4) 문제는 이게 “잘 되는 것처럼 보이는데, 종종 사고를 만든다”는 점이다. 어떤 입력은 Base64가 아니라 그냥 쓰레기인데도 통과해버리고 어떤 입력은 URL-safe 변형인데 표준 Base64로 처리하다가 깨지고 어떤 입력은 패딩이 없어도 정상인 케이스인데, 서비스마다 처리가 달라진다 최근 CPython PR 하나가 이 불편함을 정확히 겨냥했다. gh-73613: Base32/Base64에서 패딩 없는 입력을 지원/개선 CPython PR #147974 (merged 2026-04-04) 이 글은 “새 기능 소개”보다, 운영에서 바로 쓰는 패턴 위주로 정리한다. 1) 패딩(=)은 왜 생기고, 왜 자꾸 빠지나 Base64는 3바이트를 4글자로 바꾼다. 그래서 입력 길이가 3의 배수가 아닐 때 ...

uv 0.11.3 Operations Notes

uv 0.11.3 실전 업그레이드 포인트: `uv audit` 무시 규칙부터 workspace metadata까지 meta_description: uv 0.11.3(2026-04-01)는 기능 ‘추가’보다 운영 품질을 올리는 릴리스다. uv audit 에 --ignore / --ignore-until-fixed 가 들어오고, uv workspace metadata 가 lock의 의존성 정보를 더 보여주며, wheel/ABI 관련 에러 메시지도 더 친절해졌다. 이 글은 팀 repo에서 uv를 올릴 때 바로 쓰는 체크리스트(20분)와 CI 적용 팁을 정리한다. meta_keywords: python,uv,packaging,dependency,lockfile,workspace,metadata,audit,security,vulnerability,ignore,CI,uv publish,hashing,abi3,free-threaded,wheel,error,PEP,release meta_robots: index,follow uv는 “빠른 패키지 도구”로만 보면 끝이다. 실무에서 uv가 진짜 가치가 있는 지점은, 의존성/빌드/배포를 한 덩어리로 운영 할 때다. 그래서 uv 업그레이드는 릴리스 노트 한 줄 때문에 CI가 깨지는지(혹은 더 좋아지는지)를 바로 드러낸다. 이번 uv 0.11.3(Released 2026-04-01)는 큰 기능 쇼케이스보다, 운영 쪽에서 자주 부딪히는 포인트를 정리해 준 릴리스다. uv audit 에 --ignore 와 --ignore-until-fixed 추가(프리뷰) uv publish 에서 해시 계산 단계에 진행바 추가 uv workspace metadata 가 lock의 의존성 정보를 더 보여주도록 확장 빌드된 wheel 에러에서 플랫폼/ABI 관련 메시지가 더 읽히게 개선 이 글은 “릴리스 요약”이 아니라, 레포에서 안전하게 올리는 순서 로 정리한다. 1) 결론: 0.11.3은 ‘보...

Ruff 0.15.9 Upgrade Checklist

Ruff 0.15.9에서 ‘조용히’ 바뀐 것들: 린트/포맷 업그레이드 안전하게 하는 체크리스트 meta_description: Ruff 0.15.9(2026-04-02)는 큰 기능 추가보다 규칙/수정 안전성/포맷 옵션 같은 ‘업그레이드 때 사고 나는 지점’을 건드린 릴리스다. 이 글은 실제 프로젝트에서 ruff를 올릴 때 바로 쓰는 20분 체크리스트(잠금/preview 분리/unsafe fix 관리/노트북 W391/새 포맷 옵션)와 CI 적용 팁을 정리한다. meta_keywords: python,ruff,lint,formatter,format,pyflakes,pyupgrade,pycodestyle,preview,unsafe fix,CI,pre-commit,notebook,W391,F811,RUF010,nested-string-quote-style,UP012,UP018,SIM105 meta_robots: index,follow Ruff 업그레이드는 대개 “버전만 올리고 끝”이 아니다. 특히 팀/CI가 붙어 있는 프로젝트에서는, 릴리스 노트의 한 줄이 곧바로 빨간불(빌드 실패) 로 바뀐다. 이번 Ruff 0.15.9(2026-04-02)는 겉으로는 조용한 패치 릴리스처럼 보이는데, 실제로는 업그레이드 때 사고 나는 포인트 를 몇 군데 건드렸다. (preview) 타입 힌트가 붙은 변수 재선언을 F811 로 잡기 시작 fix의 안전성(unsafe) 표기 강화 ( RUF010 ) 노트북 셀에서의 W391 fix 동작 조정 포매터 옵션 추가: nested-string-quote-style 이 글은 “릴리스 노트 요약”이 아니라, 프로젝트에서 안전하게 올리는 순서 로 정리한다. 1) 먼저 결론: 0.15.9 업그레이드는 ‘preview 분리’가 핵심 0.15.9에서 가장 실무적으로 체감 큰 변화는 “preview 모드에서 규칙이 조금 더 까다로워질 수 있다”는 점이다. 대표적으로 릴리스 노트에 있는 이 항...