BYOC 배포
BYOC(Bring Your Own Cloud)는 Fascia의 배포 모델입니다. 모든 런타임 인프라가 고객의 자체 GCP 프로젝트에 존재합니다. Fascia는 고객 비즈니스 데이터를 저장하거나 처리하지 않으며, 실행 아티팩트를 생 성하고 배포하기만 합니다.
BYOC의 의미
전통적인 SaaS 모델에서는 벤더가 애플리케이션 서버, 데이터베이스, 고객 데이터 모두를 벤더의 인프라에서 호스팅합니다. Fascia는 다른 접근 방식을 취합니다.
Fascia는 책임을 두 개의 플레인으로 분리합니다:
- Control Plane (Fascia 호스팅): 스펙 설계, 검증, 리스크 분석, 배포 오케스트레이션을 담당합니다. 스펙, 메타데이터, 배포 기록만 저장합니다.
- Data Plane (고객 GCP): 모든 실행 로직을 수행하고 모든 비즈니스 데이터를 저장합니다. 고객의 GCP 계정에서 소유하고 비용을 지불합니다.
이를 통해 고객은 자신의 데이터, 인프라, 비용에 대한 완전한 소유권과 제어권을 유지합니다. Fascia는 데이터 처리 레이어가 아닌, 설계 및 배포 레이어로 기능합니다.
실행 위치
고객 GCP 프로젝트
모든 런타임 컴포넌트는 고객의 자체 GCP 프로젝트 내에 프로비저닝됩니다:
| 리소스 | 서비스 | 설명 |
|---|---|---|
| Executor | Cloud Run | Tool Flow 그래프를 실행하는 Go 바이너리입니다. 고객 스펙에서 컴파일된 SpecBundle을 수신합니다. 유휴 시 0으로 스케일 다운되며, 약 50ms 내에 시작합니다. |
| 데이터베이스 | Cloud SQL (PostgreSQL) | 워크스페이스당 하나의 PostgreSQL 인스턴스입니다. 모든 비즈니스 Entity, 관계, 감사 로그를 저장합니다. 백업이 활성화된 상태로 자동 프로비저닝됩니다. |
| 스케줄러 | Cloud Scheduler | 설정된 스케줄에 따라 크론 트리거 Tool을 호출합니다. 각 크론 Tool에 전용 스케줄러 작업이 할당됩니다. |
| 시크릿 | Secret Manager | 모든 민감 값을 저장합니다: JWT 서명 키, OAuth 클라이언트 시크릿, API 키, 데이터베이스 자격 증명. 배포 중 Terraform을 통해 생성 및 관리됩니다. |
| 메시징 | Pub/Sub (선택 사항) | 큐 트리거 Tool과 Tool 간 비동기 이벤트 기반 워크플로를 활성화합니다. 큐 트리거가 사용될 때만 프로비저닝됩니다. |
Fascia 호스팅 (Control Plane)
| 컴포넌트 | 설명 |
|---|---|
| Chat Studio | 대화형 설계 인터페이스입니다. LLM 기반 스펙 생성을 제공합니다. |
| Flow Studio | 시각적 Flow 그래프 편집기입니다. |
| Spec Registry | Entity, Tool, Policy 스펙의 버전 관리 저장소입니다. |
| Safety Agent | AI 기반 스펙 분석 및 리스크 감지를 수행합니다. |
| Risk Engine | Flow 그래프 평가 및 Risk 분류를 수행합니다. |
| Deploy Pipeline | 고객 GCP 프로비저닝을 위한 Terraform 오케스트레이션입니다. |
데이터 주권
Fascia는 엄격한 데이터 격리를 적용합니다:
- 고객 비즈니스 데이터는 고객의 GCP 프로젝트를 벗어나지 않습니다. 모든 Entity 레코드, 관계, 상태 전이, 감사 로그는 고객의 Cloud SQL 인스턴스에 저장됩니다.
- Fascia는 스펙과 메타데이터만 저장합니다. Spec Registry에는 구조화된 정의(Entity 스펙, Tool 스펙, Policy 스펙)와 배포 기록이 포함됩니다. 고객 비즈니스 데이터는 포함되지 않습니다.
- 각 워크스페이스는 자체 데이터베이스를 가집니다. 워크스페이스 간 공유 데이터베이스가 없습니다. 각 워크스페이스는 전용 Cloud SQL 인스턴스를 가지며, 완전한 격리를 제공합니다.
- 시크릿은 고객의 프로젝트에 보관됩니다. JWT 서명 키, OAuth 클라이언트 시크릿, API 키는 고객의 GCP Secret Manager에 저장됩니다. Fascia는 초기 프로비저닝 후 이러한 시크릿에 접근하지 않습니다.
IAM과 접근 권한
Fascia는 최소 권한 원칙에 따라 고객의 GCP 프로젝트에 대한 최소한의 IAM 접근만 필요합니다:
| 권한 | 목적 | 사용 시점 |
|---|---|---|
| Cloud Run Admin | Executor 서비스 배포 및 업데이트 | 배포 시에만 |
| Cloud SQL Admin | 데이터베이스 인스턴스 프로비저닝 및 마이그레이션 실행 | 초기 설정 및 스키마 변경 시 |
| Cloud Scheduler Admin | 크론 작업 생성 및 업데이트 | 크론 트리거 Tool 배포 시 |
| Secret Manager Admin | 초기 프로비저닝을 위한 시크릿 생성 | 초기 설정 시에만 |
| Service Account Creator | 런타임 서비스 계정 생성 | 초기 설정 시에만 |
배포 후 Executor는 자체 Cloud SQL 인스턴스와 Secret Manager 항목에 대한 접근만 가능한 전용 GCP 서비스 계정으로 실행됩니다. 고객이 독립적으로 인프라 업데이트를 관리하는 경우, 프로비저닝 후 Fascia의 배포 서비스 계정을 해지할 수 있습니다.
배포 흐름
사용자가 Control Plane에서 Tool(또는 Tool 집합)을 배포하면 다음 단계가 실행됩니다:
1. 스 펙 컴파일
└── 스펙이 SpecBundle (자체 완결형 실행 아티팩트)로 컴파일됩니다
2. Terraform Plan
└── 인프라 변경 사항을 계산합니다 (새 Cloud Run 리비전, DB 마이그레이션, 스케줄러 작업)
3. Terraform Apply
└── 고객의 GCP 프로젝트에 변경 사항을 적용합니다
4. Cloud Run 배포
└── 새 SpecBundle이 Cloud Run 리비전으로 배포됩니다
5. 상태 확인
└── Fascia가 새 배포의 정상 동작을 확인합니다 (HTTP 상태 확인 엔드포인트)
6. 기록
└── 배포 기록이 Spec Registry에 기록됩니다 (타임스탬프, 버전, 상태)
어떤 단계에서든 실패하면 이전의 정상 작동 상태로 롤백됩니다. Spec Registry는 감사 목적으로 실패를 기록합니다.
워크스페이스당 하나의 데이터베이스
각 워크스페이스는 자체 Cloud SQL PostgreSQL 인스턴스를 받습니다. 이 설계는 다음을 제공합니다:
- 완전한 격리 -- 워크스페이스 간 데이터 유출 위험이 없습니다.
- 독립적 확장 -- 각 데이터베이스는 자체 워크로드에 맞게 확장됩니다.
- 독립적 백업 -- 백업 스케줄과 보존 기간이 워크스페이스별로 설정됩니다.
- 깔끔한 정리 -- 워크스페이스를 삭제하면 전체 데이터베이스 인스턴스가 제거됩니다.
데이터베이스 스키마는 고객의 Entity 스펙에서 자동으로 도출됩니다. Entity가 생성되거나 수정되면, Fascia는 배포 과정에서 해당하는 SQL 마이그레이션을 생성하고 적용합니다.
클라우드 제공자 지원
Fascia는 현재 GCP만 지원합니다. 이 결정은 배포 복잡성을 줄이고 GCP 관리형 서비스(Cloud Run, Cloud SQL, Cloud Scheduler, Secret Manager)와의 깊은 통합을 유지하기 위해 이루어졌습니다.
멀티클라우드 지원(AWS, Azure)은 향후 릴리스에서 계획되어 있습니다. 인프라 레이어는 이러한 확장을 용이하게 하기 위한 추상화 경계로 설계되었지만, 현재 로드맵에서는 명시적으로 제외되어 있습니다.
전체 근거에 대해서는 BYOC with GCP에 관한 아키텍처 결정 기록을 참조하십시오.
비용 모델
모든 런타임 인프라가 고객의 GCP 프로젝트에 있으므로, 고객은 자신의 사용량에 대해 GCP에 직접 비용을 지불합니다:
| 리소스 | 과금 모델 |
|---|---|
| Cloud Run | 요청당 + CPU/메모리 시간 (유휴 시 0으로 스케일) |
| Cloud SQL | 시간당 인스턴스 비용 + 스토리지 |
| Cloud Scheduler | 작업 호출당 |
| Secret Manager | 시크릿 버전당 + 접근 작업 |
| Pub/Sub | 메시지당 (사용 시) |
Fascia는 Control Plane 사용 (스펙 저장, 설계 도구, 배포 오케스트레이션)에 대해 별도로 과금합니다. 고객의 GCP 비용은 Fascia의 요금과 독립적입니다.
관련 문서
- 시스템 아키텍처 -- 전체 Two-Plane 아키텍처와 기술 스택을 설명합니다
- Risk 분류 규칙 -- 배포 전 Risk Engine의 Tool 안전성 평가 방법을 설명합니다
- Tool 스펙 스키마 -- 트리거 유형과 Flow 그래프를 포함한 Tool 정의를 설명합니다