Guido van Rossum이 Brett Cannon과 Python을 처음 접한 계기, python-dev 커뮤니티 참여, 표준 라이브러리 기여, Python 3 전환, 거버넌스 논의와 스트레스에 대해 대화한다.
2026년 3월 06일
이 인터뷰는 명확성을 위해 약간 편집되었지만, 원래 대화에 가깝게 유지했습니다.
Guido: Python 코어 개발자 커뮤니티의 초기 역사를 맞춰 보고, 사람들이 어떻게 Python을 찾았는지(또는 Python이 어떻게 그들을 찾았는지)에 대한 개인적 기억이 무엇인지 모아 보려는 중이에요. Brett, Python에 대해 처음 들은 게 언제였나요, 또는 어떻게 알게 되었나요? 기여를 시작한 때가 아니라, Python 한 줄을 처음 읽거나 쓴 게 언제인지요?
Brett: 2000년 가을에, 객체지향 프로그래밍을 조금 배울 수 있는 언어를 찾고 있었어요. Berkeley에 있을 때 CS 입문 과목들을 들으려고 했거든요.
그때도 아직 대학에 있었죠?
맞아요. 학사 과정 중이었어요. 전공은 철학으로 하려 했지만, 컴퓨터 과학 과목도 듣고 싶었죠. 여러 이유로 복수전공은 못 했지만, 그래도 CS 과목은 듣고 싶었어요. 입문 CS 과목인 CS 61A에는 입학 시험이 있는데, 거기에 객체지향 프로그래밍 문제가 나올 수도 있을 것 같아서 겁이 났어요. 그때까지는 C를 이미 배운 상태였고요. 그래서 그 시험을 보기 전에 프로그래밍을 좀 더 익히려고 언어를 찾고 있었죠. 선택지로는 C++이나 Java가 있었어요.
2000년이면 그게 당연한 선택이었겠네요.
객체지향 프로그래밍을 배울 언어를 찾느라 이것저것 살펴봤어요.
그냥 Google에 뭔가 쳐 봤나요?
그때 제가 어떻게 검색했는지 기억은 안 나요. Alta Vista나 HotBot 같은 초기 검색 엔진이었을 수도 있겠네요.
Alta Vista는 좋았죠.
어쨌든, “Perl은 여섯 번째 언어로 배워라”, “Python은 첫 언어로 아주 좋다” 같은 조언을 계속 보게 됐어요. Python을 써 봤는데 바로 마음에 들더라고요. 문서의 튜토리얼을 읽었고, 그 즈음 O’Reilly 책도 읽었던 것 같아요. Mark Lutz의 뱀 표지인 _Programming Python_은 아니고, 더 작은 책인 마우스 표지의 _Learning Python_이요. 그게 이미 나왔는지는 확실치 않지만, 나와 있었다면 읽었을 거예요. 저는 늘 책을 더 선호했거든요. [맞아요. –Guido]
그거 Alex Martelli가 쓴 거였나요?
아니요, 그건 Mark Lutz였어요.
Martelli가 참여한 책이 뭐였는지 잊어버렸네요.
그건 _Python Cookbook_이요. 어쨌든 Python을 배워서 정말 좋아하게 됐고, 아이러니하게도 그 입학 시험에서는 결국 객체지향 프로그래밍이 필요하지 않았어요. 그래도 Python이 너무 마음에 들어서 계속 쓰게 됐고, 그 후로 지금까지 쭉 쓰고 있어요. 그렇게 제가 Python을 찾았고, Python이 저를 찾았죠.
그리고 당신은 늘 작은 것이든 큰 것이든 무언가를 코딩하는 사람이었고요.
사실상 그랬죠. 늘 이거저거 작은 프로젝트를 하거나, 과제를 위해 뭔가 해야 해서 Python 코드를 쓰면 더 쉬운 경우가 있고, 그런 식이었어요. 그래서 프로그래밍 언어를 제가 선택할 수 있는 기회가 있을 때마다 그 당시엔 Python을 선택했죠.
Python 전에 어떤 언어를 알고 있었나요?
C요. C만? Pascal을 조금 하긴 했는데 많이는 아니었어요. 네, 그 시점에는 사실상 C가 전부였죠.
2000년쯤이면 Pascal은 이미 거의 유행이 지나 있었죠.
제가 들었던 Pascal 수업은 이상하게 짧은 수업이었어요. 한 학기짜리도 아니었고요. 컴파일러에 문제가 있어서 별로 할 수 있는 게 없었어요. 그래서 그때는 저한테 사실상 C뿐이었죠. Python으로 넘어가니 완전히 다른 세상이었어요. 컴파일러 문제도 없고, REPL [Read-Eval-Print Loop]은 정말 혁명이었죠.
그 이후 얼마나 빨리 커뮤니티에 들어가게 됐나요? Python 메일링 리스트나 뉴스그룹을 처음 읽기 시작한 건 언제였나요?
커뮤니티를 어떻게 정의하느냐에 따라 달라요. 제가 기억하기로는 그 다음 해에 ActiveState가 Python Cookbook 웹사이트를 시작했어요. 유용한 코드 조각들을 올리고 공유하는 곳이었죠. Vaults of Parnassus에 올릴 만큼은 아닌 것들요. O’Reilly가 나중에 그걸 _Python Cookbook_으로 책으로 만든 거고요. 저도 몇 가지를 올렸는데, 그게 Alex Martelli를 알게 된 계기였어요. 제가 올린 레시피 하나가 Cookbook 1판에 들어갔거든요.
그 레시피가 뭐였나요?
책에서 사실상 가장 크고 마지막 레시피였어요. 당시 Windows에는 strptime이 없어서, 순수 Python으로 strptime을 구현한 거였죠. 처음 버전은 로케일 정보를 전부 제공해야 해서 마음에 들지 않았는데, 역공학으로 해결하는 방법을 찾아냈어요. 그게 코어 개발로 이어진 계기였어요. 2002년 5월, 졸업한 다음 주에 Alex에게 표준 라이브러리에 넣으려면 어떻게 해야 하냐고 물었더니 python-dev를 가리켜 줬어요. 6월 중순에 메일을 보냈고, François Pinard가 답해 주면서 과정을 도와줬고, 한 달쯤 뒤에 time.strptime이 들어갔죠. 그 뒤로 구독을 끊은 적이 없어요.
python-dev 요약을 올리기 시작한 건 언제였나요?
2002년 8월쯤이었던 것 같아요.
같은 해네요. 빠르군요!
제 학사는 철학이었고, Cal에서 CS 입문 과목이랑 학부 AI 과목을 들었어요. 복수전공을 하고 싶었지만, UC 시스템의 학점 상한 같은 이유로 할 수가 없었죠. CS로 대학원에 가고 싶다고 결심했는데, 학사가 CS가 아니라는 점이 불리할 수도 있겠다 싶어서, 자격을 쌓고 대학원에 지원하려고 갭 이어를 두었어요. 그래서 그렇게 깊이 관여할 시간이 있었죠. strptime을 올렸을 때 경험이 너무 좋아서 python-dev에 남아 있기로 했고, 계속 지켜봤어요. 다들하고 교류하는 게 즐거웠고요. 그러다가 python-dev 요약이 더 이상 유지되지 않는 걸 알아챘어요. 원래는 Andrew Kuchling이 했는데 여력이 없었던 거죠. 그래서 제가 자원했어요.
Andrew Kuchling이 당신 전에 요약을 했었나요?
네. 그가 그만두었고, 제가 이어받았어요. 아마 그때 그는 CNRI에 있었고, Neil과 함께 Quixote라는 웹 프레임워크를 만들고 있었던 것 같아요. 출력에 문자열이 나타나게 하려고 print를 쓰지 않는 식의 문자열 전용 DSL이 있었죠.
많은 사람들이 그런 걸 시도했죠. 대개 너무 암묵적이면 별로라는 걸 깨닫게 되는데요.
어쨌든, 요약은 좋은 학습 기회라고 생각했어요. 어차피 메일은 읽고 있었고, “바보 같은” 질문을 할 기회가 되는데 다들 기꺼이 답해 줬거든요. 2002년 8월이나 9월에 시작했어요.
커뮤니티에 들어가는 아주 좋은 방법이네요.
정말 좋았어요. 모두가 아주 빨리 제가 누군지 알게 됐고, 질문도 쉽게 할 수 있었어요.
사람들이 다들 좋아하죠. 갖고는 싶지만, 자원해서 하고 싶어 하지는 않는 일이니까요.
맞아요. 그걸 노리고 한 건 아니었지만, 결과적으로 코어 개발자들이 제가 메일을 읽고 질문하고 있다는 걸 알게 됐고, 직접 관여하지 않는 사람들도 요약 덕분에 따라올 수 있었죠. 몇 년 했어요. 대학원 중에 그만뒀던 것 같은데, 박사 전이었을지도요. 2~3년쯤.
커뮤니티 초기에 대해 또 무엇이 기억나나요? 누가 있었고, 큰 논의들은 뭐였나요?
그때는 2.x 초기 시절이었어요. 2.2가 막 나왔거나, 아마 2.1 직후였을 거예요. 누가 있었냐면… Martin [von Löwis], Neil Norwitz, Marc-André [Lemburg], Andrew Kuchling, Alex Martelli, Tim [Peters], Jeremy [Hylton]. 원년 멤버들이죠. Raymond [Hettinger]도 있었고, Greg [Stein]도 있었고, Jack [Jansen]도 여전히 주변에 있었어요. 아직 작은 그룹이었죠. 제가 참여한 건 DC에서 열린 첫 PyCon US(2003) 직전이었어요. 그때 가서 스프린트 룸에서 모두를 만났던 게 기억나요. Barry [Warsaw]도 당연히 있었고요. 그땐 언어 자체를 전혀 모르는 사람이 아직 많았고, 아니면 “공백(whitespace) 있는 그 언어” 정도였죠. 규모가 작아서 다들 열정적인 취미 개발자였어요. 우리 중 일부는 직장에서 썼을 수도 있고, 많은 사람은 전혀 안 썼고요.
저도 완전히 열정적인 취미 개발자였어요.
그렇죠. 규모가 작아서 뭔가 바꾸고 싶으면 그냥 했어요. 도움이 필요하면 그냥 물어봤고요. 논의가 엄청 커지진 않았어요. 가끔 커지긴 했지만, 그때는 이미 PEP가 있었거든요.
Barry가 CNRI를 떠나자마자 거의 바로 PEP를 시작했던 것 같아요.
BeOpen에 있을 때, 그러니까 이 모든 일 직전에 그 아이디어를 내신 것 같아요.
Ping은 기억나요?
[Ka-]Ping [Yee]는 확실히 활동적이었어요. PyCon에서 일어나서, 제가 함수 인자에서 튜플 언패킹을 없애는 걸 좋아하지 않는다고 말했었죠.
그건 Python 3에서 나왔죠. 저는 없애는 쪽이었어요.
제가 그걸 해도 되냐고 물었죠. 2007년 PyCon US가 텍사스에서 열렸을 때 다시 나왔는데, Ping이 마이크로 가서 “빼지 마라”라고 말했어요. 그때도 확실히 활동적이었고, pydoc과 cgitb를 했죠.
inspect도 그 사람이었죠. 그리고 예외 재설계에도 관여했어요— 체이닝, 즉 “이 예외는 저 예외를 처리하는 중에 발생했다”라는 것.
맞아요. 그는 서로 다른 요구들을 정말 신중하게 생각해 봤죠.
그도 인터뷰로 초대해야겠네요. 아직도 친구예요.
재밌겠네요. 아무튼 그땐 팀이 더 작았어요. 좀 더 느긋한 느낌이었죠. 그때는 코어 개발자가 100명이나 되진 않았어요. 아마 50명 정도였고, 그중 절반은 활동하지 않았을 거예요. 활동적인 사람 수는 20명대였죠.
지금은 활동적인 사람이 더 많아요.
한동안 저는 그 숫자를 추적했어요. 회사들을 좀 찔러 보려고요. 코어 개발자인 직원들이 업무 시간에 좀 더 활동할 수 있게 해 달라고. 활동적인 사람이 너무 적으니까요. 아니면 PSF에 기부해서, 언젠가는 사람을 고용할 수 있으면 좋겠다고요. 지금은 마침내 그렇게 해서, 일관되게 기여하도록 돕는 걸 하고 있잖아요. 그때는 우리 대부분이 업무 시간 지원을 받지 못했거든요.
맞아요, 지금은 최소 네 명의 developers-in-residence가 있어요. Łukasz, Petr, Serhiy, 그리고 보안 담당 Seth.
Security engineer in residence죠. PSF 관점에서는 Seth를 developer-in-residence라고 부르진 않아요. Alpha-Omega 프로젝트에서 자금을 대기 때문이에요. Google과 다른 회사들이 중요한 오픈 소스 프로젝트의 보안을 개선하려고 하는 보안 이니셔티브고, 그들이 PSF에 기부해서 Seth의 비용을 대죠. 하지만 그때는 직무의 일부로 Python을 작업하는 건 흔치 않았어요. 거의 전부 자원봉사 시간이었고, 여가 시간이었죠. 우리 중 일부는 직장에서 Python을 쓰지도 못했어요. 그냥 열정적인 사용자들이 많았죠.
지금도 그런 일이 있죠.
지금도요. 어쨌든, PyCon US에서—그때 저는 모르는 사이에 PSF에 들어갔어요. 누군가 저를 추천했는데 전 몰랐거든요. 투표 다음 날, PyCon에서 다들 와서 축하한다고 하길래 “뭐를요?”라고 했더니 “PSF에 선출됐잖아”라고 하더라고요. 추천된 줄도 몰랐어요.
그때 PSF는 회원이 30명쯤이었죠? 새 회원은 기존 회원들이 승인해야 했고요.
아주 작았어요. 다음 해 2004년에, 제 첫 대면 PSF 회의는 DC에서 테이블 몇 개에 둘러앉는 정도였죠.
다양성을 장려하는 방식은 아니었네요.
네. 그리고 그 PyCon 바로 뒤에 커밋 권한(commit bit)을 받았어요. 뭔가 고칠 수 있다고 했는데 누군가가 커밋해 줘야 했거든요. 그러자 당신이 “어, 아직 커밋 권한이 없어요?”라고 했고, Raymond가 SourceForge에 로그인해서 버튼을 눌렀던 것 같아요. 제 첫 커밋은 2003년 4월 18일이었어요.
우린 아직 SourceForge에 있었나요? CVS를 쓰고?
네, Martin이 아직 Subversion으로 옮기기 전이었어요. Martin이 Subversion으로 옮겼고, 그 다음엔 제가 Subversion에서 Mercurial로, Mercurial에서 Git으로, SourceForge에서 Roundup으로, 그리고 Roundup에서 GitHub로 옮겼죠.
SourceForge가 아직 악의 소굴이 되기 전의 초기였네요.
오픈 소스 호스팅을 하는 거의 유일한 곳이었죠. 또 이런저런 파편적인 기억들도 있어요. 예를 들면 Daniel Berlin이 관여했던 것 같은.
Daniel Berlin은 누구였죠? 법학 학위와 컴퓨터 과학 학위가 있었던가요?
Google의 변호사였어요. 메일링 리스트에 있었고, 한 번은 thread와 threading 모듈이 스레드 비활성 빌드에서도 동작하게 만들 방법이 있으면 좋겠다고 얘기했어요. 그 아이디어를 바탕으로, 제가 dummy_thread와 dummy_threading 모듈을 시므(shim)로 만들었죠. 그는 시간이 없었지만, 저는 갭 이어 중이었으니까 했어요. 그게 표준 라이브러리에서 제 첫 단독 모듈들이었죠.
하지만 그는 코어 개발자는 아니었죠—python-dev에만 있던.
맞아요, 가끔 아이디어를 내는 정도였죠.
또 누가 목소리가 컸나요?
Marc-André가 목소리가 컸고요. PJE [Phillip J. Eby]도 그때쯤 있었던 것 같아요. Martin은 당연히 있었고요.
Martin은 훨씬 더 중심적으로 중요했지만, PJ도 커뮤니티를 위해 대단한 일을 했죠.
저는 사람들의 코딩 스타일도 알아채기 시작했어요. 그래서 Ping이 inspect를 썼다는 걸 알았죠. 코드를 좀 고쳐야 했는데 스타일이 보이더라고요.
Ping의 스타일은 어떻게 알아봐요?
그냥 구조화 방식이요. 과하게 복잡하진 않은데, 구분되는 느낌이 있었죠. 지금은 정확히 말로 설명하긴 어렵네요. 그건 제가 박사 과정 때 importlib를 하던 시절이었고요. PJ도 복잡성 측면에서 어느 정도 비슷했어요. 다작이었지만, 그가 구축한 유연성의 수준은 제 의견으로는 극단적이었죠.
저는 모든 걸 확장 가능하게 만드는 데 늘 주저해요. 제 목표는 미래가 가져올 모든 것에 대비하는 게 아니거든요. 미래는 언제나 예상 밖의 걸 가져오니까요.
맞아요. 완벽히 맞출 수가 없죠.
Raymond Hettinger가 언제 시작했는지 기억하나요?
그는 저보다 1년쯤 먼저 시작했어요—2002년에 커밋 권한을 받았고, 저는
PEP 3100은 잡다한 Python 3 기능들이었죠— 자잘한 것들의 큰 목록. 그중 일부는 그 자체로 PEP 하나쯤 될 만했어요.
Andrew가 처음 시작했고, 제가 너무 많이 도와서 공동 저자로 넣어 줬어요. 그가 끝까지 했는지는 모르겠네요. 과정이 길었거든요. Fred Drake와 저는 2에서 3으로 넘어가는 전환에서 표준 라이브러리의 줄을 누가 더 많이 지우나 비공식 경쟁을 했어요. 저는 compiler 패키지를 지울 수 있었으니 제가 이긴 것 같네요.
compiler 패키지는 어디서 나온 거죠?
저보다 이전 일이에요. 따라잡지 못해서 없애기로 했죠. Jeremy가 시작한 새 컴파일러가 있었고, 당신이 텍사스 PyCon에서 마감 기한을 준 적이 있어요. 아마 2006년쯤이었을 거예요. 제가 도와서 뛰어들었고, 그때 AST를 제때 완성했죠. 하지만 compiler 패키지는 계속 따라오지 못했고, 결국 그걸 대체하려고 ast 모듈을 추가했어요.
compiler 패키지의 목적이 뭐였나요?
순수 Python으로 구문 트리(syntax tree)를 다루고 바이트코드 방출을 커스터마이즈할 수 있게 하는 방식이었던 것 같아요. 내부를 노출하지 않았고 ast 모듈도 없던 시절이니까요. 그런데 솔직히 세부사항은 잘 기억이 안 나요. 우리는 결국 모든 걸 두 번 구현해야 하는 데 지쳤죠. 인터프리터용으로 한 번, 그 패키지용으로 한 번.
그건 지금도 우리가 가진 흉터예요— C 구현과 Python 구현이 둘 다 있는 모듈들. Python 버전은 종종 PyPy에서만 쓰이죠.
맞아요, 그리고 그건 제 잘못이기도 해요—가속기 PEP요. C로 가속기 모듈을 쓴다면, 다른 구현체들이 참고할 수 있도록 순수 Python 레퍼런스 버전도 반드시 있어야 한다고 썼죠. 당시엔 Jython, IronPython, PyPy가 표준 라이브러리를 바닥부터 다시 구현하려고 애쓰던 시기라 의미가 있었어요. 하지만 IronPython과 Jython이 Python 3로 넘어오지 못하면서, 이제는 사실상 우리와 PyPy만 남았죠. 죽은 무게라고 하진 않겠지만, 어느 정도 부담이긴 해요.
그 PEP는 당시엔 좋은 아이디어였다고 생각해요. profile과 cProfile이 미묘하게 다른 API를 갖는 패턴보다 낫긴 했죠.
확실히요. 하지만 그건 Python의 미래 쪽 이야기네요. 그래도 제가 그 PEP를 아주 오래전에 썼다는 걸 상기시켜 주는 좋은 사례예요.
종종 PEP는 제가 가진 어떤 아이디어를 바탕으로 쓰이기도 했죠.
가끔은요. 섞여 있었어요—당신이 아이디어를 내고 누군가가 문서로 정리해 주기도 했고, 사람들이 자기 아이디어를 내기도 했죠.
최악은 커뮤니티 밖의 완전 외부인이 PEP를 제안하는 경우예요. 그런 건 거의 가망이 없죠.
그래서 PEP 스폰서를 도입했죠. 그리고 그래서 Titus Brown과 제가 python-ideas를 만들기도 했고요—python-dev의 필터로요. 반쯤 덜 익은 제안이 너무 많이 들어왔거든요.
Titus Brown에 대해 무엇을 기억하나요?
Titus는 진화생물학 교수로, 과학 분야에서 Python을 광범위하게 사용했어요. 커뮤니티에 아주 적극적이었고, 테스트 쪽에서 정말 큰 역할을 했죠. 그와 저는 python-ideas를 함께 시작했어요. python-dev의 신호 대 잡음비를 개선하려던 때였죠. 그런데 python-ideas 자체가 거칠어지면서, 우리는 처음으로 행동 강령(code of conduct)을 도입해야 했어요.
python-ideas가 행동 강령이 있던 첫 메일링 리스트였나요?
그런 것 같아요. PSF가 하나를 만든 뒤에 우리는 바로 채택했죠. 그때는 행동 강령이라는 것 자체를 왜 가져야 하는지 정당화해야 하던 시절이었어요.
많은 사람들이 반대했죠.
왜 필요한지에 대한 이해가 많이 부족했어요. 자신에게 무기처럼 쓰일까 봐 두려워했죠. 하지만 우리는 이렇게 말했어요. 목적은 사람들을 보호하고 편안하게 느끼게 하는 거라고요. 우리가 남용하면, PSF에 항의해서 리스트 관리자 자리에서 우리를 내리게 할 수 있다고요. 시간이 지나 사람들이, 정말로 문제가 있는 참여자에게만 적용되는 걸 보고 나서야 진정했죠.
그때도 ‘wokeness’에 대한 두려움이 있었죠. 그 이름으로 부르진 않았지만.
그 이름은 아니었지만, 맞아요.
실제 아카이브를 가서 팩트체크를 하려고 보면, 기억과는 완전히 다르죠.
제가 다큐멘터리에서 날짜를 잘못 말했었죠? 당신과 함께했던 인턴십 연도를 틀리게 말했어요. 가을에서 겨울로 달력이 넘어간다는 건 알았는데, 08년에 끝났다고 말했지만 사실 08년에 시작했죠.
그 인턴십은 어땠나요?
재밌었어요. App Engine 팀이었죠. 그 뒤에 팀에 정규로 합류했어요. SF에서 당신과 팀의 다른 사람들과 어울릴 수 있어서 좋았고요. 개인적으로는, 그 겨울이 제 여자친구가 저를 떠난 뒤 자살한 다음 겨울이었어요. 저는 아직 회복 중이었고, Vancouver를 떠나 환경을 바꾸는 게 도움이 됐죠.
그건 Andrea를 만나기 전이었나요?
Andrea는 인턴십 이후인 2009년 5월에 만났어요. 학교로 몇 달 돌아갔고, 소프트볼 하다가 만났죠. 또 뭐가 있냐면… 2에서 3으로 넘어가는 전환 전체, importlib와 import 시스템—제가 그걸 다시 쓴 것, 인터프리터의 핵심 부분에 Python 코드를 부트스트랩한 것. 그리고 졸업 후에는 PSF에서 두 달 일하면서 개발자 가이드를 썼죠.
dev guide를 처음부터 쓴 건가요?
처음부터요. 지금 같은 수준은 전혀 아니었어요—훨씬 작았죠. 2011년 2월에 박사를 마쳤고, Google에 들어가기 전까지 두 달이 남아서, 그 기간 동안 PSF와 계약자로 일했어요.
중요한 일을 정말 많이 했네요.
EuroPython 발표를 위해 다 글로 정리해 둔 적이 있는데, 불릿 리스트 길이를 보니 이상하더라고요. 하지만 또 생각해 보면, 제가 이걸 22년 했잖아요. 아직 인생의 절반은 아니고—제가 중간 지점을 찍는 건 2027년 10월쯤일 거예요.
저도 대략 중간쯤이에요— 1990년쯤, 제가 34살이 됐을 때 Python을 시작했거든요.
저는 2003년 4월, 25살이 되기 전에 커밋 권한을 받았어요. 지금은 47살이 되고요.
재밌는 여정이었죠. 당신에게도 스트레스가 있었을 것 같네요.
그건 다큐멘터리에 나와 있죠—당신의 은퇴와 투표 문제요.
당신은 얼마나 스트레스였는지 인정했죠. 저는 그게 누군가에게 스트레스를 줄 거라고는 상상도 못 했어요. 제 상황에만 너무 집중하고 있었거든요.
행동에 관한 제 입장과 나쁜 행동을 지적하는 역할 때문에, 사람들이 자기 문제를 들고 저에게 오곤 했어요. 사람들이 자기들의 스트레스 상황—대개 팀 내의 대인 관계 문제—를 공유해서 제가 스트레스를 받은 적이 있었죠. 게다가 python-ideas, -discuss 등에서 행동 강령을 집행하는 일도 있었고요. PSF의 conduct working group에도 참여했어요. 저는 늘 그걸, python-dev가 너무 친절하고 환영받는 곳이어서 내가 되돌려주는 방식이라고 생각했어요. 이제는 제 아이가 커서 참여하겠다고 하면, “해도 돼, 걱정 없어”라고 말할 수 있을 만큼 환영받는 곳이길 바라요.
은퇴 이후 ‘어떻게 선택을 선택할 것인가’ 시기는, 우리가 제대로 정리할 수 있을지 보장이 없어서 힘들었어요. 의견이 아주 강한 사람들, 성격이 아주 강한 사람들이 있었고, 모두를 같은 방향으로 정렬시키는 건 설득이 많이 필요했죠—제가 말하는 ‘소프트 파워’요. 팀에 오래 있던 사람들은 “정리해서 끝내자, 머리 맞대고 싸우지 말자”고 하려고 했지만, 사소한 것들에 대한 논쟁이 너무 많았어요.
서로 다른 거버넌스 제안을 가진 경쟁 PEP가 다섯 개나 있었죠.
솔직히 경쟁 PEP 자체는 괜찮았어요. 스트레스였던 건 투표 시스템이었죠. 어떻게 뽑을지 정하고 나면, 다들 아이디어를 적고 투표하면 됐어요. 이기면 이기는 거고요.
투표 방식에 대해 이의를 제기한 사람은 없었나요?
결과적으로는 없었어요. 하지만 어떻게 투표할지를 정하는 게 어려웠죠.
제가 ‘헌법’이라고 생각하는 것에 대한 투표요?
헌법에 대한 투표였죠. 기억나요? 당신이 얼마나 답답한지 저랑 Barry에게 이메일을 보냈잖아요. 어느 날 Caltrain 타고 출근하면서 “너무 답답하다, 그냥 Brett을 BDFL로 지명해야 하나”라고 우리에게 메일을 보냈죠. 그리고 기차를 탔어요. 직장에 도착할 때쯤엔 진정해서 “다들 스스로 해결할 수 있는지 보자”라고 했고요. 그러니까 두 시간 동안은 제가 BDFL이 될 뻔했던 거죠.
무엇이 쟁점이었나요?
정말로 어떻게 투표할지 결정을 못 했어요. 어떻게 결정할지를 결정할 수가 없었죠. 단순다수제(first-past-the-post)냐 승인 투표(approval voting)냐? 익명성이냐? 제안은 PEP로 하자는 건 금방 합의했지만, 투표 메커니즘은 계속 왔다 갔다 했어요. 진짜 문제는: 당신이 “전부 너희에게 달렸다”고 해 버렸으니, 최종 결정을 내릴 방법이 없었다는 거예요. 우리가 암묵적으로 전부 동의해야 했는데, 논쟁을 끝낼 장치가 없었죠.
그게 제 의도이긴 했죠.
알아요. 하지만 그게 어려움을 만들었죠. “오케이, 결정됐다”라고 말할 방법이 없었으니까요. 결국은 우리 모두가 어딘가에서 ‘충분히 합의했다’고 느끼는 방식이어야 했어요.
일정도 있어야 하고, 선거 관리자도 있어야 하고요. 누가 두 번 투표하느냐 문제가 아니라— 언제 준비가 되었는지, 무엇에 투표하는지, 어떤 투표 시스템인지의 문제였죠.
정확해요. 어느 정도 발언권이 있는 사람들이 소프트 파워를 쓰면서, 다들 해결 쪽으로 유도하려 했죠. 어떻게 투표할지에 대해 투표할 수는 없고—
무한 회귀가 되죠.
맞아요. 그리고 누군가가 반대하면, 어느 시점에서 그걸 신경 써야 하는지? Barry가 마음에 안 들어 하는 것과, 막 코어 개발자가 된 누군가가 마음에 안 들어 하는 건 다르잖아요. “끝났다”는 확정이 없었고, 그냥 큰 불만이 충분히 크지 않다는 애매한 감각이 필요했죠. 지쳐서였는지, 사람들이 보고 있으니 마무리해야 한다는 걸 깨달아서였는지는 모르겠지만, 결국 끝냈어요.
당신은 말다툼이, 말다툼하는 사람들보다 당신을 더 스트레스 받게 하는 것 같네요.
아마도요. 그리고 저는 프로젝트가 망하는 걸 보고 싶지 않았어요. 여기 친구도 많고, 프로젝트가 해체돼서 더는 함께 어울릴 수 없게 된다면 정말 슬플 테니까요.
Python이 죽을 수 있다는 생각은 한 번도 해 본 적이 없어요. 2018년이면 이미 상위 10, 아니 상위 5 안에 들어가는 언어였죠.
소프트웨어가 사라질 거란 의미는 아니었어요. 우리가 정말 합의하지 못하면 개발 팀이 어떻게 될지가 문제였죠.
저도 그게 스트레스였던 것 같아요. 하지만 잘 됐죠.
스티어링 카운슬(steering council)을 만들었죠. 당신과 제가 처음 했고, 저는 그 뒤로 네 번 더 했고, 잘 굴러가는 것 같아요.
임기 제한을 5년으로 했으면 좋겠어요. 우리가 어쩌다 보니 사실상 늘 그렇게 해 왔죠.
저는 원래 5년이나 10년을 주장했는데 반대에 부딪혔어요. 그래서 제가 내려올 때 5년에 맞췄죠—부모가 될 예정이었던 것도 있고, 제 말에 책임지려는 것도 있었고요. 여전히 좋은 생각이라고 봐요. Thomas가 우연히 그 흐름을 유지하는 데 도움을 줬죠. Pablo가 어떻게 할지는 봐야겠어요—그가 다음으로 5년이 될 것 같아요. Barry의 경우는 중간에 쉬어서 계산이 더 어렵고요.
임기 제한은 미국 대통령처럼 누적이어야 한다고 생각해요— 연속 여부가 아니라 총 재임 연수로요.
저도 그 의견에 동의해요. 제안할 가치가 있을지도요.
당신이 제안하고 싶다면, 저는 기꺼이 보고 싶네요. 그게 아주 논쟁적일 것 같진 않아요.
정치 제도 같은 문제죠. 이제 충분히 오래 해 왔으니 사람들이 받아들일지도 몰라요. PEP 13을 바꿔야겠네요.
PEP 13을 바꾸는 방법은 그냥 투표라고 생각해요. 제가 STAR voting을 도입했을 때도 PEP가 아니라, Discourse에서 투표였죠.
맞아요. 그럼 그냥 제안하고, 대체로 합의가 되면 committers 카테고리에서 2주짜리 투표를 열면 되겠네요.
커미터만 투표할 수 있게 보장해야 하고, 투표가 끝날 때까지 결과를 공개하면 안 되죠.
제가 한다면 아마 다음 달에 할 거예요. 후보 모집을 시작하기 한참 전이 되도록요.
9월 중순이니까 시간은 충분하죠.
그렇게 할게요. 큰일도 아니고요.
[Brett은 제안하지 않았다. 2025년 12월에 Thomas Wouters가 1년 공백 후 6번째 임기로 선출되었다. –Guido]
