당신은 원하는 바를 평범한 영어로 설명했고, 모델은 Terraform 코드를 작성했으며, 당신은 apply를 실행했고, 그것은 성공했습니다. 문서도, Stack Overflow도, 한 시간 동안 HCL 구문과 싸울 필요도 없었습니다. 이것이 바로 바이브 코딩 (vibe coding) — 의도를 설명하고 모델의 출력물에 올라타는 방식 — 입니다. 인프라 구축에 있어서 이는 진정으로, 중독적일 만큼 빠릅니다.

하지만 이것은 또한 화요일 오후 2시에 실수로 운영 중인 VPC를 terraform destroy 해버리는 방법이기도 합니다.

저는 생업으로 운영 환경의 OpenStack, Kubernetes, 그리고 Terraform을 관리하고 있으며, 현재 그 중 상당 부분을 바이브 코딩으로 처리하고 있습니다. 여기에는 속도는 유지하면서 파괴적인 결과는 피할 수 있는 솔직한 방법 — 제가 실제로 따르는 규칙들 — 이 있습니다.

바이브 코딩은 초안 작성에는 훌륭하지만, 결과에는 끔찍합니다

모델이 아주 잘하는 것은 "이 서비스 앞에 속도 제한(rate-limited)이 걸린 NGINX 리버스 프록시(reverse proxy)가 필요해"라는 말을 2초 만에 40줄의 설정 코드로 바꾸는 것입니다. 모델이 전혀 알지 못하는 것은, 이 서비스가 결제 API와 업스트림(upstream)을 공유하고 있다는 사실, 당신의 지난 장애가 정확히 이런 종류의 변경 사항 때문에 발생했다는 사실, 그리고 "무해한" 재설정(reload)이 피크 시간대에 진행 중인 연결(in-flight connections)을 끊어버릴 것이라는 사실입니다.

모델은 코드를 작성합니다. 하지만 그 결과(consequences)를 책임지지는 않습니다. 책임은 당신이 집니다. 따라서 인프라를 안전하게 바이브 코딩하는 전체 게임의 핵심은, 기계가 타이핑을 하게 두되 폭발 반경(blast radius)에 대한 책임은 인간이 계속 지도록 유지하는 것입니다.

규칙 1: 초안은 바이브 코딩하되, 적용(apply)은 절대 하지 마세요

가장 중요한 단 하나의 습관: AI는 변경 사항을 제안할 수는 있지만, 절대로 직접 수행하게 해서는 안 됩니다. "당신이 실행할 kubectl patch는 이것입니다"라고 말하는 것과, 봇이 당신을 대신해 그것을 실행하는 것 사이에는 천지 차이가 있습니다.

구체적으로, 이는 실제 시스템에 무엇인가가 닿기 전에 제가 읽을 수 있는 계획(plan)을 요구한다는 것을 의미합니다:

terraform plan -out=tfplan
terraform show -json tfplan | <모델에 붙여넣기>

"이 계획을 읽어줘. 어떤 변경 사항이 있는지 평범한 영어로 말해주고, 리소스를 **삭제하거나 교체(destroys or replaces)**하는 것이 있다면 표시해줘. 그리고 가장 위험한 변경 사항 3가지를 순위별로 알려줘. 괜찮다고 말하지 말고, 무엇이 잘못될 수 있는지 말해줘."

200번 줄에 숨겨진 force-replace가 바로 바이브 코딩(vibe-coding)이 간과하지만 주의 깊게 읽으면 잡아낼 수 있는 바로 그 부분입니다. 저는 이에 대한 전체 버전인 — AI 지원 리뷰를 위한 Terraform plan 파싱하기 — 를 작성했지만, 한 줄로 요약하자면 이렇습니다: 모델이 plan을 읽게 하고, 당신이 apply를 승인하세요.

규칙 2: 파괴적인 명령은 반드시 다시 확인하도록 만들기

바이브 코딩된 셸 스크립트(shell scripts)는 사람들이 가장 빠르게 피해를 입는 지점입니다. 왜냐하면 bash는 $DIR이 비어 있을 때도 아주 즐겁게 rm -rf "$DIR/"를 실행해 버리기 때문입니다. 모델이 건네준 그 어떤 것이라도 실행하기 전에, 저는 다음과 같은 위험 검토 과정을 거칩니다:

"이 스크립트에서 파괴적이거나 되돌릴 수 없는 요소 — 삭제(deletes), 덮어쓰기(overwrites), 강제 푸시(force-pushes), 드롭(drops), 운영 환경 자격 증명(prod credentials) — 를 스캔해줘. 각 항목에 대해 영향 범위(blast radius)를 알려주고, 더 안전한 버전(dry-run 플래그, 확인 프롬프트, 선행 백업 등)을 제시해줘."

이 과정은 바이브(vibe) 에너지가 건너뛰는 것들을 잡아냅니다: 누락된 set -euo pipefail, 단어 분할(word-splitting)을 유발하는 따옴표 없는 변수, 네임스페이스 범위(namespace scoping)가 지정되지 않은 kubectl delete 같은 것들 말이죠. 저는 실행 전 위험한 셸 명령어를 잡아내는 방법에 대한 패턴과, 엄격 모드(strict mode), 트랩(traps), 복구 경로(back-out paths)를 사용하여 bash 스크립트를 강화하는 방법에 대한 또 다른 패턴을 보유하고 있습니다. 첫 번째 초안은 바이브 코딩으로 작성하되, 단 한 번이라도 실행하기 전에 반드시 강화(harden)하세요.

규칙 3: 바이브가 손댄 모든 것을 스테이징(Stage)하기

바이브 코딩은 루프(loop)가 매우 빠르다고 느껴지기 때문에 지루한 안전장치(safety rails)를 건너뛰고 싶은 유혹을 느끼게 합니다. 그러지 마세요. 빠른 루프일수록 안전장치가 반드시 필요합니다. 그렇지 않으면 그저 무언가를 더 빠르게 망가뜨리는 방법이 될 뿐입니다.

• 먼저 Dry-run을 수행하세요. --dry-run=server, terraform plan, ansible --check 등을 활용하세요. 만약 도구에 no-op (작업을 수행하지 않고 확인만 하는) 모드가 있다면, vibe-coded (감각적으로 코딩된) 변경 사항을 매번 그곳에서 먼저 실행하십시오.
• 최소한의 폭발 반경 (Smallest blast radius). 단 하나의 노드, 하나의 네임스페이스(namespace), 혹은 하나의 비운영(non-prod) 환경에 먼저 적용하십시오. 지켜본 뒤에 범위를 넓히십시오.
• 적용 전 되돌리기 계획 수립. 만약 "이 작업을 60초 안에 어떻게 되돌릴 수 있는가?"라는 질문에 답할 수 없다면, 모델의 말투가 아무리 자신만만했더라도 아직 적용할 준비가 되지 않은 것입니다.

이 중 그 어떤 것도 vibe (감각적인 흐름)를 크게 늦추지 않습니다. 그저 "아차" 하는 순간을 운영 환경(production)이 아닌, 비용이 들지 않는 터미널로 옮겨줄 뿐입니다.

규칙 4: 단순 반복 작업은 vibe-code 하고, 핵심 자산은 세심하게 관리하라

모든 인프라가 동일한 가치를 지니는 것은 아닙니다. Grafana 대시보드, CI 린트(lint) 작업, 일회성 마이그레이션 스크립트, 혹은 개발 환경(dev-env) 부트스트랩(bootstrap) 정도는 대충 훑어보고 vibe-code 할 수 있습니다. 잘못되어도 고작 10분 정도 낭비될 뿐이니까요. 하지만 IAM 정책 변경, 데이터베이스 페일오버(failover), 네트워크 ACL, 또는 고객의 자금이 오가는 경로에 있는 그 어떤 것도, 마치 적대적인 PR (Pull Request)을 검토하듯 모든 줄을 읽어보지 않고는 절대 vibe-code 하지 않을 것입니다.

검토의 강도를 폭발 반경 (blast radius)에 맞추십시오. 모델은 무엇이 중요한지 구분하지 못하지만, 당신은 알고 있습니다. (만약 실제 시스템과 병행하여 실행되는 AI 도우미를 구축하고 있다면, 동일한 원칙이 확장 적용됩니다. 저는 제안만 하고 조용히 실행되지는 않는 가드레일을 갖춘 AI ops 코파일럿 구축하기에 대해 작성한 바 있습니다.)

규칙 5: vibe가 재현 가능하도록 프롬프트 라이브러리를 유지하라

훌륭한 vibe coding의 숨겨진 비밀은 그것이 실제로는 vibe가 아니라, 좋은 프롬프트(prompt)라는 점입니다.

저는 잘 작동하는 프롬프트들을 검색 가능한 프롬프트 라이브러리에 보관합니다. 스택, 난이도, 그리고 운영 안정성 가이드(production-safety guidance) 포함 여부에 따라 필터링할 수 있도록 말이죠. 그렇게 하면 다음에 Postgres 인덱스나 Kubernetes 롤아웃(rollout)을 vibe-code 할 때, 이미 가드레일(guardrails)이 내장된 프롬프트에서 시작할 수 있습니다. 재현 가능한 vibe가 운에 맡기는 vibe보다 낫습니다.

솔직한 결론

vibe coding은 신중한 엔지니어링의 적이 아닙니다. 그것은 전동 공구(power tool)이며, 전동 공구의 안전성은 전적으로 사용자에 달려 있습니다. 잘 사용한다면, 초 단위로 초안을 작성하고 실제로 위험할 수 있는 5%의 부분에 진짜 주의력을 집중할 수 있습니다. 잘못 사용한다면, 기계의 속도로 확신에 찬 헛소리를 배포하게 될 뿐입니다.

따라서 다음과 같이 하세요: 초안은 vibe로 작성하고, 계획을 검토하며, 적용(apply) 전 스테이징(stage) 단계를 거치고, 폭발 반경(blast radius)을 산정하며, 변경 티켓(change ticket)에는 반드시 사람의 이름을 남기십시오. 그렇게 한다면 "vibe-coded"는 더 이상 고백이 아니라 하나의 워크플로(workflow)가 될 것입니다.

저는 devopsaitoolkit.com에서 실제 운영 인프라와 함께 AI를 실행하는 것에 대해 글을 씁니다. 처음 오셨나요? start-here 투어에서 무료 툴킷과 장애 대응 어시스턴트(incident assistant)를 만나보실 수 있습니다. 만약 운영 환경이 vibe-coding으로 해결할 수 없을 만큼 고통스럽다면, 저는 정찰 가격 기반의 인프라 감사(fixed-price infrastructure audits)를 진행합니다.