아키텍처
가맹점은 변함없이, 결제창 시스템 전면 재작성하기
두줄요약
레거시 결제창을 결제 도메인 중심 구조로 재설계한 사례를 다뤘습니다. 기능 추상화와 단계적 전환, 자동 롤백으로 가맹점 영향 없이 개편했습니다.
문제 상황
- 20년간 유지된 레거시 결제창의 절차지향적 구조와 2,500줄 분기문으로 인한 변경 어려움
- Struts, WebLogic 기반의 구시대 스택과 FE-BE 강결합으로 기능 추가 시 광범위한 수정 필요
- 수백 개의 평면 파라미터와 전역변수처럼 쓰이는 DTO로 인한 개발 복잡도와 추적 어려움
해결 방법
- SessionCreationRequest와 Feature 추상화로 결제 요청 파라미터를 값과 기능으로 분리
- OpenAPIConverter, LegacyConverter를 분리해 연동 방식별 변환 책임을 독립화
- FE-BE를 3-Step 결제와 Bridge 인터페이스로 재구성해 관심사 분리
성능/운영 포인트
- 가맹점별, 기능별 Canary 배포와 자동 롤백으로 서비스 연속성 확보
- PREPARE 대비 CONFIRM 비율 모니터링으로 이상 징후 감지 후 즉시 레거시로 원복
- ENTRY 단계 Simple Request와 Multi-Layer Cache로 첫 화면 응답성과 대규모 트래픽 대응 개선
적용해볼 점
- 레거시 인터페이스를 코어 비즈니스 로직과 분리하는 변환 계층 설계
- 기능 단위 추상화로 외부 파라미터 변화에 대한 영향 범위 축소
- 배포·모니터링·캐시를 함께 설계해 점진적 전환과 운영 안정성 확보