안녕하세요! 그로스로그 입니다!😊 🌱
프로젝트가 커지며 길어진 빌드 시간을, 도구를 바꿔 35% 줄인 기록입니다. 2기 7회차입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
이번 회차는 큐레이션 한 편입니다. 회차마다 글의 수는 달라지지만, 한 편이든 세 편이든 기록은 이어집니다. 오늘 소개할 글은 짧지만 밀도가 높아요.
01
⚡ Bun으로 빌드시간 35% 단축하기
이종경 님
회사에서
pnpm으로 빌드하던 프로젝트가 커지면서 빌드 시간이 점점 길어지는 문제를 만납니다.이를 해결하려고 Bun을 도입했고, 설치 방법과 특징, 그리고 실제 도입 후 얻은 결과를 정리했어요.
결과가 명확합니다. 2분 30초~3분이던 빌드가 2분~2분 10초로. 회사 프로젝트에 새 도구를 적용하고 숫자로 확인한 기록입니다.
빌드 시간은 조용히 나빠지는 지표입니다. 어제보다 5초 느려진 건 아무도 못 느껴요. 그런데 반년 지나면 3분이 되어 있습니다.
조금 더 들어가 보면
빌드 시간이 왜 개발자에게 중요한지부터 짚어볼게요.
빌드는 하루에 한 번 하는 일이 아닙니다. 배포할 때마다 돌고, CI에서 PR마다 돌고, 브랜치를 바꿀 때마다 의존성을 다시 설치합니다. 3분짜리 빌드를 하루 10번 돌리면 30분이에요. 팀이 다섯 명이면 하루 2시간 반이 사라집니다.
더 큰 비용은 따로 있습니다. 집중이 끊기는 것이요. 30초짜리 빌드는 기다립니다. 3분짜리 빌드는 그동안 다른 걸 보게 돼요. 슬랙을 열고, 메일을 보고, 돌아왔을 때는 뭘 하려 했는지 잠시 더듬습니다. 시간보다 이 흐름의 단절이 더 큽니다.
그래서 빌드 속도 개선은 성능 최적화가 아니라 개발 경험(DX) 개선에 가깝습니다. 사용자에게 보이지 않지만 만드는 사람의 하루를 바꿔요.
🧭 Bun이 무엇인가
글은 Bun을 "JavaScript 및 TypeScript 런타임"으로 소개합니다. 그런데 이 한 줄이 Bun의 특이한 성격을 다 담지는 못해요.
보통 프론트엔드 프로젝트에는 도구가 여러 개 필요합니다. 실행할 런타임(Node.js), 패키지를 설치할 관리자(npm/yarn/pnpm), 번들링할 빌드 도구(webpack/Vite), TypeScript를 변환할 컴파일러. 각각 따로 설치하고 따로 설정하죠.
Bun은 이걸 하나로 합칩니다. 런타임이면서 패키지 관리자이고, 빌드 도구이자 TypeScript를 그대로 실행합니다. 글이 정리한 특징이 정확히 그 지점들이에요.
· 통합된 도구 — 자체 패키지 관리자를 내장해 npm이나 yarn을 대체
· 네이티브 TypeScript 지원 — 별도 설정 없이 .ts 파일을 바로 실행
· ESM과 CommonJS 모두 지원 — 기존 코드베이스와의 호환성
· 간단한 설치 — 설정이 최소화되어 있음
그리고 하나 더. Bun은 Zig라는 언어로 만들어졌습니다. 글에도 그 부분이 나와요.
이게 왜 중요하냐면, 기존 JavaScript 도구들은 대부분 JavaScript로 만들어져 있었기 때문입니다. JavaScript로 만든 도구가 JavaScript를 처리하는 구조였죠. 편하지만 빠르기 어렵습니다.
최근 몇 년의 흐름은 이 부분을 바꾸는 것이었습니다. esbuild는 Go로, SWC와 Turbopack은 Rust로, Bun은 Zig로 만들어졌어요. 도구 자체를 시스템 언어로 다시 짜서 속도를 확보하는 방향입니다. Bun의 빠름은 마법이 아니라 이 선택의 결과예요.
📝 원문에서는 이렇게 설치합니다
설치는 한 줄입니다. 윈도우 지원이 추가된 것도 짚어뒀어요.
# Mac OS or Linux curl -fsSL https://bun.sh/install | bash # Windows powershell -c "irm bun.sh/install.ps1 | iex"
설정 파일은 이름이 조금 독특합니다. package.json이 아니라 bunfig.toml이에요.
[install] # 2.1.0과 같이 캐럿이 추가되지 않고 정확한 버전이 설치됩니다. exact = false
짧지만 짚을 만한 옵션입니다. exact는 패키지 버전을 얼마나 엄격하게 고정할지를 정해요.
기본값에서는 ^2.1.0처럼 캐럿이 붙습니다. "2.x 안에서는 더 새 버전이 나오면 받아도 좋다"는 뜻이죠. 편하지만, 어제 되던 빌드가 오늘 깨지는 일이 여기서 생깁니다. 내 코드는 그대로인데 라이브러리가 바뀐 거예요.
exact = true로 두면 2.1.0으로 딱 고정됩니다. 업데이트는 직접 해야 하지만, 어제와 오늘의 빌드가 같다는 보장을 얻습니다. 팀 프로젝트나 배포 파이프라인에서는 이쪽이 안전한 경우가 많아요.
📊 그리고 숫자로 확인한 것
이 글에서 가장 값진 부분은 결과를 재서 적어뒀다는 점입니다.
| pnpm | bun | |
|---|---|---|
| Vite 빌드 시간 | 2분 30초 ~ 3분 | 2분 ~ 2분 10초 |
대략 30~35% 단축입니다. 제목의 숫자가 여기서 나왔어요.
이 표가 왜 중요할까요. 도구를 바꿔본 글은 많지만, 바꾸기 전과 후를 같은 조건에서 잰 글은 드물기 때문입니다.
새 도구를 도입할 때 흔한 함정이 있습니다. 빠르다는 소문을 듣고 바꾸고, 빨라진 것 같다고 느끼고, 그대로 넘어가는 거죠. 그런데 체감은 자주 틀립니다. 직접 고른 도구는 실제보다 빠르게 느껴지고, 마침 그날 컴퓨터가 한가했을 수도 있어요.
이 글은 범위로 적었습니다. "2분 30초"가 아니라 "2분 30초~3분"이에요. 여러 번 재봤다는 뜻입니다. 그리고 새 도구도 "2분"이 아니라 "2분~2분 10초"로 적었어요. 자기 결과를 좋게 보이게 하려면 최고 기록만 적으면 되는데, 그러지 않았습니다.
팀에 제안할 때 필요한 게 정확히 이런 형태의 근거입니다. "요즘 이게 빠르대요"로는 도구를 못 바꿉니다. "우리 프로젝트에서 재보니 30% 줄었습니다"여야 설득이 돼요.
🧭 조금 더 생각해 볼 것
이 글을 읽고 따라 해보고 싶다면, 몇 가지 함께 생각해두면 좋습니다.
첫째, 어느 단계가 줄었는지 나눠보기. 빌드는 크게 의존성 설치와 번들링으로 나뉩니다. Bun이 크게 이기는 쪽은 대체로 설치 단계예요. 이 글에서도 번들링 자체는 Vite가 그대로 하고 있습니다. 그러니 CI처럼 매번 새로 설치하는 환경에서 효과가 더 큽니다. 반대로 로컬에서 설치가 캐시되어 있다면 체감이 작을 수 있어요.
둘째, 호환성은 프로젝트마다 다릅니다. Bun은 Node.js와의 호환을 목표로 하지만 100%는 아닙니다. 네이티브 모듈이나 특정 빌드 스크립트에서 어긋나는 경우가 있어요. 그래서 먼저 CI에서만 써보고, 문제가 없으면 넓히는 순서가 안전합니다.
셋째, 잠금 파일이 바뀝니다. 패키지 관리자를 바꾸면 pnpm-lock.yaml 대신 Bun의 잠금 파일이 생깁니다. 팀원 일부는 pnpm, 일부는 bun을 쓰면 설치되는 버전이 서로 달라질 수 있어요. 도구를 바꾸는 건 개인 선택이 아니라 팀 결정이어야 하는 이유입니다.
이건 이 글의 부족한 점이 아니라, 이 글을 출발점으로 삼아 각자 확인해볼 것들입니다. 좋은 글은 답을 다 주지 않고 다음 질문을 만들어줘요.
큐레이터 노트
회사 프로젝트에서 실제로 바꾸고, 그 결과를 숫자로 남겼기 때문에 뽑았습니다.
개인 프로젝트에서 새 도구를 써보는 건 부담이 적습니다. 안 되면 되돌리면 되니까요. 그런데 회사에서 쓰는 빌드 파이프라인을 바꾸는 건 다릅니다. 팀원 전체의 환경이 영향을 받고, 배포가 걸려 있어요. 그 결정을 하고 결과까지 확인한 기록이라 무게가 다릅니다.
그리고 문제에서 출발했다는 점이 좋았습니다. "Bun이 요즘 뜬다더라"가 아니라 "프로젝트가 커지면서 빌드가 느려졌다"가 첫 문장이에요. 도구가 먼저가 아니라 문제가 먼저입니다. 이 순서가 맞아야 나중에 "왜 이걸 쓰나요"라는 질문에 답할 수 있어요.
글 자체는 길지 않습니다. 그런데 문제 → 대안의 특징 → 적용 방법 → 측정 결과라는 뼈대가 전부 들어 있어요. 기술 도입 글이 갖춰야 할 구조입니다. 짧다고 얕은 글이 아니라는 걸 보여주는 사례라 더 반가웠습니다.
이번 회차에서 가져갈 것
1. 바꾸기 전에 먼저 재기. 개선을 주장하려면 바꾸기 전 숫자가 있어야 합니다. 지금 우리 프로젝트의 빌드가 몇 초인지 모른다면, 오늘 한 번 재두세요. 그 숫자가 나중에 근거가 됩니다.
2. 체감 대신 범위로 적기. 한 번 재고 "2분"이라고 쓰는 것보다 여러 번 재고 "2분~2분 10초"라고 쓰는 게 정확합니다. 자기 결과를 부풀리지 않는 기록이 결국 더 오래 신뢰받아요.
3. 도구는 문제에서 고르기. 새 도구가 좋아 보여서 쓰는 것과, 겪고 있는 문제를 풀려고 쓰는 것은 다릅니다. "무엇이 불편했는가"를 먼저 한 문장으로 쓸 수 있어야 도입 결정이 흔들리지 않습니다.
4. 팀에 영향을 주는 변경은 단계적으로. 패키지 관리자처럼 모두가 쓰는 도구는 CI에서 먼저 → 문제없으면 로컬로 순서가 안전합니다. 잠금 파일이 갈리면 "내 컴퓨터에선 되는데"가 시작돼요.
좋은 글 남겨주신 이종경 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.