플랫폼 빌딩 블록: Dapr·cert-manager·Backstage (JVM에서 본 클라우드 네이티브 9)

8부까지 오면 한 서비스를 배포하고, 관측하고, 메시로 잇고, 스케일하는 도구가 다 모인다. 그런데 서비스가 수십 개가 되면 새로운 종류의 문제가 생긴다. 모든 서비스가 Kafka 클라이언트를, Redis 클라이언트를, 시크릿 로딩 코드를 각자 품는다. TLS 인증서는 만료 때마다 누가 갱신하는지 아무도 모른다. 새 서비스를 만들 때마다 보일러플레이트를 복붙한다.

이 “서비스가 많아져서 생기는” 문제들을 세 프로젝트가 각자 다룬다. Dapr, cert-manager, Backstage다.

Dapr: 분산 시스템 기본기를 사이드카로

마이크로서비스가 반복해서 다시 짜는 코드가 있다. pub/sub 발행·구독, 상태 저장, 시크릿 읽기, 다른 서비스 호출. 언어마다, 서비스마다 각 브로커·스토어의 SDK를 임베드한다. Kafka 바꾸면 전부 고친다.

Dapr는 이걸 사이드카로 뺀다. 빌딩 블록이라 부르는 API 묶음을 사이드카가 제공하고, 앱은 그걸 localhost로 부른다. 서비스 호출, pub/sub, 상태 관리, 바인딩, 시크릿, 액터 등 열두 가지가 HTTP나 gRPC API로 노출된다. 앱은 Kafka를 모른다. Dapr 사이드카에 “이 토픽에 발행해줘”라고 할 뿐이고, 뒤에 Kafka가 있는지 Redis가 있는지는 Dapr 컴포넌트 설정이 정한다. 7부 서비스 메시가 네트워크 관심사를 사이드카로 뺐다면, Dapr는 애플리케이션 레벨 관심사를 사이드카로 뺀다.

Spring 개발자에게 반가운 건 공식 통합이 있다는 점이다. io.dapr.spring:dapr-spring-boot-starter가 Dapr 호출을 친숙한 Spring 추상으로 감싼다.

implementation("io.dapr.spring:dapr-spring-boot-starter")build.gradle.kts

pub/sub은 DaprMessagingTemplate, 상태 저장은 Spring Data의 KeyValueTemplate·CrudRepository로 쓴다. 브로커 SDK를 직접 다루는 대신 Spring 관용구로 분산 기본기를 쓰는 셈이다. 다만 이 Spring Boot 통합은 공식이긴 해도 문서상 아직 alpha 단계라, 프로덕션 도입 전엔 성숙도를 따져봐야 한다. Dapr 자체는 2024년 11월에 CNCF를 졸업했고, 2026년 6월 현재 1.18 라인이다(이 릴리스의 워크플로 검증 기능은 상용 벤더 Diagrid가 기여했다).

cert-manager: TLS를 자동으로

다음은 인증서다. 서비스가 많아지면 TLS 인증서 관리가 조용한 부채가 된다. 누가 발급했고 언제 만료되는지, 갱신은 누가 하는지. 깜빡하면 어느 날 인증서 만료로 장애가 난다.

cert-manager는 Kubernetes에서 인증서 발급·갱신을 자동화한다. CRD로 선언한다.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-account
    solvers:
      - http01:
          ingress:
            class: nginx
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-service-tls
spec:
  secretName: my-service-tls
  issuerRef:
    name: letsencrypt
    kind: ClusterIssuer
  dnsNames:
    - my-service.example.comcertificate.yaml

Issuer·ClusterIssuer가 인증서를 어디서 받을지(예: Let’s Encrypt ACME) 정하고, Certificate가 무엇을 발급받을지 선언한다. 만료 전 갱신도 cert-manager가 알아서 한다. Spring 서비스 입장에선 TLS·mTLS가 게이트웨이·인그레스 레벨에서 수작업 없이 붙는다. 7부에서 메시가 mTLS를 깔 때도 그 뒤에서 인증서를 대주는 게 보통 cert-manager다. 2024년 11월에 졸업했고 1.20 라인이다.

Backstage: 흩어진 서비스를 한 포털로

마지막은 사람의 문제다. 서비스가 수십 개면 “이 서비스 누가 만들었지, 문서는 어디, API는 뭐지”가 매번 수색 작업이 된다. 새 서비스를 만들 때마다 표준 구조를 처음부터 세운다.

Backstage는 개발자 포털이다. Spotify가 만들어 CNCF에 기증했다. 세 축이 있다.

• 소프트웨어 카탈로그: 모든 서비스를 한곳에 등록. 각 서비스가 catalog-info.yaml로 자신을 기술한다. 누구 소유, 어디 의존, 문서는 어디.
• 소프트웨어 템플릿(스캐폴더): 표준 구조의 새 서비스를 버튼 하나로 생성. “Spring Boot 마이크로서비스” 템플릿을 만들어두면 새 서비스가 같은 골격으로 시작한다.
• TechDocs: 코드 옆 마크다운 문서를 포털에서 렌더링.

Spring 서비스가 많은 조직이라면, Backstage 카탈로그에 서비스를 등록하고 표준 Spring Boot 템플릿으로 새 서비스를 찍어내는 흐름이 보일러플레이트와 수색 작업을 같이 줄인다.

정리

세 도구는 “서비스가 많아져서” 생기는 서로 다른 문제를 푼다. Dapr는 반복되는 분산 기본기를 사이드카로 빼고(Spring은 공식 스타터로 받는다), cert-manager는 TLS 발급·갱신을 자동화하며, Backstage는 흩어진 서비스를 한 포털로 묶는다. 성숙도는 Dapr·cert-manager가 Graduated, Backstage가 Incubating이다.

여기까지가 1부에서 그린 다섯 층, 배포·관측·메시·스케일·플랫폼이다. 마지막 10부는 이 지도 전체가 2026년에 놓인 더 큰 맥락, AI 워크로드의 시대로 한 발 물러선다. 그 인프라 위에서 JVM은 어디에 서는지로 시리즈를 닫는다.

참고

• Building Blocks — Dapr Docs
• Dapr Spring Boot Integration
• cert-manager Documentation
• Backstage — CNCF Project
• Backstage Software Catalog