오픈소스 인증 서버의 상용화, 우리가 배워야 할 교훈
IdentityServer4는 .NET 생태계에서 OAuth 2.0 / OpenID Connect 기반 인증·인가 서버를 구축할 때 사실상 표준처럼 사용되던 오픈소스 프로젝트였다. 그러나 2022년 12월, 이를 관리하던 Duende Software가 상용 라이선스 모델로 전환하면서 무료 사용이 사실상 종료됐다. 연간 수천 달러에 달하는 라이선스 비용이 부과되자 커뮤니티의 반발이 거셌고, 많은 팀이 대안을 찾아 나서기 시작했다. Java 백엔드 개발자 입장에서 이는 남의 이야기처럼 들릴 수 있지만, 인증 인프라의 라이선스 리스크는 기술 스택을 가리지 않는 실질적인 아키텍처 문제다.
인증 인프라 선택이 아키텍처 결정인 이유
인증·인가 서버는 단순한 라이브러리가 아니다. 서비스 전반의 토큰 발급, 세션 관리, 클라이언트 등록 등 핵심 보안 흐름을 담당하기 때문에, 한번 도입하면 교체 비용이 매우 크다. IdentityServer4 사례처럼 운영 중에 라이선스 정책이 바뀌면, 마이그레이션 자체가 대형 프로젝트가 되어버린다.
Java 생태계에서도 유사한 고려가 필요하다. 대표적인 선택지를 비교하면 다음과 같다.
- Keycloak: Red Hat이 후원하는 오픈소스 IAM 솔루션. 자체 호스팅 가능하며, 엔터프라이즈 환경에서 가장 널리 쓰인다.
- Spring Authorization Server: Spring 공식 프로젝트로, Spring Security와 자연스럽게 통합된다. 커스터마이징 자유도가 높지만 운영 부담은 팀이 져야 한다.
- Auth0 / Okta: 관리형 SaaS 서비스. 운영 부담이 없지만 트래픽 증가에 따라 비용이 급격히 올라갈 수 있다.
// Spring Authorization Server 기본 설정 예시
@Bean
public RegisteredClientRepository registeredClientRepository() {
RegisteredClient client = RegisteredClient.withId(UUID.randomUUID().toString())
.clientId("my-service")
.clientSecret("{noop}secret")
.authorizationGrantType(AuthorizationGrantType.CLIENT_CREDENTIALS)
.scope("read")
.build();
return new InMemoryRegisteredClientRepository(client);
}
라이선스 리스크를 사전에 관리하는 방법
IdentityServer4 사태가 주는 핵심 교훈은 오픈소스라고 해서 영구적으로 무료가 보장되지 않는다는 점이다. 특히 인증처럼 교체 난이도가 높은 컴포넌트일수록 초기 선택 시 라이선스 지속 가능성을 반드시 검토해야 한다.
실무에서 적용할 수 있는 체크포인트는 다음과 같다.
- 프로젝트의 거버넌스 구조 확인: 특정 기업이 단독으로 소유하는 구조인지, Apache/CNCF 같은 재단 산하인지 여부
- 라이선스 종류 파악: MIT, Apache 2.0은 상대적으로 안전하지만, SSPL이나 BSL 같은 변형 라이선스는 상업적 사용 제한이 있을 수 있음
- 커뮤니티 포크 가능성 고려: IdentityServer4의 경우 커뮤니티 주도 포크 프로젝트가 등장했으며, 이는 실제 대안이 될 수 있음
- 벤더 락인 최소화: 표준 프로토콜(OAuth 2.0, OIDC) 기반으로 구현하면 서버 교체 시 클라이언트 코드 변경을 최소화할 수 있음
정리
- 인증 서버는 교체 비용이 높은 핵심 인프라인 만큼, 도입 전 라이선스 지속 가능성과 거버넌스 구조를 반드시 검토해야 한다.
- Java 생태계에서는 Keycloak 또는 Spring Authorization Server가 자체 호스팅 기반의 현실적인 대안이며, 비용 예측 가능성 측면에서 SaaS보다 유리한 경우가 많다.
- 어떤 인증 서버를 선택하든 OAuth 2.0 / OIDC 표준을 준수하는 방식으로 통합하면 향후 교체 리스크를 크게 줄일 수 있다.