https://www.youtube.com/watch?v=ED2rOHM1od0
# 1. 이건 꼭 알아야 한다[^1]
[? 질문] 웹 개발에서 프론트엔드/백엔드는 무엇이며, 각각이 담당하는 역할은 무엇인가[^2]
[= 답] 웹사이트는 크게 **프론트엔드(클라이언트, 사용자가 보는 영역)**와 **백엔드(서버, 사용자가 보지 못하는 영역/데이터 처리)**로 나뉘며, 프론트는 화면을 구성·표현하고 백은 데이터를 처리·가공하며 통신을 담당한다.[^2]
[? 질문] HTML/CSS/JavaScript는 프론트엔드에서 각각 어떤 의미와 역할을 가지는가[^3]
[= 답] HTML은 웹페이지의 **뼈대(골격)**, CSS는 **살/치장(디자인)**, JavaScript는 **동작/로직(동적 변화, 애니메이션 등)**을 담당하는 것으로 설명한다.[^3]
[? 질문] 프레임워크는 왜 필요하고, 웹 개발에서 어떤 이점이 있는가[^4]
[= 답] 처음부터 모든 것을 “밑바닥부터” 만들면 시간과 노력이 많이 들기 때문에, 미리 환경·구조를 갖춰 제공하는 **프레임워크(패키지/세트)**를 쓰면 개발이 빨라지고, 정해진 구조 덕분에 협업과 유지보수가 쉬워진다.[^4]
[? 질문] 정적 사이트와 SPA(싱글 페이지 애플리케이션)의 차이, 그리고 SPA가 나온 이유는 무엇인가[^5]
[= 답] 정적 사이트는 페이지 이동 시마다 HTML/CSS/JS를 **통째로 다시 로드**해 불필요한 데이터 로딩이 발생하는 단점이 있고, 이를 보완하려고 **필요한 부분만 갱신**해 새로고침 없이 내용이 바뀌는 SPA가 등장했다(AJAX 기반 설명).[^^5]
---
# 2. 큰 그림[^6]
이 콘텐츠는 웹 개발을 시작하려는 **완전 초보자**가 “웹 개발이 무엇인지”를 빠르게 잡을 수 있도록, 웹의 기본 구성(프론트/백), 프론트 기술(HTML/CSS/JS), 백엔드 언어, 그리고 **프레임워크**와 **정적 사이트 vs SPA** 개념을 비유와 예시로 풀어 설명한다.[^6] 특히 실무에서 프레임워크가 왜 중요해지는지(구조화, 유지보수, 속도)를 강조하며, SPA 프론트 프레임워크 3대장(Angular/React/Vue)까지 연결해 큰 지도를 제공한다.[^6]
- 웹은 **클라이언트(프론트엔드)**와 **서버(백엔드)**의 역할 분담으로 이해해야 한다.[^7] 각 영역이 “사용자가 보는 것 vs 보지 못하는 것(데이터)”을 기준으로 나뉜다는 관점이 핵심이다.[^7]
- 프론트엔드는 **HTML/CSS/JavaScript** 3요소로 페이지가 구성·표현·동작하며, 백엔드는 여러 언어(JavaScript/Java/PHP/Python 등)로 서버와 데이터 처리를 담당한다.[^8]
- **프레임워크**는 “부대찌개/유부초밥 패키지”처럼 개발 환경을 미리 갖춰줘서 빠르게 만들고, **구조화** 덕분에 협업/유지보수가 쉬워진다.[^9]
---
# 3. 하나씩 살펴보기[^10]
## 3.1 영상의 목적: 완전 초보를 위한 웹 개발 개념 정리[^11]
화자는 인사 후, “웹 개발을 시작해서 웹사이트를 만들고 싶지만 완전 초보인 사람”을 대상으로 **개념 정리**를 해주기 위해 영상을 제작했다고 밝힌다.[^11] 즉 특정 기술 튜토리얼(코딩 실습)보다는, 앞으로 학습을 이어가기 위한 **용어/구조/큰 흐름**을 먼저 잡는 데 목적이 있다.[^11]
- 대상: 웹사이트를 만들고 싶지만 어디서부터 시작해야 할지 모르는 **입문자**[^11]
- 방식: 정의를 나열하기보다 “앞/뒤”, “김밥천국”, “부대찌개 키트” 같은 **비유**로 직관적 이해를 돕는 전개[^12]
## 3.2 웹사이트는 두 영역: 프론트엔드와 백엔드(클라이언트와 서버)[^13]
화자는 웹사이트를 크게 두 가지로 나눈다고 말하며, **프론트엔드**와 **백엔드**를 제시한다.[^13] 그리고 용어를 단순화해 “-end를 빼면 프론트/백”이라고 표현하며, 초보가 단어에서 느끼는 부담을 낮춘다.[^13]
### 3.2.1 프론트엔드 = 클라이언트 = 사용자의 ‘앞’에 있는 것[^14]
화자는 프론트가 “앞(front)”이라는 단어 의미 그대로, **사용자 앞에 있는 것**이라고 설명한다.[^14] 여기서 사용자는 “일반적인 웹 사이트를 사용하는 사용자”로 상정된다.[^14] 따라서 사용자가 실제로 보는 화면, UI, 화면에 나타나는 요소들이 프론트엔드의 영역이라는 인식을 심어준다.[^14]
- [h 프론트엔드는 사용자가 보는 화면/사용자 경험에 직접 닿는 영역이라는 관점]을 제시한다.[^14]
### 3.2.2 백엔드 = 서버 = 사용자가 ‘보지 못하는 뒤’ + 데이터 처리 영역[^15]
프론트의 반대편으로 화자는 “뒤(back)”를 들며, 사용자가 볼 수 없는 곳을 다루는 것이 백엔드라고 말한다.[^15] 그리고 그 핵심을 **데이터와 관련된 부분**이라고 특정한다.[^15] 즉 데이터를 “핸들링(처리, 가공)”하는 분야가 백엔드이며, 이를 곧 **서버**라고 연결한다.[^15]
- 백엔드의 초점: 데이터 처리/가공, 서버에서 일어나는 일[^15]
- 사용자의 관점에서는 “보이지 않는 곳”이지만 서비스 동작에 필수인 영역[^15]
### 3.2.3 김밥천국 비유로 이해하는 클라이언트/서버[^16]
화자는 예전에 올렸다는 설명을 끌어와, **김밥천국** 비유를 다시 사용한다.[^16]
- 김밥천국에 와서 주문하고 서비스를 받는 **손님 = 클라이언트**[^16]
- 주방에서 요리하는 사람, 음식을 가져다 주는 역할을 하는 쪽을 **서버**로 비유[^16]
이 비유의 의도는 “요청하는 쪽(손님/클라이언트)”과 “요청을 처리해 결과를 제공하는 쪽(주방·서빙/서버)”의 관계를 직관적으로 각인시키는 데 있다.[^16]
> [!NOTE] 비유가 전달하는 핵심 구조
> 클라이언트는 “요청하고 받는 쪽”, 서버는 “요청을 처리해서 결과를 돌려주는 쪽”이라는 역할 분담으로 웹을 이해하라는 메시지다.[^16]
### 3.2.4 프론트/백을 나누는 이유: 작업 대상이 다르기 때문[^17]
화자는 프론트엔드와 백엔드가 “다른 이유”는 결국 **작업할 것들이 다르기 때문**이라고 말한다.[^17] 같은 ‘웹 개발’ 범주에 있어도 다루는 대상(화면 vs 데이터/서버)이 달라, 역할/기술 스택이 달라진다는 토대를 깐다.[^17]
## 3.3 프론트엔드의 구성 요소: HTML, CSS, JavaScript[^18]
화자는 사용자가 사이트를 접속했을 때 프론트엔드에서 대표적으로 다루는 것이 **HTML, CSS, JavaScript**라고 제시한다.[^18] 그리고 각 요소를 인체 비유처럼 설명해 기능을 분리해 이해시키려 한다.[^18]
### 3.3.1 HTML = 뼈대/골격[^19]
HTML을 “어깨뼈”라는 표현을 쓰며, 웹사이트에서 **보이는 뼈대**, 즉 **골격**이라고 설명한다.[^19] 이는 텍스트/이미지/버튼 등 요소가 어떤 구조로 배치되는지의 “틀”에 해당한다는 의미로 전달된다.[^19]
- HTML의 역할(영상의 설명): 화면 구성의 기본 구조/골격[^19]
### 3.3.2 CSS = 살/치장(디자인)[^20]
CSS는 뼈대에 붙는 “살”이라고 하거나 “이쁘게 치장하는 것”이라고 설명한다.[^20] 즉 색, 폰트, 배치 스타일, 꾸밈 요소 등 시각적 표현을 담당한다고 이해시키는 흐름이다.[^20]
- CSS의 역할(영상의 설명): 디자인/스타일링, 보기 좋게 꾸미기[^20]
### 3.3.3 JavaScript = 움직임/동적 로직[^21]
JavaScript는 “움직이고 하는 것”, “애니메이션 처리”, “동적으로 움직이게 하거나 로직이 돌아가도록 하는 부분”이라고 설명한다.[^21] 또한 CSS로도 애니메이션을 할 수는 있지만, JavaScript는 보다 일반적인 “동작/로직”의 담당으로 포지셔닝한다.[^21]
- JS의 역할(영상의 설명): 동적 변화, 인터랙션, 로직 처리[^21]
> [!TIP] 초보자가 3요소를 외울 때의 암기 프레임
> HTML=구조(골격), CSS=표현(치장), JS=동작(로직)으로 분리해서 이해하면 이후 프레임워크 학습에서도 혼동이 줄어든다는 방향으로 설명이 이어진다.[^19]
## 3.4 백엔드(서버사이드) 언어: 서버/데이터 통신과 처리[^22]
화자는 백엔드를 “서버사이드”라고 부르며, 서버에서 **데이터 통신**을 하고 처리하는 부분이라고 말한다.[^22] 그리고 백엔드 언어의 예시를 나열한다.[^22]
### 3.4.1 백엔드에도 JavaScript가 있다 (과거 vs 현재)[^23]
화자는 “원래 옛날에는 (백엔드에) 자바스크립트가 없었는데 이제는 자바스크립트로도 백엔드 웹 서버를 만들 수 있다”고 말한다.[^23] 즉 JavaScript가 브라우저 안에서만 쓰이는 언어가 아니라, 서버에서도 사용 가능해졌다는 관점을 전달한다.[^23]
- 요지: JavaScript는 프론트뿐 아니라 백엔드에서도 사용 가능[^23]
### 3.4.2 백엔드 언어 예시 나열: Java, Go, PHP, Python 등[^24]
화자는 백엔드 언어로 다음을 언급한다.[^24]
- JavaScript[^23]
- Java[^24]
- Go(고 랭귀지)[^24]
- PHP[^24]
- Python[^24]
- (그 외 Swift 등도 “여러 가지 더” 있다고 언급)[^24]
나열의 목적은 특정 언어를 추천하기보다, 백엔드가 단일 언어로 고정되지 않고 다양한 선택지가 있음을 알려주는 데 있다.[^24]
## 3.5 프레임워크란 무엇인가: “부대찌개/유부초밥 패키지” 비유[^25]
화자는 프레임워크를 설명하기 위해 요리 상황을 든다.[^25]
### 3.5.1 ‘처음부터 다 만들기’의 부담: 재료를 일일이 준비하는 문제[^26]
예로 “부대찌개를 만들려고 할 때”를 상정한다.[^26] 햄, 당면, 육수 등 재료를 하나하나 사서 준비하는 것은 번거롭고 시간이 많이 걸린다는 점을 강조한다.[^26] 이는 개발에서 라이브러리 설정, 기본 구조 설계, 공통 기능 구현 등을 매번 처음부터 하는 부담에 대응된다.[^26]
### 3.5.2 이미 세팅된 키트를 사서 끓이기만 하는 것 = 프레임워크[^27]
마트에서 “부대찌개가 이미 준비/세팅되어 있는 것”을 사면, 재료와 육수가 갖춰져 있어 “끓이기만 하면” 된다는 설명을 한다.[^27] 화자는 이 “미리 준비된 세트”가 바로 프레임워크라고 말한다.[^27]
또 다른 비유로 “유부초밥 패키지”를 든다.[^28] 원래는 밥도 하고 양념도 준비해야 하지만, 패키지를 사면 비벼서 바로 만들 수 있듯이, 프레임워크는 개발자가 바닥부터 세팅하지 않도록 환경을 제공한다고 강조한다.[^28]
- 프레임워크 정의(영상의 설명):
- [= 개발에 필요한 환경/구조를 미리 세팅해 제공하는 것]이라는 결론[^27]
- “처음부터 전부 다” 만들 필요를 줄여줌[^28]
> [!IMPORTANT] 프레임워크를 ‘편의성’만으로 보지 말라는 암시
> 단순히 편해서가 아니라, 뒤에서 설명하듯 **구조화**와 **협업/유지보수**에 의미가 있다는 논지로 연결된다.[^29]
## 3.6 왜 프레임워크가 중요한가: 실무 사용, 구조화, 유지보수, 개발 속도[^30]
화자는 “왜 프레임워크 이야기를 하느냐”를 직접 묻고, 웹 개발 시작에서 프레임워크가 **굉장히 중요**하다고 강조한다.[^30] 이유는 다음과 같이 전개된다.[^30]
### 3.6.1 회사(실무)에서 프레임워크를 사용한다[^30]
프레임워크는 개인 프로젝트만의 선택이 아니라, “회사에서도 프레임워크를 사용한다”고 말한다.[^30] 이는 학습 방향을 잡는 초보에게 “프레임워크를 알아야 실무와 연결된다”는 메시지로 기능한다.[^30]
### 3.6.2 프레임워크는 ‘구조’가 있다 → 다른 사람 작업/유지보수에 유리[^31]
화자는 프레임워크 자체가 “원래 구조를 갖고” 있다고 말한다.[^31] 이 구조 덕분에:
- 다른 사람이 작업하기 쉬움[^31]
- 이미 같은 프레임워크를 써본 사람은 프로젝트에 들어와서 “아 그거 써봤어” 하며 빠르게 파악 가능[^31]
- 결과적으로 유지보수가 가능해짐[^31]
즉, 프레임워크는 코드 작성의 편의뿐 아니라, 팀 개발에서 중요한 **표준화된 구조**를 제공한다는 점을 강조한다.[^31]
### 3.6.3 개발 시간 단축: “이미 세팅되어 있으니까”[^32]
화자는 프레임워크를 쓰면 개발 시간이 빨라진다고 말한다.[^32] 이유는 앞의 요리 비유로 돌아가 “부대찌개 세트는 끓이면 되니까”라는 방식으로 재강조한다.[^32]
- [h 프레임워크의 효용을 ‘시간 단축’과 ‘구조/유지보수’ 두 축으로 설명]한다.[^31]
## 3.7 프론트엔드/백엔드 프레임워크가 모두 존재한다[^33]
화자는 프레임워크가 한쪽에만 있는 것이 아니라, **프론트엔드 프레임워크도 있고 백엔드 프레임워크도 있다**고 말한다.[^33] 이후 설명은 먼저 백엔드(웹) 프레임워크 쪽 사례를 들고, 그 다음 정적 사이트 vs SPA로 넘어가며, 마지막에 SPA 프론트 프레임워크 3대장을 소개하는 구조로 진행된다.[^33]
## 3.8 백엔드 웹 프레임워크 예시: Express, Laravel, Spring, Django/Flask[^34]
화자는 “백엔드 웹 프레임워크”를 언급하면서, 언어마다 제공하는 프레임워크가 다르다고 설명한다.[^34] 그리고 대표 예시를 나열한다.[^34]
- JavaScript로 서버를 만들 때: **Express**[^35]
- PHP의 웹 프레임워크: **Laravel**, **CodeIgniter** 등[^36]
- Java의 웹 프레임워크: **Spring**[^37]
- Python의 웹 프레임워크: **Django**, **Flask**[^38]
이 파트는 초보가 “언어 = 프레임워크 세트”처럼 연결해서 떠올릴 수 있도록 돕는 열거 방식이다.[^34]
> [!NOTE] 영상의 표현 방식
> “내가 어떤 언어로 백엔드를 만들지에 따라 웹 프레임워크가 달라진다”는 연결고리를 만들어, 이후 학습에서 ‘언어만 고르면 끝’이 아니라 ‘프레임워크 생태계’까지 함께 본다는 관점을 준다.[^34]
## 3.9 정적 사이트(일반적 사이트)란 무엇인가: 페이지마다 전체를 로드[^39]
화자는 “정적 사이트”와 “SPA” 개념이 등장한다고 예고한 뒤, 정적 사이트를 먼저 설명한다.[^39] 정적 사이트를 “일반적인 사이트”라고 부르며, 사용자가 웹에서 흔히 경험하는 동작을 기준으로 풀어낸다.[^39]
### 3.9.1 정적 사이트의 사용자 경험: 페이지 전환 시 새 페이지가 그대로 뜸[^40]
예로 네이버 같은 사이트를 켰을 때 “한 페이지가 그대로 나오고”, 다음 버튼을 누르면 “또 한 페이지가 그냥 보이는” 방식이라고 설명한다.[^40] 즉 페이지 단위로 전환되는 전통적 내비게이션을 정적 사이트의 감각으로 제시한다.[^40]
### 3.9.2 정적 사이트에서 브라우저가 받는 구성: HTML/CSS/JS 3종 세트[^41]
화자는 브라우저(크롬/익스플로러 등)에서 보여지는 것이 HTML/CSS/JS이며 “3개가 한 세트로” 사용자에게 전달된다고 말한다.[^41] 그리고 정적 사이트는 페이지를 그때그때 “초기화”해서 계속 보내주는 것이라고 설명한다.[^41]
### 3.9.3 정적 사이트의 핵심 메커니즘: 페이지 이동마다 전체 리로드[^42]
다음 페이지를 누르면:
- HTML 전체 로드[^42]
- CSS 전체 로드[^42]
- JavaScript 전체 로드[^42]
또 다른 버튼으로 다른 페이지로 넘어가도 “몽땅 다” 로드된다는 식으로 반복을 강조한다.[^42] 이 전체 로드는 “클라이언트(프론트엔드)에서 볼 수 있는 것”이 다시 전달되는 것이라고 연결한다.[^42]
## 3.10 정적 사이트의 단점: 불필요한 데이터까지 다시 가져옴[^43]
화자는 “이렇게 되면 어떤 단점이 있을까요?”라고 질문을 던진다.[^43]
[? 질문] 정적 사이트 방식의 단점은 무엇인가[^43]
[= 답] 한 번 이미 봤던 내용도 다시 포함되어 로드되기 때문에, “불러오지 않아도 되는 데이터”까지 한 번에 다 불러오는 **불필요한 데이터 로딩**이 발생한다.[^44]
이 단점 제시는 다음 파트의 SPA 등장 이유로 자연스럽게 연결된다.[^44]
## 3.11 SPA(싱글 페이지 애플리케이션): 부분만 갱신, 새로고침 없이 내용 변경[^45]
정적 사이트 단점을 “보완하기 위해서 나온 것”이 SPA라고 말한다.[^45] 그리고 SPA가 어떤 방식으로 다른지 핵심 차이를 대조로 설명한다.[^45]
### 3.11.1 AJAX를 사용한다는 언급[^46]
화자는 SPA가 **AJAX**라는 기술을 사용한다고 말하며, “그래서 뭔가 되는 건데”라고 표현한다.[^46] 깊은 기술 설명(요청/응답, 비동기 등)을 상세히 파고들기보다는, SPA의 핵심 사용자 경험을 이해시키는 역할로 AJAX를 배치한다.[^46]
### 3.11.2 전체 페이지가 아니라 ‘바꾸고 싶은 부분만’ 가져옴[^47]
정적 사이트는 전체 페이지를 가져온다고 했는데, SPA는 “전체에서 일부분”, 즉 “내가 바꾸고 싶은 부분만 가져오는 것”이라고 말한다.[^47] 이것이 불필요한 데이터 로딩을 줄이는 방향임을 암시한다.[^47]
### 3.11.3 새로고침 없이 페이지는 그대로, 내용만 바뀜[^48]
SPA의 체감 특징으로 다음을 제시한다.[^48]
- 홈페이지가 새로고침되지 않음[^48]
- “홈페이지는 그대로인데 안의 내용은 쏙 바뀐다”[^48]
- 그래서 웹페이지가 새로고침되는 게 아니라 내부 내용들이 계속 바뀌는 방식[^48]
[? 질문] SPA를 한 문장으로 이해하면 무엇인가[^49]
[= 답] 화면(페이지)은 유지한 채, 필요한 부분만 갱신되어 사용자에게는 새로고침 없이 내용이 바뀌는 웹앱 방식이다.[^48]
## 3.12 SPA는 JavaScript로 구현 가능하지만, ‘밑바닥부터’ 만들면 비싸다[^50]
화자는 “물론 자바스크립트를 통해서 SPA를 구현할 수 있다”고 인정한다.[^50] 하지만 곧바로 문제를 제기한다.[^50]
- 처음부터 밑바닥부터 만들면 시간이 오래 걸림[^51]
- 코드 수도 너무 길어짐[^51]
즉 “가능은 하지만 비효율적”이라는 프레이밍으로, 프레임워크 도입의 필요성을 다시 강화한다.[^51]
## 3.13 SPA를 위한 프론트엔드 프레임워크: Angular / React / Vue[^52]
화자는 앞에서 썼던 “포장 부대찌개 세트” 비유를 다시 끌어와, SPA 구현을 쉽게 해주는 **프론트엔드 프레임워크**가 존재한다고 말한다.[^52] 그리고 이 프레임워크들은 JavaScript 기반이라고 명시한다.[^53]
### 3.13.1 유명한 3개: 앵귤러, 리액트, 뷰[^54]
화자는 “유명한 세 개”를 직접 말한다.[^54]
- Angular(앵귤러)[^54]
- React(리액트)[^54]
- Vue.js(뷰 제이에스)[^54]
### 3.13.2 포켓몬 비유: 3대장 중 선택하는 느낌[^55]
화자는 해외에서 포켓몬(불/물/풀) 고르는 느낌에 비유하며, Angular/React/Vue도 비슷하게 “고르는” 느낌이라고 설명한다.[^55] 그리고 색상 비유도 덧붙인다.[^56]
- 앵귤러는 빨간색[^56]
- 리액트는 파란색[^56]
- 뷰는 초록색[^56]
이 비유는 기술 선택의 맥락(입문자가 마주치는 “3대장”)을 가볍게 받아들이게 하면서도, 세 프레임워크가 널리 알려져 있다는 사회적 합의를 전달한다.[^55]
> [!TIP] 초보 학습의 다음 단계(영상이 암시하는 로드맵)
> “SPA 개념 이해 → 자바스크립트 기반 SPA 프레임워크 3대장 인지”까지 오면, 이후엔 셋 중 하나를 골라 학습하는 흐름으로 자연스럽게 이어진다.[^54]
## 3.14 마무리 정리: 프론트/백, 언어, 프레임워크, 정적 vs SPA[^57]
화자는 마지막에 “다시 한번 정리”를 한다며, 영상에서 다룬 내용을 항목처럼 되짚는다.[^57]
- 웹 개발은 프론트엔드와 백엔드, 즉 클라이언트와 서버로 나뉜다.[^58]
- 프론트엔드는 사람들 앞(사용자 앞)에 있는 영역이라 프론트라고 부른다.[^58]
- 반대로 데이터를 핸들링하는 부분은 서버/백엔드다.[^58]
- 프론트엔드는 HTML/CSS/JavaScript로 웹페이지를 보여준다.[^59]
- 백엔드 언어는 JavaScript, Java, PHP, Python 등이 있다.[^59]
- 처음부터 만들기 어렵기 때문에 “이미 만들어진 것”을 제공하는 프레임워크가 존재한다.[^60]
- 프레임워크로 만들게 되는 것을 정적 사이트로 설명했고, 정적 사이트 단점을 보완하려 SPA가 나왔다.[^61]
- SPA를 위한 프론트엔드 프레임워크는 JavaScript 기반이며 Angular/React/Vue가 대표다.[^62]
또한 설명이 어려울 수 있다며, 이해가 안 되면 카카오톡 채널로 문의하라고 안내하며 마무리 인사를 한다.[^63]
---
# 4. 핵심 통찰[^64]
1. 웹 개발을 이해하는 출발점은 기술 목록이 아니라 **역할 분담(클라이언트 vs 서버)**이라는 구조를 먼저 잡는 것이다.[^13]
- 프론트/백은 “앞/뒤”라는 언어 감각으로도 직관화할 수 있다는 점을 콘텐츠가 반복해서 활용한다.[^14]
2. 프론트엔드 3요소(HTML/CSS/JS)는 각각 **구조-표현-동작**으로 분해해 이해해야 이후 프레임워크 학습에서도 혼동이 줄어든다.[^18]
3. 프레임워크는 편의 도구가 아니라, 실무에서 중요한 **구조화/표준화**를 제공해 협업과 유지보수를 가능하게 만든다는 실용적 이유가 크다.[^31]
4. 정적 사이트와 SPA의 구분은 “페이지 이동 때 무엇을 다시 받느냐(전체 vs 부분)”로 이해하면 된다.[^42]
- 정적 사이트의 “전체 재로딩”은 불필요 데이터 로딩이라는 비용을 낳고, 그 비용을 줄이려 SPA가 등장한다는 인과를 제시한다.[^44]
5. SPA는 JavaScript로 직접 구현할 수 있지만, 밑바닥부터 만들면 시간/코드가 커져 프레임워크로 산업 표준이 형성되었다는 흐름을 보여준다.[^51]
- 실행 시사점:
- 웹 입문자는 “SPA의 사용자 경험(새로고침 없이 내용 변경)”을 먼저 체감하고[^48]
- 그 다음 Angular/React/Vue 중 하나를 골라 프레임워크 학습으로 연결하는 것이 자연스러운 다음 단계다.[^54]
---
# 5. 헷갈리는 용어 정리[^65]
- **프론트엔드(Front-end)**: 사용자가 직접 보는 화면/인터페이스 영역(클라이언트 영역)으로 설명된다.[^14]
- **백엔드(Back-end)**: 사용자가 직접 보지 못하는 영역으로, 데이터 처리/가공 및 서버에서의 동작을 담당한다고 설명된다.[^15]
- **클라이언트(Client)**: 서비스를 요청하고 화면을 보는 사용자 측(김밥천국 비유에서 손님)으로 설명된다.[^16]
- **서버(Server)**: 요청을 받아 처리하고 결과를 제공하는 측(김밥천국 비유에서 주방/서빙 역할)으로 설명된다.[^16]
- **HTML**: 웹페이지의 뼈대/골격으로 비유된다.[^19]
- **CSS**: 웹페이지를 꾸미는 살/치장(디자인)으로 비유된다.[^20]
- **JavaScript**: 화면을 동적으로 움직이게 하거나 로직을 실행하는 역할로 설명된다.[^21]
- **프레임워크(Framework)**: 개발에 필요한 환경/구조를 미리 세팅해 둔 “패키지/세트(부대찌개·유부초밥 패키지 비유)”로 설명된다.[^27]
- **정적 사이트(Static site)**: 페이지 이동 시 HTML/CSS/JS를 포함해 페이지를 통째로 다시 로드하는 일반적 방식으로 설명된다.[^42]
- **SPA(Single Page Application)**: 전체 페이지를 새로 로드하지 않고 필요한 부분만 바꿔, 새로고침 없이 내용이 바뀌는 방식으로 설명된다.[^48]
- **AJAX**: SPA에서 부분 갱신을 위해 사용되는 기술로 언급된다.[^46]
---
---
## 참고(콘텐츠 정보)[^66]
- 제목: 웹개발 개념정리 / 초보개발자 / 프론트앤드 / 백엔드 / 프레임워크[^66]
- 채널: 개발하는 정대리[^66]
- 길이: 11분 26초[^66]
- 링크: https://www.youtube.com/watch?v=ED2rOHM1od0[^66]
- 제공된 키워드: 초보개발자, 프론트앤드, 백엔드, 클라이언트, 서버[^66]
---
[^1]: @[00:05]~@[00:15] "웹 개발을 시작... 완전초보... 개념 정리" 및 영상 전체가 개념 정리를 목표로 전개됨.
[^2]: @[00:19]~@[01:44] "웹사이트는 크게 두 가지... 프론트엔드... 백엔드... 클라이언트... 서버... 데이터..."
[^3]: @[01:57]~@[02:41] "html... 뼈대... css... 살... 자바스크립트... 움직이고... 로직..."
[^4]: @[03:19]~@[05:22] 부대찌개/유부초밥 패키지 비유로 프레임워크 정의, 실무 중요성/유지보수/속도 설명.
[^5]: @[06:34]~@[08:47] 정적 사이트 동작(전체 로드)과 단점, SPA(부분만 갱신, 새로고침 없음) 설명.
[^6]: @[00:05]~@[11:04] 영상 전체 흐름(프론트/백 → 언어 → 프레임워크 → 정적 vs SPA → 프론트 프레임워크 3대장).
[^7]: @[00:19]~@[01:44] 프론트=사용자 앞, 백=사용자 뒤/데이터, 클라이언트/서버 대응 설명.
[^8]: @[01:57]~@[03:17] 프론트 기술 3요소 및 백엔드 언어들 나열.
[^9]: @[03:19]~@[05:17] 프레임워크를 ‘이미 준비된 세트’로 비유, 구조화/유지보수 언급.
[^10]: @[00:00]~@[11:20] 영상이 개념을 순차적으로 전개하는 전체 구성.
[^11]: @[00:05]~@[00:15] "웹 개발... 완전초보... 개념 정리... 영상 제작"
[^12]: @[01:07]~@[01:22] 김밥천국 비유, @[03:19]~@[04:35] 부대찌개/유부초밥 비유.
[^13]: @[00:19]~@[00:29] "웹사이트는 크게 두 가지... 프론트엔드... 백엔드..."
[^14]: @[00:29]~@[00:45] "프론트... 사용자의 앞... 프론트엔드"
[^15]: @[00:49]~@[01:44] "사용자가 보지 못하는 곳... 데이터... 처리/가공... 서버"
[^16]: @[01:03]~@[01:22] 김밥천국 손님=클라이언트, 주방/서빙=서버 비유.
[^17]: @[01:53]~@[02:06] "프론트엔드... 백... 작업할 것들이 다르다"
[^18]: @[01:57]~@[02:06] "html css 자바스크립트..."
[^19]: @[02:06]~@[02:12] "html은... 뼈대... 골격"
[^20]: @[02:12]~@[02:21] "css는... 살... 이쁘게 치장"
[^21]: @[02:21]~@[02:41] "자바스크립트... 움직이고... 동적으로... 로직"
[^22]: @[02:41]~@[02:49] "백엔드 즉 서버사이드... 데이터통신..."
[^23]: @[02:49]~@[02:58] "옛날에는... 자바스크립트... 이제는... 백엔드 웹 서버"
[^24]: @[03:03]~@[03:17] "자바... 고... php... 파이썬... 스위프트..."
[^25]: @[03:19]~@[04:44] 요리 비유로 프레임워크 도입.
[^26]: @[03:26]~@[03:39] 재료를 일일이 사면 힘들고 시간 많이 걸림.
[^27]: @[03:44]~@[04:09] 이미 준비된 부대찌개 세트=프레임워크, 끓이기만 하면 됨.
[^28]: @[04:16]~@[04:35] 유부초밥 패키지 비유.
[^29]: @[04:48]~@[05:17] 프레임워크가 회사에서 중요, 구조화/유지보수 연결.
[^30]: @[04:48]~@[05:06] "웹 개발 시작할 때 프레임워크 굉장히 중요... 회사에서도 사용"
[^31]: @[05:06]~@[05:17] "구조... 다른 사람이 작업... 유지보수"
[^32]: @[05:17]~@[05:34] "개발 시간도 빨라... 이미 세팅"
[^33]: @[05:37]~@[05:41] "프론트엔드 프레임워크도 있고 백엔드 프레임워크도"
[^34]: @[05:53]~@[06:29] 언어마다 프레임워크 다름 + 예시 나열.
[^35]: @[06:02]~@[06:11] "자바스크립트... 익스프레스"
[^36]: @[06:11]~@[06:18] "php... 라라벨... 코드이그나이터"
[^37]: @[06:18]~@[06:22] "자바... 스프링"
[^38]: @[06:22]~@[06:29] "파이썬... 장고... 플라스크"
[^39]: @[06:34]~@[06:48] "정적 사이트랑 spa... 정적 사이트는 일반적인 사이트"
[^40]: @[06:48]~@[06:58] "네이버... 한 페이지... 다음 버튼... 또 한 페이지"
[^41]: @[07:02]~@[07:23] "html css 자바스크립트... 3개가 한 세트"
[^42]: @[07:23]~@[07:36] 페이지마다 html/css/js 전체 로드 반복 설명.
[^43]: @[07:45]~@[07:54] "단점이 있을까요"
[^44]: @[07:54]~@[07:59] "불필요한 데이터... 불러오지 않아도 되는 데이터도... 다 불러"
[^45]: @[08:06]~@[08:12] "보완하기 위해서 나온게 SPA"
[^46]: @[08:12]~@[08:18] "에이젝스(AJAX) 기술"
[^47]: @[08:22]~@[08:24] "전체... 아니라... 일부분... 바꾸고 싶은 부분만"
[^48]: @[08:24]~@[08:47] "새로 고침... 되지 않고... 내용은 바뀜"
[^49]: @[08:37]~@[08:40] "싱글 페이지 애플리케이션"
[^50]: @[08:47]~@[08:52] "자바스크립트를 통해서... 구현"
[^51]: @[08:52]~@[09:02] "밑바닥부터... 시간 오래... 코드 수도 길어져"
[^52]: @[09:02]~@[09:16] "싱글 페이지 애플리케이션을 위한 프레임워크"
[^53]: @[09:16]~@[09:19] "언어는 자바스크립트"
[^54]: @[09:19]~@[09:46] "앵귤러 리액트 뷰"
[^55]: @[09:24]~@[09:35] 포켓몬 선택 비유.
[^56]: @[09:35]~@[09:40] 색상 비유(빨강/파랑/초록).
[^57]: @[10:02]~@[11:04] "다시한번 정리를 하자면..." 정리 파트.
[^58]: @[10:02]~@[10:18] "프론트엔드/백엔드... 클라이언트/서버... 앞/뒤... 데이터 핸들링"
[^59]: @[10:18]~@[10:35] 프론트=HTML/CSS/JS, 백엔드 언어 나열.
[^60]: @[10:35]~@[10:45] "처음부터 만들게 되면 너무 힘들다... 프레임워크"
[^61]: @[10:45]~@[10:55] "정적 사이트... 단점 보완... SPA"
[^62]: @[10:55]~@[11:04] "SPA 프론트엔드 프레임워크... 자바스크립트... 앵귤러/리액트/뷰"
[^63]: @[11:07]~@[11:20] "어려울수도... 카카오톡 채널 문의... 감사"
[^64]: @[00:19]~@[11:04] 전체 주장 흐름(역할 분담→3요소→프레임워크 효용→정적 vs SPA→3대장)에서 도출.
[^65]: @[00:19]~@[10:55] 용어들이 직접 정의/비유로 등장하는 구간들 종합.
[^66]: 사용자 제공 메타데이터(제목/채널/길이/링크/키워드) 및 영상 전반.