DYLabs Tech Blog
· 11 min read

Vibe Infra로 장애를 만들고, 장애에서 배우다

조현우
조현우

CEO & Fullstack Engineer

devops postmortem ai terraform vault aws

1. Vibe Infra

Andrej Karpathy가 “Vibe Coding”이라는 표현을 쓴 이후, AI에게 코드를 맡기는 개발 방식이 빠르게 퍼졌습니다. 그리고 이 흐름은 인프라 영역에도 들어왔습니다. Terraform 코드 생성, Vault 시크릿 설정, Prometheus 알럿 룰 작성, Grafana 대시보드 구성 — AI에게 맥락을 주고 결과물을 받아 apply하는 방식. 저는 이걸 Vibe Infra라고 부릅니다.

솔직히 편하고 빨랐습니다. Terraform 모듈을 새로 만들 때, 알럿 룰 수십 개를 한꺼번에 작성할 때, AI는 확실히 생산성을 올려줬습니다.

그리고 어느 일요일 오후, DB가 죽었습니다.

2. 일요일 오후, DB 인증이 끊기다

채팅 수집 서비스의 워커 로그에 password authentication failed for user가 쏟아지기 시작했습니다. 모든 워커가 Aurora DB 연결에 실패하고, 신규 채널 할당이 중단되면서 수백 개의 채널이 pending 상태로 쌓였습니다.

그런데 2시간 넘게 알럿이 울리지 않았습니다. 이유가 있었습니다.

  • Pod은 Running 상태였습니다. DB 연결만 실패할 뿐 프로세스 자체는 crash하지 않았습니다.
  • 기존 Redis 연결은 살아있었습니다. 이미 수집 중이던 채팅 메시지의 publish는 정상이었습니다.
  • 서비스 레벨 메트릭이 정상으로 보였습니다. 커넥션 수, 메시지 처리량 등 기존 알럿 조건에 걸리지 않았습니다.

인프라 의존성(DB)의 장애가 서비스 메트릭에 그림자를 드리우지 않는 blind spot이었습니다. “모든 게 정상인데 신규 할당만 안 되는” 상태 — 기존 모니터링이 전혀 고려하지 않은 failure mode였습니다.

3. AWS Secrets Manager가 비밀번호를 바꿔버렸다

원인은 Terraform 코드에 있었습니다.

resource "aws_rds_cluster" "this" {
  # ...
  manage_master_user_password = true  # ← 이것

  lifecycle {
    ignore_changes = [master_password, manage_master_user_password]  # ← 그리고 이것
  }
}

manage_master_user_password = true는 Aurora 클러스터의 master password 관리를 AWS Secrets Manager(ASM)에 위임하는 설정입니다. ASM은 7일마다 자동으로 password를 rotation합니다. 그리고 lifecycle.ignore_changes에 포함되어 있어서 Terraform plan에서도 이 설정의 변경을 추적하지 않았습니다.

문제는 우리 서비스의 DB credential은 Vault에서 관리하고 있었다는 점입니다. ASM이 Aurora의 master password를 바꿨지만, Vault는 그 사실을 모릅니다. 서비스는 Vault에서 받은 옛 password로 접속을 시도하고, Aurora는 이미 새 password만 허용합니다.

graph TD
    ASM[AWS Secrets Manager] -->|7일마다 rotation| Aurora
    Aurora -->|새 password 적용| OK[새 password로만 접속 가능]
    
    V[Vault] -->|옛 password 보유| Pod
    Pod -->|옛 password로 접속 시도| Aurora
    Aurora -->|인증 실패 ❌| Pod

    style ASM fill:#ff6b6b,color:#fff
    style V fill:#51cf66,color:#fff
    style OK fill:#ff6b6b,color:#fff

ASM과 Vault는 서로의 존재를 모릅니다. 둘 다 “시크릿 관리”라는 키워드를 달고 있지만 하는 일이 완전히 다릅니다. ASM은 DB 자체의 master password를 rotation하고, Vault는 애플리케이션에 credential을 전달합니다. 이 두 시스템이 같은 password를 독립적으로 건드리면서 충돌이 발생한 겁니다.

여기에 더 근본적인 문제가 있었습니다. 모든 서비스가 Aurora master 계정 하나를 공유하고 있었다는 점입니다. Coordinator, Discover, Worker — 역할이 다른 세 서비스가 동일한 master credential로 DB에 접속하고 있었기 때문에, 그 하나의 password가 바뀌는 순간 전체 서비스가 동시에 죽었습니다. 서비스별로 별도의 DB 계정을 만들어 사용했다면, master password가 rotation되더라도 서비스 계정에는 영향이 없으므로 이 장애는 발생하지 않았을 겁니다.

이 설정은 어떻게 들어갔는가

여기가 “Vibe Infra”의 핵심입니다. 이 manage_master_user_password = true 설정은 AI가 Terraform 코드를 작성할 때 넣었습니다. Terraform apply 과정에서 AWS가 “MasterUserPassword 또는 ManageMasterUserPassword 중 하나가 필요하다”는 에러를 반환했고, AI는 Terraform AWS Provider의 공식 문서를 조회하는 도구(Context7 등)까지 호출하여 최신 문서를 읽어왔습니다. 그리고 그 문서에서 ASM 관리를 권장하는 내용을 근거로 이 옵션을 선택했습니다.

아이러니하게도 AI가 문서를 성실하게 찾아 읽었다는 것 자체가 이 설정이 들어간 원인입니다. 문서를 읽지 않았다면 오히려 master_password를 직접 지정하는 전통적인 방식을 택했을 겁니다. AWS 문서만 놓고 보면 합리적인 선택이지만, 이미 Vault가 시크릿의 source of truth인 우리 환경에서는 치명적인 충돌을 일으킵니다.

더 문제였던 건 같은 Terraform 레포에 이미 다른 Aurora 클러스터의 코드가 있었다는 점입니다. 기존 메인 Aurora 클러스터는 manage_master_user_password 없이 잘 운영되고 있었습니다. AI가 새 클러스터의 Terraform을 작성할 때 같은 레포의 기존 코드를 참고했다면, 동일한 패턴을 따랐을 겁니다. 하지만 AI는 기존 코드를 참조하는 대신 AWS 문서를 근거로 독자적으로 코드를 작성했고, 그 결과 인프라 관리의 통일성이 깨지면서 이 설정이 들어갔습니다.

4. AI가 고치다가 더 부쉈다

장애 대응 과정에서 AI는 빛과 그림자를 동시에 보여줬습니다.

빛 — AI가 잘한 것

AI에게 장애 상황을 공유하자, Prometheus에 노출된 43개 메트릭을 전수 분석하여 어떤 failure mode가 기존 알럿에 잡히지 않는지 도출했습니다. ManageMasterUserPassword가 활성화되어 있다는 사실을 AWS API 호출로 확인하고, ASM auto-rotation이 근본 원인임을 특정했습니다. 이후 Terraform 수정안을 제안하고, 5계층 알럿 체계를 설계하고, Grafana 대시보드 보강안까지 만들었습니다.

분석 속도와 범위에서 AI는 확실히 강점을 보였습니다.

그림자 — AI가 만든 2차 장애

문제는 복구 과정에서 터졌습니다. ASM이 바꾼 새 비밀번호를 Vault에 반영하기 위해 AI가 실행한 명령은 이것이었습니다.

vault kv put secret/prod/chat-coordinator \
  DATABASE_URL="postgresql://admin:NEW_PASSWORD@aurora-host:5432/db"

vault kv put은 **전체 교체(replace)**입니다. 기존에 같은 path에 저장되어 있던 REDIS_ADDR, CLICKHOUSE_PASSWORD 등의 키가 모두 소실됐습니다.

결과:

  • 워커가 localhost:6379(Redis 기본값)에 접속 시도 → 연결 실패
  • 전체 워커 CrashLoopBackOff
  • KEDA가 crash를 감지하고 폭발적으로 scale up → 워커 34개까지 증가 (전부 crash 상태)

AI는 put이 전체 교체인지 부분 업데이트(patch)인지, 이 Vault path에 어떤 키들이 함께 저장되어 있는지 — 명령의 blast radius를 이해하지 못했습니다. 장애 대응이라는 시간 압박 속에서 이 실수를 사전에 잡아내기도 어려웠습니다.

5. Vibe Infra에 안전장치를 달다

장애 이후 추가한 방어 체계입니다.

Terraform 수정

# Before
manage_master_user_password = true
lifecycle {
  ignore_changes = [master_password, manage_master_user_password]
}

# After
manage_master_user_password = false  # ASM rotation 비활성화 — Vault가 관리
lifecycle {
  ignore_changes = [master_password]  # manage_master_user_password는 추적
}

manage_master_user_password를 ignore_changes에서 제거하여, 누군가 다시 true로 바꾸면 Terraform plan에서 감지되도록 했습니다.

여기서 한 가지 함정이 있었습니다. Terraform에서 false로 바꿔도 ASM에 이미 생성된 rotation schedule은 별도로 살아있습니다. cancel-rotate-secret을 명시적으로 실행해야 7일 후 재발을 막을 수 있었습니다.

5계층 알럿 체계

이번 장애에서 기존 알럿이 왜 울리지 않았는지 분석한 결과, “인프라 의존성 장애 → 서비스 메트릭에 반영되지 않음”이라는 blind spot이 드러났습니다. 이를 보완하기 위해 5개의 독립적인 신호를 계층별로 배치했습니다.

5개 알럿이 6분 이내에 모두 firing됩니다. 어느 하나가 실패하더라도 나머지가 잡는 구조입니다.

AI 도구 안전장치

2차 장애의 원인이 vault kv put이었으므로, AI 도구(Claude Code)에 hook을 추가했습니다.

  • vault kv put, vault kv delete, vault kv destroy 실행 시 반드시 사용자 확인을 거치도록 차단
  • terraform destroy, git push --force 등 파괴적 명령에도 동일 적용

AI가 실행하는 명령의 blast radius를 사람이 한 번 더 확인하는 관문입니다.

Grafana 대시보드 보강

기존 대시보드에 없던 패널을 추가했습니다.

  • DB Health: healthcheck error rate, connection 상태
  • KEDA Scaling: metric vs threshold, desired vs current replicas
  • Channel Lifecycle: 할당률, unassign rate, pending 추이

남은 숙제: 서비스별 DB 계정 분리

위 조치들은 모두 “ASM rotation이 다시 발생하지 않도록” 하는 방어입니다. 하지만 근본적으로는 모든 서비스가 master 계정을 공유하는 구조 자체가 문제입니다. 서비스별로 별도의 DB 계정을 만들고, 각 서비스의 Vault path에 해당 계정의 credential을 저장하면 됩니다. master password가 바뀌어도 서비스 계정에는 영향이 없고, 특정 서비스의 credential이 유출되어도 다른 서비스에는 영향이 없습니다. 단순하지만 이번 장애를 원천 차단하는 구조적 개선입니다.

“없던 것을 볼 수 있게 되었다”는 것만으로도 의미가 있습니다.

6. Vibe Infra를 계속하려면

AI로 인프라를 관리하는 건 여전히 유효합니다. 이번 장애 대응에서도 AI는 43개 메트릭 전수 분석, 5계층 알럿 설계, 대시보드 보강 등 사람이 혼자 하면 훨씬 오래 걸렸을 작업을 빠르게 해냈습니다.

단, 규칙이 필요합니다.

AI에게 맡겨도 되는 것:

  • 분석 — 메트릭 전수 조사, 로그 패턴 추적, 장애 원인 특정
  • 초안 생성 — Terraform 코드, 알럿 룰, 대시보드 JSON
  • 모니터링 — 장애 감지, 상태 리포트

반드시 사람이 확인해야 하는 것:

  • Secret/credential 변경 — put과 patch의 차이가 장애를 만든다
  • Destructive 명령 — delete, destroy, force push
  • 환경 고유의 맥락 — “우리는 Vault를 쓰니까 ASM은 필요 없다” 같은 판단

Vibe Infra의 핵심은 AI를 신뢰하는 것이 아니라, 신뢰할 수 있는 경계를 만드는 것입니다. AI가 생성한 Terraform을 apply하기 전에 plan을 읽고, AI가 실행하는 Vault 명령에 hook을 걸고, AI가 놓칠 수 있는 “우리 환경의 맥락”을 사람이 채우는 것. 이 경계를 잘 설계하면 AI는 여전히 강력한 인프라 운영 도구입니다.