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

description: |-

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

[? 질문] 시장에서 경쟁력 있는 **웹 개발자(특히 프론트엔드)**가 되려면 2022년 트렌드 기준으로 무엇부터 어떤 순서로 공부해야 하는가[^1]
[= 답] 5단계 로드맵(기본 툴 → 프론트엔드 핵심 스킬 → 퍼블리시/배포 → 생산성 툴 병행 → 테스팅·자동화) 흐름으로 학습하되, 무엇이든 “전부 외우는 방식”이 아니라 큰 그림을 이해하고 필요할 때 문서/검색으로 찾아 적용하는 능력을 함께 키우는 것이 핵심이다.[^10][^17]

[? 질문] 프론트엔드와 백엔드의 역할 차이는 무엇이며, 풀스택은 무엇을 의미하는가[^4]
[= 답] **백엔드(서버)**는 사용자 정보/데이터/핵심 로직과 DB 저장·조회·처리를 담당하고, **프론트엔드(브라우저/클라이언트)**는 서버에서 받은 데이터를 사용자에게 보여주고 사용자 요청을 서버로 전달한다; 풀스택은 이 둘을 모두 다룬다.[^4][^5]

[? 질문] HTML/CSS/JavaScript는 어디까지, 어떤 관점으로 공부해야 다음 단계(프레임워크/실무)에서 무너지지 않는가[^14]
[= 답] 세 기술을 “지나치게 붙잡고 달달 외우는 것”도, “이해 없이 프레임워크로 건너뛰는 것”도 피해야 하며, **웹 구조(HTML), 표현(CSS), 동작(JS)**의 역할과 맥락을 잡고, JS는 특히 **언어 자체(문법/개념)**와 **브라우저 API(DOM/이벤트/네트워크 등)**를 분리해 탄탄히 다져야 한다.[^14][^19][^23]

---

2. 큰 그림[^2]

이 콘텐츠는 “올해 웹개발을 정말 시작해보려는 사람”을 대상으로, 2022년 트렌드에 맞춰 프론트엔드 개발자 중심의 학습 순서(로드맵)를 단계적으로 제시한다.[^2][^7] 또한 프론트엔드/백엔드의 역할 구분과, 기본기(HTML/CSS/JS)부터 프레임워크·타입스크립트·테스팅·배포·확장 학습(백엔드/웹어셈블리/그래프QL/크로스플랫폼/AI/Web3)까지 어디를 “나침반” 삼아 학습을 이어갈지 안내한다.[^5][^55]

• 프론트엔드 로드맵을 5단계로 구조화해 “뭘 먼저 할지” 혼란을 줄이고, 각 단계에서 무엇을 익히면 되는지 구체 항목으로 정리한다.[^7][^9]
• 기초는 외우는 게 아니라 맥락+검색 능력으로 다지고, 특히 JavaScript는 언어와 브라우저 API를 분리 학습해야 이후 프레임워크/노드/실무로 확장할 때 흔들리지 않는다고 강조한다.[^17][^19][^23]
• 프레임워크/툴/테스팅/배포/추가 확장(백엔드 포함)은 “전부 다”가 아니라 필요에 따라 선택하며, 로드맵은 학습자가 현재 위치를 점검하는 **가이드(나침반)**로 활용하라고 말한다.[^40][^56]

---

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

3.1 오프닝: “경쟁력 있는 웹개발자”가 되려면 무엇을 봐야 하나[^1]

영상은 시작부터 근본 질문을 던진다: “시장(현업)에서 경쟁력 있는 웹개발자가 되려면 어떻게 해야 할까”를 2022년 트렌드 관점에서, 무엇부터 무엇을 중점적으로 공부할지 정리하겠다고 선언한다.[^1][^2]
여기서 ‘경쟁력’은 단순히 기술 목록을 많이 아는 것이 아니라, 현업에서 요구하는 스킬을 현실적으로 갖추는 것(그리고 그 순서)을 의미하는 문제의식으로 전개된다.[^6][^7]

3.2 연봉·수요로 보는 웹개발 시장 맥락[^3]

학습 로드맵을 본격적으로 다루기 전, 웹개발 직군의 보상 수준과 수요 증가 흐름을 제시해 동기 부여와 배경을 깐다.[^3]

• 백엔드 개발자: 글로벌 평균 약 9,500 이상, 미국에서는 약 1억 3천만 원 수준이라고 언급한다.[^3]
• 프론트엔드 개발자: 글로벌 평균 약 1억 원 이상, 미국에서는 약 1억 1천 이상을 언급한다.[^3]
• 풀스택 개발자: 글로벌 약 1억 1 이상, 미국에서는 약 1억 2천 이상 수준으로 평균적으로 높다고 말한다.[^3]
• 또한 시간이 갈수록 웹 개발자 수요가 점점 높아지는 추세라고 설명한다.[^3]

[!NOTE] 수치 제시의 의도
이 파트는 “왜 웹개발을 지금 시작할 가치가 있는가”를 연봉과 수요라는 시장 지표로 빠르게 설득하는 역할을 한다.[^3]

3.3 프론트엔드 vs 백엔드 vs 풀스택: 역할을 먼저 정확히 구분[^4]

로드맵을 시작하기 전 가장 먼저 프론트엔드와 백엔드의 차이를 짚고 넘어간다.[^4]

• **백엔드(서버)**에는 사용자들의 정보 및 다양한 데이터, 그리고 주요 로직이 들어 있다고 설명한다.[^4]
• 프론트엔드는 보통 브라우저(크롬, 사파리 등)를 가리키며, 브라우저를 클라이언트라고 부른다.[^4]
• 프론트엔드와 서버는 인터넷으로 연결되어 있으며, 프론트엔드가 서버에 필요한 데이터를 요청하고 서버로부터 받아 사용자에게 보여준다.[^5]

이어서 직무 정의를 더 구체화한다.[^5]

• 서버에서 DB에 데이터를 저장·읽기, 필요한 로직을 처리하는 개발자를 백엔드 개발자라 한다.[^5]
• 브라우저 위에서 사용자에게 데이터를 보여주고, 사용자 요청을 서버로 전달하는 일을 하는 개발자를 프론트엔드 개발자라고 한다.[^5]
• 이 둘을 넘나들며 모두 할 수 있는 개발자를 풀스택 개발자라고 정의한다.[^5]

결론적으로 영상은 “이번 영상에서는 이 셋 중에서 웹개발에 중요한 기본이 되는 프론트엔드 개발 로드맵을 살펴볼 것”이라고 범위를 확정한다.[^6]

3.4 기존 로드맵은 왜 어려워 보이나: “너무 복잡함”을 정리해주겠다는 약속[^7]

이미 웹에는 로드맵이 많지만, 얼핏 봐도 복잡하고 항목이 많아 보인다고 말한다.[^7]
그래서 사람들이 흔히 갖는 혼란을 그대로 대변한다.[^7]

• [? 질문] “뭐가 제일 중요한데?”[^7]
• [? 질문] “뭐부터 하지?”[^7]
• [? 질문] “어떤 걸 더 공부하면 좋은 거지?”[^7]
• [= 답] 현업에서 테크리더까지 성장하며 체득한 순서 + 현업 프론트엔드가 필수로 갖추는 실용 스킬을 “고르고 골라” 로드맵에 녹였고, 그 로드맵이 도움이 될 것이라고 말한다.[^8]

3.5 프론트엔드 학습 5단계(스텝) 전체 구조 제시[^9]

프론트엔드 개발자가 되기 위한 학습을 “총 5단계”로 제시한다.[^9]

1. Basic Tool: 개발에 필요한 기본 툴이 무엇인지, 어떻게 사용하며 “익숙하게” 쓸 수 있을 정도로 익힌다.[^9]
2. 프론트엔드 핵심 스킬 학습: 프론트엔드 개발에 실질적으로 필요한 스킬을 하나씩 배운다.[^9]
3. Publish(배포): 웹 앱/사이트를 만들었다면 배포해 친구/다른 사람에게 보여줄 수 있어야 하므로, 어디에 어떻게 배포하는지 안다.[^9]
   → 여기까지 3단계를 거치면 “기본적인 프론트엔드 역량”을 갖췄다고 본다.[^9]

이후 “더 진지한 프론트엔드 개발자”가 되려면 추가로 2가지를 더 챙기라고 말한다.[^10]

4. 생산성 툴/다양한 툴 학습: 생산성을 높여주는 여러 툴을 배운다.[^10]
5. Testing + 자동화: 앱이 제대로 동작하는지 테스트 코드를 작성하고, 배포 과정과 묶어 업데이트 때마다 배포 전 자동 테스트가 되도록 자동화를 신경 쓰면 더 뛰어난 개발자가 될 수 있다고 설명한다.[^11]

특히 “프론트엔드를 배우고 툴을 배우기보다, 프론트엔드를 공부하면서 툴을 병행하는 게 좋다”고 학습 방식까지 제안한다.[^10]

[!IMPORTANT] 단계의 의미
단계를 나누는 이유는 ‘기술 나열’이 아니라, 학습자가 실제로 만들고 배포하고 유지·검증까지 경험하도록 설계하려는 의도다.[^9][^11]

3.6 1단계 Basic Tool: 운영체제, 에디터, 브라우저, 터미널[^12]

“가장 기본이 되는 개발 툴” 파트에서 준비물을 구체화한다.[^12]

3.6.1 운영체제(PC 준비)

• 개발을 위한 PC는 macOS/Windows/Linux 중 본인이 편한 것을 선택하면 된다고 말한다.[^12]

3.6.2 텍스트 에디터(IDE)

• 코드를 작성할 에디터가 필요하다.[^12]
• 과거에는 Atom, Sublime Text 등을 많이 썼지만, 요즘은 플러그인이 강력한 VS Code 또는 IntelliJ로 개발한다고 설명한다.[^12]
• IntelliJ는 웹개발에서도 편하고 강력한 리팩토링 기능으로 생산성을 높여주지만, 라이선스 비용이라는 단점이 있다.[^12]
• VS Code는 무료이면서도 강력한 확장(Extensions)을 지원해 많은 개발자가 선호한다.[^12]
• 회사에서 유료 IntelliJ 라이선스를 제공해도 VS Code를 더 선호하는 개발자가 많을 정도라며, 본인은 VS Code를 추천한다.[^12]

또한 웹개발에 필요한 필수 익스텐션/단축키를 정리한 영상이 있으니 참고하라고 안내한다.[^13]

3.6.3 브라우저

• 웹개발 필수로 브라우저가 필요하며, 다양한 브라우저가 있지만 크롬이 많이 쓰이고 개발자 도구가 강력해 추천한다고 말한다.[^13]
• 다만, 에디터/OS는 하나만 골라 써도 되지만 브라우저는 크롬 중심으로 개발하되, 다른 브라우저에서도 동작 확인 단계를 꼭 거쳐야 한다고 강조한다.[^13]

3.6.4 터미널

• 개발자에게 필수 도구로 터미널을 든다.[^13]
• OS 기본 터미널을 써도 되고, 마음에 드는 다른 터미널을 써도 된다고 말한다.[^13]
• 터미널에서 자주 쓰는 명령어 정리 영상도 참고하라고 덧붙인다.[^13]

3.7 2단계 핵심 스킬: HTML/CSS/JavaScript를 “어떻게” 공부할 것인가[^14]

프론트엔드에서 정말 중요한 3요소로 HTML, CSS, JavaScript를 꼽으며, 이를 빼놓고 말할 수 없다고 한다.[^14]
그리고 학습자들이 자주 빠지는 양극단을 경고한다.[^14]

• [h 너무 꼼꼼하게 붙잡고 있으면 안 된다] (양이 너무 많아 진도가 안 나갈 수 있음)[^14]
• [c 그렇다고 소홀히 이해 없이 프레임워크로 넘어가면 기초 부족으로 무너질 수 있다] (나중에 디버깅/구조 이해가 어려워짐)[^14]

이어서 각 기술의 역할을 “골격-스타일-동작”으로 정리한다.[^15]

• HTML: 프레임워크와 무관하게 웹사이트/웹앱의 기본 골격을 만든다.[^15]
• CSS: HTML에 스타일을 입히고 어떻게 보일지 결정한다.[^15]
• JavaScript: 여기에 **행동(동작)**을 추가한다.[^15]

특히 프레임워크들이 대체로 JS 기반이므로, JavaScript를 잘 알아야 프레임워크를 쓸 때도 “왜 이렇게 동작하는지”, “어떻게 디버깅해야 하는지” 접근할 수 있다고 강조한다.[^16]

3.7.1 HTML 학습 포인트: 태그 암기보다 구조·시맨틱·SEO·접근성[^17]

“HTML에서 무엇을 중점적으로 공부할까”에 대해 다음을 제시한다.[^17]

• 기본적인 HTML 태그들: 어떤 태그가 있고, 어떤 걸 만들 때 어떤 태그를 쓰는지 “완벽 암기”가 아니라 존재를 알고 필요할 때 찾아 적용할 수 있어야 한다.[^17]
• 페이지 구조: 페이지의 구조를 어떻게 잡아 나갈지를 이해해야 한다.[^17]
• 시맨틱 태그: 아무 태그나 쓰지 말고, 상황에 맞는 의미 있는 태그를 쓰는 법을 공부하라고 한다.[^17]
• SEO(Search Engine Optimization): 특정 키워드로 구글/네이버 검색 시 웹사이트가 노출되도록 신경 써서 만드는 것이 중요하다고 말한다.[^17]
• 접근성(Accessibility): 접근성도 고려해 만들면 좋다고 제안한다.[^17]

다만 이 모든 것을 “꼼꼼히 다”가 아니라, 전체 흐름/구조/적절한 태그 선택을 이해하고 나머지는 찾아볼 수 있을 정도면 된다는 기준을 제시한다.[^17]

[!TIP] HTML 공부의 기준선
“다 외우기”가 아니라 구조적 사고 + 문서/검색으로 찾아 적용하는 습관을 목표로 잡으라고 한다.[^17]

3.7.2 CSS 학습 포인트: 기본 스타일 + 레이아웃 + 반응형 + 애니메이션[^18]

CSS는 다음 범위를 “정도만” 알면 좋다고 구체 항목을 제시한다.[^18]

• 기본 스타일링: 색상, 배경색, 폰트 관련 속성 등 기본 변경/적용 방법[^18]
• 레이아웃: 아이템 배치 방법(예: float, flex, grid) 이해[^18]
• 반응형: 반응형을 위한 기본 CSS 유닛/속성, 미디어 쿼리 사용법[^18]
• 애니메이션: 애니메이션을 어떻게 만들 수 있는지 정도[^18]

또한 본인 채널에 HTML/CSS 기본 영상이 있지만, 현업 하면서 만든 초창기 영상이라 초급 눈높이에서 설명이 아쉬웠고, 2022년에 아카데미 강의 형태로 더 체계적으로 만들까 고민 중이라며 수요를 코멘트로 물어본다.[^18][^19]

그리고 CSS/HTML의 “가장 중요한 포인트”를 다시 강조한다.[^19]

• 달달 외우는 게 아니라(본인도 다 외우지 못한다고 말함)
• 큰 그림을 이해하고, 맥락을 이해하며
• 상세는 검색해 적용하는 능력을 연습하라는 것.[^19]

3.7.3 JavaScript 학습 포인트(핵심 경고): “언어”와 “브라우저 API”를 분리하라[^20]

JS 파트에서 흔한 학습 실수를 지적한다.[^20]

• 많은 사람이 “브라우저에서 DOM 요소 가져와 동적으로 조정하는 것”을 자바스크립트 언어 자체를 배우는 것처럼 공부하는데, 이렇게 하면 나중에 헷갈리고 기초가 탄탄하지 않을 수 있다고 경고한다.[^20]
• 그래서 JS 언어 자체와 브라우저에서 사용하는 API를 “두 가지로 나누어” 공부하는 것이 좋다고 제안한다.[^20]

분리 학습의 순서를 구체화한다.[^21]

• (1) 먼저 JS 문법에 익숙해져, 생각한 로직을 문법으로 구현해 프로그램을 만들 수 있도록 “로직 구현”에 집중한다.[^21]
• (2) 그 다음 브라우저 API(요소 조작, 네트워크 통신 등)를 살펴, 어떤 API가 있고 언제 무엇을 쓰는지 공부한다.[^21]

이 기초를 탄탄히 하면 이후 프론트 프레임워크를 쓰거나, JS로 Node 환경 백엔드를 개발하더라도 흔들리지 않고 더 효율적으로 성장할 수 있다고 강조한다.[^22]

3.7.4 JS 문법: 기본 문법 + 심화 특징(프로토타입/호이스팅/스코프/클로저) + 면접 대비[^23]

JS 언어(문법/개념)를 어떻게 공부할지 항목으로 제시한다.[^23]

• 기본: 변수 할당, 조건문/반복문, 함수, 객체 등[^23]
• 심화: JS의 특징(예: 프로토타입, 호이스팅, 스코프, 클로저)을 공부하면 좋다고 한다.[^23]
• 이유: 실무에서 맞닥뜨릴 수 있는 특징들이고, 면접에서 설명하는 데도 도움이 되므로 정리하면서 공부하면 좋다고 한다.[^23]

또한 본인 채널에 JS 문법 정리 영상이 있지만 초창기 영상이라 아쉬움이 있어 아카데미 강의 제작을 고민 중이며, 댓글 수요를 참고하겠다고 말한다.[^24]

3.7.5 브라우저 API: DOM/이벤트/Fetch 등, “외우지 말고 존재-용도-찾는 법”[^25]

JS 문법 다음 단계로 브라우저 API 학습을 제시한다.[^25]

• DOM 요소를 어떻게 조작하는지[^25]
• 특정 이벤트에 원하는 일을 하려면 어떻게 하는지[^25]
• Fetch API로 서버 데이터를 어떻게 가져오는지[^25]

그리고 HTML/CSS와 동일하게, 전부 외우는 게 아니라 “이런 게 있구나 / 이럴 때 이걸 쓰는구나 / 더 필요하면 어디서 찾아보면 되구나” 수준으로 잡으라고 한다.[^25]

3.7.6 여기까지의 결론: 기본기만으로도 취업 가능하다고 보는 이유[^26]

HTML/CSS/JS를 위 방식대로 이해하고 사용할 수 있으며, 사이트를 보면 “어떻게 만들면 되겠구나” 정도의 구현 감이 오면 취업까지도 충분히 가능하다고 말한다.[^26]
다만 시장에서 더 경쟁력 있으려면, 이 기본을 잘 해두고 다음에 소개하는 것들을 챙기라고 이어간다.[^27]

3.8 4단계(확장/경쟁력): 프로젝트 규모가 커질 때의 문제와 해결 도구들[^27]

기본 3요소만으로 개발을 계속하면 프로젝트 규모가 커질수록 다음 문제가 생긴다고 설명한다.[^27]

• 만드는 것도 어려워지고
• 유지보수는 “정말 어렵다”[^27]

그래서 규모가 커도 개발과 유지보수를 쉽게 하도록 다양한 컨셉/프레임워크/도구가 등장했다고 배경을 설명한다.[^27]

3.8.1 CSS 아키텍처(BEM): 클래스 네이밍 충돌 문제 대응[^28]

순수 CSS만 쓰면 이름 충돌이 많이 나서, 한 곳에서 정의한 스타일이 다른 요소에 영향을 주거나 예상 못한 곳에서 덮어씌워지는 일이 생긴다고 말한다.[^28]
이를 방지하기 위해 “CSS에서 클래스 이름을 어떻게 작성하면 좋은지” 규정한 BEM 아키텍처를 배우면 좋다고 제안한다.[^28]

다만 뒤에서 소개할 CSS 프레임워크를 쓰면 BEM 규칙이 더 이상 필요 없을 수도 있지만, 그래도 배워두면 “왜 편한지”를 이해하는 데 도움이 된다고 말한다.[^28]

3.8.2 CSS 전처리기(Sass/Less/PostCSS): 변수·중첩·모듈·믹스인·함수로 생산성 향상[^29]

다음으로 CSS 전처리기를 소개한다.[^29]

• 전처리기는 순수 CSS 문법을 확장한 “그들만의 문법”으로 더 편하게 스타일을 작성하고, 다시 순수 CSS로 변환해 준다고 설명한다.[^29]
• 순수 CSS의 큰 문제로 “반복 작성이 많다”는 점을 들며, 전처리기가 이를 개선한다고 말한다.[^29]

대표로 Sass, Less, PostCSS를 언급하며, 전처리기의 특징을 예로 든다.[^29]

• 변수 선언 가능 → 재사용성 증가[^29]
• 부모 선택자 안에 자식 선택자 정의(중첩) → 반복 타이핑 감소[^29]
• 모듈화, 믹스인, 함수 등 지원[^29]

또한 각 공식 사이트에서 더 자세한 사용법을 확인하라고 안내한다.[^30]

그리고 PostCSS를 “문법 확장”뿐 아니라 모듈화된 CSS 작성/이름 충돌 방지에도 도움이 되는 도구로 다시 언급한다.[^30]

3.8.3 CSS 프레임워크(부트스트랩): 미리 만들어진 UI를 클래스로 빠르게 적용[^31]

기본 CSS를 이해한 뒤 “빨리 무언가를 만들어야 한다/일일이 만들기 귀찮다”면 CSS 프레임워크를 쓸 수 있다고 말한다.[^31]
대표로 Bootstrap을 들며, 미리 만들어진 UI 요소가 있어 클래스 이름만 지정하면 간편하게 스타일링할 수 있다고 설명한다.[^31]
(영상에서는 인풋 관련 클래스를 지정하는 것만으로 UI가 바뀌는 예를 언급한다.)[^31]

“JS 프레임워크와 함께 묶어 쓸 수 있는 CSS 프레임워크”가 더 있으며, 이는 뒤에서 이어서 말하겠다고 연결한다.[^31]

3.8.4 TypeScript: 대규모/실무에서의 안정성과 유지보수성[^32]

JavaScript를 자신감 있게 “마스터했다”고 말할 수 있다면, TypeScript를 꼭 공부해보라고 강하게 추천한다.[^32]

• 타입스크립트는 JS에 타입이 더해진, JS를 한 단계 감싼 언어이며 JS를 쓰는 곳에서 TS도 사용할 수 있다고 설명한다.[^32]
• JS보다 안정성과 유지보수성이 높아 규모 있는 프로젝트를 운영하는 대부분의 현업에서 TS를 선택한다고 말한다.[^32]
• 본인이 만드는 드림코딩 플랫폼도 백엔드/프론트엔드에서 TS를 선택했다고 사례로 든다.[^32]

또한 JS(동적 타입, 프로토타입 기반)와 TS(타입 추가, 객체지향 개념 활용 가능)를 함께 익히면 다른 분야/언어를 배울 때도 손쉽게 학습할 수 있다고 말한다.[^33]

3.8.5 JavaScript 프레임워크: 반복 로직을 추상화해 “서비스 로직”에 집중하게 함[^34]

순수 JS로 프로젝트를 만들 때 반복 처리 로직과 UI 업데이트 등 공통 문제가 있는데, 이를 처리해주는 것이 JavaScript 프레임워크라고 설명한다.[^34]
프레임워크는 개발자가 애플리케이션에 특화된 로직에 집중하도록 기본적인 것들을 제공한다고 정의한다.[^34]

대표적으로 많이 쓰이는 프레임워크 3가지를 언급하며, 그중 React가 가장 많이 쓰이고 꾸준히 향상되는 프레임워크라 선호한다고 말한다.[^35]
또한 Svelte의 추세/방향성, 그리고 React가 그것을 검토/도입하려는 움직임이 있어 추후 영상으로 다루겠다고 한다.[^35]

“프레임워크 학습 순서”에 대한 선택지

• JS → 프레임워크를 배워도 되고[^36]
• JS → TS → 프레임워크로 가도 된다고 말한다.[^36]

그리고 결정적으로 “너무 다양한 프레임워크가 있으니 전부 배울 필요는 절대 없다”고 선을 긋는다.[^37]

• [h 리액트를 먼저 배워두면] 왜 쓰는지 포인트를 이해하고, 다른 프레임워크를 배울 때 비교적 쉽게 배울 수 있다고 조언한다.[^37]
• [= 결론] 처음 공부해보고 싶은 프레임워크 하나를 고르고, 자신감 있게 사용할 때까지 써본 뒤 필요할 때 다른 것을 선택해 공부하면 된다고 정리한다.[^38]

3.9 SPA의 한계와 SSG/SSR 프레임워크(Next/Nuxt 등)로의 확장[^39]

여기까지의 프레임워크/개발 방식이 주로 SPA(브라우저에서 동작) 중심이라면, 이렇게만 개발할 때 부딪히는 문제를 제시한다.[^39]

• SEO에 취약해질 수 있다.[^39]
• 사용자가 웹페이지를 보는데 시간이 오래 걸리는 문제를 겪을 수 있다.[^39]

이런 문제 상황에서 살펴볼 프레임워크들을 소개한다.[^40]

• SSG(사이트를 미리 만들어 둠): React의 Gatsby, Vue의 Gridsome 등을 언급한다.[^40]
• SSR(요청 시 서버에서 실시간 렌더링): React의 Next, Vue의 Nuxt, Angular의 Universal을 언급한다.[^40]

그리고 React를 배웠다면 Next.js까지 배우는 것을 추천한다고 말한다.[^41]
또한 어떤 프레임워크를 쓰든 TypeScript를 활용해 개발하길 권한다.[^41]

3.10 프레임워크와 함께 쓰는 스타일링 생태계: Tailwind, MUI, Styled-components, PostCSS[^42]

JS 프레임워크와 함께 스타일링을 쉽게 해주는 다양한 선택지를 소개한다.[^42]

• Tailwind CSS: Bootstrap처럼 클래스 지정만으로 미리 만들어진 스타일/컴포넌트를 활용하는 방식으로 설명한다.[^42]
• Material UI(MUI): React에서 이미 만들어진 UI를 가져와 쓸 수 있는 라이브러리로 언급한다.[^42]
• styled-components: JS 파일 안에 CSS를 변수처럼 정의해 사용할 수 있다고 말한다.[^42]
• 이를 CSS-in-JS라고도 부른다고 설명한다.[^43]
• PostCSS는 “미리 만들어진 UI 컴포넌트를 가져다 쓰는” 쪽이 아니라, 순수 CSS를 더 간편한 문법으로, 각 UI 컴포넌트를 고립된 환경에서 쓰도록 돕는 CSS 모듈 성격으로 설명한다.[^43]

또한 도구 선호가 갈리는 지점을 “왜 갈리는지”까지 설명한다.[^44]

• Bootstrap/Tailwind/MUI: 미리 만들어진 UI를 가져다 쓰므로 빠른 개발이 가능해 선호하는 사람도 있다.[^44]
• 정형화된 UI를 싫어하는 사람은 “내가 만들 거야”라고 하며 PostCSS나 styled-components를 쓰거나, Tailwind를 커스터마이즈해 쓰기도 한다고 말한다.[^44]

3.10.1 CSS 파일 vs CSS-in-JS: 장단점 이해 후 선택하라[^45]

기존처럼 CSS 파일에 정의할지, JS 안에 정의할지 호불호가 갈리며, 각각 장단점이 있으니 이해하고 써야 한다고 말한다.[^45]

• styled-components처럼 JS에 스타일을 정의하면 동적으로 스타일 변경이 가능해 좋다고 느끼는 개발자가 있다.[^45]
• 반대로 성능 이슈, 그리고 비즈 로직이 들어갈 JS 파일에 스타일이 섞여 프리젠테이션과 비헤이비어가 섞여 지저분하고 유지보수가 힘들다고 싫어하는 개발자도 있다고 소개한다.[^45]

결론은 “정당한 이유 없이 무조건 이거”가 아니라, 이유를 알고 선택해야 한다는 것이다.[^45]

3.11 프론트엔드 스택 최종 정리(학습 포인트 재강조)[^46]

프론트엔드 파트를 “최종적으로 정리”하며 다음을 다시 강조한다.[^46]

• HTML/CSS는 기본이지만 정말 중요하니 큰 맥락을 이해하라.[^46]
• JS는 프로그래밍 문법과 브라우저 API를 구분해 배우라.[^46]
• (SPA 이후 확장 관점에서) 페이지를 미리 만들어 두는 게 좋은지, 문제점은 무엇인지 등을 포인트로 잡고 공부하라.[^47]
• TypeScript는 꼭 잊지 말고 공부해보라.[^47]

또한 여기서 말한 것보다 더 다양한 컨셉/스킬/프레임워크가 있지만, 하다 보면 “필요할 때 찾아 공부”하면 된다고 선을 긋는다.[^48]

3.12 4단계 병행 툴: Git, 패키지 매니저, 모듈 번들러[^49]

이제 프론트엔드 기술과 함께 병행하면 좋은 “필수 툴”을 소개한다.[^49]

3.12.1 버전 관리 시스템: Git과 호스팅 서비스(GitHub 등)[^49]

과거 다양한 버전관리 시스템이 있었지만, 요즘은 Git이 사실상 기본이라고 말한다.[^49]
로컬에서 작업 버전을 관리하고, 로컬 버전을 서버에 올릴 수 있는 GitHub/Bitbucket/GitLab 같은 서비스를 이용하면 작업물과 히스토리를 잃어버리지 않고 관리할 수 있다고 설명한다.[^49]

3.12.2 패키지 매니저: npm/yarn, 우선 npm 추천[^50]

프로젝트를 하다 보면 직접 코드보다 외부 라이브러리/프레임워크를 가져다 쓰는 경우가 많고, 이를 설치·관리하게 해주는 것이 패키지 매니저라고 설명한다.[^50]
npm, yarn이 있으며 상호 호환이 가능하므로 먼저 npm을 추천한다.[^50]

3.12.3 모듈 번들러: Webpack/Vite(등), 깊게 파기보다 “개념 이해”[^51]

배포 시 모든 소스 코드를 그대로 내보내지 않고 압축/제외/묶어서 사이즈를 줄여 배포하는데, 이때 쓰는 것이 모듈 번들러라고 설명한다.[^51]
예로 Webpack, Vite 등을 언급한다.[^51]

다만 “꼼꼼히 설정까지 공부해야 하냐”에 대해 답은 그렇지 않다는 것이다.[^52]

• 이유: 앞서 말한 JS 프레임워크에 모듈 번들러가 기본 포함되어 자동 번들링을 해주고 기본 설정도 갖춰져 있어 직접 깊게 설정할 일이 거의 없다고 말한다.[^52]
• 그래서 시간이 되면 “이런 식으로 번들링이 되는구나” 정도로 보고, 앞의 것들이 갖춰지고 자신감이 있을 때 봐도 늦지 않다고 조언한다.[^52]

3.13 5단계 테스팅: 테스트 피라미드, Jest/Cypress/RTL, 좋은 테스트 원칙, CI/CD[^53]

프론트 기술과 툴로 무언가를 만들었다면 바로 배포할 수도 있지만, 그 전에 테스팅을 알면 좋다고 말한다.[^53]

• 테스트 피라미드: 어떤 테스트 종류가 있고 언제 어떤 것을 테스트하면 좋은지 이해하라고 한다.[^53]
• JS 환경: Jest, Cypress[^53]
• React 사용 시: React Testing Library를 예로 든다.[^53]

또한 단순히 도구 사용을 넘어, “좋은 테스트 코드를 작성하는 원칙들”도 공부하면 좋다고 말한다.[^53]

그리고 배포 전 테스트 자동 수행을 위해 CI/CD도 살펴보라고 한다.[^54]
다만 취업 전에는 까다로울 수 있으니, 다른 부분을 더 중점적으로 공부한 다음 시간이 되면 보는 것을 추천한다고 난이도 조절 조언을 한다.[^54]

3.14 3단계 퍼블리시(배포): 일단 하나 골라 배포하며 문서로 학습[^55]

배포 단계에서는 “정말 다양한 서비스”가 있다고 말한다.[^55]

• GitHub Pages 같은 심플한 것부터[^55]
• (영상에서 언급) Netlify, Heroku 같은 서비스, 그리고 AWS까지 다양한 옵션이 있다고 한다.[^55]

접근 방식은 “따로 공부해야 하는 내용”이라기보다, 하나를 선택해 배포해보고 문제를 겪고 해결하며, 다른 플랫폼 배포도 문서 확인하면서 시도하라는 것이다.[^55]
즉 배포는 문서 기반 실습으로 익히는 영역으로 제시된다.[^55]

배포까지 해보면 기본 프론트엔드 스택을 어느 정도 마스터했다고 본다고 말한다.[^55]

3.15 배포 이후의 다음 선택: API 활용, Firebase, 백엔드 로드맵으로 확장[^56]

여기까지 왔다면 “내가 해볼 거 다 해봤다”는 느낌과 함께 부족한 부분이 보일 것이고, 추가로 더 공부하고 싶다면 백엔드를 공부해볼 수 있다고 제안한다.[^56]

구체적인 확장 실습 아이디어도 준다.[^56]

• Public API: 트위터/유튜브 등 공식 무료 API를 이용해 프론트엔드를 만들어볼 수 있다고 한다.[^56]
• 자체 데이터 보관을 하고 싶지만 백엔드는 모른다면 Firebase 같은 실시간 DB를 이용해 데이터를 저장하고 API를 사용하는 연습을 추천한다.[^56]
• 더 나아가 “나만의 서비스”를 만들고 싶다면 백엔드를 공부하고 백엔드 로드맵으로 가라고 한다.[^56]

또한 프론트 스택을 쌓아온 사람이면 Node를 이용해 백엔드 서비스를 손쉽게 만들 수 있다고 말하며, 백엔드 로드맵은 다음 기회에 다루겠다고 한다.[^56]

3.16 그 이후의 확장 옵션들: WebAssembly, GraphQL, 크로스플랫폼, AI, Web3[^57]

백엔드까지 하고도 “더 공부할 게 있냐”고 묻는다면 “많다, 정말 많다”고 하며 다양한 확장 분야를 나열한다.[^57]

3.16.1 WebAssembly: JS 대체가 아니라 “성능이 중요한 특정 경우”에 사용[^57]

• 브라우저에서 유일하게 동작하는 언어가 JS라는 전제에서, 성능 최적화를 위해 WebAssembly를 언급한다.[^57]
• C++/Rust 같은 언어로 더 빠르고 성능을 향상한 웹 앱을 만드는 방법이라고 설명한다.[^57]
• 하지만 WebAssembly가 JS를 대체하느냐에 대해 “그건 아니라고 생각”한다고 선을 긋는다.[^57]
• 취지는 JS 대체가 아니라, 비디오/이미지 처리처럼 성능이 중요한 특화 작업에 사용한다는 예를 든다.[^57]

3.16.2 GraphQL: REST 먼저, 그 다음 차이 이해하며 학습[^58]

• 백엔드 통신에서 REST API가 많이 쓰이고, 현업에서도 REST가 더 많이 쓰이는 추세라고 말한다.[^58]
• 따라서 REST를 먼저 공부하고, 그 다음 클라이언트에서 쿼리 형태로 원하는 데이터를 요청해 받는 GraphQL도 배워두면 좋다고 권한다.[^58]
• GraphQL 클라이언트 프레임워크 중 하나를 골라 사용법을 익히고, REST와 GraphQL 차이점을 학습하라고 제안한다.[^58]

3.16.3 크로스플랫폼: Electron, PWA, React Native, Flutter[^59]

만든 웹 앱을 다른 플랫폼에서 구동하고 싶다면 크로스플랫폼을 보라고 한다.[^59]

• 데스크톱 설치형: Electron[^59]
• 모바일/데스크톱 활용: PWA 등으로 기존 기술을 유지하며 확장 가능[^59]
• 또는 React Native를 따로 배워도 되고[^59]
• 완전히 다른 언어인 Dart 기반 Flutter로 모바일뿐 아니라 웹 앱도 만들어볼 수 있다고 한다.[^59]

이 모든 옵션 역시 “전부 다 배울 필요는 없고, 하고 싶을 때/원할 때/필요할 때 찾아 공부”하라는 원칙을 재확인한다.[^59]

3.16.4 AI, Web3.0: JS 환경에서 가능한 라이브러리/개념을 필요에 따라 탐색[^60]

• AI를 해보고 싶다면 브라우저 JS 환경에서 AI를 쓸 수 있는 라이브러리들이 있으니 찾아보며 “어떤 경우에 어떤 걸 쓰는지” 챙겨보라고 한다.[^60]
• 요즘 말하는 Web 3.0 관련 개념, 웹에서 쓸 프레임워크/라이브러리/서비스들이 많이 나오니 조금씩 공부해보라고 제안한다.[^60]

3.17 엔딩: 로드맵은 “전부 다”가 아니라 나침반 + 필요 키워드(HTTP/DNS/IP)는 그때그때 파고들기[^61]

영상 말미에서 로드맵의 사용법을 다시 못 박는다.[^61]

• 로드맵을 다운로드할 수 있게 공유하겠고, 추천 항목을 빨간색으로 표시한 버전/표시 없는 버전 두 가지를 제공한다고 한다.[^61]
• [c “여기 있는 걸 모두 다 공부해야 한다”는 뜻이 아니다] 라고 명확히 말한다.[^61]
• 지금 위치와 공부할 것을 점검하는 좋은 나침반으로 쓰라고 조언한다.[^61]

또한 로드맵에 포함되지 않은 HTTP, 인터넷 동작 원리, DNS, IP 같은 키워드가 튀어나오면 그냥 지나치지 말고, 찾아보고 정리하고 익히며 공부해 나가라고 말한다.[^61]

마지막으로 시청 감사, 좋아요/코멘트 요청, 로드맵 제작이 힘들었다는 제작 비하인드, 그리고 “꿈을 멋지게 디자인하고 코딩해 나가라”는 메시지로 마무리한다.[^62]

---

4. 핵심 통찰[^46]

1. [c 로드맵의 목적은 “기술 목록 완주”가 아니라, 내가 지금 어디에 있는지 점검하고 다음 행동을 선택하게 하는 나침반이다.] 로드맵을 외우거나 강박적으로 전부 학습하라고 하지 않고, 필요에 따라 선택·확장하라는 관점이 반복된다.[^61]
2. [h 프론트엔드 기본기는 “암기”가 아니라 “큰 그림+문서/검색을 통한 적용” 능력으로 만든다.] HTML/CSS/브라우저 API에서 특히 ‘전부 외우지 말라’는 메시지를 지속적으로 준다.[^17][^25]
3. [c JavaScript는 반드시 “언어 자체”와 “브라우저 API”를 분리해서 배워야 한다.] DOM 조작을 언어 학습처럼 착각하면 기초가 약해지고, 프레임워크/노드로 확장할 때 흔들린다는 문제의식을 분명히 한다.[^20][^22]
4. [h 규모가 커질수록 유지보수가 핵심 문제가 되며, 그래서 타입스크립트·프레임워크·CSS 아키텍처/도구들이 ‘필요해진다’.] 도구 소개가 유행이 아니라 문제(충돌/반복/복잡도/유지보수) 해결로 연결된다.[^27][^28][^32]
5. [h 프레임워크는 “하나를 깊게”가 유리하고, 리액트는 범용성과 학습 전이 효과가 큰 출발점이 될 수 있다.] 프레임워크 난립 상황에서 ‘전부 학습’이 아니라 ‘하나 선택→숙련→필요 시 확장’을 제시한다.[^37][^38]

실행 관점 시사점(콘텐츠의 제안을 행동으로 옮기기)[^9][^55]

• 기본 툴(VS Code/크롬/터미널) 세팅 후, HTML 구조 → CSS 레이아웃/반응형 → JS 문법 → 브라우저 API 순서로 작은 앱을 만든다.[^12][^21]
• 만든 뒤에는 반드시 **배포(예: GitHub Pages 등)**까지 해보고, 배포 문서를 읽으며 반복한다.[^55]
• 규모가 커지는 시점에 맞춰 TypeScript와 **프레임워크(React→Next)**를 붙이고, 테스트(Jest/Cypress/RTL)와 CI/CD는 난이도에 따라 단계적으로 도입한다.[^41][^53][^54]

---

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

프론트엔드(Frontend): 브라우저(클라이언트)에서 사용자에게 데이터를 보여주고, 사용자 요청을 서버에 전달하는 영역/개발자 역할.[^5]
백엔드(Backend): 서버에서 DB 저장·조회·데이터/로직 처리를 담당하는 영역/개발자 역할.[^5]
풀스택(Full-stack): 프론트엔드와 백엔드를 모두 다룰 수 있는 개발자.[^5]
SEO: 검색 엔진 최적화. 검색 키워드로 구글/네이버에서 사이트가 노출되도록 만드는 관점.[^17]
시맨틱 태그(Semantic Tag): 의미 있는 HTML 태그를 상황에 맞게 사용해 구조를 잡는 것.[^17]
브라우저 API: 브라우저 환경에서 DOM 조작, 이벤트 처리, 네트워크 통신(Fetch 등)에 쓰는 기능/함수들.[^21][^25]
BEM: CSS 클래스 네이밍 규칙(아키텍처)로, 스타일 이름 충돌/의도치 않은 영향 범위를 줄이기 위한 방식.[^28]
CSS 전처리기(Preprocessor): Sass/Less/PostCSS 등. 변수/중첩/믹스인 등 확장 문법으로 작성 후 CSS로 변환해 생산성을 높이는 도구.[^29]
SPA: 브라우저에서 동작하는 싱글 페이지 애플리케이션 방식(영상에서 프레임워크 학습 범주로 언급).[^39]
SSG: 사이트를 미리 생성해 제공하는 방식(예: Gatsby/Gridsome 언급).[^40]
SSR: 요청 시 서버에서 실시간으로 렌더링해 페이지를 제공하는 방식(예: Next/Nuxt/Universal 언급).[^40]
패키지 매니저: npm/yarn. 외부 라이브러리 설치·관리 도구.[^50]
모듈 번들러: 배포를 위해 소스 코드를 묶고 압축/최적화하는 도구(예: Webpack/Vite).[^51]
테스트 피라미드: 테스트 종류와 어떤 레벨 테스트를 언제 적용할지에 대한 개념.[^53]
CI/CD: 배포 전 자동 테스트 수행 등 배포 파이프라인 자동화 개념으로 언급.[^54]
WebAssembly: JS 대체가 아니라 성능이 중요한 특정 작업에 C++/Rust 등으로 성능을 올릴 수 있는 기술로 소개.[^57]
REST API / GraphQL: 백엔드 통신 방식. 현업은 REST가 더 흔하니 REST 먼저 후 GraphQL을 확장 학습하라고 제안.[^58]

---

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

• 제목: 2022 웹개발 로드맵 총정리 (공부순서 알려드림) | 올해는 정말 해보자[^1]
• 채널: 드림코딩[^1]
• 길이: 33분 36초[^1]
• 링크: https://www.youtube.com/watch?v=TTLHd3IyErM[^1]

---

[^1]: @[00:00] "시장(현업)에서 경쟁력 있는 웹개발자가 되기 위해서는 어떻게 할까요" + 영상 메타(제목/채널/길이/링크)로 제공된 입력 콘텐츠. [^2]: @[00:06] "2022년 트렌드에 맞춰서 어떤 거부터 무엇을 중점적으로 공부하면 좋은지 알아보겠습니다" [^3]: @[00:12]~@[00:33] 연봉 수치(백엔드/프론트엔드/풀스택) 및 수요 증가 추세 언급. [^4]: @[00:37]~@[00:53] "프론트엔드와 백엔드 차이" 도입, 서버/브라우저(클라이언트) 설명. [^5]: @[00:58]~@[01:19] 프론트-서버 요청/응답, 백엔드/프론트엔드/풀스택 개발자 정의. [^6]: @[01:28] "프론트엔드 개발 로드맵을 살펴볼 거예요" [^7]: @[01:35]~@[01:44] 기존 로드맵이 복잡해 보임, "뭐부터/뭐가 중요/뭘 더" 혼란 제시. [^8]: @[01:52] 현업 테크리더까지의 학습 순서+실용 스킬을 골라 로드맵에 녹였다는 주장. [^9]: @[02:15]~@[02:47] 5단계(툴/스킬/퍼블리시/추가 툴/테스팅 자동화) 구조 설명. [^10]: @[02:58]~@[03:20] 생산성 툴 학습의 중요성, 프론트 공부와 병행 추천. [^11]: @[03:20]~@[03:37] 테스트 코드 작성, 배포 전 자동 테스트(자동화) 강조. [^12]: @[04:21]~@[05:15] 운영체제, 에디터(VS Code/IntelliJ) 비교 및 VS Code 추천. [^13]: @[05:22]~@[06:14] 크롬 추천 및 타 브라우저 확인, 터미널과 명령어 학습 자료 언급. [^14]: @[06:27]~@[06:34] HTML/CSS/JS 중요하지만 과도 집착/기초 없이 프레임워크로 점프 경고. [^15]: @[06:49]~@[07:15] HTML=골격, CSS=스타일, JS=동작 역할 설명. [^16]: @[07:15]~@[07:25] 프레임워크가 JS 기반이므로 JS 이해가 디버깅/동작 이해에 중요. [^17]: @[07:42]~@[08:57] HTML 학습 포인트(태그/구조/시맨틱/SEO/접근성) 및 학습 기준. [^18]: @[09:03]~@[09:36] CSS 학습 범위(기본/레이아웃/반응형/미디어쿼리/애니메이션). [^19]: @[09:43]~@[10:32] 강의 제작 계획 언급, "다 외우지 말고 큰 그림+검색 능력" 강조. [^20]: @[10:44]~@[11:06] DOM 조작을 JS 언어 학습처럼 배우는 실수 지적, 언어 vs API 분리 제안. [^21]: @[11:14]~@[11:45] JS 문법으로 로직 구현 집중 후, 브라우저 API 학습 순서 제안. [^22]: @[11:58] JS 기초가 프레임워크/노드 확장 시 흔들리지 않게 한다는 주장. [^23]: @[12:27]~@[12:55] JS 기본 문법+심화(프로토타입/호이스팅/스코프/클로저) 및 면접 언급. [^24]: @[13:04]~@[13:24] JS 아카데미 강의 제작 고민 및 코멘트 요청. [^25]: @[13:32]~@[14:06] 브라우저 API(DOM/이벤트/Fetch) 학습 방식: 외우지 말고 찾아 적용. [^26]: @[14:06]~@[14:24] 여기까지면 사이트를 보고 구현 감이 생기고 취업도 충분하다는 주장. [^27]: @[14:34]~@[14:55] 기본 3요소만으로는 규모 커질수록 개발·유지보수 어려움, 해결 도구 등장 배경. [^28]: @[14:55]~@[15:31] CSS 이름 충돌 문제, BEM 아키텍처 학습 제안. [^29]: @[15:31]~@[16:23] CSS 전처리기(Sass/Less/PostCSS) 개념과 특징(변수/중첩/믹스인/함수). [^30]: @[16:33]~@[16:47] 공식 문서 확인, PostCSS의 모듈화/이름충돌 방지 언급. [^31]: @[16:47]~@[17:16] CSS 프레임워크(부트스트랩)로 빠른 스타일링 가능 설명. [^32]: @[17:37]~@[18:09] 타입스크립트 추천, 안정성/유지보수성, 실무 선택 및 본인 사례. [^33]: @[18:09]~@[18:21] JS와 TS를 함께 익히면 다른 분야/언어 학습에 도움. [^34]: @[18:36]~@[18:59] 프레임워크 정의: 반복 로직/공통 처리 제공, 서비스 로직에 집중. [^35]: @[19:03]~@[19:31] 리액트가 많이 쓰이고 선호, 스벨트 방향성 언급. [^36]: @[19:38]~@[19:51] JS→프레임워크 또는 JS→TS→프레임워크 경로 가능. [^37]: @[20:00]~@[20:13] 프레임워크 전부 학습 불필요, 리액트 먼저 추천 논리. [^38]: @[20:13]~@[20:29] 프레임워크 하나 선택→자신감 있게→필요 시 추가 학습. [^39]: @[20:36]~@[20:54] SPA 중심 개발 시 SEO 취약/로딩 문제 제시. [^40]: @[20:57]~@[21:19] SSG(Gatsby/Gridsome), SSR(Next/Nuxt/Universal) 소개. [^41]: @[21:19]~@[21:38] 리액트 후 넥스트 추천, 어떤 프레임워크든 TS 권장. [^42]: @[21:45]~@[22:12] Tailwind, MUI, styled-components 소개. [^43]: @[22:19]~@[22:39] CSS-in-JS 용어, PostCSS를 모듈화 CSS 도구로 설명. [^44]: @[22:39]~@[22:56] UI 프레임워크 빠른 개발 vs 정형화 거부, 커스터마이징/대안 언급. [^45]: @[23:04]~@[23:30] CSS 파일 vs CSS-in-JS 장단점(동적 스타일/성능/관심사 혼재)과 선택 기준. [^46]: @[23:38]~@[24:00] 프론트엔드 요약 정리: HTML/CSS 큰 맥락, JS 문법 vs 브라우저 API 구분. [^47]: @[24:00]~@[24:28] (SSG/SSR 관점) 페이지 미리 생성 포인트, TS 재강조. [^48]: @[24:32]~@[24:44] 더 많은 스킬은 필요할 때 찾아 공부하면 됨. [^49]: @[24:44]~@[25:11] Git과 GitHub/Bitbucket/GitLab 버전관리 설명. [^50]: @[25:11]~@[25:42] 패키지 매니저(npm/yarn), npm 추천. [^51]: @[25:42]~@[26:09] 모듈 번들러 개념과 예시(Webpack/Vite). [^52]: @[26:09]~@[26:44] 프레임워크에 번들러 포함, 깊게 설정 학습은 나중에. [^53]: @[26:44]~@[27:20] 테스트 피라미드, Jest/Cypress/React Testing Library, 좋은 테스트 원칙. [^54]: @[27:20]~@[27:30] CI/CD로 배포 전 테스트 자동 수행, 취업 전엔 난이도 높을 수 있음. [^55]: @[27:43]~@[28:27] 배포 서비스(GitHub Pages/Netlify/Heroku/AWS 등)와 문서 기반 실습 권장. [^56]: @[28:38]~@[29:36] Public API 활용, Firebase, 백엔드/Node로 확장 제안. [^57]: @[29:46]~@[30:29] WebAssembly 소개, JS 대체 아님, 성능 특화(비디오/이미지) 예시. [^58]: @[30:29]~@[31:04] REST가 현업에서 더 흔함, REST 후 GraphQL 학습 및 차이 이해 권장. [^59]: @[31:04]~@[31:56] 크로스플랫폼(Electron/PWA/React Native/Flutter) 옵션과 선택 학습 원칙. [^60]: @[32:03]~@[32:30] JS 환경 AI 라이브러리 탐색, Web3.0 관련 개념/도구 학습 제안. [^61]: @[32:37]~@[33:08] 로드맵 다운로드/빨간 표시 버전, 전부 학습 강요 아님, HTTP/DNS/IP 키워드 대응. [^62]: @[33:08]~@[33:34] 시청 감사, 좋아요/코멘트, 꿈을 디자인하고 코딩하라는 마무리.