현재 대부분의 플랫폼 엔지니어링(Platform Teams) 팀은 핵심적인 문제를 논의하고 있습니다. AI 코딩 에이전트(AI Coding Agents)가 인프라 수정을 위한 풀 리퀘스트(Pull Requests)를 생성하도록 허용해야 할까요? 진정한 답은 에이전트의 신뢰성 여부가 아니라, 잘못되고 파괴적인 변경 사항이 확산되기 전에 플랫폼 자체가 이를 수용할 수 있는 능력에 달려 있습니다.
유명한 Replit 사례는 이러한 위험을 잘 보여줍니다. 한 AI 에이전트가 실수로 프로덕션 데이터베이스를 삭제하고 수천 개의 가짜 계정을 생성했는데, 이는 자동화가 좋은 변경과 나쁜 변경을 구분하지 못하며, 결과가 올바르든 재앙적이든 단지 그 속도만을 가속화한다는 점을 시사했습니다.
GitOps 시대의 자동화 위험
대부분의 현대적인 클라우드 플랫폼은 Git 저장소가 인프라의 원하는 상태(desired state)를 나타내는 GitOps 방법론에 의존합니다. GitOps는 감사와 일관성 측면에서 이점이 있지만, 자동화는 여기서 "오류 증폭기" 역할을 합니다. 단 하나의 실수가 몇 초 만에 전체 인프라로 확산될 수 있기 때문입니다. AI 에이전트의 등장으로 변경 요청의 빈도는 엄청나게 증가하는 반면, 인간의 검토 능력은 제한되어 있어 인간의 검토가 기술 생산 라인에서 "가장 희귀한 자원"이 되고 있습니다.
클라우드 탄력성 구축을 위한 5가지 계층
플랫폼의 안전을 보장하려면 변경을 수행하는 주체가 누구인지에 의존하는 것이 아니라, 시스템 자체의 견고함에 기반한 다층적 보호 체계를 구축해야 합니다:
- 첫 번째 계층: 조기 테스트: 테스트 주도 개발(TDD)과 카나리(Canary) 환경을 사용하여 변경 사항이 사용자에게 도달하기 전에 전체 환경에서 동작을 모니터링합니다.
- 두 번째 계층: 추상화 및 구성(Abstraction): 가공되지 않은 YAML 파일 대신 단순화된 인터페이스를 제공하여 오류 범위를 줄입니다. 복잡한 리소스 세트를 단순한 API로 변환하기 위해 kro(Kube Resource Orchestrator)와 같은 도구를 사용하거나, 개발자의 요구 사항을 단순화하기 위해 Score 프로젝트를 사용할 수 있습니다. 이는 변경 사항을 결정론적(Deterministic)으로 만들고 AI가 알 수 없는 필드에서 "즉흥적으로" 행동하는 것을 방지합니다.
- 세 번째 계층: Kubernetes 네이티브 보호: 액세스 제어 정책(RBAC)을 활성화하고, 플랫폼 표준에 맞지 않는 모든 요청을 차단하는 "관제탑" 역할을 하는 Kyverno를 사용하며, Pod 중단 예산(Pod Disruption Budgets)을 활용합니다.
- 네 번째 계층: 클라우드 제공업체 보호: 실수로 인한 삭제를 방지하기 위해 핵심 리소스 수준에서 "삭제 방지(Deletion Protection)" 기능을 활성화합니다.
- 다섯 번째 계층: 인간의 검토: 어떤 변경 사항도 인간의 검토를 거치지 않고 통과할 수 없도록 CODEOWNERS와 같은 메커니즘을 통해 전문가의 역할을 유지합니다.
"단일 플래그(One Flag)" 개념과 제로 트러스트 모델
각 보호 계층을 별개의 결정으로 만드는 대신, 이 기사는 "단일 플래그(One Flag)"를 통해 이를 단순화할 것을 제안합니다. 리소스 정의에서 특정 필드를 protected: true로 설정하면, 플랫폼은 자동으로 클라우드 삭제 방지를 활성화하고, 지역(Region) 변경을 차단하며, 엄격한 Kyverno 정책을 적용합니다. 이 접근 방식은 인프라 자동화에 제로 트러스트(Zero Trust) 원칙을 적용합니다. 즉, 에이전트나 인간 모두를 신뢰할 수 있다고 가정하지 않고, 검토 중에 쉽게 감지할 수 있는 명시적이고 명확한 승인 요청 없이는 파괴적인 변경을 수행할 수 없도록 시스템을 설계하는 것입니다.
실무에서는 무엇이 바뀌는가?
이러한 방향성은 보안의 부담을 "사용자 모니터링"에서 "플랫폼 요새화"로 전환합니다. 플랫폼 엔지니어에게 이는 AI의 능력을 제한하려고 노력하는 것을 멈추고, 오류를 기술적으로 불가능하게 만들거나 적어도 그 영향 범위(Bounded Blast Radius)를 제한하는 시스템을 구축하기 시작하는 것을 의미합니다. 목표는 팀이 업무를 방해하는 제약을 부과하기 때문이 아니라, 가장 빠르고 안전한 경로이기 때문에 플랫폼을 채택하게 만드는 단계에 도달하는 것입니다.