Python GIL

TL;DR

• GIL은 CPython 인터프리터가 유저 공간에서 관리하는 잠금 — 한 순간 하나의 thread만 바이트코드를 실행, 커널은 존재를 모름
• 존재 이유는 참조 카운팅 — refcount race를 GIL 하나로 직렬화해 막고, GIL이 지키는 건 개발자 데이터가 아닌 인터프리터 내부 상태
• thread의 CPU 병렬은 막히지만 I/O 중엔 풀려 I/O 동시성은 가능, 3.13부터 free-threading 실험 중

AI-assisted

---

1. GIL이란 무엇인가

GIL(Global Interpreter Lock)은 **CPython 인터프리터 안에 있는 하나의 뮤텍스**다. 규칙은 단순하다: Python 바이트코드를 실행하려면 이 잠금을 쥐어야 하고, 잠금은 하나뿐이라 한 순간에 하나의 thread만 순수 Python 코드를 실행한다.

• 위치: CPython 인터프리터 내부, 유저 공간이다. OS나 프로세스의 표준 속성이 아니라, CPython이라는 프로그램이 자기 메모리에 든 락 객체다.
• 범위: CPython 프로세스마다 하나. 그래서 multiprocessing으로 프로세스를 나누면 각자 독립 GIL이 생겨 우회된다.
• 강제 주체: CPython 인터프리터 코드 자신. 바이트코드 실행 루프에서 GIL을 acquire하고, 일정 간격이나 I/O 진입 시 release한다.

---

2. 왜 있나 — 참조 카운팅을 지키려고

핵심 이유는 CPython의 메모리 관리 방식인 참조 카운팅(reference counting)이다. 모든 객체가 “지금 몇 곳에서 참조되는지”를 세는 카운터(refcount)를 갖고 이 값이 0이 되면 즉시 해제된다. Python에선 모든 게 객체라, 변수 대입·함수 전달마다 이 refcount가 쉴 새 없이 오르내린다.

문제는 refcount 갱신이 원자적이지 않다는 점이다(읽고 → 증가 → 쓰기). 여러 thread가 같은 객체의 refcount를 동시에 건드리면 race condition이 생긴다.

• 카운트가 틀어져 너무 일찍 해제 → use-after-free 크래시
• 또는 해제가 안 됨 → 메모리 누수

GIL은 이걸 한 번에 막는다. 한 순간 하나의 thread만 실행하니 refcount 조작이 직렬화되고 락 하나로 모든 객체의 refcount를 한꺼번에 보호한다.

"직렬화"의 뜻 — serialize

여기서 직렬화는 연산을 한 줄로 세워 순차 실행을 강제한다는 뜻(serialize)이다. 객체를 바이트 스트림으로 바꾸는 데이터 직렬화(pickle·JSON)나 DB의 serializable 격리 수준과는 이름만 같고 무관하다.

GIL 없이 객체마다 락을 걸면?

가능은 하지만 단일 thread 성능이 폭락한다. Python은 객체를 워낙 자주 만들고 참조해서 refcount 갱신마다 락이나 atomic 연산을 걸면 그 오버헤드가 막대하다. GIL 하나로 퉁치는 편이 단일 thread에선 훨씬 빠르다.

비유하면, 객체마다 “몇 명이 쓰는지” 적는 방명록(refcount)이 있다. 여러 일꾼이 동시에 숫자를 고치면 틀어진다. GIL은 “방명록을 고치려면 하나뿐인 펜을 쥐어야 한다”는 규칙이라 자연히 직렬화된다. GIL 없이 하려면 수백만 개 방명록마다 자물쇠를 달고 매번 잠그고 풀어야 하는데, 그게 더 느리다.

---

3. 커널은 GIL을 모른다

GIL은 유저 공간(인터프리터)에서만 관리된다. 커널이 보는 것은 그냥 여러 OS thread(리눅스의 task_struct)일 뿐이다.

• GIL을 기다리는 thread는, 커널 눈에는 “어떤 유저 공간 동기화 객체를 기다리며 sleep 중인 thread”로만 보인다. 그게 “GIL”이라는 의미는 커널이 모른다.
• 즉 “이 thread가 GIL에 막혔다”를 아는 것은 커널이 아니라 CPython 인터프리터다.

건물 관리인(커널)이 일꾼(thread)들을 방(코어)에 배치하지만 회사 내부 규칙인 “기록 펜(GIL)“은 회사(인터프리터)가 자체적으로 만든 것이라 관리인은 그 존재를 모르는 것과 같다.

---

4. GIL이 지키는 것 vs 개발자가 지키는 것

“공유 문제는 개발자가 lock으로 처리하면 되지 않나”라는 의문이 자연스럽다. 여기엔 두 층위가 있다.

• 개발자의 데이터(내 변수·자료구조): 이건 개발자가 lock으로 지키는 게 맞다. 그리고 GIL이 있어도 이건 여전히 개발자 몫이다. GIL이 있다고 애플리케이션 레벨 race condition이 다 사라지지 않는다.
• 인터프리터 내부 상태(refcount, 내부 자료구조): 개발자가 볼 수도 손댈 수도 없는 CPython 내부다. 개발자가 처리할 방법이 없다.

GIL이 지키는 것은 후자다. 개발자가 대신 못 지키는 인터프리터 내부라, 인터프리터가 스스로 지켜야 하고 그 수단이 GIL이다. 그러니 “개발자가 처리하면 되잖아”는 앞쪽(개발자 데이터)엔 맞지만 뒤쪽(인터프리터 내부)엔 해당하지 않는다.

---

5. 결과 — 무엇이 되고 무엇이 안 되나

GIL은 실행을 직렬화하므로 결과가 갈린다.

• CPU-bound + thread → 병렬 안 됨. 계산 중에는 GIL을 계속 쥐고 있어 thread를 여러 개 만들어도 순수 Python 연산은 한 번에 하나씩 돈다. 전환 비용 탓에 오히려 느려질 수도 있다. CPU 병렬이 필요하면 multiprocessing으로 프로세스를 나눠 GIL을 우회한다.
• I/O-bound + thread → 쓸모 있음. thread가 I/O 대기(blocking)에 들어가면 GIL을 놓는다. 그동안 다른 thread가 GIL을 쥐고 진행하므로, 여러 thread로 대기를 겹칠 수 있다.

즉 GIL이 막는 것은 정확히 “순수 Python CPU 연산을 thread로 병렬화하는 것”뿐이다. “Python은 동시성이 안 된다”는 틀린 말이다.

---

6. 다른 언어엔 왜 없나, 그리고 앞으로

Go·Java에 GIL이 없는 건 메모리 관리 방식이 다르기 때문이다. 이 언어들은 추적 GC(tracing garbage collection)를 쓴다 — 별도 GC가 주기적으로 안 쓰이는 객체를 찾아 청소하므로, 객체마다 refcount를 실시간 갱신하지 않는다. 그래서 refcount race 자체가 없고, GIL 같은 전역 락이 필요 없다.

	메모리 관리	GIL
CPython	참조 카운팅(refcount 실시간 갱신)	필요
Go·Java	추적 GC(refcount 없음)	불필요

GIL은 결함이라기보다 시대적 트레이드오프다. Python이 태어난 1991년은 멀티코어가 드문 단일 CPU 시대라, “멀티코어 병렬 불가”라는 단점이 크지 않았다. 참조 카운팅 + GIL은 단일 thread 성능·구현 단순성·C 확장 호환을 얻는 합리적 선택이었다. 멀티코어가 보편화된 지금 병목이 됐지만 refcount와 C 확장 생태계가 GIL에 의존해 제거가 어려웠다.

그래서 Python 3.13부터 GIL을 끄는 free-threading 빌드를 실험적으로 도입하기 시작했다. refcount를 다른 방식으로 바꾸고 C 확장 호환을 맞추는 큰 작업이라 시간이 걸리지만 GIL이 언어의 본질이 아니라 바꿀 수 있는 구현 결정임을 보여준다. Jython(JVM)·IronPython(.NET) 같은 다른 Python 구현에 애초에 GIL이 없는 것도 같은 맥락이다.