강조한다. 이 플러그인을 결코 엘리멘터 프로의 불법복제를 장려하려고 만든 것이 아니다. 단지 개발 사이트에서 개발을 할 때 불편을 덜기 위한 임시 용도임을 명확히 한다. 단지 눈에 보이는 알림만을 보이지 않게 하는 것일 뿐이다. 만일 엘리멘터 프로가 라이센스 불일치를 감지해 기능에 제약을 걸 경우, 이 플러그인은 그런 제한을 푸는 – 소위 크랙(crack) 과 같은 행위는 절대 하지 않는다. 그러니 그냥 개발 용도라만 사용하시라. 라이센스는 별도로 걸지 않는다. 자유롭게 받아 사용하시라.
그런데 UI가 조막만해서 IP를 일일이 관리하고 차단하기가 너무 어려웠어요. 오호라? UI를 잘 보니 규칙을 파일로 백업하는 기능이 있었지 뭡니까? 이것으로 .cfg라는 파일을 생성하는 것을 확인하였습니다.
Type=firewall # Do not modify
Version=1.0.0 # Do not modify
lang=utf-8 # Do not modify
[차단 #1]
enable = 1
schedule = 0000000 0000 0000
flag = 0
{
direction = outin
src_type = ip
dest_ip_address = {start}-{end}
protocol = none
policy = drop
}
[차단 #2]
enable = 1
schedule = 0000000 0000 0000
flag = 0
{
direction = outin
src_type = ip
dest_ip_address = {start}-{end}
protocol = none
policy = drop
}
위는 그 cfg 파일의 샘플입니다. 대략 24시간 외부에서 내부로 접속하는 특정 IP 대역을 차단하도록 설정한 예입니다. {start}와 {end}에 각각 IPv4 형태로 문자열을 넣어주면 됩니다.
처음에는 한국 인터넷 정보 센터 (KRNIC)에 가서 모든 국가별 IP 할당 대역을 파악한 후, 특정 국가의 IP를 전부 차단시킬 생각습니다. 그러나 공유기의 성능 한계가 있어 200개까지 등록되지 않는다는 제약이 있어 이렇게는 할 수 없더군요. 예를 들어, 중국의 모든 IP 대역 등록건만 해도 8000여개에 달하니까요.
그래서 이렇게 많은 양의 IP 대역에 대해 애쓰기보다는, 관리자 로그 파일을 보고 내 공유기에 천착하는 IP만 차단하기로 했습니다. IP 타임 관리자 로그를 보면 다음처럼 나옵니다.
2022/03/11 09:02:22 DHCP 서버가 IP 할당함: 192.168.10.32 (MAC : XX-XX-XX-XX-XX-XX)
2022/03/11 08:20:19 잘못된 VPN 계정 또는 암호로 접속을 시도 하였습니다(qq, XXX.XXX.XXX.XXX)
2번째줄입니다. 어디선지는 모르지만 VPN 계정이나 관리자 로그인을 노리고 집요하게 뭔가 하는 것입니다. qq라는 id로 로그인 실패를 했고, 뒤에 원격 IP가 나옵니다.
IP 조회를 해 보면, 진짜 아무 연고도 없는 곳입니다. 이제 로그 특정 부분을 따다 IP 부분만 수집합니다.
처럼 입력합니다. 그러면 rule.cfg 파일이 만들어 집니다. 그럼 이 cfg 파일을 공유기에 올려 두면 됩니다.
1번을 눌러 파일을 선택, 2를 눌러 공유기로 전송
저는 이렇게 적용 후, 확실히 해당 지역에서 무단 접속이 사라진 것으로 보입니다. 효과가 나름 있는 거 같네요. 다만 공유기의 로그도 무한히 있는 것도 아닙니다. 최대 400개가 한계이니 더 다양한 IP를 차단할 수 있으려면 좀 더 로그나 IP를 쌓아두고 관리하면서 차단할 수 있어야 하겠네요. 일단 이번에는 여기까지 만들어 보고 더 나은 버전은 차후에 고민해 보겠습니다.
덧, 이후 계속 “잘못된 VPN 계정 또는 암호로 접속을 시도 하였습니다” 메시지와 차단한 IP가 기록되네요. 이 방법으로는 접속 자체를 막지 못하는 것 같습니다.
워드프레스 사이트 이용을 하다 보면 별 희한한 버그를 만날 때가 가끔씩 있다. 뭐, 사실 대부분은 내가 짠 프로그램에서 나는 버그지만, 가끔은 진짜 서드파티 플러그인의 버그일 때도 있고 아니면 내가 만든 플러그인이 아닌 레거시에서 의도치 않은 버그가 나올 때가 있다.
이럴 때는 모든 테마와 플러그인을 완전히 끄고 하나하나 켜 가면서 범인을 색출하는 방법이 있다. 워드프레스에는 수많은 필터와 액션이 뒤엉켜 돌아가기 때문에 문제 파악이 매우 어려울 수도 있다. 그러므로 이럴 땐 기능을 꺼보면서 시작점을 찾아 보는 것이 가장 단순명료하다.
그런데 문제가 있다. 운영 중인 사이트에 함부로 플러그인과 테마를 껐다 켤 수는 없다. 사이트의 기능이 멈출 수도 있기 때문이다. 과연 이럴 때는 어떻게 해야 할까?
불타는 금요일을 보내고 토요일 새벽까지 디버깅을 한 결과입니다.
Uncode 테마와 KBoard 게시판을 사용할 경우 워드프레스의 성능 저하를 유발시킬 수 있습니다. 둘을 따로따로 쓰면 문제가 없지만 같이 사용하는 경우 사이트에 로딩이 생기며, 특히 비주얼 컴포저 사용시 심각한 로딩 시간이 생기게 됩니다.
원인은 KBoard의 세션과 Uncode 테마의 ‘list_images‘ AJAX 동작 때문에 발생합니다. KBoard의 메인 파일인 kboard/index.php 파일의 초반에는 session_start()로 세션을 시작하는 구문이 있습니다. 그리고 이 세션은 KBoard 곳곳에서 활용됩니다.
한편 Uncode는 list_images라는 ajax 액션을 통해 uncode_list_images()라는 함수를 동작시킵니다(uncode/core/inc/admin.php: 1086). 이 함수는 무려 모든 이미지 파일을 불러와 그 이미지 파일의 용량을 계산합니다. 그리고 아래와 같은 메시지를 응답으로 넘깁니다.
The Adaptive Images system is using 87.6M of the 6.29G space left.
JSON 포맷이 아닌, 그냥 단순 텍스트 응답으로 날아옵니다. 이 응답이 자바스크립트 같은 곳에서 프로그래밍적으로 유의미한지는 확인하지 않았으나, 그렇게 보이지는 않습니다.
문제는 이미지의 양이 많아질 때 터집니다. 제가 작업 중인 사이트는 이미지 파일만 1만개에 가깝게 유지하고 있습니다. 사이트의 용량만도 기가바이트급입니다. 언코드는 무식하게도 이 1만개에 육박하는 이미지를 매번 관리자 화면 로딩시 별도의 AJAX 요청을 통해 모두 쿼리로 불러와, 용량을 계산하고, 위 메시지를 출력하고 있던 것입니다. 이 계산을 위해 대략 수 초, 심하면 저의 경우처럼 30~40초까지 걸리기도 합니다.
이제 이 상태에 KBoard가 끼어들면 문제가 정말 심각해집니다. KBoard는 로딩될 때마다 세션을 실행합니다. 세션에는 한 번에 하나의 연결만 접근할 수 있으므로 둘 이상의 연결을 동시 처리할 수 없습니다. 그런데 언코드는 파일 용량을 계산하는 AJAX를 페이지를 부를 때마다 자동으로 실행합니다. 병목구간이 발생하는 것입니다.
비주얼 컴포저로 각 위젯을 편집 버튼을 누르면 각 UI 정보는 AJAX를 통해 얻어 옵니다. 그러나 이미 이미지 용량 계산 때문에 다른 AJAX 요청에는 응답할 수 없는 상태입니다. 그래서 꽤 오랫동안 로딩이 걸리게 되는 것입니다. 아마 다른 페이지에 접근할 때도 마찬가지로 로딩이 심하게 발생할 수 있을 것입니다.
문제를 해결하려면
Uncode와 KBoard를 같이 쓰지 않는다.
같이 써야 한다면 Uncode의 이미지 계산하는 부분, uncode/core/inc/admin.php 파일의 1086번째 줄 부근의
/* AJAX call to load all images */
add_action( 'wp_ajax_list_images', 'uncode_list_images' );
본 포스트는 UI 디자인 등에 대한 전문적인 의견이 아니라, 워드프레스 관리자 화면이 어색하다는 사람들을 설득하기위해 써 본 글임을 알려 드립니다. 올바르지 못한 점이 있다면 피드백 부탁드립니다.
처음 쓰는 툴이니 어색한 것은 당연하겠지만, 워드프레스를 초심자들은 많은 부분들을 어색해합니다. 그 중은 상당히 오랜 기간 학습을 필요로 하지요. 그 중 대표적인 하나로 “관리자 화면”을 들 수 있습니다.
대부분의 초심자들은 관리자 화면에 익숙해지기까지 상당한 인내심을 지불합니다. 약간 과정하면, 마치 웅녀가 곰에서 사람이 되기 위해 동굴에서 쑥과 마늘 먹으며 괴로움을 참아야 했던 것처럼요. 그 괴로움을 끝까지 참아내기 어려운 경우도 많고, “도대체 왜 도구 때문에 내가 바뀌어야 하는가?”라고 생각할 수도 있습니다. 참지 못한 몇몇 ‘호랑이’들은 참지 못하고 다른 CMS로 갈아탈 것이고, 이 분들 중에는 결국 워드프레스에 강한 거부감을 보일 수도 있을 것입니다.
반면 잘 적응한 사람들은 대부분 워드프레스 관리자 화면은 합리적이고 쓰기 편하다고 합니다. 아무리 적응하기 나름이라고는 하나, 단순히 적응도 때문에 불편함과 편함이 생기는 것은 아닐 겁니다. 그러면 과연 무엇 때문에 어떤 이들은 불편하다고 느끼고, 어떤 이들은 편하다고 생각하는 걸까요?
워드프레스 관리자 화면이 익숙하지 않은 이유.
우선 워드프레스의 관리자 화면이 어색하고 불편하다면, 친숙하고 편한 스타일의 관리자 스타일이 존재할 것입니다. 그것을 무엇이라 칭하기 어렵지만 “기존 스타일”이라고 뭉뚱그려 표현해 보고자 합니다. 네, 우리 한국 사람에게 익숙한 문법과 문맥을 가진 바로 그 스타일입니다. 이 문법과 문맥을 거칠게나마 특성을 몇가지 나열해 보지요.
메뉴는 위계를 이루는데, 최상단에서부터 최하단까지 상당히 깊은 깊이, 적어도 3단 이상을 가지고 있습니다.
메뉴의 레이블은 “XX 설정”, 혹은 “XX 관리”라는 스타일로 되어 있어 세부적으로 디테일한 설정 및 관리를 하는 스타일을 가지고 있습니다.
이런 UI가 익숙하신가요?
반면 워드프레스 관리자 화면을 보면 “~관리”라든지, “~설정”이라는 레이블을 찾을 수 없습니다. 특별한 플러그인을 설치하지 않은 이상은 말이죠. 그냥 알림판, 글, 미디어, 페이지, 댓글, 외모, 플러그인, 사용자, 도구, 설정 (아!), … 이렇게만 있을 뿐입니다.
워드프레스 메뉴들은 우리한테 뭔가 “관리”하라거나, “설정”하라는 요구를 하지 않습니다. 아마 기존의 스타일을 고수하셨던 분들은 여기서 혼란스러움을 느낄 수 있을 겁니다.
워드프레스의 관리자 영역. 메뉴도 심플하고, 깊이도 2단으로 제한되어 있다.
사실 “관리”나 “설정”이라는 말이 없다는 것만으로는 어색함을 극복하기는 어렵습니다. 기존 스타일과 워드프레스 스타일, 그 작은 차이를 이해한 것 가지고는 워드프레스식의 관리자 스타일을 납득하기란 어렵습니다. 그냥 관리, 설정 식으로 메뉴를 꾸며 주면 안되나요? 좋은 게 좋은 거고, 편한 게 편한 거 아닌가요?
그러나 그렇지 않습니다. 제가 이해한 바로는 이렇습니다. 기존의 스타일이 가진 ~~관리, ~~설정 같은 메뉴 구성은 그다지 좋은 메뉴 구성이 아닙니다. 저는 앞으로는 그런 스타일은 버리시기를 강력히 권하는 입장입니다. 앞으로의 글은 왜 기존의 스타일이 나쁜지, 그리고 왜 워드프레스 스타일이 권장할만한지에 대해 나열할 생각입니다. 만일 기존의 방법에서 더 이동할 생각이 없으시다면 이제 이 글을 그만 읽으셔도 됩니다.
관리자 화면 자체가 관리를 위한 장소이다.
관리자 화면 자체가 “관리(administration)”을 하기 위해 들어오는 장소입니다. 그런데 그 메뉴 하나하나에 죄다 그놈의 관리가 붙어야 하는 이유는 대체 뭔가요? 요즘은 데스크탑 뿐만 아니라 모바일 등등 여러 기기에서 웹에 접근합니다. 작은 화면에서는 집약된 정보가 중요합니다. 관리자 화면에서 관리라는 단어를 쓰는 것은 낭비입니다.
관리의 본질은 모델이지 액션이 아니다.
콘텐츠 관리 시스템(Contents Management System, CMS)에서 가장 중요한 것은 콘텐츠입니다. 그리고 콘텐츠가 존재해야 콘텐츠의 관리가 거론될 수 있는 법이죠. 그러나 기존 스타일은 콘텐츠가 무엇인지 명확히 알 수도 없는 상황에서 관리 내지 설정을 이야기합니다. 제가 기존의 스타일을 나쁘다고 말하는 이유 중 가장 주된 이유입니다.
사용자가 우선 관리자 메뉴에서 익숙해져야 하는 것은 무엇인가요? 관리 메뉴를 습득하는 것? CMS에서 가장 중요한 것은 다름아닌 콘텐츠입니다. 관리자는 자신이 관리하는 콘텐츠를 먼저 잘 파악해야 합니다. 그 다음에 그 콘텐츠를 어떻게 관리할까 하는 문제가 생기겠죠. 그러나 기존의 시스템은 다짜고짜 관리부터 하려 듭니다. 사용자가 그 관리 대상이 무엇인지 파악하지 못한 상태에서도요. 제 관점에서는 그런 메뉴들이 오히려 달갑지 않습니다.
CMS의 본질은 콘텐츠라고 반복하여 말씀드리고 있습니다. 먼저 콘텐츠라는 “모델”이 정의되어야 합니다. 그리고 나서 그 “모델”을 어떻게 처리해야 할지에 대한 “액션”을 논할 수 있습니다. 물론 거의 모든 경우 이 모델과 모델에 대한 행위는 붙어 있기 때문에 그 개념을 다 포괄하여 생각하는 경우가 많습니다만, 문법에서 명사와 동사가 다른 것처럼 모델과 액션은 엄연히 다른 개념입니다.
기존 스타일이 나쁜 예
기존의 스타일이 나쁘다고 하는 이유를 모델과 액션, 혹은 명사와 동사의 측면으로 바꾸어 다시 강조해 볼까요? 행위는 행위의 대상이 존재해야 그 의의가 있습니다. 모델이 명확하게 인지되지 않은 상태에서 액션을 취하면, 그 액션은 올바르지 못할 때도 있습니다.
메뉴 설계적인 측면에서도 액션 위주의 메뉴는 비합리성을 가지기 쉽습니다. 행위는 행위의 대상인 모델이 존재해야 그 의의가 있습니다. 그리고 만일 모델의 구조가 변화하면 행위에도 영향을 끼칠 수 있습니다. 설계적으로 보면 행위는 모델에 종속되어 있는 셈입니다.
“A 관리 메뉴”를 들어가면 “A 관리 페이지”를 보여줍니다. 여기서 “A 모델”을 조작합니다. 그런데 A 모델은 B 모델에 의존하기에, A 관리 페이지에서 암시적으로 B 모델을 편집하게 설계합니다.
예를 들어 “A 관리”라는 메뉴를 만들었다고 생각해 보죠. 그리고 A 관리 메뉴의 실대상인 A 모델은 꽤나 복잡하기 때문에 B 모델 또한 같이 생각하여 “관리”되어야 합니다. 그러나 B 모델은 상대적으로 복잡하지 않습니다. 그래서 암시적으로 A관리 메뉴에서만 B 모델이 보이도록, 즉 관리되도록 설계됩니다.
“C 관리”가 등장했습니다. “C 모델”을 관리하는데, 이것도 B 모델을 의존합니다. B모델의 관리는 A와 C 둘다 부담해야 할 입장에 처했습니다. 어느 한 쪽만 처리하기에도 애매하지요.
그런데 말이죠, 프로젝트가 진행되다가 “C 관리”라는 메뉴를 또 추가되어야만 상황이 생겼다고 보죠. 그런데 대상이 되는 C 모델 또한 B 모델을 포함합니다. 자, 그러면 C 관리 메뉴에서도 B 모델에 대한 관리가 들어가야 하나요? 그러면 메뉴가 중복되겠죠? 그렇지만 C 메뉴도 B 모델을 처리하는 부분이 있는데…? 어떡하죠?
앞으로 이런 식으로 개발하면서 “행동”에 대한 요구는 점점 늘어갈 것입니다. 그러면 이 행동에 대한 메뉴를 만들어 나가게 되면 메뉴는 자연스럽게 복잡해집니다. 그리고 이 복잡함을 감추기 위해 “위계질서”를 도입합니다. 메뉴가 깊어지겠죠. 그러나 동족방뇨입니다. 당장은 깔끔해 보일지는 모르지만, 나중에는 원하는 메뉴가 어디에 붙어 있는지 찾기 어려울 정도로 복잡해지는 경우가 생깁니다.
물론 위 경우 사용자의 편의를 위해 A, C 메뉴 둘 다 B 모델을 편집할 수 있는 UI를 주는 것도 나쁘지는 않습니다. 그러나 B 모델이 간단해서 망정이지, B 모델 또한 상당히 복잡한 구조였다면 개발자도 괴롭고, 쓰는 사람도 괴로울 것입니다. (여기 예에서는 “B 관리 페이지를 넣어!”라고 하시겠죠? 그게 제가 의도한 바입니다. 단, 그놈의 “관리”라는 접미사는 좀 빼 주는 게 어떨까요?)
제 나름대로의 생각으로는 대기업 홈페이지나 금융권들의 메뉴가 쓸데없이 어려운 이유에도 이런 이유가 있다고 생각합니다. 아, 물론 그들의 업무 범위는 상상외로 크기 때문에 그것만으로도 머리가 터질 만큼 복잡한 게 사실입니다. 그러나 애초에 복잡한 것을 더 복잡하게 만드는 이유 중 얼추 이러한 요소도 있을 것이라는 개인적인 짐작입니다.
워드프레스의 메뉴가 합리적인 이유
대개의 콘텐츠는 CRUD (Creation: 생성, Retrieval: 검색, Update: 수정, Deletion: 삭제) 이 네 가지 동작을 기본으로 합니다. 복잡한 동작도 알고 보면 이 4가지의 연장선이죠. 그런데 이 단순한 행위가 모델에 따라 여러 동선을 만들어낼 수 있습니다. 그러니 동선을 먼저 생각하기 전에 모델부터 생각해야 하는 것이 맞는 것이 아닐까요?
워드프레스의 관리자 화면이 심플하면서 직관적이라는 이유는 바로 이런 이유입니다. 메뉴는 행위에 초점을 맞추어 구성되어 있지 않습니다. 관리하고자 하는 콘텐츠에 보다 초점이 되어 있죠. 여러분이 어떤 플러그인을 설치해서 새로운 콘텐츠 형태를 추가한다 하더라도 이는 거의 변하지 않습니다.
예를 들어 Gravity Form을 설치하면 Form이라는 명사형의 메뉴가 등장하지, “Manage Form” 같은 동사형의 메뉴가 등장하지 않습니다. 우커머스 플러그인을 설치해도 마찬가지입니다. 상품, 주문 같은 명사형의 메뉴가 생깁니다. 설정 메뉴의 하위 메뉴도 마찬가지입니다. 대개 명사형의 하위 메뉴가 있죠. 그 메뉴에 들어가서야 비로소 추가, 수정, 삭제, 검색 등의 행동을 담은 페이지가 나오죠.
이제 워드프레스의 메뉴에 익숙해진 분들이 직관적이고 편하다는 이유가 무엇인지 이해하실 수 있으신가요? 이 분들은 “행동”을 먼저 생각하는 것이 아니라 관리하는 “모델”에 더 초점을 맞추고 메뉴를 보기 때문에 메뉴가 더 쉬운 것입니다. 이 관점에서 메뉴를 구성하면 그다지 메뉴가 깊어질 이유도 없습니다.
우커머스 설정화면. 상거래는 복잡한 만큼 많은 설정을 가지고 있습니다 그러나 그 복잡함이 관리 메뉴까지 간섭하지는 않습니다. 또한 메뉴들은 관리 대상과 모델에만 집중하고 있습니다.
물론 우커머스 같은 상당히 복잡한 데이터를 다루는 플러그인은 실제로 메뉴가 많이 복잡합니다. 그러나 이런 복잡성이 좌측 주 메뉴에까지 슬슬 기어나온다면, 그건 문제겠죠. 위 그림처럼 워드프레스 관리자에서도 탭이라든지, 매니지 영역 등등을 사용해 더 깊은 메뉴를 처리할 수 있도록 하고 있습니다.
마치며
여기까지 읽어주셔서 감사합니다. ‘신문물’이란 게 대개 그렇습니다 . 새로운 것을 받아 들이려면, 기존의 것과 상충되는 것은 극복해야 합니다. 처음은 괴롭지만, 더 나은 방법임은 우리는 알고 있습니다. 애초에 그것을 더 낫게 하기 위해 도입하는 것이거든요. 물론 기존의 관성이 만만찮게 강력하기 때문에 변하는 것은 쉽지 않습니다.
그러나 본질을 놓치지는 말자구요. “왜 변해야 하는가?”, “이것을 변화하면 무엇이 나아지는거?”를 잘 이해하면 그 변화를 더 잘 받아들일 수 있습니다. “워드프레스의 관리자는 왜 그 모양새를 가지고 있는가?”를 더 이해하면 보다 워드프레스를 친숙하게 받아들일 수 있을 것 같아 글을 써 보았습니다. 전문적인 UI 디자이너의 의견이 아니라 틀린 점도 많고, 제가 제대로 이해하지 못한 점이 많을 것입니다. 틀린 점이 있다면 댓글로 피드백을 부탁드립니다.