IT/모바일
제공 : 한빛 네트워크
저자 : chromatic
역자 : 이대엽
원문 : The Evolution of Python 3
2008년 12월, 파이썬 개발자들은 인기있는 동적 프로그래밍 언어인 파이썬의 새로운 버전인 3.0을 출시하였다. 파이썬의 창시자인 귀도 반 로섬(Guido van Rossum)이 지난 몇 년동안 파이썬 3000(파이썬 3.0으로 이름이 바뀜)의 사상에 관해 논의하는 가운데 파이썬 커뮤니티는 2005년 초반 파이썬 3000의 개발에 착수했다. 귀도는 개발 과정과 이 같은 새로운 출시 버전이 파이썬의 미래에 어떤 의미가 있는지에 관해 논의하는데 선뜻 응해 주었다. (본 인터뷰는 2009년 1월에 진행되었다.)
우선 파이썬 3.0이 출시된 걸 축하드립니다.
귀도 반 로섬: 감사합니다.
나온지 꽤 된걸로 알고 있습니다만, 귀도씨가 보시기에는 개발 과정이 성공적이었습니까?
귀도 반 로섬: 파이썬 커뮤니티 관점에서는 성공적이었기 때문에 적어도 제 관점에서는 그게 성공적이었는지는 크게 중요하지 않습니다. 개발 과정은 재미있었습니다. 실제로 제가 파이썬 3000에 관해 생각하기 시작한 건 2000년부터입니다. 그때부터 저는 실질적으로 파이썬 3000과 관련된 작업, 말하자면 실제로 파이썬 3000을 설계하고 모든 이들과의 합일점을 도출하는 등의 일을 약 3년전에 제가 막 구글에 입사해서 파이썬과 관련된 일을 하는데 시간을 더 쏟을 수 있는 즈음에 시작했죠. 꽤 오랫동안 실제로 저는 프로젝트를 진행시켜 왔고, 많은 이들을 들뜨게 만들었습니다. 유로 파이썬(Euro Python)에서 열린 파이콘(PyCon; 파이썬 컨퍼런스)이나 다른 컨퍼런스에서 매년 강연을 하기도 했습니다. 그리고 지난 12달 동안에는 개발자 커뮤니티에서 파이썬 3000의 최종 세부 사항들을 마무리하고 출시를 준비하는 동안 온전히는 아니지만 상당 부분을 개발 과정에 직접적으로 관여하지는 않고 개발과정을 지켜보며 조율하는 역할을 담당했습니다.
이번에는 개발에서 맡은 역할이 적었습니까?
귀도 반 로섬: 저는 1년 전까지 개발을 한 후에 아마 여러가지 이유로 구글에서 다른 팀으로 배치받기도 했으며, 다소 덜 적극적인 역할을 담당했습니다. 저는 매주 2~3일 정도를 코딩이나 설계, 검토를 하면서 보내진 않았죠. 저는 계속해서 이메일을 확인했지만 제가 개발에 관여하는 일을 줄이고 대신 코어 파이썬 개발 그룹에 계신 분들이 스스로 대부분의 일을 처리하도록 했습니다. 제가 생각하기에 그분들께서는 굉장히 일을 잘하시더군요.
파이썬 2.6과 파이썬 3의 개발 그룹은 어느 정도로 비슷한가요?
귀도 반 로섬: 거의 같은 팀이라고 보시면 됩니다. 그렇기 때문에 어느 정도 비슷하게 출시할 수 있었죠. 저희가 실제로 3년 전에 3.0의 아이디어를 내기 시작했을 때 처음 1년은 주로 상당한 양의 PEP(Python Enhancement Proposal)를 작성하고 잠재적인 변경 사항에 관해 논의하느라 개발이 어떻게 진행되어야 할 지에 관해서는 거의 생각할 수가 없었죠.
차차 작업을 시작했을 때, 그러니까 배리(Barry, 아이디: Warsaw)가 출시 관리자를 하기로 했을 때, 저희는 2.6과 3.0의 출시 버전이 실제로는 다양한 방식으로 서로 연관되어 있었기 때문에 2.6과 3.0을 맞춰서 출시하는게 꽤 괜찮은 생각이라 생각했습니다.
두 출시 버전이 연관되어 있는 부분 중에서 가장 중요한 부분은 아마 2.6이 상당수의 3.0 기능에 대한 백포트(backport) 를 가지고 있는 것이었을 겁니다. 백포트하기가 힘든 경우에는 이전 2.X 버전과는 호환되어야 하지만 3.0에서는 동작하지 않을 것이므로, 2.6에서는 여전히 동작한다는 경고를 보여주게 됩니다.
그 아이디어는 누가 낸거죠? 다시 생각해 보니 당연한 것처럼 들리긴 하지만 좋은 아이디인 것 같군요.
귀도 반 로섬: 솔직히 기억나진 않습니다. 이건 저희도 오랫동안 가지고 있었던 아이디어입니다. 약 2년 전 파이썬 컨퍼런스에서 나왔던 것 같은데, 제가 알기로 2년이 채 되기 전에 사람들이 파이썬 3000에 관해 진지하게 생각하고 있을 때 새로운 버전이 출시될 것이고 기존 버전과 호환되지 않기 때문에 수많은 기존 써드 파티 파이썬 프로젝트에 영향을 줄거라고 생각했을 때였던 것 같습니다.
제 기억으로는 Twisted 개발자 그룹과 “다 좋은데”라고 했던 몇몇 PSF(파이썬 소프트웨어 재단; Python Software Foundation) 게시판 회원들이 만들어 놓은 일종의 복병이었던 것 같습니다. 그분들은 제가 파이썬 3.0에서 바뀌는 부분과 바뀌지 않는 부분에 대해서 그때까지도 윤곽만을 잡고 있었을 때 했던 키노트만 들었을 뿐이죠. 그분들은 저한테 이렇게 말씀하시더군요. “말씀하신 내용을 들어보니 다 괜찮고, 저희도 파이썬이 그런 방향으로 발전했으면 좋겠습니다. 헌데 다른 프로젝트에서 그런 변화를 어떻게 처리할 지에 대해서도 생각해 보셔야 할 것 같군요.”
언제나 새 버전의 배포판에 하위 호환성(backward compatibility)과 관련된 항목이 있는 경우에는 새 버전으로 옮겨가는 것이 예전에 했던 것만큼이나 쉽지는 않을 겁니다. 버전 이전(transition) 전략과 관련된 다양한 부분에 관해 생각해 내는 것처럼 여러 차례에 걸쳐 브레인스토밍 회의를 한다고 해도 그럴 가능성은 충분히 있죠. 이 부분에 대해서 연구해 보신적이 있는지는 잘 모르지만, 2에서 3으로 소스 대 소스로 이행하는 툴도 있는데 이건 파이썬이 동적 언어(dynamic language)라서 실제로 변수가 어떤 타입인지에 대해서 지능적으로 알아낼 필요까지는 없다는 점 때문에 가능하죠.
한편으로 툴이 개발자를 돕지 못하거나 도와주기에 충분하지 않을 경우를 대비해서 저희는 파이썬 2.6에 경고 메시지를 추가하기로 결정했습니다. 이런 경고 메시지들은 실제로는 비활성화되어 있기 때문에, 활성화하려면 특별한 명령행 플래그인 -3을 전달해서 스크립트를 호출해야 합니다. 그렇게 하면 경고 메시지들이 출력될 겁니다. 제가 생각하기에 써드 파티 개발자들이 이전 문제를 어떻게 처리할지에 관해서 진지하게 고민해야 할 때쯤에, 저희는 어떻게 동작할 것인가에 관련된 세부사항들을 알아내려고 했고, 적어도 기본값으로 비활성화되어 있는 구체적인 명령행 플래그에 대한 설계를 생각해 냈습니다. 명령행 인자를 활성화하면 경고 메시지가 많이 출력될 겁니다. 구체적인 경고 메시지를 구현하는 일은 임시 방편적인 방법으로 나중에 이루어졌죠.
실제로는 이것에 대한 선례가 있는데, 그건 좀 더 오래된 얘깁니다. 제 기억으로는 제가 개인적으로 정수 나누기에 문제가 있다고 알게 되었을 때인 파이썬 2.2나 2.1 시절이었던 것 같습니다. 저는 정수형에 대해 어떤 나누기 연산자가 사용되고 있고, 나눌 값의 타입이 다른 경우에는 어떤 연산자가 동작할지를 런타임에 알아내는 데 도움될 명령행 플래그들을 추가했습니다. 저는 그런 플래그들이 파이썬 3.0 전까지는 기본적인 가정이 바뀌지 않을 것이므로 여전히 2.6에 있어야 한다고 봅니다.
제 생각에 그 플래그는 –Q 였습니다. 사람들은 기본적으로 파이썬 3.0에 탑재된 명령행 플래그와 동일한 의미를 가져다 주는 새로운 정수 나누기를 활성화할 수도 있는데, 아마 이렇게 한건 대부분의 사람들에게는 좋은 생각이 아니겠지만, 파이썬 인터프리터로 간단한 프로그래밍을 가르치려는 교육 환경에 있는 사람들에게는 아마 그 옵션이 도움될 겁니다. 그게 바로 그 옵션이 존재하는 최소한의 이유입니다. 이 옵션 말고도 실제로 이 옵션의 또 다른 변종으로 이중 슬래시 연산자(//)를 이용해서 표현되지 않은 정수 나누기를 하는 코드에 대해 경고 메시지를 보여 주는 것도 있죠.
그 당시 저는 이러한 모든 경고 메시지와 소스 코드를 입력받아 실제로 소스 코드에서 그 부분을 수정하지 않을 경우 사용자가 소스 코드를 패치할 때 쓸 수 있도록 통합 diff 형식(unified diff-style)의 파일을 만들어 내는 툴을 별도로 만들기도 했습니다.
저는 그런 걸 생각해 본적도 없는데요, 상당히 괜찮은 아이디어네요.
귀도 반 로섬: 사실상 두 세가지 툴은 소스 코드의 해당 라인을 변경하는 대신 일반적인 경우처럼 어떤 부분이 변경될지에 대한 통합 diff 파일을 만들어 내도록 요청할 수 있는 모드를 갖고 있습니다. 만약 그렇게 하고 싶다면 그냥 파일 대 파일로 그런 부분들을 검토해서 “아, 그래. 제대로 되고 있네”라고 할 수도 있죠. 아니면 그런 부분들을 주의깊게 검토하고 나서 사실상 툴이 제대로 처리하고 있지 않는 경우가 있다는 것도 확인할 수 있죠.
그렇게 하면 패치 파일을 받아서 수동으로 변경사항을 되돌려서 생각했던 부분이 적용되도록 패치할 수도 있습니다. 이런 방식으로 툴이 상당한 분량의 일을 처리하는데 도움을 줄 수 있습니다. 이게 바로 파이썬 2.6에서 3.0 세계로 넘어가기 전에 있었던 일입니다.
제가 알기론 내년에 파이썬 3.1이 출시된다고 하던데 제가 제대로 알고 있는 건가요?
귀도 반 로섬: 아마 그럴 겁니다. 사람들은 3.0에는 추가되지 못했던 기능들이 3.1에는 추가되길 잔뜩 기대하고 있습니다. 그런데 어떤 분이 “글쎄, 3.0이 호환되지 않기 때문에 3.1도 마찬가지로 호환되지 않게 하자”라고 말씀하시는 걸 들은 적이 있습니다.
절대로 그렇지는 않을 겁니다. 절대로요. 앞으로 진행하는 과정에서 3.1은 2.6과 2.5가, 또는 2.5가 2.4와 그랬던 것처럼 3.0과 하위 호환성을 유지할 겁니다.
그렇다면 귀도씨의 정책은 주요 출시 버전 군 내에서는 호환성을 유지한다는 얘기군요.
귀도 반 로섬: 바로 그겁니다.
귀도씨는 예측은 하지 않는다고 알고 있는데, 언젠가 파이썬 4도 나올까요? 아니면 향후에 나올 것으로 구상하고 계신건 3인가요?
귀도 반 로섬: 그 질문의 답은 향후 몇 년을 생각하고 계신가에 달려있습니다.
10년이라고 합시다.
귀도 반 로섬: 향후 10년이라면 3으로 남아있을 겁니다. 저는 최소한 5년 동안은 3으로 남아있을거라 예상하고 있습니다. 5년이면 그 사이에 어떤 일이 일어나든, 일어나지 않든 간에 제가 어느정도 확신을 갖고 예상할 수 있는 최대치라고 볼 수 있죠.
5년이면 시간상으로는 꽤 긴 시간이군요.
귀도 반 로섬: 파이썬은 상당하지만 매우 점진적인 성장률을 보여주었습니다. 실제로 이번 주나 다음 주가 엄밀히 말해서 파이썬이 탄생한지 19번째 되는 해입니다. 이제 20살이 다되어 가죠. 제 생각에 5년 후를 내다보는 건 무리라고 생각합니다.
작년이나 재작년에는 사람들이 정말로 많이 파이썬을 알게 되었죠. 저는 그 사실을 웹 프로그래밍 분야에서 알게 되었는데요, 구글의 앱 엔진(App Engine)이나 장고(Django) 같은 프로젝트를 예로 들 수 있겠죠. 이런 것들이 파이썬의 성장에 어느 정도 기여한다고 생각하십니까? 아니면 일부에 국한된 것이라고 생각하십니까?
귀도 반 로섬: 저는 동적 언어가 마침내 주목을 받게 된 거라 생각합니다. 이건 오랜 시간동안 계속해서 이루어져 왔던 일입니다. 제 기억으로 15년 전에 “파이썬을 도입하고 싶은데, 상사가 모르는 언어는 사용하지 말라고 했습니다.”라고 말하시는 분을 만난 적이 있습니다. 5년 전에도 여전히 같은 내용의 메일을 받은 적이 있죠.
이제는 더 이상 그런 광경을 볼 수 없습니다. 사실 저는 앞에서 언급하신 것들이 파이썬의 성장에 기여한다고 생각하며, 동시에 다른 동적 언어, 특히 루비도 그루비처럼 자바 세계에 기여하고 있다고 생각합니다. 동적 언어에 대해서는 이제 사람들도 잘 이해하고 있죠. 동적 언어 자체가 무엇이냐처럼 잘못된 용어를 사용하는 사람들은 그리 많지 않습니다만 얼마간은 사람들이 약한 타입과 강한 타입과 같은 용어처럼 사용할 겁니다. 이렇게 되면 아무래도 동적 언어의 평판이 나빠지고, 루비가 아직까지는 신출내기라도 홍보를 통해 많은 사람들이 동적 언어의 사상에 관해 생각하게 만들어서 루비 말고도 다른 동적 언어, 즉, 루비만이 유일한 동적 언어는 아니다, 펄도 있었고, 또 파이썬도 있었다라는 사실을 깨닫게 될겁니다. 루비는 펄과 파이썬의 영향을 모두 받았습니다. 펄과 파이썬 둘 다 여전히 왕성하게 활동하고 있는 언어죠.
동적 언어의 발상은 순전히 수많은 애플리케이션 영역에 도움을 주기 위한 수단이라는데 있습니다. 앞서 말씀하신 건 아마 동적 언어가 현재 전성기를 맞이하고 있는 웹 애플리케이션의 인기가 높아지고 있는 현상과 맞물려서 그런 것일 수도 있습니다. 그렇지만 왜 동적 언어가 그 정도로 웹 애플리케이션에서 인기있는지는 전적으로 확신할 수 없지만, 아마 다른 이들이 작성한 애플리케이션과 매우 빠르게 통합할 수 있다는 것과 관련이 있을 겁니다.
제가 알고 있기로는 사람들이 그런 생각을 갖게 된게 "93, "94년도에 CGI 붐이 일어났을 때였던 것 같은데요, 그 당시에 펄이 다른 곳엔 몰라도 문자열을 처리하는데는 안성맞춤이었죠. 분명 C는 확실히 아니라는 뜻입니다. 그리고 확실히 귀도씨가 배시 쉘이나 콘 쉘, C 쉘을 사용하려고 했다면 할일이 훨씬 더 많았을 겁니다.
귀도 반 로섬: 흥미로운 점은 꽤 오랫동안 CGI가 동적인 웹 사이트를 만드는데 쓰였다는 겁니다. 웹 사이트의 동적인 부분이라고 해도 특별한 경우가 있었죠. 제 기억으로 제가 틀린 예측을 했던 것 중 하나가 바로 CGI가 처음 나왔을 때, 저는 그게 특별히 흥미롭거나 중요하다고 생각하진 않았다는 겁니다. 제가 처음으로 HTML과 HTTP를 봤을 때, 곧바로 웹 클라이언트를 작성하기 시작해서 하나의 완전한 웹 브라우저를 만들기도 했고, 파이썬으로 두 가지나 만들어 보기도 했던 것 같습니다. 저는 웹을 다루기 위한 클라이언트 라이브러리를 상당히 많이 작성하고 또 웹 서버 코드도 짜봤지만, 실제로 동적인 웹 사이트라는 아이디어가 지금만큼 흥미롭거나 독특해 보일만큼 여겨지지는 않았습니다.
CGI 모듈은 굉장히 오랫동안 낯선 고아처럼 파이썬 표준 라이브러리에 포함되어서 아무도 그 모듈을 사용하는 사람이 없었죠. 물론 지금은 CGI의 시대는 지났죠.
사람들은 모두 각기 다른 접근법을 취합니다. 예를 들어 저는 WSGI(Web Server Gateway Interface) 표준이 파이썬 세계에 나타난 후로 파이썬으로 동적 웹사이트를 만들어 보거나 다뤄 본 사람들은 모두 서비스 인프라와 애플리케이션 인프라를 결합하는데 WSGI 표준을 사용하고 있는 걸 다행이라고 생각합니다.
그건 다른 언어에서도 왜 채택하지 않았을까 하는 궁금증을 일으키는 파이썬에만 들어있는 것 중의 하나죠. WSGI는 굉장히 이해하기 쉽게 되어 있죠.
귀도 반 로섬: 저는 자바 세계에서도 꽤 표준화된 접근법이 있다고 생각합니다.
기본적인 접근법이 없는 언어인 경우에는 전격적으로 WSGI를 채택하는 건 어떨까요?
귀도 반 로섬: 저도 거기에 찬성입니다. 아마 WSGI에는 파이썬에 특화된 세부사항이 포함되어 있겠지만, 제 생각에는 전반적인 아이디어는 펄이나 루비도 쉽게 따라올 수 있다고 봅니다. 아마 루비는 WSGI같은 게 그다지 필요하지 않다고 생각할 수도 있는데, 왜냐하면 루비에는 본래부터 루비 기반의 웹 프레임워크가 있기 때문이죠.
훨씬 더 오래전에 나온 파이썬에도 마찬가지로 또 다른 특성을 지니고 있으면서 오랜 시간동안 사용되어온 웹 프레임워크가 여럿 있습니다. 저는 WSGI가 특히 웹 서비스 프레임워크를 선택하는 것과 애플리케이션 프레임워크를 선택하는 것을 분리하기 위한 바램에서 만들어진 거라고 생각합니다. 예를 들어, 파이썬 세계의 조프(Zope)은 제가 알기로 적어도 10년이 넘었죠. 터보 기어(Turbo Gears)나, 파이론(Pylons), 장고(Django) 같은 것들도 생각나는군요… 처음으로 이걸 만드신 분들이 이것들을 구상하고 만들 때에는 WSGI 식의 접근법이 없었고, 제각기 임시 방편적인 해결책을 담고 있었습니다. 보통 그런 해결책에는 두 가지가 있습니다. 하나는 순수 파이썬으로만 작성된 개발 서버인데, 종종 단일 스레드로 돌아가고 실제로는 애플리케이션을 디버깅 하는 것 이외에는 의미가 없었습니다. 그리고 그것들을, 가령 아파치 서버에다 심는 다소 힘든 방법도 있었습니다. 모든 사람들이 제각기 스스로 그런 일을 하기 위한 세부적인 방법들을 알아내야만 했죠.
특별히 파이썬 세계의 단합을 위한 바람이 있습니까? 만약 가능하다면 다른 언어나 프로젝트에서 본보기로 삼을만한 것말이죠. 그게 파이썬에만 특별히 있는 거라면, 파이썬에는 잘된 일인거죠.
귀도 반 로섬: 제가 생각하기로는 파이썬 세계에서 때때로 일어나는 단합 노력은 실제로는 종종 사용자들이 프레임워크의 컴포넌트에 대한 가이드나 선택권을 충분히 제공받지 못한다고 인식하는 데서 나온다고 봅니다. 특정 부분에 있어서는 자체적인 프레임워크를 만들어 내기 매우 쉽고, 또 종종 프레임워크를 만든 이들이 자기 주장이 강해 다른 프레임워크와 경쟁하는 경우가 있습니다. 특정 프레임워크를 고집하거나 핵심 개발자나 해당 프레임워크의 사용자 그룹에서 중심부를 차지하는 사람들은 자기네 프레임워크를 지극히 선호하는 경향이 있습니다. 외부에서 온 어떤 이들이 "저는 파이썬으로 웹 개발을 하고 싶어요."라고 하면, 이제 누가 그 사람과 친분이 있냐에 따라서 어떤 프레임워크를 사용할지에 대해 전혀 다른 추천을 받게 될거라는 문제가 생깁니다.
만약 그 사람들에게 특별히 자신의 주장을 펼치거나 영향을 주는 사람이 없다면, 그 사람들은 스스로 어떤 프레임워크가 적당한지 알아내려고 할겁니다. 그래서 구글에서 파이썬 웹 프레임워크를 검색해 보고 약 50개 가량의 파이썬 웹 프레임워크가 있다는 사실을 알게 되죠. 그게 언제였는지는 잊어버렸지만, 아마 3~4년 전에 누군가가 다양한 파이썬 웹 프레임워크를 연구해서 좀 더 상세히 알아본 다음 그것들이 얼마나 비슷한지, 또 확실히 월등한 프레임워크가 있는지 걸러내기를 통해 알아내려고 많은 시간을 쏟은 적이 있었습니다. 그런 식으로 걸러내기를 했던 것이 직접적인 효과가 있었는지는 모르겠지만, 제가 보기에는 그 때가 바로 장고와 터보 기어가 나타나기 시작할 때였던 것 같습니다.
그 당시에 매우 인기가 있었거나 적어도 그 당시만이라도 승산이 있어 보였던 그 밖의 많은 프레임워크도 이젠 자취를 감추었습니다. 어떤 것들은 컴포넌트들을 아마 맨 처음부터 만들기 보다는 괜찮은 컴포넌트를 찾아서 통합하는 전략을 취하고 있는 터보 기어로 합쳐지기도 했을 겁니다. 반면, 장고는 조프가 그랬던 것처럼 모든 컴포넌트들을 자체적으로 만들었죠.
조프는 컨텐츠 관리 시스템으로 발전했는데, 전형적인 웹 2.0 개발자가 필요로 하는 것 보다 덩치가 더 커졌습니다. 작년에는 또 다른 컨텐트 관리 시스템을 봤고, 이 경쟁은 여전히 끝나지 않은 상태죠. 그런데 제 생각에는 어느 정도는 침체가 있어도 괜찮은 것 같습니다. 요즘은 사람들이 파이썬을 이용하여 웹 개발을 하려고 하면 너무 대안이 많이 나와있는 것에 관해서는 불평하지 않지만, 모든 이들이 접할 수 있는 종류의 대안들은 극히 일부에 불과하기 때문에 어떤 것을 골라야 할지는 모릅니다.
행복한 고민은 없죠. 다만 전체적으로 풍부해지기만 했을 뿐이죠.
귀도 반 로섬: 바로 그겁니다. 맞아요. 둘 또는 세 가지 주된 대안과 다수의 특화된 대안이 있을 뿐이죠. 저희도 이전에 그런 경험을 한 적이 있습니다. 90년대 후반에 저희는 GUI 프레임워크에서도 비슷한 문제를 겪었습니다. 결국엔 파이썬 세계에서는 실제로 다른 모든 사항들을 다룰만한 GUI 툴킷은 없다고 생각했는데, 그렇게 생각한건 어쩌면 단순히 사람들이 GUI 개발에는 별로 관심이 없고 요즘에는 웹 개발에 좀 더 관심이 있기 때문이죠.
제가 마지막으로 파이썬으로 진행했던 비즈니스 프로젝트가 아마 2002년도였을 겁니다. 저희는 프로젝트에 사용하려고 WxPython을 사용하기로 했죠.
귀도 반 로섬: WxPython은 아직까지도 사용되고 있고 여전히 굉장히 좋은 평가를 받고 있습니다.
저도 매우 즐거운 경험이었습니다. WxPython과 py2exe로 괜찮은 클라이언트 측 GUI 애플리케이션을 만들 수 있었죠. 정말 좋았습니다. 그런데 파이썬을 이용한 GUI나 클라이언트 측 프로그래밍에 비해서 웹에서는 해야 할 일이 더 있다고 하셨는데, 그건 어쩔 수 없는 건가요?
귀도 반 로섬: 실제로 저는 근래에 GUI 개발을 해야 한다거나 하고 싶었던 적이 없었습니다. 적어도 최근 3년 동안엔 전혀 없었죠. 대신 저는 웹 개발은 굉장히 많이 했죠. 일반적으로 사람들은 더 이상 데스크톱 애플리케이션을 그렇게 많이 개발하지는 않는다는 식으로 관점이 많이 바뀌었습니다.
데스크톱에는 브라우저가 있죠. 그 밖에도 맥같은 운영체제에는 아이튠즈나 아이포토와 같이 특화된 애플리케이션이 여럿 있을 것이고, 윈도우도 비슷합니다. 아마 리눅스에도 그런게 있을 겁니다. 그렇지만 그렇게 많지는 않습니다. 만약 어떤 사람이 자그마한 프로젝트를 진행중이고 사용자 인터페이스가 필요하다면 그 프로젝트는 이미 웹 서버를 갖추고 있거나 실질적으로 현황 대시보드나 데이터 입력 도구 등의 역할을 할 수 있는 웹 서버에 같은 곳에 배포하는 것이 가장 적합한 배포 방식일 겁니다. 점점 더 GUI 애플리케이션의 필요성이 줄어들고 있지요. 그런 점에서 당연히 앱 엔진은 전적으로 웹 프로젝트라 볼 수 있습니다. 굳이 하나하나 따지지만 않는다면 전체적으론 웹 프로젝트죠. 구글은 크게 웹 회사지만, 앱 엔진 맥락에서 GUI 업무가 이루어지는 부분은 실제로 론처(launcher) 뿐입니다. 기본적으로 앱 프로젝트에는 그 론처를 만든 분이 한 분 계신데, 론처의 사용자 인터페이스는 꽤 단순합니다. 아직까지도 데스크톱 애플리케이션으로 론처를 만들어야 하는 까닭은 애플리케이션이 반드시 웹에 접근할 필요가 없거나 애플리케이션이 아직 웹 서버에 배포되지 않은 환경에서 개발하려는 것 때문이죠.
제가 듣기로 그놈이나 KDE 같은 프로젝트에서는 "저흰 아직까지 모노라는 것에 확신이 서질 않아서 C 보다 쓰기 쉬운 괜찮은 언어를 알아보고 있는 중이예요."라는 말이 오고가는 것도 들은 적이 있습니다. 그 사람들이 말하길, "파이썬이 꽤 잘맞는 것 같아요. 자바스크립트도요. 루비도 마찬가지고요." 제가 궁금했던 건 사람들이 더 많은 GUI 애플리케이션을 만들도록 하는 것을 하나의 목표로 분명하게 정했었냐는 겁니다.
귀도 반 로섬: 그 질문에 내포된 답은 제 개인적으로는 정말로 예상할 수 없었다라는 겁니다. 아마 파이썬 커뮤니티 안에서도 그런 부분에 관해 활발하게 모색하거나 업무를 하는 분들이 있을 겁니다. 제가 생각하기에 그런 부분들이 파이썬 커뮤니티에서 나올 필요는 없을 정도로 파이썬은 충분히 일반화된 언어라고 생각합니다. 특정 유형의 애플리케이션에 관심이 있는 다른 커뮤니티에서도 다른 언어를 받아들이기로 할 수 있는 것처럼 단순히 파이썬을 도입하기로 결정할 수도 있습니다. 마치 C가 원래는 특정 환경에서 특정한 종류의 애플리케이션을 만드는데 사용할 목적으로 설계되었지만, 지금은 그런 용도를 넘어 사용될 만큼 성장한 것처럼요.
그리고 그런 경우는 파이썬에서는 흔한 일입니다.
그걸 파이썬이 성공한 언어라는 하나의 징표로 볼 수 있겠군요.
귀도 반 로섬: 그런 점이 파이썬을 일반 목적용 프로그래밍 언어로 만들었죠.
귀도씨가 하고 있는 일을 통해 그런 프로젝트를 만든 사람과 초기 개발자들을 놀래켜주기 시작했을 때, 그걸 좋은 징표로 볼 수 있겠네요.
귀도 반 로섬: 물론입니다.
저는 유니코드 처리와 파일 시스템에 관해서 파이썬 3 리스트에 올라온 논의내용을 본적이 있습니다. 그것들은 빨리 고쳐야할 것이었나요, 아니면 단순히 사람들이 최적화가 필요한 부분이라고 생각했던 것이었나요?
귀도 반 로섬: 말씀드리기가 곤란한데, 지금 당장은 아직까지 전 세계의 모든 사람들이 완전히 유니코드를 받아들이지는 않았기 때문에 문제라 볼 수 있습니다. 저는 한 번만이라도 특정한 체계가 폭넓게 받아들여졌으면 합니다. 흥미로운 점은 사람들이 주요 운영체제, 즉 윈도우와 맥 OS X를 둘 다 살펴보면 그 운영체제들이 실제로 유니코드를 다른 방식으로 처리하고 있다는 겁니다. 윈도우 파일 시스템에서는 모든 것이 UTF-16이죠. 맥 파일 시스템에서는 모든 것이 UTF-8입니다. 그리고 정규화에 관한 문제도 있습니다. 이것은 유니코드가 특정 언어에서는 문자를 기록할 때 사용하는 갖가지 방식들이 모호하기 때문인데, 그런데 그것들은 대부분 유니코드죠. 사용자가 자국어의 특정 문자를 담고 있는 파일명을, 사진이나 텍스트 문서 등의 파일에 이름을 주는 것처럼 주게 되면 그것들은 자동적으로 시스템 수준의 표준 파일 시스템과 부호화 방식으로 인코딩될겁니다. 파이썬에는 그와 관련된 어떠한 문제도 없을 겁니다.
그와 같은 사고방식에 반기를 들고 있는 마지막 곳은 실제로 유닉스 세계인데, 여기서는 전통적으로 파일 시스템에서 인코딩에 관한 고려는 하지 않은채로 단순히 문자들을 바이트로 처리합니다. 러시아 사람들은 라틴어 알파벳과 키릴(Cyrillic) 문자를 포함하여 8비트 인코딩을 씁니다. 제가 알기론 터키 사람들도 같은 것을 사용하는데, 단지 두 세개의 특수 문자만 포함되어 있는 터키어 알파벳도 여기에 포함되어 있죠.
재미있는 대문자 사용 규칙을 쓰는군요.
귀도 반 로섬: 네. 일본이나 중국 사람들은 유니코드를 사용할 수 있지만, 그 사람들은 파일명으로 다른, 더 오래되고 널리 사용되는 인코딩을 사용할 수도 있습니다. 리눅스 제공자는 매우 다양하기 때문에 누구도 단호한 태도로 배수진을 치고 "이제부터 파일 시스템 인코딩으로는 UTF-8을 쓰도록 하겠다."라고 선언하는 사람이 없는 것 같습니다.
저는 아마도 지금으로부터 5년 후에는 왠지 어떤 진취적인 사고를 하는 리눅스 제공자가 그런 결정을 하거나 단지 시스템 기본값을 다르게 설정하는 일이 일어나길 기대합니다. 우분투가 그런 제공자일 수도 있죠. 우분투는 전세계적으로도 사용자와 개발자가 많이 분포되어 있습니다.
저는 5년이나 10년 내로 리눅스 시스템에서도 인코딩이 문제가 되지는 않을거라 생각합니다. 그 동안에는 갖가지 철학이 있었습니다. 저는 소수 계층이 단순히 목소리만 큰건지, 아니면 그들이 실제로는 규모가 그렇게 작지는 않는지 확신할 수 없습니다. 이렇게 말하는 사람도 분명 있습니다. "전 제 파일 시스템에서는 비UTF-8 인코딩을 사용할 수 있었으면 좋겠고, 파일명으로는 다른 인코딩을 쓰는 사람들과 같은 컴퓨터상에서 협업하고 싶습니다."라고요. 글쎄요, 파이썬 프로그램에서 그런 부분을 다루기는 쉽지 않을 것 같습니다. 한편으로 그런 부분을 처리하는 파이썬 3.0 프로그램을 작성하는 것은 가능하지요. 모든 파일 시스템 API는 바이트를 받아들여 바이트를 반환하는 버전을 포함하고 있습니다.
이게 정확히 윈도우에서는 어떤 의미를 갖는지는 불분명한데, UTF-16은 바이트로는 그리 달가운 인코딩이 아니기 때문입니다. 반면, UTF-8은 어떤 시스템에서만 고유하게 사용하고 있는 게 아닙니다. 따라서 윈도우에서는 바이트 API를 사용하지 않기를 강력히 권장하는 바입니다. 한편, 맥에서는 바이트 API를 써도 괜찮은데, 맥에서는 다른 시스템에서 생성한 외부 파일 시스템에 마운트하는 매우 드문 경우를 제외하고는 언제나 UTF-8을 받기 때문입니다.
제가 예상하는 바로는 대부분의 사용자들은 UTF-8이 표준이거나 적어도 일단 인코딩을 선정하면 모든 이들이 같은 인코딩을 사용하게 되는 상황에서만 돌아가는 코드를 작성하게 될 겁니다.
파이썬 측보다 사용자 측에서 수정해야할 부분이 더 많다고 보십니까?
귀도 반 로섬: 제 예상으로는, 그리고 확실히 바라고 있지만, 정말로 저는 사용자들이 현명하게 자기가 쓸 파일 시스템을 선택하고, 바라건대 어떻게든 시스템이 모든 사용자가 동일한 인코딩을 쓰는 쪽으로 설정되었으면 합니다. 사용자들이 인코딩을 파악해야 할 일도 없고 인코딩을 처리할 일도 없게 말이죠. 시스템이 윈도우와 맥 OS X에서 하는 것처럼 인코딩을 처리하는 훌륭한 접근법을 갖추면 더할나위 없겠죠.
제가 생각하기에 자신이 사용하는 시스템을 완벽히 장악하길 원하고 실제로 모든 파일명이 동일한 인코딩을 사용하여 인코딩되어 있지는 않은 환경에서 살아가는 사용자들은 소수에 불과하다고 봅니다. 그 사람들이 누군가 보다 유니코드를 쓰기 편하게 되어 있는 환경에서 작성한, 광범위하게 파일 시스템을 검사하거나 조작하는 파이썬 애플리케이션을 다운로드한다면 해당 애플리케이션은 이따금 제대로 동작하지 않을 겁니다. 그렇게 되면 그건 구현 품질의 문제라고 볼 수 있죠. 그 사람들은 코드 작성자에게 버그를 제출할 수도 있으며, 아마도 다른 인코딩도 처리할 수 있도록 프로그램을 수정해야 하는 일이 일어날 수도 있을 겁니다. 또는 사용자들이 모든 파일명에 대해 동일한 인코딩을 사용하기로 마음먹을지도 모릅니다.
제 생각에 애플리케이션 가운데 소수의 부류는 적어도 당분간은 다른 인코딩으로 되어 있는 파일명도 처리하는 것이 중요하다고 봅니다. 만약 어떤 사람이 주된 용도가 파일 시스템을 검사하는 것인 애플리케이션을 작성하고 있다면, 아마 그 사람은 미드나잇 커맨더(Midnight Commander)의 파이썬 버전이나 그와 비슷한 다른 어떤 걸 작성하고 있는 것이며, 어떻게든 이런 사항들을 다루어야 할 겁니다.
파일 시스템을 스니핑(sniff)해서 어떤 인코딩이 지원되는지 알아내는 일은 그리 쉽지 않죠.
귀도 반 로섬: 여기서 전제는 파일 시스템이라고 해서 모든 부분이 같지는 않다는 겁니다. 물론 그 말은 만약 당신 친구가 다른 인코딩으로 파일을 만들었고, 당신이 그 파일의 인코딩이 뭔지 모른다면, 실제로 그 파일명을 읽어오거나 파일명을 입력하기가 곤란할 거라는 뜻입니다. 만약 운이 좋다면 그것들을 표시해주는 툴이 있고 몇몇 인식가능한 문자들이 있으며, 알수 없는 문자들은 사각형이나 물음표로 표시되어 실제로 파일명에 어떤 문자가 들어 있는지는 알지 못해도 그것들을 파일 목록에서 집어낼 수는 있어서, 그 파일에 들어있는 음악을 재생하거나 워드 문서로 여는 등의 작업은 할 수 있을 겁니다.
바라건대 문서에 들어있는 텍스트는 최소한 어떤 인코딩인지를 알 수 있는 방식으로 인코딩되어야 있어야 하는데, 그렇더라도 사용하기에는 다소 불편할 겁니다. 만약 누군가가 키릴 문자가 포함된 파일을 만들었는데, 사람들이 해당 디렉토리로 가서 그런 파일들을 봐달라고 하면 저는 키릴 문자들을 볼 수 있겠지만 여전히 그게 어떤 의미를 담고 있는지는 알지 못합니다. 저한테는 키릴 문자를 보는 것과 그냥 물음표를 보는 것은 큰 차이가 없습니다. 그건 실제로 제가 어떤 툴을 사용하고 있느냐에 달려있지요. 제가 이맥스(Emacs)에서 해당 파일 시스템을 본다면, 그것도 그 파일 시스템을 보는 한 가지 방법입니다. 제가 쉘에서 그걸 본다면 그것 또한 그 파일 시스템을 보는 또다른 방법인 것이죠. 제가 어떤 다른 GUI 툴에서 그 파일 시스템을 본다고 해도 마찬가지로 그 파일 시스템을 보는 또 다른 방법일 뿐입니다.
제가 바라는 것은 결국엔 더 많은 이들이 실제로 유니코드를 이해하는 겁니다. 세상엔 문자와 인코딩된 바이트와의 차이도 이해하지 못하는 사람도 많습니다. 저는 어떻게든 사람들이 좀 더 그런 부분이나 세부사항에 익숙해지거나, 그렇지 않더라도 소프트웨어가 올바르게 처리할 것이기 때문에 세부 사항은 별로 문제가 되지 않길 기대하고 있습니다.
그분들께 도움이 되는 툴을 만들어 주세요.
귀도 반 로섬: 그 부분이 바로 파이썬이 유니코드와 텍스트를 일반화해서 다루는 방식으로 변화하는 이면에 담긴 기본적인 사상입니다.
출시 계획, 즉 파이썬 3.1의 출시 체계를 봤을 때 저는 그런 일정들을 어떻게 그리도 잘 풀어나가시는지가 인상적이었습니다. 프로젝트 관리 관점에서는 어땠습니까? 빠뜨린 부분은 없었나요?
귀도 반 로섬: 저는 사실 일정을 완전히 장악하려고 했었습니다. 제가 생각하기로 처음 제가 3.0의 모든 출시일에 관해 생각하고 있었을 때가 2008년 초였습니다. 그때 저는 베이징에서 강연을 하고 있었죠. 거기서 저는 "내년 올림픽, 즉 2008년 8월에 3.0을 출시할 것으로 예상하고 있습니다."라고 말했습니다. 오랫동안 8월은 실지로 2.6과 3.0 모두에 대한 출시 예정일이었습니다. 출시일이 가까워지면서 저희는 시간에 기반한 출시가 굉장히 좋다는 사실을 알았지만, 일정 수준의 기능 완성도도 갖췄어야 했지요. 저희는 출시할 준비가 되지 않았음을 깨닫게 되었습니다. 한편으로 출시일을 무한정 연기하고 싶지는 않았고 출시 준비가 될때까지 급하게 프로젝트를 진행시키고 싶지도 않았습니다.
저희는 기획한 기능 가운데 실제로 남은 시간에 구현할 수 있는데 아직까지 아직 구현이 안된 것과, 지금 당장은 포기하고 3.1이나 2.7에서도 포함할 기회가 있을 거라 발표하는 것이 나은 것들을 골라내기 시작했습니다. 그러고 나서 출시일이 가까워지자 실제로 2.6이 3.0보다 성숙해졌고, 심지어 3.0 개발에 소요되는 리드 타임이 더 길었습니다. 그 이유는 3.0에서 변경되는 사항들이 진일보한 것이었기 때문이었죠.
결국에 저희는 더 이상 2.6을 붙들고 있어야 할 이유가 없지만, 또 3.0을 출시하는 것도 현명한 처사는 아니라는 걸 알게 되었습니다. 2.6이 최종 출시되기 전에 아주 잠깐, 저희는 2.6과 3.0이 베타버전으로 있을 때 두 버전을 완전히 맞춰서 출시하자는 아이디어를 냈습니다. 2.6의 최종 버전이 출시될 때 같은 날이었던가 같은 주에 3.0의 최종 후보 버전(RC; release candidate)도 출시했습니다. 그러고 나서 몇 번에 걸쳐 논의가 있었습니다. 어떤 이들은 최종 후보 버전이 실제로 최종 후보 버전이라는 이름을 가질 정도는 아니기 때문에 베타로 돌아가자고 말하기도 했습니다. 저희는 그것들을 계속해서 최종 후보 버전으로 부르기로 결정했지만, 다른 출시 버전에서 하면 더 나았을 법한, 이어지는 최종 후보 버전에서 발생하는 다소 규모가 큰 변경사항도 받아들였습니다. 그 시점에서 저희는 12월 초를 3.0의 최종 출시일로 정했습니다. 사람들은 매우 열심히 일했고, 마지막 순간에는 안정성을 유지하고 다른 기능을 추가하지 않는 일을 잘해주어서 결국엔 일정을 지킬 수 있었습니다.
계속해서 시간에 기반한 출시 방법을 활용할 생각이십니까? 1년에 한번씩 새로운 주요 출시 버전이 나오는 방식인가요?
귀도 반 로섬: 저는 순전히 억지로 그렇게 하고 싶지는 않습니다. 저는 꽤 구체적인 날짜를 골라서 개발자 커뮤니티의 모든 이들이 그에 관해 알고, "글쎄, 내가 만든 기능이 다음 출시 때 포함시키려면 그 기능을 좀 더 근사하게 만들고 출시하기 전에 실제로 몇 달을 전념해야 할거야"라는 생각을 할 수 있었으면 좋겠습니다.
그와 동시에 저는 출시를 그냥 임의 날짜로 맞추고 싶지도 않습니다. 그건 우리가 수년동안 겪어온 모든 출시 관리자들의 철학에 가깝습니다. 출시되는 버전은 안정성과 견고함, 완전성 측면이 특히나 높아야 합니다.
이따금 저희는 기능 동결을 해서 최종 출시 후보가 어느정도 형태를 갖추기 전까지는 기능 동결 상태를 유지할 겁니다. 지금까지는 그룹의 일원들을 통해 그런 일을 처리했었는데 항상 잘 처리되었습니다. 저는 핵심 개발 그룹 주변에 계신 많은 분들이 이것을 통해 많이 배운다고 생각합니다. 저희는 사람들이 별로 관심이 없다가 최종 출시 후보가 나오기 바로 직전에 매우 치명적인 버그가 출시되기 전에 해결되어야 한다고 주장하는 경우를 봅니다. 문제가 그렇게 심각하다면, 만약 문제가 진짜 해결해야할 문제라면 그 이슈를 실제로 해결할 조치를 취해야 할겁니다. 많은 경우, 보통 버그 트래커에서 오랫동안 해결되지 않고 남아있는 것들은 재생하기가 매우 어렵거나 애플리케이션 기능이나 API 사용, 또는 환경적인 요인이 매우 기묘하게 조합되는 경우에만 영향을 주기 때문입니다.
종종 저희는 이런 논의도 하곤 합니다. "글쎄, 세 개의 출시 버전이 계속해서 깨지고 있습니다. 단지 문제를 고칠려고 다음 출시일를 연기할 필요는 없습니다". 종종 이런 문제는 한 줄만 바꾼다고 해결되는 문제가 아닌 경우도 있습니다. 더군다나 이런 것들은 API를 리팩터링하거나 간혹 제대로 해결하려면 실제로 API를 호환되지 않는 방식으로 바꿔서 해당 API를 사용하는 기존 코드가 모두 작동하지 않도록 하는 수 밖에 없는 상황에 빠지게 하는 경우도 있는데, 이런건 3.0에서 했던 가장 전형적인 경우이고, 대개 보통의 경우에는 이렇게 하지 않습니다.
말씀하신 건 어쨌건 계획된 출시가 있기 한 주 전에는 하고 싶지는 않은 일이겠군요.
귀도 반 로섬: 확실히 서둘러서 하고 싶은 일은 아니죠.
저는 시간에 기반한 출시 방법을 굉장히 좋아합니다. 일단 몇번에 걸쳐서 그렇게 하고 나면 사람들은 그런 일정에 익숙해져서 바로 지금 출시됐다는 사실을 알게 되죠. 다음 두 주가 해금기(open season)이군요. 그럼 "아, 출시되려면 두 주나 한 달정도 남았군. 문서 패치나 지금 당장 수정해야 할 버그 목록 말고는 아무것도 받아들이지 않겠군."라고 말하게 되죠.
귀도 반 로섬: 그렇게 되면 아직까지 그 집단의 구성원이 아닌 사람들에게는 교육적인 효과가 있을 것 같군요.
혹시 독자들께 하고 싶은 말은 더 없으신지요?
귀도 반 로섬: 저는 이 시점에서 다시 한번 3.0이나 2.6 가운데 어떤 걸 사용할 것이냐는 매우 개인적인 선택이라고 말씀드리고 싶습니다. 이런 점에서 보수적인 입장을 취해서 홀로 남겨질 위험을 감수할 필요는 없습니다. 2.6도 3.0과 마찬가지로 핵심 파이썬 개발자들로 이루어진 그룹에 의해서 지원을 받을 겁니다. 그렇다고 해서 저희가 3.0의 중요성과 품질에 대해 덜 중요하다고 말씀드리는 건 아닙니다. 따라서 아직까지 3.0으로 포팅되지 않은 의존 패키지나 써드 파티 소프트웨어, 또는 다른 이들은 모두 다른 버전을 사용하고 있는 환경에서 일하고 있는 것과 같은 외부적인 요건에 구애받지 않거나, 여러분이 파이썬을 처음으로 배운다면 3.0은 새로운 언어를 배우는 굉장히 좋은 방법입니다. 3.0에는 초심자가 어려워하는 부분들을 많이 없앴습니다.
여러분이 3.0을 배운 다음에는 다른 것을 배우러 가기 보다는 2.6과 3.0간의 차이점을 배우는 것도 매우 쉽습니다. 파이썬 2.6을 배운적이 있다면 아마 책 표지가 2.5으로 나와 있고 2.2나 2.3, 그리고 저자가 갱신한 부분들에 관해 쓰인 책을 사용했을 겁니다. 그런 교재들은 실제로 아직까지도 2.3이나 2.4 버전에서는 비추천된 이디엄(idiom)들을 사용하고 있죠. 여러분이 2.6을 사용하고 있다면 실제로는 대부분 2.3이나 제 생각에 지금보다 약 5년 정도 낡은 것과 호환되는 언어의 한 변종을 사용하고 있는 셈입니다.
반면, 2.6을 사용할 목적으로 3.0을 배운다면 여러 3.0의 기능들은 실제로 2.6으로 백포트되었거나 이미 사용가능한 것들 몇가지는 배우지 않게 됩니다. 그런 것들에는 print문과 print 함수처럼 근본적으로 다른 것들도 몇 가지 있습니다.
실제로 나중에는 2.6에서 print 함수를 임포트할 수도 있을 겁니다. 정말로 사람들은 자신의 요구사항을 살펴봐서 2.6을 쓸지 3.0을 쓸지 결정해야 하며, 3.0이 지원되지 않거나 또는 2.6이 지원되지 않을 거라는 점에 관해 걱정해서는 안됩니다. 저는 5년 안에는 2.6이나 2.X 버전대가 훨씬 더 중요성이 낮아질 거라 생각합니다. 그렇지만 앞으로 3년이나 4년 동안에는 2.X에서 3.0으로의 이전 작업이 굉장히 느리게 진행될 겁니다.
천천히 미래로 나아가시길 바랍니다.
귀도 반 로섬: 네.
저자 : chromatic
역자 : 이대엽
원문 : The Evolution of Python 3
2008년 12월, 파이썬 개발자들은 인기있는 동적 프로그래밍 언어인 파이썬의 새로운 버전인 3.0을 출시하였다. 파이썬의 창시자인 귀도 반 로섬(Guido van Rossum)이 지난 몇 년동안 파이썬 3000(파이썬 3.0으로 이름이 바뀜)의 사상에 관해 논의하는 가운데 파이썬 커뮤니티는 2005년 초반 파이썬 3000의 개발에 착수했다. 귀도는 개발 과정과 이 같은 새로운 출시 버전이 파이썬의 미래에 어떤 의미가 있는지에 관해 논의하는데 선뜻 응해 주었다. (본 인터뷰는 2009년 1월에 진행되었다.)
우선 파이썬 3.0이 출시된 걸 축하드립니다.
귀도 반 로섬: 감사합니다.
나온지 꽤 된걸로 알고 있습니다만, 귀도씨가 보시기에는 개발 과정이 성공적이었습니까?
귀도 반 로섬: 파이썬 커뮤니티 관점에서는 성공적이었기 때문에 적어도 제 관점에서는 그게 성공적이었는지는 크게 중요하지 않습니다. 개발 과정은 재미있었습니다. 실제로 제가 파이썬 3000에 관해 생각하기 시작한 건 2000년부터입니다. 그때부터 저는 실질적으로 파이썬 3000과 관련된 작업, 말하자면 실제로 파이썬 3000을 설계하고 모든 이들과의 합일점을 도출하는 등의 일을 약 3년전에 제가 막 구글에 입사해서 파이썬과 관련된 일을 하는데 시간을 더 쏟을 수 있는 즈음에 시작했죠. 꽤 오랫동안 실제로 저는 프로젝트를 진행시켜 왔고, 많은 이들을 들뜨게 만들었습니다. 유로 파이썬(Euro Python)에서 열린 파이콘(PyCon; 파이썬 컨퍼런스)이나 다른 컨퍼런스에서 매년 강연을 하기도 했습니다. 그리고 지난 12달 동안에는 개발자 커뮤니티에서 파이썬 3000의 최종 세부 사항들을 마무리하고 출시를 준비하는 동안 온전히는 아니지만 상당 부분을 개발 과정에 직접적으로 관여하지는 않고 개발과정을 지켜보며 조율하는 역할을 담당했습니다.
이번에는 개발에서 맡은 역할이 적었습니까?
귀도 반 로섬: 저는 1년 전까지 개발을 한 후에 아마 여러가지 이유로 구글에서 다른 팀으로 배치받기도 했으며, 다소 덜 적극적인 역할을 담당했습니다. 저는 매주 2~3일 정도를 코딩이나 설계, 검토를 하면서 보내진 않았죠. 저는 계속해서 이메일을 확인했지만 제가 개발에 관여하는 일을 줄이고 대신 코어 파이썬 개발 그룹에 계신 분들이 스스로 대부분의 일을 처리하도록 했습니다. 제가 생각하기에 그분들께서는 굉장히 일을 잘하시더군요.
파이썬 2.6과 파이썬 3의 개발 그룹은 어느 정도로 비슷한가요?
귀도 반 로섬: 거의 같은 팀이라고 보시면 됩니다. 그렇기 때문에 어느 정도 비슷하게 출시할 수 있었죠. 저희가 실제로 3년 전에 3.0의 아이디어를 내기 시작했을 때 처음 1년은 주로 상당한 양의 PEP(Python Enhancement Proposal)를 작성하고 잠재적인 변경 사항에 관해 논의하느라 개발이 어떻게 진행되어야 할 지에 관해서는 거의 생각할 수가 없었죠.
차차 작업을 시작했을 때, 그러니까 배리(Barry, 아이디: Warsaw)가 출시 관리자를 하기로 했을 때, 저희는 2.6과 3.0의 출시 버전이 실제로는 다양한 방식으로 서로 연관되어 있었기 때문에 2.6과 3.0을 맞춰서 출시하는게 꽤 괜찮은 생각이라 생각했습니다.
두 출시 버전이 연관되어 있는 부분 중에서 가장 중요한 부분은 아마 2.6이 상당수의 3.0 기능에 대한 백포트(backport) 를 가지고 있는 것이었을 겁니다. 백포트하기가 힘든 경우에는 이전 2.X 버전과는 호환되어야 하지만 3.0에서는 동작하지 않을 것이므로, 2.6에서는 여전히 동작한다는 경고를 보여주게 됩니다.
그 아이디어는 누가 낸거죠? 다시 생각해 보니 당연한 것처럼 들리긴 하지만 좋은 아이디인 것 같군요.
귀도 반 로섬: 솔직히 기억나진 않습니다. 이건 저희도 오랫동안 가지고 있었던 아이디어입니다. 약 2년 전 파이썬 컨퍼런스에서 나왔던 것 같은데, 제가 알기로 2년이 채 되기 전에 사람들이 파이썬 3000에 관해 진지하게 생각하고 있을 때 새로운 버전이 출시될 것이고 기존 버전과 호환되지 않기 때문에 수많은 기존 써드 파티 파이썬 프로젝트에 영향을 줄거라고 생각했을 때였던 것 같습니다.
제 기억으로는 Twisted 개발자 그룹과 “다 좋은데”라고 했던 몇몇 PSF(파이썬 소프트웨어 재단; Python Software Foundation) 게시판 회원들이 만들어 놓은 일종의 복병이었던 것 같습니다. 그분들은 제가 파이썬 3.0에서 바뀌는 부분과 바뀌지 않는 부분에 대해서 그때까지도 윤곽만을 잡고 있었을 때 했던 키노트만 들었을 뿐이죠. 그분들은 저한테 이렇게 말씀하시더군요. “말씀하신 내용을 들어보니 다 괜찮고, 저희도 파이썬이 그런 방향으로 발전했으면 좋겠습니다. 헌데 다른 프로젝트에서 그런 변화를 어떻게 처리할 지에 대해서도 생각해 보셔야 할 것 같군요.”
언제나 새 버전의 배포판에 하위 호환성(backward compatibility)과 관련된 항목이 있는 경우에는 새 버전으로 옮겨가는 것이 예전에 했던 것만큼이나 쉽지는 않을 겁니다. 버전 이전(transition) 전략과 관련된 다양한 부분에 관해 생각해 내는 것처럼 여러 차례에 걸쳐 브레인스토밍 회의를 한다고 해도 그럴 가능성은 충분히 있죠. 이 부분에 대해서 연구해 보신적이 있는지는 잘 모르지만, 2에서 3으로 소스 대 소스로 이행하는 툴도 있는데 이건 파이썬이 동적 언어(dynamic language)라서 실제로 변수가 어떤 타입인지에 대해서 지능적으로 알아낼 필요까지는 없다는 점 때문에 가능하죠.
한편으로 툴이 개발자를 돕지 못하거나 도와주기에 충분하지 않을 경우를 대비해서 저희는 파이썬 2.6에 경고 메시지를 추가하기로 결정했습니다. 이런 경고 메시지들은 실제로는 비활성화되어 있기 때문에, 활성화하려면 특별한 명령행 플래그인 -3을 전달해서 스크립트를 호출해야 합니다. 그렇게 하면 경고 메시지들이 출력될 겁니다. 제가 생각하기에 써드 파티 개발자들이 이전 문제를 어떻게 처리할지에 관해서 진지하게 고민해야 할 때쯤에, 저희는 어떻게 동작할 것인가에 관련된 세부사항들을 알아내려고 했고, 적어도 기본값으로 비활성화되어 있는 구체적인 명령행 플래그에 대한 설계를 생각해 냈습니다. 명령행 인자를 활성화하면 경고 메시지가 많이 출력될 겁니다. 구체적인 경고 메시지를 구현하는 일은 임시 방편적인 방법으로 나중에 이루어졌죠.
실제로는 이것에 대한 선례가 있는데, 그건 좀 더 오래된 얘깁니다. 제 기억으로는 제가 개인적으로 정수 나누기에 문제가 있다고 알게 되었을 때인 파이썬 2.2나 2.1 시절이었던 것 같습니다. 저는 정수형에 대해 어떤 나누기 연산자가 사용되고 있고, 나눌 값의 타입이 다른 경우에는 어떤 연산자가 동작할지를 런타임에 알아내는 데 도움될 명령행 플래그들을 추가했습니다. 저는 그런 플래그들이 파이썬 3.0 전까지는 기본적인 가정이 바뀌지 않을 것이므로 여전히 2.6에 있어야 한다고 봅니다.
제 생각에 그 플래그는 –Q 였습니다. 사람들은 기본적으로 파이썬 3.0에 탑재된 명령행 플래그와 동일한 의미를 가져다 주는 새로운 정수 나누기를 활성화할 수도 있는데, 아마 이렇게 한건 대부분의 사람들에게는 좋은 생각이 아니겠지만, 파이썬 인터프리터로 간단한 프로그래밍을 가르치려는 교육 환경에 있는 사람들에게는 아마 그 옵션이 도움될 겁니다. 그게 바로 그 옵션이 존재하는 최소한의 이유입니다. 이 옵션 말고도 실제로 이 옵션의 또 다른 변종으로 이중 슬래시 연산자(//)를 이용해서 표현되지 않은 정수 나누기를 하는 코드에 대해 경고 메시지를 보여 주는 것도 있죠.
그 당시 저는 이러한 모든 경고 메시지와 소스 코드를 입력받아 실제로 소스 코드에서 그 부분을 수정하지 않을 경우 사용자가 소스 코드를 패치할 때 쓸 수 있도록 통합 diff 형식(unified diff-style)의 파일을 만들어 내는 툴을 별도로 만들기도 했습니다.
저는 그런 걸 생각해 본적도 없는데요, 상당히 괜찮은 아이디어네요.
귀도 반 로섬: 사실상 두 세가지 툴은 소스 코드의 해당 라인을 변경하는 대신 일반적인 경우처럼 어떤 부분이 변경될지에 대한 통합 diff 파일을 만들어 내도록 요청할 수 있는 모드를 갖고 있습니다. 만약 그렇게 하고 싶다면 그냥 파일 대 파일로 그런 부분들을 검토해서 “아, 그래. 제대로 되고 있네”라고 할 수도 있죠. 아니면 그런 부분들을 주의깊게 검토하고 나서 사실상 툴이 제대로 처리하고 있지 않는 경우가 있다는 것도 확인할 수 있죠.
그렇게 하면 패치 파일을 받아서 수동으로 변경사항을 되돌려서 생각했던 부분이 적용되도록 패치할 수도 있습니다. 이런 방식으로 툴이 상당한 분량의 일을 처리하는데 도움을 줄 수 있습니다. 이게 바로 파이썬 2.6에서 3.0 세계로 넘어가기 전에 있었던 일입니다.
제가 알기론 내년에 파이썬 3.1이 출시된다고 하던데 제가 제대로 알고 있는 건가요?
귀도 반 로섬: 아마 그럴 겁니다. 사람들은 3.0에는 추가되지 못했던 기능들이 3.1에는 추가되길 잔뜩 기대하고 있습니다. 그런데 어떤 분이 “글쎄, 3.0이 호환되지 않기 때문에 3.1도 마찬가지로 호환되지 않게 하자”라고 말씀하시는 걸 들은 적이 있습니다.
절대로 그렇지는 않을 겁니다. 절대로요. 앞으로 진행하는 과정에서 3.1은 2.6과 2.5가, 또는 2.5가 2.4와 그랬던 것처럼 3.0과 하위 호환성을 유지할 겁니다.
그렇다면 귀도씨의 정책은 주요 출시 버전 군 내에서는 호환성을 유지한다는 얘기군요.
귀도 반 로섬: 바로 그겁니다.
귀도씨는 예측은 하지 않는다고 알고 있는데, 언젠가 파이썬 4도 나올까요? 아니면 향후에 나올 것으로 구상하고 계신건 3인가요?
귀도 반 로섬: 그 질문의 답은 향후 몇 년을 생각하고 계신가에 달려있습니다.
10년이라고 합시다.
귀도 반 로섬: 향후 10년이라면 3으로 남아있을 겁니다. 저는 최소한 5년 동안은 3으로 남아있을거라 예상하고 있습니다. 5년이면 그 사이에 어떤 일이 일어나든, 일어나지 않든 간에 제가 어느정도 확신을 갖고 예상할 수 있는 최대치라고 볼 수 있죠.
5년이면 시간상으로는 꽤 긴 시간이군요.
귀도 반 로섬: 파이썬은 상당하지만 매우 점진적인 성장률을 보여주었습니다. 실제로 이번 주나 다음 주가 엄밀히 말해서 파이썬이 탄생한지 19번째 되는 해입니다. 이제 20살이 다되어 가죠. 제 생각에 5년 후를 내다보는 건 무리라고 생각합니다.
작년이나 재작년에는 사람들이 정말로 많이 파이썬을 알게 되었죠. 저는 그 사실을 웹 프로그래밍 분야에서 알게 되었는데요, 구글의 앱 엔진(App Engine)이나 장고(Django) 같은 프로젝트를 예로 들 수 있겠죠. 이런 것들이 파이썬의 성장에 어느 정도 기여한다고 생각하십니까? 아니면 일부에 국한된 것이라고 생각하십니까?
귀도 반 로섬: 저는 동적 언어가 마침내 주목을 받게 된 거라 생각합니다. 이건 오랜 시간동안 계속해서 이루어져 왔던 일입니다. 제 기억으로 15년 전에 “파이썬을 도입하고 싶은데, 상사가 모르는 언어는 사용하지 말라고 했습니다.”라고 말하시는 분을 만난 적이 있습니다. 5년 전에도 여전히 같은 내용의 메일을 받은 적이 있죠.
이제는 더 이상 그런 광경을 볼 수 없습니다. 사실 저는 앞에서 언급하신 것들이 파이썬의 성장에 기여한다고 생각하며, 동시에 다른 동적 언어, 특히 루비도 그루비처럼 자바 세계에 기여하고 있다고 생각합니다. 동적 언어에 대해서는 이제 사람들도 잘 이해하고 있죠. 동적 언어 자체가 무엇이냐처럼 잘못된 용어를 사용하는 사람들은 그리 많지 않습니다만 얼마간은 사람들이 약한 타입과 강한 타입과 같은 용어처럼 사용할 겁니다. 이렇게 되면 아무래도 동적 언어의 평판이 나빠지고, 루비가 아직까지는 신출내기라도 홍보를 통해 많은 사람들이 동적 언어의 사상에 관해 생각하게 만들어서 루비 말고도 다른 동적 언어, 즉, 루비만이 유일한 동적 언어는 아니다, 펄도 있었고, 또 파이썬도 있었다라는 사실을 깨닫게 될겁니다. 루비는 펄과 파이썬의 영향을 모두 받았습니다. 펄과 파이썬 둘 다 여전히 왕성하게 활동하고 있는 언어죠.
동적 언어의 발상은 순전히 수많은 애플리케이션 영역에 도움을 주기 위한 수단이라는데 있습니다. 앞서 말씀하신 건 아마 동적 언어가 현재 전성기를 맞이하고 있는 웹 애플리케이션의 인기가 높아지고 있는 현상과 맞물려서 그런 것일 수도 있습니다. 그렇지만 왜 동적 언어가 그 정도로 웹 애플리케이션에서 인기있는지는 전적으로 확신할 수 없지만, 아마 다른 이들이 작성한 애플리케이션과 매우 빠르게 통합할 수 있다는 것과 관련이 있을 겁니다.
제가 알고 있기로는 사람들이 그런 생각을 갖게 된게 "93, "94년도에 CGI 붐이 일어났을 때였던 것 같은데요, 그 당시에 펄이 다른 곳엔 몰라도 문자열을 처리하는데는 안성맞춤이었죠. 분명 C는 확실히 아니라는 뜻입니다. 그리고 확실히 귀도씨가 배시 쉘이나 콘 쉘, C 쉘을 사용하려고 했다면 할일이 훨씬 더 많았을 겁니다.
귀도 반 로섬: 흥미로운 점은 꽤 오랫동안 CGI가 동적인 웹 사이트를 만드는데 쓰였다는 겁니다. 웹 사이트의 동적인 부분이라고 해도 특별한 경우가 있었죠. 제 기억으로 제가 틀린 예측을 했던 것 중 하나가 바로 CGI가 처음 나왔을 때, 저는 그게 특별히 흥미롭거나 중요하다고 생각하진 않았다는 겁니다. 제가 처음으로 HTML과 HTTP를 봤을 때, 곧바로 웹 클라이언트를 작성하기 시작해서 하나의 완전한 웹 브라우저를 만들기도 했고, 파이썬으로 두 가지나 만들어 보기도 했던 것 같습니다. 저는 웹을 다루기 위한 클라이언트 라이브러리를 상당히 많이 작성하고 또 웹 서버 코드도 짜봤지만, 실제로 동적인 웹 사이트라는 아이디어가 지금만큼 흥미롭거나 독특해 보일만큼 여겨지지는 않았습니다.
CGI 모듈은 굉장히 오랫동안 낯선 고아처럼 파이썬 표준 라이브러리에 포함되어서 아무도 그 모듈을 사용하는 사람이 없었죠. 물론 지금은 CGI의 시대는 지났죠.
사람들은 모두 각기 다른 접근법을 취합니다. 예를 들어 저는 WSGI(Web Server Gateway Interface) 표준이 파이썬 세계에 나타난 후로 파이썬으로 동적 웹사이트를 만들어 보거나 다뤄 본 사람들은 모두 서비스 인프라와 애플리케이션 인프라를 결합하는데 WSGI 표준을 사용하고 있는 걸 다행이라고 생각합니다.
그건 다른 언어에서도 왜 채택하지 않았을까 하는 궁금증을 일으키는 파이썬에만 들어있는 것 중의 하나죠. WSGI는 굉장히 이해하기 쉽게 되어 있죠.
귀도 반 로섬: 저는 자바 세계에서도 꽤 표준화된 접근법이 있다고 생각합니다.
기본적인 접근법이 없는 언어인 경우에는 전격적으로 WSGI를 채택하는 건 어떨까요?
귀도 반 로섬: 저도 거기에 찬성입니다. 아마 WSGI에는 파이썬에 특화된 세부사항이 포함되어 있겠지만, 제 생각에는 전반적인 아이디어는 펄이나 루비도 쉽게 따라올 수 있다고 봅니다. 아마 루비는 WSGI같은 게 그다지 필요하지 않다고 생각할 수도 있는데, 왜냐하면 루비에는 본래부터 루비 기반의 웹 프레임워크가 있기 때문이죠.
훨씬 더 오래전에 나온 파이썬에도 마찬가지로 또 다른 특성을 지니고 있으면서 오랜 시간동안 사용되어온 웹 프레임워크가 여럿 있습니다. 저는 WSGI가 특히 웹 서비스 프레임워크를 선택하는 것과 애플리케이션 프레임워크를 선택하는 것을 분리하기 위한 바램에서 만들어진 거라고 생각합니다. 예를 들어, 파이썬 세계의 조프(Zope)은 제가 알기로 적어도 10년이 넘었죠. 터보 기어(Turbo Gears)나, 파이론(Pylons), 장고(Django) 같은 것들도 생각나는군요… 처음으로 이걸 만드신 분들이 이것들을 구상하고 만들 때에는 WSGI 식의 접근법이 없었고, 제각기 임시 방편적인 해결책을 담고 있었습니다. 보통 그런 해결책에는 두 가지가 있습니다. 하나는 순수 파이썬으로만 작성된 개발 서버인데, 종종 단일 스레드로 돌아가고 실제로는 애플리케이션을 디버깅 하는 것 이외에는 의미가 없었습니다. 그리고 그것들을, 가령 아파치 서버에다 심는 다소 힘든 방법도 있었습니다. 모든 사람들이 제각기 스스로 그런 일을 하기 위한 세부적인 방법들을 알아내야만 했죠.
특별히 파이썬 세계의 단합을 위한 바람이 있습니까? 만약 가능하다면 다른 언어나 프로젝트에서 본보기로 삼을만한 것말이죠. 그게 파이썬에만 특별히 있는 거라면, 파이썬에는 잘된 일인거죠.
귀도 반 로섬: 제가 생각하기로는 파이썬 세계에서 때때로 일어나는 단합 노력은 실제로는 종종 사용자들이 프레임워크의 컴포넌트에 대한 가이드나 선택권을 충분히 제공받지 못한다고 인식하는 데서 나온다고 봅니다. 특정 부분에 있어서는 자체적인 프레임워크를 만들어 내기 매우 쉽고, 또 종종 프레임워크를 만든 이들이 자기 주장이 강해 다른 프레임워크와 경쟁하는 경우가 있습니다. 특정 프레임워크를 고집하거나 핵심 개발자나 해당 프레임워크의 사용자 그룹에서 중심부를 차지하는 사람들은 자기네 프레임워크를 지극히 선호하는 경향이 있습니다. 외부에서 온 어떤 이들이 "저는 파이썬으로 웹 개발을 하고 싶어요."라고 하면, 이제 누가 그 사람과 친분이 있냐에 따라서 어떤 프레임워크를 사용할지에 대해 전혀 다른 추천을 받게 될거라는 문제가 생깁니다.
만약 그 사람들에게 특별히 자신의 주장을 펼치거나 영향을 주는 사람이 없다면, 그 사람들은 스스로 어떤 프레임워크가 적당한지 알아내려고 할겁니다. 그래서 구글에서 파이썬 웹 프레임워크를 검색해 보고 약 50개 가량의 파이썬 웹 프레임워크가 있다는 사실을 알게 되죠. 그게 언제였는지는 잊어버렸지만, 아마 3~4년 전에 누군가가 다양한 파이썬 웹 프레임워크를 연구해서 좀 더 상세히 알아본 다음 그것들이 얼마나 비슷한지, 또 확실히 월등한 프레임워크가 있는지 걸러내기를 통해 알아내려고 많은 시간을 쏟은 적이 있었습니다. 그런 식으로 걸러내기를 했던 것이 직접적인 효과가 있었는지는 모르겠지만, 제가 보기에는 그 때가 바로 장고와 터보 기어가 나타나기 시작할 때였던 것 같습니다.
그 당시에 매우 인기가 있었거나 적어도 그 당시만이라도 승산이 있어 보였던 그 밖의 많은 프레임워크도 이젠 자취를 감추었습니다. 어떤 것들은 컴포넌트들을 아마 맨 처음부터 만들기 보다는 괜찮은 컴포넌트를 찾아서 통합하는 전략을 취하고 있는 터보 기어로 합쳐지기도 했을 겁니다. 반면, 장고는 조프가 그랬던 것처럼 모든 컴포넌트들을 자체적으로 만들었죠.
조프는 컨텐츠 관리 시스템으로 발전했는데, 전형적인 웹 2.0 개발자가 필요로 하는 것 보다 덩치가 더 커졌습니다. 작년에는 또 다른 컨텐트 관리 시스템을 봤고, 이 경쟁은 여전히 끝나지 않은 상태죠. 그런데 제 생각에는 어느 정도는 침체가 있어도 괜찮은 것 같습니다. 요즘은 사람들이 파이썬을 이용하여 웹 개발을 하려고 하면 너무 대안이 많이 나와있는 것에 관해서는 불평하지 않지만, 모든 이들이 접할 수 있는 종류의 대안들은 극히 일부에 불과하기 때문에 어떤 것을 골라야 할지는 모릅니다.
행복한 고민은 없죠. 다만 전체적으로 풍부해지기만 했을 뿐이죠.
귀도 반 로섬: 바로 그겁니다. 맞아요. 둘 또는 세 가지 주된 대안과 다수의 특화된 대안이 있을 뿐이죠. 저희도 이전에 그런 경험을 한 적이 있습니다. 90년대 후반에 저희는 GUI 프레임워크에서도 비슷한 문제를 겪었습니다. 결국엔 파이썬 세계에서는 실제로 다른 모든 사항들을 다룰만한 GUI 툴킷은 없다고 생각했는데, 그렇게 생각한건 어쩌면 단순히 사람들이 GUI 개발에는 별로 관심이 없고 요즘에는 웹 개발에 좀 더 관심이 있기 때문이죠.
제가 마지막으로 파이썬으로 진행했던 비즈니스 프로젝트가 아마 2002년도였을 겁니다. 저희는 프로젝트에 사용하려고 WxPython을 사용하기로 했죠.
귀도 반 로섬: WxPython은 아직까지도 사용되고 있고 여전히 굉장히 좋은 평가를 받고 있습니다.
저도 매우 즐거운 경험이었습니다. WxPython과 py2exe로 괜찮은 클라이언트 측 GUI 애플리케이션을 만들 수 있었죠. 정말 좋았습니다. 그런데 파이썬을 이용한 GUI나 클라이언트 측 프로그래밍에 비해서 웹에서는 해야 할 일이 더 있다고 하셨는데, 그건 어쩔 수 없는 건가요?
귀도 반 로섬: 실제로 저는 근래에 GUI 개발을 해야 한다거나 하고 싶었던 적이 없었습니다. 적어도 최근 3년 동안엔 전혀 없었죠. 대신 저는 웹 개발은 굉장히 많이 했죠. 일반적으로 사람들은 더 이상 데스크톱 애플리케이션을 그렇게 많이 개발하지는 않는다는 식으로 관점이 많이 바뀌었습니다.
데스크톱에는 브라우저가 있죠. 그 밖에도 맥같은 운영체제에는 아이튠즈나 아이포토와 같이 특화된 애플리케이션이 여럿 있을 것이고, 윈도우도 비슷합니다. 아마 리눅스에도 그런게 있을 겁니다. 그렇지만 그렇게 많지는 않습니다. 만약 어떤 사람이 자그마한 프로젝트를 진행중이고 사용자 인터페이스가 필요하다면 그 프로젝트는 이미 웹 서버를 갖추고 있거나 실질적으로 현황 대시보드나 데이터 입력 도구 등의 역할을 할 수 있는 웹 서버에 같은 곳에 배포하는 것이 가장 적합한 배포 방식일 겁니다. 점점 더 GUI 애플리케이션의 필요성이 줄어들고 있지요. 그런 점에서 당연히 앱 엔진은 전적으로 웹 프로젝트라 볼 수 있습니다. 굳이 하나하나 따지지만 않는다면 전체적으론 웹 프로젝트죠. 구글은 크게 웹 회사지만, 앱 엔진 맥락에서 GUI 업무가 이루어지는 부분은 실제로 론처(launcher) 뿐입니다. 기본적으로 앱 프로젝트에는 그 론처를 만든 분이 한 분 계신데, 론처의 사용자 인터페이스는 꽤 단순합니다. 아직까지도 데스크톱 애플리케이션으로 론처를 만들어야 하는 까닭은 애플리케이션이 반드시 웹에 접근할 필요가 없거나 애플리케이션이 아직 웹 서버에 배포되지 않은 환경에서 개발하려는 것 때문이죠.
제가 듣기로 그놈이나 KDE 같은 프로젝트에서는 "저흰 아직까지 모노라는 것에 확신이 서질 않아서 C 보다 쓰기 쉬운 괜찮은 언어를 알아보고 있는 중이예요."라는 말이 오고가는 것도 들은 적이 있습니다. 그 사람들이 말하길, "파이썬이 꽤 잘맞는 것 같아요. 자바스크립트도요. 루비도 마찬가지고요." 제가 궁금했던 건 사람들이 더 많은 GUI 애플리케이션을 만들도록 하는 것을 하나의 목표로 분명하게 정했었냐는 겁니다.
귀도 반 로섬: 그 질문에 내포된 답은 제 개인적으로는 정말로 예상할 수 없었다라는 겁니다. 아마 파이썬 커뮤니티 안에서도 그런 부분에 관해 활발하게 모색하거나 업무를 하는 분들이 있을 겁니다. 제가 생각하기에 그런 부분들이 파이썬 커뮤니티에서 나올 필요는 없을 정도로 파이썬은 충분히 일반화된 언어라고 생각합니다. 특정 유형의 애플리케이션에 관심이 있는 다른 커뮤니티에서도 다른 언어를 받아들이기로 할 수 있는 것처럼 단순히 파이썬을 도입하기로 결정할 수도 있습니다. 마치 C가 원래는 특정 환경에서 특정한 종류의 애플리케이션을 만드는데 사용할 목적으로 설계되었지만, 지금은 그런 용도를 넘어 사용될 만큼 성장한 것처럼요.
그리고 그런 경우는 파이썬에서는 흔한 일입니다.
그걸 파이썬이 성공한 언어라는 하나의 징표로 볼 수 있겠군요.
귀도 반 로섬: 그런 점이 파이썬을 일반 목적용 프로그래밍 언어로 만들었죠.
귀도씨가 하고 있는 일을 통해 그런 프로젝트를 만든 사람과 초기 개발자들을 놀래켜주기 시작했을 때, 그걸 좋은 징표로 볼 수 있겠네요.
귀도 반 로섬: 물론입니다.
저는 유니코드 처리와 파일 시스템에 관해서 파이썬 3 리스트에 올라온 논의내용을 본적이 있습니다. 그것들은 빨리 고쳐야할 것이었나요, 아니면 단순히 사람들이 최적화가 필요한 부분이라고 생각했던 것이었나요?
귀도 반 로섬: 말씀드리기가 곤란한데, 지금 당장은 아직까지 전 세계의 모든 사람들이 완전히 유니코드를 받아들이지는 않았기 때문에 문제라 볼 수 있습니다. 저는 한 번만이라도 특정한 체계가 폭넓게 받아들여졌으면 합니다. 흥미로운 점은 사람들이 주요 운영체제, 즉 윈도우와 맥 OS X를 둘 다 살펴보면 그 운영체제들이 실제로 유니코드를 다른 방식으로 처리하고 있다는 겁니다. 윈도우 파일 시스템에서는 모든 것이 UTF-16이죠. 맥 파일 시스템에서는 모든 것이 UTF-8입니다. 그리고 정규화에 관한 문제도 있습니다. 이것은 유니코드가 특정 언어에서는 문자를 기록할 때 사용하는 갖가지 방식들이 모호하기 때문인데, 그런데 그것들은 대부분 유니코드죠. 사용자가 자국어의 특정 문자를 담고 있는 파일명을, 사진이나 텍스트 문서 등의 파일에 이름을 주는 것처럼 주게 되면 그것들은 자동적으로 시스템 수준의 표준 파일 시스템과 부호화 방식으로 인코딩될겁니다. 파이썬에는 그와 관련된 어떠한 문제도 없을 겁니다.
그와 같은 사고방식에 반기를 들고 있는 마지막 곳은 실제로 유닉스 세계인데, 여기서는 전통적으로 파일 시스템에서 인코딩에 관한 고려는 하지 않은채로 단순히 문자들을 바이트로 처리합니다. 러시아 사람들은 라틴어 알파벳과 키릴(Cyrillic) 문자를 포함하여 8비트 인코딩을 씁니다. 제가 알기론 터키 사람들도 같은 것을 사용하는데, 단지 두 세개의 특수 문자만 포함되어 있는 터키어 알파벳도 여기에 포함되어 있죠.
재미있는 대문자 사용 규칙을 쓰는군요.
귀도 반 로섬: 네. 일본이나 중국 사람들은 유니코드를 사용할 수 있지만, 그 사람들은 파일명으로 다른, 더 오래되고 널리 사용되는 인코딩을 사용할 수도 있습니다. 리눅스 제공자는 매우 다양하기 때문에 누구도 단호한 태도로 배수진을 치고 "이제부터 파일 시스템 인코딩으로는 UTF-8을 쓰도록 하겠다."라고 선언하는 사람이 없는 것 같습니다.
저는 아마도 지금으로부터 5년 후에는 왠지 어떤 진취적인 사고를 하는 리눅스 제공자가 그런 결정을 하거나 단지 시스템 기본값을 다르게 설정하는 일이 일어나길 기대합니다. 우분투가 그런 제공자일 수도 있죠. 우분투는 전세계적으로도 사용자와 개발자가 많이 분포되어 있습니다.
저는 5년이나 10년 내로 리눅스 시스템에서도 인코딩이 문제가 되지는 않을거라 생각합니다. 그 동안에는 갖가지 철학이 있었습니다. 저는 소수 계층이 단순히 목소리만 큰건지, 아니면 그들이 실제로는 규모가 그렇게 작지는 않는지 확신할 수 없습니다. 이렇게 말하는 사람도 분명 있습니다. "전 제 파일 시스템에서는 비UTF-8 인코딩을 사용할 수 있었으면 좋겠고, 파일명으로는 다른 인코딩을 쓰는 사람들과 같은 컴퓨터상에서 협업하고 싶습니다."라고요. 글쎄요, 파이썬 프로그램에서 그런 부분을 다루기는 쉽지 않을 것 같습니다. 한편으로 그런 부분을 처리하는 파이썬 3.0 프로그램을 작성하는 것은 가능하지요. 모든 파일 시스템 API는 바이트를 받아들여 바이트를 반환하는 버전을 포함하고 있습니다.
이게 정확히 윈도우에서는 어떤 의미를 갖는지는 불분명한데, UTF-16은 바이트로는 그리 달가운 인코딩이 아니기 때문입니다. 반면, UTF-8은 어떤 시스템에서만 고유하게 사용하고 있는 게 아닙니다. 따라서 윈도우에서는 바이트 API를 사용하지 않기를 강력히 권장하는 바입니다. 한편, 맥에서는 바이트 API를 써도 괜찮은데, 맥에서는 다른 시스템에서 생성한 외부 파일 시스템에 마운트하는 매우 드문 경우를 제외하고는 언제나 UTF-8을 받기 때문입니다.
제가 예상하는 바로는 대부분의 사용자들은 UTF-8이 표준이거나 적어도 일단 인코딩을 선정하면 모든 이들이 같은 인코딩을 사용하게 되는 상황에서만 돌아가는 코드를 작성하게 될 겁니다.
파이썬 측보다 사용자 측에서 수정해야할 부분이 더 많다고 보십니까?
귀도 반 로섬: 제 예상으로는, 그리고 확실히 바라고 있지만, 정말로 저는 사용자들이 현명하게 자기가 쓸 파일 시스템을 선택하고, 바라건대 어떻게든 시스템이 모든 사용자가 동일한 인코딩을 쓰는 쪽으로 설정되었으면 합니다. 사용자들이 인코딩을 파악해야 할 일도 없고 인코딩을 처리할 일도 없게 말이죠. 시스템이 윈도우와 맥 OS X에서 하는 것처럼 인코딩을 처리하는 훌륭한 접근법을 갖추면 더할나위 없겠죠.
제가 생각하기에 자신이 사용하는 시스템을 완벽히 장악하길 원하고 실제로 모든 파일명이 동일한 인코딩을 사용하여 인코딩되어 있지는 않은 환경에서 살아가는 사용자들은 소수에 불과하다고 봅니다. 그 사람들이 누군가 보다 유니코드를 쓰기 편하게 되어 있는 환경에서 작성한, 광범위하게 파일 시스템을 검사하거나 조작하는 파이썬 애플리케이션을 다운로드한다면 해당 애플리케이션은 이따금 제대로 동작하지 않을 겁니다. 그렇게 되면 그건 구현 품질의 문제라고 볼 수 있죠. 그 사람들은 코드 작성자에게 버그를 제출할 수도 있으며, 아마도 다른 인코딩도 처리할 수 있도록 프로그램을 수정해야 하는 일이 일어날 수도 있을 겁니다. 또는 사용자들이 모든 파일명에 대해 동일한 인코딩을 사용하기로 마음먹을지도 모릅니다.
제 생각에 애플리케이션 가운데 소수의 부류는 적어도 당분간은 다른 인코딩으로 되어 있는 파일명도 처리하는 것이 중요하다고 봅니다. 만약 어떤 사람이 주된 용도가 파일 시스템을 검사하는 것인 애플리케이션을 작성하고 있다면, 아마 그 사람은 미드나잇 커맨더(Midnight Commander)의 파이썬 버전이나 그와 비슷한 다른 어떤 걸 작성하고 있는 것이며, 어떻게든 이런 사항들을 다루어야 할 겁니다.
파일 시스템을 스니핑(sniff)해서 어떤 인코딩이 지원되는지 알아내는 일은 그리 쉽지 않죠.
귀도 반 로섬: 여기서 전제는 파일 시스템이라고 해서 모든 부분이 같지는 않다는 겁니다. 물론 그 말은 만약 당신 친구가 다른 인코딩으로 파일을 만들었고, 당신이 그 파일의 인코딩이 뭔지 모른다면, 실제로 그 파일명을 읽어오거나 파일명을 입력하기가 곤란할 거라는 뜻입니다. 만약 운이 좋다면 그것들을 표시해주는 툴이 있고 몇몇 인식가능한 문자들이 있으며, 알수 없는 문자들은 사각형이나 물음표로 표시되어 실제로 파일명에 어떤 문자가 들어 있는지는 알지 못해도 그것들을 파일 목록에서 집어낼 수는 있어서, 그 파일에 들어있는 음악을 재생하거나 워드 문서로 여는 등의 작업은 할 수 있을 겁니다.
바라건대 문서에 들어있는 텍스트는 최소한 어떤 인코딩인지를 알 수 있는 방식으로 인코딩되어야 있어야 하는데, 그렇더라도 사용하기에는 다소 불편할 겁니다. 만약 누군가가 키릴 문자가 포함된 파일을 만들었는데, 사람들이 해당 디렉토리로 가서 그런 파일들을 봐달라고 하면 저는 키릴 문자들을 볼 수 있겠지만 여전히 그게 어떤 의미를 담고 있는지는 알지 못합니다. 저한테는 키릴 문자를 보는 것과 그냥 물음표를 보는 것은 큰 차이가 없습니다. 그건 실제로 제가 어떤 툴을 사용하고 있느냐에 달려있지요. 제가 이맥스(Emacs)에서 해당 파일 시스템을 본다면, 그것도 그 파일 시스템을 보는 한 가지 방법입니다. 제가 쉘에서 그걸 본다면 그것 또한 그 파일 시스템을 보는 또다른 방법인 것이죠. 제가 어떤 다른 GUI 툴에서 그 파일 시스템을 본다고 해도 마찬가지로 그 파일 시스템을 보는 또 다른 방법일 뿐입니다.
제가 바라는 것은 결국엔 더 많은 이들이 실제로 유니코드를 이해하는 겁니다. 세상엔 문자와 인코딩된 바이트와의 차이도 이해하지 못하는 사람도 많습니다. 저는 어떻게든 사람들이 좀 더 그런 부분이나 세부사항에 익숙해지거나, 그렇지 않더라도 소프트웨어가 올바르게 처리할 것이기 때문에 세부 사항은 별로 문제가 되지 않길 기대하고 있습니다.
그분들께 도움이 되는 툴을 만들어 주세요.
귀도 반 로섬: 그 부분이 바로 파이썬이 유니코드와 텍스트를 일반화해서 다루는 방식으로 변화하는 이면에 담긴 기본적인 사상입니다.
출시 계획, 즉 파이썬 3.1의 출시 체계를 봤을 때 저는 그런 일정들을 어떻게 그리도 잘 풀어나가시는지가 인상적이었습니다. 프로젝트 관리 관점에서는 어땠습니까? 빠뜨린 부분은 없었나요?
귀도 반 로섬: 저는 사실 일정을 완전히 장악하려고 했었습니다. 제가 생각하기로 처음 제가 3.0의 모든 출시일에 관해 생각하고 있었을 때가 2008년 초였습니다. 그때 저는 베이징에서 강연을 하고 있었죠. 거기서 저는 "내년 올림픽, 즉 2008년 8월에 3.0을 출시할 것으로 예상하고 있습니다."라고 말했습니다. 오랫동안 8월은 실지로 2.6과 3.0 모두에 대한 출시 예정일이었습니다. 출시일이 가까워지면서 저희는 시간에 기반한 출시가 굉장히 좋다는 사실을 알았지만, 일정 수준의 기능 완성도도 갖췄어야 했지요. 저희는 출시할 준비가 되지 않았음을 깨닫게 되었습니다. 한편으로 출시일을 무한정 연기하고 싶지는 않았고 출시 준비가 될때까지 급하게 프로젝트를 진행시키고 싶지도 않았습니다.
저희는 기획한 기능 가운데 실제로 남은 시간에 구현할 수 있는데 아직까지 아직 구현이 안된 것과, 지금 당장은 포기하고 3.1이나 2.7에서도 포함할 기회가 있을 거라 발표하는 것이 나은 것들을 골라내기 시작했습니다. 그러고 나서 출시일이 가까워지자 실제로 2.6이 3.0보다 성숙해졌고, 심지어 3.0 개발에 소요되는 리드 타임이 더 길었습니다. 그 이유는 3.0에서 변경되는 사항들이 진일보한 것이었기 때문이었죠.
결국에 저희는 더 이상 2.6을 붙들고 있어야 할 이유가 없지만, 또 3.0을 출시하는 것도 현명한 처사는 아니라는 걸 알게 되었습니다. 2.6이 최종 출시되기 전에 아주 잠깐, 저희는 2.6과 3.0이 베타버전으로 있을 때 두 버전을 완전히 맞춰서 출시하자는 아이디어를 냈습니다. 2.6의 최종 버전이 출시될 때 같은 날이었던가 같은 주에 3.0의 최종 후보 버전(RC; release candidate)도 출시했습니다. 그러고 나서 몇 번에 걸쳐 논의가 있었습니다. 어떤 이들은 최종 후보 버전이 실제로 최종 후보 버전이라는 이름을 가질 정도는 아니기 때문에 베타로 돌아가자고 말하기도 했습니다. 저희는 그것들을 계속해서 최종 후보 버전으로 부르기로 결정했지만, 다른 출시 버전에서 하면 더 나았을 법한, 이어지는 최종 후보 버전에서 발생하는 다소 규모가 큰 변경사항도 받아들였습니다. 그 시점에서 저희는 12월 초를 3.0의 최종 출시일로 정했습니다. 사람들은 매우 열심히 일했고, 마지막 순간에는 안정성을 유지하고 다른 기능을 추가하지 않는 일을 잘해주어서 결국엔 일정을 지킬 수 있었습니다.
계속해서 시간에 기반한 출시 방법을 활용할 생각이십니까? 1년에 한번씩 새로운 주요 출시 버전이 나오는 방식인가요?
귀도 반 로섬: 저는 순전히 억지로 그렇게 하고 싶지는 않습니다. 저는 꽤 구체적인 날짜를 골라서 개발자 커뮤니티의 모든 이들이 그에 관해 알고, "글쎄, 내가 만든 기능이 다음 출시 때 포함시키려면 그 기능을 좀 더 근사하게 만들고 출시하기 전에 실제로 몇 달을 전념해야 할거야"라는 생각을 할 수 있었으면 좋겠습니다.
그와 동시에 저는 출시를 그냥 임의 날짜로 맞추고 싶지도 않습니다. 그건 우리가 수년동안 겪어온 모든 출시 관리자들의 철학에 가깝습니다. 출시되는 버전은 안정성과 견고함, 완전성 측면이 특히나 높아야 합니다.
이따금 저희는 기능 동결을 해서 최종 출시 후보가 어느정도 형태를 갖추기 전까지는 기능 동결 상태를 유지할 겁니다. 지금까지는 그룹의 일원들을 통해 그런 일을 처리했었는데 항상 잘 처리되었습니다. 저는 핵심 개발 그룹 주변에 계신 많은 분들이 이것을 통해 많이 배운다고 생각합니다. 저희는 사람들이 별로 관심이 없다가 최종 출시 후보가 나오기 바로 직전에 매우 치명적인 버그가 출시되기 전에 해결되어야 한다고 주장하는 경우를 봅니다. 문제가 그렇게 심각하다면, 만약 문제가 진짜 해결해야할 문제라면 그 이슈를 실제로 해결할 조치를 취해야 할겁니다. 많은 경우, 보통 버그 트래커에서 오랫동안 해결되지 않고 남아있는 것들은 재생하기가 매우 어렵거나 애플리케이션 기능이나 API 사용, 또는 환경적인 요인이 매우 기묘하게 조합되는 경우에만 영향을 주기 때문입니다.
종종 저희는 이런 논의도 하곤 합니다. "글쎄, 세 개의 출시 버전이 계속해서 깨지고 있습니다. 단지 문제를 고칠려고 다음 출시일를 연기할 필요는 없습니다". 종종 이런 문제는 한 줄만 바꾼다고 해결되는 문제가 아닌 경우도 있습니다. 더군다나 이런 것들은 API를 리팩터링하거나 간혹 제대로 해결하려면 실제로 API를 호환되지 않는 방식으로 바꿔서 해당 API를 사용하는 기존 코드가 모두 작동하지 않도록 하는 수 밖에 없는 상황에 빠지게 하는 경우도 있는데, 이런건 3.0에서 했던 가장 전형적인 경우이고, 대개 보통의 경우에는 이렇게 하지 않습니다.
말씀하신 건 어쨌건 계획된 출시가 있기 한 주 전에는 하고 싶지는 않은 일이겠군요.
귀도 반 로섬: 확실히 서둘러서 하고 싶은 일은 아니죠.
저는 시간에 기반한 출시 방법을 굉장히 좋아합니다. 일단 몇번에 걸쳐서 그렇게 하고 나면 사람들은 그런 일정에 익숙해져서 바로 지금 출시됐다는 사실을 알게 되죠. 다음 두 주가 해금기(open season)이군요. 그럼 "아, 출시되려면 두 주나 한 달정도 남았군. 문서 패치나 지금 당장 수정해야 할 버그 목록 말고는 아무것도 받아들이지 않겠군."라고 말하게 되죠.
귀도 반 로섬: 그렇게 되면 아직까지 그 집단의 구성원이 아닌 사람들에게는 교육적인 효과가 있을 것 같군요.
혹시 독자들께 하고 싶은 말은 더 없으신지요?
귀도 반 로섬: 저는 이 시점에서 다시 한번 3.0이나 2.6 가운데 어떤 걸 사용할 것이냐는 매우 개인적인 선택이라고 말씀드리고 싶습니다. 이런 점에서 보수적인 입장을 취해서 홀로 남겨질 위험을 감수할 필요는 없습니다. 2.6도 3.0과 마찬가지로 핵심 파이썬 개발자들로 이루어진 그룹에 의해서 지원을 받을 겁니다. 그렇다고 해서 저희가 3.0의 중요성과 품질에 대해 덜 중요하다고 말씀드리는 건 아닙니다. 따라서 아직까지 3.0으로 포팅되지 않은 의존 패키지나 써드 파티 소프트웨어, 또는 다른 이들은 모두 다른 버전을 사용하고 있는 환경에서 일하고 있는 것과 같은 외부적인 요건에 구애받지 않거나, 여러분이 파이썬을 처음으로 배운다면 3.0은 새로운 언어를 배우는 굉장히 좋은 방법입니다. 3.0에는 초심자가 어려워하는 부분들을 많이 없앴습니다.
여러분이 3.0을 배운 다음에는 다른 것을 배우러 가기 보다는 2.6과 3.0간의 차이점을 배우는 것도 매우 쉽습니다. 파이썬 2.6을 배운적이 있다면 아마 책 표지가 2.5으로 나와 있고 2.2나 2.3, 그리고 저자가 갱신한 부분들에 관해 쓰인 책을 사용했을 겁니다. 그런 교재들은 실제로 아직까지도 2.3이나 2.4 버전에서는 비추천된 이디엄(idiom)들을 사용하고 있죠. 여러분이 2.6을 사용하고 있다면 실제로는 대부분 2.3이나 제 생각에 지금보다 약 5년 정도 낡은 것과 호환되는 언어의 한 변종을 사용하고 있는 셈입니다.
반면, 2.6을 사용할 목적으로 3.0을 배운다면 여러 3.0의 기능들은 실제로 2.6으로 백포트되었거나 이미 사용가능한 것들 몇가지는 배우지 않게 됩니다. 그런 것들에는 print문과 print 함수처럼 근본적으로 다른 것들도 몇 가지 있습니다.
실제로 나중에는 2.6에서 print 함수를 임포트할 수도 있을 겁니다. 정말로 사람들은 자신의 요구사항을 살펴봐서 2.6을 쓸지 3.0을 쓸지 결정해야 하며, 3.0이 지원되지 않거나 또는 2.6이 지원되지 않을 거라는 점에 관해 걱정해서는 안됩니다. 저는 5년 안에는 2.6이나 2.X 버전대가 훨씬 더 중요성이 낮아질 거라 생각합니다. 그렇지만 앞으로 3년이나 4년 동안에는 2.X에서 3.0으로의 이전 작업이 굉장히 느리게 진행될 겁니다.
천천히 미래로 나아가시길 바랍니다.
귀도 반 로섬: 네.
TAG :
최신 콘텐츠