통합 로그인을 붙이기 전에 정리해두어야 하는 것들

로그인을 하나로 묶는다는 것이 뜻하는 것

통합 로그인(SSO)을 도입하기로 정했다고 바로 작업이 시작되지는 않습니다. 그 전에 지금 운영 중인 서비스마다 사용자 정보를 어떤 형태로 저장하고 있는지부터 맞춰봐야 합니다. 여러 서비스를 각각 따로 로그인하던 사용자가 한 번의 로그인으로 전체 서비스를 오갈 수 있게 만드는 구조이기 때문입니다.

계열사나 사업부별로 서비스를 따로 만들다 보니 계정이 서비스마다 갈라져 있는 경우, 또는 회원가입 단계의 이탈을 줄이려고 소셜 로그인부터 먼저 붙이려는 경우 모두 결국 같은 질문에서 출발합니다. 이 사람이 누구인지, 어디까지 접근할 수 있는지를 어디서 한 번에 확인할 것인가 하는 질문입니다.

카카오나 네이버 같은 소셜 로그인 연동과 사내 그룹웨어·ERP 간 계정 연동은 겉보기에는 다른 작업처럼 보이지만 같은 원리 위에 있습니다. 둘 다 원래 각자 갖고 있던 사용자 정보를 하나의 기준으로 확인하고 연결하는 일이기 때문입니다.

서비스마다 사용자 정보가 저장된 방식이 다르면, 통합은 그 차이를 하나의 기준으로 좁히는 일부터 시작합니다.

서비스마다 사용자 정보가 다르게 생겼을 때

이름, 권한, 소속 같은 항목이 서비스마다 다르게 저장돼 있을 때

같은 사람이라도 그룹웨어에는 사번과 부서명으로, 예약 시스템에는 이메일과 직급명으로 등록돼 있는 식으로 서비스마다 사용자 정보를 담는 방식이 다릅니다. 통합 로그인을 설계할 때는 먼저 이렇게 서로 다른 항목을 하나의 매핑표로 정리해, 어떤 값을 기준으로 같은 사람임을 확인할지 정합니다.

한쪽에서 바뀐 정보가 다른 서비스에도 반영돼야 하는지 정하기

부서가 바뀌거나 연락처가 바뀌었을 때, 그 변경이 연동된 다른 서비스에도 곧바로 반영돼야 하는지, 아니면 일정 주기로 모아서 반영해도 괜찮은지는 서비스 성격에 따라 다릅니다. 이 기준을 미리 정해두지 않으면 나중에 어느 쪽 정보가 맞는지를 두고 혼선이 생깁니다.

오래된 시스템이라 바로 연동이 안 될 때 다리를 놓는 방법

그룹웨어나 예약 시스템이 오래전에 만들어져, 지금 필요한 형태로 데이터를 곧바로 주고받을 수 없는 경우도 자주 있습니다. 이때는 중간에 데이터 형식을 맞춰 전달하는 연동 단계를 따로 두고, 바로 처리해야 할 항목과 모아서 처리해도 되는 항목을 나눠 설계합니다. 연동할 사내 시스템이 여러 개로 늘어나면, 이 조정은 여러 시스템을 함께 운영하는 구조 전체의 문제가 됩니다.

권한까지 하나로 묶을 때 생기는 질문

로그인은 하나로 묶였어도 서비스별로 보여줄 화면은 다르게 유지해야 하는 경우가 대부분입니다. 같은 계정이라도 어떤 서비스에서는 일반 사용자 화면만, 다른 서비스에서는 관리자 화면까지 접근하게 해야 한다면 서비스별 권한을 로그인 구조와 분리해 따로 설계합니다.

인증 서버는 모든 서비스의 로그인이 거쳐 가는 통로이므로, 문제가 생기면 전체 서비스의 로그인이 함께 막히는 구조적인 위험이 있습니다. 로그인이 몰리는 시간대의 응답 속도와 장애 시 대체 경로, 비밀번호와 토큰의 암호화 저장, 필요한 시스템에만 열어두는 접근 권한까지 이 단계에서 함께 정해둡니다.

인증 서버 하나가 멈추면 그 서버를 쓰는 모든 서비스의 로그인이 함께 멈춥니다.

소속이 바뀌는 상황, 즉 퇴사나 이직, 부서 이동이 생겼을 때 권한을 다시 정리하는 절차도 함께 설계해야 합니다. 계정 하나를 없애는 것만으로는 충분하지 않습니다. 그 계정이 접근하던 모든 서비스에서 권한이 함께 회수되는지 확인하는 체계가 필요합니다. 이 부분이 비어 있으면 떠난 사람의 계정이 한 시스템에만 남아 있는 사고로 이어집니다.

연동 범위를 처음부터 정해두면 좋은 이유

통합의 범위는 로그인만 묶을지, 데이터까지 양쪽 서비스에서 같이 쓸지에 따라 크게 달라집니다. 로그인만 묶는 작업과 데이터를 주고받는 연동은 필요한 작업량과 점검 항목이 다르기 때문에, 이를 구분하지 않고 통합이라는 한 단어로만 이야기하면 범위를 정하는 단계에서 오해가 생기기 쉽습니다.

범위를 서비스 하나와 하나를 잇는 구조로 명확히 설계해두면, 서비스를 하나씩 늘려갈 때도 같은 구조를 그대로 다시 쓸 수 있습니다. 범위를 정하지 않고 필요할 때마다 손이 가는 대로 연결하면, 서비스가 늘어날수록 무엇이 어떻게 연결돼 있는지 파악하기 어려운 상태가 됩니다.

상담을 요청하기 전에 정리해두면 좋은 것들

지금 운영 중인 서비스와 시스템을 목록으로 적어보는 것이 출발점입니다. 몇 개의 서비스가 있는지, 각 서비스가 사용자 정보를 어디에 저장하고 있는지, 소셜 로그인으로 들어오는 사용자와 사내 계정으로 들어오는 사용자가 섞여 있는지를 구분해두면 범위를 정하는 시간이 줄어듭니다.

모바일 앱을 함께 운영한다면 애플 로그인 포함 여부를 미리 확인해두는 것이 좋습니다. 다른 소셜 로그인을 제공하면서 자체 계정 체계가 아닌 앱은 앱스토어 심사 과정에서 애플 로그인도 함께 요구되는 경우가 있습니다. 개인정보보호법에 따라 소셜 로그인으로 어떤 정보까지 받아올지, 그 정보를 어떤 목적으로 쓸지도 미리 정리해두면 동의 화면과 고지 문구를 설계하는 단계가 빠르게 넘어갑니다. 꼭 필요한 항목만 받아오는 쪽으로 범위를 좁혀두는 편이 이후 보안 점검에서도 유리합니다.

정리

통합 로그인은 화면에 버튼 하나를 추가하는 일을 넘어, 서비스마다 다르게 쌓여 있는 사용자 정보와 권한을 하나의 기준으로 맞추는 작업입니다. 이 기준을 먼저 세워두면 서비스를 하나씩 늘려가도 같은 구조를 반복해서 쓸 수 있습니다.

통합인증 서비스 페이지에서는 서비스마다 다른 사용자 정보와 권한을 맞춰가는 과정을 단계별로 더 자세히 안내합니다.