은행 연동 코드를 어댑터 패턴으로 신규 프로젝트에 이전
목차
은행 핸들러 마이그레이션 시작
기존 이커머스 플랫폼에 흩어져 있던 은행 연동 코드를 신규 프로젝트로 옮김. 단순 복붙이 아니라 의존성부터 정리해야 했음.
문제는 기존 코드가 캐시 유틸을 직접 import 하고 있었고, 신규 쪽엔 그 유틸이 없었음. 같은 이름으로 새로 깎느냐, 인터페이스만 맞추느냐 사이에서 고민하다가 신규에 얇게 다시 만드는 쪽으로 감. 기존 시그니처에 맞춰서 메서드만 동일하게.
API 호환 레이어
신규 프로젝트가 기존 API 시그니처를 그대로 받게 만드는 게 핵심. 호출부 100군데 넘게 고치는 건 비현실적이라 어댑터 한 겹 둠.
- 기존 메서드 시그니처는 그대로 유지
- 내부에서 신규 송금 큐 배치로 위임
- 응답 객체는 신규 포맷이지만 외부 노출 필드만 호환되게
이렇게 가르니까 호출하는 쪽 코드 수정 0줄로 동작. 어댑터에서 한 번 변환 비용은 있지만 마이그레이션 단계에선 충분히 감수할 만함.
송금 큐 배치 이전
이게 제일 골치 아팠음. 기존엔 큐를 읽어서 동기 처리했는데, 신규 쪽은 비동기 처리 전제로 짜여 있어서 트랜잭션 경계가 달랐음.
| 항목 | 기존 | 신규 |
|---|---|---|
| 처리 방식 | 동기 | 비동기 |
| 트랜잭션 | 단건 | 배치 단위 |
| 실패 재시도 | 즉시 재호출 | 큐 재투입 |
특히 재시도 정책이 달라서 기존 동작을 보존하려고 어댑터에서 동기처럼 보이게 wrap 함. 내부적으론 큐 투입 후 짧게 폴링하면서 결과 받아오는 식. 성능은 살짝 손해 보지만 호출부 입장에선 차이 없음.
DDL 업데이트와 정리
테이블 스키마 변경분을 DDL 문서에 반영. 운영DB 반영은 사용자 승인 후로 미뤘고, 개발DB와 파트너 DB 두 곳에만 먼저 적용함.
- DDL 변경은 무조건 문서랑 코드 동시 반영 — 한쪽만 바꾸면 다음 검수에서 무조건 충돌
- .gitignore 에 로컬 빌드 산출물과 IDE 설정 추가
- 캐시 유틸은 신규 쪽에 얇게 새로 깎고, 기존 키 네이밍 규칙은 그대로 승계
회고
마이그레이션은 한 번에 다 옮기려 들면 망함. 어댑터 한 겹 두고 호출부는 그대로, 내부만 갈아끼우는 식이 안전했음. 큐 배치처럼 트랜잭션 경계가 다른 부분은 동작 보존을 1순위, 성능은 나중에 손봄.
다음 단계는 어댑터 제거하고 호출부를 신규 시그니처로 직접 옮기는 작업.
다음
댓글 0
첫 댓글 달아줘.