Vite 프로젝트 필수 도구 설정 가이드: ESLint, Prettier, Error Lens, Pretty TypeScript Errors

Vite로 프로젝트를 만들었으면 그다음은 개발 환경을 다듬을 차례입니다. 코드를 잘 짜는 것도 중요한데, 잘못된 코드를 바로 알려주는 도구가 곁에 있으면 실수가 눈에 띄게 줄어요.
이 글에서는 Vite + React + TypeScript 프로젝트에 꼭 설치해 두면 좋은 VS Code 확장 4가지의 설치 방법과 설정 방법을 다룹니다. 특히 ESLint는 팀원 모두가 같은 규칙으로 작업할 수 있게 상세하게 다뤘어요.
시작하기 전에
- Vite + React + TypeScript 프로젝트가 이미 만들어져 있어야 합니다 (없으면
npm create vite@latest my-app -- --template react-ts로 생성) - VS Code가 설치되어 있어야 합니다
- 예상 소요 시간: 약 20분

프로젝트가 생성되고 자동으로 서버가 실행됩니다. 브우저에서 http://localhost:5173 으로 열어보면 다음과 같이 보여집니다.

1. ESLint — 코드 품질 지킴이
왜 필요한가요?
ESLint는 코드를 분석해서 문제를 찾아 줍니다. 오타, 사용하지 않는 변수, 잠재적 버그 같은 것들이요. 혼자 쓸 때도 좋지만, 팀으로 일할 때 진짜 값어치를 합니다. "여기서는 세미콜론 쓰는 거야 마는 거야?" 같은 논쟁을 코드로 끝낼 수 있거든요.
1-1. VS Code 확장 설치
VS Code 마켓플레이스에서 ESLint (Microsoft)를 설치합니다.
왼쪽 사이드바 확장 아이콘(네모 네 개)을 클릭하고 "ESLint"를 검색하면 바로 나옵니다.

1-2. ESLint 패키지 설치
Vite로 프로젝트를 만들면 ESLint가 이미 설치되어 있고, eslint.config.js 파일도 자동으로 생성됩니다. 하지만 팀에서 쓰기에는 기본 설정이 부족해요. 여기서부터는 팀 프로젝트에 맞게 설정을 다듬어 보겠습니다.
먼저 필요한 패키지를 설치합니다.
cd my-app npm install -D eslint-config-prettier
eslint-config-prettier는 Prettier와 충돌하는 ESLint 규칙을 꺼 줍니다. ESLint가 코드 품질을, Prettier가 코드 스타일을 담당하도록 역할을 나누는 거예요.
1-3. ESLint 설정 파일 작성 (Flat Config)
ESLint 9부터는 eslint.config.js라는 "flat config" 방식을 씁니다. 예전의 .eslintrc.json은 더 이상 권장되지 않아요.
프로젝트 루트에 있는 eslint.config.js를 열고 아래 내용으로 바꿔 주세요.
import js from '@eslint/js' import globals from 'globals' import reactHooks from 'eslint-plugin-react-hooks' import reactRefresh from 'eslint-plugin-react-refresh' import tseslint from 'typescript-eslint' import eslintConfigPrettier from 'eslint-config-prettier' export default tseslint.config( { ignores: ['dist', 'node_modules', 'build'] }, { extends: [ js.configs.recommended, ...tseslint.configs.recommended, ], files: ['**/*.{ts,tsx}'], languageOptions: { ecmaVersion: 2020, globals: globals.browser, }, plugins: { 'react-hooks': reactHooks, 'react-refresh': reactRefresh, }, rules: { ...reactHooks.configs.recommended.rules, 'react-refresh/only-export-components': [ 'warn', { allowConstantExport: true }, ], // === 팀 규칙: 여기를 팀에 맞게 조정하세요 === // 사용하지 않는 변수는 에러 (앞에 _를 붙이면 허용) '@typescript-eslint/no-unused-vars': [ 'error', { argsIgnorePattern: '^_', varsIgnorePattern: '^_', }, ], // console.log 경고 (console.error, console.warn은 허용) 'no-console': ['warn', { allow: ['warn', 'error'] }], // == 대신 === 강제 'eqeqeq': ['error', 'always'], // var 금지 (let, const만 사용) 'no-var': 'error', // const를 쓸 수 있는 곳에서는 const 강제 'prefer-const': 'error', }, }, // Prettier와 충돌하는 규칙 비활성화 (반드시 마지막에 위치) eslintConfigPrettier, )
이 설정에서 짚고 넘어갈 부분이 몇 가지 있습니다.
tseslint.config()는 TypeScript ESLint에서 제공하는 헬퍼 함수로, 설정 배열을 타입 안전하게 만들어 줍니다.
ignores 배열에 dist, node_modules, build를 넣었는데, 빌드 결과물까지 검사하면 쓸데없는 에러가 쏟아지기 때문이에요.
eslintConfigPrettier는 반드시 배열의 맨 마지막에 넣어야 합니다. 앞에서 켠 포매팅 관련 규칙을 꺼 주는 역할이라, 순서가 중요해요.
// === 팀 규칙 === 주석 아래가 팀에서 합의해서 조정할 영역입니다. 위에 적어 둔 다섯 가지 규칙은 대부분의 팀에서 무난하게 쓸 수 있는 기본값이에요. 프로젝트 성격에 맞게 규칙을 추가하거나 빼면 됩니다.
1-4. 팀원 전체가 같은 규칙을 쓰게 만들기
ESLint 설정 파일은 프로젝트에 들어 있으니 Git에 커밋하면 팀원 모두 같은 규칙을 씁니다. 하지만 VS Code 설정도 맞춰야 완전합니다.
프로젝트 루트에 c 폴더를 만들고, 두 파일을 넣습니다.
.vscode/v — 프로젝트 전용 VS Code 설정
{ "editor.formatOnSave": true, "editor.defaultFormatter": "esbenp.prettier-vscode", "editor.codeActionsOnSave": { "source.fixAll.eslint": "explicit" }, "eslint.validate": [ "javascript", "javascriptreact", "typescript", "typescriptreact" ] }
이 설정이 하는 일은 세 가지입니다.
- 파일을 저장하면 Prettier가 자동으로 포맷합니다
- 저장할 때 ESLint가 자동 수정 가능한 문제를 고칩니다
- TypeScript, JSX, TSX 파일에서 ESLint가 동작하도록 명시합니다
.vscode/settings.json은 그 프로젝트에서만 적용되는 설정이라 개인 설정을 덮어쓰지 않아요. 팀 프로젝트에서는 이 파일을 Git에 같이 커밋하는 게 일반적입니다.
.vscode/extensions.json — 추천 확장 목록
{ "recommendations": [ "dbaeumer.vscode-eslint", "esbenp.prettier-vscode", "usernamehw.errorlens", "yoavbls.pretty-ts-errors" ] }
이 파일이 있으면 팀원이 프로젝트를 처음 열 때 VS Code가 "이 프로젝트에서 추천하는 확장이 있습니다"라고 알려 줍니다. 하나하나 찾아서 설치할 필요가 없어져요.
확인하기: eslint.config.js, .vscode/settings.json, .vscode/extensions.json 세 파일이 프로젝트에 있으면 ESLint 설정은 끝입니다.
1-5. 동작 확인
아무 .tsx 파일을 열고 일부러 문제를 만들어 보세요.
// 사용하지 않는 변수 → 빨간 줄이 떠야 합니다 const unusedVariable = 'hello' // == 사용 → 빨간 줄이 떠야 합니다 if (someValue == null) { console.log('test') // console.log → 노란 줄(경고)이 떠야 합니다 }
VS Code 하단의 "문제" 패널(Ctrl+Shift+M)에서 ESLint 경고와 에러를 확인할 수 있습니다.

만약 아무 반응이 없다면:
- VS Code를 다시 시작해 보세요 (설정 변경 후 첫 번째 시도)
- 출력 패널(Ctrl+Shift+U)에서 "ESLint"를 선택하면 에러 로그를 볼 수 있습니다
npx eslint src/명령으로 CLI에서 직접 실행해 봐서 설정 파일 문제인지 확장 문제인지 구분합니다
2. Prettier — 코드 포매터
왜 필요한가요?
Prettier는 코드 스타일을 자동으로 정리해 줍니다. 들여쓰기를 탭으로 할지 스페이스로 할지, 따옴표를 작은따옴표로 할지 큰따옴표로 할지, 세미콜론을 붙일지 말지. 이런 걸 사람이 신경 쓸 필요 없이 저장만 누르면 돼요.
ESLint와 역할이 다릅니다. ESLint는 "이 코드에 버그가 있을 수 있다"를 알려 주고, Prettier는 "이 코드의 모양을 정리한다"예요. 둘을 같이 써야 품질과 스타일을 둘 다 챙길 수 있습니다.
2-1. VS Code 확장 설치
마켓플레이스에서 Prettier - Code formatter를 설치합니다.

2-2. Prettier 설정 파일 만들기
프로젝트 루트에 .prettierrc 파일을 만듭니다.
{ "semi": false, "singleQuote": true, "tabWidth": 2, "trailingComma": "all", "printWidth": 80, "bracketSpacing": true, "arrowParens": "always", "endOfLine": "lf" }
각 옵션의 의미는 이렇습니다.
| 옵션 | 값 | 의미 |
|---|---|---|
semi | false | 세미콜론을 안 붙입니다 |
singleQuote | true | 문자열에 작은따옴표를 씁니다 |
tabWidth | 2 | 들여쓰기 2칸 |
trailingComma | "all" | 마지막 항목 뒤에도 쉼표를 붙입니다 |
printWidth | 80 | 한 줄 최대 80자 |
bracketSpacing | true | 객체 중괄호 안에 공백: { a: 1 } |
arrowParens | "always" | 화살표 함수 인자에 항상 괄호: (x) => x |
endOfLine | "lf" | 줄바꿈 문자를 LF로 통일 (Mac/Linux 기본) |
팀에서 "우리는 세미콜론을 쓴다"라고 합의했으면 "semi": true로 바꾸면 됩니다. 이 파일도 Git에 커밋해서 팀 전체가 같은 스타일을 쓰도록 합니다.
2-3. Prettier 무시 파일
포맷하지 않을 파일을 지정합니다. 프로젝트 루트에 .prettierignore 파일을 만드세요.
dist build node_modules *.min.js
2-4. 동작 확인
먼저 Visual Studio Code를 재시작한 후에 확인하세요.
아무 .tsx 파일을 열고, 의도적으로 들여쓰기를 망가뜨린 뒤 저장(Ctrl+S)해 보세요. 자동으로 깔끔하게 정리되면 Prettier가 잘 동작하고 있는 겁니다.
만약 저장해도 아무 변화가 없다면 .vscode/settings.json에 "editor.formatOnSave": true와 "editor.defaultFormatter": "esbenp.prettier-vscode"가 있는지 확인하세요. 앞에서 ESLint 설정할 때 이미 넣어 뒀다면 여기서 따로 할 건 없습니다.
3. Error Lens — 에러를 인라인으로 보기
왜 필요한가요?
VS Code는 기본적으로 에러가 있는 줄에 빨간 밑줄만 그어 두기 때문에 메시지를 보려면 마우스를 올려야 하잖아요. Error Lens는 에러 메시지를 해당 라인 옆에 바로 띄워 줍니다. 시선을 따로 옮기지 않아도 뭐가 잘못됐는지 바로 보여요.
3-1. 설치
마켓플레이스에서 Error Lens를 설치합니다.
설치하면 바로 동작합니다. 별도 설정이 필요 없어요.
3-2. 동작 확인
ESLint 에러가 있는 파일을 열어 보세요. 빨간 밑줄 옆에 에러 메시지가 인라인으로 표시되면 잘 동작하고 있는 겁니다. 경고는 노란색, 에러는 빨간색으로 구분됩니다.
메시지가 너무 길어서 거슬린다면 VS Code 설정에서 조정할 수 있어요.
{ "errorLens.messageMaxChars": 100 }
이 설정은 개인 취향이라 .vscode/settings.json에 넣지 않아도 됩니다. 개인 설정(Ctrl+,)에서 조정하세요.
4. Pretty TypeScript Errors — 타입 에러를 읽기 좋게
왜 필요한가요?
TypeScript 에러 메시지는 길고 읽기 힘든 경우가 많습니다. 제네릭이 여러 겹 겹치면 에러 한 줄이 화면 밖으로 나가기도 하죠. Pretty TypeScript Errors는 그런 메시지를 색상이 들어간 박스로 다시 그려 줘서, 어떤 타입이 어디에서 안 맞았는지 바로 파악할 수 있게 해 줘요.
4-1. 설치
마켓플레이스에서 Pretty TypeScript Errors를 설치합니다.
이것도 설치만 하면 바로 동작합니다. 설정할 건 없어요.
4-2. 동작 확인
타입 에러가 있는 코드를 만들어 보세요.
const name: number = 'hello' // 타입 불일치 에러
에러에 마우스를 올렸을 때 기존의 긴 텍스트 대신 색상이 구분된 깔끔한 박스가 뜨면 잘 동작하는 겁니다.

전체 설정 파일 체크리스트
설정이 끝나면 프로젝트에 아래 파일이 있어야 합니다.
my-app/ ├── .vscode/ │ ├── settings.json ← VS Code 프로젝트 설정 │ └── extensions.json ← 추천 확장 목록 ├── eslint.config.js ← ESLint 규칙 ├── .prettierrc ← Prettier 스타일 설정 ├── .prettierignore ← Prettier 제외 파일 ├── package.json └── ...
이 파일들을 전부 Git에 커밋해 두세요. 팀원이 프로젝트를 clone하고 npm install만 실행하면 같은 개발 환경이 만들어집니다.
팀원 온보딩 순서
새 팀원이 들어왔을 때 안내할 순서예요.
- 프로젝트를
git clone합니다 npm install을 실행합니다- VS Code로 프로젝트 폴더를 엽니다
- "추천 확장을 설치하시겠습니까?" 팝업이 뜨면 "모두 설치"를 클릭합니다
- 아무
.tsx파일을 열고 저장해 봅니다. 자동 포맷이 동작하면 완료입니다
.vscode/extensions.json과 .vscode/settings.json 덕분에 확장 설치와 설정을 반자동으로 처리할 수 있어요. "내 컴퓨터에서는 되는데 네 컴퓨터에서는 안 돼"와 같은 상황을 방지할 수 있습니다.
문제 해결
ESLint 에러가 안 뜹니다
- VS Code 하단 상태바에 "ESLint" 표시가 있는지 확인하세요. 없으면 확장이 비활성화된 상태입니다
- 출력 패널(Ctrl+Shift+U) → 드롭다운에서 "ESLint" 선택 → 에러 로그 확인
- 터미널에서
npx eslint src/를 실행해서 CLI로도 에러가 나는지 확인합니다. CLI에서 에러가 뜨면 설정 파일 문제이고, 안 뜨면 VS Code 확장 문제입니다
Prettier와 ESLint가 충돌합니다
저장할 때 코드가 포맷됐다가 다시 원래대로 돌아가는 현상이 생긴다면 두 도구가 같은 규칙을 서로 다르게 적용하고 있는 겁니다.
eslint.config.js에서 eslintConfigPrettier가 배열의 맨 마지막에 있는지 확인하세요. 이 설정이 Prettier와 겹치는 ESLint 규칙을 꺼 줍니다.
Error Lens 메시지가 너무 많습니다
정보(info) 수준의 메시지까지 표시되어 화면이 산만해질 수 있어요. VS Code 설정에서 표시 수준을 조절합니다.
{ "errorLens.severityFilter": ["error", "warning"] }
이렇게 하면 에러와 경고만 표시하고 정보는 숨깁니다.
Windows에서 줄바꿈 관련 에러가 납니다
.prettierrc의 "endOfLine": "lf" 때문에 CRLF로 저장된 파일에서 에러가 날 수 있습니다. Git 설정에서 줄바꿈 처리를 맞춰 주세요.
git config core.autocrlf input
이 설정은 커밋할 때 CRLF를 LF로 변환하고, 체크아웃할 때는 그대로 둡니다.






댓글
댓글을 작성하려면 이 필요합니다.