토마스 보우터스 인터뷰

← 모든 글

2026년 2월 28일

서문

나는 인터뷰라는 문학적 형식을 늘 좋아했고, 언젠가 직접 해보고 싶었다. 마침내 그 동기를 얻게 된 계기는 다음과 같다. 최근 유튜브에서 파이썬에 관한 훌륭한 다큐멘터리가 공개되었다. 시사회가 끝난 뒤, 몇몇 올드타이머들이 영화에 언급되지 않은 파이썬 개발자와 기여자들을 추억하기 시작했다. 그때 깨달았다. 내 시각을 통해 전해진 파이썬 구술사(특히 컴퓨터 역사 박물관이 철저하게 진행한 것)는 있지만, 커뮤니티의 다른 구성원들이 자신의 이야기를 전할 기회는 거의 없었다. 나는 이 시리즈를 통해 모든 핵심 개발자와 다른 기여자들이 직접 이야기하게 함으로써 그 공백을 메우려 한다. 물론 여전히 내 시각을 거치지만, 최대한 인터뷰 대상자가 말하도록 두려 한다.

왜 팟캐스트가 아니냐고 묻는다면? 나는 그 매체를 존경하지만, 제작자로서든 소비자로서든 글을 훨씬 선호한다.

범위

나는 2015년을 임의의 기준연도로 삼았다. 그해까지 파이썬 커뮤니티에 참여하지 않았다면, 그 참여는 너무 최근이라 '역사'라고 보기 어렵다. 나보다 뒤에 온 누군가가 젊은 세대를 인터뷰할 수 있겠지만, 나는 파이썬의 첫 25년으로 한계를 짓고 싶다.

토마스 보우터스

첫 번째 인터뷰 대상자는 토마스 보우터스다. 그는 파이썬 커뮤니티에서 정말 다양한 역할을 맡았다. 확장 할당(augmented assignment, += 연산자 등) 구현부터 PSF 이사회, 파이썬 운영위원회, PSF 대행 이사, 자유 스레딩 작업까지. 다음은 우리 대화를 요약하고 다듬은 것이다. 둘 다 추억을 나누는 재미를 느꼈다고 생각한다! (참고로 두 네덜란드인이 영어로 대화하는 것을 듣게 될 것이다. 토마스와 내가 업무 이야기를 할 때 늘 그렇고, 업무가 아닐 때도 종종 그렇다.)

귀도: 파이썬을 처음 접한 계기와 그것이 기여할 만한 재미있는 곳이라고 생각하게 된 이유를 말해줘.

토마스: 처음 접한 건 코모도어 64 베이직 외에 처음으로 진짜 프로그래밍 언어를 배웠던 람다무(LambdaMOO) 때문이야. 월드 와이드 웹 이전 인터넷 세상의 온라인 커뮤니티이자 텍스트 기반 다중 사용자 던전이었지. 내가 그만큼 나이가 많다는 뜻이야. 십대였지만 말이야. 인터넷이었지 유즈넷 같은 그 이전의 무언가는 아니었어. 마침 92, 93, 94년경에 월드 와이드 웹이 개발되던 시기였어.

암스테르담에는 '디지털 시티(Digital City)'라는 아주 흥미로운 프로젝트가 있었어. 기본적으로 사람들에게 인터넷을 소개하는 프로젝트였지. 첫 번째 버전은 고퍼(Gopher)를 사용했고, 그 일환으로 '디지털 메트로'라는 람다무 인스턴스가 있었어. 암스테르담 지하철을 모델로 한 지하 세계였고, 그 자체가 프로그래밍 환경이었지. 다중 사용자 텍스트 기반, 거의 게임 같지만 게임은 아닌 곳에서 람다무 언어로 프로그래밍할 수 있었어. 그리고 람다무 언어는 파이썬과 아주 비슷했어.

어떻게 그렇게 됐지? 그냥 평행 진화였다고 봐. 구문상으로는 그다지 비슷하지 않고 중괄호를 사용했지만, 개념적으로 '모든 것이 객체(everything-is-an-object)'라는 모델이 아주 비슷했어.

동적 타입?

동적 타입도 곳곳에 있었지. 람다무를 사용한 다른 누군가도 들은 적이 있어.

오, 원래 트위스티드(Twisted) 개발자들이 다 람다무 키드였다는 걸 알게 될 거야.

오, 물론 그들과도 이야기해야지.

나는 람다무에서 펄과 C로 옮겨갔어. 람다무가 아닌 다른 머드(MUD)에도 참여했고. 여전히 십대였나?

엄밀히 말하면 십대였지만, 네덜란드의 한 ISP에서 일하고 있었어. 디지털 시티에서 일하기 시작했고, 그다음에 디지털 시티를 설립한 회사인 XS4ALL에서 일하기 시작했어. 거기서 11년 동안 시스템 관리자로, 나중에는 소프트웨어 개발자로도 일했지.

하지만 취미 시간에 여전히 다양한 머드를 많이 했어. 그중 하나에서 누군가가 파이썬을 소개해줬어. 너는 람다무를 좋아하니까 이 언어도 마음에 들 거라고. 1998년이나 99년쯤이었던 것 같아. 처음에는 진지하게 받아들이지 않았어. 펄을 배우느라 너무 바빴고, 펄이 얼마나 싫은지 깨닫고 있었거든. 그러다 어느 시점에 펼쳐봤는데 금방 알겠더라고. 내 뇌에 딱 맞는다는 걸. 생각할 필요가 없고, 자동으로 이해가 돼. 다른 어떤 프로그래밍 언어보다 훨씬 더. C도 꽤 좋아하고 C의 모든 함정도 좋아하고, C와 C++에 아주 편안하고 자바와 PHP도 꽤 편하지만, 파이썬은 그냥 재미있고 즐겁고 말이 돼.

물론 그때는 유즈넷 시대였지. 파이썬 리스트, 음, 이메일 리스트 게이트웨이도 있었어. 파이썬 리스트를 구독하고 사용하면서 많은 걸 배웠어. 게시물을 따라가면서. 특히 팀 피터스(Tim Peters)의 게시물을 읽으면서.

파이썬 리스트를 처음 구독했을 때 인상 깊었던 사람들과 그 당시 분위기에 대해 더 말해줘.

글쎄, 분명 팀 피터스와 프레데리크 룬드(Frederik Lundh)야. 내가 기억하는 다작 게시자들이었어. 팀은 토론에 참여하고 자신의 관점을 제시하는 데 항상 매우 열정적이었고, 사람들이 참여하도록 유도하는 방식으로 설명했어. 더 많은 기여와 더 많은 토론을 이끌어냈지. 유즈넷에서는 정말 그게 다였잖아. 토론하고 또 토론하고 또 토론하는 거. 유즈넷에서 할 수 있는 건 기본적으로 토론뿐이었어.

모든 토론이 플레임 워(flame war, 감정적인 논쟁)로 변하지 않는 게 항상 좋지.

그럼. 물론 그런 것도 있었지만, 보통 파이썬 쪽에서는 일어나지 않았어. 비록 누군가가 와서 파이썬을 10배나 100배 빠르게 할 수 있다고 제안한 사람이 기억나긴 해. 파이썬 자체에 대한 실제 이해는 없이, 오 우리가 다른 언어로 이걸 했으니 파이썬으로도 할 수 있다는 식이었지.

그게 누구였지?

기억 안 나. 너무 오래됐어. 뭔가 간단한 걸 할 수 있다고 생각한 사람들이 꽤 있었어. 이건 작업을 보여주기 전에 미리 돈을 받고 싶어 했던 경우 중 하나였던 것 같아. 파이썬 리스트에서 산산조각이 났지. 아무도 진지하게 받아들이지 않았거든. 하지만 파이썬 리스트에서 적대적인 경우는 드물었어. 대체로 아주 친절하고 환영하는 분위기였으니까.

또 기억나는 사람은 마이클 허드슨(Michael Hudson)이야.

그래. 그가 패치를 올렸어. 이 작업을 시작했다. 확장 할당의 개념 증명이 여기 있다. 이걸 추가하는 패치가 얼마나 간단한지 놀랐어.

그게 +=, -= 등이지.

파이썬에 추가하는 게 얼마나 쉬웠는지. 그게 나에게 파이썬 구현을 살펴보게 만들었어. 그다음 그 패치를 가져와서 완성했어. 마이클은 할 수 없었거든. 시간이 없었거나 흥미가 없었거나, 모르겠어. 그는 프로젝트 시작가는 프로젝트 완성가보다 더 많았지.

그래. 그리고 몇 년 동안 마이클은 자신의 파이썬 주요 기여가 나를 핵심 개발로 끌어들인 것이라고 말했어.

(귀도 웃음.)

왜냐하면 그게 나를 파이썬-데브 리스트에 있게 만들었고, 기본적으로 귀도가 그 패치를 완성하도록 멘토링했으니까. 내가 하기에 너무 두려웠고 여전히 확신하지 못하는 특정 설계 결정을 귀도가 했어. 리스트에서 +=가 작동하는 방식 같은 거.

모든 타입이 어떻게 할지 결정할 수 있고, 새 객체를 생성하거나 기존 객체를 제자리에서 수정할 수 있어. 그리고 파이썬에서 내 직관은 초기부터 리스트와 일반적으로 컬렉션, 딕셔너리가 단순 값과는 다른 '중요성(significance)'을 사용자에게 가진다는 것이었어. 문자열까지의 단순 값은 모두 불변이었지만, 리스트와 그 외 모든 것은 가변이었지. 튜플은 그 중간에 있었고.

돌이켜보면 동의하지만, 이상한 코너 케이스가 있잖아? 튜플이 있고 t[0] += something을 한다고 하자. 그러면 튜플의 첫 번째 항목이 리스트라면, +=는 리스트를 수정하고, 그다음 튜플은 불변이므로 그 튜플 항목에 할당할 수 없다는 예외를 발생시켜. 하지만 리스트는 이미 변경된 상태지.

아, 그래. 그건 합리적인 의미론의 정상적인 결과지만, 그 의미론을 합치면 최종 결과는 놀라워. 더 나은 대처 방법은 없다고 봐. 린터(linter)의 영역이지. 이런 종류의 일은 하지 말아야 해. 놀라운 결과를 낳을 테니까.

글쎄, 코드를 실행하면 바로 알게 돼. 그 시절에는 작성한 모든 코드가 즉시 실행될 가능성이 훨씬 높았어.

그래, 맞아. 지금은 코드가 너무 많아서 모든 줄을 건드리는 데 시간이 걸려.

+=가 항상 복사본을 만들어야 한다면, 나는 리스트에서 아예 지원하지 않고 .extend()를 사용한다고 했을 거야. 그건 튜플 케이스에서도 작동하니까. 그리고 예상되는 일을 하고.

아니, 기억이 맞다면 그때 귀도의 주장은 이랬어. 리스트에서 이걸 하지 않으면, +=가 제자리 할당을 하지 않으면, 상황에 따라 타입이 자신의 일을 하도록 열어두지 않으면, += 자체에 가치가 없어. 그냥 +를 위한 구문적 설탕(syntactic sugar)이니까. 우리는 구문적 설탕만을 위해 이걸 추가하는 게 아니야. 가변 타입에서 새로운 효용이기 때문에 추가하는 거야.

그게 파이썬 자체 개발에 대한 나의 입문이었어.

그게 귀도의 큰 기여였다고 기억해.

그랬지. 초기에.

그래. 그것도 귀도와 파이썬랩스(PythonLabs) 팀이 비오픈(BeOpen)에서 시작한 시기와 거의 비슷했던 것 같아.

오, 그러면 2000년이었군.

2000년이었어. 1.6이 아니라 파이썬 2.0에 넣은 것 중 하나였지. 1.6 릴리스와 2.0 릴리스를 구별하기 위해서. 2.0을 위한 작은 당근 같은 거.

그리고 이게 PEP 204, 아니면 PEP 203이었던 것 같아.

[203이었어. –귀도]

오, 아주 초기네.

아주 초기였지, 그래. PEP 아이디어가 나오기 훨씬 전부터 작업을 시작했어. 내용 PEP는 200에서 시작했던 것 같아. 100은 프로세스나 특별한 것이었고.

내 것이 파이썬랩스 사람들이 쓰지 않은 최초의 PEP였다고 생각해. 그다음 것도 내가 가졌지. 범위 리터럴(range literals)에 관한 것이었는데, 내가 가장 좋아하는 PEP야. 왜냐하면 거부됐으니까.

그게 왜 가장 좋아하는 거지?

그 아이디어를 내는 과정이 좋았거든. 내 아이디어는 아니었어. 다른 언어에 비슷한 구조가 있어서 오랫동안 떠돌던 아이디어 중 하나였지. range 내장을 대체하는 범위의 구문이야. 그리고 기본적으로 오래된 xrange 내장을 대체하는 거지. 현재의 range 내장을 말이야. 하지만 당시에는 range가 전체 리스트를 반환하는 함수였고, 그 구문은 대신 전체 리스트를 인스턴스화할 필요가 없는 인덱싱과 의미론을 가진 범위 객체를 반환했어.

그 구문이 마음에 들었지만, 문맥상 약간 혼란스러웠어. 범위를 반복하는 것이 많은 콜론을 포함하니까. 그게 혼란스러웠어.

설계한 표기법이 어떠했는지 기억해?

대괄호였어. 대괄호, 시작점, 콜론, 끝점, 닫는 대괄호. 그리고 스텝(step)도 고려했던 것 같아. 그래서 리스트처럼 보였지만 리스트는 아니었지.

글쎄, 리스트 인덱스처럼 보였어. 범위 리터럴을 원한다면 그게 처음 시도할 자연스러운 표기법이야. 최소한 하나의 콜론이 있어야 하니까, 현재 유효한 리스트는 아니거든.

재밌었어. 패치를 썼거든. 파싱하는 것이 리스트인지 범위인지 콜론을 볼 때까지 결정하고 기본적으로 마음을 바꾸는 것을 의미하니까 재밌었어.

오, 그리고 원래 파서는 현재 파서보다 그것을 처리하기가 훨씬 어려웠어. 그래서 구현하고 설계하는 게 재밌었고, 그다음 거부됐어. 그리고 올바른 선택이라고 생각해. 오해하지 마. 우리가 아이디어를 가질 수 있고, 좋은 아이디어라고 생각하고, 끝까지 작업하고, 그다음 음, 사실 이건 말이 안 돼. 단점이 너무 많거나 혼란스러운 상황이 너무 많아. 변경과 혼란을 정당화할 만큼 큰 이익이 되지 않아. 하지 말자고 말할 수 있다는 사실을 즐길 뿐이야.

그게 나가 말한 거였나, 다른 사람들도 반대했나?

그룹 합의였던 것 같아. 하지만 당시 그룹은 아주 작았어. 많은 사람들이 어느 쪽이든 관심이 없었고, 이게 절대적으로 올바른 일이라고 말하는 사람이 충분하지 않았어. 그리고 이거 잘 모르겠는데라고 말하는 사람은 충분했지.

강력한 반대는 없었던 것 같아. 하지만 당시에는 강력한 반대도 꽤 드물었어.

사실 이건 역사 인터뷰를 위한 약간의 토끼굴(rathole)이지만, 그 구문에 대괄호를 사용하는 것은 리스트를 반환한다고 강하게 암시할 거라고 상상해.

그래. 그건 우리가 배운 것인데, range가 하기에 올바른 일이 아니지.

그래, 그게 일부였다고 생각해. 아마 무서운 잘못된 기능(misfeature)을 피한 셈이지.

그렇게 생각해. 당시에는 그 일부가 컴파일러가 범위 객체가 사용되는 곳을 보고 똑똑해질 것이라고 예상했던 거야. 예를 들어 범위를 반복하면 루프 언롤링 같은 것에 아주 똑똑하게 처리하는 거지. 우리는 실제로 그렇게 하려고 신경 쓰지 않았고, 여전히 루프 언롤링은 하지 않아.

글쎄, 적어도 for something in 그다음 정확히 범위 리스트인 상황을 특수 케이스로 처리할 수 있었겠지.

�프 언롤링 같은 걸 아주 똑똑하게 한다던가. 우리는 그걸 진지하게 하지 않았고, 지금도 루프 언롤링은 정말 안 해. 음, 보니까 적어도 for something in 다음에 정확히 range 리스트가 오는 상황은 특수 처리할 수 있었겠네. 맞아, 그렇지. 그러면 xrange 객체를 생성했다는 걸 아무도 알 수 없었을 거야. 그래. 하지만 우리는 다른 경우에도 그걸 쓰고 실망했겠지. 그래, 그래.

그리고 최적화 아이디어는 당시에 매력적이었어. 파이썬이 매우 느리다고 알려져 있었으니까. 수년에 걸쳐 훨씬 좋아졌지만, 당시에는 차이가 더 눈에 띄었고 지금만큼 진보하지 않았어.

그렇다면 그 당시 파이썬-데브 리스트에서 토론하던 주요 인물들은 누구였어? 물론 팀도 있고.

이 부분은 내가 아는 건데, 아카이브가 있어서 2주 전에 아카이브를 봤거든. 거기에 몇몇 이름이 있었는데 나는 알아보지 못했고 그들이 참여했다고 기억하지도 않아. 하지만 눈에 띄는 사람들은 팀 피터스, 앞서 언급한 프레더릭 룬드, 커뮤니케이션과 관련된 거라면 프레드 드레이크(Fred Drake). 그래, 그는 문서 작업도 많이 했지. 그래. 문서에 집중했다고 기억해. 제러미 힐튼(Jeremy Hylton), 배리 워소(Barry Warsaw). 나는 파이썬-데브 리스트에 합류하기 전에 배리를 알았어. 일 때문에 메일맨(Mailman) 작업도 했거든. 그리고 나는 배리와 항상 잘 지냈어, 그래서 그는 파이썬에서 환영하는 목소리였지.

아, 흥미로운 연결이네. 그리고 제러미는 주로 컴파일러 작업을 했고 중첩 스코프 같은 걸 도입했어. 우리가 중첩 스코프를 추가하려고 하위 호환성을 깨야 할지 말아야 할지에 대해 길고 긴 논쟁을 했던 게 기억나. 결국 팀 피터스가 __future__ 임포트를 제안했던 걸로 기억해. 그게 내가 가장 좋아하는 또 다른 상호작용이야.

오, __future__ 임포트가 중첩 스코프 논의에서 나왔다고 생각하는 거야. from __future__ import nested_scopes라고 쓸 수 있게 말이야. 그래. 이제 그 문구가 익숙하게 들리네. (웃음.) 그래, nested_scopes가 첫 번째 __future__ 임포트였어. 꽤 확실해. 팀 피터스가 __future__ 임포트의 원동력이었다는 건 확실해.

나는 2006년에 구글에서 일하기 시작했어. 그리고 제러미는 이미 구글에서 몇 년 일하고 있었지. 그는 아직도 구글에 있어. 작년이나 그전년인가 그를 만났는데, 그가 2001년에 우리가 중첩 스코프에 대해 가졌던 논쟁과 그 논쟁에서 __future__ 임포트가 나왔다는 이야기를 꺼냈어.

논쟁의 내용은 정확히 뭐였어? 지금은 상상하기 어렵지만, 중첩 스코프가 그냥... 그래, 거의 25년 동안 언어에 있었으니까. 하지만 당시에는 함수 안에 함수를 정의하면, 안쪽 함수에서 바깥쪽 함수의 변수를 참조할 수 없었어. 전혀. 네임스페이스가 완전히 보이지 않았어. 그래. 바깥쪽 함수의 어떤 이름도 참조할 수 없었지.

람다는 어땠어? 람다도 마찬가지였어, 그래. 그래서 바깥쪽 스코프에서 쓰고 싶은 건 뭇든 다 넘겨줘야 했어. 분명히 이건 제약이었지. 심각한 제약였어. 모두가 이 제약 때문에 할 수 없는 게 많다는 데 동의했어. 그리고 제러미가 그걸 고칠 방법을 찾았어.

음, 그건 중첩 함수를 이등 시민으로 만들지. 그래, 쓸모없게 만들지. 그냥 네임스페이싱 문제야. 바깥쪽 네임스페이스가 아니라 안쪽 네임스페이스에 정의하지만, 함수가 할 수 있는 일은 아무것도 바뀌지 않아. 그래, 그리고 그 고전적인 리스프 예제가 있잖아. 인자에 n을 더하는 함수를 반환하는 건데, 그 n을 전달할 방법이 없지.

그러니까 논쟁은 중첩 스코프를 추가할지 말지가 아니었어. 항상 '이건 환상적인 변화야. 정말 많은 걸 가능하게 할 거야'였지. 얼마나 멀리 갈지 아무도 몰랐겠지만, 중첩 스코프는 이제 너무 근본적이니까. 모든 데코레이터 같은 게 그 위에 쌓여 있잖아. 맞아. 하지만 우리는 모두 동의했어. '이건 좋은 거야.' 하지만 하위 호환성을 깨는 변화였어. 이미 중첩 함수가 있었는데 변수가 있으면... 그러니까... 음, 알겠어. 바깥쪽 함수에 의해 가려진 글로벌을 참조하면, 바깥쪽 함수에 같은 이름의 지역 변수가 있으니까, 안쪽 함수는 갑자기 완전히 다른 동작을 하게 되지. 그래.

그래서 우리는 그 문제를 오래 논의했어. 하위 호환성을 깨는 게 가치가 있는가? 하위 호환성을 일반적으로 어떻게 접근할 것인가? 제러미는, 음, 만약 당신이... 나는 이게 파이썬 개발의 전문화이기도 하다고 생각해. 더 이상 자신의 코드만 생각하는 게 아니라, 다른 사람들이 파이썬을 어떻게 배포하는지 생각하는 거지. 자신의 코드를 위해서가 아니라. 그러니까 그전에는 우리 모두 '오, 내가 파이썬을 빌드하고, 그리고 내가 파이썬을 쓰고, 내가 빌드한 버전을 써'라고 생각했던 것 같아.

나는 시스템 관리자였어. 사용자를 위해 파이썬을 빌드했고, 그들은 기업 사용자였지. 그래서 그들을 망가뜨릴 수 없었어. 내가 새로운 파이썬을 배포해서 고객의 파이썬 코드를 망가뜨리면, 고객은 나한테 화를 낼 거야. 그래서 그게 새 버전을 배포하는 걸 막았지. 그래서 내가 하위 호환성을 그렇게 강조했던 거야. 그리고 지금도 그래.

그래, 2000년대 초반에는 그게 계속되는 논쟁이자 문제였던 걸 기억해. 스티브 홀든(Steve Holden)이 어느 총회에서 일어나서, 무대 위의 사람들에게(아마 나였겠지, 아니면 핵심 개발자 무리였겠지), 파이썬이 너무 빨리 변하고 있으니 어떻게든 약속을 하고 새 기능이 있는 릴리스를 너무 자주 내지 말아야 한다고 말했던 게 기억나.

당시 타협안은 18개월이었어. 그리고 아주 오랫동안 그걸 유지했지. 루카스(Lukasz) 이후의 두 릴리스, 아니면 운영 위원회가 시작된 후? 아니, 우리는 3.9에서 연례로 전환했어. 3.9 이후인 것 같아. 3.9가 언제였는지 기억 안 나지만, 운영 위원회가 맡은 후였던 건 꽤 확실해. 그래. 왜냐하면 운영 위원회가... 선거 주기가 문자 그대로 릴리스에서 릴리스까지로 정의되어 있었거든. 그래. 그리고 어느 시점에 모두가 동의했지. '그래, 우리는 많은 다른 대규모 오픈소스 프로젝트와 동기화하려면 연례 릴리스를 해야 해.' 그리고 갑자기 깨달았어. '오! 운영 위원회도 불규칙하게 대신 매년 선출되네!' 하지만 스티브가 불평하기 전에도 우리는 포인트 릴리스에 새 기능을 추가하는 데 꽤 느슨했어. 내가 그걸 해먹은 마지막이... 기억나? 음, True와 False가 2.2.3에 추가된 거. 그런 거. 당시에는 좋은 일처럼 느껴졌지만 좋은 교훈이었어. 여파가 최소했거든. 그냥 사람들이 참고 넘길 수 있는 성가심이었지. 그리고 그게 그렇게 좋은 일이 아니라는 걸 보여줬어. 나쁜 트레이드오프였지.

그래, 그게 문제였어. 완전한 버그를 제외하면, 2.n.1과 2.n... 훨씬 높은 숫자는 항상 앞뒤 호환성이 있어야 했거든. 그래, 지루한 버그 문제야. 그게 어렵게 만들지. 하지만 그래. 하지만 지금은 상대적으로 잘하고 있어. 버그가 고쳐져야 한다면, 보통 아주 적은 수의 사람들에게만 영향을 미치지. 물론 상대적으로 말이야. 아마 2000년대 초보다 훨씬 더 많은 사람들에게 영향을 미치겠지만, 사용자가 훨씬 더 많으니까. 릴리스 매니저로서 말하자면, 특정 변경의 영향을 파악하는 건 생각보다 어려워.

오, 그래. 버그 수정을 가능하게 하려면 뭔가를 변경해야 하는데, 그 변경이 예기치 않은 결과를 낳지. 그런 일이 나는 바라는 것보다 자주 일어나. 좋은 해결책을 몰라. 그냥 어려운 문제야.

프레더릭 룬드에 대해 좀 추억해 보자. 그를 인터뷰할 수 없으니까. 그래서 우리가 그에 대해 듣는 건 다른 사람들의 기억뿐일 거야.

기억하건대, 그를 몇 번 직접 만났던 것 같아. 우리는 꽤 오랫동안 구글에 함께 있었지만, 나는 정말... 음, 그는 취리히에 있었거든? 그는 취리히에 있었어. 그는 대부분의 시간을 유튜브 작업을 했던 걸로 기억해. 하지만 일단 그가 구글에 있고 나서는 파이썬 커뮤니티에서 그를 많이 보지 못했어. 그리고 약간의 번아웃도 있었던 것 같아. 그가 이혼했었지? 기억 안 나. 그가 이혼했고, 취리히에 있으면서 딸과 충분한 시간을 보내는 게 스트레스 중 하나였던 걸로 기억해.

기억하건대 그는 Effbot이었어. 팀처럼. 팀은 Timbot이었고 프레더릭은 Effbot이었지. 정말 많은 주제에 대해 정말 많이 글을 썼어. 그리고 그의 관심사는 항상 Tkinter였던 걸로 기억해. 그가 그것과 관련된 일을 많이 했지. 그가 시작한 건 아니었던 것 같아.

시크릿 랩스(The Secret Labs) 정규 표현식 엔진. 오, 그래서 S가 붙은 거구나. 그래. 회사 이름이 시크릿 랩스였어. 그 티셔츠가 기억나. 나는 그 티셔츠를 본 적도 있어. 꽤 지루해. 기업 같아. 음, 그건 직원이 5명 정도인 회사였던 걸로 아는데. 그런 의미에서 기업은 아니었어. 그냥 남색 티셔츠에 흰색의 꽤 작은 로고가 가슴에 있었어.

그리고 시크릿 랩스, 기본적으로 프레더릭은 CNRI에 의해 유니코드 지원을 위해 고용됐어. 1.6에서 유니코드를 지원할 수 있는 정규 표현식 엔진으로 교체하기 위해서였던 걸로 기억해. 오, 고용됐었어? 내 기억엔 그들이 그 작업을 제공하기 위해 고용됐던 걸로 아는데. 그러니까 그 작업에 대한 돈을 받았지. 음, 그들은 최선을 다했어. 우리는 그걸 아주 오랫동안 의존했지. 그들은, 알다시피, 항상 거기 있었어. 프레더릭은 적어도 그걸 지원하기 위해 항상 있었지. 하지만 내 기억에는 CNRI가 그 비용을 냈어. 불가능한 건 아니지. 특히 알 베자(Al Vezza)는 그런 일에 열려 있었거든.

마르크-앙드레(Marc-André)가 알 거야. 내 기억엔 마르크-앙드레 렘부르그(Marc-André Lemburg)도 관여했지만, 정규 표현식 엔진이 아니라 유니코드 구현에 관여했을 거야. 그래서 내 기억엔 마르크-앙드레도 돈을 받았어. 그의 회사가 유니코드 작업의 일부에 대해 돈을 받았지. 하지만 CNRI가 아니었을 수도 있어. 뭔가 다른 곳이었겠지. 하지만 그게 내 기억이야.

그래, 나는 돈의 흐름에 대해 항상 꽤 순진했어. 지금도 그렇다고 생각해. 그래, 초기 파이썬 소프트웨어 재단(PSF) 시절도 기억나. 그래, 마르크-앙드레도 파이썬-데브에서 언급해야겠네. 그는 아주 오랫동안 있었으니까. 아주 오래, 그래.

다른 사람들은... 그러니까 내가 어울리고 상호작용했던 다른 사람들, 언급했던 트위스티드 개발자들. 그건 항상 흥미로웠어. 정말 모셰 자카(Moshe Zadka)는 아니고. 음, 그는 나와 비슷한 시기의 파이썬 핵심 개발자였어. 그는 사실 내가 직접 만난 파이썬 커뮤니티의 첫 번째 사람이었어. 2001년 국제 파이썬 컨퍼런스 전날 엘리베이터에서 우연히 만났거든. 그리고 그다음 날, 내가 만난 두 번째 사람은, 모셰와 내가 엘리베이터에 있었는데, 당신이 들어왔지. 그래서 당신은 내가 직접 만난 파이썬 커뮤니티의 두 번째 사람이었어.

나는 모셰를 인터뷰해야 해. 그리고 직접 할 수 있어. 하지만 다른 트위스티드 개발자들, 글리프(Glyph), 그리고 더 많은 이름을 기억해 보려고 하는데. 거기에 더 많은 이름들이 있어. 그들은 자기 권리로 파이썬 커뮤니티에서 꽤 알려진 사람들이지만, 당시에는 트위스티드 개발자들이 자기들만의 작은 것을 작업하고 있었지. 그들은 파이썬과 꽤 단절돼 있었어.

그래, 내가 기억하는 건(그리고 그건 왜곡된 기억이겠지만), 트위스티드는 글리프의 작품이었다는 거야. 아니, 트위스티드는 큰 프로젝트였어. 알겠어. 음, 글리프가 그 이야기를 훨씬 잘 말해 주겠지만... 음, 나는 그와 이야기할 거야. 그건 자바로 시작됐어. 그의 자바 MUD, 기본적으로 MUD 시도였지? 젊은이들이 여전히 그 텍스트 기반 게임을 하고 있었고, 그는 뭔가를 원했어. 트위스티드 매트릭스(Twisted Matrix), 그렇게 불렸던 것 같은데. 트위스티드 리얼리티(Twisted Reality), 그 중 하나였어.

트위스티드 매트릭스가 익숙해. 트위스티드 매트릭스가 그게 프레임워크인 거지. 그러니까 게임은 트위스티드 리얼리티였을 거야. 그리고 자바 프로젝트로 시작했다가 파이썬으로 옮겼고, 스레드 기반이 아니라 기본적으로 파이썬에 코루틴이 있기 전에 코루틴 기반이었지. 그러니까 기본적으로 콜백 기반이었어.

프로미스(Promise). 음, 디퍼드(Deferred). 오 그래, 디퍼드. 지금 asyncio가 작동하는 방식과 매우 비슷해. 그래. 프로미스, 퓨처, 디퍼드. 모두 같은 아이디어지. 디퍼드는 yield가 없어서 매우 구체적인 속성을 가졌어. 그래. yield from도 없었고, yield도 없었지. yield가 생기자 누군가 기본적으로 디퍼드 위에 코루틴을 구현했어. 인라인 콜백이라고 불렀던 걸로 기억해. 그래서 우리는 asyncio까지 절반 정도 갔던 거지. 그리고 나중에 yield from이 생기면서 그것도 합쳐졌고. 그리고 asyncio가 파이썬 3의 일부가 되면서 기본적으로 트위스티드의 위세를 조금 빼앗았다고 생각해.

그래, 그래. 음, 그건 Zope 인터페이스 같은 사소한 문제들도 고쳤지. 나는 그걸 정말 좋아하지 않았거든. 그래, 나도 그래.

그 시절의 다른 사람들... 음, 스티브 홀든은 이미 언급했고... 아카이브를 봐야 해. 음, 우리는 그냥 아카이브를 보고 이름을 보고... 내가 아카이브를 볼 때 상위 포스터 목록을 모았는데, 거기에 알아보지 못하는 이름들이 좀 있었어. 하지만 실제로 게시물을 읽으면 뭔가 떠오를지도 몰라. 아서 시겔(Arthur Siegel)이라는 이름 기억해? 아니. 흥미롭네. 아마 내가 유일하게 인상을 받은 사람일지도 몰라. 나는 그때 인상받기 쉬웠고, 시간이 지나면서 시니컬해졌으니까, 아마 이름들을 차단해 버렸을 수도 있어. 그때 내가 젊었거든? 더 이상 젊지 않지만. 음, 나한테 넌 항상 젊을 거야.

아서 시겔은 논쟁적인 사람이었어. 내가 기억하는 모든 것에 대해 항상 반대 의견을 가졌고 자신의 의견을 강하게 옹호하는 걸 두려워하지 않았지. 그래서 flame war로 이어지지 않더라도, 여전히 때로는 꽤 고통스러웠어. 나는 아마 그냥 그걸 잊어버렸을 거야. 인터넷이 성장하면서 그런 일이 더 흔해졌고, 나는 그냥 '이건 진지한 사람이 아니거나 흥미로운 사람이 아니야'라고 결정하고 무시해 버렸을지도 몰라.

오, 핑(Ping)도 언급해야겠네. 오, 그래! 반대 의견 때문이 아니라, 그건 핑과 정반대니까. 그저 그 시절에 매우 생산적이고 흥미롭고 흥미로운 아이디어를 가진 사람이었으니까. 나는 그를 인터뷰할 거야. 그도 여기서 로컬이니까. 그리고 거의 1년 동안 못 봤으니, 이제 때가 됐어.

그럼 Effbot이 Tkinter와 정규 표현식 외에 한 다른 일들은 없었어? 음, 그는 꽤 기술적이었으니까 인터프리터 세부 사항에도 꽤 관여했지만, 당시 우리 중 많은 사람이 그랬지. 그는 아주 기술적이었어. 그래. 컴파일러, 그리고 그가 AST의 도입과 컴파일러 개편에 관여했는지는 모르겠어. 그건 다 제러미였다고 생각해. 누군가 제러미와 그 일을 함께했던 게 기억나. 꽤... 그레그 스타인(Greg Stein)이었을까? 그것도 언급해야 할 이름이야. 알렉스 마르텔리(Alex Martelli)도 언급해야지. 그래, 물론.

다른 영역. 음, 표준 라이브러리가 훨씬 작았어. 그랬어? 오, 그럼, 분명했지. 모듈 수가 더 적었어. 그리고 asynchro 패키지가 없었지. 그래, 이메일 패키지도 없었고, XML도 없었고... 오, XML. 그게 Effbot이 많이 작업한 거야. 그가 elementtree를 설계했다고 생각해. 맞아. 그래. 오, 그래. 나는 XML 사용자가 전혀 아니라서 완전히 잊고 있었는데, 그건 표준 라이브러리에 있어야 할 거야. 다양한 분야의 많은 사람들이 XML로 뭔가를 해야 한다고 느끼니까. 그리고 손에 믿을 만한 게 있는 게 좋지.

그래, 단점은 xmlplus를 써서 확장 가능하게 만들려고 했다는 거야, 기억하면. xmlplus가 뭐였는지 기억 안 나. 그래서 표준 라이브러리에 XML 네임스페이스가 있었고, 거기에 elementtree와 Celementtree가 있었어. Celementtree는 더 빠르지만 기능이 조금 다른 C 구현이었지. 그리고 elementpath는 XPath와 매우 비슷하지만 표준화되지 않고 XPath만큼 다재다능하지 않은 거였어. 그런 것들이 XML 패키지에 기본적으로 있었지.

그리고 우려는 우리가 XML 네임스페이스를 차지하고 있다는 거였어, 그렇지? xmlplus를 도입했으니까. 오, 맞아. 그것도 정말 좋은 기억이야. 아이디어는 파이썬 표준 라이브러리보다 더 빠르게 움직일 수 있는 다른 것에 의해 확장 가능해야 한다는 거였어. 그래, 그리고 여전히 XML 네임스페이스 아래에 있어야 했지. 그게 우리가 네임스페이스 패키지를 발명한 이유인지는 모르겠어. 아니, 이건 네임스페이스 패키지 훨씬 전이야. 당시에는 훨씬 더 해키한 해결책이 있었어.

그게 어떻게 작동했는지 말해 줄게. 왜냐하면 이게 더 이상 관련 없게 된 후에도 아주 오랫동안 구글에서 그걸 다뤄야 했거든. 그러니까 표준 라이브러리의 XML 패키지는, 임포트하면, __init__.py에서 _xmlplus를 임포트하려고 시도했어. _xmlplus는 기본적으로 설치되지 않지만 설치할 수 있었지. 그리고 그러면 _xmlplus 디렉토리를 자신의 __path__에 추가했어. 그러니까 XML 패키지에서 뭔가를 임포트하려고 할 때 그 디렉토리도 검색했다. 그러니까 표준 라이브러리를 덮어쓰지 않고 표준 라이브러리에 추가할 수 있었어. 표준 라이브러리 버전을 먼저 취하고, 우리가 표준 라이브러리에 뭔가를 추가한 경우에만, 그렇지 않으면 xmlplus 패키지에서 가져왔지.

오, 흥미롭네. 그게 패키지가 가진 모든 유연성 중 적어도 하나의 합리적인 용도네. 내가 패키지가 자신 안에 있는 것에 대한 자신만의 검색 경로를 가진다는 걸 잊고 있었어. 구글에서 우리는 모노레포에서 그 유연성을 크게 활용했어. 메타에서도 크게 활용하지. 그래서 아주 환영할 만해. 정말 편리해. 그리고 설명하고 생각하고 추론하기 쉬워. 하지만 대부분의 사람들이 보지 못하는 약간의 추가 복잡성이지.

하지만 xmlplus 해결책은 결국 매우 어색해졌어. 결국 xmlplus 패키지가 관리되지 않게 됐거든. 그리고 더 새로운 파이썬 버전에서는 작동하지 않았지만, 사람들은 여전히 그 기능 중 일부에 의존하고 있었지. XPath가 실제로 XML에 추가되고 XSLT가 xmlplus 패키지에 추가됐다고 생각해. 그리고 그런 것들을 쓰는 사람들은 xmlplus 버전이 그걸 지원하지 않으니까 파이썬을 업그레이드할 수 없었어. 그건 좀 어색했지.

음, 사람들이 처음부터 서드파티 패키지를 썼던 것과 그렇게 다르지 않지만, XML에서 임포트했다는 사실이 그게 표준 라이브러리 모듈처럼 보이게 만들었고 실제로는 아니었지. 그래, 그래, 알겠어. 다행히 더 많은 곳에서 그러지 않았어. 그래, 뭔가가 표준 라이브러리 모듈인지 아닌지 구별하는 게 항상 약간 어색해. 하지만 그래, XML, Effbot은 한때 XML에 올인했어. 구글에 합류하기 전에 그는 XML에 올인했지. 아, 그는 XML에 올인하는 기업 고객이 있었겠지. 음, 아무도 열정 때문에 XML을 하지 않아. 아마 XML 위원회 사람들만 제외하고.

마르틴 폰 뢰비스(Martin von Löwis). 물론, 그래. 유니코드 생각하다가. 닐 노위츠(Neil Norwitz), 당신 근처에 있는. 그는 아직도 당신 근처에 있다고 생각해. 하지만 그래, 팔로업 해볼 만한 좋은 이름들이야. 마르틴이 나랑 이야기하고 싶어 하길 바라. 또 크리스티안 하이메스(Christian Heimes)도 이야기하고 싶어 하길 바라. 그는 더 새로운 이름이야. 당신은 20년 전에 그 얘기를 했고. 크리스티안은 분명 5년 전이나 10년 전이지. 내 마음에는 그들이 그렇게 오래 있지 않은 것 같지만, 꽤 오래 있었어. 내가 크리스티안을 만난 건 2003년 이전 어느 시점이었다고 생각해. 크리스티안 하이메스? 그렇다고 생각해. 왜냐하면 네덜란드의 아주 멋진 건물에서 열린 Zope 스프린트에 참석했던 게 기억나거든. somehow sitting next to two different Christians. 티스머(Tismer)랑 하이메스? 아니. 티스머는 그중 하나가 아니었어. 왜냐하면 그는 Zope에 관심이 없었거든. 맞아, 맞아, 맞아. 오, 그것도 이름이야. 그건 확실히 이름이 아니고. 다른 크리스티안은 성이 기억 안 나지만, 둘 다 독일인이고 둘 다 크리스티안이라고 불렸어. 그리고 다른 한 명은 하이메스였던 게 꽤 확실해. 알겠어. 그는 그때 아주 젊었겠네. 물론. 괜찮아. 그런 일도 있지.

그럼 당신이 완전히 독학이라고 이해하면 돼? 그래. 와. 나는 사실 고등학교 중퇴야, 그래. 와. 축하해. 꽤 놀라운 일이야. 그래, 내가 중퇴했을 때 부모님은 행복하지 않으셨지만, 나는 중퇴하게 된 직장이 있었거든. 음, 그건 단순한 직장이었어. 지역 병원에서 일했지. 그리고 그들은 '아, 1년 안에 다시 학교 갈 거야'라고 하셨지. 그리고 나서 디지털 시티에서 일하게 됐어. 일종의 ISP 같은 곳이지. 그리고 XS4ALL에서 직장을 얻었고. 그리고 구글로 이직했지. 그리고 그들은 '이제 학교로 돌아가지 않는구나'라고 하셨지. (귀도 웃음.) 그래, 빅테크에서 일하면서 아버지가 이미 교수였는데도 부모님 수입을 합친 것보다 더 많이 벌었어. 분명히 학위가 없어서 행복하시지는 않았지만, 그 시점에는 정말 신경 쓰지 않으셨지.

음, 다행이네. 내 조카가 문제가 있었어. 그 아들이 학교를 중퇴하고 싶다면서 나를 가리키며 '봐, 나도 학교 안 만나, 토마스 봐'라고 했거든. 그래서 내가 '아니, 아니, 아니'라고 했어야 했지. 나는 산업이 일할 수 있는 사람이라면 누구에게나 열려 있었고 나는 그 일을 할 수 있었던 특별한 상황에 있었어. 지금은 그렇지 않아. 그러니까 학교는 끝마쳐야 해. 그래, 그래. 나는 항상 사람들에게 학교 중퇴하지 말라고 해. 그럼 '그래도 스티브 잡스잖아요!'라고 하지. 아니. 아니.

XS4ALL에서 웃긴 게, 내가 19살이나 20살에 거기서 일하기 시작했어. 대부분의 사람들이 그 나이 좀 더 많았지만, 훨씬 많지는 않았어. 그들은 모두 대학 중퇴자였어. 왜냐하면 그들은 대학에서 뭔가를 하거나 대학에서 컴퓨터를 발견하고 그리고 재밌는 걸 하려고 중퇴했거든. 나는 기본적으로 똑같았지만... 나는 대학 중퇴 직전까지 갔어. 물론 파이썬 때문은 아니지만... 모르겠어. 컴퓨터. 그래, IT. 하지만 내 상사가... 나는 대학에서 메인프레임 지원 팀에서 아르바이트를 했어. 그리고 내 상사가 먼저 졸업하라고 설득했어. 왜냐하면 그가 내가 그때 신경 쓰지 않던 걸 알았거든. 그리고 지금 나는 그가 그렇게 하게 한 게 정말 행복해. 그가 그게 훨씬 더 나은 커리어가 될 거란 걸 알았지. 그래. 이력서에 그 여분의 한 줄이 있어서.

그래, XS4ALL에서 같이 일했던 사람 중 한 명은, 기억 안 나지만, 시스템 관리자 중 한 명의 친구였어. 그리고 그는 그녀가 시스템 관리자로 잘할 거라는 걸 알았지. 그녀는 대학으로 돌아가고 싶었지만 당장은 뭔가 못 했거나 그랬고, 우리에게 1년 동안 일했어. 그녀는 지금 다른 대학에서 양자 암호학 교수야. 그러니까 이런 걸 하고 나서도 학교로 돌아갈 수 있지만, 정말 정말 드물지.

음, 거의 1시간이네. 마지막으로 할 말 있어? 갑자기 기억나는 거?

생각하건대 PSF도 간과하지 말아야 해. 그리고 거기에 약간의 구원이 있다고 생각해. 핵심 개발 시작보다 PSF 시작에 더 많은 기록이 있다고 생각해. 처음 몇 년의 이사회 명단을 보면 더 많은 이름이 떠오를 수 있어. 그래. 모르겠어. 누가 이사회에 있었는지 기억해 보려고 하는데. 음, 나는 이사회에 있었어. 당신도 있었고. 20명 이상이었어. 아니, 이사회는 5명이나 7명이었지. 오, PSF 이사회를 말하는 거야? 그래, PSF 이사회. 오. 아니, 내가 헷갈렸어. 창립자를 생각하고 있었어. 아니, 아니, PSF를 생각하고 있었어. 그래, 당신은 PSF 회원을 말하는 거야. 아마 우리가 회원이었고 이사회는 없었을 수도 있어. 아니, 우리는 바로 이사회가 있었어. 처음부터. 그래, 그레그 스타인이 우리가 이사회를 갖도록 확실히 했어. 이사회가 있어야 했지.

우리가 공식적으로 PSF를 만든 회의가 기억나. 그리고 바로 이사회 선거를 했어. 그리고 5명이나 7명, 아마 7석이었던 것 같아. 그게 몇 년이었는지 기억해? 2001년이었어. LA였거든. LA에서 열린 국제 파이썬 컨퍼런스에서. 정말. 그래. 그리고 액티브스테이트(ActiveState)가 여러 가지를 후원했기 때문이었어. 우리는 데이비드 아셔(David Ascher)가 있었고, 그것도 리스트에 넣을 좋은 이름이지. 그래, 그래. 액티브스테이트에서 일하고. 에릭 레이몬드(Eric Raymond)가 거기 있었던 게 기억나. 그래. 그리고 생생하게 기억하는 건 우리가 이사회 선거를 했거든. 나는 이사회에 출마했어. 그도 출마했어. 우리는 6명이 선출됐어. 그리고 7위에서 동수를 기록한 게 에릭 레이몬드와 나였어. 그리고 그는 결투를 제안했어. 장난스럽게, 권총 결투를 제안했어. 그게 그의 취지고 당신은 파이로 대신하는 게 어때라고 했고 그레그가 아니라고 했지. 우리는 또 한 번 선거를 치를 거라고. 그래서 내가 이겼어. (귀도 웃음.) 그리고 PSF의 첫 몇 년 동안 우리는 수입을 어디서 얻고 회사들이 파이썬을 지원하게 하려면 어떻게 해야 하는지 같은 걸 많이 이야기했어. 그리고 분명히 IRS 상태와 우리가 뭘 해야 하는지. 그리고 어느 시점에 나는 총기 규제 같은 걸 비유로 들었어. 그리고 당신이 답장을 보내며, 에릭 레이몬드 대신 내가 이겨서 정말 기쁘다고 했어. (웃음.) 그게 웃기네. 그에 대한 내 기억은 너무 달라. 약 20명, 아마 22명의 PSF 창립 회원이 있었던 게 기억나. 주로 핵심 개발자였다고 생각해. 전부 핵심 개발자였어. 전부 핵심 개발자였어. 아마 전부 핵심 개발자였을 거야. 음, 우리가 그런 개념을 가지고 있었다면. 커밋 비트를 가진 사람들. 그랬던 것 같아. 커밋 비트를 가진 모든 사람이 PSF 창립 회원이 됐어. 25명 미만이었다고 생각해. 물론 LA, IPC에 실제로 올 수 있었던 사람들뿐이었을 수도 있어. 어디였는지 기억 안 나. 거꾸로 세어보면 IPC 중 하나였어야 했어. 하지만 나를 위해 떠오르는 기억은 PSF를 실제로 시작하기 위해 해야 했던 실질적인 것들이 꽤 있었다는 거야. 501(c)(3)로 등록하는 거라던가. 그래서 첫 해에는 액티브스테이트에서 딕 하트(Dick Hardt)가 왔거든. 그는 '나는 사업가야. 이 모든 걸 처리할게. 어떻게 하는지 알아'라고 했어. 그리고 1년 동안 아무것도 안 했어. 그래서 1년 후에 재부팅을 했지. 여전히 IPC에서. 아마 그건 LA가 아니었어. 그래, 첫 번째는 LA였어. 딕 하트도 기억하니까. 그리고 그다음 해에는 나는 그 IPC에 없었어. 그리고 그게 마지막 IPC였어. 진짜 IPC. 그게 마지막이었지. 그리고 그다음 해에는 우리는 PyCon US를 가졌어.

IPC는 여전히 기술적으로 펄 컨퍼런스나 오라일리 컨퍼런스의 일부였어. IPC 브랜딩은 별도의 트랙으로 오라일리 오픈소스 컨퍼런스로 옮겨갔어. 나는 몇 번 참석한 것 같아. 그래, 나도 한 번 갔던 것 같아. 결국 진짜 파이썬 컨퍼런스는 아니었지. 그래서 PSF는 첫 번째 PyCon에 엄청나게 중요한 역할을 했어. 왜냐하면 우리는 모든 기업 회원이나 스폰서 회원에게 회원비로 1년에 3천 달러인가 뭔가를 내라고 했거든. 파이썬을 정말 신경 쓰는 여러 아주 작은 회사들이. 그 회사들 대부분은 오래전에 사라졌지만, 모두 우리에게 2년 동안 그 돈을 냈어. 그리고 우리는 은행에 충분한 현금이 있었어. 왜냐하면 우리는 지출이 없었거든. 그걸로 아무것도 하지 않았어.

팀 피터스가 어느 시점에 501(c)(3) 일을 처리했던 게 기억나. 닐 노위츠도. 닐도 이사회에 있었던 것 같아. 그는 한동안 비서였어. 그래, 그는 오랫동안 비서였지. 팀 피터스는 IRS 서류의 공공 지원 부분을 몇 년 동안 처리했어. 우리가 광범위한 공공 지원을 가지고 있다는 걸 보여줘야 했거든. 그냥 한 회사나 소수의 회사가 아니라. 금액과 자금의 다양성에 적용해야 하는 특정 공식이 있었어. 그리고 분명히 IRS는 처음 5년 동안 그걸 아주 까다롭게 굴었어. 그래서 우리는 매년 우리가 광범위한 지원을 가지고 있다는 걸 보여줘야 했어. 우리는 그냥 심부름꾼이 아니었거든.

그래, 우리는 5년 동안 501(c)(3)로 임시 승인을 받았어. 어느 시점에 모두가 그걸 잊어버렸고 적절히 갱신하려고 스크램블을 했어. 그 후에는 IRS가 우리를 내버려 뒀거든. 그리고 팀이 거기서도 역할을 했다고 생각해. 꽤 그랬을 거야.

그래서 첫 번째 PyCon 이야기를 내가 아는 대로 알고 있는지 모르겠네. 내가 전화를 받았는데, 누군가 '당신이 아마 파이썬 컨퍼런스를 조직하려고 할 거라고 아는데, 이전 파이썬 컨퍼런스 조직자가 제공한 인프라 없이 말이에요. 포테크(Fortec)요'라고 했어. 그리고 그는 펄 컨퍼런스나 펄 언컨퍼런스 같은 걸 위해 장소를 예약했다고 했는데, 그런 게 너무 많았어. 독립적으로 펄 관련 뭔가를 조직하려고 결정한 사람들이 너무 많았거든. 그리고 그는 '그 장소를 펄 용도로 쓰는 건 포기했지만, 원하면 여기 전화할 사람들이 있어. 그 주에 그 공간을 쓸 다른 사람이 없다는 걸 우연히 알거든'라고 했어. 그리고 타이밍이 맞았어. 그리고 PSF는 그들이 요구한 계약금을 낼 충분한 돈이 있었어. 오 맙소사, 그때 케이터링 비용이 얼마인지 배웠지. 그게 조지 워싱턴 대학이었지? 정말 좋은 장소였어. 점심이 그냥 도시락이었던 게 기억나. 그건 다 내 잘못이야. 아니, 아니, 나는 그게 좋았어. 음, 점심에 다양성이 없던 게 내 잘못이었어. 아, 알겠어. 그리고 나는 채식 점심을 주문하거나 사람들이 등록할 때 선호도를 지정하도록 물어볼 생각을 했는지도 모르겠어. 그래, 나는 그런 게 전혀 고려되지 않았다고 꽤 확신해. 우리는 또한 등록을 위한 모든 작업을 하거나 하겠다고 약속한 자원봉사자가 있었어. 그리고 컨퍼런스 당일에 그는 엄청나게 늦었어. 그가 우리가 깨달은 것보다 조금 더 혼란스러웠던 것 같아. 그는 장비를 다 차에 싣고 왔는데 정오쯤에야 왔거든. 스티브 홀든은 그걸 두고 꽤 당황했어. 어떻게든 됐지만. 스티브한테 물어봐야겠네.

그리고 우리가 시간이 다 됐어. 고마워, 토마스!

← 모든 글

https://gvanrossum.github.io/interviews/Thomas.html