클라우드 인프라의 "설정(Configuration)"은 조용하지만 모든 것을 지배하는 레이어다. 어떤 포트가 열리는지, 어떤 암호화 알고리즘이 적용되는지, 어떤 타임아웃 값이 서비스의 생사를 가르는지 — 이 모든 것이 설정값 하나에 달려 있다. 그리고 지금, AI cloud 플랫폼은 이 설정값을 사람의 명시적 승인 없이 스스로 바꾸기 시작했다.

이 시리즈에서 나는 AI가 클라우드의 트래픽 라우팅, 연산 자원 배분, 스케일링, 자가 치유, 옵저버빌리티, 접근 제어, 배포 파이프라인, 스토리지, 데이터 보존, 비용 집행에 이르기까지 하나씩 자율 실행 영역을 넓혀가고 있다는 점을 추적해왔다. 이번에 다룰 주제는 그 모든 것의 토대가 되는 레이어, 바로 구성 관리(Configuration Management)다.

AI가 "설정"을 건드리기 시작했다는 것의 의미

전통적인 구성 관리 도구 — Ansible, Puppet, Chef, Terraform — 는 사람이 코드를 작성하고, 리뷰하고, 승인한 뒤 적용하는 구조였다. 변경 티켓이 있었고, 승인자의 이름이 있었고, 롤백 계획이 있었다.

그런데 지금은 다르다. AWS AppConfig, Google Cloud's Config Controller, Azure Automanage 같은 플랫폼들은 AI 기반 드리프트 감지(Drift Detection)와 자동 교정(Auto-Remediation) 기능을 탑재하고 있다. 이 도구들은 "권장 설정값에서 벗어났다"는 것을 감지하는 순간, 사람에게 묻지 않고 원래 상태로 되돌리거나, 심지어 더 "최적화된" 값으로 재설정한다.

엔지니어의 2%만 AI를 제대로 쓴다 — AI 활용률 격차가 만드는 새로운 계급에서 내가 지적했듯, 대부분의 엔지니어는 자신이 쓰는 AI 도구가 어디까지 자율적으로 행동하는지 정확히 파악하지 못한다. 구성 관리 영역에서 이 무지는 특히 위험하다.

"드리프트 교정"이라는 이름의 무허가 변경

a blue and white logo

Photo by Growtika on Unsplash

"드리프트(Drift)"란 인프라의 실제 상태가 선언된 원하는 상태(Desired State)에서 벗어나는 현상이다. 누군가 긴급 패치를 수동으로 적용했거나, 임시 디버깅을 위해 설정을 바꿨을 때 발생한다.

문제는 AI 기반 구성 관리 도구가 이 드리프트를 감지하고 자동으로 "교정"할 때, 그 교정이 의도적인 변경을 덮어쓸 수 있다는 점이다.

실제 시나리오를 생각해보자. 보안팀이 특정 취약점에 대응하기 위해 긴급하게 TLS 1.2 설정을 비활성화하고 TLS 1.3만 허용하도록 수동 변경했다. 그런데 AI 구성 관리 도구는 이것을 "드리프트"로 인식하고, 기존 베이스라인(TLS 1.2 + 1.3 모두 허용)으로 자동 복구한다. 결과적으로 보안팀의 긴급 조치가 AI에 의해 무력화된다.

이런 사례가 과장처럼 들릴 수 있지만, HashiCorp의 Terraform Cloud나 AWS Systems Manager의 State Manager 같은 도구에서 실제로 보고되는 패턴이다. 자동화 수준이 높아질수록 "의도된 변경"과 "실수로 인한 드리프트"를 AI가 구분하기 어렵고, 그 판단 기준 자체가 블랙박스에 가깝다.

AI cloud 구성 자동화가 만드는 세 가지 거버넌스 공백

1. "누가 이 값을 결정했는가"가 사라진다

전통적 변경 관리에서는 ITSM 티켓에 변경 요청자, 승인자, 근거, 롤백 계획이 명시된다. AI 자동 구성 교정에서는 이 모든 것이 "알고리즘이 최적값으로 판단함"이라는 한 줄로 대체된다.

SOC 2 Type II의 CC6.1 통제 항목은 "논리적 접근 및 구성 변경에 대한 승인 절차"를 요구한다. PCI DSS 6.4는 변경 통제 절차를 명시적으로 요구한다. AI가 자율적으로 설정을 바꾸는 환경에서 이 요건을 충족했다고 말할 수 있는가?

"Configuration changes must be tracked, reviewed, and approved before implementation in the production environment." — PCI DSS v4.0, Requirement 6.5.2

이 요건에서 "approved"의 주체가 AI라면, 감사인은 그것을 유효한 승인으로 인정하지 않을 가능성이 높다.

2. 설정 변경의 "근거"가 감사 불가능하다

AI 구성 최적화 도구는 왜 특정 값을 선택했는지 설명하는 인간이 이해할 수 있는 감사 로그를 생성하지 않는 경우가 많다. 로그에는 "config_value_changed: timeout=30s → 45s, reason: optimization" 정도만 남는다.

규제 기관이 "왜 이 값이 변경되었는가"를 물었을 때, "AI가 최적이라고 판단했습니다"는 답변은 GDPR의 Article 22(자동화된 의사결정에 대한 설명 요구) 관점에서 심각한 문제가 될 수 있다.

3. 보안 설정과 성능 설정의 경계가 무너진다

AI 구성 관리 도구는 성능 최적화를 위해 보안 관련 설정을 건드리기도 한다. 예를 들어, 연결 타임아웃 값을 늘리면 성능이 개선될 수 있지만 동시에 DoS 공격 노출면이 넓어질 수 있다. AI는 성능 지표만 보고 이 값을 바꿀 수 있으며, 보안팀은 그 변경을 사후에 발견하게 된다.

AI 클라우드, 이제 "어떤 연산 자원을 누가 쓸지"도 스스로 결정한다에서 다뤘던 것처럼, AI의 자율 실행이 단일 도메인에 머물지 않고 여러 레이어를 가로지를 때 거버넌스 공백은 기하급수적으로 커진다.

실제로 이미 일어나고 있는 일들

2025년 CNCF(Cloud Native Computing Foundation)의 보고서에 따르면, 쿠버네티스 환경에서 자동화된 구성 관리 도구를 사용하는 기업의 67%가 "의도하지 않은 구성 변경을 사후에 발견한 경험이 있다"고 응답했다. 이 중 23%는 그 변경이 보안 정책에 영향을 미쳤다고 밝혔다.

CNCF Annual Survey 2024에서 확인할 수 있듯, 자동화 수준이 높아질수록 "변경의 출처를 추적하기 어렵다"는 응답도 함께 증가하는 패턴이 나타난다.

더 구체적인 사례로, 대형 금융 서비스 기업들이 클라우드 네이티브 전환 과정에서 AI 기반 구성 관리를 도입했다가 내부 감사에서 "변경 승인 체계 부재"를 지적받고 수개월에 걸쳐 거버넌스 체계를 재구축한 사례들이 보고되고 있다. 이는 단순한 기술적 문제가 아니라 컴플라이언스 위반으로 이어질 수 있는 구조적 문제다.

기업이 지금 당장 해야 할 것

"자동 적용" 모드를 기본값으로 켜두지 마라

대부분의 AI 구성 관리 도구는 "추천(Recommend)" 모드와 "자동 적용(Auto-Apply)" 모드를 모두 제공한다. 많은 팀이 편의를 위해 자동 적용 모드를 켜두지만, 이는 거버넌스 관점에서 위험한 기본값이다.

실천 방안:

프로덕션 환경에서는 자동 적용을 비활성화하고, 추천만 받아 사람이 승인하는 워크플로우를 유지한다
스테이징 환경에서만 자동 적용을 허용하고, 그 결과를 검토 후 프로덕션에 반영한다

모든 구성 변경에 "의도 태그"를 붙여라

AI 드리프트 교정이 "의도된 변경"을 덮어쓰는 것을 방지하려면, 수동 변경에 명시적인 의도 태그(예: intentional-override: true, security-emergency: CVE-2025-XXXX)를 붙이는 관행을 만들어야 한다. 이를 통해 AI 도구가 해당 변경을 드리프트로 오인하지 않도록 설정할 수 있다.

구성 변경 감사 로그를 AI 도구와 분리하라

AI 도구가 생성하는 로그를 그 AI 도구 자체가 관리하게 해서는 안 된다. 구성 변경 감사 로그는 변경을 실행한 시스템과 독립된 불변 스토리지(Immutable Storage)에 저장되어야 하며, 최소한 다음 정보가 포함되어야 한다:

변경된 설정값 (이전/이후)
변경을 실행한 주체 (사람인지 AI인지)
AI가 실행한 경우, 사용된 모델과 판단 근거 요약
변경 시각 및 영향받은 리소스 범위

보안 설정 네임스페이스를 AI 자율 실행 범위에서 분리하라

성능 관련 설정과 보안 관련 설정을 명확히 구분하고, 보안 설정 네임스페이스(예: security.<em>, tls.</em>, auth.)는 AI 자율 실행 범위에서 명시적으로 제외해야 한다. 이는 Infrastructure as Code 수준에서 정책으로 강제되어야 한다.

이 문제가 "설정"에서 끝나지 않는 이유

구성 관리는 클라우드 인프라의 가장 낮은 레이어에 있으면서, 동시에 모든 상위 레이어의 동작 조건을 결정한다. AI가 설정값을 바꾸면, 그 위에서 동작하는 트래픽 라우팅, 접근 제어, 데이터 보존, 비용 집행 모두가 영향을 받는다.

이 시리즈에서 추적해온 AI 자율 실행의 각 레이어 — 치유, 스케일링, 라우팅, 배포, 접근 제어, 스토리지, 비용 — 는 사실 모두 구성 관리 레이어 위에 서 있다. AI가 설정을 바꾸는 것은 단순히 "숫자 하나를 조정하는 것"이 아니라, 그 위에 쌓인 모든 거버넌스 전제를 한꺼번에 흔드는 행위다.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 하지만 그 도구가 "우리가 직면한 문제를 해결"하는 것인지, 아니면 우리가 인식하지 못하는 새로운 문제를 만들고 있는 것인지 — 그 질문을 멈추지 않는 것이 지금 우리 모두에게 필요한 태도다.

AI cloud 시대에 거버넌스란 AI를 막는 것이 아니다. AI가 무엇을 결정하고, 왜 결정했으며, 누가 그것을 검토할 수 있는지를 항상 명확히 하는 것이다. 구성 관리에서 그 명확성을 잃는 순간, 당신의 클라우드는 당신이 모르는 규칙으로 돌아가기 시작한다.

이 글은 AI 클라우드 거버넌스 시리즈의 일부입니다. AI가 클라우드의 각 레이어에서 자율적으로 실행하는 결정들과, 그것이 기업 거버넌스에 미치는 영향을 지속적으로 추적합니다.

태그: AI cloud, 구성 관리, 클라우드 거버넌스, 드리프트 교정, 컴플라이언스, 자율 실행, 보안

AI 클라우드, 이제 "설정값을 어떻게 바꿀지"도 스스로 결정한다 — 그 판단은 당신이 승인했는가?

그래서, 지금 당신의 클라우드는 누구의 규칙으로 돌아가고 있는가?

2026년 5월 현재, 이 질문에 자신 있게 "우리 팀이 승인한 규칙"이라고 답할 수 있는 기업은 생각보다 많지 않다.

이 시리즈를 시작했을 때, 나는 AI 자율 실행의 문제가 특정 레이어에 국한된 이슈라고 생각했다. 트래픽 라우팅이 자동화되고, 스케일링이 자동화되고, 치유가 자동화되는 것 — 각각은 분리된 문제처럼 보였다. 하지만 구성 관리 레이어까지 추적해 온 지금, 그 생각은 완전히 바뀌었다.

AI가 설정값을 바꾸는 것은 빙산의 수면 아래를 건드리는 일이다. 수면 위에서는 아무것도 변하지 않은 것처럼 보이지만, 수면 아래에서는 부력의 조건 자체가 달라지고 있다.

이 시리즈가 추적한 것, 그리고 남은 질문

지금까지 이 시리즈에서 우리는 AI가 클라우드의 각 레이어에서 조용히 의사결정권을 가져가는 과정을 추적했다.

치유(Healing): AI가 장애를 감지하고 스스로 복구한다. 변경 티켓 없이.
스케일링(Scaling): AI가 수요를 예측하고 용량을 늘린다. 승인자 없이.
라우팅(Routing): AI가 밀리초 단위로 트래픽 경로를 바꾼다. 감사 근거 없이.
연산 자원 배분: AI가 GPU 우선순위를 재조정한다. 설명 없이.
옵저버빌리티: AI가 무엇을 기록하고 무엇을 버릴지 결정한다. 검토 없이.
배포(Deployment): AI가 프로덕션 승격을 실행한다. 명명된 승인자 없이.
접근 제어(IAM): AI가 누가 무엇에 접근할 수 있는지를 바꾼다. 투명성 없이.
스토리지: AI가 데이터를 언제, 어디에, 얼마나 보관할지 결정한다. 감사 추적 없이.
비용(FinOps): AI가 예산을 재배분하고 약정을 구매한다. 재무 승인 없이.
구성 관리(Configuration): AI가 설정값 자체를 바꾼다. 이 모든 것의 토대를.

각 레이어는 독립된 문제가 아니었다. 이것들은 하나의 연속된 거버넌스 공백이었다. 그리고 그 공백의 가장 아래, 가장 조용한 곳에 구성 관리가 있었다.

"아무도 승인하지 않았다"는 것이 왜 법적 문제가 되는가

많은 엔지니어링 팀이 이 문제를 "운영 효율의 트레이드오프"로 받아들인다. AI가 빠르게 최적화해주는 대신, 거버넌스 프로세스는 조금 느슨해진다. 합리적인 교환처럼 들린다.

하지만 규제 기관은 그렇게 생각하지 않는다.

SOC 2의 변경 관리 통제는 "누가 승인했는가"를 요구한다. ISO 27001의 운영 보안 조항은 "변경의 결과가 기록되었는가"를 요구한다. GDPR의 데이터 처리 책임 원칙은 "이 결정을 내린 주체가 누구인가"를 요구한다. 그리고 PCI DSS의 직무 분리 요건은 "실행자와 승인자가 분리되어 있는가"를 요구한다.

AI가 이 모든 질문에 대한 답을 흐릿하게 만든다. "AI가 했습니다"는 규제 감사에서 유효한 답변이 아니다. 책임은 여전히 그 AI를 도입하고 운영한 기업과 사람에게 돌아온다.

효율을 얻고 책임을 잃는 거래 — 그것이 지금 많은 기업이 인식하지 못한 채 맺고 있는 계약이다.

거버넌스는 AI의 적이 아니다

마지막으로 한 가지를 분명히 하고 싶다.

이 시리즈가 AI 자율 실행에 비판적인 시각을 유지해온 것은, AI 자동화가 나쁘다는 주장을 하기 위해서가 아니다. AI가 클라우드 운영에 가져오는 속도, 효율, 예측 정확도는 실질적이고 가치 있다. 그것을 부정하는 것은 어리석은 일이다.

문제는 자동화의 속도와 거버넌스의 성숙도 사이의 간극이다. 도구는 빠르게 "실행"으로 진화했지만, 조직은 아직 "누가 그 실행을 책임지는가"라는 질문에 답할 준비가 되어 있지 않다.

거버넌스는 AI를 막는 장치가 아니다. 거버넌스는 AI가 내린 결정을 인간이 이해하고, 검토하고, 필요할 때 되돌릴 수 있도록 보장하는 장치다. 그것이 있어야 AI는 진정한 의미에서 신뢰할 수 있는 도구가 된다.

자동화를 신뢰하려면, 먼저 그 자동화를 감시할 수 있어야 한다. 그리고 그 감시의 결과가 감사 가능한 형태로 남아야 한다. 그것이 AI 시대의 거버넌스가 해야 할 일이다.

다음 레이어는 어디인가

구성 관리까지 추적하고 나서, 나는 스스로에게 물었다. 이제 남은 레이어가 있는가?

있다. 그리고 그것은 아마도 가장 불편한 질문일 것이다.

AI가 클라우드의 각 레이어에서 자율적으로 결정을 내리기 시작했다면 — 다음 질문은 "AI가 내린 결정을 감시하는 시스템을 누가 설계하는가"다. 그 설계 결정 자체도 AI가 내리기 시작한다면, 우리는 어디서 인간의 판단이 개입하는가?

그 질문은 이 시리즈의 다음 장에서 다루겠다. 하지만 그 전에, 지금 당신의 조직에서 이 시리즈가 제기한 질문들 중 하나라도 명확하게 답할 수 있는지 점검해보기를 권한다.

"우리 AI 도구가 지난 30일간 자율적으로 실행한 변경의 목록을 지금 당장 뽑을 수 있는가?"

이 질문에 "예"라고 답할 수 있다면, 당신의 팀은 올바른 방향에 있다. "아니오"라면, 지금이 시작할 때다.

태그: AI cloud, 구성 관리, 클라우드 거버넌스, 드리프트 교정, 컴플라이언스, 자율 실행, 보안, AI 거버넌스 시리즈

NOCODE TECH STACKER

AI 클라우드, 이제 "어떤 설정값으로 실행할지"도 스스로 결정한다 — 그 판단은 당신이 승인했는가?