Monorepo Arhitecture
Arhitecture
아키텍처는 모두가 이해해야 하는 커다란 그림이다.
모노레포 사용을 위해 이해해야하는 Point
구조에 대한 이해: 계층, 어떤 코드가 어디 있는지, 모노레포 구조에 대한 이해
발전 방향에 대한 이해: 앞으로 어떻게 구조가 발전하고 코드를 응집할 것인지에 대한 이해
협업 방향에 대한 이해: 타 직군도 FE와 어떻게 일할 수 있는지 파악할 수 있어야 한다.
#1 장기적인 목표 구조 작성
처음으로 할 것은 장기적인 목표는 아니더라도, 우리가 일차적으로 달성할 장기적인 목표를 구축하는 것
공통의 코드 배치와 레이아웃/상태/비즈니스 등의 코드를 허용하는 모노레포의 구조 제작
#2. 장기적인 목표 잘게 나누기
모노레포 환경 구축
현재 코드를 온전히 모노레포로 옮기기
정상적으로 QA 진행 후 배포
공통 코드 분리
공통 코드 적용 및 QA 배포
공통 코드를 관리하기 위한 체계 수립 및 적용
아키텍처를 만들고 적용하기까지
아키텍처는 만들고 고인하기 쉽지만, 설득 후 실제 개발이 진행되게 만드는 것은 어렵다.
타당성을 부여하기 위해 실 적용하기 위한 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 영역에 코드 절감
API를 대응하는 별도의 레이어를 구축
Apps에 레벨이 아닌 별도 API 레벨을 만들어서 Library를 연결하고 App은 캡슐화하여 코드들에 영향을 받지 않게끔 하고 App에 대한 Server State Managment로 비즈니스를 처리하는 구조
각 프로덕트의 서버 별 코드를 줄이기 위한 고민
카운터 파트가 한정되어 있으므로 API의 응답 구조체는 비슷해진다.
이를 해결하기 위해 서버 상태를 재사용할 수 있는 구조가 필요해짐
공통 API 모듈, Interface 확장등을 사용하게 됨
전체 프로젝트 공통 에러처리 필요
이를 위한 API를 위한 앞 단의 레이어 혹은 Common 레이어에 공통의 코드를 관리하는 전략 등이 필요하다.
협업 프로세스의 변화
코드 작업, 공유 프로세스의 변화
Polyrepo는 프로젝트 단위의 영향도만 파악하면 된다.
Monorepo는 공통 작업 등의 영역이 추가되므로 더 복잡한 프로세스가 생길 수 있다.
오히려 프로덕트는 작은데 적용하면 영향범위 파악으로 인해 리소스가 효율적으로 쓰이지 못할 수 있다.
코드 리뷰 프로세스 고도화의 필요성
Polyrepo: 하나의 코드가 곧 운영하는 프로덕트이므로 자동화의 필요성이 적을 수 있음
Monorepo: 코드리뷰어 매칭, 리뷰시 자동 합병, 합병시 자동 배포 등의 자동화 필요성 존재
많은 프로덕트를 운영하면서 때에 맞춰 각 프로덕트를 배포하는 것은 위험성과 동시에 운영의 어려움이 존재하기 때문
업무 진행 방식의 변화: 문서화의 중요성 부각
Monorepo로 변화하면서 히스토리의 중요성은 "매우" 커진다.
하나의 작업이 수많은 프로덕트에 영향을 끼칠 수 있음,
이전에 어떤 선택이 어떤 결과를 장기적으로 불러올지 모르므로 히스토리를 통해 이전의 선택에 대해서 이해할 수 있도록 제공이 되어야 한다.
대기업에서 문서화를 하는 이유와 동일, 문서를 잘 작성해야함
Last updated