Week 18 — 프론트엔드 뿌리: 웹은 원래 문서였다

CONNECT FIRST

먼저, 배운 것과 연결하기

복습 같은 의미와 표현 확장 이미 배운 내용을 더 정확히 NEW 이번 주에 처음

기존 학습	이번 주에는	원문 다시 보기
복습 · W8 웹 = 한 편의 공연	무대인 프론트엔드 안쪽 구조로 들어간다.	공연 비유
복습 · W8 HTML=대본, CSS=의상·조명, JS=배우의 즉흥 연기	표현을 그대로 유지하고 DOM·렌더링·상태를 얹는다.	프론트엔드 3도구
복습 · W3·W8 API=웨이터 / API=무전기	둘 다 프론트와 서버 사이의 요청·응답을 설명하는 비유다. Week 19에서 실제 API를 붙인다.	식당 비유 · 무전기 비유
복습 · W9·W10 계획 → 프롬프트 → 실행 → 확인	같은 순서로 팀 문서 보관소 화면을 만든다.	Plan 모드 · 룰렛 프롬프트
확장 · W10 HTML 한 파일로 만든 룰렛	이번에는 같은 HTML·CSS·JS를 역할별 3파일로 나눈다.	한 파일 실습
확장 · W11 GitHub Pages로 바로 배포	파일을 그대로 올릴 수 있었던 프로젝트와 빌드가 필요한 프로젝트를 구분한다.	Pages 배포

01 · THE DOCUMENT WEB

인터넷과 웹은 같은 말이 아니다

인터넷은 컴퓨터를 연결하는 도로망이고, 웹은 그 도로 위에서 문서를 주고받는 시스템입니다. 이메일도 인터넷을 쓰지만 웹 자체는 아닙니다.

초기의 웹은 연구 문서를 서로 연결해 읽는 데서 출발했습니다. 그래서 오늘날의 복잡한 앱 안에도 문서의 흔적이 그대로 남아 있습니다.

HTML문서의 구조 — 무엇이 제목이고 본문인지

URL문서의 주소 — 어디에 있는지

HTTP요청·응답 규칙 — 어떻게 주고받는지

확장 · W3 Week 3에서 배운 Request와 Response는 API만의 말이 아닙니다. 브라우저가 웹 문서를 가져올 때도 HTTP 요청과 응답이 오갑니다.

02 · PROBLEM → TOOL

문제가 하나씩 기술을 만들었다

HTML = 대본제목, 버튼, 입력칸의 구조

CSS = 의상과 조명색, 글꼴, 간격, 배치

JavaScript = 배우의 즉흥 연기클릭과 입력에 반응

문제 01

문서가 못생겼다

구조만으로는 읽기 좋고 일관된 화면을 만들기 어렵다.

→

CSS

문서의 구조와 표현을 분리한다. Cascade는 여러 스타일 규칙이 우선순위에 따라 적용되는 방식이다.

문제 02

문서가 반응하지 않는다

클릭해도, 입력해도 화면이 그대로다.

→

JavaScript

이벤트에 반응하고 DOM을 바꾼다. HTML 원본 파일을 고치는 것이 아니라 브라우저 메모리 속 화면 구조를 바꾼다.

문제 03

화면 코드가 너무 복잡해졌다

버튼·카드·목록이 늘수록 같은 코드를 반복하고 상태를 맞추기 어렵다.

→

컴포넌트와 React

재사용할 화면 조각을 만들고, 데이터가 바뀌면 화면이 따라 바뀌게 구성한다.

문제 04

부품을 매번 만들 수 없다

다른 사람이 만든 도구와 라이브러리를 가져다 쓰고 싶다.

→

Node.js와 npm

Node.js로 브라우저 밖에서도 JavaScript 도구를 실행하고, npm으로 패키지를 설치·관리한다.

문제 05

개발용 파일을 브라우저가 바로 못 쓴다

여러 파일, 최신 문법, 개발 편의 기능을 배포 가능한 형태로 바꿔야 한다.

→

빌드

도구에 따라 코드를 변환하고 묶고 줄인다. 모든 웹 프로젝트에 빌드가 필수인 것은 아니다.

컴포넌트와 상태, 딱 두 문장

컴포넌트 = 반복 가능한 배우

문서 카드 틀 하나를 만들고 제목과 태그만 바꿔 여러 장을 그립니다. React가 없어도 함수로 같은 원리를 연습할 수 있습니다.

상태 = 화면의 현재 기억

입력값, 선택된 태그, 현재 카드 목록처럼 화면이 반응하기 위해 기억하는 값입니다. 영구 저장과는 다릅니다.

Week 8 표현 보충 — 당시 “Node.js = JavaScript의 서버 버전”이라고 간단히 배웠습니다. 더 정확히는 브라우저 밖에서 JavaScript를 실행하는 런타임입니다. 서버를 만들 때도 쓰고, Vite 같은 개발·빌드 도구를 돌릴 때도 씁니다.

03 · FROM CODE TO PIXELS

브라우저는 코드를 바로 보여주지 않는다

브라우저는 HTML과 CSS를 읽어 내부 구조를 만들고, 화면에 보일 것을 고른 뒤 크기와 위치를 계산하고 픽셀로 칠합니다. 실제 과정은 더 세밀하지만 오늘은 네 단계로 기억하면 충분합니다.

파싱

HTML→DOM, CSS→CSSOM이라는 나무 구조를 만든다.

렌더 트리

구조와 스타일을 합쳐 실제 표시할 요소를 고른다.

레이아웃

각 요소의 크기와 화면 속 위치를 계산한다.

페인트

텍스트·색·테두리 등을 실제 픽셀로 그린다.

리플로우는 화면이 바뀐 뒤 크기와 위치를 다시 계산하는 일입니다. 변화가 있을 때마다 무조건 나쁜 것은 아니지만, 큰 화면에서 너무 자주 일어나면 버벅임의 원인이 될 수 있습니다.

NEW 개발자도구 Elements에서 글자를 바꾸는 것은 서버의 HTML 파일을 수정하는 일이 아닙니다. 공연 중 소품을 잠깐 바꾼 것처럼, 현재 탭의 DOM만 바뀝니다. 새로고침하면 원래대로 돌아옵니다.

04 · WHO DRAWS THE PAGE?

누가 화면을 완성해서 보내는가

용어	무슨 뜻인가	주의할 점
MPA	페이지 이동 때 서버에서 새 문서를 받아 전체 화면을 표시한다.	방식 자체가 느리다고 단정할 수는 없다.
CSR	브라우저의 JavaScript가 화면을 그리거나 갱신한다.	초기 로딩·검색 노출은 구현에 따라 달라진다.
SPA	첫 진입 후 필요한 데이터와 코드로 현재 페이지 영역을 바꾸며 이동한다.	SPA는 앱 구조, CSR은 렌더링 위치를 가리켜 같은 말은 아니다.
SSR	서버가 요청 시점에 HTML을 만들어 보낸다.	매 요청을 반드시 전부 새로 계산한다는 뜻은 아니다.
하이드레이션	서버에서 받은 HTML에 JavaScript의 이벤트 처리를 연결해 상호작용 가능하게 한다.	“물을 붓는다”는 비유는 기억용이며 실제로는 이벤트 연결 과정이다.
Next.js	React 기반 프레임워크로 서버와 클라이언트 렌더링 방식을 함께 구성할 수 있다.	페이지마다 SSR/CSR 둘 중 하나만 고르는 도구로 한정하면 부정확하다.

05 · HANDS ON

팀 문서 보관소의 첫 화면

20~25분 · 각자 실습

이번 주부터 하나의 앱을 이어서 키웁니다. 오늘은 화면과 임시 상태까지만 만듭니다. 로그인·서버·영구 저장은 다음 단계입니다.

개발자도구로 렌더링 흔적 보기 · 7분
현재 페이지에서 F12를 누릅니다. Elements에서 제목 글자를 바꾸고, Computed에서 최종 스타일을 확인하고, Network에서 HTML·CSS·JavaScript 요청을 찾습니다. 새로고침 후 글자가 돌아오면 성공입니다.
기존 방식대로 계획부터 확인 · 3분
복습 · W9·W10 AI 코딩 도구에 먼저 “계획을 보여주고 승인 후 만들어줘”라고 요청합니다. 계획에 index.html, styles.css, script.js가 있는지 봅니다.

아래 프롬프트로 첫 화면 만들기 · 12분

복사해서 AI 코딩 도구에 붙여넣기

'팀 문서 보관소'라는 웹 페이지를 만들어줘.

- 먼저 구현 계획을 보여주고, 내가 승인하면 파일을 만들어줘.
- index.html, styles.css, script.js 세 파일만 사용해. 프레임워크는 쓰지 마.
- 화면 위에는 '팀 문서 보관소' 제목을 넣어줘.
- 그 아래에는 문서 제목과 태그를 입력하고 추가하는 폼을 넣어줘.
- 아래에는 문서 목록을 카드 형태로 보여줘.
- 서버가 없으므로 문서 목록은 JavaScript 배열에 임시로 저장해줘.
- 문서 카드 하나를 만드는 함수를 만들고, 배열을 반복해서 화면에 그려줘.
- 문서를 추가하면 새 카드가 바로 나타나게 해줘.
- 어두운 배경과 읽기 쉬운 한국어 글꼴을 사용하고 모바일에서도 잘 보이게 해줘.
- 마지막에 실행 방법과 확인할 항목을 설명해줘.

세 가지를 말로 설명하며 확인 · 3분
파일 역할, 카드 함수가 컴포넌트 원리인 이유, 새로고침하면 목록이 사라지는 이유를 짝에게 설명합니다.

파일 3개HTML·CSS·JS 역할이 분리됨

추가 즉시 표시배열이라는 상태가 화면을 바꿈

새로고침 시 초기화아직 영구 저장소가 없으므로 정상

막힐 때

증상	확인할 것
화면이 하얗다	개발자도구 Console의 첫 번째 빨간 오류를 복사해 AI에게 전달한다.
스타일이 적용되지 않는다	`index.html`에 `styles.css`를 연결한 `<link>`가 있는지 확인한다.
추가 버튼이 반응하지 않는다	`script.js` 연결 경로와 Console 오류를 확인한다.
AI가 React로 만들었다	프롬프트의 “프레임워크는 쓰지 마”를 다시 강조하고 3파일로 수정하도록 요청한다.

06 · DO NOT MIX THESE

헷갈리기 쉬운 것만 바로잡기

“정적 사이트는 움직이지 않는다”

정적은 배포된 파일이 요청마다 서버에서 새로 만들어지지 않는다는 뜻입니다. JavaScript로 충분히 움직이고 반응할 수 있습니다.

“package.json이 있으면 무조건 빌드한다”

package.json은 프로젝트 정보와 스크립트·의존성 명세입니다. 실제 빌드 여부는 scripts와 사용 도구를 확인해야 합니다.

“상태가 있으면 저장된 것이다”

상태는 현재 화면이 기억하는 값입니다. 새로고침 뒤에도 남기려면 Local Storage, 데이터베이스 같은 별도 저장소가 필요합니다.

“SPA와 CSR은 같은 말이다”

자주 함께 쓰이지만 기준이 다릅니다. SPA는 페이지 전환 구조, CSR은 화면을 그리는 위치에 관한 말입니다.

“API 비유가 웨이터인지 무전기인지 모르겠다”

둘 다 맞습니다. 식당 전체 시스템에서는 주문을 전달하는 웨이터, 공연 구조에서는 무대와 백스테이지 사이의 무전기입니다.

07 · NEXT QUESTION

다음 주로 넘기는 질문

오늘 만든 화면은 문서를 추가하면 바로 바뀝니다. 하지만 새로고침하면 사라지고, 누가 접속해도 처음에는 같은 목록을 봅니다.

사용자마다 다른 문서 목록을 주고, 새로고침 뒤에도 남게 하려면 무엇이 필요할까?

다음 주에는 백스테이지인 서버가 요청을 받고 JSON으로 응답하는 과정을 만들고, Week 3에서 배운 API를 실제 문서 보관소에 연결합니다.

선택 과제

오늘 만든 3파일을 개인 저장소 team-docs-{이니셜}에 커밋합니다.
AI에게 “이 프로젝트를 React로 다시 만들고, 달라진 파일과 실행 방법을 설명해줘”라고 요청합니다.
package.json의 scripts를 찾아 dev와 build가 각각 무엇을 하는지 비교합니다.

웹은 원래 문서였다