ESLint + Prettier 설정 가이드: 실전 운영 기준
좋은 설정은 먼저 “기계적으로 맞출 것”과 “의미적으로 검증할 것”을 분리하는 데서 시작합니다.
ESLint와 Prettier는 해결하는 문제가 다르다
Prettier는 사람이 더 이상 토론하지 않아도 되는 형식 문제에 강합니다.
- 따옴표 스타일
- 공백
- 줄바꿈
- trailing comma
ESLint는 아래 같은 문제에 더 적합합니다.
- 버그를 만들기 쉬운 패턴
- 사용되지 않는 변수
- 위험한 async 사용
- 프레임워크/언어 차원의 잘못된 사용
둘의 책임이 섞이면 도구끼리 싸우고, 책임이 분리되면 리뷰가 훨씬 조용해집니다.
목표는 예쁜 설정이 아니라 예측 가능한 팀 흐름이다
좋은 설정은 아래를 보장해야 합니다.
- 누가 저장해도 파일 모양이 같다
- 로컬 autofix는 빠르고 지루할 정도로 자연스럽다
- CI가 같은 기준을 강제한다
- 예외가 암묵지가 아니라 명시된 규칙으로 남는다
즉 도구 선택보다 “형식과 안전성을 기본값으로 만들 수 있는가”가 더 중요합니다.
규칙 세트는 생각보다 작아야 오래 간다
많은 저장소가 추천 규칙 팩을 크게 들여오고, 몇 달 뒤부터 그 후폭풍과 싸웁니다. 규칙이 많다고 품질이 바로 좋아지지는 않습니다.
더 건강한 방식은 보통 이렇습니다.
- 스타일은 Prettier에 맡길 것
- ESLint는 correctness와 maintainability에 집중할 것
- 프레임워크별 규칙은 실제 반복 문제를 해결할 때만 추가할 것
- 노이즈가 큰 규칙은 과감히 정리할 것
예를 들면:
{
"extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended", "prettier"]
}좋은 규칙은 6개월 뒤에도 팀이 이해하고 존중하는 규칙입니다.
로컬 autofix와 CI enforcement는 예산이 달라야 한다
로컬은 속도를, CI는 신뢰를 우선해야 합니다.
실무적으로는 보통 이렇게 나눕니다.
- 로컬 save 또는 pre-commit: 포맷과 가벼운 자동 수정
- PR CI: full lint, typecheck, 기타 품질 게이트
로컬이 무거우면 우회가 생기고, CI가 약하면 품질이 조용히 무너집니다.
모노레포에서는 규칙 소유권이 더 중요하다
큰 저장소에서는 전역 설정 하나만으로 끝나기 어렵습니다. 보통 필요해지는 것은:
- 공용 base config
- 정말 필요한 경우에만 package override
- lint rule 변경 책임자
- 생성 파일, 테스트 유틸리티에 대한 일관된 예외 처리
소유권이 없으면 lint 설정은 품질 기준이 아니라 예외 협상장이 됩니다.
자주 보이는 실패 패턴
- formatting과 linting이 서로 충돌하는 경우
- 로컬 버전과 CI 버전이 다른 경우
- 이해하지 못하는 대형 rule pack을 그대로 들여오는 경우
- pre-commit이 너무 느려서 사람들이 건너뛰는 경우
- warning이 너무 많아져서 아무도 신호로 받아들이지 않는 경우
도구는 팀이 실제로 믿고 따를 수 있을 때만 힘을 가집니다.
체크리스트
- formatting은 Prettier, 품질 규칙은 ESLint가 분명히 맡고 있는가
- 로컬과 CI 결과가 고정 버전과 공용 설정으로 일치하는가
- 규칙 세트가 설명 가능한 크기인가
- autofix와 enforcement가 맞는 층에 배치되어 있는가
- lint warning이 아직 운영적으로 의미 있는 신호인가
마무리
ESLint와 Prettier는 설정을 많이 할수록 강해지는 도구가 아닙니다. 책임을 선명하게 나누고 일관되게 운영할 때 강해집니다. 진짜 성과는 rule 개수가 아니라, 리뷰 소음이 줄고 피할 수 있는 실수가 줄어드는 데서 나옵니다.
Continue Reading
다음으로 읽기 좋은 글
Webpack에서 Vite로 마이그레이션하는 실전 가이드
단순 config 번역이 아니라 dev server 모델 변화, plugin inventory, 환경 변수 처리, 프로덕션 검증까지 포함해 Webpack에서 Vite로 안전하게 옮기는 기준을 정리합니다.
🔧 Tools엔지니어링 지식 지도 만드는 법
문서가 늘어날수록 찾기 어려워지는 문제를 지식 지도, 소유권, 검색 메타데이터로 해결하는 방법을 정리합니다.
💬 LanguageTypeScript Utility Types 실전 가이드
TypeScript 유틸리티 타입을 DTO, 업데이트 payload, selector, 파생 타입 설계에 어떻게 써야 하는지, 어디서부터는 가독성을 해치는지 정리합니다.
💬 LanguageTypeScript Generics 실전 가이드
TypeScript 제네릭을 어디서 쓰면 API 계약이 더 강해지고, 어디서부터는 타입 퍼즐이 되는지 실무 기준으로 정리합니다.
다음 탐색