🔄 마이크로서비스 데이터 공유 전략: 동기 호출을 넘어, 점진적 일관성으로

Sharing Data Between Microservices

마이크로서비스 아키텍처를 처음 접했을 때, “두 서비스는 같은 데이터베이스를 공유하면 안 된다”는 규칙을 지나치게 문자 그대로 받아들였던 기억이 납니다.

인터넷 여기저기서 “서비스 간 DB 공유는 금기다”라는 문장을 접했고, 당시에는 정말 맞는 말처럼 느껴졌습니다.

서비스는 자신의 데이터를 독립적으로 소유해야 하며, 외부에 노출된 API를 변경하지 않고도 내부 스키마를 자유롭게 수정할 수 있어야 하니까요.

하지만 시간이 지나고 나서야 이 규칙의 중요한 뉘앙스를 이해할 수 있었습니다.

이 원칙을 제대로 적용하기 위해서는 “데이터 소스(data source)를 공유하는 것“과 “데이터(data) 자체를 공유하는 것“을 구분해서 생각해야 합니다.

왜 데이터 소스를 공유하면 안 되는가

예를 들어 설명해볼게요. Products 서비스는 products 테이블과 그 안의 모든 레코드에 대한 소유권을 가지고 있어야 합니다.

이 서비스는 다른 팀이 제품 데이터를 조회할 수 있도록 GraphQL 쿼리(products)를, 새 제품을 생성할 수 있도록 createProduct 뮤테이션을 제공합니다.

즉, Products 서비스는 제품에 대한 단일 진실의 원천(Source of Truth)을 담당하며, 어떤 팀도 직접 이 DB에 접근해서는 안 됩니다.

다른 서비스가 데이터가 필요하다면 반드시 Products 서비스가 제공하는 공식 API 계약을 통해 요청해야 합니다.

직접 DB에 접근할 수 있도록 허용하는 순간, Products 서비스는 자신의 스키마를 마음대로 바꿀 수 있는 자유를 잃게 됩니다.

저도 과거에 이 규칙을 지키지 않아서 큰 고생을 했고, 그 후로는 이 원칙을 철저히 지키고 있습니다.

---

데이터를 공유하는 건 괜찮다

현실적으로, 서비스 간에 데이터를 공유하는 건 필수적입니다.

각 서비스는 자신이 소유한 도메인 외의 정보도 필요로 하기 때문이죠.

예를 들어, Trip 서비스는 탑승 이력을 제공하기 위해 승객(Passenger) 정보와 운전자(Driver) 정보를 필요로 합니다.

하지만 이 데이터는 각각 Passenger 서비스와 Driver 서비스가 소유하고 있죠.

즉, 데이터를 사용하는 주체는 다를 수 있지만, 필요한 데이터를 적절한 방식으로 “공유”하는 것 자체는 전혀 문제가 되지 않습니다.

중요한 건 데이터를 어떻게 공유하느냐입니다 — 직접 DB를 뒤지느냐, 아니면 계약(API, 이벤트 등)을 통해 가져오느냐의 차이죠.

동기 API 호출: 당연하고, 익숙했던 선택

Trip 서비스는 각 요청을 처리할 때 Passenger 서비스와 Driver 서비스에 동기적으로 데이터를 요청합니다. 예를 들어 getTrips 요청이 들어오면, 필요한 데이터를 각 소유 서비스로부터 실시간으로 받아오는 구조죠.

이 방식의 가장 큰 장점은 명확합니다 — 항상 최신의 데이터를 가져올 수 있다는 점입니다.

요청자가 받아보는 데이터는 강한 일관성(strong consistency)을 보장받으며, 말 그대로 ‘진실의 원천(Source of Truth)’로부터 직접 받은 가장 “신선한” 정보입니다.

---

강한 일관성에 집착했던 초기의 우리

저를 포함한 많은 팀들이 마이크로서비스를 처음 도입했을 때는 이 동기 요청/응답 모델이 너무나도 자연스럽게 느껴졌습니다.

• 필요한 데이터가 있다 →
• 어디서 가져올지 안다 →
• 그 서비스에 API 호출 →
• 즉시 응답으로 데이터를 받는다

이 흐름은 직관적이고, 특히 한 시스템 안에서 동작할 때는 아무런 문제가 없어 보였습니다.

그리고 무엇보다도 우리는 “강한 일관성이 있는 데이터”를 제공하는 것을 절대적인 기준으로 여겼습니다.

“최신이 아닌 데이터를 어떻게 제공할 수 있지?”

“실시간이 아닌 정보는 사용자에게 거짓말 아닌가?”

라는 생각이 머릿속에 박혀 있었죠.

그래서 우리는 이 구조를 진리처럼 여겼고, 다른 방식은 생각조차 하지 않았습니다.

동기 호출과 강한 일관성은 확장되지 않는다

동기 요청(synchronous request)과 강한 일관성(strong consistency)에 지나치게 의존하는 아키텍처는 확장성에 한계가 있습니다.

항상 진실의 원천(Source of Truth)으로부터 데이터를 직접 가져오는 것이 항상 가능하거나, 반드시 필요한 건 아닙니다.

앞서 설명한 Trip 서비스 예시는 언뜻 보면 깔끔해 보입니다.

하지만 현실에서는 시스템이 그렇게 단순하게 유지되는 경우는 드뭅니다.

시간이 지나면 새로운 서비스가 계속 생겨나고, 이들은 기존 서비스의 데이터를 필요로 하게 됩니다.

그리고 여전히 모든 데이터를 동기적으로 요청하는 패턴을 고수하다 보면, 어느 순간 서비스 간 요청들이 얽히고설킨 복잡한 거미줄이 되어버립니다.

그 결과는?

서로 의존적인 요청들이 꼬리에 꼬리를 물고, 전체 시스템의 응답 속도와 안정성을 갉아먹는 병목으로 이어집니다.

서비스 간 연쇄 요청의 덫

다음은 실제 마이크로서비스 환경에서 자주 발생하는 시나리오입니다:

1. 사용자가 챌린지를 완료하면 completeChallenge 뮤테이션을 Challenge 서비스에 보냅니다.
2. Challenge 서비스는 완료 정보를 저장한 뒤, Leaderboard 서비스에 알립니다.
3. Leaderboard 서비스는 새로운 리더보드를 생성하기 위해 User 서비스에 사용자 이름과 아바타를 요청합니다.
4. 새로운 리더가 생기면, 이를 Notification 서비스에 전달합니다.
5. Notification 서비스는 해당 리더보드에 포함된 사용자들의 이메일 주소를 얻기 위해 다시 User 서비스에 요청합니다.

이 시나리오에서 모든 서비스가 User 서비스에 의존하고 있다는 걸 알 수 있습니다.

만약 User 서비스가 다운된다면?

거의 모든 기능이 멈추게 되며, 단순히 한 서비스의 장애가 전체 시스템의 장애로 확산될 수 있습니다.

이러한 구조에서는 User 서비스의 고가용성 보장이 필수입니다.

더 많은 리플리카를 유지하고, 성능 좋은 데이터베이스를 붙여놔야 하죠.

즉, 의존도가 높아질수록 운영 비용과 장애 전파 위험도 같이 올라갑니다.

---

서비스 호출 체인의 숨겨진 비용

서비스 간 호출이 체인을 형성할 때, 호출 단계가 하나 늘어날수록 지연(latency)은 기하급수적으로 증가할 수 있습니다.

각 서비스가 자신의 의존 서비스로 또 다른 요청을 보내게 되면,

전체 요청 경로는 깊어지고, 사용자 응답 시간은 길어지며,

경우에 따라 시스템 전체의 SLA(Service Level Agreement)를 떨어뜨릴 수 있습니다.

예를 들어, SLA가 각각 99.9%인 5개의 서비스가 직렬로 연결되어 있다고 가정하면,

전체 시스템의 복합 SLA는 약 99.5%가 됩니다.

이는 연간 약 2일의 다운타임을 의미합니다.

(계산: 0.999⁵ ≈ 0.995 ≒ 2일)

---

정말 최신 데이터가 필요한가?

이 문제를 해결하기 위한 출발점은 매우 단순합니다:

👉 서비스가 정말로 최신 데이터를 필요로 하는가?

• Notification 서비스는 그렇다고 볼 수 있습니다. 사용자 이메일 주소가 변경되었는데도 이전 주소로 메일을 보낸다면, 알림이 전달되지 않을 위험이 있으니까요.
  
• 반면에 Leaderboard 서비스는 굳이 최신 아바타나 닉네임을 가져올 필요는 없습니다. 조금 이전의 데이터라 해도, 기능적으로 큰 문제가 발생하지 않기 때문이죠.
  

---

데이터 일관성 요구는 서비스마다 다르다

이처럼 각 서비스마다 요구하는 데이터 일관성 수준은 다릅니다.

어떤 서비스는 실시간 데이터가 필수지만, 어떤 서비스는 약간의 지연된 데이터로도 충분합니다.

이 차이를 인지하고, 각 상황에 맞는 데이터 공유 전략을 세워야 합니다.

그것이 바로 탄탄하고 확장 가능한 분산 시스템을 만드는 핵심입니다.

결국은 Eventual Consistency

제 커리어에서 전환점이 된 순간은 바로 이것이었습니다:

서비스는 다른 서비스의 데이터를 자체 DB에 복제해서 유지할 수 있다는 사실을 이해했을 때입니다.

물론 이런 접근에는 책임이 따릅니다.

이 데이터를 이벤트(event)나 폴링(polling)을 통해 지속적으로 갱신해야 하며, 일정 시간 동안 데이터가 최신이 아닐 수 있다는 것을 감수해야 합니다.

하지만 중요한 건, 결국엔 데이터가 최신 상태로 수렴한다는 것입니다.

완벽한 실시간은 아니지만, 항상 어느 시점에선 갱신된 상태로 따라잡을 수 있다는 보장.

그게 바로 Eventual Consistency의 핵심입니다.

---

날씨 API와 캐시의 깨달음

이 개념이 저에게 완전히 와닿았던 건, 날씨 API를 떠올렸을 때였습니다.

사용자가 매번 날씨 정보를 확인할 때마다 외부 API에 요청을 보내는 대신, 저는 하루에 몇 번 정도 날씨 데이터를 수집해서 DB에 저장해두고,

그걸 사용자에게 제공했습니다.

생각해보세요 — 사용자 입장에서 3시간 전의 날씨 정보라도 보는 데 크게 지장은 없습니다.

항상 최신일 필요는 없었던 거죠.

이 경험이 강한 일관성 대신 점진적 일관성을 선택할 수 있는 조건을 명확하게 이해하게 만든 계기였습니다.

---

Challenge 예시에 적용해보자

이제 다시 Challenge 예시로 돌아가 보겠습니다.

User 서비스에 대한 동기적 의존을 줄이고, 각 서비스가 필요한 만큼 User 정보를 자체적으로 유지하면 어떨까요?

• ✅ Leaderboard 서비스는 사용자 아바타와 닉네임을 위한 정보를 로컬에 유지할 수 있습니다. 사용자에게 약간 오래된 이미지가 보이더라도 대부분의 경우 큰 문제가 되지 않습니다.
  
• ✅ Challenge 서비스도 마찬가지입니다. 예를 들어 getChallengeDetails 쿼리에서 참여자의 정보를 보여줘야 한다면, 자체 테이블에 복제된 사용자 데이터를 기반으로 응답할 수 있습니다.
  
• ⚠️ Notification 서비스는 조금 더 민감한 상황입니다. 이메일이 잘못된 주소로 가면 안 되니까요. 하지만 이 서비스 역시 UserUpdated 이벤트를 구독해서 이메일 정보를 가능한 최신 상태로 유지함으로써, 완벽하지는 않아도 충분히 신뢰할 수 있는 수준으로 데이터를 관리할 수 있습니다.
  

---

결국은, 복제 + 이벤트 + 캐싱

오늘은 깊이 다루지 않았지만, 서비스 간 데이터 공유 방식에는 여러 방법이 있습니다.

그중 하나는 이벤트 소싱(event sourcing)과 로컬 캐싱(materialized view)을 결합하는 것입니다.

이런 방식으로 구성된 아키텍처는 확장 가능성, 회복탄력성, 응답 속도 측면에서 매우 강력합니다.

다음 포스트에서는 이 아키텍처를 실제로 어떻게 설계하고 적용할 수 있을지에 대해 자세히 다뤄보겠습니다.

지금까지의 내용을 한 문장으로 정리하면 이렇습니다:

모든 데이터가 실시간일 필요는 없다. 중요한 건 서비스의 목적에 맞는 일관성 수준을 선택하는 것.

🔚 마무리하며

마이크로서비스를 처음 접했을 때 저처럼 “데이터를 공유하면 안 된다”는 문장을 너무 문자 그대로 받아들이고 있는 개발자들이 많습니다.

하지만 이 원칙은 정확히 말하면 “진실의 원천(Source of Truth)을 공유하면 안 된다”는 의미일 뿐입니다.

다른 서비스가 소유한 데이터를 로컬에 복사하여 유지하는 것은 전혀 문제가 되지 않으며,

이는 오히려 Eventual Consistency(점진적 일관성)의 철학을 충실히 반영한 접근입니다.