pip 26.3, pylock.toml에서 선택 의존성과 개발 그룹 설치 지원
PyPA가 공개한 pip 26.3은 pylock.toml에서 선택 의존성과 비기본 의존성 그룹을 골라 설치하는 기능을 추가했습니다. 여러 구성을 한 잠금 파일에 담으려면 생성 도구가 해당 항목을 기록해야 하며, pip의 pylock 설치 지원은 실험 단계입니다.
최신기사
AI, 개발 도구, 오픈소스, 보안과 인프라의 변화와 이용 조건을 설명하는 최신 기사와 해설입니다.
환경 변수 사고는 워크스페이스·조직, 악성 패키지는 실행 호스트가 대응 기준
Railway는 복호화된 변수를 특정하지 못해 최대 1.85%의 워크스페이스를 잠재적 영향 범위로 제시하고 폭넓은 교체를 권고했습니다. Trigger.dev는 일부 조직의 환경 변수 무단 접근을 확인해 영향 계정 소유자에게 안내했습니다. LiteLLM은 악성 버전과 배포 시간, 이를 실행한 호스트를 대응 기준으로 삼았습니다.
Austin 4.1, asyncio 작업별 실행과 대기 흐름을 타임라인으로 추적
Austin 4.1.0은 CPython 3.14 이상에서 asyncio 작업과 await 관계를 연결해 작업별 실행·대기 흐름을 보여줍니다. 함수별로 시간을 합산하는 flame graph가 놓치는 지연 원인을 VS Code 확장 프로그램의 작업 타임라인에서 살펴볼 수 있습니다.
PyPI가 Passlib 소유권을 이전하고 포크는 호환성 수정을 이어갑니다
PyPI는 연락이 끊긴 기존 관리자의 Passlib 소유권을 새 관리자에게 이전했습니다. 새 관리자의 포크는 Python 3.13과 bcrypt 호환성 등을 수정해 libpass로 배포되고 있지만, 제안된 설정 API 재설계의 출시 여부는 확인되지 않습니다.
2026년 파이썬 타이핑 설문 결과
1,794명이 참여한 2026년 Python Typing Survey에서 타입 힌트 사용률은 최근 3년간 비슷했지만, 타입 검사기 선택은 빠르게 달라졌습니다. 응답자 65.1%가 서드파티 라이브러리의 타입 정보 부족을 어려움으로 꼽았고, AI 도구와 타입 검사기를 함께 쓰는 사례도 늘었습니다.
AWS Lambda Python 3.10 지원 종료: 10월 31일 이후 Python 3.12 이상으로 옮길 때 확인할 점
AWS Lambda의 Python 3.10 런타임은 2026년 10월 31일 지원 종료 단계에 들어갑니다. 기존 함수는 계속 실행되지만 보안 업데이트와 기술 지원이 끝나며, 2027년부터 생성과 업데이트도 차례로 막힙니다. Python 3.12 이상으로 옮길 때는 Amazon Linux 2023용 네이티브 의존성과 패키지 호환성을 점검해야 합니다.
파이썬 실험적 JIT, CPython에서 제거될 전망
CPython 3.13에 들어간 실험적 JIT의 표준화 제안 PEP 836이 작성자들에 의해 철회됐습니다. Python 운영위원회는 지원 계획과 성능 기준, 호환성·보안 검토가 충분히 구체적이지 않다고 판단했고, JIT 코드는 CPython 주 저장소에서 제거될 전망입니다.
Python 3.14의 concurrent.interpreters, GIL 작업 시간을 3.6초에서 0.9초로 줄이다
Python 3.14의 concurrent.interpreters로 CPU 작업을 네 개의 서브인터프리터에 나누자 네 스레드보다 훨씬 빠르게 처리됐습니다. 다만 인터프리터 하나에는 동시 호출을 하나만 허용하고 시작 비용도 프로세스보다 높아, 데이터 전달 방식과 작업 수명에 맞춘 설계가 필요합니다.
Type Server Protocol: Python 타입 분석 서버 프로토콜
Microsoft가 Python 타입 분석 결과를 구조화된 데이터로 주고받는 JSON-RPC 프로토콜 TSP를 공개했습니다. LSP 연결과 워크스페이스 상태를 활용해 타입·import 정보를 질의하며, 스냅샷과 선택적 읽기 전용 연결로 결과의 유효성과 동시 요청을 관리합니다.
Python 3.15.2, 3.14.10, 3.13.18, 3.12.16, 3.11.18 보안 업데이트 공개
Python이 지원 중인 다섯 버전의 보안 업데이트를 공개했습니다. 침해된 eMudhra 중간 인증기관 키를 차단했으며, 일반적인 pip 사용은 pip를 아직 업데이트하지 않아도 해당 키를 악용한 공격으로부터 보호됩니다.
마이크로소프트, 메타와 협력해 VS Code Pylance에 Pyrefly 지원
마이크로소프트가 Language Server Protocol(LSP)을 확장한 Type Server Protocol(TSP)을 공개하고, 메타의 Python 타입 검사기 Pyrefly를 VS Code의 Pylance에서 사용할 수 있게 했습니다. 기본 검사기는 Pyright로 유지되며, 사용자는 Pylance의 편집기 기능과 GitHub Copilot 통합을 그대로 두고 진단 엔진을 선택할 수 있습니다.
Node.js를 넘어선 Brotli 취약점, 어디까지 점검하고 디코딩은 끌 수 있나
Node.js의 런타임 업데이트로 드러난 Brotli 디코더 결함은 같은 C 코드를 포함한 Python 패키지에도 영향을 줍니다. 각 환경의 입력 경로와 수정 버전, Brotli 디코딩을 끄는 선택지를 살펴보되, 기능 비활성화가 패치를 대체하는지는 구분해야 합니다.
Broccoli2Shell: Node.js·Python 등의 Brotli 디코더 원격 코드 실행 취약점 (CVE-2026-111497)
Brotli의 C 디코더가 잘못된 블록 전환을 처리하는 과정에서 버퍼를 넘겨 쓰는 취약점이 발견됐습니다. 공격자가 조작한 압축 데이터를 디코딩하는 Node.js와 Python 앱 등이 영향을 받으며, 수정된 런타임과 라이브러리로 올리고 관련 프로세스를 재시작해야 합니다.
Node2Shell이 HTTP2Shell로 확산되다
Brotli 디코더 취약점 CVE-2026-111497은 Node.js뿐 아니라 Python 패키지와 여러 HTTP 구성요소에도 영향을 줍니다. 취약 버전과 패치 방법, Brotli 처리를 잠시 끄는 우회책을 정리합니다.
uv와 ty를 통합하기
Astral이 패키지·환경 관리 도구 uv와 타입 검사기 ty의 실험적 연동을 공개했습니다. PEP 723 스크립트마다 선언된 환경을 기준으로 검사하고, uv check 명령으로 프로젝트 환경 준비와 타입 검사를 한 번에 실행합니다.
Node2Shell 취약점, Python의 Brotli·brotlicffi 패키지에도 영향
Node2Shell(CVE-2026-111497)은 Node.js만의 문제가 아니라 공유 Brotli C 디코더의 취약점입니다. PyPI의 Brotli와 brotlicffi도 영향을 받으며, 글은 패치 버전과 의존 환경의 확인·업데이트 방법을 제시합니다.
PyPI의 LiteLLM 1.107.0에 자격 증명 탈취기와 백도어가 삽입됐습니다
PyPI에 배포된 LiteLLM 1.107.0에는 Python 프로세스가 시작될 때 실행되는 자격 증명 탈취기와 원격 코드 실행 백도어가 들어 있었습니다. SafeDep은 공개 저장소에 없는 파일이 비공개 릴리스 파이프라인에서 공격자가 수정한 소스로 빌드됐을 가능성을 중간에서 높은 신뢰도로 판단했습니다. PyPI는 해당 버전을 제거했으며, 1.106.2와 두 릴리스 후보 버전은 깨끗한 것으로 확인됐습니다.
개발 로그 #26 libp2p의 깊은 곳에서: DHT 접두사와 Yamux 리셋 수정
Python libp2p에서 Kademlia DHT의 사용자 지정 프로토콜 접두사가 네트워크 통신에 반영되지 않는 버그와 Yamux의 원격 리셋이 정상적인 EOF로 보고되는 버그를 수정하는 PR을 열었습니다. 두 PR은 아직 검토를 기다리고 있으며, Python 3.14 빌드 문제와 Nim 기반 상호 운용성 CI 오류를 포함한 이슈도 등록했습니다.
Nordwand Mono, 코딩을 위한 모노스페이스 글꼴
Nordwand Mono는 Univers의 인상과 JetBrains Mono의 비율을 참고해 Python으로 만든 코딩용 모노스페이스 글꼴입니다. 글리프와 높이 같은 지표를 직접 조정해 글꼴을 생성할 수 있으며, 최소한의 화살표 합자 두 가지를 제공합니다.
의존성 설치의 신뢰는 어디서 깨지나: 이름, 패키지 매니저, 바이너리
AI가 제안한 패키지 이름이 실제로 존재하는지, 패키지 매니저가 내려받은 파일의 변경을 막는지, 배포된 바이너리가 소스와 일치하는지는 서로 다른 검증 문제입니다. 세 자료를 비교하면 한 단계의 확인만으로는 다음 단계의 위험까지 해결할 수 없으며, 각 경계에서 무엇을 확인하는지가 달라집니다.