TIL - 20260619

juni·2026년 6월 19일

TIL

목록 보기

382/468

0619 AWS 운영 실무 기초 (10/N): 전체 아키텍처 설계와 운영 체크리스트

✅ 1. AWS 아키텍처란 무엇인가?

AWS 아키텍처란 웹서비스를 운영하기 위해 AWS 리소스를 어떻게 배치하고 연결할지 설계한 구조입니다.
단순히 EC2 하나를 만들고 서버를 실행하는 것을 넘어서, 프론트엔드, 백엔드, DB, 파일 저장소, 도메인, SSL, 로그, 백업, 보안, 비용까지 함께 고려해야 합니다.
좋은 아키텍처는 처음부터 너무 복잡한 구조가 아니라, 현재 서비스 규모에 맞고 나중에 확장 가능한 구조입니다.

➕ 1-1. 아키텍처 설계가 중요한 이유

운영 안정성
- 서버 하나가 죽어도 어디가 문제인지 빠르게 파악할 수 있습니다.
- DB, 파일, 서버가 뒤섞여 있지 않으면 장애 대응이 쉬워집니다.
확장성
- 트래픽이 늘어났을 때 EC2, RDS, S3, CloudFront를 분리해서 확장할 수 있습니다.
보안
- DB를 외부에 공개하지 않고, S3 권한을 제한하고, IAM 권한을 최소화할 수 있습니다.
비용 관리
- 어떤 리소스에서 비용이 발생하는지 파악하고, 단계별로 최적화할 수 있습니다.

✅ 2. 작은 서비스의 초기 AWS 구조

처음부터 대기업 수준의 복잡한 구조를 만들 필요는 없습니다.
1인 개발자나 작은 회사에서는 관리 가능한 단순한 구조로 시작하는 것이 좋습니다.

➕ 2-1. 초기 구조 예시

사용자
  ↓
Route 53 또는 외부 DNS
  ↓
EC2 + Nginx
  ├─ React 정적 파일 제공
  └─ NestJS API Reverse Proxy
        ↓
      PostgreSQL Docker 또는 RDS

이 구조는 간단하고 비용이 낮습니다.
EC2 한 대에서 프론트엔드와 백엔드를 같이 운영할 수 있습니다.
DB도 초기에는 EC2 내부 Docker로 운영할 수 있지만, 실제 고객 데이터가 쌓이면 RDS 분리를 고려해야 합니다.

➕ 2-2. 장점

구조가 단순합니다.
비용이 낮습니다.
설정할 AWS 서비스가 적습니다.
배포와 로그 확인이 한 서버에서 가능합니다.

➕ 2-3. 단점

EC2 하나에 장애가 생기면 프론트엔드와 백엔드가 함께 영향을 받습니다.
서버 디스크에 파일을 저장하면 서버 교체가 어렵습니다.
DB를 EC2 내부에 두면 백업과 복구를 직접 관리해야 합니다.
트래픽이 늘면 병목을 분리하기 어렵습니다.

✅ 3. 운영에 적합한 기본 AWS 구조

실제 고객 데이터와 파일 업로드가 있는 서비스라면 프론트엔드, 백엔드, DB, 파일 저장소를 분리하는 것이 좋습니다.

➕ 3-1. 기본 운영 구조 예시

사용자
  ↓
Route 53
  ↓
CloudFront
  ↓
S3 React 정적 파일

사용자 API 요청
  ↓
Route 53
  ↓
EC2 + Nginx
  ↓
NestJS + PM2
  ↓
RDS PostgreSQL

이미지/첨부파일
  ↓
S3
  ↓
CloudFront

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

➕ 3-2. 서비스별 역할

서비스	역할
Route 53	도메인과 DNS 관리
CloudFront	CDN, 정적 파일과 이미지 빠른 제공
S3	React 빌드 파일, 이미지, 첨부파일, 백업 저장
EC2	백엔드 API 서버 실행
Nginx	Reverse Proxy, HTTPS, 정적 파일 라우팅
PM2	Node.js 백엔드 프로세스 관리
RDS	운영 데이터베이스
IAM	사용자와 서비스 권한 관리
CloudWatch	지표, 로그, 알람 관리
ACM/Certbot	SSL 인증서 관리

✅ 4. 도메인 구조 설계

운영 서비스에서는 도메인을 역할별로 나누면 관리가 쉬워집니다.

➕ 4-1. 추천 서브도메인 구조

www.example.com       → 고객용 프론트엔드
api.example.com       → 백엔드 API
admin.example.com     → 관리자 페이지
cdn.example.com       → 이미지/정적 파일 CDN
dev.example.com       → 개발 서버
staging.example.com   → 운영 전 검증 서버

➕ 4-2. 도메인별 연결 예시

도메인	연결 대상
`www.example.com`	CloudFront + S3
`api.example.com`	EC2 + Nginx + NestJS
`admin.example.com`	CloudFront + S3 또는 EC2/Nginx
`cdn.example.com`	CloudFront + S3
`staging.example.com`	별도 EC2 또는 S3/CloudFront

고객 페이지와 관리자 페이지를 분리하면 배포와 권한 관리가 쉬워집니다.
API 도메인은 CORS, HTTPS, 인증 쿠키 설정과 함께 관리해야 합니다.

✅ 5. 프론트엔드 배포 설계

React/Vite 프론트엔드는 빌드 후 정적 파일이 됩니다.
운영에서는 S3 + CloudFront 조합이 자주 사용됩니다.

➕ 5-1. 프론트엔드 배포 흐름

React/Vite 프로젝트
  ↓
npm run build
  ↓
dist 폴더 생성
  ↓
S3 업로드
  ↓
CloudFront 배포
  ↓
Route 53 도메인 연결

➕ 5-2. 프론트엔드 운영 체크 포인트

VITE_API_BASE_URL이 운영 API 주소인지 확인
index.html 캐시를 너무 길게 잡지 않기
JS/CSS 파일명에 해시가 포함되는지 확인
React Router 새로고침 404 문제 해결
CloudFront 캐시 무효화 전략 준비
모바일 화면과 주요 랜딩 페이지 확인
SEO 메타태그, sitemap, robots.txt 확인
GA, 광고 스크립트, 채널톡 등 운영 태그 확인

✅ 6. 백엔드 배포 설계

NestJS 백엔드는 EC2에서 PM2 또는 Docker로 운영할 수 있습니다.
초기에는 PM2 방식이 단순하고 이해하기 쉽습니다.

➕ 6-1. 백엔드 운영 흐름

GitHub main 브랜치
  ↓
EC2에서 git pull
  ↓
npm install
  ↓
npm run build
  ↓
npx prisma migrate deploy
  ↓
pm2 reload api
  ↓
health check

➕ 6-2. 백엔드 운영 체크 포인트

.env 운영 값이 정확한가?
DATABASE_URL이 RDS를 바라보는가?
CORS Origin이 운영 프론트 도메인인가?
JWT Secret이 운영용으로 설정되어 있는가?
PM2 프로세스가 online 상태인가?
Nginx proxy_pass 포트가 백엔드 포트와 일치하는가?
/health 같은 상태 확인 API가 있는가?
배포 후 PM2 logs와 Nginx error.log를 확인하는가?

✅ 7. 데이터베이스 설계

운영 DB는 서비스의 핵심입니다.
상담 신청, 주문, 회원 정보, 관리자 계정, 상품 정보가 모두 DB에 저장됩니다.
비용을 줄이겠다고 DB 백업이나 보안을 무시하면 안 됩니다.

➕ 7-1. RDS 운영 구조

EC2 백엔드 서버
  ↓
RDS PostgreSQL

RDS 보안 그룹:
EC2 Security Group에서만 5432 접근 허용

➕ 7-2. DB 운영 체크 포인트

Public Access가 꺼져 있는가?
RDS 보안 그룹이 EC2만 허용하는가?
자동 백업이 활성화되어 있는가?
중요한 배포 전 수동 스냅샷을 생성하는가?
Prisma 운영 마이그레이션은 migrate deploy를 사용하는가?
migrate reset을 운영에서 사용하지 않는가?
인덱스, 페이지네이션, 느린 쿼리를 확인하는가?
운영 DB에 직접 쿼리 실행 전 SELECT로 대상 확인을 하는가?

✅ 8. 파일 저장소 설계

업로드 파일은 EC2 디스크보다 S3에 저장하는 것이 운영에 유리합니다.
EC2에 파일을 저장하면 서버 교체나 확장 시 문제가 생길 수 있습니다.

➕ 8-1. S3 파일 구조 예시

public/
  banners/
  products/
  events/

private/
  consults/
  documents/
  backups/

tmp/
  uploads/

➕ 8-2. 파일 운영 체크 포인트

공개 파일과 비공개 파일 경로가 분리되어 있는가?
버킷 전체 public 설정을 피했는가?
CloudFront를 통해 공개 파일을 제공하는가?
비공개 파일은 Presigned URL을 사용하는가?
S3 key에 UUID나 해시를 사용하는가?
원본 파일명을 그대로 저장 경로에 쓰지 않는가?
이미지 WebP/AVIF 최적화를 고려했는가?
Lifecycle 정책으로 임시 파일과 오래된 백업을 정리하는가?

✅ 9. 보안 설계

AWS 운영에서 보안은 나중에 붙이는 것이 아니라 처음부터 기본값으로 깔고 가야 합니다.
특히 IAM, 보안 그룹, S3 권한, Secret 관리가 중요합니다.

➕ 9-1. 보안 기본 구조

사용자
  ↓ HTTPS
CloudFront / Nginx
  ↓
백엔드 API
  ↓
RDS는 외부 공개 안 함

S3:
Public Access Block 유지
CloudFront 또는 Presigned URL로만 제공

IAM:
최소 권한 원칙

➕ 9-2. 보안 체크 포인트

루트 계정 MFA가 설정되어 있는가?
루트 계정 Access Key가 없는가?
IAM 사용자를 사람별로 분리했는가?
EC2 SSH 22번 포트는 내 IP만 허용하는가?
RDS 5432/3306 포트가 외부 공개되어 있지 않은가?
S3 버킷 전체 public을 피했는가?
Access Key가 프론트엔드나 GitHub에 노출되지 않았는가?
운영 .env 파일 권한이 제한되어 있는가?
관리자 페이지 접근 권한과 백엔드 권한 검사가 있는가?
로그에 JWT, 비밀번호, 인증번호가 남지 않는가?

✅ 10. 모니터링 설계

운영 서비스는 문제가 생긴 뒤 보는 것이 아니라, 문제가 생기기 전에 감지할 수 있어야 합니다.
최소한 EC2, RDS, CloudFront, 비용 알림은 설정하는 것이 좋습니다.

➕ 10-1. 최소 모니터링 구성

EC2 CPU 알람
EC2 Status Check 알람
RDS CPU 알람
RDS Storage 알람
CloudFront 5xx 알람
AWS Budgets 비용 알림
PM2 logs 확인
Nginx error.log 확인

➕ 10-2. 모니터링 체크 포인트

EC2 CPU와 상태 체크 알람이 있는가?
RDS CPU, Connection, Storage를 확인하는가?
CloudFront 4xx/5xx 에러율을 확인하는가?
CloudWatch Logs 보관 기간이 설정되어 있는가?
PM2 로그와 Nginx 로그를 확인할 수 있는가?
API 500 에러가 증가하면 알 수 있는가?
AWS 비용이 예상보다 증가하면 알림을 받는가?
장애 발생 시 확인 순서가 문서화되어 있는가?

✅ 11. 백업과 복구 설계

백업은 운영의 마지막 방어선입니다.
백업은 있어도 복구 방법을 모르면 의미가 없습니다.

➕ 11-1. 최소 백업 구조

RDS 자동 백업 7일
중요 배포 전 RDS 수동 스냅샷
DB dump 파일 S3 저장
S3 Versioning 검토
서버 설정 백업
.env.example 관리
배포 기록과 장애 기록 작성

➕ 11-2. 백업/복구 체크 포인트

RDS 자동 백업이 켜져 있는가?
백업 보존 기간이 정해져 있는가?
중요한 DB 변경 전 수동 스냅샷을 생성하는가?
S3 백업 파일이 public으로 노출되지 않는가?
서버 설정과 배포 스크립트를 복구할 수 있는가?
.env.example로 필요한 환경변수 목록을 알 수 있는가?
RTO와 RPO를 대략이라도 정해두었는가?
장애 기록 템플릿이 있는가?

✅ 12. 비용 설계

AWS는 사용한 만큼 비용이 발생합니다.
설계 단계부터 비용이 새기 쉬운 리소스를 알고 있어야 합니다.

➕ 12-1. 비용이 자주 새는 항목

테스트 EC2 방치
테스트 RDS 방치
오래된 EBS 볼륨
오래된 스냅샷
미사용 Elastic IP
CloudWatch Logs 무제한 보관
S3 백업 파일 누적
NAT Gateway 방치
대용량 이미지 트래픽

➕ 12-2. 비용 관리 체크 포인트

AWS Budgets가 설정되어 있는가?
Cost Explorer를 매월 확인하는가?
사용하지 않는 EC2/RDS가 없는가?
오래된 EBS, 스냅샷, Elastic IP를 정리하는가?
CloudWatch 로그 보관 기간을 설정했는가?
S3 Lifecycle 정책이 있는가?
이미지 최적화로 CloudFront 트래픽을 줄이는가?
리소스에 Project, Environment, Owner 태그를 붙였는가?

✅ 13. CI/CD와 배포 자동화 설계

배포는 수동으로 시작해도 되지만, 반복되면 자동화해야 합니다.
다만 자동화는 안전장치 없이 만들면 잘못된 코드가 빠르게 운영에 반영되는 위험도 있습니다.

➕ 13-1. GitHub Actions 배포 흐름 예시

main 브랜치 push
  ↓
GitHub Actions 실행
  ↓
빌드 테스트
  ↓
EC2 SSH 접속
  ↓
git pull
  ↓
npm install
  ↓
npm run build
  ↓
prisma migrate deploy
  ↓
pm2 reload
  ↓
health check

➕ 13-2. 배포 자동화 체크 포인트

main 브랜치에 바로 push하지 않고 PR을 사용하는가?
배포 전 빌드가 성공하는가?
환경변수 누락을 사전에 확인하는가?
DB 마이그레이션이 포함되면 수동 확인 절차가 있는가?
배포 후 health check를 하는가?
실패 시 알림을 받을 수 있는가?
롤백 방법이 정리되어 있는가?
배포 기록을 남기는가?

✅ 14. 개발/운영 환경 분리

개발 환경과 운영 환경이 섞이면 사고가 발생하기 쉽습니다.
운영 DB를 로컬에서 실수로 수정하거나, 개발용 API Key가 운영에 들어가는 일이 생길 수 있습니다.

➕ 14-1. 분리해야 할 것

항목	개발	운영
도메인	`dev.example.com`	`www.example.com`
API	`dev-api.example.com`	`api.example.com`
DB	개발 DB	운영 RDS
S3	dev bucket	prod bucket
Access Key	dev 권한	prod 최소 권한
로그	짧은 보관	운영 기준 보관
결제/문자 API	테스트 키	운영 키

➕ 14-2. 환경 분리 체크 포인트

개발 DB와 운영 DB가 분리되어 있는가?
개발 S3와 운영 S3가 분리되어 있는가?
운영 Access Key를 로컬에서 무분별하게 쓰지 않는가?
개발 환경에서 실제 문자/결제가 나가지 않도록 막았는가?
운영 환경변수와 개발 환경변수를 명확히 구분하는가?
배포 대상 브랜치가 명확한가?

✅ 15. 1인 개발자 기준 현실적인 최종 구조

1인 개발자는 너무 복잡한 구조보다 관리 가능한 구조가 중요합니다.
아래 정도면 작은 회사의 실제 서비스 운영에 꽤 현실적인 기본 구조입니다.

➕ 15-1. 추천 구조

Route 53
  ├─ www.example.com → CloudFront → S3 React 고객 페이지
  ├─ admin.example.com → CloudFront → S3 React 관리자 페이지
  ├─ api.example.com → EC2 + Nginx → NestJS + PM2
  └─ cdn.example.com → CloudFront → S3 이미지

EC2
  ├─ Nginx
  ├─ NestJS API
  ├─ PM2
  └─ 배포 스크립트

RDS
  └─ PostgreSQL

S3
  ├─ public assets
  ├─ private uploads
  └─ backups

CloudWatch
  ├─ EC2/RDS/CloudFront 알람
  └─ 로그 보관

IAM
  ├─ 관리자 사용자 MFA
  ├─ EC2 Role
  └─ GitHub Actions 배포 권한

➕ 15-2. 이 구조의 장점

프론트엔드는 S3/CloudFront로 빠르게 제공됩니다.
백엔드는 EC2에서 직접 제어할 수 있습니다.
DB는 RDS로 분리되어 백업과 복구가 유리합니다.
이미지는 S3/CloudFront로 제공되어 EC2 부하를 줄일 수 있습니다.
도메인과 SSL을 역할별로 나눌 수 있습니다.
1인 개발자가 관리하기에 지나치게 복잡하지 않습니다.

✅ 16. 운영 문서화

운영 구조는 머릿속에만 있으면 안 됩니다.
장애가 발생하거나 인수인계가 필요할 때 문서가 있어야 합니다.

➕ 16-1. 반드시 작성하면 좋은 문서

AWS 아키텍처 문서
서버 접속 방법
배포 절차
환경변수 목록
DNS/도메인 설정
S3 버킷 구조
RDS 백업/복구 절차
장애 대응 체크리스트
비용 점검 루틴
IAM 권한 목록

➕ 16-2. 운영 문서 템플릿 예시

## 운영 서버 정보

### 도메인
- 고객 페이지: www.example.com
- 관리자 페이지: admin.example.com
- API: api.example.com
- CDN: cdn.example.com

### AWS 리소스
- EC2: togethermall-prod-api
- RDS: togethermall-prod-db
- S3: togethermall-prod-assets
- CloudFront: togethermall-prod-front
- Route 53 Hosted Zone: example.com

### 배포 절차
1. main 브랜치 병합
2. GitHub Actions 실행 확인
3. API health check 확인
4. PM2 logs 확인
5. 주요 기능 테스트

### 장애 대응
- 502 발생: PM2 → Nginx → 환경변수 → DB 순서로 확인
- DB 오류: RDS 상태 → 보안 그룹 → DATABASE_URL → Prisma 순서로 확인
- 이미지 오류: S3 key → CloudFront → 권한 → 캐시 순서로 확인

✅ 17. 최종 운영 체크리스트

➕ 17-1. 서버 체크리스트

EC2 SSH 접근이 내 IP로 제한되어 있는가?
Nginx 설정이 백업되어 있는가?
PM2 프로세스가 자동 재시작되도록 설정되어 있는가?
서버 재부팅 후 앱이 자동 실행되는가?
디스크 용량을 주기적으로 확인하는가?

➕ 17-2. DB 체크리스트

RDS Public Access가 꺼져 있는가?
RDS 보안 그룹이 EC2만 허용하는가?
자동 백업이 켜져 있는가?
중요한 작업 전 수동 스냅샷을 생성하는가?
운영 마이그레이션 명령어를 구분하는가?

➕ 17-3. 파일/정적 자산 체크리스트

S3 public/private 경로가 분리되어 있는가?
CloudFront 캐시 정책이 적절한가?
이미지 최적화가 되어 있는가?
S3 Lifecycle 정책이 있는가?
비공개 파일 접근 방식이 안전한가?

➕ 17-4. 보안 체크리스트

루트 계정 MFA가 설정되어 있는가?
Access Key가 노출되지 않았는가?
IAM 권한이 최소 권한인가?
관리자 API 권한 검사가 백엔드에 있는가?
로그에 민감정보가 남지 않는가?

➕ 17-5. 비용 체크리스트

AWS Budgets가 설정되어 있는가?
Cost Explorer를 정기적으로 확인하는가?
사용하지 않는 EC2/RDS/EBS/Elastic IP가 없는가?
CloudWatch 로그 보관 기간이 설정되어 있는가?
S3와 스냅샷이 무한히 쌓이지 않는가?

✅ 18. 다음 단계로 공부하면 좋은 주제

AWS 운영 실무 기초를 마무리했다면, 다음 단계에서는 더 실무적인 백엔드/운영 고급 주제로 넘어갈 수 있습니다.

➕ 18-1. 추천 다음 시리즈

백엔드 실무 심화
- 트랜잭션과 동시성 제어
- Queue와 비동기 작업
- Redis 캐싱
- 검색과 인덱스 설계
- 대용량 엑셀 다운로드
- 관리자 권한 설계
- 이벤트/사전예약 시스템 설계

서비스 운영 자동화
- GitHub Actions 심화
- Docker 배포
- 무중단 배포
- 로그 중앙화
- Slack 알림
- 배치 작업
- 정기 리포트 자동화

현재 실무 흐름을 기준으로는 다음 시리즈를 백엔드 실무 심화로 이어가는 것이 좋습니다.
AWS 구조를 이해한 뒤에는 실제 비즈니스 로직, DB 정합성, 관리자 기능, 비동기 처리로 넘어가는 흐름이 자연스럽습니다.

✅ 19. AI를 활용해 AWS 아키텍처를 검토할 때 질문법

AWS 구조를 AI에게 검토받을 때는 서비스 규모, 현재 구조, 문제 상황, 예산을 함께 알려줘야 합니다.
단순히 “AWS 구조 추천해줘”라고 하면 너무 일반적인 답이 나올 수 있습니다.

➕ 19-1. 좋은 질문 예시

React + NestJS + PostgreSQL 기반 온라인 휴대폰 판매 사이트의 AWS 구조를 검토하고 싶어.

현재 구조:
1. 고객 페이지는 React/Vite
2. 관리자 페이지도 React/Vite
3. 백엔드는 NestJS
4. DB는 PostgreSQL
5. 파일 업로드와 배너 이미지가 있음
6. AWS는 EC2, RDS, S3, CloudFront, Route 53 사용 예정
7. 1인 개발자가 운영해야 함
8. 초기 트래픽은 작지만 광고 유입이 있음
9. 비용은 낮게 시작하고 싶음

요청:
- 초기 운영 구조
- 확장 구조
- 보안 그룹 설계
- S3 public/private 경로
- 배포 흐름
- 장애 대응 체크리스트
- 비용 주의점
을 나눠서 검토해줘.

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

무조건 비싼 구조를 추천하지 않는가?
초기 구조와 확장 구조를 구분하는가?
EC2, RDS, S3, CloudFront 역할을 명확히 나누는가?
RDS 외부 공개를 피하라고 하는가?
S3 버킷 전체 public을 피하라고 하는가?
1인 개발자가 관리 가능한 현실적인 구조인가?
비용, 보안, 백업, 로그까지 함께 고려하는가?

📌 요약

AWS 아키텍처는 프론트엔드, 백엔드, DB, 파일 저장소, 도메인, SSL, 보안, 로그, 백업, 비용을 연결해 운영 구조를 설계하는 작업입니다.
초기에는 EC2 중심의 단순 구조로 시작할 수 있지만, 실제 운영에서는 S3/CloudFront, RDS, IAM, CloudWatch를 분리해 관리하는 것이 좋습니다.
고객 페이지, 관리자 페이지, API, CDN은 서브도메인으로 나누면 운영과 디버깅이 쉬워집니다.
프론트엔드는 S3 + CloudFront, 백엔드는 EC2 + Nginx + PM2, DB는 RDS, 파일은 S3로 분리하는 구조가 1인 개발자에게 현실적인 기본 운영 구조입니다.
운영에서 중요한 것은 화려한 구조보다 보안 그룹, IAM, 백업, 로그, 비용 알림, 배포 기록 같은 기본기를 꾸준히 지키는 것입니다.
AWS 운영 실무 기초 이후에는 백엔드 실무 심화, Docker 배포, Redis 캐싱, Queue, 트랜잭션, 관리자 기능 설계 같은 주제로 넘어가면 좋습니다.

juni

이전 포스트

TIL - 20260618

다음 포스트

TIL - 20260619

TIL

0619 AWS 운영 실무 기초 (10/N): 전체 아키텍처 설계와 운영 체크리스트

✅ 1. AWS 아키텍처란 무엇인가?

➕ 1-1. 아키텍처 설계가 중요한 이유

✅ 2. 작은 서비스의 초기 AWS 구조

➕ 2-1. 초기 구조 예시

➕ 2-2. 장점

➕ 2-3. 단점

✅ 3. 운영에 적합한 기본 AWS 구조

➕ 3-1. 기본 운영 구조 예시

➕ 3-2. 서비스별 역할

✅ 4. 도메인 구조 설계

➕ 4-1. 추천 서브도메인 구조

➕ 4-2. 도메인별 연결 예시

✅ 5. 프론트엔드 배포 설계

➕ 5-1. 프론트엔드 배포 흐름

➕ 5-2. 프론트엔드 운영 체크 포인트

✅ 6. 백엔드 배포 설계

➕ 6-1. 백엔드 운영 흐름

➕ 6-2. 백엔드 운영 체크 포인트

✅ 7. 데이터베이스 설계

➕ 7-1. RDS 운영 구조

➕ 7-2. DB 운영 체크 포인트

✅ 8. 파일 저장소 설계

➕ 8-1. S3 파일 구조 예시

➕ 8-2. 파일 운영 체크 포인트

✅ 9. 보안 설계

➕ 9-1. 보안 기본 구조

➕ 9-2. 보안 체크 포인트

✅ 10. 모니터링 설계

➕ 10-1. 최소 모니터링 구성

➕ 10-2. 모니터링 체크 포인트

✅ 11. 백업과 복구 설계

➕ 11-1. 최소 백업 구조

➕ 11-2. 백업/복구 체크 포인트

✅ 12. 비용 설계

➕ 12-1. 비용이 자주 새는 항목

➕ 12-2. 비용 관리 체크 포인트

✅ 13. CI/CD와 배포 자동화 설계

➕ 13-1. GitHub Actions 배포 흐름 예시

➕ 13-2. 배포 자동화 체크 포인트

✅ 14. 개발/운영 환경 분리

➕ 14-1. 분리해야 할 것

➕ 14-2. 환경 분리 체크 포인트

✅ 15. 1인 개발자 기준 현실적인 최종 구조

➕ 15-1. 추천 구조

➕ 15-2. 이 구조의 장점

✅ 16. 운영 문서화

➕ 16-1. 반드시 작성하면 좋은 문서

➕ 16-2. 운영 문서 템플릿 예시

✅ 17. 최종 운영 체크리스트

➕ 17-1. 서버 체크리스트

➕ 17-2. DB 체크리스트

➕ 17-3. 파일/정적 자산 체크리스트

➕ 17-4. 보안 체크리스트

➕ 17-5. 비용 체크리스트

✅ 18. 다음 단계로 공부하면 좋은 주제

➕ 18-1. 추천 다음 시리즈

✅ 19. AI를 활용해 AWS 아키텍처를 검토할 때 질문법

➕ 19-1. 좋은 질문 예시

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

📌 요약

TIL - 20260618

TIL - 20260620

0개의 댓글