ESLint 룰을 더 빠르게 찾는 법
ESLint는 JavaScript·TypeScript 코드의 잠재적 오류, 스타일 위반, 안티패턴을 정적으로 검출하는 사실상의 표준 린터입니다. 코어 룰만 250개가 넘고, typescript-eslint·eslint-plugin-react·eslint-plugin-vue·import 등 플러그인을 더하면 1,000개를 훌쩍 넘기 때문에 .eslintrc를 작성할 때마다 공식 문서를 찾아가는 일이 번거롭습니다. 이 도구는 가장 자주 쓰이는 200여 개 룰을 카테고리별로 분류해 한국어 설명, 권장 옵션, --fix 자동 수정 가능 여부, 잘못된 예시와 권장 예시를 한 화면에 묶어 보여 줍니다.
왼쪽 검색창에 룰 이름의 일부나 한국어 키워드(예: "사용하지 않는", "변수", "세미콜론")만 입력해도 매칭됩니다. 카테고리 셀렉트에서 Possible Errors(잠재적 오류), Best Practices(권장 사례), Variables(변수), Stylistic(스타일), ES6, TypeScript, React 중 하나로 좁힐 수 있고, --fix 자동 수정이 가능한 룰만 따로 보고 싶다면 "자동수정" 필터를 사용하세요. 각 룰 카드를 클릭하면 권장 옵션, 잘못된 예시, 권장 예시, 관련 룰을 펼쳐 확인할 수 있습니다.
실전 사용 팁
처음 ESLint를 도입하는 팀은 eslint:recommended + @typescript-eslint/recommended로 시작한 다음, 검색 결과에서 "recommended" 배지가 붙은 룰을 우선 검토하면 80% 이상의 베스트 프랙티스를 자동으로 챙길 수 있습니다. CI 파이프라인에는 --max-warnings 0 옵션을 두어 경고가 0이 되도록 강제하고, IDE에는 ESLint 확장과 "저장 시 --fix" 옵션을 함께 켜 두면 스타일 룰의 99%는 사람이 손대지 않아도 됩니다.
자주 묻는 질문 (FAQ)
Q. ESLint와 Prettier 중에 어느 것을 써야 하나요?
A. ESLint는 코드 품질·잠재 오류 검사용, Prettier는 코드 포매팅 전용입니다. eslint-config-prettier로 충돌하는 스타일 룰만 비활성화하면 둘을 함께 쓰는 것이 표준 조합입니다.
Q. "off | warn | error" 레벨은 어떻게 정하나요?
A. 잠재적 버그(no-undef, no-unreachable 등)는 error, 스타일성 권고는 warn, 팀 컨벤션과 맞지 않는 룰은 off로 두는 것이 일반적입니다. 같은 룰도 옵션 객체 두 번째 요소로 세부 동작을 바꿀 수 있습니다.
Q. --fix는 어디까지 자동으로 고쳐주나요?
A. 의미를 바꾸지 않는 안전한 수정만 적용합니다. 세미콜론·따옴표·들여쓰기·prefer-const 같은 스타일 룰은 거의 자동 수정되지만, no-unused-vars처럼 코드 의도를 알아야 하는 룰은 사람이 직접 고쳐야 합니다.