Security Implications of Infrastructure-as-Code Generation with Large Language Models

대규모 언어 모델 기반 코드형 인프라 생성 보안성 분석

Abstract

Recently, as reliance on Large Language Models (LLMs) has increased across various fields, the efficiency of code generation has improved. However, verification and auditing of the security of the generated code remain insufficient. Particularly, if misconfigurations exist in the security aspects during the Infrastructure as Code (IaC) generation process, they can have severe impacts within cloud infrastructure. Therefore, this study examines the security of IaC generation using LLMs. Specifically, it compares and analyzes the security of generated code based on prompt configuration methods and LLM types, and proposes future improvement directions for LLM-based IaC code generation based on these findings.

최근, 다양한 분야에서 거대언어모델(Large Language Model, LLM)에 대한 의존도가 높아지면서 코드 생성의 효율성은 증가했지만, 생성된 코드의 보안성에 관한 검증 및 감사는 부족한 실정이다. 특히, 코드형 인프라(Infrastructure as Code, IaC) 생성 과정에서 보안 측면의 잘못된 구성이 존재할 경우, 클라우드 인프라 내 심각한 영향을 미칠 수 있다. 따라서, 본 연구에서는 LLM을 활용한 IaC 생성의 보안성을 검토한다. 구체적으로, 프롬프트 구성 방식과 LLM 종류에 따라 생성된 코드의 보안성을 비교·분석하고, 이를 바탕으로 향후 LLM 기반 IaC 코드 생성의 개선 방향을 제안한다.

I. 서론

클라우드 컴퓨팅 기술은 다양한 산업에서 디지털 전환의 핵심 요소로 자리 잡았으며, 이에 따라 클라우드 인프라에 대한 자동화된 관리 효율성 향상을 위한 코드형 인프라(Infrastructure as Code, IaC)의 활용이 급격히 증가하고 있다[1]. IaC는 선언형 구문을 통해 퍼블릭 클라우드, 프라이빗 클라우드, 멀티 클라우드 등 다양한 클라우드 환경에서의 자원 프로비저닝을 자동화함으로써, 구성 오류를 줄이고 배포 효율성을 높이는 방식으로 현대의 DevOps 파이프라인 내 클라우드 인프라 구축의 실질적인 표준으로 자리매김하고 있다[2].

한편, 최근 급부상한 대규모 언어 모델(Large Language Model, LLM)은 인간 수준의 자연어 이해 및 코드 생성 능력을 기반으로 다양한 개발 업무에 활용되고 있으며[3], IaC 코드와 같은 선언형 코드 자동 생성을 위한 에이전트로서의 가능성 또한 보여주고 있다. 특히 LLM을 활용한 IaC 생성은 클라우드 시스템에 대한 전문성 없이도 비전문가가 클라우드 인프라를 구축하는 데 사용할 수 있으며, 다양한 배포 환경에서의 생산성과 접근성을 향상할 수 있는 잠재력을 가진다.

그러나 IaC 코드에서의 보안 구성 오류(misconfiguration)는 사소한 지시의 누락만으로도 빈번히 발생하며, 잘못된 네트워크 접근 제어, 암호화 설정 누락, 과도한 IAM 권한과 같이 배포 즉시 심각한 위협으로 이어질 수 있다. LLM 기반 자동 생성이 확산되면서 이러한 구성 오류를 내포하는 코드가 곧바로 인프라에 반영되는 경로를 통해 증폭될 위험도 존재한다. 그러나 LLM 기반 IaC 생성 성능에 대한 기존 평가는 주로 배포 가능성을 중심으로 하거나, 개별 보안 옵션의 반영 여부만 점검하는 경향이 있어 실행 가능성과 보안성을 함께 정량적으로 다루는 통합 평가는 상대적으로 부족하다.

본 연구는 이러한 공백을 메우기 위해 LLM이 생성한 IaC 코드의 기능적 유효성과 보안성을 동시에 평가하려는 방안을 제안한다. 구체적으로 AWS(Amazon Web Service) 내 3개의 대표적 클라우드 리소스에 대해 각 10개씩 클라우드 활용 시나리오별 프롬프트를 생성, 대표적 LLM 서비스인 GPT‑4o, Claude 3, Gemini 1.5에 각각 적용하였다. 모델은 실무에서의 접근성과 활용 빈도를 고려하여 선정되었으며, 특히 코딩에 특화된 LLM이라 하더라도 리소스 간 의존성과 설정 관계를 포함하는 선언형 IaC 코드를 안정적으로 생성할 수 있는 지에 대한 보장이 없다는 점이 주요 고려 요인으로 작용하였다. 또한, 단순 보안 강화를 요청하는 표현을 프롬프트에 포함했을 때 코드의 유효성과 보안 품질이 실제로 개선되는지도 함께 검증하였다.

실험 결과, ‘보안을 강화하라’는 추상 지시만으로는 IaC 내 취약점의 유의미한 감소가 관찰되지 않았고, 오히려 취약점 수 및 심각도가 커지는 경우도 존재했다. 이를 통해 단순한 프롬프트 내 추상적 보안 강화 요청은 정적 규칙 일부를 충족시키는 방향으로 코드를 변화시킬 수는 있으나, 전체 보안 수준을 개선하지 못함을 확인하였다. 분석 결과를 바탕으로, 본 연구에서는 구조화 프롬프트와 RAG 기반 맥락 주입 등 LLM 기반 IaC 생성을 위한 프롬프트 평가의 구조화 전략을 제안한다.

본 논문의 구성은 다음과 같다. 2장에서는 LLM 기반 IaC 코드 생성과 관련된 기존 연구 및 보안 취약점 분석 도구의 활용 현황을 정리하고, 3장에서 실험 설계 및 평가 방법론을 기술한다. 4장에서는 다양한 프롬프트 유형과 LLM 모델별로 생성된 IaC 코드에 대한 기능적 실행 가능성과 보안성 평가 결과를 분석하고, 5장에서는 보안성을 향상하기 위한 프롬프트 설계 전략 및 평가 체계 개선 방향 등을 고찰한다. 마지막으로 6장에서는 본 연구의 시사점과 함께 향후 연구 방향을 제시한다.

II. 관련 연구

2.1 LLM을 활용한 코드 생성 성능 연구

LLM을 활용한 코드 생성 연구는 주로 Python과 같은 범용 프로그래밍 언어를 중심으로 활발히 이루어져 왔다. Chen et al. [4]는 GPT-3 기반의 Codex 모델을 이용해 Python 문제 해결 능력을 평가하는 HumanEval 벤치마크를 제안하였으며, 생성된 코드가 테스트 케이스를 통과하는 비율(Pass@k)을 주요 성능 지표로 활용하였다. 이 연구는 표면적 유사성 지표(BLEU 등)보다 기능적 동등성에 기반한 평가가 LLM의 실질적 코드 생성 능력을 더 적절히 반영함을 보여주었다. 이처럼 일반적인 코드 생성 연구에서는 생성된 코드의 정확도, 실행 가능성, 효율성을 중심으로 평가가 이루어지고 있으며[5][6], 이를 평가하기 위한 지표 또한 활발히 연구되고 있다.

한편, 여상엽 외 5인 [7]은 다양한 프롬프트 구성방식이 코드 품질에 미치는 영향을 분석하였다. 그 결과, 입력-출력 예제와 명확한 제약 조건을 포함한 구조화된 프롬프트가 단순 자연어 지시보다 더 높은 품질의 코드를 생성하는 데 효과적임을 확인하였다. 이는 LLM이 명시적 제약과 맥락 정보를 통해 더 안정적이고 일관된 코드를 생성할 수 있음을 시사한다.

2.2 IaC 코드 생성 및 보안성 문제

IaC의 경우, 컴파일 및 실행이 목적인 범용 프로그래밍 언어와 다르게 실제 클라우드 인프라에 대한 정의 및 리소스를 배포하는 데 활용된다. 대상이 되는 클라우드 환경에 적합한 IaC를 사용하지 않을 경우, 코드 자체가 문법적인 오류가 없는 경우라고 하더라도 사용 자체가 불가능한 경우가 존재한다. 따라서, 코드의 유효성 및 적용 가능 여부 자체가 평가 항목에 포함되어야 한다.

이러한 IaC 특수성을 반영하여 제안된 IaC-Eval[8]은 자연어 요구사항에 따라 생성된 IaC 코드가 실제로 배포 가능한지를 ‘terraform plan’ 명령 등을 통해 평가하며, 구문적 완결성과 명세 충족 여부도 함께 확인한다. 그러나 IaC-Eval은 코드의 보안성을 별도로 고려하지 않는다는 한계가 있다. 코드가 배포될 수 있더라도, 암호화 누락, 권한 과다 부여, 로깅 미설정 등 보안 구성의 부적절함이 존재할 수 있으며, 이러한 보안 결함은 클라우드 환경에서 실질적인 위협으로 이어질 수 있다.

이러한 문제를 직접적으로 다룬 연구로는 Pujar[9]의 연구가 있다. 해당 연구는 보안 요구사항과 관련된 구성(configuration) 옵션을 포함하는 다양한 프롬프트를 구성하고, LLM이 생성한 Terraform 코드가 해당 보안 설정을 제대로 반영하는지를 실증하였다. 그 결과, 생성된 코드 다수에서 보안 속성이 누락되거나 불완전하게 적용되는 현상이 나타났으며, 이는 LLM이 보안 지시어의 의미를 깊이 이해하지 못하고 단순 키워드로 처리하는 데 그치고 있음을 시사한다.

이처럼, 기존 연구들은 각각 실행 가능성 중심 평가 또는 보안 반영 여부 확인에 초점을 맞추고 있을 뿐, 실행 가능성과 보안성을 동시에 고려하며 정량적으로 평가하는 통합적 연구는 미비한 상황이다. 따라서 본 연구는 LLM이 생성한 IaC 코드에 대해 실행 가능성과 더불어 보안성까지 종합적으로 평가할 수 있는 실험 체계를 설계하고, 보안 중심 프롬프트 구성 방식이 코드 품질에 미치는 영향을 실증적으로 분석하고자 한다.

III. LLM 생성 IaC 코드의 보안성 평가

3.1 실험 설계 개요

본 연구에서는 LLM을 활용한 코드형 인프라(IaC) 자동 생성 과정에서 생성된 코드의 기능적 성능과 보안성을 종합적으로 평가하고 분석하고자 한다. 이를 위해 IaC-Eval 논문에서 제안한 벤치마크 프롬프트 구성 방식을 참고하여, 대표적 퍼블릭 클라우드 서비스인 AWS(Amazon Web Service)에서 실제 사용 비중이 높은 리소스인 IAM(Identity and Access Management), S3 Bucket, VPC(Virtual Private Cloud)를 중심으로 실험 파이프라인을 설계하였다.

선정된 세 가지 리소스는 다양한 클라우드 환경에서 빈번히 사용되는 동시에, 구성 오류(misconfiguration) 발생 시 심각한 보안 취약점으로 이어질 수 있는 항목들이다. IAM은 권한 오남용 관련 보안 위험이 크며, S3 Bucket은 퍼블릭 접근 및 암호화 누락과 같은 구성 오류가 빈번히 발생한다. VPC는 외부 노출 경로의 잘못된 설정이나 피어링(peering) 연결의 과도한 개방 등의 오류가 있으면, 네트워크 기반 공격의 표적이 될 수 있다. 실험 과정에서 생성된 IaC의 보안성 달성 여부 상황을 다변화 확인하기 위해 리소스 유형별로 각 10개의 프롬프트 테스트 케이스를 구성 후 진행하였다.

프롬프트는 리소스 생성에 필요한 조건을 자연어(영문)로 설명하는 방식으로 구성되었으며, 각 리소스의 사용 목적과 주요 보안 고려 사항을 반영하여 실무적으로 사용되는 클라우드 배치 시나리오 기반으로 설계되었다[10]. 해당 프롬프트는 단순한 리소스 생성부터 정책 부착, 연결 구성, 액세스 제어, 로깅 및 모니터링 설정 등 다양한 요구사항을 포함한다. 예를 들어, IAM 리소스에는 사용자/그룹/정책 생성, MFA 및 SSH 키 설정, Lambda 또는 RedShift와의 연동이 포함되며, S3 Bucket 리소스는 객체 업로드, 버전 관리, 인벤토리 및 메트릭 설정, 정책 적용 등 다양한 운영 목적을 반영한다. VPC의 경우 피어링 연결 구성뿐만 아니라, 인터넷 게이트웨이 및 라우팅 설정, 전용 서브넷 구성, 네트워크 ACL 등 보안 중심 네트워크 설계 요소까지 포함되었다.

이러한 프롬프트 설계를 통해 실제 인프라 운영에서 자주 요구되는 보안 구성 요소들을 LLM이 어떤 방식으로 이해하고 코드화하는지를 더 정밀하게 평가할 수 있도록 하였다. Table 1은 각 리소스 유형별로 사용된 세부 Terraform 리소스 구성을 요약한 표이다.

Table 1. Resource Types Used in the Experiment

또한, 각 케이스의 동일한 시나리오에 대해 ‘robust’라는 문구를 삽입하여 보안을 고려한 코드 생성을 유도하는 Robust 프롬프트 버전을 추가로 구성하였다. ‘robust’라는 문구는 보안 관점과 기능 관점을 아울러 강한 코드를 생성하게끔 하기 위해 사용하였다. Fig. 1는 동일한 기본 프롬프트를 Robust 프롬프트로 확장한 예시이다.

Fig. 1. Generating Robust Prompt from Basic Prompt

이를 통해 각 리소스 유형당 실험적으로 비교가 쉽도록 10개의 케이스를 구성하였으며, 3개 리소스 × 10 케이스 = 총 30개의 프롬프트가 구성되었다. 전체적으로 2개 버전 × 30개 프롬프트로 총 60개의 프롬프트가 최종 실험에 활용되었다. 이후 다양한 LLM에서의 생성 효율성을 비교하고 분석하기 위해, 해당 프롬프트들을 각각 GPT-4o[11], Claude 3[12], Gemini 1.5[13] 모델에 적용하여 총 180개의 Terraform 코드 샘플을 생성하였다.

3.2 기능적 실행 가능성 평가 절차

생성된 각 코드에 대해서는 먼저 기능적 실행 가능성을 평가하였다. 이를 위해 HashiCorp에서 제공하는 IaC 도구인 Terraform의 핵심 명령어인 ‘terraform init’과 ‘terraform plan’을 사용하여, 코드가 실제로 클라우드 리소스를 유효하게 정의하고 배포할 수 있는지를 확인하였다. 이중 ‘terraform plan’ 명령은 코드 실행 전 인프라 변경 사항을 예측해 출력해 주는 툴체인으로, 작성된 코드의 유효성과 논리 구조를 사전 검증할 수 있게 해준다.

해당 명령어가 별도의 수정 없이 오류 없이 실행되어 인프라 변경 사항을 출력할 경우, 이를 ‘Pass@1’로 분류하였다. 만약 첫 실행에서 오류가 발생했지만, 오류 메시지를 바탕으로 동일한 프롬프트를 다시 LLM에 입력하여 수정된 코드를 요청한 뒤 재실행을 통해 성공한 경우는 ‘Pass@2’로 포함하였다. 두 차례 시도 후에도 여전히 실행 불가능한 경우는 ‘Non-Pass(NP)’로 분류하였다. 이와 같은 분류 기준은 실제 IaC 코드 작성 및 디버깅 과정의 현실성을 반영하여, LLM의 코드 생성 능력을 실용적 관점에서 평가하기 위함이다.

3.3 보안성 평가 절차 및 실험 파이프라인

기능적으로 실행 가능하다고 판별된 코드에 대해서는 추가로 보안성 평가를 수행하였다. 보안 분석에는 Terraform 코드에 특화된 정적 분석 도구인 tfsec을 활용하였으며[14], 분석 대상은 Pass@1과 Pass@2로 분류된 코드 전체이다. 각 코드는 AWS 리소스의 보안 구성 오류를 기준으로 tfsec의 룰셋에 따라 검사되었고, 결과는 취약점의 심각도에 따라 Critical, High, Medium, Low로 분류되었다. 동시에 위반되지 않은 보안 규칙 수는 Passed로 계량화된다.

본 연구에서 수행한 전체 실험 프로세스는 Fig, 2과 같다. 실험은 LLM이 생성한 초기 코드를 ‘terraform init’과 ‘terraform plan’으로 실행하여 Pass@1 여부를 판단하는 단계로 시작된다. 실패 시에는 같은 프롬프트를 기반으로 다시 LLM에 코드를 요청하고, 수정된 코드에 대해 재평가를 진행한다. 두 차례의 시도 내에 실행이 가능해진 경우 Pass@2로 분류되며, 실패할 경우 NP로 종료된다. Pass@1과 Pass@2로 분류된 코드는 하나로 통합되어 tfsec을 통해 보안성 분석을 수행하며, 결과적으로 보안 취약점의 유형 및 빈도를 정량적으로 비교·분석한다.

Fig. 2. Security Evaluation Experiment Pipeline

추가로 다양한 LLM에 대한 종합적인 IaC 생성 성능 및 보안성 평가를 위해, 각 LLM이 생성한 코드의 Pass 및 Non-Pass 분포를 분석하여 모델 간 상대적인 실행 성능을 비교하였다. 보안성 평가 결과를 바탕으로, 공통으로 반복되는 보안 취약점 유형을 도출하고 이를 체계적으로 분류하였다. 아울러 동일한 프롬프트 구체성 조건 내에서 ‘robust’ 문구의 포함 여부가 코드의 실행 가능성과 보안 취약점 발생에 미치는 영향을 정량적으로 분석함으로써, 향후 LLM 기반 IaC 코드 생성을 위한 효과적인 프롬프트 설계 전략에 대해 실무적인 시사점을 제시하였다.

IV. 실험 결과 및 분석

4.1 모델별 인프라 배포 가능성 비교

세 가지 비교 대상 LLM 모델인 Claude, GPT-4o, Gemini가 생성한 IaC의 배포 가능성 및 유효성 평가를 위해 각 60개의 IaC 생성 요청을 수행한다. 이후 생성된 코드를 활용하여 ‘terraform plan’ 명령을 기준으로 기능적 실행 가능성을 평가하였다. 초기 생성된 총 180개의 코드 중, 보안성 평가(tfsec)를 수행할 수 있었던 유효한 샘플은 총 139개로 집계되었다.

모델별 코드 생성 정확도는 Table 2와 같다. Claude와 GPT-4o는 첫 시도만으로도 각각 71.6%, 75%로, 상대적으로 높은 배포 가능성을 보였다. 반면, Gemini는 첫 시도 성공률이 25%로 낮았고, 재시도를 통해 일정 수준의 회복이 가능함을 보였으나 여전히 많은 양의 NP 코드(전체의 35%)가 생성되었다. 이는 Claude와 GPT-4o가 보다 일관되게 인프라 구성을 생성하는 데 강점을 가지며 Gemini는 생성 코드의 구조적 완성도가 부족한 경향을 보였음을 시사한다.

Table 2. Code Generation Accuracy per LLM

4.2 프롬프트별 인프라 배포 가능성 비교

한편, Fig. 1과 같이 Basic/Robust 프롬프트 유형에 따른 전체 인프라 배포 성공률(pass 기준)을 비교한 결과, Robust 프롬프트가 모든 경우에서 더 높은 배포 안정성을 보장하지는 않는 것으로 나타났다.

Table 3에 제시된 실행 실패율(NP 비율)을 보면, Robust 프롬프트의 실패율은 각각 26.7%, 13.3%, 33.3%로 세 모델 모두에서 Basic 프롬프트(각각 13.3%, 13.3%, 30.0%)보다 높거나 동일한 수준에 그쳤다. 특히 Claude의 경우 Robust 프롬프트에서 실행 실패율이 많이 증가했으며, GPT-4o만이 두 프롬프트 간 차이를 보이지 않았다. 이는 때에 따라 구체적인 보안 요구 사항을 구체적으로 명시하지 않은 형태의 안전한 코드 생성 요청이 오히려 생성 코드의 길이를 늘이고, 코드 구조를 복잡하게 만들어 배포 안정성 및 코드의 유효성을 저해할 수 있음을 시사한다.

Table 3. Code Generation Accuracy per Prompt (NP rate)

4.3 프롬프트별 보안성 확보 여부

각 리소스 유형별로 Robust 버전의 코드 생성이 tfsec 보안성 평가 결과에 대한 개선으로를 평가하기 위해 모델별로 테스트할 수 있는 세트를 일차적으로 필터링하였다. Robust와 Basic 코드를 하나의 세트로 묶고, 동일 샘플 내에서 Robust 또는 Basic 프롬프트 중 어느 하나라도 실행 불가로 판정된 케이스는 총 30건으로 확인되었다. 이에 따라 Robust와 Basic 모두 실행 가능한 총 60개의 케이스만을 기준으로, tfsec을 활용한 정적 분석을 수행하였다. 그 결과, 프롬프트 유형에 따른 위험도 수준의 개선 차이가 분명히 드러났다.

Table 4와 같이, 60개의 샘플 중 16개의 샘플을 제외하고는 모두 Robust 프롬프트가 Basic 프롬프트보다 취약점을 전혀 개선하지 않았으며, 오히려 취약점의 수가 늘어나는 경우도 존재했다. 취약점의 심각도 및 개수가 Basic보다 Robust가 큰 샘플들은 총 44개로 절반가량에 해당하는 높은 비율을 차지한다.

Table 4. Robust vs Basic; Number of vulnerability improvement failures

실험 결과에서 흥미로웠던 결과는 케이스별 passed 수였다. tfsec에서 ‘passed’는 해당 인프라 코드가 특정 보안 규칙을 만족했음을 의미한다[14]. 즉, 보안 점검 항목 중 하나에 대해 코드가 취약하지 않다고 판단되어 통과 처리된 항목의 개수를 나타낸다. 이 수치는 코드가 얼마나 많은 보안 규칙을 준수하고 있는지를 정량적으로 보여주며, 보안성의 긍정적인 측면을 평가할 수 있는 지표로 활용된다.

Table 5는 배포할 수 있는 코드 중, 보안성 검사에서 Passed 규칙 수가 Basic보다 Robust 프롬프트에서 더 많았던 샘플들을 집계한 결과를 나타낸다. 세 모델 모두 절반에 가까운 케이스에서 Robust 프롬프트가 Basic보다 더 많은 보안 규칙을 통과하는 경향을 보였으며, 이는 Robust 프롬프트가 LLM으로 하여금 보다 많은 보안 규칙을 준수 하도록 유도했음을 시사한다. 그러나 취약점 수에는 뚜렷한 개선이 없고 오히려 취약성을 늘린 케이스도 많다는 점을 고려할 때, Passed 수의 증가가 반드시 전체적인 보안 수준의 향상을 의미하지 않는다고 볼 수 있다.

Table 5. Number of ‘Passed'

따라서 보안을 강화하라는 프롬프트가 정적 분석 도구의 규칙 일부를 만족시키는 방향으로 코드를 수정하게 만들 수는 있으나, 실제로 시스템의 보안성을 향상하는 방식으로 반영되지는 않았을 가능성을 시사한다.

V. 논의 및 고찰

본 연구에서는 다양한 LLM을 활용하여 프롬프트를 다변화하고, 이에 따라 생성된 IaC 코드의 보안성을 평가하였다. 그 결과, 단순히 “보안을 강화해달라”는 추상적인 지시만으로는 실제 보안성 향상에 효과적이지 않음을 확인할 수 있었다. 오히려 이러한 요청은 불필요한 리소스를 추가하거나 과도한 권한을 부여하는 등 구성의 복잡성과 취약성을 증가시키는 역설적인 결과를 초래하였다. 이는 LLM이 보안 요구를 규범적으로 해석하지 못하고, 정적 분석 도구의 단편적인 규칙만을 만족시키는 방식으로 코드를 구성했기 때문으로 해석된다.

따라서 향후 IaC 코드 생성을 실무적으로 활용하기 위해서는 프롬프트 설계 방식 및 코드 생성 과정의 구조적 개선이 필수적이다. 다음 네 가지 측면에서 프롬프트 구조와 LLM 응답의 보안성을 향상할 방안을 제안한다.

RAG Knowledge Base: LLM이 실질적인 보안 규칙을 이해하고 적용할 수 있도록 하기 위해서는, 단순히 “보안성을 높여달라”는 요청이 아니라 구체적인 보안 기준을 명시해 주는 것이 중요하다. 이를 위해 RAG(Retrieval-Augmented Generation)를 활용하여 LLM에 신뢰할 수 있는 보안 기준 문서를 참조하도록 하는 전략이 효과적일 수 있다. 예를 들어, CIS AWS Benchmark[15], Terraform best practices[16], tfsec의 각 보안 rule 설명서 등과 같은 보안 지식 기반을 구축하고, LLM이 해당 기준을 바탕으로 코드 생성을 수행하도록 유도하는 것이다. 이 방식은 보안 취약점의 의미를 LLM이 더 정밀하게 해석하고 적용하는 데 도움을 줄 수 있다.

Prompt 구조 강화: 단순한 자연어 요청만으로는 LLM이 사용자의 의도를 오해하거나, 취약한 구조를 반복 생성할 가능성이 크다. 따라서 프롬프트는 단일 요청문이 아니라, 다음과 같은 요소를 포함한 구조화된 형태로 구성되어야 한다.

• 사용자의 명시적 요청

• 해당 시나리오의 요약된 보안 요구사항

• 보안 취약 코드 예시 또는 기존 생성 코드 내 취약 부분

• 지켜야 할 보안 규칙/행동 지침

이러한 방식은 Chain-of-Prompting 또는 multi-context prompting이라고도 하며, 최근 보안 분야에 특화된 LLM 활용에서 주목받고 있다. 향후 LLM 기반 보안 코드 생성을 실무에 적용하기 위해서는, 이러한 구조적 프롬프트 설계 전략을 적극적으로 고려할 필요가 있다.

보안 룰 기반 평가: 본 연구의 실험을 통해 IaC 코드의 보안성을 평가하는 기존 접근 방식에 한계가 있음을 확인할 수 있었다. 특히, 기존 도구들에서의 명령어를 통해 출력하는 결과만으로는 코드의 실질적인 보안 수준을 정확히 판단하기 어렵다는 점이 드러났다. 따라서 향후 연구 및 실무 적용을 위해서는 단순히 도구 기반의 수치 지표에 의존하는 것을 넘어, 각 구성 요소별 보안 위험의 실질적 완화 여부를 평가할 수 있는 정량적·정성적 평가 기준이 마련되어야 한다. 이러한 새로운 평가 체계를 통해서만 LLM 기반 IaC 코드의 보안성을 정밀하게 진단하고, 보다 실효성 있는 개선 방향을 도출할 수 있을 것이다.

Domain Filtering: 모든 리소스 유형에 동일한 보안 맥락을 적용하는 것은 효율성 및 보안성이 오히려 떨어질 수 있으므로, 각 리소스가 가지고 있는 고유한 보안 요구사항에 맞춰 context를 구성하는 것이 바람직할 것으로 보인다. 리소스별 보안 관점이 분리되어야 LLM도 더 정확하고 목적성 있는 코드를 생성할 수 있을 것이다.

VI. 결론

본 연구는 LLM 기반 IaC 코드 생성의 보안성을 실증적으로 평가하기 위해, 대표적인 AWS 리소스 3개를 대상으로 다양한 프롬프트를 구성하고, GPT-4o, Claude 3, Gemini 1.5 등의 최신 LLM 모델을 활용한 실험을 수행하였다. 특히 ‘보안을 강화해 달라’는 의미를 프롬프트에 함의한 경우가 실제로 보안성에 어떤 영향을 미치는지에 대해 기능적 실행 가능성과 정적 분석 결과를 종합하여 분석하였다.

실험 결과, 보안성 강화를 요구하는 프롬프트는 위험도 수준이 높은 보안 취약점 수에는 유의미한 개선을 가져오지 못했으며, 오히려 특정 리소스에서는 취약점이 증가하는 역효과도 나타났다. 이는 LLM이 보안성을 추상적으로 해석하거나 표면적인 규칙 충족에만 집중한 나머지, 실질적인 보안 위협을 해소하지 못하는 구조를 반복 생성하고 있음을 보여준다.

이러한 결과는 단순한 자연어 요청만으로는 보안 측면에서 안전한 IaC 코드를 생성하는 데 한계가 있으며, 프롬프트 설계 방식에 대한 재고가 필요함을 시사한다. 따라서 보안성이 중요한 환경에서는 단일 지시문이 아닌, 사용자의 보안 요구사항, 시나리오 맥락, 취약 코드 예시, 구체적 행동 지침 등을 포함한 구조화된 프롬프트 설계가 요구된다. 이는 Chain-of-Prompting이나 Multi-context Prompting 등의 방식과도 맞닿아 있으며, 향후 보안 특화 LLM 활용 연구에 있어 중요한 방향성을 제공한다. 또한, 본 연구는 정적 분석 기반 정책 위반 검증을 통해 IaC 코드의 보안성을 정량적으로 평가하는 기초를 마련하였다. 이를 토대로, 정책 위반이 실제 보안 침해 시나리오와 어떤 연관성을 가지는지를 MITRE ATT&CK 프레임워크와 연계하여 심화 검증하는 등의 연구로 확장할 수 있을 것이다.

다만, 본 연구는 AWS 리소스에 한정하여 수행되었기 때문에, 관찰된 결과가 리소스 특성에 기인한 것인지, 사용된 LLM 모델의 한계에서 비롯된 것인지 명확히 구분하기는 어렵다. 기능적 완결성은 리소스의 제약에 영향을 받을 수 있으나, 보안성 확보는 프롬프트에 담긴 정보의 구체성과 설계 방식에 크게 의존한다. 이에 따라 후속 연구에서는 AWS 이외의 다양한 리소스와 클라우드 환경을 포함한 비교 분석이 필요하며, 보안 취약점을 정밀하게 감지할 수 있는 평가 도구의 결합, 특정 리소스 유형에 특화된 평가 기준, 그리고 보안 도메인에 특화된 LLM 파인 튜닝(fine-tuning) 전략 등을 종합적으로 탐색하여 IaC 자동 생성의 실질적 안전성과 신뢰성을 확보할 계획이다.