프로젝트에서 보기 →

프론트엔드 개발 (Frontend web development) - A to Z

태그
기타 웹개발 web development 프론트엔드
시작일
종료일
수정일

https://www.youtube.com/watch?v=cT4frwzWaTk

# 1. 이건 꼭 알아야 한다^1

[? 질문] 프론트엔드(클라이언트 측) 기술이 왜 이렇게 많아졌고, 무엇부터/어떻게 공부해야 하는가^2
[= 답] 브라우저가 HTML/CSS/JavaScript를 해석해 렌더링하는 기본 구조 위에서, 개발자가 더 편하게 개발하도록 돕는 수많은 도구들이 파생된 것이며, 전부를 한 번에 공부하기보다 필요할 때 필요한 부분을 역으로 찾아 공부해야 한다.^2

[? 질문] 프론트엔드 기술의 큰 진화 흐름(역사)은 무엇이며, 각 단계의 핵심 문제의식은 무엇인가[^3]
[= 답] 시간순으로 DOM(문서 구조/조작) → AJAX(리로딩 없이 통신) → jQuery(쉽게 DOM/AJAX/호환성 처리) → SPA+CSR(앱처럼 부드러운 화면 전환) → **메타 프레임워크(SSR을 결합해 SEO 해결, 풀스택 경계 약화)**의 흐름으로 발전해왔다.[^3]

[? 질문] SPA/CSR의 대표적 문제(특히 SEO)는 무엇이며 해결책은 무엇인가[^4]
[= 답] CSR 기반 SPA는 서버가 제공하는 HTML이 “빈 페이지”에 가깝기 때문에 검색엔진 크롤러가 콘텐츠를 제대로 평가하지 못해 SEO에 불리해질 수 있고, 이를 해결하기 위해 SSR(Server Side Rendering) 을 함께 제공하도록 돕는 메타 프레임워크(Next.js/Nuxt/SvelteKit 등) 가 부상했다.[^4]

# 2. 큰 그림[^5]

이 콘텐츠는 “프론트엔드 웹 개발”에서 파생된 기술들이 왜 생겨났는지, 그리고 자바스크립트 중심으로 어떤 순서로 발전해 왔는지를 역사/문제-해결 관점에서 훑어가며 설명한다.[^5] 특히 로드맵을 ‘전부 공부해야 하는 목록’이 아니라 ‘필요할 때 꺼내 쓰는 도구상자’로 바라보는 학습 관점을 제시한다.[^6]

  • 브라우저와 DOM: 브라우저는 HTML/CSS/JS를 해석해 렌더링하며, DOM은 HTML 문서를 트리 구조로 메모리에 올려 JS로 화면을 동적으로 조작하게 만든다.[^7]
  • AJAX와 SPA/CSR: 리로딩 없이 서버와 데이터를 주고받는 AJAX가 등장했고, 이후 모던 프레임워크들이 SPA를 대중화해 모바일 앱처럼 “부드러운 전환”을 가능하게 했다.[^8]
  • 메타 프레임워크와 SSR: CSR의 SEO 문제를 해결하기 위해 SSR을 결합하고, 한 프로젝트에서 프론트/백을 함께 다루는 메타 프레임워크가 대세로 떠오르고 있다.[^9]

# 3. 하나씩 살펴보기[^10]

## 3.1 웹서비스의 기본 구조와 ‘로드맵 압도감’에 대한 관점 정리[^11]

영상은 웹서비스의 가장 기본 전제부터 깔고 시작한다: 모든 웹서비스는 클라이언트와 서버가 네트워크를 통해 데이터를 주고받는 구조라는 것이다.^1 여기서 “클라이언트 측 기술”을 통상 프론트엔드라고 부르며, 프론트엔드가 주로 실행되는 곳은 브라우저다.^2

브라우저의 역할을 영상은 아주 직설적으로 정의한다.

  • 브라우저는 HTML, CSS, JavaScript를 해석해서 화면에 렌더링하는 기계다.^2
    이 한 문장으로 이후 등장하는 모든 기술(라이브러리/프레임워크/렌더링 방식 등)을 “브라우저라는 실행 환경에서 개발을 편하게 하려고 생긴 것들”로 연결한다.[^12]

이후 화자는 “프론트엔드 로드맵” 이미지를 검색하면 수많은 기술이 나열된 그림을 쉽게 볼 수 있는데, 그 양이 너무 많아 압도될 지경이라고 말한다.[^13] 하지만 그 로드맵을 그대로 “전부 공부해야 할 커리큘럼”으로 받아들이면 안 된다고 강하게 선을 긋는다.[^14]

  • [h 여러분 이거 하나(로드맵 전체) 공부하면 안 됩니다] 라고 하며, 그렇게 하면 “죽을 때까지 못해요”라고 표현한다.[^14]
  • 대신 학습 전략으로 필요할 때마다 필요한 부분만 역으로 찾아서 공부하라고 제안한다.[^15]

이 관점을 정당화하기 위해, 로드맵 아래쪽으로 갈수록 파생된 수많은 기술들의 성격을 다음처럼 정리한다.

  • 브라우저가 HTML/CSS/JS를 해석해 렌더링하는 기본 구조는 같고,
  • 그 아래 파생된 수많은 기술은 “쉽게 말하면 개발자가 더 편하게 개발하기 위해 생긴 것”이라고 이해하면 된다는 것이다.[^12]
  • 즉 “생으로 HTML/CSS/JS만으로 만들기 어렵기 때문에” 생긴 도구들이라는 맥락을 준다.[^16]

또한 영상의 범위를 제한한다.

  • CSS 분야는 이번 영상에서 다루지 않겠다고 명시하고,[^17]
  • 자바스크립트 축(자바스크립트에서 파생된 기술)이 “어떻게 변화해 왔는지”를 전달하겠다고 한다.[^18]

자바스크립트 생태계를 “거의 30년 역사”로 두고, 그동안 계속 “어떻게 하면 더 편하게 쓸 수 있을까” 고민하면서 도구들이 나왔다는 맥락도 제공한다.[^19] 그리고 다시 한 번 핵심 전제를 반복한다:

  • [h 분명 알아야 할 건 개발자들이 더 편하라고 나온 기술들이란 점]이다.[^20]

마지막으로, 앞으로 다룰 “핵심 키워드 5개”를 시간순으로 예고한다.[^3] 영상의 구성은 다음 순서다.

  1. DOM[^21]
  2. AJAX[^22]
  3. jQuery[^23]
  4. SPA(Single Page Application)[^24]
  5. 메타 프레임워크[^25]

[!IMPORTANT] 학습 프레임(이 영상의 전제) 프론트엔드 기술의 폭발은 “새로운 본질”의 등장이라기보다, 브라우저 위에서 개발을 쉽게 하려는 도구의 누적이며, 로드맵은 전부 외우는 목록이 아니라 “필요 시 찾아 쓰는 지도”로 다뤄야 한다.[^12]

## 3.2 (1) DOM: 브라우저가 HTML을 ‘트리’로 관리하고 JS가 이를 조작한다[^21]

첫 번째 주제는 DOM(Document Object Model) 이다.[^21] 영상은 DOM을 “문서 객체 모델”이라 풀어 설명하면서, 여기서 말하는 “문서”는 HTML 파일을 의미한다고 못 박는다.[^21]

3.2.1 역사적 배경: 자바스크립트(1995)와 DOM(1998)[^26]

화자는 자바스크립트의 기원을 언급한다.

  • 자바스크립트는 브렌던 아이크(Brendan Eich)가 넷스케이프에서 만들었고 1995년에 나왔다고 말한다.[^26]
  • 초창기 자바스크립트는 “아주 일부분의 기능만 할 수 있었다”고 덧붙인다.[^26]
  • 그리고 DOM 개념은 1998년에 생겼다고 이야기한다.[^27]

이렇게 JS(언어)와 DOM(브라우저가 문서를 모델링/조작하게 하는 체계)의 등장을 분리해 설명하면서, 프론트엔드의 시작점이 “문서를 조작해서 화면을 바꾸는 능력”에 있었음을 암시한다.[^21]

3.2.2 DOM을 ‘트리(자료구조)’로 이해시키는 비유[^28]

DOM을 설명할 때 영상은 나무/트리 이미지를 보여준다.[^28] 흔히 DOM을 “틀”이라고 부른다는 표현도 나오는데,[^29] 여기서 컴퓨터공학 커리큘럼의 자료구조를 끌어온다.[^30]

  • 자료구조에는 “틀(구조)” 개념이 있고,
  • 트리 자료구조는 데이터를 트리 형태로 구조적으로 저장해 두고 빨리 찾을 수 있다는 장점이 있다는 식으로 설명한다.[^30]
  • 브라우저는 이런 DOM 트리를 메모리에 저장해서 관리한다고 말한다.[^31]

즉 DOM은 단순히 “HTML을 문자열로 읽는 것”이 아니라, 브라우저 내부에서 트리 구조로 올려두고 탐색/수정 가능한 형태로 만든 모델이다.[^31]

3.2.3 DOM 조작 예시: 클릭하면 이미지가 바뀌는 원리[^32]

영상은 “DOM 조작이 무엇인지”를 움짤/예시로 명확하게 보여준다고 한다.[^32] 예시는 다음 흐름이다.

  • HTML에 버튼 태그와 이미지 태그가 존재한다.[^33]
  • 버튼의 onclick 속성 안에 자바스크립트 코드가 들어 있다.[^34]
  • 버튼을 클릭하면 그 자바스크립트 코드가 DOM, 즉 HTML 태그를 조작해서 이미지를 “순간적으로 바꾸는” 동작을 한다.[^35]

이 예시를 통해 영상이 강조하는 결론은 다음이다.

  • 자바스크립트가 DOM을 조작함으로써 화면을 동적으로 만들 수 있다.[^35]
  • 이것이 “자바스크립트가 돔을 조작해서 웹을 다이나믹하게 만든다”는 뜻이다.[^36]

3.2.4 Web API: getElementById 같은 ‘가져다 쓰는 기능’[^37]

DOM 조작에서 자바스크립트가 직접 모든 기능을 다 구현하는 것이 아니라, 브라우저가 제공하는 중간 계층이 있음을 그림으로 보여준다: JS로 DOM을 조작할 때 사이에 Web API가 있다는 것이다.[^37]

영상은 API를 먼저 일반적으로 정의한다.

  • API는 “남이 자기를 써 달라고 만들어 놓은 기능”이라고 설명한다.[^38]
  • 그럼 Web API는 “웹(브라우저)이 자기를 쉽게 써 달라고 만들어 놓은 기능”이라고 연결한다.[^39]

그리고 대표 사례로 getElementBy... 류 함수를 든다.

  • “여러분이 getElementBy…라는 함수를 만든 적이 있나요? 아니죠. 가져다 쓰는 거죠.”라는 식으로, 브라우저가 제공하는 기능을 호출하는 구조임을 강조한다.[^40]

3.2.5 브라우저 전쟁 시기: 표준 부재로 DOM/Web API가 브라우저마다 달랐다[^41]

DOM과 Web API의 초창기 역사에서 중요한 문제로 “브라우저 간 비호환”을 짚는다. 이 슬라이드는 “넣을까 말까 하다가 넣은, 참고로만 보면 되는” 내용이라며 강도는 낮추지만,[^42] 프론트엔드 역사에서 왜 라이브러리/표준화가 중요해졌는지 맥락을 제공한다.

  • 당시 넷스케이프와 인터넷 익스플로러가 점유율 싸움을 하던 “브라우저 전쟁” 시기였고,[^43]
  • 누군가가 중재해 표준을 만들던 시기가 아니라서 DOM과 Web API가 브라우저마다 달랐다고 한다.[^44]
  • 그래서 웹 프로그래머가 “두 브라우저에서 돌아가는 사이트”를 만들기 위해 매우 고생했다고 말한다.[^45]

이 문제의식은 뒤에서 jQuery의 “크로스 브라우징” 장점을 설명하는 복선으로 기능한다.[^46]

## 3.3 (2) AJAX: ‘페이지 새로고침 해방’—리로딩 없이 비동기 통신[^22]

두 번째 주제는 AJAX이며, 부제로 “페이지 새로고침 해방”이라는 표현을 붙였다.[^22] AJAX는 “Asynchronous JavaScript and XML”의 약자라고 소개하고,[^47] 핵심을 “비동기로 서버와 통신하는 기술”로 설명한다.[^48]

3.3.1 비동기란 무엇인가: 쿠팡 주문 비유[^49]

AJAX를 모르는 사람을 위해 “비동기”를 일상 비유로 풀어준다.[^49]

  • 쿠팡에서 온라인 주문 버튼을 눌렀다고 해서 배달이 올 때까지 아무것도 안 하고 가만히 기다리지 않듯이,[^49]
  • 학교에 가거나 회사에 가거나 운동을 하는 등 “일상 생활을 하면서” 시간을 보낸다.[^50]
  • 그러다 어느 순간 문 앞에 주문한 상품이 도착해 있고, 그때 물건을 받는다.[^51]

이 비유를 웹에 대응시키면,

  • 웹도 비동기로 특정 정보를 서버에 요청해두고,
  • 그동안 클라이언트는 할 일을 하다가,
  • 서버 응답(답장)이 오면 그 정보를 사용하면 된다는 것이다.[^52]

3.3.2 AJAX의 핵심 이점: 리로딩 없이 정보 교환[^53]

영상이 말하는 AJAX의 “핵심”은 다음 한 줄로 정리된다.

  • 웹에서 비동기의 이점은 리로딩(새로고침) 없이 정보를 주고받는 것이다.[^53]

그리고 AJAX가 1999년에 나온 기술이라고 연도를 제시한다.[^54] 다만 처음부터 유명하진 않았고, “처음에는 쓰는 사람이 없어서 유명하지 않았다”고 말한다.[^55]

3.3.3 구글 메일/구글맵으로 ‘떡상’: 지도만 업데이트되는 사례[^56]

AJAX가 대중적으로 부상한 계기로 구글을 든다.

  • 구글이 지메일과 구글맵에 사용하면서 “떡상”했다는 표현을 쓴다.[^56]
  • “역주행”이라는 말로, 나중에 재평가/급부상했다는 뉘앙스를 준다.[^57]

구글맵 사례를 움짤로 설명한다.

  • 사용자가 마우스로 스크롤만 하는데, 페이지 전체가 리로딩되지 않고 지도만 업데이트된다.[^58]
  • 원리는 스크롤 이벤트가 발생할 때마다 서버에 요청하고, 비동기로 데이터를 받아 지도를 업데이트하는 것이라고 설명한다.[^59]

3.3.4 전통적 AJAX 사용법(XMLHttpRequest)과 더 쉬운 대안들[^60]

AJAX로 서버와 정보를 주고받으려면 전통적으로 다음이 필요하다고 말한다.

  • XMLHttpRequest 객체를 생성하고,
  • 요청 정보를 담아 서버에 보내는 방식이 “정석”이다.[^60]

하지만 사용법이 어렵기 때문에 “이 방법으로 사용하는 사람은 없다”고 단언한다.[^61] 대신 더 쉬운 사용법/도구들이 있다고 나열한다.

  • jQuery를 이용하는 방법[^62]
  • Axios라는 라이브러리를 이용하는 방법[^62]
  • Web API인 fetch 함수를 이용하는 방법[^62]

그리고 “상황에 맞게 입맛대로 골라 쓰면 된다”고 정리한다.[^63]

3.3.5 도구 선택의 맥락: 모던 프레임워크 vs 서버 템플릿 기반(옛날 방식)[^64]

화자는 어떤 상황에서 Axios/Fetch를, 어떤 상황에서 jQuery를 많이 쓰는지 “개발 방식”에 따라 설명한다.

  • 보통 React/Vue/Svelte 같은 모던 프레임워크로 개발할 때는 Axios나 Fetch를 사용한다고 한다.[^64]
  • 서버에서 템플릿 엔진으로 완성된 HTML을 전달하는 방식(“옛날 방식”)으로 개발할 때는 jQuery를 많이 사용한다고 말한다.[^65]
    • 이유: jQuery가 AJAX를 쉽게 사용하도록 지원해서 “한 방 해결”이 된다는 식으로 설명한다.[^65]

3.3.6 기존 방식 vs AJAX 방식 비교: 로그인/링크 클릭 vs 좋아요 버튼[^66]

AJAX 파트를 마무리하며, 서버 통신에서 “기존 방식”과 “AJAX 방식”을 예시로 비교한다.[^66]

  • 기존 방식: 로그인하거나 링크 클릭 같은 경우 페이지 전체가 리로딩(새로고침)된다.[^67]
  • AJAX 방식: 예를 들어 “좋아요 버튼”을 누를 때, 버튼 하나 누르려고 페이지 전체를 리로딩하면 네트워크 자원 낭비가 크다.[^68]
    • AJAX 덕분에 좋아요 버튼과 숫자 같은 일부분만 업데이트할 수 있게 됐다고 한다.[^69]

[!TIP] AJAX를 떠올리는 가장 쉬운 기준 “페이지 전체를 다시 받을 필요가 없는 작은 상호작용(좋아요/카운트/부분 갱신)”이 많은 서비스일수록, 리로딩 없이 데이터만 주고받는 AJAX의 효용이 커진다.[^68]

## 3.4 (3) jQuery: 한때 프론트엔드의 ‘제왕’—DOM, AJAX, 애니메이션, 호환성[^23]

세 번째 주제는 jQuery이며, 부제로 “한때 프론트엔드 제왕”이라는 표현을 쓴다.[^23] 영상은 jQuery를 한 문장으로 정의한다.

  • jQuery는 자바스크립트를 더 쉽게 쓰려고 만들어진 라이브러리다.[^70]

3.4.1 2006년 등장과 당시 위상: “없으면 프론트엔드 개발 불가” 수준[^71]

  • jQuery는 2006년에 등장했다고 말한다.[^71]
  • 당시에는 “거의 혁명”이었고, “jQuery 없으면 프론트엔드 개발을 할 수 없을 정도”였다는 분위기를 전한다.[^72]

또한 당시 산업 맥락을 덧붙인다.

  • 모던 프레임워크로 개발하던 시절이 아니어서 “프론트엔드 개발자”라는 말도 없었다고 한다.[^73]
  • 그냥 백엔드 개발자가 다 하거나, 혹은 웹 퍼블리셔가 프론트엔드 전체를 담당했다고 말한다.[^74]
  • 당시 채용 공고의 자격 요건에 jQuery를 요구하는 경우가 많았다고 한다.[^75]
  • 심지어 “jQuery는 할 줄 아는데 자바스크립트 문법을 모르는 사람도 꽤 많다”는 말로, jQuery의 보급력이 언어 학습을 앞지를 정도였음을 강조한다.[^76]

3.4.2 jQuery의 역할 1: DOM 조작을 훨씬 짧은 코드로[^77]

jQuery가 실제로 어떤 일을 했는지 네 가지 역할로 설명한다.[^77]

첫째, DOM을 쉽게 조작할 수 있다.[^77]

  • 슬라이드에서 비교 코드가 나오며, jQuery를 쓰면 코드가 훨씬 짧아진다고 말한다.[^78]

3.4.3 역할 2: 애니메이션 함수 제공으로 UI 조작이 쉬움[^79]

둘째, 미리 만들어진 애니메이션 함수를 가져다 쓸 수 있다.[^79]

  • 예시로 hide(), show() 같은 함수를 언급하며 UI 조작을 쉽게 할 수 있다고 한다.[^80]

3.4.4 역할 3: AJAX를 쉽게—기존 XMLHttpRequest 대비 간결함[^81]

셋째, AJAX를 쉽게 사용할 수 있게 해준다.[^81]

  • 기존 XHR 방식과 jQuery 방식 코드를 나란히 보여주며, jQuery 방식이 “훨씬 짧고 깔끔”하다고 강조한다.[^82]

이는 앞서 AJAX 파트에서 “정석 XHR은 어렵고 잘 안 쓴다”는 주장과 연결되며, 그 ‘쉬운 대안’ 중 하나로 jQuery가 자리했음을 강화한다.[^61]

3.4.5 역할 4: 크로스 브라우징—브라우저 전쟁 시대의 결정적 가치[^83]

넷째(마지막) 역할이 영상에서 특히 강조되는 포인트다: 크로스 브라우징이다.[^83]

  • 크로스 브라우징이란 “하나의 코드로 모든 브라우저를 대응”하는 것이라고 설명한다.[^84]
  • 당시 브라우저 전쟁 시절에는 호환이 안 되는 것이 매우 많았고, 브라우저마다 맞추려면 “개고생”했을 것이라 말한다.[^85]
  • 그런데 jQuery를 사용하면 브라우저 호환성을 “알아서 맞출 수 있었다”고 한다.[^86]
  • 그리고 이것이 “결정적인 이유”라고 결론낸다.[^86]

즉, jQuery의 가치는 단순 문법 설탕(syntactic sugar)이 아니라, 분열된 브라우저 환경에서의 추상화/호환성 레이어 역할이 매우 컸다는 관점이다.[^86]

마무리로, jQuery는 지금도 많이 사용하지만 당시에는 정말 프론트엔드의 끝판왕이었다고 정리한다.[^87]

## 3.5 (4) SPA: 모바일 앱처럼 스무스한 전환—모던 프레임워크의 시대[^24]

네 번째 주제는 SPA(Single Page Application) 이다.[^24] 부제로 “모바일 앱처럼 바뀌는 트렌드”라는 표현을 달아, 사용자 경험의 변화(끊김 없는 전환)를 강조한다.[^88]

3.5.1 2010년 이후 모던 프레임워크의 등장 = SPA를 가능하게 하는 도구들[^89]

영상은 2010년부터 모던 자바스크립트 프레임워크가 등장하기 시작했다고 말한다.[^89] 그리고 여기서 “모던 프레임워크”를 이렇게 정의한다:

  • 모던 프레임워크란 SPA를 가능하게 만들어주는 도구를 말한다.[^90]

이후 주요 프레임워크들을 시간대와 함께 나열하며, 각각의 배경도 짧게 덧붙인다.

  • 2010년: Angular(앵귤러) 등장[^91]
    • 구글이 개발한 도구라고 설명한다.[^92]
  • 그 즈음: React 등장[^93]
    • 페이스북이 자기들이 쓰려고 만든 도구를 오픈소스로 공개한 케이스라고 소개한다.[^94]
  • 그 즈음: Vue 등장[^95]
    • 구글 프로그래머였던 “에반 유”가 앵귤러를 쓰다가 불편한 점을 개선해 만든 프레임워크라고 설명한다.[^96]
  • 그 즈음: Svelte 등장[^97]
    • 뉴욕타임스에서 일하던 “리치 해리스(Rich Harris)”가 만든 프레임워크라고 소개한다.[^98]

(영상 자막에는 일부 발음/표기가 흔들리지만, 핵심은 “SPA를 가능케 한 프레임워크들이 2010년대에 연속 등장했다”는 시간축 설명이다.[^89])

3.5.2 SPA의 사용자 경험 예시: 네이버 웹툰처럼 새로고침 없이 화면 전환[^99]

“백문이 불여일견”이라며 네이버 웹툰 사용 장면을 움짤로 보여주고, 이것이 SPA라고 말한다.[^99]

  • 페이지가 새로고침되지 않고
  • 모바일 앱처럼 스무스하게 화면이 바뀌는 것을 볼 수 있다고 설명한다.[^100]
  • 그리고 이런 방식으로 개발하는 것이 트렌드가 되었다고 말한다.[^101]

3.5.3 SPA vs MPA(NPA) 비교: “페이지 하나”와 “내부 요소 교체”[^102]

영상은 SPA와 “NPA”를 비교한 사진을 보여주는데, 여기서 NPA를 멀티페이지 애플리케이션(MPA)을 의미하는 말로 설명한다.[^102] 즉 과거에 해오던 방식(페이지 여러 개)이다.[^102]

  • SPA는 페이지가 하나이고, 그 안의 내부 요소를 바꿔서 화면을 바꾼다.[^103]

3.5.4 React 프로젝트 예시: index.html이 하나, 그리고 ‘빈 HTML’[^104]

“페이지가 하나”를 코드 구조로 납득시키기 위해 React 프로젝트 예시를 든다.[^104]

  • 파일 트리를 보면 index.html이라는 HTML 파일이 딱 하나만 존재한다.[^104]
  • 그리고 그 HTML 파일은 “아무 내용이 없는 빈 파일”이라고 설명한다.[^105]
  • 즉 React로 만든 자바스크립트 코드가 그 빈 HTML 요소들에 내용을 삽입해, 클라이언트 측에서 화면을 렌더링한다는 개념이라고 말한다.[^106]

이 방식의 명칭을 다음과 같이 정의한다.

  • 이런 걸 CSR(Client Side Rendering) 방식이라고 하며, 말 그대로 “클라이언트 사이드에서 화면을 렌더링”한다는 의미라고 한다.[^107]

3.5.5 CSR 동작 단계 정리: 최초엔 빈 HTML, 이후엔 데이터만 교환하며 업데이트[^108]

영상은 정리 차원에서 CSR 흐름을 스텝으로 반복 설명한다.[^108]

  • Step 1: 최초에 서버에서 이것저것 받아오지만, HTML이 아무 내용도 없기 때문에 브라우저에서 자바스크립트가 화면을 그린다.[^109]
  • Step 2부터: 서버와는 데이터만 주고받고, 화면을 리로딩 없이 업데이트할 수 있다.[^110]

즉, SPA/CSR은 “초기 로딩 이후에는 부분 업데이트가 매우 자연스럽다”는 방향으로 UX와 개발 방식이 바뀌었다는 설명이다.[^110]

3.5.6 프레임워크의 규칙: DOM 직접 조작 대신 ‘정한 규칙’ 위에서 개발[^111]

SPA 파트의 마지막에서 화자는 프레임워크 사용의 의미를 “규칙”으로 설명한다.[^111]

  • 이제는 프레임워크를 쓰기 때문에 프레임워크가 정한 규칙 위에서 코드를 작성하게 된다.[^111]
  • 예전처럼 getElementById로 DOM을 직접 조작하는 방식이 아니라는 것이다.[^112]
  • 그래서 프레임워크를 정했으면 그 규칙을 따로 공부해야 한다고 말한다.[^113]
  • “로마에 가면 로마법을 따라야죠”라는 비유로 러닝커브를 설명한다.[^114]

하지만 결론은 프레임워크 사용의 실용성이다.

  • 처음에 러닝커브가 있어 시간이 걸리지만, 결국 프레임워크를 쓰는 게 SPA 구현에 훨씬 쉽다고 한다.[^115]
  • 생(바닐라) 자바스크립트로 SPA를 하면 유지보수가 힘들어서 프레임워크를 쓰는 것이라고 정리한다.[^116]

[!NOTE] 이 영상이 말하는 “모던 프레임워크”의 핵심 가치 단순히 문법이 편해지는 수준이 아니라, SPA라는 개발/UX 패러다임을 “유지보수 가능하게” 만들도록 규칙과 구조를 제공하는 데 의미가 있다.[^115]

## 3.6 (5) 메타 프레임워크: CSR의 SEO 문제를 SSR로 보완, 그리고 풀스택 경계의 약화[^25]

다섯 번째 주제는 메타 프레임워크다.[^25] 부제로 “프론트엔드와 백엔드의 경계가 점점 허물어진다”는 표현을 단다.[^117]

3.6.1 문제 제기: CSR의 명확한 문제점 = SEO[^4]

화자는 방금 SPA에서 CSR을 다뤘음을 상기시키며, CSR에는 “명확한 문제점”이 있다고 한다.[^4] 그 문제는 SEO(Search Engine Optimization) 이다.[^4]

여기서 SEO의 필요성을 먼저 설명한다.

  • 웹사이트를 “혼자 보려고” 만드는 게 아니라 최대한 많은 사람이 봐야 의미가 있다고 말한다.[^118]
  • 구글 같은 검색 엔진은 365일 크롤러로 수많은 웹사이트를 돌아다니며,[^119]
  • 사이트에 점수를 매기고 등수를 결정한다고 한다.[^120]
  • 좋은 콘텐츠가 있는 사이트일수록 높은 점수를 받고,[^121]
  • 사용자가 특정 키워드로 검색하면 순위가 높은 사이트를 상위에 노출해줄 것이라고 설명한다.[^122]

따라서 검색 노출을 위해 SEO 작업을 해야 한다는 결론을 내리고,[^123] 그 다음 CSR을 다시 생각해 보자고 한다.[^124]

3.6.2 CSR에서 크롤러가 보는 것: 서버에는 “페이지 하나”, 그것도 “빈 HTML”[^125]

영상의 핵심 논증은 “크롤러가 무엇을 보느냐”에 있다.

  • 구글 크롤러는 서버를 돌아다닐 것이라고 말하고,[^125]
  • 그런데 CSR 기반 SPA에서 서버가 갖고 있는 페이지는 “하나”라고 한다.[^126]
  • 그리고 그 페이지는 “아무 내용도 없는 빈 HTML 파일”이었다는 점을 다시 강조한다.[^127]
  • 그러면 검색엔진 입장에서는 “아무 내용 없는 사이트”로 취급받아 노출이 잘 되지 않는다고 설명한다.[^128]

이 지점에서 화자는 “엄청난 문제라는 걸 알았다”고 말하며,[^129] 즉시 해결책 질문으로 전환한다.

[? 질문] 그럼 해결책은 뭘까요[^130]
[= 답] SSR 방식을 함께 사용하면 됩니다[^131]

3.6.3 해결책: SSR(Server Side Rendering) 결합[^131]

SSR을 “Server Side Rendering”의 줄임말로 소개하고,[^131] 일반적으로 클라이언트와 서버가 정보를 주고받던 전통적 방식을 가리킨다고 설명한다.[^132]

  • 서버에서 완성된 HTML을 받아와서 화면 전체를 다시 그린다.[^133]
  • 그래서 페이지 전체가 새로고침되었던 방식이라고 말한다.[^134]

즉 메타 프레임워크의 흐름은 “CSR이 주는 앱 같은 UX/개발 편의”는 살리되, “SSR이 주는 검색엔진 친화성(완성 HTML 제공)”을 결합하려는 시도로 제시된다.[^131]

3.6.4 2016년 이후: 메타 프레임워크가 CSR+SSR을 가능하게[^135]

화자는 2016년부터 메타 프레임워크들이 CSR과 SSR을 가능하게 했다고 말한다.[^135] 그리고 대표 도구를 나열한다.

  • Next.js: React 기반 메타 프레임워크[^136]
  • Nuxt.js: Vue 기반 메타 프레임워크[^137]
  • SvelteKit: Svelte 기반 메타 프레임워크[^138]

그리고 요즘 메타 프레임워크의 인기가 “급상승 중”이라고 말한다.[^139]

3.6.5 메타 프레임워크의 장점: JS만으로 풀스택, 높은 생산성, 많은 쇼케이스[^140]

영상은 메타 프레임워크 인기를 설명하며 장점을 든다.

  • 자바스크립트 언어만으로 풀스택 구현이 가능하다는 장점[^140]
  • 생산성이 매우 좋다는 장점[^140]
  • 메타 프레임워크로 만든 쇼케이스를 보면 유명한 사이트가 많다고 말하며, 다양한 사이트 예시 화면을 보여준다.[^141]

또한 이러한 트렌드가 지속될 것이라고 하며, “대세”라는 표현으로 정리한다.[^142]

3.6.6 결론: 한 프로젝트에서 프론트+백을 함께 → 경계가 허물어진다[^143]

마지막으로, 메타 프레임워크의 구조적 특징을 “한 프로젝트 안에서 프론트엔드와 백엔드를 동시에 진행”하는 것으로 요약한다.[^143] 이 특성 때문에:

  • 결국 갈수록 프론트엔드와 백엔드의 경계가 허물어질 것 같다는 생각이라고 말한다.[^143]

영상은 여기까지가 준비한 내용이라고 마무리하며, 정성 들여 만든 영상이니 구독/좋아요/댓글을 요청하고 끝낸다.[^144]

[!IMPORTANT] 메타 프레임워크를 이 영상이 보는 관점 메타 프레임워크는 “프레임워크 위의 프레임워크”로서 CSR의 UX와 SSR의 SEO/초기 렌더 이점을 결합하고, 개발 형태를 풀스택에 가깝게 끌어가며 프론트/백 경계를 흐리는 방향으로 진화한다.[^135]

# 4. 핵심 통찰[^145]

  1. [c 프론트엔드 기술의 폭발은 ‘브라우저의 본질 변화’라기보다 ‘개발을 더 편하게 하려는 도구의 누적’으로 이해해야 학습 전략이 선다.] [^12]

    • 로드맵을 통째로 외우려 하지 말고, 필요한 순간에 필요한 도구를 찾아 쓰는 방식이 합리적이라는 메시지로 이어진다.[^15]

  2. [h DOM은 “HTML을 트리로 메모리에 올려 관리하는 브라우저의 내부 모델”이며, JS는 Web API를 통해 DOM을 조작해 화면을 동적으로 만든다.] [^31]

    • 실행 관점에서 프론트엔드는 “DOM(상태)을 바꿔 화면을 바꾸는 일”로 귀결된다는 토대를 깐다.[^36]

  3. [h AJAX의 본질은 ‘비동기’ 그 자체보다 ‘리로딩 없이 필요한 데이터만 주고받을 수 있음’에 있다.] [^53]

    • 좋아요 버튼 같은 “부분 갱신”에서 네트워크 낭비를 줄이고 UX를 개선한다는 논지가 명확하다.[^68]

  4. [h jQuery의 시대적 가치는 짧은 문법뿐 아니라, 브라우저 호환 지옥에서 “하나의 코드로 여러 브라우저”를 대응시킨 크로스 브라우징에 있었다.] [^86]

    • 브라우저 전쟁 시기의 비표준 문제를 해결하는 추상화 레이어로서의 의미가 크다.[^44]

  5. [h SPA/CSR은 ‘페이지 하나+내부 교체’로 앱 같은 UX를 만들지만, 프레임워크의 규칙을 받아들이는 대가(러닝커브)가 있다.] [^114]

    • 바닐라 JS로 SPA를 유지보수하기 어렵기 때문에 프레임워크가 실전에서 선택된다는 결론이다.[^116]

  6. [c CSR의 SEO 문제는 “서버가 가진 HTML이 빈 페이지”라는 구조에서 비롯되며, SSR 결합이 실질적 해결책으로 제시된다.] [^127]

    • 검색엔진 크롤링/평가 메커니즘을 근거로 문제를 설명하고 해결을 SSR로 연결한다.[^131]

  7. [h 메타 프레임워크는 CSR+SSR을 동시에 제공하며, JS만으로 풀스택을 구현하는 생산성 때문에 대세가 되고 프론트/백 경계가 흐려진다.] [^140]

    • 실행 가능한 시사점:
      • SPA를 만들면서 검색 유입이 중요하면 SSR을 고려할 수 있는 스택(예: Next/Nuxt/SvelteKit) 을 검토하라는 방향으로 이어진다.[^135]
      • “프론트엔드” 역할이 점점 서버 영역까지 확장될 수 있다는 커리어/역량 확장 신호로도 읽힌다.[^143]

# 5. 헷갈리는 용어 정리[^146]

클라이언트(Client): 서버와 네트워크로 데이터를 주고받으며, 웹에서는 주로 브라우저를 의미한다.^1
서버(Server): 클라이언트 요청을 받고 응답(데이터/HTML 등)을 제공하는 쪽이다.^1
프론트엔드(Frontend): 클라이언트 측 기술을 의미하며 브라우저에서 실행되는 영역을 가리킨다.^2
DOM(Document Object Model): HTML 문서를 객체/트리 구조로 표현한 모델로, 브라우저가 메모리에 저장해 관리한다.[^31]
DOM 조작: 자바스크립트가 DOM(HTML 요소)을 변경해 화면을 동적으로 바꾸는 행위다.[^35]
Web API: 브라우저(웹)가 제공하는 기능으로, 개발자는 이를 “가져다” 호출해 DOM 조작, 통신 등을 수행한다.[^39]
AJAX: 비동기로 서버와 통신해 리로딩 없이 필요한 정보만 주고받는 기술(Asynchronous JavaScript and XML).[^47]
XMLHttpRequest(XHR): AJAX 통신의 전통적/정석적 방식의 객체로 소개되지만 사용이 어렵다고 언급된다.[^60]
Fetch: Web API로 제공되는 통신 함수로, 더 쉬운 AJAX 수단 중 하나로 언급된다.[^62]
Axios: 통신을 돕는 라이브러리로, 모던 프레임워크 개발 시 자주 사용된다고 언급된다.[^64]
jQuery: 자바스크립트를 더 쉽게 쓰기 위한 라이브러리로, DOM/AJAX/애니메이션/크로스 브라우징을 돕는다.[^70]
SPA(Single Page Application): 페이지가 하나이고 내부 요소를 바꿔 화면을 전환하는 방식이다.[^103]
NPA/MPA(Multi Page Application): 과거 방식으로, 여러 페이지를 이동하며 전체 리로딩이 일어나기 쉬운 구조로 대비된다.[^102]
CSR(Client Side Rendering): 클라이언트(브라우저)에서 자바스크립트로 화면을 렌더링하는 방식이다.[^107]
SSR(Server Side Rendering): 서버에서 완성된 HTML을 만들어 내려주는 렌더링 방식으로 설명된다.[^133]
메타 프레임워크: CSR과 SSR을 모두 가능하게 해주며, 프론트/백을 한 프로젝트에서 다루는 경향을 강화하는 도구(Next.js, Nuxt.js, SvelteKit 등).[^135]
SEO(Search Engine Optimization): 검색 엔진 노출을 위해 사이트를 최적화하는 작업/관점이며, CSR의 약점으로 연결된다.[^123]

참고(콘텐츠 정보)[^147]

  • 제목: 프론트엔드 개발 (Frontend web development) - A to Z[^147]
  • 채널: 코딩사과[^147]
  • 길이: 17분 45초[^147]
  • 링크: https://www.youtube.com/watch?v=cT4frwzWaTk[^147]
  • 제공된 키워드: 웹개발, web development, 프론트엔드, frontend, jQuery, SPA, Single Page Application, CSR, SSR, meta framework[^147]

[^3]: @[01:45] "다섯 가지... 시간순으로 다룹니다" + @[02:24] DOM + @[05:11] AJAX + @[08:50] jQuery + @[11:12] SPA + @[14:45] 메타 프레임워크 [^4]: @[14:52] "csr... 문제점... Seo" + @[16:19] "SSR 방식을 함께 사용하면 됩니다" [^5]: @[01:05] "자바스크립트 축 기술이 어떻게 변화해 왔는지" + @[01:49] "시간순으로 다룹니다" [^6]: @[00:29] "여러분 이거 하나 공부하면 안 됩니다" + @[00:36] "필요할 때마다 필요한 부분만 역으로 찾아서 공부" [^7]: @[02:24] DOM 소개 + @[03:55] "자바스크립트가 돔을 조작해서 웹을 다이나믹" [^8]: @[05:25] AJAX 비동기 통신 + @[12:28] SPA는 새로고침 없이 스무스 [^9]: @[16:37] "2016년부터 메타 프레임웍... csr ssr 가능" + @[17:03] "자바스크립트 언어만으로 풀 스택" [^10]: @[01:45] "다섯 가지... 시간순" [^11]: @[00:00]~@[01:00] 도입부 전개(클라/서버, 브라우저, 로드맵) [^12]: @[00:46]~@[00:55] "파생된 수많은 기술들은... 개발자가 더 편하게... 생으로 html css 자바스크립트만으로 만들기 어렵기 때문에" [^13]: @[00:13] "프론트엔드 로드맵" + @[00:19] "너무 많아서 압도" [^14]: @[00:29] "이거 하나 공부하면 안 됩니다" + @[00:33] "죽을 때까지 못해요" [^15]: @[00:36] "필요할 때마다 필요한 부분만 역으로 찾아서 공부" [^16]: @[00:55] "생으로 html CSS 자바스크립트만으로 만들기 어렵기 때문에 생긴 것들" [^17]: @[01:00] "css 분야는... 다루지 않겠습니다" [^18]: @[01:05] "자바스크립트 축 기술이 어떻게 변화" [^19]: @[01:21] "웹... 1990... 자바스크립트 95" + @[01:29] "거의 30년... 더 편하게" [^20]: @[01:39] "분명 알아야 할 건 개발자들이 더 편하라고 나온 기술" [^21]: @[02:24] "첫 번째 주제는 돔입니다" [^22]: @[05:11] "두 번째 주제는... (AJAX)" [^23]: @[08:50] "세 번째 주제는 제이쿼리입니다" [^24]: @[02:11] "넷째 spa... 싱글 페이지 어플리케이션" [^25]: @[02:17] "다섯째... 메타 프레임워크" + @[14:45] "다섯 번째 주제는 메타 프레임웍" [^26]: @[02:31] "자바스크립트는... 1995년에" [^27]: @[02:37]~@[02:48] "돔... 98년에 생겼습니다" [^28]: @[02:53] "나무가 있죠" [^29]: @[02:58] "흔히 돔을 틀이라고" [^30]: @[03:04]~@[03:09] "자료 구조... 트리... 구조적으로 저장... 빨리 찾" [^31]: @[03:14] "이런 돔 트리를 브라우저는 메모리에 저장해서 관리" [^32]: @[03:20] "움짤이 돔 조작... 명확" [^33]: @[03:28]~@[03:36] "html 태그... 버튼과 이미지 태그" [^34]: @[03:36]~@[03:41] "온 클릭... 자바스크립트 코드" [^35]: @[03:41]~@[03:46] "버튼 클릭... 이미지를 순간적으로 바꾸는" [^36]: @[03:55] "자바스크립트가 돔을 조작해서 웹을 다이나믹" [^37]: @[04:00]~@[04:06] "돔을 조작... 사이에 웹 API" [^38]: @[04:06] "API... 남이 자기를 써 달라고 만들어 놓은 기능" [^39]: @[04:12] "웹 API... 웹이 자기를 쉽게 써 달라고" [^40]: @[04:27]~@[04:44] "겟 엘리먼트... 만든 적 있나요... 가져다가 쓰는" [^41]: @[04:49]~@[05:03] 초기 브라우저 세력다툼 + DOM/Web API 브라우저마다 다름 [^42]: @[04:49] "넣을까 말까... 참고로만" [^43]: @[04:55] "네스케이프... 인터넷 익스플로러... 점유율 싸움" [^44]: @[05:03] "도미랑 웹 API... 브라우저마다 달랐습니다" [^45]: @[05:07]~@[05:11] "두 개 브라우저... 개고생" [^46]: @[10:39]~@[11:01] jQuery의 크로스 브라우징 설명과 연결 [^47]: @[05:18] "에이스는... 자바스크립트 앤 xml" [^48]: @[05:25] "비동기로 서버랑 통신" [^49]: @[05:30]~@[05:38] "쿠팡... 주문... 가만히 기다리나요" [^50]: @[05:46]~@[05:54] "학교... 회사... 운동" [^51]: @[05:54]~@[06:01] "문앞에... 배달" [^52]: @[06:01] "웹도 비동기로... 답장이 오면" [^53]: @[06:09] "핵심... 리로딩 없이 새로고침 없이" [^54]: @[06:09]~@[06:17] "99년에 나온 기술" [^55]: @[06:17]~@[06:25] "처음에는 쓰는 사람이 없어서" [^56]: @[06:25] "구글이 메일... 구글 맵... 떡상" [^57]: @[06:36] "역주행" [^58]: @[06:43]~@[06:50] "페이지 전체... 리로딩... 지도만 업데이트" [^59]: @[06:50]~@[06:56] "이벤트... 서버 요청... 비동기로 데이터... 지도 업데이트" [^60]: @[07:01] "xmlhttp... 객체 생성... 서버에 보내면" [^61]: @[07:10] "사용법이 어려워요... 이 방법으로 사용하는 사람은 없습니다" [^62]: @[07:18]~@[07:27] "제이쿼리... 악시오스... 패치" [^63]: @[07:27] "상황에 맞게... 골랐으면" [^64]: @[07:36]~@[07:48] "리액트 뷰 스벨트... 악시오스 패치" [^65]: @[07:48]~@[07:56] "서버 템플릿 엔진... 옛날 방식... 제이커리... 한방 해결" [^66]: @[08:06] "기존 방식과 에이스 방식 비교" [^67]: @[08:16]~@[08:28] "기존 방식... 페이지 전체 리로딩... 로그인... 링크" [^68]: @[08:28]~@[08:40] "에이스 방식... 좋아요... 페이지 전체 리로딩이면 낭비" [^69]: @[08:40]~@[08:45] "버튼과 숫자만 업데이트" [^70]: @[09:05] "자바스크립트를 더 쉽게... 라이브러리" [^71]: @[09:10] "2006년도에 등장" [^72]: @[09:15]~@[09:23] "제이커리 없으면... 혁명" [^73]: @[09:28]~@[09:33] "프론트엔드 개발자라는 말도 없었습니다" [^74]: @[09:33]~@[09:41] "백엔드 개발자가 다... 웹 퍼블리셔" [^75]: @[09:41]~@[09:50] "채용 공고... 제이커리 요구" [^76]: @[09:55] "자바스크립트 문법을 모르는 사람들도" [^77]: @[10:04] "첫째 돔을 쉽게 조작" [^78]: @[10:08] "코드가 훨씬 짧" [^79]: @[10:13] "둘째... 애니메이션 함수" [^80]: @[10:17] "하이드 쇼" [^81]: @[10:22] "셋째... (AJAX) 쉽게" [^82]: @[10:26]~@[10:33] "기존... 제이커리 방식... 훨씬 짧고 깔끔" [^83]: @[10:39] "마지막... 크로스 브라우징" [^84]: @[10:45] "하나의 코드로 모든 브라우저" [^85]: @[10:50] "브라우저마다 맞추려면 개고생" [^86]: @[10:56]~@[11:01] "제이 커리... 호환성... 결정적인 이유" [^87]: @[11:07] "당시에는 정말... 끝판왕" [^88]: @[11:19]~@[11:24] "부제로... 모바일 앱스게" [^89]: @[11:24] "2010년부터 모던... 등장" [^90]: @[11:30] "모던... spa 가능하게 만들어 주는 도구" [^91]: @[11:35] "2010년에 앵귤러" [^92]: @[11:41] "앵귤러... 구글" [^93]: @[11:47]~@[11:52] "리액트" [^94]: @[11:52] "페이스북... 오픈소스" [^95]: @[11:58] "뷰" [^96]: @[12:04]~@[12:13] "에반 유... 앵귤러 개선" [^97]: @[12:13] "스벨트" [^98]: @[12:16] "뉴욕타임스... 리치..." [^99]: @[12:20]~@[12:24] "네이버 웹툰... 움짤... 이게 spa" [^100]: @[12:28]~@[12:33] "새로 고침 되지 않고... 스무스" [^101]: @[12:33] "트렌드" [^102]: @[12:37]~@[12:45] "spa npa 비교... npa 멀티페이지" [^103]: @[12:49]~@[12:54] "spa... 페이지가 하나... 내부 요소를 바꿔" [^104]: @[13:01]~@[13:13] "리액트 프로젝트... 인덱스 html... 하나" [^105]: @[13:13]~@[13:20] "아무 내용이 없는 빈 파일" [^106]: @[13:20]~@[13:26] "자바스크립트 코드가... 삽입... 클라이언트 측 렌더링" [^107]: @[13:26]~@[13:33] "csr 방식... 클라이언트 사이드 렌더링" [^108]: @[13:33]~@[13:39] "정리 차원... 반복" [^109]: @[13:39]~@[13:51] "html 아무 내용도 없기 때문에... 자바스크립트가 화면" [^110]: @[13:51]~@[13:57] "스텝 2부터... 데이터만... 리로딩 없이 업데이트" [^111]: @[14:11] "프레임웍이 정한 규칙" [^112]: @[14:15]~@[14:20] "겟 엘리먼트... 돔 조작... 아니라는" [^113]: @[14:20]~@[14:24] "규칙을 따로 공부" [^114]: @[14:24]~@[14:29] "로마에 가면 로마법" [^115]: @[14:29]~@[14:33] "러닝 커브... 결국... 훨씬 쉽습니다" [^116]: @[14:33]~@[14:37] "생 자바스크립트로 spa... 유지보수 힘들어" [^117]: @[14:49] "프론트엔드와 백엔드의 경계... 허물어진다" [^118]: @[15:07]~@[15:16] "웹사이트... 최대한 많은 사람들이 봐야" [^119]: @[15:16]~@[15:21] "크롤러로... 수많은 웹사이트" [^120]: @[15:21]~@[15:25] "점수를 매기고 등수" [^121]: @[15:25]~@[15:30] "좋은 컨텐츠... 높은 점" [^122]: @[15:30]~@[15:35] "특정 키워드... 상위 노출" [^123]: @[15:35]~@[15:39] "검색 엔진 최적화 작업" [^124]: @[15:39]~@[15:44] "csr 다시 생각" [^125]: @[15:44]~@[15:56] "구글... 크롤러는 서버만 돌아다니" [^126]: @[15:56]~@[16:00] "서버에서 갖고 있는 페이지는 하나" [^127]: @[16:00] "아무 내용도 없는 빈 html 파일" [^128]: @[16:00]~@[16:04] "아무 내용 없는 사이트로 취급... 노출" [^129]: @[16:04]~@[16:07] "엄청난 문제" [^130]: @[16:07] "그럼 해결책은 뭘까요" [^131]: @[16:14]~@[16:19] "SSR 방식을 함께 사용" [^132]: @[16:19]~@[16:24] "일반적으로... 방식" [^133]: @[16:24]~@[16:30] "서버에서 완성된 html 받아와서" [^134]: @[16:30] "페이지 전체... 새로 고침" [^135]: @[16:37] "2016년부터 메타 프레임웍... csr ssr 가능" [^136]: @[16:42]~@[16:47] "넥스트 JS... 리액트 기반" [^137]: @[16:47]~@[16:54] "너스트 JS... 뷰 기반" [^138]: @[16:54]~@[16:59] "스벨트 킷... 스벨트 기반" [^139]: @[16:59] "인기가 급상승" [^140]: @[17:03] "자바스크립트 언어만으로 풀 스택... 생산성" [^141]: @[17:10]~@[17:17] "쇼케이스... 유명한 사이트" [^142]: @[17:17]~@[17:21] "트렌드 지속... 대세" [^143]: @[17:21]~@[17:24] "하나의 프로젝트... 프론트 엔드와 백엔드... 경계가 허물어질" [^144]: @[17:24]~@[17:38] "준비한 내용... 구독 좋아요 댓글... 끝" [^145]: @[00:46]~@[17:24] 전체 전개(도구의 등장 이유→DOM/AJAX/jQuery/SPA/메타프레임워크) [^146]: @[02:24]~@[17:24] 용어들이 정의/설명되는 구간 전반 [^147]: 사용자가 제공한 메타데이터(제목/채널/길이/키워드/링크) + 영상 링크 정보

← 프로젝트에서 보기