첫날 키노트 후반부입니다. 앞 글에서 AI 워크로드가 부딪히는 자원의 한계를 다뤘다면, 이번에는 실제로 Kubernetes 위에 AI 플랫폼과 대규모 인프라를 올린 사례 네 편을 정리합니다. 두 개씩 짝지어 읽으면 흐름이 잘 보입니다. 앞의 둘은 AI 플랫폼, 뒤의 둘은 선언적 대규모 운영입니다.🧬 왜 멀티테넌시인가 : Preferred NetworksBuilding a Multi-Tenant AI Platform with the CNCF Ecosystem — Aya Igarashi (Preferred Networks) 10분을 받은 이 발표가 첫날 키노트 중 밀도가 가장 높았습니다. 발표자는 2016년부터 Kubernetes를 썼다고 합니다. 당시는 IaC 전환과 마이크로서비스가 화두였고 선언적 배포..

업로드된 이미지를 Cloudinary(미디어 서버)에 전송하고, AI(Gemini API)로 분석하는 작업은 네트워크 상황에 따라 2~5초가량 소요됩니다. 유저를 멍하니 5초 동안 멈춰둔 채 기다리게 할 수 없어, 응답성을 높이고자 로직을 Spring @Async를 활용해 비동기로 분리하려다 영속성 컨텍스트 지옥에 빠진 트러블슈팅 경험입니다.1. 섣부른 비동기 처리의 시도요청이 오면 "업로드 대기열에 등록되었습니다"라는 성공 응답을 클라이언트에 0.1초 만에 내려주고, 무거운 작업은 백그라운드 스레드에 던져버리도록 설계했습니다.// ❌ 처음 시도한 코드 (에러 발생)@Async // 새로운 백그라운드 스레드풀에서 실행public void processUploadAsync(User user, byte[] ..

참관 후기와 현장에서 만난 사람들 이야기에 이어, 이제 세션 리뷰를 시작합니다. 첫날 키노트는 9시 30분 오프닝부터 10시 25분 클로징까지 약 한 시간 동안 일곱 개 발표가 숨 가쁘게 이어졌습니다. 3분짜리 라이트닝 형식이 대부분이라 개별로 나누기보다 주제별로 묶어 읽는 편이 낫다고 판단했고, 두 편으로 나눠 정리합니다. 이번 글에서는 오프닝 키노트와 "자원의 한계"를 다룬 두 발표를 다룹니다.🎤 오프닝 : "Keep Cloud Native Moving"Linux Foundation의 Jonathan Bryce(Executive Director)와 Chris Aniszczyk(CTO)가 25분을 채웠습니다. Aniszczyk가 정리한 CNCF 현황 중 눈에 띈 숫자입니다.지난 6개월 사이 생태계 개..

이번 글에서는 K8s 내부에 제로 트러스트(Zero Trust) 보안 모델을 구축하기 위한 Network Policy와 RBAC을 다룹니다.1. 기본값은 "모두 허용": K8s 네트워크의 위험한 출발점K8s의 기본 네트워크 설정은 모든 Pod 간 통신을 허용합니다. 같은 클러스터에 있는 프론트엔드 Pod, 백엔드 Pod, 데이터베이스 Pod가 서로 아무런 제약 없이 접근할 수 있습니다. 이는 개발 초기에는 편리하지만, 프로덕션 환경에서는 치명적인 보안 취약점입니다.프론트엔드 Pod가 해킹당하면 DB Pod에 직접 접근 가능관련 없는 네임스페이스의 Pod끼리도 자유롭게 통신2. Network Policy: Pod 간 방화벽Network Policy는 K8s에서 Pod 간의 트래픽을 제어하는 방화벽 규칙입니..

유저가 사진을 촬영하고 업로드할 때, 백엔드에서는 크게 2가지 무거운 작업이 일어납니다.Cloudinary 서버로 원본 이미지 전송 (수 초 소요)GPS 위경도를 한글 지명으로 변환하는 Reverse Geocoding API 호출 (수 초 소요)이 두 가지 작업을 순차적으로 실행하면 유저는 화면이 멈춘 채로 10초 가까이 기다려야 합니다. 이를 해결하기 위해 자바의 CompletableFuture를 도입한 경험입니다.1. 기존 방식의 문제점 (순차 실행) I/O 바운드 작업들이 직렬로 연결되어 유저 경험(UX)을 심각하게 훼손하고 있었습니다. // 기존의 느린 코드 (직렬 실행)String imageUrl = cloudinaryClient.upload(request.file().getBytes()); /..

이번 글에서는 K8s 내부 네트워킹의 심장부인 kube-proxy가 대규모 환경에서 어떤 한계에 부딪히는지 살펴보고, 이를 근본적으로 해결하는 eBPF 기반의 Cilium이 왜 차세대 K8s 네트워크 표준으로 떠오르고 있는지 알아봅니다.1. kube-proxy와 iptables의 한계K8s에서 Service로 트래픽을 보내면, 실제로는 각 노드에서 실행 중인 kube-proxy가 트래픽을 적절한 Pod로 전달합니다. 전통적으로 kube-proxy는 iptables 규칙을 사용합니다. 문제는 규모가 커지면 iptables 규칙이 선형으로 급증한다는 것입니다.Service 1,000개 × 각 Service당 Pod 10개 = iptables 규칙 수만 개패킷 하나가 도착할 때마다 이 규칙들을 순차적으로(O(..

지난 참관 후기에서 예고했던 이야기를 풀 차례입니다. 이번 KubeCon + CloudNativeCon Japan 2026에서 세션만큼이나, 어쩌면 세션보다 더 기억에 남는 건 사람들이었습니다. sysdig 부스에서 만난 한국인 엔지니어, Grafana 부스의 Alloy 개발자, 그리고 Java Champion 살라보이(Salaboy)까지 세 번의 만남을 기록합니다.1️⃣ sysdig 부스에서 만난 한국인 엔지니어 : "이제는 CNAPP의 시대""Runtime security for AI coding agents"를 내건 sysdig 부스에서 뜻밖에 한국인 엔지니어를 만났습니다. 한국어로 편하게 Falco와 Prempti에 대한 설명을 들을 수 있었는데, 특히 인상 깊었던 건 이 말이었습니다. "AI 시..