[kt cloud TECH UP] 단발성 광클 전쟁에서 러닝 맞춤형 UX와 MSA 전환으로

2026. 1. 25.
Spring BootMSAUXkt cloud TECH UPMulti-module

본 포스팅은 치열하게 진행 중인 kt cloud TECH UP 실무 통합 프로젝트의 일환으로 구축된 마라톤 티켓팅 플랫폼에 대한 첫 번째 기록입니다. 앞으로 이 프로젝트 과정에서 겪은 기술적 고민과 회고를 시간 흐름에 따라 순차적으로 공유할 예정입니다.

1. 문제 발굴: 왜 "마라톤 티켓팅" 인가?

마라톤 시장은 구조적으로 무섭게 성장하고 있습니다. 2020년 19개에 불과했던 대회가 2024년 254개로 10배 이상 폭증했고, 백만 명 이상의 참가자가 몰리고 있습니다. 하지만 시스템은 그 폭발적인 수요를 따라가지 못하고 있었습니다.

  • 대규모 트래픽 처리 실패: 4만 명이 몰리는 서울마라톤 등 대형 이벤트마다 서버 다운이 반복되었습니다.
  • 러닝 맥락을 무시한 범용 플랫폼: 인터파크, YES24 등 기존 플랫폼은 "누가 빨리 클릭하느냐"만 중요할 뿐, 참가자의 러닝 수준(풀코스, 10K, 페이스 무그룹)을 고려한 배정이라는 '마라톤의 특성'을 전혀 반영하지 못하고 있었습니다.
  • 공정성 붕괴: AI 매크로 봇이나 리셀 업자들이 수백 장을 싹쓸이하는 등 브랜드 신뢰도를 직격하는 문제들도 심각했습니다.

결론적으로 마라톤 티켓팅은 단순한 '단발성 이벤트 판매'가 아니라, 15,000명 동시 접속 환경에서 AI 매크로를 막으면서 각 러너의 특성에 맞는 좌석을 정밀하게 배정해야 하는 복합 시스템입니다. 우리는 이 시장의 고질적인 문제를 근본부터 해결해보기로 했습니다.

2. 러너를 위한 진짜 티켓팅, UX의 재설계

기존의 "접속 -> 무한 대기 -> 들어간 후 허겁지겁 빈자리 선택 -> 미스매치 시 대거 환불" 로 이어지는 일반 페스티벌 방식의 아키텍처를 과감히 버렸습니다.

우리는 사용자가 접속 전에 [자신에게 맞는 코스(5K/10K/하프)와 페이스(2분대~6분대)] 를 명확히 선택하고, 오직 해당 스펙의 "대기열"로 진입하는 UX/UI를 설계했습니다. 이를 통해 단순히 '빨리 클릭한 사람'이 아니라 '나에게 맞는 코스를 명확히 인지한 사람'이 티켓팅을 완주할 수 있게 되었으며, 미스매치로 인한 운영/환불 리스크를 확연히 줄였습니다.

3. 백엔드 생존 전략: Monolithic에서 Multi-Module로

UX 개편 이후 백엔드 팀의 고민은 "이 대규모 트래픽과 도메인의 복잡성을 어떻게 감당할 것인가" 였습니다. 기존의 단일(Monolithic) 저장소에서는 main 서비스 안에 사용자, 인증(Auth), 비즈니스 로직(티켓팅, 결제)이 거미줄처럼 얽혀 있었습니다. 우리는 서서히 다가오는 MSA 전환의 첫 단추로 멀티 모듈 구조로의 리팩토링을 감행했습니다.

3.1. common과 auth의 분리

  • common 모듈: 보안(JwtTokenProvider 등), 유틸리티 등 모든 모듈에서 사용하는 순수 공통 로직을 추출했습니다.
  • main 모듈: 이제 비즈니스 로직 자체의 응집도를 높여 트래픽 집중에 대응할 준비를 마쳤습니다.
  • auth 모듈: 인증에 관련된 컨트롤러와 서비스 로직을 독립시켰습니다. 가장 큰 변화는 main 모듈에서 auth 의존성을 완전히 제거하여 도메인 간의 결합도를 끊어낸 것입니다.

3.2. 첫 번째 트레이드오프: Auth와 User를 분리할 것인가?

가장 큰 논쟁은 인증(Auth) 모듈과 사용자(User) 모듈을 완벽하게 분리할 것인가 하는 문제였습니다.

  • 분리할 경우: Auth 모듈이 어떤 식으로든 User 모듈에 의존하게 되어 잘못 관리하면 순환 참조(Circular Dependency)의 늪에 빠질 수 있습니다.
  • 우리의 선택 (통합): 로그인, 세션 검증, JWT 발급 등 인증 행위는 본질적으로 사용자 정보를 지속적으로 조회해야 작동합니다. 따라서 현재 규모에서는 Auth 내부에 User 도메인을 강력하게 결합한 채로 통합 유지하는 것이, 복잡성을 줄이고 관리 포인트를 일원화하는 실용적인 선택이라고 판단했습니다.

이렇게 백엔드의 뼈대를 분리하고 나니 각 도메인을 지켜내는 캡슐화와 의존성 경계가 매우 중요해졌습니다. 그리고 이는 빌드(Gradle) 단에서의 깊은 토론으로 이어졌습니다.

➡️ (다음 포스팅에서 계속)