Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
개발자

"왜 안 되는 걸까?" 파이썬에서 기대할 수 없는 4가지 기능 개선

Serdar Yegulalp | InfoWorld 2022.05.10
파이썬에는 높은 편의성과 다양하고 강력한 라이브러리, 친절한 사용자 커뮤니티 등 좋은 점이 많지만 몇 가지 부족한 부분도 여전히 있다. 파이썬 작업을 수월하게 해줄 수 있는, 다른 언어에 있는 여러 기능을 적어도 당분간은 파이썬에서 기대할 수 없다. 개발자가 자주 요청하지만 현재 파이썬의 계획표에는 없는 4가지 기능을 소개한다. 이중 적어도 2개는 추가될 가능성이 없고, 다른 2개는 최소 몇 년 동안 계획이 없다. 이와 같은 기능이 왜 추가되지 않는지, 또는 미래의 파이썬에 추가되기 위해 무엇이 필요한지 살펴보자.
 
ⓒ Getty Images Bank
 

가능성 없음 : 정적 형식의 컴파일된 파이썬 버전

정적 형식 지정을 사용해 네이티브 기계 코드로 컴파일되는 파이썬을 꿈꾸는 개발자가 있다. 따지고 보면 유연한 형식 지정은 파이썬이 가진 느린 속도의 원인 중 큰 부분을 차지하는데, 정적 형식 지정을 사용하면 그 문제에 마침표를 찍을 수 있다. 또한 정적 형식 지정은 프로그래머에게 코드의 동작에 관한 강한 보장을 제공한다.

파이썬에는 형식 힌트가 있지만 형식 힌트의 용도는 린팅 툴을 통해 편집 시 정적 분석의 편의성을 높이는 데 있다. 런타임에 형식 힌트를 사용하는 것은 서드파티 프로젝트(예를 들어 pydantic)뿐이다. 파이썬 런타임 자체는 형식 힌트를 사용하지 않는다. 형식 힌트에 대한 PEP(파이썬 향상 제안) 484의 명확한 목표 중 하나는 형식 힌트를 영구적으로 옵션화하는 것이다. “파이썬은 앞으로도 동적 형식 지정 언어로 남을 것이며 파이썬 저작자는 형식 힌트를 (관례상으로도) 의무화할 생각이 전혀 없다.”

꼭 정적 형식 지정 파이썬을 원하는 개발자라면 사이썬(Cython) 또는 마이픽(mypyc)을 선택할 수 있지만 이 두 프로젝트에도 타협점은 있다. 사이썬의 경우 가장 큰 성능 향상은 순수 C 형식과 구조를 사용하고 파이썬 런타임 사용을 줄이는 데서 온다. 간단히 말해 파이썬의 동적 특성을 희생하지 않으면서 파이썬 컴파일 속도를 더 빠르게 하기는 어렵다. 동적 특성이 불필요한 부분을 따로 분리해 속도를 높이는 편이 훨씬 더 쉽다.
 

가능성 없음 : 멀티라인 람다

파이썬의 람다 식, 또는 익명 함수에 대한 제약은 의도적이다. 파이썬은 함수 본문으로 하나의 식(기본적으로 할당 연산에서 '=' 기호 오른쪽에 있는 것)만 허용한다. 자바스크립트와 같이 멀티라인 익명 함수가 표준적으로 사용되는 언어에서 파이썬으로 건너온 개발자는 파이썬에서도 이 기능을 요청하는 경우가 많다.

파이썬을 만든 귀도 반 로섬은 오래전에 람다가 단일 식을 위한 구문론적 설탕(syntactic sugar) 이상의 의미를 갖게 될 가능성은 없다고 못 박았다. 그의 생각은 2006년에 보낸 이메일에서 가장 명확히 드러난다. 이 이메일에서 반 로섬은 멀티라인 람다가 파이썬에 맞지 않고 앞으로도 구현될 가능성이 없는 이유를 다음과 같이 설명했다.
 
  • 멀티라인 람다는 파이썬에 더하는 실질적인 기능이나 표현성이 거의 없으면서 언어의 가독성을 더 낮춘다(가독성은 파이썬의 가장 큰 관심사다).
  • 공백에 민감한 파이썬 설계의 나머지 부분과 매끄럽게 통합되는 사용 가능한 구문이 나오지 않았다.
  • 멀티라인 람다를 완전한 함수로 변환하는 데는 거의 아무런 노력도 들지 않는다(반 로섬은 “멀티라인 람다” 사용 사례에서 이 방법을 사용할 것을 권장한다).

이쯤 되면 파이썬에서 멀티라인 람다에 대한 기대는 접는 것이 좋다.
 

가능성 낮음 : GIL 없는 파이썬

전역 인터프리터 잠금(Global Interpreter Lock, GIL)은 파이썬 애호가에게 오랜 ‘가시’ 같은 존재다. GIL은 파이썬 런타임 내의 활동을 동기화해서 객체에 대한 액세스를 직렬화하고 전역 상태를 관리한다. GIL의 단점은 파이썬 런타임이 싱글 스레드로 실행되도록 한다는 것이다. 스레드를 사용한 진정한 병렬성을 원한다면 별도의 파이썬 인터프리터 사본을 실행해 각 인터프리터에서 개별적으로 스레드를 실행해야 한다. GIL 없는 파이썬은 이론적으로는 병렬성을 높이고 따라서 성능을 개선할 수 있다. 그렇다면 왜 추가될 가능성이 낮을까?

그동안 파이썬에서 GIL을 없애기 위한 다양한 제안이 나왔다. 그러나 대부분은 하위 호환성을 깨거나 싱글 스레드 작업에서 파이썬의 속도를 더 느리게 하거나 두 가지 모두에 해당했다. 예를 들어 '길렉토미(GILectomy)'라는 프로젝트는 성능 저하가 심각했다. 파이썬 3.x에서는 GIL을 손봐서 기본 성능을 개선했지만 하위 호환성을 유지하기 위해 없애지는 않았다.

결국 GIL은 파이썬 사용자에게 피할 수 없는 현실로 보인다. 다만 성능 개선의 가능성은 있다. 파이썬 런타임에서 병렬성을 높일 수 있는 한 가지 방법은 하나의 프로세스에서 여러 개의 인터프리터를 실행하는 것이다. 이 제안을 현실화하기 위해서는 파이썬의 C API 개조를 포함해 파이썬의 내부 구조를 크게 바꿔야 한다. 또한 C API에 의존하는 많은 서드파티 모듈도 업데이트가 필요하다. 더 최근의 제안인 PEP 684는 여러 인터프리터라는 개념을 더 확대해 각 서브인터프리터가 자체 GIL을 사용하도록 한다. 이 제안이 실현되면 서브인터프리터 간에 공유해야 하는 객체의 전략적인 공유도 가능해진다.
 

희미한 가능성 : 파이썬 네이티브 JIT 컴파일러

파이썬의 강점인 유연함을 유지하면서 성능을 높이는 검증된 방법 한 가지는 JIT(Just-In-Time) 컴파일러를 쓰는 것이다. JIT 컴파일은 코드 분석을 사전에 하지 않고 런타임에 수행하며, 실행 중 나타나는 코드의 동작에 따라 선별적으로 또는 전체적으로 기계 코드로 컴파일한다.

파이썬에서는 JIT가 이미 존재한다. 가장 일반적으로 사용되며 가장 잘 개발된 파이파이(PyPy)가 대표적이다. 프로그램 소스 코드를 변경하지 않고도 장시간 실행되는 서버 스타일 애플리케이션의 성능을 개선하는 데 있어 탁월하다. 그러나 파이선의 레퍼런스 버전인 C파이썬(CPython)에도 JIT의 이점이 적용될까?

파이썬 속도를 높이기 위해 2021년 파이썬 랭귀지 서밋(Python Language Summit)에서 여러 사안이 논의되면서 몇 가지 제안이 나왔다. 현재의 제안은 파이썬에서 완전한 JIT를 구현하는 대신 인터프리터에 적응형 동작을 추가해 일반적인 특수 상황에서 실행 속도를 높이는 방법이다. 앞으로는 진정한 고속 코드 경로를 위해 기계 코드를 생성하는 것과 같이 다른 JIT 형식 전문화가 개발될 가능성도 있다. 그러나 단기적인 계획은 기존 인터프리터를 대체하기보다는 확장 개선하는 것이다.
editor@itworld.co.kr
 Tags 파이썬 개발자
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.