지난 번
파이썬 GIL 깊숙히! (상)을 쓴 이후로 그 글을 읽으신 분들의 느낌을
IRC, 오프라인, 블로그 등을 통해 많이 전해 들었습니다.
별 다른 코멘트 없이 사실을 전달하는 정도로만 써서 그랬는지, CPython의 구현에 굉장히 심각한
문제가 내재되어 있는 것처럼 느껴지고, 이것 때문에 파이썬에 크게 실망하신 분들도 있는 것 같습니다.
그렇지만, 파이썬의 GIL은 “문제”라기보다는, “특성” 정도가 훨씬 적당하지 않을까 싶습니다.
파이썬과 같은 높은 수준의 객체 추상화를 사용하는 언어는 필연적으로 객체들의 작업들을 내부적으로
구현하기 위해서 여러가지 lock 방법이 필요합니다. 프로그래밍 언어 뿐만 아니라, 사실 한정된 자원을
공유하는 운영체제, 플랫폼 시스템, 데이터베이스 등등 대부분의 프로그램이 그렇겠죠.
그런데, GIL은 lock을 구현하는 방법 중의 하나일 뿐입니다. GIL에 반대되는 fine-grained lock은
lock을 관리하는 부가적인 자료구조가 필요하고, lock이 세분화 되어있기 때문에 그에 따라 한 번 lock
하면 될 것을 여러 번 lock해서 작업해야하는 경우가 많이 생깁니다. lock 여러개를 왔다갔다 하느라 문맥 전환 오버헤드나 캐시 손실도 발생할 수 있고요. 또한, fine-grained lock은
데드락같은 상황을 해결하기 위한 방법을 추가로 사용해야합니다. 만약 운영체제의 디스크자원,
Bus I/O자원, 그래픽자원 등과 같이 종류도 다양하고 수도 많은 경우라면 당연히 서로 병렬로 작업이
효율적으로 일어나게 하려면 fine-grained lock을 사용해야 합니다. 그렇지만, 파이썬에서 필요한
lock은 대부분 CPU가 주요 자원으로 참여하는 것으로, 사실상 이전의 PC들이 대부분 CPU가 1개
였다는 점에서, GIL을 사용하는 것은 (1) 구현이 쉽고 (2) 프로그램이 효율적이고 (3) 구현의
복잡도가 낮아서 유지보수가 쉬우며 버그도 적게 해 줍니다.
CPython을 구현한 그룹은 기업 규모의 다른 팀들에 비해 상당히 작은 규모이며, 특히 플랫폼에 최적화된 복잡한 JIT와 객체 시스템을 구현한 뛰어난 VM을 Sun이나
MS같이 직접 제작하여 유지보수할
수 있을만한 크기가 전혀 아닙니다. 따라서, 한정된 개발자들이 파이썬 고유의 역량을 그의 특징을
살리는 데 투자하기 위해서는 복잡한 VM을 구현하는 것보다는, 새로운 라이브러리와 언어적 측면들을
발전시키는 것이 더욱 중요했고 그렇게 계속 발전되어 왔습니다. 또한, 이렇게 만들어진 파이썬 언어는
결국 IronPython이나 PyPy같은 더 높은 이상을 추구하는 프로젝트가 나올 수 있게 된 기반이 되었겠죠.
그리고, GIL을 “문제”로 보기 힘든 또 하나의 이유는, 운영체제나 데이터베이스같은 시스템과는 달리
파이썬은 프로그래밍 환경이기 때문에, 사용자가 GIL이 있다고 해도 더 좋은 방법들을 개발하여 쓸 수
있다는 것입니다. 사실 쓰레드 프로그래밍은 프로그램 안에서 여러 문맥을 쓰기 위한 좋은 방법 중의
하나이긴 하지만, 대부분의 경우에 쓰레드를 사용하는 부분을 멀티 프로세스로 처리하는 것도 가능하고,
그게 오히려 더 효율적인 경우가 많이 있습니다. 예를 들어, 과학 계산을 위한 프로그램을 CPU가 20개라서
쓰레드 20개로 돌리게 만들었다면, 이 경우 입력값과 출력값을 관할하는 한 프로세스와 다른 20개 프로세스가
서로 통신하게 분리해서 짜는 것도 가능하고 (통신 방법은 os.system 외에도 무궁무진), 아예 범용으로
코드 객체를 던져주면 그걸 실행해주는 서버를 20개 띄워놓는 방법도 있겠죠. 이렇게 되면, 쓰레드 20개로
띄우던 시절과는 달리, 꼭 컴퓨터 1대에서 다 돌아갈 필요가 없어지고 10개, 10개 나누거나 2개씩 10대로
나누는 등의 설정도 생각해 볼 수 있게 됩니다.
어떤 분들에게는 GIL은 현재 파이썬 구현의 최대약점이라고 보이실 수도 있지만, GIL 때문에 도저히 같이
못 살겠다 해도 그것을 기회로 삼아, 쓰레드 말고 다른 방법으로 구현하는 방법을 배워보시는
계기로 만들어 보시면 좋겠습니다. =3=3=3
예고대로 (하)편에서는 GIL을 다루는 (피해가는?) 여러 방법에 대해서 소개해 드리겠습니다. ^_^
