회사에서 전시 도메인 쪽 소스를 next.js와 react로 따로 프로젝트를 만들었다
속도를 더 빠르게 하기 위함 인 것 같은데 자세한 것은 공부하면서 알아가 볼 예정..
그래서 next.js 가 뭔지 하나도 모르는 나는 ..
공부해야한다 ㅜㅅㅜ
next.js
일단 공식 문서부터 찾았다.
=> 재무 대시보드 를 만들어 볼거라고 함
배우게 될 개요는 다음과 같다.
리액트도 모르는데 큰일 이다...
그래서 유튜브에서 급하게 찾아본 "리액트 1시간 기초 "
3편까지 있는 것 같은데 가보자고
리액트
react : meta가 개발함
현재 점유율 1위 라이브러리
경쟁자 : vue, angular. 등...
역사
기존 jquery 로 --> Angular -> 리액트 -> 뷰 -> 스벨트
: 우리 회사는 jquery 썼었음 . 지금도 전시 도메인 제외는 jquery 진행중
jquery 에서 react 로 왜 넘어갔을 까?
1. 페이지 전환없이 앱 같은 느낌을 원함 (Ajax, ex : gmail)
-> 한 페이지에서 다 하는 SPA (Single Page Applicaion)
방식의 유행
( 옛날에는 페이지 전환 시. 모든 페이지가 싹 사라졌다가 새로운 페이지가 뜨고 그랬었음
근데 요즘에 페이스북이나 gmail 보면은 큰 틀, 뼈대 같은건 유지되면서 안의 컨텐츠들만 쏙쏙 바뀜)
페이지는 하나인데 내부 공간만 바꾸는
그거를 SPA 라고함 싱글 페이지 (페이지가 하나인 앱인거임 )
과거에는 MPA 멀티 페이지 애플리케이션 이었음
싱글페이지어플리케이션에 대한 수요가 늘어나면서 그거에 적합한게 리액트임
- SPA 의 좋은 점
: 데이터 유지 관점에서 좋음
웹 사이트에서 한 페이지에서 다른 페이지로 넘어가면 그 전에 페이지에 있던 데이터들이 전부 날아감
그래서 날아가는 걸 막기 위해서 따로 저장소 같은걸 둬야 하는데
SPA는 한 페이지에서 내부 컨텐츠만 살짝 살짝 갈아 끼는 특성 때문에
한 페이지에 있는 데이터들이 계속 유지됨
새로고침 하거나 브라우저를 닫지 않는 이상
2. 프론트의 비중이 점점 높아짐 ( 데이터를 많이 다룸).
예전에는 데이터를 백엔드에서 가지고 있었음 _ 의존적인 측면이 강했음
SPA 가 되면서 데이터를 계속 유지할 수 있음 MPA 일때는 페이지 전환 할 떄마다 데이터가 날아가 버렸기 때문에
매번 백엔드에게 빌어서 데이터를 받아왔어야 함.
그게 아니라 한 번 갖고 오면 애플리케이션에 데이터를 갖고 있을 수 있음
그래서 프론트 엔드 개발자의 위상이 높아짐 -> 데이터를 많이 다룸 -> 데이터를 위한 아키텍처 이런게 도입됨 프론트에도
- MVC (백엔드에서 자주 쓰던 아키텍처 ) 등의 개발 방식은 대규모 개발에 적합치 않음 -> 대안 필요
ㄴ 프론트에 그대로 가져와서 하려고 했더니 뭔가 잘 안맞음 (angular)
데이터를 효율적으로 다룰 수 있는 구조를 리액트가 가지고 있었음
- 리액트는 FLUX 패턴
: MVC 패턴의 문제점을 해결함
앵귤러는 양방향 바인딩 이라고 해가지고 (2 way binding)
부모 자식 관계라고 햇을 때 부모가 자식의 데이터를 바꿀 수 있고
자식이 부모의 데이터를 바꿀 수 있는 양방향. 이런거 사용햇음
FLUX 패턴을 사용하면서
단방향 바인딩 (1 way binding) _ 반시계 방향으로 돌고 있음
- 좋은점. : 어떤 데이터가 바뀌었을 때 걔를 누가 바꿨는지 추적하기가 쉬워짐
view가 바뀌었다 ? 그 전으로 돌아가서 store을 보고 이런식으로 하면 됨
=> 매우 간단함
- 좋은점 : 대규모 웹사이트 에서 양방향 바인딩을 쓰면 (부모가 자식을 바꾸고 자식이 부모를 바꾸고 ) 나중에 에러가 났을 때 얘가 뭐때문에 바뀌어서 에러가 발생했는지 알기가 힘듬 , 단방향이면 그냥 부모에게 가서 원인 찾고 하면 됨
: 대규모에 적합함 _ 버그 잡기 쉽다
그래도 자식이 부모를 못바꾸니까 거기서 오는 불편함도 있긴 함.
ajax가 나온 후로 7~8년 동안 리액트가 나오기까지 엄청난 프론트엔드 쪽에 시행착오가 있었음
이 구조.
HTML은 구조, CSS 는 디자인, JS는 동작
한 페이지에 혼재 _ 따로 js 파일, css 파일 뺄 수 있지만 결국 html 파일에서 불러와서 쓰는 것 이기 때문에
한 파일에서 하는 거랑 마찬가지임
버튼이 여러개라면?
요즘 웹사이트 보면 한 화면에 버튼이 수십, 수백개임
스크립트가 많이 붙고 -> 너무 많아짐 -> 관리 어려움 -> 오타 남 -> 얘가 어디랑 매칭되는지도 헷갈리고
그래서 그냥 자바스크립트로 만듬. HTML을 JS 로 생성하기 너무 힘듬
근데 가독성이 너무 안좋음
: 우리회사에서는 이런식으로 안쓰긴 함.
그래서 js로 하되 가독성은 좋은 방법을 고안해내기 시작함
그게 JSX 임
js 코드인데 html 코드가 들어있음 _ JSX 라는 새로운 문법 도입
자바스크립트 쓰는 와중에 html 태그만 편하게 ~.ᐟ
물론 브라우저는 jsx 파일을 인식을 못함
이거를 ( html 태그를) 자바스크립트로 바꿔줘야함
자바스크립트로 바꾸고 나면 브라우저가 인식을 해서 실행을 할 수 있게 됨
자바스크립트 뭉치를 -> html 들어가있는 보기 편한 방식으로 바꿨다고 보면 됨
그래서 실제 사용하는거는,
함수 이름이 NextBtn 이잖아
그걸 아래 처럼 사용한다.
새로운 태그를 만든거임
그 태그의 기능, 클릭하는 거랑 css 까지 전부 한 파일에 들어있는 거임
- 좋은 점
: NextBtn 하나 썼을 때 , 애는 css 도 적용되어있고 , 기능( 클릭했을 때 기능) 까지 다 적용이 되어있는 거임
하나 하나의 버튼들이 디자인도 들어가 있고 , 기능도 들어가있는 완성체가 되는 거임
이런 완성체를
component 라고 부릅니다
요즘 웹 개발은 이런 컴포넌트들이 엄청나게 합쳐져 있는 것들임
우리는 컴포넌트를 개별적으로 만들어서 나중에 다 불러와서 합쳐버리기만 하면 됨
리액트는 컴포넌트 기반으로 만든다
- 확장자는 .jsx (타입 스크립트는 .tsx)
당연히 브라우저가 알아듣지 못함
-> 바벨, 웹팩, vite, swc 등의 툴로 js 로 변환해주어야함
이 때 여러 .jsx 파일을 하나의 .js 파일로 합쳐주기도 함.
(js 로 변환을 해주는 와중에 툴들이 여러개의 jsx 파일. 컴포넌트 별로 jsx 파일이 하나씩 있는데 실제 웹사이트는 컴포넌트가 엄청 많음 ,
그런 애들을 js 파일 하나로 합쳐주는 것 )
검색 컴포넌트 - jsx
메뉴 컴포넌느 - jsx
내정보 컴포넌트 - jsx
이렇게 하나 하나 의 컴포넌트
jsx 파일이 엄청 많이 생기겠죠
그리고 걔네들을 마지막에 전체 jsx, 네이버라는 전체 컴포넌트를 딱 두고
그 안에 잘 배치를 해요 그리고 jsx 를 js 로 바꿔주는 툴로 하나로 합쳐버리는 것임
최종적으로
html , css, js 를 만들어내는 그런 방식으로 개발이 바뀜
컴포넌트로 만들어야 하는 이유
: 안그럼 너무 복잡함 기능이 너무 많아서 복잡함
html 과 css, js 의 거리가 너무 멀어짐
"지금 이 html에 대한 js 코드는 어디있지? " 몇 천줄 내려서 찾아야 하고
이럴 수가 있음 . 이런게 불편해서 컴포넌트 식으로 개발을 한다는 것임
+ 타입스크립트는 대부분의 기업에서 사용중 ( js 대신)
js 알면 90% 는 알고 있다 나머지 10%만 알면됨
js 가 프론트엔드에서 가장 중요함
----------------
요약
✅ jquery → React로 넘어간 이유 (핵심 정리 버전)
1. SPA 트렌드 (UX 개선)
- 과거: MPA (페이지 이동 시 전체 새로고침)
- 현재: SPA (한 페이지에서 필요한 부분만 변경)
👉 대표 예: Gmail, Facebook
✔ 장점
- 페이지 깜빡임 없음
- 앱 같은 사용자 경험
- 상태(데이터) 유지 가능
2. 데이터 관리 방식 변화
🔴 과거 (jQuery + MPA)
- 페이지 이동 시 데이터 초기화됨
- 매번 서버(API) 호출 필요
- 프론트는 단순 View 역할
🟢 현재 (React + SPA)
- 한 번 가져온 데이터를 계속 유지
- 프론트에서 상태(state) 관리
- 프론트가 “데이터 중심”으로 진화
👉 그래서
➡️ 프론트 개발자 역할 ↑
➡️ 상태 관리 (Redux 등) 등장
3. jQuery의 한계
- DOM 직접 조작 ($('#id').hide() 이런 거)
- 코드가 여기저기 흩어짐
- 규모 커지면 유지보수 지옥
👉 문제
- 어떤 코드가 어떤 UI 바꾸는지 추적 어려움
- 협업 힘듦
4. Angular → React로 넘어간 이유
Angular (초기)
- 양방향 바인딩 (2-way binding)
👉 문제
- 데이터 흐름이 복잡함
- 누가 데이터를 바꿨는지 추적 어려움
- 대규모에서 디버깅 어려움
React
- 단방향 데이터 흐름 (1-way binding)
- FLUX 패턴
👉 장점
- 데이터 흐름이 명확함
- 디버깅 쉬움
- 대규모 서비스에 적합
5. 컴포넌트 기반 개발
과거
- HTML / CSS / JS 분리
- 서로 위치 떨어져 있어서 찾기 힘듦
React
- 하나의 컴포넌트 = UI + 스타일 + 기능
예:
- 버튼 UI
- 클릭 이벤트
- 스타일
👉 장점
- 재사용 가능
- 유지보수 쉬움
- 구조 명확
6. JSX 등장 이유
- JS 안에서 HTML처럼 UI 작성 가능
👉 기존 문제
- JS로 DOM 생성 → 가독성 최악
👉 JSX 해결
- 보기 쉽고 직관적
7. 빌드 도구 등장 이유
(Webpack, Vite, Babel)
- JSX는 브라우저가 못 알아들음
- → JS로 변환 필요
👉 역할
- JSX → JS 변환
- 여러 파일 → 하나로 번들링
💡 한 줄 핵심 요약
👉
“jQuery는 DOM 직접 조작이라 규모가 커지면 관리가 어려웠고,
React는 SPA + 컴포넌트 + 단방향 데이터 흐름으로
대규모 서비스에서 유지보수와 상태 관리가 훨씬 쉬워서 넘어갔다.”
- jquery → react 로 전환 계기 : 페이지 전환 없이 앱같은 느낌을 원해서 큰 틀은 유지 컨텐츠만 변경 SPA - 데이터 유지 관점에서 좋음 , 데이터를 프론트에서 많이 다루게 됨 (특징)
- 리액트의 패턴은 ? : FLUX 패턴 _ MVC 패턴의 문제 해결 _ 1 way binding (단방향 바인딩) _ 버그 잡기 쉬워짐 - 대규모 웹사이트에서 사용하기 적합
- jsx 문법은? : js 코드인데 html 코드가 들어있음 _ 브라우저는 인식 못하니까 다시 js 로 변경 해줘야함. 왜 쓰냐? 컴포넌트 방식을 채택하기 위해서
- 리액트에서 사용하는 방식은 ? : 컴포넌트 방식 왜쓰냐? html 과 css , js 의 거리가 너무 멀어짐 불편해