V1 단계에서는 핵심기능의 빠른 출시를 목표로 한다. 추가적으로 Dev/Prod 장애 영향 분리와 최소 인프라 비용, 배포 환경에서의 데이터 백업 가능을 고려한다.

현재는 Prod와 Dev에 각각 EC2가 한 대뿐이므로 ALB의 로드밸런싱 기능이 필요하지 않다. Private Subnet을 사용하면 외부 LLM·교통 API 호출을 위해 NAT Gateway가 추가로 필요한데, Private Subnet의 서버가 외부 인터넷으로 나가려면 NAT 같은 별도 경로에 따라 비용이 발생할 수 있다.

• 시간당 약 $0.059 → 월 $43
• 데이터 처리 GB당 과금
• Prod/Dev 둘 다 두면 월 $86 예상

FastAPI가 V1과 V2 에서 외부 AI API와 교통 API를 호출한다. 이때 Public EC2는 Internet GW를 통해 외부 API 호출할 수 있어 네트워크 구성이 단순해진다.

인프라 운영 담당자는 1명이고 예산은 제한적인 상황에서 V1에서 완벽한 보안,고가용성보다 빠른 구현과 운영 단순성이 우선순위가 높다고 판단했다.

보안그룹은 다음과 같이 지정했다.

V1의 Dev는 실제 사용자 서비스가 프론트엔드·백엔드 통합 테스트와 QA, 배포 전 검증을 위한 용도로 띄운 인스턴스이다.

따라서 운영자가 직접 접속해 컨테이너 로그를 확인하거나 Docker Compose를 재시작하는 작업이 자주 발생하기 때문에 운영자 IP로 SSH 접속할 수 있게 열었다.

Dev에는 운영자 IP에 한에 SSH 22번 포트를 허용해 진행하며, Prod 환경의 경우 SSM 을 이용해서 접속해야 한다.

따라서 아래 IAM이 필요하다.

• EC2의 ECR Pull 권한
• EC2의 S3 백업 업로드 권한
• CloudWatch 로그 전송 권한
• SSM 접속 권한
• GitHub Actions의 ECR Push와 SSM 배포 권한

인프라 담당자가 1명이여서 장애 발생 시 컨테이너별 로그를 확인하는 방식은 운영 비용이 많이 들기 때문에 V1에서도 로그 분석을 위한 CloudWatch 를 추가한다.

단일 EC2이기 때문에 장애 발생 시 인스턴스가 죽으면 로그도 끊기게 된다. 그래서 로그를 EBS에만 쌓으면 안되고 실시간으로 CloudWatch에서 받아 사후 분석을 진행할 수 있게 한다.

RDS를 사용하지 않고, DB 컨테이너를 선택한 시점에서 아래 위험을 수용한다.

• EC2 장애 시 서비스 중단 가능
• 복구는 백업 파일과 EBS에 의존하면
• 백업 주기만큼 데이터 손실 가능

S3는 EBS의 복구용 사본을 저장하는 DB 백업 목적과 사용자 파일 저장 목적으로 Bucket과 Prefix 수준에서 분리한다.

각 EC2의 Nginx는 외부 요청을 서비스별로 분기한다. 아래의 구조는 다음과 같은 이유를 근거로 작성하였다.

/       → Next.js
/api    → Spring Boot
/ws     → Spring Boot WebSocket
/ai     → FastAPI

• 사용자에게 서비스별 포트를 노출하지 않음
• HTTPS 처리를 한 곳에서 수행
• WebSocket Upgrade 헤더를 일관되게 처리
• Next.js·Spring Boot·FastAPI의 내부 포트를 숨김
• 서비스별 컨테이너 재시작 가능

Nginx가 중간에 있지만, V1 트래픽에서는 병목이 될 가능성이 낮다. 현재는 EC2 한 대에 애플리케이션 서버가 하나뿐이므로 Nginx의 역할은 로드밸런싱보다 Reverse Proxy을 하게 된다.

아키텍쳐구조도