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

최근에 마이크로서비스 아키텍처에 대해 다시금 생각하게 만드는 두 가지 일이 있었습니다. 하나는 가까운 지인이 자신의 회사 서비스에 마이크로서비스를 도입하며 겪은 경험담을 듣는 일이었습니다. 이야기를 듣느라 말을 하지는 않았지만 자연스럽게 제 경험과 비교하며 듣다 보니 여러 가지 생각을 하게 되었습니다.

또 다른 하나는 유명 개발자 크리스 리처드슨의 글에서 아래 이미지를 본 일입니다. 2014년 QCon에서 그의 세션을 들은 인연으로 평소 그가 쓴 글에 관심이 있기는 했지만, 대화 한번 나누지 않고도 그림을 보는 즉시 그가 하고자 한 주장의 골자를 바로 공감하는 듯한 경험은 매우 인상적이었습니다.

chrisrichardson.net >

그 두 가지 사건이 인상 깊었던 배경에는 아마도 제가 2016년부터 중국에서 일할 때, 마이크로서비스 아키텍처를 채택하며 경험한 일들이 작동했을 것입니다. 그중 일부는 2017년 개발팀에 합류한 동료가 Micro Service, Docker로 할 수 밖에 없었던 사연 >이라는 제목으로 발행한 일이 있습니다. 제 글 로도 당시 경험을 공유하며 마이크로서비스에 대한 생각을 정리했지만, 그 후로도 벌써 7년 정도의 시간이 흘렀습니다. 개인적으로는 가벼운 자극에 지나지 않아도, 두 사건을 계기로 그간 변화한 생각을 덧붙여 마이크로서비스에 대한 글을 써 보기로 합니다.

마이크로서비스를 어떤 관점에서 볼 것인가? 앞서 쓴 글 프로그래밍이 꼭 그런 것만을 말하지는 않습니다 >에서 프로그래밍을 보는 여러 가지 관점이 있을 수 있다는 주장을 했습니다. 비슷하게 이번에도 화두를 던져 보겠습니다. 여러분은 마이크로서비스 아키텍처를 떠올릴 때 스스로 어떤 관점을 갖고 있나요?

마이크로서비스를 고려하는 바탕에 있는 목적이나 필요성 따위가 분명할수록 구현 방법이 구체적일 수 있습니다. 이글에서는 주로 두 가지 관점에서 마이크로서비스를 다루려고 합니다. 그리고, 마지막에는 이들을 아우르는 관점으로 제 생각을 요약해 보겠습니다.

먼저 첫 번째 관점은 마이크로서비스 아키텍처 채택으로 사업의 속도 를 지원한다는 관점입니다. 제 경력 대부분 이 기업용 소프트웨어 개발 분야라는 점에서 제가 말하는 시스템은 주로 응용 프로그램이고, 대개 그러한 프로그램은 사업을 지원하는 도구로써 개발된 것입니다. 그러니 시스템을 구성하는 특징을 결정할 때, 사업의 속도 관점이 중요한 것은 저에게는 당연한 일입니다.

두 번째는 개발팀의 생산성 을 높이는 관점입니다. 주의할 점은 ‘개발자’의 생산성이 아니라 ‘개발팀’의 생산성이라는 점입니다. 요즘 개발의 생산성을 언급하면 Cursor나 Co-pilot 사용 따위를 주로 언급하곤 하는데, 개인의 생산성과 팀의 생산성은 조금은 초점이 다르다고 할 수 있습니다. 마이크로서비스는 분산을 바탕으로 하기 때문에 개인의 생산성에 직접적인 도움을 준다고 보기 어렵습니다. 오히려 테스트의 어려움을 가중시키는 선택이라 그 반대에 가깝습니다.

사업의 속도에 마이크로서비스가 어떤 도움을 주나? 오래된 레거시 시스템을 둔 많은 회사에서는 새로운 비즈니스 기회를 만들려고 할 때 갈등을 겪는 장면을 아주 흔하게 볼 수 있습니다. 예를 들어 커머스 기업의 시스템이 있다고 하겠습니다. 오랜 업력을 통해 다양한 판매 방식을 지원하는 만큼 시스템에 연관된 사용자와 이해관계자가 많습니다. 이런 경우 대개는 그간 있었던 다양한 시도와 사연으로 인해서 시스템을 구성하는 코드가 쉽게 수정할 수 없는 형태로 굳어지는 경우가 일반적입니다.

이럴 때 영업 담당자가 새로운 사업 기회를 만들어 오거나 힘 있는 업체와 만나 제휴의 기회를 만들어 와도 기존 시스템의 안정성을 깨트릴까 봐 두려워 시도조차 못 하는 경우를 많이 만났습니다. 사실 중국에서 제 경험 역시 예를 든 상황과 크게 다르지 않은 장면입니다.

사업적 관점에서 보면 마이크로서비스로 할 것인가 아닌가는 전혀 중요한 이슈가 아닙니다. 문제는 그저 다음 한 문장으로 요약할 수 있습니다.

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

사실 이럴 때 사업하는 사람들이 개발 책임자에게 가장 듣고 싶어 하는 대답은 단 하나입니다. 바로 ‘가능합니다.’이죠. 그렇게 답하고 나서 말을 현실로 바꿀 개발 방법을 고민하다 보면 난관에 봉착한 문제를 풀 수 있습니다. 아니, 실제로 제가 그렇게 할 수 있었습니다.

놀랍게도 지구상에 많은 조직이 당시 제가 채택한 방법과 정확하게 같은 패턴을 택합니다. 이는 위키피디아에 등재된 패턴이기도 한, Strangler Fig 패턴입니다. 패턴 자체에 대한 설명은 제가 작년에 쓴 글 Strangler Fig 패턴과 점진적 IT 투자 >을 인용하는 것으로 생략하겠습니다.

Rany ElHousieny 미디엄 >

그 대신에 제가 여기서 하고 싶은 말을 이어 하겠습니다. 사업의 요구를 우선해서 먼저 사업적 시도를 가능하게 하는 코드를 작성해야 한다는 초점입니다. 당연하게도 기존 레거시 코드에 들어 있는 규칙이 깨질 수도 있기 때문에 일부 중복된 코드가 생기더라도, 개발팀은 빠르게 사업 기회를 현실로 바꿔주는 코드를 작성합니다. 이렇게 작성된 코드의 형태를 가만히 보면 영어권에서 Strangler fig 라고 부르는, 일종의 기생식물 역할을 하게 됩니다. 그 말인즉슨 점진적으로 원래 자리에 있던 나무의 에너지를 빼앗는다는 것이죠. 이 비유는 무엇을 말하는 것일까요?

위험을 무릅쓰고 레거시 코드를 고치는 대신에 사업적 시도를 위해서 새로운 코드를 넣었다고 합시다. 이를 반드시 써야 하는 레거시 코드를 병행해서 사용하는 모습이 마치 기생하는 나무의 모습을 연상시키는 것이죠. 한편, 새로운 사업적 시도가 성공하면 결과적으로 레거시 코드의 일부 기능이 대체되는 결과를 낳기도 합니다. 이렇게 짚어 보면 시스템의 구조를 기생 식물에 비유한 이유를 조금은 이해할 듯합니다.

여기서 중요한 포인트는 목적 자체입니다. 마이크로서비스를 하려고 시스템의 모양을 바꾼 것이 아니란 점입니다. 무리하게 레거시 시스템과 현재 개발 조직을 바꾸지 않고, 새로운 사업적 시도를 하기 위해서 선택한 길이라는 것이죠. 마이크로서비스를 사업적 시도를 가능하게 하는 동시에 시스템과 개발 조직의 안정성도 유지하는 방편으로 선택한 것뿐이죠. 그렇게 하고 보니, 결과적으로 아마도 Strangler Fig 패턴을 사용하게 될 가능성이 높았을 뿐입니다.

개발팀의 생산성을 높이기 위한 시도 속에서 탄생한 마이크로서비스 앞서 ‘현재 개발 조직을 바꾸지 않고’라는 표현을 썼습니다. 이는 구성원을 인위적으로 바꾸지 않는다는 말입니다. 하지만, 이들이 일하는 방식까지 바꾸지 않고 새로운 결과를 기대할 수는 없습니다.

제가 앞서 설명한 사업적 시도를 가능하게 한 개발 작업은 실제 경험에 기반한 일입니다. 하지만, 이때 개발팀에게는 사업적 시도 자체만 강조해서는 공감을 얻을 수 없습니다. 그들이 생산성을 높이기 위해 이 시스템을 선택할 방법을 찾아야 합니다.

이 관점에서, 제가 했던 일을 이후에 살펴 보고 동료가 썼던 글 을 보면 제 경험을 개발팀 관점에서 해석한 내용이 보입니다. 당시 마이크로서비스 적용과 함께 특정 기술이 좋다고 표준화를 강요하거나 결과물에 대한 부수적인 문서로 확인을 요구하던 관행을 모두 제거한 일이 굉장히 중요했습니다. 바로 개발팀의 생산성 관점에서 말이죠.

개발자는 결국 자기 시간과 노력을 어딘가에 기울여야 합니다. 특히 당장 사용하는 응용 프로그램으로 만들어지는 일 이외의 다른 일에 쓰는 시간을 줄일 수만 있다면, 불필요한 학습과 대기 혹은 시행착오를 줄일 수 있습니다. 그 효과는 기대 이상입니다.

요즘 개발팀이 잘 구축되었다는 평판을 듣는 인터넷 서비스 기업들이 플랫폼 팀이란 이름으로 개발자를 돕는 개발조직을 만드는 모습을 관찰합니다. 그 조직을 고안한 사람은 아마도 제가 글 도입부에 인용한 그림이 지칭하는 바를 이미 깨닫고 나름대로 실천하고 있는 것이라 짐작합니다.

chrisrichardson.net >

사실 그 형태가 꼭 마이크로서비스가 되어야 할 필요는 없습니다. 하지만, 프로그래밍 언어나 요소 기술이 갖고 있는 특성이 있습니다. 해당 기술을 만든 집단의 공통적인 쓰임새와 강점과 있기 마련이니까요. 가령 인공지능 기술을 다룰 때는 파이썬을 써야 학습 비용이 줄어드는 것과 같은 식이죠. 개발자 채용 관점에서 보면 백엔드 기술 인력의 경우, 스프링 프레임워크를 잘 다루는 자바 개발자가 절대다수를 차지하기도 합니다.

이렇듯 각 기술 커뮤니티마다 활성화된 부분이 있고 그렇지 않은 부분이 있어서 기술 선택은 도리어 개발팀이나 개발팀의 핵심 개발자에 맞추는 편이 좋습니다. 그렇게 하다 보면 자연스럽게 여러 프로그래밍 언어나 요소 기술 혹은 아키텍처가 혼용되는 일이 벌어질 수 있습니다.

저는 이를 무리하게 통일시키는 대신에 적절하게 책임을 분배하는 방법이 낫다고 생각합니다. 그렇게 하려다 보면 자연스럽게 마이크로서비스로 흘러가게 되는 것이죠.

마치며 지금까지 마이크로서비스 아키텍처를 바라보는 제 생각을 두 가지 관점으로 나눠서 설명했습니다. 둘 다 결국 사람과의 관계 속에서 터득한 관점입니다.

비즈니스 속도를 지원하는 관점은 개발자와 사업하는 사람들과의 관계를 향상시키는 관점입니다. 개발자가 만드는 시스템이 사업에 이롭다는 인식을 주는 일은 당연하게도 상호 협력에 유리합니다. 때때로 그렇게 하기 어려운 일이 발생하지만, 아키텍처가 이러한 어려움을 풀어나가는 데에 나름의 역할을 할 수 있어야 합니다.

또 다른 관점으로 나눈 개발팀의 생산성 역시 비슷한 면이 있습니다. 개발팀이 다수의 그룹으로 나눠질 사정이 있다면 시스템이 이를 수용할 수 있어야 확장성과 유연성이 생긴다 할 수 있습니다. 바로 그 확장성과 유연성을 가져오는 장치가 어쩌면 마이크로서비스 아키텍처일 수 있다는 생각을 해 볼 수 있습니다.

한동안 저는 시스템의 유기체적인 특성에 대해 떠들고 다닌 일이 있습니다. 그게 뭐냐 묻는 청중들 앞에서 저는 ‘따로 또 같이’ 할 수 있는 함께성을 말한다고 답했습니다. 어쩌면 시스템 현대화를 언급할 때 자주 나타나는 마이크로서비스 아키텍처 역시, 우리들이 사람으로서 ‘따로 또 같이’ 협력하기 위한 기반일 수도 있겠다는 생각을 하게 됩니다.