Day 4 - 배포·자동화·기타: 인프라를 코드로, 그리고 서버 없이

지금까지 우리는 서비스들을 콘솔에서 클릭으로 만들었다. 그런데 같은 환경을 개발·테스트·운영용으로 세 벌 만들어야 하거나, 실수 없이 똑같이 재현해야 한다면 클릭은 위험하고 느리다. 오늘은 인프라를 코드로 다루는 방법(IaC)과, 배포를 단순화하는 도구, 그리고 서버 관리 부담을 줄이는 컨테이너·서버리스 개념을 정리한다.

핵심 질문은 하나다: "어디까지를 내가 직접 관리하고, 어디부터를 AWS에 맡길까?" 오늘 보는 도구들은 그 책임 경계를 점점 위로 올려준다.

손으로 클릭해 인프라를 만들던 시절

IaC라는 말이 왜 나왔는지는, 그것이 없던 시절을 보면 바로 이해된다.

어느 회사에 운영 환경이 하나 있다. EC2 세 대, 로드 밸런서 하나, 데이터베이스 하나, 보안 그룹 다섯 개, 그리고 그 사이를 잇는 수십 가지 설정. 이 환경은 지난 2년간 여러 사람이 콘솔에서 하나씩 클릭해 만들었다. 그러다 어느 날 요청이 온다. "테스트용으로 똑같은 환경을 하나 더 만들어 주면 된다."

그때부터 문제가 시작된다.

• 아무도 전체를 모른다. 만든 사람 중 둘은 이미 퇴사했다. 설정이 왜 그렇게 되어 있는지 설명할 수 있는 사람이 없다.
• 문서와 실제가 다르다. 위키에 적힌 구성도는 1년 전 버전이다. 그 뒤로 급하게 바꾼 것들이 반영되지 않았다.
• 똑같이 만들 수가 없다. 손으로 다시 클릭하면 어딘가는 반드시 다르게 된다. 그리고 그 미묘한 차이가 나중에 "테스트에선 됐는데 운영에선 안 되는" 사고로 돌아온다.
• 되돌릴 수 없다. 누가 설정을 잘못 바꿔도 "어제 상태"로 돌아갈 방법이 없다.
• 지우는 것도 일이다. 테스트가 끝나 정리하려면 무엇을 만들었는지 기억해 내며 하나씩 지워야 하고, 빠뜨린 리소스는 조용히 요금을 계속 만들어 낸다.

여기서 나온 발상이 단순하고 강력하다. 인프라를 "만드는 절차"가 아니라 "설계도 파일"로 다룬다. 코드처럼 파일에 적어 두면 어떻게 될까.

이것이 IaC(Infrastructure as Code, 코드형 인프라)다. 요리에 비유하면, 요리사의 감(勘)에 의존하던 방식에서 정확한 레시피를 적어 두는 방식으로 바꾼 것이다. 레시피가 있으면 누가 만들어도 같은 맛이 나고, 다른 주방에서도 재현되고, 무엇을 바꿨는지도 기록에 남는다.

AWS CloudFormation: 인프라를 코드로 (IaC)

AWS CloudFormation은 인프라를 코드(IaC, Infrastructure as Code)로 정의하는 서비스다. EC2, VPC, S3, RDS 같은 리소스를 JSON/YAML 템플릿에 적어두면, CloudFormation이 그대로 생성·수정·삭제해준다.

왜 좋을까. 콘솔 클릭은 사람마다 다르게 하고 기록도 안 남지만, 템플릿은 버전 관리되고 반복 재현 가능하다. "개발 환경을 운영과 똑같이" 만들고 싶으면 같은 템플릿을 한 번 더 배포하면 된다. 실수로 지운 환경도 템플릿만 있으면 그대로 되살아난다.

[수동 클릭]   환경마다 제각각, 기록 없음, 재현 어려움
[CloudFormation] 템플릿 1개 → 동일 환경 반복 생성/삭제, 버전 관리 가능

템플릿과 스택 — 두 단어만 알면 된다

CloudFormation에는 외울 용어가 사실상 둘뿐이다.

관계는 이렇게 흐른다.

템플릿 파일 1개
   │  (배포)
   ▼
스택 A (운영)      스택 B (테스트)      스택 C (개발)
 EC2·ELB·RDS…      EC2·ELB·RDS…        EC2·ELB·RDS…
   └─ 같은 설계도에서 나온, 서로 격리된 환경 3벌

여기서 스택이라는 단위가 주는 이점이 하나 더 있다. 스택을 삭제하면 그 스택이 만든 리소스가 함께 정리된다. 손으로 만든 환경은 지울 때 무엇을 빠뜨렸는지 알 수 없지만, 스택은 "이 묶음은 내가 만들었다"를 CloudFormation이 기억하고 있기 때문이다. 임시 실험 환경을 만들었다가 지우는 일이 부담 없어지는 이유다.

또 하나 중요한 성질은 선언적(declarative)이라는 점이다. 템플릿에는 "EC2를 만들어라, 그다음 보안 그룹을 붙여라" 같은 절차를 적는 게 아니라, "최종적으로 이런 상태였으면 좋겠다"를 적는다. 순서를 맞추고 의존 관계를 푸는 일은 CloudFormation이 알아서 한다. 그래서 같은 템플릿은 언제 돌려도 같은 결과를 낸다.

어느 게임 회사는 신작을 출시할 때마다 국가별로 환경을 새로 띄운다. 예전에는 엔지니어 두 명이 사흘씩 붙어 콘솔을 클릭했고, 매번 어딘가 설정이 하나씩 달랐다. 지금은 템플릿 하나에 "어느 리전, 어떤 크기"만 값으로 바꿔 넣고 배포한다. 환경 구축이 반나절로 줄었고, 서비스를 종료할 때는 스택을 지우는 것으로 정리가 끝난다.

⚠️ 함정: CloudFormation 템플릿이 있어도 누군가 콘솔에서 손으로 설정을 바꾸면 템플릿과 실제가 어긋난다. 이 어긋남을 드리프트(drift)라고 부른다. IaC를 도입했다는 것은 "이제 변경은 템플릿을 고쳐서 한다"는 팀의 약속까지 포함한다는 뜻이다. 도구만 들여놓는다고 재현성이 생기지는 않는다.

IaC는 Well-Architected의 Operational Excellence(운영 우수성) 핵심 실천이다. "인프라를 코드로", "반복 재현 가능한 환경", "템플릿으로 자동 프로비저닝"이 보이면 CloudFormation. 참고로 AWS CDK는 파이썬·타입스크립트 같은 익숙한 프로그래밍 언어로 인프라를 정의하면 CloudFormation 템플릿으로 바꿔 주는 도구다. 이름만 알아 두면 충분하다.

AWS Elastic Beanstalk: 코드만 올리면 배포 끝

AWS Elastic Beanstalk는 애플리케이션 코드를 업로드하면 실행에 필요한 인프라(EC2, 로드 밸런서, Auto Scaling 등)를 자동으로 구성·배포해주는 서비스다. 개발자는 인프라 세부 설정을 몰라도 코드에 집중할 수 있다.

CloudFormation과의 차이가 자주 헷갈리는데, 초점이 다르다. CloudFormation은 "원하는 모든 리소스를 내가 템플릿으로 정밀하게 정의", Elastic Beanstalk은 "웹 앱을 빠르게 배포하게 알아서 표준 환경을 구성"이다. Beanstalk도 내부적으로는 CloudFormation을 사용한다.

왜 이런 게 필요했나 — 개발자의 하루

웹 앱을 하나 만든 개발자가 그것을 인터넷에 올리려면 예전에는 이 목록을 전부 처리해야 했다.

EC2를 띄우고, OS를 고르고, 런타임(자바·파이썬 등)을 설치하고, 방화벽 규칙을 잡고, 로드 밸런서를 붙이고, Auto Scaling을 설정하고, 배포 스크립트를 짜고, 로그 수집을 붙이고, 무중단 배포 방법을 정한다. 정작 본인이 잘하는 일 — 앱 코드 짜기 — 는 이 목록 어디에도 없다.

Elastic Beanstalk은 이 목록을 통째로 가져간다. 개발자는 코드 묶음을 올리고 "이건 자바 앱입니다" 정도만 알려주면 된다. 그러면 실행 환경, 로드 밸런서, Auto Scaling, 상태 모니터링이 표준 구성으로 갖춰진다.

중요한 것은 Beanstalk이 마법을 부리는 게 아니라는 점이다. 뒤에서는 우리가 아는 그 EC2와 ELB가 만들어지고, 실제로 그것들을 만드는 일은 CloudFormation이 한다. 즉 Beanstalk은 "CloudFormation 위에 얹은 자동 조립 레시피"에 가깝다. 필요하면 만들어진 리소스를 직접 들여다보고 조정할 수도 있다.

개발자 세 명뿐인 스타트업이 첫 서비스를 출시했다. 인프라 담당자를 뽑을 여유가 없어 Beanstalk에 코드를 올려 시작했고, 초기 몇 달을 인프라 고민 없이 기능 개발에만 썼다. 사용자가 늘고 구성이 복잡해진 뒤에야 팀은 CloudFormation으로 인프라를 직접 정의하는 방향으로 옮겨 갔다. 처음에는 편의를, 나중에는 통제권을 선택한 셈이다. 시험에서 "빠르게, 인프라 지식 없이"가 강조되면 Beanstalk 쪽이다.

⚠️ 함정: Beanstalk과 CloudFormation은 경쟁 관계가 아니다. "둘 중 무엇이 더 좋은가"가 아니라 "세밀한 통제가 필요한가, 빠른 배포가 필요한가"로 갈린다. 그리고 Beanstalk은 웹 애플리케이션 배포에 초점이 있어서 "VPC와 네트워크까지 포함한 인프라 전체를 정의"하는 문항이면 답은 CloudFormation이다.

"코드만 올리면 알아서 배포", "인프라 세부 설정 없이 웹 앱 빠르게 출시"가 보이면 Elastic Beanstalk. "모든 리소스를 템플릿으로 직접 정의"면 CloudFormation이다.

컨테이너: ECS, EKS, Fargate

컨테이너는 애플리케이션과 실행 환경을 하나로 묶어 어디서나 똑같이 돌아가게 하는 기술이다. "내 컴퓨터에선 됐는데 서버에선 안 돼" 문제를 줄여준다. AWS의 대표 컨테이너 서비스는 다음과 같다.

• Amazon ECS(Elastic Container Service): AWS의 컨테이너 오케스트레이션 서비스. 컨테이너를 어디서 몇 개 띄울지 관리.
• Amazon EKS(Elastic Kubernetes Service): 표준 오픈소스 Kubernetes를 관리형으로 제공. 이미 쿠버네티스를 쓰는 팀에 적합.
• AWS Fargate: ECS/EKS에서 서버(EC2)를 직접 관리하지 않고 컨테이너만 실행하는 서버리스 컴퓨팅. 노드 패치·확장을 신경 쓸 필요 없음.

컨테이너를 이삿짐에 비유하면

컨테이너라는 말은 원래 항만에서 왔다. 규격 상자에 짐을 넣으면 배든 트럭이든 기차든 그대로 옮길 수 있다. 짐이 무엇인지 항구가 알 필요가 없다.

소프트웨어도 같다. 앱을 돌리려면 특정 버전의 언어 런타임, 라이브러리, 설정 파일이 필요한데 이것들이 서버마다 조금씩 다르면 앱이 다르게 동작한다. 컨테이너는 앱과 그 실행에 필요한 것들을 한 상자에 함께 넣는다. 그래서 개발자 노트북에서든 테스트 서버에서든 운영 서버에서든 상자 안은 똑같다.

여기서 헷갈리기 쉬운 지점을 정리한다. 컨테이너를 다룰 때는 두 가지 결정이 따로 필요하다.

1. 누가 컨테이너를 관리(오케스트레이션)할 것인가 — 몇 개를 어디에 띄우고, 죽으면 다시 살리고, 트래픽을 나눠 주는 일. → ECS 또는 EKS
2. 그 컨테이너가 돌아갈 서버는 누가 관리할 것인가 — 노드 OS 패치, 대수 조절. → EC2를 내가 또는 Fargate에 맡김

즉 ECS/EKS와 Fargate는 같은 층의 선택지가 아니라 서로 다른 두 질문에 대한 답이다. "ECS냐 Fargate냐"가 아니라 "ECS on EC2냐, ECS on Fargate냐"가 정확한 표현이다.

함정: ECS와 EKS를 "성능 차이"로 구분하려 들면 안 된다. 갈림길은 "AWS 고유 방식으로 단순하게 갈 것인가(ECS), 이미 익숙하거나 여러 클라우드에서 쓰는 표준 Kubernetes를 그대로 쓸 것인가(EKS)"다. 문항에 "이미 Kubernetes를 사용 중", "온프레미스에서 쿠버네티스로 운영하던" 같은 표현이 있으면 EKS다.

"AWS 방식 컨테이너 관리" → ECS, "표준 Kubernetes" → EKS, "서버 관리 없이 컨테이너만 실행" → Fargate. CLF에서는 깊은 운영보다 이 셋의 한 줄 차이를 묻는다.

서버리스: Lambda

서버리스(serverless)는 서버를 우리가 전혀 관리하지 않고, 코드 실행에만 비용을 내는 모델이다. 대표가 AWS Lambda다. 코드를 올려두면 이벤트(파일 업로드, API 호출 등)가 발생할 때만 실행되고, 실행한 시간만큼만 과금된다. 트래픽이 없으면 비용도 0에 가깝다.

[관리 책임이 줄어드는 순서]
EC2 (서버 직접 관리)
  → ECS/EKS on EC2 (컨테이너 + 노드 관리)
    → Fargate (컨테이너만, 노드 관리 없음)
      → Lambda (코드만, 서버 개념 없음)

호텔에 비유한 "얼마나 맡기나" 스펙트럼

위 사다리를 숙소에 비유하면 감이 확실해진다.

아래로 갈수록 자유도는 줄고 편의와 비용 효율은 올라간다. 어느 쪽이 "더 좋다"가 아니라, 상황이 무엇을 요구하느냐의 문제다. 시험 문항은 보통 이 요구를 힌트로 흘려 준다.

• "OS 수준의 세밀한 통제가 필요하다" → EC2 쪽
• "운영 부담을 최소화하고 싶다", "관리 인력이 없다" → Fargate·Lambda 쪽
• "동일 환경을 반복 생성해야 한다" → CloudFormation
• "개발자가 인프라를 몰라도 배포하게 하고 싶다" → Elastic Beanstalk

한 미디어 회사의 이미지 처리 파이프라인을 본다. 사용자가 사진을 S3에 올리면 그 즉시 Lambda가 실행돼 썸네일을 만든다. 하루 업로드가 100건인 날도, 이벤트 때문에 10만 건인 날도 코드는 그대로다. 서버 대수를 고민한 사람은 아무도 없고, 업로드가 없는 밤에는 비용도 사실상 발생하지 않는다. 반면 24시간 쉬지 않고 영상을 인코딩하는 작업은 Lambda보다 컨테이너나 EC2가 어울린다. 간헐적이고 짧은 작업은 서버리스, 길고 꾸준한 작업은 서버 기반이 대체로 맞는 감각이다.

신호 키워드별 서비스 선택

용어 정리표

오늘 헷갈리기 쉬운 짝을 모았다.

시험에 이렇게 나온다

정리

오늘은 배포와 자동화, 그리고 운영 책임을 줄이는 흐름을 봤다. CloudFormation으로 인프라를 코드화하고, Elastic Beanstalk으로 앱 배포를 단순화하며, 컨테이너(ECS/EKS/Fargate)와 서버리스(Lambda)로 점점 더 많은 운영을 AWS에 맡긴다. 관통하는 원리는 어제까지 본 공동 책임 모델이다 — 추상화가 올라갈수록 내 책임은 줄고, 나는 비즈니스 로직에 더 집중할 수 있다.

기억할 큰 그림은 두 가지다. 첫째, 인프라는 손이 아니라 파일로 다룬다. 그래야 재현되고, 리뷰되고, 되돌릴 수 있다. 둘째, "어디까지 맡길지"는 선택이지 정답이 아니다. 통제권이 필요하면 EC2 쪽으로, 속도와 편의가 필요하면 서버리스 쪽으로 간다. 시험은 이 선택의 이유를 묻는다.

스스로 확인해 본다. 템플릿과 스택의 차이는? Beanstalk이 내부적으로 무엇을 쓰는가? ECS와 EKS를 가르는 기준은? Fargate가 없애 주는 관리 부담은 정확히 무엇인가? Lambda가 어울리지 않는 작업의 예는? 여기에 한 줄씩 답할 수 있으면 오늘은 충분하다.

다음 글에서는 Week 3 전체 — 데이터베이스, 통합, 관리 도구, 배포 — 를 한 번에 복습하고 정리한다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

동일한 인프라 환경(개발·테스트·운영)을 반복 가능하고 버전 관리되는 방식으로 자동 생성하려 한다. 가장 적합한 서비스는?

• AAWS Elastic Beanstalk
• BAWS CloudFormation
• CAWS Lambda
• DAmazon ECS

문제 2

개발자가 인프라 세부 설정을 직접 다루지 않고, 코드만 업로드하면 EC2·로드밸런서·Auto Scaling을 알아서 구성해 웹 앱을 빠르게 배포하려 한다. 가장 적합한 서비스는?

• AAWS CloudFormation
• BAWS Config
• CAWS Elastic Beanstalk
• DAmazon EKS

문제 3

컨테이너를 실행하되 그 아래의 EC2 서버(노드)를 직접 패치·확장하지 않는 서버리스 방식을 원한다. 가장 적합한 것은?

• AAmazon EC2
• BAWS Fargate
• CAmazon RDS
• DAWS CloudTrail

문제 4

이벤트(예: 파일 업로드)가 발생할 때만 코드를 실행하고, 실행한 시간만큼만 과금되며 서버를 전혀 관리하지 않으려 한다. 가장 적합한 서비스는?

• AAWS Lambda
• BAmazon EC2
• CAmazon EKS
• DAWS Elastic Beanstalk

문제 5

이미 표준 오픈소스 Kubernetes를 사용 중인 팀이 AWS에서 관리형 Kubernetes를 쓰려 한다. 가장 적합한 서비스는?

• AAmazon ECS
• BAmazon EKS
• CAWS Lambda
• DAWS CloudFormation