큐샵에서 사용하는 에디터와 라이브 페이지에서 공통적으로 사용하는 컴포넌트들이 분명 있음에도 불구하고 각 레포지토리에서 “복붙” 하여 사용하고 있었다.
사람이 직접 하는 일이다 보니, 미처 확인하지 못한 부분에서 싱크가 맞지 않아 에러가 발생한 적도 종종 있었다.
앞으로 에디터의 기능 고도화가 이루어지는 만큼 사이드이펙트는 더 심해질 것을 우려하여 공통 모듈화가 필요했다.
공통 모듈화를 할 수 있는 방법으로 npm, 모노레포, 서브모듈을 비교 해봤다.
1. npm
Node.js 기반 프로젝트의 패키지 관리 도구로, 오픈 소스 라이브러리를 설치하고 관리할 수 있는 방식.
이전에 아예 생각을 안해봤던것은 아니다.
개인프로젝트로 사용하고 있던 디자인시스템을 npm 으로 배포하여 사용중이었는데, 우리 팀도 npm 으로 관리하는 방향에 대해 제안을 한 적 있다.
하지만 리드님께서 npm에서 프라이빗 패키지를 배포하려면 유료 멤버십을 결제해야 하고,
회사의 여러 사정상 .. 결국 퍼블릭으로 배포할 수밖에 없다고 하셨다. 이렇게 되면 보안 리스크도 생길 수 있기 때문에 다른 방법을 찾아보기로 했다.
2. monorepo
모든 관련 프로젝트를 하나의 저장소에서 관리하는 방식. ex - UI, PC, Mobile, Utils 등 다양한 프로젝트를 하나의 레포에서 관리
모노레포를 사용해본 경험은 없지만 이론적으로 봤을 때, 하나의 부모 레포지토리 안에 공통적으로 사용 될 여러 프로젝트들이 있는 개념이다.
모놀리스 형태의 큐샵의 에디터와 라이브 레포를 하나로 합치는것은 당연히 불가능하고, 다른 개념으로 접근해야 한다. 만약 우리가 UI, PC, Mobile 등 여러 프로젝트를 나누어 멀티레포식으로 이미 개발환경을 구축 했다면 모노레포를 선택했을지도 모른다.
아직 모듈화를 진행한 적이 없기 때문에 모노레포 내부에서 사용할 프로젝트 자체가 존재하지 않는 상황에서 바로 모노레포를 시도하는 것은 약간 오버스펙이라고 생각했다.
또한 큐샵 개발팀은 ci/cd 전략 및 버저닝 전략이 완벽하게 책정된것이 아니다.
모듈에 따라 CI를 돌릴지 말지 또 회의를 거쳐야 할테고 정해야 할 규칙이 많아질 수 있기 때문에 오히려 모노레포의 장점인 통합 버전관리 면에 있어서 더 혼란을 줄 수 있다고 생각했다.
장점:
- 통합된 버전 관리: 모든 프로젝트가 같은 버전 관리 시스템 안에서 관리되므로, 변경사항 추적 용이.
- 코드 공유와 재사용: 코드 베이스가 한 곳에 있기 때문에 코드의 공유와 재사용이 용이.
- 변경사항 : 한 번의 커밋으로 여러 프로젝트에 걸쳐 변경 사항 적용 가능.
- 통합된 빌드와 테스트: 전체 코드 베이스에 대한 빌드와 테스트를 쉽게 관리.
단점:
- 초기 설정 복잡: 기존 레포지토리를 모노레포로 전환하려면 구조변경 및 빌드 파이프라인까지 개선 필요.
- 규모의 복잡성: 프로젝트의 크기가 커질수록 관리의 복잡성 증가.
- 빌드 시간: 전체 저장소에 대한 빌드 시간이 길어질 수 있다 (캐싱도구로 개선 가능).
3. submodule ✔️
git 저장소 안에 다른 git 저장소를 서브 디렉토리로 분리하여 독립적으로 관리하는 방식. ex - UI, PC, Mobile 등 독립적인 저장소로 별도 관리하고 부모 레포에서 클론
큐샵 프로젝트는 에디터팀과 커머스팀의 배포주기가 다르다.
LP 레포지토리의 경우, 두 팀이 작업하는 코드가 모두 속해있었기 때문에, 에디터에서 작성된 코드가 커머스 배포주기때 올라가면 곤란한 상황이 생겨 더욱더 독립적인 환경이 필요했다.
서브모듈의 핵심은 독립적인 코드 관리에 있다.
서브모듈은 각각의 독립된 Git 저장소를 부모 레포지토리에 Clone 해서 포함할 수 있으며, 각 저장소의 커밋은 필요한 시점에 공통 코드를 업데이트하거나 특정 버전을 고정하여 사용할 수 있다.
다만, 이 독립적인 특성때문에 커밋과 병합 과정이 오고가는 과정에서 오히려 복잡함을 느낄수 있다. 이러한 이유때문에 코드의 변경 빈도가 낮고 주기적으로 업데이트 할 필요가 없을때 효율적일 수 있다.
private 한 레포지토리가 가능하여 보안성 또한 유지할 수 있다.
클론을 하면 에디터나 라이브가 더 무거워지는게 아닌가? 라는 생각을 할 수 있겠지만 각 서브모듈의 최신 해시값만 git 에 올라가기 때문에 걱정하지 않아도 된다.
장점:
- 독립성: 서브모듈은 각각 독립적인 저장소로, 자체적인 버전 관리가 가능.
- 재사용성: 공통 코드를 서브모듈로 관리함으로써 다른 프로젝트에서 재사용 가능.
- 액세스 제어: 각 서브모듈에 대한 액세스를 별도로 제어 가능.
단점:
- 복잡성: 서브모듈을 추가하고 업데이트하는 과정이 복잡할 수 있다.
- 커밋 관리: 서브모듈의 변경 사항을 추적하려면 부모 저장소에서 서브모듈의 커밋을 참조해야 한다.
- 의존성 관리: 서브모듈 간의 의존성을 관리하는 것이 더 어려울 수 있다.
2. 결론
내가 점진적으로 모듈화 하고싶은 범위는 다음과 같았다.
- 중복되는 코드만 조금씩 모듈화 시도
- 문제가 없을 시 API 없이 공통으로 사용되는 컴포넌트 로 확장하여 모듈화
- API 통신까지 가능한 컴포넌트로 확장하여 모듈화
- 디자인 시스템 도입될 경우, AD & HP 까지 별도로 스타일을 관리하는 모듈로서 관리.
위에서 공부한 특징과 내가 하고싶은 모듈화를 따져봤을때 모노레포가 적합한가 싶다가도,
에디터와 커머스의 다른 배포주기때문에 독립성에 더 초점을 두기로 했다.
또한 한 레포에서 작은 단위로 공통 프로젝트들로 모듈을 나누기에는 관리할만한 인력이나 시간이 부족했다.
현재 상황에서 관리의 복잡성이 있는 모노레포보다 프로젝트 간 영향을 덜 받을 수 있는 서브모듈이 더 적합해 보였다.
단, 팀원들과 규칙 및 이력관리를 철저히 하고 자주 변경되지 않을 코드부터 시도하는 것으로 결정을 내렸다.
참조
🔗 저장소 안에 저장소 - git submodule
🔗 모노레포 대신 서브모듈 선택 이유
🔗 배포된 서브모듈 적용 에디터 테스트 사이트 :
🔗 배포된 서브모듈 적용 라이브 테스트 사이트 :
