무신사, Temporal 도입으로 "스케줄 멈춤" 문제 해결!

본문에서는 무신사가 기존 Jenkins 기반 스케줄링 시스템의 한계로 인해 Temporal을 도입한 배경을 설명한다. 기존 시스템은 스케줄 실패 시 알림 부재, 로그 분석의 어려움, 수동 재실행의 번거로움 등의 문제점을 가지고 있었다. 특히, 출고 지시와 같은 중요한 작업의 지연은 배송 지연으로 이어져 운영 리스크(Operational Risk)를 증가시켰다. 이러한 문제들을 해결하기 위해 무신사는 Workflow Engine인 Temporal을 선택했으며, 이는 단순히 기술 스택 변경을 넘어 운영 방식의 혁신을 의미한다.

Temporal은 장기 실행되는 비즈니스 프로세스를 코드로 표현하고, 실패, 재시도, 상태 관리를 플랫폼 레벨에서 보장하는 Workflow Engine이다. 무신사는 Temporal을 통해 스케줄 기반 실행, 전체 Workflow 흐름에 대한 가시성 확보, 자동 재시도 및 복구, 이벤트 기반 트리거 등의 기능을 활용했다. 특히, 자동 재시도 기능(Automatic Retry)은 일시적인 네트워크 오류로 인한 실패를 자동으로 처리하여 운영 부담을 줄였으며, Temporal UI를 통해 실행 이력을 시각적으로 확인할 수 있어 장애 대응 시간(Incident Response Time) 단축에 기여했다.

Temporal을 도입하면서 가장 중요했던 결정 중 하나는 Workflow와 Activity의 경계를 설정하는 것이었다. 무신사는 Workflow를 비즈니스 정책에 따른 분기와 흐름 제어를 담당하는 영역으로, Activity를 멱등성이 보장되는 단위 작업 및 외부 시스템 호출을 담당하는 영역으로 정의했다. 예를 들어, “중복 주문이면 스킵한다”는 비즈니스 정책은 Workflow에서, “DB에서 중복 여부를 조회한다”는 실행 세부 사항은 Activity에서 처리하도록 설계했다. 이러한 구분은 향후 출고 파이프라인 전체를 Workflow로 확장할 때 일관성 있는 설계(Consistent Design)를 유지하는 데 중요한 역할을 한다.

무신사는 29CM 주문 수집 자동화를 위해 Temporal을 활용하면서 개인정보 보호를 위한 설계를 적용했다. 29CM API에서 받은 Payload는 MOMS DB에 저장하고, Temporal Workflow에는 Payload ID만 전달하는 방식을 채택했다. Activity는 Payload ID를 사용하여 DB에서 정보를 조회하고 처리한다. 이와 같은 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 개인정보는 무신사 인프라 내에 안전하게 보관되고, Temporal에는 최소한의 정보만 노출되도록 설계했다. 이는 GDPR 규제 준수(GDPR Compliance)를 위한 중요한 조치이며, 보안과 효율성을 동시에 확보하는 전략이다.

무신사는 현재 Spring Batch와 Temporal을 함께 사용하며, 점진적인 전환을 진행하고 있다. “장기 실행, 재시도, 이력 추적이 중요한 작업”은 Temporal에, “단순 반복 처리”는 Spring Batch에 적합하다는 기준을 세우고, 각 시스템의 장점을 활용하고 있다. 이러한 하이브리드 아키텍처(Hybrid Architecture)는 모든 파이프라인을 한 번에 전환하는 데 따른 위험을 줄이고, 각 기술의 장단점을 비교 분석할 수 있는 기회를 제공한다. 향후 출고 파이프라인 전체를 Temporal로 전환하여 병렬 처리 구조(Parallel Processing Structure)를 통해 처리 속도를 90% 이상 단축하는 것을 목표로 하고 있다.