정적 분석은 소스 코드를 실행하지 않고 코드의 구조, 문법, 잠재적 오류, 스타일 가이드 준수 여부 등을 검사하는 과정이다. 린팅은 정적 분석의 한 형태로, 주로 코드의 품질과 일관성을 유지하기 위해 프로그래밍 오류, 버그, 스타일 오류를 찾아내는 데 초점을 맞춘다.
ESLint와 Prettier는 현대 자바스크립트 및 타입스크립트 개발 생태계에서 코드 품질과 일관성을 보장하기 위해 가장 널리 사용되는 두 가지 도구다. ESLint는 주로 코드의 품질과 잠재적 문제를 검사하는 린터 역할을 하며, Prettier는 코드의 서식과 스타일을 일관되게 정리하는 코드 포맷터 역할을 한다.
이 두 도구는 상호 보완적으로 작동하여 개발 팀이 효율적으로 협업하고, 코드베이스의 유지보수성을 높이며, 논쟁의 여지가 있는 코드 스타일 논의를 줄이는 데 기여한다. 일반적으로 프로젝트에 함께 도입되어 개발 워크플로우에 통합된다.
ESLint는 자바스크립트와 JSX, 타입스크립트와 같은 관련 언어의 코드를 분석하여 문제 패턴을 찾고 일관된 코딩 스타일을 강제하는 정적 코드 분석 도구이다. 주로 문법 오류, 잠재적 버그, 스타일 가이드 위반 사항을 식별하고 보고하는 데 사용된다. 개발 과정에서 코드 품질을 유지하고 팀 내 코딩 컨벤션을 통일시키는 데 핵심적인 역할을 한다.
ESLint의 동작 원리는 크게 두 단계로 나뉜다. 첫째, 파서(Parser)가 소스 코드를 분석하여 추상 구문 트리(AST)로 변환한다. 둘째, 정의된 규칙(Rules)들이 이 AST를 순회하며 패턴을 검사한다. 규칙은 특정 조건을 만족할 때 린트(Lint) 오류나 경고를 생성한다. 이 구조는 사용자가 자신만의 규칙을 작성하거나 기존 규칙을 조합하여 프로젝트에 맞는 린팅 정책을 구성할 수 있게 한다.
ESLint의 구성 요소는 크게 규칙(Rules), 설정 파일(.eslintrc.*), 그리고 플러그인(Plugins)으로 구분된다. 규칙은 개별적인 검사 항목이며, "error", "warn", "off" 세 가지 수준으로 설정할 수 있다. 설정 파일(일반적으로 .eslintrc.js 또는 .eslintrc.json)에서는 이러한 규칙들을 활성화하고, 파서 옵션, 검사 환경(env) 등을 정의한다. 플러그인은 특정 프레임워크(예: React, Vue.js)나 라이브러리를 위한 추가 규칙 세트를 제공한다.
구성 요소 | 설명 | 예시 |
|---|---|---|
규칙 (Rules) | 코드의 특정 패턴을 검사하는 개별 단위 |
|
설정 파일 | 활성화할 규칙, 환경, 파서 옵션 등을 정의 |
|
플러그인 (Plugins) | 특정 기술 스택을 위한 규칙 모음 |
|
파서 (Parser) | 코드를 AST로 변환하는 엔진 | 기본 파서 |
이러한 모듈화된 구조 덕분에 ESLint는 매우 유연하며, 소규모 개인 프로젝트부터 대규모 엔터프라이즈 프로젝트에 이르기까지 다양한 상황에 맞춰 구성할 수 있다. 또한 Node.js 환경에서 실행되며, 명령줄 인터페이스(CLI)나 주요 코드 에디터의 확장 프로그램을 통해 통합되어 실시간으로 피드백을 제공한다.
ESLint는 자바스크립트 및 타입스크립트와 같은 언어의 코드를 분석하여 잠재적인 오류나 문제점, 특정 스타일 가이드 위반 사항을 찾아내는 정적 분석 도구이다. 이 도구의 핵심 개념은 소스 코드를 실행하지 않고도 코드의 구조와 패턴을 검사하여 일관성을 유지하고 버그를 사전에 방지하는 것이다. ESLint는 추상 구문 트리를 기반으로 동작하며, 사용자가 정의하거나 커뮤니티에서 제공하는 규칙 집합에 따라 코드를 평가한다.
동작 원리는 크게 세 단계로 나눌 수 있다. 첫째, 파싱 단계에서 ESLint는 소스 코드를 읽어 ECMAScript 파서를 사용해 AST로 변환한다. 둘째, 트래버싱 단계에서 이 AST를 순회하며, 활성화된 각 린트 규칙에 코드 조각이 부합하는지 확인한다. 셋째, 보고 단계에서 규칙 위반이 발견되면, 해당 위치, 규칙 이름, 심각도(에러/경고)와 함께 메시지를 출력한다. 이 과정은 구성 파일(예: .eslintrc.js)에 정의된 설정을 바탕으로 이루어진다.
ESLint의 설계 철학은 완전한 구성 가능성에 있다. 개발자는 프로젝트의 필요에 따라 규칙을 켜거나 끄고, 심각도를 조정하며, 심지어 커스텀 규칙을 직접 작성하여 적용할 수 있다. 이는 다양한 코딩 컨벤션과 프로젝트 요구사항을 유연하게 수용할 수 있게 한다. 또한, --fix 명령어 옵션을 사용하면 일부 규칙 위반 사항을 자동으로 수정할 수 있어 개발자의 생산성을 높인다.
ESLint는 JavaScript 및 JSX, TypeScript와 같은 관련 언어의 코드를 분석하여 문제를 찾고 일관된 코딩 스타일을 강제하는 데 사용되는 도구이다. 그 핵심 기능은 구성 가능한 규칙 세트를 기반으로 코드를 검사하고, 발견된 문제를 보고하거나 자동으로 수정하는 것이다.
주요 구성 요소는 다음과 같다.
* 파서(Parser): ESLint는 기본적으로 ECMAScript 표준 문법을 이해하는 자체 파서를 사용하지만, Babel 파서와 같은 대체 파서를 사용하여 실험적 구문을 분석할 수 있다.
* 규칙(Rules): 코드에서 검사할 조건을 정의하는 핵심 요소이다. 각 규칙은 "error", "warn", "off" 세 가지 중 하나의 상태로 설정할 수 있다. 규칙은 구문 오류, 안티 패턴 사용, 스타일 가이드 위반 등 다양한 범주를 포괄한다.
* 구성 파일(Configuration File): 프로젝트에서 사용할 규칙, 파서, 환경 설정 등을 정의하는 파일이다. .eslintrc.js, .eslintrc.json, eslint.config.js(새로운 플랫 구성) 또는 package.json의 eslintConfig 필드를 통해 설정할 수 있다.
* 플러그인(Plugins): ESLint의 기능을 확장하는 서드파티 패키지이다. React, Vue.js, Jest와 같은 특정 프레임워크나 라이브러리에 대한 규칙 세트를 제공하거나, 새로운 규칙을 추가한다.
* 공유 구성(Shareable Configs): 미리 정의된 규칙 세트를 패키지로 배포하여 여러 프로젝트에서 일관된 구성을 쉽게 재사용할 수 있게 한다. eslint:recommended 같은 기본 제공 구성이나 eslint-config-airbnb 같은 인기 있는 서드파티 구성이 여기에 속한다.
ESLint는 명령줄 인터페이스(CLI)를 통해 실행되며, 발견된 문제를 목록으로 출력하거나 자동 수정 플래그(--fix)를 사용하여 일부 규칙 위반을 바로잡을 수 있다. 또한 대부분의 현대 코드 에디터와 통합되어 개발 중 실시간으로 피드백을 제공한다.
Prettier는 자바스크립트, 타입스크립트, CSS, HTML, JSON 등 다양한 언어를 지원하는 코드 포맷터이다. 이 도구의 핵심 역할은 개발자가 작성한 코드를 미리 정의된 일관된 스타일로 자동으로 재구성하는 것이다. 린팅 도구인 ESLint가 코드의 잠재적 오류나 안티 패턴을 검사하는 데 초점을 맞춘다면, Prettier는 순전히 코드의 모양새와 서식을 담당한다. 이를 통해 팀 내에서 탭 대신 스페이스를 사용할지, 줄 끝의 세미콜론을 포함할지, 최대 줄 길이는 얼마로 할지와 같은 스타일 논쟁을 해소하고, 모든 코드베이스에 일관된 포맷팅을 보장한다.
Prettier는 '의견이 있는' 도구로 설계되었다. 즉, 사용자가 제어할 수 있는 설정 옵션은 제한적이며, 대부분의 포맷팅 규칙은 Prettier 자체의 철학에 따라 고정되어 있다. 이는 팀이 스타일 가이드를 논의하고 유지하는 데 드는 비용을 줄이기 위한 의도적 선택이다. 사용자는 .prettierrc 파일을 통해 일부 기본 옵션을 커스터마이징할 수 있다. 일반적인 설정 옵션은 다음과 같다.
옵션 | 설명 | 기본값 |
|---|---|---|
| 한 줄의 최대 문자 길이 | 80 |
| 들여쓰기 공백 수 | 2 |
| 들여쓰기에 탭 사용 여부 | false |
| 문장 끝에 세미콜론 추가 여부 | true |
| 작은따옴표 사용 여부 | false |
| 객체나 배열의 마지막 요소 뒤에 쉼표 추가 여부 | "es5" |
설정 파일은 JSON, YAML, JS 등 다양한 형식으로 작성할 수 있으며, 프로젝트 루트에 위치시켜 버전 관리에 포함시킨다. 이렇게 하면 모든 팀원이 동일한 포맷팅 규칙을 적용할 수 있다. 또한, prettier --write . 명령어를 실행하면 프로젝트 내 모든 지원 파일의 서식을 한 번에 정리할 수 있어 매우 효율적이다.
Prettier는 일관된 코드 스타일을 유지하기 위한 코드 포맷터이다. 이 도구는 코드의 의미나 구조를 분석하는 린터와 달리, 순전히 코드의 외관, 즉 들여쓰기, 따옴표 사용, 줄 바꿈, 최대 줄 길이 등 서식에만 집중한다. 개발자가 코드의 논리적 오류를 찾는 대신 스타일 논쟁에서 벗어나도록 설계되었다. Prettier는 파싱 가능한 코드를 받아들여, 자신의 규칙에 따라 다시 쓰고, 일관된 스타일로 출력한다.
Prettier의 핵심 역할은 '의견을 가진' 코드 포맷터로 동작하는 것이다. 대부분의 포맷팅 결정을 개발자에게 위임하는 대신, Prettier는 강력한 기본 규칙 세트를 가지고 있어 사용자의 선호도에 관계없이 일관된 결과를 보장한다. 예를 들어, 자바스크립트에서 문자열을 감쌀 때 작은따옴표를 사용할지 큰따옴표를 사용할지, 객체 리터럴의 마지막 속성 뒤에 쉼표를 넣을지 여부 등을 Prettier가 결정한다. 이로 인해 팀 내에서 코드 스타일 가이드를 길게 논의하거나, 코드 리뷰에서 사소한 포맷팅 문제를 지적하는 시간을 크게 줄일 수 있다.
이 도구는 다양한 언어와 파일 형식을 지원한다. 주요 지원 범위는 다음과 같다.
지원 언어/기술 | 주요 파일 확장자 |
|---|---|
.js, .jsx | |
.ts, .tsx | |
.css, .scss, .less | |
.json | |
.html, .htm | |
.md | |
.graphql, .gql |
Prettier의 동작은 구성 가능하지만, 그 철학은 가능한 한 적은 설정을 유지하는 데 있다. 포맷팅 규칙을 프로젝트의 .prettierrc 설정 파일에서 재정의할 수 있지만, 공식 문서는 기본값을 따르는 것을 권장한다. 이 접근 방식은 모든 프로젝트가 동일한 스타일을 따르도록 하여, 컨텍스트 전환 비용을 줄이고 코드베이스 전반에 걸쳐 균일한 가독성을 제공한다.
Prettier는 기본적으로 일관된 코드 스타일을 강제하는 의견 없는 포맷터로 설계되었다. 이는 대부분의 포맷팅 결정을 도구 자체에 위임하여 개발자 간의 논쟁을 줄이는 철학을 반영한다. 따라서 공식 문서에서는 가능한 한 기본 설정을 사용할 것을 권장한다. 그러나 특정 프로젝트나 팀의 요구사항에 따라 일부 규칙을 조정할 수 있는 유연성을 제공한다.
주요 설정 방법은 다음과 같다.
* 설정 파일: 프로젝트 루트에 .prettierrc (JSON, YAML, JS 형식), .prettierrc.json, prettier.config.js 파일을 생성하여 옵션을 정의한다.
* package.json 내 설정: package.json 파일에 "prettier" 키를 추가하여 옵션을 명시할 수 있다.
* 에디터 설정: VS Code 등의 에디터에서 기본 포맷터를 Prettier로 설정하고, 사용자 또는 작업공간(Workspace) 설정에서 옵션을 오버라이드할 수 있다.
일반적으로 커스터마이징되는 옵션은 다음과 같다.
옵션 | 설명 | 기본값 | 일반적인 커스터마이징 예시 |
|---|---|---|---|
| 한 줄의 최대 길이 | 80 | 100 또는 120으로 증가 |
| 탭 간격을 나타내는 공백 수 | 2 | 4 |
| 탭(tab) 사용 여부 | false | true (탭 사용) |
| 문장 끝 세미콜론 사용 여부 | true | false (세미콜론 생략) |
| 문자열에 작은따옴표 사용 여부 | false | true |
| 객체나 배열 등에서 후행 쉼표 사용 방식 | "es5" | "all" (모든 가능한 곳에 사용) 또는 "none" (사용 안 함) |
| 객체 리터럴의 괄호 안에 공백 삽입 여부 | true | false |
| 화살표 함수의 단일 매개변수에 괄호 사용 여부 | "always" | "avoid" (단일 매개변수일 때 괄호 생략) |
설정 파일 예시 (.prettierrc.json):
```json
{
"semi": false,
"singleQuote": true,
"tabWidth": 2,
"trailingComma": "es5"
}
```
또한, .prettierignore 파일을 생성하여 포맷팅에서 제외할 파일이나 디렉토리를 지정할 수 있다. 이는 node_modules, 빌드 출력물, 특정 설정 파일 등을 무시하는 데 유용하다. 설정의 우선순위는 일반적으로 더 구체적인 설정 파일이 더 넓은 범위의 설정보다 우선한다[1].
ESLint는 정적 분석 도구로, 코드의 잠재적 오류, 버그, 스타일 문제를 찾아내고 수정하도록 안내하는 데 초점을 맞춘다. 이 도구는 린팅 과정을 통해 개발자가 정의한 규칙이나 커뮤니티의 코딩 컨벤션을 준수하는지 검사한다. 예를 들어, 사용하지 않는 변수, 동등 연산자(==) 사용, 잘못된 스코프의 변수 참조와 같은 논리적 오류나 안티패턴을 발견하는 것이 주된 목적이다. 반면에 Prettier는 코드 포맷터로, 코드의 외관과 일관된 스타일을 유지하는 데 중점을 둔다. 들여쓰기, 줄 바꿈, 따옴표 사용, 최대 줄 길이, 연산자 간격 등 코드의 형식을 자동으로 재구성한다.
두 도구의 핵심적인 차이는 문제 해결 방식에 있다. ESLint는 "무엇이 잘못되었는지"를 알려주고, 때로는 수동으로 고치도록 요구하는 경고나 오류를 발생시킨다. 반면 Prettier는 "어떻게 고칠 것인지"를 결정하고, 사용자의 설정에 따라 코드를 자동으로 다시 쓰기 때문에 논쟁의 여지가 있는 스타일 선택을 개발자로부터 제거한다. 이는 Prettier가 '의견이 있는' 도구로 분류되는 이유이기도 하다. 아래 표는 주요 차이점을 요약한 것이다.
구분 | ESLint | Prettier |
|---|---|---|
주요 역할 | 코드 품질 검사 및 린팅 | 코드 스타일 자동 포맷팅 |
검사 대상 | 코드의 문법, 잠재적 오류, 최적화, 컨벤션 준수 | 코드의 외관(들여쓰기, 줄 바꿈, 간격 등) |
출력 결과 | 규칙 위반 시 경고 또는 오류 메시지 | 원본 파일을 포맷팅 규칙에 맞게 재작성 |
규칙 유형 | 오류 방지, 모범 사례, 스타일 가이드 등 다양함 | 주로 스타일(형식) 관련 규칙만 포함 |
자동 수정 |
| 대부분의 경우 파일 저장 시 자동 재포맷팅 |
따라서 프로젝트에서 두 도구는 상호 보완적인 역할을 한다. ESLint는 코드의 정확성과 유지보수성을 높이는 데 기여하고, Prettier는 팀 전체가 일관된 스타일을 유지하도록 하여 스타일 논쟁을 줄여준다. 현대적인 웹 개발 워크플로우에서는 ESLint가 코드 품질을 담당하고, Prettier가 코드 스타일을 담당하도록 구분하여 함께 사용하는 것이 일반적이다[2].
ESLint와 Prettier를 함께 사용하려면 먼저 프로젝트에 두 도구를 설치해야 한다. npm이나 yarn 같은 패키지 매니저를 사용하여 개발 의존성(devDependencies)으로 설치한다.
```bash
npm install --save-dev eslint prettier
```
기본 설정 파일을 생성한다. ESLint는 .eslintrc.js(또는 .eslintrc.json, .eslintrc) 파일을, Prettier는 .prettierrc 파일을 프로젝트 루트에 만든다. 두 도구의 규칙 충돌을 방지하기 위해 eslint-config-prettier 플러그인을 설치하여 ESLint의 포맷팅 관련 규칙을 비활성화하는 것이 일반적이다.
```bash
npm install --save-dev eslint-config-prettier
```
그 후 .eslintrc.js 설정 파일의 extends 배열 맨 마지막에 'prettier'를 추가한다. 이렇게 하면 Prettier의 포맷팅 규칙이 ESLint의 규칙보다 우선하게 된다.
협업을 위해 프로젝트를 구성할 때는 일관된 코드 스타일을 강제하는 설정이 중요하다. .editorconfig 파일을 추가하여 에디터의 기본 설정을 통일할 수 있다. 또한, package.json의 scripts 필드에 린팅과 포맷팅 명령어를 정의하여 모든 팀원이 동일한 명령어로 작업할 수 있게 한다.
```json
{
"scripts": {
"lint": "eslint .",
"format": "prettier --write ."
}
}
```
코드 커밋 전에 자동으로 검사하고 수정하는 husky와 lint-staged를 설정하는 것이 모범 사례이다. 이를 통해 팀의 모든 구성원이 린트 규칙과 포맷팅 규칙을 준수하는 코드만 저장소에 커밋하도록 보장한다.
Node.js와 npm이 설치된 환경에서 프로젝트에 ESLint와 Prettier를 통합하는 기본적인 절차는 다음과 같다.
먼저, 프로젝트 루트 디렉터리에서 필요한 패키지를 개발 의존성으로 설치한다. ESLint는 코드 검사, Prettier는 코드 포맷팅을 담당하며, 두 도구가 충돌하지 않도록 하는 eslint-config-prettier 패키지도 함께 설치하는 것이 일반적이다.
```bash
npm install --save-dev eslint prettier eslint-config-prettier
```
설치 후, 프로젝트 루트에 구성 파일을 생성한다. ESLint 설정 파일 .eslintrc.js (또는 .eslintrc.json, .eslintrc)를 만들고, 기본적인 규칙을 정의한다. 초기 설정으로는 널리 사용되는 공식 규칙 세트인 eslint:recommended를 확장하는 것이 일반적이다. Prettier와의 통합을 위해 eslint-config-prettier를 확장하여 Prettier의 포맷팅 규칙과 충돌하는 ESLint 규칙을 비활성화한다.
```javascript
// .eslintrc.js 예시
module.exports = {
extends: ['eslint:recommended', 'prettier'],
env: {
node: true,
es2021: true,
},
parserOptions: {
ecmaVersion: 'latest',
},
};
```
Prettier의 설정 파일 .prettierrc는 프로젝트의 코드 스타일을 정의한다. 파일 확장자는 .json, .js, .yml 등을 사용할 수 있다. 가장 간단한 형태는 빈 객체 {}로, Prettier의 기본 포맷팅 규칙을 따르게 된다. 팀의 코딩 컨벤션에 따라 들여쓰기 크기나 세미콜론 사용 여부 등을 명시적으로 설정할 수 있다.
```json
// .prettierrc 예시
{
"semi": true,
"tabWidth": 2,
"singleQuote": true
}
```
마지막으로, package.json 파일의 scripts 항목에 린팅과 포맷팅 명령어를 추가하여 편리하게 실행할 수 있도록 한다. 이 설정을 통해 npm run lint 명령으로 코드 검사를, npm run format 명령으로 전체 프로젝트 파일의 포맷팅을 실행할 수 있다.
```json
// package.json scripts 항목 예시
"scripts": {
"lint": "eslint .",
"format": "prettier --write ."
}
```
협업 프로젝트에서 ESLint와 Prettier를 효과적으로 사용하기 위해서는 모든 구성원이 동일한 규칙과 설정을 공유해야 합니다. 이를 위해 프로젝트 루트 디렉터리에 설정 파일을 명시적으로 관리하고, 버전 관리 시스템에 포함시키는 것이 필수적입니다. 일반적으로 .eslintrc.js(또는 .eslintrc.json), .prettierrc(또는 prettier.config.js), 그리고 .eslintignore, .prettierignore 파일을 생성하여 프로젝트에 맞는 규칙과 예외를 정의합니다.
프로젝트 구성의 핵심은 의존성과 설정의 명확한 정의입니다. package.json 파일에 ESLint와 Prettier, 그리고 필요한 플러그인들을 devDependencies로 명시합니다. 이를 통해 모든 개발자가 npm install 또는 yarn install 명령어 하나로 동일한 개발 환경을 구성할 수 있습니다. 또한, scripts 항목에 "lint": "eslint ."와 "format": "prettier --write ." 같은 명령어를 등록하여 일관된 실행 방법을 제공합니다.
파일/설정 | 목적 | 예시 내용 |
|---|---|---|
| ESLint 규칙 정의 |
|
| Prettier 포맷팅 규칙 정의 |
|
| ESLint 검사 제외 대상 |
|
| Prettier 포맷팅 제외 대상 |
|
| 필수 패키지 명시 |
|
린트와 포맷팅을 자동화하는 도구를 설정하는 것도 협업 효율성을 높입니다. Git의 pre-commit hook을 활용하여 커밋 전에 자동으로 코드를 검사하고 포맷팅할 수 있습니다. 이를 위해 lint-staged와 husky 패키지를 사용하는 것이 일반적인 모범 사례입니다. 이 설정은 코드베이스에 일관성을 강제하고, 리뷰 과정에서 스타일 논쟁을 줄이는 데 기여합니다. 모든 설정 파일은 프로젝트 저장소에 커밋되어야 하며, 프로젝트 온보딩 문서에 사용 방법이 명시되어야 합니다.
ESLint 규칙 설정은 .eslintrc.js, .eslintrc.json, eslint.config.js(ESLint v9 이상) 또는 package.json의 eslintConfig 필드를 통해 정의합니다. 규칙은 오류(error), 경고(warn), 끄기(off) 세 가지 수준으로 설정하며, 추가 옵션을 배열로 제공할 수 있습니다. 예를 들어, "quotes": ["error", "double"]은 큰따옴표 사용을 강제하고 위반 시 오류를 발생시킵니다. 규칙은 프로젝트의 코딩 컨벤션, 프레임워크(React, Vue), 타입스크립트 사용 여부에 따라 달라집니다.
설정 파일 형식 | 설명 | 예시 |
|---|---|---|
| 자바스크립트 객체로 설정을 내보냄. 동적 설정 가능. |
|
| JSON 형식의 정적 설정 파일. |
|
| ESLint v9의 새로운 플랫 설정 방식. |
|
|
|
|
Prettier 포맷팅 옵션은 .prettierrc.js, .prettierrc.json, .prettierrc 또는 package.json의 prettier 필드에 정의합니다. 주요 옵션으로는 들여쓰기 크기(printWidth), 탭 사용 여부(useTabs), 세미콜론 추가(semi), 문자열 따옴표 스타일(singleQuote), 객체나 배열의 마지막 항목 뒤에 쉼표 추가(trailingComma) 등이 있습니다. Prettier는 스타일 논쟁을 줄이기 위해 제한된 옵션만 제공하며, 대부분의 경우 기본값을 그대로 사용하는 것이 권장됩니다.
두 도구를 함께 사용할 때는 포맷팅 관련 ESLint 규칙과 Prettier 규칙이 충돌하지 않도록 주의해야 합니다. 이를 위해 eslint-config-prettier 패키지를 사용하여 Prettier와 충돌하는 ESLint 규칙을 비활성화하는 것이 일반적인 모범 사례입니다. 이렇게 하면 ESLint는 코드 품질과 잠재적 버그를 검사하고, Prettier는 일관된 코드 스타일을 담당하는 명확한 역할 분리가 가능해집니다.
ESLint의 규칙 설정은 .eslintrc 구성 파일(또는 package.json의 eslintConfig 속성)을 통해 관리됩니다. 이 파일은 프로젝트에 적용할 린팅 규칙을 정의하는 핵심입니다. 구성은 JSON, YAML, JavaScript 형식으로 작성할 수 있으며, 확장 가능한 구조를 가지고 있습니다.
규칙은 크게 세 가지 상태로 설정할 수 있습니다. "off"(또는 0)는 규칙을 비활성화하고, "warn"(또는 1)은 경고를 발생시키며, "error"(또는 2)는 오류를 발생시켜 종종 CI/CD 과정을 실패하게 만듭니다. 각 규칙은 추가적인 옵션 배열을 받을 수 있습니다. 예를 들어, 들여쓰기 크기나 최대 줄 길이와 같은 세부 사항을 조정할 수 있습니다.
규칙 이름 | 기본값 | 예시 설정 | 설명 |
|---|---|---|---|
|
|
| 문장 끝에 세미콜론을 강제합니다. |
|
|
| 큰따옴표 사용을 강제합니다. |
|
|
| 들여쓰기를 2칸 공백으로 설정합니다. |
|
|
|
|
|
|
| 한 줄의 최대 길이를 100자로 제한합니다. |
설정은 미리 정의된 구성을 확장(extends)하거나 특정 파일을 무시(ignorePatterns)하는 방식으로 적용됩니다. 널리 사용되는 스타일 가이드인 Airbnb JavaScript 스타일 가이드나 Google 스타일 가이드를 확장하여 시작한 후, 프로젝트 요구사항에 맞게 개별 규칙을 재정의(rules)하는 것이 일반적인 접근 방식입니다. 또한, TypeScript, React, Vue.js와 같은 특정 환경이나 프레임워크를 위한 플러그인의 규칙을 별도로 설정할 수 있습니다.
Prettier는 일관된 코드 스타일을 유지하기 위해 다양한 포맷팅 옵션을 제공한다. 이러한 옵션들은 .prettierrc, prettier.config.js 파일이나 package.json의 prettier 필드를 통해 설정할 수 있다. 주요 옵션은 들여쓰기, 따옴표 사용, 세미콜론, 줄 길이, 객체와 배열의 괄호 처리 방식 등을 제어한다.
일반적인 포맷팅 옵션은 다음과 같다.
옵션 이름 | 기본값 | 설명 |
|---|---|---|
| 80 | 한 줄의 최대 문자 길이를 지정한다. 이를 초과하면 Prettier가 줄을 바꾼다. |
| 2 | 들여쓰기 공백 수를 지정한다. |
| false | 들여쓰기에 탭(tab) 대신 공백(space)을 사용할지 여부를 결정한다. |
| true | 문장 끝에 세미콜론을 자동으로 추가할지 여부를 설정한다. |
| false | 문자열에 큰따옴표( |
|
| 객체나 배열의 마지막 요소 뒤에 후행 쉼표를 추가할지 설정한다. |
| true | 객체 리터럴의 괄호 안에 공백을 추가할지 여부를 설정한다. |
|
| 화살표 함수의 매개변수가 하나일 때 괄호를 생략할지 설정한다. |
이 외에도 파일 종류에 따른 파서 지정(parser 옵션), JSX 문법 처리 방식(jsxSingleQuote, bracketSameLine), 주석 포맷팅(comment 관련 옵션) 등 더 세부적인 설정이 가능하다. 설정 파일 예시는 다음과 같다.
```json
{
"semi": false,
"singleQuote": true,
"tabWidth": 2,
"trailingComma": "all"
}
```
이러한 옵션들은 프로젝트 팀의 코딩 컨벤션에 맞춰 조정된다. 설정을 공유하기 위해 .prettierrc 파일을 프로젝트 루트에 배치하거나, "prettier" 키를 확장하여 공유 설정 패키지를 참조하는 것이 일반적이다[3].
ESLint는 다양한 플러그인을 통해 기능을 확장할 수 있다. 인기 있는 플러그인으로는 React 컴포넌트의 규칙을 정의하는 eslint-plugin-react, TypeScript 문법을 지원하는 @typescript-eslint/eslint-plugin, Jest 테스트 코드를 검사하는 eslint-plugin-jest, import/export 문의 순서와 유효성을 관리하는 eslint-plugin-import 등이 있다. 이러한 플러그인들은 특정 프레임워크, 라이브러리, 또는 도메인에 맞춘 린팅 규칙을 제공하여 개발 생산성을 높인다.
Prettier는 플러그인보다는 공식적으로 지원하는 언어 확장에 초점을 맞추지만, 서드파티 플러그인을 통해 추가 언어를 지원하기도 한다. 반면, ESLint의 포맷팅 관련 규칙과 Prettier의 규칙이 충돌하는 것을 방지하기 위해 eslint-config-prettier와 같은 전용 구성 패키지가 널리 사용된다.
에디터 통합은 두 도구의 효율성을 극대화하는 핵심 요소이다. 대부분의 현대적인 코드 에디터(Visual Studio Code, WebStorm, Sublime Text 등)는 ESLint와 Prettier를 위한 확장 기능을 제공한다. 예를 들어, VS Code에서는 ESLint와 Prettier - Code formatter 확장을 설치하고 설정 파일(.eslintrc, .prettierrc)을 프로젝트에 추가하면, 에디터에서 실시간으로 코드 문제를 표시하고 저장 시 자동으로 코드를 포맷팅할 수 있다.
통합 요소 | 설명 | 대표적 예시 |
|---|---|---|
에디터 확장 | 실시간 코드 검사 및 자동 포맷팅 | VS Code의 ESLint, Prettier 확장 |
환경 설정 | 프로젝트별 규칙 정의 |
|
협업 보장 | 버전 관리 시스템 훅 활용 |
|
이러한 통합은 개발 과정에서 일관된 코드 스타일을 유지하고, 잠재적인 버그를 조기에 발견하는 데 기여한다. 특히 husky와 lint-staged를 조합하여 Git 커밋 직전에 코드 검사와 포맷팅을 강제하는 설정은 팀 협업 시 코드베이스의 품질을 유지하는 모범 사례이다[4].
ESLint의 기능은 다양한 플러그인을 통해 확장될 수 있다. 특정 프레임워크, 라이브러리, 테스팅 도구, 또는 코딩 스타일을 위한 규칙 세트를 제공하는 플러그인들이 널리 사용된다. 이러한 플러그인을 프로젝트에 추가함으로써, 개발 팀은 해당 기술 스택에 특화된 일관된 코드 품질 기준을 쉽게 적용할 수 있다.
다음은 특히 React, TypeScript, Vue.js 등 현대적인 프론트엔드 개발 환경에서 자주 사용되는 플러그인들이다.
플러그인 이름 | 주요 목적 | 설명 |
|---|---|---|
| React 코드 린팅 | |
| React Hooks 린팅 | React의 useState, useEffect 등 Hooks 사용 규칙을 검사하여 자주 발생하는 실수를 방지한다. |
| TypeScript 코드 린팅 | TypeScript 구문 분석을 가능하게 하고, 타입 안전성과 관련된 규칙을 제공한다. |
| 모듈 import/export 린팅 | ES6+ 모듈의 올바른 사용, 존재하지 않는 모듈 참조 방지, import 순서 정렬 등을 관리한다. |
| 접근성 검사 | JSX 요소의 접근성 관련 속성(예: |
| Vue.js 코드 린팅 | Vue.js 싱글 파일 컴포넌트( |
| Jest 테스트 코드 린팅 | Jest 테스트 스위트에서 사용되는 |
| Prettier 통합 | 코드 포맷팅 문제를 ESLint 규칙으로 보고하도록 하여, Prettier와의 통합을 원활하게 한다. |
이 외에도 특정 코드 스타일을 강제하는 eslint-plugin-sonarjs[5], 보안 취약점을 검사하는 eslint-plugin-security 등 수많은 커뮤니티 플러그인이 존재한다. 프로젝트에 필요한 플러그인을 선택하여 설치한 후, ESLint 설정 파일(.eslintrc.js 등)의 plugins 배열에 등록하고, rules 섹션에서 필요한 규칙을 활성화하면 된다.
ESLint와 Prettier를 에디터에 통합하면 코드를 저장할 때나 작성 중에 실시간으로 린팅과 포맷팅을 적용할 수 있어 개발 효율성을 크게 향상시킨다. 대부분의 현대적인 코드 에디터와 통합 개발 환경(IDE)는 공식 또는 커뮤니티 확장 기능을 통해 이 두 도구를 지원한다.
에디터/IDE | ESLint 확장 | Prettier 확장 | 주요 기능 |
|---|---|---|---|
ESLint (공식) | Prettier - Code formatter | 자동 수정, 저장 시 포맷, 문제 패널 통합 | |
내장 지원 | 내장 지원 (플러그인) | 파일 감시 도구로 실행, 커밋 전 훅 통합 | |
SublimeLinter-eslint | JsPrettier | 빌드 시스템 통합, 명령 팔레트 지원 | |
ALE 또는 coc-eslint | ALE 또는 prettier 플러그인 | 비동기 린팅, 자동 포맷팅 |
통합 설정의 핵심은 저장 시 자동 포맷팅을 활성화하는 것이다. Visual Studio Code에서는 settings.json 파일에 "editor.formatOnSave": true와 "editor.codeActionsOnSave": { "source.fixAll.eslint": true } 규칙을 추가하여 저장 시 Prettier로 코드를 포맷하고 ESLint 오류를 자동으로 수정하도록 구성할 수 있다. 두 도구의 충돌을 방지하기 위해 eslint-config-prettier 같은 구성 패키지를 사용하여 ESLint의 포맷팅 관련 규칙을 비활성화하는 것이 일반적이다.
에디터 통합은 협업 시 일관성을 유지하는 데 필수적이다. 프로젝트 루트에 .eslintrc와 .prettierrc 설정 파일을 공유하면, 모든 팀원이 동일한 규칙을 에디터 수준에서 적용받을 수 있다. 이는 코드 리뷰 부담을 줄이고, 포맷팅 논의를 불필요하게 만든다. 또한, ESLint와 Prettier 확장 기능은 일반적으로 프로젝트의 로컬 node_modules에 설치된 도구 버전을 우선 사용하므로, 프로젝트별 버전 차이로 인한 문제도 방지한다.
ESLint와 Prettier는 CI/CD 파이프라인에 통합되어 코드 품질을 자동으로 검증하고 일관된 코드 스타일을 강제하는 데 핵심적인 역할을 한다. 파이프라인의 빌드 또는 테스트 단계에서 이러한 도구를 실행함으로써, 팀은 표준을 벗어난 코드나 포맷팅 문제가 메인 브랜치에 병합되는 것을 사전에 방지할 수 있다. 일반적인 구현 방식은 package.json의 스크립트에 lint와 format:check 명령을 정의하고, GitHub Actions, Jenkins, GitLab CI와 같은 지속적 통합 도구가 해당 스크립트를 실행하도록 구성하는 것이다.
파이프라인에서의 실행은 주로 두 가지 모드로 이루어진다. 첫째는 검증 모드로, eslint --max-warnings=0이나 prettier --check 명령을 사용하여 코드가 규칙을 위반하거나 지정된 포맷과 일치하지 않으면 빌드를 실패시킨다. 둘째는 자동 수정 모드로, eslint --fix 명령을 실행하여 간단한 규칙 위반을 자동으로 교정한 후 커밋하는 방식이다. 자동 수정은 주로 푸시 전 pre-commit hook이나 별도의 포맷팅 전용 작업에서 수행되며, 검증 모드는 풀 리퀘스트 병합 전에 최종 검증 수단으로 활용된다.
효과적인 통합을 위한 모범 사례는 다음과 같다.
사례 | 설명 |
|---|---|
빠른 실패 | 린팅과 포맷팅 검사를 파이프라인 초기 단계에 배치하여 문제를 조기에 발견한다. |
캐시 활용 | ESLint 캐시( |
의존성 고정 |
|
보고서 생성 | SARIF 형식 등의 보고서를 출력하여 GitHub Advanced Security 등의 도구와 연동하거나, 결과를 시각적으로 확인할 수 있도록 한다. |
이러한 접근 방식은 코드 리뷰의 부담을 줄이고, 포맷팅 논쟁을 사전에 차단하며, 결국 더 깨끗하고 유지보수하기 쉬운 코드베이스를 유지하는 데 기여한다.
ESLint와 Prettier를 효과적으로 사용하기 위해서는 몇 가지 모범 사례를 따르는 것이 좋다. 첫째, 프로젝트 초기 단계에서 두 도구를 도입하고 설정을 공유하는 것이 바람직하다. 이미 코드베이스가 크게 성장한 후에 도입하면 포맷팅 변경사항이 너무 많아져 리뷰와 병합이 어려워질 수 있다. 둘째, 팀 내에서 일관된 코딩 컨벤션을 정하고, 이를 ESLint 규칙과 Prettier 구성 파일(.eslintrc.js, .prettierrc)에 명시적으로 정의하여 프로젝트 루트에 포함시켜야 한다. 이 파일들을 버전 관리 시스템에 커밋하면 모든 팀원이 동일한 규칙을 적용할 수 있다.
에디터의 자동 저장 기능과 도구들을 연동하여 실시간으로 코드 문제를 확인하고 수정하는 것이 생산성을 높인다. 예를 들어, Visual Studio Code에서는 파일 저장 시 자동으로 ESLint와 Prettier를 실행하도록 설정할 수 있다. 또한, pre-commit hook을 이용해 커밋 직전에 코드 검사와 포맷팅을 강제하는 것도 일반적인 방법이다. 이를 위해 Husky와 lint-staged를 함께 사용하면, 스테이징된 파일만 검사하여 불필요한 시간 낭비를 줄일 수 있다.
실천 항목 | 설명 | 권장 도구/방법 |
|---|---|---|
규칙 공유 | 팀 전체가 동일한 린팅/포맷팅 규칙 사용 |
|
자동화 | 저장 시 또는 커밋 전 자동 실행 | 에디터 확장, Husky, lint-staged |
점진적 도입 | 기존 대규모 프로젝트에 적용 시 |
|
CI 통합 | 코드 품질 게이트웨이 역할 | GitHub Actions, Jenkins 등 CI 파이프라인에 ESLint 실행 단계 추가 |
린팅 규칙은 너무 엄격하게 설정하기보다 프로젝트와 팀의 상황에 맞게 조정해야 한다. 처음에는 기본 권장 규칙 세트(예: eslint:recommended)를 사용하고, 필요에 따라 규칙을 하나씩 추가하거나 비활성화하는 접근 방식이 효과적이다. 특히 레거시 코드베이스에 적용할 때는 --fix 옵션으로 자동 수정 가능한 문제부터 해결하고, 주요 규칙 위반만 에러로 설정하여 점진적으로 개선해 나가는 것이 좋다. 마지막으로, 이러한 도구들의 실행을 CI/CD 파이프라인에 필수 단계로 포함시키면, 규칙을 위반한 코드가 메인 브랜치에 병합되는 것을 방지할 수 있다.
ESLint와 Prettier 외에도 코드 품질과 일관성을 유지하는 데 도움을 주는 다양한 도구들이 존재한다. 이들은 특정 언어, 프레임워크, 또는 추가적인 검사 기능에 초점을 맞추고 있다.
주요 대안 및 보완 도구는 다음과 같다.
도구 이름 | 주요 목적 | 주 언어/환경 | 특징 |
|---|---|---|---|
린팅 | TypeScript 전용 린터였으나, 공식적으로 ESLint로 통합을 권장하며 유지보수 모드에 들어갔다[6]. | ||
린팅 | CSS 전용 린터로, 문법 오류 검사와 컨벤션 강제가 가능하다. | ||
정적 분석 | 다국어 | 지속적인 코드 품질 검사를 제공하는 플랫폼으로, 보안 취약점, 버그, 코드 스멜까지 광범위하게 분석한다. | |
Prettier 대안 | 코드 포맷팅 | 다국어 | Prettier의 대안으로는 dprint(Rust 기반, 빠른 속도)나 언어별 포맷터(gofmt, Black 등)가 있다. |
Git 훅 통합 | - | 커밋 전에 린트와 포맷을 자동으로 실행하도록 설정하여, 잘못된 코드가 저장소에 들어가는 것을 방지한다. |
이러한 도구들은 프로젝트의 스택과 요구사항에 따라 ESLint와 Prettier와 함께 사용되거나, 특정 경우에는 대체하여 사용된다. 예를 들어, React 프로젝트에서는 ESLint에 eslint-plugin-react 플러그인을 추가로 사용하고, CSS-in-JS 스타일링에는 stylelint를 함께 구성하는 경우가 많다. 최근에는 Rust나 Go로 작성된 더 빠른 포맷터 도구들도 주목받고 있다.