Biome으로 ESLint와 Prettier 정리하기, AI 코딩할 때 진짜 편했던 실전 세팅 이야기

요즘 AI로 코딩하다 보면 참 묘한 순간이 많아요. LLM이 코드는 꽤 그럴듯하게 만들어주는데, 막상 붙여넣고 보면 import가 지저분하거나, 세미콜론이 들쑥날쑥하거나, 포맷이 팀 규칙이랑 살짝 어긋나 있는 경우가 있거든요. 저도 20년 가까이 개발하면서 별별 도구를 다 써봤는데, 최근에는 이런 사소한 정리 작업이 은근히 사람 기운을 빼더라고요. 그래서 “이걸 AI한테 매번 다시 고쳐달라고 해야 하나?” 싶은 생각이 들었고, 그때 제대로 써보게 된 게 바로 Biome이었습니다.

사실 처음에는 저도 반신반의했어요. 이미 ESLint랑 Prettier 조합을 오래 써왔고, 프로젝트마다 나름 굴러가는 설정도 있었으니까요. 그런데 LLM을 쓰면서 코딩하는 시간이 늘어나니까, 기존 방식의 불편함이 더 크게 보이기 시작했습니다. AI에게 “포맷 맞춰줘”, “unused import 제거해줘”, “세미콜론 붙여줘” 같은 말을 자꾸 하게 되더라고요. 별거 아닌데, 이게 쌓이면 토큰도 쓰고 시간도 쓰고 집중력도 씁니다. 뭐랄까, 좋은 차 타고 가는데 신호마다 내려서 바퀴 닦는 느낌이랄까요.

ESLint와 Prettier를 오래 쓰면서 느꼈던 진짜 불편함

저는 ESLint와 Prettier를 싫어하지 않습니다. 오히려 오랫동안 고마웠던 도구들이에요. 문제는 둘을 같이 쓸 때 생기는 자잘한 마찰이었습니다. 프로젝트 초기에는 괜찮은데, 시간이 지나고 패키지 버전이 올라가고 팀원이 늘어나면 설정이 슬슬 복잡해져요.

예를 들면 이런 상황이 꽤 자주 나옵니다.

ESLint는 특정 스타일을 경고로 잡는데 Prettier는 다른 방식으로 자동 포맷함

eslint-config-prettier, eslint-plugin-prettier 같은 보조 패키지가 계속 추가됨

팀원마다 VSCode 포맷터가 달라서 저장할 때마다 코드가 흔들림

AI가 만든 코드를 붙여넣으면 import 정리부터 다시 해야 함

코드 리뷰에서 로직보다 포맷 이야기가 먼저 나옴

이게 하루 이틀이면 괜찮아요. 그런데 회사 일 하면서 일정에 쫓기고, 저녁에는 사이드 프로젝트 조금 만져보고, 주말에는 어디 바람이라도 쐬러 가고 싶은 40대 직장인 입장에서는 이런 반복 작업이 생각보다 크게 느껴집니다. 개발은 결국 집중력 싸움인데, 도구 설정 때문에 흐름이 끊기면 피곤해요.

제가 Biome을 마음에 들어 한 이유는 단순합니다. 린트와 포맷을 하나의 도구로 처리해준다는 점이에요. ESLint 따로, Prettier 따로, 둘 사이 충돌을 막는 설정 따로. 이런 구조가 아니라 Biome 하나로 어느 정도 정리가 됩니다. 이게 생각보다 마음을 편하게 해줍니다.

구분	ESLint + Prettier	Biome
설치 패키지	대체로 여러 개 필요	`@biomejs/biome` 하나로 시작 가능
설정 복잡도	프로젝트가 커질수록 충돌 가능성 증가	상대적으로 단순함
포맷 속도	프로젝트 크기에 따라 느려질 때가 있음	체감상 상당히 빠름
AI 생성 코드 정리	별도 포맷, lint fix를 자주 수행	저장 시 한 번에 정리하기 좋음
팀 적용 난이도	기존 설정에 따라 조율 필요	신규 프로젝트에서는 특히 편함

제가 테스트했던 프로젝트는 React 기반의 내부 관리자 도구였고, 대략 10만 줄 조금 안 되는 규모였습니다. 정확히 모든 환경에서 똑같다고 말할 수는 없지만, 제 노트북 기준으로 Prettier를 돌릴 때보다 Biome이 훨씬 가볍게 느껴졌어요. 저장하는 순간의 딜레이가 거의 사라지는 느낌이었습니다. 이런 건 숫자보다 손끝에서 먼저 옵니다. 개발자라면 알잖아요. 저장했는데 1초 멈칫하면 괜히 기분이 식는 거요.

Biome 설치는 가볍게, 설정은 팀 규칙처럼 단단하게

설치는 정말 별거 없습니다. 저는 요즘 pnpm을 주로 써서 아래처럼 설치했습니다.

pnpm add --save-dev @biomejs/biome

npm을 쓰면 이렇게 하면 됩니다.

npm install --save-dev @biomejs/biome

그다음 프로젝트 루트에 biome.json을 만들면 됩니다. 제가 실제로 자주 쓰는 설정은 아래와 비슷합니다. 프로젝트마다 조금씩 바꾸긴 하는데, AI 코딩이 많은 프로젝트에서는 이 정도만 잡아놔도 꽤 편합니다.

{
  "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "style": {
        "noNonNullAssertion": "off"
      }
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "trailingCommas": "all",
      "semicolons": "always"
    }
  }
}

여기서 제가 가장 좋아하는 옵션은 organizeImports입니다. LLM이 코드를 만들다 보면 import가 생각보다 지저분하게 나오는 경우가 많거든요. 안 쓰는 import가 남아 있기도 하고, 같은 모듈에서 가져올 수 있는 걸 여러 줄로 나눠놓기도 하고요. 사람도 급하면 그러는데 AI라고 늘 깔끔하겠습니까.

그런데 Biome organizeImports를 켜두면 저장하거나 명령어를 실행할 때 import를 정리해줍니다. 이 작은 기능 하나가 AI 코딩할 때 정말 편해요. 예전에는 LLM에게 이런 말을 자주 했습니다.

위 코드에서 사용하지 않는 import 제거하고 import 순서도 정리해줘.

이제는 거의 안 합니다. 그냥 붙여넣고 저장합니다. 그러면 Biome이 어느 정도 정리해줘요. 이게 바로 LLM 토큰 아끼는 방법 중 하나입니다. 거창한 최적화보다 이런 식으로 반복 문장을 없애는 게 실전에서는 더 잘 먹힙니다.

VSCode 설정까지 해두면 진짜 편해집니다

Biome은 설치만 해도 쓸 수 있지만, 저는 VSCode 설정까지 해두는 걸 추천합니다. 특히 AI로 코드를 자주 붙여넣는 분이라면 저장할 때 자동으로 정리되는 흐름을 만들어두는 게 좋아요. 손이 덜 갑니다. 손이 덜 가면 생각이 덜 끊깁니다.

VSCode 확장 프로그램에서 Biome을 검색해서 공식 확장을 설치한 다음, settings.json에 아래 설정을 넣어줍니다.

{
  "editor.defaultFormatter": "biomejs.biome",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.organizeImports.biome": "explicit",
    "quickfix.biome": "explicit"
  }
}

여기서 핵심은 editor.formatOnSave입니다. 파일 저장할 때 자동 포맷이 걸리니까, LLM이 만든 코드를 붙여넣은 뒤에 따로 “정리해야지” 하고 생각할 필요가 없습니다. 그냥 저장하면 됩니다. 이 단순함이 은근히 큽니다.

다만 팀 프로젝트라면 개인 VSCode 설정에만 의존하면 조금 위험합니다. 누군가는 WebStorm을 쓸 수도 있고, 누군가는 자동 저장을 꺼둘 수도 있거든요. 그래서 저는 보통 프로젝트 안에 .vscode/settings.json을 같이 넣는 편입니다. 물론 팀 분위기에 따라 다르긴 하지만, 최소한 기본 포맷터 정도는 맞춰두는 게 좋습니다.

{
  "editor.defaultFormatter": "biomejs.biome",
  "editor.formatOnSave": true
}

그리고 package.json에는 이런 식으로 스크립트를 넣어둡니다.

{
  "scripts": {
    "lint": "biome check .",
    "lint:fix": "biome check --write .",
    "format": "biome format --write ."
  }
}

이렇게 해두면 터미널에서 한 번에 정리할 수 있습니다.

pnpm lint:fix

저는 AI가 여러 파일을 한 번에 수정했을 때 이 명령어를 자주 씁니다. LLM이 컴포넌트, hook, type 파일까지 한꺼번에 만들어주는 경우가 있잖아요. 그때 파일 하나씩 열어보면서 정리하면 좀 귀찮습니다. 그냥 전체를 한 번 밀어주는 게 마음이 편해요.

AI 바이브 코딩할 때 Biome이 특히 빛나는 순간

요즘 말로 AI 바이브 코딩이라고 하죠. 큰 흐름을 잡고, LLM에게 코드를 생성하게 하고, 사람은 방향과 판단을 맡는 방식이요. 저는 이 방식이 꽤 괜찮다고 봅니다. 다만 조건이 있어요. 사람이 기준을 세워놔야 합니다. 기준 없이 AI가 만든 코드를 계속 받아들이면, 프로젝트가 금방 헝클어집니다.

Biome은 그 기준 중 하나가 되어줍니다. 아주 엄격한 아키텍처 규칙까지 잡아주지는 못하지만, 최소한 코드 스타일과 기본 lint 품질은 계속 맞춰줍니다. AI가 만들어준 코드를 사람이 읽기 전에 한 번 걸러주는 느낌이에요.

제가 최근에 만든 사이드 프로젝트에서는 React 컴포넌트를 LLM에게 이런 식으로 요청했습니다.

버튼 컴포넌트를 만들어줘.
props로 variant, size, disabled를 받고,
Tailwind CSS를 사용해서 스타일링해줘.
접근성을 고려해서 button type도 처리해줘.

예전 같으면 여기에 이런 문장까지 붙였을 겁니다.

들여쓰기는 2칸으로 해줘.
작은따옴표를 사용해줘.
세미콜론은 항상 붙여줘.
사용하지 않는 import는 제거해줘.

그런데 지금은 저런 말 안 붙입니다. 어차피 Biome이 처리할 수 있는 부분이니까요. LLM에게는 로직과 의도만 말합니다. 이게 생각보다 중요합니다. 프롬프트가 짧아져서 토큰을 아끼는 것도 있지만, 더 중요한 건 LLM이 엉뚱한 데 신경을 덜 쓰게 된다는 점이에요.

AI에게 너무 많은 스타일 규칙을 한꺼번에 말하면, 가끔 정작 중요한 로직이 부실해집니다. 물론 모델 성능이 좋아지면서 많이 나아졌지만, 그래도 저는 역할을 나누는 게 좋다고 봅니다.

작업	LLM에게 맡길 것	Biome에게 맡길 것
컴포넌트 생성	props 설계, 렌더링 구조, 조건 처리	포맷, 세미콜론, quote 스타일
리팩토링	책임 분리, 함수 추출, 네이밍 후보	import 정리, lint fix
버그 수정	원인 추론, 수정 방향 제안	기본 규칙 위반 감지
코드 리뷰 전 정리	변경 의도 설명, 리스크 체크	전체 파일 포맷 및 자동 수정

이렇게 역할을 나누면 개발 흐름이 훨씬 깔끔해집니다. LLM은 머리를 쓰는 일에 집중시키고, Biome은 청소를 맡기는 거죠. 저는 이 조합이 꽤 현실적이라고 생각합니다.

토큰을 아끼는 프롬프트 습관, 별거 아닌데 효과 있습니다

LLM 토큰 절약이라고 하면 뭔가 대단한 기법이 있을 것 같지만, 실무에서는 작은 습관이 더 중요합니다. 특히 개발 프롬프트는 반복 문장이 많아요. “TypeScript로 작성해줘”, “포맷 맞춰줘”, “import 정리해줘”, “ESLint 오류 없게 해줘” 같은 말들이 계속 붙습니다.

저는 Biome을 도입한 뒤로 프롬프트에서 스타일 관련 문장을 대부분 뺐습니다. 대신 이런 식으로 씁니다.

아래 요구사항에 맞춰 React 컴포넌트를 작성해줘.
상태 관리는 컴포넌트 내부에서 처리하고,
비즈니스 로직은 별도 함수로 분리해줘.

그리고 코드 스타일은 Biome에 맡깁니다. 굳이 LLM에게 포맷까지 완벽하게 맞추라고 하지 않는 거죠. 이 방식이 마음에 드는 이유는 단순합니다. 사람도 그렇잖아요. 친구에게 길 설명 부탁했는데 “글씨체는 이렇게 쓰고, 줄 간격은 이렇게 하고, 쉼표는 이렇게 찍어줘”라고 하면 피곤하죠. 그냥 어디로 가면 되는지만 물어보는 게 낫습니다.

제가 실제로 자주 쓰는 기준은 아래와 같습니다.

포맷 규칙은 프롬프트에 쓰지 않는다. Biome이 처리할 수 있으면 도구에게 맡깁니다.

import 정리 요청은 하지 않는다. organizeImports로 자동 처리합니다.

lint 오류를 붙여넣을 때는 필요한 줄만 준다. 전체 파일을 매번 던지지 않습니다.

파일 구조와 요구사항은 짧고 명확하게 준다. 스타일보다 의도가 중요합니다.

수정 요청은 한 번에 너무 많이 하지 않는다. AI도 한 번에 너무 많이 시키면 이상한 데서 새기 쉽습니다.

토큰 절약을 숫자로 보면 별거 아닌 것처럼 보일 수도 있어요. 프롬프트 한 번에 20~50 토큰 줄이는 정도니까요. 그런데 하루에 AI에게 수십 번 질문하고, 팀 단위로 쓰면 이야기가 달라집니다. 비용도 비용인데, 응답이 짧아지고 맥락이 선명해지는 효과가 있습니다.

실제로 만났던 문제와 해결 방식

도구 이야기를 할 때 좋은 점만 말하면 좀 재미없죠. 저도 Biome을 쓰면서 몇 번은 멈칫했습니다. 특히 기존 프로젝트에 도입할 때는 조심해야 합니다. 이미 ESLint 규칙이 빡빡하게 잡혀 있는 프로젝트라면, Biome으로 바로 갈아타기보다 범위를 나눠서 적용하는 게 좋습니다.

한 번은 기존 프로젝트에 Biome을 바로 적용했다가 변경 파일이 너무 많이 생긴 적이 있습니다. 로직은 그대로인데 포맷 변경이 수백 파일에 걸쳐 발생한 거죠. Pull Request를 열었더니 리뷰어가 한숨부터 쉬더라고요. “이거 로직 변경이랑 포맷 변경이 섞인 거예요?” 하고요. 그때 배웠습니다. 포맷 도구를 바꿀 때는 욕심내면 안 됩니다.

그 뒤로는 이렇게 나눠서 진행합니다.

기능 개발 PR과 포맷 변경 PR을 분리

먼저 biome check .로 영향 범위 확인

자동 수정 전 Git 변경 사항 백업

팀원들에게 VSCode 설정 공유

CI에서 Biome 체크를 돌릴지 여부를 따로 합의

기존 프로젝트에서 처음 실행할 때는 아래 명령어부터 추천합니다.

pnpm biome check .

문제를 확인한 다음 자동 수정이 괜찮겠다 싶을 때 아래 명령어를 실행하는 게 좋습니다.

pnpm biome check --write .

그리고 Git diff를 꼭 봅니다. 이건 습관입니다. 아무리 좋은 도구라도 자동 수정 결과를 눈으로 확인하는 과정은 필요해요. 20년 개발하면서 느낀 건데, 도구를 믿되 방치하면 안 됩니다. 믿고 확인해야 오래 갑니다.

팀에서 쓰려면 코드 리뷰 문화까지 같이 바뀝니다

Biome을 팀에 적용했을 때 가장 좋았던 건 코드 리뷰 분위기였습니다. 예전에는 리뷰에서 “여기 줄바꿈이요”, “import 순서가요”, “세미콜론 빠졌어요” 같은 이야기가 종종 나왔습니다. 말하는 사람도 민망하고 듣는 사람도 괜히 기분이 애매해요. 틀린 말은 아닌데, 뭔가 인간적인 에너지가 아깝습니다.

Biome을 쓰고 나서는 이런 이야기가 확 줄었습니다. 리뷰어는 로직을 봅니다. 상태 관리가 적절한지, API 에러 처리가 빠지지 않았는지, 컴포넌트 책임이 너무 커지지 않았는지 같은 중요한 이야기에 집중하게 됩니다.

제가 팀에 공유했던 체크리스트는 대략 이런 느낌이었습니다.

PR 올리기 전 pnpm lint:fix 실행하기

코드 리뷰에서는 포맷보다 로직과 설계 중심으로 보기

Biome 규칙 변경은 개인 취향으로 바로 바꾸지 않기

VSCode 확장 설치는 온보딩 문서에 포함하기

AI 생성 코드도 반드시 저장 후 Biome 적용 상태로 커밋하기

이런 작은 규칙을 맞춰두면 팀 전체의 피로도가 낮아집니다. 개발 조직에서 생산성이라는 게 꼭 대단한 프레임워크 도입으로만 올라가는 건 아니더라고요. 오히려 이런 사소한 마찰을 줄이는 쪽이 더 오래 갑니다.

Biome이 모든 걸 해결해주지는 않습니다

이 부분은 꼭 말하고 싶습니다. Biome이 좋다고 해서 모든 프로젝트에서 무조건 정답은 아닙니다. ESLint 생태계에는 정말 다양한 플러그인이 있고, 특정 프레임워크나 사내 규칙에 깊게 묶여 있는 프로젝트라면 ESLint가 여전히 더 유리할 수 있습니다.

예를 들어 아주 세밀한 custom rule을 많이 쓰는 프로젝트라면 Biome만으로는 부족할 수 있어요. 접근성 규칙이나 특정 라이브러리 전용 lint 규칙도 ESLint 플러그인 쪽이 더 풍부한 경우가 있습니다. 그러니 기존 대형 프로젝트에서는 한 번에 갈아엎기보다, 신규 프로젝트나 작은 서비스부터 적용해보는 걸 권합니다.

제가 생각하는 현실적인 기준은 이렇습니다.

상황	추천	이유
신규 React 또는 TypeScript 프로젝트	Biome 적극 추천	초기 설정이 단순하고 속도가 빠름
AI 코딩을 자주 하는 개인 프로젝트	Biome 추천	포맷, import 정리 요청을 줄일 수 있음
ESLint custom rule이 많은 대형 프로젝트	단계적 검토	기존 규칙 대체 가능 여부 확인 필요
팀원마다 에디터 설정이 제각각인 팀	Biome과 공용 설정 추천	저장 시 포맷 차이를 줄일 수 있음

도구는 늘 맥락이 중요합니다. 저는 Biome을 좋아하지만, 모든 팀에 “무조건 이거 쓰세요”라고 말하고 싶지는 않습니다. 다만 LLM을 활용한 개발을 자주 하고, 포맷이나 lint 정리에 시간을 빼앗기고 있다면 한 번쯤은 꼭 써볼 만합니다.

제가 지금 추천하는 Biome 사용 방식

지금 제 기준에서 가장 편한 방식은 단순합니다. 프로젝트 루트에 biome.json을 두고, VSCode 기본 포맷터를 Biome으로 맞추고, package.json에 체크 스크립트를 넣습니다. 그리고 LLM에게는 코드 스타일 이야기를 길게 하지 않습니다.

제 작업 흐름은 보통 이렇습니다.

LLM에게 구현 의도와 제약 조건만 전달

생성된 코드를 파일에 붙여넣기

저장하면서 Biome 자동 포맷 적용

pnpm lint:fix로 전체 정리

Git diff로 의도하지 않은 변경 확인

로직 중심으로 직접 리뷰

이 흐름이 익숙해지면 AI 코딩이 조금 더 안정적으로 느껴집니다. LLM이 가끔 엉뚱한 코드를 만들더라도, 최소한 스타일 문제로 머리 아플 일은 줄어드니까요. 사람은 판단에 집중하고, 도구는 반복 작업을 맡는 구조. 저는 이게 앞으로 개발자가 AI와 같이 일하는 꽤 괜찮은 방식이라고 봅니다.

이런 분들에게 특히 추천합니다

Biome은 특히 AI로 코딩하는 시간이 늘어난 개발자에게 잘 맞습니다. LLM에게 매번 포맷을 부탁하고 있거나, ESLint와 Prettier 설정 충돌 때문에 프로젝트 시작할 때마다 피곤했다면 꽤 만족할 가능성이 높아요.

개인적으로는 이런 분들에게 추천하고 싶습니다.

LLM으로 React, TypeScript 코드를 자주 생성하는 개발자

ESLint와 Prettier 설정 파일이 점점 부담스러워진 분

코드 리뷰에서 포맷 이야기를 줄이고 싶은 팀

신규 프론트엔드 프로젝트를 가볍고 빠르게 시작하고 싶은 분

AI 바이브 코딩을 하면서 토큰과 시간을 조금이라도 아끼고 싶은 분

솔직히 저도 처음에는 “또 새 도구 배워야 하나” 싶었습니다. 그런데 막상 써보니 배운다기보다 정리되는 느낌에 가까웠어요. ESLint와 Prettier 사이에서 신경 쓰던 부분이 줄고, LLM에게 반복해서 말하던 잔소리도 줄었습니다. 개발할 때 머릿속이 조금 조용해진다고 해야 할까요.

아직 Biome을 안 써보셨다면 작은 프로젝트에 먼저 적용해보세요. 설치하고 설정하는 데 오래 걸리지 않습니다. 특히 AI 코딩을 자주 한다면 체감이 꽤 빠르게 올 겁니다. 저도 이제 새 프로젝트를 만들 때는 거의 습관처럼 Biome부터 세팅합니다. 이런 도구 하나가 개발자의 하루를 아주 드라마틱하게 바꾸지는 않겠지만, 적어도 덜 귀찮게는 만들어줍니다. 그리고 나이가 들수록, 저는 그 “덜 귀찮음”의 가치를 점점 더 믿게 되더라고요.

🔍 관련 정보 더 보기

Iros

이 블로그 검색

Featured Post

AI 바이브 코딩으로 GitHub Actions 짤 때, 토큰 덜 쓰고 덜 헤매는 내 방식