MSA 환경에서의 DB 모델링

이전 글 2026.05.14 - [BackEnd/프로그래머스 데브코스] - 세미 프로젝트 시작  참고

세미 프로젝트 시작

 

도메인을 분리하는 과정은 생각보다 훨씬 어려웠다.

기존에는 하나의 DB 안에서 외래키와 트랜잭션으로 자연스럽게 해결하던 문제들을
MSA 환경에서는 다른 방식으로 접근해야 했기 때문이다.

특히 가장 크게 고민했던 부분은 데이터 정합성이었다.

현재 프로젝트는 하나의 DB를 사용하고 있었지만,
만약 실제 MSA 환경처럼 서비스별로 DB까지 분리된다면
서로 다른 서비스의 데이터를 Spring 백엔드 입장에서 어떻게 관리해야 하는지에 대한 의문이 생겼다.

기존처럼 외래키로 데이터를 강하게 연결할 수도 없고, 하나의 트랜잭션으로 묶는 것도 어려워지기 때문이다.

또 서비스 간 데이터 의존성이 생기는 경우, 데이터를 각 서비스에 중복 저장해야 하는지
아니면 다른 서비스를 호출해서 가져와야 하는지도 고민하게 되었다.

데이터를 중복 저장하면 관리 비용과 동기화 문제가 발생할 수 있고,
반대로 서비스 호출 방식은 네트워크 비용과 성능 저하 문제가 생길 수 있다고 생각했다.

이러한 고민들을 하면서 MSA는 단순히 서비스를 나누는 것이 아니라,
데이터 관리 방식 자체가 완전히 달라지는 구조라는 점을 처음 체감하게 되었다.

 

이런 고민들에 대해 어떤 식으로 해결했는지에 대한 얘기는 세미 프로젝트 부터 최종 프로젝트까지 이어지는

흐름 속에서 자연스레 풀어볼 생각이다.

 

MSA 설계 있어서 서툰 분이라면 이 글을 통해 설계하기에 앞서 한 번쯤 고민해보길 추천한다.

 

결과적으로 팀원 모두가 실제 MSA 환경을 깊게 경험해본 것은 아니었기에,

당장 모든 의문에 대한 답을 내리기보다는 프로젝트를 진행하며 직접 부딪혀보기로 결정했다.

 

또한 제한된 환경상 하나의 DB를 사용해야 했기 때문에 완전한 MSA 구조 보다는 도메인 분리를 의식한

멀티 모듈 형태에 가깝게 설계를 진행했다.

 

다만 서비스 간 결합도를 낮추기 위해 DB 레벨의 강한 외래키 제약 조건은 최대한 제거하는 방향으로 모델링을

진행했다.

 

모델링을 어느 정도 마친 뒤에는 도메인별로 모듈을 분리하는 작업을 진행했다.

그리고 다음으로 가장 중요했던 것은 각자 어떤 도메인과 역할을 맡을지 결정하는 일이었다.

나는 프로젝트 시작 전부터 이번 프로젝트를 통해 어떤 경험을 얻어가고 싶은지에 대해 계속 고민하고 있었다.

단순 CRUD 개발이나 기본적인 API 구현은 어떤 프로젝트에서도 경험할 수 있다고 생각했다.
그렇기에 이번 프로젝트에서는 MSA 환경에서만 얻을 수 있는 경험들에 더 집중하고 싶었다.

당시 내가 중요하게 생각했던 경험은 다음과 같았다.

1. AI 기능 구현 경험
2. Kubernetes 및 AWS 인프라 환경에 대한 이해
3. 주문/결제/환불 도메인을 통한 Kafka 기반 비동기 이벤트 처리 경험
4. API Gateway 기반 인증/인가 및 서비스 라우팅 구조에 대한 이해

그리고 나는 그중에서도 인증/인가 파트를 맡고 싶다고 이야기했다.

물론 Kafka나 인프라 역시 쉽게 경험할 수 없는 좋은 기회라고 생각했다.

하지만 취준생 입장에서 특정 환경에서만 사용되는 기술보다,

어떤 서비스에서도 공통적으로 중요하게 다뤄지는 인증/인가를 깊게 경험해보고 싶었다.

또한 당시 여러 기업들의 보안 사고 이슈를 보며 자연스럽게 인증과 보안에 대한 관심도 커지고 있었다.

그렇게 나는 인증/인가 도메인을 담당하게 되었고, 이 선택은 이후 프로젝트를 진행하면서
정말 많은 고민으로 이어지게 되었다.