구텐베르크 출시의 사후, 그래서 우리는 구텐베르크 제품을 받아들일 수 있습니다

WordPress의 새로운 기본 편집기로 출시된 지 10개월이 지난 후에도 Gutenberg는 웹 개발 커뮤니티의 상당한 수의 사람들에 의해 여전히 무시당하고 있습니다. 장소), 속도가 얼마나 느린지(지금은 훨씬 빠르게 실행되고 있음에도 불구하고), 기타 여러 불만 사항이 있습니다. 구텐베르그에 대한 이러한 비관적인 반응은 구텐베르크의 능력을 보여주는 온라인 기사에서 가장 분명하게 나타나며, 이는 독자로부터 긍정적인 반응을 이끌어내는 대신 대부분 경멸을 불러옵니다(부정적인 논평의 흐름에 반영됨).

많은 사람들이 "구텐베르크에 대해" 화난 것 같습니다(우리는 잠시 후에 구텐베르크가 실제로 무엇인지 알게 될 것입니다). 구텐베르크는 발생하지 않았거나 적어도 WordPress 코어에 기본 경험으로 통합되지 않았어야 한다고 표현합니다. 그렇게 빨리. 사람들마다 구텐베르크에 반대하는 이유가 다르며, 그 이유 중 일부는 다른 사람보다 개인적으로 더 중요합니다. 예를 들어, 일부 사람들은 Gutenberg의 도착으로 인해 사라질 위기에 처한 특정 솔루션(예: 이 브랜드 또는 해당 브랜드의 페이지 빌더와 함께 일하는 사람)을 전문으로 하기 위해 열심히 일했지만 생계가 위태로워지는 것을 보았습니다. 나는 이 사람들이 구텐베르그에게 화를 내는 이유를 진정으로 이해할 수 있고 그들에게 공감합니다.

그러나 나는 또한 구텐베르그에게 끝없이 화를 내며 그것을 사용할 가치가 있는지조차 고려하지 않고 전체를 무시하는 것은 합리적인 접근 방식이 아니라고 믿습니다. 처음 런칭했을 때 구텐베르그가 준비되지 않았다는 생각에 상당히 반대했고, 이 입장이 몇 개월 동안 지속되었습니다. 그러나 나는 최근에 구텐베르크를 점점 더 많이 사용하고 있음을 알게 되었고, 요즘에는 실제로 그것을 즐기고 있다고 주장할 수도 있습니다. 처음에는 나 자신도 "구텐베르그에서" 약간 화가 났지만, 분노를 식혀서 이제는 실제로 혜택을 볼 수 있습니다.

나는 이 글을 통해 구텐베르그가 가장 일반적으로 묘사되는 서사를 바꾸려고 한다. 나는 과거에 무엇이 잘못되었는지 열거하고, 구텐베르크가 무엇인지, 그것이 무엇인지 설명할 것입니다. 여기서 구텐베르크를 호의적인 시각으로 제시하기 위해 믿음의 도약을 할 수 있습니다. 나는 또한 구텐베르그가 이미 긍정적인 힘이고, 따라서 또 다른 기회가 주어질 가치가 있다고 주장할 것입니다(아직 그렇게 하지 않았다면).

구텐베르크가 실제로 무엇인지

내 관점에서 볼 때 구텐베르크가 더 널리 받아들여지지 않는 가장 중요한 이유는 사람들이 구텐베르크에 대해 이야기할 때 하나가 아닌 두 개의 실체(서로 혼동되는)와 동일시하기 때문입니다.

1. 구텐베르크, 발사;
2. 구텐베르그 제품.

"제품"으로서의 Gutenberg는 플러그인/기능 자체입니다. "출시"로서의 구텐베르크는 구텐베르크의 초기 개발 및 릴리스와 관련된 프로세스였습니다. 아마도 WordPress 설립자 Matt Mullenweg가 WordCamp Europe 2017에서 2017년 6월에 더 많은 청중에게 구텐베르크를 소개했을 때부터 시작하여 WordPress 5.0이 출시된 2018년 12월 초에 끝났을 것입니다. 구텐베르크와 함께 출시되었습니다.

(출시가 끝나면 새로운 단계가 시작되어 현재까지 이어집니다. "구텐베르그 연속 전달 주기"입니다. 그러나 이 단계는 "구텐베르그 출시"와 매우 다른데, 아직까지 심각한 문제가 없었고, 그래서 '구텐베르그 제품'이라는 오해를 일으키지 않기 때문에 이 글에서는 굳이 언급할 필요가 없다.)

우리는 "출시"와 "제품"이라는 두 엔터티를 구별해야 합니다. 따라서 이제부터 "구텐베르그"를 언급할 때 항상 "구텐베르그 제품"을 의미하기를 바랍니다. "구텐베르크 출시"를 언급하려면 명시적으로 이름을 지정해야 합니다. , "Gutenberg의 초기 개발/출시" 또는 이와 유사한 문구). 가장 중요한 것은 런칭과 제품을 같은 가방에 혼용하는 것을 삼가야 한다는 것입니다. 구텐베르크를 우리 프로젝트에서 사용하지 않는 이유로 구텐베르그의 실망스러운 런칭에 기여한 요인을 언급하는 것은 단계적으로 제거되어야 하며, 구텐베르크를 제품으로 판단해야 합니다. 자신의 특성에 대해서만. 이것은 구텐베르그 제품에 공정한 것입니다.

"구텐베르크 출시"가 정당한 비판을 받았지만, 구텐베르그 제품을 향한 끊임없는 경멸은 (정당화되더라도) 부당하고, 구텐베르그 제품 자체가 자신이 부여한 더럽혀진 평판의 희생양이라고 생각합니다. 실망스러운 출시 기간 동안 "Gutenberg"라는 이름으로. 예를 들어 WordPress 플러그인 디렉토리에서 "Gutenberg"를 검색하면 플러그인 순위를 결정하는 알고리즘이 플러그인 등급을 결정하기 때문에 Gutenberg는 10위 정도에만 나타납니다. 그러나 Gutenberg가 핵심으로 병합되지 않았다면 별 1개 등급의 많은 부분이 발생하지 않았을 것입니다. 처음에 플러그인으로만 출시되고 가장 중요한 버그와 문제(접근성 부족 등)가 코어에 병합되기 전에 해결될 때까지 기다렸다면 현재 등급이 더 높아졌을 것입니다.

두 엔티티(출시 및 제품)를 분리하고 별도로 처리할 수 있다면 한쪽에서는 Gutenberg의 출시 동안 무엇이 잘못되었는지 사후 분석을 수행하고 이 지식을 현재 지속적 전달에 제공할 수 있습니다. 동일한 실수가 반복되지 않도록 주기(아래에서 설명할 것처럼 실제로 이것은 이미 일어나고 있는 것 같습니다); 다른 한편으로 우리는 Gutenberg를 하나의 제품으로 평가하고 이를 스택에 추가하고 희망적으로 혜택을 받을 수 있습니다.

나는 내 자신의 관점에서 정확히 이것을 할 것입니다.

구텐베르크 출시 중 잘못된 점

한 문장으로, 프로세스를 이끄는 팀이 그것을 엉망으로 만들었습니다.

Gutenberg가 통합된 WordPress 5.0은 WordCamp US 직전인 2018년 12월 초에 출시되었습니다. 당시 출시는 잘못된 결정이었습니다. 아주 단순한 이유로 구텐베르그가 아직 준비되지 않았기 때문입니다. 특히 구텐베르그가 스크린 리더와 같은 접근성 장치를 통해 거의 무용지물이 되어 이러한 장치에 의존하는 사람은 워드프레스 편집기를 사용할 수 없게 되는 등 접근성 상황이 매우 심각했습니다. 그리고 WordPress 커뮤니티는 인터넷에 액세스할 수 있는 모든 사람(말 그대로 모든 사람)의 권리를 보호하는 데 매우 적극적이기 때문에 이 서두른 출시는 좋은 평가를 받지 못했습니다.

릴리스 프로세스를 주도한 Matt Mullenweg는 해당 날짜에 출시하는 데 단호한 충분한 이유가 있었을 수 있습니다. 그러나 그것은 확실히 지역 사회의 관점에서 의미가 없었습니다. 실제로 많은 커뮤니티 회원들은 휴일임에도 불구하고 클라이언트의 사이트를 서둘러 테스트해야 한다고 불평하며 배신감을 느꼈습니다. 우리는 많은 사람들에게 그러한 조기 출시가 (소프트웨어가 제대로 작동하더라도 실제로 Y2K가 발생하지 않은) 난파선으로 인식되어 불필요한 불만을 야기했으며 연기하거나 연기함으로써 완벽하게 피할 수 있었다고 안전하게 말할 수 있습니다. 출시하거나 나중에 보다 안정적인 단계에서 코어에 병합할 플러그인으로 Gutenberg를 먼저 릴리스합니다.

지역 사회에 가해진 고통, 좌절, 실망이 정말로 그 대가를 치러야 하는 것이었습니까? 나는 대부분의 사람들이 그렇지 않다고 말할 것이라고 믿습니다. 절대 그렇지 않다고 생각합니다. 제 생각에는 커뮤니티 구성원 대다수의 의사에 반하는 이러한 상황은 앞으로는 피해야 합니다(정말로 합당한 이유가 없는 한, 모두가 동의하지는 않더라도, Gutenber의 출시에 관한 경우였습니다. 저는 그것을 정당화할 만한 좋은 이유를 알지 못하기 때문에 잘 모르겠습니다.

같은 WordCamp US 동안의 프레젠테이션에서 Matt Mullenweg는 Gutenberg를 출시하는 동안 실수가 있었고 이러한 실수가 반복되지 않도록 교훈을 얻었음을 인정했습니다. 나는 우리가 그의 사과를 받아들일 수 있고 그의 결정이 다음 번에 올바른 결정이 될 것이라고 믿을 수 있다고 생각합니다. 그러나 손상은 이미 완료되었습니다. 치유하는 데 시간이 걸릴 수 있는 상처가 생겼으므로 WordPress 리더십에 대한 신뢰가 완전히 회복될 때까지 커뮤니티는 덜 신뢰할 수 있습니다.

지금 상황이 훨씬 나아진 것처럼 보이는 이유

이제 좋은 소식이 옵니다. 상황은 대부분 긍정적인 방향을 택한 것으로 보이며 아래 나열된 개선 사항이 이미 일어나고 있습니다.

향상된 커뮤니케이션

구텐베르그 발사에 대한 가장 큰 불만 중 하나는 지도부의 커뮤니케이션 부족이었습니다. 프로젝트를 관리하고 결정 사항을 전달할 적절한 채널이 없었기 때문에(적어도 포괄적인 방식은 아님) 전체 상황을 정확하게 파악하기가 어려웠습니다. (예를 들어, 다른 저자 또는 팀의 정보는 개인 블로그와 같은 비공식적인 경로를 포함하여 다른 경로를 통해 게시되었습니다.)

이러한 우려가 크게 개선되었습니다. 특히 메이크 블로그(코어, 접근성, 디자인, 국제화 등과 같은 다양한 영역에 대해 다양한 커뮤니티가 WordPress에 대한 결정을 내리기 위해 상호 작용하는 곳)에 있는 정보의 양과 정보가 업데이트되는 빈도는 다음과 같습니다. 증가했으며 모든 팀은 WordPress.org 사용자 계정이 있는 모든 사람이 참여할 수 있는 정기적인 Slack 기반 회의(대부분 매주 또는 격주로 진행됨)를 개최합니다. 일부 커뮤니티 구성원이 경험한 바와 같이 이제 특정 주제에 대한 개발을 안정적으로 따르고 참여할 수 있는 충분한 정보를 얻을 수 있습니다.

Gutenberg의 출시로 인한 여파는 Matt Mullenweg가 WordPress의 리더십을 두 가지 새로운 역할로 확장하도록 했습니다. 즉, 전무이사(Executive Director)는 WordPress 구축 및 유지 관리 작업을 감독하고 지시하는 역할을 하고 마케팅 및 커뮤니케이션 리더는 마케팅 팀을 이끌게 됩니다. WordPress.org, 관련 웹사이트 및 모든 판매점 개선을 감독합니다(안타깝게도 이 역할에 할당된 사람은 얼마 지나지 않아 퇴사하므로 다른 사람이 이 위치를 인수해야 합니다).

미해결 문제를 다루기 위해 구성된 분류 팀

Gutenberg의 초기 개발 단계에서 몇몇 사람들은 수천 개의 버그가 누적되어 WordPress에 새로운 기능을 추가하기 전에 수정해야 한다고 불평했습니다.

올해 3월에는 WordPress Trac 버그 추적기의 미해결 문제를 정리하기 위해 분류 팀이 구성되었습니다. 이것은 수년 동안 필요한 힘든 작업입니다. 완료되면 WordPress는 Trac에서 GitHub와 같은 최신 버그 추적기로 전환할 수 있습니다.

접근성은 꾸준히 문제가 되지 않고 있습니다.

접근성 문제는 모든 새로운 Gutenberg 릴리스에서 해결되고 있으며, 버전 6.3에서는 가장 많이 개선된 버전을 제공합니다. 현재 개선 속도에서 가장 두드러진 접근성 문제(Gutenberg 접근성 감사에서 보고됨)는 곧 과거의 일부가 되어야 합니다.

구텐베르그 자체의 장점으로 판단하기

이제 우리는 Gutenberg 제품에서 Gutenberg 출시를 분리했으므로 Gutenberg를 제품으로 분석하고 자체 장점과 단점만을 기준으로 애플리케이션 스택에 추가할 가치가 있는지 결정할 수 있습니다. 많은 사람들이 (실패한 출시에 초점을 맞추는 대신에) 구텐베르크를 신뢰하지 않는 이유로 구텐베르크의 문제를 정당하게 지적합니다. 하지만 구텐베르그는 비약적으로 발전해왔고, 비판받은 많은 문제들이 해결됐거나 해결될 위기에 놓였을 수도 있다. 따라서 부정적인 평가는 만료 날짜가 있어야 하며 재평가되어야 합니다. 우리가 구텐베르그에게 새로운 시도를 해보고 그것이 오늘날 어디에 있는지 볼 수 있다면, 어쨌든 그렇게 나쁘지는 않다는 것을 이해할 수 있을 것입니다. 제 생각에 구텐베르크는 현재보다 더 따뜻한 환영을 받을 자격이 있습니다.

나는 구텐베르크가 구텐베르크를 통해 코딩하는 것이 더 어렵다고 주장하면서 여전히 워드프레스에서 콘텐츠를 편집하는 이전 방식과 비교되고 있다는 사실에 놀랐습니다. 이것은 사실일 수도 있지만 요점도 놓치고 있습니다. Gutenberg는 과거와 동일한 기능을 생성하여 애플리케이션을 코딩하는 새로운 방법을 제공하기 위해 여기에 있는 것이 아닙니다. 그 대신 과거에만 꿈꿀 수 있었던 기능을 애플리케이션에 추가함으로써 수행할 수 있는 작업을 크게 향상시키려는 것입니다. 또한 Gutenberg는 또 다른 페이지 빌더가 아닙니다. 실제로 Gutenberg를 Divi 또는 Beaver Builder와 비교하는 것은 Victorinox를 일반 칼과 비교하는 것과 같기 때문에 유사하게 요점을 놓치고 있습니다. 예, Gutenberg로 사이트/페이지 구축을 수행할 수 있습니다(사실 아직까지는 아니지만 이미 진행 상황), 그러나 그것은 많은 용도 중 하나일 뿐입니다. 처음에는 숨겨져 있던 몇 가지 다른 용도가 있지만, 일단 그것들을 구획에서 꺼내어 작동 방식을 이해하면 가능성의 새로운 세계가 드러날 것입니다. 아래에서 저는 구텐베르크가 테이블에 가져온 이러한 새로운 가능성 중 일부를 설명할 것입니다.

먼저, 구텐베르크에 대해 그다지 좋지 않은 점에 대해 논의해 보겠습니다. Gutenberg가 정말로 해로운 것으로 간주될 수 있다고 생각하는 한 가지는 React(Gutenberg가 코딩된 JavaScript 라이브러리) 학습의 가파른 곡선에 있습니다. WordPress는 항상 매우 포괄적이어서 모든 배경의 사람들(코더뿐만 아니라 블로거, 마케팅 담당자, 영업 사원 등)이 테마 또는 플러그인을 만들거나 사이트를 시작할 수 있습니다. 이것은 의심할 여지 없이 더 이상 그렇지 않으며 모든 사람이 구텐베르크 블록을 생성하기 위해 React를 배워야 한다고 기대하는 것은 불공평합니다(반드시 그렇지는 않습니다. 다른 JavaScript 라이브러리를 사용하여 심지어 JavaScript를 사용하지 않고도 블록을 생성할 수도 있기 때문입니다. , 예를 들어 ACF 블록을 통해 하지만 React를 사용하는 것은 Gutenberg가 코딩되어 있기 때문에 가장 논리적인 옵션입니다. 이러한 단점을 정당화할 수 있는 유일한 주장은 사용자에게 더 나은 경험을 제공하는지 여부입니다. 이것이 사실로 간주될 수 있는지 봅시다.

내 이전 기사에서 주장했듯이 Gutenberg의 블록 기반 아키텍처는 애플리케이션이 구축되는 방식을 근본적으로 바꿉니다. HTML 코드로 생각하는 대신 이제 구성 요소를 웹사이트 구축 단위로 생각할 수 있습니다. 이 아키텍처는 각 구성 요소(또는 블록)를 독립적으로 개발 및 테스트할 수 있고 쉽게 재사용할 수 있기 때문에 여러 애플리케이션 개발 비용을 낮출 수 있기 때문에 유지 관리가 더 쉽고 탄력적입니다. 실제로 Vue 및 React와 같은 JavaScript 라이브러리의 최근 인기는 구성 요소에 대한 지원에 크게 기인할 수 있습니다. 개발자들이 좋아하는 훌륭한 기능이며 일단 코딩을 시작하면 되돌릴 수 없다고 생각합니다.

동일한 기사에서 저는 Gutenberg가 "한 번 만들고 모든 곳에 게시" 전략("COPE"라고도 함)을 지원하여 모든 애플리케이션에 공급할 단일 정보 소스를 생성할 수 있는 방법에 대해서도 설명합니다. 웹, 이메일/뉴스레터, iOS/Android 앱, VR/AR, 재택 도우미(예: Amazon Alexa) 및 기타. 전체 콘텐츠 관리가 훨씬 간단해지기 때문에 COPE를 사용하면 다양한 플랫폼용 콘텐츠 제작 비용도 절감할 수 있습니다. 처음 기사를 썼을 때 나는 그것이 가능하다는 이론을 세웠다. 그러나 최근에 WordPress에 COPE를 구현했는데 매력처럼 작동합니다! (제가 어떻게 작동하는지 자세히 설명하는 다른 기사를 기대해 주십시오.)

COPE와 WordPress API(WP REST API, WPGraphQL 및 나만의 PoP API)의 조합은 WordPress를 통해 모든 애플리케이션에 대해 모든 콘텐츠를 관리해야 하는 강력한 이유를 제공합니다. 또 다른 강력한 이유는 최종 사용자가 매우 간단한 방법으로 정교한 콘텐츠를 만들 수 있도록 하는 Gutenberg의 사용 용이성(아직 완전히 제공되지는 않았지만 현재 개발 속도로 인해 더 빨리 제공될 것입니다)입니다.

콘텐츠가 어떻게 보이는지 실시간 미리보기, 완벽한 형식으로 Google 문서에서 복사/붙여넣기, 내부에 중첩된 요소가 있는 복잡한 그리드 레이어 생성 및 기타 여러 기능과 같은 훌륭한 새 기능에 이미 액세스할 수 있습니다. 우리는 또한 우리가 상상하지 못한 전혀 예상치 못한 기능을 제공할 새로운 블록을 기대할 수 있습니다. 내 생각에는 구텐베르크를 통해 WordPress가 웹의 디지털 자산 관리자가 될 태세를 갖추고 있다는 것입니다. (이 주제와 이 대담한 진술에 대한 나의 정당성에 관해 Smashing Magazine에 곧 게시될 기사를 이미 작성했습니다.)

또한 Gutenberg는 다른 CMS 또는 프레임워크(예: Drupal 및 Laravel용)에서 코드를 재사용할 수 있으므로 WordPress용 코딩은 더 이상 WordPress로 제한되지 않아도 됩니다. 가능한 한 많은 시스템에서 실행해야 합니다(예: Stripe와 같은 다양한 플랫폼 및 언어에 대한 API 통합을 제공하는 회사가 이점을 누릴 수 있음). 현재 클라이언트 측 코드(JavaScript 및 CSS)만 재사용되는 것으로 보이지만 서버 측 PHP 코드도 재사용할 수 있습니다. (다시 한번, 이 작업을 수행하는 방법을 설명하는 Smashing에 대한 기사를 곧 게시할 것입니다.)

이러한 기능은 이미 현실이며 앞으로 몇 년 동안 Gutenberg가 존재해야 하는 더 강력한 이유를 제공할 것으로 기대할 수 있습니다(Matt Mullenweg에 따르면 Gutenberg는 현재 잠재력의 약 10%만 구현했습니다).

마침내 Gutenberg 제품에 대한 평결을 시도할 수 있습니다. 내 입장은 그것이 WordPress에 대한 더 높은 진입 장벽을 설정한다는 것입니다. 이는 유감이지만 WordPress에 진정한 새로운 권한을 부여하는 아름답게 엔지니어링된 소프트웨어이기도 합니다. , WordPress의 탁월성으로 인해 일반적으로 웹 개발 세계에서. 그리고 비용과 이점 사이의 이러한 균형 사이에서 저는 구텐베르그를 WordPress의 일부로 포함하는 것이 그만한 가치가 있다고 생각합니다. 제 의견에 동의하시거나, 아니면 최소한 반대의 이유는 오로지 구텐베르그의 제품적 특성에만 근거할 수 있기를 바랍니다.

결론

Gutenberg는 현재 최고입니다. 이전에는 WordPress에서 불가능했던 즐거운 사용자 경험을 제공하기 시작했습니다. 그러나 모든 사람이 구텐베르크를 받아들일 수 있는 것은 아니기 때문에 모든 사람이 이 사실을 알고 있는 것은 아닙니다. 구텐베르크(제품)가 구텐베르크 출시 중에 발생한 실수에 대해 잘못을 범해서는 안 되기 때문에 이것은 불행한 상황입니다. 우리가 이 두 개체를 분리하고 각각을 독립적으로 취급할 수 있다면 사람들 에게 구텐베르크에게 한 번 더 기회 를 달라고 설득력 있게 요청할 수 있습니다. 구텐베르크 출시가 실패한 프로세스라 할지라도 제품으로서의 구텐베르크는 가질 가치가 있음을 시사합니다.

이 기사에서 나는 사건에 대한 자신의 이해를 바탕으로 실패한 구텐베르크 발사에 대한 사후 분석을 수행했습니다. 이러한 사후 조사를 수행하면 커뮤니티와 지도부가 이러한 불행한 실수가 다시 발생하지 않도록 하는 데 도움이 될 수 있습니다. 사후에 나는 구텐베르그 자체의 장점에 따라 평가를 진행했고 내 입장을 밝혔다. 구텐베르크는 훌륭한 도구이며 WordPress 커뮤니티는 분명히 이점을 누릴 수 있다고 생각합니다. 그리고 점점 더 좋아질 것이기 때문에 Gutenberg는 WordPress의 새로운 황금 시대를 열 수도 있습니다.