사내 IDP를 만들다 보면 결국 사용자 관리에서 한 번은 꼭 막히게 되는데, 지금 질문 주신 지점이 딱 그 지점인 것 같습니다. 여러 팀이 동시에 Keycloak을 쓰기 시작하면 “이걸 정말 사용자마다 하나씩 만들어야 하나?”라는 의문이 드는 게 자연스럽습니다.
결론부터 말씀드리면, Keycloak을 기본 상태로 사용할 때 여러 사용자를 한 번에 생성해 주는 단일 REST 엔드포인트는 없습니다. 아이디 여러 개와 비밀번호, 공통 설정을 한 번에 던지면 전부 처리해 주는 API는 제공되지 않습니다. 이건 단순히 기능이 빠진 게 아니라, Keycloak 쪽 설계 방향에 가깝습니다.
Keycloak 같은 글로벌 표준 솔루션들은 사용자 생성 같은 작업을 아주 보수적으로 다룹니다. 예를 들어 10명을 동시에 생성하다가 중간에 하나가 실패했을 때, 나머지를 살릴지 말지, 롤백할지 말지는 조직마다 판단이 다릅니다. 그래서 Keycloak은 “한 명을 확실하게 만든다”는 최소 단위만 제공하고, 그걸 어떻게 묶어서 쓸지는 사용하는 쪽에서 결정하도록 남겨 둔 구조입니다.
그렇다고 해서 현업에서 이걸 매번 수동으로 처리하느냐 하면, 그렇지는 않습니다. 실제로는 몇 가지 방식이 자연스럽게 섞여서 쓰이고 있습니다.
가장 많이 쓰이는 방식은, 사용자 생성 API에 모든 설정을 다 넣으려고 하지 않는 겁니다. 아이디와 비밀번호만 넘기고, 나머지 공통 설정은 Keycloak 쪽에 미리 정의해 둡니다. 예를 들면 신규 사용자는 무조건 특정 그룹에 들어가게 한다거나, 기본 역할을 자동으로 부여해 두는 식입니다. 이렇게 해 두면 API를 호출하는 쪽에서는 복잡한 걸 신경 쓸 필요가 없고, 사용자가 생성되는 순간 Keycloak이 알아서 필요한 설정을 붙여 줍니다. 운영하면서 설정 누락이 생길 여지도 훨씬 줄어듭니다.
초기 세팅이나 정기적으로 많은 사용자를 한꺼번에 넣어야 하는 경우라면, Partial Import 기능을 쓰는 경우도 많습니다. 사용자 정보를 JSON 파일 하나로 만들어서 한 번에 등록하는 방식인데, 대량 작업에는 꽤 실용적입니다. 다만 이건 어디까지나 일괄 작업용이고, 외부 시스템에서 실시간으로 호출하는 API 용도와는 성격이 다릅니다.
여러 팀이 공통으로 사용하는 IDP라면, Keycloak 앞에 내부용 API를 하나 두는 방식도 자주 선택됩니다. 외부에서는 “우리 회사 사용자 생성 API” 하나만 보이게 하고, 그 안에서 Keycloak Admin API를 여러 번 호출하는 식입니다. 이렇게 하면 각 팀이 Keycloak의 구조를 직접 알 필요도 없고, 회사 정책에 맞게 사용자 생성 흐름을 통제하기도 훨씬 쉬워집니다. 실제로는 이 방식을 쓰면서도 “Keycloak을 쓰고 있다”기보다는 “사내 사용자 생성 API를 쓴다”고 인식하는 경우가 많습니다.
Keycloak 내부에 커스텀 엔드포인트를 추가하는 방법도 있긴 합니다만, 이 단계부터는 업그레이드나 유지보수 부담을 함께 가져가야 해서, 특별한 이유가 없다면 보통은 여기까지는 가지 않습니다.
결국 관점을 조금 바꾸는 게 핵심인 것 같습니다.
Keycloak 안에 이미 완성된 대량 생성 기능이 있기를 기대하기보다는, Keycloak은 사용자 관리 엔진으로 두고, “사용자를 만든다는 게 우리 회사에서는 어떤 의미인지”를 IDP 쪽에서 정의하는 구조가 훨씬 유연합니다.
지금 고민하고 계신 지점은 단순히 API 하나의 문제가 아니라, 앞으로 사용자 관리 자동화를 어디까지 끌고 갈 것인가를 정하는 단계라고 봅니다. 엔진 자체를 복잡하게 만들기보다는, 엔진의 기본 기능을 잘 조합해서 개발자들이 쓰기 쉬운 인터페이스를 만들어 주는 쪽이, IDP 관점에서는 훨씬 오래 갑니다.