아키텍처
뱅크샐러드는 어떻게 레거시 서비스를 박살 내는가
두줄요약
거대 레거시 서비스를 조직 구조에 맞춰 15개 마이크로서비스로 분해했습니다. 섀도잉과 대시보드로 응답 차이·성능을 검증하며 점진적으로 전환했습니다.
문제 상황
- Python·MongoDB 기반 단일 서비스에 핵심 비즈니스 로직과 기능 추가가 누적된 거대 모놀리스
- 최신화되지 않은 기획 문서와 핵심 로직 테스트 부족으로 동작 변경 위험 및 개발 속도 저하
구조와 흐름
- 스쿼드의 제품·기술 오너십을 기준으로 레거시 서비스를 15개 마이크로서비스로 분해
- 기존 서비스가 HTTP 요청을 처리하면서 신규 서비스에도 동일 요청을 보내고 응답 차이인 디프를 수집하는 섀도잉 구조
- PUT·DELETE 요청의 듀얼 라이트로 서로 다른 DB 간 데이터 정합성 유지
성능/운영 포인트
- statsd·Kibana 로그와 Chronograf 대시보드로 디프, gRPC 오류, HTTP·gRPC 응답 시간을 추적
- 신규 서비스 유입을 1%부터 점진 확대하고 디프 0을 핵심 결과로 관리
- MongoDB·MySQL 및 Python·Go 간 소수점·타임존 처리 차이 사전 발견
적용해볼 점
- 목표가 아닌 개선 항목을 명시해 마이그레이션 범위 확장 방지
- Go·gRPC 서버 템플릿으로 반복 보일러플레이트와 초기 설정 비용 축소
- 짧고 잦은 스탠드업 미팅으로 고복잡도 프로젝트의 협업 지연과 실패 비용 완화
