Ship to production 후기

Ship to production

By widehyo
Posted on April 4, 2026

CloudeBro 오픈 프로젝트 최종 발표

  • season2 5개월 진행
  • 5개의 오픈 프로젝트 발표
  • AI 도입은 빠르지만 AI를 위한 인프라 도입은 아직도 사람이 필요, 비용 소요
  • 발표 이후의 여정
    • quick start guide (각 프로젝트 설치 가이드 참가자 전원에게 발송)
    • 팔로업 & 피드백
    • 기업 PoC 연결

KubeAI

presentation

  • https://github.com/cloudbro-kube-ai/k13d
  • kubeaidashboard: AI 채팅으로 관리하는 K8S 대시보드
    • upstage 근무 중
  • 명령어 대신 자연어를 통해 ai로 kubectl 실행을 맡기고 결과를 분석해 사용접근성 확보
  • 기존 프로젝트(kubectl-ai), 대시보드 통합기능은 없었음
  • 아키텍처에서 신경쓴 부분: k9s처럼 single binary로 실행가능하는데 신경을 많이 씀
  • 구성
    • web ui
    • ai assistant (모델은 upstage solr 이용했음. 다른 상용 ai 도 사용 가능, ollma 연동도 가능)
    • 승인 감사 기능: kube cli를 누가 언제 했는지 로깅, reject / approve 기능
    • llm, mcp 설정
    • metric 연동 가능(promethues 등)
    • admin: 전용 도메인을 만들어서 admin이 권한별로 관리 등
    • keyboard shortcuts 각 항목 단축키 가능
  • 실제 운영을 해보니까 웹 UI를 사용은 어려웠음
  • 그래서 TUI를 제공함(like k9s)

Q&A

  • 자연어 질의 ai 모델 연동 보안이슈? sqlite3에 token을 암호화 해서 저장
  • 환각정도와 성능? 벤치마킹 있음. docs 참고
  • 메모리 관리? web ui는 세션스토리지, tui는 메모리상에 context를 보관함
  • llm이 관여할 수 있는 범위와 관한 제어? kubeconfig.conf 이용
  • claude code, kiro-cli 대비 핵심 차별점?
  • 고가용성? docker와 helm차트는 제공하나 고가용성은 아직 고려 안했음
  • AI 모델별 차이점? 자체 테스트 결과 25B 이상이어야 쓸만했음. embedding을 이용해도 성능이 좋지 않았음

HoneyBeePF

presentation

  • 모든 토큰을 추적하고 모든 유출을 막는다
  • 미션: llm 사용을
    • 관측가능하게
    • 통제 가능하게
    • 안전하게
  • llm api에 관련된 4가지 subject
    • visibility
    • cost control
    • anomaly detection
    • security risk

  • 모니터링기능을 모든 프로젝트에 일일히 넣어야 함

  • 커널단을 이용
    • application이 하는 모든 일은 kernel을 거침
    • kernel을 감시하는 소프트웨어
  • application의 kernel 사용하는 메시지를 캡처해 promethues에 관측값 송신
  • 단순히 ai providor 수준이 아니라 각 vendor의 모델별, 팀별, pod별 각 리소스 차원에서 관측 가능
  • 민감한 파일 접근을 kernel 레벨에서 관리하고 있음 -> 보안강화

Q&A

  • 생략

Dr.Kube

presentation

  • https://github.com/dr-kube/dr-kube

  • gitops 원칙: 변경은 git pr로만, kubectl 직접 쓰기 금지

  • 기존 장애 대응의 한계: 끊어진 파이프라인
  • 단순한 자동화가 아니라 gitops 기반으로 일관성있고 반복가능한 관측기반 운영환경 제공
  • 장애 분석 ~ 복구 반영까지를 하나로 묶음
  • 장애알림 -> slack 통보 -> AI가 수정안을 만들고 yaml 수정, pr 생성 -> 사용자 승인
  • 문제는 모델이 아니라 운영 제어
    • 중복 알림 폭주 -> 필터링 및 쿨다운 등 6가지
  • 실무 적용 가치: 안전한 자동화 루프를 통한 MTTR 단축, 운영 피로도 감소, 변경 추적성 극대화

Q&A

  • ai 환각을 줄이기 위해 langgraph를 튜닝하였는지? 튜닝 안함. kodex 5.3, gemini 3.0 사용함. 메인 기능에 집중하기 위해 배제함
  • 잘못된 코드를 생성하는 등의 문제(문법은 가능하지만 지원하지 않는 옵션 적용 등)? default yaml을 이용해 제어 기대
  • 검증단계에서 정상 상태로 판단하는 기준(사내 운영 표준 및 보안 문제 검증)? 저희도 문제 있다고 생각함. humain in the loop 등 향후 보완 계획.

Gopedia

presentation

  • enterprise knowledge graph platform: AI Agent를 위한 지능형 지식 신경망 인프라
  • 문제:
    • 정보 파편화 (DB, wiki, git, confluence, 사내 문서, 게시판 등)
    • 성능 충돌?
    • 키워드 검색을 넘어선 검색(문맥인지 + 관계유지)
  • 팔란티어의 온톨로지 등 여러 관련 문제점 해결을 위한 프로젝트 존재
  • 차별점: agent-first 접근방식(사람이 아닌 AI Agent를 대상), grpc를 이용한 수평확장 가능
  • 주요 용어는 나무의 용어에서 concept 따옴
  • 구조
    • Root: md, code, project source
    • account tree(stem): ingestion + RAG extended
    • hub(Rhizome): rdb, graphdb(typedb, 관계추론), vectordb(qdrant, semantic검색) 사용
    • eco(Leaf & Fruit)
  • 기술과 언어는 바뀔수 있음
  • openstack 사용함
  • 내부 구조는 파일 일기 작업에서 관련 데이터중 최소 단위를 L3, 이후 문단 문서 등 범위를 넓히는 식으로 동작
  • 고려중인 workload
    • 흩어진 사내 시스템들의 데이터 통합 + ontology 구축으로 업무맥락 이해
    • k8s 기반의 on-prem. gopedia를 구축하여 기업의 데이터 주권 강화
    • ai agent 전용 데이터 최적화로 실시간 업무 자동화 성능 툴의 극대화
      • 현재는 markdown, 폴더 단위 하위 문서 연동 기능 존재

Q&A

  • backstage와 기본 RAG와의 차별점? 지금 당장은 큰 차이가 없음. 온톨로지 등 넣으면 차후 달라질 거라 생각함
  • openstack 위에서 테스트하는 이유? 인프라에 대한 지식이 많지는 않음. 코드기반으로 관리하기 위해 openstack과 k8s를 사용함…, 팀원에게 물어 추가
  • 지식 권한관리 전략? 나중에 진행할 프로젝트에 있음. data를 넣을 때 machine id를 넣을 예정.
  • L3에서 검색이 안되면 L2 검색한다 했는데 얼마 정도의 성능저하가 생기는지? 현재 실제 문서 단위 지식은 L3에 존재함. L1은 L2의 아이디 리스트 보유, L2는 L3의 아이디 리스트 보유
  • IaC 레포 다 넣어도 잘 될지? 되는게 목적

KubeRCA

presentation

  • kubenetes root cause analysis
  • 문제
    • 수동 컨텍스트 수집
    • 지식 파편화(slack, wiki, notion 등)
    • 경험 의존적 분석(개인 경험에 강한 의존성)
    • 높은 MTTR(반복 장애도 매번 처음부터 조사하는 경우 많음)
  • 구조
    • alert -> ai agent가 k8s 상태와 관측데이터 수집 -> RCA 초안 생성(pgvector) + 각 채널(slack 등) 송신
    • 정형화된 RCA 템플릿 + pgvector 기반 top3 유사 incident 검색
  • helm 제공
  • 어떻게 했는가?
    • Istio bookinfo 구조 사용
    • Chaos Mesh 이용해서 oomkilled, crashloopbackoff 장애 유발
    • Istio fault injection -> latency 증가와 5xx 에러 주입
    • load generator -> 실제 트래픽 부하 재현
  • 생각해서 넣은 기능
    • 초기 AI의 RCA 리포트 분석과 resolved 시점에서 다시 RCA를 만들어 비교(실제 원인이 달랐던 경우)
    • RCA에 대한 코멘트 기능
  • SRE/devops 팀 타겟.

Q&A

  • jira ticket 자동화 생성 연동 로드맵 고려중인지? 좋은 의견. 고려하겠습니다
  • llm api 비용? 테스트로 했을 때 큰 비용은 없었음. 테스트 필요해 보임
  • 데모 슬랙 메시지 내용에 비즈니스 기능이 언급되면서 실제 유저가 어떤 기능에서 장애를 겪었는지 있는게 좋아보였음. 사전에 정의해둔 내용인지? 컨텍스트 제공하기 때문에 가능
  • rca 분석 ai? 정해진 loop가 있으면 타겟하는 케이스에 특화임. 처음은 처음부터 분석하도록 프롬프팅 해둠
  • 에러로그가 남지 않은 경우의 동작방식? 저도 error log에서 안나오는 경우가 있었음. describe랑 grafana등에서 확인함. kube rca에서는 종합적으로 판단해서 rca를 제공하게 되어있음
  • 감지된 원인과 해결되었을 원인이 달랐던 실제 예시? istio에서 500번을 알아내긴 하더라

프로그램

AI 에이전트 101 현실에 수렴하는 AI의 시작(닷넷데프|Microsoft MVP)

  • 현실에 수렴하는 AI에 고민해볼 필요가 있지 않겠는가
  • AI의 장단점을 고려하여 나의 상황에 맞게 잘 전달을 해 주어야 한다
  • AI가 기존 기술을 대체하는 것이 아니라, 기존 기술 위에 AI를 얹는 것
  • 연결의 이 발표는 MCP로 보고 있음
  • ai에게 resource 위치, 연결방법, cli 어떻게 쓰고 알려주면서 프롬프팅 -> 비효율
  • mcp를 연결하자 (도구의 명세와 description을 이용)
  • 이전에는 consice한 명세를 맞추어 개발해 왔지만, mcp 상단 description을 가지고 호출하게 되어있음
  • 각 기능을 MCP 서버 형태로 발전시키자
  • 요즘은 서버에 ssh로 들어가 직접설치는 잘 안함(컨테이너 기반이 일반적)
  • k8s는 선언적으로 컨테이너간 연결등을 잘 관리하는데 좋지만 무조건 도입은 지양. (docker compose는 mcp에 좋은 기반)
  • mcp
    • let’s encrypt 초단기 ssl 인증서 무료 자동발급
    • caddy: acme 기반 자동 인증서 리뉴얼
    • tailscale / netbird 사이드카: 방화벽 변겨 없이 사내 시스템고 ㅏ전구간 암호화 연결
    • oauth2: 최소권한원칙
  • ship to productiondㅢ 본질은 끊임없는 현대화
  • 과거와 단절된 혁신은 존재할 수 없음
  • ai에 경도 X -> 내가 가진 에셋을 활용하자

클라우드 네이티브 데이터베이스의 완성: 아키텍트의 플레이북 - Kubernetes 환경에서 Postgres를 구축하고 운영하기 위한 완벽한 가이드

  • k8s 사용은 일반적. DB는 어디에 띄우지? 에 대한 이야기를 해보려 함
  • 요즘은 k8s를 거의 많이 사용함.
  • DB는 stateful한 리소스. k8s로 관리 가능은 하지만 문제점
  • CNPG: CNCF 프로젝트 중 DB 프로젝트가 거의 없는데 그 중 하나(?)
    • Operator pattern
      • PVC를 각 컨테이너에 복제해서 관리하겠다…?
      • 백업은 snapshot으로
    • 접근제어 가능
    • rw session / ro session 자동분리(마스터 슬레이브 등)
    • 그래서 어떻게 동작하냐? Operator라는 pod가 떠서 관리됨
  • 해결하는 문제?
    • CNPG를 통하면 offline에서 자동화 가능
    • pod만 죽였다가 살리는 방식으로
    • 고급 운영 제어: 비용 최적화 및 디버깅 툴
      • kubectl cnpg status 등 cli도 제공
    • DBA를 따로 두는 조직은 많지 않음.
    • k8s는 개발자가 많이 씀
  • 이건 굉장히 신박한데?

Claude Code 사용기 cloud native project 생성 중

  • ai 사용에서 가장 중요한 거. 일단 비용을 써야 함
  • 고객 / 사람은 눈으로 보지 않으면 모른다
    • 사용하는 나도 그렇다
    • 계획을 만들라 하고 나도 지적질한다
  • 계획을 세우는 것은 필수이다
  • harbor의 arm 버전이 없음(bitnami 사태)
    • 그래서 folk로 사용 중
    • 주기적 folk하지만 ci/cd 에러 나옴(주로 aws 기반)
    • ai를 사용하면 기존 repo를 folk해서 사용하기 쉽다

Nullus 클릭 몇 번으로 완성하는 devops (platform engineering framework)

  • 반복적인 구축의 고통과 운영 노하우를 모아 만듦

  • platform devsecops 표준화 /자동화 할수 없을까

  • devsecops 파이프라인 구축에 주요 영향을 주는 부분
    • 폐쇄망 / 인터넷 망
    • Iaas 수준? 외부 사용 가능?
  • 3개월간 devsecops를 어떻게 쉽게 구축할 수 있는지 고민함
  • 통합 프레임워크 개발의 needs를 추출함
  • nullus := devops를 위한 devops, platform engineering framework
  • 커뮤니티의 노하우가 담긴 실용적이고 단순한 devops f/w
    • 검증된 oss 조합을 선택하고, 노코드 ui로 설정하고, 원클릭으로 k8s환경에 배포
  • 데모
  • 리소스 추천하는 부분이 중요
  • 이거 공부할 가치가 있겠다
    • 특히 best practice에 맞는 yaml 자동 관심있음
  • 공공 폐쇄망 등 인프라 제약이 있는 상태에서 reliance
  • 다 됐고, 이 커뮤니티 들어가야겠는데
  • 데모 좀 눈에 띈다 (유튜브 nullus 데뷔)
  • roadmap의 마지막은 cncf sandbox
  • 우리 아키텍처에 관심 있으려면 ddd, hexagonal arch. 이해요망

Start Faster on JVM & Spring Boot (한국스프링사용자모임)

  • JVM과 스피링 생태계가 cloud에 어떻게 대응하고 있는가
  • JIT compiler: 대포는 hotspot
    • Class Data Sharing(CDS)
      • 동일한 호스트에서 동작하는 JVM의 시작시간 / 메모리 사용량 감소 목적.
      • 했던 기록을 cds 파일에 기록해 두고 나머지는 그 파일 참조해서 달성
        • JEP310을 통해 java first party를 넘어선 third party도 지원하게 됨
        • 이후에도 JEP 341, 350 등 발전함
    • CRaC(Coordinated Restore at Checkpoint)
      • application 상태까지 체크포인트 파일로 저장하고 스냅샷으로 복원하는 기술, linux의 Checkpoint/restore in userspace (CRIU) 기반
      • 엔터프라이즈 레벨에서 사용하긴 어려운 기술. token 등이 기록됨
  • Ahead-of-Time Compiler
    • 프로그램을 실행하기 전에 바이트코드를 네이티브 머신코드로 변환하는 컴파일러
    • 단, 런타임 최적화가 이루어지지 않아서 JIT 만큼의 성능을 높이지는 않음
  • PGO(Profile-Guided Optimization: 커뮤니티 edition에서 사용 불가, 24년 이후 재배포 불가한 라이센스로 사용 자체는 가능)
    • 애플리케이션 실행 중에 특정 이벤트가 발생한 횟수를 계측하여 요약한 프로파일을 AOT Compiler에게 제공
    • 실제로 PGO를 프로덕션과 유사한 환경을 줄수록 처리량이 올라갈 수 있으나, OOM, GC 문제도 있음
  • Project Leyden
    • 범용성을 먼저 챙기고 성능을 개선하자
    • 실행하기 위해 Training Run
    • Grall VM에서는 all or nothing 정도의 제약이었으나 이건 그정도까진 않음
    • import시 globbing star를 하면 성능문제가 있음
    • JEP 483: .cds 파일을 .aot로 바꾸자(뭔가 바꿈)
    • JEP 514: AOT 캐시 생성 워크플로우 간소화
    • JEP 515: 메서드 실행 프로파일링을 AOT 캐시에 들어간 제안
    • JEP 516: leyden에서 gc 호환성 개선(zgc 등 사용 가능), grall vm의 gc 제약 해결

On-Prem to AWK: API Gateway zero-Downtime 클라우드 전환기

  • AWS 한국사용자모임
  • LG U plus
  • 주요 대기업에서 주로 행해지고 있는 public cloud로 마이그레이션 후기
  • 가장 먼저 해야 했던 거는 연결상태 확인
  • IDC에서 AWS로 들어오는 흐름 확인이 굉장히 중요했음
  • haproxy를 이용하여 IP 변경소요를 막았음
    • haproxy 5개
  • pick traffic 보임. 대부분 작업은 출퇴근시간, 9시 이후 pass사용량이 줄어듬
  • 1순위가 대내 traffic을 꺾는 것, 2순위는 대외 트래픽 꺽는 것
  • 빠른 롤백이 되어야 함
  • 큰 고객들은 대부분 IDC를 통해 traffic이 왔어서 20%씩 바꾸니 가능했음
  • 겪었던 난관: Hair-pin NAT
Tags: 개발행사