Changwoo Blog

Blog

  • ESNext #1: 리액트 사용

    블록 에디터가 워드프레스 생태계에 주는 여파는 꽤 크다. 단순히 쓰기 편한 새로운 에디터가 등장한 것 뿐만이 닐 것이다. 이제 새로운 프론트엔드 개발 기법들을 적극적으로 반영해야 한다.

    리액트는 새로운 워드프레스 코어 코드의 중요한 의존성이 되었다. 물론 필수는 아니겠지만 개발자는 보다 리액트를 잘 이해해야 할 필요가 있다. 아마 꽤 오랫동안은 그 영향력이 유지되겠지만 점차 jQuery는 폐기될 것이다. 정말 많은 요소들이 변화하고 있으며, 나 같은 개발자는 따라가기 벅차다.

    이번 기회에 기존의 기술과 대두되는 새로운 기술들을 어떻게 사용해야 할지 좀 정리해야 할 필요가 있다고 생각했다. 새로운 기술들은 아직 사용하기 익숙치 않아 계속 실무에 투입하기 어려웠다. 하지만 이제 점점 사용해야 하지 않으면 안 될 시기가 온 것 같다. 고객들도 점점 구텐베르크를 위시한 새로운 프론트엔드 개발에 대한 사용 경험을 쌓아 왔고, 나도 그에 맞추지 않으면 안 된다고 생각한다.

    우선 블럭 에디터나 리액트를 플러그인 개발에서 사용하기 위한 절차? 방법들에 대해 정리해보자. 대략 알고 있지만, 숙련도가 높지 않은 탓에 자연스럽게 되지 않는다.

    플러그인 기본 셋업

    기존과 동일하게 플러그인 메인 파일에 헤더를 생성한다. 이러면 코어는 플러그인을 인식한다. 그러나 이제는 자바스크립트 기반의 개발 환경을 위해 package.json 파일의 추가를 반드시 해 줘야 한다.

    package.json은 NPM으로 가능하지만, 나는 yarn을 더 선호한다. 혹시 개발하는 시스템에 yarn이 설치되지 않았다면 yarn 설치하기 페이지를 보고 우선 진행하기 바란다.

    Yarn이나 NPM이 설치되었으며 ‘npm init’ 혹은 ‘yarn init’으로 package.json을 시작하자. package.json은 단순한 JSON 파일이므로 스키마를 잘 안다면 수동으로 만들어도 무방하다.

    아래 JSON 일부분은 라이센스와 기본 빌드 스크립트를 지정하는 예제이다. 아마 이 셋업은 자주 반복될 것이다.

    {
  ...
  "scripts": {
    "start": "wp-scripts start",
    "build": "wp-scripts build"
  },
  ...
  "license": "GPL-2.0-or-later"
}

    @wordpress/scripts 설치

    솔직히 내가 프론트엔드 프레임워크에서 매우 짜증내는 부분 중 하나이다. 바로 과도한 설정 홍수. 프론트를 위한 온갖 잡다한 부분이 package.json을 위시한 별별 js 파일 설정에 뒤범벅이 되어 있는 것. 나도 한 사람의 개발하는 사람으로서 그런 이유와 결과에 대해 이해하지만, 내 개인적으로는 덕지덕지 붙어있는 이런 잡다한 설정 덩어리들은 괴물같아 싫다.

    물론 더욱 정밀한 설정, 고급 설정을 하려면 그런 세세한 설정이 없으면 안되는 것은 알지만… 적어도 나한테는 프론트엔드 개발에 큰 장벽이 된다.

    그래도 좀 다행이다. 이러한 개발 설정들은 한 번 잘 설정해 두면 잘 복사해서 재사용할 수 있다는 점이고, 워드프레스 코어 개발자들은 아예 그 재사용성을 활용해 그러한 설정마저 하나의 패키지로 묶어 놨다는 사실. 보다 세세한 설정에 눈뜨게 될 때 까지는 훌륭한 조력자가 될 것이다.

    이 조력자는 yarn add --dev @wordpress/scripts라는 한 줄의 명령어로 쉽게 설치된다. 그리고 위 package.json 의 scripts 부분에 미리 설정을 해 두었으니 npm start, npm build 명령과 연계하여 사용하면 된다. 보다 복잡한 설정은 문서를 참고하면 된다.

    리액트로 Hello, World! 시작하기

    블록 에디터를 위한 커스텀 블록 생성 전에 먼저 그냥 먼저 리액트를 사용해 보자. 최초의 예제는 언제나 ‘Hello, World!’니까 그것부터 시작해 보자.

    예제는 github에 작성했고, 앞으로도 거기에 내용을 업데이트할 예정이다. 코드가 워낙 간단하니 디테일한 설명은 생략한다. 자세한 설명은 소스 코드에 주석으로 대신한다. 여기서는 중요한 포인트 몇가지만 기술하고자 한다.

    • 리액트가 프론트엔드 부분의 마크업까지 작성하게 되므로, PHP 코드 자체에서는 그다지 많은 할 일이 없다. PHP 코드는 껍데기라고 느껴질 정도로.
    • 중요. 보통 ‘depencencies’에 ‘react’, ‘react-dom’를 넣게 된다. 그러나 워드프레스에서는 ‘devDependencies’에 둘을 넣는다. 워드프레스 코어 자체에 리액트가 내장되어 있고 wp-script가 서로 다른 버전의 리액트가 중구난방하지 않도록 제어하기 때문이다. 물론 스크립트가 알아서 잘 처리하니 그냥 dependencies에 넣어도 문제가 되지는 않는다.
    • 리액트 뿐 아니라 블록 에디터를 위해 만들어진 여러 패키지, 예를 들어 UI 요소들 같은 노드 패키지들도 코어에 이미 지정되어 있다면 코어의 것을 쓰지, node_modules로 임의 설치된 것을 사용치 않는다. 즉, 패키지 설치는 단지 코드를 참조하기 위함으로 알아두자.

  • 워드프레스 코어 #3

    2020년 08월 04일 네번째 모임 발표 자료

    워드프레스 데이터베이스와 회원 로그인에 대한 자료입니다.

    슬라이드 링크

  • 워드프레스 코어 #2

    지난 시간에 이어 코어 두 번째 이야기를 준비했습니다. 이번에는 wp() 함수에서 일어나는 라우팅에 대해 알아봅니다.

    URL을 입력하면 각 주소에 따라 서로 다른 콘텐츠가 나옵니다. 어떤 주소로는 단일 포스트 세부 내용이 나오고, 또다른 주소로는 아카이브 페이지가, RSS 피드가 나옵니다. 이게 어떻게 가능할까요? 이 원리를 간단히 알아봤습니다.

    슬라이드 보기

  • 워드프레스 코어 #1

    2020년 7월 2일 두번째 모임 발표

    워드프레스가 사용자로부터 요청을 받으면, 응답을 보내기까지 어떤 일들이 일어나는지 간략하게 알아본 자료입니다.

    슬라이드 링크

  • 워드프레스 개발자 관련 커뮤니티를 만들고 싶습니다

    강력한 워드프레스 개발자 커뮤니티를 구축하고 싶습니다.

    워드프레스 개발자니까 기반은 워드프레스로 작성하고 싶습니다. 탄탄한 사이트를 원합니다. 그래서 테마와 플러그인은 직접 개발하고 싶습니다. 개발자끼리 정보를 공유하고 개발 관련 이슈를 많이 논하는 커뮤니티로 만들고 싶습니다.

  • 내가 CPT UI나 ACF를 싫어하는 이유

    CPT UI의 문제점

    CPT UI를 쓰면 커스텀 포스트나 택소노미를 빠르게 생성할 수 있다. 하지만 빠른 것이 무조건 좋은 것만은 아니다. 콘텐츠의 성격이 커스텀 포스트로 잘 반영되어야 한다. 즉 커스텀 포스트 생성시 여러 속성을 통해 조절해야만 하지만 UI로 접근하는 사람들은 그런 디테일을 잘 고려하지 않는다.

    다만 CPT UI에서는 충분히 그런 디테일을 제공한다. 누차 얘기하지만 툴을 비난하는 것이 아니다. 나는 쓰는 사람들의 무심함을 꼬집어 이야기하고 싶은 것이다. 대개 이 플러그인을 쓰는 사람들은 디테일에 지나치게 무심하다.

    이름, 여러 레이블, 공개 여부, 쿼리 변수나 다시쓰기 슬러그, 위계성, 편집 화면의 지원 요소, 그리고 RSS 피드 제공 여부… 많은 요소들이 있지 않은가?

    한편 택소노미와 포스트 타입 생성을 위한 파라미터들은 정형화되어 있으므로 적절히 샘플 코드 정도로 을 만들어 두면 된다. 조금 길어 보일 수는 있어도 콘텐츠에 대한 상세한 고려를 위해서는 이렇게 하는 것이 좋다. 또 다르지만 비슷한 타입들도 굳이 UI를 통해 일일이 클릭하는 것보다는 코드로 빠르게 복제하는 것이 능률적이다. 굳이 플러그인까지 도입해서 처리해야 만들어야 하는 건지?

    ACF의 문제점

    ACF는 CPT UI보다 문제가 심각하다. ACF를 사용하면 나름 깔끔한 관리자 UI를 생성할 수 있다. 그러나 쉽고 편한 것이 반드시 좋다고 말하기는 어렵다. 사이트의 기능이 많고 복잡할수록 ACF는 그 복잡합을 더 증가시킨다.

    ACF의 가장 나쁜 점은 코드 곳곳에 흐름의 공백을 만들어낸다는 점이다. 개발자는 코드를 보면서, 코드의 흐름을 따라가면서 프로그램을 완성시킨다. ACF가 생성하는 커스텀 필드는 그 실체가 모두 데이터베이스에 저장되어 있다. 그래서 커스텀 필드를 이해하려면 관리자 페이지에서 ACF UI를 보면서 그 설계를 이해해야만 한다. 코드를 읽다가 UI로 넘어가는 일이 잦다는 점. 사이트가 커지면 커질 수록 이 문제는 점차 감당하기 쉽지 않게 된다.

    또한 데이터와 UI가 ACF에서 강하게 결합되어 버린다. 대개 ACF의 유연한 옵션 때문에 일반적으로는 나름 괜찮은 UI로 결론이 나지만, 때때로 복잡하거나 특정한 상황에서는 좀 더 효율적인 형태로 만들어져야 할 때가 있다. 그럴때 ACF는 개발자의 창의력을 붙잡아버린다. 더 이상의 무엇이 나오지 않는 것이다.

    뭐가 불만이었니?

    CPT UI, ACF(Advnced Custom Field)는 워드프레스 개발하면서 많이 찾는 플러그인이고, 인기 있는 플러그인이다. 둘을 쓰면 쉽고 빠른 제작에 도움이 된다.

    그러나 그럼에도 불구하고 나는 CPT UI, ACF를 좋아하지 않는다. 아, 그러나 오해는 없기를 바란다. 나는 그 두 플러그인 제작자에 대한 폄하는 추호도 없다. 내 호불호를 떠나 객관적으로 이 둘은 멋진 플러그인이다. 진심으로 나도 이런 플러그인을 만들면 좋겠다. 비유를 들면 CPT UI, ACF는 마치 칼 같은 그저 도구라는 것. 이 칼들에 그렇게 심각한 문제가 있다고는 생각하지 않는다. 다만 이 칼이 너무나 무분별하게 남용하고 있다는 것.

    이들은 작은 웹사이트, 혹은 사이트의 소유자가 직접 관리하면서 개발하려는 의지가 있을 때 엄청난 축복이다. 그러나 웹사이트를 전문적으로 제작하려는 사람, 좀 더 고도화된 기능을 개발하려는 사람에게는 이들은 좋은 옵션이 될 수 없다고 생각한다. 불행하게도 나는 후자에 있고, 후자의 시선으로 판단하기에 이런 의견을 블로그에 포스팅하는 것이다.