Monorepo vs Polyrepo: 어떤 전략을 선택해야 할까요?

spinny:~/writing $ vim monorepo-vs-polyrepo.md

1~
2복잡한 소프트웨어 프로젝트를 진행할 때, monorepo와 polyrepo 사이의 선택은 팀의 생산성과 코드 확장성에 큰 영향을 미칠 수 있습니다. 이 글에서는 각 접근 방식의 차이점, 장단점을 분석하고, 어떤 것이 적합한지 이해하도록 도와드립니다.
3~
4## Monorepo와 Polyrepo란 무엇인가요?
5~
6### Monorepo
7~
8**Monorepo**(모놀리식 저장소)는 여러 프로젝트, 서비스 또는 패키지의 소스 코드를 포함하는 단일 저장소로, 종종 서로 관련되어 있습니다.
9~
10```plaintext filename="Example Monorepo Structure"
11my-monorepo/
12  packages/
13    frontend/
14    backend/
15    shared/
16  package.json
17  turbo.json
18```
19~
20### Polyrepo
21~
22**Polyrepo**(다중 저장소)는 각 프로젝트, 서비스 또는 패키지가 자체 별도의 저장소를 갖는 것을 의미합니다.
23~
24```plaintext filename="Example Polyrepo Structure"
25repos/
26  frontend/
27    package.json
28  backend/
29    package.json
30  shared/
31    package.json
32```
33~
34## 시각적 차이
35~
36```mermaid
37flowchart TD
38    subgraph Monorepo
39        A1["frontend/"]
40        A2["backend/"]
41        A3["shared/"]
42    end
43    style Monorepo fill:#e0e7ff,stroke:#6366f1,stroke-width:2px
44```
45~
46```mermaid
47flowchart TD
48    subgraph Polyrepo
49        B1["frontend repo"]
50        B2["backend repo"]
51        B3["shared repo"]
52    end
53    style Polyrepo fill:#fee2e2,stroke:#ef4444,stroke-width:2px
54```
55~
56## 장단점
57~
58### Monorepo
59~
60**장점:**
61- 코드 공유가 쉬워집니다 (예: 공유 라이브러리).
62- 여러 프로젝트에 걸친 원자적 리팩토링.
63- 의존성 및 설정의 중앙 집중 관리.
64~
65**단점:**
66- 코드베이스가 커지면 무거워질 수 있습니다.
67- 부분 빌드/테스트를 관리하기 위한 도구가 필요합니다 (예: Nx, Turborepo).
68~
69### Polyrepo
70~
71**장점:**
72- 각 팀/프로젝트가 독립적입니다.
73- 소규모 프로젝트에서 관리가 더 쉽습니다.
74- 세분화된 접근 정책을 허용합니다.
75~
76**단점:**
77- 패키지를 게시하지 않고는 코드 공유가 어렵습니다.
78- 저장소 간 리팩토링이 더 복잡합니다.
79- 설정의 중복 가능성이 있습니다.
80~
81## 실용적인 예제: Turborepo를 사용한 Monorepo
82~
83Turborepo를 사용하여 frontend와 backend가 포함된 monorepo를 만들고 싶다고 가정해 봅시다.
84~
85### 1. Monorepo 초기화
86~
87```bash
88npx create-turbo@latest
89```
90~
91### 2. 일반적인 구조
92~
93```plaintext
94my-monorepo/
95  apps/
96    web/        # frontend Next.js
97    api/        # backend Node.js/Express
98  packages/
99    ui/         # shared component library
100    utils/      # shared functions
101  turbo.json
102  package.json
103```
104~
105### 3. `package.json`의 workspace 예제
106~
107```json
108{
109  "private": true,
110  "workspaces": [
111    "apps/*",
112    "packages/*"
113  ]
114}
115```
116~
117### 4. 공유 라이브러리 가져오기 예제
118~
119`packages/utils/src/formatDate.ts`에 함수가 있다고 가정합니다:
120~
121```ts
122// packages/utils/src/formatDate.ts
123export function formatDate(date: Date): string {
124  return date.toLocaleDateString('en-US');
125}
126```
127~
128Frontend에서:
129~
130```ts
131// apps/web/pages/index.tsx
132import { formatDate } from '@myorg/utils';
133~
134export default function Home() {
135  return <div>Today is {formatDate(new Date())}</div>;
136}
137```
138~
139## 언제 Monorepo를 선택해야 할까요?
140~
141- 여러 관련 프로젝트를 진행하는 중대규모 팀.
142- 코드 공유와 대규모 리팩토링이 필요한 경우.
143- 빠르게 성장하고 최적화된 빌드/테스트가 필요한 프로젝트.
144~
145## 언제 Polyrepo를 선택해야 할까요?
146~
147- 소규모 또는 독립적인 프로젝트.
148- 서로 다른 제품을 담당하는 별도의 팀.
149- 매우 엄격한 접근 정책.
150~
151## 결론
152~
153모든 상황에 맞는 완벽한 솔루션은 없습니다. 선택은 팀 규모, 프로젝트 복잡성 및 협업 필요성에 따라 달라집니다. 중요한 것은 트레이드오프를 인식하고 복잡성을 관리하기 위한 올바른 도구를 선택하는 것입니다.
154~

NORMAL · monorepo-vs-polyrepo.md [readonly]154 lines · :q to close

2복잡한 소프트웨어 프로젝트를 진행할 때, monorepo와 polyrepo 사이의 선택은 팀의 생산성과 코드 확장성에 큰 영향을 미칠 수 있습니다. 이 글에서는 각 접근 방식의 차이점, 장단점을 분석하고, 어떤 것이 적합한지 이해하도록 도와드립니다.

4## Monorepo와 Polyrepo란 무엇인가요?

6### Monorepo

8**Monorepo**(모놀리식 저장소)는 여러 프로젝트, 서비스 또는 패키지의 소스 코드를 포함하는 단일 저장소로, 종종 서로 관련되어 있습니다.

10```plaintext filename="Example Monorepo Structure"

11my-monorepo/

12 packages/

13 frontend/

14 backend/

15 shared/

16 package.json

17 turbo.json

18```

19~

20### Polyrepo

21~

22**Polyrepo**(다중 저장소)는 각 프로젝트, 서비스 또는 패키지가 자체 별도의 저장소를 갖는 것을 의미합니다.

23~

24```plaintext filename="Example Polyrepo Structure"

25repos/

26 frontend/

27 package.json

28 backend/

29 package.json

30 shared/

31 package.json

32```

33~

34## 시각적 차이

35~

36```mermaid

37flowchart TD

38 subgraph Monorepo

39 A1["frontend/"]

40 A2["backend/"]

41 A3["shared/"]

42 end

43 style Monorepo fill:#e0e7ff,stroke:#6366f1,stroke-width:2px

44```

45~

46```mermaid

47flowchart TD

48 subgraph Polyrepo

49 B1["frontend repo"]

50 B2["backend repo"]

51 B3["shared repo"]

52 end

53 style Polyrepo fill:#fee2e2,stroke:#ef4444,stroke-width:2px

54```

55~

56## 장단점

57~

58### Monorepo

59~

60**장점:**

61- 코드 공유가 쉬워집니다 (예: 공유 라이브러리).

62- 여러 프로젝트에 걸친 원자적 리팩토링.

63- 의존성 및 설정의 중앙 집중 관리.

64~

65**단점:**

66- 코드베이스가 커지면 무거워질 수 있습니다.

67- 부분 빌드/테스트를 관리하기 위한 도구가 필요합니다 (예: Nx, Turborepo).

68~

69### Polyrepo

70~

71**장점:**

72- 각 팀/프로젝트가 독립적입니다.

73- 소규모 프로젝트에서 관리가 더 쉽습니다.

74- 세분화된 접근 정책을 허용합니다.

75~

76**단점:**

77- 패키지를 게시하지 않고는 코드 공유가 어렵습니다.

78- 저장소 간 리팩토링이 더 복잡합니다.

79- 설정의 중복 가능성이 있습니다.

80~

81## 실용적인 예제: Turborepo를 사용한 Monorepo

82~

83Turborepo를 사용하여 frontend와 backend가 포함된 monorepo를 만들고 싶다고 가정해 봅시다.

84~

85### 1. Monorepo 초기화

86~

87```bash

88npx create-turbo@latest

89```

90~

91### 2. 일반적인 구조

92~

93```plaintext

94my-monorepo/

95 apps/

96 web/ # frontend Next.js

97 api/ # backend Node.js/Express

98 packages/

99 ui/ # shared component library

100 utils/ # shared functions

101 turbo.json

102 package.json

103```

104~

105### 3. `package.json`의 workspace 예제

106~

107```json

108{

109 "private": true,

110 "workspaces": [

111 "apps/*",

112 "packages/*"

113 ]

114}

115```

116~

117### 4. 공유 라이브러리 가져오기 예제

118~

119`packages/utils/src/formatDate.ts`에 함수가 있다고 가정합니다:

120~

121```ts

122// packages/utils/src/formatDate.ts

123export function formatDate(date: Date): string {

124 return date.toLocaleDateString('en-US');

125}

126```

127~

128Frontend에서:

129~

130```ts

131// apps/web/pages/index.tsx

132import { formatDate } from '@myorg/utils';

133~

134export default function Home() {

135 return <div>Today is {formatDate(new Date())}</div>;

136}

137```

138~

139## 언제 Monorepo를 선택해야 할까요?

140~

141- 여러 관련 프로젝트를 진행하는 중대규모 팀.

142- 코드 공유와 대규모 리팩토링이 필요한 경우.

143- 빠르게 성장하고 최적화된 빌드/테스트가 필요한 프로젝트.

144~

145## 언제 Polyrepo를 선택해야 할까요?

146~

147- 소규모 또는 독립적인 프로젝트.

148- 서로 다른 제품을 담당하는 별도의 팀.

149- 매우 엄격한 접근 정책.

150~

151## 결론

152~

153모든 상황에 맞는 완벽한 솔루션은 없습니다. 선택은 팀 규모, 프로젝트 복잡성 및 협업 필요성에 따라 달라집니다. 중요한 것은 트레이드오프를 인식하고 복잡성을 관리하기 위한 올바른 도구를 선택하는 것입니다.

154~