이번 회차에서 다룬 내용
2026년 1월 6일 화요일, AWS Certified Cloud Practitioner(CLF-C02) 스터디 1회차를 진행했다. 첫 회차 주제는 가장 기초가 되는 클라우드 컴퓨팅 기본 개념이었다.
이날 다룬 범위는 네 가지였다.
- 클라우드 컴퓨팅의 정의와 온프레미스 비교
- 클라우드의 핵심 장점: 비용, 확장성, 민첩성
- 배포 모델: Public / Private / Hybrid
- 서비스 모델: IaaS / PaaS / SaaS
스터디 운영 방식상 한 회차를 여러 사람이 나눠 발표했다. 발표자 배정표 기준으로는 다음과 같았다.
- A(대산): 클라우드 컴퓨팅 정의 & 온프레미스 비교
- B(현석): 클라우드 장점
- C(지현): 배포 모델
- D(지호): 서비스 모델
나는 이 중에서 배포 모델(Public / Private / Hybrid) 발표를 맡았다. 하지만 Cloud Practitioner 시험은 개별 서비스 암기보다도 개념 간 관계를 구분하는 것이 중요하기 때문에, 복습용 블로그 글은 내 발표 범위만 따로 적기보다 1회차 전체 흐름이 한 번에 잡히도록 정리해두는 편이 낫겠다고 생각했다.
왜 첫 회차가 중요한가
Cloud Practitioner는 흔히 AWS 입문 자격증으로 분류된다. 그래서 처음 보면 EC2, S3, Lambda처럼 서비스 이름을 빨리 외우는 것이 중요할 것처럼 느껴진다. 그런데 실제로는 반대에 가깝다.
초반 개념이 흐릿하면 이후 모든 서비스가 뒤엉킨다.
예를 들어:
- 왜 어떤 회사는 온프레미스를 유지하고 어떤 회사는 클라우드로 가는가
- 왜 퍼블릭 클라우드와 프라이빗 클라우드를 구분하는가
- 왜 같은 클라우드 서비스라도 IaaS, PaaS, SaaS로 나누는가
- 왜 AWS가 비용, 확장성, 민첩성을 반복해서 강조하는가
이런 질문에 답할 수 있어야 뒤에 나오는 AWS 서비스도 맥락 속에서 이해된다. 그냥 서비스 이름만 외우면 문제를 풀 때 헷갈린다. 반대로 개념 틀이 잡혀 있으면, 뒤에서 EC2나 RDS를 배우더라도 “이건 어떤 문제를 해결하려고 나온 서비스인가”를 연결할 수 있다.
1회차는 바로 그 틀을 세우는 시간이었다.
클라우드 컴퓨팅이란 무엇인가
가장 단순하게 말하면, 클라우드 컴퓨팅은 서버, 스토리지, 데이터베이스, 네트워크, 소프트웨어 같은 IT 자원을 인터넷을 통해 필요할 때 가져다 쓰는 방식이다.
여기서 핵심은 두 가지다.
- 직접 장비를 사서 설치하고 운영하는 대신, 필요한 만큼 빌려 쓴다.
- 한번 사두고 오래 쓰는 구조가 아니라, 수요에 따라 늘리고 줄일 수 있다.
조금 더 시험식으로 표현하면 클라우드 컴퓨팅은 보통 이런 특징을 가진다.
- 온디맨드 셀프 서비스: 필요할 때 바로 자원을 할당할 수 있음
- 광범위한 네트워크 접근: 인터넷을 통해 어디서든 접근 가능
- 자원 풀링: 여러 고객이 공유하는 대규모 인프라 기반
- 신속한 탄력성: 빠르게 확장·축소 가능
- 측정 서비스: 사용량을 계량하고 과금 가능
이 개념을 이해하려면 반대편에 있는 온프레미스(On-Premises) 를 같이 봐야 한다.
온프레미스와 클라우드의 차이
온프레미스는 말 그대로 회사가 직접 하드웨어와 소프트웨어를 보유하고, 사내나 자체 데이터센터에 설치해 운영하는 방식이다.
온프레미스의 일반적인 흐름
새 서비스를 시작한다고 가정해보자.
- 서버 사양을 검토한다.
- 장비를 발주한다.
- 납품을 기다린다.
- 네트워크를 구성한다.
- 전원, 냉각, 보안, 백업 환경을 맞춘다.
- OS와 미들웨어를 설치한다.
- 테스트 후 운영에 투입한다.
이 과정은 시간도 오래 걸리고, 초기 비용도 크게 든다. 게다가 나중에 사용량이 예상보다 적으면 장비가 놀게 되고, 예상보다 많으면 다시 증설해야 한다.
클라우드의 일반적인 흐름
반대로 클라우드에서는 같은 요구를 훨씬 빠르게 처리할 수 있다.
- 콘솔에서 서비스 선택
- 사양 선택
- 몇 분 내 자원 생성
- 사용량에 따라 확장 또는 축소
즉, 온프레미스는 미리 사서 준비하는 구조이고, 클라우드는 필요할 때 가져다 쓰는 구조다.
온프레미스가 무조건 나쁜 것은 아니다
입문 단계에서는 클라우드를 배우다 보니 온프레미스가 낡은 방식처럼 느껴지기 쉽다. 하지만 실제로는 그렇지 않다.
온프레미스가 유리할 수 있는 경우도 분명히 있다.
- 규제가 강해서 데이터 위치 통제가 매우 엄격한 경우
- 초저지연이 중요해서 내부망 기반 처리가 필요한 경우
- 이미 대규모 장비 투자를 마친 기업인 경우
- 특정 레거시 시스템과 강하게 결합된 경우
즉, 핵심은 “클라우드가 항상 정답”이 아니라 비즈니스 요구와 운영 조건에 따라 어떤 모델이 더 적합한지 판단하는 것이다. 이 지점이 나중에 하이브리드 클라우드를 이해할 때도 중요해진다.
클라우드의 핵심 장점 1: 비용 구조가 달라진다
1회차에서 가장 먼저 강조된 장점은 비용이었다. 발표 자료에서는 특히 CAPEX에서 OPEX로의 전환이 핵심으로 다뤄졌다.
CAPEX와 OPEX
- CAPEX(Capital Expenditure): 자본적 지출
- OPEX(Operating Expenditure): 운영 비용
온프레미스에서는 서버, 스토리지, 네트워크 장비를 직접 사야 하므로 보통 초기에 큰 비용이 들어간다. 이것이 CAPEX에 가깝다.
클라우드에서는 필요한 자원을 빌려 쓰고 사용량에 따라 비용을 낸다. 이것이 OPEX에 가깝다.
왜 이 차이가 중요한가
초기 투자 부담이 줄어든다.
신규 서비스가 성공할지 실패할지 모르는 상황에서 장비부터 크게 사는 것은 리스크가 크다. 반대로 클라우드는 작은 규모로 시작하고, 실제 트래픽이나 사용량에 맞춰 비용을 지출할 수 있다.
Pay-as-you-go
클라우드의 대표 개념 중 하나가 쓴 만큼 내는 구조다.
물론 실제 AWS 비용 체계는 서비스마다 다르고 단순하지 않다. 하지만 CLF-C02 수준에서는 큰 그림으로 보면 충분하다.
- 미리 큰 장비를 사두는 것보다
- 필요할 때 사용하고
- 필요 없으면 줄이거나 종료하는 방식
이 비용 구조 차이는 스타트업뿐 아니라 대기업에도 의미가 있다. 예산 편성과 운영 방식 자체가 달라지기 때문이다.
규모의 경제
AWS 같은 대규모 클라우드 사업자는 엄청난 규모의 인프라를 운영한다. 그 결과 개별 기업이 직접 구축할 때보다 더 낮은 단가와 더 높은 효율을 제공할 수 있다. 시험에서는 이 부분을 economies of scale로 자주 표현한다.
즉, AWS가 전 세계적으로 큰 규모로 운영하기 때문에 고객 입장에서는 더 효율적인 비용 구조를 기대할 수 있다는 의미다.
클라우드의 핵심 장점 2: 확장성과 탄력성
Cloud Practitioner에서 자주 헷갈리는 개념이 Scalability 와 Elasticity 다. 한국어로는 둘 다 비슷하게 “확장”처럼 느껴지지만, 뉘앙스 차이가 있다.
Scalability
시스템 규모를 키울 수 있는 능력이다.
예를 들면:
- CPU와 메모리를 더 큰 서버로 바꾸는 것
- 서버 대수를 늘리는 것
즉, 서비스가 커질 때 더 많은 부하를 감당하도록 구조를 키우는 개념이다.
Elasticity
수요 변화에 맞춰 자원을 자동으로 늘렸다가 줄이는 능력이다.
예를 들면:
- 낮에는 트래픽이 많아 서버 수를 늘리고
- 밤에는 트래픽이 적어 서버 수를 줄이는 것
Scalability가 “커질 수 있느냐”에 더 가깝다면, Elasticity는 “상황에 맞게 유연하게 늘고 줄 수 있느냐”에 더 가깝다.
왜 중요할까
온프레미스에서는 최대 트래픽을 기준으로 미리 장비를 사두는 경우가 많다. 그러면 평소에는 자원이 남아돈다.
클라우드는 필요할 때 늘리고, 필요 없을 때 줄일 수 있다. 그래서 비용 낭비를 줄이고 운영 효율을 높일 수 있다.
이 개념은 뒤에서 배우는 Auto Scaling 으로 자연스럽게 이어진다. 1회차에서는 이름만 맛보기 수준이었지만, 실제로는 “클라우드가 탄력적이다”라는 말을 가장 잘 보여주는 사례 중 하나가 Auto Scaling이다.
클라우드의 핵심 장점 3: 민첩성과 글로벌 확장
세 번째 핵심은 민첩성(Agility) 이다.
민첩성은 단순히 “빠르다”는 뜻이 아니라, 아이디어를 실제 서비스로 옮기는 속도를 높여준다는 의미에 가깝다.
민첩성이 높아진다는 것
온프레미스에서는 서버 조달과 설치에 시간이 걸린다. 그러면 개발팀이 인프라 준비를 기다려야 한다.
클라우드에서는 자원을 몇 분 안에 생성할 수 있으므로:
- 실험을 빨리 해볼 수 있고
- 실패해도 빨리 접을 수 있고
- 성공하면 빠르게 확장할 수 있다
개발팀 입장에서는 “인프라가 준비될 때까지 기다리는 시간”이 줄어들고, 그만큼 제품 개선과 실험에 더 집중할 수 있다.
글로벌 배포
클라우드의 또 다른 장점은 전 세계 리전 기반으로 서비스를 배포할 수 있다는 점이다.
물론 1회차에서는 Region과 AZ를 자세히 다루지 않았고, 이 내용은 2회차로 넘어간다. 그래도 큰 그림은 이렇다.
- 전 세계 가까운 위치에 서비스를 배치할 수 있다
- 사용자는 더 낮은 지연 시간으로 접근할 수 있다
- 기업은 더 빠르게 글로벌 서비스를 확장할 수 있다
시험에서는 종종 “전 세계 사용자에게 빠르게 서비스를 제공하려면?” 같은 문제 형태로 나온다. 이럴 때 클라우드의 글로벌 인프라 장점이 연결된다.
내가 맡았던 주제: 클라우드 배포 모델
이제 내가 발표를 맡았던 배포 모델(Deployment Models) 로 넘어간다.
Cloud Practitioner에서 배포 모델은 크게 세 가지로 정리된다.
- Public Cloud
- Private Cloud
- Hybrid Cloud
처음 공부할 때는 이름만 보고 단순히 “공용/사설/혼합” 정도로 외우게 된다. 그런데 실제로는 누가 인프라를 소유하고, 누가 운영하며, 어디에 배치되고, 어떤 요구를 해결하느냐를 같이 봐야 한다.
Public Cloud
퍼블릭 클라우드는 클라우드 제공업체가 소유하고 운영하는 인프라를 여러 고객이 공유해 사용하는 모델이다.
AWS, Microsoft Azure, Google Cloud가 대표적이다.
핵심 특징
- 인프라는 클라우드 제공업체가 관리
- 고객은 인터넷을 통해 서비스 이용
- 멀티테넌트 구조 기반
- 필요할 때 빠르게 자원 사용 가능
- 사용량 기반 과금
장점
- 초기 투자 비용이 적다
- 시작이 빠르다
- 확장성이 좋다
- 글로벌 서비스 전개가 쉽다
단점 또는 고려사항
- 규제상 데이터 통제가 중요하면 제약이 생길 수 있다
- 완전한 물리적 통제권은 없다
- 보안과 거버넌스 정책을 더 신중히 설계해야 한다
어떤 조직에 잘 맞는가
- 빠르게 시작해야 하는 스타트업
- 트래픽 변화가 큰 서비스
- 글로벌 확장이 필요한 서비스
- 인프라 운영 부담을 줄이고 싶은 조직
시험에서는 Public Cloud를 거의 기본값처럼 다루는 경우가 많다. AWS 자체가 퍼블릭 클라우드 서비스 제공자이기 때문이다.
Private Cloud
프라이빗 클라우드는 특정 조직만을 위해 전용으로 운영되는 클라우드 환경이다.
중요한 점은 “프라이빗”이 반드시 “회사 내부 서버실”만을 뜻하는 것은 아니라는 점이다. 외부 데이터센터에 있더라도 특정 조직 전용으로 운영되면 프라이빗 클라우드라고 볼 수 있다.
핵심 특징
- 특정 조직 전용 인프라
- 더 높은 통제력
- 맞춤형 보안 및 규제 대응 가능
- 일반적으로 비용과 운영 복잡도는 더 높음
장점
- 데이터 및 인프라 통제가 강함
- 보안·규제 요구사항 충족에 유리함
- 조직 맞춤형 설계가 가능함
단점
- 구축·운영 비용이 큼
- 확장 속도가 퍼블릭보다 느릴 수 있음
- 운영 부담이 높음
어떤 경우에 적합한가
- 금융·공공·의료처럼 규제가 강한 산업
- 민감한 데이터를 매우 엄격히 통제해야 하는 경우
- 레거시 시스템과 강하게 결합된 환경
Cloud Practitioner 수준에서는 “보안이 더 좋다”로 단순화하기보다, 통제권이 더 크고 규제 대응에 유리하다 정도로 이해하는 편이 좋다.
Hybrid Cloud
하이브리드 클라우드는 온프레미스 또는 프라이빗 클라우드와 퍼블릭 클라우드를 함께 사용하는 모델이다.
현실에서는 이 모델이 꽤 많다. 기업이 모든 시스템을 하루아침에 퍼블릭 클라우드로 옮기기 어렵기 때문이다.
핵심 특징
- 기존 온프레미스 환경과 클라우드를 함께 사용
- 민감한 업무는 내부에 두고
- 유연한 확장이나 신규 서비스는 퍼블릭 클라우드에서 운영 가능
장점
- 기존 시스템을 한 번에 버리지 않아도 됨
- 민감한 데이터는 내부 통제 유지 가능
- 필요한 부분만 클라우드의 유연성을 활용 가능
단점
- 구조가 복잡해진다
- 운영 및 연결 관리가 어렵다
- 보안 정책과 데이터 흐름을 더 정교하게 설계해야 한다
대표적인 사용 예
- 핵심 개인정보 데이터베이스는 내부에 유지
- 웹 애플리케이션과 분석 시스템은 퍼블릭 클라우드에서 운영
이 모델은 “현실적인 이전 전략”으로 자주 등장한다. 시험에서도 전면 이전이 어렵거나 규제가 있는 조직의 시나리오에서 하이브리드가 답으로 나오는 경우가 많다.
세 가지 배포 모델을 한 번에 비교해보기
인프라 통제권
- Public Cloud: 낮음
- Private Cloud: 높음
- Hybrid Cloud: 혼합
초기 비용
- Public Cloud: 낮은 편
- Private Cloud: 높은 편
- Hybrid Cloud: 상황에 따라 다름
확장성
- Public Cloud: 매우 좋음
- Private Cloud: 제한적일 수 있음
- Hybrid Cloud: 설계에 따라 다름
규제 대응
- Public Cloud: 가능하지만 설계 필요
- Private Cloud: 유리함
- Hybrid Cloud: 유연한 대응 가능
배포 모델 관련 문제는 보통 “이 조직은 어떤 환경에 가장 적합한가” 형태로 나온다. 이때는 단순 암기보다 비용·통제·확장성·규제 네 축으로 생각하면 비교가 쉬워진다.
지호 님 발표 주제: 서비스 모델
마지막 발표 주제는 서비스 모델(IaaS / PaaS / SaaS) 이었다.
이 부분은 초반에 가장 많이 헷갈리는 개념 중 하나다. 같은 클라우드 서비스인데 왜 따로 나누는지 감이 잘 안 오기 때문이다.
핵심은 사용자가 어디까지 직접 관리하느냐다.
IaaS (Infrastructure as a Service)
IaaS는 인프라를 서비스로 제공받는 모델이다.
사용자는 서버, 스토리지, 네트워크 같은 기반 자원을 빌려 쓰지만, 그 위의 운영체제, 애플리케이션, 데이터 관리는 직접 한다.
쉽게 말하면
빈 사무실과 기본 설비는 제공받되, 내부를 어떻게 꾸미고 운영할지는 직접 하는 느낌이다.
사용자가 주로 관리하는 것
- 운영체제
- 미들웨어
- 런타임
- 애플리케이션
- 데이터
대표 예시
- Amazon EC2
장점
- 제어권이 크다
- 유연성이 높다
- 다양한 커스터마이징 가능
단점
- 직접 관리해야 할 범위가 많다
- 운영 부담이 크다
시험에서는 “OS 수준 제어가 필요하다”거나 “가상 서버를 직접 구성한다”면 IaaS를 떠올리면 된다.
PaaS (Platform as a Service)
PaaS는 플랫폼을 서비스로 제공받는 모델이다.
사용자는 애플리케이션 코드와 데이터에 집중하고, 그 아래의 운영체제, 런타임, 인프라 관리 부담은 상당 부분 줄어든다.
쉽게 말하면
주방과 기본 조리도구가 다 갖춰진 공간을 제공받고, 재료와 레시피에 집중하는 느낌이다.
사용자가 주로 관리하는 것
- 애플리케이션
- 데이터
제공자가 주로 관리하는 것
- 서버
- 스토리지
- 네트워크
- 운영체제
- 런타임 일부
일반적인 장점
- 개발 속도가 빨라진다
- 인프라 운영 부담이 줄어든다
- 배포가 쉬워진다
단점
- 자유도가 IaaS보다 낮을 수 있다
- 플랫폼 제약이 존재할 수 있다
Cloud Practitioner에서는 개념 위주로 이해하는 것이 우선이고, 특정 AWS 서비스 매핑은 시험 수준에서 아주 세세하게 따지기보다 큰 구조를 잡는 편이 낫다.
SaaS (Software as a Service)
SaaS는 완성된 소프트웨어 자체를 서비스로 제공받는 모델이다.
사용자는 계정을 만들고 바로 사용하면 된다. 인프라나 플랫폼을 거의 신경 쓰지 않는다.
쉽게 말하면
완성된 앱이나 웹 서비스를 그냥 구독해서 쓰는 형태다.
예시
- 이메일 서비스
- 협업 도구
- CRM
- 문서 작성 도구
장점
- 바로 사용할 수 있다
- 관리 부담이 가장 적다
- 도입 속도가 빠르다
단점
- 커스터마이징 여지가 적을 수 있다
- 제공자 정책 의존도가 높다
서비스 모델 문제를 풀 때는 “누가 무엇을 관리하는가”만 정확히 잡아도 대부분 풀린다.
IaaS / PaaS / SaaS를 구분하는 가장 쉬운 기준
이 부분은 외울 때 복잡해 보이지만, 한 줄로 줄이면 이렇게 정리할 수 있다.
- IaaS: 인프라는 빌려주고 나머지는 내가 많이 관리
- PaaS: 개발 플랫폼까지 제공, 나는 앱과 데이터에 집중
- SaaS: 완성된 소프트웨어를 바로 사용
즉, 왼쪽에서 오른쪽으로 갈수록 사용자가 직접 관리하는 범위가 줄어든다.
이 흐름은 이후 AWS Shared Responsibility Model을 이해할 때도 연결된다. 모든 걸 AWS가 대신해주는 게 아니라, 서비스 모델에 따라 고객이 책임지는 영역이 달라진다는 감각을 미리 잡아두는 것이 중요하다.
이번 회차에서 남겨둘 포인트
첫 회차를 하면서 가장 크게 느낀 건, 생각보다 용어가 헷갈린다는 점이었다.
예를 들어:
- 배포 모델과 서비스 모델은 이름부터 비슷하게 느껴지고
- 확장성과 탄력성도 처음 보면 거의 같은 말처럼 들리고
- 온프레미스와 프라이빗 클라우드도 막연하게 비슷해 보인다
그런데 발표를 준비하면서 차이를 문장으로 설명해보니 오히려 개념이 더 선명해졌다.
특히 내가 맡았던 Public / Private / Hybrid는 단순히 정의만 외우면 금방 헷갈리는데, “누가 소유하고 누가 통제하는가”, “어떤 상황에서 유리한가”로 나눠 생각하니 훨씬 잘 정리됐다.
이 스터디 방식이 좋은 이유도 여기 있었다. 듣기만 하면 이해한 것 같다가 금방 흐려지는데, 직접 설명할 차례가 오면 애매한 부분을 그냥 넘길 수가 없다.
시험 전에 다시 볼 포인트
마지막으로 시험용 복습 포인트만 짧게 다시 정리하면:
- 클라우드는 인터넷을 통해 IT 자원을 온디맨드로 제공하는 방식이다.
- 온프레미스는 직접 구매·설치·운영하는 구조다.
- 클라우드의 장점은 비용 구조 개선, 확장성, 탄력성, 민첩성, 글로벌 확장이다.
- Public Cloud는 공유 인프라 기반, Private Cloud는 전용 인프라 기반, Hybrid Cloud는 혼합형이다.
- IaaS / PaaS / SaaS는 사용자가 어디까지 직접 관리하느냐로 구분한다.
1회차는 서비스 이름보다 개념 프레임을 잡는 회차였다. 이 프레임이 잡혀야 2회차의 글로벌 인프라, 3회차의 EC2와 Auto Scaling, 이후의 보안·비용·아키텍처까지 자연스럽게 이어질 수 있다.
자료 다운로드
reference 폴더 기준으로 1회차에 해당하는 발표 자료 파일은 아래 3개였다. 복습용으로 바로 내려받을 수 있도록 정적 경로로 따로 옮겨두었다.
-
20260106.html 현석 발표 자료. 클라우드의 핵심 장점(비용, 확장성, 민첩성) 중심.
-
1-3Types of Cloud Deployment지현 (1).pdf 내 발표 자료. Public / Private / Hybrid 배포 모델 정리.
-
260105_Cloud service model 설명.pdf 지호 발표 자료. IaaS / PaaS / SaaS 서비스 모델 설명.
다음 글에서는 1월 8일 2회차 주제인 AWS 글로벌 인프라를 정리할 예정이다.
Community
Comments
Comments appear immediately. Use report if something needs review.
No comments yet.