클라우드 일경험 프로젝트 사전 교육을 수강하며 정리한 내용입니다.
학교 전공 수업때 배웠던 내용이고, 이번 교육 때 한번 더 학습하면서 정리해보았다.
목표 ) 개념을 확실히 하기 !
1. 클라우드 컴퓨팅이란? 개념부터 가상화까지
클라우드를 공부하기 전에!! 서버가 무엇인지부터 짚고 시작하겠다.
서버와 데이터센터
서버는 요청을 받아 처리하고 결과를 응답해 주는 시스템 또는 소프트웨어이다.
하드웨어로 보면 CPU, 메모리, 스토리지, NIC 등으로 이뤄진 장비이고, 소프트웨어로 보면 요청을 처리하는 웹 서버, DB 서버 같은 애플리케이션이다.
이런 서버와 네트워크, 스토리지, 보안장치, 냉각시설을 한곳에 모아 IT 장비가 안정적으로 동작하도록 지원하는 시설이 데이터센터다.
클라우드 컴퓨팅이란?
클라우드 컴퓨팅은 인터넷을 통해 언제 어디서든 접근할 수 있고, 추상화된 IT 리소스를 원하는 만큼(On-Demand) 즉시 빌려 쓰는 모델이다. 컴퓨팅 자원을 여러 사용자가 효율적으로 공유하고, 트래픽에 따라 크기를 바로 조정할 수 있으며, 사용량을 정확히 측정해 과금한다. 이 모든 것은 가상화 기술을 기반으로 제공된다.
NIST가 정의한 클라우드의 5가지 특성
- 온디맨드 셀프서비스
- 네트워크 접근
- 자원 풀링
- 신속한 탄력성
- 측정 가능한 서비스
가상화 기술
가상화는 물리적 리소스를 논리적으로 추상화(분할/통합/격리)하는 기술이다. 덕분에 물리 시스템을 통합하고, 하드웨어에 종속되지 않으며, 리소스를 효율적으로 쓰고 구축 비용을 줄일 수 있다. 필요할 때 빠르게 만들고 유연하게 할당하는 것도 가능하다.
가상화의 종류
- 시스템 가상화: 가상머신은 하이퍼바이저(KVM, Xen 등) 위에서 게스트 OS를 실행하고, 컨테이너는 OS 커널을 공유하면서 프로세스만 격리(Docker, Podman).
- 네트워크 가상화: SDN은 소프트웨어로 논리적 네트워크를 구성·제어하고, NFV는 네트워크 기능 자체를 소프트웨어화
- 스토리지 가상화: SDS는 소프트웨어 기반으로 스토리지를 추상화
가상머신 vs 컨테이너
가상머신은 앱마다 게스트 OS가 따로 있어 무겁지만 격리가 강하고, 컨테이너는 호스트 OS 커널을 공유해서 가볍고 빠르게 뜬다.
한 줄 요약: 클라우드는 가상화 기술로 IT 자원을 필요한 만큼 빌려 쓰는 모델이다.
2. IaaS·PaaS·SaaS와 온프레미스 vs 클라우드, 비용 관리
서비스 모델: 어디까지 내가 관리하나
서비스 모델은 관리 범위에 따라 나뉜다.
- IaaS: 가상 서버·네트워크·스토리지를 제공. -> OS 이상은 사용자가 관리함
- PaaS: 개발·운영 플랫폼을 제공해 인프라 관리 부담이 줄어듬 -> OS와 런타임은 제공자가 관리
- SaaS: 완성된 소프트웨어를 그대로 사용 -> 고객은 데이터와 사용자 설정 관리
- FaaS(서버리스): 코드 단위로 실행
핵심은 책임 공유 모델!!
IaaS는 OS·미들웨어·앱·데이터가 고객 책임이고, PaaS는 앱과 데이터만, SaaS는 데이터와 사용자 설정만 고객 책임이다.
물리 시설·서버·네트워크·가상화 계층은 어느 모델이든 제공자 책임이다.
[IaaS·PaaS·SaaS 책임 공유 모델 표]
| 관리 항목 | IaaS | PaaS | SaaS |
| 데이터 | 고객 | 고객 | 고객 |
| 애플리케이션 | 고객 | 고객 | 제공자 |
| 런타임 | 고객 | 제공자 | 제공자 |
| 미들웨어 | 고객 | 제공자 | 제공자 |
| 운영체제(OS) | 고객 | 제공자 | 제공자 |
| 가상화 | 제공자 | 제공자 | 제공자 |
| 서버·스토리지·네트워크 | 제공자 | 제공자 | 제공자 |
배포 모델
- 퍼블릭 클라우드: 사업자가 구축하고 사용량만큼 과금하며 운영 부담이 적음
- 프라이빗 클라우드: 자사 전용으로 구축해 최적화할 수 있지만 초기 비용과 시간이 큼
- 하이브리드 클라우드: 퍼블릭과 프라이빗(온프레미스)을 연계
- 멀티클라우드: 여러 퍼블릭 클라우드를 연계
보안, 규제, 기존 시스템 연계에 따라 선택해야 한다.
온프레미스 vs 클라우드
| 항목 | 온프레미스 | 클라우드 |
| 초기 비용 | 장비·시설 선투자(CAPEX) | 거의 없음, 쓴 만큼(OPEX) |
| 구축 속도 | 수 주~수 개월 | 수 분 내 프로비저닝 |
| 확장성 | 피크 기준으로 미리 증설 | 필요 시 즉시 확장·축소 |
| 운영 책임 | 하드웨어~앱 전부 직접 | 사업자와 공유 |
| 가시성·통제 | 물리 위치·구성 완전 통제 | 추상화되어 일부 제한 |
| 보안·규제 | 직접 구현, 데이터 위치 명확 | 설정 실수 시 대규모 유출 위험, 리전·규제 확인 필요 |
| 재해복구 | 별도 사이트 구축 부담 | 다중 AZ·리전으로 합리적 비용 |
| 종속·유연성 | 장비 교체 부담 | 사업자 종속(Lock-in) 가능 |
선택 기준
클라우드가 항상 더 싼 것은 아니다. 고정 부하라면 온프레미스가 유리할 수 있고, 운영 인력, 커스터마이징, 출시 속도, SLA, 규제까지 함께 봐야 한다. 두 방식을 함께 쓰는 하이브리드도 많다.
비용 구조와 FinOps
과금은 종량제, 예약·약정 할인, 스토리지·데이터 전송 비용으로 구성된다.
요금 폭탄의 단골은 켜둔 인스턴스, 미사용 EBS·Elastic IP, NAT·데이터 전송이다.(예전에 플젝할때도 사용하지않은 탄력적 IP 때문에 나갔던 기억이...) 비교할 때는 서버만이 아니라 백업, 모니터링, 운영 인력까지 포함해야 합니다.
기본 수칙: 루트 계정 사용 금지와 MFA, dev/staging/prod 분리, 태그 관리, 예산 알람 설정
한 줄 요약: 서비스 모델마다 내가 책임지는 범위가 다르고, 클라우드가 무조건 싼 것은 아니다.
3. 리전, AZ, VPC, 서브넷: 클라우드 네트워크의 기본 단위
리전(Region)과 가용영역(AZ)
리전은 서울, 도쿄, 버지니아처럼 클라우드 서비스가 제공되는 거점이고, 리전끼리는 완전히 독립적으로 운영된다.
가용영역(AZ)은 한 리전 안에서 물리적으로 분리된 데이터센터 그룹이다. AZ 사이는 전용 광케이블로 연결되어 빠르게 통신하고, 화재나 정전 같은 물리적 재해로부터 서로 격리된다. GCP의 Zone, OCI의 AD(Availability Domain)가 같은 개념이다.
리전 선택 기준
- 사용자와의 거리 및 지연시간
- 개인정보·데이터 거주 요건과 관련 규제
- 필요한 서비스의 지원 여부
- 리전별 가격과 데이터 전송 비용
- 장애 대응·재해복구 요구사항
단일 AZ vs 다중 AZ
단일 AZ는 데이터센터 하나가 다운되면 서비스 전체가 멈춘다.
다중 AZ(Multi-AZ)는 같은 리전의 AZ 2개 이상에 서버 복제본을 두고, 한쪽이 마비되면 다른 AZ로 자동 장애 조치(Failover)가 이뤄진다.
VPC(Virtual Private Cloud)
VPC는 가상의 독립적인 네트워크 공간. 리전에서 생성하고 하나 이상의 AZ를 선택해서 구성하며, VPC 자체 비용은 없지만 트래픽 비용은 발생한다. 다른 VPC나 온프레미스와 연결할 수 있고, 생성할 때 CIDR(예: 10.0.0.0/16)로 대역을 지정한다. Azure의 VNet, OCI의 VCN과 같은 개념이고, GCP는 글로벌 단위의 VPC를 사용한다.
서브넷과 CIDR 설계
서브넷은 VPC 대역을 다시 나눈 단위로, 하나의 서브넷은 하나의 AZ에 속하고 퍼블릭과 프라이빗 서브넷으로 구분된다.
CIDR 설계 원칙
- VPC 대역은 나중에 바꾸기 어려우니 처음에 넉넉하게 설계
- 사내망이나 다른 VPC와 겹치지 않게 설계(겹치면 연결 불가)
- 필요한 서버 수와 가용 IP 개수 확인(AWS는 서브넷당 IP 5개 예약)
- CIDR 별 주소 수 = 2^(32−N) → /16 = 65,536개, /24 = 256개, /28 = 16개
엣지 로케이션과 CDN
엣지 로케이션(PoP)은 사용자와 가까운 거점으로, CDN의 물리적 기반(캐싱, DNS, WAF 등).
CDN은 가까운 엣지에서 콘텐츠를 캐싱해 전달하므로 지연 시간이 줄고 원본(Origin) 서버의 부하도 줄어든다.
한 줄 요약: 리전·AZ는 물리적 구조, VPC·서브넷은 논리적 구조이며, Multi-AZ가 가용성의 기본이다.
4. 라우팅 테이블, 보안그룹, NACL
네트워크 통신의 기본
- IP 주소: 통신 대상을 식별
- 라우팅: 목적지에 도달하기 위한 다음 홉과 경로를 결정
- 포트: 시스템 내부의 서비스·애플리케이션 엔드포인트를 구분
- TCP: 연결과 신뢰성 있는 전달을 제공
- UDP: 연결 설정 없이 데이터그램을 전달
- DNS: 도메인 이름을 IP 주소 등으로 변환
퍼블릭 서브넷 vs 프라이빗 서브넷
퍼블릭 서브넷은 인터넷 게이트웨이와 연결된 서브넷이다. 라우팅 테이블에 인터넷 게이트웨이 경로를 추가하고, 퍼블릭 IP를 할당해야 외부와 통신할 수 있다.
프라이빗 서브넷은 인터넷 게이트웨이와 연결하지 않으며, 인터넷이 필요하면 NAT Gateway(비용 발생), NAT 인스턴스, VPC 엔드포인트 등을 사용한다.
라우팅 테이블
네트워크 트래픽이 어디로 가야 할지 알려 주는 이정표이다. 서브넷마다 연결하고(별도 구성 및 공유 가능), 기본적으로 VPC 내부 경로는 local로 자동 설정된다. 인터넷 게이트웨이와 NAT 게이트웨이 경로는 직접 추가하고, VPC 피어링을 구성할 때는 양쪽 모두 경로를 추가해야 한다. 여러 경로가 겹치면 가장 구체적인 경로가 우선 적용됨!
연결 요소
- 인터넷 게이트웨이: 인터넷과의 양방향 출입구
- NAT 게이트웨이: 프라이빗 자원의 아웃바운드 전용 통로
- VPN / 전용선: 사내망과의 사설 연결
- VPC 연결: 피어링, Transit Gateway, VPC 엔드포인트
보안그룹(Security Group)
인스턴스 단위의 트래픽 제어 규칙. 기본은 거부이고, 허용 규칙을 추가하는 방식이다. 인바운드가 허용되면 아웃바운드는 자동 허용되는 Stateful 방식이며, 한 보안그룹에 여러 규칙을, 한 인스턴스에 여러 보안그룹을 설정할 수 있다. 상대방의 보안그룹이나 CIDR로 대상을 한정할 수도 있다.
NACL(Network ACL)
서브넷 단위의 트래픽 제어 규칙. 인바운드와 아웃바운드를 각각 명시해야 하는 Stateless 방식이고, 허용과 거부 규칙을 모두 쓸 수 있으며 규칙 설정 시 번호를 부여해 적용 순서를 결정한다. NACL을 통과한 뒤에도 보안그룹으로 한 번 더 제어된다.
보안그룹 vs NACL
| 구분 | 보안그룹 | NACL |
| 적용 단위 | ENI(인터페이스) | 서브넷 |
| 상태 | Stateful | Stateless |
| 규칙 | 허용만(기본 거부) | 허용·거부, 번호 순 |
| 응답 | 허용된 연결의 응답 자동 허용 | 요청·응답 모두 규칙 필요 |
한 줄 요약: 라우팅은 길을 정하고, NACL은 서브넷 문, 보안그룹은 인스턴스 문이다.
5. 웹 서비스 아키텍처: 요청 흐름과 3-Tier, 모놀리식 vs MSA
서비스 요청 흐름
사용자가 요청을 보내면 서버가 응답을 돌려준다.. 흐름은 다음과 같다.
- 사용자가 DNS를 조회
- CDN 또는 로드밸런서로 요청
- 로드밸런서가 웹/애플리케이션 서버로 전달
- 애플리케이션 서버가 데이터베이스 조회
- 처리 결과를 사용자에게 응답
구성요소별 역할을 구분해 두면 장애 지점을 찾기 쉽다.
- DNS: 도메인 이름을 IP 주소 등으로 연결
- CDN: 가까운 곳에서 정적 콘텐츠를 캐싱해 지연과 원본 부하를 줄임
- 로드밸런서: 여러 서버로 요청을 분산하고, 상태 확인(Health Check)으로 정상 대상에 트래픽 전달
3-Tier 아키텍처
- Web Tier: HTTP 요청 처리, 정적 콘텐츠 제공, 리버스 프록시
- Application Tier: 업무 로직과 API 처리(Java Spring, Node.js, Python 등)
- Database Tier: 데이터 저장·조회(요구사항에 따라 관계형 DB 또는 NoSQL 선택)
URI, URL, URN
URI는 자원을 식별하는 표준 규약으로 URL과 URN을 포함한다.
URL은 자원이 어디 있는지(위치)를 알려 주고(예: http://www.example.com:80/board/list.jsp?bid=1&idx=1234),
URN은 위치와 상관없이 자원 자체의 이름을 나타낸다(예: urn:isbn:1234567890).
모놀리식 vs 마이크로서비스
| 구분 | 모놀리식 | 마이크로서비스 |
| 배포 | 하나의 배포 단위 | 서비스별 독립 배포 |
| 통신 | 프로세스 내부 호출 | 네트워크를 통한 서비스 호출 |
| 데이터 일관성 | 관리가 비교적 단순 | 분산 데이터 일관성 관리 필요 |
| 확장 | 애플리케이션 전체 확장 | 서비스별 확장 |
| 운영 | 구조와 장애 추적이 단순 | 관측성과 운영 자동화 필요 |
모놀리식은 초기 빌드·배포·장애 추적이 단순하지만, 작은 변경도 전체를 다시 배포해야 하고 규모가 커지면 영향 범위가 커진다.
마이크로서비스는 서비스별로 기술 스택을 고르고 독립 확장할 수 있는 대신 운영 복잡도가 올라간다.
-> 시스템 규모와 팀의 운영 역량을 함께 고려해 선택해야 함!
가용성과 확장성
여러 AZ에 서버를 분산 배치하고, 로드밸런서로 트래픽을 분산하며, Auto Scaling으로 부하에 따라 서버 수를 조정해야 한다(수평 확장).
DB는 별도의 복제·백업·장애 대응 전략을 적용하고, 단일 장애 지점(SPOF) 이 없는지 항상 확인해야 한다.
설계 시 고려사항
계층별로 역할과 접근 범위를 분리하고, 계층 간 통신에는 필요한 포트만 허용한다. 예상 사용자 수, 응답 시간, 장애 영향 범위, 데이터 일관성, 확장 방식과 비용을 함께 따져 볼 것.
한 줄 요약: 요청 흐름을 계층별로 나눠 이해하면 설계도, 장애 분석도 쉬워진다.
(2)편에서 계속 ...
'DEVOPS > CLOUD' 카테고리의 다른 글
| [AWS] AWS MFA 설정하기 (Google Authenticator) (0) | 2026.11.01 |
|---|---|
| [AWS] Auto Scaling (0) | 2022.12.05 |
| [Azure] 정적 웹앱 만들기 (0) | 2022.12.03 |
| [AWS] Lambda 실습 (0) | 2022.12.03 |
| [GCP] VM, Cloud Functions 실습 (0) | 2022.12.02 |