🙅‍♀️ GraphQL을 WordPress 코어에 포함해서는 안 되는 이유

네, 제목을 정확하게 읽으셨습니다. 저 자신이 WordPress용 GraphQL 서버의 제작자임에도 불구하고, WordPress가 GraphQL을 기본 탑재해야 하는지에 대한 생각이 바뀌었습니다.

얼마 전까지만 해도 저는 GraphQL이 WordPress 코어에 포함되어야 한다고 믿었습니다. 그 이유는 기여자들이 WP REST API를 위한 기능(배치 작업 등) 구현에 시간과 노력을 쏟고 있었기 때문입니다. 이는 GraphQL이 기본적으로 지원하는 기능입니다.

그러나 최근에 새로운 정보를 접하고 다시 생각하게 되었으며, 이제는 추가되는 위험성 때문에 WordPress가 GraphQL을 기본 탑재해서는 안 된다고 생각합니다.

다음은 그 이유들입니다.

​

1. 80/20 법칙을 충족하지 못한다

역사적으로, 특정 기능이 WordPress 코어에 추가되는 것은 80/20 법칙을 충족하는 경우에만 해당합니다. 즉, 사용자의 80% 이상이 해당 기능을 사용해야 합니다.

GraphQL의 경우는 어떨까요? WordPress 4.7에 WP REST API가 도입된 전례를 바탕으로 생각해 보면, 답은 "아니오"라고 생각합니다.

K. Adam White(WP REST API 초기 개발 및 릴리스의 주요 리드)는 그의 강연 WordPress as Data, 5 Years In에서, 기여자들은 REST API가 코어와 함께 출시되면 널리 사용될 것이라고 기대했다고 말했습니다. 그러나 그런 일은 일어나지 않았습니다. 개발자들은 이전과 같은 방식으로 WordPress 사이트를 계속 만들었으며, "헤드리스"나 REST API에는 거의 주목하지 않았습니다.

상황이 바뀐 것은 나중에, WordPress 5.0에서 REST API를 기반으로 하는 Gutenberg 편집기가 도입되었을 때였습니다. 그렇다면 Gutenberg가 GraphQL을 WordPress 코어에 추가하는 것을 정당화할 수 있을까요?

​

2. 헤드리스는 이미 REST API로 충족되고 있다

WordPress 편집기는 네이티브 GraphQL 서버로 강화될 수 있으며, 블록 개발자들이 (기존 REST API에 더하여) GraphQL을 사용하여 블록의 데이터를 가져올 수 있게 됩니다. 또한 테마와 플러그인이 GraphQL을 사용하여 자체 내부 기능을 강화할 수도 있습니다. 이것들은 GraphQL을 WordPress 코어에 추가하는 강력한 이유입니다.

그러나 WordPress에는 이미 REST API가 있으며, GraphQL로 할 수 있는 모든 것은 REST로도 할 수 있습니다. REST에 더하여 GraphQL을 도입하는 것은 이미 Toyota를 운전하고 있는데 BMW를 사는 것과 같습니다. 목적지에 더 빨리 도착할 수 있고, 운전 경험도 더 매력적일 것입니다. 그러나 두 차 모두 원하는 곳으로 데려다 줄 것입니다.

GraphQL이 이전에는 사용할 수 없었던 기능을 제공하는 것이 아니기 때문에, 코어에의 포함은 완전히 정당화되지 않습니다. GraphQL은 API와의 상호작용 경험을 분명히 향상시키겠지만, 이는 플러그인 영역으로 충분히 고려될 수 있습니다.

​

3. WordPress 테마와 플러그인은 webonyx/graphql-php를 사용할 수 있다

공개 플러그인은 플러그인을 사용하기 위해 WPGraphQL이나 Gato GraphQL을 설치하도록 웹사이트에 요구할 수 없습니다. 그렇게 하면 잠재적인 도달 범위가 줄어들기 때문입니다. 따라서 공개 플러그인은 GraphQL에 의존할 수 없으며, 이것은 정말 아쉬운 일입니다.

저는 이 문제에 대해 깊이 고민하여 잠재적인 해결책을 생각해 냈습니다. 바로 GraphQL API Private입니다. 이것은 플러그인이 자체 용도로 내장할 수 있는 독립형 GraphQL 엔진으로, Composer 패키지로 배포됩니다. (이 프로젝트는 아직 시작하지 않았습니다.)

그런데 몇 주 후, GraphQL 기반의 WordPress 플러그인이 출시되었습니다. 작성자가 어떻게 했는지 궁금했습니다. WPGraphQL이나 Gato GraphQL을 내부적으로 사용하고 있을까요? 그래서 소스 코드를 확인했더니, 직접 webonyx/graphql-php를 사용하고 있었습니다!

이것은 흥미로운 해결책으로, 약간의 노력으로 개발자들이 현재도 테마와 플러그인을 위해 GraphQL에 접근할 수 있음을 보여줍니다.

이 플러그인은 GraphQL을 사용하여 WordPress(게시물, 사용자, 댓글 등)의 데이터 엔티티가 아닌 자체 데이터 엔티티를 가져옵니다. 따라서 WPGraphQL과 Gato GraphQL(그리고 결국에는 GraphQL API Private)이 하는 것처럼 WordPress 데이터 모델을 포함하는 GraphQL 스키마를 재구성할 필요가 없습니다. 그런 의미에서, webonyx/graphql-php에 의존하는 것은 합리적입니다.

​

4. GraphQL에는 추가적인 위험이 있다

위의 세 가지 문제는 모두 GraphQL이 WordPress를 강화하지만, 그렇게까지 설득력 있는 것은 아님을 시사합니다. 이 관점에서 보면, 여전히 GraphQL을 WordPress 코어에 추가할 수 있으며, 그로부터 혜택을 받거나 아무 일도 일어나지 않을 수 있습니다.

그러나 이 네 번째 문제는 GraphQL이 WordPress에 큰 가치를 추가하지 않는다면, 추가적인 위험이 있기 때문에 추가해서는 안 된다는 것을 시사합니다.

GraphQL은 (다른 것들 중에서도) 다음과 같은 공격 벡터에 취약합니다:

• 단일 엔드포인트가 웹사이트의 모든 정보에 대한 접근을 제공하므로, 비공개 데이터가 의도치 않게 노출될 수 있습니다.
• 쿼리가 매우 복잡해질 수 있으며, 웹 서버와 데이터베이스 서버에 과부하를 줄 수 있습니다.
• 동일한 뮤테이션을 단일 쿼리에서 여러 번 실행할 수 있으며, 여러 쿼리를 단일 요청에서 함께 실행할 수 있어 공격자가 많은 사용자 이름/비밀번호 조합을 시도하여 백엔드 접근을 시도할 수 있습니다.

이러한 공격은 정말 심각한 피해를 줄 수 있습니다. 사이버보안 연구원 Dolev Farhi는 발표 Damn GraphQL - Defending and Attacking APIs에서 복잡한 쿼리 배치로 WPGraphQL 엔드포인트를 공격하여 30초 이내에 WordPress 사이트를 다운시키는 데 성공했습니다.

WPGraphQL 팀은 즉시 문제를 수정했습니다. 그러나 다른 취약점이 발생하지 않는다고 어떻게 확신할 수 있을까요? (WPGraphQL뿐만 아니라 Gato GraphQL도 포함하여)

이러한 공격은 GraphQL에서는 일어날 수 있지만, REST에서는 일어나지 않습니다. 왜냐하면 GraphQL이 REST보다 더 강력하기 때문입니다. REST에서는 쿼리가 사전에 정의되어 서버에 저장되지만, GraphQL에서는 (persisted queries를 사용하지 않는 한) 런타임에 클라이언트로부터 제공됩니다.

웹사이트 관리자가 엔드포인트에 접근할 수 있는 사람이나 노출되는 데이터를 설정하는 데 소홀하면 나쁜 일이 발생할 수 있습니다. 기술에 익숙하지 않은 수백만 명의 사람들이 사용하는 WordPress의 인기를 감안하면, 나쁜 일이 발생할 가능성이 매우 높습니다.

​

마무리

확실히 말씀드리지만, 저는 WordPress에서 GraphQL을 사용하지 말라고 주장하는 것이 아닙니다(물론 그런 말을 하는 것이 아닙니다!). 책임감 있게 GraphQL을 사용하자는 것입니다. GraphQL은 강력하며, 그것은 위험하기도 합니다. GraphQL을 사용할 때는 자신이 무엇을 하고 있는지 확실히 알고 있어야 합니다.

GraphQL을 WordPress 코어에 탑재하면 많은 사람들의 손에 들어가게 되고, 그 중 많은 이들은 그 위험성을 인지하지 못하고 적절한 조치를 취하지 않을 것입니다. 이는 잠재적인 재앙의 원인이 됩니다. 따라서 지금 저의 의견으로는, 이를 피해야 한다고 생각합니다.