on
왜 Jquery를 쓰지 않을까?
들어가며 ..
우연치 않게 팀에 기여 할 수 있는 기회를 얻게 되었습니다, 기회란 프론트엔드 기술 스택에 대한 선행 개발이었습니다. 아마 예전에 종종 관련 된 기술 스택을 공부하던 것을 들켜(?)서 얻게 되었지 않나 생각을 해봅니다. 아직 경험할 것이 많은 부족한 시기이지만, 흔하지 않은 기회에 시간 가는 줄 모르고 지내왔습니다.
선행 개발은 서비스 통합 관리UI를 만드는 업무에서, SPA(SinglePageApplication)기반의 클라이언트 개발의 메인을 담당하게 되었습니다. 이 과정에서 (저를 비롯한) 전통적인 화면 개발에 익숙한 팀원들에게 SPA(Single Page Application)의 이해와 요즘 많이 언급 되는 FS(Front Side)프레임워크들이 왜 유명한지, 왜 좋은 지에 대해 설명이 필요 했으므로 이제 대해 제 자신이 명확하게 이해 할 필요가 있었습니다. 이 과정을 문서로 정리 해보려고 합니다.
이 문서는 총 5장으로 진행 할 예정입니다. 1장에서는 지금 보고 계신 세션으로, 왜 기존 방식을 버리고 SPA에 관심을 가지게 되었는 지에 대한 배경에 대해 설명하고, 2장에서 관련 된 배경 지식을 말하려 합니다. 그리고 3장에서 왜 많은 프레임워크 중에서 Angular를 골랐는 지에 대한 이유와.. 4장 5장에서 Angular에 대한 실질적인 지식을 풀어보려 합니다.
왜 Jquery를 쓰지 않을까?
1. 성능 오버헤드
JQuery는 원래 브라우저 간의 상이한 JS 호환성 문제(구글링으로 JS의 역사를 검색해보면 좋습니다.)를 해결하기 위해 나왔습니다, 이 호환성이라는 것은 대표적으로 브라우저마다 같은 기능이더라도 호출하는 API가 마다 다르거나, 브라우저 마다 지원하는 기능 유무의 갭이 너무 컸던 것을 뜻 합니다. 이런 것을 Jquery에서 해결 해주었으니, 뭐랄까 각기 다른 데이터베이스들의 쿼리 방언들을 통합해주는 ORM 프레임워크 같이.. 일종의 래퍼(wrapper) 역활을 하는 친구라 생각 하면 됩니다.
이 JQuery는 각기 다른 브라우저 호완성을 해결해 주는 특징에 많은 이들에게 사랑 받고 지금까지도 많이 사용되어 왔습니다. 특히, (만악의 근원이라 불리우던) IE기반의 개발에서 많은 사랑을 받으면서 한국 시장에서도 굉장히 교과서(?)스럽게 기본시 되며 많이들 사용해왔습니다. 그리고 IE의 지원이 공식적으로 중단 될 만큼 시간이 흐른 지금, 다양한 브라우저에서 표준 스펙을 준수하며 구현하고 ECMA와 같은 표준 JS 스펙이 자연스럽게 자리를 잡으며, 웹 앱 개발자 입장에서는 예전만큼 호환성 문제를 고심하지 않아도 되게 되었습니다. (그렇다고 관심이 없어도 된다는 아닙니다.)
JQuery는 대부분의 래퍼의 특징처럼 로직을 수행하기 전에 호환성을 위해 전처리 단계로 dirty check 과정이 있습니다, 이러한 부분은 방금 야기한 것처럼 과거와 달리 지금의 시점에서는 불필요하게 되어 오히려 상황에 따라 성능 상의 오버헤드가 발생하게 되는 문제가 생겼습니다.
이러한 부분 때문에 유저 인터렉션이 다양한 웹 서비스 (예: 소셜, 포탈 등) 에서는 점차 안 쓰이게 되었고, 이 공백을 매꿀 대안으로 사용 될 프레임워크들이 등장하게 되었습니다.(Angualr, React 등)
2. 개발 패러다임의 변화
기존에 브라우저 환경에서 없다 싶어 했던 소스 모듈화의 패러다임이 확산 되고(지금도 ES6의 import 및 require와 같은 모듈 명령은 미지원입니다.), MV** 패턴과 같은 우리가 흔히 ‘컴퍼넌트’ 구조 라고 일컫는 구조가 안정적으로 정착되고 다양한 긍정적인 이점이 발견되면서, jQuery에서 사용하는 ‘명령행’ 방식은 점차 비효율적이라는 이야기가 나오기 시작 했습니다.
명령행 방식은 저의 짧은 지식으론 명확히 정의 하기가 어렵지만, 개인적으로는 전통적인 Top-Down 의 응집도가 높은 구조라 생각하고 있습니다. 브라우저 코딩에 국한 된 이야기지만 웹 페이지가 기본적으로 싱글 스레드로 돌다보니 콜백을 빼놓을 수가 없는 데, ‘기능을 위한 기능 그리고 기능’ 이란 느낌으로 콜백의 로직이 무거워지면서 콜백 지옥에 빠져 쉽게 파악하기 어려운 스파게티 소스가 될 수 있는 여지가 발생합니다.
3. 플랫폼의 진화
jQuery는 1에서 서술한 데로, 브라우저 간의 호환성 문제로 세상에 나타났습니다. 이는 클라이언트에 dependency 를 가진다는 의미를 뜻한다고 볼 수 있습니다. 이 점은 javascript가 client에만 국한되지 않는 시대의 패러다임(nodejs의 등장)을 이행할 수 없음으로도 해석할 수 있습니다.
javascript가 최근 들어 인기가 급속도로 올라가는 것은 여러 이유가 있겠지만 방금 설명한 것처럼 플랫폼 영역 구분 없이 어느 곳에서든 사용가능한 언어(요즘은 Converting 이 좋아져 App& Desktop 에서도 쓰임)가 큰 장점이다 보니, 브라우저에 dependency를 가지는 Jquery의 인기가 떨어지는 것은 당연하리라 생각합니다. (그래도 Stackoverflow의 질문을 보면 Jquery를 어떻게든 쓰려는 많은 글들이 많습니다.)
뭐 그래도..
위에서 단점(?)아닌 단점들을 서술해보았지만, 그래도 아직까지 결제 와 같은 민감한 서비스에서는 호환성을 위해 jQuery를 많이들 사용하고 있습니다, 개인적으론 이는 옳은 방안이라 생각합니다. 아무리 플랫폼(브라우저) 환경이 좋아졌다 하더라도 아직까지 XP를 OS로 쓰는 사람이 있고, IE를 브라우저로 쓰고 있는 사람 역시 많은 국내의(한국) 환경을 보면, jQuery 만한 것이 없는 것도 없으니 등한 시 할 수 없다는 점도 무시할 순 없겠지요. 이는 부트스트랩이 아직도 jQuery를 사용하고 있는 이유와 비슷하기도 합니다. (사용성이 편한 점도 있지만..)
또 한편으론 제가 힘들었든 mv** 아키텍처의 이해는 처음 접하기에 러닝커브가 있다고 생각 합니다. 이에 비해 직관적으로 보이는 명령행 스타일은 비숙련자(초심자, 비개발자 등)에게는 친근하게 다가 올 수 있습니다.
다음에는 본격적으로 SPA가 무엇인지, Angular? Vue? 그게 무엇인지에 대한 배경적 지식을 이야기 해보려 합니다. (참고로 저는 React의 JSX 문법이 개인적으로 싫어해서 Angular와 Vue를 두고 주로 얘기할 예정입니다.)