실습 프로젝트와 다음 학습 로드맵

이제는 연결해서 만들어 볼 차례

AWS를 배우다 보면 어느 순간 서비스 이름이 많이 쌓입니다. EC2, S3, RDS, Lambda, CloudFront, IAM, VPC처럼 각각은 이해했지만 "그래서 실제 서비스는 어떻게 만드는가?"라는 질문이 남습니다. 이 장의 목적은 그 질문에 답하는 것입니다.

AWS 실력은 개념을 많이 읽는 것만으로 빠르게 늘지 않습니다. 작은 시스템을 직접 만들고, 접속해 보고, 로그를 확인하고, 비용을 점검하고, 다시 삭제해 봐야 합니다. 이 과정에서 앞에서 배운 조각들이 하나의 그림으로 이어집니다.

여기서는 세 가지 입문 프로젝트를 제안합니다.

1. 정적 웹사이트 배포: S3와 CloudFront로 HTML, CSS, JavaScript 사이트를 배포합니다.

2. 3계층 웹 아키텍처: EC2, ALB, Auto Scaling, RDS를 연결합니다.

3. 서버리스 메모 API: Lambda, API Gateway, DynamoDB로 작은 API를 만듭니다.

처음부터 세 프로젝트를 모두 완벽하게 만들 필요는 없습니다. 중요한 것은 "만들기 → 확인하기 → 고치기 → 삭제하기"의 흐름을 익히는 것입니다. 만들 때보다 지울 때 더 꼼꼼해야 한다는 점도 꼭 기억하세요.

AI 생성 이미지

프로젝트 1: S3와 CloudFront로 정적 웹사이트 배포하기

가장 먼저 해 볼 프로젝트는 정적 웹사이트 배포입니다. 정적 웹사이트는 서버에서 매번 계산하지 않고, 이미 만들어진 HTML, CSS, JavaScript, 이미지 파일을 사용자에게 전달하는 사이트입니다. 회사 소개 페이지, 문서 사이트, 포트폴리오, 프런트엔드 빌드 결과물을 올릴 때 자주 사용합니다.

이 프로젝트의 목표는 단순합니다.

• S3에 웹 파일을 저장합니다.

• CloudFront를 앞에 두어 빠르게 전달합니다.

• ACM 인증서와 도메인을 연결해 HTTPS로 접속합니다.

• S3 버킷은 가능한 한 직접 공개하지 않습니다.

구성은 다음처럼 생각하면 됩니다.

사용자 → Route 53 도메인 → CloudFront → S3

S3는 파일 창고입니다. CloudFront는 전 세계 사용자 가까이에 파일을 캐시해 두는 배달망입니다. 사용자는 S3 주소를 직접 알 필요 없이 CloudFront 주소나 도메인으로 접속합니다.

실습 흐름은 다음과 같습니다.

1. index.html 파일을 하나 만듭니다.

2. S3 버킷을 만들고 파일을 업로드합니다.

3. CloudFront 배포를 만들고 S3를 원본으로 연결합니다.

4. 기본 루트 객체를 index.html로 설정합니다.

5. CloudFront 도메인으로 접속해 페이지가 보이는지 확인합니다.

6. 필요하면 Route 53에서 도메인을 CloudFront로 연결합니다.

7. ACM 인증서를 연결해 HTTPS 접속을 확인합니다.

여기서 보안상 중요한 선택이 있습니다. S3를 "웹사이트 엔드포인트"로 직접 공개하는 방법도 있지만, 학습 이후 실제 서비스에서는 S3 버킷을 비공개로 두고 CloudFront만 접근하도록 제한하는 구성을 더 자주 사용합니다. 특히 S3 REST API 엔드포인트와 CloudFront Origin Access Control(OAC)을 사용하면 S3의 퍼블릭 액세스를 막은 상태에서 CloudFront를 통해 파일을 제공할 수 있습니다.¹

처음에는 이 차이가 조금 헷갈릴 수 있습니다. 간단히 말하면, S3 웹사이트 엔드포인트 방식은 정적 웹사이트 호스팅 기능을 직접 쓰는 방식이고, OAC 방식은 CloudFront가 비공개 S3 버킷의 파일을 대신 가져가도록 허용하는 방식입니다. 이 장의 실습 목표가 "안전하게 외부에 공개하기"라면 OAC 방식을 우선 연습해 보는 편이 좋습니다.

도메인을 붙일 때는 한 가지를 더 확인하세요. CloudFront에 사용자 지정 도메인을 연결하려면 ACM 인증서를 함께 지정해야 합니다. CloudFront용 인증서는 미국 동부(버지니아 북부, us-east-1) 리전에서 발급한 인증서를 사용해야 하므로, 인증서를 만들 때 리전을 잘못 선택하지 않도록 주의해야 합니다.

확인할 것은 네 가지입니다.

• 브라우저에서 CloudFront 주소로 접속되는가?

• S3 객체를 직접 공개하지 않아도 페이지가 열리는가?

• 사용자 지정 도메인으로 접속했을 때 CloudFront로 연결되는가?

• HTTPS 인증서가 정상으로 표시되는가?

파일을 수정했는데 브라우저에서 예전 내용이 계속 보일 수도 있습니다. CloudFront가 파일을 캐시하고 있기 때문입니다. 이럴 때는 파일 이름을 바꾸거나, 캐시 만료 시간을 조정하거나, 필요한 경우 CloudFront 무효화(invalidation)를 실행해 새 파일을 다시 가져오게 할 수 있습니다.

비용도 함께 봐야 합니다. S3 저장 용량, CloudFront 전송량, Route 53 호스팅 영역과 도메인 비용이 발생할 수 있습니다. 작은 실습에서는 크지 않지만, 실습 후 필요 없는 배포와 버킷은 정리하는 습관을 들이세요.

프로젝트 2: EC2, ALB, Auto Scaling, RDS로 3계층 구조 만들기

두 번째 프로젝트는 전통적인 웹 서비스 구조입니다. 앞에서 배운 VPC, EC2, ALB, Auto Scaling, RDS가 모두 연결됩니다.

3계층 구조는 보통 다음처럼 나눕니다.

사용자
  ↓
퍼블릭 계층: ALB
  ↓
애플리케이션 계층: EC2 Auto Scaling Group
  ↓
데이터 계층: RDS

여기서 ALB는 사용자의 요청을 받는 입구입니다. EC2는 실제 애플리케이션이 실행되는 서버입니다. Auto Scaling Group은 EC2 수를 유지하고 필요할 때 늘리거나 줄입니다. RDS는 데이터를 저장하는 관리형 관계형 데이터베이스입니다.

실습 순서는 다음처럼 잡으면 좋습니다.

1. VPC 안에 퍼블릭 서브넷 2개와 프라이빗 서브넷 2개를 준비합니다.

2. ALB는 퍼블릭 서브넷에 둡니다.

3. EC2는 가능하면 프라이빗 서브넷에 둡니다.

4. RDS도 프라이빗 서브넷에 둡니다.

5. ALB 보안 그룹은 80 또는 443 포트를 인터넷에 엽니다.

6. EC2 보안 그룹은 ALB에서 오는 트래픽만 허용합니다.

7. RDS 보안 그룹은 EC2 보안 그룹에서 오는 DB 포트만 허용합니다.

8. Auto Scaling Group과 대상 그룹을 연결합니다.

9. /health 같은 헬스 체크 경로를 만들어 정상 여부를 확인합니다.

이 실습에서 가장 중요한 것은 "공개 범위"입니다. 모든 리소스를 인터넷에 열면 접속은 쉬워지지만 안전하지 않습니다. 사용자는 ALB까지만 접근할 수 있어야 합니다. 애플리케이션 서버와 데이터베이스는 내부에서만 접근되도록 구성하는 것이 기본입니다.

다만 EC2를 프라이빗 서브넷에 두면 초보자는 "그럼 서버에 어떻게 접속하지?"라는 문제를 만나게 됩니다. 운영 환경에서는 Systems Manager Session Manager, 배스천 호스트, VPN, 또는 필요한 VPC 엔드포인트 같은 방법을 사용합니다. 학습 초반에는 구조를 이해하는 것이 먼저이므로, 처음 한 번은 단순하게 시작하되 최종 목표는 "ALB만 인터넷에 공개하고 EC2와 RDS는 직접 공개하지 않는 구조"로 잡는 것이 좋습니다.

처음에는 아주 단순한 애플리케이션이면 충분합니다. 예를 들어 EC2에서 작은 웹 서버를 실행하고, /health 요청에는 OK를 반환하게 합니다. 그다음 RDS에 연결해 간단한 게시글 목록이나 방문 기록을 저장해 봅니다.

검증은 다음 순서로 합니다.

• ALB DNS 이름으로 접속했을 때 웹 페이지가 열리는가?

• 대상 그룹의 EC2가 healthy 상태인가?

• EC2 한 대를 종료해도 Auto Scaling Group이 새 인스턴스를 만드는가?

• 애플리케이션이 RDS에 연결되는가?

• RDS가 인터넷에 직접 공개되어 있지 않은가?

• 보안 그룹이 "모두 허용"에 가깝게 넓어져 있지는 않은가?

이 프로젝트는 비용이 더 발생하기 쉽습니다. ALB, EC2, RDS는 켜져 있는 시간만큼 비용이 쌓입니다. NAT Gateway를 사용했다면 시간당 비용과 데이터 처리 비용도 주의해야 합니다. 학습 목적이라면 짧은 시간 동안 만들고, 검증한 뒤 바로 삭제하세요.

프로젝트 3: Lambda, API Gateway, DynamoDB로 서버리스 메모 API 만들기

세 번째 프로젝트는 서버리스 방식입니다. EC2 서버를 만들지 않고도 API를 만들 수 있습니다.

구성은 다음과 같습니다.

사용자 또는 프런트엔드
  ↓
API Gateway
  ↓
Lambda
  ↓
DynamoDB

예제로는 "메모 API"가 좋습니다. 기능은 단순하게 잡습니다.

• POST /memos: 메모 생성

• GET /memos/{id}: 메모 조회

• GET /memos: 메모 목록 조회

• DELETE /memos/{id}: 메모 삭제

DynamoDB 테이블에는 memoId를 파티션 키로 둡니다. 각 메모에는 제목, 내용, 생성 시간 정도만 저장합니다. Lambda는 API Gateway에서 받은 요청을 해석하고 DynamoDB에 읽기·쓰기 작업을 수행합니다.

실습 순서는 다음과 같습니다.

1. DynamoDB 테이블을 만듭니다.

2. Lambda 함수를 만듭니다.

3. Lambda 실행 역할에 DynamoDB 접근 권한을 부여합니다.

4. API Gateway HTTP API를 만들고 Lambda와 연결합니다.

5. curl이나 Postman으로 API를 호출합니다.

6. CloudWatch Logs에서 Lambda 실행 로그를 확인합니다.

7. 오류가 발생하면 응답 코드와 로그를 함께 봅니다.

이 프로젝트에서 핵심은 IAM 역할입니다. Lambda 함수가 DynamoDB에 접근하려면 권한이 필요합니다. 하지만 모든 DynamoDB 작업을 허용할 필요는 없습니다. 실습 테이블에 대해 필요한 읽기·쓰기 작업만 허용하는 것이 좋습니다. 예를 들어 메모 생성과 조회, 삭제만 한다면 PutItem, GetItem, Scan 또는 Query, DeleteItem처럼 실제로 쓰는 작업 중심으로 좁혀 봅니다.

또 하나 중요한 것은 비용 구조입니다. 서버리스는 요청이 없으면 대체로 비용이 거의 발생하지 않습니다. 그래서 작은 API나 간헐적인 작업에 적합합니다. 하지만 요청이 폭증하거나 로그를 과도하게 남기면 비용이 늘 수 있습니다. DynamoDB 읽기·쓰기 용량, API Gateway 요청 수, Lambda 실행 시간, CloudWatch Logs 저장량이 모두 비용에 영향을 줄 수 있습니다. 서버리스라고 해서 비용 관리가 필요 없는 것은 아닙니다.

검증할 것은 다음과 같습니다.

• API Gateway 엔드포인트로 메모를 생성할 수 있는가?

• 생성된 데이터가 DynamoDB에 저장되는가?

• 없는 메모를 조회했을 때 적절한 오류를 반환하는가?

• Lambda 로그에서 요청과 오류를 추적할 수 있는가?

• Lambda 역할 권한이 지나치게 넓지 않은가?

서버리스 실습에서는 오류를 일부러 한 번 내 보는 것도 도움이 됩니다. 예를 들어 DynamoDB 테이블 이름을 잘못 지정하거나, Lambda 권한을 일부러 빼고 호출해 보면 어떤 오류가 CloudWatch Logs에 남는지 확인할 수 있습니다. 운영에서는 장애를 빨리 찾는 능력이 중요하므로, 성공한 호출만 보는 것보다 실패한 호출을 읽는 연습이 더 큰 도움이 됩니다.

실습 후 삭제 체크리스트

AWS 실습은 "만드는 것"만큼 "정리하는 것"이 중요합니다. 삭제하지 않은 리소스는 조용히 비용을 만듭니다. 실습을 끝낼 때마다 아래 목록을 확인하세요.

공통 확인

• 사용한 리전을 다시 확인합니다.

• Cost Explorer 또는 Billing 화면에서 비용 증가가 있는지 봅니다.

• 실습용 태그가 붙은 리소스를 검색합니다.

• CloudWatch Logs 로그 그룹이 불필요하게 남아 있지 않은지 확인합니다.

• 비용 화면에는 반영이 늦게 나타날 수 있으므로, 실습 직후와 다음 날 한 번 더 확인합니다.

S3와 CloudFront 실습 후

• CloudFront 배포를 비활성화하고 삭제합니다.

• S3 버킷 안의 객체를 비운 뒤 버킷을 삭제합니다.

• 버전 관리를 켰다면 현재 객체뿐 아니라 이전 버전과 삭제 마커도 정리합니다.

• Route 53 레코드와 호스팅 영역이 필요 없는지 확인합니다.

• ACM 인증서가 다른 곳에서 사용 중인지 확인한 뒤 정리합니다.

EC2, ALB, RDS 실습 후

• Auto Scaling Group을 삭제합니다.

• EC2 인스턴스가 남아 있지 않은지 확인합니다.

• ALB와 대상 그룹을 삭제합니다.

• RDS 인스턴스와 스냅샷 보관 여부를 확인합니다.

• EBS 볼륨, Elastic IP, NAT Gateway가 남아 있지 않은지 확인합니다.

• 보안 그룹과 키 페어도 필요 없으면 정리합니다.

서버리스 실습 후

• API Gateway API를 삭제합니다.

• Lambda 함수를 삭제합니다.

• DynamoDB 테이블을 삭제합니다.

• Lambda 실행 역할과 연결 정책이 남아 있는지 확인합니다.

• CloudWatch Logs 로그 그룹 보관 기간을 확인하거나 삭제합니다.

실습 전에는 예산 알림을 켜고, 실습 후에는 리소스를 정리합니다. 이 두 가지 습관만 있어도 초보 단계의 비용 사고를 크게 줄일 수 있습니다.

자격증으로 학습 범위 정리하기

AWS를 계속 공부한다면 자격증은 좋은 기준점이 될 수 있습니다. 자격증이 실무 능력을 자동으로 보장하지는 않지만, 빠뜨린 영역을 점검하는 데 도움이 됩니다.

처음에는 AWS Certified Cloud Practitioner 수준을 목표로 잡기 좋습니다. 이 단계에서는 깊은 설계보다 AWS의 큰 그림을 이해하는 것이 중요합니다.

학습 범위는 대략 다음과 같습니다.

• 클라우드 개념과 AWS의 장점

• 리전, 가용 영역, 글로벌 인프라

• IAM, 공동 책임 모델, 기본 보안 개념

• EC2, S3, RDS, DynamoDB, Lambda 같은 핵심 서비스의 역할

• 비용 관리, 과금 방식, 지원 플랜

• Well-Architected Framework의 기본 관점

이 책을 끝까지 따라왔다면 Cloud Practitioner의 많은 기초 개념은 이미 접한 상태입니다. 이제 필요한 것은 용어를 더 정확히 정리하고, 문제를 풀며 약한 부분을 확인하는 일입니다.

그다음 단계는 AWS Certified Solutions Architect - Associate입니다. 이 단계에서는 "어떤 서비스를 아는가"보다 "어떤 상황에서 어떤 구성을 선택하는가"가 중요해집니다.

추가로 깊게 공부할 주제는 다음과 같습니다.

• VPC 라우팅, NAT Gateway, VPC 엔드포인트

• 고가용성 설계와 Multi-AZ 구성

• ALB, Auto Scaling, Route 53 라우팅 정책

• S3 보안, 수명 주기, 복제, 암호화

• RDS 백업, 읽기 복제본, 장애 조치

• SQS, SNS, EventBridge를 이용한 비동기 설계

• CloudWatch, CloudTrail, Config를 이용한 운영과 감사

• 비용 최적화와 성능 효율성 비교

Solutions Architect 단계에서는 실습이 더 중요합니다. 같은 요구사항을 두고 EC2 기반, 컨테이너 기반, 서버리스 기반으로 각각 설계해 보세요. 그리고 비용, 보안, 운영 부담을 비교해 보세요. 그 비교 능력이 실제 설계 실력입니다.

앞으로의 공부 방법

이 책을 마친 뒤에는 다음 순서로 학습을 이어 가면 좋습니다.

1. 세 가지 실습 프로젝트 중 하나를 직접 완성합니다.

2. 같은 프로젝트를 콘솔이 아니라 CLI나 CloudFormation으로 다시 만들어 봅니다.

3. 로그, 알람, 비용 태그를 추가합니다.

4. 보안 그룹과 IAM 권한을 더 좁혀 봅니다.

5. 장애를 일부러 만들어 복구 과정을 확인합니다.

6. 마지막으로 모든 리소스를 삭제하고 비용이 멈췄는지 확인합니다.

좋은 AWS 학습은 거창한 시스템에서 시작하지 않습니다. 작은 웹 페이지 하나, 작은 API 하나, 작은 데이터베이스 하나를 제대로 만들고 지우는 것에서 시작합니다.

AWS는 서비스가 많아서 어렵게 느껴질 수 있습니다. 하지만 관점은 단순합니다. 사용자의 요청이 어디로 들어오고, 어느 서버나 함수가 처리하며, 데이터가 어디에 저장되고, 누가 접근할 수 있고, 비용은 어디서 발생하는지 계속 물어보면 됩니다.

이 질문에 답할 수 있다면 AWS를 단순히 외운 것이 아니라 이해하기 시작한 것입니다.

참고

¹How do I use CloudFront to serve a static website that's hosted on Amazon S3?