S3, DynamoDB, EC2 세팅 (3)

 

 

왜 먼저 인프라부터 구축했을까?

이 프로젝트는 “영상 → 텍스트 추출 → 요약 → PDF 생성”까지 자동으로 처리하는 서비스다.

핵심 로직은 Whisper + FastAPI이지만, 그 전에 먼저 해야 할 일이 있었다.

이 서비스가 실제로 동작하려면
파일 저장소, 메타데이터 저장소, 서버가 필요하다.

 

그래서 오늘은 다음 세 가지를 먼저 구축했다.

• 파일 저장: Amazon S3
• 메타데이터 저장: Amazon DynamoDB
• API 서버 실행: Amazon EC2

---

전체 아키텍처 구조

이번 프로젝트의 기본 구조는 아래와 같다.

[사용자]
    ↓
[S3 + CloudFront] ← React 프론트엔드
    ↓ API 호출
[EC2 - FastAPI + Whisper]
    ↓ 저장
[S3 - 결과 파일] + [DynamoDB - 메타데이터]

프론트엔드는 S3에 정적 호스팅하고,
API 서버는 EC2에서 실행한다.

파일은 S3에,
처리과정 관련 상태는 DynamoDB에 저장한다.

---

S3 버킷 생성

S3 버킷 이름은 전 세계에서 유일해야 한다

S3는 글로벌 네임스페이스를 사용한다.
즉, video-transcription-files 같은 이름은 이미 누군가 쓰고 있을 가능성이 높다.

# 파일 저장용
aws s3 mb s3://video-transcription-files-[고유한 이름] --region ap-northeast-2

# 프론트엔드 호스팅용
aws s3 mb s3://video-transcription-frontend-[고유한 이름] --region ap-northeast-2

두 버킷의 역할 분리

버킷	역할
files	영상, 텍스트, PDF 등 실제 데이터 저장
frontend	React 빌드 결과물 (정적 웹사이트)

이렇게 분리해두면:

• 데이터 접근 정책을 다르게 설정 가능
• 나중에 CloudFront 연결이 깔끔해짐
• 보안 관리가 명확해짐

---

DynamoDB 테이블 생성

S3만 사용하더라고 파일을 효과적으로 저장하고 조회할 수있다.

하지만 저장하는 데이터가 많아지고,

약간의 비즈니스 로직이 더해지는 순간 복잡도가 크게 늘어난다.

특히 파이프라인 과정 중 특정 단계에서 실패하는 경우,

재시도를 해야하는 경우 등을 고려할 때 S3 만으로 관리는 힘들고 비효율적이다.

그래서 메타데이터는 DynamoDB에 따로 저장하기로 했다.

---

S3 vs DynamoDB 역할 분담

DynamoDB (빠른 조회)           S3 (실제 파일)
───────────────────────       ───────────────────────
video_id                      videos-temp/abc123.mp4
status                        transcripts/abc123.txt
pipeline 상태                  pdfs/abc123.pdf
summary
S3 경로 참조

DynamoDB는 “상태 추적”
S3는 “파일 저장”

---

파이프라인을 단계별로 나눈 이유

{
  "video_id": "abc123",
  "status": "completed",
  "pipeline": {
    "upload": { "status": "success" },
    "transcription": { "status": "success" },
    "summarization": { "status": "success" },
    "pdf_generation": { "status": "success" }
  }
}

이렇게 분리해두면,

예를 들어 PDF 생성에서 실패했을 경우
Whisper를 다시 돌릴 필요 없이 해당 단계만 재시도할 수 있다.

→ 운영 관점에서 매우 중요하다.

---

테이블 생성

aws dynamodb create-table \
  --table-name VideoProcessing \
  --attribute-definitions \
    AttributeName=video_id,AttributeType=S \
  --key-schema \
    AttributeName=video_id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --region ap-northeast-2

PAY_PER_REQUEST는 요청한 만큼만 과금하는 방식이다.

학습 프로젝트라 트래픽이 적기 때문에
프리티어 범위 내에서 충분히 운영 가능하다.

---

EC2 인스턴스 설정

이제 실제 서버를 만든다.

전체 흐름

1. 키 페어 생성
2. 보안 그룹 생성
3. EC2 생성
4. SSH 접속

---

🔐 키 페어 생성

EC2는 기본적으로 비밀번호 로그인 대신
공개키/비밀키 기반 인증을 사용한다.

aws ec2 create-key-pair \
  --key-name video-transcription-key \
  --query 'KeyMaterial' \
  --output text \
  --region ap-northeast-2 > ~/.ssh/video-transcription-key.pem

--query와 --output text

AWS CLI는 JSON을 반환한다.
그 상태로 파일에 저장하면 키 형식이 깨진다.

• --query 'KeyMaterial'
• --output text

→ 비밀키 내용만 순수 텍스트로 추출

이때 사용하는 쿼리 문법이 JMESPath다.

---

파일 사용 권한 조정

chmod 400 ~/.ssh/video-transcription-key.pem

SSH는 키 파일 권한이 너무 열려 있으면
보안 위험으로 간주하고 접속을 거부한다.

400 = 나만 읽기 가능

---

🔥 보안 그룹 생성

보안 그룹은 EC2의 방화벽이다.

aws ec2 create-security-group ...

그리고 SSH 접속을 위해 22번 포트를 열었다.

aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxx \
  --protocol tcp \
  --port 22 \
  --cidr [내IP]/32

/32는 “딱 이 IP 하나만 허용”한다는 의미다.

절대 0.0.0.0/0으로 SSH를 열어두면 안 된다.

---

🖥 EC2 인스턴스 생성

AMI는 OS 템플릿이다.
이번에는 Ubuntu 22.04를 선택했다.

aws ec2 run-instances \
  --image-id ami-xxxxxxxx \
  --instance-type t3.xlarge \
  --key-name video-transcription-key \
  --security-group-ids sg-xxxx \
  --region ap-northeast-2

SSH 접속

ssh -i ~/.ssh/video-transcription-key.pem ubuntu@3.38.xxx.xxx

처음 접속하면 host authenticity 확인 메시지가 뜬다. 

yes 라고 입력하고 진행하자.

그냥 무심코 엔터 눌렀다가 계속 오류가 났다.

---

💰 비용 주의

t3.xlarge는 시간당 과금된다.

• stop → 일시정지 (요금 중단, 데이터 유지)
• terminate → 완전 삭제 (복구 불가)

사용 후 반드시 stop 하는 습관이 필요하다.

 

요약

✅ S3 버킷 2개 생성
✅ DynamoDB 테이블 생성
✅ EC2 인스턴스 생성 및 SSH 접속 확인

⬜ EC2 개발 환경 세팅
⬜ FastAPI 구현
⬜ Whisper 통합
⬜ 요약 API 연동
⬜ PDF 생성
⬜ React 프론트엔드
⬜ CloudFront 배포