▲

Perl의 쇠퇴는 기술적 문제가 아니라 문화적 문제였다

 (beatworm.co.uk)
2P by GN⁺ 3일전 | ★ favorite | 댓글 2개
  • Perl의 쇠퇴 원인은 기술적 한계가 아니라 보수적이고 폐쇄적인 개발 문화에 있었다는 분석
  • 초기 UNIX 시스템 관리자 문화에서 비롯된 배타적 태도와 ‘전문가 중심’의 자부심이 언어 발전을 가로막음
  • Perl 6의 분열은 기술적 실패보다 커뮤니티 내부의 갈등과 보수성을 드러낸 사건으로 평가됨
  • 같은 시기 Ruby on Rails, PHP, Python은 개방적이고 접근성 높은 문화로 성장하며 Perl의 자리를 대체
  • Perl은 여전히 POSIX 환경의 핵심 스크립트 언어로 남아 있으나, 주류 개발 언어로서의 영향력은 감소한 상태

Perl의 문화적 기원과 한계

  • Perl은 UNIX 시스템 관리자 문화에서 태동, ‘RTFM’, ‘luser’ 같은 내부 농담과 폐쇄적 규범이 지배
    • 이 문화는 지식 독점과 진입 장벽 유지를 미덕으로 삼았으며, 어려움 자체를 실력의 상징으로 여김
    • 결과적으로 새로운 사용자나 변화에 대한 저항이 강한 집단주의적 구조 형성
  • 이러한 태도는 ‘공성전식 요새 문화’ 로 비유됨
    • 내부 구성원은 자신들의 기술적 난이도를 자부심으로 삼았고, 외부의 단순화 시도를 경시
    • 이는 ‘자격 있는 자만이 진입할 수 있는’ 계급적 구조로 이어짐

Perl 커뮤니티의 구조와 Perl 6의 분열

  • Perl은 ‘TIMTOWTDI(There Is More Than One Way To Do It) ’ 원칙을 내세워 유연성을 강조
    • 그러나 이 원칙은 언어 변화에 대한 보수성을 강화, 핵심 언어는 고정되고 혁신은 CPAN 외부로 밀려남
    • CPAN 중심의 확장 구조는 의존성 혼란(dependency hell) 을 초래
  • Perl 6의 출현은 커뮤니티 내부 갈등의 결과이자 분열의 상징
    • Perl 5는 실용성과 안정성을, Perl 6는 혁신과 이상을 추구하며 문화적 이중화 발생
    • Perl 6 개발은 15년 이상 지연, ‘가장 워터폴적인 오픈소스 프로젝트’로 평가됨
    • 이 시기 Perl은 새로운 개발자 유입에 비우호적이었고, 커뮤니티는 폐쇄적으로 변함

경쟁 언어들의 부상

  • Ruby는 Perl과 유사한 문법을 가지면서도 ‘프로그래머 행복’과 친절함을 핵심 가치로 삼음
    • Ruby on Rails는 개발자 친화적 툴링과 일관된 구조로 폭발적 성공을 거둠
    • Perl은 여러 유사 프레임워크를 만들었으나 상호 호환성과 진입 용이성 부족으로 확산 실패
  • PHP는 ‘** 사용자 중심 언어**’로, 설치와 배포가 간단해 대중적 확산에 성공
    • WordPress 등 블로그 플랫폼의 기반이 되어 웹 개발자 세대의 진입 언어로 자리
  • Python은 학문적 배경에서 출발해 점진적 진화와 명확한 설계 원칙을 유지
    • Google의 채택 이후 안정적 성장, ‘배터리 포함(batteries included)’ 철학으로 실용성 확보

Perl의 현재와 유산

  • Perl은 여전히 대부분의 시스템에 기본 설치된 POSIX 스크립트 언어로 존재
    • 수많은 레거시 시스템과 자동화 스크립트에서 여전히 사용
    • 그러나 새로운 프로젝트의 기본 선택지로는 거의 사용되지 않음
  • Perl이 남긴 주요 혁신
    • 정규표현식 통합과 확장 문법
    • CPAN을 통한 인터넷 기반 패키지 배포 및 서명 검증
    • 자동화된 테스트 하네스(TAP) 와 CI 개념의 확산
    • POSIX 기능 통합으로 셸과 시스템 프로그래밍의 경계를 허문 점
    • POD 문서 시스템을 통한 문서화 혁신

결론: 문화가 만든 성공과 쇠퇴

  • Perl은 1990년대 웹 초기에 두 문화(UNIX 관리자와 웹 개발자) 를 연결하며 폭발적 성장을 이룸
  • 그러나 보수적 문화와 폐쇄적 커뮤니티가 변화에 적응하지 못해 주류에서 이탈
  • 그럼에도 Perl은 현대 소프트웨어 개발의 기반을 형성한 언어 중 하나로 평가
  • 저자는 Perl이 사라지지 않을 것이며, POSIX가 존재하는 한 Perl도 존재할 것이라 단언
  • 현재 Rust, TypeScript 등 신흥 언어들이 과거 Perl이 겪은 문화적 전환의 경로를 다시 밟고 있음
▲
kh0324 21시간전  [-]

난 펄이 루비와 문법이 비슷하다는 내용이 들어가면 글자체에 독창성을 의심함. 고전적인 시기의 펄비판글의 인용문으로 쓰이는 문구이지 실제 사용에서는 느낀적이 없는 부분이라 적당히 내용 채우고 옛날글 복사해서 넣거나 나머지는 AI한테 맡기다 보니 옛날 레거시 펄 비판 글이 무비판적으로 수용되었다는 생각이 듦.

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 나는 Perl 커뮤니티의 ‘수도승과 마법사’ 같은 설정이 늘 부담스러웠음
    한 줄짜리 코드로 뭔가 똑똑해 보이려는 문화도 별로였고, Python은 훨씬 진지하고 ‘정상적인’ 느낌이었음

    • 요즘 Perl을 배우고 있는데, 진짜 마법사들이 만든 언어처럼 느껴짐
      문법이 일부러 복잡하게 설계된 것 같고, 문서 없이는 도저히 이해가 안 되는 부분이 많음
      물론 당시엔 코드의 간결함이 중요했겠지만, 2025년에 이건 너무 불친절함
      마치 D&D에서 누군가의 즉흥적인 아이디어가 영원히 룰북에 박혀버린 느낌임
    • Perl은 표현력의 깊이에 투자한 언어였고, 그 결과 같은 일을 1000가지 방식으로 쓸 수 있게 되었음
      반면 Python은 “한 가지 명확한 방법”을 강조하며 깔끔한 코드를 유도했음
      Perl도 예쁘게 쓸 수 있었지만, 그건 개발자가 의식적으로 선택해야 했음
      Python은 들여쓰기 강제 덕분에 초보자도 일정 수준의 가독성을 확보할 수 있었음
    • Perl 커뮤니티가 세계 최초의 모듈 저장소 CPAN을 만든 건 인정함
      하지만 언어 자체가 너무 표현력이 강해서 공유 코드에는 오히려 독이 되었음
      텍스트 처리만큼은 여전히 Perl이 최고지만, 협업용 언어로는 힘들었음
    • Larry Wall 인터뷰를 들었는데, 그냥 즐겁게 실험하는 괴짜 개발자 느낌이었음
      커뮤니티의 과장된 이미지와는 달리 인간적인 면이 인상적이었음
    • Python도 한때는 공백 규칙과 타입 시스템 논쟁으로 시끄러웠음
      Perl의 장난스러움이 오히려 더 솔직하고 덜 심각하게 느껴졌음
      하지만 결국 Python이 주류가 되었고, Perl은 점점 잊혀졌음

  • Perl 커뮤니티의 독선적인 문화가 언어의 몰락을 앞당겼다고 생각함
    예전에 리눅스를 알려준 친구가 Perl 매니아였는데, 모르면 조롱하는 RTFM 태도 때문에 결국 절교했음

  • 나는 Perl 커뮤니티와 거의 교류가 없었고, 그냥 구글링으로 해결하던 시절에 썼음
    @, % 같은 기호가 너무 많아 Ruby나 Python보다 접근성이 떨어졌음
    Ruby는 처음부터 객체지향 언어로 설계되어 훨씬 자연스러웠음
    Python의 optional type hinting이 부정확할 때는 오히려 혼란만 줬음

    • 바로 그게 optional type hinting의 목적임
      정확해야 한다면 그건 이미 강제 타입 시스템이지 선택적 힌트가 아님

  • 90년대 IRC에서 누가 나에게 RTFM이라 했는데, 알고 보니 농담이자 초보자 환영 이벤트였음
    실제로 Perl 마법사들과 커피를 마시며 멘토링을 받았고, 그 경험이 내 프로그래밍 인생의 전환점이 되었음
    그때 들은 말이 아직도 기억남 — “Perl it forward!”

    • 이게 진짜인지 농담인지 모르겠음
    • 그 Software Local 2142 이야기를 더 듣고 싶음

  • “고생 끝에 도파민을 얻으면 그걸 좋은 경험으로 착각하는” 현상이 컴퓨터 업계 전반에 퍼져 있음

    • 사실 그게 모든 개발의 본질 같음
      늘 혼란스럽고, “왜 이렇게 만들었지?”라는 질문의 연속임

  • 솔직히 Perl은 그냥 다른 언어들이 더 좋아서 사라졌음

    • Perl은 실험적인 언어로서 훌륭했지만, 실용성은 떨어졌음
      마치 프로토타입 보드로 제품을 만들 수 없는 것처럼, Perl은 실험의 산물이었음
    • “do what I mean” 철학 아래 숨은 복잡성이 많았음
      예를 들어 @array를 스칼라로 받으면 길이만 반환하는 식의 문맥 의존성이 있었음
    • Perl이 나쁘다는 평가는 단순한 유행어처럼 퍼졌다고 생각함
      Toyota vs Honda처럼, 실제로는 취향 차이에 가까웠음
    • 나는 Perl 커뮤니티의 일원이었지만, 나를 Python으로 옮기게 한 건 Django였음
    • Steve Yegge의 “Ancient Languages: Perl” 글이 이유를 잘 설명함
      Perl의 참조 구문, 불편한 OO, use strict; / use warnings; 같은 반복적인 설정들이 피로감을 줬음
      Rails는 훨씬 간결하고 안전했으며, 시대적 타이밍도 완벽했음

  • Perl은 내 첫 번째 애정 언어였지만, 2012년에 Python으로 완전히 갈아탔음
    지금도 레거시 코드에서 Perl 스크립트를 보면 “정말 잘 옮겼다”는 안도감이 듦
    Perl 코드는 주석이 거의 없고, 정규식 남용으로 가독성이 최악이었음
    이제는 그런 패턴을 Python의 객체지향적 방식으로 해결함

  • Perl을 많이 썼지만 결국 CPAN의 품질 문제 때문에 Python으로 옮겼음
    CPAN 모듈은 자주 깨졌고, 직접 고쳐 써야 하는 경우가 많았음

    • 나는 Perl의 스크립트 실행 속도가 느려서 Python으로 옮겼음
      90~2000년대 초반엔 그 차이가 꽤 컸음

  • Perl이 죽은 이유는 다른 언어들이 CPAN 같은 생태계를 갖추고,
    Perl의 유연한 문법이 팀 단위 협업에 부적합했기 때문임

    • 나는 Ruby로 옮겼는데, MRI 확장성이 혁신적이었음
      SWIG이나 복잡한 타입 매직 없이 모듈을 쉽게 배포할 수 있었고,
      Perl 6의 끝없는 개발 지연이 결정타였음
    • Perl의 자유로운 진화 문화는 매력적이었지만,
      협업 환경에서는 인지 부하가 기하급수적으로 증가했음
      Python은 그 논쟁을 PEP 시스템으로 외부화해 훨씬 효율적이었음
    • npm을 제외하면 지금도 CPAN만큼 강력한 저장소는 거의 없음
답변달기