‘바이브옵스(VibeOps)’로 운영 생산성 극대화하기

서비스 전체보기

위시켓 요즘IT

고객 문의

02-6925-4867

10:00-18:00주말·공휴일 제외

yozm_help@wishket.com

이용약관

개인정보 처리방침

청소년보호정책

㈜위시켓

대표이사 : 박우범

서울특별시 강남구 테헤란로 211 3층 ㈜위시켓

사업자등록번호 : 209-81-57303

통신판매업신고 : 제2018-서울강남-02337 호

직업정보제공사업 신고번호 : J1200020180019

제호 : 요즘IT

발행인 : 박우범

편집인 : 노희선

청소년보호책임자 : 박우범

인터넷신문등록번호 : 서울,아54129

등록일 : 2022년 01월 23일

발행일 : 2021년 01월 10일

바이브 코딩(Vibe Coding)은 많이들 알고 있는 개념이지만, ‘바이브옵스(VibeOps)’라는 개념은 다소 생소할 수 있습니다.

바이브 코딩이 자연어로 설계하고 검증한 프롬프트를 입력해 코드를 생성한다면, 바이브옵스는 같은 방식으로 운영에 필요한 내용을 자연어로 입력하고, 그 결과를 받아들이거나 필요에 따라 수정하면서 운영하는 것을 의미합니다.

*사실 제가 작성한 제미나이 CLI 글(제미나이 CLI(Gemini CLI)로 쿠버네티스 관리하기, 제미나이 CLI(Gemini CLI)로 프로메테우스/그라파나 배포하기)을 접했다면, 이미 바이브옵스를 간접적으로 경험한 셈입니다.

이처럼 ‘바이브’라는 개념은 앞으로도 as Code(대표적인 예로 코드형 인프라, Infrastructure as Code)처럼 다양한 용어에 붙어 새로운 개념으로 파생될 것입니다.

as Code의 다양한 사용 예시 <출처: 작가, KubeCon China 2025 발표 장표>

오늘은 주요 환경에서의 바이브옵스 예시를 소개하고, 사용을 위해 알아야 하는 것들을 정리하려고 합니다.

기존 Ops와 바이브옵스 방식의 비교

우선 바이브옵스와 기존 운영 방식을 비교해 보면 둘의 차이가 좀 더 선명하게 보일 것입니다. 비교를 위해 3가지 경우를 준비했습니다.

깃허브 액션(CI)

깃허브 액션(GitHub Actions)처럼 자동화 작업을 할 때 가장 어려운 점은, 사용하려는 액션을 직접 찾고 활용법을 모두 숙지해야 한다는 것입니다. 그렇지 않으면 한 번 실행하고 수정하고, 다시 돌리고 또 수정하는 과정을 반복해야 합니다.

이런 경우, 깃허브 액션 하나를 작성하는 데 걸리는 시간이 분 단위가 아니라 시간 단위로 늘어납니다.

하지만 바이브옵스(VibeOps) 방식을 적용하면, 하고자 하는 내용을 적절히 지시하는 것만으로도 꽤 그럴듯한 초안을 얻을 수 있습니다. 아래 주제로, 바이브옵스를 활용한 깃허브 액션 만들기를 진행해 보겠습니다.

배포하려는 매니페스트의 보안 체크하기

테스트를 위해 도커 샘플 조직에 있는 wordsmith 저장소를 포크(fork)해 옵니다.

이렇게 포크해 온 내용은 git clone으로 내려받습니다.

➜  /tmp (☸️ |aks:default) git clone https://github.com/sysnet4admin/wordsmith.git

Cloning into 'wordsmith'...

remote: Enumerating objects: 206, done.

remote: Counting objects: 100% (94/94), done.

remote: Compressing objects: 100% (56/56), done.

remote: Total 206 (delta 60), reused 38 (delta 38), pack-reused 112 (from 1)

Receiving objects: 100% (206/206), 412.79 KiB | 6.66 MiB/s, done.

Resolving deltas: 100% (81/81), done.

내려받기가 끝나면, 내요을 받은 디렉터리로 이동한 다음 제미나이 CLI(Gemini CLI)를 실행합니다.

➜  /tmp (☸️ |aks:default) cd wordsmith

➜  wordsmith git:(main) (☸️ |aks:default) gemini

이제 Trivy를 이용해 k8s-manifests/api.yaml 파일을 보안 점검하는 깃허브 액션을 만들어 달라고 요청합니다.

Prompt | create github action for security check by trivy @k8s-manifests/api.yaml

제미나이CLI가 만들어 준 내용을 확인했다면, Yes를 선택합니다. (여기서 등장한 함정은 뒤에서 얘기하겠습니다.)

만들어진 깃허브 액션을 저장소에 반영하기 위해 git 명령을 사용합니다. git status add, commit, push를 순서대로 실행하려고 합니다.

Prompt | git add commit and push it

생각해 보니, 약간 ‘바이브스럽지 않게’ 직접적인 명령어로 프롬프트를 썼네요.

확인 메시지가 나올 때마다 Yes를 선택했습니다.

이제 깃허브 저장소의 GitHub Actions 탭에서 로그를 확인합니다. yaml 파일을 스캔해 3개의 잘못된 설정(Misconfiguration)을 발견한 것을 확인할 수 있습니다.

여기서 앞서 언급했던 ‘함정’이 드러납니다. 프롬프트에서는 @을 이용해 특정 파일 하나만 지정했음에도, 실제로는 해당 디렉터리에 있는 것을 모두 스캔하도록 깃허브 액션이 작성된 것입니다.

이처럼 바이브옵스를 활용할 때는 인공지능이 작성한 것이 완벽하지 않다는 점을 항상 알아야 합니다.

헬름 배포

만약 헬름(Helm)을 단순히 helm install <차트 이름>으로 한다면 별다른 문제가 발생하지는 않습니다.

그러나 실제로 ‘헬름을 쓴다는 것’은 ‘현재 배포 환경에 맞게 값을 변경한다’는 것입니다. 이때는 --set 옵션이나 values.yaml 파일로 수정된 값을 배포하게 됩니다. 이때는 필요한 개별 값을 찾기 위해 공식 문서 등에 있는 내용을 찾아 적용 여부를 반복적으로 테스트하며 만들어가게 됩니다.

하지만 바이브옵스를 활용하면 이러한 값 탐색과 적용에 드는 시간을 절약할 수 있어, 생산성을 높일 수 있습니다. 이번에는 그 예시로 쿠버네티스 대시보드를 바이브옵스 형태로 배포해 보겠습니다.

쿠버네티스 대시보드 배포하기

먼저, 쿠버네티스 대시보드를 헬름으로 배포하면서 서비스 노출 방식을 로드밸런서(LoadBalancer)로 하도록 요청합니다.

Prompt | deploy k8s dashboard by helm on current aks cluster. and expose as loadlbanacer type

헬름 저장소가 업데이트되고 적절한 --set 값이 적용되어 배포가 진행됩니다.

그러나 기다려도 로드밸런서를 통한 노출이 이루어지지 않은 듯합니다.

현재 상태는 다음과 같습니다.

$ kubectl get svc kubernetes-dashboard-kong-proxy

NAME                              TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE

kubernetes-dashboard-kong-proxy   LoadBalancer   10.0.225.135   <none>        443/TCP   5m5s

문제를 바탕으로 “쿠버네티스 대시보드에 로드밸런서가 없는 것 같다”고 제미나이 CLI에 말합니다.

Propmt | it seems like no loadbalancer for k8s dashboard

곧 이 부분을 제미나이 CLI가 조사합니다.

제미나이 CLI가 배포한 내용 가운데 실제로 로드밸런서 설정이 없는 것을 찾고, 이를 수정합니다.

수정을 마친 상태는 다음과 같이 조회됩니다.

$ kubectl get svc kubernetes-dashboard-kong-proxy

NAME                              TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)         AGE

kubernetes-dashboard-kong-proxy   LoadBalancer   10.0.225.135   20.249.164.144   443:31718/TCP   10m

이제 브라우저에서 접속해 보겠습니다. 안전하지 않은 접근이지만, 진행을 위해 Continue to site를 누릅니다.

여기서 또 다른 문제가 발생합니다. 등록된 토큰(Token)이 없어 더는 진행할 수 없는 상황입니다.

“쿠버네티스 대시보드에 접속할 수 없다”고 제미나이 CLI에 알립니다.

Prompt | I cannot connect to k8s dashboard

곧바로 제미나이가 조사에 착수합니다.

문서를 확인한 제미나이CLI는 대시보드에 서비스 어카운트(Service Account)가 설정되어 있지 않음을 파악했습니다. 이에 따라 서비스 어카운트를 생성했습니다.

생성한 서비스 어카운트에는 권한도 부여합니다.

또한 이 서비스 어카운트에 대응하는 토큰을 발급합니다. 해당 토큰으로 쿠버네티스 대시보드에 접속할 수 있습니다.

다시 브라우저에서 대시보드에 접속한 다음, 생성한 토큰을 입력하면 로그인할 수 있습니다.

아래 화면이 나오면, 로그인을 마쳤다는 뜻입니다.

이처럼 바이브옵스를 활용한 구성은 초기 배포에서 불완전하게 구축될 수 있습니다. 따라서 다음 단계에서는, 보다 안전하고 신뢰성 있는 방법을 소개하겠습니다.

스크립트 작성

바이브옵스(VibeOps)는 LLM을 기반으로 하기 때문에, 그 특성에 따라 통계적으로 가장 가능성이 높은 결과를 제시합니다. 따라서 언제나 같은 결과가 나오지 않습니다. 반면 코드나 스크립트와 같은 텍스트는 동일한 환경이라면 언제나 같은 결과를 보장합니다.

이 때문에 생성한 내용을 스크립트로 저장해 두면, 일관성이 부족하다는 바이브옵스의 단점을 어느 정도 보완할 수 있습니다.

AKS의 할당 파드를 파악하기

예를 들어, 현재 AKS(Azure Kubernetes Service)는 바닐라 쿠버네티스와 달리 노드당 할당되는 파드 수가 110개가 아닙니다. (이는 EKS도 동일하며, GKE의 경우 기본값이 110입니다.) 따라서 운영 환경에서는 노드당 할당된 파드 수와 실제 사용 중인 파드를 따로 파악해야 하는 경우가 있습니다. 이 과정을 바이브옵스로 진행한 다음, 스크립트로 정리해 보겠습니다.

먼저, 노드별로 현재 할당된 파드와 최대로 할당될 수 있는 파드를 체크해 달라고 요청합니다.

Prompt | check "allocated pod | max pod " per node

다시 보니 프롬프트에서 count라는 단어를 빠뜨렸지만, 제미나이 CLI는 잘 이해하고 제대로 진행했습니다.

처음에는 약간 틀린 명령어가 실행되었지만, 다시 노드별로 조사를 잘 해냈습니다.

조사를 마친 다음에는 결과를 테이블 형태로 보여줍니다.

이제 이를 스크립트로 만들어 달라고 요청합니다.

Prompt | create script for it

생성된 스크립트를 실행하면 동일한 결과가 다시 나오는 것을 확인할 수 있습니다.

이처럼 바이브옵스로 얻은 작업을 스크립트로 정리해 두면, 필요할 때마다 바로 실행해 항상 동일한 결과를 얻을 수 있습니다.

마치며: 그래서 바이브옵스를 어떻게 사용해야 할까?

지금까지 살펴본 바이브옵스(VibeOps)는 분명 편리하고 장점도 많아 보입니다. 그러나 문제도 있습니다. 항상 의도한 대로 동작하지는 않다거나, 에러로 인해 동작 자체가 멈춰 중단해야 하는 경우도 생깁니다.

이러한 약점을 고려하면, 결국 실제로 바이브옵스를 실행하는 데브옵스(DevOps) 엔지니어와 사이트 신뢰성 엔지니어(SRE) 등이 AI가 작성한 내용을 충분히 검토하고 활용하는 것이 좋습니다. 특히 프로덕션(Production) 환경에서 직접 구현하고 적용하기보다는, Dev 또는 Stage 환경에서 테스트한 다음 스크립트로 작성해 실행하는 방식이 훨씬 안전합니다.

여기에 제미나이 CLI의 setting.json을 잘 설정하면 실행하면 안 되는 것을 정의할 수 있습니다. 또, GEMINI.md로 명확한 가이드를 제공하면 예기치 못한 부작용을 줄일 수 있습니다. 이렇게 컨텍스트를 잘 설정하고, 생성된 결과물에 가드레일을 명확하게 주는 것이 프로덕션 수준에서 활용할 가장 효과적인 방법입니다.

*setting.json, GEMINI.md 등에 대한 활용법은 알아두면 쓸모있는 제미나이 CLI 사용법에서 확인할 수 있습니다.

다음 편 예고

지금까지는 제미나이 CLI(25년 6월 25일 출시)를 중심으로 설명했지만, 사실 바이브옵스를 위한 다양한 AI 에이전트 도구가 이미 출시되어 있습니다.

대표적인 예로는 클로드 코드(Claude Code, 25년 2월 24일 출시), 코덱스 CLI(Codex CLI, 25년 4월 16일 출시), 그리고 여러 오픈 소스 기반 도구들이 있습니다. 특히 클로드 코드는 터미널 환경에서 AI 에이전트를 구현하고 사용하는 것을 가장 먼저 시작한 만큼, 여러 면에서 비교 우위를 지니고 있습니다.

다음 글에서는, 바이브옵스 관점에서 제미나이 CLI와 클로드 코드를 비교하여 어떤 차이가 있는지, 그리고 무엇을 선택하면 좋을지 살펴보겠습니다.

작가

조훈(CNCF 앰버서더)

시스템/네트워크 IT 벤더의 경험 이후, 메가존 GCP 클라우드 팀에서 쿠버네티스와 연관된 모든 프로젝트에 대한 Tech Advisor 및 Container Architecture Design을 제공하고 있다. 페이스북 ‘IT 인프라 엔지니어 그룹’의 운영진을 맡고 있으며, 오픈 소스 컨트리뷰터로도 활동한다. 지식 공유를 위해 인프런/유데미에서 앤서블 및 쿠버네티스에 관한 강의를 하기도 한다. 책 <컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커> 등 3권을 썼다. CNCF(Cloud Native Computing Foundation) 앰버서더로서 쿠버네티스 생태계가 더 활발하게 퍼질 수 있도록 기여하고 있다.

심근우

LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.

문성주

체커(CHEQUER) 사의 DevOps Engineer로서 쿠버네티스의 멀티 클러스터 관리 방법론과 쿠버네티스 구현체(CAPI, OCI)에 대한 명세와 컨테이너 리소스 격리 방법에 대한 연구를 병행하고 있다. 이런 연구 활동을 기반으로 쿠버네티스 볼륨 테스트 파트에 컨트리뷰션했다. 본업은 쿠버네티스 오퍼레이터와 같은 CRD(커스텀 리소스)를 개발해 현업에서 쿠버네티스를 좀 더 편리하게 사용할 수 있도록 돕는 일이다. 또한, 페이스북 그룹 ‘코딩이랑 무관합니다만'과 ‘IT 인프라 엔지니어 그룹'의 운영진을 맡고 있다.

이성민

미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.