클라우드는 무엇이고,
왜 달라야 하는가

정의, 구조 그리고 그것을 가능하게 하는 원리들

Jul 4. 2025

"클라우드 컴퓨팅은 기술의 변화가 아니라, 비즈니스 모델의 변화다"

- David Linthicum

클라우드는 어느새 우리에게 너무 익숙한 단어가 되었다. 하지만, '클라우드가 무엇인지 정확히 설명해 보라'는 질문에는 대부분이 멈칫하게 된다. 단지 인터넷 어딘가에 저장되어 있는 공간? 서버를 빌려 쓰는 서비스? 그런 식의 설명만으로는 클라우드가 기업의 IT 그리고 비즈니스 구조 전체를 어떻게 바꿔놓는지를 이해하기 어렵다.

클라우드는 하나의 구조다

우리가 말하는 클라우드는 단지 서버의 위치나 장비를 바꾸는 기술을 뜻하지 않는다. 그것은 'IT를 사용하는 방식' 자체를 전환하는 구조적인 변화이다. 에전에 기업이 서버나 스토리지를 직저 구매하고 설치한 뒤 이를 수년간 운용했다면, 이제는 필요할 때 필요한 만큼만 비용을 지불하는 방식이 가능해졌다. 이 방식이야말로 클라우드가 가져온 가장 큰 전환점이다.

이 개념을 가장 잘 정리한 것이 미국의 NIST(National Institute of Standards and Technology)의 정의이다. NIST는 클라우드를 다섯 가지 특징으로 설명한다:

1. 필요할 때 즉시 사용할 수 있어야하고 (on-demand service)

2. 인터넷 어디서든 접근할 수 있어야하고 (broad network access)

3. 여러 사용자가 자원을 함께 나눠 쓰고 (resource pooling)

4. 수요에 따라 자원이 자동으로 늘고 줄어들며 (rapid elasticity)

5. 사용량에 따라 비용을 지불한다. (measured service)

이 다섯 가지는 모두 퍼블릭 클라우드에서 가장 충실하게 구현된다. 프라이빗 클라우드에서도 일부는 구현할 수 있지만, 퍼블릭처럼 빠르게 확장되거나, 수백만 사용자를 동시에 수용하는 구조를 만드는 데에는 한계가 있다. 따라서 우리가 말하는 '클라우드의 변화'는 대부분 퍼블릭 클라우드를 전제로 하고 있다.

CapEx에서 OpEx로 - 비용 구조의 변화

클라우드가 가져온 가장 현실적인 변화는 비용 구조이다. 기존의 온프레미스 방식은 서버, 스토리지 등 IT 자산을 선투자(CapEx, 자본적 지출)로 구매했다. 이 장비들은 감가상각 자산으로 회계에 반영되며, 사용 여부와 관계없이 고정비로 남는다.

반면 클라우드는 사용량 기반 요금(OpEx, 운영적 지출)이다. 필요한 시점에 자원을 쓰고, 쓴 만큼만 비용을 낸다. 이 방식은 초기 투자 부담을 줄이고, 예산의 유연성을 높여준다.

하지만 *David Linthicum은 이렇게 지적한다. "클라우드의 핵심은 OpEx로 바뀌는 것이 아니다. 그것은 속도와 민첩성을 확보하고, 그 위에 혁신을 실행할 수 있는 구조를 갖추는 것이다."

결국 중요한 건 회계가 아니라 비즈니스의 변화 속도이다.

*David Linthicum은 전 딜로이트 컨설팅의 Chief Cloud Strategy Officer를 역임하였고 현재 클라우드 관련 인플루언서로 활동하고 있는 클라우드 전문가이다.

클라우드는 하나가 아니다 - IaaS, Paas, SaaS

클라우드는 단일한 형태가 아니다. 서비스 제공 방식에 따라 크게 세 가지 모델로 나뉜다.

- IaaS(Infrastructure as a Service): 서버와 스토리지만 빌려주는 구조. 운영체제 설치부터 애플리케이션 관리까지는 사용자의 몫이다. AWS의 EC2가 대표적이다.

- PaaS(Platform as a Service): 인프라와 개발플랫폼까지 제공한다. 개발자는 코드만 올리면 되고, 나머지 인프라와 미들웨어는 클라우드 제공자가 관리한다. 대표적으로는 GCP의 AppEngine, Azure의 Web App이 있다.

- SaaS(Software as a Service): 우리가 흔히 사용하는 Gmail, Salesforce처럼 완성된 소프트웨어를 웹에서 바로 사용하는 모델이다. 사용자는 설치도, 유지보수도 할 필요 없고 사용자는 로그인만 하면 된다.

이처럼 서비스 모델에 따라 사용자의 관리 책임과 권한이 달라진다. 클라우드에서 보안 사고가 발생했을 때 '책임은 누구에게 있는가'를 판단할 때, 이 구조를 이해하는 것이 중요하다.

공유 책임 모델 - 클라우드는 모든 것을 맡겨주는가?

많은 기업이 '클라우드는 모든 걸 대신해 준다'라고 생각하지만, 사실 클라우드는 모든 것을 '위임'하는 것이 아니라, 책임을 '분담'하는 구조이다.

예를 들어, IaaS에서는 하드웨어와 네트워크, 가상화까지는 클라우드 사업자가 책임지지만, OS 설정, 패치, 애플리케이션 보안 등은 사용자의 몫이다. SaaS의 경우 대부분 책임이 공급자에게 있지만, 사용자 계정 관리, 접근 통제는 여전히 고객 책임이다. 이 구조를 '공유 책임 모델(Shared Responsibility Model)'이라고 한다.

프라이빗 클라우드는 이와 다르다. 인프라와 보안 모두를 기업 내부 IT가 직접 책임져야 한다. 이는 제어권이 크다는 의미이기도 하지만, 반대로 사고가 나면 모든 책임이 조직 내부에 돌아간다는 뜻이기도 하다.

클라우드를 가능하게 하는 기술들

클라우드 컴퓨팅은 왜 가능해졌을까? 클라우드가 가능해진 데에는 기술적인 배경이 있다. 단순히 인터넷에 서버를 두는 것이 아니라, 다음과 같은 변화가 있었기에 오늘날의 클라우드 구조가 실현될 수 있었다.

1. 리눅스와 X86 구조 - 표준화된 아키텍처

클라우드는 리눅스 기반 운영체제와 x86 서버 아키텍처를 기반으로 대규모 가상화를 구현한다. 이 구조는 저비용 고성능 서버를 수천 대 이상 연결해 사용할 수 있게 만들었다. 하지만 유닉스(Unix) 기반 서버를 많이 사용 중인 기존 기업들은 클라우드 이전을 위해서는 U2L(Unix to Linux) 전환이 선행되어야 한다.

2. 가상화 기술의 성숙

가상화 기술은 물리서버 위에 수십 개의 가상 머신을 동시에 운영할 수 있도록 만들었고 이를 통해 자원 활용률이 획기적으로 높아졌다. 하이퍼바이저는 각 가상 머신이 독립적인 서버처럼 동작하도록 만들어준다.

클라우드로 이전을 위해서는 P2V(Physical to Virtual), V2V(Virtual to Virtual) 기술이 사용된다.

3. 자동화와 프로비저닝 - 코드로 인프라를 다룬다

오늘날의 클라우드는 수십~수백 개의 서버를 클릭 몇 번 없이 자동으로 구성해야 한다. 이 문제를 해결한 것이 IaC(Infrastructure as Code)이다. Terraform, Ansible 같은 도구를 통해 네트워크, 서버, 보안 설정을 코드로 정의하고, 프로비저닝 과정을 통해 그 코드를 실행하면 수많은 인프라 리소스가 즉시 배포된다.

덕분에 서비스 런칭 속도는 빨라지고, 운영은 표준화된다.

4. API 중심 아키텍처 - 모든 작업은 하나의 통로로

클라우드에서는 모든 자원 생성, 수정, 삭제 작업이 API를 통해 이루어진다.

단지 기능 호출 수단이 아니라, 인프라 자체를 외부에서 통제할 수 있도록 만든 단일한 인터페이스가 API이다. 이는 클라우드 인프라를 자동화하고, 유연하게 확장/축소하며, 운영을 외부 시스템과 연결할 수 있는 근간이다. 핵심은 'API로 서버를 만들 수 있다'는 것이 아니라, API가 모든 것의 유일한 통로라는 것이다.

기술의 그림자 - 표준화가 주는 역설

클라우드는 표준화된 구조를 기반으로 설계되었기 때문에, 그 표준 바깥에 있는 기업에게는 오히려 제약이 된다. 유닉스 기반 시스템을 사용하는 제조사, 자체 개발 시스템을 운영하는 금융사처럼 기존 구조가 클라우드 아키텍처와 맞지 않는 경우, 이전은 기술적 리스크를 수반하는 '재설계'수준의 프로젝트가 된다.

클라우드는 누구에게나 당연히 선택지가 아니라는 현실을 잊지 말아야 한다.

정리하며

클라우드는 단순한 기술 변화가 아니라, 운영 방식과 비즈니스 구조를 뒤바꾸는 근본적인 전환이다. 그리고 그 이면에는 기술적 혁신과 구조적 재설계가 함께 존재한다. 클라우드를 제대로 이해한다는 것은 그 구조와 철학 그리고 기술이 어떤 문제를 해결하려고 만들어졌는지를 아는 일이다.