파이썬의 타입 주석과 정적 타입 체킹을 둘러싼 논쟁을 과거의 개발 경험과 대비하며, 타입의 가치와 비용, 그리고 파이썬의 철학적 뿌리를 되짚는다.
Title: 타입 없는 파이썬: 그때의 파이썬
작성일: 2023년 12월 01일
파이썬 타이핑에 관해서는 이미 많은 이야기가 나왔다. 트위터에서 나를 팔로우했거나(혹은 나와 함께 일해본 적이 있는 불행한(?) 분이라면) 내가 파이썬 타이핑에 회의적이라는 걸 알 것이다. 그 이유는 문법의 복잡함, mypy의 느림, 구현 전반의 번거로움, 그리고 그것과 상호작용하는 과정의 어색함에서 비롯된다. 오늘은 이 얘기를 늘어놓으려는 게 아니다. 대신 내가 파이썬을 처음 접하던 시절로 잠깐 돌아가 보려 한다. 왜냐하면 파이썬의 본래 철학과 타입이라는 개념 사이의 충돌이 근본적이고 깊으며, 동시에 새로운 것도 아니라고 믿기 때문이다.
타입이 있는 프로그래밍 언어의 개념은 2015년보다 훨씬 이전부터 있었다. 지금 막 발명된 게 아니다. 타입의 필요성을 둘러싼 논쟁도 결코 최근의 일이 아니다. 새로운 소프트웨어 프로젝트, 특히 웹 서비스와 비슷한 것을 시작하려 할 때면 언제나 프로그래밍 언어를 선택해야 했다. 2004년 무렵 내가 프로그래밍에 뛰어들었을 때만 해도 선택지는 아주 많았다. 그때 통상적인 선택은 파이썬이 아니었고, 자명한 선택은 PHP조차 아니었다. 오히려 자바였다. 정적 타입 시스템과 엔터프라이즈급 기능 덕분에 진지한 웹 애플리케이션 프로젝트에는 자바가 정석이었다. PHP는 장난감이었고, 파이썬은 존재감조차 없었다. PHP는 인기 있었지만, 내 주변에서는 늘 전혀 말도 안 되는 개념으로 여겨졌고, 그걸로 사업을 한다는 발상은 더더욱 우스웠다. 대학 1학년 때를 떠올려 보면, 현실 세계는 .NET, Java, C++로 돌아간다는 게 지배적인 의견이었다. PHP는 조롱의 대상이었고, 파이썬과 루비는 대화에 등장하지도 않았으며, 서버에서의 자바스크립트는 존재하지도 않았다.
그런데도 나는 PHP와 파이썬으로 무언가를 만들었다. 내 선택은 게으름 때문에 정적 타이핑을 기피해서가 아니라, 이 언어들이 제공한 탁월한 개발자 경험 때문이었다. 그중 상당 부분은 타입이 없다는 점 덕분이기도 했다. 개발자 경험은 정말 훌륭했다. 인텔리센스는 없었지만, 내가 한 수정은 즉시 웹에 반영되었다. FTP로 라이브 웹사이트를 실시간으로 직접 고치던 기억이 난다. 나중에는 운영 서버에서 vim으로 바로 웹사이트를 편집하기도 했다. 끔찍하고 무서웠느냐? 그렇다. 하지만 정말 미친 듯이 생산적이었다. 그 과정에서 나는 많은 것을 배웠다. 트레이드오프에 대한 귀중한 교훈이었다. 나만 그런 게 아니다. 그 언어들을 쓰던 개발자 한 세대가 우리 가장 큰 약점(타이핑도 없고, 컴파일도 되지 않는다는 점)이 동시에 가장 큰 강점이라는 걸 배웠다. 약간의 절제와 조금 다른 프로그래밍 방식을 요구했지만, 믿을 수 없을 만큼 생산적이었다.
XPath의 세계가 있었고, DTD의 세계가 있었고, SOAP과 WSDL의 세계가 있었다. 시스템의 내재된 복잡성이 너무 커서 IDE, 코드 생성, 컴파일 타임 도구가 절대적으로 필요한 세계였다. 그와 대조적으로 내 세계가 있었다. 나는 Vim, CVS와 SVN, 기본적인 리눅스 박스만으로도 내가 무척 자랑스러워하는 것들을 만들 수 있었다. 결국 PHP를 파이썬으로 바꿨는데, 나에게 더 나은 트레이드오프를 제공했기 때문이다. 하지만 PHP가 내게 준 것을 결코 잊지 않는다. 모든 것이 예뻐야 할 필요는 없고, 문제를 해결하면 그만이라는 걸 배웠다. 그리고 PHP는 그걸 해냈다.
PHP 때와 마찬가지로, 나와 파이썬 언어 런타임 사이의 총 접점은 아주 작았다. 내가 쓴 코드는 인터프리터가 바이트코드 명령으로 변환했고(심지어 그걸 들여다볼 수도 있었다!), 인터프리터의 작은 루프가 그것을 평가했다. 인터프리터는 오픈 소스였고 읽기 쉬웠으며, 무엇보다 내가 직접 이리저리 건드려볼 수 있었다. 이 덕분에 컴퓨터를 더 배웠을 뿐 아니라, 무슨 일이 실제로 일어나고 있는지 정확히 이해하기가 놀라울 만큼 쉬웠다. 의심의 여지 없이, 내가 작성한 코드와 실행된 코드 사이의 모든 것을 처음부터 끝까지 이해할 수 있었다.
그래, 정적 타입 체크는 없었고 인텔리센스도 사실상 없었다. 마이크로소프트 같은 회사들은 파이썬을 아직 언어로 여기지도 않았다. 하지만 그런 건 상관없었다. 우리는 생산적이었다! 게다가 우리는 대형 소프트웨어 프로젝트도 만들었다. 어디에 트레이드오프가 있는지도 알고 있었다. 잘못된 타입이 전달되어 운영에서 런타임 오류가 사방에서 날아들기도 했지만, 그걸 다룰 도구도 갖추고 있었다! 내가 쓰던 도구 몇 가지를 보여줬을 때 .NET 출신 동료가 얼마나 놀랐는지 지금도 생생하다. 나쁜 코드를 배포해 누군가에게 에러가 터지면, 내가 읽기 쉬운 스택 트레이스뿐 아니라 각 프레임의 소스 코드 한 줄까지 포함된 이메일을 받는다는 사실에 깜짝 놀랐다. 실행 중인 인터프리터에 원격으로 붙어, 즉석에서 파이썬 코드를 실행하며 디버깅할 수 있는 모듈을 보여주자 더더욱 놀랐다. 개발자 경험은 양파의 겹이 거의 없다는 사실을 전제로 구축되어 있었다.
하지만 들어보라. 동적 언어와 동적 타이핑 시스템을 반대하는 논거들은 이미 다 있었다! 새로 발명된 건 없고, 근본적으로 변한 것도 없다. 우리 모두 타입에 가치가 있다는 걸 알았고, 동시에 이렇게 말했다. 됐어. 그거 없어도 돼, 우린 덕 타이핑을 한다. 이걸 우리의 강점으로 만들자.
달라진 게 있다면 이것이다. 우리는 더는 개발자를 그만큼 신뢰하지 않고, 예전에 맞서 싸우던 복잡성을 다시 들여오고 있다. 오늘날의 파이썬은 때때로 개발자가 이해하기가 불가능할 정도로 복잡해지기도 한다. 어떤 영역에서는 새로운 자바를 만들어내고 있다. 우리는 처음에 밀어냈던 그 사람들이 되어가고 있다. 조심하지 않으면 세계 최악의 자바로 가는 길에 서게 된다. 타입을 지원하지 않던 언어에 타입을 덧씌웠고, 인터프리터는 느리고, GIL도 있다. 우리의 뿌리가 다른 곳에 있다는 사실을 잊지 않도록 조심해야 한다. 우리가 누리던 장점을 집단적으로 내던져서는 안 된다.
바람은 바뀌었다는 건 부정할 수 없다. 다른 언어들이 타입이 새로운, 흥미로운 방식으로 가치를 더한다는 걸 보여줬다. 처음 파이썬과 자바의 타이핑을 두고 논쟁하던 때에는 자바에 제네릭조차 없었다. 자바스크립트는 지긋지긋한 장난감이라는 평판과 싸우고 있었다. 타입스크립트가 나오려면 아직도 몇 년이 남아 있었다. 새롭게 발명된 것은 없었지만, 몇몇은 대중화되었다. 추상 데이터 타입은 더 이상 연구자들의 장난감이 아니다. .NET은 정적과 동적 타이핑을 섞기 시작했고, 타입스크립트는 본래 타입이 없던 언어에 타입을 더하는 방식을 대중화했다. 그리고 우리 커뮤니티에는, 그 언어들이 애초에 왜 매력적이었는지 잘 모를 가능성이 더 높은 개발자들이 훨씬 많아졌다.
그렇다면 우리는 어디에 서 있는가? 이 글이 그저 내가 옛날을 그리워하며 타입이 모든 걸 망친다고 투덜대는 것일까? 전혀 아니다. 타이핑에는 부정할 수 없는 효용이 있고, 전체 생산성을 높일 수 있는 요소도 있다. 하지만 내재된 트레이드오프는 변하지 않았으며, 타입을 쓰느냐 마느냐는 낙인 없이 선택할 수 있어야 한다. 이 결정의 핵심 원리는 달라지지 않았다. 타입은 가치를 더하고, 동시에 비용도 더한다.
추신: 지금의 파이썬은, 내가 타입을 다는 데 들이는 시간이 내게 보상을 충분히 가져다주지 못하는 지점에 와 있다. 반면 타입스크립트는 내게 생산성 쪽으로 더 기운다. 파이썬도 충분히 그 지점에 도달할 수 있다. 다시 돌아와 살펴볼 생각이다.
