한빛출판네트워크

저자: 카메론 레어드, 역 전순재

스택리스 파이썬은 파이썬의 향후 나아갈 방향이 궁금한가? 그렇다면 먼저 파이썬 프로그래밍 언어가 어디로 향하고 있는지부터 살펴볼 필요가 있다.

수 많은 뉴스들

귀도 반 로섬(Guido van Rossum)은 1989년 말 암스테르담에 있는 수학과 컴퓨터과학을 위한 국립 연구소^[1]에서 연구원으로 근무하는 동안 파이썬을 고안했다. 1995년 그가 입사한 회사는 버지지아주 레스톤에 본사를 둔 비영리 단체인 CNRI^[2]였다. 그렇지만 3월 말 "오픈-소스 애플리케이션 관문(portal)인" BeOpen.com사가 귀도와 그의 동료들을 고용하여 산타 클라라(Santa Clara)에 본사를 둔 BeOpen 네트워크 안에 PythonLabs를 구성하였다. PythonLabs의 본사는 여전히 레스톤(Reston)에 있다.

공학적 수준에서 버전 1.5가 다양한 배포본의 형태로 여전히 통용되고 있다(1.5.2는 파이썬 1.5의 마지막 배포본이 되었다). 파이썬 1.5 버전과 관련된 소식이 두 가지 있다. 하나는 1.6으로 불리며 2000년 9월 최종 형태로 배포되었다. 다른 하나는 2.0으로 지칭되며 2000년 10월에 배포되었다. 현업에 종사하는 대부분의 프로그래머에게 1.6과 2.0의 차이는 일상 작업에서 느낄 수 없을 것이다. 앤드류 쿠클링(Andrew Kuchling)은 파이썬 개발 메일링 리스트에 오가는 정보들이 깊은 토론 끝에 해결되면 한 달에 두 번 요약해 주는데 그는 이 차이를 다음과 같이 요약했다.

1.6은 2000년 3월 말 존재하는 파이썬 CVS 트리로서, 유니코드와 SRE[정규 표현식을 대체하는 모듈]가 모두 작동되도록 수정되었으며 새로이 갱신되었다. 2.0에는 2000년 3월 이후의 모든 개발 성과가 포함되며 그 성과에는 새로운 모듈들, 리스트 번역과 같은 언어의 중대한 변화들 대부분, 그리고 많은 수정 사항들이 포함된다.

왜 이 두 버전이 겉보기에 비슷한데도 서로 다른 라벨을 달고 있는가? CNRI에서 BeOpen으로 이사한 것을 비롯해 난마처럼 얽힌 이유때문에 이와 같은 약간은 혼란스런 결정이 나게 되었다. 파이썬 내부 핵심집단이 라이센스와 버전번호 매기기라는 복잡한 문제와 싸우고 있는 동안, 외부 개발자들은 거의 주목을 받지 못하고 소외되어 있었다.

• 파이썬은 여전히 자유롭다. 파이썬은 변경, 복사 등등에 제한이 없다. 적절하게 변호사와 상의하라.
• 파이썬 1.5와 비교해 볼 때 1.6과 2.0의 가장 큰 장점은 유니코드를 완전하게 지원한다는 것이다. 유니코드가 XML 표준에서 탁월하기 때문에 유니코드 지원에 대해 "국제화"에 별 관심이 없는 프로그래머조차도 큰 관심을 갖게 되었다. 또한, 2.0 배포본의 핵심(core)에는 이제 압축파일(zipfile)을 관리하고, 유니코드 변환, 메모리에-매핑된(memory-mapped) 파일 등등 유용한 라이브러리 모듈 여러 가지가 새로이 포함된다. 이외 다른 변화들은 대부분 기술적인 것으로 type에 대한 세부적인 사용법, 숫자 형식을 표시하는 법 등을 포함해 상대적으로 중요성이 덜한 다른 것들이다.

파이썬 1.6과 2.0은 스택리스(Stackless)라고 볼 수 없다. 파이썬 2.1과 "Python 3000" 모두 서로 다른 수준에서 이미 작업이 시작되었다. 우리는 "Python 3000" 부푼 마음으로 그렇게 부른다. 파이썬 2.1은 2.0을 계승하여 계속 발전할 것이다. Python 3000은 사실상 파이썬을 처음부터 전부 재작성하게 될 것이다. 아마도 가장 방대한 크기가 되지 않을까 싶다.

2.1에 스택리스(Stackless)를 포함할 것인지 말지에 대해서는 끊임없는 논의가 있어왔다. 과연 "2.1을 스택리스를 포함해야 하는가?"에 대한 논의는 이 시리즈의 첫번째 기사인 스택리스 파이썬 개론에 자세하게 설명되어 있지만, 가장 기본적인 질문에 대한 대답조차도 아직 결정되어 있지 않은 실정이다. 스택리스 파이썬을 사랑하는 팬들은 파이썬에 합병하는 것이 손쉬운 선택이라고 주장한다. 중요 임무를 띤" 애플리케이션 제작에 이미 수개월간 사용되어 온 것을 보면 스택리스 파이썬이 빠르고, 능력 있으며, 성숙하다는 것을 짐작할 수 있을 것이다. 스택리스 파이썬으로 변경하면 큰 비용을 들이지 않고서도 "완전한 승리"를 얻을 수 있다.

다른 편에서는 크게 아래와 같은 두 가지 주장이 있다

1. 반 로섬(Van Rossum)은 보수적인 사람이기 때문에 파이썬 개발에 신중하다. 스택리스 파이썬이 파이썬을 구현하는데 있어 한 면에 중대한 변경을 한다는 사실을 아무도 부인하지 않는다. 반 로섬(Van Rossum)은 시간을 가지고 천천히 이와 관련된 모든 사항들을 소화하고 그 변경이 파이썬이라는 언어에 진정으로 안전한가를 결정하기만 하면 된다.
2. JPython은 난색을 표명한다.

여기서 JPython에 대해 약간 설명할 필요가 있다.

미래를 예측할 수 없게 만드는 JPython

여러분이 데스크탑이나 서버에 1.5.2로 설치한 것과 같은 "정상적인" 파이썬은 소스코드가 C로 구현된다. 파이썬은 여러 가지 플랫폼에서 사용할 수 있다는 점에서 상당한 이식성이 있다. 같은 소스로 유닉스, 윈도우, 맥 OS, OpenVMS를 비롯한 기타 다양한 운영체제(OSs)에서 실행되는 파이썬 언어 처리기를 만들 수 있다. 이와 같은 "큰흐름의" 파이썬을 "Cpython"이라고 부른다.

현재 파이썬 인터프리터를 대체하여 구현한 몇몇 것들이 있지만, 대부분은 연구목적으로만 사용될 뿐이다. 그렇지만 우리가 이미 살펴본 바와 같이 스택리스 파이썬은 1.5.2에 구현된 거의 모든 것들을 공유하고 거의 똑같이 여러 운영체제에서 사용된다. 세 번째로 광범위하게 사용되는 파이썬 구현은 JPython이다.

JPython은 CPython과 거의 동일한 기능을 가지는 언어 처리기이지만 자바로 구현되었다. print 1 + 3라고 명령할 경우 CPython과 JPython 모두는 같은 작동을 하여 4를 화면에 보낸다. 그렇지만 그 차이는 JPython은 자바 가상 기계(JVM, Java Virtual Machine) 안에서 실행한다는 것이다. 예를 들어 이것은 곧 JPython 실체를 자바가 구동되는 웹 브라우저에서 시작할 수 있다는 것을 뜻한다. 그리고 그렇게 함으로써 클라이언트측 파이썬 웹 스크립트를 실행할 수 있다는 것을 뜻한다. 또한 JPython은 자바를 이해한다. 자바로 코딩된 실체를 만들 수 있으며 JPython안에서 자바 메소드들을 요청할 수 있다.

JPython은 중요하다. 대기업들은 자바를 표준으로 선택하고 있다. 그리고 Jpython이 그러한 수요를 채워준다.

그렇지만 JPython은 스택리스 파이썬에 대해 도전을 표명한다. JPython은 CPython 만큼 쉽게 스택리스 파이썬의 변경에 패치될 수 없다. 사실 신중한 파이썬 전문가들은 JPython이 본래적으로 스택리스와 호환되지 않는다고 믿고 있다. 이 문제는 궁극적으로 기술적으로 더 깊이 연구해야 확실한 해답을 얻을 수 있을 것이라 생각된다. 그러나 JPython을 스택리스로 갱신하는 작업은 약간 더 섬세하고 시간을 들이면 해결될 과제라는 생각에 대해서는 누구도 의심을 하지 않는다.

따라서 스택리스를 도입하게 될 경우 적어도 중-단기적으로 CPython과 JPython사이의 호환관계에 틈이 생기게 될 것이다. 어떤 스택리스 파이썬 팬들은 이 괴리현상의 중요성을 과소평가한다. 스택리스 파이썬의 열렬한 지지자중 한 사람인 귀도의 동생 저스트 반 로섬(Just van Rossum)은 2000년 8월초 "자바진영의 주장은 대단히 논리가 빈약한 주장이다."라는 기사를 썼다. 그 기사에 따르면 JPython이 CPython을 뛰어 넘어 자바 정의를 적재하는 잘-모듈화된 능력을 갖추었듯이, 장기적으로 보아 CPython이 import continuation이라는 스택리스의 능력을 부여하는 것이 전혀 해가 없다는 것이다.

마이크로스레드(Microthread) 전문가인 마이크 플레처(Mike Fletcher) 이에 대해 다른 점을 지적한다. 그에 따르면 JPython에서 완전한 콘티뉴에이션(continuations)을 구현하는 것은 힘들겠지만, 마이크로스레드(microthreads)와 코루틴(coroutines) 같은 고수준 인터페이스는 JPython의 쓰레드(threads)로 적절하게 흉내낼 수 있다고 한다. 만약 개발자들 대부분이 스택리스 파이썬에 대해 이러한 API 만을 이용한다면 JPython에서 그에 상응하는 구현과 충돌할 필요가 없다. 단 충분한 메모리와 그에 관련된 자원들을 가지고 JVM 안에서 그 프로그램들을 실행하는 한 말이다.

스택리스 파이썬의 사용

그렇지만 스택리스 파이썬이 도입한 제어 구조는 특별 목적의 자바 클래스 정의보다 더 섬세하고 광범위해 보인다. 공학자들은 열광적으로 스택리스를 사용하고 싶어한다. CPython이 스택리스(Stackless)가 된다고 상상해보자. 그렇게 되면 스택리스 파이썬의 콘티뉴에이션에 의존하는 애플리케이션들이 번성하기 시작할 것이다. 이렇게 번성한 많은 프로그램들이 JPython으로 돌아가지 않는다면 전체적으로 파이썬에게 이익이 있는가? 그 문제가 바로 귀도 반 로섬과 그의 조언자 코어 팀 앞에 던져진 골치 아픈 문제인 것이다.

수 십 명의 선도적인 파이썬 플레이어와의 대화를 모두 종합해 보면 다음과 같은 "평균적인" 결과를 얻을 수 있다. CPython 2.1이 성숙한 스택리스 코드에 기초를 두고, 다시 말해 디스머(Tismer)가 이미 수 개월동안 사용해온 코드에 기초를 두고 거의 대부분이 재작성될 것이다. 이렇게 재작성하게 되면 스택 보호, 성능향상, 그리고 팜 OS와 같은 특별한 환경에 대한 적합성이라는 구현상의 이점들을 얻을 수 있다. 미래의 배포본에 남겨질 문제는 스택리스 경계 문제가 뿐이다. 경계 문제가 되는 특수 클래스 사이의 관계를 디스머는 현재 FrameState와 FrameData라고 부른다. 또 콘티뉴에이션(Continuation), 코루틴(CoRoutine), 제너레이터(Generator), 마이크로스레드(Microthread) 등등의 사용자 수준에 국한된 코딩 인터페이스는 2.1에 진입하지 못할 수도 있다. 바이트 코드 인터프리터를 제일 먼저 뜯어 고쳐야 하는 스택리스를 이식하는 수술과 이와 같은 사용자 수준의 인터페이스는 서로 별개의 문제이다. 병행 프로그래밍 인터페이스에 대한 세부사항은 아마도 파이썬 2.1을 계승한 버전이 발표되는 시기에 맞추어 구체화될 것 같다.

약간만 스택리스 파이썬이라는 변종을 2.1에 포함시키면 디스머와 그의 동료들은 파이썬 개발을 따라 방대한 패치들을 계속해서 추적할 필요가 없어지고 시간적인 여유를 가지게 될 것이다. 그러면 디스머는 더욱 많은 시간을 투자하여 스택리스 파이썬을 다듬어 성능, 영속성, 그리고 확장성을 개선할 것이다. 스택리스 파이썬의 지지자들은 병행적으로 프로그래밍 인터페이스를 공개하면서 문서화할 수 있을 것이다. 스택리스 파이썬이 파이썬 배포본의 핵심(core)에 들어가는데 성공한다면, 빠른 속도로 많은 사람들이 사용하게 되리라 생각한다.

스택리스 파이썬이 파이썬 2.1에 성공적으로 진입할 것 같다고 보는 것은 타당성 있게 보인다. 일단 성공적으로 진입하면 활동이 봇물처럼 터져 나와, 고수준 인터페이스가 (무엇보다도 마이크로쓰레드와 코루틴이) 2.2에 자리 잡게 될 것이다. 스택리스 파이썬의 진입은 충분히 흥미로운 변화로서 진입이 미치게 될 모든 영향들을 이해하는데는 몇 달이 걸릴지도 모른다. 다만 파이썬 미래의 그림에 그림자를 드리우는 것이 또 있다면 마이크로소프트의 .NET 테크놀러지가 중요한 다크호스로 출현했다는 것이다. .NET은 비약적인 발전을 준비하고 있는 듯이 보인다. 그리고 파이썬 .NET 인터프리터는 특히 이 과정에서 중대한 역할을 할 것이다. 스택리스 파이썬과 파이썬 .NET은 서로 어떤 충격을 주고 받을 것인가? 지금까지 전문가들의 의견에 의하면 서로를 목표로 하여 그 둘을 구축하는 작업을 할 것이라고 한다.

카메론 레어드(Cameron Laird)는 Phaseit, Inc.사의 부사장이며, 오픈-소스 테크놀러지에 관하여 자주 글을 쓴다.

---

^[1] National Research Institute for Mathematics and Computer Science (Centrum voor Wiskunde en Informatica--CWI)
^[2] Corporation for National Research Initiatives