귀도 반 로섬이 파이썬 커뮤니티의 핵심 기여자 토머스 우터스와 나눈 대화를 정리한 인터뷰. 파이썬에 처음 기여하게 된 계기, 초기 메일링 리스트 문화, `+=`(증강 대입) 구현, 중첩 스코프와 `__future__` 임포트, XML/xmlplus, PSF 창립 및 초기 PyCon 이야기 등을 다룬다.
URL: https://gvanrossum.github.io/interviews/Thomas.html
Title: Interview with Thomas Wouters
2026년 2월 28일
나는 언제나 인터뷰라는 문학적 형식을 즐겨 왔고, 언젠가 나도 그걸 조금이라도 해 볼 수 있기를 바랐다.
마침내 내가 동기를 얻게 된 과정은 이렇다.
최근 유튜브에 파이썬에 관한 훌륭한 다큐멘터리가 공개됐고, 상영 파티가 끝난 뒤 몇몇 올드타이머들이 영화에 언급되지 않았던 파이썬 개발자들과 기여자들에 대해 추억을 나누기 시작했다.
나는 파이썬의 구술사가 내 관점을 통해 전해진 사례(특히 컴퓨터 역사 박물관이 매우 철저하게 진행한 것이 대표적)는 있었지만, 커뮤니티의 다른 많은 이들은 자기 이야기를 할 기회가 거의 없었다는 걸 깨달았다.
이 시리즈를 통해 나는 그 공백을 메우고자 한다. 모든 코어 개발자(그리고 다른 기여자들)에게 발언권을 주려는 것이다. 물론 이것도 여전히 내 렌즈를 통과해 보이겠지만, 나는 인터뷰이가 주로 말하도록 최대한 노력한다.
왜 팟캐스트가 아니냐고 물을 수도 있겠다. 매체 자체는 존중하지만, 제작자로서도 소비자로서도 나는 글로 된 형식을 훨씬 선호한다.
나는 2015년을 임의의 커트오프(기준 연도)로 잡았다. 그 해까지 파이썬 커뮤니티에 관여하지 않았다면, 나는 그 참여가 너무 최근이라 “역사”로 보기 어렵다고 판단한다. 나 이후의 누군가가 더 젊은 세대를 인터뷰하면 되겠지만, 나는 파이썬의 첫 25년에 집중하고 싶다.
내 첫 번째 인터뷰는 토머스 우터스(Thomas Wouters)와 함께했다. 그는 += 연산자와 그 친구들(증강 대입, augmented assignment)을 구현하는 것부터 PSF 이사회, 파이썬 스티어링 카운슬, PSF 임시 디렉터 역할, 그리고 프리 스레딩(free threading) 작업에 이르기까지 파이썬 커뮤니티에서 정말, 정말 많은 역할을 맡아 왔다.
아래는 우리 대화를 압축하고, 정리하고, 다듬은 버전이다. 둘 다 옛이야기하는 걸 즐겼던 것 같다! (또 한 가지: 여러분이 듣는 것은 영어로 잡담하는 두 네덜란드인의 대화다. 토머스와 나는 개발 이야기를 할 때는 물론이고, 종종 그 외의 경우에도 늘 이렇게 대화한다.)
Guido: 파이썬을 처음 알게 된 건 언제였고, 어떻게 여기서 기여하는 게 재미있겠다고 생각하게 됐나요?
Thomas: 처음 파이썬을 들은 건, 코모도어 64 베이식(Commodore-64 Basic) 이후로 내가 처음 제대로 써 본 프로그래밍 언어가 LambdaMOO였기 때문이에요. LambdaMOO는 월드 와이드 웹이 생기기 전 인터넷 세계에 있던 온라인 커뮤니티/텍스트 기반 멀티 유저 던전(MUD)이었죠. 내가 그만큼 나이가 있다는 뜻이기도 하고요. 그러니까, 난 당시엔 십대였지만, 나이는 어쨌든 그 정도입니다.
유즈넷 같은 그 이전의 무언가가 아니라, 인터넷 위였군요.
맞아요.
그 시기가 월드 와이드 웹이 개발되던 때였어요. 92, 93, 94년쯤. 암스테르담에는 ‘디지털 시티(Digital City)’라는 게 있었는데, 사람들에게 인터넷을 소개하는 굉장히 흥미로운 프로젝트였죠. 첫 버전은 고퍼(Gopher)를 썼고, 그 일환으로 ‘디지털 메트로(Digital Metro)’라는 LambdaMOO 인스턴스를 운영했어요. 암스테르담 지하철을 모델로 했고, 지하 세계라는 설정이었죠. 그리고 그곳이 프로그래밍 환경이었어요. 다중 사용자, 텍스트 기반, 거의 게임 같은데 완전한 게임은 아닌… 그런 곳에서 LambdaMOO 언어로 프로그래밍을 할 수 있었어요. 그리고 LambdaMOO 언어가 파이썬과 굉장히 비슷했거든요.
어쩌다 그렇게 된 거죠?
그냥 병렬 진화(parallel evolution)였던 것 같아요. 문법적으로는 완전히 비슷하진 않았고, 예를 들어 중괄호를 썼죠. 하지만 개념적으로는 ‘모든 것이 객체다(everything-is-an-object)’라는 모델이 아주, 아주 비슷했어요.
동적 타입도요?
네, 동적 타입이 어디에나요.
LambdaMOO를 썼던 다른 사람 이야기도 들은 적이 있는 것 같네요.
아마 초창기 Twisted 개발자들 중에 LambdaMOO 키즈가 꽤 많을 거예요.
아, 그럼 그분들도 당연히 인터뷰해야겠네요.
그래서 난 LambdaMOO에서 Perl과 C로 옮겨 갔고요. LambdaMOO가 아닌 다른 MUD들도 좀 했어요.
그래도 여전히 십대였나요?
형식적으로는 십대였는데, 네덜란드의 한 ISP에서 일하고 있었어요. 디지털 시티에서 일하기 시작했고, 그다음엔 디지털 시티를 만든 회사인 XS4ALL에서 일하기 시작했죠. 거기서 11년 일했어요. 시스템 관리자였다가 소프트웨어 개발도 했고요. 그런데 취미로는 여전히 다양한 MUD를 많이 했고, 그중 하나에서 누군가가 파이썬을 소개해 줬어요. “LambdaMOO 좋아하니까 이 언어 좋아할 거야”라고요.
그게 1998년이나 99년쯤이었던 것 같아요. 그런데 그땐 Perl을 배우느라 바빴고, Perl이 얼마나 싫은지 깨닫는 중이어서, 그 말을 심각하게 받아들이진 않았죠. 그러다 어느 시점에 파이썬을 잡아 봤는데, 아주 빨리 “아, 이게 내 머리에 딱 맞는다”는 걸 알게 됐어요. 뭔가 따로 생각하지 않아도 자동으로 이해되는 느낌이랄까요. 다른 어떤 언어보다도요.
C도 꽤 좋아하고, C의 함정들조차 꽤 좋아해요. C와 C++은 매우 편하고, Java나 PHP도 꽤 편하게 다루지만, 파이썬은 그냥 재미있고 즐겁고, 말이 돼요.
그리고 물론 그때는 유즈넷 시대였죠. 파이썬 리스트… 네, 이메일 리스트 게이트웨이도 있었던 것 같고요. 그래서 Python-List를 구독했고, 그냥 쓰면서, 따라가면서 파이썬을 많이 배웠죠. 글을 읽고, 특히 팀 피터스(Tim Peters) 글을 많이요.
처음 Python-List를 구독했을 때 인상 깊었던 사람들, 그리고 분위기가 어땠는지 더 말해 주세요.
그러니까, 당연히 팀 피터스랑 프레드릭 룬드(Fredrik Lundh)죠. 내가 기억하기로는 그들이 가장 왕성하게 글을 올렸어요. 팀은 늘 토론에 참여하는 걸 엄청 즐겼고, 자기 관점을 제시하고, 사람들이 참여하고 싶게 설명했어요. 그러면 더 많은 기여와 더 많은 토론이 이어지고요. 유즈넷이 원래 그런 문화였죠. 토론, 또 토론, 또 토론.
유즈넷에서는 사실 거의 토론밖에 할 게 없죠. 매번 불꽃 튀는 싸움(플레임 워)으로 번지지 않으면 좋은 거고요.
맞아요. 플레임 워도 있긴 했지만, 보통 파이썬 쪽에선 많지 않았어요. 다만, 누군가가 와서 “파이썬을 10배, 100배 더 빠르게 만들 수 있다”고 주장했던 건 기억나요. 파이썬 자체를 실제로 이해하진 못했으면서도, “다른 언어에서 해 봤으니 파이썬도 할 수 있다” 같은 식이었죠.
그게 누군가요?
기억이 안 나요. 너무 오래전이라서요.
그런 생각을 한 사람들이 꽤 많긴 했죠. 뭔가 간단하게 할 수 있다고 믿는 사람들.
아마 그런 부류였을 거예요. 그 사람이 선불로 돈을 받으려 했던 것 같아요. 어떤 작업 성과도 보여주기 전에요. Python-List에서 완전히 박살 났죠. 아무도 진지하게 받아들이지 않았거든요. 하지만 Python-List에서 그런 적대감은 드문 편이었어요. 대체로 매우 친절하고 환영하는 분위기였죠.
그리고 또 기억나는 사람이 마이클 허드슨(Michael Hudson)인데요.
맞아요.
그가 “이걸 시작해 봤어. 증강 대입에 대한 개념 증명(proof of concept) 패치야”라며 패치를 올렸죠. +=, -= 같은 것들요. 그 패치가 파이썬에 그 기능을 추가하는 데 놀랄 만큼 단순하다는 점이 내게는 충격이었어요. 그래서 파이썬 구현을 들여다보게 됐죠. 그리고 내가 그 패치를 가져다가 마무리했어요. 마이클은 못 했거든요. 시간이 없었는지, 흥미가 없었는지, 모르겠어요.
그는 프로젝트를 시작하는 사람이지, 끝내는 사람은 아니었죠.
네. 그리고 마이클은 여러 해 동안 “내가 파이썬에 한 가장 큰 기여는 토머스를 코어 개발로 끌어들인 거야”라고 말하곤 했죠.
(Guido 웃음.)
그게 나를 Python-Dev 리스트로 이끌었고, 사실상 귀도가 그 패치를 끝내도록 멘토링해 줬죠. 내가 감히 못 했고, 지금도 확신이 없는 설계 결정들을 귀도가 해 줬는데, 예를 들면 리스트에서 +=가 작동하는 방식 같은 거요.
그래요. 각 타입은 어떻게 할지 결정할 수 있고, 새 객체를 만들 수도 있고, 기존 객체를 제자리(in place)에서 수정할 수도 있죠. 그리고 파이썬 초창기부터 내 직감은, 리스트나 일반적인 컬렉션(딕셔너리 등)은 단순 값들보다 사용자에게 다른 “의미”를 가진다는 거였어요. 문자열까지의 단순 값들은 전부 불변(immutable)이었지만, 리스트와 그 밖의 것들은 가변(mutable)이었죠. 튜플은 그 중간쯤에 앉아 있었고요.
돌아보면 동의해요. 하지만 이상한 코너 케이스가 있잖아요. 예를 들어 튜플이 있고 t[0] += something을 하면요. 튜플의 첫 항목이 리스트라면, +=가 리스트를 변경한 다음에, 튜플은 불변이니까 그 항목에 대입할 수 없어서 예외가 나요. 그런데 리스트는 이미 변경되어 버렸죠.
아, 맞아요.
그건 합리적인 의미론들의 정상적인 결과이지만, 그 의미론들이 합쳐진 결과가 놀랍게 느껴지는 거죠. 더 나은 처리 방법이 있다고 생각하진 않아요. 이런 건 린터(linter)의 영역이죠. “이런 짓은 하지 마라. 놀라운 결과가 나온다”라고 경고하는요.
뭐, 코드를 실행하자마자 알게 되긴 하죠. 그리고 그 시절엔 자기가 쓴 코드가 즉시 실행되는 경우가 훨씬 많았고요.
맞아요.
지금은 코드가 너무 많아서 모든 줄을 건드리는 데 시간이 오래 걸리죠. 만약 +=가 항상 복사를 해야 했다면, 나는 리스트에서는 아예 지원하지 않고 .extend()만 쓰라고 했을 것 같아요. 그건 튜플 케이스에서도 동작하거든요.
그렇죠. 그리고 기대한 대로 동작하고요. 아니, 기억이 맞다면 그때 귀도의 논리는 이거였어요. “리스트에서 +=가 제자리 대입을 하지 않게 만들거나, 상황에 따라 타입이 각자 동작을 정할 수 있게 열어두지 않으면, +=는 애초에 가치가 없다. 그냥 +의 문법 설탕일 뿐이니까. 우리는 문법 설탕만을 위해 그걸 넣는 게 아니다. 가변 타입에서 새로운 유틸리티를 제공하기 위해 넣는 거다.”
그래서 그게 내가 파이썬 자체 개발에 들어오게 된 계기였죠.
그게 당신의 큰 기여였던 걸로 기억해요.
맞아요.
초기의요.
네. 그리고 그 무렵 귀도와 PythonLabs 팀이 BeOpen에서 시작했었죠. 아마.
아, 그럼 2000년이군요.
2000년이 맞아요. 이건 파이썬 1.6이 아니라 2.0에 넣은 것 중 하나였죠. 1.6과 2.0을 구분하기 위해요.
2.0을 위한 작은 당근이었죠.
그리고 이게 PEP 204인가, PEP 203인가… [203이었습니다. –Guido]
꽤 초창기네요.
엄청 초창기죠. 사실 PEP라는 아이디어가 나오기도 전에 작업을 시작했으니까요.
내용 PEP는 200번대부터 시작했던 것 같아요. 100번대는 프로세스 같은, 뭔가 특별한 거였고.
내 PEP는 PythonLabs 사람들이 쓰지 않은 첫 번째 PEP였던 것 같아요. 그리고 다음으로 내가 쓴 PEP가 ‘range 리터럴(range literals)’인데, 그건 내 최애 PEP예요. 왜냐하면 거절됐거든요.
왜 그게 최애죠?
아이디어를 떠올리고 발전시키는 과정 자체가 좋았어요. 내 아이디어였던 것 같진 않고요. 다른 언어에 비슷한 구문이 있어서 오래전부터 떠돌던 아이디어였죠. range 내장 함수를 대체하기 위한 범위 구문(syntax)을 만들자는 거였고, 사실상 옛 xrange 내장 함수를 대체하려는 거였죠. 즉, 지금의 range요.
당시 range는 전체 리스트를 반환하는 함수였는데, 그 구문은 리스트 전체를 인스턴스화하지 않고도 인덱싱이 가능하고 필요한 의미론을 가진 range 객체를 반환하게 하자는 거였어요. 나는 그 문법이 좋았지만, 문맥에 따라 좀 헷갈릴 수 있었어요. 예를 들어 range를 순회(iterate)하면 콜론이 엄청 많이 나올 수 있었고, 그게 혼란스러웠죠.
당신이 설계했던 표기법이 뭐였는지 기억하나요?
대괄호였어요. 대괄호 열고, 시작점, 콜론, 끝점, 대괄호 닫기. 그리고 스텝(step)도 고려했던 것 같아요. 그래서 리스트처럼 보이지만 리스트는 아닌.
음, 리스트 인덱스처럼 보였죠. 범위 리터럴을 만들고 싶다면 가장 자연스럽게 먼저 시도할 표기예요. 게다가 콜론이 최소 하나는 들어가야 하니까, 현재 문법에서는 유효한 리스트가 아니고요.
재밌었어요. 패치도 썼고요. 콜론을 보기 전까진 리스트로 파싱하다가, 콜론을 보면 “아, 이건 range구나” 하고 마음을 바꾸는 식이었죠.
아, 맞아요. 그리고 당시의 원래 파서는 지금보다 그걸 훨씬 어려워했죠.
그래서 구현하고 설계하는 게 정말 재미있었는데, 결국 거절됐죠. 그리고 그게 옳은 선택이었다고 생각해요. 오해하진 마세요. 나는 단지 “좋은 아이디어라고 생각하고 끝까지 밀고 나가서 실제로 구현해 본 다음, 결국 ‘아니, 이건 말이 안 된다. 단점이 너무 많고 혼란이 너무 크고, 이득이 변화와 혼란을 정당화할 만큼 크지 않다. 그러니 하지 말자’라고 결론 내릴 수 있는” 그 과정 자체가 즐거웠던 거예요.
그 결정은 내가 내린 건가요, 아니면 다른 사람들도 반대했나요?
대체로 그룹 합의였던 것 같아요. 물론 당시 그룹 자체가 매우 작았지만요. 많은 사람은 딱히 어느 쪽이든 강하게 관심이 없었고요. “그래, 이게 절대적으로 옳다”라고 말하는 사람이 충분히 많지 않았고, “음, 잘 모르겠다”는 사람은 충분히 있었죠. 누군가가 강경하게 ‘반대!’한 건 아니었던 것 같아요. 다만 그 시절엔 강경한 ‘노(no)’ 자체가 꽤 드물었죠.
그리고 이건 역사 인터뷰와는 좀 다른 이야기로 빠지지만, 그 문법에서 대괄호를 쓰면 반환값이 리스트라고 강하게 암시했을 것 같아요.
맞아요.
그리고 우리는 결국 range가 리스트를 반환하는 게 옳지 않다는 걸 배우게 됐죠.
그것도 이유였던 것 같아요.
어쩌면 꽤 무서운 미스피처를 피한 걸지도 모르겠네요.
네, 그런 것 같아요. 당시엔 컴파일러가 똑똑해서 range 객체가 어디에 쓰이는지 보고 최적화할 거라고 기대했던 부분도 있었어요. 예를 들면 range를 순회할 때 루프 언롤링(loop unrolling) 같은 걸 한다든지요. 그런데 우리는 그런 걸 실제로 하려고 들지 않았고, 지금도 사실 루프 언롤링은 거의 안 하죠.
적어도 for … in 다음에 정확히 range 리스트가 오는 케이스만 특별 취급(special-case)할 수는 있겠네요.
네, 맞아요.
그럼 누구도 리스트 대신 xrange 객체가 생성됐다는 걸 알아챌 방법이 없죠.
맞아요.
하지만 다른 곳에서 쓰면 실망했겠죠.
네, 네. 그리고 최적화 아이디어가 당시에는 매력적이었어요. 파이썬이 매우 느리다고 알려져 있었으니까요. 수년 동안 정말 많이 좋아지긴 했지만, 그땐 차이가 더 크게 느껴졌고 지금처럼 성숙하지도 않았어요.
그 시절 Python-Dev 리스트에서 논의하던 ‘큰 이름들’은 누구였나요?
당연히 팀도 있었고요. 그리고 이 부분에 대해선, 아카이브가 공개되어 있다는 걸 알고 있어서(실제로 2주 전에 봤어요), 거기엔 내가 알아보지 못하는 이름들도 있었어요. 기억엔 참여했던 것 같지 않은데, 글을 읽어보면 뭔가 떠오를지도 모르죠.
내가 또렷이 기억하는 이름들은 팀 피터스, 아까 말한 프레드릭 룬드, 그리고 소통 관련이면 프레드 드레이크(Fred Drake)요.
그는 문서 작업도 정말 많이 했죠.
네. 문서 중심이었다고 기억해요. 제러미 힐튼(Jeremy Hylton), 배리 워소(Barry Warsaw)도요. 배리는 Python-Dev에 들어오기 전부터 알고 있었어요. 난 직장에서 Mailman을 작업했거든요. 배리와는 늘 잘 맞았고, 파이썬에서도 따뜻하게 맞아주는 목소리였죠.
흥미로운 연결이네요.
그리고 제러미는 주로 컴파일러를 했고, 중첩 스코프(nested scopes) 같은 걸 도입했죠. 중첩 스코프를 넣기 위해 하위 호환성을 깨뜨릴지 말지에 대해 길고 지리한 논쟁을 했던 게 기억나요. 결국 그게 팀 피터스가 “future imports(미래 임포트)”를 제안하는 계기가 됐죠. 그것도 내가 좋아하는 상호작용 중 하나예요.
아, future import가 중첩 스코프 논의에서 나왔다고요? 그래서 from __future__ import nested_scopes 같은 걸 쓸 수 있게.
네.
이제야 그 문구가 익숙하게 들리네요.
(웃음) 네. nested_scopes가 첫 번째 future import였던 것 같아요. 꽤 확실해요.
future import의 추진력이 팀 피터스였다는 건 확실하죠.
나는 2006년에 구글에서 일하기 시작했는데, 제러미는 그때 이미 구글에서 몇 년 일하고 있었어요. 지금도 구글에 있어요. 작년이나 재작년에 그를 만났는데, 그가 2001년에 중첩 스코프 때문에 우리가 했던 논쟁과, future import가 그 논쟁에서 나왔다는 이야기를 꺼내더라고요.
그 논쟁이 정확히 뭐였죠?
지금은 상상하기 어렵지만, 당시엔 중첩 스코프가 그냥…
네, 거의 25년 동안 언어에 있었죠.
그런데 그땐 함수 안에 함수를 정의하면, 안쪽 함수에서 바깥 함수의 변수를 참조할 수 없었어요.
전혀요. 바깥 네임스페이스가 완전히 보이지 않았죠.
네. 바깥 함수의 어떤 이름도 참조할 수 없었어요.
람다는요?
람다도 마찬가지였어요. 그래서 바깥 스코프에서 쓰고 싶은 건 모두 인자로 넘겨야 했죠. 이건 당연히 심각한 제약이었고, 그 제약 때문에 할 수 없는 일이 많다는 데는 모두가 동의했어요. 제러미가 그걸 고칠 방법을 찾았죠.
그럼 중첩 함수가 2등 시민이 되는 거네요.
네, 쓸모없어져요. 그냥 네임스페이싱용일 뿐, 함수가 할 수 있는 일이 달라지진 않죠.
그리고 고전적인 LISP 예제 있잖아요. 인자로 n을 더하는 함수를 반환하는데, 그 n을 생성 시점에 넘겨서 캡처할 방법이 없던.
그래서 논쟁은 “중첩 스코프를 넣을 것인가”가 아니었어요. 그건 다들 “대단히 좋은 변화고 많은 걸 가능하게 해 줄 것”이라고 동의했죠. 다만 어디까지 갈지, 얼마나 근본적이 될지(지금은 데코레이터 등 수많은 것이 그 위에 세워졌잖아요)는 아무도 몰랐고요.
맞아요.
우리는 “좋다”에는 합의했지만, 문제는 하위 호환성 변경이라는 점이었어요. 이미 중첩 함수를 쓰고 있는 코드에서, 예를 들어 변수 이름이…
전역을 참조하고 있는데, 바깥 함수가 같은 이름의 로컬을 가지고 있어 그 이름을 가리면, 안쪽 함수의 동작이 갑자기 완전히 달라지는 거죠.
네. 그래서 우리는 그걸 오래 논쟁했어요. 하위 호환성을 깨뜨릴 가치가 있는가? 일반적으로 하위 호환성을 어떻게 다룰 것인가?
제러미는, 음… 이게 파이썬 개발이 ‘전문직화(professionalization)’되는 과정이기도 했다고 생각해요. 더 이상 우리 코드만 생각하지 않고, 다른 사람들이 파이썬을 어떻게 배포하는지 생각하게 됐으니까요. 자기 코드만을 위해 파이썬을 쓰는 게 아니라, 파이썬 사용자들을 위해 파이썬을 배포하는 사람들이요.
그전엔 다들 “내가 파이썬 빌드해서 내가 쓴다. 내가 빌드한 버전을 쓴다” 정도였던 것 같은데, 나는 시스템 관리자였고, 사용자들을 위해 파이썬을 빌드하고 배포했어요. 그것도 기업 사용자였고, 그들을 깨뜨리면 안 됐죠. 새 파이썬을 배포했다가 고객 코드가 깨지면 고객이 나한테 화내니까요. 그럼 내 입장에선 새 버전 배포가 막히는 거예요. 그래서 내가 그렇게 하위 호환성을 강조했죠. 지금도 그렇고요.
맞아요. 2000년대 초에는 그게 계속된 논쟁거리였죠. 스티브 홀든(Steve Holden)이 어느 시점에 전체 세션(plenary)에서 일어나서, 무대 위의 사람들(아마 나 혼자였을 수도 있고, 여러 코어 개발자였을 수도)에게 “파이썬이 너무 빨리 바뀐다. 커밋을 해야 한다. 새 기능이 있는 릴리스 직후 너무 빠르게 또 새 기능 릴리스를 내면 안 된다”라고 말했던 게 기억나요. 그때 타협안이 18개월이었던 것 같고, 그걸 아주 오래 유지했죠. 그러다 현대적인 프로세스로 두 번 정도 릴리스를 한 뒤였나, 아니면 스티어링 카운슬이 시작된 뒤였나… 아마 우카시(Łukasz)였나?
아니요, 연 1회 릴리스로 바뀐 건 3.9부터예요. 3.9 이후였던 것 같아요.
3.9가 언제였는지는 기억이 안 나지만, 스티어링 카운슬 이후였던 건 꽤 확실해요.
네.
스티어링 카운슬은 선거 주기가 릴리스에서 릴리스까지로 정의되어 있었으니까요.
맞아요.
그리고 어느 시점에 다들 “다른 대형 오픈소스 프로젝트들과 보조를 맞추려면 연간 릴리스가 필요하다”에 동의했죠. 그러고 나서 ‘아!’ 스티어링 카운슬도 이제 매년 선출되는구나를 깨달았고요. 하지만 스티브가 그걸 불평하기 전에는, 포인트 릴리스에 새 기능을 넣는 데 꽤 느슨하지 않았나요? 내가 마지막으로 그걸 해도 넘어갔던 게 언제였는지 기억나요?
음, True와 False가 2.2.3에 추가된 거요.
그런 비슷한 거요.
당시엔 좋은 일처럼 느껴졌지만, 좋은 학습 경험이었죠. 후폭풍이 최소였잖아요. 사람들이 감수할 수 있는 수준의 짜증 정도였고요. 그래서 “그건 좋은 일이 아니다”라는 걸 보여줬죠. 나쁜 트레이드오프였어요.
맞아요. 이슈는, 명백한 버그 수정이 아닌 한, 2.n.1과 2.n.어떤 큰 숫자 사이가 항상 앞/뒤로 호환되어야 한다는 거였죠.
네. 지루한 버그(boring bugs) 문제가 있어서 어렵긴 하지만요.
요즘은 버그를 고쳐야 할 때도 대체로 아주 소수에게만 영향을 주도록 비교적 잘 하고 있죠. 물론 “비교적”이긴 해요. 사용자 수가 너무 많아져서, 2000년대 초보다 훨씬 많은 사람이 영향받겠지만요.
릴리스 매니저 관점에서 보면, 어떤 변화의 영향을 파악하는 게 생각보다 어렵습니다.
아, 네.
버그 수정을 가능하게 하려면 뭔가를 바꿔야 하는데, 그 변화가 예상치 못한 결과를 낳는 경우가 있어요. 내가 바라는 것보다 더 자주요. 좋은 해결책은 모르겠어요. 그냥 어려운 문제죠.
프레드릭 룬드에 대해 추억 좀 해 봅시다. 나는 그를 인터뷰할 수 없으니까요. 결국 그에 대한 이야기는 다른 사람들의 기억을 통해서만 듣게 되겠죠.
나는 직접 몇 번 만났던 것 같아요. 구글에 같이 있던 기간도 꽤 길었는데, 난 사실 그와…
그는 취리히에 있었죠, 맞나요?
네, 취리히요. 아마 대부분 유튜브에서 일했을 거예요.
그런데 구글에 간 뒤에는 파이썬 커뮤니티에서 그를 자주 보진 못했죠. 번아웃도 있었던 것 같고요. 이혼도 했죠?
그건 기억이 안 나요.
이혼했고, 취리히에 있으면서 딸과 충분한 시간을 보내는 게 인생의 스트레스 중 하나였던 걸로 기억해요.
그는 Effbot이었죠. 팀이 Timbot이었듯이, 프레드릭은 Effbot이었어요. 워낙 많은 주제에 대해 너무 많이 글을 올렸으니까요. 그리고 기억하기로 그의 관심은 늘 Tkinter였던 것 같아요.
거기에 많이 관여했죠. 처음 만든 건 아닐 거예요.
Secret Labs 정규표현식 엔진도요.
아, 그래서 S가 붙는군요.
네. 회사 이름이 Secret Labs였어요.
그 티셔츠 기억나요.
나도 티셔츠를 본 적 있어요.
좀 지루하죠.
기업 느낌이요.
직원 다섯 명쯤 되는 회사였던 걸로 아는데요. 그 정도면 딱히 ‘기업’이라기보다는… 남색 티셔츠에 하얀 로고가 가슴에 작게 있는 정도였죠.
그리고 Secret Labs, 그러니까 프레드릭은… 기억이 맞다면 CNRI에서 유니코드 지원을 위해 고용되어서, 유니코드를 지원할 수 있도록 정규표현식 엔진을 교체하는 일을 했어요. 1.6에서요.
아, 고용이었어요?
내 기억으론 CNRI가 그 일을 하도록 비용을 지불했던 것 같아요. 대가를 받고 그 일을 했다는 거죠. 어쨌든 우리는 그걸 아주 오래 의존했고, 그들은 늘 거기에 있었고, 적어도 프레드릭은 지원도 늘 해 줬죠. 그래서 내 기억은 CNRI가 돈을 댔다는 거예요.
가능성 있네요. 특히 알 베자(Al Vezza)는 그런 일에 열린 사람이었어요.
아마 마크-앙드레가 알 거예요. 내 기억으론 마크-앙드레 렘부르크(Marc-André Lemburg)도 이 일에 관여했거든요. 정규표현식 엔진이 아니라 유니코드 구현 쪽일 수도 있지만요. 마크-앙드레도 돈을 받았던 걸로 기억해요. 그의 회사가 유니코드 작업 일부에 대해 비용을 받은 거죠. CNRI가 아니었을 수도 있고 다른 곳이었을 수도 있지만, 내 기억은 그래요.
나는 돈의 흐름에 대해 항상 순진했어요. 지금도 그런 것 같고요.
나도 초기 파이썬 소프트웨어 재단(PSF) 시절 기억이 있어요. 그래서 Python-Dev에서 마크-앙드레도 언급해야죠. 정말 오래 있었어요.
아주 오래요.
음, 다른 사람들… 내가 어울리고 상호작용한 사람들로는, 앞서 말한 Twisted 개발자들도 있어요. 늘 흥미로웠죠. 모셰 자카(Moshe Zadka) 자체는 그렇게까지는 아니었고요. 그는 나와 비슷한 시기에 파이썬 코어 개발자였어요.
그는 내가 실제로 처음 직접 만난 파이썬 커뮤니티 사람이기도 해요. 2001년 국제 파이썬 컨퍼런스(IPC) 전날, 엘리베이터에서 우연히 마주쳤거든요. 그리고 다음 날, 두 번째로 마주친 사람이… 모셰와 내가 엘리베이터에 있었고, 귀도가 탔죠. 그래서 귀도가 내가 직접 만난 두 번째 파이썬 커뮤니티 사람이었어요.
모셰는 인터뷰해야겠네요. 직접 만나서 할 수 있고요.
하지만 다른 Twisted 개발자들… Glyph도 있고, 더 많은 이름이 있는데… 꽤 유명한 사람들이죠. 다만 당시엔 자기들 작은 일(Twisted)을 하던 개발자들이었고, 파이썬과는 꽤 분리되어 있었어요.
이건 내 기억이 왜곡된 걸지도 모르지만, Twisted는 전부 Glyph의 작업이라고만 기억하고 있었어요.
아니요, Twisted는 큰 프로젝트였어요.
그렇군요.
Glyph가 훨씬 잘 말해주겠지만…
그 사람도 인터뷰할게요.
Twisted는 원래 Java로 시작했어요. 그러니까, 그가 Java로 멀티… 기본적으로 MUD 같은 걸 만들려던 시도였죠? 젊은이들이 여전히 텍스트 기반 게임을 하던 때였고, 그는 Twisted Matrix…였나, Twisted Reality… 중 하나였던 것 같아요.
Twisted Matrix는 익숙하네요.
Twisted Matrix는 프레임워크 이름이 된 것 같고요. 게임은 Twisted Reality였던 것 같아요. Java 프로젝트로 시작했다가 Python으로 옮겼고, 스레드 기반이 아니라 코루틴이 파이썬에 생기기 전의 코루틴 같은 방식이었죠. 즉, 콜백 기반이었어요.
프로미스(Promise)군요.
음, Deferred요.
아, Deferred.
지금의 asyncio가 동작하는 방식과 아주 비슷하죠.
맞아요. Promise, Future, Deferred. 다 같은 아이디어죠. Deferred는 yield가 없던 시절이라 아주 특정한 특성이 있었고요.
네. yield from도 없었고, yield도 없었죠. yield가 생기고 나서 누군가 Deferred 위에 사실상 코루틴을 구현했는데, 아마 inline callbacks라고 불렀을 거예요. 그걸로 asyncio까지 절반쯤 갔고, 나중에 yield from이 생기면서 그것도 접목됐죠. 그리고 asyncio가 파이썬 3의 일부가 되면서, Twisted의 빛을 조금 가져가 버린 것 같아요.
그렇죠.
그리고 Zope 인터페이스 사용 같은 흠(wart)도 고쳤고요. 난 그걸 별로 좋아하지 않았어요.
나도요. 그 시절 다른 사람들은…
아카이브를 봐야 할 것 같아요. 그냥 아카이브를 보고 이름을 보면, 읽다 보면 떠오르겠죠.
아카이브를 봤을 때 상위 포스터 목록을 뽑았는데, 내가 전혀 모르는 이름도 있었어요. 실제 글을 읽으면 뭔가 생각날 수도 있고요.
아서 시겔(Arthur Siegel)이라는 이름 기억하나요?
아니요.
흥미롭네요. 나만 그에게 인상을 받은 걸지도요.
그땐 내가 쉽게 영향을 받았고, 시간이 지나면서 냉소적으로 변했으니, 이름들을 많이 잊어버렸을지도 모르죠. 그때 난 어렸으니까요. 이제는 안 젊고요.
내게 당신은 항상 젊을 거예요. 아서 시겔은, 기억하기로는, 뭐든지 반대 의견을 내는 논쟁적 인물이었고, 자기 의견을 강하게 방어하는 걸 두려워하지 않았죠. 그래서 플레임 워로 번지지 않아도, 때로는 꽤 고통스러웠어요.
나는 아마 그걸 그냥 지워버린 것 같아요. 인터넷이 성장하면서 그런 일이 더 흔해졌고, “이 사람은 진지한 사람이 아니다/흥미로운 사람이 아니다”라고 판단하고 무시했을 수도요.
아, 핑(Ping)도 언급해야 해요.
아, 맞다!
반골 기질 때문이 아니라, 핑은 그 반대지만요. 그가 당시에 매우 생산적이었고 흥미로운 아이디어가 많았어요.
그는 여기 근처에 사니까 인터뷰할 거예요. 거의 1년 동안 못 봤으니, 이제 슬슬 볼 때도 됐고요. 그럼 Effbot이 Tkinter랑 정규표현식 말고도 다른 걸 했나요?
기술적으로 매우 깊었어요. 인터프리터 내부도 많이 다뤘고요. 당시엔 우리 대부분이 그랬죠.
그는 매우 기술적이었죠.
컴파일러도요. AST 도입이나 컴파일러 리워크에 관여했는지는 모르겠네요.
그건 다 제러미였던 것 같아요.
제러미와 함께 누군가가 했던 것 같기도 해요. 예를 들면 그렉 스타인(Greg Stein)? 그도 언급해야 할 이름이고요. 알렉스 마르텔리(Alex Martelli)도요.
그야 물론이죠.
다른 영역이라면… 표준 라이브러리는 훨씬 작았어요.
그랬나요? 아, 그랬겠죠.
모듈 수 자체가 적었죠.
그리고 비동기(asynchro) 패키지도 없었고요.
맞아요. 이메일 패키지도 없었고… 아, XML. Effbot이 많이 했던 게 그거예요. elementtree를 설계한 게 그였던 것 같아요.
맞다. 그래요. 나는 XML을 전혀 쓰는 사람이 아니라서 그걸 완전히 잊고 있었는데, XML은 워낙 많은 분야에서 다룰 필요가 있으니 표준 라이브러리에 뭔가 믿을 만한 도구가 있는 게 좋죠.
네. 다만 단점은, xmlplus를 이용해서 확장 가능하게 만들려 했던 거예요. 기억하나요?
xmlplus가 뭔지 기억이 안 나요.
표준 라이브러리의 XML 네임스페이스 패키지가 있었고, 거기에 elementtree와 Celementtree(더 빠른 C 구현이지만 기능이 약간 다른)가 들어 있었죠. 그리고 elementpath도 있었는데, XPath와 비슷하지만 표준화되진 않았고 XPath만큼 다재다능하지도 않았어요.
그리고 문제는 우리가 XML 네임스페이스를 차지해 버렸다는 거였죠. 그래서 xmlplus를 도입했어요.
아, 맞아요. 그거 정말 좋은 기억이네요.
의도는 표준 라이브러리보다 더 빠르게 움직일 수 있는 무언가로 확장할 수 있게 하자는 거였어요.
맞아요. 그리고 somehow XML 네임스페이스 아래에 계속 있게 하려 했죠. 그게 네임스페이스 패키지를 발명한 이유였는지는 모르겠지만요.
아니요, 네임스페이스 패키지 훨씬 이전이에요.
그때는 훨씬 더 해키(hacky)한 해결책이었겠네요.
작동 방식은 설명할 수 있어요. 난 구글에서 이게 유효하지도 않은 시대 이후로도 굉장히 오래 다뤄야 했거든요.
표준 라이브러리의 xml 패키지는 import될 때, 그러니까 __init__.py에서 _xmlplus를 임포트하려고 시도했어요. _xmlplus는 기본 설치엔 없지만 설치할 수 있었죠. 그러면 _xmlplus 디렉터리를 자기 자신의 __path__에 추가했어요. 그래서 xml 패키지에서 뭔가를 import할 때 그 디렉터리도 검색되게 만든 거죠.
이 방식은 표준 라이브러리를 덮어쓰지 않으면서도 표준 라이브러리를 확장할 수 있었어요. 표준 라이브러리에 새로 추가된 게 있으면 그걸 우선 사용하고, 없으면 xmlplus 패키지에서 가져오는 식이었죠.
오, 흥미롭네요. 패키지가 자기 안에 뭐가 있는지에 대해 자체 검색 경로를 가진다는 그 유연성의 합리적 사용 사례네요. 난 패키지에 그런 검색 경로가 있다는 걸 잊고 있었어요.
구글에서는 모노레포에서 그 유연성을 많이 활용해 왔고, 메타에서도 많이 활용해요. 정말 환영할 만한 기능이죠. 편리하고, 설명하기도 쉽고, 이해하고 추론하기도 쉬워요. 다만 대부분 사람들은 보지 못하는 추가 복잡성이긴 하죠.
그런데 xmlplus 해법은 결국 매우 어색해졌어요. xmlplus 패키지가 유지보수되지 않게 되었고, 더 새 파이썬 버전에선 동작하지 않았는데, 사람들은 여전히 그 기능 일부에 의존하고 있었거든요. XPath는 XML에 추가됐던 것 같고, XSLT는 xmlplus에 추가됐던 것 같은데, 그걸 쓰는 사람들은 xmlplus가 새 파이썬을 지원하지 않으니 파이썬 업그레이드를 못 하게 됐죠.
사실 처음부터 서드파티 패키지를 썼다면 그다지 다르지 않았을 수도 있지만, xml에서 import했다는 사실 때문에 마치 표준 라이브러리 모듈인 것처럼 보였다는 게 문제였어요. 실제로는 아니었는데.
그렇죠. 이해돼요.
더 많은 곳에서 이런 방식을 쓰지 않아서 다행이에요.
맞아요. 표준 라이브러리 모듈인지 아닌지 판별하기가 애매해지는 건 늘 좀 어색하죠.
하지만, XML… Effbot은 어느 시점에 XML에 올인했어요. 구글 들어가기 전엔 특히요.
아, 기업 고객이 XML에 올인했었나 보네요. 보통 사람들은 열정으로 XML을 하진 않죠. 아마 XML 위원회 사람들 정도나.
마르틴 폰 뢰비스(Martin von Löwis).
그야 물론이죠.
유니코드 얘기하면, 닐 노위츠(Neil Norwitz)도요. 귀도 동네에 있는 사람. 아직도 그 동네에 있을 거예요.
네, 좋은 이름들이네요. 후속으로 꼭 연락해 보고 싶어요. 마르틴도 인터뷰해 주면 좋겠고, 크리스티안 하이메스(Christian Heimes)도요.
그는 더 ‘새’ 이름이죠. 당신이 말한 건 20년 전 이야기고, 크리스티안은 5년 전, 10년 전… 내 머릿속에선 그렇게 오래된 사람으로 느껴지진 않지만, 그래도 오래 있었죠.
나는 크리스티안을 2003년 전쯤에 만난 것 같아요.
크리스티안 하이메스를요?
그런 것 같아요. 네덜란드에서 아주 멋진 건물에서 열린 Zope 스프린트에서였는데, 우연히 두 명의 크리스티안 옆에 앉았던 기억이 있어요.
티스머(Tismer)랑 하이메스?
아니요. 티스머는 Zope 쪽이 아니었으니까요.
맞다, 맞다. 아, 그리고 그건 또 다른 이름이네요. 확실히 ‘그 이름’이 아니네요(=확실히 다른 이름이네요). 그리고 다른 크리스티안은 성을 기억 못 하는데, 둘 다 독일인이었고 둘 다 크리스티안이었어요. 그리고 다른 한 명이 하이메스였던 게 꽤 확실해요.
그렇군요. 그땐 아주 어렸겠네요.
좋아요. 그럴 수도 있죠. 그렇다면, 당신은 완전히 독학인가요?
네.
와.
사실 난 고등학교 중퇴예요.
와. 축하해요. 정말 대단하네요.
부모님은 내가 중퇴했을 때 기분이 좋지 않았죠. 하지만 중퇴한 이유가 일이 있었기 때문이에요. 처음엔 지역 병원에서 단순한 일을 했고요. 부모님은 “1년 뒤에 학교로 돌아가겠지”라고 생각했죠. 그런데 디지털 시티에서 일하게 됐고, 그다음에 XS4ALL에서 일하게 됐고, 그리고 구글로 갔죠. 그러자 부모님도 “아, 얘는 학교로 안 돌아가겠구나”가 됐죠. (Guido 웃음)
빅테크에서 일하면서, 당시 교수였던 아버지를 포함해서 부모님 두 분이 번 돈을 합친 것보다 더 벌었거든요. 학위가 없는 건 여전히 마음에 들지 않았겠지만, 그 시점 이후로는 솔직히 더 이상 신경 안 쓰셨죠.
다행이네요.
내 조카가 그걸 문제 삼은 적이 있어요. 조카의 아들이 학교를 그만두고 싶어 했는데 “토머스 봐, 학교 필요 없어”라고 나를 예로 든 거죠. 그래서 내가 “아니, 아니, 아니”라고 말해야 했어요.
나는 업계가 “일을 할 수 있는 사람”이라면 누구든 받아들이던 독특한 시대에 있었고, 내가 일을 할 수 있었던 거예요. 지금은 그렇지 않아요. 그러니 학교를 끝내야 한다고요.
맞아요. 나도 항상 “중퇴하지 마라. 대학도 중퇴하지 마라”라고 말해요. 그러면 다들 “하지만 스티브 잡스는!”이라고 하죠.
아니요. 아니에요.
XS4ALL에선 웃긴 게… 내가 19살이나 20살에 시작했는데, 대부분 사람들이 그 또래거나 조금 더 많았지, 크게 많진 않았어요. 다들 대학 중퇴자였어요. 대학에서 뭔가 하다가, 혹은 대학에서 컴퓨터를 발견하고 재미있는 일을 하려고 중퇴했죠. 난 그들과 비슷했지만…
나도 대학 중퇴를 할 뻔했어요. 파이썬 때문은 아니고, 그냥… 잘 모르겠네요.
컴퓨터죠. IT.
맞아요. 그런데 내 상사가… 나는 대학에서 메인프레임 지원팀에서 파트타임으로 일했는데, 그 상사가 먼저 졸업하라고 설득했어요. 그땐 내가 신경도 안 썼던 걸 그 사람은 알고 있었죠. 지금은 그때 졸업하게 한 게 정말 기뻐요. 그 사람은 그게 커리어에 훨씬 도움이 될 거란 걸 알았던 거죠.
네.
이력서에 그 한 줄이 더 있는 것.
네. XS4ALL에서 함께 일하던 사람 중 한 명은… 기억이 정확하진 않은데, 한 시스템 관리자 친구의 친구였어요. 그 관리자가 “이 사람은 시스템 관리에 소질이 있다”는 걸 알고 있었죠. 그녀는 대학으로 돌아가고 싶었지만 당장은 어려움이 있었고, 우리랑 1년 일했어요. 지금은 다른 대학에서 양자 암호(quantum crypto) 교수예요. 그러니까, 이렇게 했다가 학교로 돌아갈 수도 있지만, 정말 정말 드문 일이죠.
이제 거의 한 시간이 됐네요. 마지막으로 하고 싶은 말이 있나요? 갑자기 떠오른 것 같은.
PSF도 놓치면 안 된다고 생각해요. 그리고 거기엔 약간의 ‘구원’이 있어요. 코어 개발 초기에 비해 PSF 초기에 대한 기록이 더 많거든요. 초기 몇 년간의 이사회(board) 멤버 목록을 보면, 몇몇 이름이 더 떠오를지도 몰라요.
네.
누가 이사회에 있었는지 기억하려고 해 보는데… 나는 이사회에 있었고, 당신도 있었고.
20명 넘게 있었죠.
아니요, 이사회는 5명이나 7명이었어요.
아, PSF 이사회(board) 말하는 건가요?
네.
아, 내가 헷갈렸네요. 나는 창립 멤버(founders)를 말하는 줄 알았어요. 아니, PSF를 말한 거였어요.
그러니까, PSF 회원(members)을 말한 거죠.
혹시 우리는 회원이었고, 이사회가 없었던 건가요?
아니요, 시작부터 이사회가 있었어요. 그건 그렉 스타인이 꼭 필요하다고 했어요. PSF를 공식적으로 만든 회의를 기억해요. 그리고 바로 이사회 선거를 했죠. 자리 수는 5석이나 7석이었던 것 같아요. 7석이었나? 그게 몇 년이었죠? 2001년이었어요. L.A.였어요. 국제 파이썬 컨퍼런스(IPC)에서요.
정말요.
네. ActiveState가 여러 걸 후원하고 있었거든요. 데이비드 애셔(David Ascher)도 목록에 넣을 좋은 이름이에요.
맞아요, 맞아요.
에릭 레이먼드(Eric Raymond)도 있었어요.
네.
생생히 기억하는데요. 이사회 선거가 있었고, 나는 이사회에 출마했고, 에릭 레이먼드도 출마했어요. 6명이 당선됐고, 7위가 동점이었는데 그게 에릭 레이먼드와 나였어요. 그가 결투(shootout)를 제안했죠. 장난스럽게 총 결투를 하자고요. 그게 그의 스타일이니까요.
그러자 귀도가 “파이로 하자”고 했고, 그렉은 “아니, 그냥 한 번 더 투표하자”고 했고, 결국 내가 이겼죠. (Guido 웃음)
그리고 PSF 초창기에는 수입을 어떻게 만들지, 기업들이 파이썬을 지원하게 하려면 어떻게 해야 할지 같은 이야기를 많이 했어요. IRS 지위(면세 지위)도 그렇고, 뭘 해야 하는지도요.
내가 어느 시점에 총기법이나 총기 규제 같은 것에 비유를 들었던 적이 있는데, 당신이 답장으로 “에릭 레이먼드가 아니라 당신이 당선돼서 정말 다행이다”라고 했던 게 기억나요.
(웃음) 재밌네요. 내 기억은 좀 달라요. PSF 창립 멤버가 20명 정도, 22명 정도였던 것 같아요. 대부분 코어 개발자였고요.
전부 코어 개발자였어요. 그냥 코어 개발자들.
전부 코어 개발자였을 수도 있겠네요.
뭐, 그때 그런 개념이 있었는지 모르겠지만요. 커밋 권한(commit bit)이 있는 사람들. 아마 커밋 권한이 있는 사람은 모두 PSF 창립 멤버가 될 수 있었던 것 같아요.
25명 미만이었던 걸로 기억해요.
아마 LA의 IPC에 실제로 올 수 있었던 사람들만이었을 수도 있죠.
어디였는지는 기억이 안 나는데, IPC 중 하나였다는 건 거슬러 올라가면 알 수 있을 것 같아요. 그런데 내게 가장 두드러진 기억은, PSF를 실제로 굴리려면 해야 할 실무가 엄청 많았다는 거예요. 예를 들어 501(c)(3) 등록 같은. 그래서 첫 해에 ActiveState의 딕 하트(Dick Hardt)가 있었는데, 그는 “나는 사업가다. 이런 건 내가 맡겠다. 어떻게 하는지 안다”라고 했어요. 그런데 1년 동안 아무것도 안 했죠. 그래서 1년 뒤에, 여전히 IPC에서, 리부트가 있었어요. 그게 LA는 아니었을지도요.
첫 번째는 LA였어요. 딕 하트도 기억하고요. 그 다음 해 IPC에는 나는 안 갔어요. 그게 마지막 IPC, 마지막 ‘진짜’ IPC였죠.
그게 마지막이었죠.
그리고 그 다음 해에는 대신 PyCon US가 있었죠. 기술적으로는, Perl 컨퍼런스의 일부로 IPC가 남아 있었던 것 같아요. 오라일리(O’Reilly) 컨퍼런스였나.
IPC라는 브랜드는 오라일리 오픈 소스 컨퍼런스에서 별도 트랙으로 옮겨갔죠. 나도 몇 번 참석했을 거예요.
나도 한 번 갔던 것 같아요.
**결국 그건 진짜 파이썬 컨퍼런스는 아니었죠. 그리고 PSF는 첫 PyCon에서 엄청나게 중요한 역할을 했어요. 기업 회원 또는 스폰서 회원들에게 연회비로, 얼마였더라, 연 3,000달러 정도를 내 달라고 했고, 파이썬을 정말 아끼던 아주 작은 회사들이(대부분은 지금은 오래전에 사라졌지만) 그 돈을 2년 동안 냈어요.
우리는 비용이 없었으니 아무 데도 쓰지 않았고, 그래서 은행에 현금이 쌓였죠. 그리고 팀 피터스가 어느 시점에 501(c)(3) 관련 일을 챙겼던 걸로 기억해요.**
닐 노위츠였던 것 같아요. 닐이 이사회에도 있었고, 한동안 서기(secretary)였죠.
맞아요. 그는 아주 오래 서기였죠.
팀 피터스는 IRS 서류에서 ‘대중의 폭넓은 지지(public support)’를 보여주는 부분을 몇 년 동안 처리했어요. 한 회사나 소수 회사만이 아니라, 폭넓은 공적 지지가 있어야 했거든요. 자금의 규모와 다양성에 대해 특정 공식을 적용해야 했고요.
IRS가 처음 5년 정도는 그 부분을 매우 엄격하게 봤던 것 같아요. 그래서 매년 “우리가 폭넓은 지지를 받고 있다”는 걸 보여줘야 했죠. 누군가의 앞잡이(shill)가 아니라는 걸요.
맞아요. 우리는 5년짜리 임시 501(c)(3) 승인을 받았죠. 어느 순간 다들 그 사실을 잊었고, 제대로 갱신하려고 난리가 났어요. 그 이후로는 IRS가 우리를 내버려뒀는데요. 팀도 거기서 역할을 했던 것 같아요.
그럴 가능성이 크죠.
첫 PyCon 이야기를 알고 있나요? 내 기억으로는 이런데요. 어떤 사람이 내게 전화해서 말했어요. “당신들이 예전 파이썬 컨퍼런스 주최 측이 제공하던 인프라 없이, 파이썬 컨퍼런스를 조직하려고 할 텐데…”
Fortec.
**…그가 말하길, Perl 컨퍼런스 혹은 Perl 언컨퍼런스 같은 걸 위해 장소를 예약해뒀는데, Perl 관련 행사를 하려는 사람이 너무 많아져서, 그 장소를 Perl에 쓰는 걸 포기했다고 했어요. 대신 당신들이 원하면, 그 주에 그 공간을 쓸 다른 사람이 없다는 걸 아는 자신이 연결해 줄 사람들이 있다고요.
아마 타이밍이 맞았던 거죠. PSF에는 계약금으로 요구한 돈을 낼 만큼의 돈이 막 있었고… 그리고 그때 내가 케이터링 비용이 얼마나 비싼지 처음 알게 됐어요.**
그리고 그게 조지 워싱턴 대학교였죠?
정말 좋은 장소였죠.
점심은 도시락(팩 런치)였던 걸로 기억해요.
그건 내 잘못이에요.
아니요, 난 좋았어요.
점심에 다양성이 없었던 게 내 잘못이죠.
아, 그런 의미군요.
채식 도시락을 따로 주문한다든지, 등록할 때 선호 식단을 받는다든지 하는 걸 생각도 못 했던 것 같아요.
네, 그런 건 고려되지 않았던 것 같아요.
그리고 등록(registration) 업무를 자원봉사자가 다 해주겠다고 했는데, 컨퍼런스 당일 엄청 늦었어요. 아마 우리가 생각했던 것보다 좀 더 혼란스러운 사람이었던 것 같아요. 장비를 전부 차에 싣고 있었는데, 정오쯤 돼서야 도착했죠. 스티브 홀든이 굉장히 패닉이었어요. 그래도 somehow 해결됐죠. 스티브에게 물어봐야겠어요.
그리고 오늘은 여기까지입니다. 고마워요, 토머스!
