# 전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것"

> Clean Markdown view of GeekNews topic #7839. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=7839](https://news.hada.io/topic?id=7839)
- GeekNews Markdown: [https://news.hada.io/topic/7839.md](https://news.hada.io/topic/7839.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2022-11-17T11:17:01+09:00
- Updated: 2022-11-17T11:17:01+09:00
- Original source: [twitter.com/jasoncwarner](https://twitter.com/jasoncwarner/status/1592227285024636928)
- Points: 46
- Comments: 13

## Topic Body

- "Monolith > apps > services > microservices"   
- 첫째, 이건 규칙은 아니고 내 생각이 그렇다는 것. 대규모 분산 시스템을 구축해 본 사람은 실제로 그대로 작동하지 않으며, 적응해야 한다는 것을 알고 있음   
- 둘째, 단계가 중요함  
  - 5-50인 회사라면 그냥 Monolith로 가세요  
  - 1만명 회사라면, 위의 모든 것들을 다 가지고 있을 것. 근데 예전과 달라진 생각들을 얘기해보자면..  
### 먼저 정의(Definition) 부터   
- monolith - xyz.com   
- apps - abc.xyz.com  
- services - 앱/모노리스를 지원, 핵심 인프라, 핵심 컴플라이언스 기능, 앱팀에서 작성하지 않을 수 있음(인프라에서 유지관리)  
- microserivces - 몇백라인의 코드, 대부분 일회성, 라이브러리 또는 SDK 일수/있어야(could/should) 함  
### Why ? : 기본적으로 "Speed & Risk" 때문   
- #1 전체 개발팀이 하나의 빅앱(전체 사이트가 Rails앱 이라고 생각해 볼 것)에서 개발하는게 더 쉬움   
- #2 성장하면 필수로 가지게 될 분산시스템은, 자체적으로 위험한 수백개의 마이크로서비스 없이도 이미 추론하기가 어려움   
- #3 완전히 마이크로로 간다면, 무분별한 확장을 처리하기 위해 새로운 개념을 도입해야 함   
- #4 맞춤형(Bespoke) 인프라 서비스 또는 마이크로서비스는 부채의 극단적 개념임. 코드도 부채이지만 서비스가 그것의 극단적인 버전. 이게 뭘 의미하는지 생각해 볼 것. 레버리지 포인트가 되게 할 것  
- 분산 시스템 엔지니어들은 중복되는걸 싫어하기 때문에 뭔가가 여러데서 이뤄진다면 "이걸 빼내서 마이크로 서비스를 만들자" 라고 생각함   
- 이론적으로는 이게 맞고, 일이십개 까지 되는 것은 괜찮음. 하지만 수십개가 넘어가거나 대규모 회사를 넘어서 사용된다면 기술 문제가 아니라 조직의 문제가 됨   
- 내가 이야기 하는 것이 잘못된 이분법 처럼 느껴지긴 하지만, 실제로 마이크로서비스에 대해서는 기술적인 도전들이 있고, 더 많은 조직적인 문제도 있음  
### 내가 우려하는 것은   
- #1 (특이하게 IT출신 CEO가 이끌지 않는 한) 인프라는 항상 우선순위에서 밀려남(get the short end of priority stick)  
- #2 서비스가 너무 많으면 일반적으로 소유권 문제 및 경계 문제가 생김   
- #3 수많은 마이크로서비스를 처리하기 위해 더 많은 도구를 도입함   
- #4 가장 중요한 것은 라이브러리나 SDK가 되었어야할 각 마이크로서비스들이 프로덕션에 위험을 초래함   
### 일반적으로 내가 추천하는 것은  
- #1 가능하면 최대한 오래 Monolith를 유지   
- #2 서비스는 인프라에 필요한 것에서 시작하고, 앱 개발쪽에서 시작하지 말 것   
- #3 Mono를 쪼개야 한다면, 작은 서비스들이 아닌 큰 앱들로 분해할 것  
- #4 각 새로운 앱은 회사내의 가상 벽이라고 생각할 것   
- #5 가능하다면 마이크로서비스 대신 라이브러리를 선호

## Comments



### Comment 13341

- Author: jonnung
- Created: 2022-11-18T09:16:34+09:00
- Points: 2

마지막 부분 우려와 추천 부분이 공감되네요.   
사실 회사 규모나 서비스 규모나 비슷한 맥락이고, 쪼개지 않으면 안 되는 순간이 올텐데 그걸 미리 대비하는 탁월한 판단이 필요하겠다라고 느꼈습니다.

### Comment 13335

- Author: love7peace
- Created: 2022-11-17T18:14:39+09:00
- Points: 1

회사 규모가 아니라 시스템 규모에 따라 달라져야 되는 거 아닌가? 내가 msa 를 잘못 이해하고 있었나?

### Comment 13334

- Author: ilbanin
- Created: 2022-11-17T15:13:44+09:00
- Points: 1

윗 댓글중에  
마이크로서비스의 문제가 아니라 무분별한 서비스의 확장이 문제가 아닐까요?  
라는 의견에 일단 동의하고, 회사가 커질수록 배포 문제+브랜치 관리같은 모노리스 자체의 단점이 너무 명확하게 드러나기 때문에 비용과 생산성간의 trade off 를 잘 선택해야할 것 같네요

### Comment 13333

- Author: functor
- Created: 2022-11-17T14:55:02+09:00
- Points: 1

너무 좋은 글이네요. 감사합니다.

### Comment 13331

- Author: ruinnel
- Created: 2022-11-17T14:35:26+09:00
- Points: 1

디자인패턴 중요성 논란? 과 비슷한거 같아요.  
디자인패턴이라는게 다양한 문제를 해결하는 과정에서 도출 된 코드 패턴들인데....  
어디까지나 상황에 맞게 필요에 의해서 응용 & 적용해야 하는데.....  
  
모범답안 마냥 디자인 패턴이 필수이고 몰입하는 사람들이 종종 있죠...  
  
요즘 MSA 관련해서도 비슷한게 무조건 MAS...인 사람들이 많아지는거 같습니다.

### Comment 13330

- Author: deokim
- Created: 2022-11-17T13:19:38+09:00
- Points: 1

닭이 먼저냐 달걀이 먼저냐 같은 말 같아요.  
마이크로서비스의 문제가 아니라 무분별한 서비스의 확장이 문제가 아닐까요?

### Comment 13329

- Author: bbulbum
- Created: 2022-11-17T12:57:10+09:00
- Points: 1

적절한 균형이 중요하다고 생각이 듭니다.  
마이크로서비스로 가게 되면 새로운 기능 = 새로운 마이크로 서비스로 귀결될 수 있는 점 때문에,  
관리가 점점 어려워지는것이 아닐까 싶네요.

### Comment 13328

- Author: hiddenest
- Created: 2022-11-17T12:18:17+09:00
- Points: 4

이전에 Segment 기술 블로그에 올라온 'Goodbye Microservices' 라는 글이 떠오르네요.  
Segment 역시 CDP라 굉장히 많은 데이터를 실시간으로 처리함에도 불구하고, Microservices에서 Monolith 구조로 전환하며 그 이유 등을 블로그에 정리해놓았습니다. 이 글과도 일정 부분 맞닿아있다고 생각이 듭니다 :)  
  
https://segment.com/blog/goodbye-microservices/

### Comment 13325

- Author: bamchi
- Created: 2022-11-17T11:51:06+09:00
- Points: 1

대체로 제 생각과 일치합니다.  
저희 회사의 개발자는 5명이라 아직까지는 monolith(RubyOnRails)를 지향하는게 맞다고 생각됩니다.   
위 글 처럼 50인 이상이 동시에 개발하는 프로젝트가 되면 그때는 두 번째 monolith를 개발하게 될거 같습니다.

### Comment 13324

- Author: tnrnfl
- Created: 2022-11-17T11:47:08+09:00
- Points: 1

5-50인 회사라면 그냥 Monolith로 가세요 << 이는 개발자수가 아니라 총 구성원의 수겠죠?

### Comment 13326

- Author: devstorm
- Created: 2022-11-17T11:58:04+09:00
- Points: 1
- Parent comment: 13324
- Depth: 1

회사 규모를 말하는 것 같아요~

### Comment 13323

- Author: yolatengo
- Created: 2022-11-17T11:39:20+09:00
- Points: 2

가능하면 최대한 오래 Monolith를 유지 < 극공감합니다. 분리하면서 유지비용 늘어나는게 커요

### Comment 13322

- Author: nicewook
- Created: 2022-11-17T11:27:48+09:00
- Points: 2

MSA가 도그마화 되어 가는 것에 대한 반동으로서의 글이라 생각이 되고, 그런 점에서 의미가 있겠다 싶습니다.