프론트엔드 개발 환경은 지난 몇 년 동안 눈부시게 발전했습니다. 과거에는 단순히 <script> 태그로 JS 파일을 불러오면 되었지만, 규모가 커지고 모듈 단위 개발이 보편화되면서 “모듈 번들러(Module Bundler)”가 필수 도구가 되었습니다. 이번 글에서는 대표적인 모듈 번들러인 Webpack, Rollup.js, 그리고 차세대 번들링 도구로 각광받는 Vite에 대해 비교해 보겠습니다.

1. 모듈 번들러란

모듈 번들러는 여러 개의 JavaScript, CSS, 이미지 등의 파일을 의존성 그래프(Dependency Graph)로 분석해 하나의 파일(또는 최적화된 여러 파일)로 묶어주는 도구입니다.

목적: 브라우저가 효율적으로 로드할 수 있도록 최적화된 번들을 만들어주는 것.

왜 필요한가?

👀속도 개선: 파일이 많으면 브라우저가 하나씩 요청해야 해서 느려요. 번들러가 파일을 합쳐서 요청을 줄여줍니다.
👀최적화: 쓰이지 않는 코드를 제거(트리 쉐이킹)하거나, 코드를 압축해 용량을 줄여줍니다.
👀개발 편의성: 최신 문법(ES6, TypeScript 등)을 구버전 브라우저에서도 쓸 수 있도록 변환해 줍니다.

2. 주요 모듈 번들러

이제 많이 쓰이는 3가지 도구를 비교해볼게요

Webpack

가장 유명하고 오래된 번들러
설정이 강력하지만 복잡하다는 단점이 있다
entry → loader → plugin → output 구조로 동작.

대규모 프로젝트에서 안정적이고 확장성이 높습니다.

예시
React, Vue 같은 프레임워크의 기본 번들러로 많이 쓰였습니다.
복잡한 빌드(이미지, CSS, JS, TS 다 합치기)에 유리.

Rollup.js

라이브러리 제작에 강점.
Webpack보다 단순하고 가볍습니다.
트리 쉐이킹(tree shaking) 기능이 강력해서, 쓰지 않는 코드가 거의 남지 않아요.

예시:
Lodash, D3.js 같은 유명한 JS 라이브러리도 Rollup으로 빌드됩니다.
라이브러리 제작할 때는 Webpack보다 Rollup이 더 선호됩니다.

Vite

차세대 번들러로, 최근 가장 핫합니다.

내부적으로 Rollup을 기반으로 하지만, 개발 서버는 ESBuild(Go 언어로 만든 초고속 번들러)를 사용


🔴장점: 개발 서버 속도가 엄청 빠름 (변경된 부분만 즉시 반영 → HMR)

🔴단점: 아직은 Webpack만큼 플러그인 생태계가 방대하지 않음


예시:
Vue 3, React 최신 템플릿에서 기본 빌드 도구로 채택됨
스타트업이나 개인 프로젝트에서 빠르게 개발할 때 최적

회사에서도 기존에 React + Webpack 기반으로 운영하던 서비스를 Vite로 마이그레이션한 경험이 있습니다. 프로젝트가 무거워지면서 Webpack 환경에서 빌드 속도가 오래걸려 초기 개발 서버를 시작하는데에 10분 정도가 걸리는 아주 힘든 상황이 생겨버린거죠! HMR 속도도 개선하기 위함과 최신 생태계와 호환성을 고려해서 논의 결과 vite로 마이그레이션하기로 결정을 했습니다

그 결과, 개발 서버 구동 속도가 1분 미만으로 단축, HMR속도는 말할 것도 없이 현저히 빨라졌습니다.

결론적으로, Vite는 Webpack 대비 훨씬 가볍고 빠른 개발 경험을 제공했고, 팀의 생산성에도 긍정적인 효과를 줬습니다.

프론트엔드 애플리케이션을 개발하다 보면, 컴포넌트 간 상태를 공유하고 변경 사항을 일관성 있게 반영하는 것이 중요한 과제가 된다.

이를 위해 다양한 상태관리 라이브러리가 존재하며, 대표적으로 Redux, Recoil, MobX 등이 있다. 최근에는 보다 단순하고 가벼운 접근 방식을 제공하는 Zustand가 주목받고 있다.

1. Zustand란 무엇인가

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

Zustand의 공식문서이다.
공식문서에 따르면,

작고, 빠르며 확장 가능한 최소한의 상태 관리 솔루션입니다.
Zustand는 훅(Hooks)에 기반한 편안한 API를 제공합니다. 보일러플레이트 코드가 많거나 특정한 의견(opinion)에 치우치지 않지만, 명시적이고 Flux와 유사한 구조를 유지할 수 있는 충분한 규칙을 가지고 있습니다.

귀엽다고 무시하지 마세요. 발톱이 있습니다!
많은 시간을 들여 흔히 겪는 문제들을 해결했습니다. 예를 들어, 악명 높은 좀비 자식(zombie child) 문제, React의 동시성(concurrency), 서로 다른 렌더러 간의 컨텍스트 손실(context loss) 등을 다룹니다.
React 생태계에서 이러한 모든 문제를 올바르게 처리하는 거의 유일한 상태 관리 라이브러리일지도 모릅니다.

라고 한다.

✔️종합해보면

1. Zustand는 핵심 기능만 제공하는 가벼운 상태 관리 라이브러리

2. Redux처럼 복잡한 설정이나 파일 구조 없이도 쓸 수 있고, 프로젝트 규모가 커져도 무리 없이 확장할 수 있다는 장점

3. React의 useState, useEffect 같은 방식으로 쉽게 사용할 수 있다는 의미

4. 복잡한 action, reducer, dispatch 같은 개념을 강제로 쓰게 하지 않아서 진입 장벽이 낮음

5. 특정 패턴을 강제하지 않지만, Flux 아키텍처처럼 데이터 흐름이 단방향이라 구조가 명확합니다.

6. 좀비 자식 문제(zombie child problem)
→ 상태가 업데이트됐는데 이미 언마운트된 컴포넌트가 옛 데이터를 참조하는 버그를 의미합니다.

7. React 동시성(Concurrency)
→ React 18의 concurrent mode에서도 상태 관리가 안전하게 동작하도록 설계됨.

8. 컨텍스트 손실(Context loss)
→ React Native, Web, Three.js 같이 렌더러가 혼합된 환경에서도 상태를 안전하게 공유 가능.

요약: Zustand는 단순하지만 깊이 있는 상태 관리 라이브러리이고, React에서 발생하는 까다로운 버그 상황도 대부분 해결해주는 거의 유일한 선택지이다

2. 기본사용방법

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 }),
}))

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>
}

1. create()
• Zustand 스토어를 만드는 최초 함수.
• 인자로 전달하는 함수 안에서 상태(state)와 상태 변경 로직(setter)을 정의합니다.


2. set()
• 상태를 변경하는 함수.
• 부분 업데이트 가능(merge 동작).

3. get()
• 스토어의 현재 상태를 즉시 읽는 함수.
• React 훅 없이도 외부에서 상태를 읽을 수 있음.

4. subscribe()
• 특정 상태 변화에 대해 리스너 등록.
• React 컴포넌트 바깥에서도 상태 변화를 감지 가능.

const unsubscribe = useStore.subscribe(state => {
  console.log('count changed:', state.count);
});

unsubscribe(); // 구독 해제

다른 라이브러리들과의 차이점 (Zustand vs 다른 상태관리 라이브러리 비교)

우리 팀은 현재 상태관리 라이브러리의 과도기를 겪고 있다.
과거 프로젝트 요구사항과 팀원의 선호도 차이로 인해 Jotai, Redux, Recoil이 혼합된 구조가 형성되었고, 그 결과 전역 상태의 흐름이 복잡해지고 유지보수가 점점 어려워졌다.

이에 따라 우리는 상태관리 방식을 Zustand로 통합하기로 결정했다.

Zustand는 비교적 가벼우면서도 명시적이고 확장 가능한 구조를 제공하므로, 기존에 분산된 상태를 한 곳으로 모으기에 적합하다고 판단했다.

다만, 통합 과정에서 고려해야 할 중요한 점이 있다.

현재 Redux에서는 비동기적 라우팅 처리 로직이 전역에서 관리되고 있는데, 이 기능을 단순히 Zustand로 옮기는 것만으로는 동일한 유연성을 확보하기 어렵다.
Zustand에서는 이러한 비동기 흐름을 미들웨어 또는 subscribe 기반 이벤트 처리로 재구성해야 하며, 상태 변경과 라우팅 전환이 끊김 없이 동작하도록 설계하는 것이 핵심 과제였다.

다음 글에서는 어떻게 이러한 과제들을 적용시켰는지 써보도록 하겠다!

팀내에서 디자인 시스템 설계시 기존 사용하던 폴더 구조를 따라가기에는 한계가 있엇다.

아래는 기존 폴더 구조이다.

해당 구조는 서비스 규모가 커지면서 유지보수성에 불리하게 되었다.

이 구조의 단점을 살펴보면 다음과 같다.

1. 관심사 혼합

components와 pages 폴더의 파일이 거의 1:1로 매핑되다 보니, 마치 특정 컴포넌트가 해당 페이지에서만 사용되는 것처럼 보인다. 하지만 예를 들어 user라는 컴포넌트가 다른 페이지에서도 사용된다면, 해당 컴포넌트를 사용해도 되는지 판단하기 위해 결국 코드를 직접 열어 확인해야 한다.

2. 확장 시 스케일 문제

• 기능별로 폴더가 아니라 레이어별(components, pages, utils)로만 나눠져 있어서,
  페이지나 기능이 많아지면 components/ 폴더 안이 너무 커지게 된다. 실제로 components내의 파일 개수는 1000개를 넘어가는 상황이다.
• 따라서 새로운 기능 개발 혹은 기존 기능 고도화 작업을 진행하게 되면 그 기능에만 관련된 파일만 봐야하는 것이 아닌, 어떤 것이 연관이 있는지 직접 찾아가며 사이드이펙트를 살펴봐야 한다.

3. 페이지와 컴포넌트 결합도 문제

• pages/와 components/가 물리적으로 멀리 떨어져 있음 → 유지보수 시 페이지-컴포넌트 간 맥락 파악 어렵다.
• 같은 기능을 위한 페이지와 컴포넌트를 서로 다른 폴더에서 찾아야 한다. → 쓰이는 곳을 찾아가며 경로를 이동하다 길을 잃을 수 있다 (;;)

이러한 단점들로 인해 우리 팀 내에서는 개선방향으로 프로젝트에 FSD 아키텍쳐를 적용하기로 하였다.

단, 프로젝트 규모가 워낙 크다보니 FSD(Feature-Sliced Design) 아키텍쳐를 한 번에 프로젝트에 적용할 수 없었고, 디자인 시스템 정립이 새로 진행되고 있었으므로 디자인 시스템에 이 아키텍쳐를 도입해 보기로 하였다. 

기본 골자는 아래와 같다.

📂 shared/

프로젝트 전역에서 공용으로 쓰이는 요소 모음

• tokens/
  • 색상, 폰트, spacing, z-index 등 디자인 토큰
  • ex) colors.ts, typography.ts, spacing.ts
• hooks/
  • 프로젝트 전역 공용 훅
  • ex) useMediaQuery, useTheme
• utils/
  • 포맷터, 헬퍼 함수 등 재사용 가능 로직
  • ex) formatDate, debounce, clsx

📂 entities/

하나의 독립적인 UI 엔티티(컴포넌트) 단위

• ex) button/, input/, avatar/
• 각 엔티티는 자기 완결적
  • ui/ → 실제 UI 컴포넌트 (styled-components + variant 스타일 정의 포함)
  • model/ → 타입 정의, 상태 관리, 내부 비즈니스 로직
  • index.ts → 해당 엔티티의 진입점 (외부에 노출할 API)

이렇게 하면, 버튼을 쓸 때 내부 구조를 몰라도 import { Button } from '@/entities/button' 식으로 가져올 수 있음.

📂 widgets/ (선택적)

엔티티들을 조합해 만든 복합 UI 컴포넌트 (단, 우리 프로젝트에서는 폴더 축소화를 위해 entities에 복합 ui를 포함하기도 하였다.)

• 예: Form, Navbar, Sidebar
• 페이지나 기능에 재사용 가능한 조합 단위
• 비즈니스 로직이 거의 없고 UI 결합 중심

📂 app/

애플리케이션 전역 환경과 데모 페이지

• 디자인 시스템 Storybook, 테스트 페이지 등
• 라우팅, 전역 Provider, App-level 설정 포함 가능
• ex) storybook/, App.tsx, global.css

이 구조의 특징을 살펴보자.

1. 관심사 분리
디자인 토큰, 공용 유틸, UI 엔티티, 복합 UI, 앱 환경이 물리적으로 분리되어 있음
2. 스케일 확장에 강함
새 컴포넌트를 만들 때 해당 엔티티 폴더만 생성하면 됨 → 폴더가 기능 중심으로 늘어남.
3. Storybook/TDD 친화적
각 엔티티/위젯 안에서 바로 스토리북과 테스트 작성 가능.
4. 재사용성 극대화
위젯·엔티티를 다른 프로젝트에 가져가기 쉬움.

현재까지 작업은 계속 진행중이다. 하루 빨리 디자인 시스템 및 FSD 아키텍처 도입이 정상화되어 일의 효율이 높아지면 좋겠다.

대규모 프로젝트에서는 FSD 패턴, 즉 기능별 디자인 아키텍쳐가 필수적이라고 생각하는 요즘이다!

오늘은 싱글턴패턴에 대해 알아볼 것입니다.

프론트엔드에서 디자인 패턴이란 반복적으로 발생하는 문제를 효과적으로 해결하기 위한 "검증된 코드 구조나 설계 방식"을 의미합니다.

즉, 어떤 기능이나 구조를 만들 때 좀 더 나은 설계와 유지보수를 위해 사용할 수 있는

"코딩 방식의 정석"이라고 할 수 있습니다.

말로만 들어서는 어떤 걸 의미하는지 와닿지 않기도 합니다.

아래 설명과 예제 코드를 보며 1. 싱글턴 패턴에 대해 알아봅시다.

프론트엔드 개발 실무에서는 어떻게 적용하면 좋을지도 같이 알아보도록 하겠습니다.

싱글턴 패턴 (Singleton Pattern)

싱글턴 패턴은 애플리케이션에서 단 하나의 인스턴스만 존재하도록 보장하는 생성 패턴(Creational Pattern)입니다.

주로 *환경 설정, 앱의 전역 상태, 공용 리소스 등을 한 곳에서 관리해야 할 때 사용됩니다.

여기서 잠깐! 왜 환경설정, 앱 전역, 공용리소스에 사용할까?

1. 일관된 상태 관리
예: 로그인 상태, 사용자 설정, 테마, 언어 등이런 정보는 앱 전체에서 일관되게 유지되어야 합니다.
여러 컴포넌트에서 동일한 정보가 필요한데,각각의 컴포넌트가 이 정보를 따로 관리하면 데이터 불일치, 버그 발생 가능성이 큽니다.
📌 Singleton 패턴으로 하나의 전역 인스턴스에서 관리하면 항상 동일한 상태를 참조할 수 있습니다.

2. 불필요한 중복 제거
공용 리소스 (예: API 인스턴스, DB 커넥션, WebSocket 연결 등)는하나만 있으면 되는데 여러 개 만들면
메모리 낭비성능 저하불필요한 네트워크 트래픽 유발 가능성
📌 이런 경우에도 하나의 인스턴스만 생성되도록 제한하는 Singleton 패턴이 효과적입니다.

3. 중앙 집중식 관리 → 유지보수 편리
환경 설정, 공통 로직, 전역 상태 등을 여기저기 흩뿌려두면…
나중에 수정하려면 모든 파일을 찾아다녀야 함실수로 다른 곳에서 설정을 덮어쓸 수 있음
📌 전역에서 접근 가능한 단 하나의 인스턴스로 통제하면,중앙에서 쉽게 관리하고 수정 사항도 한 군데만 변경하면 끝입니다.

4. 클라이언트가 늘어나도 동일한 인스턴스를 공유
프론트엔드 앱에서는 사용자 상호작용에 따라 여러 컴포넌트, 페이지가 동시에 생기고 사라집니다.
이때도 매번 인스턴스를 새로 생성하지 않고하나의 고정된 인스턴스를 계속 재사용하면
👉 성능상 이점 + 코드 간 연결성 유지

그럼 다시 본론으로 돌아와서!

싱글턴 패턴의 핵심 개념은

1. 인스턴스는 단 하나만 생성된다.

2. 외부에서 직접 생성자를 호출할 수 없다.

3. 항상 동일한 인스턴스를 반환하는 정적(static) 메서드를 제공한다.

일단 코드부터 보면서 이해해볼게요.

아래 코드는 싱글턴패턴의 Javascript 예제 코드입니다.

class Singleton {
  constructor() {
    if (Singleton.instance) {
      return console.warn(
        'Warning: Singleton class already instantiated'
      );
    }
    Singleton.instance = this;
    this.version = Date.now();
    this.config = 'test';
  }

  static getInstance() {
    if (!this.instance) {
      this.instance = new Singleton();
    }
    return this.instance;
  }
}

구조 설명

• 생성자(private or 제한적 접근)
  • 인스턴스를 외부에서 새로 만들지 못하도록 막습니다.
• 정적 프로퍼티(static instance)
  • 인스턴스를 메모리에 한 번만 생성하고 재사용합니다.
• 정적 메서드(static getInstance)
  • 인스턴스를 외부에서 접근할 수 있게 해줍니다. 새로운 인스턴스를 만들지 않고 기존 인스턴스를 반환합니다

그럼 위 작성된 코드를 호출해볼까요?

const s1 = new Singleton();
const s2 = new Singleton();

이렇게 호출하면 어떻게 될까요?

결과는..

const s1 = new Singleton(); // 정상 생성
const s2 = new Singleton(); // 경고 발생

Singleton { version: 1754567722799, config: 'test' }
Warning: Singleton class already instantiated
Singleton {}

첫번째 결과에는 Singleton의 instance가 나왔지만, 두번째 결과는 Warning을 뱉으며,

인스턴스를 찾지 못하는 것을 알 수 있습니다.

그 이유는

❌ constructor를 직접 호출하면 싱글턴의 규칙이 깨질 수 있습니다.

이 예제에서는 경고만 띄우지만, 실제로는 constructor를 private 또는 protected로 만들어 완전히 차단하는 것이 더 안전합니다. (TypeScript 등에서는 private constructor 사용 가능)

그럼 이제 제대로 호출을 해보겠습니다.

const s1 = Singleton.getInstance();
const s2 = Singleton.getInstance();

console.log(s1); // Singleton { version: ..., config: 'test' }
console.log(s2); // Singleton { version: ..., config: 'test' }
console.log(s1 === s2); // true

위 코드처럼 s1과 s2의 결과값이 같으며, 동등비교를 해도 true값이 나오며 동일한 인스턴스를

반환하는 것을 알 수 있네요!

* 항상 getInstance()를 통해 동일한 인스턴스에 접근해야 합니다.

보완 사항

1. 자바스크립트에서 생성자 차단하려면?

• 완벽히 차단은 불가능하지만, 관례적으로 직접 호출을 금지하는 구조를 만들 수 있습니다.
• TypeScript에서는 private constructor를 활용하여 명확하게 제어할 수 있습니다. 아래는 타입스크립트 예제 코드입니다.

class Singleton {
  private static instance: Singleton;

  private constructor() {
    // 외부에서 new Singleton()을 절대 못 씀
  }

  static getInstance(): Singleton {
    if (!Singleton.instance) {
      Singleton.instance = new Singleton();
    }
    return Singleton.instance;
  }
}

• private constructor: 외부에서 new Singleton() 직접 호출 불가
• Java, C# 등 클래스 기반 언어의 싱글턴과 거의 유사한 방식으로 안전하게 구현 가능

2. 멀티스레드 환경이라면?

• Java, C++ 같은 언어에서는 동기화(Synchronized)를 고려해야 합니다.
• JS는 기본적으로 싱글 스레드이지만, WebWorker나 Node.js에서 멀티 프로세스를 쓸 경우 주의가 필요합니다.
• -> 멀티스레드에서는 여러 쓰레드가 동시에 getInstance()를 호출할 수 있고 두 개 이상의 인스턴스가 생성될 가능성이 있기 때문입니다.
• Java, C++ 등 멀티스레드 언어에선 동기화(Synchronization) 필요

public class Singleton {
  private static Singleton instance;

  public static synchronized Singleton getInstance() {
    if (instance == null) {
      instance = new Singleton();
    }
    return instance;
  }
}

• synchronized: 한 번에 하나의 스레드만 접근 허용
• Double-checked locking 등의 최적화도 사용함

그럼 싱글턴패턴은 여기까지 알아보도록 하겠습니다!

참고영상: Youtube 코딩문

✅ 1. 재귀(Recursion)란?

함수 안에서 자기 자신을 다시 호출하는 함수

🔁 예시: 1부터 n까지 더하기 (재귀 버전)

function sum(n) {
  if (n === 1) return 1;     // 종료 조건 (base case)
  return n + sum(n - 1);     // 자기 자신을 호출 (재귀 호출)
}

console.log(sum(5)); // 출력: 15

작동 순서:

sum(5)
→ 5 + sum(4)
     → 4 + sum(3)
          → 3 + sum(2)
               → 2 + sum(1)
                    → 1

✅ 2. 스택(Stack)과 재귀의 관계

🔸 스택이란?

나중에 들어간 게 먼저 나오는 자료구조 (LIFO: Last In, First Out)

const stack = [];
stack.push(1);  // [1]
stack.push(2);  // [1, 2]
stack.pop();    // → 2 (먼저 나감)

🔸 재귀 함수는 내부적으로 스택 구조를 사용해요!

• 함수 호출 시 "호출 정보"가 콜 스택(Call Stack)에 쌓임
• 종료 조건을 만나면 마지막 호출부터 차례로 스택에서 빠져나오며 연산 수행

📌 sum(3) 재귀 호출 예시

sum(3) 호출 → stack: [sum(3)]
sum(2) 호출 → stack: [sum(3), sum(2)]
sum(1) 호출 → stack: [sum(3), sum(2), sum(1)]
sum(1) 종료 → stack: [sum(3), sum(2)]
sum(2) 종료 → stack: [sum(3)]
sum(3) 종료 → stack: []

✅ 3. 재귀 함수 구성 2가지 핵심 요소

1. Base Case (종료 조건)
   → 무한 루프 방지를 위해 필수
2. Recursive Case (자기 자신 호출)
   → 문제를 단순화하며 재호출

✅ 4. 재귀 vs 반복문

✅ 5. 실전에서 많이 쓰이는 재귀 예

✅ 6. 재귀 → 반복문으로 바꾸기

function factorial(n) {
  let result = 1;
  for(let i = 1; i <= n; i++) {
    result *= i;
  }
  return result;
}

→ 꼭 재귀만 써야 하는 건 아니고, 복잡한 문제 구조를 간결하게 표현할 때 유용해요.

✅ 7. 마무리 요약

1. 유틸리티 함수 모음 (Helper Class)

상황

예를 들어, 날짜를 포맷팅하거나, 특정 문자열을 변환하는 함수가 여러 군데에서 필요할 때가 있어요.
이럴 땐 매번 함수로 선언해서 가져오는 것보다, 하나의 헬퍼 클래스에 static 메서드로 묶어두면 훨씬 편리합니다.

예시 코드

class StringUtils {
  static capitalize(str) {
    return str.charAt(0).toUpperCase() + str.slice(1);
  }

  static toKebabCase(str) {
    return str.toLowerCase().replace(/\s+/g, '-');
  }
}

// 사용 방법
console.log(StringUtils.capitalize('hello'));     // Hello
console.log(StringUtils.toKebabCase('Hello World')); // hello-world

왜 static?

• StringUtils는 인스턴스를 만들 필요가 없어요.
• 그냥 StringUtils.methodName()으로 호출만 하면 돼요.

2. 설정 값 관리 (Config Object)

상황

여러 컴포넌트나 모듈에서 공통으로 참조해야 하는 설정값, 버전 정보, API URL 같은 걸 관리할 때도 static을 쓰면 좋아요.

예시 코드

class AppConfig {
  static API_BASE_URL = 'https://api.example.com';
  static VERSION = '1.2.3';

  static printInfo() {
    console.log(`API: ${this.API_BASE_URL}, Version: ${this.VERSION}`);
  }
}

// 사용 예시
console.log(AppConfig.API_BASE_URL);  // https://api.example.com
AppConfig.printInfo(); // API: https://api.example.com, Version: 1.2.3

장점

• 설정 값을 전역 변수로 흩뿌리지 않고, 한 곳에서 관리할 수 있어요.
• 필요할 땐 AppConfig.API_BASE_URL처럼 쉽게 꺼내 쓸 수 있어요.

3. 객체를 만드는 공장 함수 (Factory Method)

상황

어떤 데이터를 받아서 클래스 인스턴스를 쉽게 만들어주는 메서드가 필요할 때가 있어요. 이럴 때 static으로 팩토리 메서드를 만들 수 있어요.

예시 코드

class User {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  }

  static fromJson(json) {
    const data = JSON.parse(json);
    return new User(data.name, data.age);
  }
}

// 사용 예시
const jsonStr = '{"name": "Sally", "age": 30}';
const user = User.fromJson(jsonStr);
console.log(user); // User { name: 'Sally', age: 30 }

장점

• 외부 데이터(JSON 등)를 받아서 깔끔하게 인스턴스를 생성
• new를 외부에서 일일이 사용하지 않아도 돼요

💡 언제 static을 쓰면 좋을까?

상황 왜 static이 좋은가요?

"인스턴스를 만들 필요 없이, 클래스 자체에 붙여서 공통 기능을 제공하고 싶을 때" static을 사용하세요.