최종연구보고서 KISA-WP-2010-0043

클라우드 서비스 적용

가능 분야별 환경분석

및 정책방향 연구Research on the Environment Analysis of Cloud

Services and Policy Direction

수 탁 기 관 : 동 국 대 학 교

2010.11

제 출 문

한국인터넷진흥원 원장 귀하

본 보고서를 “클라우드 서비스 용 가능 분야별 환경분석

정책방향 연구”의 최종연구개발 결과보고서로 제출합니다.

2010년 11월 14일

수탁 기 : 동국 학교 산학 력단

연구책임자 : 김양우(동국 학교 정보통신공학과)참여연구원 : 이승하(동국 학교 정보통신공학과)

김 호(동국 학교 정보통신공학과) 이하나(동국 학교 정보통신공학과) 조성환(동국 학교 정보통신공학과) 김태형(동국 학교 정보통신공학과)

- i -

요 약 문

1. 연구 방향의 선정

본 보고서는 “클라우드 서비스 용 가능 분야별 환경분석 정책방

향 연구” 과제의 최종보고서로서 본 과제에서는 각종 다양한 클라우드

서비스들의 구 실행 환경을 유형별로 분석하여 클라우드 련 시범

사업을 주 하는 인터넷진흥원의 과제도출 정책방향에 기여를 하자는

목 을 갖는다. 이에 따라 본 연구의 방향을 설정하기 하여 많은 자료 수집과 내외

부의 문가들과 많은 토의를 실시한 결과, 의 연구목 에 가장 잘 부

합하고 국제 표 화 문서로 최근에 등록되어 있는 “Cloud Computing Use Cases White Paper” 문서를 번역하여 1차 으로 본 연구에서 활용

하고 이후 국내 다른 연구 개발자들을 하여 보 을 확산시킨다면 국내

클라우드 산업 활성화에 많은 기여를 할 수 있다는 결론을 도출하 다.

2. 보고서의 구성

본 연구 보고서는 크게 ‘1장: 클라우드 서비스 용 가능 분야별 환

경분석’과 ‘2장: 시범사업 련 정책방향’, 그리고 ‘3장: 클라우드

산업 활성화를 한 정책방향’ 등 3 부분으로 구성되어 있다. 제1장에

서는 클라우드 응용서비스의 유즈 이스 분석을 통한 기술 인 이슈들과

그들 사이의 연 성 분석, 그리고 보안상의 기술 요구사항들과 서비스

수 약(Service Level Agreement)이 포함되도록 하 고, 이후 제2장에

- ii -

서는 시범사업 아이템 (2개)의 개발과 그들의 필요성, 당 성, 각 아이템

분야의 시장 기술 동향, 그리고 추진 략 등이 포함되도록 하 고, 마지막으로 제3장에서는 클라우드 서비스 산업의 활성화를 한 법/제도

에서의 주요 이슈들에 한 정책방향이 포함되었다.

3. 연구결과의 활용방안

본 연구의 결과물 하나인 번역된 클라우드 컴퓨 유즈 이스 백서

는 그 내용의 요성을 고려할 때 본 연구에서의 활용은 물론, TTA PG420 클라우드분과를 통해 국내표 으로 등록할 것이고, 이와 더불어

재 백서의 원본과 함께 각국의 언어로 번역본들이 등록되고 있는데, 거기에 한 버 으로 등록하여 국내외 다른 연구자들을 한 기여를 할

수 있을 것으로 기 한다. 한 제2장에 포함된 시범사업 아이템 2개는

클라우드 시범 사업을 주 하는 인터넷진흥원에 실질 인 도움이 될 수

있는 내용으로 추후 시범 사업을 추진할 때 많은 도움이 될 것이며, 제3장의 법/제도 에서의 정책방향 역시 클라우드 서비스 활성화를

한 제도 측면에서의 환경을 구축하는데 기여를 할 수 있을 것이다.

- iii -

SUMMARY

1. Title

Research on the Environment Analysis of Cloud Services and Policy

Direction

2. Purpose of the study

This document is the KISA"s final report on the project called

"Research on the Environment Analysis of Cloud Services and Policy

Direction". The project is to analyze various Cloud services based on

service types and development environments so that it can be used to

generate other Cloud service projects by KISA as well as their policy

direction.

In order to satisfy the above object, we gathered and studied many

informational documents and also surveyed many experts. Then we

came to a conclusion that translating then spreading the recent

international standard document called "Cloud computing use cases,

white paper" would be the best way to satisfy the object. The

translated document is to be used in this research and it is also

expected to make contribution on the development of Cloud industry.

3. Contents and scope

This research report consists of three parts. The first chapter will be

- iv -

focused on applicable Cloud service types and their environment

analysis. The second chapter will be focused on Cloud project case

studies that can be used by KISA and the third chapter is about

policy direction to activate Cloud industry. The 1st chapter includes

technical issues and their relationship among them by analyzing

application service use cases, security issues, and finally service level

agreement. In chapter two, we developed two Cloud service project

items, and their needs, market trends, technical trends, as well as

strategic directions for each item. In chapter three, we included policy

direction and issues on legislative regulations for Cloud computing

industry activation.

4. Results of the study

Registered domestic Korean standard, translated version of 'Cloud

computing use cases, white paper' version 4 and its upload at

http://www.opencloudmanifesto.org/, as well as technical papers on

international conferences will be the results of this studies. Moreover,

two Cloud service project items and its details that can be used by

KISA as well as the policy direction and issues on legislative

regulations for Cloud computing industry will also be included.

5. Expected effects and applications

Using the domestic standard and the translated document are

expected to promote Cloud computing industries. The Cloud service

project items as well as the policy directions and issues on legislative

regulation are expected to be used by KISA for Cloud computing

industry development.

- v -

<목 차>

제 1 장 클라우드 서비스 용 가능 분야별 환경분석

제 1 서론 ····················································································· 1

제 2 정의와 분류 ······································································· 2 1. 클라우드 컴퓨 개념의 정의 ············································2 2. 분류(taxonomy) ····································································8 3. 표 과 분류 간의 계 ······················································12 4. 애 리 이션 로그래 인터페이스 (APIs) ···············14 제 3 유즈 이스 시나리오 ·····················································18 1. 최종 사용자와 클라우드 간 ··············································20 2. 기업과 클라우드 그리고 최종 사용자 간 ························21

3. 기업과 클라우드 간 ······························································24

4. 기업과 클라우드 그리고 기업 간 ······································26

5. 라이빗(private) 클라우드 ···············································28

6. 클라우드 벤더 교체 ······························································29

7. 하이 리드 클라우드 ····························································33

8. 상호참조: 요구사항들과 유즈 이스 ·································35

제 4 고객 시나리오 ···································································37

1. 고객 시나리오: 클라우드에서의 여처리 ·······················37

2. 고객 시나리오: 클라우드에서의 로젝트 리 ·············39

3. 고객 시나리오: 클라우드에서의 앙 정부 서비스 ·······42

4. 고객 시나리오: 하이 리드 클라우드에서의 지방 정부

서비스 ························································································43

5. 고객 시나리오: 천문 데이터 처리 ·····································45

제 5 개발자 요구사항 ·······························································47

- vi -

제 6 보안 시나리오 ···································································50

1. 규정 (regulation) ··································································51

2. 보안 제어 ················································································52

3. 보안 통합(federation) 패턴 ················································54

제 7 보안 유즈 이스 시나리오 ·············································56

1. 클라우드에서의 컴퓨 워 ··············································56

2. 클라우드 기반 개발과 테스 ············································58

3. 클라우드에서의 장공간 ····················································60

4. 상호참조: 보안 제어와 고객 시나리오 ·····························62

5. 상호참조: 보안 통합 패턴과 고객 시나리오 ···················63

제 8 서비스 수 약서(SLAs) ···········································64

1. 서비스 수 약(SLA)이란 무엇인가? ··························65

2. 서비스 수 목표 ··································································66

3. 서비스 수 리 ··································································67

4. SLA에 한 고려사항들 ······················································67

5. SLA 요구사항 ········································································72

6. 신뢰성에 한 언 ······························································77

7. 상호참조: SLA 요구사항들과 클라우드 제공 모델 ·······78

8. 상호참조: SLA 요구사항들과 유즈 이스 시나리오 ··· 79

제 9 결론 ···················································································80

제 2 장 시범사업 련 정책방향

제 1 혼합 실 기반 가상교육 캠퍼스 커뮤니티 ·················83

1. 개요 ··························································································83

2. 국내외 황 문제 ························································85

3. 추진 목표 략 ································································89

- vii -

제 2 스마트라이 환경을 한 융합형 클라우드컴퓨 · 96

1. 개요 ··························································································96

2. 국내외 황 문제 ························································98

3. 추진 목표 략 ······························································103

제 3 장 서비스 활성화를 한 법/제도 정책방향

제 1 사용자 보호 측면에서의 문제 ·································110

1. 사업자 산 ··········································································110

2. 서비스 단 장애 ··························································111

3. 사용자의 정보보호 ······························································112

4. 랫폼의 독립성 강화 ························································112

제 2 공 자 지원 보호 측면에서의 문제 ·················113

1. 사업의 보안성 확보 ····························································113

2. 상호 호환가능성을 통한 서비스 안정화 ························114

3. 공 자의 역량 강화 ····························································115

4. 인증제도 ················································································115

참고문헌 ··································································································117

- viii -

<Contents>

Chapter 1 Research on the Environment Analysis of

Cloud Services

Section 1 Introduction ·······································································1

Section 2 Definitions and Taxonomy ············································2

1. Definitions of Cloud Computing Concepts ······················2

2. Taxonomy ··················································································8

3. Relationships Between Standards and Taxonomies ····· 12

4. Application Programming Interfaces (APIs) ···················14

Section 3 Use Case Scenarios ·······················································18

1. End User to Cloud ·······························································20

2. Enterprise to Cloud to End User ·····································21

3. Enterprise to Cloud ······························································24

4. Enterprise to Cloud to Enterprise ····································26

5. Private Cloud ·········································································28

6. Changing Cloud Vendors ···················································29

7. Hybrid Cloud ·········································································33

8. Cross-Reference: Requirements and Use Cases ·············35

Section 4 Customer Scenarios ·······················································37

1. Customer Scenario: Payroll Processing in the Cloud ··37

2. Customer Scenario: Logistics and Project Management

in the Cloud ··········································································39

3. Customer Scenario: Central Government Services in the

Cloud ························································································42

- ix -

4. Customer Scenario: Local Government Services in a

Hybrid Cloud ·········································································43

5. Customer Scenario: Astronomic Data Processing ·········45

Section 5 Developer Requirements ··············································47

Section 6 Security Scenarios ··························································50

1. Regulations ············································································51

2. Security Controls ···································································52

3. Security Federation Patterns ·············································54

Section 7 Security Use Case Scenarios ·······································56

1. Computing Power in the Cloud ······································56

2. Cloud-based Development and Testing ··························58

3. Storage in the Cloud ···························································60

4. Cross-Reference: Security Controls and Customer

Scenarios ··················································································62

5. Cross-Reference: Security Federation Patterns and

Customer Scenarios ······························································63

Section 8 Service Level Agreements (SLAs) ·····························64

1. What is an SLA? ·································································65

2. Service Level Objectives ······················································66

3. Service Level Management ·················································67

4. Considerations for SLAs ······················································67

5. SLA requirements ··································································72

6. A note about reliability ·······················································77

7. Cross-reference: SLA Requirements and Use Case

Scenarios ··················································································78

8. Cross-reference: SLA Requirements and Cloud Delivery

- x -

Models ·····················································································79

Section 9 Conclusions ·····································································80

Chapter 2 Cloud Service Project Items

Section 1 E-learning Campus Community based on Mixed

Reality ·································································································83

1. Concept ····················································································83

2. Present state ···········································································85

3. Object and Strategy ····························································89

Section 2 Harmonic Cloud Computing for Smart Life

Environment ····················································································96

1. Concept ····················································································96

2. Present state ···········································································98

3. Object and Strategy ··························································103

Chapter 3 Legislative Regulation Direction for Cloud

Industry

Section 1 Issues from the User's Point of View ···················110

1. Supplier's Bankruptcy ························································110

2. Service Interruption or Failure ········································111

3. User's Privacy Protection ··················································112

4. Platform Independency ······················································112

Section 2 Issues from the Supplier Support and Security

Point of View ··················································································113

1. Security Guarantee ······························································113

2. Service Stability through Compatibility ·························114

- xi -

3. Supplier's Capability Increase ········································115

4. Certification System ····························································115

References ·······························································································117

- xii -

<그림 목차>

(그림1-1) 클라우드 컴퓨 의 분류 ····································································8

(그림1-2) 서비스 소비자 ······················································································9

(그림1-3) 서비스 제공자 ····················································································10

(그림1-4) 서비스 개발자 ····················································································11

(그림1-5) 표 과 분류간의 계 ······································································12

(그림1-6) 최종 사용자와 클라우드 간 ·························································· 20

(그림1-7) 기업과 클라우드 그리고 최종 사용자간 ·································· 22

(그림1-8) 기업과 클라우드 간 ········································································ 25

(그림1-9) 기업과 클라우드 그리고 기업 간 ················································ 27

(그림1-10) 라이빗 클라우드 ········································································ 28

(그림1-11) 클라우드 벤더 교체 ····································································· 29(그림1-12) 하이 리드 클라우드 ···································································· 33

(그림1-13) 커뮤니티 클라우드 ········································································ 34

(그림2-1) 혼합 실 기반 가상교육 캠퍼스 시스템 아키텍쳐 ··················90

(그림2-2) 혼합 실 기반 가상교육 캠퍼스 체 화면 ······························92

(그림2-3) 회의 컨퍼런스 ··············································································93

(그림2-4) 수업 강의 ······················································································93

(그림2-5) 공지 사항 ··························································································94

(그림2-6) 교육 서비스 선택 화면 ····································································94

(그림2-7) 미국 원격근무자 수 증가 추이 ······················································99

(그림2-8) 일본 원격근무자 비율 ····································································101

(그림2-9) 원격근무자 비율 ··············································································102

(그림2-10) 원격근무 도입 계획 ································································103

(그림2-11) 융합형 클라우드 컴퓨 서비스 랫폼 ··································106

(그림2-12) 클라우드 컴퓨 을 이용한 스마트워크 아키텍쳐 ··················106

- xiii -

<표 목차>

[표1-1] 유즈 이스 시나리오 ············································································18

[표1-2] 요구사항들과 유즈 이스 ····································································35

[표1-3] 고객 시나리오 ························································································37

[표1-4] 개발자 요구사항 ····················································································49

[표1-5] 보안 제어와 유즈 이스 ······································································52

[표1-6] 보안 제어와 련 표 ········································································54

[표1-7] 보안 시나리오 1 에 필요한 요구사항들 ·········································57

[표1-8] 보안 시나리오 2 에 필요한 요구사항들 ·········································59

[표1-9] 보안 시나리오 3 에 필요한 요구사항들 ·········································61

[표1-10] 보안 제어와 고객 시나리오 ······························································62

[표1-11] 보안 통합 패턴과 고객 시나리오 ··················································63

[표1-12] SLA 요구사항들과 클라우드 제공 모델 ···································· 78

[표1-13] SLA 요구사항들과 유즈 이스 시나리오 ·································· 79

[표2-1] 세계 이러닝 시장 규모 ······································································86

[표2-2] 2009년 국내 이러닝 수요시장 규모 ············································ 87

[표2-3] 미국 재택근무자 수(‘08년~’16년) ···············································100

- 1 -

제 1 장 클라우드 서비스 용 가능 분야별

환경분석

(클라우드 컴퓨 유즈 이스)

제 1 서론

본 보고서는 유즈 이스 그룹에서 작성한 클라우드 컴퓨 유즈 이

스 백서의 내용을 기반으로 한 것으로 본 문서의 목표는 클라우드 환경

에서 상호운 성, 통합의 편의성, 호환성(portability)을 보장하기 해 표

화를 되어야 하는 요구사항들과 기능력을 강조하기 한 것이다. 본

보고서에서 기술된 모든 유즈 이스들은 비공개된 사유 기술(proprietary technology) 없이도 구 이 가능하여야 하며, 클라우드 컴퓨 은 반드시

벤더의 종속을 최소화 하고 사용자 선택이 증가하는 개방형환경으로 발

해야 한다.이 유즈 이스들은,

o 상호운 성과 표 에 한 논의를 해 실 이며 사용자 경험에

기반을 둔 내용(context)을 제공하고,o 기존의 표 들이 어디에 사용되어야 하는지를 명확하게 하며,o 오 클라우드 컴퓨 의 요성에 해 산업계의 심을 집 시키

고,o 어디에 표 화 작업이 필요한지를 명확히 한다. 만약 특정 유즈 이

스가 재 구 될 수 없다거나, 독 인 API와 제품들로만 구 될

수 있다면 산업계는 그 유즈 이스를 가능하게 할 표 을 정의할

필요가 있다.어떤 공통의 작업을 명확히 묘사하고 그것을 이루기 한 어려움을 기

술하는 유즈 이스는 표 을 정립하기 한 모든 노력들을 해 가장 명

- 2 -

분 있는 작업이다.

제 2 정의와 분류

이번 장에서 설명하는 정의와 분류는 클라우드 컴퓨 개념의 개요를

제공하기 하여 포함되었다. 그러나 이 보고서의 은 클라우드 컴퓨

자체를 정의하는 것이 아니라 실생활의 실제 어 리 이션과 요구사

항들을 기반으로 한 클라우드 시나리오들과 유즈 이스들을 정의하는 것

이다. 우리의 목표는 어떻게 이 시나리오들이 정의되거나 분류될 것 인

가에 계없이 명확하고 흥미롭고 유용한 유즈 이스 시나리오들을 제공

하는 것이다.

1. 클라우드 컴퓨 개념의 정의

클라우드 컴퓨 : 클라우드 컴퓨 은 언제 어디서나 용이하게 구성이

가능한 컴퓨 자원(e.g. networks, servers, storage, application, service)들의 공유된 풀에 온디멘드 네트워크 근이 가능한 모델이다. 이 컴퓨

자원들은 최소한의 리 노력 혹은 서비스 제공자와의 상호 작용을

통해 원할 때 신속히 제공되고 회수되어야 한다. (이 정의는 U.S. Government's National Institute of Standards and Technology 가 발행한

NIST Working Definition of Cloud Computing의 최종 버 에서 따옴.1))

가. 서비스 모델 (Delivery Models)

클라우드 컴퓨 의 NIST 정의는 3가지의 딜리버리 모델들을 정의

한다:

1) 본 NIST 클라우드 컴퓨팅 페이지는 http://csrc.nist.gov/groups/SNS/cloud-computing/ 에서 찾을 수 있을 수 있으며, 본 백서에서 논의된 기본적 특성, 딜리버리 모델, 그리고 운용 모델들은 2009년 8월 19일 날자의 버전15에 기반을 두고 있음.

- 3 -

o 소 트웨어형 서비스 (Software as a Service / SaaS): 소비자는

단지 어 리 이션만을 사용하고, 그것을 실행시키고 있는 운 체

제, 하드웨어, 네트워크에는 근(제어)하지 않는다.o 랫폼형 서비스 (Platform as a Service / PaaS): 소비자는 그들

의 어 리 이션들을 해 제공되는 호스 환경을 사용한다. 이

소비자는 그 환경에서 실행되는 어 리 이션들(그리고 그 호스

환경의 일부 제어권)은 제어할 수 있지만, 어 리 이션들을 실행

시키고 있는 운 체제, 하드웨어, 는 네트워크 인 라는 제어하

지 않는다. 이 랫폼은 형 인 어 리 이션 임워크이다.o 인 라스트럭춰형 서비스 (Infrastructure as a Service / IaaS):

여기의 소비자는 로세싱 워, 스토리지, 네트워크 는 미들웨

어와 같은 기본 인 컴퓨 자원을 사용한다. 이 소비자는 운 체

제, 스토리지, 배치된 어 리 이션들, 그리고 방화벽과 부하분산기

와 같은 네트워크 컴포 트들에 한 제어가 가능하다.

나. 운용 모델 (Deployment Model)

NIST 는 4가지의 디 로이먼트(운용) 모델을 정의한다: o 퍼 릭 클라우드(Public Cloud): 퍼 릭(공공) 클라우드 서비스는

인터넷을 통해 제 3의 서비스 제공자로부터 클라이언트들에게 제

공된다는 특징을 갖는다. ‘공공(public)’이라는 용어는 그것이 무료

일 수도 있고 사용료가 렴할 수도 있지만 항상 무료를 의미하는

것은 아니다. 퍼 릭 클라우드란 사용자의 데이터가 일반에 보여

진다는 것을 의미하는 것은 아니다; 퍼 릭 클라우드 벤더는 일반

으로 그들의 사용자들을 한 근 제어 메커니즘을 제공한다. 퍼 릭 클라우드는 솔루션들을 제공하기 한 유연하고 경제 인

수단이다.o 라이빗 클라우드(Private Cloud): 라이빗 클라우드는 유연성과

서비스 기반 등과 같이 퍼 릭 클라우드 환경이 갖는 장 들의 많

- 4 -

은 부분을 역시 제공한다. 퍼 릭 클라우드와 라이빗 클라우드의

차이 은 라이빗 클라우드에서는 퍼 릭 클라우드 서비스들을

사용하는데 따를 수 있는 법 요구사항과, 보안 노출, 네트워크

용량과 같은 제약들이 없이 한 기 내에서 데이터와 로세스를

리한다는 이다. 한 라이빗 클라우드 서비스는 제공자와 사

용자에게 클라우드 인 라에 한 확장된 제어권을 제공하여 보안

과 복원력을 향상시킨다. 이는 사용자 근과 이용하는 네트워크가

지정되고 제한 가능하기 때문이다.2)o 커뮤니티 클라우드(Community Cloud): 커뮤니티 클라우드는 특정

한 보안 요구사항이나 공통의 임무와 같이 동일한 심을 가진

기 들로 구성된 그룹에 의해 운 되고 사용된다. 그룹의 구성원들

은 클라우드의 데이터와 어 리 이션을 근하고 공유할 수 있

다.3)o 하이 리드 클라우드(Hybrid Cloud): 하이 리드 클라우드는 상호

운 되는 퍼 릭과 라이빗 클라우드의 조합이다. 이 모델에서 사

용자들은 비즈니스에 요하지 않은 정보와 처리는 릭 클라우

드로 외부 탁을 하고, 요한 서비스와 데이터는 그들이 직 운

한다.

다. 클라우드 컴퓨 본질 특성 (Essential Characteristics)

NIST 정의에서는 클라우드 컴퓨 의 5가지의 본질 특성을 기술한

다. o 빠른 탄성(Rapid Elasticity): 여기서 탄성이란 필요에 따라 자원의

양을 증가 는 감소시킬 수 있는 능력을 의미한다. 사용자에게 클

2) 프라이빗 클라우드는 제3자에 의해 관리되고 외부에 존재할 수 있다. 굳이 이 클라우드를 사용하는 기관에 의해서 관리되고 호스팅되어야 할 필요는 없다.

3) 하이브리드 클라우드는 커뮤니티 클라우드에서 사용된 기술의 수퍼셋이다. 이러한 이유로 이들 두 개의 운용모델들의 요구사항은 제 3 절의 “하이브리드 클라우드”에서 같이 논의된다.

- 5 -

라우드는 무한하게 보여지고 사용자는 그들의 필요에 따라 거나

많은 컴퓨 워를 살 수 있다. 이것은 NIST가 정의한 클라우드

컴퓨 의 본질 인 특성 의 하나이다.o 측정된 서비스(Measured Service): 측정된 서비스에서는 클라우드

서비스가 클라우드 제공자에 의해 모니터 되고 리된다. 이것은

과 정책, 근제어, 자원 최 화, 사용량 측 등을 해 필수

이다.o 요청기반 셀 서비스(On-Demand Self-Service): 클라우드 컴퓨

의 요청(On-Demand)과 셀 서비스 (Self-Service)는 소비자가

클라우드 제공자와의 어떤 인간 인 상호작용(human interaction)없이 클라우드 서비스를 필요한 만큼 이용할 수 있다는 것을 의미

한다.o 유비쿼터스 네트워크 속(Ubiquitous Network Access): 유비쿼

터스 네트워크 속은 클라우드 제공자의 역량(기능과 성능)을 클

라이언트의 성능과 상 없이(thick, thin한 클라이언트 모두) 표

차에 의해 근 가능하며 네트워크상에서 이용할 수 있다는 것을

의미한다.4)o 자원 풀(Resource Pooling): 자원 풀은 클라우드 제공자로 하여

그들의 소비자들을 다 소유 모델(multi-tenant model)로 서비스

할 수 있게 한다. 물리 인 그리고 가상 자원들은 소비자의 요청에

따라 할당되고 재할당된다. 자원의 치는 독립 이고 고객은 제공

되는 자원의 정확한 치에 한 인지나 제어가 불가능하지만 높은

벨의 추상 인 치는 지정할 수도 있다. (나라, 주, 데이터센터

등)5)

4) 이는 꼭 인터넷을 통한 접근을 의미하는 것은 아니다. 정의에 따르면, 프라이빗 클라우드는 방화벽 내부에서만 접근할 수 있다. 네트워크 유형에 관계없이 클라우드로의 접근은 특정 유형의 클라이언트로 한정되지는 않는다.

5) 많은 경우에 정보보호 법안들과 규정들은 클라우드 제공자의 자원들이 특정 지역에 있을 것을 요구한다. 클라우드 제공자와 소비자는 이 규정들에 준수하도록 협력하여야 한다.

- 6 -

라. 기타 용어

o 상호운 성(Interoperability): 상호운 성은 시스템들의 통신능력

과 연 이 있다. 정보를 받는 시스템은 달된 정보를 이해해야 한

다. 클라우드 컴퓨 에서, 이것은 제공자들에 계없이 한 개 이상

의 클라우드 제공자에서 동시에 작동하는 코드를 작성할 수 있는

능력을 의미한다.6)o 이식성(Portability): 이식성은 한 환경에서 작성된 컴포 트나 시

스템을 여러 환경에서 실행할 수 있는 능력이다. 클라우드 컴퓨

에서, 이것은 소 트웨어와 하드웨어 인 환경을 모두 포함한다. (물리 인 것과 가상 환경 모두)

o 통합(Integration): 통합은 컴포 트나 시스템을 체 시스템으로

결합하는 과정이다. 클라우드 기반의 컴포 트나 시스템 사이의 통

합은 다 소유, 연계(federation), 정부규약과 같은 이슈에 의해 복

잡해질 수 있다.o 서비스 벨 보증(Service Level Agreement, SLA): 서비스 벨

동의(SLA)는 사용자의 요구와 제공자의 의무를 기술한 제공자와

사용자 사이의 규약이다. 일반 인 SLA는 가동시간, 사 기 성, 보안, 백업 차를 포함한다.

o 연합(Federation): 연합은 여러 시스템간의 데이터 혹은 식별자

(identity)를 결합하는 것이다. 연합은 클라우드 로커나 클라우드

제공자에 의해 실행될 수 있다.o 로커(Broker): 로커는 자신의 클라우드 자원을 직 가지지는

않지만 소비자의 요구에 따른 SLA에 기 하여 소비자와 제공자를

연결한다. 소비자는 로커가 자원을 운 하지 않는 다는 것을 모

른다.

6) 상호운영성과 이식성, 그리고 통합성의 정의는 아래의 작업 내용을 기준으로 했다.

- 7 -

o 다 소유(Multi-Tenancy): 다 소유는 동일한 물리 하드웨어

에 다양한 기업들로 부터의 다양한 데이터, 시스템, 어 리 이션

들을 수용할 때의 특징(property)이다. 다 소유는 부분의 클라

우드 시스템에서 흔히 용된다.o 클라우드 버스 (Cloud bursting): 클라우드 버스 은 라이빗 클

라우드의 필요 요청에 따라 추가 인 자원을 할당해주는 하이 리

드 클라우드 기술이다. 만약 라이빗 클라우드가 그들의 작업을

처리하기 한 충분한 처리 용량을 갖고 있다면, 하이 리드 클라

우드는 사용되지 않는다. 그러나 라이빗 클라우드의 작업량이 처

리용량을 과할 때는 하이 리드 클라우드가 자동 으로 라이

빗 클라우드에 추가 인 자원을 할당한다. o 정책(Policy): 정책은 운 차를 한 일반 인 용어이다. 를 들

어, 어떤 한 보안 정책은 특정 클라우드 서비스에 한 모든 요청

을 암호화하라고 명시할 수 있다.o 통제(Governance): 통제는 정책이 용되는 것을 확실하게 하기

한 차와 제어를 의미한다.o 가상 머신(Virtual Machine, VM): 실행될 때 사용자에게 실제 머

신처럼 보이는 일반 으로 이미지라 불리는 일이다. IaaS는 필요

에 따라 실행되거나 멈출 수 있는 가상 버신 이미지로 종종 제공된

다. 실행 인 가상 머신에게 용된 변경사항들은 유지를 하여

디스크에 장될 수 있다.o 애 리 이션 로그래 인터페이스(Application Programming

Interface, API): API는 어떤 한 시스템과 서로 작용하는 코드를

어떻게 작성할 것인지 개발자에게 알려주는 규약이다. API는 그

시스템에서 지원되는 기능들의 문법을 기술한다. 각각의 기능에

해, API는 시스템으로 보내져야 하는 정보, 시스템에서 반환되는

정보, 발생할 수 있는 각종 에러 조건들에 한 정보를 기술한다.- API는 특정 로그래 언어 는 WSDL(Web Services

Description Language), IDL(Interface Definition Language)과

- 8 -

(그림 1-1) 클라우드 컴퓨 의 분류

같은 보다 일반 인 형식으로 정의된다. REST 명세서는 컴퓨

터가 해석할 수 있는 언어를 갖지 않음에도 불구하고 API를

정의한다.- API는 HTTP 같은 로토콜과 JSON이나 XML 스키마와 같은

데이터 형식들의 세부 사항들을 포함할 수도 있다.- API는 데이터와 기능들의 의미를 이해하기 해 인 지능을

요구한다. 머신은 두 개의 정수형 변수를 요구하는 메소드 x를

발견할 수는 있지만, 개발자인 인간이 무수히 많은 2개의 정수

형 변수 어떤 것인지를 알아내야 한다.

2. 분류(taxonomy)

이 그림은 클라우드 컴퓨 의 분류를 정의한 것이다.

이 다이어그램에서, 서비스 소비자(Service Consumer)는 클라우드를 통

해 제공되는 서비스를 사용하고, 서비스 제공자(Service Provider)는 클라

우드 인 라를 리하고, 서비스 개발자(Service Developer)는 클라우드

- 9 -

(그림 1-2) 서비스 소비

자

서비스 자체를 만든다. (그들의 역할 사이의 상호작용을 한 오 표

이 필요하다.) 각각의 역할은 다음 장에서 자세히 기술된다.

가. 서비스 소비자(Service Consumer)

서비스 소비자는 SaaS, PaaS, IaaS 서비스를 사용하는 실질 인 최

종 사용자나 기업이다. 서비스의 유형과 그들의 역할에 따라 그 소비자는 서

로 다른 사용자 인터페이스와 로그래 인터페이스를

가지고 작업을 한다. 어떤 사용자 인터페이스들는 어

리 이션처럼 보인다. 따라서 소비자는 그 어 리 이션

을 사용하면서 클라우드 컴퓨 에 해 알 필요가 없다. 다른 사용자 인터페이스들은 가상 머신을 시작시키고 멈

추거나 스토리지를 리하는 것과 같은 리자 기능들을

제공한다. 어 리 이션 코드를 작성하는 소비자는 그들

이 작성하는 어 리 이션에 따라 서로 다른 로그래

인터페이스들을 사용한다. 소비자들은 한 SLA들과 계약들에 따라 작업한다. 일반 으로 SLA와 규약들은 소비자와 제공자 사이에서

사람의 조정에 의해 결정된다. 소비자의 기 치와 제공

자의 평 은 이런 상의 요한 부분이다.

나. 서비스 제공자(Service Provider)

서비스 제공자는 소비자에게 서비스를 제공한다. 제공자의 실제 인

일은 서비스 종류에 따라 다르다.o SaaS 서비스에서 제공자는 소 트웨어를 설치하고 리하고 유지한

다. 제공자는 이런 소 트웨어가 실행되는 물리 인 라를 소유 할

필요는 없다. 소비자는 인 라에 속할 권한이 없고, 단지 그들은

- 10 -

(그림 1-3) 서비스 제공자

오로지 어 리 이션에만 근할 수 있다.o PaaS 서비스에서 제공자는 특정 종류의 어 리 이션을 한

임워크인 랫폼을 한 클라우드 인 라를 리한다. 소비자의 어

리 이션은 랫폼 하단의 인 라에는 근할 수 없다.o IaaS 서비스에서 제공자는 스토리지, 데이터베이스, 메시지 큐 혹은

미들웨어, 는 가상 머신을 한 호스 환경을 유지한다. 소비자

는 이러한 서비스들이 각각 디스크 드라이 , 데이터베이스, 메시지

큐, 는 머신들인 것처럼 사용하지만 이들을 호스 하고 있는 인

라에는 근할 수 없다. 서비스 제공자 그림에서, 가장 하 벨 단 는 모든 것의 기반이

되는 퍼엄웨어(firmware)와 하드웨어이다. 그 에는 운 체제 는

가상 머신 리자인 소 트웨어 커 이 존재하고 이들은 클라우드 하

부단의 인 라를 리한다. 가상화된(virtualized) 자원과 이미지는

로세싱 워, 스토리지, 미들웨어와 같은 기본 인 클라우드 컴퓨

- 11 -

(그림 1-4) 서비스

개발자

서비스들을 포함한다. 가상 머신 리자에 의해 리되는 가상 이미지

들은 이미지 자체와 그들을 리하기 한 메타데이터를 포함한다. 서비스 제공자의 동작 가장 요한 부분은 리 이어이다. 하

벨에서는 가 서비스를 사용하는 지와 얼마만큼의 규모로 사용

하는지를 측정하는 메터링, 어떤 방법으로 자원을 소비자에게 할당할

것인지를 결정하는 로비져닝, 시스템과 자원의 상태를 계속 모니터

링 하는 등의 리 기능이 요구된다. 상 벨에서의 리 기능에는 경비를 회수하기 한 요 청구, 소

비자의 요청을 만족시키기 한 용량계획, 제공자와 소비자가 동의한

서비스 항목들을 충족시키기 한 SLA 리, 그리고 리자에게 보고

하는 기능들이 있다. 보안은 서비스 제공자 제공기능들의 모든 측면에 용된다. 오 표

은 서비스 제공자의 제공기능에도 역시 용된다. 잘 작성된 표 은

제공자 내에서의 기능들과 제공자들 사이의 상호운 성을 간소화시킨

다. 다. 서비스 개발자(Service Developer) 서비스 개발자는 클라우드 서비스를 만들고 배치하고

모니터링 한다. 이러한 클라우드 서비스는 일반 으로

SaaS 모델을 통해 최종 사용자에게 직 달되는 비즈

니스 련(line-of-business) 어 리 이션들이다. IaaS와 PaaS 벨에서 작성된 어 리 이션들도 추후

SaaS 개발자나 클라우드 제공자들에 의해 사용된다. 서비스 개발 환경은 다양하다. 만약 개발자들이 SaaS 어 리 이션을 개발한다면 그들은 아마도 클라우드 제

공자에 의해 제공된 환경에서 어 리 이션을 개발할

것이다. 이런 경우에 서비스를 개시/운 한다는 것은 그

서비스를 클라우드 제공자의 인 라에 배치하는 것이다.

- 12 -

(그림 1-5) 표 과 분류간의 계

서비스를 개발하는 과정에는 소비자에게 서비스를 제공하기 에

서비스를 테스트하기 한 원격 디버깅이 포함된다. 일단 서비스가 오

된 후 개발자들은 자신들의 서비스의 성능을 감시 하고 필요에 따

라 변화를 주게 한다.

3. 표 과 분류 간의 계

표 들이 클라우드 유즈 이스들에게 향을 주는 데는 아래 그림과

같이 4가지 분야가 있다. 표 은 각 유형의 클라우드 서비스 내에서, 서

로 다른 유형의 클라우드 서비스들 간에, 엔터 라이즈와 클라우드 간

에, 그리고 한 엔터 라이즈의 라이빗 클라우드 내 등의 4분야에 향

을 가질 것이다.

가. 클라우드 서비스 유형들 간의 표 (Standards Across Cloud Service Type)

- 13 -

클라우드 컴퓨 이 지 보다 더 일반 이 되면, 어 리 이션은 여러

종류의 클라우드 서비스들을 사용할 것이다. 어떤 어 리 이션은 클

라우드 스토리지 서비스, 클라우드 메시지 큐, 클라우드에서 실행되는

가상 머신 리(실행, 정지, 모니터링)를 사용할 수도 있다. 이러한 여

러 다른 서비스들이 어떻게 함께 동작할 것인지에 한 정의를 하는

표 은 가치를 제공해야 한다.

나. Standards Within Cloud Service Type

IaaS, PaaS, SaaS 각각의 클라우드 서비스 타입의 범 내에서 오

표 은 기업(vender)에 종속되는 것을 막을 수 있을 것이다. IaaS에서, 클라우드 데이터베이스들과 연동하기 한 표 화된 API 셋은 다양한 기업들의 데이터들과 함께 동작하는 어 리 이션들을

가능하게 한다. 이러한 공통된 API 는 사용자들이 많은 변경 작업 없

이 클라우드 데이터베이스 제공자를 교체할 수 있는 자유를 제공하는

것과 더불어 재의 어 리 이션에 새로운 데이터 자원을 통합하는

것을 쉽게 만든다. 스토리지, 메시지 큐, 맵리듀스와 같은 다른 클라우

드 인 라스트럭춰 서비스들을 한 공통된 API들도 데이터와 데이터

교환을 한 공통된 형식을 지원하는 경우와 같이 유사한 장 을 제

공할 것이다. 가상 머신의 경우, 공통된 가상 머신 형식은 매우 요

하다. 사용자는 한 클라우드 제공자가 만들고 배치한 가상 머신을

다른 클라우드 제공자에게 변경 없이 배치할 수 있어야 한다. PaaS에서, 클라우드에서 제공되는 많은 랫폼은 어 리 이션

임워크이다. 이런 임워크는 일반 으로 소비자 인터페이스, 스토

리지, 그리고 데이터베이스와 같은 공통 인 서비스를 제공하지만 그

들은 이런 임워크의 API를 통해서만 근할 수 있다

SaaS에서, 오 표 은 어 리 이션 벨에 용된다. 클라우드와

련된 표 은 매우 기 때문에 이런 표 은 이 문서의 범 가 아니

다. 를 들어 클라우드 기반의 워드 로세싱 어 리 이션은 문서의

- 14 -

이식성을 한 표 을 지원해야 하는데, 워드 로세싱 응용을 지원하

는 표 에 한 요구사항은 그 어 리 이션이 클라우드 내에서 실행

되는 것인지 아닌 것인지 와는 아무런 상 이 없다.

다. 클라우드와 엔터 라이즈 간의 표 (Standards Between the Cloud and the Enterprise)

클라우드 컴퓨 이 계속 발 을 하더라도 Java EE와 같은 엔터 라

이즈 아키텍춰는 사라지지 않을 것이다. 엔터 라이즈 어 리 이션이

어떻게 클라우드 데이터베이스, 그리고 클라우드 메시지 큐와 같은 자

원들과 통신을 하는가에 한 표 은 이런 어 리 이션들이 수정 없

이 는 약간의 수정으로 클라우드 서비스들을 사용할 수 있도록 한

다. 클라우드 컴퓨 과 존하는 아키텍쳐들, 그리고 개발 패러다임들

을 어떻게 통합할 것인가는 본 그룹의 큰 과제가 될 것이다.

라. 엔터 라이즈 내부의 표 (Standards Within an Enterprise)

기업(enterprise) 내부의 표 은 상호운 성(Interoperability), 감사

(auditability), 보안, 그리고 리(management) 등의 요구사항에 의해

결정될 것이고, 추후 엔터 라이즈와 클라우드 간의 표 으로 발 할

것이다. 이런 엔터 라이즈는 릭, 라이빗, 그리고 하이 리드 클

라우드들의 일부 조합들과 향을 주고 상호작용할 것이다.

4. 애 리 이션 로그래 인터페이스 (APIs)

클라우드 컴퓨 솔루션을 만들기 한 가장 기본 인 방법은 클라우

드 제공자에 의해 제공되는 API를 통하는 것이다. 클라우드 API는 4개의

벨에서 동작하고, 5개의 기본 인 분류(category)에 속한다.

- 15 -

가. API들의 벨(Levels of APIs)

4개 벨의 API들이 존재하는데, 각 벨은 개발자로 하여 서로

다른 작업들과 데이터 구조를 가지고 일 할 것을 요구한다.o Level 1 – The Wire: 이 벨에서, 개발자는 특정 요청의 와이어

포맷으로 직 코드를 작성한다. 만약 REST기반의 서비스라면 개

발자는 한 HTTP 헤더를 개발하며, 요청에 따라 페이로드

(payload)를 만들고, 서비스에게로의 HTTP 연결을 열어 다. 그러

면 그 REST 서비스는 HTTP 응답코드(response code)를 갖는 데

이터를 회신한다. 많은 REST서비스는 간단하기 때문에, 이 벨의

코드를 작성하는 것은 상 으로 효율 이다. 만약 어떤 서비스가

SOAP 기반이라면, 그 개발자는 SOAP 엔벨롭(envelope)을 만들고

한 SOAP 헤더를 추가한 후, 데이터 페이로드로 SOAP의 본문

(body)을 채운다. 그러면 이 SOAP서비스는 요청의 결과를 담은

SOAP 엔벨롭으로 응답한다. SOAP 서비스로 작업한다는 것은 엔벨

롭의 XML 내용을 싱해야 한다. 그런 이유로 부분의 SOAP 서

비스들은 상 벨 API에서 호출된다.o Level 2 – 언어 종속 툴킷(Language-Specific Toolkits): 이

벨의 개발자는 SOAP와 REST요청에 해 작업하기 해 언어 종속

인 툴킷을 사용한다. 비록 개발자가 와이어를 통해 달되는 데이

터들의 포맷이나 구조에 치 을 해야 하지만 많은 세부사항( 를

들어 응답 코드의 처리와 시그니춰 계산)들은 그 툴킷에 의해 처리

된다.o Level 3 – 서비스 종속 툴킷(Service-Specific Toolkits): 이

벨의 개발자는 어떤 한 특정 서비스와 작업하기 해 상 벨의

툴킷을 사용한다. 이 벨에서 작업하는 개발자는 비즈니스 목 과

차에 집 할 수 있다. 개발자는 와이어 로토콜에 집 하는 신

에 조직에 련된 데이터와 로세스 문제에 집 할 때 보다 더 생

산 이 될 수 있다.

- 16 -

o Level 4 – 서비스 독립 툴킷(Service-Neutral Toolkits): 이 벨

은 API의 최상 벨이다. 이 벨에서의 개발자는 여러 클라우드

컴퓨 제공자들과의 연결을 해 하나의 공통된 인터페이스를 사

용한다. 벨3과 마찬가지로 이 벨의 개발자는 비즈니스 목 과

비즈니스 차에 집 한다. 그러나 벨 3과는 달리 벨 4에서는

개발자는 어떤 클라우드 서비스와 그들이 작업하고 있는지 걱정할

필요가 없다. 서비스 독립 툴킷으로 작성된 한 어 리 이션은 코

드상의 작은 수정만으로도 다른 클라우드 벤더를 사용할 수 있어야

한다.

나. API들의 유형(Categories of APIs)

로그래 인터페이스는 5가지의 유형으로 나 어 질 수 있다.o Category 1 – 일반 인 로그래 (Ordinary Programming): C#,

PHP, Java 등과 같은 일반 인 어 리 이션 로그래 이다. 이

카테고리에서는 클라우드와 연 되는 부분이 없다.o Category 2 – 배치(Deployment): 클라우드에 어 리 이션을 배치

하기 한 로그래 인터페이스이다. 클라우드 종속 인 모든 패

키징 기술과 더불어 .Net 어셈블리와 EAR/WAR 일 등과 같은

통 인 기존의 패키징 방법들이 포함된다.o Category 3 – 클라우드 서비스(Cloud Service): 클라우드 서비스와

함께 동작하는 로그래 인터페이스이다. 앞장에서 논의된 것과

같이 클라우드 서비스 API는 서비스 종속 이거나 아니면 서비스

독립 이다. 이러한 API들은 클라우드 스토리지 서비스, 클라우드

데이터베이스, 클라우드 메시지 큐, 그리고 그 이외의 클라우드 서

비스 등 여러 서 카테고리고 나 어진다. 클라우드 서비스 API를

사용하여 코드를 작성하는 개발자는 그들이 클라우드를 사용하고

있다는 것을 알고 있다.o Category 4 –이미지와 인 라 리(Image and Infrastructure

- 17 -

Management): 가상 머신 이미지와 세부 인 인 라를 리하기

한 로그래 인터페이스이다. 이런 API들은 이미지의 업로드, 시

작, 지, 재시작, 그리고 삭제를 지원한다. 인 라 리 API들은 방

화벽, 노드 리, 네트워크 리, 부하분산 등의 세부 인 사항들을

제어한다.o Category 5 – 내부 인터페이스(Internal Interface): 클라우드 인

라의 서로 다른 여러 부분들 사이의 내부 인터페이스를 한 로

그래 인터페이스이다. 이런 API는 클라우드 아키텍쳐 내의 스토

리지 이어를 한 벤더를 바꾸기 원할 때 사용되는 API이다.

다. 개발자 역할(Developer Roles)

개발자들에 한 요구사항들을 논의하기 해서는 개발자들이 하는

다양한 역할들을 명시하는 것이 도움이 된다. API들과 클라우드 서비

스들에 한 요구사항은 각각의 역할에 따라 다르다. 아래는 본 문서

에서 논의할 역할들과 그들이 사용하는 API 유형들이다. o 고객 응용 개발자(Client Application developer): 최종 사용자를

한 클라우드 기반의 클라이언트 어 리 이션을 개발한다. 이런 개

발자들은 클라우드 서비스를 한 API를 사용한다. (category3)o 응용 개발자(Application developer): 클라우드를 사용하는 통

인 어 리 이션을 개발한다. 이런 개발자들은 유형3의 클라우드 서

비스 API 뿐만 아니라 유형1의 통상 인API들을 사용한다. o 배치자(Deployers): 클라우드를 사용하는 어 리 이션들을 포장

(package), 배치, 그리고 유지한다. 수명주기(lifecycle) 리 한 여

기에 속한다. 이러한 개발자들은 배치, 클라우드 서비스, 그리고 이

미지 리를 한 API들을 사용한다. (유형2, 3, 4)o 리자(Administrator): 배치와 인 라 리를 포함하는 여러 벨

에서 어 리 이션들과 작업한다. 이런 개발자들은 유형 2, 3, 4의

API를 사용한다.

- 18 -

End User to Cloud클라우드 안에서 실행

이고 최종사용자가

근하는 응용 로그램

Enterprise to Cloud to End User

직원들과 고객들은

퍼 릭 클라우드에서

실행 인 응용

로그램들에 근할 수

있다.

[표 1-1] 유즈 이스 시나리오

o 클라우드 제공자(Cloud Provider): 그들이 제공하는 클라우드의 하

부에 있는 인 라와 작업을 한다. 이러한 개발자들은 유형5의 API들을 사용한다.

제 3 유즈 이스 시나리오

엔터 라이즈 클라우드 사용 시나리오는 가장 일반 인 클라우드 컴퓨

사례(유즈 이스)들을 설명하고 있을 뿐이지, 클라우드 환경에서 나타

날 수 있는 모든 이스들을 나열한 것은 아니다. 이번 에 있는 그래픽은 공통의 요소들을 갖고 있다. 만약 주어진 요

소가 특정 유즈 이스에 용되지 않는다면, 회색으로 표시되거나 선

으로 그려졌다. 를 들어, 라이빗 클라우드 유즈 이스는 최종 사용

자 는 퍼 릭 클라우드를 포함하지 않으므로, 엔터 라이즈만 색상이

표 다.

- 19 -

Enterprise to Cloud클라우드 응용

로그램은 기업 내부의

IT 기능들과

통합된다.

Enterprise to Cloud to

Enterprise

퍼 릭 클라우드 안에서

실행 인 클라우드 응용

로그램은 트 사의

응용 로그램과

상호운용 된다.

Private Cloud한 조직의 방화벽

안에서 그 조직에 의해

호스트된 클라우드

Changing Cloud Vendors

클라우드 서비스를

이용하는 조직은 해당

서비스 제공자를

바꾸거나, 추가 인

제공자들과 작업 할 수

있다.

- 20 -

Hybrid Cloud

여러 클라우드가 함께

작업하고, 클라우드

로커는 데이터, 응용

로그램, 사용자 식별, 보안 등을 연합시킨다.

(그림 1-6) 최종 사용자와 클라우드 간

1. 최종 사용자와 클라우드 간 (End User to Cloud)

이 시나리오에서, 최종 사용자는 클라우드의 데이터와 응용 로그램

에 근할 수 있다. 이런 타입의 흔한 응용 로그램에는 이메일 호스

과 소셜 네트워킹 등이 있다.

Gmail 이나 Facebook, Linkedln의 사용자는 어떤 단말의 어떤 라우

를 통해서도 응용 로그램과 데이터에 근할 수 있다. 그리고 그 사용

- 21 -

자는 그들의 데이터가 클라우드에서 장되고 리되기 때문에 오직 비

번호만 알면 된다. 가장 요한 것은, 사용자는 구조 으로 어떻게 동작하는지 몰라도 된

다는 이다. 단지 사용자는 인터넷만 연결되어 있다면, 원하는 자신들

의 데이터에 근할 수 있다.

가. 요구사항(Requirements) o 식별자(Identity) : 클라우드 서비스는 특정 최종 사용자를 인증해

야 한다.o 오 클라이언트(An open client): 특정 랫폼이나 기술 없이도 클

라우드 서비스에 근 가능하다.o 보안(Security): 세 하게 보면 각각의 이스 마다 조 씩 다르고

다양하겠지만, 보안은 모든 이스에서 필요한 요소이다.o SLAs:　비록 사용자에 한 SLA가 기업에 한 SLA보다 단순하겠

지만, 클라우드 벤더들은 자신들이 제공하는 서비스가 어디까지 보

장될 수 있음을 명확히 알고 있어야 한다.

2. 기업과 클라우드 그리고 최종 사용자 간 (Enterprise to Cloud to End User)

이 시나리오에서, 기업은 사용자에게 데이터와 서비스를 달하기

해 클라우드를 사용한다. 사용자가 기업과 하면, 기업은 데이터를

가져오고 다루기 해서 클라우드에 근하고 그 결과를 사용자에게 보

내 다. 사용자는 기업 내의 군가가 될 수도 있고 외부의 고객이 될

수도 있다.

- 22 -

(그림 1-7) 기업과 클라우드 그리고 최종 사용자 간

가. 요구사항(Requirements)

o 식별자(Identity): 클라우드 서비스는 최종 사용자를 인증해야 한다. o 오 클라이언트(An open client): 특정 랫폼이나 기술 없이도 클

라우드 서비스에 근 가능하다.o 연합된 식별자(Federated identity): 최종 사용자에게 필요한 기본

인 인증과 더불어, 기업 사용자도 기업과의 인증이 추가로 필요할

수 있다. 그러나 클라우드 서비스에 요구되는 식별자들을 모두 연합

하는 인 라가 있어서 기업 사용자는 단 하나의 식별자만 리하는

것이 이상 이다.o 치 인지(Location awareness): 기업이 사용자를 신하여 리하

는 데이터의 종류에 따라, 데이터가 장되는 물리 서버의 치에

한 법 제한이 있을 수 있다. 비록 이것이 사용자가 물리 인

라의 세부사항을 몰라도 된다는 클라우드 컴퓨 의 이상에는 반

되는 것이지만, 꼭 필요한 요소이다. 많은 응용 로그램들은 클라

- 23 -

우드 서비스를 달하는 물리 인 하드웨어의 치를 결정하는 API를 클라우드 벤더가 제공할 때 까지는 클라우드로 이동 될 수 없다.

o 계량과 모니터링(Metering and monitoring): 모든 클라우드 서비스

들은 비용 리, 환불처리, 로비 닝을 해서 계량되고, 모니터링

되어야 한다.o 리와 통제(Management and Governance): 퍼 릭 클라우드 제공

자는 쉽게 거래를 시작하고, 쉽게 클라우드 서비스를 사용할 수 있

도록 해 다. 하지만 이것으로 한 기업에 속한 개인이 자신의 개인

인 이익을 해 클라우드 서비스를 사용 할 험이 생긴다. 가상

머신의 리와 스토리지, 데이터 베이스, 메시지큐 같은 클라우드

서비스의 리에는 어떤 서비스들이 사용되었는지가 포함되어야 한

다. 통제는 클라우드 컴퓨 이 어디에서 사용이 되었든지, 정책과

정부 규율이 용되었는지를 보장하는 하기 해 요하다. 기타 통

제 요구 사항은 산업과 지역( 치)에 련된 것들이다.o 보안(Security): 기업이 연 된 모든 이스들은 단일 사용자와 연

된 이스보다 더 정교한 보안 요구사항들을 가질 것이다. 유사하

게, 앞으로 나올 보다 더 진보한 기업 유즈 이스들은 그에 따른 보

안 요구사항도 더 진보할 것이다.o 가상 머신용 공통된 일 형식(A Common File Format for VMs):

어느 한 클라우드 벤더의 랫폼을 해 만들어진 가상 머신은 다

른 벤더의 랫폼에도 이식 가능해야 한다. 이 요구사항에 한 모

든 솔루션들은 클라우드 벤더가 가상 머신에 스토리지를 붙이는 방

법을 (방법의 차이를) 설명해야 한다.o 클라우드 스토리지와 미들웨어를 한 공통 APIs(Common APIs

for Cloud Storage and Middleware):　기업의 유즈 이스는 클라우

드 스토리지 서비스, 클라우드 데이터베이스, 메시지 큐 같은 클라

우드 미들웨어 서비스에 근하기 한 공통된 API를 요구한다. 특

정 벤더의 클라우드 서비스에서만 동작하는 맞춤 용 코드를 사용

하는 것은 그 해당 벤더의 시스템에 기업이 종속되고, 클라우드 컴

- 24 -

퓨 이 제공하는 경제 인 이득과 유연성이 반감된다.o 데이터와 어 리 이션의 결합(Data and Application Federation):

기업 응용 로그램은 여러 클라우드 기반의 소스로부터 데이터를

결합하고 서로 다른 클라우드에서 동작하는 응용 로그램의 활동

을 조정할 수 있어야 한다.o SLA와 벤체마크(SLAs and Benchmarks): 최종 사용자에게 필요한

기본 SLA에 추가 으로, SLA를 기반으로 계약을 체결한 기업은 성

능 벤치마킹을 한 표 인 방법이 필요하다. 클라우드 제공자가

달해야 하는 것에 해 명확히 정의할 수 있는 방법이 있어야 하

고, 실제로 달된 것에 명확히 측정할 수 있는 방법이 있어야 한

다. (SLA에는 추가 으로 클라우드 보안에 한 내용이 포함되어야

한다.)o 라이 사이클 리(Lifecycle Management): 기업들은 응용 로그램

과 문서들의 라이 사이클을 리할 수 있어야 한다. 여기에는 응용

로그램의 버져닝, 데이터의 유지 삭제 리 등이 포함된다. 디

스커버리(Discovery)는 많은 조직에서 요 이슈이다. 어떤 데이터

를 더 이상 사용할 수 없다면 실질 인 법 책임이 따른다. 데이터

의 유지뿐만이 아니라 경우에 따라 기업들은 어떤 특정 시 에 데

이터가 확실히 삭제되었는지를 명확하게 하고 싶어 한다.

3. 기업과 클라우드 간 (Enterprise to Cloud)

이번 이스는 기업이 내부의 로세스를 해 클라우드 서비스를 사

용하는 경우이다. 이 경우는 기업에게 부분의 제어권을 주기 때문에

클라우드 컴퓨 의 기 단계에서 가장 흔한 이스다.

- 25 -

(그림 1-8) 기업과 클라우드 간

이번 시나리오에서, 기업은 필요한 리소스를 보충하기 해 클라우드

서비스를 사용한다.o 백업 혹은 드물게 사용되는 데이터를 장하기 해 클라우드 스토리

지를 사용한다.o 최 부하를 처리하기 해 추가 로세서를 온라인으로 가져오기

해 클라우드의 가상 머신을 사용한다. (물론, 더 이상 필요하지 않다

면 가상 머신을 지할 수 있다.)o 기업의 특정 기능(email, calendaring, CRM 등)을 해 클라우드의 응

용 로그램을 사용한다.o 응용 로그램 처리의 일부로서 클라우드 데이터베이스를 사용한다. 이

것은 트 사, 정부, 에이젼시 등과 데이터베이스를 공유할 때 매우

유용하다.

- 26 -

가. 요구사항(Requirements)

Enterprise to Cloud 유즈 이스의 기본 요구사항은 기업과 클라우드

그리고 최종 사용자간(Enterprise to Cloud to End User) 유즈 이스와

많은 부분 동일하다. 오 클라이언트, 연합된 식별자, 치인지, 계량

과 모니터링, 리와 통제, 보안, 가상머신용 공통 일 형식, 클라우

드 스토리지와 미들웨어를 한 공동된 API, 데이터와 어 리 이션

연동, SLA와 라이 사이클 리 등이 모두 용된다.그 밖의 요구사항은 다음과 같다.o 배치(Deployment): 필요에 따라 가상 머신 이미지를 구축하고 배포

하는 작업이 단순해야 한다. 가상 머신 이미지가 구축될 때, 한 클

라우드 제공자에서 다른 제공자로의 이미지 이동이 가능해야 하고, 벤더들 마다 다를 수 있는 가상 머신에 스토리지를 장착하는 방법

을 알려주어야 한다. 클라우드로의 응용 로그램 배포 역시 간단해

야 한다.o 기업 련 표 과 로토콜(Industry-specific standards and

protocols): 기업들 간의 많은 클라우드 컴퓨 솔루션들은

RosettaNet 이나 OAGIS 같은 기존의 표 을 사용할 것이다. 이

용 가능한 표 들은 응용 로그램에 따라, 산업에 따라 달라질

것이다.

4. 기업과 클라우드 그리고 기업 간 (Enterprise to Cloud to Enterprise)

이번 이스에서는 두 기업이 같은 클라우드를 사용한다. 여기서 요

한 것은 기업들의 응용 로그램들이 서로 상호작용할 수 있도록 클라우

드 내에서 리소스를 호스 하는 것이다. 공 사슬(supply chain)이 이번

이스의 가장 확실한 이다.

- 27 -

(그림 1-9) 기업과 클라우드 그리고 기업 간

가. 요구사항(Requirements)

기업과 클라우드 그리고 기업 간(Enterprise to Cloud to Enterprise)의 기본 요구사항은 기업과 클라우드 간의 것들과 거의 유사하다. 식

별자, 오 클라이언트, 연합된 식별자, 치인지, 계량과 모니터링, 리와 통제, 보안, 산업 련 표 , 스토리지와 미들웨어를 한 공통된

API, 데이터와 어 리 이션 연동, 그리고 SLA와 라이 사이클 리

등이 모두 용된다. 그 밖의 요구사항은 다음과 같다. o 트랜잭션과 동시성(Transactions and concurrency): 서로 다른 기

업들 간에 응용 로그램과 데이터를 서로 공유하기 해서는 트랜

젝션과 동시성이 필수 이다. 만약 두 기업이 같은 클라우드에 호스

트된 응용 로그램과 가상 머신, 미들웨어, 그리고 스토리지를 공유

- 28 -

한다면, 어느 한 기업에 의한 모든 변화들이 신뢰 있게 용된다는

것은 요하다. o 상호운 성(Interoperability): 하나 이상의 기업들이 연 되기 때문

에, 기업들간의 상호운 성은 필수다.

5. 라이빗(private) 클라우드

라이빗 클라우드 유즈 이스는 클라우드가 기업 내에 포함되어 있다

는 에서 다른 이스들과 다르다. 이런 경우는 규모의 기업들에게

유용하다. 를 들어, 각 달의 15일과 30일에 어느 기업의 여부서에

작업량이 몰린다면, 비록 나머지 날에는 작업량이 조 일지라도, 최

치의 작업량을 다루기 한 컴퓨 워가 충분히 필요하다. 라이빗

클라우드를 이용하면 컴퓨 워가 기업 반에 분포되어 있다. 의

여부서는 컴퓨 워가 필요할 때 여분의 워를 이용할 수 있고, 다

른 부서들도 마찬가지다. 이 게 기업은 기업 반에 걸쳐 컴퓨 워

를 상당부분 약 할 수 있다.

(그림 1-10) 라이빗(private) 클라우드

- 29 -

가. 요구사항(Requirements)

라이빗 클라우드의 기본 요구사항들은 오 클라이언트, 계량과 모

니터링, 리와 통제, 보안, 배치, 상호운 성, 가상머신용 공통 일 형

식, 그리고 SLAs이다. 식별자, 연합된 식별자, 치인지, 트랜젝션, 산업 련 표 , 미들웨어

를 한 공통된 API, 그리고 라이 사이클 리 등은 라이빗 클라우드

에서는 필요하지 않다는 에 주목해야 한다. 많은 경우에, 소비자들은

치인지가 더 이상 문제가 되지 않기 때문에 라이빗 클라우드를 사용

해야 하는 경우들도 많다. 기업 내에서 클라우드를 유지하게 되면, 식별

자 리, 표 과 공통 APIs에 한 요구사항이 필요 없어진다.

6. 클라우드 벤더 교체

이번 이스는 다른 벤더를 추가하거나 기존의 벤더를 교체함으로써, 다른 벤더와 작업하는 경우이고, 이 문서에 언 되었던 모든 유즈 이스

에 용된다. 큰 변경 없이 다른 벤더와 작업할 수 있다는 것은 개방과

표 의 요 이 이다.

(그림 1-11) 클라우드 벤더 교체

- 30 -

여기에는 요구사항들이 약간씩 다른 4개의 시나리오가 있다. 일반 으

로, 클라우드 벤더 교체는 오 클라이언트, 치인지, 보안, SLAs, 가상

머신용 공통 일 포맷, 그리고 클라우드 스토리지와 미들웨어를 한

공통 APIs등을 필요로 한다. 자세한 내용은 다음 세부항목에서 확인 할

수 있다.

가. 시나리오 1: SaaS 벤더의 교체(Changing SaaS vendors) 이번 시나리오에서 클라우드 고객은 SaaS 벤더를 교체한다. 두 Saas 벤더는 같은 응용 로그램(CRM, 회계, 문서 작성기 등)을 제공한다. 기존 벤더의 소 트웨어에서 만들어진 문서와 데이터는 두 번째 벤더

의 소 트웨어에서 인식/호환될 수 있어야 한다. 어떤 경우에는 고객

이 두 벤더를 번갈아 사용할는지도 모른다.

(1) 요구사항(Requirements)

o 산업 련 표 (Industry-specific standards): 한 벤더의 응용 로

그램에서 다른 벤더로 문서와 데이터를 이동시키기 해서는 두 응

용 로그램이 같은 포맷을 지원해야 한다. 그 포맷은 응용 로그램

의 타입에 따라 다를 것이다. 어떤 경우에는, 다른 응용 로그램의 타입들을 한 표 APIs가 필

요할 것 이다. 이 요구사항들이 클라우드와 계가 없다는 것을 안다는 것은 요

하다. Zoho에서 Google Docs로 한 문서를 이동 할 때나 Microsoft Office에서 OpenOffice로 문서 이동할 때나 사용되는 표 은 같다.

나. 시나리오 2: 미들웨어 벤더의 교체(Changing middleware vendors)

이번 시나리오에서 클라우드 고객은 클라우드 미들웨어 벤더를 교

- 31 -

체한다. 기존 벤더의 데이터, 쿼리, 메시지 큐, 응용 로그램들은 내보

내질 수 있어야 하고, 새로운 벤더의 미들웨어는 읽어 올 수 있어야

한다.

(1) 요구사항(Requirements)

o 산업 련 표 (Industry-specific standards): 한 벤더의 응용 로

그램에서 다른 벤더로 문서와 데이터를 이동시키기 해서는 두 응

용 로그램이 같은 포맷을 지원해야 한다. 그 포맷은 응용 로그램

의 타입에 따라 다를 것이다.o 클라우드 미들웨어를 한 공통 API(Common APIs for Cloud

Middleware): 이것은 클라우드 데이터베이스, 클라우드 메시지 큐, 미들웨어를 포함한 오늘날의 클라우드 서비스들에 의해 지원되는

모든 기능들이 포함된다. 데이터베이스와 테이블과의 연결, 생성, 삭

제 등을 한 APIs. 클라우드 데이터베이스 벤더들은 그들의 제품을 더 탄력 으로 만

들고, 처리를 해 많은 자원을 요구하는 큰 데이터 셋에 한 질의처

리를 제한하기 해 특정한 제약사항들을 용했다. 를 들어, 어떤

클라우드 데이터베이스는 테이블들을 상으로 하는 조인을 불허하고, 어떤 데이터베이스는 트루(true) 데이터베이스 스키마를 지원하지

않는다. 이와 같은 제한은 클라우드 데이터베이스 벤더들 사이에서의

이동, 특히 트루(true) 계형 모델을 기반으로 구축된 응용 로그램에

해서는 해결해야 할 큰 과제이다. 메시지 큐 같은 그 밖의 미들웨어 서비스는 서로 유사하기 때문에, 공통 API를 만들기가 더 단순할 것이다.

다. 시나리오 3: 클라우드 스토리지 벤더의 교체(Changing cloud storage vendors)

- 32 -

이번 시나리오에서 클라우드 고객은 클라우드 스토리지 벤더를 교

체한다.

(1) 요구사항(Requirements)

o 클라우드 스토리지를 한 공통 API(A Common API for Cloud Storage): 한 클라우드 스토리지 시스템에서 데이터를 읽고 쓰는 코

드는 가능하면 최소한의 변경사항만으로 다른 시스템과 연동할 수

있어야 한다. 그리고 그 변경 사항은 구성/설정 코드에 국한시켜야

한다. 를 들어, JDBC 응용 로그램에서 URL과 드라이버 이름의

포맷은 데이터베이스 벤더들마다 다르지만 그 데이터베이스와 상호

작용하는 코드는 동일하다.

라. 시나리오 4 : 가상머신 호스트의 변경(Changing VM hosts)

이번 시나리오에서 클라우드 고객은 한 클라우드 벤더의 시스템에

구축된 가상머신을 가져다가 다른 벤더의 시스템에서 실행시키길 원

한다.

(1) 요구사항(Requirements)

o 가상머신을 한 공통 포맷(A common format for virtual machines):　가상머신 포맷은 어떤 운 체제와도 작동해야 한다.

여기서의 가정은 가상머신 자체가 도우나 리 스 같은 운 체제

를 실행하고 있다는 이다. 이것은 가상머신의 사용자가 클라우드에

가상머신을 구축하기 에 랫폼을 선택한 것이고, 가상머신 안에서

동작하는 소 트웨어를 한 요구사항들은 클라우드와 연 되는 것이

없다.

- 33 -

7. 하이 리드 클라우드(Hybrid Cloud)

이번 이스는 퍼 릭 클라우드와 라이빗클라우드를 포함해서 여러

클라우드가 함께 동작하는 경우이다. 하이 리드 클라우드는 자기의 리

소스와 다른 제공자의 리소스를 결합하는 연합 클라우드 제공자에 의해

달될 수 있다. 로커도 한 하이 리드 클라우드를 제공할 수 있다. 차이 은 로커는 자신의 클라우드 자원들을 갖고 있지 않다는 이다. 하이 리드 클라우드 제공자는 소비자 요구조항에 따라 클라우드 자원들

을 리해야 한다.

(그림 1-12) 하이 리드 클라우드

하이 리드 클라우드의 소비자에게 본 유즈 이스는 앞에서 언 했던

최종 사용자와 클라우드 간(End User to Cloud)의 유즈 이스와 거의 차

이가 없다는 이 요하다. 사용자는 하이 리드 클라우드 제공자가 실

- 34 -

(그림 1-13) 커뮤니티 클라우드

제로 무엇을 하는지 알지 못한다.

가. 요구사항(Requirements)

o 트랜젝션과 동시성(concurrency)을 제외하고 앞에서 언 했던 모든

요구사항들이 용된다. 특히, 보안, 데이터와 어 리 이션의 연합, 그리고 상호운 성이 용된다.

o SLAs: SLA를 표 하는 표 포맷은 기계가 읽을 수 있어야 한다. 이는 하이 리드 클라우드 제공자로 하여 사람의 개입 없이 소비

자의 조건에 따라 자원들을 선택할 수 있게 한다. 제 2 에서 언 했듯이, 커뮤니티 클라우드의 요구사항은 하이 리

드 클라우드의 요구사항에 포함된다. 커뮤니티 클라우드는 공동의 목

을 갖는 기업들 간에 공유되는 인 라를 갖고 있다. 아래는 커뮤니

티 클라우드의 구성도이다.

- 35 -

RequirementEnd

User to

Cloud

Enterprise to

Cloud to End User

Enterprise to

Cloud

Enterprise to

Cloud to

Enterprise

private

Cloud

Changing

Cloud Vendor

s

Hybrid

Cloud

identity ✔ ✔ ✔ ✔

Open Client ✔ ✔ ✔ ✔ ✔ ✔ ✔

Federated Identity ✔ ✔ ✔ ✔

Location Awareness ✔ ✔ ✔ ✔ ✔Metering

and Monitoring

✔ ✔ ✔ ✔ ✔

Management ✔ ✔ ✔ ✔ ✔

[표 1-2] 요구사항들과 유즈 이스

커뮤니티와 커뮤니티 클라우드 사이의 통신은 인트라넷(Intranet)을 통

해 이루어진다. VPN이 될 수도 있지만, 근은 퍼 릭(공공) 인터넷을

통하지는 않는다.

8. 상호참조: 요구사항들과 유즈 이스(Cross-Reference: Requirements and Use Cases)

다음 표는 요구사항과 유즈 이스 사이의 계를 요약하고 있다.

- 36 -

and Governance

Security ✔ ✔ ✔ ✔ ✔ ✔ ✔

Deployment ✔ ✔ ✔Transactions

and Concurrency

✔

Interoperability ✔ ✔

Industry-Specific

Standards✔ ✔ ✔

VM Image Format ✔ ✔ ✔ ✔ ✔ ✔

Cloud Strorage API ✔ ✔ ✔ ✔ ✔

Cloud Database

API✔ ✔ ✔ ✔ ✔

Cloud Middleware

API✔ ✔ ✔ ✔ ✔

Data and Application Federation

✔ ✔ ✔ ✔

SLAs ✔ ✔ ✔ ✔ ✔ ✔ ✔

- 37 -

Lifecycle Management ✔ ✔ ✔ ✔

고객 시나리오

고객의 문제 해결 요구사항 기능

용 가능한 사용

이스

여 처리

• 처리 시간 감소• 하드웨어 요구 사항 감소• 미래 확장성 가능한 신축성

Iaas(VMs), cloudstrorageEnterprise toCloud

물류 로젝트

리

• 처리 시간 감소• 수작업 제거• 업데이트 되고 연속 인 개발 환경

PaaS (appframework),cloudstorageEnterprise toCloudtoEndUser

앙 정부 • IT 문 기술 통합• 하드웨어 요구사항 축소

IaaS, PaaS Private Cloud지방 정부 • IT 문 기술 통합

• 하드웨어 요구사항 축소 IaaS, PaaS Hybrid Cloud

천문학 인 데이터 처리

• 하드웨어 비용을 크게 감소( 로세싱 원과 장장치)• 에 지 비용을 크게 축소• 리의 간소화

Iaas(VMs), cloudstrorageEnterprise toCloudtoEndUser

[표 1-3] 고객 시나리오

제 4 고객 시나리오

이번 은 본 유즈 이스의 고객 경험을 설명한다. 여기에 그러한 고객

들의 시나리오가 요약되어 있다.

1. 고객 시나리오: 클라우드에서의 여처리 (Payroll Processing in the Cloud)

- 38 -

가. 제 3 에서 용 가능한 유즈 이스:

기업과 클라우드 간

나. 고객 시나리오:

이 시나리오에서는 두 의 서버가 복잡하고 시간이 소요되는 여

처리를 해 할당되어 있다. 이 기 에서는 클라우드 환경에서 여처

리를 하는 것이 얼마나 실용 인지를 보기로 결정했다. 기존의 여

시스템은 분산 응용 로그램으로 설계되어 있어서 클라우드 환경으

로 옮기기가 상 으로 수월했다.여 응용 로그램은 직원들의 데이터 처리를 해 SQL 데이터베이

스를 사용했다. 클라우드 데이터베이스 서비스를 사용하기 해 응용

로그램을 재 작성하기 보다는, 데이터베이스 서버가 있는 가상머신

을 배치했다. 데이터베이스 서버는 클라우드 스토리지 시스템으로부터

데이터를 읽어서 그것을 가지고 계형 테이블을 만들었다. 원본 데이

터베이스의 크기 때문에, 오직 여 처리를 해 필수 인 정보들만을

추출하도록 추출도구들을 사용하 다. 그 추출된 정보는 클라우드 스

토리지 서비스로 송되었고, 데이터베이스 서버에 의해 사용되었다. 여 응용 로그램은 동시에 실행되는 가상머신 4곳에 배치되었다; 그러한 4개의 가상머신은 데이터베이스 서버를 호스 하는 가상머신

과 함께 작동한다. 여 응용 로그램의 구성은 데이터베이스 서버를

호스 하는 가상머신을 사용하도록 변경되었으며, 그 이외에 어 리

이션에 한 다른 변경은 없었다.

다. 고객의 문제 해결

클라우드 기반 버 에서의 응용 로그램에서는 여 작업의 처리

시간이 80% 감소되었다. 추가 인 혜택으로, 이 에 여처리 용으

- 39 -

로 사용되던 두 의 서버가 다른 작업을 해 사용될 수 있었다. 마

지막으로, 클라우드 기반 버 은 훨씬 더 신축성이 있고 이는 그 조직

이 확장됨에 따라 상당한 이 이 될 것이다.

라. 요구사항들과 기능(Requirements and Capabilities):

사용된 클라우드 서비스들은 가상 머신들과 클라우드 스토리지(IaaS)다. 여 응용 로그램은 수정될 필요가 없었고, 단순히 가상 머신

에 배치되었다. 클라우드 데이터베이스를 사용하도록 데이터 구조와

응용 로그램을 수정하는 신에 계형 데이터베이스 서버가 클라

우드에 배치되었다. 유일하게 사용된 API는 S3 클라우드 스토리지 API이다.

마. 이식성에 한 우려:

여 응용 로그램은 Fedora와 Java 1.5에서 실행되기에 Fedora를

지원하는 모든 클라우드 제공 업체의 랫폼에서 아무런 변경 없이

실행될 것이다. 만약 다른 업체가 여 처리 과정에서 사용되었던 특

정 S3 API를 지원하지 않는다면, 다른 클라우드 스토리지 공 자를 사

용 하기 해 응용 로그램을 수정하는 것은 문제가 될 수도 있다. 마지막으로 클라우드 데이터베이스를 사용하도록 응용 로그램을 변

경하는 것은 무척 어려울 수도 있다. 특히 혹시라도 계형 모델을 지

원하지 않는 클라우드 데이터베이스로 이동하는 것이라면 더욱 어려

울 수 있다.

2. 고객 시나리오: 클라우드에서의 로젝트 리

가. 제 3 에서 용 가능한 유즈 이스

- 40 -

기업과 클라우드 그리고 최종 사용자 간

나. 고객 시나리오:

약 20명의 행정 직원을 둔 소 건설 회사는 그들의 자원을 리하

고, 로젝트 스 링을 최 화하며 작업 비용을 계산 할 방법이 필

요했다. 이 회사는 일반 인 시스템과는 달리 매우 구체 인 요구사항

들을 가지고 있었기에 Quickbooks와 스 드 시트의 조합을 사용하

다. 이 시스템은 신축성이지 않으며 큰 인 자원의 낭비 다. 이 문제에 한 해결책은 고유의 클라이언트용 응용 로그램을 구

축하는 것이었다. 모든 비즈니스 논리는 클라이언트에 있다. 그 응용

로그램 한 데이터는 Google App Engine (GAE) 데이터스토어에서

제공된다. 이 데이터스토어는 비록 RDF-OWL 온톨로지(ontology)를 호

스트 하지만 이 데이터스토어는 RDF 그래 이외에는 어떤 종류의 스

키마도 지원하지 않는다. 클라이언트는 이 온톨로지(ontology)를 사용

하여 사용자에게 데이터를 보여주기 에 는 데이터를 다시 GAE로

보내기 에 데이터의 유효성을 검사한다. 데이터 작업들은 HTTP를 통한 응용 련RESTful 로토콜을 사용

하여 데이터스토어와 통신된다. 데이터스토어는 서버에서 리되는

silos 내에서 제공되고 있는 응용 로그램에 련된 RDF 그래 를 유

지한다

보안은 데이터의 특별한 silo를 사용하는 응용 로그램의 요구사항에

따라 별도로 각각의 silo를 해 구 된다. 이러한 시스템을 사용하여

어떠한 숫자의 응용 로그램들도 각각에 해 새 코드 기반을 구축

하지 않고 데이터 스토어를 사용할 수 있습니다. 데이터는 로컬에 호스트 된 Quickbooks SQL 서버와 사용자 지정 스

드 시트를 업로드하기 에 데이터를 일치시키는 일회성 데이터

마이그 이션 스크립트(one-time data migration script)를 사용하여

GAE 데이터 스토어로 옮겼다. 데이터세트는 작고 쉽게 로컬 리소스를

- 41 -

사용하여 처리되었다. 클라이언트 응용 로그램은 데이터의 가장 최근 변경 사항의 일부

를 포함하는 로컬 데이터 장소를 유지한다. 응용 로그램의 REST 아키텍처는 HTTP에 내장된 캐슁 기능을 이용하여 자동으로 마스터

데이터 스토어의 변경 사항이 클라이언트에게 달되도록 한다. 데이

터의 일부 서 셋만을 사용함에 따른 성능상의 이 과 더불어 이러한

설계는 보안을 단순화한다. 만약 클라이언트 응용 로그램이 특정 필

드 는 코드에 근할 필요가 없다면, 데이터 스토어의 그러한 부

분은 서버를 벗어나지 않는다.

다. 고객의 문제 해결:

데이터는 미흡한 소 트웨어와 스 드시트 매크로의 비효율 인

시스템에서 클라우드 기반 시스템으로 옮겨졌다. 그 결과 데이터스토

어가 다양한 종류의 응용에서 사용될 수 있고, 앞으로의 개발 유지

보수를 훨씬 간단하게 만들 수 있다. 비록 원래 응용 로그램 인 라는 여 히 사용되고 있지만, 그 인

라에서 작성된 응용 로그램들은 데이터를 분석하고 조작하기 해

서 더 이상 스 드시트에 의지할 필요가 없다. 스 드시트를 더

이상 유지할 필요가 없다는 은 큰 비용 감을 가져온다. 게다가 손

으로 데이터를 자르고 붙이는 일은 더 이상 작업의 일부가 아니며, 따

라서 지루한 작업과 오류의 원인을 제거 할 수 있다

라. 요구사항들과 기능:

여기서 사용된 클라우드 서비스는 데이터베이스를 지원하는 PaaS구

물인 Google App Engine을 사용하 다. RESTful API와 클라우드 데

이터스토어의 조합은 통 인 계형 데이터베이스를 사용하여 구

한 경우보다 더욱 신축성 있는 응용을 만드는 것이 가능하다.

- 42 -

마. 이식성에 한 우려:

이 응용 로그램은 Google App Engine과 그 BigTable 에서 실행

된다. BigTable은 신축성(elasticity)을 갖는 분산된 다차원의 정렬 맵이

다. 이건 다른 부분의 데이터스토어들과는 큰 차이를 갖는 것으로

응용 로그램 개발에 해 근본 으로 다시 생각할 것을 요구한다. 보다 통 인 데이터스토어에서 실행되도록 그 응용 로그램을 이

식한다면 그 응용의 구조를 크게 바꾸어야 했을 것이다.

3. 고객 시나리오: 클라우드에서의 앙 정부 서비스

가. 제 3 에서 용 가능한 유즈 이스

라이빗 클라우드

나. 고객 시나리오:

일본 정부의 부처들은 그들의 인 라에 수 천 의 서버들을 가지고

있다. 앙 정부는 정부 응용 로그램들을 호스 하기 해서 보안과

앙집 식 인 라를 제공하는 "카수미가세키(Kasumigaseki)"라 불리

는 라이빗 클라우드 환경을 발표했다. 여, 회계와 인사 리 같은 존하는 백오피스 시스템들은 클라우

드 환경에서 가상화되고 호스 될 것이다. 자 조달과 같은 일부

론트 오피스 시스템들은 퍼블릭 클라우드에 가상화 될 것이지만 그것

은 이 로젝트의 범 밖이다. 이 로젝트의 궁극 인 목 은 복

되는 시스템과 각 부처에 있는 리자의 필요성을 제거하여 총 소유

비용을 이는 것이다.

- 43 -

다. 고객의 문제 해결

카수미가세키에 의해 해결된 3가지 문제는 비용 감, 에 지 소비

감, IT 인력의 감축이다.

라. 요구사항들과 기능

클라우드 인 라는 일본 통신 회사에 의한 라이빗 네트워크에 만

들어지게 된다. 개인정보 보안이 주요 우려 사항이기 때문에 라

이빗 클라우드가 요구된다. 많은 타입의 개인 정보들이 일본 국외에

서버에 장되는 것은 불법이다.

마. 이식성에 한 우려

정부가 정부의 자체 응용 로그램들을 호스트 하기 해서 자체

라이빗 클라우드를 만들고 있기 때문에 이식성은 문제가 되지 않는다. 정부는 앙 집 된 응용 로그램과 데이터들을 라이빗 클라우드에

서 퍼 릭 클라우드로 이동할 의도가 없다.

4. 고객 시나리오: 하이 리드 클라우드에서의 지방 정부 서비스

가. 제 3 에서 용 가능한 유즈 이스

하이 리드 클라우드

나. 고객 시나리오:

일본 역에는 자체 서버와 IT인력을 가지고 있는 지방 자치 정부가

1800개 이상 있다. 카수미가세키의 클라우드의 2 차 목표는 하이 리

- 44 -

드 클라우드 환경을 제공하는 것이다. 카수미가세키 클라우드에 추가

으로 일본의 앙 정부는 일본의 행정 구역인 수 에서 지방 정

부를 그룹화 하기로 결정했다. 각 은 라이빗 클라우드를 가질 것

이고 이것을 카수미가세키 하이 리드 클라우드와 연결할 것이다. 내

부 업무들과 일부 데이터는 의 라이빗 클라우드에 호스트 될 것

이며, 그 외 다른 데이터는 로컬에 장된다. 동안 내부 업무 일부

데이터는 내의 라이빗 클라우드에 호스트 될 것이다. 가능한 최

한으로 기존 시스템들은 가상화되고 카수미가세키 클라우드에 호스

트 될 것이다.

다. 고객의 문제 해결:

이 하이 리드 클라우드에서 해결된 세 가지 문제들이 비용 감, 에 지 소비 약 그리고 IT 인력의 감소이다.

라. 요구 사항들과 기능:

개인 정보 보호 보안은 이 시나리오에 아주 요하다. 일본 법률

은 일부 유형의 데이터가 지방 자치 단체 서버 이외의 외부에 장되

는 것을 지하고 있다. 그래서 응용 로그램 데이터가 카수미가세

키 클라우드로 이동하는 것은 고려할 옵션이 아니다. 일부 로세싱은

지방 자치 단체의 인 라에 있기 때문에, 하이 리드 클라우드 내의

응용 로그램들과 데이터들을 통합하는 것은 매우 요하다.

마. 이식성에 한 우려:

이 고객 시나리오와 마찬가지로 정부가 자체 라이빗 클라우드

(private cloud)를 구축하기 때문에 이식성에 한 우려는 없다. 정부는

앙 집 된 응용 로그램과 데이터들을 라이빗 클라우드에서 퍼

- 45 -

릭 클라우드로 이동할 의도가 없다.

5. 고객 시나리오: 천문 데이터 처리

가. 제 3 에서 용 가능한 유즈 이스

최종 사용자와 클라우드 간

나. 고객 시나리오:

가이아(Gaia)는 우리의 은하계에 있는 10 억 개의 별들을 조사하는

유럽 우주국(European Space Agency, ESA)의 임무이다. 그것은 5 년간

의 기간 동안 약 70번씩 각각의 해당 별들을 찰하고, 정확한 별들의

치, 거리, 움직임과 밝기의 변화를 차트화 시킨다. 여분의 태양 항성

들 는 갈색 난쟁이라 불리는 떨어진 항성들과 같은 새로운 수십만

개의 천상의 개체들을 발견할 것으로 기 되고 있다. 이 임무는 분석해야 할 량의 데이터를 수집할 것이다. ESA는 그

데이터를 분석하기 해 클라우드 기반의 시스템을 모델로 결정했다. 목표는 규모 데이터 세트를 처리하기 해 클라우드 컴퓨 을 사용

하는 것에 해 기술 인 그리고 비용 인 면들을 결정하기 한 것

이다. 로토타입 시스템에서는 작업 실행 데이터 처리를 해 분산

컴퓨 (자체 개발) 임워크가 사용된다. 임워크는

AGIS(Astrometric Global Iterative Solution)를 실행하도록 구성되어 있

고, 이 로세스는 그 결과가 수렴할 때까지 이 데이터들을 상으로

반복 으로 실행된다. 처리를 해선, 각각의 작업 노드들은 데이터베이스에서 작업 설명

을 수신하고, 데이터를 가져온 후, 처리하여 간 단계의 서버로 결과

를 보낸다. 이 간 단계의 서버는 그 다음 반복을 하여 데이터를

- 46 -

갱신한다. 이 로토타입은 2백만 개 항성들의 5년치 데이터를 평가했으며, 이는 실제 로젝트에서 처리해야 할 체 데이터의 일부분이다. 로토

타입은 20개의 가상 머신들을 40시간 동안 실행시키는 것과 동등한

각각 100분씩 소요되는 작업을 24번 반복했다. 체 로젝트에서는 1억 개의 주 행성들의 6년치 데이터가 분석될 것이고, 이는 20개의 가

상머신 클러스터를 16,200시간 동안 실행시켜야 한다. 클라우드 기반 솔루션의 신축성(elasticity)을 평가하기 해, 로토

타입은 120개의 고성능 CPU를 가진 형 가상머신들로 두 번째 테

스트를 시행하 다. 각 가상머신에는 12개의 쓰 드들이 실행되고

1,440개의 로세스들이 병렬로 동작하고 있었다.

다. 고객의 문제 해결:

클라우드 기반 솔루션에 한 상 비용은 자체 솔루션 비용의

반 이하이다. 그 비용 견 은 추가 인 기 는 시스템 자체 솔루션

의 리 비용을 포함하지 않았기에 실제 비용 감은 더 클 것이다. 데이터세트의 스토리지 한 클라우드 기반이 될 것이다. 두 번째 테스트에서는 데이터베이스에서 SQL 쿼리와 락(lock) 경합

에 련된 성능 문제가 몇 개 감지되었으나 해결되었다. 이러한 문제

는 재의 자체 시스템에서는 감지될 수 없었을 수도 있다. 이 로토

타입은 이 기 이 실제 구축 에 성능과 신축성 련 문제를 찾아내

고 해결할 수 있도록 했다.

라. 요구사항들과 기능:

이 로토타입은 AGIS 소 트웨어와 데이터베이스를 해 가상머신

을 사용했다. 데이터베이스는 가상머신 내에서 실행되는 통 인 데

이터베이스로서 클라우드 데이터베이스가 아닌 완 한 계형 데이터

- 47 -

베이스이다. 스토리지는 각 100GB 클라우드 스토리지 5개가 데이터베

이스 서버에 연결되었다.

마. 이식성에 한 우려:

모든 가상머신들은 표 운 체제를 사용하고 있고 로젝트에서

사용된 어떤 소 트웨어도 클라우드와 련되지 않았다. 이러한 응용

에서 이식성에 한 고려사항은 가상머신 이미지들을 다시 만들거나

재설정하지 않고도 다른 제공자의 시스템으로 옮기는 것이다.

제 5 개발자 요구사항

개발자들을 한 요구 사항들은 모든 사용 이스 고객 시나리오들

을 통해 도출된 것이다. 논의를 단순화하기 해, 개발자들의 모든 요구

사항들을 여기에 나열하 다. o 슁(Caching): 클라우드 리소스에 한 캐싱을 지원하는 로그래

툴킷은 응용 로그램의 성능을 높일 것이다. 개발자는 캐시를 비우기

한 API가 필요하고, 캐시에 특정 개체 는 리소스를 넣을 때도

API가 필요할 수 있다.o 앙집 된 로깅(Centralized Logging): 로깅은 자신의 역할 는 그

들이 작성하고 있는 응용 로그램들의 유형에 계없이 모든 개발자

를 한 공통된 요구 사항이다. API는 로그에 쓰기, 로그 기록 검토, 로그 생성, 그리고 로그 일을 열고 닫는 것 등을 지원해야 한다.

o 데이터베이스(Database): 개발자는 클라우드 데이터베이스에 근할

수 있는 방법이 필요하다. 클라우드 데이터베이스들은 그들의 설계가

많이 다르다. (일부는 스키마 기반이면서 계형이고, 많은 경우에

는 둘 다 아닌) 때문에 개발자들은 각각의 응용 로그램의 필요에 따

- 48 -

라 클라우드 데이터베이스 공 자를 선택한다. 데이터베이스 API는

기본 인 CRUD(Create, Read, Update, Delete) 기능들을 지원해야

한다.o 식별자 리(Identity Management): 개발자는 ID를 리하는 방법이

필요하다. 가장 간단한 경우에는 이러한 요구가 주어진 사용자의 자격

증명을 인증할 수 있어야 한다. 한 응용 로그램이 여러 데이터 소스

응용 로그램들과 함께 작업이 이루어지는 경우에는 개발자가 사용

자의 ID를 통합할 수 있는 방법이 필요하다. 통합 ID 리 시스템은

서비스와 사용자가 서로의 정보를 가지고 있지 않는 경우에도 특정 서

비스에 액세스하려는 해당 사용자를 허용하도록 자격 증명을 생성할

수 있다. 식별자(신원) 리를 한 API는 제 로 자격증명을 캐시하

고 삭제하여야 한다.o 메시징- (Messaging - Point-to-Point): 개발자들은 큐에 메시지들

을 추가하고 이런 메시지들을 사용하기 해서 API가 필요하다. API는

한 개발자가 메시지를 엿볼 수 있도록 허용해야 한다. (메시지의 내

용을 소모하지 않고 검사만 하는 경우)o 메시징(Messaging - Pub-Sub): 개발자는 메시지 큐잉 시스템의 주

제들과 작업을 하기 한 API가 필요하다. 이 API는 개발자들이 특정

주제에 메시지를 게시할 수 있도록 하고, 한 주제에서 메시지를 가져

갈 수 있다.o Raw Compute / Job Processing: 개발자들은 Hadoop 스타일 데이터

마이닝과 같은 용량 로세싱 작업을 하기 해 API가 필요하다. 이 API는 개발자들이 처리 작업을 시작, 정지, 모니터 일시 지

할 수 있도록 허용해야 한다.o 세션 리(Session Management): 사용자 세션을 리하기 한 능력

은 특히 클라우드 환경에서 아주 요하다. 클라우드의 인 라는 노드

의 실패를 고려해도 복성과 탄력성이 있기 때문에 특정 클라우드 노

드가 다운될 경우에도 세션이 유지되어야 한다. 세션 API는 근하기

쉽게 하거나 사용자 세션의 재 상태를 조작할 수 있어야 한다.

- 49 -

Developer Requirement

Ordinary Program

mingDeployme

ntCloud

Service

Image and

Infrastructure

Management

Internal Interfaces

Caching ✔ ✔Centralized

Logging ✔ ✔ ✔ ✔ ✔Database ✔ ✔Identity

Management ✔ ✔ ✔ ✔Messaging –

Point-to-Point ✔Messaging –

Pub-Sub ✔

[표 1-4] 개발자 요구사항

o 서비스 발견(Service Discovery): 개발자는 어떠한 클라우드 서비스가

사용 가능한지 발견할 수 있는 방법이 필요하다. 클라우드 서비스는

서비스의 종류에 따라 탐색이 가능해야 하고 각 서비스 유형에 한

추가 인 기능들을 제공하는 API가 있어야 한다. o SLAs: 서비스 검색을 이용하는 개발자들은 그들의 코드가 사용하는

서비스의 정책을 결정하기 해 자동화된 방법이 필요하다. 이러한

API를 통해 개발자는 클라우드 서비스와 연동되는 응용 로그램을

작성할 수 있으며, 이 응용 로그램의 SLA 항목에 가장 합한 서비

스를 선택할 수 있다. o 스토리지: 개발자들는 클라우드 스토리지 서비스에 액세스할 수 있는

방법이 필요하다. API는 데이터 메타 데이터를 장하고 검색할

수 있도록 해야 한다. 다음의 표는 개발자의 요구 사항들과 함께 제 2 에서 논의된 5가지

서로 다른 API 유형들을 상호참조하고 있다.

- 50 -

Raw Compute /JobProcessing ✔ ✔ ✔

Service Discovery ✔ ✔ ✔ ✔Session

Management ✔ ✔SLAs ✔ ✔ ✔ ✔ ✔

Storage ✔ ✔ ✔ ✔

제 6 보안 시나리오

다른 분야에서도 마찬가지지만, 클라우드 컴퓨 에서 보안은 아주

요한 문제이다. 여기서 강조하는 것은 기획자들이나 개발자들이 클라우드 컴퓨 으로

옮겨 갈 때, 보안 문제를 꼭 고려해야 한다는 것이다. 명심할 것은 클라우드 컴퓨 을 용한다고 해서 보안에 한 어떤 새

로운 이나 문제가 생겨나지는 않는 다는 이다. 상황을 고려해 볼

때, 클라우드 컴퓨 은 체 으로 클라우드 배포 모델에 계없이 일

성, 투명성, 표 기반 보안 임워크에 한 필요성을 강조하는 이상

인 유즈 이스로 간주될 수 있다. 기업들이 클라우드 컴퓨 으로 솔루

션을 옮기거나 구축할 때, 이 일 된 보안 모델을 갖추는 것은 개발을

단순화하고 벤더 종속(lock-in)을 피하고 IT 투자를 유지하는 데에 필수

요소다. 어떤 특정 기술 인 문제 이슈들과는 달리 클라우드 컴퓨 의 에

서 보안을 고려할 때 가장 큰 차이 은 기업의 제어권 손실이다. 기업

내부 응용 로그램에서 민감한 데이터와 응용 로그램에 한 근 제

어는 매우 요하다. 클라우드 기반의 응용 로그램에서도 근 제어는

동등하게 요하지만, 인 라 스트럭쳐, 랫폼, 응용 로그램에 한 보

- 51 -

안은 특정 클라우드 제공자에게 직 인 제어권이 있다. 이번 장에서는 아래의 순서에 맞추어 보안 주제들을 설명한다. o 규정 : 규정은 기술 인 문제는 아니지만, 꼭 다 져야 한다. 법과 규

정은 기능 요구사항 보다 상 의 보안 요구사항을 정의한다. o 보안 제어 : 비록 소비자가 모든 보안 제어를 필요로 할런지는 모르겠

지만, 소비자들은 모든 보안제어가 가능한 인 라도 없이 보안과 련

해서 안심시키는 주장을 하는 클라우드 제공자들을 경계해야 한다.o 보안 통합 패턴 : 이러한 보안 제어를 구 하기 해서는 몇 가지 통

합 패턴들이 필요하다. 클라우드 제공자들은 기존의 보안 표 들을 통

해서 이러한 패턴들을 달해야 한다. 이러한 에서 사용자 유즈 이스 시나리오에 한 논의를 다음 장

에서 하도록 한다. 1. 규정 (regulation)

클라우드 컴퓨 을 사용하는 에 따른 기술 인 이슈들을 제외하면

규제라는 엄격한 실이 존재한다. 여러 가지 이유로, 세계의 정부들은

클라우드 컴퓨 의 사용에 해 우려를 하고 있다. 많은 나라들은 그 나

라 밖에 치한 물리 인 머신에 특정 데이터를 장하는 것을 지하는

엄격한 개인정보 법률을 가지고 있다. 이러한 법률을 반 할 시에는 기

업을 ( 는, 경 진들) 처벌하는 무거운 처벌 규정들이 종종 존재한다. 클라우드에 민감한 데이터를 장하는 모든 기업과 기 은 그들의 클

라우드 제공자가 특정 지역 밖에 치한 물리 서버에 데이터를 장하

지 않는다는 것을 증명할 수 있어야 한다. 정부기 을 포함하여 많은 무역 산업 단체들도 역시 규제들을 만든

다. 비록 이런 규제들은 법에 의해 요구되지 않을 수는 있지만, 잘 알려

진 행을 따른다. 비슷한 우려가 클라우드에서 동작하는 어 리 이션들에게도 용된

다. 한 가상 머신이 클라우드에서 실행되고 있다면, 그 가상 머신에서

- 52 -

Security Control Description자산 리

(Asset Management)

클라우드 인 라를 구성하는 모든 물리 혹은 가상의

하드웨어, 네트워크, 소 트웨어 자산을 리할 수 있어

야 한다. 여기에는 감사 규정 수의 목 을 해서는

어떠한 자산에 한 어떤 물리 혹은 네트워크 기반의

근이 설명될 수 있어야 함을 포함한다.암호화: 키와

인증서 리

(Cryptography : Key and Certificate

Management)

모든 안 한 시스템은 암호화 키와 인증서를 용하고

리하는 인 라가 필요하다. 여기에는 작동할 때나 안

할 때나 정보 보안을 지원하는 표 기반의 암호화 기

능과 서비스를 용하는 것이 포함된다.

데이터/스토리지 암호화된 형식으로 데이터를 장하는 것이 가능해야 한

[표 1-5] 보안 제어와 유즈 이스

작동하는 어 리 이션은 민감한 데이터에 근할 수 있는가? 비록 새로

운 법률과 규정들이 지속 으로 만들어지고 있다 하더라도, 이것이 많은

나라들이 해결하지 못한 부분이다. 이러한 법률과 규정들을 따르는 것은 모든 다른 요구사항들에 비해 높

은 우선순 를 가질 것이다. 한 신규 법률은 한 기 에게 그들의 자원을

이용하여 기능을 추가하는 정도가 아니라 한 응용 로그램의 인 라스

트럭처를 변경하도록 요구할는지도 모른다. 그 CIO의 사무실은 이런 변

화를 리해야 하고 새로운 법률과 규정들이 만들어지는 것에 해 민감

히 처하여야 한다.

2. 보안 제어

몇 개의 제어들은 모든 시스템들의 한 보안을 해서 필요하다. 다음 장은 여러 유즈 이스들과 그들 각각에 따른 보안 요구사항들을 기

술한다. 유즈 이스들에 한 논의는 여기 정의된 제어권에 한 유즈

이스들의 요구사항들과 련이 있다.

- 53 -

보안 (Data / Storage Security)

다. 한, 일부 소비자들은 그들의 데이터가 다른 소비자

들의 데이터와 분리되어 장되는 것을 요구할 것이다. 종 보안

(Endpoint Security)

소비자들은 그들의 클라우드 자원에 한 종 을 보호할

수 있어야 한다. 여기에는 네트워크 로토콜과 디바이스

타입에 따라 종 을 제한할 수 있는 기능을 포함한다.

이벤트 감사와

보고

(Event Auditing and Reporting)

소비자들은 클라우드에서 발생하는 이벤트, 특히 시스템

오류와 보안 침해에 한 데이터에 근할 수 있어야 한

다. 이벤트에 한 근은 과거의 이벤트들에 한 인지

능력과 그들의 발생으로 인한 새로운 이벤트들에 한

보고가 포함된다. 클라우드 제공자들은 시에 이벤트들

을 보고하지 못 할 경우, 자신들의 평 에 상당한 피해를

입게 될 것이다.식별자, 역할, 근제어와 속성

(Identity, Roles, Access Control and Attributes)

클라우드 기반 자원들에 한 효과 으로 근 제어를

구 하고 보안 정책을 시행하기 해서는 일 성 있고

기계가 독할 수 있는 방식으로 개인과 서비스들의 식

별자, 역할, 권리와 그 밖의 다른 속성들을 정의할 수 있

어야 한다.네트워크 보안

(Network Security)

스 치, 라우터, 패킷 벨에서 네트워크 트래픽의 안

을 확보할 수 있어야 한다. IP 스택 자체도 역시 안 을

확보할 수 있어야 한다.

보안 정책

(Security Policies)

일 성 있고 기계 독 가능한 방법으로 정책을 정의하

고, 근 제어와 자원 할당, 그 밖의 다른 결정들을 지원

하는 보안정책을 결정하고 용할 수 있어야 한다. 정책

을 정의하는 방법은 SLA와 라이선스들이 자동으로 용

될 수 있을 정도로 충분히 견고해야 한다.서비스 자동화

(Service Automation)

보안 수 감사를 지원하기 해 보안 제어 흐름과 과정

을 자동화된 방법으로 리하고 분석할 수 있어야 한다. 여기에는 보안 정책이나 고객 라이선스 계약을 반하는

모든 이벤트들을 보고해야 한다는 도 포함된다.작업량과 서비스

리(Workload and Service

Management)

정의된 보안 정책과 고객 라이선스 계약에 따라서 서비

스들을 구성하고, 배포하고, 모니터 할 수 있어야 한다.

- 54 -

Security Control Relevant Standard암호화: 키와 인증서

리 (Cryptography : Key and Certificate

Management)

KMIP, the OASIS Key Management Interoperability Protocol(http://www.oasis-open.org/committees/kmip/)

데이터/스토리지 보안

(Data / Storage Security)

IEEE P1619, developed by the IEEE Security in Storage Working Group(http://siswg.net)

식별자, 역할, 근제어와 속성

(Identity, Roles, Access Control and Attributes)

SAML, the OASIS Security Assertion Markup Language(http://saml.xml.org/)

식별자, 역할, 근제어와 속성

(Identity, Roles, Access Control and Attributes)

X.509 Certificates, part of the ITU Public Key and Attribute Certificate Frameworks Recommendations(http://www.itu.int/rec/T-REC-X.509)

보안 정책

(Security Policies)

XACML, the OASIS eXtensible Access Control MarkupLanguage(http://www.oasis-open.org/committees/xacml/)

작업량과 서비스 리

(Workload and Service Management)

SPML, the OASIS Service Provisioning Markup Language(http://www.oasis-open.org/committees/provision/)

[표 1-6] 보안 제어와 련 표

여기에는 이러한 제어권들에 용될 수 있는 일부 표 들이 있다.

3. 보안 통합(federation) 패턴

통합은 많은 수의 독립된 자원들이 마치 하나의 자원처럼 동작하는 능

력이다. 클라우드 컴퓨 자체가 자원들의 통합이고, 그래서 많은 자산

들, 식별자들, 구성들, 그리고 클라우드 컴퓨 솔루션의 그 밖의 다른

세부 사항들은 클라우드 컴퓨 을 실질 이며 실 으로 만들기 해서

- 55 -

는 통합되어야 한다.앞 에서 언 했던 요구사항들은 다음의 통합 패턴들을 통해 구 된다.o 신뢰 : 인증기 을 통해 두 단체가 신뢰 계를 정의하는 능력을 말한

다. 그 인증기 은 신임장(일반 으로 X.509 인증서)을 교환 할 수 있

고, 그러면 이러한 인증서를 이용하여 메시지들의 안 을 확보하고 서

명된 보안 토큰(일반 으로 SAML)을 생성할 수 있다. 통합 신뢰는

다른 모든 보안 통합 패턴의 기 가 된다. o 식별자 리 : 사용자의 자격증(사용자 ID와 비 번호, 인증서 등)을

받고, 그 사용자를 인증하는 서명된 보안 토큰을 반환하는 식별자 제

공자를 정의하는 능력. 그 식별자 제공자를 신뢰하는 서비스 제공자는

비록 그 서비스 제공자가 사용자에 한 정보가 하나도 없더라도, 사

용자에게 한 근을 허용하는 토큰을 사용할 수 있다. o 근 리 : 클라우드 자원들에 한 근을 리하기 한 보안 토큰

을 검사하는 정책(일반 으로 XACML)을 만드는 능력. 자원들에 한

근은 한 가지 이상의 요인들에 의해 제어될 수 있다. 를 들어, 어

느 한 자원에 한 근은 어느 특정 역할을 담당하는 사용자들에게는

특정 로토콜을 통해서 는 하루 어떤 특정 시간에는 제한될 수

있다. o 단일 사인-온/사인-오 : 신뢰기 으로부터의 자격증을 기반으로 로

그인을 통합하는 능력. 특정 역할의 인증된 사용자가 있다면, 통합 단

일 사인-온은 그 사용자가 한 어 리 이션에 로그인 한 후, 같은 신

뢰기 을 신뢰하는 다른 어 리 이션에 해서도 근 할 수 있도록

한다. 통합 단일 사인-오 도 이 같은 패턴을 따른다. 많은 경우에 사

용자가 하나의 어 리 이션에 해서 로그아웃 하면, 필히 다른 어

리 이션에 해서도 로그아웃 되어야 할 것이다. 단일 사인-온 패턴

은 식별자 리 패턴에 의해 가능하다. o 감사 규정 수 : 하이 리드 클라우드를 포함하여, 여러 도메인들

에 퍼져 있는 감사 규정 수 데이터를 모으는 능력. 통합 감사는

SLAs와 규제 요구 사항들에 한 수 보장과 문서화를 해 필수이

- 56 -

다. o 설정 리 : 서비스, 어 리 이션, 가상 머신을 한 설정 데이터를

통합하는 능력. 이런 데이터는 여러 도메인들 간에 걸친 근 정책과

라이센스 정보를 포함 할 수 있다. 기존의 보안 모범 사례가 클라우드에 용되기 때문에, 제공자들은

와 같은 통합 패턴들을 제공하기 해 기존의 표 들을 사용해야 한다.

제 7 보안 유즈 이스 시나리오

이번 장에서는 보안 요구 사항을 만족하면서 클라우드 컴퓨 을 사용

하는 고객의 경험을 설명한다. 정의된 요구 사항들과 패턴들을 고려하면

서 실제로 용되는 클라우드 보안을 묘사하기 한 실제 시나리오를 보

도록 한다. 이 시나리오는 다양한 어 리 이션 타입, 용(배포) 모델, 그리고 패턴과 역할을 다룬다.

1. 클라우드에서의 컴퓨 워

가. 고객 시나리오:

어느 한 보험 회사는 그들의 정책 소유자(고객)와 그들이 받은 모든

재산 피해에 한 데이터를 추출하는데 사용되는 보험청구 어 리

이션을 가지고 있다. 한 허리 인은 미국의 걸 해안 지역을 공격하

여, 막 한 재산 피해를 입힐 것으로 상된다. 이것은 수많은 보험청

구를 만들어낼 것이고, 이어서 기업의 IT 인 라에 엄청난 부하를 만

들 것이다. 이 회사는 상되는 수요를 처리하기 해서 가상 머신을 제공하는

퍼블릭 클라우드 제공자를 이용하기로 결정했다. 이 회사는 회사의 인

- 57 -

Requirement Controls특정 역할들로 제한하기 한

비디오 근

• 식별자, 역할, 근 제어와 속성들

• 자산 리

• 네트워크 보안

어 리 이션이나 데이터의 모든

흔 들은 가상 머신이 종료되면

모두 제거되어야 한다. • 워크로드와 서비스 리

[표 1-7] 보안 시나리오 1 에 필요한 요구사항들

증된 리인들만이 근이 허용되도록 하면서, 기업 자신의 시스템과

클라우드 제공자로부터 호스 받은 가상 머신들 사이의 근을 제어

해야만 한다. 한, 회사는 클라우드 기반의 어 리 이션에 의해 생

성된 모든 데이터도 회사 방화벽 안으로 안 하게 송해야 한다. 마

지막으로, 클라우드 제공자는 가상 머신이 종료할 때는 언제나 어 리

이션이나 련 데이터의 흔 이 남아있지 않도록 보장해야 한다.

나. 고객의 문제 해결:

퍼블릭 클라우드를 사용하면, 회사는 평소보다 몇 십 배 더 큰 규모

의 워크로드를 처리 할 수 있다. 상상할 수 있는 가장 높은 워크로드

를 처리하기 해 충분한 여분의 시스템을 구매, 유지, 원공 , 그리

고 냉각하는 것은 경제 으로 비효율 이다. 회사는 매일의 일상 인

작업을 처리 할 수 있는 자체 능력을 가지고 있지만, 필요할 때마다

자동으로 컴퓨 워를 추가 할당 할 수 있다.

다. 요구사항들과 제어:

다음은 이번 유즈 이스에 필요한 요구사항들과 계되는 제어권이

다.

라. 통합 패턴:

- 58 -

신뢰, 자산 리, 설정 리

마. 역할

보험청구 조정자, 보험 에이 트, 감사자

2. 클라우드 기반 개발과 테스

가. 고객 시나리오:

한 온라인 소매업자는 새로운 웹 2.0 론트(상품진열) 어 리 이션

의 개발이 필요하지만, 자사의 IT 직원과 기존의 자원들에 한 부담

은 원하지 않는다. 이 회사는 개발 도구와 소스 코드 장소가 호스

된 클라우드 기반의 개발 환경을 제공해주는 클라우드 제공자를 선택

한다. , 새로운 어 리 이션이 많은 다른 타입의 머신들 규모

워크로드와 상호작용 할 수 있도록 테스 환경을 제공해주는 다른

클라우드 제공자도 선택한다. 클라우드 기반의 개발과 테스트를 다루는 두 제공자를 선택한 것은

통합이 요하다는 것을 의미한다.

나. 고객의 문제 해결:

개발자 에서, 클라우드로 호스트된 개발 툴들을 사용하면 각각

의 개발자의 머신마다 툴들을 설치하고 설정하고 리할 필요가 없어

진다. 클라우드 제공자의 사이트에서 툴들이 일단 한번 설치되고 업데

이트되면, 모든 개발자들은 자동으로 같은 버 의 툴들을 사용할 수

있다. 큰 규모의 빌드는 클라우드 제공자 인 라의 확장성을 이용할 수

- 59 -

Requirement Controls개발자 툴들은 하나의 심지에서

설치되고 유지된다. • 자산 리

어 리 이션이나 데이터의 모든

흔 들은 가상 머신이 종료되면 모두 • 워크로드와 서비스 리

[표 1-8] 보안 시나리오 2 에 필요한 요구사항들

있기 때문에 제품 빌드를 훨씬 더 빠르게 할 수 있다. 한, 클라우드

기반의 빌드는 클라우드 기반 장소에서 최신 소스 코드를 검색, 추

출할 수 있다. 테스 에서, 회사가 통 인 인터페이스로부터 웹 2.0 인터페

이스로 바 어 감에 따른 서버의 추가 인 부담은 알 수 없다. 웹 2.0 인터페이스는 정 웹 페이지보다 서버와 훨씬 더 많은 상호작용을

한다. 그래서 클라우드 환경에서 새로운 어 리 이션을 테스트하면

테스 은 새로운 인터페이스의 향을 측정 할 수 있다. 클라우드 환경에서 새로운 어 리 이션에 한 스트 스 테스 은

더 쉽다. 만약 테스 이 1 마다 500개의 다른 머신으로 작업 요청

이 들어왔을 때, 그 어 리 이션이 어떻게 수행하는지를 알고 싶다

면, 클라우드는 500개의 가상 머신을 구동시키고 테스트할 수 있도록

한다. 서로 다른 VM 이미지를 사용하면, 많은 서로 다른 타입의 머신

들(운 체제, 버 , 로토콜 등)에서 어 리 이션을 테스트하기 편하

다. 그 테스 이 1,000개 머신이나 10,000개 머신으로 테스트하고자

할 때, 클라우드에서 그 게 하는 것은 경제 이지만, 자체 인 라를

구축한다는 것은 매우 비경제 이다.

다. 요구사항들과 제어:

다음은 이번 유즈 이스에 필요한 요구사항들과 이에 계되는 제

어권이다.

- 60 -

제거되어야 한다.

단일 사인-온은 개발과 클라우드

테스 모두에 용된다.

• 암호화

• 종 에 한 보안

• 식별자, 역할, 근 제어와

속성들

• 네트워크 보안

소스 코드와 테스트 계획에 한

근 제어

• 자산 리

• 식별자, 역할, 근 제어와

속성들

빌딩과 테스트는 가상 머신을

자동으로 시작하고 종료해야 한다. • 서비스 자동화

빌딩과 테스트는 가상 머신 사용과

성능에 한 통계를 보고해야 한다. • 이벤트 감사와 보고

라. 통합 패턴:

신뢰, 식별자 리, 근 리, 단일 사인-온, 감사 규정 수, 설정 리

마. 역할

개발자, 테스터, 리자, 감사자

3. 클라우드에서의 장공간

가. 고객 시나리오

한 융 투자 회사는 회사의 에이 트와 계열사에 해 새로운 투

자 상품을 출시한다. 많은 수의 비디오가 새로운 상품에 한 이익과

특징들을 회사의 에이 트와 계열사에게 설명하기 해 만들어졌다. 이 비디오들은 용량이 매우 크고 수요에 따라 즉시 공 되어야 하기

- 61 -

Requirement Controls특정 역할에게만 제한 으로 제공되는 • 식별자, 역할, 근 제어

[표 1-9] 보안 시나리오 3 에 필요한 요구사항들

때문에, 클라우드 환경에 장하게 되면 기업 인 라의 사용 요구를

일 수 있다. 그러나 이 비디오들에 한 근은 면 히 제어되어

야 한다. 경쟁상의 이유로, 오로지 인증을 걸친 회사의 에이 트만이

비디오를 볼 수 있어야 한다. 이와 더불어 더 큰 제약 조건으로 회사

는 제품 출시 까지 상품과 비디오에 한 기 을 유지해야 한다는

것이다. 이 회사의 결정은 안 하게 비디오를 호스 하고 스트리 할 수

있도록 퍼블릭 클라우드 스토리지 제공자를 사용하기로 하는 것이다. 그 클라우드 솔루션은 그 회사의 보안 정책을 용한 근 제어 메커

니즘으로 비디오들을 컨트롤해야 한다.

나. 고객의 문제 해결

퍼블릭 클라우드 스토리지 서비스를 사용하면 고객들은 그들 데이

터 센터의 물리 자원들의 증가 없이 원하는 만큼의 규모의 데이

터 일들과 역폭 요청을 리할 수 있다. 그러나 정부 규제와 기

(기업)의 요구사항은 보안이 필수 으로 요하다는 것을 의미한다. 규정 수를 보장 할 수 없는 퍼블릭 클라우드 스토리지 제공자는 그들

이 제공하는 퍼포먼스와 가격, 확장성에 계없이 고려 상이 될 수

없다.

다. 요구 사항과 제어권

다음은 이번 유즈 이스에 필요한 요구사항들과 이에 계되는 제

어권이다.

- 62 -

어 리 이션에 한 근

속성들

• 자산 리

• 네트워크 보안

• 정책들

클라우드에 장된 데이터는 안 해야

한다. • 암호화

• 데이터 / 스토리지 보안

클라우드에 장된 데이터는 그

회사의 방화벽 안으로 옮겨져야 한다.

• 암호화

• 데이터 / 스토리지 보안

• 종 에 한 보안

• 네트워크 보안

Security Control Computing Power in the Cloud

Cloud-based Development and

TestingStorage in the

CloudAsset

Management ✔ ✔ ✔Cryptography :

Key and ✔ ✔

[표 1-10] 보안 제어와 고객 시나리오

라. 통합 패턴

신뢰, 식별자 리, 근 리, 감사와 규정 수

마. 역할

비디오 로듀서, 회사 리인(에이 트), 회사 계열사, 감사자, 규제

기

4. 상호참조: 보안 제어와 고객 시나리오

다음 테이블은 보안 제어와 고객 시나리오 사이의 계를 요약한 것이

다.

- 63 -

Certificate Management

Data / Storage Security ✔Endpoint Security ✔ ✔

Event Auditing and Reporting ✔

Identity, Roles, Access Control and Attributes

✔ ✔ ✔

Network Security ✔ ✔

Policies ✔Service

Automation ✔

Workload and Service

Management ✔ ✔

Security Federation

PatternComputing Power

in the CloudCloud-based

Development and Testing

Storage in the Cloud

Trust ✔ ✔ ✔

[표 1-11] 보안 통합 패턴과 고객 시나리오

5. 상호참조: 보안 통합 패턴과 고객 시나리오

다음 테이블은 보안 통합 패턴과 고객 시나리오 사이의 계를 요약한

것이다.

- 64 -

Identity Management ✔ ✔

Access Management ✔ ✔ ✔

Single Sign-On ✔Audit and Compliance ✔ ✔

Configuration Management ✔ ✔

제 8 서비스 수 약서(SLAs)

클라우드 제공자와 소비자 사이의 계는 반드시 서비스 수 약서

(SLA)를 가지고 설명을 되어야 한다. 클라우드 소비자들은 클라우드 제

공자들이 그들의 인 라 서비스의 일부를 제공하기를 기 하기 때문에

이러한 서비스들을 정의하는 것과 어떻게 제공되고 어떻게 사용 되어

지는 것인가는 아주 요하다. SLA는 제공자에 한 소비자 신뢰의 기본이다. 하나의 잘 작성된 SLA는 제공자의 평 을 결정짓는다. 소비자와 제공자간에 계를 정의하는 문장에 더불어 SLA는 클라우드

서비스에 한 객 이고 측정 가능한 조건들을 정의하는 서비스 수

목표(SLOs)를 포함한다. 클라우드 소비자들은 그들의 사업 목표에 비추

어 클라우드 서비스 제공자를 선택하기 한 SLA와 SLO 항목들을 반드

시 평가해야 한다. 클라우드 서비스 소비자가 제공자 SLA의 모든 항목들을 완 한 이해

해야 한다는 것과, 소비자들이 어떤 약에 서명하기 에 그들의 기

- 65 -

에서 필요한 요구들을 고려하는 것은 매우 요하다.

1. 서비스 수 약(SLA)이란 무엇인가?

SLA는 클라우드 서비스 제공자와 클라우드 서비스 소비자 간의 상호

작용을 정의한다. SLA는 여러 가지를 내포하고 있다.o 제공자가 달하고자 하는 여러 서비스들의 집합

o 각 서비스의 완 하고 구체 인 정의

o 제공자와 소비자의 책임들

o 제공자가 약속된 로 서비스를 제공하고 있는지 여부를 결정하기

한 측정기 들의 집합

o 서비스를 모니터링 하기 한 감사 방법

o SLA 항목이 충족 되지 않았을 경우 제공자와 소비자에게 가능한

안들

o SLA가 시간이 지남에 따라 어떻게 변화하는지

시장에는 두 가지 타입의 SLA가 있다: 기존에 개발된 일반 인 약서

와 소비자의 구체 인 요구를 만족시키기 해 제공자와 소비자 간에 상

호 의를 거친 약서가 있다. 요한 데이터와 응용 로그램을 가진

어떤 소비자가 첫 번째 타입을 사용할 수 있을 것 같진 않다. 그러므로

SLA(그리고 일반 으로 클라우드)에 근하기 한 소비자의 첫 번째 단

계는 얼마나 그들의 데이터와 응용 로그램들이 요한지 결정하는 것이

다. 부분의 퍼블릭 클라우드 서비스들은 상이 불가능한 SLA를 제공한

다. 이러한 제공자들로 부터 요구사항이 만족되지 못한 소비자는 두 가

지 안을 가진다.o 다음 달 요 청구서에 한 부분은 신용으로 받는다. (이번 달 요

청구서는 완 히 지불한 후) 는

o 서비스 사용을 단한다. 매우 요한 애 리 이션이나 데이터의 경우에는 이러한 조항들이 있

- 66 -

는 SLA는 결코 수용될 수 없다. 반면에, 이러한 조항들을 가진 SLA는 상

호 약된 SLA 하에서 제공되는 클라우드 서비스 보다 매우 렴할 것

이다.

2. 서비스 수 목표 (Service Level Objectives)

SLO는 정확하고 측정 가능한 서비스 성격을 정의한다. 여기에 몇 가

지 SLO에 한 시가 있다.o 시스템은 10개 이상의 보류 요청을 가져서는 안 된다.o 처리량 요청은 3 이내이어야 한다.o 읽기 요청에 한 데이터 스트리 은 2 이내 시작되어야 한다.o 어도 5개의 VM 인스턴스들이 99.99999%의 가용성을 가져야 하

고, 제공자의 3개의 데이터 센터에서 각각 최소 1개 이상의 인스턴

스들이 이용 가능해야 한다. 당연히 서로 다른 서비스 수 목표들이 다양한 사용 이스들, 응용

로그램들 그리고 데이터 타입에 용될 것이다. SLO는 다양한 SLO의

상 인 요성을 나타내기 한 긴 성 등 을 한 포함 할 수 있다. 만약 클라우드 제공자가 응답시간과 가용성 SLO들을 둘 다 같이 만족시

키지 못 한다면 소비자는 응답시간보다 가용성이 더 요하다는 긴 성

등 을 사용할 수 있다. 다양한 역할들은 한 용되는 SLO에 향을 끼친다. 를 들어, 클

라우드 제공자에 의해 호스트 되고 최종 소비자가 근하며 클라우드 소

비자에 의해 작성된 한 응용 로그램을 고려 해보자. 만약 그 응용 로

그램과 그 응용 로그램의 데이터가 같은 클라우드 제공자에 의해 호스

트 되면, 그 응용 로그램은 제공자의 데이터 센터를 떠나지 않아도 그

데이터에 근할 수 있을 것이다. 클라우드 소비자는 그 응용 로그램이

자신의 데이터에 속할 때마다 매우 빠른 응답 시간을 기 할 것이다. 반면에 이 소비자는 최종 소비자가 웹을 통하여 이 응용 로그램에 속

할 때에는 상 으로 낮은 응답시간 기 치를 가질 것이다.

- 67 -

3. 서비스 수 리 (Service Level Management)

서비스의 성능을 측정하고 모니터링하지 않는다면 SLA 항목들이 충족

되고 있는지 아는 것은 불가능하다. 서비스 수 리는 어떻게 이런 성

능 정보가 취합되고 다루어지는지에 한 것이다. 서비스의 측정은 SLA의 서비스 수 목표들에 근거한다. 클라우드 제공자는 그들의 인 라에 한 결정을 하기 해 서비스 수

리를 사용한다. 를 들어, 제공자는 특정 서비스에 한 성능이

고객의 요구사항들을 간신히 만족시킨다는 것을 알 수도 있다. 이 제공

자는 물리 인 하드웨어를 더 추가하거나 역폭을 재할당 함으로써 그

러한 상황에 응할 수도 있다. 그러나 만약 한 소비자에게 더 많은 자

원들을 추가함으로써 다른 소비자의 SLA 항목을 만족시키는 것이 불

가능 해진다면, 제공자는 다른 고객의 희생을 통해 한 고객을 만족시키

기로 결정할 수도 있다. 서비스 수 리의 목표는 제공자들로 하여

사업 목 들과 기술 실에 근거하여 지 인 결정을 내리도록 도와주

는 것이다. 클라우드 소비자는 클라우드 서비스들을 어떻게 사용할지에 한 결정

을 내리기 해서 서비스 수 리를 사용한다. 를 들어서, 한 소비

자가 어느 특정 VM의 CPU 이용률이 90%이상인 것을 알았다. 이에 따라

이 소비자는 다른 VM을 시작시킬 수도 있다. 그러나 만약 소비자의

SLA에 처음 100개까지의 VM 이용 가격 보다 추가로 이용하는 VM에

한 가격이 더 높게 책정되어 있다면 이 소비자는 그 추가 가격을 지불하

면서 새로운 VM을 생성하는 결정을 하지 않을 수도 있다. 제공자와 마

찬가지로 서비스 수 리는 소비자가 어떻게 클라우드 서비스를 사용

할 것인지에 한 결정을 내리는데 도움을 다.

4. SLA에 한 고려사항들

- 68 -

소비자들이 SLA에 필요한 항목들이 무엇인지를 결정하는 데는 그들이

고려해야 할 몇 개의 요인들이 있다.

가. 사업 수 목표 (Business Level Objectives)

만약 기 이 사업 수 목표를 아직 정의하지 않았다면 SLA 항목들

에 한 검토는 무의미 하다. 소비자는 그 기 의 목 에 따라 제공자

들과 서비스들을 선택해야 한다. 만약 기 이 처음부터 왜 이 서비스

를 사용할 것인지에 해 정의를 하지 않았다면 정확하게 무슨 서비

스를 사용할 것이라고 정의하는 것은 가치가 없다. 클라우드 컴퓨 에서 볼 때 가장 어려운 문제는 기술 인 이

슈라기보다는 기 자체의 정치 인 이해 문제이다. 한 기 에서 모든

부서들이 목표들에 동의하게 만들다 보면 어떤 그룹은 산 삭감을

받아들이고, 다른 어떤 그룹은 그들의 인 라에 한 통제권을 잃어버

릴 수도 있고, 그 이외 어려운 결정들이 따를 수도 있다. 이러한

어려움들에도 불구하고, 기 은 사업 수 목표가 정의되기 이 에는

클라우드 컴퓨 ( 는 다른 어떤 기술)을 최 한 활용할 수 없다. 소비

자들은 그들이 어떻게 클라우드 컴퓨 을 사용할 것인지 결정하기

에 그들이 왜 클라우드 컴퓨 을 사용하는지를 반드시 알아야 한다.

나. 제공자와 소비자의 책임들

비록 일반 으로 SLA는 제공자의 책임들의 책임을 정의하는 것이라

고 생각하지만, 소비자의 책임들에 한 부분 한 명확해야 한다. 소

비자의 책임들에는, 시스템 사용량 제한에 한 책임, 장할 수 있는

데이터 타입에 한 제한, 는 제공자 시스템에 사용된 모든 소 트

웨어의 유효한 라이선스에 한 책임 등이 포함 될 수 있다. 제공자와

소비자 간의 책임 균형은 서비스 형태에 따라 다양하다. 를 들면, 클라우드 제공자는 SaaS(Software as a Service)에 한 부분의 책임

- 69 -

들을 가진다. 반면에 라이선스 있는 소 트웨어를 포함하고 민감한

데이터를 가진 VM의 경우에는 더 많은 책임들이 그것을 리하고 빌

드하는 소비자에게 있다.

다. 비즈니스 연속성과 재해 복구

많은 소비자들은 비즈니스 연속성 때문에 클라우드 컴퓨 을 사용

한다. 몇몇의 소비자들은 백업을 해서 여러 클라우드 시스템에 소

한 데이터의 사본을 장한다. 다른 소비자들은 회사 자체 내부 데이

터 센터들이 부하들을 처리할 수 없을 때 클라우드버스

(Cloudbursting)을 이용한다. 클라우드 컴퓨 은 자체 시스템이 다운되

었을 때 기 운 을 유지시키기 해서는 정 인 큰 가치를 감는

다. 그러나 만약 클라우드 제공자 자신이 한 연속성과 재해 복구

차들을 가지고 있지 않다면 그러한 문제들은 아무 소용이 없다. 소

비자들은 그들의 클라우드 제공자들이 재난 발생 시 한 보호책을

가졌다는 것을 확인해야 한다.

라. 시스템 복

많은 클라우드 제공자들은 거 한 여분( 복)의 시스템들을 통해서

그들의 서비스를 제공하고 있다. 그러한 시스템들은 하드 드라이 들

는 네트워크 연결들 는 서버들의 오류가 일어날 경우에 비해

설계되어서 소비자들이 어떠한 사용 단도 경험하지 않도록 하고 있

다. 연속 으로 사용 가능해야 하는 응용 로그램과 데이터를 옮기는

소비자들은 그들의 제공자의 시스템 복과 여분을 고려해야 한다.

마. 유지 리

제공자들은 그들의 인 라를 그들 자신이 유지( 리)함으로써 소비

- 70 -

자들을 시스템 유지 리에 한 문제로부터 해방시켰다. 그러나 소비

자들은 그들의 제공자들이 어떻게 는 언제 유지 리 업무들을 할

것인지에 한 이해를 하고 있어야 한다. 그들의 서비스들은 그러한

시간 동안 이용할 수 없는 것인지? 그들의 서비스들이 이용 가능은 하

겠지만 훨씬 더 낮은 성능을 가질 것인지? 이 유지 리가 소비자의 응

용 로그램에 향을 미칠 가능성이 있다면 업데이트된 서비스를

상으로 소비자들은 그들의 응용 로그램들을 테스트할 기회를 가질

수 있는지? 유지 리는 소 트웨어뿐 만 아니라 하드웨어 등 모든 유

형의 클라우드 서비스에 향을 미칠 수 있다는 을 유념해야 한다.

바. 데이터의 치

많은 타입의 데이터에 한 물리 인 치는 제한되어 있다. 를

들어서, 많은 나라들에서는 그들 국가의 시민들에 한 개인 정보를

국경 밖의 어떤 시스템에도 장하는 것을 지하고 있다. 만약 클라

우드 제공자가 소비자의 데이터를 특정 치에만 장되도록 보장할

수 없다면 소비자는 제공자의 서비스들을 사용할 수 없다. 만약 클라

우드 서비스 제공자가 데이터 치 규정을 용할 것을 약속한다면, 소비자는 반드시 제공자가 그러한 규정을 잘 따르고 있는지 제공자에

한 감사를 시행할 수 있어야 한다.

사. 데이터 압수

사법 당국이 호스 업체의 자산을 압류한 몇 가지 잘 알려진 가

있어왔다. 비록 법 집행 기 은 특정 소비자와 연 된 데이터와 응용

로그램들을 표 으로 하겠지만 다 소유(multi-tenant)라는 클라우드

컴퓨 의 속성상 다른 소비자에게도 향을 미칠 수 있다. 비록 SLA가 커버 할 수 있는 것이 한계가 있을 지라도, 소비자들은 제공자들에

게 용된 법 조항들을 고려해야 한다. 소비자들은 그들의 데이터와

- 71 -

응용 로그램들을 백업하기 해서 서드 티(제3자)를 이용하는 것을

한 고려해야 한다.

아. 제공자의 불이행

어떤 클라우드 제공자라도 사업을 거나 는 다른 사업자에게 인

수될 수 있는 잠재 가능성을 가진다. 소비자들은 제공자들의 재정

인 건 성을 고려해야 하고 만약 제공자가 문을 닫을 것을 비해서

연속성을 가지게 하는 계획들을 만들어야 한다. 게다가 만약 소비자의

사용료 계정이 연체되거나 분쟁의 소지를 가지고 있다면 소비자의 데

이터와 응용 로그램의 근에 한 제공자들의 정책들을 명확하게

알고 있어야 한다.

자. 할권

소비자들은 그들이 고려한 모든 클라우드 제공자들에게 용될 법

조항들을 이해해야 한다. 를 들어서, 클라우드 제공자는 클라우드

제공자의 서비스들을 사용하는 모든 데이터 는 응용 로그램들을

모니터할 수 있는 권리를 보유한 국가에 근거지를 둘 수도 있다. 소비

자의 데이터와 응용 로그램들의 특성을 감안할 때, 이러한 은 받아

들일 수 없을지도 모른다.

차. 클라우드 개인과 재 매업자

만약 클라우드 제공자가 실제로 다른 클라우드 제공자의 재 매

업자 는 개인이라면, SLA 조항들은 개인 는 재 매업자 는

제공자의 시설들에 문제가 발생할 경우를 고려하여 책임과 의무에

한 사항들을 명확히 하여야 한다.

- 72 -

5. SLA 요구사항

가. 보안

일반 인 요구사항으로서의 보안은 본 문서의 6 과 7 에 자세하

게 논의 되었다. SLA의 보안 련 사항들은 6 의 보안 제어와 통합

패턴을 고려하여 작성되어야 한다. 클라우드 소비자는 그들의 보안 요

구사항과 어떤 제어와 통합 패턴이 그러한 요구조건을 만족시키기

해 필수인지 반드시 이해해야 한다. 한 클라우드 제공자들은 한

제어와 통합 패턴들을 가능하게 하기 해서 소비자들에게 뭐를 제공

해야 하는지를 이해하여야 한다.

나. 데이터 암호화

만약 소비자가 클라우드 안에 단히 요한 데이터를 장하고 있

다면, 데이터가 이동하거나 장되어 있는 동안 암호화시키는 것은

요하다. 암호화 알고리즘과 근 제어 정책에 한 세부사항들은 SLA에서 구체화 되어야 한다.

다. 개인정보보호

기본 인 개인정보보호 문제는 데이터 암호화, 유지, 삭제와 같은

요구사항들로 언 되었다. 추가로, SLA는 다 소유자 환경에서 클라

우드 제공자가 어떻게 데이터들과 응용 로그램들을 분리시킬 수 있

는지 명확히 해야 한다.

라. 데이터 유지와 삭제

많은 기 들은 데이터를 일정 기간 동안 보 해야 한다는 법 인

- 73 -

요구사항들을 가진다. 어떤 기 들은 한 일정 기간 후에는 데이터의

삭제를 필요로 한다. 클라우드 제공자들은 그들이 이러한 정책들에 부

합하는지를 증명할 수 있어야 한다.

마. 하드웨어 삭제 괴

데이터 유출의 공통 인 원인은 하드웨어의 부 한 폐기이다. 만

약 클라우드 제공자의 하드 드라이버가 오류가 났다면, 그 디스크의

래터들은 드라이 가 폐기되거나 재활용되기 에 반드시 제로 상

태가 되어야 한다. 이와 유사하게, 많은 클라우드 제공자들은 소비자

가 VM의 원을 끄면 메모리 공간을 제로의 상태로 만들어 주는 추

가 보호 기능을 제공한다.

바. 규정 수

많은 유형의 데이터와 응용 로그램들은 규정들의 향을 받는다. 그러한 규정들 몇몇은 법 조항들(미국의 의료 기록에 한 HIPAA)이고, 반면에 다른 것들은 산업 련(신용카드들을 받는 소매업자에

한 PCI DSS)된 것이 있다. 만약 규정들이 반드시 시행되어야 한다

면, 클라우드 제공자들은 그들이 규정을 수하고 있는지 증명할 수

있어야 한다.

사. 투명성

몇몇 클라우드 제공자들의 SLA에는, 제공자들이 SLA의 항목들에 맞

게 시행하지 못한 경우 이를 소비자들이 증명해야 할 부담을 겪는다. 한 제공자의 서비스가 몇 시간 동안 다운될 수도 있지만, 이를 증명하

지 못하는 소비자는 어떤 종류의 보상도 받을 자격이 없다. 요한 데이터와 응용 로그램에 해서 제공자들은 SLA 항목에 배

- 74 -

되었을 경우 소비자들에게 능동 으로 통지해야 한다. 이것은 보안사

고 뿐만이 아니라 서비스 단과 성능문제와 같은 인 라 인 문제도

포함한다.

아. 인증

특정 유형의 데이터와 응용 로그램들에 용되는 많이 다양한 인

증들이 있다. 를 들면, 소비자는 그들의 클라우드 제공자는 ISO 27001 인증을 받아야 한다는 요구사항을 가질 수도 있다. 제공자는 그

들의 인증을 증명하고 그것을 최신 상태로 유지 하려는 책임을 가져

야 한다.

자. 핵심 성과 지표에 한 문 용어

가동시간(uptime)이란 용어는 다양한 방법으로 정의 될 수 있다. 종

종 이 정의는 제공자의 구조와 련이 있다. 만약 제공자가 여섯 륙

에 데이터 센터를 가지고 있다면 가동시간이란 어느 특정 한 데이터

센터에 용되나? 아니면 모든 데이터 센터에 용되는 것인가? 만약

오직 이용 가능한 데이터 센터가 다른 륙에 있다면 가동시간은 별

의미가 옶고 수용될 수 없을 것이다. 설상가상으로 다른 클라우드 제

공자들은 그들만의 구조에 특화된 정의를 사용할 것이다. 이러한 은

클라우드 서비스들을 비교하는 것을 어렵게 한다. 다양한 핵심 성능 지표들에 한 일련의 산업 용어 정의는 특히

SLA를 비교하기 쉽게 한다.

차. 모니터링

만약 SLA 항목들을 만족시키는데 실패한 경우 재정 이거나 법률

인 문제들이 발생한다면, 가 제공자( 는 소비자가 책임을 같이 져

- 75 -

야 하는지)의 성능을 감시해야 하는가라는 질문이 요해진다. 제공자

들은 가능한 한 폭넓은 용어와 조항으로 가동시간을 정의하려 할 것

이고, 반면에 소비자들은 발생한 모든 시스템 문제를 가지고 제공자를

비난하려고 할 것이다. 이 문제에 한 가장 최선의 해결책은 제공자

의 성능을 모니터 하는 립 인 서드- 티(third-party) 기 이다. 이게 하면 제공자가 단독 재량으로 장애를 보고 하거나 는 소비자

가 발생된 장애를 증명하는 책임을 가질 때 발생할 수 있는 서로 간

의 이해 계 문제를 해결할 수 있다.

카. 감사 능력

많은 소비자 요구 사항들은 법 규제 는 업계 표 들의 수를

포함한다. 소비자는 발생하는 모든 반들에 해서 책임져야 하기 때

문에 소비자에 의한 제공자의 시스템들과 차들에 한 감사는 필수

으로 가능해야 한다. SLA는 어떻게 그리고 언제 그러한 감사를 실

시할지를 명확하게 해주어야 한다. 감사는 불편하고 비싸기 때문에 제

공자들은 부분 제한을 두거나 비용을 청구하려고 할 것이다.

타. 측정항목

사실에 한 감사이고 발생한 것에 한 모니터링이기 때문에 모니

터링과 감사는 실재하는 어떤 것을 요구한다. SLA의 측정항목은 객

으로 모호하지 않고 분명하게 정의 되어야 한다. 클라우드 소비자들

은 그들의 응용 로그램과 데이터의 특성에 따라 끝없이 다양한 측정

(항목)을 가질 것이다. 비록 모든 측정항목의 나열은 불가능할 지라도

가장 공통 인 것들은:o 투처리량(Throughput) – 얼마나 빠르게 서비스가 반응하는지

o 신뢰성(Reliability) – 얼마나 자주 서비스가 사용가능한지

o 부하 조 (Load balancing) – 언제 탄력성이 시작할지 ( 를 들어,

- 76 -

새로운 VM의 부 는 소멸)o 내구성(Durability) – 데이터가 손실될 수 있는 가능성

o 탄력성(Elasticity) – 한계가 명확한 내에서 주어진 자원의 확장성

( 를 들어, 최 장 공간 는 역폭)o 선형성(Linearity) – 부하의 증가에 따른 시스템의 성능

o 민첩성(Agility) – 소비자 자원 부하의 증감에 따라 얼마나 빠르게

제공자가 응하는지

o 자동화(Automation) – 사람의 개입 없이 처리되는 제공자에 한

요청의 비율

o 고객 서비스 응답 시간(Customer service response times) – 얼마

나 빠르게 제공자가 서비스 요청에 반응하는지. 이것은 클라우드의

셀 서비스와 온디멘드 측면에서 뭔가가 잘못되었을 때 요구되는

사람의 개입을 의미함.

. 컴퓨터로 읽을 수 있는 SLAs

컴퓨터로 인식할 수 있는 SLA는 동 으로 클라우드 제공자를 선택

할 수 있는 자동화된 클라우드 로커를 가능하게 한다. 클라우드 컴

퓨 의 기본 특징 에 하나는 온디멘드 셀 서비스이다; 자동화된 클

라우드 로커는 사용자 요청에 따라 클라우드 제공자를 선택함으로

써 이러한 특징을 확장 할 수도 있다. 이 로커는 소비자에 의해 정

의된 비즈니스 기 에 근거하여 클라우드 제공자를 선택 할 수도 있

다. 를 들어, 소비자의 정책은 개인이 일부 업무에 해서 가장

렴한 제공자를 사용해야 한다고 하는 반면 다른 업무에 해서는

가장 보안이 강한 제공자를 사용하도록 할 수 있다. 비록 이러한 요구

사항에 한 마켓의 수요가 개되기 까지는 일정 시간이 필요할 것

이나 SLA 표 화를 한 작업은 이 을 염두에 두어야 한다.

하. 인간의 상호작용

- 77 -

비록 사용자 주문형 셀 서비스는 클라우드 컴퓨 의 가장 기본

인 특징 에 하나이나 오직 인간의 상호 작용으로만 해결될 수 있는

문제들이 항상 있을 것이라는 사실은 계속 존재한다. 이러한 상황들은

거의 발생하지 말아야 하지만 많은 SLA들은 제공자의 지원 요청들에

한 응 보장을 포함 할 것이다. 일반 인 보증들은 소비자들이 얼

마나 많은 요청이 할 수 있으며, 그들의 비용, 그리고 얼마나 빨리 제

공자가 응답할 것이란 부분이다.

6. 신뢰성에 한 언

신뢰성에 해 논의에서 일반 인 측정은 제공자가 제공하는 숫자

“9”들의 개수만큼 이루어지고 있다. 를 들어, 5개 9의 신뢰성은 서

비스가 이용 가능한 시간이 99.99999% 하다는 것을 의미하고, 이것은 모

든 시스템에서 매 12달 5분 동안 장애가 있다는 것으로 해석이 된다. 이러한 측정의 한 가지 문제는 무엇이 장애인지 명확한 정의 없다면 이

러한 측정은 빠르게 의미가 없어진다는 것이다. (특히 클라우드 제공자

가 사고에 동작정지를 포함시키면 더 의미가 없어진다.) 9들의 모호한 특징을 뛰어넘어서, 많은 클라우드 서비스 제공들이 다

른 클라우드 서비스 제공들의 에 구축된다는 은 요하게 고려되어

야 한다. 여러 인 라들을 조합하는 능력은 매우 큰 유연성과 워를 제

공하지만, 각각의 추가 인 제공자들은 시스템의 신뢰성을 다소 떨어지

게 만든다. 만약 한 클라우드 제공자가 두 번째 클라우드 제공자의 스토

리지 서비스와 세 번째 클라우드 제공자의 데이터베이스 서비스를 기반

으로 서비스를 제공하고, 그리고 이러한 제공자들이 모두 숫자 9가 5개

되는 신뢰성을 제공한다면, 체 시스템의 신뢰성은 숫자 9가 5개인 경

우보다 떨어진다. 이 서비스는 첫 번째 클라우드 제공자의 시스템이 다

운이 될 때 사용이 불가능하고 역시 두 번째나 세 번째 제공자의 시스템

에 문제가 생겼을 때 마찬가지로 사용이 불가능하다. 더 많은 클라우드

- 78 -

Requirement Platform as a Service

Infrastructureas a Service

Software as a Service

Data Encryption ✔ ✔ 　

Privacy ✔ ✔ 　Data RetentionAnd Deletion 　 ✔ ✔

Hardware Erasure and Destruction 　 ✔ ✔

[표 1-12] SLA 요구사항들과 클라우드 제공 모델

제공자가 련될수록 시스템 장애시간은 더욱 늘어날 것이다. 마지막으로, 클라우드 제공자의 숫자가 늘어날수록 외부요인의 수는

한 늘어난다. 만약 VM과 클라우드 데이터베이스가 같은 데이터 센터

에 있다면 VM과 데이터베이스 사이에 통신은 네트워크 속을 필요로

하지 않는다. 반면에, 클라우드 데이터베이스가 다른 제공자에 의해

공 된다면, VM 사이에 이용 가능한 역폭과 데이터베이스는 반 인

시스템의 신뢰성과 성능에 향을 미친다. 두 클라우드 제공자들과 모두

건강하게 작동할 수도 있지만, 만약 그들 사이의 네트워크 연결이 실패

한다면 모든 시스템이 다운 될 것이다. 요약하면, 클라우드 서비스의 신뢰성을 평가할 필요가 있는 모든 소비

자는 직 이든 간 이든, 서비스를 제공하는 클라우드 제공자에

해서 되도록 많이 알아야만 한다.

7. 상호 참조: SLA 요구사항들과 클라우드 제공 모델(Cross-reference: SLA Requirements and Cloud Delivery Models)

다음 표는 여기에 나열된 SLA 요구사항과 함께 제 2 에서 나온 세 가

지의 NIST 제공 모델들의 상호 참조 모델의 상호 참조이다.

- 79 -

RegulatoryCompliance ✔ ✔ ✔

Transparency ✔ ✔ ✔

Certification ✔ ✔ ✔Terminology forKeyPerformance

Indicators　 ✔ ✔

Metrics ✔ ✔ ✔

Auditability ✔ ✔ ✔

Monitoring ✔ ✔ ✔Machine-Readable

SLAs 　 ✔ 　

Requirement

End User to

Cloud

Enterprise to Cloud to End User

Enterprise to Cloud

Enterprise to Cloud

to Enterpr

ise

private

Cloud

Changing

Cloud Vendor

s

Hybrid

Cloud

Data Encryption 　 ✔ 　 　 　 　

Privacy ✔ ✔ ✔ ✔ ✔ ✔ ✔Data 　 　 ✔ ✔ 　 　 ✔

[표 1-13] SLA 요구사항들과 유즈 이스 시나리오

8. 상호참조: SLA 요구사항들과 유즈 이스 시나리오(Cross-reference: SLA Requirements and Use Case Scenarios)

- 80 -

RetentionandDeletionHardware

Erasure and Destruction

　 　 ✔ ✔ 　 　 ✔

RegulatoryCompliance ✔ ✔ ✔ ✔ ✔ ✔ ✔Transparenc

y ✔ ✔ ✔ ✔ ✔ ✔ ✔Certification ✔ ✔ ✔ ✔ ✔ 　 ✔Terminology

forKeyPerforma

nceIndicators

　 　 ✔ ✔ ✔ ✔ ✔

Metrics ✔ ✔ ✔ ✔ ✔ ✔ ✔

Auditability ✔ 　 　 　 　 　 　Monitoring ✔ ✔ ✔ ✔ ✔ 　 ✔

Machine-Readable SLAs 　 　 　 ✔ 　 　 　

최선으로 SLA는 클라우드 소비자와 제공자 양쪽 모두의 이해 계들을

보호한다. 주어진 SLA가 모든 소비자들의 요구들을 충족시키지 못하는

것과 같이 모든 요구사항은 모든 고객 시나리오들에 용되지는 않는다. 다음 표는 여기서 열거된 SLA 요구사항들이 제 3 에서의 7가지 유즈

이스와 상호 참조 한 것이다.

제 9 결론

클라우드 컴퓨 은 가상화, SOA, 그리고 Web 2.0을 포함하는 산업계

- 81 -

의 많은 트랜드를 구축하고 보완한다. 따라서 본 문서에서 언 된 많은

요구사항들에 한 표 은 이미 존재한다. 계속 진행되어 가면서, 고객

의 요구를 만족시키는 존하는 표 을 명시하고, 진행 인 표 화 작

업을 통합하며, 존하는 표 으로 만족이 안 되는 갭을 찾아내기 하

여 함께 일해야 할 것이다. 여기서 설명된 유즈 이스들은 소비자를 해서 아래의 일반 인 요구

사항들을 도출하 다.o 공통 인 VM 포맷, 데이터 포맷 그리고 APIs: 어느 한 클라우드 제공

자를 해 만들어진 가상머신, 데이터, 그리고 응용 로그램은 다른

클라우드 제공자에서도 변경 없이 작동되어야 한다.o 클라우드 리: 클라우드 컴퓨 은 다음 서비스들이 없이는 실 이 불

가능하다. 서비스 리, 통제, 미터링, 모니터링, 통합된 식별자, SLAs, 벤치마크, 데이터와 응용 로그램 통합, 배치(deployment), 그

리고 생명주기 리. 이러한 요구사항들은 3 에 정의되어 있다.o 보안: 비록 보안에 한 요구사항은 응용 로그램과 데이터 유형에 따

라 다르지만 보안은 클라우드 컴퓨 에서 필수 이다.o 치인지: 클라우드 인 라스트럭처를 구성하는 물리 인 머신의 치

를 악하는 것은 많은 정부 규정을 해 필수 인 요구사항이다.o 소비자들은 여기에 나열된 모든 유즈 이스들을 벤더에 종속이 될 수

있는 패쇄 이고 사 인 솔루션에 의존하지 않고도 구 가능해야 한

다.여기서 설명된 개발자 요구사항들은 크게 두 유형으로 분류할 수 있다.o 서비스들을 한 APIs: 데이터베이스, 메시징 ( 과 발표-구독

모두), 컴퓨 워와 장기기 등의 모든 API 요구사항들은 모두 직

으로 클라우드 서비스와 연 된다.o APIs 지원: 캐슁, 로깅, 식별자 리, 서비스 발견, 세션 리, 그리고

SLA 등의 API 요구사항들은 클라우드 서비스를 효율 으로 사용하기

해서는 필수 인 것들이다. 개발자들은 여기에 나열된 모든 유즈 이스들을 벤더에 종속이 될 수

- 82 -

있는 패쇄 이고 사 인 솔루션에 의존하지 않고도 구 가능해야 한다. 그들의 데이터와 응용 로그램을 클라우드로 이동하려는 소비자들에게

보안은 끊임없이 가장 많은 우려를 발생시킨다. 클라우드 컴퓨 은 일반

인 IT 보안에서 이미 발생하지 않은 어떤 새로운 보안 이슈를 추가로

만들지는 않는다. 클라우드로 이동할 때의 우려는 이제 보안 정책을 구

하고 용하는데 제 3자가 개입된다는 것이다. 이런 통제의 상실은 클

라우드 제공자의 투명성에 한 필요성을 강조한다. 여기서의 보안에

한 논의는 보안 제어, 통합 패턴, 그리고 표 과 같이 클라우드 제공자

가 제공해야 하는 것들을 포함한다. 기 들이 클라우드 서비스를 사용해감에 따라 소비자와 제공자 모두의

책임은 서비스 수 약(SLA)에 명확하게 명시되어야 한다. SLA는 소비

자가 어떻게 서비스들을 사용할 것이고, 제공자는 그 서비스들을 어떻게

제공할 것이란 부분에 해 정의한다. 어떠한 계약에 서명을 하기 에, 클라우드 서비스의 소비자가 제공자의 SLA 조항들을 충분히 이해하고

그들 소비자 기 의 필요성들을 고려한다는 것은 매우 하다. 클라우드 컴퓨 의 모든 측면에서, 존하는 기존의 표 이 요구사항

들을 만족시킨다면 그 기존의 표 들이 일 성 있게 개발되고 용되도

록 노력하여야 한다. 기존의 표 들이 요구사항들을 만족시키지 못하는

경우에는 만족되는 표 들을 정의하고 개발하여야 한다. 본 문서는 진실

된 개방형 클라우드 컴퓨 환경을 구축하기 한 참조로서의 의미를 갖

는다.

- 83 -

제 2 장 시범사업 련 정책방향

제 1 혼합 실 기반 가상교육 캠퍼스 커뮤니티

1. 개요

가. 정의

“언제 어디서나 인터넷이 연결 가능한 곳에서 IT 인 라의 제약 없

이 혼합 실에 기반한 캠퍼스와 같은 실제 세계를 보고 학습 내용과

련된 부가 인 정보를 가상객체로 제시함으로써 학습자에게 실제

공간과 목된 가상의 체험학습 경험을 제공하고 실제감과 몰입감을

진하여 학습 효과를 향상시키는 교육 환경 시스템”o 방향으로 의사 달이 가능하도록 설계되어 온라인 IT인 라

를 통해 기존의 단순하고 일방향 인 교육 콘텐츠에서 벗어나 새로

운 기술에 기반한 고품질의 양방향 콘텐츠를 제공

o 가상 데스크탑 기술을 통해 사용자의 데스크탑 환경을 서버의 가상

컴퓨터에 두고 연결 가능한 여러 디바이스(스마트폰, 노트북, PC)를

통해 융합된 클라우드 컴퓨 환경을 제공하는 서비스

- 가상 데스크탑 : 하나의 컴퓨터를 여러 로 나 어 효율 으로

사용하는 기술

o 학습자에게 실재감과 몰입감을 진하고 사용자의 직 인 조작

활동을 통해 양방향 상호 작용을 극 화 할 수 있는 혼합 실

(mixed reality)

나. 필요성

- 84 -

(1) 새로운 고품질의 융합된 교육 환경 요구

o 속한 정보통신 기술의 발달로 인하여 클라우드 컴퓨 , 네크워크

인 라, 3D기술, 가상화 기술 같은 미래 콘텐츠 기술을 용한 새로

운 디지털 환경을 통하여 일방향의 교육 환경에서 벗어나 새로운

고품질의 교육 환경이 요구됨

(2) 요청 기반 셀 서비스 요구

o 클라우드 컴퓨 으로의 IT 트 드가 움직임에 따라 공공기 기

업 그리고 개인 맞춤형 컴퓨 에 한 수요가 발생

o 개인의 체험 심의 학습 경험과 지식을 스스로 구성하고 자발 인

환경을 만들어 나가는 새로운 학습 환경과 방법이 필요함

(3) 유비쿼터스 네트워크 속 요구

o 클라우드 제공자의 역량을 교육 받는 사용자의 성능과 상 없이 표

차에 의해 근이 가능하고 네트워크상에서 이용 가능함

o 특정 교육장소, 강사 확보 등 리 부담이 감소

o 디지털 콘텐츠를 교육과 지식 심으로 다변화 시키는데 견인차 역

할이 가능

(4) 빠른 탄성 요구

o 3D 상 인식의 안정성과 실시간성의 문제로 인한 과부하로 필요에

따라 원활한 컴퓨 자원의 양을 증가 는 감소시킬 수 있는 능력

이 요구됨.

(5) 측정된 서비스 요구

- 85 -

o 교육 서비스 사용자를 모니터 하고 리 할 수 있는 객 인 측정

이 필요함

o 개인별 교육 경력을 측정하여 DB로 활용함으로써 맞춤형 교육 리

가능

(6) 다 소유 모델 요구

o 교육 서비스의 특성상 소비자의 많은 요청을 감당 할 수 있는 시스

템이 필요하며 혼합 실에서의 여러 가상 자원들을 요청에 따라

할당되고 재 할당할 수 있어야 함

(7) 미래 교육 경쟁력 확보 시

o 디지털 세 에 맞는 미래 교육환경 구축을 한 연구는 미국, 싱가

포르, 랑스 등 선진 각국에서 오래 부터 연구되어 왔음

2. 국내외 황 문제

가. 해외 산업 황

(1) 시장규모

o "05년부터 ‘10년 까지 연평균 23.1%의 성장률을 기록하며, ‘10년에

538억 달러 수 에 이를 망

o 동남 아시아 국가 국 등 이러닝이 본격 도입되는 아태권과 유

럽은 20%를 상회하는 격한 성장세가 상

- 86 -

권역 2008 2009 2010 2011 2012 2013 평균 성장률

(‘08~13)세계 35,990 42,650 50,363 59,438 69,366 79,360 17.1%

미주권 25,808 30,103 34,999 39,709 45,857 50,112 14.2%유럽권 5,895 7,360 9,120 11,792 13,958 17,376 24.1%일본 1,960 2,301 2,679 3,088 3,305 3,866 14.6%

국 698 811 983 1,945 2,756 3,750 40.0%아태권 1,628 2,075 2,582 2,904 3,490 4,257 21.2%

[표 2-1] 세계 이러닝 시장 규모

(단 :백만달러)참조 : GA 2008 : ALIC, 2008 : Ireserach, 2008 : Ambient insight 2008

(2) 산업동향

o 싱가포르는 IT 인 라를 기반으로 교육환경의 신을 추구하는 MP I, II ,III for education 로젝트를 단계 으로 추진 이며

eduPAD라는 교육 용 단말을 개발 보 하여 새로운 교육의 신

을 보여

o 국의 미래교실 로젝트는 미래 교실 구축을 한 로젝트를 실

행 이며 모바일 디바이스를 이용한 혼합 실 기술, 효과 인 학습

을 한 콘텐츠 제작 기술, 콘텐츠 리 기술 등 련 기술 개발

로젝트 진행

o 유럽 연합은 청소년들의 평생교육목표 측면에서 스포츠, 음악, 언어, 직업 기술 개발을 한 콘텐츠가 포함된 m-Learning Project 진행

(3) 기술 동향

o 뉴질랜드의 HIT Lab과 미국 워싱턴 HIT Lab- 실 상을 입력 받아 기하학 마커를 인식하고 마커와 련된 가

상 콘텐츠를 표 하는 혼합 실 콘텐츠 표 기술인 AR Toolkit

- 87 -

연도 시장규모 년 비 증가액 년 비 증가율

2007 1,727,057 109,230 6.8 %2008 1,870,475 143,418 9.3 %2009 2,091,033 220,558 11.8 %

[표 2-2] 2009년 국내 이러닝 수요시장 규모

을 개발

o 싱가포르 난양기술 학의 혼합 실 Labo 독자 마커 인식 방법을 개발 3D magic story cube, 교토가든, 3D

매직랜드 등 AR 기술을 용한 동화책 에듀테인먼트용 콘텐츠

개발

나. 국내 산업 황 문제

(1) 시장규모

o 국내 이러닝 수요 시장 규모는 ‘09년 총 2조 910억 원 규모이며, 08’년 1조 8704억원 비 11.8% 증가

o 2005년 실태 조사가 시작된 이후 꾸 한 성장을 기록하고 있어 성

장 산업의 핵심 인 면모를 보이고 있음

(단 : 백만원)참조 : 2009년 이러닝 산업실태조사, 지식경제부

(2) 산업 동향

IT 기반 교육 산업이 이러닝을 심으로 지속 으로 성장하고 있는

가운데 이러닝은 교육 패러다임의 변화에 따라 u- 러닝으로 진화

o 정보통신산업진흥원과 한국정보통신기술 회는 국내 이러닝 품질경

쟁력 강화를 해서 이러닝 품질인증사업 공동 수행을 한 업무

- 88 -

정 체결

o 정보통신산업진흥원은 아랍에미리트 고등교육과학부가 주 하는

GETEX(Gulf Education & Training Exhibition) Dubai 2010에 한

국이러닝산업 회와 함께 국내 업체 7개사의 제품 홍보를 한 한

국스마트러닝 을 설치하여 한국 최첨단 IT 교실 구 과 스마트 기

기를 이용한 다양한 교육방법 제시하고 시 제품간 연계를 통한

효과 인 마 과 해외 진출 지원 연계를 지원

o 서울시는 첨단 IT를 통해 소득 청소년의 교육을 온라인을 활용하

여 효과 인 학습 지원과 IT 창의력 함양 교실 운 을 통해 창의성

과 사회성을 갖춘 미래 인재를 육성하기 한 목표로 u-러닝 서비

스 ‘쌤’을 실시

o SK 로드밴드는 강남구청과 U-러닝 존 구축에 한 제휴를 맺고

평생 교육 콘텐츠를 무료로 이용할 수 있도록 모바일 교육 행정

서비스를 제공

o SK텔 콤은 메가스터디와 함께 인터넷 사이트와 스마트폰간 연동이

되며 강좌검색, 학력평가 채 서비스, 웹과 스마트폰간의 인터넷

강의 상호 이어보기등 ‘스마트인강 메가스터디 서비스’라는 교육 서

비스를 제공

o 포씨소 트는 세계최 로 안드로이드 기반의 통합모바일 학습 리

시스템(LMS)를 통해 미국 고 상 온라인 교육의 강자인

Edutone사의 심 표명과 함께, 구 본사에 공동으로 소개 할 것

을 제안받음

(3) 기술 동향

o 재 국내에서는 IT 융합 기술을 활용한 새로운 이러닝 서비스 시

장을 선 하기 한 다양한 기술 개발이 진행 임

o 고도화된 IT 기술 인 라를 바탕으로 세계를 선도할 수 있는 첨

단 u-러닝 기술의 개발 필요

- 89 -

- U-디바이스를 활용한 끊김 없는(Seamless) 이러닝 기술

- 유아용 교육 안으로 로 이러닝 활용 기술

- 3D, 증강 실을 활용한 K12 산업 장 e-Training 시스템

- 개인에 IPTV 채 을 제공하는 오 IPTV 응 기술

- 스마트폰과 연계한 로벌 이러닝 활용 기술

o IT 융합 이러닝 웹 기반 이러닝 서비스에 한 표 화가 이슈로

부각

3. 추진 목표 략

가. 수요 지향형 R&D

이러닝이 정보통신기술의 비약 인 발 에 힘입어 화, 문화, 고도화됨에 따라서 기술 경쟁력을 확보한 국내 네트워크 모바일

인 라를 활용하여 정부와 민간이 효율 인 역할 분담을 통해 ‘혼합

실 기반 가상교육 캠퍼스 커뮤니티’ 교육 서비스 개발

o (정부 주도) 원천 기술 분야인 혼합 실 데스크탑 가상화 기술 신

규 R&D 추진

- 서버 기반의 클라우드 컴퓨 서비스 제공을 해 필수 인 데스

크탑 가상화, 스토리지 가상화, 웹OS, IO가상화

o (민간 주도) ‘혼합 실 기반 가상교육 캠퍼스 커뮤니티’ 서비스

실 을 한 요청 기반 셀 서비스 클라우드 기반 혼합 실 이러

닝 시스템 설계

- 실감형 교재와 콘텐츠 콘텐츠 작 도구, 3D 콘텐츠 작 도

구 그리고 학습 리 시스템과 인터페이스와 같은 기반 기술 확

보

- 90 -

(그림 2-1) 혼합 실 기반 가상교육 캠퍼스 시스템 아키텍쳐

참조 : 한국 자통신연구원, 혼합 실기반 이러닝 기술동향

나. 신시장 발굴을 한 시범 사업 추진

(1) 학 교육 기 선도 시범 서비스 제공

o 시간과 장소에 제한 없이 혼합 실 교육 환경을 제공하는 교육용

가상화 데스크탑 시범 서비스 추진(Smart Campus Community Service)

o 11년 학교 U-러닝 시스템과 연동하여 시범 서비스 제공

o 11년 서비스 개발을 한 테스트 베드 조성

o 12년 까지 20개 기업과 5개 학을 선정하여 서비스 안정성 등을

시험 검증한 후 추가 학을 선정하여 혼합 실 기반 교육 서비스

모델을 창출

(2) 교육 련 서비스

- 91 -

o 혼합 실 기반 가상 교육/이러닝 강좌 수업, 수업 도우미

o 수업 련 자료 공유, 보고서/과제물 출제 제출

o 출석 체크, 각종 성 정보 입력

o 강의 계획서 강의 평가 결과 조회, 수강신청

o 선배의 강의 내용을 공유하는 멘토링 로그램 운

(3) 가상 앙 도서 운

o 도서 검색 외부 자료 신청

o 도서 도서 여 황 eBook 여

o 도서 좌석 약 취소

o 각종 증명서 발

(4) 커뮤니티 서비스

o 동아리 회원 가입 탈퇴

o 스터디 그룹

(5) 공지사항 서비스

o 단과별 이메일 SMS 발송

o 실제 캠퍼스와 같은 가상 게시 , 자보, 홍보 서비스( 학, 학과, 동아리 등)

(6) 개인별 맞춤형 가상 실 서비스

o 각종 증명서 원스톱 발

o 무선 랜 각종 정보/ 산 서비스 신청

o 개인별 포트폴리오 리 공간 제공

- 92 -

(그림 2-2) 혼합 실 기반 가상교육 캠퍼스 체 화면

o 교내 복지 서비스 제공

o 기존의 트 터 페이스 북과 같은 SNS와 연계된 인터페이스 제

공

(7) 교내용 사이버 머니 제도

o 축 (학교 설문, 강의평가, 출석 성 우수, 각종 교내 회 수

상)o 사용(게임, SMS 발송, 도서 좌석 약 시 우선권 구매, 아바타

리용 물품 구매, 각종 증명서 발 비용, 그 외 학교 복지 시설에

이용 가능)

(8) 혼합 실 기반 가상교육 컴퍼스 커뮤니티 시

- 93 -

(그림 2-3) 회의 컨퍼런스

(그림 2-4) 수업 강의

- 94 -

(그림 2-5) 공지 사항

(그림 2-6) 교육 서비스 선택 화면

- 95 -

다. 산업 활성화를 한 여건 조성

(1) IT 융합 이러닝 서비스에 한 표 화 정립

o 국, 독일, 일본 등 표 선진국에서는 교육 정보화 분야에서의 시

장 경쟁력 활보를 한 국제표 화 노력을 더욱 강화할 것으로

망 되므로 국제 경쟁력에 뒤쳐지지 않는 국가 인 차원의 국제 표

활동 강화

- ISO 국제 표 화 기구 IMS, IEEE 등 사실상 표 화 기구와

연계한 표 화 응체계 운 이 필요한 시

o 국가 략 목표와 연계하여 정보화가 교육에 미치는 효과를 극

화 할 수 있는 략 이러닝 표 화 수립 검토

o 이러닝 표 기술의 연구� 개발 성과를 국내 이러닝 제품 서비

스에 표 용하는 권장 방안 마련

(2) 서비스 도입 진을 한 법� 제도 개선

o 서비스 제공에 필요한 합리 인 SW 라이선스 제도 수립

o 양질의 이러닝 컨텐츠, 솔루션 개발을 유도 할 수 있는 품질 인증

체계 마련이 요구

o 이러닝 시스템 요구 사항, 콘텐츠 재산권 보호 상호 호환성 보장

을 한 법체계 마련이 요구

o 개인정보 보안에 한 방안 검토 련 법� 제도 정비

(3) 정보 통신 네트워크 속도 향상 인 라 고도화

o 상 인식의 안정성과 실시간성의 문제 해결을 해 기존 네트워크

망 속도 개선안 검토

o 고가의 인터페이스 장비 도입을 한 처 방안 마련

- 96 -

o 가상화에 필요한 클라우드 컴퓨 인 라 확충을 한 제도 마련

(4) 산업체의 자율 시장 참여 유도를 한 제도 마련

o 데스크탑 가상화, 스토리지 가상화 솔루션을 선도 으로 용한 시

범사업 참여자에 해 인센티 제도 검토

제 2 스마트 라이 환경을 한 융합형 클라우드 컴

퓨

1. 개요

가. 정의

“클라우드 컴퓨 을 통한 일과 삶의 조화와 진정한 IT 융합을 만드는

컴퓨 업무 환경” 정보 통신 기술의 융합을 통해 시간과 장소의 제약을 없애고 클라

우드 컴퓨 을 이용하여 가상의 업무 환경을 조성하여 언제 어디서나

업무를 수행하는 유연한 근무 방식으로 일과 삶의 조화를 꾀하고

업과 소통강화, 생산성 신, 업무 연속성을 제공하며 모든 업무 작업

을 클라우드 앙 서버 단의 가상화된 데스크탑 환경에서 수행함으로

써 진정한 지식 공유화와 자산화를 이루는 진일보된 근무 환경이다. 업무 환경을 클라우드 컴퓨 센터의 가상 오피스 환경에 두고 기존

데스크탑 뿐만 아니라 스마트폰 태블릿 PC등 다양한 IT 단말기를

통해 구성원 모두가 업무를 공유할 수 있도록 한다. 기존의 환경에서

인터넷 기반으로 클라우드 컴퓨 센터간의 호환성을 제공하고 같은

컨텐츠에 한 복을 제거하며 컨텐츠를 서로 나 어 제공받는 모델

- 97 -

로서 련 서비스 수 약서(Service Level Agreement)로 차원 높

은 서비스 질을 제공하기 한 환경을 제공한다.

나. 필요성

(1) 새로운 패러다임 환의 사회 요구

기존의 산업시 에 합한 획일 인 근무 방식에서 지식 정보 사회

에 합한 정보 통신 기술을 이용한 유연한 근무 환경을 만들어 기

술이 필요성이 요구되고 있는 시

(2) 사용자 요청 기반 셀 서비스 요구

언제 어디서든 필요한 근무 환경을 바로 쓸 수 있고 필요한 IT업무

인 라를 필요한 만큼 쓸 수 있음

(3) 측정된 업무 요구

클라우드 서비스는 제공자에 의해 모니터 되고 리 된다. IT자원의

최 화에서 더 나아가 재 근로자의 업무 성과와 상황을 있는 실시

간 악이 요구

(4) 유비쿼터스 네트워크 속 요구

모든 업무 환경은 근로자의 IT자원 역량에 상 없이 표 화된 서비

스로 일정하게 제공 될 수 있으며 네트워크 상에서 원활하게 돌아가

도록 요구

(5) 빠른 탄성 요구

- 98 -

유연한 업무의 선택과 집 에 따라 자원을 상황에 맞게 늘리거나

불필요한 상황에선 여야 하므로 필요에 따라 거나 많은 컴퓨

자원을 제공할 필요가 있음. 가상화 기술을 통해 클라우드 자원의 상

황에 따른 탄력 인 응이 요구 됨

(6) 차원 높은 자원 풀 요구

클라우드 컴퓨 의 자원 풀은 다 소유 모델로 서비스 할 수 있게

하고 가상 자원들은 사용자의 요청에 따라 할당되고 재할당 된다. 높

은 벨의 추상 인 자원 치를 설정 할 수 있어 체 자원을 임의

의 벨로 설정 가능

(7) 통합된 디지털 업 강화와 유연 근무제 확

개개인의 비연속 인 환경에서 가상화된 자원의 공유를 통한 체

시스템의 통합이 요구되며 이를 통해 면 업무 문화를 극복은 물론

업무의 연계성이 보장된 유연한 근무 환경이 필요해짐

(8) 클라우드 컴퓨 기반의 스마트 워크 경쟁력 확보 시

사회 반 인 비용 감소가 요구되고 선진국에 비해 뒤떨어진 스마

트워크 도입이 매우 조한 실정이므로 비용 비 성능 문제에서 인

라를 합리 인 비용으로 구축하기 해서는 클라우드 컴퓨 이

안이 되며 렴한 비용으로 실제 사무실 환경과 동일한 수 의 서비

스가 개발되어 제공되는 것이 가능해짐

2. 국내외 황 문제

가. 해외 추진 황

- 99 -

(그림 2-7) 미국 원격근무자 수 증가 추이

(1) 미국

o 원격 근무자 수 황 망

Worldatwork가 발간한 ‘Telework Trend lines 2009’에 의하면, ‘06년 최소 월 1회 원격근무를 하는 근로자(고용형 원격 근무자)는

1,240만 명에서 ‘08년 1,720만 명으로 2년 간 39% 증가

참조 : Worldatwork ‘Telework Trend lines 2009’

o 총무성(GSA, General Services Administration)은 스마트워크 민간

활성화를 해 워싱턴DC 일 에 구축한 15개의 원격근무센터를 민

간기업에 하루 40~60달러의 사용료를 받고 개방 운 함으로써 미

국 체 직장인 15.5%(3400만명)이 스마트워크를 수행

o 재택 근무가 ‘08년 34.5백만 명에서 ‘16년까지 43% 확 될 것으로

측(포 스터 리서치, ’09. 3).o ‘정보 통신기반 원격근무 활성화 방안’이 미 상원을 통과(’10.5)

- 2009년 연방 정부의 50%가 원격 근무

o 연방 정부 차원의 ‘범부처간 재택근무 시범사업 로젝트’를 통해

공공 부문에 스마트워크를 선도입했으며 2007년 기 80여개 행정

기 에서 원격 근무 자격이 있는 직원의 7.62%가 스마트워크를 수

행

- 100 -

[표 2-3] 미국 재택근무자 수(‘08년~’16년)

참조 : Forrester Research

(2) 국

o 이미 1993년부터 BT 워크 스타일이라는 탄력근무제를 도입

o 체 BT 직원 9만2000여명 에 85%가 스마트워크 기술을 기반으

로 한 재택근무, 원격근무, 출퇴근 자율제 등에 참여로 인해 오히려

기존보다 병가율이 63% 감소했고, 산후휴가 복귀율은 99%에 달했

으며, 탄력 인 고용여건이 제공되면서 체 고용인원도 증가

o 사무실 공간 감소에 따른 업무공간을 자산화 함으로써 2006년까지

9억5000만달러에 달하는 비용을 감

(3) 일본

o 출산� 고령화로 인한 ‘노동인구 감소’를 해결하기 한 방안으로

‘원격근무제도’의 추진을 결정, 가이드라인개발 환경정비에 착수

(2003년 ‘e-Japan 계획’) ‘2010년까지 취업인구 스마트

워크 근무자 비율을 20%로 확 하는 목표를 수립(2007년 ‘텔 워

크 인구배증을 한 액션 랜’)o 원격 근무 련 설비 취득 후 자산세 감면과 같은 세제지원 정책을

제정 민간 확산을 지원하 고 ‘08년 기 스마트워크 근무자 비율은

15.2%로 확

- 101 -

o ‘08년 일본의 원격 근무자 비율은 15.2%로, ‘05년 10.4% 비 약

5% 증가

(그림 2-8) 일본 원격근무자 비율

참조 : 국토교통성, ‘2008년 텔 워크 인구 실태조사’, 2009.4 원격근무자 비율 : 원격근무자 수 / 15세 이상 취업자

(4) 네덜란드

o 사업체의 49%가 원격 근무를 실시(‘07년 12월 기 )o 융업과 비즈니스 서비스업에서 원격 근무가 일반 임

나. 국내 추진 황 문제

(1) 국내 추진 황

o 삼성 SDS는 산·육아 친화경 이란 화두로 우수한 여성인력 확보와

유출방지를 해 재택근무 제도 운

o KT는 분당에 스마트워킹센터를 개 하고 2012년 말까지 국 30개 지역에 스마트워킹센터를 구축해 새로운 성장 모델로 도입

o 삼성 증권은 모토로라의 FMC 솔루션 도입으로 무선 화, 이메일, 그룹 웨어 등을 하나의 모바일 단말기에서 활용할 수 있게 하 으

며 그 결과 장소에 구애 없이 실시간으로 고객 응 가 가능해 졌으

- 102 -

(그림 2-9) 원격근무자 비율

며, 외부 세일즈를 하는 시간에도 업무 지속성을 유지함

참조 : Statistics Netherlands, 'Digital Economy 2008', 2009

o CJ 제일제당은 업무의 연속성 제고 목 으로 외근, 해외출장 에도

사용할 수 있는 모바일 오피스를 도입하여 결재 소요시간이나 업무

처리 시간이 획기 으로 개선 되는 결과를 이끌었다.o 모비스는 본사 국내외 지사간 화상회의를 실시하여 국내지사

해외지사 간 출장 감소

o 한국 IBM은 시간·장소에 계없이 필요한 업무를 수행할 수 있는

‘모바일오피스’ 도입

o 포스코는 스마트폰을 활용한 ‘스마트팩토리’를 구축하여 생산 장

신 신속한 의사결정 지원

o 공업은 설계도면 조회, 공정 입력 등이 가능한 ‘와이 로 조

선소’를 구축하여 장에서 실시간 업무처리

o 롯데 홈쇼핑은 주문 화가 쇄도하는 시간 에 탄력 인 인력 운용

을 해 시간 별 재택근무제 운

(2) 국내 산업 문제

‘08년 원격 근무 도입 ‘09년 도입 계획이 있는 사업체의 비율

- 103 -

은 체 사업체의 1% 미만에 불과해 사업체 부문의 원격근무 도입이

활성화되지 않았음

o 원격 근무를 한 인식 환 획기 인 인 라 도입이 시

o 세계 최고 수 의 IT 인 라에 비해 재택근무 도입률이 0.7%로 선진

국의 20분의 1수 에 불과

o 한국 기업은 유연근무제 활용에 있어 아직 보 수 으로 제도에

한 인식 환이 필요한 시

o 2008년 말, 체 사업체(315만여 개) 원격근무를 도입한 사업체

는 0.6%인 1만 8천여 개 사업체로 나타났으며, 2009년 원격근무를

신규 도입 는 지속 추진 의지가 있는 사업체는 0.7%인 2만 4천

여 개인 것으로 추정되었다.

(그림 2-10) 원격근무 도입 계획

참조 : 한국정보화진흥원, 2009정보화통계집

3. 추진 목표 략

가. 목표

- 104 -

o 스마트 라이 환경을 한 융합형 클라우드 컴퓨 을 통해 언제

어디서나 이용 가능한 가상 오피스를 조성

o 일과 삶의 조화를 이루는 진일보된 근무 환경인 스마트워크를 완성

o 추후 선진국 수 의 원격 근무율을 50% 달성하고 2만여 개 사업체

도입을 확보하기 한 교두보 마련

o 스마트폰 기반의 장 심 모바일 오피스 확산

o 창의 인 지능형 업무환경 완성

o 업무 환경을 클라우드컴퓨 센터의 가상 오피스 환경에 두고 기존

데스크탑 뿐 만 아니라 스마트폰 태블릿 PC등 다양한 IT 단말기

를 통해 구성원 모두가 업무를 공유

o 공 자와 사용자 사이에 서비스 수 약서(Service Level Agreement)로 차원 높은 스마트 라이 서비스 품질을 제공

나. 수요 지향형 R&D

최고 수 의 네크워크 인 라와 IT기술력을 기반으로 정부와 민간이

역할 분담을 통해 세계 스마트워크 시장을 선도 할 수 있는 “융합형

클라우드 스마트 라이 솔루션” 개발

(1) (정부 주도) 스마트 인 라 확충을 한 기술 투자와 개발

(가) 수요자 심의 융합형 클라우드기반 스마트 라이 기술 개발

o 스마트워크센터에 스마트 라이 를 한 클라우드 데스크탑 가상

화 기술 개발 용

- 스마트워크센터 : ICT기반의 원격 업무 시스템을 갖춘 시설

o IT 자원 없이 모니터와 입력장치만 가지고 원격으로 데스크탑

가상화가 가능하도록 서버 기반의 클라우드 컴퓨 솔루션 개발

o 서비스 제공을 해 필수 인 데스크톱 가상화, 스토리지 가상화,

- 105 -

네트워크 가상화, 가상IO 등 핵심 기술 개발

o 스마트워크에 알맞도록 커스터마이징된 융합형 클라우드 스마트

라이 솔루션 개발

(나) 유무선 네크워크 인 라 고도화

o 와이 이 지역 이용 지역 확 (‘10년 53,000개소) 수퍼와이

이 도입

- 수퍼 와이 이 : 방송용 유휴 주 수 역인 화이트 스페이스를

사용하여 역 와이 이 망을 구축하는 기술

o 국 와이 로 서비스 지역 확 (‘11년 국 84개 도시로 확

)o 새로운 이동통신망(4G) 상용화(‘13년)o 기존 랜보다 10 빠린 기가 인터넷 서비스 도입으로 유선망

고도화

(2) (민간 주도) 서비스 실 을 한 고객 맞춤 클라우드 스마트 라

이 서비스 랫폼 기술개발

o 서비스 달 랫폼, 클라우드 사용자 단일 인증 트래픽 리

기술등 수요자 심의 비즈니스 모델 개발을 한 기반 기술 확보

o 가상 데스크탑 클라우드와 퍼스 미디어 클라우드가 융합된 형태

의 랫폼 개발

o 서비스수 약(Service Level Agreement)을 통한 보장된 양질

의 가상 환경을 보장

o 클라우드 컴퓨 도입으로 사용자 단에서 인 라 장비를 이용하

여 모든 운 리 자원, 보안 리 자원, 어 리 이션 자원을 앙 서

버에 속하여 스트리 으로 사용하기 때문에 사용자는 단말기 외에

는 소 트웨어 으로 별도로 리할 사항이 없어 매우 편리하고 클

- 106 -

(그림 2-11) 융합형 클라우드 컴퓨 서비스 랫폼

참조 : ETRI Virtualization Data

라우드 센터에 모든 컨텐츠가 장되기 때문에 보안성이 높음

(그림 2-12) 클라우드 컴퓨 을 이용한 스마트워크 아키텍쳐

참조 : 벤처기업 회, 그린 SW 기술 시장 동향

- 107 -

다. 신시장 발굴을 한 시범 사업 추진 연계

(1) 정부 기 선도 시범서비스 제공

정부 공공 기 의 스마트워크를 해서 시간과 장소 그리고 IT 자원의 제한 없이 업무를 수행할 수 있는 공공기 용 융합형 클라우

드 스마트 라이 시범 서비스 추진

o 스마트워크센터에서 융합형 클라우드 스마트 라이 솔루션을 이용

하여 근무자에게 IT 자원을 나눠주고 사무실과 동일한 가상 데스크

톱 환경을 추진

o 추후 “일부 앙부처 시범도입(’11)”, “ 앙 부처로 확산(’12)”, “공공기 민간 확산 추진(’13)”계획에 연계된 스마트워크센터에

서 활용 가능한 호환성 제공

(2) 그린IT 시범 서비스 연계

o 출퇴근 교통량을 감소시키고 탄소 업무환경 환 서비스의 일환

으로 지능형 교통� 물류체계와 연계한 시범 사업 추진

o 지능형 력망 재난조기 응과 융합형 클라우드 스마트워크와

연계한 시범 사업 연계 추진

o 가상화 데스크탑의 기술 완료 시까지 기술 용과 검증이 수월한

기 을 심으로 추진

(3) 사업체들의 도입을 유도하기 산업 연계형 시범 서비스 추진

o 소기업 개인 사업체를 상으로 스마트워크의 도입 활성화를

한 ‘클라우드 스마트 라이 ’ 테스트 베드 조성

o ‘12년까지 100개 기업을 선정하여 서비스 효율성과 안정성을 시험,

- 108 -

검증한 후 서비스 국 확산을 통해 비즈니스 모델 창출

라. 산업활성화를 한 여건조성

(1) 융합형 클라우드 스마트 라이 솔루션 도입 진을 한 법과 제

도 개선

o 스마트워크 업 활성화를 한 원격근무 지원기술 개발 지원

o 공공부문 확산을 한 제도화와 스마트워크 련 행 법률정비

o 스마트워크 실행 지침 가이드라인 제정

o 민 의체를 구성 운

(2) 정부 추진 사업에 융합형 클라우드 스마트 라이 솔루션 사용을

권장하고, 산업체의 자율 용을 유도

o 정부, 지자체, 공공기 을 상으로 추진 인 망분리 사업에 보

안성을 강화한 가상화 방식의 논리 망분리(클라우드 컴퓨 시

스템) 솔루션을 용하여 데스크탑 가상화 시장 활성화 진

- 산이 5,000억원에서 3,000억원으로 40%가 감

- 2 의 PC 구동에서 1 의 구동으로 에 지 50% 감

- 정부의 규모 클라우드 컴퓨 시스템 운 에 따른 소 트웨어

활성화에 기여

공공기 의 원천 인 해킹차단을 하여 인터넷망과 업무망을 분리

시키는 사업으로 PC 2 를 설치하는 기 의 물리 방식과 함께 ‘10년부터 PC 1 로 가상화 기술을 이용한 논리 망분리 방식도 허용

(국가정보원, ’10.1월)

(3) 공공 부분 정부 추진 사업에 융합형 클라우드 스마트 라이

- 109 -

솔루션 사용을 권장

o 스마트워크센터 구축시 융합형 클라우드 스마트 라이 솔루션의

선도 도입 유도

o 행안부는 스마트워크센터를 ‘15년까지 공공 30개소 민간 450개

소로 단계별 확산할 것을 추진하겠다고 발표

- 110 -

제 3 장 서비스 활성화를 한 법/제도

정책방향

제 1 사용자 보호 측면에서의 문제

클라우드 컴퓨 서비스에 하여 사용자들은 여러 가지 측면에서 불

안감을 가지고 있다. 특히 클라우드 컴퓨 서비스에 문제가 생길 경우

사용자가 얼마나 보호될 수 있는가에 한 우려가 크다. 최근에는 구 G메일 속장애, 트 터 사내자료 유출, 세일즈포스닷

컴 아마존의 서비스 단 등으로 사용자들의 불안감이 커지고 있기

때문에 클라우드 컴퓨 서비스에 한 안정성과 신뢰성 확보에 한 요

구가 높아지고 있다. 이러한 사례들이 반 하는 바와 같이 서비스 사업

자가 산하는 경우, 서비스가 단되거나 장애가 있는 경우, 사용자의

개인정보 보호, 랫폼의 독립성 강화 등에 한 문제 이 크게 부각되

고 있으며, 법 으로 이를 보호할 수 있는 방안이 미흡하다. 각각의 측

면에서 우리나라 법제도가 가지고 이슈는 다음과 같다.

1. 사업자 산

사업자가 산하는 경우, 클라우드 컴퓨 서비스의 사용자 입장에서

는 손해가 막 할 수밖에 없다. 사업자가 산하는 경우, 기존에 서비스

이용자는 안정 으로 서비스를 이용하지 못해 지 까지 서비스를 이용해

진행하던 업무가 정지하게 된다. 한 데이터가 훼손되거나 손실되는 경

우, 지 까지 클라우드컴퓨 서비스에 보유하고 있었던 정보들이나 데

이터를 잃게 된다. 만일 서비스 제공자의 산 이후 다른 서비스 제

공자를 찾는다고 하여도, 기존에 제공받던 서비스를 동일하게 제공받을

수 있는지, 업체들 간 시스템 부분에서 호환이 가능한지의 문제들이 발

- 111 -

생할 수 있다. 이와 련하여 해외에서는 클라우드 컴퓨 사업자의 산에 따른 피

해 축소를 해 부분 기술자료 임치제도를 활용하고 있다. 기술자료

임치제도란, 개발자의 소스코드, 실행 로그램 등을 제3의 임치기 이

보 하고 있다가 사업자의 산․폐업 등이 발생하는 경우 해당 임치물을

사용 기업에게 제공하여 해당 기술의 신뢰성을 보호하여 주는 제도이다. 사업자의 산은 상치 못한 상황이기 때문에 클라우드 임치기 이 사

용자 정보의 실시간 자동 백업이 클라우드 임치의 핵심 요소이다. 표

인 기술임치 서비스 기업은 미국의 Iron Mountain사와, 국의

NCCGlabal사가 있다.

2. 서비스 단 장애

클라우드 컴퓨 서비스가 단되거나 장애가 발생하는 경우에도 사용

자는 서비스 공 자가 산하는 경우와 유사한 피해를 입게 된다. 특히

클라우드 컴퓨 서비스는 인터넷과 마찬가지로 각각의 서비스와 컴퓨터

가 네트워크로 연결되어 있어 바이러스 감염이나 침해사고 등에 취약하

여 언제라도 서비스에 장애가 발생할 수 있는 가능성이 크다. 게다가 클

라우드 컴퓨 서비스는 사용자의 정보를 서비스 제공자의 서버에 장

해놓는 형태로 제공되기 때문에 서비스 장애에 따른 정보 유실이나 손실

의 규모는 여타 다른 인터넷 기반 서비스보다 훨씬 클 것으로 상할 수

있다. 서비스 사용자가 입게 되는 손해의 크기뿐만 아니라, 클라우드 컴퓨

서비스는 인 라스트럭처, 미들웨어 랫폼, 소 트웨어 애 리 이션

등까지 포 하는 범 가 큰 서비스이다. 따라서 단일 사업자 는 복수

사업자가 서비스 제공에 참여가능하기 때문에 서비스 장애에 따른 손해

배상의 귀책에 한 분쟁이 일어날 소지가 크다. 이를 방하기 해서는 클라우드 컴퓨 서비스 사업자의 이용 약

- 112 -

규정에서, 우선 서비스 장애에 따른 손해배상의 범 를 명확히 규정하는

것이 필요하다. 특히 손해배상 범 에 해당하는 장애 시간을 폭 여

야 한다. 한 손해배상의 면책 규정을 일방 인 사업자 입장만을 고려

하는 것이 아니라 서비스 이용자의 입장을 함께 고려함으로써 서비스 이

용자들이 서비스를 이용하는 데에 있어서 가지는 불안감을 해소해 수

있어야 할 것이다.

3. 사용자의 정보보호

클라우드 컴퓨 의 핵심 기술은 가상화이다. 따라서 사용자가 장해

놓은 데이터의 치 악이 어려울 뿐만 아니라 외부공격에 취약하고, 리자가 권한을 오남용 하는 경우 민감한 개인정보의 유출 험이 크

다. 그럼에도 불구하고 행법에 의하면 사용자의 개인정보 보호에 외

가 되는 법조항들이 존재한다. 한 정보 유출로 인하여 개인이 큰 피해

를 입은 경우에도 행법으로는 서비스 제공자에게 벌 을 부과할 뿐 구

체 으로 피해자에 한 보상이 명시되어 있지 않아 클라우드 컴퓨 의

사용자들에게 정보보호에 한 불안감을 해소시켜 주기에는 미흡한 이

많다.

4. 랫폼의 독립성 강화

랫폼의 독립성이란, 랫폼이 운 체제 는 단말기에 상 없이 작

업을 행할 수 있는 것을 의미한다. 클라우드 컴퓨 서비스에서는 랫

폼의 독립성 강화가 무엇보다도 요하다. 클라우드 컴퓨 서비스 사업자가 갑작스럽게 산을 하거나 사업을

폐지하는 경우, 기존에 해당 서비스를 이용하던 사용자들은 다른 서비스

로의 환이 불가피하다. 이 경우 랫폼이 독립 인 경우, 사용자들은

별다른 환비용 없이 손쉽게 다른 서비스로 옮겨갈 수 있게 된다. 따라

- 113 -

서 클라우드 컴퓨 서비스에 있어서 랫폼의 독립성 강화는 사용자들

의 권리와 정보를 보호해 수 있는 제도 장치의 연장선이라 할 수

있다. 클라우드 컴퓨 활성화를 한 랫폼 독립성 확보를 해서는 우선

“국가정보화기본법”상에서 랫폼의 독립성 확보를 한 의무규정을

추가하는 것이 필요하다. 그러나 재 클라우드 컴퓨 산업이 시작되려

는 시 에서는 랫폼의 다양성과 산업경쟁력 확보를 하여 민간부문

모두에 랫폼 독립성을 의무화 하는 것은 바람직하지 않다. 이와 달리

공공부문은 인터넷 서비스에 한 국민들의 보편 근성 보장이 우선

이다. 따라서 모든 정부기 의 자 으로 구축되는 시스템에 한하여 랫

폼의 독립성이 보장되도록 하는 규정을 추가하는 것이 필요하다.

제 2 공 자 지원 보호 측면에서의 문제

공 자의 측면에서 볼 때 사용자가 불안감을 느끼는 사항들은 모두 공

자에게도 불안감으로 작용될 수 있다. 공 자 측면에서 바라본 사용자

의 불안감은 크게 사용자 정보의 보안성과 안 성으로 나 수 있다. 공

자의 입장에서는 사용자의 정보의 보안 유지와 사용자 정보의 손망실

을 방지하기 해 안 성을 유지하는 것이 시행되어야 하지만 이에 한

책은 재로서는 미비하다. 추가 으로 클라우드 컴퓨 의 서비스는

시작된 지 얼마 되지 않아 이에 한 이해도나 지원이 빈약하다. 인

자원이나 법제도 측면에서의 지원이 미흡한 도 공 자들이 클라우드

컴퓨 서비스를 공 하는데 문제 이 될 수 있다.

1. 사업의 보안성 확보

- 114 -

클라우드 컴퓨 의 문제 으로 지 되는 서비스의 보안성을 들 수 있

다. 사용자 측면에서 언 한 로 해킹 등의 외부 공격과 리자의 오남

용 문제로 인해 사용자들은 보안성에 해 우려할 수 있다. 사용자의 우

려는 곧 공 자의 우려로 번질 수 있다. 사용자의 정보에 한 보안성을

확보하지 않은 상태에서 서비스를 시행하다가 보안 문제로 인해 사용자

가 피해를 입는다면 공 자 역시 이에 한 손해배상을 비해야 한다. 사용자에 한 배상 범 와 액수도 정확하지 않아 많은 문제 이 상된

다. 클라우드 컴퓨 서비스 보안을 규정하는 제도는 아직 자리 잡지 못했

다. 기존의 법률은 정보통신 산업 쪽의 보안을 유지하는 데에는 가능할

지 모르지만 클라우드 컴퓨 에 용하기에는 명확하지 않은 부분이 많

다. 따라서 행 법 체계를 개선하기 해서는 몇몇 방안이 필요하다. 먼 공 자가 서비스 공 에 있어서 충분한 보안 책을 세우고 클라우

드 컴퓨 에 맞는 보안 요소를 보장할 수 있는 법규를 신설해야 한다. 그리고 데이터가 국외로 분산되는 경우 국내의 클라우드 컴퓨 서비스

를 받을 수 있는지에 한 법률 규정도 필요하다. 이 외에도 클라우드

컴퓨 으로 인해 새로 나타나는 기술들인 가상화 서버에 한 보안 항목

을 추가하거나 기존 체계에서 소홀히 다 진 데이터에 한 복구 는

임치 등을 규정하는 항목 한 추가되거나 새로이 클라우드 컴퓨 을

한 인증체제로 만들어 나갈 필요성이 있다.

2. 상호 호환가능성을 통한 서비스 안정화

공 자간의 호환성은 클라우드 컴퓨 서비스를 안정화 시킬 수 있다. 단기 인 시각으로 볼 때 호환성은 각 사업자의 특성을 통합하여 이윤을

감소시킬 수 있다. 그리하여 재 공 자간의 호환성에 해서는 클라우

드 컴퓨 산업에서 크게 이루어지지 않고 있다. 한 이를 규정하는 법

제도 한 미흡하여 서비스를 안정화 하는 데 있어서 많은 문제 을 야

- 115 -

기하고 있다. 먼 모든 사업자들이 상호호환성과 표 화를 통해 사고율을 낮추고

개념을 일 성 있게 정리하여 체 인 시장의 크기를 넓힌 뒤에 각 공

자가 개별 인 사업 아이템을 들고 나와야 수익성을 확보할 수 있을

것이다.

3. 공 자의 역량 강화

공 자 측면에서 볼 때 정부나 민간 부문의 인력 지원, 조세 감면, 제

도 보완, 규제 완화 등의 직 인 지원도 요한 요소 의 하나이

다. 그러나 클라우드 컴퓨 은 기술이 도입되어 실제로 서비스가 실시된

지 얼마 안 된 계로 클라우드 컴퓨 을 사용하는 기업에 한 지원 제

도가 미비하다. 먼 클라우드 컴퓨 을 실행하는 기업에 한 정의가

모호하여 지원에 한 범 가 정해져 있지 않다. 이로 인해서 클라우드

컴퓨 을 서비스하는 기업의 경우 그 지원의 상과 규모가 정확하지 않

아 지원이 어렵다. 이를 한 가장 기본 인 방법 하나로는 클라우드 컴퓨 산업을

여타 소기업이나 벤처기업과 같이 하나의 산업으로 규정하고 클라우드

컴퓨 의 범 를 명시하는 법률을 하나 신설하는 것이다. 클라우드 컴퓨

산업이 하나의 법률로서 명시된다면 다른 법률에는 새로운 법률을

용하는 내용으로 수정하는 방식으로 공 자들에 한 역량 강화를 이룰

수 있다.

4. 인증제도

인증제도는 제품 기술의 효과를 보증하여 사용자가 신뢰를 갖고 사

용할 수 있도록 하는 방식이다. 재 클라우드 컴퓨 이 도입된 지 얼마

되지 않은 상황에서 인증제도는 다수의 클라우드 컴퓨 에 해 알지

- 116 -

못했던 사람들에게 신기술에 한 불안감을 여 수 있다. 이로 하여

공 자들은 사용자들의 신뢰를 얻어 좀 더 과감하게 기술을 개발하여 클

라우드 컴퓨 산업을 활성화시킬 수 있게 된다. 한 산업계 측면에서

도 이러한 인증(GS, NET 등)획득은 공공기 의 우선구매 뿐만 아니라

자 지원, 정부 사업 참여시 가 부여, 조세지원 등의 혜택을 받을 수

있다.

- 117 -

참고문헌

[1] Cloud Computing Use Case Discussion Group, “Cloud Computing Use Cases,” Ver. 4.0, July 2010[2] Distributed Management Task Force(DMTF), “Interoperable Clouds,” Ver. 1.0 , Nov. 2009[3] Peter Mell, and Tim Grance, “The NIST Definition of Cloud Computing,” Ver. 15, Oct. 2009[4]“Open Cloud Manifesto,” http://www.opencloudmanifesto.org/, Spring 2009[5] Thijs Metsch, “Open Cloud Computing Interface – Use Cases and Requirements for a Cloud API,” Open Grid Forum, GDF-I.162, Jan. 2010[6] Peter Mell, and Tim Grance, “Effectively and Securely Using the Cloud Computing Paradigm,” NIST, Information Technology Laboratory, Oct. 2009[7]“2007년 해외디지털콘텐츠시장조사”, 2008. 10 한국SW진흥원

[8] KATS 기술 보고서, “이러닝 산업 표 화 동향”, 2010. 4 지경부

기술표 원

[9]“혼합 실기반 이러닝 기술동향”, 2009. 2 한국 자통신연구원

[10] 2009 이러닝산업실태조사”, 2010. 3 정보통신산업진흥원

[11]“2009 정보화통계집”, 2009. 10. 한국정보화진흥원

[12]“IT 융합의 국내외 동향 국내 산업역량 강화 방향”, 2010. 2 한

국 자통신연구원

[13]“IT기반 원격근무 재조명과 정책이슈”, 2009. 8. 한국정보화진흥원

[14]“그린 SW 기술 시장 동향 - Virtual Office 분야 -”, 2009. 12. 벤처기업 회

[15]“창조경 과 유연근무제”, 2009년 삼성경제연구소

- 118 -

[16]“Smart Work 구 략”, 2010. 6. 4행정안 부

[17]“인터넷 안의 내 컴퓨터 추진방안”, 2010. 5 지식경제부 정보통신

산업과

[18]“2008년 텔 워크 인구 실태조사”, 2009. 4, 일본 국토교통성,[19]“모바일 오피스 넘어 스마트워크 시 성큼”, 2010. 9 제79호 - 연

합뉴스

[20]“ 동 이러닝 시회 참가, 300만 달러 계약 체결 상”, 2010. 4. 22 - ITDAILY[21]“SK 로드밴드-강남구청, U-러닝 존 구축”, 2010. 2. 25 - ITDAILY[22]“통신 3사 클라우드 서비스 략”, 2010. 9. 26 – CIOBIZ[23]“기업 스마트워크센터 도입, 교통유발 분담 감면 추진”, 2010. 8. 31 - mk뉴스

[24]“출퇴근 ‘NO’ 세계는 스마트워크 열풍”, 2010. 7. 20 - 디지털타

임스

[25]“한국 ‘수퍼 와이 이’ 도입 가속”, 2010. 10. 6 - 디지털타임

스

[26]“서울시, u-러닝서비스 ‘쌤’ 2월부터 시행”, 2010 1. 31. - ITDAILY[27]“SKT, 스마트인강 메가스터디 서비스 런칭”, 2010. 7. 12 - 미디어

잇

[28]“NIPA, 산업부문 이러닝 품질인증 평가 문화한다”, 2010. 6. 3 – ZDNet Korea

- 119 -

1. 본 보고서는 한국인터넷진흥원의 사업결과입니다. 2. 본 보고서의 내용을 발표할 때에는 반드시 한국인터넷진흥원 결과

임을 밝 야 합니다. 3. 본 보고서의 원은 한국인터넷진흥원이 소유하고 있으며, 당 진흥

원의 허가 없이 무단 재 복사를 합니다.

클라우드 서비스 용 가능 분야별 환경분석

정책방향 연구

인쇄 : 2010년 11월

발행 : 2010년 11월

발행인 : 서 종 렬

발행처 : 한국인터넷진흥원(KISA, Korea Internet & Security Agency) 서울시 송 구 가락동 79-3 동빌딩

Tel : (02) 405-4118인쇄처 : 동국 학교 Copy Center

서울시 구 필동 3가 26 번지 동국 학교

Tel : (02) 2260-8984

< 비매품 >