[Tooling] ESLint와 Prettier: 협업의 효율을 높이는 코드 컨벤션 자동화

소프트웨어 개발은 혼자 하는 예술 활동이 아니라, 여러 사람이 함께 집을 짓는 협업 과정입니다. 하지만 사람마다 코드를 짜는 습관은 제각각입니다. 누구는 세미콜론(;)을 생략하고, 누구는 작은따옴표(') 대신 큰따옴표(")를 선호합니다. 이런 사소한 차이는 코드 리뷰 시간을 갉아먹고, 깃(Git) 히스토리를 지저분하게 만들며, 심지어는 찾기 힘든 논리적 버그를 유발하기도 합니다.

오늘은 팀의 생산성을 극대화하고 코드의 품질을 일정하게 유지해 주는 프론트엔드의 필수 도구, ESLint와 Prettier의 완벽한 설정법과 실무 활용 전략을 다뤄보겠습니다.

---

1. 린터(Linter)와 포맷터(Formatter)의 역할 분담

많은 초보 개발자가 ESLint와 Prettier를 비슷한 도구로 오해하곤 합니다. 하지만 이 둘은 엄연히 다른 목적을 가지고 있습니다.

1.1 ESLint: 코드의 질(Quality)을 감시하는 파수꾼

ESLint는 소스 코드를 분석하여 문법 에러, 버그 유발 가능성, 안티 패턴 등을 찾아내는 정적 분석 도구입니다.

• 하는 일: "선언만 하고 쓰지 않는 변수가 있어요", "이 함수는 너무 복잡하니 분리하는 게 어때요?", "리액트 훅의 규칙을 어기고 있어요" 등을 지적합니다.
• 가치: 실행해 보기 전에는 알기 어려운 잠재적 에러를 코딩 시점에 잡아냅니다.

1.2 Prettier: 코드의 스타일(Style)을 맞추는 재단사

Prettier는 코드가 어떻게 보일지를 결정합니다. 정해진 규칙에 따라 코드를 완전히 다시 작성하여 일관된 형식을 만듭니다.

• 하는 일: 줄 바꿈 위치, 들여쓰기 너비, 따옴표 종류, 객체 마지막의 콤마(Trailing Comma) 유무 등을 자동으로 정리합니다.
• 가치: "스타일"에 대한 논쟁을 원천 차단하여 개발자가 로직에만 집중하게 합니다.

---

2. 왜 함께 사용해야 하는가?

혼자 개발할 때는 취향의 문제일 수 있지만, 협업 시에는 이 둘의 조합이 강력한 시너지를 냅니다.

1. 코드 리뷰 시간 단축: 리뷰어는 더 이상 "여기 들여쓰기가 안 맞아요" 같은 코멘트를 남길 필요가 없습니다. 로직의 타당성과 아키텍처에만 집중할 수 있습니다.
2. Git 충돌 방지: 포맷팅이 통일되지 않으면, 로직을 건드리지 않았는데도 단순 스타일 변경 때문에 대량의 Diff가 발생합니다. 이는 Merge 충돌의 주범이 됩니다.
3. 학습 도구: ESLint의 규칙을 따라가다 보면 자연스럽게 해당 언어(JS/TS)나 프레임워크(React)의 Best Practice를 익히게 됩니다.

---

3. 실전! ESLint와 Prettier 완벽 설정 가이드

가장 대중적이고 안정적인 Airbnb 스타일 가이드를 기반으로 설정을 구성해 보겠습니다.

3.1 필수 패키지 설치

두 도구가 충돌하지 않도록 하는 것이 핵심입니다. eslint-config-prettier는 ESLint의 규칙 중 Prettier와 충돌하는 스타일 관련 규칙을 꺼주는 역할을 합니다.

Bash

 

npm install -D eslint prettier eslint-config-prettier eslint-plugin-react eslint-plugin-react-hooks @typescript-eslint/eslint-plugin @typescript-eslint/parser

3.2 .eslintrc.json 설정

단순한 문법 검사를 넘어, 리액트 프로젝트에 최적화된 설정을 적용합니다.

JSON

 

{
  "parser": "@typescript-eslint/parser",
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:react-hooks/recommended",
    "prettier" // 항상 마지막에 위치하여 스타일 규칙을 덮어씀
  ],
  "rules": {
    "no-unused-vars": "warn",
    "react/prop-types": "off",
    "react/react-in-jsx-scope": "off" // React 17+ 환경
  }
}

3.3 .prettierrc 설정

팀원들과 합의된 스타일을 명시합니다.

JSON

 

{
  "singleQuote": true,
  "semi": true,
  "useTabs": false,
  "tabWidth": 2,
  "trailingComma": "all",
  "printWidth": 80
}

---

4. 협업의 완성: 자동화 프로세스 구축

설정 파일만 만든다고 끝이 아닙니다. 모든 팀원이 강제로, 혹은 자연스럽게 이 규칙을 따르게 해야 합니다.

4.1 VS Code 설정 공유 (Format on Save)

프로젝트 루트에 .vscode/settings.json 파일을 만들어 공유하세요. 파일을 저장할 때마다 자동으로 코드가 교정됩니다.

JSON

 

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  }
}

4.2 husky와 lint-staged (커밋 전 강제 검사)

팀원 중 누군가 설정을 끄고 코드를 올리는 것을 막으려면 Git Hooks를 활용해야 합니다. husky를 사용하면 git commit 명령 시점에 자동으로 린트와 포맷팅을 검사하고, 통과하지 못하면 커밋을 거부할 수 있습니다.

---

5. 결론: 좋은 아키텍처의 시작은 일관된 코드

ESLint와 Prettier를 설정하는 작업은 프로젝트 초기 30분이면 충분합니다. 하지만 이 30분이 아끼는 시간은 프로젝트 전체 기간을 통틀어 수십, 수백 시간에 달할 것입니다.

오늘의 요약:

• ESLint는 코드의 논리적 오류를, Prettier는 시각적 형식을 담당합니다.
• eslint-config-prettier를 사용하여 두 도구의 충돌을 방지하세요.
• 저장 시 자동 교정 설정을 팀 전체에 공유하세요.
• Husky를 통해 '깨진 유리창'이 코드 베이스에 들어오지 못하게 막으세요.