UUID Soft FK만으로는 부족했다: 분리된 회원 데이터의 조회 경계
중앙 회원 서버와 개별 서비스의 데이터베이스를 분리하면서, 서비스에는 중앙 회원의 UUID를 저장해 논리적으로 연결했습니다. 이 선택으로 회원 원본과 서비스 도메인 데이터의 소유권은 나눌 수 있었지만, 운영 과정에서 UUID만으로는 해결되지 않는 조회 문제가 드러났습니다.
이 글은 중앙 회원 서버의 전체 인증 흐름을 반복하지 않습니다. 물리적으로 분리된 데이터베이스에서 UUID Soft FK를 사용한 뒤, 관리자와 개발자가 회원을 조회하고 추적할 경계를 어떻게 보완했는지에 집중합니다.
UUID로 데이터 소유권을 분리했다
ID·비밀번호·UUID의 원본은 중앙 회원 서버가 관리하고, 서비스는 주문이나 업무 정보처럼 자신의 도메인에 필요한 회원 데이터만 보유했습니다. 물리적으로 다른 데이터베이스 사이에 Foreign Key를 만들 수 없었기 때문에, 서비스는 중앙 회원의 UUID를 자신의 데이터에 저장해 Soft FK로 사용했습니다.
이 구조의 장점은 분명했습니다. 서비스가 중앙 회원 DB를 직접 공유하지 않아도 회원과 도메인 데이터를 연결할 수 있었고, 인증 원본과 서비스 데이터의 책임도 섞이지 않았습니다. 다만 시스템이 관계를 찾을 수 있다는 사실과 운영자가 그 관계를 이해할 수 있다는 사실은 같지 않았습니다.
시스템 식별자와 운영 식별자는 달랐다
UUID는 시스템이 충돌 없이 관계를 연결하기에는 적합했지만 사람이 보고 회원을 식별하기는 어려웠습니다. 관리자 목록에서 회원을 확인하거나 장애 로그와 서비스 DB를 대조할 때, UUID만 보고 어떤 로그인 계정인지 바로 추적할 수 없었습니다. 개발자가 데이터베이스만 살펴보는 상황에서도 같은 문제가 생겼습니다.
처음에는 중앙 회원 서버를 다시 조회하면 된다고 생각할 수 있습니다. 그러나 목록의 각 행이나 로그를 확인할 때마다 개별 조회를 반복하면 운영 화면과 중앙 API의 결합이 커지고 요청 수도 늘어납니다. 반대로 로그인 ID를 서비스의 새 원본처럼 다루면 중앙 회원 데이터와 불일치할 수 있습니다.
로그인 ID를 운영 읽기 모델로 사용했다
첫 운영 서비스에서는 로그인 응답으로 받은 UUID와 로그인 ID, 토큰 정보를 로컬 user_tokens 테이블에 함께 저장했습니다. UUID는 서비스 도메인 데이터와 중앙 회원을 연결하는 시스템 식별자로 유지하고, 로그인 ID는 관리자 화면과 로그에서 사람을 찾기 위한 운영 읽기 모델로 사용했습니다.
여러 회원을 관리자 목록에 표시할 때는 중앙 회원 서버에 UUID 배열을 보내 로그인 정보를 한 번에 가져오는 Batch API도 추가했습니다. 서비스 DB의 읽기 모델만으로 충분한 화면은 로컬 값을 사용하고, 중앙 원본의 최신 정보가 필요한 목록은 Batch API로 보완했습니다.
로그인 ID처럼 변경될 수 있는 값을 복제한다면 동기화 경계가 필요합니다. 이 프로젝트에서는 회원 조회·변경 API를 후속으로 추가했지만, 모든 변경 상황에서 로컬 읽기 모델의 즉시 일관성을 검증한 것은 아닙니다. 따라서 로그인 ID 복제를 완성된 동기화 체계로 주장하지 않습니다.
UUID Soft FK와 읽기 모델을 함께 설계해야 한다
초기
중앙 회원 DB(ID·비밀번호·UUID)
│ UUID Soft FK
▼
서비스 DB(UUID·도메인 데이터)
└─ 관리자·개발자가 UUID만으로 회원을 추적하기 어려움
보완 이후
중앙 회원 DB(ID·비밀번호·UUID)
├─ UUID Soft FK ──> 서비스 도메인 데이터
└─ UUID Batch API ─> 관리자 목록
▲
서비스 user_tokens(UUID·로그인 ID) ─ 운영 읽기 모델
초기에는 중앙 회원 DB의 UUID만 서비스 데이터와 연결했습니다. 이후에는 서비스의 user_tokens에 조회용 로그인 ID를 함께 두고, 여러 UUID의 중앙 정보를 한 번에 조회하는 Batch API를 추가했습니다. 원본의 소유권은 중앙에 유지하면서도 운영 조회에 필요한 경계를 별도로 만든 변화입니다.
적용 기준
물리적으로 분리된 서비스가 중앙 회원을 참조한다면 식별자 선택만으로 설계를 끝내지 않습니다. 시스템이 관계를 연결하는 키, 운영자가 사람을 식별하는 읽기 모델, 원본의 최신 값이 필요한 조회 경로를 각각 구분해야 합니다.
복제 값이 자주 바뀌거나 즉시 일관성이 중요하다면 변경 이벤트나 명시적인 동기화 계약이 필요합니다. 반대로 운영 조회에 필요한 최소 정보가 안정적이라면 서비스에 제한된 읽기 모델을 두고, 상세·최신 정보는 중앙 API로 조회하는 방식이 실용적일 수 있습니다. 핵심은 UUID Soft FK가 데이터 관계를 해결해도 운영 조회 문제까지 자동으로 해결하지는 않는다는 점입니다.