신규 프로젝트 [0] : 초기 아키텍쳐 설계

이번에 이직을 하면서 신규 프로젝트의 0 -> 1 설계부터 초기 구현까지 혼자 맡게 되었다.

실제 내부 비즈니스 로직, 도메인 관련된 것은 제외하고 아키텍쳐만 서술한다.

 

우선 서버리스로 결정하게 되었다.

초기 스타트업이기에 무작정 EC2/c4a 인스턴스에 올리는건 여러가지 의미의 비용 부분에서 손해가 크다고 생각했다.

그래서 docker image로 배포가 가능한 GCP Cloud Run 서비스를 사용하기로 했다.

 

코드 레벨에서 특정 클라우드 런타임에 강하게 종속되는 구조보다는 컨테이너 기반 실행 환경을 유지하는 것이
향후 VM/GKE 마이그레이션 시 유리하다고 판단했다.

 

Cloud Run 환경에서 Redis를 사용할 수 없는 것은 아니지만, MVP 단계에서 VPC 구성 및 상시 인프라 운영 부담을 줄이기 위해
managed queue인 Cloud Tasks를 우선 채택했다.

 

현재 요구사항은 이벤트 스트리밍보다는 개별 Job 실행 제어 성격이 강하다.
따라서 Kafka 대신 Cloud Tasks를 채택하고, 이벤트 fan-out 필요 시 Pub/Sub를 추가하는 구조로 설계했다.

 

일단 MVP 완성을 하더라도 매우 니치한 도메인의 B2B 서비스인것을 감안하면 어느정도 기간동안은 EKS/GKS에 redis든 kafka든 노드 3~4개씩 띄워야 할 수준의 트래픽은 발생하지 않을거라고 생각하고 있다.

 

아래는 이 내용들을 좀 더 세부적으로 정리해서 GPT 초벌 돌려 개인 notion 정리용으로 만든 문서 일부이다.

 

---

1. 목적

다음 원칙을 기준으로 설계한다.

• Core Backend = System of Record (단일 진실)
• AI/리포트 처리 = 완전 비동기 Job
• 대용량 파일 = Object Storage (GCS)
• Core DB = 메타데이터만 저장
• 동기 AI 호출 = 금지 (MVP 범위 제외)

본 구조는 다음을 확보하기 위한 필수 설계 원칙이다.

• 장애 격리
• 확장성
• 운영 안정성

---

2. 전체 구조 개요

2.1 구성 요소

Frontend (Web / Mobile)

책임:

• Core API 호출
• 파일 업로드 (Signed URL 사용)
• Job 상태 조회 (Polling)

제약:

• AI/Worker 직접 호출 금지
• DB 직접 접근 금지

---

Core Backend (Cloud Run)

System of Record (SoT)

책임:

• 사용자/권한/테넌트 관리
• Job 생성 및 상태 관리
• 결과 메타데이터 저장
• Signed URL 발급 (업로드/다운로드)
• Worker 콜백 검증 및 반영
• 이외 도메인 관련 

원칙:

• Core만 DB를 수정할 수 있다
• 모든 상태 전이는 Core를 통해서만 반영한다

---

Worker (Cloud Run)

AI/리포트 처리 전용 실행 계층

책임:

• 결과 파일 업로드 (GCS)
• Core 콜백 호출 (결과 전달)
• 이외 도메인 관련

제약:

• DB 직접 수정 금지
• 사용자 권한 처리 금지
• 상태 전이 직접 처리 금지 (Core 콜백 통해 반영)

---

Queue (Cloud Tasks)

비동기 Job 트리거

책임:

• HTTP Task 기반 Worker 호출
• 재시도 처리
• 최소 1회 실행 보장 (at-least-once)

---

DB (Cloud SQL - PostgreSQL)

메타데이터 저장소

저장 대상:

• Job 상태/결과 요약
• 파일 경로(키)
• 버전/에러코드/타임스탬프

저장 금지:

• PDF 바이너리
• 원본

---

Storage (GCS)

대용량 파일 저장소

저장 대상:

• 문서 등

접근 원칙:

• Core가 발급한 Signed URL로만 접근 허용
• 클라이언트는 GCS 경로를 직접 조작할 수 없음