원더월 프론트엔드 모노레포 적용기

안녕하세요. 원더월 프론트엔드 개발자 황호찬입니다.
이번에는 원더월 프론트엔드 팀에서 프로젝트에 모노레포를 도입하게된 배경, 그리고 느낀 장단점들을 간단하게 공유해보려고 합니다.

모노레포란?

먼저 간단하게, 모노레포의 개념만 간단하게 잡고 진행하겠습니다.
모노레포란, 간단하게 둘 이상의 프로젝트를 하나의 저장소에 저장하여 관리하는 코드 관리 방식 입니다. 유사성이 있는 프로젝트들을 하나의 저장소에 저장하여 공통 요소들을 재사용할수 있게 해줍니다.

적용 배경

저희는 기존에 4개의 프로젝트를 멀티레포로 관리하고 있었습니다.
모두 같은 디자인 베이스를 사용하여, 하나의 컴포넌트 디자인을 사용하지만 각각의 코드를 따로 관리하기 때문에 하나의 컴포넌트를 4번씩 작성해야 했으며 프로젝트들이 사용하는 툴도 각각 달라 단순 복사로 해결되는 문제도 아니었습니다.
또한, 저희는 코드리뷰를 깃헙에서 진행하고 있는데 저장소가 분리되어 있으니 리뷰할때마다 다른 저장소를 찾아가고, 어떤 경우는 리뷰가 올라온걸 인지하지 못하고 마지막에 급하게 리뷰를 처리하게 되는 경우도 발생했습니다.

도구 선택

모노레포 도구에는 turborepo, lerna, yarn workspace 등등 여러가지 도구가 있는데 저희는 그중 vercel의 turborepo를 사용하기로 결정했습니다.
그 이유로 저희는 vercel을 통해서 배포를 진행하고 있었고 빠르게 프로젝트가 진행되는 과정속에서 최소한의 설정만으로 빠르게 진행하기 위해서 turborepo를 사용하고자 했습니다.
또한 turborepo의 현재 재공하고 있는 기능이 유용할 뿐만 아니라 지속적인 업데이트가 이루어진다는 것이 장점으로 느껴졌기 때문입니다.
turborepo에 대해서 자세히 알고싶으신분들을 위해 공식 문서 링크를 공유드립니다.

적용

예시 프로젝트를 통해서 모노레포를 적용하는 과정을 간단하게 공유해보려고 합니다.

구조

구조는 크게 apps 디렉토리와 packages 디렉토리로 구분되어 있습니다.
apps 디렉토리는 모노레포에 추가되는 서비스들이 위치하는 디렉토리로 저희 서비스에서는 프롬 스토어 프로젝트가 해당 디렉토리에 포함되어 있습니다.

packages 디렉토리는 apps 디렉토리에서 사용할 공통 요소들이 저장되는 디렉토리로, 디자인 시스템이나 공통된 타입들이 해당 디렉토리에 포함될 수 있습니다.

설정

우선 코드상에서, turbo.json 파일에서 프로젝트에 대한 설정이 가능합니다.
설정도 한눈에 알아볼수 있을수 있도록 간단한데

{
  "$schema": "https://turbo.build/schema.json",
  "globalDependencies": ["**/.env.*local"],
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "cache": true
    }
  }
}

해당 설정을 해준 후에 turbo run build 커맨드를 실행시켜주면 각 apps 디렉토리 하위 각각의 프로젝트에서 build 명령어를 실행시켜줍니다.
그리고 packages에 있는 코드는 아래처럼 디펜던시에 추가할 수 있습니다.
"@packages/components": "workspace:*"

다음으로 vercel에서 모노레포 프로젝트를 설정하는 방식은 다음과 같습니다.

1. 사용하는 언어를 선택하고
2. apps 디렉토리 하위의 경로를 지정해주면

알아서 해당 경로에 있는 프로젝트를 인식하고 빌드 및 배포까지 처리해줍니다.
이때 turbo-ignore 설정을 해줘야 다른 프로젝트의 커밋은 배포를 하지 않습니다.

장, 단점

우선 모노레포 적용 이후에는 확실하게 개발적으로 편리해졌다고 생각합니다.
위에서 언급한 모노레포 적용 배경인 공통 컴포넌트의 사용, 리뷰 및 관심사의 산개를 잡을수 있었고 새로운 프로젝트의 추가도 간단하게 처리할 수 있었습니다.
추가로 이미 vercel을 활용해서 배포를 진행하고 있었다보니 생각보다 훨씬 간단하게 처리할 수 있었습니다.

다만 여러 프로젝트가 합쳐짐으로 인해, 커밋과 PR이 어떤 프로젝트를 위한건지 알기 힘들었고 이런 부분은 PR, 커밋 메세지의 prefix로 각 프로젝트의 키를 붙이기로 팀 컨벤션을 정해서 문제를 해결할 수 있었습니다.
그리고 여러 프로젝트가 하나의 배포 스레드에서 돌아가기 때문에, 하나의 스프린트에서 복수의 프로젝트가 배포될때면 병렬적으로 동시에 배포되는게 아니라 하나의 배포가 끝나는걸 기다려야 하는 이슈가 있습니다. 이는 vercel의 기능으로 해결할수 있지만, 동시에 배포가 허용되는 숫자 하나하나가 비용이기도 하고 실제 배포 시간이 그리 길지 않아 현재는 적용하지 않고 있습니다.

+) 저희는 각 프로젝트마다 React.js, Next.js, Qwik, Astro 등 사용하는 언어, 프레임워크가 달라 타입이나 설정은 공유하여 재사용하기 편했지만 사실 공용 컴포넌트를 사용하는데에는 불편함이 있었습니다.
하지만 저희는 pandacss를 사용하여 레시피를 공유하고 각 언어 및 프레임워크에 맞춰 기능을 추가하는 식으로 개발을 하여 더욱 편하게 사용할 수 있었다고 생각합니다.
pandacss 관련된 내용들은 아래 링크로 추가해두었습니다.

• 공식 문서 링크
• PandaCSS와 함께 CSS-in-JS의 미래로

마무리

오늘은 간단하게 프론트엔드 팀에서 모노레포를 적용한 경험과 예시를 통한 설정 방식을 공유해보았습니다.
모노레포는 분명히 장점이 있고 저희처럼 공통된 요소를 갖는 여러 프로젝트를 관리하는 경우 유용한 방식이지만 반대로, 반드시 사용해야 하는것은 아니며 오히려 멀티레포로 사용하는 경우가 더 좋을 때도 있습니다.
예를 들어, 저희 프로젝트중 원더월 웹 프로젝트는 프롬 서비스와는 다른 도메인, 컴포넌트, 배포 프로세스를 사용하기 때문에 저희 모노레포 서비스에 포함되어 있지 않고 별도의 저장소로 분리되어 있습니다.

여러분이 사용하는 프로젝트에 적합한 개발 방식을 선택하고, 모노레포가 여러분의 선택이 되었을 때 이 글이 조금이나마 도움이 되었으면 좋겠다 생각하며 글을 마치려고 합니다.
감사합니다.