마이크로서비스 아키텍처의 사실과 오해

최근 마이크로서비스 아키텍처에 대한 두 가지 일이 제 경험을 다시금 되새기게 했습니다. 하나는 지인에게서 들은 마이크로서비스 도입 경험담이며, 다른 하나는 유명 개발자 크리스 리처드슨의 글에서 본 인상적인 이미지였습니다.

제 경험은 2016년 중국에서 마이크로서비스를 채택했던 때로 거슬러 올라갑니다. 시간이 지나며 마이크로서비스에 대한 생각이 변화했기에 이를 정리해보고자 합니다.

마이크로서비스를 어떤 관점에서 볼 것인가?

마이크로서비스 아키텍처를 떠올릴 때 스스로 어떤 관점을 갖고 있나요? 어떤 목적이 뒷받침되면 구현 방법이 더 구체적일 수 있습니다. 이 글은 주로 두 가지 관점에서 마이크로서비스를 다루겠습니다.

첫 번째는 마이크로서비스 아키텍처가 사업의 속도를 지원한다는 것입니다. 많은 시스템이 사업을 지원하는 도구로 개발되므로 이 관점은 매우 중요합니다.

두 번째는 개발팀의 생산성을 높이는 관점입니다. 여기서 강조하는 것은 ‘개발자’의 생산성이 아닌 ‘개발팀’ 전체의 생산성입니다.

사업의 속도에 마이크로서비스가 어떤 도움을 주나?

레거시 시스템을 가진 기업은 새로운 비즈니스 기회를 시도할 때 갈등을 겪곤 합니다. 이러한 상황에서 마이크로서비스는 사업적 시도를 가능하게 하는 데 도움을 줄 수 있습니다.

“그들이 원하는 사업적 시도를 할 수 있게 해 줄 것인가?”

마이크로서비스는 사업적 시도를 위한 새로운 코드를 작성하고, 기존 레거시 코드의 규칙을 깨트리며 사업 기회를 현실로 바꿉니다.

일반적으로 Strangler Fig 패턴은 기존 시스템을 점진적으로 대체하는 방법론으로, 사업적 요구를 우선하며 시스템을 발전시킵니다.

개발팀의 생산성을 높이기 위한 시도 속에서 탄생한 마이크로서비스

개발팀이 생산성을 높이기 위해서는 시스템을 효율적으로 선택해야 합니다. 개발자는 자신의 시간과 노력을 최대한 활용해야 하며, 시스템이 이를 지원할 수 있어야 합니다.

최근 많은 인터넷 서비스 기업이 플랫폼 팀을 통해 개발자들을 지원하는 모습을 보이고 있습니다. 이는 마이크로서비스의 특성을 이해하고 활용한 것으로 보입니다.

기술의 선택은 개발팀이나 핵심 개발자에게 맞추는 것이 더 효과적입니다. 무리한 통일 대신 적절한 책임을 분배하는 것이 중요합니다.

마치며

마이크로서비스 아키텍처에 대한 두 가지 관점을 설명하였습니다. 이는 결국 사람과의 관계 속에서 배우는 것이었습니다. 개발자가 만드는 시스템은 사업에 기여해야 하며, 이는 상호 협력을 증진하는 요소입니다.

시스템의 확장성과 유연성을 가져오는 장치로서 마이크로서비스 아키텍처에 대해 다시 한 번 생각해봅니다. 이는 ‘따로 또 같이’ 협력하기 위한 기반이 될 수 있습니다.