AI 데이터센터에 맞게 코드형 인프라 다시 쓰기 : zum 뉴스

생성형 AI가 코드형 인프라(IaC) 시장에 공식 진출했다. 시작은 사소했다. 개발자들은 구글에서 테라폼 구문을 검색하기 귀찮아서, 또는 끝없는 StackExchange 스레드에 파묻히는 상황을 피하기 위해 챗GPT와 코파일럿을 사용하기 시작했다. 이 현상이 이제는 더 복잡하고 광범위하게 발전해서 기업 조직은 단순히 구성(config) 파일을 작성하기 위한 용도가 아니라 인프라 의사 결정을 이끌고 관찰가능성을 통합하고 배포 오류를 포착하기 위한 툴로 AI를 채택하고 있다.

그러나 또 다른 가속화가 이야기의 전부는 아니다. AI 데이터센터에서 AI가 생성한 IaC가 보편화되면서 드러나지 않는 잘못된 구성부터 노출되면 안 되는 API가 공개되는 등의 위험도 함께 증가하고 있다.

기계의 부상

짐작할 수 있겠지만 개발자들은 이미 상당기간 동안 생성형 AI 툴을 사용해 IaC 구성 코드를 작성해왔다. 특히 초기에는 개발자들이 이를 주도했다. 마이크로소프트의 보안 기술 책임자인 시리 바르마 베지라주는 “내가 아는 많은 개발자, 특히 IaC 전문가가 아닌 개발자들이 GPT나 코파일럿에 의지해 테라폼 또는 앤서블 구성을 생성한다. 이 방법이 빠르다. 또한 모든 AWS 리소스 구문이나 모듈을 일일이 검색하는 귀찮은 일도 필요 없다”라고 말했다.

빠른 속도와 쉬운 접근성을 이끈 것은 구성 코드 작성의 문턱을 낮춘 AI다. 월람(Wallarm)의 CEO 이반 노비코프는 “AI는 개발자들이 깊은 지식 없이도 구성 파일을 작성할 수 있도록 문턱을 낮춰준다. AI가 등장하기 전에는 프로덕션급 쿠버네티스나 테라품 구성 파일 작성은 SRE, 데브옵스, 인프라 팀의 몫이었다. 이제는 백엔드 개발자도 챗GPT를 열고 “API에 사용할 자동 확장과 인그레스를 포함한 헬름 차트를 만들어줘”라고 요청만 하면 AI가 만들어준다”라고 말했다.

이 같은 IaC의 민주화는 많은 실험이 관리의 사각 지대에서 이뤄진다는 것을 의미하기도 한다. 마인드가드(Mindgard)의 최고 마케팅 책임자이자 AI 보안 전문가인 퍼갈 글린은 “많은 개발자들이 특히 자신이 잘 모르는 클라우드 서비스에 대해 챗GPT/코파일럿을 사용해서 IaC 템플릿 초안을 작성한다. 이렇게 하면 작업 속도는 빨라지지만 검토를 거치지 않은 AI 코드는 예를 들어 과도하게 권한을 부여하는 규칙과 같은 보안 틈새를 초래할 위험이 있다”라고 말했다.

페덱스의 소프트웨어 엔지니어 자문 위원이자 선임 클라우드 엔지니어인 밀란쿠마르 라나는 “많은 기업에서 이러한 AI 툴 사용은 처음에는 비공식적이었다. 즉, 엔지니어들이 ‘몰래’ 챗GPT에 리소스 블록을 생성하는 방법이나 오류를 수정하는 방법을 물었다. 그러나 이제는 더 체계적인 도입이 이뤄지고 있다”라고 말했다.

이 변화를 주도하는 주체는 대규모 조직이다. 이들은 AI가 보조하는 IaC의 잠재력을 인정하지만 가드레일 안에 두고 싶어한다. 글린은 “대규모 조직은 예를 들어 토크(Torque)의 코드형 환경(Environment-as-Code)과 같은, 오류를 방지하기 위한 가드레일을 갖춘 AI 증강 플랫폼을 사용한다. 스타트업과 데브옵스 팀은 실험부터 시작하는 경향이 있지만 대기업은 거버넌스 프레임워크를 더 중시한다”라고 말했다.

AI 대세에 합류하는 대기업

인프라 엔지니어링에서 생성형 AI 사용이 확대됨에 따라 이에 대응하기 위해 많은 조직이 생성형 AI 사용을 지도하고 관리하기 위한 내부 툴을 개발하고 있다. 컨플루언트(Confluent)의 선임 데브옵스 엔지니어인 니미샤 메타는 “AI를 선도하는 기술 조직은 AI 플러그인이 있는 IDE와 같은 다양한 툴을 채택하며, 특정 환경에 LLM을 통합하기 위한 맞춤형 시스템과 툴을 구축하는 데 시간과 자본을 투자하기도 한다”라고 말했다.

점차 일반화되고 있는 접근 방식은 내부 AI “플레이그라운드”, 즉 프로덕션 인프라를 위험에 빠뜨리지 않고 팀이 구성을 테스트할 수 있는 샌드박스 환경을 만드는 방식이다. 마인드가드의 글린은 “개발자는 배포 전에 샌드박스에서 IaC 템플릿을 실험하고 결과물을 검증해 오류를 잡아낼 수 있다. 이러한 플레이그라운드는 혁신과 감독 사이에서 균형을 맞춰 보안 틈새와 같은 위험을 최소화하면서 AI 코드형 인프라 워크플로우를 통제된 방식으로 채택할 수 있게 해준다”라고 설명했다.

혼란스러운 초기의 AI 생성 IaC 상황에 대처하기 위해 이러한 내부 툴을 개발하게 되는 경우도 있다. 컨트롤몽키(ControlMonkey)의 CTO이자 공동 창업자인 오리 예미니는 “한 고객이 챗GPT를 사용해 약 80개의 마이크로서비스용 테라폼 파일을 대량으로 생성했다. 작동은 했지만, 나중에 확인해 보니 생성된 코드가 태그 정책, 모듈 규칙, 팀 기반 권한과 같은 기준을 따르지 않는다는 사실이 드러났따. 드리프트 감지 시스템을 실행한 결과 기준 대비 수백 건의 차이가 감지됐다. 코드가 기술적으로 ‘작동’은 했지만, 운영 측면에서 혼란을 초래한 사례”라고 말했다.

해결책은 LLM이 조직의 컨텍스트에 따르도록 한 맞춤형 내부 툴이었다. 예미니는 “이 고객은 통제된 접근 방식으로 전환했다. 즉, 필수 태그, 명명 규칙, 알려진 모듈 저장소와 같은 조직의 컨텍스트를 반영한 프롬프트와 함께 LLM을 감싸는 내부 래퍼를 사용했다. 이렇게 하자 드리프트와 재작업이 비약적으로 줄어들었다”라고 전했다.

생성형 AI와 IaC의 약속과 위험

최상의 경우 생성형 AI는 인프라 작업의 강력한 가속기 역할을 한다. 컨트롤몽키의 예미니는 “엔지니어링 팀이 코드형 인프라에 접근하는 방식에 있어 조용하지만 중요한 변화가 일어나고 있다. 핵심은 단순히 테라폼 코드를 빠르게 작성하는 것이 아니라 갈수록 더 복잡해지는 환경에서 인프라 결정을 가속화하는 것”이라고 말했다. 페덱스의 라나 역시 “과거에는 문서 교차 참조에만 몇 시간씩 걸렸던 일이 이제는 잘 다듬어진 한 번의 지시를 통해 훨씬 더 빨리 수행된다”라고 말했다. 라나는 일반적인 사용 사례로 재사용 가능한 테라폼 모듈 생성, 셸 스크립트를 앤서블 플레이북으로 변환하기, 풀루미 코드를 위한 타입스크립트 스캐폴딩 등을 들었다.

혜택은 코드 생성에 그치지 않는다. 이제 AI는 관찰가능성 시스템과 통합돼 인프라를 실시간으로 관리하는 데 활용되기 시작했다. 마이크로소프트의 베지라주는 “더 발전된 환경에서는 AI 시스템에 텔레메트리를 공급해서 IaC 기반 수정 사항을 제안하거나 아예 자동으로 적용하는 방안이 실험 중이다. 예를 들어 CPU 자원 고갈로 인해 서비스가 반복해서 수평 확장된다면 AI는 CPU 한도를 높이거나 자동 확장 임계값을 변경하는 구성 조정을 제안할 수 있다”라고 설명했다. 이와 같은 기능은 대부분 아직 개념 증명 단계에 있지만 AI가 코드 작성 비서 이상의 역할로 발전할 것임을 가리키는 신호다.

컨플루언트의 메타는 에이전트 AI의 문제 해결 능력을 들어 운영 측면에서도 이와 비슷한 발전이 이뤄지고 있다면서 “네트워크 스택의 여러 계층을 통과해 흐르는 네트워크 패킷이 있다고 가정해 보자. AI는 선택지를 제거해 나가면서 문제의 근본 원인을 정확히 짚어내는 데 탁월하다”라고 말했다. 메타는 아직 초기이긴 하지만 에이전트 AI가 더 자율적이고 자체 복구가 가능한 시스템을 예고한다고 말했다.

그러나 모든 장밋빛 약속에도 불구하고, AI에는 인간 엔지니어가 의존하는 기본적인 속성인 컨텍스트가 아직 없다. 메타는 “AI는 IaC와 YAML 매니페스트를 작성하는 데는 뛰어나지만 현재 가장 큰 단점은 분산된 프로덕션급 인프라가 실제 세계에서 어떻게 설정되는지에 대한 시야가 없다는 점”이라고 말했다. 에이전트 툴은 인프라와 더 직접적으로 통합되는 방식으로 이 문제를 해결하기 시작했지만 메타는 “이는 수천 개의 컴퓨팅 클러스터 규모로 확장되지 않는다”라고 지적했다.

월람의 노비코프는 더 직설적으로, “프롬프트에는 인프라와 설정의 전체 컨텍스트가 반영되지 않는다. 인프라는 규모가 크다. 수십 개의 서비스, 비밀 정보, RBAC 규칙, 사이드카, CI/CD 흐름, 정책, 명명 규칙, 그리고 테라폼 상태의 많은 것들이 포함돼 있다. 이 모든 것을 AI가 알지는 못한다. 이 상태에서 ‘API X를 위한 구성을 작성하라’고 요청하면 아무 컨텍스트 없이 진공 상태에서 작성하게 된다”라고 말했다.

이 진공 상태로 인해 발견하기 어려우면서 피해를 초래할 가능성이 있는 실수가 발생한다. 마이크로소프트의 베지라주는 “AI가 생성한 구성은 구문적으로는 맞지만 의미적으로는 틀릴 수 있다”라고 말했다. 베지라주는 간단한 프롬프트를 기반으로 AI가 작성한 다음과 같은 테라폼 구성 코드를 예로 들었다.

resource "azurerm_storage_account" "example" { 

  name                     = "examplestorageacct1"  

  public_network_access_enabled = true 

}

이 구성은 배포는 성공적으로 되지만 스토리지 계정을 공개 인터넷에 노출시키는 문제도 있다. 베지라주는 “엄격한 네트워크 규칙이나 ID 기반 액세스 제어가 없으면 무단 액세스나 데이터 유출로 이어질 수 있다. 실제 시나리오의 90% 이상에서 공개 네트워크 액세스는 비활성화돼야 한다”라고 말했다.

이와 같은 보안상의 부주의는 결코 이론적 문제에 그치지 않는다. 노비코프는 “구성은 보안 모범 사례를 놓치는 경우가 많다. 요청 횟수 제한이 없고 네트워크 노출 범위가 넓고(0.0.0.0/0) 리소스 제한이 누락되고 CORS가 열리고 내부 API에 대한 인증이 없다”라고 말했다. 한 핀테크 개발자가 내부 API를 위한 인그레스를 생성하기 위해 AI를 사용한 실제 사례가 있다. 베지라주는 “이들은 IP 화이트리스트를 추가하는 것을 깜박 잊었다. 결과적으로 API가 공개되고 20분 만에 스캔됐으며 공격자들이 오래된 디버그 경로를 발견했다”라고 말했다.

AI와 인프라의 미래에 대한 조심스러운 전망

생성형 AI가 인프라 워크플로우의 점점 더 많은 부분에 통합되면서 그 역할도 발전하고 있다. 컨트롤몽키의 예미니는 “중간 규모와 대규모 조직에서 나타나는 한 가지 패턴은 AI가 당장은 ‘1차 초안 생성기’로 사용되지만 의사 결정 지원 툴로 활용되는 경우도 점차 늘고 있다는 것이다. 엔지니어들은 단순히 ‘이 AWS 보안 그룹을 어떻게 작성해야 하나?’라고 묻는 것이 아니라, ‘향후 확장이 가능하도록 이 VPC의 구조를 가장 깔끔하게 설계하는 방법은 무엇인가?’라고 묻는다”라고 말했다. 예미니는 이러한 질문이 초기 설계 단계에 국한되지 않고 스프린트 도중에 실제 장애물에 직면한 상황에서도 나온다는 점을 강조하며 “가장 성공적인 조직은 생성형 AI를 훈련되지 않은 신입 엔지니어처럼 대한다. 즉, 작업 속도를 높이는 데 유용하지만, 검증과 구조, 내부 표준에 대한 관심이 필요하다”라고 말했다.

모든 전문가가 공통적으로 언급한 주제는 인간 감독의 필요성이다. 마이크로소프트의 베지라주는 “엔지니어들은 LLM에서 출력되는 코드를 사용하기 전에 먼저 이해해야 한다”라고 말했다. 컨플루언트의 메타는 가드레일의 중요성을 강조하며 “사람의 실수든 AI가 생성한 변경이든 충돌을 일으키는 변경을 방지하기 위한 가드레일을 마련해야 한다”라고 말했다. 메타는 깃옵스 시스템과 동료 리뷰 기반의 버전 관리를 통해 워크플로우에 책임성을 명확히 구현해야 한다고 지적했다.

마인드가드의 글린 역시 비슷한 패턴을 확인하며 “WISDOM-ANSIBLE과 같은 모델은 자연어 프롬프트만으로 앤서블 플레이북을 생성한다. 그러나 AI가 생성한 YAML/셰프 파일은 경계 사례에 대해 수작업 조정이 필요하다”라고 말했다. 기업은 이러한 툴을 사용해 규정 준수를 강제할 수 있지만(예를 들어 HIPAA 설정을 자동으로 추가) 배포하기 전에 여전히 출력의 정확성을 검토한다.

이와 같은 신중을 기하지 않을 경우 위험이 빠르게 누적될 수 있다. 월람의 노비코프는 “한 대형 SaaS 기업은 이제 IaC의 30%를 AI로 생성한다. 그러나 이와 동시에 CI/CD의 구성 오류(예를 들어 부적절한 비밀 정보 취급, 열린 포트, 잘못된 S3 정책, 보호되지 않는 API 등)도 작년에 비해 3배 증가했다”라고 말했다. 이제 이 기업은 Checkov, tfsec, 맞춤형 월람 규칙과 같은 툴을 사용해 사후에 구성 문제를 포착한다. 그러나 근본 원인은 속도가 안전보다 앞서 나간다는 데 있다. 노비코프는 “한 신입 개발자는 ‘프롬프트를 붙여넣고 출력된 YAML을 봐서 괜찮은 것 같으면 그냥 푸시한다’고 했다. 바로 이 부분에서 문제가 발생한다”라고 말했다.

툴은 점점 더 향상되고 있지만 여전히 주의가 필요하다. 노비코프는 “AI는 매우 강력하다. 그러나 PaaS와 API에서 무분별하게 AI를 사용하는 것은 위험하다. 적절한 정책 확인, 컨텍스트 인식, 테스트가 따르지 않으면 AI가 생성한 구성은 새로운 보안 부채가 된다”라고 경고했다.

노비코프는 “인프라에 AI를 사용하는 것은 좋지만 너무 믿으면 안 된다”라고 덧붙였다.

dl-itworldkorea@foundryco.com

이 기사의 카테고리는 언론사의 분류를 따릅니다.