IdentityServer4 상용화가 던진 경고: 인증 인프라의 라이선스 리스크
2022년 12월, .NET 생태계에서 사실상 표준 인증 프레임워크로 자리잡았던 IdentityServer4가 Duende Software에 의해 상용 라이선스로 전환되었다. 연간 수천 달러에 달하는 라이선스 비용이 부과되면서 오픈소스로 무료 사용하던 수많은 개발팀이 갑작스러운 비용 부담과 마주하게 됐다. 이 사건은 단순히 .NET 진영의 이슈가 아니다. 특정 오픈소스 인증 솔루션에 아키텍처를 깊게 의존했을 때 어떤 리스크가 발생하는지를 Java 백엔드 개발자에게도 명확히 보여주는 사례다.
인증 인프라, 왜 라이선스 리스크를 따져야 하는가
인증·인가 계층은 시스템의 가장 깊은 곳에 위치한다. OAuth2, OIDC 서버를 특정 라이브러리나 솔루션에 결합시키면, 나중에 교체하는 비용은 단순한 의존성 교체를 훨씬 넘어선다. 토큰 발급 정책, 클라이언트 등록 방식, 세션 관리, 커스텀 클레임 로직까지 모두 해당 솔루션의 추상화에 녹아들기 때문이다.
IdentityServer4 사태의 핵심 교훈은 "현재 무료"라는 조건이 미래에도 유지된다는 보장이 없다는 점이다. 특히 소수의 회사가 관리하는 프로젝트일수록 상용화, 개발 중단, 포크 분열 등의 리스크가 존재한다. 실무에서는 다음 기준을 함께 검토해야 한다.
- 거버넌스 구조: Apache, CNCF 등 재단 주도 프로젝트인가, 단일 기업 주도인가
- 라이선스 종류: Apache 2.0, MIT처럼 상업적 사용에 제한이 없는가
- 커뮤니티 규모: 포크 및 대안이 충분히 존재하는가
- 상용 지원 분리 여부: 오픈소스 코어와 엔터프라이즈 기능이 명확히 분리되어 있는가
Java 생태계에서의 현실적인 대안 점검
Java 백엔드 개발자라면 인증 서버 선택지로 주로 Keycloak, Spring Authorization Server, Authelia 등을 고려한다. 이 중 Keycloak은 Red Hat(IBM)이 지원하는 CNCF 연계 프로젝트로, 거버넌스 안정성이 높다. Spring Authorization Server는 Spring 공식 프로젝트로 편입되어 있어 Spring Boot 생태계와 통합이 자연스럽다.
// 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);
}
직접 구축이 부담스럽다면 관리형 서비스(Auth0, AWS Cognito 등)를 선택하는 팀도 많다. 다만 이 경우에도 벤더 종속성 문제는 다른 형태로 남는다. 중요한 것은 선택 시점에 "이탈 비용(exit cost)"을 명확히 계산해두는 것이다.
정리
- 오픈소스 인증 솔루션 선택 시 라이선스 구조와 거버넌스 주체를 반드시 검토해야 한다
- 인증 인프라는 교체 비용이 높으므로, 초기 아키텍처 결정 단계에서 벤더 종속 리스크를 평가해야 한다
- Java 생태계에서는 Keycloak, Spring Authorization Server처럼 재단 또는 공식 프로젝트 기반의 선택지를 우선 검토하는 것이 안전하다