[JavaScript] ESLint 이론

 

ESLint 이론

 

 

---

 

목차

 

개발자마다 다른 코드 스타일

코드 작성 규칙을 지켜야 하는 이유

ESLint란?

ESLint와 Prettier 차이점

ESLint 장단점

ESLint와 Prettier 충돌 해결법

 

---

 

---

[개발자마다 다른 코드 스타일]

개발자들마다 코드를 작성하는 스타일은 다르다.

같은 기능을 구현하더라도 스타일차이로 인해 코드의 가독성과 유지보수성에 큰 차이가 발생할 수 있다.

 

여기 개발자 A와 B가 있다.

숫자 배열을 받아 짝수만 필터링한 후 각 요소에 2를 곱해 출력하는 함수

 

개발자 A(일관된 스타일, ESLint/Prettier 적용)

function processNumbers(numbers) {
  const evenNumbers = numbers.filter((n) => n % 2 === 0);
  const doubled = evenNumbers.map((n) => n * 2);

  console.log(doubled);
  return doubled;
}

<특징>

• 들여 쓰기 및 공백 처리
• const 사용 등 최신 문법 반영
• 세미콜론 있음
• 가독성 높은 화살표 함수
• 의미 있는 변수/함수명

 

개발자 B(비 일관된 스타일, 규칙 없음)

function process_numbers( numbers ){
var result = []
for(let i=0;i<numbers.length;i++){
if(numbers[i]%2==0){
result.push(numbers[i]*2)
}
}
console.log(result)
return result
}

 

<특징>

• 함수명이 카멜 케이스가 아니다.(process_numbers)
• var 사용(지양됨)
• 들여 쓰기와 공백 없음
• 세미콜론 없음
• 전체적으로 가독성이 낮고 유지보수가 어렵다.

 

<코드 스타일이 일관되지 않으면 생기는 문제점>

상황	결과
git 에서 PR 리뷰 시	코드 스타일 다름으로 불필요한 리뷰 증가
팀원이 수정 시	이해 어려워 실수 발생 가능
에디터에서 자동 포멧이 다를 경우	코드를 열 마다 포맷 충돌 발생
디버깅이나 테스트 중	스타일 차이로 실수 찾기 어려움

그렇기 때문에 팀 프로젝트나 협업에서는 코딩 스타일을 일관되게 유지하는 것이 중요하다.

이를 위해 ESLint, Prettier 같은 도구를 사용한다.

이 도구들은 팀원 간 코드 스타일을 통일하고 가독성과 유지보수성을 크게 향상해 준다.

 

---

[코드 작성 규칙을 지켜야 하는 이유]

<왜 코드 작성 규칙을 지켜야 할까?>

코드를 작성할 때 스타일 규칙을 지키는 것은 단순한 형식 문제가 아니다.

개인의 자유보다 팀 전체의 생산성과 유지보수성이 더 중요하기 때문이다.

1. 코드 일관성 유지
   • 스타일 가이드를 준수하면 모든 팀원이 일관된 방식으로 코드를 작성하게 되어 가독성이 향상된다.
2. 버그 예방 및 오류 방지
   • ESLint : 잠재적인 버그나 잘못된 코드 사용을 사전에 경고해 준다.
   • Prettier : 자동 포매팅을 통해 실수로 생긴 오류를 줄인다.
3. 팀 협업 강화
   • 동일한 환경과 스타일로 작성된 코드는 팀원 간에 이해를 돕고 협업 속도를 높일 수 있다.
4. 자동화로 개발 효율 상승
   • 도구를 통해 스타일 검사와 포매팅을 자동화하면 로직 구현에 집중할 수 있다.
5. 불필요한 리뷰 줄이기
   • 코드 스타일로 인한 리뷰 피드백을 줄일 수 있고, 더 중요한 부분에 집중할 수 있다.

 

<코드 작성 규칙을 만드는 도구>

도구	역할
ESLint	문법 및 코드 품질 검사(규칙 기반 경고 / 오류 표시)
Prettier	코드 포맷터(스타일 자동 정리)
Husky + lint-staged	커밋 전에 자동으로 ESLint/Prettier 실행

 

---

[ESLint란?]

개발자들은 항상 버그를 줄이기 위해 노력하지만 실제로 버그는 사소하고 예상치 못한 부분에서 종종 발생한다.

이렇게 예상하지 못한 동작을 막기 위한 여러 가지 방법 중 정적 분석 도구가 있다.

코드를 작성하다 보면 사용하지 않는 변수, 고치다 남겨진 로직 등 일종의 '코드 보풀'이 쌓이게 된다.

이런 불필요한 코드는 시간이 지날수록 유지보수를 어렵게 만들고 협업 시 어려움을 만들기도 한다.

이러한 코드 보풀을 자동으로 감지하고 제거할 수 있도록 도와주는 도구가 Linter이다.

Linter는 코드의 먼지와 보풀을 정리해 주는 청소 도구

 

언어별로 다양한 Linter가 있다.

자바스크립트, 타입스크립트는 ESLint

파이선은 pylint

go는 golint

swift는 swiftlint를 사용한다.

 

프런트엔드 개발에서 핵심 언어는 자바스크립트로 ESLint를 사용한다.

ESLint는 코드의 일관성을 물론, 잠재적인 오류나 스타일문제를 사전에 잡아주는 정적 분석 도구이다.

 

정적 코드 분석이란 코드 실행 없이 코드 자체만 분석하여 잠재적인 문제점이나 코드 스멜을 사전에 발견하고 수정하는 과정을 의미한다.

즉 런타임 환경 없이 코드를 검사하고 디버깅해 주는 도구다.

 

<정적 분석 도구가 필요한 이유>

1. 코드를 작성하면서 개발자들은 실수를 하기도 한다.
2. 사용하지 않은 변수가 import
3. 선언되지 않은 변수
4. 사용되지 않는 코드
5. 오타, 안티패턴
6. 성능 저하 요소
7. 코드 스멜( : 문제 가능성이 있는 코드)
8. 잠재적인 보안 취약점

이러한 문제는 런타임 환경에서 발견하기 어려운 문제들도 많다.

그래서 우리는 코드 리뷰 문화를 거치기도 한다.

코드 리뷰나 테스트 단계에서 뒤늦게 발견되기도 하지만 하나하나 모두 찾아서 해결하기에는 리소스를 많이 소모한다.

그래서 우리는 ESLint와 같은 도구를 사용해 코드 품질을 사전에 관리한다.

정적 분석 도구는 반복적이고 자잘한 오류를 자동으로 검출하고 수정 가이드를 제공함으로써 개발자의 생산성을 높인다.

 

<예시 : 사용하지 않는 import>

page.tsx에 ButtonA와 ButtonB가 있다.

import ButtonA from "@/component/ButtonA";
import ButtonB from "@/component/ButtonB";

function Page() {
    return (
        <>
            <ButtonA />
            <ButtonB />
        </>
    );
}

 

ButtonA가 필요 없어져 제거하였다.

import ButtonA from "@/component/ButtonA";
import ButtonB from "@/component/ButtonB";

function Page() {
    return (
        <>
            <ButtonB />
        </>
    );
}

이때 ButtonA는 더 이상 사용되지 않지만 import 문은 그대로 남아 있다.

이처럼 불필요한 코드를 수동으로 찾아내기는 쉽지 않으며 잔여 코드나 불필요한 코드는 유지보수에 혼란을 줄 수 있다.

ESLint는 이러한 '보풀 같은 코드'를 자동으로 감지하고 제거할 수 있도록 도와준다.

 

<ESLint 주요 기능>

• 스타일 검사 : 들여 쓰기 , 따옴표, 세미콜론 등
• 오류 감지 : 선언되지 않은 변수, 잘못된 문법 등
• 권장사항 제공 : 성능, 가독성 향상을 위한 제안
• 코드 일관성 유지 : 팀 내 코딩 컨벤션을 강제해 협업 효율 향상
• 자동 수정기능 (Auto-fix) : --fix 옵션으로 간단한 문제는 자동으로 수정 가능

 

나의 생각

 

코드 품질은 프로젝트의 성공과 연결된다고 생각한다.

ESLint는 오류를 줄이고 일관된 스타일을 유지하며 생산성을 높여주는 도구다.

혼자 개발할 때는 안정적인 코드 작성을 돕고, 협업 환경에서는 더욱 큰 효과를 발휘한다.

코드 작성 초기부터 문제를 감지해 개발 속도는 빠르게, 품질은 높게 유지할 수 있다.

코드 리뷰 시간을 줄이고, 실수를 사전에 방지해 일관된 코드를 만드는 데 큰 도움이 된다.

개발은 혼자 하는 일이 아니다. 팀 전체의 생산성과 품질을 위해서도 일관된 코드 스타일은 중요하다는 걸 알게 되었다.

 

---

[ESLint와 Prettier 차이점]

<공통점>

• 코드를 정적 분석해서 문제를 해결

<차이점>

• Prettier
  • 코드의 포매팅을 도와주는 도구
  • 줄바꿈, 들여쓰기, 따옴표 등 코드의 형태적인 부분을 다룬다.
  • 자바스크립트뿐만 아니라 HTML, CSS, JSON 등 다양한 언어에도 적용 가능
• ESLint
  • 코드의 잠재적인 문제가 될 수 있는 부분을 분석
  • 자바스크립트, 타입스크립트에서 작동

 

쉽게 설명하면 ESLint는 var을 사용하지 못하게 하거나 코드 안의 규칙을 말한다.

Prettier는 띄어쓰기나 정렬 부분에 있어서 가독성을 좋게 설정한다.

변수나 함수라던지 코드를 보기 쉽게 색이 바뀐다.

 

---

[ESLint의 장단점]

<장점>

• 일관된 코드 스타일 유지
• 버그 및 오류를 사전에 참지
• 개발자 팀 간 협업 강화
• 실시간 피드백을 통해 코딩 효율을 높여줌

<단점>

• 잘못된 설정 시 과도한 에러 발생
• Prettier와 충돌 가능성
• 규칙을 직접 만들기에는 많은 시간 소요

 

---

[ESLint와 Prettier 충돌 해결법]

ESLint에서도 Prettier가 처리하는 작업(들여쓰기, 줄바꿈, 따옴표 등)을 처리할 수 있다.

두 가지 모두 자바스크립트 코드에서 실행한다면 서로 다른 규칙으로 인해 에러가 발생한다.

최악의 경우 ESLint, Prettier 모두 만족하지 못하는 코드가 만들어질 수 있다.

1. 규칙이 충돌되지 않게 선언하기
   • 원인 : 코드에서 ESLint를 적용하는 작업과 코드의 포매팅을 하는 작업이 서로 다른 패키지에서 발생한다.
   • 해결 : Prettier에서 제공하는 규칙을 어기지 않도록 ESLint에서는 해당 규칙을 끄기
2. 파일 유형에 따라 도구 분리
   • ESLint : 자바스크립트/타입스크립트
   • Prettier : 마크다운, JSON 등
3. eslint-plugin-prettier 활용
   • Prettier 규칙을 ESLint 플러그인으로 연동하여 충돌 최소화

 

이렇게 Prettier와 ESLint가 서로 관여하는 파일을 물리적으로 분리한다면 코드 충돌의 위험은 없애고 Prettier가 제공하는 규칙을 사용할 수 있다.

 

https://devyihyun.tistory.com/244

[JavaScript] ESLint의 구성요소

 

---

잘못된 정보는 댓글에 남겨주시면 감사하겠습니다!😊

댓글과 좋아요는 큰 힘이 됩니다!

 

[ 참고자료 ]

 

https://www.youtube.com/watch?v=RYTWkWOI_eg

 

https://www.youtube.com/watch?v=Be9q0k5BJ_s

 

https://www.youtube.com/watch?v=M6NVLZx2m5Y