Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

"Python's success is not despite its simplicity. It's because of it." — Guido van Rossum (BDFL, 2018년 사임)

2008년 12월 3일, Python 3.0이 출시되었다. 그리고 Python 커뮤니티는 12년간 분열되었다. "2로 남을 것인가, 3으로 갈 것인가." 많은 이들이 Python의 종말을 예언했다. "Ruby on Rails에 웹을 내주고, Scala/Kotlin에 JVM을 내주고, Go에 서버를 내줬다"고.

그러나 2012년 AlexNet, 2015년 TensorFlow, 2018년 BERT, 2022년 ChatGPT... AI/ML 혁명이 Python을 왕좌로 올렸다. 2024년 GitHub Octoverse에서 Python이 JavaScript를 제치고 1위를 차지했다. 2025년 Stack Overflow에서 사용률 1위.

이 글은 "단순한 파이썬 스크립트"에서 "Python의 깊이와 미래"로 넘어가려는 사람을 위한 지도다.

1. Python의 기적적 재기 — 타임라인

1991 — 탄생

Guido van Rossum이 크리스마스 휴가에 시작
ABC 언어의 후속, "실용적인" 언어 목표
이름은 Monty Python에서

2008 — 2 vs 3 분열의 시작

3.0 출시, 호환성 깨는 전환
print → print(), str ≠ bytes, range는 이터레이터
사람들이 3으로 안 넘어감

2015 — Python 2 사망 공지

PSF가 "2020년 지원 종료" 공식화

2020 — Python 2 EOL

12년 분열 종료
그동안 NumPy, Pandas, scikit-learn이 Python 3에 올인
AI/ML이 Python으로 수렴

2022 — ChatGPT

OpenAI, HuggingFace 전부 Python
Python이 "AI의 표준 언어"로 굳어짐

2024 — GitHub 1위

JavaScript를 처음으로 제침
AI 폭발 + 데이터 과학 + 교육용

2025 — 현재

3.13에서 GIL 실험적 제거
JIT 도입
Astral(uv, ruff)로 도구 생태계 혁명
Mojo 부상

2. CPython 내부 — 어떻게 작동하는가

CPython = 기본 구현

Python 코드 → 바이트코드 → CPython 인터프리터가 실행
C로 쓰여짐 (이름의 유래)
표준 구현

실행 파이프라인

source.py
  ↓ (파싱)
AST
  ↓ (컴파일)
bytecode (.pyc)
  ↓ (실행)
ceval.c의 거대한 switch 문

ceval.c — 인터프리터의 심장

Python 코어 = 3000줄짜리 C 함수
각 바이트코드를 dispatch
많은 최적화 시도의 무대

바이트코드 보기

import dis
def f(x):
    return x * 2 + 1

dis.dis(f)

  2           0 LOAD_FAST                0 (x)
              2 LOAD_CONST               1 (2)
              4 BINARY_MULTIPLY
              6 LOAD_CONST               2 (1)
              8 BINARY_ADD
             10 RETURN_VALUE

Reference Counting

모든 객체에 refcount 필드
0이 되면 즉시 해제
순환 참조는 주기적 GC로 수집

GIL — Global Interpreter Lock

이것이 Python 성능 역사의 중심이다.

3. GIL — 30년의 축복과 저주

GIL이란

한 시점에 하나의 스레드만 Python 바이트코드를 실행할 수 있게 하는 락.

왜 존재하나

CPython의 refcount는 thread-safe 아님
모든 객체 작업에 세밀한 락 걸면 싱글스레드 성능 절반
GIL로 하나의 거대한 락만 잡음 → 빠름

결과

장점:

C extension 작성 쉬움
싱글스레드 코드 빠름
CPython 구현 단순

단점:

멀티코어 병렬 처리 안 됨 (CPU 바인딩)
I/O는 블로킹 중 GIL 해제 → OK
**"Python은 느리다"**는 인식의 주범

우회 방법들

multiprocessing — 프로세스 분리, 오버헤드 큼
asyncio — I/O 집중에만
C 확장 (NumPy, PyTorch) — GIL 해제하고 네이티브 실행
Cython — C로 컴파일

30년의 "GIL 제거 시도 실패사"

Unladen Swallow (2009, Google) — 실패
Greg Ewing의 수많은 실험
Larry Hastings의 Gilectomy (2016) — 실패
2023, Sam Gross의 PEP 703 — 드디어 성공

4. PEP 703 — Free-Threaded Python (3.13)

Sam Gross의 nogil 포크

Meta 엔지니어 (당시)
2021년 Python 3.9를 포크해서 GIL 없이 구현
싱글스레드 10% 느림, 멀티스레드 N배 빠름
코어 팀이 놀람 → PEP 703 제안

3.13 (2024년 10월)

실험적 Free-Threaded 빌드 (python3.13t)
기본 빌드는 여전히 GIL
Opt-in

3.14-3.15 — 점진 안정화

주요 C 확장(NumPy, PyTorch) nogil 호환 작업
에코시스템 준비

목표 — 2026-2027

GIL 없는 빌드가 기본값
기존 GIL 빌드는 호환성 플래그로 유지

싱글스레드 성능 비용

기존 대비 10-20% 느림
Biased Reference Counting으로 완화
PEP 659 (Adaptive Interpreter)와 결합

C extension 저자의 부담

기존 GIL 가정 코드 재검토
락 추가 또는 thread-local 관리
numpy/scipy/torch 등 이미 작업 완료

5. Python이 갑자기 빨라진 이유 — Faster CPython (3.11+)

프로젝트 시작

Mark Shannon이 주도, Microsoft 후원
Guido van Rossum도 참여 (2020년 은퇴 번복)
목표: 5년 내 5배

3.11 — 평균 25%, 최대 60% 빠름

주요 최적화:

Specialized bytecode — 자주 실행되는 타입에 특화
Zero-cost exceptions — try/except 진입 비용 제거
Frame 객체 경량화 — 함수 호출 3배 빠름
Stack frame inlining

3.12 — 더 빠르게

PEP 709: comprehension inlining (2배 빠름)
Per-Interpreter GIL (PEP 684) — 여러 interpreter 분리
f-string 성능 개선

3.13 — JIT + Free-Threaded

Copy-and-patch JIT — Brandt Bucher 주도
아직 성능은 작지만 기반 마련
미래: 정교한 JIT로 큰 향상

JIT의 원리 — Copy-and-patch

전통 JIT(V8, Java): 바이트코드 → 네이티브 코드 동적 생성 (복잡)
Copy-and-patch: 미리 준비된 "스텐실(stencil)"을 복사 + 주소 패치
훨씬 단순, 시작은 작지만 확장 가능

6. 타입 힌트의 진화

PEP 484 (2014) — 타입 힌트 도입

def greet(name: str) -> str:
    return f"안녕, {name}"

런타임에는 영향 없음 (주석에 가까움).

PEP 526 — 변수 타입 (2016)

age: int = 30
names: list[str] = []

PEP 585 (3.9) — 기본 제네릭

# 이전
from typing import List, Dict
def f(x: List[int]) -> Dict[str, int]: ...

# 3.9+
def f(x: list[int]) -> dict[str, int]: ...

PEP 604 (3.10) — Union 간편 문법

# 이전: Optional[str] 또는 Union[str, None]
# 3.10+:
def f(x: str | None): ...

TypedDict (3.8+)

from typing import TypedDict

class User(TypedDict):
    name: str
    age: int

u: User = {'name': '김', 'age': 30}

JSON 스키마처럼 딕셔너리에 타입 부여.

Protocol (3.8+) — 구조적 타이핑

from typing import Protocol

class Greetable(Protocol):
    def hello(self) -> str: ...

def greet(x: Greetable) -> None:
    print(x.hello())

# Kim은 Greetable을 상속하지 않아도 OK (구조적 타이핑)
class Kim:
    def hello(self) -> str: return "안녕"

greet(Kim())  # OK

Generic (3.12의 PEP 695)

# 3.12+ 간결한 문법
def first[T](items: list[T]) -> T:
    return items[0]

class Stack[T]:
    def push(self, item: T) -> None: ...

TypeGuard와 narrow (3.10+)

from typing import TypeGuard

def is_str_list(val: list) -> TypeGuard[list[str]]:
    return all(isinstance(x, str) for x in val)

def process(items: list):
    if is_str_list(items):
        for s in items: print(s.upper())  # str로 narrow됨

7. 타입 체커 전쟁 — mypy, pyright, pyrefly

mypy — 원조 (2012)

Jukka Lehtosalo, 박사 논문에서 시작
Dropbox 입사 후 Python 공식 협업
느림 (Python으로 쓰여짐)

pyright — VSCode의 무기 (2019)

Microsoft, Eric Traut 주도
TypeScript로 구현, 매우 빠름
Pylance(VSCode 확장)의 엔진
대규모 프로젝트의 표준

pyrefly (2025) — Meta의 Rust 체커

2025년 Meta 공개
Rust로 구현, pyright보다 4-10배 빠름
점진적 호환성
아직 초기, 안정화 과정

비교

측면	mypy	pyright	pyrefly
구현 언어	Python	TypeScript	Rust
속도	느림	빠름	매우 빠름
VSCode 통합	플러그인	네이티브(Pylance)	작업 중
엄격성	기본 완화	엄격 옵션 많음	pyright 유사
커뮤니티	크다	크다	성장중

8. Astral의 Rust 혁명 — uv와 ruff

배경

2022년까지 Python 도구는 파편화:

린트: flake8, pylint
포맷: black, autopep8, isort
패키지: pip, poetry, pipenv, conda
빌드: setuptools, flit, hatch

Charlie Marsh의 Astral

전 Spring(now acquired) 엔지니어
"Python tooling should be fast. Rust-fast."
2022년 ruff 공개

ruff — 린터+포맷터

Rust로 작성, flake8/isort/pylint의 800+ 규칙 구현
기존 도구보다 10-100배 빠름
대형 프로젝트를 1초 이내 린트
2024년 사실상 표준

ruff format — Black 대체

Black 호환
10배 빠름
2024년 안정화

uv — pip/poetry 대체 (2024)

rust 기반 Python 패키지 매니저
pip보다 10-100배 빠름
pipx, pyenv, virtualenv도 대체
단일 바이너리

# 프로젝트 초기화
uv init

# 의존성 추가 (pip install + pyproject.toml 업데이트)
uv add requests

# 의존성 설치
uv sync

# 스크립트 실행 (자동으로 venv 활성)
uv run python script.py

# Python 버전도 자동 관리 (pyenv 대체)
uv python install 3.13

충격적 속도

poetry lock 30초 → uv lock 0.3초
pip install 전체 ML 스택 3분 → uv sync 15초

2025 채택

FastAPI, LangChain 등 주요 프로젝트가 uv 추천
GitHub Actions 캐시 통합
Python 도구의 미래는 Rust라는 인식

9. pytest와 현대 테스트

pytest — 사실상 표준

def test_add():
    assert add(2, 3) == 5

@pytest.fixture
def user():
    return User(name="Kim")

def test_greet(user):
    assert user.greet() == "안녕, Kim"

표준 unittest보다 훨씬 간결. Fixture, parametrize, hook이 강력.

pytest-xdist — 병렬 실행

pytest -n auto  # CPU 코어 수만큼

hypothesis — Property-based Testing

from hypothesis import given, strategies as st

@given(st.integers(), st.integers())
def test_add_commutative(a, b):
    assert add(a, b) == add(b, a)

Haskell QuickCheck 영향. 수백 개 케이스 자동 생성.

coverage.py

coverage run -m pytest
coverage report --fail-under=80

10. AI/ML 스택 — Python이 왕이 된 이유

NumPy (2006) — 행렬의 황제

C/Fortran으로 쓴 벡터화된 연산
BLAS/LAPACK 활용
Python에 과학 계산을 가져옴

Pandas (2008)

DataFrame — 행+열 구조화 데이터
R의 data.frame 영감
데이터 분석의 표준

scikit-learn (2007)

전통적 ML (회귀, 분류, 클러스터링)
교육용/프로덕션 모두

TensorFlow (2015) vs PyTorch (2016)

초기: TensorFlow 주도
2019-: PyTorch가 학계/연구에서 압승
2024-: PyTorch 2.x로 torch.compile, 사실상 표준

PyTorch의 우아함

import torch
import torch.nn as nn

class MLP(nn.Module):
    def __init__(self):
        super().__init__()
        self.layers = nn.Sequential(
            nn.Linear(784, 256),
            nn.ReLU(),
            nn.Linear(256, 10),
        )
    
    def forward(self, x):
        return self.layers(x)

model = MLP()
optimizer = torch.optim.Adam(model.parameters())

동적 그래프
Python-first 인터페이스
torch.compile로 2-3배 자동 가속

JAX

Google Research, 함수형 ML
자동 미분 + XLA 컴파일
TPU 최적화
DeepMind 표준

HuggingFace Transformers

2019년 공개
BERT, GPT 등 사전 훈련 모델 표준 인터페이스
수십만 모델 호스팅
LLM 시대의 pip install

LangChain / LlamaIndex

LLM 애플리케이션 프레임워크
RAG, 에이전트, 체인
2023-2024 폭발적 성장

11. 웹/서버 Python

Django (2005) — 배터리 포함 풀스택

ORM, admin, auth 내장
Instagram, YouTube 등이 사용
안정성과 생산성

Flask (2010) — 마이크로

작고 유연
교육/프로토타입 인기

FastAPI (2018) — 현대적 표준

Starlette + Pydantic
타입 힌트 기반 자동 문서
비동기 네이티브
OpenAI, Uber 등 채택

from fastapi import FastAPI
from pydantic import BaseModel

class User(BaseModel):
    name: str
    age: int

app = FastAPI()

@app.post("/users")
async def create_user(user: User) -> User:
    return user

이 30줄로 OpenAPI 문서, 타입 검증, 비동기 서버가 완성.

Starlette + Uvicorn

ASGI (비동기 WSGI)
FastAPI의 기반
C10K 문제 해결

12. 대안 인터프리터 — CPython 아닌 Python

PyPy

JIT 기반 Python
일부 케이스 10배 빠름
NumPy 호환성 문제로 ML에는 못 씀
순수 Python 코드에는 훌륭

Mojo (2023)

Chris Lattner(LLVM, Swift 창시자) 주도
Python의 슈퍼셋 + 시스템 프로그래밍
MLIR 기반 컴파일
벤치마크에서 Python 대비 35000배 빠른 경우
2024년 오픈소스화, 2025년 주류 진입 중

GraalPython

Oracle GraalVM의 Python
JVM 통합 가능
성능 PyPy 수준

Faster-CPython 팀

Microsoft가 Guido 포함 지속 투자
CPython 자체를 5배로가 목표
2028년까지 로드맵 있음

13. 현실의 Python 성능 최적화

1단계 — 프로파일링

import cProfile
cProfile.run('my_function()')

또는 py-spy, scalene 같은 현대 도구.

2단계 — 벡터화

# 느림
result = [x * 2 for x in huge_list]

# 빠름
import numpy as np
arr = np.array(huge_list)
result = arr * 2

3단계 — 네이티브 코드

Cython: Python + C 혼합
pybind11: C++ 바인딩
PyO3: Rust 바인딩 (2024년 급성장)
Numba: JIT 데코레이터

4단계 — 멀티프로세싱 / asyncio

# CPU 바인딩
from multiprocessing import Pool
with Pool(8) as p:
    results = p.map(f, items)

# I/O 바인딩
import asyncio
results = await asyncio.gather(*[fetch(url) for url in urls])

5단계 — 프리 스레디드 (3.13+)

import threading
# GIL 없는 빌드에서는 진짜 병렬

14. 2025년 Python 생태계 맵

필수 도구

uv — 패키지 매니저 (pip/poetry 대체)
ruff — 린터 + 포맷터
pyright/pyrefly — 타입 체커
pytest — 테스트
pydantic — 데이터 검증

웹/API

FastAPI — API
Django — 풀스택
Flask — 작은 서비스
Starlette + Uvicorn — ASGI

데이터/ML

NumPy, Pandas — 기본
Polars — Rust 기반 Pandas 대안 (2024년 폭증)
DuckDB — 임베디드 OLAP
PyTorch, JAX — 딥러닝
Transformers, LangChain — LLM

운영

Rich — 아름다운 터미널 출력
Textual — TUI 앱
Typer — CLI (FastAPI 쌍둥이)

15. 안티패턴 TOP 10

pip install -r requirements.txt만으로 재현 — uv/poetry lock 써라
global state 남발 — 테스트 지옥
mutable default arg — def f(x=[]) 금지, 공유됨
except: 모든 에러 잡기 — 타입 명시
list comprehension vs for의 과도 대비 — 가독성 우선
type hint 없이 대규모 코드 — 장기 유지보수 어려움
import * — 네임스페이스 오염
synchronous requests를 FastAPI에서 — httpx.AsyncClient
설치 스크립트를 setup.py로 — pyproject.toml 표준
Python 2 코드 유지 — 2020년 EOL, 마이그레이션

16. Python 체크리스트

마치며 — "뱀이 왕좌에 올랐다"

2012년 HackerNews에서 "Python is dead"라는 글이 주기적으로 올라왔다. 2025년, 같은 플랫폼에서 "Python이 너무 많은 곳에서 쓰인다"는 불평이 올라온다. 12년 만의 반전이다.

Python이 살아남은 이유는 단순하다: 읽기 쉽고, 배우기 쉽고, "거의" 뭐든 할 수 있다. AI 연구자가 새 아이디어를 3시간 만에 구현할 수 있어서, 주피터 노트북에서 실험한 코드를 그대로 프로덕션에 올릴 수 있어서, 수많은 라이브러리가 "import"만으로 작동해서.

그리고 2025년, 부족했던 마지막 조각이 채워지고 있다:

속도 — Faster CPython + JIT + Mojo
동시성 — PEP 703의 free-threaded Python
도구 UX — Astral의 uv/ruff Rust 혁명
타입 안전성 — pyrefly, pydantic v2
배포 — Docker + uv의 5초 이미지 빌드

"Python was never the best language. It was just the right language, at every moment it needed to be." — Luciano Ramalho (Fluent Python 저자)

다음 글 예고 — 현대 웹 성능의 과학 — Core Web Vitals, INP, RUM, Lighthouse까지

Python이 "어떻게 빨라지고 있나"라면, 웹 성능은 "왜 내 사이트가 느린가"에 답한다. 2024년부터 **INP(Interaction to Next Paint)**가 LCP와 함께 Core Web Vitals 3대 지표로 공식화되었다. 다음 글에서는:

Core Web Vitals 진화 — FID → INP (2024)
LCP, CLS, INP — 각 지표의 실제 측정
Critical Rendering Path — HTML/CSS/JS가 화면에 도달하는 여정
RUM vs 합성 모니터링 — 진짜 사용자 데이터
Long Task와 메인 스레드 — INP의 적
Partial Hydration, Islands, Qwik Resumability — 해결 전략
Image/Font 최적화 — AVIF, WebP, font-display
HTTP/3 + Early Hints
Speculation Rules API — Chrome의 prerendering
Lighthouse vs CrUX — 측정의 정치
2025 웹 성능 도구 스택 — Vercel Analytics, Speedscope, PerfEtto

"왜 느린가"에 과학적으로 답하는 여정.

"Python is syntactic sugar on top of numpy which is syntactic sugar on top of CUDA which is syntactic sugar on top of silicon. The whole AI industry runs on sugar." — Anonymous tweet (2024)