Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Vite+는 Vite, Vitest, Oxlint 등 다양한 개발 도구들을 통합하여 AI 에이전트가 애플리케이션을 구축하고 검증하는 워크플로우를 혁신했습니다. 이를 통해 프로젝트 생성부터 테스트, 빌드까지의 과정이 명확하게 표준화되었습니다. 특히, 이 방식은 로컬 환경과 CI 간의 불일치 문제를 해결하며 개발 프로세스의 신뢰성을 높이는 데 중점을 둡니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 HN Show HN (AI)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기어떤 프로젝트는 47개의 개발 의존성(development dependencies), 7개의 설정 파일, 그리고 에이전트에게 모든 것을 실행하는 방법을 설명하는 Markdown 파일을 가지고 있었습니다. 새벽 2시에 저는 로컬 검사와 CI 간의 차이를 디버깅하고 있었습니다. 코드는 완성되었지만, 주변 도구들은 그렇지 못했습니다. Vite+를 네 개의 프로젝트에 걸쳐 3주 동안 사용한 후, 새로운 Vite 앱을 위한 간단한 규칙이 생겼습니다. 바로 제가 AI에게 주는 첫 번째 프롬프트에 그 내용을 담는 것입니다.
vp create로 프로젝트를 생성하게 하고, 이후 vp check, vp test, 그리고 vp build로 작업 결과를 검증하도록 합니다. - 속도 자체도 좋지만, 저에게 더 큰 이점은 에이전트, 저, CI 모두를 위한 명확한 워크플로우가 있다는 점입니다.vp migrate를 마이그레이션의 시작으로 간주합니다. 여전히 diff, 테스트, 빌드 동작을 검토합니다.제 명령어들은 ESLint, Prettier, TypeScript, 테스트 러너, 그리고 package.json 스크립트에 걸쳐 분산되어 있었습니다. 에이전트를 프로젝트에 투입했을 때, 그 첫 번째 임무는 어떤 명령어가 올바른 것인지 파악하는 것이었습니다. 저는 이를 설명하기 위한 지침을 작성해야 했습니다. 그러면 또 다른 파일을 유지 관리해야 했죠. 정말 시간 절약이 되는 일일까요?
문제는 단순히 파일의 개수만이 아니었습니다. 한때, 제 로컬 설정과 CI가 생성된 파일을 다르게 검사했습니다. 에이전트는 한 가지 결과를 보고했지만, 파이프라인은 다른 결과를 보았습니다. 컴포넌트 생성이 빨라진다고 해서 이 문제가 해결되는 것은 아닙니다.
Vite+는 일상적인 작업을 vp 아래로 통합합니다. 즉, 개발 및 빌드를 위한 Vite, 테스트를 위한 Vitest, 검사를 위한 Oxlint 및 Oxfmt, 라이브러리를 위한 tsdown, 그리고 작업(tasks)을 위한 Vite Task가 있습니다. 이들의 설정은 vite.config.ts에 유지할 수 있습니다. 여전히 package.json, tsconfig, 그리고 프로젝트에 따라 프레임워크 설정 파일이 존재합니다.
전역적으로 사용할 수 있습니다. 전역 설치는 선택 사항이며, 패키지 관리자를 통해 로컬 종속성으로도 Vite+를 실행할 수 있습니다. vp install
사용하는 패키지 관리자에 따라 작동하므로, Vite+가 npm이나 pnpm을 대체하지 않습니다.
vp create terminal output while setting up a project
Vite+ 문서는 AI 어시스턴트를 위한 프롬프트를 포함하고 있습니다. 유용한 시작점이지만, 저는 이를 프로젝트에 맞게 조정합니다. 제 목표는 구체적입니다. 즉, 에이전트가 Vite+를 사용하여 앱을 설정하고 첫 페이지 생성 후 조용히 포기하는 것이 아니라 계속 진행하도록 하는 것입니다.
Create a new React + TypeScript app on Vite using Vite+.
First read the current `vp create` guide and run `vp help create`.
Inspect the target directory and do not overwrite existing files.
...
저는 모든 프로젝트에서 curl을 통한 전역 설치를 요구하지 않습니다. 일회성 설정의 경우, npx [email protected] vp create와 같은 것이 충분합니다. 이미 구축된 프로젝트에서는 에이전트가 선택한 패키지 관리자를 통해 로컬 CLI를 실행할 수 있습니다. 또한 create-vite도 금지하지 않습니다: vp create vite는 해당 템플릿을 사용합니다. 중요한 것은 에이전트가 의도된 설정을 따르고 일관된 도구 체인을 유지하는 것입니다.
에이전트에게 자유를 주었을 때, 저는 Prettier와 Oxfmt 두 가지 포맷터, 세 개의 lockfile, 그리고 신뢰할 수 없는 CI까지 갖게 되었습니다. 두 번째 포맷터를 금지하고 하나의 lockfile을 요구하는 것은 미적인 선호도가 아닙니다. 다시 정리하고 싶지 않은 두 가지 실수입니다.
코드를 변경한 후, 저는 vp check를 실행합니다. 이는 포맷팅과 린트를 확인하며, 설정에서 typeAware와 typeCheck가 모두 활성화된 경우 TypeScript도 확인합니다. vp create로 생성된 새 프로젝트는 기본적으로 이들을 활성화합니다. 기존 프로젝트에서는 단순히 녹색 결과라고 가정하는 대신 설정을 검증함으로써 타입이 건전한지까지 확인합니다.
기존 워크플로우와의 차이점은 다음과 같습니다:
1# Before: it depended on each project's scripts.
2npm run format:check
3npm run lint
...
vp check --fix
일부 발견된 문제점들을 자동으로 수정할 수 있습니다. 그 후, 저는 diff를 읽고 검사를 다시 실행합니다. 녹색의 lint 결과가 앱이 올바르게 작동하는지 여부를 알려주지는 않습니다. 저는 동작(behavior)을 위한 vp test와 애플리케이션 빌드를 확인하기 위한 vp build가 필요합니다.
또한 이 규칙을 리포지토리의 에이전트 지침에 넣었습니다. 일주일 후에 프로젝트로 돌아왔을 때, 새로운 에이전트는 어제의 채팅 내용을 기억하지 못할 것입니다. 하지만 리포지토리는 여전히 그 명령어를 알고 있습니다.
1## 작업을 완료하기 전 확인 사항
2
3- 코드를 변경한 후, `vp check`를 실행하여 모든 오류를 수정합니다.
...
로컬 지침(Local instructions)과 Git 훅(Git hooks)도 도움이 되지만, 우회되거나 비활성화될 수 있습니다. 저는 CI에서도 동일한 검사를 실행합니다. 에이전트가 사람이 개입하지 않은 상태에서 작업하도록 한 실험에서는 병합(merging) 전에 인간의 검토가 여전히 저의 책임이었습니다.
모노레포(monorepo) 환경에서, 워크플로우를 변경한 후 CI 시간이 4분에서 50초로 줄어들었습니다. 프리-커밋 체크는 11초에서 2초 미만으로 떨어졌습니다. 이것들은 저의 프로젝트에서 나온 결과이며, 동일한 조건에서 Vite+와 다른 툴체인(toolchain)을 비교하는 벤치마크가 아닙니다. 성능 향상의 일부는 무엇이 실행되고 어떤 파일들을 검사하느냐에 달려있기 때문에, 다른 설정으로 이 CI 시간을 자동으로 얻을 수는 없습니다.
GitHub Actions benchmark output: classic toolchain, 10.441 seconds
GitHub Actions benchmark output: Vite+, 1.356 seconds
변경된 파일들을 빠르게 확인하기 위해 저는 vp staged와 vp hooks로 관리되는 Git 훅을 사용합니다. 서로 다른 프로젝트들이 다르게 작동할 때, vp toolchain은 활성화된 버전을 보여줍니다. vp toolchain --global은 전역 설치를 보여줍니다. 이것이 제가 예전에 쓰던 방식인 “분명히 업데이트했어”보다 디버깅에 더 유용합니다.
vp staged --verbose terminal output
vp toolchain terminal output showing Vite+ tool versions
alone makes every build faster.## 불편했던 점
vp migrate
이 명령어는 오래된 모노레포에서 약 4분 동안 실행되었습니다. 이 과정에서 ESLint, Prettier, 그리고 기존 tsup 빌드 설정을 변환했으며, 제 경우 아무것도 깨지지 않았습니다. 그렇다고 해서 모든 마이그레이션이 4분이 걸린다는 뜻은 아닙니다. 이전의 lint 설정, 테스트, 훅(hook), 빌드 결과물과 결과를 비교해야 합니다. 플러그인이나 사용자 정의 규칙은 여전히 수동 작업이 필요할 수 있습니다.
또 다른 함정은 내장 명령어와 프로젝트 스크립트 간의 차이입니다. vp build
는 Vite 앱 빌드를 실행합니다. vp run build
은 package.json에 있는 build 스크립트나 해당 이름의 작업을 실행합니다. Next.js 프로젝트에서 에이전트는 vp build
가 next build를 대체한다고 가정해서는 안 됩니다. 동일한 구분이 vp dev
과 vp run dev에도 적용됩니다. Vite+는 다른 템플릿과 함께 작동할 수 있지만, 그것이 해당 명령어의 기능을 바꾸지는 않습니다.
세 번째 문제는 버전 관리입니다. 전역 vp env
은 Node.js와 패키지 관리자를 관리할 수 있습니다. 저는 세 개의 프로젝트를 세 가지 Node 버전을 사용하여 운영하고 있으며, 이 기능 덕분에 전환이 더 쉬워졌습니다. 만약 원하지 않는다면 vp env off로 끌 수 있습니다. vp upgrade
은 전역 CLI를 업데이트하며, 모든 프로젝트의 로컬 vite-plus 패키지를 자동으로 업데이트하는 것은 아닙니다. 저는 이 명령어가 반대되는 가정을 유도하기 때문에 제 에이전트 지침에 이를 명시적으로 작성했습니다.
AI가 새로운 Vite 앱 설정을 시작할 때입니다. 표준화의 비용은 여기서는 작습니다. 하나의 툴체인을 선택하고, 확인 명령을 레포지토리와 CI에 넣으면, 에이전트는 코드 변경부터 검증까지 명확한 경로를 갖게 됩니다. 3주 동안 네 개의 프로젝트를 거치면서 저에게 가장 큰 이점은 기본적인 명령어들을 반복해서 설명할 필요가 없었다는 점입니다.
기존에 빌드와 테스트 스위트가 작동하는 대규모 애플리케이션을 무작정 마이그레이션하지는 않을 것입니다. 자체적인 빌드를 가진 프레임워크라면, 저는 먼저 Vite+의 어떤 부분을 실제로 사용하고 싶은지 결정할 것입니다. 그리고 이미 잘 문서화되고 빠르며 안정적인 스택을 가지고 있다면, '단 하나의 명령어'라는 약속만으로는 그것을 교체하도록 설득되지 않을 것입니다.
다음번에 Vite 프로젝트를 시작한다면, 첫 번째 프롬프트에 vp create를 넣고, 완료의 정의(definition of done)의 일부로 vp check의 출력, 테스트 결과, 그리고 빌드 결과를 요청하세요. 완성된 앱의 스크린샷도 좋지만, 체크를 통과하는 것이 더 많은 것을 알려줍니다.