[마소 394호] 제대로 구성하는 마이크로서비스 아키텍처

오세용 기자
입력 2018.10.30 10:01
소프트웨어 전문지 마이크로소프트웨어 394호는 클라우드(Cloud)와 백엔드(Back-End)를 주제로 담았습니다. 트래비스CI, 데브옵스, PaaS, 마이크로서비스 아키텍처 등 마소 394호의 주요 기사들을 IT조선 독자에게도 소개합니다. [편집자주]

마이크로서비스 아키텍처! 마이크로가 들어간 이름치고는 다루는 범위가 넓으며, 아키텍처가 들어간 이름치고는 무엇 하나 쉽사리 결정해주지 않는다. 이 까다로운 녀석을 사내 백오피스 시스템에 적용하면서 얻은 경험과 결과물을 공유해보고자 한다.

버즈니가 운영 중인 모바일 홈쇼핑 포털 앱 홈쇼핑모아는 홈쇼핑과 T커머스 등 16개 채널을 한 곳에 모은 서비스다. 홈쇼핑모아를 위한 주요 개발 영역에는 서비스에 직접 사용되는 영역(프론트엔드 및 서비스 API) 외에도 백오피스(관리자 페이지 및 API) 영역이 있다. 이 글은 백오피스 영역에 마이크로서비스 아키텍처를 적용하게 된 이야기를 다룬다. 크게 세 가지 파트인 분해(Decomposition), 배포(Deploy), 인터페이스(Interface)로 나눠 설명하겠다.

백오피스 영역은 초기부터 규모가 절대 작지 않았다. 생방송 상품, 상품의 검색 키워드, 광고, 이벤트, 설문 조사, 고객 관리, 푸시 등 관리 페이지 자체만 20여 페이지가 넘게 있었다. 프론트엔드 개발자와 백엔드 개발자가 장고(Django) 프레임워크 안에서 함께 개발하고 있었고, 구조적으로 API, 클라이언트, 데이터베이스까지 다 한곳에 모인 모놀리틱(Monolithic Architecture) 아키텍처였다. 테스트와 빌드는 간편했고, 새로운 기능을 추가할 때 프레임워크 위에 소스만 추가하면 됐다. 다만 문제점은 시간이 흐르면서 복합적으로 나타났다.

버즈니는 2018년 상반기 직군 중심 구조에서 직무 중심으로 조직구조를 개편했다. 이는 프로젝트를 진행하면서 직무적 유관도와 업무 이해도가 적은 직군 중심의 팀 단위로 움직이기보다 프로젝트에 필요한 직무의 사람을 중심으로 업무를 진행하며, 각 구성원이 역할과 책임을 가지고 기민하게 움직일 수 있도록 하기 위함이다. 하지만 모놀리틱 아키텍처 구조에서는 경계의 애매함으로 관련자에게 적당한 역할과 책임을 나눠 주는 데 한계가 있었다.

버즈니의 백오피스 마이크로서비스 아키텍처. / 마이크로소프트웨어 394호 발췌
모놀리틱 아키텍처에서는 폴리글랏(Polyglot)하게 개발을 할 수 없다. 다시 말하면 요구 사항을 가장 잘 만족시킬 수 있는 적합한 언어, 프레임워크, 디자인 패턴을 선택할 수 없다. 이는 기술적 비효율로 이뤄질 수 있을 뿐 아니라, 개발자의 성장을 막는 요소로 작용하기도 한다.

또한 프로젝트의 절대적인 크기 자체가 커지며 생기는 문제점도 있다. 빌드 및 배포 시간이 늘어나며 패키지 관리가 힘들어진다. 개발을 시작하기 전 프로젝트 구조 및 히스토리를 파악하는데 필요한 시간 또한 늘어나게 된다.

마이크로서비스 아키텍처에는 정해진 정답은 없다는 말을 강조하고 싶다. 마이크로서비스 아키텍처는 태생적으로 많은 기업의 각기 다른 사례에서 생겨났기 때문이다. 다양한 옵션 및 패턴이 존재하며 상황에 맞게 적용하면 된다.

유민정 필자의 ‘제대로 구성하는 마이크로서비스 아키텍처’에 대한 자세한 내용은 ‘마이크로소프트웨어 394호(https://www.imaso.co.kr/archives/3939)’에서 확인할 수 있다.


관련기사를 더 보시려면?
T조선 뉴스레터 를 받아보세요! - 구독신청하기
매일 IT조선 뉴스를 받아보세요 닫기