🛸 오늘의 주제 - 기술 스택 선정 과정

comfit FE팀의 모토는 ‘기초부터 탄탄히, 근거있는 개발’이에요. 우리는 충분한 논의를 통해 기술 스택을 선정했어요. 우리의 서비스를 100% 이해하고 어떤 선택이 우리 팀에게 가장 핏한, 최적의 선택일지 치열하게 고민하여 아래와 같은 선택을 내렸습니다.

[ comfit FE Tech Stack ]

⚡🔗 빌드 도구 및 패키지 매니저: Vite + pnpm


프로젝트의 초기 기술 스택 선정은 단순한 도구의 선택을 넘어, 팀의 개발 생산성과 협업의 안정성을 결정짓는 중요한 요소예요. 그래서 우리는 제한된 앱잼 기간 내에 빠른 기능 구현이라는 단기 목표와 안정적인 의존성 관리라는 장기적 가치를 모두 충족하기 위해 Vitepnpm을 도입했습니다.

vite+pnpm.png

⚡Vite

기존의 Webpack같은 번들러는 개발 서버를 띄울 때 모든 소스 코드를 하나로 뭉치는 번들링(Bundling) 과정이 선행되어야 했기 때문에, 프로젝트 규모가 커질수록 서버 구동과 갱신 속도가 느려져 개발 흐름이 끊기는 문제가 있었어요.

반면 **Vite**는 브라우저가 개별 모듈을 직접 가져올 수 있는 Native ESM 방식을 활용해요. 소스 코드를 미리 번들링하지 않고, 브라우저가 요청하는 파일만 그 즉시 변환하여 전달하기 때문에 서버 구동이 빨라지며, 수정 사항에 대한 반영(HMR: Hot Module Replacement) 속도 역시 빨라집니다.

이는 코드를 작성하고 결과를 확인하는 피드백 시간을 줄여서, 기능 구현에 온전히 집중할 수 있게 합니다.

🔗pnpm

단순히 빠른 설치 속도를 넘어, 프로젝트 패키지의 효율적인 관리를 위해 **pnpm**을 선택했습니다.

기존의 npm이나 yarn은 디스크 낭비를 줄이기 위해 의존성 패키지들을 최상위로 끌어올리는 평탄화(Hoisting) 방식을 사용해왔어요. 하지만 이 방식은 package.json에 명시하지 않은 하위 의존성 패키지까지 코드에서 접근할 수 있게 만드는 유령 의존성 문제를 야기해요. 이는 특정 패키지가 업데이트되거나 사라질 때 원인 모를 런타임 에러를 발생시키는 주범이 되며, 복잡한 의존성 트리를 재구성하느라 설치 속도 또한 저하시키게 됩니다.