TIL - 20260608

juni·2026년 6월 8일

TIL

목록 보기

373/468

0608 AWS 운영 실무 기초 (1/N): 클라우드와 AWS 기본 구조

✅ 1. 클라우드란 무엇인가?

클라우드(Cloud)란 서버, 저장소, 데이터베이스, 네트워크, 보안, 배포 환경 등을 직접 장비로 구매하지 않고 인터넷을 통해 필요한 만큼 빌려 쓰는 방식입니다.
예전에는 회사가 직접 서버 장비를 구매하고 IDC에 설치해야 했지만, 지금은 AWS, Azure, Google Cloud 같은 클라우드 서비스를 통해 몇 분 안에 서버를 만들 수 있습니다.
웹 개발자에게 클라우드는 단순한 서버 임대 서비스가 아니라, 배포, 운영, 확장, 보안, 백업, 모니터링을 관리하는 핵심 인프라 환경입니다.

➕ 1-1. 클라우드가 필요한 이유

초기 비용 절감
- 서버 장비를 직접 구매하지 않아도 됩니다.
- 필요한 만큼만 사용하고 비용을 지불할 수 있습니다.
빠른 서버 생성
- 몇 분 안에 서버, DB, 저장소를 만들 수 있습니다.
- 신규 프로젝트나 테스트 환경을 빠르게 구성할 수 있습니다.
확장성
- 사용자가 늘어나면 서버 성능을 높이거나 서버 수를 늘릴 수 있습니다.
- 트래픽이 줄면 다시 줄여 비용을 아낄 수 있습니다.
운영 도구 제공
- 모니터링, 로그, 백업, 권한 관리, CDN, 보안 그룹 같은 기능을 함께 제공합니다.

✅ 2. AWS란 무엇인가?

AWS(Amazon Web Services)는 Amazon이 제공하는 클라우드 서비스 플랫폼입니다.
서버, DB, 파일 저장소, 네트워크, 보안, 배포, 모니터링, AI 서비스 등 수많은 기능을 제공합니다.
실무 웹서비스에서는 EC2, RDS, S3, CloudFront, Route 53, IAM, CloudWatch 같은 서비스를 자주 사용합니다.

➕ 2-1. 풀스택 개발자가 알아야 할 AWS 핵심 서비스

서비스	역할
EC2	가상 서버
RDS	관리형 데이터베이스
S3	파일/이미지/정적 파일 저장소
CloudFront	CDN, 정적 파일 빠른 배포
Route 53	도메인/DNS 관리
IAM	사용자, 권한, Access Key 관리
CloudWatch	로그, 모니터링, 알람
ACM	SSL 인증서 관리
VPC	네트워크 격리 환경
Security Group	서버 방화벽 역할

✅ 3. AWS 기본 구조 한눈에 보기

일반적인 웹서비스는 다음과 같은 구조로 운영될 수 있습니다.

사용자
  ↓
도메인 Route 53
  ↓
CloudFront CDN
  ↓
S3 정적 파일 또는 Nginx 프론트 서버
  ↓
EC2 백엔드 서버
  ↓
RDS 데이터베이스

React 프론트엔드, NestJS 백엔드, PostgreSQL DB를 운영한다고 하면 다음과 같이 구성할 수 있습니다.

React 빌드 파일
  → S3 또는 EC2/Nginx에 배포

NestJS API 서버
  → EC2에서 PM2 또는 Docker로 실행

PostgreSQL
  → RDS 또는 EC2 내부 Docker DB로 실행

이미지/첨부파일
  → S3에 저장

도메인
  → Route 53 또는 외부 도메인 DNS에서 연결

로그/모니터링
  → CloudWatch, PM2 logs, Nginx logs 확인

✅ 4. EC2

EC2(Elastic Compute Cloud)는 AWS에서 제공하는 가상 서버입니다.
쉽게 말하면 인터넷에 연결된 리눅스 서버를 빌려 쓰는 서비스입니다.
백엔드 서버, 관리자 페이지, 프론트엔드 정적 파일, 배포 스크립트, Nginx 등을 EC2에서 운영할 수 있습니다.

➕ 4-1. EC2에서 하는 일

Node.js/NestJS 서버 실행
Nginx 웹 서버 실행
React 빌드 파일 제공
PM2로 백엔드 프로세스 관리
Docker 컨테이너 실행
배포 스크립트 실행
로그 확인
SSL 인증서 적용

➕ 4-2. EC2 접속 예시

ssh -i my-key.pem ubuntu@서버IP

EC2는 보통 SSH 키를 이용해서 접속합니다.
SSH 키 파일은 절대 GitHub에 올리면 안 됩니다.
키 파일 권한이 너무 열려 있으면 접속이 거부될 수 있습니다.

chmod 400 my-key.pem

✅ 5. RDS

RDS(Relational Database Service)는 AWS에서 제공하는 관리형 관계형 데이터베이스 서비스입니다.
MySQL, PostgreSQL, MariaDB, Oracle 등을 사용할 수 있습니다.
직접 EC2에 DB를 설치하는 것보다 백업, 모니터링, 장애 대응, 스냅샷 관리가 편리합니다.

➕ 5-1. RDS를 사용하는 이유

자동 백업 설정 가능
스냅샷 생성 가능
DB 모니터링 가능
운영 DB를 서버와 분리 가능
장애 대응 옵션 제공
보안 그룹으로 접근 제어 가능

➕ 5-2. 실무 주의점

운영 DB는 외부에 공개하지 않는 것이 좋습니다.
EC2에서만 RDS에 접근하도록 보안 그룹을 제한해야 합니다.
DB 비밀번호는 .env 또는 Secret Manager로 관리해야 합니다.
운영 DB에 직접 쿼리를 실행할 때는 반드시 백업 여부를 확인해야 합니다.

DATABASE_URL=postgresql://USER:PASSWORD@RDS_ENDPOINT:5432/DB_NAME

✅ 6. S3

S3(Simple Storage Service)는 AWS의 객체 스토리지 서비스입니다.
이미지, 첨부파일, 백업 파일, 정적 파일 등을 저장할 수 있습니다.
쇼핑몰이나 이벤트 페이지에서는 상품 이미지, 배너 이미지, 업로드 파일 저장소로 많이 사용합니다.

➕ 6-1. S3에 저장하기 좋은 데이터

상품 이미지
이벤트 배너
사용자 업로드 파일
엑셀 다운로드 파일
DB 백업 파일
로그 아카이브
React 정적 빌드 파일

➕ 6-2. S3 사용 시 주의점

버킷을 무조건 public으로 열면 안 됩니다.
공개 파일과 비공개 파일을 구분해야 합니다.
Access Key를 프론트엔드에 넣으면 안 됩니다.
파일 URL보다 S3 key를 DB에 저장하는 것이 유연합니다.
오래된 파일은 Lifecycle 정책으로 정리할 수 있습니다.

banners/2026/galaxy-s25-main.webp
products/galaxy-s25/detail-01.webp
backups/db/backup_20260608.sql

✅ 7. CloudFront

CloudFront는 AWS의 CDN 서비스입니다.
S3나 서버에 있는 정적 파일을 사용자와 가까운 캐시 서버에서 빠르게 제공할 수 있습니다.
이미지가 많은 사이트에서는 CloudFront를 사용하면 로딩 속도와 서버 부하를 개선할 수 있습니다.

➕ 7-1. CloudFront를 사용하는 이유

이미지 로딩 속도 개선
S3 직접 접근 최소화
서버 트래픽 감소
글로벌 사용자 대응
HTTPS 적용 가능
캐싱으로 비용 절감 가능

사용자
  ↓
CloudFront
  ↓
S3 원본 파일

➕ 7-2. 캐시 주의점

CloudFront는 파일을 캐싱하기 때문에 원본 파일을 바꿔도 바로 반영되지 않을 수 있습니다.
같은 파일명으로 덮어쓰기보다 파일명에 해시나 UUID를 붙이는 것이 좋습니다.

좋은 예시:
banner.8f3a2c.webp

주의가 필요한 예시:
banner.webp

급하게 캐시를 비워야 할 때는 Invalidation을 사용할 수 있습니다.

✅ 8. Route 53과 DNS

Route 53은 AWS의 DNS 관리 서비스입니다.
도메인을 서버, CloudFront, Load Balancer 등에 연결할 때 사용합니다.

➕ 8-1. DNS란?

DNS는 사람이 읽기 쉬운 도메인을 서버 주소로 바꿔주는 시스템입니다.

www.example.com
  ↓ DNS 조회
123.123.123.123

➕ 8-2. 자주 사용하는 DNS 레코드

레코드	설명
A Record	도메인을 IPv4 주소에 연결
CNAME	도메인을 다른 도메인에 연결
TXT	소유권 인증, SPF, DKIM 등에 사용
MX	메일 서버 설정
NS	네임서버 설정

➕ 8-3. 실무 예시

www.example.com → CloudFront
api.example.com → EC2 또는 Load Balancer
admin.example.com → 관리자 페이지 서버

✅ 9. IAM

IAM(Identity and Access Management)은 AWS 사용자와 권한을 관리하는 서비스입니다.
AWS에서 가장 중요한 보안 서비스 중 하나입니다.
누가 어떤 AWS 리소스에 접근할 수 있는지 제어합니다.

➕ 9-1. IAM에서 관리하는 것

사용자
그룹
역할
정책
Access Key
권한 범위
MFA 설정

➕ 9-2. IAM 보안 원칙

루트 계정은 일상 작업에 사용하지 않는다.
IAM 사용자를 별도로 만든다.
MFA를 활성화한다.
필요한 권한만 부여한다.
Access Key를 Git에 올리지 않는다.
사용하지 않는 Key는 삭제한다.
퇴사자나 외부 작업자 권한은 즉시 회수한다.

➕ 9-3. Access Key 주의점

AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=

Access Key는 AWS 리소스에 접근할 수 있는 열쇠입니다.
절대 프론트엔드 코드, GitHub, Notion 공개 문서, Slack 공개 채널에 올리면 안 됩니다.
유출되면 과금 사고나 데이터 유출로 이어질 수 있습니다.

✅ 10. Security Group

Security Group은 EC2, RDS 같은 AWS 리소스의 방화벽 역할을 합니다.
어떤 IP와 포트에서 접근을 허용할지 설정합니다.

➕ 10-1. 자주 사용하는 포트

포트	용도
22	SSH 접속
80	HTTP
443	HTTPS
3000	Node.js 개발 서버
5432	PostgreSQL
3306	MySQL

➕ 10-2. 보안 그룹 설정 예시

EC2 인바운드
- 22: 내 IP만 허용
- 80: 0.0.0.0/0 허용
- 443: 0.0.0.0/0 허용

RDS 인바운드
- 5432: EC2 Security Group에서만 허용

SSH 22번 포트를 전체 공개하면 위험합니다.
DB 포트를 전체 공개하는 것은 더 위험합니다.
운영 DB는 가능하면 EC2나 특정 내부 네트워크에서만 접근하게 해야 합니다.

✅ 11. CloudWatch

CloudWatch는 AWS 리소스의 로그와 지표를 모니터링하는 서비스입니다.
EC2 CPU 사용률, RDS 연결 수, 로그 이벤트, 알람 등을 확인할 수 있습니다.

➕ 11-1. CloudWatch로 확인할 수 있는 것

EC2 CPU 사용률
네트워크 트래픽
RDS CPU/Connection/Storage
애플리케이션 로그
알람 조건
장애 징후

➕ 11-2. 실무 활용 예시

EC2 CPU 80% 이상 5분 지속
  ↓
CloudWatch Alarm 발생
  ↓
이메일 또는 Slack 알림

운영자는 사용자가 장애를 제보하기 전에 시스템 알림을 받을 수 있어야 합니다.
다만 작은 서비스에서는 CloudWatch만 믿지 말고 PM2 로그, Nginx 로그도 함께 봐야 합니다.

✅ 12. AWS 비용 구조

AWS는 대부분 사용한 만큼 비용이 발생합니다.
그래서 서비스를 만들 때 성능뿐 아니라 비용도 함께 고려해야 합니다.

➕ 12-1. 비용이 발생하는 주요 요소

EC2 인스턴스 실행 시간
RDS 인스턴스 실행 시간
S3 저장 용량
S3 요청 수
CloudFront 트래픽
데이터 전송량
스냅샷 저장 용량
NAT Gateway 사용량
로그 저장 용량

➕ 12-2. 비용 관리 주의점

사용하지 않는 EC2를 중지한다.
테스트용 RDS를 방치하지 않는다.
S3에 오래된 백업이 계속 쌓이지 않게 한다.
CloudWatch 로그 보관 기간을 설정한다.
비용 알림을 설정한다.
프리티어 사용량을 초과하지 않는지 확인한다.
NAT Gateway는 비용이 크게 나올 수 있으므로 구조를 이해하고 사용한다.

✅ 13. 1인 개발자가 AWS에서 특히 조심해야 할 것

1인 개발자는 서버, DB, 배포, 보안, 비용까지 혼자 봐야 하기 때문에 기본 안전장치가 중요합니다.

➕ 13-1. 반드시 해야 할 설정

루트 계정 MFA 활성화
IAM 사용자 별도 생성
Access Key Git 업로드 금지
EC2 SSH 접근 IP 제한
RDS 외부 공개 금지
S3 Public Access 설정 확인
비용 알림 설정
DB 자동 백업 확인
운영 서버 .env 권한 제한
배포 후 로그 확인 루틴 만들기

➕ 13-2. 하지 말아야 할 행동

AWS_SECRET_ACCESS_KEY를 프론트엔드에 넣기
RDS를 0.0.0.0/0으로 공개하기
S3 버킷 전체를 public으로 열기
루트 계정 Access Key 만들기
운영 DB 비밀번호를 Notion 공개 문서에 적기
비용 알림 없이 리소스 방치하기

✅ 14. AWS 기본 운영 흐름 예시

작은 규모의 React + NestJS + PostgreSQL 서비스라면 다음과 같은 구조로 시작할 수 있습니다.

Route 53
  ↓
CloudFront
  ↓
S3 React 정적 파일

api.example.com
  ↓
EC2 + Nginx
  ↓
NestJS + PM2
  ↓
RDS PostgreSQL

이미지 업로드
  ↓
S3
  ↓
CloudFront로 제공

로그/모니터링
  ↓
PM2 logs + Nginx logs + CloudWatch

더 단순한 초기 구조라면 EC2 한 대에서 프론트엔드 정적 파일과 백엔드를 같이 운영할 수도 있습니다.
다만 서비스가 커지면 프론트 정적 파일은 S3/CloudFront로 분리하고, DB는 RDS로 분리하는 것이 안정적입니다.

✅ 15. 실무 체크리스트

➕ 15-1. AWS 계정 체크리스트

루트 계정 MFA를 설정했는가?
IAM 사용자를 별도로 만들었는가?
IAM 권한을 최소 권한으로 설정했는가?
사용하지 않는 Access Key를 삭제했는가?
비용 알림을 설정했는가?

➕ 15-2. EC2 체크리스트

SSH 접속이 내 IP로 제한되어 있는가?
80, 443 포트만 외부 공개되어 있는가?
PM2 또는 systemd로 서버 프로세스를 관리하는가?
서버 재부팅 후 자동 실행 설정이 되어 있는가?
디스크 용량과 로그 용량을 확인하는가?

➕ 15-3. RDS 체크리스트

외부 공개가 비활성화되어 있는가?
EC2에서만 접근 가능하도록 보안 그룹이 설정되어 있는가?
자동 백업이 활성화되어 있는가?
스냅샷 생성 방법을 알고 있는가?
운영 DB 접속 정보가 안전하게 관리되는가?

➕ 15-4. S3 체크리스트

버킷 Public Access 설정을 확인했는가?
공개 파일과 비공개 파일 경로를 구분했는가?
업로드 파일명을 안전하게 생성하는가?
오래된 파일 정리 정책이 있는가?
CloudFront 연결 여부를 검토했는가?

✅ 16. AI를 활용해 AWS 구조를 설계할 때 질문법

AWS는 서비스가 많기 때문에 “서버 어떻게 만들어?”처럼 물으면 답변이 너무 넓어집니다.
현재 프로젝트 구조, 트래픽, 예산, 기술스택을 함께 알려줘야 현실적인 설계를 받을 수 있습니다.

➕ 16-1. 좋은 질문 예시

React + NestJS + PostgreSQL 기반의 온라인 휴대폰 판매 사이트를 AWS에 배포하려고 해.

조건:
1. 프론트엔드는 React/Vite
2. 백엔드는 NestJS
3. DB는 PostgreSQL
4. 이미지 업로드가 있음
5. 관리자 페이지가 있음
6. 초기 트래픽은 크지 않지만 광고 유입이 있을 수 있음
7. 비용은 최대한 낮게 시작하고 싶음
8. 나중에 확장 가능해야 함

EC2, RDS, S3, CloudFront, Route 53, CloudWatch를 어떻게 구성하면 좋을지
초기 구조와 확장 구조를 나눠서 설명해줘.
그리고 보안 그룹과 비용 주의점도 알려줘.

➕ 16-2. AI 답변 검증 기준

무조건 비싼 구조를 추천하지 않는가?
EC2, RDS, S3 역할을 구분하는가?
DB를 외부 전체 공개하지 말라고 하는가?
S3 Secret Key를 프론트엔드에 넣지 말라고 하는가?
비용 알림과 로그 보관 기간을 언급하는가?
초기 구조와 확장 구조를 나눠 설명하는가?
보안 그룹 설정을 구체적으로 설명하는가?

📌 요약

클라우드는 서버, DB, 저장소, 네트워크 등을 인터넷을 통해 필요한 만큼 빌려 쓰는 방식입니다.
AWS는 EC2, RDS, S3, CloudFront, Route 53, IAM, CloudWatch 등 웹서비스 운영에 필요한 다양한 클라우드 서비스를 제공합니다.
EC2는 가상 서버, RDS는 관리형 DB, S3는 파일 저장소, CloudFront는 CDN, Route 53은 DNS, IAM은 권한 관리, CloudWatch는 모니터링 역할을 합니다.
AWS 운영에서 가장 중요한 것은 보안과 비용 관리입니다.
EC2 SSH는 내 IP로 제한하고, RDS는 외부 공개를 피하고, S3는 전체 public 설정을 조심해야 합니다.
Access Key, DB 비밀번호, JWT Secret 같은 민감정보는 절대 GitHub나 프론트엔드 코드에 올리면 안 됩니다.
1인 개발자는 AWS 리소스 구조를 단순하게 시작하되, 백업, 로그, 비용 알림, 권한 관리는 처음부터 챙겨야 합니다.

juni

이전 포스트

TIL - 20260607

다음 포스트

TIL - 20260608

TIL

0608 AWS 운영 실무 기초 (1/N): 클라우드와 AWS 기본 구조

✅ 1. 클라우드란 무엇인가?

➕ 1-1. 클라우드가 필요한 이유

✅ 2. AWS란 무엇인가?

➕ 2-1. 풀스택 개발자가 알아야 할 AWS 핵심 서비스

✅ 3. AWS 기본 구조 한눈에 보기

✅ 4. EC2

➕ 4-1. EC2에서 하는 일

➕ 4-2. EC2 접속 예시

✅ 5. RDS

➕ 5-1. RDS를 사용하는 이유

➕ 5-2. 실무 주의점

✅ 6. S3

➕ 6-1. S3에 저장하기 좋은 데이터

➕ 6-2. S3 사용 시 주의점

✅ 7. CloudFront

➕ 7-1. CloudFront를 사용하는 이유

➕ 7-2. 캐시 주의점

✅ 8. Route 53과 DNS

➕ 8-1. DNS란?

➕ 8-2. 자주 사용하는 DNS 레코드

➕ 8-3. 실무 예시

✅ 9. IAM

➕ 9-1. IAM에서 관리하는 것

➕ 9-2. IAM 보안 원칙

➕ 9-3. Access Key 주의점

✅ 10. Security Group

➕ 10-1. 자주 사용하는 포트

➕ 10-2. 보안 그룹 설정 예시

✅ 11. CloudWatch

➕ 11-1. CloudWatch로 확인할 수 있는 것

➕ 11-2. 실무 활용 예시

✅ 12. AWS 비용 구조

➕ 12-1. 비용이 발생하는 주요 요소

➕ 12-2. 비용 관리 주의점

✅ 13. 1인 개발자가 AWS에서 특히 조심해야 할 것

➕ 13-1. 반드시 해야 할 설정

➕ 13-2. 하지 말아야 할 행동

✅ 14. AWS 기본 운영 흐름 예시

✅ 15. 실무 체크리스트

➕ 15-1. AWS 계정 체크리스트

➕ 15-2. EC2 체크리스트

➕ 15-3. RDS 체크리스트

➕ 15-4. S3 체크리스트

✅ 16. AI를 활용해 AWS 구조를 설계할 때 질문법

➕ 16-1. 좋은 질문 예시

➕ 16-2. AI 답변 검증 기준

📌 요약

TIL - 20260607

TIL - 20260609

0개의 댓글