1. 서론
최근 클라우드 기반 인프라 환경의 확산과 함께 DevOps 및 클라우드 보안 역량에 대한 수요가 빠르게 증가하고 있다. 특히 인프라 자동화, 애플리케이션 배포 자동화뿐만 아니라, 인공지능 서비스와 클라우드 보안이 통합된 복합 아키텍처를 구현할 수 있는 실전 능력은 클라우드 네이티브 시대의 핵심 역량으로 부상하고 있다. 본 논문은 Terraform과 Ansible을 연계하여 DevOps 기반의 인프라 및 애플리케이션 자동화 실습 환경을 설계하고, Flask 기반 인공지능 웹 애플리케이션을 보안이 고려된 클라우드 인프라 상에 자동 배포하는 전 과정을 구현함으로써, 해당 역량을 효과적으로 교육할 수 있음을 보여준다. 본 연구는 다음의 목적을 지닌다.
첫째, Terraform을 활용한 AWS 기반 인프라 자동화 실습을 통해 IaC(Infrastructure as Code) 기반 보안 구성 원칙, 예를 들어 서브넷 분리, 보안 그룹 설정, 키페어 기반 인증 등의 보안 설계 절차를 학습할 수 있도록 한다.
둘째, Ansible을 활용하여 EC2 기반 웹 애플리케이션을 자동 배포하고, 보안 강화를 위한 접근 제어 및 서비스 기동 설정을 자동화함으로써 구성 관리 도구의 실제 적용 가능성과 보안 연계 방안을 제시한다.
셋째, Flask와 Gemini API를 활용한 AI 서비스 개발을 클라우드 인프라 상에 통합함으로써, AI 서비스와 인프라 보안의 상호작용, 예컨대 환경 변수 기반의 API 키 관리 및 민감정보 보호 절차를 실습할 수 있는 통합적 교육 모델을 제안한다.
이러한 실습은 단일 기술 습득을 넘어, DevOps 엔지니어가 실무 환경에서 직면하는 인프라 구성, 보안 설정, 서비스 배포, AI 통합 등의 복합 문제를 효과적으로 해결할 수 있는 실전 역량을 배양하는 데 초점을 둔다.
본 논문은 위 실습 환경의 설계와 구현, 교육 효과 분석 및 향후 DevSecOps 확장 방향까지 체계적으로 제시함으로써, 자동화 기반 클라우드 보안 교육 모델로서의 실현 가능성을 논의한다.
2. 관련 연구
2.1 DevOps와 인프라 자동화 관련 연구
최근 클라우드 기반 인프라 환경의 확산과 함께 DevOps 및 클라우드 보안 역량에 대한 수요가 빠르게 증가하고 있다. 특히 인프라 자동화, 애플리케이션 배포 자동화뿐만 아니라, 인공지능 서비스와 클라우드 보안이 통합된 복합 아키텍처를 구현할 수 있는 실전 능력은 클라우드 네이티브 시대의 핵심 역량으로 부상하고 있다. Terraform, Ansible과 같은 IaC(Infrastructure as Code) 도구는 구성의 재현성과 일관성을 확보할 수 있는 방식으로 주목받고 있으며, 클라우드 인프라의 자동화와 운영 효율성을 동시에 향상시키는 데 기여하고 있다.
Smith et al.(2023)은 Jenkins와 Ansible을 연계한 CI/CD 자동화 실험을 통해 배포 오류율과 시간을 각각 30%, 40% 이상 절감하였으며, Role 기반 Playbook 설계와 변수 분리를 통해 자동화의 유지보수성과 교육 효과를 강조하였다. 본 연구는 Jenkins 대신 Terraform을 활용하여 인프라 계층까지 자동화 범위를 확장하였고, Gemini 기반 AI 웹앱을 실습에 포함함으로써 DevOps 실습의 폭을 넓혔다.
Wiedemann et al.(2018)은 DevOps 교육에서 실습 중심 커리큘럼이 DevOps 문화와 도구의 이해에 효과적이라는 점을 입증하였다. 이들은 Jenkins, GitLab, Docker, Kubernetes 등 다양한 도구를 통해 협업, CI/CD, 자동화의 전 과정을 체험하게 하였으며, 학습자 설문을 통해 교육 효과를 분석하였다. 본 연구 역시 Terraform과 Ansible을 기반으로 한 자동화 실습을 통해 이러한 교육 흐름을 따르고 있다.
또한 Linares-Vásquez et al.(2022)는 DevOps 교수진 인터뷰를 통해 실무 도구 중심의 실습 구성의 필요성을 강조하였으며, Ferino et al.(2023)은 협업 기반 학습과 반복 가능한 실습 구조가 DevOps 교육에 효과적이라는 점을 제시하였다. 본 연구는 이러한 교육 전략을 수용하여, 인프라 자동화, 애플리케이션 배포, AI 기능 통합을 포함한 통합형 DevOps 실습 환경을 설계하였다.
마지막으로 Aly et al.(2021)은 Ansible, Chef, Puppet 등 자동화 도구의 활용이 조직의 배포 신뢰성과 반복 가능성 향상에 기여한다고 보았으며, 이는 DevOps 자동화가 교육 현장에서도 실무 연계성을 높이는 수단임을 시사한다.
본 연구는 이러한 자동화의 효과를 교육 모델로 확장하여, Terraform과 Ansible 기반 DevOps 실습 구조의 교육적 타당성과 확장 가능성을 실증적으로 제시한다.
2.2 Terraform과 Ansible의 기술 개요 및 비교
Terraform과 Ansible은 각각 인프라 프로비저닝과 구성 관리를 위한 도구로 널리 사용된다. Terraform은 선언형 언어를 기반으로 인프라 리소스를 정의하고, 이를 통해 일관된 환경 구성이 가능하다. 반면, Ansible은 에이전트리스 구조를 채택하여 SSH를 통해 원격 시스템의 구성 및 애플리케이션 배포를 자동화한다. 일반적으로 Terraform은 인프라의 초기 설정에 적합하며, Ansible은 운영 중인 시스템의 관리 및 애플리케이션 배포에 효과적이다. 두 도구는 상호 보완적으로 사용되어 전체 인프라 및 애플리케이션의 자동화를 실현할 수 있다.
2.3 인공지능 서비스의 클라우드 인프라 요구사항
인공지능 기반 서비스는 높은 연산 성능과 유연한 확장성을 요구한다. 이를 위해 클라우드 인프라는 GPU 지원 인스턴스, 컨테이너 오케스트레이션(Kubernetes 등), 그리고 지속적인 데이터 파이프라인을 지원해야 한다. 또한, AI 모델의 학습 및 배포를 위한 MLOps(Machine Learning Operations) 체계가 필요하며, 이는 데이터 수집, 모델 학습, 검증, 배포, 모니터링의 전 과정을 자동화하는 데 중점을 둔다. 이러한 요구사항을 충족하기 위해서는 인프라의 자동화와 함께 보안, 확장성, 유지보수성을 고려한 설계가 필수적이다.
2.4 기존 교육 및 실습 사례 분석
기존의 DevOps 교육 및 실습 사례는 주로 CI/CD 파이프라인 구축, 컨테이너화, 기본적인 인프라 자동화에 초점을 맞추고 있다. 그러나 AI 서비스를 포함한 통합형 실습 구성이나, 기초 보안 설계를 함께 고려한 실습 구조는 여전히 부족한 실정이다. 최근 Terraform과 Ansible을 활용한 자동화 실습 사례는 증가하고 있으나, 대부분 인프라나 배포에 국한되어 있으며, 클라우드 보안 설정과 AI 응용의 연계까지 포함하는 사례는 드물다.
이에 본 논문은 Terraform과 Ansible을 기반으로 한 자동화 실습 환경에, 퍼블릭/프라이빗 서브넷 분리, 보안 그룹 설정, SSH 인증 등 기초적인 보안 설정을 포함하고, Flask 및 Gemini API 기반의 AI 웹 애플리케이션 자동 배포까지 실현하는 실습 구조를 제안한다. 이러한 통합 실습은 학습자가 인프라 구성과 애플리케이션 배포뿐 아니라, 기초적인 클라우드 보안 개념과 설정 원리까지 함께 경험할 수 있도록 구성되었다.
또한 실습 과정은 코드 기반 구성의 반복 실행과 오류 복원성을 강조하여, 수동적 실습 환경에서 벗어나 현장감 있는 자동화 경험을 제공한다. 이를 통해 학습자는 단편적 기술 습득을 넘어서, 실제 서비스 수준의 구성 흐름과 기본 보안 요소를 통합적으로 이해하는 역량을 기를 수 있으며, 향후 클라우드 네이티브 환경에서 요구되는 실무 기반의 적응력을 높일 수 있다.
3. 실습 환경 및 아키텍처 설계
3.1 전체 시스템 구성 개요
본 실습 환경은 Terraform과 Ansible을 활용하여, AI 웹 애플리케이션 기반의 DevOps 자동화를 구현한 구조이다. Flask 프레임워크와 Gemini API를 연동한 인공지능 사주 서비스 앱을 예시로 하며, 사용자 요청에 따라 실시간 응답을 생성한다. 모든 인프라는 AWS IaaS 환경에서 운영되며, Terraform을 통해 VPC, Subnet, EC2, RDS 등을 선언적으로 배포하고, Ansible로 Flask 앱과 관련 패키지 설치 및 실행을 자동화한다. 이를 통해 보안 정책과 구성 자동화가 동시에 적용된 상태로, 수작업 없이 일관되고 재현 가능한 실습 환경을 제공한다.
3.2 서비스 구조: Flask 기반 인공지능 API 연동 및 데이터 저장 구조
Flask 웹앱은 사용자 입력을 HTML 폼 또는 REST API로 수신하여 Gemini API에 전달하고, 생성된 응답을 반환한다. 결과는 HTML 또는 JSON 형태로 출력되며, 입력 및 응답은 RDS(MySQL)에 저장된다. RDS는 프라이빗 서브넷에 배치되어 퍼블릭 접근이 차단되고, EC2 인스턴스에서만 접근 가능하도록 보안 그룹이 설정된다. 템플릿은 Jinja2를 통해 동적으로 렌더링되며, 웹-API-DB의 3계층 구조는 서비스의 유지보수성과 보안성을 높인다.
3.3 AWS 인프라 구성 요소 (VPC, Subnet, EC2, ALB, RDS 등) 및 보안 고려사항
본 실습에서 사용된 AWS 기반 클라우드 인프라는 Terraform을 통해 선언적으로 구축되었으며, 구성 요소별 역할과 보안 설계는 다음 <표 1>과 같다. 이와 같은 구성은 웹 서버, 데이터베이스, 네트워크를 분리하여 3계층 아키텍처(3-Tier Architecture)를 형성하며, 보안 격리 및 접근 통제를 체계화함으로써 실습 환경에서도 실무와 유사한 클라우드 보안 모델을 구현하도록 설계되었다.
<표 1> AWS 인프라 구성요소 및 보안 등 고려사항

3.4 실습 구성 흐름도 및 자동화 연계 구조
본 실습 환경은 Terraform과 Ansible을 단계적으로 연계하여, 클라우드 인프라 구축과 애플리케이션 배포를 완전 자동화하는 구조로 설계되었다. 초기 단계에서는 Terraform을 활용하여 AWS 기반의 VPC, 퍼블릭/프라이빗 서브넷, EC2 인스턴스, ALB, RDS, 보안그룹 등의 인프라 자원을 선언적으로 생성한다. 이를 통해 네트워크 격리와 역할 분담이 명확한 3계층 구조의 클라우드 환경이 자동으로 구성된다[그림 1].

(그림 1) 실습 구성 및 자동화 흐름도
인프라 생성이 완료되면, 해당 EC2 인스턴스의 퍼블릭 IP와 ALB DNS 주소는 Terraform output으로 추출되며, 이 정보를 기반으로 Ansible 플레이북이 실행된다. Ansible은 EC2 인스턴스에 SSH로 접속한 후, Python 환경, Flask 프레임워크, Gemini API 연동 모듈, PyMySQL, 그리고 사용자 정의 웹 애플리케이션 코드(app.py) 및 템플릿 파일 등을 설치 및 배포한다. 또한 시스템 서비스 또는 백그라운드 실행을 통해 애플리케이션이 자동 기동되도록 구성한다.
최종적으로 사용자는 ALB 주소를 통해 웹 애플리케이션에 접속할 수 있으며, 입력된 데이터는 Gemini API와 연동되어 AI 응답을 생성하고, 그 결과는 RDS에 저장된다. EC2는 보안 그룹을 통해 ALB 및 RDS와만 통신이 가능하도록 설정되어 있으며, RDS는 외부 접근이 차단된 프라이빗 서브넷에 위치하여 데이터 보안성이 강화되었다.
이러한 자동화 연계 구조는 DevOps 기반의 실습 환경에서 재현성과 반복성을 보장할 뿐 아니라, 인프라와 애플리케이션 계층 모두를 아우르는 자동화 경험을 제공한다. 특히 보안적으로 격리된 아키텍처 구성과 자동화된 구성 관리는 실무 환경에서 요구되는 DevOps 및 클라우드 운영 역량을 효과적으로 학습할 수 있도록 지원한다.
4. 인프라 자동화 구현
본 장에서는 Terraform을 활용하여 AWS 기반 인프라 자원을 코드로 정의하고 자동으로 배포한 절차에 대해 기술한다. 주요 Terraform 및 Ansible 스크립트는 실습 과정에서 핵심 구조만을 요약하여 제시하였으며, 각 자원은 모듈화된 구조로 선언되어 반복적이고 재현 가능한 형태로 구성되었다.
특히 본 실습에서는 보안성을 고려하여 서브넷 분리, EC2-RDS 간 접근 제어(Security Group), SSH 키 기반 인증, 외부 접근 차단 설정 등을 포함하여 클라우드 보안의 기초 개념을 실습 환경에 반영하였다.
4.1 Terraform 설치 및 환경 구성
Terraform은 HashiCorp에서 개발한 오픈소스 IaC(Infrastructure as Code) 도구로, AWS, Azure, GCP 등 다양한 클라우드 환경에 적용 가능하다. 본 실습에서는 macOS 기반 로컬 환경에서 Terraform을 설치하였으며, terraform init, plan, apply 명령어를 통해 AWS 인프라가 자동으로 생성되도록 구성하였다. 또한 AWS 인증은 profile 옵션 또는 환경 변수 기반으로 설정되며, 보안 자격증명 유출을 방지하기 위해 하드코딩을 지양하였다.
4.2 AWS Provider 설정 및 변수 관리
Terraform의 provider "aws" 블록은 리전과 인증 정보를 설정하며, 본 실습에서는 ap-northeast-2 리전과 로컬 프로파일 기반 인증을 사용하였다. 민감한 정보는 terraform.tfvars 파일과 변수 정의를 통해 코드와 분리되어 관리되며, sensitive = true 속성을 통해 출력 노출을 방지하였다. 또한, 실습에서는 로컬 상태 파일을 사용하되, 실무 환경에서는 S3 백엔드와 암호화를 적용한 상태 관리가 필요하다. 이러한 구성은 실습 단계에서도 기본적인 클라우드 인증 보안과 민감 정보 보호 원칙을 반영하였다.
# AWS 프로바이더(Provider) 설정. 서울 리전(ap-northeast-2)을 사용.
provider "aws" {
region = "ap-northeast-2"
# 로컬에 저장된 'default' AWS 프로필을 사용하여 인증.
profile = "default"
}
# 데이터베이스 비밀번호를 위한 입력 변수 선언.
variable "db_password" {
type = string
# 'sensitive' 설정을 통해, Terraform 실행 계획 및 로그에 비밀번호 값이 노출되는 것을 방지.
sensitive = true
}
4.3 VPC 및 서브넷 구성 및 보안고려
본 실습에서는 aws_vpc 리소스를 통해 CIDR 범위가 10.0.0.0/16인 가상 네트워크를 생성하고, 퍼블릭 및 프라이빗 서브넷을 가용 영역 단위로 분리하여 이중화하였다. 보안 측면에서 EC2 및 ALB는 외부 접근이 가능한 퍼블릭 서브넷에, RDS는 외부 접근을 차단한 프라이빗 서브넷에 배치함으로써 기본적인 네트워크 분리(서브넷 격리)에 기반한 방어 전략을 적용하였다. 이를 통해 외부 노출 자원을 최소화하고, 중요 데이터 자산은 내부 네트워크에 안전하게 격리하는 클라우드 보안 원칙을 실습에 반영하였다.
아래 코드는 Terraform의 선언적 문법을 통해 네트워크 인프라를 자동으로 정의한 예이며, 실습의 재현성과 확장성을 높이는 데 기여한다. 주요 설정은 다음과 같다
# 가상 네트워크(VPC) 정의. 전체 IP 대역은 10.0.0.0/16.
resource "aws_vpc" "main_vpc" {
cidr_block = "10.0.0.0/16"
}
# 퍼블릭 서브넷. 외부 인터넷과 통신하며, 인스턴스에 공인 IP를 자동 할당.
resource "aws_subnet" "public_subnet" {
vpc_id = aws_vpc.main_vpc.id
cidr_block = "10.0.1.0/24"
map_public_ip_on_launch = true
}
# 프라이빗 서브넷. 외부 접근이 차단된 내부망으로, 공인 IP를 할당하지 않음.
resource "aws_subnet" "private_subnet" {
vpc_id = aws_vpc.main_vpc.id
cidr_block = "10.0.2.0/24"
}
4.4 EC2 인스턴스 및 키 페어 구성
본 실습에서는 Ubuntu 22.04 LTS 기반 Amazon EC2 인스턴스를 퍼블릭 서브넷에 배치하여 애플리케이션을 구동하였다. EC2 인스턴스에 대한 접속 권한은 aws_key_pair 리소스를 통해 생성한 SSH 공개키로 제한하였으며, 인스턴스 보안 그룹은 22번(SSH), 80번(HTTP) 포트만 허용하고 나머지 트래픽은 차단하는 최소 권한 원칙(Principle of Least Privilege)을 적용하였다.
보안을 강화하기 위한 설계는 다음과 같다. EC2 인스턴스는 퍼블릭 IP가 할당되지만, 접근은 등록된 키페어를 가진 사용자만 가능하며, 비인가 접근을 차단한다. 보안 그룹은 최소 권한 원칙에 따라 22번(SSH), 80번(HTTP) 포트만 허용하고, 나머지 인바운드는 차단되어 있다. Ansible을 통한 구성 과정에서도 루트 계정을 사용하지 않고, Python 가상환경 내에서 Flask 및 의존 패키지를 설치하여 애플리케이션을 격리된 환경에서 실행함으로써 시스템 수준 보안도 고려하였다.
이러한 접근은 단순한 자동화 수준을 넘어, 클라우드 인프라 보안에서 요구되는 기본적인 접근 통제와 네트워크 노출 최소화를 실습 과정에 내재화한 구조이다. 실습자는 이를 통해 실무에서 요구되는 보안 사고 대응 원칙과 클라우드 인프라의 보안 설계 전략을 체득할 수 있다.
# SSH 키 인증 설정
resource "aws_key_pair" "deployer" {
public_key = file("~/.ssh/id_rsa.pub")
}
# 최소 권한 보안 그룹 (22, 80 포트만 허용)
resource "aws_security_group" "web_sg" {
ingress { from_port = 22, to_port = 22, protocol = "tcp", cidr_blocks = ["0.0.0.0/0"] }
ingress { from_port = 80, to_port = 80, protocol = "tcp", cidr_blocks = ["0.0.0.0/0"] }
}
# EC2 인스턴스 배포 (보안 그룹 및 키 연동)
resource "aws_instance" "web" {
ami = "ami-xxxx"
instance_type = "t2.micro"
key_name =
aws_key_pair.deployer.key_name
vpc_security_group_ids =
[aws_security_group.web_sg.id]
}
4.5 ALB, Target Group, Listener 구성 및 보안 고려
외부 트래픽을 수신하고 내부 EC2 인스턴스로 전달하기 위한 Application Load Balancer(ALB)는 aws_lb, aws_lb_target_group, aws_lb_listener 리소스를 통해 구성하였다. ALB는 EC2를 대상으로 하는 타겟 그룹과 연결되며, 리스너는 HTTP 80번 포트를 수신하도록 설정하여 기본적인 웹 트래픽 라우팅을 처리한다.
보안 측면에서는 ALB에 적용된 보안 그룹을 통해 허용된 포트(HTTP 80) 외의 외부 접속을 차단하였으며, ALB 자체는 퍼블릭 서브넷에 위치하되, 대상 그룹(EC2)은 별도의 보안 그룹 규칙을 통해 ALB에서의 인바운드 트래픽만 수신하도록 제한하였다. 이를 통해 불필요한 외부 노출을 방지하고, ALB를 통해서만 인스턴스에 접근 가능한 보안 계층(Defense-in-Depth)을 실습에 반영하였다.
또한, 실무 환경에서는 HTTPS(443) 기반 암호화 통신을 적용하고, AWS WAF(Web Application Firewall)나 Shield Standard와 연계한 DDoS 대응 체계도 고려해야 한다. 본 실습은 학습 목적에 따라 HTTP 기반 설정을 유지하지만, 보안 모범 사례를 체득할 수 있도록 구성되었다. ALB의 DNS 이름은 output.tf 파일을 통해 출력되며, 웹 서비스 접속 주소로 활용된다.
# Application Load Balancer 생성 (퍼블릭 서브넷 + 보안 그룹 적용)
resource "aws_lb" "app_alb" {
name = "app-alb"
load_balancer_type = "application"
subnets = [aws_subnet.public1.id,
aws_subnet.public2.id]
security_groups = [aws_security_group.alb_sg.id] # HTTP(80)만 허용
}
# EC2 인스턴스를 대상으로 하는 타겟 그룹 정의
resource "aws_lb_target_group" "web_tg" {
name = "web-tg"
port = 80
protocol = "HTTP"
vpc_id = aws_vpc.main.id
}
# ALB 리스너 설정 (HTTP 80 수신 → Target Group으로 라우팅)
resource "aws_lb_listener" "http" {
load_balancer_arn = aws_lb.app_alb.arn
port = 80
protocol = "HTTP"
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.web_tg.arn
}
}
4.6 RDS(MySQL) 인스턴스 구성 및 보안고려
본 실습에서는 웹 애플리케이션의 데이터 저장소로 Amazon RDS(MySQL 8.0)를 구성하였다. 데이터베이스 인스턴스는 외부 노출을 차단하기 위해 프라이빗 서브넷에 배치되었으며, EC2 인스턴스에서만 접근 가능한 전용 보안 그룹을 통해 접근을 제어하였다. 이를 통해 DB 접근 경로를 최소화하고, 외부 공격 표면을 줄이는 보안 전략을 구현하였다.
RDS 인스턴스는 단일 가용 영역(AZ)에 배치되었으며, 실습 목적에 따라 고가용성(Multi-AZ)은 적용하지 않았다. 자동 백업, 암호화, 파라미터 그룹 등의 기본 보안 설정은 유지되었고, 특히 DB 사용자 비밀번호는 terraform.tfvars에 별도 정의하여 코드와 분리하고 sensitive = true 속성을 적용함으로써 민감 정보 노출을 방지하였다. 이처럼 실습 환경에서도 최소한의 클라우드 보안 원칙—서브넷 격리, 접근 제어, 민감 정보 보호—를 체득할 수 있도록 설계되었다.
# RDS 인스턴스 생성 (MySQL 8.0, 프라이빗 서브넷에 배치)
resource "aws_db_instance" "flask_db" {
engine = "mysql"
engine_version = "8.0"
instance_class = "db.t3.micro"
name = "flaskdb"
username = var.db_user
password = var.db_password
subnet_group_name =
aws_db_subnet_group.flask_db_group.name # 프라이빗 서브넷 그룹
vpc_security_group_ids = [aws_security_group.rds_sg.id]
# EC2 전용 보안 그룹
publicly_accessible = false
# 외부 접근 차단
skip_final_snapshot = true
}
4.7 Output 구성 전략
본 실습에서는 주요 리소스를 output.tf 파일을 통해 출력하여, 후속 자동화 도구인 Ansible에서 이를 동적으로 참조할 수 있도록 구성하였다. 출력 대상은 EC2 인스턴스의 퍼블릭 IP, Application Load Balancer의 DNS 이름, RDS의 엔드포인트 주소 등으로, 각 인프라 구성 요소의 접근 지점을 자동으로 추출하고 활용할 수 있도록 설계되었다.
보안 측면에서, 출력 정보 중 민감도가 높은 항목(예: RDS 엔드포인트, 내부 IP 등)에 대해서는 sensitive = true 속성을 적용하여 Terraform 실행 시 출력 결과에서 해당 값이 숨겨지도록 설정하였다. 또한, 실습자는 출력값을 .tfvars 파일이나 .env 형식으로 연계하여 재사용함으로써 수동 입력으로 인한 오탈자, 불필요한 노출을 줄이고, 클라우드 환경에서의 정보 보안 관리 능력을 실습을 통해 익힐 수 있다.
이러한 Output 구성 전략은 단순한 실습 편의성을 넘어서, 보안성을 갖춘 DevOps 자동화의 기초로 작용하며, 반복 가능한 실무형 인프라 배포 환경을 구성하는 데 기여한다.
# EC2 인스턴스의 퍼블릭 IP 출력
output "ec2_public_ip" {
value = aws_instance.web.public_ip
sensitive = false # 퍼블릭 IP는 민감 정보 아님
}
# ALB의 DNS 이름 출력
output "alb_dns_name" {
value = aws_lb.app_lb.dns_name
sensitive = false
}
# RDS 엔드포인트 출력 (민감 정보이므로 출력 시 숨김 처리)
output "rds_endpoint" {
value = aws_db_instance.mydb.endpoint
sensitive = true # 민감 정보 보호를 위해 true 설정
}
5. 애플리케이션 자동 배포 구현
본 장에서는 Ansible을 활용하여 EC2 인스턴스 상에 Flask 기반 인공지능 웹 애플리케이션을 자동으로 배포하고, MySQL(RDS) 연동 및 Gemini API 호출 기능을 포함하는 서비스를 구성한 절차를 기술한다. 이 과정을 통해 DevOps 실습 전 과정을 완성하며, 코드 중심의 반복 가능하고 검증 가능한 배포 프로세스를 구현하였다. 특히, 보안 측면에서 SSH 키 기반 인증, 최소 권한 보안 그룹 설정, 민감 정보 보호를 위한 환경 변수 및 권한 분리 등 기본적인 보안 원칙이 적용되었다.
5.1 Ansible 인벤토리 및 Role 기반 구성
Ansible은 EC2 인스턴스에 SSH로 접속하여 명령을 실행하며, 실습에서는 인벤토리 파일에 퍼블릭 IP를 수동으로 기입하여 구성하였다. 역할(Role) 기반 구성을 위해 roles/flask/tasks/main.yml 구조를 사용하였으며, Python 가상환경 구성, 패키지 설치, 애플리케이션 파일 배포, 서비스 실행을 각각의 태스크로 분리하였다.
보안적으로는 루트 계정을 사용하지 않고 일반 사용자 권한 내에서 Python 가상환경을 구성하고, 민감한 인증 정보는 플레이북 외부 환경변수 또는 Ansible Vault 등 안전한 방식으로 분리 관리되도록 설계되었다. 다음은 주요 작업 구성 예시이다.
# roles/flask/tasks/main.yml
- name: Python 가상환경 구성
shell: python3 -m venv <가상환경 디렉토리 경로>
- name: 필요한 패키지 설치 (Flask, PyMySQL 등)
pip:
requirements: <requirements.txt 경로>
virtualenv: <가상환경 디렉토리 경로>
- name: 애플리케이션 파일 배포
copy:
src: <app.py 및 템플릿 경로>
dest: <EC2 대상 경로>
- name: Flask 앱 실행 (백그라운드 or systemd 방식)
shell: |
source <가상환경>/bin/activate
nohup python <app.py 경로> > flask.log 2>&1 &
5.2 Flask 앱 자동 배포 및 RDS 연동
EC2 인스턴스는 최소한의 네트워크 접근 설정만으로 생성되며, 애플리케이션 구성은 Ansible 플레이북을 통해 자동화된다. 플레이북은 Python 가상환경 구성, 필수 패키지 설치, Flask 애플리케이션 복사, 실행 순서로 구성되며, MySQL(RDS) 연동을 위한 설정 파일을 환경변수 기반으로 관리한다.
보안적 요소로는 RDS 인스턴스를 퍼블릭 서브넷이 아닌 프라이빗 서브넷에 배치하고, EC2에서만 접근 가능한 보안 그룹으로 통제하며, DB 접속 정보는 app.py 또는 설정파일 내에 하드코딩하지 않고 Ansible이나 환경 변수로 주입되는 방식으로 구성된다.
# Flask 배포 요약
- name: Flask 및 PyMySQL 설치
pip:
name: [flask, pymysql]
virtualenv: /home/ubuntu/venv
- name: 애플리케이션 복사
copy:
src: ./app/
dest: /home/ubuntu/app/
- name: Flask 백그라운드 실행
shell: |
source /home/ubuntu/venv/bin/activate
nohup python /home/ubuntu/app/app.py > flask.log 2>&1 &
5.3 Gemini API를 활용한 AI 서비스 구현
본 애플리케이션은 사용자의 텍스트 입력을 수신하고 이를 Google의 Gemini Pro API로 전달하여 자연어 응답을 생성하는 AI 기반 웹 서비스로 설계되었다. 사용자가 웹 인터페이스에 질문을 입력하면, Flask 서버는 이를 처리하여 Gemini API에 전달하고, 생성된 응답을 HTML 템플릿에 렌더링하여 사용자에게 반환한다. 이러한 구조는 챗봇, 운세 분석, 사주 상담 등 다양한 사용자 맞춤형 상호작용형 서비스로 확장 가능하다.
보안 측면에서 가장 중요하게 고려된 요소는 API 키 및 민감 정보의 안전한 관리이다. Gemini API의 인증을 위해 사용되는 API 키는 코드에 직접 하드코딩되지 않고, Ansible을 통해 배포된 .env 환경 변수 파일 또는 운영체제 환경 변수로부터 동적으로 로드된다. 이를 통해 Git 등의 코드 저장소에 민감 정보가 노출되는 것을 방지하며, 배포 환경에 따라 키를 안전하게 분리·관리할 수 있도록 구성하였다. .env 파일은 .gitignore에 포함되어 버전 관리 대상에서 제외되고, 필요 시 Ansible Vault로 암호화할 수 있다.
서비스 내부 로직은 Flask 라우팅을 기반으로 구성된다. POST 요청이 /ask 등의 URL로 수신되면, 서버는 폼 데이터에서 사용자의 질문을 추출하고, 이를 기반으로 Gemini API에 질의한다. 응답은 자연어 형태로 구성되어 사용자에게 시각적으로 전달된다. 이때 입력값에 대한 서버 측 유효성 검사(Input Validation)가 적용되어, 악의적인 입력이나 명령어 삽입 시도를 방지하며, HTML 출력 시 이스케이프 처리를 통해 XSS(크로스사이트 스크립팅) 공격을 예방한다.
통신은 HTTPS를 기반으로 하며, 필요 시 WAF나 ALB 레벨에서 IP 제한, 비정상 요청 탐지 등 추가 보안 기능을 연계할 수 있다. 이처럼 최소한의 코드로 구현된 서비스는 DevOps 실습 및 AI 교육 목적에 매우 유용하며, 보안성을 유지한 상태에서 빠르게 기능을 확장할 수 있는 기반을 제공한다.
import os
import google.generativeai as genai
from flask import Flask, request, render_template, Markup
from dotenv import load_dotenv
# .env 파일 로드 및 Flask 앱 초기화
load_dotenv()
app = Flask(__name__)
# --- 보안: API 키를 환경 변수에서 안전하게 로드 ---
# 코드에 민감 정보를 하드코딩하지 않고, 배포 환경에 따라 키를 분리하여 관리합니다.
try:
genai.configure(api_key=os.environ["GEMINI_API_KEY"])
model = genai.GenerativeModel('gemini-pro')
except KeyError:
raise ValueError("보안 오류: GEMINI_API_KEY 환경 변수가 설정되지 않았습니다.")
@app.route('/', methods=['GET', 'POST'])
def handle_request():
"""GET 요청 시 페이지를 표시하고, POST 요청 시 AI 응답을 생성합니다."""
if request.method == 'POST':
# 보안: 서버 측 입력값 유효성 검사 (Input Validation)
# 악의적이거나 비어있는 입력을 처리 단계 이전에 차단
if not (question := request.form.get('question', '').strip()):
return render_template('index.html', error="질문을 입력해주세요.")
try:
response_text =
model.generate_content(question).text
# 보안: XSS방지를 위한 출력 이스케이프
# API 응답을 Markup 객체로 감싸 Jinja2가 안전하게 렌더링
# 단순 텍스트의 줄바꿈(\n)만 HTML 태그(<br>)로 변환하여 안전성을 유지합니다.
answer = Markup(response_text.replace('\n', '<br>'))
return render_template('index.html', question=question,
answer=answer)
except Exception as e:
return render_template('index.html', question=question,
error=f"API 오류: {e}")
# GET 요청 시 질문이나 답변 없이 페이지만 렌더링
return render_template('index.html')
if __name__ == '__main__':
app.run(debug=False)
5.4 배포 자동화 검증: 로그 확인, 웹 응답 테스트
배포 완료 후, 서비스의 정상 작동 여부는 다음과 같은 절차를 통해 검증하였다. 먼저, 웹 브라우저 및 명령줄 도구(curl)를 활용해 Application Load Balancer(ALB)의 DNS 주소로 접근함으로써 HTTP 응답 상태(200 OK 등)를 점검하였다. 이 과정은 ALB를 통한 보안 그룹 설정 및 HTTPS 적용 여부(예: 443 포트 리스너)도 함께 검토하였다.
다음으로, EC2 인스턴스 내부의 로그 파일(/home/ubuntu/flask.log)을 확인하여 Flask 애플리케이션의 구동 여부와 Python 예외, 인증 오류 등 보안 로그 항목 유무를 검토하였다. 로그에는 Gemini API 호출 실패나 DB 연결 오류가 포함될 수 있으므로, 이를 기반으로 네트워크 보안 그룹, IAM 권한, 환경 변수 주입 여부를 간접적으로 검증하였다.
데이터베이스 연동 확인은 RDS(MySQL) 인스턴스에 외부에서 직접 접속하지 않고, EC2 내부에서만 접근 가능한 보안 그룹 정책 하에 mysql -h <RDS 엔드포인트> -u admin -p 명령어를 통해 수행하였다. 이때, 초기 테이블 생성과 테스트 데이터가 정상적으로 입력되어 있는지 확인하였으며, DB 인증 정보는 app.py에 하드코딩되지 않고 환경 변수로 안전하게 전달되었는지 여부도 점검하였다.
마지막으로, 웹 인터페이스를 통해 Gemini API 호출 결과가 정확히 출력되는지를 시각적으로 검증하였다. 응답 내용은 사용자 입력 → 서버 처리 → AI API 호출 → 응답 렌더링의 전체 흐름이 보안 에러 없이 이루어졌는지를 기준으로 평가하였다.
이러한 종합적인 검증 과정을 통해, Terraform 기반 인프라 구성, Ansible 기반 애플리케이션 배포, 환경 변수 기반 보안 설정이 통합된 DevOps 자동화 환경이 안정적이고 신뢰성 있게 작동함을 입증할 수 있었다.
6. 실습 효과 분석 및 교육적 시사점
6.1 실습 구성의 교육 효과
본 실습은 Terraform과 Ansible을 활용한 DevOps 기반 클라우드 인프라 자동화와, Flask 및 Gemini API를 활용한 인공지능 애플리케이션 배포 과정을 통합적으로 다룸으로써, 학습자가 실무에서 요구되는 엔드투엔드 클라우드 운영 역량을 체득할 수 있도록 설계되었다.
특히, IaC 기반의 인프라 구성(Terraform)에서는 네트워크 분리(VPC 및 퍼블릭/프라이빗 서브넷), 접근 통제(SG, Key Pair), 민감 정보 보호(tfvars 분리 및 sensitive 지정)와 같은 클라우드 보안의 기본 원칙을 실습에 내재화하였으며, Ansible을 통한 애플리케이션 자동화 과정에서는 루트 권한 최소화, Python 가상환경 격리, 환경변수를 통한 보안 정보 주입 방식 등 보안 친화적인 운영 모델을 학습할 수 있도록 구성하였다.
또한, RDS와의 보안 연결 설정, API 키의 안전한 관리 및 호출, ALB를 통한 외부 트래픽 제어 등 전체 파이프라인 전반에서의 보안 고려 사항을 포함함으로써, 단순한 기능 구현 수준을 넘어 시스템 운영 및 클라우드 보안에 대한 통합적 사고력을 기를 수 있도록 설계되었다. 이는 교육적 측면에서 실제 기업 환경에서의 DevSecOps 기반 업무 수행 능력 배양에 효과적인 기반을 제공한다.
6.2 동료 전문가 대상 설문을 통한 실습 난이도 및 교육 효과 평가
본 실습 구성안은 정식 강의 적용에 앞서, DevOps 및 인공지능 교육 경험이 있는 동료 연구자 및 실무자 8인을 대상으로 사전 설문을 실시하였다. 설문 항목은 실습 흐름의 명확성, 자동화 구성의 적절성, 보안 요소의 반영 수준, 교육 효과에 대한 주관적 인식을 포함하도록 구성되었으며, 이는 정규 강의 전 커리큘럼의 타당성을 검토하고 개선하기 위한 파일럿 조사로 활용되었다. 특히, Terraform 및 Ansible 기반 자동화 과정에 내재된 클라우드 보안 설계(예: 최소 권한 원칙 적용, 민감 정보 분리 관리, 네트워크 분리 구성 등)에 대해 실무적 타당성 검토가 병행되었다.
설문은 Google Form을 활용해 총 8개의 문항으로 구성되었으며, 리커트 척도(1~5점)의 정량 평가와 개방형 의견 수렴을 병행하였다. 설문 결과는 <표 2>의 설문 결과에 따르면, 전체 평균 만족도는 4.6점(5점 만점)으로 높게 나타났다. 특히 Q3. 전체 실습 흐름의 논리성과 단계적 구성(4.8점) 및 Q6. 다른 수업이나 강의에서 활용하고 싶은 의향(4.8점)에 대해 가장 높은 점수를 받았다. 또한 Q2. Ansible을 통한 Flask 앱 배포 자동화 과정의 이해도(4.6점)와 Q5. DevOps 실무 역량 향상 기여도(4.6점)에 대해서도 높은 평가가 나타났으며, Q1과 Q4 역시 4.4점으로 대체로 긍정적인 결과를 보였다. 응답자 중 일부는 실습 도중 오류를 경험했으나, Ansible의 선언적 구성과 명확한 로그 출력으로 인해 문제 해결이 가능했다고 기술하였다. 가장 많이 제기된 개선 요청 사항은 실습 중 자주 발생하는 보안 설정 오류에 대한 사전 안내와 해결 가이드의 문서화였으며, 이는 실습 설계 시 보안성과 학습 편의성의 균형을 고려할 필요성을 보여준다.
<표 2> 설문 내용 및 결과

6.3 교육용 DevOps 실습의 한계점 및 확장
현 실습은 단일 인스턴스와 단일 사용자를 기준으로 설계되었기에 실제 DevOps 환경의 멀티 사용자 협업, CI/CD 파이프라인 자동화, Helm 기반 Kubernetes 배포 등의 고급 시나리오를 반영하지 못한 한계가 있다. 또한 비용 문제로 인해 로컬 또는 프리 티어 기반의 AWS 리소스를 활용하게 되면서, Auto Scaling, 고가용성 아키텍처 구성 등에 제약이 발생하였다. 향후에는 GitHub Actions 또는 GitLab CI와의 통합 실습, Docker 기반 컨테이너 배포, EKS 기반 클러스터 확장을 포함한 고도화 커리큘럼 개발이 요구된다.
6.4 보안을 내재한 클라우드-AI 앱 통합 교육의 실천적 가치
Terraform, Ansible, Flask, Gemini API를 유기적으로 연계한 본 실습은 단순한 인프라 자동화 교육을 넘어, 보안을 고려한 클라우드 인프라와 AI 서비스의 통합 운영이라는 관점에서 실질적인 DevOps 학습을 구현했다는 점에서 큰 의의가 있다.
특히 클라우드 환경 내 민감 정보 보호, 접근 통제(Security Group), 환경 변수 기반 인증 키 주입 방식, 로컬 상태파일 분리 관리 등 보안 실무의 기초 원칙을 실습 전반에 반영함으로써, 학습자는 인공지능 서비스의 배포뿐 아니라 보안 친화적인 시스템 구축 역량까지 함께 습득할 수 있다.
실시간 응답 기반의 AI 서비스 구조에 대한 실습은 학습자의 기술적 자신감과 창의적 응용 능력을 높이는데 기여하였으며, 클라우드 인프라 설계와 AI 모델 연동이라는 이질적인 두 기술의 융합은 단순한 기능 구현을 넘어서 실제 문제 해결 중심의 프로젝트 기반 학습(PBL)으로 확장 가능한 가능성을 제시하였다.
따라서 본 실습은 보안 요소를 내재한 DevOps 교육 모델로서, 향후 정책 기반 통제(Kyverno 등), 이미지 취약점 진단(Trivy), 런타임 이상 탐지(Falco) 등 DevSecOps 전반으로 확장 가능한 구조를 갖추고 있다. 이러한 통합형 실습은 클라우드 네이티브 시대에 요구되는 실무형 인재 양성에 기여할 수 있는 기초 교육 사례로 평가된다.
7. 결론 및 향후 연구
본 연구는 Terraform과 Ansible을 기반으로 클라우드 인프라 및 인공지능 애플리케이션을 자동화하는 교육 실습 구조를 제안하였다. 학습자는 퍼블릭/프라이빗 서브넷 분리, EC2–RDS 보안 그룹 구성, SSH 키 인증 등 기초적인 클라우드 보안 설계를 직접 경험하며, Gemini API를 활용한 Flask 앱과의 통합 실습을 통해 인프라부터 애플리케이션, AI 연동까지 전과정을 실습하게 된다. 이는 반복 가능하고 유지보수가 용이한 자동화 환경 속에서 실무형 DevOps 역량을 체득하도록 설계된 구조로, DevOps 교육과 보안 교육의 통합 가능성을 제시한다.
그러나 본 실습은 교육 목적에 따라 간소화된 구조로 구현되어, 고가용성, 무중단 배포, 모니터링 시스템, 대규모 사용자 처리와 같은 고도화된 실무 구성은 제외되었다. 또한 Ansible 인벤토리 구성이 정적이며, API 인증·요금 관리·Rate Limiting 등도 단순화되어 있다.
향후에는 Checkov, TFLint 등 정적 분석 도구를 통한 IaC 보안 검증, Falco와 Kyverno 기반의 실행 시점 정책 통제, CI/CD 파이프라인 연동을 통한 자동 검증, 그리고 EKS/GKE 전환 및 GitOps 기반 배포 전략을 추가함으로써 DevSecOps 프레임워크로 확장할 예정이다. 이를 통해 본 구조는 단순 교육 실습을 넘어, 클라우드 네이티브 보안 교육 플랫폼으로 진화할 수 있는 기반을 갖추고 있다.
References
- J. Smith, A. Patel and L. Zhao, "Optimizing DevOps Pipelines with Automation using Ansible", International Journal of Computer Applications, Vol. 184, No. 17, pp. 15-22, 2023.
- J. Smith and R. Kumar, "Automating Infrastructure Management: Benefits and Challenges", Journal of Cloud Engineering and DevOps, Vol. 9, No. 2, pp. 101-114, 2021.
- J. Wiedemann, M. Wiesche and H. Krcmar, "Teaching DevOps in academia and industry: reflections and vision paper", In 2018 IEEE/ ACM 40th International Conference on Software Engineering: Software Engineering Education and Training (ICSE-SEET) (pp. 127-136). IEEE, 2018. https://doi.org/10.1145/3183377.3183393
- S. Ferino, M. Fernandes, E. Cirilo, L. Agnez, B. Batista, U. Kulesza, E. Aranha and C. Treude, "Overcoming Challenges in DevOps Education through Teaching Methods," arXiv preprint arXiv:2302.05564, 2023.
- M. Linares-Vásquez, C. Bernal-Cárdenas, C. Vendome, G. Bavota, R. Bonifácio and D. Alégroth, "DevOps Education: An Interview Study," arXiv preprint arXiv:2203.10324, 2022.
- M. Aly, S. Shamim and T. Hegazy, "Optimizing DevOps Pipelines with Automation: Ansible and Beyond," arXiv preprint arXiv:2104.04480, 2021.