워드프레스 엘리멘터 빌더를 쓰는 이들에게는 꽤 오래전부터 아토믹 에디터(Atomic Editor) 안내가 뜨고 있었다. 한번 납품으로 사실상 특별한 업데이트를 하지 않는 정적인 사이트(정적 사이트가 아니라 정적인 사이트)라면 신경 쓰지 않을 수 있다. 계속 운영하면서 매번 업데이트를 쫓아가는 동적인 사이트라면, 언젠가는 마주해야 할 것이라 보였다.
테스트 서버에서 베타 기능으로 활성화했었던 그땐 몰랐다. 애초에 테스트 서버는 스펙이 매우 모자란 서버라, 버벅댐이 당연하고 리소스를 꽉 채워 쓰는 것이 당연했다. 아토믹 에디터 영향이 있으리라고는 전혀 예상치 못했다.
아토믹 에디터 사용법은 테스트 서버에서 적당히 익혔다
아토믹 에디터는 기존 에디터 대비, 각 위젯의 세부 설정 위치가 꽤 많이 바뀌었다. 간격, 크기, 위치는 물론이고, 배경이나 고급 설정 위치도 싹 바뀌었다.
아토믹 에디터 스타일에 맞춘 아토믹 위젯(Atomic Widget)도 추가됐다. 기존 위젯을 모두 커버할 정도는 아니지만, 기본 용도로 쓰는 위젯인 플렉스 박스, 제목, 텍스트, 이미지 등등은 다 새로 추가됐다. 물론 그렇다고, 새 위젯만 써야 하는 건 아니다. 기존 위젯도 동시에 쓸 수 있다. 여기서부터 아리송해진다. 이렇게 둘을 다 병행 사용할 거라면, 기존 위젯 완전 대체는 한참 먼 미래겠구나 싶다.
싱글 페이지를 새로 만드는 김에 아토믹 에디터를 도입해 보자
싱글 페이지를 추가할 일이 생겼다. 항상 모든 일에는 계기가 중요한 법이다. 계기가 생긴 김에 간단한 싱글 페이지에 엘리멘터 4.0 업데이트로 정식 버전이 된 아토믹 에디터를 써보기로 했다.
모든 위젯을 대처하지 못하다 보니, 쓰다 보면 구버전과 동시에 사용해야 하는 경우는 필연적으로 등장했다. 이때부터 위젯 세부 설정에 혼란이 생기기 시작했다. 그러다 반응형 설정에서 극한을 향했다. 기존 위젯은 반응형 메뉴 자체가 설정 메뉴에 있다. 아토믹 위젯은 반응형이 따로 있기보다, 각 뷰별 화면을 누른 후에 설정을 잡아야 한다. 글로 상황을 표현하려니 쉽지 않지만, 아무튼 반응형 설정이 더 까다로워졌다.
나름 꼼수로 쓰던 PC에서만 보이고 나머지에선 숨기기를 한 후, 모바일뷰 위젯을 따로 하나 더 추가해서 작업하던 형식은 거의 불가능해졌다. 꼼수 없이 정직하게 만들어야 한다니... 그러기엔 모든 위젯이 아토믹 에디터용으로 나오지도 않았고, 우선 할 수 있는 최선의 조치로 간단한 싱글 페이지를 비공개 발행했다.
리소스 과다 사용 알림이 오기 시작했다
안 그래도 온갖 크롤러가 마구잡이로 휘젓고 다니는 서버라, 이런저런 조치를 해둔 서버였다. 어뷰징 또는 과대 호출 크롤러는 Nginx에서 1차 차단 처리하고, 다시 2차로 웹 방화벽이 잡는다. 레디스로 오브젝트 캐시를 써서 PHP 호출을 커버하고, 다시 웹 캐시를 써서 HTML/CSS/JS를 커버하는 형태로 계속 보완을 해뒀다. 그래서 어지간해선 2주 평균치로 요약해서 볼 땐 40%를 넘어서기 쉽지 않다.
특히 최초 튐 현상이 극한으로 올라가기 시작한 5월 8일 밤은 휴일 시작이라, 정작 트래픽 자체는 뚝 떨어지는 시점이라 리소스 소모는 줄어야 했다. 처음엔 그저 크롤러가 또 서버를 괴롭힌다고만 생각했다.
어차피 능사는 없지 않은가, 하나하나 다 뒤져보자
평시 트래픽 유휴 상태는 20% 이하에서 머물러야 정상인데, 20%를 계속 넘어선다. 40% 이하면 되긴 하지만, 괜히 30% 아래위로 걸쳐있는 상태가 매우 신경 쓰였다.
별수 없지 않은가. 다 뒤져야 했다. 숨어있는 크롤러, 슬로우 쿼리, 과다 점유 프로세스, 네트워크 호출 속도 등등 AI와 함께 전체를 하나하나 점검했다. Nginx 액세스 로그에 각 호출별 응답 시간을 같이 남기고 있었기에, 소모 시간이 2초 이상 걸리는 모든 호출을 하나하나 열어봤다. 로그 예시는 아래에 올려 놓는다.
110.93.150.52 - - [20/May/2026:13:18:22 +0000] "https://********" "GET /******** HTTP/1.1" 200 45593 "https://**********" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko; compatible; Yeti/1.1; +https://naver.me/spd) Chrome/144.0.0.0 Safari/537.36" | fw_ip="-" real_ip="-" cf_ip="-" | ip_status="1" agent_status="0" | time:0.000초
211.249.46.73 - - [20/May/2026:13:18:57 +0000] "https://********" "GET /?p=114019 HTTP/1.1" 301 5 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko; compatible; Yeti/1.1; +https://naver.me/spd) Chrome/144.0.0.0 Safari/537.36" | fw_ip="-" real_ip="-" cf_ip="-" | ip_status="1" agent_status="0" | time:0.487초
211.249.46.73 - - [20/May/2026:13:18:59 +0000] "https://********" "GET /****** HTTP/1.1" 200 38295 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko; compatible; Yeti/1.1; +https://naver.me/spd) Chrome/144.0.0.0 Safari/537.36" | fw_ip="-" real_ip="-" cf_ip="-" | ip_status="1" agent_status="0" | time:0.936초
110.93.150.204 - - [20/May/2026:13:20:35 +0000] "https://********" "GET /****** HTTP/1.1" 200 39762 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko; compatible; Yeti/1.1; +https://naver.me/spd) Chrome/144.0.0.0 Safari/537.36" | fw_ip="-" real_ip="-" cf_ip="-" | ip_status="1" agent_status="0" | time:1.165초
110.93.150.179 - - [20/May/2026:13:21:04 +0000] "https://********" "GET /****** HTTP/1.1" 200 61219 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko; compatible; Yeti/1.1; +https://naver.me/spd) Chrome/144.0.0.0 Safari/537.36" | fw_ip="-" real_ip="-" cf_ip="-" | ip_status="1" agent_status="0" | time:0.023초
114.111.32.112 - - [20/May/2026:13:23:50 +0000] "https://********" "GET /****** HTTP/1.1" 200 39735 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko; compatible; Yeti/1.1; +https://naver.me/spd) Chrome/144.0.0.0 Safari/537.36" | fw_ip="-" real_ip="-" cf_ip="-" | ip_status="1" agent_status="0" | time:0.896초잡초를 다 뽑아도 계속 튄다
외부 요인으로 서버 리소스를 쓴다고 생각했는데, 전체 로그를 하나하나 뜯어보면서 생각이 바뀌었다. 비공개 발행한 페이지를 편집하거나, 테스트 접속하는 시점 등등에 소모량이 많은 걸 당연하게 여긴 것도 문제였다.
정확히 아토믹 에디터를 활성화한 직후에 튀어 오른 건 아니었다. 하지만, 활성화한 이후부터 튀어 오르는 현상이 매우 잦아졌단 걸 연계해서 떠올리지 못했던 것이 문제였을지도 모르겠다.
AI도 헤매고, 나도 헤메고... 혹시나 하는 생각에 아토믹 에디터 영향이 있는 걸까 싶어서, 퍼플렉시티 검색을 돌렸다. 커뮤니티 사이트, 깃허브 이슈, 깃허브 디스커션 등에 올라온 내용이 있는지. 그리고 얻은 답은 너무 시원한 한방의 답변이 나왔다. 역시 AI는 Garbage In, Garbage Out이 맞는듯..
상세 내용은 딱 한두 개 리포트가 아니라 여러 리포트가 있으므로, 검색을 위한 링크와 프롬프트로 대처하는 것이 더 맞을 듯 하다.
아래 두 링크에서 엘리멘터 빌더 4.0 이후 추가된 Atomic Editor로 인해 서버 리소스를 과다 소모하는 건에 대해 접수되거나 토론되는 사례가 있는지 찾아서 정리해 줘.
- https://github.com/orgs/elementor/discussions/categories/editor-v4
- https://github.com/elementor/elementor/issues비활성화 이후 안정됐다
어차피 모든 위젯을 대처해주지 못하던 아토믹 에디터와 아토믹 위젯이다. 싱글 페이지에서 아토믹 관련 리소스를 싸악 지우고 구형 위젯으로 바꿀까 하다가, 리비전에도 남겨두기 싫어서 아예 새로 페이지를 만들었다. 기존에 만든 건 완전히 영구 삭제했다.
페이지 세팅을 마친 후, 아토믹 에디터 자체를 비활성화했다. 그리고, 더 이상 서버 알림은 오지 않았다. 아마도 이렇게 일단락을 맺었다고 볼 수 있지 않을까? 엘리멘터는 계속 아토믹 에디터 활성화를 푸시하겠지만, 이 현상이 확실히 해소되지 않는다면 다시 도입은 하지 않을 것 같다.
해소된 건 어떻게 알 수 있을까? 업데이트 릴리스 노트에 넣어주려나? 계속 깃허브 모니터링을 해야 하나?