안녕하세요. 인벤토리 스쿼드 백엔드 개발자 펭귄대장입니다!
오늘은 저희 올리브영이 SpringCamp2025에 후원사로 참가한 소식을 전해드리려고 합니다.
SpringCamp 2025
저희 올리브영은 AWS Summit, DASH, FEConf 등 국내외 다양한 개발자 컨퍼런스/커뮤니티에 참여해 왔는데요.
이번엔 KSUG(한국 스프링 사용자 모임)에서 주최하는,
국내 대표 백엔드 컨퍼런스 중 하나인 SpringCamp 에 골드🏅 후원사로 참여하여
물류 시스템 개선기 발표와 홍보 부스 운영을 통해 약 500명의 외부 개발자 분들과 소통할 수 있는 기회를 가졌습니다.
Part 01. 기술, 공유하고 소통하다 : 물류 시스템 개선기 발표
명실상부 대한민국 대표 헬스&뷰티 스토어인 올리브영은 매일 수많은 트래픽과 데이터를 처리하고 있습니다.
특히 매 올영세일마다 매출 신기록을 갱신하고 있고, 세일 기간의 트래픽과 데이터의 양은 기하급수적으로 증가하고 있는데요.
이러한 상황 속에서 시스템의 실시간성과 확장성을 위해,
1. 기존의 EAI(Enterprise Application Integration) + 배치 기반 구조로 동작하던 물류 IF를 AWS MSK(Kafka) 기반의 실시간 처리 시스템으로 전환하고,
2. RDB 중심의 재고 시스템을 Redis 기반으로 개선한 경험을 소개했습니다.
발표는 45분간 진행되었고, 정말 많은 분들이 관심을 가져주셨습니다.
약 150석의 좌석이 가득 차고도, 자리가 모자라 발표장 뒤쪽에 서서 듣는 분들이 많아 뒷쪽 벽이 보이지 않을 만큼 큰 호응을 얻었습니다.
행사 종료 후 진행된 설문에서도 '가장 유익했던 세션' 중 하나로 꼽히는 기쁨도 누렸습니다. 🙌
발표 후에는 많은 분들이 홍보 부스를 찾아주셔서 발표 내용에 대한 질문과 의견을 나누는 시간을 가졌습니다.
다른 발표와 시간이 겹쳐 홍보 부스에서 질문에 대한 답변을 드리지 못한 분들도 계셨는데요.
그중, 많이 겹쳤던 질문들을 위주로 Q&A를 정리해 보았습니다.
물류 시스템 개선기 관련 Q&A
DLQ(Dead Letter Queue) 관련 문답
Q. "DLQ를 사용하면 순서 보장이 어려웠을 텐데, 이런 문제가 없었는지, 어떤 전략이 있었는지 궁금합니다."
A. "순서 보장이 중요한 토픽은 DLQ를 사용하는 대신 애플리케이션 수준에서 재처리 전략을 통해 예외 상황을 처리했습니다.
DLQ에 메시지가 쌓이는 경우에는 우선 오류 원인을 분석하고, 재처리가 필요한 메시지에 한해 순서를 고려하여 처리하도록 설계했습니다.
또한, 순서 보장이 필요한 경우 메시지 키 기반으로 Kafka 파티션을 구성하여 동일한 키의 메시지는 항상 같은 파티션으로 전송되도록 함으로써 Kafka의 파티션 수준 순서 보장을 활용하고 있습니다."
KAFKA 운영 관련 문답
Q. "Kafka를 실무 환경에서 안정적으로 운영하기 위해 고가용성을 확보하는 데 도움이 되었던 방법이나 운영 상의 노하우가 있을까요?"
A. "카프카 운영 시 메시지 중복과 유실 문제가 발생할 수 있고, 이를 방지하는 것이 안정적인 카프카 운영의 핵심이라고 할 수 있는데요.
Kafka 메시지 중복 및 유실 케이스별 해결 방법
포스팅을 참고해 주시면 좋을 것 같습니다."
오프라인 재고 시스템 개선기 관련 Q&A
REDIS 데이터 정합성 관련 문답
Q. "Oracle과 Redis 간 데이터 정합성이 틀어지면 어떻게 처리하나요?"
A. "정합성 이슈에 대비하여 Oracle과 Redis 간 데이터 정합성을 주기적으로 비교·검증하는 배치 작업을 운영하고 있습니다.
이 과정에서 정합성 문제가 발생하면, Datadog을 통해 Slack 알림을 전송하여 실시간으로 대응할 수 있도록 구성되어 있습니다.
문제가 확인된 경우에는 Oracle 데이터를 기준으로 Redis 데이터를 업데이트하여 정합성을 복구합니다.
또한, 매장 운영이 중단되어 재고 변경이 없는 새벽 시간대에 Oracle 데이터를 기준으로 Redis 데이터를 일괄 업데이트 및 생성하여,
정합성 오차가 발생하더라도 새벽에 자동 복구될 수 있도록 설계되어 있습니다."
재고 이력 관련 문답
Q. "재고 도메인 특성상 이슈 대응을 위해 특정 시간에 몇개의 재고가 있었는지와 같은 이력 관리도 중요하다고 생각하는데,
재고 이력 관리는 어떻게 하고 있나요?"
A. "맞습니다. 과주문 이슈, 입고 이슈 등의 대응을 위해 재고 이력 관리는 매우 중요한데요.
기존에 여러 테이블, 시스템, 백오피스 화면에서 재고 이력을 관리하고 있어 내부 사용자들의 혼란이 많았습니다.
또한 조회 시점의 재고 수량만 알 수 있는 상태였고, 특정 시점의 재고 수량을 조회하려면 수많은 테이블을 조인하고,
너무나도 복잡한 쿼리를 작성해야 해서 이슈 대응이 매우 힘들었습니다..
이런 문제들을 해결하고, 재고 이력 관리의 일관성을 갖기 위해 OpenSearch를 기반으로 EFK스택을 구축하여 재고 변경 이력을 통합 관리하고 있습니다.
Oracle 에 재고가 변경되는 시점에 Redis 에 데이터를 적재하고 있으며 이때 OpenSearch 에 재고 변경 이력을 함께 저장하고 있는 구조 인데요.
Fluentbit sidecar pattern 을 사용하여 구축했는데 이는 AWS OpenSearch 기반 EFK STACK 구축기
포스팅을 참고해주시면 좋을 것 같습니다."
기타 성능/부하 관련 문답
Q. "전자라벨의 경우 특정 매장의 모든 상품 재고를 필요로 하여,
Redis Hash 구조에서 매장별 키(store key)를 생성하여 상품코드를 해시 필드로, 상품의 재고 수량을 해시 value로 하여 데이터셋을 구성하셨다고 했는데요.
해당 해시키를 사용한다고 해도, 올리브영의 천 개가 넘는 모든 매장에서 모든 상품의 재고를 조회하게 되면 성능 이슈나 부하 문제가 발생했을 것 같은데,
관련해서 성능 이슈는 없으셨나요?"
A. "일부 매장의 전 상품 재고를 조회할 경우 부하가 크지 않아 문제가 되지 않지만,
예상하신 것처럼, 전자라벨처럼 주기적으로 모든 매장의 모든 상품 재고 수량을 조회하는 전자라벨의 요청은 서버나 REDIS 입장에서 큰 부하 요소입니다.
그래서 매장이 오픈되기 전인 새벽 시간엔 매장 해시키를 사용하여 모든 매장의 모든 상품 재고를 조회하는 API를 사용하고,
트래픽이 많은 일과 시간엔 변경된 재고 수량만 반환하는 API를 사용하고 있습니다.
관련하여 "재고의 변동을 시계열 데이터로?!"
포스팅을 참고해주시면 좋을 것 같습니다."
발표 내용은 추후, Spring Camp 홈페이지 에 업로드될 예정이니,
발표 자료를 놓치신 분들은 해당 링크를 통해 발표 자료와 발표 영상을 확인하실 수 있습니다.
Part02. 사람, 소통하고 연결하다 : 홍보 부스 현장
01. 홍보부스 운영 📢
발표 외에 홍보 부스도 운영하여, 올리브영의 개발 문화와 조직 문화를 소개하는 시간을 가졌습니다.
올리브영의 백엔드 개발자들이 "오늘드림", "올영매장찾기" 등 직접 자신이 개발한 서비스를 소개하고,
개발하면서 사용한 기술 스택과 개발 환경을 소개하며, 올리브영의 개발 문화를 알리는 시간을 가졌습니다.
