[Community] Cloud Native Korea Community Day 2025 후기

Cloud Native Korea Community Day 2025에 참여한 세션과 후기를 정리했습니다.

[Community] Cloud Native Korea Community Day 2025 후기
Photo by Alexandre Pellaes / Unsplash

개요

2025.09.16일Cloud Native Korea Community Day 2025에 참여하고 작성했습니다.

Cloud Native Korea Community Day 2025
Cloud Native Korea Community Day 2025, Kubernetes와 CNCF 프로젝트를 아우르는 대규모 기술 행사가 여러분을 기다립니다!
Notion Image

세션 정리

오전 세션

오전 세션은 스폰서 기업에서 발표를 진행하였습니다.

  • Tech FOMO 클라우드 네이티브로 승화 방법
  • AWS & GenAI로 실현하는 비즈니스 트랜스포메이션
  • FinOps 없이는 못 살아, Kubernetes 비용 절감
  • AI 시대의 관문: F5 AI Gateway로 여는 안전한 혁신

잘 변하지 않을 기초와 트렌드 파악과 AWS의 AI First 전략을 확인할 수 있었습니다. kubecost를 통해 Network 비용까지 추적할 수 있다는 걸 확인했습니다. EKS 노드를 AZ간 병렬 연결하여 모델 훈련시 과도한 비용이 청구된 것을 몇 번 확인했던지라 k8s 환경에서 비용을 추적하기 좋은 방안이라고 생각했습니다.

마지막으로 OpenAI의 GPT OSS 모델이 등장하며 다양한 솔루션이 재편되는 것까지 확인하며 앞으로의 목표를 다듬게 되었습니다.

오후 세션

간단하게 식사 후 쭉 이어지는 세션에 참가했습니다.

저는 AI를 활용하는 다양한 아이디어를 얻기 위해 참가했고 Cloud Native 솔루션보단 AI를 어떻게 구성하고 활용하는지에 집중했습니다.


그렇게 첫 번째 세션은 다음과 같습니다.

  • 수천 명의 개발자를 위한 내부 DevOps 플랫폼: CI/CD부터 DevSecOps까지

활용 목적, 숙련도에 따라 C-DEP, P-DEP, A-Hub 플랫폼으로 구분하며 운영 중 이라는 것을 확인했습니다. Jenkins, k8s 등으로 쉽게 빌드, 배포할 수 있도록 구성했다는 점. AI 기반의 운영 보조를 수행한다는 점을 확인했습니다.

많은 개발자를 지원하기 위해 트러블 슈팅했던 경험을 공유해주셨고 표준 방법론을 알 수 있었습니다.

두 번째 세션은 다음과 같습니다.

  • k8s에서 Claude Code로 구현하는 Agentic AI: 프로덕션 레디 아키텍처와 실전 활용

AI 도구들이 소수 정예 팀으로 개발되고 유니콘급 매출을 달성한다는 점을 확인했습니다. 동시에 사내에선 생산성을 극대화를 위해 AI를 다양한 곳에 적극 활용하고 있다는 점이 인상깊었습니다.

저도 AI 도입의 시행착오를 겪고있는 만큼 다양한 시도와 경험들이 앞으로 공유되길 바라고 있습니다.

세 번째 세션은 다음과 같습니다.

  • 클라우드 수요 예측을 위한 시계열 AI 파이프라인 구축기: 실험에서 전략까지

GenAI가 아니더라도 ML/DL을 기반의 추론과 AI를 통한 설명 가능성을 추가한 것이 인상싶었습니다. 특히 비즈니스와 모델을 사용한 목적, 선택 이유와 과정까지 발표해주셨던 점이 인상깊었습니다.

서비스를 운영하는데 있어 도입 과정을 살펴볼 수 있어 좋았습니다. 제일 중요했던건 AI 서비스를 개발하며 고민했던 데이터 통합 관점을 다시 한번 생각해볼 수 있게 되어 개인적으로 매우 만족했던 세션이었습니다.

네 번째 세션은 다음과 같습니다.

  • Vibe Coding with Maps

구글에서 바이브코딩 활용 사례를 공유해주셨습니다.

기존의 사용 사례들과 문제점과 실서비스에 상용화하기엔 다소 어려움이 존재했던 이유를 알게되었습니다.
특히 바이브 코딩을 위한 3가지 규칙 중 대중적이고 단순한 기술을 사용할 것과 Git(생성과 삭제를 위함) Product Manager의 역할을 수행해야한다는 점은 AI 기반 프로젝트를 수행하며 느낀 점과 동일하여 매우 공감했습니다.

뿐만 아니라 최소 단위 설계, Raw한 문서가 아닌 실제 동작하는 큐레이션 코드, 엄격한 markdown 파일 관리는 반복적인 프로젝트에 있어 필수라는 걸 깨달았습니다.

CLAUDE.md 이렇게 쓰면 정말 편합니다 | 요즘IT
클로드 코드 새 세션마다 맥락 설명을 하던 어느 날, 우연히 CLAUDE.md를 알게 되고 더 이상 반복 설명하지 않아도 내 오랜 동료처럼 작업하게 할 수 있단 걸 알게 됐습니다. CLAUDE.md는 프로젝트의 기술 스택, 개발 규칙, 워크플로우, 특별 주의사항을 정리해두는 ‘프로젝트 설명서’로, 클로드가 자동으로 읽고 이해합니다. 한 번만 작성해두면 세션을 새로 열어도, 브랜치를 바꿔도, 팀원이 프로젝트를 클론해도 일관된 컨텍스트가 유지됩니다. 계층 구조 활용으로 컨텍스트를 상황별로 전환하고, 클로드에게 직접 CLAUDE.md 작성을 맡겨 효율성과 일관성을 극대화할 수 있었죠. 이 글에서는 요즘IT 실제 프로젝트에서 CLAUDE.md를 활용하는 방법을 중심으로 CLAUDE.md에 무엇을 담아야 하는지, 특별 주의사항을 어떻게 활용할지, 계층 구조를 통한 효율적 운영법, 그리고 클로드에게 직접 작성·개선을 맡기는 방법까지 다룹니다.

다섯 번째 세션은 다음과 같습니다.

  • 로컬 컨테이너 환경에서 지능형 앱에 LLM을 오케스트레이션 할 수 있는 3가지 방법

Ollama만 사용해보며 오픈소스 모델을 테스트해봤는데 다양한 앱이 존재한다는 것을 확인했습니다. 특히 로컬 배포를 클라우드 연동하는 것을 보며 보안, 비용 문제 등 앞으로 좋은 대안이 될 수 있다는 것을 확인했습니다.

GitHub - aliencube/open-chat-playground: Open Chat Playground (OCP) is a web UI that is able to connect virtually any LLM from any platform.
Open Chat Playground (OCP) is a web UI that is able to connect virtually any LLM from any platform. - aliencube/open-chat-playground
GitHub - devkimchi/meai-for-local-llms: This provides sample codes that uses Microsoft.Extensions.AI for locally running LLMs through Docker Model Runner, Foundry Local, Hugging Face and Ollama
This provides sample codes that uses Microsoft.Extensions.AI for locally running LLMs through Docker Model Runner, Foundry Local, Hugging Face and Ollama - devkimchi/meai-for-local-llms

마지막 세션은 다음과 같습니다

  • K8S, Container 환경에서 성능 저하 없는 Model Serving 하기

HPC 환경에 대한 경험은 없다시피하여 MLOps 관점에서 들어보기 어려운 가치있는 세션을 경험했다고 느꼈습니다. 현대 컴퓨터 구조의 성능적인 문제와 이를 해결하기 위한 다양한 도구들을 알게되었습니다.

DeepSeek 모델의 구성부터 거대 모델을 운영하기 위한 다양한 개념들을 알게 되었습니다. 공유차 따로 요약하지않고 리스트 형태로 작성했습니다.

  • MLOps는 트래픽이 많지 않지만 GPU 성능에 매우 민감함.
  • GPU 플랫폼 엔지니어로써 k8s 경험을 공유
  • API로 쓸 수 있게되며 애플리케이션 개발에 집중
  • 최근 트렌드 상으로 Optimization이 극히 필요하게 됨
  • 상당히 많은 애플리케이션이 쌓여있음
  • 병렬 하드웨어와 그걸 쓸 수 있는 알고리즘
  • GPU의 태생적인 문제인 병목 현상
    • BUS간 병목과 CPU간 병목
    • CPU를 타지 않고 소통하기 위한 방법과 BUS 대역폭 확장 NVLINK
      • RDMA - Internode의 낮은 Bandwith 극복
  • MOE
  • MPI vs Distributed Shared Memory
    • NVSHMEM - GPU 메모리와 메모리를 노드 안에서 직접적으로 사용(핵심) 메모리를 공유함
      • 폰노이만 구조에서 GPU는 결국 보조장치.. CPU를 거쳐야함.
        • NVLINK 기반 GPU 간 바로 통신
  • internode 통신 누가 쓰고 누가 읽는지 메모리 맵을 매우 복잡하게 설계
  • HPC 네트워크 토폴로지 → Management N/W / High Performance N/W 분리해서 사용
    • Multus CNI로 따로 Network 구축 → NAD
    • GPUDirectRDMA 점점 더 상용화되고 있음.
    • DeepSpeed
    • NCCL, SR-IOV, Host N/W

후기

Cloud Native 주제 하에 AI 세션이 많아 좋았습니다.

특히 다양한 비즈니스 고민과 경험하기 어려운 다른 도메인은 Full Day 세션에 참여하는 이유라고 생각합니다. 앞으로는 다양한 해외 세션까지 찾아보며 다양한 인사이트를 수집하는게 목표입니다.