한빛출판네트워크

1990년대 초반 귀도 반 로섬(Guido van Rossum)은 보다 우아하고 강력한 스크립팅 언어를 요구하는 회사 내부의 열망에 부응하여 파이썬이라는 언어를 암스테르담에 있는 CWI사에서 만들었다. 현재 그는 조프 코퍼레이션(Zope Corporation)사에서 파이썬랩(PythonLabs)사의 개발 팀을 이끌고 있다.

귀도는 곧 오라일리에서 개최할 오픈 소스 회의(Open Source Convention)에서 파이썬 연합체의 지위(State of the Python Union)에 관하여 세션 발표를 하기로 되어있다. 최근 바쁜 일정에도 불구하고 귀도는 잠깐 짬을 내어 파이썬과 오픈 소스 개발에 관하여 답변을 해주었다.

스튜어트: 바로 얼마 전에 파이썬 버전 2.2.1이 배포되었다고 하던데요. 이 버전에서 새로워진 점은 무엇입니까?

반 로섬: "2.1과 비교해 2.2는 무엇이 다른가?" 아니면 "2.2 이후로 2.2.1에는 어떤 새로운 점이 있는가?" 이렇게 두 가지 방식으로 이해할 수 있을 것입니다.

많은 사람들이 아직까지도 2.1.x 버전을 사용하고 있습니다. 2.2.1이 배포되기 몇일 전에도 버그를 수정한 버전으로 2.1.3을 배포하기조차 할 정도니까요. 따라서 첫 번째 질문은 중요합니다. 첫 번째 질문에 대한 대답으로는 대개 앤드류 쿠클링(Andrew Kuchling)이 파이썬 2.2에서 새로워진 점이라는 제목으로 작성한 글을 늘 인용합니다. 개인적으로 견해로 말해 요지는 반복자(iterators)와 발생자(generators) 그리고 새로이 구현된 클래스하고 할 수 있습니다. 지금 현재는 신형 클래스가 구형 클래스와 함께 있지만 결국 구형 클래스를 대체하게 될 겁니다.

"2.2.1에서 새로워진 것이 무엇인가"라는 질문에 대한 대답이 특별히 흥미롭지는 않습니다. 뭐 당연히 그래야 하겠지만요. 버전 2.2.1에서는 2.2에 새로이 도입된 특징을 더 안정적으로 만들고, 가끔씩 발생하는 오래된 버그들을 수정한 유지보수 배포판이니까요. 2.2 버전을 사용하고 있다면 2.2.1로 업그레이드하는 것이 좋습니다.

가까스로 새로운 특징의 약 절반정도를 완성했는데 이것은 실제로 2.3에 도입할 특징을 대략 구현한 것입니다. 그 특징들은 대략적으로 다음과 같습니다. 새롭게 도입한 내장 함수인 bool()은 임의의 값을 취해서 표준적인 True 값이나 False 값을 반환합니다. 내장 상수로 True와 False도 있습니다. 2.3에서는 bool이 별개의 형(type)이 된다는 것이 달라질 점이죠(int의 하부형). 2.2에서 bool()은 평범한 int를 반환하는 역할을 합니다. 2.3에 비해 더 호환성이 있기는 하지만 쓸모는 떨어지죠.

bool()을 2.2.1에 추가하여 도달하고자 하는 목표는 그 새로운 특징을 예상하는 코드를 작성하기 시작할 수 있도록 하는 데 있는 것이 아니라 하위 호환되는 코드를 2.2.1에서 2.3용으로 더욱 쉽게 작성할 수 있도록 하는데 있습니다.

스튜어트: 미래의 파이썬 버전에 개발되었으면 하고 간절히 바랄 만한 특징이 있다면 무엇이 있습니까?

반 로섬: 일단 언어이기 때문에 새로운 클래스가 완전히 통합되어 구현되기를 바랍니다. 상당히 난망한 일이긴 합니다. 특히나 파이썬의 진화 단계에서 지금은 하위 호환성이 중요하기 때문이지요.

또다른 하나는, 아주 오랜 시간이 지난 후의 일이긴 하겠지만 C나 기계어로 컴파일하는 것입니다. 사실 이것은 불가능한 일이고 어쩌면 그런 이유 때문에 별로 재미 없는 작업이라고 여겼었는데, 아민 리고(Armin Rigo)의 Psyco와 그레그 어윙(Greg Ewing)의 Pyrex 같은 최근의 실험을 보고 이것이 결국 가능할 것이라고 생각하게 되었습니다. 그렇게 되면 파이썬은 놀라울 정도로 성능이 향상되고 많은 사람들이 파이썬 사용을 주저하는 여러 이유들을 잠재울 수 있게 되겠지요.

그리고 IDLE의 새로운 버전이 별개의 프로젝트로 개발중이라 대단히 기쁩니다. Tkinter 기반의 파이썬 편집기겸 셸인 IDLE은 제가 언제나 관심을 가지고 있던 프로젝트였지만 사실 작업할 시간이 없었습니다. 다행스럽게도 몇몇 분들이 스티브 가바(Stephen Gava)의 지도아래 내가 빠트린 부분들을 메꾸어 주었고 다른 특징들을 새롭게 추가해 주었습니다.

아마도 IDLE에 대한 가장 큰 변화라면 실행을 분리한 것일 겁니다. 현재는 파이썬 명령어를 IDLE의 셸 환경에서 타자하면, IDLE이 실행되고 있는 프로세스와 같은 프로세스에서 그 명령어가 실행됩니다. 이 방법이 대단히 효율적이고 보통 IDLE의 내부 데이터를 사용자 코드와 따로 유지하기가 쉬운 반면, 어떤 작업은 어렵거나 불가능합니다. 예를 들어 Tkinter 메인 루프를 독자적으로 가진다거나(IDLE의 메인 루프에 방해가 됨), 또는 독자적으로 프로세스를 관리하는 프로그램을 테스트하는 경우가 그렇습니다.

현 버전에서는 문제를 일으키는(runaway) 코드를 가로채기도 어렵지만 이와 같은 문제들이 수정될 것으로 예상됩니다. 적절한 상호작용 설정 대화상자도 갖추어 질 것이고 프로그램 테스트를 위한 인터페이스는 더욱 더 직관적이 될 겁니다.

모든 사람들이 IDLE을 중요하게 생각하지 않는다는 것은 알고 있습니다. 그러나 상업적 제품들은 상당히 훌륭한 대안이라고 생각합니다. 핵심을 찌르는 질문을 해주셔서 감사합니다.

스튜어트: 무엇 때문에 파이썬을 개발하게 되었나요? 다른 스크립팅 언어에서는 사용할 수 없는 무엇인가가 필요했나요?

반 로섬: 나는 제대로 된 스크립팅 언어가 필요했습니다. 생각해보세요, 그 때가 벌써 12년 전이나 되는군요. 티클(Tcl)은 그 때까지 버클리대학의 실험실 안에서만 사용되고 있었습니다. 펄(Perl)이 나왔지만 제 개인적인 언어 디자인 감각에 맞지 않았을 뿐만 아니라 유닉스에만 엄격하게 제한되어 있었습니다.

나는 앤드류 타넨바움 그룹(Andrew Tanenbaum"s group)이 개발한 분산 운영 체제인 아메바(Amoeba) 프로젝트에서 가장 먼저 실행될만한 것이 필요했습니다. 그 플랫폼에서 사용할 수 있는 유일한 대안은 Unix V7 셸로 이식하는 것뿐이었지만 그 시절에는 아메바의 놀랍고도 새로운 능력을 이식하기 어려웠습니다.

나는 이와 같은 내외부적 필요를 결합하였습니다. 실패한 ABC 언어 프로젝트를 계승하고자 하는 욕망이 꿈틀대고 있었죠(아직도 웹에서 볼 수 있다).

나는 80년대 초반 ABC 개발 팀의 일원이었습니다. 그리고 머리속으로는 그 언어가 실패한 이유들을 분석하고 있었죠. 실패는 여러 면에서 측정할 수 있었습니다. 높은 관리 비용 때문에 그 프로젝트에서 모든 자금투자가 위축되었으며 다른 한편으로는 사용자가 거의 없었습니다. 나는 사용자가 없다는 것에 대한 이유들을 조금은 이해하였고, 파이썬이 어느 정도 그 문제에 대한 직접적인 대답이 되어주었죠.

부분적으로 ABC가 실패한 이유는 물론 그 정도로 고수준의 언어를 필요로 하기에는 시대가 너무 빨랐다는 것이었습니다. 물론 몇 가지 중요한 초기 디자인 결정이 그 언어를 소멸시킨 가장 큰 원인이기는 하지만 말입니다. 실패 요인을 목록화 하면 다음과 같습니다.

• 비관례적인 전문용어 사용: 초보자를 더 편안하게 해주기 위한 목적으로 만들어졌으나 숙련가는 이러한 신조어에 등을 돌림
• 새로운 특징을 추가하기가 어려운 모노리딕(monolithic)적 구현(† 역자 주: 통합적으로 구현)
• 이론적인 최적화 성능에 대한 지나친 강조
• 같은 컴퓨터에서 실행되는 다른 소프트웨어와 상호작용에 있어서의 유연성 부족(ABC는 한 프로그램 안에서 파일을 열 방법이 없었다)

파이썬은 객체지향적 디자인을 사용하고 확장 모듈을 쉽게 작성할 수 있도록 함으로써 이러한 문제들에 접근합니다.

스튜어트: 파이썬 개발 과정이나 파이썬 공동체에 변화를 주고 싶다면 무엇이 있을까요?

반 로섬: 예전처럼 공공체와 널리 대화를 나눌 수 있었으면 하는 바램입니다. 그러나 comp.lang.python에 오고가는 정보가 너무 엄청나서, 근래에는 거의 들여다보지 않습니다(나의 관심을 끄는 특별한 주제가 있지 않는 한 말이지요).

개발 과정에 변화를 주고 싶은 개인적 욕망은 없습니다. 파이썬은 파이썬 공동체의 성장과 함께 할 것이기 때문이지요. 언제인가 친구 하나는 "사람만 많으면 모든 주제가 논쟁의 대상이 된다"라고 말했습니다. 그리고 최근에 comp.lang.python을 들여다 본 바로는 이것이 현실화 되리라는 확신이 들었습니다. 그렇지만 파이썬 공동체는 필요한 처리과정과 메카니즘을 훌륭히 잘 개발해 나가리라고 생각합니다.

스튜어트: 파이썬 공동체는 조프(Zope)에 매료된 초보들의 유입에 잘 대처하고 있습니까?

반 로섬: 새로 들어오는 모든 초보가 조프(Zope)에 매료되었는지는 모르겠습니다. 미숙련 초보자들이 파이썬을 고려대상에 집어넣는 이유로는 다른 것들도 많이 있습니다. 예를 들어 점점 많은 수의 학교와 대학이 파이썬을 프로그래밍 개론 강좌에 사용하고 있는 것처럼 말입니다.

파이썬 공동체는 잘 대처하고 있다고 생각합니다. 숙련된 개발자들 역시 많이 들어오고 있으니까요. 그래서 초보들에게 더욱 도움이 될 수 있습니다. 그리고 더 많은 개발자들이 파이썬 언어를 진보시키는데 도움을 주고 있습니다.

스튜어트: 귀하의 프로젝트 리더쉽의 스타일은 어떤가요?

반 로섬: 솔직한 답변을 얻고 싶다면 나와 같이 일하고 있는 사람들에게 물어보는 편이 좋겠군요.

보통 나는 사람들에게 무엇을 어떻게 하라고 명령하는 것을 좋아하지 않습니다. 솔선 수범하여 이끄는 편을 좋아하죠. 결정을 내려야 할 경우, 보통 방대한 양의 피드백을 취합한 후에야 겨우 결정을 내립니다. 그렇다고 해서 내가 항상 권장 사항들을 따른다는 것은 아닙니다. 옳은 것을 선택할 수 있는 확실한 직관이 있다면 그리고 반론이 설득력 있게 들리지 않는다면 "민주주의"를 따르기 보다는 내 방식대로 합니다. 그렇지만 나중에라도 훌륭한 반론이 새로 나오면 나는 언제든 생각을 바꿀 의향이 있습니다.

나의 리더쉽 스타일에서 또다른 면은 내가 충돌(conflict)을 좋아하지 않는다는 것입니다. 항상 나는 "우리 모두 함께 사이좋게 지낼 수는 없는가?"라는 자세를 취하고 있습니다. 아마 심리학자라면 이런 나를 퓨저(† 역자 주: fuser, 녹여서 하나로 붙여주는 역할을 하는 물건. 예를 들어 레이저 프린터에서 예열 모듈, 의학에서 응고제)라고 부르겠지요. 어쩌면 이런 나의 성격 때문에 (아마 딱 두 명만 있는 것 같은데) 사람들이 파이썬 공동체에서 나에게 개인적인 반감을 품고 있는 듯이 보이는 것을 잘 받아들이지 못하는 것 같기도 하네요. 사람사이의 충돌을 이성적으로 처리하기 위하여 진짜 열심히 노력해야 하고 또 모든 사람을 만족시킬 수는 없다는 것을 나 스스로 인정해야겠지요.

스튜어트: 오픈 소스 프로젝트에서 가장 중요한 점이 무엇이라고 생각합니까?

반 로섬: 단 한 가지만 중요하다고 할 수는 없죠. 모든 것이 서로 조화를 잘 이룰 필요가 있습니다. 프로젝트는 반드시 필요를 충족시켜야 하고 또한 적소에 맞아야 합니다. 따라서 프로젝트 지도자는 반드시 제대로 된 리더쉽을 갖추고 훌륭한 기술을 갖고 있어야 하지만, 때로는 보다 전문적인 지식을 가진 다른 사람들의 의견을 따를 줄도 알아야 합니다. 그래서 여러 사람사이의 관계를 조절하는 소질이 있어야 하죠. 이는 사업을 성공으로 이끄는 요인들과 별로 다르지 않으리라 생각합니다.

파이썬이 기타 다른 성공한 오픈 소스 프로젝트와 공유하는 한가지 기술적 측면이 있다면 파이썬에 여러 수준의 확장성이 있다는 것입니다. 한편으로, 이 덕분에 수준이 천차만별인 최종 사용자들은 "가려운 곳을 긁을 수 있게" 파이썬을 적응시킬 수 있습니다.

초보자들은 파이썬 모듈을 만들고, 상급 개발자들은 파이썬이 자신을 떠나서는 할 수 없는 것들을 할 수 있도록 C나 C++로 확장 시킵니다. 그리고 파이썬은 오픈 소스이기 때문에 원하기만 한다면 언제든지 파이썬 인터프리터를 수정할 수 있습니다.

다른 긍정적인 부분이 있다면 핵심 개발자들이 최종 사용자의 문제를 해결하는데 이리저리 신경쓰지 않아도 된다는 것입니다. 나는 파이썬을 최종 사용자에게 적합하게 변경해달라는 요구를 받아본 적이 거의 없습니다. 설사 그런 요청을 받는다고 하더라도 파이썬을 변경할 필요없이 그들이 원하는 것을 해주는 확장 작성법을 설명해 주면 되니까요.

스튜어트: 상업적 소프트웨어의 개발에 적용될 수 있을 정도로 오픈 소스 파이썬 프로젝트가 성공했는데 이로부터 배울만한 교훈이 있다면 무엇이라고 생각하십니까?

반 로섬: 내가 대답하기 어려운 질문이기는 하지만 중요한 질문입니다. 지금 일하고 있는 Zope Corporation사를 제외하고는 상업적 소프트웨어 회사에서 일한 적이 없습니다. 나는 언제나 교육적 분위기(academic setting)에서 일했습니다. Zope Corporation사는 오픈 소스에서 얻은 교훈을 많이 적용하여 전 세계에 흩어져 있는 고객과 자유 개발자들을 깊숙히 끌어 들입니다. 이는 분산되고 개방된 개발 과정이라고 할 수 있죠. 또한 첨단 프로그래밍(Extreme Programming)도 많이 훈련합니다.

CTO인 짐 풀튼(Jim Fulton)은 "sprint"라고 부르는 아주 흥미로운 혁신을 하나 도입했습니다. 숙련된 프로그래머들과 아직은 부족한 점이 있는 수 많은 프로그래머들이 함께 모여 보통 페어 프로그래밍(pair-programming), 첨단 프로그래밍(Extreme-Programming) 방식으로 몇일 동안 강렬한 프로그래밍 세션을 갖는 것이죠.

Sprint의 참여자들은 오픈 소스 조프 코드베이스의 개발에 참여하는데 관심이 있는 사원들과 프리렌서들 모두를 포함합니다. sprint가 끝나면 보통 유닛 테스트를 장착한 의미심장한 코드를 새로이 확보합니다. 경험이 부족한 프로그래머들은 많은 것을 배울 수 있고 조프 프로젝트는 새로운 기여자를 확보하게 됩니다. 그 결과 이 과정에서 조프(Zope) 개발 과정은 다시 활력을 되찾을 수 있게 되죠.

이 과정에서 나는 오픈 소스로부터 그리고 나의 동료인 팀 피터스(Tim Peters)로부터 배운 교훈이 있습니다. 팀은 오픈 소스가 이제 자신에게 너무 중요하게 되었기 때문에 폐쇄된 소스를 다루는 회사로 다시 돌아가지 않겠다고 합니다. 이와 같은 경험에서 보듯이 내가 얻은 교훈은 오픈 소스는 개발 과정에서부터 아주 충성스런 피고용인(loyal employees)들이 탄생한다는 것입니다.

전형적인 폐쇄 소스를 다루는 회사에서 프로그래머들은 방대한 양의 코드를 개발하게 됩니다. 이 코드는 프로그래머들의 개인적인 애착이 묻어 있습니다. 그러나 프로젝트가 취소되면 회사에서는 다시 구조조정이 시작되고 관리방법이 변화하며 프로그래머들은 종종 자신이 개발한 코드에 접근할 기회까지도 잃게 되는데 이것은 정말 힘 빠지는 일입니다. 소스 코드를 공개적으로 개방하는 방식은 자신이 개발한 코드를 자랑스럽게 생각하기 때문에 계속해서 그 코드를 개선하게 만드는 진정한 동기가 됩니다.

스튜어트: 아직도 몬피 파이썬(Monty Python)이 재미있나요?

반 로섬: 거의 몬티 파이썬 쇼를 보지 못하지만 볼 수만 있다면 여전히 재미있을 거라고 생각됩니다. 몇몇 파이썬 최신 무비(Meaning of Life, Brazil)는 항상 즐겨 보는 것들 중에 하나이죠.

스튜어트: 요즘들어 재미 있는 일은 무엇입니까?

반 로섬: 아들 올리진(Orlijn)과 함께 놀면서 시간을 보내는 겁니다. 지금 태어난 지 7개월 밖에 안됐지만 제법 한 인격체로서의 인간으로 발달되어 간다는 생각이 드니까요. 유머 감각도 있고 그 녀석이 세상을 하나 하나 알아가면서 커간다는 것을 상상하는 것 만으로도 재미있습니다.

스튜어트: 곧 오라일리에서 개최될 오픈 소스 회의(OSCON, Open Source Convention)에서는 어떤 내용을 연설하실 생각이십니까?

반 로섬: 저는 마지막 순간이 되어서야 속마음을 밝히는 사람입니다. 그래서 아직 말씀 드릴 수 없네요. 그렇지만 지난 몇 년간 제가 경험하고 습득한 많은 교훈들이 중요한 역할을 할 것이라는 것은 분명합니다.

편집자 주: 우리에게는 실제로 귀도가 어떤 연설을 할 것인지 짐작은 하고 있다. 오라일리에서 개최할 오픈 소스 회의에서 그는 파이썬 연합체의 지위(State of the Python Union)와 관련하여 한 세션을 발표할 것이다. 최신 파이썬 배포와 새로운 기술을 비롯하여 향후 파이썬 계획 등에 대해 연설할 것이다.