1P by GN⁺ | ★ favorite | 댓글 1개
  • WordPress는 Matt Mullenweg와 Mike Little이 b2/cafélog를 포크해 첫 릴리스를 낸 지 21년이 됐고, 앞으로의 개발에서도 초기 성공을 만든 조건을 다시 붙잡아야 함
  • 제품 방향은 쉬운 일은 직관적으로, 복잡한 일도 가능하게 만드는 원칙에 맞춰져 있음
  • 블로깅, 댓글, pingback 같은 동적 웹 기능은 웹사이트를 더 재미있게 만들며, 정적 웹사이트보다 동적 웹사이트에 더 큰 가치를 둠
  • 플러그인과 테마 생태계는 WordPress 코어 수준의 개발 인프라를 갖춰야 하며, 2024년에 ZIP 업로드에 의존하는 방식은 맞지 않음
  • 사용자와 가까운 피드백 루프, 커뮤니티 중심 포럼, 좋은 테마 미리보기, Playground가 향후 WordPress 경험을 좌우함

WordPress 21주년과 제품 원칙

  • WordPress는 Matt Mullenweg와 Mike Little이 Michel의 b2/cafélog 작업을 포크해 첫 릴리스를 낸 지 21년이 됨
  • 앞으로의 개발에서도 WordPress 초기 성공에 기여한 요소들을 계속 염두에 둬야 함
  • 핵심 제품 원칙은 단순한 것은 쉽고 직관적이어야 하며, 복잡한 것도 가능해야 한다는 데 있음

블로그, 문서, 커뮤니티 기능

  • 블로깅, 댓글, pingback은 재미있어야 함
    • 정적 웹사이트도 괜찮지만, 동적 웹사이트가 더 낫다는 입장임
    • 거의 모든 사이트는 훌륭한 블로그가 있으면 개선될 수 있음
  • 문서는 위키처럼 쉽게 편집할 수 있어야 함
    • 위키는 “놀라운” 도구로 평가됨
  • 커뮤니티에서는 포럼이 중심에 있어야 함

플러그인과 테마 생태계

  • 모든 플러그인과 테마는 WordPress 자체를 만들 때 쓰는 수준의 개발 인프라를 가져야 함
    • 버전 관리
    • 버그 트래커
    • 포럼
    • 문서
    • 국제화
    • 채팅방
    • P2
    • 기여와 커뮤니티로 이어지는 쉬운 경로
  • 2024년에 플러그인과 테마를 ZIP 업로드 방식으로 다루는 것은 적절하지 않음
  • 테마 미리보기는 훌륭해야 함
  • 다양한 미감과 기능을 가진 비상업적 테마 컬렉션이 중요함

규칙보다 피드백 루프와 투명성

  • 가이드라인과 요구사항에 지나치게 치우쳐서는 안 됨
  • 좋은 마켓플레이스 역학, 자동화된 피드백 루프, 사용자에 대한 투명성을 설계하는 편이 더 나음
  • 기능과 디자인의 경계는 더 밀어붙여야 함
  • 스팸과 스팸성 행동에는 무관용이 필요함
  • 피드백 루프는 게이트키퍼에게 의존하기보다 사용량과 전체 커뮤니티에 맞춰 확장돼야 함

코어의 성격과 사용자 접점

  • WordPress 코어는 자기 의견이 있고 독특해야 함
    • Easter egg
    • 번역이 어렵더라도 개성이 있는 언어
    • 재즈 같은 성격
  • 소프트웨어를 개발하고 의사결정하는 사람은 모두 그 소프트웨어를 사용해야 함
  • 개발자와 의사결정자는 지원 업무, 밋업, 이벤트 등 가능한 활동을 통해 일반 최종 사용자와 가까이 있어야 함

Playground와 초기 경험

  • Playground는 모든 것을 바꿀 것으로 기대됨
  • 2003년 5월 27일, 첫 WordPress 릴리스가 나온 날 Matt Mullenweg는 부모님 집 현관에서 쓴 953단어 블로그 글에 “WordPress를 내놓았고, 기분이 좋았다”는 문장을 남김
  • 그날 밤 그는 친구 Ramie Speight를 위해 WP를 설정했고, 지역 블로거 모임에서 만난 Mike Tremoulet에게 전화 기술 지원을 함
  • 고등학교 친구들이 각자 도메인에서 WordPress를 썼고, 그 피드백 루프가 소프트웨어를 형성하는 데 큰 역할을 함

댓글과 토론

Hacker News 의견들
  • WordPress가 개발 표준을 지키기는커녕 적극적으로 깨려는 것처럼 보여서 아쉬움
    전역 변수를 everywhere 쓰고 클래식 테마로 스파게티 코드를 부추기더니, 새 테마에서는 HTML 주석 안에 JSON을 넣도록 해서 에디터 지원도 없고 오류도 쉽게 나며 그냥 이상한 설계가 됨
    진지하게 시니어 엔지니어들이 HTML 주석 안에 JSON 템플릿을 넣자고 결정한 건가 싶고, 음모론적으로 보면 프리랜서나 디지털 에이전시 시장을 죽이고 WP.com의 WYSIWYG 사이트 빌더로 밀어 넣으려는 것처럼 보이기도 함

    • WordPress는 나쁜 관행을 정말 많이 장려함. 기본 테마 구조만 봐도 CSS 파일의 주석으로 테마 메타데이터를 설명하고, 합성 대신 문자열 이어붙이기를 everywhere 써서 HTML 조각을 재사용하기 어렵게 만듦
      PHP 안의 HTML 안의 JS 안의 CSS 같은 식이고, 전체 페이지를 만들기 위해 어떤 파일을 어떤 순서로 읽는지 암묵적 구조에 의존함
      처음에는 편해 보이지만 HTML 요소를 같은 파일에서 제대로 닫지 않고 다른 파일에서 끝내게 만들어 재사용도 못 하게 함
      초보자 실수처럼 보이지만 수천 개 테마가 여기에 의존하니 이제는 묶여버렸고, Jinja2 템플릿에서 블록과 매크로를 렌더링하는 방식과 대비됨
    • 프리랜서를 죽인다고? 지난 15년 동안 값싼 잠재 고객에게 가장 즐겨 하던 말이 WordPress로 사이트를 만들고 WordPress “전문가”를 찾아보라는 것이었음
      WordPress는 단순한 웹사이트가 필요하다는 착각을 가진 예산 없는 고객과 저가 고객을 위해 존재하고, 그런 단순 사이트라는 개념 자체도 이미 죽은 이야기라고 봄
    • WP로 작업해야 한다면 블록/클래식 버전 대신 항상 Timber 프레임워크를 씀
      https://timber.github.io/docs/v2/
    • WordPress 전문가는 전혀 아니지만, 가끔 고객 사이트를 옮겨야 했고 데이터베이스 안의 직렬화된 PHP에 하드코딩된 절대 파일 시스템 경로가 박혀 있던 기억이 생생함
      설치 경로가 조금만 다른 새 서버로 옮기려 하면 바로 깨졌음
    • 개발 표준을 지키면 사용자가 플랫폼에 묶이지 않음. 더 잘 작동하고 관리하기 쉬운 CMS로 옮기거나, 어쩔 수 없이 누군가에게 돈을 내는 대신 호스팅 솔루션으로 갈 수 있음
      안타깝게도 그러면 “우리 플랫폼이 전체 웹사이트의 43.4% 를 구동한다”는 마케팅 문구에 악영향이 있을 수 있음
  • 빠른 판단과 강한 의견이 커뮤니티의 일부가 되어버린 건 아쉬움
    지난 2~3개월 동안 WordPress 개발을 많이 해보니, 블록(Gutenberg)이 제공하는 코드 격리는 훌륭하다고 말하고 싶음
    독립 플러그인으로 쓰거나 Advanced Custom Fields와 함께 쓰면 HTML까지 100% 직접 제어하는 완벽한 모듈식 웹사이트와 개발 흐름, 즉 디자인 시스템을 만들 수 있음
    WordPress를 제대로 이해하고 배우는 걸 모두에게 추천함. WordPress와 아무 관계나 연관은 없음

    • 지금 바로 그 제안대로 작업 중인데, 프로덕션에서 흥미로운 500 오류를 겪고 있음
      오늘 갑자기 Gutenberg와 ACF Blocks가 중첩 미디어 필드의 콘텐츠 파싱을 두고 어딘가에서 충돌하고 있음
      원인은 “사용자가 넣으면 안 되는 이미지 설명을 넣었다”일 수도 있고, “플러그인의 전역 객체가 acf_register_block_type()에 전달되는 다른 전역 객체를 오염시켰다”일 수도 있음
      이미 화가 난 고객에게 전화를 걸어 빠른 판단과 강한 의견을 피하라고 말해야 할지도 모르겠음
    • 대부분의 판단은 21년에 걸쳐 형성됐다고 봄. WordPress는 처음엔 웹사이트를 빠르고 쉽게 만드는 방법으로 명성을 얻었고, 이후에는 보안 악몽이라는 평판을 얻었음
      지금은 아닐 수도 있지만 회의적인 건 당연함. 매주 확인하는 업데이트에서 CVE가 꽤 많이 보이는데, 전부 낮은 위험이거나 거의 쓰이지 않는 플러그인 관련일 수도 있음
    • 어릴 때 첫 프로그래밍 경험 중 하나가 WordPress의 index.php를 순진하게 열어 동작 방식을 이해하려 한 것이었음
      파일 맨 위의 “code is poetry”라는 주석 말고는 아무것도 이해할 수 없었던 기억이 남아 있음
      그 덕분에 코드에 대한 사고방식이 바뀌고 프로그래밍에 더 빠져들게 됨
    • 조금만 더 깊이 들어가면 WordPress가 얼마나 난장판인지 바로 드러남
      글에 메타데이터가 필요하면 ACF를 설치하고, 그 메타데이터로 필터링하려 하면 필터가 몇 개만 동시에 걸려도 SQL 질의가 시간 초과됨. WP의 이상한 스키마를 보면 이유를 알 수 있음
      Gutenberg는 WYSIWYG로 편집 가능한 React 컴포넌트를 약속하는데, 속성을 HTML 안에 저장하고 데이터베이스에 렌더링된 HTML을 넣으며 컴포넌트 개발자가 뭔가 바꿀 때마다 deprecated 변경 배열을 유지하게 하는 이상한 결정을 내림
      WordPress를 리팩터링하고 Laravel을 붙여 풀어내려는 시도도 있지만[1], 레이어마다 악몽이고 서로 다른 부분의 작성자들도 왜 무작위로 깨지는지 제대로 판단하기 어려워 보임
      플러그인 생태계가 매력적일 수는 있지만 플러그인 구현은 제각각이라 사용자에게 비대한 CSS와 JS 덩어리를 밀어 넣게 될 가능성이 큼
      나는 Directus와 Astro로 옮겼고, 더 일반적인 PHP 배포라면 October나 Statamic 같은 Laravel 기반 CMS를 쓸 것 같음
      [1]: https://roots.io/
    • WordPress를 제대로 이해하고 배우는 더 나은 방법을 추천해줄 수 있는지 궁금함
      2009~2011년에 플러그인 작성과 수정까지 포함해 꽤 많이 다뤘지만, 제대로 이해했다는 느낌은 없었고 대략적으로만 이해하거나 받아들였음
  • WordPress를 좋아함. 사람들이 직접 설치하고, 쓸모없고 안전하지 않고 버그 많은 플러그인을 수십 개 깔고, 시간이 지나 사이트가 망가지면 더 안전하고 탄탄한 솔루션 비용을 청구할 수 있음

    • 2011년에 플러그인 순위 2위였던 sociable 플러그인을 들여다볼 기회가 있었는데, 본 코드 중 가장 취약하고 비대한 축에 속했음
      끝나지 않은 주말 프로젝트가 너무 오래 끌리다 공개된 느낌이었고, 거대한 전역 변수 위를 도는 5화면짜리 for 루프가 중복되어 뭔가를 처리하는 식이었음
    • 플러그인을 설치하고 싶게 만드는 데는 확실히 성공했음. 특히 그 UI를 전면에 배치한 것만으로도 그렇고, 이미지가 기본으로 압축되지 않으니 이미지를 압축하라고 요구하는 여러 SEO 분석기와도 완벽한 동맹이 됨
  • WordPress는 “완벽할 필요는 없고, 작동만 하면 된다”의 가장 좋아하는 예시임
    많은 멋진 프로젝트가 첫 단계를 지나치게 복잡하게 만들어서 죽음. 사람들이 쓰기 시작하면 나중에 언제든 개선할 수 있지만, 먼저 출시해야 함

    • 오히려 반대를 증명한다고 봄. WordPress는 사실상 전체 코드베이스를 공개 API로 만들어버렸고, 그래서 기존 상태에 의존하는 플러그인 때문에 영원히 레거시 코드에 묶여 의미 있는 개선을 하기 어렵게 됨
      너무 심해서 PHP 언어 개발자들도 일부 기능이나 수정을 구현하지 못함. WordPress 팀이 코드를 마이그레이션하지 않으려 하고, WordPress가 PHP 사용량의 큰 덩어리를 차지하기 때문임
    • 사람들이 약 25년 전에 WP를 쓰기 시작했다는 사실 자체가 “나중에 언제든 개선할 수 있다”에 대한 반례 아닌가 싶음
  • WP는 작업의 95%에는 완벽한 도구지만, 마지막 5%를 조정하는 일이 엄청나게 답답함
    많이 써봤고, 이렇게 오래 살아남은 건 유용성의 증거라고 봄. 앞으로도 21년 더 이어지길 바람

  • 솔직히 WordPress가 사용하기 쉽다고 느낀 적은 없음. 좋은 테마와 플러그인을 찾을 수 있을 때까지만 장밋빛이고, 아주 작은 맞춤 변경이 필요해지는 순간부터 꼬이기 시작함

    • 스스로 평균 이상 웹 개발자라고 생각했고, 친구들이 WordPress 사이트에서 몇 가지만 고쳐달라고 하면 주저 없이 쉽게 바꿀 수 있다고 말하곤 했음
      막상 사이트와 플러그인/테마 코드, CSS 파일을 열면 원하는 효과를 내려고 몇 시간씩 씨름했고, 설령 성공해도 사이트의 다른 부분을 깨뜨리곤 했음
      비하성 일화는 그렇다 치고, Matt 잘했고 마지막 이야기도 좋았음
    • WordPress의 초기 설정은 매우 쉽지만 시간이 지나면 유지보수가 아주 어려워짐
      업데이트에는 수동 개입이 필요하고, 테마는 고쳐야 하며, 플러그인은 폐기됨. 이런 부담을 받아들이고 싶지 않아서 2017년쯤부터 모든 사이트를 Hugo/Jekyll/MkDocs 등으로 옮겼음
    • Ghost로 옮겼는데 처음엔 약간 거칠었지만 전역 CLI가 생긴 뒤로 꽤 괜찮아짐
      블로그라면 WP보다 Ghost를 쓰고 싶고, PHP보다 JS를 선호하기도 함
  • 여러 사람이 “나는 WordPress 개발자”라고 말해도 실제로는 전혀 다른 경험과 기술 묶음을 뜻한다는 점이 흥미로움
    어떤 사람에게는 WordPress 관리자 화면에서 테마와 플러그인을 설치하고 페이지 콘텐츠를 작성하는 뜻임
    다른 사람에게는 PHP 템플릿으로 HTML을 작성하며 WordPress 동작을 커스터마이즈하는 구식 PHP 코드, 즉 클래식 테마를 뜻함
    또 다른 사람에게는 Docker, CI/CD와 함께 JS+React를 작성하는 새 블록 테마를 뜻함

    • 고객층을 충분히 다양하게 잡았다면, 어떤 사람에게는 이 모든 것을 다 의미할 수도 있음
  • 더 많은 회사가 Automattic의 안식휴가 정책을 도입했으면 좋겠음
    https://automattic.com/benefits/sabbatical/

    • 미국에서는 연간 휴가가 2주라서, 3개월 안식휴가가 있어도 유럽보다 적다는 점은 감안해야 함
  • 나이가 들었다고 느끼게 하는 건 “WP”를 보고 WordPress가 아니라 WordPerfect(https://en.wikipedia.org/wiki/WordPerfect)를 떠올릴 때임
    WordPress는 이제 가장 보수적인 나라에서도 성인으로 인정될 나이가 됐고, WordPerfect는 이제 중년의 위기 나이에 접어듦

    • 아직도 WordPerfect가 그리움. MS Word보다 더 좋아했는데, 마지막으로 쓴 지 25년이 지났음
  • WordPress에서 인상적인 건 웹 너드들이 당연히 쉬울 거라고 기대했다가 그렇지 않으면 화를 낸다는 점임
    다른 모든 것처럼 WordPress도 배워야 하고, 나름의 관점이 있음
    이상한 역사도 있고, 특히 미디어 항목 처리 방식은 정말 마음에 안 들지만, 그래도 방법론이 있음
    내가 Go, JS, Perl, Java, Ruby, C를 안다고 말하면서 Rust가 배우기 어렵다고 화를 내면 당연히 반박당할 것임
    WordPress는 단순한 일을 하는 것처럼 보이지만 실제로는 꽤 넓은 플랫폼임. 문서를 좀 읽어야 할 수도 있음
    Elementor를 쓰는 사이트를 물려받았다면 만든 사람에게 간단한 변경 방법을 물어보면 도움을 줄 수 있을 것임
    Visual Composer나 Divi를 쓰는 사이트를 물려받았다면 만든 사람들을 쏴버리고 싶을 정도임
    Gutenberg가 나쁘다고 생각한다면, 지금은 전혀 그렇지 않음. Divi 시절을 떠올리면 정말 심했음

    • 전체 스타일링에 Divi를 쓰는 웹사이트를 물려받았는데, 지금까지 본 상용 소프트웨어 중 최악에 가까움
      WordPress 위에 얹은 끔찍한 JavaScript UI 실행에서 조금이라도 시간 초과가 나면 블로그 글 저장만으로도 전체 웹사이트가 복구 불가능한 상태가 될 수 있음
      이탈리아어와 프랑스어 현지화는 90년대 일본 게임 수준으로 형편없고, 반응형 옵션은 특정 중단점에서 콘텐츠를 숨기고 보이는 것을 반응형이라고 부르지 않는 한 사실상 동작하지 않음
      프런트엔드 “테마”가 jQuery 시대 JavaScript의 읽을 수 없는 덤프에 가깝기 때문에 모든 것이 극도로 취약함
      Elegant Themes가 광고에 엄청나게 돈을 쓰지 않았다면 아무도 쓰지 않았을 거라고 100% 확신함
    • 그 이상한 역사가 뭔지 궁금함