계정을 통합할 때 과거 식별자와 현재 세션을 어떻게 나눌까

계정 A를 대표 계정 B로 통합했다고 하자. DB의 거래 관계는 B를 가리키지만 앱은 A의 토큰, WebView는 A의 쿠키를 가지고 있다. 다음 요청에서 과거 ID를 B로 치환하면 통합이 끝난 것일까.

과거 이력을 찾아주는 편의와 현재 세션에 B의 권한을 주는 판단은 다르다. 계정 통합을 식별자 변경으로만 다루면 이 경계가 숨는다. 이 글은 소유 증명 이후에도 나누어야 할 데이터·세션·소속 정책을 설명한다.

별칭은 이력 연결에 사용한다

이메일이나 이름이 같다는 이유만으로 계정을 합치지 않는다. 두 계정의 소유 증명을 업무·보안 정책에 맞게 확인한 뒤 대표 계정과 이전 식별자를 연결한다.

account_alias
  previous_account_id
  canonical_account_id
  merge_operation_id
  merged_at

이 모델은 과거 로그·거래·외부 식별자가 어느 통합 작업으로 이동했는지 설명한다. 별칭을 발견했다는 이유로 모든 오래된 인증을 대표 계정 권한으로 바꾸는 기능은 아니다. 이력 조회와 세션 재인증에 각각의 정책을 둔다.

토큰 검증과 현재 계정 상태를 따로 본다

서명·만료가 유효한 토큰에도 통합 전 subject가 남을 수 있다. Spring Security JWT 문서는 서명과 시간·발급자 검증 등을 설명하지만, 애플리케이션 계정 병합 정책까지 자동 반영하지는 않는다.

기존 세션 유지, 대표 계정 토큰으로 교환, 재인증 가운데 필요한 정책을 고른다. 민감한 거래에는 즉시 폐기가 필요할 수 있다. 계정의 session_version을 토큰과 비교하는 설계는 이전 세션을 거절할 수 있지만 서버 조회와 캐시 갱신 비용을 추가한다. 짧은 만료의 지연을 허용할지와 비교한다.

인증 이후에도 객체 접근 범위를 확인한다. OWASP 객체 수준 인가의 기준처럼 로그인 성공과 대상 거래를 볼 권한을 같은 검사로 취급하지 않는다.

앱과 WebView의 전환 완료를 각각 확인한다

네이티브 보안 저장소의 토큰 교체와 WebView 쿠키 갱신이 별도 작업인 구성이라면 한쪽만 성공할 수 있다. 서버가 토큰을 발급했다는 사실과 모든 클라이언트가 새 주체로 요청한다는 사실을 구분한다.

교환 도중 앱 종료, WebView 갱신 실패, 재시도에 대비해 전환 상태를 두거나 재인증으로 돌아갈 경로를 정한다. 인증 헤더와 쿠키가 함께 왔을 때 서버가 어떤 값을 사용하는지도 확인한다. 진단에는 토큰 원문 대신 제한된 세션 식별자와 갱신 버전을 사용한다.

소속과 원장은 합집합으로 옮기지 않는다

두 계정에 같은 소속이 있어도 출처·만료·계약 상태가 다를 수 있다. 합치면서 만료 혜택을 되살리거나 유효한 인증을 덮지 않도록 이력 보존과 대표 소속 선택을 나눈다.

원장도 금액 합산 전에 동일 거래가 양쪽에서 참조됐는지 확인한다. 이전 소유자와 거래 식별자는 감사·복구에 필요하다. 통합을 신규 가입이나 새 포인트 지급으로 처리하는 경로가 있는지도 점검한다.

그림에서 별칭은 이력 검증으로 이어지고 세션 전환은 따로 놓인다. 같은 사람의 데이터라는 사실이 모든 세션의 같은 권한을 뜻하지 않기 때문이다.

확인은 API 하나가 아니라 통합 전후 웹·앱의 주체, 포인트, 소속, 예약, 과거 거래를 묶어 수행한다. 동일 통합 재시도와 만료 토큰, 두 계정의 동시 요청도 포함한다. 다음에는 어떤 이전 데이터가 보존돼야 하는지와 어떤 이전 세션이 거절돼야 하는지를 각각 기대 결과로 적어 통합 완료를 판단한다.