핵심 요약 (Summary)
MSA(Microservices Architecture)는 하나의 거대한 서비스를 독립적으로 배포 가능한 작은 단위로 나누는 아키텍처 방식입니다. 백엔드에서 먼저 확산됐지만, 프론트엔드에서도 팀 규모와 서비스 복잡도가 커지면서 같은 문제를 겪게 됩니다. 어떤 상황에서 MSA가 필요해지는지, 무엇을 얻고 무엇을 포기해야 하는지, 그리고 단일 서비스와 멀티 서비스에서 각각 어떻게 설계하면 좋은지를 정리합니다.
왜 이런 문제가 발생하나요? (Why)
네이버, 카카오, 토스 같은 대형 서비스는 하나의 프론트엔드 코드베이스 안에 수십 개의 팀이 함께 작업합니다. 팀이 2~3명일 때는 문제가 없습니다. 하지만 팀이 10개, 50개가 되면 상황이 달라집니다.
A팀의 코드 변경이 B팀의 배포를 막습니다. 긴급 수정을 위해 전체 서비스를 재배포해야 합니다. 신규 기능을 추가하려면 다른 팀의 코드 리뷰를 기다려야 합니다. 특정 페이지만 트래픽이 폭증해도 전체 서비스가 부하를 받습니다.
이 문제들이 반복되면서 "서비스를 독립적인 단위로 나눌 수 없을까"라는 질문이 생깁니다. 그 답 중 하나가 MSA입니다.
MSA란 무엇인가요
MSA는 하나의 애플리케이션을 독립적으로 개발, 배포, 운영할 수 있는 작은 서비스들의 집합으로 구성하는 방식입니다.
전통적인 방식인 모놀리식(Monolithic) 아키텍처에서는 모든 기능이 하나의 코드베이스에 묶여 있습니다. 쇼핑몰을 예로 들면, 상품 목록, 장바구니, 결제, 마이페이지가 모두 하나의 프로젝트 안에 있습니다. 하나를 수정하면 전체를 다시 빌드하고 배포해야 합니다.
MSA에서는 이것을 각각 독립된 서비스로 분리합니다. 상품 서비스, 장바구니 서비스, 결제 서비스, 마이페이지 서비스가 각자의 코드베이스와 배포 파이프라인을 가집니다. 결제 서비스에 긴급 수정이 필요하면, 결제 서비스만 배포하면 됩니다.
프론트엔드에서는 이 개념이 Micro Frontend라는 형태로 구체화됩니다. 각 팀이 독립적인 프론트엔드 앱을 소유하고, 사용자에게는 하나의 통합된 서비스처럼 보이도록 조합합니다.
어떤 상황에서 MSA가 필요해지나요
MSA가 무조건 좋은 선택은 아닙니다. 아래 상황 중 하나라도 해당된다면 고려해볼 시점입니다.
팀이 커지고, 배포가 자주 충돌할 때
개발자가 20명을 넘어가면 하나의 저장소에서 충돌 없이 협업하기가 어려워집니다. 서로 다른 기능을 개발 중이어도 공통 파일에서 충돌이 나고, 한 팀의 배포가 전체 팀의 배포를 지연시킵니다.
서비스의 특정 영역이 다른 속도로 성장할 때
결제 기능은 안정성이 최우선이고, 마케팅 이벤트 페이지는 빠르게 만들고 빠르게 없애야 합니다. 두 영역이 같은 배포 주기로 묶여 있으면, 빠른 팀도 느린 팀도 모두 비효율을 겪습니다.
기술 스택을 팀별로 다르게 가져가야 할 때
레거시 서비스는 Vue로 되어 있는데, 신규 팀은 React를 쓰고 싶을 수 있습니다. 모놀리식에서는 이 결정을 단일 기술 스택으로 통일해야 합니다. MSA에서는 서비스별로 다른 기술 스택을 허용할 수 있습니다.
특정 서비스만 독립적으로 스케일링해야 할 때
쇼핑몰의 상품 목록 페이지는 트래픽이 집중되는 반면, 고객센터 페이지는 상대적으로 한산합니다. 모놀리식에서는 전체를 스케일링해야 하지만, MSA에서는 상품 서비스만 리소스를 늘릴 수 있습니다.
반대로 아래 상황이라면 MSA는 오버엔지니어링입니다.
팀이 10명 이하인 스타트업, 서비스 초기 단계로 요구사항이 자주 바뀌는 상황, 운영 인프라를 담당할 인력이 없는 경우. 이 상황에서 MSA를 도입하면, 기능 개발보다 아키텍처 관리에 더 많은 시간을 쓰게 됩니다.
MSA의 좋은 점
독립 배포
가장 큰 장점입니다. 결제 팀이 새 기능을 배포할 때 상품 팀의 코드 리뷰를 기다리지 않아도 됩니다. 각 팀이 자신의 서비스를 원하는 시점에 배포할 수 있습니다.
장애 격리
이벤트 페이지에서 에러가 나도, 결제 서비스에는 영향이 없습니다. 모놀리식에서는 하나의 컴포넌트에서 발생한 문제가 전체 서비스를 다운시킬 수 있지만, MSA에서는 장애가 해당 서비스 안에서 격리됩니다.
팀 자율성
각 팀이 자신의 서비스에 대해 기술 선택, 배포 전략, 테스트 방식을 독립적으로 결정할 수 있습니다. 중앙 집중식 의사결정 병목이 줄어듭니다.
점진적 전환
레거시 서비스를 한 번에 전부 교체하는 것은 위험합니다. MSA에서는 마이페이지 서비스부터 새 기술 스택으로 교체하고, 나머지는 기존 코드를 유지하는 식의 점진적 전환이 가능합니다.
MSA의 나쁜 점
운영 복잡도의 급증
서비스가 10개라면 배포 파이프라인도 10개, 모니터링 대시보드도 10개, 장애 대응 채널도 10개가 됩니다. 단순히 코드만 나뉘는 것이 아니라 운영 부담 전체가 서비스 수에 비례해 커집니다.
서비스 간 통신 비용
하나의 페이지가 여러 서비스의 데이터를 동시에 필요로 할 때, 서비스 간 API 호출이 늘어납니다. 네트워크 지연, 에러 처리, 데이터 동기화 문제가 모놀리식에 비해 훨씬 복잡해집니다.
공통 상태 관리의 어려움
로그인 상태, 사용자 정보, 알림 등 전역적으로 공유해야 하는 상태를 여러 서비스가 각자 관리하면 동기화 문제가 생깁니다. 이를 해결하기 위한 별도 설계가 필요합니다.
초기 도입 비용
MSA를 처음 도입할 때는 인프라 설계, CI/CD 구성, 서비스 간 통신 규약, 공유 라이브러리 관리 등 기능 개발과 무관한 초기 작업량이 상당합니다.
단일 서비스와 멀티 서비스, 어떻게 설계하면 좋을까요
단일 서비스 (모놀리식)에서 잘 설계하기
서비스를 처음 만들 때는 모놀리식으로 시작하는 것이 일반적으로 더 좋은 선택입니다. 단, 나중에 MSA로 전환하기 쉬운 구조를 미리 잡아두는 것이 중요합니다.
핵심은 도메인 기반 폴더 구조입니다. 기능별로 폴더를 나누는 것이 아니라, 비즈니스 도메인 단위로 코드를 모아두는 방식입니다. features/payment, features/cart, features/product처럼 각 도메인이 자신의 컴포넌트, 훅, API 호출, 상태를 모두 가지고 있으면, 나중에 이 폴더 단위로 서비스를 분리하기가 훨씬 쉬워집니다.
공통으로 쓰이는 컴포넌트, 유틸, 타입은 shared 레이어로 분리해두고, 도메인 간 직접 의존성을 최소화합니다. payment 도메인이 cart 도메인의 내부 컴포넌트를 직접 import하는 구조는 나중에 분리할 때 걸림돌이 됩니다.
멀티 서비스 (MSA / Micro Frontend)에서 설계하기
여러 서비스를 사용자에게 하나처럼 보여주는 방법은 크게 두 가지입니다.
첫 번째는 라우팅 기반 통합입니다. /payment 경로는 결제 서비스가, /mypage 경로는 마이페이지 서비스가 담당하는 방식입니다. 서비스 간 전환이 페이지 이동과 함께 일어나기 때문에 구현이 단순합니다. 네이버나 카카오처럼 서비스 간 이동이 자연스럽게 분리되는 구조에 적합합니다.
두 번째는 런타임 통합입니다. 하나의 페이지 안에서 여러 서비스의 컴포넌트를 조합하는 방식입니다. Webpack Module Federation이 대표적인 기술입니다. 한 페이지 안에 헤더는 공통 서비스가, 상품 정보는 상품 서비스가, 구매 버튼은 결제 서비스가 각자의 컴포넌트를 제공하는 구조입니다. 구현 복잡도가 높지만, 사용자 경험의 일관성을 유지하면서 팀을 분리할 수 있습니다.
서비스 간 공유해야 하는 상태(로그인 정보, 장바구니 수량 등)는 쿠키, localStorage, 또는 공용 API 서버를 통해 동기화합니다. 각 서비스가 독립적이더라도 사용자 입장에서는 하나의 서비스처럼 느껴져야 하기 때문에, 공유 상태 설계는 MSA에서 가장 신중하게 다뤄야 하는 영역입니다.
디자인 시스템은 어떻게 가져가야 하나요
MSA 구조에서 가장 먼저 문제가 되는 것이 UI 일관성입니다. 서비스마다 버튼 색상이 다르고, 폰트가 다르고, 모달 스타일이 다르면 사용자는 같은 서비스를 쓰는 느낌을 받지 못합니다.
이를 해결하는 방법이 공유 디자인 시스템입니다. 컴포넌트 라이브러리를 독립된 npm 패키지로 만들어 모든 서비스가 동일하게 사용하는 방식입니다. 토스의 toss/slash, 카카오의 내부 디자인 시스템이 이 방식을 따릅니다.
버전 관리가 핵심입니다
디자인 시스템이 npm 패키지로 배포되면, 각 서비스는 특정 버전을 사용합니다. 디자인 시스템 팀이 버튼 컴포넌트를 변경해도, 각 서비스는 준비가 됐을 때 버전을 올립니다. 강제 업데이트가 없기 때문에 각 팀의 자율성이 보장됩니다.
단, 버전이 너무 오래 분산되면 동일한 서비스처럼 보이지 않는 문제가 생깁니다. 최소 버전 정책을 만들어 너무 오래된 버전은 지원 종료하는 방식으로 관리합니다.
디자인 토큰을 기반으로 잡아야 합니다
컴포넌트보다 더 아래 레이어에 디자인 토큰이 있습니다. 색상, 간격, 타이포그래피, 그림자 같은 값을 CSS 변수나 JSON 형태로 정의해두고, 모든 서비스와 디자인 시스템이 이 토큰을 참조하는 구조입니다.
컴포넌트 레이어에서 불일치가 생겨도, 토큰 레이어가 통일되어 있으면 전체적인 비주얼 언어는 일관성을 유지합니다. 서비스가 많아질수록 컴포넌트 단위 공유보다 토큰 단위 공유가 더 현실적인 선택이 됩니다.
문서화와 Storybook
디자인 시스템이 패키지로 분리되는 순간, 어떤 컴포넌트가 있고 어떻게 써야 하는지를 알려주는 문서가 필수가 됩니다. Storybook을 통해 컴포넌트를 시각적으로 확인하고, 각 props와 사용 예시를 문서화해두어야 각 팀이 독립적으로 올바르게 사용할 수 있습니다.
정리 (Conclusion)
MSA는 팀이 커지고 서비스가 복잡해질 때 생기는 문제를 해결하기 위한 구조입니다. 독립 배포, 장애 격리, 팀 자율성이라는 강점이 있지만, 운영 복잡도와 초기 도입 비용이라는 현실적인 대가가 따릅니다.
서비스를 처음 만들 때는 모놀리식으로 시작하되, 도메인 기반 폴더 구조로 나중을 대비해두는 것이 현명합니다. MSA가 필요한 시점이 오면, 잘 설계된 모놀리식은 자연스럽게 서비스 단위로 분리할 수 있습니다.
디자인 시스템은 MSA에서 UI 일관성을 지키는 핵심 장치입니다. 컴포넌트 패키지와 디자인 토큰을 분리해 공유하고, 버전 정책으로 관리하는 구조가 현실적입니다.
결국 아키텍처 선택은 기술의 문제가 아니라 팀과 서비스의 현재 상태에 맞는 판단의 문제입니다.