속도를 위해 빚진 인프라, 이제 안정성으로 상환할 때입니다
해커톤의 15시간이라는 극단적인 제약 속에서 탄생한 ‘Locally(로컬리)’ 프로젝트는 초기 개발 속도를 극대화하기 위해 탁월한 선택을 했습니다. 프론트엔드와 백엔드는 Vercel과 Supabase라는 편리한 클라우드 서비스를 사용하고, 비용이 많이 드는 AI 추론 모듈은 팀원의 ‘로컬 컴퓨터(GPU 서버)‘에서 구동하는 방식입니다.
하지만 서비스가 성장하고 실제 유저의 트래픽을 받아내야 하는 시점이 오면서, 이 ‘빠르고 저렴했던’ 구조는 **비즈니스의 발목을 잡는 가장 큰 리스크(기술 부채)**가 되었습니다. 이 문서는 PM(Project Manager)의 시각에서 현재 구조의 리스크를 진단하고, 이를 어떻게 안전하고 확장 가능한 클라우드(AWS) 환경으로 이전할 것인지에 대한 구체적인 마이그레이션 전략을 담고 있습니다.
1. 현재 구조의 해석: 우리 AI는 지금 ‘연구실 컴퓨터’에 있습니다
현재 Locally의 아키텍처는 다음과 같습니다.
- 사용자 접점 (Vercel): 누구나 24시간 안정적으로 접속할 수 있는 현대적인 쇼핑몰 건물입니다.
- 데이터 저장소 (Supabase): 고객 정보와 데이터를 안전하게 보관하는 클라우드 금고입니다.
- AI 모듈 (로컬 GPU 서버): 가장 핵심적인 두뇌 역할을 하지만, 누군가의 개인 연구실에 있는 컴퓨터 한 대에서 돌아가고 있습니다.
PM 관점에서의 3대 비즈니스 리스크
- SPOF (단일 장애점): 로컬 서버가 있는 곳에 정전이 나거나, 인터넷이 끊기거나, 컴퓨터가 다운되면 Locally의 핵심 기능인 ‘AI 여행 플래너’가 즉각 마비됩니다.
- 트래픽 대응 불가 (스케일아웃 불가): 마케팅 대성공으로 동시 접속자가 10배 늘어났을 때, Vercel(웹)은 버티지만 로컬 AI 서버는 요청을 처리하지 못하고 뻗어버립니다. 물리적인 컴퓨터를 당장 10대 사서 연결할 수 없기 때문입니다.
- 인적 의존성과 보안: 해당 컴퓨터를 관리하는 특정 팀원에게 운영 부담이 집중되며, 회사의 핵심 AI 자산과 데이터가 개인 환경에 노출되어 있습니다.
2. 해결책: ‘표준 규격화(Docker)‘와 ‘클라우드 인프라(Terraform)’
이 문제를 해결하기 위해 우리는 AI 모듈을 클라우드(AWS)로 이사시켜야 합니다. 이 과정을 성공적으로 수행하기 위해 두 가지 핵심 기술이 사용됩니다.
- Docker (도커) - AI 모듈의 이삿짐 박스화: 현재 로컬 컴퓨터 환경(운영체제, GPU 설정, 파이썬 버전 등)에 복잡하게 얽혀있는 AI 프로그램을, 어디서든 똑같이 실행될 수 있는 **‘표준 규격의 컨테이너 박스’**로 포장하는 기술입니다.
- Terraform (테라폼) - 인프라의 설계도화 (IaC): AWS 클라우드에 AI 서버를 띄우고, 네트워크를 연결하는 복잡한 과정들을 마우스 클릭(GUI)이 아닌 **‘코드(설계도)‘**로 작성하여 자동화하고 기록을 남기는 기술입니다.
3. 딥다이브: AI 모델의 AWS 이관 세부 전략
AI 서버를 AWS로 옮길 때 가장 큰 허들은 ‘GPU(그래픽 카드)’ 환경을 맞추는 것과 ‘비용’입니다. 이를 어떻게 풀어나갈지에 대한 기술적 접근입니다.
단계 3-1. AI 모듈 컨테이너화 (Dockerizing)
로컬에서 잘 도는 AI 코드가 클라우드에서도 똑같이 돌기 위해서는 완벽한 포장이 필요합니다.
- 의존성 격리: AI 모델이 사용하는 무거운 라이브러리(PyTorch, TensorFlow 등)와 NVIDIA GPU 드라이버(CUDA) 버전을
Dockerfile이라는 명세서에 정확히 기록합니다. - 경량화: 불필요한 파일은 제외하고, 딱 AI 추론에 필요한 환경만 압축하여 ‘Docker Image’를 생성합니다. 이렇게 만든 이미지는 AWS의 창고(ECR)에 안전하게 보관됩니다.
단계 3-2. AWS GPU 인프라 선택 전략 (비용 vs 편의성)
AWS에서 GPU를 사용하는 방법은 크게 두 가지가 있으며, 서비스의 성장 단계에 맞춰 선택해야 합니다.
| 구분 | Amazon EC2 (G4dn, G5 인스턴스) | Amazon SageMaker (Endpoints) |
|---|---|---|
| 비유 | 클라우드상의 고성능 빈 컴퓨터(GPU 장착)를 빌려서 직접 세팅 | AI 추론에만 딱 맞춰진 완전 관리형 AI 서빙 플랫폼 |
| 장점 | 상대적으로 저렴한 비용. 자유도가 매우 높음. | 서버 관리 불필요. 오토스케일링(트래픽에 따른 자동 확장)이 매우 쉬움. |
| 단점 | OS 업데이트, 보안 패치, 스케일링을 개발팀이 직접 구성(Terraform/ECS 등 활용)해야 함. | 초기 세팅 학습 곡선이 있고, 사용량 대비 비용이 상대적으로 높음. |
| PM 추천 | 초기 마이그레이션 단계 추천. 예산 통제가 수월하며, Terraform으로 관리를 자동화하면 운영 부담을 줄일 수 있음. | 서비스가 급격히 성장하여 트래픽 예측이 어렵고, 인프라 관리 인력이 부족할 때 전환. |
4. 실행을 위한 Two-Track 마이그레이션 로드맵
서비스 중단 없이, 개발 리소스를 안배하며 진행하는 2단계 계획입니다.
Phase 1: 현행 유지 + 가시성 확보 (Terraform 기초 공사)
- 목표: 현재 잘 돌아가는 구조는 놔두되, 흩어진 설정들을 Terraform 코드로 중앙 집중화합니다.
- AI 전략: AI 서버는 당분간 로컬에 두지만, 외부와 통신하는 방식을 안전한 터널링(예: Cloudflare Tunnels)으로 구성하고 이 터널링 설정을 Terraform으로 관리합니다.
- PM 체크포인트: 서비스 다운타임 없음. 개발팀이 Terraform 다루는 법을 숙달하는 기간.
Phase 2: AI 클라우드 이관 및 전면 AWS 전환 (본 게임)
- 목표: 준비된 Docker Image를 AWS EC2(GPU) 기반의 컨테이너 서비스(ECS)에 배포합니다.
- AI 전략:
- VPC(가상 사설망)를 구축하여 보안을 강화합니다.
- 로컬 AI 서버의 트래픽을 AWS의 새 AI 서버로 10% → 50% → 100% 점진적으로 넘깁니다(Canary 배포).
- 데이터베이스(Supabase)도 장기적으로 AWS RDS로 이전하여 Vercel/Supabase 의존도를 낮춥니다.
- PM 체크포인트: AWS 인프라(특히 GPU) 발생 비용에 대한 예산 승인 필요. 이관 완료 후 로컬 AI 서버 장비 반납/용도 변경.
5. 결론 및 PM 액션 아이템
이 마이그레이션은 단순히 ‘서버 위치를 옮기는 것’이 아니라, Locally가 학생들의 해커톤 프로젝트에서 ‘엔터프라이즈급 B2C 서비스’로 도약하기 위한 필수적인 체질 개선입니다.
✅ PM이 챙겨야 할 Next Step:
- 비용 검토: AWS GPU 인스턴스(예:
g4dn.xlarge등)의 월 예상 비용을 산출하고 예산을 확보합니다. - 일정 조율: AI 엔지니어와 백엔드/인프라 엔지니어가 협업하여 ‘AI 모듈 Docker 컨테이너화’ 작업을 이번 혹은 다음 스프린트 백로그에 할당합니다.
- 지표 설정: 이관 전후의 AI 응답 속도(Latency)와 성공률 추이를 모니터링할 대시보드를 기획합니다.