Perl¹은 이제 많이 사용하는 사람들도 없고, 유입되는 사람들도 거의 없는 것 같다. 나도 2000년대 전에 펄을 접했었지만, 그때에 나에겐 너무 복잡하고 이해하기 어려운 프로그래밍언어였었다. 차라리 당시의 파이썬 1.5이나 Ruby 1.x, PHP 4 정도가 더 상식적으로 이해할 수 있는 언어였었다. 이미 Smalltalk, LISP을 이해하고 있었어서, 파이썬, 루비의 객체시스템이나 실행시간 Reflection, Meta-Programming 같은 주제들이 더 납득하기 좋았다.

2000년대 전후의 웹개발은 ANSI C을 이용한 CGI프로그래밍을 하거나, 아니면 펄을 사용해야 했었던거 같다. 대부분의 ‘웹호스팅’계정들은 보통 MySQL을 제공하지 않거나 비싸서, cgi-bin의 스크립트가 직접 로컬파일에 데이터를 저장하거나, dbm파일을 db처럼 사용해야만 했었었다.² 그리고 CGI스크립팅 자체가 결국 문자열 파싱과 조립이니 펄의 CGI.pm 같은 모듈 지원은 인기가 좋을 수 밖엔 없었다.

다만, 내가 CGI개발을 시작하던때는 이미 파이썬을 알고 있었고, 파이썬 1.5의 import cgi-이 펄의 use CGI;-보다 더 나는 좋았었다.

물론, 2000년대 전후에 파이썬이나 루비에 관심을 갖는 것은 한국에선 그다지 인기 있는 일은 아니었다. 오히려 웹개발을 한다고 하면 CGI/C/Perl이거나 MS IIS을 위한 Classic ASP, 혹은 APM으로 불리는 Apache + PHP4 + MySQL이 더 대세였었다. ³

그리고 나는 그때 PHP4, Python 1.5 + cgi모듈을 사용하던 때에, 멍청하게 print-문으로 HTML와 JS코드를 출력해대며 웹개발을 하던 때에, 나는 개인적으로는 정말 즐겁게 내딴에는 창의적으로 뭔가를 만들어 댔었었다. 🧓

루비나 파이썬에 이미 익숙해진 다음에, 나중에(2000년대~2010년대?) 취미정도로 조금 더 진지하게 익혀가던 시점에, 이미 어떤 커뮤니티의 몇몇 분들은 너무나 특정언어에 경도되어, 뉴비가 유입되기엔 이미 별로였던거 같다. 이 포스팅에서도 계속 이야기해 나가겠고, 지금에 생각해보면 어느 누구에게도 유익할 것 없는 관점이지만 말이다.

―이미 당시에도 펄은 유입이 거의 없었던거 같다. 한국이나 외국이나 어느 커뮤니티에서도 펄은 그저 농담거리 이상은 아니게 되었던거 같다.⁴

파이썬, 루비가 더 인기를 끌게 된 이후, 펄은 새로운 Perl 6에 대한 계획을 발표한다. 거창한 계획이었지만 몇 년간 레퍼런스구현체도 없었고 너무 방대해 보이는 범위의 기능들을 포함한 문서만 계속 개정되어 갔었다. ⁵

Audrey Tang의 Pugs-이 나오고 그 이후에 Raku으로 발전해나갔다. 하지만 내 생각엔 이미 너무 시간이 흘러버린 다음에야 진행된것 아닐까 싶다.

펄5 커뮤니티는 Moose 이후 큰 변화가 있었긴 했다. 그리고 계속해서 Moose와 호환되는, 하지만 더 가벼운 Moo, Mouse 등등의 OO-라이브러리들이 계속해서 나왔고, 아직도 나오고 있는 것 같다. 🤐

심지어 최근 버전의 펄은 자체적으로 드디어 class-키워드를 통해 OO을 하는 방식을 제공하기 시작했다: https://perldoc.perl.org/perlclass …그나마도 perldoc에 나타나지 않은, static-method/field 등을 만들려면 여전히 https://perldoc.perl.org/perlootut 의 펄의 전통적인 package + bless을 통한 Perl-OO의 내용을 알고 있어야 좀 쓸만해지지만.

Moose은 CommonLISP의 CLOS, MOP 같은 강력함, 유연함을 제공하려는 노력인 것 같다.⁶ …실은 현실에서 바로 사용하지 못할거 같은 펄6, 혹은 더 나아가서 펄6이 의식하지 않았나 싶은 루비의 객체지향과 실행시간 메타프로그래밍 같은 것들을 지원하려 노력한 것 같다.

하지만 여전히 펄답게, 펄을 좀 이해하고 나서야, 그것도 다른 파이썬이나 루비에 비해 더 많은 이해가 수반된 다음에야 재밌게 여길 수 있을테니… 글쎄다 싶다. 루비는 펄 사용자들을, 혹은 펄의 변절자들을 성공적으로 수용하지 않았나 싶다. 물론, 여전히 펄에도 유입이 있었을테고 계속해서 펄을 사용해온 사람들도 많이 있겠지만.

거기에 Raku은 나온지 꽤 되었고, 루비나 커먼리습스러운 문법구성요소⁷-을 지원하지만, 생태계의 대부분은 여전히 Beta인 것 같다: https://cro.raku.org/

…그냥 2026년 오늘에 와서도 펄+Moose, 혹은 “Perl6”을 쓸 바엔, 커먼리습이나 루비를 쓰는게 맞지 않을까 싶은 느낌이다.

한 때는, C10k problem, 지금에 와서는 C100k problem 같은게 논의되었었다. 그런 논의의 구현으로서, 그때의 인기였던 WhatsApp와 함께 Erlang이 주목 받기도 했었었다. 그리고 당시의 메인스트림이었던 MPM Prefork 방식의 Apache httpd2 등은 이제는 완전히 밀려나고, 이벤트 I/O 방식의 nginx이 남게 되었다.

당시 메인스트림 언어였던 Java 또한 NIO이나 Netty 같은 것들이 각광 받게 되었었다. 하지만 사람들은 자바나 얼랭보다 더 단순하고 가벼운 스택을 선호했다: Node.js, Go.

당연하지 않나 싶은 것이, FP언어라고 주장하던 Erlang 언어는 너무 당시의 메인스트림 언어와 달라서 이해하기 어려웠고⁸, OTP 같은 “훌륭한” 프레임웍이 함께 제공되었지만, 역시 너무 거리가 멀어보였고 너무 부담스러웠다.

그리고 자바의 NIO, Netty 역시, 자바와 Servlet, 혹은 스프링프레임웍도 부담스럽게 여기는게 대부분인데, 거기에 또 다른 공부하고 익혀야 할 무언가일 뿐이어서 부담스러웠던 것 같다. 물론 자바가 더 성숙했었을 때였으니 Node.js, Go보다 Netty 적용을 한 경우도 많을 것 같다.

그리고 지금은 파이썬도 async/await, asyncio 등을 잘 지원하고 대부분의 언어들이 고려가 되어 있다.⁹

Perl 5은 여전히 비동기입출력도 Moose와 OO라이브러리와 비슷한 상황이다. 펄에 우호적으로 표현한다면, 객체지향도 그렇고 이런 비동기입출력도 언어자체가 유연하니 얼마든지 확장할 수 있고, 펄 + CPAN 생태계 특유의 “건강한 무정부주의”라고 말할 수도 있을거다.

하지만 객체지향과 마찬가지로, 새로 유입된 사람이 사용하기엔 골치가 아프다. 단순히 어렵거나 한 문제가 아니라 어떤 라이브러리가 더 나은지, 어떤 라이브러리에 시간과 노력을 투자를 해야 맞을지 알기 어렵다.

POE, AnyEvent, Async, IO::Async 등등… 나도 이젠 모르겠다.

기존 Perl 웹프레임웍, 웹서버들은 PSGI 스펙-에 기반.

그런데, 막상 이걸 쓰면 좋긴한데, 웹소켓만 구현을 하려고 해도 제약이 생긴다: https://metacpan.org/pod/Plack::App::WebSocket#Prerequisites

…문제는 저런걸 지원하는 웹서버구현체도 적고, Mojolicious 같은 웹프레임웍이 자체 웹서버 구현과 함께 웹소켓 등도 잘 지원하기는 한다.

…하지만 Mojolicious을 제외하고는, 제대로 지원하는 조합을 펄에선 찾기 너무 어려웠다.

최근에 들어서 펄도 파이썬의 WSGI => ASGI 확장처럼, PSGI 스펙을 확장하여 비동기방식을 지원하기 시작했다:

1. https://github.com/jjn1056/pagi/
2. https://metacpan.org/dist/PAGI
3. https://www.reddit.com/r/perl/comments/1puc5uv/perl_pagi_tutorial_early_access/
4. https://www.reddit.com/r/perl/comments/1q3xaeg/the_first_pagi_compliant_web_framework_on_cpan/

흥미롭기는 하지만 아예 차라리 비동기이 아니더라도, 2026년 현시점에도 PHP이나 Ruby이 더 매력적으로 느껴지는 이유는 뭘까 싶다.