모노레포 운영과 트러블슈팅

changeOrderStatus, autoSignInCheckbox 등은 적절한 프로덕트 단위의 공통 컴포넌트인가?
- No, 프로덕트 단위가 아닌 도메인 단위이다.
Chart, Input, Search, Slider 등 공통의 이름을 가진 것들이 정말 공통이 맞는가?
- No, 비즈니스 및 페이지 단위의 예외처리가 많이 들어가 있는 페이지 단위의 코드이다.
- ~~Input 등의 명확하게 네이밍이 설정이 되어있어야 적합하다.

프로덕트 단위로 공통의 코드를 제공하는 것이 한 군데 밖에 없다면 더 잘게 쪼개야 한다.

프로덕트 내의 공통의 코드는 원래대로 공통의 역할을 하기도 하지만 코드 응집 및 긴 코드 은닉용으로도 사용된다.
다양한 용도로 사용되는 공통의 코드를 더 분산시킬만한 아키텍처를 사용하여 한 군데에 응집되는걸 막아야 한다.
도메인에 의존적인 컴포넌트가 아닌 도메인을 공통으로 만들어 줄 수 있는 컴포넌트를 만들어야 한다.
- 컴포넌트를 잘 만들었단 소리를 들을려면 컴포넌트를 레이아웃과 비즈니스를 분리하여 레이아웃을 공통으로 쓰일 수 있도록 만들어야 한다.
응집되는 걸 막기 위한 방안
- 첫 번째: 컴포넌트는 Atomic Design을 쓰거나 페이지 별로 컴포넌트 폴더를 추가할 수 있다.
  - 컴포넌트 내부에서 쪼개거나, 컴포넌트 위에서 폴더링으로 쪼개거나
- 두 번째: hooks, utils 등도 페이지, 도메인 별로 폴더를 추가한다.
  - 공통의 코드를 단계별로 확장시킬 수 있는 방안을 고민
- 세 번째: 추가적으로 각 컴포넌트들을 내릴지 올릴지를 결정하여 지속적으로 위치를 변경시킨다.
  - 올린다는건 공통으로 쓰이는 더 영향력있는 컴포넌트가 된다.

컴포넌트가 잘 만들어졌다. 또는 못만들어졌다가 중요한게 아니다.

비즈니스를 빠르게 작업하기 위한 과거의 히스토리를 생각하고 과거의 코드들의 Respect를 갖고 있어야 한다.

과거 코드들의 히스토리에서 더 좋은 방향으로 나아가는 것들을 제안해야 한다.

공통 코드로 올려보낼 수록 더 많은 사람이 존재를 알게하기 위해 공유 프로세스를 거쳐야 한다.

DX 개선의 필요성 대두

Developer Experience 모노레포를 운영하다보면 DX의 한계에 다다를 시점이 다가온다.

속도, 이해도, 관리 세 가지 측면에서 터보레포 프레임워크를 사용해야 한다.
지금까지 모노레포를 단순히 workspace 개념으로만 사용됨
- 어느 일정 수준이되면 수많은 라이브러리 빌드 및 런타임 사용으로 vs code나 툴의 메모리 초과로 shutdown 되는 현상이 생긴다.
- 더불어 실행 속도가 저하되면, 용량 자체도 무거워지는 경우가 생김
이러한 부분은 개발 속도를 저하시키며, 빠른 비즈니스 개발을 하고자 모노레포를 썻던 이유를 퇴색시킨다.

CRA가 표준에서 없어진 이상, Next를 사용하는 경우가 많을 것으로 판단

turbo.json

첫 번째: TypeCheck, lint stage를 거쳐서 코드상의 문제를 체크한다.
두 번째: common과 apis를 병렬 빌드를 진행한다.
- 원래되로라면 &&로 진행되어 각 각 5분씩 걸린다면(병렬X) 10분이 걸리게 되어 속도면에서 손해가 된다. -> 병렬 빌드로 최적화 가능
세 번쨰: web 빌드를 하고 실제 프로덕션 배포를 진행한다.