프론트엔드 모노레포

모노레포는 여러 프로젝트나 라이브러리를 하나의 저장소(Repository)에서 관리하는 방식을 말해요. 여러 프로젝트에서 공통으로 사용하는 코드를 좀 더 쉽게 관리할 수 있다는 장점이 있죠. 하지만 이 방식에도 단점이 있기 때문에, 팀의 방향성과 상황에 맞는 선택이 중요하답니다.

저희 사내 프론트엔드 팀은 서비스의 수가 많지는 않았지만, 프로젝트별로 오너십을 명확히 하기 위해 모노레포 방식을 도입하게 되었어요.

처음엔 괜찮았지만, 어두운 면이 다가왔어요

처음엔 동일한 도메인을 여러 서버로 나눠 관리하게 되면서, 각 팀원이 맡을 부분이 명확히 구분돼서 좋았어요. 회사의 방향성과도 잘 맞았고요. 하지만 시간이 지나면서 아쉬운 점이 서서히 드러나기 시작했어요.

특히 여러 서비스가 동시에 변경되는 경우 또는 공용 코드가 변경되는 경우, 빌드 시스템이 병목 현상을 겪었어요. 기존에는 로컬 환경에서 빌드와 배포를 진행했는데, 한 대의 컴퓨터에서 모든 서비스를 빌드하다 보니 CPU와 메모리 사용량이 너무 높아져서 다른 작업에 큰 지장을 주더라고요. 심지어는 멈추기까지 했어요.

사실, 이런 상황은 사전에 충분히 고민하지 못했던 탓이 컸던 것 같아요. 기존에는 하나의 서비스만 빌드하다 보니 다른 작업을 병행해도 문제없었거든요. 여러 서비스를 동시에 빌드할 때의 문제를 미처 생각하지 못했답니다.

CI/CD 환경으로 전환하기로 했어요

이 문제를 해결하려면 로컬 환경에서 진행하던 CI/CD 프로세스를 외부 플랫폼이나 Kubernetes 클러스터로 옮길 필요가 있었어요. 두 가지 방식을 검토하면서 각각의 장단점을 정리해 보았어요.

1. Kubernetes 클러스터

장점

• 빌드, 테스트, 배포뿐 아니라 복잡한 프로세스도 커스터마이징하기 좋아요.
• 외부 플랫폼을 사용하지 않으니 보안 면에서 더 안전해요.
• 클러스터 리소스를 자유롭게 관리할 수 있어요.

단점

• 처음 설정할 때 많은 리소스와 시간이 필요해요.
• 디테일한 관리를 위해 사전에 관련 지식을 많이 익혀야 해요.

2. 외부 CI/CD 플랫폼

장점

• 운영 부담이 줄어들고 다른 개발 업무에 집중할 수 있어요.
• 대시보드 같은 시각화 도구로 관리가 쉬워요.
• 다양한 플러그인과 서드파티 서비스를 쉽게 활용할 수 있어요.

단점

• 원하는 대로 완벽히 커스터마이징하기는 어려워요.
• 데이터 보안 문제가 생길 가능성도 있어요.

두 가지 방법을 테스트해 봤어요

쉽게 결론을 내리긴 어려워서, 두 방법을 간단히 테스트해 보기로 했어요. 테스트 결과 Kubernetes 클러스터는 자유도가 높은 대신 관리와 설정에 너무 많은 리소스가 들어갔어요.

예를 들어, 외부 CI/CD 플랫폼은 빌드 단계마다 캐싱을 활용하기 쉬웠는데, Kubernetes 클러스터에서는 EBS 같은 외부 저장소를 사용해야 해서, 여러 머신이 동시에 접근하는 상황 등을 고려해야 했어요. 설정이 복잡하고 손이 많이 가더라고요.

반면, 외부 CI/CD 플랫폼은 플러그인과 서드파티 서비스를 통해 많은 작업을 간단히 해결할 수 있었고, 결과적으로 개발 리소스를 많이 줄일 수 있었어요. 그래서 저희는 외부 CI/CD 플랫폼을 선택하고, 이를 단계적으로 적용하기로 했답니다.

전환 후 달라진 점

• 캐싱 문제 해결 기존에는 ARM 환경(개인 노트북)에서 빌드를 진행했어요. 배포 환경에 맞추기 위해 QEMU 가상머신을 사용했는데, QEMU를 이용하면 Native 환경보다 빌드 시간이 더 오래 걸리는 문제가 있었거든요. 😢

  변경 후에는 캐싱 처리가 가능해지면서 빌드 시간이 약 2분 정도 단축되었답니다.

• 프로세스 분리

  각 서비스마다 별도의 머신에서 빌드가 실행되면서, 항상 일정한 빌드 시간이 보장되었어요.

후기와 정리

이번 글에서는 모노레포를 운영하면서 겪은 문제들과 이를 해결하기 위한 과정들을 공유해 보았어요. 돌이켜보면 미리 예상하고 준비할 수 있었던 문제들이었기에 스스로에게 조금 아쉬움이 남네요. 하지만 같은 고민을 하시는 분들께 이 글이 도움이 되었으면 좋겠습니다. 😊