[활용 사례] AI와 GitOps의 만남: Chkk MCP 기반 쿠버네티스 애드온 업그레이드 실전기

 

kt cloud Platform엔지니어링팀 이지은 님

 

📝 요약 SUMMARY

이 글에서는 Chkk MCP와 AI Agent를 활용해 Kubernetes 애드온 업그레이드를 자동화하고,
수동 배포 환경을 GitOps로 전환한 실증 사례를 다룹니다.
Argo Workflows, Gitea, ArgoCD의 업그레이드 과정과 IaC 자동 생성 및 운영 환경 적용 과제를 정리합니다.

#Chkk #MCP #Kubernetes #GitOps #애드온업그레이드

---

계획된 진화, 그리고 엔지니어가 마주하는 ‘실행’의 장벽

대규모 쿠버네티스(Kubernetes) 환경을 안정적으로 운영하는 일은 단순히 클러스터 자체의 버전을 올리는 것에 그치지 않습니다. 오히려 그 위에서 인프라의 모니터링, 배포, 형상 관리를 지탱하는 수많은 오픈소스 및 서드파티 애드온(Add-on)들의 라이프사이클을 최신으로 유지하는 것이 훨씬 더 까다롭고 손이 많이 가는 작업입니다.

 

kt cloud와 같이 대규모 멀티 클러스터를 전사적으로 지원하는 엔터프라이즈 환경에서는 이러한 애드온 관리를 방치할 경우 보안 취약점이 누적되고, EOL 리스크에 직면하며, 궁극적으로는 쿠버네티스 코어 API와의 버전 호환성 충돌로 인해 인프라 전체가 거대한 기술 부채로 변하게 됩니다.

 

그러나 이 업그레이드 프로세스를 면밀히 들여다보면, 인프라 엔지니어의 엄청난 ‘수작업’과 정신적 피로도가 숨어 있습니다. 새로운 버전이 릴리스될 때마다 엔지니어는 수많은 업스트림 리포지토리를 돌아다니며 릴리스 노트를 한 줄씩 읽어야 하고, 버전 간의 호환성 매트릭스를 수동으로 검증해야 합니다.

 

특히 GitOps 매니페스트를 관리하는 상황에서 버전에 따라 미세하게 혹은 완전히 구조가 바뀌는 values.yaml 설정을 손수 비교(diff)해가며 IaC(Infrastructure as Code) 코드를 수정하는 작업은 생각보다 큰 리스크를 동반합니다.

"차트 버전이 올라가면서 내부 인프라 설정 파라미터 구조가 완전히 바뀌면 어쩌지?"

"도커 허브(Docker Hub) 이미지 레지스트리 변경 같은 Breaking Change를 놓쳐 배포 장애가 나면 어쩌지?"

 

결국, 장애에 대한 두려움 때문에 인프라 버전을 구형으로 방치하게 되고, 이는 다시 더 큰 기술 부채로 돌아오는 악순환이 반복됩니다. kt cloud 는 이러한 '실행의 장벽'을 허물고 인프라 라이프사이클 관리를 완벽히 자동화하기 위해, 최근 클라우드 네이티브 생태계에서 가장 주목받는 기술인 MCP(Model Context Protocol)를 Chkk 솔루션과 결합하여 통합개발환경(IDE)에서 Add-on 업그레이드 자동화 PoC를 진행하고 운영에 도입했습니다.

 

단순히 도구를 설치해 본 수준을 넘어, 실제 사내 보안 정책과 폐쇄망이라는 혹독한 프로덕션급 제약을 엔지니어링으로 어떻게 극복하고 코드를 자동 반영했는지 그 실전 기록을 상세히 공유합니다.

 

 

---

Chkk MCP가 주입하는 ‘우리 클러스터’ 맞춤형 런타임 컨텍스트

일반적인 대형 언어 모델(LLM) 기반의 GenAI 비서(Cursor, Claude Code 등)는 인터넷에 공개된 오픈소스의 범용적인 정보만 학습했을 뿐입니다. 당연하게도 우리 조직의 특수한 인프라 제약 조건이나, 환경별로 Fork하여 커스텀하게 수정한 Helm 차트 구조를 알지 못합니다. 이 때문에 컨텍스트가 없는 단순 AI에게 인프라 코드를 수정해달라고 요청하면, 현업 환경에 전혀 맞지 않거나 문법이 깨진 매니페스트를 생성하여 GitOps 파이프라인을 깨뜨리기 일쑤입니다.

 

Chkk는 이 결정적인 간극을 Chkk Upgrade Context MCP Server 아키텍처를 통해 해결합니다.

 

개발자 로컬 워크스테이션 환경에 Docker 기반 런타임으로 Chkk MCP Server를 등록하면, AI Agent는 Chkk가 자체 가상 복제 환경(Digital Twin)에서 미리 빌드하고 유효성 검증을 완벽히 마친 고유의 Upgrade Template 및 생성된 플랜 ID(upgrade_id)와 실시간으로 연동됩니다.

 

이는 단순히 릴리스 노트를 요약한 가이드 텍스트를 복사-붙여넣기 하는 기존 챗봇 방식과 차원을 달리합니다. 실제 우리 클러스터의 현재 구동 상태와 완벽히 동기화된 파일 아티팩트, 백엔드 Unified Diff 정보, API Deprecation 경고, 호환 가능한 최적의 타깃 버전 메타데이터가 AI의 프롬프트 컨텍스트에 프로토콜 레벨로 직접 주입되는 구조입니다.

 

엔지니어는 형상 관리를 위해 로컬 저장소에서 chkk-test 브랜치를 생성한 후, 터미널 환경이나 Claude IDE에서 제공하는 에이전트 프롬프트에 Chkk가 보증하는 가이드라인 명령어를 입력하는 것만으로 안전장치가 완벽히 확보된 업그레이드 워크플로우를 시작할 수 있게 됩니다.

 

---

실전 검증: 3가지 Case별 업그레이드 스토리를 전개하다

현재 사내에서 가동 중인 배포 방식의 다양성을 반영하기 위해, Helm 차트 기반(FluxCD HelmRelease 아키텍처) 2종과, 표준화 정립 이전에 코드화(IaC) 없이 수동 매니페스트 파일 묶음으로 직접 밀어 넣었던 Raw YAML 배포 구조 1종을 실증 타깃으로 선정하여 테스트를 수행했습니다.

1️⃣ Argo Workflows: 대폭적인 버전 점프도 흔들림 없이 자동화

• 인프라 상황: 기존에 v2.6.10 버전으로 오래 구동되어 EOL(지원 종료) 리스크 및 알려진 보안 취약점 노출 위험이 높았던 Argo Workflows 차트를 최신의 v3.6.10 버전으로 한 번에 대폭 점프하는 난도 높은 릴레이 업그레이드 케이스였습니다. 버전 격차가 커서 매니페스트 스키마 하위 호환성 손상이 우려되는 상황이었습니다.
• 실행 및 결과: Chkk 템플릿(template-Argo Workflows-v3.6.10) 발행이 완료된 후, 개발자 환경에서 AI Agent에게 업그레이드 수행을 명령했습니다. Chkk MCP Server는 팀 내 인프라 적재 패턴을 스스로 정밀 스캔하여, 기존 Git 리포지토리 내에 정의된 helmrepo 및 helmrelease 선언부를 정확하게 식별했습니다. AI는 주입된 컨텍스트를 바탕으로 신규 규격에 맞게 버전을 자동 스위칭하고, 형상 관리 이력 추적을 위한 명확한 변경 근거(Reason) 주입까지 한 번에 완료했습니다. 이후 수정된 코드를 GitOps 파이프라인을 통해 ArgoCD로 배포하여 클러스터 내 최종 정상 구동 상태를 성공적으로 확인했습니다.

2️⃣ Gitea: 복잡한 values 구조 변경과 이미지 레지스트리 이주 대응

• 인프라 상황: Gitea 업그레이드(1.22.0-rootless) 과정은 훨씬 더 복잡한 함정이 숨어 있었습니다. 단순 버전 넘버링 변경 외에, 오픈소스 내부 종속성 설정 규격이 변경되면서 values.yaml 내의 핵심 파라미터 계층 구조가 완전히 뒤바뀌는 구조적 변화가 예정되어 있었습니다. 또한 업스트림 정책에 따라 기존 도커 허브(Docker Hub)에서 Gitea 공식 도큐멘테이션 지정 레지스트리(Installation with Docker | Gitea Documentation)로 이미지 저장소를 이주해야 하는 Breaking Change가 섞여 있어, 수동으로 진행할 시 휴먼 에러 발생 확률이 매우 높은 상태였습니다.
• 해결의 핵심, VDM(Values Delta Map) 기술: Chkk는 이 문제를 해결하기 위해 백엔드에서 VDM(Values Delta Map) 엔진을 가동했습니다. VDM은 기존 실행 중인 BASE 버전의 values와 새로 올라갈 REMOTE 버전의 values.yaml 전체 구조를 정밀 알고리즘으로 자동 비교하여, 어떤 키가 삭제되었고, 어떤 키가 새로 추가되었으며, 어떤 파라미터의 이름이 변경(Rename)되었는지 매핑 맵을 스스로 도출해 냅니다. AI Agent는 이 촘촘한 VDM 컨텍스트를 입력받아, 엔지니어가 릴리스 노트를 놓쳤다면 100% 누락했을 이미지 레지스트리 이주 주소를 완벽히 변경하고, 신규 규격에 맞는 추가 필수 values 설정까지 스스로 작성하여 코드를 완성했습니다.

3️⃣ ArgoCD 수동 배포 환경: 형상 관리 없는 YAML을 GitOps 체계로 흡수하기

• 인프라 상황: 초기 설치 시점에 IaC 형상 관리 체계를 거치지 않고, 가공되지 않은 수동 매니페스트(Raw YAML)를 kubectl apply로 클러스터에 직접 밀어 넣어 운영하던 구형 ArgoCD 환경이었습니다. 이 구형 환경을 최신 버전으로 업그레이드하면서 규격화된 코드 기반의 GitOps 관리 체계로 전환해야 하는 난도 높은 미션이었습니다. 실제 Chkk 기술 채널을 통해 "초기 설치를 수동으로 진행한 환경인데, Chkk로 업그레이드하면서 IaC 코드를 새로 작성하고 GitOps 방식으로 전환하는 것이 정말 가능한가?"라는 실무적인 질문을 던지며 실증을 시작했습니다.
• 클러스터-저장소 자동 매핑 메커니즘: Chkk 오픈소스 백엔드는 이에 대해 명쾌한 해답을 주었습니다. 소스 저장소(Gitea/GitHub)가 연결되면 Chkk LCM 에이전트는 단순히 파일 이름만 매칭하지 않고, 클러스터 실제 런타임의 구성 정보, 애드온 메타데이터, 네임스페이스 및 레이블 규격, 리소스 네이밍 규칙 등 수많은 인프라 시그널(Signals)을 종합 분석합니다. 이를 통해 형상 관리가 단절되어 있던 수동 배포 환경이 어떤 코드 저장소와 매핑되는지 스스로 추론해 냅니다. 만약 분석 결과 확신도가 낮을 경우 독단적으로 진행하지 않고 워크플로우를 일시 중단(Suspend)한 뒤 엔지니어의 선택을 유도하는 안전장치(Safe Guard)도 갖추고 있습니다.
• 실행 결과: Chkk에서 발행한 template-ArgoCD-v3.0.12 템플릿을 기반으로 AI Agent를 구동한 결과, 기반 IaC 구조가 전혀 없던 환경이었음에도 분석된 신호 컨텍스트를 바탕으로 AI가 신규 규격의 구조화된 코드를 자동 작성해 냈습니다. 결과적으로 수동 인프라 부채를 청산하고 완벽한 GitOps 관리 체계 안으로 안전하게 편입시키는 성과를 거두었습니다.

---

실증을 통해 체감한 Chkk MCP의 뚜렷한 차별점

이번 통합개발환경 실증 테스트를 통해 직접 체감한 Chkk MCP 기반 인프라 자동화의 핵심 차별점은 다음과 같습니다.

• 지능형 IaC 패턴 자동 감지: FluxCD HelmRelease, ArgoCD, Terraform 등 기업마다 인프라를 관리하는 도구와 코드 스타일은 제각각입니다. Chkk MCP는 저장소가 연결되면 사람이 개입하지 않아도 기존 IaC 패턴을 스스로 감지하여, 조직의 배포 파이프라인 규격에 맞는 정확한 문법의 코드로 변환을 가합니다.
• 디지털 트윈(Digital Twin) 기반 사전 검증: Chkk 백엔드는 엔지니어에게 업그레이드 플랜을 발행하기 전, 자체 가상 복제 환경(Digital Twin)에서 시뮬레이션을 미리 구동합니다. 이 사전 테스트를 통과해 유효성이 검증된 안심 플랜만 엔지니어의 IDE 환경으로 전달하므로 배포 실패율을 최소화합니다.
• 철저한 감사 추적(Audit Trail) 제공: 일반 챗봇과의 대화는 기록이 휘발되어 이력 추적이 어렵지만, Chkk MCP는 구동 즉시 로컬 최상위 경로에 스크래치패드 디렉토리(.chkk/scratchpad/)를 생성합니다. 이곳에 실행 로그, VDM 변동 히스토리, 액션 플랜을 파일로 기록하여 투명한 변경 이력 관리와 안전한 코드 리뷰를 보장합니다.

---

프로덕션 전사 적용을 위해 한 걸음 더 나아가야 할 과제

성공적인 실증 성과를 거두었지만, 이를 실제 전사 수백 개의 프로덕션(Production) 라이브 클러스터 환경에 전면 확대 적용하기 위해 고도화해야 할 현실적인 보완점들도 명확히 식별되었습니다.

• MCP 실행 환경 제약 및 파이프라인 연동: 현재 Chkk MCP 작동 방식은 엔지니어의 로컬 터미널이나 특정 클라이언트 IDE(Cursor, Claude Desktop 등) 환경 및 개별 개발자의 유료 API 토큰에 의존하는 경향이 있습니다. 엔지니어의 수작업 개입을 최소화하고 전사 표준화를 이루기 위해서는, 코드 저장소에 업그레이드 알림이 뜨는 순간 깃랩 CI(GitLab CI)나 깃허브 액션(GitHub Actions) 파이프라인 런타임이 자동으로 Chkk MCP Server 컨테이너를 올리고 코드를 수정하여 자동으로 PR을 오픈하는 '중앙 파이프라인 연동용 자동화 래퍼 스크립트' 개발이 선행되어야 합니다.
• 최소 권한 원칙 기반의 촘촘한 권한 관리(RBAC) 체계 정립: AI Agent가 우리 인프라의 핵심 소스 리포지토리와 실제 가동 중인 클러스터의 내부 메타데이터 신호에 직접 접근해야 하는 구조이므로, 금융 및 공공 클라우드 규정을 준수하기 위해 최소 권한 원칙(Principle of Least Privilege)에 부합하는 Chkk 전용 쿠버네티스 RBAC 가이드라인과 시크릿 관리 보안 정책을 한층 더 촘촘하게 설계해야 합니다.
• 멀티 차트 종속성 구조의 단계별 통합 테스트 체계 병행: 대형 플랫폼 서비스의 경우 여러 오픈소스 애드온들이 서로 웹훅(Webhook)이나 CRD로 촘촘하게 얽혀 있는 멀티 차트 체인 구조를 가집니다. 단일 컴포넌트 관점의 Chkk 검증을 넘어, 업그레이드가 일어난 후 연쇄적으로 영향을 받을 수 있는 이종 애드온 간의 상관관계를 통제하기 위해 스테이징(Staging) 환경에서의 단계별 통합 스케줄링 테스트 프로세스가 반드시 병행되어야 인프라 무중단 진화를 완벽히 달성할 수 있습니다.

---

AI Agent 기반 플랫폼 엔지니어링의 미래를 그리며

쿠버네티스 애드온의 버전 관리를 방치하는 것은 인프라의 안전을 담보로 시한폭탄을 안고 가는 것과 같습니다. 그러나 매번 수많은 릴리스 노트를 숨바꼭질하듯 뒤져가며, 업스트림이 파놓은 함정(Breaking Change)을 피해 수동으로 YAML을 고치는 것은 소중한 엔지니어링 리소스를 단순 반복 수작업에 낭비하는 일이었습니다.

 

이번 kt cloud 의 실증 테스트는 "엔지니어가 밤을 새워가며 변경 이력을 분석하고 values 설정을 한 줄씩 타이핑하던 시대"가 저물고, "Chkk MCP라는 신뢰할 수 있는 인프라 가드레일 엔진 위에서 AI Agent에게 안전하게 코드 수정을 명령하고, 사람은 발행된 Pull Request의 아키텍처적 유효성만 최종 검토하여 Merge하는 시대"로의 패러다임 전환이 완전히 눈앞에 다가왔음을 증명했습니다.

 

kt cloud는 이번 실증 데이터와 폐쇄망 극복 경험을 자산 삼아 AI Agent 기반의 플랫폼 엔지니어링(Platform Engineering)을 더욱 고도화할 것입니다. 이를 통해 라이프사이클 관리 속도를 기존 대비 3~5배 이상 획기적으로 끌어올리는 것은 물론, 어떤 외풍에도 흔들리지 않고 가장 신속하고 안전하게 중단 없이 진화하는 최첨단 클라우드 인프라 생태계를 구축해 나갈 것입니다.

 

---

❔자주 묻는 질문 FAQ

Q 초기 설치 시 코드화(IaC) 없이 수동 매니페스트(Raw YAML)로 직접 밀어 넣은 구형 애드온 환경도 Chkk를 통해 GitOps 체계로 전환하며 업그레이드가 가능한가요?

A 네, 완전히 가능하며 이번 실증 테스트(ArgoCD 케이스)를 통해 그 유효성을 직접 검증했습니다. Chkk LCM 에이전트는 사내 소스 저장소(Gitea/GitHub)가 연결되면 단순히 파일 이름만 매칭하는 것이 아니라, 클러스터 실제 런타임의 구성 정보, 배포된 애드온의 메타데이터, 네임스페이스, 레이블 규격, 리소스 네이밍 규칙 등 수많은 런타임 신호(Signals)를 종합 분석합니다. 이를 통해 형상 관리가 단절되어 있던 수동 배포 환경이 어떤 코드 저장소에 매핑되는지 스스로 추론해 냅니다. 만약 데이터 분석 결과 확신도가 낮을 경우 독단적으로 진행하지 않고 워크플로우를 일시 중단(Suspend)한 뒤 담당 엔지니어의 선택을 유도하는 안전장치를 갖추고 있어, 안전하게 수동 인프라 부채를 청산하고 GitOps 체계로 흡수시킬 수 있습니다.

Q 일반적인 GenAI(챗봇)에게 인프라 코드를 고쳐달라고 하는 것과 Chkk MCP Server를 결합하여 AI Agent를 쓰는 것은 기술적으로 어떤 차별점이 있나요?

A 일반적인 GenAI는 인터넷의 대중적인 오픈소스 정보만 알 뿐, kt cloud가 처한 고유한 인프라 제약 조건이나 포크(Fork)된 커스텀 values 설정을 알지 못해 오답을 낼 확률이 높습니다. 반면 Chkk MCP 는 다음의 3가지 강력한 백엔드 엔진을 제공합니다. Contextualization: 우리 클러스터의 현재 구동 상태와 동기화된 파일 아티팩트, API Deprecation 경고, 호환 타깃 버전 메타데이터를 AI 프롬프트 레벨에 주입합니다. VDM (Values Delta Map): 기존 버전과 신규 버전의 values.yaml 전체 구조를 자동 비교하여 파라미터의 삭제, 추가, 이름 변경(Rename) 내역을 정확히 발려내어 가시화합니다. Digital Twin (가상 사전 검증): 엔지니어에게 수정 플랜을 제안하기 전, Chkk 자체 가상 복제 환경에서 업그레이드 시뮬레이션을 미리 구동하여 100% 성공이 확인된 안심 플랜만 인도하므로 프로덕션 장애율을 획기적으로 낮춥니다.

---