Monorepo를 Bun으로 마이그레이션한 솔직한 후기

최근에 Intlayer(i18n 솔루션) — 여러 앱(Next.js, Vite, React, design-system 등)으로 구성된 monorepo — 를 pnpm에서 Bun으로 마이그레이션했습니다.

요약 (TL;DR): 미리 알았다면, 아마 하지 않았을 겁니다.
몇 시간 걸릴 줄 알았는데, 실제로는 약 20시간이 걸렸습니다.

“올인원(all-in-one)”이라는 약속과 놀라운 성능 벤치마크에 끌렸습니다.
설정하고, 빌드하고 — 번개처럼 빠르더군요.
“좋아, 커밋하자!” 했는데… 첫 번째 문제가 발생했습니다.

Husky가 작동하지 않음

commit-msg와 pre-commit 파일 안에 직접 Bun 경로를 추가해야 한다는 사실을 알게 됐습니다.
공식 문서에는 아무런 설명이 없었습니다.
GitHub 이슈를 깊게 파고들어 해결책을 찾아야 했습니다.

다음은 GitHub Actions.
변경 → 푸시 → 대기 → 확인 → 수정 → 반복 × 15회.
캐시 문제를 디버깅하는 데만 3시간이 걸렸습니다.
드디어 모든 빌드가 통과.
이제 앱을 실행할 차례… 라고 생각했는데, 또 문제가 생겼습니다.

백엔드 (Backend)

문제 1:
express-rate-limit을 사용하면 모든 요청이 실패했습니다.

문제 2:
앱에서 사용하는 express-intlayer는 컨텍스트 변수를 위해 cls-hooked에 의존합니다.
하지만 Bun은 cls-hooked를 지원하지 않습니다.

해결책: Bun으로 빌드하고 Node로 실행.

웹사이트 (Website)

문제 1:
로컬에서는 빌드가 잘 되었지만, 공식 Bun 이미지 기반의 컨테이너에서는 빌드가 무한 정지.
CPU 100% 사용 후 서버가 크래시.
결국 롤백했습니다.
2023년 GitHub 이슈에서 “Node 이미지를 사용하고 Bun을 수동으로 설치하라”는 해결책을 찾았습니다.

문제 2:
Design system 컴포넌트에서 “module not found” 오류가 발생했습니다.
Bun은 여전히 패키지 경로 해석에 어려움을 겪고 있습니다.
createRequire 호출을 모두 교체하고 (CJS/ESM 호환성을 위해), 필요한 모든 함수에 require를 직접 전달해야 했습니다.

그 외의 오류는 생략하겠습니다.

수많은 시간을 들인 끝에, 마침내 모든 것이 작동했습니다.
그렇다면 CI 성능 향상은 어땠을까요?

런타임에서는 Express와 Next.js 앱 모두 여전히 Node에서 실행 중입니다.

결론

“이제 Bun으로 마이그레이션할 때인가요?”라고 묻는다면, 제 답은 이렇습니다:

작동은 하지만, 복잡한 프로젝트에는 아직 프로덕션 준비가 완벽하지 않습니다.

그럼에도 불구하고, 저는 Bun의 잠재력을 높이 평가하며 앞으로의 발전이 무척 기대됩니다.

여러분은 마이그레이션 중 비슷한 문제를 겪으셨나요?