콘텐츠 대표 이미지 - JavaScript 코드 품질 관리와 ESLint · Prettier 완전 정복 가이드
📘 JavaScript 개발 가이드

JavaScript 코드 품질 관리와 ESLint · Prettier 완전 정복 가이드

코드가 더럽다고? 이제 ESLint랑 Prettier로 깔끔하게 정리해버리자 🧹✨

야 솔직히 말해봐 ㅋㅋㅋ 혼자 개발할 때 코드 스타일 신경 쓴 적 있어?
변수명은 camelCase였다가 snake_case였다가, 세미콜론은 있다가 없다가, 들여쓰기는 2칸이었다가 4칸이었다가... 😅
그러다 팀 프로젝트 들어가면 진짜 대참사 나는 거 알지? ㅋㅋㅋ

근데 이게 단순히 "보기 싫다"의 문제가 아니야. 코드 품질은 버그 발생률, 유지보수 비용, 팀 생산성에 직결되는 진짜 중요한 이슈거든.
오늘은 JavaScript 개발자라면 반드시 알아야 할 ESLint와 Prettier를 제대로 파헤쳐볼게! 🔥

JavaScript 코드 품질 관리 흐름 💻 코드 작성 ESLint 문법 오류 검사 코드 규칙 적용 Prettier 코드 포맷팅 스타일 통일 ✅ 깔끔하고 안전한 코드! 🔍 ESLint가 잡아주는 것들 • 미사용 변수 (no-unused-vars) • 정의되지 않은 변수 사용 • 잠재적 버그 패턴 • 코딩 컨벤션 위반 • 보안 취약 패턴 ✨ Prettier가 정리해주는 것들 • 들여쓰기 (2칸 or 4칸) • 세미콜론 유무 • 따옴표 스타일 통일 • 줄 길이 제한 • 괄호·쉼표 스타일 🚀 기대 효과 • 버그 사전 예방 • 팀 코드 스타일 통일 • 코드 리뷰 효율 상승 • 유지보수 비용 절감 • 개발 생산성 향상
🤔 코드 품질이 왜 이렇게 중요해?

먼저 "코드 품질"이 뭔지부터 제대로 짚고 가자.
코드 품질은 단순히 "돌아가냐 안 돌아가냐"의 문제가 아니야. 아래 요소들을 종합적으로 봐야 해.

📊 코드 품질의 핵심 요소들

1. 가독성 (Readability)
다른 사람이 (혹은 3개월 후의 나 자신이) 코드를 읽었을 때 바로 이해할 수 있어야 해.
변수명이 a, b, temp1 이런 거면... 진짜 나중에 본인도 모름 ㅋㅋㅋ

2. 유지보수성 (Maintainability)
기능 추가하거나 버그 수정할 때 다른 부분을 건드리지 않고 안전하게 수정할 수 있어야 해.
스파게티 코드는 진짜 손대기 무서움... 😱

3. 일관성 (Consistency)
팀 전체가 같은 스타일로 코드를 작성해야 해.
어떤 파일은 세미콜론 있고, 어떤 파일은 없고... 이러면 코드 리뷰가 지옥이 됨 ㅠㅠ

4. 안전성 (Safety)
잠재적인 버그나 보안 취약점이 없어야 해.
== 대신 === 써야 하는 이유, ESLint가 알려줌!

💡 재미있는 통계! 소프트웨어 개발 비용의 약 80%가 유지보수에 쓰인다는 연구 결과가 있어.
코드 품질에 투자하는 게 장기적으로 훨씬 이득이라는 거 수치로도 증명된 거야!

그래서 등장한 게 바로 린터(Linter)와 포매터(Formatter)야.
JavaScript 생태계에서 가장 널리 쓰이는 조합이 바로 ESLint + Prettier인데,
이 둘은 역할이 달라서 같이 쓰면 시너지가 엄청남! 🔥


🔍 ESLint 완전 정복

ESLint는 2013년 Nicholas C. Zakas가 만든 JavaScript 정적 분석 도구야.
"정적 분석"이라는 게 뭐냐면, 코드를 실제로 실행하지 않고도 문제를 찾아내는 거야.
마치 맞춤법 검사기처럼 코드를 쭉 훑으면서 "야 이거 이상한데?" 하고 알려주는 거지 ㅋㅋㅋ

⚙️ ESLint 설치하기

Node.js 프로젝트에서 ESLint 설치는 이렇게 해:

# npm 사용 시
npm install --save-dev eslint

# yarn 사용 시
yarn add --dev eslint

# pnpm 사용 시
pnpm add --save-dev eslint

설치 후 초기 설정 파일 생성:

# ESLint 9.x 이상 (Flat Config 방식)
npx eslint --init

# 또는 직접 설정 파일 생성
touch eslint.config.js
📁 ESLint 설정 파일 구조

ESLint 9.x 버전부터는 Flat Config 방식이 기본이야.
기존의 .eslintrc.js 방식에서 eslint.config.js로 바뀐 거야.

// eslint.config.js (ESLint 9.x Flat Config)
import js from "@eslint/js";

export default [
  js.configs.recommended,
  {
    rules: {
      // 미사용 변수 경고
      "no-unused-vars": "warn",
      // console.log 경고
      "no-console": "warn",
      // === 사용 강제
      "eqeqeq": "error",
      // var 사용 금지
      "no-var": "error",
      // const 선호
      "prefer-const": "warn",
    }
  }
];

구버전 방식 (.eslintrc.js)도 아직 많이 쓰이니까 알아두자:

// .eslintrc.js (구버전 방식)
module.exports = {
  env: {
    browser: true,
    es2021: true,
    node: true,
  },
  extends: [
    "eslint:recommended",
  ],
  parserOptions: {
    ecmaVersion: "latest",
    sourceType: "module",
  },
  rules: {
    "no-unused-vars": "warn",
    "no-console": "warn",
    "eqeqeq": "error",
    "no-var": "error",
    "prefer-const": "warn",
  },
};
🎯 ESLint 규칙 레벨 이해하기

ESLint 규칙에는 3가지 레벨이 있어:

레벨 값 의미 동작
🔕 off 0 규칙 비활성화 아무것도 안 함
⚠️ warn 1 경고 노란 경고 표시, 빌드는 됨
🚨 error 2 오류 빨간 오류 표시, CI/CD 실패
⚠️ 주의! error로 설정된 규칙을 위반하면 eslint 명령어가 exit code 1로 종료돼.
CI/CD 파이프라인에서 빌드가 실패하게 되니까 팀에서 어떤 규칙을 error로 할지 신중하게 결정해야 해!
🌟 자주 쓰이는 ESLint 규칙 모음

변수 관련:

{
  "no-unused-vars": "warn",        // 미사용 변수 경고
  "no-undef": "error",             // 미정의 변수 사용 금지
  "no-var": "error",               // var 사용 금지 (let/const 사용)
  "prefer-const": "warn",          // 재할당 없으면 const 권장
  "no-shadow": "warn",             // 상위 스코프 변수 가리기 금지
}

코드 품질 관련:

{
  "eqeqeq": ["error", "always"],   // === 사용 강제
  "no-console": "warn",            // console.log 경고
  "no-debugger": "error",          // debugger 사용 금지
  "no-alert": "warn",              // alert 경고
  "no-eval": "error",              // eval() 사용 금지 (보안!)
  "no-implied-eval": "error",      // 암묵적 eval 금지
}

ES6+ 관련:

{
  "arrow-body-style": ["warn", "as-needed"],  // 화살표 함수 간결하게
  "prefer-arrow-callback": "warn",            // 콜백에 화살표 함수 권장
  "prefer-template": "warn",                  // 템플릿 리터럴 권장
  "object-shorthand": "warn",                 // 객체 단축 표기 권장
  "no-duplicate-imports": "error",            // 중복 import 금지
}
📦 ESLint 플러그인과 Extends

ESLint의 진짜 강점은 플러그인 생태계야!
React, TypeScript, Vue 등 다양한 환경에 맞는 플러그인이 있어:

# React 프로젝트용
npm install --save-dev eslint-plugin-react eslint-plugin-react-hooks

# TypeScript 프로젝트용
npm install --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin

# Import 관련
npm install --save-dev eslint-plugin-import

# 접근성 관련
npm install --save-dev eslint-plugin-jsx-a11y

React 프로젝트 설정 예시:

// .eslintrc.js (React + TypeScript)
module.exports = {
  extends: [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:react-hooks/recommended",
    "plugin:@typescript-eslint/recommended",
  ],
  plugins: ["react", "react-hooks", "@typescript-eslint"],
  parser: "@typescript-eslint/parser",
  settings: {
    react: {
      version: "detect",  // React 버전 자동 감지
    },
  },
  rules: {
    "react/react-in-jsx-scope": "off",  // React 17+ 불필요
    "react/prop-types": "off",          // TypeScript 사용 시 불필요
  },
};
🚀 ESLint 실행하기
# 현재 디렉토리 전체 검사
npx eslint .

# 특정 파일 검사
npx eslint src/index.js

# 자동 수정 가능한 오류 자동 수정
npx eslint . --fix

# 특정 확장자만 검사
npx eslint . --ext .js,.jsx,.ts,.tsx

package.json에 스크립트 추가해두면 편해:

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix"
  }
}

✨ Prettier 완전 정복

Prettier는 2017년 James Long이 만든 Opinionated Code Formatter야.
"Opinionated"라는 게 핵심인데, 이건 "우리가 이미 결정해놨으니까 너는 그냥 따라와" 라는 뜻이야 ㅋㅋㅋ

ESLint가 "이 코드 이상해요!" 라고 알려주는 거라면,
Prettier는 "내가 그냥 다 고쳐줄게!" 하고 코드를 자동으로 포맷팅해주는 거야.
진짜 편함... 😍

🎯 Prettier의 핵심 철학: "코드 스타일 논쟁을 끝내자!"
탭이냐 스페이스냐, 세미콜론이냐 아니냐... 이런 소모적인 논쟁 대신 Prettier가 정해주는 대로 따르면 돼!
⚙️ Prettier 설치하기
# npm
npm install --save-dev prettier

# yarn
yarn add --dev prettier

# pnpm
pnpm add --save-dev prettier

설정 파일 생성 (.prettierrc 또는 prettier.config.js):

// .prettierrc (JSON 형식)
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "useTabs": false,
  "printWidth": 80,
  "trailingComma": "es5",
  "bracketSpacing": true,
  "arrowParens": "always"
}

또는 JS 형식으로:

// prettier.config.js
module.exports = {
  semi: true,           // 세미콜론 사용
  singleQuote: true,    // 작은따옴표 사용
  tabWidth: 2,          // 들여쓰기 2칸
  useTabs: false,       // 탭 대신 스페이스
  printWidth: 80,       // 한 줄 최대 80자
  trailingComma: "es5", // ES5 호환 후행 쉼표
  bracketSpacing: true, // 객체 괄호 안 공백
  arrowParens: "always",// 화살표 함수 매개변수 괄호
};
🎛️ Prettier 주요 옵션 상세 설명
옵션 기본값 설명
printWidth 80 한 줄 최대 글자 수
tabWidth 2 들여쓰기 칸 수
useTabs false 탭 문자 사용 여부
semi true 세미콜론 사용 여부
singleQuote false 작은따옴표 사용 여부
trailingComma "all" 후행 쉼표 (none/es5/all)
bracketSpacing true 객체 괄호 내 공백
arrowParens "always" 화살표 함수 매개변수 괄호
endOfLine "lf" 줄바꿈 문자 (lf/crlf/cr/auto)
🎨 Prettier 포맷팅 전후 비교

포맷팅 전 (엉망진창 ㅋㅋㅋ):

const obj={name:'홍길동',age:25,job:'개발자'}
const greet=(name)=>{return `안녕하세요, ${name}님!`}
function add(a,b){
return a+b
}
const arr=[1,2,3,4,5]
if(arr.length>0){console.log('배열에 요소가 있어요')}

포맷팅 후 (Prettier 적용):

const obj = { name: '홍길동', age: 25, job: '개발자' };
const greet = (name) => {
  return `안녕하세요, ${name}님!`;
};
function add(a, b) {
  return a + b;
}
const arr = [1, 2, 3, 4, 5];
if (arr.length > 0) {
  console.log('배열에 요소가 있어요');
}

훨씬 읽기 편하지? 이게 자동으로 되는 거야! 😎

🚀 Prettier 실행하기
# 특정 파일 포맷팅
npx prettier --write src/index.js

# 전체 파일 포맷팅
npx prettier --write .

# 포맷팅 확인만 (수정 안 함)
npx prettier --check .

# 특정 확장자만
npx prettier --write "src/**/*.{js,jsx,ts,tsx,css,json}"

package.json 스크립트:

{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  }
}
🚫 .prettierignore 설정

포맷팅에서 제외할 파일/폴더를 지정할 수 있어:

# .prettierignore
node_modules
dist
build
.next
coverage
*.min.js
public/

ESLint vs Prettier 역할 비교 🔍 ESLint (린터) 코드의 논리적 오류와 패턴 검사 ✗ 오류 감지 const x = 1; // 사용 안 됨 → 경고! ✗ 오류 감지 if (a == b) → === 사용 권장! ✗ 오류 감지 eval('코드') → 보안 위험! ✗ 오류 감지 var x = 1 → let/const 사용 권장! → 코드의 "의미"와 "논리"를 검사 일부 자동 수정 가능 (--fix) VS ✨ Prettier (포매터) 코드의 형식과 스타일 자동 정리 ✓ 자동 수정 {name:'홍길동'} → { name: '홍길동' } ✓ 자동 수정 들여쓰기 자동 정렬 (2칸/4칸) ✓ 자동 수정 긴 줄 자동 줄바꿈 (80자 기준) ✓ 자동 수정 따옴표 통일 ("" → '') → 코드의 "형식"과 "스타일"을 정리 항상 100% 자동 수정
🤝 ESLint + Prettier 함께 쓰기

ESLint와 Prettier를 같이 쓸 때 문제가 생길 수 있어.
왜냐면 ESLint도 일부 포맷팅 규칙을 가지고 있거든.
예를 들어 들여쓰기 규칙 같은 거... 이게 Prettier 설정이랑 충돌하면 진짜 난리남 ㅋㅋㅋ

이 문제를 해결하는 방법이 있어!

🔧 충돌 해결 방법

방법 1: eslint-config-prettier 사용 (권장!)

# 설치
npm install --save-dev eslint-config-prettier
// .eslintrc.js
module.exports = {
  extends: [
    "eslint:recommended",
    "prettier",  // 반드시 마지막에 추가! Prettier와 충돌하는 ESLint 규칙 비활성화
  ],
  rules: {
    // 여기에는 포맷팅 관련 규칙 넣지 말기!
    // 로직/품질 관련 규칙만 넣기
    "no-unused-vars": "warn",
    "eqeqeq": "error",
  },
};

방법 2: eslint-plugin-prettier 사용

# 설치
npm install --save-dev eslint-plugin-prettier eslint-config-prettier
// .eslintrc.js
module.exports = {
  extends: [
    "eslint:recommended",
    "plugin:prettier/recommended",  // 이 한 줄로 해결!
  ],
};
💡 어떤 방법이 더 좋아?
Prettier 공식 문서에서는 eslint-config-prettier만 사용하고,
ESLint와 Prettier를 별도로 실행하는 방식을 권장해.
eslint-plugin-prettier는 편리하지만 성능이 약간 느릴 수 있어.
📋 완성된 설정 예시 (React + TypeScript 프로젝트)
// .eslintrc.js
module.exports = {
  env: {
    browser: true,
    es2021: true,
    node: true,
  },
  extends: [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:react-hooks/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier",  // 항상 마지막!
  ],
  parser: "@typescript-eslint/parser",
  parserOptions: {
    ecmaVersion: "latest",
    sourceType: "module",
    ecmaFeatures: {
      jsx: true,
    },
  },
  plugins: ["react", "react-hooks", "@typescript-eslint"],
  settings: {
    react: { version: "detect" },
  },
  rules: {
    "react/react-in-jsx-scope": "off",
    "react/prop-types": "off",
    "@typescript-eslint/no-unused-vars": "warn",
    "@typescript-eslint/explicit-function-return-type": "off",
    "no-console": ["warn", { allow: ["warn", "error"] }],
    "eqeqeq": "error",
    "prefer-const": "warn",
  },
};
// .prettierrc
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "useTabs": false,
  "printWidth": 100,
  "trailingComma": "es5",
  "bracketSpacing": true,
  "arrowParens": "always",
  "endOfLine": "lf"
}

🛠️ VS Code에서 자동화 설정하기

매번 터미널에서 명령어 치는 거 귀찮잖아 ㅋㅋㅋ
VS Code에서 파일 저장할 때 자동으로 ESLint 검사하고 Prettier 포맷팅 되게 설정해보자!

📦 VS Code 확장 프로그램 설치

VS Code 마켓플레이스에서 아래 두 개 설치해:

ESLint - dbaeumer.vscode-eslint
Prettier - esbenp.prettier-vscode

⚙️ VS Code 설정 (.vscode/settings.json)

프로젝트 루트에 .vscode/settings.json 파일 만들어:

{
  // 저장 시 자동 포맷팅
  "editor.formatOnSave": true,
  
  // 기본 포매터를 Prettier로 설정
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  
  // 저장 시 ESLint 자동 수정
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },
  
  // JavaScript/TypeScript에서 Prettier 사용
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  
  // ESLint 검사할 파일 타입
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact"
  ]
}

이제 파일 저장하면 자동으로 포맷팅되고 ESLint 오류도 자동 수정돼! 🎉


🔒 Git Hooks로 코드 품질 강제하기

VS Code 설정은 개인 설정이라 팀원이 안 따를 수도 있잖아 ㅋㅋㅋ
그래서 Git Hooks를 사용해서 커밋 전에 자동으로 검사하게 만들어버리는 거야!
이러면 품질 안 좋은 코드는 아예 커밋이 안 됨 😈

🐶 Husky + lint-staged 설정

Husky: Git Hooks를 쉽게 관리해주는 도구
lint-staged: 스테이징된 파일에만 린트 실행 (전체 파일 검사하면 너무 느리니까)

# 설치
npm install --save-dev husky lint-staged

# Husky 초기화
npx husky init

이러면 .husky/ 폴더가 생기고 pre-commit 파일이 만들어져.

# .husky/pre-commit
npx lint-staged

package.json에 lint-staged 설정 추가:

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{css,scss,json,md}": [
      "prettier --write"
    ]
  }
}
💡 이제 git commit 할 때마다 자동으로 ESLint 검사 + Prettier 포맷팅이 실행돼!
오류가 있으면 커밋이 실패하고, 자동 수정 가능한 건 수정 후 커밋돼. 팀 코드 품질 유지에 최고야!
🔄 commit-msg 훅으로 커밋 메시지도 검사

커밋 메시지 컨벤션도 강제하고 싶다면 commitlint를 추가해:

# 설치
npm install --save-dev @commitlint/cli @commitlint/config-conventional

# commitlint 설정
echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
# .husky/commit-msg
npx --no -- commitlint --edit $1

이제 커밋 메시지도 feat:, fix:, docs: 같은 형식을 따라야 해!

# 올바른 커밋 메시지 예시
git commit -m "feat: 로그인 기능 추가"
git commit -m "fix: 버튼 클릭 이벤트 오류 수정"
git commit -m "docs: README 업데이트"
git commit -m "refactor: 인증 로직 리팩토링"

🚀 CI/CD 파이프라인에 통합하기

로컬에서 검사하는 것도 중요하지만, CI/CD에서도 검사해야 완벽해!
GitHub Actions 예시를 보여줄게:

⚡ GitHub Actions 설정
# .github/workflows/code-quality.yml
name: Code Quality Check

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  lint-and-format:
    runs-on: ubuntu-latest
    
    steps:
      - name: 코드 체크아웃
        uses: actions/checkout@v4
      
      - name: Node.js 설정
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      
      - name: 의존성 설치
        run: npm ci
      
      - name: ESLint 검사
        run: npm run lint
      
      - name: Prettier 포맷 확인
        run: npm run format:check

이제 PR 올릴 때마다 자동으로 코드 품질 검사가 실행돼!
검사 실패하면 머지 못 하게 막을 수도 있어. 팀 코드 품질 관리 완벽 ✅


💡 실전 팁과 트러블슈팅
🔕 특정 코드에서 ESLint 규칙 비활성화

가끔은 특정 줄에서 규칙을 무시해야 할 때가 있어:

// 다음 줄 전체 규칙 비활성화
// eslint-disable-next-line
console.log('디버깅용');

// 특정 규칙만 비활성화
// eslint-disable-next-line no-console
console.log('디버깅용');

// 블록 전체 비활성화 (남용 금지!)
/* eslint-disable no-console */
console.log('여러 줄');
console.log('비활성화');
/* eslint-enable no-console */

// 파일 전체 비활성화 (진짜 남용 금지!!)
/* eslint-disable */
⚠️ eslint-disable은 진짜 필요할 때만 써야 해!
남용하면 ESLint 쓰는 의미가 없어짐 ㅋㅋㅋ 코드 리뷰에서 지적받을 수 있어.
🎯 자주 발생하는 충돌 문제 해결

문제 1: ESLint와 Prettier 들여쓰기 충돌

// 잘못된 설정 - ESLint에 indent 규칙이 있으면 충돌!
rules: {
  "indent": ["error", 2],  // 이거 지워야 해!
}

// 올바른 설정 - prettier가 들여쓰기 담당
// ESLint에서 indent 규칙 제거하고 prettier에서 tabWidth 설정

문제 2: 줄 끝 문자 (CRLF vs LF) 문제

// .prettierrc
{
  "endOfLine": "lf"  // Windows에서도 LF 사용
}

// .gitattributes
* text=auto eol=lf

문제 3: TypeScript 파일에서 ESLint 파서 오류

// .eslintrc.js
module.exports = {
  parser: "@typescript-eslint/parser",  // 이거 꼭 추가!
  parserOptions: {
    project: "./tsconfig.json",  // TypeScript 설정 파일 경로
  },
};
⚡ 성능 최적화 팁

프로젝트가 커지면 ESLint 실행이 느려질 수 있어. 이렇게 해결해:

// .eslintrc.js - 성능 최적화
module.exports = {
  // 캐시 사용 (CLI에서 --cache 옵션)
  // npx eslint . --cache
  
  // 불필요한 파일 제외
  ignorePatterns: [
    "node_modules/",
    "dist/",
    "build/",
    "*.min.js",
    "coverage/",
  ],
};
# package.json scripts
{
  "scripts": {
    "lint": "eslint . --cache",  // --cache 옵션으로 속도 향상
    "lint:fix": "eslint . --cache --fix"
  }
}

🌐 다양한 프레임워크별 추천 설정
⚛️ Next.js 프로젝트

Next.js는 자체 ESLint 설정을 제공해:

# Next.js 프로젝트 생성 시 자동 설정됨
# 수동으로 추가할 경우:
npm install --save-dev eslint-config-next
// .eslintrc.js
module.exports = {
  extends: [
    "next/core-web-vitals",  // Next.js 권장 설정
    "prettier",
  ],
  rules: {
    // 추가 규칙
  },
};
💚 Vue.js 프로젝트
npm install --save-dev eslint-plugin-vue
// .eslintrc.js
module.exports = {
  extends: [
    "eslint:recommended",
    "plugin:vue/vue3-recommended",  // Vue 3 권장 설정
    "prettier",
  ],
  parser: "vue-eslint-parser",
  parserOptions: {
    parser: "@babel/eslint-parser",
    requireConfigFile: false,
  },
};
🔷 TypeScript 전용 프로젝트
npm install --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin
// .eslintrc.js
module.exports = {
  extends: [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:@typescript-eslint/recommended-requiring-type-checking",
    "prettier",
  ],
  parser: "@typescript-eslint/parser",
  parserOptions: {
    project: true,
    tsconfigRootDir: __dirname,
  },
  rules: {
    "@typescript-eslint/no-explicit-any": "warn",
    "@typescript-eslint/no-floating-promises": "error",
  },
};

📚 코드 품질 관리의 큰 그림

ESLint와 Prettier는 코드 품질 관리의 시작이야.
더 넓은 관점에서 보면 이런 도구들도 함께 쓰면 좋아:

도구 역할 특징
ESLint 정적 분석 / 린팅 코드 오류 및 패턴 검사
Prettier 코드 포맷팅 스타일 자동 통일
TypeScript 타입 검사 컴파일 타임 오류 방지
Jest / Vitest 단위 테스트 기능 동작 검증
SonarQube 코드 품질 분석 복잡도, 중복 코드 분석
Husky Git Hooks 관리 커밋 전 자동 검사
🎯 코드 품질 관리는 "도구"가 아니라 "문화"야!
도구를 설정해놓고 끝이 아니라, 팀 전체가 왜 이 규칙이 필요한지 이해하고 따르는 게 중요해.

재능넷 같은 플랫폼에서 개발 관련 재능을 거래할 때도,
ESLint/Prettier 설정이 잘 되어있는 프로젝트를 납품하면 클라이언트 만족도가 훨씬 높아!
코드 품질은 프로 개발자의 기본 소양이니까 꼭 챙기자 💪


🚀 ESLint + Prettier 도입 단계별 가이드 1 패키지 설치 eslint prettier eslint-config- prettier 필요한 플러그인 📦 2 설정 파일 생성 .eslintrc.js .prettierrc .eslintignore .prettierignore ⚙️ 3 에디터 연동 VS Code 확장 설치 .vscode/ settings.json 저장 시 자동 포맷팅 설정 💻 4 Git Hooks 설정 husky 설치 lint-staged 설정 pre-commit 훅 커밋 전 자동 검사 실행 🐶 5 CI/CD 통합 GitHub Actions 설정 PR 시 자동 검사 실행 🚀 ✅ 완료! 이제 팀 전체가 일관된 코드 품질을 유지할 수 있어!
🎓 마무리 - 코드 품질 관리의 진짜 의미

자 이제 ESLint와 Prettier에 대해 꽤 깊게 알아봤어!
처음에는 설정하는 게 귀찮고 복잡하게 느껴질 수 있어.
근데 한 번 제대로 설정해놓으면 그 다음부터는 자동으로 다 해줘서 진짜 편함 ㅋㅋㅋ 😄

📝 핵심 요약

ESLint 코드의 논리적 오류와 패턴을 검사하는 린터

Prettier 코드 스타일을 자동으로 통일해주는 포매터

eslint-config-prettier 두 도구의 충돌을 방지하는 설정

Husky + lint-staged 커밋 전 자동 검사로 품질 강제

GitHub Actions CI/CD에서 코드 품질 자동 검증

개발 실력을 키우고 싶다면 재능넷에서 JavaScript 관련 멘토링이나 코드 리뷰 서비스를 찾아보는 것도 좋은 방법이야!
경험 많은 개발자에게 직접 피드백 받으면 성장 속도가 훨씬 빨라지거든 😊

코드 품질 관리는 단순히 "예쁜 코드"를 위한 게 아니야.
버그를 줄이고, 팀 생산성을 높이고, 유지보수 비용을 절감하는 실질적인 가치가 있어.
오늘 배운 내용으로 프로젝트에 바로 적용해봐! 처음엔 어색해도 금방 익숙해질 거야 💪

🌟 마지막 꿀팁! 새 프로젝트 시작할 때 ESLint + Prettier 설정을 제일 먼저 해두는 습관을 들여!
나중에 기존 코드에 적용하면 수백 개의 오류가 한꺼번에 뜨는 지옥을 경험하게 됨 ㅋㅋㅋ 😅
댓글 작성

이 글에 대한 여러분의 생각을 들려주세요

댓글 0
댓글을 불러오는 중입니다.

아직 댓글이 없습니다.