📚FOS Study
홈카테고리
홈카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • agents 페이지로 이동
    • langgraph 페이지로 이동
    • BMAD Method — AI 에이전트로 애자일 개발하는 방법론
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • Claude Code를 11일 동안 쓴 결과 — 데이터로 본 나의 사용 패턴
    • Claude Code 멀티 에이전트 — Teams
    • 하네스 엔지니어링 — 오래 실행되는 AI 에이전트를 위한 설계
    • 멀티모달 LLM (Multimodal Large Language Model)
    • AI 에이전트와 함께 MVP 만들기 — dooray-cli 사례
  • architecture 페이지로 이동
    • 캐시 설계 전략 총정리
    • 디자인 패턴
    • 분산 트랜잭션
  • css 페이지로 이동
    • FlexBox 페이지로 이동
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • redis 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야할까?
    • 인덱스 - DB 성능 최적화의 핵심
    • 역정규화 (Denormalization)
    • 데이터 베이스 정규화
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • monitoring 페이지로 이동
    • Envoy Proxy
    • Graceful Shutdown
  • go 페이지로 이동
    • Go 언어 기본 학습
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • 210812 페이지로 이동
    • 뱅크샐러드 AI Native Server Engineer
    • CJ 올리브영 커머스플랫폼유닛 Back-End 개발 지원 자료
    • 마이리얼트립 - Platform Solutions실 회원주문개발 Product Engineer
    • NHN 서비스개발센터 AI서비스개발팀
    • nhn gameenvil console backend 직무 인터뷰 준비
    • 면접을 대비해봅시다
    • 토스증권 Server Developer (Platform) 지원 자료
    • 토스증권 Server Developer (Product) 지원 자료
    • 토스뱅크 Server Developer (Product) 지원 자료
    • Tossplace Node.js Developer
    • 토스플레이스 Node.js 백엔드 컬처핏
  • java 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • 더_자바_코드를_조작하는_다양한_방법 페이지로 이동
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • OpenTelemetry 란 무엇인가?
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • Data_Structures_and_Algorithms 페이지로 이동
    • Heap 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node.js
    • npm vs pnpm 선택기준은 무엇인가요?
    • `setImmediate()`
  • kafka 페이지로 이동
    • Kafka 기본
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • 메시지 전송 신뢰성
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • tmux — Terminal Multiplexer
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • react 페이지로 이동
    • JSX 페이지로 이동
    • VirtualDOM 페이지로 이동
    • v16 페이지로 이동
  • resume 페이지로 이동
    • CJ 올리브영 지원 문항
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • sb-dev-team 페이지로 이동
    • the-future-company 페이지로 이동
📚FOS Study

개발 학습 기록을 정리하는 블로그입니다.

바로가기

  • 홈
  • 카테고리

소셜

  • GitHub
  • Source Repository

© 2025 FOS Study. Built with Next.js & Tailwind CSS

목록으로 돌아가기
📁task/ sb-dev-team

Svelte 프론트엔드 번들러 Vite로 교체

약 3분
2026년 3월 29일
GitHub에서 보기

Svelte 프론트엔드 번들러 Vite로 교체

진행 기간: 2023.12

기존에 Rollup 기반으로 직접 번들링하던 구조를 Vite로 교체했다. 환경별(dev/alpha/stage/release) 빌드가 복잡하게 얽혀 있었고, 특히 wemix SDK가 환경마다 다른 파일을 사용하는 구조라 처리할 게 좀 있었다.


왜 Vite로

당시 빌드 구조는 Rollup 설정 파일을 직접 관리하는 방식이었다. Svelte는 이미 공식적으로 Vite + @sveltejs/vite-plugin-svelte 조합을 권장하고 있었고, 설정이 단순해지는 것 외에도 개발 서버 HMR 속도 문제가 있어 전환을 결정했다.


주요 변경 사항

1. 환경 변수 prefix 추가

Rollup 때는 환경 변수를 자유롭게 사용할 수 있었는데, Vite는 클라이언트 측 환경 변수에 VITE_ prefix를 강제한다. 기존 .env 파일을 전부 수정해야 했다.

# 기존
API_BASE_URL=https://...

# Vite 이후
VITE_API_BASE_URL=https://...

코드에서는 import.meta.env.VITE_API_BASE_URL 형태로 접근한다.

2. env 파일 디렉터리 분리

환경 파일이 프로젝트 루트에 섞여 있어서 별도 폴더로 정리했다.

// vite.config.ts
export default defineConfig({
  envDir: './env',
  // ...
})

3. base path 설정

배포 환경에서는 /sports 경로 하위에 올라가는 구조였다. Rollup 때는 이걸 별도 처리했는데 Vite는 base 옵션 하나로 해결됐다.

base: mode !== 'localdev' ? '/sports' : '/',

로컬에서는 / 그대로, 배포 환경에서는 /sports를 기본 경로로 쓴다.

4. sourcemap 제어

릴리즈 빌드에서는 소스맵을 포함하지 않도록 명시적으로 설정했다.

build: {
  sourcemap: mode !== 'release' ? true : false,
}

5. 빌드 버전 주입

빌드 시각을 import.meta.env.VITE_BUILD_TIME으로 주입해 런타임에서 확인할 수 있게 했다.

define: {
  'import.meta.env.VITE_BUILD_TIME': dayjs().unix(),
},

wemix SDK 환경별 분리 문제

Vite 마이그레이션 이후 별도로 처리한 부분이다(2024.02). wemix SDK가 환경마다 다른 파일을 사용하는데, 5개 환경(localdev/dev/alpha/stage/release)의 SDK 파일이 모두 번들 결과물에 포함되는 문제가 있었다. 배포 시 필요없는 파일들이 같이 나가는 것도 문제지만, 파일 크기도 상당했다.

Vite 플러그인을 직접 작성해서 빌드 완료 후 현재 환경 외의 SDK 파일들을 삭제하도록 처리했다.

function wemixPlugin(): Plugin {
  let config: ResolvedConfig

  return {
    name: 'wemix-plugin',
    configResolved(_config) {
      config = _config
    },
    renderStart(outputOptions, inputOptions) {
      const modes = ['localdev', 'dev', 'alpha', 'stage', 'release']
      const wemixPrefix = 'wemix_'

      for (const mode of modes) {
        if (mode === config.mode) continue  // 현재 환경은 건너뜀
        const wemixPath = path.resolve(outputOptions.dir, wemixPrefix + mode + '.js')
        fs.rmSync(wemixPath)
      }
    },
  }
}

renderStart 훅은 번들 파일 생성이 시작될 때 호출된다. 여기서 현재 mode와 다른 환경 SDK 파일들을 fs.rmSync로 삭제한다.


Node.js 폴리필 문제

wemix SDK 내부에서 Node.js 빌트인 모듈(crypto, buffer 등)을 사용하는 부분이 있어서, 브라우저 번들에서 이를 폴리필해줘야 했다.

import { nodePolyfills } from 'vite-plugin-node-polyfills'

plugins: [
  svelte(...),
  tsConfigPaths(),
  nodePolyfills(),   // wemix SDK가 Node.js API 사용
  wemixPlugin(),
]

Rollup 때도 비슷한 처리를 했지만 Vite 생태계에선 vite-plugin-node-polyfills 패키지로 해결했다.


정리

마이그레이션 자체는 하루 안에 끝났는데, 후처리(env prefix 전부 교체, CSS 경로 수정, wemix 플러그인 작성)가 더 시간이 걸렸다. 전환 후 개발 서버 기동 속도가 눈에 띄게 빨라졌고, 빌드 설정이 단일 파일(vite.config.ts)로 관리되어 훨씬 파악하기 쉬워졌다.


관련 문서

  • wemix 지갑 연동
task 카테고리의 다른 글 보기수정 제안하기

댓글

댓글을 불러오는 중...
  • Svelte 프론트엔드 번들러 Vite로 교체
  • 왜 Vite로
  • 주요 변경 사항
  • 1. 환경 변수 prefix 추가
  • 기존
  • Vite 이후
  • 2. env 파일 디렉터리 분리
  • 3. base path 설정
  • 4. sourcemap 제어
  • 5. 빌드 버전 주입
  • wemix SDK 환경별 분리 문제
  • Node.js 폴리필 문제
  • 정리
  • 관련 문서