PARA/03_Resources/R006_잡다한_것들/글쓰기/모노레포 절망편, 14개 레포로 부활하기까지 걸린 1년.md

모노레포 절망편, 14개 레포로 부활하기까지 걸린 1년

2025년 8월 23일

개요

나는 플렉스의 김종혁이다
- 강의 할 생각에 신난다
플랙스는 일주일 정기배포를 없앴다
14개의 모노레포로 쪼갰다
- 참고로 올해 6월까지였다
플렉스는 올인원 플랫폼을 지향한다
- 플렉스는 강한 의존을 가진다
플렉스는 규모가 커졌다
- 다른 도메인과의 연결이 중요하다
- 유틸은 어느 패키지든 가져다 쓸 수 있었다
- 모노레포를 도입해야 한다고 생각했다
  - 터보레포를 썼다
  - 제품의 크기가 커지니까 의존성이 엄청나게 복잡해졌다.
  - 변경될때마다 의존성 때문에 전체배포가 필요했다.
    - 그래프 그리는 툴이 에러가 날 정도였다.
    - 한날 한시에 배포하고 모두가 모니터링 하는 식이었다
      - 모노레포가 망했다.
- 정기배포를 그만하고 싶었다
  - 이때문에 모노레포를 해체하게 됐다.
    - 폴리레포를 사용하게 됐다
      - 코드 파편화, 업무 공유 어려움, 원자적 커밋 불가능 <- 해결 가능함
      - 레포지토리 안정성, 정기배포 <- 해결하기 어려움
    - 빌드, 버저닝, 변경을 분류했다.
    - 각각의 패키지를 개별 레포지토리로 분리시켰다.
    - 결국 모노레포는 툴링으로 경계를 명확하게 만들어야 올바르게 동작한다
      - 폴리레포는 자연스럽게 경계가 만들어진다
경계 없이 코드를 공유하지 말것
- 경계가 없으면 코드는 엄청나게 확산된다
  - 제품 안정성이 떨어진다
- 특정 함수를 export해서 쓰다가 해당 함수를 변경했을때 발생하는 사이드이펙트
- 개발자는 일반적으로 빠르게 작업할 수 있게 사용할 수 있는 코드를 모두 사용하게 된다.
  - 쓰지말자 -> 말 안들음
- 결론적으로 잘 정의된 관계가 중요하다
코드베이스를 복잡한 상태로 방치하면 안됨
- 복잡한 코드베이스는 개발자들이 코드 변경이 두려워하게 만든다
- 안정된 환경에서는 모두가 안정을 유지하려고하지만 불안정안 환경은 모두가 구조를 지키지 않는다
  - 공유하는 문화가 사라지고 숨기는 문화가 생김
  - 공유하려고 만든게 공유가 안됨
  - 어디에 뭐가 있는지 모름
  - 모듈 1~2개 공유하기 위해 패키지를 자꾸 새로 만듬
- 우린 고구마라는걸 만듬
  - 의존성을 고구마 줄기처럼 만들기때문
  - 구문분석을 해주는 패키지
  - 패키지 개수가 줄어드는것 만으로도 전체 패키지 빌드 성능 38% 개선됨.
  - 그러나 패키지는 많고 의존성은 여전히 복잡함
  - 버저닝을 통해 복잡한 의존관계를 정리함
    - 같은 버전에서만 각 패키지들이 상호착용 할 수 있도록 함.
    - 의존 트리의 깊이를 줄여나가기 위한 노력이었음
    - 버저닝 도입으로 3개의 깊이를 가짐
      - 패키지-> 디자인시스템 -> 서비스
  - 결과적으로 인지부하를 줄일 수 있었음.
공유 모듈을 정의하고 알맞게 다루자
- 심플한 기능을 가졌던 컴포넌트가 복잡해지게되면 뭔지 모를 공유모듈이 됨
  - 뭔지 몰라서 안씀
- 공유 모듈이 될 수 있는 것
  - 제품 전체에서 하나여야만 하는 코드
  - 공용화가 안되면 생산성이 확 떨어지는 코드
  - 이 외의 코드는 각 사용처에서 내재화시켜야함
- 공유 모듈 처리 의사결정 트리
  - 나중에 누가 올려주겠지
- 코드 고립 상태를 만들기 위해서는 못들음
정기배포 그만두기 위해 작업 계획서 작성
- 코드 고립 작업 대상을 리스트업함
  - 이 또한 의사결정 트리를 만듬
앞으로 할일
- 스쿼드가 더욱 자유롭게 개발할 수 있도록 지원
- AI를 활용할 수 있도록 명세와 문서 작성
듣다보니 저렇게까지 복잡하게 해야하나 싶음.
- 일을 굉장히 어렵게 하는 느낌
- 그러나 어려운 일을 어떻게든 기술적으로 해결했다는 점이 멋있다

모노레포 도입 초기의 경험은 [[KnowledgeBase/Blog/모노레포를 실무에 적용한 뒤 한달. 후기]]에서 확인할 수 있다.

개요

댓글