FileStack에서 S3로: 별것 아닌 마이그레이션이 가져다 준 것들

FileStack에 의존하던 회사 로고/프로필 이미지 업로드를 S3로 통합하면서 겪었던 문제와 해결 과정을 정리한 글입니다.

도입 배경

• 초기에 FileStack은 “핵심이 아닌 업로드 기능” 구현 시간을 크게 줄여줬고, 프로덕션에서도 오랫동안 문제 없이 사용
• 시간이 지나 S3 인프라가 갖춰졌는데, 로고/프로필만 외부 서비스에 남아있는 구조가 신경 쓰이기 시작
• Dev/테스트 환경에서는 FileStack Rate Limit로 이미지가 깨지는 일이 잦아짐

문제

• 로컬에서 AWS S3로 개발하려니 STS 임시 토큰 만료, 네트워크 의존성, 온보딩 허들이 불편
• 마이그레이션 중 놓칠 뻔한 함정: 이메일 로고가 presigned URL TTL 만료로 나중에 깨질 수 있음

해결

• 로컬 개발은 MinIO로 단순화(S3 API 호환, Docker로 간단히 구성)
• 이메일 로고는 버킷을 private로 유지하면서, CloudFront에서 public/* 경로만 공개하는 방식으로 분리

왜 이번엔 했나

• “레거시 개선”은 늘 ROI 문제라 미루기 쉬운데, 이번엔 AI 코딩 도구 덕분에 삽질 비용이 줄어서 ‘해볼 만하다’는 판단이 섰음
• 솔직히 AI 없이는 시도하지 않았을 것

배운 점

• FileStack은 나쁜 선택이 아니라, 그때는 최선이었고 “언제 걷어낼지”가 더 중요한 문제
• 상황이 바뀌면 걷어내면 되고, AI 도구들이 그 “나중”을 더 수월하게 만들어주고 있음