Herding Cats — WordPress 환경을 개발하는 동안 배운 교훈

Elementor 3.0이 1년 전인 2020년에 출시되었을 때 우리는 이를 더 빠르고 훨씬 더 강력한 편집기를 향한 중요한 단계로 보았습니다. 그것이 사실이지만, 이 버전은 또한 중요하고 예상치 못한 결과를 가져왔습니다. 그것은 상당수의 사이트가 작동을 멈추게 했고 솔직히 말해서 우리의 평판을 손상시켰습니다. 이 릴리스 이후에 이러한 사이트를 다시 작동시키기 위해 일련의 수정 사항을 마련해야 했습니다. 또한 전체 경험을 통해 전체 테스트 및 릴리스 절차를 점검해야 함을 알 수 있었습니다. 고통스럽긴 하지만 이 프로세스는 v3.0과 v3.4 버전의 릴리스 사이에 특히 중요한 문제가 크게 감소한 것을 반영하여 오늘날 성과를 거두고 있습니다.

이제 Elementor 3.0의 1주년이 다가옴에 따라 릴리스에 수반되는 문제가 다시 발생하지 않도록 하기 위해 우리가 마련한 절차를 되돌아보고 검토하는 것이 좋습니다. 커뮤니티와 가능한 한 투명하게 공개하기 위해 3.0 릴리스를 둘러싼 문제의 배경, 작년에 우리가 취한 조치, 안정적인 릴리스를 보장할 수 있었던 방법 및 미래가 무엇인지 조사하고 싶습니다. 그러나 먼저 Elementor의 역사와 WordPress 환경 내에서 복잡하고 정교한 플러그인을 개발하는 데 직면한 문제를 이해하는 것이 중요합니다.

Elementor와 WordPress 챌린지

2016년 6월에 Elementor의 첫 번째 버전을 출시했을 때 우리는 플러그인을 개발하고 사람들이 웹사이트를 구축하는 것을 돕는 것을 좋아하는 소수의 "아이들"이었습니다. 이것은 우리의 첫 번째 제품이 아니었고 WordPress 커뮤니티에서 사용되는 몇 가지 플러그인을 이미 개발했습니다. 하지만 Elementor를 작업하면서 우리는 뭔가 특별한 것을 개발하고 있다는 확신을 갖게 되었습니다. 결과적으로 우리의 생각이 맞았습니다. 첫 번째 릴리스 후 몇 개월 만에 수만 명의 사용자가 이미 Elementor를 설치했으며 이를 사용하여 전 세계적으로 웹사이트를 구축하고 있었습니다.

그 이후로 우리 회사는 더 많은 개발자, 더 많은 사용자, 더 많은 기능으로 모든 면에서 성장했습니다. 이러한 성장과 함께 중요하지만 더 일상적인 문제는 제쳐두고 긴급한 문제에 집중하면서 기술 적자 증가를 포함하여 새로운 문제가 많이 발생했습니다.

이러한 문제를 처리하는 것은 워드프레스 환경의 특성으로 인해 발생하는 전반적인 문제로 인해 훨씬 ​​더 어려워졌습니다.

개방형 플랫폼인 WordPress는 개발자에게 여러 가지 큰 이점을 제공합니다. 릴리스를 모니터링하고 속도를 늦추는 몇 가지 장애물이 있습니다. 개념이 상상되고 개발되어 저장소에 추가됩니다. 사용자는 이러한 제품을 시도하고 테스트하고 판단하며 시장에서 어떤 제품이 성공하고 실패할지 결정합니다. 그러나 이러한 속도와 단순함에는 대가가 따릅니다.

WordPress 환경에는 균일성이 거의 없고 질서 있는 워크플로가 없습니다. 웹 제작자는 방대한 플러그인, 테마 등을 사용하면서 사이트 환경을 자유롭게 정의할 수 있습니다. 즉, WordPress 사이트에는 플러그인, 테마 및 서버 구성의 무수한 조합이 포함되어 있습니다.

또한 릴리스 프로세스의 단순성과 강력한 배포 도구의 부재로 인해 WordPress 개발자는 CI/CD, Canary 배포 및 기능 플래그와 같은 최신 릴리스 개념을 활용할 수 없습니다.

개방성은 WordPress의 아름다움의 일부이지만 내재된 다수의 사이트 및 서버 구성은 플러그인 충돌 및 특정 서버 문제를 설명할 때 개발자에게 진정한 문제를 안겨줍니다.

우리의 경우 Elementor가 점점 더 많은 웹사이트에 사용되면서 이러한 다양한 조합을 모두 지원해야 했기 때문에 출시 일정이 늦어지고 새로운 기능 개발을 주저하게 되었습니다. 말할 필요도 없이, 이 상황은 용납될 수 없었고 우리는 상황을 흔들어야 했습니다.

기존 기능을 훼손하지 않고 새로운 기능 개발

위의 모든 요소는 이미 Elementor에 의존하고 있던 사람들의 작업에 부정적인 영향을 미치지 않으면서 어떻게 계속 개발하고 개선할 수 있는지에 대한 딜레마를 남겼습니까?

우리는 릴리스 프로세스에서 몇 가지 작은 변경 사항을 구현하는 것으로 시작했습니다. Elementor 1.5에서는 개발자에게 베타 버전에 대한 액세스 권한을 제공하기 시작했습니다. 우리는 릴리스 전에 이 버전이 다양한 플러그인/테마/환경 조합과 어떻게 상호 작용했는지 표시하고 초기에 비호환성에 대해 경고하는 피드백을 받을 수 있는 Github 및 기타 커뮤니티를 통해 이 작업을 수행했습니다. 이 접근 방식은 한동안 잘 작동했지만 Elementor가 성장함에 따라 우리는 이것이 충분하지 않다는 것을 알게 되었습니다.

이때까지 우리는 500만 설치 임계값을 넘었습니다. 놀라운 성과인 동시에 이 모든 웹사이트가 원활하게 작동하도록 해야 한다는 의미이기도 합니다.

Elementor 3.0이 출시되면서 마침내 상황이 해결되었습니다. 이 버전에서 우리는 로딩 속도를 높이기 위해 DOM 요소를 제거하고 오래된 것처럼 보이는 일부 기능을 삭제하기로 결정했습니다. 이것은 최소한 부분적으로는 우리가 시스템에 불필요하게 부담을 주고 있다는 정당한 불만에 대한 응답이었습니다.

불행히도 이 변경으로 인해 우리가 삭제한 코드에 의존하던 많은 사이트가 업그레이드 중에 중단되었습니다. 타사 개발자를 프로세스에 참여시키려는 노력에도 불구하고 이러한 버그는 여전히 발견되지 않았으며 상황을 수정하기 위해 신속하게 움직여야 했습니다. 결국, 우리는 업그레이드의 일부를 선택 사항으로 만들어 그렇게 할 수 있었지만 커뮤니티의 일부 구성원이 플러그인의 안정성에 대한 신뢰를 흔들기 전에는 그렇지 않았습니다.

이 경험을 통해 우리는 개발 프로세스를 오랫동안 열심히 살펴보고 많은 주요 변경 사항을 적용해야 했습니다. 우리의 프로세스는 우리 규모와 설치 기반의 회사에 적합하지 않았습니다. 첫 번째이자 아마도 가장 명백한 움직임은 QA 팀의 규모와 범위를 늘리는 것이었지만 여전히 많은 미해결 문제로 씨름하고 있었습니다.

• 수많은 사이트 설정과 버전의 호환성 확인
• 5백만 개 이상의 기존 사이트와의 역호환성 보장
• 수백 가지 타사 Elementor 확장의 호환성 확인

이러한 모든 문제를 처리하기 위해 WordPress 세계에 최신 소프트웨어 개발 방법을 가져와야 했습니다.

피드백 루프

일반적으로 개발이 직면한 큰 문제 중 하나는 사용자가 릴리스된 후에만 업데이트를 경험한다는 것입니다. 이는 사용자로부터 피드백을 받을 때까지 기능이 이미 설계, 개발 및 출시되었음을 의미합니다. 수백 개의 타사 확장 및 플러그인을 처리하는 우리의 경우 이 피드백 루프의 문제가 훨씬 더 중요합니다.

이 피드백 루프를 단축하는 방법을 찾기 위해 브라우저 개발자가 우리와 매우 유사한 문제를 처리하는 방법을 살펴보았습니다. 또한 수많은 타사 웹 페이지, 앱, 확장 프로그램 등과의 호환성도 보장해야 합니다.

예를 들어 Google에서 Chrome 브라우저용으로 개발한 시스템을 조사했습니다. 개발자는 언제든지 베타 버전, 개발자 버전 및 야간 버전의 세 가지 브라우저 버전에 액세스할 수 있습니다. 즉, 개발자는 새로운 Chrome 기능을 조기에 살펴보고 버전이 공식적으로 출시되기 훨씬 전에 Google에 피드백을 제공할 수 있습니다.

이러한 교훈을 플러그인에 적용하여 Elementor는 WordPress 저장소에서 사용할 수 있는 자체 개발자 에디션인 Elementor Beta(개발자 에디션)를 출시하기 시작했습니다. 이 에디션은 말하자면 "보도적인" 우리의 새로운 기능을 확인하는 데 관심이 있는 개발자를 대상으로 합니다.

물론 우리는 호환성 문제에 대한 조기 경고를 수신함으로써 이익을 얻습니다. 개발자 에디션을 사용하면 이러한 모든 새로운 기능에 액세스할 수 있을 뿐만 아니라 버그 보고를 위한 Github에 대한 직접 링크도 있습니다. 즉, 기존 웹 사이트를 위험에 빠뜨리지 않고 새로운 기능을 지속적으로 배포하고 이에 대한 피드백을 받을 수 있습니다. 개발자는 이를 통해 향후 공식 릴리스를 미리 준비할 수 있으므로 자체 호환성 문제를 방지하고 기능이 아직 작업 중인 동안 제품 및 기술 피드백을 제공할 수 있는 기회를 얻을 수 있습니다.

개발자 에디션의 릴리스는 Elementor 릴리스를 개발하는 데 사용되는 일반 프로세스(알파, 베타, RC 및 프로덕션)와 병렬로 실행됩니다. 우리가 새로운 기능을 개발할 때 사용하기에 충분히 안정적이지만 아직 알파 단계인 동안 개발자 에디션에 추가합니다. 이렇게 하면 기능이 베타에 도달하기 전에도 개발자가 피드백을 제공할 수 있습니다. 또한 개발자 에디션에는 베타 단계에 도달하지 않은 기능이 포함되어 있습니다.

기본적으로 베타 단계는 의도적인 디버깅 프로세스를 위해 예약되어 있는 반면 개발자 버전은 가장 초기 단계의 기능을 통합하여 더 자주 업데이트됩니다.

개발자 에디션은 출시 이후 1년도 채 되지 않아 40,000개 이상의 설치를 달성하여 큰 성공을 거두었습니다.

"실험적" 기능 소개

수년에 걸쳐 개발자들이 수용한 또 다른 개념은 기능 플래그이며, 이는 특히 SaaS 세계에서 널리 퍼져 있습니다. 일반적인 아이디어는 이러한 기능 플래그를 사용하여 개발자가 새로운 기능을 테스트하고 작동 방식을 확인하기 위해 다양한 사용자 세그먼트에 대해 새 기능을 켜고 끌 수 있다는 것입니다.

위에서 언급했듯이 3.0 릴리스에서 비롯된 많은 문제는 이전 코드를 제거하는 새로운 기능으로 인해 발생했습니다. 이러한 종류의 문제를 피하기 위해 우리는 기능 플래그와 유사한 접근 방식을 채택하기로 결정했습니다.

Elementor 3.1부터 우리는 새로운 기능을 "실험적"으로 표시하여 더 신중하게 출시하기 시작했습니다. 여기에는 새로운 기능을 단계적으로 도입하는 시스템이 포함됩니다. 이 시스템에서 새로 개발된 기능은 "알파"로 표시됩니다. 이는 기본적으로 모든 사이트에서 꺼져 있음을 의미합니다. 더 안정적인 것으로 입증됨에 따라 "베타"가 됩니다. 즉, 이제 기본적으로 새 사이트에 대해 켜져 있고 기존 사이트에 대해 꺼져 있습니다. 안정적인 것으로 확인되면 모든 사이트에 대해 기본적으로 켜져 있습니다. 그럼에도 불구하고 제한된 시간 동안 사용자가 기능을 비활성화할 수 있는 옵션이 있습니다.

이 시스템을 통해 우리는 Elementor를 계속 개발하여 기능 세트와 속도를 모두 추가할 수 있으며, 동시에 제작자는 사이트의 필요에 따라 이러한 새로운 업그레이드를 선택하거나 선택 해제할 수 있습니다. 이는 또한 제작자가 새로운 기능을 더 신중하게 채택할 수 있도록 하여 사이트를 업데이트하는 데 도움이 됩니다.

호환성 태그

Elementor의 매우 활발한 개발자 커뮤니티의 성장은 자부심의 큰 원천이 되었지만 그 자체로 도전 과제이기도 했습니다. 타사 개발자는 기존 기술을 기반으로 수백 가지 확장, 테마, 키트 및 위젯을 만들었습니다.

이러한 타사 추가 기능의 개발자를 지원하기 위해 개발자 블로그와 메일링 리스트를 사용하여 API에 대한 변경 사항과 사용 중단에 대한 조기 통지를 제공했습니다. 그러나 위에서 언급했듯이 우리는 이것으로 충분하지 않다는 것을 발견했습니다. 새 릴리스에서 경험한 많은 문제는 이러한 타사 추가 기능으로 인해 호환성 문제가 발생했습니다. 우리 플러그인은 우리 기술 때문이 아니라 이러한 타사 비호환성 때문에 불안정한 것으로 보였습니다.

다시, 우리는 다른 사람들이 영감을 얻기 위해 무엇을 하고 있는지 살펴보았습니다. 이 경우 WooCommerce 및 타사 개발자와 협력하는 접근 방식. 3.1 릴리스부터 타사 개발자가 확장 기능이 새 버전과 호환됨을 인증하는 시스템을 시작했습니다(자세히 알아보기). 그런 다음 사용자에게 Elementor를 업그레이드할 수 있는 옵션이 제공되면 사용 중인 타사 확장 목록과 새 버전의 Elementor와 호환되는 것으로 인증되었는지 여부가 표시됩니다. 이러한 방식으로 사용자는 업그레이드에 대한 정보에 입각한 결정을 내릴 수 있습니다.

더 나은 미래를 향해

이러한 도전과제와 우리가 구현한 변경 사항을 간략하게 설명함으로써 전 세계적으로 사용할 수 있는 제품을 오픈 소스로 끊임없이 변화하는 환경에서 개발하는 것이 어떤 것인지 살짝 엿볼 수 있기를 바랍니다. 이 오픈 소스 문화의 일환으로 사용자 및 개발자 커뮤니티에 투명하게 공개하는 것이 중요합니다. 회사가 성장하고 "개인적인 접촉"을 유지하기가 더 어려워질수록 더욱 그렇습니다. 사용자의 고통이 우리의 고통이기 때문일 뿐만 아니라 Elementor가 가능한 한 광범위한 사용자에게 개방된 안정적인 도구를 유지하는 가장 좋은 방법이기 때문입니다.

우리는 우리가 구현한 변경 사항이 Elementor의 성장과 성공에 기여했으며 앞으로도 계속 기여할 것이라고 굳게 믿습니다. 그러나 우리는 아직 해야 할 일이 있고 Elementor와 Elementor 커뮤니티 간의 커뮤니케이션이 열려 있어야 하고 개선되어야 한다는 것도 알고 있습니다. 예를 들어, 개발자 리소스 사이트를 업그레이드하여 개발자가 Elementor를 사용자 지정하고 빌드하는 데 도움이 되는 사용하기 쉬운 설명서를 제공합니다.
그러나 아마도 의사 소통을 개선하기 위해 취한 가장 중요한 단계는 Elementor Community Hub를 구축하는 것입니다. 여기에서 전 세계의 웹 제작자는 서로 아이디어를 교환하고 우리와 함께 아이디어를 교환할 수 있습니다. 함께 협력하여 Elementor를 최고로 만들 수 있습니다. 결국 옛말에서 알 수 있듯이 고양이를 치는 것은 거의 불가능하지만 함께 일하면 프라이드라고 합니다.