티스토리 뷰
목차
AI가 점점 우리 생활 깊이 파고들고 있습니다. 이제 컴퓨터 언어를 배우지 않아도 코딩이 가능한 세상이 열리고 있고 이를 잘 활용하여 성공적인 1인 기업을 운영하여 수익을 일으키고 있다는 인물들의 뉴스도 자주 접하게 됩니다. 누구나 쉽게 가능하다고는 하지만, 어떻게 접근을 해야하는지는 막막한 것이 사실입니다. 큰 배경 지식을 한번 정리하고 싶던 와중에 한 유튜버의 양질의 영상을 발견했습니다. 문제는 이 분야를 전공하지 않은 일반인으로서는 여전히 어렵다는 것이지요.
우선 정리를 해보고 여러번 다시 반복해서 들어봐야 할 것 같습니다. 양실장의 바이브코딩대학 뿌리강의 (1) 비개발자 바이브코더를 위해 만든, 가볍게 들어도 깊게 남는 프론트엔드 기본 지식의 전체 스크립트를 바탕으로 각 챕터별 핵심 내용과 흐름을 학습하기 좋게 정리해 보았습니다. 지식이 휘발되지 않도록 기록을 남깁니다!!
1. 인트로 & 개념 구분
- 강의 목적: 프론트엔드 용어를 단순 암기하는 대신, 기술의 탄생 배경과 문제 해결 역사를 이해하여 AI(바이브코딩) 활용 능력을 높임.
- 인터넷 vs 웹 개념 차이
- 인터넷 (Internet): 전 세계 컴퓨터를 연결하는 네트워크 인프라 (도로망)
- 웹 (Web): 인터넷이라는 도로 위에서 동작하는 서비스/우편 시스템 (이메일, FTP 등도 인터넷 위에서 노는 별개 시스템)
2. 웹의 탄생과 3대 기술
- 웹의 출발점: 1989년 CERN의 팀 버너스리가 연구 문서 공유를 위해 제안. (원래 앱이나 쇼핑몰이 아닌 단순 문서 공유 시스템)
- 웹 3대 핵심 기술 (1991년 등장)
- HTML (HyperText Markup Language): 문서의 구조와 의미를 정의
- URL (Uniform Resource Locator): 인터넷상 문서의 고유 주소
- HTTP (HyperText Transfer Protocol): 문서를 주고받는 대화 규칙/프로토콜
- 초기 웹의 특징 : 스타일이나 사진이 거의 없는 텍스트 중심의 정적 페이지(Static Page) 형태
3. CSS의 등장 - 구조와 표현의 분리
- 배경: HTML 태그 안에 디자인 스타일을 직접 집어넣다 보니 코드 유지보수가 극도로 어려워짐 (유지보수 지옥)
- CSS (Cascading Style Sheets, 1996년)
- 핵심 철학: 구조(HTML)와 표현/디자인(CSS)의 분리
- 캐스케이딩(Cascading) 원리: 스타일이 폭포처럼 상위(부모)에서 하위(자식)로 흐르며 상속 및 적용됨
4. JavaScript와 반응형 웹
- JavaScript (1995년): 네스케이프에서 단 10일 만에 개발. 브라우저 내부 엔진에서 '실행'되는 언어 (Java와는 이름만 유사할 뿐 완전히 다른 언어).
- 핵심 개념
- 이벤트(Event): 클릭, 스크롤, 키 입력 등 사용자 동작 신호 감지
- DOM 조작 (Document Object Model): HTML 구조를 브라우저 내부 지도로 파악하여 실시간으로 글자/색상/요소를 변경 (무대 세팅을 공연 도중 바꾸는 연출)
5. 브라우저 전쟁 & 렌더링 원리
- 브라우저 전쟁: IE와 네스케이프 등의 주도권 싸움으로 인해 동일한 코드가 브라우저마다 완전히 다르게 표현되는 크로스 브라우징 문제 발생
- 브라우저 렌더링 과정
- 파싱 (Parsing): HTML/CSS 파일을 위에서 아래로 읽고 구조 파악
- 렌더 트리 생성: 실제 화면에 그려질 요소만 선별
- 레이아웃 (Layout): 각 요소의 위치 좌표 및 크기 계산
- 페인트 (Paint): 실제로 색을 칠하고 화면에 완성
- 리플로우 (Reflow): JS로 DOM을 바꿀 때 레이아웃을 다시 계산하는 과정. 리플로우가 잦아지면 성능 저하(버벅임) 발생
6. 라이브러리와 프레임워크의 진화
- jQuery (2006년): 복잡하고 브라우저마다 달랐던 DOM 조작 방식을 하나로 통일
- React (2013년): 웹 서비스가 거대해지며 상태(State) 관리가 복잡해지자 등장
- 추상화 (Abstraction): 복잡한 로직은 내부로 숨기고 간편한 기능 제공
- 재사용성 (Component): 반복되는 UI 요소를 틀(컴포넌트)로 만들어 재사용
- 상태 관리 (State Management): 데이터가 변경되면 UI가 알아서 업데이트되도록 제어
- 퍼블리셔 → 프론트엔드 개발자로의 전환: 단순 화면 구현에서 데이터 흐름과 로직을 설계하는 영역으로 발전
7. Node.js, NPM & 조립식 개발 생태계
- Node.js (2009년) : 브라우저 외부(내 컴퓨터/서버)에서도 자바스크립트를 실행할 수 있게 해주는 런타임 환경
- NPM (Node Package Manager, 2010년): 개발자들의 코드 패키지 앱스토어
- package.json & 의존성 (Dependency) : 어떤 패키지와 버전을 사용하는지 적어 놓은 부품 명세서. 프로젝트 환경 통일의 핵심
8. 빌드(Build) 과정의 이해
- 빌드가 필요한 이유: 개발 용도의 최신 문법/분동 코드는 구형 브라우저 미지원 및 용량/속도 문제를 유발하므로 배포용으로 변환해야 함.
- 4대 빌드 과정
- 트랜스파일링 (Transpiling): 최신 자바스크립트 문법을 구형/표준 문법으로 자동 번역 (예: Babel)
- 번들링 (Bundling): 수십, 수백 개의 모듈 파일을 하나/몇 개로 압축 묶음 (예: Webpack, Vite)
- 트리쉐이킹 (Tree Shaking): 미사용 코드(가지)를 흔들어 지워내는 용량 최적화
- 프로덕션 최적화: 공백, 주석, 긴 변수명을 압축하여 난독화 및 최소화
9. MPA vs SPA & 클라이언트 사이드 라우팅
- MPA (Multi-Page Application) 전통적인 구조. 페이지 이동 시마다 서버에서 전체 HTML을 새로 받으므로 화면 깜빡임 발생
- SPA (Single Page Application): 앱 같은 웹 경험 제공. HTML은 단 1개만 로드하고, 내부 화면 교체는 자바스크립트가 처리 (클라이언트 사이드 라우팅)
10. API 기반의 역할 분리
- 프론트엔드와 백엔드의 분리 : 과거에는 서버가 완제 HTML을 전달했으나, 현대에는 서버가 API(데이터 창구)를 통해 순수 데이터만 주고 프론트엔드가 이를 받아 화면에 조립
11. SPA의 한계와 현대의 렌더링 방식
- SPA의 대표적인 문제점
- 초기 로딩 속도 지연: 전체 자바스크립트 번들을 다 다운로드해야 화면이 보임
- SEO (검색 엔진 최적화) 불리: 검색 크롤러가 빈 HTML만 읽고 나가버림
- 렌더링 방식 비교
- CSR (Client-Side Rendering): 브라우저가 자바스크립트로 화면을 직접 그림 (SPA 방식)
- SSR (Server-Side Rendering): 서버에서 완성된 HTML을 만들어 빠르게 뿌려줌
- 하이드레이션 (Hydration): SSR로 전달받은 정적 HTML에 자바스크립트를 주입하여 반응형 앱으로 다시 활성화하는 과정
- 현대 프론트엔드의 트렌드: SSR과 CSR을 적재적소에 섞어 쓰는 Next.js 기반의 혼합(하이브리드) 렌더링 구조 사용