Spring에 적용하는 gRPC 라이브러리 비교

Spring 환경에 gRPC를 적용하는 방법은 크게 2가지 라이브러리에 대해서 알아 본다.
Tags:

개요

Spring 환경에 gRPC를 적용하는 방법은 크게 2가지 라이브러리가 있다.

  • net.devh:grpc-server-spring-boot-starter
  • org.springframewor.grpc:spring-grpc-spring-boot-starter

두 라이브러리는 Spring 환경에 gRPC를 붙인다는 점에서는 비슷하지만, 출신·철학·설계·지원 방식·미래성이 크게 다르다.

본인의 프로젝트 어떤 라이브러리를 적용해야 할지 비교 내용을 확인하고 선택하길 바란다.

라이브러리 비교

항목 net.devh:grpc-server-spring-boot-starter org.springframework.grpc:spring-grpc-spring-boot-starter
출처 커뮤니티/오픈소스 (3rd-party) Spring 공식 프로젝트 (Spring Team이 개발)
안정성 오랫동안 널리 사용됨 아직 초기(1.0 전후), 빠르게 발전 중
최신성 Spring Boot 3, Native 지원 부족 Spring Boot 3 / AOT / Native 완전 지원
아키텍처 gRPC 서버/클라이언트 Wrapping 중심 Spring 관점의 신규 gRPC 추상화 제공
의존성 구조 netty 기반의 직접 gRPC 통합 Spring Framework 6 기반 추상화 + AutoConfig
클라이언트 방식 직접 Stub 생성 + annotation 기반 주입 채널 팩토리 기반, Spring Bean 방식
확장성 Interceptor 등 기존 방식 고착 Spring 생태계에 맞춘 고급 확장 기능 가능
장기적 미래 유지보수는 하지만 성장 둔화 Spring 공식 표준으로 자리잡을 가능성 높음

출신과 배경

net.devh (전통적인 방식)

  • 커뮤니티에서 오래전부터 만들어진 3rd-party 외부 라이브러리
  • Spring Boot 1.x ~ 2.x 시절부터 gRPC를 쉽게 붙이기 위해 시작됨
  • 기업에서 꽤 많이 사용했고, 안정성이 높음
  • 하지만 Spring 팀이 만든 게 아님
  • 최근에는 “유지보수는 하지만 새로운 기능은 적음”

Spring gRPC (신규, 공식)

  • Spring 프로젝트 공식 gRPC 지원
  • Spring Framework 6 / Boot 3 에 맞춰 새롭게 설계됨
  • Spring 팀이 직접 관리하는 미래 지향 프로젝트
  • AOT, Native Image, Observability 등 Spring 생태계와 완전 호환

설계 철학 및 아키텍처 차이

net.devh

  • gRPC의 원래 Netty 기반 서버를 Spring 방식으로 감싼 것
  • @GrpcService, @GrpcClient 등을 제공
  • Stub이나 Channel을 직접 관리하는 형태
  • 확장성은 있지만 Spring스럽지 않은 부분이 많음
  • “Spring 애플리케이션 안에 gRPC를 집어넣는다"는 느낌

Spring gRPC

  • gRPC 기능을 Spring Framework의 개념 안으로 재해석
  • 채널 추상화, 서버 추상화, Bean 구성까지 Spring 방식으로 설계
  • gRPC = Spring의 1급 지원 기능으로 편입
  • net.devh처럼 그냥 Wrapping한 것이 아님
  • Spring AOT(Native), GraalVM, Observability(Micrometer)와 함께 동작하도록 설계

→ 즉, 단순 통합이 아니라 “Spring스러운 gRPC 구현체"라고 보면 됨.

사용 방식 비교

net.devh

서비스 등록

@GrpcService
public class HelloServiceImpl extends HelloServiceGrpc.HelloServiceImplBase { ... }

클라이언트 주입

@GrpcClient("myService")
private HelloServiceGrpc.HelloServiceBlockingStub stub;
  • Stub은 자동 주입되지만 내부 구현이 다소 난해
  • 클라이언트 채널 관리가 덜 투명함

Spring gRPC

서비스 등록 → BindableService 빈을 등록하면 자동 인식

@Service
class HelloServiceImpl : HelloServiceGrpcKt.HelloServiceCoroutineImplBase()

클라이언트 생성 → 채널 팩토리로 gRPC 채널을 만들고 Stub 직접 주입

@Bean
fun helloStub(factory: GrpcChannelFactory) =
    HelloServiceGrpcKt.HelloServiceCoroutineStub(factory.createChannel("local"))
  • Spring Bean 시스템에 완전히 통합된 API
  • Spring Cloud LoadBalancer, Metrics, AOT 등과 자연스럽게 동작

성숙도 및 실제 운영에서의 평가

항목 net.devh spring-grpc
성숙도 매우 높음 아직 초기
대기업 실제 사용 많음 점점 증가 중
Spring Boot 3 / AOT 일부 제한적 완전 지원
문서 GitHub 위키 중심 Spring 공식 문서 시스템
확장성 기존 gRPC 방식 그대로 Spring-native 확장 가능

어떤 걸 선택해야 하나?

즉시 안정성이 중요하면 → net.devh 추천

  • 기존 기업 레거시/대규모 프로젝트 호환성 최고
  • 문서 많고 예제 많음
  • 이미 검증된 방식

장기적으로 최신 Spring 기술을 쓴다면 → Spring gRPC 추천

  • Spring Boot 3.x / Spring 6.x 와 최적화됨
  • 공식이기 때문에 Spring 에코시스템과 긴밀하게 진화
  • AOT + GraalVM Native Image 최적

절대로 섞어쓰면 안 됨

두 라이브러리는 내부적으로 서버 · Stub 관리 방식이 완전히 다르므로 공존이 불가능함.

결론

net.devh

  • 3rd party
  • 오래 사용됨, 안정적
  • Spring Boot 1.x~2.x 시대의 솔루션
  • 앞으로 큰 신규 기능은 기대 어려움

Spring gRPC

  • Spring 공식 프로젝트
  • Boot 3 / Spring 6 / Native / Observability 등 현대적 기능 지원
  • 향후 Spring 진영의 표준 gRPC 솔루션이 될 가능성이 큼