이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
모노레포를 구성한 경험에서 가장 큰 장점은 공통 컴포넌트와 타입 정의를 한 곳에서 관리할 수 있다는 점이었습니다. 인턴 팀에서 Turborepo 기반으로 세 개의 서비스를 묶었는데, 공유 UI 라이브러리 변경이 즉시 모든 앱에 반영되어 중복 코드가 줄었습니다.
반면 단점도 분명했습니다. 빌드 파이프라인 설정이 복잡해졌고, 특히 CI/CD에서 변경된 패키지만 골라 빌드하는 변경 감지 로직을 직접 구성해야 했습니다. 처음에는 전체 빌드가 매번 돌아가면서 파이프라인 시간이 오히려 길어지는 문제가 있었습니다.
결국 팀에서는 서비스 간 코드 공유 비율이 높을 때 모노레포가 효과적이고, 독립적으로 배포 주기가 다른 서비스끼리는 멀티레포가 더 단순하다는 결론을 내렸습니다. 현재 프로젝트 성격에 맞는 선택이 중요하다고 생각합니다.
모노레포에서 타입스크립트 타입 정의를 공유했을 때 '이래서 쓰는구나'를 실감했습니다. API 응답 타입을 프론트와 BFF 서버에서 각자 정의하다 보면 타입이 어느 순간 어긋나는 문제가 생겼는데, 모노레포로 묶고 packages/types를 공유 패키지로 분리하니 타입 불일치로 인한 런타임 오류가 크게 줄었습니다. 단점은 CI에서 드러났습니다. 처음에는 모든 패키지를 매번 빌드해서 파이프라인 시간이 두 배로 늘었습니다.
Turborepo의 원격 캐싱과 변경된 패키지만 골라 빌드하는 `--filter` 설정을 구성한 뒤에야 빌드 시간이 원래 수준으로 돌아왔습니다. 모노레포 도구 없이 모노레포를 운영하면 단점만 남는다는 것을 이 경험에서 배웠습니다.
두 번째 프로젝트에서는 모노레포로 시작했다가 중간에 멀티레포로 분리한 경험이 있습니다. 세 개의 서비스가 있었는데 하나는 매일 배포, 다른 하나는 주 1회, 나머지는 분기 1회였습니다. 모노레포로 묶으니 자주 배포하는 서비스의 변경이 다른 서비스 CI에도 영향을 줘서, 분기 1회 서비스 팀이 불필요한 빌드를 매번 기다리는 상황이 생겼습니다. 공유 코드도 사실상 거의 없었습니다. 서비스를 분리했더니 각 팀이 자기 파이프라인만 신경 쓰면 됐고 배포 속도도 독립적으로 조절할 수 있었습니다.
모노레포는 코드 공유 비율이 높고 배포 주기가 비슷한 서비스에 적합하다는 것을 직접 겪고 나서야 이해했습니다. 먼저 고민해야 할 것은 '공유하는 것이 무엇인가'라는 질문입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 부스터즈 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.