video note · 48
48. 비개발자 바이브코더를 위해 만든, 가볍게 들어도 깊게 남는 프론트엔드 기본 지식
배울 내용
프론트엔드는 사용자가 보고 누르는 화면과 그 반응을 만듭니다. HTML로 내용 구조를 적고, CSS로 배치와 색을 정하며, JavaScript로 클릭 뒤 상태 변화를 처리합니다. 오류를 볼 때도 세 역할 중 어디에서 생겼는지 먼저 나눕니다.
React와 Next.js는 이 세 언어를 대신하는 마법 도구가 아닙니다. 화면이 커졌을 때 구성요소, 상태, 데이터 요청, 서버 렌더링을 정리하는 도구입니다. 작은 정적 페이지는 HTML·CSS·JavaScript만으로도 충분할 수 있습니다.
시간대별 정리
| 구간 | 영상 흐름 | 배울 내용 |
|---|---|---|
| 00:00:00–00:00:33 | 인트로 (외우지 말고 이해해야 하는 이유) | React·Next.js 같은 이름을 외우기보다 앞선 문제를 해결하며 기술이 등장한 순서를 보겠다고 안내합니다. |
| 00:00:33–00:01:08 | 인터넷 vs 웹 (인프라 vs 서비스 개념 차이) | 인터넷은 컴퓨터를 연결하는 통신망이고, 웹은 그 위에서 주소와 링크로 문서를 주고받는 서비스라고 구분합니다. |
| 00:01:08–00:01:47 | 웹의 탄생 (팀 버너스리 & 하이퍼링크) | 팀 버너스리가 연구 문서를 쉽게 연결하고 공유하려고 하이퍼링크 기반 웹을 제안한 배경을 소개합니다. |
| 00:01:47–00:03:23 | 웹 3대 기술 (HTML / URL / HTTP 구조 이해) | HTML은 문서 구조, URL(Uniform Resource Locator)은 자료 주소, HTTP(HyperText Transfer Protocol)는 브라우저와 서버가 요청·응답하는 규칙으로 설명합니다. |
| 00:03:23–00:03:52 | 초기 웹 (텍스트 기반, 기능 없음) | 초기 웹은 글과 링크 중심의 정적 문서라 배치·색·사용자 상호작용 표현이 제한됐다고 설명합니다. |
| 00:03:52–00:05:31 | CSS (디자인 문제 해결, 구조/표현 분리) | HTML 내용 구조와 화면 표현을 분리해 여러 페이지의 글꼴·색·배치를 일관되게 바꾸는 CSS의 역할을 설명합니다. |
| 00:05:31–00:07:45 | JavaScript (이벤트, DOM, 인터랙션 시작) | 클릭·입력 같은 이벤트를 받고 DOM을 바꿔 새 문서를 받지 않아도 화면이 반응하게 하는 JavaScript를 소개합니다. |
| 00:07:45–00:10:12 | 브라우저 전쟁 (크로스브라우저 문제) | 브라우저마다 같은 코드의 동작이 달라 개발자가 별도 처리를 해야 했고, 웹 표준의 필요가 커졌다고 설명합니다. |
| 00:10:12–00:12:01 | 렌더링 과정 (파싱 → 렌더트리 → 레이아웃 → 페인트 + 리플로우) | 브라우저가 HTML·CSS를 분석해 그릴 요소를 정하고, 크기와 위치를 계산한 뒤 픽셀을 그리는 순서를 설명합니다. 배치가 바뀌면 계산을 다시 할 수 있습니다. |
| 00:12:01–00:12:54 | jQuery (DOM 조작 통일, 개발 편의성 혁명) | 브라우저별 DOM 조작 차이를 같은 문법으로 감싸 개발 코드를 줄인 jQuery의 역할을 설명합니다. |
| 00:12:54–00:14:24 | React (상태 기반 UI, 추상화/재사용/상태관리) | 데이터 상태가 바뀌면 관련 화면을 다시 계산하고, 화면을 재사용 가능한 구성요소로 나누는 React의 접근을 소개합니다. |
| 00:14:24–00:14:58 | 프론트엔드 변화 (퍼블리셔 → 개발자 전환) | 화면 꾸미기 중심 작업에서 상태·데이터·성능을 다루는 독립적인 프론트엔드 개발 역할로 범위가 넓어졌다고 설명합니다. |
| 00:14:58–00:17:01 | Node.js / NPM (JS 생태계 확장, 패키지 관리) | Node.js가 브라우저 밖에서도 JavaScript를 실행하게 했고, npm이 다른 사람이 만든 코드 패키지를 설치·관리하는 통로가 됐다고 설명합니다. |
| 00:17:01–00:18:02 | 빌드 등장 배경 (코드 관리 문제 발생) | 모듈과 최신 문법, CSS·이미지 파일이 늘면서 개발용 코드를 브라우저가 읽기 좋은 결과물로 바꾸는 단계가 필요해졌다고 설명합니다. |
| 00:18:02–00:20:00 | 빌드 과정 (트랜스파일링 / 번들링 / 트리쉐이킹 / 최적화) | 최신 문법 변환, 여러 파일 묶기, 쓰지 않는 코드 제거, 파일 압축을 거쳐 배포 파일을 만드는 과정을 설명합니다. |
| 00:20:00–00:21:16 | MPA (기존 웹 구조, 페이지 새로고침 방식) | 페이지 이동 때 서버에서 새 HTML 문서를 받아 화면 전체를 다시 그리는 MPA 방식을 소개합니다. |
| 00:21:16–00:22:06 | SPA (싱글 페이지, 앱처럼 동작, CSR 개념) | 첫 문서를 받은 뒤 JavaScript가 필요한 데이터와 화면만 바꾸는 SPA와 CSR(Client-Side Rendering, 브라우저에서 화면을 만드는 방식)을 설명합니다. |
| 00:22:06–00:23:02 | 프론트엔드 역할 확장 (UI + 상태 + API 통신) | SPA에서는 UI(User Interface, 사용자가 보는 화면)뿐 아니라 사용자 상태, 화면 이동, 백엔드 API(Application Programming Interface, 프로그램 사이의 요청 규칙)와 오류 처리까지 프론트엔드가 맡는다고 설명합니다. |
| 00:23:02–00:24:05 | API 구조 (프론트 ↔ 백엔드 데이터 흐름 변화) | 프론트엔드가 API로 데이터를 요청하고 JSON 응답을 받아 화면 상태를 갱신하는 구조를 설명합니다. |
| 00:24:05–00:25:29 | SPA 단점 (초기 로딩 느림 + SEO 문제) | 처음에 JavaScript를 많이 받아야 해 초기 표시가 늦을 수 있고, 검색 엔진이 완성된 내용을 바로 읽기 어려운 문제가 있었다고 설명합니다. |
| 00:25:29–00:26:12 | SSR / CSR / 하이드레이션 (렌더링 방식 비교) | SSR(Server-Side Rendering, 서버에서 HTML을 만드는 방식)은 초기 HTML을 보내고, 하이드레이션은 브라우저가 그 HTML에 상호작용을 붙이는 과정이라고 설명합니다. |
| 00:26:12–00:26:50 | Next.js & 혼합 렌더링 (현대 구조) | Next.js가 페이지별로 서버 렌더링과 브라우저 렌더링을 조합할 수 있게 해 초기 표시와 상호작용 요구를 함께 다룬다고 소개합니다. |
| 00:26:50–00:27:12 | 트레이드오프 (SPA vs SSR 핵심 개념 정리) | 모든 화면에 같은 방식을 쓰지 않고 검색 노출, 초기 속도, 사용자 상호작용, 서버 비용을 보고 렌더링 방식을 고른다고 정리합니다. |
| 00:27:12–00:28:25 | 전체 흐름 요약 | 문서 공유에서 CSS·JavaScript·표준화·React·npm·빌드·SPA·SSR로 이어진 문제와 해결의 흐름을 다시 묶습니다. |
| 00:28:25–00:29:12 | 결론 & 다음 강의 예고 (백엔드) | 프론트엔드를 브라우저와 사용자 경험을 설계하는 영역으로 정리하고, 요청 처리와 저장을 다룰 백엔드 후속 편을 예고합니다. |
학습 포인트
- HTML은 내용 구조, CSS는 화면 표현, JavaScript는 사용자 행동 뒤의 변화를 맡습니다.
- 빌드 오류와 브라우저 실행 오류는 생기는 단계가 다르므로 로그 위치를 나눠 봅니다.
- React나 Next.js는 화면의 상태와 데이터 흐름이 복잡해질 때 정리를 돕는 도구이며 모든 페이지의 필수 조건은 아닙니다.
따라 하기
- 같은 소개 카드를 HTML 구조, CSS 표현, JavaScript 동작 세 파일로 나눠 만듭니다. 버튼을 누르면 카드의
data-state값과 문구가 바뀌게 하고, 각 파일이 맡은 역할과 브라우저에서 확인한 결과를frontend-three-layers.md에 기록합니다.