AI VIDEO BRIEFING

NoGIL 파이썬과 머신러닝 성능: GIL 제거가 판다스·넘파이·사이킷런에 미치는 영향

GIL을 제거한 NoGIL 파이썬이 머신러닝을 얼마나 빠르게 하는지 라이브러리별 벤치마크로 검증한다. 순수 파이썬 연산은 약 3배, 판다스는 약 2.7배 빨라졌지만 넘파이·사이킷런 같은 네이티브 코드 기반 라이브러리는 거의 변화가 없었다.

GIL 없는 파이썬(NoGIL), 머신러닝을 정말 빠르게 할까? 라이브러리별 실측 영상 대표 이미지

핵심 메시지

  • GIL(전역 인터프리터 락)은 여러 스레드가 있어도 한 번에 하나의 스레드만 파이썬 바이트코드를 실행하게 제한하며, NoGIL 파이썬은 이 제약을 없애 여러 CPU에서 파이썬 코드를 동시에 실행할 수 있게 한다.
  • 파이썬 코드 자체를 많이 실행하는 작업일수록 NoGIL의 이득이 크다. 순수 파이썬 연산은 약 3배, 판다스는 약 2.7배 빨라졌다.
  • 넘파이·사이킷런처럼 연산 대부분을 C++ 같은 네이티브 코드에서 처리하는 라이브러리는 이미 GIL을 풀고 실행하므로 NoGIL로 바꿔도 속도 이득이 거의 없었다.
  • 라이브러리 호환성은 아직 과도기다. 허깅페이스 트랜스포머의 토크나이저는 NoGIL 파이썬에서 충돌해 벤치마크조차 하지 못했다.

쉽게 이해하기

GIL(Global Interpreter Lock, 전역 인터프리터 락)은 오랫동안 파이썬 동시성의 근본적인 제약이었다. 여러 스레드를 띄워도 한 시점에 오직 하나의 스레드만 파이썬 바이트코드를 실행할 수 있게 락으로 묶어두기 때문이다. 최근 이 GIL을 제거하려는 움직임(NoGIL 파이썬)이 있어, 영상은 그것이 머신러닝 작업에 실제로 어떤 의미가 있는지 실측으로 따진다.

먼저 파이썬의 네 가지 동시성 방식을 정리한다. 비동기 IO(async IO)는 이벤트 루프와 코루틴으로 IO 대기 시간을 겹쳐 처리하지만 한 번에 하나의 CPU만 쓰므로 계산이 무거운 머신러닝에는 큰 도움이 안 된다. 스레딩은 메모리를 공유하지만 GIL 때문에 파이썬 코드 실행은 한 스레드로 제한된다. 다만 IO 대기나 네이티브 함수 호출 같은 '비(非)파이썬' 작업은 여러 스레드가 동시에 할 수 있다.

멀티프로세싱은 각 프로세스가 자기만의 메모리와 인터프리터를 가지므로 GIL의 영향 없이 여러 CPU를 쓸 수 있고, 표준 파이썬에서 다중 CPU를 활용하는 사실상 유일한 방법이다. 대신 프로세스 간 통신이 어렵다. 공유 메모리나 메시지 큐를 써야 하고, 파이썬 객체를 그대로 주고받을 수 없어 종종 객체를 프로세스마다 복제해야 하는 부담이 있다. 마지막 방식은 아예 파이썬을 벗어나 C++·러스트·CUDA(GPU)로 연산을 넘기는 것으로, 이때는 GIL을 풀었다가 함수가 끝나면 다시 잡는다.

영상 제작자는 여러 스레드가 같은 작업을 수행하는 벤치마크를 만들어, 표준 파이썬과 NoGIL 파이썬에서 자주 쓰는 라이브러리들의 속도를 비교했다. 순수 파이썬 반복문 위주인 만델브로트 렌더링은 NoGIL에서 약 3배 빨라졌고, apply·정렬·그룹 연산이 섞인 판다스는 약 2.7배 빨라졌다. 반면 사이파이(scipy)는 약 12%의 소폭 향상에 그쳤는데, 대부분 네이티브 코드지만 파이썬 콜백이 어느 정도 있기 때문이다.

넘파이(행렬 곱·특이값 분해)와 사이킷런(SVM 학습)은 연산이 전부 네이티브 코드에서 이뤄지고 이미 GIL을 풀기 때문에 속도 이득이 없었고, 사이킷런은 오히려 약간 느려지기도 했다. 허깅페이스 트랜스포머로 GPT-2 문장 생성을 시도했으나 토크나이저가 NoGIL에서 충돌해 측정 자체가 불가능했다. 결론적으로 파이썬 연산 비중이 큰 라이브러리(예: 판다스)만 유의미하게 빨라지고, 네이티브 연산 위주 라이브러리는 영향이 미미하다.

주요 인사이트

  • NoGIL의 이득 여부를 가르는 핵심 기준은 '연산이 파이썬에서 도는가, 네이티브 코드에서 도는가'다. 파이썬 바이트코드 실행이 많을수록 멀티스레딩 이득이 커진다.
  • 표준 파이썬에서 다중 CPU를 쓰려면 멀티프로세싱이 필요했지만, 프로세스 간 객체 공유가 어려워 메모리 복제 등 엔지니어링 비용이 든다. NoGIL 스레딩은 이 통신 부담 없이 메모리를 공유하며 병렬 실행할 여지를 준다.
  • 실제 현장에서는 GIL·멀티스레딩 문제로 아예 언어를 바꾸기도 한다. 한 딥마인드 엔지니어 팀은 관련 문제가 너무 많아 전체를 C++로 다시 작성하는 편이 낫다고 판단했다고 소개된다.
  • 라이브러리 성숙도가 관건이다. 토크나이저 충돌 사례처럼 일부 라이브러리는 아직 NoGIL을 제대로 지원하지 못해 오작동하거나 잘못된 결과를 낼 수 있다.
  • 같은 라이브러리라도 어느 부분을 벤치마크하느냐에 따라 결과가 달라진다. 판다스처럼 파이썬 연산 비중이 큰 라이브러리도 정렬처럼 네이티브로 처리되는 부분이 섞여 있다.

자주 묻는 질문

GIL이 무엇이고 왜 문제가 되나요?

GIL(전역 인터프리터 락)은 여러 스레드가 있어도 한 시점에 하나의 스레드만 파이썬 바이트코드를 실행하도록 제한하는 잠금 장치입니다. 그래서 파이썬 로직이 많은 프로그램은 스레드를 여러 개 띄워도 사실상 단일 스레드처럼 동작합니다.

NoGIL 파이썬으로 바꾸면 머신러닝이 무조건 빨라지나요?

아닙니다. 순수 파이썬 연산(약 3배)이나 판다스(약 2.7배)처럼 파이썬 코드 비중이 큰 작업은 크게 빨라졌지만, 넘파이·사이킷런처럼 연산을 네이티브 코드에서 처리하는 라이브러리는 이미 GIL을 풀고 실행하기 때문에 속도 이득이 거의 없었습니다.

표준 파이썬에서 여러 CPU를 쓰는 방법은 무엇이었나요?

멀티프로세싱입니다. 각 프로세스가 독립된 메모리와 인터프리터를 가져 GIL의 제약 없이 여러 CPU를 쓸 수 있습니다. 다만 프로세스 간 통신이 어렵고 파이썬 객체를 그대로 공유할 수 없어 객체를 복제하는 등의 비용이 따릅니다.

지금 바로 NoGIL 파이썬을 도입해도 될까요?

아직 과도기입니다. 영상에서는 허깅페이스 트랜스포머의 토크나이저가 NoGIL에서 충돌해 벤치마크가 불가능했고, 일부 라이브러리는 오작동하거나 잘못된 결과를 낼 수 있다고 언급합니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식