운영 적용 범위
서비스 1개
- 근거 종류
- 사용자 보고값
- 기준 시점
- 2026-09
사용자 인터뷰와 중앙 회원 서버·HiPass 연동 코드에서 확인한 공개 범위입니다.
관찰 범위: 여러 서비스의 인증을 통합한 성과가 아니라 첫 운영 서비스에 적용한 범위입니다.
데이터를 불러오는 중입니다...
데이터를 불러오는 중입니다...
1인 백엔드 개발자로 Express 기반 초기 서버부터 NestJS·Prisma 전환까지 중앙 회원 관리·인증 서버 전반을 설계하고 구현했습니다. ID·비밀번호·UUID를 중앙에서 관리하고, 첫 번째 운영 서비스가 중앙 서버에서 인증과 토큰 발급을 처리하면서도 자신의 도메인 데이터는 별도 DB에 유지하도록 구성했습니다.
1인 백엔드 개발자로 Express 기반 초기 서버부터 NestJS·Prisma 전환까지 중앙 회원 관리·인증 서버 전반을 설계하고 구현했습니다. 회원 원본과 서비스 데이터의 책임 분리, 회원가입·로그인·토큰 발급과 갱신, Provider 권한, UUID 연결, 서비스의 로컬 토큰 검증과 키 캐시를 담당했습니다.
운영 적용 범위
서비스 1개
사용자 인터뷰와 중앙 회원 서버·HiPass 연동 코드에서 확인한 공개 범위입니다.
관찰 범위: 여러 서비스의 인증을 통합한 성과가 아니라 첫 운영 서비스에 적용한 범위입니다.
구축·확장 기간
2024.07 – 2025.06
초기 Express 구축 시점은 사용자 인터뷰, 2025년 NestJS·Prisma 전환과 기능 확장은 Git 이력으로 확인했습니다.
현재 상태
운영·유지보수 중
첫 연동 서비스가 현재도 운영 중이라는 사용자 보고 범위입니다.
문제는 향후 서비스마다 회원 테이블과 비밀번호 처리, 인증 API를 반복해서 구현해야 한다는 점이었습니다. 이를 피하기 위해 회원 원본과 인증 책임을 별도 서버로 분리해야 했습니다. 목표는 한 번의 로그인으로 여러 서비스를 이용하게 하는 SSO가 아니라, 회사 차원에서 ID·비밀번호·UUID를 하나의 원본으로 관리하고 각 서비스가 자신의 도메인 데이터와 접근 정책에 집중하도록 만드는 것이었습니다.
첫 번째 목표는 다중 서비스 통합 성과가 아니었습니다. 중앙 회원 관리 구조를 실제 운영 서비스 하나에 적용해 회원가입·로그인·토큰 갱신·서비스 데이터 연결이 동작하도록 만드는 데 범위를 한정했습니다.
중앙 회원 서버와 서비스는 물리적으로 다른 데이터베이스를 사용했습니다. DB Foreign Key로 회원과 서비스 데이터를 직접 연결할 수 없었고, 서비스가 중앙 회원 DB를 직접 공유하면 데이터 소유권과 접근 책임이 섞였습니다. 반대로 모든 요청에서 중앙 API를 조회하면 서비스의 도메인 처리까지 중앙 서버 응답에 의존하게 됩니다.
Provider 키 조회 실패에는 서비스가 보관한 JSON 캐시를 사용하는 경로를 두었습니다. 그러나 로그인 API 자체가 중단됐을 때 신규 로그인을 처리하는 fallback은 구현하거나 테스트하지 않았습니다. 이미 발급된 토큰으로 가능한 범위 역시 장애 실험으로 확인하지 않았으므로 가용성 성과로 주장하지 않습니다.
당시 실제로 비교한 대안은 중앙 회원 DB를 서비스가 직접 공유하는 방식과, 서비스가 회원을 식별할 때마다 중앙 회원 API를 조회하는 방식이었습니다.
공용 DB 방식은 별도 조회 API가 필요 없지만 인증 원본과 서비스 도메인 데이터의 책임·보안 경계를 섞습니다. 매 요청 조회 방식은 중앙 원본을 기준으로 처리할 수 있지만 서비스 도메인 요청도 중앙 응답에 의존합니다. 그래서 ID·비밀번호·UUID는 중앙 서버가 관리하고, 서비스는 로그인 응답으로 받은 UUID를 자신의 DB에 저장해 논리적으로 연결하는 방식을 선택했습니다. Redis 중앙 세션은 당시 검토한 대안으로 기록하지 않습니다.
Provider 키 준비부터 로그인, 서비스의 로컬 검증, 토큰 갱신과 확인되지 않은 장애 경계를 보여줍니다.
서비스는 중앙 회원 서버에서 Provider 키를 받아 캐시하고, 로그인 응답의 UUID와 토큰을 저장한 뒤 Access Token은 로컬에서 검증하고 Refresh Token 갱신은 중앙 서버에 요청합니다.
서비스가 마지막으로 저장한 JSON 캐시를 읽어 토큰 검증에 사용할 키를 준비합니다.
신규 로그인 fallback은 구현하거나 테스트하지 않았으므로 흐름이 중단됩니다.
중앙 회원 서버가 ID·비밀번호·UUID의 원본을 관리합니다. 서비스 서버는 Provider 식별자와 API 인증값을 포함해 회원가입·로그인 요청을 전달하고, 중앙 서버는 등록된 Provider와 허용 서버를 확인한 뒤 요청을 처리합니다.
중앙 회원 서버가 Access Token과 Refresh Token을 발급하고 UUID를 회원정보로 반환합니다. 2024년 초기 토큰에 어떤 회원 식별자가 포함됐는지는 코드를 확인하지 못했으므로 공개 사실로 단정하지 않습니다.
HiPass는 로그인 응답의 UUID·로그인 ID·Access Token·Refresh Token과 만료 정보를 로컬 user_tokens 테이블에 저장합니다. 이후 Access Token은 Provider 키로 로컬 검증하고, user_tokens에서 로그인 ID에 대응하는 UUID를 복원해 서비스 도메인 데이터를 조회합니다.
Access Token 재발급은 Refresh Token을 중앙 회원 서버에 보내 처리합니다. 서비스 DB의 user_tokens 레코드를 직접 제거한 뒤 해당 사용자가 재로그인을 요구받는 것도 확인했습니다. 중앙에서 모든 서비스의 세션을 한 번에 종료하는 기능은 구상했지만 구현하지 않았습니다.
서비스는 중앙 회원 서버의 Provider 정보를 JSON 파일에 캐시합니다. 주기적 갱신이나 서비스 시작 시 통신에 실패하면 마지막 파일을 사용해 키 조회 실패가 즉시 토큰 검증 중단으로 이어지지 않게 했습니다. 이 fallback은 로그인 API 장애까지 해결하지 않습니다.
UUID만으로 관리자 목록과 장애 로그를 추적하기 어려워 서비스에는 로그인 ID를 함께 저장했습니다. 이후 중앙 회원 서버에 UUID 배열을 한 번에 조회하는 Batch API를 추가하고, 관리자 목록에서 여러 회원의 로그인 ID를 한 번에 가져오도록 보완했습니다.
2024년 Express 기반으로 시작했고 2025년 4월 NestJS로 전환했습니다. 이어 Prisma 전환과 회원 조회·변경, 관리자 기능을 확장했습니다. Module·Provider·DI, Middleware·Guard·Decorator, DTO 검증과 예외 처리 기준은 이후 다른 사내 백엔드 프로젝트에도 재사용했고, nestjs-expert 스킬을 구성할 때 참고한 실무 근거 중 하나가 됐습니다.
중앙 회원 관리 구조를 운영 서비스 하나에 적용했고 현재도 유지보수하고 있습니다. 회원가입·로그인, 중앙 토큰 발급, 서비스의 로컬 검증, Refresh Token 갱신, UUID 기반 서비스 데이터 연결과 로컬 토큰 레코드 제거 후 재로그인 요구를 확인했습니다.
Git 이력에서는 2025년 4월 NestJS 전환, 5월 Prisma 전환과 회원 조회·변경 API, 6월 관리자 대리 로그인 기능 확장이 확인됩니다.
인증 장애 감소율이나 성능 개선 수치는 측정하지 않았고 여러 서비스를 통합한 결과도 아닙니다. 중앙 로그인 API 장애와 다중 서비스 세션 통제 역시 검증된 성과에 포함하지 않습니다.
이 프로젝트를 통해 공통 회원 원본 관리와 Single Sign-On은 별개의 요구사항이라는 점을 구분하게 됐습니다. 사용자 집단과 로그인 경험을 실제로 공유해야 할 때만 SSO를 확장하고, 그렇지 않다면 중앙 회원 원본과 서비스별 인증·권한 경계를 명확히 하는 편이 적합합니다.
Provider 키 조회 실패에는 파일 캐시 fallback을 두었지만 로그인 API 장애에는 대응하지 못했습니다. 지금 다시 설계한다면 로그인 API의 가용성 요구와 장애 시 사용자 경험을 먼저 정의하고, 재시도·이중화 또는 제한된 장애 대응 범위를 직접 테스트하겠습니다.
UUID로 시스템 관계를 잇는 것과 운영자가 회원을 추적할 읽기 모델을 만드는 것도 별개의 문제였습니다. 원본 데이터, 서비스 도메인 데이터와 운영 조회용 복제 값의 책임을 처음부터 구분해야 한다는 판단이 남았습니다.