속도를 위해 빚진 인프라, 이제 완전한 독립과 안정성으로 상환할 때입니다
해커톤의 15시간이라는 극단적인 제약 속에서 탄생한 ‘Locally(로컬리)’ 프로젝트는 초기 개발 속도를 극대화하기 위해 Vercel, Supabase(PostgreSQL), Upstash(Redis), 그리고 팀원의 로컬 컴퓨터(AI API 서버)라는 파편화된 구조를 선택했습니다.
하지만 서비스가 성장하고 트래픽을 감당해야 하는 시점이 오면서, 외부 SaaS 서비스들에 대한 의존성(비용 한계, 제어권 상실)과 로컬 서버의 불안정성은 비즈니스의 발목을 잡는 가장 큰 리스크가 되었습니다.
이 문서는 파편화된 데이터베이스(PostgreSQL, Redis)와 AI API 서버를 AWS 클라우드의 단일 환경(Docker)으로 통합하여 완전히 독립적이고 제어 가능한 인프라로 마이그레이션하는 구체적인 전략을 담고 있습니다.
1. 현재 구조의 한계: ‘남의 집 셋방살이’와 ‘연구실 컴퓨터’
현재 Locally의 백엔드/인프라 아키텍처는 다음과 같습니다.
- 데이터 저장소 (Supabase - PostgreSQL): 편리하지만 트래픽이 늘어날수록 요금 폭탄의 위험이 있고, DB 상세 튜닝이 불가능합니다.
- 캐시/세션 (Upstash - Redis): 외부 네트워크를 타고 통신해야 하므로 응답 속도(Latency)에 손해를 봅니다.
- AI API 모듈 (로컬 서버): 가장 핵심적인 두뇌 역할을 하지만, 누군가의 개인 컴퓨터에서 돌아가고 있어 정전이나 인터넷 끊김에 무방비 상태입니다.
PM 관점에서의 3대 비즈니스 리스크
- SPOF (단일 장애점) 및 네트워크 지연: 데이터베이스, 캐시, API 서버가 물리적으로 다 다른 곳에 떨어져 있어 통신 속도가 느리고, 셋 중 하나만 장애가 나도 서비스가 멈춥니다.
- 데이터 주권 및 제어권 상실: 고객 데이터가 외부 SaaS(Supabase)에 종속되어 있어, 장애 발생 시 우리가 직접 복구하거나 대응할 수 없습니다.
- 운영 복잡도 및 보안: 로컬 PC와 외부 SaaS들을 연결하기 위한 보안 설정이 복잡하고 파편화되어 있습니다.
2. 해결책: ‘올인원 컨테이너(Docker)‘와 ‘클라우드 인프라(Terraform)’
이 문제를 해결하기 위해 우리는 API 서버, PostgreSQL, Redis를 모두 묶어 AWS 클라우드의 안전한 울타리 안으로 이사시켜야 합니다.
- Docker Compose - 인프라의 규격화 및 통합: AI API 서버뿐만 아니라, PostgreSQL(DB)과 Redis(캐시)까지 모두 Docker 컨테이너로 만듭니다. 이 3개의 컨테이너를 하나의 세트(Docker Compose)로 묶어 서로 가장 빠른 속도로 통신하게 만듭니다.
- Terraform (테라폼) - 인프라의 설계도화 (IaC): 이 컨테이너 세트가 올라갈 AWS의 튼튼한 서버(EC2)와 네트워크(VPC), 방화벽(Security Group)을 마우스 클릭이 아닌 **‘코드(설계도)‘**로 작성하여 구축합니다.
3. 딥다이브: All-in-One AWS 이관 세부 전략
데이터베이스(상태 저장)가 포함된 마이그레이션이므로, 데이터 유실 방지와 안정적인 성능 확보가 최우선입니다.
단계 3-1. 백엔드 생태계의 완전한 컨테이너화 (Dockerizing)
어디서든 띄울 수 있는 독립적인 백엔드 환경을 구축합니다.
- API 컨테이너:
hamster_locally파이썬 코드를 실행하는 가벼운 컨테이너. - DB 컨테이너: PostgreSQL 16 공식 이미지를 사용하되, 데이터가 날아가지 않도록 호스트 서버(EC2)의 디스크(EBS 볼륨)에 데이터를 안전하게 매핑(Volume Mount)합니다.
- Cache 컨테이너: Redis 7 공식 이미지를 사용하여 API 서버와 초고속 메모리 통신을 구성합니다.
단계 3-2. AWS 인프라 선택: EC2 단일 인스턴스 (비용 효율성)
초기 마이그레이션 단계에서는 복잡한 쿠버네티스(EKS)나 관리형 DB(RDS) 대신, 성능이 넉넉한 EC2 인스턴스 1대에 Docker Compose로 3개의 컨테이너를 모두 띄우는 방식을 선택합니다.
- 장점:
- 압도적인 가성비: RDS나 ElastiCache를 따로 쓰는 것보다 비용이 훨씬 저렴합니다.
- 최고의 성능: API, DB, Redis가 같은 컴퓨터(localhost) 안에서 통신하므로 네트워크 지연(Latency)이 0에 가깝습니다.
- 관리의 단순화: Terraform으로 EC2 한 대만 프로비저닝하면 되므로 인프라 복잡도가 낮습니다.
- 단점 극복: EC2가 죽으면 DB 데이터가 날아갈 수 있는 위험은, Terraform을 통해 디스크(EBS)를 EC2와 분리하여 독립적으로 존재하게 만들고, 주기적인 스냅샷 백업을 자동화하여 해결합니다.
4. 실행을 위한 마이그레이션 로드맵
서비스 중단 없이 외부 의존성을 끊어내는 단계적 계획입니다.
Phase 1: AWS 인프라 구축 및 컨테이너 테스트 (Terraform & Docker)
- 목표: AWS에 새 집을 짓고, 로컬에서 잘 도는지 확인했던 Docker Compose 환경을 클라우드에 띄워봅니다.
- 액션:
- Terraform으로 AWS VPC, Security Group, EC2 인스턴스를 코드로 생성합니다.
- EC2 내부에 Docker를 설치하고 API, PostgreSQL, Redis 컨테이너를 실행합니다.
- Vercel(프론트엔드)에서 테스트용 트래픽을 새 AWS 서버로 보내 통신을 확인합니다.
Phase 2: 데이터 마이그레이션 및 전면 전환 (Cut-over)
- 목표: 기존 Supabase에 있던 실제 유저 데이터를 새 AWS 내부의 PostgreSQL로 옮기고 트래픽을 완전히 전환합니다.
- 액션:
- 서비스 점검 시간을 공지합니다 (새벽 시간대 1~2시간).
- Supabase의 데이터를 덤프(Dump)하여 AWS EC2의 PostgreSQL로 복원(Restore)합니다.
- 프론트엔드(Vercel)의 환경 변수(API 주소, DB 연결 정보 등)를 AWS 주소로 변경하고 배포합니다.
- 기존 Supabase, Upstash, 로컬 터널링을 종료합니다.
5. 결론 및 PM 액션 아이템
이번 마이그레이션은 비싼 SaaS와 불안정한 로컬 환경에서 벗어나, **우리가 온전히 통제할 수 있는 독립적이고 빠르고 경제적인 클라우드 성(Castle)**을 구축하는 과정입니다.
✅ PM이 챙겨야 할 Next Step:
- 비용 승인: 통합 환경을 돌릴 AWS EC2 인스턴스(예:
t3.medium또는t3.large) 및 스토리지(EBS)의 월 예상 비용을 확인하고 승인합니다. (기존 SaaS 요금과 비교) - 데이터 이전 계획: 기존 Supabase 데이터를 AWS로 끊김 없이 옮길 데이터 마이그레이션 전략(덤프 및 복원 스크립트)을 백엔드/인프라 담당자와 리뷰합니다.
- 다운타임 협의: Phase 2의 데이터 전환 시점에 발생할 서비스 점검 시간을 기획하고 사용자 공지 방안을 마련합니다.