통합인증 서비스

80여 개 연동 코드에서 공통 명세를 찾다

소유인증, 본인인증, 계좌인증이 따로 운영되고, 호출하는 클라이언트마다 필요한 정보와 처리 로직도 달랐습니다. 각 연동부가 인증사와 직접 통신하고 엔드포인트도 나뉘어 있어, 인증 기능을 바꾸면 여러 곳을 함께 살펴야 했습니다.

지마켓·옥션·ESMPLUS에서 사용 목적별로 발급한 80여 개 연동 코드를 취합해 공통 명세를 설계했습니다. 서로 달랐던 인증 엔드포인트를 공통 API로 통합하고, 각 팀에 명세에 맞춘 연동 개선을 요청했습니다.

통합은 2차인증을 위한 소유인증에서 시작했습니다. 이후 본인인증을 추가하고 기존 계좌인증을 공통 인터페이스로 감싸는 범위까지 넓혔습니다. 3인 팀에서 프로젝트를 주도하며 다섯 인증 유형의 모듈, 외부 업체 연동, 공통 세션과 관리자 기능까지 전체를 구현했습니다.

전체 아키텍처

호출 서비스가 회원 유형과 업무 조건을 판단해 유입코드·목적코드로 요청합니다. 통합인증은 해당 코드에 연결된 어드민 설정으로 인증을 수행하며, 회원 서비스나 개별 도메인의 업무 로직에 의존하지 않습니다.

업무 판단은 호출 서비스에, 인증 수단은 설정으로

호출 서비스는 업무 조건을 판단한 뒤 유입코드와 목적코드로 인증을 요청합니다. 통합인증 어드민은 사이트 > 유입코드(도메인) > 인증 목적 구조로 설정을 관리하고, 각 코드에 적용할 인증 수단을 정합니다.

같은 E쿠폰 조회라도 사업자회원은 문자·이메일 소유인증을, 개인회원은 휴대폰·아이핀·신용카드 등의 본인인증을 수행합니다. 개인과 사업자를 구분하고 그에 맞는 코드로 요청하는 일은 E쿠폰을 제공하는 호출 서비스가 맡습니다.

통합인증은 전달된 코드에 연결된 설정으로 인증을 수행합니다. 회원 서비스에 개인·사업자 여부를 묻거나 쿠폰 업무를 해석할 필요가 없습니다. 업무 판단과 인증 수행의 책임을 나눠 사이트와 도메인이 달라도 공통으로 사용할 수 있도록 설계했습니다.

외부 인증업체와의 통신도 윈도우 설치형 모듈에서 API 토큰 방식으로 바꾸고, On-Premise ASP.NET에 있던 인증 기능을 Spring Boot로 옮겼습니다.

운영자가 손댈 수 있는 인증

기존의 휴대폰 본인인증·아이핀·신용카드 인증에 더해 소셜 인증사를 도입했습니다. 사용자가 간편하게 인증할 수 있는 선택지를 넓히고, 이용 단가와 이벤트 활용도 함께 고려했습니다.

휴대폰 본인인증과 계좌인증의 업체 장애에 대응하기 위해 요청 비중 조정 기능을 추가했습니다. 운영자는 업체 장애나 이용 비용을 고려해 신규 요청의 비중을 배포 없이 바꿀 수 있습니다. 장애 시에는 자동 비활성화와 비중 조정으로 대체 업체에 요청을 분산합니다. 변경된 비율은 신규 요청에 적용하고, 진행 중인 인증은 기존 흐름으로 처리합니다.

장애 횟수 갱신과 상태 알림의 역할을 나누다

동시 요청이 Redis의 장애 횟수를 함께 갱신하므로, 관련 카운트 갱신을 Lua 안에 묶어 원자적으로 실행했습니다. 스크립트는 SHA로 캐시하고 EVALSHA에 변수를 전달해 호출했습니다. EVALSHA는 실행을 생략하거나 결과를 캐시하는 기능이 아니라 스크립트 본문의 반복 전송을 줄이는 방식입니다.

상태 변경은 Redis Pub/Sub으로 Caffeine 캐시에 알리고, RDB 원천 데이터를 주기적으로 다시 읽어 알림 누락 경로를 보완했습니다. 이 규모의 상태 변경에 Kafka까지 추가할 필요는 없다고 판단했습니다. Lua는 갱신의 원자성, Pub/Sub은 변경 알림, 주기 동기화는 누락 보완을 담당하며 각각의 역할을 구분했습니다.

장애 시 비율 조정과 TTL 재시도

휴대폰 본인인증에서 외부 인증업체에 장애가 발생하면 해당 업체를 자동 비활성화하고, 대체 인증업체로 요청을 분산하도록 비율을 조정했습니다. 로컬에 보관한 장애 상태의 TTL을 10분으로 두고, 만료 후 비율을 보정해 다시 시도하는 흐름까지 구현했습니다.

장애 상태의 TTL 만료 후 재시도와, 정상화를 확인한 뒤 원래 요청 비율로 자동 복귀하는 기능은 별개입니다. 원래 비율로의 자동 복귀(auto recovery)는 설계 리뷰까지 진행했지만, 기존 서비스가 정상 운영 중인 점을 고려해 구현에는 반영하지 않았습니다.

다섯 인증 유형이 공유하는 세션

세션은 특정 인증이나 E쿠폰만을 위한 기능이 아니라 통합인증의 공통 기능입니다. UUID로 세션을 조회하고, 관리자 화면에서 정한 유효기간을 기준으로 활성 여부를 확인하도록 구현했습니다.

인증별 처리 로직은 각 모듈이 담당하고, 세션 유효성 확인은 공통으로 사용합니다. E쿠폰에는 본인·소유인증을 연동해 공통 세션으로 인증 내역과 이력을 관리했습니다.

연동부터 운영까지 맡은 범위

소유·본인·계좌·정보·기업인증의 API와 외부 업체 연동, 공통 세션, 코드별 인증 설정과 업체별 요청 비율 관리 기능을 모두 구현했습니다. 정보인증에는 아이디·비밀번호와 소셜인증이 포함됩니다. 계좌인증은 유입 경로별 은행 정보 API와 연동 가이드를 제공하고, E쿠폰은 세션 상태 때문에 인증이 진행되지 않는 문의까지 확인했습니다.

오픈 직전 연동 명세가 바뀐 경험을 계기로 회의록·설계 문서·진행 상황을 공유하며 연동 서비스와 변경 사항을 맞췄습니다.

구현 범위 · 사용 기술

돌아보면

공통 API로 인증을 모으면서도 업무 판단은 호출 서비스에 남겼습니다. 통합인증은 코드와 설정에 따라 인증을 수행하고, 운영자는 인증 수단과 업체별 요청 비중을 관리합니다. 여러 도메인에서 재사용할 수 있는 경계와 운영 중 바꿀 수 있는 범위를 함께 정리한 작업입니다.