Home
기존 회원 관리 플랫폼들은 대형 입시 학원을 타겟으로 설계되어,
중소규모 태권도장에는 불필요하게 복잡한 기능과 높은 진입 장벽이 존재했습니다.
이전 직장에서 이를 타겟팅하여 특화된 서비스를 제공하며 비즈니스적 가치를 확인했으나,
서비스 성장과 함께 늘어난 트래픽 및 데이터를 수용하기에는 기존 레거시 아키텍처의 확장성 저하와 산재된 기술 부채로 아쉬움이 있었습니다.
이에, 현장의 기술 부채 및 페인포인트를 해결하여 신뢰성과 견고함을 갖춘 SaaS 아키텍처를 설계하고 구현하고자 프로젝트를 시작했습니다.
- TenantContext 와 AOP 기반의 스코핑 전략을 통해 테넌트 간 데이터 혼선을 방지하고 보안성을 강화했습니다.
- TSID 를 활용한 식별자 체계와 공유 스키마 전략을 채택하여, 도장 증가에 따른 인프라 확장 비용을 최적화 했습니다.
- 레이어드 아키텍처 기반에서 애그리거트 경계를 설정함으로써 다른 관심사에 대한 직접 참조를 지양하고
기능 수정시 영향 범위를 최소화 했습니다. - 태권도장 운영의 핵심 도메인인 '출결, 수납, 알림, 결제' 도메인을 우선적으로 설계하여 기능의 순수성과 완성도를 높였습니다.
- 별도의 MQ 인프라를 운영하는 대신, Application Event 와 DB Polling 기반의 비동기 큐를 구성하여
인프라 비용과 관리 복잡도를 낮추면서도 신뢰성을 확보했습니다. -
@Scheduled워커가 PENDING 메시지를 배치 선점하여 채널별로 발송 처리하며,
지수 백오프(30s → 120s → 600s → 1800s → 3600s) + Jitter 기반의 재시도 정책과
Stuck 복구 스케줄러를 통해 메시지 유실 시나리오를 방지했습니다.
- 도장 검색 시 검색 쿼리의 비효율을 제거하고 인프라 의존성을 낮추기 위해, Bi-gram 및 초성 추출 기반의 역인덱싱 기술을
직접 구현하여 한글 검색을 최적화 했습니다. - MatchType 가중치(FULLWORD 5.0, ENGLISH 5.0, CHOSUNG 2.0, BIGRAM 1.0)와
IndexField 가중치(NAME 3.0, ADDRESS 1.5, OWNER 1.0)에 IDF 를 결합한 스코어링 시스템으로
관련도 순위를 산출하여, 외부 솔루션 없이 도메인에 특화된 검색을 실현했습니다.
- 청구(Invoice), 수납(Payment), PG 결제(PgPayment), 환불(Refund)을 독립된 도메인으로 분리하여
각 관심사의 라이프사이클을 명확히 관리합니다. - Invoice 가 '얼마를 내야 하는가'를, Payment 가 '얼마를 냈는가'를 담당하며,
PG 결제는 Payment 를 생성하는 하나의 채널로 위치시켜 비즈니스 로직과 결제 인프라 간의 결합도를 낮췄습니다. - PG 결제 승인 시 paymentKey 기반 멱등성 보장, PENDING 선저장(독립 트랜잭션)을 통한 상태 추적,
트랜잭션 롤백 시 보상 취소(@TransactionalEventListener+ ORPHANED 전환),
비관적 락(SELECT FOR UPDATE)을 통한 동시 결제 방지 등 결제 안전성을 설계했습니다. - 토스페이먼츠 PG 연동(결제 링크 → SMS 발송 → 결제 페이지 → 승인)과 서브몰 관리, 부분 환불 등
도장별 결제 운영에 필요한 기능을 지원합니다.
- 서비스 초기에 과도할 수 있는 Redis 등 외부 인프라 대신 Caffeine Cache 를 활용해
권한 검증 및 설정 조회 시 발생하는 DB 부하를 낮췄습니다. - 불필요한 인프라 확장을 지양하고 애플리케이션 레벨의 최적화를 통해 외부 인프라 의존 및 관리 포인트를 최소화 했습니다.
- Github Wiki 와 기술 문서를 통해 시스템 전반의 아키텍처, 도메인 경계, 주요 기술적 전략의 배경을 문서화하여
온보딩 비용 감소화 장기적인 유지보수 가능성을 확보했습니다. - DB 스키마 변경을 코드 변경과 동일한 수준의 형상 관리 대상으로 관리하기 위해 Flyway 기반의 DB 마이그레이션 전략을 도입했습니다.