CNCF와 클라우드 네이티브란 무엇인가: Spring 개발자를 위한 표준 지도 (Spring 개발자를 위한 클라우드 표준 1)

Spring Boot 애플리케이션을 Kubernetes 클러스터로 옮기는 순간, jar 파일 하나만 잘 챙긴다고 끝나지 않는다. Kubernetes, Helm, Prometheus, Grafana, Loki, OpenTelemetry, Istio, Argo, KEDA, cert-manager 같은 이름이 한꺼번에 쏟아진다. 이 도구들이 각각 무엇을 위한 것인지 구분도 서지 않은 채로 이름부터 마주치니, 어느 것부터 봐야 하는지 판단이 서지 않는다.

이 이름들은 흩어진 유행어가 아니다. 서버 한 대에서는 드러나지 않던 문제마다 붙은 표준 도구 이름이다.

이 시리즈는 Spring 애플리케이션 하나를 프로덕션 클러스터까지 끌고 가면서 순서대로 마주치는 문제와 그 문제를 푸는 표준 도구를 다룬다. 1편은 그 지도부터 그린다.

왜 갑자기 이 많은 이름이 필요해졌나

서버 한 대에 올리던 시절엔 이런 이름들이 필요 없었다. WAR를 톰캣에 얹고, 로그는 파일로 남기고, 모니터링은 서버 CPU 그래프 하나면 충분했다. 헬스체크? 프로세스가 살아 있으면 됐다. 서비스 간 통신? 같은 JVM 안이거나, 잘해야 옆 서버로 HTTP 한 번 쏘는 정도였다.

앱을 여러 개의 파드로 쪼개서 클러스터에 뿌리는 순간, 그 한 대가 조용히 해주던 일들이 전부 밖으로 튀어나온다.

프로세스가 살아 있는 것과 요청을 받을 준비가 된 것이 다른 문제가 된다. 그래서 헬스체크를 누가 어떻게 하느냐를 정해야 한다. 로그는 더 이상 한 파일에 안 쌓이고 파드 수만큼 흩어지므로, 모아서 검색할 무언가가 필요하다. 파드가 언제든 죽고 새로 뜨니, 메트릭을 밖으로 계속 내보내지 않으면 죽은 파드의 상태는 영영 못 본다. 서비스가 여러 개로 갈라지면 그 사이 트래픽을 누가 암호화하고 재시도하고 나눠 보낼지가 새 숙제가 된다.

낯선 이름 하나하나는 이 새 숙제 하나하나에 대한 답이다. Kubernetes는 “파드를 어디에 어떻게 띄울까”, Prometheus는 “흩어진 메트릭을 어떻게 긁어올까”, OpenTelemetry는 “트레이스와 메트릭을 무슨 규격으로 내보낼까”, Istio는 “서비스 사이 트래픽을 코드 안 건드리고 어떻게 다룰까”에 대한 답이다. 문제를 모르는 채 도구 이름만 들으면 폭격이지만, 문제를 먼저 보면 하나씩 자리를 찾는다.

이 이름들이 왜 한 재단에 모였나

여기서 CNCF가 나온다. 다만 주인공은 아니다.

CNCF(Cloud Native Computing Foundation)는 Linux Foundation 산하의 벤더 중립 오픈소스 재단이다. 재단 스스로는 “글로벌 기술 인프라의 핵심 컴포넌트를 호스팅한다”고 소개한다. 쉽게 말하면, 위에서 열거한 문제들을 푸는 오픈소스 프로젝트가 특정 회사에 종속되지 않고 공용 표준으로 자라도록 모아두는 곳이다. Kubernetes, Prometheus, Envoy가 여기서 컸다.

이 재단을 굳이 알아야 하는 이유는 재단 자체가 대단해서가 아니라, 클라우드에서 만나는 도구 대부분이 결국 이 우산 아래 있기 때문이다. 어느 클라우드를 쓰든, 어느 회사를 다니든, 배포는 Kubernetes고 메트릭은 Prometheus다. 벤더 중립이라 한 회사가 마음대로 갈아엎을 수 없고, 그래서 실무 표준이 된다. CNCF는 그 표준이 모이고 검증되는 장소일 뿐이다. 이 시리즈는 재단 조직도나 프로젝트 등급표를 외우게 하지 않는다. 참고로 프로덕션 검증이 끝난 Graduated 등급이 지금 36개쯤 되는데, 그중 Spring 워크로드에 실제로 손이 닿는 건 한 줌이다. 그 한 줌만 순서대로 만난다.

이미 아는 Spring과 어떻게 이어지나

다행인 건, 이 낯선 이름들이 완전히 새 개념을 요구하지 않는다는 점이다. 대부분 Spring에서 이미 하던 일이 인프라 층으로 자리를 옮긴 것에 가깝다.

로깅부터 그렇다. Logback으로 파일에 남기던 로그는, 클러스터에선 표준 출력으로 뱉고 수집기가 모아 검색 가능한 저장소에 쌓는다. 하던 일은 같고 목적지만 바뀐다. 설정도 그렇다. application.yml과 프로파일로 환경을 가르던 걸, ConfigMap과 Secret이라는 클러스터 리소스가 이어받는다. 패키징은 bootJar로 실행 가능한 jar를 만들던 흐름이 컨테이너 이미지를 굽는 단계로 한 겹 확장된다. 마이크로서비스도 마찬가지다. Spring Cloud로 서비스 디스커버리와 회로 차단기를 코드에 박던 일의 상당 부분을, 서비스 메시가 사이드카에서 대신 처리한다.

관측성은 가장 깔끔하게 이어지는 지점이다. Spring Boot 3의 Observability는 OpenTelemetry 규격에 직접 물리도록 설계돼 있어서, Micrometer가 노출한 메트릭을 Prometheus가 긁어가고 트레이스는 OTLP로 흘려보낸다. 새로 배우는 게 아니라, Actuator에서 이미 켜던 스위치가 클러스터 밖의 표준과 맞물리는 것이다.

물론 이어지기만 하고 끝나면 시리즈가 필요 없다. JVM은 다른 런타임이 안 겪는 마찰을 여기서 따로 겪는다. 컨테이너 메모리 limit과 힙 크기가 어긋나 파드가 OOM으로 죽고, Knative로 scale-to-zero를 하면 JVM 기동 몇 초가 그대로 첫 요청 지연이 된다. 매 편이 같은 질문을 던진다. 이 표준 도구가 Spring 워크로드에 닿을 때 무엇이 달라지는가.

시리즈 로드맵: 고통이 이어지는 순서로

이 시리즈는 프로젝트를 알파벳 순이나 등급 순으로 나열하지 않는다. Spring 앱을 클라우드에 올리다 보면 문제가 문제를 부른다. 앞 편에서 해결한 일이 다음 편의 새 고통을 만든다. 그 연쇄를 그대로 목차로 삼았다.

1. (이 글) 지도: 낯선 이름들이 왜 쏟아지고, 왜 한 재단에 모였고, Spring과 어떻게 잇는가
2. 올리기: 컨테이너 이미지를 굽고 Kubernetes에 파드로 띄운다. 그런데 메모리 limit과 JVM 힙이 어긋난다
3. 로그가 흩어진다: 파드 수만큼 흩어진 로그를 구조화 로깅과 Loki로 다시 한곳에 모은다
4. 상태가 안 보인다: Prometheus로 메트릭을 긁고 Grafana로 본다. Actuator가 뱉던 숫자가 대시보드가 된다
5. 요청이 경계를 넘는다: 서비스가 갈라지자 요청 하나가 여러 파드를 통과한다. 분산 추적과 OpenTelemetry로 흐름을 잇는다
6. 트래픽을 누가 지키나: mTLS, 재시도, 트래픽 분할을 코드 밖 서비스 메시로 내린다
7. 부하가 오르내린다: KEDA 이벤트 오토스케일과 Knative scale-to-zero, 그리고 JVM 콜드 스타트라는 정면 충돌
8. 배포를 손으로 못 한다: GitOps로 Git 저장소를 배포 상태의 단일 근원으로 삼는다
9. 플랫폼으로 묶는다: Dapr 사이드카, cert-manager TLS 자동화, Backstage 개발자 포털
10. AI가 옆에 온다: 같은 클러스터에 AI 워크로드가 붙을 때 Spring 서비스가 서는 자리

각 편은 표준 도구의 원래 목적을 짧게 깔고, Spring 워크로드에 닿을 때 부딪히는 지점에 분량을 쓴다. 일반론은 이미 인터넷에 넘친다. 이 시리즈가 채우려는 건 JVM이 실제로 걸려 넘어지는 자리다.

다음 편

지도만으로는 아무것도 배포되지 않는다. 다음 편은 이미지를 굽고 파드로 띄우는 첫 관문과, 컨테이너 메모리 limit과 JVM 힙이 어긋나는 첫 사고(OOMKilled)를 다룬다.

참고

• CNCF: Who We Are
• CNCF Projects
• 2025 CNCF Annual Cloud Native Survey
• Spring Boot Observability
• Grafana LGTM Stack