안녕하세요. 올리브영 온라인몰의 O2O(Online to Offline) 서비스를 담당하고 있는 너굴입니다. 👋
올리브영은 온라인과 오프라인의 경계를 허물고, 고객에게 유기적이고 심리스한 O2O 경험을 제공하기 위해 시스템 아키텍처를 지속적으로 발전시키고 있습니다. 이 혁신의 중심에 있는 것이 바로 ‘올영매장’ 서비스입니다.

올영매장은 올리브영 앱에서 가까운 매장을 찾고, 매장별 재고/행사/픽업 주문 현황 등을 확인할 수 있는 O2O 핵심 서비스입니다. 이 서비스는 Phase 1(올영매장 서비스 재정의)과 Phase 2(올영매장 UI/UX 리뉴얼)를 거쳐 지속적으로 고도화되어 왔으며, 저희는 최근 Phase 3(매장 행사 및 프로모션 고도화 개편)을 성공적으로 완료했습니다.

💡 올리브영이 매장 도메인을 어떻게 설계하고 현대화해 왔는지는 '10년 된 레거시를 현대화하다 시리즈'에서 확인할 수 있습니다. 그리고 이번 Phase 3의 프로덕트 기획 배경과 UX 설계 과정은 올영매장팀이 2026년 2월 27일 발행한 포스트 '매장을 찾는 과정을 설계한 올영매장 고도화 여정'에서 확인할 수 있습니다.

MSA 환경에서 데이터 통합의 복잡성과 데이터 연동 방식

올영매장에서는 고객에게 매장과 연관된 다양한 정보를 제공해야 합니다. 하지만 이러한 다양한 정보들은 현재 올리브영의 MSA(Microservice Architecture) 환경 내에서 각기 다른 담당 스쿼드에서 관리되고 있습니다. 구체적으로 저희가 연동해야 했던 핵심 데이터들은 다음과 같고, 이 외에도 여러 데이터가 각 영역별로 상이한 환경, 서버, 데이터양 등을 가지며 개별 영역 내에서 관리되고 있습니다.

• 스토어 스쿼드: 오프라인 매장 정보 관리

• 쿠폰증정 스쿼드: 오프라인 프로모션 정보 관리

• 주문결제 스쿼드: 온라인 픽업 주문 정보 관리

"그냥 API로 데이터를 가져오면 되는 것 아닌가?"라고 생각하실 수 있습니다. 물론 API 연동은 MSA 환경의 기본입니다. 하지만 매번 API를 호출하는 것이 항상 최선은 아닙니다. 데이터의 변경 빈도, 사용처, 유효 기간에 따라 더 효율적인 방법이 있을 수 있기 때문입니다. 저희는 불필요한 API 호출을 줄이면서도 고객에게는 빠르고 정확한 데이터를 제공하는 방법을 고민했습니다.

데이터 연동, 무엇을 고려해야 할까요?

1. 사용처(Use Case): 이 데이터를 서비스의 어디에서, 어떤 형태로 고객에게 제공하는가?

2. 변경 특성(Characteristic): 데이터가 얼마나 자주 갱신되며, 생성/수정/삭제가 어떻게 이루어지는가?

3. 라이프사이클(Lifecycle): 데이터는 언제부터 유효하고, 언제 만료되는가?

이 세 가지 관점이 연동 방식(캐시 vs 이벤트 vs API 직접 호출)을 결정하는 기준이 됩니다. 아래 두 가지 사례를 통해 구체적으로 살펴보겠습니다.

데이터 연동 전략 분석: 두 가지 핵심 사례를 중심으로

사례 1. 오프라인 프로모션 데이터 - 캐시(Redis) 전략

오프라인 프로모션 데이터는 그동안 매장에 직접 방문해야만 확인할 수 있었던 매장별 행사 및 할인 정보를 앱에서도 제공하기 위해 연동이 필요한 데이터였습니다.

1-1. 프로모션 데이터의 특성

(1) 데이터 사용처: 연동받은 데이터를 고객에게 실시간으로 제공해야 하므로, 트래픽 집중 시에도 높은 조회 성능과 낮은 지연이 요구됩니다.

(2) 데이터 변경 특성: 프로모션은 행사 전 미리 등록되고, 운영 중에는 자주 변경되지 않습니다(Low Change). Pull 기반 API 연동이 가능하지만, 갱신 빈도를 고려하지 않은 빈번한 호출은 서버 리소스 낭비를 초래합니다.

(3) 데이터 라이프사이클: 프로모션은 시작일과 종료일이 명확하게 정해져 있습니다. 이 특성을 활용하여 주기적인 배치를 통해 종료일이 지난 프로모션 데이터를 캐시에서 자동 삭제하는 방식으로 데이터 정확성을 유지합니다.

1-2. 연동 방식 비교

위 특성을 바탕으로, 서비스의 안정성과 효율성을 최대화하기 위한 연동 방식을 고민했고, 3가지 후보를 검토했습니다.

후보 방식	논의 내용	채택
필요할 때마다 API 호출	매장별 프로모션 데이터가 필요할 때마다 API를 호출하는 방식. 변경이 거의 없는 데이터를 빈번하게 호출하여 리소스 낭비 발생	❌
1일 1회 S3 저장 후 조회	변경이 적은 데이터 특성상 대안이 될 수 있으나, S3 전송 및 조회 과정 추가로 Latency 발생 및 아키텍처 복잡화	❌
갱신 필요 시 API 호출 + 캐시	갱신이 필요할 때만 API를 호출하고, 연동받은 데이터는 캐시(Redis)에 저장. 서버 부담 최소화 및 실시간에 가까운 응답 속도 제공	✅ 채택

1-3.최종 결정: Cache-Aside 패턴 적용

Cache-Aside는 애플리케이션이 캐시를 직접 관리하는 패턴입니다. 데이터 요청 시 먼저 캐시를 조회하고, 캐시에 없으면(Miss) 원본 저장소에서 가져와 캐시에 적재한 뒤 응답합니다. 저희는 이 패턴을 적용하되, 갱신이 필요한 시점에만 API를 호출하여 Redis에 캐싱하는 방식을 채택했습니다. 이를 통해 확보한 장점은 아래와 같습니다.

(1) 효율성: 갱신이 필요한 시점에만 API를 호출하여, 데이터 제공 서버의 부담을 최소화했습니다.

(2) 안정성: 캐시에서 데이터를 제공하므로, 트래픽이 급증해도 매장별 프로모션 정보를 안정적으로 응답할 수 있습니다.

(3) 정확성: 주기적인 배치를 통해 종료일이 지난 프로모션의 자동 삭제와 운영 중 변경된 프로모션의 캐시 갱신을 함께 처리합니다.

사례 2. 픽업 주문 데이터 - 이벤트(Kafka) + 캐시 하이브리드

픽업 주문 데이터는 고객이 주문한 픽업의 실시간 진행 상태를 올영매장에서 바로 확인할 수 있도록 연동이 필요한 데이터였습니다.

2-1. 실시간 픽업 주문 데이터의 특성

(1) 데이터 사용처: 주문 상태가 변경되는 순간 고객 화면에 즉시 반영되어야 하므로, 최고 수준의 실시간성(Real-Time Update) 이 요구됩니다.

(2) 데이터 변경 특성: 주문 이후 주문 취소, 픽업 준비 완료 등 상태 변경이 빈번하게 발생하며(High Change), 상품 정보·금액·고객 정보 등을 포함하는 무거운(Heavy) 데이터입니다.

(3) 데이터 라이프사이클: 픽업 주문 완료 시점부터 데이터를 제공하며, 픽업 수령 완료 혹은 주문 취소 이후에는 더 이상 제공할 필요가 없는 명확한 라이프사이클을 가집니다.

2-2. 데이터 연동 방식 결정: API 부하 절감과 실시간성 확보

픽업 주문 데이터는 빈번한 상태 변경(High Change)으로 인해 단순 캐싱만으로는 데이터 불일치(Staleness) 위험이 크고, 무거운 데이터 특성(Heavy Data)상 API를 반복 호출하면 제공 서버에 과도한 부하가 발생합니다. 즉, 실시간성 확보와 시스템 부하 절감을 동시에 달성해야 했습니다. 이를 위해 저희가 선택한 해법은 이벤트 주도 방식(Event-Driven)과 API 호출의 지능적 활용을 결합하는 하이브리드 전략이었습니다.

💡 Martin Fowler는 What do you mean by "Event-Driven"?에서 이벤트 기반 아키텍처를 Event Notification, Event-Carried State Transfer, Event Sourcing, CQRS 네 가지로 구분합니다. 저희가 채택한 방식은 이 중 Event Notification 패턴에 해당하며, Kafka의 대표적인 활용 사례이기도 합니다. (Apache Kafka Use Cases 참고)

저희가 Event Notification을 선택한 이유는, 전체 주문 데이터를 이벤트에 실어 보내는 대신 "상태가 변경되었다"는 알림만 받고, 필요할 때 API로 상세 데이터를 조회하는 것이 올영매장의 데이터 특성에 가장 적합했기 때문입니다. 구체적인 구현은 다음과 같습니다.

(1) 이벤트 수신 및 식별자 캐싱: 주문 상태가 변경되면 Kafka를 통해 이벤트가 발행됩니다. 올영매장 서비스는 이 이벤트에서 회원번호·주문번호 등 최소한의 식별자만 추출하여 Redis에 저장합니다. 전체 주문 데이터가 아닌, '상태가 변경된 주문의 Key 목록'만 캐싱하는 것이 핵심입니다.

(2) 캐시 키 기반 선택적 API 호출: 만약 올영매장에 접근하는 모든 고객의 트래픽마다 주문 API를 호출한다면, 데이터 제공 서버에 막대한 부하가 발생하게 됩니다. 이를 방지하기 위해 저희는 아래 이미지가 표현하는 로직과 같이 API 호출을 최적화했습니다. 즉, 고객이 픽업 대시보드에 접근할 때, 모든 요청을 주문 API로 전달하지 않습니다. Redis에 해당 고객의 Key가 존재하는 경우에만 API를 호출하여 최신 데이터를 조회합니다.

아래 시퀀스 다이어그램은 이 프로세스를 정리한 것입니다. Redis 캐시 조회 결과(Hit/Miss)에 따라 외부 API 호출 여부가 갈리는 분기 처리가 핵심입니다.

2-3. 최종 결정: Kafka Event + Redis Key 하이브리드

Kafka로 주문 상태 변경 이벤트만 경량 메시지로 전달받고, Redis에 API 호출 Key만 캐싱하는 하이브리드 구조를 적용했습니다.

(1) 효율성: 올영매장 접근 트래픽 중 Redis에 Key가 존재하는 고객의 요청에만 API를 호출하여, 데이터 제공 서버의 부담을 최소화했습니다.
(2) 안정성: 이벤트 주도 방식을 채택하여 주문 상태가 변경되는 즉시 감지할 수 있으며, 경량화된 Kafka 메시지로 통신 부하를 줄였습니다.
(3) 정확성: 실시간 이벤트(Kafka)를 기반으로 API를 호출하므로, 캐싱된 데이터가 아닌 항상 최신 상태의 픽업 현황을 고객에게 제공합니다.

💡 올리브영이 Kafka 기반 이벤트 처리에서 메시지 중복과 유실 문제를 어떻게 해결했는지는 Kafka 메시지 중복 및 유실 케이스별 해결 방법에서 상세히 다루고 있으니, 이벤트 기반 연동의 운영 안정성이 더 궁금한 분은 참고하셔도 좋습니다.

결론: 두 가지 교훈

1. 데이터 특성이 연동 전략을 결정한다

올영매장 Phase 3에서 저희는 변경이 적은(Low Change) 프로모션 데이터에는 캐시(Redis) 전략을, 변경이 잦은(High Change) 픽업 주문 데이터에는 Kafka 이벤트 + Redis 캐시 하이브리드 전략을 적용했습니다. 같은 "데이터 연동"이라도 사용처·변경 빈도·라이프사이클에 따라 최적의 방식은 달라집니다. 데이터의 특성을 먼저 분석한 덕분에 제공 서버의 부담은 줄이면서도, 고객에게는 빠르고 정확한 정보를 전달할 수 있었습니다.

2. 데이터 소비자가 연동 설계를 주도해야 한다

이번 개편에서 얻은 가장 큰 교훈은, 데이터를 소비하는 쪽이 사용처·변경 빈도·라이프사이클을 가장 잘 이해하고 있으므로 연동 방식의 의사결정을 주도해야 한다는 점입니다. 이는 MSA 환경에서 스쿼드 간 책임과 자율성을 확립하는 중요한 원칙이며, 비즈니스 흐름에 정렬된 팀이 자율적으로 의사결정하는 Stream-Aligned Team(Team Topologies)의 개념과도 맞닿아 있습니다.

결국 MSA 환경에서 가장 강력한 연동 도구는 특정 신기술이 아닌, 저희가 사용할 데이터의 본질을 꿰뚫어 보는 관점이었습니다. 저희의 고민이 비슷한 과제를 안고 계신 분들께 작은 힌트가 되었기를 바랍니다. 긴 글 읽어주셔서 감사합니다! 🙇‍♂️