☁️ SNS 사이드 프로젝트에서의 이미지 파일 저장 전략과 인프라 설계

SNS 서비스를 사이드 프로젝트로 구현하면서 이미지 파일을 어떻게 저장할지 고민이 생겼습니다.

처음에는 Spring Boot 내부에서 파일을 직접 받아 서버에 저장하고 관리하는 구조를 고려했지만, 결국 AWS S3를 사용하기로 결정했습니다.

✅ 왜 S3인가?

• 성능 측면: WAS가 직접 파일을 핸들링하는 것보다 S3에 위임하는 것이 I/O 성능 부담을 줄입니다.
• 확장성 측면: 트래픽 증가 시에도 S3는 서버리스 기반으로 자동 확장됩니다.
• 유지보수성: 정적 자산은 정적 자산답게! 관리 책임을 분리할 수 있습니다.

온디맨드 수요에 맞춰 잘 설계된 클라우드 구조를 이해하면서, 확장성과 책임 분리를 자연스럽게 체득하게 됐습니다.

---

🛠️ 인프라 구성: Terraform + GitHub Actions

클라우드를 배우면서 자연스럽게 IAC(Infrastructure as Code)에 관심을 갖게 되었고,

Terraform을 통해 실습용 아키텍처를 코드로 구성해보았습니다.

또한 GitHub Actions를 연동하여 코드 푸시 시 자동으로 배포 및 이미지를 갱신하도록 만들었습니다.

resource "aws_s3_bucket" "image_bucket" {
  bucket = "my-sns-image-bucket"
  acl    = "public-read"

  tags = {
    Name = "SNS Image Bucket"
  }
}

# .github/workflows/deploy.yml
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Build Docker Image
        run: |
          docker build -t $DOCKER_IMAGE_NAME .
      - name: Push to GHCR
        run: |
          docker push ghcr.io/username/$DOCKER_IMAGE_NAME:latest

---

⚙️ 앞으로

• CloudFront와 S3를 연결하여 정적 파일의 CDN 최적화
• API 서버(Spring Boot)는 EC2에서 관리하되, 이미지 정적 파일만 S3로 위임
• 보안 설정 및 버킷 정책을 통해 접근 제어

---

이번 실습을 통해 “어떤 파일은 서버에서 관리하지 않는 것이 더 좋은가?“라는 질문에 대해 스스로 답을 찾게 되었습니다.

향후 MSA나 CDN 도입 시에도 이 경험이 좋은 밑거름이 될 것이라 생각합니다.