IT/모바일
by 카메론 레이어드
가장 좋아하는 언어를 크기가 더 작고, 더 빠르고, 유연성 있으며 안전하게 사용하고 싶은가? 이것이 스택리스 파이썬(Stackless Python)이 주장하는 바이다.
스택리스 파이썬은 독립적인 개발자 크리스찬 티즈머가 대안적인 구현으로서 만든 것이다. 그는 파이썬의 창시자 귀도 반 로섬이 관리했던 종래의 파이썬 언어 프로세서에서부터 출발해서 자기만의 스택리스를 파이썬 내부의 작지만 중심적인 부분에 패치시켰다.
스택리스 파이썬은 이렇게 해서 생긴 것이다. 이 기사에서는 티즈머의 기술을 소개하고, 그것이 왜 중요한지 설명한다. 앞으로의 기사에서는, 스택리스와 파이썬의 주된 배포판을 통합하는 것에 대한 조망과 함께 스택리스 파이썬을 프로그램하는 것을 어떻게 시작하는지 설명할 것이다.
왜 스택리스인가?
대부분의 흥미있는 기술이 그렇듯이, 스택리스를 다루는 사람들은 다양하지만 서로 밀접한 연관성이 있는 관심사가 있다. 여기에 임하고 있는 사람들은 동기와 지식이 놀라울 정도로 서로 다르지만, 지금까지는 상대적으로 순조롭게 일을 진행해 왔다.
티즈머는 모험가적인 기질이 있다. 그는 스택리스에 대해서 들었을 때 무언가 "가능해 보이는" 것을 할 수 있는지 시험해 보고 싶어서 스택리스를 만들게 되었다. 처음에 그런 생각을 하게 된 동기는, 우연히 파이썬 구현에 대한 기술적인 토론의 메일링 리스트를 읽은 것이었다. 1999년 초기에, 샘 러슁(Sam Rushing) 등은 현재의 파이썬 디자인은 코루틴(coroutine)을 잘 지원해 주지 않는다고 지적했다. 코루틴은 병행(concurrency) 구조이다. 즉, 다른 작업이 다 끝나지 않아도 연산을 실행할 수 있는 것을 관리하는 모델이다. 스레드(thread)와 이벤트는 병행(concurrency)이나 멀티 프로세싱과 같은 역할을 수행한다. 자바나 다른 언어들과 같이, 파이썬은 직접적으로 스레딩 모델을 지원한다. 스레드는 대학의 프로그래밍 과정에서 많이 가르치는 과목이다.
역주: 우리가 워드를 실행하면 OS에서 하나의 프로세스가 실행되는 것이다. 워드에서 우리가 단어를 입력하는 동안, 워드는 자동으로 맞춤법 검사를 하면서 틀린 맞춤법에는 빨간색 밑줄을 나타낸다. 이것은 키보드를 통해 단어를 입력받는 스레드, 맞춤법 검사를 하는 스레드, 화면에 글자를 표시하고 틀린 부분에 밑줄을 표시하는 스레드가 동작하고 있는 것이다. 워드라는 하나의 프로세스를 여러 개의 스레드가 일을 나누어 처리하고 있는 것이다. 만약 스레드가 없다면 단어를 입력하는 동안은 맞춤법 검사를 할 수 없을 것이고, 맞춤법 검사를 하는 동안은 단어를 입력할 수 없을 것이다.
하지만 코루틴은 덜 전문적이며, 사용자들이 올바르게 사용할 수 있도록 배려를 더 하고 있기 때문에 스레드보다 안전하다는 시각이 있다. 1963년, 멜빈 콘웨이(Melvin E. Conway)는 대칭성의 연산을 모델링하기 위해 코루틴을 소개했다. 여기서 각각의 코루틴은 동일한 "랭크(rank)"를 가지고 작동한다. 이것은 하나의 메쏘드가 다른 것을 불러 오는 책임을 맡고 있어서, 우리가 일반적으로 하는 코딩 절차외는 반대가 된다. SIMULA나 Modula와 같은 언어들에서는 코루틴을 잘 활용하고 있고, 특정 목적을 가진 라이브러리는 C++과 자바에서 코루틴을 사용할 수 있도록 해 준다.
역주: 코루틴(Coroutine) : 컨트롤 플로우로, 특히 컴파일러와 같은 파서(parser)나 상태 기계(state machine) 구현에 자주 사용된다. 일반적으로 a 함수와 b 함수가 있고, a함수가 b 함수를 호출하면 b 함수는 a 함수에 종속적인 관계를 갖게 된다. 그러나 코루틴에서는 a 함수와 b 함수를 대등한 관계로 본다. 즉, a 함수가 b 함수를 호출하고, b 함수가 다시 a를 호출하면 a에서 실행이 멈춘 부분부터 실행을 시작한다. 다시 a에서 b를 호출하면 b에서 실행이 멈춘지점부터 실행이 시작된다. 이 둘의 관계를 코루틴이라고 한다. 즉, 시스템에 동시에 존재하는 셈이다.
한 메소드에서 다른 메소드로 통제가 이동할 때 필요한 정보를 유지하는 방식과 관련해서, 러슁은 파이썬 구현의 기술적인 한계에 뛰어들었다. 표준 파이썬 배포판에는 인터프리터의 상태 정보와 현재 실행되고 있는 파이썬 코드의 정보가 동일한 "스택" 안에 뒤섞여 있다.
역주: 파이썬은 C 언어로 구현되어 있다. 따라서 파이썬으로 작성된 프로그램을 파이썬이 인터프리트 할 때 인터프리터 자체가 이용하는 상태 정보와 파이썬 코드의 정보가 동시에 존재한다. 스택리스 파이썬은 파이썬을 C 스택하고 분리한 것이다.
두 가지의 서로 다른 정보를 같은 스택에 담음으로써 파이썬의 초기 개발이 단순화되었다. 러슁의 실험 이전에도, 파이썬 전문가들은 이러한 한계에 여러 번 부딪혔다. 스티븐 매주스키가 90년대 중반에 코루틴과 밀접한 관계가 있는 "제너레이터(Generator)"를 개발하는 일을 했을 때를 예로 들 수 있다. 제너레이터와 마이크로스레드는 스택리스 파이썬 기능이 가능한 프로세싱이나 병행(concurrency) 모델이다.
역주: OS에서 스레드를 제어하는 것은 한계가 있고, 동시에 많은 수의 스레드를 돌리지 못한다. 그에 비해서 마이크로스레드를 이용하면 수천, 수만개의 스레드를 돌릴 수 있다.
컨티뉴에이션 어려움을 가능한 한 정확하게 설명하려고 하는 과정에서, 파이썬 개발 공헌자인 러슁과 팀 피터스는 컨티뉴에이션을 강조했다. 컨티뉴에이션은 가장 초보적이거나 기초적인 멀티프로세싱 구조이다. 제너레이터나 코루틴, 스레드 등은 컨티뉴에이션의 직접적인 표현이다. 티즈머는 메일링 리스트 스레드를 읽기 시작했을 때 컨티뉴에이션이 무엇인지 몰랐지만, 자신이 잘 알지 못하는 컨티뉴에이션에 도전하고 싶어했다. 그는 멀티프로세싱 통제 구조에 대한 책을 읽고는, 이전에 했던 일을 파이썬을 통해 바라보았다. 그는 파이썬 "프레임"의 레이아웃을 공부했다. 프레임이란, 불러낸 서로 다른 메쏘드에 대한 정보가 보존되는 스택의 세그먼트이다. 티즈머는 점점 새로운 외부의 종래의 스택을 운영하는 콜링 프레임 매니저에 이식하기 위해서 파이썬을 정확하게 바꿀 수 있겠다고 확신하게 되었다. 스택리스 레이어 "스택리스 파이썬"은 사람들에게 각각 다른 의미를 가진다. 티즈머에게 스택리스 파이썬은 내부적이거나 구현된 것이다. "단지 약간의 C 모듈"만 변화시켜서, 그는 C 스택에서 프레임 스택을 분리했다. 현재 이러한 작업은 완료되었고, 유용하게 쓰이고 있다. 티즈머는 여러 가지 세부 사항을 개선하기 위해서 스택리스에 노력을 쏟았다. 스택리스는 지금 있는 "순수한" 파이썬 애플리케이션, 즉 파이썬으로만 개발된 애플리케이션과 경쟁할 만 하다. 하지만 많은 파이썬 애플리케이션에는 다른 언어(일반적으로 C)로 코드된 것들이 조금씩 들어있다. 파이썬이 다른 언어들과 "잘 조화되도록" 하는 것은 많은 프로그래밍 팀에서 추구하는 주요 목표 중 하나이다. 섬머 2000(summer 2000)의 스택리스 파이썬은 종래의 파이썬에 비해서 교차 언어(cross-language) 작업으로서 약간 다른 인터페이스를 가지고 있다. 몇 가지 언어를 함께 사용하는 일부 프로젝트에서는 단지 스택리스 파이썬이 대체용으로 "끼어들었다"는 점 때문에 스택리스 파이썬을 허용하지 않는다. 그리고 티즈머는 코루틴과 같이 부가적이고 높은 수준의 구조를 더 잘 지원할 수 있는 발전된 개념을 찾고 있다. 공식적인 코루틴은 컨티뉴에이션 위에 있는 층으로 구현되어야 할 것인가? 파이썬 스타일에 가장 잘 맞는 코루틴의 정확한 정의는 무엇인가? 이러한 세부 사항은 제쳐 두더라도, 스택리스 파이썬은 구현 그 자체로서 중요하다. 종래의 파이썬에서는 스택에 너무 많은 정보가 담겨 있기 때문에, 회귀의 깊이를 제한한다. 프로그램을 차곡 차곡 포개 넣거나 깊이 회귀하는, 스케일이 큰 애플리케이션은 단지 스택을 다 소진해버렸다는 이유 때문에 수행에 실패할 수도 있다. 스택리스 파이썬은 상태 거의 모든 정보가 힙 메모리에 저장이 되기 때문에, 이러한 점에서의 제약이 더 적다. 그리고 코루틴으로 스택리스 파이쎤을 구현한 병행(concurrency) 알고리즘이 스레드로 구현된 파이썬보다 응답 속도가 세 배 정도 빠르게 실행된다. 하지만, 구현의 변화는 다양한 결과의 레이어를 가지고 있다. 티즈머가 여기까지 드러낸 주된 프로그래밍 인터페이스는, continuation 모듈이다. 일반적으로 continuation은 파이썬 애플리케이션 개발자들이 어렵다고 느끼지만, 그것은 시스템 프로그래머들이 블록을 구축하기에 딱 알맞다. 그들은 continuation을 기본으로 가지고, 스레드보다 훨씬 더 잘 수행하고, 이해하기 더 쉬운 새로운 병행(concurrency) 정의를 레이어로 분리하였다. 티즈머는 스택리스 대해서, 대개 파이썬 통역에 의해서 생기는 커널과 어떻게 그것의 아키텍처를 강하게 할 지에 대해 생각한다. 이로 인해서 혁신적인 통제 구조를 만드는 것이 가능해졌다. 그들의 파이썬 수준의 모듈 정의는, 반대로 코루틴과 마이크로스레드, 그리고 실제적인 프로그래밍 문제를 담고 있는 다른 상위 수준의 병행(concurrency) 모델을 제공한다.
역주: 우리가 워드를 실행하면 OS에서 하나의 프로세스가 실행되는 것이다. 워드에서 우리가 단어를 입력하는 동안, 워드는 자동으로 맞춤법 검사를 하면서 틀린 맞춤법에는 빨간색 밑줄을 나타낸다. 이것은 키보드를 통해 단어를 입력받는 스레드, 맞춤법 검사를 하는 스레드, 화면에 글자를 표시하고 틀린 부분에 밑줄을 표시하는 스레드가 동작하고 있는 것이다. 워드라는 하나의 프로세스를 여러 개의 스레드가 일을 나누어 처리하고 있는 것이다. 만약 스레드가 없다면 단어를 입력하는 동안은 맞춤법 검사를 할 수 없을 것이고, 맞춤법 검사를 하는 동안은 단어를 입력할 수 없을 것이다.
하지만 코루틴은 덜 전문적이며, 사용자들이 올바르게 사용할 수 있도록 배려를 더 하고 있기 때문에 스레드보다 안전하다는 시각이 있다. 1963년, 멜빈 콘웨이(Melvin E. Conway)는 대칭성의 연산을 모델링하기 위해 코루틴을 소개했다. 여기서 각각의 코루틴은 동일한 "랭크(rank)"를 가지고 작동한다. 이것은 하나의 메쏘드가 다른 것을 불러 오는 책임을 맡고 있어서, 우리가 일반적으로 하는 코딩 절차외는 반대가 된다. SIMULA나 Modula와 같은 언어들에서는 코루틴을 잘 활용하고 있고, 특정 목적을 가진 라이브러리는 C++과 자바에서 코루틴을 사용할 수 있도록 해 준다.
역주: 코루틴(Coroutine) : 컨트롤 플로우로, 특히 컴파일러와 같은 파서(parser)나 상태 기계(state machine) 구현에 자주 사용된다. 일반적으로 a 함수와 b 함수가 있고, a함수가 b 함수를 호출하면 b 함수는 a 함수에 종속적인 관계를 갖게 된다. 그러나 코루틴에서는 a 함수와 b 함수를 대등한 관계로 본다. 즉, a 함수가 b 함수를 호출하고, b 함수가 다시 a를 호출하면 a에서 실행이 멈춘 부분부터 실행을 시작한다. 다시 a에서 b를 호출하면 b에서 실행이 멈춘지점부터 실행이 시작된다. 이 둘의 관계를 코루틴이라고 한다. 즉, 시스템에 동시에 존재하는 셈이다.
한 메소드에서 다른 메소드로 통제가 이동할 때 필요한 정보를 유지하는 방식과 관련해서, 러슁은 파이썬 구현의 기술적인 한계에 뛰어들었다. 표준 파이썬 배포판에는 인터프리터의 상태 정보와 현재 실행되고 있는 파이썬 코드의 정보가 동일한 "스택" 안에 뒤섞여 있다.
역주: 파이썬은 C 언어로 구현되어 있다. 따라서 파이썬으로 작성된 프로그램을 파이썬이 인터프리트 할 때 인터프리터 자체가 이용하는 상태 정보와 파이썬 코드의 정보가 동시에 존재한다. 스택리스 파이썬은 파이썬을 C 스택하고 분리한 것이다.
두 가지의 서로 다른 정보를 같은 스택에 담음으로써 파이썬의 초기 개발이 단순화되었다. 러슁의 실험 이전에도, 파이썬 전문가들은 이러한 한계에 여러 번 부딪혔다. 스티븐 매주스키가 90년대 중반에 코루틴과 밀접한 관계가 있는 "제너레이터(Generator)"를 개발하는 일을 했을 때를 예로 들 수 있다. 제너레이터와 마이크로스레드는 스택리스 파이썬 기능이 가능한 프로세싱이나 병행(concurrency) 모델이다.
역주: OS에서 스레드를 제어하는 것은 한계가 있고, 동시에 많은 수의 스레드를 돌리지 못한다. 그에 비해서 마이크로스레드를 이용하면 수천, 수만개의 스레드를 돌릴 수 있다.
컨티뉴에이션 어려움을 가능한 한 정확하게 설명하려고 하는 과정에서, 파이썬 개발 공헌자인 러슁과 팀 피터스는 컨티뉴에이션을 강조했다. 컨티뉴에이션은 가장 초보적이거나 기초적인 멀티프로세싱 구조이다. 제너레이터나 코루틴, 스레드 등은 컨티뉴에이션의 직접적인 표현이다. 티즈머는 메일링 리스트 스레드를 읽기 시작했을 때 컨티뉴에이션이 무엇인지 몰랐지만, 자신이 잘 알지 못하는 컨티뉴에이션에 도전하고 싶어했다. 그는 멀티프로세싱 통제 구조에 대한 책을 읽고는, 이전에 했던 일을 파이썬을 통해 바라보았다. 그는 파이썬 "프레임"의 레이아웃을 공부했다. 프레임이란, 불러낸 서로 다른 메쏘드에 대한 정보가 보존되는 스택의 세그먼트이다. 티즈머는 점점 새로운 외부의 종래의 스택을 운영하는 콜링 프레임 매니저에 이식하기 위해서 파이썬을 정확하게 바꿀 수 있겠다고 확신하게 되었다. 스택리스 레이어 "스택리스 파이썬"은 사람들에게 각각 다른 의미를 가진다. 티즈머에게 스택리스 파이썬은 내부적이거나 구현된 것이다. "단지 약간의 C 모듈"만 변화시켜서, 그는 C 스택에서 프레임 스택을 분리했다. 현재 이러한 작업은 완료되었고, 유용하게 쓰이고 있다. 티즈머는 여러 가지 세부 사항을 개선하기 위해서 스택리스에 노력을 쏟았다. 스택리스는 지금 있는 "순수한" 파이썬 애플리케이션, 즉 파이썬으로만 개발된 애플리케이션과 경쟁할 만 하다. 하지만 많은 파이썬 애플리케이션에는 다른 언어(일반적으로 C)로 코드된 것들이 조금씩 들어있다. 파이썬이 다른 언어들과 "잘 조화되도록" 하는 것은 많은 프로그래밍 팀에서 추구하는 주요 목표 중 하나이다. 섬머 2000(summer 2000)의 스택리스 파이썬은 종래의 파이썬에 비해서 교차 언어(cross-language) 작업으로서 약간 다른 인터페이스를 가지고 있다. 몇 가지 언어를 함께 사용하는 일부 프로젝트에서는 단지 스택리스 파이썬이 대체용으로 "끼어들었다"는 점 때문에 스택리스 파이썬을 허용하지 않는다. 그리고 티즈머는 코루틴과 같이 부가적이고 높은 수준의 구조를 더 잘 지원할 수 있는 발전된 개념을 찾고 있다. 공식적인 코루틴은 컨티뉴에이션 위에 있는 층으로 구현되어야 할 것인가? 파이썬 스타일에 가장 잘 맞는 코루틴의 정확한 정의는 무엇인가? 이러한 세부 사항은 제쳐 두더라도, 스택리스 파이썬은 구현 그 자체로서 중요하다. 종래의 파이썬에서는 스택에 너무 많은 정보가 담겨 있기 때문에, 회귀의 깊이를 제한한다. 프로그램을 차곡 차곡 포개 넣거나 깊이 회귀하는, 스케일이 큰 애플리케이션은 단지 스택을 다 소진해버렸다는 이유 때문에 수행에 실패할 수도 있다. 스택리스 파이썬은 상태 거의 모든 정보가 힙 메모리에 저장이 되기 때문에, 이러한 점에서의 제약이 더 적다. 그리고 코루틴으로 스택리스 파이쎤을 구현한 병행(concurrency) 알고리즘이 스레드로 구현된 파이썬보다 응답 속도가 세 배 정도 빠르게 실행된다. 하지만, 구현의 변화는 다양한 결과의 레이어를 가지고 있다. 티즈머가 여기까지 드러낸 주된 프로그래밍 인터페이스는, continuation 모듈이다. 일반적으로 continuation은 파이썬 애플리케이션 개발자들이 어렵다고 느끼지만, 그것은 시스템 프로그래머들이 블록을 구축하기에 딱 알맞다. 그들은 continuation을 기본으로 가지고, 스레드보다 훨씬 더 잘 수행하고, 이해하기 더 쉬운 새로운 병행(concurrency) 정의를 레이어로 분리하였다. 티즈머는 스택리스 대해서, 대개 파이썬 통역에 의해서 생기는 커널과 어떻게 그것의 아키텍처를 강하게 할 지에 대해 생각한다. 이로 인해서 혁신적인 통제 구조를 만드는 것이 가능해졌다. 그들의 파이썬 수준의 모듈 정의는, 반대로 코루틴과 마이크로스레드, 그리고 실제적인 프로그래밍 문제를 담고 있는 다른 상위 수준의 병행(concurrency) 모델을 제공한다.
To be continue...
TAG :
이전 글 : LPIC Level 1: 101 시험에 대한 50가지 팁
다음 글 : 제니퍼 니더스트와의 인터뷰
최신 콘텐츠