본 보고서에서는 IaaS 에서 제공해주는 물리적 경제성을 넘어 미들웨어, 소프트웨어 컴포넌트, 생명주기 관리, 지속적 제공(Delivery) 등의 개발과 운영에 대한 인건비적 비용을 줄여주는 PaaS 에 대한 도입 방안을 다룬다. 독자는 PaaS 를 기업 내부에 퍼블릭 혹은 프라이빗으로 도입하는 경우나 직접 플랫폼을 구축하여 플랫폼 운영자가 되는 입장에서 도입에 있어 검토해야할 사항들을 이해할 수 있다. 보다 자세한 이해를 돕기 위해 국산 오픈소스를 중심으로 프라이빗 PaaS 를 구성한 사례연구도 포함한다

1. PaaS: 클라우드 도입 효율의 완성
Platform As A Service
대외 공개 가능
- 작성자 -
주식회사 유엔진클라우드 장진영 대표이사
jyjang@uengine.org
2013-10-31
- 본 문서의 목적 -
본 보고서에서는 IaaS 에서 제공해주는 물리적 경제성을 넘어 미들웨어, 소프트웨어
컴포넌트, 생명주기 관리, 지속적 제공(Delivery) 등의 개발과 운영에 대한 인건비적 비용을
줄여주는 PaaS 에 대한 도입 방안을 다룬다. 독자는 PaaS 를 기업 내부에 퍼블릭 혹은
프라이빗으로 도입하는 경우나 직접 플랫폼을 구축하여 플랫폼 운영자가 되는 입장에서
도입에 있어 검토해야할 사항들을 이해할 수 있다. 보다 자세한 이해를 돕기 위해 국산
오픈소스를 중심으로 프라이빗 PaaS 를 구성한 사례연구도 포함한다.
- 본 문서의 목차 -
PaaS 로의 확장: IaaS 로 부족한 것들
Platform As A Service 는 무엇인가?
PaaS 는 IaaS 를 넘어 어떤 이익을 가져다 주는가?

2. PaaS 에 관심을 가져야 할 사람들은 누구인가?
우리 조직은 어떤 PaaS 서비스를, 어떻게 선택해야 하는가?
퍼블릭 PaaS
프라이빗 PaaS
Platform As a Service 의 기본 이해
고전적 개발과 디플로이 방식에 대한 도전
PaaS 는 어떠한 변화를 주는가?
PaaS 와 애플리케이션 생애주기
클라우드상의 미들웨어로서의 PaaS
PaaS 의 유형들
개발도구 지원성에 따른 분류 - 포레스터 리서치
벤더 종속 성향에 따른 분류 - PaaS for dummies
PaaS 의 비즈니스 가치
개발 플랫폼으로 바라본 PaaS
클라우드에서 애플리케이션 개발하기
어플리케이션 개발 서비스의 역할
개발용 PaaS 서비스들
Deployment 플랫폼으로의 PaaS
애플리케이션을 클라우드로 디플로이 한다는 것은
PaaS 에서의 스테이징과 테스팅
PaaS 디플로이의 장점
모니터링과 노티 서비스
플랫폼 비즈니스 모델 구현체로서의 PaaS
PaaS 도입시 검토사항과 적용로드맵
Step1: 현재의 컴퓨팅 환경에 대한 핸들을 쥐기
Step 2: PaaS 의 가치에 대하여 조직적으로 이해시키기
Step 3: 옵션들을 기반으로 실험해보기
Step 4: 어떤 요구사항이 있는지 확인하라
Step 5: 평가팀을 구성
Step 6: 파일럿 수행
Step 7: 조직 구성하기
Step 8: 새롭게 개발되는 표준들에 지속적으로 검증하기

3. Step 9: 개발/디플로이 사이클의 지속성을 보유하기
IBM 의 클라우드 도입 가이드라인
사례 연구: KIAT R&D 클라우드의 국산 Open PaaS 도입
KIAT 의 도전
솔루션
도입효과
결론
참고문헌
1. PaaS 로의 확장: IaaS 로 부족한 것들
1.1. Platform As A Service 는 무엇인가?
PaaS(Platform as a Service)는 SaaS 의 개념을 개발 플랫폼에도 확장한 방식으로,
개발을 위한 플랫폼 구축을 할 필요 없이 필요한 개발 요소들을 웹에서 쉽게 빌려쓸
수 있게 하는 모델이다. 오픈 클라우드 플랫폼은 이러한 PaaS 와 IaaS 를 사용자와
독립소프트웨어개발사(ISV)들이 안정되고 자유롭게 활용할 수 있도록 하는
플랫폼이다.
TechTarget 의 최근 조사 에 의하면, SaaS 개발자의 58.7%가 PaaS 를 개발 및 실행
환경으로 사용하고 있다.
(http://searchcloudapplications.techtarget.com/feature/What-is-PaaS-Experts-
explain-growing-role-in-as-a-service-family 참조) 예컨대, Facebook 에 $1B 에
인수된 Mobile Social Media 업체인 Instagram 경우, 당 시 10 명 남짓의 개발자만
가지고 PaaS 및 IaaS 기반으로 구축하였었기에, 12 시간 사이에 100 만 명의
신규가입이라는 폭발적 성장을 소화할 수 있는 Elasticity 와 Scalability 를 발휘할 수
있었던 것이다.

4. ● Google Apps (SaaS)를 Google App Engine (PaaS)를 사용하여 개발하고
Google Apps Marketplace 를 통해 거래할 수 있다.
● 기업용 SaaS 를 Salesforce 의 Force.com (PaaS)를 사용하여 개발하고
Salesforce 의 AppExchange 를 통해 거래할 수 있다. 현재 2000 개에
육박하는 SaaS 가 AppExchange 에 등록되었으며, 2 백만 건 정도
Install 되었다. (https://appexchange.salesforce.com/ 참조)
● 기업용 SaaS 를 Windows Azure (PaaS)를 사용하여 개발한 후 Windows
Azure Marketplace 를 통해 거래할 수 있다. 현재 650 개 가량의 SaaS 가
Marketplace 등록되었다. (http://datamarket.azure.com/browse/applications
참조)
1.2. PaaS 는 IaaS 를 넘어 어떤 이익을 가져다 주는가?
우리에게 필요한 모든 서비스가 이미 SaaS 로 제공되진 않는다. 물론, 국내에서
쓸만한 국산화된 SaaS 솔루션들이 부족한것도 사실이지만, 특히나 공유된 공간에
사내의 중요한 데이터를 둔다는 것에 대한 두려움이 더 크게 작용하는 것 같다.
거기다 경우에 있어서 때로 사내의 개발조직은 맞춤형 솔루션을 비즈니스 목적에
맞춤화해서 개발해야만 한다. 개발자들이 IaaS 플랫폼을 기반하여 바로
애플리케이션을 만들 수도 있지만, IaaS 만으로 매우 생산적인 환경이 되지는 못하다.
개발자들이 자신이 사용하고 싶은 미들웨어나 개발 프로세스 (라이프사이클)에
필요한 도구들을 직접 책임져야 하기 때문이다. OS, 미들웨어, 그리고 이들을
환경에 맞게 관리하고 패치하는 모든 작업들이 책임져야 할 사항들이다. PaaS 는
이러한 복잡성을 해결하기 위하여 만들어졌다. PaaS 이러한 클라우드 환경에 대한
개발, 실행, 관리에 대한 통합 환경을 모두 제공하기 위하여 고안되었다.
첫째로, PaaS 는 개발조직에게 통합 미들웨어와 개발 서비스를 알아서 관리해준다.
이러한 플랫폼은 클라우드 환경의 생성, 디플로이, 관리의 환경에 대한 좀더
추상화된 환경을 제공한다:
■ PaaS 는 애플리케이션을 설계, 구현, 디플로이 하는 총체적 인프라를
퍼블릭이나 플라이빗 환경에 제공한다.

5. ■ PaaS 는 개발조직으로 하여금 복잡한 각 하드웨어와 소프트웨어 구성요소를
직접다루지 않아도 핵심 미들웨어 서비스를 제공한다.
■ PaaS 는 웹브라우저를 통하여 셀프서비스 형태의 완전한 개발도구 스택을
제공한다.
둘째로 PaaS 를 적용함으로써 개발과 운영조직은 SW 라이프사이클 관리를 위한 SW
형상과 버전을 트래킹하는 일관성 있는 플랫폼을 갖추게 된다. 이는 조직의 개발과
배포 프로세스를 일관되게 해준다. 다음은 이러한 IT 운영에 관련한 PaaS 의
컴포넌트들이다:
● 애플리케이션 개발과 실행 서비스
● 통합 라이프사이클 서비스 (ALM)
● 워크로드 관리 서비스
● 데이터 관리 서비스

6. 가트너의 PaaS 레퍼런스모델은 PaaS 가 갖추어야 할 보편적인 서비스와 기술을 정의하고
있다.
1.3. PaaS 에 관심을 가져야 할 사람들은 누구인가?
앞서 제시한대로 PaaS 는 우리 조직에 특화된 SaaS 의 빈자리를 채워주기 위하여
IaaS 를 넘어서 개발에서 운영, 유지보수까지의 전 소프트웨어 생명주기를 관점으로
효율성을 기대도록 고안된 플랫폼이다. 그러면, 어떤 이 들이 이러한 PaaS 를 도입할
필요성이 있을까?
● 자체 요구에 맞는 SaaS 서비스가 존재하지 않아 이를 쉽고 저렴하게
개발하고 운영하기 하고자 개발하여야 하는 조직
● 개발 인프라, 미들웨어, 판매 유통 채널을 보유하지 못한 개인 개발자나 독립
소프트웨어 벤더
● 위의 다양한 엔드-유저와 제공자(개발자)들을 끌어들이기 위한 플랫폼
비즈니스 모델을 구사할 필요성이 있는 기존 IaaS 클라우드 제공자
1.4. 우리 조직은 어떤 PaaS 서비스를, 어떻게 선택해야 하는가?
여러분께서 IaaS, SaaS, 그리고 PaaS 에 대하여 관심을 갖는다면, 이러한 서비스를
비즈니스 요구사항에 어떻게 적용할 것인가를 이해해야 한다. PaaS 를 적용하는
디플로이 모델은 퍼블릭, 프라이빗(구내구축), 그리고 이 둘을 적절히 혼합한
하이브리드의 방식이 있다. 이러한 3 가지의 모델을 구분하는 것은 실제로 누가
클라우드 자원을 소유하고, 호스팅하고 운영하느냐에 달려있다. 어떤 디플로이
모델을 선택하느냐는 우리 조직의 규정 준수, IT 기술 보유 인력 상황이나 기존
시스템 상황 등에 따라 잘 선택해야 한다.

7. IBM 이 정의한 클라우드 배포 (디플로이) 모델
1.4.1. 퍼블릭 PaaS
초기에 클라우드라 하면 대부분 퍼블릭 클라우드를 두고 이야기 했다. 퍼블릭
클라우드는 실질적으로 서버, 네트워크, 저장공간, 서비스 그리고
인터페이스를 아마존, KT 와 같은 다른 회사의 퍼블릭 인프라를 통하여
언제든지 접근할 수 있도록 제공하는 디플로이 모델이다. 이러한 서비스들은
‘규모의 경제’에 의하여 복잡한 네트워크 보안과 같이 처리하기 까다로운
IT 스킬들을 몰라도 서비스 제공자가 알아서 다 해준다.
클라우드 제공자들에게 규모의 경제를 내도록 하는 것의 핵심에는
'멀티태넌시'의 개념이 있다. 이것은 여러 다른 사용자 회사들이 같은 기반
리소스를 공유하여 사용하는데 있다. 이러한 플랫폼의 장점 중 하나는 새로운
고객이 추가됨에 따라 비용 최적화된 방식으로 받아들일 수 있다는 것인데,
이것은 하나의 사용자(태넌트)에 종속된 리소스를 제공하는 것이 아니라 여러
사용자가 가상의 큰 자원을 공유하는 개념이기 때문에 규모의 경제를 내는
것이다.

8. 개발, 테스팅, 디플로이 하는 개발의 과정에서도 어떠한 기간에 집중된
리소스 요청이 있을 수 있다. 또한 개발 팀이 지리적으로 원격지에서
근무하는 경우도 있다. 최적화된 스케일 업과 스케일 다운에 대한 최적화된
개발 플랫폼을 적시에 고르게 사용하고 반납할 수 있으므로,
애플리케이션개발과 테스팅을 퍼블릭 클라우드에서 운영하는 것은 서버를
직접 구매하고 설치 운영하는 것 보다 훨씬 경제적이라 할 수 있다.
이렇게 퍼블릭 클라우드와 퍼블릭 PaaS 를 도입하는 필요성은 주로 비용
중심의 도입 필요성을 느끼는 대기업 혹은 이러한 환경을 구축하고 운영할
인력과 인프라가 부족한 중소기업에 걸맞다.
1.4.2. 프라이빗 PaaS
어떠한 상황에서는 퍼블릭 플랫폼은 어떠한 조직에 있어서 최적의 선택이
아닐 수 도 있다. 그러한 경우의 회사는 주로 매우 엄격한 규정을 준수해야
하는 산업이며, 이러한 규정을 IT 가 준수해야 하는 경우가 예가 된다. 보통의
회사들이 퍼블릭 클라우드가 알아서 해주는 서비스를 좋아하는가 하면, 어떤
회사들은 IT 환경에 대하여 좀더 직접적인 컨트롤을 하기를 원하는 경우가
있다. 즉, 경우에 따라, 특수한 보안서비스가 필요한 경우도 있고, 혹은 이미
하드웨어 혹은 호스팅을 위한 데이터 센터와 솔루션을 갖추고자 하는 경우도
있다. 이런 경우, 프라이빗 클라우드의 형태의 서비스를 구축할 수 있다.
프라이빗 PaaS 를 구축하면 어떤 부분이 다른지를 살펴보면:
■ 프라이빗 클라우드는 IT 운영팀과 개발자들이 IT 리소스를 필요할
때마다 할당 (및 반납) 할 수 있는 요청, 승인, 반려 등의 프로세스와
셀프서비스 인터페이스를 제공하고 부서별 사용량 등을 측정 관리해
준다.
■ 기존 데이터와 애플리케이션을 데이터 센터 내에 마이그래이션 하는
기능을 제공 하기도 한다.

9. ■ 프라이빗 클라우드는 리소스 풀을 제공한다 - 컴퓨팅 자원에서
스토리지, 분석, 프로세스 관리 그리고 여러 가지 미들웨어 들을
내장한다.
■ 프라이빗 클라우드는 조직의 보안과 거버넌스에 맞춘 프로세스를
특화 할 수 있다. 이를 위하여 잘 설계된 PaaS 소프트웨어는
Framework, BPM (Business Process Management) 및 SOA
아키텍처를 기반한 아키텍처를 갖추어 기능 추가에 유연성과
프로세스 적응성을 보유한다.
2. Platform As a Service 의 기본 이해
2.1. 고전적 개발과 디플로이 방식에 대한 도전
최근의 격화된 경쟁과 복잡해지는 비즈니스 환경 속에서도 우리 SW 기업과 IT
부서들은 더욱 우아하고 차별화된 소프트웨어 애플리케이션들을 지속적으로
개선해나가야 하는 요구사항에 직면해있다. 이러한 IT 비즈니스가 발전해나감에
따라 다음과 같은 4 가지 도전을 받게 된다:
2.1.1. 빠르게 진행되는 개발환경을 관리하기
빠르게 변화하는 비즈니스 어플리케이션의 요구사항을 신속히 대응하기
위해서 기업들은 애자일(민첩한 개발 방법론; 반복적인 요구사항 수집과
점진적 개발 방식)한 개발과 디플로이 프로세스를 따르게 된다. 이러한
변화에의 대응은 새로운 기능들의 지속적 딜리버리(공급) 라는 요구에
부합되기 위한 관리 프로세스를 구축하는 데서 시작한다.
"항상 접속 가능한" 소프트웨어 모델을 지원하기 위하여 주기적 빌드를
시행하는 SaaS 서비스를 관리하는데 있어서 전통적 개발프로세스의 한번에

10. 누적된 많은 량의 코드를 한번에 반영 하는 방식은 수작업으로 인한 오류도
많고 시간 소모가 많다. 보다 자동화된 환경을 이러한 업무처리 방식이
필요하다.
2.1.2. 미들웨어 복잡성
클라우드를 운영하는 조직은 추가적인 기반 이슈들을 갖고 있는데,
미들웨어와 개발, 디플로이 도구들을 클라우드에 구축하는 데 있어, 배우고,
구현하고, 운영, 사용이 어렵다는 것이다.
예를 들면, 일반적인 큰 개발조직은 년간 50 개 이상의 미들웨어나 개발
도구들을 도입을 한다고 하는데, 이는 기존에, 그리고 현재에도 매우
복잡하고 깨지기 쉬운 SW 도구 스택과 플랫폼을 구성하고 있다는 것이다.
이는 많은 기술자들을 보유해야 하는 인건비와도 직결된다. 만약 한 개발자가
어떤 툴이나 스크립트에 익숙한데, 그 자가 조직을 떠나면 프로젝트는 곧
바로 위험에 빠지게 들 수도 있다. 전체 개발 프로세스가 꼬이게 되므로,
소프트웨어 품질은 예측하기 어려워 진다.
2.1.3. 컴퓨팅 자원 할당 받기
프로젝트 사이즈가 커지고 복잡해 짐에 따라, IT 운용 기업의 개발팀은
컴퓨팅자원과 저장 공간 등이 더 필요하게 되는데, 그때마다 장비를 구입하여
설정하고 (때때로 크로스-플랫폼 (닷넷과 자바?) 일 경우도 있을 것이고),
테스트하는 것은 아주 어렵다. 개발팀은 조달 팀이 시스템을 구매해서
할당해줄 때까지 몇 주를 놀면서 보내야 할 수 도 있다.
2.1.4. 사업의 확장과 함께 발생하는 협업 및 코디네이션의 증가
사업과 SaaS 의 형태의 서비스의 확장이 계속되면 개발조직은 여러 지리적
장소와 타임존이 다른 장소에서 협업을 해야할 때 다음과 같은 어려움에
봉착하게 된다:

11. ● 지리적으로 떨어진 개발조직을 코디네이팅하기
● 어떤 일들이 일어나고 있는지 확인하기
● 조직간 혹은 심지어 프로젝트간 진행상태를 파악하고 보고하기
이러한 이슈들은 결국 개발과 운영의 프로세스 관리가 되지 않는 실수를
일으키게 만든다.
2.1.5.
2.2. PaaS 는 어떠한 변화를 주는가?
PaaS 는 개발자와 운영자로 하여금 개발 도구와 미들웨어에 대한 설치와 운영의
대한 부담을 없애줌으로서 SaaS 와 같은 호스팅 되는 서비스의 제공과 관리의
복잡성을 줄여준다. PaaS 는 개발자에게 동일한 일종의 '개발 도구 서비스'를 제공
함으로서 개발과 제공 프로세스를 가속화 해준다. 개발과 실행에 대한 모든 서비스를
포괄하여 온라인에서 제공 함으로서 PaaS 는 어플리케이션 라이프사이클을
단순화한다.
2.2.1. PaaS 는 복잡성을 줄여준다.
많은 IT 환경의 복잡성은 매우 스킬업된 개발자들을 수작업과 운영 중 문제에
시간을 소모하게 만드는데, PaaS 환경은 이러한 컴파일러, 개발도구,
데이터관리, 보안 그리고 미들웨어까지 모두 추상화하여 제공한다.
대부분은 PaaS 환경에서는 인프라에 대한 디테일 한 관리는 개발자에게
노출되지 않는다. 대신 PaaS 환경이 몇가지 개발에 필요한 기능과
유즈케이스를 제공하는데, 예를 들어 버저닝, 롤백하기 기능을 제공한다 -
VM 이미지의 롤백이 아니라 애플리케이션 수준에서의 롤백. 애플리케이션을
개발상태에서 관리상태로 몇 가지 스텝을 밟아 설정만 함으로서 고 가용성의
환경을 제공할 수 있게 하는 것이다.
잘 설계된 PaaS 환경은 개발과 운영 팀에 좋은 협업 환경을 통하여 반복적
기계작업을 대신해주고 개발 프로세스를 자동화 해주어야 한다.

12. 2.2.2. 미들웨어 기반환경 서비스를 표준화
PaaS 는 일종의 IaaS 위에 올려져 있는 '호스팅 되고 있는 미들웨어'라고 할 수
있다. IaaS 의 역할은 메모리를 할당하고, 디스크를 할당하는 그런 수준이라고
한다면, PaaS 는 IaaS 위에서 DB 나 분산캐시와 같은 기술을 쉽게 통합해주는
역할을 한다. 데이터와 트랜잭션 손실을 최소화하려면 SaaS 는 IaaS 와
PaaS 의 조합위에 올라가는 것이 좋다. 이러한 기반을 깔고 가면 자원관리에
대한 복잡성을 줄임과 동시에 일관성과 관리성까지 높힐수 있기 때문이다.
2.2.3. 서비스 프로비져닝의 용이성 제고
PaaS 는 개발 서비스에 대산 쉬운 프로비져닝을 할 수 있게 해준다 - 빌드,
테스트 그리고 형상관리 저장소 서비스 등을 - 어떠한 표준적이지 않은
환경에서 개발되었을 때 발생할 수 있는 비효율성, 오류, 비일관성 등의
문제를 개발 라이프사이클 전반에 있어서 막아준다. PaaS 는 스테이징에서,
운영, 확장까지의 애플리케이션 프로비져닝도 IaaS 를 직접 다룰 필요 없이
셀프서비스 포탈에서 쉽게 도와주거나 심지어 자동으로 해준다.
2.2.4. IT 의 쪼개짐을 최소화
전통적으로 새로운 애플리케이션 서버나 미들웨어가 조직 내에 도입되면
IT 부서는 기존의 서비스들이 새로운 미들웨어와 연결되고 하나의 파트로
자리 잡을 수 있도록 구성해주어야 한다. 개발과 품질관리팀은 이런 것들을
해야 하는데, 가끔 이러한 부분들을 구성함에 있어 중복성과 깨짐 현상이
발생할 수 있다.
PaaS 를 기반하면 충돌을 최소화된다. 모든 미들웨어는 쉽게 관리되고 연결될
수 있도록 미리 설정되어있기 때문이고 부서별, 프로젝트 별로 매번 다시
설정하지 않는 Single-instance 이기 때문이다.
2.2.5. IT 리소스에 대한 제어권의 개선
PaaS 에서는, 자원들은 공유된 SW 자원속에서 셀프서비스를 통하여 얻어진다.
리소스가 더 이상 필요 없어지면, 자동적으로 반납된다. 이것은 개발과 QA 가
직접 IT 인프라 팀에게 요청 해야 하는 프로세스와 요청을 줄여준다.
2.2.6. 협업개선

13. PaaS 는 자원에 대한 개발과 운영에 대한 방식을 바꾼다. PaaS 기반하면
소프트웨어 개발 프로세스가 가시화된다. 예를 들면, PaaS 내에 포함된
지속적 통합 (CI) 도구들이 어플리케이션의 한 모듈이 모든 웹 브라우저에서
테스트를 자동화 하여 해당 모듈이 바로 시스템 동작가능 한 상태인지, 깨진
상태인지, 릴리즈가 될 정도인지를 바로 확인할 수 있게 해준다.
또한 협업공간으로 ‘소셜코딩'을 위한 git 와 같은 협업 개발을 위한 형상관리
지원, 지식관리를 위한 소셜네트워크를 통하여 유사한 개발에 대한 버그나
오류를 곧바로 비교하고 선후배와 검토 개발을 할 수 있도록 지원하는
기능들이 협업을 가속화한다.
2.3. PaaS 와 애플리케이션 생애주기
PaaS 는 개발에서 테스팅, 스테이징, 그리고 디플로이 까지 모든 애플리케이션의
생애주기에 관여한다. 개발자들이 개발을 마친 후 애플리케이션이 반영되는 시간을
설정하면 자동으로 무정지 반영이 이루어지며 필요에 따라 문제가 생기면 이를
곧바로 이전단계로 되돌려 줄 수 도 있어야 한다. 이는 매우 고도화된 테스트 자동화,
지속적 통합 (CI) 과 같은 기능들이 자동화되면서도 쉽게 컨트롤 될 수 있어야 한다는
것이다.
2.4. 클라우드상의 미들웨어로서의 PaaS
미들웨어는 EAI, DB, BPM 등을 포함하여, SW 컴포넌트들을 서로 연결하는 접착제와
같은 역할을 하면서도 생산되는 애플리케이션을 표준화 해주는 역할을 한다. 이러한
미들웨어들을 잘 배치하는 것은 복잡하고 어려운 아키텍처 수립이 요구된다.
PaaS 에서는 미들웨어 서비스가 호스팅된 서비스형태로 제공되기 때문에 개발팀은
어떻게 서비스들의 통합 관계가 관리될지에 대한 것이 관리 될 수 있다.
기존에는 이러한 미들웨어 자원들을 직접 인프라에 설치하고 연결하는 것을 해왔을
텐데 이러한 서비스들이 PaaS 에 의하여 자동으로 관리됨에 따라 다음과 같은 큰
차이점을 경험하게 될 것이다:

14. ● PaaS 에서 자원은 SW 형태로 제공되는 것이 아니라 서비스의 형태 - 즉, 항상
호스트된 상태로, 즉시 대응되는, 항상 떠 있는 형태로 제공된다.
● PaaS 에서의 개발과 딜리버리에 이르는 과정은 클라우드상에서 제공된다.
따로 구성하지 않는다.
● IaaS 에서 관리되던 리소스는 PaaS 가 추상화하여 관리해준다. PaaS 는
어떠한 셀프서비스 혹은 프로그래밍 API 등으로 자원을 추상화하여
제공해준다. 이러한 API 정의 기존에 표준화되지 않던 미들웨어들을
표준화하는 효과를 주기 때문에 기존에 부서간, 담당자간 협조를 요청하던
것에서 API 문서화 서버에 접속하여 바로 연동 테스트를 하는 셀프서비스
방식의 전환이 필요하다.
● 미들웨어와 서비스는 설치와 구성이 필요없다- PaaS 에서 통합되어 제공된다.
2.5. PaaS 의 유형들
PaaS 의 유형을 나누는 방식은 아직까지 시장 상황에 따라 다양한 유형이 앞으로도
나뉘어갈 예정으로 보인다. 포레스터 리서치가 나눈 방식을 보면 어떠한 개발환경을
제공하느냐에 따라 분류하고 있으며 :
2.5.1. 개발도구 지원성에 따른 분류 - 포레스터 리서치
● 클라우드 디플로이 기능을 갖춘 통합 개발 환경 (IDE)을 제공하는 하이브리드
방식
가장 큰 범주의 PaaS 제품군은 기존 개발 도구에서 크게 벗어나지 않고
제공하는 방식을 택한 PaaS 제품이다. 예를들면 기존의 이클립스나 비쥬얼
스튜디오 같은 도구를 그대로 사용함으로서 기존 개발자가 익숙한 사용성을
그대로 유지하는 방식이다. 다만, 디플로이 할때만 추가적인 클라우드
디플로이에 필요한 정보를 입력함으로써 클라우드에 애플리케이션을
디플로이한다. 개발자들은 자신의 로컬 머신에서 코딩하지만 이를 원격의

15. 클라우드 데이터 센터에 디플로이한다. 구글 앱엔진, 피보탈(VMWare)의
‘클라우드 파운드리’와 레드햇의 ‘오픈시프트’가 이러한 방식으로 클라우드
개발을 지원하고 있다. 한편 최근 구글 앱 엔진의 경우는 ‘구글 스크립트'를
통하여 클라우드상에서 어떠한 로컬장비에 설치 없이도 곧바로 개발과
디플로이를 할수 있는 ‘클라우드 IDE’를 내놓고 있다.
● 모든 개발을 클라우드에서 수행하는 클라우드 IDE 방식
클라우드 IDE 는 웹브라우저 기반의 개발환경으로 모든 개발과 디플로이를
클라우드 상에서 수행한다. 개발자들은 원격의 클라우드센터에 접속하여
개발을 하고 디플로이도 해당 클라우드 센터에서 한다. 개발자들은 어떠한
개발환경이나 설정이 없이도 수분 내에 애플리케이션을 개발하여 테스트해
볼 수 있어 플랫폼에의 유인효과가 높고 개발환경과 개발 프로세스의
거버넌스도 용이하다. 구글의 ‘구글스크립트', Exo 의 ‘CodeEnvy’, 국내의 ‘구름
IDE’, OCE 의 ‘유클립스' 등이 클라우드 IDE 에 속한다 (CodeEnvy 는
애플리케이션 개발환경만을 제공하며, 운영환경은 제공하지는 않는다).
클라우드 IDE 들은 이클립스나 비쥬얼 스튜디오와 유사한 UI 를 하고 있지만
웹 브라우저 기술을 기반하고 있어 아직 로컬에서 설치하여 사용하는 기존
IDE 들에 비하여 기능이나 사용성이 떨어질 수 밖에 없다. 하지만 HTML5
등의 웹기술이 발전함에 따라 (실제로 이클립스의 오리온 프로젝트와
윈도우즈 Azure 플랫폼 또한 클라우드 IDE 를 내놓고 있다) 곧 모든 개발을
클라우드상에서 끊김 없이 수행하는 날이 머지 않았다.
● 강력한 새로운 기능들을 제공하는 비즈니스 전문가용 PaaS
어떤 PaaS 제품들 중에는 코딩보다는 비즈니스 전문가가 사용하는 도구에
집중한 제품들이 있다. 이런 제품들은 코딩을 하지 않거나 최소화하여
애플리케이션을 생성할 수 있는 혁신적인 도구들을 제공한다. 순수하게 100%
클라우드 상에서의 (웹브라우저 상에서의) 개발은 많은 제약이 따르기 때문에
로컬에서 실행되는 사용성을 따라잡기 힘든 클라우드 IDE 를 통하여 코딩
방식으로 애플리케이션 개발을 하도록 완전하게 제공하는 것보다 이러한
방식을 혼합하는 것은 매력적인 접근방식이다.

16. OpenText Cordys 는 Business Process Management Platform 를 중심으로 한
비즈니스 폼/UI 디자이너, 규칙 정의, 프로세스 정의, SOA 퍼블리싱,
통합도구를 제공하여 비즈니스 유저가 어떠한 복잡한 코딩없이 비즈니스
애플리케이션을 생성할 수 있는 BPM-PaaS 플랫폼을 제공하고 있다.
SalesForce.com 은 Java 범용언어를 확장한 비즈니스 애플리케이션 개발용
언어인 Apex 를 클라우드 상에서 직접 개발할 수 있는 클라우드 IDE 와 함께
프로세스 디자이너, 룰 디자이너, 폼 디자이너등을 통합 제공하여 설치형
IDE 의 의존성이 없이도 수준 높은 애플리케이션을 개발할 수 있도록 해준다.
하지만 이러한 도구들이 생성한 비즈니스 오브젝트들은 호환성이 유지될 수
있도록 표준을 잘 지키고 있는지를 확인해야 한다. 예를 들어 비즈니스
프로세스 표준으로는 OMG 의 BPMN (Business Process Management
Notation), 비즈니스 폼 규약으로는 X-Forms, SOA 규약으로 OASIS 의 WS-
표준 등을 준수하는지를 살펴보아야 한다. 국내에서 개발된 OCE 의 경우는
이러한 표준 기반의 비즈니스 프로세스를 중심으로 한 Cordys 와 유사한
PaaS 개발 환경을 제공하고 있다.
● 개발 단계를 지원하지 않는 IDE 중립적 클라우드 실행타임 방식
어떤 PaaS 는 개발도구를 일체 제공하지 않는 경우도 있다. 이러한 PaaS 는
애플리케이션을 디플로이할 수 있는 대상으로 소스관리서버 등을
인터페이스로 하여 디플로이 할 수 있도록 해준다. 이러한 플랫폼은
디플로이된 애플리케이션의 향후 스케일-아웃 하는 등의 운영시나리오 만을
지원한다.

17. 포레스터가 분류한 PaaS 의 4 가지 분류
포레스터는 클라우드 개발 지원 서비스의 범위와 방식에 따라 분류하였지만, PaaS 의
특징상 벤더 종속에 대한 이슈가 크므로 다음과 같이 벤더 종속 성향에 따라 분류할
수 있다:
2.5.2. 벤더 종속 성향에 따른 분류 - PaaS for dummies

18. PaaS 를 제공하는 여러 벤더들이 존재하며 각기 약간씩 다른 보유 기술을 기반으로
제공된다. PaaS 도입을 검토하는 입장에서는 자신의 요구사항을 먼저 정확히 파악해야 한다.
● 특정 SaaS 환경에 맞춰진 PaaS
어떤 SaaS 플랫폼들은 많은 회사들의 핵심 비즈니스 서비스로 자리잡고 있다.
예를 들면 Workday, SugraCRM, 그리고 Saleforce.com 같은 서비스들은
고전적인 구내 설치형 (on-premise) 시스템들을 대체하고 있다. 이러한
SaaS 제공자중의 일부는 자신의 서비스를 PaaS 서비스로 확대하고 있는데,
Salesforce.com 을 예로 들면, Force.com 이라고 하는 PaaS 플랫폼을
제공하여 Salesforce.com 의 SaaS 서비스에 접근할 수 있는 API 들과, 개발
도구, 미들웨어들을 제공하여 개발자들이 새로운 애플리케이션을 이 기반
위에서 개발하여 제공할 수 있도록 하고 있다.
[Tip] 이러한 접근은 기존에 Salesforce.com 을 이미 사용하던 기업이
자신만의 프로세스를 개선하여 시장에서 경쟁력을 내고자 할 때 매우
매력적일 수 있다.

19. ● OS 환경에 묶여 제공되는 유형의 PaaS
OS 에 묶어서 PaaS 환경을 제공하게 되면 어떠한 액션들이 용이해진다.
이러한 접근은 어떠한 하나의 IaaS 만을 사용하는 고객에게 쉬운 선택이 될
수 있다.
마이크로소프트는 Azure 플랫폼을, 아마존은 Beanstalk 을 자신의 API 와
추상화된 기능들을 제공하여 개발자들이 자신의 플랫폼을 계속 사용하게끔
한다. 예를 들면, Windows Azure 의 경우 Windows 플랫폼과 SQL Server 를
추상화하여 제공한다. 마이크로소프트는 여러 개발도구, 관리도구와
서비스들을 이렇게 추상화했다. .NET 에 익숙한 개발자가 많은 조직인 경우
Azure 서비스로 전환하는 것은 매우 용이하다. 본질적으로 개발자는 개발과
디플로이에 있어서 마이크로 소프트의 인프라에 묶이게 되는 것이다.
아마존 닷 컴도 배포에 최적화된 자체의 PaaS 플랫폼을 제공한다. AWS
Elastic Beanstalk 은 Amazon 의 클라우드에서 좀더 쉽게 디플로이와 관리를
할 수 있도록 해준다.
● 오픈 플랫폼 기반 PaaS
오픈플랫폼기반 PaaS 는 특정 클라우드 환경에 종속되지 않은 오픈된
프로세스와 환경을 제공하기 위하여 제공되는 PaaS 플랫폼이다. 몇가지 오픈
플랫폼의 시도들이 진행되고 있다:
● Cloud Foundry 는 WMWare 가 중심이 된 PaaS 환경으로 빌드,
디플로이와 운영 프로세스를 지원한다.
● OpenShift 는 레드햇의 움직임이다.
● CloudBees 는 자바 PaaS 플랫폼으로 빌드, 테스트, 운영, 관리를
지원한다.
● OCE (Open Cloud Engine) 는 국산 오픈소스 미들웨어인 큐브리드
DBMS, 유엔진 BPMS, 플라밍고 빅데이터 플랫폼, 네트라
오케스트레이터로 구성된 자바언어와 표준을 준수하는 비즈니스
전문가용 개발도구를 제공하는 오픈 PaaS 플랫폼이다.

20. 2.6. PaaS 의 비즈니스 가치
2.6.1. 비용절감
PaaS 는 몇가지 비용을 절감해준다. PaaS 의 경제적인 영향을 측정하기
위하여 클라우드로 전환함에 있어서 직접적, 간접적 비용들을
살펴보면 다음과 같다:
● IaaS 에서 계승된 비용절감 요소인 서버와 저장공간, 네트워크:
사용되지 않는 컴퓨팅 리소스들이 차지하는 전력과 냉방비용 그리고
공간사용은 기업에서는 막대한 비용이 된다.
● 미들웨어 관리 비용: IaaS 를 기반한 멀티태넌시 아키텍처에서는
VM 내에 필요한 미들웨어 스택을 태넌트별로 다시 적재해야 하지만,
PaaS 가 주로 제공하는 멀티태넌시 프레임워크는 애플리케이션을
가능한 하나의 인스턴스로 구성하여 미들웨어 또한 싱글인스턴스로
구성하게 된다. 이는 애플리케이션과 미들웨어를 단일 코드베이스로
유지시키기 때문에, 어떠한 패치나 업데이트가 한곳에 이루어지면
이를 사용하는 모든 태넌트는 이 업데이트의 영향을 받게 되어 관리
비용이 급격히 감소하게 된다. 여기에 더해 미들웨어 라이센스의 공유
(멀티태넌시)를 통한 라이센스 비용절감 효과도 있다.
● 지원 인력 비용: 만약 고가의 아키텍트를 고용하고 있고, 프라이빗
PaaS 를 구축하고 있다면 (혹은 독자께서 플랫폼 제공자를
생각하신다면), 해당 아키텍트가 한번 근사하게 설계한 SOA
아키텍처를 기반으로 많은 소비자들이 우리가 구축한 PaaS 위에서
이러한 효율을 누릴 수 있다.
2.6.2. 스피드, 유연성, 그리고 민첩함
제공자 입장에서 보았을때 PaaS 의 지속적 딜리버리 모델이 적용되면, Time-
to-market 을 줄여 시장에서 경쟁 우위를 점할 수 있다.
소비자 입장에서 보았을때 PaaS 를 기반한 태넌트에 대한 애플리케이션
프로비져닝은 IaaS 를 기반한 VM 기반 프로비져닝 보다 다소 빠르다. 이는
하이퍼바이저를 통한 VM 기반 프로비져닝이 애플리케이션 템플릿을

21. 인스턴스화 하는데 걸리는 물리적 시간이 필요한데 비해 PaaS 자체의
싱글인스턴스-멀티태넌시 구조에 기반하여 태넌트에 대한 변경부위에
대하여서만 데이터를 관리하기 때문에 수초내지 수분 내에 프로비져닝이
가능하다.
운영자입장에서는 새로운 보안 규정, 환경에 개발과 운영에 대한 환경 설정을
한곳에서 반영할 수있어서 민첩한 대응이 가능하게 된다. 이는 거버넌스의
강화의 효과를 가져온다. 예를 들어 SW 개발된 소스코드의 외부 유출을 막기
위한 용도로 클라우드 IDE 의 사용시간 외, 특정 계정에 대한 잠금 기능을
적용할 수 있으며, 잘못된 코드의 유입을 좀더 개발 단말기에서 차단할 수
있는 ‘안티패턴' 실시간 점검 등을 제공할 수 있다.
2.6.3. 플랫폼 비즈니스 모델의 구사
만약 독자께서 퍼블릭 IaaS 환경을 보유하였거나, 막대한 애플리케이션
콘텐츠를 보유하였다면, 좀더 자사의 플랫폼에 종속되는 사용자 계층을
강화하고 싶을 것이다. 이렇게 사용자 계층이 늘어나면 어느 순간 ‘네트워크
효과'를 통하여 애플과 아마존과 같이 자체적으로 플랫폼이 수익을 내는
비즈니스 모델을 구사할 수 있다. PaaS 에는 이러한 플랫폼 비즈니스 모델을
구사할 수 있는 도구들이 제공된다. 플랫폼 비즈니스 모델의 구현체로서의
PaaS 에 대해서는 이후 챕터에서 상세히 다룬다.
2.6.4. 비즈니스 영속성 (Business Continuity)
비즈니스가 글로벌화되고 다양한 참여자들이 비즈니스에 참여하게 됨에 따라
비즈니스적으로 무정지가 약속되어야 하는 SaaS 애플리케이션이나 여러
타임존에 걸쳐진 비즈니스 환경을 제공해야 하는 요구사항이 늘고 있다.
PaaS 를 기반하면 애플리케이션이 확장이 필요한지, 어떠한 서비스 노드가
문제가 있는지를 IaaS 만으로 비즈니스 애플리케이션의 상태를 파악할때보다
좀더 민첩하게 파악할 수 있으며, 이는 동적 자동 확장, 자동 복구, 무정지
배포 등의 24-365 서비스 체계를 갖추게 해준다. 좀더 상세하게 ‘디플로이
플랫폼으로의 PaaS’ 챕터에서 다룬다.

22. 3. 개발 플랫폼으로 바라본 PaaS
PaaS 기반의 개발 프로세스는 고전적 개발 프로세스와 어떻게 다르고, 왜 더 빠르고
안전하게 제공되는가? PaaS 플랫폼은 우리 개발팀에게 어떤 의미가 되는가?
3.1. 클라우드에서 애플리케이션 개발하기
고전적인 소프트웨어 개발의 복잡성을 관리하는 것은 빌드, 관리, 업그래드 하는
많은 시간과 돈이 소모된다. 개발도구가 호스팅 된 채로 제공되면서 애자일한
어플리케이션의 생애주기가 자동 관리되는 PaaS 기반의 개발 프로세스에서는
상대적으로 적은 리소스로 설계, 개발, 그리고 테스트를 할 수 있다. 개발자에게
주어지는 순수한 영향은 아래와 같다:
● 보다 높은 품질과 안전한 소프트웨어를 만들 수 있다
● 사용자 기대를 민첩하게 대응할 수 있다.
● 소프트웨어 개발 프로젝트를 제시간과 주어진 예산 내에서 완수 할 수 있다.
다른 한편의 PaaS 는 개발과정에서 호스팅 되는 미들웨어와 OS 서비스라 할 수
있다. 이러한 서비스는 개발자에게 어떠한 설치, 관리, 혹은 IT 지원 없이도 항상
개발자에게 제공되며 개발자가 이러한 복잡한 미들웨어 서비스를 직접적으로
다루지 않아도 되게한다.
PaaS 는 많은 개발 프로세스의 경제적 관점과 속도와 민첩성의 개선에 많은 장점이
있다. 거기다가 인프라에 대한 셀프서비스 인터페이스를 제공한다. 많은 PaaS
벤더들은 개발자와 IT 담당자들이 해야하는 IT 플랫폼 관리와 안정성 요구사항을
대신 해결해주는것에 촛점을 맞추고 개발하고 있다. 서버, 미들웨어, 그리고 다른
인프라의 지출을 줄일 수 있다. 게다가 PaaS 의 비용은 사용자 수와 관계가 있으므로,
플랫폼 비용은 총체적 개발과 인건비의 절약에 영향을 준다.
PaaS 환경을 개발과 각자 개발자와 IT 파트너들이 다음과 같은 부가적 이득을 누릴
수 있다:
● 상세한 설정과 개발도구의 선택과 통합이 뒷단에서 일어나므로 비즈니스
아이디어와 목적성에 보다 집중하여 개발할 수 있다

23. ● 지속적 통합이 자동화 됨에 따라 그간 발생하던 통합과정의 오류가 줄어든다.
● 보다 안정적인 코드를 생산할 수 있다. PaaS 가 보안 업데이트와 데이터
보안성, 보안규칙등을 기반환경에서 제공하기 때문이다.
● 보다 높은 품질의 코드를 SW 품질 도구들을 사용 함으로서 생산할 수 있다.
● 개발 시간을 추가적인 IT 인프라에 대한 대기시간이 줄어듦으로 속도를 높힐
수 있다.
● 관리와 컴포넌트 업그래이드 시간이 일원화되므로 개발 속도를 높힌다.
● 다양한 디바이스 (모바일)와 OS 에 반영하는 시간이 단축된다.
3.2. 어플리케이션 개발 서비스의 역할
어플리케이션 개발 서비스는 PaaS 서비스의 핵심이다:
● 프로비져닝, 개발, 빌드, 테스트, 스테이징 환경을 제공한다
● 코딩과 개발, 테스팅에 집중할 수 있는 추상화된 개발환경을 제공한다.
개발자용 클라우드 통합개발환경(IDE)는 개발자에게 다음과 같은 장점을 제공한다:
● 기존에 사용하던 IDE 를 계속 쓰는 경우: 이클립스와 비쥬얼 스튜디어 같은
환경에 추가 플러그인등을 제공하여 좀더 개발팀과 같이 공동 개발하여
생산성을 높히고 클라우드 환경을 에뮬레이션 해볼 수 있는 샌드박스 같은
것을 PaaS 에서 제공해준다. 이는 기존에 익숙한 개발도구를 그대로 사용할
수 있다는 장점이 있다.
● 100% 웹 브라우저 기반 클라우드 IDE 를 사용하는 경우: 개발자는 어떠한
복잡하고 무거운 개발도구를 설치하고 설정을 맞추고 클라우드 환경과
연결하는 작업을 하지 않아도 바로 필요한 적시에 모바일, 소셜, 심지어
빅데이터 응용을 위한 하둡 같은 개발을 할 수 있다. 설치과정과 거버넌스를
위한 추가 플러그인 설치요청에 대하여 대응하지 않아도 내 환경은 중앙에서
관리된다.
● 클라우드 기반의 공유된 SCM (소스코드 저장소)에 넣어둘 수 있고, 모든
개발팀이 이를 공유하여 툴을 기반으로 공유할 수 있다.
● 개발과정중에 실제 사용자에게 제공될 동일한 운영환경에서 개발과 테스트를
할 수 있다.

24. 결론적으로, 애플리케이션 개발을 빨리 시작할 수 있거니와 에러도 빨리 찾을 수
있게 된다.
잘 설계된 PaaS 환경은 충분히 유연하고 모듈화가 잘되어있어 많은 시나리오에
적용가능하며 다양한 개발 목적성에 부합될 수 있도록 변형 및 프로세스 수정 등이
용이하도록 고안되었다 (프로세스 기반 ALM).
3.3. 개발용 PaaS 서비스들
3.3.1. 호스팅된 소프트웨어 형상관리 서비스
개발자들은 소프트웨어 형상관리 서비스를 사용하여 개발과정에서 발생하는
코드의 버전과 모듈을 관리한다. 코드는 온라인 저장소에 관리된다.
GitHub 는 이러한 호스팅 된 서비스의 전형을 보여준다.
소프트웨어 형상 관리 서비스는 일종의 개발자용 가상 개발기인 샌드박스
개발환경을 쉽게 복제해 내는데도 도움을 준다. 개발과 테스트를 위한
임시적인 워크로드를 운영기와 동일하게 구성할 수 있도록 해줄 때
소소저장소는 테스트하고자 하는 대상을 즉시에 빌드 될 수 있도록 하는
역할도 한다.
3.3.2. 빌드 서비스
PaaS 는 애플리케이션 빌드의 여러 가지 방식 - 서비스들을 통합하는 과정,
코드 컴파일, 그리고 테스팅 까지 거쳐서 최종 실행 가능한 애플리케이션을
만드는 과정을 포함한다. 애플리케이션을 생성할 때는 개발자들을 여러 모듈
(혹은 라이브러리) 들에 대한 종속성을 지니고 만들어 지게 되는데, PaaS 의
빌드서비스는 이러한 모듈들의 버전과 종속성을 관리하여 빌드를 자동화
해준다. 이러한 도구에는 다음과 같은 오픈소스들이 있다:
Maven: 자바개발자들에게 주로 사용되며 어플리케이션 내의 모듈간
종속성을 관리하여 빌드를 자동화 해준다.

25. Maven Repository: 소프트웨어 컴포넌트 (모듈)들을 메타데이터를 근간하여
종속성 디렉토리 등을 관리해주는 온라인 저장소이다.
3.3.3. 웹어플리케이션 서버
PaaS 환경은 개발자가 자신이 만든 애플리케이션을 쉽고 빠르게 가능한 실제
환경에서 테스트해볼 수 있게 해주는 기능이 중요한데, 웹 어플리케이션인
경우 이러한 모의 실행환경을 제공하기 위해 제공된다. 개발자가 마음껏
테스트를 해볼 수 있도록 개발기를 PaaS 는 개발자가 요청이 있는 경우
동적으로 생성하여 제공해주게 된다. 기존에는 이러한 테스트 환경을 위하여
개발자가 직접 개발기 머신을 구성하여야 했다. PaaS 는 개발자가 최대한 실
운영상황과 동일한 시뮬레이션 환경을 구성하고 실제 프로덕션에서 발생하는
환경의 차이에 대한 대비를 하지 못하는 문제를 해소해준다.
3.3.4. 프레임워크 서비스
개발자들은 주로 개발 프레임워크를 통하여 빠르게 애플리케이션을 개발하고
있다. 프레임워크를 좀더 공유된 방식으로 사용되게 되면 다음과 같은 이득을
얻을 수 있다:
● 매번 프레임워크를 설정하고 설치할 필요가 없어진다.
● 애플리케이션의 일관성 있는 구조를 구축할 수 있다.
● 안정되고 테스트된 기반 소프트웨어 모듈을 근간하여 개발할 수 있다.

26. PaaS 제공자는 다음과 같은 프레임워크들을 제공할 수 있다:
● Spring, Play Framework 같은 서버 프레임워크, X-Forms, Responsive
Web 과 같은 웹 2.0 UX 프레임워크
3.3.5. 모델 플랫폼 서비스
모델 플랫폼은 범용 어플리케이션의 기본 골격을 갖추기 위한 목적을 가진
프레임워크와 달리 비즈니스 프로세스 관리 (BPM), 비즈니스 룰 관리 (BRE),
비즈니스 인텔리젼스 (BI) 와 같은 모델 기반의 애플리케이션 통합 방식을
지원하는 미들웨어의 클라우드 서비스 형태이다. 모델 플랫폼을 제공하는
PaaS 의 경우는 매우 수준 높은 SaaS 서비스를 제공하는데, 바로
애플리케이션의 태넌트별 특화되는 영역을 소비자가 직접 셀프서비스할 수
있는 도구를 제공할 수 있기 때문이다. 좀더 상세히 말하자면, 모델
미들웨어는 주로 소비자의 업무 전문가가 직접 사용할 수 있는 프로세스
편집기, 폼 편집기, 룰 편집기 등을 제공하여 개발자가 아니더라도
애플리케이션의 형상을 관리할 수 있는 추상성을 제공하기 때문에 이후에
소비자가 셀프서비스를 통하여 자신이 취득한 애플리케이션의 업무 규칙이나
프로세스를 용이하게 관리할 수 있도록 해주고, 자신이 원하는 레포트를
주어진 BI 플랫폼의 사용자 도구를 통하여 뽑아 낼수도 있는 자율성을 준다.
이러한 모델 플랫폼을 갖춘 PaaS 는 일반적인 PaaS 에 대비하여 아주 높은
비즈니스 가치를 가지기 때문에 앞서 살펴본 포레스터의 PaaS 유형에서
‘비즈니스 전문가를 위한 PaaS’영역으로 구분된다. IBM 의 경우는 ‘BPM As A
Service - BPaaS’ 로 구분하여 정의함으로써 비즈니스 가치의 차별화를
두기도 한다. 현재 OpenText 의 Cordys, Force.com, 국내에서는 OCE 가
이러한 PaaS for Business Expert 제품군에 속한다. 대기업이나 공공기관 등
아주 높은 사용자 만족도를 요구하는 경우 모델 플랫폼 기반의 혁신적인
도구들을 제공할 필요가 있다.

27. IBM 의 클라우드 서비스 수준 정의 - IBM 은 모델 플랫폼인 BPM 서비스를 PaaS 서비스와
차별화하여 높은 비즈니스 가치로 구분하여 정의하고 있다.
3.3.6. 컴포넌트 애즈-어-서비스 (CaaS)
컴포넌트 애즈-어-서비스는 말그대로 소프트웨어 컴포넌트들을 호스팅 된
채로 제공하는 것이다. 이것이 프레임워크와 라이브러리 내에 있는
빌딩블록이나 클래스들과 차별화 되는 점은 컴포넌트화의 성숙도 수준이
높은 SOA 성숙도를 갖고 있기 때문이다. 이러한 성숙도를 갖춘 소프트웨어
컴포넌트는 쉽게 Open API 로 (RESTful 서비스나 웹서비스, XML 서비스
등으로) 노출시키기 쉽고 언제든지 동적인 바인딩 및 통합이 가능하고
프로세스 오케스트래이션과 같이 비즈니스 유저가 다루기에도 용이하도록
하는 활용 수준을 제공한다. 이는 조심스럽게 설계된 가이드라인 상에서
훌륭한 아키텍트의 손에서 컴포넌트들이 잘 정의되고 포장되어야 하는
과정을 거치기 때문에 이러한 과정을 거친 컴포넌트들을 사용할 수 있는
것은 개발자들에게는 큰 축복이며 해당 컴포넌트 개발을 맡은 아키텍트의
설계 능력수준에 따라 개발 비용 전체에 큰 차별화를 가져올 수 있다. 서비스
컴포넌트 포장 규약과 SOA 아키텍처 구현을 위해서는 웹서비스 플랫폼을
주로 떠올리게 되지만 그 특성상 잦은 호출이 빈번히 발생하는 워크로드를

28. 견뎌야 하거니와 최근에 모바일 및 IoT (Internet of Things)의 구현을 위하여
보다 가볍고 강력한 SOA 구현 플랫폼인 OSGi 을 사용하거나 좀더 낮은
Modularity 를 제공하지만 언어차원에서 RESTful 서비스를 지원하는 JAX-RS
혹은 Node.JS 등을 사용하기도 한다.
3.3.7. 인테그래이션 플랫폼 서비스
기존에 우리는 이미 많은 IT 에 대한 투자를 기존 시스템과 내부 호스팅
서비스를 통하여 제공해왔기 때문에 좋은 PaaS 제공자라고 자처한다면,
기존의 서비스나 시스템과 통합을 용이하게 해줄 의무가 있다. PaaS 벤더를
선택하기 전에 다음 몇 가지의 이러한 기존 애플리케이션에 대한 서포트를
어떻게 지원받을 수 있는지를 매우 신중히 검토할 필요가 있다:
● 애플리케이션은 우리 클라우드 서비스내의 애플리케이션들 필요에
따라 쉽게 화면, 서비스, 데이터가 통합될 수 있어야 한다. 이때
ACID 한 트랜잭션이 보장되거나 메시지 큐등을 통하여 연동이
보장되어야 한다.
● 또한 전혀 다른 네트워크 상에 존재하는 클라우드에서 제공하는
서비스나 서비스의 단위 화면과 서비스와도 연계될 수 있어야 한다.
● 이러한 서비스 통합은 가능한 ‘서비스-중심-아키텍처' 기반의 SOA
성숙도 모형에 근거하여 높은 수준을 제공할 수록 좋다.
이렇게 되게 하기 위하여 PaaS 제공자는 잘 문서화되거나 잘 정의된
인터페이스를 여러분께 제공해야 한다 다른 말로, 기존 애플리케이션과
클라우드 간의 통합의 중간에서의 API (애플리케이션 프로그래밍 인터페이스)
나 EAI (Enterprise Application Integration) 및 끊김 없는 프로세스 통합을
위한 BPM, Presentation Mashups 과 같은 서비스를 제공해야 한다.
3.3.8. 데이터베이스 서비스
애플리케이션 구현에 있어 가장 중요한 요소중 하나로 볼 수 있는 것이
데이터베이스이다. 이러한 테스팅은 주로 개발자에게 아주 대용량의 복잡한
데이터베이스를 운영 때 제공 해야 하는 시나리오 일 때 더욱 테스팅 환경은

29. 중요해진다. 개발자들은 종종 가벼운 데이터베이스를 자신의 개발환경에
코드를 테스트하고 위하여 설치해서 테스트하는데, 실제 프로덕션환경에서의
대용량 상황과 맞지 않기 때문에 충분한 테스트가 되지 못한다.
PaaS 의 환경의 중요한 장점 중 하나는 이러한 실제 운영환경의 용량을
테스트해볼 수 있는 개발기를 필요 할때 곧바로 구성해 준다는 것이다. 예를
들어 10 대의 클러스터된 MySQL 데이터베이스가 애플리케이션에서 사용될
예정이라면, 이러한 개발환경을 웹브라우저 상의 셀프서비스에서 명시해주는
것 만으로 이러한 샌드박스 환경이 구축되는 것이다.
3.3.9. 테스트와 자동화 도구
테스팅 서비스는 PaaS 플랫폼내에 포함되어 제공된다. 이러한 서비스는
UI 테스트와 로드 테스트 두가지를 포함하는데, 이러한 서비스는 모든
사이즈의 회사에 사용될 수 있다. 특히 중소기업에는 이러한 테스팅 도구
서비스의 지원이 매우 큰 임팩트를 줄 수 있는데, 이러한 중소기업들을 이를
구비하거나 구축 운영할 비용이 없는 경우가 많기 때문이다. 이러한 작은
팀들이 베스트프랙티스의 개발환경을 제공받을 수 있음은 동일한 사이즈의
경쟁자를 이길 수 있는 좋은 기반이 된다.
테스트 도구와 자동화 도구는 다음과 같은 것이 있다:
● Jenkins: 가장널리 사용되는 지속적 통합(CI) 서버중 하나이다.
소스코드를 내려 받아 Maven 을 호출하여 빌드를 수행하고 다양한
종류의 플러그인들을 통하여 테스트, 정적 코드 분석 등을 자동적으로
수행할 수 있다.
● Selenium: 여러 종류의 웹브라우저 상에서 UI 테스트를 자동화할 수
있다.
● Sonar: 코드의 품질에 대한 피드백을 자동화하여 보고한다.
3.3.10. 성능분석도구
개발자가 직접 로컬에 구성할 수 있는 개발환경에 있어서의 다양한 한계들
중에서도 아마 성능분석도구가 가장 큰 것 중 하나일 것이다. 프로덕션
프로파일링과 로드 테스팅 같은 성능 분석은 개발자가 직접 구비하기 가장
어려운 것 중 하나인 이유는 테스트를 위한 기계적, 네트워크적 구성 자체가

30. 크게 요구되기 때문이다. 이러한 목적으로 제공되는 클라우드 기반 도구들은
다음과 같은 것들이 있다:
● SOASTA: 클라우드 머신들의 클러스터를 구성하여 실제 사용자
로드를 생성하여 여러분의 애플리케이션을 테스트 할 수 있게 한다
(클라이언트 타입과 개수, 지리적 위치, 로드 패턴 등을 지정할 수
있다)
● New Relic: 엔드-유저의 행동, 서버 행위를 모니터링, 보틀넥을
찾아내는데 사용될 수 있다.
3.3.11. 개발에서 테스트 - 테스트에서 프로덕션을 위한 자동화 서비스
PaaS 제공자는 클라우드 애플리케이션의 업데이트를 서비스 운영에 방해
없이 제공하는 서비스를 제공한다. 예를 들면 새로운 버전의 서비스를
사용자가 이미 사용중인 서비스에 적용시켜야 하는 경우이다. PaaS 에서는
개발과 테스팅, 그리고 배포의 과정이 좀더 끊김 없이 제공되도록 하는데,
PaaS 는 좀더 서비스의 업-타임에 손실을 최소화하도록 한다.
이러한 관계가 좀더 디플로이에 있어서 예를 들면, 자바 웹 어플리케이션은
사용자의 정보를 담는 세션 스토어가 상태가 유지된 채로 실패상태나
업데이트간에 유지해 줄 수 있어야 하는데, PaaS 는 세션 스토어를 내장하여
자동으로 업데이트시에 이 데이터를 유지해준다.
4. Deployment 플랫폼으로의 PaaS
4.1. 애플리케이션을 클라우드로 디플로이 한다는 것은
일반적인 클라우드 리소스를 사용하고 인프라의 가용성을 가지게 하면
어플리케이션 디플로이와 운영을 매우 쉽게 해준다. 비용 효율성은 멀티태넌트
아키텍처상에서의 표준화된 서비스의 제공모델에 기인한다. PaaS 는 많은 관점의 IT
개발 부서가 해주던 고전적 환경에서의 디플로이 라이프사이클을 자동화 해준다:
● 리소스 할당

31. ● 스테이징과 테스팅
● 서버 클러스터 상의 노드 프로비져닝
● 애플리케이션 서버와 DB, 로드밸런서 설치, 설정, 보안처리
PaaS 운영 라이프사이클의 표준화 서비스의 의미는 디플로이와 운영의 일관성을
총체적으로 용이하게 한다. PaaS 환경에서 모든 핵심 배포 기능은 개발자에게서는
추상화되어 이러한 우아한? 기능들의 복잡성은 가려진다. 결과적으로 PaaS 는
애플리케이션의 업데이트 과정을 빠르고 효율적으로 제공한다.
PaaS 는 애플리케이션들을 상호 연결하는 책임도 진다. 서비스들간의 통합이 이미
이루어진 PaaS 의 특징이 이를 쉽게 한다.
4.2. PaaS 에서의 스테이징과 테스팅
PaaS 환경은 개발팀으로 하여간 훨씬 훌륭한 스테이징 환경 - 실제 운영전에 실제와
가깝거나 동일한 환경으로 테스트할 수 있는 환경 - 을 구축할 수 있도록 해준다.
고전적인 방식으로는 많은 비용과 동일화에 대한 시간이 소요되지만 IaaS 의 도움과
PaaS 의 자동화 덕분에 이러한 환경 구축이 용이하다. 이러한 기능은 개발자들로
하여금 IT 인프라이슈에 빠져있는 시간 보다 실제 엔드유저 들과의 미팅시간을
늘려주어 비즈니스 요구사항을 논의하는 시간을 늘려준다.
기본적으로 PaaS 를 기반하면 애플리케이션의 스테이징과 테스팅에 논리적이고
실제적인 접근을 할 수 있게 되는데, 다음과 같은 것들을 스테이징 환경에서 기대할
수 있게 된다:
● 실제 환경으로 대체시킬 수 있는 완전한 미러 환경
● 오류가 발견되었을시 곧바로 롤백시킬 수 있는 환경의 보유
4.3. PaaS 디플로이의 장점
PaaS 모델의 디플로이에 있어서의 다양한 장점은 멀티태넌트 클라우드 환경에서
얻어진다. 디플로이 팀은 많은 높은 품질의 어플리케이션 요구사항을 맞추는 것에
초점을 맞춘다. SaaS 애플리케이션에서 요구된 빠른 주기의 디플로이 모델을

32. 기반하였기 때문이다. 여러분의 IT 직원들이 새 버전의 어플리케이션을 어떻게 잘
(무정지, HA 구성등) 배포할지에 대한 고민을 하는 동안 비즈니스 요구사항에 좀더
집중할 수 있도록 해준다.
엔드-유저들이 SaaS 를 구매하는 경향들이 늘어남에 따라 PaaS 는 지속적으로
새로운 기능들을 제공하는 방식을 지원해야 한다. 이러한 PaaS 의 디플로이
기능으로서 도입함에 따른 장점은 아래와 같다:
● 사전에 구성되고 최적화된 런타임 환경의 즉시적 접근
● 애플리케이션 디플로이 프로세스의 단순화
● 고가용성, 확장성, 파이어월, 그리고 네트워킹 구성의 자동화
● 시스템 운영 비용 감소
때때로 이러한 설정, 설치, 디플로이의 용이성의 반면에 두려움이 있을 수 있는데,
이렇게 알아서 다 해줌으로써 여러분의 IT 환경은 PaaS 의 제공과 기능에 종속될 수
있다는 것이다. 예를 들어, 여러분의 PaaS 환경은 알아서 JBoss WAS 와 Java 를 기본
제공해주는데, 다른 WAS 나 요구사항이 정교해짐에 따라 모델 미들웨어 환경을
추가하고 싶다면 그 방법을 PaaS 벤더에게 고가의 서비스를 요청해야 하거나 혹은
불가능할 수도 있다는 것이다. 이러한 문제는, Open PaaS 의 요구와 접근이
생겨나게 된 배경이 된다. 여러분의 애플리케이션은 하나의 PaaS 에서 다른
PaaS 플랫폼으로 갈아 탈수 있는 Portability 와 필요하다면 자체적으로 확장할 수
있는 소스코드를 제공 해야 한다. 이러한 종속성의 폐해를 한번이라도 경험해본
조직이라면 왜 필자가 Open PaaS 를 여러 번 강조하는지 충분히 이해하리라
생각한다.
4.3.1. 지속적 딜리버리의 역할
스마트한 IT 조직은 개발과 디플로이는 생애주기 프로세스를 기반으로
운영되어야 함을 이해할 것이다.
지속적 딜리버리의 목적은 개발에서 프로덕션으로 이전 할 때에 높은 품질을
유지하면서, 운영되는 상태로, 이러한 이전의 시간을 줄이는 것이다. 그러려면,
새롭게 개발된 코드는 빠르게 통합테스트 될 수 있어야 하고, 예측되지 못한

33. 이슈는 곧바로 보고될 수 있어야 한다. 이러한 장점을 기반으로 경쟁적
우위를 항상 점할 수 있도록 PaaS 는 여러 기능을 제공해야 하는데 여러분의
PaaS 제공자들은 다음과 같은 질문에 대응할 수 있어야 한다:
● PaaS 를 통하여 어떻게 CI 기능과 ALM 을 제공할 것인가?
● 우리의 웹 어플리케이션을 어떻게 Auto Scale out/in 할 것이고 HA
속성을 제공할 것인가?
● 물리서버중 하나가 다운된다면, 어떻게 엔드-유저가 방해 받지 않고
서비스를 일관성 있게 사용할 수 있게 해 줄 것인가?
● 장애복구(Disaster Recovery)플랜은 어떻게 되나? 우리의 지역에서의
서비스가 장애가 발생하여 다른 지역으로 이러한 서비스를 옮겨야 할
경우 어떻게 Mobility 를 제공할 수 있나?
● 어떻게 우리 회사가 선호하는 개발 프레임워크를 탑재시킬 수 있는 가.
자체의 프레임워크를 갖고 있을 텐데 이를 변경할 수 있는가?
● 운영과 디플로이 등의 프로세스를 우리 기업의 속성에 맞게 프로세스
체인지를 쉽게 할 수 있는가?
4.4. 모니터링과 노티 서비스
엔드유저의 생산성에 영향을 미치는 모든 관점의 PaaS 환경은 모니터링 될 필요가
있다. 대부분 PaaS 제공자는 PaaS 상에서 제공되는 서비스의 퍼포먼스를 볼 수 있는
대시보드를 제공할 것이다 이 도구를 통하여 SLA 에 기반한 서비스의 상태를 볼 수
있도록 제공해 줄거다. 하이브리드 환경에서 대시보드 환경에서도 하나의 관점으로
모든 자원들을 통합관제 할 수 있어야 할 것이다.
보안이슈는 가장 높은 수준의 이슈가 될 수 있다. 여러분의 실행환경은 매우 보안에
민감하게 설계되어야 하고, 외부 공격에 방어할 수 있도록 문제가 인식되면
운영자에게 알림이 자동화되어야 하고, 이를 조치하기 위한 프로세스가 고안되어야
한다.

34. 5. 플랫폼 비즈니스 모델 구현체로서의 PaaS
최근 IT 용어 중 가장 심심치 않게 등장하는 용어 중 하나가 ‘플랫폼’ 일 것이다. 또한
플랫폼은 PaaS 의 첫 두문자에 사용된 용어이기도 하다. 사실 PaaS 를 SaaS 개발과 운용을
위한 클라우드 서비스로만 단정 짓는 것은 PaaS 의 일부 단면 만을 조명한 것에 불과하다.
잘 설계된 PaaS 는 애플, 구글, 아마존, 아니 고전적으로는 나이키, 닌텐도, 심지어 스타벅스
커피가 구사했던 ‘프로슈머', ‘앱스토어', ‘디지털 마케팅 도구’, ‘셀프서비스’와 같은 잘 알려진
‘플랫폼 비즈니스 모델'을 곧 바로 구사할 수 있고, 이를 위한 다양한 프로세스와 도구들을
내장 하고 있다.
5.1. 플랫폼 비즈니스 모델이란?
하바드 비즈니스 리뷰에서 Sangeet Paul Choudary 는 ‘파이프 모델에서 플랫폼
모델로의 전환' - 이라는 말로 풀이되는 기존의 선형적 비즈니스 모델에서
네트워크를 기반으로 하는 플랫폼 비즈니스 모델의 전환기를 언급했다. 파이프
모델에서는 고객에게 제품을 만들어서 밀어내면 된다. 가치가 생산자에게서
창조되어 고객에게로 흘러내려가 소비되는 모델이다. 그런데 이러한 파이프 모델과
달리 플랫폼 모델에서는 고객을 포함한 모든 시장 참여자들이 참여하여 가치를
만들고 소비하는 주체가 된다. 즉, 기존에 Seller 와 Buyer 만 존재했던 Market 의
시대와 달리 Platform Provider, Developer, Publisher, Marketer, AD Player, User 등이
서로 Interaction 하는 플랫폼의 시대는 새로운 기회와 가치를 만들어 주었기
때문이다.
플랫폼 비즈니스모델은 21 세세기의 웹 2.0 - 집단지성, 네트워크 효과, 사용자 저작
콘텐츠, 등의 자가발전하는 시스템으로 인한 비즈니스 모델로 발전하였다. 항공,
교통, 유통, 호텔, 음식점, 그리고 정보 통신 기술과 온라인 게임과 같은 산업들이 웹
2.0 의 특징을 잘 살려 비즈니스 모델에 접목되고 있고 ‘네트워크 효과’를 내고 있다.
모바일 시대가 오면서 기업들은 C(콘텐츠, Contents)-P(플랫폼, Platform)-N(네트워크,
Network)-T(단말, Terminal) 중심의 수직통합 전략을 강화하고 있다.
계속적으로 통합되면서도 특성화되어 발전하고 있는 플랫폼 비즈니스 모델을
구사하는 데는 많은 비즈니스 지원 서비스들을 플랫폼 제공자가 직접 구현해야 하게

35. 만든다. 물론 자사의 특수한 비즈니스 모델을 최적화 하기 위해서는 이러한 서비스를
직접 구현해야 하겠지만 절정의 PaaS 소프트웨어는 이러한 플랫폼 비즈니스 지원
서비스를 쉽게 커스터마이징 할 수 있는 방식 (예를 들면 BPM 기반의 운영 프로세스
유연성을 보유한 PaaS) 포함하여 제공된다.
5.2. 플랫폼 비즈니스 모델을 위한 PaaS 의 구성 요소들
PaaS 에서는 플랫폼 비즈니스 모델을 구사할 수 있도록 하기 위하여 다음과 같은
제공자, 소비자, 운영자를 위한 셀프서비스 포탈과 앱 스토어, 그리고 마케팅
도구들을 제공한다.
● 앱스토어 - 앱스토어는 기본적인 장터를 제공하여 제공자와 소비자가 플랫폼
상에서 애플리케이션을 제공하고 구매할 수 있는 마켓 플레이스를 제공한다.
구글의 Apps Marketplace, 세일즈포스닷컴의 AppExchange 가 이에
해당한다. 앱스토어를 프라이빗 클라우드로 구축하면 자사내의 정보화
서비스 자산을 효율적이게 관리할 수 있다는 측면에서도 활용 가능하다.
이후에 소개된 KIAT R&D 프로젝트에서는 오픈 PaaS 플랫폼인 OCE 의
앱스토어를 활용하여 내부 서비스를 일원화하여 관리하고 각 소비자가
셀프서비스로 자체 애플리케이션을 사용하고 앱의 수정사항이 있을 경우
이를 요청할 수 있도록 구축되었다.
● 제공자 포탈 - 제공자 포탈에서는 플랫폼의 기반 서비스와 컴포넌트를
기반하여 개발을 위한 라이프사이클을 제공한다. 이 외에 개발된
애플리케이션에 대한 광고를 위한 광고글, 스크린샷, 동영상 등을 게시하는
기능, 과금과 결제를 위한 사용자 사용량 검침 기능 등의 서비스 판매에 대한
다양한 셀프서비스 기능을 제공한다.
● 디지털 마케팅 도구 - 구글의 구글앱엔진으로 올려진 애플리케이션은 구글의
Ad-sense 서비스를 통하여 광고, 마케팅, 캠패인 결과의 분석 등을 할 수
있도록 통합되어 제공된다.
● 사용자 포탈 - 사용자는 자신이 사용할 애플리케이션을 자신 조직의
요구사항에 맞게 셀프서비스로 커스터마이징 할 수 있는 기능, 조직도를
구성하는 기능, 사용량의 한도를 설정하는 기능 등이 제공된다. 특히
멀티태넌트로 제공되는 애플리케이션의 경우 사용자 별 브랜드,

36. 워크플로우(업무 프로세스), 비즈니스 규칙 등이 상이 하기 때문에 이를 위한
사용자 셀프서비스는 제공자가 일일이 작은 단위의 사용자를 위하여 별도의
코드베이스로 구현해줄 수 없기 때문에 (없기도 하거니와, 플랫폼의 규모의
경제를 낼 수 없게 됨) 사용자가 알아서 적절히 자신의 필요성에 맞춤화 하는
기능이 필요하다.
IBM 의 클라우드 도입 로드맵에서는 운영지원서비스 뿐만 아니라 비즈니스 운영을 위한
서비스의 즉, 플랫폼 전체 참여자를 위한 서비스의 비중을 높게 보고 있다.
5.3. PaaS 를 특화 영역에 구체화한 플랫폼 서비스들의 예시
● Mobile 개발을 위한 PaaS - KT BaaS.io ( Backend As A Service)
● 게임개발에 특화된 PaaS - Play My Code
● 전자정부용 PaaS
● 협회, 단체의 공동 비용 감축을 위한 PaaS - 제조생산시스템 PaaS,
중소기업용 PaaS

37. ● 그밖에 생각해 볼 수 있는 X-PaaS 들: Big Data PaaS, IoT PaaS
이러한 플랫폼 비즈니스 모델은 앞서 언급한 CPNT 모델 중에서 Platform 을 둘러싼 나머지
자원을 하나 이상 지대하게 보유한 자가 자신의 플랫폼 비즈니스 모델을 완성하기 위한
퍼즐 블록으로 활용할 수 있을 것이다. 예를 들어 기존에 많은 게임 소프트웨어 콘텐츠를
보유한 기업은 Game PaaS 를, 기존에 방대한 IaaS 환경과 네트워크를 갖춘 기업은 자체
퍼블릭 PaaS 를 구축할 수 있을 것이다. 많은 공공 서비스를 클라우드 화 하는데 미션을
가지고 있는 미국 GSA 는 최근 IaaS 도입을 넘어 PaaS 를 공공서비스의 효율적 제공 모델로
고려하고 있다. 플랫폼을 가진자가 디지털 경제의 영토를 차지하게 된다고 하도 떠들어
대니, 이러한 ‘힘’과 ‘전략'을 가진 기업이나 정부는 PaaS 를 하나의 경제 성장의 돌파구로
생각해 볼 만 하다.
6. PaaS 도입시 검토사항과 적용로드맵
이상으로 PaaS 의 기본적인 개념에서 부터 큰 제공 기능들과 비즈니스 가치들에 대하여
소개하였다. 이처럼 많은 것을 대신해주는 PaaS 를 도입하는 것은 그 기능성에서 주는 것과
같이 세심하고 폭넓은 검토과정 그리고 단계적 적용 로드맵을 갖고 접근해야 할 것이다.
다음은 필자가 구할 수 있는 몇 가지 PaaS 도입에 대한 가이드라인을 정리해 보았다.
6.1. ‘PaaS for Dummies’ 도서 에서의 권고
쉽게 쓰여지기로 유명한 IT 전문서적 ‘~ for Dummies’ 시리즈 (바보들을 위한 ~;
독자 여러분들은 절대 바보가 아님을 일러둡니다. 그만큼 쉽게 쓰여졌다는 의미로
받아들이시면 되겠습니다) 에서 발췌한 PaaS 도입 가이드라인이다.
6.1.1. Step1: 현재의 컴퓨팅 환경에 대한 핸들을 쥐기
미래 계획을 세우기 위해서는 과거와 현재의 상태를 먼저 이해해야 한다.
다음과 같은 질문을 자신에게 해본다:
● 어떤 유형의 컴퓨팅 환경을 운용 중인가
● 현재의 비즈니스 니드를 어떻게 반영하고, 얼마나 잘 그 변화를
서포트하고 있는가?

38. ● 어떤 비즈니스를 수행 중인가?
● 고객과 파트너에게 서비스를 판매하기 위하여 어떤 위치에 있는가?
● 빠르게 변화할 수 있는 구조를 갖고 있는가?
이러한 자신(기업)에 대한 이해를 통하여 미래 구상을 할 수 있게 된다.
6.1.2. Step 2: PaaS 의 가치에 대하여 조직적으로 이해시키기
만약 PaaS 도입을 고려 중이라면, 기본적인 클라우드 컴퓨팅에 대한 경험을
갖고 있을 것이다. 그러나 당신은 클라우드 전환에 있어서 지금 준비가 된
상태일 것인데, 보다 당신의 조직을 경쟁우위에 있도록 만들고 싶을 거다.
IaaS 환경을 도입해서 바로 도구도 구매하고 바로 시작해보고 싶을 거다.
하지만 그러한 점프를 하기 전에 다음의 단계들을 점검해보라:
● 클라우드 도입 옵션 - 퍼블릭/프라이빗/하이브리드 - 들에 대하여
먼저 학습하라
● PaaS 벤더가 제공하는 내용에 대하여 익숙해져라
● 각 플랫폼이 어떻게 동작하는지를 파악하고 어떤 스킬 들을 학습해야
하는지 이해하라
6.1.3. Step 3: 옵션들을 기반으로 실험해보기
대부분의 회사들을 PaaS 에 대하여 직접적인 경험을 갖고 있지 않다. 그리고
어떠한 단점이나 예외사항들에 대한 지식 없이 의사결정을 할 것이다.
클라우드 모델의 이점 중 하나는 상업적인 제품을 비용을 들이지 않고
시험해볼 수 있다는 것이다. 많은 벤더들은 개발자들이 먼저 실험을 해볼 수
있는 샌드박스나 테스트 드라이브 등을 제공하므로 이러한 시범 서비스를
충분히 사용 해볼만하다.
예를 들어 어떤 PaaS 는 특정 SaaS 에 묶여있을 수 있는데, 이러한
SaaS 서비스가 여러분 고객관리에 좋은 선택이라면 괜찮겠지만 그게 아니라

39. SaaS 와 PaaS 를 분리하고 싶다면 다른 종속적이지 않은 Open PaaS 같은
것들을 검토해야 할 것이다.
6.1.4. Step 4: 어떤 요구사항이 있는지 확인하라
발생할 수 있는 요구사항들을 도출하라
● 어떤 프로그래밍 언어를 많이 사용하는가
● 어느 정도 수준의 추상화를 원하는가
● 플랫폼이 대부분의 기계적 개발과 디플로이 작업을 대신해 줄텐데,
어느 수준까지 자동화되기를 원하는가
● 어떤 미들웨어가 기존에 사용되고 있고 향후 필요한가?
● 다른 퍼블릭 혹은 프라이빗 클라우드와 어떤 연동 관계가 필요한가?
이러한 질문을 던지게 되면 자연스레 제품선정에 필요한 답을 얻게 될
것이다.
6.1.5. Step 5: 평가팀을 구성
PaaS 환경은 여러분 개발조직에 매우 지대한 변화를 줄 것이기 때문에
담당자 혼자 의사결정 할 수 있는 사안이 아니다. PaaS 환경은 많은 비즈니스
가치사슬에 영향을 주기 때문에 관계된 모든 이해관계자들 - 개발, OA, 운영
- 들이 모여서 의사결정을 해야 한다.
6.1.6. Step 6: 파일럿 수행
개발과 운영팀에 어떻게 좋은 영향을 줄 수 있는지를 검증하기 위한 작은
프로젝트를 실시한다. 이 과정 동안 몇 가지 다른 PaaS 제품들을 동시에
적용해보면서 벤치마킹 / 비교해보는 것도 좋은 방법이다.
6.1.7. Step 7: 조직 구성하기

40. 기술은 그것을 받아들일 조직이 얼마나 잘 준비되었느냐 따라 그 효과가
결정 난다. 변화는 어렵고 많은 개발자와 운영자들을 새로운 접근에 대하여
저항을 일으킬 수 있다. 팀을 지속적으로 교육시키고 PaaS 의 이점에 대하여
설득하는 과정이 필요하다. (많은 IT 전문가들이 오래되고 잘못된 클라우드
기술과 지식에 사로잡혀있을 수 있다. PaaS 는 이러한 IT 전문가들이 이러한
잡다한 기술에 얽매어 있기 보다 비즈니스 자체를 지원하는데 좀더
효율적으로 배치될 수 있게 해준다)
6.1.8. Step 8: 새롭게 개발되는 표준들에 지속적으로 검증하기
클라우드 컴퓨팅을 적요한 후에 회사는 지속적으로 성장하기 때문에 새로운
표준과 베스트 프랙티스 들을 지속적으로 검토 해야 한다.
6.1.9. Step 9: 개발/디플로이 사이클의 지속성을 보유하기
PaaS 환경에 한번 개발과 디플로이를 해놨다고 해서 끝이 아님을 성공적인
회사들은 잘 알고 있다. 어플리케이션들은 갈수록 다이내믹해진다. 클라우드
기반 애플리케이션들을 최신의 혁신을 받아들여 지속적으로 업데이트 된다.
6.2. IBM 의 클라우드 도입 가이드라인
IBM 의 클라우드 도입 가이드라인은 PaaS 자체의 도입 가이드라인에 집중되어
쓰여지지는 않았지만 도입하고자 하는 조직의 규모와 요구사항에 따라 어떤 도입
절차를 가져야 하는지를 한눈에 볼 수 있는 비쥬얼 로드맵 프레임워크를 개발하였다.
다음은 IBM 클라우드 도입 프레임워크의 원문에서 발췌한 내용이다:
조직의 IT 전략, 조직 에서 선택한 제공 모델 및 제공되는 서비스뿐만 아니라, 클라
우드 환경으로의 마이그레이션을 추진하는 조직이 IT 조직인 지 비즈니스 조직인지
여부에 따라 클라우드 구현의 경로가 달라진다.
대기업에서는, 강력한 후원 조직이 클라우드 프로젝트를 추진하는 경우, 일반적으로
클라우드 도입 목적은 새로운 비즈니스 기회 또는 비즈니스 해결 과제로부터

41. 시작된다. 리소스 확보에 절감이 비즈니스 타당성의 근거가 될 수도 있지만, 보다
비즈니스 이점과 가치 실현 시간의 단축이 중심 화두가 될 가능성이 높다. 서비스
유형은 좀더 더 높은 수준의 요구상에 있을 것이며, 일반적으로 애플리케이션 또는
비즈니스 프로세스 클라우드 서비스가 될 수 있다.
반대로, IT 를 주성장 동력으로 하는 대규모 기업에서는 더욱 동적으로 서비스를
제공하기 위한 인프라 최적화의 필요성과 더불어, 기존 인프라 활용도를 높임으로써
자본 비용을 줄여야 하는 필요성이 더 높다. 이 경우는 클라우드 구현이 인프라
수준의 탐색 프라이빗 클라우드 프로젝트에서 시작되어 기술을 확보함에 따라
스택의 더 높은 계층으로 이동할 것이다. 프라이빗 클라우드 구현부터 시작하면 IT
조직은 웹 컨퍼런 스 또는 테스트 환경 등, 적용하고자 하는 워크로드를 퍼블릭
클라우드로 이동하기 전에 프라이빗클라우드 구현 및 적용부 터 시작하여 클라우드
기능에 대한 이해를 높일 수 있다.
중간규모의 기업에서는 자본비용과 운영비용을 모두 줄이고 필요한 내부 IT 기술의
수준과 복잡도를 줄이기 위해 기본 적인 IT 업무 부담을 낮춰야 하는 필요성에 따라
클라우드로 가는길이 결정 될 수 있다.
그보다 규모가 더 작은 회사들은 주로 퍼블릭 클라우드 공급자가 제공하는 비즈니스
프로세스 서비스를 활용하여 IT 및 비즈니스 프로세스 제공 기술에 대한 요건들을
줄일 수 있다.

42. IBM 의 클라우드 도입 프레임워크는 클라우드 도입 규모별 목적별로 최적의 도입 패스를
가시화하고 있다. 여기서 PaaS 와 IaaS 는 동시에 구축하는 경향으로, 규모와 관계없이
종국에는 결국 BPM As A Service (혹은 CSB) 를 활용하게 되는 로드맵을 제시하고 있다.
7. 사례 연구: KIAT R&D 클라우드의 국산 Open PaaS 도입
산업통상자원부 산하의 한국산업기술진흥원 (KIAT) 를 비롯한 3 개 연구개발(R&D)기관은
지난 2013 년 6 월 공개소프트웨어(SW) 기반 클라우드 플랫폼을 구축했다. 본 사업의
시사점은 순수 국내 중견·중소기업이 국산 기술을 적용해 성공적으로 사업을 마무리했다는
것인데, 그 구축 내용 중에는 구산 오픈 PaaS 플랫폼인 OCE 가 포함되어 있어 PaaS 도입의
사례연구로 적합하다.
7.1. KIAT 의 도전

43. KIAT 의 클라우드 시범 풀은 서버나 스토리지 등 IT 하드웨어와 소프트웨어 자원을
KEIT, KIAT, KETEP 의 3 개 기관이 필요한 만큼 스마트폰이나 PC, 태블릿 PC 등
다양한 단말기에서 이용할 수 있도록 하는 시스템으로 기획되었다. 예를들어 KIAT 에
업무가 집중될 때에는 클라우드 IT 자원을 KIAT 에 대폭 할당하고, 상대적으로 업무
집중도가 낮은 다른 기관에는 적게 할당하여 IT 자원 사용효율을 극대화 하는 것이다.
또한 표준프레임워크 기반의 PaaS 플랫폼을 지원하도록 기획되어 4 개 임차기관이
사용할 애플리케이션을 언제든지 개발하여 앱스토어에서 사용할 수 있도록 하자는
것이다.
KIAT 클라우드 플랫폼 개념도
7.2. 솔루션
KIAT 의 요건은 크게 IaaS 기반의 자원공유 환경을 만들고 그 위에서 자유롭게
애플리케이션을 표준기반, 오픈소스 기반으로 향후 벤더 종속의 염려가 없는 공개
PaaS 구축, 그리고 그 상에서 운영될 수 있는 문서관리시스템을 포함한 몇 가지
대표적 SaaS 애플리케이션을 탑재하는 것이다. 이를 위하여 KIAT 에는 국산 오픈소스
PaaS 플랫폼인 OCE ( Open Cloud Engine )가 적용되었다.

44. KIAT 에서 구축한 R&D PaaS 의 사용자는 OCE 가 제공하는 소프트웨어 개발
생명주기에 참여하는 액터인 개발자, 가입자, 운영자로 구성되었다. 개발환경
구축부터 앱스토어를 통한 소프트웨어 배포까지 PaaS 생태계의 모든 사이클을
지원하며 소비자가 필요한 경우 자체 어플리케이션의 비즈니스 양식, 프로세스,
규칙등을 셀프서비스할 수 있도록 BPaaS 의 특성을 갖추었다. PaaS 와 IaaS 가
연동된 방식은 Apache Delta Cloud 기반 표준 인터페이스로 제공하고,
표준프레임워크의 지원과 BPMN 과 같은 표준을 준수하여 이후 생산된
애플리케이션의 이동성이 보장된다.
KIAT R&D PaaS 의 주 사용자와 제공 도구
이러한 클라우드 시범 풀은 오픈스택의 다종 IaaS 나 큐브리드 DBMS, JBoss WAS,
uEngine 의 BPM 프로세스 엔진 등 여러 국내산 / 외산 오픈소스 기반 구성 요소들을
통하여 구성되어 있습니다.

45. KIAT 구축 사례: OCE 의 PaaS 아키텍쳐
7.3. 도입효과
KIAT 는 성공리에 구축된 오픈 클라우드 엔진 기반의 클라우드 시범 풀 구축을
통하여 IT 운영 부서와 IT 개발 부서 모두 적용 효과를 볼 수 있게 되었다.
이번 사업으로 신규 시스템을 구축할 때 필요한 자원을 공용 클라우드 인프라에서
유연하게 제공받을 수 있게 됐다.
SW 개발자는 웹 포털 기반 가상개발 환경으로 애플리케이션(앱)을 개발·테스트하고
제품을 앱스토어에 올릴 수 있다. 사용자는 앱스토어에서 필요한 앱을 내려 받아
사용하고 개발자에게 피드백을 남겨 개선을 요청할 수 있다.
종전 각종 SW 설치·설정 후 앱 개발환경을 구축하는 방식보다 비용이 적게 든다.
업무효율 제고에도 유리하다. 기업 내에서 부서마다 비슷한 앱을 각자 개발해
비용·시간을 낭비하는 문제를 해결할 수 있다.

46. KIAT 는 클라우드 시범 풀 구축을 통하여 기관별 서버와 PC 구매비가 평균 20% (약
1 억원) 가량 절감되는 효과가 있을 것으로 전망되며, NT 서버 53 대를 클라우드로
구축하게 되며 연간 30 만 kW 의 전력 소비 또한 절감할 수 있을 것으로 예상하고
있다.
KIAT 구축 사례: 클라우드 시범 풀 적용 효과
8. 결론
많은 기업들이 IT 자원의 효율적 관리와 공유를 목적으로 IaaS 구축을 하고 있다. 그러나
IaaS 에서 제공해주는 물리적 효율성을 넘어 미들웨어, 소프트웨어 컴포넌트, 생명주기 관리,
지속적 제공(Delivery) 등의 복잡한 개발과 운영에 대한 인건비적 비용은 여전히 남아있다.
이를 하나로 패키징하여 대신 처리해주는 것이 PaaS 이다. PaaS 는 그만큼 많은 일을
대신해주기 때문에 벤더 종속성이 가장 우려되는 클라우드 서비스이다. 서버는 쉽게 갈아탈
수 있으나 플랫폼은 쉽게 갈아타기 힘들기 때문이다. 때문에 어떤 PaaS 플랫폼을 어떻게

47. 도입할 것인가는 매우 중요하며 또한 어떤 표준성과 오픈 된 철학으로 개발되었느냐는
중요한 선택의 기준이 된다.
도입하고자 하는 조직이 자신의 도입의 요건이 비용절감인지 비즈니스 우위 선점인지를
판단 하는 것과 기존 시스템의 상황, 보유 기술 인력의 상황 등을 충분히 검토해본 후에
어떻게 PaaS 를 디플로이할 것 인지와 도입을 어떤 순서로 진행 할 지의 계획을 세워야 한다.
요즘 플랫폼 비즈니스는 하루하루가 다른것 같다. 오늘날 디지털 경제 영토는
구글·아마존·애플·페이스북 등 미국 거대 기업들이 독점한 텃밭이 됐고 이런 구조는 갈수록
견고해지고 있다. 인터넷이 미국에 경제적·전략적 이익을 몰아주는 상황에 유럽을 비롯한
세계의 국가들은 거의 무방비 상태다. 우리나라도 마찬가지다. 이러한 상황에서 지리적
특성이나 프라이빗 클라우드와 B-PaaS 시장의 성장 등에 발맞추어 틈새시장을 공략하는 발
빠른 전략이 필요하다. 그러한 시도가 없으면 거대 플랫폼에 록-인 되어 어떤 힘도 써보지
못하고 어떤 비즈니스 아이디어도 종속된 디지털 영토 내에서 구현되어야 할 것이다.
필자는 국내 오픈소스 기업들이 뭉쳐 개발하는 오픈 PaaS 인 OCE 를 직접 참여하여
개발하고 있는 입장이기도 하다. 국내 개발자들이 외산 플랫폼 위에 단순히 종속된 서비스
개발과 유통에만 집중할 것이 아니라 시장에서 의미를 가질만한 특화된 서비스와 비즈니스
모델을 연구하고 시도하여 새로운 플랫폼을 구현하는 시도들이 많이 있었으면 한다.
클라우드 기반 개발도구인 구름 IDE 와 플라밍고 Big Data PaaS, Netra IaaS Orchestrator,
올챙이 클라우드 DB 클라이언트 같은 시도들의 등장은 이러한 가능성을 보여준다. 앞으로
이러한 플랫폼 서비스들이 많이 등장하고 이를 기반한 국내 대기업을 비롯한 중소 SI 기업의
구축 서비스 참여, 재판매, 컨설팅 시장이 크게 형성되기를 기원한다.
9. 참고문헌
[1] Forrester Research, “The Forrester WaveTM: Platform-As-A-Service For Vendor
Strategy, Professionals, Q2 2011”
[2] 박준성, “SaaS 에 대한 소고”, 클라우드 기술 보고서 - 제 1 호, 2013
[3] Hurwitz 외, “Platform As A Service for Dummies”, John wiley & Sons

48. [4] IBM, “클라우드 컴퓨팅 도입을 위한 프레임워크 정의”
[5] IBM, “올바른 클라우드 컴퓨팅 구축 방법”
[6] 오픈 클라우드 엔진, http://www.opence.org