657
16
장
진화하는 아키텍트
은 이러한 지연을 결합의 위험보다는 덜 우려하고 있었다. 필자가 만난 다른 팀들은 마이크로
서비스 템플릿을 단순히 공유 바이너리 의존성으로 취급했지만,
DRY
(반복하지 않기
don
’
t
repeat
yourself
)에 매달려 지나치게 결합된 시스템이 되지 않도록 매우 부단히 노력해야 한다!
16.13.316.13.3
대규모로 포장된 길 대규모로 포장된 길
많은 마이크로서비스를 보유한 조직에서는 흔히 사내 내부의 마이크로서비스 템플릿 및 프레
임워크를 사용하며, 넷플릭스와 몬조가 그런 조직의 대표적인 예다. 각 조직은 기술 스택을 어
느 정도 표준화하기로 결정하고 (넷플릭스의 경우
JVM
, 몬조의 경우
Go
언어 ) 공통 도구 세트
를 사용해 예상대로 동작하는 표준적인 새 마이크로서비스를 빠르게 생성할 수 있다. 기술 스
택이 다양해지면, 요구에 맞는 표준 마이크로서비스 템플릿을 갖추기가 더욱 어려워진다.
서로 다른 다수의 기술 스택을 수용하려면 각각에 맞는 마이크로서비스 템플릿이 필요하다. 하
지만 이를 위해서는 팀에서 언어 선택을 섬세하게 제한하는 방식이 필요할 것이다. 사내 마이
크로서비스 템플릿이
JVM
만 지원하므로 사람들이 더 많은 작업을 직접 수행해야 한다면, 그들
은 대안의 기술 스택을 선택하길 꺼릴 것이다. 예를 들어, 넷플릭스는 시스템 일부분의 중단으
로 인해 모든 것이 중단되지 않도록 하려고 내결함성
fault
tolerance
과 같은 측면에 특히 신경을 쓰
고 있다. 또한 이러한 문제를 해결하고자