이 글은 알파코에서 진행되는 [신한투자증권] 프로디지털아카데미 과정 중, 김송아 강사님과 함께하는 '파이널 프로젝트'를 기반으로 작성되었습니다
팀 CTO 리드 하에 ‘MSA'기반으로 아키텍처를 설계하였다!
우리 팀의 핵심 목표는 단순히 작동하는 백엔드를 만드는 것이 아니라, 확장성과 내결함성을 동시에 확보하는 구조를 만드는 것이었다.
이를 위해 프로젝트 전반에 MSA(Microservice Architecture) 를 적용했다.
사실 파이널 프로젝트 주제가 MSA를 이용한 설계라서 MSA를 사용해야만 했다.
프로젝트 개요
우리의 프로젝트인 ‘초보자 어시스트 대시보드’ 는 주식 초보자들이 투자 지표를 쉽게 이해하고, 자신의 성향에 맞는 분석과 신호를 제공받을 수 있도록 돕는 서비스다.
우리는 이 서비스를 MSA 기반으로 어떻게 안정적이고 유연하게 설계할 것인지 고민하였고, 하나의 거대한 서버보다, 여러 개의 작은 서비스가 독립적으로 동작하면서 서로 협력하는 구조가 필요했다.
WHY?????
두가지 큰 이유가 있었다.
1. 기능이 많아질수록 하나의 서버로는 관리가 어렵기 때문에!
2. 장애가 발생했을 때, 전체가 멈추지 않기 위해서!
그래서 EC2를
- AWS VPC 기반으로 네트워크를 설계
- 퍼블릭 서브넷에는 Nginx API Gateway + Next.js
- 프라이빗 서브넷에는 세 개의 MSA 서비스(Internal / External / Chart)
로 분리해 배포했다
이 구조는 앞으로의 기능 확장과 유지보수에 큰 기반이 될 것이다.
시스템 아키텍처 설계
이번 아키텍처 설계의 핵심은 안정성과 분리였다.
- 보안 / 접근 제어
- 퍼블릭과 프라이빗 서브넷을 나누고, Bastion 호스트를 통해서만 내부 EC2에 SSH 접근이 가능하도록 했다.
- 이를 통해 외부 공격으로부터 내부 리소스를 안전하게 보호할 수 있다.
- API Gateway
- Nginx를 활용해 클라이언트 요청을 각 서비스로 라우팅한다.
- 인증, 로깅, 로드밸런싱 같은 공통 기능은 Gateway에서 처리하도록 하여 서비스 부담을 줄였다.
- Kafka 기반 비동기 메시징
- Internal ↔ External ↔ Chart 간 데이터 연동은 Kafka 이벤트로 처리한다.
- 서비스 간 직접 의존성을 줄이고, “느슨한 결합(loose coupling)” 구조를 만들었다.
- 예를 들어, External 서비스가 새로운 뉴스 데이터를 발행하면, Chart 서비스가 이를 구독해 자동으로 신호를 갱신한다.
- RDS (Master/Slave 구조)
- 쓰기·읽기를 분리하고, 멀티 AZ 복제로 장애 상황에서도 자동 복구가 가능하다.
- 단순한 DB 설계가 아니라, “실제 운영 환경에서도 끊기지 않는 시스템”을 목표로 했다.
위와 같이 구성된 인프라는 “무겁지 않지만 단단한 구조”였다.
직접 설계하며 느낀 건, “보안과 분리”는 결국 유연성을 위한 투자라는 점이었다.
서비스 모듈 분리
MSA를 해야하는 것은 알겠다!
그런데!
서비스를 어디까지 쪼개야 할까..
처음에는 단순히 “Internal / External / Chart / Common” 네 개로 나눴지만, 단순히 물리적으로 나누는 것이 아니라 비즈니스 도메인 단위로 책임을 명확히 해야 했다.
그래서!
- internal-assistant-service : 사용자 정보, 거래 내역, 투자 성향 리포트 등 내부 데이터 기반 서비스
- external-assistant-service : 뉴스/시장 데이터, 섹터별 정보, 고수 종목 거래량 등 외부 데이터 연동
- chart-similarity-service : 차트, 호가창, 유사 차트 신호 분석 및 매매 신호 계산
- common-service : 공통 인증/인가, 설정 관리, 멤버 도메인
이렇게 나눴다.
확실히 하나의 거대한 시스템(모놀리식)을 완벽히 만드는 것보다,
작은 서비스 하나를 명확히 정의하는 것(MSA)이 훨씬 어렵다...
쨌든 이 모듈 분리가 팀 단위 병렬 개발을 가능하게 했고, 문제 발생 시에도 서비스 단위 장애 격리를 실현할 수 있었다.
CI/CD 및 배포 전략
CTO님께서 CI/CD 서비스별 무중단 배포 파이프라인을 구축하자고 제안하셨다. 느낌으로는 알지만 정확히는 잘 몰라서 찾아보았다.
다음과 같이 구상하였다.
- 독립 배포 : Internal / External / Chart 서비스는 각각 별도의 브랜치로 관리되고, 커밋 시 자동으로 빌드 → 테스트 → 배포까지 이어진다.
- 공통 모듈 연동 : Common 모듈 수정 시에는 3개 서비스가 자동으로 재빌드되어 버전 충돌을 방지했다.
- Blue-Green 배포 : 새로운 버전을 병렬로 띄우고, 정상 동작이 확인되면 트래픽을 전환한다. 장애가 발생해도 즉시 이전 버전으로 롤백 가능하다.
자동화 파이프라인을 설계하니깐 이제는 뭔가 실전같았다..!
딸깍한번에 배포가 끝나버리니 더 조심해야겠다는 생각이 들었다.
데이터베이스와 메시징
데이터 관리는 RDS 기반의 관계형 DB와 Kafka 메시징 큐로 나누어 설계했다.
RDS는 멤버, 종목, 거래, 섹터, 뉴스 등의 관계형 데이터를 관리하며
Kafka는 서비스 간 이벤트를 연결했다.
예를 들어:
External 서비스 → “새 뉴스 등록” 이벤트 발행
Internal 서비스 → 해당 섹터를 보유한 유저에게 알림 전송
Chart 서비스 → 관련 종목 차트 데이터 업데이트
회고 및 느낀 점
1. 어렵다,,
어려운거 알고는 있었는데 진짜 어렵다.
처음해봐서 그런거겠지만 진짜 어렵다.
CTO님이 주도해서 설계해주신 덕분에 겨우겨우 따라갔지만 없으셨다면 조금 힘들었을것같다.
2. 정답은 없다!
또한 아키텍처에 정답은 없다고 생각이 들었다.
설계를 하다 보니깐 MSA가 좋은 것 같다가도 또 '이럴 거면 모놀리식으로 하는 게 낫지 않나?'라는 생각이 여러 번 반복되었다.
개발에 정답은 없다고 생각한다! 하지만 오답은 있다.
최대한 상황에 맞게 사용하되, 내가 왜 이렇게 했는지에 대한 당위성을 갖고 다른 사람에게 설명할 수 있으면 되는 것 같다.
3. MSA에 관하여
MSA로 아키텍처를 설계할 때 몇가지 들은 생각이 있다.
MSA가 장점이 명확했다.
- 서비스가 작아질수록 책임이 명확해지고
- CI/CD가 자동화될수록 코드보다 운영에 집중할 수 있었다.
- Kafka를 통해 서비스 간 통신을 느슨하게 만들면서, 장애에 대한 두려움이 줄었다.
하지만 동시에 느낀 한계도 있다.
- 공통 모듈은 세 서비스 모두에 영향을 주기 때문에, “공통화의 기준”을 어디까지로 할지 신중해야 했다.
- 초기 아키텍처 구상을 하는데 시간이 많이 소요된다.
- 무엇보다 어렵다,,
4. 그래서?
다음 주부터는 이 아키텍처를 실제 코드로 구현할 예정이다.
명절 잘 쉬었다.
이제 본격적으로 달려가봐야겠다.
다들 화이팅!!!
