기존 ERP 이관

goldnus-erp와 leyvecloud-erp의 바로빌 구현, 기존 고객의 Popbill 문서는 공통 gateway로 이관할 때 중요한 참고자료입니다. 그러나 기존 wrapper 전체를 공통 서비스로 복사하지는 않습니다.

재사용하는 것

• 실제 사용 operation 목록
• SOAP action과 요청·응답 mapping 경험
• 수정세금계산서와 취소 절차 fixture
• 오류 코드와 timeout 사례
• 기간 분할·대량 조회 경험
• provider가 발급한 기존 document ID와 로컬 문서 key의 대응 자료

새로 구현하는 것

• Leysys account와 capability authorization
• canonical request/response schema
• idempotency claim과 operation ledger
• provider routing과 permanent document binding
• unknown reconciliation과 manual review
• 감사 로그, 원문 접근 통제, 보존·파기 정책
• provider-neutral client SDK

기존 helper의 중복과 제품별 인증 경계를 그대로 옮기면 공통 gateway가 아니라 레거시 코드 집합이 됩니다.

이관 순서

1. 각 제품의 직접 호출 operation과 credential 위치를 비밀값 출력 없이 목록화합니다.
2. 로컬 문서 key, provider, provider document ID binding을 추출·검증합니다.
3. 기존 Popbill 문서와 Barobill 문서를 gateway에 발행 없이 import합니다.
4. 신규 문서 cohort routing을 승인합니다.
5. sandbox에서 issue, duplicate, timeout, unknown, reconcile, cancel fixture를 통과합니다.
6. 한 제품을 shadow/read-only 조회로 먼저 연결합니다.
7. 쓰기 parity와 감사 로그를 확인한 뒤 제품 직접 호출을 중단합니다.
8. 마지막으로 제품 배포 환경에서 provider credential과 SDK를 제거합니다.

이관 중 금지

• binding import 전에 새 provider로 기존 문서를 재발행
• timeout을 확정 실패로 간주
• 기존 Popbill 고객을 일괄 Barobill로 바꾸며 진행 중 문서까지 이동
• 실제 발행으로 sandbox fixture를 대체
• 제품별 credential을 공통 client SDK에 넣기

마이그레이션 비용

Greenfield 구조로 가려면 기존 provider wrapper를 capability adapter로 다시 경계 짓고, 직접 호출을 공통 client로 교체하며, 과거 문서 binding을 이관해야 합니다. 이 비용은 존재하지만 제품별 직접 호출을 유지하는 아키텍처 근거는 아닙니다.