자동화와 인프라 코드 시작하기

2026-07-16Views 7약 8분생성형 AI 활용

Summary

왜 자동화가 필요한가

지금까지 우리는 콘솔에서 여러 리소스를 만들었다. VPC를 만들고, EC2를 실행하고, 보안 그룹을 열고, 로드 밸런서를 연결하고, 로그와 비용 알림도 설정했다. 처음 배울 때는 콘솔이 좋다. 화면을 보면서 구조를 익힐 수 있기 때문이다.

하지만 같은 작업을 두 번, 세 번 반복하면 문제가 생긴다. 첫 번째 환경에서는 보안 그룹의 SSH 접근을 내 IP로 제한했는데, 두 번째 환경에서는 실수로 0.0.0.0/0으로 열어 둘 수 있다. 개발 환경에는 Project 태그를 붙였지만 테스트 환경에는 빼먹을 수 있다. 실습을 끝낸 뒤 EC2는 지웠는데 EBS 볼륨이나 로그 그룹은 남길 수도 있다.

자동화는 이런 실수를 줄이는 방법이다. 사람이 매번 기억해서 클릭하는 대신, 정해진 명령과 코드가 같은 작업을 반복하게 만든다. 인프라 코드, 즉 Infrastructure as Code는 서버, 네트워크, 보안 규칙, 데이터베이스 같은 인프라 구성을 코드 파일로 정의하는 방식이다.

핵심은 단순하다.

클릭으로 만든 환경은 기억에 의존한다.
코드로 만든 환경은 파일에 남는다.
파일에 남은 환경은 검토하고, 반복하고, 삭제하고, 다시 만들 수 있다.

자동화는 큰 회사만의 기술이 아니다. 오히려 학습 단계에서 더 유용하다. 실습 환경을 만들고 지우는 일을 자동화하면 비용을 줄이고, 같은 구성을 다시 만들며, 실수했을 때 처음부터 다시 시작하기 쉬워진다.

자동화와 인프라 코드 시작하기 AI 생성 이미지

AWS CLI: 콘솔 작업을 명령어로 바꾸기

AWS CLI는 AWS Command Line Interface의 약자로, 터미널에서 명령어로 AWS를 조작하는 도구다. 콘솔에서 버튼을 누르는 작업을 명령어로 실행한다고 생각하면 된다.

예를 들어 S3 버킷 목록을 확인하는 작업은 콘솔에서 S3 화면에 들어가도 되지만, CLI에서는 다음처럼 실행할 수 있다.

aws s3 ls

EC2 인스턴스 목록을 확인하려면 다음처럼 명령할 수 있다.

aws ec2 describe-instances

처음에는 명령어가 낯설다. 하지만 CLI의 장점은 결과를 스크립트로 만들 수 있다는 데 있다. 매일 확인해야 하는 명령, 여러 리소스에 반복해야 하는 설정, 실습 후 정리해야 하는 작업을 파일 하나로 묶을 수 있다.

예를 들어 학습용 S3 버킷을 만들고 태그를 붙이는 작업을 매번 콘솔에서 한다고 생각해 보자. 손으로 하면 버킷 이름, 리전, 태그 값을 빼먹기 쉽다. CLI 명령을 스크립트로 만들면 같은 규칙을 반복할 수 있다.

aws s3api create-bucket \
  --bucket my-study-bucket-12345 \
  --region ap-northeast-2 \
  --create-bucket-configuration LocationConstraint=ap-northeast-2

aws s3api put-bucket-tagging \
  --bucket my-study-bucket-12345 \
  --tagging 'TagSet=[{Key=Project,Value=aws-study},{Key=Environment,Value=dev}]'

CLI를 사용할 때도 IAM 권한은 그대로 적용된다. 명령어를 실행하는 사용자가 S3 버킷 생성 권한이 없으면 실패한다. 자동화가 보안을 우회하는 것은 아니다. 오히려 자동화 계정이나 역할에는 필요한 권한만 주어야 한다. 실습용 스크립트에 장기 Access Key를 그대로 넣는 것도 피해야 한다. 가능하면 CloudShell, IAM 역할, 짧은 수명의 자격 증명을 사용하는 습관이 안전하다.

CLI는 자동화의 첫 단계다. 하지만 CLI 스크립트만으로는 복잡한 인프라의 전체 상태를 관리하기 어렵다. 그래서 다음 단계로 CloudFormation 같은 인프라 코드 도구가 필요해진다.

CloudFormation: 인프라를 템플릿으로 정의하기

CloudFormation은 AWS 리소스를 템플릿 파일로 정의하고, 그 파일을 바탕으로 리소스를 생성·수정·삭제하는 서비스다. 템플릿은 보통 YAML이나 JSON 형식으로 작성한다.

CloudFormation에서 중요한 개념은 스택이다. 스택은 템플릿으로 만든 리소스 묶음이다. 예를 들어 하나의 템플릿 안에 VPC, 서브넷, 보안 그룹, EC2 인스턴스를 정의하면 CloudFormation은 이를 하나의 스택으로 관리한다. 나중에 스택을 삭제하면 그 안에 포함된 리소스도 함께 정리할 수 있다.

간단한 템플릿은 다음과 같은 구조를 가진다.

AWSTemplateFormatVersion: '2010-09-09'
Description: Simple security group example

Parameters:
  VpcId:
    Type: AWS::EC2::VPC::Id

Resources:
  WebSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow HTTP from anywhere
      VpcId: !Ref VpcId
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
      Tags:
        - Key: Project
          Value: aws-study
        - Key: Environment
          Value: dev

Outputs:
  SecurityGroupId:
    Value: !Ref WebSecurityGroup

여기서 Parameters는 템플릿 실행 시 외부에서 받는 값이다. 위 예시에서는 어떤 VPC에 보안 그룹을 만들지 입력받는다. Resources는 실제로 만들 리소스다. Outputs는 생성된 리소스의 ID처럼 다른 곳에서 확인하거나 연결할 값을 출력한다.

CloudFormation의 장점은 구성이 파일에 남는다는 것이다. 누군가 보안 그룹을 어떻게 만들었는지 물어보면 콘솔 화면을 하나씩 열어 설명할 필요가 없다. 템플릿을 보면 된다. 코드 리뷰처럼 인프라 변경도 검토할 수 있다.

또 하나의 장점은 삭제다. 콘솔에서 만든 리소스는 서로 연결되어 있어 정리할 때 빠뜨리기 쉽다. CloudFormation 스택으로 만들면 스택 단위로 삭제할 수 있다. 학습 환경에서는 이 점이 특히 중요하다. 실습이 끝났다면 스택을 삭제해 비용이 계속 발생하지 않게 해야 한다.

다만 CloudFormation을 쓴다고 모든 문제가 자동으로 해결되지는 않는다. 템플릿에 잘못된 보안 규칙을 적으면 잘못된 구성이 그대로 만들어진다. 그래서 템플릿에도 최소 권한, 태그, 로그 보관 기간, 암호화, 삭제 정책 같은 운영 기준을 함께 넣어야 한다.

AWS CDK: 프로그래밍 언어로 인프라 표현하기

CloudFormation은 강력하지만 YAML이나 JSON이 길어질수록 읽기 어려워질 수 있다. 리소스가 많아지고 조건이 늘어나면 같은 설정을 반복해서 작성해야 하는 경우도 많다.

AWS CDK는 Cloud Development Kit의 약자로, 프로그래밍 언어로 AWS 인프라를 정의하게 해 주는 도구다. TypeScript, Python, Java 같은 익숙한 언어를 사용해 인프라를 표현할 수 있다. CDK 코드는 최종적으로 CloudFormation 템플릿으로 변환되어 배포된다.

비유하자면 CloudFormation 템플릿은 완성된 설계도이고, CDK 코드는 설계도를 만들어 내는 프로그램에 가깝다. 같은 패턴을 여러 번 반복하거나, 환경별로 조금씩 다른 구성을 만들 때 CDK가 편리하다.

예를 들어 개발 환경과 운영 환경이 있다고 하자. 둘 다 같은 구조를 쓰지만 운영 환경은 인스턴스 수가 더 많고, 로그 보관 기간이 더 길고, 삭제 방지 설정이 필요할 수 있다. CDK에서는 environment 값에 따라 설정을 나누는 코드를 작성할 수 있다.

CDK의 장점은 다음과 같다.

반복 구성을 함수나 클래스로 묶을 수 있다.
애플리케이션 코드와 비슷한 방식으로 테스트하고 리뷰할 수 있다.
팀이 사용하는 프로그래밍 언어로 인프라를 설명할 수 있다.
여러 리소스를 하나의 구조물처럼 묶어 재사용할 수 있다.

하지만 초보자라면 순서를 지키는 것이 좋다. 먼저 콘솔로 구조를 이해하고, CLI로 명령을 익히고, CloudFormation으로 인프라 코드의 기본을 배운 뒤 CDK로 넘어가면 훨씬 자연스럽다. CDK가 쉬운 문법을 제공하더라도, 내부에서 만들어지는 것은 결국 VPC, 보안 그룹, IAM 역할, Lambda, ECS 같은 AWS 리소스다. 기본 개념을 모르면 CDK 코드도 안전하게 작성하기 어렵다.

CodePipeline과 CodeBuild: 변경부터 배포까지 연결하기

인프라를 코드로 만들었다면 다음 질문은 자연스럽다.

"이 코드를 누가, 언제, 어떻게 배포할 것인가?"

처음에는 개발자가 로컬 컴퓨터에서 명령어를 실행해 배포할 수 있다. 하지만 팀 작업에서는 위험하다. 각자의 컴퓨터 환경이 다르고, 누가 어떤 버전으로 배포했는지 추적하기 어렵다. 배포 명령을 빠뜨리거나 순서를 잘못 실행할 수도 있다.

CodePipeline은 소스 변경부터 빌드, 테스트, 배포까지의 흐름을 단계로 연결하는 서비스다. 파이프라인은 공장 생산 라인처럼 생각하면 쉽다. 코드가 저장소에 들어오면 정해진 순서대로 다음 단계로 이동한다.

기본 흐름은 보통 다음과 같다.

Source 단계: Git 저장소나 S3 같은 위치에서 변경된 소스 코드를 가져온다.
Build 단계: CodeBuild가 코드를 빌드하고 테스트를 실행한다.
Deploy 단계: CloudFormation, ECS, Lambda, S3, CodeDeploy 같은 대상으로 배포한다.

CodeBuild는 빌드 작업을 실행하는 관리형 서비스다. 별도의 빌드 서버를 직접 운영하지 않아도 된다. 프로젝트에 buildspec.yml 파일을 두고, 어떤 명령을 실행할지 정의한다.

예를 들어 CDK 프로젝트라면 빌드 단계에서 의존성을 설치하고, 테스트를 실행하고, CDK 합성 명령으로 CloudFormation 템플릿을 만들 수 있다.

version: 0.2

phases:
  install:
    commands:
      - npm install
  build:
    commands:
      - npm test
      - npx cdk synth

실제 배포까지 자동화할 때는 IAM 권한을 특히 조심해야 한다. 파이프라인과 빌드 프로젝트에는 AWS 리소스를 만들 권한이 필요하다. 그렇다고 관리자 전체 권한을 쉽게 주면 안 된다. 어떤 스택을 배포하는지, 어떤 리전에 배포하는지, 어떤 리소스를 만들 수 있는지 범위를 줄여야 한다.

자동 배포는 속도를 높이지만, 잘못된 변경도 빠르게 반영할 수 있다. 그래서 운영 환경 배포 전에는 테스트, 승인 단계, 변경 내용 검토가 필요하다. 작은 학습 프로젝트라면 간단한 파이프라인으로 시작하되, 운영 서비스에서는 실패 시 되돌리는 방법까지 함께 설계해야 한다.

실습 환경은 만들기보다 지우기까지 자동화한다

자동화를 배울 때 많은 사람이 생성에만 집중한다. 하지만 AWS 학습에서 더 중요한 습관은 삭제 자동화다. 비용은 리소스를 만들 때가 아니라, 만든 뒤 방치할 때 커진다.

실습 환경을 코드로 만들면 다음 흐름을 만들 수 있다.

# 생성
./deploy-dev.sh

# 테스트
./test-dev.sh

# 삭제
./destroy-dev.sh

CloudFormation을 사용한다면 실습이 끝난 뒤 스택을 삭제하는 명령을 스크립트에 넣을 수 있다.

aws cloudformation delete-stack --stack-name aws-study-dev

CDK를 사용한다면 다음처럼 삭제할 수 있다.

cdk destroy

물론 삭제 전에 중요한 데이터가 있는지 확인해야 한다. S3 버킷, RDS 데이터베이스, EBS 스냅샷처럼 데이터가 담긴 리소스는 삭제 정책을 신중하게 정해야 한다. 학습 환경에서는 과감히 삭제해도 되지만, 운영 환경에서는 백업과 복구 절차가 먼저다.

좋은 자동화 습관은 다음과 같다.

모든 실습 리소스에 Project, Environment, Owner 태그를 붙인다.
개발 환경 이름에는 dev, 실습 환경 이름에는 study처럼 구분 값을 넣는다.
로그 그룹에는 보관 기간을 설정한다.
실습이 끝나면 스택 삭제나 정리 스크립트를 실행한다.
삭제 후 Cost Explorer나 리소스 목록에서 남은 항목을 확인한다.

이 습관은 비용뿐 아니라 보안에도 도움이 된다. 오래된 실습 서버, 열려 있는 보안 그룹, 사용하지 않는 IAM Access Key는 모두 위험 요소다. 자동화는 빠르게 만드는 기술이지만, 동시에 안전하게 없애는 기술이기도 하다.

처음 시작하는 순서

자동화 도구가 많아 보이지만 한 번에 모두 배울 필요는 없다. 다음 순서로 접근하면 부담이 적다.

첫째, 자주 확인하는 작업을 AWS CLI로 실행해 본다. S3 목록 보기, EC2 목록 보기, CloudFormation 스택 확인처럼 읽기 전용 명령부터 시작하면 안전하다.

둘째, 작은 리소스 하나를 CloudFormation으로 만들어 본다. 보안 그룹이나 S3 버킷처럼 단순한 리소스가 좋다. 만든 뒤에는 반드시 스택 삭제까지 해 본다.

셋째, 여러 리소스를 하나의 템플릿으로 묶는다. 예를 들어 VPC, 서브넷, 보안 그룹, EC2를 함께 정의하면 콘솔에서 배운 구조가 코드로 연결된다.

넷째, 반복이 많아지면 CDK를 검토한다. 같은 패턴을 여러 환경에 배포하거나, 팀이 프로그래밍 언어 기반 작업에 익숙하다면 CDK가 도움이 된다.

다섯째, 배포 명령을 사람이 직접 실행하지 않도록 CodePipeline과 CodeBuild로 연결한다. 처음에는 테스트와 템플릿 생성까지만 자동화해도 충분하다. 이후 안정되면 개발 환경 배포, 운영 승인, 운영 배포 순서로 확장하면 된다.

자동화의 목표는 멋진 도구를 많이 쓰는 것이 아니다. 같은 환경을 다시 만들 수 있고, 변경 이력을 남길 수 있고, 필요 없을 때 안전하게 삭제할 수 있는 상태를 만드는 것이다. 이 세 가지가 되면 AWS 학습은 훨씬 단단해진다.

지금까지 배운 EC2, S3, RDS, Lambda, ECS, CloudWatch, 비용 관리 지식은 자동화와 만나야 실제 운영 습관이 된다. 클릭으로 구조를 이해하고, 코드로 구조를 남긴다. 이것이 AWS를 오래 안전하게 사용하는 기본 방식이다.

책 목록

AWS 쉽게 배우기: 초보자를 위한 클라우드 실습 입문

전체 목차 보기