사실상 코드잽에 합류하게 된 이유인 모노레포! 그걸 도입하기로 한 이유와 그 과정을 설명해보자 합니다.
🌐 기존 코드잽 프로젝트 구조
현재 코드잽 프로젝트는 다음과 같은 구조로 이루어져 있습니다:
- backend
- frontend
- chrome-extension (서브 모듈로 관리)
또한 앞으로 추가될 예정인 패키지들:
- vscode-extension
- intellij-plugin
이러한 구조에서는 프론트엔드에서 이미 구축한 디자인 시스템을 크롬 익스텐션에서 전혀 사용할 수 없는 상황입니다. 이로 인해 크롬 익스텐션에서 디자인 시스템을 별도로 작업해야 했고, API 스펙에 변경 사항이 생길 경우 프론트엔드와 크롬 익스텐션 코드를 각각 수정해야 하는 불편함이 있었습니다.
이러한 문제를 해결하기 위해 디자인 시스템과 공통 모듈을 분리하고, 모노레포 구조를 도입하여 코드 재사용성을 높이고 유지보수성을 개선하려는 계획을 세우게 되었습니다.
🏗️ 모노레포 전환 후 예상되는 이점
모노레포 구조로 전환했을 때 기대할 수 있는 주요 이점은 다음과 같습니다:
- 코드 재사용성 향상
- 디자인 시스템, 유틸리티 함수, API 클라이언트 등의 공통 코드를 여러 패키지에서 쉽게 공유하고 재사용할 수 있습니다. 이를 통해 중복된 코드를 줄이고, 디자인이나 API 수정이 필요할 때 한 곳에서만 수정하여 모든 프로젝트에 반영할 수 있습니다.
- 일관된 코드 스타일 및 설정
- ESLint, Prettier, 테스트 설정 등을 모노레포 전체에 통일되게 적용할 수 있습니다. 이렇게 하면 각 패키지 간에 일관된 코드 스타일을 유지할 수 있으며, 새로운 패키지를 추가할 때도 빠르게 동일한 설정을 적용할 수 있습니다.
- 버전 관리 및 배포 효율성
- pnpm과 같은 도구를 사용하면 각 패키지의 버전을 명확하게 관리할 수 있으며, 필요한 경우에만 패키지를 개별적으로 배포할 수 있습니다. 이를 통해 불필요한 배포를 줄이고 유지보수 및 배포 프로세스의 효율성을 높일 수 있습니다.
- 협업 효율성 향상
- 모든 코드가 하나의 레포지토리에서 관리되므로, 팀원 간 협업이 더 원활해집니다. 서로 다른 모듈에서 작업하더라도 중앙에서 변경 사항을 쉽게 추적할 수 있고, 코드 리뷰 과정에서 여러 패키지에 영향을 미치는 변경 사항을 한눈에 파악할 수 있습니다.
🔍 모노레포 도입을 위한 도구 선택: 왜 pnpm인가?
모노레포를 도입하기로 결정한 후, 도입할 도구에 대한 선택지가 많았습니다. 대표적으로 Turborepo, Lerna 등 다양한 도구들이 있었고, Yarn, npm, pnpm 같은 패키지 매니저도 고려해볼 수 있었습니다. 이 중에서 우리는 pnpm을 선택하게 되었습니다.
🛠️ pnpm을 선택한 이유
- 효율적인 디스크 공간 관리
- pnpm은 의존성을 설치할 때 디스크에 중복으로 저장하지 않고, 하드 링크 방식으로 관리하여 디스크 공간을 절약합니다. 특히 모노레포 환경에서는 여러 패키지가 동일한 의존성을 사용하는 경우가 많기 때문에, 이 방식이 더욱 유리합니다.
- 빠른 설치 속도
- pnpm은 패키지를 설치하는 속도가 매우 빠릅니다. 이는 모노레포 환경에서 많은 패키지를 관리할 때 개발 속도와 CI/CD 파이프라인에서 설치 시간을 크게 단축할 수 있습니다. 기존의 npm과 달리 성능 문제를 효과적으로 해결했습니다.
- workspace 지원
- pnpm은 모노레포 환경에서 각 패키지를 workspaces로 관리할 수 있습니다. 이를 통해 각 프로젝트의 의존성을 루트 레벨에서 한 번에 관리하고, 패키지 간의 의존성을 명확하게 설정할 수 있어 유지보수와 배포가 용이해집니다.
- 패키지 간 의존성 관리
- pnpm은 패키지 간의 의존성 일관성을 보장합니다. 패키지 간 의존성을 정확하게 관리하고, 프로젝트 간 의존성 충돌을 줄여 안정성을 높일 수 있습니다.
🚀 향후 계획 및 고려할 점
모노레포로의 마이그레이션 과정에서 우리는 빌드 및 테스트 속도 관리, 패키지 간 의존성 트리 관리, CI/CD 파이프라인 구축 등의 기술적 요소들을 신중하게 고려할 예정입니다. 특히 pnpm의 workspace 관리를 통해 빌드 및 배포 프로세스를 최적화하고, 개발 및 배포 과정에서 효율성을 확보하는 것이 주요 목표입니다.
마이그레이션 이후에는 모든 패키지가 공통된 코드와 설정을 공유하게 되어, 코드 변경에 따른 유지보수가 훨씬 간편해지고, 더 나은 협업 환경을 제공할 수 있을 것입니다.
모노레포로로 마이그레이션을 진행하면서 프로젝트 전반의 유지보수성과 협업 효율성을 높이는 데에 중요한 역할을 할 것으로 기대하고 있습니다 ~ ! 진행 후 회고도 작성하도록 하겠습니다. 많관부...
'우테코' 카테고리의 다른 글
[우테코 6기] 불필요하게 리랜더링 되는 문제 해결하기 (0) | 2024.12.02 |
---|---|
[우테코 6기] 사용자 피드백 반영 및 A/B 테스트로 UX 개선하기 (2) | 2024.11.27 |
[우테코 6기] 모든 팀의 AWS S3 프로젝트 폴더를 날렸다고..? (0) | 2024.10.02 |
[우테코 6기] 개발자가 현장 유저 테스트에서 깨달은 것: 불편함을 개선하다 (2) | 2024.10.02 |
[우테코 6기] 지치지 않고 협업하는 법 (0) | 2024.10.01 |