[신투 프디아] MSA 좋은 듯 어렵다 - 왜 투게더는 MSA로 설계했을까?

 

이 글은 알파코에서 진행되는 [신한투자증권] 프로디지털아카데미 과정 중, 김송아 강사님과 함께하는 '파이널 프로젝트'를 기반으로 작성되었습니다.

---

 

이번 글에서 다룰 내용은 바로!

우리 서비스에 '왜 MSA 방식을 도입했느냐'이다!

 

---

💥 시작에 앞서 MSA 란 무엇일까?

일단 MSA(Microservice Architecture)와 모놀리식(Monolithic Architecture)의 차이를 간단히 짚고 넘어가자.

 

모놀리식 vs MSA

 

🧱 모놀리식(Monolithic Architecture)

 - 하나의 큰 애플리케이션 안에 모든 기능이 통합된 구조

 - 유저, 매매, 페이 기능이 모두 한 프로젝트 안에 공존한다.

 - 초기 개발은 빠르지만, 규모가 커질수록 유지보수가 어려워진다.

   ex) 결제 모듈 하나를 수정하더라도 전체 빌드 및 배포가 필요하다.

 

✅ 장점

• 구조가 단순해 초기 개발 속도가 빠르다.
• 트랜잭션 일관성을 유지하기 쉽다. (모든 기능이 한 DB를 공유)
• 테스트 및 디버깅이 비교적 단순하다.

❌ 단점

• 규모가 커질수록 유지보수가 복잡해진다.
• 하나의 기능 수정이 전체 시스템에 영향을 미친다.
• 부분 장애가 전체 장애로 번질 위험이 있다.
• 기술 교체나 리팩토링이 어렵다.

---

 

🧩 MSA(Microservice Architecture)

 - 기능을 독립적인 서비스 단위로 분리한 구조

 - 각 서비스가 독립적으로 실행되고, API로 통신한다.

 - 즉, User, Trading, Pay, Vote가 각각의 작은 서버로 존재하는 것과 같다.

 - 서비스 별로 독립 배포, 확장성, 장애 격리가 가능하다.

 

✅ 장점

• 서비스별 독립 개발 및 배포 가능
    거래 기능만 수정하더라도 다른 서비스에 영향을 주지 않는다.
    각 서비스가 자기 주기로 배포되기 때문에 장애 범위가 최소화된다.
• 확장성
    트래픽이 몰리는 특정 서비스만 선택적으로 확장 가능하다.
    ex) 매매 트래픽이 급증하면 trading-service만 스케일 아웃 가능
• 장애 격리
    하나의 서비스에 문제가 발생해도 다른 서비스는 정상적으로 동작한다.
    ex) 결제 서버(pay-serviec)가 잠시 중단되어도 로그인(user-service)은 유지
• 기술 스택 선택의 자유
    장기적으로 새로운 기술 도입이 유연하다.
• 유지보수 및 팀 협업에 유리
    서비스 단위로 코드베이스가 분리되어 있어 팀별 병렬 개발이 가능하다.
    한 팀이 한 서비스에 집중할 수 있다.

❌ 단점

• 초기 설정 및 인프라 구성 복잡
   서비스 간 통신, API Gateway, Eureka(서비스 디스커버리, 클라이언트 사이드인 경우) 설정이 필요하다.
• 데이터 일관성 유지의 어려움
   서비스별로 DB가 분리되어 있어 분산 트랜잭션 관리가 복잡하다.
   ex)  거래와 결제 서비스의 데이터가 동시에 반영되어야 할 때, 트랜잭션 처리가 어렵다.
• 운영 및 모니터링 복잡도 증가
    로그, 트래픽, 장애를 통합해서 관리하려면 별도의 모니터링 시스템(ELK, Prometheus 등)이 필요하다.
    장애 추적이 어려워질 수 있다,
• 통신 비용 증가
    서비스 간 REST API 또는 메시지 큐(RabbitMQ/Kafka) 호출로 인한 오버헤드가 존재한다.
• 배포 및 테스트 환경 관리가 까다로움
    서비스가 여러 개라 CI/CD 파이프라인과 테스트 시나리오 관리가 복잡해진다.

---

 

💬 그래서! 우리 서비스는 왜 MSA를 도입했을까?

1️⃣ 금융 서비스

• 금융 서비스는 안정성과 확장성이 핵심이다.
• 실제로 대부분의 증권사, 은행, 페이 서비스가 MSA 구조를 채택하고 있다.
    거래량이 많고, 장애가 전체 시스템에 영향을 주면 안 되기 때문이다.
• 예를 들어 매매, 결제, 투표 등 각 기능이 독립적으로 동작해야 장애가 발생하더라도 다른 기능이 정상적으로 유지된다.
• 따라서 '투게더’ 역시 그룹형 주식 투자 서비스라는 특성상, MSA로 설계하기로 결정했다.

 

2️⃣ 페이 / 매매 / 투표 / 유저 - 명확한 기능 분리

• 우리 서비스는 Pay, Trading, Vote, User 등 역할이 명확한 기능 단위로 구성되어 있다.
• 투표, 거래, 결제처럼 서로 다른 책임을 가진 기능들은
  독립적인 서비스로 분리되어야 각자의 로직을 안정적으로 유지할 수 있다.
• 이런 구조는 MSA가 가진 도메인 단위 분리(Domain Separation)와 맞다고 판단했다.
• 특히, 투표 결과에 따라 거래를 실행하거나, 거래 결과를 알림으로 전달하는 등 서비스 간 연동이 많기 때문에
  서비스 간의 결합도를 낮춤으로서 장애 전파를 최소화할 수 있다.
• 기능 간 경계를 명확히 하고, 각 서비스의 독립성을 보장하기 위해 MSA를 결정했다.

 

3️⃣ 서비스 확장성 & 팀 단위 협업 용이

• 현재 서비스 규모가 작기에 MSA가 필수적이지는 않다.
• 하지만 장기적으로 서비스를 확장하거나 기능을 추가할 때, MSA 구조는 변화에 강하고 확장에 유연하다.
• 또한, 개발팀 입장에서도 MSA 설계 경험은 대규모 시스템 설계 능력을 기르는 데 큰 도움이 되고, 팀 단위의 협업에서도 용이하다.

 

4️⃣ DB는 하나로 통합

• 현재는 하나의 공용 DB를 사용하기로 결정했다.
    개발 효율성과 데이터 일관성 유지가 용이하기 때문이다.
    DB를 서비스별로 분리할 경우, 서비스간 JOIN이 불가능하고 데이터 정합성 유지가 어려워지는 단점이 있다.
• 따라서, 서비스 간 JOIN은 허용하되, 각 서비스는 자기 도메인의 데이터만 수정하도록 설계했다.
  ex) trading-service가 vote 테이블을 조회할 수는 있지만, 데이터 수정(INSERT/UPDATE/DELETE)은 하지 않도록 설계
• 이후, 서비스가 커진다면 스탠바이 DB(Standby DB)를 도입하여 장애 발생 시 즉시 복구가 가능한 구조로 전환할 계획이다. DB를 쪼개지 않더라도, 장애 복원력과 고가용성의 장점은 취하려고 한다.

 

💡 정리하자면

금융 서비스의 안정성, 명확한 도메인 분리, 확장성 확보, 팀 단위 협업 효율
이 네 가지 이유로 MSA 구조를 도입했다.

 

아래는 투게더의 초기 아키텍처이다.

 

초기 아키텍처

 

 

서비스는 총 네 개의 주요 모듈로 구성되어 있다.

 

1. Trading Service

 → 주식 매수/매도, 체결, 예수금 관리 등 거래 관련 핵심 로직

2. User Service

 → 사용자 정보 관리, 로그인/회원가입 등 인증 및 사용자 관리

3. Pay Service

 → 그룹 자금을 활용한 페이 결제

4. Vote Aervice

 → 매도/매수/예수금 충전 등 투자 의사결정 투표

 

이렇게 나누어진 거래, 결제, 투표, 사용자 관리가 하나의 금융 흐름을 만든다.

 

🐛 지금까지 MSA로 개발을 하며 느낀 점

지금까지 MSA로 개발을 하며 느낀 점은

MSA 좋은 듯 어렵다..

 

 

application.yml 같은 환경 설정이나 build.gradle 빌드 설정부터 시작해서,
서비스 간 기능이 연결될 때마다 한 번 더 구조를 고민해야 한다는 점이 쉽지 않았다.
작은 수정 하나를 하더라도 다른 서비스에 미치는 영향을 고려해야 해서,
확실히 개발 난이도는 높다고 느꼈다.

 

 

하지만 그만큼 서비스별 독립성이 뚜렷하게 느껴졌다.
특히 내가 맡은 트레이딩 시스템을 개발하면서,
매매 기능이 하나의 완결된 시스템처럼 돌아가는 과정이 흥미로웠다.

 

설정은 복잡하지만, 명확한 구조 안에서 개발할 수 있다는 점이
결국 MSA의 가장 큰 매력이라고 생각한다!