글
GCP STUDY=
1. 온디맨드 셀프 서비스 (On-Demand Self-Service)
2. 광범위한 네트워크 액세스 (Broad Network Access)
3. 자원 풀링 (Resource Pooling)
4. 신속한 탄력성 (Rapid Elasticity)
5. 측정 가능한 서비스 (Measured Service)
클라우드 컴퓨팅은 유연한 자원 활용과 광범위한 접근성 등을 특징으로, 사용자가 언제 어디서나 필요한 만큼 자원을 활용할 수 있는 환경을 제공합니다. 주요 클라우드 서비스 업체(AWS, GCP, Azure 등)가 공통적으로 제공하는 클라우드 컴퓨팅의 다섯 가지 핵심 기술적 특성은 다음과 같습니다. 이 특성들은 클라우드 컴퓨팅의 표준 정의(NIST 등)에도 명시되어 있으며, 클라우드의 장점을 이해하는 데 중요합니다. 아래에서는 각 특성별로 용어 정의, 기술적 배경, 그리고 실제 예시를 초보자도 이해하기 쉽도록 설명합니다.
1. 온디맨드 셀프 서비스 (On-Demand Self-Service)
정의: 온디맨드 셀프 서비스란 사용자가 언제든지 원하는 시점에, 별도의 관리자 개입 없이 스스로 필요한 컴퓨팅 자원을 즉시 할당받아 사용할 수 있음을 의미합니다. 다시 말해, 클라우드에서는 서버나 스토리지 같은 자원을 요청하면 바로바로 제공되어 “필요할 때 바로 쓰는” 서비스가 가능합니다.
기술 배경: 이러한 self-service가 가능한 이유는 클라우드 공급자가 자동화된 프로비저닝 시스템을 갖추고 있기 때문입니다. 사용자는 웹 포털이나 API를 통해 스스로 자원을 생성/관리하며, 이 과정에서 사람의 수동 승인 없이 소프트웨어가 자동으로 자원 할당을 수행합니다. 예를 들어, 가상화 기술로 미리 준비된 서버 풀(pool)에서 요청이 들어오면 소프트웨어가 즉시 빈 서버를 할당해 주는 식입니다.
예시: AWS 콘솔에서 사용자가 새 가상 서버(EC2 인스턴스)를 몇 번의 클릭만으로 생성할 수 있는 것이 온디맨드 셀프 서비스의 대표적 예입니다. 새벽 3시라도 개발자가 테스트용 서버가 필요하면, 클라우드 웹콘솔에 접속해 수분 내로 원하는 사양의 서버를 만들고 바로 사용할 수 있습니다. 실제로 AWS 클라우드에서는 몇 초 만에 필요한 사양의 VM을 띄울 수 있고, 사용한 만큼만 비용을 내면 됩니다. 별도로 업체 직원을 통하지 않고도 셀프 서비스 포털에서 손쉽게 인스턴스 생성, 저장공간 증설 등을 할 수 있다는 점이 클라우드의 큰 장점입니다.
2. 광범위한 네트워크 액세스 (Broad Network Access)
정의: 광범위한 네트워크 접근성은 클라우드 서비스가 인터넷 등을 통해 어디서나 접근 가능하고, PC, 노트북, 스마트폰 등 다양한 단말기에서도 이용될 수 있음을 뜻합니다. 즉 네트워크만 연결되어 있다면 장소나 기기에 구애받지 않고 클라우드 자원에 접속할 수 있습니다.
기술 배경: 이러한 특성은 클라우드 서비스가 표준화된 인터넷 프로토콜과 웹 기술을 사용해 제공되기 때문에 가능합니다. 예를 들어 웹 브라우저(크롬, 사파리 등)만 있으면 동작하는 씬 클라이언트 방식이나, 전용 앱이 설치된 두터운 클라이언트 모두를 통해 서비스에 접근하도록 클라우드가 설계되어 있습니다. 또한 클라우드 사업자는 전 세계 데이터센터와 고속 네트워크 인프라를 구축하여, 사용자들이 **낮은 지연(latency)**으로 서비스를 이용할 수 있게 합니다. 공용 클라우드의 경우 인터넷으로 접속하고, 프라이빗 클라우드의 경우 사내망(LAN)으로도 접속하는 등 여러 네트워크 형태를 지원합니다.
예시: 우리가 일상에서 사용하는 구글 드라이브, 마이크로소프트 365 같은 클라우드 앱은 집, 회사, 혹은 이동 중 스마트폰으로도 동일하게 접근 가능합니다. 예를 들어, 휴대폰으로 찍은 사진을 클라우드 스토리지에 업로드해 두면 나중에 노트북이나 태블릿으로도 인터넷만 연결하면 바로 볼 수 있습니다. 개발자 입장에서도 AWS나 Azure의 관리 콘솔에 웹으로 접속해 서버 상태를 모니터링하거나 설정을 변경하는 등, 장소 제약 없이 클라우드를 활용할 수 있습니다.
3. 자원 풀링 (Resource Pooling)
정의: 자원 풀링이란 클라우드 공급자가 보유한 물리/가상 자원을 공동 자원 풀 형태로 관리하여 여러 사용자에게 필요에 따라 할당하는 모델을 말합니다. 다수의 고객이 하나의 큰 자원 풀을 공유하지만 각 사용자는 자신에게 할당된 자원만 쓰며, 사용이 끝난 자원은 다시 풀로 반환되어 재분배됩니다. 이때 사용자들은 자원이 어디에 있는지, 얼마나 있는지 등의 세부 사항을 알 필요 없이 추상화된 형태로 서비스를 받습니다.
기술 배경: 자원 풀링의 핵심 기술 배경은 **가상화(Virtualization)**와 **멀티테넌시(Multi-tenancy)**입니다. 가상화 기술을 통해 한 대의 물리 서버를 여러 대의 가상 서버로 나누고, 이를 여러 사용자에게 각각 할당함으로써 한 물리 자원을 여러 사람이 동시에 활용할 수 있습니다. 멀티테넌트 아키텍처란 하나의 시스템 인스턴스에 다수의 테넌트(고객)가 입주하듯 사용하는 구조로서, 각 사용자 데이터는 논리적으로 분리되어 서로 간 간섭 없이 보안이 유지됩니다. 클라우드 공급자는 이러한 가상화 및 멀티테넌트 기술로 대규모 인프라를 효율적으로 공유하여 자원 활용도를 극대화합니다.
예시: AWS EC2를 예로 들면, 여러 고객의 가상 서버들이 단일 물리 서버를 공유하도록 운영됩니다. 사용자 A의 EC2 인스턴스와 사용자 B의 인스턴스가 동일한 물리 호스트에서 동작하더라도, 가상화로 철저히 격리되어 서로 영향을 주지 않죠. SaaS 환경에서의 자원 풀링 예로는 Gmail이나 Salesforce 같은 서비스가 있는데, 수많은 이용자가 같은 애플리케이션과 데이터베이스 플랫폼을 공유하지만 각 계정의 데이터는 분리되어 저장됩니다. 이러한 자원 풀링 덕분에 클라우드 업체는 유휴 자원을 줄이고 필요한 곳에 효율적으로 배분할 수 있으며, 사용자는 저렴한 비용으로 고성능 인프라를 나눠 쓰는 혜택을 얻습니다.
4. 신속한 탄력성 (Rapid Elasticity)
정의: 신속한 탄력성은 클라우드 자원을 짧은 시간 내에 신속하게 확장하거나 축소할 수 있는 능력을 뜻합니다. 즉 사용자의 수요 변화에 맞춰 필요한 만큼 자원을 늘리거나 줄일 수 있고, 겉보기에는 자원이 무한정 제공되는 것처럼 느껴질 정도로 유연한 확장이 가능합니다. 이러한 확장/축소 작업은 자동화된 경우 몇 분 내지 즉각적으로 이루어집니다.
기술 배경: 클라우드에서는 **오토스케일링(Auto-scaling)**과 같은 메커니즘을 통해 탄력성을 구현합니다. 모니터링 시스템이 서버 부하나 네트워크 트래픽 증가를 감지하면, 미리 정해진 규칙에 따라 가상 서버를 자동으로 추가 배치하거나 줄이는 식입니다. 컨테이너 오케스트레이션(Kubernetes 등)도 수 초~수 분 내에 새로운 컨테이너 인스턴스를 띄우거나 제거하여 탄력적으로 자원을 운용합니다. 이 모든 과정은 사용자가 일일이 개입하지 않아도 자동화 프로그램이 수행하며, 클라우드 공급자의 대규모 자원 풀 덕분에 확장할 자원이 항상 준비되어 있습니다. 결과적으로 사용자는 초기에는 소량의 자원만 쓰다가도, 트래픽 폭주 등의 상황에서 즉시 서버 수를 늘려 대응하고 이후 다시 줄이는 유연한 스케일 운영이 가능합니다.
예시: 예를 들어 전자상거래 사이트는 평소보다 이용자가 폭주하는 할인 행사 기간에 클라우드 서버 인스턴스를 자동으로 수십 대까지 늘려 트래픽을 견딜 수 있습니다. 행사 종료 후에는 다시 인스턴스 수를 줄여 불필요한 비용 지출을 막습니다. Netflix같은 스트리밍 서비스도 시청자가 몰릴 때 자동으로 서버와 네트워크 용량을 늘려 서비스 중단 없이 대응하는데, 모두 클라우드의 신속한 탄력성 덕분입니다. 실제 사례로, 한 대학 연구팀이 AWS에서 평소에 쓰던 수백 개 vCPU 규모 환경을 필요 시 일시적으로 백만 개 이상의 vCPU를 갖는 초대형 컴퓨팅 클러스터로 확장하고, 실험 후에는 자원을 반납하여 비용을 최소화한 사례가 있습니다. 이처럼 클라우드 탄력성으로 스타트업도 소규모 자원으로 시작해 사용자 1명에서 1억 명까지 무리 없이 서비스를 확장할 수 있습니다.
5. 측정 가능한 서비스 (Measured Service)
정의: 측정 가능한 서비스란 클라우드 자원 사용량을 정량적으로 계측하고 모니터링하여, 그 데이터에 기반해 과금하거나 리소스를 관리하는 특성을 의미합니다. 쉽게 말해, 클라우드에서는 누가 얼마나 자원을 썼는지 자동으로 기록되며, 사용자는 사용량에 따라 요금을 내고 필요한 경우 더 많은 자원을 요청할 수 있습니다.
기술 배경: 클라우드 시스템에는 미터링(metering) 기능이 내장되어 있어, 서비스 유형에 따라 적절한 단위로 사용량을 추적합니다. 예를 들어 CPU 사용 시간, 저장소 용량, 네트워크 대역폭, 사용한 사용자 계정 수 등을 실시간으로 계측하고 로그를 남깁니다. 이렇게 수집된 데이터는 클라우드 관리 콘솔에 대시보드 형태로 제공되어, 사용자와 공급자 모두 서비스 사용량을 투명하게 확인할 수 있습니다. 또한 측정된 사용량 데이터는 자동 확장 판단(예: CPU 사용률 70% 이상 시 서버 추가) 등 자원 최적화를 위한 근거로도 활용됩니다.
예시: 요금 부과 측면에서, AWS나 Azure 같은 클라우드에서는 월말에 고정비용 청구서가 나오는 것이 아니라 “쓴 만큼만(pay-as-you-go)” 비용을 지불합니다. 예를 들어 한 달 동안 가상서버를 100시간 돌렸다면 100시간치만 과금되고, 저장소를 50GB 사용했다면 그 용량만큼 요금을 냅니다. 또한 관리 측면에서 사용자는 웹 콘솔에서 현재까지 사용한 트래픽 양, CPU 시간, 메모리 사용량 등을 한눈에 모니터링할 수 있어 예산 관리와 용량 계획을 세우기 용이합니다. 이러한 측정 및 계량 특성 덕분에 클라우드 환경은 마치 전기나 수도처럼 사용량 기반의 합리적인 비용 정산과 투명한 자원 관리가 이루어집니다.
참고: 위의 5대 특성은 클라우드 컴퓨팅을 정의하는 표준적인 요소로, 모든 주요 클라우드 서비스에서 공통적으로 찾아볼 수 있습니다. 이 외에도 높은 가용성(HA), 서비스 수준 관리, 보안 등의 부가적인 특징들이 있지만, 근본적으로는 위의 다섯 가지 요소를 기반으로 클라우드의 장점들이 구현됩니다. 초보자분들은 이 다섯 가지를 통해 클라우드가 왜 기존 IT인프라와 다른지를 이해할 수 있으며, 이를 토대로 클라우드 서비스를 더욱 효과적으로 활용할 수 있습니다.
① 사용자(User)
-
실제 사람 계정
-
예: 직원의 Google 계정, 사내 사용자 계정
-
주 용도: 콘솔 로그인, 수동 작업
② 서비스 계정(Service Account)
-
사람이 아닌 애플리케이션/시스템용 계정
-
서버, 애플리케이션, 배치 작업 등이 사용
-
예: VM이 Cloud Storage에 접근할 때 사용하는 계정
③ 그룹(Group)
-
여러 사용자를 묶은 논리적 단위
-
권한 관리를 단순화하기 위해 사용
-
예:
dev-team@company.com
④ 도메인(Domain) / 조직(Organization)
-
특정 조직 또는 회사 전체
-
조직 차원의 기본 권한 설정에 사용
**IAM 보안 주체(IAM Principal)**는
**“클라우드 리소스에 대해 어떤 행위를 할 수 있는 주체”**를 의미합니다.
즉, 누가(Who) 어떤 권한(What) 을 가지고 있는지를 정의하는 대상입니다.
아래는 초보자 관점에서 핵심만 간략히 정리한 설명입니다.
1. IAM 보안 주체란?
IAM에서 보안 주체는 인증된 신원(identity) 으로,
클라우드 리소스에 접근하거나 작업(API 호출 등)을 수행할 수 있는 행위의 주체입니다.
“이 사람이(또는 이 서비스가) 이 리소스에 접근해도 되는가?”
→ 이 질문의 대상이 바로 IAM 보안 주체입니다.
2. 대표적인 IAM 보안 주체 유형 (GCP 기준)
GCP, AWS 등 주요 클라우드에서 공통적으로 사용되는 개념입니다.
① 사용자(User)
-
실제 사람 계정
-
예: 직원의 Google 계정, 사내 사용자 계정
-
주 용도: 콘솔 로그인, 수동 작업
② 서비스 계정(Service Account)
-
사람이 아닌 애플리케이션/시스템용 계정
-
서버, 애플리케이션, 배치 작업 등이 사용
-
예: VM이 Cloud Storage에 접근할 때 사용하는 계정
③ 그룹(Group)
-
여러 사용자를 묶은 논리적 단위
-
권한 관리를 단순화하기 위해 사용
-
예:
dev-team@company.com
④ 도메인(Domain) / 조직(Organization)
-
특정 조직 또는 회사 전체
-
조직 차원의 기본 권한 설정에 사용
3. IAM 보안 주체와 권한의 관계
IAM에서는 보안 주체 자체에 직접 권한을 주지 않고,
항상 다음 구조로 관리합니다.
-
보안 주체 → 역할(Role) 을 부여받음
-
역할 → 여러 권한(Permission) 의 묶음
예시:
-
서비스 계정 A에
-
Storage Object Viewer역할을 부여 -
→ Cloud Storage 객체를 읽을 수 있음
4. 왜 IAM 보안 주체가 중요한가?
-
보안의 출발점이기 때문
-
누가 어떤 리소스에 접근하는지 명확히 통제 가능
-
최소 권한 원칙(Least Privilege) 구현 가능
-
감사·추적·사고 대응에 필수
한 줄 요약
IAM 보안 주체란, 클라우드 리소스에 접근하고 작업을 수행할 수 있는 ‘사람 또는 시스템의 신원’이다.
원하시면
-
IAM 주체 vs 역할 차이
-
서비스 계정 실무 예시
-
GCP·AWS IAM 비교
도 추가로 설명해드릴 수 있습니다.
이미지는 “GCP vs AWS” 비교표로, “스토리지(저장소)”를 3가지 종류로 나누고, 각 클라우드에서의 서비스 이름이 무엇인지 매칭해 둔 자료입니다.
-
블록 스토리지: GCP = PD(영구 디스크), AWS = EBS
-
파일 스토리지: GCP = Filestore, AWS = EFS
-
오브젝트 스토리지: GCP = Cloud Storage, AWS = S3
아래는 ELI5(초등학생도 이해하게) 버전으로 “이 3개가 뭐가 다른지”를 자세히 풀어 설명한 것입니다.
큰 그림: “저장소”는 3가지 서랍 방식이 있다
컴퓨터에서 뭔가를 저장할 때, 저장 방식은 크게 3가지로 생각하면 됩니다.
-
블록(디스크)처럼 붙여 쓰는 저장소
-
폴더/파일처럼 공유하는 저장소
-
물건(객체)처럼 던져 넣는 저장소
각각 “쓰는 목적”이 다릅니다.
1) 블록 스토리지 (GCP: PD / AWS: EBS)
ELI5 비유
“컴퓨터에 꽂는 외장하드/SSD” 같은 느낌입니다.
-
서버(가상머신)에 디스크를 붙여서 사용합니다.
-
운영체제(OS) 설치 디스크, 데이터베이스 디스크처럼
‘서버 한 대가 주로 붙잡고 쓰는’ 저장소입니다.
핵심 특징
-
빠르고 안정적: 디스크처럼 동작해서 성능이 좋습니다.
-
서버에 ‘붙는다’: 보통 한 번에 한 서버에 연결해서 씁니다
(설정에 따라 여러 서버에서 읽기 전용 공유 같은 예외도 있지만, 기본 개념은 “붙이는 디스크”) -
파일 시스템을 직접 구성: 사용자가 디스크를 붙인 뒤,
그 위에 파일 시스템(ext4 등)을 만들고 폴더/파일을 씁니다.
언제 쓰나?
-
VM의 부팅 디스크(OS 디스크)
-
데이터베이스 저장소(디스크 I/O 중요한 경우)
-
서버 애플리케이션이 “로컬 디스크”처럼 써야 할 때
2) 파일 스토리지 (GCP: Filestore / AWS: EFS)
ELI5 비유
“반 친구들이 같이 쓰는 ‘공용 폴더’(공유 드라이브)” 입니다.
-
여러 서버가 같은 폴더를 동시에 읽고/쓰게 해주는 저장소입니다.
-
“파일/폴더 구조” 그대로 접근합니다.
(리눅스 기준으로는 보통 NFS 같은 방식으로 마운트)
핵심 특징
-
여러 서버가 동시에 공유하기 좋음
-
폴더/파일 권한, 경로 같은 개념을 그대로 사용
-
애플리케이션이 “공유 폴더가 필요할 때” 매우 편리
언제 쓰나?
-
여러 웹서버가 같은 이미지/업로드 파일을 공유해야 할 때
-
콘텐츠 관리 시스템(CMS), 워드프레스 같은 앱에서 공유 파일 필요할 때
-
사내 파일 서버처럼 “공유 폴더”가 필요할 때
3) 오브젝트 스토리지 (GCP: Cloud Storage / AWS: S3)
ELI5 비유
“커다란 창고에 ‘상자(물건)’를 넣고, 상자마다 이름표(키)를 붙이는 것” 입니다.
-
파일을 “디스크에 저장한다”라기보다,
객체(Object) 로 업로드하고, URL/키로 꺼내 씁니다. -
폴더처럼 보이긴 하지만(콘솔에서 폴더처럼 보이게 해줌),
실제로는 ‘키-값 저장’ 같은 구조입니다.
핵심 특징
-
엄청나게 많이 저장 가능 (대용량/대규모에 강함)
-
내구성/가용성이 높고 보관에 유리
-
보통 HTTP 기반(REST API) 으로 접근 (웹에서 링크로 접근하기 쉬움)
-
“자주 바뀌는 디스크 작업”보다는
저장/조회/배포에 강합니다.
언제 쓰나?
-
이미지/동영상/백업 파일/로그 아카이브 저장
-
정적 웹사이트 파일 호스팅
-
데이터 레이크(분석용 원천 데이터 저장)
-
파일을 URL로 배포(CDN 연동 등)
한 번에 이해하는 선택 기준 (ELI5 요약)
-
서버에 디스크처럼 붙여서 빠르게 써야 한다 → 블록 스토리지
-
GCP PD, AWS EBS
-
-
여러 서버가 같은 폴더를 같이 써야 한다 → 파일 스토리지
-
GCP Filestore, AWS EFS
-
-
엄청 많이 저장하고 URL/키로 꺼내 쓰면 된다 → 오브젝트 스토리지
-
GCP Cloud Storage, AWS S3
-
원하시면, “웹서비스에서 업로드 파일을 어디에 두면 좋은지” 같은 실전 시나리오(예: EC2/GCE + 업로드 + DB)로도 가장 흔한 아키텍처를 예시로 들어서 정리해드릴 수 있습니다.
아래는 “웹서비스에서 사용자가 업로드한 파일(이미지/첨부파일 등)을 어디에 두는 게 좋은가”를 가장 흔한 아키텍처 기준으로 정리한 실전 시나리오입니다. (GCP/AWS 공통 개념이며, 서비스명만 매핑해서 보시면 됩니다.)
결론부터: 대부분의 웹서비스는 “오브젝트 스토리지 + DB(메타데이터)”가 정답
업로드 파일의 실제 바이트 데이터:
GCP: Cloud Storage / AWS: S3
파일의 정보(메타데이터):
DB에 저장 (파일명, URL, 용량, 업로더, 생성일, 권한, 만료일 등)
이 구성이 가장 널리 쓰이는 이유는 확장성(트래픽/용량), 비용, 운영 편의, 내구성이 압도적으로 좋기 때문입니다.
가장 흔한 아키텍처(표준 패턴)
패턴 A) “App 서버(EC2/GCE) → 오브젝트 스토리지(S3/Cloud Storage) → DB”
흐름
사용자가 웹/앱에서 파일 업로드 요청
웹서버(EC2/GCE)가 파일을 받아서
S3/Cloud Storage에 업로드
DB에 파일 메타데이터 저장 (예: object key, public URL, 소유자 등)
다운로드/조회 시엔 보통 S3/Cloud Storage에서 직접 제공(또는 CDN 경유)
장점
서버 디스크가 꽉 차는 문제 방지
여러 서버로 스케일아웃해도 파일 공유 문제 없음
객체스토리지는 내구성/가용성 높고 운영 부담 낮음
단점
업로드/다운로드가 앱 서버를 통과하면 서버 네트워크 비용/부하 증가 가능
패턴 B) “클라이언트가 스토리지에 직접 업로드(Pre-signed URL) + DB”
대규모 서비스에서 더 선호되는 패턴입니다.
흐름
클라이언트가 “업로드할게요”라고 앱 서버에 요청
앱 서버가 임시 업로드 권한이 포함된 URL을 발급
AWS: Pre-signed URL
GCP: Signed URL / Signed Policy 개념
클라이언트가 그 URL로 S3/Cloud Storage에 직접 업로드
업로드 완료 콜백/확인 후 앱 서버가 DB에 메타데이터 기록
장점
앱 서버를 파일 데이터가 통과하지 않음 → 서버 부하/대역폭 절감
대규모 트래픽에 가장 강함
보안도 “짧은 시간만 유효한 업로드 권한”으로 깔끔하게 통제 가능
단점
구현이 패턴 A보다 약간 복잡(업로드 완료 처리, 예외/재시도, CORS 등)
“그럼 파일 스토리지(Filestore/EFS)는 언제 쓰나?”
업로드 파일을 파일 스토리지에 두는 경우는 보통 아래 조건일 때입니다.
패턴 C) “여러 앱 서버가 같은 파일시스템을 반드시 공유해야 하는 경우”
레거시 앱이 “로컬 폴더 경로”에 저장하도록 강하게 결합된 경우
POSIX 파일 락, 디렉터리 탐색, 잦은 파일 변경/부분 수정이 필요한 경우
예: 특정 미디어 처리 파이프라인, 일부 CMS/사내 시스템 등
장점
기존 애플리케이션 수정이 적다(그냥 공유 폴더로 마운트하면 됨)
파일/폴더 기반 접근이 자연스러움
단점
트래픽과 동시성이 커지면 운영 난이도 상승 가능
객체 스토리지 대비 비용/확장성에서 불리한 경우가 많음
결국 CDN 연동/외부 배포는 객체 스토리지 쪽이 더 일반적
“블록 스토리지(PD/EBS)에 업로드 파일 저장”은 왜 비추천인가?
패턴 D) “한 대 서버 디스크(EBS/PD)에 업로드 저장” (소규모/임시만)
가능은 하지만, 실서비스에서는 대체로 다음 문제로 확장 단계에서 막힙니다.
서버 장애/교체 시 파일 유실 위험(백업/복구 설계 필요)
서버 여러 대로 늘리면 업로드 파일이 분산되어 “어느 서버에 파일이 있는지” 문제가 생김
디스크 용량/IO 관리 부담 증가
언제 허용되나?
아주 작은 서비스의 MVP
캐시/임시 파일
“원본은 객체 스토리지, 서버 디스크는 임시 처리용” 구조(예: 변환 작업 후 업로드)
실전 추천 구성 예시(EC2/GCE + 업로드 + DB)
예시 1) 일반 웹서비스(사진 업로드, 첨부파일)
Compute: EC2 또는 GCE (또는 컨테이너/ECS/GKE 등)
Storage: S3 또는 Cloud Storage (원본 파일)
DB: RDS/Cloud SQL (메타데이터)
배포/가속: CloudFront 또는 Cloud CDN
보안: 업로드는 pre-signed URL, 다운로드는 signed URL 또는 권한 체크 후 링크 발급
예시 2) 동영상 업로드 + 트랜스코딩
업로드 원본: S3/Cloud Storage
트랜스코딩 작업: 배치/서버리스/컨테이너(필요 시 GPU)
결과물 저장: S3/Cloud Storage (다양한 해상도 버전)
스트리밍/배포: CDN + (필요 시 HLS/DASH)
DB: 메타데이터/상태(업로드 완료, 변환 진행률 등)
선택 체크리스트(현업 기준)
업로드 파일 저장소를 고를 때는 아래 질문으로 빠르게 결정합니다.
서비스가 커질 가능성이 높은가? → 오브젝트 스토리지
여러 서버에서 동일 파일을 “폴더처럼” 공유해야 하나? → 파일 스토리지
파일을 서버에 “붙인 디스크”에 두고 싶은가?
정말 소규모/임시가 아니면 보통 비추천
CDN으로 외부에 빠르게 배포해야 하나? → 오브젝트 스토리지 + CDN
업로드 트래픽이 크거나 서버 비용이 부담인가? → 클라이언트 직업로드(pre-signed URL)
원하시면 다음 중 하나로 더 구체화해서 “정답 설계” 형태로 도면 수준까지 정리해 드리겠습니다.
(1) 이미지 업로드 중심 서비스(썸네일 생성 포함)
(2) PDF/첨부파일(권한 제어/만료/다운로드 감사 로그 포함)
(3) 동영상 업로드/스트리밍(트랜스코딩 파이프라인 포함)
(4) 다중 테넌트 SaaS(조직별 격리/권한 모델 포함)
