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

description: |

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

[? 질문] ‘모던’ 웹개발자가 되려면 예전(HTML/CSS/JS만)과 비교해 무엇을 추가로 배우고 왜 배워야 하는가^2
[= 답] 요즘 웹 개발은 라이브러리 설치/관리(npm), 결과물을 최적화해 배포하는 번들링/빌드, 개발 방식 자체를 바꾸는 SPA 프레임워크(React/Vue 등), 그에 따른 상태 관리, SEO/초기 로딩 문제를 해결하는 SSR, 타입 안전성을 위한 TypeScript, 서버를 직접 만들거나 대체하는 Node.js/백엔드·BaaS까지가 한 흐름으로 묶여 돌아가므로, “왜 있는지/왜 하는지”를 이해하고 도입할 줄 알아야 한다.[^3]

[? 질문] 라이브러리를 많이 쓰는 요즘 방식은 왜 생겼고, 장단점은 무엇인가[^4]
[= 답] 과거엔 자바스크립트 기본 문법/환경이 불편해 외부 라이브러리를 많이 설치했는데, 지금은 오히려 더 심해졌지만 npm과 번들링 툴 덕분에 설치·관리와 용량 최적화가 쉬워져 “많이 쓰는 것 자체”가 가능해졌다.[^5] 다만 SPA 중심 개발은 SEO 노출이 어렵고 JS 번들 사이즈 증가로 초기 로딩이 느려질 수 있어, 필요하면 SSR로 되돌아가는 흐름이 함께 생겼다.[^6]

[? 질문] 프론트엔드만 하던 사람도 왜/어떻게 백엔드까지 범위가 확장되는가[^7]
[= 답] Node.js로 브라우저 밖에서도 자바스크립트를 실행해 간단한 서버를 만들 수 있고, SSR까지 같은 언어로 처리 가능해지면서 프론트엔드 개발자가 비교적 쉽게 풀스택 영역으로 확장할 수 있게 되었다.[^8]

2. 큰 그림[^9]

이 콘텐츠는 “요즘 웹 개발 현장이 예전과 어떻게 달라졌는지”를 출발점으로, 프론트엔드 입문자가 현업에서 마주치는 도구/개념(패키지 관리, 번들링, SPA, SSR, 타입스크립트, 서버 대체 서비스 등)이 왜 존재하는지를 빠르게 연결해 설명한다.[^10] 단순히 기술 목록을 나열하기보다, “문제(불편/복잡/성능/SEO/타입 버그) → 해결책(도구/패턴/프레임워크)”의 맥락으로 모던 프론트엔드 생태계를 훑는다.[^11]

• HTML/CSS/JS만으로도 웹은 만들 수 있지만, 실제 현업은 라이브러리·툴체인·프레임워크를 전제로 굴러간다.[^12]
• npm + 번들링/빌드는 라이브러리 과다 사용을 가능하게 만든 기반(설치·관리·최적화·변환)이다.[^13]
• SPA의 편리함(동적 UI, 앱 같은 UX)에는 상태 관리/SEO/번들 크기라는 대가가 따르고, 이를 보완하려고 SSR/Node/TypeScript/BaaS 같은 선택지가 등장한다.[^14]

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

3.1 프론트엔드 입문자가 많아진 현상과 “재밌는 것부터 시작”의 이유[^16]

화자는 요즘 프론트엔드로 개발 입문하는 사람이 많아졌다고 말하며, 이것을 “아주 좋은 현상”으로 평가한다.[^17] 이어서 개발을 처음 시작할 때는 “재밌는 것부터 시작해야 흥미를 붙인다”는 관점을 제시한다.[^18] 즉, 입문자의 동기·흥미를 유지하는 방식 자체를 긍정하면서도, 곧바로 “요즘 웹 개발 현장은 예전과 많이 달라졌다”는 전제를 깔고 ‘모던 개발’에서 마주칠 것들을 설명하겠다고 방향을 잡는다.[^19]

• 여기서의 메시지는 “입문 장벽을 낮추는 출발(재미)”과 “현업 현실(도구/기술 스택 복잡화)”을 함께 인식하라는 것이다.[^18]
• 화자는 이후 내용에서 “이것들(여러 도구/개념)이 왜 있는지, 왜 하는지 빠르게 알아보고 지나가자”고 예고한다.[^20]

3.2 (과거 관점) HTML/CSS/JS만 알면 웹사이트는 만들 수 있다[^21]

화자는 가장 전통적인 웹 제작 방식을 먼저 상기시킨다.[^21]

• 웹페이지에 글/그림을 넣고 싶으면 HTML 파일을 만든다.[^22]
• 디자인을 넣고 싶으면 CSS 파일을 만든다.[^23]
• 기능을 넣고 싶으면 자바스크립트(JS) 파일을 만들어 코드를 짠다.[^24]

그리고 “이 정도만 알면 모든 웹사이트 다 만들 수 있다”고 말한다.[^25] 즉, **기술적으로는 최소 셋(HTML/CSS/JS)**만으로도 구현 가능하다는 점을 명확히 한다.[^25] 다만 여기서 끝내지 않고, “그런데 왜 요즘은 이것저것 마구 쓰느냐”로 논지를 확장한다.[^20]

3.3 라이브러리의 의미와 ‘예전보다 더 심해진’ 라이브러리 의존[^26]

화자는 라이브러리를 “코딩 편하게 하려고 남들이 만들어 놓은 코드들”이라고 정의한다.[^27] 이어서 과거(약 10년 전)를 회상하며, 당시에는 자바스크립트 기본 문법 자체가 불편(화자는 강한 표현으로 비판)해서 “수많은 외부 라이브러리를 설치”하며 웹 개발을 진행했다고 말한다.[^28]

중요한 포인트는 “10년이 지난 지금은 더 심해졌다”는 진단이다.[^29] 즉, 라이브러리/도구 체인이 줄어든 게 아니라 오히려 더 늘었다는 것.[^29]
다만 화자는 이것을 단순히 나쁘다고 결론내리지 않는다. “하지만 나쁜 건 아니”라고 선을 긋고, 왜 괜찮아졌는지(혹은 가능해졌는지)를 다음 도구들로 설명한다.[^30]

3.4 npm(패키지 매니저): 라이브러리 설치/수정/삭제를 ‘쉽게’ 만드는 기반[^31]

화자는 npm을 소개한다.[^31]

• npm은 라이브러리 설치·수정·삭제를 쉽게 해주는 프로그램이라고 말한다.[^32]
• npm을 “패키지 매니저”라고 부르며, 자바스크립트 라이브러리 설치/수정/삭제를 “매우 쉽게 도와준다”고 강조한다.[^33]

3.4.1 npm을 쓰는 방법(터미널 명령 중심 설명)[^34]

npm 사용 방식은 “코드 짜던 폴더에 터미널 열고” 명령어를 입력하는 흐름으로 설명된다.[^35]

• 설치: npm install 라이브러리이름 형태로 입력하면 설치 가능하다고 말한다.[^35]
• 업데이트/삭제도 특정 명령어를 입력하면 된다고 하며, 세부 명령을 화면 예시처럼 처리 가능하다고 언급한다.[^36]

[!TIP] npm을 배우는 핵심 포인트[^33] npm은 “라이브러리를 어떻게 ‘가져다 쓰는가’”의 출발점이며, 모던 프론트 개발에서 외부 코드 의존이 커진 상황을 운영 가능하게 만든 최소 도구로 제시된다.[^33]

3.4.2 npm을 쓰려면 Node.js 설치가 필요(같이 딸려옴)[^37]

화자는 “npm을 쓰고 싶으면 Node.js 설치하면 딸려온다”고 말해, npm이 독립 도구라기보다 Node 생태계의 일부로 자연스럽게 따라오는 것임을 알려준다.[^38]

3.5 Node.js: 브라우저 밖에서 JS를 실행시키는 엔진 + npm의 기반[^39]

화자는 자바스크립트의 원래 실행 환경을 “웹브라우저 안에서만 실행”이라고 전제한다.[^40] 그리고 “브라우저 안 켜고도 PC 아무데서나 자바스크립트 파일을 실행할 수 있게 도와주는 자바스크립트 파일 실행 엔진”이 Node.js라고 설명한다.[^41]

• 설치는 구글 검색으로 가능하다고 말한다.[^42]
• 설치 후에는 터미널에서 명령을 통해 JS 파일을 바로 실행할 수 있다고 언급한다.[^43]

3.5.1 node_modules 폴더와 라이브러리 사용의 현실적 문제(구조 복잡화)[^44]

npm으로 설치한 라이브러리는 node_modules 폴더에 추가된다고 한다.[^45] 그리고 그 안의 라이브러리를 “대충 갖다 쓰고 싶으면” 코드에서 import/require 같은 방식으로 가져다 쓰면 된다는 식으로 설명한다.[^46]

다만 “다른 파일들을 이렇게 갖다 쓰면 파일 구조가 복잡해질 수도” 있다고 지적한다.[^47] 즉,

• 의존성이 늘수록 파일 참조 관계가 복잡해지고,[^47]
• 결과물을 배포하기에도 정리가 필요해진다는 문제의식을 다음 주제(번들링)로 연결한다.[^48]

3.6 번들링 툴: 여러 파일/의존성을 한 파일로 합치고, 용량·호환성·변환까지 처리[^49]

화자는 번들링 툴을 사용하면 “지금 필요한 자바스크립트 파일들을 전부 다 가져와서 하나의 파일로 깔끔하게 합쳐줄 수 있다”고 말한다.[^50] 이는 복잡한 파일 구조/의존성을 배포 가능한 형태로 재구성하는 과정으로 제시된다.[^50]

3.6.1 번들링의 1차 효익: 배포가 쉬워진다[^51]

파일이 하나로 합쳐지면 “나중에 배포 같은 게 쉬워”진다고 말한다.[^52] 즉, 서버에 올릴 산출물이 정리되어 전달되기 때문이다.[^52]

3.6.2 번들링의 추가 장점들(최적화/변환/호환성)[^53]

화자는 번들링 툴의 장점을 여러 갈래로 설명한다.[^54]

• 트리 쉐이킹/최적화: “내가 쓰는 코드만 딱 추려서 합쳐”주기 때문에 “전체 파일 용량”을 줄여준다고 말한다.[^55]
• 확장자/문법 변환: .js가 아니라 .ts, .vue, .jsx 같은 “이상한 파일 형식”으로 개발한 것도 .js로 “잘 변환”해준다고 한다.[^56]
• 구문 트랜스파일(호환성): “최신 자바스크립트 문법을 호환성 좋은 옛날 문법으로 변환”해주는 기능도 있다고 언급한다.[^57]

이로써 번들링 툴은 단순 합치기가 아니라,

• 개발 중에는 다양한 문법/파일 포맷을 쓰게 해주고,[^56]
• 배포 시점에는 브라우저가 이해할 형태로 바꿔주며,[^57]
• 필요 없는 코드 제거로 성능/용량까지 잡는 도구로 그려진다.[^55]

3.6.3 “요즘 건 쉬우니 따로 공부할 필요는 없다”는 접근[^58]

화자는 최근 번들링 툴은 사용법이 쉬워서 “따로 공부하고 그럴 필요는 없다”고 말한다.[^59] 즉, 원리를 깊게 파기보다도 세팅된 도구를 실행하며 익숙해지는 것을 권한다.[^59]

3.7 예시: Vite(영상 발음상 “빛”)로 프로젝트 세팅/미리보기[^60]

화자는 “가장 쉬운” 번들링 툴 예시로 Vite를 들어 시연 흐름을 말로 안내한다.[^61]

• “세팅 완료된 프로젝트를 만들고 싶다”면 터미널에 안내된 명령을 입력한다.[^62]
• 이어서 기본 세팅에서 어떤 라이브러리를 선택할지 고르는 화면이 나오는데, “싫으면 바닐라(= 바닐라 JS)”를 선택하면 된다고 말한다.[^63]
• 이후 출력되는 명령어들을 차례로 입력하면 “세팅 끝”이라고 설명한다.[^64]
• “실시간 미리보기”를 띄우려면 설치된 폴더에서 터미널을 열고 안내된 명령을 입력하면 된다고 한다.[^65]

+++ 상세 예시(영상의 의도대로 재구성) 화자의 흐름은 “복잡한 설정을 직접 만들지 말고, Vite 같은 도구로 프로젝트 골격을 자동 생성한 다음, 터미널 명령 몇 개로 개발 서버를 켜서 즉시 미리보기까지 연결하라”는 것이다.[^61] 즉 “번들러를 공부”하기보다 “번들러가 제공하는 표준 워크플로우를 사용”하는 쪽에 방점이 찍혀 있다.[^59] +++

3.8 빌드(build): 번들링 툴로 합치고 배포 폴더를 만드는 단계[^66]

개발이 끝나고 라이브러리를 이것저것 설치한 뒤, “파일들을 하나로 합치고 싶다”고 할 때 번들링 툴을 이용한다고 다시 정리한다.[^67]

• 작업 폴더에서 터미널을 열고 npm run build를 입력하라고 안내한다.[^68]
• 이 과정을 “빌드 작업”이라고 부른다고 명명한다.[^69]
• 빌드를 하면 폴더가 하나 생성되는데, 그 안에 “자바스크립트 파일을 하나로 합쳐”주는 결과물이 담긴다고 설명한다.[^70]
• 이제 그 폴더 안의 내용물을 “서버에 올리면 개발 끝”이라고 말해, 빌드 산출물이 곧 배포 단위임을 강조한다.[^71]

[!IMPORTANT] 개발과 배포의 경계로서의 빌드[^69] 개발 중에는 여러 파일/형식/최신 문법을 쓰지만, 배포 직전에는 build로 “합쳐진 결과물 폴더”를 만들고 그걸 서버에 업로드하는 흐름이 모던 프론트의 기본 작업 단위로 제시된다.[^71]

3.9 React/Vue 등 SPA 라이브러리: HTML 조작을 쉽게 하고 “새로고침 없는” 웹앱을 만든다[^72]

화자는 “요즘 많이 쓰는 자바스크립트 라이브러리”를 언급하며, 이런 것들을 쓰면 HTML 수정/생성/삭제를 편하게 해준다고 말한다.[^73]

이어서 이 라이브러리들이 가능하게 하는 대표 결과물로 **싱글 페이지 애플리케이션(SPA)**을 든다.[^74]

• SPA는 “모바일 앱처럼 새로고침 없이 부드럽게 동작하는 사이트”라고 설명된다.[^74]
• 그런 걸 만들고 싶으면 이런 라이브러리를 사용하면 된다고 결론낸다.[^75]

3.9.1 왜 SPA 라이브러리가 유용한가: JS로 HTML을 동적으로 생성/변경[^76]

화자는 이유를 명시한다: 이런 라이브러리를 쓰면 자바스크립트로 웹페이지의 HTML을 “동적으로 생성하고 변경”하는 것이 쉬워지기 때문이라고 말한다.[^77]

또한 이 행위를 용어로 부르며,

• “HTML 생성과 조작을 자바스크립트로 하는 것”을 **클라이언트 사이드 렌더링(CSR)**이라고 설명한다.[^78]

3.10 SPA의 1차 단점: 프론트엔드에서 ‘데이터(변수)’ 관리가 어렵다 → 상태 관리(state management)[^79]

화자는 “SPA 라이브러리들의 단점”을 이야기한다.[^80]

• 이런 라이브러리를 사용할 때 “자바스크립트 변수 문법”으로 데이터를 저장한다고 말한다.[^81]
• 그런데 프론트엔드에는 “데이터베이스 같은 것들이 없”다고 단언한다.[^82]
• 그 결과 “수많은 변수들 관리하는 게 어렵다”고 문제를 정의한다.[^83]

그리고 이 문제를 다루는 행위를 용어로 붙인다:

• 변수들을 관리하는 행위를 **스테이트 매니지먼트(state management)**라고 한다.[^84]
• 이를 쉽게 도와주는 외부 라이브러리를 설치해 해결하는 경우가 많다고 설명한다.[^85]

[!NOTE] 여기서 말하는 ‘상태’의 뉘앙스[^84] 화자는 엄밀한 정의 대신 “프론트에는 DB가 없고, 앱이 커지면 변수(데이터)가 많아져서 관리가 어려워진다 → 그래서 상태 관리가 필요하고 라이브러리를 붙인다”는 실무적 맥락으로 설명한다.[^83]

3.11 SPA의 더 심각한 단점: SEO 노출 어려움 + 초기 로딩 저하(번들 크기)[^86]

화자는 “더 심각한 단점”이 있다고 하며 두 가지를 든다.[^87]

1. “웹페이지를 구글 검색 결과에 노출시키는 게 매우 어렵”다고 말한다.[^88]
2. “자바스크립트 파일 사이즈가 너무 커져” 초기 로딩 속도가 저하된다고 말한다.[^89]

즉, SPA/CSR은 개발 경험과 UX(부드러움)를 주는 대신,

• 검색엔진 최적화(SEO)에서 불리해질 수 있고,[^88]
• JS 번들이 커질수록 첫 화면이 뜨는 시간이 늘 수 있다는 트레이드오프를 제시한다.[^89]

3.12 해결책: 서버사이드 렌더링(SSR) — HTML을 서버에서 만들어 보내기[^90]

화자는 위 문제가 싫다면 **서버사이드 렌더링(SSR)**을 하라고 제안한다.[^91]

• CSR처럼 “프론트엔드 자바스크립트 코드로 HTML을 만드는” 게 아니라,[^92]
• “서버에서 생성해서 보내주면” 된다고 설명한다.[^93]

이어서 “실은 옛날에 항상 하던 것”이라고 말하며, SSR이 새로운 발명이 아니라 전통적인 방식임을 강조한다.[^94] 다만 “이런 옛날 방법들이 좋은 것 같다고 다시 한번 유행”한다고 덧붙여, SPA 유행 이후의 반작용/재평가 흐름을 이야기한다.[^95]

3.12.1 React 비슷한 문법으로 SSR을 하고 싶다면: 관련 라이브러리(프레임워크)를 설치[^96]

화자는 “리액트 비슷한 문법을 써서 SSR을 하고 싶다”면, 그런 용도의 라이브러리(프레임워크)를 설치해서 쓰라고 안내한다.[^97] (영상 맥락상 Next.js 같은 SSR 프레임워크를 염두에 둔 설명으로 읽히지만, 화자는 구체 이름을 “이런 라이브러리들”로 처리한다.)[^97]

3.13 Node 기반 확장: JS 문법 하나로 서버/SSR까지 → 풀스택 가능성[^98]

화자는 “자바스크립트 문법 하나만으로 간단한 서버까지 만들 수도” 있다고 말한다.[^99] 또한 SSR도 할 수 있어, 프론트엔드만 하던 사람도 “쉽게 백엔드까지”, 즉 풀스택 개발이 가능하게 만들어주는 라이브러리가 있다고 설명한다.[^100]

여기서의 연결 고리는:

• Node로 서버를 만들 수 있고,[^99]
• SSR 프레임워크로 서버 렌더링도 하며,[^100]
• 결과적으로 프론트/백 경계가 낮아진다는 점이다.[^100]

3.14 TypeScript: 타입 강제가 없는 JS의 버그를 줄이기 위한 선택[^101]

화자는 자바스크립트의 언어적 특성으로 “원래 타입 강제하는 기능이 없”다고 말한다.[^102] 그 결과 “나중에 타입이 틀려서 발생하는 버그”가 생길 수 있다고 문제를 제기한다.[^103]

이를 방지하고 싶으면 TypeScript를 사용한다고 소개한다.[^104]

• .ts 파일을 만들어 TypeScript 문법으로 코드를 짠다고 말한다.[^105]
• 문법은 JS와 “똑같은데” 변수나 함수에 타입을 집어넣을 수 있다고 설명한다.[^106]
• 다만 .ts 파일은 브라우저가 해석할 수 없어서 번들링 툴로 .js로 변환해야 한다고 말한다.[^107]

[!TIP] 타입스크립트 도입의 실무적 포인트[^103] “타입이 틀려서 생기는 버그”를 줄이고 싶다면 TS를 고려하고, TS를 쓰는 순간 빌드/번들링 과정에서 JS로 변환하는 파이프라인이 자연스럽게 필요해진다는 연결이 제시된다.[^107]

3.15 완전한 웹서비스를 위해 필요한 것: 서버/DB, 그리고 ‘서버를 대신 만들어주는 서비스(BaaS)’[^108]

화자는 “완전한 웹 서비스 하나”를 만들려면 프론트엔드 코드만으로는 안 되고, 서버와 데이터베이스까지 있어야 “웹서비스 같은 걸로” 된다고 말한다.[^109]

그리고 만약 “서버를 만들 줄 모르면” 서버를 대신 만들어주는 서비스 같은 것을 쓰라고 제안한다.[^110]

• 이런 서비스들이 “유명”하다고 언급한다.[^111]
• 이런 것을 쓰면 “회원 인증”, “서버 기능”, “DB 저장” 같은 것들을 “대충 서버 없이도 구현”할 수 있다고 말한다.[^112]
• 다만 “몇 가지 단점들도” 있다고 짧게 경고하지만, 구체 단점은 영상에서 상세히 열거하지는 않는다.[^113]

3.16 결론: 프론트엔드 수요/보상 증가와 ‘이상한 라이브러리’ 도입의 의미(전문성/밥그릇)[^114]

화자는 최근 “리액트 같은 이상하고 어려운 라이브러리”를 쓰기 시작하면서 프론트엔드 개발자들이 많이 필요해지기 시작했다고 말한다.[^115] 그리고 실제로 “돈을 잘 벌기 시작”했다고 덧붙인다.[^116]

이어서 시청자에게 행동을 권한다:

• 앞으로 “이상한 라이브러리나 신기술”을 많이 도입하면 프론트엔드 개발자라는 전문성과 밥그릇을 지킬 수 있으니 그렇게 하라고 말한다.[^117]

마지막으로, 이런 라이브러리들이 유행하는 것을 보면 “나중 가면 프론트랑 백엔드랑 별 구분이 없어질 것 같”다고 전망하며 마무리한다.[^118]

4. 핵심 통찰[^119]

1. 라이브러리 사용이 늘어난 것은 단순 유행이라기보다, npm/번들링/빌드 같은 기반 도구가 “많이 써도 굴러가게” 만들었기 때문이다.[^5]
2. SPA/CSR은 UI 개발을 강력하게 만들지만, 상태 관리 복잡도와 SEO/초기 로딩 문제를 동반한다는 트레이드오프가 핵심이다.[^83]
3. SSR은 ‘새로운 기술’이라기보다 전통적 방식을 재도입하는 흐름이며, SPA의 약점을 보완하는 선택지로 재유행한다.[^94]
4. TypeScript는 “JS의 타입 부재로 생기는 버그”를 줄이기 위한 실용적 도구로 제시되며, 도입 시 번들링/트랜스파일 파이프라인이 필수로 따라온다.[^107]
5. Node/SSR/BaaS의 존재는 프론트엔드 개발자가 백엔드 영역으로 확장하기 쉬운 환경을 만들고, 결과적으로 프론트/백의 경계가 약해질 수 있다는 전망으로 이어진다.[^118]

• 실행 시사점(콘텐츠의 권고 흐름을 행동으로 번역)
  • npm 설치/삭제/업데이트 기본 명령을 익혀 의존성 관리를 “할 줄 아는 상태”를 만든다.[^35]
  • Vite 등으로 프로젝트 생성 → 개발 서버 → npm run build로 배포 산출물 생성 흐름을 최소 1회 끝까지 해본다.[^68]
  • SPA를 만든다면 상태 관리가 왜 필요해지는지(변수/데이터 폭증 관점)를 먼저 체감하고 도입을 검토한다.[^83]
  • SEO/초기 로딩이 중요하면 CSR만 고집하지 말고 SSR 프레임워크를 고려한다.[^91]
  • 타입 버그가 부담이라면 TS를 도입하고, 번들러로 JS 변환하는 전제를 세팅한다.[^107]

5. 헷갈리는 용어 정리 (해당 시에만)[^120]

라이브러리: 코딩을 편하게 하려고 남들이 만들어 둔 코드(묶음)로 설명된다.[^27]
npm: 자바스크립트 라이브러리 설치/수정/삭제를 쉽게 해주는 패키지 매니저.[^33]
Node.js: 브라우저 없이도 PC 어디서나 자바스크립트 파일을 실행하게 해주는 실행 엔진(환경)로 설명된다.[^41]
node_modules: npm으로 설치한 라이브러리들이 들어가는 폴더로 언급된다.[^45]
번들링 툴: 여러 JS/의존 파일을 모아 하나로 합치고, 용량 최적화/파일 형식 변환/최신 문법 호환 변환까지 해주는 도구.[^55]
빌드(build): 번들링 툴로 파일을 합치고 배포용 결과물(폴더)을 생성하는 작업으로 설명된다.[^69]
SPA(싱글 페이지 애플리케이션): 새로고침 없이 모바일 앱처럼 부드럽게 동작하는 사이트 형태.[^74]
CSR(클라이언트 사이드 렌더링): 자바스크립트로 HTML을 생성·조작하는 행위를 지칭.[^78]
상태 관리(State management): 프론트엔드에서 수많은 변수(데이터)를 관리하는 행위로 설명된다.[^84]
SSR(서버사이드 렌더링): HTML을 프론트 JS로 만들지 않고 서버에서 생성해 보내는 방식.[^93]
TypeScript: JS와 문법은 비슷하지만 변수/함수에 타입을 지정할 수 있고, 브라우저가 직접 해석 못해 JS로 변환이 필요한 언어.[^106]
BaaS(서버를 대신 만들어주는 서비스): 서버/DB를 직접 만들지 못할 때 회원인증/DB저장 등을 서버 없이도 구현하게 해주는 서비스로 설명된다.[^112]

---

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

• 제목: 모던 웹개발자 하려면 배울 것들[^121]
• 채널: 코딩애플[^121]
• 길이: 6분 32초[^121]
• 링크: https://www.youtube.com/watch?v=ZM55pce2AkY[^121]

[^3]: @[00:45] npm 설치/관리, @[02:03] 번들링, @[03:36] SPA, @[04:46] SSR, @[05:19] TS, @[05:48] 서버/DB 필요 [^4]: @[00:28] 라이브러리 정의 및 과거 맥락, @[04:35] SPA 단점 언급 [^5]: @[00:45] "mpm ... 라이브러리 설치 수정 삭제", @[00:52] 번들링으로 안 쓰는 코드 삭제/용량 절감 [^6]: @[04:35] "검색 결과 노출... 어렵", @[04:40] "자바스크립트 파일 사이즈... 초기 로딩 속도 저하", @[04:46] "서버사이드 렌더링" [^7]: @[05:03] "자바스크립트 문법 하나만으로 간단한 서버", @[06:28] "프론트랑 백엔드랑... 구분이 없어질" [^8]: @[01:28] Node.js 정의, @[05:08] SSR도 가능 → 풀스택 [^9]: @[00:06] "현장은 ... 달라졌습니다" [^10]: @[00:11] "왜 있는 건지 왜 하는 건지" [^11]: @[04:08] 단점 → @[04:46] SSR 제안의 문제-해결 흐름 [^12]: @[00:19]~@[00:25] HTML/CSS/JS로 끝 [^13]: @[00:45] npm, @[02:14] 용량 줄임/변환 [^14]: @[03:36] SPA, @[04:18] 상태관리, @[04:35] SEO/로딩, @[04:46] SSR [^15]: @[00:11] "빠르게 알아보고" [^16]: @[00:00]~@[00:06] 입문/흥미 [^17]: @[00:00] "아주 좋은 현상" [^18]: @[00:06] "재밌는 거부터 시작" [^19]: @[00:06] "현장은 ... 달라졌습니다" [^20]: @[00:11] "왜 있는 건지 왜 하는 건지" [^21]: @[00:19] 웹페이지 구성 설명 시작 [^22]: @[00:19] "글... 그림 넣고 싶으면 html" [^23]: @[00:22] "디자인 넣고 싶다 그러면 css" [^24]: @[00:24] "기능 ... 자바스크립트" [^25]: @[00:25] "정도만 알면 모든 웹사이트" [^26]: @[00:28] 라이브러리 설명 시작 [^27]: @[00:28] "라이브러리는 ... 남들이 만들어 놓은 코드" [^28]: @[00:28] "10년 전엔 ... 수많은 외부 라이브러리" [^29]: @[00:34] "지금은 더 심해졌어요" [^30]: @[00:39] "하지만 나쁜 건 아니고요" [^31]: @[00:45] npm 소개 [^32]: @[00:45] "라이브러리 설치 수정 삭제" [^33]: @[01:04]~@[01:07] "패키지 매니저... 매우 쉽게" [^34]: @[01:11] 사용법 설명 [^35]: @[01:11] "npm install ... 라이브러리 이름" [^36]: @[01:15] "업데이트... 삭제... 명령어" [^37]: @[01:21]~@[01:22] Node 설치하면 npm 포함 [^38]: @[01:22] "노드 js 설치하면 딸려옵니다" [^39]: @[01:28] Node.js 정의 [^40]: @[01:28] "브라우저 안에서만 실행" [^41]: @[01:28] "브라우저 안 켜고도... 실행 엔진이 노드 js" [^42]: @[01:34] "검색하시면 설치" [^43]: @[01:40] "터미널에서 ... 실행" [^44]: @[01:47] node_modules 언급 [^45]: @[01:47] "노드 모듈러스라는 폴더" [^46]: @[01:47] "대충 갖다 쓰면" [^47]: @[01:54] "파일 구조 ... 복잡" [^48]: @[02:03] 번들링 툴로 해결 연결 [^49]: @[02:03] 번들링 툴 소개 [^50]: @[02:03]~@[02:06] "전부 다 가져와서 하나로" [^51]: @[02:10] 배포 쉬움 [^52]: @[02:10] "배포 ... 쉬워지겠죠" [^53]: @[02:14] 장점들 [^54]: @[02:14] "장점들이 있는데" [^55]: @[02:14]~@[02:19] "내가 쓰는 코드만... 용량 줄여" [^56]: @[02:19]~@[02:25] ".ts .vue .jsx ... js로 변환" [^57]: @[02:25]~@[02:33] "최신 문법... 옛날 문법으로 변환" [^58]: @[02:37] 사용법 쉬움 [^59]: @[02:41] "따로 공부... 필요는 없습니다" [^60]: @[02:45] 예시 도입 [^61]: @[02:45] "가장 쉬운 ... 번들링 툴" [^62]: @[02:45]~@[02:48] "프로젝트 ... 터미널에" [^63]: @[02:48]~@[02:52] "싫으면 바닐라" [^64]: @[02:52]~@[02:56] "명령어 ... 세팅 끝" [^65]: @[02:56] "실시간 미리보기 ... 입력" [^66]: @[03:07] 빌드 단계 [^67]: @[03:09]~@[03:11] 번들링 툴 이용 [^68]: @[03:14] "npm run build" [^69]: @[03:18]~@[03:21] "빌드 작업" [^70]: @[03:21]~@[03:24] "폴더가 ... 생성... 하나로 합쳐" [^71]: @[03:27] "서버에다가 올리면... 개발 끝" [^72]: @[03:34] SPA 라이브러리 소개 [^73]: @[03:36] "html 수정 생성 삭제 ... 편하게" [^74]: @[03:36]~@[03:45] "싱글 페이지 ... 새로고침 없이" [^75]: @[03:45] "사용하시면" [^76]: @[03:53] 이유 설명 [^77]: @[03:53] "html을 동적으로 생성... 변경... 쉬워져서" [^78]: @[04:02]~@[04:08] "클라이언트 사이드 렌더링" [^79]: @[04:08] 단점 도입 [^80]: @[04:08] "단점" [^81]: @[04:08]~@[04:18] "변수문법의 데이터를 저장" [^82]: @[04:18] "프론트엔드엔 데이터베이스... 없어요" [^83]: @[04:18]~@[04:21] "변수들 관리... 어렵습니다" [^84]: @[04:21]~@[04:24] "스테이트 매니지먼트" [^85]: @[04:24] "외부 라이브러리... 해결" [^86]: @[04:35] 더 심각한 단점 [^87]: @[04:35] "더 심각한 단점" [^88]: @[04:35]~@[04:40] "구글 검색 결과... 매우 어렵" [^89]: @[04:40] "파일 사이즈... 초기 로딩 속도... 저하" [^90]: @[04:46] SSR 제안 [^91]: @[04:46] "이게 싫다 그러면 ... 서버사이드 렌더링" [^92]: @[04:46]~@[04:52] "프론트... 만드는게 아니라" [^93]: @[04:46]~@[04:52] "서버에서 생성해서 ... 보내" [^94]: @[04:52] "옛날에 항상 하던" [^95]: @[04:52]~@[04:57] "다시 한번 유행" [^96]: @[04:57] SSR 라이브러리 언급 [^97]: @[04:57]~@[05:03] "리액트 비슷한 문법... 설치" [^98]: @[05:03] 풀스택 연결 [^99]: @[05:03] "간단한 서버" [^100]: @[05:08]~@[05:15] "풀스택 개발 ... 가능" [^101]: @[05:19] TS 소개 [^102]: @[05:19] "타입 강제... 없어" [^103]: @[05:19]~@[05:23] "타입이 틀려... 버그" [^104]: @[05:23] "타익스크립트" [^105]: @[05:29] ".ts ... 만들어서" [^106]: @[05:33]~@[05:38] "타입을 ... 집어 넣을 수" [^107]: @[05:38]~@[05:46] "브라우저에서 해석... 못... js로 변환" [^108]: @[05:46] 웹서비스 조건/대체 서비스 [^109]: @[05:46]~@[05:48] "서버 데이터베이스까지" [^110]: @[05:48]~@[05:58] "서버를 만들 줄 모르면 ... 서비스" [^111]: @[06:01] "유명" [^112]: @[06:03]~@[06:05] "회원 인증... DB 저장... 서버 없이도" [^113]: @[06:05]~@[06:10] "단점들도" [^114]: @[06:10] 마무리 메시지 [^115]: @[06:10]~@[06:16] "프론트엔드 개발자들이 많이 필요" [^116]: @[06:16] "돈을 잘 벌기" [^117]: @[06:20]~@[06:23] "전문성과 밥그릇... 지킬 수" [^118]: @[06:23]~@[06:28] "구분이 없어질 것 같" [^119]: @[00:45]~@[06:28] 전반 결론 재구성 [^120]: @[00:28]~@[06:05] 용어들이 직접 언급/정의됨 [^121]: 사용자가 제공한 메타데이터(제목/채널/길이/링크)