클라우드 서비스

클라우드 컴퓨팅을 처음 접하는 분들을 위한 입문 글입니다. 개념부터 동작 원리까지, 비유와 그림으로 쉽게 풀어봅니다.

1. 클라우드, 한 줄로 정의하면?

"내가 직접 서버를 사지 않고, 인터넷을 통해 컴퓨팅 자원을 빌려 쓰고, 쓴 만큼만 비용을 내는 방식"

전기에 비유해볼게요. 전기를 쓸 때 발전소가 어떻게 돌아가는지 몰라도 되듯이, 클라우드를 쓸 때도 데이터센터의 전원, 냉각, 하드웨어 교체를 신경 쓰지 않아도 됩니다.

▶ 표 1. 온프레미스 vs 클라우드 비교

구분	온프레미스 (직접 구축)	클라우드
비유	내 집에 발전소를 짓는다	한전에서 전기를 끌어다 쓴다
초기 비용	매우 큼	거의 없음
비용 방식	구매 (CAPEX)	사용량 과금 (OPEX)
확장 속도	주문 → 배송 → 설치 (몇 주)	클릭 몇 번 (몇 분)
관리 책임	전부 내 책임	일부는 클라우드 업체가 담당

2. 왜 클라우드가 필요해졌을까?

2-1. 온프레미스 시절의 고민

서비스가 갑자기 인기를 얻으면? → 서버가 모자라서 장애 발생
반대로 서버를 넉넉히 사두면? → 평소엔 놀고 있는 자원에 돈 낭비
서버 구매, 설치, 네트워크 연결까지 수 주~수 개월 소요
하드웨어 고장, 전원, 냉각, 물리 보안까지 전부 직접 관리

2-2. 클라우드가 준 해결책

필요할 때 바로 서버를 만들고
안 쓰면 바로 지우고
쓴 만큼만 비용을 냅니다

이 세 가지가 클라우드의 핵심 가치입니다.

3. 클라우드의 5가지 핵심 특성 (NIST 정의)

미국 국립표준기술연구소(NIST)는 클라우드의 조건을 다섯 가지로 정리했습니다.

▶ 표 2. NIST가 정의한 클라우드의 5대 특성

특성	설명
온디맨드 셀프서비스	담당자에게 요청하지 않아도 사용자가 직접 콘솔이나 API로 자원을 만듭니다.
광범위한 네트워크 접근	인터넷만 되면 어디서든 접속할 수 있습니다.
자원 풀링	여러 고객이 거대한 자원 풀을 나눠 씁니다. (멀티 테넌시)
빠른 탄력성	트래픽이 늘면 자동으로 늘리고, 줄면 자동으로 줄입니다.
측정 가능한 서비스	사용량이 측정되고, 그에 따라 과금됩니다.

4. 클라우드는 어떻게 가능할까? (핵심 원리)

4-1. 가상화 (Virtualization)

클라우드의 가장 밑바닥 기술입니다.

물리 서버 1대를 논리적으로 여러 대의 "가상 서버"로 쪼개는 기술

▶ 그림 1. 가상화 전후 비교

[가상화 이전]                  [가상화 이후]
물리 서버 1대                   물리 서버 1대
 └─ OS 1개                      ├─ 가상머신 A (Linux)
 └─ 앱 1개                      ├─ 가상머신 B (Windows)
 (CPU 10%만 사용...)            └─ 가상머신 C (Linux)
                                (자원 활용률 대폭 상승)

하이퍼바이저라는 소프트웨어가 물리 자원(CPU, 메모리, 디스크)을 나눠서 각 가상머신에 배분합니다. 아파트 한 동(물리 서버)을 여러 세대(가상머신)로 나눠 각자 독립된 집처럼 쓰는 것과 비슷해요.

4-2. 자원 풀링과 규모의 경제

클라우드 업체는 전 세계에 거대한 데이터센터를 운영하며 서버를 대량으로 구매합니다. 이렇게 확보한 자원을 여러 고객이 나눠 쓰기 때문에, 개별 기업이 직접 구축하는 것보다 단가가 낮아집니다.

4-3. 자동화와 API

클라우드의 모든 기능은 API로 제어됩니다. 콘솔에서 버튼을 누르는 것도 내부적으로는 API를 호출하는 것이죠. 그래서 코드로 인프라를 만드는 IaC(Infrastructure as Code) 가 가능해집니다.

▶ 코드 1. Terraform으로 서버 1대 생성하기

resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  tags = {
    Name = "my-first-server"
  }
}

이 코드를 실행하면 서버가 만들어지고, 코드를 삭제하고 적용하면 서버가 사라집니다. 인프라가 "손으로 하는 작업"에서 "버전 관리되는 코드"로 바뀌는 거죠.

5. 서비스 모델: IaaS, PaaS, SaaS

클라우드 입문에서 가장 자주 나오는 개념입니다. 핵심은 "내가 어디까지 관리하느냐" 의 차이예요.

5-1. 피자로 이해하기 🍕

▶ 표 3. 피자 비유로 보는 서비스 모델

모델	비유	설명
온프레미스	집에서 직접 만들기	재료, 도구, 조리 전부 내가
IaaS	재료와 주방 빌리기	서버·네트워크는 빌리고 나머지는 내가
PaaS	피자 배달 (토핑만 고르기)	실행 환경까지 제공, 앱만 올리면 됨
SaaS	피자 가게에서 먹기	완성품을 그냥 사용

5-2. 관리 책임 비교

▶ 그림 2. 모델별 관리 주체 (내가 관리 / 업체가 관리)

                온프레미스   IaaS    PaaS    SaaS
애플리케이션       내가       내가    내가    업체
데이터            내가       내가    내가    내가
런타임/미들웨어     내가       내가    업체    업체
OS               내가       내가    업체    업체
가상화            내가       업체    업체    업체
서버/스토리지       내가       업체    업체    업체
네트워크           내가       업체    업체    업체

SaaS에서도 내가 입력한 데이터의 관리와 접근 권한 설정은 사용자 몫입니다.

5-3. 실제 서비스 예시

▶ 표 4. 서비스 모델별 대표 서비스

모델	대표 서비스
IaaS	AWS EC2, Azure Virtual Machines, Google Compute Engine
PaaS	AWS Elastic Beanstalk, Azure App Service, Heroku
SaaS	Microsoft 365, Google Workspace, Slack, Salesforce

6. 배포 모델: 퍼블릭 / 프라이빗 / 하이브리드

▶ 표 5. 클라우드 배포 모델 비교

모델	설명	예시
퍼블릭 클라우드	업체가 운영하는 자원을 여러 고객이 공유	AWS, Azure, GCP
프라이빗 클라우드	한 조직 전용으로 구축한 클라우드	사내 VMware 기반 환경
하이브리드 클라우드	온프레미스(또는 프라이빗)와 퍼블릭을 연결	민감 데이터는 사내, 웹 서비스는 퍼블릭
멀티 클라우드	여러 퍼블릭 클라우드를 함께 사용	AWS + Azure 병행

실무에서는 규제, 보안, 비용, 기존 자산 때문에 하이브리드나 멀티 클라우드를 택하는 경우가 매우 많습니다.

7. 클라우드의 구조: 리전과 가용 영역

퍼블릭 클라우드는 다음과 같은 계층으로 구성되어 있습니다.

▶ 그림 3. 클라우드 인프라 계층 구조

클라우드 (예: AWS)
└─ 리전 (Region): 지리적 지역 (예: 서울, 도쿄, 버지니아)
    └─ 가용 영역 (AZ): 리전 안의 독립된 데이터센터 묶음
        └─ 데이터센터: 실제 서버가 있는 건물

왜 이렇게 나눌까?

장애 격리: 한 데이터센터에 화재나 정전이 나도 다른 AZ는 멀쩡합니다.
고가용성: 서버를 여러 AZ에 분산 배치하면 한 곳이 죽어도 서비스가 유지됩니다.
지연 시간(Latency): 사용자와 가까운 리전을 쓰면 응답이 빨라집니다.
데이터 주권: 법적으로 데이터를 특정 국가 안에 둬야 할 때 리전을 선택합니다.

8. 탄력성: 오토스케일링

클라우드의 꽃이라 할 수 있는 기능입니다. 트래픽에 맞춰 서버 수가 자동으로 늘고 줄어듭니다.

▶ 그림 4. 트래픽에 따른 서버 자동 증감

트래픽
 ▲
 │        ╱╲          ← 이벤트 시간대 (서버 자동 증가)
 │      ╱    ╲
 │  ___╱      ╲___    ← 평상시 (서버 자동 감소)
 └──────────────────▶ 시간

▶ 표 6. 확장 방식 비교

방식	의미	특징
Scale Up / Down (수직 확장)	서버 한 대의 사양을 키우거나 줄임	간단하지만 한계가 있고, 서버 1대가 죽으면 끝
Scale Out / In (수평 확장)	서버 대수를 늘리거나 줄임	한 대가 죽어도 나머지가 버팀

클라우드에서는 보통 수평 확장을 선호합니다.

9. 공동 책임 모델 (Shared Responsibility Model)

"클라우드에 올렸으니 보안도 업체가 알아서 해주겠지?" 는 위험한 착각입니다.

▶ 표 7. 클라우드 업체와 고객의 보안 책임 구분

영역	책임 주체
데이터센터 물리 보안, 하드웨어, 네트워크 인프라	☁️ 클라우드 업체
OS 패치, 방화벽 설정, 접근 권한(IAM), 데이터 암호화	👤 고객

업체는 "클라우드 자체의 보안" 을, 고객은 "클라우드 안에 올린 것들의 보안" 을 책임집니다.

실제로 클라우드 보안 사고의 상당수는 업체의 해킹이 아니라 고객의 설정 실수(공개 상태로 열린 스토리지 버킷, 과도한 권한 부여 등)에서 발생합니다.

10. 클라우드의 장점과 주의할 점

장점 ✅

초기 투자 비용 절감
빠른 도입과 확장
글로벌 서비스 용이
고가용성, 재해 복구 구성이 쉬움
인프라 운영 부담 감소

주의할 점 ⚠️

비용 관리: 켜놓고 잊어버린 리소스가 청구서 폭탄으로 돌아옵니다. (FinOps의 필요성)
벤더 종속(Lock-in): 특정 업체 전용 서비스에 깊이 의존하면 이전이 어렵습니다.
보안 설정 책임: 공동 책임 모델의 이해가 필수입니다.
네트워크 의존: 인터넷 연결 품질이 곧 서비스 품질입니다.

11. 정리

▶ 표 8. 핵심 키워드 요약

키워드	한 줄 요약
클라우드	인터넷으로 빌려 쓰는 컴퓨팅 자원, 종량제
가상화	물리 서버를 논리적으로 쪼개는 기반 기술
IaaS / PaaS / SaaS	내가 어디까지 관리하느냐의 차이
리전 / AZ	장애 격리와 고가용성을 위한 물리적 구조
탄력성	수요에 따라 자원을 자동으로 늘리고 줄임
공동 책임 모델	업체와 고객이 보안 책임을 나눠 가짐

다음 글 예고

컨테이너와 쿠버네티스는 왜 클라우드와 함께 언급될까?
클라우드 네트워크(VPC) 쉽게 이해하기
IAM: 클라우드 보안의 시작점

읽어주셔서 감사합니다. 궁금한 점은 댓글로 남겨주세요! 🙌

김재현

문제를 해결하고, 더 나은 경험을 만드는 것을 즐깁니다

이전 포스트

About VPN

다음 포스트