직장인이라면 무조건 한 번쯤 들어본 단어, ERP. 만약 어느 정도 규모 있는 회사에 다니는 사람이라면 혹시 출근 후 가장 먼저 하는 일이 VDI 환경에 로그인하는 것이 아닌가? Google Workspace, Naver Cloud, Slack, Microsoft Office, 요즘은 이미 다양한 협업 공간이 사내에 마련되어 있다.
각 협업 공간은 모두 나의 계정이라는 것이 존재하는데, 회사 입장에서 보면 이 수 많은 서비스와 계정들은 수시로 몇 개씩 생겨나고 삭제될 것이다. 또한 부서 이동이나 연락처 변경 등 직원 정보 변동도 있을 것이다. 이 모든 정보는 회사 내 여러 협업 공간에서 업데이트 되고 있다.
여기서 잠깐, 혹시 인사 담당자의 고충을 상상해 본 적 있는가? 누가 과연 이 모든 데이터를 관리하고 있을까? SCIM과 Provisioning은 바로 이 지점에서 출발했다.

프로비저닝(Provisioning)이란?
기업 등 조직에서는 구성원 정보를 단 하나의 DB(MS-Excel 파일, Google-Sheet, 3rd-party ERP, MS-EntraID(구. ActiveDirectory), Okta 등 인사 정보를 담고 있는 그 어떤 것)에서 일괄 관리한다. 조직에서 사용하는 서비스가 여러 개인 경우, 각 서비스 마다 구성원 정보를 관리해야 하는 번거로움이 있다. 프로비저닝을 사용하면 단 하나의 DB에서만 구성원 정보를 최신화 하고, 나머지 여러 서비스들에는 자동으로 동기화 된다.
여기서, 구성원 정보는 조직에서 정의하기에 따라 매우 다양할 수 있겠다. 예를 들면,
- 이름, 나이, 사는 곳, Email, 전화번호
- 소속 부서, 직책, 직위, 연봉
- 입사일, 기념일, 취미 등
이 중에서 어떤 서비스에는 이름, Email, 전화번호 정보만 동기화 하고 싶을 수도 있고, 어떤 서비스에는 소속 부서, 직책을 동기화 하고 싶을 수도, 어떤 서비스에는 모든 정보를 다 담고 싶을 수도 있다. 즉, 서비스의 특성에 따라 동기화 하려는 구성원 정보는 모두 다를 것이다. 특히 전사 구성원이 상시적으로 사용하는 서비스라면, 구성원의 핵심 정보를 최신으로 업데이트하려는 니즈가 클 것이다.
구성원이 많은 회사들은 이미 단 하나의 DB를 구축하고 있고, 그 DB 구축을 유료 서비스하는 곳도 있으며, 일부 서비스들에는 이 프로비저닝 기능을 쉽게 구현할 수 있도록 부가 서비스를 제공하기도 한다. 그 예시가 바로 MS-EntraID(구. AzureAD), Okta 등이다.
SCIM이란?
다양한 도메인 간 구성원 정보를 관리하기 위해 이미 누군가 만들어 놓은 표준화 된 체계이다. 이것을 사용하면, 각 서비스들은 보다 효율적으로 상호 프로비저닝할 수 있게 된다. 그 목적이 명확한 만큼 구조는 단순하다. 구성원에 해당하는 User, 조직도(팀)에 해당하는 Group 이 있다.
SCIM은 일종의 RESTful API이다. 따라서 GET, POST, PATCH, DELETE 를 사용한다. SCIM으로 할 수 있는 것들은 아래와 같다.
- User 생성, 정보 조회, 업데이트, 삭제(비활성 처리)
- Group 생성, 정보 조회, 업데이트, 삭제
- Schema 정보 조회
MS-EntraID(구. AzureAD) 및 Swit 사례로 살펴보는 프로비저닝 흐름
User(계정 정보) 업데이트 상황
EntraID의 User 목록을 기반으로, 일정 주기를 갖고 Swit의 User 목록을 조회하고 업데이트한다. EntraID는 SCIM API를 사용하여 Swit의 사용자 목록을 조회하여, 사용자 데이터가 없다면 Swit 사용자를 생성, 사용자 데이터가 있다면 달라졌는지 검토하고 필요시 업데이트한다.
그렇다면, 데이터가 있는지 없는지 어떻게 판별할까? Swit User ID 값을 아는지 모르는지에 따라 로직이 나뉜다. 아는 경우, Get user by ID를 사용하여 조회한다. 모르는 경우, Get user by query (email)를 사용하여 조회한다. 이 때, EntraID의 데이터와 Swit 사용자 데이터를 비교했더니 업데이트가 필요하다면, Patch user by ID를 통해 최신 정보로 업데이트한다.
Group(조직도) 업데이트 상황
EntraID의 Group 목록을 기반으로, 일정 주기를 갖고 Swit의 조직도를 조회하고 업데이트한다. EntraID는 SCIM API를 사용하여 Swit의 조직도를 조회하여, 팀이 없다면 새로운 팀 생성, 팀이 있다면 달라졌는지 검토하고 필요시 업데이트한다.
팀이 있는지 없는지 판별하는 로직은 User와 동일하다.
'Developer Advocacy' 카테고리의 다른 글
| RFC 7643 한글 해설 2 - 리소스 (1) | 2024.07.03 |
|---|---|
| RFC 7643 한글 해설 1 - 용어 및 스키마 설명 (2) | 2024.06.26 |
| SAML과 SSO, 비개발자도 이해할 수 있게 알려드립니다! feat. 네이버로 로그인하기, 카카오로 로그인하기, ERP, Google Sign-in의 비밀 (0) | 2023.07.01 |
댓글