올리브영 테크블로그

배송최적화 시스템 구축기 Part 01. 올리브영이 멀티 센터 체제로 배송 시간을 14시간 단축한 과정

Fri, 06 Mar 2026 00:00:00 GMT

안녕하세요. 배송최적화 스쿼드에서 백엔드 개발을 담당하고 있는 리아입니다.🐣

오늘은 저희 스쿼드에서 최근까지 진행해온 배송최적화 시스템 구축 과정을 공유하려 합니다.
서비스의 비약적인 성장에 발맞춰 단일 센터 구조에서 멀티 센터 구조로 전환하는 과정은 단순한 인프라 확장을 넘어, 기존의 경직된 주문 처리 아키텍처를 전면 재설계해야 하는 복잡하고도 흥미로운 과제였습니다.

저희 스쿼드가 어떤 고민을 거쳐 지금의 구조를 설계하게 되었는지, 그 과정의 기록을 시작해보겠습니다.

1. 왜 새로운 시스템이 필요했을까?

올리브영은 최근 몇 년간 비약적인 성장을 이어가고 있습니다. 2024년 연간 매출과 영업이익 모두 전년 대비 20% 이상 성장하였으며, 특히 온라인 사업은 가파른 성장세를 보이며 전체 매출의 30% 이상을 차지하게 되었습니다.

🔗 관련 자료: 소비자가 만드는 신문, "CJ올리브영 '옴니채널 전략' 통했다...온라인 매출 비중 30% 돌파, 전체 매출도 '쑥쑥'"

2021~2025년 올리브영 매출 추이

🏢 단일 센터 체제의 한계와 멀티 센터로의 전환

올리브영은 이러한 가파른 성장세를 뒷받침하기 위해 물류 인프라를 다각화해 왔습니다. 양지센터 중심의 단일 센터 체제를 넘어, MFC(Micro Fulfillment Center, 도심형 물류 센터) 확대와 오늘드림 서비스 고도화를 병행하며 물류망의 범위를 넓히는 데 주력했습니다.
이러한 물류 인프라 확장의 연장선으로 2025년 1월에는 비수도권 배송 효율을 극대화할 경산센터를 온라인몰 배송에도 본격 투입하며 전국 단위 멀티 센터 체제를 향한 물리적 토대를 마련했습니다

🔗 관련 자료: 올리브영 뉴스룸, "CJ올리브영, 비수도권 물류 허브 ‘경산센터’ 본격 가동"

올리브영 전국 물류망(출처: 올리브영 뉴스룸)

하지만 단순히 물리적인 센터를 늘리는 것만으로는 문제가 해결되지 않았습니다. 오히려 늘어난 센터를 효율적으로 활용하지 못하는 기존 시스템의 구조적 한계가 하나둘 드러나기 시작했습니다. 🥲

분배 로직의 부재로 인한 양지센터 과부하
- 센터가 확장되었음에도 주문은 여전히 기존 방식대로 양지센터로 인입되었습니다. 두 개의 센터가 존재함에도 특정 센터에만 물량이 쏠리는 현상이 반복되었고, 결과적으로 인프라 확장 효과를 체감하기 어려운 구조가 지속되었습니다.
수작업 기반의 비효율적인 물량 재분배
- 양지센터의 부하를 덜기 위해 경산센터로 주문을 넘길 때마다 운영자는 매번 주문 데이터를 엑셀로 추출하여 수동으로 할당해야 했습니다. 이러한 인적 자원에 의존하는 수작업 기반의 프로세스는 물류 전반의 운영 효율을 저하시키는 핵심 요인이 되었습니다.
지속되는 배송 지연과 고객 경험 저하
- 결국 센터 확장이라는 변화에도 불구하고 이를 뒷받침할 시스템의 부재로 배송 지연은 해소되지 않았고, 고객 문의와 주문 취소 증가라는 고객 경험 저하로 이어졌습니다.

결국 물류 현장의 비효율을 걷어내고 거점 확장의 효과를 극대화하기 위해서는 전체 주문 흐름을 실시간으로 제어할 새로운 시스템이 필요했습니다.
이를 위해 저희 스쿼드는 배송최적화 시스템을 구축하게 되었습니다.🚀

2. 기존 시스템은 어떻게 되어 있었나 (As-Is)

기존 주문 처리 시스템 구조 (As-Is)

기존 주문 처리 구조는 앞서 설명해 드린 대로 양지센터 중심의 단일 센터 체제를 전제로 설계되어 있었습니다.
고객이 주문/결제를 완료하면 출하지시 MQ(Message Queue, 메시지 큐)를 통해 주문관리시스템(OMS) → 운송관리시스템(TCS) → 창고관리시스템(WMS) 순으로 하나의 흐름을 타고 내려가며, 최종적으로 양지센터에서만 출고가 이뤄지는 구조였습니다.

💡 OMS, TCS, WMS 등 올리브영 물류 시스템의 전반적인 구조가 궁금하시다면, "올리브영 물류 시스템의 이해" 포스팅을 참고해주세요.☺️

단일 센터 체제는 출고처가 고정되어 있었기에 별도의 복잡한 로직 없이 선형적 구조만으로도 안정적인 운영이 가능했습니다.
하지만 운영하는 센터가 늘어나는 순간, 단일 센터 중심의 경직된 주문 처리 구조는 다음과 같은 구조적인 한계를 드러내며 명확한 페인 포인트(Pain Point)가 되었습니다.

데이터 단절로 인한 판단 불가
- 주문 단계에서 실시간 재고나 센터별 가동률(CAPA) 같은 물류 데이터를 즉시 확인하고 의사결정에 반영하기 어려웠습니다.
경직된 주문 흐름
- 기존 창고 시스템(WMS)은 확정된 주문을 처리하는 데 특화되어 있어, 운영 상황에 따라 출고처를 유연하게 변경하거나 재배정하는 기능이 미비했습니다.
정책 대응의 높은 비용
- 새로운 배송 정책이나 센터별 특이 사항이 발생할 때마다 각 시스템의 로직을 직접 수정해야 했기에, 급변하는 비즈니스 요구에 즉각 대응하기엔 한계가 있었습니다.

결국 기존 센터와 신규 센터 사이에서 최적의 출고처를 실시간으로 찾아줄 새로운 판단 레이어(Control Tower) 가 절실해졌습니다.

3. 무엇이 달라졌나 (To-Be)

앞서 살펴본 구조적 한계를 극복하고 확장된 물류 인프라를 지능적으로 제어하기 위해, 기존의 선형적인 주문 흐름 사이에 '지능형 판단 레이어'를 추가하여 데이터 흐름의 제어권을 확보하는 설계를 진행했습니다.
단순히 시스템 하나를 추가하는 것을 넘어, 주문 생성부터 출고에 이르는 전체 데이터 파이프라인에서 의사결정의 주체를 재정의한 것이 이번 설계의 핵심입니다. 이를 위해 다음과 같은 네 가지 핵심 설계 원칙을 세웠습니다.

로직의 파편화를 방지하는 '판단 레이어의 통합'
- 기존에는 주문 시점에 단순히 실시간 재고 유무만을 확인하여 출고처를 결정하는 단편적인 방식을 사용했습니다.
- 새로운 시스템에서는 재고뿐만 아니라 센터별 실시간 가동률(CAPA), 고객 주소지 기반의 배송 권역 정보 등 파편화된 운영 변수를 한곳에 모아 종합적으로 판단합니다.
- 이를 통해 OMS와 WMS 사이에서 복잡한 분배 로직을 전담 처리하는 독립적인 엔진을 구축했습니다.
운영 리스크를 최소화하는 '확정 전 단계의 제어'
- 설비 할당 이후 수정이 어려운 WMS의 경직성을 고려하여, 출고 지시 데이터가 넘어가기 직전 단계에서 모든 검증을 마치는 구조를 택했습니다.
- 잘못된 센터 할당이 물류 현장의 병목으로 이어지지 않도록 실시간 재고와 CAPA를 다각도로 검증하는 독립적인 검증 레이어 역할을 수행합니다.
비즈니스 속도에 대응하는 '정책 가변성 확보'
- 상시로 변하는 운영 정책을 코드 수정 없이 반영할 수 있도록 룰 기반(Rule-based) 엔진 구조를 도입했습니다.
- 특정 센터 우선 출고나 이벤트성 정책 변경 시에도 시스템 배포 없이 DB 설정값 변경만으로 유연한 대응이 가능합니다.
고객 가치를 지키는 '데이터 기반의 SLA 보장'
- 센터별 가동률과 배송 권역 정보를 실시간 데이터로 판단하여 리드타임을 최소화하는 최적의 출고처를 도출합니다.
- 모든 시스템 판단의 기준은 배송 리드타임 최소화라는 본질적인 가치에 집중합니다.

이러한 원칙을 바탕으로 주문 관리(OMS)와 창고 관리(WMS) 사이에 배송최적화 시스템(Delivery Optimization System)을 배치하여, 주문 완료 후 실제 물류 센터로 출하지시 데이터가 넘어가는 시점에 각 주문별 최적의 출고처를 실시간으로 판단하도록 했습니다.

개선된 주문 처리 시스템 구조 (To-Be) - 배송최적화 시스템이 최적의 센터를 동적으로 결정

고가용성을 고려한 배송최적화 시스템 아키텍처

결과적으로 OMS는 복잡한 분배 로직을 직접 인지할 필요 없이, 배송최적화 시스템과의 API 연동만으로 실시간 물류 상황이 반영된 최적의 출고처를 할당받게 되었습니다. 주문 프로세스의 중심에 위치한 시스템인 만큼, 대규모 트래픽 부하 속에서도 100ms 이내의 빠른 응답 속도와 고가용성을 보장하기 위해 아키텍처 내부에 설계한 핵심 기술 요소들을 이어지는 섹션에서 하나씩 살펴보겠습니다.

4. 배송최적화 시스템 (Delivery Optimization System)

배송최적화 시스템은 유연한 물류 운영을 위해 크게 주문분배와 주문이관이라는 두 가지 핵심 기능을 수행합니다.

4-1. 실시간으로 최적의 출고처를 결정하는 '주문분배(Order Distribution)'

배송 정책은 비즈니스 상황과 물류 전략에 따라 유연한 확장성이 요구되는 영역입니다.
최적의 출고처를 판단하기 위해 각 분배 로직을 독립적인 전략(Strategy) 단위로 모듈화하고, 이를 조합해 최종 의사결정을 내리는 룰 엔진(Rule Engine) 구조를 채택했습니다.

특히 배송최적화 시스템은 일정 주기로 인입되는 대량의 출하지시 주문들을 지연 없이 처리하는 것이 핵심입니다.
도메인 특성상 주문 건들이 특정 시점에 한꺼번에 내려오기 때문에, 수만 건의 주문이 일시에 유입되더라도 전체 프로세스가 정체되지 않아야 합니다. 이를 위해 개별 주문에 대한 판단 로직을 100ms 이내로 최적화하여 대규모 트래픽 환경에서도 성능 병목(Bottleneck) 없는 안정적인 처리가 가능해졌습니다.

이러한 고성능과 회복 탄력성을 뒷받침하기 위해 시스템 내부에 설계한 핵심 장치들은 다음과 같습니다.

장애 격리를 위한 서킷 브레이커(Circuit Breaker) 적용
- 장애 전파 방지: Resilience4j 기반의 서킷 브레이커를 적용하여, 배송최적화 시스템의 부하가 상위 시스템(OMS)으로 전이되는 현상 차단
- 시스템 안정성 확보: 특정 구간의 과부하가 전체 주문 프로세스의 결함으로 이어지지 않도록 회복 탄력성 확보
데이터 특성에 따른 다중 캐싱 전략:
- Local Cache(Caffeine): 센터별 가용량(Capacity) 등 정적 기준 정보를 서버 메모리에 적재하여 네트워크 통신 지연(Latency) 최소화
- Remote Cache(Redis): 실시간 출고량(Throughput) 등 동적 데이터는 Redis로 관리하여, 분산 환경에서의 데이터 정합성 유지 및 100ms 이내의 판단 성능 보장
전략 패턴 기반의 필터링 파이프라인
- 런타임 전략 결정: 복잡한 if-else 구조 대신, DB 설정값에 따라 런타임에 실행 전략이 결정되는 파이프라인 구축
- 운영 정책의 유연한 변경: 개별 전략(Filter/Score)의 조합을 DB 값 변경만으로 제어하여, 코드 수정이나 배포 없는 운영 정책의 유연성 확보
💡 최적의 센터를 찾아가는 프로세스
1단계. SKU(Stock Keeping Unit, 상품 관리 코드) 및 재고 보유 확인: 해당 상품 재고를 보유한 센터 판별 (경산/양지)
2단계. CAPA(Capacity, 처리 용량) 여유 확인: 재고는 있지만 일일 처리 한계를 초과한 센터는 제외
3단계. 우편번호 기준 권역 매칭: 고객 주소지 기반으로 배송 권역 확인, 최적 센터 우선순위 결정
4단계. 출하지시 MQ 전송: 최종 선택된 센터로 출하 지시 메시지 발행

배송최적화 시스템의 주문 처리 워크플로우

4-2. 운영 변수에 유연하게 대응하는 '주문이관(Order Transfer)'

주문분배가 초기 최적화를 담당한다면, 주문이관은 출고처 배정 이후의 부하를 조절하는 유동성 확보 의 핵심입니다.
특정 센터에 물량이 과도하게 집중될 때, 여유가 있는 다른 센터로 물량을 이동시켜 물류 적체를 해소하는 역할을 합니다.

특히 이 기능은 양지센터의 부하를 경산센터로 분산할 때 진가를 발휘합니다. 과거에는 양지센터의 부하가 임계치에 도달하면 운영자가 수만 건의 데이터를 엑셀로 추출해 경산센터에 수동으로 할당하는 과정을 거쳐야 했습니다. 하지만 이제는 단 한번의 클릭만으로 수만 건의 물량을 안정적으로 이관할 수 있는 환경을 구축하여 운영 효율을 개선했습니다.

이러한 대량의 데이터를 안정적으로 처리하기 위해 아키텍처 내부에 설계한 기술적 장치들은 다음과 같습니다.

분산 환경에서의 데이터 정합성 보장
- Redis 기반의 분산락(Distributed Lock)을 적용하여 다수 인스턴스 환경에서도 중복 이관을 방지하고 작업 멱등성 및 데이터 정합성을 확보했습니다.
장애 격리
- 외부 시스템(재고, OMS) 연동 시 발생하는 응답 지연이 전체 프로세스로 전파되지 않도록 구간별 서킷 브레이커를 배치하여 시스템 전반의 가용성 및 서비스 연속성을 유지했습니다.
데이터 최종 정합성 확보
- 재고 처리나 OMS 상태 변경 등 외부 시스템 연동 과정에서 일부 단계가 실패할 경우, 이미 처리된 앞선 단계를 원복하는 보상 트랜잭션(Compensating Transaction) 을 설계하였습니다.
- 각 단계별 실패 시나리오에 맞춰 상대 시스템의 롤백 API를 즉시 호출함으로써, 분산된 환경에서도 시스템 간 데이터 불일치 리스크를 최소화하고 최종적인 정합성을 보장합니다.
💡 이관 실행 프로세스
1단계. 사전 검증: 대상 센터의 실시간 재고와 기존 WMS의 작업 상태를 확인하여 이관 가능 여부 판단
2단계. 상태 제어: 기존 센터의 주문 취소와 신규 송장 채번, 재출하 지시를 하나의 트랜잭션처럼 동기화하여 처리
3단계. 재고 동기화: 변경 전후 센터의 재고 데이터를 정확히 증감시켜 시스템과 실재고 사이의 오차 방지
운영 가시성 확보를 위한 모니터링 UI
- 실시간 트래킹: 대량 주문 이관 진행 시 진행률과 성공/실패 여부를 실시간으로 확인할 수 있는 모니터링 UI 구축
- 운영 효율 개선: 운영자는 수만 건의 이관 현황을 엑셀 수작업 없이 대시보드로 실시간 파악 및 관리 가능

주문이관 진행 현황 UI - 실시간으로 이관 진행률, 성공/실패 건수 모니터링 가능

5. 배송최적화 시스템 도입 효과 (9월 vs 12월 세일)

배송최적화 시스템 도입 후, 실제로 어떤 변화가 있었을까요?
객관적인 성능 검증을 위해 트래픽이 가장 집중되는 '올영세일' 기간을 기준으로 도입 전(9월)과 도입 후(12월)의 성과 지표를 대조해 보았습니다.

💡 참고: 두 기간 모두 물류 센터의 가용량(CAPA) 한계치까지 트래픽이 몰리는 고부하 상황이라는 공통점을 기반으로 대조군을 설정했습니다.

📦 출고 처리 성능

최대 일 출고량 43.5% ↑

총 출고 물량 34.4% 증가

⚙️ 운영 자동화

수동 개입 49.2% ↓

분배 자동화율 100% 달성

🚚 고객 배송 경험

평균 14시간 단축

리드타임 16.5% 개선

5-1. 출고 처리 성능(Throughput)의 향상

단일 센터 체제에서는 특정 센터의 CAPA가 차오르면 그대로 배송 지연으로 이어졌습니다.
하지만 이제는 실시간 가동률 데이터에 기반한 동적 분배를 통해 양지센터의 부하를 경산센터로 즉시 분산합니다.
그 결과, 전체 센터의 가용 자원을 낭비 없이 100% 활용하며 최대 일 출고량을 전년 대비 43.5% 끌어올리는 성과를 거두었습니다.

5-2. 운영 프로세스 자동화 및 안정성 확보

전체 처리 물량은 전년 대비 크게 늘었으나, 시스템 자동화를 통해 현장의 운영 부담은 오히려 대폭 감소했습니다.
특히 주문분배 및 이관 과정에서 시스템의 자율 판단 체계를 구축함으로써 운영자의 수동 개입을 49.2% 줄이고, 수기 할당 업무를 사실상 '제로(Zero)'화 했습니다. 또한, 보상 트랜잭션과 멱등성 설계를 통해 이관 프로세스의 안정성을 확보한 결과, 휴먼 에러가 발생할 수 있는 수동 개입 포인트를 원천 차단하고 데이터 기반의 예측 가능한 운영 환경을 구축했습니다.

5-3. 배송 리드타임 단축을 통한 고객 경험 개선

가장 유의미한 성과는 고객이 체감하는 배송 속도의 향상입니다.
단순히 출고처를 나누는 것에 그치지 않고, 각 센터의 실시간 가동 상황과 권역별 최적 경로를 반영한 '흐름의 최적화'를 통해 출고 정체 구간을 해소했습니다.
그 결과, 대규모 물량이 몰리는 피크 타임에도 배송 리드타임을 전년 대비 평균 14시간 단축하는 성과를 거두었습니다.
이는 시스템이 스스로 최적의 경로를 찾아냄으로써 물류 병목을 해결하고, 고객에게 더욱 빠르고 신뢰받는 배송 경험을 제공할 수 있게 되었음을 의미합니다.

6. 마치며: 물류의 '자율 주행'을 향하여

멀티 센터 체제로의 전환은 단순히 센터 하나를 더 운영하는 수준을 넘어, 물류 시스템 전체의 관점에서 아키텍처를 전면 재설계하는 도전적인 작업이었습니다. 이번에 구축한 배송최적화 시스템은 그 변화의 첫걸음이자, 앞으로 만들어갈 유연한 물류 인프라의 기반이 될 것입니다. 그리고 이 모든 기술적 시도의 중심에는 저희 배송최적화 스쿼드가 지향하는 명확한 목표가 있었습니다.

🎯 올리브영 배송최적화 스쿼드의 목표

“
고객이 주문 버튼을 누르는 순간,
스스로 가장 빠르고 효율적인 경로를 선택하는
물류 운영 시스템을 구축한다
”

이번 프로젝트로 그 초석을 다졌다면, 이제는 이 비전을 완성하기 위해 다음과 같은 기술적 로드맵을 그려나가고 있습니다.

출고처 및 배송방식 자동 전환 고도화: 운영 상황에 따라 택배사와 배송 방식을 실시간으로 스위칭하는 유연한 출고 구조 완성
분리 배송 아키텍처 도입: 부분 결품이나 특정 센터 지연 시에도 가용한 상품부터 선출고하는 유연한 주문 처리 로직 고도화
정확한 배송 예정일(ETA) 산출: 재고 현황, 센터별 부하, 권역별 상황을 실시간 반영하여 주문 시점에 정확한 배송 예정일을 안내하는 알고리즘 개발
멀티 채널 출고 확장성 확보: MFC, 매장, 외부 물류 파트너 등 신규 출고처를 코드 수정 없이 즉시 수용할 수 있는 룰 기반 확장성 강화

•••

저희가 추구하는 가치는 명확합니다.

고객에게는 기다림 없는 배송 경험을, 운영자에게는 시스템이 스스로 판단하는 자율적인 환경을 제공하는 것
배송최적화 스쿼드는 이 가치를 현실로 만들기 위해 오늘도 보이지 않는 곳에서 치열하게 고민하고 있습니다.

여러분의 서비스도 물류 센터 확장을 앞두고 계신가요?
그렇다면 센터를 늘리는 것만큼이나 중요한 '어떻게 최적으로 분배할 것인가'에 대한 고민을 꼭 먼저 시작해 보시길 권합니다.
그리고 저희의 시행착오와 성취가 담긴 이 경험이 비슷한 도전을 앞둔 분들께 의미 있는 실마리가 되었기를 바랍니다. 🐥

이번 포스팅에서는 전체적인 아키텍처와 도입 성과를 중심으로 살펴보았는데요.
배송최적화 시스템의 상세한 엔지니어링 디테일은 이어지는 저희 스쿼드의 다음 포스팅에서 더 자세히 소개해 드릴 예정이니 많은 기대 부탁드립니다! 🔜

마지막으로 올리브영에서 저희와 함께 물류의 미래를 만들고 싶으신 분들의 많은 관심과 지원 부탁드립니다. 🙇‍♀️
👉 올리브영 코어플랫폼유닛 Back-end 개발자 채용 공고 바로가기

매장을 찾는 과정을 설계한 올영매장 고도화 여정

Fri, 27 Feb 2026 18:00:00 GMT

안녕하세요! 올리브영 올영매장팀에서 PM을 맡고 있는 김연경, 프로덕트 디자이너 김보라입니다.👋

여러분은 올리브영 매장에 방문해 보신 적이 있으신가요? 많은 분들이 매장에서 화장품과 생활용품을 구매하고, 팝업 스토어나 체험 이벤트를 즐긴 경험이 한 번쯤은 있으실 거예요. 사실 올리브영 앱에도 ‘올영매장’이 있습니다.

올영매장은 전국 1,400여 개 오프라인 매장과 관련된 정보를 앱에서 제공하는 서비스인데요, 단순한 매장 안내를 넘어, 온라인에서 픽업 주문을 하든, 매장을 직접 방문하든, 고객이 어디에서 쇼핑을 시작하더라도 끊김 없이 하나의 올리브영 경험을 느낄 수 있도록 하는 것. 이것이 바로 올영매장의 핵심 가치죠.

이번 글에서는 2025년 한 해 동안 올영매장이 어떤 방향성과 가설을 기반으로 프로덕트를 고도화해 왔는지를 PM과 디자이너의 시선으로 소개해 보려 합니다.

💡 올영매장의 기술적 토대가 어떻게 만들어졌는지 궁금하시다면, 2025년에 발행된 [10년 된 레거시를 현대화하다 시리즈] 포스트에서 매장 도메인의 설계와 확장 과정을 확인할 수 있습니다.

한 번의 실험이 바꾼 다음 경로

올영 매장 고도화의 실마리는 서비스 내 트래픽이 가장 높은 ‘구매 가능 올영매장’의 병목 현상에서 발견했습니다. 많은 고객이 매장 상품에 관심을 갖고 페이지에 진입했지만, 그 이후 행동으로 이어지지 않은 채 이탈하고 있었어요. 재고 정보는 충분했지만, 다음에 무엇을 할 수 있는지가 명확하지 않았던 것이죠.

그래서 우리는 픽업 장바구니 담기 버튼을 전면에 배치했습니다. 재고를 보여주는 것에서, 바로 행동하게 만드는 것으로의 전환이었죠. 배포 한 달 만에 올영 매장을 경유한 픽업 주문 건수는 2배 이상 늘었습니다. 이 변화는 버튼 하나를 추가한 결과라기보다, 구매 의향이 형성된 바로 그 순간, 다음 행동을 명확히 제시했기 때문이라고 해석했습니다. 2024년이 매장안내 서비스 리뉴얼을 통해 데이터 정합성과 시스템 기반을 다지는 해였다면, 이제는 그 위에서 고객의 행동을 유도하는 설계를 해야 한다는 것을 확인했던 과정이었어요.

올영매장 고도화 방향성과 대전제

픽업 장바구니 개선은 올영매장이 단순한 정보 제공을 넘어 고객 행동을 이끌어내는 판으로 확장될 수 있음을 보여준 출발점이었습니다. 그다음으로는 고객에게 어떤 정보가 더 필요할지, 그리고 어떻게 행동하게 만들 수 있을지에 대해 질문할 차례였습니다.

비즈니스 문제 발견: 매장에만 존재하는 정보들

😵‍💫 문제: 매장을 직접 방문하지 않으면 진행 중인 프로모션을 알지 못했어요.

올리브영의 각 매장은 고유한 프로모션과 혜택을 운영하고 있습니다. 특정 매장에서만 제공하는 할인 쿠폰과 증정품, 팝업 스토어, 체험 이벤트 등이 대표적이죠. 상권과 매장 특성에 맞춰 매달 수십 개의 프로모션이 기획·운영되며, 이는 고객을 매장으로 유입시키는 중요한 장치입니다.

하지만 이런 정보는 대부분 매장 내 인쇄 연출물이나 구성원의 설명에 의존하고 있었어요. 온라인몰에서는 개별 매장의 혜택이나 콘셉트를 사전에 확인할 방법이 거의 없었죠. 그 결과, 고객은 매장 방문을 미리 계획하기 어려웠고, 매장이 가진 고유한 혜택은 온라인에서 충분히 전달되지 못하고 있었습니다.

기회 발견: 온라인에서 오프라인 경험 확장

💡기회: 매장에만 존재하던 정보를 온라인에서도 보여줄 수 있다면, 전국 1,400여 개 올영 매장이 가진 옴니채널 가치가 더욱 강해지겠죠.

매장 프로모션이 온라인까지 확장된다면, 온라인 고객을 오프라인 매장으로 자연스럽게 유입시킬 수 있을 것으로 기대했습니다. 실제로 올리브영은 온·오프라인을 모두 이용하는 옴니채널 고객 비중이 꾸준히 증가하고 있었으며, 여전히 추가 성장을 기대할 수 있는 단계였어요.

고객 관점에서도 가능성은 분명했습니다. 매장 방문 전에 프로모션과 혜택을 미리 확인할 수 있다면, 방문 계획을 세우기 훨씬 수월해집니다. 특히 2030 고객층은 오프라인 매장을 단순한 구매 공간이 아닌, 브랜드를 경험하는 장소로 인식합니다. 따라서 온라인에서 사전에 매력을 느낀 매장은 실제 방문으로 이어질 가능성이 높은 것이죠.

고도화 목표와 가설 수립

올영매장이 추구하는 가치는 분명했습니다.

"매장에 대한 정보 접점을 넓히고, 고객이 올영 매장만의 가치를 자연스럽게 인지하고 학습하게 만들어, 실제 방문으로 이어지게 만든다."

물론 로드맵에는 개인화된 매장 추천 기능도 포함되어 있었어요. 그러나 앞선 픽업 실험을 통해, 우리는 중요한 전제를 확인했습니다. 고객의 행동을 이끌어내려면, 그전에 먼저 인지와 맥락이 갖춰져야 한다는 것이었죠. 따라서 우리는 먼저 저변을 넓히는 단계가 선행되어야 한다고 판단했고, 이를 검증하기 위해 다음과 같은 가설을 세워 실험을 진행했습니다. 그리고 아래 가설을 바탕으로 구체적인 설계를 이어갔습니다.

[가설 1] 접점 확대를 통한 볼륨 성장: 올영 매장으로 이어지는 유기적인 트래픽 접점을 넓히면, 전체 접속 볼륨이 증가할 것이다.
[가설 2] 콘텐츠 가시화를 통한 탐색 증가: 매장별 콘텐츠와 혜택을 가시화하면, 고객의 탐색 소비량이 증가할 것이다.
[가설 3] 행동 유도를 통한 액션 전환율 향상: 프로모션 정보와 함께 행동을 유도하는 요소를 제공하면, 액션 전환율이 높아질 것이다.

그래서 어떻게 했나요?

목적 달성의 도구에서, 탐색의 공간으로

올영매장에서 가장 큰 변화는 탐색 구조를 다시 정의한 것이었어요. 그동안 매장 관련 경험은 특정 목적을 달성하기 위한 기능 단위로 흩어져 있었습니다. 재고를 확인하거나, 픽업 주문을 하거나, 매장 정보를 찾기 위해 각각 다른 경로를 거쳐야 했죠. 그러나 매장 경험은 더 이상 부분적인 기능이 아니라, 고객에게 독립적으로 전달되어야 할 하나의 O2O 레이어라고 보았습니다.

우리는 단순히 유입을 늘리는 것이 아니라, ‘매장 탐색’ 자체를 하나의 완결된 경험으로 제공하고자 했습니다. 이를 위해 올리브영 앱 하단 Tab Bar에 ‘올영매장’을 독립적인 공간으로 배치했어요. 매장 탐색부터 혜택 확인, 구매·픽업, 실제 방문까지 이어지는 흐름을 하나의 여정으로 담아내기 위해, 파편화된 진입 구조가 아닌 종합적인 안내 구조 설계가 필요했습니다.

🟡 연경(PM): 고객의 쇼핑 여정 안에서 매장 탐색을 제공해야 한다는 점에는 전사적인 공감이 있었지만, 그 탐색을 담아낼 ‘판을 어떤 형태로 만들 것인가’는 옴니채널 스쿼드가 풀어야 할 과제였습니다.

우리가 만들고 싶었던 건 고객이 “지금 매장에서 어떤 일이 일어나고 있을까?”를 궁금해하며 스스로 찾아오게 만드는 공간이었어요. 올영매장 홈은 매장과 관련한 모든 탐색이 출발하는 종합 안내 공간으로 기획되었습니다. 픽업이나 재고 확인처럼 뚜렷한 목적을 가진 고객만을 위한 공간이 아니라, 올리브영을 이용하는 모든 고객이 매장을 자연스럽게 탐색할 수 있는 게이트웨이로 만든 것이죠.

🟣 보라(PD): 올리브영 앱에서 고객의 흐름을 보면, 상품을 구경하다가 점점 ‘실제로 사야겠다’는 행동으로 이어져요. 그 흐름 어딘가에 ‘직접 매장에 가볼까?’라는 생각이 자연스럽게 드는 순간이 있어야 했고, 올영 매장 탭이 바로 그 역할을 맡았습니다. 탭 바는 단순한 메뉴가 아니라, 고객이 온라인에서 오프라인으로 발걸음을 옮기는 전환점이라고 생각했어요.

오프라인 경험, 사전에 설득하기

정보를 잘 보여주는 것과 행동을 이끌어내는 것은 다른 문제라고 생각합니다. 고객은 정보를 확인했을 때보다, ‘갈 이유가 생겼을 때’ 움직이기 때문입니다. 매장 정보를 아무리 상세히 제공해도 ‘그래서 왜 매장에 가야 하지?’라는 질문에 답하지 못하면 방문으로 이어지기 어렵습니다. 그래서 우리는 매장 방문을 사전에 설득하는 장치가 필요하다고 판단했고 콘텐츠(가 볼 이유), 혜택·프로모션(지금 가야 하는 이유)이라는 두 가지 방향으로 접근했어요.

첫 번째는 콘텐츠였습니다. ‘이달의 스토어 콘텐츠’와 ‘색다른 매장’은 매장을 단순한 구매 공간이 아니라 직접 가보고 싶은 경험의 공간으로 인식시키기 위한 시도였어요. 트렌드팟, N성수처럼 올리브영만의 콘셉트를 가진 매장 이야기를 콘텐츠로 풀어내며, 매장 방문이 자연스러운 선택지가 되도록 했습니다.

🟡 연경(PM) : 온라인 쇼핑이 일상이 된 지금, 오프라인 매장이 제공해야 할 가치는 결국 ‘경험’이라는 이야기를 반복해서 들어왔어요. 올리브영 역시 매장에서만 느낄 수 있는 체험적 가치를 앱 안에서 더 적극적으로 드러낼 필요가 있었습니다. 실제로 이전까지 앱에서는 온라인 상품 기획전과 이벤트 중심의 콘텐츠만 노출되고 있었는데요, 매장 기획전을 위한 프로덕트가 새롭게 마련되면서, 이를 올영매장 안에서 어떻게 보여줄지가 새로운 과제가 되었습니다.

🟣 보라(PD) : 저는 고객이 탐색하는 과정에서 ‘새로운 발견’을 경험하도록 만드는 데 집중했어요. 정보를 얼마나 빠르게 전달하느냐보다, 고객이 얼마나 자주 다시 방문하게 만들 수 있는지가 더 중요하다고 봤거든요. 그래서 매장 소개를 단순한 정보 나열이 아니라, 스토리텔링 기반의 콘텐츠로 설계했습니다. 한 번 보고 끝나는 게 아니라, 다음에도 자연스럽게 다시 찾게 되는 탐색 습관을 만드는 장치로 기획한 거죠.

두 번째는 관심 매장의 혜택과 프로모션을 더 잘 보이게 만드는 것이었어요. 고객의 생활권이나 일상 루틴과 연결된 매장을 중심으로, 매장 한정 증정품이나 지역 맞춤 할인 쿠폰 같은 혜택을 우선적으로 노출했습니다. 매장마다 다른 혜택을 눈에 띄게 보여줌으로써, 고객이 특정 매장과 자연스럽게 관계를 맺고 다시 찾을 이유가 생기는 구조를 만들고자 했습니다.

이처럼 올영매장의 콘텐츠와 프로모션은 각각 분리된 기능이 아니라, 매장 방문으로 이어지기 위한 하나의 흐름으로 설계되었습니다. 온라인에서 매장 경험을 먼저 이해하고 공감한 뒤, 실제 방문이라는 행동으로 이어지게 만드는 것. 이것이 이번 개선에서 우리가 만들고자 했던 변화였습니다.

고객의 다음 행동을 이어주는 픽업 대시보드

올영매장에서 직접적인 구매 전환으로 이어질 수 있는 행동은 ‘픽업’이라고 생각했어요. 그래서 고객이 올영매장에 진입했을 때 가장 먼저 인지해야 할 것은 ‘여기서 바로 매장 픽업을 할 수 있다’는 메시지였습니다. 고객이 이탈하지 않고 행동으로 이어지려면, 고민 없이 다음 단계로 넘어갈 수 있는 구조가 필요했죠.

이런 맥락에서 픽업 대시보드를 홈 최상단에 배치했습니다. 단순히 픽업 주문 수를 늘리기 위한 선택이 아니었어요. 픽업은 온라인에서 시작된 구매 의도를 매장 방문이라는 실제 경험으로 연결하는 중요한 접점이기 때문입니다.

기존에는 마이페이지나 카카오 알림을 통해서만 픽업 상태를 확인할 수 있었어요. 하지만 개선 이후에는 올영매장 홈에 들어오는 순간부터 픽업 기능을 바로 확인할 수 있고, 주문 상태에 따라 다음 행동도 명확하게 이어지는 구조가 되었죠.

🟣 보라(PD) : 픽업 대시보드는 주문 상태에 따라 보여주는 정보의 우선순위가 달라져요. 고객의 현재 상황을 실시간으로 반영해, 지금 할 수 있는 행동이 자연스럽게 눈에 들어오도록 했고요. 정보를 나열하는 대신, 보자마자 이해하고 바로 행동할 수 있도록 최대한 단순하게 만드는 데 집중했어요.

💡 픽업 대시보드가 실시간으로 주문 상태를 반영할 수 있었던 기술적 배경이 궁금하시다면, 
옴니채널 스쿼드 너굴님이 3월 중 공유할 [올영매장과 데이터 연동 기술 이야기]에서 Kafka 이벤트 기반 하이브리드 설계를 확인해 보실 수 있습니다.

숫자로 본 변화

그러자 트래픽 관점에서 아래와 같은 유의미한 움직임이 나타났습니다. 저희는 이를 올영매장이 특정 상황에서만 찾는 기능이 아니라, 고객의 탐색 흐름 안에 자연스럽게 자리 잡기 시작했다는 신호로 해석했습니다.

지표	결과
유입 경로	직접 유입 비중 약 10%p 증가
트래픽	2025년 월별 PV/순 방문자 수(Unique Visitor)/MAU 우상향 성장
인지도	올리브영 전체 순 방문자 수(Unique Visitor) 대비 올영매장 UV 비중 성장

이번 올영매장 확장의 핵심은 고객이 언제, 어디서든 가장 편한 방식으로 구매와 매장 탐색을 이어갈 수 있게 만드는 것이었습니다. 특히 단기 성과를 위한 개선이 아니라, 온·오프라인을 연결하는 경험의 기반을 다지는 구조적 변화의 출발점에 가깝습니다. 앞으로는 이 기반 위에서 온·오프라인 데이터를 유기적으로 연결하고, 고객의 구매 여정 전반에서 발생하는 니즈와 문제를 더 입체적으로 바라보며 다음 방향성을 설계해 나갈 예정입니다.

아직 남은 과제

한편, 픽업 주문 전환율은 기대만큼 오르지 않았어요. 접근성과 전환은 다른 문제였기 때문인데요. 이는 고객이 왜 픽업을 선택해야 하는지에 대한 설득이 아직 충분하지 않았다는 신호로 보았습니다.

원인은 아래 두 가지로 분석할 수 있었어요.

올영매장의 인지도와 접근성은 개선되었지만 ‘픽업으로 구매해야 하는 이유’까지는 설득하지 못함
온라인 구매에 익숙한 고객의 행동 패턴을 변화하기에는 시간이 필요

픽업이 가능하다는 사실을 아는 것과, 지금 이 순간 픽업이 가장 합리적인 선택이라고 이해하는 것은 다른 문제였어요. 앞으로는 재고가 한정된 상황이나 빠른 수령이 필요한 순간처럼, 픽업이 자연스럽게 더 유용해지는 상황을 설계하는 실험이 필요하다고 판단했습니다.

또한, 이미 온라인 구매에 익숙한 고객의 선택을 바꾸는 건 단기간에 이루어지기 어려워요. “왜 매장에 가야 해?”라는 근본적인 질문에 더 설득력 있는 답을 제시해야 하죠. 그래서 앞으로의 목표는 명확해요. 올영매장의 고관여 고객에 대한 이해를 바탕으로, 인지도가 아닌 재방문율을 높이고, 트래픽이 아닌 전환을 개선하며, 기능이 아닌 습관을 만드는 거예요.

또 하나의 과제는 개인화 경험의 시작이 쉽지 않다는 점이었습니다. 관심 매장 설정을 유도하는 것만으로는 한계가 있었거든요. ‘아직 아무 설정도 하지 않은 첫 방문자에게, 어떤 즉각적인 이득을 줄 수 있는가?’에 대한 고민이 더 필요합니다. 설정을 마친 고객에게만 가치가 작동하는 구조로는, 아직 아무것도 설정하지 않은 첫 방문자를 붙잡기 어렵기 때문입니다. 따라서, 설정 이전에도 충분한 가치를 느낄 수 있는 구조를 만들어야겠다고 생각했어요.

마치며

올영매장 고도화 프로젝트를 통해 분명해진 것은 하나입니다. 고객이 원하는 것은 눈에 보이는 기능이 아니라, 자신의 문제를 해결해 주는 경험이라는 것입니다.

이제 올영매장은 인지와 접근성이라는 첫 단계를 지나, 왜 지금 이 매장을 선택해야 하는지에 대한 ‘행동의 이유’를 만들어야 하는 단계에 들어섰습니다. 즉, 매장 정보를 잘 보여주는 것이 지난 단계에서의 목표였다면 고객이 별도의 탐색 없이도 ‘지금 이 선택이 가장 합리적이다’라고 느끼게 만드는 것이 다음 과제인 거죠.

앞으로의 고도화 방향은 기능을 더 추가하는 데 있지 않습니다. 고객을 움직이게 만드는 맥락과 설득을 더 정교하게 다듬고, 한 번의 선택이 자연스럽게 반복되는 습관으로 이어지도록 설계하는 것입니다. 올영매장은 그렇게, 고객의 일상 안에 스며드는 경험으로 계속 진화해 나갈 예정입니다. 그럼, 앞으로도 관심 있게 지켜봐 주세요!

글. 김연경(올영매장 PM), 김보라(Product Designer) / 올영매장 팀

우리의 성장은 계속됩니다

올리브영은 앞으로도 이러한 지식 교류의 장을 지속적으로 마련할 예정입니다. 혼자 고민하면 풀기 어려운 ‘숙제’가 되지만, 함께 나누면 세상을 놀라게 할 ‘혁신’의 실마리가 된다는 것을 믿기 때문입니다. 올리브영의 PM과 디자이너는 단순히 기능과 화면을 만드는 사람이 아닙니다. 단단한 커뮤니티 안에서 동료들과 함께 정답을 찾아가고, 그 과정에서 나만의 독보적인 커리어를 만들어갑니다.

💡 더 자세한 올리브영 프로덕트 이야기가 궁금하신가요? 이 글은 올리브영 프로덕트 메이커가 직접 전하는 생생한 소식지, [올리브영 PM 블로그(Medium)]에서도 만나보실 수 있습니다. 서비스 기획의 깊은 고민과 추가 콘텐츠가 궁금하시다면 이 링크를 확인해 보세요! 👉🏻 올리브영 PM 블로그 바로가기 💚

💡 세상을 바꿔나갈 멋진 여정에 합류하세요! 최고의 동료들과 함께 더 건강하게 성장할 여러분을 기다리고 있습니다. 👉🏻 올리브영 PM 채용 공고 보기 💚

Spring 트랜잭션 동기화로 레거시 알림톡 발송 시스템 한계 넘어서기

Mon, 23 Feb 2026 15:00:00 GMT

안녕하세요, 올리브영 배송스쿼드에서 백엔드 엔지니어로 일하고 있는 애쉬입니다. 이번 글에서는 입사 후 처음 맡게 된 프로젝트를 진행하며 느꼈던 고민과 배움을 공유해보려 합니다.

입사 첫 프로젝트가 단순 기능 개발이 아닌 대규모 아키텍처 전환이라니... 설렘 반 걱정 반으로 시작했던 1년차의 치열한 레거시 탈출기를 공유합니다. 🚀

1. 전환의 계기

올리브영의 알림톡 발송 시스템은 주문, 결제, 배송 등 고객의 서비스 경험 속에서 핵심적인 소통 역할을 합니다. 1,600만 명 이상의 회원에게 실시간으로 소식을 전하는 매우 중요한 채널이죠. 하지만 비즈니스가 급성장하며 레거시 시스템은 점점 복잡해졌고, 변화하는 요구사항을 담아내기에는 한계에 부딪혔습니다. 특히 발송 플랫폼의 변화를 앞두고, 지속 가능한 구조를 위한 모던 아키텍처로의 전환이 필요했습니다.

1.1 왜 바꿔야 했을까?

알림톡 발송 시스템을 개편하게 된 이유는 하나의 문제가 아니라, 여러 한계가 동시에 드러났기 때문입니다. 먼저 알림톡 발송 플랫폼이 변경되면서, 기존 구조의 수정이 필요했습니다. 그런데 알림톡 발송과 관련된 로직이 여러 비즈니스 코드에 흩어져 있어, 해당 부분을 일일이 찾아 수정해야 하는 번거로움이 있었습니다. 또 데이터 조회 기준의 불일치 문제도 있었죠. 같은 내용이라도 알림 유형이나 서비스에 따라 서로 다른 테이블과 조건으로 데이터를 조회하는 경우가 있어, 일관성이 깨지고 기준이 모호했습니다. 마지막으로 올리브영은 레거시 시스템을 모던 아키텍처로 점진적 전환 중이기 때문에, 앞으로 모던 환경 중심으로 배송 알림을 확장하기 위해서라도 발송 기능을 하나의 구조로 일원화할 필요가 있었습니다.

1.2 어떻게 바꿔야 할까?

레거시 시스템과 모던 아키텍처 시스템 간 통신을 위해 Kafka 메시지를 사용하기로 했습니다. 기존 배송스쿼드에서 사용하던 컨슈머 서비스에서 알림톡을 발송하기 위해서죠. 여기서부터 신입 개발자의 고민이 시작됩니다...

기존 레거시 코드는 주문/배송 상태 변경 로직 안에서 메시지 발송 서비스를 직접 호출하고 있었고, 이 호출은 try-catch로 감싸져 있어 알림톡 발송에 실패하더라도 기존 비즈니스 로직에는 영향을 주지 않는 구조였습니다. 그래서 처음에는 레거시의 알림톡 발송 서비스를 호출하는 시점에 Kafka 메시지를 바로 생성하려고 했습니다.

하지만 코드를 작성하다 다시 살펴보니 알림톡 발송이 성공한 이후에 비즈니스 로직에서 오류가 발생하더라도, 이미 발송된 알림톡은 되돌릴 수 없다는 문제가 있었습니다. 즉, 실제 데이터 상태와 고객에게 전달된 알림이 어긋날 수 있는 구조였던 셈입니다. 오류 발생으로 같은 로직을 재실행한다면 알림이 중복 발송될 거고요.😱 그래서 알림톡 발송을 비즈니스 로직에서 분리하되, 주문/배송 상태 변경과 고객 안내의 명확한 순서가 보장되는 구조가 필요하다고 판단했습니다.

2. 전환 방법론

2.1 트랜잭션 동기화 구현

일반적으로 Spring 환경에서는 트랜잭션 동기화를 위해 @TransactionalEventListener를 활용한 트랜잭션 커밋 이후 이벤트를 처리하는 방식이 널리 사용됩니다.

하지만 저는 해당 방식을 사용할 수 없었는데요, 간략히 제가 겪었던 과정을 설명드려보겠습니다. 처음에는 @TransactionalEventListener를 사용해서 트랜잭션 커밋 후 이벤트를 처리하려고 했는데, 이 어노테이션은 Spring 4.2부터 지원되는 기능이었습니다. 문제는 레거시에서 하위 버전을 사용하고 있어서 TransactionPhase.AFTER_COMMIT 같은 클래스 자체가 존재하지 않았다는 점이죠. 그래서 Spring 4.2.5로 버전을 올렸는데, 하필 다른 모든 모듈이 의존하는 공통 모듈을 건드렸던 게 화근이었습니다. Maven에서 기존 프레임워크와의 의존성 충돌이 발생했고, spring-context만 올렸더니 spring-tx도 함께 올려야 한다는 오류가 연쇄적으로 터졌죠. 하나씩 해결하다 보니 빌드는 성공했지만 서버 실행 시 NoClassDefFoundError가 발생했습니다. 이 오류는 클래스패스에 4.2.5와 하위 버전이 섞여 있으면서, 컴파일 타임에는 4.2.5 클래스를 참조했지만 런타임에는 하위 버전의 클래스가 로드되어 메서드 시그니처가 맞지 않아 발생한 것이었죠. 버전을 잘 맞춰서 이 문제를 해결하고 나서는 제가 수정하지 않은 부분에서도 빈 생성 오류가 발생했습니다. 🫠

이렇게 하나를 해결하면 새로운 오류 메시지가 발생하는 상황의 연속을 경험하면서... 개발 경험이 부족했던 저는 운영 환경에서도 예상치 못한 오류가 발생할까 걱정되어 이벤트 리스너 구조를 고집하기 보다 차선책을 택하기로 했습니다. 레거시 시스템을 처음 크게 수정하는 프로젝트였는데, 제가 생각한 대로 흘러가지 않고 무수한 오류들을 마주하며 레거시가 얼마나 복잡한 시스템인지, 왜 전사 차원에서 모던화를 빠르게 추진하는지 체감할 수 있었습니다.

제가 선택한 방법은 TransactionSynchronizationManager를 활용한 커밋 이후 콜백 메서드 실행이었습니다. 이 방식이 이벤트를 발행하거나 리스너를 등록하는 구조는 아닙니다. 하지만 트랜잭션이 성공적으로 커밋된 이후에만 특정 로직이 실행되도록 보장할 수 있기 때문에, 실행 시점 보장 측면에서는 이벤트 처리와 동일한 효과를 가집니다. 즉, 구현 방식은 단순한 콜백이지만 “데이터가 확정된 이후에만 후속 처리가 시작된다”는 중요한 조건을 만족시킬 수 있었고, 이를 통해 알림톡 발송 흐름을 비즈니스 트랜잭션으로부터 안전하게 분리할 수 있었습니다.

현재 트랜잭션 커밋 후 바로 Kafka 메시지를 발행하는 방식을 사용했는데, 메시지 발행이 실패할 경우에는 실패 로그를 DB에 저장하여 별도로 재처리할 수 있도록 설계되어 있습니다. 다행히 운영 환경에서 서버 장애로 인한 메시지 유실은 발생하지 않았지만, 이번 개발 과정을 회고해보니 더 높은 안정성이 요구되는 환경이라면 Outbox Pattern을 통해 이벤트를 DB에 먼저 저장한 후 별도 프로세스가 발행하도록 하거나, 재시도 메커니즘 같은 방어책들을 추가로 고려해볼 필요가 있겠다는 생각이 들었습니다. 당장은 필수는 아니지만 이런 부분들도 점진적으로 개선해나가면 좋을 것 같습니다.

✅ 레거시 비즈니스 로직 + 커밋 후 Kafka 메시지 발행

public class NotificationEvent {

    private final String orderNo;
    private final String notificationType;

    public NotificationEvent(String orderNo, String notificationType) {
        this.orderNo = orderNo;
        this.notificationType = notificationType;
    }
}

@Component
public class NotificationAfterCommitHandler {

    private final MessagePublishService messagePublishService;    // Kafka 메시지 발행 서비스

    public void handle(NotificationEvent event) {

        // 트랜잭션 커밋 이후에만 실행될 로직 등록
        TransactionSynchronizationManager.registerSynchronization(
            new TransactionSynchronizationAdapter() {
                @Override
                public void afterCommit() {
                    // 커밋이 완료된 이후에만 후속 처리 수행
                    messagePublishService.publish(
                        event.getOrderNo(),
                        event.getNotificationType()
                    );
                }
            }
        );
    }
}

그림 1. 레거시의 구조와 개선된 메시지 기반 아키텍처 비교

2.2 MSA(Microservices Architecture) 환경에서의 알림톡 처리 흐름

이제 레거시 시스템과 모던 아키텍처 시스템이 어떻게 연결되고, 어떤 시점에 실제 발송 흐름이 시작되는지 살펴보겠습니다. 레거시에서 트랜잭션 커밋 이후에 Kafka 메시지를 발행하고, MSA의 Delivery Consumer 서비스가 이를 소비(consume)합니다. 이제부터는 레거시가 아니라, Delivery Consumer가 모든 발송 처리를 전담하게 됩니다.

배송에서 관리하고 있는 알림톡이 약 40개 정도로 꽤 많은 편이라, 어떻게 나눠서 기능화할지 설계와 구현에 많은 시간을 쏟았는데요. 우선 레거시에서 발행된 메시지에 알림톡 유형이 있으니, 같은 배송 유형별(ex. 오늘드림 / 일반배송)로 분리하여 처리하도록 했습니다. 배송 유형별로 안내하는 내용이 비슷하기 때문에, 같은 쿼리를 사용해 데이터를 조회하도록 한 거죠. 그런데 막상 테스트해보니 같은 배송 유형 안에서도 이 배송이 일반 주문인지, 교환 주문인지 또는 취소된 항목은 없는지에 따라서 필요한 데이터가 조금씩 상이하여 하나의 쿼리로 특정 배송 유형에 대한 모든 범위의 알림톡을 커버하지 못했습니다. 수정과 테스트를 반복하며 모든 유형을 최소 갈래로 분류하여 공통 쿼리를 수정해 나갔습니다. 이 작업을 하면서도 난항을 겪어서 그냥 알림 유형별로 조회 쿼리를 만들까도 생각했지만😅 그러면 레거시와 다른 점이 없기 때문에! 열심히 고민한 결과 배송 유형 내에 같은 조건끼리 묶어서(ex. 일반 / 교환) 데이터를 조회할 수 있도록 했습니다. 이렇게 데이터 조회까지 완성한 뒤에는 알림톡 내 링크 생성, 알림톡 발송 요청 API 등 공통 기능을 구현해서 모던 시스템을 완성할 수 있었습니다.

위에서 설명한 내용을 단계별로 정리해보면 아래와 같습니다.

컨슈머가 메시지 소비
- Kafka를 통해 전달된 메시지를 소비합니다.
- 이 메시지에는 주문번호, 알림톡 유형과 같은 최소한의 필수 정보만 포함되어 있습니다.
알림톡 유형에 따라 배송 유형 분기
- 컨슈머는 전달받은 알림톡 유형을 기준으로 일반 배송, 오늘드림, 픽업, 선물하기 중 어떤 배송 유형의 알림인지 판단합니다.
공통 기준으로 알림톡 정보 조회
- 배송 유형이 결정되면, 해당 알림에 필요한 공통 데이터와 템플릿 정보를 DB에서 일관된 기준으로 조회합니다.
- 과거처럼 서비스마다 서로 다른 테이블을 조회하지 않고, 하나의 기준 테이블만 조회하도록 통합했습니다.
템플릿 구성 후 발송 요청
- 조회한 데이터를 바탕으로 알림톡 템플릿을 채우고, 최종적으로는 하나의 공통 발송 API를 통해 알림톡 발송 요청이 이루어집니다.
- 어떤 배송 유형이든, 실제 외부 알림 플랫폼으로 나가는 통로는 항상 하나로 통일되어 있습니다.

즉, 레거시에서는 언제 알림을 보내야 하는지만 결정하고, 컨슈머에서는 어떤 내용을, 어떤 방식으로, 안정적으로 보낼지를 전담하는 구조로 역할이 완전히 분리되었습니다. 이렇게 공통화한 덕분에 새로운 알림톡을 추가할 때 매우 간편한 구조가 완성되었습니다. 템플릿과 발송 시점만 추가하면 끝이죠. 여담이지만 이후에 제가 알림톡 추가 작업도 진행했는데, 모던 전환 미리 해두길 정말 잘했다는 생각과 함께 보람이 느껴졌습니다.

그림 2. MSA에서의 알림톡 처리 흐름

3. 전환 과정에서의 배움

신입 개발자로서 이번 프로젝트는 단순한 기능 구현을 넘어, 시스템을 설계하는 관점에서 많은 고민을 하게 만든 경험이었는데요. 제가 느낀 내용들은 한 번 정리해보겠습니다.

3.1 아키텍처 설계의 중요성

코드를 작성하기 전에 시스템 전체의 흐름을 이해하는 것이 무엇보다 중요했습니다. 초반에 여러 제약을 고려하지 않고 단순한 시스템 설계 후 코드를 작성했다가, 부족한 점을 보완한 후 다시 작성하며 시간이 거의 두 배로 들었습니다. 입사 초반에는 '개발자는 코드를 잘 짜야 한다'는 생각이 강했다면, 이 프로젝트를 통해 '설계를 잘 하는 개발자가 되고 싶다'고 생각이 바뀌었습니다. 특히 단일 서비스에서 해결되던 문제도, 분산 환경에서는 여러 시스템 간 데이터 흐름을 고려해야 한다는 점을 가장 크게 느꼈습니다.

3.2 철저한 테스트의 필요성

아무리 설계를 잘 해놓더라도 허점이 있기 마련인데요. 이런 점은 코드만 놓고 보면 보이지 않는 경우가 많습니다. 그래서 QA팀과 함께 직접 여러 케이스를 테스트해보며 이상한 점은 없는지, 누락된 기능은 없는지 꼼꼼히 확인했습니다. 특히 알림톡은 고객에게 직접 발송되고 안내하는 기능이라 작은 실수도 치명적일 수 있어, 다양한 케이스를 반복 테스트하며 안정성을 확보하려 노력했습니다.

3.3 MSA 구조에서의 비즈니스 흐름

입사 전에는 제대로 된 MSA 환경을 접하기 어렵기 때문에 추상적으로만 알고 있던 구조를 이번 프로젝트를 통해 좀 더 구체적으로 이해할 수 있었습니다. MSA에서는 하나의 비즈니스 흐름이 여러 시스템으로 나뉘어 처리되기 때문에, DB 트랜잭션 이후의 처리까지 포함해 전체 흐름의 일관성을 어떻게 유지할지가 중요하다는 것을 배웠고, 이후 올리브영의 다른 마이크로 서비스와 통신하며 협업해야 하는 작업에서 정말 많은 도움을 얻을 수 있었습니다.

4. 전환 후 개선된 점

저의 피땀눈물로 완성한 전환 이후 시스템은 훨씬 단순하고 안정적으로 개선되었습니다. 주요 개선 사항을 표와 함께 정리해볼까요?

구분	기존 (Legacy)	개선 후 (Modern)
아키텍처 구조	서비스 로직 내 발송 코드 결합(Monolithic)	Kafka 기반 이벤트 주도 아키텍처 (EDA)
발송 시점 보장	비즈니스 로직 결과와 별개로 발송	afterCommit 활용 트랜잭션 정합성 확보
데이터 조회	서비스별 산재된 테이블/조건 조회	통합 기준으로 일관된 데이터 조회
관리 주체	각 비즈니스 도메인 서비스	배송 컨슈머(Delivery Consumer)로 일원화
확장성	알림톡 추가 시마다 레거시 코드 수정/배포	템플릿 등록 및 메시지 발행으로 낮은 공수

4.1 유지보수성 향상

알림톡 관련 코드가 모던 알림톡 서비스 한 곳으로 집중되면서 관리 포인트가 크게 줄었습니다.
데이터 조회 기준도 공통화되어 서비스별 테이블 불일치 문제가 해소되었습니다.
수정 시 영향 범위 파악과 장애 대응 속도 모두 개선되었습니다.

4.2 확장성과 유연성 증가

알림 발송 시점이 이벤트 기반으로 정의되어, 이벤트 추가만으로 확장이 가능해졌습니다.
알림 기능이 특정 서비스에 결합되지 않고 독립된 구조로 분리되었습니다.
향후 배송 정책이나 서비스 유형이 추가되어도 최소한의 변경으로 대응할 수 있습니다.

4.3 공통 재시도 로직 구축 (확장)

레거시에서는 공통 재시도 로직을 독립적으로 구성하기가 어려웠으나, 모던 환경에서 실패 건을 별도 테이블에 저장해 비동기적으로 재처리하는 공통 재시도 구조를 새롭게 설계했습니다.
이를 통해 단순한 기능 구현을 넘어 운영 관점의 안정성까지 함께 확보할 수 있었습니다.

5. 마무리하며

이번 프로젝트는 저에게 단순한 마이그레이션을 넘어, 시스템을 설계하고 개선하는 개발자로 성장하는 계기가 되었습니다. 트랜잭션 동기화라는 기술적 도전, 메시지 기반 구조 전환, 테스트를 통한 안정성 확보와 같은 과정을 통해 유지보수성과 확장성을 모두 갖춘 배송 알림톡 시스템을 완성할 수 있었죠. 무엇보다 이번 경험은 신입 개발자로서 시스템을 바라보는 시야를 넓혀준 좋은 시작이었습니다. 앞으로 올리브영에서 어떤 문제를 해결하게 될지, 또 어떤 기술적인 도전을 하게 될지 매우 기대되고 다음 번에 더 성장한 모습으로 돌아오겠습니다. 감사합니다!

오프라인 매장에 코드를 배포하다 Part 2: 올리브영 전자라벨(ESL) 최적화 여정

Tue, 10 Feb 2026 10:00:00 GMT

들어가며

안녕하세요! 올리브영에서 Back-end 개발을 담당하고 있는 '코드다이버(이시훈)'입니다. 앞서 "올리브영 전자라벨(ESL) 구축기 Part 1: 종이 없는 매장을 만드는 데이터 파이프라인"에서는 전자라벨의 도입 배경과 아키텍처 설계 부분을 다뤘습니다. 이번 글에서는 전국 1,300여 개 매장으로 대규모 확산하는 과정에서 마주한 성능 최적화 기술들을 중점적으로 소개하겠습니다. 특히 아래와 같은 내용을 담고 있으니 참고해 주세요.

🛠️ Engineering Highlights

Partitioning - 1,300개 매장 배치 처리 시간 13일 → 5분 단축
Lock Free - 데이터 범위 분할로 DB Deadlock 원천 차단
Serverless v2 - 트래픽 폭주에 대응하는 오토스케일링으로 비용 40% 절감

🎯 특히 이런 분들께 도움이 될 거예요

대용량 배치 처리 속도 문제로 고민하는 백엔드 개발자
예측 불가능한 트래픽에 대응하는 DB 인프라 전략이 궁금한 엔지니어

1편에서 이야기한 아키텍처가 설계도라면, 지금부터는 실제 데이터를 태워 가동할 차례입니다. 굳이 비유하자면, 시스템 구축 초기의 파일럿 매장은 '2~4명으로 구성된 우리 가족을 위해 집에서 두쫀쿠를 몇개 만들어 제공'하는 수준과 같았습니다. 하지만 전국 1,300개 이상 매장 적용은 '전국에 근무 중인 수천 명의 올리브영 임직원에게 동시에 일정한 퀄리티의 두쫀쿠를 제공하는 시스템을 운영'하는 것과 같습니다. 메뉴(로직)는 같을지 몰라도, 조리 도구와 조달 방식(아키텍처와 성능 최적화)은 근본적으로 달라야만 했습니다.

이에 압도적인 규모로 전국 매장에 안정적으로 시스템을 도입하기 위해 저희가 치열하게 고민했던 대용량 트래픽 처리와 운영 최적화 이야기, 지금부터 시작합니다.

Chapter 1. 배치가 끝나지 않는다: 병렬 처리의 함정과 Partitioning

전자라벨 시스템의 배치는 상품 데이터 중 변경된 데이터(Delta)를 찾아내는 고된 작업입니다. 초기 버전(V1) 성능 테스트 결과, 복잡한 데이터 집계(Aggregation) 로직으로 인해 1개 매장을 처리하는 데 평균 15분이 소요되었습니다. 이 속도라면 1,300개 매장을 순차적으로 처리할 경우 약 13일(15분 × 1,300개)이 걸린다는 충격적인 결과가 도출됩니다. 매장 오픈 시간(오전 10시)까지 작업을 끝내야 하는 저희에게 이는 말그대로 '불가능한 미션'이었습니다.

V1 성능 테스트 결과표
항목	측정 및 계산 결과	비고
단위 매장 처리 시간	약 15분	복잡한 집계(Aggregation) 로직
전체 대상 매장 수	19,500분 (약 13.5일)	순차 처리 시 소요 기간
목표 완료 시간	매장 오픈 전 (오전 10시)	현실적 달성 불가능

시도: 단순 병렬 처리의 실패 (V2)

이러한 물리적인 시간을 단축하기 위해 저희는 가장 먼저 Scale-out(병렬 처리) 카드를 꺼냈습니다. Spring Batch의 Multi-threaded Step을 적용하여 수십 개의 스레드가 동시에 여러 매장의 데이터를 집계하고 DB에 갱신을 하도록 설정했습니다.

"스레드 수만큼 속도가 선형적으로 증가하겠지"라는 기대와 달리, 배치를 가동하자마자 성능 향상은커녕 터미널은Deadlock Loser 오류로 뒤덮였습니다. 원인은 긴 트랜잭션과 자원 경합에 있었습니다. 복잡한 Aggregation 로직이 실행되는 동안 트랜잭션이 길게 유지되었고, 병렬 스레드들이 동일한 테이블 내의 인접한 인덱스 범위에 대해 동시에 Write를 시도하며 락(Lock) 경쟁을 벌인 것입니다. 결국 스레드들은 서로가 점유한 자원이 해제되기만을 기다리는 교착 상태(Deadlock)에 빠졌고, 시스템은 아무런 처리도 하지 못한 채 멈춰 섰습니다.

해결: Partitioning으로 완성한 10분의 기적 (V3)

그래서 저희는 '스레드 간의 데이터 간섭을 0으로 만들자'는 원칙으로 구조를 전면 개편했습니다. 해답은 Spring Batch Partitioning이었습니다.

Spring Batch Partitioning: 전체 데이터를 PK(Primary Key) 범위 기반으로 논리적 격리를 수행했습니다. (예: ID 1~~1000, 1001~~2000...)
Lock Free 구조: 각 Worker Step은 자신에게 할당된 고유한 PK 범위 내에서만 집계(Aggregation)와 갱신(Update)을 수행합니다.

PK 범위 분할(Partitioning)을 통해 Lock 경합을 제거한 아키텍처 구조(Gemini 생성)

이 방식은 각 워커가 서로 다른 데이터 범위를 처리하므로 물리적으로 자원 침범이 발생하지 않아 DB Lock 경합이 원천 차단되었습니다. Lock이 사라지자 CPU와 I/O 자원을 온전히 데이터 처리에만 쓸 수 있게 되었고, 13일이 걸릴 뻔했던 작업은 단 5분 만에 1,300개 매장 처리를 완료하는 기적 같은 효율을 보여주었습니다.

Partitioning 도입으로 1,300개 매장 배치 처리 시간이 13.5일에서 10분으로 단축된 성능 비교(Gemini 생성)

Chapter 2. 예측 불가능한 폭주를 감당하라: RDS Serverless v2의 탄력성

배치 성능의 문제는 해결했지만, 인프라 운영의 난관이 남았습니다. 우리 서비스의 트래픽은 단순히 '배치 시간'에만 몰리는 것이 아니라, 그 강도(Intensity)를 예측하기 어렵다는 것이 문제였습니다.

평시: 적은 양의 데이터 변경만 발생
프로모션/올영세일 기간: 평소 대비 수십 배, 수백 배의 변경 데이터가 예고 없이 폭주(Burst)

기존의 RDS On-Demand(고정형 인스턴스) 방식으로는 이 변동성을 감당하기 어려웠습니다. 세일 기간을 대비해 항상 최고 사양(Provisioned)을 유지하자니 비용 낭비가 심했고, 그렇다고 평시에 맞춰두자니 갑작스러운 데이터 폭증 시 장애가 발생할 위험이 있었습니다.

시도: 인프라 스스로 숨 쉬게 하라 (RDS Serverless v2)

저희는 이 딜레마를 해결하기 위해 트래픽 양에 따라 실시간으로 DB 자원을 늘리고 줄이는 Aurora RDS Serverless v2 도입을 결정했습니다. 저희가 주목한 핵심 기능은 데이터 폭주가 시작되는 시점에 지연 없이 대응하는 '즉각적이고 중단 없는 확장(Instant & Seamless Scaling)' 입니다. 이는 운영자가 수동으로 개입하지 않아도 시스템이 스스로 트래픽의 파도에 맞춰 숨을 쉬는 구조를 완성해주었습니다.

기존 RDS vs Aurora RDS Serverless v2 비교표
구분	기존 RDS (On-Demand)	Aurora RDS Serverless v2
확장 방식	수동 스케일업 (재부팅 필요)	자동 오토스케일링 (즉시 반영)
다운타임	수 분 발생 (서비스 중단)	없음 (Seamless Scaling)
비용	피크 트래픽 기준 고정 비용	사용량 기반 종량제 과금

검증 및 결과: 예상치 못한 파도타기

도입 후 저희는 Serverless v2가 보여준 야생성에 놀랐습니다. 배치가 시작되고 데이터가 급격히 유입되면, DB의 ACU(Aurora Capacity Unit) 가 수직 상승하며 부하를 받아냈습니다. 반대로 작업이 끝나거나 데이터 양이 적은 날에는 즉시 최저 사양(Min ACU)으로 줄어들어 숨을 고르는 걸 볼 수 있었습니다. 운영자가 "오늘 데이터가 많을까?"를 고민하며 미리 스펙을 올리고 내릴 필요가 없어진 것입니다. 시스템이 데이터의 파도에 맞춰 스스로 서핑을 하는 셈입니다.

Serverless v2의 탄력적 오토스케일링: 배치 처리 중만 높은 ACU 사용, 평시에는 최소 수준 유지(Gemini 생성)

결과적으로 저희는 '성능의 안전판'과 '비용 효율' 이라는 두 마리 토끼를 잡았습니다. 데이터가 적을 땐 확실하게 비용을 아끼고, 폭주할 땐 성능 제한 없이 확실하게 처리하는 '클라우드 네이티브' 환경을 구축함으로써, 고정형 인스턴스 대비 약 40%의 비용 절감 효과를 거둘 수 있었습니다.

마치며: 안정성과 효율성의 균형

이렇게 저희는 1,300개 매장의 데이터를 안정적으로 처리하면서도 비용 효율적인 시스템을 갖추게 되었고, 전자라벨을 도입하며 두 가지 큰 교훈을 얻었습니다.

Application Level: 대용량 데이터 집계(Aggregation)는 단순한 병렬화가 아니라, '데이터의 분할과 정복(Partitioning)' 을 통해 Lock을 회피해야 한다는 점
Infrastructure Level: 클라우드의 이점은 단순히 서버를 빌리는 것이 아니라, 상황에 맞게 '탄력적(Elastic)으로 사용하는 것' 에 있다는 점

이제 종이 라벨이 사라진 자리에는 데이터가 흐르고, 그 데이터는 초단위의 실시간 정보로 진화하고 있습니다. 이어지는 다음 편에서는 "파이프라인 위에서 고객과 직원의 경험을 실시간으로 혁신하는 이벤트 기반 재고 시스템" 이야기로 찾아오겠습니다. 계속해서 많은 기대 부탁드립니다.

참고 자료

오프라인 매장에 코드를 배포하다 Part 1: 종이 없는 매장을 만드는 데이터 파이프라인 구축

Mon, 09 Feb 2026 09:00:00 GMT

들어가며

안녕하세요! 올리브영에서 Back-end 개발을 담당하고 있는 '코드다이버(이시훈)'입니다. 많은 분들에게 오프라인 매장의 가격표는 매우 익숙한 풍경이지만, 그 이면에서 온-오프라인 데이터를 실시간으로 동기화하는 전자라벨(ESL, Electronic Shelf Label)의 메커니즘은 다소 생소하게 느껴지실 겁니다. 그래서 최대한 쉽고 간결하게 설명해드리려고 하니 차근차근 읽어주세요.

🎯 특히 이런 분들께 도움이 될 거예요

오프라인 매장의 디지털 전환(DX) 사례가 궁금하신 분
수백만 개의 IoT 기기를 제어하는 아키텍처가 궁금하신 개발자
레거시 시스템을 단계적으로 개선한 경험이 필요하신 분

💡 요약하자면 이런 기술적 난제를 해결했어요

물리적 부채 해결: 종이라벨 교체에 드는 수동 업무 제거
실시간 동기화: 온-오프라인 재고/가격 데이터 일치
운영 효율화: 매장당 일 평균 2시간 업무 시간 절감

개발자에게 '배포(Deployment)'는 익숙한 일상입니다. 코드를 수정하고, 빌드하고, 서버에 배포하면 끝이죠. 하지만 올리브영의 오프라인 매장에는 오랫동안 '사람의 손으로 직접 수행하는 수동 배포(Manual Deployment)' 시스템이 존재했습니다. 마치 수천 대의 서버에 SSH로 일일이 접속해 파일을 덮어쓰던 시절처럼, 이러한 종이라벨 교체는 매장 직원의 물리적인 리소스를 끝없이 소모하는 작업이었습니다. 이러한 물리적인 제약을 기술로 극복하고, 흩어진 데이터를 모아 동적인 디지털 환경으로 변화시킨 여정의 첫번째 이야기를 지금부터 본격적으로 시작해 보겠습니다.

배경: 규모의 경제가 아닌 '규모의 부채'

본격적으로 이야기를 시작하기 전, 다뤄야 할 숫자를 먼저 이야기 해보겠습니다. 올리브영은 전국에 약 1,300여 개의 매장을 운영하고 있으며, 각 매장에는 수천 개의 상품이 진열되어 있습니다. 이를 전체 매장으로 환산하면 수백만 개의 가격표가 존재한다는 계산이 나옵니다. 이 거대한 규모는 디지털 환경이 아닐 때, 단순한 관리의 대상을 넘어 감당하기 힘든 '부채' 로 다가왔습니다. 수백만 개의 라벨을 사람의 손으로 관리해야 한다는 것, 이것이 저희가 마주한 현실이었습니다.

레거시(Legacy)의 한계: 종이라벨이라는 '물리적 부채'

개발자 관점에서 종이라벨 시스템은 '확장성이 부족하고 업데이트 비용이 높은 정적 뷰(Static View)' 였습니다. 단순한 스티커 부착 작업처럼 보이지만, 그 이면에는 더 큰 비효율이 숨어 있었죠.

프로모션 기간 내 물리적 업무 부담 과중

올리브영의 핵심 경쟁력 중 하나가 다양하고 역동적인 프로모션이다보니 종이라벨 환경은 매장 직원들에게 엄청난 '물리적 부채(Physical Debt)'를 의미했습니다. 특히 올영세일과 같은 대규모 행사가 시작되면, 하룻밤 사이 수천 개의 상품 가격이 변동됩니다. 직원들은 개점 전에 이 수많은 라벨을 모두 새로 출력해 진열대를 일일이 찾아다니며 교체해야 했는데, 이 과정은 단순 반복 노동을 넘어 오프라인 운영의 가장 큰 병목 구간이었습니다.

수천 장의 종이라벨을 수동으로 교체하는 매장의 모습(Gemini 생성)

물리적 지연(Physical Latency)과 동기화 이슈

종이라벨은 현재 상품이 품절인지 아닌지를 실시간으로 보여주지 못합니다. 그래서 고객은 진열대에 상품이 비어있으면 직원에게 "이거 재고 있나요?"라고 묻게 됩니다. 상품이 품절되어도 진열대의 라벨은 여전히 '판매 중' 상태를 유지하기 때문이죠. 이때 발생하는 비효율은 고스란히 직원의 리소스 소모로 이어집니다. 직원은 하던 일을 즉시 중단하고 시스템 조회나 창고 확인을 위해 자리를 비워야 합니다.

이에 저희는 '데이터(재고 유무)가 고객에게 도달하기 위해 반드시 직원의 물리적 개입이 필요한 시간'을 물리적 지연(Physical Latency)이라 정의했습니다. 시스템 관점에서는 매장 운영이라는 메인 루프를 멈추게 만드는 불필요한 I/O Blocking인거죠. 데이터가 스스로 자신을 증명하지 못해 발생하는 이 대기 시간은 결국 매장 전체의 업무 효율을 저하시켰습니다.

실시간 재고 정보 미노출로 인해 발생하는 물리적 지연 상황(Gemini 생성)

정보 표시 유연성 부족 및 마케팅 제약

매장의 진열대는 한정된 공간 내에서 수십 수천 개의 상품이 저마다의 존재감을 드러내야 하는 치열한 공간입니다. 하지만 종이라벨은 정해진 규격 안에 텍스트를 인쇄하는 '정적 렌더링' 방식에 머물러 있었습니다.

개발자 관점에서 이는 UI가 코드에 하드코딩되어 있어 런타임에 변경할 수 없는 상태와 같습니다. 예를 들어, 특정 상품이 '단독 특가' 중일 때는 가격을 강조하고, '증정 행사' 중일 때는 사은품 정보를 부각해야 하는 등 상황에 따른 UI 다형성(Polymorphism)이 필요하지만, 종이라벨은 이러한 동적인 요구사항에 대응할 수 없는 구조적 한계를 가지고 있었습니다. 결국, 프로모션의 성격과 상관없이 천편일률적인 정보만을 제공해야 했고, 이는 곧 오프라인 매장의 마케팅 유연성까지 제약하는 요소가 되었습니다.

유연하지 못한 라벨 UI가 야기하는 매장 현장의 어려움(Gemini 생성)

Architecture: 수백만 IoT 기기를 제어하는 메시지 기반 파이프라인 구축

수많은 상품 정보와 실시간 재고 데이터는 어떻게 전국 매장의 진열대까지 오차 없이 도달할까요? 수천 개의 매장, 수백만 개의 상품 데이터를 실시간으로 동기화하기에는 단순한 API 호출 방식만으로는 한계가 명확했습니다. 매장 네트워크의 일시적인 불안정성이나, 대규모 세일 기간의 트래픽 폭주에도 시스템이 무너지지 않아야 했기 때문입니다. 그래서 저희는 대규모 데이터의 신뢰성 있는 전달을 위해 이벤트 기반의 메시지 파이프라인(Event-driven Message Pipeline)을 설계했습니다.

Conceptual Architecture

Tech Stack

저희는 수백만 개의 IoT 기기를 안정적으로 제어하기 위해 Kotlin과 Spring Boot 3.x를 선택했습니다. 특히 파이프라인 중간에 Message Queue를 도입한 것이 핵심입니다. 이는 전사적인 데이터 폭주를 완충하는 버퍼 역할을 수행할 뿐만 아니라, 네트워크 환경이 제각각인 1,300여 개 매장에 데이터를 비동기로 전달하여 시스템 전체의 가용성을 극대화하기 위한 결정이었습니다.

구분	기술 스택
Language	Kotlin
Framework	Spring Boot 3.x
Messaging	MSK, SQS
Database	Oracle, ElastiCache (Redis)
Storage	S3

클라우드 기반의 데이터 중앙화 (Cloud Centralization)

파편화되어 있던 원천 데이터를 전자라벨(ESL)에 적합한 데이터로 모아 클라우드 환경으로 통합했습니다. 이제는 새로운 아키텍처가 '단일 진실 공급원(Single Source of Truth)' 역할을 합니다. 상품 정보 변경이나 프로모션 시작과 같은 모든 이벤트는 거대한 메시지 파이프라인을 통과합니다. 이 과정에서 DB 부하를 줄이고 속도를 높이며, 장애 복구 능력을 강화했습니다. 최종적으로 가공된 데이터가 각 매장의 게이트웨이로 일관성 있게 전달됩니다. 어떤 매장이든 동일한 시점에 동일한 데이터를 바라볼 수 있도록 보장하는 것입니다.

특히 이 과정에서 레거시 DB에 직접적인 쿼리를 날리는 대신, 이벤트 기반의 데이터 동기화를 택하여 조회 성능을 높이고 원본 시스템의 부하를 원천적으로 차단했습니다. 결과적으로 전국의 모든 매장이 물리적 위치와 상관없이 '가장 최신의, 동일한 데이터'를 바라보는 높은 데이터 일관성을 보장하게 되었습니다.

물리적 거리를 넘는 원격 관제 (Remote Monitoring & Control)

클라우드 아키텍처의 가장 큰 강점은 '현장에 가지 않아도 된다'는 것입니다. 이에 저희는 수백만 개의 IoT 디바이스를 안정적으로 운영할 수 있는 강력한 중앙 관제 시스템을 구축했고, 시스템은 실시간으로 반영된 데이터 및 업데이트 성공 여부를 모니터링하고 있습니다. 예를 들어, 제주도 매장의 특정 라벨 업데이트가 실패했다고 가정해 볼까요? 중앙 시스템은 문제를 즉시 감지하고 자동으로 재시도(Retry) 명령을 내려 해결합니다. 엔지니어가 KTX나 비행기를 타고 현장으로 출동하지 않아도, 서울 본사 사무실에 앉아 원격으로 문제를 진단하고 해결할 수 있는 환경을 구현된 것이죠.

Feature: 물리적 지연을 '0'으로 만드는 기술들

이러한 모든 기술적 노력은 결국 매장 운영의 물리적 비효율을 제거하고, 데이터를 통해 고객과 직원의 경험을 개선하기 위함입니다. 구체적으로 구현한 핵심 기능들은 다음과 같습니다.

상황에 맞는 동적 뷰(Dynamic View) 렌더링

종이라벨의 고질적인 '정보 경직성'을 서버 중심의 템플릿 렌더링 기술로 해결했습니다. 전자라벨은 이제 단순한 가격표가 아니라, 서버에서 전송한 데이터를 실시간으로 시각화하는 단말기 역할을 수행합니다. 프로모션 성격에 맞춰 레이아웃을 동적으로 변경하는 로직을 통해, 한정된 디스플레이 공간 안에서 정보의 우선순위를 자유롭게 조정하며 공간 효율과 전달력을 극대화했습니다.

이벤트 기반의 준실시간 품절 반영

가장 큰 페인 포인트는 고객이 보는 정보와 실제 재고의 불일치였습니다. 과거에는 상품이 품절되어도 그 정보가 고객에게 도달하기까지 직원의 물리적 확인과 개입이 반드시 선행되어야 했습니다. 이것이 앞서 언급한 물리적 지연의 실체입니다. 이제는 시스템이 재고 변동 이벤트(Stock Event)를 실시간으로 감지합니다. 그리고 특정 상품이 품절되는 즉시 관련 데이터가 메시지 파이프라인을 타고 전국의 전자라벨 단말에 도달하며, 화면은 즉시 상태를 갱신합니다. 사람이 개입하지 않아도 시스템이 스스로 온-오프라인의 데이터 정합성을 맞추는 자동 동기화(Auto-Sync) 환경을 구현한 것입니다.

프로모션 자동화와 배치 처리

수작업에 의존하던 대규모 가격 변경 업무를 예약 기반의 배치(Batch) 시스템으로 전환했습니다. 행사 시점에 맞춰 대량의 데이터를 안정적으로 분산 처리하여, 전국 1,300여 개 매장의 가격 정보를 오차 없이 업데이트합니다. 수동 교체 시 발생하던 오기입이나 누락 등의 휴먼 에러를 구조적으로 차단하여 운영 안정성을 비약적으로 높였습니다.

Outcome: 기술이 선물한 '90만+ 시간'의 가치

실제 운영 데이터를 분석한 결과, 다음과 같은 유의미한 성과를 얻을 수 있었습니다.

📈 전자라벨 구축에 따른 주요 성과

도입 규모: 전국 1,300여 개 매장

업무 효율화: 매장당 평균 일 2시간 절감 (라벨 관리 및 재고 응대 리소스 절감)

고객 경험 향상: 상품 큐레이션과 매장 컨디션 관리 등 더 본질적이고 가치있는 고객 경험 개선 업무에 집중

데이터 무결성: 가격 오기입으로 인한 결제 클레임 제로화

대규모 대응력: 올영세일 등 피크 타임 시 수만 건의 가격 변경을 수 분 내 자동 완료

결국 전자라벨 구축은 단순히 종이를 디지털로 바꾼 것이 아니라, 기술을 통해 구성원의 업무 몰입도를 높이고 고객 경험의 질을 한 단계 끌어올린 디지털 트랜스포메이션의 결실이었습니다.

마치며: 디지털로 연결된 매장

올리브영은 계속해서 데이터와 기술로 온라인과 오프라인을 연결하고 있습니다. 그 중에서도 전자라벨 구축은 올리브영의 오프라인 매장이 더 이상 정적인 공간이 아니라, 데이터와 소프트웨어로 제어 가능한 영역으로 확장되었음을 의미합니다. 하지만 이러한 시스템 구축은 거대한 여정의 시작일 뿐이었습니다.

시스템 구축 이후 올영세일 기간마다 갱신되는 트래픽 폭풍 속에서 어떻게 전국 매장을 동기화했는지 궁금하지 않나요? 이렇게 더 깊이 있는 전자라벨 구축기가 궁금한 분들을 위해 준비한 두 번째 이야기, "오프라인 매장에 코드를 배포하다 Part 2: 올리브영 전자라벨(ESL) 최적화 여정" 은 아키텍처 이면에 숨겨진 치열한 성능 개선기와 실전 운영 노하우를 본격적으로 다루고 있습니다. 가장 아날로그적인 공간을 가장 디지털적인 방법으로 혁신해 나가는 올리브영의 DX 과정이 궁금한 분들께는 분명 흥미롭게 읽힐 내용이니 계속해서 많은 관심 부탁드립니다. 감사합니다.

올리브영 대규모 트래픽 레거시 시스템의 무중단 OAuth2 전환기

Fri, 30 Jan 2026 15:00:00 GMT

안녕하세요, 올리브영에서 인증 시스템을 개발하는 망고입니다.

커머스 플랫폼에서 사용자의 진짜 여정은 로그인에서 시작됩니다. 로그인에 성공하면 사용자는 "인증"된 상태로 사이트를 이용할 수 있게 되며, 특히 올리브영과 같은 커머스 플랫폼에서 인증은 주문, 결제, 배송 조회 등 모든 핵심 기능의 전제 조건입니다. 그렇다 보니 인증 시스템이 평소에는 조용히 제 역할을 하다가, 문제가 생기면 모든 서비스 담당자의 이목이 집중되는 가장 중요하고도 영향력있는 인프라입니다. 로그인이 풀리거나 세션이 끊기면 장바구니가 비워지고, 결제에 실패합니다. 이 때 사용자는 당황스러운 경험을 하게 됩니다. 그래서 인증 시스템을 건드리는 것은 언제나 조심스러운 일입니다.

2025년 3월부터 10월까지, 저희 스쿼드는 올리브영 온라인몰의 레거시 세션 기반 인증을 OAuth2로 전환하는 프로젝트를 진행했습니다. 전체 배포 이후 2주 뒤에 평소 대비 10배의 대규모 트래픽을 처리해야 하는 정기 플래그십 이벤트 '올영세일'을 앞두고 있었기 때문에 모든 기능을 포괄하는 OAuth2 표준을 완벽히 구현하기보다, 기존 서비스의 '핵심 기능'을 보호하고 무중단 전환을 보장하는 '안전 구조'를 최우선 목표로 삼아 '중단 없이, 장애 없이' 배포했습니다. 이 과정에 겪은 기술적 도전과 해결 과정을 공유합니다.

1. 들어가며: 대규모 트래픽 환경에서의 인증 체계 교체

1.1 왜 인증 체계를 바꿨나

기존 시스템은 Spring Session 기반이었고, 자동 로그인을 위한 별도 쿠키를 사용했습니다. 이 방식은 다음 세 가지 측면에서 명확한 한계와 비즈니스/기술적 제약을 가져왔습니다.

확장성 및 복잡성 문제: 세션-쿠키의 혼재 구조로 인해 인증 로직이 복잡함, 새로운 마이크로서비스들이 중앙의 세션 Redis에 의존해야 했기 때문에, 마이크로서비스 환경으로의 전환과 독립적으로 인증할 표준 필요
보안 및 제어의 한계: 로그아웃 시에도 자동 로그인 쿠키가 유효하여, 도난/분실 시 보안 사고에 즉시 대응할 수 있는 메커니즘이 부재하였고, 특정 기기에서만 로그아웃하는 기기별 세션 관리가 불가능하여 짧은 수명의 토큰을 통해 노출 시간을 최소화할 필요 있었음
비즈니스 확장성 제약: 복잡한 레거시 인증 로직으로 인해 외부 서비스 연동이나 신규 서비스 론칭 시 인증 연동에 큰 공수가 소요되어 비즈니스 확장 속도 저해

OAuth2를 선택한 이유는 단순 JWT 대신 검증된 표준 프레임워크가 필요했기 때문입니다.

Refresh Token 무효화 가능 (RFC 7009)
짧은 Access Token + 긴 Refresh Token 조합
멀티 토큰 관리 표준 제공
향후 OIDC(OpenID Connect, OAuth2 기반의 사용자 신원 확인 계층 표준)로 자연스럽게 진화 가능

1.2 핵심 도전

가장 큰 과제는 무중단 마이그레이션이었습니다. 특히 8월 말 올영세일 기간 중에는 평소 대비 약 10배의 트래픽이 몰리는 상황에서도 안정적으로 전환을 진행해야 했습니다. 이에 이 글에서는 "왜 바꿨는지"보다 "어떻게 안전하게 바꿨는지"에 초점을 맞춥니다. 특히 다음 기술들에 대해 상세히 다루고 있으니 참고하며 읽어주세요.

Feature Flag 위임 패턴 - 세일 중에도 점진적 전환
점진적 롤아웃 전략 - 10% → 100% 단계적 확대
Jitter 도입 - Peak TPS 40% 감소
Resilience4j 장애 격리 - Circuit Breaker로 안정성 확보

[참고로 OAuth2나 JWT의 기본 개념은 다루지 않습니다. 대신 대규모 트래픽 환경에서 실제로 동작하는 구현 패턴과 최적화 기법에 집중합니다.]

2. Fail-Safe Architecture: 안전한 전환을 위한 4가지 전략

무중단 마이그레이션의 핵심은 언제든 되돌릴 수 있어야 한다는 원칙이었습니다. 코드 배포 없이 런타임에 인증 방식을 전환하고, 문제 발생 시 즉시 롤백할 수 있는 구조가 필요했습니다.

2.1 Feature Flag 위임 패턴 (런타임 전환)

Feature Flag 기반 위임 패턴을 적용했습니다. 하나의 진입점(FeatureFlagDelegatingInterceptor)에서 사용자별로 다른 인증 방식으로 요청을 위임하는 구조입니다.

그림 1. Feature Flag 기반 위임 패턴 - 런타임에 인증 방식을 동적으로 전환하는 구조

2.2 구현 상세: Strategy 패턴으로 안전한 전환

Feature Flag 위임 패턴을 실제로 구현하기 위해 FeatureFlagDelegatingInterceptor를 중심으로 Strategy 패턴을 적용했습니다. 이 인터셉터는 Feature Flag 값에 따라 적절한 인터셉터 체인을 선택하는 역할을 담당합니다.

먼저 전체 아키텍처를 살펴보겠습니다. 아래 다이어그램은 HTTP 요청이 들어왔을 때 어떻게 처리되는지 보여줍니다.

그림 2. Feature Flag 기반 위임 패턴의 전체 요청 처리 흐름

HTTP 요청이 들어오면 FeatureFlagDelegatingInterceptor가 모든 요청을 가로챕니다. 그 다음 FeatureFlagService를 통해 Database에서 기능플래그를 조회하고, 기능플래그 확인 분기점에서 Yes/No를 결정합니다. 이 결정에 따라 JWT 활성화 또는 JWT 활성화되지 않음 경로로 분기되며, 각각 JWT AuthenticationInterceptor 또는 Legacy AuthenticationInterceptor가 실행됩니다. 마지막으로 Request attribute에 Phase 정보를 저장한 후 최종적으로 Spring Controller로 전달됩니다.

이러한 흐름을 구현한 핵심 코드는 다음과 같습니다.

public class FeatureFlagDelegatingInterceptor extends HandlerInterceptorAdapter {

    @Override
    public boolean preHandle(HttpServletRequest request,
                            HttpServletResponse response,
                            Object handler) throws Exception {
        // 1. Feature Flag 확인 (Database 조회)
        boolean isPhase2Enabled = loginTokenFlagService.activatePhase2(request, response);

        // 2. Phase 정보 저장 (모니터링용)
        request.setAttribute("oauth.phase.version", isPhase2Enabled ? "2.0" : "1.0");

        // 3. Strategy 패턴: 동적으로 인터셉터 선택
        if (isPhase2Enabled) {
            return executePhase2Chain(request, response, handler);  // JWT
        } else {
            return executeLegacyChain(request, response, handler);   // Legacy
        }
    }
}

이 구현은 네 가지 핵심 설계 원칙을 따릅니다.
첫째, 단일 진입점을 통해 모든 요청이 하나의 인터셉터를 거치도록 했습니다.
둘째, 런타임 분기를 통해 Database 설정만으로 즉시 전환할 수 있게 했습니다.
셋째, 안전한 Fallback으로 오류 시 자동으로 Legacy 모드로 전환됩니다.
넷째, 완전한 격리를 통해 Phase 2와 Phase 1 로직이 독립적으로 동작하도록 했습니다.

그렇다면 Feature Flag는 어떻게 Phase를 결정할까요? 우리는 임직원을 대상으로 선정하되, 비로그인 사용자는 제외하는 것으로 기준을 설정하고 단계를 나눴습니다.

임직원을 첫 배포 대상으로 선택한 이유는 실제 운영 환경에서의 검증이 필요했기 때문입니다. 개발 서버에서 아무리 테스트해도 실제 사용자 환경에서만 발견되는 문제들이 있습니다. 특히 쿠키처럼 개인 기기와 브라우저 설정에 따라 동작이 달라지는 기능의 경우, 다양한 환경에서의 실제 검증이 필수적입니다. 임직원 대상 Beta Test를 통해 피드백을 받으면서 실 사용자에게서 발생할 수 있는 오류를 사전에 체크할 수 있었습니다.

비로그인 사용자를 제외한 이유는 간단합니다. OAuth2 기반 자동 로그인은 로그인한 사용자만을 대상으로 하기 때문에, 비로그인 사용자는 애초에 전환 대상이 아닙니다.

이러한 배경을 바탕으로 Feature Flag는 3단계 체크를 통해 Phase를 결정합니다.

@Service
public class LoginTokenFlagServiceImpl implements LoginTokenFlagService {

    @Override
    public boolean activatePhase2(HttpServletRequest request,
                                 HttpServletResponse response) {
        try {
            Customer customer = getCustomer(request, response);

            // 1. All Open Flag 확인 (전체 공개)
            if (isFlagEnabled(config.get("oauth.flag.code.phase2.all"))) {
                return true;  // 모든 사용자에게 Phase 2 적용
            }

            // 2. 비로그인 사용자는 Phase 1 사용
            if (customer == null || !customer.isLoggedIn()) {
                return false;
            }

            // 3. Staff Open Flag 확인 (임직원 대상)
            if (isFlagEnabled(config.get("oauth.flag.code.phase2.staff"))) {
                return isStaff(customer);
            }

            return false;  // 기본값: Phase 1

        } catch (Exception e) {
            // 오류 시 안전하게 Phase 1으로 Fallback
            return false;
        }
    }
}

Feature Flag는 다음과 같은 단계로 구성됩니다.

단계	Flag	설명	대상
0	(모두 비활성)	Phase 1만 사용	전체
1	`phase2.staff` = Y	임직원 대상 테스트	내부 검증
2	`phase2.all` = Y	전체 공개	모든 사용자

이러한 구조 덕분에 데이터베이스 설정만 변경하면 코드 배포 없이 즉시 전환할 수 있었습니다. 또한 각 요청마다 Phase 정보를 로깅해 Datadog에서 Phase별 트래픽 분포, 에러율, 응답시간을 실시간으로 추적할 수 있었습니다. 이를 통해 점진적 롤아웃 과정에서 두 Phase 간 성능을 비교하고 안정성을 검증했습니다.

결과적으로 이 위임 패턴은 Feature Flag 값 변경만으로 인증 방식을 즉시 전환할 수 있었고, 예외가 발생하면 자동으로 Legacy로 처리되는 안전한 Fallback을 제공했습니다. Phase 2와 Phase 1 코드는 완전히 격리되어 독립적으로 동작했으며, 코드 배포 없이 DB 설정만 변경하는 무중단 배포가 가능했습니다. 임직원부터 시작해 일부 사용자를 거쳐 전체로 확대하는 세밀한 제어가 가능했고, 각 Phase별 성능 메트릭을 실시간으로 추적할 수 있었습니다.

Feature Flag 위임 패턴으로 런타임 전환 구조를 만들었다면, 이제 실제로 어떻게 사용자를 단계적으로 전환했는지 살펴보겠습니다.

2.3 점진적 롤아웃 전략 (10% → 100%)

Feature Flag를 통해 사용자별로 단계적으로 확대하는 전략을 수립했습니다. 핵심은 문제 발생 시 즉시 되돌릴 수 있는 안전장치를 유지하면서 점진적으로 범위를 넓혀가는 것이었습니다.

점진적 롤아웃 일정은 다음과 같았습니다.

날짜	전환율	단계
07/28 (월)	10%	첫 배포 - 내부 검증
07/29 (화)	10%	안정성 모니터링
07/30 (수)	20%	+10% 확대
08/01-11	20%	2주간 안정화
08/12 (화)	50%	+30% 확대
08/13 (수)	75%	+25% 확대
08/14-15	75%	대규모 검증
08/16 (토)	100%	전체 배포 완료

Shadow Mode: 토큰 선배포 전략

본격적인 전환 전, Phase 1에서는 토큰을 "발급만" 하고 실제 인증에는 사용하지 않았습니다. 기존 세션 기반 인증은 그대로 유지하면서, 백그라운드에서 OliveToken(Access Token, Refresh Token)을 함께 발급하는 방식입니다. 즉, 기존 세션과 새로운 토큰이 공존하는 상태에서 안정성을 먼저 검증한 것입니다. 이 전략의 핵심 목적은 아래 두 가지였습니다.

성능 검증: 토큰 발급 로직이 실제 트래픽에서 안정적으로 동작하는지 확인
토큰 선배포: 최대한 많은 사용자에게 미리 토큰을 발급

토큰 선배포가 중요한 이유는, 나중에 세션에서 토큰 기반으로 전환할 때 토큰이 없는 사용자는 로그아웃되기 때문입니다. 미리 사용자의 "주머니"에 토큰을 넣어두면, 실제 전환 시점에 자연스럽게 로그인이 유지됩니다.

롤아웃 전략은 다음과 같습니다.

점진적 확대: 10% → 20% → 50% → 75% → 100%
- 각 단계마다 2-14일의 안정화 기간 확보
- 50% 이전까지는 신중하게 진행 (2주간 20% 유지)
단계별 목적
- (임직원 대상): 내부 검증
- 10%: 기본 동작 검증
- 20%: 초기 사용자 피드백
- 50%: 대규모 트래픽 검증, 성능 이슈 확인
- 75%: 올영세일 전 최종 검증
- 100%: 전체 전환
최종 목표: 올영세일 대비
- 100% 전환 완료 후 2주 버퍼를 두고 올영세일 진입
- 평시 트래픽에서 100% 안정성 확인 = 올영세일 준비 완료
- 올영세일 = 실전 대규모 트래픽 검증

08/16 - 100% 배포 완료
  ↓
08/16~28 - 2주간 안정화
  ↓
08/29 - 올영세일 시작 (평소 대비 10배 트래픽)

올영세일 기간 중 실전 트래픽에서 새로운 인증 체계를 검증했습니다. 평소 대비 10배의 트래픽 상황에서도 안정적으로 작동했습니다.

그림 3-1. 올영세일 기간 Latency 모니터링 (P50/P75/P95)

그림 3-2. 올영세일 기간 요청량 추이

그림 3-3. 올영세일 기간 에러율 (0% 유지)

실제 운영 메트릭 (2025.08.29-09.04, 올영세일 기간)입니다.

지표	측정값	비고
P50 레이턴시	약 5ms	50% 요청이 10ms 이하
P75 레이턴시	약 35ms	75% 요청이 40ms 이하
P95 레이턴시	약 50ms	95% 요청이 50ms 이하
리소스 사용률	CPU/메모리 30-35%	안정적 범위 유지
성공률	100%	전 기간 무장애 운영

이 수치들이 말해주는 핵심 성과는 명확했습니다. 세일 기간 중에도 절반의 요청이 5ms 이내에 처리되었고, 95%의 요청이 50ms 이내에 완료되는 매우 빠른 응답 속도를 유지했습니다. 리소스 사용률은 30-35% 수준을 유지하며 여유 있는 운영이 가능했고, 100% 성공률로 전 기간 무장애 운영을 달성했습니다. 약 5ms, 약 35ms, 약 50ms 수준의 레이턴시가 전 기간 동안 일관성을 유지하며 안정적인 성능을 보여주었습니다.

결국 Feature Flag 위임 패턴의 진정한 가치는 이 순간에 드러났습니다. 코드 배포 없이 런타임에서 전환할 수 있었고, 문제가 생기면 즉시 롤백할 수 있었으며, 사용자별로 세밀하게 제어할 수 있었습니다. 무엇보다 중요한 것은 평소 대비 10배의 트래픽이 발생하는 세일 기간에도 안전하게 전환을 완료할 수 있었다는 점입니다.

점진적 롤아웃으로 안전하게 전환을 완료했지만, 대규모 트래픽 환경에서 또 다른 최적화 포인트를 발견했습니다.

2.4 Jitter 도입 (Peak TPS 40% 감소)

Feature Flag로 점진적 전환을 준비했지만, 또 다른 문제가 남아있었습니다. 대규모 동시 접속 시 토큰 갱신 요청이 특정 시점에 집중되는 현상이었습니다. 세일 기간 중 넷퍼널(Net Funnel) 대기 상황을 예로 들어보겠습니다.

09:00:00 - 넷퍼널 오픈, 5,000명 동시 입장
         → 5,000건 로그인 요청 (초당 5,000 TPS)

09:05:00 - 정확히 5분 후, Access Token 만료
         → 5,000건 토큰 갱신 요청 (초당 5,000 TPS)

09:10:00 - 또 다시 5분 후
         → 5,000건 토큰 갱신 요청 (초당 5,000 TPS)

그림 4. Access Token 만료 시점에 토큰 갱신 요청이 집중되는 문제

Access Token의 만료 시간은 5분으로 고정되어 있기 때문에, 갱신 요청이 5분 간격으로 스파이크를 만들었습니다. 이 문제를 해결하기 위해 Jitter(무작위 지연)를 적용했습니다. 토큰 만료 시간에 ±30초의 랜덤 값을 추가하는 방식입니다.

핵심 아이디어는 간단합니다. 각 토큰마다 독립적인 랜덤 만료 시간을 부여하되, 설정을 통해 활성화/비활성화할 수 있게 했습니다. 사용자 경험에는 영향이 없습니다. ±30초는 사용자가 인지할 수 없는 수준이기 때문입니다.

그렇다면 Jitter 적용의 효과는 어땠을까요? 아래 그래프에서 확인할 수 있습니다. 막대 그래프는 Access Token이 고정 5분일 때 Refresh API에 가해지는 부하이고, 선 그래프는 Jitter(±30초)가 적용되었을 때의 부하입니다.

그림 5. Jitter 도입으로 Peak TPS가 40% 감소한 모습

결과를 정리하면 다음과 같습니다.

지표	Jitter 없음	Jitter 적용	개선
Peak TPS	5,000	3,000	-40%
평균 TPS	1,000	1,000	동일
요청 분산	5분 간격 집중	1분 간격 분산	✓
시스템 안정성	주기적 부하	평준화된 부하	✓

Jitter 도입의 가치는 분명했습니다. 순간 최대 부하가 5,000 TPS에서 3,000 TPS로 40% 감소했고, 급격한 스파이크가 제거되어 부하가 평준화되었습니다. Auto Scaling이 대응할 시간을 확보함으로써 시스템 안정성이 크게 향상되었으며, ±30초의 차이는 사용자가 전혀 인지할 수 없는 수준이어서 사용자 경험에는 영향을 주지 않았습니다. 이러한 Jitter 적용을 통해 세일 기간과 같은 고부하 상황에서도 안정적인 서비스를 제공할 수 있었습니다.

2.5 Resilience4j 장애 격리 (Circuit Breaker)

OAuth2 전환 과정에서 또 하나의 중요한 고려사항이 있었습니다. 부하 최적화와 함께, 외부 서비스 장애에 대한 대비도 필요했던 거죠. 실제로 Authorization Server에 장애가 발생하면 어떻게 될까요? 토큰 발급과 갱신이 모두 외부 서버에 의존하는 구조에서, 해당 서버의 장애가 전체 서비스 중단으로 이어질 수 있었습니다.

OAuth2 인증 흐름은 로그인할 때 Token 발급을 요청하고, 토큰을 갱신할 때 Refresh를 요청하며, 로그아웃 시 Token 폐기를 요청하고, 로그인 기기를 조회할 때 Active Device 조회를 요청합니다. 모든 단계에서 Authorization Server를 호출합니다. 만약 이 서버가 느려지거나 응답하지 않으면 어떻게 될까요? 요청이 무한정 블로킹되어 스레드가 고갈되고, 하나의 장애가 전체 시스템으로 전파되며, 결국 로그인이 불가능해져 전체 커머스 기능이 마비됩니다.

이 문제를 해결하기 위해 Resilience4j의 Circuit Breaker를 도입했습니다. Circuit Breaker는 전기 회로의 차단기처럼 작동합니다. 정상 상태에서는 모든 요청을 통과시키다가, 실패율이 50%를 초과하면 회로를 열어(OPEN) Authorization Server 호출을 차단하고 즉시 실패를 반환합니다. 30초 대기 후에는 반열림 상태(HALF_OPEN)로 전환되어 일부 요청만 허용해 서버 회복을 확인하고, 성공하면 다시 정상 상태(CLOSED)로 돌아가 정상 운영을 재개합니다.

그림 6. Circuit Breaker의 3가지 상태(CLOSED, OPEN, HALF_OPEN)와 전환 조건

실제 설정 예시를 살펴보겠습니다.

resilience4j:
  circuitbreaker:
    instances:
      OYAuthorizationApi:
        # 실패율 임계값
        failureRateThreshold: 50              # 50% 이상 실패 시 OPEN
        slowCallRateThreshold: 50             # 50% 이상 느린 호출 시 OPEN
        slowCallDurationThreshold: 3000       # 3초 이상을 "느림"으로 간주

        # 측정 윈도우
        slidingWindowType: COUNT_BASED        # 호출 횟수 기반
        slidingWindowSize: 100                # 최근 100번 호출 기준
        minimumNumberOfCalls: 10              # 최소 10번 호출 후 판단

        # 상태 전환
        waitDurationInOpenState: 30000            # OPEN 상태 30초 유지
        permittedNumberOfCallsInHalfOpenState: 5  # HALF_OPEN에서 5번 테스트

        # 자동 상태 전환
        automaticTransitionFromOpenToHalfOpenEnabled: true

실제 코드로 구현할 때는 @CircuitBreaker 어노테이션과 함께 @TimeLimiter, @Retry를 조합하여 다층 보호 체계를 구축했습니다.

@Service
public class AuthorizationServerClient {

    @CircuitBreaker(name = "authorizationServer", fallbackMethod = "fallbackResponse")
    @TimeLimiter(name = "authorizationServer")
    @Retry(name = "authorizationServer")
    public ResponseEntity<TokenResponse> callAuthorizationServer(TokenRequest request) {
        // Authorization Server 호출 (Circuit Breaker 보호)
        return restTemplate.postForEntity(
            authServerUrl + "/oauth2/token",
            request,
            TokenResponse.class
        );
    }

    // Circuit Breaker OPEN 시 또는 예외 발생 시 실행
    private ResponseEntity<TokenResponse> fallbackResponse(
            TokenRequest request,
            Exception exception) {

        log.warn("Circuit breaker activated: {}", exception.getMessage());

        // Fallback 전략에 따라 처리

        return someFallbackMethod(request);
    }
}

이 코드가 실제로 어떻게 동작하는지 살펴보겠습니다. 정상 상황에서는 Authorization Server를 정상적으로 호출합니다. 그러다가 최근 100번의 호출 중 50번 이상이 실패하면 Circuit이 OPEN 상태로 전환되고, 이후 들어오는 모든 요청은 Authorization Server를 호출하지 않고 즉시 fallback 메서드로 처리됩니다. 30초가 지나면 자동으로 일부 요청만 허용해 서버 상태를 확인하고, 정상이면 다시 모든 트래픽을 통과시킵니다.

하지만 Circuit Breaker만으로는 충분하지 않았습니다. Timeout과 Retry를 함께 적용해야 했습니다.

resilience4j:
  timelimiter:
    instances:
      OYAuthorizationApi:
        timeoutDuration: 3s        # 3초 타임아웃

  retry:
    instances:
      OYAuthorizationApi:
        maxAttempts: 2             # 최대 2회 시도 (원본 1회 + 재시도 1회)
        waitDuration: 100          # 재시도 간격 100ms
        retryExceptions:
          - java.net.SocketTimeoutException
          - java.net.ConnectException

이 세 가지 보호 장치가 어떻게 협력하는지 살펴보겠습니다.

Request
  ↓
[Timeout: 3초] ─────→ 3초 초과 시 실패
  ↓
[Retry: 최대 2회] ───→ 네트워크 오류 시 재시도
  ↓
[Circuit Breaker] ───→ 반복 실패 시 차단
  ↓
Authorization Server

요청이 들어오면 먼저 Timeout이 3초 제한을 걸고, 네트워크 오류가 발생하면 Retry가 최대 2회까지 재시도하며, 그래도 계속 실패하면 Circuit Breaker가 회로를 차단합니다. 이렇게 3단계 보호 체계를 구축함으로써 단일 실패 지점을 제거하고 시스템 안정성을 확보했습니다.

이 시스템이 어떻게 작동했는지는 2025년 9월에 발생한 실제 사례를 통해 확인할 수 있었습니다. 당시 Authorization Server의 응답 시간이 정상 상태인 3초에서 10초 이상으로 급증하는 장애가 발생했습니다. Circuit Breaker는 실패율이 50%에 도달하자 즉시 OPEN 상태로 전환되었고, 이후 들어오는 모든 요청은 Authorization Server를 호출하지 않고 Fallback 전략으로 처리되었습니다. Fallback 전략은 Graceful Degradation 모드로 동작해 기존 세션 인증 방식으로 자동 대체되었고, 사용자는 서비스 중단 없이 계속 이용할 수 있었습니다. 30초 후 Circuit Breaker는 HALF_OPEN 상태로 전환되어 서버 정상화를 확인했고, 정상 응답을 받자 다시 CLOSED 상태로 돌아가 정상 운영을 재개했습니다. 전체 영향은 약 2분간 일부 요청이 Fallback으로 처리된 것뿐이었고, 실제 서비스 중단은 없었습니다.

이 사례가 보여주는 핵심 가치는 명확합니다. 외부 서버 장애가 전체 서비스로 전파되지 않았고, 자동 복구 덕분에 수동 개입이 필요하지 않았으며, 사용자는 어떤 영향도 느끼지 못했습니다.

결국 Resilience4j를 도입한 가장 큰 성과는 장애 격리였습니다. Authorization Server에 문제가 생겨도 전체 서비스로 확산되지 않았습니다. 빠른 실패 전략으로 타임아웃을 기다리지 않고 즉시 fallback으로 처리했고, 자동 회복 메커니즘 덕분에 서버가 정상화되면 자동으로 트래픽을 재개했습니다. 무엇보다 스레드 보호가 중요했습니다. 블로킹으로 인한 스레드 고갈을 방지함으로써 시스템 전체가 마비되는 최악의 상황을 막았습니다. 그리고 실시간 모니터링을 통해 장애 상황을 즉시 감지하고 대응할 수 있었습니다.

3. 마치며

6개월간의 OAuth2 전환 프로젝트를 되돌아보면, 성공의 핵심은 완벽한 기술이 아니라 안전한 접근 방식이었습니다. Feature Flag로 언제든 되돌릴 수 있는 구조를 만들고, 10%부터 시작해 점진적으로 확대하며, Circuit Breaker로 장애를 격리했습니다.

가장 중요했던 것은 완벽보다 안정성을 우선했다는 점입니다. 이론적으로 괜찮을 것이라는 가정이 아닌, 실제 트래픽으로 검증하고 작은 실패를 빠르게 경험하며 큰 실패를 예방했습니다. Authorization Server는 언제든 장애날 수 있다는 전제로 모든 안전장치를 설계했고, 그 결과 올영세일이라는 가장 중요한 순간에도 안전하게 전환을 완료할 수 있었습니다.

레거시 시스템 전환을 고민 중이라면, 안전하게 되돌릴 수 있는 구조를 먼저 만들고, 테스트 환경이 아닌 실제 사용자로 검증하며, 장애를 가정한 설계로 시작하시길 권장합니다. 올리브영의 인증 체계는 이제 OAuth2를 기반으로 OIDC 도입을 준비하며 계속 진화하고 있습니다. 이 글이 같은 고민을 하는 개발자분들께 도움이 되길 바라며 글을 마치겠습니다. 감사합니다.

참고자료

OAuth2 및 인증 표준

장애 격리 패턴

T4 GPU 1장으로 일궈낸 올리브영의 Gemma 3 기반 sLLM 구축기

Wed, 21 Jan 2026 00:00:00 GMT

안녕하세요! 😆 지난 포스팅인 'ItemLM: 상품 정보 기반의 임베딩 생성기'에 이어 두 번째로 인사드립니다.
저는 올리브영에서 머신러닝으로 다양한 문제를 풀고 있는 🪄 데이터 사이언티스트 입니다.

지난 글에서 상품 데이터를 효율적으로 다루는 기초 체력을 다뤘다면, 이번에는 최신 오픈소스 모델을 기반으로 상용 모델 대비 95%의 정확도를 유지하면서도 운영 비용은 획기적으로 낮춘, 올리브영의 sLLM(Small LLM) 구축 경험을 공유하려 합니다. 🥂

올리브영의 첫 sLLM 학습기

그 중에서도 자체 학습시킨 sLLM을 서비스에 도입한 첫 번째 사례, '리뷰 테마 추천' 시스템을 소개합니다.

아래 이미지와 같이 올리브영 앱을 켜면 보이는 '인기 리뷰 추천 테마' 영역은 단순히 상품을 보여주는 일반적인 추천이 아닙니다. 사용자들이 남긴 방대한 리뷰 데이터를 sLLM이 분석하여, "복합성 피부에 딱 맞는 클렌징 워터"나 "합리적인 가격에 품질 좋은 헤어 트리트먼트"처럼 사용자의 고민과 니즈에 딱 맞는 '추천 테마'를 매력적인 문구와 이미지로 자동 생성해 제안하는 공간입니다.

그림 1. Intro

실제로 존재하는 생생하고 다양한 상품에 대한 고객의 표현을 녹여 추천 카드로 탄생시킨 건데요, 이 과정은 단순한 모델 개발 그 이상의 도전이었습니다. "고가의 상용 API 없이 Tesla T4 GPU 1장이라는 제한된 환경에서 과연 상용 모델급의 고성능을 낼 수 있는가?"라는 질문에 대한 기술적 해답을 찾아가는 여정이었기 때문입니다. 저사양 GPU 환경이라는 제약을 딛고 상용 모델 못지않은 고품질 sLLM을 완성하기까지 치열하게 고민했던 해결 과정을 '올리브영 리뷰테마 추천 시스템'을 예로 들어 상세히 소개해 보겠습니다.

그림 2. 리뷰 테마 추천 화면 UX

리뷰테마 추천 시스템의 컴포넌트

리뷰 테마 추천 시스템은 리뷰 분류부터 표현 추출, 검증, MAB(Multi-Armed Bandit) 기반 전시 최적화까지 다양한 컴포넌트로 연결되어 있습니다. 본문에서는 전체 구조 중 sLLM이 활약하는 영역에만 집중합니다. 특히 사용자 리뷰를 매력적인 추천 문구로 탄생시키는 '표현 생성 모델'의 학습 과정을 중심으로 심층적인 기술 노하우를 공유합니다.

그림 3. 리뷰 테마 추천을 위한 모델 추론 플로우

상용 모델 대신 자체 sLLM을 선택한 이유

이 프로젝트는 "사용자들의 생생한 리뷰로부터 최적의 추천 문구를 자동으로 생성하자"라는 비즈니스 요구에서 출발했습니다.

추천 문구는 "합리적인 가격에 품질 좋은 헤어 트리트먼트"처럼 자연스러우면서도 다양한 조합이 필요했기 때문에, 고정된 패턴만 다루는 규칙 기반(Rule-based) 시스템으로는 품질과 확장성 측면에서 명확한 한계가 있었습니다.

이에 따라 자연어 생성이 가능한 LLM을 사용하기로 결정했고, 특히 상용 LLM API를 직접 호출하는 방식과 오픈소스 sLLM을 자체 학습(SFT)하는 방식을 면밀히 비교 검토했습니다. 최종적으로는 sLLM SFT 방식을 선택했으며, 결정적 이유는 다음과 같습니다.

재현성과 버전 통제

상용 LLM API는 제공사의 모델 업데이트에 따라 동일한 프롬프트라도 응답 품질이나 스타일이 예측 불가능하게 변할 수 있습니다. 리뷰테마 추천처럼 안정적인 품질의 결과를 지속적으로 제공해야 하는 서비스에서는, 학습 데이터, 코드, 체크포인트를 직접 관리하고 언제든 동일한 결과를 재현할 수 있는 구조가 필수적이었습니다.

프롬프트 엔지니어링의 한계 극복

상용 모델을 운영 수준의 품질로 사용하려면, 프롬프트에 조건·예시·제약을 반복해서 추가해야 합니다. 그러나 프롬프트가 길어질수록 토큰 비용이 급증하고 응답 시간이 늘어납니다. 또한 모델이 모든 지시사항을 완벽히 따르기 어려워집니다. 반면 SFT를 통해 지시사항과 출력 형식을 모델에 직접 학습시키면, 훨씬 짧은 프롬프트만으로도 안정적이고 정확한 결과를 얻을 수 있습니다.

운영 비용의 예측 가능성

API 방식은 호출량에 비례해 비용이 급증하는 구조이기 때문에, 트래픽이 급증하는 상황에서 비용 통제가 어렵습니다. 반면 자체 GPU 환경에서 운영하는 sLLM은 시간당 고정된 서버 비용 내에서 명확히 예측·통제 가능하며, 서비스 규모가 커져도 비용 상한선을 관리하기 용이합니다.

비용과 품질을 동시에 잡는 자체 sLLM의 이점

초기에는 상용 LLM API를 그대로 사용하는 방식과 오픈소스 sLLM을 직접 SFT하는 방식을 모두 검토했습니다. 결과적으로 아래와 같은 이유로 소형 오픈소스 LLM을 직접 학습(sLLM SFT) 하는 방향을 선택했습니다.

SFT (Supervised Fine-Tuning)
기초 교육을 마친 신입사원(Base Model)에게 올리브영만의 업무 매뉴얼(데이터)을 집중적으로 가르쳐 우리 부서에 딱 맞는 인재로 만드는 과정입니다.

표 1. 상용 LLM API와 오픈소스 sLLM SFT 방식 비교

구분	상용 LLM API	오픈소스 sLLM SFT
성능 (파라미터 규모)	20B 이상 대형 모델 중심, 전반적으로 높은 성능	9B 이하 소형 모델 중심, 절대 성능은 상대적으로 낮음
재현성	동일 프롬프트라도 응답 변화 가능, 내부 업데이트에 영향 받음	학습·체크포인트 고정으로 재현성 확보 가능
프롬프트 복잡성	운영 수준의 완성도를 위해 매우 긴 프롬프트·다단계 호출 필요	원하는 형태의 Ground Truth를 학습해 프롬프트를 단순화 가능
버전 통제	모델 버전·동작 변경을 제어하기 어려움	모델·데이터·코드를 모두 내부에서 버전 관리 가능
속도	클라우드 인프라 기반으로 대체로 빠름	디바이스 성능에 의존. 단, 적절한 서버/GPU 구성 시 충분히 빠름
비용	호출량 증가 시 비용 급증	자체 서버 기준, 시간당 수 USD 수준으로 예측 가능·통제 가능

이 중 가장 중요한 의사결정 기준은 “재현성”과 “버전 통제 가능성”이었습니다.

리뷰테마 추천 시스템은 항상 일정한 품질의 표현을 안정적으로 제공해야 하기 때문에, 언제든 다시 학습/재현할 수 있고 모델, 데이터, 코드를 함께 버전 관리할 수 있는 구조가 필요했습니다.

프롬프트 엔지니어링의 한계: 복잡도와 재현성 문제

상용 LLM을 사용할 때는, 원하는 품질을 얻기 위해 프롬프트에 조건·예시·제약을 계속 추가하게 됩니다. 이 과정이 반복되면, 결국 다음과 같은 문제가 생깁니다.

프롬프트가 지나치게 길어져 토큰 비용과 응답 지연이 커짐
여러 단계의 호출을 조합하면서 사실상 if 문이 많은 프로그램을 짜는 것과 비슷한 복잡도로 변함
프롬프트가 길고 복잡할수록 작은 변경에도 동작이 예측하기 어려워짐

아무리 정교하게 프롬프트를 다듬어도 Task의 복잡도가 임계치를 넘으면 LLM이 모든 지시사항을 완벽히 이행하지 못합니다. 일관된 품질 유지에 명확한 한계가 존재하는 것입니다.

반면 sLLM을 직접 SFT하는 방식은 우리가 원하는 출력 형식과 품질 기준을 데이터에 직접 내재화할 수 있습니다. 덕분에 프롬프트 구성을 단순하게 유지하면서도 결과의 재현성과 버전 통제권을 완벽히 확보하게 됩니다. 결과적으로 리뷰 테마 생성과 같은 도메인 특화 Task에서 sLLM이 상용 모델보다 더 적합한 선택지라고 판단했습니다.

최적의 파운데이션 모델 찾기: Gemma 3와 후보군 비교

프로젝트 초기에는 Gemma2-2B을 기반으로 시작했습니다. 이후 개발 기간 중 Gemma3가 출시되면서 성능과 다국어 지원 면에서 더 적합하다고 판단해 Gemma3-4B로 변경했습니다.

후보 모델군 검토 및 한국어 벤치마크 비교

아래 한국어 벤치마크 성능 비교표와 같이 네이버의 HyperCLOVA X SEED, Qwen 시리즈 등 한국어 성능이 준수한 여러 오픈소스 모델을 함께 검토했습니다. 하지만 서비스 적합성을 고려하여 최종 후보군에서는 제외했는데요, 사유는 다음과 같습니다.

HyperCLOVA X SEED 3B

한국어 성능은 가장 우수했으나, MAU 기반 라이선스 제약으로 인해 서비스 적용이 어렵다고 판단.
Qwen 2.5/3 시리즈

벤치마크 성능은 우수했으나, 실제 테스트 시 한국어 오타 정정(Typo Robustness) 성능이 상대적으로 낮아 리뷰 기반 생성 Task에는 부적합하다고 판단.

표 2. 후보 모델별 한국어 벤치마크 성능 비교 (Zero-shot 기준)

모델	파라미터	KMMLU¹	HAE-RAE²	CLiCK³	KoBEST⁴
HyperCLOVAX-SEED-Vision-Instruct-3B	3B	0.4422	0.6499	0.5599	0.7180
Qwen2.5-3B-Instruct	3B	0.4451	0.6031	0.5649	0.7053
gemma-3-4b-it (최종 선택)	4B	0.3895	0.6059	0.5303	0.7262

¹ KMMLU: 한국어 일반 상식 지식, ² HAE-RAE: 한국 문화·역사 지식, ³ CLiCK: 언어 이해 및 문화 상식, ⁴ KoBEST: 추론 및 이해 성능

실무 적용을 위한 두 가지 핵심 허들

컴퓨팅 효율성

개발 및 운영 환경이 Tesla T4 16GB 기준이기 때문에, 이 조건에서 안정적으로 동작할 만큼 메모리 사용이 가벼우면서도 충분한 성능을 제공하는 모델이어야 했습니다. Gemma는 효율적인 추론을 위해 설계된 아키텍처적 강점을 가지고 있습니다. Sliding Window Attention과 Local-Global Attention 혼합 구조를 통해 메모리 사용량을 최소화하면서도 긴 컨텍스트를 효과적으로 처리할 수 있으며, Multi-Query Attention(MQA)과 Grouped-Query Attention(GQA) 기법을 적용해 추론 속도를 향상시켰습니다. 이러한 최적화 덕분에 T4와 같은 제한된 GPU 환경에서도 안정적으로 동작하면서 실시간 서비스에 필요한 응답 속도를 확보할 수 있었습니다.
한국어 처리 능력

실제 사용자 리뷰는 오타, 비문, 구어체가 많기 때문에 한국어 인식 및 오타 복원 능력을 필수 조건으로 설정했습니다. Gemma 3는 140개 이상의 언어를 지원하는 멀티링구얼 모델로 설계되었으며, Gemini 2.0 계열의 SentencePiece 토크나이저(262k vocab)를 사용해 한국어를 포함한 CJK(중국어·일본어·한국어) 언어의 인코딩 효율이 크게 개선되었습니다. 동일한 한국어 텍스트를 처리할 때 이전 세대 대비 토큰 수가 줄어들어 메모리 사용량과 추론 속도가 향상되었으며, 리뷰 데이터처럼 구어체와 오타가 혼재된 텍스트에서도 안정적인 토큰화 성능을 보여주어 실무 적용에 적합했습니다.

왜 Gemma 3-4B 인가

Gemma는 경량화된 실용적인 크기에서 효과적인 성능을 제공하도록 설계된 Google의 오픈소스 LLM입니다.

그림 4. Google의 오픈소스 LLM Gemma

Gemma2: 2B, 9B, 27B 세 가지 모델로 제공되며, 가장 작은 2B 모델조차 GPT-3.5를 능가하는 성능을 보여주었습니다. (출처: Chatbot Arena)
Gemma3: 멀티모달 입력과 더 확장된 다국어 지원을 제공하며, 특히 4B 모델이 Chatbot Arena에서 GPT-4와 유사한 수준의 성능을 기록하여 소형 모델 중 매우 우수한 결과를 보였습니다. (참고: Gemma 3 Model Card)

학습 방법

학습 목표

리뷰 테마 추천 모델의 핵심 목적은 사용자 리뷰에서 상품 추천 카드에 사용할 '테마 표현'을 안정적으로 추출하는 것입니다. 구체적으로는 입력된 리뷰에서 entity, expression, name을 식별하여 구조화된 JSON 리스트 형태로 출력하도록 학습합니다.

그림 5. 표현 생성 모델의 input과 output

학습 데이터 생성

리뷰 기반 추천 표현을 학습시키기 위해서는 대규모의 입력–출력 쌍이 필요합니다. 그러나 이를 사람이 모두 직접 제작하는 것은 현실적으로 시간과 비용 측면에서 매우 비효율적입니다.

따라서 기본적인 지침과 출력 형식을 정의한 뒤, 오픈소스 LLM으로 생성하고 사람의 검토 및 수정을 거쳐 SFT용 데이터셋을 구축했습니다. 이 방식은 품질을 일정 수준으로 통제하면서도, 필요한 데이터 규모를 빠르게 확보할 수 있다는 장점이 있습니다.

Supervised Fine-Tuning 전략 (Post-Training)

오픈소스 LLM을 특정 도메인(Task)으로 적응시키는 가장 일반적인 방법은 Post-training 단계의 첫 과정인 Supervised Fine-tuning(SFT) 입니다. 대부분의 오픈소스 모델은 다음과 같은 형태로 공개됩니다.

~pt : Pre-training만 완료된 Base 모델
~it : Instruction finetuning까지 완료된 Chat 모델 (SFT 1차 완료 상태)

이번 프로젝트에서는 Gemma 3-4B-IT 모델을 기반으로, 그 위에 올리브영 리뷰 데이터에 특화된 도메인 적응(Domain Adaptation) SFT를 수행했습니다. (아래 표의 D단계)
즉, 기존 Chat 모델 위에 리뷰테마에 적합한 추가 지식·스타일·출력 규칙을 학습시키는 단계입니다.

표 3. LLM 학습 파이프라인 단계별 설명

1) Pre-training (사전 학습)	• 데이터: 대규모 웹, 문서, 코드, 멀티모달 데이터 • 결과물: Base Model (기반 모델)
2) Post-training (후학습)	(A) SFT: Supervised Fine-tuning (Instruction/Chat) (B) Preference Optimization: RLHF, DPO, ORPO (C) Safety Tuning: 안전 가이드라인 및 거부 응답 강화 (D) Domain Adaptation (우리가 수행한 과정) └ 도메인 특화 데이터 기반 SFT 수행
3) Deployment (서빙 및 배포)	• Quantization: 양자화를 통한 경량화 • Distillation: 지식 증류를 통한 모델 압축

우리가 베이스 모델(Base Model)로 선택한 Gemma 3-4B-IT는 이미지와 텍스트를 동시에 처리하는 멀티모달 모델입니다. 따라서 내부적으로 이미지 인코더인 비전 타워(Vision Tower)와 전용 프로세서를 포함하고 있습니다. 하지만 이번 프로젝트는 오직 텍스트 데이터만을 활용하므로 제한된 인프라 자원을 효율적으로 쓰기 위해 모델과 전처리 체인을 텍스트 전용으로 경량화하는 과정이 반드시 필요했습니다.

허깅페이스(Hugging Face)의 가이드에 따르면 멀티모달 기능을 모두 활용할 때는 Gemma3ForConditionalGeneration 클래스를 사용해야 합니다. 하지만 우리는 비전 타워 로딩을 과감히 생략하고 일반적인 LLM처럼 활용하기 위해 Gemma3ForCausalLM 클래스로 모델을 호출했습니다. 이러한 Text-only 최적화 로드 방식을 통해 불필요한 파라미터를 제거하고 오직 텍스트 학습에만 집중할 수 있는 환경을 구축했습니다.

참고
Hugging Face 공식 블로그: Transformers를 활용한 Gemma 3의 세부 추론 가이드
https://huggingface.co/blog/gemma3#detailed-inference-with-transformers

학습 시에는 어차피 LoRA를 사용해 전체 파라미터가 아니라 일부만 업데이트하기 때문에, 학습 속도나 GPU 메모리 사용량이 극적으로 줄어들지는 않습니다. 다만 운영 관점에서는 비전 관련 가중치를 제외함으로써 모델 파일 크기와 로드 시 메모리 사용량이 약 15% 정도 감소하는 효과가 있었습니다.

16GB VRAM 환경을 위한 학습 최적화

16GB GPU(Nvidia Tesla T4) 작은 VRAM 환경에서는 파라미터 규모가 4B 수준인 sLLM이라도 학습 시에 VRAM이 부족하기에 메모리 최적화가 필수적입니다. 그래서 다음과 같은 방법들을 적용했습니다.

모델 연산 효율화를 위한 Precision 설정

보통 VRAM이 작은 환경에서 LLM은 FP16(BF16) 기반의 half-precision 연산을 사용하도록 가이딩되어 있으며, 이는 연산 속도와 VRAM 사용량을 균형 있게 줄여주는 가장 기본적인 설정입니다.

배치 처리 최적화로 메모리 사용량 제어

두 가지의 최적화 방법을 통해서 작은 GPU 메모리에서도 안정적으로 학습이 가능하도록 최적화했습니다.

Gradient Checkpointing

중간 활성화를 모두 저장하지 않고 일부 지점만 저장한 뒤 역전파 때 다시 계산해서, 연산량을 늘리는 대신 학습 시 필요한 GPU 메모리를 대략 절반 수준까지 줄이는 방법
Gradient Accumulation

GPU 메모리가 작아 한 번에 큰 배치를 올리기 어려울 때, 여러 번의 작은 배치(micro batch)에서 그래디언트를 누적했다가 한 번에 업데이트하여 메모리는 작은 배치 수준으로 유지하면서도 큰 batch size로 학습한 것과 비슷한 효과를 내는 방법

LoRA 및 파라미터 Quantization 학습

가장 중요한 부분으로 SFT를 진행할 때는 전체 파라미터를 직접 학습하지 않고, 특정 모듈에 저차원 어댑터(LoRA) 를 추가한 뒤 이 파라미터만 업데이트하는 방식을 사용했습니다. 이 방식은 전체 모델을 미세 조정하는 것보다 학습 시간과 GPU 메모리 사용량을 크게 줄일 수 있다는 장점이 있습니다.

이번 프로젝트에서는 여기에 더해, 기저 모델 가중치를 4bit로 양자화한 상태에서 LoRA 어댑터를 학습하는 QLoRA 방식을 적용해 학습 시 필요한 VRAM을 추가로 절감했습니다. (연산은 FP16/BF16으로 수행하고, Base 모델 가중치 저장에만 4bit quantization을 적용)

LoRA 기반으로 학습하면 추론 단계에서도 이점이 있습니다. 기존 base model에 학습된 LoRA 모듈만 어댑터처럼 결합해 사용할 수 있기 때문에, 여러 도메인·목적에 맞춰 학습된 LoRA를 빠르게 교체할 수 있고, 전체 모델을 여러 개 따로 관리하는 것보다 저장 공간과 로딩 시간 모두를 크게 줄일 수 있습니다.

LoRA & Quantization
거대한 모델 전체를 수정하려면 엄청난 메모리가 필요합니다. Quantization(양자화)으로 모델의 무게를 가볍게 줄이고, LoRA를 통해 모델의 핵심 지식은 건드리지 않은 채 '얇은 노트' 한 권 분량의 지식만 추가로 학습시키는 효율적인 방법입니다.

그림 6. QLoRA SFT개념과 adapter 방식의 이점 설명

프롬프트 단축

SFT 과정에서 프롬프트를 단축하는 이유는 추론 시 토큰 비용을 줄이고 응답 속도를 개선하기 위해서입니다.

프롬프트 단축의 비용 절감 효과

프롬프트를 단축 전 528자에서 98자로 단축(약 81% 감소)하면, 대규모 배치 추론 시 상당한 인프라 비용을 절감할 수 있습니다. 이를 구체적인 수치로 환산해보면 다음과 같습니다. 프롬프트 단축은 자체 GPU 서버(AWS g4dn.xlarge 등)에서 sLLM을 운영할 때 처리량(throughput) 향상에 직접적인 영향을 미칩니다.

표 4. 자체 GPU 서버 운영 시 프롬프트 단축 효과 (g4dn.xlarge 기준)

구분	원본 프롬프트 (528자, ~350 토큰)	짧은 프롬프트 (98자, ~65 토큰)
배치당 처리 시간^*	약 3.2초	약 0.6초 (약 81% 단축)
시간당 처리 가능량	약 18,000 건	약 96,000 건 (약 5.3배 향상)
100만 건 처리 소요 시간	약 55.6 시간	약 10.4 시간 (약 81% 단축)
100만 건 추론 인프라 비용^**	약 $38.9	약 $7.3 (약 81% 절감)

^* batch_size=16 기준, 실제 측정값 (짧은 프롬프트 기준 0.6초/배치)
^** AWS g4dn.xlarge 온디맨드 가격 $0.70/hour 기준

LLM으로 학습 데이터를 생성할 때는 제약조건·지시사항을 모두 포함한 긴 프롬프트가 필요하지만, 자체 학습한 sLLM에서는 지시문 자체를 모델이 내재적으로 학습할 수 있으므로 훨씬 짧은 형태의 프롬프트로도 동일한 품질을 유지할 수 있습니다.

프롬프트 길이가 모델 성능에 어떤 영향을 주는지 검증하기 위해, 다양한 형식을 구성하여 1 epoch씩 학습한 후 비교한 결과 다음과 같은 인사이트를 얻었습니다.

실험 인사이트

설명(Rich Desc)을 함께 제공하는 형식이 가장 안정적으로 동작
예시(Example based)만 제공하면 품질이 떨어짐
설명 없이 한 블록으로 줄인 extreme 단축 버전(TaskTagOnly)은 성능이 가장 낮았음
설명과 input 사이의 구조적 구분(ShortDesc, NoInputHeader)을 제거하면 품질이 저하됨

즉, 지나치게 축약하는 것보다 짧더라도 구조, 규칙, 역할을 명확히 보여주는 형태가 가장 효율적이라는 결론을 얻었습니다.

그림 7. 각 프롬프트 구성 조합별 1epoch eval loss 비교

프롬프트 단축 실험 예시

준비된 학습 데이터를 기반으로 SFT를 진행하면서, 다양한 단축 형식을 실험했습니다. 아래는 실제 테스트한 프롬프트 형식 예시입니다.

예시 1: 최소 축약형

#OY-TASK: 올리브영 리뷰 테마 추천용 표현을 추출
상품: {goods_nm}
리뷰: {review}

예시 2: 구조적 명시형

<올리브영 리뷰 테마 추천용 표현을 추출>
수식하는 표현은 2 단어보단 많아야해
적절한 표현이 없다면 공백 목록만 반환 [""]

<input review>
상품: {goods_nm}
리뷰: {review}

예시 3: 예시 기반 형식

# 올리브영 리뷰 표현 추출
example : ["사용감 : 순하고 자극 없는 '미스트'"]
input : {goods_nm}
"{review}"

최종 프롬프트 형식

실험 결과, 다음 구성의 템플릿이 성능 유지 + 토큰 단축 관점에서 가장 우수했습니다.

#OY-TASK: 올리브영 리뷰 테마 추천용 표현을 추출
#FORMAT: 긍정적 표현만, 카테고리+표현, JSON 리스트
상품: {goods_nm}
리뷰: {review}

이 템플릿은 아래와 같은 구성을 통해 최소한의 토큰으로도 안정적인 결과를 제공합니다.

짧고 명확한 task 명명(#OY-TASK)
출력 형태를 강제하는 FORMAT 규칙
불필요한 설명 없이 input만 제시

성능 비교

표현 추출 모델 기준으로 정규식의 형식/어미 alignment 검증과 LLM as a judge 방법론으로 LLM을 통해서 문맥을 검증했습니다. 평가/벤치마크를 위한 비교 대상은 모델 개발 시점 Gemini flash 버전인 2.0 기준으로 압축하지 않은 프롬프트로 질의하여 비교했습니다.

표 5. Gemini 2.0 flash와 Gemma3-4b-it 모델 성능 비교

구분	Gemini 2.0 flash (비교 대상)	Gemma3-4b-it (SFT 후)
프롬프트 길이	528 자	98 자
정확도 상대 평가	1.0 (기준)	0.95
속도	0.8초 / 16개 동시 요청 (GCP API)	0.6 초 / 배치 (GPU 16GB, batch_size=16)

평가 설정
위의 정확도 평가는 리뷰 샘플에 대해 내부에서 정의한 기준으로 레이블과 모델 출력을 비교해 산출한 상대 지표입니다.
Gemini 2.0 flash 기반 결과를 기준값 1.0으로 두고, 같은 검증 셋에서 Gemma3-4B의 SFT 모델의 상대적인 정확도를 측정한 값이 0.95입니다.
Gemini는 생성 결과 비교 및 벤치마크(LLM as a judge) 용도로만 사용했고 SFT 학습/레이블 생성에는 사용하지 않았습니다.

실제로 두 모델의 출력을 비교해보면, 유사한 품질의 결과를 생성합니다. 아래는 실제 리뷰에 대한 두 모델의 출력 예시입니다:

예시 1

리뷰: 블랙프라이데이 때 특가로 득템했는데 무난하게 수분 채워주기 좋아요! 안개분사~

Gemini: ["무난하게 수분 채워주는 '미스트' : 효과"]
Ours: ["수분 채워주기 좋은 '미스트' : 보습력"]

예시 2

리뷰: 이젠 집에 없으면 안될 제품이에여 몇통째 먹고있는제품인데
      젤 괜찮은제품같아요 속쓰림 속부대낌 그런거 없어요 굿굿

Gemini: ["속쓰림 속부대낌 없는 '기능식품' : 효과"]
Ours: ["속쓰림 없이 편안한 '영양제' : 효과"]

Key Takeaways

결론적으로 도메인 특화 SFT를 통해 상용 LLM 대비 약간의 정확도 손실(5%p 이내)이 있었지만, 서비스에 필요한 수준의 품질을 충분히 확보할 수 있었습니다.

표 6. sLLM 도입의 주요 성과 요약

비용 효율	외부 API 호출 대비 비용 예측 가능성 확보
속도	배치 처리 최적화로 0.6초 대 응답 속도 달성
품질	상용 모델 대비 95% 수준의 정확도 유지하며 도메인 특화 완료

속도 및 운영 관점 해석

속도는 각 환경에서 측정한 평균 응답 시간입니다.

Gemini 2.0 flash는 GCP API 기준 16개 동시요청 시 약 0.8초이며, Gemma3-4B SFT 모델은 Tesla T4 16GB 환경에서 batch size 16 기준 한 배치를 처리하는 데 약 0.6초가 소요되었습니다. GCP Gemini API의 동시 호출의 한계가 있으나, 자체 LLM은 Scale-Out으로 Throughput을 충분히 늘려 원하는 만큼의 처리가 가능하다는 장점이 있습니다.

자체 sLLM은 배치 처리 전제가 있기 때문에 실제 단일 요청 단위 처리 시간과 전체 처리량(throughput) 관점에서는 상용 LLM 대비 더 유리하게 동작할 수 있으며, 호출량이 증가해도 GPU 인스턴스 단가 범위 내에서 비용 상한을 예측 가능하게 유지할 수 있다는 장점이 있습니다

자체 sLLM을 SFT하며 얻은 것

학습 목표, 품질 기준을 먼저 고정하기

LLM에게 “좋은 품질의, 내가 원하는 느낌의 결과”를 막연히 기대하는 것은 올바른 접근 방식이 아닙니다.

모델이 제대로 학습하려면 어떤 출력이 좋은 결과인지를 구체적인 기준으로 정의해야 합니다. 이를 검증 가능하게 형식화하는 것이 필수적입니다. 그래야만 해당 Task를 안정적으로 학습시킬 수 있습니다.

실제 리뷰 테마 프로젝트 과정에서는 초기 기획 단계의 콘셉트와 서비스 UI가 변경되면서 학습 목표가 여러 차례 수정되었습니다. 그 결과 이미 학습을 마친 모델의 출력을 서비스 직전에 다시 필터링해야 하는 비효율이 발생하기도 했습니다.

이 경험을 통해, 학습 전에 목표와 품질 기준을 충분히 합의·고정해 두는 것이 sLLM 프로젝트의 성패를 좌우하는 핵심 요소라는 점을 다시 한 번 확인했습니다.

Human-in-the-loop 검수의 필요성

리뷰테마 추천은 사용자 화면에 직접 노출되는 콘텐츠이기 때문에 자동 검증 모델만으로는 충분하지 않습니다. 1차적으로는 검증 모델을 통해 필터링을 수행하지만, 최종적으로는 사람이 직접 확인하는 단계가 반드시 필요합니다.

이를 위해서는 정량적·정성적으로 명확한 검증 기준이 정의되어 있어야 하며, 사람이 그 기준에 따라 일관되게 검수할 수 있어야 합니다.

올리브영의 첫 번째 자체 sLLM의 의미

이번 프로젝트는 NVIDIA Tesla T4 16GB라는 매우 한정된 자원 환경에서 sLLM을 학습하고 서비스에 성공적으로 적용할 수 있음을 검증한 올리브영의 첫 사례라는 점에서 큰 의미가 있습니다.

비록 완벽한 결과는 아닐지라도 범용 LLM에 의존하지 않고 비용 효율적이면서도 빠른 개선이 가능한, 우리만의 도메인 특화 sLLM을 구축할 수 있다는 가능성을 명확히 확인했습니다. 이는 향후 올리브영이 도메인 특화 AI를 전방위로 확장해 나가는 데 있어 견고한 기술적 기반이 될 것입니다.

앞으로의 방향성

리뷰 테마 추천은 올리브영 내부에서 sLLM 역량을 쌓는 파일럿 프로젝트이자, 전자신문 등 외부 매체에 '고객 리뷰 기반 생성형 추천' 사례로 소개된 의미 있는 레퍼런스입니다. 우리는 이 첫 번째 버전을 출발점 삼아 기술적 고도화를 진행 중입니다.

참고
CJ올리브영, 자체 'sLLM' 개발... AI가 'K뷰티' 골라준다 (전자신문, 2025년 9월 16일)

표현 품질 개선을 위한 개선 작업

리뷰 텍스트를 기반으로 생성된 추천 표현 중에는 문맥이나 문법적으로 UI에 노출하기 적합하지 않은 문장도 일부 포함됩니다. 이를 개선하기 위해, 생성된 표현을 임베딩 공간에서 클러스터링하고 군집 중심에서 벗어난 outlier 표현을 자동으로 제거하는 방식을 적용하고 있습니다.

이를 통해 더 자연스럽고 안정적인 품질의 표현만 최종 추천에 반영되도록 개선하고 있습니다.

카드 이미지 자동 생성 개발

현재는 UI/UX 팀이 제작·리터칭한 소수의 이미지를 사용하고 있어, 추천 내용이 달라도 유사한 카드가 반복 노출되는 한계가 있습니다. 이에 따라 이미지 생성 파이프라인을 자동화하여, 아래와 같은 목표로 개발을 진행 중입니다. 자동화로 더 많은 이미지를 생성해서 추천 카드를 더 신선하고 자연스럽게 확장 가능한 형태로 전환하려고 합니다.

다양한 스타일과 구성의 이미지 생성
리뷰·추천 내용과 연동된 맞춤형 시각 요소 생성
운영 비용 절감 및 이미지 다양성 확보

더 크고 복잡한 Task를 위한 LLM 개발

시작은 4B 규모의 작은 모델과 간단한 생성 과업이었지만, 이번 경험은 우리에게 큰 자신감을 주었습니다. 앞으로는 더 크고 복잡한 태스크를 수행할 수 있는 대형 모델 학습에 도전하며, 올리브영의 다양한 도메인 문제를 AI로 해결해 나가는 여정을 멈추지 않을 것입니다.

올리브영 타입스크립트로 알아보는 제네릭과 매개변수 다형성

Wed, 31 Dec 2025 17:00:00 GMT

지난 아티클 타입스크립트로 알아보는 타입과 타입 시스템에서 우리는 타입 시스템의 기초를 탄탄히 다졌습니다. 타입 검사기가 어떻게 프로그램의 모순을 찾아내는지, 그리고 서브타입에 의한 다형성이 딱딱한 타입에 유연성을 어떻게 부여하는지 살펴보았죠.

서브타입에 의한 다형성 덕분에 TodayProduct 타입의 값을 Product 타입이 필요한 곳에 전달할 수 있게 되었습니다. "(올리브영의 당일 배송 서비스인) 오늘드림 상품도 상품이다"라는 직관적인 관계가 타입 시스템에서도 인정받게 된 것이죠.

그런데 한 가지 의문이 듭니다.

서브타입 관계가 없는, 완전히 독립적인 타입들에 동일한 로직을 적용하려면 어떻게 해야 할까요?

이번 글에서도 올리브영의 실무 코드를 바탕으로, 타입의 한계를 뛰어넘어 유연성을 극대화하는 방법을 함께 파헤쳐 보겠습니다.

같은 로직, 다른 타입

올리브영 서비스에는 수많은 데이터 모델이 존재합니다. 상품, 리뷰, 주문 내역은 각각 그 목적에 맞게 서로 다른 속성들을 가지고 있죠.

interface Product {
  id: string;
  name: string;
  price: number; // 상품은 가격이 중요합니다.
}

interface Review {
  id: string;
  content: string;
  rating: number; // 리뷰는 별점이 핵심이죠.
}

interface Order {
  id: string;
  orderDate: Date; // 주문은 언제 했는지가 중요합니다.
}

이렇게 데이터의 모양이 제각각인 상황에서, 목록의 첫 번째 요소를 가져오는 함수가 필요하다고 가정해봅시다.

function getFirstProduct(items: Product[]): Product | undefined {
  return items[0];
}

잘 작동합니다. 그런데 이번엔 리뷰 목록의 첫 번째 요소도 가져오고 싶습니다.

function getFirstReview(items: Review[]): Review | undefined {
  return items[0];
}

주문 내역의 첫 번째 요소도요.

function getFirstOrder(items: Order[]): Order | undefined {
  return items[0];
}

세 함수의 본문을 보세요. return items[0];로 모두 동일합니다. 로직은 하나인데, 타입이 다르다는 이유만으로 함수를 세 개나 만들어야 합니다.

Product와 Review와 Order 사이에는 서브타입 관계가 없습니다. "상품은 리뷰이다"라거나 "주문은 상품이다"라는 명제는 성립하지 않으니까요. 서브타입에 의한 다형성으로는 이 문제를 해결할 수 없습니다.

우리에겐 새로운 도구가 필요합니다. 타입 자체를 추상화하는 도구, 바로 제네릭입니다.

제네릭이란?

제네릭(Generics)은 타입 변수(Type Variable)를 사용하여 타입을 추상화하는 방법입니다.

함수가 값을 매개변수로 받아 다양한 값에 대해 같은 로직을 수행하듯이, 제네릭은 타입을 매개변수로 받아 다양한 타입에 대해 같은 로직을 수행합니다.

앞서 만든 세 개의 함수를 제네릭으로 합쳐봅시다.

function getFirst<T>(items: T[]): T | undefined {
  return items[0];
}

<T>가 바로 타입 변수입니다. 이 함수는 "어떤 타입 T의 배열을 받아서, 그 T 타입의 값을 반환한다"고 선언합니다.

이제 하나의 함수로 모든 경우를 처리할 수 있습니다.

const firstProduct = getFirst<Product>(products);  // Product | undefined
const firstReview = getFirst<Review>(reviews);      // Review | undefined
const firstOrder = getFirst<Order>(orders);         // Order | undefined

함수를 호출할 때 <Product>, <Review>, <Order>처럼 타입 인자를 전달합니다. 마치 함수에 값을 전달하듯이요.

여기서 중요한 점이 있습니다. 제네릭 없이 any를 사용해도 비슷해 보이지만, 결정적인 차이가 있습니다.

// any 사용 - 타입 정보 손실
function getFirstAny(items: any[]): any {
  return items[0];
}
const first = getFirstAny(products); // any - 타입 정보가 사라짐

// 제네릭 사용 - 타입 정보 보존
function getFirst<T>(items: T[]): T | undefined {
  return items[0];
}
const first = getFirst(products); // Product | undefined - 타입 정보 유지

any를 사용하면 함수를 통과하는 순간 타입 정보가 증발해 버립니다. 반환값이 any이니 이후 어떤 속성에 접근해도 타입 검사기는 아무런 도움을 주지 못합니다.

반면 제네릭을 사용하면 타입 정보가 함수를 관통하여 보존됩니다. Product[]를 넣으면 Product가 나오고, Review[]를 넣으면 Review가 나옵니다. 타입 검사기의 보호를 계속 받을 수 있습니다.

[그림 1: 일반 함수 vs 제네릭 함수 - 타입 정보의 흐름]

타입 인자 추론

사실 대부분의 경우, 타입 인자를 명시적으로 적을 필요가 없습니다.

const firstProduct = getFirst(products); // T가 Product로 자동 추론됨

타입스크립트 컴파일러는 products의 타입이 Product[]임을 알고 있습니다. 이 정보를 바탕으로 T가 Product임을 스스로 추론합니다. 이를 타입 인자 추론(Type Argument Inference)이라고 합니다.

타입 인자 추론 덕분에 제네릭 코드도 일반 코드처럼 간결하게 작성할 수 있습니다. 컴파일러가 추론에 실패하는 복잡한 경우에만 명시적으로 타입 인자를 적어주면 됩니다. (더 자세한 내용은 타입스크립트 공식 핸드북을 참고하세요.)

제네릭의 필요성 - 올리브영 API 응답

제네릭의 진가는 실무에서 더욱 빛납니다. 올리브영의 API 응답 구조를 생각해봅시다.

상품 목록 API, 사용자 정보 API, 주문 내역 API 모두 비슷한 응답 구조를 가집니다. 실제 데이터(data)와 함께 상태 코드(status), 메시지(message)를 반환하죠.

// 제네릭 없이 - 타입마다 별도 정의
interface ProductResponse {
  data: Product;
  status: number;
  message: string;
}

interface UserResponse {
  data: User;
  status: number;
  message: string;
}

interface OrderResponse {
  data: Order;
  status: number;
  message: string;
}

interface ReviewListResponse {
  data: Review[];
  status: number;
  message: string;
}

// ... API가 늘어날 때마다 새로운 타입 정의

status와 message 부분이 계속 반복됩니다. API가 수십 개라면 수십 번 같은 코드를 작성해야 합니다.

제네릭으로 이 반복을 제거해봅시다.

// 제네릭으로 - 하나의 타입으로 모든 응답 처리
interface ApiResponse<T> {
  data: T;
  status: number;
  message: string;
}

// 사용
type ProductResponse = ApiResponse<Product>;
type UserResponse = ApiResponse<User>;
type OrderResponse = ApiResponse<Order>;
type ReviewListResponse = ApiResponse<Review[]>;

ApiResponse<T>라는 하나의 제네릭 인터페이스가 모든 API 응답 타입을 생성합니다. T 자리에 실제 데이터 타입을 넣으면 완전한 응답 타입이 만들어집니다.

이제 API 응답 구조가 변경되어도 ApiResponse<T> 한 곳만 수정하면 됩니다. 모든 응답 타입에 일괄 적용되니까요.

[그림 2: 제네릭으로 코드 중복 제거]

제네릭 함수와 타입 추론

제네릭 함수를 좀 더 살펴봅시다. 다양한 목록을 필터링하는 상황을 생각해보세요.

// 설명을 위해 단순화한 예시입니다.
function filterItems<T>(items: T[], predicate: (item: T) => boolean): T[] {
  return items.filter(predicate);
}

이 함수는 "어떤 타입 T의 배열과, T를 받아 불리언을 반환하는 함수를 받아서, T의 배열을 반환한다"고 선언합니다.

올리브영에서 사용해볼까요?

// Product에는 price, Review에는 rating, Order에는 date 속성이 있다고 가정

// 5만원 이상 상품 필터링
const expensiveProducts = filterItems(products, (p) => p.price > 50000);

// 4점 이상 리뷰 필터링
const goodReviews = filterItems(reviews, (r) => r.rating >= 4);

// 이번 달 주문 필터링
const thisMonthOrders = filterItems(orders, (o) => o.date.getMonth() === new Date().getMonth());

세 번의 호출 모두 타입 인자를 명시하지 않았습니다. 그런데 콜백 함수 안에서 p.price, r.rating, o.date에 접근할 때 자동완성이 작동합니다. 타입 검사도 정상적으로 이루어집니다.

어떻게 가능할까요? 타입스크립트가 products의 타입에서 T를 Product로 추론했기 때문입니다. 그 추론이 콜백 함수의 매개변수 p에까지 전파되어, p가 Product 타입임을 알게 됩니다.

이것이 제네릭과 타입 추론의 시너지입니다. 타입을 명시하지 않아도 타입 안전성을 누릴 수 있습니다.

제네릭 제약

제네릭의 강력함에는 대가가 따릅니다. T가 무엇이든 될 수 있기 때문에, T에 특정 속성이 있다고 가정할 수 없습니다.

function getLength<T>(arg: T): number {
  return arg.length; // Error: Property 'length' does not exist on type 'T'
}

T가 number일 수도 있고, boolean일 수도 있습니다. 이들에게는 length 속성이 없죠. 타입 검사기는 가능한 모든 경우를 고려하므로, 이 코드를 허용하지 않습니다.

하지만 우리는 '길이' 속성이 있는 타입에 대해서만 이 함수를 사용하고 싶습니다. 이때 제네릭 제약(Generic Constraints)을 사용합니다.

interface HasLength {
  length: number;
}

function getLength<T extends HasLength>(arg: T): number {
  return arg.length; // OK!
}

T extends HasLength는 "T는 HasLength의 서브타입이어야 한다"는 제약입니다. 이제 T는 최소한 length 속성을 가진 타입만 될 수 있습니다.

getLength("hello");      // OK - string은 length가 있음
getLength([1, 2, 3]);    // OK - 배열도 length가 있음
getLength({ length: 10 }); // OK - length 속성이 있는 객체

getLength(123);          // Error - number는 length가 없음
getLength(true);         // Error - boolean도 length가 없음

여기서 서브타입에 의한 다형성과 매개변수에 의한 다형성이 만납니다. extends 키워드가 그 접점입니다.

올리브영 예제로 적용해봅시다. 가격이 있는 모든 것에 할인을 적용하는 함수를 만들어보겠습니다.

// 설명을 위해 단순화한 예시입니다.
interface HasPrice {
  price: number;
}

function applyDiscount<T extends HasPrice>(item: T, rate: number): T {
  return {
    ...item,
    price: item.price * (1 - rate / 100)
  };
}

이 함수는 price 속성을 가진 어떤 타입이든 받을 수 있습니다.

const discountedProduct = applyDiscount(product, 10);     // Product
const discountedTodayProduct = applyDiscount(todayProduct, 15); // TodayProduct
const discountedGiftSet = applyDiscount(giftSet, 20);     // GiftSet

Product, TodayProduct, GiftSet 모두 price 속성을 가지고 있다면 이 함수를 사용할 수 있습니다. 그리고 반환 타입은 입력 타입과 동일하게 유지됩니다. TodayProduct를 넣으면 TodayProduct가 나옵니다.

[그림 3: 제네릭 제약으로 타입 범위 한정]

제네릭과 서브타입의 만남 - 변성 입문

지금까지 제네릭의 기초를 살펴보았습니다. 이제 조금 더 깊이 들어가봅시다.

지난 글에서 우리는 서브타입 관계를 배웠습니다. TodayProduct는 Product의 서브타입입니다. "오늘드림 상품은 상품이다"가 성립하니까요.

그렇다면 질문을 던져봅시다.

TodayProduct가 Product의 서브타입일 때, Array<TodayProduct>는 Array<Product>의 서브타입일까요?

직관적으로는 "그렇다"고 답하고 싶습니다. 오늘드림 상품의 배열은 상품의 배열이니까요.

하지만 이 질문의 답은 생각보다 복잡합니다. 그리고 이 복잡함을 설명하는 개념이 바로 변성(Variance)입니다.

변성의 세 가지 종류

타입 A가 타입 B의 서브타입일 때, 제네릭 타입 F<A>와 F<B>의 관계는 크게 세 가지로 나뉩니다. (타입스크립트에는 이변성이라는 네 번째 종류도 있는데, 뒤에서 다룹니다.)

1. 공변성 (Covariance)

A가 B의 서브타입이면, F<A>도 F<B>의 서브타입이다.

타입 인자의 서브타입 관계가 그대로 유지됩니다.

TodayProduct <: Product
     ↓ 관계 유지
Array<TodayProduct> <: Array<Product>

직관과 일치하죠. 오늘드림 상품이 상품의 서브타입이니, 오늘드림 상품 배열도 상품 배열의 서브타입입니다.

도 Array의 서브타입이 되는 관계" title="" loading="lazy" decoding="async" style="width:100%;height:100%;margin:0;vertical-align:middle;position:absolute;top:0;left:0;">

[그림 4: 공변성 - 서브타입 관계가 유지된다]

2. 반공변성 (Contravariance)

A가 B의 서브타입이면, F<B>가 F<A>의 서브타입이다.

타입 인자의 서브타입 관계가 뒤집힙니다.

TodayProduct <: Product
     ↓ 관계 역전
Consumer<Product> <: Consumer<TodayProduct>

// Consumer<T>는 T를 "소비"하는 타입, 즉 T를 매개변수로 받는 함수 타입입니다
// type Consumer<T> = (item: T) => void

이건 좀 낯섭니다. 하지만 지난 글에서 이미 이 개념을 만났습니다. 기억하시나요?

함수 타입은 매개변수 타입의 서브타입 관계를 뒤집는다.

바로 이것이 반공변성입니다. 상품을 처리하는 함수는 오늘드림 상품도 처리할 수 있기에, 상품 함수는 오늘드림 상품 함수의 서브타입이 됩니다.

가 Consumer의 서브타입이 되어 관계가 역전됨" title="" loading="lazy" decoding="async" style="width:100%;height:100%;margin:0;vertical-align:middle;position:absolute;top:0;left:0;">

[그림 5: 반공변성 - 서브타입 관계가 뒤집힌다]

3. 불변성 (Invariance)

A와 B가 다른 타입이면, F<A>와 F<B> 사이에 서브타입 관계가 없다.

정확히 같은 타입만 허용됩니다. 서브타입도 안 되고, 슈퍼타입도 안 됩니다. 오늘드림 상품과 상품은 엄연히 다른 타입이기에, 둘 사이에는 어떤 서브타입 관계도 인정하지 않습니다.

와 F 사이에 어떤 서브타입 관계도 성립하지 않음" title="" loading="lazy" decoding="async" style="width:100%;height:100%;margin:0;vertical-align:middle;position:absolute;top:0;left:0;">

[그림 6: 불변성 - 서브타입 관계가 없다]

왜 변성이 중요한가?

변성이 왜 필요한지, 배열을 예로 들어 살펴봅시다.

배열이 공변적이라고 가정해봅시다. 즉, Array<TodayProduct>가 Array<Product>의 서브타입입니다.

const todayProducts: TodayProduct[] = [ { title: "탈모 샴푸", price: 25000, isTodayDelivery: true }, { title: "마스크팩", price: 15000, isTodayDelivery: true } ]; // 공변성에 의해 이 할당이 허용된다고 가정 const products: Product[] = todayProducts;

여기까지는 문제없어 보입니다. 읽기만 한다면요.

// 읽기 - 안전함 console.log(products[0].title); // OK

하지만 쓰기를 하면 어떨까요?

// 쓰기 - 위험! products.push({ title: "일반 상품", price: 10000 }); // isTodayDelivery 속성이 없는 일반 Product // todayProducts 배열에 TodayProduct가 아닌 값이 들어감! todayProducts.forEach(p => { console.log(p.isTodayDelivery); // undefined - 런타임 에러 가능! });

products와 todayProducts는 같은 배열을 참조합니다. products를 통해 일반 Product를 추가하면, todayProducts에도 그 값이 들어갑니다. 하지만 todayProducts는 모든 요소가 TodayProduct라고 믿고 있죠. 타입 시스템이 깨지는 순간입니다.

이것이 변성이 중요한 이유입니다. 읽기만 하는 컨테이너는 공변적이어도 안전하지만, 쓰기도 하는 컨테이너는 공변적이면 위험합니다.

타입스크립트의 변성 처리

타입스크립트는 이 복잡한 변성을 어떻게 처리할까요? 타입 안전성과 실용성 사이에서 고민한 타입스크립트만의 현실적인 절충안을 여기서 엿볼 수 있습니다.

배열은 공변적으로 처리된다

앞서 살펴본 것처럼, 쓰기가 가능한 배열이 공변적인 것은 타입 안전하지 않습니다(unsound). todayProducts 배열을 products로 참조한 뒤 일반 Product를 추가하면, 타입 시스템이 보장하던 안전성이 깨지죠.

그럼에도 타입스크립트는 배열을 공변적으로 처리합니다.

function printProductTitles(products: Product[]) { products.forEach(p => console.log(p.title)); } const todayProducts: TodayProduct[] = [/* ... */]; printProductTitles(todayProducts); // OK - 허용됨

왜일까요? 실용성 때문입니다.

위 코드처럼 배열을 읽기 전용으로 사용하는 패턴은 자바스크립트에서 매우 흔합니다. 이 패턴을 에러로 처리하면 수많은 정상적인 코드가 컴파일되지 않습니다.

타입스크립트는 완벽한 타입 안전성보다 실용성을 선택했습니다. 대신 개발자가 위험한 쓰기를 하지 않을 것이라고 신뢰합니다.

함수 타입의 변성

배열에서는 실용성을 위해 공변성을 허용했습니다. 그렇다면 함수 타입은 어떨까요? 함수 타입은 좀 더 엄격합니다. strictFunctionTypes 옵션이 켜져 있다면 타입스크립트는 다음과 같이 동작합니다.

반환 타입: 공변적 (서브타입 관계 유지)

매개변수 타입: 반공변적 (서브타입 관계 역전)

매개변수 반공변성이 낯설게 느껴진다면, 지난 글의 예제를 떠올려보세요. "함수 타입은 매개변수 타입의 서브타입 관계를 뒤집는다"고 했었죠. 왜 그래야 하는지, 만약 공변적이라면 어떤 일이 벌어지는지 살펴봅시다.

type TodayProductHandler = (p: TodayProduct) => void; // TodayProduct의 isTodayDelivery 속성에 접근하는 함수 const processTodayProduct: TodayProductHandler = (p) => { console.log(`오늘 배송 여부: ${p.isTodayDelivery}`); }; // 만약 매개변수가 공변적이라면, 이 할당이 허용될 것입니다 // (TodayProduct <: Product 이므로 TodayProductHandler <: ProductHandler?) const processProduct: ProductHandler = processTodayProduct; // 실제로는 에러! // 일반 Product를 전달하면? processProduct({ title: "일반 상품", price: 10000 }); // isTodayDelivery 속성이 없음 - 런타임 에러!

processTodayProduct는 isTodayDelivery 속성이 있다고 가정하고 동작합니다. 그런데 일반 Product에는 이 속성이 없죠. 매개변수가 공변적이면 타입 시스템을 통과하지만 런타임에 실패합니다.

반대 방향은 안전합니다.

type ProductHandler = (p: Product) => void; type TodayProductHandler = (p: TodayProduct) => void; // Product의 공통 속성만 사용하는 함수 const handleProduct: ProductHandler = (p) => { console.log(`상품명: ${p.title}, 가격: ${p.price}`); }; // 반공변성: ProductHandler를 TodayProductHandler에 할당 가능 const handleTodayProduct: TodayProductHandler = handleProduct; // OK! // TodayProduct를 전달해도 안전 handleTodayProduct({ title: "샴푸", price: 10000, isTodayDelivery: true }); // title과 price는 확실히 존재함

handleProduct는 Product의 속성만 사용합니다. TodayProduct는 Product의 모든 속성을 가지고 있으므로, TodayProduct를 전달해도 문제없이 동작합니다. 이것이 매개변수 반공변성이 타입 안전한 이유입니다.

반환 타입은 직관대로 공변적입니다.

type GetProduct = () => Product; type GetTodayProduct = () => TodayProduct; const getTodayProduct: GetTodayProduct = () => ({ title: "샴푸", price: 10000, isTodayDelivery: true }); // 공변성: GetTodayProduct를 GetProduct에 할당 가능 const getProduct: GetProduct = getTodayProduct; // OK! const product = getProduct(); console.log(product.title); // TodayProduct도 title이 있으므로 안전

getTodayProduct가 반환하는 TodayProduct는 Product의 모든 속성을 포함합니다. Product를 기대하는 곳에서 사용해도 안전하죠.

메서드 vs 함수 프로퍼티

함수 타입에서 매개변수는 반공변적이라고 했습니다. 그런데 타입스크립트에서는 같은 함수라도 어떻게 정의하느냐에 따라 이 규칙이 다르게 적용됩니다.

interface Container { // 메서드 문법 - 이변성(bivariant) process(item: Product): void; // 함수 프로퍼티 문법 - strictFunctionTypes에서 반공변성 handle: (item: Product) => void; }

메서드는 이변성(bivariance)으로 처리됩니다. 양방향 할당이 모두 허용된다는 뜻입니다. 이것도 실용성을 위한 선택입니다. 기존 자바스크립트 코드와의 호환성, 그리고 일반적인 객체 지향 패턴을 지원하기 위해서입니다.

더 엄격한 타입 검사를 원한다면 메서드 대신 함수 프로퍼티 문법을 사용하세요.

실전 활용 - 유틸리티 타입 이해하기

제네릭의 강력함을 가장 잘 보여주는 것이 타입스크립트의 내장 유틸리티 타입들입니다. 이들이 어떻게 구현되어 있는지 살펴보면 제네릭에 대한 이해가 깊어집니다. (더 자세한 내용은 타입스크립트 공식 핸드북 - Utility Types를 참고하세요.)

Partial<T>

모든 속성을 선택적으로 만드는 유틸리티입니다.

// 구현 원리 - "객체의 모든 키를 순회하며 새 타입을 만든다" 정도로 이해하면 됩니다. type MyPartial<T> = { [K in keyof T]?: T[K]; }; // 사용 예시 - 올리브영 상품 수정 폼 // (설명을 위해 간략화된 Product 타입) interface Product { title: string; price: number; description: string; } // 수정 시에는 일부 필드만 보내도 됨 type ProductUpdateInput = Partial<Product>; // { title?: string; price?: number; description?: string; } function updateProduct(id: string, updates: Partial<Product>) { // 전달된 필드만 업데이트 } updateProduct("123", { price: 25000 }); // OK - price만 업데이트

Pick<T, K>와 Omit<T, K>

특정 속성만 선택하거나 제외합니다.

// 상품 목록에서는 일부 정보만 보여줌 type ProductListItem = Pick<Product, "title" | "price">; // { title: string; price: number; } // 상품 생성 시에는 id를 제외 type ProductCreateInput = Omit<Product, "id">;

올리브영 맞춤 유틸리티 타입

내장 유틸리티를 참고하여 올리브영에 필요한 유틸리티 타입도 만들 수 있습니다.

// 할인 적용 결과 타입 type Discounted<T extends HasPrice> = T & { originalPrice: number; discountRate: number; }; // 사용 const discountedProduct: Discounted<Product> = { ...product, originalPrice: product.price, discountRate: 15 }; // API 응답에서 데이터만 추출 type ExtractData<T> = T extends ApiResponse<infer U> ? U : never; type ProductData = ExtractData<ApiResponse<Product>>; // Product

위 ExtractData 타입에서 사용된 infer 키워드는 조건부 타입에서 타입을 추론하는 데 사용됩니다. 지금은 "이런 것도 가능하구나" 정도로 넘어가도 괜찮습니다. 조건부 타입과 infer는 다음 글에서 더 자세히 다루겠습니다.

마치며

이번 글에서 우리는 제네릭과 매개변수에 의한 다형성을 살펴보았습니다.

서브타입에 의한 다형성은 "A는 B이다"라는 관계로 타입 간 호환성을 만들었습니다. TodayProduct는 Product이므로 Product가 필요한 곳에 TodayProduct를 쓸 수 있었죠.

매개변수에 의한 다형성은 타입 자체를 추상화합니다. T라는 타입 변수를 사용하여, 어떤 타입이든 받을 수 있는 범용적인 코드를 작성합니다. 서브타입 관계 없이도 같은 로직을 여러 타입에 적용할 수 있게 되었습니다.

그리고 변성(Variance)을 통해 두 다형성이 만났을 때 어떤 일이 일어나는지 이해했습니다. 타입 인자의 서브타입 관계가 제네릭 타입에 어떻게 전파되는지, 그리고 타입스크립트가 실용성과 타입 안전성 사이에서 어떤 선택을 했는지 살펴보았습니다.

올리브영에서도 제네릭은 코드 품질 향상에 크게 기여하고 있습니다. ApiResponse<T>로 수십 개의 API 응답 타입을 하나로 통합했고, 상품·리뷰·주문 등 서로 다른 도메인의 목록을 처리하는 공통 유틸리티 함수들도 제네릭으로 구현되어 있습니다. 덕분에 새로운 도메인이 추가되어도 기존 유틸리티를 그대로 재사용할 수 있고, 타입 안전성은 그대로 유지됩니다.

다음 글에서는 조건부 타입(Conditional Types)과 타입 추론의 심화 내용을 다루어볼 예정입니다. 타입 수준에서 조건을 분기하고, 복잡한 타입을 변환하는 방법을 알아보겠습니다.

Reference

https://www.typescriptlang.org/docs/handbook/2/generics.html

https://www.typescriptlang.org/docs/handbook/type-compatibility.html

https://github.com/microsoft/TypeScript/wiki/FAQ

https://toss.tech/article/typescript-type-compatibility

https://blog.hjaem.info/46

SQS 기반 알림톡 처리에서 발생한 DB 커넥션 데드락 분석기

Tue, 30 Dec 2025 17:30:00 GMT

들어가며

안녕하세요. 올리브영 클레임 스쿼드에서 백엔드 담당하고 있는 바로바로입니다.

올리브영에서는 고객분들에게 주문 완료, 배송 완료, 반품 완료 등 다양한 알림톡이 발송되고 있습니다.

저희 클레임 스쿼드는 이번에 여러 서비스에 흩어져 있던 알림톡 발송 로직을 정리하고, 이를 이벤트 기반 구조로 사내에 새롭게 구축된 Messaging-API 호출로 전환하는 작업을 진행했습니다.

하지만 진정한 개선은 기능을 완성했을 때가 아니라, 배포 후 마주한 데드락 문제를 해결하며 시스템의 한계치를 정확히 이해했을 때 이루어졌습니다. 30,000ms의 타임아웃 에러를 0으로 만들기까지, SQS와 트랜잭션 설정을 꼼꼼하게 튜닝했던 기록을 정리했습니다.

기존 알림톡 구조의 문제점

기존 알림톡 발송 구조에서는 반품 완료, 스마트반품 접수 등 각 비즈니스 로직마다 알림톡 전송 로직이 개별적으로 구현되어 있어, 공통 로직을 수정하거나 정책을 변경할 때 여러 코드를 동시에 수정해야 하는 문제가 있었습니다.

이로 인해 유지보수가 점점 어려워지고, 변경에 따른 사이드 이펙트 발생 가능성도 높아졌습니다.

또한 알림톡 전송이 실패했을 경우 이를 자동으로 재처리할 수 있는 별도의 재전송 프로세스가 마련되어 있지 않아, 장애 상황에서는 운영자가 직접 개입해야 하는 한계가 있었습니다.

기술적으로는 알림톡 발송 로직이 비즈니스 트랜잭션 내에 강하게 결합되어 있다는 점이 가장 큰 문제였습니다. 외부 API 호출 지연이나 네트워크 이슈가 발생할 경우 비즈니스 트랜잭션 전체가 대기 상태에 빠지게 되며, 이는 곧 시스템 전체의 처리량 저하로 이어질 수 있었습니다.

특히 대량의 알림톡을 배치로 발송할 때는 모놀리식 애플리케이션에 부하가 집중되어 시스템 전반의 안정성을 위협하는 구조였습니다.

SQS 기반 이벤트 알림 구조 도입

저희는 기존 알림톡 구조를 개선하기 위해 Amazon SQS 기반의 이벤트 알림 구조 도입을 검토했습니다.
이에 따라 SQS 중심으로 알림 발송 흐름을 재설계했고, 아래와 같이 구성도를 설계했습니다.

1. 구성도 설계

이벤트 기반 알림 발송 시스템 구성도

위 구성도를 바탕으로 한 알림톡 발송 프로세스는 다음과 같습니다.

트리거: 각 비즈니스 로직(반품 완료 등)에서 알림 발송 API를 호출합니다.

메시지 발행: 발송 API는 알림에 필요한 최소한의 데이터를 담아 SQS 메시지를 발행합니다.

이벤트 소비: 컨슈머(Consumer)에서 발행된 메시지를 획득합니다.

최종 발송: 컨슈머는 알림톡 종류에 따라 필요한 데이터를 가공한 뒤, Messaging API를 호출하여 최종 발송 처리를 완료합니다.

발송 실패 시에는 실패 로그를 DB에 적재하며, Amazon EventBridge를 통해 주기적으로 재시도 API를 호출하여 위 프로세스를 반복하게 됩니다.

Amazon EventBridge를 활용한 주기적 재시도 처리

알림톡 발송은 외부 API 호출을 동반하므로 네트워크 이슈 등에 의한 일시적 실패가 발생할 수 있습니다.

이런 경우에도 메시지가 유실되지 않도록 실패 이력을 테이블에 저장하고, EventBridge가 주기적으로 재시도 API를 호출해 해당 건을 재발송하도록 구현했습니다.

DLQ(Dead Letter Queue) 방식도 고려했지만, 실패 원인 추적과 개별 재처리 제어가 어렵고 운영 가시성이 낮아,
대신 DB 기반 이력 관리 + EventBridge 재시도 구조를 선택했습니다. 이를 통해 운영자가 직접 실패 건을 조회·분석하고 유연하게 대응할 수 있는 운영 가시성을 확보했습니다.

💡 DLQ: SQS에서 설정된 최대 재시도 횟수를 초과한 메시지를 별도 큐에 보관하는 기능으로, 메시지 유실 방지에는 유용하지만 세부 제어(원인 분석, 개별 재처리)는 직접 구현이 필요합니다.

2. 알림톡 발송 로직 공통화

기존에 각 업무 로직 내부에 흩어져 있던 알림톡 전송 코드를 아래와 같이 공통 인터페이스 기반 구조 (NoticeSender)로 표준화했습니다.

//알림톡 SQS 메시지 Listener @Component class Listener( private val noticeService: NoticeService ) { @SqsListener fun consumeMessage(message: String) { when (val queueMessage = mapper.readValue(message, QueueMessage::class.java)) { noticeService.handleNotice(queueMessage) } } } //알림 핸들러 (다양한 알림톡 분기) @Service class NoticeHandler( private val noticeSenders: Map<String, NoticeSender> ) { fun handleNotice(queueMessage: QueueMessage) { val sender = when (queueMessage.noticeType) { // 반품 완료 알림톡 RETURN_COMPLETE -> noticeSenders["returnComplete"] // 교환 철회 알림톡 EXCHANGE_CANCEL -> noticeSenders["exchangeCancel"] // ...그 밖의 알림톡 발송 } ?: throw IllegalArgumentException( "지원하지 않는 알림톡 타입이거나 Sender가 등록되지 않았습니다. noticeType=${queueMessage.noticeType}" ) sender.send(queueMessage) } } //실제 알림톡 전송 프로세스 Sender interface NoticeSender { //알림톡 전송 시작 fun send(queueMessage: QueueMessage) { //공통 DTO val noticeSenderDto = NoticeSenderDto(queueMessage = queueMessage) //검증 및 관련 데이터 셋 validateAndDataPut(noticeSenderDto) //템플릿 생성 createTemplate(noticeSenderDto) //Messaging API Request 생성 createMessagingRequest(noticeSenderDto) //Messaging API callMessageApi(noticeSenderDto) //알림 내역 저장 saveNoticeMessageInfo(noticeSenderDto) } //검증 및 데이터 PUT fun validateAndDataPut(noticeSenderDto: NoticeSenderDto); //템플릿 생성 fun createTemplate(noticeSenderDto: NoticeSenderDto): Map<String, String> //messaging API Request 생성 fun createMessagingRequest(noticeSenderDto: NoticeSenderDto): MessageApiRequest //Messaging API 호출 fun callMessageApi(noticeSenderDto: NoticeSenderDto) //알림 내역 저장 fun saveNoticeMessageInfo(noticeSenderDto: NoticeSenderDto) //...공통 구현체 }

알림톡 발송 로직 공통 인터페이스

이를 통해 알림 발송 흐름(검증 → 템플릿 생성 → 메시지 생성 → 발송 → 저장)을 하나의 파이프라인으로 일원화하고, 각 알림 유형은 별도의 Sender 구현체만 추가하면 동작하도록 설계했습니다.

이렇게 개선함으로써 알림 발송 로직이 트랜잭션 처리와 분리되어 성능 저하나 커넥션 점유의 위험을 줄일 수 있었으며, 새로운 알림이 추가될 때도 기존 코드를 수정하거나 의존성을 변경할 필요 없이, 각 알림이 독립적으로 확장·관리될 수 있는 구조를 만들었습니다.

3. 트랜잭션 결합 해소

기존 구조에서는 알림톡 발송이 비즈니스 트랜잭션 내부에서 함께 처리되면서, 알림 전송 성공 여부와 관계없이 트랜잭션이 알림 발송 완료 시점까지 유지되는 구조였습니다. 이로 인해 외부 Messaging API 호출 지연이나 실패가 발생할 경우에도 트랜잭션이 계속 유지되며, 커넥션 점유 시간이 불필요하게 길어지는 문제가 발생할 수 있었습니다.

SQS 기반 이벤트 구조로 전환한 이후에는, 비즈니스 로직이 알림톡 발송 요청을 SQS에 발행하는 시점까지만 책임지고 즉시 다음 프로세스로 진행하도록 변경되었습니다.

실제 알림톡 발송 여부나 처리 결과는 Consume 서버에서 비동기적으로 처리되기 때문에, 발송 성공·실패와 관계없이 비즈니스 트랜잭션은 빠르게 종료됩니다.

이를 통해 트랜잭션 경합과 커넥션 점유를 줄이고, 알림 발송 처리량이 증가하더라도 비즈니스 로직에 미치는 영향을 최소화할 수 있는 구조를 만들 수 있었습니다.

배포 후 DB 커넥션 데드락

배포 후 안정적으로 알림톡들이 발행되고 한숨을 돌리려던 찰나… 아래의 오류가 순간 대량 발생한 것을 모니터링을 통해 확인했습니다.

💡 `java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30008ms.`

이는 트랜잭션이 커넥션을 점유한 상태에서 추가 커넥션을 확보하지 못하여, 대기 시간을 초과했기 때문에 타임아웃이 발생한 에러였습니다.

우리는 해당 오류에 즉시 대응했습니다. 오류와 상황을 분석해 보니 자원 경합에 의한 데드락이었어요. 단일 원인이 아닌, 아래 세 가지 요소가 복합적으로 맞물리며 발생했습니다.

SQS 폴링(Polling) 방식의 병렬 처리 특성

HikariCP maximumPoolSize 설정의 한계

트랜잭션 전파 옵션 REQUIRES_NEW에 의한 커넥션 중첩 점유

그렇다면 위의 시스템 구성 요소가 어떤 메커니즘을 통해 데드락을 유발했을까요? 내부 라이브러리 코드와 예제를 통해 상세히 살펴보겠습니다.

1. SQS 폴링 방식

Spring에서 @SqsListener를 사용하여 메시지를 소비할 경우 기본적으로 SQS는 폴링(Polling) 방식으로 메시지를 가져옵니다.

💡*Polling: 서버가 주기적으로 새로운 데이터를 확인하기 위해 반복적으로 요청을 보내는 방식

아래는 실제 메시지를 폴링하는 Spring AWS 라이브러리 코드의 일부입니다.

package org.springframework.cloud.aws.messaging.listener //SimpleMessageListenerContainer 라이브러리 일부 public class SimpleMessageListenerContainer extends AbstractMessageListenerContainer { protected void startQueue(String queueName, QueueAttributes queueAttributes) { //...생략 //**큐별로 비동기적 호출 Future<?> future = getTaskExecutor() .submit(new SimpleMessageListenerContainer.AsynchronousMessageListener(queueName, queueAttributes)); this.scheduledFutureByQueue.put(queueName, future); } private final class AsynchronousMessageListener implements Runnable { @Override public void run() { //**주기적 polling 시작점 while (isQueueRunning()) { try { //**SQS에 쌓인 메시지 가져오기 ReceiveMessageResult receiveMessageResult = getAmazonSqs() .receiveMessage( this.queueAttributes.getReceiveMessageRequest()); //**가져온 메시지의 프로세스가 모두 종료됐는지 확인하기 위한 CountDownLatch 생성 CountDownLatch messageBatchLatch = new CountDownLatch( receiveMessageResult.getMessages().size()); //**각 메시지 처리 for (Message message : receiveMessageResult.getMessages()) { if (isQueueRunning()) { //**메시지 처리 Executor (메시지를 @SqsListener로 전달 및 처리된 SQS 메시지 삭제 처리) SimpleMessageListenerContainer.MessageExecutor messageExecutor = new SimpleMessageListenerContainer.MessageExecutor( this.logicalQueueName, message, this.queueAttributes); //**메시지를 처리할 태스크 Executor(메시지 처리 Executor 종료시 CountDownLatch countDown 처리) //**각 태스크는 별도의 스레드 getTaskExecutor().execute(new SimpleMessageListenerContainer.SignalExecutingRunnable( messageBatchLatch, messageExecutor)); } else { messageBatchLatch.countDown(); } } try { //모든 메시지가 처리가 끝날때까지 대기 messageBatchLatch.await(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } catch (Exception e) { //...생략 } } //...생략 } } //...생략 }

SQS 라이브러리 코드 일부

코드의 실행 프로세스를 요약하면 다음과 같습니다.

큐 이름별로 메시지 수신을 위한 폴링 스레드 실행

폴링을 통해 SQS로부터 메시지 뭉치(Batch)를 가져옴

가져온 각 메시지를 처리하기 위해 워커 스레드(Worker Thread)를 병렬로 생성

CountDownLatch를 사용하여 해당 배치의 모든 메시지 처리가 끝날 때까지 대기

메시지 처리가 완료되면 다시 1번으로 돌아가 폴링 반복

여기서 중요한 점은, SQS는 수신한 메시지 개수만큼 스레드를 생성하여 병렬로 처리한다는 것입니다.

SQS는 폴링할 때 최대 처리 메시지를 MaxNumberOfMessages 옵션을 통해 설정할 수 있습니다.

@Bean fun messageListenerFactory(): SimpleMessageListenerContainerFactory { val factory = SimpleMessageListenerContainerFactory() factory.setAmazonSqs(amazonSQSAsync()) //**폴링을 통해 가져오는 최대 메시지 개수 5개로 설정 factory.setMaxNumberOfMessages(5) return factory }

SQS 설정 클래스

처리 방식을 좀 더 자세히 분석해보면 MaxNumberOfMessages 옵션을 통해 아래처럼 병렬로 처리할 TaskExecutor의 스레드 개수가 설정됩니다.

package org.springframework.cloud.aws.messaging.listener //SimpleMessageListenerContainer 라이브러리 일부 public class SimpleMessageListenerContainer extends AbstractMessageListenerContainer { //...생략 protected AsyncTaskExecutor createDefaultTaskExecutor() { String beanName = getBeanName(); ThreadPoolTaskExecutor threadPoolTaskExecutor = new ThreadPoolTaskExecutor(); threadPoolTaskExecutor.setThreadNamePrefix( beanName != null ? beanName + "-" : DEFAULT_THREAD_NAME_PREFIX); int spinningThreads = this.getRegisteredQueues().size(); if (spinningThreads > 0) { threadPoolTaskExecutor .setCorePoolSize(spinningThreads * DEFAULT_WORKER_THREADS); //**MaxNumberOfMessages 설정값을 통해 Executor Thread 개수 결정 int maxNumberOfMessagePerBatch = getMaxNumberOfMessages() != null ? getMaxNumberOfMessages() : DEFAULT_MAX_NUMBER_OF_MESSAGES; //**스레드 최대 개수 설정 threadPoolTaskExecutor .setMaxPoolSize(spinningThreads * (maxNumberOfMessagePerBatch + 1)); } // No use of a thread pool executor queue to avoid retaining message to long in // memory threadPoolTaskExecutor.setQueueCapacity(0); threadPoolTaskExecutor.afterPropertiesSet(); return threadPoolTaskExecutor; } //...생략 }

Spring SQS 라이브러리 SimpleMessageListenerContainer 코드 일부

또한 SQS 폴링시 메시지 개수 파라미터로 보낸다는 것을 확인할 수 있습니다.

SQS 메시지 폴링 요청시 maxNumberOfMessages 값 확인

하지만 이러한 SQS 메시지 처리 동작 방식이 어떻게 데드락을 유발했을까요? 다음 이슈도 같이 살펴보도록 하겠습니다.

2. Hikari DB Maximum-pool-size

Hikari maximum-pool-size는 스프링 개발자에게 많이 익숙한 옵션으로, 동시에 사용 가능한 DB 커넥션의 최대 개수를 설정합니다.

아래 코드는 병렬로 fooTransaction() 2번 호출하여 DB에 데이터를 저장하는 코드 예제입니다.

fun foo() { //Thread Pool 2개 SET val exec = Executors.newFixedThreadPool(2) (1..2).forEach { i -> //총 2번 병렬 호출 exec.submit { fooService.fooTransaction(i) } } } @Service class FooService(private val fooRepository: FooRepository) { @Transactional fun fooTransaction(num: Int) { println("num: $num Transaction Start") //저장 val fooEntity = FooEntity(name = "$num") fooRepository.save(fooEntity) println("num: $num Transaction End") } }

트랜잭션 예제 코드

그리고 아래와 같이 maximum-pool-size=2 설정후에 예제를 수행했습니다.

maximum-pool-size=2 설정

수행 후 실행 로그를 보면 각 스레드1, 스레드2가 커넥션 1개씩 점유하여 병렬로 트랜잭션이 실행됩니다.

maximum-pool-size=2 설정 후 트랜잭션 실행 로그

maximum-pool-size=1로 설정후 수행시 다음과 같이 스레드1 트랜잭션 종료 -> 스레드2의 트랜잭션이 수행되는 것을 확인할 수 있습니다.

maximum-pool-size=1 설정 후 트랜잭션 실행 로그

maximum-pool-size=1 이므로 총 사용 가능 커넥션은 1개, 스레드 2개가 병렬로 수행되어도,
커넥션 점유한 스레드1은 트랜잭션을 수행하고, 스레드2는 스레드1 트랜잭션이 끝난후 수행됩니다.

여기서! sleep을 추가하여 커넥션 점유 시간이 connection-timeout을 초과하도록 수정해봤습니다.

💡 Connection-timeout : 커넥션 점유를 대기하는 최대 시간

@Service class FooService(private val fooRepository: FooRepository) { @Transactional fun fooTransaction(num: Int) { println("num: $num Transaction Start") //저장 val fooEntity = FooEntity(name = "$num") fooRepository.save(fooEntity) //오래 점유 Thread.sleep(6000) println("num: $num Transaction End") } }

sleep 추가한 예제 코드

maximum-pool-size=1 설정

실행 후 로그를 확인해보니 이번 운영 이슈와 동일한 에러로그가 발생했습니다.

커넥션 타임아웃 에러 로그

위 에러 발생 상황을 정리하면 다음과 같습니다.

스레드1 트랜잭션 커넥션 점유

스레드2 트랜잭션 커넥션 점유 대기 (maximum-pool-size=1)

스레드1 6초(Sleep)동안 트랜잭션 커넥션 점유

스레드2 트랜잭션 커넥션 점유 대기 5초 초과로 인한 에러 발생 (Connection-timeout=5000ms)

3. 트랜잭션 REQUIRES_NEW

트랜잭션 REQUIRES_NEW는 트랜잭션 전파 옵션 중 하나입니다.

@Transactional(propagation = Propagation.REQUIRES_NEW)

특징은 다음과 같습니다.

이전에 수행된 트랜잭션과 별개로 항상 새로운 트랜잭션을 생성

별개의 트랜잭션을 생성하므로 커넥션도 새로 점유 → A 트랜잭션에서 REQUIRES_NEW B 트랜잭션이 실행되면 A, B 커넥션 총 2개의 커넥션을 점유

별개의 트랜잭션으로 동작하므로 B 트랜잭션이 정상처리되어 커밋되고 A 트랜잭션이 롤백되어도 B 트랜잭션은 롤백 X

하지만 주의해야할 점은 REQUIRES_NEW를 사용할 시 데드락 이슈가 발생할 수 있습니다.

예제로 살펴보겠습니다.

fun fooRequiresNew() { //요청 Thread 2 val exec = Executors.newFixedThreadPool(2) //두번 병렬 호출 (1..2).forEach { i -> //FooParentService 호출 exec.submit { fooParentService.fooTransactionParent(i) } } } @Service class FooParentService( private val fooChildService: FooChildService, private val fooRepository: FooRepository ) { @Transactional fun fooTransactionParent(num: Int) { println("$num Parent Transaction Start") val fooEntity = FooEntity(name = "$num") fooRepository.save(fooEntity) //Child 트랜잭션 시작전 Sleep Thread.sleep(1000) //Child 트랜잭션 호출 fooChildService.fooTransactionChild(num) println("$num Parent Transaction End") } } @Service class FooChildService( private val fooRepository: FooRepository ) { @Transactional(REQUIRES_NEW) fun fooTransactionChild(num: Int) { println("$num Child Transaction Start") val fooEntity = FooEntity(name = "$num") fooRepository.save(fooEntity) println("$num Child Transaction End") } }

REQUIRES_NEW 트랜잭션 예제 코드

해당 예제를 maximum-pool-size=2로 설정하고 수행시 다음과 같은 결과가 나오는 것을 확인할 수 있습니다.

maximum-pool-size=2 설정 후 예제 실행 로그

로그를 확인해보면 1번, 2번 트랜잭션 모두 Child 트랜잭션이 수행되지 못하고 데드락이 발생하여 타임아웃이 발생한 것을 볼 수 있습니다.

데드락 발생 과정은 다음과 같습니다.

병렬 fooTransactionParent() 2번 호출

1번 Parent 트랜잭션 커넥션 1개 점유

2번 Parent 트랜잭션 커넥션 1개 점유

1번 Parent 트랜잭션 Save 및 1초후 1번 Child 트랜잭션 점유를 위해 대기 (이미 커넥션은 모두 점유된 상태)

1번 트랜잭션과 동일하게 2번 Child 트랜잭션 점유 대기

1, 2번 Parent 트랜잭션은 Child 트랜잭션이 끝날때까지 계속 점유하기에 데드락 발생

그림으로 표현하면 다음과 같습니다.

트랜잭션 데드락 발생 과정

해결 과정

이제 위에서 봐온 내용을 토대로 이번 이슈가 실제로 어떻게 발생했는지 간략하게 정리하고 해결방법에 대해 말씀드리겠습니다.

1. 장애 발생 메커니즘 (Root Cause)

이번 장애는 병렬 처리 환경과 트랜잭션 전파 속성이 충돌하며 발생한 전형적인 자원 경합 문제였습니다.
아래 두 가지 설정이 맞물리면서 시스템은 데드락에 빠질 수 있는 임계 상태에 놓여 있었습니다.

커넥션 점유의 불균형: SQS의 MaxNumberOfMessages 가 DB 커넥션 풀 크기보다 크게 설정되어 있었습니다. (커넥션 개수 < 최대 폴링 메시지 개수)

중첩 트랜잭션의 함정: 이력 저장 로직에 REQUIRES_NEW 옵션을 사용하여, 알림 발송 1건당 최소 2개의 커넥션이 필요한 구조였습니다.

정리하면 병렬로 처리되던 각 메시지가 커넥션을 1개씩 점유한 상태에서, 이력 저장을 위해 1개의 커넥션이 더 필요했지만 가용 커넥션이 남아 있지 않아 모든 메시지 처리가 동시에 대기 상태에 빠지며 데드락이 발생했습니다

SQS 메시지 폴링 요청시 maxNumberOfMessages 값 확인

2. 병렬 처리 환경에서의 최소 커넥션 계산

해당 상황 해결을 위해 HikariCP에서 제시하는 풀 사이징 가이드를 기준으로 필요 커넥션 수를 계산해보면, 다음과 같이 정리할 수 있습니다.

(참고: Hikari CP 공식 문서)

데드락을 피하기 위한 최소 필요 커넥션 수 = Tn × (Cm − 1) + 1

• Tn: 동시에 처리되는 최대 스레드 개수 • Cm: 스레드 1개 처리 시 필요한 최대 커넥션 수

이번 사례에서는 알림톡 1건 처리 시 부모 트랜잭션 1개, 이력 저장을 위한 REQUIRES_NEW 트랜잭션 1개로, Cm = 2인 구조였습니다.

즉, SQS 폴링으로 동시에 처리되는 메시지 수(Tn)가 증가할수록, 필요한 커넥션 수 역시 증가하는 구조라 볼 수 있습니다. (Cm = 1 인 경우 필요 커넥션 개수는 1개로 고정)

3. 커넥션 요구량 제어를 통한 문제 해결

이번 이슈의 해결 방법은 필요 커넥션 수를 조절하면 되기에 아래처럼 간단하게 수정하여 해결했습니다.

REQUIRES_NEW 옵션이 필요없는 로직이었기에 REQUIRES_NEW 옵션 제거 (Cm = 1)

SQS 최대 폴링 메시지 개수를 커넥션 개수와 같거나 적게 변경 (메시지 개수 <= 커넥션 개수)

이러한 설정을 조정함으로써, 알림 처리 과정에서 동시에 요구되던 커넥션 수를 효과적으로 줄일 수 있었습니다.

REQUIRES_NEW 옵션 제거를 통해 알림 한 건당(스레드) 추가 트랜잭션 생성을 방지했고, SQS 폴링 시 한 번에 처리되는 메시지 개수를 제한함으로써 병렬로 실행되는 트랜잭션 수 또한 제어할 수 있었습니다.

그 결과, 메시지 처리량이 증가하는 상황에서도 커넥션 경합과 데드락이 발생하던 구조를 해소할 수 있었습니다.

마치며

이번 사례는 단순한 설정 오류라기보다는, 서로 다른 구성 요소들이 병렬 처리 환경에서 어떻게 맞물려 동작하는지에 대한 이해가 충분히 연결되지 않았던 지점에서 비롯된 이슈였습니다. 이를 통해 기능 자체의 구현뿐만 아니라, 해당 기능이 어떤 실행 환경과 처리 흐름 속에서 동작하는지를 함께 고려하는 것이 얼마나 중요한지 다시 한 번 되돌아보게 되었습니다.

이 글을 읽고 계신 분들 역시 비동기 처리 구조를 설계할 때, 각 설정과 옵션이 병렬 환경에서 어떤 영향을 미칠 수 있는지 한 번쯤 점검해보시면 좋을 것 같습니다.

저희는 앞으로도 이러한 경험들을 바탕으로, 시스템의 동작 방식과 구조적인 특성을 함께 고려하는 개발을 이어가고자 합니다.

긴 글 읽어주셔서 감사합니다.

올리브영의 실시간 캠페인 타겟팅을 위한 CDC 전환기

Mon, 29 Dec 2025 16:00:00 GMT

캠페인과 데이터 정합성

캠페인 시스템은 올리브영 고객들에게 필요한 혜택과 상품을 적절한 타이밍에 제공하여 완성된 쇼핑 경험을 제공하고 구매 전환을 극대화하는 역할을 담당합니다. 주요 임무는 고객의 최신 행동이나 구매 패턴에 기반해 가장 적절하다고 생각되는 알림을 선별해 발송하는 것입니다.

예를 들자면 쿠폰 등의 혜택을 미사용한 사용자에게 혜택을 사용하도록 유도하거나 사용자가 놓치기 쉬운 프로모션을 강조함으로써 올리브영의 구매 전환율을 끌어올리는데 크게 기여하고 있습니다.

그런데 만약 유저 패턴이 실시간으로 시스템에 반영되지 않아서 유저가 필요한 알림을 받지 못한다면 어떨까요? 쿠폰 발행 대상자가 알림을 받지 못한다든지, 혹은 마케팅 정보 수신을 거부했음에도 알림받는 경우가 있겠는데요. 전자는 잠재적인 구매 전환율의 하락으로 이어질 것이고, 후자는 고객의 신뢰를 잃을 수 있겠죠.

이런 이슈는 데이터 정합성(Data Consistency) 측면에서 발생합니다. 다르게 말하면 고객의 최신 상태가 캠페인 시스템에 실시간성으로 반영되지 못했기 때문입니다.

올리브영의 캠페인 시스템은 ODI를 이용한 배치성 스케줄러로 고객 데이터를 소스 데이터베이스에서 싱크하고 있었습니다. 주기는 20분에서 1시간까지 다양하지만 실시간 데이터 변경을 반영하지 못 한다는 명백한 한계를 가지고 있습니다. 배치 주기를 아무리 짧게 해도 짧게는 몇 분, 길게는 몇십 분의 공백이 발생하기 때문입니다.

이는 실시간으로 변화하는 고객 행동에 기민하게 대응하는 것을 어렵게 만들었습니다. 따라서 저희는 이 근본적인 문제를 해결하고자 OGG 기반의 CDC와 Kafka 기반 실시간 스트리밍 시스템으로 데이터 파이프라인을 구축하기로 했습니다.

그럼 이제부터 캠페인 도메인에서 ODI 기반의 배치 시스템을 OGG와 Kafka 기반의 CDC 아키텍처로 성공적으로 전환한 여정과 그 과정에서 마주한 기술적 도전, 그리고 해결책에 대해 소개드리고자 합니다.

ODI의 기반 캠페인 시스템의 한계

기존 올리브영 캠페인 시스템은 ODI(Oracle Data Integrator)를 활용한 배치(Batch) 방식으로 고객 데이터를 동기화했습니다. 이 구조는 데이터 웨어하우징 통합에는 최적화되어 있지만, 실시간 대응이 필요한 캠페인 서비스에는 근본적인 한계를 가집니다.

ODI 핵심 구조 및 작동 원리

데이터 추출 (Extract): 소스 데이터베이스에서 데이터를 추출합니다.

타겟 적재 (Load): 추출한 데이터를 타겟 데이터베이스에 적재합니다.

대규모 변환 (Transform): 데이터를 적재한 후, 타겟 데이터베이스의 성능을 이용하여 대규모 데이터 변환(조인, 계산 등)을 수행합니다.

동기화 방식: 캠페인 시스템이 바라보는 원천 테이블에 대응하는 ODI 스케줄러를 통해 동기화가 이루어집니다.

동기화 주기: 최소 20분에서 최대 1시간까지 주기적인 간격으로 데이터를 싱크합니다.

데이터 매핑 구조: 1:1 단순 매핑부터 여러 소스 테이블을 조인하여 하나의 타겟에 싱크하는 복잡한 방식까지 혼재되어 있습니다.

ODI를 통한 소스와 타겟 데이터베이스의 싱크

이러한 배치 중심의 구조는 구체적으로 다음과 같은 성능 및 비즈니스적 문제로 이어졌습니다.

데이터 지연 (Data Latency)

실시간 대응 불가: 데이터가 정해진 배치 주기에만 업데이트되므로, 고객의 행동 변화(예: 마케팅 수신 동의/철회, 쿠폰 발급)에 대한 최신 정보를 즉각적으로 활용할 수 없었습니다.

고객 타겟팅 오류: ODI 수행 시간대에 따라 데이터 최신화가 지연되어, 마케팅 수신 동의를 했음에도 타겟팅에서 누락되거나(기회 손실), 반대로 알림을 껐음에도 알림을 받는(고객 경험 저하) 이슈가 발생했습니다.

성능 이슈 (Performance Bottleneck)

소스 DB 부하 집중: 특정 시간대에 쿠폰 대량 발급이나 회원 멤버십 승급과 같이 대규모 데이터 변경이 발생하면, ODI가 이를 한꺼번에 처리하려 하면서 소스 데이터베이스에 과도한 부하를 주었습니다.

연쇄적인 싱크 지연: 처리해야 할 데이터량이 많아지면 ODI 작업 자체가 지연되고, 이 지연된 ODI Task가 전체 시스템에 영향을 미쳐 모든 데이터 싱크 프로세스가 함께 지연되는 결과를 야기했습니다.

OGG(Oracle Golden Gate)

올리브영이 실시간 데이터 동기화(CDC)를 위해 채택한 OGG는 엔터프라이즈급 안정성과 확장성을 갖춘 툴로, 기존 배치 시스템의 한계를 극복하는 핵심 기능을 제공합니다.

OGG의 주요 기능은 Oracle DB의 트랜잭션 로그를 활용하여 데이터 변경 사항을 실시간으로 캡처하고, 이를 Kafka 스트리밍 생태계로 효율적으로 전송하는 데 집중되어 있습니다.

실시간 변경 데이터 캡처 (CDC 기능)

OGG는 Oracle 데이터베이스의 트랜잭션 로그(Redo Log)를 직접 읽어 INSERT, UPDATE, DELETE와 같은 데이터 변경 사항을 실시간으로 캡처합니다. 이는 데이터 변경이 발생하자마자 즉시 감지하여 데이터 지연 시간을 극소화합니다.

Kafka 연동 및 데이터 처리

캡처된 변경 사항을 Kafka 환경에서 사용하기 적합하도록 JSON, Avro, Parquet 등의 형식으로 변환하고 포맷팅합니다.

Kafka로 전송

변환된 데이터를 Kafka Connect 프레임워크를 통해 지정된 Kafka 메시지로 안정적으로 전송합니다.

데이터 파이프라인 구축

OGG 커넥터를 사용하여 데이터베이스를 Kafka의 데이터 스트리밍 생태계에 연결함으로써, 복잡한 실시간 데이터 파이프라인을 효율적으로 구축할 수 있습니다.

안정성, 신뢰성 및 확장성

OGG는 엔터프라이즈급 솔루션으로서, 데이터 손실 없이 안정적인 데이터 복제 및 전송을 보장합니다.

Kafka Connect 프레임워크를 사용하기 때문에 수평 확장(Scale-out)이 용이하며, 여러 데이터베이스의 변경 사항을 동시에 처리할 수 있는 능력을 갖춥니다.

OGG 커넥터의 활용

OGG 커넥터를 활용하면 데이터베이스의 변경 사항이 발생하는 즉시 Kafka로 전송되어, 실시간 분석, 데이터 웨어하우징, 마이크로서비스 간 데이터 동기화 등 다양한 실시간 시나리오에 즉각적으로 활용할 수 있습니다.

OGG가 지원하는 주요 데이터 복제 토폴로지

OGG를 활용한 하이브리드 CDC 적용 전략

OGG 커넥터를 그대로 도입하지 못한 주요 원인은 기존 배치 시스템의 복잡한 데이터 통합 로직 때문이었습니다. 이 문제를 해결하고 커넥터의 장점을 유지하기 위해 OGG 커넥터와 워커를 혼합한 하이브리드 아키텍처를 절충안으로 채택했습니다.

OGG 커넥터 단독으로는 기존 ODI 시스템의 복잡한 요구사항을 처리할 수 없었습니다.

1:1 매핑 제약 : OGG 커넥터는 기본적으로 소스 테이블의 Row와 타겟 테이블의 Row가 1:1로 대응하는 구조만 지원합니다. 즉, 타겟 테이블의 컬럼이 모두 소스 테이블에 존재해야 합니다.

복잡한 비즈니스 로직 미지원 : 기존 캠페인 도메인은 ODI를 통해 다수의 원천 테이블을 조인(Join) 하고 데이터를 가공하여 하나의 통합 테이블(Consolidated Table) 에 데이터를 싱크하는 복잡한 통합 로직을 가지고 있었습니다.

결과 : 순수한 OGG 커넥터만으로는 이처럼 예외적이고 복잡한 데이터 변환 및 통합 비즈니스 로직을 처리하는 것이 불가능했습니다.

하이브리드 구조 구상

OGG는 CDC의 안정성을, Campaign-Worker는 데이터의 통합 및 가공을 담당하는 방식으로 역할을 분리했습니다.

OGG 커넥터와 Campaign-Worker의 하이브리드 아키텍처

제시된 하이브리드 아키텍처는 OGG 커넥터의 안정성과 Campaign-Worker의 비즈니스 로직 처리 능력을 결합하여, 기존 ODI 시스템의 복잡한 요구사항과 CDC의 실시간성 목표를 동시에 달성했습니다.
1. OGG 커넥터 담당 (1:1 단순 매핑)

메시지 발행량이 많고, 별도의 비즈니스 로직이 필요 없는 테이블은 OGG 커넥터를 통해 ADW(타겟 DB)로 자동 싱크됩니다. 애플리케이션 레벨의 관리 없이 안정성과 효율성을 확보했습니다.

2. Campaign-Worker 담당 (복합 처리 로직)

복잡한 비즈니스 로직이 필요한 테이블 (예: 여러 테이블 조인, 조건부 변환)의 변경 메시지는 Kafka를 통해 워커가 직접 소비하여 자체 로직으로 처리합니다. 커넥터의 안정성을 유지하면서 복잡한 통합 요구사항을 만족시킵니다.

메시지 순서 문제와 해결 전략 요약

문제 상황: 테이블 간의 의존성

하지만 위 구조 역시 완전한 솔루션은 아니었습니다. 가장 큰 문제를 하나 꼽자면 시스템 자체가 여러 토픽에서 발행된 메시지들의 순서에 서로 의존하는 구조라는 점 입니다. 하지만 카프카의 단일 파티션이 아닌 서로 다른 토픽들간의 메시지 순서 제어는 카프카 자체의 메커니즘으로만으론 불가능합니다. 이러한 이슈로 인해 핵심 문제는 서로 연관된 두 테이블이 바라보는 토픽의 메시지가 타겟에서 원하는 순서대로 소비되지 않을 때 발생합니다.

이해를 돕기 위해 테이블 A와 테이블 B를 다음과 같이 정의하겠습니다.

테이블 A (베이스 정보): 회원 기본 정보(회원번호, 회원ID 등)를 담고 있으며, 변경량이 많습니다.

테이블 B (부가 정보): 마케팅 수신 정보 등 부가 데이터를 담고 있으며, 테이블 A와 조인되어 타겟에 통합됩니다.

문제 발생 원인 및 시나리오

문제는 테이블 B의 변경 메시지가 먼저 도착했는데, 테이블 A에 해당하는 베이스 정보(Key)가 타겟 테이블에 아직 없는 경우에 발생합니다. 일반적으로는 A 테이블의 변경이 먼저 완료되지만, 드물게 A와 B 테이블이 거의 동시에 업데이트될 경우 Kafka 토픽에서 메시지 순서가 보장되지 않아, B에 해당하는 A의 베이스(Key) 정보를 찾을 수 없어 B의 변경 메시지가 저장에 실패하는 문제가 발생했습니다.

메시지 순서 불일치로 인한 데이터 누락 발생 시나리오

해결 전략 - Retry, DLT, 복구 배치를 활용한 3중 안전장치

이러한 이슈를 보완하기 위해 메시지의 소비 순서를 강제로 보장할 수 없다는 가정을 바탕으로, 손실을 최소화하고 복구 능력을 확보하는 3가지 전략들을 보완했습니다.

1. Retry (재시도) 메커니즘

목적: 일시적인 메시지 도착 지연으로 인한 데이터 불일치 문제를 해결합니다.

작동: 베이스 테이블(A)의 레코드(ROW)가 없을 경우, 최대 3회까지 짧은 간격으로 즉시 재시도를 수행하여 대부분의 요청을 성공시킵니다.

2. DLT(Dead Letter Topic) 발행

목적: 컨슈머 처리량 부족이나 장기간의 순서 문제로 인한 메시지 유실을 방지하고 격리합니다.

작동: 3회 재시도 후에도 실패한 메시지는 별도의 DLT 토픽으로 발행합니다.

3. DLT 복구 배치 (DLT Recovery Batch)를 통한 최종 정합성 보장

목적: 영구적인 데이터 누락을 해결하여 최종 데이터 정합성을 보장합니다.

작동: DLT 리스너가 해당 메시지를 받아 별도의 테이블에 저장하고, 5분/1시간 주기로 동작하는 복구 배치를 통해 저장되지 않은 건들을 주기적으로 재처리합니다. 이는 베이스 테이블 정보가 뒤늦게 도착했을 경우의 누락을 해결합니다.

Retry와 DLT 사용 예시

Retry와 DLT를 사용한 이중 백업 전략을 수립할 때, 다음과 같은 가정을 바탕에 두었습니다.

가정 1 : 연관되어 있는 두 토픽에서 발행하는 메시지는 기본적으로 짧은 텀의 간격을 두고 동시에 발행됩니다.

가정 2 : 메시지 발행량에 따라 이 텀은 커질 수 있으며, 기본적으로 테이블 A와 B 중의 순서는 보장 불가합니다.

위 가정을 기반으로 Retry 로직을 적용했습니다. 전체 처리 속도가 Retry 덕분에 감소할 수 있지만, 데이터 정합성이 훨씬 중요했기에 짧은 간격으로 Retry 시도하는 것만으로도 대부분의 요청이 성공하는 것을 확인했습니다. 하지만 Retry만으로도 부족한 케이스가 존재했습니다. 특정 토픽에 대해 메시지 발행량이 컨슈머의 처리량보다 커져서 offset lag이 많이 발생한다면, 몇 분의 간격으로 토픽의 메시지 소비 텀이 길어지기도 했기 때문입니다. 이처럼 Retry만으로 해결되지 않는 장기적인 지연 케이스를 수정하기 위해 실패 케이스를 저장하는 DLT 테이블과, 해당 테이블에서 데이터를 복구시키는 복구 배치가 필요했습니다.

Retry & DLT 동작 flow

백업 로직은 다음과 같이 구성됩니다.

Base 테이블 (A)에 해당하는 레코드가 없을 경우 예외 발생

예외 발생시 최대 3회 Retry

Retry 후에도 Base 테이블이 없을 경우 DLT 로 발행

DLT 리스너에서는 해당 건을 받아 따로 테이블에 저장

이후 복구 배치가 돌면서 저장되지 않은 건들을 BASE 테이블에 저장 시도

//카프카 에러 핸들러에서의 DLQ 설정 @Bean fun kafkaListenerMultiConcurrencyContainerFactory(kafkaTemplate: KafkaTemplate<String, Any>): ConcurrentKafkaListenerContainerFactory<String, String> { val factory: ConcurrentKafkaListenerContainerFactory<String, String> = ConcurrentKafkaListenerContainerFactory() factory.consumerFactory = memberConsumerFactory() factory.containerProperties.ackMode = ackMode factory.containerProperties.pollTimeout = POLL_TIMEOUT factory.containerProperties.idleBetweenPolls = idleBetweenPolls factory.setConcurrency(6) val errorHandler = getDlqErrorHandler(kafkaTemplate) factory.setCommonErrorHandler(errorHandler) return factory } private fun getDlqErrorHandler(kafkaTemplate: KafkaTemplate<String, Any>) : DefaultErrorHandler { return DefaultErrorHandler( DeadLetterPublishingRecoverer(kafkaTemplate) { record, ex -> TopicPartition("${record.topic()}.dlq", record.partition()) }, FixedBackOff(BACK_OFF_INTERVAL, KAFKA_CONSUMER_MAX_RETRY_ATTEMPT) ) }

검증과 모니터링

CDC 기반 데이터 파이프라인의 핵심은 실시간 데이터의 정합성과 안정성을 보장하는 것입니다. 이를 위해 Datadog 대시보드와 주기적 배치 작업을 결합한 다각적인 검증 및 모니터링 체계를 구축하였습니다.

1. Datadog 기반 실시간 모니터링

CDC 시스템을 모니터링하는 Datadog 대시보드

Datadog 대시보드는 CDC 시스템의 운영 현황과 성능 지표를 실시간으로 시각화하여 데이터 흐름의 건강 상태를 파악하는 핵심 도구입니다.

토픽 메시지 유입 현황: 각 토픽에 얼마나 많은 메시지가 들어오고 있는지를 파악하여 실시간 데이터 로드 상태를 확인합니다.

컨슈머 지연 (Kafka Lag): 토픽별로 컨슈머가 메시지를 처리하지 못하고 얼마나 뒤처지고 있는지(지연 정도)를 모니터링하여, 시스템의 처리 속도 및 병목 현상을 즉시 감지합니다.

2. DLQ 후처리 배치를 이용한 정합성 검증 및 복구

DLT 복구 배치

데이터 유실이나 정합성 문제를 방지하기 위해 복구 메커니즘과 검증 프로세스를 주기적인 Batch로 처리했습니다.

검증 배치: 실제 데이터가 소스와 타겟 간에 정확하게 동기화되었는지를 확인하는 배치 작업입니다.

DLT 복구 배치: 실패 메시지가 격리된 DLT(Dead Letter Topic) 테이블에 쌓이면, 이 배치 작업이 주기적으로 돌면서 저장되지 않은 메시지들을 재처리하여 누락된 데이터가 없도록 복구합니다.

이러한 검증 배치 및 복구 배치의 수행 내역과 복구 현황 또한 모니터링 대시보드에서 확인할 수 있도록 구성하여, 데이터 무결성을 이중으로 보장합니다.

최종 구현

최종적으로 구축된 CDC 아키텍처는 다음과 같습니다.

최종 아키텍쳐

OGG-kafka 기반의 CDC 최종 아키텍처는 데이터의 종류에 따라 처리 경로를 이원화하고, 재시도(Retry)와 DLT(Dead Letter Topic)를 활용한 복합적인 복구 전략을 통해 데이터 정합성과 안정성을 극대화했습니다.

️데이터 처리 방식

이원화된 경로: 데이터를 단순 베이스 정보와 복잡한 부가 정보로 나누어, 각 데이터의 특성에 맞는 최적의 경로로 처리했습니다.

커넥터(OGG) 담당: 가장 변경량이 많은 핵심 데이터는 커넥터를 활용해 신속하고 안정적인 ADW(Analytical Data Warehouse) 적재를 담당합니다.

워커(Campaign-Worker) 담당: 약관 동의, 마케팅 정보 등 여러 테이블의 변경 사항을 받아 복잡한 조인 및 변환 로직을 수행하여 타겟 테이블에 적재합니다.

🛡️ 복합적인 비즈니스 로직 환경에서 메시지 순서 불일치로 인한 데이터 손실을 방지하기 위해 3단계의 방어 메커니즘을 구축했습니다. 회원 기본 정보(Base) 메시지가 부가 정보 메시지보다 늦게 도착하여 발생하는 일시적인 데이터 불일치 문제를 해결하기 위해, Campaign-Worker는 매칭되는 회원 번호(MBR_NO)가 없으면 최대 3회까지 메시지 처리를 재시도(Retry)하여 순서 지연을 해소합니다. 이후 3회 재시도 후에도 처리에 실패한 메시지는 DLT(Dead Letter Topic)로 이동시켜 별도의 테이블에 안전하게 저장합니다. 이는 메시지 유실을 방지하는 1차적인 격리 조치입니다. 마지막으로 복구 배치가 DLT 테이블에 쌓인 실패 메시지들을 대상으로 주기적인 실행(5분 및 1시간 주기)을 통해 누락된 기본 정보가 타겟에 반영된 후 실패 메시지를 재처리하여 최종적인 데이터 정합성을 보장합니다.

성과

ODI 기반(Batch)에서 OGG/Kafka 기반(CDC)으로 전환하며 다음과 같은 개선 사항을 달성했습니다.

데이터 처리 속도: 20분 ~ 1시간 주기 (배치)에서 준실시간 (이벤트 기반)으로 개선

고객 대응 능력: 실시간 고객 행동에 대한 지연 대응에서 벗어나, 변경 발생 즉시 타겟팅 가능 (예: 마케팅 동의 즉각 반영)

소스 DB 부하: 특정 시간대에 부하가 집중되던 문제에서 트랜잭션 로그 기반으로 전환되어 부하 분산 및 최소화

데이터 정합성 보장: 순서 이슈 발생 시 데이터 누락 위험이 있었으나, Retry, DLT, 복구 배치를 통한 이중 안정성 확보로 극복

모니터링: Datadog과 Slack 등을 활용하여 메시지 누락 발생이나 소비 이상 시 즉시 탐지 가능

이번 프로젝트는 올리브영 캠페인 시스템의 데이터 파이프라인 핵심 문화를 '주기적 동기화' 에서 '이벤트 기반의 실시간 반응' 으로 변화시켰다는 점에 큰 의의가 있습니다.

특히, ODI의 1:N 조인 변환 로직을 OGG 커넥터와 Campaign-Worker의 하이브리드 구조로 분리하고, 메시지 순서 문제 해결을 위해 DLT와 복구 배치를 적용한 것은 실시간 스트리밍 환경에서 복잡한 비즈니스 로직과 엔터프라이즈급 안정성을 동시에 확보한 전략이었습니다.

이러한 준실시간 데이터 환경을 통해 올리브영은 고객의 행동 변화에 즉각적으로 대응하는 개인화된 캠페인을 제공할 수 있는 견고하고 확장 가능한 시스템을 구축하며, 고객 경험 측면에서 한 단계 더 성장할 수 있었습니다.

권한마다 보안 솔루션이 다르다면? 하이브리드 환경에서 우아하게 파일 보호하기

Fri, 26 Dec 2025 00:00:00 GMT

목차

들어가며: 변화의 지침과 현실적인 제약

해결책 탐색: 왜 전략 패턴인가?

기술적 설계: 전략 패턴을 통한 추상화

AOP를 활용한 자동 적용

삽질기: 실제 적용하면서 마주한 문제들

마치며

1. 들어가며: 변화의 지침과 현실적인 제약

올리브영의 오프라인 매장 운영을 책임지는 백오피스 시스템은 매일 수많은 엑셀과 PDF 문서를 생성하고 처리합니다. 그동안 우리는 이 문서들을 보호하기 위해 표준화된 설치형 에이전트(Agent) 보안 솔루션을 사용하여 파일을 암호화해 왔습니다.

최근 전사 보안 정책이 고도화됨에 따라, 문서 보안 체계를 신규 클라우드 기반 보안 시스템으로 전환하게 되었습니다. 이에 따라 백오피스 시스템 내 파일 암호화가 적용된 모든 영역을 새로운 방식으로 전환해야 했습니다.

하지만 분석 단계에서 중요한 현실적 제약에 직면했습니다. 신규 도입된 클라우드 보안 시스템은 라이선스 및 인프라 구조상 '본사 구성원'에게만 지원된다는 점이었습니다.

백오피스 시스템은 본사 구성원뿐만 아니라, 매장에서 근무하는 '매장 구성원'이나 외부 '협력사'들도 빈번하게 사용합니다. 결국, 우리는 두 가지 보안 체계를 동시에 운영해야 하는 상황이 되었습니다.

본사 임직원: 신규 클라우드 기반 보안 (Type A)

그 외 (매장/협력사): 기존 에이전트 기반 보안 (Type B)

즉, "로그인한 사용자의 권한(Role)에 따라 적절한 암호화 솔루션을 동적으로 선택하여 적용"해야 하는 과제가 주어진 것입니다.

2. 해결책 탐색: 왜 전략 패턴인가?

처음부터 전략 패턴을 떠올린 건 아니었습니다. 가장 먼저 떠오른 건 역시 단순한 if-else 분기였습니다.

2.1. 첫 번째 시도: 단순 if-else 분기

"일단 돌아가게 만들자"는 생각으로 빠르게 프로토타입을 작성해봤습니다.

// 첫 번째 시도: 단순 if-else public byte[] downloadSalesReport(User user) { byte[] excelData = excelService.createExcel(); if (user.isHeadquarters()) { // 클라우드 API 호출 return cloudSecurityApi.encrypt(excelData, user.getId()); } else { // 에이전트 라이브러리 호출 return agentSecurityLib.protect(excelData); } }

간단해 보이지만, 실제로 적용하려니 문제가 보이기 시작했습니다.

백오피스 시스템에는 파일을 다운로드하는 API가 수십 개에 달했습니다. 매출 리포트, 재고 현황, 발주서, 정산 내역... 이 모든 곳에 동일한 if-else 로직을 복붙해야 했습니다. 그리고 만약 향후 제3의 보안 솔루션이 추가된다면? 수십 개의 파일을 다시 찾아다니며 else if를 추가해야 하는 악몽이 그려졌습니다.

2.2. 두 번째 시도: 별도 서비스 클래스로 분리

그렇다면 암호화 로직을 별도 서비스로 분리하면 어떨까요?

// 두 번째 시도: 서비스 클래스 분리 @Service public class FileEncryptionService { public byte[] encrypt(byte[] data, User user) { if (user.isHeadquarters()) { return cloudSecurityApi.encrypt(data, user.getId()); } else { return agentSecurityLib.protect(data); } } } // 사용하는 쪽 public byte[] exportExccel(User user) { byte[] excelData = excelService.createExcel(); return fileEncryptionService.encrypt(excelData, user); // 호출 필요 }

if-else가 한 곳으로 모이긴 했지만, 여전히 두 가지 문제가 남았습니다.

호출 누락 위험: 모든 다운로드 메서드에서 fileEncryptionService.encrypt()를 명시적으로 호출해야 합니다. 신규 API를 만들 때 깜빡하면? 암호화되지 않은 파일이 그대로 내려갑니다.

OCP 위반: 새로운 보안 솔루션이 추가되면 FileEncryptionService 내부를 수정해야 합니다. "확장에는 열려 있고, 수정에는 닫혀 있어야 한다"는 개방-폐쇄 원칙(OCP)에 어긋납니다.

2.3. 세 번째 시도: 팩토리 패턴?

잠깐, 팩토리 패턴은 어떨까요? 사용자 타입에 따라 적절한 암호화 객체를 생성해서 반환하면 되지 않을까요?

// 팩토리 패턴 검토 public class EncryptorFactory { public Encryptor create(User user) { if (user.isHeadquarters()) { return new CloudEncryptor(); } else { return new AgentEncryptor(); } } }

팩토리 패턴은 객체 생성에 초점을 맞춘 패턴입니다. 반면 우리가 필요한 건 이미 존재하는 암호화 구현체 중 하나를 선택하는 것이었습니다.

매번 new로 객체를 생성하는 방식은 여러 측면에서 적합하지 않았습니다.

Spring 컨테이너 외부의 객체: new로 생성한 객체는 Spring 컨테이너가 관리하지 않습니다. 이 말은 @Autowired를 통한 의존성 주입, AOP 프록시, 트랜잭션 관리 등 Spring이 제공하는 이점을 전혀 활용할 수 없다는 의미입니다. 실제로 우리의 암호화 구현체들은 내부적으로 다른 Spring 빈(API 클라이언트, 설정 정보 등)에 의존하고 있었기에 이는 치명적인 단점이었습니다.

싱글톤 빈의 설계 철학과 불일치: Spring의 기본 빈 스코프는 싱글톤입니다. 애플리케이션 전체에서 하나의 인스턴스만 생성하여 재사용함으로써 메모리 효율성과 일관성을 보장합니다. 팩토리 패턴으로 매번 새 인스턴스를 생성하는 것은 이러한 Spring의 설계 철학에 역행하는 방식이었습니다.

결론적으로, 우리에게 필요한 것은 "객체를 생성"하는 것이 아니라 "이미 Spring 컨테이너가 관리하고 있는 싱글톤 빈 중 적절한 것을 선택"하는 것이었습니다. 이 요구사항에 가장 부합하는 패턴이 바로 전략 패턴이었습니다.

2.4. 결론: 전략 패턴 + AOP 조합

고민 끝에 내린 결론은 전략 패턴과 AOP의 조합이었습니다.

전략 패턴: 암호화 방식을 인터페이스로 추상화하고, 각 구현체를 독립적으로 관리합니다. 새로운 보안 솔루션이 추가되면 기존 코드 수정 없이 구현체만 추가하면 됩니다.

AOP: 개발자가 명시적으로 암호화 메서드를 호출할 필요 없이, 어노테이션 하나로 자동 적용됩니다. 호출 누락의 위험이 사라집니다.

방식 중복 제거 확장성 누락 방지 채택

if-else 분기 X X X -

서비스 클래스 분리 O X X -

팩토리 패턴 O △ X -

전략 패턴 + AOP O O O 채택

3. 기술적 설계: 전략 패턴을 통한 추상화

전략 패턴이 낯선 분들을 위해 설명드리자면, 전략 패턴은 '게임기'와 '게임 팩'의 관계로 비유할 수 있습니다. 게임기(비즈니스 로직)는 꽂는 팩(전략: 클라우드 보안 또는 에이전트 보안)의 종류에 따라 플레이할 게임(암호화 방식)이 달라지죠. 이와 유사하게 우리는 사용자가 누구냐에 따라 알맞은 전략을 자동으로 반영하는 시스템을 설계했습니다.

3.1. 전략 인터페이스와 구현체

먼저 FileProtectionStrategy라는 인터페이스(규격)를 정의하고, 각각의 보안 방식을 따르는 구현체(게임 팩)를 만들었습니다. 이렇게 하면 향후 또 다른 보안 솔루션이 추가되더라도 기존 코드를 수정할 필요 없이 새로운 구현체만 추가하면 됩니다.

public interface FileProtectionStrategy { /** 전략 식별자 (예: "CLOUD", "AGENT") */ String getType(); /** 파일 보호(암호화) 처리 */ byte[] protect(byte[] inputBytes, String fileName); /** 파일 보호 해제(복호화) 처리 */ byte[] unprotect(byte[] protectedBytes); }

각각의 구현체는 전략에 맞는 API 혹은 라이브러리를 호출하여 실제 암호화를 수행합니다.

/** * 전략 A: 신규 클라우드 보안 구현체 */ @Component public class CloudFileProtectionStrategy implements FileProtectionStrategy { @Override public String getType() { return "CLOUD"; } @Override public byte[] protect(byte[] inputBytes, String fileName) { // GW API를 호출하여 클라우드 방식 암호화 수행 return inputBytes; } // ... unprotect 구현 생략 } /** * 전략 B: 기존 에이전트 보안 구현체 */ @Component public class AgentFileProtectionStrategy implements FileProtectionStrategy { @Override public String getType() { return "AGENT"; } @Override public byte[] protect(byte[] inputBytes, String fileName) { // 기존 에이전트 방식 암호화 수행 return inputBytes; } // ... unprotect 구현 생략 }

3.2. 전략 선택기 (Resolver)

다음으로, 런타임 시점에 필요한 전략을 빠르게 찾을 수 있도록 Resolver를 구성했습니다.

여기서 주목할 점은 생성자에서 List<FileProtectionStrategy>를 주입받는 부분입니다. 이는 Spring의 다중 빈 자동 주입(Autowiring Collections) 기능을 활용한 것으로, 동일한 인터페이스를 구현한 모든 빈을 한 번에 주입받을 수 있습니다.

전략의 개수가 적을 때는 리스트를 순회해도 문제가 없지만, 호출 빈도가 매우 높은 보안 모듈 특성상 확장 시에도 성능 저하가 없는 구조를 목표로 했습니다. 따라서 주입받은 전략 리스트를 애플리케이션 시작 시점에 단 한 번만 Map으로 변환하여 캐싱해둠으로써, 런타임에는 별도의 조건문(if-else)이나 리스트 순회 없이 O(1) 시간 복잡도로 전략을 즉시 조회할 수 있도록 구현했습니다.

이 접근법의 장점은 새로운 전략 구현체를 추가할 때 Resolver 코드를 전혀 수정할 필요가 없다는 것입니다. @Component로 등록된 새 전략 빈은 애플리케이션 시작 시점에 Spring이 자동으로 감지하여 리스트에 포함시킵니다. 이는 OCP(개방-폐쇄 원칙)를 자연스럽게 만족하는 구조입니다.

참고문서: Spring 공식 문서 - Using @Autowired

@Component public class FileProtectionStrategyResolver { private final Map<String, FileProtectionStrategy> registry; // 생성자 주입 시점에 모든 전략 구현체를 Map으로 변환하여 캐싱 public FileProtectionStrategyResolver(List<FileProtectionStrategy> strategies) { this.registry = strategies.stream() .collect(Collectors.toMap(FileProtectionStrategy::getType, Function.identity())); } /** * 지정한 전략 식별자(Type)로 구현체를 O(1)로 조회 */ public FileProtectionStrategy resolve(String type) { FileProtectionStrategy strategy = registry.get(type); if (strategy == null) { throw new IllegalArgumentException("지원하지 않는 보안 타입입니다: " + type); } return strategy; } }

4. AOP를 활용한 자동 적용

마지막 퍼즐은 AOP(Aspect Oriented Programming)입니다.

앞서 전략 패턴을 게임과 게임 팩에 비유했다면, AOP는 공항 보안 검색대에 가깝습니다. 파일을 생성하는 모든 코드마다 resolve()를 호출하고 protect()를 실행하는 방식은 번거로울 뿐 아니라, 호출을 누락할 위험도 있습니다. 이런 반복적이고 빠뜨리기 쉬운 보안 처리를 AOP에 맡기면 훨씬 안정적으로 관리할 수 있습니다. 마치 승객이 비행기를 타기 전에 반드시 보안 검색대를 지나가야 하듯, AOP는 비즈니스 로직으로 진입하기 전에 데이터를 자동으로 검사하고 통과시키는 관문 역할을 합니다.

우리는 @ProtectFile이라는 커스텀 어노테이션만 붙이면, AOP가 자동으로 개입하여 보안 처리를 수행하도록 했습니다.

@Aspect public class ProtectFileAspect { private final FileProtectionStrategyResolver resolver; public ProtectFileAspect(FileProtectionStrategyResolver resolver) { this.resolver = resolver; } @Around("@annotation(protectFile)") public Object aroundProtect(ProceedingJoinPoint pjp, Object protectFile) throws Throwable { // 1. 비즈니스 로직 실행 (파일 생성/다운로드) // (예시를 위해 반환 타입이 byte[]라고 가정) byte[] raw = (byte[]) pjp.proceed(); // 2. 보안 전략 결정 // 실제 운영 코드에서는 사용자 세션 정보(SessionUser)를 기반으로 // "CLOUD" 또는 "AGENT" 타입을 동적으로 결정합니다. String securityType = getCurrentUserSecurityType(); // 3. 전략 조회 및 암호화 수행 FileProtectionStrategy strategy = resolver.resolve(securityType); // 4. 암호화된 결과 반환 // (전략 구현체 내부에서 처리) return strategy.protect(raw, "sample_report.pdf"); } // 사용자 권한에 따른 보안 타입 결정 로직 (예시) private String getCurrentUserSecurityType() { // 실제로는 SecurityContextHolder 등에서 사용자 권한을 확인합니다. // return userContext.isHeadquarters() ? "CLOUD" : "AGENT"; return "CLOUD"; // 데모를 위해 고정값 사용 } }

이제 비즈니스 로직 개발자는 파일 생성 코드에 집중하고, 아래처럼 @ProtectFile 어노테이션 하나만 붙여주면 됩니다.

@ProtectFile // 이 어노테이션 하나로 암호화 로직이 자동 적용됩니다. public byte[] downloadSalesReport() { // 순수 비즈니스 로직 (파일 생성) return reportService.createPdf(...); }

5. 삽질기: 실제 적용하면서 마주한 문제들

설계는 깔끔했지만, 실제 적용 과정은 순탄치 않았습니다. 여기서는 개발 중 마주했던 문제들과 해결 과정을 공유합니다.

5.1. 로컬 개발 환경에서 에이전트 솔루션이 동작하지 않는 문제

가장 먼저 부딪힌 벽은 로컬 개발 환경이었습니다.

클라우드 보안 API는 개발 환경에서도 문제없이 동작했지만, 기존 에이전트 기반 솔루션은 상황이 달랐습니다. 에이전트 솔루션은 네이티브 라이브러리에 의존하고 있었는데, 이 라이브러리가 macOS 아키텍처를 지원하지 않았습니다.

// 문제: macOS 로컬 환경에서 에이전트 솔루션 호출 시 agentSecurityLib.protect(data); // -> UnsatisfiedLinkError: 네이티브 라이브러리 로드 실패

대부분의 개발자가 macOS 환경에서 개발하고 있었기 때문에, 에이전트 방식 암호화를 테스트하려면 매번 개발 서버에 배포하거나 Docker 환경에서 실행해야 했습니다. 로컬에서 코드 수정 후 즉시 테스트하면 피드백 루프가 1~2분이면 충분하지만, 개발 서버 배포를 거치면 커밋 → CI/CD 파이프라인 → 서버 재시작까지 적지 않은 시간이 소요되어 개발 생산성이 크게 저하되는 문제가 있었습니다.

해결책: 로컬 환경용 Mock 전략 구현체

이 문제를 해결하기 위해 로컬 개발 환경에서만 활성화되는 Mock 전략을 추가하여, 로컬 환경에서는 Mock 전략이 에이전트 전략을 대체하도록 설정했습니다.

@Component @Profile("local") // 로컬 환경에서만 활성화 public class MockFileProtectionStrategy implements FileProtectionStrategy { @Override public String getType() { return "AGENT"; } // 에이전트 타입을 대체 @Override public byte[] protect(byte[] inputBytes, String fileName) { // 실제 암호화 없이 원본 그대로 반환 log.debug("[Mock] 에이전트 암호화 스킵: {}", fileName); return inputBytes; } }

이제 우리는 실제 암호화는 수행하지 않지만, 전략 패턴의 흐름은 그대로 테스트할 수 있게 되었습니다.

실제 암호화 동작 검증이 필요할 때만 개발 서버에 배포하면 되니, 암호화 에이전트를 사용할 수 없는 macOS 환경에서 코드와 흐름에 대한 불확실성을 제거할 수 있었습니다.

이는 인프라의 종속성에서 개발 환경을 완전히 독립시킨 의미 있는 리팩터링었습니다.

5.2. 기존 코드에 어노테이션 일괄 적용

마지막으로, 기존에 존재하는 수십 개의 다운로드 API에 @ProtectFile 어노테이션을 붙이는 작업이 남아있었습니다.

단순 작업이라 생각했지만, 막상 시작하니 까다로운 케이스들이 있었습니다.

파일이 아닌 JSON을 반환하는 API에 실수로 어노테이션을 붙이면?

이미 다른 방식으로 암호화가 적용된 레거시 코드는?

암호화가 필요 없는 공개 문서(약관 등)는?

해결책: API 목록화 + 꼼꼼한 QA 테스트

무작정 적용하기보다, 먼저 모든 파일 다운로드 API를 목록화하고 각각의 특성을 파악했습니다.

[파일 다운로드 API 체크리스트] ✅ /api/report/sales - 매출 리포트 (암호화 필요) ✅ /api/report/inventory - 재고 현황 (암호화 필요) ⬜ /api/template - 양식받기 (공개 문서, 암호화 불필요)

목록화 이후에는 QA 엔지니어분과 함께 꼼꼼한 테스트 과정을 거쳤습니다. 사용자 권한별로 파일을 다운로드하고, 암호화가 정상 적용되는지 하나하나 검증했습니다.

이 자리를 빌려 늦은 시간까지 수십 개의 API를 빠짐없이 테스트해주신 QA팀 여러분께 깊은 감사를 전합니다.🙇‍♀️

6. 마치며

이번 프로젝트는 전사적인 보안 체계 전환이라는 미션을 수행함과 동시에, 현장의 다양한 사용자 환경을 모두 고려해야 하는 과제였습니다.

전략 패턴과 AOP의 조합으로 본사 구성원에게는 최신 클라우드 보안 환경을, 매장 구성원에게는 익숙한 기존 환경을 제공하면서도 코드의 복잡도는 최소화할 수 있었습니다.

단순히 "돌아가는 코드"를 넘어, 변화에 유연하게 대처할 수 있는 "좋은 구조"를 고민했던 이번 경험이, 복잡한 레거시 환경과 새로운 요구사항 사이에서 고민하는 개발자분들에게 작은 힌트가 되기를 바랍니다.

한 기기에 개발·운영 앱을 동시에 설치하는 방법: 올리브영 DEV/PROD 환경 분리

Wed, 24 Dec 2025 18:00:00 GMT

안녕하세요. 올리브영의 앱 개발을 맡고 있는 Hz, 송편입니다.

이번 글에서는 개발용 앱(이하 ‘개발 앱’) 과 실제 운영용 앱(이하 ‘운영 앱’)을 완전히 분리해 관리하게 된 과정을 공유합니다. 특히 Android(Product Flavor)와 iOS(xcconfig)에서 환경을 코드 밖 설정으로 고정하고, CI/CD까지 연결해 운영 배포 리스크를 줄인 방법을 정리했습니다.

왜 환경을 분리해야 했는가

① 커뮤니케이션 비용을 줄이고 싶어요

프로덕트팀 🍊 오후 2:34

안녕하세요! 이번 업데이트 화면 확인하려고 하는데, 지금 제 폰에 깔려있는 앱이 개발용인가요 아니면 운영용인가요?

디자인팀 🐰 오후 3:15

새로운 이벤트 페이지 확인하고 싶은데 개발 서버로 바꾸려면 어떻게 해야 하나요? 앱을 삭제하고 다시 깔아야 하나요?

QA팀 🦫 오후 4:22

지금 운영앱으로 보고 있는데 개발중인 기능이 안보이네요. 혹시 제가 잘못 보고 있는 건가요?

아, 개발앱을 봐야 하는군요. 운영앱 지우고 개발앱 다시 설치할게요...

환경 분리 전, 반복되던 문의들

이런 상황은 왜 발생했을까요?

올리브영 앱은 개발용 앱과 운영용 앱이 같은 앱 식별자(설치 단위) 를 사용하고 있었습니다. (iOS는 Bundle Identifier, Android는 applicationId가 설치 단위를 구분합니다.)

모바일 OS의 샌드박스 정책상 식별자가 같으면 동일한 앱으로 구분하기 때문에, 한 기기에 두 가지 버전을 동시에 설치하는 것은 불가능했습니다. 이로 인해 환경을 전환하려면 반드시 기존 앱을 삭제하거나 덮어씌워야 했습니다. 이 과정에서 로그인 세션, 로컬 DB, 캐시 데이터가 초기화되다 보니, QA나 개발 과정에서 연속적인 테스트를 수행하는 데 큰 걸림돌이 되었습니다. 또한, 시각적으로 두 앱이 구분되지 않아 비개발 직군의 동료들은 지금 보고 있는 앱이 어떤 환경인지 몰라 혼란을 겪는 일도 빈번했습니다.

② 휴먼 에러를 방지하고 싶어요

개발 앱과 운영 앱이 같은 앱 식별자를 공유하면, 실수로 개발 앱을 스토어에 배포하는 사고가 발생할 수 있습니다. 특히 QA·개발·운영이 동시에 진행되는 바쁜 시기에는 사람이 수동으로 설정을 바꾸는 과정에서 실수로 테스트용 푸시 알림이 실제 고객에게 발송되거나, 운영 DB에 테스트용 데이터가 쌓이는 등의 문제가 발생할 수 있습니다.

이러한 이유로 많은 테크 기업들은 배포 파이프라인에서 환경 변수가 맞지 않으면 빌드 단계에서 실패하도록 가드레일을 둡니다. 또한 실리콘밸리의 여러 기업들은 dogfooding 문화의 일환으로, 내부 테스트 전용 빌드나 사내 배포용 앱을 운영하며 운영용 앱과 명확히 구분된 환경에서 검증을 진행합니다.

저희 역시 사람이 조심하는 것에는 한계가 있다고 판단했고, 이를 앱 레벨(xcconfig / Product Flavor)에서 강제함으로써 배포 담당자가 실수하고 싶어도 구조적으로 환경이 섞일 수 없는 상태를 목표로 환경 분리를 설계했습니다.

환경 분리 전략

그래서 올리브영 앱을 두 가지로 분리했습니다.

구분 운영 앱 개발 앱

대상 실제 고객 내부 구성원(QA·개발·기획·디자인·마케팅 등)

목적 검증이 완료된 기능을 스토어를 통해 안정적으로 제공 QA 검증, 개발 및 테스트 수행

서버 환경 운영 서버 고정 운영 / STG / QA 등 서버 전환 가능

특징 운영 키·설정 고정, 스토어 배포 기준에 따른 품질·안정성 검증, 불필요한 로그 제거 디버깅에 도움이 되는 개발자 모드 제공

이러한 분리를 위해 iOS와 Android는 각각의 플랫폼 특성이 있지만, 완전히 별도의 앱으로 구분하는 것을 원칙으로 개발환경 분리 작업을 진행했습니다.

Android 프로젝트에서 환경 분리하기

1. Build Variant로 환경 분리

Android는 Gradle의 빌드 구성 시스템인 Build Variant를 통해 다른 버전의 앱을 만들어낼 수 있습니다. 하나의 코드베이스에서 BuildType과 ProductFlavor를 조합하여 다양한 앱 버전을 만들 수 있게 해줍니다. 올리브영 프로젝트에서의 BuildType은 debug/release로, ProductFlavor는 production/develop으로 구성되어 있습니다. 앱 버전은 아래처럼 총 4가지입니다. 이 중에서 협업 동료들에게 배포되는 버전은 developRelease(개발 앱)와 productionRelease(운영 앱)입니다.

developDebug - 개발 환경 디버그

Android 개발자들이 로컬 환경에서 개발할 때 사용하는 앱

developRelease - 개발 환경 릴리즈

QA 기간 동안 협업 동료들이 설치하여 확인할 때 사용하는 앱

productionDebug - 운영 환경 디버그

운영 환경과 동일한 설정을 로컬에서 빠르게 확인할 때 사용하는 디버그용 앱(개발자용)

productionRelease - 운영 환경 릴리즈

협업 동료들이 설치하여 스토어 배포 전 확인할 때 사용하는 앱

스토어 배포용(운영) 빌드. 사내 배포 채널을 통해 검증 후 스토어에 게시

개발 앱과 운영 앱이 별도로 설치되게 하기 위해서는 추가적으로 해줘야 하는 작업이 있습니다. 각 앱에게 별도의 패키지명을 지정하는 일입니다. 개발과 운영을 구분하기 위해 기존 운영 패키지명 뒤에 dev를 추가적으로 붙여주었습니다.

운영(production)

applicationId : com.oliveyoung

개발(develop)

applicationId: com.oliveyoung.dev

패키지명이 달라지면 OS가 두 앱을 서로 다른 앱으로 인식하기 때문에, 한 기기에 개발 앱과 운영 앱을 동시에 설치할 수 있습니다.

// build.gradle flavorDimensions += "version" productFlavors { create("develop") { dimension = "version" applicationIdSuffix = ".dev" } create("production") { dimension = "version" } }

2. 운영과 개발 환경으로 소스셋 나누기

ProductFlavor를 통해 flavor를 나누어놓으면 지정한 이름 별로 소스셋을 관리할 수 있습니다. 아직 개발 중인 코드나 디버깅용으로 확인하기 위한 기능들은 개발(develop) 디렉토리에, 상용에 출시할 기능들은 운영(production) 디렉토리에 두어 환경별로 소스 분리를 했습니다. 예를 들어 앱 아이콘과 앱 이름을 각각 리소스에 분리하여 처리해주고 있습니다.

app/src/ ├── main/ # 공통 소스 ├── develop/ # 개발 환경 전용 │ ├── java/ │ ├── res/ │ │ ├── mipmap/ # 개발용 앱 아이콘 │ │ │ └── ic_launcher.png │ │ └── values/ │ │ └── strings.xml # 앱 이름: "올디브영" │ └── AndroidManifest.xml └── production/ # 운영 환경 전용 (production) ├── java/ ├── res/ │ ├── mipmap/ # 운영용 앱 아이콘 │ │ └── ic_launcher.xml │ └── values/ │ └── strings.xml # 앱 이름: "올리브영" └── AndroidManifest.xml

각 모듈들을 운영/개발 flavor로 나눈 결과의 프로젝트 구조는 아래와 같습니다.

올리브영 Android 앱 구조

iOS 프로젝트에서 환경 분리하기

iOS에서는 빌드 설정과 설정 파일(xcconfig, Info.plist)을 중심으로 환경을 분리했습니다.

용어를 간단히 정리하면 다음과 같습니다.

Scheme: “어떤 앱을 어떻게 빌드/실행할지”를 고르는 레시피

Build Configuration: DEV/PROD처럼 빌드 설정 묶음(값의 집합)

xcconfig: 위 설정값을 코드 밖 파일로 분리해 관리하는 설정 파일

1. Build Configuration과 Scheme로 환경 정의하기

기존에는 Debug / Release 두 가지 설정만 두고, 코드 안에서 #if DEBUG 전처리로 개발/운영 동작을 나누는 방식이 섞여 있었습니다. 이 구조에서는 어느 빌드가 어떤 키와 엔드포인트를 쓰는지 한눈에 파악하기 어려웠습니다. 환경을 명확히 나누기 위해 아래와 같이 빌드 설정과 Scheme을 재구성했습니다.

Build Configuration 예시

Debug-DEV Release-PROD

각 Configuration에 대응하는 Scheme 구성

OliveYoung-DEV OliveYoung-PROD

이렇게 해 두면 Xcode에서 Scheme만 바꿔도 "지금 이 빌드는 어느 환경용인지"를 바로 알 수 있고, CI에서도 동일한 Scheme 이름을 사용해 환경별 빌드를 자동화할 수 있습니다.

2. xcconfig로 환경별 설정 분리하기

다음 단계는 환경별 설정을 코드에서 빼서 xcconfig로 옮기는 작업이었습니다.

환경별 설정

Dev.xcconfig, Prod.xcconfig를 분리

각 파일에서만 달라지는 값들만 관리

(예: 서버 베이스 URL, 서드파티 ‘앱 등록 ID’, API 키 등)

예를 들어 아래와 같은 값들을 xcconfig에서 관리하도록 변경했습니다.

API 서버 주소: API_BASE_URL

서드파티 API Key

3. Bundle Identifier, App Group, 딥링크 설정까지 분리

환경을 완전히 분리하려면 UI만 다르게 보는 것만으로는 부족하고, 시스템 레벨 식별자들도 분리해야 합니다. iOS에서는 다음 항목들을 환경별로 각각 갖도록 정리했습니다.

Bundle Identifier

앱을 구분하기 위해 사용하는 고유 식별자

App Group / Keychain Group

Extension과 데이터를 공유할 때 환경이 섞이지 않도록 분리

Associated Domains (Universal Links)

운영/개발용 도메인을 나누고, 각 환경 앱에서 바라볼 수 있도록 설정

이렇게 정리하여, 식별자들도 서로 다른 환경별로 겹치지 않도록 설정했습니다. 각 패키지별로 설정파일을 바라보게 되며 분리되는 프로젝트 구조는 다음과 같습니다.

iOS에서의 Build Configuration 및 식별자(Identifier) 격리 구조

서드파티 SDK와 분석 도구 설정 통합

AppsFlyer, Firebase, Braze 같은 서드파티 SDK는 환경별로 다른 앱 ID나 프로젝트를 바라봐야 합니다.
환경 분리 이후에는 아래의 작업을 했습니다.

각 SDK에서 참조하는 앱 등록 ID / API Key를 전부 환경 설정 파일(xcconfig 등)로 이관

운영/개발용 앱 ID를 명확히 분리

작업 후에는 특정 빌드가 어떤 환경의 데이터 소스로 연결되는지가 설정 파일만 봐도 명확해졌고, 마케팅/데이터 팀과의 커뮤니케이션도 수월해졌습니다.

CI/CD 구축

마지막으로, GitHub Actions 기반 CI/CD에서 환경별로 다른 빌드를 생성하고 다른 채널로 배포하도록 워크플로우를 정리했습니다.

DEV 빌드

개발용 Scheme을 사용해 빌드

Firebase App Distribution 등 내부 테스트 채널로 배포

PROD 빌드

운영 Scheme으로 빌드

TestFlight 및 App Store용 아카이브 생성

추가로, 환경 혼선을 줄이기 위해 CI에서 다음 가드레일을 적용했습니다.

DEV 워크플로우는 DEV Scheme만 허용

PROD 워크플로우는 PROD Scheme만 허용

워크플로우 분리를 통해 환경 설정이 잘못된 상태로 운영 빌드가 스토어에 배포되는 리스크를 줄였습니다.
하지만 자동화만으로는 충분하지 않았습니다. 정말로 개발 환경과 운영 환경이 섞이지 않는지를 반복적으로 확인할 수 있는 기준이 필요했습니다.

환경이 섞이지 않도록 확인하는 기준

그래서 우리는 다음 기준으로 확인했습니다. 환경 분리는 “분리했다”에서 끝나지 않고, 정말로 섞이지 않는지를 반복 검증할 수 있어야 합니다.

설치 확인: 한 기기에 DEV/PROD 앱이 동시에 설치되는지(아이콘/앱명으로 즉시 구분)

엔드포인트 확인: 앱 실행 후 네트워크 로그에서 DEV 빌드가 DEV 서버(API_BASE_URL)를 바라보는지

서드파티 프로젝트 확인: AppsFlyer/Firebase/Braze에서 DEV 이벤트가 DEV 프로젝트로만 수집되는지

딥링크 확인: DEV/PROD 도메인이 각 앱으로 올바르게 라우팅되는지(Universal Links/App Links)

위 항목 중 하나라도 어긋나면, 설정 파일(xcconfig)과 식별자(Bundle Identifier/App Group/Associated Domains)를 우선 점검하도록 팀 내의 컨벤션을 정리했습니다.

마무리: 개발환경분리를 통해 얻은 구조적 안정성

시각적 인지 편의성을 극대화한 개발용(올디브영) 및 운영용(올리브영) 앱 아이콘/명칭 분리

개발 환경과 운영 환경을 완전히 분리한 후, 다음과 같은 긍정적인 변화를 경험했습니다.

협업 부서 간 커뮤니케이션 비용 감소

개발 앱과 운영 앱이 동시에 설치 가능해지면서, "지금 보고 있는 앱이 어떤 환경인가요?"라는 질문이 사라졌습니다.

앱 아이콘과 이름만으로도 환경을 구분할 수 있게 되어, 비개발부서와의 소통이 훨씬 명확해졌습니다.

배포 과정에서의 안정성 향상

CI/CD 파이프라인에서도 환경별로 명확히 분리된 워크플로우가 각각의 빌드를 처리하기 때문에, 배포 과정에서의 안정성이 크게 향상되었습니다.

개발 생산성 향상

개발자들은 더 이상 환경 전환을 위해 설정을 바꾸거나 앱을 재설치할 필요가 없어졌습니다.

두 앱을 동시에 띄워놓고 비교 테스트를 진행할 수 있게 되어, 디버깅과 검증 작업이 훨씬 수월해졌습니다.

안정적인 앱 운영

서드파티 SDK와 분석 도구들이 환경별로 명확히 분리되어, 개발 중인 기능이 운영 데이터에 영향을 주는 일이 없어졌습니다.

동료 A 👱‍♀️ 오후 12:25

올디브영 있어서 너무 좋아요🥰 스토어버전 앱과 개발중인 앱 따로 볼 수 있어서 너무 편합니다!!

동료 B 👨‍🍳 오후 2:28

올디브영 없을때 어떻게 개발 했나 싶네요. 상용앱 깔았다가 개발 앱 깔았다가… 이제 개발 앱을 따로 깔 수 있어서 헷갈리는 일이 없어요! 너무 좋습니다.

동료 C 👩‍🦱 오후 3:35

예전처럼 서버 설정 바꿀 필요 없이 앱만 전환하면 되니까 확인이 너무 수월합니다. 가이드도 꼼꼼해서 좋네요. 잘 쓰겠습니다!

동료 D 🧑‍🎨 오후 5:30

올디브영이 생겨서 개발, 상용 돌아가면서 설치하지 않아도 되서 너무 좋아요

올디브영(개발앱)에 대한 동료들의 긍정적인 피드백

환경 분리는 단순히 기술적인 개선이 아니라, 개발조직 전체의 협업 방식과 개발 문화를 개선하는 계기가 되었습니다.

기술적인 개선을 통해, 전체적인 커뮤니케이션 비용을 줄이고, 배포 안정성을 높일 수 있었습니다.

올리브영의 개발자들은 앞으로도 더 나은 개발 경험과 안정적인 서비스 제공을 위해 지속적으로 개선해 나갈 것입니다.

올리브영 네이티브 앱 개발 더 알아보기

DEV/PROD 환경 분리부터 앱 구조 개선, 생산성 도구까지— 아래 글들을 함께 보시면 올리브영 앱 개발자들이 실제로 어떤 문제를 풀고 있는지를 더 입체적으로 살펴볼 수 있습니다. ☺️

앱 구조·운영 안정성·성능 개선기

하이브리드 앱에 구축하는 iOS 개발자 모드: 운영 환경에서 안전하게 디버깅하기

SDUI로 네이티브 앱 운영 민첩성 높이기: 서버 주도 UI 도입 사례

올리브영 앱 스마트 스캐너 개선기: 사용자 경험과 성능을 함께 개선한 사례

개발 생산성·문서화

iOS 개발자를 위한 DocC 실무 튜토리얼: 문서로 협업 품질 높이기

Swift 매크로 1탄: Swift 매크로란 무엇이고 왜 필요한가

Swift 매크로 2탄: 실무에서 Swift 매크로 활용하기

개발자 행사·커뮤니티

Let’s Swift 2024 × 올리브영: 기술과 경험을 나눈 개발자 행사 후기

운영 비용을 95% 절감한 서버리스 온콜 시스템 구축기

Wed, 24 Dec 2025 15:00:00 GMT

안녕하세요. 고기를 좋아하는 올리브영 SRE 태극기입니다!
올리브영은 기존에 사용하던 외부 솔루션 기반 온콜 시스템의 한계를 해결하기 위해, 2025년 7월 Amazon SES + Amazon Connect 기반의 서버리스 온콜 시스템으로 전환했습니다.
이 글에서는 그 과정에서의 설계 의도, 시행착오, 그리고 최종적으로 얻어진 안정성과 결과를 공유합니다.

1. 온콜(On-call)은 무엇이며 왜 중요한가

온콜은 장애가 발생했을 때 담당자에게 즉시 연락해 문제가 더 커지기 전에 빠르게 조치할 수 있도록 하는 비상 호출 체계입니다.
특히 대규모 트래픽을 처리하는 플랫폼이나 이벤트 발생 시에는 1분의 지연이 수만 명의 고객 경험에 영향을 주기 때문에, 이 비상 호출의 무게감이 남다릅니다. 이에 장애 발생 시 온콜이 정상적으로 작동해야만 비로소 다음과 같은 가치들을 지켜낼 수 있습니다.

장애 조기 감지: 시스템 모니터링이 포착한 신호를 엔지니어의 인지로 즉각 연결합니다.

SLA 준수 및 고객 영향 최소화: 대응 골든타임을 확보하여 서비스 가용성을 유지합니다.

장애 확산 억제: 초기 대응을 통해 국지적 결함이 전체 시스템 마비로 번지는 것을 막습니다.

온콜이 울리지 않는 순간, SRE의 어떤 대응 프로세스도 시작할 수 없습니다. 따라서, 온콜의 신뢰성 자체가 서비스 안정성의 가장 중요한 요소입니다.

2. 기존 온콜 솔루션의 구조적 한계

올리브영은 그동안 외부 온콜 솔루션을 이용해 장애 알림을 운영했습니다. 하지만 다음과 같은 한계가 존재했습니다.

해외 번호 발신

온콜 발신 번호가 해외번호로 표시되면서, 국내 통신사 스팸정책에 의해 전화가 차단되는 사례가 반복되었습니다.
개발자가 직접 통신사 고객센터에 연락해 국제전화 수신을 요청해야 하는 불편함도 있었습니다.

국제전화 수신거부 서비스로 온콜 수신 실패 사례

발신 실패 발생

외부 솔루션 이슈로 간헐적으로 발신 실패하는 사례가 발생했습니다.

높은 고정 비용

발신 실패 여부와 관계없이 월 약 200만 원 이상의 솔루션 사용료가 고정적으로 청구되었습니다. 사용량 대비 비용 효율이 떨어지는 구조였습니다.

기존 외부 온콜 솔루션이 가진 제약을 해결하기 위해, '어떻게 하면 더 단순하면서도 확실하게 전화가 울리게 만들 수 있을까?'라는 관점에서 전체 구조를 다시 검토했습니다.
Amazon Connect는 주로 AICC(AI Contact Center, 인공지능 컨택센터) 구축에 활용되는 서비스입니다. 아메리칸 항공에서 고객센터를 Amazon Connect로 전환한 사례처럼, API 기반의 발신 제어와 안정적인 통화 품질을 강점으로 하는 서비스이기도 합니다. 올리브영에서는 이 서비스를 ‘장애 대응 온콜 시스템’이라는 특수한 목적에 맞게 재해석해 적용했습니다. 콜센터 서비스 특유의 안정적인 발신 품질, 고가용성, TTS 연동 능력이 온콜 발신 시스템으로 활용하기에 매우 적합했기 때문입니다.
이제 필요한 것은 '이 발신 엔진을 어떤 방식으로 트리거할 것인가'였습니다. 다양한 장애 알림을 하나의 입력으로 통합하려면 표준화된 단일 채널이 필요했습니다. 이 기준에서 검토한 결과, 가장 신뢰성이 높고 구현이 단순한 방식이 바로 '이메일을 온콜 트리거로 사용하는 구조'였습니다.

3. 온콜 트리거를 이메일로 통합

새로운 온콜 시스템 설계의 핵심 원칙은 가능한 빠르고 확실하게 전화를 울리게 하는 것이었습니다.
이를 위해 이메일(Amazon SES)을 온콜 트리거로 선택했습니다.

Slack, Datadog 등 올리브영이 사용하는 대부분의 모니터링 도구는 '이메일 발신'을 기본 인터페이스로 지원합니다. 따라서 별도의 복잡한 API 연동 없이도 이메일이라는 표준화된 통로를 통해 모든 장애 신호를 하나로 통합할 수 있었습니다.

실제 운영을 통해 확인한 이메일 기반 구조의 강점은 다음과 같습니다.

단일 파이프라인: 모든 장애 트리거가 이메일이라는 하나의 채널로 수렴되어 관리가 용이함

구조적 단순함: 아키텍처가 직관적이라 유지보수가 쉽고 장애 포인트가 적음

검증된 신뢰성: 운영 이후 트리거 누락 없이 안정적으로 동작 중

4. 이메일 기반 아키텍처 설계

이메일을 트리거로 삼기로 결정한 후, 이 신호를 단 한 번의 유실도 없이 Amazon Connect까지 전달할 파이프라인을 설계했습니다. 이 설계의 핵심은 '유연성'과 '안정성'입니다.

핵심 설계 포인트

표준화된 통합: Slack 인시던트나 Datadog Alert 등 파편화된 장애 신호를 이메일이라는 공통 표준 인터페이스로 수렴하여 연동 복잡도를 제거

관리의 유연성: Google Groups를 브릿지로 활용해, 인프라 코드(IaC) 수정 없이도 팀·스쿼드 단위의 온콜 그룹을 유연하게 운영

안정적인 메시지 릴레이: SES(수신) → SNS(팬아웃) → SQS(버퍼링) 구조를 채택하여, 대량 메일이 쏟아지는 상황에서도 메시지 유실을 방지하고 발신 속도를 제어할 수 있는 기반을 마련

이메일에서 온콜 발신까지의 데이터 여정

1. 트리거 발송: 모니터링 도구가 미리 정의된 온콜 전용 이메일 주소로 장애 알림을 발송 2. 신호 수집(SES): Amazon SES가 이메일을 수신하면, Receipt Rule을 통해 메일 원문을 SNS를 거쳐 SQS에 적재 3. 데이터 파싱(Lambda): 온콜 발신 Lambda가 SQS에서 메시지를 꺼내 수신 대상자(전화번호)와 안내 음성(TTS) 내용을 정교하게 파싱 4. 최종 발신(Amazon Connect): 파싱된 정보를 바탕으로 Amazon Connect API를 호출. 이때 Lambda는 SQS 메시지를 초당 4건의 속도로 소비하여 발신량(Rate Limit)을 제어

즉, 온콜 프로세스는 이메일(Amazon SES) 수신을 출발점으로 삼아, 이후 모든 단계가 서버리스 기반으로 자동 처리됩니다.

이렇게 아키텍처가 정리되면 다음 과제는 '누구에게 전화를 발신해야 하는가'를 정확하게 식별하는 일입니다.
온콜 수신 대상자는 조직 개편, 담당자 변경 등 다양한 이유로 변경이 잦을 수 있기 때문에, 구조적으로 단순하면서도 변경이 쉬운 방식이 필요했습니다. 이에 전화번호를 DB에 저장하고 관리하는 일반적인 방식 대신, '기존 조직 관리 체계(Google Groups)를 그대로 활용하면서도, 별도 DB 없이 동적으로 발신 대상을 식별할 수 없을까?'를 고민했습니다.
그 해답은 Google Groups와 RFC 5233 표준인 '플러스 어드레싱'의 조합에 있었습니다.

5. Google Groups 기반 온콜 대상자 관리

Google Groups를 활용하면 온콜 그룹을 이메일 주소 하나로 관리할 수 있고, 담당자 변경 시 온콜 시스템을 수정하지 않아도 됩니다.

예시는 다음과 같습니다.

sre-oncall@oliveyoung.co.kr security-oncall@oliveyoung.co.kr payment-oncall@oliveyoung.co.kr

시스템의 작동 원리는 간단합니다. 장애 트리거 메일이 Google Groups로 발송되면, 해당 메일은 등록된 멤버들의 온콜 전용 주소로 즉시 전달됩니다.

이때 Amazon SES는 유입되는 메일을 Receipt Rule에 의해 SNS를 거쳐 SQS로 전달합니다. 이후 파이프라인의 핵심인 온콜 발신 Lambda가 동작하며, SQS 메시지에서 다음 두 가지 핵심 데이터를 추출합니다.

수신 주소: 누가 전화를 받을 것인가? (플러스 어드레싱 기반 식별)

이메일 제목: 어떤 내용으로 전화를 걸 것인가? (TTS 음성 변환)

즉, 이메일에 '누구에게, 무엇을' 전달할지에 대한 정보가 모두 담겨 있어, 별도의 DB 조회 없이도 즉각적인 온콜 발신이 가능해집니다.

플러스 어드레싱 기반 대상자 식별 — RFC 5233 Subaddressing 활용

온콜 대상자 식별을 위해 이메일 주소에 플러스 어드레싱(+ Addressing) 방식을 적용했습니다.
이는 RFC 5233에서 정의된 공식 표준(Subaddressing)으로, 이메일 로컬 파트(local-part)에 + 식별자를 추가하는 방식입니다.

실제로 Gmail 등 대부분의 메일 시스템은 'ID+식별자@domain.com' 형태에서 '+' 뒤의 문자열을 무시하고 원래의 'ID 주소'로 메일을 전달합니다. 하지만 이메일 원문에는 이 플러스 어드레스가 그대로 남아있다는 점에 주목했습니다. Amazon SES가 수신한 메일 원문을 SQS로 넘겨주면, Lambda는 복잡한 DB 조회 대신 아주 단순한 정규식만으로 '누구에게 전화를 걸지' 판단합니다.

[데이터 파싱 예시]

- 수신 주소: call+821012345678@oliveyoung.co.kr → 추출 번호: 821012345678 - 메일 제목: [장애] ALB 응답시간 지연 발생 → TTS 내용: ALB 응답시간 지연 발생

이 방식의 장점은 다음과 같습니다.

무상태성(Stateless) 유지: 시스템이 전화번호 데이터를 들고 있을 필요가 없어 DB 관리 공수가 0에 수렴

즉각적인 확장: 새로운 담당자가 추가되어도 Google Groups에 플러스 어드레싱이 적용된 메일 주소만 등록하면 즉시 온콜 대상에 포함

6. 실제 운영 중 겪은 문제 — 야간 스팸메일로 인한 오발신

완벽하다고 믿었던 시스템도 실제 프로덕션의 변수 앞에서는 예외가 발생했습니다.
내부 테스트 기간 중, 모두가 깊이 잠든 자정 즈음에 느닷없이 온콜 전화가 울렸습니다.

스팸 온콜로 잠에서 깬 직후 슬랙 대화

원인은 황당하게도 '광고성 스팸 메일'이었습니다. 수신된 이메일을 모두 온콜로 처리하는 트리거의 치명적인 허점이었습니다. 온콜 전용 주소가 외부로 노출되지 않았더라도, 무작위로 발송되는 스팸 메일은 온콜 트리거를 작동시켰고, Lambda는 스팸메일 제목을 정성스럽게 TTS로 읽어주면서 담당자를 깨웠던 것입니다.

이 사건 이후, 지정한 도메인에서 발신한 이메일만 온콜 트리거로 허용하는 필터링 규칙을 Lambda에 적용하여 문제를 해결했습니다.

최종 해결책: 이메일 화이트리스트(Allow-List) 도입

보완 전: 수신된 모든 메일을 온콜 처리

보완 후: 이메일의 발신도메인을 체크하여, 허가된 시스템(Datadog, Slack, 올리브영 사내메일)에서 보낸 메일만 온콜 처리

전사 적용 후에 이런 일이 발생했다면, 새벽에 모든 개발자를 온콜로 깨우는 상황이 될 뻔 했습니다. 전사 확산 전, 내부 테스트 기간에 이렇게 매운맛 경험을 한 것이 오히려 천운이었습니다. 덕분에 현재는 단 한 건의 오발신 없는 철벽 방어 시스템을 유지하고 있습니다. ~~(어? 사내메일로 예약메일을 보내면 모닝콜 대신 쓸 수 있는 건 비밀입니다.)~~

이메일 기반 온콜 흐름에서 발생할 수 있는 문제들을 해결한 이후, 실제 대규모 발신 테스트를 통해 Amazon Connect의 제약 사항도 확인할 수 있었습니다.

7. Amazon Connect 도입 직후 발견된 Rate Limit 제약

숨겨진 제약: Amazon Connect의 동시 발신 제한

위와 같이 이메일 기반 온콜 흐름에서 발생할 수 있는 문제들을 해결한 이후, 실제 대규모 발신 테스트를 통해 Amazon Connect의 제약 사항도 확인할 수 있었습니다. 온콜 테스트를 위해 약 50여 명에게 동시에 발신을 시도하자, 예상치 못한 상황이 발생한 것인데요, 일부 인원에게 전화가 가지 않는 '발신 누락'이 확인되었습니다. 원인은 Amazon Connect의 초당 호출 제한(Rate Limit)이었습니다. 확인해보니 StartOutboundVoiceContact API를 짧은 시간에 집중적으로 호출할 경우, Quota 초과로 호출이 거절된 것이었습니다. 수십 명에게 즉시 전화를 걸어야 하는 온콜 시스템에는 턱없이 부족한 수치였습니다.

해결 과정: Quota 증설과 안정성 확보

올리브영 담당 AWS TAM(Technical Account Manager)에 서비스 할당량 증설을 요청했고, 약 2주간의 검토를 거쳐 초당 5회까지 발신 가능하도록 증설을 마쳤습니다. 하지만 여기서 그치지 않았습니다. 인프라의 한계치까지 사용하는 것은 위험하다고 판단하여, 실제 운영 시에는 안전 마진을 둔 초당 4회로 발신 속도를 제어하기로 결정했습니다.

8. SQS 기반 발신 속도 제어 구조로 문제 해결

발신 속도를 안정적으로 제어하기 위해 SQS를 도입하여 아키텍처를 재설계했습니다.

개선된 아키텍처

SQS 지연 처리: 대량의 메일이 쏟아지더라도 SQS가 이를 안전하게 보관하며 버퍼 역할을 수행합니다.

Lambda 동시성 제어: Lambda의 Reserved concurrency 값을 4로 설정하여, Amazon Connect API 호출이 초당 4건을 넘지 않도록 정교하게 제어했습니다.

관측성 확보: 모든 발신 성공/실패 로그를 Datadog으로 전송하여, 실제 전화가 몇 초 만에 도달했는지 대시보드에서 실시간으로 확인할 수 있게 구성했습니다.

Amazon Connect 기반 온콜 발신 테스트 후기

테스트 결과: 46명에게 17초 만에 도달

재설계된 구조로 대규모 발신 테스트를 진행한 결과, 단 한 건의 누락도 발생하지 않았습니다.

성능: 46명 전원 발신 완료까지 약 17초 소요 (초당 4건 목표치 준수)

안정성: API Throttling 에러 발생률 0%

온콜 품질 개선 이후 개발팀 실제 후기

9. 전화 + SMS 이중화

온콜이 안정적으로 작동하자, 실제 온콜을 받는 개발팀으로부터 실무적인 피드백이 도착했습니다.

“회의 중이거나 이동 중이라 전화를 놓치는 경우가 있어요. 전화를 못 받더라도 어떤 이슈인지 SMS로 바로 확인할 수 있으면 좋겠습니다!”

이에 Amazon SNS를 활용한 SMS 발신 기능을 추가하여 알림 이중화를 구현했습니다.

알림 레이어의 확장

기존 Lambda에 Amazon SNS 연동을 추가하여, 단일 트리거로 두 가지 경로의 알림이 동시에 발생하도록 개선했습니다.

1단계 Voice: Amazon Connect를 통해 긴급 상황임을 알리는 전화 발신 (즉각적 대응 유도)

2단계 Text: 동일한 TTS 안내 내용을 SMS로 즉시 전송 (기록성 및 가독성 확보)

이제 담당자가 전화를 받지 못하더라도, 뒤이어 도착한 SMS를 통해 장애의 맥락을 즉시 파악하고 조치에 들어갈 수 있게 되었습니다.
'전화'가 대응의 시작을 알린다면, 'SMS'는 대응의 정확도를 높이는 역할을 수행하게 된 것입니다.

10. 고정 비용 최적화

기존 외부 솔루션은 발신 건수와 관계없이 고정비용으로 월 200만 원 이상을 지출하고 있었습니다.
하지만 Amazon SES + Amazon Connect 기반 서버리스 구조로, 전환하며 운영 비용을 월 10만원 이하(약 95% 이상 절감)로 조정할 수 있었습니다.

구분 기존 외부 온콜 솔루션 Olive Connect (신규 서비스) 비고

과금 방식 구독형 고정 비용 사용량 기반 과금 -

월 예상 비용 약 2,000,000원 + α 약 100,000원 미만 약 95% 절감

주요 과금 항목 유저당 라이선스, 플랫폼 사용료 Amazon Connect 발신 비용, Lambda 호출 비용 등 -

발신 안정성 해외 번호 발신 (스팸 차단 위험) 국내 번호 발신 및 서버리스로 안정성 높음 안정성 향상

11. 최종 온콜 아키텍처

아래는 현재 운영 중인 온콜 시스템 구성도입니다.

Google Groups와 Amazon SES, Amazon Connect를 활용한 Olive Connect 전체 구성도

12. 사내 전파와 안착 — 개발자 포털(IDP)을 통한 운영 가이드 제공

온콜 시스템이 안정적으로 운영되기 시작하면서, 다음 과제는 '이 시스템을 어떻게 조직 전체에 안전하게 확산시키고, 오래 유지할 것인가'였습니다. 아무리 잘 만든 시스템이라도 사용 방법이 명확하지 않거나, 담당자 변경 시 지식이 단절되는 구조라면 문제가 됩니다. 시간이 지나면 결국 또 다른 운영 리스크로 되돌아오기 마련입니다.

이를 방지하기 위해, 온콜 시스템의 설계 배경, 사용 방법을 정리한 가이드 문서를 작성했고, 이를 사내 IDP(Internal Developer Portal)에 배포했습니다.

가이드에는 다음과 같은 내용을 포함했습니다.

온콜 시스템 전체 아키텍처 개요

신규 서비스 온콜 연동 방법 (이메일 트리거 설정 가이드)

Google Groups 기반 온콜 그룹 관리 방법

이제 새로운 서비스에 온콜을 도입할 때, 별도의 설명이나 인프라 지원 없이도 가이드 문서만으로 셀프 적용이 가능한 구조가 되었습니다. 기술적인 완성도뿐 아니라, 운영과 전파까지 고려한 문서화는 이 온콜 시스템을 '특정 팀의 도구'가 아닌 조직의 공통 인프라 자산으로 만드는 데 중요한 역할을 했습니다.

마무리

현재 Amazon Connect는 Amazon Polly TTS 서비스로 장애 정보를 온콜로 전달하고 있습니다. 하지만 긴박한 장애 상황에서 기계적인 한국어 발음은 때때로 정보 전달력을 떨어뜨리기도 합니다.
이에 다음 단계로 음성 사용자 경험(VUX)을 고도화할 계획입니다. 네이버 클로바 더빙이나 Typecast 같은 외부 AI TTS 솔루션을 연동하여, 마치 동료가 직접 전화를 걸어 상황을 설명해 주는 듯한 자연스러운 음성 안내를 구현하고자 합니다. 단순히 '듣기 좋은 목소리'를 넘어, 장애 대응 중인 엔지니어의 인지 부하를 줄이고, 상황 파악 속도를 높이는 데 기여할 것입니다.

그리고, 이메일 기반 온콜이라는 단순한 접근 방식은 예상보다 훨씬 강력했습니다.

신뢰성: 복잡한 연동 없이 이메일 표준을 활용해 발신 실패율 0% 달성

완결성: 전화와 SMS 이중화를 통한 장애 전파 누락 방지

유연성: 별도 DB 없이 Google Groups만으로 온콜 그룹 관리 자동화

효율성: 운영 리소스와 비용(95% 절감)의 획기적 최적화

무엇보다, 가장 단순한 구조가 가장 안정적인 구조가 될 수 있다는 경험을 얻었습니다.

온콜은 단순한 전화 발신 기능을 넘어, 장애 상황과 엔지니어의 대응 사이의 간극을 메우는 '서비스 신뢰성의 마지막 1cm'입니다. 이 짧은 간극을 어떻게 채우느냐에 따라 고객이 경험하는 서비스의 안정성이 결정됩니다.
올리브영 SRE팀은 앞으로도 복잡하게 얽힌 문제들을 가장 명쾌하고 단순한 기술로 풀어내며, 고객이 믿고 머무를 수 있는 탄탄한 플랫폼을 만들어 나갈 것입니다. '단순함으로 구현한 견고한 신뢰'에 대한 저희의 또 다른 도전과 해결 사례들도 계속해서 기대해 주세요.

QA Built on Trust - 팀워크가 품질을 만든다

Wed, 17 Dec 2025 16:00:00 GMT

안녕하세요. 주문결제, 클레임, 고객센터 스쿼드의 QA 엔지니어 유갱입니다!
2025년의 끝자락, 저희 QA 조직은 한 해를 마무리하며 올리브영의 품질을 지켜냈던 치열했던 시간들을 반추해보고 있습니다. 그 중 가장 뜨거운 에너지와 팀워크를 발휘했던 순간은 바로 7월 5일에 참여했던 2025 QA Korea Conference 였습니다. 이 글에서는 올리브영 QA 조직이 복잡한 옴니채널 환경에서 어떤 비전을 가지고 외부와 소통했는지, 그리고 팀워크가 어떻게 품질의 기반이 되었는지를 회고록 형식으로 공유하려 합니다.

QA Korea Conference는 국내 QA 직무 또는 소프트웨어 품질 관련 분야에 종사하는 실무자들이 모이는 큰 규모의 컨퍼런스입니다. 주로 각자의 업무 프로세스와 전략을 공유하며 함께 성장을 도모하고 있는데요! 2022년을 시작으로 다양한 업계의 QA 전문가들이 서로를 알아가며 네트워크를 넓혀 왔습니다. 그동안 COVID-19 등의 이유로 온라인으로만 이어오던 행사를 올해 최초! 오프라인으로 진행한다는 소식을 듣고, 올리브영은 국내 SW 품질 생태계 확장에 기여하고자 공식 후원사로 참여를 결정했습니다. 저희 QA팀은 이 뜻깊은 자리를 주도적으로 준비하며, 외부와 소통하는 소중한 기회로 삼았습니다.

🍭 2025 QA Korea Conference, 우리가 왜 거기 있었냐면요.

드디어 오프라인으로 문을 열게 된 QA Korea Conference!
2025년의 QA Conference는 ‘국내 SW 품질 엔지니어링 생태계 확장’을 모토로 약 500여 명의 업계 전문가가 한 자리에 모인 행사였습니다. 첫 오프라인 개최였던 만큼, QA 종사자들이 직접 경험을 공유하며 교류할 수 있었고 현장은 그야말로 뜨거운 열기로 가득했습니다. 그동안 화면에서만 보던 발표자와 참가자들이 한 공간에 모였고 발표 세션과 부스, 네트워킹 공간까지 모든 것이 알차게 준비되어 있었습니다.

공식 후원사로서 올리브영 QA팀은 이 순간을 놓칠 수 없었습니다. 회사의 지원을 통해 팀장님 포함 팀원 다섯 명이 직접 부스를 기획/운영하고 연사로 참여하며 올리브영의 품질 문화를 전파하기 위해 현장에 나섰습니다.

☀️ 우리 팀의 참여 목적은 단순하고 명확했습니다️.

1. 올리브영 QA팀은 어떤 일을 하고 있는가?
2. 우리 팀은 어떤 목표를 지향하고, 어떻게 나아가고 있는가?
3. 우리 팀의 존재감과 팀워크를 보여주며 향후 인재 확보 가능성과 올리브영 서비스의 홍보 효과 높이기

이 세 가지를 진솔하게 전하고, 나아가 저희 팀에 관심이 있거나 미래의 지원자가 될 지도 모르는 분들과 더 가깝게 소통하기 위해서였어요!

2025 QA 코리아 컨퍼런스 현장

오전 9시부터 시작된 행사는 약 500여 명의 참여자와 14명의 연사자가 함께하며 더 뜨거운 열기를 더했습니다.

- 방문객 수 : 약 500명 (QA 리더십부터 주니어 실무자까지, 폭넓은 경력층 참여) - 연사자 수 : Open Talk 포함 14명 - 스폰서 수 : 올리브영 포함 14곳

🍭 이 부스, 그냥 지나칠 수 없게 만들었습니다.

| 🐾 방문자_발목_부여잡은_우리_부스의_매력.zip

저희는 올리브영 QA팀의 색깔을 그대로 담은 공간으로 부스를 꾸몄습니다. 눈에 띄면서도 방문객들의 참여도를 높이고, 올리브영에 대한 잔상이 오래도록 남게 하기 위한 의도였어요! 부스 앞 판넬에는 참여를 유도하면서도 오늘드림 문구를 넣어 올리브영 서비스의 홍보 효과까지 높였답니다.

우리 부스, 올리브영의 색깔을 참 잘 담아내지 않았나요?

이 때문이었을까요? 올리브영 QA팀의 부스는 방문객들의 참여가 끊이지 않았습니다. 우리도 그 기대에 부응하고자 최선을 다했습니다. 특히 팀의 업무와 올리브영 서비스를 전파하기 위해 온몸을 불사르고 왔답니다.

문전성시를 이뤘던 우리 부스의 모습

QA Misson : QA 직무와 직결된, 그런데 이제 지루하지 않은 !

부스 프로그램은 세 가지의 간단한 미션으로 진행했어요. 미션 카드를 들고 게임에 참여하여 두 개 이상의 PASS 스탬프를 받으면 미션 성공! 마지막에는 자유롭게 뽑기 게임을 한 후 당첨된 상품을 수령하면 됩니다. 카드 뒷면에는 우리 팀의 업무 방식을 소개하며 팀의 홍보 효과를 높였어요!

업무에 대한 간접적인 설명과 참여자들의 흥미를 동시에 잡았던 세 가지 게임을 간단하게 소개할게요.

프로그램 소개 브로셔와 QA 미션카드

1. 초간단 OX 퀴즈

OX 퀴즈는 간단하지만 올리브영 QA팀 업무의 핵심 내용을 담아 구성했습니다! 특히 저희 올리브영 테크 블로그의 QA 포스트나 외부 발표 세션 참여 경험이 있으셨던 독자분들이 '오, 이거 아는 내용이다!'라고 반가워하며 정답을 척척 맞히는 모습에 보람을 느꼈습니다. 이는 컨퍼런스 현장을 넘어, 우리가 온라인으로 공유했던 기술적 메시지와 노하우가 실제 커뮤니티와 QA 생태계에 잘 전달되고 있음을 확인하는 소중한 경험이었습니다.

QA 검증 범위에 대한 OX 퀴즈! 정답이 뭘까요?

2. QA Defect Challenge 버그 헌터즈 - 바이브 코딩으로 다듬고 다듬은 UX

'버그 헌터즈' 게임은 QA팀원들이 이번 행사를 위해 직접 기획하고 구현한 웹 기반 미니 게임입니다. 특히 Netlify를 활용해 빠르게 배포함으로써 현장에서 방문객들에게 직접 체험 기회를 제공했습니다. 팀원들이 바이브 코딩을 통해 즐겁게 만들었으며, 올리브영 QA팀이 단순 테스트를 넘어 직접 코드를 구현하고 배포할 수 있는 역량을 갖췄음을 보여주고자 했습니다.

🕹️ 버그 헌터즈 게임을 직접 체험해 보세요! : QA Defect Challenge 버그 헌터즈 체험하기

본 게임을 개발하는 과정에서 가장 집중했던 부분은 코드를 논리적으로 우선 작성한 뒤, 사용자가 체감하기에 자연스럽고 편안한 타이밍을 맞추는 과정이었습니다. 그리고 단순히 기능 구현을 넘어 사용자 경험을 극대화하기 위해 애니메이션과 깨알 같은 효과음의 타이밍까지 QA 관점에서 섬세하게 다듬었습니다.
사용자에게 직관적이며 불편한 점이 없어야 한다는 원칙(feat. QA Engineer 직업병)이 반영된 게임인 만큼 실제 현장에서의 반응도 좋았답니다!

진행하는 입장에서도 재미있었던 버그헌터즈

게임은 올리브영 QA 업무와 직접적으로 관련된 질문과 답변으로 구성했습니다. 정답을 바로 맞히기 보다는 한 번 더 생각할 수 있도록 유도했어요! 참여율을 높이고 긍정적인 경험을 제공하기 위해 틀렸더라도 재도전의 기회가 있었다는 건 비밀이에요😉

3. 카드 선택 게임

카드 선택 게임은 본인이 풀 문제 카드를 직접 골라 답을 맞히는 게임이었어요. 서로 다른 종류의 문제 카드 중 하나를 고르면, 그 문제에 맞는 답안지 세 장이 오픈되는 3지 선다형의 방식이었답니다.

정답을 빨리 선택해야 해요. 3,2,1..!

답안지가 공개된 후 빠르게 답을 골라야하는 방식에 다들 긴장해서였을까요? 약간의 위트를 더해 힌트를 드렸지만, 생각보다 오답이 많아서 더 긴장감 넘치고 재미있었습니다.

🍭 발 디딜 틈 없고 활력이 넘쳤던 발표 세션

let energy = crowd.getEnergy(); while (energy < Infinity) { energy++; } console.warn("⚠️ EnergyOverflow: 현장의 열기가 메모리 한도를 초과했습니다!!");

올리브영 QA팀에서는 두 가지 발표를 준비했는데요! 첫 번째 발표의 주제는 올리브영이 옴니 서비스로서 갖고 있는 특성 및 구조와 그 안에서 이뤄지는 QA의 업무에 대한 설명이었습니다.

1. 복잡한 옴니채널의 소프트웨어 품질을 높이기 위한 QA Engineer의 역할(feat. QA 팀장님)

저희 팀의 첫 번째 발표에서는 복잡하게 얽힌 옴니 서비스의 기술 및 구조와 함께 올리브영의 QA 업무 중 당면하게 되는 과제들을 소개했습니다. 특히 올리브영 QA팀의 기술 베이스와 전략에 대한 설명은 현재 실무자인 저희 팀원들에게도 다시금 되뇌게 하는 내용이었습니다.
당장 눈 앞에 놓인 업무를 단기적인 목표로 수행하지 않고 우리가 궁극적으로 나아가야하는 방향에 대해서도 상기시킬 수 있었습니다.

[발표 자료] 옴니채널 환경에 대한 소개와 QA 전략 슬라이드

2. 다양한 스쿼드 조직에서의 QA 협업을 말하다 – 실무자의 진짜 이야기

여러 기업들의 멋진 발표 후, 저희 팀의 두 번째 발표는 마지막 순서였습니다. 바로 옴니채널의 협업에 대해서도 공유하는 실무자의 인사이트 토크 시간도 있었는데요. 여기서 저희 팀에 대한 소개와 올리브영에서 일하는 방식을 간접적으로 체험할 수 있도록 자세한 설명을 준비했습니다.

[발표 현장] (좌) 올리브영의 옴니채널 QA 전략 발표 / (우) 올리브영의 스쿼드 협업에 관한 인사이트 토크

마지막 순서였지만, 많은 분들이 끝까지 집중해주어 기쁜 마음으로 발표를 마칠 수 있었습니다. 좋은 반응을 얻어 준비하느라 고생했던 일련의 과정에 보람을 느꼈습니다.

3. 우리 발표에 대한 목소리

발표가 끝난 후 공유받은 따뜻한 후기를 공유합니다! 같은 QA엔지니어로서 느끼는 공감이 올리브영 QA팀에 대한 관심까지 확장 되었다는 점을 확연하게 느꼈습니다. 이번 발표에 쏟은 노력이 결실을 맺는 순간이었습니다. 많은 후기를 받았지만, 그 중 기억에 남는 다섯 가지를 뽑아봤어요!

"체계적인 시스템을 구축하여 사용자의 불편함을 빠르게 해소하려는 프로세스가 정말 잘 잡혀있다고 느꼈습니다."

"올리브영의 QA 업무와 커뮤니케이션의 중요성을 배워 의미 있는 시간이었습니다."

"올리브영에서 어떤 인재를 원하는지 궁금한 부분이 있었는데, 오늘 발표를 듣고 제대로 알게 되었습니다."

"기술과 협업의 중심에서 QA가 어떤 역할을 하는지 실감할 수 있었어요."

"보안, 성능, 인프라까지 QA가 고려해야 할 넓은 범위를 알게 됐고, ‘작은 소통이 큰 결함을 막는다’는 말이 깊이 와닿았습니다."

4. 막간 세션 듣기! 다른 팀의 발표

부스를 운영하느라 모든 발표를 자세히 듣지는 못했지만, 예상보다 더 다양한 QA 사례를 들을 수 있어 좋았습니다. 테스트 자동화와 AI 관련 내용은 QA 업계에서 빠지지 않고 발의 되는 주제인데요, AI 기술을 실무에 적용시키는 건 이제 거의 모든 직무의 공통 분모가 된 것 같습니다. 다른 발표 중 테스트 자동화 전략에 대한 내용이 있었는데요. 모든 것을 무조건 자동화시키기 보다는 ROI(투자 대비 효과)가 높은 영역을 찾아 점진적으로 확대하는 것이 효율적인 전략이라는 점에 깊이 공감했고, 이 것은 올리브영 QA팀에서도 자주 고민하고 논의하고 있는 지점이라고 느꼈습니다.

🍭 Teamwork Log - 우리 팀을 알리기 위한 치열한 기록

| 우리_팀워크_실화냐_?_땀방울로_맺어진_준비_과정_그_비하인드.zip

저희는 컨퍼런스에 더 좋은 모습으로 참여하기 위해 약 한 달전부터 주기적으로 회의를 열었고, 어떤 프로그램을 진행할지 아이디어를 공유했습니다. 테크전략지원팀의 도움을 받아 이전 행사들에 대한 정보를 참고했지만, 제한된 시간 안에 예상했던 것보다 훨씬 더 많은 것들에 대해 논의해야 했어요.

우리가 논의했던 사항들

No. Main Topic

1 발표 주제는 무엇이 적절하고, 팀 소개 및 우리의 업무는 어디까지 공유할 수 있는가?
2 우리 팀이 타사의 QA팀과 차별화 되는 부분을 어필하기 위해 어떤 것을 강조해야 하는가?

3 제한된 공간과 시간 안에서 진행할 수 있는 QA직무와 관련된 프로그램은 무엇이 있는가?

4 참여자들이 만족하면서 올리브영에 대해 좋은 기억을 간직할만한 경품은 어떤 것인가?

5 커피챗 타임에서 예상되는 질문은 무엇이고, 우리 팀이 추구하는 방향과 일치하는 모범 답변은 무엇인가?

뿐만 아니라, 당일에 발생할 수 있는 여러 변수들에 대한 체크도 필요했어요. 경품은 사람들의 관심을 끌면서 동시에 회사의 정체성을 드러낼 수 있어야했고, 향후 지원자가 될 지도 모르는 분들을 위해 어필할 수 있는 포인트를 통찰력있게 그려내야했어요!

딱딱한 바닥 작업도 재미있게 느껴졌던 환상 그 잡채 팀워크

사실 이번 포스팅을 통해 가장 강조하고 싶은 것은 팀워크의 효과입니다. 팀워크가 실제 업무 효율성에 얼마나 중대한 영향을 끼치는 지는 많은 분들이, 단 n개월의 경력만으로도 느끼실거라 생각하는데요. 팀워크 수준이 높을수록 조직의 성과와 생산성이 향상 된다는 점은 ‘협업 계수(collaborative coefficient)’라는 개념을 사용한 연구(MDPI)를 통해 증명된 바 있습니다.

“The Impact of Teamwork on an Organization’s Performance” 논문 중

이미 여러 연구를 통해 데이터적으로 입증되었던 사실이지만, 이번 컨퍼런스를 준비하며 팀원들과 협업을 도모하는 과정에서 일이 빠르게 진행되는 것을 체험했습니다. 작은 상품 하나를 준비하는 것 마저도 서로가 잘하는 부분을 찾아주며 기분 좋은 분업을 했고, 이는 마치 누군가가 알맞는 인재를 적재적소에 배치한듯한 느낌이었습니다. 실제로 '우리 팀워크 진짜 좋다!'라는 말을 여러 번 외쳤고, 그 때문인지 컨퍼런스 준비는 체력적으로 힘든 것이 느껴지지 않았을 정도로 즐거웠습니다. 의견을 조율하고 문제를 함께 정의하는 과정에서 흩어져 있던 퍼즐이 자연스럽게 맞춰졌고, 그만큼 우리의 일도 효율적으로 흘러갔습니다. 서로의 강점을 믿고 맡길 수 있었기에 가능한 경험이었고, 이 힘이 앞으로의 업무에서도 강력한 동력이 될 것이라는 확신이 들었습니다.

사진만 봐도 느껴지는 현장의 밝은 분위기

🍭 부드러운 "Coffee"에 깊이를 더했던 "Chat"

| QA 업무와 현실적인 진로 이야기

마지막 프로그램은 커피챗을 신청해주신 분들과 진솔한 이야기를 나누는 시간이었어요. 커피챗은 단순한 질문과 답변의 시간이 아니라, 서로의 경험을 나누고 상황에 맞는 해법을 함께 찾아가는 시간이었습니다. 그리고 현실적인 진로의 방향성을 같이 고심해보는 시간도 가지게 되어 큰 의미가 있었습니다. 나아가 신청자분들의 고민을 통해 우리 팀원들 또한 진취적인 관점을 얻게 되었습니다.

커피챗에서 만났던 여러 지원자들 중 특히 인상 깊었던 분이 있습니다. Front-End 개발자로 입사했지만, 스타트업에서 여러 역할을 맡게 되었고 ‘QA 프로세스도 직접 만들어보는 게 어떻겠냐’는 제안을 받은 상황이었습니다. 이를 계기로 QA 직무에 본격적으로 관심을 갖게 되었고, 정해진 프로세스 없이 업무를 수행하는 상황에서 ‘어떻게 QA 프로세스를 구축하면 좋을까?’ 하는 고민이 많았다고 합니다. 이에 그 분의 상황에 맞춰 실제로 QA 프로세스를 어떻게 시작하고 개선할 수 있는지, 또 커리어를 확장하는 과정에서 어떤 접근을 할 수 있는지를 공유했습니다. 단순한 서비스 검증을 넘어 프로세스를 정립하고 품질 문화를 만들어 가는 어려움과 보람에 대해 이야기를 나누며 깊이 공감할 수 있었습니다.

커피챗을 진행하며 올리브영 QA팀에서는 보다 다양한 업무 기회가 있다는 점을 알리고, 온오프라인 서비스를 동시에 경험할 수 있다는 장점도 전달했습니다. 비록 긴 시간은 아니었지만, QA라는 직무의 가치를 커피챗을 통해 서로 공유하고 대화를 나눴던 분들의 커리어에도 작은 도움이 되었길 바라고, 올리브영 QA팀에 대한 관심이 더욱 커졌길 바랍니다.

🍭 컨퍼런스 참여 후기 : 우리의 이야기를 나누다

| 이 경험은 앞으로 우리에게 어떤 의미가 되고, 팀에는 어떤 영향을 가져올까?

부스 운영자로 참여함으로써 올리브영이라는 브랜드의 긍정적인 이미지와 저희 QA팀에 대한 인지도를 모두 얻었다고 생각합니다. 이번 활동이 팀과 조직에 대한 홍보 효과뿐만 아니라, 고객 관점에서 서비스에 대한 경험 확대에도 영향을 미쳤다고 느꼈어요. 컨퍼런스에서의 경험은 앞서 언급한 대로, 단순한 참여 또는 개인적인 성장을 뛰어넘어 팀 전체가 한 단계 성장하는 계기가 되었습니다.

컨퍼런스를 마치며 팀원들과 함께! ^.^

제한된 조건 속에서도 우리가 목표를 완수할 수 있었던 이유는 팀워크였습니다. 누군가 무거운 부분을 짊어지면 다른 누군가가 자연스럽게 빈 자리를 채웠고, 그 경험은 업무 효율을 넘어 ‘함께 일하는 이유’를 다시 일깨워주었습니다. QA로서 확신하건대, 팀워크는 품질을 향상시키는 힘입니다. 우리가 지향하는 품질 기준을 더 높이기 위해 앞으로도 밀도 높은 팀워크와 유기적인 협업을 그려나가봅니다!☺️

💌 우리의 참여 소회 💌

이번 기회에 '진짜 옴니채널의 협업 이야기'를 주제로 발표하며, 현장에서의 우리의 고민과 노력을 공유할 수 있어 뜻깊었습니다.

10분이라는 시간의 제약 때문에 우리가 매일 마주하는 스쿼드 기반의 품질 확보와 협력사와의 상생 등 더 구체적인 이야기들을 모두 담지 못해 아쉬움이 남습니다.

올리브영의 복잡한 옴니채널 환경은 QA를 넘어 모두의 유기적인 협력이 필요하다는 점과 이는 우리 팀의 가장 큰 강점이자 올리브영의 성장을 이끄는 동력이라고 다시 느꼈어요.

앞으로 더 많은 내부 소통 채널을 통해 우리의 '진짜' 협업 사례들을 공유하고 싶어요.

컨퍼런스를 준비하며 체력적으로는 힘들었지만, 업무 외적으로도 더 가까워진 계기가 되었습니다.

서로 다른 스쿼드를 맡고 있지만, 협업할 기회가 많은 업무 특성상 팀에도 시너지를 낼 것 같아요. 좋아서 웃었고, 힘들어서 성장했습니다.

💌 올리브영 QA팀에 전하는 방문객들의 후기 💌

끝으로, 이 모든 과정을 뿌듯함으로 마무리할 수 있게 해줬던 부스 참여자 분들의 후기를 나눠봅니다. 한 문장 한 문장이 컨퍼런스 준비부터 마지막까지 모든 일련의 과정을 떠올리게 했고 성취감을 느끼게 해줬습니다. 이 소중함을 그대로 간직한 채로, 오늘 터득한 팀워크를 내일의 효율성에 보태는 팀이 되겠습니다.

1등 상품 당첨 기념 사진

👩🏻‍🔬 : “QA 업무 중에 발생하는 문제를 예시를 통해 쉽게 이해할 수 있었던 것 같아요.”

🧙🏻‍♀️ : “현장에서 QA 사례를 직접 체험할 수 있어 실무 인사이트가 풍부하다고 느꼈습니다.”

👨🏼‍🌾 : “프로그램도 직관적이고 설명도 친절해서 품질 관리에 대한 실무자 분들의 진정성을 느낄 수 있었어요.”

👨‍🚀 : “퀴즈의 내용이 알차다고 느꼈고, 너무 재미있었는데 실무자로서 유익하기까지 했습니다!”

👩🏻‍🏫 : “참여형 부스라 재미있었고, 퀴즈를 풀던 중 긴장하고 집중도 할 수 있어서 좋은 추억이 될 것 같아요. 자연스럽게 올리브영 QA팀에도 관심이 생겼습니다.”

🧑‍🎄 : “올리브영이 너무 잘 준비해주셔서 컨퍼런스가 잘 진행된 것 같습니다." from. QA 컨퍼런스 운영진

"이번 경험을 발판 삼아, ‘모두가 함께 만들어가는 진짜 품질’을 향해 나아갑시다. 고생한 모든 팀원들에게 감사합니다." - QA Team Leader

올영세일 선착순 쿠폰, 미발급 0%를 향한 여정

Mon, 15 Dec 2025 00:00:00 GMT

안녕하세요. 올리브영 쿠폰 시스템 백엔드 개발자 '라이트'입니다.

올리브영에서 행사와 쿠폰을 빼면 고객들의 관심도가 떨어질 만큼 쿠폰은 아주 중요한 요소 중 하나입니다. 특히 선착순 쿠폰은 올영세일 같은 대규모 행사 때마다 핵심 이벤트로 빛을 발하기 때문에, 오픈 시점에 스파이크성의 동시다발적인 대량 트래픽이 발생합니다. 올리브영에서는 여러 차례에 걸쳐 쿠폰 관련 포스트를 게시했습니다. 그 중에서도 쿠폰 발급 RabbitMQ 도입기는 대량 트래픽에도 안정적인 발급 시스템을 구축한 이야기를 다루고 있죠.
이렇게 지속적인 개선으로 시스템 자체의 안정화에 도달했지만, 여전히 비동기 시스템의 단점이 남아 있었습니다. 이런 상황에 쿠폰 미발급 문제를 직면하니 제대로 해결해보자는 강한 의지가 생겼습니다.

문제 상황 - 올영세일에서 마주한 과제

2025년 6월 올영세일, 7일간의 대규모 선착순 쿠폰 행사를 운영하면서 지속적으로 모니터링한 결과 예상치 못한 문제를 발견했습니다. 세일 기간에는 온라인몰에서 동시다발적으로 쿠폰 발급 요청이 발생합니다. 모든 요청의 제한 수량 유효성 검사를 통과하면 Message Queue로 메시지가 발행되고, 발급 워커가 유효성 검사를 또 한 번 진행한 뒤 쿠폰을 최종 발급합니다. 그런데 6월 올영세일에서 발급 워커의 2차 유효성 검사가 실패해, 쿠폰이 발급되지 않은 문제가 발생했습니다. 이로 인해 사용자에게는 발급 성공으로 응답했지만, 실제 워커에서는 발급에 실패했습니다. 이는 곧바로 CS 문의로 이어지는 치명적인 문제였습니다.

2025년 6월 올영세일 선착순 쿠폰 현황

📅 행사 기간: 7일간 (05.31 ~ 06.06)

📊 평균 미발급률: 약 0.014% (10,000건당 약 1.4건 수준)

일차별 미발급률 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1일차 ███ 0.021% 2일차 ██ 0.008% 3일차 ██████ 0.037% 4일차 ██ 0.013% 5일차 ██ 0.013% 6일차 █ 0.004% 7일차 ████ 0.025%

미발급률이 평균 0.014%라는 수치는 통계적으로는 낮아 보일 수 있습니다. 하지만 이는 사용자에게 발급 성공 응답을 보냈음에도 실제 처리가 실패하여 고객 경험의 불일치를 야기하는 심각한 문제였습니다. 특히, 선착순 쿠폰을 기다린 고객에게 브랜드 신뢰도 하락과 CS 처리 비용 증가로 이어지는 치명적인 비즈니스 리스크로 인식되었습니다. 이 미발급 문제를 해결하기 위해 다방면으로 고민하고 개선한 과정을 지금부터 자세히 소개해 드리겠습니다.

비동기 시스템의 단점

비동기 처리는 요청처에 빠르게 응답하여 트래픽 지연을 해소할 수 있는 장점이 있지만, 실제 데이터 처리 결과는 비동기 로직 수행이 완료된 후 알 수 있기 때문에 데이터 일관성을 보장하기 어렵습니다. 성능과 안정성이 중요한 선착순 쿠폰 시스템에서 대량의 트래픽을 감당하기에 MQ 기반 비동기 시스템이 탁월한 방안이었지만, 여전히 개선이 필요한 점들이 남아있었습니다.

선착순 쿠폰 발급 로직 (기존)

기존의 쿠폰 발급 로직을 보면, 발급 수량 유효성 검사에 대한 빠른 처리를 위해 데이터 저장소를 DB 외에 인메모리 데이터 저장소인 Redis를 하나 더 두어 수량을 관리하고 있습니다. 매번 DB를 조회하는 비용이 크기 때문에, 수량 관리 용도로 Redis에 쿠폰 유효 기간만큼의 TTL(Time To Live)을 설정한 쿠폰별/유저별 키를 세팅하고, 쿠폰 발급 요청 시 Redis를 통해 수량을 조회하여 유효성 검사를 수행합니다.

다만, 앞서 말씀드린 바와 같이 실제 데이터 처리는 워커에서 비동기로 수행하기 때문에 1차 유효성 검사 시점과 실제 DB에 반영되어 수량을 처리하는 시점 사이에 필연적으로 시간 간극(Time Gap)이 존재할 수밖에 없는 구조였습니다. 특히, 밀리초(ms) 단위로 다량의 발급 요청이 동시에 들어온다면, 1차 유효성 검사를 통과한 n개의 요청이 모두 발급 성공 응답을 했지만, 일부 요청은 2차 유효성 검사에서 실패하게 되는 문제가 발생했습니다.

문제의 근본 원인

이 문제를 더 깊이 분석해보니 세 가지 핵심 원인이 있었습니다.

1. Time Gap (시간 간극)

T0: Redis GET (count=99) → 통과 ✅ T1: MQ 발행 (10ms) T2: Worker 수신 (50ms) T3: Redis GET (count=101) → 실패 ❌ <- T0와 T3 사이의 간극!

첫 번째 검증(T0)과 워커의 재검증(T3) 사이에는 MQ 지연 시간을 포함한 시간 간극이 발생합니다. 이처럼 짧은 순간(예: 100ms)에 수백 건의 요청이 동시에 몰리면서 경합 상태(Race Condition)가 발생하여, T0 검증이 무의미해지는 결과를 낳았습니다.

2. Double Validation Overhead (이중 검증 오버헤드)

[Online Mall] [Worker] 유효성 검사 1차 ---→ 유효성 검사 2차 (통과) (실패 가능)

비동기 시스템의 신뢰성을 위해 워커에서 한 번 더 검증하는 것은 필수였지만, 이 시간 간극으로 인해 앞단의 1차 검증 결과가 무의미해지는 상황이 발생했습니다.

3. Redis GET/INCR 원자성(Atomicity) 부재

// 문제가 되는 코드 패턴 val currentCount = redisTemplate.opsForValue().get(key) // GET if (currentCount < maxCount) { redisTemplate.opsForValue().increment(key) // INCR (별도 명령) // ⚠️ GET과 INCR 사이에 다른 요청이 끼어들 수 있음! (이 짧은 간극 사이에 경합 발생) }

Redis의 개별 명령('GET', 'INCR')은 원자적으로 동작하지만, 이들을 조합한 'GET'과 'INCR' 로직이 분리되어 수행되면서 문제가 발생했습니다. 즉, 두 명령 사이에 다른 요청이 개입할 수 있게 되어 결과적으로 원자성이 깨지고 수량 오버플로우를 유발했습니다. 이를 해결하기 위해 일부 로직을 변경하며 겪은 시행착오는 다음과 같습니다.

개선 방안

1️⃣ 시도 1: 발급 수량 선차감 (시간 간극 줄이기)

문제점: 기존에는 워커가 수량을 증가(INCR) 처리했기 때문에, 1차 검증(GET)과 실제 수량 반영(INCR) 사이에 MQ 전송 시간까지 포함된 긴 시간 간극이 발생했습니다.

개선 방안: 이 시간 간극을 줄이기 위해 'Redis 발급 수량 증가' 처리를 워커가 아닌, 온라인몰 앞단에서 선차감하도록 로직을 변경했습니다.

실패 처리: 당연히 발급 실패 시 처리도 고려했습니다. 워커에서 실제 DB 처리 중 이슈가 발생하면 선차감했던 수량을 다시 원상복구(Rollback) 하도록 구현했습니다.

선착순 쿠폰 발급 로직 (개선)

결과 및 한계: 이처럼 수량 선차감 로직을 적용한 후 부하 테스트를 진행한 결과, 미발급 건수가 줄기는 했지만 여전히 잔존하는 문제를 발견했습니다. 이는 Time Gap을 줄여도 원자성이 보장되지 않았기 때문입니다. Redis GET과 INCR이 여전히 분리되어 수행되는 한, 경합 상태는 원천적으로 차단될 수 없었습니다.

2️⃣ 시도 2: Lua 스크립트 적용 (원자성 확보)

첫 번째 시도에서 확인했듯이, 근본적인 문제는 Time Gap이 아니라 원자성 부재였습니다. 이 문제를 완전히 해결하려면 Redis의 GET/INCR 명령 수행 간 원자성이 보장되어야 합니다. 그래야 모든 요청이 순차 처리되어 정확한 유효성 검사가 가능해집니다. 이러한 원자성 보장을 위해 저희가 적용을 검토한 방법이 바로 Lua 스크립트입니다.

💡 여기서 Lua 스크립트란?

루아(Lua) 스크립트는 가볍고 빠른 스크립트 프로그래밍 언어로, 다른 시스템(예: 게임 엔진, 서버, 데이터베이스 등)에 내장해서 동작을 확장하거나 자동화할 때 자주 사용됩니다. Redis는 서버 내부에서 Lua 스크립트를 실행할 수 있게 지원하며, 여러 명령을 원자적(atomic) 으로 실행하거나, 복잡한 로직을 네트워크 왕복 없이 한 번에 처리할 수 있습니다.

local current = redis.call('GET', KEYS[1]) if current then local num = tonumber(current) if num and num < tonumber(ARGV[1]) then redis.call('INCR', KEYS[1]) return true else return false end else redis.call('SET', KEYS[1], 1) redis.call('EXPIREAT', KEYS[1], tonumber(ARGV[2])) return true end

참고 문서) Redis Programmability - Scripting with Lua

위의 예시처럼 작성된 스크립트를 하나의 트랜잭션처럼 묶어서 처리하므로 원자성을 보장하지만, Redis는 단일 스레드 구조이기 때문에 스크립트를 수행하는 동안 다른 요청은 모두 대기하게 됩니다. 따라서, 스크립트가 길고 복잡해질수록 성능은 낮아질 수밖에 없습니다. 실제로 스크립트를 적용하여 부하 테스트를 수행한 결과, 미발급/과발급 건은 모두 0건으로 해소되었지만, 기존 대비 약 21% 정도의 성능 저하가 발생하였습니다.

⚠️ 주의사항: Lua 스크립트와 성능

고성능을 요구하는 시스템에서는 Lua 스크립트의 수행 시간을 최소화하고, 반드시 필요한 로직만 원자적으로 처리하도록 구현해야 합니다.

처음부터 원자성을 고려한 스크립트 적용으로 설계가 되었으면 모르겠으나, 이미 선착순 쿠폰 발급에 대한 우수한 성능을 자랑하던 시스템에 성능 저하가 되는 로직을 넣기에는 무리였습니다.

3️⃣ 시도 3: 발급 요청 수량 체크 용도의 별도 Redis Key 추가 관리

이중 카운터 전략

원자성 보장과 성능 유지라는 두 마리 토끼를 잡기 위해 고안한 방법은 바로 이중 카운터(Double Counter) 전략입니다. 이 전략은 실제 쿠폰 발급 제한 수량을 관리하는 키 외에, 발급 요청 수량 관리를 위한 별도의 Redis 키를 추가하여 유효성 검사를 이중화하는 방식입니다.

Redis Key 용도

C001-count 최종 쿠폰 발급 제한 수량 제어 (DB 정합성에 사용)

C001-countReq 쿠폰 발급 요청 수량 제어 (경합 상태 방지)

기존 방식의 문제

Redis 수량 차감 흐름도 (기존)

개선된 방식

Redis 수량 차감 흐름도 (개선)

왜 이 방법이 효과적인가?

✅ 요청 카운터가 먼저 증가하므로 동시 요청 차단

✅ 실제 카운터는 통과된 요청만 증가 → 정확성 보장

✅ Lua 스크립트 없이 2개 명령으로 해결 → 성능 영향 최소화

참고 문서) Redis Docs - Pattern:Counter

결론적으로, 실제 수량이 초과될 상황이 원천 차단되었으며, 워커로 넘어가는 초과 발급 건수는 모두 0건으로 완벽히 해소되었습니다.

최종 의사결정: 1번 + 3번 조합 선택

다양한 시도 끝에 발급 수량 선차감(1번)과 이중 카운터 전략(3번)을 조합한 방식을 최종 선택했습니다.

의사결정 과정

방안 정확성 성능 선택 여부

1️⃣ 수량 선차감 △ (개선됨) ⭐⭐⭐⭐⭐ ✅ 채택

2️⃣ Lua 스크립트 ⭐⭐⭐⭐⭐ ⭐⭐⭐ (21%↓) ❌ 기각

3️⃣ 이중 카운터 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ (8%↓) ✅ 채택

기각 이유 (Lua 스크립트):

❌ 성능 저하: 21%의 처리량 감소는 대규모 트래픽 환경에서 치명적

❌ Redis 부하: 단일 스레드 특성상 전체 시스템 병목 가능성

❌ 운영/관리 복잡도 증가: 스크립트 디버깅과 모니터링의 어려움

채택 이유 (이중 카운터):

✅ 허용 가능한 성능 영향: 8%의 성능 저하가 발생했지만, 운영 환경 스펙 및 실제 요청량 대비 TPS 및 분당 처리량을 계산했을 때 충분히 감당 가능한 수준이라고 판단 (정확성 100% 확보와 동시에 성능 트레이드오프 최소화)

개선 결과

📊 성능 지표 비교 및 성과

개발 환경에서 수행한 부하테스트 결과입니다. 실제 운영 환경보다 높은 부하 조건에서 측정한 수치이므로 미발급률에 다소 차이가 있을 수 있으나, 이를 감안해도 개선 효과는 매우 분명하게 나타났습니다.

부하 테스트 결과 (쿠폰 제한 수량 10,000건)

선착순 쿠폰 제한 수량 10,000건을 기준으로 비교한 결과, 발급 정확도는 100%로 향상되었고, 미발급 건수는 0건으로 완전히 감소했습니다.

구분 개선 전 개선 후 개선율

발급 성공 응답 10,162건 10,000건 ⭐️100% 정확⭐️

미발급 건수 162건 0건 ⭐️100% 감소⭐️

미발급률 1.62% 0% ⭐️완전 해소⭐️

실제 운영에서도 동일한 결과가 확인되었습니다. 정확한 비교를 위해 9월 올영 세일 3일차까지는 위에서 개선한 기능 플래그를 OFF로 해두고, 4일차부터 ON하여 미발급 건의 차이가 있는지 확인해보았습니다. 그 결과 3일차까지 기존처럼 미발급 건이 발생하였고, 4일차부터는 미발급 건수는 0건, 그리고 분당/초당 최대 처리량 역시 6월 대비 저하 없이 안정적으로 유지되었습니다! 🥳🎉👏🏻👏🏻 (8% 성능 저하는 실전에서 영향이 미미했습니다.)

개선 방안을 실무에 적용 시 고려했던 사항들은 아래와 같습니다.

1. Redis 키 관리 전략

키 네이밍 명확히 구분 및 적절한 TTL 설정

// 쿠폰별 키 네이밍 규칙 val countKey = "coupon:${couponId}:count" // 실제 발급 수 val countReqKey = "coupon:${couponId}:countReq" // 발급 요청 수 // TTL 설정 (쿠폰 종료 시각 + 버퍼) val ttl = couponEndTime.plusHours(1)

2. 모니터링 포인트

정합성 체크: count vs countReq 간의 지속적인 차이 모니터링 (경합 상태 완화 후에도 발생 가능한 비정상적 흐름 감지)

알람 설정: 두 키의 카운트 차이가 임계치를 벗어날 경우 즉시 알람 설정

Redis 자원 추적: Redis 메모리 사용량 및 명령 처리 지연(Latency) 추적

3. 장애 대응 및 안정화 시나리오

Fallback 전략: Redis 장애 발생 시 DB 기반 Fallback 로직을 통한 서비스 연속성 확보 필요 (단, 성능 저하 위험 인지)

정합성 보정: count와 countReq 수량 불일치 감지 시 자동 또는 수동 정합성 체크 및 수량 조정 프로세스 마련

마무리

이 프로젝트를 통해 배운 것은 크게 세 가지입니다.
첫째, 완벽한 시스템은 없다, 그러나 개선은 계속된다. 어떠한 예외 상황에서도 완벽한 시스템을 만들어내는 것은 거의 불가능에 가까운 일 아닌가 싶습니다. 99.99%의 고가용성 시스템이라도 단 0.01% 가 실패하면 그건 완벽한 시스템은 아니니까요. 그래서 문제가 발생하면 빠르게 캐치하고, 더 나은 해결책을 찾아 적용하는 과정이 무엇보다 중요하다는걸 느꼈습니다.
둘째, 성능과 정확성의 균형이 필요하다. Lua 스크립트가 기술적으로 가장 완벽한 해결책처럼 보였지만, 실제 프로덕션 환경에서는 21%의 성능 저하가 더 큰 문제였습니다. 반면 이중 카운터 전략을 통해 시스템의 응답 속도를 유지하면서도 데이터 정합성을 100% 보장하는 실질적인 균형점을 찾아냈습니다.
셋째, 데이터 정합성과 응답 속도는 트레이드오프다. 비동기 시스템은 빠른 응답 속도를 얻는 대신 데이터 정합성 보장이 어렵다는 근본적인 트레이드오프를 가지고 있습니다. 다행히 이번 개선에서는 응답 속도를 유지하면서도 정합성을 보장하는 방법을 찾았습니다.

저의 해결책 역시 올리브영 쿠폰 시스템 환경에 최적화된 결과일 뿐, 완벽하다고 말할 수는 없습니다. 하지만 각 시스템마다 최우선시해야 하는 요소가 무엇인지에 따라 해결책은 다양하게 적용될 수 있습니다. 올리브영 쿠폰 시스템에서는 고객 신뢰가 가장 중요한 가치였기에, 저희는 정확성을 최우선으로 두면서도 성능을 포기하지 않는 합리적인 방법을 찾아냈습니다. 이 과정에서 얻은 경험과 노하우가 비슷한 고민을 하는 분들께 조금이나마 도움이 되길 바랍니다.
저의 첫 포스팅을 읽어 주셔서 감사합니다. 다음에는 더 좋은 내용으로 찾아뵙겠습니다. 🙏

Kafka Streams 기반 EDA 구축 사례: 올리브영 품절 시스템 현대화 프로젝트

Mon, 15 Dec 2025 15:00:00 GMT

안녕하세요. 올리브영의 상품 운영 프로세스 개발 업무를 담당하고 있는 벙개맨⚡️ 입니다.
제가 소속된 상품 탐색 스쿼드는 보다 안정적이고 확장성 있는 상품 정보 관리를 위해 상품 통합 프로젝트를 진행하고 있습니다.
오늘은 위 프로젝트의 한 부분인 상품의 품절 여부 관리 프로세스를 어떻게 개선했는지, 그리고 개선 과정에서 실시간 데이터 처리를 위해 활용한 Kafka Streams에 대하여 소개해 드리겠습니다.

이 이미지는 Google Gemini로 생성되었습니다.

⛔️ 멈춰버린 데이터 고속도로: 기존 프로세스의 문제점

올리브영 온라인몰은 고객에게 정확한 상품의 품절 여부(Sold Out Status) 정보를 제공하기 위해, 이 데이터를 장바구니, 검색 결과, 상품 상세 페이지 등 다양한 영역에서 핵심적으로 활용하고 있습니다. 하지만 개선 이전에는 품절 여부를 조회하기 위해 Oracle 함수를 직접 호출하는 구조를 사용하고 있었고, 내부적으로 복잡한 쿼리를 수행해야 했기 때문에 응답 속도와 처리 효율이 떨어졌습니다. 또한 별도의 캐시 처리 없이 모든 트래픽이 Oracle 함수를 직접 호출했습니다. 이로 인해 데이터베이스에 지속적인 부하가 발생했습니다. 특히 올영세일과 같은 대규모 트래픽 상황에서는 이 부하가 심화되어 품절 정보 조회 지연은 물론, 온라인몰 전체 서비스 품질에도 영향을 주는 문제가 발생했습니다. 이러한 한계를 해소하고 보다 안정적이며 확장 가능한 서비스를 제공하기 위해 저희는 품절 여부 관리 프로세스 개선을 진행하게 되었습니다.

AS-IS 상품 품절 조회 process

🚉 새로운 환승 시스템을 설계하다: 해결책 모색

저희는 기존 DB 내부 로직(Oracle 함수 등)에 의존하던 일방향식 처리 구조를 벗어나, OGG(Oracle GoldenGate), AWS MSK(Managed Streaming for Apache Kafka), Kafka Streams를 활용한 Event-Driven Architecture(EDA) 기반의 새로운 데이터 환승 시스템을 설계하였습니다. EDA를 도입한 주요 목적은 다음과 같습니다.

DB 단일 의존성 제거와 안정성 확보

기존에는 Oracle DB에 집중된 레거시 구조로 인해, DB 부하나 장애가 발생하면 전체 서비스가 영향을 받는 단일 장애 지점(Single Point of Failure) 문제가 있었습니다. 이에 저희는 DB 의존성을 줄이고, 서비스 단위로 독립적인 확장과 안정적인 장애 대응이 가능한 구조로 전환하였습니다.

실시간 데이터 처리와 낮은 결합도 구현

과거에는 배치 중심의 데이터 전달 방식이라 지연(latency) 이 발생하고, 서비스 간 결합도가 높아 변경이 어려웠습니다. 이를 이벤트 기반 구조로 전환하면서, 데이터 변경 시 즉시 이벤트를 발행하고 필요한 서비스가 이를 구독하여 실시간으로 처리할 수 있게 되었습니다. 결과적으로 서비스 간 결합도가 낮아지고, 변경 대응이 유연해졌습니다.

손쉬운 확장성과 유연한 비즈니스 대응

Kafka 기반의 이벤트 파이프라인은 새로운 서비스가 필요할 때 단순히 이벤트를 구독하는 것만으로 손쉽게 확장할 수 있습니다. 또한 Kafka Streams를 활용해 이벤트를 실시간으로 가공, 조합함으로써, 기존 DB 중심 처리 방식으로는 구현하기 어려웠던 다양한 비즈니스 요구사항에도 유연하게 대응할 수 있게 되었습니다.

TO-BE 상품 품절 관리 process

🔄 실시간으로 흐르는 재고 데이터: 새로운 아키텍처의 동작 방식

새로 설계한 아키텍처에서는 상품 재고의 변경 이벤트가 발생하는 순간부터 해당 정보가 실시간으로 흐르는 구조로 변경되었습니다.

먼저, Event Data Producer 영역에서는 재고 변경이 감지되면 CDC(Change Data Capture)를 통해 변경 이벤트를 Kafka Topic으로 즉시 발행합니다. 이 메시지는 Stream Data Processing 영역으로 전달되어 Kafka Streams를 통해 필요한 로직이 실시간으로 처리되고, 최종적으로 OpenSearch에 상품의 품절 여부 정보가 저장됩니다.

상품 유형별 재고 관리 구조

이 아키텍처를 이해하려면 먼저 올리브영의 재고 관리 체계를 알아야 합니다. 추후 인벤토리 담당 스쿼드에서 통합 관리 예정이나, 현재 올리브영에서는 상품 유형에 따라 재고 데이터의 관리 주체가 다릅니다.

올리브영의 상품은 크게 세 가지 재고 관리 체계로 구분됩니다.

직매입 상품 (올리브영이 직접 재고 보유)

관리 주체: 인벤토리 스쿼드

처리 방식: Inventory Service 내부에서 변경된 재고 정보를 감지하여 Kafka Topic으로 발행

위수탁 상품 (협력사 재고)

관리 주체: 상품 탐색 스쿼드

처리 방식: Kafka Streams로 실시간 이벤트 처리

예약/한정 상품 (한시적 재고)

관리 주체: 상품 탐색 스쿼드

처리 방식: Kafka Streams로 실시간 이벤트 처리

Kafka Streams를 통한 실시간 품절 처리

특히 위수탁 및 예약/한정 상품의 경우, Kafka Streams는 다음과 같은 방식으로 품절 여부를 실시간 판단합니다.

이벤트 감지: 재고 변경 이벤트 중 "모든 재고 소진" 또는 "재고 입고로 판매 재개" 상태 전환을 감지

토픽 발행: 감지된 이벤트를 SoldOut 토픽으로 발행

Kafka Streams를 통한 재고 품절 처리

이러한 구조로 전환하면서 기존 DB 기반 배치 처리 방식에서 발생하던 시간 지연과 데이터 정합성 문제가 크게 개선되었습니다. 각 단계가 이벤트 기반으로 긴밀하게 연결되어, 재고 변경부터 검색 결과 반영까지의 전체 프로세스가 실시간으로 처리됩니다. 마치 잘 정비된 고속 환승 시스템처럼 매끄럽게 이어지는 거죠.

🚄 데이터 KTX를 소개합니다: Kafka Streams란?

위 아키텍처를 보면서 "재고 변동이 일어날 때마다 어떻게 그렇게 빠르게 처리될까?" 궁금하셨을 텐데요. 그 비밀은 바로 Kafka Streams에 있습니다. Kafka Streams란 Kafka에서 공식적으로 제공하는 Kafka 클라이언트 Java 라이브러리로, 토픽 데이터를 낮은 지연과 빠른 속도로 처리가 가능합니다. 토픽 데이터를 가공하여 다른 토픽으로 발행하거나 2개 이상의 토픽을 조인하여 데이터 집계 처리하는 등 다양하게 활용될 수 있으며, 간단한 코드로 구현이 가능한 장점이 있습니다.

카프카와 완벽한 호환

Kafka에서 공식으로 제공되는 라이브러리로 Kafka 버전에 맞춰 호환성을 제공

딱 1번만(Exactly-once) 처리 보장

데이터가 유실되거나 중복 처리되지 않도록 한 번만 처리될 수 있는 기능 제공

별도 스케줄링 도구가 불필요

Spark Streaming 등 별도의 스케줄링 도구가 필요 없이 Kafka Streams를 통하여 Stream Processing 처리 가능

Streams DSL과 Processor API를 사용하여 간단한 구현 가능

Streams DSL

미리 제공되는 함수들을 사용하여 간단하게 로직 구현 가능 (filter, map, join, window 등)

KStream, Ktable, GlobalKtable 데이터 처리 구조 제공

스트림 데이터 처리뿐 아니라 key-value 저장소로 사용 가능

Processor API

Streams DSL을 통한 구현이 불가할 경우 사용

Streams DSL 보다 복잡한 코드 구조를 가지지만, Lower-Level에서 복잡하고 정교한 로직 구현 가능

로컬 상태 저장소를 사용

상태 기반 처리를 위하여 RockDB를 사용하며, 장애가 발생하더라도 안전하게 복구 가능

🧩 Kafka Streams의 동작 방식

Kafka Streams는 내부적으로 Topology(토폴로지) 구조로 동작합니다. Topology는 데이터를 처리하는 일련의 흐름을 노드(Processor) 단위로 구성한 형태로, 각 노드가 데이터를 받아 가공하고 다음 단계로 전달하는 파이프라인 역할을 합니다.

Kafka Streams의 Topology는 크게 다음 세 가지 Processor로 구성됩니다.

Source Processor

Topology의 시작점으로, Kafka 토픽과 직접 연결되어 메시지를 가져오는 역할을 합니다. 즉, 스트림 처리를 시작하기 위해 가장 먼저 데이터를 받아오는 입구 노드입니다.

Stream Processor

가져온 메시지를 실제로 가공·처리하는 핵심 노드입니다. 여기서는 join, window 등의 연산이나 다양한 비즈니스 로직을 적용하여 데이터를 원하는 형태로 변환하거나 조합합니다.

Sink Processor

Topology의 마지막 노드로 가공, 집계된 데이터를 다른 Kafka 토픽으로 발행하는 역할을 합니다. 즉, 처리된 결과가 다음 시스템이나 서비스로 전달되는 출구 노드입니다.

Kafka Streams 동작방식

🔑 어째서 Kafka Streams일까?

상품 재고 수량의 실시간 변동을 처리하기 위해 Kafka Streams를 선택한 이유는 다음과 같습니다.

1️⃣ Streams DSL을 활용해 구현이 간결합니다.

Kafka Streams는 map, filter 등 기본 함수를 제공하여 복잡한 로직 없이도 원하는 비즈니스 조건을 간단한 코드로 표현할 수 있습니다. 이를 통해 개발 효율성을 높이고, 유지 보수가 용이한 구조를 확보할 수 있었습니다.

2️⃣ 애플리케이션 구조가 단순해집니다.

기존 구조에서는 Consumer와 Producer 애플리케이션의 분리로 인해 불필요한 네트워크 통신이 발생하고 복잡도가 높았습니다. Kafka Streams는 Consumer와 Producer 로직을 단일 애플리케이션 내에서 통합 관리하여 구조를 간결하게 만들고, 유지 보수성을 크게 개선할 수 있었습니다.

3️⃣ 실시간 데이터 처리에 최적화된 아키텍처입니다.

Kafka Streams는 스트리밍 데이터의 특성에 맞춰 설계된 라이브러리로, 재고와 같이 지속적으로 변화하는 데이터를 낮은 지연과 높은 처리 안정성으로 다룰 수 있습니다.

결과적으로 Kafka Streams는 실시간성과 단순성을 모두 갖춘 구조로, 상품 재고 처리 프로세스의 안정성과 효율성을 한층 높이는 핵심 역할을 하게 되었습니다.

⌨️ Kafka Streams 예제 코드

Kafka Streams의 가장 큰 장점 중 하나는 복잡한 실시간 데이터 처리를 단 몇 줄의 코드로 구현할 수 있다는 점입니다. 아래 예제는 Streams DSL을 사용하여 품절에 대한 이벤트를 감지하고, 가공된 데이터를 다른 토픽으로 발행하는 간단한 구현 예제 코드입니다.

@Component class SoldOutStreamsProcessor ( private val goodsInventoryService: GoodsInventoryService, private val streamsBuilder: StreamsBuilder, private val streamsProperty: StreamsProperty ) { fun soldOutInventory() { streamsBuilder.stream<String, String>(streamsProperty.optionInventory) // streamsBuilder를 통하여 스트림 데이터를 consume .mapValues { value -> convertToMessage<SoldOutVo>(value) } // 비즈니스 형식에 맞게 Message Convert .filter { _, value -> goodsInventoryService.validateSoldOut(value) } // 비즈니스 조건에 맞는 이벤트 감지 .map { _, value -> convertFromMessage(value?.afterInventory) } // produce topic 형식에 맞게 Message Convert .filter { _, value -> !value.isNullOrEmpty() } .to(streamsProperty.optionSoldOut) // topic produce } }

이처럼 Kafka Streams는 토픽 데이터를 읽고(consume), 비즈니스 로직을 적용한 뒤, 다시 토픽으로 발행(produce) 하기까지의 과정을 하나의 애플리케이션 내에서 간결하게 처리할 수 있습니다. 복잡한 네트워크 구성이나 별도의 Consumer/Producer 관리 없이도 안정적인 스트리밍 처리가 가능하다는 점이 큰 장점입니다.

🚄 열차 운행의 비밀: 코드와 주의 사항

다만 Kafka Streams를 도입할 때는 몇 가지 주의해야 할 점이 있습니다. 스트리밍 처리의 장점을 극대화하기 위해서는 아래 항목들을 유념해야 합니다.

1️⃣ 네트워크 통신이 필요한 고비용 작업은 지양할 것

Kafka Streams는 메모리 기반의 실시간 데이터 처리에 최적화된 구조를 가지고 있습니다. 따라서 내부 프로세스에서 외부 API 호출이나 DB I/O 등 네트워크 통신이 필요한 작업을 수행하면 지연(latency)이 증가하고 전체 스트림 처리 효율이 저하될 수 있습니다. 이런 경우에는 별도의 비동기 처리나 외부 서비스 연동 구조로 분리하는 것이 좋습니다.

2️⃣ 토픽 간 조인(Join)에는 제약이 존재함

Kafka Streams는 토픽 간 조인을 지원하지만, 다음과 같은 조건을 만족해야 합니다.

동일한 Kafka Cluster 내에 토픽이 존재해야 합니다.

조인 대상 토픽의 키(Key) 가 동일해야 합니다.

토픽들이 동일한 파티션 수를 가지며 코파티셔닝(co-partitioning) 되어 있어야 합니다.

이 조건 중 하나라도 만족하지 않으면 조인 동작이 정상적으로 수행되지 않을 수 있습니다.

🙋‍ 조인(Join)이란?

Kafka Streams에서 조인(Join) 이란, 두 개 이상의 스트림(토픽)을 공통된 키(key)를 기준으로 결합하는 기능을 의미합니다. 즉, 서로 다른 토픽 혹은 상태 저장소(State Store)에서 유입된 데이터를 같은 키값으로 묶어 새로운 이벤트나 상태를 만들어내는 방식입니다. 예를 들어, 토픽 A와 토픽 B가 동일한 키를 가진 데이터를 각각 발행하면, Stream Processor는 두 데이터를 하나로 결합하여 새로운 토픽으로 발행하게 됩니다. 이 과정을 통해 여러 소스에서 들어오는 실시간 데이터를 하나의 통합된 이벤트로 다룰 수 있습니다.

Kafka Streams Join

🙋‍ 코파티셔닝(Co-partitioning)이란?

2개 이상의 스트림(토픽)이 동일한 파티셔닝 스키마를 따르는 것을 의미합니다. 즉, 서로 다른 두 개의 토픽이 파티션 개수가 같고 동일한 파티셔닝 전략(partition strategy)을 사용하면서, 조인이 되고자 하는 데이터가 메시지 키에 주입된 상태를 의미합니다. 아래 그림을 보면 각 토픽 및 파티션에 전달되는 데이터의 동일한 키를 가진 메시지는 동일한 파티션으로 할당되는 것을 볼 수 있습니다. Kafka Streams에서는 각 파티션 별로 Task를 할당하여 데이터를 처리하기 때문에 데이터를 조인을 사용하기 위해서는 아래와 같이 코파티셔닝된 구조가 선행되어야 합니다.

Kafka Streams Co-partitioning

아쉽지만 위에 설명드린 조인(Join) 기능에 대해서는 품절 시스템에 활용하지는 못했습니다. 초기 프로모션 정보까지 포함되어 재고 관리가 되도록 기획되었으나 복잡한 비즈니스 관계로 인해 간소화되었고, Kafka Streams를 통해서 상품 분류 별 재고 토픽의 필터링 처리하는 기능으로 사용하게 되었습니다. 하지만 Kafka Streams의 활용성은 무궁무진하니, 앞으로도 다양한 비즈니스에 적용해 볼 계획입니다!

🎯 러시아워에 본 개선 결과: 성공 그 자체

상품 품절 여부 관리 프로세스 개선을 진행한 후 첫 올영세일을 맞이했습니다! 모니터링 결과는 놀랍게도 함수 호출 양의 약 86%가 감소했습니다! 개선 전 일주일 동안 오라클 함수 호출 양은 2.34G (23억 4천만)이었으나, 개선 후 237M (2억 3천7백만)으로 함수 호출 양이 대폭 감소한 것을 확인할 수 있었습니다.👏🏻👏🏻👏🏻 그로 인해 올영 세일 기간에 보다 안정적인 서비스를 제공할 수 있게 되었습니다.

개선 전 Oracle 함수 호출

개선 후 Oracle 함수 호출

🏃 우리의 여정은 계속됩니다

이번 글에서 소개한 상품 품절 여부 관리 프로세스 개선은 현재 진행 중인 상품 통합 프로젝트의 한 부분입니다. 다양한 팀과 협업하는 큰 프로젝트를 처음 진행하다 보니 개인적으로 많은 도전과 성장의 기회를 얻었습니다. 앞으로 넘어야 할 산이 참 많지만, 능력 있는 팀원들과 함께라면 남은 여정도 성공적으로 헤쳐나갈 수 있을 것이라 확신합니다!

다음 포스트에는 더 많은 정보를 담아 풍성하게 돌아오겠습니다.
많은 관심 부탁드리며 마무리 하겠습니다. 긴 글 읽어주셔서 감사합니다.

QA 엔지니어가 AI로 만든 교육 영상, 25분짜리 인시던트 가이드 탄생기

Mon, 08 Dec 2025 17:00:00 GMT

안녕하세요! 올리브영의 QA팀 입니다. 이번 글에서는 저희 팀이 AI 기술을 활용하여 제작한 인시던트 교육 영상에 대한 흥미로운 제작 과정을 소개하려 합니다.

💡잠깐! 인시던트 관리에 대해 먼저 알고 싶다면?
이 글은 인시던트 관리 정책을 효과적으로 전파하기 위한 '영상 제작 과정'에 초점을 맞추고 있습니다. 따라서 평소 올리브영의 인시던트 관리 문화와 체계에 대해 궁금하셨다면, 올리브영은 인시던트를 어떻게 관리하고 있는가?를 먼저 읽어보시길 권장드립니다.😉

💭 왜 영상이었나: 인시던트 교육의 새로운 시도

QA팀의 역할 확장: 검증을 넘어 전파로

QA팀이라고 하면 흔히 "버그를 찾는 팀" 또는 "검증하는 팀"으로 생각하기 쉽습니다. 물론 그것도 우리의 중요한 역할입니다. 하지만 올리브영의 QA팀은 단순한 확인을 넘어 서비스 안정성과 품질 향상을 주도하는 팀이기도 합니다.

QA팀은 매년 다양한 인시던트를 분석하고, 그 원인과 대응 과정을 기록하며 서비스 품질 개선을 위해 꾸준히 노력해왔습니다. 하지만 아무리 정확한 가이드와 상세한 문서를 만들어도, 실제로 읽히지 않거나 제대로 이해되지 않으면 의미가 없습니다.

특히 인시던트 대응은 초기 판단이 가장 중요합니다. 발생 후 1시간 이내에 정확한 레벨을 선언하고, 적절한 보고 체계를 따라야 피해를 최소화할 수 있습니다. 그래서 올리브영은 인시던트 레벨 선언 및 대응 프로세스를 강화해오고 있습니다.

2025 인시던트 레벨 개편: 동일한 기준 공유의 필요성

서비스의 성장에 맞춰 2025년 새로운 비즈니스 규모를 반영한 레벨 기준이 적용되면서, 전체 조직이 동일한 이해를 갖고 대응할 수 있도록 정확한 기준 공유가 무엇보다 중요해졌습니다.

올리브영은 인시던트를 영향도에 따라 Level 0부터 Level 3까지 4단계로 분류하며, 각 레벨마다 보고 체계와 대응 절차가 다릅니다. 하지만 기존처럼 구두/문서 전파를 하자니 참고 자료로는 훌륭하지만 긴급 상황의 행동 지침으로는 한계가 있다고 판단했습니다. 단순히 '정보를 제공'하는 것을 넘어, 구성원들이 긴급 상황에서 '정보를 기억하고 즉시 행동'할 수 있도록 해야 했습니다.

이러한 학습 효과의 관점에서 기존 방식을 재검토한 결과, 교육학에서 학습 방법에 따른 기억 보존율을 나타내는 "학습 피라미드(Learning Pyramid)" 이론을 주목하게 되었습니다. 수백 명의 관계자에 가르치기(Teaching) 및 실습(Practice)을 진행할 수 없는 현실적 제약 하에서, 시청각 자료를 제공하는 것이 단순 문서 제공 대비 2배 기억 보존율을 2배 이상 높일 수 있는 가장 현실적인 대안이라고 판단했습니다.

학습 피라미드(Learning Pyramid) 이론

무엇보다 이 교육 영상은 아래와 같은 효과가 기대되었고, 그래서 우리는 결심했습니다. 품질을 관리하는 팀이니까, 이제는 품질의 '이해'까지 관리하자고!

반복 시청 용이성: 필요할 때마다 해당 챕터만 빠르게 확인 가능

시각적 강조 효과: 중요한 기준을 화면과 음성으로 동시에 전달

메시지 통일성: 누가 시청하든 동일한 내용과 방식으로 메시지를 전달

확장성 확보: 신규 입사자 온보딩 교육에도 즉시 활용 가능

처음에는 저희도 스스로에게 물었습니다.

“QA팀이 영상을 만든다고?”
“검증은 자신 있는데… 영상 제작은 또 다른 세계 아닐까?” 😅

하지만 곰곰이 생각해보니, 인시던트 교육이야말로 QA가 가장 잘 설명할 수 있는 영역이었습니다. 인시던트의 본질은 '무엇이 왜 잘못되었는가'를 찾고, '앞으로 어떻게 예방할 것인가'를 정의하는 일! 즉, 서비스 품질을 개선하는 QA의 핵심 역할과 완전히 맞닿아 있었죠. 그렇게 QA팀의 첫 번째 AI 영상 제작 도전이 시작됐습니다. 영상 제작 경험은 없었지만, “정확하고 이해하기 쉬운 전달”이라는 목표 하나만큼은 누구보다 확실했죠.

🎬 AI 툴 평가: QA 관점의 의사결정 과정

교육 영상 제작, 누구나 겪는 현실적 장벽

기존 방식으로 교육 영상을 제작하는 데에는 상당한 어려움이 따릅니다. 긴 제작 일정부터 막대한 비용, 전문 기술 요구 사항까지 효과적인 교육 자료 제작의 장벽은 압도적으로 느껴질 수 있습니다.

스크립트 작성, 소스 제작, 촬영, 편집, 후반 작업 등 전통적인 영상 제작은 각 단계마다 막대한 시간과 리소스를 요구합니다. 특히 저희처럼 전문 영상팀이 없는 조직은, 이러한 리소스 제약 때문에 외주 제작을 고려할 수밖에 없습니다. 하지만 전문 제작사에 의뢰하는 경우 15분 분량 교육 영상 하나에 300만원에서 500만원, 제작 기간만 최소 2주에서 한 달이 소요되는 것이 일반적입니다.

저희처럼 전문 영상팀이 없는 조직의 경우 상황은 훨씬 더 복잡합니다. 전문 장비나 전문 지식 없이 고품질 영상을 제작하는 것은 거의 불가능에 가깝습니다. 저희 QA팀도 예외는 아니었습니다. 인시던트 교육의 중요성은 누구보다 잘 알고 있었지만, 아래와 같은 현실적인 제약이 발목을 잡았습니다.

영상 제작 경험이 전무한 QA 엔지니어 2명

제한된 예산 (외주 제작은 선택지에서 제외)

촉박한 일정 (2025년 9월까지 새 기준 전파 필수)

이러한 리소스와 확장성의 격차는 중요한 문제입니다. 영상은 학습을 위한 강력한 도구이지만, 일관성 있는 고품질 교육 콘텐츠를 제작하는 데 필요한 노력으로 인해 조직이 그 잠재력을 완전히 실현하지 못하는 경우가 많습니다. 바로 이 지점에서, AI가 게임 체인저가 될 수 있다고 판단했습니다.

AI 툴이 바꾸는 콘텐츠 제작의 패러다임

생성형 AI의 발전은 영상 제작의 진입 장벽을 극적으로 낮추고 있습니다. 전문 영상 제작자나 편집자 없이도, 고가의 장비 없이도, AI 툴의 조합만으로 방송 수준의 교육 콘텐츠를 만들 수 있는 시대가 열린 것입니다. 하지만 현실은 그렇게 단순하지 않았습니다. 시중에 수십 가지 AI 영상 툴이 넘쳐났지만, 이렇게 길이가 길고 메세지가 많은 콘텐츠에는 "어떤 툴을 어떻게 조합해야 하는가"에 대한 검증된 가이드는 찾기 어려웠습니다. 그래서 우리는 회사에 양해를 구하고 직접 실험하기로 했습니다.

8가지 조합을 테스트한 2주간의 여정

영상 제작을 결심한 뒤 첫 번째 과제는 바로 툴 탐색과 조합 전략 수립이었습니다. 말씀드린대로 우리는 테스트 자동화와 품질 검증에는 익숙하지만 영상 편집은 처음이었습니다. 하지만 소프트웨어 툴을 평가하는 방법론은 알고 있었죠. 짧은 시간 안에 효율적으로 제작할 수 있으면서도 전달력이 뛰어난 조합을 찾는 것이 핵심이었습니다.

1단계) 후보군 선정

AI 영상 제작 툴 비교

먼저 시장에서 주목받는 AI 영상 제작 툴들을 비교했습니다. 가격은 선택 과정에서 중요한 판단 요소였기 때문에, 2025년 여름(7월 기준) 가격을 조사해 아래 표에 정리했습니다. 이후 정책 변경이나 업데이트에 따라 변동될 수 있다는 점도 함께 고려했습니다.

도구 특징 비고 가격(월)

Synthesia 글로벌 기업용 AI 아바타 영상 제작, 다국어 지원 강점 자연스러운 진행자형 영상 가능 $0~89

Vyond 캐릭터 기반 애니메이션 연출, 스토리텔링에 유리 다양한 상황 연출 가능 $0~99

Gemma 텍스트 기반 슬라이드 제작 도구로, 콘텐츠 콘셉트 시각화에 용이 빠르고 간단하지만 연출 한계가 있음 $0~25

Vrew 자막/컷 편집 지원, 영상 흐름과 템포 조절 가능, AI 목소리 학습 가능 커스터마이징 자유도 높음 $0~28

AI STUDIOS (DeepBrain AI) 실제 인물형 AI 아바타가 자연스럽게 설명 교육 영상의 강의자 역할 구현에 적합 $0~69

Veo3 챕터 기반 영상 자동 생성, 이미지와 텍스트 기반 스토리 제작 가능 깔끔하고 다양한 스타일 영상 제작 가능 $0~35

Hailuo 슬라이드 기반 교육 콘텐츠 자동 영상화, 자막+음성+BGM 포함 문서-영상 전환에 용이 $0~35

Midjourney 고품질 이미지 생성 영상 썸네일, 배경, 캐릭터 컷 활용에 적합 $0~35

Runway 영상 클립 편집, 음성 변조, 스타일 전환 등 생성형 영상 편집 AI 영상 흐름 보정, 효과 추가에 유용 (후반 작업용) $0~35

Heygen 실제 인물형 AI 아바타, 다국어 리핑 싱크 우수 글로벌 온보딩/리더 대상 영상에 효과적 $0~29

Hedra 캐릭터 + 배경 + 내레이션을 AI가 자동 생성 캐릭터 기반 설명 영상에 적합, 스크립트 중심 제작에 강점 $0~30

Capcut 직관적 인터페이스의 영상 편집 툴! 템플릿 다양 초보자도 쉽게 클립 편집 가능, SNS 스타일 영상 연출에 유리 $0~14

ChatGPT 스크립트 작성, 슬라이드 구조 설계, 내레이션 대본 자동화, 이미지 생성 다른 툴과 연계해 전체 영상 설계 가능 $0~3

2단계) 평가 기준 수립

QA팀답게 명확한 평가 매트릭스를 만들었습니다.

구분 한국어 자연스러움 (30점) 시각적 완성도 (25점) 작업 효율성 (20점) 확장성 (15점) 비용 효율 (10점)

구분 - TTS 발음 정확도
- 억양 및 호흡
- 전문용어 처리 - 아바타 자연스러움
- 립싱크 정확도
- 화면 구성 자유도 - 학습 곡선
- 협업 가능 여부
- 렌더링 속도 - 구독료
- 사용량 제한
- 무료 기능 범위 - 향후 콘텐츠 제작 재사용 가능성
- 템플릿화 가능성

3단계) 실전 테스트

하나씩 테스트하며 평가해보니 각각의 장단점이 확실했습니다. 그리고 실제로 몇장을 샘플로 만들어보니 단일 툴보다는 3개 내외의 툴을 조합해 제작 효율을 높이는 방식이 현재 상황에서 가장 적합하다는 결론을 내리게 되었습니다. 그래서 아래 두 가지 조합으로 데모 작업에 착수했습니다.

AI 툴을 조합해 최고의 방법 찾기

두 조합을 사내 동료 5명에게도 보여준 후 피드백을 받았는데, 더 우수한 품질의 조합B가 제작 시간은 더 걸리지만 교육적 효과는 압도적으로 높았습니다. 이번 교육 영상의 목적이 "구성원이 인시던트 프로세스를 정확히 이해하는 것"이므로 최종적으로 조합 B를 선택했습니다. 확실히 이 2주간의 실험을 통해 "AI는 만능 도깨비라, 알아서 다 해준다"라는 환상에서 벗어나 단일 AI 툴의 한계를 깨달았습니다. 툴마다 강점이 다르다 보니 전략적 조합이 필수였습니다. 비록 제작 시간에 투자가 필요하긴 했지만 한번 조합을 확정하면, 이번에 구축한 파이프라인으로 향후 모든 테크팀 교육 콘텐츠에 활용할 수 있을 거라는 확신이 들었습니다. 이제 이 조합으로 최종 영상을 구체적으로 어떻게 만들었는지, 각 단계별로 그 과정을 상세히 공유하겠습니다.

⚙️ 제작 파이프라인: AI 툴 조합으로 완성하기

영상 제작 플로우

구분 Step 01 Step 02 Step 03 Step 04

제작기간 2주 1주 1주 2일

참여인원 2명 2명 2명 1명

작업 시간 (1인) 6시간 2시간 3시간 2시간

사용 툴 수기 AI STUDIOS Vrew AI STUDIOS

최종 산출물 126페이지 PPT AI 아바타 AI로 목소리 삽입 인사장면 삽입

PPT 제작: 콘텐츠 구조화

여러가지 방식을 시도해본 결과, 결국 정보 전달에 가장 적합한 도구는 PPT였습니다. 회사에서 이미 사용 중인 공식 템플릿이 있었고, 로고 라이브러리와 디자인 가이드가 정리되어 있어 일관성 확보와 함께 대외 공유에도 즉시 활용 가능한 수준이었습니다. AI로 PPT 초안을 생성하는 Gamma도 테스트해봤지만, 결과물이 우리의 요구사항과 맞지 않았습니다. 올리브영의 브랜드 컬러, 폰트, 레이아웃 가이드를 AI가 완벽히 따르기는 어려웠고, 결국 수동으로 하나씩 만드는 것이 더 빠르고 정확했습니다. 그러다 보니 디자인 감각이 부족한 저희에게 PPT로 제작된 회사 템플릿은 최고의 파트너였습니다.

챕터 내용 핵심 메세지

1. 인시던트와 레벨 선언 인시던트 정의, 선언시점, 초기선언 원칙 1시간 이내 선언, 영향도가 불확실하면 최대 손실 기준으로 선언

2. 인시던트 레벨 정의 Level 0~3 개요 및 선언 기준 요약 각 레벨의 핵심 판단 기준 숙지

3. 온/오프라인 판단 기준 세부 기준 제시 (시간, 손해금액, 건수 등 영향도) 명확한 수치 기준으로 즉시 판단

4. 보고 체계 원칙 초기 보고, 최종 보고, 보고자/피보고자 역할 레벨별 보고 프로세스 준수

5. 재발방지대책 후속관리 절차, 조치기한, 추적 방법 인시던트는 종료가 아닌 개선의 시작

그런데 PPT를 영상으로 변환할 때 가장 큰 난관이 발생했습니다. 바로 애니메이션 처리 부분이었습니다. 일반적인 PPT에서는 한 슬라이드 안에서 텍스트나 이미지가 순차적으로 나타나도록 애니메이션을 설정합니다. 하지만 AI Studios나 Vrew 같은 영상 툴은 각 슬라이드를 하나의 정적 이미지로만 인식합니다. 그래서 애니메이션마다 슬라이드를 분할해 강조 포인트를 추가하니 원래 45페이지였던 PPT가 126페이지로 증가했습니다.😱 한 장면의 강조를 위해 슬라이드 한 장을 더 만드는 고통… 공감하시죠? 하지만 영상에서 시청자의 시선을 정확히 유도하기 위해서는 필수적인 과정이었습니다. 이렇게 완성된 PPT는 그 자체로도 훌륭한 교육 자료였지만, "몰입력 있는 교육"으로 만들기 위해서는 시각적, 청각적 요소가 필요했습니다.

시각화 및 아바타 합성

단순한 나레이션이 깔린 슬라이드쇼보다, 사람이 설명하는 느낌을 주는 영상이 집중도를 훨씬 높인다는 것은 많은 연구에서 입증되었습니다. 이를 "Personification Effect(의인화 효과)"라고 합니다. 하지만 실제 사람이 126페이지 분량을 촬영하려면 스튜디오 대관, 전문 촬영 장비, 전문 강사 또는 아나운서 섭외, 지원 인력 투입, 편집, 시사 등 여러 제약이 존재하죠. 그런데 AI 아바타가 있으면 촬영 없이 스크립트만으로 생성이 되고, 수정이 간편하며, 일관된 톤과 표정을 유지할 수 있습니다. 필요하다면 다국어 지원도 가능해 영어 또는 중국어 등 다양한 버전으로 제작도 가능합니다.

물론 시중에 좋은 AI 영상 툴이 많았지만 저희 콘텐츠에는 치명적인 문제가 있었습니다. 외국인 아바타에 한국어 음성을 입히면 어색하고 립싱크 또한 불일치하여 한국인과 비슷한 아바타를 보유한 툴이 많지 않았습니다. 애니메이션풍 캐릭터도 많았으나 급격한 몰입감 저하로 선호도가 낮았으며, 대부분 한국어 발음이 부자연스럽고 전문용어를 오독하기도 했습니다.

반면 AI Studios(DeepBrain AI)는 다른 툴에서 아쉬웠던 문제를 대부분 해결했습니다. 실사 기반 한국인 아바타 4종 제공, 발음 정확도 90% 이상 체감되는 한국어 TTS 최적화, 립싱크 자동 매칭, 공동 작업이 가능한 편집 기능 등이 만족감을 높였습니다. 특히 협업 기능은 126개 슬라이드를 빠르게 처리하는 데 결정적이었습니다. 하지만 단점 역시 존재했습니다. 예를 들어 “Level 1”을 “레벨 원” 대신 “레벨 하나”로 읽는 경우가 있어, 영어와 숫자는 모두 한글로 변환해야 정확한 발음이 가능했습니다. 또한, 효과음을 지원하지 않아 강조가 필요한 구간은 다른 툴의 도움을 받아야 했습니다.

AI STUDIOS를 사용한 영상 제작과정

음성 클로닝 및 후처리

국내 스타트업 VoyagerX가 개발한 AI 영상 편집 툴 Vrew를 최종 편집 툴로 선택한 이유는 아래와 같습니다.

1️⃣ AI 보이스 학습 기능: 실제 사람의 목소리를 학습해 TTS로 생성 가능
2️⃣ 효과음 및 배경음악 라이브러리: 약 980종 효과음, 270종 배경음악 무료 제공
3️⃣ MP4 파일 병합 및 편집: AI Studios에서 만든 여러 영상을 하나로 합치기

무엇보다 "CTO 등 실제 구성원의 목소리로 교육 영상을 만들 수 있다"는 점이 결정적이었습니다. 왜 구성원의 목소리, 특히 그 중에서도 CTO 목소리가 필요했을까요? 사실 영상 제작 초기부터 어떻게 하면 구성원들이 이 콘텐츠를 끝까지 집중해서 볼지 고민이 컸습니다. 그런데 인시던트 관리는 기술총괄자 CTO님이 가장 중요하게 생각하는 영역입니다. 만약 그러한 CTO님이 직접 설명한다면, 구성원들은 "이건 정말 중요한 내용이구나"라고 인식할 것입니다. 이를 조직 심리학에서는 "Authority Principle(권위 원칙)"이라고 합니다. 하지만 현실적으로 CTO가 15분 분량을 직접 녹음하기는 어렵습니다. 스크립트 숙지, 일정 조율, 촬영 준비, NG를 포함한 실제 녹음 등에 투입해야 할 시간이 너무 많기 때문입니다.

그런 상황에서 Vrew의 음성 학습 기능이 이 문제를 해결했습니다. 단 10분의 녹음으로, 수십장 분량의 나레이션을 CTO 목소리로 만들 수 있었습니다. 이에 CTO님께 Vrew에서 제공하는 30개 표준 문장을 읽어주시면 AI가 음성을 학습해 영상에 적용할 수 있다고 요청했고, 흔쾌히 승낙을 해주셔서 CTO 집무실에서 녹음을 진행할 수 있었습니다.

하지만 완벽해 보이는 Vrew에도 단점이 있었습니다. AI Studios처럼 하나의 프로젝트를 여러 명이 실시간으로 편집할 수 없어, 다음과 같이 작업을 분담했습니다. 각자 맡은 파트를 따로 작업한 후 각각의 영상을 합치는 방식으로 진행했습니다. 이렇게 병합하면 하나의 통 파일로 변환되기 때문에 이미지, TTS, 효과음 중 하나라도 수정이 필요하면 처음부터 다시 만들어야 했습니다. (하나라도 틀리면 다시 처음부터… 절대 안돼😭) 따라서 병합 전 철저한 검수가 필수였습니다. 우리는 2인이 각각 2회씩, 총 4회의 전체 시청 검수를 진행했습니다.

vrew를 사용한 영상 제작과정

실사 삽입 및 최종

영상 제작이 거의 완료된 시점에서, 우리는 한 가지를 더 고민했습니다. AI로 만든 영상은 물론 투자 대비 완성도가 높지만, 뭔가 '사람의 온기'가 부족하지 않을까 하는 고민을요. YouTube 분석에 따르면, 시청자는 첫 10초 안에 영상을 계속 볼지 말지 결정한다고 합니다. AI 아바타로 시작하는 것도 나쁘지 않지만, 실제 CTO가 직접 등장해 인사를 건네는 장면이 있다면 훨씬 강력한 인상을 줄 수 있고 그 첫 10초가 시청률을 결정한다고 생각했습니다. 이에 CTO님께 다시 한 번 협조를 구해, 약 10초 분량의 인트로 영상을 촬영했습니다. 그렇게 만들어진 실사 인트로와 Vrew에서 만든 영상을 합치는 작업은 Adobe Premiere Pro에서 진행했습니다.

Adobe Premiere Pro를 사용한 영상 제작과정

영상을 배포하기 전, QA팀답게 아래의 체크리스트를 기반으로 철저한 품질 검증을 진행했습니다

항목 세부 내용 결과

정확성 모든 수치와 기준이 최신 가이드와 일치하는가 ✅ 검증 완료

일관성 용어 표기가 통일되어 있는가 ✅ 통일 완료

가독성 글자 크기와 적절한가, 아바타가 글자를 가리진 않는가 ✅ 조정 완료

음질 음성이 명확하게 들리는가, 잡음이 없는가 ✅ 문제없음

타이밍 나레이션과 화면 전환이 자연스러운가 ✅ 동기화 완료

효과음 효과음이 과하거나 부족하지 않은가 ✅ 적절함

오타/오독 자막 오타, 음성 오류 없는가 ✅ 2건 수정

재생 다양한 기기에서 정상 재생되는가 ✅ 테스트 완료

🧚‍♀️ 제작한 교육 영상을 구성원에게 전달하기까지

그렇게 영상을 완성하고 나니, 다음 고민이 생겼습니다. "이걸 어디에 올려야 구성원들이 진짜로 잘 볼까?" 이 질문에 대한 답으로 단순히 영상을 업로드하는 것만으로는 부족했습니다. 누가 시청했는지 확인할 수 있고, 적당한 '강제성'을 부여할 수 있는 플랫폼이 필요했습니다. 아무리 좋은 콘텐츠라도 '자율 시청'에만 의존하면 놓치는 사람이 생기기 마련입니다. 특히 인시던트 기준처럼 전 구성원이 반드시 숙지해야 하는 내용은 더욱 그렇습니다. 그래서 올리브영에서 사용 가능한 교육 콘텐츠 배포 채널을 비교했습니다.

영상 업로드를 위한 플랫폼 비교

최종 선택한 "올리브라운지"는 올리브영 구성원만 이용할 수 있는 사내 커뮤니케이션 플랫폼으로 공지, 사내방송, 교육, 공모 등 다양한 콘텐츠를 공유할 수 있습니다. 특히 시청 현황 확인 기능이 있어 교육 이행률을 실시간으로 관리할 수 있어 선택에 결정적이었습니다. 또한 이번 교육은 인시던트에 직·간접적으로 영향을 미치는 구성원들을 대상으로 진행된 만큼, 높은 참여가 중요했습니다. 이에 시청 완료율 목표를 90%로 잡았고, 올리브라운지를 통해 안내와 독려가 자연스럽게 이루어지면서 최종 95%라는 기대 이상의 완료율을 달성할 수 있었습니다. 이러한 성과 덕분에 아래와 같은 긍정적인 보이스도 들을 수 있었습니다.

올리브라운지에 영상 업로드

🧔🏻‍♂️ B님: "이번 교육 영상에서 가장 인상 깊었던 부분은 바로 CTO님의 목소리였습니다. 너무 자연스러워서 순간 "진짜 녹음하신 건가?" 싶을 정도였죠. 그 덕분에 전달력이 훨씬 강해졌고, 콘텐츠에 집중할 수 있는 몰입도가 한층 높아졌습니다. 게다가 헷갈릴 수 있었던 레벨 구분도 화면 구성이 깔끔해서 이해하기가 훨씬 쉬웠어요. 듣는 재미랑 보는 재미가 동시에 살아 있어서, 교육 영상이라기보단 잘 만든 콘텐츠 보는 느낌이었어요😀"

👩🏼 S님: "단순히 테스트만 하는 팀을 넘어 조직 구성원들이 인시던트에 대해 공통된 이해를 갖게 하고 서비스 안정성 확보에 적극적으로 참여하도록 주도하려는 의지가 느껴지는 영상이었습니다. 모두가 문제의 심각성을 동일하게 인식하고 즉시 대응할 수 있는 좋은 가이드가 될 것 같습니다! 앞으로도 좋은 품질 문화를 널리 전파해주세요~!"

👱🏼‍♀️ G님: "대부분의 교육 영상은 다소 단조로운 음성으로 인해 집중하기 어려운 경우가 많은데, 이번 영상은 CTO님 목소리가 직접 들어가 있어서 신선하고 더욱 기억에 남았습니다😆 더불어, 인시던트는 관련 담당자가 아니라면 실제 대응 과정을 체감하기 어렵지만, 교육 영상을 통해 프로세스를 구체적으로 이해할 수 있어 많은 도움이 되었어요."

🌱 마치며

이번 인시던트 교육 영상 제작은 올리브영 QA팀에게 분명 새로운 영역으로의 도전이었습니다. 테스트 케이스를 설계하던 손으로 대본을 다듬고, 리포트 검증에 집중하던 눈으로 영상의 컷 편집을 맞추는 과정은 낯설었지만, 그만큼 신선하고 즐거운 경험이었습니다. 이 경험을 통해 우리가 얻은 가장 큰 인사이트는 '좋은 품질은 결국 이해에서 시작된다'는 확신입니다. 딱딱한 문서나 구두 전달에 의존하던 인시던트 정의와 레벨 기준이 영상이라는 새로운 형태로 전환되자, 구성원들의 반응도 평소와는 달랐습니다. 복잡한 규정도 쉽고, 자연스럽게 조직 전체의 공통 언어로 자리 잡을 수 있다는 가능성이 엿보였습니다.

또한, AI의 실용적인 힘을 체감하는 계기가 되기도 했습니다. AI 아바타, 음성 합성 기술은 촬영, 편집, 녹음 등의 기술적 장벽을 효과적으로 제거하여, QA 엔지니어가 직접 '전달 방식의 혁신'에 집중할 수 있는 환경을 만들어주었습니다. 하지만 중요한 것은 "무엇을, 어떻게 전달할 것인가"라는 콘텐츠 기획 및 스토리텔링 역량은 여전히 사람, 즉 우리의 몫이라는 점입니다. AI는 훌륭한 도구이지만, 전달하려는 품질의 본질을 설계하는 것은 QA팀의 역할입니다.

이처럼 올리브영 QA팀은 이제 단순한 '품질 검증' 조직을 넘어, '품질 문화 전파'를 주도하는 조직으로 그 영역을 확장해 나가고자 합니다. 앞으로도 새로운 기술과 방식을 적극적으로 탐색하여, 서비스의 완성도를 높이고 모두가 공감하는 품질 문화를 만들어 가겠습니다. 다음번 QA팀의 도전도 많이 기대해주세요! 감사합니다.

iframe으로 웹앱 통합했더니 토큰 요청이 폭발했다

Mon, 08 Dec 2025 10:00:00 GMT

안녕하세요. 올리브영에서 프론트엔드 개발을 담당하고 있는 그냥 잇츠테드입니다.

저희 팀은 올리브영의 새로운 성장 동력인 리테일 미디어 사업 확대를 위해, 광고 파트너 오피스 시스템을 기존 플랫폼과 매끄럽게 통합하는 프로젝트를 맡았습니다.

목표는 명확했습니다. 부모 애플리케이션에서 자식 애플리케이션을 iframe으로 임베드하되, 사용자가 두 번 로그인하지 않도록 인증을 공유하는 것이었죠.

자식 애플리케이션에는 자체 인증 시스템이 없었기 때문에, 부모 애플리케이션의 인증 토큰을 안전하게 공유하는 방법이 필요했습니다.

간단해 보였던 이 과제는 생각보다 복잡했습니다.

동시에 쏟아지는 토큰 요청, 401 에러의 연쇄 폭발, 무한 재시도 루프까지. 이를 하나씩 해결하며 안정적인 인증 시스템을 만들어낸 과정을 공유합니다.

이런 분들께 도움이 될 거예요.

iframe을 사용한 마이크로프론트엔드 아키텍처를 구현하는 개발자

크로스 오리진 환경에서 안전한 토큰 관리가 필요한 분

401 에러가 동시 다발적으로 발생하는 문제를 겪고 계신 분

postMessage API의 실전 활용 사례가 궁금한 분

postMessage API를 활용해 이 문제를 어떻게 해결했는지, 그리고 예상치 못했던 4가지 난관과 해결 과정을 공유합니다.

TL;DR

iframe 환경에서 postMessage를 활용해 안전한 토큰 기반 인증 시스템을 구현했습니다.

핵심 포인트:

✅ 동시 10개 요청 → 1개로 최적화 (Request Queue)

✅ Promise 공유로 401 에러 동시 처리

✅ 쿨다운 메커니즘으로 무한 루프 방지

✅ Origin 검증 + Rate Limiting으로 보안 강화

핵심 코드 (Promise 공유 패턴):

let handling401Promise: Promise<string | null> | null = null; if (handling401Promise) { // 이미 갱신 중이면 같은 Promise 기다림 const newToken = await handling401Promise; } else { // 첫 401만 실제 갱신 수행 handling401Promise = refreshTokensDirect(); }

문제 상황

부모 애플리케이션에서 자식 애플리케이션을 iframe으로 임베드하는 프로젝트가 시작되었습니다. 자식 애플리케이션은 자체 인증 시스템이 없었기 때문에 부모 애플리케이션의 인증 시스템을 활용해야 했고, 저는 이 인증 통신 시스템을 구현하게 되었습니다.

iframe으로 통합하면서 가장 먼저 마주한 질문은 "어떻게 안전하게 인증 정보를 공유할 것인가?" 였습니다. 서로 다른 도메인에서 실행되는 두 애플리케이션 사이에서 토큰을 주고받아야 하는데, 보안을 해치지 않으면서도 안정적으로 작동해야 했습니다.

초기 고민들

처음에는 간단하게 생각했습니다.

"그냥 URL 파라미터로 토큰 넘기면 되지 않을까?"

"localStorage는 같은 도메인에서만 공유되니까 안 되겠구나..."

"Cookie는? 🤔 SameSite 정책 때문에 복잡해질 것 같은데..."

내부 검토 및 기술 논의를 거쳐, 위 문제들을 가장 안전하고 유연하게 해결할 수 있는 postMessage API를 사용하기로 결정했습니다.

왜 postMessage인가?

postMessage는 서로 다른 출처(origin) 간에 안전하게 메시지를 주고받을 수 있는 Web API입니다.

💡 Origin(출처)이란? 웹사이트의 프로토콜(https), 도메인(example.com), 포트번호를 합친 것입니다. 예를 들어 https://parent.com과 https://child.com은 도메인이 다르므로 서로 다른 origin입니다. 보안상 브라우저는 기본적으로 다른 origin 간의 데이터 접근을 차단합니다.

제가 postMessage를 선택한 이유는 다음과 같습니다.

보안성: Origin 검증을 통해 신뢰할 수 있는 출처만 통신 가능

유연성: 복잡한 데이터 구조(객체, 배열 등)도 전달 가능

표준 API: 별도 라이브러리 설치 없이 바로 사용 가능

양방향 통신: 부모↔자식 양쪽 모두 메시지 송수신 가능

URL 파라미터로 토큰을 넘기는 방법은 브라우저 히스토리에 노출되어 보안상 위험하고, Cookie는 SameSite 정책 때문에 크로스 오리진에서 제약이 많습니다. postMessage는 이런 문제 없이 안전하고 유연하게 통신할 수 있는 최적의 선택이었습니다.

기본 구조 설계

먼저 간단한 구조부터 만들어보았습니다. 자식 iframe이 부모에게 토큰을 요청하면, 부모가 자신의 토큰을 전달하는 방식입니다.

부모 뷰

// hooks/useIframeAuth.ts export const useIframeAuth = (iframeRef: RefObject<HTMLIFrameElement>) => { useEffect(() => { const handleMessage = (event: MessageEvent) => { // Origin 검증 if (event.origin !== CHILD_ORIGIN) return; const { type } = event.data; if (type === 'GET_PARENT_TOKEN') { const token = getToken('token'); const refreshToken = getToken('refresh_token'); // 토큰 전송 iframeRef.current?.contentWindow?.postMessage( { type: 'PARENT_TOKEN', token, refreshToken, }, event.origin ); } }; window.addEventListener('message', handleMessage); return () => window.removeEventListener('message', handleMessage); }, [iframeRef]); };

자식 뷰 (iframe)

// 토큰 요청 const requestToken = (): Promise<TokenResponse> => { return new Promise((resolve, reject) => { const handleMessage = (event: MessageEvent) => { if (event.data?.type === 'PARENT_TOKEN') { window.removeEventListener('message', handleMessage); resolve({ token: event.data.token, refreshToken: event.data.refreshToken, }); } }; window.addEventListener('message', handleMessage); window.parent.postMessage({ type: 'GET_PARENT_TOKEN' }, '*'); }); };

여기까지는 순조로웠습니다. 기본적인 토큰 전달은 잘 작동했습니다. 하지만 실제 서비스에 적용하려고 하자 예상치 못한 문제들이 하나씩 나타나기 시작했습니다.

첫 번째 난관: 동시 다발적인 API 호출

컴포넌트가 마운트되면서 여러 API가 동시에 호출되는 상황이 발생했습니다. 문제는 각 API 요청마다 부모에게 토큰을 요청하면서 불필요한 중복 요청이 발생한다는 것이었습니다. 10개의 API가 동시에 호출되면 부모에게도 10번의 토큰 요청이 날아갔고, 같은 토큰을 10번 반복해서 받아오는 비효율이 발생했습니다.

해결 방법. Request Queueing

첫 번째 요청만 실제로 처리하고, 나머지는 큐에 넣어서 결과를 공유하도록 했습니다.

const isHandlingTokenRequest = useRef(false); const pendingTokenRequests = useRef<PendingTokenRequest[]>([]); const handleTokenRequest = async (messageType: string) => { // 이미 처리 중이면 큐에 추가 if (isHandlingTokenRequest.current) { return new Promise((resolve, reject) => { pendingTokenRequests.current.push({ resolve, reject, messageType }); }); } isHandlingTokenRequest.current = true; try { // 토큰 획득 const token = await getValidToken(); // 원본 요청 응답 sendTokenResponse(token); // 큐에 대기 중인 요청들도 같은 토큰으로 응답 const queuedRequests = [...pendingTokenRequests.current]; pendingTokenRequests.current.length = 0; queuedRequests.forEach(({ resolve }) => { sendTokenResponse(token); resolve(token); }); } finally { isHandlingTokenRequest.current = false; } };

이렇게 하니 10개의 요청이 동시에 와도 실제로는 1번만 토큰을 갱신하게 되었습니다!

📊 개선 효과

동시 API 호출 시 불필요한 토큰 요청 95% 감소

네트워크 부하 감소로 평균 응답 속도 향상

서버 토큰 발급 API 호출 횟수 대폭 절감

두 번째 난관: 401 에러 폭탄

첫 번째 문제를 해결하고 나니 더 심각한 문제가 드러났습니다. 토큰이 만료되어 여러 API가 동시에 401 에러를 받으면서 각자 토큰 갱신을 시도하는 상황이었죠. 5개의 API가 동시에 실패하면 5번의 토큰 갱신 요청이 발생했고, 이는 서버 부하는 물론 경합 상태(race condition)를 유발했습니다.

Request A → 401 ─┐ Request B → 401 ─┼→ 동시에 토큰 갱신 시도? 😱 Request C → 401 ─┘

시행착오 1: 단순 플래그로 제어

처음에는 간단하게 플래그 하나로 제어하려고 했습니다.

let isRefreshing = false; if (error.response?.status === 401) { if (isRefreshing) return; // 이미 갱신 중이면 무시 isRefreshing = true; await refreshToken(); isRefreshing = false; }

하지만 이 방법은 갱신이 완료되기 전에 들어온 요청들은 그냥 실패하게 됩니다.

해결 방법: Promise 공유

모든 401 에러가 하나의 갱신 작업을 공유하도록 수정했습니다. 첫 번째 401 에러만 실제 토큰 갱신을 수행하고, 나머지 요청들은 그 갱신 작업이 완료될 때까지 기다립니다. 갱신이 완료되면 대기 중이던 모든 요청이 새 토큰을 받아 자동으로 재시도됩니다.

let handling401Promise: Promise<string | null> | null = null; // Response Interceptor interceptor.response.use( (response) => response, async (error) => { if (error.response?.status === 401) { const originalRequest = error.config; // 이미 갱신 중이면 그 Promise를 기다림 if (handling401Promise) { const newToken = await handling401Promise; originalRequest.headers['Authorization'] = `Bearer ${newToken}`; return axios(originalRequest); } // 첫 번째 401만 실제 갱신 작업 수행 handling401Promise = (async () => { try { const result = await refreshTokensDirect(); return result?.token || null; } finally { handling401Promise = null; } })(); const newToken = await handling401Promise; originalRequest.headers['Authorization'] = `Bearer ${newToken}`; return axios(originalRequest); } return Promise.reject(error); } );

이제 여러 요청이 동시에 401을 받아도 하나의 갱신 작업만 수행됩니다. 대기 중이던 요청들은 갱신이 완료되면 새 토큰을 헤더에 담아 원래 요청을 자동으로 재시도합니다. 사용자는 에러를 전혀 느끼지 못하고, 서버 부하도 최소화됩니다.

세 번째 난관: Refresh Token도 만료되면?

토큰 갱신 로직을 구현하면서 또 다른 케이스를 발견했습니다. Refresh Token마저 만료된 경우입니다. 이 경우 재로그인이 필요한데, 이걸 어떻게 처리할까요?

에러 코드 분리

ACCESS_TOKEN_EXPIRED: Access Token 만료 → 갱신 시도

REFRESH_TOKEN_EXPIRED: Refresh Token 만료 → 재로그인 필요

if (error.response?.status === 401) { const errorCode = error.response?.data?.code; // Refresh Token 만료 if (errorCode === 'REFRESH_TOKEN_EXPIRED') { clearToken('token'); clearToken('refresh_token'); // 부모에게 인증 실패 알림 if (environmentState?.isIframe) { window.parent.postMessage({ type: 'AUTHENTICATION_FAILED' }, '*'); } return Promise.reject(error); } // Access Token 만료 - 갱신 시도 if (errorCode === 'ACCESS_TOKEN_EXPIRED') { // ... 토큰 갱신 로직 } }

부모 뷰에서는 이 메시지를 받으면 전체 페이지를 새로고침하여 재로그인 플로우로 진입합니다.

// 부모 뷰 if (type === 'AUTHENTICATION_FAILED') { console.error('[PARENT] Authentication failed, clearing tokens'); clearToken('token'); clearToken('refresh_token'); window.location.reload(); }

네 번째 난관: 무한 재시도 방지

토큰 갱신이 실패했을 때 무한히 재시도하면 서버에 부하를 줄 수 있습니다. 이를 방지하기 위해 쿨다운 메커니즘을 도입했습니다.

const tokenRefreshState = { failedAttempts: 0, lastFailureTime: 0, maxRetries: 3, cooldownMs: 5000, // 5초 }; // 갱신 시도 전 쿨다운 체크 const timeSinceLastFailure = Date.now() - tokenRefreshState.lastFailureTime; if ( tokenRefreshState.failedAttempts >= tokenRefreshState.maxRetries && timeSinceLastFailure < tokenRefreshState.cooldownMs ) { console.warn('[AXIOS] Token refresh in cooldown period'); return Promise.reject(error); } // 갱신 시도 try { await refreshToken(); tokenRefreshState.failedAttempts = 0; // 성공 시 리셋 } catch (error) { tokenRefreshState.failedAttempts++; tokenRefreshState.lastFailureTime = Date.now(); }

3번 연속 실패하면 5초 동안 재시도를 막습니다. 서버도 보호하고 불필요한 요청도 줄일 수 있었습니다.

전체 통신 흐름

최종적으로 완성된 통신 흐름은 다음과 같습니다.

iframe 로드: 부모로부터 토큰 요청

API 호출: 토큰을 헤더에 담아 전송

401 발생: 동시성 제어 후 토큰 갱신

갱신 완료: 부모와 동기화 후 재시도

인증 만료: 재로그인 플로우

보안 고려사항

개발 중에는 편의를 위해 Origin 검증을 비활성화했지만, 프로덕션에서는 반드시 활성화해야 합니다.

// ❌ 개발 중 (임시) // if (event.origin !== ADORA_ORIGIN) return; // ✅ 프로덕션 const ALLOWED_ORIGINS = [ 'https://your-iframe-domain.com', 'https://your-parent-domain.com', ]; if (!ALLOWED_ORIGINS.includes(event.origin)) { console.error('[PARENT] Invalid origin:', event.origin); return; }

또한 Rate Limiting을 추가하여 악의적인 공격도 방어했습니다:

const REQUEST_RATE_LIMIT = 10; // 초당 최대 10개 const REQUEST_WINDOW = 1000; // 1초 if (requestCount.current > REQUEST_RATE_LIMIT) { throw new Error('Too many token requests'); }

마무리

"그냥 토큰 하나 전달하면 되겠지"라고 생각했던 과제는 생각보다 복잡했습니다. 동시성 제어, 자동 재시도, 무한 루프 방지, 보안까지. 하나씩 해결하면서 안정적인 인증 시스템을 만들 수 있었습니다.

주요 해결 방법 요약

✅ 동시성 제어 → Request Queue + Promise 공유

✅ 자동 재시도 → Axios Interceptor 활용

✅ 무한 루프 방지 → 쿨다운 메커니즘 (3회/5초)

✅ 보안 → Origin 검증 + Rate Limiting

✅ 상태 동기화 → 부모-자식 토큰 일치 보장

핵심 교훈

1. 동시성은 예상보다 복잡하다

여러 API가 동시에 401을 받는 상황은 단순 플래그로 해결되지 않았습니다. Promise를 공유하는 패턴이 핵심이었죠. 처음엔 "이미 갱신 중이면 무시"하는 방식으로 접근했다가, 대기 중인 요청들이 실패하는 문제를 겪었습니다. 결국 모든 요청이 하나의 갱신 작업을 공유하도록 만들어 해결했습니다.

2. 사용자 경험이 최우선이다

기술적 구현도 중요하지만, 사용자가 인증 오류를 느끼지 않도록 하는 것이 가장 중요했습니다. 토큰이 만료되어도 자동으로 갱신하고 재시도하기 때문에, 사용자는 로그인 상태가 끊김없이 유지된다고 느낍니다.

3. 보안은 프로덕션에서 필수이다(당연하지만!)

개발 중에는 편의를 위해 Origin 검증을 비활성화했지만, 프로덕션에서는 반드시 활성화해야 합니다. 악의적인 사이트가 우리 토큰을 요청하는 것을 막으려면 Origin 검증과 Rate Limiting이 필수입니다.

iframe 환경에서 인증 통신을 구현하면서 마주쳤던 문제들과 해결 과정을 공유해 봤습니다. 비슷한 과제를 하시는 분들께 시행착오를 줄이는 데 도움이 되었으면 좋겠습니다. 더 나은 방법이나 궁금한 점이 있으시다면 댓글로 공유해 주세요!

참고 자료

MDN - Window.postMessage()

JWT 토큰 인증

배달대행사 API 연동과 장애 대응 - 오늘드림 서비스 개발기

Mon, 01 Dec 2025 10:00:00 GMT

오늘 주문하면 오늘 받는 오늘드림 서비스, 이를 위해 뒤에서는 얼마나 바쁘게 돌아갈까요?

안녕하세요. 올리브영 배송 및 물류 스쿼드에서 백엔드 개발을 담당하고 있는 맹곰이입니다.✌️

올리브영은 택배 배송과 오늘드림 두 가지 배송 서비스를 제공하고 있는데요. 이 중 택배 배송과 관련 있는 물류시스템과 데이터 전송 방식은 "올리브영 물류시스템에서는 데이터를 어떻게 주고 받을까?"라는 제목으로 지난 해에 소개드렸습니다.

오늘은 물류시스템만큼 많은 트래픽을 발생하는 오늘드림 서비스에서 외부 배달대행사와 API 통신을 통해서 데이터를 주고 받는 부분을 소개해드리려고 찾아왔습니다! 또한, 배달대행사와 안정적으로 연동하기 위한 API 설계전략과, 실제 운영 중 겪었던 트랜잭션 장애 사례를 공유합니다.

올리브영 택배배송

올리브영 오늘드림

오늘드림

우선 다들 아시겠지만 오늘드림부터 간단히 소개해 드릴게요. 오늘드림을 한줄로 표현해보면, 원하는 상품을 당일에 빠르게 배송 받을 수 있는 즉시배송 서비스입니다.

오늘드림은 빠름 배송 기준, 보통 1시간 이내로 여러분의 집으로 도착을 하는데요. 이렇게 빠르게 배송이 가능한 이유는 전국 여기저기에 올리브영 매장이 여러분 집 주변에 있기도 하지만, 빠르게 배송을 해주는 배달대행사도 한 몫을 하고 있습니다. 오늘은 이 배달대행사와 데이터를 주고 받는 부분을 소개해드리려고 합니다.

올리브영과 배달대행사간의 API 호출

시스템 간에 데이터를 주고 받는 방법은 저번 시간에 소개해드린거 처럼 여러가지 방법이 있는데요. 배달대행사와 데이터를 주고 받는 부분은 API를 사용해서 연동을 했습니다.

여러분이 오늘드림으로 주문하면 매장에서 상품 포장이 완료되면 배달대행사를 호출하게 되는데요. 올리브영은 배달대행사와 긴밀한 API 연동을 통해 '오늘드림' 서비스를 운영합니다. 이 연동은 크게 두 단계로 이루어집니다.

올리브영 -> 배달대행사 API 호출 : 고객의 주문이 접수되고 매장에서 상품 포장이 완료되면, 올리브영 시스템은 배달대행사 주문 접수 API를 호출하여 배송을 요청합니다.

배달대행사 -> 올리브영 API 호출 (콜백) : 배달대행사는 라이더 배차, 상품 픽업, 배송 완료 등 배송상태가 업데이트 될 때마다 올리브영 API를 호출하여 그 정보를 전달합니다.

오늘드림 주문 배달대행사 접수 API

우선 올리브영에서 호출하는 배달대행사 주문 접수 API 연동부터 살펴볼까요? API는 상황에 따라서 여러 문제가 발생할 수 있는데요. Read Timeout, Connection Timeout, 서버 에러, 클라이언트 에러 등 여러 문제가 있습니다. 이 에러들을 재시도하면 성공할 수 있을지 여부에 따라서 나누어서 생각해보려고 합니다.

해당 개념을 쉽게 이해하도록 Read Timeout, Connection Timeout을 간단하게 전화에 비유해서 표현해 볼게요.

Read Timeout : 전화를 걸어 상대방이 받았으나, 일정 시간 동안 상대방이 응답이 없어 내가 끊어버린 경우

Connection Timeout : 전화를 걸었으나, 일정 시간동안 상대방이 받지를 않아 내가 끊어버린 경우

Read Timeout, Connection Timeout, 서버 에러

Read Timeout, Connection Timeout 등의 에러는 일시적으로 발생하는 에러로 대부분 잠시 후에 재시도할 경우 에러가 발생하지 않는 케이스입니다. 그렇기에 이러한 케이스는 내부적으로 잠시 후 재시도하도록 처리했습니다.

그러나 여기서 Read Timeout은 중복처리의 문제가 있을 수도 있습니다. 클라이언트 입장에서는 Timeout으로 주문 접수 실패로 판단했지만, 서버인 배달대행사에는 설정된 Timeout값보다 오래 걸렸지만 접수가 처리된 경우도 있죠.

다행히 대부분의 배달대행사에서는 똑같은 주문번호로 접수를 하게 되면 중복접수로 응답을 하는 기능이 있습니다. 중복접수 응답이 오면 내부적으로는 접수성공으로 판단을 하여 해당 문제를 해결하고 있습니다.

그리고 서버 에러의 경우에는 일시적인 에러일수도 있지만, 그렇지 않은 경우도 있습니다. 그렇지 않는 경우라 함은, API를 호출하면 서버에서 지속적으로 에러로 응답할 것이고 될 때까지 기다릴수는 없기에... 재시도 횟수 또한 제한 하고 있습니다.

클라이언트 에러

클라이언트 에러는 대부분 다시 시도를 해도 계속해서 에러가 발생할 텐데요. 이러한 경우에는 주문접수를 할 수가 없고 여러분이 주문한 상품을 배달을 할수가 없습니다. 이러한 상황으로는 대표적으로 주소가 잘못되었거나 배달대행사에서 라이더가 부족하다거나 기상악화로 배달을 못 하는 경우가 있습니다.

아래는 주문접수 API 호출 시 사용하는 코드 샘플이며, 주문접수 성공 시에는 http status가 200으로 응답, 중복접수 시에는 409, 잘못된 요청은 400, 서버 에러는 500으로 응답이 온다를 가정했습니다.

webClient.post() .uri("URI 주소") .contentType(MediaType.APPLICATION_JSON) .accept(MediaType.APPLICATION_JSON) .bodyValue(requestDto) .header("Authorization", "인증 값") .retrieve() // 접수성공 .onStatus(HttpStatus::is2xxSuccessful) { response -> response.bodyToMono(ResponseDto::class.java).flatMap { errorBody -> Mono.empty() } } .onStatus(HttpStatus::isError) { response -> response.bodyToMono(ResponseDto::class.java).flatMap { errorBody -> // 중복접수 if (response.statusCode() == HttpStatus.CONFLICT) { logger.info("중복 접수") Mono.empty() } else { when { // 클라이언트 에러 response.statusCode().is4xxClientError -> { logger.info("접수 실패") Mono.empty() } // 서버 에러 else -> { Mono.error( WebClientResponseException( "주문접수 실패", response.rawStatusCode(), response.statusCode().reasonPhrase, response.headers().asHttpHeaders(), errorBody.toString().toByteArray(), null ) ) } } } } } .bodyToMono(ResponseDto::class.java) .block()

오늘드림 콜백 API

다음은 올리브영이 제공하는 배달대행사에서 라이더가 배차가 되고, 상품을 픽업, 배송완료 시 호출하는 API입니다. 이러한 콜백 API는 라이더 배차, 상품 픽업, 상품 배송 완료, 배달 취소 등의 기능으로 구성됩니다.

라이더 배차 : 라이더가 배차가 되었다고 알려주는 기능입니다.

상품 픽업 : 라이더가 상품을 픽업했다고 알려주는 기능입니다.

상품 배송완료 : 라이더가 상품을 배달완료했다고 알려주는 기능입니다.

배달 취소 : 배달을 수행 할 수 없을 때 알려주는 기능입니다.

이 API들은 얼마전에 대규모 리뉴얼을 진행했습니다.

리뉴얼 하게 된 이유

배달대행사마다 같은 기능을 하는 각자 다른 api로 이루어져 있어 하나로 합치자.

리뉴얼을 하게 된 이유는 여러가지가 있지만, 그 중에서도 각기 다른 API로 이루어진 기능을 한 개 API로 통합한 이유는 이렇습니다.

기존에는 제일 처음 도입된 A 배달대행사 전용 콜백 API가 있었습니다. 그리고 B 배달대행사가 추가되면 B 배달대행사에 맞춰서 콜백 API를 개발을 했고, C 배달대행사가 추가되면 C 배달대행사 콜백 API를 개발 했습니다.

이렇게 1개씩 추가되다보니... 동일 기능을 하는 API가 여러개가 되어 관리해야하는 API 숫자가 늘게 되었습니다.

그러다보니 발생하는 문제가 기능 수정 시 여러 API를 수정해야하기에 일부 API에는 누락될 가능성이 많아졌습니다. 또한 내부 로직은 같은 코드 사용하도록 하여 수정은 한곳만 하도록 구현하더라도 테스트는 각각 API를 해야 하기에 시간이 더 많이 필요한 등의 이슈가 있습니다.

이러한 문제점들을 해결하고 관리 효율성을 위해 1개 기능을 하는 API는 1개가 되도록 리뉴얼을 하게 되었습니다!

덕분에 아래 그림처럼 API가 12개에서 4개로 줄어들었고, 운영상에서도 봐야할 지표 및 로그 종료도 그만큼 줄어들어 관리 효율성이 증대되었습니다.

리뉴얼 전후 API 구조

트랜잭션 에피소드

위 그림처럼 배대사 API는 1개로 리뉴얼은 성공적으로 완료되었습니다!! 리뉴얼하면서 발생한 기술적인 에피소드가 하나 있어 추가로 소개해드릴려고 합니다. 개발을 하다보면 많은 에피소드가 있을텐데요. 그중 오늘 소개해드리려는 에피소드로 단 한 줄의 코드 때문에 서버가 멈춰버린 이슈를 풀어보겠습니다.🫢🫣

이는 트랜잭션을 무분별하게 사용하면서 서버에 과부하가 발생한 결과였습니다. 그렇다면 문제의 한 줄이 무슨 내용이었을지 짐작 가시나요?

그 1줄은 UPDATE 쿼리의 트랜잭션 전파옵션입니다.

트랜잭션 전파옵션 간단설명!

REQUIRED : 기존 트랜잭션과 동일한 트랜잭션을 사용합니다.

REQUIRES_NEW : 새로운 트랜잭션을 생성합니다.

트랜잭션 전파옵션 스프링 공식 문서

UPDATE 쿼리를 실행하는 메소드에 트랜잭션 전파옵션을 REQUIRED로 설정했는데, 동일 트랜잭션을 사용할 수 있는 메소드가 있었습니다. 그렇지만 이 메소드의 트랜잭션을 분리해 REQUIRES_NEW로 변경했습니다. 이로 인해 메소드 호출 한 번당 트랜잭션이 기존 대비 2배로 증가하게 되었습니다. 평소에는 동시 트랜잭션 수가 Connection Pool 크기를 넘지 않아 문제가 없었지만, 특정 시간대에 해당 메소드 호출이 급증하면서 상황이 달라졌습니다. Connection Pool 크기를 초과하는 트랜잭션 요청이 발생했고, Connection을 얻지 못한 스레드들이 대기 상태로 쌓이기 시작했습니다. 대기 스레드가 계속 증가하면서 서버에 과부하가 걸리니 결국 서버가 응답하지 않는 상황까지 이어진거죠. (사전에 Connection Pool 용량이 충분한지 계산해봤더라면 이런 상황을 예방할 수 있었을텐데요😭)

다행히 MSA가 적용되어 일시적인 일부 장애로 끝났고 서버 증설로 임시 대응이 가능하였으며, 현재는 트랜잭션 전파옵션을 변경해서 이슈를 해결하였습니다.

마무리

올리브영 오늘드림 주문건수는 계속해서 늘고 있는데요. 그에 비례해서 배달대행사와 연동하는 데이터 양도 많아졌습니다. 또한 이로 인하여 트래픽도 계속해서 늘고 있는데요.

위 사례을 겪으면서 배운 세 가지 교훈을 정리해 볼게요!!

MSA는 왜 해야하는가 : MSA가 적용되어 있어 올리브영 전체 서비스 장애로 이어지지 않았습니다.

트랜잭션 전파옵션의 중요성 : 트랜잭션 전파옵션 1줄로 서버가 멈추는 결과까지 이르게 되었습니다.😭

부하 테스트의 중요성 : 부하 테스트 한번 해보았으면 해당 문제는 배포 전에 발견했을 거 같아요.

여러분의 프로젝트에서도 외부 시스템 연동이나 트랜잭션 관리로 고민하고 계신다면, 이 글이 시행착오를 줄이는 데 도움이 되길 바랍니다.

그럼 전 이만 또 다른 기능을 개발하러 가보겠습니다!!!

감사합니다.

SDUI의 성능 병목을 넘어: 올리브영 로컬 캐시 기반 백엔드 최적화 성공기

Tue, 11 Nov 2025 15:30:00 GMT

들어가며

빠르게 변화하는 이커머스 환경에서, SDUI(Server-Driven UI)는 선택이 아닌 필수가 되어가고 있습니다.

SDUI는 '서버가 주도하는 사용자 인터페이스'라는 뜻으로, 쉽게 말해 스마트폰 앱이나 웹사이트 화면을 구성하는 요소들(버튼, 이미지, 텍스트 배치 등)을 클라이언트(앱/웹 브라우저)가 알아서 만드는 대신, 서버가 '이렇게 만들어라' 하고 설계도(JSON 데이터)를 전달해 주는 방식입니다.

이를 통해, 과거에는 iOS, Android, Web 등 각 플랫폼이 UI 컴포넌트를 개별적으로 구현해야 했지만, 이제는 서버의 UI 구성을 통해 업데이트 없이도 서비스 화면을 실시간으로 바꿔줄 수 있게 되었습니다.

이는, UI 일관성 확보는 물론, 개발 리소스 절감, 비개발자의 직접적인 UI 수정 가능성 등의 이점을 가져왔습니다.

그러나 SDUI의 특성 상 모든 클라이언트가 서버로부터 UI 구성을 요청·수신하기 때문에 API 응답 속도 및 네트워크 지연이 사용자 경험에 직접적인 영향을 미칩니다. 저희 팀 역시 성능 테스트 과정에서 트래픽 증가에 따른 API 지연 문제를 경험했고, 이에 대한 해결 방안으로 로컬 캐시(Local Cache)를 활용한 최적화 전략을 채택했습니다.

이 글에서는 올리브영이 SDUI를 도입하며 겪었던 문제점과, 로컬 캐시 기반의 Backend API 최적화 전략을 통해 어떻게 성능 병목을 해결하고 안정적인 서비스를 구축했는지 그 경험을 상세히 공유하고자 합니다.

올리브영 개발 조직이 특히 더 신경쓰는 기간은 '올영세일' 인데요. 초당 6만 건이 넘는 트래픽 속에서도 응답 속도 1ms 미만을 달성한 사례 기반 SDUI의 도입부터 운영까지, 저희의 시행착오와 실제 서비스로 검증된 해결책이 여러분의 서비스에 큰 도움되기를 바랍니다.

배경: 올리브영이 SDUI를 선택한 이유

개발자라면 한 번쯤 겪어봤을 겁니다. iOS, Android, Web 등 각 플랫폼에서 동일한 UI를 중복으로 구현해야 하는 비효율, 작은 UI 수정에도 앱스토어 배포 과정을 거치며 중요한 마케팅 기회를 놓치는 답답함. 올리브영 역시 빠르게 변화하는 시장과 고객 요구사항 앞에서 이러한 문제들에 직면했습니다.

우리가 겪었던 핵심적인 어려움은 다음과 같았습니다.

비효율적인 개발: 플랫폼별 UI 중복 구현으로 개발 리소스가 낭비되고, 팀의 피로도가 높았습니다.

느린 반영 속도: UI 수정 시 앱스토어 배포가 필수였기에, 시장 변화에 민첩하게 대응하기 어려웠습니다.

일관성 없는 사용자 경험: 플랫폼 간 미묘한 UI 불일치로 브랜드 경험의 일관성이 저해되었습니다.

즉, '어떻게 하면 더 빠르고, 효율적이며, 일관된 사용자 경험을 제공할 수 있을까?'라는 질문에 대한 답으로 SDUI 도입을 결정했습니다.

서버에서 JSON Schema 기반의 UI 컴포넌트 데이터를 제공하고 클라이언트가 이를 렌더링하는 방식은, 앱 업데이트 없이도 실시간으로 UI를 변경할 수 있는 유연성을 제공했습니다.

우리는 SDUI의 잠재력을 확인하고, 우선적으로 올리브영 앱의 핵심 영역인 탭바와 테마 드로워에 도입을 시도하며 새로운 기술 여정의 첫걸음을 내디뎠습니다.

문제 상황: 성능 병목 현상

SDUI 전환 후 '올영세일'과 같은 대규모 트래픽 상황을 모의하기 위해, 실제 서비스 환경과 유사한 조건에서 다음과 같은 시나리오로 테스트를 진행했습니다.

테스트 도구: nGrinder

테스트 환경: N개의 nGrinder 에이전트

테스트 시나리오:

사용자 수: M명의 가상 사용자 동시 접속 테스트 시간: X초 동안 지속 요청 방식: M명의 가상 사용자가 X초 동안 SDUI API에 대해 요청(Request) → 응답(Response) → 다음 요청(Next Request)을 동기 방식으로 반복 수행했습니다. 이는 실제 사용자가 UI를 로드하고 다음 액션을 수행하는 과정을 충실히 모사하여, 서버가 지속적인 부하를 처리하는 능력을 측정하기 위함입니다. 트래픽 목표: 6월 '올영세일' 피크 트래픽의 2배 수준의 부하 생성 측정 지표: API 응답 시간(Response Time), 초당 처리량(TPS), 네트워크 트래픽 등

이러한 테스트 환경과 시나리오를 통해, SDUI Backend API가 실제 대규모 트래픽 상황에 어떤 성능 변화를 보이는지 명확하게 측정할 수 있었고, 아래와 같은 문제를 확인했습니다.

API 응답 속도 저하
'올영세일' 기준 트래픽으로 성능 테스트 시 트래픽으로 인한 P50 서버 응답 시간이 733ms에 따라서 초기 로딩 시간 증가가 발생했습니다.

네트워크 트래픽 증가
동일한 탭바 및 테마드로워 데이터를 대규모 사용자가 반복적으로 요청하다 보니 서버와 캐시인 Redis 사이 구간의 네트워크 트래픽이 증가했습니다.

사용자 경험 악화
API 응답 속도 저하 및 네트워크 트래픽 증가에 따른 응답 지연에 따른 테마드로워 / 탭바 렌더링이 느려지고 사용자 경험이 악화되는 것을 확인했습니다.

즉, 성능 최적화 없이는 SDUI의 장점이 오히려 단점으로 전환될 수 있음을 확인했습니다.

해결 전략: 이중 캐시의 도입

1차 캐시: Caffeine (Local Cache) ➡️ 네트워크 트래픽 감소 및 API 응답 속도 극대화 2차 캐시: Redis (Remote Cache) ➡️ DB로의 부하를 최소화하고, 다중 서버 환경에서 캐시 일관성 유지 3차 저장소: Oracle DB (관계형 데이터베이스) ➡️ 백오피스에서 UI 구성 요소를 관리하는 최종 데이터 원천

1. 캐시 정책

동일 파라미터에 대한 요청은 캐시 응답으로 반환하도록 구현했고, API 단위의 키로 관리했습니다.
(예: commonContents:tabbar::ALL:v2)

2. API 응답 구조 개선

캐시 효율성을 극대화하기 위해 API 설계 단계에서 멱등성(Idempotency)을 보장했습니다.
멱등성은 '동일한 요청을 여러 번 보내도 항상 같은 결과가 반환되는 특성'을 말합니다. 마치 리모컨으로 TV를 켤 때 한 번 누르나 여러 번 누르나 TV는 결국 켜지거나 꺼진 상태를 유지하는 것과 같습니다.
이러한 특성을 통해 동일 입력값에 대하여 항상 동일한 출력이 반환되도록 구조화하여 캐시의 유효성을 높였습니다.

3. 캐시 무효화 전략: 실시간성 확보와 안정성 유지를 위한 투 트랙

캐시는 데이터를 빠르게 제공하는 이점이 있지만, 데이터 변경 시 오래된 데이터(Stale Data) 문제가 발생할 수 있습니다.
SDUI는 UI가 실시간으로 변경되어야 하는 요구사항이 강하므로, 데이터 변경에 따른 캐시 무효화 전략이 매우 중요했습니다. 우리는 두 가지 전략을 조합하여 이를 해결했습니다.

3-1. 백오피스(Back Office) 연동을 통한 즉시 무효화
백오피스에서 SDUI 관련 데이터(예: 탭바 메뉴, 테마 드로워 컨텐츠)를 수정하면, 해당 변경 이벤트를 감지하여 관련된 Redis 캐시를 즉시 삭제하도록 구현했습니다.
이로써 관리자가 UI를 변경하는 즉시 사용자에게 최신 UI가 반영될 수 있도록 했습니다.
또한, 백오피스의 접근은 사내 내부 네트워크에서만 가능하고, 데이터 등록/수정/삭제는 명확한 인증/인가 프로토콜을 통해 등록된 특정 관리자 계정만 데이터 조작을 가능케 제한하여서 캐시 오염 시나리오를 방지하였습니다.

3-2. 주기적인 배치(Batch) 작업을 통한 캐시 갱신
혹시 모를 캐시 누락이나 시스템 오류로 인한 데이터 불일치를 방지하고, 캐시의 안정성을 확보하기 위해 하루에 한 번(일 1회 주기) 배치(Batch) 작업을 실행했습니다.
이 배치는 단순히 캐시를 비우는 것을 넘어, 주요 SDUI 데이터를 미리 조회하여 캐시를 신규 데이터로 사전 캐싱(Pre-warming) 하는 역할도 수행합니다. 이는 시스템 부하가 적은 새벽 시간대에 실행하여, 주간 피크 타임에 콜드 캐시(Cold Cache)로 인한 응답 지연이 발생하는 것을 최소화했습니다.

이 두 가지 전략을 통해 우리는 UI 변경의 실시간성과 캐시 데이터의 안정성이라는 두 마리 토끼를 모두 잡을 수 있었습니다.

4. 아키텍쳐 및 Caffeine 설정

올리브영 SDUI Backend API는 Spring Boot와 Kotlin 기반으로 개발되었으며, 클라이언트 요청 처리부터 데이터 조회까지 효율적으로 분배하기 위해 다음과 같은 계층 구조를 가집니다. 각 계층은 명확한 책임을 가지며, 특히 캐시 전략이 서비스 로직과 유기적으로 결합되어 있습니다.

우리는 Caffeine을 1차 로컬 캐시로 활용하여 JVM 메모리 내에서 고성능 캐싱을 구현했습니다. 다음은 CacheConfig에 정의된 Caffeine 캐시 설정의 주요 부분입니다.

@Configuration @EnableCaching class CacheConfig { @Bean fun localCacheManager(): CacheManager { val cacheManager = SimpleCacheManager() val caches = listOf( CaffeineCache( CaffeineCacheKeys.LOCAL_TABBAR_CACHE_KEY, Caffeine.newBuilder() .expireAfterWrite(TTL_TEN_SECONDS, TimeUnit.SECONDS) .build() ), CaffeineCache( CaffeineCacheKeys.LOCAL_THEMEDRAWER_CACHE_KEY, Caffeine.newBuilder() .expireAfterWrite(TTL_TEN_SECONDS, TimeUnit.SECONDS) .build() ) ) cacheManager.setCaches(caches) return cacheManager } // RedisCacheManager 설정 등 }

expireAfterWrite(TTL_TEN_SECONDS, TimeUnit.SECONDS):

캐시 데이터가 마지막 쓰기(생성/업데이트) 시점으로부터 10초가 지나면 만료되도록 설정했습니다.
올리브영 트래픽 특성 상 피크 타임의 트래픽만 무사히 넘기면 되기 때문에 TTL을 짧게 설정했습니다.
또한, 클라우드 환경 특성 상 로컬 캐시에 대한 중앙 관리가 어려운 점이 있어, 짧은 TTL을 이용하여 데이터 갱신 시 최신 데이터 반영 시간을 최소화하고자 했습니다.

5. 코드 예시: 캐시 계층별 역할

TabbarController, IntegratedSduiService, TabbarService는 각각의 역할을 분리하여 단일 책임 원칙(SRP)을 준수하고, 캐시 로직과 비즈니스 로직을 명확히 구분합니다.

TabbarController (클라이언트 요청 처리)

@RequestMapping("/tabbar/information", method = [RequestMethod.GET]) fun fetchTabbarInformation(@RequestParam(value = "tabbarType") tabbarType: String): TabbarResponse { return integratedSduiService.fetchTabbarInformation(tabbarType) }

TabbarController는 클라이언트의 HTTP 요청을 받아 IntegratedSduiService를 호출하는 게이트웨이 역할을 합니다.

IntegratedSduiService (1차 로컬 캐시 담당)

@Cacheable( cacheManager = "localCacheManager", value = ["localTabbar"], key = "{#tabbarType}", unless = "#result == null" ) fun fetchTabbarInformation(tabbarType: String): TabbarResponse { return tabbarService.getTabbarData(tabbarType) }

IntegratedSduiService는 SDUI에 대한 통합 비즈니스 로직을 담당하며, 여기에 1차 로컬 캐시(Caffeine)를 적용했습니다.
@Cacheable은 로컬 캐시에 데이터가 존재하면 네트워크 호출 없이 즉시 반환하여 가장 빠른 응답을 제공하는 어노테이션입니다. 만약 로컬 캐시에 데이터가 없다면, 하위 계층인 tabbarService를 호출하여 다음 캐시 계층으로 조회를 위임합니다. 단, unless = "#result == null" 조건을 통해 null 응답은 제외하고 유효 데이터만 캐싱합니다.

TabbarService (2차 원격 캐시 및 DB 조회 담당)

@Cacheable( cacheManager = "redisCacheManager", value = ["redisTabbar"], key = "{#tabbarType}", unless = "#result == null" ) fun getTabbarData(tabbarType: String): TabbarResponse { return tabbarRepository.getTabbarData(tabbarType) }

TabbarService는 2차 원격 캐시(Redis)를 담당합니다.
로컬 캐시에 데이터가 없을 경우 redisCacheManager를 통해 Redis에서 데이터를 조회합니다.
Redis에도 데이터가 없다면 최종적으로 tabbarRepository를 호출하여 Oracle DB에서 데이터를 가져옵니다.
이처럼 캐시 계층을 명확히 분리함으로써, DB 부하를 최소화하고 다중 서버 환경에서도 캐시 데이터의 일관성을 효과적으로 유지할 수 있도록 설계했습니다.

결과: 성과 지표

SDUI, 그리고 로컬 캐시의 성과 지표는 9월 '올영세일'에서 명확하게 드러났습니다.

2025년 9월 '올영세일' 첫째날 평균 응답 시간 (출처: DataDog APM 대시보드)

2025년 9월 '올영세일' 첫째날 최대 요청 수 (출처: DataDog Infrastructure 모니터링)

최대 초당 63.3k TPS (Transactions Per Second)를 견뎠으며, 이는 1초에 약 6만 3천 건의 요청을 처리했다는 의미입니다.
P90 Response Time은 최대 1ms가 되지 않는 결과를 보여줬습니다. P90은 '전체 요청 중 90%가 이 시간 안에 처리되었다'는 성능 지표인데요, 대부분의 사용자가 1ms보다 훨씬 빠른 시간 안에 응답을 받았다는 압도적인 성능 개선을 의미합니다.
뿐만 아니라, iOS, Android, Web 등 모든 플랫폼에서 동일한 탭바와 테마드로워 화면을 볼 수 있었습니다.

결론 및 향후 계획

본 사례를 통해 로컬 캐시가 SDUI 도입의 안정성과 성능을 동시에 보장하는 핵심 요소임을 확인했습니다.
성능 테스트를 기반으로 한 문제 인식과 그에 대한 해결책을 제안하는 과정을 통해서 단순히 이론이나 설계로만 답을 찾는 경험이 아닌 실제 데이터 기반의 답을 찾는 경험을 한 점은 인상 깊었습니다.
향후에는 SDUI를 적용하는 영역을 점차 확대할 예정이며, 다른 API 영역에도 로컬 캐시 도입을 적극적으로 검토할 예정입니다.
올리브영의 사례가 여러분의 서비스 최적화에 실질적인 영감이 되길 바라며, 궁금한 점이나 비슷한 경험이 있다면 댓글로 공유해 주세요.

대규모 프론트엔드 아키텍처의 새로운 패러다임 - Part 3. Nx를 활용한 마이크로프론트엔드

Mon, 10 Nov 2025 15:00:00 GMT

안녕하세요! 발레를 좋아하는 올리브영의 프론트엔드 개발자 개발레리나🩰 입니다.

마이크로프론트엔드(Micro Frontend Architecture,이하 MFE)는 하나의 거대한 애플리케이션을 작고 독립적인 모듈로 나누고, 각각의 모듈을 별도로 개발하고 운영할 수 있는 환경을 구축하는 아키텍처 패턴입니다.

이렇게 모듈을 분리하면 각 도메인이나 기능 단위로 코드를 관리할 수 있어 대규모 코드베이스에서도 리스크를 줄이고, 빠른 개발 속도를 유지할 수 있습니다.

만약 MFE에 대한 개념 자체가 생소하거나, 더 자세한 개념과 장단점이 궁금하시다면,

➡️ 시리즈 첫 번째 글인 대규모 프론트엔드 아키텍처의 새로운 패러다임 - Part 1. 마이크로프론트엔드 너 뭐야? 먼저 읽고 오시는 걸 추천드려요 😊

MFE환경을 구축할 수 있는 대표적인 기술로는 Webpack을 활용한 모듈 페더레이션이 있습니다. 이 기술을 사용하면 서로 다른 앱을 런타임에 하나로 통합할 수 있게 되는데요,

이 기술에 대한 자세한 설명과 실제 구현 방식이 궁금하시다면,

➡️ 시리즈 두 번째 글인 대규모 프론트엔드 아키텍처의 새로운 패러다임 - Part 2. 모듈 페더레이션 PoC 글을 참고해 주세요! 🦊

모듈 페더레이션은 멀티레포뿐 아니라 모노레포 환경에서도 구현할 수 있습니다. 특히 이번에 소개할 Nx는 간단한 명령어와 설정만으로 모듈 페더레이션을 손쉽게 적용할 수 있도록 지원합니다.

또한 모노레포의 특성상 런타임 통합뿐 아니라 빌드타임 통합도 가능하며, 공통 설정과 의존성 관리까지 체계적으로 구성할 수 있기 때문에 협업과 유지보수 측면에서도 큰 장점이 있습니다.

올리브영은 지속적인 서비스 성장과 함께 프론트엔드 코드베이스가 빠르게 확장되고 있습니다.
이에 따라 여러 도메인과 기능이 복잡하게 얽히면서, 각 모듈 간의 의존성을 명확히 파악하고 관리하는 것이 점점 더 중요해지고 있습니다. 또한 새로운 기능을 빠르게 출시해야 하는 비즈니스 요구사항과 함께, 각 팀이 독립적으로 개발하고 배포할 수 있는 유연성도 필요해지고 있습니다.

이런 상황에서 저희는 모노레포 환경에서 MFE를 구축할 수 있는 도구들을 검토하게 되었고, 그 과정에서 Nx를 실험하고 연구하게 되었습니다. Nx는 단순히 모노레포를 관리하는 도구를 넘어서, MFE와 같은 복잡한 아키텍처를 안정적으로 운영하는 데 필요한 기능들을 통합적으로 제공한다는 점에서 저희의 선택지가 되었습니다. (Nx 공식 사이트 바로가기)

이번 글에서는 ⌜대규모 프론트엔드 아키텍처의 새로운 패러다임⌟ 시리즈의 마지막 편으로, 올리브영이 왜 이 시점에 Nx를 고민하고 실험하게 되었는지 그 배경을 함께 살펴보고, Nx라는 모노레포 도구를 활용해 빌드타임과 런타임 환경에서 마이크로프론트엔드를 구현하는 방법을 실제 코드 예시와 함께 소개합니다.

📝 한 줄 요약

Nx의 특징을 이해하고, 이 도구를 활용하여 빌드타임 통합 방식과 런타임 통합 방식으로 MFE를 구현하는 과정을 실제 코드로 실습하며 최종 결과물을 확인합니다.😁

빌드타임 통합 방식 런타임 통합 방식(w. 모듈 페더레이션)

Nx가 무엇인가요?

Nx는 대규모 프로젝트에서 여러 앱과 라이브러리를 하나의 저장소에서 체계적으로 관리할 수 있도록 돕는 모노레포 도구입니다.

간단한 명령어를 통해서 특정 모듈의 변경을 감지하고, 변경이 일어난 모듈에 대해서만 명령을 실행하는 등의 기능을 제공합니다. 특히 remote caching을 지원하여 이전에 빌드된 모듈의 경우 빠르게 빌드 결과물을 불러올 수 있습니다.

또한 React, Next.js, Angular 같은 프레임워크를 위한 템플릿과 CLI를 제공하여 독립된 앱을 빠르게 구성하여 출시할 수 있게 됩니다.

주요 기능 요약

Computation Caching: 이전에 실행한 빌드/테스트 결과를 캐싱

Affected: 변경된 코드에만 영향을 받는 앱/라이브러리만 선택적으로 빌드/테스트

Graph: 앱과 라이브러리 간의 의존성을 시각화해 확인할 수 있음

CLI: Angular, React, Next.js, Express 등 개발 환경 구성 지원 → 초기 개발 비용 절감

왜 Nx인가요?

Nx는 모노레포 환경에서 MFE를 구축하기 위한 최적화된 구조를 제공합니다.

다만, 이러한 유사한 기능을 제공하는 다른 도구들도 있는데요, 그렇다면 다른 선택지들 중에서도 왜 Nx를 선택해야 할까요?

올리브영처럼 지속적으로 성장하는 플랫폼에서는 단순히 빌드 속도를 개선하는 것을 넘어서, 장기적인 관점에서 개발 생산성과 유지보수성을 극대화할 수 있는 도구가 필요합니다. 특히 복잡하게 얽히는 앱과 라이브러리 간의 의존성을 한눈에 파악할 수 있는 기능과, 새로운 기술 스택 도입 시 확장성이 뛰어난 플러그인 생태계는 대규모 코드베이스를 관리하는 데 필수적이라고 판단했습니다.

Nx와 유사한 기능을 제공하는 대표적인 도구인 Turborepo와 비교해보겠습니다.

Nx vs Turborepo

항목 Nx Turborepo

의존성 시각화 지원 미지원

Affected 기능 지원 지원

Plugin 생태계 풍부함 (Next.js, React, Storybook 등) 상대적으로 제한적

초기 학습 난이도 다소 높음 낮음

설정 유연성 높음 보통

Turborepo도 강력한 모노레포 도구이지만, Nx는 MFE와 같은 복잡한 아키텍처를 구성할 때 더 많은 가이드와 기능을 제공합니다. 특히 특히 CLI 기반의 프로젝트 생성과 통합, 의존성 시각화와 같은 기능은 실무에서 개발 생산성을 크게 높여줍니다.

무엇보다도 Nx에서는 이 모든 구성 요소들은 프로젝트의 목적과 규모에 따라 점진적으로 도입할 수 있도록 각 기능이 모듈화된 구조로 설계 되어 있습니다. 그래서 작은 팀이든 대규모 조직이든, 필요에 따라 유연하게 적용할 수 있다는 점이 Nx의 큰 장점 중 하나입니다.

Nx 기반 모노레포에서 마이크로프론트엔드 환경 구축해보기

이제 실제 코드 예시를 통해 Nx에서 마이크로프론트엔드를 빌드타임과 런타임 방식으로 어떻게 구현할 수 있는지 살펴보겠습니다.

빌드타임 통합하기

빌드타임 통합은 여러 앱이나 모듈을 하나의 메인 앱 안에 포함시켜, 최종적으로 하나의 번들로 함께 빌드하고 배포하는 방식입니다.

빌드타임 코드 통합 시 MFE 구조도

1. 워크스페이스 생성하기

Nx에서 제공하는 CLI를 사용해 모노레포 워크스페이스 생성합니다.

npx create-nx-workspace@latest

이 명령어를 실행하면 위 이미지와 같이 프롬프트에서 새로운 워크스페이스 구성을 위한 여러 설정들을 단계별로 선택할 수 있습니다.

저는 nx-example이라는 이름으로 Nx 워크스페이스를 생성하였고, main-app이라는 이름의 Next.js 기반의 웹 어플리케이션을 초기 앱으로 설정하였습니다.

그 외의 ESLint, Prettier, 스타일 라이브러리나 테스팅 도구 등의 개발환경설정들도 자유롭게 선택하시면 됩니다.

모든 설정이 완료되면 아래와 같은 구조로 워크스페이스가 구성됩니다.

이제 아래 명령어를 입력하면 main-app을 작동시킬 수 있습니다.

npx nx g @nx/react:lib libs/sub-app

기본 메인앱 구동 화면

2. 메인 앱에 통합될 서브 모듈 생성하기

이제 libs 디렉토리에 메인 앱에 통합될 서브 모듈(라이브러리 앱)을 생성해보겠습니다.

npx nx g @nx/react:lib libs/sub-app

저는 sub-app이라는 이름으로 React 기반의 라이브러리 앱을 생성하였습니다.

위와 같이 설정을 완료하면 다음과 같이 libs 폴더 안에 sub-app이라는 새로운 라이브러리 앱이 추가됩니다.

명령어 두 줄만으로 하나의 Next.js 기반의 메인 앱과 React 기반의 서브 앱이 추가된 새로운 Nx 워크스페이스가 생성되었습니다!! 👍

이렇게 만들어진 Nx 워크스페이스의 주요한 폴더와 기능을 알아보겠습니다.

apps 폴더: 실제 실행 가능한 앱이 위치합니다.

libs 폴더: 여러 앱에서 공통으로 사용하는 공유 라이브러리나 서브 모듈을 정의합니다.

nx.json: Nx의 핵심 설정 파일로, 프로젝트의 구조와 스크립트 명령어 실행 규칙 등을 정의합니다.

tsconfig.base.json: 워크스페이스 전역에서 공유하는 TypeScript 설정 파일입니다.

3. 서브모듈을 메인앱에서 사용하기

이제 libs/sub-app에서 만든 모듈을 apps/main-app에서 가져와서 실제로 사용해보겠습니다.

sub-app에는 기본적으로 lib/sub-app.tsx라는 컴포넌트가 생성되어 있습니다. 이 컴포넌트를 불러오려면 @nx-example/sub-app 경로를 임포트하면 Nx에서 자동으로 경로를 매칭해줍니다.

// apps/main-app/pages/index.tsx import { SubApp } from '@nx-example/sub-app'; export default function HomePage() { return ( <div> <h1> <span> Hello there, </span> Welcome main-app 👋 </h1> <SubApp /> </div> ); }

이렇게 main-app 안에서 sub-app 내에 있는 컴포넌트를 불러오면 별다른 설정 필요없이 이 모듈은 빌드 시점에 main-app에 함께 통합됩니다.

빌드타임 통합 화면

현재 main-app과 sub-app은 서로 다른 디렉토리에 존재하고 각자 독립적인 구조를 가지고 있지만, 빌드 시점에 하나의 앱으로 통합되어 최종 번들에 함께 포함됩니다. 또한 Nx가 제공하는 Affected, 캐싱, 의존성 분석 기능을 함께 활용하면, 서브 모듈이 많아져도 전체 앱을 매번 재빌드할 필요 없이 변경된 부분만 빠르게 빌드할 수 있어 개발 환경에서 매우 효율적으로 사용할 수 있습니다.

그러나 이 방식은 모든 모듈이 하나의 배포 파이프라인을 따르기 때문에, 각 모듈이 독립적으로 배포되어 각 팀에서 자율적으로 배포 주기를 관리해야야하는 경우에는 적합하지 않습니다.

다음으로는 위와 같은 단점을 보완하여 앱을 완전히 분리된 단위로 개발하고 개별적으로 배포할 수 있는 런타임 통합 방식을 살펴보겠습니다.

런타임 통합하기 (feat. 모듈 페더레이션)

런타임 통합은 각 앱을 완전히 독립적으로 개발 및 배포한 뒤, 런타임 시점(어플리케이션 실행 시점)에 하나로 통합되어 서로 코드를 공유하는 방식입니다.

런타임 코드 통합 시 MFE 구조도

1. 워크스페이스 생성하기

먼저 Nx CLI를 사용해 워크스페이스 생성합니다.

npx create-nx-workspace@latest

runtimeExample이라는 workspace를 만들었습니다. 이 명령어를 통해 기본 앱이 생성이 되는데, 아래에서 host앱과 remote앱을 함께 생성하는 generator 명령어를 사용해 두 앱을 따로 만들어볼 예정입니다. 이 때 이미 생성된 기본 앱은 제거해주세요.

2. host앱과 remote 앱 추가하기

다음 명령어를 사용하면 모듈 페더레이션이 적용된 host/remote 앱을 동시에 생성할 수 있습니다.

물론 각각의 앱을 따로따로 만들어 모듈 페더레이션관련 설정들을 추가하는 방식으로도 구현이 가능하지만, 이렇게 만들면 좀 더 간편하게 host앱과 reomte 앱을 만들 수 있습니다.

npx nx g @nx/react:host apps/host --remotes=remote

⚠️ 주의

워크스페이스 이름이나 remote 앱 이름에 -, @ 같은 특수 문자가 포함되면 generator 실행 시 오류가 발생합니다.
예: "Invalid remote name: @nx-exmaple/remote-app"

따라서 프로젝트나 워크스페이스의 이름에 특수기호가 들어가지 않도록 설정하세요!

그러면 이렇게 hostApp과 remoteApp이 동시에 생성됩니다.

이제 모듈 페더레이션설정 관련 파일들을 살펴보겠습니다.
각각의 앱 내부를 보면 module-federation.config.ts 파일이 자동으로 생성되어있습니다.

이 파일은 Webpack 모듈 페더레이션 설정을 Nx가 추상화하여 쉽게 사용할 수 있도록 제공하는 기능으로, 각 앱 간의 연결 관계와 노출할 컴포넌트를 정의하는 핵심 설정파일입니다.

3. 모듈 페더레이션 관련 설정 확인

<Host App>

Host 앱은 Remote 앱을 소비하는 쪽이기 때문에, remotes 항목을 통해 어떤 앱과 연결할지 명시해야 합니다.

// apps > hostApp > module-federation.config.ts import { ModuleFederationConfig } from '@nx/module-federation'; const config: ModuleFederationConfig = { name: 'hostApp', /** * To use a remote that does not exist in your current Nx Workspace * You can use the tuple-syntax to define your remote * * remotes: [['my-external-remote', 'https://nx-angular-remote.netlify.app']] * * You _may_ need to add a `remotes.d.ts` file to your `src/` folder declaring the external remote for tsc, with the * following content: * * declare module 'my-external-remote'; * */ remotes: ['remoteApp'], }; /** * Nx requires a default export of the config to allow correct resolution of the module federation graph. **/ export default config;

name: 현재 host앱의 이름입니다.

remotes: 런타임 시점에 연결할 remote 앱의 이름입니다. 실제 remote앱의 이름과 일치해야합니다.

// apps > hostApp > src > app > app.tsx import * as React from 'react'; import NxWelcome from './nx-welcome'; import { Link, Route, Routes } from 'react-router-dom'; const RemoteApp = React.lazy(() => import('remoteApp/AppComponent')); export function App() { return ( <React.Suspense fallback={null}> <ul> <li> <Link to="/">Home</Link> </li> <li> <Link to="/remote-app">RemoteApp</Link> </li> </ul> <Routes> <Route path="/" element={<NxWelcome title="hostApp" />} /> <Route path="/remote-app" element={<RemoteApp />} /> </Routes> </React.Suspense> ); } export default App;

<RemoteApp>

Remote 앱은 자신의 내부 모듈 중 어떤 것을 외부에 공유할지 명시해야 하며, Host 앱은 이 이름을 기준으로 해당 모듈을 동적으로 불러옵니다.

// apps > hostApp > module-federation.config.ts import { ModuleFederationConfig } from '@nx/module-federation'; const config: ModuleFederationConfig = { name: 'remoteApp', exposes: { './AppComponent': './src/app/app.tsx', }, }; /** * Nx requires a default export of the config to allow correct resolution of the module federation graph. **/ export default config;

name: 현재 remote 앱의 이름입니다. (host앱에서 이 이름을 통해 접근합니다.)

exposes: 외부에 노출할 컴포넌트 혹은 모듈 경로를 정의합니다.

여기서AppComponent은 host에서 import할 때 사용되는 경로이고,

'./src/app/app.tsx'은 실제 컴포넌트 파일의 위치입니다.

4. 타입 에러 방지를 위해 타입 선언 로직 추가 및 타입 설정 파일 수정

Host App에서 Remote App 모듈을 사용할 때 타입스크립트 에러를 방지하려면 아래와 같이 글로벌 타입 선언 파일을 추가해주세요.

// apps > host > src > remotes.d.ts declare module "RemoteApp/AppComponent" { const App: React.ComponentType; export default App; }

그리고 Host App이 Remote App의 코드를 인식하고 타입 컴파일을 할 수 있도록 tsconfig.app.json의 rootDir과 include를 수정합니다:

// apps > host > tsconfig.app.json { "extends": "../../tsconfig.base.json", "compilerOptions": { "outDir": "dist", "tsBuildInfoFile": "dist/tsconfig.app.tsbuildinfo", "jsx": "react-jsx", "lib": ["dom"], "types": [ "node", "@nx/react/typings/cssmodule.d.ts", "@nx/react/typings/image.d.ts" ], // 아래 로직 수정 루트 디렉토리에 remoteApp 패키지도 포함되도록 root 디렉토리 설정 "rootDir": "../.." // "src" }, "exclude": [ "out-tsc", "dist", "src/**/*.spec.ts", "src/**/*.test.ts", "src/**/*.spec.tsx", "src/**/*.test.tsx", "src/**/*.spec.js", "src/**/*.test.js", "src/**/*.spec.jsx", "src/**/*.test.jsx", "jest.config.ts", "eslint.config.js", "eslint.config.cjs", "eslint.config.mjs" ], "include": [ "src/**/*.js", "src/**/*.jsx", "src/**/*.ts", "src/**/*.tsx", // 아래 로직 추가 => remoteApp 패키지도 타입스크립트 컴파일 목록에 포함시키기 "../../apps/remoteApp/src/**/*" ], "references": [] }

이제 Nx 명령어로 이 두 앱을 실행시켜보겠습니다! 🥁🥁

참고로 remote app을 실행하는 명령어를 입력하면, remoteApp과 함께 이를 참조하고있는 hostApp도 자동으로 실행됩니다.

nx serve remoteApp

콘솔에 명령어를 실행하면 위와 같이 두 앱이 병렬로 실행되고있는 것을 확인할 수 있습니다.

현재 각각의 앱은 다음과 같은 주소에서 접근 가능합니다.

hostApp: http://localhost:4200

remoteApp: http://localhost:4201

각 주소에 접근해 보면 다음과 같이 각 앱이 실행되고 있는 모습을 확인할 수 있습니다.

호스트앱 실행 화면

리모트앱 실행 화면

그리고 아래와 같이 hostApp에서는 remoteApp에서 정의한 컴포넌트가 모듈 페더레이션을 통해 동적으로 로드되어 렌더링되는 것을 확인할 수 있습니다. 😍

런타임 통합 방식 결과 화면

이렇게 런타임 통합 방식은 각 앱이 독립적으로 빌드 및 배포되면서도 동적으로 통합되어 하나의 어플리케이션처럼 동작할 수 있게 해줍니다.

마치며

지금까지 Nx 기반의 모노레포 환경에서 마이크로프론트엔드를 빌드타임 방식, 런타임 방식으로 통합하는 방법을 알아보았습니다.

이 글을 작성하는 지금 시점에서도 몇 달 전과 비교해보면 설정 방식이나 CLI 명령어 등 사용법이 미묘하게 달라진 부분이 있더라구요...! 😲

그만큼 Nx가 얼마나 빠르게 변화하고 꾸준히 개선되고 있는지를 체감할 수 있었습니다. (빠르게 변화가 일어난다는 점은 커뮤니티와 수요가 그만큼 활발하다는 뜻이기도 하겠죠?)

Nx는 다소 러닝커브가 있지만, 그만큼 제공하는 기능이 다양하고 강력합니다. 빌드 캐싱, Affedted 기반 최적화, 앱 간의 의존성 그래프 시각화 등의 기능은 특히 규모가 큰 프로젝트일수록 유지보수와 협업 측면에서 큰 효과를 발휘할거라고 생각합니다.

또한 단순히 모노레포 환경을 지원하는 도구를 넘어서, MFE 환경을 손쉽게 구축할 수 있도록 CLI 기반으로 모듈 페더레이션을 구현할 수 있도록 도와준다는 점에서 정말 좋은 도구라고 생각합니다.

물론 모든 팀과 모든 프로젝트에 정답이 될 수는 없겠지만, 이러한 도구가 어떤 문제를 해결할 수 있는지를 아는 것만으로도 앞으로 기술적인 문제를 해결해나가는 데 도움이 될 수 있다고 생각해요! 💪

이 시리즈가 마이크로프론트엔드 구조 도입을 고민하고있는 팀, 혹은 MFE에 궁금증을 가지고계셨던 프론트엔드 개발자분들에게 조금이나마 도움이 되었기를 바랍니다.

이번 글에서는 Nx를 활용한 MFE 환경 구축의 기본적인 방법을 다뤘지만, 실제 대규모 프로덕션 환경으로 확장하기 위해서는 더 많은 고민이 필요합니다. 상태 관리 전략, 공통 라이브러리 운영, 모니터링 및 디버깅, 성능 최적화 등 고도화된 과제들이 남아있죠. 올리브영 테크 팀은 이러한 영역들을 지속적으로 탐구하고 실전 경험을 쌓아가며, 그 과정에서 얻은 인사이트를 여러분과 함께 나누고자 합니다.

올리브영 테크 팀과 함께 성장하고 새로운 기술 패러다임을 만들어나가고 싶다면, 저희의 다음 글도 기대해주세요! 🚀

긴 글 읽어주셔서 감사합니다.

하이브리드 앱에 구축하는 iOS 개발자모드

Thu, 06 Nov 2025 00:00:00 GMT

안녕하세요! 올리브영의 iOS Junior Engineer Ted입니다.
저는 오늘, 올리브영 iOS 앱에 개발자모드를 구축했던 경험에 대해 이야기하려 합니다.
신입 개발자로 올리브영에 합류하여 첫 프로젝트로 진행했던 개발자모드 구축을 통해 하이브리드 앱 구조에 적응하고, FE와 소통하는 법을 배우며, SwiftUI로 개발한 경험을 공유하겠습니다 💪🏻💪🏻💪🏻

👶🏻 주니어 개발자가 경험한 올리브영 iOS 앱

올리브영 앱은? 하이브리드 앱!

신입 iOS 엔지니어로 올리브영에 합류했을 때 마주친 수많은 WebView에 적잖이 당황했었습니다 😯 입사 전에는 네이티브 위주의 개발을 주로 경험했고, WebView는 가볍게만 사용해보았습니다. 팀에 합류했을 때에는 많은 서비스가 웹 기반이었기 때문에 iOS 웹뷰에 대한 이해가 많이 필요했습니다. 처음으로 개발해보는 하이브리드 앱의 구조가 어렵기도 하면서 새롭다고 느꼈던 것 같습니다. 아래는 올리브영 앱의 일부 구조입니다. 한번 같이 보시죠!

올리브영 앱 구조

위의 올리브영 앱 구조를 보시면 아시겠지만, 많은 부분이 웹 기반의 서비스입니다.
이런 웹 기반의 환경에서 고객에게 서비스를 제공하기위해, iOS 파트에서는 다음과 같은 일들을 FE와 소통하여 개발하고 있습니다.

1. URL 기반으로 올리브영 앱의 전반적인 Navigation을 관리합니다.

2. 각 서비스 영역에서 필요한 네이티브 기능들을 제공합니다.

느낌이 오지 않나요? 네 맞아요. 올리브영 앱은 원활한 고객경험을 위해 FE와 상당히 많은 부분을 고민하고 함께 개발합니다. 이런 상황에서 FE 개발자와 협업하는 방식도 저에게는 새로운 경험이었습니다. 새롭게 알아가야 할 게 많은 상황에서 저는 첫 프로젝트였던 개발자 모드 구축을 통해 WebView에 익숙해지며, FE 개발자분들과 협업하는 방식을 배웠습니다.

첫 프로젝트: 개발자모드

🧑🏻‍💻 매일 매일 들어오는 디버깅 요청: 개발자모드의 등장

올리브영 앱을 개발하다보면 FE개발자 분들과 소통할 일이 정말 많습니다. 웹과 iOS 앱이 함께 기능을 개발하며 고객에게 서비스를 전달하기 때문입니다. 필요한 기능을 웹에 API 형태로 전달하기도 하고 웹에서 전달받은 데이터를 이용해 앱에서 특정 기능을 동작하도록 합니다. 이 과정에서 iOS 웹뷰인 WKWebView의 WKScriptMessage를 통해 필요한 데이터를 주고받습니다. (올리브영에서는 이를 편의상, JS Interface라고 부르고 있습니다)

그러다보면, Slack에서 다음과 같은 대화가 잦아집니다.

슬랙의 수많은 디버깅 요청

앱과 웹에서 데이터가 제대로 송수신이 되었는지 확인하기위해서는 직접 Xcode에서 빌드하여 디버깅을 해야합니다. 이에 더해서 Safari 웹 인스펙터를 이용하여 웹도 함께 디버깅을 해야하는 상황이 매번 연출되었습니다. 하이브리드 앱을 디버깅하기 위해서는 이렇게 양방향으로 디버깅을 해야하는 어려움이 있습니다. 이런 일이 계속 있다고 한다면? 상당히 비효율적이고 시간도 많이 소요됩니다. 이런 이유로 앱 개발자와 FE 개발자의 생산성 향상을 위해 올리브영에 개발자모드가 도입되었습니다.

개발자모드? 🤔

먼저, 개발자모드가 뭔지 알아야겠죠?
올리브영의 개발자모드는 앱 실행중에 다양한 디버깅과 테스트 기능들을 지원하는 툴 입니다. 앱 개발자뿐만 아니라, FE 개발자들도 실행중인 앱 내에서 로그를 파악하고, 테스트 목적으로 특정 기능을 실행할 수 있는 필수적인 툴 입니다. 물론 개발자들의 디버깅을 돕는 외부 라이브러리도 있습니다! 하지만, 하이브리드 앱 구조를 고려한 커스텀 기능들을 위해 직접 개발자모드를 구축했습니다.

올리브영 iOS의 개발자모드는 SwiftUI를 이용하여 개발했습니다. 개발자 모드는 외부 사용자에게 노출되지 않고, 개발환경에서만 사용되는 기능입니다.따라서 UI 완성도보다는 빠른 구현 속도와 유연한 변경이 더 중요합니다. SwiftUI를 선택한 가장 큰 이유는 선언형 UI의 생산성입니다.

화면의 상태를 데이터로 표현하고, 이를 기반으로 UI를 선언하듯 작성하면 기존 UIKit 대비 훨씬 빠르게 UI를 만들 수 있습니다. 간단한 View와 @State, @Binding만으로도 필요한 화면을 모두 구현할 수 있었고, 짧은 주기로 기능을 실험하고 수정하는 개발자모드 특성에 딱 맞았습니다. 결과적으로, SwiftUI를 통해 개발자 모드의 화면은 기획 → 개발 → 배포까지의 사이클이 크게 단축되었고, 개발자들에게 필요한 기능들을 빠르게 구현하고 배포할 수 있었습니다.
(SwiftUI 덕분에 빠르게 개발하고 퇴근이 가능해졌습니다!)

출처: MBC '무한도전' 캡처

What's in my 개발자모드? ⚙️

개발자모드 버튼

개발자 모드 버튼

그럼 올리브영 iOS 앱의 개발자 모드에 대해 소개해드리겠습니다.
올리브영 개발자 모드는, 플로팅 버튼을 통해 진입할 수 있습니다. (물론 개발환경에서만 진입할 수 있습니다!) 앱과 별도의 UIWindow에 개발자 버튼을 배치하여 항상 모든 화면보다 개발자 모드가 위에 있을 수 있도록 처리했습니다. 올리브영 개발자들은 버튼을 클릭하여 개발자모드에 진입하여 다양한 기능들을 사용할 수 있게 되었습니다.

또한 버튼에 앱 버전, iOS 버전, 현재 서버,, 활성화된 기능, 을 표시해두어 빠르게 기기 버전과 앱 버전을 파악할 수 있게 했습니다. 덕분에 Slack이나 Jira를 통해 전달받는 이슈에서도 개발자 모드 버튼만 보면 앱 버전과 서버를 즉시 확인할 수 있어, 이슈 추적 속도가 크게 빨라졌습니다.

WebView Debugger

개발자 모드 : WebView 메뉴

다양한 기능들이 있지만, 올리브영 개발자 모드는 웹뷰에 관련된 기능을 가장 많이 사용합니다. 이 기능들을 통해 FE 개발자와 앱 개발자들은 로그를 확인할 수 있게 되었고, 런타임에 다양한 기능들을 사용할 수 있게 되었습니다. 더 이상 Xcode에서 디버깅을 하지 않아도 되었고, FE-App 개발자 모두 앱에서 로그를 확인할 수 있어 불필요한 커뮤니케이션이 사라졌습니다! 그럼 어떤 기능이 있는지 간략히 보여드리겠습니다.

URL Editor

최상단 웹뷰의 URL의 정보와 User Agent 정보를 확인할 수 있으며, URL 이동, Query Parameter 수정이 가능합니다

웹 로그 탐색기

화면별 WKScriptMessage 로그, javascript 실행 로그를 확인하여 디버깅이 가능합니다.

URL 이동로그, 외부링크 앱 진입 로그를 통해 어떤 경로로 앱의 Flow를 디버깅할 수 있습니다.

웹 스토리지 뷰어

최상단 웹뷰의 세션 스토리지, 로컬 스토리지, 쿠키 값을 확인할 수 있습니다.

Javascript Console

최상단 웹뷰에 런타임에 스크립트를 앱에서 실행할 수 있습니다.

스택 스크린 로그

앱의 뷰 계층 구조(View Hierarchy)를 시각화할 수 있으며, 각 화면별 로그를 그룹화 할 수 있습니다.

로컬 플래그: 기능 플래그 스위치

개발자 모드의 또 다른 주인공은 바로 로컬 플래그 입니다.

로컬 플래그는 다양한 이유로 도입된 기능입니다. 올리브영의 일부 서비스는 안정적인 운영을 위해 기능 플래그를 이용하고 있습니다. 새로운 기능을 배포할 때 기능 플래그를 이용해 혹시 모르는 상황에 대비해 언제든지 기존 동작으로 돌아갈 수 있도록 설계하고 있습니다. 앱은 롤백이 불가능하고, 배포하기 위한 프로세스가 복잡하다보니, 중요한 기능들에 대해서는 기능 플래그를 사용하고 있습니다.

기능 플래그를 이용해 개발을 하면 다음과 같은 프로세스가 추가적으로 발생합니다.

개발시에는 개발환경에만 필요한 플래그와 데이터를 서버에 등록해두어야 합니다. (운영 환경에 영향을 미치면 안됩니다!)

QA 시에는 해당 서버의 기능 플래그를 직접 On/Off하며 기존 동작과 새로운 기능이 모두 잘 동작하는지 테스트 해야합니다.

이런 프로세스가 추가적으로 생기면서, 따라오는 비효율과 리스크가 발생했습니다. 개발 혹은 QA 시에 매번 기능 플래그를 On/Off를 해야하니 비효율이 증가했습니다. 단순 true/false 플래그가 아닌, 리스트형태로 갖고 있는 데이터도 변경해야하다보니 꼼꼼하게 검수도 해야 했습니다. 또한, 개발시에 사용하는 플래그와 운영에서 사용하는 플래그가 분리되어있고, QA 테스트에서 On/Off를 수시로 해야한다면, 실수로 운영 환경에 플래그를 변경할 위험이 있습니다. 이와 같은 이유로 기능 플래그 값을 직접 수정하지 않고 테스트폰에서 직접 플래그 값을 조절할 수 있는 로컬 플래그 를 개발하게 되었습니다.

개발자모드 기능 플래그

로컬 플래그를 On하면 개발자가 설정하는 값으로 기능이 동작합니다

로컬 플래그에서 값을 변경하면 사용자가 식별하기 쉽게 파란 동그라미와 변경됨 표시를 제공합니다

해당 기능을 통해, 원격 서버의 값 변경없이 개발 & QA 시에 테스트 기기에서 플래그값을 조절 할 수 있게 되었습니다. 이 덕분에, 운영상에 영향을 미칠 리스크가 사라졌습니다. 그뿐만이 아닙니다. QA 엔지니어와 앱 개발자 간에 플래그 조절을 위한 커뮤니케이션도 할 필요 없게 되었습니다. 앱 개발자는 이제 기능 개발에 집중할 수 있게 되었고, 이는 또 빠른 퇴근으로 이어질 수 있었습니다.

하지만, 이 기능을 구현하는데에 있어 많은 고민들이 필요했었는데, 그 고민의 결과를 잠깐 공유하고자 합니다.

고민의 결과

로컬 플래그 기능은 여러 버전을 거쳐서 현재의 안정적인 버전으로 자리를 잡았는데요. 이 과정에서 많은 리팩토링이 있었습니다. 리팩토링을 하며 모듈화, 추상화, 디자인패턴 등 많은 것을 경험할 수 있었습니다. 많은 고민들이 있었지만 구현상의 중요한 고민은 다음과 같았습니다.

어떻게 런타임에 리모트 플래그를 볼 것인지, 로컬 플래그를 볼 것인지 결정할 수 있을까? (리모트 - 서버에 저장된 값, 로컬 - 테스트 단말의 저장된 값)

운영 환경에는 절대 로컬 플래그로 동작하면 안된다! (그것은 사고니까..)

현재의 결과를 보며 어떻게 그 고민이 해소되었는지 보여드리겠습니다. 먼저 모듈 관계와 코드를 통해 OYFlag 모듈의 역할을 먼저 같이 보시죠!

플래그 & 개발자모드 모듈 관계

// MARK: OYFlag Module /// 실제 플래그 값을 가지고 있는 Object final class RemoteFlag { private var flags: [String: FlagValue] = [:] init() { fetchFlags() } ... }

// MARK: OYFlag Module /// Flag 값을 return 할 수 있는 프로토콜 protocol FlagProvidable { func value<T: Decodable>(for key: some FlagKey) -> T? }

우선 모듈 관계입니다. Common Layer에 Flag Module이 있습니다. 이 플래그모듈의 역할은 단순합니다.

플래그 값을 서버로부터 받아와서 가지고 있습니다.

이 플래그 값을 Return 하는 프로토콜 타입이 있습니다.

이 모듈이 제공하는 프로토콜을 이용해서 이제, 운영에서는 운영용 Flag Provider를, 개발환경에서는 개발용 Flag Provider를 만들 수 있습니다.

다음으로는 이 프로토콜을 사용하는 OYDevMode의 모듈의 코드의 일부를 보시죠!

// MARK: OYDevMode import OYFlag final class DevFlagProvider: FlagProvidable { @Published private var isLocalFlagMode = false @Inject private var localFlag: LocalFlag! // 로컬 플래그는 컨테이너에 넣어두고, 개발자모드에서도 사용합니다 private let remoteFlag = RemoteFlag() func value<T: Decodable>(for key: some FlagKey) -> T? { isLocalFlagMode ? localFlag.value(for: key.name) : remoteFlag.value(for: key.name) } }

개발환경에서만 사용할 FlagProvider입니다. 운영에서 사용할 FlagProvider는 운영 모듈에서 따로 구현하여 Remote Flag 값만 Return 할 수 있게 했습니다. 따라서 이제는 앱이 메모리에 올라올 때에, 이 전역적으로 사용할 Provider의 Concrete 타입만 잘 정해서 넣어주면 됩니다. 이렇게 하면 운영에서는 운영 Provider를 사용할 수 있고 개발 환경에서는 개발용 Provider를 사용할 수 있습니다.

/// Container Register #if DEBUG // 개발 환경 OYContainer.register(FlagProvidable.self) { _ in DevFlagProvider() } #else // 운영 환경 OYContainer.register(FlagProvidable.self) { _ in FlagProvider() } #endif

여기서 잠깐. OYContainer가 무엇이냐고요? OYContainer는 올리브영 iOS 프로젝트에서 자체적으로 개발하여 사용중인 경량 DI 컨테이너입니다. 일반적인 컨테이너와 같은 기능을 지원하고, @Inject, @LazyInject와 같은 커스텀 프로퍼티 래퍼를 이용하여 의존성 주입을 합니다. FlagProvidable를 해당 컨테이너에 넣어두고 여러 Feature 모듈에서 사용하고 있습니다.

아무쪼록 Protocol과 컨테이너를 이용하여 Flag를 사용하는 코드에서 운영환경이든 개발환경이든 관계 없이 코드를 작성할 수 있습니다. Flag를 필요로하는 비즈니스 로직 혹은 View 어느 곳이든 Container를 통해 FlagProvider를 이용할 수 있습니다. 바로 다음과 같이 사용하면 됩니다.

import OYFlag struct ProductView: View { @Inject private var flagProvider: FlagProvidable! var body: some View { ... if flagProvider.value(for: ProductKey.featureA) == true { // 기능 플래그에 따른 특정 기능 } ... } }

그럼 개발자 모드에서는 어떻게 값을 변경하냐고요? 개발자모드에서는 간단하게 로컬 플래그를 변경할 수 있습니다! 컨테이너에 등록되어 있는 로컬 플래그 Object의 값을 변경하면 됩니다.

struct LocalFlagView: View { // 컨테이너에 등록되어 있는 LocalFlag @ObservedObject private var localFlag = OYContainer.resolve(LocalFlag.self)! var body: some View { Toggle(isOn: Binding( get: { localFlag.flagDict[key] }, set: { newValue in localFlag.flagDict[key] = newValue } // Toggle 변경시 LocalFlag 값 변경 )) { VStack { Text(key) } } } }

이렇게 추상화와 모듈화를 이용한 설계 덕분에 해결하고 싶었던 문제를 해결할 수 있게 되었습니다.

✅ 개발자모드에서 로컬 플래그를 이용하여 런타임에 값을 변경
✅ 운영 환경과 개발 환경의 Flag Provider를 완전히 분리하여 운영에 미칠 리스크 원천 차단
✅ OCP(Open/Closed principle)을 지킴으로써 향후 A/B 테스트를 위한 ABFlagProvider가 추가되어도 수정없이 확장가능

처음에는 이렇게 깔끔하게 설계하지 못했었는데, 동료들과 고민하고 보완해나가니 배우는 것도 많았고 특히 추상화와 모듈화의 실용적인 적용을 경험할 수 있어 좋았습니다 😎 어때요 개발자모드 참 쉽죠?

출처: EBS의 '그림을 그립시다'의 밥로스

🚀 0건의 디버깅 요청, 그리고 주니어의 성장

개발자모드 도입의 성과는 명확했습니다. 가장 큰 변화는 두 가지입니다. 첫째로, 웹뷰 관련 단순 디버깅 요청은 0건으로 수렴했습니다. 두번째로, 기능 플래그 때문에 서버의 값을 바꾸는 비효율적이고 위험한 일은 하지 않아도 됩니다. FE 개발자분들은 필요한 로그를 직접 앱에서 확인하고, QA 엔지니어분들은 로컬 플래그를 통해 서버 값 변경 없이도 자유롭게 테스트를 진행할 수 있습니다. "개발자 모드에 디버깅에 필요한건 다 있어서 개발이 많이 편해졌다"라는 FE 개발자분들의 긍정적인 피드백도 받을 수 있었습니다.

결과적으로 앱 개발자는 불필요한 커뮤니케이션 비용을 줄이고 본연의 기능 개발에 더 집중할 수 있게 되었습니다.

신입 개발자로서 첫 프로젝트를 진행하며, 올리브영 앱의 하이브리드 아키텍처와 도메인 지식을 빠르게 습득할 수 있었습니다. SwiftUI의 높은 생산성 덕분에 UI 개발 시간은 아끼고, FlagProvidable 프로토콜 설계처럼 더 중요하고 근본적인 고민에 시간을 쏟을 수 있었습니다.

개발자모드는 단순히 편의 기능을 만든 것이 아니라, 개발자들의 비효율을 해결하는 엔지니어링 이었습니다. 앞으로도 올리브영에서 동료들의 생산성을 높이고, 나아가 고객에게 더 나은 서비스를 제공하는데 기여하는 엔지니어로 성장하겠습니다! 💪🏻💪🏻 여러분의 경험과 질문을 댓글로 남겨주시면 함께 고민하고 성장할 수 있을 것 같습니다! 🙇🏻

7,000줄 PL/SQL 프로시저와의 결별: 클레임 로직 Java 모듈 이관기

Thu, 06 Nov 2025 18:00:00 GMT

목차

소개

거대한 프로시저의 그림자

레거시 탈출을 결심하다

마주한 시행착오

우리가 얻은 것

마치며

글쓴이

소개

안녕하세요.
올리브영 온라인몰에서 교환·반품 서비스를 담당하고 있는 클레임 스쿼드 현앙입니다.

이번 글에서는 수천 줄짜리 PL/SQL 프로시저에 얽혀 있던 교환·반품 로직을 Java로 이관하며, 기능별로 분리하고 유지보수성을 높였던 경험을 공유하려 합니다.

우리가 마주한 수천 줄 짜리 프로시저라는 문제는 단순한 기술 부채에 그치지 않았습니다. 그 영향은 곧바로 고객 경험으로 이어졌죠.

"환불이 왜 지연되나요?" = 고객님 죄송합니다.. 오류가났네요..
"반품신청했는데 회수를 안해가요" = 고객님 죄송합니다.. 반품접수가 안됐어요..
"교환이 접수된 건 맞나요?" = 고객님 죄송합니다...

이런 문의들의 대부분은 개발자가 디버깅하기 어려운 구조와 모든 로직이 한데 엉켜있는 레거시 프로시저에서 비롯된 경우가 많았습니다.

"개발자도 프로시저 내에서 발생한 오류를 추적하는 것이 불가능했고, 블랙박스와도 같은 느낌이었기에...."
"프로시저 디버그는 왜이렇게 어려운걸까요.. 수정과 컴파일은.. 왜.. 또.. 복잡하고... 어렵...고..난리야..."

거대한 프로시저의 그림자

우리 시스템에는 커머스에서 가장 중요한 모든 흐름이 하나의 프로시저 안에 들어 있었습니다.

주문 완료

주문 취소

교환 접수/철회/완료

반품 접수/철회/완료

옵션 변경

이 모든 것이 7,000줄이 넘는 PL/SQL 코드로 구성된 단일 프로시저 안에 뒤섞여있었습니다. 문제는 단순히 코드가 길다는게 아니라 비즈니스 로직 경계가 무너져 반품 절차 하나만 수정하려 해도 주문, 교환 로직에까지 영향을 미치는 구조였습니다. 이로 인해 작은 수정이 전사적인 서비스 리스크로 이어졌고, 결국 누구도 건드릴 수 없는 **기술 부채의 핵심(Core Tech Debt)**으로 남게 되었습니다.

이 구조는 모두가 기술 부채임을 알고 있었지만, 어디서부터 손대야 할지 모르는 상태로 오랜시간 유지되었습니다. 프로시저 안에는 수년간의 패치, 신규 정책이 누적되어 있었고, 문서화 되지 않은 수많은 분기 처리가 있었기 때문입니다. 결국 누구도 쉽게 들어가서 수정할 수 없는 ... 건드리면 터져버리는 폭탄이 되어버린거죠. 그로인해 아무도 고치고싶어하지않는, 고치지않는 코드가 되어버렸습니다.

미로같은 프로시저이기에, 변경 범위와 영향도를 예측하기 어렵다는 게 가장 큰 문제였습니다.

문제 영역 상세 설명

디버깅 난이도 DB 내부에서의 함수 호출, 로그성 데이터 부재

인력 의존성 소스를 이해하는 인력이 극소수라, 변경 자체가 리스크

우회 로직 남발 프로시저 수정을 피하기 위해 호출 앞뒤에 로직을 붙여 임시 대응 발생

"난 반품로직만 수정하고 싶은데.. 왜 주문이 안되는거야^.ㅠ...."와 같은 작은 변경이 곧 전사적 리스크가 되는 상황, 바로 이것이 우리가 탈출하고자 했던 현실이었습니다.
바로 이 상황에서 "이제는 프로시저와 이별하자!"라는 결심이 시작되었습니다.

레거시 탈출을 결심하다

우리가 내린 해법은 단순했습니다.
“프로시저를 쪼개고, 기능별 로직을 Java에서 다루자.”

하지만 실행은 쉽지 않았습니다.
PL/SQL은 데이터베이스 내에서 실행되므로 네트워크 오버헤드가 없고 DB 내부에서 최적화된다는 장점 때문에, Java로 변경시 성능 저하 우려가 있었으며 7,000줄짜리 코드에는 지뢰같은 예외 케이스도 숨어 있었습니다. 또한 올리브영은 MSA를 목표로 하고 있기 때문에 각 모듈별 중요 로직들을 신규 API로 이관을 해야하는지에 대한 고민이 있었습니다. 다만 프로시저 로직에 대한 이해도가 낮았고, 커머스에 가장 중요한 로직이기 때문에 완벽히 신규로 만드는 것에 대한 부담이 있었습니다.

따라서 우리는 무중단 점진적 이관 전략을 택했습니다.
올리브영 온라인몰은 24시간 많은 고객님들이 들어오는 시스템기에 무중단 점진적 전환이 매우 중요했습니다. 저희 클레임 스쿼드는 문제 해결 방법으로 레거시 전환의 모범 사례로 알려진 Strangler Pattern을 적용했습니다. 이는 기존 레거시 시스템을 새로운 시스템으로 점진적으로 대체하는 전략이자 올리브영 개발 조직의 개발 철학 중 하나라, 저희는 이 전략을 택하였습니다.

설계: 주문·교환·반품·옵션 변경 기능별 경계를 재정의

도입: 프로시저 호출 구간 앞단에 Java 모듈을 두어, 기존 프로시저는 유지한 채 점진적으로 전환

실행: 기능 단위로 이관하면서 장애 발생 시 [Fallback] 모드로 즉시 원복 가능하도록 설계

검증: 단위 및 통합 테스트 강화, 주요 지표 모니터링 체계화

점진적 이관 : Step-by-Step

🧩 Phase 0. 사전 준비 (Preparation)

목표 : 리스크 최소화와 빠른 의사결정을 위한 기능 분석 및 구조 파악

모듈별 기능 분석 : 미사용 분기처리, 예외처리 등 중요로직 파악을 위한 모듈별 흐름도 작성

트랜잭션 경계 맵핑 : COMMIT/ROLLBACK 지점, 격리수준, 재시도·보상 로직 정리

데이터 계약 정리 : 입력/출력 스키마, 에러 계약, 신·구 모듈 간 호환 규칙 정의

🧭 Phase 1. 도메인 모델링 (Domain Modeling)

목표 : 레거시 의존을 줄이고, 기능별 경계를 명확히 정의

모듈간 경계 분석 : 주문·교환·반품·옵션 변경 기능별 도메인 경계 재정의

도메인 엔티티/Value Object 설계 : 도메인 경계별 필요 엔티티 정의

Fallback 로직 설계 : 문제 발생시 프로시저 버전으로 원복될 수 있도록 로직 설계

🚀 Phase 2. 모듈 이관 (Migration)

목표 : 기능 단위로 점진적 전환 및 안정성 확보

Java 모듈 구현 및 테스트 : 단위 테스트, 통합 테스트 진행

Shadow 트래픽 검증 : 신규 모듈과 구 레거시를 병행 처리하여 결과 비교

모니터링 강화 : 주요 지표가 기준선을 유지하는지 실시간 검증

🧹 Phase 3. 레거시 해체 (Decommission)

목표 : 완전 전환 후 불필요한 복잡도 제거

나머지 모듈 Phase0 ~ 2까지 계속 진행

A[기존 PL/SQL 프로시저] A -->|분리| B[주문 모듈(Java)] A -->|분리| C[교환 모듈(Java)] A -->|분리| D[반품 모듈(Java)] A -->|분리| E[옵션 변경 모듈(Java)]

미사용 분기 제거 및 신규 모듈로의 완전 전환

마주한 시행착오

1년간의 이관 과정에서 다양한 시행착오를 겪었습니다.

트랜잭션 문제
기존에는 프로시저에서 암묵적으로 처리되던 부분이 Java로 옮겨지며 데이터 반영이 끊기는 문제가 발생했습니다.
→ 트랜잭션 익셉션을 재설계해 안정성을 확보했습니다.

로직 중복
PL/SQL과 Java가 병존하면서 소스 이원화 문제가 있었습니다.
→ Feature Toggle 관리로 혼선을 줄였습니다.

교훈

모든 걸 한 번에 옮기려 하지 말 것.

모니터링은 철저하게 할 것!

작은 단위로 쪼개어 옮기고, 실패 시 안전하게 되돌릴 수 있어야 한다.

우리가 얻은 것

이관 이후 예상보다 큰 효과를 얻을 수 있었습니다.

유지보수성
기능별 모듈화 변경 범위가 명확해지고, 영향도 예측이 가능해졌습니다. 또한 반품접수 로직을 쉽게 고칠 수 있어 고객에게 편리한 기능도 쉽게 제공할 수 있게 되었습니다.

디버깅 가능, 모니터링 강화
Java 전환 이후 로그와 예외 추적이 가능해지면서 장애 원인 파악 속도가 획기적으로 빨라졌습니다. 이 변화는 단순한 기술 개선이 아니라, 우리가 업무 병목을 ‘보이게 만든’ 결정적 진전이었습니다. 그전까지는 반품 접수에서 완료까지 걸리는 리드타임을 정확히 알 수 없었습니다. 어느 구간에서 지연이 발생하는지, 환불이 왜 늦어지는지조차 추적이 불가능했죠. 하지만 이제는 로그를 통해 반품 완료 단계의 오류를 실시간으로 식별할 수 있고, 이를 기반으로 병목 구간을 명확히 찾아내어 개선할 수 있게 되었습니다. 결과적으로 그동안 “언제부턴가 해결이 어려워진 문제들”까지도 이제는 근본 원인을 추적하고, 데이터 기반으로 해결해나갈 수 있는 환경이 만들어졌습니다.

이제! 모니터링이 가능해졌어요! 고객님의 문제를 빠르게 해결할게요 😉

확장성 확보
주문/반품/교환 등 모듈별 기능확장이 자유롭게 가능해졌습니다. 예를들어 반품접수 단계에서 고객에게 환불 예정금액이나, 반품 배송비를 사전에 안내하는 기능도 쉽게 도입이 가능해졌습니다. 이러한 개선 사례는 다음 포스팅에서 자세히 다룰 예정입니다.

마치며

이번 레거시 탈출은 단순한 기술 전환이 아니라, 도메인 중심의 로직 재설계 과정이었습니다. 또한, 기술 부채 해결 과정이 고객 신뢰와 비즈니스 성장으로 직결됨을 깨닫게 된 중요한 작업이었습니다.

앞으로는 고객의 불만이 더 깊어지지않고 신뢰받을 수 있는 올리브영이 되도록 교환/반품 모듈의 개선은 계속될 예정입니다. 저희의 경험이 비슷한 고민을 하는 분들께 도움이 되기를 바랍니다.

대규모 프론트엔드 아키텍처의 새로운 패러다임 - Part 2. 모듈 페더레이션 PoC

Thu, 06 Nov 2025 15:00:00 GMT

📖 목차

개요

모듈 페더레이션(Module Federation - MF) 넌 뭐니?

MF의 특징은 뭐가 있을까?

MF의 구현 방법은?

MF를 구성해보고 느낀 점은?

참고 자료

개요

안녕하세요, 올리브영 내 프론트엔드 개발을 담당하고 있는 노땅 문지훈🦊 입니다.

대규모 프론트엔드 아키텍처의 새로운 패러다임 - Part 1. 마이크로프론트엔드 너 뭐야?

대규모 프론트엔드 아키텍처의 새로운 패러다임 - Part 2. 모듈 페더레이션 PoC

대규모 프론트엔드 아키텍처의 새로운 패러다임 - Part 3. Nx를 활용한 마이크로프론트엔드

Part 1에서는 MFE(Micro Frontend)의 개념을 정리했습니다. 이제 구현으로 시선을 옮겨 보겠습니다. Part 2의 핵심은 모듈 페더레이션입니다. 레포지토리 전략과 무관하게, 런타임에 모듈을 공유해 MFE를 구현하는 아키텍처 패턴이죠. 이어지는 Part 3에서는 모듈 페더레이션을 더 쉽게 적용하도록 돕는 도구인 Nx를 다룰 예정입니다.

이번 글에서는 내부 PoC(Proof of Concept)를 통해 확인한 모듈 페더레이션의 핵심 개념, 장단점, 그리고 구현 방법을 차례로 살펴보겠습니다. 그럼 저와 같이 출발해 보실까요~ 🚀

모듈 페더레이션(Module Federation - MF) 넌 뭐니?

MF 로고

MF는 JavaScript 애플리케이션의 분산화를 위한 아키텍처 패턴입니다. (서버 측의 마이크로서비스와 유사) 이를 통해 여러 JavaScript 애플리케이션(또는 마이크로 프론트엔드) 간에 코드와 리소스를 공유할 수 있습니다.

MF를 도입해서 얻는 이점은 아래와 같습니다.

코드 중복 감소

코드 유지 관리성 개선

애플리케이션의 전체 크기 감소

애플리케이션 성능 향상

간단히 런타임에 여러 코드 및 리소스를 병합하는 기술이라고 이해하면 됩니다. 쉽죠잉?

A 애플리케이션 모듈을 수정한다고 가정해봅시다. 만약 빌드 타임에 통합하면, A를 사용하던 B, C 애플리케이션도 다시 빌드/배포해야 합니다. 그러면 마이크로프론트엔드의 장점인 독립적 배포가 어려워지죠. 반대로 런타임에 통합하면, B, C 애플리케이션에서 별도 배포 없이 A 애플리케이션의 변경 사항을 실시간 반영할 수 있습니다. 다시 말해 런타임에 각 서비스를 개별 배포하고, 동적으로 로딩할 수 있습니다.

자주 사용되는 개념

호스트(Host) 애플리케이션: 다른 마이크로 프론트엔드를 로드하여 통합하는 주 애플리케이션입니다.

리모트(Remote) 애플리케이션: 자신의 모듈을 외부에 노출하여 다른 애플리케이션에서 이를 사용할 수 있도록 하는 독립적인 마이크로 프론트엔드입니다.

모듈: Webpack 또는 Vite로 번들링 가능한 리소스입니다. (JS, CSS, HTML, JSON, Asset ..)

Local: 현재 애플리케이션 내 단일 빌드에 포함되는 일반적인 모듈입니다.

Expose: 원격 모듈로 노출할 부분을 지정합니다. (expose하면 Host가 원격 모듈의 코드를 사용할 수 있게 됩니다.)

Container: 다른 애플리케이션에서 로드 가능한 단위입니다.

Shared Dependencies: 여러 애플리케이션(Host, Remote) 간에 공유할 의존성(라이브러리)입니다. MF는 설정된 공유 의존성을 버전까지 고려하여 중복 로드를 방지하고 효율적으로 관리해 줍니다. 예를 들어, Host와 Remote가 모두 React v18을 사용한다면, 브라우저에는 React v18 코드가 한 번만 로드됩니다. (Singleton 개념)

언제 사용할까?

MF는 다음 시나리오에 적합합니다.

대규모 애플리케이션: 대규모 애플리케이션의 경우 애플리케이션을 여러 개의 마이크로 프론트엔드로 나누고 MF를 사용하여 이들 간에 코드와 리소스를 공유할 수 있습니다.

마이크로 프론트엔드 아키텍처: MF는 마이크로 프론트엔드 아키텍처를 구축하는 데 이상적인 도구입니다.

큰 규모의 개발팀: MF는 여러 팀이 대규모 애플리케이션을 공동으로 개발하는 데 도움을 줄 수 있습니다.

MAU 800-900만 명을 돌파하며 성장 중인 올리브영은 거대한 트래픽과 수많은 기능이 업데이트되는 환경인만큼, 기존의 모놀리식 프론트엔드 구조는 배포 병목, 코드베이스 복잡성 등 개발 속도를 저해하는 한계에 봉착했습니다.

이러한 문제 해결과 올리브영의 넥스트 비전 달성을 위해, 저희는 MF를 어떠한 구성 방식으로 사용하면 좋을 지 검토하였고, 이 구조적 문제를 해결할 핵심 기술인 MF의 Next.js 기반 PoC 과정과 결과를 이번에 공유하게 되었습니다.

이를 통해 해결하고자 하는 문제가 뭐야?

프로젝트 규모가 커지고 복잡해짐에 따라 다양한 문제에 직면하게 됩니다.

중복 개발: 프로젝트가 커질수록 비슷한 기능이나 컴포넌트가 여러 부분에서 중복 구현되는 경우가 많아집니다.

업무 결합도 증가: 프로젝트가 커질수록 하나의 팀이 아닌 다양한 팀이 하나의 코드베이스를 공유하게 되어 의존성 및 복잡성이 증가합니다. 또 팀 간 협업 과정에서 충돌과 병목현상이 발생합니다.

응집도 낮음: 다양한 기능이 하나의 애플리케이션에 있다보니 응집도가 떨어집니다. 특정 기능을 수정하거나 확장할 때 전체 시스템에 대한 이해가 필요하여 코드 품질 관리가 어려워집니다.

장애파급범위: 시스템의 한 부분에서 발생한 문제가 전체 애플리케이션에 영향을 미칠 수 있습니다. 또한 문제 발생 시 근본 원인을 찾아 해결하는데 비교적 많은 시간과 노력이 필요합니다.

배포시간증가: 전체 애플리케이션을 한 번에 빌드하고 배포해야 하므로 시간이 오래 걸립니다. 작은 변경사항에도 전체 애플리케이션을 다시 배포해야 합니다.

이런 문제들을 해결하고자 하는 니즈는 누구나 가지고 있을 것입니다. 그 문제를 해결하는 여러 방법 중 하나가 MF라고 생각하면 될 것 같아요.

마이크로 프론트엔드에서 말하는 각 통합 방식 추천 환경

빌드 통합 방식 추천 상황

소규모 팀으로 단일 레포지토리에서 개발하는 경우

성능과 SEO가 매우 중요한 경우

기술 스택이 통일된 경우

런타임 통합 방식 추천 상황

여러 팀이 독립적으로 개발하는 경우

독립적인 배포와 확장성이 중요한 경우

다양한 기술 스택을 사용해야 하는 경우

점진적인 마이그레이션이 필요한 경우

MF의 특징은 뭐가 있을까?

MF 런타임 통합

모놀리식과 차이점은?

일반적인 모놀리식과의 차이를 비교해봤습니다.

특징 모놀리식 프론트엔드 마이크로 프론트엔드

코드베이스 단일 거대 코드베이스 여러 개의 작은 코드베이스

개발 모든 팀이 동일 코드베이스 작업 팀별 독립적인 코드베이스 작업

배포 전체 애플리케이션 단위 배포 마이크로 앱 단위 독립 배포 가능

기술 스택 단일 기술 스택 (변경 어려움) 기술 스택 다양성 가능 (점진적 변경 용이)
팀 구조 기능별 팀 또는 거대 단일 팀 기능 중심 자율적 팀

결합도 높음 (변경 영향 범위 큼) 낮음 (변경 영향 범위 제한적)

복잡성 초기에는 낮으나, 규모 증가 시 급증 초기 설정 복잡성 높음, 개별 앱은 단순

MF를 사용하면 얻을수 있는 이점과 발생할 수 있는 이슈는?

이점

개발 속도 향상 - 여러 팀이 동시에 독립적으로 작업할 수 있어 전체 개발 속도가 빨라집니다. 다른 팀의 작업을 기다릴 필요가 없습니다.

유지보수성 향상 - 코드베이스가 작고 집중되어 있어 이해하기 쉽고 디버깅하기도 쉬워집니다. 거대한 코드베이스에서 버그 찾는 것보다 훨씬 효율적입니다.

확장성 개선 - 새로운 기능이나 팀을 쉽게 추가할 수 있습니다. 기존 코드를 건드리지 않고 새 마이크로 프론트엔드를 추가하면 됩니다.

기술 부채 관리 - 전체 애플리케이션을 한 번에 리팩토링할 필요 없이 한 번에 하나의 마이크로 프론트엔드를 현대화할 수 있습니다. "이번 분기에는 검색 기능만 React 18로 업그레이드하자!" 같은 접근이 가능합니다.

장애 격리 - 한 마이크로 프론트엔드의 문제가 전체 애플리케이션에 영향을 미치지 않습니다. 결제 시스템에 버그가 있어도 사용자는 여전히 콘텐츠를 탐색할 수 있습니다.

점진적 업그레이드 - 레거시 애플리케이션을 한 번에 하나씩 마이크로 프론트엔드로 전환할 수 있습니다. 빅뱅 방식의 리팩토링보다 훨씬 안전합니다.

발생할 수 있는 이슈

1. 성능 관련 이슈

초기 로딩 시간 증가

여러 마이크로 프론트엔드를 별도로 로드해야 하므로 초기 로딩 시간이 길어질 수 있습니다.

여러 자바스크립트 번들을 다운로드하는 과정에서 네트워크 요청이 증가합니다.

런타임 오버헤드

여러 애플리케이션이 동시에 실행되면서 메모리 사용량이 증가할 수 있습니다.

브라우저 리소스 경쟁으로 인한 성능 저하가 발생할 수 있습니다.

2. 의존성 관리 이슈

공유 라이브러리 충돌

여러 마이크로 프론트엔드가 다른 버전의 동일한 라이브러리를 사용할 경우 충돌이 발생할 수 있습니다.

예를 들어, 한 마이크로 프론트엔드는 React 18을 사용하고 다른 하나는 React 17을 사용하면 문제가 발생합니다.

전역 상태 관리 복잡성

여러 마이크로 프론트엔드 간 상태 공유가 복잡해집니다.

Redux, Context API 등을 통한 상태 관리가 어려워질 수 있습니다.

3. 스타일 관련 이슈

CSS 충돌

글로벌 CSS가 다른 마이크로 프론트엔드의 스타일을 덮어쓸 수 있습니다.

클래스 이름 충돌이 발생할 수 있습니다.

일관된 디자인 시스템 유지 어려움

여러 팀이 독립적으로 개발할 경우 일관된 UI/UX를 유지하기 어려울 수 있습니다.

테마 관리, 다크 모드 등의 전역 스타일 적용이 복잡해집니다.

4. 라우팅 관련 이슈

라우팅 충돌

각 마이크로 프론트엔드가 자체 라우터를 가질 경우 라우팅 충돌이 발생할 수 있습니다.

브라우저 히스토리 관리가 복잡해집니다.

딥 링킹 문제

특정 상태나 페이지로 직접 이동하는 딥 링크 구현이 어려울 수 있습니다.

브라우저 새로고침 시 상태가 유지되지 않을 수 있습니다.

5. 통신 관련 이슈

컴포넌트 간 통신 복잡성

마이크로 프론트엔드 간 이벤트 기반 통신이 복잡해질 수 있습니다.

타입 안전성 보장이 어려울 수 있습니다.

API 중복 호출

여러 마이크로 프론트엔드가 동일한 API를 중복 호출할 가능성이 있습니다.

캐싱 전략이 복잡해질 수 있습니다.

6. 개발 및 배포 복잡성

환경 구성 복잡성

개발, 테스트, 스테이징, 프로덕션 환경 구성이 복잡해집니다.

로컬 개발 환경 설정이 어려울 수 있습니다.

배포 파이프라인 복잡성

각 마이크로 프론트엔드의 배포 버전 관리가 복잡해집니다.

롤백 전략 구현이 어려울 수 있습니다.

7. 테스트 관련 이슈

통합 테스트 어려움

마이크로 프론트엔드 간 통합 테스트가 어려워집니다.

E2E 테스트 구성이 복잡해질 수 있습니다.

모킹 복잡성

다른 마이크로 프론트엔드의 기능을 모킹하는 것이 복잡해질 수 있습니다.

8. SEO. 및 접근성 이슈

SEO 최적화 어려움

클라이언트 사이드에서 동적으로 로드되는 마이크로 프론트엔드는 SEO 최적화가 어려울 수 있습니다.

메타 태그 관리가 복잡해질 수 있습니다.

접근성(A11y) 관리

여러 팀이 개발할 경우 일관된 접근성 표준을 유지하기 어려울 수 있습니다.

스크린 리더와 같은 보조 기술과의 호환성 문제가 발생할 수 있습니다.

MF를 구성하다보면 위와 같은 이슈들이 발생할 수 있기 때문에 MF를 구성하기 전 고려해야 할 부분들을 확실하게 고민해보고 설계하고 선택하면 좋을 것 같습니다.

고려해야 할 부분들

런타임 통합 방식의 마이크로 프론트엔드는 많은 이점을 제공하지만, 다양한 기술적 이슈가 발생할 수 있습니다. 대규모 프론트엔드 아키텍처의 새로운 패러다임 - Part 3. Nx를 활용한 마이크로프론트엔드 에서 공유드릴 내용이기도 하지만 Nx를 활용하면 이러한 이슈들을 효과적으로 해결하면서 마이크로 프론트엔드의 장점을 활용할 수 있습니다.

해결책을 구현할 때는 다음과 같은 방법을 고려하세요.

설계 단계부터 고려 - 마이크로 프론트엔드 경계, 통신 방식, 공유 리소스 등을 미리 설계

팀 간 표준화 - 코딩 표준, 컴포넌트 설계 원칙, 스타일 가이드 등 공유

점진적 도입 - 한 번에 모든 것을 마이크로 프론트엔드로 전환하기보다 점진적으로 도입

모니터링 및 성능 최적화 - 지속적인 모니터링과 성능 개선

만약 Next.js를 사용 중이라면 놓치지 말아야 할 이슈가 있습니다. 현재 Page Router만 지원하며, 2026년에는 deprecated 처리될 예정입니다. 등록된 이슈를 참고해 구현하세요. 😭

이러한 접근 방식을 통해 런타임 통합 방식의 마이크로 프론트엔드를 성공적으로 구현하고 유지할 수 있습니다.

MF의 구현 방법은?

예제로 올리브영 웹에 Next.js 프레임워크의 두 가지 환경에서 모듈 페더레이션을 구현해보았습니다. 디플롯이라는 서비스에서 응답되는 상품에 대한 데이터를 올리브영 상품카드 컴포넌트를 리모트로 가져와서 병합 후 데이터를 주입하여 사용하는 케이스 예시입니다.

모든 코드는 모듈 페더레이션 GitHub을 참고해 테스트용으로 구성했습니다. (모듈페더레이션.io 예제 github)

Webpack 설정

적용 시나리오

MF 아키텍쳐

호스트와 리모트의 개념을 아는게 중요합니다.

최상위 Host APP: 라우팅 또는 상태를 관리하는 컨테이너가 최상단 Host 역할

HomeModule APP: 최상위 Host APP의 Remote 역할과 CommonUI의 Host 역할

CommonUI: HomeModule APP에서 사용하는 Remote App 역할

HomeModule은 CommonUI에서 제공하는 ProductCard 컴포넌트를 활용하여 페이지를 구성하고 최상위 Host에서 해당 HomeModule을 활용하여 페이지를 구성합니다.

Host

const NextFederationPlugin = require("@module-federation/nextjs-mf"); webpack(config, options) { config.module.rules.push(videoFileLoaderOptions); const { isServer } = options; const getRemotes = () => { const location = isServer ? "ssr" : "chunks"; return { HomeModule: `HomeModule@http://localhost:3001/_next/static/${location}/remoteEntry.js`, }; }; config.plugins.push( new NextFederationPlugin({ name: "host", remotes: getRemotes(), filename: "static/chunks/remoteEntry.js", exposes: { }, extraOptions: { debug: true, automaticAsyncBoundary: true, enableImageLoaderFix: true, enableUrlLoaderFix: true, }, shared: { // react-query의 의존성을 같이 공유해서 싱글톤 객체로 사용한다. 버전이 달라서 생기는 문제를 해소할 수 있다. (완전해소 아님) "@tanstack/react-query": { singleton: true, requiredVersion: false, }, "@tanstack/core": { singleton: true, requiredVersion: false, }, }, }) ); return config; },

Remote

HomeModule (CommonUI APP의 호스트이자 Host APP의 리모트)

const NextFederationPlugin = require("@module-federation/nextjs-mf"); webpack(config, options) { const plugins = [...config.plugins]; const { isServer } = options; const getRemotes = () => { const location = isServer ? "ssr" : "chunks"; return { host: `host@http://localhost:3000/_next/static/${location}/remoteEntry.js`, CommonUI: `CommonUI@http://localhost:3002/_next/static/${location}/remoteEntry.js`, }; }; plugins.push( new NextFederationPlugin({ name: 'HomeModule', filename: 'static/chunks/remoteEntry.js', exposes: { './home': './src/pages/home-module', }, remotes: getRemotes(), extraOptions: { debug: true, exposePages: true, automaticAsyncBoundary: true, enableImageLoaderFix: true, enableUrlLoaderFix: true, }, shared: { // react-query의 의존성을 같이 공유해서 싱글톤 객체로 사용한다. 버전이 달라서 생기는 문제를 해소할 수 있다. (완전해소 아님) "@tanstack/react-query": { singleton: true, requiredVersion: false, }, "@tanstack/core": { singleton: true, requiredVersion: false, }, }, }), ); };

공통 컴포넌트

CommonUI

const NextFederationPlugin = require("@module-federation/nextjs-mf"); webpack(config, options) { const plugins = [...config.plugins]; const { isServer } = options; const getRemotes = () => { const location = isServer ? "ssr" : "chunks"; return { HomeModule: `HomeModule@http://localhost:3001/_next/static/${location}/remoteEntry.js`, }; }; plugins.push( new NextFederationPlugin({ name: 'CommonUI', filename: 'static/chunks/remoteEntry.js', exposes: { "./ProductCard": "./src/ProductCard/index.tsx", "./ProductCards": "./src/ProductCards/index.tsx", }, remotes: getRemotes(), extraOptions: { debug: true, exposePages: true, automaticAsyncBoundary: true, enableImageLoaderFix: true, enableUrlLoaderFix: true, }, shared: { // react-query의 의존성을 같이 공유해서 싱글톤 객체로 사용한다. 버전이 달라서 생기는 문제를 해소할 수 있다. (완전해소 아님) "@tanstack/react-query": { singleton: true, requiredVersion: false, }, "@tanstack/core": { singleton: true, requiredVersion: false, }, }, }), ); };

CSR

적용

첫 번째는 CSR 환경입니다. react 환경에서 사용할 수 있습니다.

HomeModule - CommonUI에 있는 ProductCard와 ProductCards를 런타임에 병합하여 가져옵니다.

import { lazy, Suspense } from "react"; import { Layout } from "@common/components"; const ProductCard = typeof window === "undefined" ? (): null => null : lazy(() => import("CommonUI/ProductCard")); const ProductCards = typeof window === "undefined" ? (): null => null : lazy(() => import("CommonUI/ProductCards")); const Page = () => { return ( <Layout> <Suspense fallback={<div>로딩 중...</div>}> { Array.from({length: 20}).map((productProps, idx) => ( <Anchor href={productTargetUrl}> <ProductCards layout="TYPE_3"> <ProductCard {...productProps} /> </ProductList> </Anchor> ) } </Suspense> </Layout> ); }; export default Page;

Host

import { lazy, Suspense } from "react"; import { Layout } from "@common/components"; const HomeModule = typeof window === "undefined" ? (): null => null : lazy(() => import("HomeModule/home")); const Page = () => { return ( <Layout> <Suspense fallback={<div>로딩 중...</div>}> <HomeModule /> </Suspense> </Layout> ); }; export default Page;

결과

MF CSR 결과 - 올리브영 앱에서 특정 페이지 일부를 MF 적용한 모습

CommonUI의 상품 카드 컴포넌트를 리모트로 가져와서 HomeModule 컴포넌트에 일부분에 적용하였습니다. CSR일 경우 Nextjs에서 응답한 HTML에 해당 컴포넌트에 대한 HTML이 첨부되지 않은 채로 응답됩니다.

SSR

적용

두 번째는 SSR 환경입니다. 예제 코드에서 보시다시피 nextjs 환경에 영향을 받습니다.

HomeModule - CommonUI에 있는 ProductCard와 ProductCards를 런타임에 병합하여 가져옵니다.

import { lazy, Suspense } from "react"; import { dehydrate, QueryClient, useQuery } from '@tanstack/react-query'; import { Layout } from "@common/components"; const ProductCard = typeof window === "undefined" ? (): null => null : lazy(() => import("CommonUI/ProductCard")); const ProductCards = typeof window === "undefined" ? (): null => null : lazy(() => import("CommonUI/ProductCards")); const Page = () => { // 예시 const res = useQuery(queryOptions({ queryKey: ['products'], queryFn })); return ( <Layout> <Suspense fallback={<div>로딩 중...</div>}> { res.products.map((productProps, idx) => ( <Anchor href={productTargetUrl}> <ProductCards layout="TYPE_3"> <ProductCard {...productProps} /> </ProductList> </Anchor> ) } </Suspense> </Layout> ); }; export default Page; export async function getServerSideProps() { const queryClient = new QueryClient(); await queryClient.prefetchQuery(queryOptions({ queryKey: ['products'], queryFn, staleTime: 5000, })); return { props: { dehydratedState: dehydrate(queryClient), }, }; }

Host

import type { GetServerSidePropsContext } from "next"; import dynamic from "next/dynamic"; import { Layout } from "@common/components"; const HomeModule = dynamic(() => import("HomeModule/home"), { ssr: true, loading: () => <p>Loading...</p> }); export default function Page(props: any) { return ( <Layout> <ShopPage {...props} /> </Layout> ); } export async function getServerSideProps(context: GetServerSidePropsContext) { const Remote = await import("HomeModule/home"); return Remote.getServerSideProps(context); }

결과

MF SSR 결과 - 올리브영 앱에서 특정 페이지 일부를 MF 적용한 모습

MF SSR 결과 - 파싱된 HTML 결과

서버사이드 렌더링을 판단하는 기준은 Nextjs에서 응답된 HTML에 비동기로 받아온 데이터를 기준으로 HTML 내에 렌더한 엘리먼트 노드들이 첨부되어 있는 것을 확인하면 됩니다.

MF를 구성해보고 느낀 점은?

Module Federation 필요성과 원격 모듈 로딩 원리에 대해서 파악해 보았으나 아직은 사용하기에 불편한 점이 PoC간에 몇 가지 있었습니다.

원격 모듈을 추가할 때마다 웹팩 설정을 함께 수정해야 했습니다.

아주 큰 규모의 개발팀과 어플리케이션에 적합한 아키텍쳐라고 설명하고 있는데 만약에 수많은 모듈들과 함께 사용하게 된다면 expose를 계속적으로 수정해야 할텐데 이 부분이 파일명 오타 및 exposes 목록 내 누락등의 휴먼에러가 발생할 여지가 있어 이를 자동화 할 수 있는 방법이 필요하다고 생각했습니다.

원격 모듈을 추가할 때마다 호스트 어플리케이션에서 타입을 정의해 주어야 했습니다.

원격 모듈을 추가할 때마다 호스트 어플리케이션을 수정해야 했었고 이는 독립적 개발 및 배포라는 장점과 모순되는 부분이기도 했습니다. 또한 type safe 하게 설정해야 하는데 이를 자동화 할 수 있는 방법을 구현해 활용하지 못한게 많이 아쉬웠는데 이 부분을 자동화 한다면 원격모듈 추가가 쉬워질 것이라 생각했습니다.

SSR 환경의 모듈을 구현하기가 매우 어려웠습니다.

레퍼런스를 보니 왜 SPA 위주의 MF 예제만 있는지 이해할 수 있었습니다. Nextjs의 page router만 지원하는 것과 getServerSideProps 등을 가져와야 하는 부분들등이 구현하기 매우 까다로웠습니다.

이처럼 MF의 잠재력은 확실하지만, 대규모 프론트엔드 환경에서 수많은 모듈과 팀이 이 기술을 효율적이고 안전하게 활용하려면 PoC 과정에서 발견된 이 불편함들을 반드시 자동화하고 체계화해야 합니다. 과연 올리브영 프론트엔드 개발자들은 이 '수동 설정' 과 '타입 안전성' 이라는 난관을 어떻게 극복하고, Next.js 기반 MFE 아키텍처를 성공적으로 정착시키려고 할까요?

다음 Part 3에서는 이 문제들을 해결하기 위한 선택지, Nx를 활용한 올리브영의 MFE 아키텍처 구현 전략을 구체적으로 공개합니다. Part 3도 놓치지 마세요! 그리고 못다 한 이야기는 향후 이런 구성으로 풀어보겠습니다. 기대 많이 해주세요!

MF를 실제 운영 환경에 배포하고 모니터링 해본 경험

MF를 Type Safe하게 사용해보려 시도한 내용

Zephyr MF Devtools 활용한 경험

이상으로 MF PoC편을 마치도록 하겠습니다. 딱딱하고 긴 글이었는데 읽어주셔서 정말 감사드립니다.

참고 자료

모듈페더레이션.io

모듈페더레이션.io 공식 Nextjs 문서

모듈페더레이션.io 예제 github

Spring Cloud Config & Bus-Refresh 도입기

Tue, 04 Nov 2025 17:38:00 GMT

🎶 마이크로서비스 오케스트라 지휘법: Spring Cloud Config로 실시간 설정 변경하기

배포 없이 실시간으로 설정을 바꾸는 지휘자의 비밀 노트

안녕하세요! 올리브영 상품통합프로젝트의 하모니를 책임지고 있는 불광동꿀주먹👊입니다.

"설정값 딱 하나 바꾸려는데, 전체 서버를 다 재시작해야 한다고요? 그게 최선인가요?" 🤔

이런 고민, 개발자라면 한 번쯤 해보셨을 겁니다. 저희 팀도 얼마 전까지 설정 파일의 작은 수정 하나 때문에 전체 오케스트라의 연주(서버 배포)를 멈춰야 하는 아찔한 상황을 겪곤 했죠. 각자 다른 악보(설정)를 보고 연주하는 연주자들처럼, 서비스마다 설정이 꼬이는 일도 상상하기 싫은 현실이었습니다.

하지만 이 모든 혼란을 잠재울 멋진 지휘봉을 발견하며 저희 프로젝트는 새로운 국면을 맞이했습니다. 바로 Spring Cloud Config Server와 Bus-Refresh를 도입한 것이죠. 🎼

설정 변경을 위해 더 이상 서비스 전체를 멈추지 않아도 되는, 우아하고 조화로운 저희 팀의 개발 여정을 여러분께 공유해 드립니다. 자, 이제 저희 오케스트라의 변화를 함께 감상해 보시죠! 🚀

🎼 문제의 시작: 조율되지 않는 오케스트라

저희는 상품통합프로젝트를 진행하면서 여러 마이크로서비스(MSA)를 운영하고 있습니다. 그러다보니 여러 프로젝트가 공통으로 사용하는 설정값, 예를 들면 온라인 상품 조회 API가 변경될 때마다 문제가 발생했죠.

하나의 설정을 바꾸기 위해 연관된 모든 서비스를 다시 빌드하고 배포하는 과정은 비효율의 극치였습니다. 연주 중간에 악보 한 장을 바꾸려고 전체 오케스트라를 무대 뒤로 보내는 것과 같았죠.

저희에게는 모든 연주자(서비스)에게 변경된 악보(설정)를 실시간으로 전달해 연주의 흐름을 끊지 않을 방법이 절실했습니다.

💡 우리의 지휘봉을 찾아서: 해결책 모색

이러한 문제를 해결하기 위해 저희는 Spring Cloud Config Server를 도입했습니다.

이 솔루션은 분산된 여러 서비스의 설정값(악보)을 Git과 같은 중앙 저장소에서 통합 관리하고, 변경이 생겼을 때 각 서비스에 실시간으로 동기화하는 지휘자 역할을 합니다.

다양한 솔루션을 비교 검토한 결과, Spring Cloud Config Server가 저희 오케스트라에 가장 적합한 지휘봉이라고 판단했습니다.

특히 Git을 통한 버전 관리 및 롤백 기능, Spring Cloud Bus와 연동하여 여러 서비스에 한 번에 설정을 전파하는 bus-refresh 기능 은 저희에게 꼭 필요한 기능이었습니다.

마지막까지 고민했던, AWS Parameter Store 와의 비교자료는 아래와 같습니다.

Spring Cloud Config Server 🆚 AWS Parameter Store

항목 Spring Cloud Config Server AWS Parameter Store

기본 기능 Git 기반 설정파일 외부화, 분산 어플리케이션 구성 관리 Key-Value 설정 저장, 버전관리, IAM 인증

특징 Git, Vault 등 외부 저장소와 연동, 복잡한 구성 가능 AWS Managed, IAM 권한 기반 접근 제어

장점 강력한 설정 파일 구조화 및 프로파일별 관리 서버리스, 쉬운 접근, 고가용성

단점 자체 구성 필요, 운영 오버헤드 발생 가능 Git 버전관리 불가, 설정 계층 표현이 제한적

🏗️ 조화로운 연주를 위한 설계도: 아키텍처

Spring Cloud Config & Bus-Refresh 도입 아키텍처

저희는 위와 같은 아키텍처를 통해 실시간 설정 변경 시스템을 구축했습니다.

전체 연주(프로세스)는 이렇게 진행됩니다.

작곡가 (AWS General User) 가 악보(설정)를 수정하여 Git에 Push합니다.

지휘자 (Spring Cloud Config Server) 가 TeamCity의 트리거를 통해 변경을 감지합니다.

지휘자는 /actuator/busrefresh 엔드포인트를 호출하여 "악보가 바뀌었어!"라고 외칩니다.

이 외침은 음파 (Amazon MQ) 를 통해 모든 연주자 (Spring Boot MicroService) 에게 순식간에 퍼져나갑니다.

각 연주자는 새로운 악보를 받아 즉시 연주에 반영합니다.

🛠️ 악기 튜닝하기: 상세 구현 과정

지휘봉을 손에 넣었으니, 이제 각 악기(서비스)를 세심하게 튜닝할 차례입니다.

적용 범위

이 시스템은 API 설정값이나 DB Endpoint처럼 외부에서 주입받는 값들에 적용하기 좋습니다. (단, DB Endpoint와 같은 DataSource 설정을 실시간으로 변경하려면, 해당 DataSource 빈(Bean)에도 @RefreshScope를 적용하고 Spring 2.x 이상 버전의 DataSource 구성 방식을 사용해야 합니다.)

하지만 주의할 점도 있습니다. Java나 Kotlin의 DTO 클래스 필드처럼 컴파일 시점에 구조가 고정되는 경우에는 적용할 수 없습니다. 연주 중간에 바이올린을 첼로로 바꿀 수 없는 것과 같은 이치죠.

Spring의 @RefreshScope는 빈(Bean)을 새로고침하는 수준이지, 클래스의 구조 자체를 바꾸지는 못하기 때문입니다.

⚙️ 설정 방법

🚨 주의사항 : Spring Boot의 버전에 따라 설정 방법이 상이합니다

https://spring.io/projects/spring-cloud

해당 사이트를 참고하여, 각 스프링부트 버전에 대응하는 spring-cloud-dependencies:2020.0.3 버전을 설정해주셔야 합니다

Spring Cloud Config Dependencies

Spring Boot 2.3.x 이하:

bootstrap.yml 파일 필요

spring.cloud.config.uri 설정 방식

Spring Boot 2.4.x 이상:

spring.config.import 방식 (본 가이드 기준)

bootstrap.yml 불필요 (선택적)

참고: Spring Boot 2.4 Release Notes

build.gradle.kts (domain, interface패키지 하위) 의존성 추가

dependencies { implementation("org.springframework.boot:spring-boot-starter-actuator") implementation("org.springframework.cloud:spring-cloud-starter-config") implementation("org.springframework.cloud:spring-cloud-starter-bus-amqp") } dependencyManagement { imports { mavenBom("org.springframework.cloud:spring-cloud-dependencies:2020.0.5") } }

application.yml 또는 application-.yml에 아래와 같이 설정

spring: application: name: test-application config: import: optional:configserver:http://spring-cloud-config-server.com activate: on-profile: "qa"

설정 적용을 위한 actuator endpoint 활성화

management: endpoints: web: exposure: include: health, info, refresh, busrefresh

rabbitMQ 설정 추가(계정정보는 config-server에서 암호화되어 설정)

rabbitmq: host: b-1234-4567-8900-abcd-123456789.mq.ap-northeast-2.on.aws port: 5671 virtual-host: / ssl: enabled: true `

호출하려는 클래스에 @RefreshScope 어노테이션 추가, @Value 어노테이션으로 값 주입

@RefreshScope @Service class TestServiceImpl( val testRepository: TestRepository ) : TestService { @Value("\${config.goods-api-url}") lateinit var goodsApi: String }

✨ 클라이맥스: 실시간 변경의 순간

모든 튜닝이 끝나고, 드디어 지휘를 시작할 시간입니다. 개발자가 Git에 변경된 설정값을 Push하자, TeamCity가 이를 감지하여 busrefresh를 자동으로 호출합니다.

BusRefresh 수동 호출 Teamcity Trigger 설정 자동호출

curl --location --request POST 'http://spring-cloud-config-server.com/actuator/busrefresh' github push Trigger로 동작하여 actuator/busrefresh 호출!

곧이어 서비스 로그에는 변경된 설정 키들이 새로고침되었다는 메시지가 나타납니다.

2025-06-21 01:45:19.733 [INFO] (RefreshListener.java:50) Keys refreshed [config.goods-api-url] [cite: 149]

그리고 마법처럼, 서버 재시작 없이 API 응답값이 즉시 변경된 것을 확인할 수 있었습니다.

이로써 단순 설정 변경을 위한 배포 시간이 기존 평균 20분에서 1분 이내로 단축되었고, 긴급 상황 발생 시 운영 서버의 재시작 부담 없이 신속하게 대응할 수 있는 안정성을 확보했습니다.

이 모든 과정이 끝나면 Slack으로 알림 메시지가 전송되어, 모든 오케스트라 단원들이 변경 사항을 인지하게 됩니다.

Config Server 알럿 메시지(Config 변경 내역 전송)

Config Server 알럿 메시지(Config 변경 내역 전송)

🚀 앙코르: 표준화와 다음 연주를 향하여

저희는 이 경험을 바탕으로, 해당 시스템 구성을 올리브영 개발센터의 표준 아키텍처 템플릿(olive-plate)에 적용했습니다.

이제 누구나 이 강력한 지휘봉을 사용하여 조화로운 마이크로서비스 오케스트라를 구성할 수 있게 된 것이죠.

급변하는 기술의 세계 속에서, 마치 시간에 쫓기는 토끼처럼 쉼없이 달려가던 저희는 잠시 멈춰 서서 이 오케스트라를 조율하는 법을 배운 셈입니다.

이제 저희의 오케스트라는 지휘자의 손짓 하나(git push)에 일사불란하게 연주를 바꾸는 환상적인 하모니를 자랑하게 되었습니다.

저희의 다음 연주가 궁금하시다면, 올리브영 기술 블로그를 계속 주목해주세요! 🎶

References

Spring Cloud 공식 문서

Spring Cloud Config 공식 문서

Spring Cloud Bus 공식 문서

SDUI로 네이티브 운영 민첩성 높이기

Tue, 04 Nov 2025 17:30:00 GMT

들어가며

안녕하세요, 올리브영 웰니스서비스 개발팀에서 안드로이드 앱을 개발하고 있는 차니혀니 입니다. (집에서는 두 아들의 아빠이기도 합니다.)

앱을 운영하다 보면 스토어 심사라는 벽 앞에서 한숨 쉬어본 경험, 다들 있으실 겁니다. 특히 빠르게 변화하는 이커머스 환경에서 네이티브 앱의 업데이트 속도는 비즈니스의 발목을 잡기도 합니다. 이러한 '속도의 한계'를 극복하고, 스토어 심사없이 서버 설정만으로 화면을 변경하는 라는 여정을 시작했습니다. 이 글에서는 저희가 SDUI를 어떻게 설계하고, 어떤 문제들을 고민하였는지 그 경험을 공유하고자 합니다.

우리의 고민: 속도, 일관성, 효율 그리고 SDUI

웹과 달리 네이티브 앱은 배포 후 이슈가 생겨도 스토어 심사로 인해 즉각 대응이 어렵습니다. 그래서 빠르게 수정이 필요할 때 사용자에게 반영되기까지 시간이 소요됩니다. 그래서 저희의 고민은 명확했습니다. 앱 배포를 어떻게 해야 빠르면서, 일관성있고, 효율적일까? 이런 맥락에서 속도, 일관성, 효율 이라는 세 가지 핵심 문제를 극복하기 위한 솔루션이 바로 SDUI(Server-Driven UI) 입니다. SDUI는 화면 정보를 서버에서 내려주고, 앱은 그 데이터를 기반으로 UI를 그려내는 방식입니다. 서버는 ‘무엇을, 어떤 순서로’ 보여줄지에 집중하고, 클라이언트는 그 정보를 받아 ‘어떻게’ 빠르고 자연스럽게 그릴지에 집중할 수 있습니다.

아키텍처 정의: 작게 시작하여 점진적으로!

처음에는 역할을 나누고, 리스크를 낮추기 위해 스코프를 작게 잡은 뒤 점진적으로 확장하는 전략을 택했습니다. 우선 서버와 클라이언트가 각자 무엇에 집중해야 할지부터 정의했습니다.

서버의 역할: 강제 업데이트, 앱 버전 등 앱의 '운영'과 관련된 큰 그림을 관리하고, 화면을 그릴 '설계도(스키마)'를 제공하는 데 집중합니다.

클라이언트의 역할: 서버가 준 설계도를 네이티브 UI로 '렌더링'하고, 알 수 없는 정보가 오더라도 앱이 죽지 않도록 '안전하게 폴백'하며, 사용자의 행동(이벤트, 트래킹)을 실행합니다.

특히 초기 범위 결정이 중요했습니다. 처음부터 모든 레이아웃 속성(margin, padding 등)까지 서버가 제어하려 하면 복잡도가 걷잡을 수 없이 커질 거라 판단했습니다. 그래서 초기 범위는 '섹션, 컴포넌트, 데이터, 액션' 4가지로 한정하고, 레이아웃은 클라이언트의 디자인 시스템에 위임하여 단순함을 유지했습니다.

확장 가능한 설계의 핵심: 스키마 정의

SDUI의 성패는 서버와 클라이언트 간의 '약속', 즉 스키마를 얼마나 잘 설계하는지에 달려있습니다. 스키마가 너무 복잡하면 유지보수가 어렵고, 너무 단순하면 SDUI의 장점을 살릴 수 없습니다. 저희는 '이커머스 서비스'의 특성을 고려하여 다음과 같이 4가지 핵심 요소를 정의했습니다.

섹션 (Section): '오늘의 특가', '실시간 랭킹'처럼 독립적인 목적을 가진 컴포넌트 이상의 단위

컴포넌트 (Component): 섹션을 구성하는 '상품 카드', '헤더 타이틀' 같은 최소 단위

데이터 (Data): 컴포넌트에 채워질 실제 내용 (예: 상품명, 가격, 이미지 URL)

액션 (Action): 버튼 클릭 시 특정 페이지로 이동하거나, 분석 로그를 보내는 등 사용자의 행동을 정의

앞서 네 가지 핵심 요소를 정리했으니, 이제 각 요소의 역할과 스키마 예시를 차례로 살펴보겠습니다. 첫 번째로 '섹션'입니다.

섹션

정확한 목적을 가지고 있는 독립적인 UI 단위라 설명할 수 있습니다. 예를 들면 전시화면에서의 상단 배너섹션, 타임딜 섹션 등을 예로 들 수 있을 것 같습니다. 섹션은 아래 코드와 같이 꼭 컴포넌트 단위의 구성이 아니더라도, 해당 섹션만을 위한 필드들을 구성할 수 있습니다. 그럼 서버 관점에서 매번 컴포넌트(header, more_button, title)를 조합하지 않고 미리 정의된 데이터만 채워서 내려주면 되니 단순해집니다. 물론 공통의 요소들을 컴포넌트 단위로 정의하고 사용한다면 재사용성을 높이고 일관된 UI를 표현할 수 있는 장점도 있습니다.

// 타임딜 섹션 샘플 { "type": "TIME_DEAL_SECTION", "id": "10", "header": { "title": "타이틀", "style": "HEADER_LARGE" }, "limitTime": "2025-12-31T23:59:59Z", "totalCount": 2, "itemList": [ { "type": "CARD_TYPE", "id": 1, "code": "상품code", "title": "올리브영 상품1" }, { "type": "CARD_TYPE", "id": 2, "code": "상품code", "title": "올리브영 상품2" } ] }

컴포넌트

컴포넌트는 하나의 섹션을 만들기 위해 여러 개의 컴포넌트가 조합될 수 있는 요소로 정의할 수 있습니다. 물론 하나의 컴포넌트로 한 영역을 담당 할 수 도 있습니다. 예를 들면 header, productCard가 될 수 있겠네요. 아래 코드를 통해 몇 가지 샘플을 살펴보겠습니다.

{ "type": "HEADER_COMPONENT", "id": 10, "title": "타이틀", "style": "HEADER_LARGE" // HEADER_MEDIUM, HEADER_REGULAR }

{ "type": "HEADER_COMPONENT", "id": 11, "title": "타이틀", "handler": "이벤트 처리" }

{ "type": "PRODUCT_CARD", "id": 12, "code": "10001", "title": "올리브영 상품", "price": 9900, "imageUrl": "https://...", "badge": "HOT" }

{ "type": "FOOTER_COMPONENT", "id": 13, "title": "더 보기", "handler": "이벤트 처리" }

위의 3가지를 조합하여(HEADER_COMPONENT + PRODUCT_CARD + FOOTER_COMPONENT) 하나의 섹션을 만들어 사용할 수 있습니다. 상황에 따라 헤더 또는 푸터가 없을 수도 있어서 스키마 존재에 따라 유연하게 반응해야 합니다. 가로형 상품카드에 쓰이는 상품카드 타입은 단독으로도 노출할 수 있어야 하며, 다양한 섹션 또는 컴포넌트와 조합 가능하도록 구조화가 필요합니다.

가로형 상품섹션 구성도

데이터: 모든 플랫폼의 '공통 언어'

스키마의 세 번째 요소는 컴포넌트에 실제 내용을 채우는 '데이터'입니다. SDUI는 Android, iOS, Web이 모두 같은 스키마를 바라보기 때문에, 이 '공통 언어'의 규칙을 명확히 정의하는 것이 무엇보다 중요했습니다. (must not be null 오류를 수도 없이 경험했던 기억이... 😅)

저희는 다음과 같은 엄격한 데이터 규칙을 세웠습니다.

필수값 (Required): id, type처럼 이 값이 없으면 렌더링 자체가 불가능한 값

옵션값 (Optional): subtitle처럼 값이 없어도 UI가 깨지지 않는 값

기본값 (Default): isShow = false처럼, 값이 누락되었을 때 클라이언트가 안전하게 처리할 기본 상태

포맷 (Format): date 포맷, ImageUrl 경로 등 데이터의 형식을 통일

{ "type": "PRODUCT_CARD", "id": "12", "title": "상품명", "price": 9900, "imageUrl": "이미지 URL", "badge": "SALE", "rating": 4.6, "reviewCount": 0, "isShow": false }

액션

각 컴포넌트의 이벤트 및 로그 등을 담당하게 됩니다. 해당 설계방향은 서비스 특성에 따라 달라지게 됩니다.

{ "type": "PRODUCT_CARD", // ..... "handler": { "action": { "type": "Link", "value": "url 정보" }, //1안 "event1": { "amplitude": { "name": "product_select", "parameters": { "param1": "value1", "param2": "value2" } }, "appsflyer": { "name": "product_select", "parameters": { "param1": "value1", "param2": "value2" } } }, //2안 "event2": [ { "type": "amplitude", "event_type": "impression", "name": "product_impression", "parameters": { "param1": "value1", "param2": "value2" } }, { "type": "appsflyer", "event_type": "click", "name": "product_select", "parameters": { "param1": "value1", "param2": "value2" } } ] } }

Action의 경우 Type에 따라 동작이 달라집니다. 아래와 같이 정의해보았습니다.

Link : URL을 통해 외부,내부 브라우저로 이동 하거나 딥링크가 동작

API : API BaseUrl을 제외한 Path 정보를 제공함으로써 앱에서 별도의 하드코딩 없이 API를 요청
{ @GET suspend fun getPageInfo( @Url path: String, @Query("cursor") cursor: String? ): Result<ComponentInfoResponse> }

Event의 경우 1안은 명시적이고, 이벤트 타입이 한 곳에 모여 있는 장점이 있지만, 새로운 이벤트 추가 시 확장성이 떨어지는 단점이 있습니다. 2안이 적합한 이유에는 '확장성' 외에 '플랫폼 간 일관성'이나 '로깅 정책 통일' 관점에서도 유효한 점이 있어 권장하지만, 각 이벤트별로 파라미터 및 제공하는 스펙이 다르면 데이터 구조를 통일하는 어려움이 있습니다. 하지만 확장성을 고려하면 가장 이상적인 방법이라 볼 수 있고, 자체 로그 시스템이 존재한다면 이벤트별 라우팅을 담당하도록 위임하는게 가장 좋습니다.

사용자 경험을 극대화하는 SDUI 성능 최적화 전략

SDUI는 서버가 정의한 데이터를 클라이언트가 그대로 렌더링하는 데서 그치지 않습니다. 다양한 상황에 즉각 대응하기 위해 여러 각도에서 고려해야 할 요소들이 있습니다. 이번에는 그 고려 사항을 공유해보겠습니다.

ATF(Above-The-Fold)

스크롤 없이 가장 처음에 보이는 초기화면 영역입니다. 사용자는 해당 영역으로 서비스의 가치를 판단하기도 합니다.

ATF 전용 API 분리: 첫 화면 로딩에 필수적인 데이터만 담은 가벼운 API를 먼저 호출하고, 스크롤해야 보이는 하단 영역 데이터는 별도 API로 분리하여 비동기 처리했습니다.

초기 데이터 최소화: ATF 영역에 표시되는 섹션의 종류와 개수를 최소화하여, 클라이언트가 화면을 그리는 데 필요한 연산 부담을 줄였습니다.

이러한 최적화는 서버 응답 시간(Latency)과 클라이언트 렌더링 성능을 꾸준히 프로파일링하며 최적의 균형점을 찾아나가는 과정이 중요합니다.

Pagination: 끊김 없는 스크롤 경험

Pagination은 사용자가 스크롤을 내릴 때, 다음 페이지가 로드되고 있다는 사실조차 느끼지 못하게 만드는 것이 핵심입니다.

저희는 사용자가 리스트의 마지막에 도달하기 전, 특정 인덱스의 섹션이 보이기 시작할 때 다음 페이지 데이터를 미리 요청하도록 구현했습니다. '미리 로딩'을 시작하는 시점(인덱스)은 섹션이 화면을 차지하는 높이나 개수에 따라 달라질 수 있으므로, 각 화면의 특성에 맞게 유연하게 결정하는 것이 좋습니다.

Lazy Loading

서버 응답 시간에 영향을 미치는 개인화 영역이 있습니다. 개인화 영역의 일부 섹션이나 컴포넌트는 서버에서 캐싱 처리가 어렵기 때문입니다. 이때 Lazy Loading 기법을 활용할 수 있습니다.

Lazy Loading을 활용한 개인화 영역은 처음부터 모든 데이터를 받지 않습니다. 서버 응답을 받을 때 스켈레톤 로딩을 해당 영역에 노출하고 비동기로 API를 호출하여 유저 경험에 부정적 영향을 주지 않도록 합니다.

Lazy Loading 동작 메커니즘

페이지정보 요청

섹션 타입에 스켈레톤 Prefix가 붙은 섹션은 Lazy Loading이 필요한 요소

path를 통해서 해당 섹션에 대해 비동기 통신

새로운 응답값을 통해 UI 바인딩 처리

// 개인화 추천 섹션 템플릿 { "type": "SKELETON_SECTION_HORIZONTAL_CAROUSEL_LIST", "id": "5", "path": "해당 스켈레톤 섹션을 통해 요청할 API Path" } // Path를 통해 새롭게 받아온 개인화 데이터 { "type": "HORIZONTAL_CAROUSEL_LIST", "id": "5", "header": { "title": "타이틀" }, "items": [ { "type": "PRODUCT_CARD", "id": "상품1" }, { "type": "PRODUCT_CARD", "id": "상품2" } ], "footer": null }

그 외에 고민한 요소는?

데이터가 비어있을 경우(Empty Section)

전시지면에서 정상적인 상품 리스트를 받아오지 못한 경우 에러뷰를 노출 합니다. 이런 경우에 아래와 같이 Error Section을 관리하면 에러 타입별 문구와 재시도 동작 또한 정의해서 사용할 수 있습니다.

{ "type": "ERROR_SECTION", "id": "5", "imageUrl": "이미지 Path", "title": "상품이 존재하지 않습니다", "subtitle": "다시 검색해주세요", "buttonTitle": "재시도", "handler": { "action": { "type": "API", "value": "재시도할 API PATH" } } }

클라이언트 상태와 서버 상태의 동기화

위에서 설명한 필터 버튼을 클릭한 후 활성화 여부를 클라이언트에서 관리하지 않습니다. 아래 코드에서 handler를 통해 API를 요청하고, 응답받은 데이터에 id가 5인 필터는 isSelected = true 값으로 내려오고, 이전에 선택된 필터는 false로 내려오도록 동기화되어 있습니다. 이 부분은 응답 속도에 따라 영향을 받을 수 있어, 먼저 선택한 값을 활성화하고 응답 여부에 따라 다시 롤백 또는 유지도 가능하기 때문에 상황에 맞게 메커니즘을 결정하면 됩니다.

{ "type": "FILTER_CHIP", "id": "5", "title": "필터1", "isSelected": false, "handler": { "action": { "type": "API", "value" : "API PATH" } } }

결과: 그래서 무엇이 달라졌나?

아직 정식 배포 전이지만, 저희는 이미 SDUI를 설계하고 구축하는 과정에서부터 문제를 즉각 통제할 수 있다는 강력한 변화를 체감하고 있습니다.

과거에는 치명적인 핫픽스조차 스토어 배포와 심사라는 긴급 대응이 불가능한 프로세스에 의존해야 했습니다. 하지만 이제는 문제가 된 섹션을 서버 설정만으로 즉시 비활성화 하거나 안전한 구성으로 대체할 수 있는 기술적 기반이 마련되었습니다.

A/B 테스트와 같은 실험을 진행하는 방식 자체도 근본적으로 달라졌습니다.

과거에는 동일한 실험을 위해 iOS, Android 각 플랫폼별로 개별 개발과 배포 일정을 조율하는 복잡한 과정이 필요했습니다. 이제는 기획이 확정되면 서버에서 스키마를 정의하는 단 한 번의 작업으로, iOS, Android, Web 모든 플랫폼에 '동시에' 새로운 UI를 노출할 수 있게 되었습니다.

이는 팀이 같은 타이밍에 같은 실험을 시작할 수 있음을 의미하며, 실험 준비에 드는 리드 타임이 '플랫폼 배포 주기(수일에서 수주)'에서 '서버 배포 주기(수분에서 수시간)'로 바뀌는 질적인 변화를 의미합니다.

마치며: SDUI는 만능인가?

지금까지 네이티브 앱의 고질적인 '속도의 한계'를 극복하기 위해 저희가 SDUI를 탐색하고 고민해 온 여정을 공유해 드렸습니다. 이 여정을 거치며 저희가 내린 결론은, SDUI는 만능 해결책이 아니라는 것입니다.

모든 기술이 그렇듯, SDUI 역시 명확한 트레이드오프가 존재합니다. 서버와 클라이언트가 '스키마'라는 강력한 약속으로 연결되기에 초기 설계의 복잡도가 높고, 문제가 발생했을 때 양쪽을 모두 살펴봐야 하므로 디버깅 난이도도 올라갑니다. 무엇보다 사용자의 네트워크 환경에 절대적으로 의존한다는 제약도 무시할 수 없습니다.

그렇기 때문에 핵심은 모든 화면을 SDUI로 전환하는 것이 아니라, 각 화면의 목적에 맞게 네이티브, 웹, SDUI를 전략적으로 조합하여 최적의 사용자 경험을 제공하는 것이었습니다. 어떤 화면은 네이티브의 성능이 절대적으로 중요하고, 어떤 화면은 웹의 범용성이 필요합니다.

그렇다면 SDUI의 진정한 가치는 어디에 있을까요? 저희는 SDUI가 단순히 콘텐츠를 보여주는 기술을 넘어, 네이티브의 느린 대응 속도를 보완하는 효율적인 운영 도구가 되는 지점에 있다고 생각합니다.

SDUI 도입을 고민해봤거나, 하고 있는 분들에게 저희의 경험이 조금이나마 도움이 되기를 바랍니다. 그리고 기회가 된다면, SDUI와 안드로이드 Jetpack Compose를 결합하여 적용한 사례도 소개하는 시간을 만들어 보겠습니다.

[Appendix] SDUI 도입을 위한 실전 가이드

자주 받는 질문(FAQ)

어떤 화면부터 SDUI로 바꾸면 좋을까요?

변화가 잦고, 실험이 활발하며, 크리티컬하지만 네이티브 변경 부담이 큰 전시/리스트 영역부터 시작하는 것을 추천합니다.

모든 레이아웃을 서버로 옮겨야 하나요?

아닙니다. 초기에는 레이아웃을 제외하고 섹션/컴포넌트/데이터/액션만 다루는 것이 안정적입니다.

실험/롤백은 어떻게 빠르게 하나요?

스키마 버저닝과 기능 토글(서버 설정)을 결합해 섹션 단위로 비활성화/치환/롤백이 가능하도록 합니다.

도입 시 흔한 함정과 회피법

스키마 과설계: 너무 많은 옵션/레이아웃을 한 번에 넣지 않습니다. 항상 최소 스펙으로 시작합니다.

알 수 없는 타입 처리 누락: 모르는 타입/필드는 안전 폴백하고 로그로만 남기는 것이 좋습니다.

단일 거대 API: ATF 전용 API를 분리해 첫 화면 체감 속도를 먼저 확보합니다.

추상화 누락: 공통 컴포넌트(상품 카드, 헤더 등)는 재사용을 전제로 스키마와 뷰를 함께 설계합니다.

빠른 도입 체크리스트

섹션/컴포넌트/데이터/액션 스키마 초안

알 수 없는 타입/필드 폴백 정책

ATF 전용 API, 하단 영역 분리 API

페이지네이션, Lazy Loading 동작 기준

이벤트/트래킹 스펙(공통 파라미터, 라우팅)

섹션 단위 비활성화/치환/롤백 방법

RabbitMQ Classic Queue 메모리 장애와 Quorum Queue 전환기

Tue, 28 Oct 2025 17:00:00 GMT

안녕하세요. 쿠폰 스쿼드 포덕입니다.

2025년 새해 첫 대량 쿠폰 발급을 진행하던 중, 예상치 못한 일이 벌어졌습니다. 1,500만 건의 쿠폰을 발급하던 중에 RabbitMQ 클러스터에 문제가 생겼습니다.

이번 글에서는 긴급 상황에서의 대응 과정부터 AWS TAM(Technical Account Manager)과 함께 찾아낸 근본 원인, 그리고 Classic Mirrored Queue에서 Quorum Queue로 전환하기까지의 여정을 공유해드리려고 합니다.

🚨 장애 발생과 초기 대응

https://media.tenor.com/2bgUC0TWiecAAAAM/elmo-elmos-fire.gif

2025년 1월, 새해 첫 대량 쿠폰 발급을 진행하던 평범한 오후였습니다. 1,500만 건의 쿠폰을 발급하던 중 갑자기 쿠폰 발급이 완전히 멈춰버렸습니다.

처음에는 단순한 일시적 지연으로 생각했지만, 시간이 지날수록 상황은 심각해졌습니다. 다수의 고객 문의가 쏟아졌고, 매출 손실 발생 가능 이슈로 긴급 대응 채널이 생성되었습니다.

문제의 핵심은 RabbitMQ 클러스터의 메모리 과다 점유였습니다. 메모리가 부족해지면서 브로커가 Critical Status로 변경되었고, 클러스터 내 특정 노드가 unsynchronized 상태로 전환되면서 메시지 처리가 완전히 멈춰버린 것이었습니다.

쿠폰 발급 처리 감소 및 노드 메모리 부하

🔧 초기 대응과 긴급 복구

처음 문제가 접수되었을 때는 평소처럼 DB, 트래픽, WAS부터 확인했습니다. 하지만 모든 지표가 정상이었습니다. 쿠폰 관련 리소스들을 하나씩 점검하던 중에서야 MQ 상태 이상이 발견되었고, 그제서야 진짜 원인을 찾을 수 있었습니다.

인스턴스 증설부터 시도해봤지만 예상과 달리 효과가 없었습니다. 메모리를 늘려도 unsynchronized 상태는 그대로였는데, 이는 이미 동기화가 깨진 상태에서는 단순히 리소스를 늘리는 것만으로는 해결되지 않기 때문입니다. RabbitMQ의 미러링 메커니즘에서 한 번 out of sync 상태가 되면, 모든 노드가 다시 동기화될 때까지 메시지 소비가 중단되는데, 이 과정에서 메모리 증설은 근본적인 해결책이 되지 못합니다. 브로커 재시작을 시도하려 했지만 Memory Alarm이 해소된 후에야 재시작이 가능하다는 안내를 받았습니다. 관리형 서비스 특성상 즉시 재시작이 제한되었습니다. Queue Purge도 Admin UI로만 가능하고 Force Purge는 지원되지 않아서, 긴급 상황에서의 세밀한 제어가 어려웠습니다.

복구가 계속 지연되면서 비즈니스 영향이 커지는 상황에서, 일단 서비스부터 살리기로 했습니다. 기존 장애 브로커와 동일한 설정으로 새로운 RabbitMQ 브로커를 생성하고, 복잡한 클러스터 재구성 대신 독립 운영 방식을 선택했습니다.

애플리케이션의 MQ 접속 정보를 신규 브로커로 변경하면서 기존 메시지 손실을 방지하기 위해 전환 시점을 신중하게 조율했습니다. 점진적으로 트래픽을 전환하면서 실시간 모니터링으로 정상 동작을 계속 확인한 결과, 약 30분 만에 메시지 처리가 정상화되었고 쿠폰 발급 서비스가 완전히 복구되었습니다.

긴급 대응이 끝나고 나서는 재발 방지를 위한 체계적인 원인 분석에 착수했습니다. 메모리 부족이 브로커의 메시지 처리에 미치는 영향과 당시 진행 중이던 대량 발급의 연관성을 가설로 설정하고, 장애 상황을 개발 환경에서 재현해서 정확한 원인을 찾아보기로 했습니다.

🔍 원인 분석과 재현 실험

정확한 원인을 찾기 위해 사고 발생 전 상황을 자세히 조사했습니다. 당시 세 가지 작업이 동시에 진행되고 있었습니다. 1,500만 건 규모의 전체 회원 대상 대량 발급, 전체 매장 대상 쿠폰의 동시 발급 및 사용 처리, 그리고 평상시 트래픽과 겹치면서 Queue 메시지가 급격히 쌓인 상황이었습니다.

병목 지점들을 분석해보니 1,500만 건 대상자를 조회하는 과정에서 DB에 부하가 발생했고, count-up 로직에서 지연이 누적되면서 메시지 처리 속도가 떨어졌습니다. 결국 처리 속도보다 메시지가 더 빠르게 들어오면서 메모리 사용량이 급증한 것이 문제의 시작이었습니다.

RabbitMQ 미러링 메커니즘의 구조적 한계

Classic Mirrored Queue는 고가용성을 보장하기 위해 Master 노드와 Mirror 노드 간의 동기화 구조로 동작합니다. Master 노드가 메시지를 실제로 저장하고 Consumer가 연결되는 주 노드 역할을 하고, Mirror 노드는 Master와 동일한 데이터를 갖도록 유지되는 백업 노드입니다.

Master 노드와 Mirror 노드 간의 동기화 과정에서 메모리 부족 시 동기화 실패가 발생

문제는 동기화 실패 시나리오에서 발생합니다. Master 노드가 메시지를 받으면 모든 Mirror 노드에 복제 요청을 보내는데, Mirror 노드가 메모리 부족으로 제대로 응답하지 못하면 동기화가 실패합니다. 그러면 해당 Queue가 out of sync 상태가 되고, RabbitMQ는 데이터 안전성을 위해 out of sync가 해소되기 전까지 메시지 소비 처리를 완전히 중단합니다.

AWS MQ 공식 문서를 보면, RabbitMQ는 메모리 사용량이 임계점에 도달할 경우 Memory Alarm을 작동시켜 새로운 메시지 수신을 차단합니다. 하지만 이미 처리 중인 메시지의 미러 노드 동기화 과정에서는 새로운 메시지 publish가 차단되고, 기존 메시지의 동기화 요청에 대한 응답이 지연되거나 무시되며, Mirror 노드의 동기화 상태 확인 프로세스가 중단되는 문제가 발생할 수 있습니다.

이런 보수적인 방식은 데이터 무결성 측면에서는 안전하지만, 서비스 가용성 측면에서는 치명적인 약점이 될 수 있습니다. RabbitMQ 팀에서도 이런 한계를 인정하고 Classic Mirrored Queue를 deprecated로 지정했으며, 대신 Quorum Queue 사용을 권장하고 있습니다.

AWS MQ 공식 문서의 메모리 임계점 관리 가이드라인
https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/troubleshooting-action-required-codes-rabbitmq-memory-alarm.html

🔍 상황 재연과 근본 원인 확정

정확한 분석을 위해 운영 환경과 똑같은 조건으로 개발 환경을 구성해서 다양한 테스트를 해봤습니다. AWS MQ 브로커를 운영 환경과 동일한 인스턴스 타입 및 설정으로 구성하고, Classic Mirrored Queue에 운영 환경과 같은 미러링 정책을 적용했습니다.

재연 프로세스

1차 재연 시도: 부분적 성공

테스트 시나리오 1

1. 일반 쿠폰 발급 진행 (점진적 증가) 2. 대량발급 약 1,500만 건 일괄 요청 3. 대량발급 Queue 메시지 적재 상태 확인 4. 일반 쿠폰 발급 지속 유입 5. 1시간 정도 계속 모니터링

결과: Memory High Critical Alarm은 발생했지만 unsynchronized 상태까지는 재현되지 않았습니다. 메모리 사용량이 임계점에 도달한 후 시간이 지나면서 자연스럽게 해소되는 패턴을 보였습니다.

2차 재연: 브로커 재시작 시나리오 추가

운영 환경에서 문제 해결을 위해 브로커 재시작을 시도했다는 점에 주목해서, 테스트 시나리오를 확장해봤습니다.

테스트 시나리오 2

1. 일반 쿠폰 발급 진행 2. 대량발급 약 1,500만 건 일괄 요청 3. 대량발급 Queue 메시지 적재 확인 4. 일반 쿠폰 발급 지속 유입 5. 1시간 정도 모니터링 진행 6. 🔥 Consumer 처리 중 broker 강제 재시작 7. 재시작 후 동기화 상태 모니터링

드디어 브로커 재시작 과정에서 unsynchronized 상태를 재현할 수 있었습니다!

메모리 부족 + 브로커 재시작 = Unsynchronized 상태라는 공식이 확정되었습니다. 재시작 과정에서 브로커가 일시적으로 메인터넌스 모드로 전환되고, 클러스터 내에서 노드 역할이 재배치되면서 누적된 메시지를 처리하는 과정에서 순간적으로 메모리가 급증합니다. 이때 클러스터 내 노드 간 복제본 동기화 과정에서 타임아웃이 발생하는 것이 문제의 핵심이었습니다.

노드의 메모리 사용량이 높은 상태에서 브로커를 재시작하면 오히려 상황이 더 악화될 수 있다는 것을 확인했습니다. Classic Mirrored Queue의 구조적 한계가 고부하 상황에서 더욱 명확하게 드러났습니다.

🤝 AWS TAM 협업을 통한 공식 해결책 도출

GPT 생성 이미지

분석 결과를 바탕으로 AWS TAM과 미팅을 진행했습니다. 개발 환경에서 성공적으로 재연한 과정, 상세한 브로커 로그 분석, 클러스터 상태 변화 추이, 그리고 AWS MQ 제약사항을 공유하면서 공식적인 해결책을 찾아나갔습니다.

AWS 측 분석 결과는 명확했습니다. "이 현상은 RabbitMQ 3.11.28 버전에서 확인된 알려진 이슈(Known Issue)일 가능성이 높습니다. Classic Mirrored Queue의 메모리 관리와 동기화 로직에서 발생하는 구조적 한계로, 고부하 상황에서 브로커 재시작 시 더욱 자주 발생할 수 있습니다."

TAM에서 제시한 해결책은 2단계 접근법이었습니다. 즉시 적용 가능한 해결책으로는 RabbitMQ 버전 업그레이드를 통해 최신 버전에서 개선된 미러링 관련 동기화 로직과 메모리 관련 동작 안정성을 확보하는 것이었습니다.

구조적 개선 방안으로는 Classic Mirrored Queue에서 Quorum Queue로의 전환을 권고했습니다. Quorum Queue는 Raft consensus 알고리즘 기반으로 더 안정적인 동기화를 제공하고, 비정상 replica 자동 제거 및 재동기화 기능이 내장되어 있으며, 네트워크 분할(Split-brain) 상황에서의 강력한 복구 능력을 갖추고 있습니다.

1차 개선: 브로커 버전 업그레이드

AWS TAM의 권고에 따라 바로 RabbitMQ 브로커 버전을 3.11.28에서 3.12.14로 업그레이드했습니다. 주요 개선사항으로는 메모리 알람 처리 로직 개선과 미러링 동기화 안정성 강화가 있었습니다.

동일한 테스트 시나리오로 다시 검증해본 결과, unsynchronized 상태가 발생하지 않는 것을 확인했습니다. 메모리 사용량이 임계점에 도달해도 동기화 상태가 안정적으로 유지되었습니다.

2차 개선: Quorum Queue 전환 결정

버전 업그레이드로 당장의 위험은 해소되었지만, 장기적인 안정성을 위해 Quorum Queue 전환을 결정했습니다.

Classic Mirrored Queue와 Quorum Queue의 핵심 차이점 비교 - 안정성과 복구 능력에서 Quorum Queue의 우위가 명확합니다

Quorum Queue는 Raft Consensus 알고리즘을 기반으로 해서 Classic Mirrored Queue의 한계를 근본적으로 해결합니다. 리더(Leader) + 팔로워(Follower) 구성으로 과반수 합의를 통한 안정적인 메시지 처리가 가능합니다.

리더(Leader) + 팔로워(Follower) 구성으로 과반수 합의를 통한 안정적인 메시지 처리

RAFT Consensus 알고리즘의 핵심 장점은 리더 노드 장애 시 즉시 새로운 리더 선출로 서비스 연속성을 보장하고, 메시지 커밋 시 과반수 노드의 승인으로 데이터 일관성을 확보하며, 장애 노드 복구 시 자동으로 클러스터에 재참여하고, 네트워크 분할 상황에서도 과반수 원칙으로 안정성을 유지한다는 것입니다.

운영 관점에서는 수동 개입 없이 자동 장애 복구가 가능하고, 복잡한 동기화 상태 관리가 불필요하며, 예측 가능한 성능과 안정성, 그리고 확장성과 내결함성의 균형을 제공합니다.

📊 전환 이후 성과와 개선 지표

전환 후 3개월간의 운영 결과를 보면 극적인 개선을 확인할 수 있었습니다. 가장 눈에 띄는 변화는 장애 발생 빈도입니다. 월 평균 2-3회 발생하던 장애가 전환 후 0회로 완전히 줄어들었습니다.

성능 면에서도 개선이 있었습니다. 평균 메시지 처리 지연시간이 150ms에서 120ms로 20% 단축되었고, 무엇보다 중요한 것은 대량 발급 상황에서의 안정성입니다. 이전에 문제가 되었던 1,500만 건 규모의 대량 쿠폰 발급을 무장애로 처리할 수 있게 되었습니다.

운영 관점에서도 큰 변화가 있었습니다. 이전에 월 평균 5-7건씩 발생하던 Memory Critical 알람이 0건으로 현저히 줄어들어 운영 부담이 크게 감소했습니다.

항목 Classic Mirrored Queue Quorum Queue 개선율

메모리 사용 효율성 높음 (단순 복제) 중간 (로그 기반) -15%

동기화 안정성 낮음 (단일 실패점) 높음 (과반수 합의) +85%

장애 복구 시간 수동 개입 필요 자동 복구 (30초 이내) +90%

네트워크 분할 대응 취약 강력 (Split-brain 방지) +100%

Quorum Queue 전환과 함께 포괄적인 모니터링 시스템도 구축했습니다. CloudWatch 기반으로 메모리 사용률 알람(80% 이상 시 경고, 90% 이상 시 Critical), Queue Length 모니터링, Consumer Lag 추적, 클러스터 상태 감시를 실시간으로 진행하고 있습니다. SNS 기반 즉시 알림 체계를 통해 Slack 채널과 연동한 실시간 장애 알림, 심각도별 escalation 정책, 자동 복구 가능 여부 판단 로직도 포함했습니다.

🚀 향후 개선 계획과 확장 방향

단일 브로커 장애에 대비해서 이중화 구성으로 서비스 연속성을 확보하는 것이 다음 목표입니다. Primary 브로커가 평상시 모든 트래픽을 처리하고, Secondary 브로커는 동일한 설정으로 standby 상태를 유지하면서 큐 설정 및 메시지 라우팅 규칙을 실시간으로 동기화합니다. 30초 간격으로 서로의 상태를 확인하는 Health Check도 구축할 예정입니다.

Route 53 Private DNS를 활용한 무중단 전환도 계획하고 있습니다. coupon-mq.internal.oliveyoung.com(예시) 같은 고정 도메인을 통해 장애를 감지하면 자동으로 Secondary 브로커로 라우팅을 변경하고, DNS 레코드 TTL을 30초로 설정해서 빠른 전환이 가능하도록 할 것입니다. Route 53 Health Check와 연동해서 자동 failover가 이루어지면 평균 전환 시간을 90초 이내로 단축할 수 있을 것으로 예상합니다.

예방적 운영 체계 강화를 위해 메모리 사용률 70% 도달 시 자동 인스턴스 증설 검토, Queue Length가 임계값을 초과하면 Consumer 자동 증설, 매일 오전 브로커 상태 및 성능 지표 자동 점검 등의 자동화된 장애 대응 시스템을 구축할 예정입니다. 상황별 단계별 대응 절차를 문서화한 장애 대응 플레이북, 장애 심각도별 담당자 및 대응 시간을 명시한 에스컬레이션 정책, 장애 복구 후 정상 동작 확인 항목을 정리한 복구 검증 체크리스트도 체계화할 계획입니다.

메시징 시스템 고도화 로드맵으로는 단기적으로(3-6개월) 가용 영역 장애에 대비한 Cross-AZ 브로커 배치, 네트워크 대역폭 효율성 개선을 위한 메시지 압축 최적화, 처리량과 지연시간 균형점 탐색을 위한 Consumer 그룹 최적화, 실패 메시지 처리 및 재시도 로직 개선을 위한 Dead Letter Queue 고도화를 진행할 예정입니다.

중기적으로는(6-12개월) 대용량 로그성 데이터 처리를 위한 RabbitMQ Streams 도입, 쿠폰 상태 변경 이력 관리 고도화를 위한 Event Sourcing 패턴 적용, 머신러닝을 활용한 트래픽 예측 및 자동 스케일링 등을 검토하고 있습니다.

💡 결론과 인사이트

이번 RabbitMQ 장애를 통해 대용량 메시징 시스템 운영의 복잡성과 중요성을 다시 한 번 깊이 깨달았습니다. 특히 단순한 기술적 해결책을 넘어선 구조적 개선의 필요성과 예방적 접근의 중요성을 명확하게 확인할 수 있었습니다.

서비스 안정성 지표에서 장애 발생 빈도가 월 2-3회에서 0회로 100% 개선되었고, 평균 복구 시간이 2시간에서 90초로 98.7% 단축되었습니다. 1,500만 건 무장애 처리를 달성했고, 고객 만족도 측면에서도 VoC 건수가 80% 감소(2,800건 → 560건/월)했습니다.

운영 효율성에서도 False Positive 알람이 90% 감소하고, 긴급 대응 인력이 50% 절감되었으며, 정기 점검 시간이 70% 단축되는 성과를 거두었습니다.

핵심 인사이트

메모리 상태와 큐 동기화의 직접적 상관관계를 확인했습니다. RabbitMQ Classic Mirrored Queue 환경에서 메모리 사용량이 임계점에 도달하면 미러 노드 간 동기화 실패 확률이 급격히 증가합니다. 특히 고부하 상황에서 브로커 재시작은 문제를 악화시킬 수 있으므로, 메모리 기반 알람과 예방적 대응이 필수입니다.

AWS MQ 관리형 서비스의 운영적 제약사항도 명확해졌습니다. 관리형 서비스의 편의성과 안정성은 분명한 장점이지만, 브로커 레벨의 세밀한 제어가 제한됩니다. 장애 발생 시 수동 복구 옵션이 제한되므로, 구성 단계에서부터 안정성을 확보하는 것이 중요합니다.

Queue Type 선택의 중요성도 재확인했습니다. Classic Mirrored Queue는 단순하고 메모리 효율적이지만 동기화 실패에 취약합니다. Quorum Queue는 메모리 사용량이 다소 높지만 Raft 합의 알고리즘을 통한 강력한 내결함성을 제공합니다. 비즈니스 중요도와 트래픽 패턴을 고려한 신중한 선택이 필요합니다.

대용량 메시징 시스템 운영 가이드라인

사전 설계 단계에서는 트래픽 패턴과 안정성 요구사항을 고려한 적절한 Queue Type 선택, 평상시 사용량의 2-3배 메모리 할당을 통한 메모리 여유도 확보, Single Point of Failure 제거를 위한 브로커 이중화 구성, 예방적 알람과 자동 대응 로직을 포함한 모니터링 체계 구축이 필요합니다.

운영 단계에서는 대량 처리 시 단계적 부하 적용을 통한 점진적 부하 증가, 메모리, CPU, 네트워크 사용률 추적을 위한 실시간 성능 모니터링, 운영 환경과 동일한 조건의 부하 테스트를 통한 정기적 성능 테스트, 정기적인 DR(Disaster Recovery) 테스트 실시를 통한 장애 대응 훈련이 중요합니다.

장애 대응 단계에서는 임시 해결책보다 원인 규명에 집중하는 근본 원인 분석 우선, 개발 환경에서의 정확한 재현으로 해결책을 검증하는 체계적 재현 시도, AWS TAM, 커뮤니티 등 외부 전문 리소스를 적극 활용하는 전문가 협업, 단순 복구를 넘어선 근본적 개선 방안 수립이 필요합니다.

바람 잘 날 없는 쿠폰 도메인이지만... 🤯 이런 어려움들이 더 견고한 시스템을 만드는 밑거름이 되고 있습니다. 모든 커머스의 쿠폰 담당자분들께 진심으로 리스펙을 보내며, 올리브영 쿠폰팀은 앞으로도 더욱 안정적이고 효율적인 시스템 구축을 위해 지속적으로 노력하겠습니다.

⚙️ 올영 쿠폰 개선 일지

올리브영 쿠폰 발급 개선 이야기

Redis Pub/Sub을 활용한 쿠폰 발급 비동기 처리

쿠폰 발급 RabbitMQ도입기

올리브영 초대량 쿠폰 발급 시스템 개선기

🗓️ 관련 시리즈 예고

"올리브영 쿠폰 시스템 아키텍처 Deep Dive" (언젠가 다시 만나겠습니다..🥲)

긴 글 읽어주셔서 감사합니다! 궁금한 점이나 경험 공유는 언제든 환영합니다. 💪

KPT 회고, 이렇게 했더니 스쿼드 문화가 바뀌었습니다: 올리브영 주문결제 스쿼드의 애자일 성장기

Fri, 17 Oct 2025 14:00:00 GMT

안녕하세요! 트랜잭션서비스개발팀 주문결제 스쿼드의 따끈따끈한 입사자 써니입니다!

지난 1분기, 올리브영 주문결제 시스템은 급변하는 고객 요구와 복잡한 운영 이슈 속에서 분주한 시간을 보냈습니다.

간편 결제 연동, 장바구니 로직 최적화 등 굵직한 프로젝트들을 성공적으로 완수했지만, 스쿼드 내부적으로는 '휴먼 에러'로 인한 잦은 장애와 개선되지 않는 스쿼드 문화라는 고민을 안고 있었습니다.

특히 도메인 규모가 크고 복잡한 주문결제 영역 특성상, 스쿼드원들이 각자의 업무에만 몰입하기 쉬웠고, 그 과정에서 코드 리뷰가 형식적이 되거나, 사소한 실수가 큰 장애로 이어지는 경우가 종종 발생했습니다. 바쁜 일정 속에서 스쿼드원들의 피로도는 누적되었고, 단순히 '회상'에 그치는 기존의 회고 방식으로는 이러한 근본적인 문제들을 해결하기 어렵다는 것을 깨달았습니다.

이 이미지는 Napkin으로 생성되었습니다.

올리브영 주문결제 스쿼드, KPT를 만나다

우리는 이 문제들을 직시하고, 지속 가능한 성장을 위한 해결책을 모색했습니다. 단순히 '회상'에 그치는 회고가 아닌, 구체적인 실행 과제를 도출하는 강력한 도구가 필요했죠.

그 해답으로 우리는 KPT(Keep, Problem, Try) 회고를 선택했습니다.

KPT는 'Keep(지속할 점)', 'Problem(개선할 점)', 'Try(시도할 점)'이라는 단순한 3단계 구조를 가집니다. 이 패턴은 복잡한 도메인 속에서 스쿼드의 경험을 명확히 정리하고, 히스토리 기반의 인사이트를 담아 실질적인 개선으로 이어지게 합니다.

우리 스쿼드는 '더 빠르게, 더 안전하게, 더 편리하게'라는 명확한 비전을 바탕으로, 회고를 진행하기전 다음과 같은 4가지 원칙을 도입해 보았습니다.

이 이미지는 Napkin으로 생성되었습니다.

1. 회고 주제 사전 공유: 깊이 있는 논의를 준비하기:

회고 3일 전, 스쿼드원들에게 가볍게 생각해볼 수 있는 질문을 미리 공유하여 깊이 있는 논의를 유도했습니다. 이는 각자가 지난 분기를 충분히 돌아볼 시간을 제공하여, 회고 당일 더욱 풍성한 인사이트가 나올 수 있는 기반을 마련했습니다.

2. 시니어-주니어 페어링 디스커션: 침묵을 깨고 핵심 문제 파고들기

단순히 의견을 모으는 것을 넘어, 우리는 시니어와 주니어 개발자가 한 팀을 이루어 주문결제 고객 여정 속 숨어있는 문제점을 각자의 시각에서 정의하고 끈질기게 고민하는 디스커션 세션을 진행했습니다. 초기에는 주니어 개발자들이 시니어 앞에서 의견을 내는 것을 부담스러워하는 경향이 있었습니다.

이러한 장벽을 해소하기 위해, 우리는 '답을 찾는 것보다 질문을 던지는 것이 중요하다'는 원칙을 강조하고, 모든 의견이 존중받는다는 분위기를 조성하는 데 집중했습니다. 예를 들어, 한 주니어 개발자는 "레거시 코드 때문에 신기능 구현에 항상 시간이 더 걸린다"는 문제를 제기했고, 이에 시니어 개발자는 해당 레거시 코드가 과거 어떤 배경으로 만들어졌는지 설명하며 함께 개선 방안을 모색하는 의미 있는 대화가 오고 갔습니다. 이는 주니어의 시각에서 놓칠 수 있는 문제점을 발굴하고, 시니어의 경험으로 현실적인 해결책을 찾는 시너지로 이어졌습니다.

3. 타임 박싱으로 효율 높이기: 핵심에 집중하는 기술

주제별 발표와 논의 시간을 엄격하게 제한하는 타임 박싱을 적용해 회고의 효율성을 극대화했습니다. 초기에는 시간을 초과하는 경우가 잦았지만, 퍼실리테이터의 능숙한 개입과 스쿼드원들의 적극적인 참여로 점차 핵심에 집중하는 문화가 정착될 수 있었습니다. 이 덕분에 우리는 불필요한 논쟁을 줄이고, 가장 중요한 문제와 해결책에 대한 깊이 있는 토론에 집중할 수 있었습니다.

4. "이번 분기엔 이것 하나만!" 집중할 항목 선정: 모두의 실행력을 높이는 전략

KPT 회고를 통해 개선할 점(Problem)은 항상 많았지만, 모든 것을 한 번에 해결하려는 욕심은 오히려 스쿼드의 실행력을 저해한다는 것을 경험했습니다. 그래서 우리는 이번 분기엔 가장 임팩트 있는 것 하나만! 이라는 원칙을 세웠습니다.

예를 들어, 지난 회고에서는 장바구니/주문 영역의 복잡한 로직으로 인한 로딩 시간 증대 및 DB 커넥션풀 과다 사용 문제가 큰 'Problem'으로 지목되었습니다. 처음에는 '전면적인 시스템 개편'과 같은 큰 목표가 나왔지만, 이를 쪼개어 가장 시급하고 파급력이 큰 장바구니 캐싱 도입을 첫 번째 'Try' 항목으로 선정했습니다.

KPT 회고로 얻은 놀라운 변화들

우리는 앞으로 무엇을 해야하는가? 어떻게 달성할수 있는가?

이 이미지는 GPT-5로 생성되었습니다.

이번 1분기 회고 워크숍에서는 이전의 워크숍과는 달리 조금 특별한 시도를 도입했습니다.

시니어와 주니어 개발자가 한 팀을 이루어, 주문결제 고객 여정 속 숨어있는 문제점을 각자의 시각에서 정의하고,

무엇이 문제인지 (What)

왜 그것이 문제인지 (Why)

어떻게 해결할 수 있을지 (How)

함께 끈질기게 고민하는 디스커션 세션을 진행했습니다.

이렇게 머리를 맞대어 도출된 소중한 액션 아이템들은 다음 분기 실행의 밑거름이 되었고, 실제로 2분기에는 눈에 보이는 변화로 이어졌습니다.

🌟 KPT 회고로 얻은 놀라운 변화들 🌟

🛠 코드 품질

Problem: '휴먼 에러'로 인한 인시던트 발생

Try: PR 템플릿 정의 및 코드 리뷰 활성화

Result: 코드리뷰 퀄리티 향상 → 코드 이해도 증대 및 실수 감소

🤝 스쿼드 문화

Problem: 과중한 업무로 인한 피로 누적 및 소통 부재

Try: 데일리스크럼 문화 정착

Result: 업무 가시성 증대 & 협업 만족도 상승

💳 서비스 경험

Problem: 결제 직전 복잡한 코드로 쿼리 과다 호출/에러 증가

Try: 장바구니/주문 영역 전면 개편 논의 및 초기 개선

Result: 장바구니 캐싱 도입으로 DB 부하 감소

PR 템플릿의 도입

저번 분기에는 '휴먼 에러'로 인한 인시던트가 발생했습니다. 코드 리뷰를 진행했음에도, 핵심 변경 사항이 명확하게 공유되지 않아 문제가 발생했습니다. 따라서 '코드 리뷰를 열심히 하자'는 의지뿐만 아니라, 체계적인 PR 템플릿을 정의하여 코드 리뷰를 더 쉽고 효과적으로 만들자는 방안을 논의했습니다.

새로운 PR 템플릿은 코드 리뷰의 비효율을 해결하기 위해 다음과 같은 필수 항목들을 담았습니다.

## 작업명 / JIRA [CJOYPG-0000] 결제 실패 시 재시도가 안 되는 버그 수정 ## 변경 요약 (1~3줄) - 실패 시 즉시 종료 → 최대 3회 재시도 후 실패 처리 로직으로 변경 ## 영향 범위 ⚠️ - 결제 로직의 실패 부분 (OrderServiceImpl A메서드) - 주문 상태 변경 로직 ## 리뷰어가 꼭 봐야 할 부분 👀 (선택) - PaymentRetryHandler.java 45-47 라인: 재시도 로직 - 레거시 호환을 위해 A방법 대신 B방법 사용 ## 특이사항 (선택) - 공통코드 ORD032에 88 추가 [파일 10개 이상 또는 ±400라인 이상 변경 시] - 상세 설명 - 로직 설명 또는 관련 문서 링크 - 플로우차트나 다이어그램 링크

이 템플릿은 리뷰어가 변경 사항의 의도를 빠르게 파악하고, 영향 범위를 정확히 예측하며, 중요하게 검토할 지점을 놓치지 않도록 도왔습니다. 특히 '리뷰어가 꼭 봐야 할 부분' 항목은 핵심 로직에 대한 집중적인 검토를 유도하여, 과거에 놓쳤던 잠재적 버그나 비효율적인 코드를 사전에 발견하는 데 결정적인 역할을 했습니다.

PR 템플릿 도입 후 코드 리뷰의 퀄리티가 눈에 띄게 좋아졌습니다. 핵심 변경 사항에 대한 이해도가 증대되었고, 이번 분기에는 휴먼에러의 90% 이상이 배포 전 조기 발견되는 성과를 이루었습니다.

데일리 스크럼 문화 정착

그러나 PR 템플릿만으로 모든 문제가 해결되지는 않았습니다. 바쁜 일정 속에서 스쿼드원들의 피로도가 누적되고, 서로의 업무 상황을 파악하기 어려워 소통이 부족해지는 문제가 있었습니다. 우리는 '서로 잘 도와줄 수 있는 환경을 만들자'는 목표 아래, Slack 내에 데일리 스크럼 봇을 도입하여 매일 아침 간단하게 업무 진행 상황을 공유하는 문화를 정착시켰습니다.

도입 이후 업무의 가시성이 크게 향상되었고, 여러 커뮤니케이션을 하나의 스레드에서 통합 관리하면서 협업 비용이 줄었습니다. 서로의 업무를 더 잘 이해하게 되면서 문제 발생 시 빠르게 해결책을 찾고 부담을 나눌 수 있게 되었습니다. 중간 점검 설문에서도 전원 긍정적인 평가를 주었고, 이후 데일리 스크럼은 스쿼드의 자연스러운 문화로 자리잡았습니다.

우리의 데일리 스크럼

장바구니 캐싱 도입

PR 템플릿과 데일리 스크럼을 통해 협업 방식은 개선되었지만, 기술적인 문제 역시 남아 있었습니다. 장바구니/주문 영역의 복잡한 로직으로 인해 로딩 시간 증가와 DB 커넥션 풀 과다 사용 문제가 심각했기 때문입니다. 전면 개편 논의 끝에, 가장 시급하고 효과가 큰 첫 단계로 장바구니 캐싱을 도입했습니다.

그 결과 장바구니 조회 쿼리 사용량이 54% 이상 감소하며 성능 개선 효과를 입증했습니다. 특히 9월 세일 기간에도 DB 커넥션풀 부하가 완화되어 안정적인 운영이 가능했습니다.

장바구니 캐싱으로 경량화된 쿼리와 함께 우상향하는 9월 세일 DB 커넥션풀!

마무리: 3개월 후, 우리가 깨달은 것들

KPT 회고를 시작하기 전엔 "회고에 시간만 낭비하는 건 아닐까?", "바쁜데 또 하나의 루틴만 추가되는 건 아닐까?" 하고 걱정했던 게 사실입니다. 하지만 3개월을 돌아보니 예상보다 훨씬 실용적이고 의미 있는 변화들이 많았다는 것을 깨달았습니다. 가장 크게 느낀 변화는 다음과 같습니다.

장애 대응 시간이 확실히 줄었습니다. 새로 도입한 PR 템플릿 덕분에 코드 리뷰가 꼼꼼해지면서 배포 전 휴먼 에러의 90% 이상을 조기에 잡아내는 경우가 늘었습니다. 결과적으로 쿼리 과다 호출로 인한 DB 부하도 54% 이상 감소하면서 안정적인 서비스 운영에 큰 도움이 되었습니다.

"이거 누가 알고 있지?"라는 말이 줄어들었습니다. Slack 데일리 스크럼 봇 덕분에 스쿼드원 각자가 어떤 업무를 진행하고 있는지 명확히 알게 되면서, 업무의 투명성과 가시성이 크게 향상되었습니다.

주니어 개발자인 저의 입장에서도, 질문을 어떻게/누구에게 해야 할지에 대한 고민이 줄고 질문이 쉬워졌습니다. 시니어-주니어 페어링 디스커션 이후로 서로에 대한 이해가 깊어지고 신뢰가 쌓이면서 자연스럽게 소통이 활발해진 것 같습니다. 이는 스쿼드 전체의 코드 이해도 증대로 이어지는 선순환을 만들었습니다.

물론, 아직 완벽하지 않습니다. 바쁠 때는 여전히 코드 리뷰가 충분히 깊지 못하게 넘어갈 때도 있고, 회고에서 정한 액션 아이템을 미처 실행하지 못하고 다음 분기로 미루는 경우도 있습니다. 하지만 가장 중요한 건, 우리가 과거에는 단순히 '불편함'에 적응하고 있었던 문제들에 대해, 이제는 "이 불편함을 어떻게 해소할 수 있을까?"라는 질문을 던지게 되었다는 점입니다. 이것이 KPT 회고가 올리브영 주문결제 스쿼드에 가져다준 가장 크고 본질적인 변화라고 생각합니다. 앞으로도 완벽한 스쿼드가 되려는 욕심보다는, 조금씩이라도 함께 나아지려는 스쿼드가 되고 싶습니다.

이번 회고를 통해 얻은 실행력을 바탕으로, 앞으로도 스쿼드원 모두가 문제의 원인을 함께 찾고 해결하는 문화를 더욱 공고히 하며 진화해 나갈 예정입니다.

앞으로도 주문결제 여정을 더 빠르게, 더 안정적으로, 더 편리하게 만들어가겠습니다. 읽어주셔서 감사합니다! 🚀

"이 버튼 왜 안 눌려요?" 물류 현장의 목소리로 PDA 시스템 완성하기

Wed, 24 Sep 2025 18:00:00 GMT

"삐빅, 삐빅." 1분 1초가 급박하게 돌아가는 물류센터. 이곳에서 현장 작업자의 손에 들린 PDA(산업용 단말기)의 작은 화면은 전쟁터의 레이더와 같습니다. 하지만 이 레이더가 낡고 해상도가 낮다면? 브라우저 툴바가 화면의 10% 이상을 차지하고, 키패드로 다음 단계를 넘어가려 해도 아무 반응이 없다면? 버튼이 작아서 장갑 낀 손으로는 화면 버튼이 제대로 안 눌린다면? 실제로 저희가 마주한 현실이었습니다.

이는 단순한 불편함을 넘어 물류 전체의 속도와 정확성을 저해하는 심각한 문제이자 저희가 개발하고 있는 WMS(Warehouse Management System) 의 사용자 경험(UX)에 대한 중요한 질문이기도 했습니다.

저희 조직은 이러한 문제를 해결하기 위해, 네이티브 앱이 아닌 웹 기술이라는 현실적인 선택을 했습니다. 그리고 PWA(Progressive Web App) 도입과 키패드 이슈 해결 등 현장 피드백을 통해 시스템을 개선하여 이번에 저 무계획이 대표로 올리브영 테크팀이 물류 현장의 '진짜' 목소리를 듣고, 이를 기술적으로 해결해 나간 생생한 여정을 담아 보았습니다.

포스트 작성은 처음이지만 비슷한 고민을 안고 있는 개발팀에게는 이 여정에서 얻은 인사이트가 분명 도움이 될 것이라 생각해 기록을 공유하니 많은 관심 부탁드립니다.

우리가 마주한 올리브영 물류 현장의 현실적 제약사항

물류센터 운영에는 다양한 프로세스가 존재합니다. 각 프로세스는 단일 시스템을 통해 관리되지만, 각 파트의 담당자들은 서로 다른 역할을 수행하며 지속적으로 데이터를 업데이트합니다. 그리고 그 프로세스는 다양한 형태의 인터페이스를 통해서 진행됩니다.

GMS 시스템 인터페이스

본격적인 진행에 앞서서 이번 프로젝트 진행시 존재했던 제약 조건들을 먼저 살펴보겠습니다.

하드웨어의 한계: PDA 단말기는 일반 스마트폰에 비해 해상도, 처리 속도, 메모리 용량 등에서 제약이 많습니다. 이러한 제약은 복잡한 UI나 무거운 애플리케이션을 실행하는 데 어려움을 줍니다.

사용 상황의 특성: 장갑을 끼고 한손으로 작업하는 경우가 많아, 작은 버튼이나 복잡한 인터페이스는 사용하기 어렵습니다. 또한, 물건을 이동하거나 들고있는 상황에서 빠르게 작업을 처리해야 합니다.

개발 리소스 및 일정의 한계: 네이티브 앱 개발 및 운영을 위한 리소스가 부족했으며, 개발 일정 또한 넉넉하지 않았습니다.

PDA 단말을 통한 물류 작업

올리브영 물류센터의 상품관리 시스템은 PDA 디바이스를 핵심 인터페이스로 활용합니다. PDA의 내장 스캐너는 바코드(또는 QR코드)를 인식하여 시스템에 필요한 입력 데이터를 만들어냅니다. 이러한 스캔 데이터를 통해 작업자는 재고 관리, 상품 이동, 분류 등 다양한 물류 작업을 수행합니다.

물류센터 내 모든 상품은 물론, 물품 보관 설비인 랙(Rack)의 위치를 나타내는 로케이션까지 바코드로 관리하고 있습니다. 이를 스캔할 수 있는 PDA는 상품관리 영역 전반에서 정확한 데이터 입력을 위한 핵심적인 역할을 수행합니다.

바코드 예시

PDA 디바이스에 최적화된 클라이언트를 제공하기 위해 네이티브 앱과 웹 앱 사이에서 많은 고민이 있었습니다. 하지만 개발 리소스 및 일정의 제약과 PDA의 단순 작업 위주 운영이라는 현실을 고려했을 때, 웹 기반 시스템이 가장 합리적인 선택이었습니다.

물론, 웹 기반으로 구현할 경우 PDA의 스캐너 기능을 웹에서 인식해야 한다는 기술적인 도전 과제가 남아 있었습니다. 그럼에도 불구하고 우리는 웹의 유지보수 용이성과 높은 개발 생산성이라는 장점을 극대화하기로 결정했습니다.

다음 표는 당시 우리가 고려했던 두 가지 방식의 장단점을 비교한 내용입니다.

항목 Native App Web App

바코드 스캐너 연동 SDK로 직접 제어, 안정적 연동 가능하지만 제약 존재

사용자 경험 스캔 → 응답 → 처리 플로우 최적화 가능 브라우저 기반으로 인해 UX 튜닝 한계 존재

기기 기능 제어 진동, 알림음, 화면 제어 자유로움 제한적

보안성 OS 권한 기반 제어 가능 HTTPS 기반
오프라인 지원 로컬DB와 sync 처리 가능 제한적 (PWA 일부 지원)

개발 생산성 앱개발 스택 필요 웹 기술 스택으로 가능

유지보수 패키지 배포 등 부담스러운 업데이트 절차 서버 배포를 통해 비교적 용이한 유지보수 가능

1차 해결: 웹 기반 스캐너 연동 구현

위에서 말한 물류 현장의 현실적 제약사항들 앞에서, 저희가 가장 먼저 부딪힌 벽은 바로 '스캔 기능'이었습니다. 물류 작업의 핵심인데, 웹에서는 하드웨어 제어가 쉽지 않다는 딜레마가 있었습니다.

무엇보다 PDA 디바이스의 스캐너 기능을 웹에서 활용하려면 몇 가지 기술적 제약을 극복해야 했습니다. 웹 기반 시스템은 하드웨어와 직접적으로 연결되지 않아 스캔 이벤트를 감지하거나 입력 필드의 포커스를 세밀하게 제어하기 어렵기 때문입니다.

그럼에도 불구하고 저희는 개발 생산성과 유지보수의 용이성을 위해 웹 기반 시스템을 선택했고, 이 잠재적인 단점을 극복하는 데 집중했습니다.

가장 먼저 해결해야 할 문제는 스캔 데이터 처리였습니다. PDA 스캐너는 바코드를 인식한 후 그 결과값을 키보드 입력처럼 전달합니다. 저희는 이 특성을 활용해 특정 input 요소에 포커스를 유지시키고, 스캔된 문자열을 바로 처리하는 로직을 구현했습니다.

하지만 여기서 예상치 못한 문제가 발생했습니다. 일부 기기에서는 스캔 후 엔터(Enter) 입력이 누락되어 이벤트가 트리거되지 않았습니다. 이를 해결하기 위해 PDA 단말기 자체의 설정을 변경해, 스캔이 완료되면 항상 엔터 입력을 보내도록 구성했습니다.

더 나아가, 사용자가 손을 최소한으로 움직이도록 하기 위해 포커스 관리 로직을 고도화했습니다. 상위 컴포넌트에서 keydown 이벤트 리스너를 활용해 앱 전반에서 스캔 기능을 즉시 사용할 수 있게 했고, 각 비즈니스 로직에 맞춰 input을 유기적으로 초기화하도록 구현했습니다.

2차 해결: PWA 도입으로 사용성 극대화

서비스를 모바일 웹으로 제공하다보니 또 다른 불편사항이 존재했습니다. PDA 디바이스 특성상 화면의 크기와 해상도에 한계가 있습니다. 현장에서 사용하는 디바이스는 일반적으로 우리가 사용하는 스마트폰보다 해상도 사양이 더 좋지 않습니다. 이런 제한사항은 사용자들에게 보여줄 수 있는 영역을 더 좁게 만들었습니다. 특히 모바일 브라우저를 사용하기 때문에 상단의 툴바 영역을 추가적으로 제외해야 하므로 어플리케이션 노출 영역은 더더욱 좁아졌습니다.

이러한 제약을 해결하기 위해 PWA (Progressive Web App) 기술을 도입했습니다. 네이티브 앱 수준의 기능이 꼭 필요한 상황이 아니라면, PWA는 충분한 대안이 될 수 있습니다. 아래에서 PWA의 일반적인 장점을 살펴보겠습니다.

앱 설치한 후 캐싱으로 인한 데이터와 시간을 절약

변경한 콘텐츠만 업데이트할 수 있음

홈 화면에 앱 아이콘 적용 가능

전체화면으로 앱 실행 가능

시스템 알림 및 푸시 메시지 활용 가능

사용자에게 더 넓은 화면 영역을 제공할 수 있을 뿐만 아니라, 서비스 로딩시 로고 적용, 앱 아이콘 적용 그리고 캐시 등 더 완성도 높은 서비스를 제공할 수 있게 되었습니다. 전체화면 활용으로 인해 다른 url 입력을 통해 서비스를 이탈할 수 있는 행위도 방지할 수 있게 되었습니다.
PWA 적용을 위해 다음과 같은 작업들을 진행했습니다.

1. Manifest 파일 생성: PWA의 메타데이터를 정의하는 manifest.json 파일을 생성했습니다. 이 파일에는 앱 이름, 아이콘, 시작 URL, 디스플레이 모드 등을 정의합니다. GMS는 vite 번들러를 사용하고 있어서 아래와 같이 vite.config.js에 작성했습니다.

// vite.config.js { plugins: [ VitePWA({ registerType: 'autoUpdate', manifest: { name: '', short_name: 'GMS', start_url: '/', display: 'standalone', orientation: 'portrait-primary', background_color: '#fafafb', theme_color: '#000000', icons: [ { src: '/icon_192x192.png', sizes: '192x192', type: 'image/png', }, { src: '/icon_512x512.png', sizes: '512x512', type: 'image/png', }, ], }, }), ] }

2. 아이콘 이미지 등록: PWA 적용을 위해 특정 사이즈(192x192, 512x512)의 PNG 파일이 필수적입니다. 규격에 맞지 않는 경우 PWA가 올바르게 동작하지 않을 수 있습니다.

3. 홈 화면 설치 유도: 사용자에게 브라우저를 통해 앱 설치를 유도하고, 바탕화면에 바로가기 아이콘을 추가했습니다.

PWA App 아이콘

PWA 적용의 효과는 기대 이상이었습니다. 가장 큰 변화는 화면 활용도의 극적인 개선입니다.

기존 모바일 웹 환경에서는 브라우저 상·하단 UI가 약 10%의 화면을 차지했지만, PWA의 전체 화면 모드(display: 'standalone') 덕분에 이 영역을 모두 콘텐츠 표시 영역으로 활용할 수 있게 되었습니다. 저해상도 PDA 환경에서 이는 체감 성능을 높이는 매우 유효한 개선이었습니다. 또한, 홈 화면에 추가된 앱 아이콘은 작업자들이 매번 URL을 입력하거나 북마크를 찾아 헤맬 필요 없이, 터치 한 번으로 시스템에 바로 진입할 수 있게 하여 작업 시작 시간을 눈에 띄게 단축시켰습니다.

PWA 도입을 통한 해상도 개선

3차 해결: 현장 테스트를 통한 키패드 이슈 해결

PWA 도입으로 기술적 문제는 어느 정도 해결했다고 생각했습니다. 하지만 진짜 시험대는 따로 있었습니다. 바로 현장이었죠. 사실 서비스 개발 과정에서 실제 사용자의 목소리를 가까이에서 들을 기회는 쉽게 찾아오지 않는데, 이번 프로젝트에서는 작업자의 생생한 피드백을 들을 수 있는 귀중한 기회가 있었습니다. 특히 현장 테스트를 통해 PDA 시스템의 사용성을 크게 개선할 수 있는 핵심 인사이트들을 발견할 수 있었죠.

현장 작업자의 목소리를 직접 들으며 UX 개선 중인 올리브영 개발팀

그 중 의미 있던 개선을 이룬 케이스를 다루려합니다. 화면에 input이 여러 개가 있는 경우 키패드 버튼을 통해서 next step으로 넘어가는 부분에 대한 개선이 필요했습니다.

PDA 작업자들은 주로 한 손으로 작업하며 빠르게 입력을 진행합니다. 그러나 기본 PDA에서 제공하는 키패드의 다음(→|) 버튼이 의도한대로 동작하지 않거나, 포커스가 엉뚱한 위치로 이동하는 경우가 있었습니다.

상황에 따라 액션 정의가 필요한 모바일 화면 속 다음(→|) 버튼

디바이스에 따라 결과가 다를 수 있지만, 일부 기기에서는 화면에 다중으로 input이 존재하는 경우 키패드의 다음(→|) 버튼이 submit이 아니라 다음 탭으로 이동으로 작동됩니다. 실 사용자는 submit이 적용되는 것을 원하기 때문에 이를 해결할 방법을 찾기 시작했습니다.

다양한 옵션과 함수를 사용해 보았지만 원하는 방향으로 작동하지 않았고, 시행착오를 거쳐서 방법을 찾아냈습니다. 특정 input에 포커스가 있는 경우 다른 input을 disabled 처리해서 다음(→|) 버튼을 submit으로 작동시켰습니다. 구현은 간단했지만, 그 효과는 명확했습니다. 이 로직을 적용한 후, 현장 작업자의 불편함은 해소되었습니다. 작은 아이디어 하나가 현장의 작업 효율에 미치는 긍정적인 영향을 직접 확인할 수 있었던 의미 있는 개선이었습니다.

input 비활성화를 통해 다중 입력 액션을 제어하게된 개선 로직

프로젝트를 통해서 배우다

경험한 문제점과 해결방안

개선 작업 이후, 연속된 로케이션 조회시 초기화 프로세스 단계 제외할 수 있어 25% 이상의 작업 시간이 단축되었습니다. 또한 "PDA를 사용하는데 불편한 부분이 있다"라는 현장의 피드백이 사라졌습니다.

PDA 시스템 최적화 여정을 통해 저희는 다음과 같은 교훈을 얻었습니다. 이 글을 읽는 개발자분들 중 비슷한 고민을 안고 있는 분들께도 저희의 경험이 실질적인 도움이 되기를 바랍니다.

현장으로 목소리를 들어봅시다: 완벽한 이론을 적용하는것도 필요하지만, 때에 따라 '왜 안 돼요?' 같은 현장의 목소리를 직접 듣는 것이 더욱 중요할 수 있습니다.

작은 개선부터 적용합시다: 완벽한 솔루션을 기다리지 말고, 작은 불편함이라도 즉시 해결하며 시스템을 발전시켜 나가봅시다.

현실적인 솔루션을 선택합시다: 저희가 네이티브 앱이 없어도 웹과 PWA만으로 충분히 문제를 해결할 수 있었던 것처럼, 주어진 제약 속에서 가장 효율적인 기술을 찾아야 집중합시다.

이렇게 만들어진 저희 GMS에 관심있는 분들은 시나브로우님의 아래 포스팅도 참고 부탁드립니다.

👉 제로베이스 WMS 구축기: Kafka 기반 분산 물류 시스템 설계와 Out-of-Order Events 해결

메시징 시스템 QA, 정합성을 지켜낸 올리브영의 이야기

Wed, 24 Sep 2025 09:00:00 GMT

올리브영이 데이터의 품질을 높이기 위한 여정

"고객이 100원 상품을 클릭했는데 결제하고 보니 10,000원 짜리 상품이였다면?" 이커머스에서 이런 일이 발생하면 고객 신뢰도는 급격히 떨어집니다. 문제의 근본 원인은 바로 '데이터 정합성'! 즉, 여러 시스템 간 데이터가 서로 일치하지 않는 것이죠. 올리브영도 예외는 아니었습니다. 기존엔 개발자들이 데이터 정합성을 책임졌지만, 실시간 메시지 기반 시스템으로 전환하면서 상황이 복잡해졌습니다. 하지만 데이터 정합성 또한 QA의 영역이라는 생각에 QA팀에서 데이터 정합성 확보를 위한 다양한 시도를 해왔습니다. 이번 편에서는 그중 하나인 API를 이용한 데이터 정합성 확보 전략에 관해 이야기할 예정입니다.

데이터 정합성이란?

쉽게 말해 "같은 상품 정보가 모든 시스템에서 동일하게 보이는 것"입니다. 립스틱 가격이 15,000원이라고 예를 들어 보겠습니다. 이 립스틱은 상품 관리 시스템, 주문 시스템, 고객용 앱에 동일한 제품으로 등록된 이상 서로 일치하는 정보를 표기해야 합니다. 이를 데이터 정합성이라 합니다.

데이터 정합성을 확보하기 위한 상품통합TF의 히스토리

현재 올리브영의 상품통합TF는 올리브영은 고객에게 더욱 신속하고 정확한 상품 정보를 제공하기 위해 기존 상품의 정보를 새로운 시스템으로 이전하는 과정을 거치는 중입니다.
기존의 배치 기반 데이터 처리 방식을 탈피해 실시간 메시지 기반의 데이터 처리 구조를 새롭게 도입했습니다.
시스템이 완전히 바뀌면서 새로운 과제에 직면했습니다. 데이터가 여러 시스템을 거치며 실시간으로 흐르게 되자, 데이터 정합성이 문제가 발생할 수 있다는 것이었습니다. 즉, 상품 정보가 최종적으로 고객에게 도달하는 과정에서 데이터가 서로 불일치하는 상황이 생길 수 있었습니다. 수많은 상품 정보가 오가는 올리브영에서는 치명적인 문제였습니다.
물론 이 테스트를 기존처럼 상품 정보에 대한 부분을 등록, 수정하면서 최종 테이블에 정상적으로 저장되는 것을 확인할 수는 있지만 모든 경우의 수를 테스트하기에는 한계가 있었습니다.
그래서 상품통합TF에서 낸 아이디어 중 하나가 구간마다 데이터를 조회하는 API를 만들어서 그 API를 통해 데이터 정합성을 확보하는 것이었습니다.

데이터 정합성 확보 전략

2가지 전략을 세웠습니다. 첫 번째는 UI 테스트를 통해 데이터 정합성을 확보하는 것이고, 두 번째는 API를 이용하여 데이터 정합성을 확보하는 것입니다.

전략 1. UI 테스트를 통한 데이터 정합성 확보

UI 테스트는 실제 사용자와 유사한 환경에서 애플리케이션을 테스트하는 방법입니다. 상품 정보에 영향을 미칠만한 항목들을 등록, 수정하여 최종적으로 상품 정보를 제공하는 테이블에 정상적으로 적재되었는지 확인하는 방식입니다. 이 방식으로 기본적인 등록, 수정을 통해서 정상적으로 데이터가 적재되는지를 확인할 수 있었습니다. 이 과정에서는 상품 정보에 영향을 줄 수 있는 항목별로 개발 과정에서 누락되거나, 반영 로직이 잘못되어있는 경우를 찾아낼 수 있었습니다.

전략 2. API를 이용한 데이터 정합성 확보

상품, 프로모션등의 데이터를 등록, 수정할 때 최종 테이블까지 적재되는 데까지는 여러 단계가 있습니다. UI 테스트로는 단계별로 확인하지 않고 최종 테이블에 정상적으로 적제되는지를 확인하였습니다. 최종 테이블은 1개의 테이블을 가지고서 가공되는 것이 아니라 여러 테이블에 저장된 데이터를 가지고서 최종적으로 가공하여 만든 테이블입니다. 그러므로 최종 테이블의 정합성을 정확하게 확인하기 위해서는 단계마다 데이터를 모두 확인하는 것이 좋습니다. 다만 리소스 문제로 인해 단계별 데이터를 모두 확인하는 것에 어려움이 있으니, 각 구간에서 제공하는 데이터 조회 API를 통해서 정합성을 자동으로 확인하면 좋을 것으로 생각했습니다. 그래서 일단 QA 서버에서 테스트하는 기간에 단계의 데이터를 API로 조회하여 자동으로 정합성을 확인하여 알림을 주는 시스템을 만들고 이렇게 만든 시스템을 현재는 STG, 운영에서 스케줄링하여 사용하고 있습니다.

시스템은 Postman과 Teamcity, Datadog을 이용하여 구축하였습니다.

여기서 잠깐! 왜 Postman, Teamcity, Datadog을 이용했는지 궁금하신 분들이 있을 수 있습니다.

Postman: API 테스트 자동화 도구로 GUI 환경에서 스크립트를 작성하고 관리할 수 있어 각각의 API의 응답값을 비교할 수 있는 로직을 만들 수 있습니다.

Teamcity: CI/CD 도구로, Postman에서 작성한 테스트 스크립트를 스케쥴링 하여 실행하고 결과를 관리 할 수 있습니다.

Datadog: 모니터링 및 알림 도구로, 테스트 결과를 시각화하고 이상 징후 발생 시 알림을 받을 수 있습니다. 시스템 상태를 실시간으로 모니터링하는 데 유용합니다.

저희가 정합성을 맞춰야 하는 테이블은 A, B, C, D, 기존 최종 테이블, 신규 최종 테이블 크게 6개의 테이블이 있습니다. (그 외에도 더 있지만 이해를 돕기 위해서 구성도를 간략하게 하였고 테이블도 6개로 축약하였습니다.)

(확인 해야하는 정합성 테이블들)

1. 정합성을 자동으로 확인하기 위한 플로우 정의

가장 먼저 정합성을 테스트 해야하는 구간과 어떤 값을 비교해야 할 것인지를 정의 하였습니다. 예시 플로우를 하나 설명드리겠습니다.

Step1) 오늘 날짜에 변경된 상품 리스트를 조회하는 API를 호출하여 조회된 상품 리스트의 상품 코드값을 가져옵니다.
Step2) A테이블에 상품 코드값을 넘겨서 상품 상세 정보를 조회하는 API를 호출합니다.
Step3) B테이블에 상품 코드 값을 넘겨서 상품 상세 정보를 조회하는 API를 호출하여 A테이블과 B테이블에서 조회된 상품 상세 정보를 비교합니다.

2. API 정의서 바탕으로 API 마다 같은 값이 반환되어야 하는 값들 정의

API마다 응닶값의 필드명이 다른 경우도 있고 같은 경우도 있어서 이 부분을 정리하여 정의하였습니다.

3. Postman을 이용하여 스크립트 작성

Postman을 이용하여 각 API를 호출하고 응답 값을 비교하는 스크립트를 작성하였습니다. 각 API의 응답 값에서 비교해야 하는 필드명을 추출하여 비교하는 로직을 작성하였습니다. 각 Step에서 작성된 스크립트와 플로우를 간단하게 설명하겠습니다.

Step1) 오늘 날짜에 변경된 상품 리스트를 조회하는 API를 호출하여 조회된 상품 리스트의 상품 코드값을 추출

{ "modifiedDateStart": "{{todayDate}}", "modifiedDateEnd": "{{todayDate}}" }

body에 오늘 날짜를 넣어서 변경된 상품 리스트를 조회하는 API를 호출합니다. 이 경우 todayDate를 넘겨주어야 해서 pre-request script에 오늘 날짜를 구하는 코드를 작성하였습니다.

pre-request script

// 오늘 날짜를 YYYY-MM-DD 형식으로 생성 let today = new Date(); let yyyy = today.getFullYear(); let mm = String(today.getMonth() + 1).padStart(2, '0'); let dd = String(today.getDate()).padStart(2, '0'); let formattedDate = `${yyyy}-${mm}-${dd}`; // 환경 또는 글로벌 변수에 저장 pm.environment.set("todayDate", formattedDate);

오늘 날짜에 변경된 API를 조회하게되면 아래와 같은 형태로 넘어오게 됩니다. 이때 받은 number값은 그 다음 A테이블에 상품 상세 정보를 조회하는 API를 호출할 때 사용하게 됩니다.

{ "status": "SUCCESS", "message": "Requested Successful", "code": 200, "data": { "List": [ { "number": "A0000000122" }, { "number": "A0000000123" } ] } }

받은 응답 값의 상품 번호를 20개씩 자르는 과정을 진행됩니다.

여기서 잠깐! 왜 상품 번호를 20개씩 자르는 과정을 거쳤는지 궁금하신 분들이 있을 수 있습니다.
아래에 알림을 주는 과정을 설명할 예정인데 그 과정에서 한 번에 많은 오류가 발생 시 알림을 줄 수 있는 글자 수를 초과하거나 Postman 또는 Newman테스트 결과서가 잘려서 만들어지는 경우들이 발생하였습니다. 또한 API 자체에도 너무 많은 상품 번호를 넘겨주게 되면 API에서 처리할 수 있는 양을 초과하여 Timeout이 발생하는 때도 있었습니다. 그래서 상품 번호를 20개씩 잘라서 API를 호출하도록 하였습니다.

post-request script

let res = pm.response.json(); let rawList = res.data.List || []; // 테스트 제외 상품 등록 let excludeList = []; // 필터링 let goodsNumbers = rawList .map(item => item.number) .filter(num => !excludeList.includes(num)); // 20개씩 잘라서 저장했을 때 현재 테스트 할 index를 환경 변수에 저장 let index = parseInt(pm.environment.get("currentChunkIndex") || "0"); pm.environment.set("currentChunkIndex", index); // 상품 번호를 20개씩 잘라서 저장 let chunks = []; let pageSize = 20; for (let i = 0; i < goodsNumbers.length; i += pageSize) { chunks.push(goodsNumbers.slice(i, i + pageSize)); } pm.environment.set("goodsChunks", JSON.stringify(chunks)); // 현재 테스트한 페이지 수의 상품 번호가 null로 넘어오면 테스트 종료 if (chunks[index] == null) { pm.execution.setNextRequest(null); }

Step2) A테이블에 상품 코드값을 넘겨서 상품 상세 정보를 조회하는 API를 호출

A 테이블에서 상품 상세 정보를 조회하기 위해서는 어떤 body로 넘겨주어야 하는지 살펴보면 아래와 같습니다.

{ "goodsNumbers": [ "A0000000122", "A0000000123" ] }

Step2에서 받은 number값을 body로 쓰기 위해서는 2번의 post-request, 3번의 pre-request script에 아래와 같이 작성하여 호출하였습니다.

pre-request script

// Step1에서 넘겨준 상품 정보 (20개씩 잘려서 넘어오는 상품 정보 let chunks = JSON.parse(pm.environment.get("goodsChunks") || "[]"); let currentChunk = chunks[index]; pm.environment.set("currentGoodsNumbers", JSON.stringify(currentChunk)); // 요청해야할 JSON 형식으로 변환 let requestBody = { goodsNumberList: currentChunk }; pm.environment.set("finalRequestBody", JSON.stringify(requestBody));

Step2에서 받은 상품 상세정보에 대한 응답 값을 상품 번호 기준으로 빠르게 찾기 위해서 hashmap 방식으로 저장하였습니다.

post-request script

let res2 = pm.response.json(); let step2Data = res2.data || []; // 현재 시간에서 10분(600,000ms) 전의 시간 계산 (정합성 정확성을 위해서 Message가 반영되지 않았거나 배치 타이밍에 대한 부분때문에 정합성에 부정확함이 생길 수 있습니다. // 그래서 10분 이상 지난 데이터만 필터링하여 정합성을 테스트 하는 대상에서 제외합니다 let tenMinutesAgo = Date.now() - 30 * 60 * 1000; let oneAndHalfHoursAgo = Date.now() - 4 * 60 * 60 * 1000; // status가 10이 아니고, modifiedDate가 10분 이상 지난 애들만 필터링 let filteredStep2 = step2Data.filter(item => { let modifiedTime = new Date(item.modifiedDate).getTime(); return modifiedTime < tenMinutesAgo && modifiedTime >= oneAndHalfHoursAgo }); let goodsNumberList = filteredStep2.map(item => item.goodsNumber); // goodsNumber로 빠르게 찾기 위해 Hash map 방식으로 저장 let step2Map = {}; filteredStep2.forEach(item => { step2Map[item.goodsNumber] = item; }); pm.environment.set("step2Map", JSON.stringify(step2Map));

Step3) B테이블에 상품 코드 값을 넘겨서 상품 상세 정보를 조회하는 API를 호출하여 A테이블과 B테이블에서 조회된 상품 상세 정보를 비교

Pre-request script에서 통해서 B테이블의 데이터를 호출하는 과정은 Step2와 동일하여 설명은 생략하겠습니다. Step3에서는 Post-request script에서 B테이블의 응답 값을 A테이블과 비교하는 과정이 중요합니다. (전체 발췌는 어려워 일부 코드 발췌하였습니다.)

Step3 post-request script

필드명이 같을 경우는 다음 스크립트를 사용하였습니다.

let res3 = pm.response.json(); let step3Data = res3.data || []; // Step2에서 저장한 Hash map 가져오기 let step2Map = JSON.parse(pm.environment.get("step2Map") || "{}"); // 비교 대상 필드 premiumBrandFlag 제외, statusName fieldsToCompare = ["goodsName", "status"]; // 원하는 항목 여기에 추가 // 결과 로그 step3Data.forEach(item3 => { let goodsNo = item3.goodsNumber; let item2 = step2Map[goodsNo]; fieldsToCompare.forEach(field => { let val2 = item2[field]; let val3 = item3[field]; pm.test(`${goodsNo} - 필드 테스트: '${field}' A vs B`, function () { if (val2 !== val3) { console.error(`❌ ${goodsNo} - '${field}' mismatch | A: ${val2} | B: ${val3}`); pm.expect.fail(`❌ ${goodsNo} - '${field}' mismatch | A: ${val2} | B: ${val3}`); } }); }); });

필드명이 다를 경우 다음 스크립트를 사용하였습니다.

// 필드 매핑 정의 const fieldMapping = { goodsName: "goodsName", goodsSectionCode: "goodsSectionCode", goodsType: "goodsTypeCode", underAgeSalePossibleFlag: "underageSalesFlag", duplicateItemFlag: "multipleOptionFlag", freeDeliveryFlag: "deliveryFreeFlag", progressStateCode: "status", mediaType: "mediaCode", soldOutFlag: "soldOutFlag", searchDisplayFlag: "searchExposureFlag", displayStartDateTime: "displayStartDateTime", displayEndDatetime: "displayEndDatetime" }; step3Data.forEach(item => { const goodsNo = item.goodsNumber; const match = Object.values(step2Map).find(m => m.goodsNumber === goodsNo); for (const [sourceField, targetField] of Object.entries(fieldMapping)) { let val2, val3; val2 = item[sourceField]; val3 = match[targetField]; pm.test(`${goodsNo} - ${sourceField} vs ${targetField} 비교`, function () { if (val2 !== val3) { console.error(`❌ ${goodsNo} - 필드 불일치: '${targetField}' (A: ${val3}) vs '${sourceField}'(B: ${val2})`); pm.expect.fail(`❌ ${goodsNo} - 필드 불일치: '${targetField}'(A: ${val3}) vs '${sourceField}'(B: ${val2})`); } else { console.log(`✅ ${goodsNo} - '${sourceField}' vs '${targetField}' 일치`); } }); } });

이렇게 작성된 스크립트를 Postman에서 Postman에서 제공하는 CLI 기능을 통해서 Teamcity, cronjob에 연결하여 테스트를 자동으로 하게 하였습니다.

4. Teamcity OR Cornjob을 이용하여 정기적으로 테스트 실행 및 리포트 생성

for i in {0..999} do echo "Running with currentChunkIndex=$i" # 20개씩 끊어서 테스트를 진행함으로 currentChunkIndex를 이용하여 page수를 증가시켜서 테스트 하도록 함 postman collection run {id} -e {env} --env-var currentChunkIndex=$i --reporters cli,json --reporter-json-export result.json # 실패 수 추출 PRE_COUNT=$(jq '.run.summary.prerequestScripts.executed' result.json) # 테스트 한 것이 없으면 break if [ "$PRE_COUNT" -eq 1 ]; then break fi SUMMARY=$(jq -r ' .run.summary.tests.executed as $executed | .run.summary.tests.failed as $failed | "📦 *A <-> B <-> C 테스트 요약[prd] *\n✅ Total: \($executed), ❌ Failed: \($failed)" + ( [.run.executions[] | select(.tests != null) | .tests[] | select(.error != null) | " • \(.error.message)" ] | if length > 0 then "\n" + join("\n") else "" end )' result.json) # 실패 수 추출 FAILED_COUNT=$(jq '.run.summary.tests.failed' result.json) # 실패 시에만 메시지 전송 if [ "$FAILED_COUNT" -gt 0 ]; then curl -X POST -H "Content-Type: application/json" --data "{\"text\": \"$SUMMARY\"}" https://hooks.slack.com/services/... echo "Slack 메시지 전송 완료" fi done

이렇게 작성된 스크립트는 Teamcity 또는 Cronjob에서 정기적으로 실행되며, 테스트 결과를 JSON 형식으로 저장합니다.
그러나 여전히 타이밍적인 이슈가 발생하는 경우가 있어 2번 연속 문제가 발생했을 때 알림이 오길 바랬고 문제가 있는 상품의 번호의 히스토리를 한번에 볼 수 있는 대시보드가 필요했습니다.

5. Datadog을 이용하여 대시보드 구축 및 알림

기존 실행 방식에 datadog에 적재할 저장할 log를 만드는 부분을 추가하였습니다.

# 총 테스트 결과 jq -r ' "Type=API_Monitoring," + "TotalCase=\(.run.summary.tests.executed)," + "Passed=\(.run.summary.tests.passed), " + "Failed=\(.run.summary.tests.failed)" ' result.json | tee -a /Users/app/oliveyoung/Logs/result.log # 실패 수 추출 FAILED_COUNT=$(jq '.run.summary.tests.failed' result.json) # 실패 시에만 메시지 전송 if [ "$FAILED_COUNT" -gt 0 ]; then # 실패 발생 시 오류 메시지를 result.log 파일에 저장 echo "$Datadog\n" >> /Users/app/oliveyoung/Logs/result.log fi

Datadog Agent를 통해서 Logs폴더 하위에 생성되는 *.log 파일을 읽어가도록 만들었고 Datadog에서 읽어간 로그를 parsing하여 대시보드에 표시하도록 하였습니다.
이렇게 구축된 대시보드는 정합성 테스트 결과를 실시간으로 모니터링할 수 있게 해주며, 문제가 발생했을 때 빠르게 대응할 수 있는 환경을 제공합니다.

(Datadog 대시보드)

일시적인 타이밍으로 인한 오류는 제외하기 위해서 알림은 이 중에 1시간에 2번 이상 같은 오류를 발생시킨 경우에만 알림이 오도록 설정하였습니다.

(Datadog 알림)

Datadog에 대해서 조금 더 자세히 알고 싶다면 올리브영 QA는 Datadog을 어떻게 활용하고 있을까?를 참고해 주세요.

현재 운영되고 있는 데이터 정합성 확보를 위한 자동화 테스트 리스트

위에서 기본적인 플로우를 설명해 드렸는데 위의 방식을 변형, 응용하여 현재 운영되고 있는 데이터 정합성 확보를 위한 자동화 테스트 리스트는 다양합니다

(현재 운영 중인 정합성 자동화 테스트 플로우 리스트)

API를 이용한 데이터 정합성 테스트를 통해서 얻은 효과

효과는 3가지 측면으로 나눌 수 있습니다.

1. 리소스 절감 측면

테스트 기간의 리소스 절감 측면에서 확인한 수치는 다음과 같습니다.

범위 부분 : 75% 절감 - 전체 확인해야하는 구간 중에 75%를 API를 이용한 정합성 자동화 테스트로 진행하였습니다.

인적 리소스 부분 : 45% 절감 - 리소스 측면에서 절감 효과가 범위 절감보다 낮은 이유는 상품, 프로모션등을 케이스별로 등록, 수정하는 작업들은 리소스를 많이 소비하기 때문입니다.

2. 수동 테스트로 발견할 수 있는 케이스의 한계 극복

전체 발견 이슈 중 약 51% 이슈 발견 하였습니다.
정합성 자동화 테스트로 발견한 대표적인 이슈 예시를 보면 다음과 같습니다.

메시지 발행 타이밍

메시지 중복 발행

다수 메세지 발행 시 성능 문제

DB 특정상으로 인한 문제

3. 실 운영 서버에서 타이밍적인 부분, 예외 케이스에 대한 검증 측면

QA서버에서 발견할 수 있는 이슈들의 케이스는 한정적이기 때문에 운영 서버에 API를 통한 자동화 정합성 시스템을 구축해놓음으로써 운영 서버에서 발생할 수 있는 타이밍적인 부분이나 예외 케이스에 대한 검증을 할 수 있었습니다.
이 부분에서 좀 더 다양한 사례들을 확인하여 정합성을 확보하는 데 가장 중요한 역할을 하였습니다.

데이터 정합성을 확보하려는 자동화 테스트의 핵심 요소

데이터 정합성에 대한 품질을 높이는 것은 QA팀이 혼자서 의지를 가진다고 할 수 있는 부분이 아닙니다.
개발팀에서도 필요성이 있다고 인식이 되어야 서로 협업을 통해서 구축할 수 있습니다. 왜냐하면 어떻게 데이터 정합성 테스트를 진행할 것인지 결정하고, 결정된 방향성에 대해 개발팀의 도움이 필요합니다. 상품통합TF에서 API를 이용하여 데이터 정합성을 테스트 하기로 결정된 후 API를 통해 데이터를 조회할 수 있는 API가 있어야 하며, API의 응답 값에 대한 정의서가 있어야 했습니다. 필요성이 없다고 인식이 되었다면 이러한 부분에 대한 협의가 원활하게 이루어질 수 없습니다. 이것이 얼마나 필요한 것인지에 설득하는 것은 QA의 역할이라고 생각이 듭니다.
이번에 데이터 정합성을 높이기 위해 API 자동화 테스트 시스템을 구축하는 과정은 기존에 해본 API 테스트와는 조금 다른 방식이었습니다. 그러므로 중간에 많은 변화 과정을 거치게 되었는데 개발팀에서도 이런 방식은 어떨지 이런 것은 가능할지 등의 문의와 제안을 주셨습니다. 이 과정에서 저는 품질을 위해서 다 같이 고민하고 있다는 생각이 들었습니다.
그러므로 데이터 정합성 확보를 위한 자동화 테스트를 구축하기 데 필요한 것은 품질을 위해서 다같이 고민 문화라고 생각합니다.

마무리

이번 글은 올리브영에서 API 테스트를 활용해 데이터 정합성을 확보한 첫 번째 사례입니다. 이 글을 통해 저희가 리소스 절감과 운영 안정성을 어떻게 동시에 확보했는지 알려드리고 싶었습니다. 앞으로도 API를 활용해 품질을 높이는 다양한 방식을 꾸준히 소개해 드릴 예정이니 많은 관심 부탁드립니다.

이번 데이터 정합성 자동화 테스트 시스템을 성공적으로 구축할 수 있었던 건, 저희 QA팀의 노력뿐만 아니라 품질 향상을 위해 함께 고민하고 협력해 주신 상품통합TF💚 덕분이었습니다. 함께 한 모든 분들께 다시 한번 진심으로 감사드립니다.

저희와 함께 일할 동료를 열린 마음으로 기다리고 있습니다. 🤩

상품, 회원, 프로모션 등
올리브영 플랫폼의 코어를 책임지는 QA
채용공고 보기

물류/재고 관리 시스템의 안정성을
책임지는 SCM QA
채용공고 보기

내부 시스템의 품질을 책임지는
백오피스 QA
채용공고 보기

빅뱅 배포, QA는 어떻게 살아 남았나: GMS 프로젝트 테스트 전략 백서

Mon, 08 Sep 2025 18:00:00 GMT

올리브영에서 SCM 도메인 QA 엔지니어 겸민입니다. 이 글은 올리브영의 글로벌 WMS 시스템인 GMS(Global Warehouse Management System)의 구축부터 서비스 안정화에 이르기까지의 검증 여정을 담았습니다. 특히, 테스트 전략 수립, 시나리오 기반 통합 테스트 및 운영 환경 검증 등 실제 프로젝트 현장에서의 구체적인 경험과 노하우를 소개 드립니다.

왜 GMS 프로젝트 테스트는 특별해야 했을까?

물류 시스템을 새로 구축하는 프로젝트는 늘 복잡하지만, GMS 프로젝트는 특히 어려운 도전이었습니다. 기존 시스템을 단계적으로 전환하는 대신, ‘빅뱅 배포(Big Bang Deployment)’, 즉 모든 시스템을 한 번에 전환하는 방식을 선택했기 때문입니다. 이는 마치 기존 도로를 완전히 폐쇄하고 새로운 고속도로를 단숨에 개통하는 것과 같은 일이었습니다.

특히 백오피스, CBT(Cross-Border Trade), WCS(Warehouse Control System) 등 수많은 연계 시스템이 복잡하게 얽힌 환경에서는 단 하나의 오류라도 발생하면 시스템 전체가 마비되는 치명적인 리스크를 안고 있었습니다. 따라서 우리의 테스트 전략은 단순히 기능 검증을 넘어, 전환 직후의 안정성과 데이터 정합성까지 전방위적으로 점검해야 했습니다.

이 이미지는 Google Gemini로 생성되었습니다.

문제 해결의 시작: 리스크 식별과 전략 수립

처음 GMS 프로젝트 합류했을 당시, GMS 프로젝트는 전체 개발 진척도가 40% 정도 수준이었고, 2주간의 짧은 분석·설계 기간 후 곧바로 기능 단위 테스트(Feature Test)를 시작해야 했습니다. 다행히 PO와 개발자분들의 세심한 지원 덕분에 바쁜 일정 속에도 GMS의 핵심 구조와 흐름을 빠르게 파악할 수 있었고, 이 자리를 빌려 감사의 말씀을 전합니다.

도메인 구조를 파악한 후, QA 관점에서 시스템 안정성에 영향을 줄 수 있는 다양한 리스크를 선제적으로 식별했습니다. 이 리스크들을 "Risk Factor"로 정리해 테스트 전략 수립의 기초 자료로 활용하였습니다. Risk Factor를 도출하는 과정에서는 GMS와 연계된 시스템의 구조와 물류 데이터 흐름을 면밀히 분석하고 명확하게 정리하는 작업도 병행했습니다.

✅ Risk Factor란?
QA 입장에서 말하는 Risk Factor는 단순한 '버그 가능성'을 넘어서, 시스템 안정성에 영향을 줄 수 있는 모든 잠재 리스크를 의미합니다.
GMS와 같이 여러 서비스가 유기적으로 연동되는 시스템의 경우 인터페이스 규격 불일치, 메시지 큐(이벤트) 지연·중복 등으로 발생하는 데이터 정합성 훼손 등은
모두 테스트 설계 초기부터 고려해야 할 주요 Risk Factor였습니다.

Risk Factor 정리 예시

이를 토대로 상품 → 입고 → 출고 → 배송이라는 주요 카테고리를 기준으로 전체 워크플로우를 설계했습니다. 그 과정에서 개발 단계에서도 E2E(End-to-End) 통합 테스트가 반드시 필요하다는 점을 확인할 수 있었습니다.

그러나 현실적인 제약도 존재했습니다. 각 연계 시스템의 개발 환경 지원 수준이 달랐기 때문에, 먼저 E2E 테스트 가능 범위를 확인해야 했습니다. 예를 들어, 특송사 샌드박스는 응답이 불안정해 운송장 생성 단계에서 테스트가 제한되었고, WCS는 아예 개발 환경이 없어 출고 관련 E2E 테스트 자체가 불가능했습니다. 이러한 제약 속에서 저희는 협력 부서와 여러 차례 논의를 거듭하며 "개발 단계에서 검증 가능한 영역 vs. 불가능한 영역"을 명확히 구분했습니다. 이후 각 구간별로 테스트 전략을 분리·수립함으로써 한정된 환경에서도 유연하고 실효성 있는 테스트를 이어갈 수 있었습니다.

단계별 전략적 테스트: 견고한 시스템을 만드는 과정

GMS는 앞서 언급한 것처럼 백오피스, 글로벌몰, CBT, WCS 등의 다양한 외부 시스템과 연계되는 구조로 설계되어 있으며 데이터 Interface 방식 또한 API, MQ(MSK), BATCH 등 여러 방식을 활용하도록 구성되었습니다.

상품, 입고, 출고, 배송 기준 워크플로우

상품·입고·출고·배송이라는 4대 주요 카테고리를 중심으로 구성한 워크플로우를 시스템 관점에서 실제 연동 방식과 데이터 흐름 기준으로 재정의했습니다. 이 워크플로우를 시스템 연동 방식과 데이터 흐름에 따라 Interface Spec(인터페이스 명세)으로 세분화하였습니다. 정리된 11개의 Interface Spec은 시스템 간 인터페이스 검증 기준이자 E2E 테스트용 Test Suite의 기반이 되었습니다.

동시에 GMS의 기능 단위를 Feature 단위로 나누어 Feature List를 작성하여 이는 기능별 단위 테스트의 검증 기준으로 삼았습니다. 이처럼 정리된 Interface Spec과 Feature List를 기반으로 Test Case를 체계적으로 설계한 뒤, 기능별·단계별 테스트 일정을 마일스톤 기반으로 스케줄링하여 전체 테스트 플랜을 수립했습니다.

Interface Spec & Feature List 예시

설계된 테스트 플랜을 바탕으로 테스트는 단계별로 세분화하여 진행하였으며, 각 단계에서는 단순 통과율보다는 '무엇을 검증해야 하는가'에 초점을 맞춘 전략적 접근을 적용했습니다.

✅ 기능 단위 테스트 (Feature Test): 결함 발견율에 집중하다

기능 단위 테스트는 개발 완료된 기능 모듈별로 진행했습니다. 이 단계에서는 테스트 종료 기준(Exit Criteria)을 단순한 결함 수정률이 아닌, 결함 발견율 자체에 두고 운영하였습니다. 테스트 목적은 ‘완성된 기능을 빠르게 통과시키는 것’이 아니라, 가능한 많은 취약 지점을 사전에 식별하는 것이었기 때문입니다.

기능 단위 테스트 기간 결함 추이

이를 위해 기능 단위에서의 오류 처리와 필수 파라미터 누락, 예외 케이스 등을 고려한 Negative Test를 설계했습니다. 그 결과, 로직의 견고함과 에러 핸들링의 완성도를 높일 수 있었습니다.

특히 입고/출고와 같은 재고 처리 로직은 기능 단위 테스트에서 정상 동작이 확인되더라도, 실제 운영 환경에서는 여러 사용자가 동시에 요청을 보낼 수 있는 상황이 빈번하게 발생합니다. 따라서 정상 기능 검증과 별개로 동시성에 대한 안정성 검증이 반드시 병행될 필요가 있었습니다.

✅ 동시성 테스트 (Concurrency Test): 보이지 않는 충돌을 막아라

기능 단위 테스트가 기능 자체의 견고함을 검증하는 단계였다면, 동시성 테스트는 복잡한 운영 환경에서 발생할 수있는 충돌 가능성을 선제적으로 제거하기 위한 보완적 검증 단계였습니다. 특히 입고·출고와 같이 재고 수량을 처리하는 로직에서는 동일 데이터를 여러 요청이 동시에 접근·변경하는 상황이 자주 발생합니다. 이 경우 예기치 못한 Race Condition이나 데이터 충돌이 발생할 가능성이 높기 때문에, 기능 단위 테스트만으로는 안정성을 보장하기 어렵습니다.

이에 따라 저희는 동일 상품에 대해 복수의 입고 요청이 동시에 발생하는 시나리오를 구성했습니다. 그리고 GMS가 내부적으로 요청을 어떻게 직렬화하고 충돌 없이 처리하는지, 또 Lock 처리 메커니즘이 정상적으로 작동하는지를 집중적으로 검증했습니다.

입고 작업 시 동시성 발생 시나리오

동시성 테스트를 통해 다음과 같은 주요 리스크를 사전에 확인할 수 있었습니다.

동일 요청이 거의 동시에 발생했을 때 재고 데이터가 중복 처리되는 현상

Lock 처리 로직이 제대로 동작하지 않아 발생하는 Race Condition

비정상 상태에서의 Deadlock 또는 데이터 정합성 오염

이러한 리스크를 사전에 식별하고 검증함으로써 운영 단계에서 발생할 수 있는 데이터 충돌 이슈를 효과적으로 차단할 수 있었습니다. 또한 API 로직이 동시 요청 환경에서도 안정적으로 동작한다는 신뢰를 확보하여, QA 관점에서 시스템 안정성 보장의 핵심적인 검증 과정이 되었습니다.

✅ 통합 테스트 & E2E 시나리오 검증: 데이터 정합성까지 놓치지 않는 심화 검증

통합 테스트 단계에서는 기능 단위 테스트를 통해 검증된 기능들을 실제 운영 흐름과 동일한 방식으로 연결하여 E2E 시나리오 기반 테스트를 중점적으로 수행했습니다. 특히 GMS는 백오피스, 글로벌몰, CBT, WCS 등 다양한 외부 시스템과 연동되어 있었고, 이들 시스템 간 인터페이스는 대부분 Kafka 기반 MQ(MSK)로 이루어져 있었습니다. 따라서 메시지 기반 비동기 통신의 신뢰성과 데이터 정합성 검증이 핵심 테스트 포인트가 되었습니다. 이번 통합 테스트에서 가장 중점적으로 둔 전략적 포인트는 두 가지입니다.

🔹 1. Interface Spec 기반 E2E Test Suite 구성

초기에 정의한 총 11개의 Interface Spec을 기준으로, 실제 사용자 행위를 반영한 업무 중심의 시나리오(E2E Test Suite)를 설계했습니다. 각 테스트 케이스는 단순 기능 검증에 머물지 않고, 업무 단위(예: 출고 지시 → 재고 할당 → 출고 확정)의 연계를 검증하는 방향으로 구성했습니다. 이를 통해 시스템 간 메시지 흐름이 정상적으로 연계되는지, 전체 프로세스가 의도한 대로 작동하는지를 종합적으로 검증할 수 있었습니다.

인터페이스 테스트 시나리오 예시

🔹 2. Interface Contract Test – 데이터 정합성 및 스키마 호환성 검증

여기서 말하는 Interface Contract Test는, 일반적인 Consumer Contract Test보다 확장된 개념으로, MQ 기반 메시지와 수신 시스템(DB) 간의 스키마 정합성까지 포함한 테스트를 의미합니다.

MQ 기반 인터페이스의 특성상, 메시지가 성공적으로 전송되었다고 해서 실제 데이터가 문제없이 반영된다고 보장할 수는 없습니다. 수신 시스템의 DB 스키마와 메시지 필드 간에 다음과 같은 사양 차이가 존재할 수 있기 때문입니다.

데이터 타입(Type)

컬럼 크기(Size)

NULL 허용 여부

ENUM/코드값 정의 여부

이 경우 데이터 유실, 오류, 또는 Silent Failure가 발생할 수 있습니다. 이를 방지하기 위해 시나리오 테스트와 함께 Interface Contract Test를 함께 수행했고, 주요 검증 항목은 다음과 같습니다.

메시지 필드 ↔ DB 컬럼 간 데이터 타입 불일치 여부

VARCHAR 컬럼 크기 초과로 인한 값 절단 또는 예외 발생 여부

NULL 제약 조건 위반 상황의 처리 여부

ENUM/코드값 등의 미정의 값 처리 상태

Interface Contract Test 예시

예를 들어, 고객 이름(user_name)과 주소(address) 필드가 서비스간 전송될 때 암호화/복호화 과정을 거쳐 전달되는 시나리오를 가정해 보겠습니다.

글로벌몰 → GMS: user_name은 VARCHAR(20), address는 VARCHAR(100) 으로 정의

GMS → 특송사: 복호화 후 전달되지만, 특송사 스키마에서는 user_name이 VARCHAR(10) 으로 설정

이처럼 글로벌몰에서 전달된 20자 이상의 이름 정보는 특송사에 저장되는 과정에서 Schema Mismatch가 발생해 데이터 저장 오류가 나거나, 오류 메시지 없이 값이 잘리는 Silent Failure이 발생할 수 있습니다. 이러한 Interface Contract Test는 서비스 간 사소한 스키마 불일치가 운영 환경에서 예기치 않은 데이터 정합성 문제로 이어지지 않도록 사전에 차단하는 핵심 검증 과정이 되었습니다.

운영 환경 최종 검증 : UAT의 진정한 의미

개발 환경에서의 기능 단위 테스트와 통합 테스트를 통해 GMS의 주요 기능 안정성은 충분히 검증되었습니다. 하지만 WCS(Warehouse Control System)와 실제 물류센터 운영 환경은 개발 환경에서 충분히 테스트가 불가능한 ‘그레이존’으로 남아 있었습니다. 특히 검수 확정 이후 출고 처리까지 이어지는 물류센터 내 프로세스와 시스템 간 연동은, 실제 운영 환경 검증 없이는 사전 리스크 파악이 어려운 영역이었습니다.

이러한 배경 속에서 우리는 실제 센터 환경에서 진행하는 UAT(User Acceptance Test)를 설계하게 되었습니다. 다만 UAT를 수행하는 동안 물류센터 작업이 일시중단되어야 했기 때문에, 단순 시나리오 테스트가 아닌 "반드시 검증해야 할 항목"만 담은 정제된 테스트 시나리오가 필요했습니다.

저희가 설계한 UAT 시나리오와 체크리스트는 다음 기준을 따랐습니다.

글로벌 매출 기준으로 상위 국가와 주요 특송사 조합을 선정

실제 센터 운영에서 발생 가능한 대표 케이스를 중심으로 구성

각 케이스를 E2E 통합 시나리오 흐름에 맞춰 체계화

단순 성공 여부가 아니라, WCS 동작 상태와 데이터 정합성까지 포함한 체크리스트 작성

UAT 제안 초기에는 센터 운영 중단에 대한 부담과 우려가 컸습니다. 그러나 GMS는 기존 시스템과 병행 운영이 불가능한 ‘빅뱅 배포(Big Bang Deployment)’ 방식이었고, 사전 검증 없이 오픈하는 것은 곧 운영 리스크로 직결된다는 의미였죠. QA는 이 부분을 꾸준히 설득했고, 결국 논의를 거쳐 2차에 걸친 UAT를 정식으로 진행하기로 결정했습니다.

UAT 진행 스레드

그 결과, 실제 테스트 과정에서 예상치 못했던 여러 이슈들을 사전 탐지할 수 있었습니다.

WCS 장비 환경 전환 시 발생하는 네트워크 오류

간헐적인 출고 검수 확정 실패

재고이동/재고보충 기능이 실제 운영 환경과 달랐던 부분 등

이러한 경험은 실제 운영 환경 기반 QA의 필요성을 명확히 보여주는 사례였고, 안정적인 GMS 오픈을 위한 핵심 기반이 되었습니다. 이처럼 UAT는 단순한 운영자 확인 절차를 넘어, 운영 중단이라는 리스크를 감수하고서라도 반드시 수행해야 하는 ‘운영 환경 최종 검증 단계’였고 그 중심에는 QA가 있었습니다.

오픈 이후의 QA: 조용한 실패까지 잡아내는 모니터링

UAT를 통해 실제 운영 환경에서의 기능 안정성은 검증했습니다. 하지만 오픈 이후에도 품질 확보는 멈추지 않습니다. 이 시점에서 QA 역할은 단순히 운영 중 발생한 이슈를 수정하는 것에 머무르지 않고, 대신 결함을 조기에 감지하고, 인시던트로 확대되기 전에 선제적으로 대응하는 체계를 만드는 데 있습니다. GMS는 여러 외부 시스템과 MQ 기반 인터페이스(Kafka/MSK)로 연동되므로, 서버 상태 모니터링만으로는 품질 리스크를 찾기 어렵습니다. 예를 들어 서버 Health Check API가 정상(200 OK) 반환해도, Kafka 프로듀서가 메시지를 발행하지 않는 경우(커넥션 단절, 전송 오류 등)도 발생합니다. 이러한 상황을 탐지하기 위해 저희는 Datadog 기반의 커스텀 모니터링 룰을 구축했습니다.

📌 실제 모니터링 적용 예시

출하 지시(Shipment Order)는 일정 주기마다 자동 배치로 내려가야 하는 구조였는데, 만약 Kafka 프로듀서가 침묵한 채 메시지를 전송하지 않는다면 센터의 작업 지시가 멈춰 물류가 중단되는 리스크가 발생합니다. 이를 방지하기 위해 Datadog에서 ‘배치 주기 내 출하지시 메시지 수가 0건일 경우 알림’이 발생하도록 설정했습니다. 덕분에 실제로 운영에서도 센터 작업이 완전히 멈추기 전에 사전 조치를 취할 수 있었습니다.

건수 기반 임계치 알림

메시지 지연 감지

이 외에도 입고 확정, 재고 동기화 등 주요 메시지 플로우에 대해 추가 모니터링하여, 기능 오류가 아닌 ‘조용한 실패(Silent Failure)’도 실시간으로 탐지할 수 있도록 구성했습니다.

모니터링 알림 예시

Datadog 기반의 실시간 모니터링은 단순 대응을 넘어, ‘관측 가능한 QA’로의 전환을 이끈 핵심 전략이었습니다.

마치며: QA, 정답은 없지만 방향은 있다

이번 GMS 프로젝트는 저에게 WMS 시스템을 분석하고 설계부터 런칭까지 직접 경험한 두 번째 사례였지만, 같은 도메인이라고 해서 같은 방식으로 접근할 수는 없었습니다. 시스템 구조는 유사할 수 있어도, QA의 접근 방식은 매번 새로운 고민과 선택의 연속이었습니다. 프로젝트를 진행하며 다시 한 번 깨달은 것은, “이 시스템은 이렇게 검증하면 된다”는 절대적인 정답은 없다는 점입니다. 각 프로젝트는 도입 기술, 연동 환경, 조직의 역량, 팀의 속도 등 수많은 변수를 기반으로 움직이므로, QA는 이러한 요소를 고려해 최적의 테스트 전략을 매번 설계해야 합니다. 무엇이 효과적인 접근법인지 끊임없이 고민하고 방향을 조정하는 과정 자체가 QA가 지녀야 할 가장 본질적인 자세라는 것을 이번 경험을 통해 배웠습니다. 이 글이 새로운 시스템을 처음 검증해야 하는 QA 엔지니어분들께 실질적인 인사이트와 용기를 전하길 바랍니다.

읽어주셔서 감사합니다.

혹시 이 글을 읽고 올리브영 QA팀의 일이 흥미롭게 느껴지셨나요? 저희와 함께 새로운 품질 경험을 만들어 갈 분들을 기다리고 있습니다.

👉 QA Engineer (코어플랫폼) 지원하러 가기

👉 QA Engineer (Back Office) 지원하러 가기

👉 QA Engineer (SCM) 지원하러 가기

또한, 아래 글들도 함께 읽어보시면 GMS 프로젝트와 QA 업무 전반에 대해 더 깊이 이해하실 수 있습니다.

👉 제로베이스 WMS 구축기: Kafka 기반 분산 물류 시스템 설계와 Out-of-Order Events 해결

👉 버그가 아니라 장애를 잡아라!! QA와 카오스 엔지니어링의 만남

올리브영, 블록 기반 CMS로 콘텐츠 제작 시간을 99% 줄이다

Thu, 04 Sep 2025 00:00:00 GMT

안녕하세요! 올리브영 프론트엔드 개발자 쩡다입니다.

"하나의 콘텐츠를 만드는 데 정말 7일이나 걸려야 할까요?"

이 질문에서 시작된 올리브영의 콘텐츠 제작 프로젝트를 소개합니다.
직접 구축한 블록 기반 CMS로 제작 시간을 7일에서 20분으로 단축하고,
Vue에서 Lit 웹 컴포넌트로 전환하며 얻은 확장성 인사이트를 공유하겠습니다.

단순히 기술 전환의 이야기가 아니라,

기존 발행 방식이 가진 비효율성과 병목 지점

CMS를 모듈화하면서 얻은 아키텍처 인사이트

프레임워크 종속성과 확장성 문제를 어떻게 풀었는지

이 과정을 정리해 보려 합니다. CMS 구축을 고민하는 개발팀이나 콘텐츠 워크플로우 개선이 필요한 분들께 도움이 되길 바랍니다.

7일 걸리던 콘텐츠 제작, 20분으로 단축하다

기존 발행 과정의 한계

기존 에디토리얼 콘텐츠 발행은 아래의 단계를 거쳤고, 하나의 콘텐츠가 완성되기까지 평균 7일 이상이 걸렸습니다.

콘텐츠 기획 → 디자인 → 퍼블리싱 → 콘텐츠 발행

특히 디자인과 퍼블리싱은 외주 인력이 담당하다 보니 커뮤니케이션에만 수십 시간이 소요되었고,
이 과정에서 다음과 같은 문제가 있었습니다.

제작 효율 저하: 같은 모양의 블록을 매번 새로 작성해야 함

수요 대응 불가: 인력이 제한되어 콘텐츠 수요를 따라가기 어려움

사용자 경험 한계: 발행량 부족으로 개인 맞춤형 추천 같은 고도화가 어려움

문제 해결을 위한 접근

이런 문제 때문에 CMS를 직접 만들기로 결정했습니다. 핵심 목표는 다음과 같았습니다.

퍼블리싱 제거 – 더 이상 HTML을 직접 작성하지 않도록 함

디자인 제거 – 모듈 단위 블록 시스템을 도입해 디자이너 개입을 최소화

누구나 제작 가능 – 기획자나 BPO도 개발자 도움 없이 콘텐츠 작성 가능

👉 즉, 블록 기반 CMS 에디터를 통해 "기획만 하면 바로 발행"이 가능하도록 구조를 바꾼 것입니다.

성과

콘텐츠 제작 시간이 기존 40시간 → 약 20분으로 대폭 단축

디자인/퍼블리싱 단계를 제거해 외주 커뮤니케이션 비용 감소

에디토리얼 콘텐츠 발행량이 약 2배 증가

현재 올리브영 내 발행 콘텐츠의 약 40% 가 CMS를 통해 생성

👉 이로써 콘텐츠 발행 주기가 크게 단축되었고, 사용자에게 더 풍부한 맞춤형 콘텐츠를 제공할 수 있는 기반이 마련되었습니다.

새로운 접근: 모듈화된 CMS 아이디어

저희가 세운 목표는 "누구나 빠르게 콘텐츠를 만들고 발행할 수 있는 시스템" 이었습니다.

이를 위해 다음과 같은 방향으로 설계했습니다.

모듈 단위 설계: 이미지, 텍스트 등 콘텐츠 요소를 독립 모듈로 제작

위치 이동: Drag & Drop으로 손쉽게 배치

필수 정보 입력 후 자동 생성: 디자인 및 퍼블리싱 리소스 없이 즉각적인 콘텐츠 발행 가능

👉 이렇게 하면 퍼블리셔 의존도가 크게 줄고, 콘텐츠 제작 속도도 눈에 띄게 빨라집니다.

첫 번째 구현: Vue 기반 CMS

처음에는 Vue를 활용해 CMS를 구현했습니다.

선택 이유:

팀에서 이미 Vue를 사용하고 있었고, 빠른 시제품 개발이 가능했기 때문

에디터는 contentEditable 대신 CKEditor5를 사용

contentEditable은 표준이 아니어서 브라우저마다 태그 처리, 줄바꿈 방식, execCommand 동작 등이 달라 일관성 부족

구현 방법:

모듈 단위 Vue 컴포넌트 작성

부모 컴포넌트에서 상태 관리 및 렌더링

장점:

빠르게 프로토타입을 완성

실제 BPO/디자이너가 바로 써볼 수 있는 환경을 제공

한계:

Vue 종속성 때문에 다른 프로젝트에서 재사용하기 어려움

유지보수 관점에서 확장성이 부족

기능이 늘어날수록 상태 관리 복잡성이 커짐

👉 이러한 한계점들을 통해 프로토타입 속도만큼이나 장기적인 재사용성과 확장성이 중요하다는 교훈을 얻었고, 이는 이후 Lit 기반 웹 컴포넌트 전환 결정의 핵심 근거가 되었습니다.

CMS 초기 아키텍처

콘텐츠 구조: 블록 기반

콘텐츠는 블록 기반 구조로 저장됩니다. 즉, 단순히 HTML로 서술하는 방식이 아니라, 각 블록이 타입과 데이터를 가진 배열 형태로 나열됩니다.

예를 들어, 텍스트, 상품, 이미지 등의 요소가 각각 독립된 블록으로 정의됩니다.

[ { id: "78421c00-7e4f-11f0-b7a6-6942e7596f9e", type: 'text' inputText: { text: "<h2 class="fHead1">안녕하세요</h2><p style="text-align:center;">안녕하세요</p>" } }, { id: "7f5ca6e0-7e4f-11f0-b7a6-6942e7596f9e", type: "image", inputImage: { type: "singleType", list: [ { uid: "vc-upload-1755754022576-2", url: "image path" } ] } }, { id: "92e1c0b0-7e4f-11f0-b7a6-6942e7596f9e", type: 'productList', inputProductList: { price: 1000, goodsName: '퍼퓸 파우터 팩트', imagePath: 'image path' status: '판매중' } } ]

두 번째 구현: Lit 기반 웹 컴포넌트

Vue에서 얻은 경험을 바탕으로, 지금은 Lit을 사용한 웹 컴포넌트 기반 CMS로 전환했습니다.

선택 이유:

프레임워크 독립적 → React, Vue, Angular 어디서든 재사용 가능

웹 컴포넌트 표준 기반 → 장기적 유지보수 유리

구현 방법:

이미지/텍스트/상품 모듈을 각각 Lit 컴포넌트로 제작

모듈 간 통신은 이벤트 기반으로 처리

상태는 중앙 store에서 관리 (필요 시 공유 가능)

CMS 모듈을 npm 패키지로 배포 → 다른 프로젝트에서 라이브러리처럼 다운로드 후 사용 가능

기대 효과:

다양한 프로젝트에 쉽게 붙일 수 있음

CMS 모듈이 라이브러리처럼 활용 가능

코드 구현 방식

웹 컴포넌트 정의: @customElement 데코레이터:

@customElement('article-editor-container')는 이 클래스를 브라우저가 인식할 수 있는 사용자 정의 HTML 태그인 로 등록하는 역할을 합니다.
이를 통해 와 같이 HTML 문서에서 재사용 가능한 UI 요소로 사용할 수 있습니다.

상속과 스타일링: extends BaseComponent & static styles:

static override styles는 부모 클래스의 스타일에 추가로 현재 컴포넌트의 고유한 스타일을 적용하는 부분입니다.
unsafeCSS(styles)는 별도로 작성된 CSS 파일을 가져와 컴포넌트의 캡슐화된 스타일로 만들어 줍니다.
이를 통해 컴포넌트의 스타일이 전역 CSS와 충돌하는 것을 방지합니다.

반응형 속성: @property 데코레이터와 접근자:

이 속성은 컴포넌트의 다양한 설정을 담고 있는 객체입니다. 예를 들어, 어떤 모듈을 보여줄지(visibleModuleList) 등을 제어하는 데 사용됩니다. 이 또한 @property로 정의되어 있어 설정값이 변경되면 UI가 자동으로 갱신됩니다.

@customElement('article-editor-container') export class ArticleEditorContainer extends BaseComponent { static override styles = [...super.styles, unsafeCSS(styles)]; private _moduleList: ModuleItem[] = []; @property({ type: Array }) get moduleList(): ModuleItem[] { return this._moduleList; } set moduleList(value: ModuleItem[]) { const oldValue = this._moduleList; this._moduleList = [...value]; this.requestUpdate('moduleList', oldValue); } @property({ type: Object }) config: Config = { visibleModuleList: [], }; }

타 프레임워크 환경에서 라이브러리 설치 후 적용

<article-editor-container id="editor"></article-editor-container>

const config = { visibleModuleList: [IMAGE, TEXT, PRODUCT], }; const editor = document.getElementById('editor'); window.addEventListener('DOMContentLoaded', () => { editor.config = config; });

실제 사용 흐름 (초기 데모 영상)

마치며: 배운 점과 앞으로의 계획

"처음엔 그냥 빨리 만드는 게 목표였는데, 이제는 정말 쓸만한 도구가 됐네요."

함께 작업한 기획자분의 이 한마디가 이번 프로젝트를 가장 잘 요약하는 것 같습니다.
저희는 단순히 콘텐츠를 빠르게 만드는 것을 넘어, 사용자의 워크플로우를 근본적으로 개선하는 도구를 만들고자 했습니다.

핵심 인사이트

이 과정에서 얻은 가장 중효한 깨달음은 다음과 같습니다.

CMS는 단순한 관리자 툴이 아니라 콘텐츠 제작 효율을 혁신하는 도구

프레임워크 종속적 구조보다 웹 컴포넌트 표준 기반의 독립적 구조가 장기적으로 유리

개발자에게는 코드를 짜는 것만큼 사용자의 문제를 깊이 이해하는 것이 중요

앞으로의 방향

앞으로는 이번에 구축한 편집기를 단순히 빠른 제작용 툴을 넘어 퀄리티 있는 콘텐츠 제작에 최적화된 도구로 발전시켜 나갈 계획입니다.

👉 CMS 구축을 고민하고 계신 분들에게 저희의 경험이 조금이라도 도움이 되었으면 좋겠습니다.
그리고 기술이 비즈니스와 만나 어떤 시너지를 낼 수 있는지 계속해서 고민하는 올리브영 테크 조직의 여정에도 많은 관심 부탁드립니다.

외부 백엔드 커뮤니티와 함께 한 올리브영의 SpringCamp 2025 참가 후기

Thu, 28 Aug 2025 10:00:00 GMT

안녕하세요. 인벤토리 스쿼드 백엔드 개발자 펭귄대장입니다!
오늘은 저희 올리브영이 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를 사용하고 있습니다.
관련하여 "재고의 변동을 시계열 데이터로?!" 포스팅을 참고해주시면 좋을 것 같습니다."

발표 자료를 놓치신 분들은 🔗이곳에서 발표 자료와 발표 영상을 확인하실 수 있습니다.

Part02. 사람, 소통하고 연결하다 : 홍보 부스 현장

01. 홍보부스 운영 📢

발표 외에 홍보 부스도 운영하여, 올리브영의 개발 문화와 조직 문화를 소개하는 시간을 가졌습니다.

올리브영의 백엔드 개발자들이 "오늘드림", "올영매장찾기" 등 직접 자신이 개발한 서비스를 소개하고,
개발하면서 사용한 기술 스택과 개발 환경을 소개하며, 올리브영의 개발 문화를 알리는 시간을 가졌습니다.

각 유닛을 대표하여 개발자 분들이 열정적으로 자신이 개발한 서비스와 올리브영의 기술 스택/개발 환경을 소개하고 있는 모습

올리브영의 개발 문화와 조직에 대해 궁금한 점을 물어보시거나,
올리브영에서 진행 중인 프로젝트에 대해 질문하시는 분들이 많아
개발자분들 사이에서 올리브영에 대한 관심이 높다는 것을 느낄 수 있었습니다.🔥

또한 홍보 부스에서는 올리브영과 관련된 간단한 퀴즈를 풀고,
올리브영의 다양한 상품을 받을 수 있는 뽑기 이벤트 🎁를 진행했습니다.
역시 많은 분들이 참여해 주셨고, 퀴즈를 통해 올리브영에 대한 이해도를 높일 수 있는 기회가 되었습니다.

발표 세션 사이마다 사람들로 가득 찬 뽑기 홍보 부스

02. 현장 커피챗 ☕️

홍보 부스 운영과 동시에 커리어에 대해 고민이 있는 주니어 개발자 분들 몇 분을 선정하여 커피챗 시간을 가졌습니다.
올리브영의 개발 문화와 성장 환경을 소개하고, 현장에서 느낄 수 있는 실질적인 커리어 조언을 나누며 뜻깊은 시간을 보냈습니다.

아래는 커피챗에 참여한 개발자 분들의 소감 💌입니다.

👦🏻 4년차 백엔드 개발자 김*성님:
"아직까지 레거시만 실무에서 다루고 있어 커리어에 대해 고민이 많았는데,
레거시를 하더라도 어떤 자세와 생각을 가지고 평소에 업무에 임해야 할지에 대한 방향성을 잡을 수 있었습니다.
레거시라고 커리어에 도움이 아예 안 되는 게 아니라는 말씀을 깊이 새기게 되었습니다.
커피챗이 끝나고 선물로 주신 서적과, 안에 손글씨로 써져 있는 글귀도 너무 감동입니다. 감사합니다!"

👧 3년차 백엔드 개발자 이*현님:
"앞으로 어떤 기술 스택을 어떻게 공부해야 할지에 대한 고민이 많이 해소되었습니다.
올리브영에서 일하는 것에 대한 매력을 느낄 수 있었고, 앞으로도 올리브영과 같은 좋은 기업에서 일하고 싶다는 생각이 들었습니다.
귀중한 시간을 할애하여 커피챗 해주셔서 감사드립니다."

03. 오피스 아워 🏢

홍보 부스와 커피챗을 통해 많은 개발자분들과 소통했지만, 모든 분들과 충분히 대화하기는 어려웠습니다.
이에 일부 개발자분들을 올리브영 본사로 초청해 오피스아워를 진행했습니다.

사전 신청으로 선정된 참가자들은 점심 식사와 티타임을 함께하며 조직 소개와 커리어 관련 이야기를 나누었고, 시니어 개발자들은 경험과 조언을 전했습니다.
이어서 테크 조직의 역할과 업무 방식, 그리고 본사 사옥 투어를 통해 실제 근무 환경도 살펴볼 수 있었습니다.

평일 근무 시간에 진행된 행사였기에, 개인 연차를 내고 참석해 주신 열정에 보답하고자 회사 소개 자료와 소정의 기념품을 준비했습니다.
참가자들은 “연차가 아깝지 않은 유익하고 의미 있는 시간이었다”는 소감을 남기며, 서로에게 영감을 주는 자리로 마무리되었습니다.

마치며.. 🎬

SpringCamp2025는 올리브영이 외부 개발자들과 더 가까워질 수 있었던 의미 있는 행사였습니다.
참가한 저희도 올리브영에서 일하는 것에 대한 자부심과 긍지를 느낄 수 있었고,
외부 개발자분들의 열정을 통해 저희도 다시 한 번 열정을 불태울 수 있는 계기가 되었습니다.

앞으로도 올리브영은 개발자 커뮤니티와의 소통을 지속적으로 이어가며,
개발자들이 함께 성장할 수 있는 문화를 만들어 나가겠습니다.
다시 한 번 SpringCamp2025에 참여해 주신 모든 분들께 감사드리며,
올리브영의 개발 문화와 조직 문화에 많은 관심과 응원 부탁드립니다.

감사합니다!

그리고 현재 올리브영에서는 다양한 개발 직군의 채용도 진행 중입니다.
올리브영의 개발 문화와 조직 문화를 직접 경험하고, 함께 성장할 수 있는 기회를 놓치지 마세요!
많은 지원을 기다리겠습니다! 🙏

👉 올리브영 개발자 채용 바로가기

Visual Studio Code를 Cursor처럼? Amazon Q로 AI 코딩 환경 업그레이드하기

Wed, 20 Aug 2025 18:30:00 GMT

안녕하세요, 올리브영에서 프론트엔드 업무를 진행하고 있는 개발새발자입니다.

최근 개발 환경의 가장 큰 화두는 단연 LLM 기반의 AI 코딩 도우미일 것입니다. 저희 올리브영에서도 개발자들의 생산성을 혁신하기 위해 ChatGPT, Gemini, Amazon Q 등 다양한 AI 서비스를 적극적으로 검토 및 도입해왔습니다. 특히, "코딩 경험을 바꾼다"는 평가를 받는 Cursor에 대한 기대로 PoC까지 진행 중이나, 아직은 전사 도입 단계는 아니라 대안을 찾는 목소리가 많았습니다.

그래서 저희는 익숙한 Visual Studio Code 환경을 유지하면서도 Cursor의 강력한 기능을 대체할 방법을 고민했고, 그 해답을 Amazon Q에서 찾았습니다. 특히, 사내에서 쉽게 MCP로 접근할 수 있는 Amazon Q와 Amazon MCP의 뛰어난 연동성을 고려했을 때, Amazon Q는 Cursor보다 더 나은 선택일 수 있습니다.

이번 포스팅에서는 Amazon Q의 MCP, Rule, Memory Bank 기능을 활용해 여러분의 Visual Studio Code를 Cursor처럼 강력한 AI 코딩 머신으로 탈바꿈시키는 방법을 공유해 드리고자 합니다. AWS 환경에서 개발하시는 분들에게 이번 글이 매우 유익할 것으로 기대되니, 편안한 마음으로 따라와 주세요!

Cursor vs Amazon Q, 무엇이 다를까?

본격적인 설정에 앞서, 두 도구의 특징을 간단히 짚고 넘어가겠습니다.

Cursor는 그 자체로 완벽하게 통합된 개발 환경을 제공합니다. 직관적인 UI, 쉬운 설정, 그리고 코드의 의미 단위(Symbol)까지 정교하게 이해하는 능력은 정말 매력적입니다. 하지만 완성된 제품인 만큼 리소스 사용량이 많고, 유료 플랜을 사용하지 않으면 최소한의 기능만 사용할 수 있다는 점이 아쉬울 수 있습니다.

반면 Visual Studio Code에서 사용하는 Amazon Q는 익숙한 내 개발 환경을 그대로 유지하면서 강력한 AI 기능을 더할 수 있다는 장점이 있습니다. 특히 AWS 생태계와의 뛰어난 연동성과 높은 자유도를 바탕으로 내가 원하는 대로 커스터마이징하는 재미가 쏠쏠합니다. 다만, Cursor처럼 모든 기능이 직관적인 UI로 제공되지는 않아 다소 복잡한 초기 설정과 일부 기능을 직접 구현해야 하는 노력이 필요합니다.

결론적으로 Cursor가 잘 차려진 멋진 정식이라면, Amazon Q는 내 입맛대로 만드는 최고의 비빔밥과 같습니다. 이제 그 최고의 비빔밥을 만드는 방법을 알아보겠습니다.

본격적으로 Visual Studio Code를 Cursor처럼 업그레이드하기 위해, 우리는 다음 5가지 핵심 단계를 차례대로 진행할 것입니다.

기본 설정: 가장 먼저 Amazon Q 확장 프로그램을 설치합니다.

핵심 기능 구현: MCP로 외부 도구를 연동하여 파일 시스템 제어 등 강력한 기능을 추가합니다.

편의성 높이기: 반복적인 확인 작업을 줄이도록 도구 실행을 자동 승인합니다.

나만의 AI 비서 만들기: 사용자 정의 Rule을 추가하여 나만의 코딩 스타일과 규칙을 AI에게 학습시킵니다.

Pro-Tip 적용: 메모리 뱅크 기법으로 AI의 할루시네이션을 방지하고 정확도를 높입니다.

기본 설정: Amazon Q 확장 프로그램 설치

가장 먼저 할 일은 Visual Studio Code에 Amazon Q를 통합하는 것입니다. Visual Studio Code 마켓플레이스에서 Amazon Q 확장 프로그램을 설치하세요. 설치가 완료되면 Visual Studio Code 좌측 액티비티 바에 Amazon Q 아이콘이 나타나며, 이 아이콘을 클릭하면 사이드바에 Amazon Q 채팅창이 열리면서 성공적으로 연동된 것을 확인할 수 있습니다.

Visual Studio Code에서 Amazon Q 확장 프로그램 설치한 모습

핵심 기능 구현: MCP로 외부 도구 연동하기

Cursor의 강력함 중 하나는 다양한 외부 도구를 통합하는 MCP를 지원한다는 점 입니다. Amazon Q에서도 MCP(Model Context Protocol)를 지원하고 있으며, MCP를 활용하면 파일 생성, 이동, 라이브러리 설치 등 다양한 작업을 AI 명령어 한 줄로 처리할 수 있어 코드 작성의 퀄리티를 한 단계 높일 수 있습니다.

파일 시스템을 제어하는 desktop-commander MCP 서버를 연동해 보겠습니다. desktop-commander MCP서버를 제공하는 Smithery.ai 웹 페이지로 이동한 후 desktop-commander MCP 서버 정보를 가져옵니다.

잠깐!🖐️ Smithery.ai란?

Smithery.ai(이하 Smithery)는 한마디로 'AI를 위한 앱 스토어'입니다. 우리가 스마트폰에 새로운 앱을 설치해 기능을 추가하듯, Smithery는 AI가 웹 검색, 데이터 분석, 특정 서비스 이용 등 새로운 능력을 얻을 수 있도록 도와주는 플랫폼입니다. 이곳에는 AI가 사용할 수 있는 다양한 도구(MCP)들이 목록화되어 있어, 개발자들은 필요한 기능을 손쉽게 찾아 자신의 AI에 연결할 수 있습니다. 즉, Smithery는 AI와 외부 도구를 연결하는 '중앙 허브' 역할을 하여, AI가 더욱 강력하고 실용적인 프로그램으로 발전하도록 돕는 핵심적인 공간입니다.

Smithery에서 제공하는 desktop-commander MCP서버

이렇게 가져온 JSON 값은 다음과 같습니다.

{ "mcpServers": { "desktop-commander": { "command": "npx", "args": [ "-y", "@smithery/cli@latest", "run", "@wonderwhy-er/desktop-commander", "--key", "<여러분의 Smithery 계정 키를 입력하세요>", "--profile", "<여러분의 Smithery 프로필 값을 입력하세요>" ] } } }

이제 이 값을 Visual Studio Code의 Amazon Q 확장 프로그램을 이용하여 사용해보겠습니다. Visual Studio Code를 연 후 Amazon Q 확장 프로그램 인터페이스의 진입하면 우측 상단의 MCP 도구 아이콘(🛠️)을 클릭하면 MCP 관리 인터페이스가 나타납니다. 여기서 우측 상단의 'Add' 버튼을 누르고, 이어지는 추가 양식에 아래 정보를 입력해주세요.

Visual Studio Code의 Amazon Q에서 MCP를 설정하는 과정

각 항목의 역할은 다음과 같습니다.

Scope: MCP 서버를 글로벌로 설치할지, 현재 프로젝트에만 설치할지 지정합니다.

Global: 모든 프로젝트에서 사용할 MCP일 경우 선택합니다.

This Workspace: 현재 열려있는 프로젝트에서만 사용할 MCP일 경우 선택합니다.

Name: 설치할 MCP 서버의 별칭 또는 이름입니다.

Transport: MCP 서버와 메시지를 주고받는 전송방식을 설정하는 항목입니다. 현재는 STDIO만 지원합니다.

command: MCP 서버를 실행할 명령어입니다. npx는 Node.js 패키지를 별도 설치 없이 바로 실행해주는 명령어입니다.

args: command 명령어에 전달될 인자(argument)들의 목록입니다.

environment: args에서 사용할 환경변수입니다.

timeout: MCP 서버 요청 시, 응답을 기다리는 최대 시간(ms)입니다. 이 시간이 지나면 요청이 중단됩니다.

이 항목에 맞춰 다음과 같이 입력해주세요.

Scope: This workspace

Name: desktop-commander

Transport: STDIO

command: npx

args

-y,

@smithery/cli@latest

run

@wonderwhy-er/desktop-commander

--key

${SMITHERY_KEY}

--profile

${SMITHERY_PROFILE}

environment

SMITHERY_KEY

<여러분의 Smithery 계정 키를 입력하세요>

SMITHERY_PROFILE

<여러분의 Smithery 프로필 값을 입력하세요>

timeout: 0

Visual Studio Code의 Amazon Q에서 MCP를 설정하는 과정

모든 정보를 입력한 후 'Save' 버튼을 누르면 desktop-commander MCP 서버가 성공적으로 등록됩니다. 그럼 프로젝트 루트에 .amazonq/agents/default.json이라는 파일이 생성되면서 아래의 내용이 추가됩니다.

// .amazonq/agents/default.json { ... "mcpServers": { "desktop-commander": { "name": "desktop-commander", "command": "npx", "args": [ "-y", "@smithery/cli@latest", "run", "@wonderwhy-er/desktop-commander", "--key", "${SMITHERY_KEY}", "--profile", "${SMITHERY_PROFILE}" ], "environment": { "SMITHERY_KEY": "<여러분의 Smithery 계정 키를 입력하세요>", "SMITHERY_PROFILE": "<여러분의 Smithery 프로필 값을 입력하세요>" }, "timeout": 0 } }, ... }

이제 잘 작동하는지 테스트해 볼까요? 프로젝트 루트에 README.md 파일을 하나 생성한 후, Amazon Q 채팅창에 다음과 같이 요청해 보세요.

"프로젝트 루트에 있는 README.md 파일을 'test-mv' 폴더를 만들어 그 안으로 이동시켜 줘."

요청 후, desktop-commander가 파일 이동을 실행해도 되는지 확인하는 팝업이 나타날 것입니다. Run를 클릭하면 test-mv 폴더가 생성되고 파일이 이동하는 것을 볼 수 있습니다.

Amazon Q에서 Desktop Commander MCP 서버 실행 과정

편의성 높이기: 도구 실행 자동 승인 설정

매번 Run 버튼을 누르는 것이 번거롭게 느껴질 수 있습니다. Cursor의 Auto Run 모드처럼, 신뢰할 수 있는 도구는 자동으로 실행되도록 설정할 수 있습니다. 다시 MCP 도구 아이콘(🛠️)을 클릭하여 MCP 도구를 관리하는 인터페이스로 이동하여 desktop-commander 항목 우측의 도구 아이콘(🛠️)을 클릭해 도구 관리 화면으로 들어갑니다. 나타나는 수많은 도구 리스트 중에서 자동 승인하고 싶은 도구(예: Move file)를 찾아 Ask로 되어 있는 셀렉터 박스를 Always Allow로 변경해주면 됩니다. 설정 후, 아까와 동일한 프롬프트를 다시 입력해보세요.

"test-mv 폴더에 있는 README.md 파일을 프로젝트 루트로 다시 옮겨 줘."

Desktop Commander MCP 서버 Always allow 적용 과정

이번에는 확인 요청 없이 바로 파일이 이동하는 것을 확인할 수 있습니다. 짠! 한결 더 편리해졌죠?

나만의 AI 비서 만들기: 사용자 정의 Rule 추가

Cursor의 꽃이라 불리는 기능은 바로 Rule입니다. 개발자가 지정한 규칙에 따라 AI가 답변의 톤, 형식, 준수사항 등을 지키게 만드는 기능이죠. Amazon Q에서도 .amazonq 폴더를 통해 이 기능을 구현할 수 있습니다. Amazon Q 채팅창 상단의 'Rules' 버튼을 클릭하고, 'Create a new rule' 버튼을 눌러 새로운 규칙의 이름을 입력하세요. Create를 클릭하면 프로젝트 루트에 .amazonq/rules 폴더가 생성되며, 그 안에 방금 만든 이름의 마크다운(.md) 파일이 열립니다. 이제 이 파일에 원하는 규칙을 자유롭게 작성하면 됩니다. 여러 개의 파일을 만들어 규칙을 세분화할 수도 있습니다.

Visual Studio Code에서 Amazon Q 룰 설정

Pro-Tip: AI 기억력 강화와 할루시네이션 방지

AI를 사용하다 보면 사실이 아닌 정보를 그럴듯하게 만들어내는 할루시네이션(Hallucination) 현상을 겪곤 합니다. 이를 방지하고 AI가 프로젝트의 맥락을 더 잘 이해하게 만들기 위해 메모리 뱅크라는 기법을 적용해 볼 수 있습니다.

방법은 간단합니다. 특정 폴더에 작업 내용을 기록하고, AI가 답변하기 전에 항상 그 내용을 참조하도록 Rule을 만드는 것입니다. 먼저 프로젝트 루트에 .context-memory라는 폴더를 생성한 후, 앞서 만든 Rule 파일에 아래와 같은 규칙을 추가합니다.

## 답변 전 필수 확인 절차 - **컨텍스트 확인**: 사용자가 질문하면, 답변 전에 반드시 `.context-memory` 폴더 안의 모든 파일을 확인하여 전체 맥락을 파악한 후 답변해야 합니다. 이 절차는 AI가 부정확한 정보를 생성하는 것을 방지하기 위함입니다. ## 작업 메모리 관리 - **작업 내용 저장**: 모든 작업 내용은 프로젝트 루트의 `.context-memory` 폴더에 마크다운 문서로 저장합니다. - **메모리 파일 생성**: 하나의 기능 단위나 논리적 변경이 완료되면, 해당 작업 내용을 요약하는 마크다운 문서를 생성합니다. - **파일명 규칙**: 파일명은 `YYYY-MM-DD_HH-MM-SS_작업요약.md` 형식을 따릅니다. ## 메모리 파일 구조 - 작업 내용을 저장할 때는 다음 구조를 따라주세요. ### 📋 작업 개요 - **작업 일시**: YYYY-MM-DD HH:MM:SS - **작업 유형**: [기능 개발/버그 수정/리팩토링 등] ### 🎯 작업 목표 - 이 작업의 목적과 해결하려는 문제를 설명합니다. ### 🔧 구현 내용 - 주요 변경사항, 추가된 기능, 수정된 로직 등을 상세히 기술합니다. ### 🔗 관련 파일 - 수정되거나 새로 생성된 파일 경로 목록을 기재합니다.

이렇게 규칙을 정해두면, Amazon Q는 답변하기 전 메모리 뱅크를 먼저 확인하여 훨씬 더 맥락에 맞고 정확한 답변을 제공하게 될 것입니다.

마무리하며

지금까지 Visual Studio Code와 Amazon Q를 조합하여 Cursor처럼 강력한 AI 개발 환경을 구축하는 방법을 알아보았습니다.

LLM 기술이 발전하며 수많은 모델과 서비스가 등장하고 있지만, 그 핵심은 결국 AI를 어떻게 잘 활용할 것인가에 있습니다. 오늘 소개해 드린 MCP와 Rule을 잘 정립해두는 것만으로도 여러분의 곁에 뛰어난 주니어 개발자 한 명을 두는 것과 같은 효과를 누릴 수 있습니다.

올리브영은 개발자들이 최신 기술을 마음껏 실험하고 실전에 적용할 수 있도록, 도구 지원·샌드박스·사내 바이브 코딩 대회 등 실질적인 성장 장치에 꾸준히 투자하고 있습니다.

오늘 소개한 Amazon Q 사례처럼, 우리는 스스로 기술을 검토·도입하며 동료와 함께 더 나은 개발 환경을 만들어갑니다. 변화의 흐름에 맞춰 함께 성장하고 싶다면, 올리브영에서 여러분만의 규칙과 도구로 개발 문화를 직접 빚어보세요. 아래 채용 정보를 통해 여러분을 기다리겠습니다.

[올리브영 채용 페이지 바로가기] (https://recruit.cj.net/recruit/ko/recruit/recruit/detail.fo?zz_jo_num=8315)

올리브영은 왜 선물하기를 개편했을까? Part - 2

Mon, 04 Aug 2025 18:00:00 GMT

안녕하세요. 올리브영 전시 영역 백엔드 개발을 담당하고 있는 robi입니다.

오래 기다리셨죠? 작년 11월 28일에 작성된 🎁 올리브영은 왜 선물하기를 개편했을까? Part - 1의 후속편이 드디어 작성되었습니다.

1부에서 말씀드렸던 대로 2부에서는 개편 과정의 세부 기술과 구현 과정을 더 자세히 다뤄볼 예정인데요.

여러 주제 중, 가장 중요했던 "캐싱"에 관해 여러분에게 소개해 드리고자 합니다.

🔑 What is 캐싱

캐싱(Caching)은 자주 사용하는 데이터를 빠른 저장소에 미리 저장해두어, 같은 요청이 들어올 때 더 빠르게 응답할 수 있도록 돕는 기술입니다.

'숨겨진 보물창고'라는 'Cache'의 본래 의미처럼, 개발에서도 자주 쓰는 데이터를 미리 숨겨두고 꺼내 쓰면 시스템이 훨씬 민첩해질 수 있는데요.

이러한 캐싱 기술은 비단 웹뿐만 아니라 하드웨어, CPU, 데이터베이스, DNS 등 다양한 분야에서 널리 활용됩니다.

특히 실시간 트래픽이 많은 전시 영역에서는 DB나 외부 API 호출 같은 느린 작업의 결과를 캐시에 저장해두어, 약간의 정합성을 포기하더라도 빠르게 응답할 수 있도록 사용합니다.

🫒 올리브영의 캐싱

전시 서비스에서는 캐싱을 위한 NoSQL로 주로 레디스(Redis)를 사용하며 장애 확산을 방지하고 시스템을 보호하기 위해 서킷 브레이커로 Resilience4j를 함께 사용 중인데, 이를 위해 작성된 Spring Boot에서의 Kotlin 코드는 아래와 같았습니다.
⚠️ 이하 모든 코드는 예시로 작성되었음을 알려드립니다.

@CircuitBreaker( name = "commonCircuitBreaker", fallbackMethod = "fallbackPagedFooData" ) @Cacheable( cacheManager = "displayCacheManager", value = "display:foo", key = "{#pageNumber}", unless = "#result == null or #result.isEmpty()" ) fun fetchPagedFooData(pageNumber: Long): List<FooDisplayResponseDto> { // ➀ HttpAPI호출, DB조회, 비즈니스 로직 ... } private fun fallbackPagedFooData(): List<FooDisplayResponseDto> { // ➁ fallback 로직 ... }

Case 1 : 'commonCircuitBreaker'가 닫혀(CLOSED) 있는 경우 'displayCacheManager'로부터 데이터 획득 시도

레디스에서 'display:foo:{#pageNumber}'에 해당하는 값 획득

값을 획득하지 못했다면 함수 구현체인 ➀을 수행

➀의 수행 결과가 null이 아니고 'isEmpty() == false'라면 레디스에 저장

수행 결과를 반환

Case 2 : 'commonCircuitBreaker'가 열려(OPENED) 있거나 허용되지 않은 예외가 발생한 경우 'fallbackPagedFooData'함수를 수행

오류 상황을 로깅

➁를 통해 DB 데이터를 조회하여 반환하거나, emptyList()를 반환

위 코드로 서비스를 개발하는 데 큰 문제는 없었지만, 캐시를 많이 사용하는 선물하기 영역에서는 새로운 기능을 추가할 때마다 아래와 같은 단점을 느꼈습니다.

써킷과 캐시 적용을 위한 2개의 어노테이션의 개별 사용으로 인한 불편함

명확한 캐시 key값과 TTL등 설정을 빠르게 확인하기 어려움

레디스의 hash타입 데이터를 사용할 수 없음 ❌

@CircuitBreaker의 fallbackMethod속성을 문자열로 지정하여 IDE도움을 받을 수 없음에 의한 실수 유발 가능성 ⬆️

@Cacheable의 key, unless속성에 SpEL(Spring Expression Language)사용으로 인한 실수 유발 가능성 ⬆️

따라서, 저희는 이러한 불편함을 개선해보고자 별도의 캐시 모듈을 만들었고, 이를 Spring의 AoP에 묶는 작업도 함께 진행했습니다.

🛠️ 개선된 캐시 모듈

설계에 앞서 저희는 캐시를 가장 효율적으로 활용할 방안을 고민했으며, 다음과 같은 요구사항을 바탕으로 논의를 시작했습니다.

레디스 연동: 캐시는 레디스에 적재하고, 필요할 때 불러올 수 있어야 합니다.

예시: 선물하기 서비스의 전시 데이터 적재 구조

동적 캐시 키: 캐시 키는 문자열로 설정하며, 함수의 매개변수(parameter)를 키 값에 동적으로 포함할 수 있어야 합니다.

TTL 설정: 캐시의 유효 시간(TTL, Time-To-Live)을 설정할 수 있어야 합니다.

일자별 버전 설정: 일자별 캐시 버전을 키 값을 통해 표현할 수 있어야 합니다.

다양한 자료구조 지원: 레디스의 string(value) 및 hash타입을 모두 지원해야 합니다.

실패 처리 옵션: 캐시 조회에 실패했을 때, 예외(Exception)를 발생시키거나 대체 로직(Fallback)을 수행하는 것 중 선택할 수 있어야 합니다.

Fallback 결과 처리: 대체 로직(Fallback)이 수행된 후, 그 결과를 캐시에 다시 적재할지 여부를 선택할 수 있어야 합니다.

기존 방식의 단점 개선: 앞서 언급했던 캐시 활용 방식이 가진 문제점들을 개선해야 합니다.

위 요구사항들을 바탕으로 논의한 끝에, 저희는 아래와 같은 구조로 모듈을 호출하는 @DisplayCaching 어노테이션을 제공하기로 결정했습니다.

❗️1부에서 언급됐던 @GiftCaching, @GiftCachingKey가 각각 @DisplayCaching, @DisplayCachingKey로 이름이 변경되었습니다.

// @CircuitBreaker + @Cacheable 어노테이션의 기능을 대체하는 @DisplayCaching @DisplayCaching( ··· ① displayCacheInfo = DisplayCacheInfo.FOO_PAGED, ··· ② dateTimeKeySuffix = DateTimeKeySuffixType.LOCAL_DATE, ··· ③ throwWhenReadFail = false, ··· ④ putDataAfterProceed = true ··· ⑤ ) fun fetchPagedFooData( @DisplayCachingKey pageNumber: Long ··· ⑥ ): List<FooDisplayResponseDto> { // HttpAPI호출, DB조회, 비즈니스 로직 }

① @DisplayCaching : 캐싱을 적용할 함수 위에 어노테이션을 선언하고, 적용할 캐시 속성을 지정합니다.

DisplayCaching.kt (클릭하여 펼치기)

@Target(AnnotationTarget.FUNCTION) @Retention(AnnotationRetention.RUNTIME) annotation class DisplayCaching( val displayCacheInfo: DisplayCacheInfo, val dateTimeKeySuffix: DateTimeKeySuffixType = DateTimeKeySuffixType.NOT_USE, val throwWhenReadFail: Boolean = false, val putDataAfterProceed: Boolean = true )

② displayCacheInfo : 열거형 상수를 지정합니다. 여기에는 캐시명, TTL, 캐시 타입이 정의되어 있습니다.

DisplayCacheInfo.kt

enum class DisplayCacheInfo( val key: String, val ttl: Long, val redisDataType: RedisDataType = RedisDataType.VALUE ) { FOO_PAGED( key = "display:foo", // 레디스 키값으로 사용 ttl = 900L, // 15분 redisDataType = RedisDataType.VALUE ), }

③ dateTimeKeySuffix : 열거형 상수를 지정합니다. 값에 따라 Key의 마지막에 붙을 접미사(suffix)를 현재 시간을 기준으로 생성합니다. (-yyyyMMdd)

DateTimeKeySuffixType.kt

interface DateTimeKeySuffix { fun getSuffixString(currentTime: LocalDateTime): String } enum class DateTimeKeySuffixType : DateTimeSuffix { NOT_USE { override fun getSuffixString(currentTime: LocalDateTime): String = "" }, LOCAL_DATE { override fun getSuffixString(currentTime: LocalDateTime): String = String.format("%04d%02d%02d", currentTime.year, currentTime.month.value, currentTime.dayOfMonth) // yyyyMMdd } }

④ throwWhenReadFail : 값이 true인 경우 캐시 읽기 작업이 실패하면 함수 구현부(fallback)을 수행하지 않고 예외를 던집니다.

⑤ putDataAfterProceed : 값이 true인 경우 fallback을 수행한 결과를 캐시로 저장합니다.

⑥ @DisplayCachingKey : 캐시 키 값에 사용할 파라미터 앞에 어노테이션을 선언하면 키를 생성할 때 해당 파라미터를 활용합니다. 또한, forHashKey = true로 설정한다면 해당 파라미터는 레디스의 hash타입 데이터의 해시 키 값으로 사용할 수 있습니다.
(위 예제의 경우 pageNumber에 1L이 전달된 경우 최종적으로 생성되는 키는 "display:foo:1")

DisplayCachingKey.kt

@Target(AnnotationTarget.VALUE_PARAMETER) @Retention(AnnotationRetention.RUNTIME) annotation class DisplayCachingKey( val forHashKey: Boolean = false, // true인 경우 RedisDataType.HASH의 HashKey로 사용 ) { companion object { fun convertParamValueToKeyString(value: Any?): String { return when (value) { null -> "null" is String -> value is LocalDateTime -> String.format( "%04d%02d%02d%02d%02d%02d", value.year, value.month.value, value.dayOfMonth, value.hour, value.minute, value.second ) is LocalDate -> String.format("%04d%02d%02d", value.year, value.month.value, value.dayOfMonth) else -> value.toString() } } } }

그리고, 어노테이션 속성값에 따라 캐시 모듈이 어떻게 분기 처리되는지를 Excalidraw로 도식화했습니다.

이러한 설계를 바탕으로 DisplayCacheModule을 구현했으며, 그 구조는 다음과 같습니다.

DisplayCacheModule.kt

class DisplayCacheModule( private val circuitBreaker: CircuitBreaker, private val redisTemplate: RedisTemplate<String, Any?>, private val objectMapper: ObjectMapper ) { private val logger = LoggerFactory.getLogger(DisplayCacheModule::class.java) companion object { private val SAFE_NULL_OBJECT = Object() /** * 파라미터 기반의 캐시 키를 생성 */ fun makeDefaultCacheKey( baseCacheKey: String, paramValuesForKey: List<String> = emptyList(), dateTimeSuffixType: DateTimeKeySuffixType = DateTimeKeySuffixType.NOT_USE, ): String { // paramValuesForKey 처리 val parameterCacheKey = paramValuesForKey.joinToString(separator = "") { it } .let { if (it.isNotBlank()) ":$it" else "" } // ":xyz" or "" // dateTimeKeySuffix 처리 val dateTimeKeySuffix = if (dateTimeSuffixType != DateTimeKeySuffixType.NOT_USE) { dateTimeSuffixType.getSuffixString(LocalDateTime.now()) .let { if (it.isNotBlank()) "-$it" else "" } // "-yyyyMMdd" or "" } else "" // 최종적으로 base, parameterCacheKey, dateTimeKeySuffix를 조립하여 반환 return baseCacheKey + parameterCacheKey + dateTimeKeySuffix } } /** * 캐시를 읽어옵니다. 캐시를 획득하지 못한 경우 함수 본체를 수행한 결과를 캐싱 후 반환합니다. * @param redisDataType 레디스 데이터 타입 * @param cacheKey 캐시 키 * @param hashKey 해시 키 ([RedisDataType.HASH]의 경우 사용) * @param ttlBySeconds 데이터의 TTL(초) * @param putDataAfterProceed fallback로직 수행 후 데이터 적재 수행 여부 * @param throwWhenReadFail 읽기작업 실패 시 예외 던지기 여부 * @param fallbackFunction 읽기작업 실패 시 수행할 fallback 함수 * @param fallbackReturnType fallback함수의 반환 자료형 */ fun fetchAndPut( redisDataType: RedisDataType, cacheKey: String, hashKey: String, ttlBySeconds: Long, putDataAfterProceed: Boolean = true, throwWhenReadFail: Boolean = false, fallbackFunction: Any?.() -> Any?, fallbackReturnType: Class<*> ): Any? { // 2.레디스로부터 데이터 읽기 시도 val fetchResult = tryReadFromRedis( redisDataType = redisDataType, cacheKey = cacheKey, hashKey = hashKey, // 3-3.throwWhenReadFail가 true면 데이터 읽기 실패 예외를 던지고 종료 throwWhenReadFail = throwWhenReadFail, returnType = fallbackReturnType ) // 3-1.읽기 성공 시 데이터 반환 if (fetchResult !== SAFE_NULL_OBJECT) { return fetchResult } // 3-4.데이터 획득을 위한 fallback함수 수행 val fallbackResult = fallbackFunction() // 4-2.fallback함수 수행 결과를 반환 if (!putDataAfterProceed || isNullOrEmptyData(fallbackResult)) { return fallbackResult } // 4-1.레디스에 데이터 적재 시도 tryWriteIntoRedis( redisDataType = redisDataType, cacheKey = cacheKey, hashKey = hashKey, ttlBySeconds = ttlBySeconds, writeData = fallbackResult!!, // isNullOrEmptyData(..)에서 null 검증을 수행 ) // 7.적재 후 fallback함수 수행 결과를 반환 return fallbackResult } /** * 빈 데이터인지 검증합니다. */ private fun isNullOrEmptyData(data: Any?): Boolean { return when (data) { null -> true is Collection<*> -> data.size == 0 is Map<*, *> -> data.size == 0 else -> data.toString().isBlank() } } /** * Resilience4j적용, 레디스에서 데이터를 읽어옵니다. * 데이터 읽기에 실패하거나 데이터가 없는 경우(null) [SAFE_NULL_OBJECT]를 반환합니다. */ private fun tryReadFromRedis( redisDataType: RedisDataType, cacheKey: String, hashKey: String, throwWhenReadFail: Boolean, returnType: Class<*> ): Any { /* 생략 ... */ } /** * Resilience4j적용, 레디스에 데이터를 쓰고 예외 발생 시 핸들링을 수행합니다. */ private fun tryWriteIntoRedis( redisDataType: RedisDataType, cacheKey: String, hashKey: String, ttlBySeconds: Long, writeData: Any ): Boolean { /* 생략 ... */ } }

캐시 우선 전략을 구현한 범용적인 데이터 조회 모듈로, 주어진 키로 Redis 캐시에서 데이터를 조회하고, 캐시에 없거나 읽기 실패 시 fallbackFunction을 실행해 데이터를 가져온 후 캐시에 저장

그리고 Spring AoP를 활용하여 함수 실행 시 캐시 모듈을 호출하는 DisplayCachingAspect는 아래와 같이 작성되었습니다.

DisplayCachingAspect.kt

@Aspect @Component @Order(Ordered.LOWEST_PRECEDENCE) class DisplayCachingAspect( private val circuitBreaker: CircuitBreaker, private val redisTemplate: RedisTemplate<String, Any?>, private val objectMapper: ObjectMapper, ) { /** * joinPoint와 method로부터 @DisplayCachingKey가 붙은 모든 매개변수들을 추출하여 키 값을 생성합니다. */ private fun makeCacheKey(joinPoint: ProceedingJoinPoint, displayCaching: DisplayCaching, method: Method): String { // @DisplayCachingParamKey가 있는 파라미터 획득 val annotatedParamAndValues = method.parameters .zip(joinPoint.args) // Pair(first: Parameter, second: Actual value) .filter { (param, _) -> param.isAnnotationPresent(DisplayCachingKey::class.java) && !param.getAnnotation(DisplayCachingKey::class.java).forHashKey } // 파라미터 접두사 및 값 변환 일괄 처리 val prefixProcessedParamValue = annotatedParamAndValues.map { val param = it.first val annotation = param.getAnnotation(DisplayCachingKey::class.java) val prefix = annotation.prefix val convertedValue = DisplayCachingKey.convertParamValueToKeyString(it.second) prefix + convertedValue } // 캐시 키 생성 return DisplayCacheModule.makeDefaultCacheKey( baseCacheKey = displayCaching.displayCacheInfo.key, paramValuesForKey = prefixProcessedParamValue, dateTimeSuffixType = displayCaching.dateTimeKeySuffix ) } /** * joinPoint와 method로부터 @DisplayCachingKey(forHash = true)인 매개변수를 추출하여 * 레디스 해시에 사용할 키 값을 생성합니다. */ private fun readHashKeyOrThrow( joinPoint: ProceedingJoinPoint, method: Method, cacheKey: String ): String { try { // @DisplayCachingParamKey가 있는 파라미터중 forHashKey = true인 파라미터 획득 val hashKeyAnnotatedParam = method.parameters .zip(joinPoint.args) .first { (param, _) -> param.isAnnotationPresent(DisplayCachingKey::class.java) && param.getAnnotation(DisplayCachingKey::class.java).forHashKey } val annotatedValue = hashKeyAnnotatedParam.second ?: throw IllegalArgumentException( "'@${DisplayCachingKey::class.simpleName}.forHashKey = true' parameter value should not be null.") // 해시 키 생성 및 반환 val hashKey = DisplayCachingKey.convertParamValueToKeyString(annotatedValue) if (hashKey.isBlank()) { throw IllegalArgumentException( "'@${DisplayCachingKey::class.simpleName}.forHashKey = true' parameter value should not be blank.") } return hashKey } catch (e: Exception) { val exceptionMessage = "Fail to proper '@${DisplayCachingKey::class.simpleName}.forHashKey=true' " + "annotated parameter or value from the '${cacheKey}'. Please check annotation or actual value." throw IllegalStateException(exceptionMessage, e) } } /** * [@DisplayCaching]어노테이션의 around로 동작합니다. */ @Around("@annotation(display.module.cache.annotation.DisplayCaching)") @Throws(Throwable::class) fun aroundDisplayCaching(joinPoint: ProceedingJoinPoint): Any? { // 캐시 모듈을 호출하기 위한 전처리: 리플랙션을 통한 fallback함수 속성, 캐시 키 생성, 어노테이션 속성 추출 등 수행 val method = (joinPoint.signature as MethodSignature).method val annotation = method.getAnnotation(DisplayCaching::class.java) val cacheKey = makeCacheKey(joinPoint, annotation, method) val hashKey = when (annotation.displayCacheInfo.redisDataType) { RedisDataType.HASH -> readHashKeyOrThrow(joinPoint, method, cacheKey) else -> "" // hashKey 는 RedisDataType.HASH일때만 사용 } // 캐시 모듈 호출 return DisplayCacheModule( circuitBreaker = circuitBreaker, redisTemplate = redisTemplate, objectMapper = objectMapper ).fetchAndPut( redisDataType = annotation.displayCacheInfo.redisDataType, cacheKey = cacheKey, hashKey = hashKey, ttlBySeconds = annotation.displayCacheInfo.ttl, putDataAfterProceed = annotation.putDataAfterProceed, throwWhenReadFail = annotation.throwWhenReadFail, fallbackFunction = { joinPoint.proceed(joinPoint.args) }, fallbackReturnType = method.returnType ) } }

@DisplayCaching 어노테이션이 붙은 메서드 호출에 DisplayCachingModule의 캐싱 로직을 적용하는 AoP(관점 지향 프로그래밍)의 Aspect 구현체

최종적으로는 아래와 같은 모습으로 패키지가 구성되었습니다.

📂 display ├── 📂 aop │ └── 📄 DisplayCachingAspect.kt ① Spring AoP 기능을 활용하기 위한 클래스 ├── 📂 config │ └── 📄 DisplayCacheInfo.kt ② 전시영역에서 사용하는 캐시 정보를 담은 열거형(enum) 클래스 └── 📂 module └── 📂 cache ├── 📂 annotation │ ├── 📄 DisplayCaching.kt ③ @DisplayCaching 어노테이션 클래스 │ └── 📄 DisplayCachingKey.kt ④ @DisplayCachingKey 어노테이션 클래스 ├── 📄 DateTimeKeySuffixType.kt ⑤ 일자 접미사로 키 버전을 구현하기 위한 정보를 담은 열거형 클래스 ├── 📄 DisplayCacheModule.kt ⑥ 실질적인 캐시 모듈의 기능을 담당하는 클래스 └── 📄 RedisDataType.kt ⑦ 지원하는 레디스 데이터 종류를 표현하기 위한 열거형 클래스

자체적으로 구현한 커스텀 캐시 모듈 덕분에, 앞서 언급했던 다섯 가지 문제점을 모두 해결할 수 있었습니다.

하지만 프로젝트가 성공적으로 마무리될 무렵, 저희는 예상치 못한 큰 난관에 봉착했습니다.

⚡️ 숨은 문제점: 캐시 스탬피드

캐시 모듈에 숨어있던 문제는 서비스 출시를 앞두고 진행한 부하 테스트 과정에서 발견되었습니다.

특정 캐시가 만료되고 재생성되는 과정에서 서비스 전반의 성능이 저하되는 현상이 발생한 것인데요.

면밀한 디버깅 끝에 저희는 그 원인이 바로 캐시 스탬피드(Cache Stampede) 현상임을 파악했습니다.

📒 캐시 스탬피드 : 캐시 스탬피드란 캐시 데이터의 유효 기간(TTL)이 만료되는 순간, 수많은 동시 요청이 캐시에서 데이터를 찾지 못하고 한꺼번에 백엔드 데이터베이스(DB)로 몰려들어 과도한 부하를 일으키는 현상을 말합니다.

아래 그림처럼, 평소에는 대부분의 트래픽이 Redis와 같은 NoSQL 캐시에서 처리되어 DB는 안정적인 상태를 유지합니다.

✅ 일반 케이스 : 트래픽이 NoSQL(Redis)로 몰려 DB 부하 없음

하지만 캐시 스탬피드가 발생하면 상황은 달라집니다. 캐시 데이터가 만료되는 짧은 순간, 마치 댐이 터지듯 엄청난 수의 요청이 캐시를 뚫고 DB로 쏟아져 들어옵니다.

❌ 캐시 스탬피드 발생 케이스 : 캐시 데이터의 TTL 만료 순간, 수많은 요청이 동시에 DB로 폭주

이 문제는 특히 선물하기 기능의 랭킹 데이터 조회와 같이 무거운 쿼리를 수행하는 곳에서 치명적이었습니다.

평소에도 DB에서 데이터를 가져오는 데 시간이 오래 걸리던 쿼리였기에, 캐시 만료 시점에 요청이 급증하자 서비스 전체의 응답 속도가 현저히 느려지고 장애 발생 위험까지 높아지는 상황에 직면했습니다.

약 3초면 수행되는 API가 캐시 스탬피드가 발생하여 전체적으로 지연되는 상황 발생 😨

이러한 캐시 스탬피드(Cache Stampede) 문제를 해결하기 위해 저희는 여러 대안을 검토했고, 다음과 같은 세 가지 접근법을 찾을 수 있었습니다.

분산 락 (Distributed Lock)

캐시가 만료되었을 때, 락(Lock)을 획득한 하나의 요청만 캐시를 재생성하도록 허용하고 락을 얻지 못한 나머지 요청들은 캐시가 재생성될 때까지 기다림

👍 : DB를 확실하게 보호 가능

👎 : 락을 획득하지 못한 요청들의 지연 발생 및 락 관리의 복잡함 발생

확률적 조기 갱신 (PER: Probabilistic Early Recomputation)

캐시의 TTL이 만료되기 전 확률적으로 fallback을 호출하여 캐시 갱신을 수행, TTL이 만료에 가까워질수록 fallback 수행 확률을 높임

👍 : 비동기 처리를 활용하면 별도의 지연시간 발생 없음

👎 : 낮은 확률이지만 DB에 여러번의 요청이 발생할 수 있음

백그라운드 업데이트

배치 등을 활용하여 데이터를 주기적으로 미리 생성

👍 : DB를 확실하게 보호 가능

👎 : 별도의 배치 서비스 개발 및 운영의 필요성과 실시간 데이터 제공에 제약 발생

프로젝트 마감 기간이 얼마 남지 않아있던 저희는 남아있던 개발 기간과 위험성을 고려하여 분산 락을 이용한 방식으로 문제를 해결하기로 결정하여 설계를 시작했고, 위험 부담이 큰 DB에 락을 거는 방식보다 레디스를 활용하여 락을 거는 방식으로 접근했습니다.

레디스 캐시에 접근했을 때 "display:foo:1"키의 값이 존재하지 않고, 락 옵션을 사용하는 경우 "display:foo:1.lock"을 키로 갖는 데이터를 10초의 TTL로 생성하여 락을 획득한 것을 표현했습니다. (TTL은 프로세스가 비정상 종료되어 영원히 락 해제를 할 수 없는 상황에 대비하기 위해 결정)

이어서, ".lock"데이터 생성에 실패한 경우, 매 초마다 "display:foo:1" 데이터가 생성되었는지 확인하도록 로직을 변경했습니다.

이러한 설계를 바탕으로 DisplayCacheModule에 기능을 추가했으며 코드는 다음과 같이 작성되었습니다.

DisplayCacheModule.kt (Fallback Lock 로직 추가)

/** * fallback 기능을 분산락을 사용하여 한 번만 수행할 때, * 락의 수명과 다시 읽는 주기 등을 설정하기 위한 열거형 클래스 */ enum class FallbackLockOption( val maxLockDurationMs: Long, // 락 수명(밀리초) val sleepMsBetweenObtainLock: Long // 읽기/락 획득 주기(밀리초) ) { // 락 미사용 DISABLED(0L, 0L), // 기본 락 (최대 10초간 락을 걸고, 1초마다 락 해제/데이터 적재여부를 확인) LOCK_10S_CHECK_EVERY_1S(10000L, 1000L); } class DisplayCacheModule( private val circuitBreaker: CircuitBreaker, private val redisTemplate: RedisTemplate<String, Any?>, private val objectMapper: ObjectMapper ) { companion object { // 이전 코드 생략 ... /** * Resilience4j적용, 레디스에서 데이터를 읽어오고 예외 발생 시 핸들링 수행합니다. * 추가로, 데이터 획득 실패 시 락 획득을 시도하고 획득에 성공한 경우 '[isCurrentThreadHasFallbackLock] = true'로 플래그를 설정합니다. */ private fun tryReadFromRedisWithObtainLock( redisDataType: RedisDataType, cacheKey: String, hashKey: String, throwWhenReadFail: Boolean = false, fallbackReturnType: Class<*>, fallbackLockOption: FallbackLockOption = FallbackLockOption.DISABLED, isCurrentThreadHasFallbackLock: AtomicBoolean ): Any { val isFallbackLockEnabled = (fallbackLockOption != FallbackLockOption.DISABLED) val readRetryCount = if (isFallbackLockEnabled) (fallbackLockOption.maxLockDurationMs / fallbackLockOption.sleepMsBetweenObtainLock).toInt() else 1 repeat(readRetryCount) { try { // 1.레디스로부터 데이터 읽기 시도 val readData = circuitBreaker.executeSupplier { tryReadFromRedis( redisDataType = redisDataType, cacheKey = cacheKey, hashKey = hashKey, throwWhenReadFail = throwWhenReadFail, returnType = fallbackReturnType ) } // 2-1.읽기 성공 시 반환 if (readData !== SAFE_NULL_OBJECT) { return readData } } catch (e: Exception) { logger.warn("No data '${cacheKey}' in redis. (readRetryCount: ${readRetryCount})") if (throwWhenReadFail) throw e } // 2-2.읽기 실패 시 if (throwWhenReadFail) { throw NoSuchElementException("No such data '${cacheKey}' in redis.") } // 3.락 획득 시도 if (isFallbackLockEnabled) { if (tryObtainRedisLock( cacheKey = cacheKey, fallbackLockOption = fallbackLockOption, isCurrentThreadHasFallbackLock = isCurrentThreadHasFallbackLock) ) { return@repeat } // 락 획득 실패 시 (1)부터 다시 시작 } } // 레디스에 데이터가 없고, 락 획득도 실패한 경우 도달 return SAFE_NULL_OBJECT } /** * Redis에 .lock 데이터를 생성하여 락 획득을 시도합니다. */ private fun tryObtainRedisLock( cacheKey: String, fallbackLockOption: FallbackLockOption, isCurrentThreadHasFallbackLock: AtomicBoolean ): Boolean { val lockKey = cacheKey + ".lock" val lockValue = "true" try { val lockObtained = circuitBreaker.executeSupplier { redisTemplate.opsForValue().setIfAbsent(lockKey, lockValue, fallbackLockOption.maxLockDurationMs, TimeUnit.MILLISECONDS) } if (lockObtained) { // 4-1.락 획득 성공 isCurrentThreadHasFallbackLock.set(true) return true } else { // 4-2.락 획득 실패 // 과부하 방지를 위해 일정 시간만큼(최소 1ms) 대기 후 레디스 읽기 재시도 // 대기 후 다음 싸이클에 데이터 읽기가 시도됐을 때, // 다른 컨테이너/스레드에서 fallback수행 결과를 적재했다면 여기에 다시 진입하지 않음 Thread.sleep(fallbackLockOption.sleepMsBetweenObtainLock.coerceAtLeast(1L)) return false } } catch (e: Exception) { logger.warn("Fail to obtain lock '${lockKey}' from redis. (${e.message})") return false } } /** * Resilience4j적용, 레디스에 데이터를 쓰고 예외 발생 시 핸들링을 수행합니다. * 추가로, 레디스에 생성되어있던 .lock 데이터의 삭제를 시도합니다. */ private fun tryWriteIntoRedisWithReleaseLock( redisDataType: RedisDataType, cacheKey: String, hashKey: String, ttlBySeconds: Long, writeData: Any, isCurrentThreadHasFallbackLock: AtomicBoolean ) { var isWriteSuccess = false try { // 5.레디스에 데이터 적재 시 isWriteSuccess = tryWriteIntoRedis( redisDataType = redisDataType, cacheKey = cacheKey, hashKey = hashKey, ttlBySeconds = ttlBySeconds, writeData = writeData ) } catch (e: Exception) { logger.warn("Fail to write data '${cacheKey}' into redis.", e) } finally { // 6.락 해제 if (isWriteSuccess && isCurrentThreadHasFallbackLock.get()) { tryReleaseRedisLock(cacheKey = cacheKey) } } } } }

이에 따라, DisplayCacheModule의 fetchAndPut(..)함수도 약간의 변화가 생겼습니다.

DisplayCacheModule.kt - fetchAndPut(..) (Fallback Lock 로직 추가)

/** * 캐시를 읽어옵니다. 캐시를 획득하지 못한 경우 함수 본체를 수행한 결과를 캐싱 후 반환합니다. * @param redisDataType 레디스 데이터 타입 * @param cacheKey 캐시 키 * @param hashKey 해시 키 ([RedisDataType.HASH]의 경우 사용) * @param ttlBySeconds 데이터의 TTL(초) * @param putDataAfterProceed fallback로직 수행 후 데이터 적재 수행 여부 * @param throwWhenReadFail 읽기작업 실패 시 예외 던지기 여부 * @param fallbackFunction 읽기작업 실패 시 수행할 fallback 함수 * @param fallbackReturnType fallback함수의 반환 자료형 * @param fallbackLockOption fallback함수 수행 시 Lock 사용 옵션 */ fun fetchAndPut( redisDataType: RedisDataType, cacheKey: String, hashKey: String, ttlBySeconds: Long, putDataAfterProceed: Boolean = true, throwWhenReadFail: Boolean = false, fallbackFunction: Any?.() -> Any?, fallbackReturnType: Class<*>, fallbackLockOption: FallbackLockOption = FallbackLockOption.DISABLED ): Any? { val threadHasFallbackLock = AtomicBoolean(false) // [Note] 지역 변수는 동시성을 고려하지 않아도 되지만, 락 획득 여부를 참조로 전달하기 위해 사용 // 2.레디스로부터 데이터 읽기 시도 (읽기 실패 시 Lock획득 시도) val fetchResult = tryReadFromRedisWithObtainLock( redisDataType = redisDataType, cacheKey = cacheKey, hashKey = hashKey, // 3-3.throwWhenReadFail가 true면 데이터 읽기 실패 예외를 던지고 종료 throwWhenReadFail = throwWhenReadFail, fallbackReturnType = fallbackReturnType, fallbackLockOption = fallbackLockOption, isCurrentThreadHasFallbackLock = threadHasFallbackLock ) // 3-1.읽기 성공 시 데이터 반환 if (fetchResult !== SAFE_NULL_OBJECT) { return fetchResult } // 3-4.데이터 획득을 위한 fallback함수 수행 val fallbackResult = try { fallbackFunction() } catch (e: Exception) { // fallback수행 중 오류 발생 시 빠른 재시도를 위해 락 해제를 시도하고 예외를 던짐 if (threadHasFallbackLock.get()) { tryReleaseRedisLock(cacheKey) } throw e } // 4-2.fallback함수 수행 결과를 반환 if (!putDataAfterProceed || isNullOrEmptyData(fallbackResult)) { return fallbackResult } // 4-1.레디스에 데이터 적재 시도 (적재 후 Lock해제 시도) tryWriteIntoRedisWithReleaseLock( redisDataType = redisDataType, cacheKey = cacheKey, hashKey = hashKey, ttlBySeconds = ttlBySeconds, writeData = fallbackResult!!, // isNullOrEmptyData(..)에서 null 검증을 수행 isCurrentThreadHasFallbackLock = threadHasFallbackLock ) // 7.적재 후 fallback함수 수행 결과를 반환 return fallbackResult }

마지막으로 캐시 호출부인 @DisplayCaching에도 FallbackLockOption속성이 추가되어 아래와 같이 호출하도록 변경되었습니다.

@DisplayCaching( displayCacheInfo = DisplayCacheInfo.FOO_PAGED, fallbackLockOption = FallbackLockOption.LOCK_10S_CHECK_EVERY_1S // 기본 락 (최대 10초간 락을 걸고, 1초마다 락 해제/데이터 적재여부를 확인) ) fun fetchPagedFooData( @DisplayCachingKey pageNumber: Long ): List<FooDisplayResponseDto> { // HttpAPI호출, DB조회, 비즈니스 로직 }

캐시 모듈에 분산 락을 적용하자, 재실행된 부하 테스트에서 폴백 로직이 정확히 한 번 실행됨을 보여주었습니다.

폴백에 의해 데이터가 채워지는 동안, 다른 프로세스와 스레드들은 매초 레디스에 데이터 적재 여부를 반복적으로 확인했고, 데이터가 적재된 후에야 정상적으로 읽기를 진행했습니다.

최초 .lock을 획득한 로직이 3.25초의 수행 시간이 걸렸고 비슷한 시점에 들어온 요청은 DB호출 없이 약 3초간 레디스 호출, 데이터가 레디스에 적재된 후 부터 빠르게 응답받음을 확인

🎁 마치며

많은 고민과 노력 끝에 다사다난했던 선물하기 기능 개편을 성공적으로 마무리할 수 있었는데요. 👏

이로써 평균 1.74초가 소요되던 페이지 로딩 시간을 5밀리초로 크게 개선시킬 수 있었습니다.

또한, 새로 개발된 캐시 모듈을 통해 기존의 불편함을 개선하고 '캐시 스탬피드'라는 잠재적 위험 요소까지 해결할 수 있었습니다.

하지만 여기서 끝이 아니었습니다. 개인적으로는 아무리 좋은 기능을 만들었더라도 이를 제대로 공유하고 전파하는 과정 또한 매우 중요하다고 생각했기에 새로 개발된 기능에 대해 팀 내에 공유하고 전파하는 시간을 별도로 마련했습니다.

여러분도 새로운 기능을 개발했다면, 팀원들과 지식을 나누는 시간을 가져보는 것은 어떨까요?

선물하기 캐시 모듈 개발은 단순히 기능을 구현하는 것을 넘어, 안정적인 서비스의 기반을 다지는 여정이었습니다. 그리고 이 여정은 현재 진행형입니다.

저희는 예측 가능한 문제를 넘어, 아직 수면 위로 드러나지 않은 위험까지 찾아 해결하는 과정을 통해 기술적 깊이를 더해가고 있습니다.

혹시 저희가 놓치고 있는 부분이 보이시나요? 올리브영은 함께 더 나은 기술적 해답을 찾아낼 동료를 언제나 기다리고 있습니다.

저희와 함께 다음 기술 블로그의 주인공이 되어 보시는 것은 어떠신가요?

긴 글 함께해주셔서 진심으로 감사합니다.

올리브영 물류 시스템의 진화 - 고객 경험의 시작과 끝을 함께하다

Fri, 01 Aug 2025 00:00:00 GMT

안녕하세요! 올리브영에서 물류 시스템을 개발하는 올여우🦊입니다.
올리브영의 물류 시스템은 비즈니스의 성장과 발맞춰 끊임없이 진화하고 있습니다. 오늘은 올리브영의 물류와 재고 그리고 배송에 대한 이야기를 들려드리겠습니다.

개요 : 고객 여정의 시작부터 끝까지 함께하는 올리브영 물류

올리브영의 물류 시스템은 고객의 Discovery(상품 발견)부터 Last Mile(최종 배송)까지 모든 여정에 함께 합니다. 고객이 온라인몰(국내/글로벌)이나 매장에서 상품을 탐색하고 주문하는 순간부터 고객에게 전달되는 마지막 순간까지, 물류 시스템은 모든 과정을 유기적으로 연결하고 있습니다.

먼저, 올리브영의 주요 물류 시스템을 간단하게 소개 드리겠습니다.

1. 재고 시스템 (Inventory System)

재고 시스템은 고객이 원하는 상품을 구매할 수 있도록 정확한 재고 정보를 제공합니다. 온라인몰에서는 재고 관리가 곧 주문으로 이어지며, 품절 시 즉각적인 표시와 재입고 알림 기능으로 고객 불편을 최소화합니다. 또한 매장 방문 전 온라인몰에서 재고 현황을 확인하거나, 매장에서 전자라벨로 실시간 재고를 확인할 수 있습니다. 나아가 재고는 정확한 발주, 빠른 배송 등 물류 프로세스 전반의 기초 데이터로 활용됩니다.

2. 주문 관리 시스템 (OMS, Order Management System)

OMS는 고객 주문을 실시간으로 처리하고 통합 관리하는 시스템입니다. 고객이 온라인몰에서 주문을 하면 OMS를 통해 주문 정보가 물류센터(WMS)에 즉시 전달됩니다. 이후 물류센터에서 출고 작업을 거쳐 배송이 시작되면 OMS는 해당 정보를 다시 고객에게 전달합니다. OMS는 주문과 물류센터 현장 업무를 연결하는 핵심 역할을 수행합니다. 또한 OMS는 재고와 발주 등 주요 물류 데이터를 통합 처리하는 시스템이기도 합니다.

3. 창고 관리 시스템 (WMS, Warehouse Management System)

WMS는 입고, 보관, 피킹, 출고, 재고, 반품 등 물류센터 업무 전반을 관리하는 핵심 시스템입니다. OMS에서 전달된 데이터는 WMS를 통해 물류센터 현장 업무에 반영되며, 고객의 주문정보를 바탕으로 상품을 피킹하고 출고 작업이 진행됩니다. 최적의 WMS 구축은 물류 서비스 효율을 높여 고객 배송 서비스 향상으로 이어집니다.

4. 배송 시스템 (Delivery System)

배송시스템은 출고된 상품을 고객에게 신속하고 정확하게 전달합니다. 배송최적화 기능을 통해 주문별 최적의 배송 경로와 방법을 결정하여 배송 리드타임을 최소화합니다. 또한 고객 주문 패턴과 배송 데이터를 분석해 지연 요인을 최소화하고 고객 만족도를 높이는 데 기여합니다. 물류센터, MFC, 매장 등 다양한 경로를 활용해 고객이 원하는 시점에 상품을 받을 수 있도록 지원합니다.

5. 발주 시스템 (Logistics Ordering System)

고객 구매 상품 재고가 소진되면, 다음 판매를 위해 재고를 확보해야 합니다. 바로 발주가 이루어지는 순간입니다. 자동발주 기능을 통해 고객의 구매 패턴과 재고 현황을 분석하여 최적의 발주를 실행합니다. 이를 통해 재고 부족 문제를 최소화하고, 고객에게 필요한 상품을 적시에 제공합니다. 동시에 판매가 부진한 상품의 발주를 제한해서 재고 과잉 문제 또한 예방합니다.

이러한 물류 시스템은 올리브영이 고객에게 최고의 구매 경험을 제공하는 데 중요한 역할을 합니다.
아래는 전체적인 물류 시스템 구성도입니다.

물류 시스템 구성도

그럼 이제 각 시스템을 순서대로 살펴볼까요?
시스템이 어떻게 개선되었고 어떤 성과를 냈는지, 또 고객 경험과 운영 효율성에 어떤 영향을 주었는지 함께 알아보겠습니다.

Inventory API 구축 : 실시간 재고로 고객 만족도 극대화

올리브영은 온라인과 오프라인 서비스를 모두 제공하는 O2O(Online to Offline) 기업의 대표 주자입니다. 특히 온라인몰에서 주문하면 가까운 매장과 MFC에서 당일 배송하는 오늘드림은 올리브영의 핵심 O2O 서비스입니다.

다양한 O2O 서비스를 원활히 제공하려면 온/오프라인의 정확한 재고를 모두 파악하는 것이 필수적입니다. 하지만 기존에는 재고 데이터가 온/오프라인 각각의 시스템으로 분리되어 있었습니다. 이로 인해 사용성이 떨어지고, 레거시(오래된 시스템) 성능 이슈도 빈번했습니다. 또한 배치와 EAI를 통한 일괄 재고 반영 방식은 처리 지연과 잦은 오류로 이어져 재고 데이터의 정확성(정합성)을 떨어뜨렸습니다. 이는 결국 고객 경험 악화로 직결되었습니다. 예를 들어, 온라인몰에서 주문했는데 재고가 없어서 취소되거나, 매장 재고를 확인하고 픽업을 갔는데 막상 매장에는 재고가 없는 경우가 비일비재했습니다.

이러한 문제를 해결하고자 올리브영은 온/오프라인 재고를 통합하고 시스템을 모던화하는 프로젝트를 진행했습니다. Amazon MemoryDB로 재고 전용 데이터베이스를 구축해서 안정성을 높였고, Amazon MSK(Managed Streaming for Apache Kafka)로 메시지 기반의 실시간 재고 연동을 구현했습니다. 그 결과, 올리브영의 모든 서비스에서 빠르고 간편하며 안정적인 Inventory API를 통해서 재고 조회가 가능해졌습니다. 이 시스템은 온라인몰, 오늘드림, 검색, 매장, MFC, 전자라벨, PDA, POS, 백오피스, 파트너오피스 등 주요 서비스에 모두 적용되었습니다.

실시간 재고 조회는 고객 경험을 크게 향상시켰습니다. 우선 고객이 주문 후에 재고가 부족해서 취소되는 결품률을 이전 대비 50% 이상 낮췄습니다. 또한 고객은 언제든 방문할 매장의 정확한 재고 현황을 확인할 수 있고, 필요한 경우 원하는 상품을 미리 픽업할 수도 있습니다. 이러한 고객 경험 향상은 곧 매출 증가로 이어집니다.

내부 사용자들도 큰 변화를 체감하고 있습니다. 통합 대시보드(OpenSearch/Datadog)를 통해 실시간 및 히스토리 재고 데이터를 간편하게 조회할 수 있습니다. 기존에는 재고 문제가 발생했을 때 원인 추적에 오랜 시간이 걸렸습니다. 심지어 원인을 찾지 못하고 넘어가는 경우도 다반사였습니다. 이제는 누구나 대시보드를 통해 재고 데이터에 접근할 수 있고 활용할 수 있습니다. 특히, 재고 이슈 발생 시 5단계 이상의 복잡한 확인 절차를 2단계로 축소하여 빠른 원인 분석 및 대응이 가능해졌습니다. 또한 수억 건으로 파편화된 데이터 탓에 10분 이상 걸리던 대용량 재고 조회 시간을 평균 1~3초로 대폭 개선했습니다. 이처럼 통합 대시보드를 통해 전반적인 재고 운영 효율이 대폭 향상되었습니다.

신규 재고 시스템 구축에 대한 더 자세한 이야기는 이전 블로그 글에서 확인하실 수 있습니다.

재고 통합 시스템 아키텍처 다이어그램

OMS (Order Management System) 구축 : 주문부터 배송까지 Seamless 연결

기존 올리브영의 물류 시스템은 EAI(Enterprise Application Integration) 방식의 데이터 연동으로 잦은 오류와 지연 처리, 그로 인해 빈번한 시스템 장애를 발생시켰습니다. 이러한 문제를 해결하고 운영 안정화 및 효율성을 높이기 위해, 메시지 기반의 데이터 파이프라인으로 구성된 OMS를 구축했습니다. 이제 물류센터의 주요 데이터는 안정적으로 준실시간 연동됩니다.

그럼 물류 데이터의 실시간 연동이 왜 필요할까요? 바로 물류센터 업무 효율화와 재고 데이터 정확성(정합성) 향상이 가능하기 때문입니다.

물류센터 업무 효율화 : 물류 공정 시간 단축으로 고객 배송 만족도 향상

온라인몰에서 주문이 들어오거나 매장에서 발주가 이루어지면 해당 데이터는 물류센터(WMS)로 전달됩니다. 그럼 물류센터는 출고 작업을 비롯한 현장 처리 정보를 다시 올리브영(OMS)에 전달합니다. 이외에도 올리브영(OMS)과 물류센터(WMS)는 수많은 데이터를 주고받습니다.
그런데 데이터 연동이 30분마다 된다면? 데이터 처리에 잦은 지연과 오류가 발생한다면? 당연히 물류센터 현장 작업이 지연되고 고객 배송 또한 늦어질 수밖에 없습니다.
올리브영은 시스템 개편을 통해 물류 전체 공정 시간을 70% 이상 절감했으며, 특히 주문량이 폭발적으로 증가하는 올영세일 기간에도 센터 배송 리드타임을 3일 이내로 단축했습니다. 매 분기 진행되는 올영세일은 그동안 엄청난 주문량 때문에 센터 배송 지연이 아쉬웠지만, 이번 개편으로 고객 만족도를 크게 높일 수 있었습니다. 물론 세일 기간에도 오늘드림은 변함없이 빠른 배송을 자랑합니다.

재고 데이터 정합성 향상 : 온라인몰 매출 증가로 이어지는 재고 관리

물류센터의 재고를 실시간으로 파악할 수 있게 되면서, 온라인몰에서 판매 기회가 크게 증가했습니다. 동시에 주문 후 재고 부족으로 인해 주문이 취소되는 결품률 또한 대폭 줄었습니다. 이처럼 재고 정합성 향상은 곧 온라인몰 매출 증가와 고객 경험 향상으로 이어집니다.

올리브영은 OMS 구축을 통해 물류센터와의 데이터 연동을 개선하고, 물류 프로세스 효율화를 이끌어내고 있습니다.

OMS 시스템 아키텍처 다이어그램

WMS (Warehouse Management System) 구축 : WMS 내재화로 글로벌 물류 경쟁력 강화

커머스 서비스의 성장은 물류 역량 강화와 떼려야 뗄 수 없는 관계에 있습니다. 그중에서도 WMS(창고 관리 시스템)는 물류의 핵심 시스템입니다.
지금까지 올리브영은 외부 WMS에 의존했습니다. 외부 시스템은 도입이 간편한 대신 기능 확장과 프로세스 개선에 한계가 분명합니다. 올리브영의 성장과 물류 도메인 확장을 위해 WMS 내재화가 필수적인 시점입니다.

글로벌 WMS 내재화 : 성장의 첫 번째 목표

올리브영은 WMS 내재화의 첫 번째 목표를 글로벌 WMS 구축으로 정했습니다. 혹시 올리브영에 글로벌몰이 있다는 사실, 알고 계셨나요? 글로벌몰은 해외 고객이 주문하면 한국에서 직접 해외로 배송해 주는 서비스입니다. 기존 글로벌몰 WMS는 외부 시스템에 의존하고 있어, 급변하는 시장 상황에 신속히 대응하기 어려웠습니다. 그 결과, 운영의 비효율성과 물류 생산성 저하가 발생했습니다. 또한 물류센터 내 동선 최적화나 신규 장비 도입과 같은 효율화 작업이 외부 시스템의 제약으로 인해 지연되거나 무산되는 경우도 있었습니다. 반복적인 외부 시스템 투자에도 불구하고 비용은 계속 증가하고, 산출물은 지속적으로 소실되면서 서비스 자산화의 필요성이 시급한 과제로 떠올랐습니다. 올리브영의 넥스트 플랜은 글로벌입니다. 글로벌몰 성장뿐 아니라 미국, 일본 등 글로벌 비즈니스를 확장하고 있는 만큼, 강력한 물류 시스템이 뒷받침되어야 합니다.

올리브영은 자체 WMS를 성공적으로 구축하며, 전사 비즈니스 전략에 맞춘 확장 가능한 물류 플랫폼을 마련했습니다. 이번 시스템 구축으로 주문할당, 피킹지시 등 주요 공정 시간이 평균 80% 절감되었고, 출고 조회를 비롯한 WMS 주요 기능의 성능이 90% 이상 개선되는 놀라운 성과를 이루었습니다. 그 결과, 글로벌 WMS 오픈 이후 처음 진행된 올영세일에서 출고량이 기존 대비 약 50% 증가하며 역대 최고치를 경신했습니다.

이번 올리브영 WMS 구축을 기반으로, 앞으로는 사용 중인 외부 물류 시스템들을 순차적으로 내재화할 계획입니다. 또한 그동안 시스템 제약으로 시도할 수 없었던 고도화 과제들도 하나씩 수행해 나가고 있습니다. 이처럼 물류 시스템 내재화는 올리브영의 물류 서비스 경쟁력을 강화하고, 궁극적으로 올리브영의 미래 성장을 위한 든든한 밑거름이 됩니다.

글로벌 WMS 시스템 아키텍처 다이어그램

배송최적화 시스템 구축 : 빠르고 정확한 고객 맞춤 배송

보통 온라인에서 구매하면 센터 배송으로 고객에게 전달되지만, 올리브영의 배송은 계속해서 다각화되고 있습니다. 물류센터는 기존 양지센터에 더해 경산/안성 센터가 추가되었고, 오늘드림은 매장에서 시작했지만 지금은 MFC에서 더 많은 배송이 이루어지고 있습니다. 물류 시스템이 다각화되고 규모가 커진 만큼 배송도 최적화할 필요가 생겼습니다. 예전처럼 주문하면 센터에서 배송되는 단순한 구조가 아니기 때문입니다. 그래서 올리브영은 고객이 빠르게 배송받을 수 있는 최적화 시스템을 구축하고 있습니다.

배송최적화 시스템의 원리는 간단합니다. 고객이 필요한 상품을 적시에 제공하고 빠르게 배송하는 시스템입니다.

예를 들어, 고객 A가 3개의 상품을 구매하고 싶을 때 2개 상품은 1번 물류센터에 재고가 있지만 1개 상품은 재고가 없다고 가정해 보겠습니다. 현재는 주문이 성립하지 않거나 주문 후 결품으로 취소 처리되어 고객에게 좋지 않은 경험을 제공하게 됩니다.
만약 1번 물류센터에 재고가 없더라도 2번 물류센터에 재고가 있다면.. 아니면 인근 매장이나 MFC에 재고가 있다면..
현재는 다른 곳에 재고가 있어도 팔지 못해 판매 기회 손실이 수시로 발생합니다. 현실적으로 모든 센터에 모든 상품 재고를 보관할 수는 없습니다.

또한 물류센터 CAPA(Capacity, 물류 처리 용량)를 효율적으로 관리하지 못하면 수시로 배송 리드타임 지연이 발생할 수 있습니다. 예를 들어 1번 물류센터 CAPA가 100건인데 150건의 주문이 들어오면, 50건은 배송이 지연될 수밖에 없습니다. 하지만 2번 물류센터 CAPA에 여유가 있다면, 당연히 2번 물류센터에서 주문을 처리하면 배송 리드타임을 단축할 수 있습니다. 현재도 센터별로 CAPA 관리를 하고 있지만, 데이터를 기반으로 더욱 체계화되고 효율적인 프로세스 구축이 필요합니다.

배송최적화 시스템이 구축되면 고객은 전혀 다른 경험을 하게 됩니다. 재고를 보유한 가까운 곳에서 고객에게 신속히 배송합니다. 또한 주문 상품을 분할해서 재고 보유를 기준으로 여러 곳에서 분리 배송도 가능해집니다. 고객에게 판매 기회는 증가하고 배송과 재고로 인한 주문 취소는 감소하게 됩니다. 배송최적화 시스템 구축은 이제 막 첫걸음을 떼었습니다.

배송최적화 프로세스

자동발주 시스템 구축 : 효율적인 재고 관리의 시작

그동안 올리브영의 발주는 엑셀을 통한 수기 계산으로 이루어졌습니다. 발주 담당자들이 기준 데이터를 모아 엑셀에 입력하면 계산되는 방식입니다. 물류 서비스가 확장될수록 담당자 업무가 계속 늘어날 수밖에 없었고, 발주 데이터가 많아질수록 정확도 역시 떨어질 수밖에 없는 구조였습니다.

발주 정확도 향상과 운영 효율화를 위해 자동발주 시스템 구축이 시급한 상황입니다. 몇 년 전 매장 자동발주 시스템을 우선 구축하여 발주 운영 효율을 개선했지만, 레거시 시스템 기반이라 기능 확장에 제약이 있었습니다. 올리브영의 최종 목표는 매장을 넘어 MFC, 온라인 등 전체 시스템의 통합 자동발주입니다. 이를 위해 기존 수기 계산 중인 개별 시스템을 모던 아키텍처로 전환하는 작업이 필요합니다.

첫 번째로 MFC 자동발주 전환을 진행하고 있습니다. 수기로 계산 중인 MFC 발주 업무를 전면 자동화합니다.
올리브영의 오늘드림 배송은 어떻게 그렇게 빠를까요? 바로 MFC(Micro Fulfillment Center) 덕분입니다. 일반 물류센터가 외곽에 있는 반면, 도심형 소규모 물류센터인 MFC는 고객 가까이 위치해서 빠른 배송을 가능하게 합니다. 올리브영은 물류 서비스 경쟁력을 강화하고 퀵커머스를 확대하기 위해 전국 주요 도심에 MFC를 확장하고 있습니다. 실제로 고객 경험이 좋은 오늘드림의 매출은 꾸준히 상승 중이며, 그에 따라 MFC 발주의 최적화 필요성은 점점 커지고 있습니다.

올리브영은 자동발주 시스템 구축을 통해 효율적인 재고 관리와 판매 기회 증가를 목표로 합니다. 고객이 필요할 때 해당 상품을 발주해서 재고를 확보하는 것이 핵심입니다. 또한 발주 담당자들의 업무를 경감하고, 과잉 재고로 인한 비용을 최소화할 수 있습니다.

나아가 자동발주에 더해 수요예측을 준비하고 있습니다. 최적의 발주는 다양한 조건 고려가 필수입니다.
주요 발주 조건은 판매량/잔여재고/프로모션/상품특성/브랜드/카테고리/요일/지역/날씨/계절/고객성향/구매시간/POG/매장특성/온라인판매여부... 등이 있는데, 이 모든 조건을 사람이 선별하고 계산해서 발주에 반영하는 것은 불가능에 가깝습니다. 그렇기 때문에 저희는 올리브영만의 다양한 데이터를 수집하고 수요예측 모델링을 진행해서 발주 정확도를 더욱 높일 계획입니다.

자동발주 프로세스

마치며 : 진화를 멈추지 않는 올리브영 물류 시스템

오늘은 올리브영의 물류 시스템 전반을 이야기했습니다.
물류 시스템은 PHASE 1을 넘어 PHASE 2가 진행 중입니다.

PHASE 1에서는 레거시 시스템의 모던화와 분산형 기술(MSA, AWS, Kafka, OpenSearch, Redis, Datadog 등)에 집중했습니다.
이를 통해 올리브영의 기술 내실을 다지고 비즈니스 확장에 기여했습니다.

PHASE 2에서는 AI를 중심으로 한 생성형 및 추론형 기술에 집중합니다.
이미 구축된 시스템과 데이터를 기반으로 효율화와 최적화를 구현합니다.

이러한 노력은 올리브영의 지속적인 비즈니스 확장과 차별화에 기여할 것입니다.
올리브영의 성장과 함께 물류 시스템의 진화는 계속되고 있습니다.

아직 할 이야기가 많지만, PHASE 2가 완성되면 또 찾아뵙겠습니다~!
긴 글 읽어 주셔서 감사합니다.

우리 스쿼드에서 같이 일하실래요?

Wed, 30 Jul 2025 18:00:00 GMT

반갑습니다! 오늘도 올리브영입니다!

반갑습니다! 올리브영 백엔드 개발자 유롱롱입니다! 🐶

개발 조직의 스쿼드 운영 방식, 어떻게 돌아가나요?

요즘 개발 조직에서는 빠르게 변화하는 요구에 유연하게 대응하기 위해 다양한 방식의 조직 구조를 도입하고 있습니다.

그 중 하나가 바로 '스쿼드(Squad)'라는 형태입니다.

이번 글에서는 스쿼드란 무엇인지부터 업무를 실제로 어떻게 운영하는지까지, 올리브영의 일하는 방식을 정리해보려 합니다.

1. 스쿼드란 무엇인가요?

스쿼드는 다양한 역할의 팀원이 모여 하나의 기능이나 서비스를 중심으로 자율적으로 운영되는 작은 단위 조직입니다.

기획자, 디자이너, 프론트엔드/백엔드 개발자, QA 등이 모두 한 팀 안에 포함되어 있어 빠른 의사결정과 협업이 가능하죠.

이 개념을 쉽게 게임에 빗대어 보자면, 하나의 게임 파티와 유사합니다.

파티는 보통 특정 레이드를 공략하거나 목표를 위해 각기 다른 직업의 캐릭터들이 모여 협력합니다.

전사, 힐러, 마법사처럼 역할은 다르지만, 같은 목표를 향해 함께 움직입니다. 스쿼드도 마찬가지입니다.

📌 예시 그림 설명:

스쿼드 이해하기

2. 기능 조직 vs 목적 조직

전통적인 개발 조직은 기능 조직(Function-based)입니다. (예: 프론트엔드 팀, 백엔드 팀, QA 팀.)

스쿼드는 목적 조직(Purpose-based)이며, 하나의 기능을 중심으로 다양한 역할이 모여 있는 형태입니다.

구분 기능 조직 목적 조직(스쿼드)

구성 기준 기술/역할 기반 목적/기능 기반

커뮤니케이션 팀 간 협업 필요 팀 내 협업으로 신속함

장점 기술 전문성 강화 빠른 실행, 책임 분산

단점 병목/지연 발생 가능 기술 중복/일관성 문제 가능

3. MSA와 스쿼드 운영, 왜 잘 어울릴까요?

올리브영은 지금 MSA(마이크로서비스 아키텍처) 라는 구조로 서비스를 만들고 있습니다.

이 방식은 서비스 하나를 여러 개의 작고 독립적인 단위로 나누어 관리하는 구조로, 빠르게 바뀌는 시장에 잘 대응할 수 있는 장점이 있습니다.

여기에 스쿼드(Squad) 조직을 더하면 더 큰 효과를 낼 수 있습니다.

MSA와 스쿼드는 아주 잘 맞는 조합입니다

올리브영은 이미 MSA 구조를 쓰고 있기 때문에, 스쿼드 운영 방식은 자연스럽게 어울립니다.

각각의 스쿼드가 하나의 마이크로서비스를 맡아서 책임지고 운영할 수 있기 때문입니다.

이렇게 되면 좋은 점이 많습니다

빠르게 일할 수 있어요 : 각 스쿼드가 독립적으로 일하고, 직접 배포도 할 수 있어서 속도가 빨라집니다.

자율성이 커져요 : 스쿼드가 자기 서비스에 필요한 기술이나 도구를 자유롭게 선택할 수 있어, 더 효율적으로 일할 수 있습니다.

책임이 명확해요 : 어떤 서비스에 문제가 생기면 누가 담당인지 명확하니, 빠르게 대응할 수 있습니다.

단점도 있지만, 해결할 수 있어요

물론 단점도 있어요. 스쿼드마다 사용하는 기술이나 방식이 다르면 추후 관리가 어려울 수 있습니다.

상품 조회 기능을 구현하는 경우를 예로 들어볼게요.

A팀은 빠른 응답 속도를 위해 Redis 캐시를 적극적으로 활용하고, 일부 데이터는 메모리에도 상주시키는 구조로 만들었습니다.

반면 B팀은 실시간성을 중요하게 여겨, 상품 정보를 매 요청마다 데이터베이스에서 직접 조회하도록 구현했습니다.

“상품 조회”라는 같은 기능임에도 두 팀의 구현 방식이 다르다 보니, 사용자 경험이나 성능 면에서 차이가 발생할 수 있습니다. 다시 말해, 통합적으로 성능 개선이나 공통 API 설계가 필요할 때 큰 어려움이 생길 수 있죠.

하지만 이런 문제는 공통 가이드라인이나 기술 리뷰 등을 통해 충분히 조정할 수 있습니다. 자율성을 유지하면서도 기본적인 원칙은 함께 지키는 것이 중요합니다.

📌 예시 그림 설명:

[MSA와 스쿼드 연결도] ┌──────────────┐ │ 스쿼드 A │ → 마이크로서비스 A ├──────────────┤ │ 스쿼드 B │ → 마이크로서비스 B ├──────────────┤ │ 스쿼드 C │ → 마이크로서비스 C └──────────────┘ → 각 서비스는 API, 배포까지 독립적으로 운영

4. 2주 스프린트 & Jira로 스토리포인트 산정

스쿼드는 보통 2주 단위의 스프린트로 업무를 계획하고 실행합니다.

이 방식은 정해진 시간 안에 해야 할 일을 명확히 정리하고, 팀원 모두가 같은 목표를 바라보며 일할 수 있게 도와줍니다. 업무는 각각 예상되는 작업량과 난이도를 기준으로 스토리 포인트(Story Point) 를 부여해 관리합니다.

올리브영에서는 각 스쿼드마다 기준이 있는데 제가 소속되어있는 스쿼드는 다음과 같은 기준을 사용하고 있습니다:

기준: 1포인트 = 1일 작업량 (1명이 하루 동안 할 수 있는 일)

도구: Jira

📌 예시 그림 설명:

[Jira에서 스프린트 구성] ┌────────────────────────────┐ │ Sprint: 2025-07-01 ~ 07-14 │ ├────────────────────────────┤ │ ▢ [3pt] 로그인 API 리팩터링 │ │ ▢ [2pt] UI 오류 수정 │ │ ▢ [5pt] 새로운 결제 모듈 │ └────────────────────────────┘ → 총 10포인트 = 10일 분량

이렇게 하면 좋은 이유

일정 예측이 쉬워요 : 각 스프린트가 10포인트라면, 2주 동안 어느 정도 양의 일을 할 수 있는지 감이 생깁니다.

업무 우선순위가 명확해요 : 중요한 일부터 포인트를 할당하고 계획하므로, 어디에 집중해야 할지가 분명해집니다.

업무 부담 조절이 쉬워요 : 지나치게 많은 업무가 쌓이지 않도록 조정할 수 있습니다.

각 업무 항목에 포인트를 미리 정해두면, 스프린트가 끝날 때 실제 진행 상황과 비교하여 예측 정확도를 점검할 수도 있습니다.

이를 바탕으로 다음 스프린트 계획이 더 정교해집니다.

5. 회고 → 플래닝: 돌아보고, 다음을 준비하기

스프린트가 끝나면 팀은 회고(Retrospective) 시간을 가집니다.

이 시간은 지난 2주 동안 어떤 점이 잘 됐고, 어떤 점은 개선이 필요했는지를 함께 돌아보는 중요한 과정입니다.

하지만 회고가 아쉬운 점 중심으로만 흐르면, 팀 분위기가 무거워질 수 있습니다.

그래서 올리브영에서 저의 스쿼드는 긍정적인 피드백과 개선점이 균형 있게 나올 수 있도록 다음과 같은 방식을 사용합니다:
“좋았던 점 하나 + 아쉬운 점 하나”를 함께 말하기

모든 팀원이 돌아가며 각자 한 가지씩

자연스럽게 서로를 격려하고

놓치기 쉬운 피드백까지 챙기고

회고를 통해 얻은 인사이트는 곧바로 다음 단계인 플래닝(Planning) 으로 이어집니다.

플래닝에서는 다음 스프린트 동안 어떤 일을 할지 정리하고, 스프린트 목표와 우선순위를 명확히 합니다.

이 과정을 통해 팀은 매 스프린트마다 작게라도 더 나아지고, 협업 방식도 지속적으로 개선해 나갈 수 있습니다.

스쿼드 운영 방식은 자율성과 책임, 빠른 실행력과 피드백 사이의 균형을 잘 유지해야 효과를 발휘합니다.

단순히 팀을 나누는 것 이상의 조직 문화와 협업 방식이 필요하기 때문에, 그 안에서의 경험과 학습이 굉장히 중요합니다.

혹시 스쿼드를 운영 중이거나 준비하고 계시다면, 이 글이 조금이나마 도움이 되었으면 좋겠습니다! 🚀

프론트엔드 개발자를 위한 5가지 스크롤 복구 시나리오와 실전 코드 팁

Wed, 30 Jul 2025 17:30:00 GMT

안녕하세요! 올리브영 프론트엔드 개발자 hee 입니다‍

여러분은 혹시 사용자가 이전에 보던 화면 그대로 다시 보여주려다 예상치 못한 스크롤 위치 때문에 당황했던 경험이 있으신가요? SPA 환경에서 '스크롤 복구(Scroll Restoration)'는 단순해 보여도 개발자를 끊임없이 괴롭히는 난제 중 하나입니다. 이번 포스팅에서는 올리브영 프론트엔드 개발팀이 다양한 프로젝트에서 마주했던 스크롤 복구 이슈들을 어떻게 해결해왔는지, 그 생존 전략과 실전 팁들을 공유해드리고자 합니다. 이 글이 여러분의 '스크롤 지옥' 탈출에 조금이나마 도움이 되기를 바랍니다!

Scroll restoration이란?

Scroll restoration은 사용자가 페이지를 떠났다가 다시 돌아왔을 때, 이전에 보고 있던 스크롤 위치를 자동으로 복구하는 기능입니다. 전통적인 웹사이트에서는 브라우저가 자동으로 이 기능을 제공했지만, 현대의 SPA(Single Page Application) 환경에서는 여러 가지 기술적 제약으로 인해 이 기능이 제대로 작동하지 않는 경우가 많습니다.

이러한 스크롤 위치 복구 실패는 사용자 경험에 심각한 영향을 미칩니다. 특히 긴 목록을 스크롤하다가 상세 페이지로 이동한 후 다시 돌아왔을 때 맨 위로 되돌아가는 현상은 사용자들에게 큰 불편함을 안겨줍니다. 이는 단순히 불편함을 넘어서 사용자의 이탈률 증가와 전반적인 서비스 만족도 저하로 이어질 수 있어, 현대 웹 개발에서 반드시 해결해야 할 중요한 과제 중 하나입니다.

SPA 환경에서 스크롤 복구가 어려운 이유

SPA에서 스크롤 복구가 어려운 이유를 차근차근 살펴보겠습니다. 전통적인 멀티 페이지 웹사이트에서는 각 페이지가 독립적인 HTML 문서였습니다. 브라우저는 사용자가 페이지를 떠날 때 스크롤 위치를 기억해두었다가, 다시 그 페이지로 돌아올 때 자동으로 복구해주었습니다.

하지만 SPA의 동작은, 하나의 페이지 안에서 JavaScript가 콘텐츠를 동적으로 바꾸는 방식입니다. 이 때 브라우저 입장에서는 계속 같은 페이지에 머물러 있다고 인식하기 때문에, 기본적인 스크롤 복구 기능이 제대로 작동하지 않습니다.

더 복잡한 문제는 현대 웹 애플리케이션의 특성에서 나타납니다. 데이터를 비동기적으로 불러오고, 무한 스크롤을 구현하며, 콘텐츠의 높이가 동적으로 변하는 환경에서는 단순히 스크롤 위치만 저장하는 것으로는 해결되지 않습니다. 페이지를 다시 방문했을 때 데이터가 아직 로드되지 않았거나, 동적으로 생성되는 콘텐츠의 높이가 달라질 수 있기 때문입니다.

상황별 스크롤 복구 방법

실제 프로젝트에서 마주했던 다양한 상황들을 유형별로 분류해서 살펴보겠습니다. 각 상황마다 최적의 해결책이 다르다는 것을 이해하는 것이 중요합니다.

1) 정적인 데이터 상황

가장 간단한 경우부터 시작해보겠습니다. 페이지의 모든 데이터가 미리 로드되어 있고, 콘텐츠의 높이가 변하지 않는 상황입니다. 이런 경우에는 브라우저의 History API를 활용하여 비교적 쉽게 해결할 수 있습니다.
아래 예제에서는 단순하게 History API를 사용해서 scrollY값을 저장했지만 Web Storage를 이용하거나 URL 쿼리를 이용해서 저장할 수 있습니다.

// 기본적인 스크롤 위치 저장 및 복구 function setupBasicScrollRestoration() { // 페이지를 떠날 때 현재 스크롤 위치를 저장 window.addEventListener('beforeunload', () => { const scrollY = window.scrollY; history.pushState({ scrollY }, null, '?page=1'); }); // 페이지로 돌아왔을 때 저장된 위치로 스크롤 window.addEventListener('popstate', (event) => { if (event.state && event.state.scrollY) { setTimeout(() => { window.scrollTo(0, event.state.scrollY); }, 100); } }); }

정적인 데이터 환경에서는 이 방법이 매우 효과적입니다. 하지만 실제 프로젝트에서는 대부분 동적인 데이터를 다루기 때문에 더 복잡한 접근이 필요합니다.

2) 동적인 데이터 상황

동적인 데이터를 다루는 상황에서는 단순히 스크롤 위치만 저장하는 것으로는 부족합니다. 데이터가 비동기적으로 로드되면서 페이지의 높이가 변하기 때문에, 저장된 스크롤 위치가 의미 없어질 수 있습니다.

이런 상황에서는 스크롤 위치와 함께 추가적인 정보를 저장해야 합니다. 현재 화면에 보이는 아이템들의 정보를 함께 저장하면, 데이터가 다시 로드되더라도 특정 아이템을 기준으로 스크롤 위치를 복구할 수 있습니다.

// 동적 데이터 환경에서의 스크롤 관리 class DynamicScrollManager { saveScrollState(pageKey) { const scrollY = window.scrollY; const visibleItems = this.getVisibleItemsInfo(); // 스크롤 위치와 보이는 아이템 정보를 함께 저장 sessionStorage.setItem(pageKey, JSON.stringify({ scrollY, visibleItems, })); } async restoreScrollState(pageKey) { const savedData = JSON.parse(sessionStorage.getItem(pageKey) || '{}'); if (!savedData.visibleItems) return; // 데이터 로딩이 완료될 때까지 대기 await this.waitForDataLoad(); // 저장된 아이템을 찾아서 기준점으로 사용 const targetElement = this.findTargetElement(savedData.visibleItems); if (targetElement) { targetElement.scrollIntoView(); // 미세 조정을 위해 저장된 정확한 위치로 스크롤 window.scrollTo(0, savedData.scrollY); } } getVisibleItemsInfo() { // 현재 화면에 보이는 아이템들의 ID와 위치 정보 수집 const items = document.querySelectorAll('[data-item-id]'); return Array.from(items).map(item => ({ id: item.dataset.itemId, offsetTop: item.offsetTop })); } findTargetElement(savedItems) { // 저장된 아이템 중 첫 번째 아이템을 기준점으로 사용 return document.querySelector(`[data-item-id="${savedItems[0].id}"]`); } }

이 방식의 핵심은 절대적인 스크롤 위치보다는 상대적인 기준점을 활용한다는 점입니다. 특정 아이템을 기준으로 위치를 복구하기 때문에, 데이터가 다시 로드되어 페이지 높이가 변하더라도 안정적으로 작동합니다. 중요한점은 데이터로드 이후에 스크롤을 복구해야된다는 점 입니다.

3) 동적인 데이터 상황 - 레이지 로딩

동적 데이터 상황 중에서도 무한 스크롤이나 레이지 로딩을 사용하는 경우가 가장 복잡합니다. 사용자가 스크롤을 내릴 때마다 새로운 데이터를 불러오는데, 페이지를 벗어나거나 새로고침으로 다시 방문할 때는 그 데이터가 없는 상태이기 때문입니다.

"스크롤이 해당 지점에 도달했을때 데이터를 불러온다면 어떻게 스크롤 처음 위치를 잡을 수 있을까?" 이 문제를 해결하기 위해서는 두 가지 전략을 조합해야 합니다. 첫째는 필요한 데이터를 미리 로드하는 것이고, 둘째는 스켈레톤 UI를 통해 레이아웃을 미리 확보하는 것입니다.

// 레이지 로딩 환경에서의 스크롤 복구 class LazyLoadScrollManager { async restoreScrollWithPreload(pageKey) { const savedState = this.getSavedState(pageKey); if (!savedState) return; // 1단계: 스켈레톤으로 공간 확보 this.createSkeletonPlaceholders(savedState.totalHeight); // 2단계: 저장된 지점까지 필요한 데이터를 배치 단위로 미리 로드 await this.preloadRequiredData(savedState.requiredItemCount); // 3단계: 실제 스크롤 위치 복구 window.scrollTo(0, savedState.scrollY); } async preloadRequiredData(itemCount) { const batchSize = 20; for (let i = 0; i < itemCount; i += batchSize) { const batch = await this.loadDataBatch(i, batchSize); this.renderBatch(batch); await this.waitForRender(); // DOM 업데이트 대기 } } }

스켈레톤을 이용한 CLS 줄이기

Cumulative Layout Shift(CLS)를 줄이기 위해 스켈레톤 UI를 활용하는 것이 중요합니다. 스켈레톤은 실제 콘텐츠가 로드되기 전에 레이아웃을 미리 잡아주는 역할을 합니다.

스켈레톤으로 해당 데이터의 height 크기를 미리잡아놓기

스켈레톤의 효과를 극대화하려면 실제 콘텐츠와 비슷한 높이를 갖도록 해야 합니다. 이를 위해 과거 데이터를 기반으로 예상 높이를 계산하는 방법을 사용할 수 있습니다.

// 스켈레톤 높이 관리 class SkeletonHeightManager { constructor() { this.itemHeights = []; // 실제 아이템 높이들을 기록 this.averageHeight = 200; // 초기 평균 높이 } // 높이 평균값 계산을 위해 각 엘리먼트 순회 recordItemHeight(element) { const height = element.offsetHeight; this.itemHeights.push(height); } // 최근 50개 아이템의 평균 높이 계산 getItemAverageHeight(element) { const recentHeights = this.itemHeights.slice(-50); this.averageHeight = recentHeights.reduce((sum, h) => sum + h, 0) / recentHeights.length; } // 스켈레톤 생성 createSkeletonWithEstimatedHeight(count) { const container = document.createElement('div'); for (let i = 0; i < count; i++) { const skeleton = document.createElement('div'); skeleton.className = 'skeleton-item'; skeleton.style.height = `${this.averageHeight}px`; container.appendChild(skeleton); } return container; } }

4) react-query를 사용하는 상황

React Query를 활용하면 데이터 캐싱 기능 덕분에 스크롤 복원을 훨씬 수월하게 구현할 수 있습니다. 이미 캐시된 데이터를 즉시 화면에 표시할 수 있어 복잡한 로딩 상태 관리가 불필요해집니다.

이런 효과를 얻기 위해서는 React Query의 캐싱 메커니즘을 제대로 이해하는 것이 중요합니다. 데이터가 캐시에 저장되어 있으면 별도의 네트워크 요청 없이 UI를 바로 렌더링할 수 있습니다. 이러한 특성은 스크롤 복원 과정에서 끊김 없는, 매끄러운 사용자 경험을 제공합니다.

// React Query 환경에서의 스크롤 복구 function useScrollRestorationWithQuery(queryKey) { const queryClient = useQueryClient(); const saveScrollState = () => { const scrollData = { scrollY: window.scrollY, timestamp: Date.now() }; // React Query 캐시에 스크롤 정보도 함께 저장 queryClient.setQueryData([...queryKey, 'scroll'], scrollData); }; const restoreScrollState = async () => { // 1단계: 캐싱된 데이터 가져옴 const scrollData = queryClient.getQueryData([...queryKey, 'scroll']); const cachedData = queryClient.getQueryData(queryKey); if (scrollData && cachedData) { // 2단계: 캐싱된 데이터를 이용해서 컴포넌트를 화면에 렌더링 await componentsRendering(cachedData); // 3단계: 캐싱된 스크롤값을 이용해서 좌표이동 window.scrollTo(0, scrollData.scrollY); } }; return { saveScrollState, restoreScrollState }; } // 무한 스크롤과 조합한 경우 function useInfiniteScrollRestoration(queryKey) { const infiniteQuery = useInfiniteQuery({ queryKey, queryFn: fetchData, staleTime: 5 * 60 * 1000, // 캐시 시간을 길게 설정 }); const restoreWithInfiniteData = async () => { // 1단계: 저장된 pageCount와 스크롤 위치를 가져옴 const savedScrollData = getSavedScrollData(); if (savedScrollData) { // 2단계: 저장된 페이지 수만큼 데이터 복구 while (infiniteQuery.data.pages.length < savedScrollData.pageCount) { await infiniteQuery.fetchNextPage(); } // 3단계: 모든 데이터 로딩 완료 후 스크롤 복구 window.scrollTo(0, savedScrollData.scrollY); } }; return { ...infiniteQuery, restoreWithInfiniteData }; }

React Query를 사용할 때의 핵심은 데이터와 스크롤 상태를 함께 관리한다는 점입니다. 캐시된 데이터가 있다면 로딩 시간 없이 즉시 스크롤을 복구할 수 있고, 없다면 데이터 로딩과 스크롤 복구를 순차적으로 처리할 수 있습니다.

5) 대량 리스트에서 가상화를 이용한 상황

가상화(Virtualization)를 사용하는 경우에는 특별한 접근 방식이 필요합니다. 가상화된 리스트는 실제로 화면에 보이는 아이템들만 DOM에 렌더링하기 때문에 기존의 스크롤 복원 방법으로는 한계가 있습니다.

먼저 가상화의 동작 원리를 살펴보겠습니다. 수천 개의 아이템이 포함된 리스트라고 해도 실제 DOM에 존재하는 것은 현재 화면에 표시되는 10~20개 정도에 불과합니다. 나머지 아이템은 가상으로 존재하며, 사용자의 스크롤에 따라 동적으로 생성되고 제거되는 방식으로 동작합니다.

그래서 가상화 환경에서 스크롤을 복원하려면 기존과는 다른 접근이 필요합니다. 사용자가 마지막으로 보고 있던 아이템 데이터를 먼저 로드하고, 이후 주변 데이터를 점진적으로 불러오는 방식을 사용해야 합니다. 이렇게 데이터가 준비되면 해당 위치로 스크롤을 이동시켜 자연스러운 복원 경험을 만들 수 있습니다.

// 가상화 환경에서의 스크롤 복구 class VirtualizedScrollManager { saveVirtualizedScrollState(pageKey) { const virtualList = getVirtualListInstance(); // 먼저 로드되는 상황을 고려해서 0부터 시작하는 sequence값을 계산해서 저장 const listSequence = virtualList.getSequence(); const pageNumber = virtualList.getPageNumber(); const pageSize = virtualList.getPageSize(); // 가상화된 환경에서는 보이는 아이템 순서값과 최신 페이징 데이터값을 저장 sessionStorage.setItem(pageKey, JSON.stringify({ listSequence, pageNumber, pageSize, })); } async restoreVirtualizedScroll(pageKey) { const savedState = JSON.parse(sessionStorage.getItem(pageKey) || '{}'); if (!savedState.listSequence) return; // 1단계: 먼저 보이는 아이템 데이터 호출 await this.loadDataRange(savedState.pageNumber, savedState.pageSize); // 2단계: 가상 리스트에 저장된 스크롤 오프셋 적용 virtualList.scrollTo(savedState.listSequence); // 3단계: 보이던 아이템 주변 데이터 로드 await this.preloadAroundVisibleRange( savedState.pageNumber, savedState.pageSize ); } }

가상화 환경에서의 핵심은 필요한 부분만 우선적으로 로드하고, 나머지는 백그라운드에서 점진적으로 로드한다는 점입니다. 이렇게 하면 사용자는 즉시 원하는 위치를 볼 수 있고, 전체 데이터 로딩을 기다릴 필요가 없습니다.

위 코드는 pseudo 코드를 이용해서 간결하게 작성했습니다. 만약 리액트에서 사용한다면 React-Virtualized, Virtuoso 와 같은 라이브러리 사용을 추천합니다.

완벽보단 자연스럽게

지금까지 상황별 스크롤 복구 방법을 살펴봤습니다.

실제 프로젝트에서는 여러 방법을 조합해 사용하는 경우가 많습니다. 예를 들면 React Query로 데이터를 관리하면서 무한 스크롤을 구현하고, 스켈레톤 UI로 사용자 경험을 개선하는 형태가 있죠. 중요한 것은 각 프로젝트의 특성과 사용자의 사용 패턴을 이해하는 것, 그리고 그에 맞는 최적의 방법을 선택하는 것입니다.

스크롤 복구을 완벽하게 하기 보다는, 사용자가 불편함을 느끼지 않을 정도의 적절한 수준을 목표로 하는 것이 현실적인 접근입니다. 여러분의 환경에 적합한 꿀조합은 어떤 방법인가요?

방식	중복 제거	확장성	누락 방지	채택
if-else 분기	X	X	X	-
서비스 클래스 분리	O	X	X	-
팩토리 패턴	O	△	X	-
전략 패턴 + AOP	O	O	O	채택

구분	운영 앱	개발 앱
대상	실제 고객	내부 구성원(QA·개발·기획·디자인·마케팅 등)
목적	검증이 완료된 기능을 스토어를 통해 안정적으로 제공	QA 검증, 개발 및 테스트 수행
서버 환경	운영 서버 고정	운영 / STG / QA 등 서버 전환 가능
특징	운영 키·설정 고정, 스토어 배포 기준에 따른 품질·안정성 검증, 불필요한 로그 제거	디버깅에 도움이 되는 개발자 모드 제공

구분	기존 외부 온콜 솔루션	Olive Connect (신규 서비스)	비고
과금 방식	구독형 고정 비용	사용량 기반 과금	-
월 예상 비용	약 2,000,000원 + α	약 100,000원 미만	약 95% 절감
주요 과금 항목	유저당 라이선스, 플랫폼 사용료	Amazon Connect 발신 비용, Lambda 호출 비용 등	-
발신 안정성	해외 번호 발신 (스팸 차단 위험)	국내 번호 발신 및 서버리스로 안정성 높음	안정성 향상

No.	Main Topic
1	발표 주제는 무엇이 적절하고, 팀 소개 및 우리의 업무는 어디까지 공유할 수 있는가?
2	우리 팀이 타사의 QA팀과 차별화 되는 부분을 어필하기 위해 어떤 것을 강조해야 하는가?
3	제한된 공간과 시간 안에서 진행할 수 있는 QA직무와 관련된 프로그램은 무엇이 있는가?
4	참여자들이 만족하면서 올리브영에 대해 좋은 기억을 간직할만한 경품은 어떤 것인가?
5	커피챗 타임에서 예상되는 질문은 무엇이고, 우리 팀이 추구하는 방향과 일치하는 모범 답변은 무엇인가?

Redis Key	용도
C001-count	최종 쿠폰 발급 제한 수량 제어 (DB 정합성에 사용)
C001-countReq	쿠폰 발급 요청 수량 제어 (경합 상태 방지)

방안	정확성	성능	선택 여부
1️⃣ 수량 선차감	△ (개선됨)	⭐⭐⭐⭐⭐	✅ 채택
2️⃣ Lua 스크립트	⭐⭐⭐⭐⭐	⭐⭐⭐ (21%↓)	❌ 기각
3️⃣ 이중 카운터	⭐⭐⭐⭐⭐	⭐⭐⭐⭐ (8%↓)	✅ 채택

구분	개선 전	개선 후	개선율
발급 성공 응답	10,162건	10,000건	⭐️100% 정확⭐️
미발급 건수	162건	0건	⭐️100% 감소⭐️
미발급률	1.62%	0%	⭐️완전 해소⭐️

도구	특징	비고	가격(월)
Synthesia	글로벌 기업용 AI 아바타 영상 제작, 다국어 지원 강점	자연스러운 진행자형 영상 가능	$0~89
Vyond	캐릭터 기반 애니메이션 연출, 스토리텔링에 유리	다양한 상황 연출 가능	$0~99
Gemma	텍스트 기반 슬라이드 제작 도구로, 콘텐츠 콘셉트 시각화에 용이	빠르고 간단하지만 연출 한계가 있음	$0~25
Vrew	자막/컷 편집 지원, 영상 흐름과 템포 조절 가능, AI 목소리 학습 가능	커스터마이징 자유도 높음	$0~28
AI STUDIOS (DeepBrain AI)	실제 인물형 AI 아바타가 자연스럽게 설명	교육 영상의 강의자 역할 구현에 적합	$0~69
Veo3	챕터 기반 영상 자동 생성, 이미지와 텍스트 기반 스토리 제작 가능	깔끔하고 다양한 스타일 영상 제작 가능	$0~35
Hailuo	슬라이드 기반 교육 콘텐츠 자동 영상화, 자막+음성+BGM 포함	문서-영상 전환에 용이	$0~35
Midjourney	고품질 이미지 생성	영상 썸네일, 배경, 캐릭터 컷 활용에 적합	$0~35
Runway	영상 클립 편집, 음성 변조, 스타일 전환 등 생성형 영상 편집 AI	영상 흐름 보정, 효과 추가에 유용 (후반 작업용)	$0~35
Heygen	실제 인물형 AI 아바타, 다국어 리핑 싱크 우수	글로벌 온보딩/리더 대상 영상에 효과적	$0~29
Hedra	캐릭터 + 배경 + 내레이션을 AI가 자동 생성	캐릭터 기반 설명 영상에 적합, 스크립트 중심 제작에 강점	$0~30
Capcut	직관적 인터페이스의 영상 편집 툴! 템플릿 다양	초보자도 쉽게 클립 편집 가능, SNS 스타일 영상 연출에 유리	$0~14
ChatGPT	스크립트 작성, 슬라이드 구조 설계, 내레이션 대본 자동화, 이미지 생성	다른 툴과 연계해 전체 영상 설계 가능	$0~3

구분	Step 01	Step 02	Step 03	Step 04
제작기간	2주	1주	1주	2일
참여인원	2명	2명	2명	1명
작업 시간 (1인)	6시간	2시간	3시간	2시간
사용 툴	수기	AI STUDIOS	Vrew	AI STUDIOS
최종 산출물	126페이지 PPT	AI 아바타	AI로 목소리 삽입	인사장면 삽입

챕터	내용	핵심 메세지
1. 인시던트와 레벨 선언	인시던트 정의, 선언시점, 초기선언 원칙	1시간 이내 선언, 영향도가 불확실하면 최대 손실 기준으로 선언
2. 인시던트 레벨 정의	Level 0~3 개요 및 선언 기준 요약	각 레벨의 핵심 판단 기준 숙지
3. 온/오프라인 판단 기준	세부 기준 제시 (시간, 손해금액, 건수 등 영향도)	명확한 수치 기준으로 즉시 판단
4. 보고 체계 원칙	초기 보고, 최종 보고, 보고자/피보고자 역할	레벨별 보고 프로세스 준수
5. 재발방지대책	후속관리 절차, 조치기한, 추적 방법	인시던트는 종료가 아닌 개선의 시작

항목	세부 내용	결과
정확성	모든 수치와 기준이 최신 가이드와 일치하는가	✅ 검증 완료
일관성	용어 표기가 통일되어 있는가	✅ 통일 완료
가독성	글자 크기와 적절한가, 아바타가 글자를 가리진 않는가	✅ 조정 완료
음질	음성이 명확하게 들리는가, 잡음이 없는가	✅ 문제없음
타이밍	나레이션과 화면 전환이 자연스러운가	✅ 동기화 완료
효과음	효과음이 과하거나 부족하지 않은가	✅ 적절함
오타/오독	자막 오타, 음성 오류 없는가	✅ 2건 수정
재생	다양한 기기에서 정상 재생되는가	✅ 테스트 완료

빌드타임 통합 방식	런타임 통합 방식(w. 모듈 페더레이션)

항목	Nx	Turborepo
의존성 시각화	지원	미지원
Affected 기능	지원	지원
Plugin 생태계	풍부함 (Next.js, React, Storybook 등)	상대적으로 제한적
초기 학습 난이도	다소 높음	낮음
설정 유연성	높음	보통

문제 영역	상세 설명
디버깅 난이도	DB 내부에서의 함수 호출, 로그성 데이터 부재
인력 의존성	소스를 이해하는 인력이 극소수라, 변경 자체가 리스크
우회 로직 남발	프로시저 수정을 피하기 위해 호출 앞뒤에 로직을 붙여 임시 대응 발생

특징	모놀리식 프론트엔드	마이크로 프론트엔드
코드베이스	단일 거대 코드베이스	여러 개의 작은 코드베이스
개발	모든 팀이 동일 코드베이스 작업	팀별 독립적인 코드베이스 작업
배포	전체 애플리케이션 단위 배포	마이크로 앱 단위 독립 배포 가능
기술 스택	단일 기술 스택 (변경 어려움)	기술 스택 다양성 가능 (점진적 변경 용이)
팀 구조	기능별 팀 또는 거대 단일 팀	기능 중심 자율적 팀
결합도	높음 (변경 영향 범위 큼)	낮음 (변경 영향 범위 제한적)
복잡성	초기에는 낮으나, 규모 증가 시 급증	초기 설정 복잡성 높음, 개별 앱은 단순

항목	Spring Cloud Config Server	AWS Parameter Store
기본 기능	Git 기반 설정파일 외부화, 분산 어플리케이션 구성 관리	Key-Value 설정 저장, 버전관리, IAM 인증
특징	Git, Vault 등 외부 저장소와 연동, 복잡한 구성 가능	AWS Managed, IAM 권한 기반 접근 제어
장점	강력한 설정 파일 구조화 및 프로파일별 관리	서버리스, 쉬운 접근, 고가용성
단점	자체 구성 필요, 운영 오버헤드 발생 가능	Git 버전관리 불가, 설정 계층 표현이 제한적

항목	Classic Mirrored Queue	Quorum Queue	개선율
메모리 사용 효율성	높음 (단순 복제)	중간 (로그 기반)	-15%
동기화 안정성	낮음 (단일 실패점)	높음 (과반수 합의)	+85%
장애 복구 시간	수동 개입 필요	자동 복구 (30초 이내)	+90%
네트워크 분할 대응	취약	강력 (Split-brain 방지)	+100%

항목	Native App	Web App
바코드 스캐너 연동	SDK로 직접 제어, 안정적	연동 가능하지만 제약 존재
사용자 경험	스캔 → 응답 → 처리 플로우 최적화 가능	브라우저 기반으로 인해 UX 튜닝 한계 존재
기기 기능 제어	진동, 알림음, 화면 제어 자유로움	제한적
보안성	OS 권한 기반 제어 가능	HTTPS 기반
오프라인 지원	로컬DB와 sync 처리 가능	제한적 (PWA 일부 지원)
개발 생산성	앱개발 스택 필요	웹 기술 스택으로 가능
유지보수	패키지 배포 등 부담스러운 업데이트 절차	서버 배포를 통해 비교적 용이한 유지보수 가능

구분	기능 조직	목적 조직(스쿼드)
구성 기준	기술/역할 기반	목적/기능 기반
커뮤니케이션	팀 간 협업 필요	팀 내 협업으로 신속함
장점	기술 전문성 강화	빠른 실행, 책임 분산
단점	병목/지연 발생 가능	기술 중복/일관성 문제 가능