소스코드 저장소 호스팅의 양대산맥!

GitHub 와 GitLab 의 핵심적인 차이는 DevOps 워크플로우 통합 수준과 사용하는 목적 이다.

• GitHub: 오픈소스 공유, 커뮤니티 협업(SaaS 위주) 강점, 속도우선 <<프로젝트 중심>>
• GitLab: 자체 호스팅가능, 내장된 CI/CD로 올인원 DevOps 플랫폼 지향, 안정성우선 <<DevOps 중심>>

대표적인 차이점 몇가지를 살펴보자면,

1. 브랜치

• GitHub: 브랜치를 생성하고 병합하는 것이 용이함 → 신속한 배포가능, 문제 발생시 이전 버전으로의 신속한 복원가능, PR(Pull Request) 의 코드 검토방법
• GitLab: master 브랜치 외에 배포 환경에 따라 브랜치를 분리하여 관리 → 병합 요청시 MR(Merge Request) 방법으로 까다로운 코드검토 필요

2. 소프트웨어 서비스

• GitHub: GitLab보다 적은 수의 자체적인 소프트웨어 서비스를 제공하는 대신 외부 프로그램 및 서비스와 통합하는 쉬운 방법 제공 (예: 깃허브 마켓플레이스)
• GitLab: 완전한 소프트웨어 개발 솔루션 제공 → 올인원 DevOps 플랫폼라 불리움, 지라(Jira)/팀즈/슬랙/G메일같은 플랫폼과의 통합 제공

각각에 대해서 자세하게 살펴보자

GitHub

너무나 친숙한 github는 버전관리도구인 git 을 기반으로 소스코드를 클라우드에 저장하고 공유 및 협업하는 웹 호스팅 플랫폼 이다.

관련하여 자세하게 다루려면 적은 양이 아니므로 이번 포스팅에서는 간단하게만 정리하고 넘어가고, 나중에 하나씩 살펴보자.

git과 github는 간단하게 아래와 같이 생각하고 넘어가면 되겠다.

• Git: 개인PC에서 동작하는 버전관리도구
• GitHub: Git으로 관리하는 프로젝트를 올리는 웹사이트

GitLab

gitlab에도 종류가 있는데, GitLab.com 과 GitLab 이 있다. (처음엔 같은 말인줄 알았다....) 두 방식 모두 강력한 내장 CI/CD, 이슈 트래커, 보안 테스트 등의 올인원 데브옵스(DevOps) 플랫폼 기능을 제공한다.

그렇다면 두 가지는 어떤 차이가 있을까?

1. GitLab.com

• SaaS(클라우드) 서비스 → 회원가입 즉시 사용 가능
• 장점
  • 회원가입 후 사용하므로 서버 관리 부담이 없음
  • 즉시 사용 가능함
  • 자동으로 업데이트가 이루어짐
• 단점
  • 데이터가 외부 클라우드에 저장되어 보안이 약함
  • 커스터마이징에 제한이 있음
  • 대규모로 사용시 비용측면에서 부담이 될 수 있음

2. GitLab

• 자체 설치형(Self-managed) → 자체 서버 직접 설치 필요
• 장점
  • 자체 서버를 사용하므로 보안이 강력함
  • 데이터 통제가 가능함
  • 사내 네트워크와 연동 가능
• 단점
  • 서버를 관리하는 인력이 필요함
  • 직접 설치 및 유지보수가 필요함

🌟GitLab의 모습은 어떨지 궁금해서 학습목적으로 가입을 진행해보았다.

로그인 후 'Create new project' 를 하면 아래와 같은 화면을 볼 수 있다.

여기서 import project 클릭 후 GitHub를 연동하면 개인 레포지토리를 GitLab에 import할 수도 있다.

테스트로 레포지토리를 import 해보니 아래와 이 상태가 변경되면서 import가 완료되었다.

import가 완료된 레포지토리를 클릭하면 GitHub에서 보던 화면과 크게 다르지않은 화면을 볼 수 있다. (추후 작업 후 pull/push 테스트도 진행하여 내용을 추가해보겠다.)

✋🏻잠깐! GitLab 이 CI/CD가 내장되어있다고하는데 Github에는 Github Actions 가 있잖아?

맞는말이지만 GitLab은 CI/CD기능이 "내장" 되어있어 설정이 간편하지만, Github는 Github Actions라는 별도 도구를 연동해야한다.

두 가지의 대표적인 특징과 어떤 상황에서 어떤 걸 선택하여 사용하면 좋을까?

• GitLab: 단일 애플리케이션 형태의 내장된 강력한 파이프라인 제공 → 전체 DevOps 프로세스를 하나의 플랫폼에서 관리하거나, 자체 서버에 CI/CD 환경을 구축해야할때 사용
• Github Actions: 마켓플레이스 중심의 유연하고 가벼운 자동화, workflows 라는 설정파일을 기반으로 동작 → 이미 GitHub에서 코드를 관리 중이며, 빠르고 간편하게 빌드 및 배포 자동화 설정을 하고싶을때 사용

그래도 두 가지 모두 YAML 기반의 DevOps 도구라는 점은 동일하다.

Github Actions 을 살짝 사용해보니 feat브랜치에서 main으로 push 를 하면 (workflows 설정파일 내용을 기반으로) 자동으로 빌드를 진행하여 에러를 체크해주는 것이 편리하게 느껴졌다.

확실히 빌드 및 배포를 자동화 해놓으면 정말 "개발" 에만 집중할 수 있으니 코드의 품질을 높이는데도 도움이 될거라 생각된다.

정리해보자면, GitLab은 대규모 기업형 프로젝트에 유리하고 GitHub은 개인 및 소규모 프로젝트에 유리하다.

구글의 V8 엔진으로 빌드된 자바스크립트 런타임 환경인 Node.js가 등장함으로써 웹의 영역에서 벗어나 서버 사이드 애플리케이션 영역까지 커버할 수 있는 범용 개발 언어가 되었다.

그래도 역시나 주력 분야는 웹 브라우저 환경에서 동작하는 웹 페이지/애플리케이션 의 클라이언트 사이드이다. (major 는 무시못하져)

대부분의 프로그래밍 언어는 운영체제(OS) 또는 가상머신(VM) 과 손잡고 실행되지만, 웹 애플리케이션 의 클라이언트 사이드인 자바스크립트는 HTML, CSS 의 손을 잡고 실행된다.

자, 그럼 프론트엔드라면 모를 수가 없는 HTML, CSS, JavaScript 로 작성된 문서를 어떻게 파싱하여 렌더링하는지 살펴보자!

✋🏻 잠깐! 파싱과 렌더링이 뭐야?

• 파싱(parsing) : 구문 분석이라는 의미로 작성된 텍스트 문서를 프로그래밍 언어가 읽고 실행할 수 있도록 문자열을 토큰으로 분해한 후, 토큰에 문법적 의미와 구조를 반영하여 트리 구조의 자료구조를 생성하는 과정을 의미한다.
• 렌더링(rendering) : HTML, CSS, JavaScript 로 작성된 문서를 파싱하여 브라우저에 시각적으로 출력하는 것을 의미한다.

그렇다면 브라우저가 렌더링을 수행하는 과정은 어떻게 될까? 1️⃣ HTML, CSS, JavaScript, 이미지, 폰트 등 렌더링에 필요한 리소스를 요청하고 서버로부터 응답 받는다. 2️⃣ 렌더링 엔진은 응답된 HTML, CSS 를 파싱하여 DOM과 CSSOM 을 생성하고 결합하여 렌더 트리를 생성한다. 3️⃣ 자바스크립트 엔진은 응답된 자바스크립트를 파싱 하여 AST를 생성하고 바이트코드로 변환하여 실행한다. 이 때, 자바스크립트는 DOM API를 통해 DOM 이나 CSSOM 변경을 할 수 있으며, 변경된 DOM과 CSSOM은 다시 렌더 트리로 결합된다. (변경상태 업데이트 완료!) 4️⃣ 최종적으로 업데이트 된 렌더 트리를 기반으로 HTML 요소의 레이아웃을 계산하고 우리가 보는 브라우저 화면에 요소를 그린다.

이제 단계별로 하나씩 살펴보자.

요청과 응답

브라우저의 핵심 기능이라고하면 필요한 리소스를 서버에 요청하고, 응답받아 브라우저에 시각적으로 렌더링 하는 것이다.

https://www.naver.com/

우리에게 너무나 익숙한 이 것, URL 이다. 이 곳에서 검색어를 입력하고 엔터키를 누르면 검색결과를 볼 수 있다. 이것이 우리가 사용하는 과정을 겉으로만 봤을 때이다. 우리가 엔터키를 누르고 검색결과를 보는 간단해보이는 과정이 브라우저에서의 처리과정으로 보면 어떨까?

서버에 리소스를 요청하기위해 브라우저는 주소창을 제공한다. 제공된 주소창에 우리는 요청할 내용을 URL에 담아서 입력하고 엔터키를 누르면 결과가 보인다.

https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=0&ie=utf8&query=%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8&ackey=9m6l1yfc

위 URL 은 네이버에서 '자바스크립트' 로 검색했을 때 주소창의 모습이다.

검색어를 입력하고 엔터키를 누르면 루트요청(/) 과 호스트(domain, 도메인) 으로 구성된 요청이 서버로 전송된다.

루트요청에는 리소스를 요청하는 내용이 명확하게 나타나있지 않지만, 암묵적으로 서버는 루트요청에 대해서는 index.html 을 응답하도록 설정되어 있다. (이것이 우리가 루트디렉토리에 index.html을 구성하는 이유인 것이다.)

💡 요청과 응답은 개발자도구-Network에서 확인할 수 있다.

HTTP 1.1과 HTTP 2.0

HTTP란?

| 웹에서 브라우저와 서버가 통신하기 위한 규약(프로토콜)이다.

그렇다면 HTTP 1.1 과 HTTP 2.0의 차이점은 뭘까?

HTTP 1.1은 기본적으로 커넥션당 하나의 요청과 응답만 처리한다. 즉, 여러 개의 요청이 들어와도 한 번에 전송할 수 없으며, 응답도 마찬가지이다. (1.1이라는 숫자에 연관지어서 생각해보면, 1:1 처리방식이라고 생각하면 좋겠다. "하나의 요청엔 하나의 응답만이!")

그렇기때문에 응답시간은 요청할 리소스의 개수에 비례한다는 단점이 있다.

이러한 단점을 보완하여 나온 것이 HTTP 2.0이다. (두-둥🎉)

HTTP 2.0은 커넥션당 여러 개의 요청와 응답이 가능하므로 HTTP 1.0보다 페이지 로드속도가 약 50%정도 빠르다고 한다.

HTML 파싱과 DOM 생성

순수한 텍스트로 이루어진 HTML문서를 브라우저에 시각적으로 표현하려면 브라우저가 이해할 수 있는 자료구조(DOM)로 변환하여 메모리에 저장해야 한다. 그 과정은 아래와 같다.

여기서 DOM은 HTML문서를 파싱한 결과물이라고 볼 수 있다.

CSS 파싱과 CSSOM 생성

렌더링 엔진은 HTML 을 한 줄씩 순차적으로 파싱하여 DOM을 생성한다. 그 과정중에서 CSS 로드를 담당하는 link, style 태그를 만나면 DOM 생성을 잠시 멈추고, CSS 로드 담당 태그내용을 먼저 처리한다.

파싱하여 CSSOM을 생성하는 과정은 DOM을 생성하는 과정과 동일하며, CSS파싱을 완료하고나면 일시중지해놨던 DOM 생성을 다시 시작한다.

렌더 트리 생성

렌더링 엔진은 서버로부터 응답된 HTML과 CSS 파싱과정을 거쳐 DOM와 CSSOM을 생성하고, DOM과 CSSOM은 최종 렌더링을 위해 렌더 트리(render tree)로 결합된다.

렌더 트리는 렌더링을 위한 트리 구조의 자료구조이기 때문에 브라우저 화면에 렌더링되지 않는 노드(meta, script태그 등)와 CSS에 의해 표시되지 않는(display:none) 노드들은 포함되지 않는다.

렌더 트리는 브라우저에 렌더링되는 노드만으로 구성되어 있다.

이렇게 완성된 렌더 트리는 각 HTML 요소의 레이아웃 계산에 사용되며, 브라우저 화면을 렌더링하는 페인팅처리에 입력값으로 사용된다.

브라우저 렌더링 과정은 구성값이 변경되면 반복적으로 실행된다. 이렇게 페인팅을 다시 실행하게하는 리렌더링은 비용이 많이들고, 성능에 악영향을 줄 수 있기 때문에 리렌더링이 자주 발생하지 않도록 주의해야 한다.🚨

자바스크립트 파싱과 실행

자바스크립트 코드에서 DOM API 를 사용하면 이미 생성된 DOM의 동적 조작이 가능하다.

CSS 파싱과정에서 살펴본 것처럼 HTML을 한 줄씩 파싱하면서 script 태그를 만나게되면 DOM 생성을 일시중지하고 script 코드를 먼저 실행한다.

CSS때와의 차이점이라고하면 자바스크립트 파싱과 실행은 브라우저의 렌더링 엔진이 아닌 자바스크립트 엔진이 처리한다. 자바스크립트 엔진에는 다양한 종류가 있으며, 모든 자바스크립트 엔진은 ECMAScript 사양을 준수하게 되어있다.

렌더링 엔진이 HTML과 CSS를 파싱하여 DOM과 CSSOM을 생성한 것처럼, 자바스크립트 엔진은 자바스크립트를 파싱하여 AST(추상적 구문 트리) 를 생성한다. 그 과정을 그림으로 살펴보면 다음과 같다.

여기서 토크나이징과 파싱, 바이트코드 생성과 실행 단계에 대해서 간단하게 살펴보자.

• 토크나이징 : 단순 문자열인 자바스크립트 소스코드를 문법적 의미를 갖는 코드의 최소 단위인 토큰들로 분해하는 과정이다.
• 파싱 : 이 장의 초반에 살펴본 개념이지만 한번 더 살펴보자면, 토큰들의 집합을 구문분석 하여 AST 를 생성한다. (AST 사용시, TypeScript, Babel, Prettier 와같은 트랜스파일러 구현이 가능하다.)
• 바이트코드 생성과 실행 : 파싱의 결과물인 AST는 인터프리터가 실행할 수 있는 중간 단계인 바이트코드로 변환되고, 인터프리터에 의해 실행된다.

리플로우와 리페인트

앞서 살펴보았던 DOM과 CSSOM이 변경되면, 다시 렌더 트리로 결합되고 그렇게 변경된 렌더 트리를 기반으로 페인트 과정을 지나 브라우저 화면에 렌더링되는 과정을 리플로우, 리페인트 이라고 한다.

리플로우

• 레이아웃 재계산 하는 것을 의미
• 노드 추가/삭제, 요소의 크기/위치 변경, 윈도우 리사이징 등 레이아웃에 영향을 주는 변경이 발생한 경우가 해당됨

리페인트

• 재결합된 렌더 트리를 기반으로 다시 페인트를 하는 것을 의미

변경이 일어났을 때 리플로우, 리페인트가 반드시 다 실행되는 것은 아니다. 레이아웃에 영향이 없는 변경은 리페인트만 실행이 되는 것이다.

JS 파싱에 의한 HTML 파싱 중단

렌더링 엔진과 자바스크립트 엔진의 파싱 과정을 살펴봤을 때, 병렬적으로 파싱을 실행한다기보단 직렬적 으로 파싱을 진행한 것이 보였을 것이다.

이처럼 브라우저는 동기적 으로 (위에서 아래, 순차적) HTML, CSS, 자바스크립트를 파싱하고 실행한다. 이 말은 script 태그 위치에 따라 HTML 파싱이 블로킹되어 DOM 생성이 지연될 수 있다는 말이다.

script 태그의 위치는 그만큼 중요하다!

❌ script 태그의 위치가 올바르지 못할 경우, DOM이 완성되지 않은 상태에서 자바스크립트가 DOM 조작을 하게되어 에러가 발생할 수 있다.

✅ 반면 script 태그를 올바르게 위치시키면, 자바스크립트 로딩/파싱/실행으로 인해 HTML 요소들의 렌더링에 지장받는 일이 발생하지 않아 페이지 로딩시간이 단축되는 효과가 있다.

script 태그의 async/defer 어트리뷰트

자바스크립트 파싱에 의해 DOM 생성이 중단되는 문제를 근본적으로 해결하기 위해서는 어떻게 하는 것이 좋을까?

⇒ script 태그에 async, defer 어트리뷰트를 추가하는 것이다.

async 와 defer 어트리뷰트는 src 어트리뷰트를 통해 외부 자바스크립트 파일을 로드하는 경우에만 사용할 수 있다. (src 없이는 못살아~)

<script async src="example.js"></script>
<script defer src="example.js"></script>

async 와 defer 어트리뷰트를 사용하면 HTML 파싱과 외부 자바스크립트 파일의 로드가 비동기적으로 진행된다.

❗️하지만 자바스크립트의 실행 시점에는 두 가지가 차이가 있다.

async

• 자바스크립트의 파싱과 실행은 자바스크립트 파일 로드가 완료된 직후 진행되며, 이때 HTML 파싱은 중단된다.
• 여러개의 async 어트리뷰트로 지정한 script 태그가 있는 경우, 작성된 순서가 아닌 로드가 완료된 순서대로 실행된다. → 순서보장이 되지 않음❌

defer

• 자바스크립트의 파싱과 실행은 HTML 파싱이 완료된 직후(DOM 생성이 완료된 직후) 진행된다. → DOM 생성이 완료된 이후 실행되어야 하는 코드에 유리함
• 2025년 현재 기준으로 async와 마찬가지로 IE10 이상에서 지원되지만, defer 의 경우에는 IE6~9에서도 지원은 되나 정상작동하지 않을 수 있다.

Set이란?

| set객체는 중복되지 않는 유일한 값들의 집합이다.

이러한 Set 객체는 배열과 유사하지만 몇 가지 차이점이 있다. (배열은 이 반대의 특징을 가진다는 의미겠지?)

• 배열과 다르게 동일한 값을 중복 포함할 수 없다. ❌
• 배열과 다르게 요소 순서에 의미가 없다. ❌
• 배열과 다르게 인덱스로 요소에 접근할 수 없다. ❌

이렇게 수학적 집합의 특성과 일치하는 덕분에 Set으로 교집합, 합집합, 차집합, 여집합 등을 구현할 수 있다.

그렇다면 Set객체는 어떻게 생성할까?

Set 객체의 생성

| Set 생성자 함수로 객체를 생성한다.

단, Set 생성자 함수에 인수를 전달하지 않을 경우 빈 객체 가 생성된다.

// Set 생성
const set = new Set() // 인수 전달안함
console.log(set) // Set(0) {} 빈 객체 생성

앞서 다뤘던 이터러블 을 인수로 전달받아서 객체를 생성하는데, 중복된 값은 요소로 저장되지 않는다. => Set 객체의 첫 번째 특징이였다!

이러한 특성을 활용하면 기존에 filter 를 통해 제거했던 배열의 중복요소를 Set으로 간단하게 진행할 수 있다.

// 기존의 filter 활용 방법
const arr1 = array => array.filter((v, i, selr) => self.indexOf(v) === i)
console.log(arr([2, 1, 2, 3, 4, 3, 4])) // [2, 1, 3, 4]

// Set 활용 방법
const arr1 = array => [...new Set(array)]
console.log(arr([2, 1, 2, 3, 4, 3, 4])) // [2, 1, 3, 4]

Set 객체의 메서드

요소 개수 확인

• Set.prototype.size 프로퍼티 사용
• size 프로퍼티는 setter 함수없이 getter 함수만 존재하는 접근자 프로퍼티이기 때문에 요소 개수를 변경은 할 수 없다. (조회만 가능)

const {size} = new Set([1, 2, 3, 3])
console.log(size) // 3 -> 중복된 값 제외하고 개수 체크

요소 추가

• Set.prototype.add 메서드 사용
• add 메서드는 호출할 때마다 새로운 요소가 추가된 Set객체를 반환하므로, 연속적인 호출가능

이 때, 중복된 요소를 add 메서드로 추가하여도 에러를 발생시키지않고 알아서^^ 무시한다. (알잘딱깔센~)

const set = new Set()

set.add(1).add(2).add(2)
console.log(set) // Set(2) {1, 2}

Set 객체는 객체나 배열과 같은 자바스크립트의 모든 값을 요소로 저장할 수 있다!

특정 요소 존재여부 확인

• Set.prototype.has 메서드 사용
• has 메서드는 불리언(boolean) 값 반환

const set = new Set([1, 2, 3])

console.log(set.has(2)) // true
console.log(set.has(4)) // false

그렇다면 요소를 삭제할 때는 어떤 메서드를 사용하면 될까? (우리가 잘 아는 그 단어!)

요소 (일괄)삭제

• Set.prototype.delete 메서드 사용
• delete 메서드는 삭제 성공여부를 불리언(boolean) 값 으로 반환

단, delete 메서드를 사용할 때는 삭제하려는 요소의 인덱스가 아니라 요소값 자체를 전달해야한다. Set 객체 특성의 3번째였던 내용을 떠올려보자. Set 객체는 배열과 다르게 인덱스로 요소에 접근할 수 없다. 고 하였다.

특정 요소말고 전체 삭제(일괄 삭제)를 하고 싶다면 Set.prototype.clear 메서드를 사용하면 되며, clear 메서드는 언제나 undefined 를 반환한다.

요소 순회

• Set.prototype.forEach 메서드 사용
• 콜백 함수와 forEach 메서드의 콜백 함수 내부에서 this 로 사용될 객체를 인수로 전달하며, 3개의 인수를 전달받음 (배열의 forEach 메서드와 유사)
  • 현재 순회 중인 요소값
  • 현재 순회 중인 요소값
  • 현재 순회 중인 Set 객체 자체

Set 객체는 이터러블 이므로 for...of문 으로도 순회할 수 있으며, 스프레드 문법 및 배열 디스트럭처링의 대상이 될 수도 있다.

집합 연산

• 교집합 intersection 메서드 사용
• 합집합 union 메서드 사용
• 차집합 difference 메서드 사용
• 부분집합 및 상위집합 isSuperset 메서드 사용

Map이란?

| Map 객체는 키와 값의 쌍으로 이루어진 컬렉션이다.

Set이 배열과 유사했다면, Map 객체는 객체와 유사하지만 몇 가지 차이점이 있는데 표로 살펴보자.

그렇다면 Map객체는 어떻게 생성할까? 방법은 Set객체와 동일하다.

Map 객체의 생성

| Map 생성자 함수로 객체를 생성한다.

단, Map 생성자 함수에 인수를 전달하지 않을 경우 빈 객체 가 생성된다.

// Map 생성
const map = new Map() // 인수 전달안함
console.log(map) // Map(0) {} 빈 객체 생성

Map 객체도 인수로 전달한 이터러블 중 중복된 키를 갖는 요소가 존재하면 값 덮어쓰기를 하므로 중복된 키를 갖는 요소가 존재할 수 없다.

Map 객체의 메서드

요소 개수 확인

• Map.prototype.size 프로퍼티 사용
• size 프로퍼티는 setter 함수없이 getter 함수만 존재하는 접근자 프로퍼티이기 때문에 요소 개수를 변경은 할 수 없다. (조회만 가능)

놀랍게도 Set 객체와 똑같은 내용...!

요소 추가

• Map.prototype.set 메서드 사용
• set 메서드는 호출할 때마다 새로운 요소가 추가된 Map객체를 반환하므로, 연속적인 호출가능

이 때, 중복된 요소를 set 메서드로 추가하여도 에러를 발생시키지않고 알아서^^ 덮어쓰기를 한다. (얘도 참 알잘딱깔센)

요소 취득

• Map.prototype.get 메서드 사용
• get 메서드의 인수로 전달한 키를 전달하면 Map 객체에서 전달된 키를 갖는 값을 반환하며, 존재하지 않을 경우에는 undefined 를 반환한다.

특정 요소 존재여부 확인

• Map.prototype.has 메서드 사용
• has 메서드는 불리언(boolean) 값 반환

요소 (일괄)삭제

• Map.prototype.delete 메서드 사용
• delete 메서드는 삭제 성공여부를 불리언(boolean) 값 으로 반환

특정 요소말고 전체 삭제(일괄 삭제)를 하고 싶다면 Map.prototype.clear 메서드를 사용하면 되며, clear 메서드는 언제나 undefined 를 반환한다.

요소 순회

• Map.prototype.forEach 메서드 사용
• 콜백 함수와 forEach 메서드의 콜백 함수 내부에서 this 로 사용될 객체를 인수로 전달하며, 3개의 인수를 전달받음 (배열의 forEach 메서드와 유사)
  • 현재 순회 중인 요소값
  • 현재 순회 중인 요소값
  • 현재 순회 중인 Map 객체 자체

Map 객체는 이터러블 이므로 for...of문 으로도 순회할 수 있으며, 스프레드 문법 및 배열 디스트럭처링의 대상이 될 수도 있다.

Set 은 배열과 닮은듯 다르고, Map 은 객체와 닮은듯 다른 형태의 자료구조인 것으로 정리해보자

이터러블 프로토콜이란?

| 순회 가능한 데이터 컬렉션(자료구조)을 만들기 위한 약속한 규칙이다.

ES6이전에는 각자의 방법으로 데이터 컬렉션을 순회하였지만, ES6에서는 이터러블 로 통일시켜 'for...of문', '스프레드 문법', '배열 디스트럭처링 할당' 의 대상으로 사용할 수 있도록 일원화했다.

이터러블이란?

| 이터러블 프로토콜을 준수한 객체를 의미한다.

Symbol.iterator 를 프로퍼티 키로 사용한 메서드를 직접 구현하거나 프로토타입 체인을 통해 상속받은 객체를 의미한다.

이터러블은 for...of문으로 순회할 수 있고, 스프레드 문법, 디스트럭처링 할당의 대상으로 사용할 수 있다. 반면, Symbol.iterator 메서드를 직접 구현하지 않거나 상속받지 않은 일반 객체는 이터러블이 아닌 것으로 판단되기 때문에 for...of문 순회, 스프레드 문법, 디스트럭처링 할당의 대상으로 사용할 수 없다.

이터레이터란?

| 이터러블의 Symbol.iterator 메서드를 호출하면 반환되는 것을 의미한다.

이터러블의 Symbol.iterator 메서드가 반환한 이터레이터는 next 메서드를 갖는다. 이 next 메서드는 이터러블의 각 요소 순회를 위한 포인터 역할을하는데, 순회 결과를 나타내는 이터레이터 리절트 객체를 반환한다.

이터레이터 리절트 객체 의 value 프로퍼티는 현재 순회 중인 이터러블의 값을 나타내고, done 프로퍼티는 이터러블의 순회 완료 여부를 나타낸다.

빌트인 이터러블

| 자바스크립트는 이터레이션 프로토콜을 준수한 객체인 빌트인 이터러블을 제공한다.

for...of 문

*| 이터러블을 순회하면서 이터러블의 요소를 변수에 할당한다. *

// 형태 - for...in문과 유사함
for (변수선언문 of 이터러블) {...}

1. for...of문은 내부적으로 이터레이터의 next 메서드를 호출하여 이터러블을 순회한다.
2. 그리고 next 메서드가 반환한 이터레이터 리절트 객체의 value 프로퍼티 값을 변수에 할당한다.
3. 이터레이터 리절트 객체의 done 프로퍼티 값이 false이면 순회를 계속하고 true이면 순회를 중단한다.

이터러블과 유사 배열 객체

마치 배열처럼 인덱스로 프로퍼티 값에 접근할 수 있고 length 프로퍼티를 갖는 객체를 말한다. 유사 배열 객체는 length 프로퍼티를 갖기 때문에 for문으로 순회가 가능하고, 배열처럼 인덱스로 프로퍼티 값에 접근도 가능하다.

단, 단어 그대로 '유사'배열 객체이기 때문에 Symbol.iterator 메서드가 없으므로 for...of 문으로의 순회는 할 수 없다.

그렇다면 이터레이션 프로토콜이 왜 필요할까?

이터러블은 데이터 소비자에 의해 사용되므로 데이터 공급자의 역할을 한다고 볼 수 있다. 만약, 다양한 데이터 공급자가 각자의 순회 방식을 갖는다면 데이터 소비자는 그에 맞는 방식을 모두 지원해야하는 불편함을 느끼게 된다. (비효율적이다)

그렇기때문에 다양한 공급자가 기준인 이터레이션 프로토콜을 준수하도록 규정하면 데이터 소비자는 이터레이션 프로토콜만 지원하도록 구현하면 되므로 무척 효율적이다. (소비자와 공급자를 연결해주는 인터페이스 역할)

사용자 정의 이터러블

이터레이션 프로토콜을 준수하지 않는 일반 객체도 준수하도록 구현을 하면 사용자 정의 이터러블이 될 수 있다. 이를 통해 다양하게 활용을 할 수 있는데, 대표적인 예시로는 다음 두 가지가 있다.

• 피보나치 수열 구현
• 무한 수열 구현

위 두 가지의 공통점이 있는데, 바로. 지연 평가를 통해 데이터를 생성한다는 것이다. 지연 평가 란 데이터가 필요한 시점 이전까지는 데이터를 생성하지 않다가 필요한 시점이 되면 데이터는 생성하는 기법이다.

지연 평가 를 사용하면 불필요한 데이터를 미리 생성하지 않고 필요한 순간에 생성하기 때문에 실행 속도가 향상되고, 불필요한 메모리 소비를 하지않아 '무한'도 표현할 수 있다는 장점이 있다.

들어가면서,

자바스크립트가 ECMAScript로 표준화되면서 6개의 타입(문자열, 숫자, 불리언, undefined, null, 객체 타입)이 존재하게 된다.

그런데 ES6에서 7번째 데이터 타입으로 등장한 것이 있는데, 그게 바로 이번 장에서 살펴볼 Symbol(심벌) 이다.

Symbol(심벌) 은 다른 값과 중복되지 않는 유일무이한 값 으로, 주로 충돌 위험이 없는 유일한 프로퍼티 키를 만들때 사용한다.

Symbol(심벌)

그렇다면 변경 불가능한 원시 타입의 값인 Symbol(심벌)은 어떻게 생성할까?

Symbol(심벌) 생성

*| 심벌 값은 Symbol 함수를 호출하여 생성하며, 생성된 심벌 값은 외부로 노출되지 않기때문에 확인할 수가 없다. *

// 심벌 값 생성
const mySymbol = Symbol()

console.log(mySymbol) // Symbol()

Symbol 함수에는 선택적으로 '문자열' 을 인수로 전달할 수 있는데, 전달하는 '문자열'은 심벌 값에 대한 설명 으로, 디버깅 용도로만 사용하며 심벌 값 생성에는 영향을 미치지 않는다.

const mySymbol = Symbol('hello')

console.log(mySymbol) // Symbol(hello)
console.log(mySymbol.description) // hello
console.log(mySymbol.toString()) // Symbol(hello)

console.log(typeof mySymbol) // symbol
console.log(typeof mySymbol.toString()) // string

Symbol(심벌)의 메서드

1️⃣ Symbol.for

| 인수로 전달받은 문자열을 '키'로 사용하여 '키'와 심벌 값의 쌍들이 저장되어 있는 전역 심벌 레지스트리에서 해당 '키'와 일치하는 심벌 값을 검색하는 메서드이다.

• (검색 성공) 새로운 심벌 값을 생성하지 않고, 검색된 심벌 값을 반환한다.
• (검색 실패) 새로운 심벌 값을 생성하여 메서드의 인수로 전달된 '키'로 레지스트리에 저장한 다음 생성된 새로운 심벌 값을 반환한다.

Symbol 함수는 호출될 때마다 유일무이한 값을 생성하는데, 생성 당시에는 심벌 값 저장소인 레지스트리에서 해당 심벌 값을 검색할 수 있는 '키'가 지정되어 있지 않기 때문에 전역 심벌 레지스트리에 등록 및 관리되지 않는다.

하지만, Symbol.for 메서드를 사용하면 전역에서 중복되지 않는 유일무이 한 심벌 값을 생성하므로 레지스트리를 통해 공유가능한 상태가 되어 관리가 가능해진다.

2️⃣ Symbol.keyFor

| 전역 심벌 레지스트리에 저장된 심벌 값의 '키'를 추출할 수 있는 메서드이다.

// Symbol.for 메서드를 사용하여 심벌 값 생성 → 관리 ✅
const s1 = Symbol.for('mySymbol')
Symbol.keyFor(s1) // mySymbol

// Symbol 함수를 사용하여 심벌 값 생성 → 관리 ❌
const s2 = Symbol('haha')
Symbol.keyFor(s2) // undefined

심벌 값은 다음과 같이 다양하게 활용될 수 있는데, 활용되는 경우들을 간단하게 살펴보자.

• 상수를 정의할 때 심벌 값으로 상수 값을 생성한다.
• 심벌 값으로 프로퍼티 키 를 동적으로 생성할 수 있는데, 심벌 값을 프로퍼티 키로 사용하려면 심벌 값에 대괄호 를 사용하면 된다. (접근할 때도 대괄호 는 써주기!)
• 심벌 값을 프로퍼티 키로 사용하여 생성한 프로퍼티는 for...in, Object.keys 등의 메서드로 찾을 수 없으므로 외부에 노출할 필요가 없는 프로퍼티 은닉이 가능하다. (단, ES6에서 도입된 Object.getOwnPropertySymbols 메서드 사용시에는 찾을 수 있다)

또한, 심벌 값의 몇 가지 특징으로는 다음과 같은 내용이 있다.

• 일반적으로 표준 빌트인 객체에 사용자 정의 메서드를 직접 추가하여 확장하는 것은 권장하지 않으며, 읽기 전용으로 사용하는 것을 권장한다.
• 자바스크립트가 기본적으로 제공하는 빌트인 심벌 값이 있으며, Well-known-Symbol 이라고 부른다.

정규표현식이란?

| 일정한 패턴을 가진 문자열의 집합을 표현하기 위해 사용하는 형식 언어이다.

정규표현식은 문자열을 대상으로 패턴 매칭 기능을 제공한다. (패턴 매칭 기능: 특정 패턴과 일치하는 문자열을 검색하거나 추출 또는 치환할 수 있는 기능)

정규표현식 사용시, 반복문과 조건문없이 패턴을 정의하고 테스트하여 문자열 체크를 할 수 있다. (단, 주석 또는 공백은 허용되지 않으며 여러 기호를 혼합하여 사용하기때문에 가독성은 좋지 않다.)

정규표현식 생성

정규표현식 생성방법에는 두 가지 방법이 있다.

1️⃣ 정규 표현식 리터럴 2️⃣ RegExp 생성자 함수

일반적으로는 정규 표현식 리터럴을 사용한다.

정규 표현식 리터럴은 패턴 과 플래그 로 구성된다.

여기서 패턴 과 플래그가 무엇인지 궁금할텐데, 곧 나오니 일단 예제만 확인하고 넘어가자 😉

const target = 'Is this all there is?'

// 패턴: is
// 플래그: i (대소문자 구별 ❌)
const regexp = /is/i

// test 메서드: 문자열에 대해 정규 표현식 regexp 패턴을 검색하여
// 매칭결과를 불리언 값으로 반환
regexp.test(target) // true

RegExp 메서드

정규 표현식을 사용하는 메서드는 다양하게 있지만, 이번 31장 에서는 3가지만 살펴보자.

1️⃣ RegExp.prototype.exec

인수로 전달받은 문자열에 대해 정규 표현식의 패턴을 검색하여 매칭 결과를 배열로 반환하며, 매칭 결과가 없는 경우에는 null 을 반환한다. (단, 문자열 내의 모든 패턴을 검색하는 g 플래그로 지정해도 첫 번째 매칭 결과만 반환한다.)

const target = 'Is this all there is?'
const regExp = /is/

regExp.exec(target)
// ["is", index: 5, input: "Is this all there is?", groups: undefined]

2️⃣ RegExp.prototype.test

인수로 전달받은 문자열에 대해 정규 표현식의 패턴을 검색하여 검색 결과를 불리언 값 으로 반환한다.

const target = 'Is this all there is?'
const regExp = /is/

regExp.test(target) // true

3️⃣ String.prototype.match

대상 문자열과 인수로 전달받은 정규 표현식과의 매칭 결과를 배열로 반환한다.

✋🏻 잠깐! 그렇다면 exec 메서드와 어떤 차이점이 있을까? exec 메서드는 모든 패턴을 검색하는 g 플래그로 지정을 해도 첫 번째 매칭 결과만 반환한다고 했다. 하지만, match 메서드는 g 플래그가 지정되면 모든 매칭 결과를 반환한다는 점이 다르다.

// g플래그 미지정
const target = 'Is this all there is?'
const regExp = /is/

target.match(regExp)
// ["is", index: 5, input: "Is this all there is?", groups: undefined]

// g플래그 지정
const target = 'Is this all there is?'
const regExp = /is/g

regExp.test(target) // ["is", "is"]

플래그

| 플래그는 정규 표현식의 검색 방식을 설정하기 위해 사용한다.

플래그는 총 6가지가 있지만, 중요한 3가지만 살펴보자. (TOP3)

이러한 플래그는 옵션 이므로 선택하여 사용할 수 있으며, 순서 상관없이 하나 이상의 플래그를 동시에 설정할 수도 있다.

아무런 플래그를 사용하지 않을 경우에는 기본적으로 대소문자를 구별하여 패턴검색을 한다. 또한, 문자열에 검색 매칭 대상이 1개 이상 존재한다고해도 첫 번째 매칭한 대상만 검색 후 종료한다.

const target = 'Is this all there is?'

target.match(/is/)
// ["is", index: 5, input: "Is this all there is?", groups: undefined]

target.match(/is/i)
// ["Is", index: 0, input: "Is this all there is?", groups: undefined]

target.match(/is/g) // ["is", "is"]

target.match(/is/ig) // ["Is", "is", "is"]

패턴

| 문자열의 일정한 규칙을 표현하기 위해 사용한다.

/ 로 열고 닫으며 문자열 따옴표 는 생략한다. 따옴표 를 생략하는 이유는 포함할 경우, 따옴표까지 패턴에 포함하여 검색하기 때문이다.

패턴은 특별한 의미를 가지는 메타문자 또는 기호 로도 표현할 수 있다.

그렇다면 패턴을 표현하는 방법에는 어떤 내용이 있는지 살펴보자.

1️⃣ 문자열 검색

패턴에 문자 또는 문자열을 지정하면 검색 대상 문자열에서 지정 문자/문자열을 검색한다.

검색 수행은 RegExp 메서드를 사용하여 검색 대상 문자열과 정규 표현식의 매칭 결과를 구할때 이루어진다.

이 때, 플래그를 생략하면 대소문자를 구별하여 매칭 진행을 한 후 첫 번째 결과만 반환하는데, 대소문자 구별없이 검색을 해야할 경우에는 i 플래그 를 사용한다. (첫 번째 결과만 반환되는 내용은 동일하게 적용됨)

2️⃣ 임의의 문자열 검색

. 은 임의의 문자 한 개 를 의미하는데, 문자의 내용은 무엇이든 상관없다.

즉, . 의 갯수는 문자열의 자릿수를 의미하는 것이다.

• ... 3자리 문자열
• .. 2자리 문자열
• ..... 5자리 문자열

3️⃣ 반복 검색

{m,n} 은 패턴이 최소 m번, 최대 n번 반복되는 문자열을 의미하며, 콤마 뒤에 공백 이 있으면 정상 동작하지 않는다.

패턴이 {n} 인 경우에는 패턴이 n번 반복되는 문자열을 의미한다. ({n,n} 과 동일의미) {n,} 패턴의 경우는 최소 n번 반복디는 문자열을 의미한다.

const target = 'A AA B BB Aa Bb AAA'

const regExp = /A{1,2}/g

target.match(regExp) // ["A", "AA", "A", "AA", "A"]

+ 가 붙는 경우가 있는데, 이 경우는 패턴이 최소 한 번 이상 반복되는 문자열을 의미힌다. ({1,} 와 동일한 의미이다.)

const target = 'A AA B BB Aa Bb AAA'

const regExp = /A+/g

target.match(regExp) // ["A", "AA", "A", "AAA"]

? 는 패턴이 최대 한 번(0번 포함) 이상 반복되는 문자열을 의미한다. ({0,1} 와 동일한 의미이다.)

4️⃣ OR 검색

| 가 or의 의미를 갖는다.

const target = 'A AA B BB Aa Bb AAA'

const regExp = /A|B/g

target.match(regExp) // ["A", "A", "A", "B", "B", "B", "A", "B"]

이 외에도 다양한 형태로 or 의 개념이 사용된다.

• 분해되지 않은 단어로 검색하려면 + 를 같이 사용하면 된다. ⇒ /A+|B+/g
• 범위를 지정하기를 원하면 [] 기호 내에 -를 사용하면 된다. ⇒ /[A-Z]+/g
• 대소문자 구별없이 알파벳을 검색하고 싶을 때는 이렇게 사용하면 된다. ⇒ `/[A-Za-z]+/g``
• 숫자를 검색하고 싶을 때는 이렇게 사용하면 된다. ⇒ /[0-9 ]+/g
• 숫자를 검색을 하되 결과에 쉼표로 구분짓고 싶지 않으면 ,를 패턴에 포함시키면 된다. ⇒ /[0-9,]+/g

5️⃣ NOT 검색

[...] 내의 ^ 는 not 을 의미한다.

• [^0-9] 는 숫자를 제외한 문자를 의미한다.

6️⃣ 시작 위치로 검색

[...] 밖의 ^ 는 문자열의 시작을 의미한다.

• /^https/ 는 문자열이 'https' 로 시작하는지 검사한다는 의미이다.

7️⃣ 마지막 위치로 검색

$ 은 문자열의 마지막을 의미한다.

• /com$/ 은 문자열이 'com'으로 끝나는지 검사한다는 의미이다.

자주 사용하는 정규표현식

위 패턴들을 이용하여 유독 자주 사용하는 정규표현식들이 있다.

• 특정 단어로 시작하는지 검사
• 특정 단어로 끝나는지 검사
• 숫자로만 이루어진 문자열인지 검사 (^\d+$ 사용)
• 하나 이상의 공백으로 시작하는지 검사 (\s 사용)
• 아이디로 사용가능한지 검사 (알파벳 구분없이 + 반복 패턴 활용)
• 메일주소 형식에 맞는지 검사
• 핸드폰번호 형식에 맞는지 검사 (^\d{3]-\d{3,4}\d{4}$ 사용)
• 특수문자 포함여부 검사 ([^A-Za-z0-9] 사용)

Next.js란?

| React 기반의 메타 프레임워크로 웹 애플리케이션을 구축하는데 사용하는 도구이다.

React는 UI구성에 포커스를 맞춘 라이브러리인 반면, Next.js는 React 개념에 렌더링과 서비스 제공에 특화된 추가 기능을 더해서(+) 제공하는 프레임워크이다.

✋🏻 잠깐! 라이브러리 와 프레임워크 는 어떤거고, 무슨 차이가 있는거야? 🗂️ 라이브러리 는 개발자가 특정 기능이 필요할 때 호출하는 코드 모음이다. ⚙️ 프레임워크 는 애플리케이션의 전체적인 구조와 흐름을 제공하며, 개발자가 그 틀 안에서 작업하도록 제어권을 가진다.

Next.js가 가진 가장 큰 장점은 복잡한 도구설정의 자동화가 가능하다는 것이다. 번들링, 컴파일 등의 작업을 내부적으로 알아서 처리하므로 개발자는 설정에 보내는 시간을 줄여 애플리케이션 구축에 더욱 집중할 수 있다. (알잘딱깔센 Next.js 최고)

그렇다면 React의 어떤 부분이 아쉬워서 Next.js가 나오게 된걸까?

React만으로는 부족한 이유

리액트는 UI 라이브러리로, 화면구성에 특화되어있다. 반면 프로덕션 애플리케이션에 필요한 모든 기능을 제공하지는 않기때문에 리액트만을 이용해서 개발을 하기엔 부족하다.

React 와 Next.js 의 개발환경에는 어떤 차이가 있을까?

React 개발환경

위에서 봤듯이 리액트는 UI 라이브러리이기 때문에, 개발에 필요한 기능은 개발자가 파악하고 직접 추가해야한다. 자주 쓰이는 개발에 필요한 기능은 다음과 같다.

• 상태관리: Zustand, Redux 등
• 데이터 가져오기: axios, fetch 등
• 라우팅: React Router, Tanstack Router 등
• 번들링: webpack, esbuild, Rspack 등
• 이미지 최적화: 상황별 별도 도구 필요
• 코드 분할: 수동 설정 필요

Next.js 개발환경

Next.js는 React 프레임워크로 실제 개발에 필요한 대부분의 기능이 포함되어 자동처리된다. (편리성 Good)

• SSR(서버 사이드 렌더링)을 기본적으로 지원한다.
• 라우팅 시스템과 상태 관리 패턴이 빌트인 되어있다.
• 표준 fetch API 를 활용한다.
• 캐싱 시스템이 있다.
• 자동 번들링 및 최적화, 이미지/폰트 자동 최적화를 해준다.
• 자동 코드 분할이 가능하다.

Next.js의 주요기능

| Next.js는 개발에 필요한 모든 기능을 통합적으로 제공한다.

Next.js의 라우터 방식

Next.js는 다음의 두 가지 라우터 방식을 제공한다.

1️⃣ App Router (권장)

• 리액트의 최신 기능을 활용한다. (서버 컴포넌트, 스트리밍 등)
• 더 직관적인 파일 구조를 가지고 있다.
• 향상된 성능과 개발자 경험이 제공된다.

2️⃣ Page Router (레거시)

• 최초의 Next.js 라우터이다.
• 기존에 계속 진행해오던 Next.js 프로젝트에서 사용한다.
• 호환성 유지를 위해서 지속적인 지원은 이루어진다.

*⇒ 프로젝트를 새로 시작하는 경우에는 '앱 라우터' 사용을 권장한다. *

Next.js를 사용해야하는 이유

• 개발 생산성 향상 복잡한 설정없이 개발에만 집중할 수 있다.
• 성능 최적화 다양한 최적화 기능들이 자동으로 적용된다.
• SEO 친화적 서버 사이드 렌더링으로 SEO(검색 엔진 최적화)가 용이하다.
• 확장성 개인 프로젝트부터 대규모까지 광범위하게 대응이 가능하다.
• 활발한 생테계 Vercel의 지속적인 지원과 활말한 커뮤니티를 통해 풍부한 리소스를 제공한다.

Next.js의 장점

1. 빠른 페이지 로딩

• Next.js는 페이지를 미리 렌더링하여 클라이언트로 전송한다.
• React의 기본 방식인 클라이언트 렌더링보다 초기 로딩 시간이 단축되기때문에 사용자 경험이 향상된다.

  2. 검색 엔진 최적화

• 완성된 HTML이 서버에서 전송되므로 검색 엔진의 콘텐츠 인덱싱이 용이하다.
• 공유 시, 미리보기가 지원되어 검색 엔진 최적화 서비스를 제공할 수 있다.

  3. 빌트인 최적화 기능

• Next.js가 웹 폰트, 이미지 등을 자동으로 처리하여 최적화한다.

  4. React가 서버 컴포넌트

• 리액트 서버 컴포넌트(RSC)는 서버에서 실행된다.
• 새로운 기능도입으로 RSC를 Next.js로 안정적이게 사용가능하다.

Next.js vs. React

| React: 기본적으로 클라이언트 환경에서 작동한다. 1️⃣ 서버에서 빈 HTML 다운로드 2️⃣ 서버에서 JavaScript 다운로드 3️⃣ 클라이언트에서 모든 렌더링 수행

| Next.js: 기본적으로 서버 환경에서 작동한다. 1️⃣ 서버에서 HTML 생성 2️⃣ 완성된 HTML을 클라이언트에 전송 3️⃣ 수화(Hydration) 과정으로 React 연결

✋🏻 잠깐! 수화(Hydration)가 무슨 의미야? 서버에서 생성된 HTML에 React 기능을 연결하는 과정을 의미한다. 이 과정에서 정적 HTML이 동적 React 컴포넌트로 변환된다. 덕분에 사용자는 즉시 컨텐츠를 볼 수 있고, 상호작용도 가능해진다.

🔗 참고자료 https://nextjs.org/docs https://vercel.com/frameworks/nextjs

웹 개발의 진화

*| PHP → RSC *

LAMP스택과 PHP시대

오래 전, 대부분의 개발자들이 풀스택 개발의 시작점이였던 LAMP 스택(Linux, Apache, MySQL, PHP) 로 풀스택 웹 개발을 시작했다.

PHP 는 HTML 의 상위 집합으로 모든 HTML문서가 유효한 PHP문서가 될 수 있다. (호환가능!)

서버는 PHP파일을 해석하여 동적으로 HTML을 생성하고 사용자에게 전달한다.

<?php
    # 사이트 제목 변수
  $siteTitle = "트렌드에 민감한 MZ!";

  # 데이터베이스 연결
  $link = mysqli_connect("localhost", "root", "passwerd");
  # 데이터베이스에서 products 데이터 가져오기
  §data = mysqli_query($link, "SELECT * FROM products");
?>

<!DOCTYPE html>
<html lang="ko-KR">
  <head>
    <meta charset="UTF-8" />
    <title><?php echo $siteTitle ?></title>
  </head>
  <body>
    <main>
      <h1>트렌드 제품</h1>
      <?php 
        while ($item = mysqli_fetch_array($data)) {
          echo "<article>";
            echo "<h2>" . $item['title'] . "</h2>";
            echo "<p>" . $item['description'] . "</p>";
          echo "</article>";
        }
      ?>
    </main>
  </body>
</html>

php 특징

• HTML과 자유롭게 섞어서 사용할 수 있다.
• 서버에서 실행되기 때문에 완전히 정적인 HTML을 반환한다.
• 데이터베이스(MySQL 등) 와 직접 연결하여 데이터를 가져올 수 있다.
• 개발 방식이 직관적이고 선언적이다.

php 한계

• 동적 인터랙션(기사 재정렬, 삭제 등)은 자바스크립트 등 별도의 언어가 있어야 처리가 가능하다.
• 서버에서만 실행되기 때문에 클라이언트와의 상호작용이 제한적이다.

React와 CSR

초기의 리액트 앱은 대부분 클라이언트에서 데이터 요청을 처리했다. 브라우저에서 직접 데이터베이스 쿼리를 할 수 없어서 API 엔드포인트 로 데이터를 받아서 처리했다. (SWR;Stale-Whie-Revalidate 라이브러리 사용)

import useSWR from 'swr'

// 데이터 가져오기 함수
async function fetcher(endpoint) {
  const response = await fetch(endpoint)
  const json = await response.json()
  return json
}

// 클라이언트 컴포넌트
function TrendingProducts() {
  // 데이터 가져오기 요청
  // - data: null
  // - isLoading: true
  const { data, isLoading } = useSWR(
      '/api/get-trending-products', 
      fetcher
    )

  if (isLoading) {
    return <p>데이터 로딩중...</p>
  }

  return (
    <main>
      <h1>트렌드 제품</h1>
      {data.map((item) => (
        <article key={item.id}>
          <h2>{item.title}</h2>
          <p>{item.description}</p>
        </article>
      ))}
    </main>
  )
}

CSR의 특징

• 데이터는 페이지 로드 후, 네트워크 요청을 받아온다.
• 첫 렌더링 시에는 데이터가 없으므로 로딩 상태관리가 필요하다.
• 사용자 경험이 PHP보다 복잡하고 때로는 느릴 수 있다.

Next.js와 SSR

CSR의 문제점을 보완하고 해결하기 위해 Next.js 가 등장했다. (두-둥!)

Next.js는 서버에서 먼저 데이터를 가져와서 렌더링하는 SSR(Server Side Rendering)을 지원한다.

SSR의 특징

• 페이지를 요청하면 서버가 먼저 데이터를 가져와서 렌더링한다.
• getServerSideProps 와 같은 특별한 메서드를 사용하여 데이터를 패칭한다.
• 초기 UI가 서버에서 완성된 상태로 사용자에게 전달된다.
• 페이지 수준에서만 SSR을 적용할 수 있다.

SSR의 한계

• SSR은 Next.js, Gatsby, Remix 등 프레임워크마다 방식이 다르다. ⇒ 표준화 부족
• SSR 컴포넌트도 클라이언트에서 다시 실행(수화;Hydration) 된다. ⇒ CPU 비용부담 및 성능부담 증가
• 페이지 최상단에서만 SSR 로직을 사용할 수 있다.

RSC 등장

서버와 클라이언트의 경계를 더욱 분명히 하고자 나온 것이 RSC(React Server Components) 이다.

RSC의 특징

• 서버/클라이언트에서 실행되는 컴포넌트를 명확히 구분한다.
• 서버 컴포넌트에서는 상태, 이펙트 등 클라이언트 전용 기능을 사용할 수 없다.
• 클라이언트 컴포넌트는 "use client" 라고 디렉티브를 명시해주어야 한다.
• 기본값은 서버 컴포넌트이며, 클라이언트 컴포넌트는 옵트인(Opt-in) 이다.
• 두 컴포넌트는 자유롭게 혼합하여 사용할 수 있다. (이것이 RSC의 장점)

RSC의 장점

• 서버에서만 실행되는 컴포넌트는 클라이언트로 코드가 전송되지 않는다. (SSR의 '클라이언트에서 다시 실행됨으로 인해 CPU 비용부담 및 성능부담 증가' 내용 보완)
• 데이터베이스 요청, API호출 등 서버 작업을 컴포넌트 내부에서 직접 수행 가능하다.
• 클라이언트 컴포넌트와 조합하여 동적 인터랙션을 구현할 수 있다.

정리하자면,

RSC는 아직은 새로운 개념에 가까우며, SSR과는 별개의 패러다임이다. 그렇다고 각각 독립적으로 사용하기보다는 함께 사용할 때 더 큰 시너지효과를 낸다.

RSC와 SSR 각각에 해당되는 앱/방식을 살펴보자.

표준 클라이언트 앱

• 일반적으로 브라우저에서 실행되는 리액트 앱을 의미한다.
• SSR이나 RSC없이 모든 UI와 로직이 클라이언트에서 작동한다.

서버 렌더링 앱

• SSR을 사용하면 서버에서 HTML을 미리 렌더링하여 사용자에게 전달할 수 있다.
• 초기 로딩속도가 빠르며, SEO(검색엔진 최적화)에 유리하다.
• RSC만으로는 전통적인 SSR앱을 구현할 수 없기에 함께 사용하는 것이 권장된다.

RSC 페이로드

• RSC에서 서버가 클라이언트로 데이터를 전달하는 형식이다.
• 서버에서만 실행되는 컴포넌트의 특성을 활용할 수 있다.
• SSR에서는 RSC의 기능을 사용할 수 없다.

모던 풀스택 React

• 최신 Next.js 에서 지원하는 방식이다.
• SSR과 RSC를 모두 활용하여 서버 및 클라이언트의 경계를 명확히 한다.
• 효율적인 데이터 패칭 및 UI렌더링이 가능하다.
• SSR과 RSC가 함께 사용될 때 가장 강력한 풀스택 개발 환경이 만들어진다.

✋🏻 잠깐! 살펴본 내용중에 서버 컴포넌트, 클라이언트 컴포넌트라는 말이 자주 나왔다.

여기서 서버 컴포넌트는 이름에서도 유추할 수 있듯이 서버에서만 렌더링되는 것이 맞지만, 클라이언트 컴포넌트는 이름과는 달리 서버 및 클라이언트. 즉, 모든 환경에서 렌더링이 된다는 점을 기억하자!

** 🔗 참고자료** https://www.php.net/ https://www.digitalocean.com/community/tutorials/how-to-install-lamp-stack-on-ubuntu https://nextjs.org/docs/app/getting-started/server-and-client-components https://swr.vercel.app/ko

CSR 이란?

| Client Side Rendering 즉, 클라이언트 측에서 렌더링하는 것을 의미한다.

브라우저가 자바스크립트를 실행하여 클라이언트에서 화면을 동적으로 렌더링하는 것이다.

전체적인 사이트 구조와 기능을 자바스크립트 코드로 클라이언트에게 전달한 후 브라우저에서 리액트가 직접 화면을 생성하고 상호작용하도록 하는 방식이 CSR 이다.

CSR 작동방식

1️⃣ 사용자가 사이트에 접속한다. 2️⃣ 브라우저가 HTML, CSS, JavaScript 파일을 다운로드 한다. 3️⃣ 브라우저가 JavaScript 를 실행하여 화면을 동적으로 만든다. 4️⃣ 이후 페이지 이동 또는 데이터 변경도 모두 브라우저에서 처리한다.

⇒ 모든 것은 브라우저에서 이루어진다. ⭐️

CSR의 장점

• 서버 부담이 적다. 서버는 정적인 파일만 전달하면 되므로 단순한 작업만 하면된다.
• 앱처럼 부드러운 화면 전환이 가능하다. SPA(Single Page Application) 방식으로 페이지 전체를 리로딩하는 것이 아니라 일부만 변경할 수 있다.
• 동적 기능 구현에 용이하다. 사용자와의 상호작용이 많거나, 실시간 데이터가 필요한 서비스에 적합하다.

CSR의 단점

• 초기 로딩이 느릴 수 있다. 브라우저가 모든 JavaScript 를 받아 실행하므로 첫 화면 로딩이 늦게 보일 수 있다.
• SEO(Search Engine Optimization;검색엔진 최적화)에 불리하다. 검색엔진이 JavaScript 를 실행하지 못하면 콘텐츠를 제대로 인식하지 못할 수 있다.

SSR 이란?

| Server Side Rendering 즉, 서버 측에서 렌더링하는 것을 의미한다.

서버(Node.js 등)가 사전에 HTML을 만들어서 브라우저(클라이언트)에게 전달하는 방식이다.

동일한 전체 사이트를 Node.js 에서 작동시킨 후, 이를 HTML로 사전 렌더링한다. 그리고 마지막으로 이를 클라이언트의 리액트(프론트엔드 프레임워크)에서 가져오도록 하는 것이다.

SSR 작동방식

1️⃣ 사용자가 사이트에 접속한다. 2️⃣ 서버가 React 등 프레임워크를 실행하여 해당 페이지의 HTML 을 생성한다. 3️⃣ 서버는 완성된 HTML 을 브라우저로 전달한다. 4️⃣ 브라우저는 전달받은 HTML 을 바로 보여준다. 5️⃣ 이후 리액트 프레임워크가 작동하며 인터랙티브한 기능을 제공한다.

SSR의 장점

• 초기 로딩이 빠르다. 브라우저가 완성된 HTML을 바로 보여주므로 사용자가 내용을 빠르게 볼 수 있다.
• SEO(Search Engine Optimization;검색엔진 최적화)에 유리하다. 검색엔진이 HTML을 쉽게 읽을 수 있기때문에 검색결과 노출에 유리하다.
• 공유 및 미리보기가 편리하다. 링크 공유시, 미리보기 이미지와 텍스트가 잘 표시된다.

SSR의 단점

• 서버 부하가 크다. 사용자가 많으면 서버가 HTML을 계속 만들어야 하므로 서버의 성능이 중요하다.
• 서버와 클라이언트 모두에서 코드를 실행해야 하므로 복잡성이 증가한다.

CSR vs. SSR

• 각 방식마다 장단점이 있으므로 서비스의 목적과 상황에 맞게 선택해서 활용하는 것이 좋다.

🔗 참고자료 https://nextjs.org/docs/pages/building-your-application/rendering/client-side-rendering https://nextjs.org/docs/pages/building-your-application/rendering/server-side-rendering https://nextjs.org/docs/app/guides/migrating/from-vite https://ko.vite.dev/guide/ssr

클래스 정의방법

• 클래스는 class 키워드를 사용하여 정의한다.
• 생성자 함수와 마찬가지로 파스칼 케이스를 사용한다. (단, 파스칼 케이스를 사용하지 않아도 에러가 발생하지는 않는다🤷🏻‍♀️)
• 일반적이지는 않지만 표현식으로 정의할 수도 있다. ⇒ 값으로 사용할 수 있는 일급 객체 이다. (즉, 클래스는 함수다.)

// 기본형태
class Person {}

// 표현식 정의형태
// 익명 클래스 표현식
const Person = class {}

// 기명 클래스 표현식
const Person = class Myclass {}

클래스의 메서드

클래스 몸체에서는 다음 세 가지의 메서드를 정의할 수 있다.

• 생성자(constructor)
• 프로토타입 메서드
• 정적 메서드

클래스와 생성자함수의 정의방식은 참 닮았는데 비교해보면 다음과 같다.

클래스의 호이스팅

앞서 살펴본 것처럼 클래스는 함수이다.

다음과같이 클래스 선언문으로 정의한 클래스는 함수 선언문처럼 평가 과정 이전에 먼저 평가되어 함수 객체를 생성한다.

class Person {}

console.log(typeof Person) // ?

생성된 함수 객체는 생성자 함수로서 호출할 수 있는 생성자(constructor) 이다. 함수 객체 생성시점에 프로토타입 도 더불어 생성이 된다. 이 때, 19장.프로토타입-리터럴 표기법에 의해 생성된 객체의 생성자 함수와 프로토타입 에서도 살펴본 바와같이 생성자 함수와 프로토타입은 단독으로 존재할 수 없고 언제나 쌍으로 존재한다.

단, 클래스는 정의 이전에 참조할 수 없다. 그래서 호이스팅이 발생하지 않는 것처럼 보이지만 그렇지 않다.

클래스 선언문도 변수 선언, 함수 정의와 마찬가지로 호이스팅이 발생하는데, let, const 키워드로 선언한 변수처럼 발생한다.

✋🏻 잠깐! 이게 무슨 소리야? let, const 키워드로 선언된 건 뭐가 다른데? let, const 키워드로 선언한 변수는 일시적 사각지대(TDZ; Temporal Dead Zone) 에 빠지게된다.

즉, 클래스 선언문도 TDZ 에 빠지게 되므로 호이스팅이 발생했지만 하지않은 것처럼 보이는 것이다.

var, let, const, function, class 키워드로 선언된 모든 식별자는 호이스팅 된다. 왜? 모든 선언문은 런타임 이전에 실행되기 때문이다.

클래스의 인스턴스 생성

| 클래스는 생성자 함수이며, new 연산자와 함께 호출되어 인스턴스를 생성한다.

클래스의 존재이유는 인스턴스 생성이다. 그렇기 때문에 반드시 new 연산자와 함께 호출해야한다.

class Person {}

// ❌ 잘못 호출한 경우 → 에러발생
const me = Person()
// TypeError: Class constructor cannot be invoked without 'new'

// ✅ 올바르게 호출한 경우
const me = new Person()

인스턴스 생성 조건1. new 연산자로 호출해라

또한, 클래스 표현식으로 정의된 클래스의 경우에는 식별자를 사용해 인스턴스를 생성하지 않고, 기명 클래스 표현식의 클래스 이름을 사용해 인스턴스를 생성하면 에러가 발생한다.

const Person = class MyClass {}

const me = new Person()

console.log(MyClass) // 

위와같은 오류가 발생하는 이유는 클래스 표현식에서 사용한 클래스 이름은 외부 코드에서는 접근이 불가능하기 때문이다. (like 기명함수 표현식)

인스턴스 생성 조건2. 클래스를 가리키는 식별자를 사용하여 인스턴스를 생성해라

클래스의 메서드

클래스 몸체에서 정의할 수 있는 메서드는 클래스의 정의방법에서도 살펴본 것처럼 세 가지가 있다.

• 생성자(constructor)
• 프로토타입 메서드
• 정적 메서드

생성자(constructor)

| 인스턴스를 생성하고 초기화하기 위한 특수한 메서드이며, 이름을 변경할 수 없다.

클래스 생성자(constructor)의 특징

• 클래스 내에 최대 한 개만 존재할 수 있다. (만약 2개 이상의 포함하게되면 문법 에러가 발생한다.)
• 생략할 수 있다. → 생략시, 빈 constructor가 암묵적으로 정의된다.
• 프로퍼티 추가로 인스턴스 초기화 생성이 필요하다면 constructor 내부에서 this 에 인스턴스 프로퍼티를 추가한다. ⇒ 인스턴스 초기화를 위해서는 constructor를 생략하면 안된다.
• 별도의 반환문을 갖지 않아야 한다. 이 부분은 17장.생성자 함수에 대한 객체 생성에서도 살펴보았듯이, 명시적으로 this 가 아닌 다른 값을 반환하는 것은 클래스의 기본 동작을 방해하는 것이기 때문에 반드시 반환문을 생략해야 한다.

프로토타입 메서드

| 클래스 몸체에서 정의한 메서드는 생성자 함수에 의한 객체 생성 방식과는 다르게 기본적으로 프로토타입 메서드가 된다.

또한, 생성자 함수와 마찬가지로 클래스가 생성한 인스턴스는 프로토타입 체인에 포함된다.

클래스 몸체에서 정의한 메서드는 객체의 프로토타입에 존재하는 프로토타입 메서드가 되며, 객체는 프로토타입 메서드를 상속받아 사용할 수 있다.

프로토타입 체인은 기존의 모든 객체 생성방식(객체 리터럴, 생성자 함수 등), 클래스에 의해 생성된 객체에도 동일하게 적용된다. 클래스는 생성자 함수의 역할을 하는 즉, 객체를 생성하는 생성자 함수라고 볼 수 있다.

정적 메서드

19장.프로토타입-정적 프로퍼티/메서드 에서도 살펴보았듯이 정적 메서드는 인스턴스를 생성하지 않아도 자신의 프로퍼티와 메서드를 가지기 때문에 호출할 수 있는 메서드이다.

생성자 함수에서는 정적 메서드를 다음과 같이 명시적으로 추가를 했다.

function Person(name) {
  this.name = name
}

// 정적 메서드 생성
Person.sayHi = function() {
  console.log("Hi!")
}

// 정적 메서드 호출
Person.sayHi() // Hi!

하지만, 클래스에서는 간단하게 메서드에 static 키워드만 붙이면 정적 메서드(클래스 메서드)가 된다. (와웅!!!!)

class Person {
  constructor(name) {
    this.name = name
  }

  // 정적 메서드 생성
  static sayHi() {
    console.log("Hi!")
  }
}

// 정적 메서드 호출
Person.sayHi() // Hi!

클래스는 클래스 선언문이나 클래스 표현식으로 정의가 평가되는 시점에 함수 객체가 된다. 그래서 정적 메서드는 클래스 정의 후, 별다른 인스턴스를 생성하지 않아도 호출 할 수 있다.

프로토타입 메서드 vs. 정적 메서드

1. 정적 메서드와 프로토타입 메서드는 속해있는 프로토타입 체인이 다르다.

2. 정적 메서드는 클래스로 호출하고 프로토타입 메서드는 인스턴스로 호출한다.

3. 정적 메서드는 인스턴스 프로퍼티를 참조할 수 없는 반면, 프로토타입 메서드는 인스턴스 프로퍼티를 참조할 수 있다.

위 세 가지 내용을 다음과같이 공식처럼 정리해보았다.

• static이 앞에 있다 → 정적 메서드이다. → 메서드 호출방법: 클래스명.메서드()
• static이 앞에 없다 → 프로토타입 메서드(instance)이다. → 메서드 호출방법: 인스턴스.메서드()
• 메서드 내부에서 인스턴스 프로퍼티를 참조해야 한다. → this 사용
• 메서드 내부에서 인스턴스 프로퍼티를 참조하지 않아도 된다. → this 미사용

클래스에서 정의한 메서드 특징

클래스에서 정의한 메서드는 다음과 같은 특징이 있다.

• function 키워드를 생략한 축약 표현을 사용한다.
• 객체 리터럴과는 다르게 메서드 정의 시 콤마가 필요없다.
• 암묵적으로 strict mode 로 실행된다.
• for...in문 또는 Object.keys 메서드 등으로 열거할 수 없다.
• 내부 메서드 [[Constructor]] 를 갖지 않으므로, new 연산자로 호출할 수 없다.

클래스의 인스턴스 생성과정

1️⃣ 인스턴스 생성과 this 바인딩

• new 연산자와 함께 클래스 호출 → 암묵적으로 빈 객체 생성(클래스가 생성한 인스턴스)
• 클래스가 생성한 인스턴스의 프로토타입 으로 클래스의 프로토타입 프로퍼티가 가리키는 객체 설정
• 인스턴스 this에 바인딩 ⇒ constructor 내부의 this는 클래스가 생성한 인스턴스를 가리킨다.

2️⃣ 인스턴스 초기화

• constructor 내부코드 실행 → this에 바인딩되어있는 인스턴스 초기화 (constructor가 인수로 전달받은 초기값으로 인스턴스의 프로퍼티 값을 초기화)
• 단, constructor가 생략되었다면 이 과정은 생략된다.

3️⃣ 인스턴스 반환

• 완성된 인스턴스가 this에 바인딩 → this의 암묵적 반환으로 마무리

프로퍼티

인스턴스 프로퍼티

| 인스턴스 프로퍼티는 constructor 내부에서 정의해야한다.

constructor 내부에서 this에 추가한 프로퍼티는 언제나 클래스가 생성한 인스턴스의 프로퍼티가 된다. 클래스는 다른 객체지향 언어처럼 접근 제한자(private, public, protected) 를 지원하지 않기때문에 인스턴스 프로퍼티는 언제나 public하다.

접근자 프로퍼티

| 접근자 프로퍼티는 자체적으로는 값을 가지지않고 다른 데이터 프로퍼티의 값을 읽거나 저장할 때 사용하는 접근자 함수로 구성된 프로퍼티이다.

이러한 접근자 프로퍼티는 클래스에서도 사용할 수 있다.

접근자 프로퍼티는 getter 함수와 setter 함수로 구성되어있다.

getter 함수

• 인스턴스 프로퍼티에 접근할 때마다 프로퍼티 값을 조작하거나 별도의 행위가 필요할 때 사용한다.
• 메서드 이름 앞에 get 키워드를 사용하여 정의한다.
• 취득할 때 사용 → 반드시 무언가를 반환 해야한다.

setter 함수

• 인스턴스 프로퍼티에 값을 할당할 때마다 프로퍼티 값을 조작하거나 별도의 행위가 필요할 때 사용한다.
• 메서드 이름 앞에 set 키워드를 사용하여 정의한다.
• 할당할 때 사용 → 반드시 매개변수가 있어야한다. (단 하나의 값만 할당받으므로 하나의 매개변수만 선언할 수 있다.)

class Person {
  constructor(firstName, lastName) {
    this.firstName = firstName
    this.laseName = lastName
  }

  // getter 함수
  get fullName() {
    return `${this.firstName} ${this.lastName}`
  }

  // setter 함수
  set fullName(name) {
    [this.firstName, this.lastName] = name.split(' ')
  }
}

// ...

접근자 프로퍼티는 호출하는 것이 아니라 참조(getter)하거나 값을 할당(setter)하는 형식으로 사용한다.

기본적으로 클래스의 메서드는 프로토타입 메서드가 된다. 그러므로 클래스의 접근자 프로퍼티도 프로토타입의 프로퍼티가 된다.

클래스 필드

| 클래스 필드란 클래스 기반 객체지향 언어에서 클래스가 생성할 인스턴스의 프로퍼티를 가리킨다.

클래스 기반 객체지향 언어에서의 this 는 언제나 클래스가 생성할 인스턴스를 가리킨다.

• 자바스크립트의 클래스 몸체에는 메서드만 선언할 수 있다. 하지만, 자바스크립트의 클래스 몸체에서도 클래스 필드를 정의할 수 있도록 제안이 되어있으며, Chrome 72 이상 의 브라우저와 버전 12 이상 의 Node.js는 이 제안내용을 미리 구현해 놓았다. ⇒ 해당 환경에서는 클래스 몸체에 클래스 필드 정의를 에러발생없이 할 수 있다.

✋🏻 잠깐! 하지만, 2025 9월 현재 찾아본 바에 의하면

2021년 1월, TC39 프로세스의 stage3에 클래스 필드로 정의할 수 있는 새로운 표준 사양이 제안됐었고, 2025년 9월 현재 mdn에 공식적으로 등록되어 사용가능한 상태이다. 🥳👏🏻👏🏻🎉

👉🏻클래스 필드 mdn 보러가기

class Person {
  name = "Lee"
}

const me = new Person()
console.log(me) // Person{name: "Lee"}

이렇게 클래스 몸체에서 클래스 필드를 정의할 때에는 this 에 클래스 필드 바인딩을 해서는 안된다. ❌ ⇒ this는 클래스의 constructor 와 메서드 내에서만 유효하다.

• 클래스 필드를 참조하는 경우에는 this 를 반드시 사용하여야 한다. (자바와 같은 클래스 기반 객체지향 언어에서는 생략이 가능하다.)
• 클래스 필드에 초기값 을 할당하지 않으면 undefined 를 갖는다.
• 인스턴스 생성시 외부 초기값으로 클래스 필드를 초기화해야 하는 경우에는, constructor 내부에서 클래스 필드를 참조하여 초기화를 진행하여야 한다.
• 함수는 일급 객체이므로 클래스 필드에 할당할 수 있지만 권장하지는 않는다.

private 필드

24장.클로저-캡슐화와 정보은닉 에서 '인스턴스 메서드와 프로토타입을 활용하여 private 흉내를 낼 수는 있지만 완전하다고 할 수는 없다.' 이런 내용을 살펴본적이 있다.

클래스도 역시나 접근 제한자를 지원하지 않아 인스턴스 프로퍼티는 항상 public 이다. 즉, 클래드 필드 정의 제안을 사용하더라도 기본적으로 public이기때문에 외부에 노출이 그대로 된다.

private 필드의 앞에 # 을 붙여서 사용을 하고, 참조시에도 마찬가지로 # 을 붙여주면 된다.

class Person {
  // private 필드 정의
  #name = ''

  constructor(name) {
    this.#name = name
  }
}

const me = new Person('Lee')

// 잘못된 참조 ❌
console.log(me.#name) // SyntaxError
// 올바른 참조 ✅
console.log(me.name) // Lee

public 필드는 어디서든 참조할 수 있지만, private 필드는 클래스 내부 에서만 참조할 수 있다.

또한, private 필드는 반드시 클래스 몸체에 정의해야하며, 직접 constructor 에 정의하면 에러가 발생한다.

✋🏻 잠깐! 하지만, 2025 9월 현재 찾아본 바에 의하면

2021년 1월, TC39 프로세스의 stage3에 private 필드를 정의할 수 있는 새로운 표준 사양이 제안됐었고, 2025년 9월 현재 mdn에 공식적으로 등록되어 사용가능한 상태이다. 🥳👏🏻👏🏻🎉

👉🏻private 필드 mdn 보러가기

static 필드

정적 메서드는 프로토타입 메서드에서 살펴보았듯이 static 을 앞에 붙여서 정의할 수 있다. 하지만, static 키워드를 사용하여 정적 필드 를 정의할 수는 없었다.

하지만, private 와 마찬가지로 static 또한 2021년 1월, TC39 프로세스의 stage3에 static 필드를 정의할 수 있는 새로운 표준 사양이 제안됐었고, 2025년 9월 현재 mdn에 공식적으로 등록되어 사용가능한 상태이다. 🥳👏🏻👏🏻🎉

class MyMath {
  //static public 필드 정의
  static PI = 22 / 7
  // static private 필드 정의
  static #num = 10

  // static 메서드
  static increment() {
    return ++MyMath.#num
  }
}

console.log(MyMath.PI) // 3.142857142857143
console.log(MyMath.increment()) // 11

👉🏻static 필드 mdn 보러가기

상속에 의한 클래스 확장

클래스 상속과 생성자 함수 상속

프로토타입 기반 상속은 프로토타입 체인을 통해 상속받는 개념이였지만, 상속에 의한 클래스 확장은 기존 클래스를 상속받아 새로운 클래스를 확장하여 정의하는 것이다.

extends 키워드

| 상속을 통해 클래스를 확장하기 위해서는 extends 키워드를 사용하여 상속받을 클래스를 정의해야한다.

// 수퍼(부모/베이스) 클래스 (상속받을 클래스)
class Base {}

// 서브(자식/파생) 클래스
class Derived extends Base {}

수퍼클래스와 서브클래스는 인스턴스의 프로토타입 체인뿐만 아니라 클래스간의 프로토타입 체인도 생성한다. ⇒ 프로토타입 메서드, 정적 메서드 모두 상속이 가능하다.

동적 상속

extends 키워드는 클래스뿐만 아니라 생성자 함수를 상속받아 클래스 확장을 할 수 도 있다. (단, extends 키워드 앞에는 반드시 클래스가 와야한다.)

// 생성자 함수
function Base(a) {
  this.a = a
}

// 생성자 함수를 상속받는 서브 클래스
class Derived extends Base {}

extends 키워드 다음에는 [[Constructor]] 내부 메서드를 갖는 함수 객체로 평가될 수 있는 모든 표현식을 사용할 수 있으며, 이를 통해 동적으로 상속받을 대상을 결정할 수 있다.

서브 클래스의 constructor

앞서 살펴본 바와같이 클래스에서 constructor를 생략하면 다음과 같은 비어있는 constructor가 암묵적으로 정의된다.

constructor() {}

이걸 서브 클래스에서 생략을 하게되면 아래와 같은 형태의 constructor가 암묵적으로 정의된다. (args는 new 연산자와 함께 클래스를 호출할 때 전달한 인수의 리스트이다.)

constructor(...args) { super(...args) }

여기서 super() 는 수퍼 클래스의 constructor(super-constructor) 이다.

super 키워드

| 함수처럼 호출할 수도 있고 this와 같이 식별자처럼 참조할 수 있는 특수한 키워드이다.

super 의 동작방식은 다음과 같으며 하나씩 살펴보자.

• super 호출 → 수퍼 클래스의 constructor(super-constructor) 호출
• super 참조 → 수퍼 클래스의 메서드 호출

1️⃣ super 호출

수퍼 클래스의 constructor 내부에서 추가한 프로퍼티를 그대로 갖는 인스턴스를 생성하면 서브 클래스의 constructor 는 생략할 수 있다. (새로 추가되는 프로퍼티가 없기 때문에)

하지만, 수퍼 클래스의 프로퍼티와 서브 클래스에서 추가한 프로퍼티를 갖는 인스턴스를 생성할 때에는 서브 클래스의 constructor 는 생략할 수 없으며, 수퍼 클래스의 constructor에 해당되는(전달해야하는) 인수가 있다면 서브 클래스의 constructor에서 super 를 통해 전달한다.

super 를 호출 할때에는 몇 가지 주의사항이 있다.

1. 서브 클래스에서 constructor를 생략하지 않는 경우에는 반드시 super 를 호출해야하며, 호출하지 않을 경우 ReferenceError 가 발생한다.
2. 서브 클래스의 constructor에서 this 를 참조하려면 super 를 먼저 참조해야한다. (순서가 있다!)

   class Base {}
   

class Derived extends Base { constructor() { // 잘못된 순서 ❌ this.a = 1 super() } }

class Base {}

class Derived extends Base { constructor() { // 올바른 순서 ✅ super() this.a = 1 } }

3. `super`는 반드시 `서브` 클래스의 constructor 에서만 호출해야하며, 서브 클래스가 아닌 다른 클래스에서 호출 시 `SyntaxError` 가 발생한다.

#### 2️⃣ `super` 참조

`super` 를 참조할 때에도 몇 가지 알아둬야할 내용들이 있다.

1. 서브 클래스의 프로토타입 메서드 내에서 사용되는 `super.메서드명` 에서 `메서드명`은 수퍼 클래스의 프로토타입 메서드를 가리킨다.

- `super`참조를 통해 수퍼 클래스의 메서드를 참조하려면, `super`가 바인딩된 객체 (*수퍼 클래스의 prototype 프로퍼티*)에 바인딩된 프로토타입을 참조할 수 있어야한다.
- `super` 참조는 클래스의 전유물이 아니므로 객체 리터럴에서도 사용할 수 있다.

2. 서브 클래스의 정적 메서드 내에서의 `super.메서드명` 에서 `메서드명`은 수퍼 클래스의 정적 메서드를 가리킨다.

```js
class Base {
  static sayHi() {
    return "Hi!"
  }
}

class Derived extends Base {
  static sayHi() {
    // 여기서의 sayHi는 수퍼 클래스의 정적 클래스인 sayHi 를 가리킨다.
    return `${super.sayHi()} how are you doing?`
  }
}

console.log(Derived.sayHi())

상속 클래스의 인스턴스 생성과정

1️⃣ 서브 클래스의 super 호출

자바스크립트 엔진은 클래스 평가 시, 수퍼/서브 클래스 구분을 위해 base , derived 를 값으로 갖는 내부 슬롯인 [[ConstructorKind]] 를 갖는다.

클래스를 상속받지 않는 클래스는 내부 슬롯([[ConstructorKind]])의 값이 base 로 설정되고, 상속받는 클래스의 내부 슬롯([[ConstructorKind]])의 값은 derived 로 설정된다.

서브 클래스는 직접 인스턴스를 생성하지 않고, 수퍼 클래스에게 인스턴스 생성을 위임하여 상속받는다. ⇒ 서브 클래스의 constructor 에서 꼭 super 로 호출해야한다. (super 로 호출하지 않으면 인스턴스를 생성할 수 없다.)

2️⃣ 수퍼 클래스의 인스턴스 생성과 this 바인딩

수퍼 클래스의 constructor 내부의 코드가 실행되기 전에 암묵적으로 빈 객체를 생성하는데, 이 빈 객체가 클래스가 생성한 인스턴스이다. 생성된 인스턴스는 this 에 바인딩된다. ⇒ 수퍼 클래스의 constructor 내부의 this 는 생성된 인스턴스를 가리킨다.

3️⃣ 수퍼 클래스의 인스턴스 초기화

수퍼 클래스의 constructor가 실행되면 this 에 바인딩되어있는 인스턴스가 초기화된다.

4️⃣ 서브 클래스 constructor로의 복귀와 this 바인딩

super 호출이 종료되면 흐름은 서브 클래스의 constructor 로 돌아온다.

super 호출이 종료되면서 반환한 인스턴스가 this 에 바인딩되기 때문에 서브 클래스는 별도의 인스턴스를 생성하지 않고 그대로 사용한다.

이런 흐름상의 이유로 super 가 호출되지 않으면 인스턴스 생성도, this 바인딩도 할 수 없다. 앞서 super 키워드 내용을 살펴볼 때, '순서가 있다!' 라고 한 이유가 바로 이때문이다.

5️⃣ 서브 클래스의 인스턴스 초기화

super 호출 이후 서브 클래스의 constructor에 있는 인스턴스의 초기화가 실행된다.

6️⃣ 인스턴스 반환

클래스의 모든 처리가 완료되면 완성된 인스턴스가 바인딩된 this 의 암묵적 반환이 실행된다.

표준 빌트인 생성자 함수 확장

앞서 살펴봤듯이 extends 키워드 다음에는 클래스가 아니더라도 [[Constructor]] 내부 메서드를 갖는 함수 객체로 평가될 수 있는 모든 표현식을 사용할 수 있다.

String, Number, Array 같은 표준 빌트인 객체도 내부 메서드를 갖는 생성자 함수이므로 extends 키워드를 사용하여 확장 할 수 있다.

리액트에서 핵심이 되는게 뭘까? 라고 했을때 많은 것들이 있겠지만, 상태관리가 빠지면 섭섭할 것 같다.

리액트 훅을 소개하면서 가장 먼저 소개한 훅도 useState 였던만큼 상태관리를 빼놓고 리액트를 얘기할 수는 없다.

사용자가 어떤 동작을 했을 때, 요청을 보내고 응답을 받아 처리하며 대기상태, 에러상태 등 을 useState 를 통해 처리해왔다.

useState만을 이용해서도 대기, 에러상태를 관리할 수 있다.

그치만 더 복잡한 상태관리를 해야할 때, 개발자가 상태관리까지 신경쓰지않고 로직에만 집중할 수 있도록 나온 것이 바로 액션(Action) 이다. (🎬레뒤? 액!션)

액션(Action) 이란?

| 대기상태, 에러, 폼, 낙관적 업데이트를 처리하는 비동기 함수를 의미한다.

다음의 폼 예시를 통해 액션의 도입 전/후를 비교해보자.

// 액션 도입 전
import { useState } from 'react'
import { updateName } from '@/api'

function UpdateName() {
  const [loading, setLoading] = useState(false)
  const [error, setError] = useState(null)
  const [name, setName] = useState('')

  // 이벤트 핸들러를 사용하여 처리
  const handleSubmit = async (e) => {
      e.preventDefault()

    setLoading(true)
    const error = await updateName(name)
    setLoading(false)
    if (error) {
      setError(error)
      return
    }
    redirect('/path')
  }

  return (
    <form 
        onSubmit={handleSubmit}
        aria-describedby={error ? 'error-message' : undefined}
      >
    // ...
    </form>
 )
}

// 액션 도입 후
import { useState, useTransition } from 'react'
import { updateName } from '@/api'

function UpdateName() {
  const [loading, startTransition] = useTransition()
  const [error, setError] = useState(null)

    // 액션 함수 : 폼 데이터를 받아 비동기 작업 처리
  const handleSubmit = async (formData) => {
    startTransition(aync () => {
        const name = formData.get('name')
        const error = await updateName(name)

        if (error) {
          setError(error)
          return
        }

        redirect('/path')
    })
  }

  return (
    <form 
        action={handleSubmit} // 액션속성에 액션함수 전달
        aria-describedby={error ? 'error-message' : undefined}
      >
    // ...
    </form>
 )
}

비동기 작업 처리시, 직접 상태관리를 해야했던 도입 전과 달리 도입 후에는 폼 데이터를 받아 비동기 작업을 처리한다.

리액트(마니또)가 자동으로 로딩, 에러, 완료상태를 관리해주기때문에 개발자는 로직에만 집중하면 되는 것이다.

폼을 예시로 한 것은 액션이 자주 사용되는 대표적인 경우가 폼(Form)이라는 점을 기억해두자 😉

액션의 특징

1. 코드가 간결해진다.

-별도의 상태관리없이 비동기 작업처리가 가능하다. 2. 로딩/에러/완료 상태관리를 자동으로 한다. 3. 폼, 버튼 등 다양한 곳에서 액션을 쉽게 적용할 수 있다. 4. useTransition 를 함께 사용하여 대기 상태일때도 부드러운 반응을 보여줄 수 있다. 5. 서버 컴포넌트와 연계하여 클라이언트와 서버사이의 작업을 안전하게 처리할 수 있다.

💡 참고사항 데이터 제출을 자동을 관리하는 액션?

• 대기상태: 요청 시작 시 대기상태 활성화 → 최종 상태 커밋 후 자동 초기화 진행
• 낙관적 업데이트: useOptimistic 을 통해 요청을 제출하는 동안 즉각적인 피드백 표시가능
• 에러상태: 요청 실패 시 Error Boundary를 보여주고 자동으로 낙관적 업데이트를 원래 값으로 돌려놓음
• 폼: <form> 앨리먼트는 action 및 formAction props에 함수전달하는 것을 지원 → props에 함수가 전달되면 기본적으로 액션사용 및 제출 후 폼 자동 초기화 진행

✋🏻 잠깐! 그렇다면 왜 제목에서 *"상태관리? 내 마니또가 알아서 해줘"* 라고 했을까?

action={formAction}이 나타나는 순간, 리액트는 이 action 을 관심있게 보기시작한다.

그리곤 상태별로 마니또(리액트)는 행동을 개시한다!

1. 로딩상태

• action 함수가 실행되면 리액트는 비동기 Promise 추적을 시작한다.
• Promise가 pending 이면 ispending=true 로 상태관리를 자동으로 해주고 컴포넌트 리렌더링을 트리거한다.
• ⇒ 별도의 useState 사용없이 로딩UI 제어가 가능하다.*

2. 에러상태

• action 함수 내에서 에러가 발생하거나 Promise가 reject되면, 리액트가 알아서 에러처리를 해준다.
• ⇒ action 함수에서 throw를 한다면 ErrorBoundary 연동까지 해주므로 전역 에러처리가 가능하다.* (try...catch 를 직접 넣지 않아도 됨)

3. 완료상태

• Promise 가 resolve 되면 리액트는 반환값을 state에 살포시 넣어준다.
• ⇒ 해당 값은 자동으로 컴포넌트 리렌더링을 발생시켜 완료UI를 보여주게 된다.*

정리하자면,

액션은 비동기 작업을 더 쉽고 깔끔하게 구현할 수 있는 뉴-페이스이다.

폼 요소에 일반 이벤트 핸들러와 액션 함수 가 연결된 경우의 차이점을 살펴보며 이 글을 마무리하겠다.

🎃이벤트 핸들러

• 이벤트 객체를 전달받음
• e.preventDefault() 설정
• form.reset() 필요
• 비동기 함수 코드 (상태 업데이트 요청시, 렌더링 우선 순위를 가짐)

🎬액션 함수

• formData 를 전달받음
• 별도 설정 필요 없음 (자동 브라우저 기본 작동 방지)
• 별도 설정 필요 없음 (자동 폼 초기화)
• 자동 트랜지션(transition)처리가 됨 → 렌더링의 우선순위가 낮아짐 → 당장 급하게 처리할 아이가 아님
• 사용자가 제출할 때 쓰는거라 즉각적인 반응이 일어나지 않아도됨

🔗 참고자료 https://ko.react.dev/blog/2024/12/05/react-19#actions https://ko.react.dev/reference/react-dom/components/form

리액트 훅이라고하면 일반적으로 use- 접미사로 시작을 한다.

그런데 use 만 덩그러니인 것이 나타났다!? 이건 리액트 훅일까 아닐까? 🧐

use 란?

| Promise 나 Context 와 같은 데이터를 참조하는 React API 이다.

// 형태
const value = use(resource)

매개변수

resource

• 참조하려는 데이터로, 데이터는 Promise 또는 Context 일 수 있다.
• Promise 일 경우, 항상 같은 Promise 인스턴스를 전달해야한다. 컴포넌트 내부에서 렌더링될 때마다 새로운 Promise 를 생성하게되면, 무한반복에 빠질 수 있다. ☠️

// 무한반복에 빠지는 경우
import { Suspense } from 'react'
import { ErrorBoundary } from 'react-error-boundary'
import { Users, Spinner, ErrorFallback } from '@/components'
import { fetchUsers } from '@/api'

export default function App() {
    // ❌ 렌더링마다 새로운 Promise 생성
    const promise = fetchUsers()

    return (
        <ErrorBoundary FallbackComponent={ErrorFallback}>
            <Suspense fallback={<Spinner />}>
                <Users promise={promise} />
            </Suspense>
        </ErrorBoundary>
    )
}

// 무한반복에 빠지지 않는 경우
import { Suspense, useMemo } from 'react'
import { ErrorBoundary } from 'react-error-boundary'
import { Users, Spinner, ErrorFallback } from '@/components'
import { fetchUsers } from '@/api'

export default function App() {
    // ✅ 의존성 배열이 빈 배열이므로 최초 한 번만 생성됨
    const promise = useMemo(() => fetchUsers(), [])

    return (
        <ErrorBoundary FallbackComponent={ErrorFallback}>
            <Suspense fallback={<Spinner />}>
                <Users promise={promise} />
            </Suspense>
        </ErrorBoundary>
    )
}

💡 참고사항 Next.js 서버 컴포넌트는 렌더링이 한 번만 이루어지므로 use 함수로 Promise 를 직접 사용해도 무한반복이 일어나지 않는다.

export default function ServerComponent() {
    // 서버 컴포넌트는 한 번만 렌더링되므로
    // use 함수에서 직접 Promise를 사용해도 안전합니다.
  const data = use(fetchUsers())
  return (...)
}

반환값

Promise 또는 Context 에서 참조한 값을 반환한다.

use의 특징

• 일반 훅(useState, useEffect)과는 달리 조건문, 반복문 내에서도 사용이 가능하다.
• 일반 훅처럼 함수형 컴포넌트 또는 커스텀 훅 내에서만 사용할 수 있다.
• 컨텍스트 값을 가져올 때도 사용이 가능하여 useContext 처럼 작동할 수 있다. (단, useContext 와의 차이점은 조건문내에서 사용할 수 있다는 점이다.)
• 서버 컴포넌트 에서 데이터를 가져올 때는 use 를 사용하기보다는 async 및 await 를 사용하는 것이 좋다. async 및 await는 await 이 호출된 시점부터 렌더링을 시작하지만, use 는 데이터가 리졸브된 이후부터 컴포넌트를 렌더링하기 때문이다.
• 클라이언트 컴포넌트 에서 Promise 를 생성하는 것보다 서버 컴포넌트 에서 생성하여 클라이언트 컴포너느로 전달하는 것이 좋다. 서버 컴포넌트에서는 렌더링이 한 번만 이루어지는 반면 클라이언트 컴포넌트에서는 렌더링할 때마다 Promise가 재생성되기 때문이다.

use와 Suspense & Error boundary

use로 Promise를 호출했을 때 Promise 의 상태에 따라 Suspense 와 Error Boundary 는 다음과같이 작동한다.

• pending → Suspense 의 fallback 를 보여준다.
• fulfilled → resolve 된 값을 반환하여 화면에 렌더링한다.
• rejected → Error Boundary 로 에러를 전달한다.

✋🏻 잠깐! 그렇다면 Suspense 와 Error Boundary가 없다면 use 로 Promise 를 호출할 수 없는걸까?

"No!"

호출은 할 수 있지만, pending 상태일 때와 rejected상태일 때의 렌더링처리를 어떻게 해야할지 모르는 상태가 되기때문에 렌더링 멈춤현상이 발생하거나 에러가 발생할 수 있다. ⇒ 안전하게 동작하기 위해서는 Suspense 와 Error Boundary로 감싸주자!

정리하자면,

use는 함수의 형태를 가진 훅의 규칙을 따르고 훅처럼 동작하는 API이다. (1인 2역)

즉, *"함수 형태로 구현된 새로운 훅"* 이라고 소개할 수 있겠다.

🔗 참고자료 https://ko.react.dev/reference/react/use

예고편 되돌아보기 🎥

Suspense 글의 마무리에서 예고했던 내용을 되돌아보자.

페이지가 로딩될 때 전체적인 레이아웃은 보이는데, 내용은 희미하게 처리되어 보이는 화면을 본 경험이 있을 것이다. (있다고 해주세요 제발)

이렇게 상태 전환이 급하지 않아서 이미 공개된 컨텐츠를 대체UI(fallback) 로 숨기느니 이전 페이지를 계속 표시하는 것이 좋겠다고 리액트에게 알려주면 리액트는 컴포넌트의 로딩이 완료될 때까지 이전 페이지로 대기한다.

useTransition 이란?

| UI 업데이트의 우선순위를 정하고, 중요한 업데이트는 먼저 처리되도록 해주는 훅이다.

즉, 중요한 업데이트가 낮은 우선순위의 업데이트로 인해 멈춤 현상이 발생하지 않고, 먼저 처리되어 UI 업데이트가 진행될 수 있게 해주는 훅이다. (서포트 팍팍)

// 형태
const [isPending, startTransition] = useTransition()

매개변수

어떠한 매개변수도 받지 않는다. ❌

반환값

두 개의 항목이 있는 배열 을 반환한다.

• isPending : 대기 중인 Transition의 존재여부를 알려준다.
• startTransition 함수 : 상태 업데이트를 Transition으로 표시하게 해주는 함수이다.

startTransition

// 형태
startTransition(action)

매개변수

action

• 하나 이상의 set 함수를 호출하여 일부 상태 를 업데이트하는 함수
• 즉시 action 함수를 호출하고, 호출 중 동기적으로 예약된 모든 상태 업데이트를 Transitions 로 표시한다.
• action 내에서 상태 업데이트 및 사이트 이펙트를 수행할 수 있으며, 페이지에서의 상호작용을 차단하지 않고 백그라운드에서 작업 수행을 한다.
• Transition 내에서의 action 은 실행 순서를 보장하지 않는다.
• 전달되는 함수는 동기식 이여야 한다. → 리액트는 action 함수를 즉시 실행하여, 실행하는 동안 발생하는 모든 state 업데이트를 Transition으로 표시한다. 더 많은 상태 업데이트를 수행하고자 setTimeout 등의 비동기 코드를 사용하면 Transition으로 표시되지 않는다.
• Transition은 여러 개의 action을 포함할 수 있으며, Transition이 진행되는 동안 UI도 계속 반응하여 변경된다.
• Transitions 로 표시된 상태 업데이트는 non-blocking 방식으로 처리되며, 불필요한 로딩표시가 나타나지 않는다.

💡 권장사항 startTransition 내에서 호출되는 모든 콜백의 이름은 action 이거나 Action 접미사를 포함해야한다.

// 리액트 공식문서 예시
function SubmitButton({ submitAction }) {
  const [isPending, startTransition] = useTransition();
  return (
    <button
      disabled={isPending}
      onClick={() => {
        startTransition(async () => {
          await submitAction();
        });
      }}
    >
      Submit
    </button>
  );
}

반환값

아무것도 반환하지 않는다.

// 사용형태
startTransition(action)

// 사용예시
import { useState, useTransition } from 'react'

export default function TabComponent() {
  const [tab, setTab] = useState('posts')
  const [isPending, startTransition] = useTransition()

  function handleTabChange(nextTab) {
    startTransition(() => {
      setTab(nextTab)
    })
  }

startTransition의 특징 및 유의사항

• 비동기 요청 이후 (await 사용) 상태 업데이트를 Transition으로 표시하기 위해서는 또 다른 startTransition 으로 감싸야한다. 단, action prop 을 노출할 때에는 Transition 내부에서 await 를 사용해야한다. 이렇게 사용할 경우, 콜백의 동기/비동기 여부에 상관없이 작동할 수 있으며 startTransition 으로 한번 더 감쌀 필요가 없어진다.

  // 잘못된 방법
  startTransition(async () => {
  await someAsyncFunction();
  // ❌ await 이후에 startTransition을 사용하지 않음
  setPage('/about');
  });
  

// 올바른 방법 startTransition(async () => { await someAsyncFunction(); // ✅ await 이후에 startTransition을 사용 startTransition(() => { setPage('/about'); }); });

- `startTransition` 함수는 안정된 식별성을 가지고 있다. → Effect 의존성에서 생략되는 경우가 대부분이며, 포함한다고해도 Effect가 실행되지 않는다.
- `startTransition` 내에서 동기적으로 `setState` 를 호출해야 효과가 반영된다.
```js
startTransition(() => {
  setPage('/about')
})

• setTimeout, Promise 등 비동기 코드 내에서 호출할 경우에는 transition이 제대로 작동하지 않는다.

  // ❌ 잘못된 방법
  startTransition(() => {
  setTimeout(() => {
    setPage('/about')
  }, 1000)
  }) 
  // ✅ 올바른 방법 (수정)
  setTimeout(() => {
  startTransition(() => {
    // ✅ startTransition 호출 *도중* state 설정
    setPage('/about');
  });
  }, 1000);

useTransition의 특징 및 유의사항

• startTransition으로 감싸면 중요한 UI는 즉시 반응한다.
• isPending으로 transition 상태(로딩 중) 자동 표시가 가능하다.
• 해당 state의 set 함수 에 접근할 수 있는 경우에만 Transition으로 감쌀 수 있다. 일부 prop이나 커스텀 훅의 값에 대한 응답에 Transition을 적용하려면 useDeferredValue 를 사용해야 한다.
• Transition 으로 표시된 상태 업데이트가 일어나고 있는 도중에 입력을 시작하면 (다른 상태 업데이트 발생!) 진행되고 있던 업데이트는 중단되고 입력 업데이트(new)를 먼저 처리한 후 다시 시작한다. ⇒ 우선순위 결정 후 그게 따라 작업 진행
• 입력을 제어하는 state 변수에는 Transition 을 사용할 수 없다. Transition은 non-blocking 이지만, 변경 이벤트에 대한 응답으로 입력을 업데이트하는 것은 동기적으로 이루어져야하기 때문이다.

✋🏻잠깐! non-blocking 은 무슨 의미일까? UI가 버벅거리면서 멈추는 일없이 즉각적인 상호작용을 보장하는 것을 의미한다.

• 데이터 라이브러리와같은 컴포넌트나 훅 내부가 아닌 곳에서 Transition을 해야하는 경우 또는 isPending이 필요없는 경우에는 독립형인 startTransition 을 호출해야 한다.

✋🏻잠깐! 그럼 useTransition 이랑 startTransition 이랑 어떻게 구분해서 사용하는게 좋은거야?

• 컴포넌트 내부 에서 transition 상태(isPending)를 UI에 표시해야 하는 경우 → useTransition 사용
• 컴포넌트 외부 에서 transition 을 적용하거나 isPending 이 필요없는 경우 → startTransition 사용
  ⇒ startTransition 은 useTransition 없이도 사용가능한 독립성을 가진 API 함수 이다. 결국 두 가지 모두 같은 기능(transition 업데이트 표시)를 가지고 있지만, 훅 의 형태로 쓰느냐 함수 의 형태로 쓰느냐의 차이이다.

useTransition vs. useDeferredValue

useTransition

• 여러 상태 중 '급한 상태' 와 '급하지 않은 상태'를 구분지어야할 때 사용
• 상태 변화에도 UI가 멈추지 않게 하고 싶을 때 사용

useDeferredValue

• 입력값에 따라 무거운 연산이 수반될 때 사용
• 값 자체만 지연시키고 싶을 때 사용

공통점

• 실제로 느린 연산 또는 컴포넌트가 있을 경우에만 적용하는 것이 효과적이다.
• Suspense, memo 등과 함께 사용하면 더 자연스러운 UX구현이 가능하다. (시너지 효과)

정리하자면,

startTransition

• 함수형태이다.
• 컴포넌트 외부 에서 작동한다.
• startTransition에 전달한 함수는 지연없이 즉시 실행 된다.
• useTransition 에 의존하지 않고 독립적이다. ⇒ 단독사용가능
• isPending (Transiton 대기여부 추적) 플래그를 제공하지 않는다. ❌

useTransition

• 훅의 형태이다.
• 컴포넌트 내부 에서 작동한다.
• isPending (Transiton 대기여부 추적) 플래그를 제공한다.

🔗 참고자료 https://ko.react.dev/reference/react/useTransition https://ko.react.dev/reference/react/startTransition

예고편 되돌아보기 🎥

Suspense 글의 마무리에서 예고했던 내용을 되돌아보자.

검색어를 입력하는 상황에서 '사' 라고 입력하고 다음 글자로 '과'를 입력하는데 지연이 발생했다고 하자. 자동완성기능에 '사'로 시작하는 단어들이 나왔다가 '과'를 입력하니까 '로딩중...' 이라고 렌더링이 됐다면? 사용자는 😲"이게뭐지?" 하며 어리둥절해할 것이고, 결국 사용자경험(UX)도 좋지않을 것이다.

이럴 때는 '사'라고 입력했을 때의 결과. 즉, 이전 값을 유지한채 '과'에 대한 결과값 로딩을 기다리는 것이 사용자경험 측면에서 더 좋은 방향이다.

위 예고편의 문제(사용자 경험 저하)를 해결하는 방법 중 하나로 memo 함수로 느리게 렌더링되는 컴포넌트를 감싸는 방법이 있다.

이 방법으로 불필요한 렌더링을 줄일 순 있으나, 입력값이라는 props는 변경되지 않았으므로 여전히 렌더링이 느려 근본적인 해결책이 되기엔 아쉬운 부분이 있다.

이 때, 예고했던 훅을 사용하면 즉각적인 업데이트가 필요한 부분과 조금은 느려도 되는 부분을 분리하여 문제를 해결할 수 있다! (살펴봅시다)

useDeferredValue란?

| 일부 UI 업데이트 반응속도를 지연시킬 수 있는 리액트 훅이다.

// 형태
const deferredValue = useDeferredValue(value, initialValue?)

매개변수

value

• 지연시키려는 값
• 모든 타입을 값으로 가질 수 있다.

(optional) initialValue

• 컴포넌트 초기 렌더링시 사용할 값
• 옵션 생략시, 초기 렌더링동안은 값을 지연시키지 않는다.
• 리액트 19버전부터 설정이 가능해졌다. → 초기 렌더링시 undefined 가 아닌 설정한 값으로 시작할 수 있게 되었다.

반환값

currentValue

• 초기 렌더링 중 반환된 지연된 값은 사용자가 제공한 값과 동일하다.

이러한 useDeferredValue 의 대표적인 사용예시는 다음과 같으며, 이 예시를 생각하면서 내용을 살펴보자.

import { useState } from 'react'
import SlowChild from './slow-child'

export default function App() {
  const [query, setQuery] = useState('')

  return (
    <div className="app">
      <label htmlFor="search-input">
        검색어 입력
      </label>
      <input
        id="search-input"
        type="text"
        value={query}
        onChange={e => setQuery(e.target.value)}
        placeholder="검색어를 입력하세요."
      />
      <SlowChild query={query} />
    </div>
  )
}

// SlowChild.tsx
export default function SlowChild({ query }) {

    // start 변수 컴포넌트가 렌더링될 때 시간(ms) 저장
  const start = performance.now()

  // 현재 시간에서 start 변수 값을 뺀 값이 
  // 100ms보다 작을 동안 아무 작업도 하지 않고 계속 반복
  // 즉, 아무 일도 않고 100ms 동안 CPU를 점유
  while (performance.now() - start < 100) {
    // 성능 저하 시뮬레이션
  }

  return <p>검색어: {query}</p>
}

Suspense와의 관계

Suspense로 감싼 컴포넌트를 렌더링할 때 새로운 검색어를 입력하면 '로딩 중...'만 보여주었다.

하지만 useDeferredValue와 함께라면, 새 데이터가 준비될 때까지 이전 데이터(지연된 값)를 렌더링할 수 있다.

✋🏻잠깐! 그럼 Suspense를 굳이 왜 쓰는거야?
useDeferredValue 의 반환값인 지연된 값과 입력값이 다를 수가 있는데, 이 때는 보여줄 이전 데이터가 없어진다. 왜냐면 useDeferredValue 훅은 별도의 로딩 상태를 제공하지않기 때문이다. 이럴 때 짜잔-! 하고 보여주려고 Suspense 가 든든하게 컴포넌트를 감싸고 대기중인 것이다. (마니또 느낌)

useDeferredValue의 특징 및 유의사항

1. 실제 성능 병목지점 파악하기

• 입력과 동시에 렌더링 되는 컴포넌트가 실제로 성능 문제를 일으키는지 개발자도구-Profiler 를 통해서 확인해야한다.
• 즉시 렌더링 되어야하는 컴포넌트인지 구분지을 수 있어야 한다.

2. 입력영역과 결과영역 렌더링 분리하기

• 입력영역은 즉시 업데이트가 되어야하고, 결과를 보여주는 영역은 나중에 보여지게 하는 것이 중요하다. → 대용량 데이터 처리에 매우 효과적 ✨

3. UI 우선순위를 자동으로 조정

• 훅을 사용하면 빠른 작업 과 느린 작업 을 구분지어 우선순위 를 자동으로 조정한다.
• 쓰로틀(Throttle) 과 디바운스(Debounce) 를 사용하지 않고도 부드러운 사용자 경험을 만들 수 있다.

✋🏻잠깐! 쓰로틀(Throttle) 과 디바운스(Debounce)가 뭔데?
곧 내용 업데이트 예정입니다

4. 이전 데이터로 렌더링 유지가능

• Suspense 와 함께 사용시, 새로운 데이터를 불러오는 동안 '로딩 중...' 대신 이전 데이터를 보여줄 수 있다. → 시너지 효과 뿜뿜!
• 데이터의 로딩준비가 완료되면 자동으로 새로운 데이터로 교체된다.

5. 캐싱전략도 챙기기

• 동일 입력값에 대한 캐싱을 적용하면 불필요한 네트워크 요청과 렌더링을 줄이는게 효과적이다. (useDeferredValue 은 그 자체로 추가 네트워크 요청 방지를 하지 않는다.)

6. Effect 일시중단 시키기

• useDeferredValue 로 인한 백그라운드 리렌더링이 화면에 커밋 될 때까지 Effect 는 실행되지 않는다. (백그라운드 리렌더링 일시 중단 → 데이터 로딩 → UI 업데이트 → Effect 실행)

7. 가장 최근에 제공(입력)받은 값이 기준

• 리액트는 항상 가장 최근에 제공(입력)받은 값을 기준으로 사용한다. 예를 들어, 검색어를 '바' 입력 → '나' 입력 → '나' 지우고 '보' 입력 이렇게 수정입력했다고하면 리액트는 '바나' 까지를 지연된 값으로 저장해놨다가 '나' 를 지우고 '보' 를 입력하는 순간 저장해둔 '바나' 를 지우고 새로운 값인 '바보'로 지연된 값을 업데이트 하는 것이다.

정리하자면,

1. useDeferredValue 의 사용목적은 분리 이다.

• 즉각적으로 반응하길 원하는 값과 잠시 대기했다가 보여주길 원하는 값의 분리

2. memo 와 같이 사용해야 최적화가 이루어진다.

• memo 로 감싸지 않을 경우, 입력값이 변경될 때마다 부모 컴포넌트가 리렌더링 되어야 한다.
• props 변경까지 memo 가 캐치해줄 수는 없지만, memo 마저 없으면 최적화의 취지가 무색해진다.

🔗 참고자료 https://ko.react.dev/reference/react/useDeferredValue

볼륨이 큰 웹 앱을 만들어가다보면, 컴포넌트도 점점 많아지고 자연스레 코드도 커지게 된다. 이 때, 모든 코드를 빠짐없이 한 번에 다운로드하게되면 페이지 하나를 여는 데도 오랜 시간이 걸리게 된다.

그렇게되면 불필요한 자원낭비와 느려진 로딩속도만 남는다...(덩그러니)

그렇다면 다양한 컴포넌트를 페이지기능별로 필요할 때만 불러와서 코드를 다운로드하면 어떨까?

"Nice"

이렇게 페이지기능별로 코드를 불러올 수 있게 하기위한 작업이 "코드 분할" 이다.

코드 분할의 장점

1. 불필요한 코드 다운로드 방지
2. 빠른 속도의 초기 로딩
3. 네트워크 효율성 증가: 사용자의 니즈에 맞춰 필요한 코드만 서버에서 받아온다.

lazy 란?

| 컴포넌트가 처음 렌더링될 때까지 해당 컴포넌트의 코드로딩을 지연시키는 기능이다.

// 형태
import { lazy } from 'react'

const SomeComponent = lazy(load)

코드를 로딩시키는 lazy 는 컴포넌트 외부에서 호출하여 지연로딩된 컴포넌트를 선언하여 사용한다.

매개변수

load

• Promise 또는 thenable(then 메서드가 있는 Promise 유사객체)을 반환하는 함수이다.
• 매개변수를 받지 않는다.
• 반환값인 컴포넌트를 처음 렌더링할 때까지 load 를 호출하지 않는다.
• 호출 후 해결된 값의 default 를 컴포넌트로 렌더링한다.
• 반환된 값은 캐시 되므로, 리액트는 load 를 한 번만 호출한다.
• Promise가 거부될 경우, 가장 가까운 에러 바운더리가 처리하도록 에러를 throw 한다.

반환값

• 트리에 렌더링할 수 있는 React 컴포넌트 를 반환한다.
• 컴포넌트 코드가 로딩되는 동안 렌더링을 시도하면 반환이 일시중지되며, 이 때 로딩상태를 표싷려면 앞에서 살펴본 Suspense 를 사용하면 된다.
• React.lazy 로 로드되는 컴포넌트는 반드시 Suspense 로 감싸져야 한다.

import { lazy, Suspense, useState } from 'react'

// 댓글 컴포넌트를 lazy로 가져옴
const Comments = lazy(() => import('./Comments'))

function Article() {
  const [showComments, setShowComments] = useState(false)

  return (
    <div>
      <h1>게시글 내용</h1>
      <button type="button" onClick={() => setShowComments(true)}>
        댓글 보기
      </button>
      {showComments && (
        <Suspense fallback={<p role="status">로딩 중...</p>}>
          <Comments /> // `React.lazy` 로 로드되는 컴포넌트 → `Suspense` 품으로~
        </Suspense>
      )}
    </div>
  )
}

위 예시가 작동하는 방식은 다음과 같다.

1. 사용자가 댓글 보기 버튼을 누르기 전까지는 Comments 컴포넌트가 다운로드 되지 않는다.
2. 버튼을 눌러야 네트워크를 통해 코드 다운로드가 진행된다.
3. 코드 로딩이 준비되는 동안 Suspense  의 fallback 이 실행된다. (환상의 궁합)

lazy 와 Suspense 는 시너지 효과를 낸다.

React.lazy 사용시 주의사항

• lazy 컴포넌트는 다른 컴포넌트 내부에서 선언해서는 안된다. → 항상 모듈 최상위에서 선언해야한다. 다음과 같이 다른 컴포넌트 내부에서 선언할 경우, 리렌더링시 모든 상태가 재설정되는 상황이 발생한다.

  // ❌ 잘못된 방법: 이렇게 하면 다시 렌더링할 때 모든 상태가 재설정된다.
  import { lazy } from 'react';
  

function Editor() { const MarkdownPreview = lazy(() => import('./MarkdownPreview.js')); // ... }

// ✅ 올바른 방법: lazy 컴포넌트를 컴포넌트 외부에 선언한다. import { lazy } from 'react';

const MarkdownPreview = lazy(() => import('./MarkdownPreview.js'));

function Editor() { // ... }

- 기본 내보내기(`export default`) 만 지원하기때문에 기본 내보내기로 했을 때에만 `lazy` 적용시 작동이 된다.
기본 내보내기가 아닌 이름으로 내보내기를 할 경우, 가능은 하나 다음과같이 한 번 더 감싸야하는 번거로운 작업이 추가되므로 권장하지 않는다.

```js
const Comments = React.lazy(() =>
  import('./CommentsModule').then((module) => ({
    default: module.Comments
  }))
)

정리하자면,

• React.lazy 와 Suspense 를 적절히 사용하면 초기 로딩 속도 개선과 네트워크 효율성을 향상시킬 수 있다.
• Suspense 는 감싸는 방식에따라 UI로딩순서를 달리할 수 있으므로 사용자 경험에 맞춘 설계를 해야한다.
• 에러 처리와 export default 규칙에 유의해야한다.

🔗 참고자료 https://ko.react.dev/reference/react/lazy

기존에는 로딩상태표시와 에러표시를 해야할 때 상태 변수를 사용하였다.

useState 를 활용하여 진행을 해도 문제는 없다. 하지만, 관리해야하는 로딩 및 에러상태가 많아진다면 코드가 길어져 가독성이 떨어질 것이다.

이 때, 리액트에서 기본적으로 제공하는 Suspense 를 사용하면 컴포넌트 내에서 로딩 상태를 관리할 필요가 없어진다.

Suspense란?

| Suspense 가 감싸고 있는 자식 요소가 로드되기 전 화면에 대체 UI를 보여주는 로딩상태만 처리하는 기능이다.

// 형태
import { Suspense } from 'react'

<Suspense fallback={...}>
    <SomeComponent />
</Suspense>

속성(Props)

fallback

• 실제 UI가 로딩되기 전까지 렌더링되는 대체 UI이다.
• 보통 로딩 스피너, 스켈레톤과같은 간단한 placeholder 를 활용한다.
• fallback 렌더링이 지연될 경우에는 가장 가까운 부모 Suspense 기능이 활성화된다.

활성화 조건

기본적으로 비동기 데이터 요청시에 활성화가 된다.

• Suspense가 가능한 프레임워크(Relay, Next.js)를 사용한 데이터를 가져올 때
• lazy 를 활용한 지연 로딩 컴포넌트에 사용될 때
• use 를 사용한 캐시된 Promise 값을 읽을 때

Suspense 는 Effect, 이벤트 핸들러 내부에서 가져오는 데이터는 감지하지 않는다.

Suspense 의미를 보면 로딩 상태만 처리를 한다고 되어있다. 그렇다면 에러상태는 어떻게 처리해야하는 걸까? 바로 이전에 살펴봤던 에러 바운더리 에서 처리한다.

Suspense 장점

1. 로딩/에러 상태관리가 간편해진다. ⇒ 컴포넌트에서 직접 상태관리할 필요가 없다.
2. 컴포넌트 코드가 단순해진다.
3. 로딩과 에러 UI를 나누어 관리할 수 있다. ⇒ 코드가 깔끔하고 직관적이게 정리된다.
4. state 또는 props가 변경될 때도 자동으로 fallback UI 가 표시된다. ⇒ 항상 최신 데이터가 준비될 때까지 로딩 UI를 보여준다.

알아두어야할 점

• Suspense 는 어떤 상황에서든지 작동하는 것이 아니다. ⇒ Suspense 를 지원하는 라이브러리나 프레임워크에서만 작동한다. (Next.js, TanStack Query 등)
• fetch 로 데이터를 불러오는 경우에는 동작하지 않는다.

기본적으로 Suspense 로 감싸져있는 내부트리는 하나의 단위로 취급된다. 즉, 여러 컴포넌트 중 하나라도 지연되면 로딩상태 대체 UI가 렌더링된다. (우리는 하나!)

<Suspense fallback={<Loading />}>
  <Biography /> // 로딩완료 → Albums가 로딩완료 되기전까지는 같이 지연상태.
  <Panel>
    <Albums /> // 로딩지연 → Suspense 작동!
  </Panel>
</Suspense>

🤔 그런데 이건 너무 비효율적이라는 생각이 든다. Biography컴포넌트는 데이터 로딩이 완료되었는데도 Albums컴포넌트가 지연되었다고 같은 취급을 받아야 하는 것이다. (억울해!!!)

Biography컴포넌트의 억울함을 풀어줄 방법이 있다.

Suspense 중첩사용

컴포넌트가 지연(일시 중단)이 되면 가장 가까운 상위 Suspense 컴포넌트의 fallback이 활성화된다. 이 특징을 활용하면 Suspense를 중첩하여 컴포넌트 로딩순서를 만들 수 있는 것이다.

공식문서에 나와있는 다음 예시를 통해 확인해보자.

<Suspense fallback={<BigSpinner />}>
  <Biography />
  <Suspense fallback={<AlbumsGlimmer />}>
    <Panel>
      <Albums />
    </Panel>
  </Suspense>
</Suspense>

위 예시에서 Biography 컴포넌트는 이제 Albums 컴포넌트의 데이터 로딩이 완료될 때까지 기다리지 않아도 된다.

작동하는 순서는 다음과 같다.

1. Biography 가 로딩되지 않은 경우 → fallback(BigSpinner) 실행
2. Biography 로딩완료 → fallback(BigSpinner) 이 실 컨텐츠로 대체
3. Albums 가 로딩되지 않은 경우 → fallback(AlbumsGlimmer) 실행
4. Albums 로딩완료 → fallback(AlbumsGlimmer)이 실 컨텐츠로 대체되고 마무리.

이렇게 Suspense 의 중첩을 활용하면 컴포넌트의 로딩 순서를 정할 수 있다.

두-둥 예고편 🎥

항상 suspense를 사용하는 것이 옳은 것은 아니다.

1️⃣ 검색어를 입력하는 상황에서 '사' 라고 입력하고 다음 글자로 '과'를 입력하는데 지연이 발생했다고 하자. 자동완성기능에 '사'로 시작하는 단어들이 나왔다가 '과'를 입력하니까 '로딩중...' 이라고 렌더링이 됐다면? 사용자는 😲*"이게뭐지?"* 하며 어리둥절해할 것이고, 결국 사용자경험(UX)도 좋지않을 것이다.

이럴 때는 '사'라고 입력했을 때의 결과. 즉, 이전 값을 유지한채 '과'에 대한 결과값 로딩을 기다리는 것이 사용자경험 측면에서 더 좋은 방향이다.

예고편1. 이 때 사용하는 것이 다음에 소개할 useDeferredValue 훅(지연된 값) 이다.

2️⃣ 페이지가 로딩될 때 전체적인 레이아웃은 보이는데, 내용은 희미하게 처리되어 보이는 화면을 본 경험이 있을 것이다. (있다고 해주세요 제발)

이렇게 상태 전환이 급하지 않아서 이미 공개된 컨텐츠를 대체UI(fallback) 로 숨기느니 이전 페이지를 계속 표시하는 것이 좋겠다고 리액트에게 알려주면 리액트는 컴포넌트의 로딩이 완료될 때까지 이전 페이지로 대기한다.

예고편2. 이 때 사용하는 것이 다음에 소개할 useTransition 훅(UI우선순위 조정) 이다.

🔗 참고자료 https://ko.react.dev/reference/react/Suspense https://ko.react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary

영화 코코(coco)를 아시나요?

영화 속 수많은 장면들 중에 사진과 같은 장면이 있다. 클로저 에 대해 알아보기 전에 이 사진을 기억하고서 시작해보면 좋을 것 같아 사진을 넣어보았다. 사진을 기억하며 클로저에 대해서 알아보자! (remember me 🎶)

클로저에 대해 이해하기위해 이전에 다뤘던 내용들은 다시 살펴보자.

1️⃣ 13장.스코프에서 렉시컬 스코프에 대해서 다음 내용을 살펴보았다.

*"함수를 어디서 호출했는지가 아니라 어디서 정의했는지에 따라 상위 스코프를 결정한다."*

즉, 함수의 상위 스코프는 함수를 정의한 위치에 의해 정적으로 결정이 되고난 이후에는 변하지 않는다.

2️⃣ 23장.실행컨텍스트에서 스코프 체인에 대해서 다음 내용을 살펴보았다.

*"스코프의 실체는 실행 컨텍스트의 렉시컬 환경이며, 렉시컬 환경은 자신의 '외부 렉시컬 환경에 대한 참조'를 통해 상위 렉시컬 환경과 연결된다."*

위 두 가지 내용을 종합하여 렉시컬 스코프에 대한 개념을 다음과 같이 잡아두고 클로저에 대해서 알아보자.

상위 스코프에 대한 참조는 함수 정의가 평가되는 시점에 함수가 정의된 환경에 의해 결정된다.

함수 객체의 내부 슬롯, [[Environment]]

함수가 정의되는 환경과 호출되는 환경은 다를 수 있다.

그럼 호출되는 환경이 정의된 환경과 다르더라도 정의된 환경에 대해 기억을 해야하지 않을까?

⇒ 정의된 환경에 대해 기억하는 공간이 바로 함수 자신의 내부 슬롯 [[Environment]] 이다.

더 자세히 살펴보자면, 함수 정의가 평가되어 함수 객체를 생성할 때 자신이 정의 된 환경에 의해 결정된 상위 스코프의 참조를 함수 객체 자신의 내부 슬롯 [[Environment]] 에 저장한다. 이 때, 내부슬롯에 저장되는 상위 스코프의 참조는 바로 현재 실행 중인 실행 컨텍스트의 렉시컬 환경 인 셈이다.

함수 정의가 평가되어 함수 객체를 생성하는 시점은 상위 함수가 평가 또는 실행되고 있는 시점이고, 이 때 실행 중인 실행 컨텍스트는 상위 함수의 실행 컨텍스트이기 때문이다.

정리해보자면, 함수 객체의 내부 슬롯에 저장된 현재 실행 중인 실행 컨텍스트의 렉시컬 환경의 참조는 상위 스코프이며, 자신이 호출되었을 때 생성될 '외부 렉시컬 환경에 대한 참조'에 저장될 참조값이기도 하다. 함수 객체는 내부 슬롯에 저장한 상위 스코프를 자신이 존재하는 한 기억하는 것이다. (like coco)

관련하여 예시로 한번 더 살펴보자.

const x = 'squirrel'

function moo() {
  const x = 'minji'
  hoo() // hoo() 호출위치 → 정의된 위치의 렉시컬 환경에서의 기억을 소환(squirrel)
}

function hoo() {
  // hoo() 정의위치(전역) → 전역 렉시컬 환경 기억(squirrel)
  console.log(x)
}

moo() // squirrel
hoo() // squirrel

클로저와 렉시컬 환경

const x = 'squirrel'

function outer() {
  const x = 'minji'
  const inner = function () {console.log(x)}
  return inner
}
// 위 함수가 실행이 되고 outer() 함수는 제 역할을 다 했기 때문에
// 스택에서 pop 되어 사라짐

const innerFunc = outer() // outer() 함수 호출!
innerFunc() // 'minji' ⁉️

outer() 함수의 지역변수 값인 minji 이 예시의 결과값으로 나왔다.

outer() 함수는 호출되고나서 inner함수를 반환하며 제 역할을 다 했기때문에 스택에서 제거가 되었다. 스택에서 제거되면서 가지고 있던 지역변수도 함께 제거가 되었을텐데 어떻게 minji이라는 결과가 나온 것일까?

외부 함수(outer)보다 중첩 함수(inner)가 더 오래 유지되는 경우, 중첩 함수는 제 역할을 다 끝낸 외부 함수의 변수를 참조 할 수 있다. ⇒ 이러한 중첩 함수를 "클로저" 라고 한다.

이 말에 대해서 자세하게 살펴보자.

자바스크립트의 모든 함수는 자신의 상위 스코프를 기억하고, 기억한 상위 스코프는 함수의 호출위치에 상관없이 계속 기억하고있다.

위 예시에서 inner 함수는 자신이 평가될 때 상위 스코프인 outer 를 내부 슬롯에 저장하였다. 즉, outer 함수의 렉시컬 환경이 inner 함수의 내부 슬롯에 저장되어 기억되고 있는 것이다. 그렇기 떄문에 outer 함수의 실행 컨텍스트가 제거되었어도 렉시컬 환경까지 소멸되지는 않은 것이다.

inner 함수에서 outer 함수의 렉시컬 환경을 기억(참조)하고 있기때문에 가비지 컬렉터도 함부로 작업을 시작하지 못한다.

✋🏻 잠깐! 자바스크립트의 모든 함수는 자신의 상위 스코프를 기억한다고 했는데, 그렇다면 중첩 함수는 모두 클로저인가?

"No! 클로저가 되기위한 성립조건이 있어"

클로저 성립조건

아래 예시들을 통해 성립조건을 알아보자.

function foo() {
  const x = 1
  const y = 2

  function bar() {
    const z = 3
    console.log(z)
  }

  return bar
}

const bar = foo()
bar()

위 예시에서 bar 함수는 중첩함수니까 클로저라고 생각할 수 있다. 하지만 여기서 bar 는 클로저가 아니다. 왜? bar 는 외부 함수인 foo 함수의 중첩 함수이긴 하지만, foo 함수의 어떤 식별자도 참조하고 있지 않기 때문이다.

성립조건 1. 상위 스코프의 식별자를 참조하라

자, 이제 다른 예시를 살펴보자.

function foo() {
  const x = 1

  function bar() {
    console.log(x)
  }
  bar()
}

foo()

이 예시에서의 bar 함수는 중첩 함수에다가 foo 함수의 식별자도 참조하고있다. 그렇다면 bar 는 클로저!?!?

안타깝게도 이번에도 땡! 이다 🙂‍↔️ (대체 왜! 뭐때문에!)

이유는 중첩 함수 bar가 외부 함수 foo 의 외부로 반환되지 않았기 때문이다. 즉, 외부 함수보다 중첩 함수가 오래 살아남아야하는데 예시에서는 중첩 함수의 생명주기가 외부 함수보다 짧다. (bar 는 아주 찰나의 클로저였달까..)

성립조건 2. 외부 함수보다 오래 살아남아라

위 성립조건 두 가지를 충족하는 bar 함수가 클로저가 될 수 있는 예시는 다음과 같다.

function foo() {
  const x = 1
  const y = 2

  function bar() {
    console.log(x)
  }

  return bar
}

const bar = foo()
bar()

✋🏻 잠깐! 위 예시에서 중첩 함수 bar 는 foo 함수의 식별자 중 x 만 참조를 하고 있다. 그렇다면 참조되지않는 y 는 어떻게 되는걸까?

소중한 메모리 공간을 생각하여 클로저가 참조하지 않는 식별자는 기억되지 못하고 GC(Garbage Collector)에게 수거된다.

이처럼 클로저에 의해 참조되는 상위 스코프의 변수는 자유 변수(free variable) 이라고 부른다.

여기서 클로저라는 말의 의미와 연결될 수 있는데, 클로저란 "함수가 자유 변수에 묶여있다. (닫혀있다)" 라는 의미이다

클로저의 활용

클로저는 자바스크립트의 강력한 기능 중 하나로 적극적으로 활용하면 유용하게 사용될 수 있다.

유용하게 사용되는 상황들 중 대표적인 상황을 살펴보자.

상태를 안전하게 변경하고 유지하기 위한 상황

즉, 상태가 의도치않게 변경되지 않도록 은닉하고 특정 함수에게만 상태 변경을 허용하기 위해 사용되는 것이다.

아래 예시와 함께 살펴보자

// 문제상황 👿
let num = 0

const increase = function() {

  return ++num
}

console.log(increase()) // 1
console.log(increase()) // 2
console.log(increase()) // 3

위 예시에서 함수 내에서 사용되는 변수는 전역 변수를통해 관리되고 있다. 이렇게되면 언제든지, 누구나 접근을 할 수 있기 때문에 의도치 않게 값이 변경될 수 있고 그렇게 되면 오류발생으로 이어진다.

카운트 상태를 나타내는 전역 변수인 num 을 다음과같이 안전하게 은닉하는 것이 필요하다.

const increase = function() {
  let num = 0 // 은닉 완료 😎

  return ++num
}

console.log(increase()) // 1
console.log(increase()) // 1 ⁉️
console.log(increase()) // 1 ⁉️

이제 num 변수는 increase 함수의 지역 변수로 변경되어 오염될 일은 사라졌다.

그런데 또 다른 문제가 있다. 바로 increase 함수가 호출될 때마다 지역 변수인 num 이 초기화 되어 출력 결과가 언제나 동일하다는 것이다.

이전 상태를 유지해야 num이 하나씩 증가하는 함수의 목적을 실현시킬 수 있다. 이 때 클로저를 사용해보면 어떨까?

const increase = (function() {
  let num = 0

  // 클로저!
  return function() {
    return ++num
  }
}())

console.log(increase()) // 1
console.log(increase()) // 2
console.log(increase()) // 3

즉시 실행함수가 호출된 이후 클로저 함수를 반환하고 사라진다. 하지만 클로저 함수가 자유변수 num 을 기억하고 있기 때문에 초기화 되지않고 이전 상태를 기억하고 num이 하나씩 증가는 결과를 가져온다.

캡슐화와 정보은닉

캡슐화란?

| 객체의 상태를 나타내는 프로퍼티와 프로퍼티를 참조하고 조작할 수 있는 메서드를 하나로 묶는 것을 말한다.

정보은닉이란?

| 위에서 말한 캡슐화가 객체의 특정 프로퍼티나 메서드를 감출 목적으로 사용되는 것을 말한다.

자바스크립트는 다른 객체지향 프로그래밍 언어와 다르게 public, private, protected 와 같은 공개범위를 한정할 수 있는 접근 제한자를 제공하지 않는다. 그렇기 때문에 자바스크립트 객체의 모든 프로퍼티 와 메서드는 기본적으로 외부에 공개되는 public 으로 선언되어 있다.

인스턴스 메서드와 프로토타입을 활용하여 private 흉내를 낼 수는 있지만 완전하다고 할 수는 없다.

이와 관련한 자세한 내용은 다음장인 25장.클래스에서 살펴보자.

클로저 사용시 자주하는 실수

다음은 클로저를 사용할 때 자주 발생할 수 있는 실수를 보여주는 예시이다.

var funcs =[]

for (var i = 0; i < 3; i++) {
  funcs[i] = function() {return i}
}

for (var j = 0; j < funcs.length; j++) {
  console.log(funcs[j]())
}

위 예시에서 기대하는 결과값은 0, 1, 2 이다. 안타깝게도 실제 결과값은 3 이 출력된다.

이유는 for문에서 변수 선언시 var 키워드로 선언하였기 때문이다. 13장.스코프에서도 살펴봤듯 var키워드는 블록 레벨 스코프가 아니라 함수 레벨 스코프를 갖기때문에 전역 변수이다.

그렇기 떄문에 최종적으로 funcs[j] 함수를 호출하면 3이라는 결과값이 나온다.

위 예시를 기대하는 결과값으로 도출하기 위해서는 어떻게 수정하면 좋을까?

책에 나와있는 클로저를 사용한 방법은 우리가 자주 보던 형태는 아니다. (그리고 복잡해보인다)

우리에게 익숙한, 자주 보던 형태로 수정해보자!

const funcs = []

for (let i = 0; i < 3; i++) {
  funcs[i] = function() {return i}
}

for (let i = 0; i < funcs.length; i++) {
  console.log(funcs[i]())
}

*const 와 let 을 보니 마음이 편-안해진다. 😊 *

이처럼 let 키워드로 선언한 변수를 사용하면 반복 실행될 때마다 for문 코드 브록의 새로운 렉시컬 환경이 생성되며 식별자의 값을 유지한다. (like 스냅샷)

단, 함수가 반복문의 코드 블록 내부에서 정의되어야 적용이 되는 내용이다. 반복문의 코드 블록 내부에 함수 정의가 없다면 생성된 렉시컬 환경을 참조하는 곳이 없기때문에 가비지 컬렉션의 타겟이 된다. 👀

정리하자면,

클로저란?

| 외부 함수(outer)보다 중첩 함수(inner)가 더 오래 유지되는 경우, 중첩 함수가 제 역할을 다 끝낸 외부 함수의 변수를 참조하는 것

클로저 성립조건

1️⃣ 상위 스코프의 식별자를 참조하라 2️⃣ 외부 함수보다 오래 살아남아라

클로저의 활용

| 상태가 의도치않게 변경되지 않도록 은닉하고 특정 함수에게만 상태 변경을 허용하고자할 때 활용하자

리액트에서는 컴포넌트간 상태공유를 할 때, 부모 컴포넌트에서 상태관리를 하면서 자식 컴포넌트에는 상태정보를 props 로 전달한다.

다음과같이 단순한 구조에서는 상태를 공유하고 관리하는 것이 어렵지 않다.

하지만, 상태 끌어올리기 글에서도 다뤘듯이 자식 컴포넌트에서 관리중이던 state 를 부모 컴포넌트로 끌어올려 공유해야하는 상황도 있다.

상태를 끌어올리기만 하는 상황이 있는 것은 아니다. 아래와 같은 상황에서 A컴포넌트에서 C컴포넌트 로 상태를 전달하려면 중간에 C컴포넌트 에 관여하지 않는 컴포넌트에도 props 를 전달하여야 합니다.

내가 필요한 state도 아닌데 전달만하기위해서 props를 받아서 전달을 해야한다면? 물론, 하면 해! 한다면 할 말이 없지만 무척 비효율적인 처리방식이다. 이러한 처리방식을 Props Drilling 이라고한다.

✋🏻Props Drilling 이란? props를 오로지 하위 컴포넌트로 전달하는 용도로만 사용하는 컴포넌트들을 거치면서 데이터를 전달하는 과정이다. state를 전달해줄 상위 컴포넌트가 너무 높이 위치해있어서 하위 컴포넌트까지 props로 내려가는것이 드릴과 비슷하여 붙여진 이름이지 않을까싶다.

Props Drilling은 비효율적인 부분뿐만 아니라 코드가 복잡해지고 그로인해 유지보수가 어려워지는 문제까지 야기한다. 또한, 컴포넌트 구조가 변경되면 props 전달경로도 함께 변경되어야하므로 효율을 중시하는 개발에서는 질색팔색할 일인 것이다. 🤯

그렇다면 C컴포넌트 에서 필요한 state니까 A컴포넌트 에서 바로 전달하면 편하고 좋지않을까?!

그래서 등장한 것이 리액트의 컨텍스트(Context) 이다. 컨텍스트(Context) 를 사용하면 컨텍스트의 내부에 값을 공유할 수 있다.

컨텍스트(Context)란?

| 부모 컴포넌트가 트리 전체에 데이터를 전달할 수 있도록 해주는 것

자세히 살펴보겠지만 간단하게 context가 진행되는 단계는 다음과 같다.

1. Context 생성

   const Context = createContext(defaultValue)

2. 데이터가 필요한 컴포넌트에서 context를 사용

   // 레거시 방식 (사용권장 ❌)
   function Button() {
   return (
    <ThemeContext.Consumer> // .Counsumer는 생략불가능 ❌
        //...
    </ThemeContext.Consumer>
   )
   }
   

// useContext 방식 (사용권장 ✅) function Button() { const theme = useContext(ThemeContext) return

3. 데이터를 **지정**하는 컴포넌트에서 context를 **제공**
```js
function App() {
  const [theme, setTheme] = useState('light')
  // ...
  return (
    <ThemeContext.Provider value={theme}> // .Provider 생략가능 ✅
        <Page />
    </ThemeContext.Provider>
}

컨텍스트의 특징

• 정적인 값뿐만 아니라 동적인 값도 전달할 수 있다.
• 값이 변경되면 공유받은 하위 컴포넌트들의 값도 자동으로 업데이트 된다.
• createContext() 로 생성한 컨텍스트는 완벽하게 분리되어 있기 때문에 서로 다른 리액트 context는 서로에게 영향을 주지 않는다. → 하나의 컴포넌트에서 여러 컨텍스트를 사용 또는 제공할 수 있다.

컨텍스트가 사용되는 대표적인 예시

1. 상태관리 2. 테마관리

• 라이트 / 다크모드 전환시, 상단에 테마 컨텍스트 공급자를 위치시키고 하위 컴포넌트에서는 정보를 읽게하면 모드 전환을 쉽게 할 수 있다.

3. 인증관리

• 로그인한 사용자 정보는 여러 컴포넌트에서 필요할 것이다. 이 때, 컨텍스트에 사용자 정보를 저장해두고 필요한 컴포넌트에서 접근하여 사용할 수 있다.

4. 라우팅관리

이제 위에서 간단하게 살펴봤던 context 의 진행단계에 대해서 살펴보자.

1️⃣ 컨텍스트 생성

컨텍스트를 생성하여 사용하려면 먼저 createContext를 import 해야한다. 이를 통해 컨텍스트 객체를 만들 수 있는데, 생성된 컨텍스트 객체는 공급자(Provider) 와 소비자(Consumer) 를 포함한다.

생성시 매개변수로 defaultValue를 받는데, 이 값은 상위에 일치하는 컨텍스트 제공자가 없을 경우 컨텍스트가 가지는 기본값이다. 의미있게 설정할 기본값이 없으면 null 로 설정하면되며, 이 값은 정적인 값으로 시간이 지나도 변경되지 않는다.

생성을 하면 위에서 언급한 컨텍스트 객체를 반환하게 되는데, 객체 자체는 어떠한 정보도 가지고 있지 않다. 대신 다음의 몇 가지 속성을 가지고 있다.

• SomeContext : 컴포넌트에 컨텍스트 값을 제공한다.
• SomeContext.Consumner : 컨텍스트 값을 읽는 방식이며, useContext가 등장하기 전의 방식이다. (legacy way)
• SomeContext.Provider : 컨텍스트 제공자로, 컴포넌트를 감싸서 컨텍스트의 값을 모든 내부 컴포넌트에 지정한다. (legacy way)

반환된 컨텍스트 객체를 컴포넌트가 useContext()에 전달하여 컨텍스트 값을 읽을 수 있게 한다.

// 기본 형태
import { createContext } from 'react'

export const MyContext = createContext(defaultValue)

import { createContext } from 'react'

export const THEME = {
    light: {
        foreground: '#000',
        background: '#fff',
    },
    dark: {
        foreground: '#fff',
        background: '#000',    
    }
}

// 다른 컴포넌트에서 사용할 수 있도록 export 
export const ThemeContext = createContext() // createContext의 유일한 인자는 '기본값'임

console.log(ThemeContext.Provider) // 공급자
console.log(ThemeContext.Consumer) // 소비자

2️⃣ 컨텍스트 값 제공 (Provider)

컨텍스트를 제공하지 않으면 리액트는 생성단계에서 지정한 기본값을 가져온다. 생성한 컨텍스트를 자식 컴포넌트에게 제공하기 위해서는 provider 가 필요하다.

3️⃣ 컨텍스트 값 사용 (Consumer)

생성한 컨텍스트를 사용하려면 useContext 라는 리액트 훅이 필요하다. 더불어 생성한 컨텍스트를 사용하려는 컴포넌트에서는 useContext 훅과 함께 생성 컨텍스트도 필요하다.

import { useContext } from 'react'
import { ThemeContext } from '파일위치'

export default function Toolbar() {
  const [mode] = useContext(ThemeContext) // 컨텍스트 값 읽기
  // ...

⚙️ 효율적인 컨텍스트 관리

컴포넌트 내부에 작성된 컨텍스트 로직을 별도의 파일로 분리하여 사용 및 관리하는 것이 유지보수 측면에서도, 코드의 가독성 측면에서도 좋다.

1. 별도의 파일에 사용할 컨텍스트 생성
2. 프로바이더 컴포넌트 작성

• 컨텍스트에 실제 값을 넣어서 하위 컴포넌트에 전달해주는 컴포넌트로, 상태와 상태 업데이트 함수를 값으로 제공한다.

3. 프로바이더 컴포넌트 사용

• 상태를 공유할 컴포넌트를 프로바이더 컴포넌트로 감싸준다.
• 프로바이더 컴포넌트에 감싸진 컴포넌트와 그 하위 컴포넌트 모두 상태를 공유받게 된다.

---

✋🏻잠깐! 지금까지 컨텍스트에 대해 살펴봤는데 그래서 useContext가 뭔데?

useContext 란?

| 컴포넌트에서 Context 를 읽고 구독할 수 있는 리액트 훅이다.

형태

const value = useContext(SomeContext)

매개변수

• SomeContext : createContext 로 생성한 컨텍스트로 자체적으로 정보를 담고 있지는 않다. 참고

반환값

• 호출하는 컴포넌트에 대한 컨텍스트 값을 반환한다.
• 트리에서 호출하는 컴포넌트 상위의 가장 가까운 SomeContext에 전달된 값으로 결정된다.
• Provider가 없으면 반환되는 값은 생성시 설정한 defaultValue가 되며, 반환된 값은 항상 최신상태이다.
• 컨텍스트가 변경되면 리액트는 자동으로 변경된 컨텍스트를 읽는 컴포넌트를 리렌더링한다.

useContext() 는 항상 호출하는 컴포넌트 상위에서 가장 가까운 Provider 를 찾는다. 위쪽 방향으로 찾으며, 호출하는 컴포넌트 내의 Provider 는 고려하지 않는다.

context 를 업데이트하려면 State와 함께 시너지효과를 내보자!

---

🔗 참고자료 https://ko.react.dev/reference/react/createContext https://ko.react.dev/reference/react/useContext https://ko.react.dev/learn/passing-data-deeply-with-context https://ko.react.dev/learn/scaling-up-with-reducer-and-context#moving-all-wiring-into-a-single-file https://kentcdodds.com/blog/prop-drilling

]]> https://velog.io/@minji-kim0524/%EB%A9%8B%EC%9F%81%EC%9D%B4%EC%82%AC%EC%9E%90%EC%B2%98%EB%9F%BCREACT-useReducer-Hook https://velog.io/@minji-kim0524/%EB%A9%8B%EC%9F%81%EC%9D%B4%EC%82%AC%EC%9E%90%EC%B2%98%EB%9F%BCREACT-useReducer-Hook Fri, 12 Sep 2025 05:41:35 GMT *"관리해야하는 상태가 많아지고 힘들어질 땐 나를 찾아와!"*

---

'상태관리하는 훅' 이라고하면 자연스럽게 useState 를 떠올리게 된다. 하지만, 관리해야하는 상태의 규모가 커지고 복잡해진다면 useState 만 사용해서 관리하기엔 (코드가독성저하, 유지보수등 여러 관리측면으로)어려워 질것이다.

그럴때 사용하는 것이 useReducer 라는 훅이다.

useReducer란?

| 컴포넌트에 reducer 함수를 추가하는 React Hook이다.

이 훅을 사용하면 상태와 상태를 변경하는 로직을 분리하여 관리할 수 있다.

상태가 어떻게 변해야하는지의 규칙은 리듀서 함수에 담고, 상태를 변경할 때는 액션을 전달하여 상태업데이트를 진행한다. 이 방식은 나중에 다룰 내용인 리덕스와 매우 유사하지만, ~~전역 상태에서 사용하는 리덕스~~와 달리 useReducer 는 컴포넌트 내부에서만 사용할 수 있고, 설정이 간단하다.

✋🏻 reduce 함수란 뭘까? useState 사용 형태를 보면 const [state, setState] 라고해서 상태를 관리하는 함수인 setState 가 있다. reduce 가 useReducer 에서는 setState 의 역할을 하는 것이다. 즉, 컴포넌트 내부에 있는 state 로직을 reduce 가 받는것이다.

// 형태
const [state, dispatch] = useReducer(reducer, initialArg, init?)

위와같이 생긴 useReducer 는 다음과 같이 컴포넌트 최상위에서 호출하고 사용(state 관리)한다.

// useReducer 호출
import { useReducer } from 'react'

// reducer 함수 선언
function reducer(state, action) {
  // ...
}

function Component() {
  const [state, dispatch] = useReducer(reducer, { key: value })
  // ...

위의 기본형태를 활용하여 어떻게 사용하는지에 대한 간단한 예시는 다음과 같다.

import { useReducer } from 'react'

function Counter() {
  const [state, dispatch] = useReducer(reducer, { count: 0 })

  return (
    <div className="counter">
      <p>카운트: {state.count}</p>
      <button 
          type="button" 
          onClick={() => dispatch({ type: 'decrement' })}
          aria-label="카운트 감소"
        >
            -
          </button>
      <button 
          type="button" 
          onClick={() => dispatch({ type: 'increment' })}
          aria-label="카운트 증가"
        >
            -
          </button>
    </div>
  )
}

function reducer(state, action) {
  switch (action.type) {
    case 'increment': return { count: state.count + 1 }
    case 'decrement': return { count: state.count - 1 }
    default: return state
  }
}

핵심은 상태를 변경하려면 dispatch 함수를 사용해야하고, 실제 상태 변경 로직은 전부 reducer 함수 내부에 모여있다는 점이다.

매개변수

1️⃣ reducer

• state 업데이트를 진행하는 함수로 반드시 순수함수 여야한다.
• 인수로 state 와 action 을 받으며, 다음 state 를 반환해야한다.
• 인수에는 모든 데이터타입이 할당가능하다.
• 실제 상태변경 로직이 모여있는 곳

function (state, action) {
  swtich(action.type) {
    case 'added_todo" : {
        return {
            ...state,
            todos: [
              ...state.todos,
              {id: nextId++, text: action.text}
            ]
          }
    }
    // ...
  }
}

2️⃣ initialArg

• 초기 state 가 계산되는 값이다.
• 모든 데이터타입이 할당될 수 있다.
• 초기 state 가 어떻게 계산되는지는 다음 init 인수에 달렸다.

3️⃣ (optional)init

• 초기 state를 반환하는 초기화 함수이다.
• 선택사항인만큼 해당 인수가 할당되지 않았을 경우의 초기 state는 initialArg 로 설정된다.
• 인수로 할당이 되었다면 초기 state는 init(initialArg) 를 호출한 결과가 할당된다.

반환값

2개의 엘리먼트로 구성된 배열을 반환한다. 1️⃣ 현재 state: 첫 번째 렌더링에서의 state는 init(initialArg)의 결과 또는 initialArg로 설정된다. (읽기전용으로 변경할 수 없다 ❌) 2️⃣ dispatch 함수: state를 새로운 값으로 업데이트하고 리렌더링을 일으킨다. (상태변경함수)

⇒ 화면을 업데이트하려면 action 객체(사용자가 수행한 활동)를 인수로하여 dispatch함수를 호출해야한다.

✋🏻 dispatch란?

• useReducer에 의해 반환되는 함수이며, state를 새로운 값으로 업데이트하고 리렌더링을 일으킨다.
• dispatch 함수의 유일한 인수는 action이며, dispatch 함수는 어떤 값도 반환하지 않는다. → 다음 렌더링에 사용할 state 변수 업데이트만 진행한다.
• dispatch 함수 호출은 현재 동작하고 있는 코드의 state를 변경하지 않는다. → 함수 호출 직후에 state변수를 읽으면 호출 이전의 최신화되기전 값을 참조하게 된다.
• dispatch 함수의 매개변수인 action은 사용자에 의해 수행된 활동이며, 모든 데이터 타입이 할당될 수 있다.
• action 은 객체형태로 이루어져있으며, type 프로퍼티와 payload 프로퍼티로 구성되어있다.
• action 의 type 프로퍼티이름은 컴포넌트 내에 단일 상호작용을 설명하는 지역적 특성을 가지고 있다.

  // action 형태
  type Action = {type: /*액션이 무엇인지 정의*/, payload: ...}
  // dispatch 형태
  const [state, dispatch] = useReducer(reducer, { key: value })
  function handleClick() {
  dispatch({type: action.type /*reducer가 다음 state를 계산하는데 필요한 정보*/})
  // ...

useReducer 잘 작성하는 방법

1. 반드시 순수해야 한다.

• reducer 는 렌더링 중에 실행된다. (action은 다음 렌더링까지 대기) → 동일입력 동일출력이 이루어져야한다. ⇒ 순수해야 한다.
• 컴포넌트 외부에 영향을 미치는 사이드 이펙트를 수행해서는 안된다.
• 객체와 배열을 변경하지 않고 업데이트 해야한다.

2. action 발생으로 인해 여러 데이터가 변경되더라도, 모든 데이터 변경을 포함하는 하나의 명확한 상호작용을 나타내야한다.

• 모든 action 을 reducer에 기록할 경우, 어떤 상호작용이나 응답이 어떤 순서로 일어났는지를 재구성할 수 있을 정도로 로그가 명확해야 한다. → 디버깅이 용이해진다.
• 예: reducer가 관리하는 5개의 필드가 있다. 해당 양식에서 '재설정' 버튼을 눌렀을 때, 각각의 필드에서 action 을 발생시키는 것 보다는 하나의 action 을 전송하는 것이 더 합리적이다.

useState vs. useReducer 비교표

비교항목	useState	useReducer
코드크기	간단명료 → 단순한 상태에 적합	작성해야하는 코드양 많음 → 여러 이벤트가 상태를 바꾸는 등의 복잡한 상태관리에서는 오히려 코드가 간결해짐
가독성	상태가 단순하거나 컴포넌트가 작을 때 가독성이 좋음	상태가 복잡하거나 컴포넌트의 규모가 커질수록 가독성이 좋음
디버깅	잘못된 위치와 이유 파악이 어려움	모든 상태 업데이트와 액션이 한 곳(리듀서)에 모여있어 파악이 쉬움
테스트	상태 업데이트 로직이 컴포넌트에 의존하고있어 테스트가 어려움	로직(리듀서)이 컴포넌트에 의존하지않는 순수함수로, 독립적으로 분리되어있어 테스트하기에 용이함
선호도 (취향에 맞게 선택가능)	직관적이며 익숙한 방식	구조적이며 명확한 방식
혼용 가능여부	다른 hook과 함께 사용가능 / useReducer 와 혼용가능	다른 hook과 함께 사용가능 / useState 와 혼용가능

---

여기서 조금 더 파고들어가본다면, 배열을 사용해서 리액트 상태를 관리할 때 useState 대신 useImmer 로 사용이 가능하다고 했다. Immer 라이브러리를 이용하여 일반적인 state에서 객체와 배열을 업데이트 했던 것처럼, Immer 라이브러리를 사용하면 reducer 를 더 간결하게 작성할 수 있다.

Immer 라이브러리에서 제공하는 useImmerReducer 를 import 하여 push 또는 arr[i] = 으로 값을 할당함으로써 state 변경이 가능하다.

그런데 여기서 드는 의문은ruducer는 순수함수라고 했는데, state 변경을 하면 동일입력 동일출력이 이루어지지않지 않을까? ⇒ Immer 는 내부적으로 변경사항이 반영된 draft 를 이용하여 state 복사본을 생성한다. 그렇기때문에 state 변경이 가능한 것이다.

---

🔗 참고자료 https://ko.react.dev/reference/react/useReducer https://ko.react.dev/learn/extracting-state-logic-into-a-reducer

]]> https://velog.io/@minji-kim0524/%EB%A9%8B%EC%9F%81%EC%9D%B4%EC%82%AC%EC%9E%90%EC%B2%98%EB%9F%BCREACT-Flux-Architecture https://velog.io/@minji-kim0524/%EB%A9%8B%EC%9F%81%EC%9D%B4%EC%82%AC%EC%9E%90%EC%B2%98%EB%9F%BCREACT-Flux-Architecture Thu, 11 Sep 2025 12:02:15 GMT 리액트의 단방향 데이터 흐름 패턴

---

useReducer 에 대해서 알아보기전에 리액트의 단방향 데이터흐름 패턴에 대해서 간단하게 살펴보자.

Flux 아키텍처란?

페이스북에서만든 데이터 흐름 패턴으로, 데이터의 단방향 흐름을 파악하여 상태관리를 쉽게 할 수 있도록 이해를 높여준다.

Flux 아키텍처 구성요소

1️⃣ 액션 (Action)

• 사용자의 입력이나 이벤트가 해당됨
• 예: 버튼클릭, 데이터 추가 등

2️⃣ 디스패처 (Dispatcher)

• 모든 액션을 받아 스토어에 전달하는 중간 관리자역할
• 함수가 위치하는 곳

3️⃣ 스토어 (Store)

• 실제 데이터와 상태를 저장하는 곳
• 디스패처로부터 받은 액션을 데이터로 변경 액션 → 데이터

4️⃣ 뷰 (View)

• 사용자에게 보여지는 화면
• 스토어에서 받아온 데이터를 화면에 렌더링

Flux 아키텍처를 바탕으로 데이터가 어떻게 한 방향으로 흐르는지 살펴보면 다음과 같다.

Flux 아키텍처 데이터 흐름

사용자 입력
   ↓
Action : { type, payload } 객체 구성
   ↓
Dispatcher : Action 전달
   ↓
Store : 전달된 Action으로 데이터 변경
   ↓
View : 변경된 데이터로 다시 렌더링

[사용자 입력] → [Action] → [Dispatcher] → [Store] → [View]

디스패처라는 단어를 보니 디스패치 가 생각이 나면서... 데이터 흐름을 조금 더 쉽게 이해하기위해 나는 이렇게 비유해서 이해해보았다.

단계	비유
액션 (Action)	사건 발생(예를들면 열애설)
디스패처 (Dispatcher)	디스패치 기자가 사건정보를 수집
스토어 (Store)	정보를 전달받은 방송국, 기사를 쓰기시작
컨트롤러 뷰(Controller View) & 뷰 (View)	인터넷에 기사가 올라가고 확인가능한 상태가 됨

위 비유는 단순히 각 단계를 이해하기위한 내용이고, 애플리케이션의 데이터 흐름관점으로 단계를 살펴보면 다음과 같다.

먼저, 애플리케이션이 초기화될 때 첫 번째 준비과정을 거친다.

1. 스토어 → 디스패처 : *"액션이 들어오면 알려줘!"*
2. 컨트롤러 뷰 → 스토어 : *"업데이트된 최신 상태있어? 이거 맞아?"*
3. 스토어 → 컨트롤러 뷰 : *"여기 업데이트된 최신 상태가 있어! 전달할게!"*
4. 컨트롤러 뷰 → 뷰 : *"(자식)뷰들아, 최신 상태 전달할게 받으렴"*
5. 뷰 : *"전달받은 최신 상태를 렌더링 해볼까나"*

위와같은 준비과정이 끝나면 애플리케이션은 사용자 입력을 받아들일 준비가 완료된 것이다.

🪄 이제 사용자 입력을 통해 액션(Action)이 발생했을 때의 데이터 흐름을 살펴보자.

1. 사용자 입력 발생!
2. 뷰 → 액션 : *"준비해! (레뒤)"*
3. 액션 → 디스패처 : *"여기 사건(액션)이 발생했어!"*
4. 디스패처 → 스토어 : *"(전달된 액션 순서대로) 여기 발생한 액션 전달할게~"*
5. 스토어 : *"(필요한 액션만 골라서) 보자보자 상황에 맞게 좀 바꿔볼까"*
6. 스토어 → 컨트롤러 뷰 : *"나 구독하고 있지? 여기 니가 필요할만한 것들을 모아봤어. 선물이야😎"*
7. 컨트롤러 뷰 → 뷰 : *"자, 업데이트된 데이터(상태)가 들어왔어! 상태에 맞게 화면 렌더링 시작하자구"*
8. 뷰 : *"업데이트된 데이터(상태)로 렌더링을 시작하지"*

리액트는 이러한 Flux 아키텍처의 원리를 활용하여 복잡한 상태관리를 하는 훅인 useReducer 를 제공한다.

다음 글에서는 복잡한 상태를 관리하는 훅인만큼 조금은 복잡한 useReducer 에 대해서 살펴보자!

---

정리하자면,

Flux 아키텍처의 전체 흐름

1. 사용자 요청 → 액션 생선
2. 액션을 디스패처에 전달
3. 디스패처가 액션을 스토어에 전달
4. 스토어가 상태 업데이트 및 콜백 실행
5. 뷰가 상태 변경 감지 및 상태 전달요청
6. 뷰가 전달받은 새로운 상태로 리렌더링

---

🔗 참고자료 https://facebookarchive.github.io/flux/ https://www.youtube.com/watch?v=i__969noyAM&t=125s

]]>