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

4년에 가까운 시간동안 flex 웹 제품을 지탱해오던 모노레포는 제품과 팀의 규모가 꾸준히 커지며 여러 문제에 맞닥뜨렸습니다. 개발 속도는 느려지고 복잡한 의존관계로 인해 제품 안정성이 위협받았습니다.

flex 웹 클라이언트 플랫폼 팀은 제품 개발과 릴리즈를 멈추지 않으면서, 1년간 하나의 레포지토리를 14개의 개별 레포지토리로 분리했습니다. 그 과정에서 안정적이고 빠른 마이그레이션 전략을 만들고, 팀과 제품 규모에 맞는 코드베이스 전략이 무엇인지 깊이 고민했습니다. 모노레포가 어떻게 절망이 되었는지, 그리고 팀이 그것을 극복하기 위해 어떤 기술적·조직적 판단을 내렸는지 공유합니다.

- 플렉스팀이 풀고 있는 문제와 팀에 관심이 있으시다면 플렉스팀 Product Engineer(FE) 채용 페이지를 참고해주세요.
- 제 블로그에도 놀러오세요!

Transcript

1. 모노레포 절망편, 14개의 레포로 부활하기까지 걸린 1년 김종혁 \ 플렉스팀
2. 모노레포를 14개의 폴리레포로 쪼갰다. 모든 제품이 일주일에 한 번 모두 나가는 정기배포를 없앴다. (2024.02 ~ 2025.06)
3. 팀과 제품에 맞는 적정 코드베이스를 만들기 위해 꼭 알아야 하는 3가지
4. 저희도 알기 싫었습니다
13. 패키지 단위의 태스크 실행 및 의존성 추적 build build build build build workspaces:* 로 모노레포 내 패키지들을 연결
19. 한날 한시에 prod로 내보낸다 󰳕󰠁최 선을 다해 지켜본다
20. 한날 한시에 prod로 내보낸다 󰳕󰠁최 선을 다해 지켜본다
21. 너무 많은 사람이 건드려서 뭔가 이상해져버린 공용 코드 서로의 변경이 서로의 코드를 터트리는 개발자들 다음주 정기배포 당번 (하기싫음) 거대 변경 PR 언제나 불타는 레포지토리
22. 정기배포 그만두기 프로젝트 - 2024년 2월 시작 - 정기배포 그만두기가 목표 - 모노레포 해체 선택 - 패키지와 애플리케이션을 개별 레포지토리로 분리
24. 빌드, 버저닝, 변경 통제
25. 빌드, 버저닝, 변경 통제 개별 레포지토리 코드 고립
27. 🥳🥳🥳
28. 3년 전...
29. 팀과 제품에 맞는 적정 코드베이스를 만들기 위해 꼭 알아야 하는 3가지
30. 1. 경계 없이 코드를 공유하지 말 것 사실 모노레포냐 폴리레포냐가 가장 중요한 건 아님
36. 가장 빠르게 작업하기 위해, 사용할 수 있는 코드를 모두 사용한다. (그리고 그래야 한다) 오 이거 쓰면 더 빨리 끝나고 덜 귀찮을듯!!!!!
37. 이거 이제 쓰지 마세요 -> 말 뿐이라면 공허하다.
38. “여러 프로젝트가 포함된 레포지토리에서 코드는 “같은 곳에 위치(code colocation)"하지만, 이들 사이에 명확하게 정의된 관계(well defined relationship)가 없다면 우리는 그것을 모노레포라고 부르지 않을 것입니다.” - Nx Team(monorepo.tools)
39. 모노레포를 버린 이유 모노레포 해체의 장점 모노레포 해체의 단점
40. 모노레포를 버린 이유 레포지토리 경계 안정성 정기배포 빨리 끝내기 원자적 커밋 불가능 코드 파편화 업무 공유 힘들어짐 감당할 수 있다. 경계는 필요하다.
41. 모노레포 폴리레포 툴링으로 경계 만들어야 함 자연스럽게 경계가 만들어짐
42. Why Google Stores Billions of Lines of Code in a Single Repository(2016): Piper(사내 버전관리 시스템), CitC(클라우드 기반 워크스페이스), CodeSearch(대규모 코드 검색 도구), Rosie(대규모 코드 변경 자동화 도구), Refaster(패턴 기반 리팩토링 도구), ClangMR(코드 자동 변환 도구)...
43. 2. 코드베이스를 복잡한 상태로 방치하지 말 것 사람이 인지할 수 있는 의존성, 버전의 개수는 한계가 있다.
44. 패키지 개수가 너무 많다 의존성이 인지 범위를 넘어간다 변경 추적이 불가능하다 알아야 하는 코드가 많다 코드 변경이 두렵다 😱 방치된+복잡한 코드베이스
45. 방치된+복잡한 코드베이스 관리된+단순한 코드베이스
46. 이 패키지들이 정말 다 필요했을까? - 어디에 뭐가 있는지도 모름 - 공유하려고 만들었는데 공유되지 않음 - 모듈 1~2개 공유하기 위해 패키지를 자꾸 새로 만듬 󰢄󰢃
47. -> 정리 가능
48. 고구마 Analyze
49. 고구마 Workflow
50. 고구마의 효능 패키지 개수가 줄어드는것 만으로도, 전체 패키지 빌드 성능 38% 개선 CI 성능 개선
51. 그래도 패키지는 많고 의존성은 여전히 복잡하다
52. 퇴사할때까지 의존성만 뜯어도 못하지 않을까? 🫠🫠 🫠
54. 레포지토리별로 버저닝 (통 버저닝)된 패키지의 버전으로 소비
55. 의존성 설치, CI 과정에서 버전 정합성 안 맞으면 에러 발생
56. 패키지 레이어링 - 코드베이스 전체에 단순함을 가져옴 - 의존 할 수 있는/없는 관계를 최초로 정의
57. AS-IS
58. AS-IS 1 2 3 4 5 6
59. TO-BE(통 버저닝) 1 2 3
60. 원래 알아야 했던 것 인지 부하는 꾸준히, 계속해서 관리되어야 한다. 몰아서 하면 괴롭다. 이제 알아야 하는 것 모노레포 위에서의 복잡한 패키지 의존관계 너무 많은 패키지들에 무슨 코드가 있는지 패키지들의 단일 버전 내 앱이 사용하는 패키지들
61. 3. 공유 모듈을 정의하고 알맞게 다룰 것
62. 뭔지 모를 공유 모듈 뭔지 모를 것이 되어서 사용률이 떨어짐
63. 끌고 들어오는 의존성 취약성 증가
64. 공유 모듈이 될 수 있는 것은 1) 제품 전체에서 하나여야만 하는 코드 2) 공용화가 안 되면 개발 생산성이 급격히 떨어지는 코드
65. 공유 모듈이 될 수 있는 것은 1) 제품 전체에서 하나여야만 하는 코드 2) 공용화가 안 되면 개발 생산성이 급격히 떨어지는 코드 이 외 코드들은 과감하게 중복, 각 사용처로 내재화!
66. 이 원칙으로 공용 레이어 패키지의 의미를 정립 디자인 일관성을 보장하기 위한 디자인 시스템 널리 쓰이는 유틸성 함수, 기반 도구, 프레임워크 일관성이 중요한 비즈니스 로직 및 이를 포함하는 UI
67. 공유 모듈 처리 의사결정 트리 공유 모듈 레포지토리로 가는 것 최소한으로 디자인 명세 있는가? 변경될 가능성이 있는가? 코드를 중복시키고 의존성을 끊음
68. 애플리케이션 코드고립
69. 지난한 코드 변경
70. 작업 계획서
71. 작업 계획서 > 코드 고립 작업 대상 구현체
72. 작업 계획서 > 코드 고립 작업 대상 구현체
73. 작업 계획서 > 코드 고립 작업 대상 구현체 > 구현체 상세
74. 정리 팀과 제품에 맞는 적정 코드베이스를 만들기 위해 알아야 하는 3가지 3 - 공유 모듈을 정의하고 알맞게 다룰 것 2 - 코드베이스를 복잡한 상태로 방치하지 말 것 1 - 경계없이 코드를 공유하지 말 것 -> 모노레포든 폴리레포든 코드사이에 적절한 경계가 필요하다. -> 코드베이스를 단순하게 유지하고 인지 부하를 관리해야 한다. -> 공유할 가치가 없는 모듈들이 코드베이스를 취약하게 만든다.
75. 앞으로의 계획 - 규제 완화 및 스쿼드가 더욱 자유롭게 개발할 수 있도록 지원 - 공용 모듈에 대한 명세와 문서 만들어 AI 개발 도구 지원
76. 이 프로젝트는 팀(WCP)을 정의했다 시스템에 의문을 제기한다 동료를 성심껏 돕는다 궂은 일을 도맡는다 인내심을 바탕으로 전진한다
77. 저희가 궂은 일 다 할테니 오셔서 꿀잼 개발만 하셔요! 이게???재밌어 보인다고요? 당신을 애타게 찾았습니다. Product Engineer(FE) Product Engineer(FE Platform) bit.ly/3V6MVa4 bit.ly/45n29hf