2017.09.08

"실행시간 줄고 API 리팩토링"··· 파이썬은 지금 '환골탈태' 중

Serdar Yegulalp | InfoWorld
파이썬(Python)은 부지런하다. 파이썬 언어와 가장 널리 사용되는 구현체 'C파이썬(CPython)'은 새 버전이 나올 때마다 발전을 거듭해 사용하기도 편해지고 있다.



그러나 파이썬의 인기가 높아지고 활용 사례가 늘어나면서 느린 실행 속도에서부터 동시 실행 불가 등과 같은 한계점도 더 두드러지고 있다. 최근에 파이썬에 이루어진 개선은 자동화, 머신러닝, 마이크로서비스와 같은 다양한 분야에서 대두되는 요구사항을 충족하기 위한 것이었다. 파이썬의 코어 개발 팀이 대대적인 개선을 추진 중인 4가지를 살펴보자.

실행 시간 단축
파이썬이 계획 중인 개선은 대부분 '속도 증가'와 관련이 있다. 이 중 최우선 목표는 C파이썬 해석기 실행에 걸리는 시간을 줄이는 것이다. 개발 비용 대비 단기 효과가 가장 클 것으로 기대된다. 파이썬의 실행 시간이 문제라는 점은 의심의 여지가 없다. 코어 C파이썬 개발자 빅터 스티너는 파이썬 3.7(현재 트렁크(trunk) 버전)의 실행 속도가 파이썬 2.7 펄(Perl) 5보다 2.3~2.8배 느리며 PHP 7의 실행 속도는 파이썬 3에 비해 5~10배 빠르다고 설명했다.

파이썬 3의 실행이 굼뜨다 보니 파이썬 2.x 사용자는 업그레이드를 망설이고 있다. 그러나 파이썬 2가 2020년 지원 종료 예정임을 감안하면 업그레이드가 시급한 상황이다. 컨테이너의 언어 실행 시간과 같이 짧은 실행 시간이 필수적인 환경에서 굳이 파이썬, 특히 C파이썬을 써야 할 정당성을 찾기도 어렵다. 실행 시간이 짧으면 짧을수록, 즉, 컨테이너가 명령을 받아들일 준비가 빨리 될수록 언어의 유용성은 어떤 컨테이너 환경에서든 높아진다.

네임드 튜플 속도 향상
C파이썬의 코어 개발자가 실행 시간(시동 시간 포함)을 단축하기 위해 사용하는 가장 일반적인 방식 중 하나는 네임드 튜플(named tuple)을 구현하는 것이다.

파이썬에서 튜플은 요소 0, 요소 1 등 인덱스 위치에 의해 접근되는 정수나 문자열과 같은 개체의 불변 목록이다. ‘네임드’ 튜플은 파이썬의 표준 라이브러리에서 사용할 수 있으며 점 속성(예를 들어 address[3] 대신 address.zip_code)을 통해 이러한 요소에 대한 접근을 가능하게 한다. 이렇게 되면 코드를 읽기 훨씬 쉬워진다.

문제는 현재의 네임드 튜플이 파이썬의 느린 구동 시간에 한 원인으로 지목됐다는 점이다. 이에 따라 파이썬의 창시자 귀도 반 로섬은 C파이썬에서 네임드 튜플을 공격적인 방법으로 최적화하기로 했다. C파이썬의 실행 시간을 줄이기 위한 것으로 동시에 C파이썬을 사용하는 타사 응용프로그램 모두에게도 도움이 된다.

C파이썬 최적화 관련해서는 C 자체에서 수정해야 부분도 있다. 반 로섬도 파이썬의 속도를 높이려면 C파이썬의 태생지, 즉 파이썬이 아닌 C에서 구현되어야 한다고 지적했다. 그는 "예를 들어 소스 코드와 exec()을 생성하는 방식은 파이썬의 멋진 표현력을 보여준다. 그러나 exec()와 eval()을 사용하는 주요 관용구를 마주칠 때마다 느낀 것은, 이런 호출을 피하기 위한 언어(또는 빌트인)를 강화해야 한다는 것이었다”고 말했다.


내부 API 리팩토링
현재 C파이썬을 개선하지 못하는 주요 원인 중 하나는 C API에 대한 하위 호환성을 유지해야 한다는 점이다. 이론적으로는 C파이썬을 다시 작성해서 전체적으로 엄청난 성능 향상을 꾀할 수 있지만, 이렇게 하면 수많은 소프트웨어와의 호환성이 단절될 수 있다. 파이썬 종사자들은 언어의 경계를 넘는 것을 제외하고는 (파이썬 2 vs. 파이썬 3) 무엇인가를 중단하는 변경은 하지 않는 것에 오랜 자부심을 갖고 있다.

이에 따라 코어 파이썬 개발자 빅터 스티너가 제안한 대안은 C파이썬의 C API를 리팩토링해 구현 상세 내용을 숨기는 것이다. 이렇게 하면 개발자는 무언가를 중단시킬 가능성이 있는 새로운 최적화(예를 들면 GIL(Global Interpreter Lock) 없애기)보다 더 쉽게 테스트할 수 있다. 이 리팩토링에 대한 테스트는 C파이썬의 자체 테스트 제품으로 수행할 뿐만 아니라 NumPy, SciPy와 같이 API에 플러그인하는 가장 흔한 타사 패키지에 대해서도 수행할 수 있다.

C파이썬 API 리팩토링의 장점은 이 밖에도 다양하다. 예를 들면 C파이썬의 코드를 탐색, 이해하기 쉬워지고 잠재적인 기여자에 대한 장벽을 낮출 수 있다. 이는 C파이썬 팀은 개발자와 기여자의 건강한 관심을 유지하기 위해 소스 저장소를 기트허브로 옮긴 바 있다. API 리팩토링은 이러한 노력의 효과를 더 보완할 수 있다.

GIL 제거
파이썬의 문제 중 가장 많이 지적되는 것 중 하나가 바로 GIL이다. GIL은 C파이썬에서 사용하는 모든 객체에 대한 메모리 접근의 '쓰레드-안전(thread-safe)'을 유지하는 역할을 한다. 즉, 파이썬 객체는 한 번에 하나의 쓰레드에 의해서만 사용되도록 한다. C파이썬은 실질적으로 싱글 쓰레드라는 의미이기도 하다. 이 때문에 CPU 제약을 받는 멀티 쓰레드 연산은 C 확장 기능이나 여러 개의 C파이썬 인스턴스를 통해 처리해야 한다.

파이썬이 나온 이후 이 문제는 파이썬을 쓰기 위해 어쩔 수 없이 지급해야 하는 비용으로 받아들여졌다. 그러나 CPU 클럭 속도가 안정되고 코어가 확산하면서 파이썬은 태생적으로 멀티쓰레딩을 지원하는 언어에 점차 밀리고 있다.

물론 파이썬의 주요 응용 분야인 머신러닝과 통계 등의 많은 부분은 GIL의 제약을 받지 않는 C 코드로 가속한다. 그러나 이 문제는 점점 더 무시하긴 힘든 상황으로 치닫고 있다. 만약 파이썬 솔루션이 플랫폼 간에 이동이 더 쉽고 응용프로그램 간에 유연성이 더 높으면 개발자가 활용하기에 더 편해질 것이다.

이에 대해 C파이썬 개발자 래리 해스팅스은 'GIL 적출수술'이라고 부르는 작업을 진행 중이다. 그러나 GIL을 제거하는 가장 최근의 시도 결과를 보면, GIL 제거만으로는 완벽한 답이 되지 않는다. 이렇게 할 수는 있지만 주로 C 확장 기능인 기존 파이썬 패키지에 대한 하위 호환성이 중단될 위험이 있는 것이다.

따라서 이러한 노력이 성공하려면 C API와 하위 호환이 유지되면서 GIL을 제거해야 한다. 그러나 지금까지의 시도 결과는 성능 면에서 엄청난 손해가 동반됐다는 점이다. 해스팅스는 2017년 파이콘(PyCon) 행사를 통해 이러한 성과와 한계에 대해 발표하기도 했다. 현재는 GIL 제거 계획이 여전히 잠정적이고 실험적이다. 파이썬이 실제로 사용되는 방식 때문에 제약될 수밖에 없다. 그러나 C파이썬의 API 재작업이 끝나면 GIL 제거가 더 쉬워질 지도 모른다. ciokr@idg.co.kr 

2017.09.08

"실행시간 줄고 API 리팩토링"··· 파이썬은 지금 '환골탈태' 중

Serdar Yegulalp | InfoWorld
파이썬(Python)은 부지런하다. 파이썬 언어와 가장 널리 사용되는 구현체 'C파이썬(CPython)'은 새 버전이 나올 때마다 발전을 거듭해 사용하기도 편해지고 있다.



그러나 파이썬의 인기가 높아지고 활용 사례가 늘어나면서 느린 실행 속도에서부터 동시 실행 불가 등과 같은 한계점도 더 두드러지고 있다. 최근에 파이썬에 이루어진 개선은 자동화, 머신러닝, 마이크로서비스와 같은 다양한 분야에서 대두되는 요구사항을 충족하기 위한 것이었다. 파이썬의 코어 개발 팀이 대대적인 개선을 추진 중인 4가지를 살펴보자.

실행 시간 단축
파이썬이 계획 중인 개선은 대부분 '속도 증가'와 관련이 있다. 이 중 최우선 목표는 C파이썬 해석기 실행에 걸리는 시간을 줄이는 것이다. 개발 비용 대비 단기 효과가 가장 클 것으로 기대된다. 파이썬의 실행 시간이 문제라는 점은 의심의 여지가 없다. 코어 C파이썬 개발자 빅터 스티너는 파이썬 3.7(현재 트렁크(trunk) 버전)의 실행 속도가 파이썬 2.7 펄(Perl) 5보다 2.3~2.8배 느리며 PHP 7의 실행 속도는 파이썬 3에 비해 5~10배 빠르다고 설명했다.

파이썬 3의 실행이 굼뜨다 보니 파이썬 2.x 사용자는 업그레이드를 망설이고 있다. 그러나 파이썬 2가 2020년 지원 종료 예정임을 감안하면 업그레이드가 시급한 상황이다. 컨테이너의 언어 실행 시간과 같이 짧은 실행 시간이 필수적인 환경에서 굳이 파이썬, 특히 C파이썬을 써야 할 정당성을 찾기도 어렵다. 실행 시간이 짧으면 짧을수록, 즉, 컨테이너가 명령을 받아들일 준비가 빨리 될수록 언어의 유용성은 어떤 컨테이너 환경에서든 높아진다.

네임드 튜플 속도 향상
C파이썬의 코어 개발자가 실행 시간(시동 시간 포함)을 단축하기 위해 사용하는 가장 일반적인 방식 중 하나는 네임드 튜플(named tuple)을 구현하는 것이다.

파이썬에서 튜플은 요소 0, 요소 1 등 인덱스 위치에 의해 접근되는 정수나 문자열과 같은 개체의 불변 목록이다. ‘네임드’ 튜플은 파이썬의 표준 라이브러리에서 사용할 수 있으며 점 속성(예를 들어 address[3] 대신 address.zip_code)을 통해 이러한 요소에 대한 접근을 가능하게 한다. 이렇게 되면 코드를 읽기 훨씬 쉬워진다.

문제는 현재의 네임드 튜플이 파이썬의 느린 구동 시간에 한 원인으로 지목됐다는 점이다. 이에 따라 파이썬의 창시자 귀도 반 로섬은 C파이썬에서 네임드 튜플을 공격적인 방법으로 최적화하기로 했다. C파이썬의 실행 시간을 줄이기 위한 것으로 동시에 C파이썬을 사용하는 타사 응용프로그램 모두에게도 도움이 된다.

C파이썬 최적화 관련해서는 C 자체에서 수정해야 부분도 있다. 반 로섬도 파이썬의 속도를 높이려면 C파이썬의 태생지, 즉 파이썬이 아닌 C에서 구현되어야 한다고 지적했다. 그는 "예를 들어 소스 코드와 exec()을 생성하는 방식은 파이썬의 멋진 표현력을 보여준다. 그러나 exec()와 eval()을 사용하는 주요 관용구를 마주칠 때마다 느낀 것은, 이런 호출을 피하기 위한 언어(또는 빌트인)를 강화해야 한다는 것이었다”고 말했다.


내부 API 리팩토링
현재 C파이썬을 개선하지 못하는 주요 원인 중 하나는 C API에 대한 하위 호환성을 유지해야 한다는 점이다. 이론적으로는 C파이썬을 다시 작성해서 전체적으로 엄청난 성능 향상을 꾀할 수 있지만, 이렇게 하면 수많은 소프트웨어와의 호환성이 단절될 수 있다. 파이썬 종사자들은 언어의 경계를 넘는 것을 제외하고는 (파이썬 2 vs. 파이썬 3) 무엇인가를 중단하는 변경은 하지 않는 것에 오랜 자부심을 갖고 있다.

이에 따라 코어 파이썬 개발자 빅터 스티너가 제안한 대안은 C파이썬의 C API를 리팩토링해 구현 상세 내용을 숨기는 것이다. 이렇게 하면 개발자는 무언가를 중단시킬 가능성이 있는 새로운 최적화(예를 들면 GIL(Global Interpreter Lock) 없애기)보다 더 쉽게 테스트할 수 있다. 이 리팩토링에 대한 테스트는 C파이썬의 자체 테스트 제품으로 수행할 뿐만 아니라 NumPy, SciPy와 같이 API에 플러그인하는 가장 흔한 타사 패키지에 대해서도 수행할 수 있다.

C파이썬 API 리팩토링의 장점은 이 밖에도 다양하다. 예를 들면 C파이썬의 코드를 탐색, 이해하기 쉬워지고 잠재적인 기여자에 대한 장벽을 낮출 수 있다. 이는 C파이썬 팀은 개발자와 기여자의 건강한 관심을 유지하기 위해 소스 저장소를 기트허브로 옮긴 바 있다. API 리팩토링은 이러한 노력의 효과를 더 보완할 수 있다.

GIL 제거
파이썬의 문제 중 가장 많이 지적되는 것 중 하나가 바로 GIL이다. GIL은 C파이썬에서 사용하는 모든 객체에 대한 메모리 접근의 '쓰레드-안전(thread-safe)'을 유지하는 역할을 한다. 즉, 파이썬 객체는 한 번에 하나의 쓰레드에 의해서만 사용되도록 한다. C파이썬은 실질적으로 싱글 쓰레드라는 의미이기도 하다. 이 때문에 CPU 제약을 받는 멀티 쓰레드 연산은 C 확장 기능이나 여러 개의 C파이썬 인스턴스를 통해 처리해야 한다.

파이썬이 나온 이후 이 문제는 파이썬을 쓰기 위해 어쩔 수 없이 지급해야 하는 비용으로 받아들여졌다. 그러나 CPU 클럭 속도가 안정되고 코어가 확산하면서 파이썬은 태생적으로 멀티쓰레딩을 지원하는 언어에 점차 밀리고 있다.

물론 파이썬의 주요 응용 분야인 머신러닝과 통계 등의 많은 부분은 GIL의 제약을 받지 않는 C 코드로 가속한다. 그러나 이 문제는 점점 더 무시하긴 힘든 상황으로 치닫고 있다. 만약 파이썬 솔루션이 플랫폼 간에 이동이 더 쉽고 응용프로그램 간에 유연성이 더 높으면 개발자가 활용하기에 더 편해질 것이다.

이에 대해 C파이썬 개발자 래리 해스팅스은 'GIL 적출수술'이라고 부르는 작업을 진행 중이다. 그러나 GIL을 제거하는 가장 최근의 시도 결과를 보면, GIL 제거만으로는 완벽한 답이 되지 않는다. 이렇게 할 수는 있지만 주로 C 확장 기능인 기존 파이썬 패키지에 대한 하위 호환성이 중단될 위험이 있는 것이다.

따라서 이러한 노력이 성공하려면 C API와 하위 호환이 유지되면서 GIL을 제거해야 한다. 그러나 지금까지의 시도 결과는 성능 면에서 엄청난 손해가 동반됐다는 점이다. 해스팅스는 2017년 파이콘(PyCon) 행사를 통해 이러한 성과와 한계에 대해 발표하기도 했다. 현재는 GIL 제거 계획이 여전히 잠정적이고 실험적이다. 파이썬이 실제로 사용되는 방식 때문에 제약될 수밖에 없다. 그러나 C파이썬의 API 재작업이 끝나면 GIL 제거가 더 쉬워질 지도 모른다. ciokr@idg.co.kr 

X