Monorepo Arhitecture

Arhitecture

아키텍처는 모두가 이해해야 하는 커다란 그림이다.

모노레포 사용을 위해 이해해야하는 Point

• 구조에 대한 이해: 계층, 어떤 코드가 어디 있는지, 모노레포 구조에 대한 이해

• 발전 방향에 대한 이해: 앞으로 어떻게 구조가 발전하고 코드를 응집할 것인지에 대한 이해

• 협업 방향에 대한 이해: 타 직군도 FE와 어떻게 일할 수 있는지 파악할 수 있어야 한다.

#1 장기적인 목표 구조 작성

• 처음으로 할 것은 장기적인 목표는 아니더라도, 우리가 일차적으로 달성할 장기적인 목표를 구축하는 것

• 공통의 코드 배치와 레이아웃/상태/비즈니스 등의 코드를 허용하는 모노레포의 구조 제작

#2. 장기적인 목표 잘게 나누기

1. 모노레포 환경 구축

2. 현재 코드를 온전히 모노레포로 옮기기

3. 정상적으로 QA 진행 후 배포

4. 공통 코드 분리

5. 공통 코드 적용 및 QA 배포

6. 공통 코드를 관리하기 위한 체계 수립 및 적용

아키텍처를 만들고 적용하기까지

• 아키텍처는 만들고 고인하기 쉽지만, 설득 후 실제 개발이 진행되게 만드는 것은 어렵다.

  • 타당성을 부여하기 위해 실 적용하기 위한 phase를 나누고, 최대한 그림으로 설득

• 작은 것부터 시작하여 실패 확률이 낮은 성공할 수 있는 것들에 대해서 최대한 많이 쌓기

  • 신뢰를 만들기 위한 방법

• 함께 다른 작업을 같이 하지 않기

  • 분리는 분리대로, 적용은 적용만

아키텍처에 필수적으로 포함되면 좋을 것들

• 저장소 전체의 폴더 구조 그리고 프로젝트 별 폴더 구조

• 각 프로젝트 별 인프라 구축, 작업 담당자

• 전체 공통의 코드를 나누는 기준, 올리기 위한 승인 프로세스

• 브랜치 전략에 따른 개발, 운영 환경

• 프로젝트 별 카운터 파트

결론

• 모노레포 전환을 통해 더 복합적인 상황을 대응할 수 있는 구조로 나아간다.

• 여러 도메인의 프로덕트를 코드 저장소 하나로 합병하면서 팀원이 하나의 방향성을 인지가능

• 일괄적인 협업 팀 기반의 도메인 분리 등을 통해 업무 방식이 일원화 될 수 있음

• 코드를 작성할 때 물리적으로 코드들이 분리되어 있지 않으므로 어느정도 규격화된 코드를 작성할 수 있음

• 프로젝트 단위로 설정된 CI/CD, 자동화, 파이프라인 등 일원화 가능

• 코드 전체 단위의 테스트 커버리지, 인프라, 설정 상황 등을 한눈에 파악 가능

폴더 스트럭처의 변화

단계별 코드의 변화

• Phase1은 모노레포에 그대로 플젝 레벨의 코드를 이식하는 것이 키 포인트

  • Lint등은 중앙화 시킴

• Phase2는 이식된 각 프로젝트 레벨의 공통 코드를 뽑아내는 것

  • 이 때 프로젝트별 코드의 용량이 매우 줄어든다.

• Phase3는 공통 코드를 라이브러리화 시켜 운영하는 것

  • 공통 코드를 유지보수하기 위한 프로세스 및 파이프라인이 구축되어야 한다.

컴포넌트 레벨의 변화

• Library Layer: 앞으로 변할 가능성이 거의 없고 버저닝으로 버전 관리가 잘 되는 것들

• Common Layer: 공통으로 만들어진 코드를 유지보수하는 레이어

  • 아직 Product들에 여러군데 쓰이지만 쓰이는 것들이 조금 staging이 된것

  • 거의 비즈니스 로직이 없고 재사용이 높은 것

• 각 프로젝트는 비즈니스 컴포넌트를 들고 있으며, 프로젝트별로 공통 컴포넌트 또한 포함한다.

서버 상태를 관리하는 공통 코드의 필요성 대두

각 프로덕트 별 마이크로서비스에 대응하는 현상

• 규모가 커질수록 비슷해지는 API 스펙과 비슷한 로직이 생기게 됨

• API 코드를 받아 페이지 단위로 서버 상태를 관리하여, 전역 상태와 다른 상태 관리 쳬게가 필요해짐

• 이를 해결하기 위해 Common Layer에 API를 도와주는 헬퍼 코드들을 추가하게 된다.

• 모노레포에서 워크스페이스 프로토콜이라고 워크스페이스 단위로 모듈을 만들어서 공유할 수 있는 기능이 있다.

  • Model Layer: API Code들의 공통적인 부분 (모델 값, 비즈니스 코드들을 해결할 수 있는 방안 등)

  • Server State Management Tools: Server State Managment 영역에 코드 절감

라이브러리는 비즈니스 코드들이 100% 문제 없고 모노레포 바깥으로 빼도 독자적으로 살수 있는 레벨이어야 라이브러리에 등재됨

API를 대응하는 별도의 레이어를 구축

• Apps에 레벨이 아닌 별도 API 레벨을 만들어서 Library를 연결하고 App은 캡슐화하여 코드들에 영향을 받지 않게끔 하고 App에 대한 Server State Managment로 비즈니스를 처리하는 구조

각 프로덕트의 서버 별 코드를 줄이기 위한 고민

• 카운터 파트가 한정되어 있으므로 API의 응답 구조체는 비슷해진다.

• 이를 해결하기 위해 서버 상태를 재사용할 수 있는 구조가 필요해짐

  • 공통 API 모듈, Interface 확장등을 사용하게 됨

  • 전체 프로젝트 공통 에러처리 필요

• 이를 위한 API를 위한 앞 단의 레이어 혹은 Common 레이어에 공통의 코드를 관리하는 전략 등이 필요하다.

협업 프로세스의 변화

코드 작업, 공유 프로세스의 변화

• Polyrepo는 프로젝트 단위의 영향도만 파악하면 된다.

• Monorepo는 공통 작업 등의 영역이 추가되므로 더 복잡한 프로세스가 생길 수 있다.

  • 오히려 프로덕트는 작은데 적용하면 영향범위 파악으로 인해 리소스가 효율적으로 쓰이지 못할 수 있다.

코드 리뷰 프로세스 고도화의 필요성

• Polyrepo: 하나의 코드가 곧 운영하는 프로덕트이므로 자동화의 필요성이 적을 수 있음

• Monorepo: 코드리뷰어 매칭, 리뷰시 자동 합병, 합병시 자동 배포 등의 자동화 필요성 존재

  • 많은 프로덕트를 운영하면서 때에 맞춰 각 프로덕트를 배포하는 것은 위험성과 동시에 운영의 어려움이 존재하기 때문

업무 진행 방식의 변화: 문서화의 중요성 부각

• Monorepo로 변화하면서 히스토리의 중요성은 "매우" 커진다.

  • 하나의 작업이 수많은 프로덕트에 영향을 끼칠 수 있음,

  • 이전에 어떤 선택이 어떤 결과를 장기적으로 불러올지 모르므로 히스토리를 통해 이전의 선택에 대해서 이해할 수 있도록 제공이 되어야 한다.

  • 대기업에서 문서화를 하는 이유와 동일, 문서를 잘 작성해야함