Biome이 ESLint+Prettier를 대체할 수 있을까

토요일 아침에 삽질이 시작됐다

ESLint 설정 파일을 보고 있었다. .eslintrc.json에 플러그인이 11개 들어있었다. eslint-plugin-import, eslint-plugin-jsx-a11y, @typescript-eslint... 거기에 Prettier 충돌 방지용 eslint-config-prettier까지. 솔직히 이 설정 파일을 처음부터 다시 짜라고 하면 못 한다. 2년 전에 스택오버플로우에서 복붙한 거에 그때그때 플러그인 추가한 누더기 코드다.

그래서 Biome을 써보기로 했다. (사실 트위터에서 멋있어 보여서.)

설치는 진짜 빨랐다

npm install --save-dev --save-exact @biomejs/biome 한 줄이면 끝이다. npx @biomejs/biome init으로 설정 파일 생성하면 biome.json 하나가 생긴다. ESLint + Prettier 합쳐서 설정 파일 3개에 의존성 패키지 14개였는데, Biome은 설정 파일 1개에 패키지 1개.

린트 + 포맷팅 실행도 npx biome check --write . 한 줄이다. 이 간결함에 바로 마음이 갔다.

속도 차이가 체감이 된다

프로젝트가 파일 287개짜리 Next.js 앱이었는데, ESLint + Prettier 돌리면 8.3초 걸렸다. Biome은 같은 프로젝트를 0.47초에 끝냈다. (정확히는 0.47초에서 0.52초 사이를 왔다 갔다 했다.) 거의 17배 차이. Rust로 만들어서 이런 건지, 아무튼 CI에서 린트 단계가 눈에 띄게 짧아졌다.

근데 사실 8초든 0.5초든 커피 한 모금 마시면 끝나는 시간이라, 체감 차이가 생각보다 크진 않다. 뭔가 엄청난 혁명을 기대했는데 "아 빠르네" 정도.

여기서부터 아쉬운 게 나온다

플러그인 생태계가 아직 ESLint에 한참 못 미친다. 이게 가장 큰 문제다. eslint-plugin-react-hooks 같은 건 Biome에 내장돼 있어서 괜찮은데, 프로젝트에서 쓰던 eslint-plugin-import의 정렬 규칙이나, eslint-plugin-testing-library 같은 건 Biome에 없다.

커스텀 룰을 작성하는 것도 안 된다. ESLint는 AST 기반으로 커스텀 룰을 만들 수 있는데, Biome은 그런 확장 포인트가 없다. "우리 팀만의 규칙"을 강제할 수가 없다는 뜻이다.

Prettier와 미묘하게 다른 포맷팅

Biome의 포맷터는 Prettier와 97% 호환된다고 공식 문서에 쓰여 있다. 근데 그 3%가 은근히 신경 쓰인다. 특히 긴 삼항 연산자 포맷팅이 다르고, 일부 JSX 줄바꿈 위치가 달라서 diff가 수백 줄 나왔다. 기존 코드베이스에 Biome을 넣으면 첫 커밋에서 거대한 포맷팅 변경이 생긴다.

사이드 프로젝트라서 "에이 그냥 커밋하자" 했는데, 팀 프로젝트였으면 이 diff 때문에 git blame이 다 망가진다. 이건 진심으로 고민해야 할 부분이다.

3주 써본 뒤 내린 판단

사이드 프로젝트나 새로 시작하는 프로젝트에서는 Biome이 확실히 좋다. 설정이 간단하고, 빠르고, 하나로 다 된다. 근데 이미 ESLint 생태계에 깊이 들어간 프로젝트에서는 아직 이르다.

나도 결국 회사 프로젝트는 ESLint + Prettier를 유지하기로 했다. eslint-plugin-boundaries라는 플러그인에 팀이 의존하고 있어서, 이걸 대체할 방법이 없었다. 약 487,000원어치의 CI 시간을 절약할 수 있다는 계산이 나왔는데, 그래도 마이그레이션 리스크가 더 컸다.

근데 이게 1년 뒤에도 같은 얘기일까

Biome 팀이 플러그인 시스템을 개발 중이라는 로드맵을 봤다. 이게 나오면 이야기가 완전히 달라질 수 있다. ESLint도 flat config로 대대적인 변화를 거치면서 설정이 간소화되고 있긴 한데, 여전히 Biome의 원커맨드 심플함에는 못 미친다.

솔직히 "지금 당장 갈아타야 하느냐"는 질문에는 "아직은 아니다"가 답이다. 근데 "주시하고 있어야 하느냐"에는 "당연하다"라고 답하겠다. Biome이 실패작이 되든, ESLint의 후계자가 되든, 어느 쪽이든 린트 도구의 사용자 경험이 나아지는 건 확실하다.

사이드 프로젝트에서는 계속 Biome 쓸 거다. 이 블로그도 Biome으로 돌아가고 있다. (솔직히 그냥 멋있어서.)