점진적 MSA 전환은 환상일까? - 사내 강결합 레거시 서비스와의 사투기

안녕하세요. 프롭테크 플랫폼에서 3년차 백엔드 개발자로 일하고 있는 정정일입니다.

저는 최근 3월 팀에 합류했고 많은 기업들이 그렇듯, 저희 팀도 더 나은 확장성과 유지보수성을 위해 레거시 서비스를 마이크로서비스 아키텍처(MSA)로 전환하는 대장정을 진행하고 있었습니다.

도메인별로 서비스를 착착 분리하고, 새로운 기술을 적용하며 점진적으로 시스템을 개선해나가는 청사진을 그렸죠.

하지만 현실은 달랐습니다. 특히 도메인 간의 강한 결합이라는 큰 벽에 부딪혔습니다. “하나씩, 점진적으로 전환하면 된다"는 이상적인 시나리오는 저희 회사의 강력하고 거대한 레거시 시스템 앞에서 힘을 잃었습니다.

이 글에서는 저희가 레거시 서비스의 강한 결합 문제를 어떻게 마주하고, 어떤 고민 끝에 해결책을 찾아 나갔는지, 그 경험을 공유하고자 합니다.

마주하게 된 과제 - 핵심 도메인 분리

제가 팀에 합류하는 시점에 저희 팀은 이미 MSA 전환 여정을 어느 정도 진행한 상태였습니다. 알림, 사용자 이벤트(쿠폰, 포인트 등)처럼 다른 도메인과 결합이 비교적 느슨한 서비스들은 성공적으로 분리하여 MSA의 장점을 맛보고 있었죠. 다음 타겟으로 핵심 도메인 중 하나인 ‘아파트 관련 기능’을 선택하게 됐습니다.

하지만 이 결정은 우리가 이전에 겪어보지 못한, ‘진짜 문제’ 의 시작이었습니다. ‘도메인 강결합’ 이라는 거대한 산이 나타난 것입니다.

아래 다이어그램은 저희가 마주했던 레거시 시스템의 내부를 단순화한 모습입니다.

보시다시피, Matching Domain의 핵심 로직이 Apartment Domain의 데이터에 직접 의존하고 있었습니다.

단순히 API를 호출하는 관계를 넘어, 같은 데이터베이스의 테이블을 공유하며 비즈니스 로직이 깊숙이 얽혀있었습니다.

Apart-Service를 분리한다는 것은 매칭 로직관련 로직의 수정이 불가피하다는 의미였습니다.

“아파트 관련 기능만 이관하고 싶었으나, 레거시 서비스에서는 아파트 정보와 ‘매칭’ 기능에 강한 결합이 있어 아파트만 분리할 수 없었다. 매칭도 같이 분리해야 하는데, 이런 경우들이 문제가 되는 경우들이 있어 점진적 전환이 어려운 부분이 있습니다.”

레거시 서비스에 대한 파악을 진행하고 팀 회의에서 이야기 해야했던 이 한마디가 저희가 처한 상황을 가장 정확하게 설명하고 있었습니다.

기술적 기반 다지기와 드러난 진짜 문제

물론 저희도 MSA 전환을 진행하며 기술적 기반을 마련하기 위해 노력했습니다.

1. 헥사고날 아키텍처 & CQS: 서비스 내부의 설계 품질을 높이고, 도메인 로직이 외부 기술에 의존하지 않도록 구조를 잡았습니다.
2. 서비스 간 통신 (FeignClient): 서비스간 통신에 gRPC, Zero-Payload, CQRS 등을 고려했으나 Spring Cloud 환경에서 효율적인 동기 통신을 위해 FeignClient를 표준으로 사용했습니다.
3. 이벤트 기반 아키텍처 (SQS, Kubernetes): 서비스 간의 비동기 처리가 필요한 경우를 대비해 SQS를 도입하고, 이 모든 것을 쿠버네티스 위에서 안정적으로 운영할 수 있는 환경을 구축했습니다.

이러한 노력들 덕분에 저희 MSA의 기술적인 안정성은 높아졌습니다.

하지만 기술들은 근본적으로 ‘도메인 강결합으로 인한 점진적 MSA 전환의 어려움’을 해결해주지 못했습니다.

얽혀버린 도메인이라는 실타래를 푸는 것은 결국 저희의 ‘전략’에 달려있었습니다.

현실적인 방법을 찾아서

고민 끝에 저희는 두 가지 전략을 동시에 사용하는, 현실적인 방법을 선택했습니다.

1. 강결합된 도메인은 ‘함께’ 전환한다. (부분적 빅뱅방식) ‘점진적 전환’이라는 원칙을 일부 포기해야 했습니다. 아파트와 매칭, 이 두 도메인은 하나의 전환 단위로 묶어 동시에 MSA로 분리하기로 결정했습니다.

이는 단기적으로 더 많은 리소스를 투입해야 하는 부담이 있었지만, 장기적으로 불완전한 분리로 인한 데이터 불일치나 비즈니스 로직의 꼬임을 막는 유일한 방법이라 판단했습니다.

2. 레거시 서비스의 ‘수정’을 감수하고, 과도기를 설정한다. 전환 기간 동안 레거시와 신규 MSA는 공존해야 하는 경우도 있었습니다. 이 과도기 동안 데이터 정합성과 서비스 연속성을 유지하기 위해, 레거시 서비스의 코드 수정을 피할 수 없었습니다. 저희는 다음과 같은 과도기 전략을 사용했습니다.

• 레거시에서 신규 MSA 호출: 레거시 시스템의 일부 로직을 수정하여, 새로 분리된 MSA의 API를 직접 호출하도록 변경했습니다. 이는 모든 기능을 한 번에 옮기지 않고, 필요한 부분부터 점진적으로 신규 서비스의 기능을 사용하도록 만드는 역할을 했습니다.
• 데이터 이중 적재 및 동기화: 전환 기간 동안 데이터의 일관성을 유지하는 것이 가장 큰 숙제였습니다. 저희는 사용자의 요청이 들어왔을 때 레거시 DB와 신규 MSA의 DB에 데이터를 이중으로 적재(Dual Write)하는 방식을 택했습니다. 물론 이 방식만으로는 데이터 정합성을 100% 보장할 수 없기에, 주기적으로 배치 작업을 실행하여 두 데이터베이스 간의 데이터를 동기화하는 고단한 과정을 거쳤습니다.

이런 강결합을 가진 도메인이 아파트와 매칭의 케이스만 존재했던게 아니기 때문에 두가지 전략을 케이스마다 적절히 선택해야했습니다.

아파트, 매칭 도메인의 경우 함께 전환하기로 결정했습니다.

MSA 전환의 장단점

덕분에 저희는 많은 것을 얻었습니다.

• 명확한 책임과 자율성: 도메인별로 팀의 책임이 명확해지고, 각 팀은 독립적으로 기술 스택을 선택하고 배포할 수 있게 되었습니다.
• 향상된 확장성: 트래픽이 몰리는 특정 서비스만 독립적으로 확장할 수 있어 비용 효율적인 운영이 가능해졌습니다.

하지만 솔직히 단점도 명확했습니다.

• 개발 리소스 증가: 당연하게도 관리해야 할 서비스와 인프라가 늘어나면서 초기 개발 및 운영 리소스가 크게 증가했습니다.
• 분산 시스템의 복잡성: 이벤트 기반 아키텍처에서 장애가 발생했을 때, 어떤 서비스에서 시작된 문제인지 추적하고 디버깅하는 것이 훨씬 어려워졌습니다. (이 문제를 해결하기 위해 저희는 별도의 모니터링 시스템을 구축하기도 했습니다.)

그래서, MSA가 정답일까?

저는 팀에 합류했을 때부터 MSA 전환이 이미 결정이된 상태였습니다. 하지만 이 과정을 겪고 난 지금, 저는 “서비스가 충분히 크고 복잡하지 않다면, 굳이 MSA를 도입해야 할까?“라는 질문을 스스로에게 던지게 됩니다.

MSA는 은탄환이 아니라고 생각합니다. 오히려 복잡한 문제를 해결하기 위해 서비스의 복잡성을 감수해야 하는 트레이드오프에 가까운 것 같습니다.

특히 저희처럼 도메인 간 결합이 강한 레거시 시스템을 전환할 때는, ‘점진적 전환’이라는 이상적인 말 뒤에 숨겨진 수많은 난관을 마주할 준비가 되어 있어야 하는 것 같습니다.

만약 비슷한 고민을 하고 계신 분이 있다면, 기술적인 우아함이나 유행을 좇기보다는 우리 조직과 서비스의 ‘현실’을 냉정하게 진단하고, 가장 적합한 전략을 선택하시는 게 좋지 않을까 싶습니다.

긴 글 읽어주셔서 감사합니다.