GIL과 Python의 미래, 성능 개선과 버전업, Python의 뒤를 이을 새로운 후보인 Go, Rust와 Julia 이어서 최후의 프로그래밍 언어

(제목에 파이썬의 뒤를 이을 언어라고 해서 파이썬이 사라지고 그 자리를 차지할 언어처럼 들릴 수 있지만 오해를 피하기 위해 정정하자면 파이썬이 근 몇년동안 보여준 성과처럼 급상승세를 거쳐 주류언어에 뛰어들 수 있는 언어라고 제목을 바꾸는 편이 낫겠지만 제목이 너무 길어져서 본문에 적었습니다.)

 

예전에 파이썬을 공부하면서 global interpreter lock 이라는 개념을 접한 적이 있다. 처음 이 단어를 접했을때는 파이썬만의 고유한 기능인줄 알았다. 그래서 그 당시에는 그냥 그런 개념이 있나보구나하고 넘어갔었다. 

 

그리고 이후에 블로그들을 돌아다니면서 GIL이 자주 언급되는 것을 보고 찾아보았다.

 

간략히 설명하자면 Global Interpreter Lock의 약어로 파이썬 인터프리터가 한 스레드만 하나의 바이트코드를 실행시킬 수 있도록 해주는 Lock이라고 말할 수 있다. 

그리고 이것은 기능이 아니라 파이썬 동작 방식의 특성이었으며 단점에 속하는 특성이었다. 다른 포럼이나 커뮤니티에서도 왜 파이썬이 미래의 프로그래밍 언어에서 승리할 수 없는지를 이야기하면서 파이썬의 특성 중 GIL로 인한 제약을 순위에 꼽았다. 

 

파이썬이 느리다는 것은 이미 잘알려진 사실이다. 기존 정적 타입언어들에 비해서 5~20배정도 느리다고 알려져 있으며, 이것은 사실 연산이 조금만 큰 작업을 수행하면 크지 않은 프로젝트이더라도 곧바로 체감되는 현실이다. 하지만 이 문제는 점차 해결이 되고 있으며 계속해서 버전업을 통해 개선되어나가고 있다.

(지금도 계속해서 빨라지고 있다. 하지만 귀도 반 로섬이 기존 파이썬에서 성능이 개선될 것이고 꾸준히 버전이 올라갈 것이라고 이야기했지만 그것이 python4.x 를 의미하지는 않을 것이라고 인터뷰한 내용을 보면 파이썬의 언어철학에 포함된 GIL이 해결되지 않을 수도 있겠다는 뜻으로도 해석할 수 있을 것 같다. 이에 대해 다른 의견들을 찾아보았는데 비슷한 의견들이 있었고 다른 의견들도 많았다. 다른 의견으로는 애초에 GIL이라는 개념 자체를 파이썬에서 해결한다고 하더라도 그전과는 성능차이가 별반 다르지 않을 것이라는 예측이 있었다. 이 부분에서는 아직 확인할 수 없는 내용이기때문에 정확히 믿기는 어려울 것 같다.)

 

그렇다면 왜 GIL이라는 개념이 꼭 필요한지에 대해서 말할 수 있다. 바로 다음과 같다. 

 

python은 기본적으로 garbage collection과 reference counting을 통해 할당된 메모리를 관리하게 된다. 

따라서 파이썬의 모든 객체는 refernce count 즉 해당 변수가 참조된 수를 저장하고 있는 것이다. 

여기서 문제가 발생하는데 멀티스레드인 경우 여러 스레드가 하나의 객체를 사용한다면 refernce count를 관리하기 위해서 모든 객체에 대한 lock이 필요하다. 그리고 이러한 비효율을 막기 위해서 python에서 GIL을 사용하게 된 것이다. 

즉 하나의 Lock을 통해서 모든 객체들에 대한 refernce count의 동기화 문제를 해결한 것이다.

(여기서 궁금한 점이 생길 수도 있다. 파이썬의 경우 reference counting에서 순환참조 발생시 어떻게 해결할까라는 궁금점이 생긴다면 아래 블로그 글을 읽어보면 좋을 것 같다. 미리 짧게 이야기하자면 파이썬에서는 Cyclic Garbage Collection을 지원하고 이를 통해 참조 주기를 감지하여 메모리 누수를 예방한다고 보면 될 것 같다.)  https://goodlucknua.tistory.com/48

 

이러한 내용만 보더라도 GIL은 파이썬이 작동하는 방식에서 나온 부산물이라는 것을 알 수 있다. 따라서 GIL이 이후 파이썬 버전에서 해결되지 않을 것이라는 여타 의견들은 어느정도 일리가 있는 의견이라고 할 수 있다. GIL은 확장성으로는 해결되지 않는 문제이기 때문에 이를 해결하기 위해서는 python2에서 python3으로 넘어가는 수준의 변화가 필요하지만 귀도 반 로섬이 python4.x는 없을 것이라고 못박았기에 GIL문제를 해결함으로써 파이썬의 성능이 개선될것이라는 의견은 근거가 빈약하다. 

 

그렇기 때문에 결론적으로는 이러한 제약사항때문에 파이썬이 미래의 프로그래밍 언어에서 밀려날 것이라는 예측이 많다고 생각한다. 관련 커뮤니티나 포럼에서 마찬가지로 GIL 혹은 성능(주로 속도)을 주요 문제점으로 꼽고 있다. (하드웨어 성능의 비약적 상승과 파이썬의 버전업으로 인한 개선 덕분에 속도 문제는 GIL보다는 치명적이지 않은 단점이라고 언급하는 의견도 존재한다.)

 

따라서 파이썬이 미래 언어가 되지 않을 것이라는 의견 속에서 그에 대한 대안 언어로써 제시되는 언어들을 살펴볼 수 있다. 주로 언급되는 것으로는 Go, Rust, Julia 정도가 언급되는데 하나씩 개인적인 생각을 말해보겠다. (사실 전부 잘 알지 못한다. Go가 그나마 사용되고 있으며 (Julia는 특정 도메인에서만 사용) 나머지는 거의 마이너한 언어로 알고 있고  Go의 경우 아주 예전에 예제를 따라서 코딩했던 기억이 있다. 계산기를 만들었던 것 같은데 지금은 머릿속에서 삭제됬다.)

 

Go 의 경우 구글에서 밀어주고 있지만 제네릭을 지원하지 않고 객체지향적으로 설계하기 불편하다는 점이 가장 큰 단점으로 작용하여 동의하지 못할 것 같다. 함수형, 논리형 등 수많은 패러다임이 있지만 객체지향은 계속 사용될 것이라고 생각한다. 실제로도 함수형 언어인 Scala나  얼랭 등이 뜨겁게 이야기되고 있지만 주류를 대체하지 못할 것이라고 생각한다. 대체가 아닌 병행사용이 될 것이다. 어느 패러다임이 무조건 뛰어나다고 말하기 보다는 필요한 곳에서 적재적소에 사용될 것이라고 생각된다. 

 

이 말은 즉슨 대규모 애플리케이션을 작성할때 객체지향은 다른 여타 패러다임보다 더 유리하기에 사라질 수 없다고 말한 것이다. 규모가 조금만 커지더라도 다른이로 하여금 읽기 어렵게 만드는 함수형 언어의 특성상 많은 인원이 투입하여 진행되는 프로젝트에서는 차선책 옵션 중 하나가 될 것이라고 생각한다. 따라서 파이썬처럼 완전 주류로 자리잡긴 어려울 것이라고 생각한다. 

 

Rust의 경우 제약이 많은 언어라고 알고 있다. 씨패밀리의 강력함과 안정성을 보장하는 언어라고 알고 있는데 러스트의 경우 사실 코드를 접해본적이 없어서 내 경험에서 어떻다 말할 수 가 없다. 다만 러스트를 즐겨 쓰는 다른 이들의 말을 빌리면 러닝커브가 높고 또한 기본적으로 불변으로 선언하기 때문에 안전하며 널 포인터가 애초에 존재할 수 없게 만들었기에 기존 C/C++에서 발생하는 문제들을 근본적으로 해결해줄 수 있을것이라 말한다. 하지만 아직 커뮤니티가 작고 사용처도 마땅하지 않다는 점이 단점으로 작용하고 있다. C++의 성능과 동시에 안정성을 보장해줄 수 있는 언어에 대한 소망은 예전부터 존재했는데 이 언어가 그 후보가 될 수 있기 때문에 해외에서 상당히 핫하게 이야기되는 것 같다. 하지만 아직 언어가 성장 중이고 제대로 자리잡지 못했기 때문에 일단은 한동안의 과정을 지켜봐야할 것 같은 생각이 든다. (한번 배워보고 싶다. 아주 잘 정리된 도큐먼트가 있다고 소문이 나있는데 나중에 꼭 한번 읽어봐야겠다.) 하지만 계속해서 꾸준히 성장한다면 다른 언어들보다는 더욱 가능성이 있다고 생각한다. 사용자들이 확보되고 어느정도 궤도에 오른다면 주류언어로 성장할 수 있다고 생각한다. 

 

Julia는 다른 포럼의 의견들을 들어보면 확실히 파이썬과는 구분되는 행보를 보일 것이라고 말한다. 우월한 병렬성과 함께 파이썬 대비 수치계산에서 강점을 보이는 이 강점은 정확히 이 부분에서만 파이썬을 대체할 것이라고 생각한다. 이미 많은 라이브러리가 존재하고 큰 생태계를 보유하고 있는 파이썬을 Julia가 특정 부분에서만 강점을 보인다고 해서 모든 도메인에서 밀어내지는 못할 것이라고 생각한다. 따라서 Julia의 강력한 계산능력과 동시에 병렬성이 필요한 특정 도메인에서만 꾸준히 사용되고 끝까지 주류 언어는 되지 못할 것이라고 생각한다. 

 

관련하여 읽어보면 좋은 블로그를 아래 첨부했다. 링크된 태그를 따라 더 많은 정보를 얻을 수 있는데 구체적인 기술적 내용이라기보다는 재밌게 읽어볼 수 내용들이 많다. 

 

https://towardsdatascience.com/why-python-is-not-the-programming-language-of-the-future-30ddc5339b66

Why Python is not the programming language of the future

 

언어에 매몰되지 않고 어떤 언어이던지 그에 구속되지 않고 필요할때 사용할 수 있는 것이 진정 훌륭한 엔지니어라고 하는데 그것이 가장 어렵다고 생각한다. 관련된 이론적 지식을 머릿속에 집어넣고 연차가 쌓이면서 동시에 경험이 쌓이는 것 또한 노력없이는 어려운 일이라고 생각하지만 결국에는 공학적인 문제해결능력이 중요하다고 생각한다. 그리고 그러한 문제해결능력은 '문제해결능력 바이블' 이라는 책이 있는 것도 아니고 경험으로 인해 노하우를 쌓는다고 해서도 나아질 것이라고는 생각하지 않는다.

 

인간은 자신의 과거의 경험에 기반하여 판단을 내리는 경향이 있다. 어떤 환경에서 자라왔느냐에 따라서 판단을 내리는 기준이 매우 다르다. 마찬가지라고 생각한다. 물론 어떠한 문제를 해결함에 있어서 단 한 가지의 방법이 존재하는 것은 아니지만 최적의 솔루션은 반드시 단 하나가 존재한다고 생각한다. 흔히 Optimal Solution이라고 자주 언급되는 이 해결방안을 찾기 위해서는 표면적인 이해를 통한 땜질이 아니라 어떻게 해당 기술이 움직이는지에 대한 이해를 통해서만 찾아낼 수 있을 것이라고 생각한다. 

 

글과는 상관없는 내용이지만 가끔 이런 컬럼들을 읽다보면 흥미로운 내용들을 많이 건질 수 있다. 하지만 그와 동시에 드는 생각은 너무나 많은 기술들이 난립해있다는 생각이 든다. 그 누구도 이 모든 것을 마스터하라고 말하지 않으며 그렇게 할 수도 없다. 물론 자신이 몸담고 있는 특정 도메인이 있다면 그 분야에 한해서는 평생을 파고들어야 하지만 가끔 완벽한 프로그래밍 언어가 단 하나 존재하면 어떨까라는 생각을 하게 된다. 다들 완벽한 프로그래밍 언어는 존재할 수 없다고 말하며 항상 속도와 안정성은 trade off 의 관계라고 말한다. 다른 사람들이 그렇게 말해서 나도 정말 그런건가라고 생각했지만 계속 드는 생각은 왜 완벽한 프로그래밍 언어는 탄생할 수 없는거지라는 의문이 들게 된다. 완벽한 프로그래밍 언어가 나올 수 없는 이유는 언어 설계상 trade off가 있기 마련이라고 한다. 그렇다면 단점으로 여겨지는 부분 즉 속도 혹은 안정성을 위해 희생당한 해당 개념을 우리가 문제점으로 인식하여 공학적 문제로 다루어 해결할 수 있지 않을까? (물론 나보다 더 똑똑한 많은 분들이 여태 이렇게 고민하고 또 고민해서 만들어낸게 지금 있는 산물들이니 막연히 가능할 것이라고는 생각하지 않는다. 엄청 어려운 문제이니 아직 해결이 되지 않은 거라고 생각한다.)

 

그래도 소망하는 것은 언젠가 모든 도메인에 완벽한 언어가 나왔으면 좋겠다는 것이다. 메모리에 잘못 접근할 위험성도 완벽하게 제약하고 동시에 성능 또한 머신코드에 가까울 정도로 빠른 그런 언어말이다. 

 

해당 내용과 관련해서 '최후의 프로그래밍 언어' 라는 내용의 글이 있는데 읽어보면 정말 재밌을 것이다. 

 

해당 글에서 언급된 내용 중 핵심적인 내용만 미리 언급하면 다음과 같다. 

 

 최후의 프로그래밍 언어의 조건 :

1. 한 회사의 통제 하에 있어서는 안된다.
2. Garbage Collection을 지원해야 한다.
3. GOTO 문이 없어야 한다.
4. 할당문 사용이 제한되어야 한다. (보다 함수적 프로그래밍이 되어야 한다)
5. 다형성을 제공해야 한다.
6. 멀티 패러다임이지 않아야 한다. (멀티 패러다임이란 명령형/객체지향/함수형/논리형 패러다임중 하나가 아니라 여러 개를 지원하는 것을 말한다)
7. 가상 머신상에서 실행되어야 한다.
8. 기존 프레임워크를 사용할 수 있어야 한다.
9. 빨라야 한다.
10. 단순한 문법이어야 한다.
11. 등상성(Homoiconicity)을 가져야 한다 (등상성은 Code As Data 라고도 하는데, 한 언어에서 코드와 데이타가 같은 방식으로 표현되는 것을 말한다. 등상성을 지원하는 언어에서는 데이터를 생성하는 것과 코드를 생성하는 것이 정확하게 같은 것이다. 이런 점에서 기계어는 등상성이다 (그밖에 Prolog, XSLT, R, Factor, Io 등))

 

쭉 살펴보면 흥미로운 내용들이 많다. 아마 1번은 Java를 염두에 두고 한 말이라 생각된다. 또한 3번 같은 경우는 다익스트라께서 하신 말씀이고 그 당시에 논쟁에 불이 붙어서 아직까지 논쟁중인 것으로 알고 있는데 내가 알고 있는게 최신 지식이 아닌것 같다. 아마 이미 논쟁이 종료되었고, GOTO문은 쓰지 않는 것이 좋다는 결론이 난 것 같다. 이 부분은 좀 더 자세히 알아봐야 겠다. 또한 나머지 중에서 한 가지 이해가 가지 않는 것은 6번이다. 왜 다중패러다임을 지원해서는 안되는지에 대해서는 왜 그래야 하는지 감이 잡히지 않는다. 이 부분은 조금 더 깊게 알아봐야할 것 같다. 아마 미약하게나마 추측하건데 C++가 다중패러다임을 지원하면서 몸집을 부풀리면서 엄청 비대해지고 문법이 난잡해지는것을 염두에 두고 한 말일 수도 있겠다는 생각이 든다. (그저 개인적인 추측일 뿐이다.)

 

7번과 9번은 서로 죽을 때까지 싸울 것 같다. 

 

아래 링크는 제목상 클로저 바이럴인것 같지만 재밌는 내용들도 있다. 

 

http://www.techsuda.com/archives/1674

[왜 클로저(Clojure)인가?] 1. 최후의 프로그래밍 언어 - 테크수다

 

아무튼 오랜만에 긴 글을 쓴 것 같다. 최근 Stackoverflow 2021 설문 결과를 보면서 내가 알지못하는 수많은 프레임워크와 개발환경이 있구나라는 생각이 들면서 제일 나은 언어는 무엇이고 최후에는 어떤 것이 살아남을까라는 생각을 하면서 쓰게 된 글이다.

 

개인적으로는 Rust가 파이썬처럼 성장하는 언어가 될 것이라고 생각한다. 아직 파이썬이 ML에 쓰이는 것처럼 Rust에도 무언가가 필요하지만 아직까지 주요한 킬러앱이 없는 것은 물론이고 사용자도 적으며 아직 성장중인 언어라서 지금 이렇다 저렇다를 말하긴 이르지만 언젠는 Rust가 주요한 역할을 하는 도메인이 생겨나서 널리 쓰이게 될 것 같다. 

 

오랜만에 혼자 상상의 나래를 펼쳐봤다.