개발자로 성장하는 데 필요한 건 어떤 태도일까? | 우아한 형제들 출신 멘토님
F-Lab : 상위 1% 개발자들의 멘토링
jQuery를 쓰면서 performance 오버헤드를 적게 가져가는 법
jQuery(와 ES11)을 가지고 프레임워크를 개발하는 입장이라 jQuery에 대한 최근 언급되는 내용들을 인터넷에서 살펴보았습니다. jQuery가 사용되지 않을 이유야 다양하지만 문서 전체를 뒤지기 때문에 성능이 느리다....라는 언급이 있는걸 보고 이게 무슨 소리지?..하고 생각했습니다.
jQuery 하면 누구나 생각하는 ${'tag#id.class') 쿼리 셀렉트 방식은 jQuery의 핵심이지만 한편으론 그저 document.getElementBy...문들, 좀 더 가까이는 querySelectorAll의 좀 더 편리한 버전에 불과하기 때문에 말 그대로 문서 전체에서 검색을 하게 되므로 성능 하락이 있는 건 매우 당연합니다.
물론 해결책이 없는 건 아닙니다. 당연하게도 DOM 조작이 필요한 최상위 고정 지점에 대해 $쿼리를 한 후 이를 변수로 가지고 있다가 필요할 때 꺼내 쓰고, 그 아래 요소에 또 고정 지점이 있다면 쿼리 결과를 담아뒀던 변수에서 find문을 사용하여 하위 요소를 셀렉트한 후 마찬가지로 변수에 저장해 두는 식으로 사용하면 됩니다. 이렇게 변수로 저장하고 find문으로 해당 요소 내 자식 요소들을 다시 쿼리 하는 식으로 이용하면 일단 보관해 둔 셀렉트 결과를 재활용하면서 쿼리 횟수가 극단적으로 줄어들고, 하위 요소로 내려갈 수록 검색 범위가 좁혀지는 데다 개인적으로는 쿼리를 할 때 '>'(자식 셀렉터)를 애용하는데, 그럼 범위가 더 좁혀지기 때문에(더 극단적으로는 .children().filter() 사용) 결과적으로 단점으로 언급되는 쿼리 속도에 대한 문제가 해결이 됩니다.
이렇게 너무나 당연한 사항임에도 여전히 단점으로 거론되는 이유는 jQuery를 이용 할 때 HTML 태그의 on.... attribute. 즉 이벤트 콜백에 인라인으로 하드코딩하거나, 글로벌 내지 익명 함수(특히 setTimeout에 넣을 때)같이 상시 동일하게 접근 가능한 멤버 변수가 없는 영역에서 쿼리를 해서 DOM 조작을 하는게 너무나 흔하기 때문입니다. 이는 편의성 때문이기도 하고, 화면 내 고정 요소에 대해 매칭되는 controller object나 class같은 형식을 사용하지 않고 개발하기 때문입니다. 그저 작동하니까...그렇게 쓸 뿐인데 그 이상의 개선을 하려고 하지도 않기 때문에 발생하는 문제인 것이죠. 그것을 SPA 용으로나 개발 환경에서 장기적으로 점점 사용하지 않게 될 이유로 꼽히는 것은 상당히 불합리한 평가입니다.
현재까지 10여년을 jQuery를 가지고 SPA 개발을 진행해온 입장으로서는 jQuery가 성능으로 문제가 되는 경우는 거의 존재하지 않았습니다. 물론 그럼에도 최신 프레임워크들이 더 빠른 성능을 낼 것이라는 점은 다르지 않습니다만, 그렇다고 역으로 jQuery가 못 쓸 물건이 되는 것은 아닌 것이죠.
10 여 년 간 독자적으로 SPA 웹 프론트 개발을 발전시켜 나가면서 먼저 하게 된 것이 고정 요소에 대한 쿼리 결과를 고정 변수에 먼저 할당 해 두는 것이었습니다. 그 다음이 controller object를 최상위 UI 요소 컴포넌트에 매칭시켜서 초기화하고 실행해 두도록 하는 것이었고, 이는 또한 제 개발의 한 축이었던 Android Native 개발하면서 익은 MVC 패턴이 자연히 녹아든 것이었습니다. 최종적으로는 class를 사용하게 되었고, 안드로이드 개발에서 익숙해진 UI 컴포넌트의 라이프 싸이클까지 영역을 넓히면서 프레임워크의 형태를 갖추게 되었습니다.
그렇게 프레임워크를 끼고 라이프 싸이클의 가장 처음에 하는것 역시 해당 최상위 요소의 jQuery 객체(쿼리 결과 객체)에서 고정적으로 사용하는 요소를 find문을 써서 컨트롤러 객체의 멤버변수에 보관해 놓는 것 입니다. 결과적으로 $의 사용은 극단적으로 줄어들었고 $ 함수를 사용하는 것은 프레임워크의 초기화 부분 정도로 한정됩니다. 실제 프레임워크 이용 시에는 객체가 jQuery 쿼리 결과 객체인지 여부를 구분하기 위한 변수이름의 prefix 정도로만 사용하게 되었습니다.
결론적으로 간단히 요약하자면 $()를 사용하는 순간 성능을 지불하고 편의를 얻는 것과 같다..라고 할 수 있겠습니다. 그래서 $표시였던게 아닌가 싶기도 하고....하여튼 $를 남발하면 돈을 뿌리고 다니는 것과 같은데 그 돈이 웹 페이지 접속자의 접속 기기 퍼포먼스라는 지갑에서 나온다는게 문제라면 문제겠지요. 그래도 필요하면 무지성으로 그냥 비용을 지불하고 시간을 아끼는 방법을 쓸 수 있다는 것이 jQuery를 사용하는 입장에서의 장점인 것이겠죠. 결국은 비용을 남발하는 것이 문제이지 jQuery는 죄가 없다는 게 결론이라 하겠습니다.
다음 내용이 궁금하다면?
이미 회원이신가요?
2025년 3월 14일 오후 5:34
댓글 0
함께 읽은 게시물
혹시 Cursor 채팅만 사용하시나요? Agent 쓰는 방법!
Cursor와 함께라면, 더이상 에디터는 단순한 입력 도구가 아닌
... 더 보기웹 앱이 만들어지던 시기에도, 모바일 앱이 창궐(?)하는 시기에도 웹의 종말론 그런게 항상 나왔었다. 앱은 서로를 연결하지 않으니까.
하지만 웹은 그 존재 의의를 계속 진화시키고 발전시켜가며 중요한 역할을 계속 해 왔다.
🪄 플레이모어와 함께할 동료를 찾습니다
첫
... 더 보기
