프로덕션 빌드에서 절대 경로 문제로 Turbopack을 webpack으로

개발 단계에서는 빨라야 한다. Turbopack이 매력적이었던 이유다. 그런데 프로덕션 환경에 배포할 땐 얘기가 달랐다. macOS 머신에서 빌드한 결과물에 절대 경로가 고스란히 남아있는 현상을 발견했고, 이게 배포 재현성과 보안상 문제가 될 수 있다는 판단 아래 webpack으로 전환했다.

Turbopack의 매력과 현실의 간격

처음 Turbopack을 도입했을 때 가장 큰 기대는 번들링 속도였다. 팀의 빌드 피드백 루프를 줄이고, CI/CD 시간을 단축하고 싶었다. 개발 환경에선 정말 그 효과가 있었다. Next.js와 함께 번들링 되는 속도가 눈에 띄게 빨랐거든.

문제는 프로덕션 빌드였다. Turbopack이 번들링할 때 macOS의 경로를 절대 경로로 임베딩하는 현상이 발생했다. 예를 들면:

/Users/developer-username/projects/app/src/...

이런 식의 경로가 최종 번들 안에 남아있으면, 다른 개발자의 머신이나 CI 서버에서 빌드한 결과물과 일관성이 깨진다. 로컬에서 동작하는 빌드가 CI에서 실패하거나, 팀원마다 다른 바이너리가 생성되는 상황이 만들어진다.

근본 원인과 영향 범위

이런 경로 임베딩 문제는 단순히 "보기 흉한" 수준을 넘어간다:

• 배포 재현성 (Reproducibility): 같은 소스코드에서 다른 번들이 나온다
• 캐시 무효화: CI에서 아티팩트 캐싱이 제대로 작동하지 않음
• 보안: 개발자의 로컬 디렉토리 구조가 프로덕션 번들에 노출됨
• 디버깅: 소스맵에 절대 경로가 섞여 있으면 다른 환경에서 추적 어려움

Turbopack은 빠르지만 아직 프로덕션 ready 관점에서는 edge case가 있다는 뜻이었다. 개발 환경의 속도와 프로덕션 안정성 중 뭘 우선할지는 자명했다.

의사결정: Dev/Prod 빌드 도구 분리

가장 먼저 검토한 게 "과연 Turbopack을 고쳐야 하나"였다. 커뮤니티 이슈를 봐도 이건 알려진 문제고, 해결 일정이 명확하지 않았다. 우리는 기다릴 여유가 없었다.

그래서 선택한 전략은 이중 번들러 설정이다:

package.json에서 build script를 분리하면 되는 문제였다. dev는 Turbopack으로 빠르게 가고, prod build만 webpack으로 가도록 설정하면, 로컬 개발 생산성과 프로덕션 안정성을 모두 챙길 수 있다.

// 예시 구조
"scripts": {
  "dev": "turbo dev",           // 개발: 빠름
  "build": "webpack build",      // 프로덕션: 안정적
  "build:dev": "next build"      // 개발 검증용
}

팀 차원의 고민과 배운 점

이런 결정을 내릴 땐 팀에 전달할 메시지도 중요하다. "우리가 새 도구를 포기한다"는 식으로 들릴 수도 있으니까. 실제로는 "각 상황에 최적 도구를 쓴다"는 프래그마틱한 접근이다.

프로덕션 빌드는 속도보다 정확성과 재현성이 우선이다. 배포 시간이 2초 더 걸려도 괜찮지만, 프로덕션 환경에서 예측 불가능한 버그가 나면 큰 문제다. 팀원들도 이 우선순위에 공감했다.

또 한 가지 배운 점은, 기술 도구를 선택할 때 "새것"이라는 이유로 모두 바꿀 필욘 없다는 것. Turbopack은 정말 좋은 도구지만, 우리의 프로덕션 기준에 아직 안 맞는 부분이 있었다. 그럼 그 부분만 안정적인 솔루션으로 우회하는 게 현명하다.

프로덕션 빌드는 선택지가 아니라 필수 요건이기 때문에, 거기서 절대 경로 임베딩이 발생하면 즉각 대응해야 한다. 이게 팀장 입장에서의 의사결정 기준이었다.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.