EC2 Docker Compose 기반 초기 배포 설계 - 100-hours-a-week/KTB4-11th-Cloud GitHub Wiki

1. 초기 서비스 규모 정의

V1 기준 서비스 특성 및 사용자 니즈 분석

V1 기능 확정: 위임률 100% 모의투자 에이전트 -> 위임률 100%이기에 사용자의 직접투자 과정X. 리포트를 통해 주식 매매 판단의 논리적 흐름을 보여주는게 서비스의 핵심 기능!

핵심 페르소나 : 국내주식 투자를 시작하려는 투자 경험이 없는 사회 초년생 -> 실제 돈을 넣기 전에 AI가 종목을 고르고 사고파는 과정을 관찰하고 싶은 20~30대 직장인

우리 서비스를 통해 얻고자 하는 경험

자신의 돈을 잃지 않고 AI가 투자하는 과정을 구경하고 이해하고 싶음

구체적으로 우리 서비스에서 사용자가 원하는 경험을 제공하는 기능은?

AI 매매 리포트 생성

유저 수 산정

방문자 수 가정

Ahrefs는 자체 크롤러를 통해 24시간 내내 전 세계 웹을 분석하고 방대한 검색 마케팅 데이터를 수집하는 빅데이터 기반 SEO 플랫폼

2025년 기준 Ahrefs 데이터를 바탕으로 한 국내 스타트업 웹사이트 오가닉 트래픽 지표는 다음과 같습니다.(자연 검색 유입)

  • 월 100명 ~ 300명대: 클라썸(약 100회), 되는시간(약 150회), 플로우(약 150회), 콜라보(약 150회), 레몬베이스(약 200회), 해피톡(약 300회)
  • 월 500명 ~ 800명대: 모두싸인(약 500회), 잔디(약 700회), 스티비(약 700회), 센드버드(약 800회)
  • 월 1,000명 ~ 3,000명대: 세일즈맵(약 1,000회), 나인하이어(약 1,600회), 스팬딧(약 1,600회), 릴레잇(약 1,800회), 주주(약 2,300회), 인블로그(약 2,800회), 그리팅(약 3,300회)

→ 1000명으로 결정한 이유: 우리서비스랑 유사도 높은 주식분석(주주), 재무재표 분석(스팬딧) 그다음으로 높은 Esg 경영(그리팅)에 대한 플랫폼 모두 월 1000-3000명 대에 해당하므로 (나머지는 우리 서비스와 유사도 낮음) 보수적으로 잡아서 방문자수 1200-1500명 가정.

별다른 마케팅 비용없이, 팀원들이 직접 잠재 사용자가 존재하는 채널에 접근하여 초기 사용자를 확보한다.

  • 재테크·주식 관련 카카오톡 오픈채팅
  • 투자·재테크 관련 온라인 커뮤니티
  • 학교·지인 네트워크
  • SNS
  • 개발·창업 커뮤니티 등

Unbounce가 41,000개 이상의 랜딩페이지와 약 4.64억 회의 방문을 분석한 결과, 전체 산업의 방문→전환율 중앙값은 6.6%, 교육 분야 랜딩페이지의 중앙값은 8.4%로 나타났다.

출처: Unbounce, 「2024 Conversion Benchmark Report」
https://unbounce.com/conversion-benchmark-report/

따라서 방문→가입 전환율을 8.4%로 가정할 경우, 방문자 수 1200-1500을 대입하면 100명의 가입자 수가 나온다.

팀의 첫 달 마케팅 목표: 월간 고유 방문자 1,200~1,500명
팀의 첫 달 MAU 목표: 100명

예상 활성 MAU: 23명

TouchClass가 국내 107개 기업의 35개월 운영 데이터를 분석한 결과, 비필수 교육 서비스의 등록 학습자 대비 MAU 비율은 다음과 같다.

구분 등록 학습자 대비 MAU
1분위(Q1) 9%
중앙값 23%
3분위(Q3) 52%

직접 비교 가능한 국내 AI 투자 학습 서비스의 공개 활성 사용자 자료가 없으므로, 유사한 성격의 비필수 학습 서비스 데이터를 참고한다. -> V1 기준으로 서비스는 학습 서비스의 특성을 가장 크게 띈다고 생각했기 때문

출처: TouchClass, 「기업 이러닝 참여율 통계 — LMS MAU 실태 107개사 35개월 실측」, 2026
https://www.touchclass.com/ko/lms-benchmark

V1의 예상값에는 일반적인 운영 수준을 나타내는 중앙값 23%를 적용한다.

$$ 가입자\ 100명 \times MAU\ 비율\ 23% = 예상\ Product\ MAU\ 23명 $$

V1 예상 Product MAU: 23명
상향 시나리오 Product MAU: 52명

유저 시나리오

활성 사용자 기준 시나리오 소개

활성 사용자 1명 당 우리 서비스를 이용하는 3가지 패턴이 있을 것이라고 예측함.

S1: 홈화면을 통해 자본의 변동 사항이 생겼는지 빠르게 확인하고 나가는 패턴
S1-2: 홈화면을 통해 자본의 변동 사항이 생긴 것을 확인하고 새 리포트를 보고 나가는 패턴
S3: 재테크 공부를 하기 위해 여러 리포트를 조회하고 오래 머무는 패턴

ID 시나리오 발생 조건 빈도 사용자 흐름 체류시간 REST 호출 WebSocket
S1 빠른 확인 일반 거래일 주 2회 홈→종료 10~30초 3회 1연결
S2 단일 리포트 확인 새 판단에 관심 발생 주 1회 홈→내역→리포트 1개 2~5분 약 5회 1연결
S3 일일 종합 확인 장 마감 후 학습 주 3회→ 재태크 공부 타이밍 홈→내역→당일 리포트 여러 개 30분 약 9회 1연결
  • S1/S2/S3 → 다 합치면 주 6회의 방문 횟수가 발생함. 근데 이게 다 장을 여는 평일에만 집중되니 평일에만 트래픽을 고려하면 될 듯. → 5일 기준 7회 발생 일 1-2회가 발생함.

Baseline RPS 산정

  1. S1 빠른 확인
    : 23(활성 MAU) X 주 2회 X 3요청 = 138 요청/주

  2. S2 단일 리포트 확인
    : 23(활성 MAU) X 주 1회 X 5요청 = 115 요청/주

  3. S3 일일 종합 확인
    : 23(활성 MAU) X 주 3회 x 9요청 = 621 요청/주

  4. 전체 반복 요청
    : 138 + 115 + 621 = 874요청/주

  • 거래일 5일 기준 : 874/5 = 174.8요청/일
  • 결론 -> 174.8/86.400초 => Baseline RPS≈0.00202

Baseline RPS는 거래일 하루 동안 발생하는 전체 요청을 하루의 초로 나눈 평균값으로 정의한다. 따라서 Baseline RPS는 약 0.002RPS로 정의한다.

Peak RPS을 미산정한 이유는,

  1. StockSpoon V1은 사용자가 지속적으로 요청을 발생시키는 실시간 거래 서비스가 아니라, 홈 화면과 AI 리포트를 필요할 때 조회하는 저빈도·읽기 중심 서비스이다.
  2. V1에는 대규모 동시 유입을 발생시키는 마케팅 이벤트, 푸시 알림, 실시간 주문 경쟁 기능이 없다.

이러한 서비스 특성을 가진 StockSpoon V1은 특정 시점에 모든 사용자가 동시에 요청을 보내는 상황을 고려하여 대비할 이유가 없다고 판단하여 산정하지 않았다.

2. 서버 구성 요소

CSP 선정

우리가 할거: VM 서버 2개 올리기

  • 사용자 입장: 상관 없음

  • 서비스 입장: 상관 없음

  • 개발자 입장:

    • 난이도 - 어떤 플랫폼을 쓰던 Ec2 하나 올리는건 어렵지 않음

  • 팀의 입장:

    • 초기 자금이 제한적이므로 가능한 무료로 올리고 싶다
    • VM 2대 자체는 크게 비용 차이가 나지 않는다

    ⇒ 그러니까 그냥 오래 무료로 올릴 수 있는 걸 사용하자

    ⇒ 무료 크래딧을 많이 주면서 무료로 장기간 사용할 수 있는 플랫폼 선택

    ⇒ 스타트업 크래딧은 고려하지 않음, 인증하고 V1을 올리면 오래 걸림 / 당장 올려야하는 상황일 때 가능한 프리티어/무료 요금제를 고려

  • 필요한 서버 사양(예상)

    서버 구성 예상 메모리 권장 사양
    App 서버 Nginx + FE + BE + PostgreSQL 약 2.5~3.3GB 2 vCPU / 4GB RAM / SSD 30~40GB
    AI 서버 Celery + Worker 2개 + LangGraph + LLM Client + pandas/numpy 등 약 1.15GB 이상 2 vCPU / 2GB 최소, 4GB 권장 / SSD 20GB

Azure

  • 무료 혜택: 일부 VM을 12개월 무료 제공 (B1s는 1 vCPU / 1GB RAM)

→ “원하는 사양”을 구성 불가능

OCI

  • 비용: 영구적 무료 서비스 제공
    • 현재 A1 무료 할당량은 총 2 OCPU / 12GB RAM
    • 그러나 현재 무료 VM 추가 생성을 시도했으나 Capacity 부족으로 생성하지 못함 - 한국 리전, 주변 도쿄 리전도
      • 한 사람당 무료 사용량이 정해져있는게 아니라 한국 리전 안에 compute 물리 자원 풀이 있고 나눠 쓰는 구조
        (**선착순**, Oracle 공식 문서에서도 Capacity 부족 시 Out of host capacity로 인스턴스 생성이 실패할 수 있음을 명시)

→ 애초에 “지금 당장” 구성 불가능

AWS

  • 비용: 최대 6개월 간 $200 (일반 신규 계정)
  • 필요한 사양: 구성 가능

GCP

  • 비용: 90일 간 $300 (일반 신규 계정)
  • 필요한 사양: 구성 가능

[결론]

지금 당장 구성 가능한 것: AWS, GCP

  • AWS, GCP 에서 app 서버는 24시간, ai 서버는 하루 7시간(09:00~16:00)만 실행한다고 가정
  • 단순히 크레딧 금액이 큰 CSP를 선택하는 것이 아니라, 실제 V1 서버 운영 패턴을 기준으로 월 예상 비용을 계산하여 무료로 운영 가능한 기간

배포 방식

V1은 초기 서비스이므로 기능 추가보다 버그 수정과 설정 변경으로 인한 재배포가 빈번할 것으로 예상한다.

  • 사용자 입장: 무관
  • 서비스 입장: 안정적인 실행 필요 → 이를 위해서는 장애 발생 시 빠른 복구
  • 클라우드 개발자 입장: 애플리케이션 관리를 쉽게 할 수 있어야한다

[고려한 배포 방식]

  1. 애플리케이션 직접 실행 방식
  2. Container 방식

[서비스 입장의 요구]

서비스 입장: 안정적인 실행 필요 → 이를 위해서는 장애 발생 시 빠른 복구

→ CI/CD 자동화나 롤백 자체는 애플리케이션을 직접 실행하는 방식과 Container 방식 모두 차이가 없으므로 두 방식 중 어떤 것을 사용하던 서비스 입장은 충족

[클라우드 개발자의 요구]

클라우드 개발자 입장: 애플리케이션 관리를 쉽게 할 수 있어야한다

→ 해당 요구 사항을 “통일된 배포 방식으로 충족할 수 있다.”로 충족

  • 우리 서비스의 구조
    • AI Application: FastAPI + LangGraph 기반 애플리케이션 4개
    • Frontend: React 애플리케이션 1개
    • Backend: Java 애플리케이션 1개
  • 시나리오
    • 명령어를 통한 실행:
      • 각 애플리케이션마다 필요한 runtime, 실행 방법 관리, 사용하는 Python / Node.js / Java의 버전과 의존성 관리 해야한다.
    • 이미지를 통한 실행:
      • 각 환경 구성이 이미지에 정의되어 있음, 모든 애플리케이션을 동일하게 container image로 container화 가능

컨테이너 실행 & 관리 도구

현재 상황:

EC 두 대에서 각각 약 4개의 Container를 실행한다.

  • AI EC2: AI 관련 Container 약 4개
  • Web EC2: Frontend, Backend, PostgreSQL, Nginx

각 입장에서 원하는 거:

  • 사용자 입장: 무관

  • 서비스 입장: 무관 (Container가 실행되기만 하면 됨)

  • 개발자 입장:

    컨테이너 관리를 간단하게 하고 싶다

    • 여러 컨테이너를 실행, 중단

    • 재시작, 로그 확인

      (모두 단일로 띄워서 장애 발생 가능성 존재→ 컨테이너에 문제 발생 시 원인 파악을 위해)

고려한 후보:

  1. containerd

    • 개발자가 원하는 편리한 관리 기능을 바로 제공하지 않고, 직접 개발자가 추가적인 설정이 필요하다

      → 우리가 원하는 관리 기능을 제공해주지 않음, 직접 설정해야함 → 탈락

  2. Podman

    • 기본적인 컨테이너 관리는 제공함

    • 여러 container를 compose 방식으로 관리할 경우에 추가적인 compose provider 필요 → 탈락

      (Podman는 자체 구현이 아니라 외부 provider를 호출하는 방식)

  3. docker engine

    • 기본적인 컨테이너 관리 제공

    • Docker Compose를 통해 여러 Container를 하나의 설정으로 함께 관리 가능

      → 우리가 필요한 관리 기능을 가장 단순하게 제공

3. 서버 구성

image

  1. AI 서버만 분리한 이유

    저희가 클라우드 플랫폼 서비스를 선정할 때의 기준은 “V1 서비스를 무료로 얼마나 오래 운영할 수 있는가?” 입니다.

    • App 서버는 24시간 내내 접속 가능해야하지만, AI 서버는 장 운영 시간에 맞춰 9-16시 정도만 운영 됩니다. → AI 를 딱 운영하는 시간 동안만 띄우게 되면 한 서버에 다 넣었을 때보다 가격 절감이 가능합니다.

      구성 인스턴스 실행시간 월 비용
      한 서버에 통합 t3a.large 2 vCPU / 8GB 730h $68.33
      분리 App: t3a.medium 2 vCPU / 4GB    
      AI: t3a.small 2 vCPU / 2GB App: 730h    
      AI: 210h $39.08    

      AWS Pricing Calculator가 한 달 평균 시간을 월 730시간을 기준으로 계산하여서 그대로 적용하였습니다.

    • AWS freetier 기간 내인 6개월 동안 띄우려는 목적인데 ai까지 한 번에 띄우면 200 크래딧 내에서 6개월 내내 띄울 수 없고, 3개월 정도만 띄울 수 있습니다.

    • 따라서 저희의 원래 목표인 “V1 서비스를 무료로 얼마나 오래 운영할 수 있는가?” 를 달성하기 위해 분리하는 구조를 생각하였습니다.

  2. DB를 서버 내에 띄운 이유

    RDB가 제공하는 기능:

    • 자동 백업 및 특정 시점 복구(PITR)
    • DB 패치 및 유지보수 관리
    • 모니터링
    • 스토리지 확장
    • Multi-AZ 기반 고가용성/장애 대응

    → V1에서 DB 유실 시 데이터 복구를 위한 백업 하나입니다.

    → 이건 AWS의 EBS Snapshot 을 통해서 구현 가능하므로 굳이 RDB를 사용할 이유가 없습니다.

    • EBS Snapshot으로 볼륨의 특정 시점 백업 생성 & 나중에 스냅샷을 통해 복구 진행 가능
    • App EC2의 EBS Volume을 EBS Snapshot으로 백업하고, Amazon Data Lifecycle Manager를 이용해 Snapshot 생성·보존·삭제를 자동화하는 방식

  3. private subnet 을 고려하지 않은 이유

    • 현재 AI 서버, APP 서버는 실시간으로 외부 API 주가 데이터를 받아오기 위해 인터넷에 접근해야한다
    • V1에서 저장하는 데이터
      • 사용자 식별 - oauth 토큰 정도
      • 모의투자 계좌 및 거래 데이터
      • AI 매매 결과 및 리포트
    • 개인 정보/실제 금융 정보도 존재하지 않고, 외부로 통신할 때마다 비용이 나가야하는걸 감수할만큼 private 에 넣을 이유가 없음
⚠️ **GitHub.com Fallback** ⚠️