vite-plus 딥다이브
— Rust와 TypeScript로 웹 개발 도구를 한 입구에 연결하기

1프로젝트 한줄 요약

Vite+는 Vite, Rolldown, Vitest, Oxlint, Oxfmt, tsdown, Vite Task를 연결하고, vp라는 명령으로 웹 개발의 반복 작업을 수행하게 하는 도구입니다. 여기에 Node.js 버전과 패키지 관리자 관리까지 더합니다. 이 저장소의 핵심은 모든 도구를 새로 만드는 것이 아니라, 서로 다른 도구가 같은 환경에서 일하도록 연결하는 설계입니다.

웹 프로젝트를 시작하면 개발 서버, 포매터, 린터, 테스트 도구, 빌드 도구를 각각 골라야 합니다. 명령도 다르고 설정 파일도 늘어납니다. Vite+는 프로젝트의 vite.config.ts에 관련 설정을 모으고, 명령 이름과 도구 선택을 일관되게 만드는 방향을 택했습니다.

개발자의 하루를 명령으로 읽기

근거는 README.md, packages/cli/src/bin.ts, packages/cli/src/resolve-vite.ts, packages/cli/src/resolve-test.ts입니다. 명령에 따라 Rust만으로 처리하는 부분과 Node.js를 거치는 부분이 다릅니다.

이름이 비슷해도 다른 두 명령

# 내장 Vitest를 실행
vp test

# 프로젝트가 정의한 test 스크립트 또는 작업을 실행
vp run test

# vp run의 짧은 이름
vpr test

package.json에 "test": "jest"가 있다면 vp run test는 그 스크립트를 실행합니다. vp test는 여전히 내장 테스트 경로를 택합니다. 같은 이름의 스크립트로 내장 명령을 덮어쓰지 않는 규칙은 docs/guide/run.md와 packages/cli/src/bin.ts에 드러납니다.

2왜 주목받는가

2026-10-23 GitHub 기준 스타는 6,458개, 포크는 296개입니다. GitHub Trending Rust Weekly #10이라는 순위는 발견의 계기입니다. 이 순위만으로 특정 기능이 인기를 끌었다거나 사용자가 급증했다고 증명할 수는 없습니다. 여기서는 소스에서 드러나는 매력을 세 가지로 해석합니다.

1. 명령과 설정을 함께 묶습니다. 단축 명령만 제공하는 수준을 넘어, packages/cli/src/define-config.ts가 Vite의 설정 타입에 lint, fmt, run, staged 등을 추가합니다.
2. Rust와 JavaScript 생태계의 역할을 나눕니다. 환경 관리와 네이티브 실행 계층은 Rust로, 도구 탐색과 프로젝트 설정 로딩은 TypeScript로 연결합니다.
3. 설치 이후의 문제까지 다룹니다. 프로젝트별 CLI 선택, 네이티브 모듈 배포, Git 훅, 마이그레이션, CI 호환성을 같은 제품 범위에 둡니다.

Vite+의 장점은 명령 몇 글자를 줄이는 데서 끝나지 않고, 팀이 합의해야 할 도구 조합과 실행 규칙을 함께 줄이는 데 있습니다.

기존 선택지와 어떻게 다른가

다음은 역할과 구성 방식을 비교한 표입니다. 실행 속도나 호환성 전체를 측정한 결과가 아니며, 다른 도구도 추가 설정과 플러그인으로 범위를 넓힐 수 있습니다.

Vite와 pnpm은 이 프로젝트가 없애려는 대상으로만 보면 안 됩니다. Vite는 코어에 포함되고 pnpm은 관리 가능한 패키지 관리자 중 하나입니다. 이미 검증된 도구를 조합하면서 반복되는 접착 코드를 제품으로 만든다는 관점이 더 정확합니다.

“설정 없이”라는 소개를 어디까지 받아들일까

README.md는 기본 설정만으로 시작하는 도구 모음이라고 소개합니다. 실제로는 vite.config.ts에서 세밀한 설정을 받으며, vp check의 타입 검사도 조건부입니다. 이 저장소의 vite.config.ts는 lint.options.typeAware와 typeCheck를 모두 켭니다. “아무 설정도 필요 없다”보다 “기본값을 주되 한곳에서 조정한다”로 이해하면 맞습니다.

packages/cli/src/resolve-test.ts는 Vitest를 CLI 쪽에서 먼저 찾습니다. 테스트 실행기와 vite-plus/test에서 불러오는 API가 서로 다른 복사본을 가리켜 내부 상태가 갈라지는 일을 줄이려는 선택입니다. 도구 통합에서 버전 정합성이 왜 중요한지 보여줍니다.

3기술 스택 전체 지도

이 제품은 데이터베이스를 둔 웹 서비스가 아니라 개발자 컴퓨터와 CI에서 실행하는 도구입니다. 따라서 백엔드는 서버 API보다 실행 코어에 해당합니다. 프론트엔드도 제품의 필수 웹 화면과 문서 사이트를 구분해서 봐야 합니다.

실행 코어: Rust가 맡는 백엔드 역할

선언은 루트 Cargo.toml, 잠금 값은 Cargo.lock 기준입니다. crates/vp_global_cli/Cargo.toml은 vp 실행 파일을 정의하고, packages/cli/binding/Cargo.toml은 crate-type = ["cdylib"]로 Node.js가 불러올 네이티브 라이브러리를 만듭니다.

Rust 최소 버전 선언이 있어도 이 저장소 전체를 stable Rust만으로 빌드할 수 있다고 읽으면 안 됩니다. rust-toolchain.toml은 fspy의 사전 로드 라이브러리 빌드에 필요한 -Z bindeps를 nightly 선택 이유로 설명합니다. Windows용 vp_trampoline도 별도 설정으로 표준 라이브러리를 빌드합니다.

TypeScript 연결부와 실제 포함 도구

모든 도구가 같은 방식으로 들어오는 것은 아닙니다. packages/cli/toolchain.config.json은 Vite와 tsdown을 bundled, Vitest·Oxlint·Oxfmt를 dependency, Vite Task를 compiled로 구분합니다. README의 “단일 의존성”은 사용자의 진입점이 단순하다는 뜻이며, 내부 npm 의존성이 하나라는 뜻은 아닙니다.

// packages/cli/package.json의 핵심 부분
{
  "version": "1.4.0",
  "dependencies": {
    "vite": "workspace:@voidzero-dev/vite-plus-core@*",
    "vitest": "catalog:",
    "oxlint": "catalog:",
    "oxfmt": "catalog:"
  }
}

vite라는 의존성 이름이 내부 코어 패키지를 가리킵니다. packages/cli/BUNDLING.md는 배포 시 이 관계를 정확한 npm 별칭으로 바꾸고, CLI와 플러그인이 같은 코어를 보도록 유지한다고 설명합니다. 이름을 단순히 바꾸는 것보다 같은 모듈을 공유하도록 보장하는 일이 중요합니다.

프론트엔드: 제품의 필수 GUI와 문서 사이트 구분

주 사용 인터페이스는 터미널입니다. 문서 사이트는 docs/의 VitePress와 Vue로 구성되며, 웹 앱을 만드는 사용자는 React·Vue 등 자신의 프레임워크를 따로 선택합니다. 문서가 Vue로 작성됐다고 Vite+가 Vue 전용 빌드 도구가 되는 것은 아닙니다.

docs/는 별도의 pnpm-lock.yaml을 둡니다. 루트 catalog에 적힌 Vue ^3.5.35와 VitePress ^2.0.0-alpha.15를 문서 패키지의 직접 선언과 혼동하지 맙시다. 같은 이름의 의존성도 어느 패키지의 선언인지 확인해야 합니다.

인프라·빌드: 도구 자체를 배포하는 공정

• 워크스페이스: Rust는 Cargo resolver 3, JavaScript는 pnpm workspace로 여러 패키지를 관리합니다. vp_trampoline은 Cargo 워크스페이스에서 제외된 별도 패키지입니다.
• 상류 소스 고정: packages/tools/.upstream-versions.json에 Vite·Rolldown·oxc-node의 커밋을 적고, .github/actions/clone/action.yml이 각각 받아옵니다.
• CI: .github/workflows/ci.yml의 CLI E2E 행렬은 Linux x64 + Node.js 22.18.0, macOS arm64 + Node.js 24.11.0, Windows x64 + Node.js 26.0.0의 세 조합을 명시합니다.
• 설치 재현성: .github/actions/setup-ci-node/action.yml의 비 Linux 경로는 pnpm install --frozen-lockfile --ignore-scripts를 사용합니다.
• 컨테이너: docker/Dockerfile은 debian:bookworm-slim을 바탕으로 Git·C/C++ 빌드 도구·Python 등을 넣는 개발·CI용 이미지입니다.

4아키텍처 심화 분석

아래 구조도는 vp dev처럼 JavaScript 도구에 위임하는 대표 경로입니다. 모든 명령이 이 전체 경로를 통과하지는 않습니다. 환경·패키지 관리자 명령 중에는 글로벌 Rust CLI가 직접 처리하는 경로도 있습니다.

NAPI 호출은 새 서버에 보내는 요청이 아닙니다. Node.js 프로세스 안에 불러온 Rust 네이티브 모듈과의 호출입니다. 반대로 도구를 자식 프로세스로 실행하는 부분은 운영체제의 프로세스 경계를 넘습니다. 두 종류의 경계를 구별해야 흐름이 보입니다.

설계 1. 로컬 우선 위임과 실행기 교체

crates/vp_global_cli/src/js_executor.rs의 JsExecutor::resolve_local_vite_plus_package_dir()는 Oxc Resolver로 vite-plus/package.json을 찾습니다. 이어 resolve_local_vite_plus()가 dist/bin.js의 존재를 검사합니다. prepare_js_entry()는 그 경로가 있으면 선택하고, 없으면 글로벌 설치의 bin.js를 택합니다.

이 구조 덕분에 한 머신의 글로벌 입구를 유지하면서 프로젝트마다 다른 CLI 버전을 사용할 수 있습니다. 단, 모든 명령이 무조건 로컬 우선인 것은 아닙니다. 같은 파일의 delegate_migrate()는 로컬 버전이 글로벌보다 오래된 업그레이드 상황에서 글로벌 마이그레이션으로 올려 보내는 별도 정책을 가집니다.

// packages/cli/src/bin.ts: run()에 전달하는 항목 일부
const exitCode = await run({
  nodeExecPath: process.execPath,
  lint,
  pack,
  fmt,
  vite,
  test,
  doc,
  // 이 밖에 설정 resolver, 인자, 패키지 경로 등을 전달
});

위 코드는 핵심 항목만 발췌한 것입니다. packages/cli/binding/src/lib.rs의 CliOptions는 이 함수들을 ThreadsafeFunction으로 받습니다. create_resolver()는 JS 콜백이 반환한 Promise를 기다려 bin_path와 envs를 Rust 실행 계층의 결과로 바꿉니다.

초보자가 볼 지점은 Rust가 npm 패키지의 모든 배치 규칙을 혼자 구현하지 않는다는 것입니다. TypeScript 쪽의 packages/cli/src/resolve-test.ts나 packages/cli/src/resolve-vite.ts가 경로를 알아내고, Rust는 정해진 결과 형태를 이용합니다. 언어를 나눌 때 책임도 함께 나누는 사례입니다.

설계 2. 정적 분석 우선, 알 수 없을 때만 실행

crates/vp_static_config/src/lib.rs의 resolve_static_config()는 Oxc Parser로 설정을 읽습니다. 설정 파일 자체를 실행하지 않고 AST에서 값을 추출합니다. packages/cli/binding/src/cli/handler.rs의 VitePlusConfigLoader::load_user_config_file()은 그 결과의 run 필드에 따라 세 갈래로 움직입니다.

// 학습용 비교: 첫 번째 run은 정적으로 읽을 수 있음
export default {
  run: { tasks: { hello: { command: 'node hello.js' } } },
};

// 변수의 실제 값까지 따라 계산하지 않으므로 대체 경로 필요
const tasks = makeTasks();
export default { run: { tasks } };

이 예시는 서로 다른 두 설정을 비교한 것이므로 한 파일에 함께 넣지는 않습니다. 실제 구현의 FieldMap은 내부에 open이라는 상태를 둡니다. { run: oldRun, ...extra }에서는 뒤의 전개가 run을 바꿀 수 있습니다. extract_object_fields()는 전개를 만나면 앞서 모은 필드를 지우고, 뒤에서 명시한 값만 확실한 정보로 남깁니다.

정적 분석기의 중요한 능력은 모든 값을 계산하는 것이 아니라, 확실히 아는 값과 아직 모르는 값을 구분하는 것입니다.

대체 경로인 packages/cli/src/resolve-vite-config.ts의 resolveUniversalViteConfig()는 설정을 로딩하고 lint, fmt, check, run, staged 등을 JSON으로 돌려줍니다. 정적 추출이 있다고 해서 모든 명령에서 JavaScript 실행이 없어지는 것은 아닙니다.

설계 3. 여러 검사를 순서 있는 하나의 작업으로 만들기

packages/cli/binding/src/check/mod.rs의 execute_check()는 검사기를 단순히 동시에 켜지 않습니다. 설정과 옵션을 읽고, 형식 검사·수정 뒤 린트 단계를 실행하며, 수정 모드에서는 마지막 포맷을 다시 적용할 수 있습니다.

왜 마지막 포맷이 필요할까요? 린터의 자동 수정이 중괄호를 추가하면 처음 포맷했을 때와 코드 모양이 달라질 수 있기 때문입니다. “수정 단계들의 순서를 어떻게 정해야 최종 결과가 안정적인가”라는 작은 작업 흐름 설계입니다.

// 학습용 최소 설정: 두 옵션을 함께 켬
import { defineConfig } from 'vite-plus';

export default defineConfig({
  lint: {
    options: {
      typeAware: true,
      typeCheck: true,
    },
  },
});

packages/cli/binding/src/check/analysis.rs의 lint_config_type_check_enabled()는 두 옵션의 논리곱을 사용합니다. --no-lint는 린트 규칙 단계를 끄더라도 활성화된 타입 검사는 남길 수 있습니다. --no-fmt --no-lint를 주고 타입 검사도 꺼져 있으면 execute_check()는 검사할 것이 없다는 메시지를 출력하고 종료 상태 1을 반환합니다.

다른 학습 포인트도 있습니다. 결과 분석기가 도구의 요약 출력을 읽으므로, 이 함수는 린트 호출에 --format=default를 넣습니다. GitHub Actions 환경에서 출력 형식이 달라져 파서가 오판하는 일을 막기 위해서입니다. 외부 도구의 출력도 통합 계층에서는 하나의 계약이 됩니다.

설계 4. 잠금 충돌을 재시도하되, 이미 끝난 일은 반복하지 않기

분석 기준 커밋의 주제는 Git 설정 잠금입니다. 연결된 여러 worktree가 같은 Git 설정을 쓰면, 동시에 실행한 vp config가 config.lock을 두고 충돌할 수 있습니다. 핵심 구현은 Rust가 아닌 packages/cli/src/config/hooks.ts의 writeGitConfig()에 있습니다.

// 실제 상수와 제어 흐름을 줄인 의사 코드
const delays = [50, 100, 200, 400, 800];
let result = writeOnce();
for (const delay of delays) {
  if (!isLockFailure(result.status)) break;
  wait(delay);
  if (isApplied()) return success;
  result = writeOnce();
}
return result;

실제 상수 GIT_CONFIG_LOCK_RETRY_DELAYS_MS는 [50, 100, 200, 400, 800]입니다. 잠금 실패 상태 255와 0xffffffff일 때만 기다립니다. 최초 시도에 더해 최대 다섯 번 재시도하고, 명시한 대기 합계는 쓰기 한 번당 최대 1.55초입니다. Git 실행 시간까지 포함한 전체 명령 시간의 상한은 아닙니다.

gitConfigSet()은 값이 이미 같으면 쓰지 않습니다. 기다린 뒤에도 isApplied()로 다시 읽어, 다른 프로세스가 원하는 값을 저장했다면 성공으로 끝냅니다. Git 자체 대기와 중복되지 않도록 core.configLockTimeout=0도 명령 인자로 지정합니다.

이를 멱등성과 지수형 재시도의 조합으로 읽을 수 있습니다. 다만 sleepSync()는 Atomics.wait()로 현재 스레드를 멈춥니다. 짧게 끝나는 설정 CLI에서 택한 방식이며, 장시간 동작하는 웹 서버의 요청 처리에 그대로 옮기는 방식은 별도 검토가 필요합니다.

packages/cli/src/config/__tests__/hooks.spec.ts에는 값이 같을 때 잠금을 새로 잡지 않는 경우, 잠금이 풀리기를 기다리는 경우, 다른 실행이 같은 값을 쓴 경우를 다루는 테스트가 있습니다. 기능 설명과 테스트 시나리오를 나란히 읽으면 재시도의 목적이 더 선명해집니다.

5디렉토리 구조 해부

아래는 주요 경로를 추린 지도입니다. 파일 경로는 모두 저장소 루트 기준입니다. 디렉토리 이름만 외우기보다, “이 폴더가 어느 실행 경계를 책임지는가”를 함께 적어 보세요.

트리에 없는 중요한 엔진

Vite와 Rolldown의 본체 소스가 이 저장소에 모두 직접 들어 있는 구조는 아닙니다. .github/actions/clone/action.yml은 별도 저장소의 고정 커밋을 각각 vite/, rolldown/, oxc-node/로 가져옵니다. Vite Task 크레이트도 Cargo.toml의 Git 의존성입니다. 이 경계를 알아야 통합 코드의 줄 수를 엔진 전체 규모로 오해하지 않습니다.

packages/core/build.ts에는 buildVite(), bundleRolldown(), bundleTsdown(), mergePackageJson()이 있습니다. packages/core/build-support/rewrite-imports.ts의 RewriteImportsPlugin은 import 경로를 코어 패키지 쪽으로 바꿉니다. 빌드 스크립트도 제품의 모듈 구성을 결정하는 소스입니다.

실제로 센 언어별 규모

커밋 d3d9f57에서 Git이 추적하는 4,949개 경로를 대상으로 확장자별 물리적 줄 수를 합산했습니다. 빈 줄·주석·테스트·예제·생성 파일도 포함합니다. TypeScript는 .ts/.tsx/.mts/.cts, JavaScript는 .js/.jsx/.mjs/.cjs를 합쳤습니다.

이 표는 선택한 확장자의 집계이며 모든 형식을 합친 전체 줄 수 표는 아닙니다. 숫자는 코드 복잡도나 품질의 점수가 아닙니다. 특히 YAML에는 큰 잠금 파일이 들어가고, 테스트 입력도 파일 수를 늘립니다. 별도 의존성인 Vite·Rolldown·Vite Task의 전체 소스 규모는 포함하지 않습니다.

6학습 포인트 (기술별)

처음부터 전체 저장소를 읽으려 하지 않아도 됩니다. 한 기술마다 “읽을 파일 하나, 설명할 동작 하나, 바꿔 생각할 입력 하나”를 정하면 학습 범위가 구체적이 됩니다.

문법을 이해했다는 기준은 코드를 그대로 따라 쓰는 것이 아니라, 입력이 달라졌을 때 어느 분기로 가는지 설명할 수 있는가입니다.

Rust: “에러가 났다”를 두 층으로 나누기

execute_check()의 반환형은 Result<ExitStatus, Error>입니다. 바깥 Result는 실행 과정의 오류를 표현하고, 안쪽 종료 상태는 실행한 검사가 성공했는지를 표현합니다. 코드에 린트 문제가 있는 것과 프로세스를 시작하지 못한 것은 사용자에게 다른 안내가 필요합니다.

// 설명용 모델: 실제 함수를 복제한 코드는 아님
enum CheckOutcome {
    Passed,
    DiagnosticsFound,
    CouldNotStart,
}

// 세 결과를 모두 단순한 false로 바꾸면 복구 방법도 사라짐

TypeScript: 타입은 설정을 설명하는 문서이기도 하다

packages/cli/src/define-config.ts는 Vite의 UserConfig에 필드를 추가합니다. 이를 모듈 보강이라고 부릅니다. check.fmt와 check.lint의 주석을 읽으면, 이 설정은 통합 검사에만 적용되고 개별 vp fmt와 vp lint에는 적용되지 않는다는 계약도 알 수 있습니다.

타입이 있다고 값이 실행 시점에도 자동 검증되는 것은 아닙니다. Rust 쪽에서는 JSON을 UserRunConfig로 역직렬화하는 단계가 따로 있습니다. 편집기의 안내, 데이터 전달, 실행 시점 검증을 세 층으로 나누어 보세요.

캐시: “재실행하지 않아도 같은가”를 묻기

docs/config/run.md의 기본값은 run.cache = { scripts: false, tasks: true }입니다. 즉 package.json 스크립트는 기본적으로 캐시하지 않고, vite.config.ts에 정의한 작업은 기본적으로 캐시합니다. 모든 vp run이 자동으로 같은 캐시 정책을 가지지는 않습니다.

// 학습용 작업 설정
import { defineConfig } from 'vite-plus';

export default defineConfig({
  run: {
    tasks: {
      build: {
        command: 'vp build',
        cache: { env: ['NODE_ENV'] },
      },
    },
  },
});

NODE_ENV가 결과를 바꾸는 입력이라면 캐시 판단에도 영향을 주어야 합니다. 이 예시는 설정 계약을 배우기 위한 것입니다. 파일·환경 자동 추적과 스케줄러의 내부 구현은 별도 Vite Task 저장소를 더 읽어야 설명할 수 있습니다.

7하드웨어 / 시스템 요구사항

Vite+로 작은 웹 앱을 개발하는 것과 Vite+ 자체의 Rust·네이티브 모듈·상류 도구까지 빌드하는 것은 부담이 다릅니다. 요구사항을 판단할 때는 완성된 도구를 쓰는 경우와 그 도구를 만드는 경우를 먼저 나누어야 합니다.

글로벌 vp는 사전 설치된 Node.js 없이 시작할 수 있는 Rust 실행 파일입니다. 그러나 Vite·Vitest 같은 JavaScript 도구를 쓸 때는 실제 Node.js가 필요하며, 관리 기능이 적절한 런타임을 준비합니다. “글로벌 바이너리가 독립적”이라는 말과 “Node.js를 전혀 쓰지 않음”은 다릅니다.

바이너리의 플랫폼과 런타임의 플랫폼을 함께 확인

packages/cli/package.json의 napi.targets는 8개 대상을 명시합니다. macOS x64·arm64, Windows x64·arm64, Linux x64·arm64의 GNU·musl 조합입니다. docs/guide/index.md는 Linux x64 musl을 실험적 대상으로 분류하며, Alpine에서는 관리형 Node.js 실행을 위해 libstdc++가 필요하다고 설명합니다.

운영체제 이름이 같아도 C 표준 라이브러리가 다르면 같은 네이티브 파일을 사용할 수 없습니다. 특히 Linux의 GNU와 musl 대상이 나뉘는 이유를 이해하면, npm의 선택적 네이티브 패키지가 왜 필요한지도 배울 수 있습니다.

학습 환경의 규모를 잡는 보수적인 기준

위 RAM·저장공간 숫자는 공식 최소 사양이나 실측 결과가 아닌 학습 계획용 추정입니다. 새 장비를 고르는 기준으로 단정하지 말고, 작은 범위에서 시작해 실제 사용량을 보며 확장하세요. 병목은 GPU보다 메모리·디스크·병렬 컴파일에서 생길 가능성을 먼저 살펴보는 편이 합리적입니다.

컨테이너도 역할을 구분해서 읽기

docker/Dockerfile은 개발·CI·빌드 단계용으로 여러 도구를 포함합니다. 기본 사용자는 vp이고, 추가 개발 패키지를 설치할 수 있도록 암호 없는 sudo 설정도 둡니다. docs/guide/docker.md는 제품 배포에서는 다단계 빌드로 결과물과 필요한 Node.js만 작은 실행 이미지에 옮기는 방식을 안내합니다.

8직접 해볼 수 있는 실습 과제

과제 1·2·4는 읽기와 손으로 추적하기만으로 진행할 수 있습니다. 과제 3의 실행은 Vite+가 준비된 별도 예제 프로젝트에서 선택적으로 진행합니다. 과제 5도 우선 설계와 예측 결과를 작성하고, 구현은 독립된 연습 파일에서 확장하면 됩니다.

각 실습은 실행했다는 기록보다, 예상한 결과와 그 근거가 되는 코드 위치를 함께 남기는 것을 목표로 합니다.

{
  "scripts": {
    "dev": "custom-dev-server",
    "test": "jest",
    "build": "node compile.js"
  }
}

// A
export default { plugins: [] };
// B
export default { run: { tasks: {} } };
// C
export default { run: { tasks: {} }, ...extra };

// 타입 오류를 포함하는 학습용 입력
export const total: number = '세 개';

// 비교할 명령
vp check
vp check --no-fmt
vp check --no-fmt --no-lint

문서 메타데이터 생성 -> 사이트 빌드 -> 배포
                              ^
                              |
                         링크 검사 완료

9관련 기술 심화 학습 로드맵

주당 3~5시간의 학습을 가정한 예시입니다. Rust가 처음이라면 3주 차를 두 주로 늘려도 좋습니다. 모든 구성 요소를 설치하는 일보다 매주 하나의 설명 가능한 결과물을 남기는 데 집중합니다.

마지막 목표는 Vite+를 통째로 재구현하는 것이 아니라, 왜 어떤 책임은 Rust에 있고 어떤 책임은 TypeScript에 있는지 자기 말로 설명하는 것입니다.

각 주차를 마칠 때 답할 질문

1. 입력: 이 단계가 받는 값은 명령 인자, 설정, 파일 경로 중 무엇인가?
2. 소유권: 실행할 도구와 버전을 최종적으로 고르는 쪽은 어디인가?
3. 실패: 실패가 값으로 돌아오는가, 예외가 되는가, 종료 코드가 되는가?
4. 재현성: 다음 실행이 같은 결과를 내기 위해 무엇을 고정해야 하는가?

10핵심 키워드 사전

영어 식별자를 정확히 기억하는 것도 중요하지만, 코드 리뷰에서는 동작을 문장으로 풀어 말해 보세요. “fallback을 쓴다”보다 “정적으로 값을 읽지 못하면 Node.js에서 설정을 로딩한다”가 이 설계를 더 잘 설명합니다.

11참고 링크

공식 저장소와 사용 문서

• Vite+ 공식 저장소 — 코드·이슈·설계 문서의 출발점
• v1.4.0 릴리스 — 2026-10-23 기준 최신 릴리스
• 시작 가이드 — 글로벌 CLI와 프로젝트 CLI 사용법
• 통합 검사 가이드 — 타입 검사 활성화 조건과 옵션
• 작업 실행 가이드 · 작업 설정 — 스크립트·작업·캐시 정책
• 환경 관리 가이드 · Docker 가이드 — 런타임과 빌드 환경
• setup-vp — GitHub Actions에서 사용하는 별도 공식 설치 액션

커밋에 고정한 핵심 구현

• 글로벌 CLI의 JavaScript 위임 — 프로젝트별 CLI와 실행 환경 선택
• TypeScript 명령 진입점 · Rust NAPI 연결부
• 정적 설정 분석기 · 정적 분석과 JS 대체 경로의 연결
• 통합 검사 실행 순서 · 타입 검사 조건과 출력 분석
• Git 설정의 멱등적 쓰기·재시도 · 관련 테스트
• Rust 의존성 선언 · JavaScript 공통 catalog · CI 설정

관련 기술을 더 깊게 공부할 때

• Rust 공식 책 · Cargo 워크스페이스
• NAPI-RS — Node.js와 Rust를 연결하는 네이티브 모듈
• Oxc — 파서·린터·포매터 등 JavaScript 도구의 기반
• Vite · Rolldown · tsdown
• Vitest — 테스트 실행과 프로젝트 설정
• Vite Task — 작업 실행·추적·캐시 엔진의 별도 소스
• TypeScript 선언 병합·모듈 보강 · pnpm catalog

현재 상태 (2026-10-23 확인)