David Heinemeier Hansson: Microservices vs. Monolith - https://www.youtube.com/watch?v=rkXGSLf-rVQ
For the last several years, one of the big titanic battles in how to structure your application has been to go microservices or to go monolith. This debate has been raging on and off, sometimes intensively, otherwise dulling down. But as of recent note, it's kind of blossomed up again, because a lot of applications who've gone with a microservices architecture when that was the hot, hot thing, have I realized that perhaps it wasn't so hot for them? Even the likes of Amazon has backed off on microservices for at least some of their applications. And I think there's a really good reason for that. Microservices is a pattern that is about organizational structure much more than it is about how to organize your code. If you have incredibly large teams working on single applications and you have to break those up such that the individual teams can own a sub area of it, yeah, microservices can make sense in some cases. But if you're a team of 10, 20, maybe even 50 or 100 developers, going with a monolith is just so much simpler. Instead of replacing all your method calls with network calls, you can just keep it on the same computer. When you don't have to worry about network connectivity to make the app do its most basic functions, you cut out a huge swath of complexity that otherwise bogs you down, makes things hard to debug, makes it hard for any individual to understand the whole system. And I think what's really key here is to realize that different patterns fit different organizations. Microservices, and that whole approach came out of companies like Netflix, with thousands and thousands of developers who needed a different approach to building their systems and making it scale for that level of an organization. And if you take those kinds of patterns, the patterns that were built and extracted from companies of thousands of developers, and you apply them to companies of 5, 10, or 100 developers, you very often get really poor results. You are paying a heavy complexity tax for an environment and a context that just doesn't exist in your organization. That, to me, is one of the most foolish things that you can do. So I love the monolith. I love it so much. I coined the term the Majestic Monolith many years ago. I've been advocating for keeping things as simple as possible for as long as possible. And the Majestic Monolith does exactly that.
David Heinemeier Hansson: Microservices vs. Monolith - https://www.youtube.com/watch?v=rkXGSLf-rVQ
지난 몇 년간, 애플리케이션 구조를 어떻게 설계할 것인가에 대한 큰 논쟁 중 하나는 마이크로서비스로 갈 것인가, 아니면 모놀리스로 갈 것인가였습니다. 이 논쟁은 계속되어 왔는데, 때로는 격렬하게, 때로는 잠잠하게 이어졌습니다. 그런데 최근 들어 이 논쟁이 다시 불붙었습니다. 마이크로서비스가 한창 유행일 때 해당 아키텍처를 도입했던 많은 애플리케이션들이, 사실 그게 자신들에게는 그다지 좋지 않았다는 것을 깨달았기 때문입니다. Amazon조차도 일부 애플리케이션에서 마이크로서비스를 철회했습니다. 그리고 저는 그 이유가 분명하다고 생각합니다. 마이크로서비스는 코드를 어떻게 구성하느냐보다 조직 구조에 관한 패턴입니다. 단일 애플리케이션에 엄청나게 큰 팀이 있고, 각 팀이 특정 영역을 독립적으로 담당해야 한다면, 네, 어떤 경우에는 마이크로서비스가 의미 있을 수 있습니다. 하지만 10명, 20명, 혹은 50명이나 100명 규모의 팀이라면, 모놀리스가 훨씬 단순합니다. 모든 메서드 호출을 네트워크 호출로 대체하는 대신, 그냥 같은 컴퓨터 안에서 처리할 수 있습니다. 기본 기능을 위해 네트워크 연결을 걱정할 필요가 없다면, 불필요한 복잡성을 대폭 줄일 수 있습니다. 그 복잡성은 디버깅을 어렵게 만들고, 전체 시스템을 이해하기 힘들게 만듭니다. 그리고 핵심은, 서로 다른 패턴은 서로 다른 조직에 맞는다는 것입니다. 마이크로서비스와 그 접근 방식은 수천 명의 개발자를 보유한 Netflix 같은 회사에서 나온 것입니다. 그들은 시스템을 구축하고 그 규모의 조직에 맞게 확장하기 위해 다른 접근이 필요했습니다. 수천 명의 개발자로부터 나온 패턴을, 5명, 10명, 또는 100명 규모의 회사에 적용하면, 매우 좋지 않은 결과를 초래하는 경우가 많습니다. 여러분의 조직에는 존재하지도 않는 환경과 맥락을 위해 엄청난 복잡성 비용을 지불하는 것입니다. 그 환경과 맥락은 여러분의 조직에 존재하지 않습니다. 제 생각에 그것은 가장 어리석은 일 중 하나입니다. 저는 모놀리스를 사랑합니다. 정말 많이 사랑합니다. 저는 수년 전에 '장엄한 모놀리스'라는 용어를 만들었습니다. 저는 가능한 한 오랫동안 가능한 한 단순하게 유지하는 것을 주장해 왔습니다. 그리고 장엄한 모놀리스는 정확히 그것을 실현합니다.
# Summary of Video: The Debate Between Microservices and Monolith Architectures
이 비디오는 소프트웨어 애플리케이션 구조 방식에 대한 지속적인 논쟁, 즉 마이크로서비스와 모놀리식 아키텍처 중 어느 것을 사용할지에 대해 탐구합니다. 이 논쟁이 최근 다시 부상한 배경, 각 패턴이 적합한 조직적 맥락, 그리고 작은 팀에서는 모놀리식의 단순성을 옹호하는 내용을 다룹니다.
---
## Introduction to the Debate [00:00:20]
- **마이크로서비스 대 모놀리식** 아키텍처 간의 싸움은 수년간 계속되어 왔습니다.
- 최근 들어 일부 회사들이 마이크로서비스의 이점을 재고하면서 이 논쟁이 다시 격화되고 있습니다.
## Challenges with Microservices [00:00:36]
- 마이크로서비스를 도입한 많은 회사들이 항상 최선의 선택은 아니었다는 것을 발견했습니다.
- 아마존조차 특정 애플리케이션에 대해 마이크로서비스 사용을 축소했습니다.
- 마이크로서비스는 **네트워크 호출과 분산 시스템에 관련된 복잡성**을 도입합니다.
## Organizational Context Matters [00:00:39]
- 마이크로서비스는 단순한 코드 조직보다 **조직 구조**에 더 관련이 있습니다.
- 수천 명의 개발자가 있는 매우 큰 팀이 하위 시스템 소유권을 나눌 필요가 있을 때 적합합니다.
- 10명에서 100명 규모의 작은 팀에는 모놀리식이 종종 더 단순하고 효과적입니다.
## Benefits of Monoliths for Smaller Teams [00:01:07]
- 모놀리식은 메서드 호출을 로컬에 유지하여 네트워크 오버헤드를 피합니다.
- 이는 복잡성을 줄이고 디버깅을 쉽게 하며 전체 시스템을 이해하기 쉽게 만듭니다.
- 마이크로서비스가 불필요하게 부과하는 “복잡성 세금”을 회피합니다.
## Origin of Microservices and Misapplication [00:01:35]
- 마이크로서비스는 넷플릭스 같은 매우 큰 개발팀을 가진 회사들에서 시작되었습니다.
- 수천 명의 개발자를 위한 패턴을 작은 팀에 적용하면 종종 나쁜 결과를 초래합니다.
- 마이크로서비스가 더하는 복잡성은 작은 팀의 조직적 필요와 맞지 않을 수 있습니다.
## Advocacy for the "Majestic Monolith" [00:02:15]
- 발표자는 단순성과 관리 용이성을 이유로 모놀리식을 강력히 지지합니다.
- **“Majestic Monolith(장엄한 모놀리식)”**라는 용어는 시스템을 가능한 한 오랫동안 단순하게 유지하는 가치를 강조하기 위해 만들어졌습니다.
---
## Conclusion
이 비디오는 개발자와 조직이 팀 규모와 조직적 필요에 맞춰 아키텍처 패턴을 선택할 것을 권장합니다. 마이크로서비스는 매우 큰 조직에 필수적이지만, 작은 팀은 모놀리식 아키텍처의 단순성과 명료성에서 이익을 얻습니다. **Majestic Monolith**를 수용함으로써 팀은 불필요한 복잡성에서 벗어나 생산성을 향상시킬 수 있습니다.
---
**Key takeaway:** 조직적 맥락에 맞게 아키텍처 선택을 조정하세요—복잡성이 정당화되는지 고려하지 않고 마이크로서비스를 맹목적으로 도입하지 마십시오.