1단계 초기 서비스 및 인프라 설계

모여타 V1이 해결할 사용자 문제와 초기 시장을 정하고, 팀 규모와 예산 안에서 서비스를 빠르게 검증할 배포 구조를 선택한다. 이 문서는 서비스 가정에서 인프라 구성까지의 판단을 하나의 흐름으로 정리한다. 각 주제의 수치와 세부 기준은 문단에 연결된 원문에서 확인할 수 있다.

목차

• 1단계 초기 서비스 및 인프라 설계
  • 1. 팀과 운영 제약
  • 2. 해결할 문제와 V1의 검증 목표
    • 해결하고자 하는 문제 상황
    • 제공하려는 가치
    • V1의 운영 목표
  • 3. 초기 시장과 사용자 행동
    • 서비스 시장 규모 가정
  • 4. 초기 트래픽 가정
  • 5. V1 서버 및 컨테이너 구성
  • 6. 아키텍처 선택과 운영 한계

1. 팀과 운영 제약

V1은 인프라 운영 1명, 백엔드 2명, 프론트엔드 1명, AI 2명으로 구성된 6명 팀이 개발한다고 가정한다. 인프라 담당자가 클라우드, 네트워크, 배포, 모니터링, 비용 및 백업을 함께 관리하므로 운영 컴포넌트가 늘어날수록 개발 속도와 장애 대응 여력이 줄어든다. 3개월 인프라 예산은 90만 원으로 두고, V1에서는 확장성을 미리 확보하기보다 핵심 기능을 빠르게 출시해 사용자 피드백을 얻는 데 우선순위를 둔다. 상세한 인력·기간·운영 제약은 팀 운영 구조와 실행 제약 가정에 정리되어 있다.

개발 기간에 로컬 환경만으로 작업하면 API 명세, 데이터베이스 스키마, 환경 변수와 WebSocket 설정이 서로 달라질 수 있다. 이를 조기에 발견하기 위해 Dev는 기능 단위로 자주 통합하고 배포하며, Prod는 검증된 변경을 정기 배포하는 방향을 잡는다.

2. 해결할 문제와 V1의 검증 목표

해결하고자 하는 문제 상황

출퇴근·통학 중 교통 혼잡이나 지연이 생기거나 심야에 대중교통을 이용하기 어려울 때, 사용자는 같은 시간과 방향으로 이동할 사람을 찾기 어렵고 택시 비용도 부담한다. 기존 게시판과 메신저는 팟을 발견한 뒤 좌석과 참여 상태를 확인하고, 이동을 조율하고, 비용을 정산하는 과정을 한 흐름으로 이어 주지 못한다.

제공하려는 가치

모여타는 위치와 이동 정보를 기준으로 사용자를 연결하고 팟 생성·참여·채팅·정산을 한 서비스에서 제공하는 것을 핵심 가치로 삼는다. 문제 정의와 사용자 가설은 서비스 문제와 제공 가치 가정을 참고한다.

V1의 운영 목표

기능 수를 늘리는 것이 아니라 사용자가 자신의 조건에 맞는 팟을 발견해 실제 동승과 정산까지 완료하는지를 확인한다.

위치 기반 팟 조회와 생성, 참여 요청·승인, 좌석 관리, 팟 채팅, 기본 정산, 회원가입·로그인을 우선 구현한다. 참여 요청이 동시에 들어와도 정원이 초과되지 않는지, 재접속 뒤 팟과 채팅 정보가 유지되는지도 핵심 검증 항목이다. 실시간 혼잡도, 이미지 기반 정산 자동화, GPU 모델 서빙과 전국 확장은 V1 범위에서 제외하고 후속 단계로 둔다.

3. 초기 시장과 사용자 행동

초기 시장은 판교 테크노밸리로 좁힌다. 근로자와 기업이 밀집하고 출퇴근 목적지와 시간대가 비교적 뚜렷해, 제한된 사용자 규모 안에서도 같은 지역·시간·방향의 사용자를 모아 매칭 가능성을 확인하기 적합하다는 판단이다.

서비스 시장 규모 가정

구분	규모	의미
TAM	83,465명	판교 테크노밸리 전체 근로자
SAM	약 54,169명	서울 및 경기 남부에서 통근하는 후보 사용자
일일 이동 수요 참고값	약 5,000명	서울에서 판교 제2테크노밸리로 이동하는 대중교통 이용 수요
SOM 상한 시나리오	약 16,630명	SAM의 30.7%가 서비스에 긍정적이라고 가정한 값
초기 도달 시나리오	약 8,315명	SOM 상한의 50%에 도달한다고 가정한 값

서울 거주자 27.3%와 경기 남부 거주자 37.6%를 합산하여 광역 통근 후보군을 약 64.9%로 계산한다. 판교 테크노밸리 근로자 83,465명에 64.9%를 적용하면 다음과 같다.

83,465 × 64.9% ≈ 54,169명

자세한 시장 규모 및 MAU·DAU 가정의 산정 기준은 초기 타깃 시장과 시장 검증 가정에 정리되어 있다.

주요 사용 상황은 출퇴근·통학 중 교통 장애와 심야·교대 근무 후 이동이다. 사용자는 출발지, 목적지, 시간, 현재 인원과 남은 좌석을 보고 팟을 고른 다음 참여를 요청한다. 모집자는 참여 상태를 확인하고, 참여자들은 채팅으로 만날 위치와 시간을 맞춘다. 이동 후에는 참여자와 비용을 확인해 정산을 마친다. 이 과정에서 조회 요청은 반복적으로 발생하고, 참여·좌석 변경·정산은 정합성이 중요한 쓰기 요청이며, 채팅은 장시간 연결과 메시지 이력을 요구한다.

4. 초기 트래픽 가정

초기 HTTP 부하는 위 사용자 여정의 행동 횟수와 피크 시간대 집중도를 바탕으로 산정한다. 팟 탐색과 상세 확인은 조회 트래픽으로, 팟 생성·참여·정산은 거래성 쓰기 트래픽으로, 채팅은 WebSocket 연결과 메시지 트래픽으로 나눈다. 시나리오별 행동 횟수와 초기 HTTP RPS 계산은 사용자 상황과 행동 기반 RPS 가정을 참고한다.

구분	예상 피크 RPS
커뮤니티·정보 조회	약 1.25 RPS
매칭·정산 쓰기	약 0.27 RPS
합계	약 1.52 RPS

5. V1 서버 및 컨테이너 구성

EC2 사양과 운영 방식은 Docker Compose 운영에 정리되어 있다.

6. 아키텍처 선택과 운영 한계

V1은 단일 EC2와 Docker Compose 구성을 채택한다. 팀 규모와 인프라 예산, 초기 예상 트래픽 및 빠른 검증이라는 목표를 고려하면 ECS·EKS·ALB·RDS·Redis·Multi-AZ·Auto Scaling을 처음부터 운영하는 것보다 관리 대상이 적은 구성이 적합하다고 판단했다. 최종 구성과 선택 근거는 V1 아키텍처 설계에 설명되어 있다. 위의 V1 설계 구조는 아래와 같은 한계 지점을 가질 수 있다.

1. EC2, 운영체제, Docker 호스트 또는 디스크에 장애가 나면 여러 서비스가 함께 중단될 수 있음
2. 단일 노드만으로 고가용성이나 무중단 배포를 보장할 수 없음
3. 컨테이너 재시작만으로 복구 절차가 끝나는 것이 아닌 로그와 상태를 관측하며 이미지 버전 관리, 데이터 백업 및 새 환경 복구 절차를 준비가 필요하기 때문에 자동화된 운영이 아님