통합인증 서비스

만든 것

• 인증 모듈지식 · 소셜 · 소유 · 본인 · 계좌 · 기업 인증
• 도메인별 연동연동 서비스마다 쓸 인증 유형과 설정을 어드민에서
• 인증업체 비율업체별 트래픽 비율을 운영 중에 변경
• 인증 서비스 토큰도메인별 쿠키 대신 서비스가 발급한 토큰으로
• 외부사 통신설치형 모듈에서 API 토큰 기반으로
• 플랫폼 개편On-Premise ASP.NET에서 Spring Boot로

어떤 상황이었나

지마켓과 옥션의 인증 기능이 서비스마다 따로 있었습니다. 인증 로직 하나를 고치려면 여러 곳을 같이 손봐야 했고, 인증업체는 한 곳에 의존하고 있어서 그 업체에 문제가 생기면 할 수 있는 일이 별로 없었습니다. 비용을 조정할 여지도 없었습니다.

다뤄야 할 인증 유형도 많았습니다. 지식인증, 소셜인증, 소유인증, 본인인증, 계좌인증, 기업인증. 3인 팀에서 설계와 핵심 구현을 맡았습니다.

인증을 모듈로, 설정은 어드민으로

인증 유형별 기능을 한 서비스 안의 모듈로 정리하고, 어떤 도메인이 어떤 인증을 어떤 설정으로 쓰는지는 코드가 아니라 어드민 설정으로 뺐습니다. 새 서비스가 인증을 붙일 때 코드를 고치는 대신 설정을 추가하면 되는 구조를 목표로 했습니다.

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

운영자가 손댈 수 있는 인증

가장 신경 쓴 건 인증업체별 트래픽 비율을 어드민에서 바로 조정하는 기능입니다. 한 업체에 장애가 나면 배포 없이 비율을 옮겨서 신규 요청을 다른 업체로 돌릴 수 있고, 평소에는 같은 기능으로 업체 간 비용을 조정할 수 있습니다.

자동으로 장애를 감지해서 전환하는 방식은 아닙니다. 사람이 판단하고 조정하는 방식이고, 이미 진행 중인 인증은 비율 변경과 별개로 처리됩니다. 그 대신 언제 어떤 비율로 바꿨는지가 남고, 운영자가 즉시 쓸 수 있는 대응 수단이 생겼습니다.

토큰과 세션

도메인마다 쿠키로 들고 있던 인증 결과를 인증 서비스가 발급하는 토큰으로 바꿨습니다. 토큰이 진짜인지 확인하는 것과 지금 이 인증 내역이 아직 유효한지 확인하는 것은 다른 질문이라서, 전자쿠폰 인증처럼 다음 단계에서 다시 확인해야 하는 내역은 서버 세션에 따로 유지했습니다. 어떤 요청에서 서버 상태를 조회하느냐에 따라 세션 저장소 장애의 영향이 달라지기 때문에, 그 경계를 의식하면서 설계했습니다.

직접 손댄 것들

휴대폰 본인확인(PASS) 연동, 계좌점유인증에서 유입 경로별로 쓸 수 있는 은행 정보를 내려주는 API와 연동 가이드, 전자쿠폰의 본인 · 소유인증 내역과 이력을 다음 단계까지 유지하는 세션 관리는 제가 담당한 범위로 기록이 남아 있습니다.

2026년에는 기존 휴대폰 본인확인 모듈이 종료되면서 NICE 통합인증 API로 전환하는 작업을 맡았고, 지마켓 · 옥션 본인확인 서비스의 운영 반영과 배포 절차 문서까지 정리했습니다.

돌아보면

인증을 공통화하면 중복은 줄지만 영향 범위는 넓어집니다. 정상 흐름보다 외부 업체의 실패, 결과를 알 수 없는 타임아웃, 세션 만료 같은 경우를 얼마나 구체적으로 설계하느냐가 서비스의 품질을 정한다는 걸 이 프로젝트에서 배웠습니다.