AI‑네이티브 시대의 인프라 자동화, ‘더 많이’가 아니라 ‘더 안전하게’로 간다

# AI 네이티브 시대, 인프라 자동화는 운영 철학의 재배치다 AI 네이티브 시대의 인프라 자동화는 도구의 진화가 아니라 운영 철학의 재배치다. 현장에서는 이미 자동화가 충분히 도입되었는데도 장애는 줄지 않는다. 이 모순은 자동화의 목표가 바뀌었음을 보여준다. 이제 자동화는 편의가 아니라 안전을 위해 설계된다. 한동안 인프라 자동화는 '배포를 빠르게'에 집중했다. 그러나 야간 장애에서 체감되는 것은 속도가 아니다. 사람 손이 꼬이는 순간의 재현성 부재, 알림 홍수 속의 판단 지연, 권한과 비밀의 틈에서 터지는 사고다. 결국 남는 건 복구다. 이 글은 자동화를 클라우드 도구 목록으로 정리하지 않는다. 대신 자동화를 세 층으로 나누고, 클라우드·엣지·온프레미스를 제약 조건으로 재해석한다. 그 위에 실무 전략을 로드맵으로 얹는다. 핵심은 하나다. AI를 끼워 넣을 운영 구조가 먼저인가. ## 자동화는 3층 구조로 진화한다 인프라 자동화를 한 덩어리로 보면 늘 싸움이 난다. "Terraform이냐 Ansible이냐" 같은 논쟁은 대개 생산적이지 않다. 자동화는 서로 다른 목적을 가진 층으로 구성되기 때문이다. AI 네이티브 시대로 올수록 이 층위 구분이 선명해진다. ### 1층: 프로비저닝 자동화 1층은 리소스를 만들고 바꾸는 자동화다. IaC(Infrastructure as Code)는 인프라를 코드로 고정해 변경을 재현 가능하게 만든다. GitOps는 변경의 단일 진실 공급원을 Git에 둔다. 여기서 얻는 가치는 속도가 아니라 형태의 일관성이다.  현장에서 자주 부딪히는 지점은 '코드는 있는데 운영이 불안한' 상태다. 리소스는 잘 만들어지는데, 장애가 나면 사람마다 다른 방식으로 만진다. IaC는 배포를 빠르게 하지만, 복구를 자동으로 보장하진 않는다. 1층은 필요조건이지 충분조건이 아니다. ### 2층: 운영 자동화 2층은 SRE와 관측성(Observability), 그리고 대응 자동화가 중심이다. 여기서 질문은 '어떻게 배포할까'가 아니라 '어떻게 덜 망가질까'로 바뀐다. 알림은 많아질수록 안전해지는 게 아니라, 판단 비용이 올라간다. 그래서 운영 자동화의 핵심은 수집이 아니라 해석 비용 절감이다. 관측은 보통 지표·로그·트레이스를 말한다. 그러나 실무에서 더 중요한 것은 원인 후보를 줄이는 설계다. 카디널리티 관리, 샘플링 전략, 알림의 품질이 이 단계의 본체다. 알림이 줄어들수록, 실제로는 더 빨리 대응한다. 여기서 한 번은 뼈아픈 경험을 한다. 대규모 전환 작업에서 자동화가 부족하면 성공률이 아니라 재현성이 무너진다. 같은 절차를 두 번 반복할 수 없으면, 다음 장애에서 팀은 다시 초보가 된다. 운영 자동화는 숙련을 코드로 옮기는 일이다. ### 3층: 의사결정 자동화 3층은 자동화의 가장 어려운 구간이다. 여기서는 배포 여부, 권한 경계, 비용 폭증, 위험 노출 같은 판단이 개입한다. 사람이 매번 회의로 결정하면 속도는 나지만, 일관성은 사라진다. 그래서 정책을 코드로 만들고, 검증을 자동화한다.  최근 흐름에서 GitOps의 다음 단계가 여기에 있다. 배포 자동화만으로는 사고를 막지 못한다. 배포 전에 정책이 자동 검증되고, 위반은 자동 차단되어야 한다. 이때 자동화는 실행보다 제동에서 가치를 낸다. 자동화가 깊어질수록, 더 자주 실행하는 것이 아니라 더 자주 멈춘다. 안전한 자동화는 멈춤의 규칙을 먼저 만든다. ## 클라우드·엣지·온프레미스는 제약 조건이다 인프라 논의가 흐트러지는 이유는 분류 기준이 잘못되었기 때문이다. 클라우드, 엣지, 온프레미스를 '어디에 두느냐'로만 보면 도구 얘기로 끝난다. 그러나 실무자는 '무엇이 발목을 잡느냐'로 사고한다. 자동화 전략도 그 제약에서 출발해야 한다. ### 클라우드: 변경 폭이 크다 클라우드는 API가 풍부하고, 선언적 리소스 모델이 잘 갖춰져 있다. 그래서 1층 자동화는 가장 빨리 성숙한다. 문제는 그만큼 변경이 빠르고, 공급자 변화가 잦다는 점이다. 자동화가 잘 되어 있을수록, 변화가 더 빨리 전파된다. 따라서 클라우드에서는 자동 배포보다 자동 검증이 더 중요해진다. 태깅, 계정 구조, 권한 경계 같은 표준이 없으면 비용과 위험이 동시에 증폭된다. 태깅이 없어서 비용이 증발하는 경험은 흔하다. 클라우드의 자동화는 속도보다 통제 가능한 속도를 목표로 해야 한다.  ### 엣지: 자율성이 핵심이다 엣지는 네트워크가 끊기고, 전력이 불안정하며, 물리 접근이 어렵다. 이 환경에서는 '중앙에서 명령을 내려서 고친다'가 성립하지 않는다. 그래서 엣지 자동화의 핵심은 자율 복구와 오프라인 내성이다. 관측도 상시 스트리밍이 아니라, 요약과 지연 전송을 전제로 설계된다. 엣지에서 자동화가 실패하는 전형은 예외 처리다. 장비 모델이 조금씩 다르고, 설치 환경이 균일하지 않다. 이때 자동화는 수동을 없애는 게 아니라 예외를 표준으로 흡수하는 과정이 된다. 자동화의 적은 수동이 아니라 예외다. ### 온프레미스: 표준화 비용이 병목이다 온프레미스는 통제 범위가 넓고, 네트워크와 보안을 세밀하게 설계할 수 있다. 그러나 그 통제는 곧 표준화 비용을 의미한다. 장비, 가상화, 스토리지, 네트워크가 팀과 세대에 따라 다르면 자동화는 쉽게 깨진다. 그리고 자동화의 빈자리를 사람 숙련이 메운다. 이때 위험은 특정 개인의 손에 운영 지식이 고정되는 것이다. 장애 시나리오가 늘어날수록, '그 사람만 아는 절차'가 늘어난다. 온프레미스 자동화는 도구 도입보다 런북의 표준화, 권한·감사의 기본값 정립이 먼저다. 사람을 줄이기 위한 자동화가 아니라, 사람을 지키기 위한 자동화다. ## 최신 트렌드는 운영 패턴의 이동이다  트렌드는 늘 도구의 이름으로 유통된다. 그러나 실무에서 남는 것은 이름이 아니라 패턴이다. AI 네이티브 시대의 트렌드는 공통적으로 '실행의 자동화'에서 '안전의 자동화'로 이동한다. ### GitOps는 정책으로 확장된다 GitOps의 효용은 배포 자동화만이 아니다. 변경 이력이 남고, 승인 흐름이 생기며, 롤백이 구조화된다. 여기에 정책 자동화(Policy as Code)와 사전 검증이 붙는다. 배포 파이프라인이 릴리스 엔진에서 통제 장치로 변한다. 여기서 중요한 전제는 표준이다. 네이밍, 태깅, 계정 구조, 네트워크 경계, 권한 모델이 정리되지 않으면 정책은 늘 예외로 뚫린다. 예외가 많아질수록 정책은 형식이 되고, 자동화는 부채가 된다. ### 관측성은 원인 후보 축소로 이동한다 관측은 많이 모을수록 좋아 보인다. 하지만 알림이 많아지면 중요한 알림을 놓친다. 그래서 관측의 목표는 데이터 양이 아니라, 원인 후보를 줄이는 속도다. 노이즈 제거가 곧 복구 시간 단축으로 이어진다. 실무에서 가장 자주 보는 함정은 '대시보드는 화려한데, 장애 때 쓸모가 없는' 상태다. 장애는 대개 경계 조건에서 터진다. 그래서 관측은 평시 보고서가 아니라, 장애 시 의사결정의 비용을 줄이는 방향으로 설계되어야 한다.  ### AIOps는 제한적 실행으로 이동한다 요즘 많은 팀이 LLM을 붙여 알림을 요약하고, 로그를 검색한다. 이 단계만으로도 야간 대응의 피로가 줄어든다. 다만 다음 단계는 더 위험하다. 런북 실행을 자동화하려는 순간, 가드레일이 없으면 사고가 난다. 따라서 LLM은 운영을 대체하는 주체가 아니라 판단 비용을 낮추는 보조 장치로 두는 편이 안전하다. 요약, 검색, 변경 영향 분석, 런북 초안 생성까지는 효과가 크다. 실행은 제한적으로, 승인과 롤백이 전제될 때만 허용해야 한다. ### 보안 자동화는 기본값을 강제한다 보안은 종종 '도구를 더 사면 된다'로 오해된다. 그러나 실제 사고는 권한, 비밀, 감사의 기본값이 허술해서 난다. 그래서 보안 자동화의 방향은 탐지보다 강제에 가깝다. 권한 경계를 코드로 만들고, 비밀은 자동 회전되며, 감사는 누락되지 않게 설계한다. AI 네이티브 환경에서는 이 강제가 더 필요해진다. 자동화가 늘수록 권한의 오남용은 더 빠르게 확산된다. 따라서 보안 자동화는 속도를 늦추는 장치가 아니라 속도를 안전하게 만드는 장치가 된다. ## 실무 전략은 우선순위 로드맵으로 정리된다  자동화는 한 번에 완성되지 않는다. 특히 클라우드·엣지·온프레미스를 함께 운영한다면 더 그렇다. 그래서 실행 가능한 로드맵이 필요하다. 아래 단계는 도구가 아니라 질서의 순서다. ### 0단계: 표준화 표준은 지루하지만, 자동화의 전제다. 태깅, 네이밍, 계정 구조, 권한 경계가 없으면 자동화는 예외 처리로 무너진다. 예외가 늘면 운영은 다시 사람 손으로 회귀한다. 표준은 자동화를 위한 문서가 아니라, 자동화를 위한 계약이다. 이 단계에서 성급히 플랫폼을 도입하면 역효과가 난다. 도구는 표준을 대신하지 못한다. 표준이 없는 조직에서 도구는 기능이 아니라 갈등을 증폭시킨다. ### 1단계: IaC와 변경 이력의 단일화 인프라 변경은 반드시 흔적을 남겨야 한다. Git은 단순한 저장소가 아니라 책임의 구조다. 누가, 왜, 무엇을 바꿨는지가 남으면 복구가 빨라진다. 1단계의 목표는 자동 배포가 아니라 변경의 재현성이다. 여기서 흔히 하는 착각은 '코드화=완료'다. 코드는 시작일 뿐이다. 코드가 리뷰되고, 승인되고, 배포되고, 롤백되는 흐름이 갖춰져야 한다.  ### 2단계: 관측과 알림의 품질 개선 알림이 많아지면 팀은 무감각해진다. 무감각은 곧 장애 대응 지연이다. 따라서 먼저 해야 할 일은 알림을 늘리는 것이 아니라 줄이는 것이다. 중요한 것만 울리게 만드는 것이 자동화의 기반이다. 이 단계에서는 '무엇을 모을까'보다 '무엇을 버릴까'가 중요해진다. 카디널리티 폭발을 막고, 샘플링을 설계하며, 서비스 수준 목표(SLO)에 맞춰 알림을 다듬는다. 관측이 정리되면, 그 다음 자동화가 안전해진다. ### 3단계: 런북과 복구 자동화 자동화의 체감 가치는 배포가 아니라 복구에서 나온다. 장애 때 사람 손이 꼬이는 이유는 절차가 머릿속에 있기 때문이다. 런북을 문서로만 두지 말고, 실행 가능한 형태로 정리해야 한다. 그리고 가능한 범위에서 자동화한다. 복구 자동화는 보통 보수적으로 시작한다. 재기동, 롤백, 스케일 조정처럼 위험이 비교적 낮은 작업부터 자동화한다. 페일오버처럼 위험이 큰 작업은 더 강한 검증과 승인 흐름이 필요하다. ### 4단계: 정책·보안·비용의 자동 검증 여기서 자동화는 실행이 아니라 차단의 형태를 띤다. 정책 위반은 배포 전에 잡혀야 한다. 권한 과다, 태깅 누락, 비용 폭증 가능성, 네트워크 노출 같은 문제는 사후 대응이 비싸다. 사전 검증은 사고 비용을 구조적으로 줄인다. 이 단계가 자리 잡으면 조직의 운영 언어가 바뀐다. '누가 허락했나'가 아니라 '정책이 허용하는가'로 이동한다. 사람의 기분이 아니라 규칙의 일관성이 운영을 지배한다. ### 5단계: LLM 활용 LLM은 매력적이지만, 운영의 중심에 놓기엔 위험이 크다. 특히 실행 권한을 주는 순간, 실수는 곧 사건이 된다. 따라서 순서는 거꾸로 가야 한다. 먼저 구조를 만들고, 그 위에 LLM을 얹는다. 현실적인 진입점은 요약과 검색이다. 알림·로그·변경 이력을 한 문맥으로 묶어 주면 판단 시간이 줄어든다. 그 다음이 런북 보조다. 제한적 실행은 마지막이며, 승인·가드레일·롤백이 전제되어야 한다. ## 결론 AI 네이티브 시대의 인프라 자동화는 더 많은 자동화가 아니다. 더 안전한 자동화다. 클라우드·엣지·온프레미스는 서로 다른 장소가 아니라 서로 다른 제약이며, 이를 관통하는 해법은 표준화·정책화·복구 중심 설계다. 자동화의 끝은 무인화가 아니라, 실패를 다루는 질서다.