11월 3일 학습일지

오늘 공부시간 : 6시간

프론트앤드의 역사

1. 왜 프론트앤드라는 이름이 붙었을까?

프론트엔드는 말그대로 fornt :앞 , end :끝 말로 사용자와 마주하는 제일 앞쪽 부분이라는 뜻이다.

웹에서는 화면,글자,버튼과 각 요소들의 반응을 담당한다.

2번~5번에대한 답은 프론트엔드의 역사를 순서대로 이야기면서 각 단계마다 이야기하겠다.

프론트엔드는 지난번 웹과 브라우저의 역사에서 이어진다.

웹은 문서들을 링크로 연결하게 해주었고 -> 브라우저는 문서를 화면에 그려주었다.

프론트엔드의 이야기는 여기서부터 시작된다.

<CSS>

1) 왜 "CSS"이라는 이름이 붙었을까?

CSS는 Cascading Style Sheets의 약자디.

Cascading: 여러 규칙이 겹칠 때, 정해진 우선순위에 따라 적용된다는 뜻 (폭포수).

Style: 글자 색·크기·간격처럼 화면을 꾸미는 규칙.

Sheets: 그 규칙들을 모아 놓은 문서.

->쉽게 이야기하면 규칙에는 우선순위가 있고, 더 구체적인 규칙이 이긴다.

->여러곳에서 내려온 디자인 규칙을 우선순위에 따라 정리하는 방식이 핵심이다.

2) 누가 · 언제 · 왜 만들었을까?

누가 :CSS를 처음 제안한 사람은 노르웨이의 호콘 비움 리

언제 :1994년 처음 제안되었고, 1996년 첫 공식표준인 CSS1을 발표했다.

왜? : 웹문서의 HTML은 문서의 구조만 표현하고,

CSS는 글꼴,색,배치같은 꾸미는 방법을 따로 분리해서 관리하고자 만들었다,

3) 이게 나오기 전엔 어떤 불편함이 있었을까?

초창기 브라우저는 HTML 안에 꾸밈 명령을 하나하나 직접 넣었다.

여기서 큰 불편함이 발생하였다. 문서양이 많아졌을때

모든 문서 안의 디자인을 일괄적으로 변경하려면, 코드하나씩 일일히 수정을 해야했다.

굉장한 비효율이다.

4) 이게 나와서 뭐가 편해졌을까?

웹페이지의 내용은 건드리지 않고, 디자인만 한꺼번에 일괄적으로 바꿀수 있게 되어서

수정시간이 크게 줄었다.

5)기존의 불편함을 어떻게 해결했을까?

HTML에 반복하던 꾸밈 지시를 별도 CSS로 분리하고, 여러 페이지가 같은 규칙을 공유하게 했디.

<JavaScript>

1) 왜 "JavaScript"이라는 이름이 붙었을까?

JavaScript라는 이름은 당시 주목받던 언어인 ‘Java’와 연결해 홍보하려고 붙였다.

Mocha(모카) → LiveScript → JavaScript

2) 누가 · 언제 · 왜 만들었을까?

누가: 넷스케이프 소속 개발자인 브랜던 아이크

언제: 1995년에

왜? : 웹페이지가 내용만 보여주는데서 나아가, 사용자의 행동에 반응하게 하려고 만들었다.

-> HTML만으로도 글, 사진, 링크 입력칸을 만들 수있었지만 ,입력 내용을 확인하려면

서버에 보내고 결과를 받아야함.

->서버에서 확인하면: 제출 → 서버로 전송 → “비밀번호를 입력하세요”라는 페이지를 받음.

JavaScript로 확인하면: 현재 화면에서 바로 “비밀번호를 입력하세요”라고 보여 줌.

궁극적으로 서버에 매번 요청하지 않아도 브라우저에서 사용자의 행동에 바로 반응하도록 한 것이다.

3) 이게 나오기 전엔 어떤 불편함이 있었을까?

자바스크립트가 나오기 전에는 웹페이지 안에서 사용자 행동에 즉각 반응하는 기능을 만들기 어려웠다.

예를들어 주문수량에서 수량을 바껐을때 서버에 보낸 계산결과를 가져오는동안 바로 바뀌지 않았다.

이같은 문제로 업무나 행정에 여러 오류가 많이 발생했다

한마디로, 작은 일을 처리할때도 기다리거나 페이지를 다시 불러와야해서 사용흐름도 끊기고

결과적 오류도 많이 발생했다.

4) 이게 나와서 뭐가 편해졌을까?

사용자가 웹페이지에서 작업할때, 기다리는 시간이 줄고 실수를 할 확률이 줄었다.

쉽게말해, 화면안에서 바로 확인하고 작업을 이어갈수 있게 되었다.

5)기존의 불편함을 어떻게 해결했을까?

웹페이지에 JavaScript로 "사용자가 이렇게 행동하면 이렇게 처리하라" 는 규칙을 넣었다.

그 결과 서버에 보내야 처리할수 있던 간단한 일들은 브라우저에서 바로 처리할수 있게 했다.

매번 서버의 응답을 기다릴 필요가 없어졌다.

여기까지 HTML -> CSS -> JavaScript 의 이야기였다.

이때 "1차 브라우저 전쟁"이 일어났다.

쉽게말해 여러 브라우저들이 서로 경쟁하며 자기 브라우저에서만 되는 기능들을 계속 추가해댔고,

이때문에 표준에서 많이 벗어난 브라우저가 많았다.

그결과 같은 코드를 입력해도 각 브라우저마다 다르게 출력이 되었다.

이를 크로스브라우징 이슈 라고 한다.

개발자들이 화면하나 만들려면 여러 브라우저에 대해 다 공부하고 다 직접 확인하면서 고쳐야 했다.

여기서 이 문제를 해결하기 위해 등장한것이 바로 jQuery다.

<jQuery>

1) 왜 "jQuery"이라는 이름이 붙었을까?

‘JavaScript로 웹페이지에서 원하는 부분을 찾는다’는 의미를 담은 이름이다.

j : JavaScript를 가르킴

Query : 질의하다,찾아내다 라는 뜻으로, " 이페이지에서 이런 버튼을 찾아줘" 처럼 원하는 요소를 찾는걸 말한다.

->찾은 다음에는 "그 버튼을 누르면 메뉴를 열어라"같은 동작을 붙일수도 있다.

2) 누가 · 언제 · 왜 만들었을까?

누가: 존레식

언제: 2005년에 개발하기 시작해서 2006년 1월에 공개

왜? : JavaScript로 웹페이지의 동작을 만드는 일을 더 쉽고 짧게 하려고 만들었다.

3) 이게 나오기 전엔 어떤 불편함이 있었을까?

jQuery가 나오기 전에는 간단한 화면 동작도 코드를 길게 쓰고, (반복할 코드가 많았다)

브라우저마다 따로 맞춰야 하는 불편함이 있었다.

-> 수정과 확인에 시간이 많이 들었다.

4) 이게 나와서 뭐가 편해졌을까?

개발자가 더 적은 코드로 웹페이지의 동작을 만들고, 여러 브라우저에 일일히 맞추는 수고도 줄었다.

그 결과 웹페이지의 제작과 수정이 쉬워지고 빨라졌다.

JavaScript가 웹페이지를 반응하게 해 줬다면, jQuery는 개발자가 그 반응을 더 쉽게 만들게 해 준 것이다.

5)기존의 불편함을 어떻게 해결했을까?

반복해서 쓰던 코드와 브라우저별 처리방법을 제이쿼리 안에 미리 만들어넣어서 해결했다.

그 결과 개발자는 "무엇을 찾아서, 어떤 동작을 할지"만 짧게 적으면 됐다.

즉, 개발자들이 매번 직접 만들던 공통작업을 도구안에 모아두고, 짧은 명령으로 꺼내쓸수있게 해주었다.

<Node.js>

1) 왜 ‘Node.js’라는 이름이 붙었을까?

Node는 ‘연결 지점’, JS는 JavaScript를 뜻한다.

Node.js에서 쓰는 언어와 문법도 자바스크립트다”는 맞지만,

다만 Node.js 자체가 언어인 건 아니다. 자바스크립트를 실행해 주는 프로그램이다.

2) 누가 · 언제 · 왜 만들었을까?

누가: 라이언달

언제 : 2009년

왜? : 네트워크 통신이 만ㅀ은 웹서비스에 맞는, 효율적인 서버를 만들고 싶어서

서버에 특정 자료를 요청하면 기다리는 시간이 길었다.

기다리는동안 담당자가 아무것도 못하고 기다리는건 시간낭비라고 생각했다.

3) 이게 나오기 전엔 어떤 불편함이 있었을까?

이당시 서버 처리 방식에는 파일이나 db의 응답을 기다리는 동안

해당 작업을 맡은 처리 흐름이 묶이는 경우가 많았다.

그래서 동시에 많은 요청을 처리하려면 인력을 늘리거나, 자원을 더쓰거나, 복잡하게 설계해야했다.

4) 이게 나와서 뭐가 편해졌을까?

동시에 많은 요청을 받는 서비스를 만들기 편해졌다.

예를들어 채팅처럼 데이터를 주고받는 서비스가 대표적이다.

5) 기존의 불편함을 어떻게 해결했을까?

기다리는 일은 맡겨두고, 다른 요청들을 처리하도록 만들었다.

다만 한 명이 계산 수천 개를 동시에 하는 마법은 아니다.

긴 계산을 JS에서 계속 돌리면 다른 요청 처리가 막힐 수 있다.

강점은 특히 기다리는 시간을 잘 활용하는 것이다.

<npm>

1) 왜 이런 이름이 붙었을까?

Node Package Manager , 즉 노드 패키지 관리자

다른사람이 만들어 놓은 코드 묶음인 패키지를 가져다 쓸수 있도록 코드와 관련 정보를 묶어 놓은것

역할은 그 코드묶음인 패키지를 가져와 설치하고 관리하는 도구.

예를들어 타이머를 만들고 싶을때 그 패키지를 npm으로 설치해서 쓸수 있다.

2) 누가 · 언제 · 왜 만들었을까?

누가: 아이작 슐루터

언제: 2010년

왜? : 다른 사람이 만든 코드를 쉽게 가져와 함께 사용하도록 만들었다.

당시 Node.js용으로 유용한 코드가 나오고 있었지만,

각각 설치 방법이 다르고 여러 코드를 한 프로젝트에서 함께 쓰기 번거로웠다.

3) 이게 나오기 전엔 어떤 불편함이 있었을까?

다른 사람이 만든 코드 부품을 가져다쓰려면 개발자가 일일이 챙겨야 할 게 많았다.

-직접 찾아서 내려받아야 했다. ->만든 사람의 사이트나 저장소를 찾아 파일을 가져왔다.

-설치 방법이 제각각이었다.-> 어디에 넣고 어떻게 연결하는지 설명을 따로 읽어야 했다.

-딸린 부품도 챙겨야 했다.-> 달력 부품이 다른 날짜 계산 부품을 필요로 하면 별도로 구해야 했다.

버전을 맞추기 번거로웠다.-> 내 컴퓨터와 동료 컴퓨터에 다른 버전이 있으면 작동 결과가 달라질 수 있었어.

즉, 기능을 만드는 일 외에도 코드 부품을 구하고, 연결하고, 서로 맞추는 데 손이 많이 갔던 것이다.

4) 이게 나와서 뭐가 편해졌을까?

-필요한 코드 부품을 쉽게 설치하고 다른 사람과 같은 개발 환경을 맞추기 편해졌다.

-개발이 빨라졌다. 달력·차트 같은 기존 부품을 간단한 명령으로 가져와 사용할 수 있게 되었다.

-설치할 때 빠뜨리는 일이 줄어들었다. 해당 부품에 필요한 다른 부품도 함께 설치해 주었다.

-협업이 편해졌다. 프로젝트의 부품 목록과 버전 기록을 공유해 같은 구성으로 설치하기 쉬워졌다.

-직접 만든 부품을 공유하기 편해졌다. npm에 공개하면 다른 개발자도 쉽게 설치해 사용할 수 있게 되었다.

-코드 부품을 준비하고 관리하는 수고가 줄어들어, 실제 필요한 기능을 만드는 데 더 집중할 수 있게 되었다.

5) 기존의 불편함을 어떻게 해결했을까?

코드 부품을 모아놓는 공용 저장소와, 이를 설치하고 관리하는 공통 도구를 만들어 해결했다.

-부품을 찾고 내려받는 과정을 통일했다.

-함께 필요한 부품도 자동으로 설치하도록 했다. (부품마다 필요한 다름 부품 목록을 기록하고 npm이 그 목록을 읽어 함께 설치하도록 했다.

-프로젝트에 사용하는 부품과 버전을 파일로 기록했다. 다른 개발자도 이 기록을 바탕으로 같은 구성의 부품을 설치할 수 있게 됐다.

즉, 개발자가 직접 챙기던 다운로드,설치 버전관리 과정을 공통된 규칙과 도구로 자동화 시킨것이다.

<React>

1) 왜 이런 이름이 붙었을까?

"반응하다" 라는 뜻으로, 데이터의 변화에 맞춰 화면이 반응한다는 특징에서 착안.

2) 누가 · 언제 · 왜 만들었을까?

누가: 페이스북의 개발자인 조던워크

언제: 2013년

왜? : 데이터가 자주 바뀌는 복잡한 화면을 더 쉽게 만들고 관리하기 위해 개발했다.

예를들어 댓글 추가하면 댓글 목록과 개수가 바뀌어야하고, 좋아요도 마찬가지.

이런 연결이 많아질수록 개발자가 화면을 하나씩 직접 고치는 코드는 너무 복잡해졌다.

React는 현재 데이터라면 화면이 어떤 모습이어야 하는지를 작성하면 실제 화면을 바꾸는

작업은 React가 맡도록 했다. 또한 화면을 재사용 가능한 부품으로 나눠 관리하도록 했다.

3) 이게 나오기 전엔 어떤 불편함이 있었을까?

데이터가 바뀔때마다 화면의 어느 부분을 어떻게 고칠지 개발자가 직접 챙겨야 하는 불편함이 있었다.

예를들어 쇼핑몰에 상품 하나를 장바구니에 추가하면 다음 항목을 함께 바꿔야했다.

-상품목록

-상품개수

-총 결제 금액

-장바구니가 비어 있다는 안내문

jQuery로 각각을 바꾸는 작업은 짧게 작성 가능하지만, 어떤 항목들을 함께 바꿔야 하는지는

개발자가 기억하고 연결해야 했다.

화면이 복잡해지면 하나를 빠트려 상품은 추가됐는데 합께는 그대로인 문제도 생겼다.

즉, 기능을 수정할 때도 연결된 화면을 일일이 확인해야 했다.

4) 이게 나와서 뭐가 편해졌을까?

리액트의 핵심개념은 1.컴포넌트, 2.상태

1.컴포넌트: 반복되는 화면 조각을 조립 블록으로 만들어둠. (좋아요버튼,댓글창,프로필카드 등등)

2.상태: 서비스가 기억해야하는 정보 -> 장바구니 내용,로그인여부,화면테마,-> "데이터가 바뀌면 화면이 반응한다"의 그 데이터

위 두가지 개념으로 데이터가 바뀔때마다 어느화면을 같이 곹여야 할지 일일이 챙기는 수고가 줄었다.

-화면이 서로 어긋나는 실수가 줄었다. : 장바구니에 상품 추가 시 개수나 합계가 그대로 남는 문제.

-비슷한 화면은 더빠르게 만들 수 있게 되었다. : 한번 만든 상품 카드나 버튼을 상품 목록과 추천화면에서 다시 사용가능

-기능을 수정하기 편해졌다.

5) 기존의 불편함을 어떻게 해결했을까?

화면을 컴포넌트로 나누고, 각 컴포넌트에 "현재 상태라면 무엇을 보여 줄지"를 작성하도록 했다.

장바구니를 예로 들면

1. 화면을 나눴다 : 상품목록, 수량표시 ,결제요약을 각각의 컴포넌트로 만들었다.

2. 기준이 되는 상태를 정했다. : 장바구니에 어떤 상품이 몇개 담겼는지 한 곳에서 관리하도록 했다.

수량 표시와 결제 요약은 이 상태를 함께 사용하도록 했다.

3. 상태가 바뀌면 리액트가 화면을 갱신했다.

:수량이 1개 늘어나면 리액트는 새 상태를 바탕으로 컴포넌트가 무엇을 보여줄지 다시 계산하고,

수량과 합계 처럼 연결되게 달라지는 부분을 화면에 반영했다.

-> 리액트의 효과로 직군도 바뀌었다.

디자인 시안을 HTML·CSS로 옮기던 퍼블리셔

→ 상태 관리 , 데이터 설계 , 컴포넌트 조립까지 하는 프론트엔드 개발자.

지금 채용 공고도 AI가 짜 주는 코드도 사실상 React가 기본값이다.

리액트는 데이터가 바뀔때 화면을 관리하기 편하게 해주었다.

그런데 화면의 동작을 만드는 것과 디자인을 만드는 것은 별개의 일이었다.

버튼 하나에도 색,크기,여백,테두리 등을 정해야했고,

컴퓨터에서 잘 보이던 화면이 휴대폰에서는 잘 안보이는 문제도 있었다.

이런 디자인을 매번 처음부터 만들어야 할까?

<CSS 프레임워크>

1) 왜 이런 이름이 붙었을까?

프레임워크는 무언가를 만들때 사용하는 기본 틀이라는 뜻이다.

CSS 프레임워크는 화면을 꾸미는데 필요한 규칙을 미리 만들어 놓은 도구다.

대표적으로 Bootstrap과 Tailwind CSS가 있다.

Bootstrap : 미리 만들어진 버튼,메뉴 같은 것을 가져다 쓰는 방식.

Tailwind : 색,여백,글자크기 같은 작은 규칙들을 가져와 조합하는 방식.

->쉽게 이야기하면 Bootstrap은 만들어진 옷을 골라 입는 것이고,

Tailwind는 준비된 재료들을 조합해서 원하는 옷을 만드는 것과 비슷하다.

2) 누가 · 언제 · 왜 만들었을까?

Bootstrap

누가: 트위터에서 일하던 마크 오토와 제이컵 손턴

언제: 2011년 공개

왜?: 화면마다 다른 디자인과 작성 방식을 통일하고, 반복되는 작업을 줄이기 위해서다.

Tailwind CSS

누가: 애덤 워던을 중심으로 한 개발팀

언제: 2017년 첫 공개

왜?: 정해진 디자인을 그대로 사용하는 것보다, 원하는 디자인을 빠르게 조합해서 만들기 위해서다.

3) 이게 나오기 전엔 어떤 불편함이 있었을까?

버튼 하나를 만들때도 글자 크기,배경색,안쪽 여백,모서리 모양을 직접 정해야했다.

그런데 이런 작업이 버튼 하나로 끝나는게 아니었다.

입력창,메뉴,상품카드 등에도 비슷한 작업이 계속 필요했다.

여러 개발자가 같이 만들면 같은 사이트인데도 버튼 모양이나 간격이 달라지기도 했다.

게다가 컴퓨터와 휴대폰의 화면 크기가 다르기 때문에, 각각에 맞는 배치도 신경써야 했다.

즉, 비슷한 디자인을 반복해서 만들고 맞추는데 시간이 많이 들었다.

4) 이게 나와서 뭐가 편해졌을까?

기본적인 디자인을 매번 처음부터 만들지 않아도 되었다.

Bootstrap은 준비된 버튼이나 메뉴를 가져다 쓸수 있어서 화면을 빠르게 만들 수 있었다.

다만 기본 디자인을 그대로 사용하면 사이트들이 전부 비슷하게 보이기 쉬웠다.

Tailwind는 작은 꾸밈 규칙을 조합하기 때문에 원하는 디자인을 만들기 편했다.

예를들어 “배경은 파랗게,글자는 하얗게,여백을 넣고,모서리는 둥글게”를 준비된 이름으로 지정하는 것이다.

두 도구 모두 휴대폰과 컴퓨터의 화면 크기에 따라 배치를 바꾸는 작업을 도와준다.

5) 기존의 불편함을 어떻게 해결했을까?

개발자들이 반복해서 작성하던 CSS를 도구 안에 미리 만들어 넣었다.

Bootstrap은 버튼에 필요한 여러 규칙을 하나의 묶음으로 준비했다.

Tailwind는 여백,색,크기 같은 작은 규칙들을 각각 준비했다.

개발자는 필요한 규칙의 이름을 붙여서 가져다 쓰면 되었다.

즉, 반복되는 디자인 작업을 미리 준비해두고 재사용하도록 해결한 것이다.

이렇게 화면을 부품으로 나누고, 다른 사람이 만든 코드까지 가져다 쓰면서

프로젝트 안에는 많은 파일이 생겼다.

그런데 개발자가 작업하던 파일을 그대로 브라우저에 보내면 되는건 아니었다.

브라우저가 읽지 못하는 문법도 있었고, 배포하기 전에 정리해야 할 부분도 있었다.

여기서 필요한 과정이 빌드다.

<빌드>

1) 왜 이런 이름이 붙었을까?

Build는 만들다,조립하다 라는 뜻이다.

개발자가 작성한 코드와 필요한 부품들을 가공해서 실행할 수 있는 결과물로 만드는 과정이다.

석재 공장으로 생각하면 이해가 쉽다.

원석과 도면이 있다고 바로 현장에 설치할 수 있는건 아니다.

절단하고 가공해서 납품할 판재로 만들어야 한다.

웹도 비슷하다.

원본 코드 → 빌드로 가공 → 브라우저에서 사용할 파일

2) 누가 · 언제 · 왜 만들었을까?

누가: 특정 한 사람이 만든 것은 아니다.

언제: 웹이 나오기 전부터 프로그램을 만드는 과정에 사용하던 개념이다.

왜?: 개발자가 작성하기 편한 형태와, 실제 실행에 필요한 형태가 다르기 때문이다.

예를들어 React에서 자주 사용하는 JSX는 HTML처럼 생겼지만,

브라우저는 이 문법을 그대로 실행하지 못한다.

브라우저가 실행할 수 있는 JavaScript로 바꿔줘야 한다.

이런 변환과 정리 작업을 해주는 도구로 웹팩,비트(Vite) 등이 있다.

3) 이게 나오기 전엔 어떤 불편함이 있었을까?

프로젝트가 커지면 파일도 많아지고 가져다 쓰는 코드 부품도 많아진다.

이것들을 개발자가 직접 연결하고,변환하고,배포할 파일까지 챙기려면 번거로웠다.

그렇다고 한 파일에 모든 코드를 넣으면 수정하고 관리하기가 어려워진다.

->개발할때는 기능별로 나눠서 작업하는게 편하다.

->사용자에게 보낼때는 브라우저가 실행하기 좋게 정리하는게 필요하다.

이 두가지 필요를 개발자가 수작업으로 맞추려면 시간이 많이 들고 빠뜨릴 가능성도 있었다.

4) 이게 나와서 뭐가 편해졌을까?

개발자는 코드를 관리하기 편하게 작성하고,

사용자에게 전달할 파일을 만드는 작업은 도구에 맡길 수 있게 되었다.

-브라우저가 읽지 못하는 문법을 자동으로 바꿔준다.

-여러 파일과 부품을 연결해 배포할 파일로 만들어준다.

-불필요한 부분을 줄여 파일을 가볍게 만들 수 있다.

즉, 개발하기 편한 원본을 유지하면서도 사용자에게는 실행하기 좋게 가공한 결과물을 줄 수 있게 된 것이다.

5) 기존의 불편함을 어떻게 해결했을까?

빌드 도구가 코드를 읽고 필요한 가공을 순서대로 처리하도록 했다.

1. 번역 : JSX 같은 문법을 JavaScript로 변환했다.

2. 묶기와 나누기 : 연결된 코드들을 정리해서 배포할 파일로 만들었다.

3. 용량 줄이기 : 불필요한 공백이나 사용하지 않는 코드 등을 줄였다.

4. 이름표 붙이기 : 내용이 바뀐 파일은 이름도 달라지게 해서 예전 파일과 구분하도록 했다.

여기서 묶는다는 말이 모든 파일을 무조건 하나로 만든다는 뜻은 아니다.

필요한 화면에서 필요한 코드만 받도록 나누기도 한다.

->빌드와 배포는 다르다.

빌드가 납품할 판재를 만드는 과정이라면,

배포는 사용자가 이용할 수 있는 곳으로 보내는 과정이다.

여기까지는 개발자가 웹을 만들고 정리하는 과정이었다.

그런데 사용하는 사람 입장에서는 또 다른 불편함이 있었다.

상품목록에서 상품상세로, 다시 장바구니로 이동할때마다

새 문서를 불러오면서 화면의 흐름이 끊기는 것이다.(깜빡임)

휴대폰 앱처럼 필요한 부분만 바꿔서 보여줄 수는 없을까?

이것과 연결되는 방식이 SPA다.

다만 SPA가 React 이후에 처음 생긴 것은 아니고, 여기서는 문제의 흐름에 따라 설명하겠다.

<SPA>

1) 왜 이런 이름이 붙었을까?

Single Page Application의 약자다.

하나의 페이지를 바탕으로 동작하는 웹앱이라는 뜻이다.

여기서 페이지가 하나라는건 화면이 하나뿐이라는 뜻은 아니다.

상품목록,장바구니,마이페이지처럼 여러 화면을 보여줄 수 있다.

다만 화면을 바꿀때마다 새 HTML 문서를 받는 대신,

현재 문서 안의 내용을 JavaScript로 바꿔 보여주는 것이다.

2) 누가 · 언제 · 왜 만들었을까?

누가: 특정 한 사람이 만든 도구가 아니라 여러 개발자가 발전시켜온 방식이다.

언제: 2000년대부터 발전해 2010년대에 널리 사용되었다.

왜?: 문서 전체를 매번 새로 받지 않고, 앱처럼 화면을 자연스럽게 바꾸기 위해서다.

예를들어 상품목록에서 장바구니로 이동할때

상단 로고와 메뉴는 그대로 두고 가운데 내용만 장바구니로 바꾸는 것이다.

3) 이게 나오기 전엔 어떤 불편함이 있었을까?

전통적인 웹에서는 다른 페이지로 이동하면 서버에서 새 HTML 문서를 받아왔다.

상품목록 클릭 → 상품목록 문서를 받음

상품상세 클릭 → 상품상세 문서를 받음

장바구니 클릭 → 장바구니 문서를 받음

로고나 메뉴처럼 똑같이 보이는 부분이 있어도 문서 자체가 교체되는 방식이었다.

이 과정에서 화면이 깜빡이거나 작업의 흐름이 끊기는 느낌이 생길 수 있었다.

또한 이전 화면에서 기억하던 정보를 다음 화면에서도 이어가려면 별도의 처리가 필요했다.

4) 이게 나와서 뭐가 편해졌을까?

전체 문서를 바꾸지 않고 필요한 내용만 바꿀 수 있게 되었다.

-공통으로 사용하는 메뉴나 화면을 유지할 수 있었다.

-화면 이동이 부드러워졌다.

-사용자가 작업하던 상태를 이어서 관리하기 편해졌다.

웹페이지를 한장씩 새로 받는 느낌보다,

하나의 프로그램 안에서 화면을 바꾸는 느낌으로 사용할 수 있게 된 것이다.

다만 처음에 받아야 할 JavaScript가 많으면 첫 화면이 나타나기까지 오래 걸릴 수도 있었다.

5) 기존의 불편함을 어떻게 해결했을까?

화면 이동을 JavaScript가 처리하도록 했다.

1. 처음 접속하면 기본 문서와 필요한 코드를 받는다.

2. 사용자가 메뉴를 누르면 어떤 화면을 보여줄지 결정한다.

3. 필요한 데이터가 있으면 서버에서 가져온다.

4. 그 데이터로 현재 문서의 내용을 바꾼다.

이때 주소에 맞는 화면을 연결하는 것을 라우팅이라고 한다.

장바구니 주소면 장바구니 화면을 보여주는 식이다.

React는 이런 화면을 컴포넌트로 나누고 상태에 맞춰 관리하는데 사용할 수 있다.

즉, React는 화면을 만드는 도구이고 SPA는 웹앱을 구성하는 방식이다.

SPA로 화면 이동은 편해졌지만 처음 접속했을때의 문제는 남아있었다.

브라우저가 코드를 받아 실행해야 실제 내용이 나타나는 경우가 있었기 때문이다.

그렇다면 첫 화면의 내용은 서버에서 미리 만들어 보내주면 안될까?

<SSR과 Next.js>

1) 왜 이런 이름이 붙었을까?

SSR은 Server Side Rendering의 약자다.

서버 쪽에서 화면에 필요한 HTML을 만든다는 뜻이다.

Next.js는 React로 개발할때 SSR 같은 기능을 쉽게 사용하도록 도와주는 프레임워크다.

->SSR은 화면을 만드는 방식이다.

Next.js는 그 방식을 구현하도록 도와주는 도구다.

2) 누가 · 언제 · 왜 만들었을까?

SSR

서버에서 HTML을 만들어 보내는 방식은 예전부터 있었다.

SPA가 나온 뒤에 처음 만들어진 기술은 아니다.

Next.js

누가: 기예르모 라우흐 등이 속한 ZEIT 팀. 현재 회사 이름은 Vercel이다.

언제: 2016년

왜?: React로 만든 화면을 서버에서도 만들고, 페이지 연결과 빌드 같은 작업을 쉽게 처리하기 위해서다.

브라우저에서만 화면을 만들면 첫 내용이 늦게 나타나거나 검색엔진이 내용을 읽기 어려울 수 있었다.

이런 문제를 해결하기 위해 서버에서 HTML을 만드는 방식을 React와 함께 사용하기 편하게 한 것이다.

3) 이게 나오기 전엔 어떤 불편함이 있었을까?

브라우저에서 화면을 만드는 SPA는 처음 받은 HTML에 실제 내용이 적게 들어있을 수 있었다.

JavaScript를 받아 실행해야 상품명,가격,설명 같은 내용이 나타나는 것이다.

여기서 두가지 불편함이 있었다.

-사용자는 코드가 실행될때까지 첫 화면의 내용을 기다려야 했다.

-검색엔진이나 링크 미리보기 서비스가 내용을 제대로 읽지 못하는 경우가 있었다.

검색 결과에 잘 나오도록 하는 작업을 SEO라고 한다.

즉, SEO에 불리할 수 있었던 것이지 SPA라고 무조건 검색이 안되는 것은 아니다.

React에서도 서버에서 HTML을 만들 수는 있었지만

개발자가 설정하고 연결해야 하는 작업이 많았다.

4) 이게 나와서 뭐가 편해졌을까?

처음부터 내용이 담긴 HTML을 보내기 편해졌다.

사용자는 브라우저가 화면을 만드는 코드를 전부 실행하기 전에도 내용을 볼 수 있었고

검색엔진도 상품명이나 설명 같은 내용을 읽기 쉬워졌다.

또한 Next.js를 사용하면 서버 렌더링과 페이지 연결 등을 직접 구성하는 수고가 줄었다.

즉, 첫 내용은 먼저 보여주면서 이후 화면 이동은 SPA처럼 부드럽게 만드는 구성을 구현하기 편해졌다.

5) 기존의 불편함을 어떻게 해결했을까?

브라우저가 하던 화면 만들기 작업의 일부를 서버에서 먼저 하도록 했다.

예를들어 상품 상세페이지라면:

기존의 브라우저 중심 방식:

기본 HTML을 받음 → JavaScript를 받음 → 상품 데이터를 가져옴 → 화면에 상품을 보여줌.

SSR 방식:

서버가 상품명,가격,설명이 담긴 HTML을 만듦 → 브라우저가 받아 내용을 보여줌.

이후 필요한 JavaScript가 실행되면서 장바구니 버튼 같은 동작을 연결한다.

이 과정을 하이드레이션이라고 한다.

즉, 처음부터 내용이 담긴 문서를 보내서 사용자의 기다림과 검색엔진의 읽기 어려움을 줄인 것이다.

Next.js는 React에서 이런 처리를 쉽게 할 수 있도록 도와준다.

다만 Next.js를 사용한다고 모든 페이지가 SSR이 되는 것은 아니다.

AI 꼬리질문
https://share.aside.com/s/2fG4dtcfhtvCQENK

꼬리질문1.DOM이 뭔지 더 자세히 알고 싶어.

꼬리질문2.빌드가 뭔지 더 쉽고 자세하게 설명해 줘.

꼬리질문3.V8을 브라우저 밖에서 쓰고 싶었다는데, 구체적으로 무엇을 하고 어떤 결과를 얻고 싶어서 Node.js를 만든 거야?

꼬리질문4.그럼 결국 Node.js에서 쓰는 언어와 문법도 자바스크립트인 거야?

꼬리질문5.웹팩(Webpack)과 비트(Vite)는 뭐야?

오늘 잘한 점:
프론트엔드 영상을 여러번 봐서 잘 알고있다고 생각했던 내용들이
5가지 질문형태로 적으려니 처음에는 잘 안되었지만
점점 잘 되기 시작하면서
왜 이런 질문에 답을하면서 적는게 좋은 학습법인지 몸으로 깨달았다.
영상과 교재만으로도 충분하다고 생각했던걸 다시 적어보면서
그게 큰 오산이었다는걸 느꼈다.
하나의 개념을 공부할때는 여러 방면으로 다양한 표현방식의 자료들을 보고
내가 한 이해를 바탕으로 5가지 질문에 답을 해보며
정리하는게 가장 머리속에 기억에 오래남는다는걸 꺠우친게 제일 잘한점이라 생각한다.

오늘 부족했던 점:

vs코드와 터미널사용, 옵시디언 사용에 대해 보고 셋팅해보려 했지만
계속 헤메는 느낌이었다. 그래서 어제 오늘 학습일지 적었던것처럼
각 기능들이 어떤 불편함을 해결해주기 위한 목적으로 만들어진것인지,
그것을 어떻게 해결했기에 내가 어떻게 쓰면 되는지
잘 공부해서 셋팅 잘 해봐야겠다.

프론트엔드 내용 전체를 다 일지에 적으려하니 적는데 시간이 많이걸렸다.
처음부터 이 방법으로 했으면 좋았을텐데 내용을 영상과 교재로 먼저 다 숙지하려고 노력해보고 적으려니까
막상 적을때 되니 노력한만큼 술술 적히진 않아서 내가만든 필기노트를 보며 동시에 ai에게 질문하면서 적었다.
시간이 2배로 걸린듯하다.


오늘 총평: 오늘 VS코드 ,옵시디언을 프론트앤드 공부와 동시에 셋팅하려는건 너무 욕심이었다.
내일은 옵시디언,LLM위키 에대해 제대로 공부해보고 셋팅하는 날을 가져야겠다.
시간이 된다면 VS코드까지!