001 팀 운영 구조와 실행 제약 가정 - 100-hours-a-week/KTB4-3rd-CLOUD GitHub Wiki

이 문서는 모여타 서비스를 개발하는 팀의 운영 구조와 실행 제약, 개발·배포 방식, V1에서 운영 가능한 인프라 복잡도와 비용을 가정하는 것을 목적으로 한다.

팀 인원·역할·책임 범위

서비스 개발 초기 6명 규모의 스타트업을 가정한다.

구분 인원 주요 책임
인프라 운영 1명 CSP, 네트워크, 배포, 모니터링, 비용, 백업
백엔드 2명 API, 데이터베이스, 매칭, 정산, WebSocket
프론트엔드 1명 웹 화면, 지도, 커뮤니티, 채팅 UI
AI 2명 외부 AI API 연동, AI 품질 검증, V3 모델 서빙

인프라 예산은 CSP와 관계없이 3개월에 90만 원으로 가정한다. AI API 및 모델 운영 예산은 별도로 3개월에 36만 원으로 가정한다. 팀의 공동 운영 목표는 다음과 같다.

  • 핵심 서비스 기능을 우선 구현한다.
  • 짧은 주기로 배포하여 실제 사용자 피드백을 확보한다.
  • 개발·테스트·배포 과정에서 발생하는 운영 부담을 1명의 인프라 담당자가 감당할 수 있는 수준으로 제한한다.
  • V1에서는 확장성보다 빠른 검증과 장애 발생 시 신속한 복구를 우선한다.

V1·V2·V3 개발 및 검증 기간

기간 단계 주요 내용
09/14 ~ 09/25 V1 개발 핵심 기능 개발
09/28 ~ 10/02 V1 테스트 및 1차 배포 통합 테스트, QA, 1차 운영 배포
10/05 ~ 10/23 V2 개발 및 2차 배포 혼잡도 및 AI 기능 확장
10/26 ~ 11/13 V3 개발 및 3차 배포 GPU 기반 AI 모델 서빙 검증

V1에서는 모여타의 핵심 가치가 되는 서비스를 제공하고, AI 기능은 다음과 같이 단계적으로 도입한다.

  • V1: AI 서비스 제외
  • V2: 외부 LLM API를 사용한 혼잡도 및 이미지 기반 정산 기능
  • V3: GPU 기반 AI 모델 서빙 도입 및 성능 검증

V1 개발 범위

V1 기간 구현해야할 핵심 기능은 다음과 같다.

  • 노선·지도 위치 기반 커뮤니티
  • 택시팟 생성 및 매칭
  • 동승자 채팅
  • 기본 정산 기능
  • 회원가입 및 로그인
  • 홈 화면 및 지도 화면

위에서 정산은 기본적인 참여자가 수동으로 금액을 입력하고 결제한 내역과 송금한 내역을 채팅방 안에서 관리해주는 기능을 먼저 구현한다. 이후 AI를 활용한 미터기 이미지에서 금액을 추출해 정산의 자동화를 추가하는 것은 V2 때부터 제공한다.

V1 개발 기간 주요 개발 인원과 작업 공간

  • Github Actions

주요 PR을 생성하고 통합하는 인원은 백엔드 2명과 프론트엔드 1명이다. AI 팀은 V1에서 직접적인 AI 서비스 서빙을 담당하지 않으며, V2 이후의 외부 API 연동 및 모델 검증을 준비한다.

개발자들이 각자의 로컬 환경에서 병렬 작업을 진행하면 다음과 같은 차이가 발생할 수 있다.

  • 프론트엔드와 백엔드의 API 명세 차이
  • 요청·응답 필드 및 데이터 타입 차이
  • 데이터베이스 스키마 버전 차이
  • 환경 변수와 외부 API 설정 차이
  • 로컬 실행 순서 및 의존 서비스 차이
  • WebSocket 연결 주소 및 인증 방식 차이

이러한 차이는 단순한 Git diff가 아니라 애플리케이션 간 계약과 실행 환경의 차이로 이어진다. 한 팀원의 로컬 환경에서는 정상 동작하더라도 실제 통합 환경에서는 요청이 실패하거나 화면과 API가 정상적으로 연결되지 않을 수 있다.

V1은 핵심 기능을 짧은 기간에 개발해야 하므로, 기능을 각자의 브랜치에 오래 보관한 뒤 한 번에 통합하는 방식은 적합하지 않다. 작은 기능 단위로 자주 테스트하고 Dev 환경에 배포하여 API, 화면, 데이터베이스 간 차이를 빠르게 발견할 수 있도록 공동의 테스트 환경을

V1의 배포 빈도

현재 팀의 배포 환경과 테스트 환경이 분리되어 있기 때문에 배포 빈도를

  • Prod: 주 1회 계획 배포
  • Dev: 기능 단위로 수시 배포 및 테스트

주 1회 정기 배포 일정

배포일 릴리즈 배포 범위 배포 목표
2026.09.18 R1.1 기반·탐색 PB-09 회원가입/로그인, PB-10 프로필, PB-01 출발지·목적지·시간 검색 서비스 진입 및 검색 기능 확보
2026.09.25 R1.2 추천 PB-02 조건 기반 동승자 추천 검색 조건에 맞는 동승자 탐색
2026.09.28 R1.3 매칭·소통 PB-03 매칭 신청·확정, PB-04 채팅 동승자 매칭부터 채팅까지 연결
2026.10.02 R1.4 MVP 완료 PB-06 AI 정산 인증, PB-07 동승 종료, PB-08 후기·별점 가입부터 동승 완료·평가까지 핵심 사용자 여정 완성
2026.10.09 R2.1 AI 만남 지원 PB-05 AI 이미지 인식 매칭된 동승자 식별 기능 추가
2026.10.16 R2.2 AI 정산 고도화 PB-06 오류·재시도·예외 처리 보완 정산 인증 성공률과 안정성 개선
2026.10.23 R2.3 통합 안정화 PB-05~08 통합 테스트 및 V1 회귀 테스트 AI·매칭·정산 기능의 연동 검증
2026.10.30 R3.1 운영 기능 전체 기능 오류 수정, 알림·상태 변경 보완 사용자 상태 변화와 운영 안정성 개선
2026.11.06 R3.2 최종 안정화 전체 핵심 사용자 여정, 예외·권한·네트워크 오류 점검 최종 QA 전 결함 제거
2026.11.13 R4 최종 배포 전체 기능 E2E·성능·보안·롤백 검증 프로덕션 최종 배포

V1에서 운영 가능한 시스템 복잡도

팀 규모가 6명이고 인프라 운영자가 1명이므로 운영 컴포넌트가 증가할수록 배포, 모니터링, 장애 대응, 비용 관리의 부담도 증가한다. 따라서 V1에서는 현재 예상 규모와 핵심 목표를 고려하여 다음 구성요소를 기본적으로 사용하지 않는 것을 가정하고 설계할 예정이다.

  • ECS
  • EKS
  • ALB
  • RDS
  • Redis
  • Multi-AZ
  • Auto Scaling

따라서 V1은 단일 EC2와 Docker Compose를 기반으로 구성하여, 외부 요청은 단일 진입점인 Nginx를 통해 전달한다. 애플리케이션 컨테이너와 데이터베이스 컨테이너를 분리해 리소스를 독립적으로 할당한다. 다만 단일 EC2 구성은 고가용성 구성이 아니므로 다음 장애에 취약한 것을 인지하고 설계할 예정이다. 이를 보완하기 위한 재시작 정책, 관측 가시성, 이미지 버전 관리에 대해 추가로 결정한다.

  • EC2 장애
  • 호스트 디스크 장애
  • Docker 또는 운영체제 장애
  • 데이터베이스 컨테이너 장애
⚠️ **GitHub.com Fallback** ⚠️