| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 |
- 클린코드
- 그리디
- 애자일기법
- 코드
- ES
- JPA
- 개발
- 프레임워크
- kotlin
- 데이터베이스
- spring boot
- framework
- 읽기쉬운코드
- cleancode
- Baekjoon
- 자바
- API
- 엘라스틱서치
- Elasticsearch
- 코딩
- Java
- 백준
- Spring
- 그리디알고리즘
- 개발자
- 스프링
- AI
- 코딩테스트
- 알고리즘
- database
- Today
- Total
튼튼발자 개발 성장기🏋️
올영매장은 MSA 환경에서 흩어진 도메인 데이터를 어떻게 연동했을까?를 읽고 본문
데이터의 성질로 바라보는 MSA
올리브영 기술 블로그에서 올영매장의 MSA 데이터 연동 전략에 대한 글을 읽었다. 솔직히 처음에는 "또 MSA 얘기인가?" 하고 가볍게 봤는데, 읽다 보니 나도 모르게 공감과 비판을 하면서 재밌게 읽고 있었다. 내가 생각하는 이 글의 핵심은 단순히 "Redis를 써!!" 혹은 "Kafka를 써!!"와 같은 1차원 적인 기술적 방법이 아니라, "흩어진 데이터를 연동할 때에는 그 데이터가 어떤 성질을 가졌는지 먼저 바라봐야 한다!!"라는 것 같다.
특히나 "그냥 API로 가져오면 되는 것 아닌가?"라는 질문에 대한 답변 방식이 인상 깊었다. 실무에서 개발/비개발 직군 동료들로부터 가장 많이 듣는 질문 중 하나인데 너굴님은 Use Case, 변경 특성, 라이프사이클이라는 세 가지 관점을 통해 연동 방식을 분류했다. 이건 단순한 방법론이 아니라 데이터를 대하는 개인 혹은 조직의 철학 아닐까한다.
변경이 적은 데이터는 Cache-Aside가 정답일까?
프로모션 데이터 사례를 보면서 나도 예전 프로젝트가 떠올랐다. 변경이 거의 없는 설정값 같은 데이터를 매번 API로 호출해서 서버에 불필요한 부하를 줬었다. 그때는 단순히 TTL을 길게 잡은 Redis를 썼는데 올영매장팀은 더 정교하게 갱신이 필요한 시점에만 API를 호출하는 Cache-Aside 패턴을 적용한 것이다. 여기에 종료일이 지난 데이터를 주기적으로 정리하는 배치까지 함께 운영하니까 데이터 정확성과 시스템 효율성을 동시에 잡은 거지 않을까?
나는 이 부분에서 물음표 하나 던져보게된다. 이런 구조는 캐시와 원본 데이터 간의 정합성을 맞추는 로직이 복잡해지지 않을까? 특히 갱신이 필요한 시점을 어떻게 정의하느냐에 따라 로직이 달라질 것 같은데... 만약 운영 중 예상치 못한 데이터 변경이 발생했을 때 캐시를 즉시 무효화할 수 있는 메커니즘이 없다면 사용자는 잘못된 프로모션 정보를 보게 될 수도 있다. 나는 이런 경계 조건에서의 처리가 궁금하다. 혹시 캐시 무효화를 위한 별도의 이벤트 채널도 함께 운영하고 있는 건가..? 전 직장에서 배송상태 관련되어 비슷한 경험을 한 나로서는 굉장히 큰 관심이 생긴다.
Kafka와 Redis
또 흥미로웠던 부분은 픽업 주문 데이터를 다룬 방식이다. 변경이 잦은 데이터이면서도 무거운 데이터 특성 때문에 단순 캐싱도 문제고 단순 API 호출도 문제인 상황에서 Kafka Event Notification + Redis Key 필터링이라는 전략을 택한 것이다.
나는 이 방식이 단순히 "최신 기술을 썼다!!"라는 것보다 훨씬 실용적인 해결책이라고 생각한다. Kafka에는 상태 변경 알림만 경량으로 보내고 Redis에는 "이 고객은 API를 호출해야 한다"라는 플래그만 저장하는 방식은 마치 트래픽을 위한 스마트 게이트키퍼 같은 역할을 할 것이다. 이렇게 하면 올영매장에 접속하는 수많은 고객 중에서 실제로 픽업 주문이 있는 고객에 대해서만 주문결제 서버에 부하를 주니까 마이크로서비스 간의 강결합을 자연스럽게 느슨하게 풀어낸 것이다.
여기서 또 물음표가 생긴다. 만약 Kafka 이벤트는 정상적으로 수신했는데 그 사이 주문결제 서버가 일시적인 장애로 응답하지 못한다면? Circuit Breaker 패턴은 어떻게 적용했을지? 그리고 이벤트를 받아서 Redis에 Key를 저장하는 과정 자체가 실패하거나 메시지 중복 처리가 발생했을 때의 멱등성 처리는 어떻게 했을지? 블로그에서도 언급했듯이 메시지 중복과 유실에 대한 별도 포스트가 있다고 하니, 이따가 같이 봐야겠다.
마지막에 교훈 부분에서 [데이터 소비자가 연동 설계를 주도해야 한다]라는 내용에 대해서 고민해보게되었다. 실무에서 데이터를 제공하는 쪽은 보통 여러 팀의 요구사항을 받다 보니 범용적인 API만 제공하려는 경향이 있다. 하지만 실제로 그 데이터를 어떻게 쓸지, 얼마나 자주 갱신되어야 하는지를 가장 잘 아는 건 소비하는 쪽이다.
나는 이게 단순한 기술적 의사결정을 넘어 조직 문화의 문제라고 생각한다. 스쿼드 간에 내가 필요한 데이터는 내가 설계한다는 마인드가 없으면 결국 누군가는 불필요한 API 호출을 하거나, old 데이터를 보게 되는 상황이 나온다. 올영매장팀이 언급한 Stream-Aligned Team의 개념도 결국 비즈니스 흐름에 맞춰 팀이 자율적으로 데이터 연동을 설계할 수 있어야 진정한 MSA의 가치가 발휘된다는 뜻이라고 생각한다.
참고
'기타 > 타사 기술 블로그 읽기' 카테고리의 다른 글
| LLM을 이용한 서비스 취약점 분석 자동화 1편을 읽고나서 (0) | 2026.03.25 |
|---|---|
| 개발자는 AI에게 대체될 것인가를 읽고 나서 (0) | 2026.02.07 |
| 올리브영의 실시간 캠페인 타겟팅을 위한 CDC 전환기를 읽고나서 (0) | 2026.01.28 |
| T4 GPU 1장으로 일궈낸 올리브영의 Gemma 3 기반 sLLM 구축기를 읽고나서 (0) | 2026.01.26 |
| 배달대행사 API 연동과 장애 대응 - 오늘드림 서비스 개발기를 읽고나서 (0) | 2026.01.20 |