DevLog

엔지니어링 블로그를 한 곳에서 탐색하고, 최근 발행 흐름을 빠르게 파악할 수 있는 서비스 입니다.

Quick Links

  • Latest Feed
  • Engineering Directory

Support

  • 소개
  • 개인정보처리방침

Contribute

  • 원하는 블로그 추가 (준비 중)
  • Feedback

© 2026 DevLog Inc. All rights reserved.

본 사이트는 공개 RSS 피드를 통해 콘텐츠를 수집하며, 모든 콘텐츠의 저작권은 원저작자에게 있습니다.

Back to Feed
Read Original

Contents

Continue Reading

  • More from 올리브영
  • Related reads#Spring
#Backend

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

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

Summary

레거시 알림톡의 대변신! Spring 트랜잭션 동기화로 1,600만 고객의 신뢰를 지키는 법

비즈니스 로직과 알림 발송의 '완벽한 결별'을 통해 데이터 정합성과 개발 생산성을 동시에 잡은 기술 전환기

올리브영의 급성장하는 비즈니스 요구사항을 감당하기 위해, 파편화된 레거시 알림 시스템을 Kafka 기반 MSA 환경으로 전환한 과정을 다룹니다. 신입 엔지니어의 시선에서 겪은 기술적 제약 사항과 이를 해결하기 위한 트랜잭션 동기화 기법, 그리고 책임 분리를 통한 아키텍처 개선 과정을 상세히 공유합니다. 단순한 기능 구현을 넘어 시스템 설계의 본질과 안정적인 데이터 흐름을 고민하는 개발자들에게 실질적인 인사이트를 제공합니다.

  • 01복잡한 레거시 의존성 문제를 극복하기 위한 TransactionSynchronizationManager 활용 전략
  • 02Kafka 메시징을 통한 레거시와 모던 시스템 간의 안정적인 비동기 통신 구조 설계
  • 03데이터 일관성 확보를 위해 배송 유형별 공통 쿼리 및 통합 조회 기준 수립
  • 04비즈니스 로직 성공 후 발송을 보장하는 커밋 이후(After Commit) 콜백 메커니즘 구현
  • 0540여 종의 알림톡을 효율적으로 관리하기 위한 역할 중심의 서비스 분리

+RECOMMENDATION

레거시 시스템을 점진적으로 MSA로 전환하고 있거나, 비즈니스 로직과 외부 연동 로직 사이의 데이터 정합성 문제로 고민하는 백엔드 엔지니어에게 적극 추천합니다. 특히 Spring 프레임워크 버전 제약으로 인해 최신 기능을 사용하기 어려운 환경에서 트랜잭션 커밋 시점을 제어하는 실용적인 대안을 제시합니다.

The Problem

기존 알림톡 시스템은 로직이 비즈니스 코드에 산재해 있어 수정이 어렵고, 데이터 조회 기준이 서비스마다 달라 일관성이 부족했습니다. 특히 비즈니스 로직과 발송 처리가 강하게 결합되어 있어, 발송 후 로직 오류 발생 시 데이터 상태와 안내 내용이 불일치하는 안정성 문제가 존재했습니다.

The Solution

Spring의 TransactionSynchronizationManager를 활용하여 비즈니스 트랜잭션 커밋 이후에만 Kafka 메시지를 발행하도록 콜백 구조를 구현했습니다. 이를 통해 레거시 시스템은 발송 시점만 결정하고, 모던 아키텍처 기반의 컨슈머가 메시지를 소비하여 배송 유형별 공통 쿼리 조회 및 발송 처리를 전담하도록 역할을 분리했습니다.

The Result

발송 로직이 모던 시스템으로 일원화되면서 새로운 알림톡 추가 시 템플릿과 시점만 등록하면 되는 간편한 구조가 완성되었습니다. 또한 데이터 상태와 알림 발송 간의 정합성이 확보되었으며, 산재해 있던 데이터 조회 기준을 통합하여 시스템의 일관성과 유지보수성이 크게 향상되었습니다.

Trade-off

초기에는 @TransactionalEventListener를 도입하려 했으나 레거시 환경의 프레임워크 버전 충돌 및 의존성 문제로 인해 TransactionSynchronizationManager를 활용한 차선책을 선택했습니다. 본문에 구체적인 한계는 없으나, 현재 구조는 메시지 발행 실패 시 로그 기반 재처리에 의존하므로 트랜잭션 아웃박스 패턴(Outbox Pattern) 대비 발행 보장 측면에서 상대적으로 완결성이 낮을 수 있습니다.

03

Key Concepts

Concept · 01

TransactionSynchronizationManager

Spring에서 트랜잭션의 생명주기에 맞춰 특정 작업을 동기화하거나 등록된 리소스를 관리하는 중앙 관리 클래스입니다.

  • 비즈니스 로직이 담긴 DB 트랜잭션이 성공적으로 커밋된 이후에만 Kafka 메시지를 발행하도록 콜백을 등록하는 데 사용되었습니다.
  • @TransactionalEventListener를 사용할 수 없는 하위 버전의 레거시 환경에서 안정적인 실행 시점을 보장하는 대안으로 활용되었습니다.
Concept · 02

Kafka Message-driven Architecture

메시지 브로커인 Kafka를 중심으로 시스템 간 이벤트를 주고받아 결합도를 낮추는 아키텍처 스타일입니다.

  • 레거시 시스템은 발송 트리거(Publisher) 역할만 수행하고, 실제 발송 처리는 컨슈머(Consumer)가 담당하도록 분리했습니다.
  • 메시지에는 주문번호와 유형 등 최소한의 정보만 담아 시스템 간 데이터 전송 부하를 최소화했습니다.
Concept · 03

Role Separation (SOC)

프로그램의 각 부분이 서로 겹치지 않는 별개의 관심사를 가지도록 기능을 분리하는 설계 원칙입니다.

  • 레거시에서는 '알림 전송 시점 결정'을, 컨슈머 서비스에서는 '데이터 구성 및 발송 API 호출'을 전담하게 했습니다.
  • 기능 분리를 통해 새로운 알림 유형 추가 시 기존 비즈니스 로직을 건드리지 않고도 확장이 가능한 구조를 구축했습니다.
Continue reading · same source

올리브영More from 올리브영

View all posts from 올리브영
  • 옴니채널 재고 정합성 한계에 대응하는 인벤토리 데이터 파이프라인 구축기

    KafkaSpring BatchEDA
    1주 전
  • 에러로그 하나에 깨던 새벽에서 벗어나기까지 — 상품 모니터링 진화기

    DatadogCDCAutomation
    1주 전
  • 150개국 K-뷰티 플랫폼 뒤의 팀, 올리브영 글로벌엔지니어링센터의 첫 번째 워크숍 이야기

    GenAIVibe CodingVertex AI
    2개월 전
  • 45분 배치에서 준실시간으로! 다수 도메인 데이터를 Kafka로 통합한 전환기

    KafkaEvent-Driven ArchitectureRedis Pub/Sub
    2개월 전
  • AI와 협업하는 새로운 개발 프로세스, 올리브영은 어떻게 시작했을까 (feat. AI-DLC)

    AI-DLCSDLCAWS
    2개월 전

Related reads#Spring

Explore #Spring
무신사·Java Flight Recorder

의심했던 범인은 알리바이가 있었다.

#Spring4일 전
올리브영·Kafka

옴니채널 재고 정합성 한계에 대응하는 인벤토리 데이터 파이프라인 구축기

#Spring1주 전
여기어때·Spring Data Redis

Spring Data Redis: Repository vs RedisTemplate — 실전 성능 비교

#Spring1주 전
Flex·Spring Boot

[의존성의 방향을 따라 1/5] 버전업이 고통인 이유

#Spring1개월 전
Flex·Hexagonal Architecture

[AI가 읽을 수 있는 코드베이스 3/5] Standalone App: 도메인 슬라이스 독립 실행

#Spring1개월 전

Source

올리브영
올리브영
Engineering Blog

Published · February 23, 2026

Topics

SpringKafkaMSATransactionLegacyMessage QueueArchitecture