코딩하는퇴근길

[개발읽기 vol.10] 프론트엔드 개발자를 위한 Node.js와 npm 기초 완벽 정리

콘솔로그 — Wed, 17 Sep 2025 12:58:12 +0900

회사나 프로젝트에서 프론트엔드 개발을 시작할 때, 우리가 가장 먼저 하는 일은 깃(Git)에서 소스를 받아오는 것입니다.
그리고 소스를 받은 뒤 거의 자동처럼 입력하는 명령어가 있죠.

바로 npm install 입니다.

이 명령어 하나로 수많은 라이브러리와 패키지가 설치되고, 프로젝트가 실행 가능한 상태로 세팅됩니다.

그런데 잠깐, 여기서 궁금증이 생깁니다.
npm이 도대체 뭐길래 이런 일을 해주는 걸까요?
그리고 이 npm을 사용하기 위해 꼭 필요한 Node.js는 왜 존재하는 걸까요?

오늘은 프론트엔드 개발자라면 반드시 알아야 할 Node.js와 npm에 대해,
그 배경과 역할, 그리고 왜 생겨났는지를 차근차근 풀어보려 합니다.

들어가기 이전에 미리 알고 가야하는 개념이 있어요.

프론트엔드 개발자가 코드를 작성을 하고 코드를 실행할 수 있는 “실행 환경”이 필요해요.

예를 들어,

자전거 = JavaScript 코드

자전거 자체만으로는 이동할 수 없음
자전거는 규칙과 기능만 가지고 있음 (페달 밟으면 굴러간다, 핸들 돌리면 방향 전환)

사람 = 런타임 환경(실행 환경)

사람이 페달을 밟아야 자전거가 움직임 (런타임이 없으면 코드가 실행되지 않는다)
브라우저나 Node.js 같은 런타임 환경이 코드 실행을 가능하게 하는 힘
사람이 자전거를 조종하듯, 런타임이 JavaScript 코드를 해석하고 실행

이 개념을 잘 기억하고, 이제 본격적으로 Node.js에 대해 설명해보겠습니다.

브라우저 = JavaScript 런타임 환경

브라우저는 원래 웹 페이지를 실행하기 위해 만들어졌습니다.
따라서 브라우저 런타임에서는 아래와 같은 기능과 API를 제공해요.

JavaScript 엔진 (예: Chrome=V8, Firefox=SpiderMonkey)
Web API (DOM, BOM, Fetch API, Cookies, localStorage 등)
이벤트 루프, 콜백 큐

덕분에 버튼 클릭, 화면 변경, Ajax 요청 같은 동작이 가능

⚙️ Node.js = JavaScript 런타임 환경

Node.js는 브라우저 밖에서 JavaScript 실행을 가능하게 만든 런타임입니다.
Node 런타임에서는 아래와 같은 기능과 API를 제공해요.

JavaScript 엔진 (V8)
Node 전용 API (파일 시스템 fs, 네트워크 net/http, OS, 이벤트 모듈 등)
이벤트 루프, 비동기 I/O

덕분에 서버 실행, DB 연결, 파일 읽기/쓰기 같은 동작이 가능

Node.js란 무엇인가?

Node.js는 오픈 소스이자 크로스 플랫폼 JavaScript 런타임 환경입니다.
자바스크립트(JavaScript)는 원래 웹 페이지 안에서 동작하도록 만들어진 언어예요.

예를 들어, 브라우저(Chrome, Safari, Firefox 등)에서:

버튼을 클릭했을 때 글씨를 바꾸거나
팝업을 띄우는 동작

이 모든 것이 브라우저 안에서 JavaScript 코드가 실행되기 때문에 가능합니다.

하지만 Node.js를 설치하면 브라우저 없이도 컴퓨터 터미널에서 JavaScript를 바로 실행할 수 있습니다.
실제로 실행해보려면:

터미널을 엽니다.
node라고 입력하고 엔터를 누릅니다.
이제 바로 JavaScript 코드를 입력하고 실행할 수 있습니다.

한 줄 요약: 런타임 환경 = JavaScript 코드가 실행되고, 주변 기능을 제공받는 환경입니다.

node.js는 어떤 특징을 가지고 있는지 알아보겠습니다.

1️⃣ V8 엔진 기반의 높은 성능

Node.js는 Google Chrome의 핵심 엔진인 V8 JavaScript 엔진을 브라우저 외부에서도 실행합니다.
덕분에:
- 매우 빠른 성능과 효율성 ⚡
- 최신 ECMAScript 표준 지원
즉, 브라우저 없이도 빠르고 현대적인 자바스크립트를 활용할 수 있습니다.

// Node.js에서 최신 JavaScript 문법 바로 사용 가능
const greet = (name) => {
  console.log(`Hello, ${name}!`);
};

greet("Node.js"); // Hello, Node.js!

2️⃣ 비동기 I/O와 논블로킹 아키텍처

Node.js는 요청마다 새로운 스레드를 생성하지 않고 단일 프로세스로 실행됩니다.
덕분에:
- 동시에 많은 요청 처리 가능 (고성능 서버)⏱️
  단일쓰레드인데 어떻게 동시에 많은 요청이 처리 가능한걸까?
  비동기 I/O 덕분에 동시에 처리 가능.
  Node.js가 I/O 작업(파일 읽기, HTTP 요청 등)을 만나면 자바스크립트 코드 실행은 멈추지 않고 작업을 백그라운드로 넘김
  -> 작업이 끝나면 콜백 함수, Promise, async/await 등을 통해 결과를 다시 처리
- 블로킹 없이 빠른 I/O 처리
즉, 서버가 다른 작업을 기다리지 않고 효율적으로 여러 작업을 동시에 처리할 수 있습니다.

단일 프로세스(Single Process) : 프로그램이 하나의 프로세스만 사용하여 실행되는 것
즉, Node.js 앱을 실행하면 하나의 프로세스 안에서 모든 코드가 돌아감

프로세스 : 프로그램이 실행 중인 상태를 운영체제에서 관리하는 단위
예시) 브라우저 하나를 열면 하나의 프로세스가 생성 메모장에서 메모장 프로그램을 열면 또 다른 프로세스가 생성

비동기 I/O 방식을 사용하여 CPU 자원을 효율적으로 활용하며,
네트워크, 데이터베이스, 파일 시스템 작업 시에도 스레드를 차단하지 않습니다.

// 파일을 비동기적으로 읽는 예시
const fs = require("fs");

fs.readFile("example.txt", "utf8", (err, data) => {
  if (err) {
    console.error("파일 읽기 에러:", err);
    return;
  }
  console.log("파일 내용:", data);
});

console.log("읽기 요청 완료"); // 이 부분이 먼저 실행됨

3️⃣ 스레드 관리의 부담 없는 개발 환경

전통적인 서버 환경에서는 스레드 동시성 관리가 버그의 주요 원인이 되곤 합니다.
그러나 Node.js는 기본적으로 논블로킹 패러다임을 따르기 때문에
개발자가 스레드 동기화 문제에 신경 쓰지 않아도 됩니다.

블로킹(Blocking) vs 논블로킹(Non-blocking)
블로킹 : 어떤 작업이 끝날 때까지 다음 코드 실행을 기다리는 방식
논블로킹: 작업을 요청하고, 결과가 올 때까지 기다리지 않고 다음 코드 실행 완료되면 콜백이나 Promise가 결과를 알려줌

Node.js는 I/O 작업(파일 읽기, 네트워크 요청 등)을 논블로킹 방식으로 처리 단일 스레드로도 수천 개 동시 요청을 처리할 수 있는 이유 이벤트 루프(Event Loop)와 함께 동작하여, 작업 완료 시 콜백 함수나 Promise를 통해 결과 처리

// setTimeout으로 확인하는 비동기 동작
console.log("첫 번째 출력");

setTimeout(() => {
  console.log("비동기 출력 (2초 후 실행)");
}, 2000);

console.log("두 번째 출력");
// 실행 순서: 첫 번째 → 두 번째 → 비동기 출력

4️⃣ ECMAScript 활용의 유연성

Node.js에서는 브라우저 호환성을 기다릴 필요 없이
새로운 ECMAScript 기능을 바로 사용할 수 있는 장점이 있습니다.

// 최신 ECMAScript 기능: optional chaining
const user = { profile: { name: "콘솔로그" } };

console.log(user?.profile?.name); // "콘솔로그"
console.log(user?.account?.email); // undefined (에러 아님)

5️⃣ 네트워킹과 서버 구축

Node.js는 네트워킹에 대한 최고 수준의 지원을 포함한 훌륭한 표준 라이브러리를 제공합니다.
그중 대표적인 것이 http 모듈이며, 이를 통해 손쉽게 웹 서버를 만들 수 있습니다.

createServer() 메서드는 새로운 HTTP 서버를 생성하고 반환합니다.

HTTP 서버를 생성한다
우리가 평소에 웹사이트를 열 때는 브라우저 주소창에 주소(URL)를 입력합니다.
그러면 브라우저는 서버에게 “이 페이지 좀 보여줘!” 하고 요청(Request)을 보내고,
서버는 그에 맞는 데이터를 찾아서 응답(Response)을 돌려줍니다.

"HTTP 서버를 생성한다"는 말은, Node.js가 브라우저의 요청을 받아주고 알맞은 답을 돌려주는 프로그램을 만든다는 뜻입니다.
쉽게 말해,
"누군가 나에게 들어오면 받아줄 준비를 하자" → 서버 열기 (server.listen())"들어온 요청을 확인하고 답장을 보내자"
→ 요청 처리 (req, res)
이 과정을 가능하게 해주는 것이 바로 http.createServer() 입니다.

// Node.js에서 가장 간단한 서버 만들기
const http = require("http");

const server = http.createServer((req, res) => {
  res.end("안녕하세요! 여기는 Node.js 서버입니다  ");
});

// 3000번 포트에서 요청을 받아줄 준비
server.listen(3000, () => {
  console.log("서버 실행 중 → http://localhost:3000");
});

위 코드를 실행한 뒤 브라우저에서 http://localhost:3000 으로 접속하면,
“안녕하세요! 여기는 Node.js 서버입니다 ” 이라는 문구가 화면에 출력됩니다.

즉, Node.js는 복잡한 설정 없이도 웹 브라우저의 요청을 받아주는 서버 역할을
아주 간단한 코드 몇 줄로 구현할 수 있는 강력한 도구입니다.

Node.js를 배우기 전에 알아두면 좋을 JavaScript 기초

Node.js를 배우기 전, JavaScript 기초를 어느 정도 알고 있는 것이 큰 도움이 됩니다.
프로그래밍 초보라면 코딩하면서 “이건 JavaScript이고, 이건 Node.js인가?” 하고 혼란스러울 수 있어요.
Node.js를 깊이 이해하려면 먼저 JavaScript의 기본 개념을 확실히 해두는 것이 좋습니다.

아래는 노드 공식 홈페이지에 나와있는 Node.js를 깊이 있게 공부하기 전에 무엇을 배우는 것이 좋을 개념들입니다.

링크도 첨부해드릴께요.

(https://nodejs.org/ko/learn/getting-started/how-much-javascript-do-you-need-to-know-to-use-nodejs)

JavaScript 기초 개념

아래 개념들을 알고 있다면, 브라우저 환경과 Node.js 환경 모두에서
원활하게 개발할 수 있는 기반을 다질 수 있습니다.

어휘 구조 & 표현: 문법과 기본 표현 방식
데이터 유형: 숫자, 문자열, 불리언, 객체 등
변수 & 상수: var, let, const
함수 & 화살표 함수: function, () => {}
this 연산자: 객체와 함수 컨텍스트 이해
루프 & 조건문: for, while, if, switch
배열과 객체: 데이터를 저장하고 조작하는 방법
템플릿 리터럴: ${}로 문자열 내 변수 사용
엄격 모드: "use strict";로 안전한 코딩
ES6 이후 문법: class, let/const, 구조 분해, 모듈 등
비동기 JavaScript 기초: 콜백, Promise, async/await

Node.js 핵심: 비동기 프로그래밍

Node.js를 이해하려면 비동기 프로그래밍에 익숙해져야 합니다.
Node.js는 요청 처리, 파일 I/O, 네트워크 작업 등에서 블로킹 없이 빠르게 처리하도록 설계되어 있기 때문입니다.

콜백 함수: 작업이 끝난 후 실행되는 함수
타이머: 일정 시간 후 실행되는 함수(setTimeout, setInterval)
Promise: 비동기 작업의 결과를 다루는 객체
async/await: 비동기 코드를 동기 코드처럼 쉽게 작성
클로저: 함수 내부에서 변수 유지
이벤트 루프: Node.js가 비동기 작업을 관리하는 핵심 구조

이러한 개념을 숙지하면, Node.js에서 발생하는 비동기 I/O, 이벤트 처리, 서버 요청 관리 등을 자연스럽게 이해할 수 있습니다.

Node.js와 브라우저의 차이점

Node.js와 브라우저는 모두 JavaScript를 사용하지만,
실제로 앱을 만들 때 경험은 크게 다릅니다.
프론트엔드 개발자 입장에서는, 프론트와 백엔드를 모두 같은 언어로 개발할 수 있다는 것이 큰 장점입니다.

Node.js를 이용하면 브라우저(JavaScript)와 서버(Node.js) 모두에서 같은 언어를 사용할 수 있어, 큰 이점을 갖게 됩니다.

차이점 1️⃣ 환경과 제공되는 API의 차이

브라우저 JavaScript
- 주로 DOM 조작, Cookies, localStorage 등 Web Platform API 사용
- document, window 같은 객체 존재
Node.js
- document, window 객체 없음
- 대신 파일 시스템 접근, 네트워크 요청, 서버 관리 등 다양한 API 제공
- 즉, 브라우저용 JavaScript와 Node.js는 실행 환경과 사용 가능한 기능이 다름

브라우저 JavaScript는 화면과 상호작용, Node.js는 서버와 시스템 제어에 특화되어 있다.

// 브라우저에서는 불가능한 예시: Node.js 파일 읽기
const fs = require("fs");

fs.readFile("example.txt", "utf8", (err, data) => {
  if (err) throw err;
  console.log(data);
});

차이점 2️⃣ 환경 제어

Node.js
- 개발자가 어떤 버전에서 실행할지 직접 결정 가능
- 최신 ES2015+ 문법을 바로 사용 가능 ✅
브라우저 JavaScript
- 사용자가 어떤 브라우저를 쓰는지 개발자가 제어할 수 없음
- 호환성을 위해 Babel 같은 트랜스파일러 사용 필요 ⚠️

Node.js는 실행 환경을 개발자가 직접 제어할 수 있어 최신 문법 사용이 자유롭다. 브라우저는 사용자 환경에 따라 제약이 생긴다.

차이점 3️⃣ 모듈 시스템

Node.js
- CommonJS(require())와 ES Modules(import) 모두 지원
- 오래된 코드와 최신 문법을 동시에 활용 가능
브라우저 JavaScript
- 최근에야 ES Modules(import) 표준이 도입됨
- require()는 사용할 수 없음
- 호환성을 위해 번들러(예: Webpack, Vite, Parcel) 사용 필요

Node.js는 다양한 모듈 방식을 지원하지만, 브라우저는 주로 최신 import만 지원하며, 구형 방식인 require()는 사용할 수 없다.

// Node.js에서는 이렇게도 가능
const fs = require("fs"); // CommonJS
import path from "path";   // ES Module

️ V8 JavaScript 엔진 완벽 정리

1. V8 JavaScript 엔진이란?

V8은 Google이 개발한 JavaScript 엔진으로,
Chrome 브라우저의 핵심 동작을 담당합니다.
역할: 우리가 작성한 JavaScript 코드를 실제로 실행하는 프로그램

2. 브라우저와 V8의 관계

브라우저에는 DOM, Cookies, Fetch API 등 다양한 Web API가 존재합니다.
하지만 V8은 오직 JavaScript 코드 실행만 담당합니다.
이 독립성 덕분에 브라우저 밖에서도 V8을 활용할 수 있었고,
바로 그 결과물이 Node.js입니다.

3. Node.js와 V8

2009년 Node.js가 만들어질 때, 엔진으로 V8이 선택됨
이후:
- Node.js의 폭발적인 성장
- 서버 사이드 JavaScript 생태계 확장
V8은 브라우저 밖에서도 동작할 수 있었기에, Node.js와 Electron 같은 플랫폼의 기반이 되었습니다.

4. 브라우저별 JavaScript 엔진

Chrome → V8
Firefox → SpiderMonkey
Safari → JavaScriptCore (Nitro)
Edge
- 과거: Chakra
- 현재: Chromium 기반 → V8 사용
그 외: 각 브라우저마다 자체 엔진 보유

5. 브라우저 엔진과 크로스 브라우징

브라우저 엔진 = 코드 실행의 핵심
- JavaScript → JS 엔진 (V8, SpiderMonkey, JavaScriptCore 등)
- HTML/CSS → 렌더링 엔진 (Blink, Gecko, WebKit 등)
문제: 엔진마다 지원 기능, 최적화 방식, 구현 시점이 다름
결과: 동일한 코드라도 브라우저마다 다르게 동작 → 크로스 브라우징 이슈 발생

예시:

Chrome(V8)에서는 async/await이 빠르게 지원 → Safari(JavaScriptCore)는 늦게 반영
CSS grid, flexbox 초창기에는 브라우저별 레이아웃 차이 발생

6. 공통점

모든 엔진은 ECMAScript(ES-262) 표준을 구현
역할: JavaScript 코드를 해석하고 실행

7. ⚡ V8의 성능과 특징

C++로 작성, 지속적 성능 개선
Mac, Windows, Linux 등 다양한 OS 지원
Node.js뿐만 아니라 Electron, 서버리스 환경, 데스크탑 앱에도 활용
Just-In-Time(JIT) 컴파일을 통해 빠른 실행 속도 제공

JavaScript 컴파일과 JIT

1. 전통적인 JavaScript 실행 방식

과거에는 인터프리터 언어로 분류 → 코드를 한 줄씩 읽고 곧바로 실행
장점: 실행이 빠르게 시작됨
단점: 실행 속도가 느리고, 최적화가 부족함

2. 현대 JavaScript 엔진의 변화

현대 엔진(V8, SpiderMonkey 등)은 단순 해석만 하지 않음
컴파일 과정을 도입해 실행 속도를 크게 개선
즉, “인터프리터 + 컴파일러 혼합 구조”

3. JIT(Just-In-Time) 컴파일

정의: 프로그램 실행 도중, 필요한 시점(Just In Time)에 기계어로 컴파일
특징:
- 자주 실행되는 코드는 최적화된 기계어로 변환
- 불필요한 코드는 굳이 컴파일하지 않아 효율적
결과: 브라우저에서도 네이티브 애플리케이션 수준 성능 제공

4. JIT 덕분에 가능한 것들

브라우저에서 수 시간 동안 실행되는 복잡한 앱도 원활히 동작
예: 게임, IDE, 영상 편집기 같은 고성능 웹 애플리케이션
서버 사이드(Node.js)에서도 빠른 실행 환경 제공

첫 번째 호출즉, “필요할 때 바로 번역해서 실행”하는 방식 → Just-In-Time

코드가 처음 실행될 때는 인터프리터처럼 한 줄씩 실행

반복적으로 실행되는 함수나 코드 블록을 동적으로 최적화하여 기계어로 변환

변환된 기계어 코드로 빠르게 반복 실행 가능

예시)
function sumUpTo(n) {
  let total = 0;
  for (let i = 1; i <= n; i++) {
    total += i;
  }
  return total;
}

// 반복 호출
console.log(sumUpTo(1000000));
console.log(sumUpTo(1000000));
console.log(sumUpTo(1000000));
첫 번째 호출
console.log(sumUpTo(1000000)); 은

엔진이 함수 코드를 인터프리터처럼 한 줄씩 실행

아직 최적화되지 않았기 때문에 약간 느릴 수 있음

두 번째, 세 번째 호출

엔진이 “이 함수 반복 실행되네?” 판단

동적으로 최적화된 기계어 코드로 변환

이미 최적화된 코드로 실행 → 훨씬 빠름

Node.js와 JIT의 관계

1. Node.js는 V8 위에서 동작한다

Node.js 자체에는 JavaScript 실행 엔진이 없음
대신 Google V8 엔진을 기반으로 동작
즉, Node.js = (V8 + Node 전용 API + 런타임) 구조

2. V8의 JIT 최적화 → Node.js 성능

V8이 JIT을 사용해 코드를 기계어로 컴파일하기 때문에
- 파일 처리, 네트워크 요청 같은 서버 로직도 빠르게 실행 가능
Node.js가 싱글 스레드 + 이벤트 루프 구조임에도
수많은 요청을 감당할 수 있는 배경에는 V8 JIT의 성능 덕분이 큼

3. JIT이 없다면?

단순 인터프리터였다면 → Node.js는 고성능 서버 환경에서 경쟁력이 부족했을 것
하지만 JIT 덕분에 JavaScript = 느리다라는 고정관념을 깨고,
서버 사이드 개발에도 쓰일 수 있게 됨

4. 실제 영향

Node.js가 API 서버, 채팅 서버, 실시간 스트리밍, 마이크로서비스 등에 활용 가능한 건
V8의 JIT 성능 덕분
또, JIT 최적화가 계속 발전하면서 → Node.js도 버전이 올라갈수록 속도 개선 효과를 함께 누림

프론트엔드 개발자가 Node.js를 배우면서 V8의 동작 원리를 이해하면,

성능 최적화와 비동기 처리를 더 잘 이해할 수 있는 큰 장점이 됩니다.

Node.js: 개발 환경(Development)과 운영 환경(Production)의 차이

Node.js 자체는 개발 환경과 운영 환경 간에 특별한 설정 차이가 없습니다.
즉, Node.js는 개발 환경에서 실행하든 운영 환경에서 실행하든 기본 동작은 동일하며, 바로 프로덕션 환경에서도 실행할 수 있습니다.

하지만 일부 npm 라이브러리는 NODE_ENV 환경 변수를 참고하여 기본값을 development로 두고, 개발용 기능과 운영용 기능을 구분해 동작합니다.
따라서 운영 환경에서 Node.js 애플리케이션을 실행할 때는, 라이브러리 최적화와 성능 확보를 위해

NODE_ENV=production 을 명시적으로 설정하는 것이 좋습니다.

하지만 여기서 한 가지 주의할 점이 있습니다.
바로 NODE_ENV를 개발용 코드 분기나 조건문에 남용할 경우 발생할 수 있는 문제입니다.

운영 환경에서 단순히 NODE_ENV만을 기준으로 기능을 켜고 끄면, 테스트 신뢰성이나 코드 안정성에 예상치 못한 영향을 줄 수 있습니다.

즉, 이제부터는 NODE_ENV를 사용할 때 발생할 수 있는 위험과 올바른 활용법을 살펴보겠습니다.

보통 프로젝트에서는 두 가지 방식으로 개발 환경과 운영 환경을 구분합니다.

1️⃣ .env 파일에서 상수를 정의하여 환경별 설정값을 관리하는 경우
2️⃣ NODE_ENV를 활용하여 코드 자체에서 실행 환경을 나누고, 개발용 코드와 운영용 코드를 분기하는 경우

NODE_ENV와 안티패턴

앞서 살펴본 것처럼, NODE_ENV는 코드 실행/포함 분기와 라이브러리 최적화를 위해 사용됩니다.
하지만 NODE_ENV를 남용하면 안티패턴(Anti-pattern)이 될 수 있습니다.

왜 안티패턴이 될까?

개발용 코드와 운영용 코드가 NODE_ENV 조건문에 직접 의존하면, 환경별 테스트 신뢰성이 떨어집니다.

if (process.env.NODE_ENV === 'development') {
  // 개발용 기능
}
if (process.env.NODE_ENV === 'production') {
  // 운영용 기능
}

이런 방식은 운영 환경에서 기능이 제대로 동작하는지 테스트하기 어렵고, 코드 유지보수 시 혼동을 줄 수 있습니다.

권장 방식

환경별 값은 .env 파일로 분리 → Configuration 관리
개발용 코드/디버깅 코드는 NODE_ENV로 분기 → Behavior & Optimization 관리
핵심 비즈니스 로직은 NODE_ENV에 의존하지 않고 기능 플래그나 설정값으로 제어

요약:

.env → 값/설정 분기

NODE_ENV → 코드 실행/최적화 분기

NODE_ENV를 코드 로직 분기용으로 남용 X → 안티패턴

단순 디버거용 코드를 개발기에서만 해보고 싶을 경우,

단순 디버그용 코드나 오류 검사용 코드는

.env 상수보다 process.env.NODE_ENV === 'development'로 분기하는 게 낫다고 합니다.

번들 최적화 가능

개발용 로그나 DevTools 초기화 코드를 NODE_ENV 조건문으로 감싸면,
운영 빌드(NODE_ENV=production) 시 Webpack 등 번들러가 코드를 아예 제거합니다.
.env 상수로 DEBUG=true/false를 쓰면 런타임에서 조건문을 평가하게 되어, 코드 자체는 번들에 남아 있어 최적화가 제한됩니다.

// 권장: NODE_ENV 분기
if (process.env.NODE_ENV === 'development') {
  console.log("개발용 로그"); // 운영 빌드에서 제거 가능
}

// 비권장: .env 상수
if (config.debug) {
  console.log("개발용 로그"); // 운영 빌드에 남음
}

운영 환경 안전

NODE_ENV 분기는 환경 자체를 기준으로 하므로, 운영 환경에서는 절대 실행되지 않음
반대로 .env 상수는 설정 실수로 DEBUG=true가 운영 환경에서도 적용될 수 있음

관습적/표준적 사용

대부분의 라이브러리와 프레임워크가 개발/운영 분기를 NODE_ENV 기준으로 최적화
React, Vue, Express 등에서 NODE_ENV 조건 분기 사용 예제 다수

그럼 만약 신규 기능 로직 등을 개발기 환경에만 적용하고 싶은경우는?

상황에 맞게 적절히 선택하거나 필요에 따라 같이 사용하는 것이 안전하고 실무에서 권장되는 방법.

만약, NODE_ENV만 쓰는 경우

✅ 장점: 운영 환경에서 절대 실행되지 않음
❌ 단점: 기능이 개발용인지 운영용인지 판단하기 어렵고, 기능 켜고 끄는 세밀한 제어가 힘듦

if (process.env.NODE_ENV === 'development') {
  newFeature(); // 개발 환경에서만 실행
}

기능 플래그를 활용하는 경우 (권장)

✅ 장점:

개발 환경에서 기능을 자유롭게 테스트 가능
운영 환경에서는 절대 실행되지 않아 안정성 확보
배포 준비 시 플래그만 변경하면 바로 운영 적용 가능

//.env.development
FEATURE_NEW=true

//.env.production
FEATURE_NEW=false

// config.js
export const config = {
  newDashboard: process.env.FEATURE_NEW_DASHBOARD === 'true',
};

import { config } from './config.js';

if (config.newDashboard) {
  newFeature(); // 개발 환경에서만 실행, 운영 환경에서는 실행되지 않음
}

NODE_ENV로 라이브러리 성능 최적화 및 운영용 번들 생성

NODE_ENV는 라이브러리와 프레임워크의 최적화 동작에 직접적인 영향을 줍니다.

Node.js와 프론트엔드 프로젝트를 운영할 때,

NODE_ENV는 라이브러리와 프레임워크가 개발용 기능과 운영용 기능을 구분하도록 하는 핵심입니다.
하지만 코드 분기를 위한 용도가 아니라, 라이브러리 내부 동작을 최적화할 때도 사용됩니다.

이 설정 하나만으로 실제 성능과 번들 크기에도 큰 영향을 줄 수 있습니다.

NODE_ENV가 성능 최적화에 좋은 이유

1️⃣ 개발용 코드와 운영용 코드를 분리 가능

라이브러리나 프레임워크는 NODE_ENV 값에 따라 개발용 기능과 운영용 기능을 다르게 동작하도록 설계되어 있습니다.
예시: React
- NODE_ENV=development → 디버그용 경고 메시지, PropTypes 검증, 상세 오류 메시지 출력
- NODE_ENV=production → 디버그 메시지 제거, PropTypes 검증 비활성화 → 번들 크기 축소, 실행 속도 향상

2️⃣ 불필요한 코드 제거 (Tree-shaking 가능)

번들러(Webpack, Vite 등)는 process.env.NODE_ENV 조건문을 보고 개발 전용 코드를 운영 빌드에서 제거합니다.
결과: 번들 크기 축소, 로딩 속도 향상, 불필요한 코드 제거

3️⃣ 환경별 최적화 자동 적용

라이브러리들은 운영 환경에서는 불필요한 연산이나 체크를 비활성화하고, 개발 환경에서는 디버깅과 안전성을 강화합니다.
즉, 개발 시 편리함을 유지하면서 운영에서는 성능을 극대화할 수 있습니다.

4️⃣ 안정적 배포 지원

운영 환경에서는 항상 NODE_ENV=production을 설정하여 라이브러리가 최적화된 상태로 실행되도록 강제할 수 있습니다.
이로 인해 예측 가능한 성능과 일관된 동작 보장

운영용 번들 생성 (Production Build)

프론트엔드 개발에서는 개발 환경과 운영 환경에서 필요한 코드와 설정이 다릅니다.
운영 환경에서는 최적화된 번들을 만들어 배포하는 것이 중요합니다.

1️⃣ 운영 번들이 필요한 이유

개발 환경에서는 디버그용 로그, PropTypes, 상세 오류 메시지 등 디버깅용 코드가 포함됩니다.
이런 코드는 운영 환경에서는 불필요하며, 그대로 두면 번들 크기가 커지고 실행 속도가 느려집니다.
따라서 개발용 코드 제거, 압축, 최적화를 거쳐야 성능이 향상됩니다.

2️⃣ NODE_ENV 활용

번들을 생성할 때 NODE_ENV=production을 설정하면, 라이브러리와 프레임워크가 운영 환경 최적화 모드로 동작합니다.
운영 환경 최적화 모드(Production Mode)란?
운영 환경 최적화 모드는 말 그대로 배포된 서비스에서 성능을 최대한 끌어올리기 위해 라이브러리와 번들이 동작하는 방식을 뜻합니다. 프론트엔드 라이브러리(예: React, Vue)나 Node.js 패키지들은 개발 환경과 운영 환경에서 다른 동작을 하도록 설계되어 있습니다.

이제 어느 정도 node.js에 대해 알아보았으니 npm 에 대해서 알아볼께요.

npm의 기본 역할

패키지 관리: 프로젝트에서 필요한 라이브러리, 모듈, 프레임워크를 설치하고 버전을 관리
프로젝트 실행 환경 구성: npm install 한 번이면 수많은 라이브러리를 설치하고 프로젝트가 실행 가능한 상태로 세팅
스크립트 관리: package.json에 등록한 명령어(npm run build, npm start) 실행

npm의 주요 기능

패키지 저장소(레지스트리)
- 수많은 오픈소스 자바스크립트 패키지가 등록된 온라인 데이터베이스
- 필요한 기능을 검색하고 다운로드하여 프로젝트에 바로 활용 가능
명령줄 인터페이스(CLI)
- npm install [패키지 이름], npm update, npm uninstall 등 명령어를 통해 패키지를 쉽게 설치, 업데이트, 삭제
- 터미널에서 바로 프로젝트에 패키지를 추가하거나 관리
의존성 관리
- 프로젝트에 필요한 패키지 목록과 버전을 package.json 파일에 기록
- 다른 개발자와 협업하거나 프로젝트 배포 시 의존성을 손쉽게 관리

npm과 Node.js의 관계

Node.js: JavaScript 런타임, 서버 사이드 코드를 실행
npm: Node.js 프로젝트에서 필요한 라이브러리를 쉽게 설치하고 관리하는 도구
즉, npm 없이는 Node.js 기반 프로젝트의 라이브러리 의존성을 관리하기 어렵습니다.

npm을 사용하는 이유

개발 시간 단축: 이미 만들어진 패키지를 활용해 복잡한 기능을 쉽게 구현
관리 효율성 향상: 여러 패키지를 package.json 하나로 통합 관리 가능
생태계 공유: 전 세계 개발자들이 패키지를 공유하는 오픈소스 생태계의 중심

npm 주요 명령어

⚡ 패키지 설치

npm install <패키지>
→ 특정 패키지를 설치하고 node_modules에 저장
npm install
→ package.json에 정의된 모든 의존성 설치
npm install <패키지> --save-dev
→ 개발용 패키지 설치 (devDependencies)
npm install -g <패키지>
→ 글로벌 설치, 터미널 어디서든 사용 가능
npx <패키지>
→ 설치 없이 바로 실행 가능

패키지 제거 및 업데이트

npm uninstall <패키지>
→ 설치된 패키지 제거
npm update <패키지>
→ 특정 패키지를 최신 버전으로 업데이트
npm outdated
→ 설치된 패키지 버전과 최신 버전 확인

프로젝트 초기화

npm init
→ 프로젝트 초기화, package.json 생성
npm init -y
→ 기본값으로 빠르게 초기화

패키지 정보 조회

npm view <패키지>
→ 패키지 정보 조회 (버전, 의존성 등)
npm list
→ 설치된 패키지 트리 확인
npm list -g --depth=0
→ 글로벌 설치 패키지 확인

스크립트 실행

npm run <스크립트명>
→ package.json의 scripts 실행
npm start
→ 앱 시작용 스크립트 실행 (npm run start)
npm test
→ 테스트 스크립트 실행 (npm run test)
npm build
→ 빌드 스크립트 실행 (npm run build)

패키지 캐시 관리

npm cache clean --force
→ npm 캐시 초기화
npm cache verify
→ 캐시 무결성 검증

[개발읽기 vol.9] 클라우드 아키텍처 진화: 모놀리식에서 MSA까지 완벽 정리

콘솔로그 — Tue, 16 Sep 2025 14:46:19 +0900

요즘 Yarn Berry랑 pnpm을 공부하다 보니까, 자연스럽게 모노레포(Monorepo)라는 개념을 알게 되었어요.

처음에는 단순히 패키지 관리나 프로젝트 구조를 조금 더 효율적으로 만드는 방법 정도로만 생각했는데, 조금 더 깊이 공부해보니 이게 프로젝트 구조뿐만 아니라 전체 아키텍처와도 연결돼 있다는 걸 깨달았죠.

모노레포에서 시작해서 점점 서비스 지향 아키텍처(SOA), 그리고 MSA(마이크로서비스 아키텍처)까지 아키텍처가 진화하는 과정을 보면서, 단순한 코드 관리 이상의 의미가 있다는 걸 알게 되었어요.

특히 저희 회사도 이미 MSA 구조를 쓰고 있어서, "MSA가 뭔지 모르고 쓰는 건 안 되겠다"는 생각이 들었습니다.

단순히 백엔드 개발자만 아는 지식이 아니라, 프론트 개발자에게도 꼭 필요한 내용이라는 점이죠.

공부를 이어가면서 서비스별 독립 배포, API 호출 구조, 장애 대응 방식 같은 MSA 요소들을 이해하면, 프론트 개발에서도 훨씬 효율적이고 안정적으로 구현할 수 있다는 걸 깨달았죠.

결국 단순히 패키지를 설치하고 프로젝트를 관리하는 단계에서 시작했지만, 점점 클라우드 아키텍처와 MSA의 중요성을 몸소 체감하게 되었습니다.

그래서 이번 글에서는 모노레포부터 MSA까지 아키텍처가 어떻게 진화했는지, 그리고 각각의 구조가 갖는 의미와 장단점을 쉽게 정리해보려고 합니다.

읽으시는 분들께도 도움이 되었으면 좋겠어요.

프론트엔드인데 왜 클라우드 아키텍처를 알아야할까?

1️⃣ 배포와 운영 이해

프론트엔드도 서버/클라우드 환경에서 돌아가는 경우가 많습니다.
정적 파일(HTML, JS, CSS)을 클라우드에 배포할 때, CDN, 서버, 스토리지 구조를 이해하면 문제 해결과 최적화가 쉬워집니다.
예: AWS S3 + CloudFront로 빠른 페이지 로딩, 트래픽 폭주 대응

2️⃣ MSA와 API 구조 이해

현대 클라우드 환경에서 백엔드는 대부분 MSA로 구성되어 있습니다.
프론트엔드는 여러 마이크로서비스 API를 호출하게 되는데,
- 서비스별 엔드포인트 구조
- 인증/권한 처리
- 장애 처리 및 fallback 로직
  이런 것을 이해하면 효율적 프론트 개발이 가능해집니다.

3️⃣ 확장성과 성능 최적화

클라우드 아키텍처를 이해하면, 프론트 성능 최적화가 더 쉬워집니다.
예:
- 이미지/동영상 CDN 배포
- 서버리스 함수와 연동한 프론트 로직
- Lazy loading, API throttling

4️⃣ DevOps, CI/CD와 연계

프론트엔드도 요즘은 자동 빌드/배포(CI/CD) 환경에서 돌아갑니다.
클라우드 아키텍처를 이해하면:
- 배포 파이프라인 설계
- 환경별 설정 관리(dev/stage/prod)
- 에러 추적 및 모니터링
  이런 작업을 더 능숙하게 할 수 있습니다.

5️⃣ 비즈니스와 팀 협업 이해

클라우드 아키텍처를 이해하면:
- 백엔드, DevOps, 인프라 팀과 원활한 협업 가능
- “왜 이 API가 느린지?”, “왜 배포가 오래 걸리는지” 이해 가능
결과적으로 프론트엔드 개발자로서 서비스 전체를 이해하는 시야가 생깁니다.

프론트엔드 개발자에게 클라우드 아키텍처 지식은 단순히 서버 지식이 아니라,

API 구조 이해
배포와 성능 최적화
팀 협업과 서비스 운영 능력

를 높여주는 필수 역량입니다.

클라우드 아키텍처란?

클라우드 아키텍처(Cloud Architecture)는 인터넷 위에서 서비스가 어떻게 작동할지를 설계하는 방법을 말합니다.

쉽게 말하면, 누군가 웹사이트에 접속했을 때 페이지가 잘 뜨고, 버튼을 클릭하면 원하는 기능이 실행되며, 데이터가 저장되거나 불러와지도록 앱이나 서비스를 서버, 저장 공간, 네트워크 등에 배치하고 미리 계획한 전체 구조를 말합니다.

핵심 개념

클라우드 운영 방식은 총 2가지로 나뉩니다.

서버리스(Serverless) 방식과 서버 기반(Server-based) 방식 두가지가 있습니다.

클라우드 설계의 핵심 특징에는

분산 구조(Distributed) : 여러 서버와 서비스가 서로 통신하며 동작하여 장애가 발생해도 전체 서비스가 멈추지 않도록 설계함

확장성(Scalability): 사용자가 늘어나면 자동으로 서버나 리소스를 늘림 → 클라우드의 큰 장점

클라우드 설계를 잘해야 사람들이 편리하게 이동하고, 필요할 때 방을 늘리거나 줄일 수 있는 것처럼, 클라우드 아키텍처도 효율적인 서비스 운영을 위해 꼭 필요합니다.

클라우드 구조 핵심 요소

서버(Server) : 실제 애플리케이션을 실행하고 데이터를 처리하는 공간.
네트워크(Network) : 서버, 스토리지, 사용자를 연결하여 데이터와 요청을 전달.
스토리지(Storage) : 데이터를 저장하고 필요할 때 불러오는 공간.
애플리케이션(Application) : 사용자가 실제로 이용하는 기능과 서비스.
로드밸런서(Load Balancer) : 여러 서버에 트래픽을 분산하여 과부하를 방지.
자동 확장(Auto Scaling) : 사용량 변화에 따라 서버 수를 자동으로 늘리거나 줄임.
보안(Security) : 데이터와 서비스 보호, 접근 통제.
클라우드 서비스 계층
- IaaS(인프라): 서버, 스토리지, 네트워크를 직접 구성
- PaaS(플랫폼): 애플리케이션 실행 환경 제공, 서버 관리 불필요
- SaaS(서비스): 최종 사용자에게 바로 제공되는 애플리케이션

클라우드 아키텍처의 진화: 모놀리식에서 MSA까지

클라우드 환경에서 애플리케이션 아키텍처는 끊임없이 발전해 왔습니다. 오늘은 전통적인 모놀리식(Monolithic) 아키텍처부터, 서비스 지향 아키텍처(SOA), 그리고 최신 마이크로서비스 아키텍처(MSA)까지 그 흐름과 특징을 정리해보겠습니다.

모놀리식(Monolithic) 아키텍처

모놀리식은 모든 기능을 하나의 애플리케이션에 통합한 구조입니다.

초기 개발이 간단하고 배포가 단일 단위라 관리가 쉽지만, 서비스가 커질수록 유지보수가 어려워집니다.

저장소: 일반적으로 하나의 저장소에서 모든 기능 관리 / 작은 프로젝트나 전통적 구조에서는 자연스럽게 하나의 저장소
배포: 전체 앱 단위
팀 협업: 작은 팀에 적합, 동시에 여러 기능 개발 시 충돌 가능
특징: 코드 통합, 배포 단순, 작은 변경에도 전체 배포 필요

[모놀리식 앱]
 ├── 사용자 관리
 ├── 주문 관리
 ├── 결제 관리
 └── 상품 관리
 
프로젝트 구조 (Git 저장소: 1개)
/app
  /login
  /board
  /payment
  /user
server.js

1️⃣ 단일 빌드 & 배포

프론트엔드가 백엔드와 함께 한 번에 배포됨
(보통 프론트엔드 코드와 백엔드 코드가 같은 프로젝트/깃 저장소 안에 존재하는 경우가 많음.)
개발자가 서버를 빌드하면 프론트와 백엔드가 동시에 묶여서 배포.
예를 들어, Spring Boot 서버 안에 /static 폴더로 프론트 빌드 결과물이 들어가고, 서버를 띄우면 동시에 프론트와 백엔드가 동작하는 구조입니다.
장점: 배포가 간단하고 버전 관리 용이
단점: 작은 변경에도 전체 애플리케이션을 다시 배포해야 함

2️⃣ 코드 구조

프론트엔드와 백엔드 코드가 통합되어 있음
장점: 작은 프로젝트에서는 구조가 단순하고 이해하기 쉬움
단점: 프로젝트가 커지면 코드 의존성이 많아 유지보수가 어려움

3️⃣ 성능 및 확장

특정 페이지만 독립적으로 최적화하거나 확장하기 어려움
프론트 성능 최적화(예: lazy loading, CDN 활용) 제한적

4️⃣ 팀 협업

동일 코드베이스 공유로 충돌 발생 가능
기능 추가 시 전체 시스템 테스트 필요

✅ 요약

초기 개발 속도가 빠르고 SSR 같은 전통적 구조와 연동 쉬움
코드가 커지면 모듈화 어려움, 배포 주기가 길고 SPA 등 최신 프론트와 결합 시 확장성 제한
단일 애플리케이션이므로 한 기능 수정 시 전체를 배포해야 하는 위험도 존재합니다.

서비스 지향 아키텍처(SOA)

SOA는 기능 단위로 서비스를 나누고, 서비스 간 메시지나 API로 통신하는 구조입니다. 재사용성이 높고 대규모 시스템에 적합하지만, 서비스 간 통신 구조가 복잡해져 유지보수가 쉽지 않습니다. 클라우드 환경에서 SOA는 확장성과 재사용성을 위한 첫 단계로 볼 수 있습니다.

저장소: 저장소는 하나로 관리할 수도 있고, 서비스별로 나눌 수도 있음
배포: 통합 배포 가능 (전체 서버 기준)
팀 협업: 서비스별 개발 가능, 병렬 작업 가능
특징: 기능 단위로 분리, 배포는 아직 전체 단위, 서비스 간 의존 존재

SOA는 서비스 단위로 나누지만 배포는 통합될 수 있는 구조.

중요한 건 서비스가 논리적으로 독립적이라는 점이지, Git 저장소 수는 필수 조건이 아님.

[SOA]
 ├── 사용자 서비스 ↔ 주문 서비스
 ├── 결제 서비스 ↔ 상품 서비스
 
프로젝트 구조
/monorepo (Git 저장소 1개 가능)
  /auth-service
  /board-service
  /payment-service
/frontend
server.js (전체 배포)

1️⃣ 서비스 단위 호출

프론트엔드는 단일 백엔드가 아니라 여러 서비스 API 호출 (서비스 단위 ≠ 서버 단위)

이 서비스는 반드시 서버가 분리된다는 뜻이 아니라, API/모듈 단위로 독립적이라는 의미예요.

예: 사용자 관리, 주문 처리, 결제 기능이 각각 서비스라고 하면,

같은 서버 안에서 독립 모듈로 구현할 수도 있고
실제로 다른 서버로 나눌 수도 있습니다.
장점: 필요한 기능만 호출 가능, 백엔드 변경이 프론트에 덜 영향

** 단일 백엔드란?

모놀리식 구조에서는 보통 프론트엔드가 요청을 보내는 서버가 하나입니다.

예를 들어, 쇼핑몰 앱이 있다고 할 때: 사용자 로그인, 상품 조회, 주문, 결제 기능이 하나의 서버에서 모두 처리됨

그래서 프론트는 항상 이 서버에 요청만 하면 모든 기능을 사용할 수 있습니다.

즉, 단일 백엔드 = 프론트가 호출하는 서버가 한 곳뿐이라는 의미예요.

2️⃣ 독립적 개발 가능

각 서비스가 독립적이므로 팀이 병렬 개발 가능
장점: 기능 추가/수정 시 전체 시스템 영향을 최소화

예시: 쇼핑몰 서비스 개발

서비스 단위 분리
- 사용자 서비스: 회원가입, 로그인, 프로필 관리
- 주문 서비스: 상품 주문, 장바구니
- 결제 서비스: 결제 처리, 결제 내역 확인
팀 구성
- A팀 → 사용자 서비스 개발
- B팀 → 주문 서비스 개발
- C팀 → 결제 서비스 개발

3️⃣ 통신 구조 이해 필요

프론트는 서비스별 엔드포인트, 인증/권한, 에러 처리를 이해해야 함
인증/권한은 모놀리식에서도 필요했지만,
- SOA에서는 서비스가 분리되면서 각 서비스가 독립적으로 인증/권한을 체크할 수 있음
- 따라서 프론트는 서비스별로 올바른 토큰·권한 정보를 전달해야 함
- 인증/권한 처리 로직이 분산되므로 관리가 더 까다로움
서비스 간 의존성은 낮지만, 네트워크 지연·장애 상황까지 고려해야 함

4️⃣ 코드 구조

API 호출 많아짐 → API 관리 모듈, 상태 관리(store/context) 설계 필요
장점: 코드 모듈화 가능
단점: 서비스 수가 많아지면 관리 부담 증가

✅ 장점

대규모 시스템에서도 유연한 확장 가능
API 테스트와 프론트 개발 병행 가능
MSA 이전, 서비스 단위 사고에 익숙해짐

✅ 단점

서비스별 API 호출 증가 → 네트워크 비용 상승
서비스 상태 통합 관리 필요
초기 설계가 복잡, 러닝 커브 존재

마이크로서비스 아키텍처(MSA)

MSA는 작은 단위의 서비스로 애플리케이션을 분리하고, 각 서비스는 독립적으로 배포됩니다. 컨테이너(Docker)와 오케스트레이션(Kubernetes)와 같은 클라우드 기술과 결합하면 빠른 배포와 유연한 확장이 가능합니다.

MSA는 개발 효율성, 안정성, 비용 최적화를 동시에 잡을 수 있지만, 서비스 간 통신과 데이터 관리, 모니터링 체계가 필수적입니다.

저장소: 서비스별 독립. 보통 서비스별 저장소를 가지는 경우가 많음
배포: 서비스 단위 완전 독립
팀 협업: 서비스 단위 담당 → 팀별 배포 가능
특징: 독립적 배포, 확장성 뛰어남, 장애 영향 최소화

MSA는 서비스 단위가 완전히 독립적 배포를 전제로 함.

그러나 기술적으로는 하나의 저장소(monorepo)에서도 MSA처럼 독립 서비스 개발 가능 → 단지 배포와 관리가 복잡해짐

[MSA]
 ├── 사용자 서비스 → 독립 컨테이너
 ├── 주문 서비스 → 독립 컨테이너
 ├── 결제 서비스 → 독립 컨테이너
 └── 상품 서비스 → 독립 컨테이너
 
 
프로젝트 구조 (Git 저장소 서비스별 독립)
auth-service/  (Git repo A)
board-service/  (Git repo B)
payment-service/  (Git repo C)
frontend/      (Git repo D)

1️⃣ 독립적 배포

서비스별 API 호출을 통해 기능 구성
특정 서비스 업데이트가 다른 서비스에 영향 없음
✅ 작은 변경도 개별 배포 가능 → 배포 주기 단축

2️⃣ API 중심 개발

프론트는 서비스별 API 계약(API contract)에 맞춰 개발
인증/권한 처리, 에러 핸들링, fallback 로직 고려 필요
✅ 서비스 단위 테스트 및 유지보수 효율 ↑

3️⃣ 성능 최적화·확장 용이

필요한 서비스만 스케일 업/다운 가능
CDN, 서버리스 함수, lazy loading 활용 쉬움

4️⃣ 팀 협업·개발 효율

프론트/백엔드 팀이 독립 작업 가능
소규모 팀 단위 담당 → 개발 속도 ↑
장애 발생 시 특정 서비스만 대응 가능

✅ 장점

빠른 개발·배포
서비스 단위 유지보수·테스트 용이
클라우드 환경에서 최적화·확장성 확보

✅ 단점

서비스 수 증가 → API 호출·상태 관리 복잡
네트워크 지연·장애 처리 로직 필요
초기 설계, 모니터링·로깅 체계 구축 필수

핵심 포인트: 저장소 수는 아키텍처를 결정하는 필수 조건이 아니고, 배포 독립성과 서비스 독립성이 핵심이에요.

요즘 흔한 조합

SPA (React/Vue) + 백엔드 MSA + 경우에 따라 Micro Frontend 적용

** Micro Frontends(마이크로 프론트엔드, MFE)

화면을 여러 팀/서비스 단위로 쪼개서 독립 배포
예) 쿠팡 메인 페이지의 "배너 영역", "추천 상품", "장바구니"가 각각 다른 팀에서 독립 개발/배포

https://medium.com/@isuruariyarathna2k00/a-deep-dive-into-micro-frontend-architecture-with-react-js-264ca6edca6b

A Deep Dive into Micro Frontend Architecture with React.js

Discover the power of Micro Frontend Architecture in React.js! Learn how to build modular and scalable web applications in our latest blog.

medium.com

MSA를 사용하는 기업들

넷플릭스 (Netflix)

넷플릭스는 원래 모놀리식에서 시작했지만, 트래픽 급증과 기능 복잡성 증가로 인해 마이크로서비스 아키텍처로 전환함.

각 기능(예: 계정관리, 스트리밍, 추천, 사용자 프로필 등)이 독립적 서비스로 분리됨.
장애 격리 (하나의 서비스 장애가 전체 서비스에 미치는 영향 줄임)
AWS 같은 클라우드 인프라를 활용해서 수평 확장 및 로드 밸런싱, 콘텐츠 전송망(CDN) 등을 운용함.
“Chaos Monkey”라는 장애 테스트 도구 등을 통해 내결함성(resilience) 확보 노하우 있음.

https://newsletter.systemdesign.one/p/netflix-microservices?utm_source=chatgpt.com

Microservices Lessons From Netflix

#19: Check This Out - Awesome Microservices Guide (5 minutes)

newsletter.systemdesign.one

https://www.techaheadcorp.com/blog/design-of-microservices-architecture-at-netflix/?utm_source=chatgpt.com

쿠팡

쿠팡은 2013년에 모놀리식 아키텍처로 구성된 서비스를 마이크로서비스 아키텍쳐(Microservices Architecture, MSA)로 전환하는 프로젝트를 진행하였습니다.

아래 링크는 이러한 전환을 위해 쿠팡이 취한 전략이 무엇이고, 그 과정에서 나타난 문제를 어떻게 풀어나갔는지 소개하는 페이지 입니다.

https://medium.com/coupang-engineering/how-coupang-built-a-microservice-architecture-fd584fff7f2b

마이크로서비스 아키텍처로의 전환

행복을 찾기 위한 쿠팡 엔지니어링의 여정, 마이크로서비스 구현하기 — Part 1

medium.com

토스

토스 역시 Django 기반 모놀리식 프로젝트 안에서 React를 통한 Micro Frontend를 점진적으로 도입하였다고 합니다. 오래된 코드 베이스를 대대적으로 수정하는 것보다 “필요한 부분만 조금씩 분리”하는 방식으로 접근하였다고 합니다.

아래 링크는 이러한 전환을 위해 토스가 취한 전략이 무엇이고, 그 과정을 소개하는 페이지 입니다.

https://toss.im/slash-21/sessions/2-5?utm_source=chatgpt.com

Micro-frontend React, 점진적으로 도입하기

거대한 모놀리식 Django 프로젝트에 현대적인 프론트엔드 인프라를 구축한 사례를 공유합니다. 어떻게 해야 오래된 코드 베이스를 대대적으로 수정하지 않으면서도, 최신 프론트엔드 기술들을

toss.im

주요 인사이트 (우리 글에 넣으면 좋은 것들)

쿠팡은 모놀리식 → MSA 전환 과정에서 한 리포지토리(monorepo 비슷한 구조)였고, 기능별 컴포넌트들을 같은 저장소 안에서 관리했었다는 점. Medium
토스는 Micro Frontend를 도입하면서 전체를 한꺼번에 갈아엎기보다는 점진적인 분리를 택했다는 점. 필요 기능만 골라서 현대화/분리함. 토스
조직 구조(팀/사일로)도 아키텍처 영향을 많이 준다는 사례. 기능 책임 팀 ≒ 해당 기능의 프론트 + 백이 같이 움직이면 분리/독립이 더 쉬워짐. 토스 Frontend 챕터 글에서 이런 조직 구조가 보고됨. 토스 테크

프론트엔드 관점에서 본 아키텍처

아키텍처 이야기는 보통 백엔드 개발자나 인프라 팀의 영역이라고 생각하기 쉽지만, 프론트엔드 개발자에게도 큰 영향을 줍니다. 왜냐하면 서비스를 어떻게 나누고, 어떻게 배포하고, 어떤 방식으로 확장하느냐에 따라 프론트 코드도 달라지기 때문이죠.

1️⃣ API 호출 방식의 변화

모놀리식: 하나의 백엔드 서버에서 API를 제공하므로, 프론트에서는 단일 엔드포인트만 호출하면 됐습니다.
SOA/ MSA: 서비스가 여러 개로 나뉘면서, 프론트는 다양한 엔드포인트를 호출해야 합니다.
- 인증/인가 처리가 서비스별로 다를 수 있음
- 서비스 간 장애 발생 시 fallback 로직 필요
  따라서 프론트 개발자는 단순히 fetch를 넘어서 API Gateway, BFF(Backend for Frontend) 같은 개념을 이해해야 효율적으로 개발할 수 있습니다.

2️⃣ 배포 파이프라인의 변화

프론트엔드도 CI/CD 환경에서 자동 빌드 & 자동 배포가 기본이 되었습니다.
환경(dev/stage/prod)별 설정 분리, API 주소 변경, feature flag 처리 등을 아키텍처 수준에서 고려해야 합니다.
클라우드 환경에 맞춘 배포 파이프라인을 이해하면, 백엔드/인프라 팀과 협업이 훨씬 수월해집니다.

3️⃣ 성능 최적화 & 장애 대응

MSA 환경에서는 네트워크 호출이 많아져서 지연(latency)이 커질 수 있습니다.
프론트 차원에서 API 호출 최적화, 캐싱 전략, Lazy loading 같은 패턴이 필요합니다.
특정 서비스가 장애가 나더라도 전체 화면이 죽지 않도록 fallback UI를 준비하는 것도 중요합니다.

Micro Frontend 소개 (확장 개념)

MSA가 백엔드를 쪼갠 것처럼, 프론트엔드도 커지다 보면 독립적으로 나눠야 할 필요가 생깁니다.
이를 Micro Frontend라고 부릅니다.

필요성
- 대규모 SPA에서 빌드/배포 시간이 길어지고, 팀 간 충돌이 생길 때
- 기능별로 독립 배포가 필요할 때
장점
- 팀 단위로 독립 배포 가능 → 특정 기능만 수정/배포 가능
- 서비스별로 기술 스택을 다르게 가져갈 수도 있음 (예: 일부 React, 일부 Vue)
단점
- 초기 설정 복잡 (라우팅, 공통 라이브러리 관리)
- UX 통일성을 맞추기 위한 추가 작업 필요

아직은 모든 회사가 쓰는 건 아니지만, 토스, 쿠팡 같은 대규모 서비스에서 점진적으로 도입하고 있습니다.

클라우드 네이티브와의 관계

아키텍처가 진화하면서 클라우드 환경은 사실상 필수 요소가 되었습니다.

Docker(컨테이너): 서비스별 독립 실행 환경 제공 → MSA 필수
Kubernetes(오케스트레이션): 수십~수백 개의 마이크로서비스를 자동으로 배포, 확장, 복구 관리
Serverless: 특정 이벤트(API 요청, 스케줄링)에 맞춰 코드만 실행 → 프론트에서도 Lambda 같은 서비스 자주 활용

정리하자면:
MSA는 클라우드 없이는 운영이 거의 불가능합니다.
그리고 프론트엔드 개발자도 이런 구조를 이해해야 API 호출, 배포 전략, 장애 대응을 더 깊이 이해할 수 있습니다.

프론트엔드 개발은 이제 단순히 화면을 예쁘게 그리는 일이 아닙니다.
서비스가 점점 커지고 복잡해질수록, 아키텍처를 이해하는 프론트엔드 개발자가 더 큰 경쟁력을 갖게 됩니다.

저 역시 패키지 매니저 공부에서 출발했지만, 모놀리식 → SOA → MSA → Micro Frontend, 그리고 클라우드 네이티브까지 이어지는 흐름을 배우면서 큰 깨달음을 얻었습니다.

내가 배우는 개념이 회사 구조랑 맞닿아 있다는 걸 알게 되는 순간, 개발자로서 한 단계 성장한다는 걸 느꼈습니다.
이 글이 독자분들께도 그런 시야를 넓히는 데 도움이 되었으면 좋겠습니다.

참고하시면 좋을 영상 첨부해요~
https://www.youtube.com/watch?v=8d4h7K_Fq-0

[토스 오픈소스 기여 vol.0] 오픈소스 기여 가이드

콘솔로그 — Mon, 15 Sep 2025 11:44:25 +0900

많은 개발자들이 조직에서 반복적인 프로젝트를 하다 보면, 기술적으로 정체되어 있다는 느낌을 받곤 합니다.
저 역시 최근 들어 그런 느낌을 자주 받았고, 큰 성장을 체감하지 못하고 있어 스스로 성장이 필요하다고 느꼈습니다.

그러던 중 오픈소스 관련 포스팅을 작성하면서, 오픈소스가 주는 이점을 크게 느끼게 되었고, 자연스럽게 오픈소스 기여를 해보고 싶다는 생각이 들었습니다. 하지만 처음이라 어디서부터 시작해야 할지 감이 오지 않아, 하나씩 차근차근 해보기로 마음먹었습니다.

먼저, 토스의 경우 코드를 이렇게 작성하고, 이슈나 PR을 이렇게 커뮤니케이션하는구나 라는 점을 느끼며, 초기에는 문서(docs) 수정부터 시작하고 점차 코드 영역으로 확장했다고 합니다. 저 역시 간단한 타입 정의나 테스트 코드부터 시작해서, 나중에는 CI 관련 코드 등으로 참여 범위를 넓혀보려고 합니다.

이번 글에서는 제가 이 과정을 직접 경험하며 공유하려고 합니다.
오늘은 프로젝트를 다운받고, 코드를 어떤 식으로 작성하고 있는지 확인하는 것부터 시작해보겠습니다.

토스에는 Slash라는 내부 라이브러리 컬렉션이 있습니다.
Slash는 토스 내부에서 사용되는 여러 TypeScript/JavaScript 유틸리티와 React 도구를 한데 모아놓은 컬렉션으로, “Slash libraries”라는 이름으로 문서가 정리되어 있습니다.

이 라이브러리들은 미리 정의된 문제들을 해결하기 위해 만들어졌습니다.
예를 들어, 한글 처리, React Suspense 관리, 복잡한 사용자 흐름 관리 등 다양한 개발 과정에서 반복적으로 발생하는 문제들을 효율적으로 처리할 수 있도록 돕습니다.

https://www.slash.page/ko/

Slash 라이브러리

높은 퀄리티의 웹 서비스를 개발하기 위한 TypeScript/JavaScript 패키지 세트

www.slash.page

토스 오픈소스 라이브러리 목록

es-toolkit
토스에서 만든 유틸리티 라이브러리 모음
es-hangul
한글 관련 유틸리티 및 텍스트 처리 라이브러리
suspensive
React Suspense를 활용한 비동기 상태 관리 라이브러리
overlay-kit
모달, 팝업 등 UI 오버레이 컴포넌트 라이브러리
use-funnel
퍼널 분석 및 이벤트 추적을 위한 React 훅 라이브러리

각 라이브러리 설명

라이브러리 이름	기능 / 문제 해결	주요 특징 / 활용 예
es-toolkit	일반적인 자바스크립트 유틸리티 함수 모음 (lodash 같은 역할)	작고 빠름, 번들 사이즈 작고 타입 안정성 있음. 예: debounce, sum, delay, throttle 같은 함수들이 있음.
es-hangul	한글 문자열 처리를 편하게 조사 붙이기 / 초성 추출 / 분해 및 조합 등	예: getChoseong, josa 함수 등이 있어 “사과가/사과를 먹었습니다” 같은 표현을 자동 처리 가능. ECMAScript Modules 방식이며 브라우저에서도 최소 코드 다운로드 하도록 설계됨.
suspensive	React의 Suspense / ErrorBoundary 등을 간편하게 사용하려는 도구 집합	SSR 환경에서 Suspense를 점진적으로 적용 가능하게 해주는 clientOnly 같은 기능도 제공됨. <Suspense>, <ErrorBoundary>, <ErrorBoundaryGroup> 등의 선언적 API 제공.
overlay-kit	React에서 모달, 팝업, 다이얼로그 등 “오버레이” UI를 선언적으로 관리	상태 관리(useState 등)과 이벤트 핸들링 복잡성 줄임. overlay.open, overlay.openAsync 같은 API가 있음. 오버레이 안에서 어떤 UI를 렌더링할지 쉽게 조정 가능.
use-funnel	단계(step)가 있는 사용자 흐름(funnel)이나 wizard 형태의 UI 흐름 관리	예: 여러 입력 단계(이메일 → 비밀번호 → 정보 입력 등)를 타입 안정성 있게 관리. 히스토리(back/forward) 지원됨. 다양한 라우터 환경(Next.js, react-router, react navigation) 대응.

처음 오픈소스 기여를 시작할 때는

프로젝트의 규모, 코드 난이도, 문서화 상태, 이슈 난이도를 보고 선택하는 게 좋을것 같아서 비교를 해보았습니다.

토스 오픈소스 5개 라이브러리(es-toolkit, es-hangul, suspensive, overlay-kit, use-funnel)를 내부 구조와 API 관점에서 비교해보면, 접근 난이도나 활용 목적을 한눈에 볼 수 있을 것같아서 GPT의 도움을 받아 비교해서 선별해보았습니다.

정리

초보 기여자: es-toolkit / es-hangul → 함수 중심, 테스트/문서 개선으로 시작하기 좋음
중급 개발자: overlay-kit, use-funnel → Hook/컴포넌트 구조 이해 필요
상급 개발자: suspensive → React Suspense + SSR, 에러 경계 관리 이해 필요

라이브러리의 내부 구조와 대표 API

1️⃣ es-toolkit (범용 JS 유틸)

es-toolkit/
├─ src/
│   ├─ debounce.ts       # 함수 지연 호출
│   ├─ throttle.ts       # 함수 제한 호출
│   ├─ sum.ts            # 배열 합계
│   └─ delay.ts          # Promise 지연
└─ tests/
    ├─ debounce.spec.ts
    ├─ throttle.spec.ts
    └─ sum.spec.ts

대표 API: debounce(), throttle(), sum(), delay()
특징: 순수 JS 함수, 타입스크립트 지원, 테스트(Vitest) 포함

es-toolkit은 단순한 JS 함수들의 모음이에요. src 폴더 안에는 debounce, throttle, sum, delay 같은 개별 함수 파일이 있고, 각각에 대응하는 테스트 파일이 tests 폴더에 있어요.
대표 API는 debounce()나 throttle() 같은 함수로, 브라우저나 Node 환경에서 그대로 쓸 수 있습니다. 타입스크립트를 지원하고 Vitest로 테스트를 돌릴 수 있어 초보자가 기여하기 가장 쉬운 구조입니다.

2️⃣ es-hangul (한글 처리)

es-hangul/
├─ src/
│   ├─ josa.ts           # 조사 붙이기
│   ├─ getChoseong.ts    # 초성 추출
│   ├─ hangulCompose.ts  # 글자 조합
│   └─ hangulDecompose.ts# 글자 분해
└─ tests/
    ├─ josa.spec.ts
    ├─ getChoseong.spec.ts
    └─ hangulCompose.spec.ts

대표 API: josa('사과', '을'), getChoseong('가나다')
특징: 작은 범위, 직관적, 타입 안전, Vitest

es-hangul은 한글 문자열 처리에 특화된 유틸 모음이에요. src 안에는 josa.ts(조사 붙이기), getChoseong.ts(초성 추출), hangulCompose.ts(글자 조합), hangulDecompose.ts(글자 분해) 같은 파일들이 있어요. 테스트도 Vitest로 작성되어 있습니다.
대표 API는 josa('사과', '을')나 getChoseong('가나다')이고, 한글 처리 도메인이 직관적이라 입문용으로 적합합니다.

3️⃣ suspensive (React Suspense & ErrorBoundary)

suspensive/
├─ src/
│   ├─ components/
│   │   ├─ Suspense.tsx
│   │   └─ ErrorBoundary.tsx
│   ├─ hooks/
│   │   └─ clientOnly.ts
└─ tests/
    ├─ Suspense.spec.tsx
    └─ ErrorBoundary.spec.tsx

대표 API: <Suspense>, <ErrorBoundary>, clientOnly()
특징: React 전용, SSR 대응, 중급 난이도

suspensive는 React 환경에서 Suspense와 ErrorBoundary를 관리하기 위한 라이브러리입니다. src/components에는 와 컴포넌트가 있고, src/hooks에는 clientOnly 같은 Hook이 있습니다.
대표 API는 와 를 JSX에서 직접 쓰거나, clientOnly()로 SSR 환경에서 특정 컴포넌트를 클라이언트 전용으로 렌더링하는 방식입니다. React와 SSR 지식이 필요해 난이도가 중급 수준이에요.

4️⃣ overlay-kit (모달/팝업 관리)

overlay-kit/
├─ src/
│   ├─ overlay.tsx       # 오버레이 컨트롤
│   ├─ hooks/
│   │   └─ useOverlay.ts
└─ tests/
    ├─ overlay.spec.tsx
    └─ useOverlay.spec.ts

대표 API: overlay.open(<Modal />), overlay.close()
특징: Hook + API 조합, React UI 관리, 중급 난이도

overlay-kit은 React에서 모달, 팝업, 다이얼로그 등 오버레이 UI를 선언적으로 관리할 수 있게 도와주는 라이브러리입니다. src/overlay.tsx가 핵심이고, src/hooks/useOverlay.ts로 상태를 제어할 수 있습니다.
대표 API는 overlay.open()와 overlay.close()로, 오버레이를 열고 닫는 동작을 간단히 제어할 수 있습니다. React Hook과 컴포넌트 구조를 이해해야 해서 난이도는 중급이에요.

5️⃣ use-funnel (단계별 UI 흐름)

use-funnel/
├─ src/
│   └─ hooks/
│       └─ useFunnel.ts   # step 관리, next/back
└─ tests/
    └─ useFunnel.spec.ts

대표 API: const { step, next, back } = useFunnel(...)
특징: Wizard/Flow 관리, 타입 안전, 중급~상급

use-funnel은 단계별 UI 흐름이나 Wizard를 타입 안전하게 관리하는 Hook입니다. src/hooks/useFunnel.ts 안에서 step, next, back 등을 관리하며, 히스토리(back/forward)도 지원합니다.
대표 API는 const { step, next, back } = useFunnel(...)이고, 복잡한 단계형 UI를 만들 때 유용합니다. 타입 안정성을 이해해야 해서 난이도는 중급~상급이에요.

정리를 해보자면,

난이도별 접근성

es-hangul (가장 쉬움 ✅)
- 한글 관련 문자열 처리라 문제 도메인이 직관적임.
- 비교적 작은 범위(문자열 유틸 함수)라 이해하기 쉬움.
- “오타 수정”, “문서 보강”, “테스트 케이스 추가” 같은 기여 포인트 많음.
es-toolkit
- lodash 같은 유틸 모음.
- 코드가 단순한 함수 단위로 나뉘어 있어서 특정 함수 하나만 분석해도 됨.
- 작은 개선(PR) 시도하기 좋아요.
overlay-kit
- React에서 모달/팝업 UI를 다루는 라이브러리.
- 컴포넌트/Hook 기반이라, 프론트엔드 개발자로서 실사용 경험을 살려 기여하기 좋음.
- 다만 내부 구조(상태관리/Portal 등) 이해가 조금 필요.
use-funnel
- "단계별 UI 흐름" 관리 라이브러리.
- 타입 안정성이 핵심이라 TypeScript 타입 설계 경험 있으면 기여하기 괜찮음.
- 초반에는 난이도가 조금 높을 수 있음.
suspensive (가장 어려움 ⚠️)
- React Suspense/ErrorBoundary 다루는 고급 패턴.
- React 동작 원리에 대한 깊은 이해 필요.
- 초보자 입장에서는 난이도가 꽤 있음.

그리고 어떤 부분 먼저해야할지 감이 오지않아서 기여 포인트도 정해달라고 해보았다.

es-toolkit

기여 포인트
- 테스트 케이스 추가: debounce, throttle, sum 같은 함수의 경계값 테스트
- 문서 개선: 각 함수의 예제 코드 추가, 사용법 명확화
- 버그 수정: 작은 함수 동작 오류, 타입 정의 오류
난이도: 낮음
추천 이유: 순수 JS 함수라 코드 이해가 쉽고, 테스트/문서 기여가 곧바로 의미 있음

es-hangul

기여 포인트
- 테스트 케이스 확장: 조사 처리, 초성 추출 등 예외 케이스 추가
- 문서 보강: 함수 사용 예제, 한국어 맞춤법 관련 설명 추가
- 작은 버그/오타 수정
난이도: 낮음
추천 이유: 한글 처리라는 도메인이 직관적이고, 초보자도 테스트/문서 개선으로 기여 가능

overlay-kit

기여 포인트
- 테스트 케이스 추가: overlay.open() / overlay.close() 동작 검증
- 문서 개선: 오버레이 사용 예제, Hook 사용법 추가
- UI 컴포넌트 개선: 기본 Modal 컴포넌트 스타일 수정이나 Props 설명 추가
난이도: 중급
추천 이유: React Hook과 UI 관리 경험을 살릴 수 있음, 테스트/문서 기여로 시작 가능

use-funnel

기여 포인트
- 테스트 케이스 추가: step 이동, back/forward, 예외 케이스
- 문서 개선: 단계별 UI 구성 예제, 타입 설명 추가
- 예제 시나리오 추가: Wizard나 회원가입 같은 흐름 샘플 작성
난이도: 중급~상급
추천 이유: 단계별 UI 흐름 이해가 필요하지만, 테스트/문서로 접근하면 시작 가능

suspensive

기여 포인트
- 문서 개선: <Suspense> / <ErrorBoundary> 사용법, SSR 관련 주의 사항 추가
- 테스트 케이스 확장: Suspense fallback, 에러 처리 시나리오
- 작은 버그/타입 오류 수정
난이도: 상급
추천 이유: React Suspense와 SSR 이해가 필요하지만, 문서/테스트 기여로 접근 가능

[React 공식문서 Vol.1] 리액트 설치 및 환경 구축 완벽 가이드

콘솔로그 — Sun, 14 Sep 2025 09:54:41 +0900

리액트 공식문서 짚어보기 1일차 시작하겠습니다.

오늘 해 볼 부분은 설치하기 입니다.

↓↓↓ 아래 공식문서 링크 입니다.

https://ko.react.dev/learn/installation

설치하기 – React

The library for web and native user interfaces

ko.react.dev

이 장에서는

리액트 공식문서에 따르면 React를 실행해 볼 수 있는 방법은 크게 두 가지예요.
바로 "샌드박스"와 "로컬개발환경구성"입니다.

️ 샌드박스에서 실행하기

리액트는 별도의 설치 없이도 온라인 코드 에디터에서 바로 실행해 볼 수 있습니다.
예를 들어 CodeSandbox, StackBlitz, CodePen 같은 툴들이 React를 지원하기 때문에,
처음 설치 과정이 번거롭게 느껴진다면 브라우저에서 바로 코드를 작성하고 실행해볼 수 있어요.

로컬 개발 환경 구성하기

하지만 결국에는 내 PC에 직접 개발 환경을 세팅하는 방법이 가장 좋아요.
이 방식은 실제 프로젝트를 만들 때도 그대로 사용할 수 있기 때문에, React를 본격적으로 배우려면 꼭 거쳐야 하는 과정입니다.

로컬 환경을 꾸미려면 보통 다음 과정이 필요합니다.

Node.js 설치
프로젝트 생성 도구 사용 (예: Create React App, Vite, Next.js 등)
코드 에디터 준비 (Visual Studio Code 추천)

1️⃣ Node.js 설치하기

React는 자바스크립트 기반 라이브러리이기 때문에 Node.js가 꼭 필요합니다.
Node.js 공식 사이트에 들어가면 LTS(Long Term Support) 버전과 Current 버전 두 가지가 보일 거예요.

LTS(Long Term Support) : 장기 지원 버전으로, 안정성과 호환성이 보장됩니다. 기업이나 프로젝트에서 실무에 가장 많이 사용해요.
Current : 최신 기능이 포함된 버전이지만, 안정성보다는 새 기능 테스트에 가깝습니다.

React를 배우고 실제 프로젝트를 진행하려면 LTS 버전을 설치하는 게 안전합니다.

설치가 잘 되었는지 확인하려면 터미널에서 다음 명령어를 입력합니다:

node -v
npm -v

2️⃣ 프로젝트 생성하기

로컬에서 React 프로젝트를 시작하는 방법은 여러 가지가 있습니다.

Create React App (CRA)

가장 전통적인 방식으로, 초보자도 쉽게 사용할 수 있습니다.

npx create-react-app my-app
cd my-app
npm start

npm install 따로 안 해줘도 되나?

사실 npx create-react-app my-app 명령어 안에는 이미 설치 과정이 포함되어 있어서 따로 설치할 필요가 없습니다.

여기서 사용되는 npx는 npm 패키지를 로컬에 설치하지 않아도 바로 실행할 수 있게 해주는 도구예요.

하지만, 공식문서에도 있다시피 CRA는 더 이상 사용되지 않습니다.

️ Create React App(CRA)의 등장과 퇴장

CRA의 탄생 (2016년)

2016년, React 팀은 Create React App(CRA)을 처음 공개했습니다.
그 당시에는 React 앱을 새로 만들기 위한 표준적인 방법이 없었어요.

React를 시작하려면 직접 다음과 같은 도구들을 하나하나 설치하고 연결해야 했습니다.

JSX 컴파일러
Linting 도구
Hot Reloading 환경

이 과정은 굉장히 까다롭고 복잡했습니다.
그래서 커뮤니티에서는 자주 사용하는 설정을 묶어 보일러플레이트(boilerplate)를 만들었지만,
업데이트가 어렵고 설정이 조각나 있어서 React 팀이 새로운 기능을 배포하기 힘들었죠.

CRA는 이런 문제를 해결했습니다.
여러 도구를 하나의 권장 설정으로 통합해 주었고,
React 팀이 Fast Refresh 지원, Hooks Lint 규칙 같은 새로운 기능을
쉽게 많은 사용자에게 배포할 수 있도록 도와주었습니다.

CRA의 한계와 지원 종료

CRA는 초보자가 React를 쉽게 시작할 수 있도록 큰 역할을 했습니다.
하지만 시간이 지나면서 한계가 뚜렷해졌습니다.

빌드 속도가 느려 대규모 앱에는 비효율적
최신 개발 트렌드(예: 서버 사이드 렌더링, 코드 스플리팅 등) 반영이 어려움
유지보수 담당자가 사라지면서 업데이트 정체

React 팀은 CRA를 프레임워크로 발전시켜 문제를 해결할 수도 있었지만,
이미 Next.js, Remix, Vite 같은 강력한 대안들이 자리를 잡은 상황이었습니다.

결국 React 팀은 CRA의 지원 종료를 결정했습니다.
이제 새로운 앱을 설치할 때 CRA를 사용하면 지원 종료 경고 메시지가 표시됩니다.

그래서 요새 대부분 마이그레이션을 하는 추세예요.

CRA를 꼭 알아야 마이그레이션 할 수 있을까?

1. CRA를 몰라도 마이그레이션 가능 ✅

CRA 프로젝트는 기본적으로 Webpack + Babel 기반의 설정을 감춰둔 구조입니다.
실제 마이그레이션은 대부분 의존성 패키지 교체 + 빌드 도구 전환 작업이에요.
그래서 CRA 내부 설정을 다 알 필요는 없습니다.

즉, “CRA가 내부적으로 어떻게 동작하는지”까지 알 필요는 없어요.

2. 하지만 CRA 구조를 조금 알면 이득 ⬆️

CRA는 src/, public/ 폴더 구조와 index.js 진입 파일 등 표준 프로젝트 구조를 가지고 있어요.
이 구조를 이해하면 Vite나 Next.js로 옮길 때 파일 매핑이 훨씬 수월합니다.
예를 들어:
- CRA의 public/index.html → Vite의 index.html
- CRA의 index.js → Vite/Next.js의 진입점(main.jsx or _app.tsx)

3. 마이그레이션 접근 방식

CRA → Vite
- 폴더 구조 비슷, 비교적 단순
- react-scripts 제거 후 Vite 설정 추가
- babel 대신 Vite의 esbuild/rollup을 사용
CRA → Next.js
- 라우팅, 서버 기능이 다르므로 단순 교체보다는 프로젝트 구조 개편 필요
- 하지만 CRA 내부를 몰라도 Next.js 공식 문서의 “마이그레이션 가이드”만 따르면 충분

CRA에서 마이그레이션 하기

CRA의 지원이 종료되면서, 이제는 새로운 프로젝트를 시작하거나 기존 앱을 이어가려면 프레임워크 또는 빌드 도구로 옮겨야 합니다.

1️⃣ 프레임워크로 마이그레이션 하기 (추천 ⭐)

React 팀은 새로운 앱을 만들 때 프레임워크 기반으로 시작하는 걸 권장합니다.
추천되는 모든 프레임워크는 다음 특징을 지원합니다:

클라이언트 사이드 렌더링(CSR)
단일 페이지 앱(SPA)
CDN 또는 정적 호스팅 서비스에 서버 없이 배포 가능

즉, CRA로 하던 방식은 그대로 유지하면서도 프레임워크가 제공하는 강력한 기능들을 더 활용할 수 있습니다.

공식 마이그레이션 가이드:

2️⃣ 빌드 도구로 마이그레이션하기 (커스텀 세팅이 필요할 때)

만약 앱이 특수한 제약 조건을 가지고 있거나, 직접 프레임워크를 만들고 싶은 경우, 혹은 React가 처음부터 어떻게 동작하는지 배우고 싶다면 빌드 도구를 직접 선택할 수 있습니다.

대표적인 빌드 도구:

Vite → 빠른 빌드, 간단한 설정
Parcel → 제로 설정(Zero-config) 철학
RSBuild → 최신 Rust 기반 빌드 도구

공식 마이그레이션 가이드:

또한 React 팀은 Vite, Parcel, RSBuild로 앱을 새로 시작하는 데 도움을 주는 문서를 별도로 추가해 두었습니다.

⚡ Vite

요즘은 빠른 빌드 속도와 가벼운 설정 때문에 Vite를 많이 사용합니다.

npm create vite@latest my-app
cd my-app
npm install
npm run dev

1. Vite 설치 및 프로젝트 생성 방법

방법 1: npx 사용

npx create-vite@latest my-app

CRA처럼 패키지를 임시로 다운로드해서 실행
프로젝트 폴더(my-app) 생성 후 기본 세팅 완료
이후 cd my-app → npm install → npm run dev

방법 2: npm init 사용 (최신 권장)

npm create vite@latest my-app

사실상 npx와 동일한 기능
최신 Vite 문서에서는 이 방법을 더 권장
이유: npm create <패키지>가 npx보다 명확하게 최신 버전을 설치해 줌

2. 실행 과정

프로젝트 생성: npm create vite@latest my-app
디렉터리 이동: cd my-app
의존성 설치: npm install
개발 서버 실행: npm run dev

CRA와 달리 Vite는 프로젝트 생성 후 의존성을 별도로 설치해야 합니다.
CRA는 npx create-react-app 명령어 안에서 자동으로 설치까지 해주지만, Vite는 한 단계가 추가되는 구조예요.

Next.js

서버 사이드 렌더링과 라우팅까지 제공하는 프레임워크를 쓰고 싶다면 Next.js가 좋아요.

npx create-next-app@latest my-app
cd my-app
npm run dev

3️⃣ 코드 에디터 준비

개발을 편하게 하려면 Visual Studio Code(VS Code) 같은 코드 에디터를 설치하는 게 좋아요.
여기에 React 관련 확장 프로그램(예: ES7+ React/Redux/React-Native snippets, Prettier 등)을 추가하면 더 편리합니다.

️ Custom Toolchain

우선 알기 쉽게 간단히 요약하고 아래에 자세히 한번 알아볼게요.

⚙️ React 개발 환경의 역할별 도구 구조

React 앱을 개발할 때, 여러 도구가 각자 역할을 나눠 수행합니다.
한눈에 이해하기 쉽게 기호와 단계로 정리해 보겠습니다.

  패키지 매니저
└─ npm / yarn / pnpm
   → 프로젝트 생성, 라이브러리 설치/관리

  컴파일러(Transpiler)
└─ Babel / TypeScript / esbuild
   → JSX, 최신 JS, TS를 브라우저가 이해할 수 있는 JS로 변환

  번들러(Bundler)
└─ Webpack / esbuild / Rollup / Parcel
   → 여러 파일(JS, CSS, 이미지)을 하나 또는 몇 개로 묶고 최적화

  개발 서버(Dev Server)
└─ CRA: react-scripts start
└─ Vite: vite dev server
└─ Next.js: next dev
   → 코드 변경 시 자동 반영, Hot Reload 지원

  Lint & Formatter
└─ ESLint / Prettier
   → 코드 스타일 검증, 문법 오류 확인

  테스트 도구
└─ Jest / Vitest
   → 단위 테스트, 통합 테스트 수행

패키지 매니저란?

Node.js를 설치하면 함께 npm(Node Package Manager)이라는 패키지 매니저가 따라옵니다.
패키지 매니저는 리액트 같은 라이브러리를 설치하고 관리해 주는 도구예요.

대표적으로는 다음 세 가지가 있습니다:

npm
- Node.js 기본 패키지 매니저
- 따로 설치할 필요 없음 (Node 설치 시 자동 포함)
- 가장 널리 사용됨
yarn
- Meta(구 Facebook)에서 만든 패키지 매니저
- npm보다 속도가 빠르고, 설치 과정에서 안정성을 강조
- 팀 단위 프로젝트에서 종종 사용됨
pnpm
- 디스크 공간을 효율적으로 쓰는 최신 패키지 매니저
- 동일한 패키지를 여러 프로젝트에서 공유 가능
- 속도도 빠르고 최근에 점점 인기가 올라가는 중

처음 시작하는 단계라면 npm 그대로 사용해도 충분합니다.
필요에 따라 yarn이나 pnpm을 선택할 수도 있다는 정도만 알고 계시면 돼요.

그럼 패키지 매니저 선택 시점은 언제일까요?

패키지 매니저 선택 시점

보통 React 프로젝트를 시작할 때 패키지 매니저는 프로젝트 생성 직전에 선택합니다.

1️⃣ 프로젝트 생성 도구 실행 전

CRA, Vite, Next.js 등 프로젝트 생성 명령어를 실행하기 전에
자신이 사용할 패키지 매니저를 결정합니다.
예시:
- npm → CRA: npx create-react-app my-app
- yarn → CRA: yarn create react-app my-app
- pnpm → Vite: pnpm create vite@latest my-app

패키지 매니저에 따라 생성 후 설치 명령어(npm install / yarn / pnpm install)가 달라집니다.

2️⃣ 프로젝트 생성 후

프로젝트 생성 과정에서 패키지 매니저가 설치와 의존성 관리를 담당합니다.
이후 모든 패키지 추가, 삭제, 실행 명령은 선택한 패키지 매니저로 실행합니다.
- 예: npm install axios vs yarn add axios vs pnpm add axios
이미 프로젝트를 시작한 뒤 다른 매니저로 바꾸는 것도 가능하지만,
의존성 관리 방식이 달라 충돌이 생길 수 있어 추천하지 않습니다.

3️⃣ 선택 기준

팀에서 표준화된 매니저가 있다면 그걸 선택
초보자 / 단순 프로젝트 → npm
속도와 캐싱 효율 → yarn 또는 pnpm
디스크 공간 효율 → pnpm

️ React에서 컴파일러란?

React 자체는 브라우저에서 바로 실행 가능한 자바스크립트 라이브러리입니다.
그런데 우리가 작성하는 코드에는 최신 자바스크립트 문법, JSX, TypeScript 등이 포함되어 있어서
브라우저가 이해하지 못하는 경우가 많아요.

이때 등장하는 것이 컴파일러(Transpiler)입니다.

컴파일러는 다음 작업을 수행합니다.

JSX → JavaScript 변환

const element = <h1>Hello, React!</h1>;

→ 브라우저가 이해할 수 있는 JS 코드로 변환
최신 JS 문법 변환
- ES6+ 문법 (예: import, const, arrow function) → 호환 가능한 코드로 변환
TypeScript → JavaScript 변환
- 타입 정보를 제거하고 순수 JS 코드로 변환

대표 컴파일러

Babel: CRA, Vite 등에서 기본적으로 사용
TypeScript Compiler(tsc): TypeScript 프로젝트에서 사용
esbuild: Vite 등 최신 빌드 도구에서 빠른 변환용

어떤 식으로 동작하냐면,

개발자 코드(JSX, TS) → 컴파일러(Babel/esbuild/tsc) → 브라우저가 이해 가능한 JS

즉, 컴파일러는 브라우저가 이해하지 못하는 코드를 변환해 주는 역할
React 개발 환경에서는 거의 항상 자동으로 설정되어 있어서 개발자가 따로 설치할 필요는 없음

️ CRA vs Vite vs Next.js 컴파일러 비교

React 프로젝트를 만들 때 어떤 컴파일러가 쓰이는지에 따라 빌드 속도와 개발 경험이 달라집니다.

프로젝트 도구	기본 컴파일러	특징	주의점
CRA (Create React App)	Babel	- JSX, 최신 JS 문법을 브라우저 호환 코드로 변환 - 프로젝트 생성 시 자동 설정 - 개발 서버 Hot Reload 지원	- 빌드 속도가 비교적 느림 - 설정 커스터마이징이 제한적
Vite	esbuild + Babel	- esbuild가 빠른 변환 제공 → 개발 서버 매우 빠름 - 일부 고급 변환은 Babel 사용 - TypeScript 지원	- CRA보다 초기 설정 자유도가 높음 - 일부 Babel 플러그인 호환성 확인 필요
Next.js	Babel + SWC	- SWC(Speedy Web Compiler)로 빠른 빌드 - SSR, SSG 지원 - JSX, TS 변환 모두 처리	- SWC는 일부 고급 Babel 플러그인 미지원 - 서버 렌더링 관련 설정 필요

️ 기본 컴파일러와 커스터마이징 가능 여부

1. CRA (Create React App)

기본 컴파일러: Babel
변경 가능 여부: 제한적
- CRA는 설정이 숨겨져 있음(react-scripts 내부에 설정)
- 직접 Babel을 교체하거나 Webpack 설정을 바꾸려면 eject 해야 함
- eject 후에는 모든 설정이 프로젝트 안으로 풀리지만, 되돌릴 수 없음 → 관리 부담 ↑

npm run eject

대부분은 CRA 기본 Babel 설정 그대로 사용하는 것이 권장

2. Vite

기본 컴파일러: esbuild + Babel
변경 가능 여부: 자유로움
- Vite는 설정 파일(vite.config.js)을 직접 수정 가능
- 필요하면 esbuild 대신 Babel로 전환하거나 플러그인을 추가 가능
- 설정 자유도가 높아서 커스텀 툴체인에 적합

3. Next.js

기본 컴파일러: Babel + SWC
변경 가능 여부: 부분적으로 가능
- Next.js는 SWC를 기본으로 사용하여 빠른 빌드 제공
- SWC 대신 Babel로 강제 전환 가능 (next.config.js 설정)
- 하지만 SWC 최적화 일부를 포기해야 함

Vite가 가장 유연하게 컴파일러를 변경할 수 있고, CRA는 거의 못 바꾸는 수준, Next.js는 부분적 조정만 가능하다고 이해하면 됩니다.

️ 번들러(Bundler)란?

React 프로젝트에서는 많은 파일과 라이브러리를 사용하게 됩니다.
브라우저는 import 같은 모듈 문법을 일부만 지원하고, 여러 개의 파일을 한 번에 로드하는 데 한계가 있어요.
이때 등장하는 것이 번들러(Bundler)입니다.

번들러의 역할:

여러 개의 JS, CSS, 이미지 파일을 하나 또는 몇 개의 파일로 묶음
브라우저가 효율적으로 읽을 수 있는 형태로 변환
필요시 최적화, 코드 스플리팅, 압축까지 수행

대표 번들러

번들러	특징	사용 예시
Webpack	가장 널리 쓰이는 번들러, 플러그인과 설정 자유도가 높음	CRA, 커스텀 프로젝트
esbuild	매우 빠른 빌드, TypeScript 지원, 최신 도구 중심	Vite 개발 서버
Rollup	라이브러리 배포에 최적화, 트리 쉐이킹(Tree Shaking) 강력	라이브러리 제작, Vite 빌드
Parcel	설정 거의 필요 없음, Zero-config	개인 프로젝트, 학습용

React 프로젝트에서 번들러 위치

개발자 코드 + 라이브러리 → 번들러(webpack/esbuild/rollup) → 브라우저가 읽는 단일/최적화된 파일

CRA: Webpack
Vite: 개발 서버 → esbuild, 빌드 시 Rollup 사용
Next.js: Webpack 기본, 빌드 최적화 가능

번들러를 직접 바꿀 수 있을까?

CRA: Webpack 설정 숨겨져 있어 어렵다(eject 필요)
Vite: 설정 파일에서 쉽게 교체/커스터마이징 가능
Next.js: Webpack 교체 가능, 일부 제한 존재

번들러는 여러 파일을 하나로 묶어 브라우저가 실행 가능하게 해주는 도구
React 프로젝트에서는 필수적인 역할
도구마다 기본 번들러가 다르고, 변경 가능 여부도 차이가 있음

️ 미니파이어(Minifier)란?

미니파이어는 코드 파일의 크기를 줄여주는 도구입니다.
React 앱처럼 여러 JS, CSS 파일을 브라우저에서 로드할 때, 파일 크기가 크면 페이지 로딩 속도가 느려집니다.

미니파이어는 이를 해결하기 위해 불필요한 공백, 줄 바꿈, 주석, 변수 이름을 축약합니다.

// 원본
function sayHello(name) {
    console.log("Hello, " + name + "!");
}
sayHello("React");

↓↓↓ 미니파이 후

// 미니파이 후
function a(b){console.log("Hello, "+b+"!")}a("React");

번들링 과정에서 자동 적용: Webpack, Vite, Rollup 등 대부분 번들러가 미니파이어 기능을 포함
프로덕션 빌드 시 필수: 개발 서버에서는 가독성을 위해 적용하지 않음

목적: 코드 용량 줄여 페이지 로딩 속도 개선
언제 쓰는가: 프로덕션 빌드 시 자동 적용
개발자가 직접 건드릴 필요 거의 없음

️ 테스트 러너(Test Runner)란?

테스트 러너는 작성한 테스트 코드를 실행하고 결과를 확인하는 도구입니다.
React 앱에서는 UI, 기능, 상태 관리 등이 의도대로 동작하는지 검증할 때 사용합니다.

역할

테스트 파일 실행
성공/실패 여부 출력
테스트 환경 설정 (예: DOM 시뮬레이션, Mock 데이터 제공)
테스트 보고서 생성

즉, 코드를 실제로 실행해서 기능이 올바른지 확인해주는 역할입니다.

테스트 러너	특징	React 환경 사용 예시
Jest	Facebook에서 만든 JavaScript 테스트 러너	CRA, Vite, Next.js 기본 지원, 단위/통합 테스트 가능
Vitest	Vite 친화적, 빠른 테스트	Vite 프로젝트 추천, Jest 호환 API 지원
Mocha	유연한 구조, 커스텀 가능	구버전 또는 커스텀 프로젝트에서 사용
Jasmine	BDD 스타일, 비교적 오래된 JS 테스트	과거 프로젝트 유지보수용

React에서 사용하는 방식

단위(Unit) 테스트: 함수, 컴포넌트 개별 기능 검증
통합(Integration) 테스트: 여러 컴포넌트를 함께 사용했을 때 동작 검증
UI 테스트: React Testing Library와 결합해 실제 DOM 렌더링 결과 검증

import { render, screen } from '@testing-library/react';
import App from './App';

test('renders hello message', () => {
  render(<App />);
  const heading = screen.getByText(/hello react/i);
  expect(heading).toBeInTheDocument();
});

오늘은 React 공식 문서의 설치 및 개발 환경 구성 부분을 중심으로 살펴봤습니다.
CRA, Vite, Next.js 등 다양한 프로젝트 생성 도구가 있고, 각 도구마다 기본 컴파일러와 번들러가 있다는 점을 배웠습니다.
npx create-react-app 명령어가 프로젝트 생성과 의존성 설치를 한 번에 처리해준다는 것도 확인했죠.

Vite는 최신 도구답게 빠른 빌드와 자유로운 설정이 장점이며, Next.js는 서버 사이드 렌더링까지 지원합니다.
React 환경에서는 패키지 매니저, 컴파일러, 번들러, 미니파이어, 개발 서버, 테스트 러너가 각자 역할을 나눠 프로젝트를 효율적으로 관리합니다.
특히 Jest와 같은 테스트 러너를 통해 단위 테스트와 통합 테스트를 쉽게 실행할 수 있다는 것도 실습해봤습니다.
CRA와 Vite, Next.js의 도구별 특징과 커스터마이징 가능 여부를 비교하면서, 자신에게 맞는 개발 환경을 선택하는 기준도 알 수 있었습니다.

이 과정에서 각 도구가 제공하는 편의성과, 직접 설정할 수 있는 Custom Toolchain의 장단점도 이해할 수 있었죠.
앞으로는 오늘 배운 내용을 바탕으로 실제 프로젝트를 만들고 실행해보며, 각 도구가 어떻게 동작하는지 경험해보는 것이 중요합니다.
React 개발 환경을 제대로 이해하면, 새로운 프로젝트를 시작할 때 어떤 도구를 선택하고, 효율적으로 구성할지 자신 있게 결정할 수 있습니다.

[React 공식문서 vol.0] 공식문서로 리액트 기본 다지기

콘솔로그 — Sun, 14 Sep 2025 08:31:43 +0900

리액트를 공부하려고 마음먹었다면, 아마 가장 먼저 고민하게 되는 질문이 있습니다.

"뭐부터 공부해야 하지?" 혹은 "책을 볼까, 영상 강의를 볼까?"

솔직히 말해서, 저는 리액트를 제대로 공부하고 싶다면 공식문서보다 좋은 자료는 없다고 생각합니다.
왜냐하면 공식문서 안에는 리액트 기초부터 고급 문법까지, 핵심 개념과 실습 예제가 모두 담겨 있기 때문입니다.

게다가 이 문서는 리액트를 직접 개발한 사람들이 작성한 공식문서입니다.
즉, 누구보다 정확하고 믿을 수 있는 정보가 담겨 있으며, 최신 버전 React에 맞춰 항상 업데이트됩니다.
책이나 영상 강의는 출간 시점 이후 최신 내용이 반영되지 않을 수 있지만, 공식문서는 실시간으로 최신 정보가 반영됩니다.

저 역시 이미 4년 넘게 리액트를 사용했지만, 이번에 새롭게 버전업한 React가 어떤 새로운 기능과 개선 사항을 담고 있는지,
그리고 제가 알고 있는 지식이 여전히 정확한지 짚어보는 시간을 갖고 싶었습니다.

이런 이유로 이번 시리즈에서는 공식문서를 한 챕터씩 정주행하며, 리액트 기본을 다시 다지는 과정을 기록하려고 합니다.

공식문서를 읽는 목적

첫 번째 목표는 단순히 읽는 것이 아니라 이해하고, 직접 코드를 작성하며 내 것으로 만드는 것입니다.
JSX 문법, 컴포넌트 구조 같은 기본 개념부터 시작해, Hooks, Context API, Suspense 등 고급 주제까지 차근차근 학습할 예정입니다.

작은 컴포넌트를 직접 만들어보며 실습하면, 단순히 읽는 것보다 기억에 오래 남고 이해가 깊어집니다.
공식문서의 예제 코드는 실제로 동작하도록 작성되어 있어, 복사해서 내 프로젝트에 적용하거나 조금 변형해 나만의 코드로 만들 수 있습니다.

또한 공식문서를 정주행하면 리액트의 철학과 설계 의도를 자연스럽게 이해하게 됩니다.
그냥 사용법만 아는 개발자와, 왜 이런 방식으로 만들어졌는지 이해하는 개발자는 문제를 해결할 때 큰 차이가 납니다.

시리즈 진행 방식

이 시리즈에서는 매 포스트마다 한 챕터씩 정리하면서, 제가 직접 코드를 작성해보고 느낀 점도 함께 기록하려고 해요.

그래서 혼자 공부하는 분이나, 이제 막 리액트를 배우기 시작한 분도 같이 따라올 수 있도록 쉽게 따라갈 수 있는 구성으로 만들었습니다.

중요한 건 속도가 아니라 이해의 깊이예요.

하루에 조금씩 읽고, 코드를 작성하고, 다시 돌아보는 과정을 반복하다 보면 리액트의 기초부터 고급 개념까지 자연스럽게 내 것이 된답니다.

시리즈가 끝나갈 즈음에는, 공식문서를 읽는 게 얼마나 큰 힘이 되는지 직접 느낄 수 있을 거예요.

그리고 혼자서도 충분히 리액트 프로젝트를 설계하고 구현할 자신감이 생기실 거예요.

리액트 공식문서를 검색하면 두개가 있는데 필요하신 버전에 맞게 공부하시면 될 것같습니다.

현재 리액트는 v19 까지 나왔습니다.

구 React 공식문서

https://ko.legacy.reactjs.org/docs/getting-started.html

시작하기 – React

A JavaScript library for building user interfaces

ko.legacy.reactjs.org

신 React 공식문서

https://react.dev/

React

React is the library for web and native user interfaces. Build user interfaces out of individual pieces called components written in JavaScript. React is designed to let you seamlessly combine components written by independent people, teams, and organizati

react.dev

리액트 버전별 비교: 주요 변화와 특징

1. React 15 이전

주요 특징: 클래스 컴포넌트 중심, JSX 문법 기본, 가상 DOM 개념 도입
주의점: 함수형 컴포넌트는 단순한 렌더링용, 상태 관리 불가

2. React 16

주요 특징: Fiber 아키텍처 도입 → 렌더링 성능 개선
주요 추가 기능: Error Boundaries, Fragments, Portals
Hooks 전 단계: 상태와 사이드 이펙트는 여전히 클래스 컴포넌트에 의존

3. React 16.8

주요 특징: Hooks 도입 → 함수형 컴포넌트에서도 상태 관리와 생명주기 사용 가능
주요 Hooks: useState, useEffect, useContext

4. React 17

주요 특징: 주로 내부적인 변화, 점진적 업그레이드 용이
주의점: 새로운 기능 추가보다는 호환성과 마이그레이션 편의성 강화

5. React 18

주요 특징: Concurrent Mode 도입, 자동 배치(Batched Updates), Suspense 개선
주의점: 기존 프로젝트 업그레이드 시 일부 렌더링 방식 차이 확인 필요

함수형 컴포넌트 vs 클래스형 컴포넌트

리액트 컴포넌트에는 함수형 컴포넌트와 클래스형 컴포넌트 두 가지가 있어요.
최근에는 함수형 컴포넌트가 주류지만, 차이를 이해하면 둘 다 활용할 수 있습니다.

구분클래스형 컴포넌트함수형 컴포넌트

문법	class 키워드 사용, extends React.Component	일반 함수 형태, function 혹은 화살표 함수
상태 관리	this.state, this.setState()	Hooks 사용 (useState, useReducer)
생명주기	componentDidMount, componentDidUpdate 등	Hooks 사용 (useEffect)
장점	과거 프로젝트와 호환성, 명시적 생명주기 관리	간결하고 직관적, 코드량 적음, 최신 React 패턴과 호환
단점	코드가 길고 복잡해지기 쉬움	Hooks 개념 학습 필요, 클래스형 경험 없으면 초기 혼란

핵심 포인트

함수형 컴포넌트는 최근 리액트에서 권장되는 방식입니다.
클래스형 컴포넌트는 레거시 코드 유지나 일부 라이브러리 호환에서 여전히 필요할 때가 있어요.
Hooks를 활용하면 함수형에서도 상태 관리와 생명주기 기능을 완전히 사용할 수 있습니다.

리액트를 공부하다 보면 한 번쯤은 클래스형 컴포넌트 vs 함수형 컴포넌트를 비교하게 됩니다.
클래스형은 과거 프로젝트에서 많이 쓰였고, 생명주기 메서드가 명시적으로 드러난다는 장점이 있어요.
하지만 요즘 리액트의 흐름은 명확히 함수형 컴포넌트 + Hooks 쪽으로 가고 있습니다.

함수형은 코드가 훨씬 간결하고 직관적이라서,
처음 배우는 분들에게도 이해하기 쉽고 유지보수하기도 좋아요.
무엇보다 리액트 공식문서에서 제시하는 최신 패턴도 모두 함수형 기준으로 설명되어 있죠.

그래서 이번 시리즈에서는 함수형 컴포넌트를 중심으로 공부를 이어가려고 합니다.

물론 필요하다면 클래스형도 함께 다루겠지만,
중요한 건 최신 리액트가 어디에 초점을 맞추고 있는지를 따라가는 거라고 생각해요.

이제 본격적으로 문서를 정주행하면서,
리액트의 기초부터 고급 주제까지 차근차근 살펴보고 직접 코드를 작성해보겠습니다.
끝까지 따라오신다면, 단순히 "리액트를 쓸 줄 아는 사람"이 아니라
"리액트를 이해하는 개발자"가 될 수 있을 거예요.

[React] SPA와 리액트: 현대 웹 개발의 핵심 기술 이해하기

콘솔로그 — Sat, 13 Sep 2025 17:38:25 +0900

안녕하세요! 오늘은 리액트(React)에 대해 이야기해보려고 해요.
프론트엔드 채용 시, 거의 모든 회사가 요구하는 자격 조건이라고 해도 과언이 아니죠.

그런데 리액트가 왜 갑자기 등장했는지, 또 왜 이렇게 인기가 많아졌는지는 잘 모르는 분들도 많더라고요.
사실 리액트의 등장은 그냥 우연이 아니라, 웹 개발 환경과 트렌드 변화와 깊은 관련이 있어요.

조금만 거슬러 올라가 보면, 예전 웹은 대부분 정적인 페이지 중심이었어요.
사용자가 버튼을 누르면 페이지가 새로고침되고, 서버에서 HTML을 다시 받아오는 방식이었죠.

쉽게 예시를 들어 볼까요?

1️⃣ 쇼핑몰 장바구니

정적 페이지: 상품을 장바구니에 담으면 페이지가 새로고침됨.
- 화면 전체가 깜빡이면서 장바구니 리스트가 나타남.
- 장바구니 안에서 선택한 수량 같은 상태도 다시 초기화될 수 있음.
SPA: 수량 버튼 클릭 → 서버에 필요한 데이터만 요청 → 화면 일부만 업데이트.
- 깜빡임 없이 장바구니 수량이 바로 반영됨.

2️⃣ 댓글 작성/좋아요

정적 페이지: 댓글을 작성하거나 좋아요를 누르면 페이지 전체가 새로고침됨.
- 기존 댓글도 깜빡이며, 스크롤 위치가 맨 위로 이동할 수 있음.
SPA: 댓글 입력 → 서버로 데이터 전송 → 화면 일부만 업데이트.
- 기존 댓글은 그대로, 스크롤도 유지, 좋아요 숫자만 바로 바뀜.

3️⃣ 지도/위치 검색

정적 페이지: 지도에서 다른 지역을 검색하면 페이지 전체가 새로고침됨.
- 지도 화면이 잠깐 사라지고 다시 나타남 → 깜빡임 발생.
SPA: 검색 결과만 받아서 지도만 갱신 → 깜빡임 없음, 지도 위치 유지.

이런 예시가 도움이 되셨나요? 조금 더 이해가 쉬워졌길 바라요

처음에는 큰 불편함이 없었지만, 웹 서비스가 점점 복잡해지면서 문제가 나타났어요.

특히 사용자 경험이 중요한 서비스에서는 페이지 깜빡임과 느린 로딩이 큰 걸림돌이었죠.

그래서 등장한 것이 바로 SPA(Single Page Application)예요.
SPA는 한 페이지 안에서 필요한 부분만 갱신해서 보여주는 방식이에요.

SPA는 많은 웹 페이지를 로딩하더라도, 필요한 데이터만 빠르게 업데이트할 수 있어요.
덕분에 페이지 로딩 속도가 빨라지고, 트래픽도 줄일 수 있죠.
화면 전환이 부드럽고, 업데이트가 끝날 때까지 기다리는 시간도 짧아져서 사용자가 몰입감 있게 웹을 사용할 수 있어요.
덕분에 페이지 전체를 새로 불러오지 않아도 되고, 사용자 입장에서는 앱처럼 부드럽게 느껴지죠.

SPA의 주요 장점

1️⃣ 빠른 로딩 속도와 반응성
SPA는 페이지 전환 시 서버에서 전체 HTML을 내려받지 않고, 필요한 데이터만 업데이트해요.
최초 한 번만 전체 웹 애플리케이션 파일을 다운로드하면 이후에는 필요한 데이터만 받아 화면을 바꿀 수 있죠.
덕분에 로딩 속도가 빨라지고, 서버 트래픽도 줄일 수 있어요.

2️⃣ 향상된 사용자 경험
빠른 화면 전환과 부드러운 렌더링 덕분에, 사용자는 SPA를 엑셀이나 워드 같은 네이티브 앱처럼 느낄 수 있어요.
페이지가 느리면 사용자가 쉽게 이탈하지만, SPA는 체류 시간을 늘리고 만족도를 높일 수 있습니다.

3️⃣ 웹/모바일 공통 아키텍처 활용
전통적인 웹 개발 방식에서는 모바일 앱용 API 서버를 별도로 구성해야 했지만,
SPA는 UI와 서버 데이터를 분리하고 비동기 방식으로 데이터를 가져오기 때문에
웹 앱뿐 아니라 모바일 앱에서도 같은 백엔드를 활용할 수 있어 개발 효율이 높아요.

4️⃣ 복잡한 대규모 애플리케이션 대응
사용자와의 상호작용이 많고 동적 요소가 많은 앱도 SPA라면
필요한 부분만 업데이트하기 때문에 트래픽 부담을 줄이고 반응성을 유지할 수 있어요.
React, Vue, Angular 같은 프레임워크가 SPA 원칙을 도입하는 이유도 바로 여기에 있죠.

하지만 SPA 개발도 쉽지만은 않았어요.
자바스크립트 코드가 점점 복잡해지고, 상태 관리가 어려워지면서 개발자들이 머리를 싸매야 했거든요.

이때 등장한 것이 페이스북에서 만든 리액트예요.

리액트는 컴포넌트 단위로 UI를 쪼개 관리할 수 있게 해주고,

상태(state)가 바뀌면 알아서 화면을 효율적으로 업데이트해주는 가상 DOM(Virtual DOM)을 도입했어요.

덕분에 복잡한 SPA도 훨씬 깔끔하고, 유지보수가 쉬워졌죠.

즉, 리액트는 단순히 “유행하는 라이브러리”가 아니라,
SPA 시대의 필연적인 해결책이자, 개발자들의 고민을 덜어주는 도구였던 거예요.

오늘 글에서는 리액트가 왜 만들어졌는지, 어떤 문제를 해결하려고 했는지, 그리고 SPA와 어떤 관계가 있는지를 친근하게 풀어보려고 해요.
코드를 바로 다루기 전, 이렇게 배경부터 이해하면 훨씬 재밌게 따라올 수 있답니다.

리액트가 왜 만들어졌는가?

리액트는 SPA 개발의 복잡함을 해결하기 위해 만들어졌어요.

페이스북은 이런 문제를 해결하기 위해 UI를 컴포넌트 단위로 쪼개고,

상태 변화에 따라 필요한 부분만 효율적으로 업데이트하는 가상 DOM(Virtual DOM)을 도입한 리액트를 만들었습니다.
즉, "복잡한 SPA를 쉽게 만들고, 유지보수도 편하게 하자!"가 핵심 목표였어요.

여기서 궁금한점!

SPA 개발의 복잡함 이 뭐예요? 뭐가 복잡하다는 걸까요?

여기서 말하는 SPA 개발의 복잡함은 단순히 코드가 많아진다는 뜻이 아니라,

사용자 인터랙션과 상태 관리를 처리하는 로직이 점점 얽히면서 생기는 문제를 말해요.
좀 더 쉽게 풀어보면 이렇게 이해할 수 있어요.

1. 상태(state) 관리 문제

SPA에서는 한 페이지 안에서 여러 UI가 동적으로 바뀌잖아요.
예를 들어:

장바구니 목록 업데이트
댓글 작성 후 바로 화면 갱신
좋아요 버튼 클릭 시 숫자 증가

이럴 때 어떤 데이터가 어디에서 바뀌었는지, 그리고 화면에 어떻게 반영할지를 직접 다 관리해야 했어요.
페이지가 커질수록 “어떤 상태가 어디에 영향을 주는지”가 복잡해지고, 버그가 생기기 쉽죠.

2. DOM 업데이트 문제

SPA 이전에는 페이지 전체를 새로 그리면 됐어요.
하지만 SPA에서는 부분만 업데이트해야 하니까, DOM을 직접 조작해야 했어요.

어떤 요소를 바꿀지
이벤트 핸들러가 꼬이지 않도록
데이터와 UI를 동기화

이게 많아지면 코드가 점점 지저분하고 관리하기 어려워지는 구조가 돼요.

3. 이벤트와 비동기 처리 문제

SPA는 사용자 이벤트가 많고, 서버 데이터도 **비동기(Async)**로 받아와요.

서버에서 데이터를 받아와 화면에 바로 반영
동시에 여러 이벤트가 발생하면 상태 충돌 가능

이런 비동기 로직과 이벤트 로직을 직접 관리하다 보면 코드가 복잡해지고, 디버깅도 어렵죠.

쉽게 요약하면, SPA는 “화면 전체를 새로 그리지 않고 부분 업데이트”를 하기 때문에
상태 관리 + DOM 업데이트 + 비동기 처리가 복잡하게 얽히면서 코드가 복잡해지는 거예요.

2️⃣ 누가 만들었는가?

리액트는 페이스북(Facebook)에서 개발되었고, 2013년에 오픈소스로 공개되었습니다.
초기에는 페이스북 내부 뉴스피드에서 UI 문제를 해결하기 위해 시작됐고,
지금은 페이스북뿐만 아니라 인스타그램, 넷플릭스, 에어비앤비 등 다양한 기업에서도 사용되고 있어요.

3️⃣ 리액트는 어떻게 사용하는가?

리액트는 컴포넌트 기반으로 UI를 구성합니다.

화면을 작은 단위(컴포넌트)로 나누고, 각 컴포넌트가 자신만의 상태(state)와 속성(props)을 가짐
상태가 바뀌면 리액트가 알아서 화면을 효율적으로 업데이트
JSX라는 자바스크립트 안에서 HTML처럼 쓸 수 있는 문법으로 UI를 작성

즉, "UI를 작은 블록처럼 나누고, 상태가 바뀌면 필요한 블록만 자동으로 업데이트"하는 방식이에요.
리액트는 웹뿐만 아니라 모바일 앱 개발(React Native)에도 사용될 수 있어 확장성이 뛰어나죠.

1. 리액트 설치

보통은 간편하기 때문에 CRA 방식으로 프로젝트를 시작하시곤 해요. 저희 회사역시도 CRA로 만든 프로젝트들이 많습니다.

(하지만 최근 리액트에서는 해당 방식을 사용하지 말라고 해요. CRA 방법도 설명해드리지만 권장하진 않습니다.)

우선 CRA 방식 설명해드릴께요. 왜 리액트 공식 페이지에서 다른 방법을 권장하는지는 이 설명 밑에서 자세히 다룰께요.

리액트 프로젝트를 만들려면 Node.js가 필요해요.
설치 후 터미널에서 이렇게 입력하면 간단하게 새 프로젝트를 만들 수 있어요.

npx create-react-app my-app
cd my-app
npm start

create-react-app : 리액트 프로젝트를 빠르게 생성
npm start : 개발 서버를 실행해서 브라우저에서 바로 확인

이제 브라우저에서 http://localhost:3000을 열면 기본 페이지가 나타나요.

여기서

npx create-react-app my-app

해당 명령어를 CRA(Create React App) 방식이라고 말해요.

CRA란?
- 페이스북이 만든 공식 툴로, 리액트 프로젝트를 빠르게 생성하고 개발 환경을 세팅해주는 도구
- 번들러(Webpack), Babel, ESLint 같은 복잡한 설정을 자동으로 구성해 줌
- 덕분에 바로 코드를 작성하고 개발 서버를 띄울 수 있음
명령어 설명
- npx create-react-app my-app → my-app이라는 폴더에 새 리액트 프로젝트 생성
- cd my-app → 프로젝트 폴더로 이동
- npm start → 개발 서버 실행, 브라우저에서 결과 확인 가능

간편하다는 장점으로 리액트 초창기에는 많은 사람들이 CRA 방식을 선호했답니다.

하지만 최근에는,

리액트 공식 문서에서는 새로운 프로젝트에 create-react-app(CRA)을 사용하지 말고,

대신 Next.js, Vite, Parcel, Remix와 같은 최신 프레임워크나 빌드 도구를 사용하라고 권장하고 있습니다.

공식 권장 사항

2025년 2월 14일, 리액트 팀은 CRA를 공식적으로 사용 중단(deprecate)한다고 발표했습니다.

이후 새로 생성한 프로젝트에서는 CRA를 사용할 때마다 경고 메시지가 표시됩니다.

CRA는 더 이상 활성 유지보수가 이루어지지 않으며, 최신 리액트 버전(React 19)과의 호환성 문제로 인해 권장되지 않습니다 react.dev.

✅ 왜 CRA를 지양하나요?

성능 문제: CRA는 Webpack을 기반으로 하여 개발 서버 시작 속도와 핫 리로드(HMR)가 느립니다.
최신 기능 부족: 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 코드 분할 등의 기능이 기본적으로 지원되지 않습니다.
유지보수 부족: CRA는 2021년부터 활발한 유지보수가 이루어지지 않고 있으며, 리액트 19와의 호환성 문제로 인해 더 이상 권장되지 않습니다 Socket.

대안으로 권장되는 도구들

리액트 팀은 다음과 같은 도구들을 권장하고 있습니다:

Next.js: 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), API 라우팅 등 다양한 기능을 제공하는 풀스택 프레임워크입니다.
Vite: ESBuild를 기반으로 한 빠른 개발 서버와 빌드 도구로, 설정이 간단하고 성능이 뛰어납니다.
Parcel: 제로 설정으로 빠른 빌드를 지원하는 도구입니다.
Remix: 웹 표준을 기반으로 한 최신 프레임워크로, 데이터 패칭과 렌더링 최적화에 중점을 둡니다.

이러한 도구들은 최신 리액트 기능을 지원하며, 성능과 개발 경험을 향상시킬 수 있습니다.

️ CRA를 대체하려면?

새로운 프로젝트 시작 시: CRA 대신 위에서 언급한 도구들 중 하나를 선택하여 시작하는 것이 좋습니다.
기존 CRA 프로젝트를 마이그레이션할 때: 리액트 팀은 Vite, Next.js, Remix 등으로의 마이그레이션 가이드를 제공하고 있습니다.

리액트 공식 문서에서는 이러한 대체 도구들에 대한 자세한 정보를 제공하고 있으며, 프로젝트의 요구사항에 맞는 도구를 선택할 수 있도록 안내하고 있습니다 react.dev.

리액트 핵심 문법

리액트에서 가장 기본이 되는 개념은 State와 Props입니다.
이 두 가지를 이해하면, 컴포넌트 단위로 UI를 만들고 데이터가 바뀔 때 화면이 어떻게 업데이트되는지 쉽게 이해할 수 있어요.

State = 컴포넌트의 메모리

컴포넌트가 가지고 있는 값들을 저장하는 공간
값이 바뀌면 리액트가 알아서 UI를 갱신
페이지 전체를 새로고침하지 않고도 상태 변화에 따라 화면을 업데이트할 수 있음

import React, { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0); // 여기서 count가 메모리 역할

  return (
    <div>
      <p>현재 숫자: {count}</p>
      <button onClick={() => setCount(count + 1)}>증가</button>
    </div>
  );
}

count는 컴포넌트가 기억하고 있는 값
버튼 클릭 시 setCount로 값을 바꾸면,
리액트가 변경된 값으로 화면을 다시 그려줌

Props = 부모가 내려주는 값 (부모 = 상위컴포넌트)

Props는 컴포넌트가 부모로부터 받는 데이터
읽기 전용(Read-only)이어서, 자식 컴포넌트에서는 직접 바꿀 수 없음
화면에 데이터를 전달하거나, 컴포넌트 재사용 시 설정값을 넣을 때 사용

function Greeting({ name }) {
  return <h1>안녕하세요, {name}님!  </h1>;
}

function App() {
  return (
    <div>
      <Greeting name="콘솔로그" />
      <Greeting name="프론트엔드 개발자" />
    </div>
  );
}

부모(App)에서 name="콘솔로그"과 name="프론트엔드 개발자"를 자식(Greeting)에 전달
자식은 받은 값을 그대로 화면에 표시

State와 Props 차이

구분	State	Props
정의	컴포넌트 내부에서 관리하는 데이터	부모가 자식에게 전달하는 값
변경 가능	가능 (setState 사용)	불가능 (읽기 전용)
역할	UI가 동적으로 바뀔 때 사용	컴포넌트 설정/데이터 전달용

쉽게 비유하면:

State → “컴포넌트 안에서 마음대로 바꿀 수 있는 메모리”
Props → “부모가 준 선물 상자, 열어서 볼 수는 있지만 마음대로 바꿀 수는 없음”

App
├─ Counter(state: count=0)                       <-- state는 Counter에서 관리
└─ Greeting(state: name="콘솔로그")               <-- Greeting 자체 state
       └─ Profile(props: name="콘솔로그", state: age=25)  <-- Profile에서 age state 관리, 부모(Greeting)의 name을 props로 사용

Counter → 자체 count 상태 관리
Greeting → 자체 name 상태 관리
Profile → 부모(Greeting)로부터 받은 name을 props로 사용, 자체 age 상태 관리

리액트의 조건부로 렌더링

리액트는 앞서 설명했듯 SPA 기반이기 때문에, 조건부 렌더링을 활용해 효율적이고 부드러운 화면 업데이트를 제공합니다.

왜 리액트는 조건부로 렌더링할까요? 그 이유는 아래와 같습니다.

1️⃣ 성능 최적화

웹 앱에서 모든 상태 변화마다 전체 화면을 다시 그리면 느려집니다.
특히 SPA에서는 한 페이지 안에 여러 컴포넌트가 동시에 존재하기 때문에, 불필요하게 렌더링하면 속도 저하와 브라우저 과부하가 생길 수 있습니다.

예: 100개의 리스트 아이템이 있을 때,
하나의 아이템만 바뀌었는데 100개를 다 다시 그리면 비효율적입니다.

2️⃣ 필요한 부분만 업데이트

리액트는 Virtual DOM을 사용하여 실제 DOM과 비교(Diff)한 후,
변경된 부분만 실제 DOM에 반영합니다.
즉, 조건부 렌더링으로 UI의 필요한 부분만 업데이트되어 효율적입니다.

3️⃣ 상태와 데이터 기반 UI

리액트의 핵심 철학은 데이터가 UI를 결정한다(Data-driven UI) 입니다.
State, Props, Context 등의 값이 바뀔 때만 렌더링되므로,
화면과 데이터의 일관성을 유지할 수 있습니다.
불필요한 렌더링을 줄이고, 사용자가 보는 화면과 실제 데이터가 항상 일치하게 됩니다.

4️⃣ 사용자 경험 향상

필요한 부분만 빠르게 업데이트하므로, 화면 전환이 부드럽고 자연스러움
전체 페이지를 다시 불러오지 않아 몰입감 있는 UI 경험을 제공하며,
SPA 환경에서는 특히 중요한 요소입니다.

라이프사이클과 훅(Hooks)

리액트 컴포넌트는 생성되고, 업데이트되고, 삭제되는 생명주기(Lifecycle)를 가지고 있어요.
클래스형 컴포넌트에서는 componentDidMount, componentDidUpdate, componentWillUnmount 같은 메서드를 사용했지만,
함수형 컴포넌트에서는 Hooks를 사용합니다.

주요 훅 예시

useEffect: 컴포넌트가 생성, 업데이트, 삭제될 때 동작 정의
useMemo: 계산량이 많은 값이나 함수를 메모이제이션하여 불필요한 재계산 방지
useCallback: 함수 자체를 메모이제이션해서 자식 컴포넌트 불필요한 렌더링 방지

** 리액트에서 생명주기가 필요한 이유

리액트 컴포넌트는 단순히 한 번 그려지는 UI가 아니라, 동적으로 변화하는 화면을 만들기 위해 존재합니다.
따라서 컴포넌트가 생성되고, 업데이트되고, 사라지는 과정마다 특정 작업을 처리할 필요가 있어요.

요약하면, 생명주기가 필요한 이유는:

초기화 작업: 컴포넌트가 생성될 때 필요한 작업 수행
업데이트 작업: 상태/데이터 변경에 따라 작업 수행
정리 작업: 컴포넌트 제거 시 리소스 정리

즉, 생명주기는 컴포넌트의 “생성과 관리, 종료”를 체계적으로 다루기 위해 필요합니다.
SPA 환경에서 수많은 컴포넌트가 동시에 존재할 때, 리소스 누수 없이 효율적으로 동작하게 만드는 핵심 개념이에요.

조건부 렌더링 확장

리액트에서 조건부 렌더링은 UI를 필요한 상황에서만 보여주는 기능이에요.
기본적인 삼항연산자 외에도 여러 방법이 있습니다.

const isLoggedIn = true;

return (
  <div>
    {/* 삼항연산자 */}
    {isLoggedIn ? <p>환영합니다!</p> : <p>로그인이 필요합니다.</p>}

    {/* && 연산자 */}
    {isLoggedIn && <button>로그아웃</button>}

    {/* switch 사용 */}
    {(() => {
      switch(status) {
        case "loading": return <p>로딩 중...</p>;
        case "error": return <p>에러 발생!</p>;
        default: return <p>데이터 준비 완료</p>;
      }
    })()}
  </div>
);

포인트:

조건부 렌더링으로 불필요한 요소 생성 방지 → 성능 개선
UI 흐름을 깔끔하게 유지 가능

컴포넌트 구조와 재사용

리액트의 핵심 장점 중 하나는 컴포넌트를 재사용 가능하게 구조화할 수 있다는 점이에요.

오늘은 리액트가 등장한 배경과 SPA, 그리고 리액트의 핵심 문법과 렌더링 원리에 대해 이야기해봤어요.
리액트는 단순히 인기 있는 라이브러리가 아니라, 복잡한 SPA 개발을 효율적으로 만들어주는 도구예요.

State와 Props를 통해 컴포넌트 단위로 데이터를 관리하고, 조건부 렌더링으로 필요한 부분만 업데이트할 수 있죠.
Hooks를 활용하면 함수형 컴포넌트에서도 생명주기 관리와 성능 최적화가 가능해요.

컴포넌트를 구조화하고 재사용하며, React.memo 같은 최적화를 적용하면 유지보수성과 성능까지 잡을 수 있습니다.
Virtual DOM 덕분에 화면 갱신이 효율적이고, 사용자 경험도 부드럽고 자연스럽게 만들어줍니다.

리액트를 이해하면 단순히 코드를 작성하는 수준을 넘어, 데이터와 UI를 어떻게 설계할지 감이 생깁니다.

처음에는 어렵게 느껴질 수 있지만, 차근차근 State, Props, 렌더링 원리부터 익히면 금방 익숙해져요.

리액트의 세계에 발을 들이면, 웹 개발이 훨씬 더 즐겁고 직관적으로 느껴질 거예요!

읽어보면 좋을 만한 참고 사이트

SPA 관련 정리 글 : https://www.elancer.co.kr/blog/detail/214

SPA란? 웹 개발 트렌드 SPA의 특징부터 구현 방법까지 모두 알려드립니다! I 이랜서 블로그

웹 페이지 로딩 속도를 향상시키고 트래픽을 줄여 부드러운 페이지 전환과 함께 업데이트가 될 때까지 기다리는 시간을 단축시켜 사용자로 하여금 높은 몰입도와 생동감을 선사하는 웹 페이지

www.elancer.co.kr

리액트 공식문서: https://ko.react.dev/

React

ko.react.dev

React 기초 및 TodoLIst: https://react.vlpt.us/

벨로퍼트와 함께하는 모던 리액트 · GitBook

벨로퍼트와 함께하는 모던 리액트 본 강의자료는 패스트캠퍼스 온라인 강의에서 제공하는 리액트 강의에서 사용되는 강의 문서입니다. 이 튜토리얼은 여러분들이 JavaScript 의 기초를 잘 알고있

react.vlpt.us

React 따라해보기: https://nomadcoders.co/react-for-beginners

React 리액트 무료 강의: 영화 웹 서비스 만들기 (56,000명 수강 중)

리액트의 기본기를 쉽고 실습 위주로 배워보세요. JSX, State, Props, 컴포넌트, 데이터 가져오기, 라우팅 등 핵심 개념을 익히고, 직접 영화 웹 서비스를 만들어보며 실전 경험을 쌓을 수 있습니다. 5

nomadcoders.co

[개발읽기 vol.8] Zustand: 최소한의 코드로 최대한의 상태관리

콘솔로그 — Fri, 12 Sep 2025 12:55:52 +0900

오늘은 상태관리 라이브러리인 Zustand에 대해 이야기해보려고 합니다.

저희 회사에서는 따로 상태관리 라이브러리를 쓰지 않고 있어서, 실무에서 직접적으로 다룰 기회는 거의 없었어요.
그런데 최근 채용 공고를 살펴보다 보면, 대부분의 회사들이 상태관리 경험을 중요하게 보는 경우가 많더라구요.
특히 Redux, Recoil, Zustand 같은 키워드가 빠지지 않고 등장하는 걸 보면서 ‘나도 한번 제대로 공부해봐야겠다’는 생각이 들었습니다.
그래서 이번 기회에 Zustand를 직접 써보고, 기존에 많이 사용되는 Redux와는 어떻게 다른지 비교도 해봤어요.
생각보다 진입 장벽이 낮고, 코드가 간결해서 개인적으로는 꽤 만족스러웠는데요.

npm trend 사이트에서 보면,

최근에 Zustand의 사용량이 급격히 증가한 것을 확인할 수 있습니다.
현재는 Redux 다음으로 많이 사용되고 있는데,
기존에 대부분의 개발자들이 Redux를 주로 활용해왔다는 점을 고려하면 이 추세가 정말 인상적이라고 볼 수 있습니다.

또한 패키지 사이즈 측면에서도 정말 매력적인데요.

Zustand는 다른 상태관리 라이브러리에 비해 굉장히 가벼운 편이라 번들 크기에 거의 부담을 주지 않습니다.

실제로 설치해보면 "이게 진짜 상태관리 라이브러리 맞아?" 싶을 정도로 크기가 작아서,
프로젝트 성능 최적화를 신경 쓰는 분들에게 특히 매력적으로 다가옵니다.

사용 방법도 놀라울 만큼 간단합니다.

Zustand 공식 홈페이지에 들어가면 처음에 딱 보이는 코드 예제가 있는데,
처음 보면 “어..? 이거면 진짜 끝이야?” 싶을 정도로 간단하더라구요.

복잡한 설정이나 보일러플레이트 코드가 필요 없고, 그냥 몇 줄만 작성하면 바로 상태관리를 시작할 수 있습니다.
덕분에 처음 접하는 사람도 금방 이해할 수 있고,
Redux처럼 설정 단계에서부터 부담을 느낄 필요가 없다는 게 큰 장점이에요.

이 글에서는 Zustand의 특징과 사용법, 그리고 써보면서 느낀 장단점까지 솔직하게 정리해보려고 합니다.

Zustand 말고도 상태관리 라이브러리도 사실 꽤 많은 편인데요, 이번 포스팅에서는 zustand를 자세히 살펴보려고 해요.

다른 상태관리가 궁금하시다면 이전에 제가 정리해둔 포스트가 있으니 궁금하신 분들은 아래 글을 참고해주시면 좋을 것 같아요.

https://jjung2ing.tistory.com/81

[개발읽기 vol.5] 2025년 리액트 상태관리 가이드: Redux, Recoil, Zustand, Jotai, MobX 비교

요즘 채용 공고를 보면,자격요건이나 우대사항에 꼭 한 번쯤은 Redux, Zustand, MobX 같은 상태관리 라이브러리 이름이 등장합니다. 그만큼 리액트에서 상태관리를 어떻게 하느냐가 실무에서 중요한

jjung2ing.tistory.com

그리고 아마 "그럼 상태관리 라이브러리가 왜 필요하지?"라는 궁금증이 생기실 수도 있을 것 같아요.

그 이유는 기존 React의 상태 관리 방식 때문입니다.

React에서는 상태가 단방향으로만 흐르기 때문에, 다른 컴포넌트나 페이지와 상태를 공유하려면
상태를 상위 컴포넌트로 끌어올린 뒤 다시 하위 컴포넌트로 내려주는 방식으로 관리해야 하죠.

문제는 이 과정에서 끝도 없이 상태를 내려줘야 하는 이른바 Props Drilling 현상이 발생한다는 점입니다.

쉽게 비유하자면, 위쪽에서 물통을 받아 아래로 계속 전달해야 하는 상황과 비슷합니다.
중간에 하나라도 놓치면 물이 새듯, 상태를 잘못 전달하면 오류가 생기고, 코드는 점점 복잡해지며 유지보수에도 큰 부담을 주게 됩니다.

PropsDrilling

중첩된 컴포넌트간 상태고유를 위해 Props를 전달하는 과정에서 Props 전달이 드릴로 땅을 뚫듯 깊어지는 현상으로

유지보수가 어렵습니다.

중간에 props를 받기만 하는 컴포넌트가 많아지면 코드가 길어지고, 어떤 데이터가 어디서 왔는지 추적하기 어려워집니다.
예: App → A → B → C → D 구조에서 D에만 필요한 데이터라면 A, B, C는 단순 전달자 역할만 하게 됩니다.

컴포넌트 재사용성 감소

중간 컴포넌트들이 특정 props를 받아야 하므로, 재사용할 때 불필요한 props를 계속 전달해야 할 수도 있습니다.

리렌더링 문제

부모 컴포넌트가 리렌더링되면, props를 받는 모든 중간 컴포넌트가 함께 리렌더링될 수 있습니다.
성능 저하로 이어질 수 있습니다.

코드 가독성 저하

많은 계층을 거쳐 props가 전달되면 코드가 장황해지고, 데이터를 이해하고 수정하기 어려워집니다.

그럼 여기서 Zustand가 어떻게 Props Drilling 문제를 해결하는지 이야기해볼게요.

Zustand를 사용하면 상태를 중앙 저장소(store)에 보관할 수 있어서, 상위 컴포넌트로 끌어올리거나 하위로 내려줄 필요가 없습니다.

필요한 컴포넌트는 그냥 store에서 상태를 가져다 쓰면 되죠.

즉, 상태를 어디서든 쉽게 공유할 수 있고, 전달 과정에서 생기는 오류나 복잡함이 사라집니다.

게다가 Zustand는 사용법이 매우 간단합니다.
몇 줄의 코드로 store를 만들고, 원하는 컴포넌트에서 바로 상태를 읽거나 수정할 수 있죠.

Redux처럼 복잡한 액션, 리듀서, 미들웨어 설정이 필요 없어서, 작은 프로젝트나 개인 프로젝트에서도 부담 없이 바로 적용할 수 있습니다.

결과적으로 코드는 더 깔끔해지고 유지보수도 쉬워지며, 개발자가 상태 관리 때문에 고민할 시간도 줄일 수 있다는 장점이 있습니다.

Zustand

적은 보일러 플레이트 코드
직관적인 사용법
작은 패키지 사이즈
Flux처럼 단방향이지만 구조는 더 단순함

용어정리

보일러플레이트 코드(Boilerplate Code) : zustand는 보일러 플레이트 코드가 적다.

프로그램을 만들 때 반복적으로 꼭 작성해야 하는 기본 틀이나 코드를 말합니다.

예를 들어 Redux를 사용하면 상태를 관리하려고 할 때,

액션(action) 정의
리듀서(reducer) 작성
스토어(store) 설정
미들웨어(middleware) 적용

이런 과정들을 매번 비슷한 형태로 작성해야 하죠.

이처럼 실제 로직과 상관없이 구조상 꼭 필요한 반복 코드가 바로 보일러플레이트 코드입니다.

Flux 패턴 : zustand는 Flux패턴 처럼 단방향이지만 구조는 더 단순하다.

데이터를 중앙 집중형 스토어에 저장하고 Action을 통해 데이터를 조작하는 패턴

Flux 패턴은 React 생태계에서 많이 쓰이는 상태 관리 구조 중 하나로,
애플리케이션의 상태(state)를 단방향으로 흐르게 설계하는 아키텍처입니다.

기본 구조는 다음과 같이 이해하면 쉽습니다.

Action(액션)
- 상태를 변경하겠다는 의도를 담은 객체
- 예: ADD_TODO, REMOVE_ITEM
Dispatcher(디스패처)
- Action을 받아서 Store로 전달하는 역할
- 중앙 허브 역할을 수행
Store(스토어)
- 상태를 실제로 저장하고 관리
- 상태가 바뀌면 View에 알려서 화면을 갱신
View(뷰)
- Store의 상태를 기반으로 UI를 렌더링
- 사용자가 UI를 통해 Action을 발생시킬 수 있음

즉, Flux는 Action → Dispatcher → Store → View 순으로
데이터가 한 방향으로만 흐르도록 설계되어 있어,
상태 관리가 예측 가능하고 복잡한 상태 변화를 추적하기 쉬운 구조를 제공합니다.

이건 WOOWACON에서 나온 내용인데, 이해하기 쉽게 나와있어서 가져와봤습니다.

자, 이제 Zustand를 실제로 어떻게 사용하는지 보여드릴게요.

공식 홈페이지에도 자세한 예시가 나와 있으니 참고하시면 좋습니다.

https://zustand-demo.pmnd.rs/

Zustand

zustand-demo.pmnd.rs

하지만 여기서도 간단히 설명해드릴게요.

1️⃣ 설치 방법

Zustand는 NPM 패키지로 제공되기 때문에, 프로젝트에 바로 설치해서 사용할 수 있습니다.

# NPM
npm install zustand
# Or, use any package manager of your choice.

2️⃣ 먼저 스토어(Store)를 만들어주세요

Zustand에서는 스토어가 훅(Hook)입니다.
스토어 안에는 원시값, 객체, 함수 등 원하는 무엇이든 넣을 수 있고,
set 함수를 사용하면 상태를 쉽게 업데이트할 수 있습니다.

import { create } from 'zustand'

const useStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
  removeAllBears: () => set({ bears: 0 }),
  updateBears: (newBears) => set({ bears: newBears }),
}))

3️⃣ 컴포넌트에서 스토어 사용하기

스토어 훅을 어디서든 사용할 수 있으며, Provider를 따로 쓸 필요가 없습니다.
스토어에서 상태를 선택(select)하면, 해당 상태가 변경될 때 컴포넌트가 자동으로 리렌더링 됩니다.

function BearCounter() {
  const bears = useStore((state) => state.bears)
  return <h1>{bears} bears around here...</h1>
}

function Controls() {
  const increasePopulation = useStore((state) => state.increasePopulation)
  return <button onClick={increasePopulation}>one up</button>
}

이렇게만 해도 상태 관리가 끝!
간단하게 상태를 읽고 수정할 수 있으면서, 컴포넌트 간 공유도 아주 쉽게 할 수 있습니다.

비교: Zustand는 다른 상태관리 라이브러리와 어떻게 다른가?

Zustand는 React에서 사용할 수 있는 여러 상태관리 라이브러리 중 하나입니다.
이번 글에서는 Redux, Valtio, Jotai, Recoil 등과 비교하며 Zustand의 특징과 장단점을 살펴보겠습니다.

각 라이브러리는 저마다 장점과 단점이 있으며, 중요한 차이점과 공통점을 중심으로 비교합니다.

Redux와 비교

상태 모델(State Model)
개념적으로 Zustand와 Redux는 꽤 비슷합니다.
둘 다 불변(Immutable) 상태 모델을 기반으로 하고 있죠.
하지만 큰 차이점이 있습니다.
- Redux는 앱 전체를 Context Provider로 감싸야 하는 반면,
- Zustand는 이런 설정이 필요 없고, 스토어 훅을 바로 사용할 수 있습니다.

Zustand

import { create } from 'zustand'

type State = {
  count: number
}

type Actions = {
  increment: (qty: number) => void
  decrement: (qty: number) => void
}

const useCountStore = create<State & Actions>((set) => ({
  count: 0,
  increment: (qty: number) => set((state) => ({ count: state.count + qty })),
  decrement: (qty: number) => set((state) => ({ count: state.count - qty })),
}))

Zustand에서는 먼저 useCountStore라는 훅을 만들어 상태를 관리합니다.
이 스토어 안에는 count라는 상태와, 상태를 변경할 수 있는 increment와 decrement 같은 액션이 들어 있습니다.
상태를 업데이트할 때는 set 함수를 사용하면 되고, Redux처럼 별도의 리듀서나 미들웨어를 만들 필요 없이
단 몇 줄만으로 상태와 액션을 정의할 수 있어서 코드가 훨씬 간결합니다.

import { create } from 'zustand'

type State = {
  count: number
}

type Actions = {
  increment: (qty: number) => void
  decrement: (qty: number) => void
}

type Action = {
  type: keyof Actions
  qty: number
}

const countReducer = (state: State, action: Action) => {
  switch (action.type) {
    case 'increment':
      return { count: state.count + action.qty }
    case 'decrement':
      return { count: state.count - action.qty }
    default:
      return state
  }
}

const useCountStore = create<State & Actions>((set) => ({
  count: 0,
  dispatch: (action: Action) => set((state) => countReducer(state, action)),
}))

Zustand에서는 필요하다면 Redux처럼 리듀서 패턴도 적용할 수 있습니다.
이 경우, dispatch 함수를 통해 상태를 업데이트하며, 액션 타입과 상태를 변경하는 로직을 분리할 수 있죠.
즉, 구조는 Redux와 비슷하지만, 여전히 Provider 없이 훅만으로 바로 사용할 수 있다는 점이 큰 장점입니다.

Redux

import { createStore } from 'redux'
import { useSelector, useDispatch } from 'react-redux'

type State = {
  count: number
}

type Action = {
  type: 'increment' | 'decrement'
  qty: number
}

const countReducer = (state: State, action: Action) => {
  switch (action.type) {
    case 'increment':
      return { count: state.count + action.qty }
    case 'decrement':
      return { count: state.count - action.qty }
    default:
      return state
  }
}

const countStore = createStore(countReducer)

Redux는 상태 관리 구조가 Store와 Reducer로 명확하게 나뉘어 있습니다.
하지만 React에서 사용하려면 반드시 <Provider store={countStore}>로 앱 전체를 감싸야 합니다.
상태를 변경하려면 항상 dispatch를 통해서만 가능하며,
전체적으로 코드가 길고 반복되는 부분, 즉 boilerplate 코드가 많다는 단점이 있습니다.

import { createSlice, configureStore } from '@reduxjs/toolkit'

const countSlice = createSlice({
  name: 'count',
  initialState: { value: 0 },
  reducers: {
    incremented: (state, qty: number) => {
      // Redux Toolkit does not mutate the state, it uses the Immer library
      // behind scenes, allowing us to have something called "draft state".
      state.value += qty
    },
    decremented: (state, qty: number) => {
      state.value -= qty
    },
  },
})

const countStore = configureStore({ reducer: countSlice.reducer })

Redux Toolkit은 Redux를 더 쉽게 사용할 수 있도록 만든 라이브러리입니다.
내부적으로 Immer 라이브러리를 사용하기 때문에, state.value += qty처럼 마치 상태를 직접 수정하는 것처럼 코드를 작성할 수 있습니다.
덕분에 반복되는 코드가 줄어들고, 타입스크립트와도 자연스럽게 통합되어 코드가 더 깔끔하고 가독성이 좋아집니다.

⚡ 렌더링 최적화(Render Optimization) – Redux와 비교

앱 내에서 렌더링 최적화를 고려할 때, Zustand와 Redux 간의 접근 방식에는 큰 차이가 없습니다.
두 라이브러리 모두 선택자(Selector)를 활용해 필요한 상태만 선택하고,
컴포넌트가 불필요하게 리렌더링되지 않도록 최적화를 적용하는 것이 권장됩니다.

즉, 상태 관리 라이브러리를 선택하더라도,
렌더링 성능을 높이려면 개발자가 직접 최적화를 신경 써야 한다는 점은 동일합니다.

Zustand

import { create } from 'zustand'

type State = {
  count: number
}

type Actions = {
  increment: (qty: number) => void
  decrement: (qty: number) => void
}

const useCountStore = create<State & Actions>((set) => ({
  count: 0,
  increment: (qty: number) => set((state) => ({ count: state.count + qty })),
  decrement: (qty: number) => set((state) => ({ count: state.count - qty })),
}))

const Component = () => {
  const count = useCountStore((state) => state.count)
  const increment = useCountStore((state) => state.increment)
  const decrement = useCountStore((state) => state.decrement)
  // ...
}

이 예제에서는 useCountStore라는 Zustand 스토어를 만들어 count 상태와 상태를 변경하는 함수들을 정의하고 있습니다.

count라는 상태를 0으로 초기화하고,
increment와 decrement라는 액션을 만들어 set 함수를 사용해 상태를 업데이트하도록 했습니다.

컴포넌트에서는 이 스토어 훅을 사용해 상태와 액션을 가져올 수 있습니다.

const count = useCountStore((state) => state.count)
const increment = useCountStore((state) => state.increment)
const decrement = useCountStore((state) => state.decrement)

즉, 필요한 상태나 액션만 선택해서 사용할 수 있고, 상태가 바뀌면 자동으로 해당 컴포넌트가 리렌더링됩니다.

이 방식의 장점은 Provider가 필요 없고, Redux처럼 복잡한 설정 없이 훅 하나로 상태 관리가 가능하다는 점입니다.
또한, 액션과 상태를 한 곳에서 정의할 수 있어 코드가 직관적이고 간결합니다.

Redux

import { createStore } from 'redux'
import { useSelector, useDispatch } from 'react-redux'

type State = {
  count: number
}

type Action = {
  type: 'increment' | 'decrement'
  qty: number
}

const countReducer = (state: State, action: Action) => {
  switch (action.type) {
    case 'increment':
      return { count: state.count + action.qty }
    case 'decrement':
      return { count: state.count - action.qty }
    default:
      return state
  }
}

const countStore = createStore(countReducer)

const Component = () => {
  const count = useSelector((state) => state.count)
  const dispatch = useDispatch()
  // ...
}

먼저 countReducer라는 리듀서 함수를 정의합니다.

상태 count를 가지고 있고,
액션 타입이 'increment'일 경우 count를 증가시키고,
'decrement'일 경우 count를 감소시킵니다.
그 외의 액션은 그대로 상태를 반환합니다.

const countStore = createStore(countReducer)

이렇게 리듀서를 전달해 스토어(Store)를 생성합니다.

Redux에서는 이 스토어를 앱 전체에 제공하기 위해 <Provider store={countStore}>로 감싸야 합니다.

컴포넌트에서는

const count = useSelector((state) => state.count)
const dispatch = useDispatch()

useSelector를 사용해 상태를 읽고,
useDispatch를 사용해 액션을 보내 상태를 업데이트합니다.

즉, Redux는 상태와 액션 관리가 명확하고 예측 가능하지만,

스토어와 Provider 설정, dispatch를 통한 상태 변경 등 코드가 상대적으로 길고 구조가 복잡하다는 특징이 있습니다.

import { useSelector } from 'react-redux'
import type { TypedUseSelectorHook } from 'react-redux'
import { createSlice, configureStore } from '@reduxjs/toolkit'

const countSlice = createSlice({
  name: 'count',
  initialState: { value: 0 },
  reducers: {
    incremented: (state, qty: number) => {
      // Redux Toolkit does not mutate the state, it uses the Immer library
      // behind scenes, allowing us to have something called "draft state".
      state.value += qty
    },
    decremented: (state, qty: number) => {
      state.value -= qty
    },
  },
})

const countStore = configureStore({ reducer: countSlice.reducer })

const useAppSelector: TypedUseSelectorHook<typeof countStore.getState> =
  useSelector

const useAppDispatch: () => typeof countStore.dispatch = useDispatch

const Component = () => {
  const count = useAppSelector((state) => state.count.value)
  const dispatch = useAppDispatch()
  // ...
}

먼저 createSlice를 이용해 상태와 액션을 한 번에 정의합니다.

countSlice 안에는 상태 value가 있고,
incremented와 decremented라는 액션이 정의되어 있습니다.
Redux Toolkit은 내부적으로 Immer 라이브러리를 사용하기 때문에, state.value += qty처럼 마치 상태를 직접 변경하는 것처럼 작성해도 실제로는 불변성을 유지합니다.

const countStore = configureStore({ reducer: countSlice.reducer })

이렇게 스토어를 설정하고, 앱 전체에서 사용할 수 있도록 제공합니다.

컴포넌트에서는

const count = useAppSelector((state) => state.count.value)
const dispatch = useAppDispatch()

useAppSelector를 통해 상태를 읽고,
useAppDispatch로 액션을 디스패치해 상태를 업데이트합니다.

즉, Redux Toolkit은 기존 Redux보다 훨씬 간단하게 상태와 액션을 정의할 수 있고,

불변성을 직접 관리할 필요가 없어 코드를 더 깔끔하게 작성할 수 있다는 장점이 있습니다.

✅ 정리

Zustand: 간단하고 직관적, 소규모/중규모 프로젝트에 적합
Redux: 구조가 명확하고 예측 가능, 대규모 프로젝트에 유리하지만 boilerplate가 많음
Redux Toolkit: Redux의 장점은 유지하면서 코드를 간결하게, Immer로 상태 변경이 편리

간단히 코드를 비교해 보자면,

⚠️ 상태관리 라이브러리는 무조건 써야 할까?

답변:
무조건 사용할 필요는 없습니다. 상태관리 라이브러리는 프로젝트 규모와 복잡도에 따라 선택하면 돼요.

라이브러리가 필요할 때

여러 컴포넌트에서 같은 상태를 공유해야 할 때
상태 변화가 많고 복잡한 로직이 포함될 때
Props Drilling이 많아져 유지보수가 어려울 때
상태를 예측 가능하게 관리하고 싶을 때

⚡ 라이브러리가 필요 없을 때

상태 공유가 거의 없고 컴포넌트 내부 상태만 사용하는 작은 프로젝트
상태 변화가 단순해서 React의 useState나 useReducer만으로 충분할 때

✅ 정리

상태관리 라이브러리는 규모가 크거나 상태가 복잡한 앱에서 유용하지만,
작거나 단순한 프로젝트에서는 오히려 불필요한 학습과 코드 복잡도를 늘릴 수 있습니다.

실전에서 상태관리 라이브러리, 언제 쓰고 안 쓰나?

1️⃣ 사용하면 좋은 경우

앱 규모가 크고 여러 페이지나 컴포넌트에서 같은 상태를 공유해야 할 때
→ 예: 사용자 로그인 정보, 장바구니, 테마 설정 등
상태 변화가 많거나 복잡한 로직이 포함된 경우
→ 예: 계산 로직, 필터/정렬 기능, 동시성 상태 관리
Props Drilling이 발생해 상위에서 하위로 상태를 계속 내려야 하는 구조가 반복될 때
상태를 예측 가능하게 관리하고 싶을 때
→ 팀 협업 시 버그 방지와 유지보수 용이

2️⃣ 사용하지 않아도 되는 경우

상태 공유가 거의 없고 컴포넌트 자체 상태만 사용하는 작은 프로젝트
→ 예: 단순 토글 버튼, 입력 폼, 작은 위젯
상태 변화가 단순해서 React의 useState나 useReducer로 충분할 때
라이브러리를 도입할 만큼 복잡도가 크지 않은 경우

오늘은 React 상태관리 라이브러리 중 Zustand, Redux, Redux Toolkit을 비교하며 살펴봤습니다.
각 라이브러리마다 장점과 단점이 명확하고, 사용 용도에 따라 적합한 선택이 달라집니다.
작고 단순한 프로젝트에서는 굳이 라이브러리를 도입하지 않아도 충분히 상태를 관리할 수 있고,
오히려 코드를 더 간결하게 유지할 수 있다는것을 알게되었습니다.

반대로 여러 컴포넌트가 상태를 공유하거나, 상태 변화가 복잡한 프로젝트에서는
Zustand처럼 직관적인 라이브러리나 Redux/Redux Toolkit을 활용하면 코드 유지보수가 훨씬 편리해짐을 알게 되었습니다.

Props Drilling을 피하고, 상태를 예측 가능하게 관리할 수 있다는 점도 큰 장점입니다.

상태관리 라이브러리는 도구일 뿐이며, 항상 프로젝트의 규모와 복잡도를 고려해서 선택하는 것이 중요합니다.
처음에는 작은 프로젝트에서 React 내장 훅으로 시작해보고, 필요할 때 점차 라이브러리를 도입하는 전략도 좋습니다.

오늘 소개한 내용이 상태관리 선택에 조금이라도 도움이 되었기를 바라며,
나중에는 실제 프로젝트에서 Zustand를 적용한 실전 예제와 팁을 공유해보겠습니다!

[전시 / 축제] 서울 5대 궁궐에서 만나는 2025 궁중문화축전 가이드

콘솔로그 — Thu, 11 Sep 2025 13:48:25 +0900

오늘, 궁을 만나다

‘궁중문화축전’은 대한민국을 대표하는 문화유산이며 조선과 대한제국의 역사를 품고 있는 경복궁, 창덕궁, 창경궁, 덕수궁, 경희궁 등 서울 소재 5개의 궁궐과 종묘에서 펼쳐지는 문화유산 축제입니다.

국가유산청이 주최하고 국가유산진흥원이 주관하는 궁중문화축전에서는 내·외국인에게 ‘오늘, 궁을 만나다’라는 취지에 어울리는 다양한 프로그램이 펼쳐집니다. 봄과 가을에 궁궐의 역사를 담고 있으면서 각각의 궁궐 전각과 장소의 특성을 반영한 공연, 전시, 체험, 의례 재현 등의 문화, 예술프로그램을 제공하고 있습니다.

궁중문화축전은 궁을 사랑하는 많은 분들이 직접 축전의 주인공이 되고, 더 많은 분이 궁의 매력을 느낄 수 있도록 노력을 다하고 있습니다. 이와 함께 궁중문화축전은 한국을 방문한 외국인에게 품위 있고 흥미로운 역사, 문화 프로그램에 참여하는 기회를 제공함으로써 한국 문화유산과 한국의 문화 역량을 대외적으로 널리 알리는 특별한 장이 될 것입니다.

저도 작년부터 열심히 참여하고 있는데요. 무료 체험도 있고 유료 체험도 있지만, 어떤 프로그램을 선택해도 그 가격이 전혀 아깝지 않을 만큼 만족스러운 행사였어요.
특별한 경험과 잊지 못할 추억을 만들고 싶으신 분들께 강력히 추천드려요!

어떤 프로그램이 있는지 미리 알아야 제대로 즐길 수 있겠죠?
2025 궁중문화축전 공식 페이지에서 확인할 수 있지만, 조금 번거로우실 수 있으니 제가 바로 정리해드릴게요.

홈페이지에서 보시려면 여기로 들어가시면 됩니다.

https://www.kh.or.kr/cms/content/view/1532

궁중문화축전

매년 봄과 가을 5대궁과 종묘·사직단에서 펼쳐지는 국내최대 문화유산축제

www.kh.or.kr

궁중문화축전을 즐기기 위해서는 티켓이 필요하겠죠?
예약 방법도 간단하니 미리 준비하시면 더 편하게 즐길 수 있어요.

티켓 예매 사이트 : 티켓링크 (https://www.ticketlink.co.kr/bridge/1378)

2025년 가을 궁중문화축전 프로그램 예매 정보

궁중문화축전 특별 굿즈 <궁패스 노리개>
- 오픈일정: 2025.09.11 12:00
- 예매마감: 2025.10.12 17:00
- 취소마감: 2025.10.07 17:00
- 구매수량: 1인 당 최대 4매
<경복궁 한복연향>
- 오픈일정: 2025.09.11 12:00
- 예매마감: 관람일 전일 17:00
- 취소마감: 관람일 전일 17:00
- 구매수량: 1인 당 최대 4매
<덕수궁 인문학 콘서트>
- 오픈일정: 2025.09.11 14:00
- 예매마감: 관람일 전일 17:00
- 취소마감: 관람일 전일 17:00
- 구매수량: 1인 당 최대 4매
<아침 궁을 깨우다>
- 오픈일정: 2025.09.11 14:00
- 예매마감: 관람일 전일 13:00
- 취소마감: 관람일 전일 12:00
- 구매수량: 1인 당 최대 2매
<준명당 어린이 학교>
- 오픈일정: 2025.09.11 14:00
- 예매마감: 관람일 전일 17:00
- 취소마감: 관람일 전일 17:00
- 구매수량: 1인 당 최대 2매
<동궐 장원서>
- 오픈일정: 2025.09.11 15:00
- 예매마감: 관람일 전일 17:00
- 취소마감: 관람일 전일 17:00
- 구매수량: 1인 당 최대 4매
<조선의 밤, 하늘과 바람>
- 오픈일정: 2025.09.11 15:00
- 예매마감: 관람일 전일 17:00
- 취소마감: 관람일 전일 17:00
- 구매수량: 1인 당 최대 2매
<종묘 인문학 콘서트>
- 오픈일정: 2025.09.11 16:00
- 예매마감: 관람일 전일 17:00
- 취소마감: 관람일 전일 17:00
- 구매수량: 1인 당 최대 4매
<종묘 건축 탐험대>
- 오픈일정: 2025.09.11 16:00
- 예매마감: 관람일 전일 17:00
- 취소마감: 관람일 전일 17:00
- 구매수량: 1인 당 최대 2매

선선한 가을, 가족과 연인, 친구들과 함께 특별한 추억을 남기고 싶다면
2025 궁중문화축전을 강력히 추천드려요.

다양한 궁중 체험과 전통 공연, 역사 투어까지
모두가 즐겁게 참여할 수 있는 프로그램이 가득하답니다.

저도 오늘 궁패스 티켓팅에 도전해봤는데, 생각보다 금방 매진되더라고요!

모두들 서둘러 예매하시고, 원하는 프로그램 꼭 즐기시길 바라며
화이팅입니다!

[여행 로그] 평화누리 캠핑장 이용 후기와 예약 방법 총정리 2편

콘솔로그 — Thu, 11 Sep 2025 13:31:33 +0900

저번 포스팅에서는 평화누리 캠핑장의 예약 방법과 기본적인 정보를 알려드렸었죠! ️
이번에는 드디어 실제로 다녀온 생생한 캠핑장 이용 후기를 전해드리려고 합니다. ✨
예약만으로는 알 수 없었던 현장 분위기, 시설 이용 팁, 그리고 제가 직접 겪은 에피소드까지 담아왔어요.

특히 초보 캠퍼분들이 가장 궁금해하실 부분들을 중심으로 솔직하게 작성해봤습니다.
그럼 지금부터 제가 다녀온 평화누리 캠핑장의 하루를 함께 보실까요?

캠핑장 입구 & 체크인

캠핑장 입구에 들어서면 가장 먼저 차단기가 보입니다. 미리 차량 정보를 입력해두셨다면 자동으로 열리지만, 혹시 열리지 않더라도 당황하지 마세요! 좌측 차단기에 있는 호출 버튼 을 눌러 “캠핑장 예약자입니다”라고 말씀하시면 바로 열어주십니다.
차단기가 열리면 그 앞에 차를 잠시 세우고 좌측에 있는 **웰컴센터(관리동)**로 가셔서 예약 내역과 신분증을 보여주시면 체크인이 완료됩니다. 저희는 카키색 박스를 받았는데, 그 안에는 TV 리모콘, 에어컨 리모콘, 드라이기, 카라반 안내서가 들어있었어요. 특히 안내서에는 외부 화장실 비밀번호와 카라반 비밀번호가 적혀 있으니 절대 잃어버리시면 안 됩니다!

아래 사진에서 보이는 곳은 바로 텐트존⛺ 이에요!

실제로 이곳에서 1박을 즐기시는 분들도 꽤 많더라구요.

불빛 아래서 텐트가 줄지어 있는 모습이 캠핑 분위기를 한층 더 살려주는 것 같았습니다. ✨

카라반도 좋지만, 다음에는 꼭 이 텐트존에서 하루 묵어보면서 또 다른 매력을 느껴보고 싶어요.

️ Z존 카라반 입장

저희는 Z존을 예약했는데요, 진입은 웰컴센터 바로 우측 길로만 가능합니다. 직진하시면 안 돼요!
짐을 옮기고 난 뒤에는 차량을 반드시 캠핑존 외부 주차장에 주차하셔야 합니다.

카라반 문은 키패드 방식 이라 비밀번호 입력 후 “열림(자물쇠 열림)” 버튼을 누르면 지잉~ 소리가 나면서 열려요.

처음엔 조금 헷갈려서 고생했지만, 익숙해지면 괜찮습니다. (괜찮다고 했지만 버벅거리다 웰컴센터가서 다시 배워온 1인)

문을 잠그고 싶으실 때는 “잠김” 버튼이나 내부의 주황색 고리 를 이용하면 안전하게 닫을 수 있어요.

️ 카라반 내부 소개

카라반 안은 생각보다 넓어서 4명이 사용해도 전혀 좁지 않았습니다.

오른쪽: 2인용 침대 ️, TV , 화장대, 옷장
중앙: 4인용 테이블, 인덕션 , 싱크대, 냉장고, 밥솥, 전자레인지, 커피포트 ☕
왼쪽: 2층 침대 화장실도 깔끔하고 크기가 넉넉해서 샤워하기에 불편함이 전혀 없었어요.

카라반 안의 2인용 침대는 성인 두 명이 함께 자기엔 약간 차렷 자세(?)로 바르게 누워야 하는 크기였습니다.

하지만 답답할 정도는 아니었고, 오히려 아늑한 느낌이 들었어요.

저는 개인적으로 너무 푹 꺼지는 매트리스보다는 단단한 매트리스를 좋아하는 편인데, 이곳 침대는 푹신하지 않고 적당히 단단해서 제 취향에 딱 맞았습니다.

카라반 안에 있는 TV는 채널도 꽤 다양해서 볼 거리가 많았습니다.
특히 각도를 자유롭게 돌릴 수 있는 구조라서, 테이블에 앉아 식사하면서 보기도 좋고 침대에 누워서 편하게 시청하기도 딱이었어요. ️✨
작은 디테일이지만 캠핑의 만족도를 확 올려주는 요소 중 하나였습니다.

카라반 안에는 낭만 가득한 2층 침대도 마련되어 있었는데요, 아늑하고 포근한 분위기라 아이들이 특히 좋아할 것 같았어요. ✨
제가 앉아 있을 때는 허리나 목을 구부리지 않아도 될 정도의 높이라 편안했습니다.

다만, 키가 크신 분들은 앉으실 경우 살짝 몸을 숙이셔야 할 수도 있어요. 그래도 누웠을 때는 충분히 넉넉하고 아늑해서 캠핑 감성 제대로 느낄 수 있었습니다.

캠핑장 화장실도 직접 이용해봤는데, 생각보다 훨씬 깔끔했습니다. ✨
특히 샤워기 수압이 세서 씻는 데 전혀 불편함이 없었고, 따뜻한 물도 콸콸 잘 나와서 캠핑장에서 흔히 겪는 불편함이 전혀 없었어요.
이 부분은 정말 만족스러워서, 캠핑 끝나고 상쾌하게 마무리할 수 있었습니다.

카라반 내 수건은 보관함 안에 구비되어 있어 따로 챙기지 않아도 됩니다. ✅
다만 샴푸, 바디워시 등 세면 용품은 제공되지 않으니 꼭 개인적으로 준비해가셔야 해요.
사소하지만 미리 챙기면 캠핑 첫날부터 편하게 이용할 수 있습니다.

카라반 내부에 다른 기구들도 많이 있어서 좋았습니다.

커피포트 밥솥 전자렌지 냉장고 등이 있어 밥 해먹기도 편리했어요카라반 안에는 생활에 필요한 기구들이 알차게 갖춰져 있어서 정말 편리했습니다.

커피포트 ☕, 밥솥 , 전자레인지, 냉장고 ❄️ 등이 구비되어 있어서 간단한 요리나 식사를 해먹기에도 전혀 불편함이 없었어요.
캠핑을 오면 가끔 조리 도구가 부족해서 곤란할 때가 있는데, 평화누리 카라반은 그런 부분이 잘 준비되어 있어 초보 캠퍼도 안심하고 사용할 수 있었습니다.

카라반 내부를 둘러보니 군데군데 콘센트가 곳곳에 배치되어 있었습니다.

덕분에 휴대폰이나 노트북을 충전하기에도 편리했고 ,

전자제품을 사용할 때도 자리를 옮기지 않고 바로 연결할 수 있어 아주 유용했어요.

사소한 부분 같지만, 이런 디테일 덕분에 캠핑이 훨씬 더 쾌적하게 느껴졌습니다. ✨

카라반 안에는 에어컨이 완비되어 있어, 더운 여름이나 추운 겨울에도 쾌적하게 캠핑을 즐길 수 있었습니다. ️
또한, 테이블에 비치된 태블릿 을 통해 필요한 도구를 요청하면,

정해진 시간에 맞춰 카라반까지 직접 가져다주는 서비스도 제공되더라구요.
캠핑용품을 일일이 들고 다닐 필요가 없어 편리했고, 초보 캠퍼에게 특히 큰 장점이었습니다. ✨

특별했던 포인트

카라반 출입문에는 방충망 전용 문이 설치되어 있어요. 문을 열고 방충망만 닫아두면 바깥 풍경이 시원하게 들어와 개방감이 아주 좋았습니다. 저희는 Z15번 카라반을 이용했는데, 문 옆이 확 트여 있어서 전망도 좋고 웰컴센터와도 가까워서 정말 만족스러웠어요. “다음에 다시 오게 된다면 꼭 Z15로 예약해야겠다!”라는 생각이 들 정도였습니다.

카라반 옆 타프존

카라반 옆에는 마치 타프존처럼 천막 ⛺이 설치되어 있어서 그 안에서 고기를 구워 먹기 딱 좋았습니다.

불판 올려놓고 고기 구우니 정말 캠핑 분위기가 제대로 나더라구요!
무엇보다 천막이 햇빛과 비를 가려주기 때문에 날씨에 크게 구애받지 않고 식사와 휴식을 즐길 수 있었어요. ️

여름철 물놀이

또 여름 시즌라서 카라반 옆에 간이 수영장 도 설치되어있더라구요. 추가 비용을 내면 아이들이 마음껏 물놀이를 즐길 수 있어서, 가족 단위 캠퍼분들에게는 정말 좋은 선택지가 될 것 같았습니다. 아이들이 신나게 노는 동안 어른들은 옆 타프존에서 여유롭게 바비큐 파티~ 상상만 해도 너무 즐겁지 않나요?

전체적으로 캠핑장과 카라반 시설이 정말 잘 갖춰져 있어서 만족도가 높았습니다. ✨
초보 캠퍼인 저희도 큰 걱정 없이 편안하게 캠핑을 즐길 수 있었어요. ️
카라반 내부도 넓고 아늑해서 4명이서 사용해도 불편함이 없었고,
부대시설과 편의시설 덕분에 준비물 없이 가볍게 와도 충분히 즐길 수 있었습니다. ️

특히 에어컨과 다양한 주방 기구, 태블릿 주문 서비스 덕분에 실내에서도 편안하게 시간을 보낼 수 있었어요. ❄️
타프존과 주변 풍경도 좋아서 바비큐 파티 분위기가 최고였습니다.
저녁에는 조용하고 평화로운 분위기 덕분에 잘 쉬었고,

다음 날 아침에는 상쾌한 공기를 마시며 캠핑장 주변을 산책했는데 정말 힐링 그 자체였습니다.
햇살과 바람, 자연의 소리를 느끼면서 걷다 보니 마음까지 가벼워지는 기분이었어요. ☀️
이번 캠핑은 기대 이상으로 즐거웠고, 다음에도 꼭 다시 방문하고 싶은 캠핑장으로 기억될 것 같습니다.

[여행 로그] 평화누리 캠핑장 이용 후기와 예약 방법 총정리 1편

콘솔로그 — Wed, 10 Sep 2025 14:14:28 +0900

2025.09.07

9월 초, 아침저녁으로 선선한 바람이 불어 캠핑하기 딱 좋은 계절이에요.
주말마다 답답한 도심을 벗어나 자연 속에서 힐링하고 싶다는 생각이 점점 커지더라고요.
사실 저는 캠핑 초보라서 지난번에는 오토캠핑장을 예약했는데,
텐트 설치부터 장비 챙기기까지 혼자 하려니 생각보다 너무 힘들었어요.

그래서 이번에는 조금 편하게 캠핑을 즐기고 싶어서 카라반을 예약했습니다.
평화누리 캠핑장은 넓은 잔디와 잘 정비된 시설 덕분에 초보자도 부담 없이 즐길 수 있다고 하더라고요.
특히 9월의 선선한 날씨 덕분에 캠핑장 주변 산책도, 바람 맞으며 쉬는 것도 정말 상쾌했어요.
카라반 안은 깔끔하게 준비되어 있어서 짐만 들고 와도 바로 캠핑을 시작할 수 있었습니다.
이번 글에서는 캠핑 초보인 제가 경험한 평화누리 캠핑장 카라반 이용 후기와 꿀팁을 자세히 공유하려고 합니다.
편안하고 즐거운 캠핑을 계획 중이라면, 이 글이 도움이 될 거예요.

위치 & 오시는길

주소

도로명: 경기 파주시 문산읍 임진각로 148-40
지번: 마정리 613-1
네비게이션: 임진각평화누리캠핑장 / 평화누리캠핑장

자가용 이용 안내

서울문산고속도로(17번) 이용

자유로 → 남고양 IC 또는 북로 JC → 서울문산고속도로(17번) → 내포 IC → 자유로 이용 → 마정JC에서 판문점 방면 진출

자유로 이용

자유로 → 마정 JC에서 판문점 방면 진출 → 도로 차단점에서 유턴 후 우측으로 캠핑장 주차장 진입

통일로 이용

1번 국도 통일로 → 판문점행 도로 차단점 도착 → 유턴 후 캠핑장 주차장 진입

대중교통 이용 안내

경의선 전철

서울역 → 신촌 → 가좌 → 디지털미디어시티 → 수색 → 한국항공대 → 강매 → 행신 → 능곡 → 대곡 → 곡산 → 백마 → 풍산 → 일산 → 탄현 → 야당 → 운정 → 금릉 → 금촌 → 월롱 → 파주 → 문산역 하차

경의중앙선 추가 안내

문산역 하차 후 플랫폼 이동 → 문산 ↔ 임진강행 전철 탑승 → 임진강역 하차
또는 문산역 1번 출구 → [한진1차.문산역] 정류장(30336) 도보 이동 → 058번 버스 탑승 → 임진각 하차

경의선 운행 시간표 (문산 ↔ 임진강)

주중: 문산역 → 임진강역 10:30 / 17:05 | 임진강역 → 문산역 10:50 / 17:25
토요일·공휴일: 문산역 → 임진강역 09:35 / 10:35 / 15:45 / 10:00 / 12:40 / 16:10 / 17:45

버스 이용 안내

9710번 (평일 + 주말): 광화문 → 숭례문 → 독립문역 → 연신내역 → 삼송역사거리 → 관산동·벽제시장 → 파주삼릉 → 월롱역 → 한진1차.문산역 → 058번 마을버스 환승 → 임진각 하차
7300번 (주말만): 홍대입구역 → 합정역 → 헤이리예술마을 → 동화경모공원 → 체인지업캠퍼스(파주영어마을) → 임진각 하차

평화누리 캠핑장 예약 방법

https://ggtour.or.kr/camping/00000/00005.web

예약안내 | 평화누리캠핑장

예약방식 응모기간 전체 및 결과발표일이 휴일(공휴일)인 경우 그 다음 평일로 일정이 변경될 수 있으며, 매월 예약일정은 공지사항에서 확인하실 수 있습니다. 관광취약계층 우선추첨은 관광

ggtour.or.kr

홈페이지에 들어가시면 오른쪽 하단에 있는 캠핑장 예약하기 버튼을 눌러주시면 됩니다!
평화누리 캠핑장은 우선 추첨제로 예약이 진행되고, 이후 잔여석은 선착순으로 예약할 수 있어요. ⏳

저는 운 좋게 잔여석으로 예약해서 다녀왔답니다.
잔여석 예약은 **전월 11일 오후 2시(14시)**에 열리니, 그 시간에 맞춰 미리 대기하면 예약 성공 확률이 높아요! ️

예약 방법

우선 회원가입 후 로그인은 필수예요! ‍♀️ ‍♂️

1️⃣ 화면 우측에 있는 "캠핑장 예약하기" 버튼을 클릭하면 예약 페이지가 열립니다. ️

예약 페이지 우측 상단에는 로그아웃 · 개인정보 관리 · 예약 확인 및 취소 버튼이 있어요.
나중에 예약을 확인하거나 취소하려면 반드시 이 페이지에서만 가능하답니다.
저도 처음에는 어디서 취소해야 하는지 몰라서 한참 헤맸었어요.

원하는 타입을 선택할 때, 이름 앞에 색깔 동그라미( ) 안에 표시된 숫자가 바로 잔여 자리 수예요.
저도 처음엔 이게 뭔지 몰라서 잠깐 헷갈렸는데, 알고 나니까 훨씬 예약하기 편하더라고요!

원하는 타입을 클릭하면, 다음 단계인 [ 02 자리선택 ] 페이지로 이동합니다! ️➡️

2️⃣ 자리 선택 단계에서는 먼저 숙박 일수를 선택해야 해요.
드롭박스 ⬇️를 클릭해서 원하는 숙박 일수를 고르면 됩니다. ️✨

그 다음에는 아래에 나오는 캠핑 사이트 그림에서 원하는 자리를 직접 클릭하면 돼요. ️
빈자리는 색깔 원( )으로 표시되어 있어서 한눈에 확인하기 쉽답니다!

선택하신 캠핑 사이트 타입 외에는 클릭이 되지 않아요.
만약 다른 타입으로 변경하고 싶으시다면, ⬅️ 이전 버튼을 눌러 다시 처음부터 타입을 선택하셔야 합니다.

숙박일수를 선택하시면 아래와 같이 예약가능 여부를 알 수 있어요.

3️⃣ 약관동의 및 결제 단계

자리를 고르고 다음 버튼을 누르면 결제 페이지로 이동합니다. ✨
이때 차량 정보 입력란 이 있는데, 꼭 미리 입력해두셔야 해요!

만약 입력하지 않으면 캠핑장 입구 차단기가 열리지 않는 불편한 상황이 생깁니다.

혹시 깜빡했다면 당황하지 마시고, 차단기 옆에 있는 호출 버튼 을 눌러

“캠핑 예약자입니다” 하고 말씀하시면 입장이 가능하답니다.

추가로 알아두면 좋은 주의사항
예약과 이용 과정에서 몇 가지 꼭 챙겨야 할 부분들이 있어요.
저도 처음에는 몰라서 조금 헤맸던 부분이라, 미리 알고 가시면 훨씬 편하게 캠핑을 즐기실 수 있답니다! ️✨

평화누리 캠핑장 요금 정보

️ 평화누리 캠핑장 부대서비스

다양한 부대시설이 잘 갖춰져 있어서, 짐을 많이 챙기지 않아도 가볍게 캠핑을 즐길 수 있을 것 같아요.

** 유의사항

모든 대여용품은 양도불가하며, 퇴실시 반납 부탁드립니다.

미사용한 물품은 결제 30분 이내 반납시에만 환불 가능합니다.

보증품 : 신분증, 신용카드 또는 현금 5천원 ※ 대여용품 반납시 웰컴센터에서 돌려드립니다.

물품 반납기한은 퇴실 전(오전 11시)까지입니다.

등유는 별도로 판매하지 않습니다. 직접 구비해주시기 바랍니다.

평화누리 캠핑장 이용수칙

️ 캠핑 사이트에서는 매점에서 음식물 쓰레기와 종량제 봉투를 구매해서 사용해야 한답니다.

️ 평화누리 캠핑장 정보

편의시설 안내

캠핑장에 들어서면 제일 먼저 왼쪽에 **관리동(웰컴센터)**이 보입니다.
입실을 위해서는 차량을 잠시 갓길에 세워두고, 웰컴센터에서 체크인을 하셔야 해요. ✅

웰컴센터 기준으로 왼쪽에는 무인 편의점 이 자리하고 있는데요, 체크인하면서 꼭 들러보시는 걸 추천드립니다!

여기서 간단한 먹거리뿐만 아니라, 캠핑장에서 꼭 필요한 음식물 쓰레기봉투와 종량제 봉투도 구입하실 수 있어요. ️
미리 준비해두시면 캠핑 중에 훨씬 편하게 이용하실 수 있습니다.

무인 편의점은 현금 결제 불가 ❌이며, 카드 결제만 가능합니다.
체크인하면서 들르실 계획이라면 카드 준비를 잊지 마세요! ✨

이번 글에서는 평화누리 캠핑장의 예약 방법과 기본 정보를 정리해보았습니다.
처음 캠핑을 준비하시는 분들이나 예약 과정이 헷갈리셨던 분들께 도움이 되었길 바라요. ✨
특히 잔여석 예약 팁이나 차량 정보 입력 같은 부분은 꼭 기억해두시면 좋아요.

저도 처음엔 조금 헤맸지만, 이번에 정리하면서 다시 한 번 확실히 알게 되었답니다.
캠핑은 준비 단계부터 설레고, 하나하나 알아가는 재미가 있는 것 같아요.
덕분에 캠핑 초보라도 큰 걱정 없이 떠날 수 있겠죠? ️

평화누리 캠핑장은 시설과 부대 서비스가 잘 갖춰져 있어 초보자도 편하게 즐길 수 있습니다.
이번 글이 캠핑을 준비하는 분들께 작은 가이드북 같은 역할이 되었으면 합니다.
다음 편에서는 제가 직접 다녀온 평화누리 캠핑장 이용 후기를 자세히 들려드릴게요!
기대해주셔도 좋습니다. 그럼 오늘도 즐거운 하루 보내세요.