구매 내역과 보상을 가진 두 계정을 하나로 합치려 합니다. 무엇을 합치고 무엇을 보존해야 하며, 중간 실패는 어떻게 처리하나요?

먼저 두 계정을 모두 소유한다는 증명과, 병합 후 어떤 데이터가 어디에 남아야 하는지를 정하겠습니다. 계정 ID 하나를 다른 것으로 치환하는 작업처럼 보이지만 결제 권리, 제재, 로그인 수단, 게임 진행처럼 서로 다른 규칙이 얽힐 수 있습니다. 모든 데이터를 단순 합산해서는 안 됩니다.

예를 들어 두 계정이 같은 일회성 쿠폰을 이미 썼다면 사용 이력을 단순 합쳐도 재사용 가능 횟수가 늘어나서는 안 됩니다. 반면 각각 구매한 서로 다른 상품의 권리는 보존해야 합니다. 이렇게 병합 전후에 반드시 지켜야 하는 규칙을 불변식이라고 합니다. 항목별로 결과를 먼저 정해야 복구 중에도 무엇이 맞는 상태인지 알 수 있습니다.

재화는 합칠 수 있어도 이미 사용한 쿠폰이나 유일한 구매 권리는 중복될 수 있습니다. 제재 계정을 정상 계정에 합쳐 제한을 피해서도 안 됩니다. 저는 데이터별로 합산·한쪽 선택·금지·수동 확인 규칙을 명시하고, 되돌릴 수 없는 단계 전에 사용자 확인을 받는 흐름을 설계하겠습니다. 병합 중 두 계정에 새 쓰기가 들어오는지도 통제해야 합니다.

여러 서비스가 참여하면 전체를 하나의 DB 롤백으로 묶기 어려우므로 진행 상태와 재시도 키를 내구성 있게 저장하겠습니다. 같은 병합 요청이 다시 와도 중복 지급되지 않게 하고, 완료 여부를 계정별로 조회할 수 있어야 합니다. 완료 뒤 이전 세션과 토큰이 어떤 권한으로 동작하는지도 정하겠습니다. 검증은 성공 결과뿐 아니라 단계 중단·동시 로그인·늦은 이벤트에서 권리와 제한이 사라지거나 늘어나지 않는지 확인하는 방식으로 하겠습니다.

병합 결과를 항목별로 확정합니다

포인트는 단순한 숫자 합계가 아니라 원장, 만료 시각, 차감 이력을 함께 옮겨야 합니다. 서로 다른 상품 구매 권리는 합집합으로 보존할 수 있지만 동일 주문·환불·분쟁 중인 권리는 주문 ID와 현재 상태를 기준으로 중복 제거합니다. 같은 쿠폰을 두 계정에서 이미 썼다면 사용 이력의 합집합을 대표 계정에 남기고 추가 사용을 허용하지 않습니다. 제재는 정상 계정으로 흡수해 사라지지 않게 별도 정책으로 합치며, 인증 수단은 이메일이 같다는 이유가 아니라 각 공급자의 소유권 증명으로 연결합니다.

동시 쓰기와 부분 완료를 다룹니다

병합을 시작할 때 두 계정에 merging 상태와 현재 버전을 기록하고, 상태가 바뀌면 기존 작업을 중단합니다. 결제·보상 이벤트가 그 사이 도착하면 대표 계정으로 귀속시키거나 보류 큐에 두고, 병합 ID와 이벤트 ID를 조건으로 한 번만 적용합니다. 여러 서비스가 참여하면 계정·구매·보상 단계의 완료 여부를 별도 저장해 실패 지점을 재개합니다. 보상이 이미 지급된 뒤 다음 단계가 실패했다면 단순 재시작이 아니라 보상 취소, 대사, 수동 확인 중 가능한 경로를 선택해야 합니다. 병합 완료 후에는 원본 세션·토큰을 폐기하고, 늦은 이벤트가 원본 ID를 사용해도 대표 ID로 정규화되는지 테스트하겠습니다. 성공률보다 권리 합계, 사용 이력, 제재, 보류 건수가 병합 전후 불변식을 만족하는지가 기준입니다.

구체적인 경계 사례

동시 병합도 고려합니다. A를 B로 합치는 요청과 B를 C로 합치는 요청이 겹치면 대표 계정 연결이 중간 상태를 가리키거나 순환할 수 있습니다. 계정 ID의 고정 순서로 잠금을 획득하거나 두 계정 버전을 조건으로 병합 예약을 원자적으로 생성하고, 이미 진행 중인 병합은 새로 시작하지 않겠습니다. 대표 계정 조회는 순환을 거절하고 최종 대상과 병합 세대를 반환해야 합니다.

완료된 단계를 재실행할 때 원본 잔액을 다시 더하는 대신 고정된 이전 원장 항목 ID의 처리 여부를 확인합니다. 병합 취소는 아직 이전하지 않은 단계의 예약 해제와 이미 이전한 권리의 역이전을 구분합니다. 후자는 새 거래가 발생했다면 원래 값으로 덮어쓸 수 없으므로 별도의 조정 원장을 남깁니다.