top of page

모던 웹 스택 심층 분석

프론트엔드 기술요소들을 분류하여 프레임워크별로 비교해 우리에게 맞는 기술이 무엇인지 파악해 봅시다.

들어가는 말

오늘날 비즈니스 컴퓨팅 분야에서 변화를 추진하는 가장 큰 요인 두 가지는 멀티 디바이스 컴퓨 팅과 클라우드다. 멀티 디바이스와 클라우드는 애플리케이션 아키텍처가 보다 더 강력한 프론트 엔드와 유연한 백엔드로 빠르게 진화하는 원동력이 되고 있다. 모바일 디바이스는 비즈니스 데이 터와 애플리케이션으로 가는 중요한 관문이 되고 있다. 그리고 대개 리치 API 서비스 포인트로 구현되는 클라우드 백엔드는 빠른 속도로 새로운 애플리케이션의 추세를 완벽하게 뒷받침해주는 백엔드가 되고 있다.

지난 5년 동안 웹과 네이티브 기술에는 폭발적인 혁신이 이루어졌다. 라이브러리와 프레임워크, 도구가 물밀듯이 릴리즈되어 개발자들이 이처럼 새로운 세상에 맞는 애플리케이션을 생성하게 도 왔다. 백엔드에서는 자바스크립트로 작성되고 가장 기본적인 것만 남긴 이벤트 시스템 Node.js를 기초로, 개발자들이 그들의 서버 백엔드를 새로운 멀티 디바이스 세계에 맞춰 조정했다. 프론트엔 드에서는 새로운 실험적인 라이브러리들이 폭발적으로 증가하며 웹과 네이티브 개발자들이 차세 대 사용자 경험을 만들 수 있게 했다.

새로운 아키텍처

많은 조직에서는 전통적인 자바 애플리케이션 서버 중심의 개발 프로세스와 구축 기술을 만드는 데 막대한 양의 시간과 노력을 쏟아부었다. 그들은 이런 식의 투자가 이제는 구식이 되어 가고 있다는 것을 믿지 못하는 때가 많다. 많은 사람은 “왜 우리가 변해야 하지?”라는 질문부터 생각한 다. 간단히 말해, 모바일 컴퓨팅은 새로운 아키텍처를 필요로 한다.

2000년대에 급격히 증가한 데스크톱 웹 애플리케이션은 공통적인 씬 클라이언트 아키텍처를 공 유했다. 오라클 웹로직(Oracle WebLogic) 같이 무거운 애플리케이션 서버가 브라우저에 전체 페이 지를 제공했고, 애플리케이션 인터랙션은 전부 페이지 요청과 응답으로 수행되었다. 모든 데이터 관리와 통합, 비즈니스 논리, HTML 및 CSS 생성 등의 애플리케이션 작업 전체는 서버 측에서 이 루어졌다. 자바스크립트를 사용한 페이지 인터랙션이 있기는 하지만 적은 수에 불과하다. 그럴 만 한 이유는 세 가지가 있다. 브라우저는 아주 느린 자바스크립트 엔진이 있는 구식의 페이지 뷰어 였고, 데스크톱 브라우저는 오프라인이 되는 경우가 드물었으며, 모든 작업을 서버상에서 할 때 보안에 대해 생각하기가 더 쉬웠던 것이다.

그러나 모바일 컴퓨팅으로 이동하고 HTML5 브라우저가 성장하면서 위의 세 가지 이유 중 두 가 지는 더 이상 유효하지 않다. 모바일 앱은 오프라인에서 작동되어야 하고, 브라우저(그리고 네이티브 모바일 OS)의 기능성이 대단히 높아졌다. 과거에는 서버에서 이루어졌던 대부분의 비즈니스 논리와 데이터 처리가 오늘날 최첨단 애플리케이션에서는 모바일 디바이스에서 나타난다. 그리고 모바일 애플리케이션 경험은 서버에서의 정적인 페이지 제공으로는 절대 얻을 수 없을 만큼 대단히 풍부하다.

웹 1.0 vs 멀티디바이스 서비스 제공 웹 아키텍쳐의 비교

웹 1.0 vs 멀티디바이스 서비스 제공 웹 아키텍쳐의 비교

오늘날 애플리케이션 아키텍처에서, HTML이든 네이티브든 리치 클라이언트는 씬 클라우드 백엔 드와 커뮤니케이션한다. 모바일 디바이스는 클라우드에 있는 RESTful API와 커뮤니케이션해 JSON 객체를 보내고 받는다. 아키텍처 변화를 배경으로 새로운 세대의 애플리케이션은 상태를 유지하 고 데이터가 풍부하며 사용자 응답이 신속하다. 이런 멀티 디바이스 애플리케이션은 새로운 모바 일 디바이스, 기존의 데스크톱 브라우저뿐만 아니라 키보드를 사용 가능한 태블릿이나 패블릿 같 이 새로운 트위너(tweener) 디바이스에서도 작동한다.

이런 유형의 애플리케이션은 메모리에나 지속적인 로컬 데이터 스토어에나 많은 양의 데이터를 로컬로 저장하기 때문에 사용자 인터랙션에 빠르게 반응한다. 따라서 새로운 데이터를 가져오기 위해 서버에 오고가지 않아도 데이터(예: 데이터베이스 레코드)를 검색, 정렬, 필터링, 그룹화할 수 있다.

또한 이런 애플리케이션은 웹 1.0 앱보다 상태 유지도가 훨씬 높다. 사용자는 다수의 스크린과 서 브스크린에 걸쳐 나타난 콘텐츠와 데이터를 내비게이션하고 서버에서 새로운 페이지를 요청할 필 요 없이 여러 단계의 처리를 할 수 있다. 즉, 이런 애플리케이션은 데이터가 굉장히 풍부하기 때 문에 전통적인 데이터 그리드든 더 발전된 시각화 효과든 무수한 방식으로 커다란 데이터셋을 표 시하고 조작할 수 있다는 뜻이다.

“자, 모두 에디터를 켜자!”

개발자는 이클립스나 vi를 열고 이 패턴에 대해 위와 같은 애플리케이션을 코딩하기 시작하는 것 이 그저 즐거울 수 있지만, 잠시 멈추고 자신의 개발팀이 계획, 설계, 제작해야 하는 애플리케이 션의 환경에서 새로운 앱 모델이 안겨줄 영향을 모두 생각해보는 것도 매우 유용하다.

이것은 1인 관리자가 아닐 경우에 특히 맞는 말이다. 평균적인 기업은 100명까지는 아니어도 적 어도 10명의 개발자가 수십만 개의 스크린에서 애플리케이션의 라이프사이클을 관리하는 작업에 대한 업무 관행을 만들어야 한다. 이런 스크린 경험은 수십 만 줄의 코드와 백만 개의 데이터 스 토어를 바탕으로 구축될 수 있다. 이는 잠재적으로 극히 만만찮은 작업이다(센차의 고객 중에서는 애플리케이션을 새로운 아키텍처 패턴으로 업그레이드하는 일정을 5년까지 잡기도 한다). 그러므 로 한 발 물러서서 차세대 런타임을 구성하는 모든 부분들을 가만히 생각해보는 것도 좋은 생각 이다.

프론트엔드 개발 과제

프론트 엔드 개발시 흔히 요구되는 기능요소들

대부분의 멀티 디바이스 애플리케이션는 공통적인 문제를 갖고 있고 그 문제들은 네 가지 카테고리로 분류할 수 있다(어느 정도 임의적으로)

  1. 스크린 디자인: 위젯과 차트, 그리드 등 애플리케이션 콘텐츠의 모습과 동작을 말하는 사용자 인터페이스를 생성하고 배열한다.

  2. 뷰 관리: 레이아웃과 화면 엘리먼트의 상호작용성과 같은 뷰 시스템을 구조화하고 관리할 뿐만 아니라 아랍어 같이 오른쪽에서 왼쪽으로 쓰는 언어나 외국어 등의 사용자 요청을 처리한다. 그리고 마우스로 입력하는 데스크톱 스크린과 제스처로 인터랙션하는 모바일 화면 모두에 작동하는 애플리케이션을 구축하는 핵심적인 멀티 디바이스 문제를 처리한다.

  3. 데이터와 코드 관리: 데이터가 변할 때 화면을 업데이트하고 사용자 입력이 있을 때 데이터를 업데이트한다.

  4. 백엔드와 및 서버 측과 커뮤니케이션.

​이런 과제들을 전부 아우르는 것은 여러 레벨에서의 코드 캡슐화와 모듈화를 위해 필요하다. 그래야 여러 개발자와 개발팀이 서로의 영역을 침범하지 않되 서로의 작업을 활용해 효율적으로 협업할 수 있다.

프론트엔드 기술 요소 분류

네이티브 개발 기술은 이런 문제들에 오래 전부터 솔루션을 제공해왔다. 애플 플랫폼의 코코아 프레임워크, 플래시 개발을 위한 플렉스 프레임워크, 마이크로소프트 플랫폼의 윈도 프레젠테이션 파운데이션(Windows Presentation Foundation) 같은 네이티브 런타임을 보면 리치 클라이언트 애플리케이션을 생성하는 문제에 대한 놀라울 정도로 비슷한 솔루션들이 존재한다. 각각의 기술적 플랫폼들은 비슷한 종류의 기능을 비슷한 묶음으로 제공한다.

시스템 라이브러리와 그것의 프레임워크에 내장된 기능 사이에서, 네이티브 플랫폼에는 여러 가지 도구들이 풍부하게 들어 있어 애플리케이션 구조화, 공통적인 개발 과제 자동화, 멋진 모습의 애플리케이션 생성을 돕는다. 그림 3 에서 프론트엔드 스택의 포괄적인 모델이다. 모델이기에 이것은 실제 코드의 구조화 방식을 명백히 단순화한다. 예를 들어, 모듈 시스템은 엄밀히 말해 별도의 코드가 아니고 모든 코드가 구조화된 방식이다. 그럼에도 불구하고 우리는 그것이 프론트엔드 기능을 조직화하고 다양한 프론트엔트 기술의 기능을 구상하는 데 유용한 방법이라고 생각한다.

인터페이스 엘리먼트

  • 기본 위젯(Basic Widgets): 텍스트 영역, 버튼, 폼 엘리먼트, 프로그레스 바 및 로딩 바, 메뉴 등을 비롯해 애플리케이션에 필수적인 디스플레이 엘리먼트들

  • 복합 위젯(Compound Widgets): 하나 이상의 데이터를 표시하거나 데이터 그리드, 목록이 중첩되거나 계층이 많은 파일을 표시하는 등 다수의 하위 컨트롤을 포함하는 복잡한 디스플레이 엘리먼트들.

  • 시각화(Visualizations): 차트, 그래프, 폭포형 차트, 그 밖의 도표 같은 데이터 중심의 그래픽 엘리먼트를.

  • 컨테이너(Containers): 위젯과 컨텐츠를 담아두는 역할을 하고 중첩된 패널 같이 스크롤 가능한 디스플레이, 캐러셀처럼 카드 기반의 디스플레이, 알림이나 위저드 같은 모달 컨테이너 등을 포함한다.

  • 스타일(Styles): 콘텐츠나 위젯 집합의 프로퍼티나 어트리뷰트인 글꼴 크기, 그림자, 그 밖의 시각적 효과들.

  • 테마(Themes): 애플리케이션에 일관성 있는 모습과 느낌을 주는 스타일 집합, 그래픽 자산이다. 테마는 스타일 언어와 구별되는 테마 언어나 시스템으로 표현될 수 있다.

뷰 시스템

  • 템플레이팅(Templating): 애플리케이션의 규칙 집합을 따라 플레이스홀더를 최종 콘텐츠로 변환하는 기능이다. 완전한 템플레이팅 시스템은 단일 또는 복합 조건문과 반복문은 물론 완전한 함수도 허용한다.

  • 레이아웃 관리자(Layout Manager): 일련의 레이아웃 규칙을 적용해 창 크기, 디바이스 유형과 해상도에 따라 화면 엘리먼트를 x, y 나 z 공간으로 배치하는 것을 결정한다.

  • 인터랙션(Interactions): 이 기능은 처리되지 않은 시스템 이벤트(에: touchstart)를 앱 개발자가 사용하고자 하는 제스처(예: 스크롤 제스처)로 변환해준다. 우리는 이 카테고리에 드래그 앤드 드롭 가능성도 넣었다.

  • 시각적 효과(Visual Effects): 블러, 리컬러링, 채도 없애기 등의 시각적 변환과 프로퍼티 애니메이션을 포괄하는 용어다.

  • 드로잉(Drawing) API: 처리되지 않은 드로잉 요소 위에 추출을 제공한다. 만약 플랫폼의 요소가 충분히 풍부하다면 필요하지 않을 수 있다. clips, masks, blends 등의 작업을 결합하는 것은 드로잉 API로도, 시각적 효과로도 볼 수도 있다.

  • 테마(Theming) 시스템: 애플리케이션에 스타일과 자산의 집합을 일괄적으로 적용하는 방법이다. 계산형 스타일 프로퍼티를 제공하기도 한다.

  • 로컬리제이션(Localization) 기능: 텍스트 문자열과 애플리케이션 메시지를 애플리케이션 로케일에 따라 바꿔준다. 로컬리제이션은 별도의 블록으로 나타나 있지만 보통은 스택 전체에 걸쳐 많은 것에 속한다. 철저한 로컬리케이션은 시간, 날짜 등에 로컬라이즈된 데이터 포맷뿐만 아니라 데이터와 텍스트에 로컬라이즈된 정렬 규칙을 구현할 뿐만 아니라 어떤 언어가 오른쪽에서 왼쪽으로 쓰여졌냐에 따라 위젯 레이아웃 & 구성을 조정한다.

  • 접근성(Accessibility): 스택의 많은 항목들에 포함되는 또 다른 기능이고 키보드 내비게이션, 스크린 리더 호환성과 시각장애인을 위한 시각적 고대비 테마 같은 기능이 들어 있다.

로직과 데이타

  • 상태 관리(State Management) 기능: 상태 시스템 모델이 되어 애플리케이션 개발자들이 애플리케이션의 상태를 일관적으로 관리하게 도와준다. undo/redo 기능, 내비게이션 스택, 거래형 양자택일의 데이터 커밋이 이 카테고리에 들어간다.

  • 데이터 객체(Data Objects): 컬렉션, 트리, 큐, 그래프 같은 유형의 데이터 객체는 표준 언어 라이브러리로 충분한 수준까지 제공되는 때가 많다. 그러나 부족한 경우에 프론트엔드 스택에서 제공하거나 개발자가 처음부터 자신만의 데이터 객체를 작성해야 한다.

  • 데이터 바인딩(Data Binding): 인 메모리 데이터 변수와 데이터를 나타내는 스크린 엘리먼트 사이의 변화를 쉽게 동기화한다. 따라서 개발자는 변화를 관리하는 코드를 명시적으로 작성할 필요가 없어진다.

  • 데이터 모델(Data Models): 애플리케이션의 작업 세트을 저장하는 인 메모리 데이터 구조를 제공한다. 기능이 잘 갖춰진 모델에는 정렬, 검색, 필터링, 유효성 검사, 그룹화를 하기 위한 데이터베이스 스타일의의 기능이 있다. 이런 기능은 와이어 포맷에서의 직렬화와 역직렬화도 돕는다.

  • 모듈화(Modularity): 개발자와 개발팀이 저마다 코드를 구조화하고 의존성을 관리하게 도와주는 스택의 기능을 포괄하는 말이다. 하나의 식별 가능한 코드를 가리키지 않고, 객체네임스페이스 지정, MVC 등의 아키텍처 패턴, 컴포넌트 모델과 모듈/패키지 시스템 등의 기능을 포함한다.

  • 영속 데이터(Persistent Data): 처리되지 않은 파일 read-write 를 바탕으로 하는 기능이고 로컬에서 애플리케이션 자산과 데이터를 저장, 캐싱, 동기화하게 돕는다.

  • 테스팅(Testing) 기능: 오류 로깅, 이벤트 반복 같은 자동적인 유닛 및 시스템 테스트를 가능하게 만드는 기능들이 있고, 모든 애플리케이션 이벤트가 외부 스크립트로 실행될 수 있게 보장한다.

  • 멀티미디어(Multimedia) 기능: 애플리케이션 안에 시스템 비디오 및 오디오 재생을 내장하고 커스터마이징하는 기능, playback 과 read 메타데이터 컨트롤과 captioning 컨트롤 기능 등을 갖고 있 있다.

서버 커뮤니케이션

서버 측 커뮤니케이션을 하는 앱이 요청/응답, 양방향 서버 푸시 데이터 커뮤니케이션을 쉽게 할 수 있다. 일반적으로 서버 커뮤니케이션은 시스템 라이브러리에서 제공되지만, 웹 기술의 특수한 경우에는 처리되지 않은 소켓 커뮤니케이션이 브라우저 샌드박스 모델에 의해 금지되고 XHR과 웹 소켓처럼 더 높은 레벨의 기능만 제공된다.

이 분류 체계는 글꼴 렌더링, 스레드나 센서 API처럼 운영 체제에 일반적으로 들어 있는 기능들을 포함하지 않기 때문에 브라우저에 보통 들어 있는 기능(웹 글꼴, 웹 워커, 지오로케이션 등) 역시 분류 체계에 포함되지 않는다.

이 분류 체계를 HTML5 이전의 웹기술에 대응시켜 보기

이 분류 체계를 택해서 웹 플랫폼에 적용해보면 결과가 상당히 흥미롭습니다. 특히 HTML5 이전의 웹 플랫폼의 경우, 그 기능이 얼마나 적은지 알 수 있습니다. HTML5 이전의 브라우저에서 사실상 어떤 문제에 대한 솔루션을 원했다면 거의 전부를 아주 처음부터 만들거나 그래픽, 비디오와 양방향 서버 커뮤니케이션 같은 기능을 위해 브라우저 외의 플러그인을 사용해야 했다.

HTML5 이전의 웹 플랫폼에는 제한된 위젯 집합, 약간의 스타일링과 레이아웃 기능, 요청/응답 http 호출 기능이 있었다. 이게 전부다. 이렇게 소수의 브라우저 기능을 기초로 1 세대의 웹 애플리케이션 전체를 쌓아올렸다고 생각하면 놀라울 따름이다.

최신 HTML5 브라우저가 등장하며 플랫폼의 기능은 더욱 많아졌다.

  • Canvas,WebGL과 SVG로 2D와 3D 그래픽, 비트맵, 벡터 가능Ÿ

  • HTML5 입력으로 범위 슬라이더, 컬러 피커와 확장된 날짜/시간 입력 가능 Ÿ CSS 애니메이션과 전환으로 모션 그래픽 가능

  • 웹 소켓으로 양방향 서버 커뮤니케이션 가능 그외에도 많은기능이 있다.

이 분류 체계를 HTML5 이후의 웹기술에 대응시켜 보기

HTML5 에서 사용가능한 기술요소들 (녹색 부분)

위 그림서 볼 수 있듯이 HTML5 덕분에 새로운 기능이 많이 늘어나기는 했지만 프론트엔드 웹 스택은 네이티브 플랫폼에 비해 아직 불완전하다. 처리되지 않은 HTML5 에서의 플랫폼 차이를 철저하게 설명하지는 않겠지만 그 중 몇 가지 예를 알아보자.

  • 레이아웃 관리: HTML5 는 플렉스박스(Flexbox)를 도입해서 종합적인 1 차원 레이아웃을 제공한다. 그러나 인터넷 익스플로러 10 과 현재의 크롬과 사파리처럼 이전의 웹킷 브라우저에서는 조금 다르게 구현된다. 2D 레이아웃 관리자인 Gridlayout 은 여전히 인터넷 익스플로러에서만 구현된다. HTML5 에 새로 생긴 Multicol 로 텍스트를 자동으로 컬럼화할 수 있지만, 이는 동일한 너비의 컬럼에서만 가능하다.

  • 인터랙션: HTML5 에서는 터치 이벤트 인식이 지원되지만 인터넷 익스플로러(pointerEvents)와 다른 브라우저(touch events)에서 서로 다르게 구현된다. 그뿐만 아니라 HTML5 에는 드래그 앤드 드롭 API 도 추가됐지만, 지나치게 이벤트가 많은 인터넷 익스플로러 5 마이크로소프트 드래그 앤드 드롭 API를 바탕으로 하기 때문에 기본 이벤트를 언제나 재정의해야 하고 아주 시끄러운 이벤트 버블링은 물론 다른 문제들도 나타난다.

  • 데이터 바인딩: HTML5 는 데이터 바인딩을 어떤 유형으로든 추가적으로 지원하지 않았다(아주 기본적인 형태의 데이터 바인딩이 인터넷 익스플로러 4 에 도입되었다가 나중에 폐기되기는 했다).

일부 브라우저는 이런 차이 일부를 채우기 위해 기능들을 추가했지만, 추가 기능이 폭넓게 수용되지는 않았다. 예를 들어, 크롬의 웹 컴포넌트 규격은 템플릿과 기본(조금은 복잡하더라도) 컴포넌트 모델에 대한 부분적인 지원을 포함한다. 또한 크롬은 유례없이 애플리케이션 도메인당 파일과 디렉토리를 지원한다. 그리고 복합 크로스 엘리먼트 텍스트 플로우에 대한 어도비 리전(Regions)의 규격은 인터넷 익스플로러와 사파리에서 부분적으로 사용 가능하지만 크롬에서는 아니다. 요악하자면 2014 년 중반인 현재, 완전한 프론트엔드 개발 스택을 원하는 개발팀에게 남아 있는 차이는 아주 크다. 그리고 가까운 시기에 이런 차이가 메워질 것이라는 기대는 크지 않다.

[역자주 : 2016년 현재는 내용이 다를수 있습니다. 위에서 언급된 내용에 대한 최신 브라우저 반영여부에 대해서는 확인하지 못했음을 말씀드립니다]

자바스크립트가 구원에 나서다

다행히도 1995 년에 자바스크립트가 처음 나온 이래로, 스크립트와 프레임워크, 라이브러리와 전처리기 개발은 증가 추세고 브라우저 기능을 확대했다. 그리고 GitHub 같은 코드 공유 사이트의 발달로 라이브러리와 프레임워크는 자바스크립트뿐만 아니라 이제는 CSS 에서도 계속해서 빠른 속도로 급증했다. 2014 년 봄 무렵, 깃허브의 공용 자바스크립트 저장소는 120 만 개가 넘는다.

개발팀이 당면한 새로운 문제는 기능 차이를 채우기 위한 라이브러리를 어떻게 찾느냐가 아니라 어떤 라이브러리를 사용하느냐다. 그리고 자신의 앱 포트폴리오, 기술 베이스와 배치 요구 조건에 맞는 프론트엔드 전략을 선택하는 것이 무엇보다도 중요하다. 개발팀 관리자가 내려야 할 주요 결정 하나는 자급자족 여부다. 깃허브 저장소의 98%는 1 주년 이후로 전혀 업데이트되지 않아서 공용 리소스 모음을 선택하기로 한 개발팀에게 자급자족은 어쩔 수 없는 선택이 된다.

상황 가늠하기

블로그 포스팅이나 트위터 메시지를 보면 “무엇이 최고의 프레임워크인가” 또는 개발자가 라이브러리 x와 y 중에서 무엇을 사용할지에 관한 주제가 많다. 그러나 경험 많은 개발팀은 이런 질문이 틀렸다는 것을 안다. 개발팀이 어떤 경우에는 물어야 할 올바른 질문은 다음이라고 생각한다.

  • 구축하고자 하는 앱 경험의 종류를 고려… Ÿ

  • 개발팀의 언어와 기술…

  • 앱의 유지 관리 라이프타임…

  • 지원해야 하는 브라우저…

  • 개발팀의 규모…

  • Ÿ무엇이든 간에 갖고 있을 수 있는 추가적인 요구조건…

앱 포트폴리오와 개발 조직을 위한 최고의 프레임워크와 라이브러리는?

예를 들어 최신 브라우저를 타깃으로 하고 콘텐츠만 있는 애플리케이션을 한 사람의 개발자가 작성하고 유지 관리하는 경우처럼 특정 유형의 애플리케이션 경험이라면 이 질문에 대해 프레임워크가 전혀 필요하지 않다고 답할 수 있다. 반면 규모가 크고 변화가 많은 팀이 개발한 복잡하고 상호의존적인 앱 포트폴리오의 경우, 조직에 걸친 하나의 프레임워크에 표준화하는 것이 해답일 수 있다.

이런 생각을 염두에 두고 지금부터는 가장 널리 쓰이는 프레임워크와 라이브러리의 스택이 우리의 프론트엔드 분류 체계와 어떻게 비교되는지 살펴본다. 프레임워크 기능을 잘 보여주는 도표를 이해하면 무엇이 최고의 프레임워크이냐는 질문에 대답하기가 더 쉬워질 것이다.

일반적인 프레임워크들과 라이브러리 개요

다음은 웹 앱 개발 커뮤니티에서 아주 많이 보이고 가장 눈에 띄는 프레임워크의 라이브러리들을 선별해 설명하고 있다.