OEM 통합 서버

오디야 안정화를 마무리하면서, 신규 서비스가 계속 붙는데 매번 따로 회원가입을 받는 구조는 UX와 운영 비용 양쪽에서 부담이 누적된다는 게 명확했습니다. 통합 OEM 인증을 회사에 제안해 채택받고, 팀장으로서 리딩하며 백엔드(Spring Boot)·운영자 대시보드(Next.js)·가입·마이페이지 WebView 세 컴포넌트를 처음부터 설계·구현했습니다.

핵심 위험은 데이터 정합성이었습니다. 부모-자녀 관계가 서비스마다 따로 저장되면 한 곳만 어긋나도 사용자 화면에서 데이터 불일치가 노출됩니다. 동시에 자녀 단말은 백그라운드 위치 전송 때문에 장수명 인증이 필요한데, 짧은 토큰 회전 모델로는 안드로이드 백그라운드 강제 종료와 네트워크 끊김 사이에 위치 전송이 빠져버립니다.

• 부모-자녀 관계를 서비스별로 따로 저장 → 한 곳만 어긋나도 사용자 화면에서 사고로 노출
• 자녀 단말은 백그라운드 위치 송출용 장수명 인증 필요 — 일반 access/refresh 회전 패턴으로는 위치가 끊김
• 미성년자 자가 탈퇴 금지 — 부모/자녀 탈퇴 처리가 비대칭이어야 함
• Webhook 단계적 재시도가 다 실패해도 운영팀이 추적·복구할 수단이 필요

네 가지 설계 결정을 처음부터 잡고 들어갔습니다. 부모/자녀 비대칭 토큰 모델, refresh 재사용 탐지를 처음부터, Webhook은 DLQ와 운영자 콘솔까지, 그리고 "서비스 탈퇴"와 "계정 탈퇴"는 다른 신호로 분리한다는 것입니다.

매니지드 인증(Auth0/Cognito/Firebase)·표준 OAuth(Spring Authorization Server)·Kafka/RabbitMQ 모두 검토했지만, 미성년자 도메인 제약과 자사 백엔드 통합이 1차 목표라는 점에서 자체 모델 + DLQ가 가장 잘 맞았습니다.

토큰 모델을 부모/자녀 비대칭으로 분리했습니다. 자녀 쪽 토큰을 길게 잡은 이유는, 자녀폰의 백그라운드 강제 종료와 네트워크 끊김이 일상이라 표준 회전 패턴으로는 위치 전송이 끊기고 그게 곧 보호자 컴플레인으로 이어지기 때문입니다. 부모 쪽은 표준 회전, 자녀 쪽은 장수명 토큰을 DB에 안전하게 보관하는 구조로 풀었고, 회수된 토큰의 재사용이 감지되면 같은 묶음 전체를 즉시 무효화하고 감사 로그를 남깁니다. Webhook은 단계적 재시도 후 실패하면 별도 보관소로 보내 운영팀이 추적·재시도·포기할 수 있게 했고, 휴면 → 익명화 → 완전 삭제 라이프사이클은 자동으로 돌게 했습니다.

• 토큰 재사용 탐지 — 회수된 토큰의 재사용이 감지되면 같은 묶음 전체를 즉시 무효화 + 감사 로그
• 비대칭 토큰 모델 — 자녀 쪽은 장수명 토큰을 DB에 안전 보관해 백그라운드 위치 송출이 끊기지 않게 처리
• Webhook 전달 추적 — 전용 비동기 풀에서 단계적 재시도 → 실패 시 별도 보관소 + 운영자 콘솔(목록·재시도·포기 + 감사 로그)
• 라이프사이클 자동화 — 휴면 안내 → 익명화 → 완전 삭제 단계가 자동 진행

한 번에 완성된 설계가 아닙니다. 외부 QC와 내부 QC 단계에서 네 가지 빈틈이 차례로 드러났고, 그때마다 DB 스키마와 동작을 한 단계씩 보강했습니다. 위치 공유와 단말 통제를 한 번에 묶던 가입을 서비스 단위로 분리했고, 메모리 3회 재시도가 다 실패한 Webhook은 DLQ 테이블과 운영자 콘솔을 붙여 추적·복구 가능하게 만들었습니다. 직접 가입 사용자에게 두 번 발송되던 휴면 안내 경로를 차단했고, "한 서비스 데이터만 정리"와 "계정 자체 소멸 → JWT 즉시 차단" 신호를 별도 이벤트로 갈랐습니다.

• 서비스 단위 가입 분리 — 같은 부모-자녀가 위치 공유와 단말 통제를 따로 신청할 수 있도록, 한 번에 묶이던 연동 구조를 서비스 단위로 갈랐습니다.
• Webhook 추적성 보강 — 일시 장애로 단계적 재시도가 모두 실패한 메시지가 사라지던 문제를 잡기 위해, 실패 메시지를 별도 보관하는 영역과 운영자가 직접 재시도·포기를 누를 수 있는 콘솔, 같은 메시지가 두 번 처리되지 않게 막는 중복 방지 제약을 함께 투입했습니다.
• 휴면 안내 중복 발송 차단 — 웹에서 직접 가입한 사용자에게 안내 메일이 두 번 발송되던 경로를 차단했습니다.
• 계정 탈퇴 신호 분리 — "한 서비스에서만 데이터를 정리하라"는 신호와 "계정 자체가 사라지니 모든 서비스에서 토큰까지 즉시 차단하라"는 신호를 별도 이벤트로 갈랐습니다.

여러 서비스가 부모-자녀 관계를 각자 따로 저장하던 구조를, 모두 OEM 인증 서버 한 곳을 바라보는 구조로 옮겼습니다. 이 통합 인증 아키텍처가 안정적으로 자리잡으면서 후속 사업 의사결정의 기반이 됐고, 그 위에서 모하니가 정식 사업화로 이어졌으며 오디야는 새 버전이 OEM 사전탑재 채널로 확장돼 회사 B2B 사업 규모를 한 단계 키울 수 있었습니다.