기본 콘텐츠로 건너뛰기

Apple iCloud와 Google, Cloud Computing Metaphor 비교

애플의 스티브 잡스는 6월 6일 있었던 WWDC 오프닝 키노트에서 자사의 iOS 플랫폼을 새로운 클라우드 컴퓨팅 플랫폼인 iCloud와 밀접하게 결합하도록 플랫폼의 진화를 선언했다.

일부 클라우드 서비스 제공 기업들이 클라우드를 주로 스토리지 즉, 저장소 중심으로 표현하는 경향이 있어서, 왜 KT 같은 기업들이 클라우드 컴퓨팅을 스토리지 중심으로 바라보나 (혹은 광고하나?) 하는 의문이 있었는데, 애플의 iCloud 발표는 또하나의 다른 시각을 보여주는 셈이었다.

스티브 잡스가 설명하는 애플의 iCloud 메타포

클라우드 컴퓨팅을 어떻게 이해하면 좀더 쉽게 개념(mental image)을 잡을 수 있을까? 그리고 구글과 애플, 기타 다른 기업들의 접근 방식을 이해할 수 있을까?
추상적 개념은 은유법만큼 이해하기 쉬운 게 없고, 또 잘 만들어진 은유 체계는 사고의 깊이를 더하고 더 발전시킬 수가 있다.
조금 지나치게 단순화하는 감이 있지만, 개괄적 수준에서 이해해주기 바란다. 클라우드 컴퓨팅의 기반 기술을 보는 게 아니라 활용 측면에서 바라보는 것이므로 전문 지식 없이도 쉽게 이해할 수 있을 것이다.

클라우드 컴퓨팅의 메타포(은유 체계)
흔히 클라우드라고 부르는 것은 클라우드 컴퓨팅(Cloud Computing)을 뜻하는 것인데 단순화해서 표현하자면 클라우드는 인터넷을 의미하고 컴퓨팅은 개념적인 컴퓨터의 연장선 상에 있다.

메인프레임, 유닉스 혹은 퍼스널 컴퓨터(PC)에 익숙해진 컴퓨팅 개념을 클라우드로 확장시키려면 컴퓨팅의 요소들을 식별해보면 쉬운데 대표적 요소는 1. 프로세서 즉 계산 장치, 2. 장기 기억 장치 즉 저장소(스토리지), 그리고 3. 이 환경에서 실제 실행되는 프로그램들을 들 수 있다.
이렇게 단순화하면 첫번째 요소인 프로세서에는 PC의 경우에 CPU와 메모리, 캐시 등의 요소들이 모두 포함된다고 볼 수 있다. 즉, 프로세서라고 분류한 영역은 계산 능력을 가지고 있다. 좀더 구체적으로 기능을 설명하면 프로그램을 실행하는 요소이다.
두번째 요소인 스토리지는 다양한 용도로 사용될 수 있겠지만, 보통의 경우 프로그램을 저장하는 스토리지와 데이터를 저장하는 스토리지로 구분할 수 있다.
세번째 요소는 프로그램, 실제 실행 가능한 논리들을 가지고 있는 단위이다. 보통 프로그램 프로그램용 스토리지에 저장되어 프로세서에 의해 실행된다고 볼 수 있다.

구글의 클라우드 컴퓨팅
클라우드 컴퓨팅의 확산에 절대적인 기여를 한 기업으로 구글을 들 수 있다. 구글은 현재 회자되는 클라우드 컴퓨팅의 기술적 토대를 구현하고 또 그 기술을 공개하는 등 대단한 기여를 해왔다.
앞의 세 가지 분류에 따라 구글의 클라우드 접근을 정리해보자.

1. 프로세서
구글에게 있어 클라우드 프로세서는 실제 클라우드로 구성되는 서버에 존재한다고 볼 수 있다. MapReduce와 같은 클라우드 상의 동시 처리 기술을 가지고 이에 맞게 설계된 프로그램들이 실제 클라우드에서 실행된다.

2. 스토리지
프로그램 정보도 서버의 확장 개념이라고 볼 수 있는 클라우드 상에 위치하고, 프로그램이 사용하는 데이터 역시 클라우드 상에 위치한다.

3. 프로그램
구글의 클라우드 프로그램은 기본적으로는 기존 서버 프로그램의 확장이라고 볼 수 있다.

클라우드 기반의 프레임웍(PAAS, Platform as a Service)인 Google AppEngine 같은 형태로 혹은 다른 수많은 서비스 API들로 프로그램들을 좀더 쉽게 만들 수 있도록 해주기도 한다.
구글에게 클라이언트 즉 사용자와의 인터랙션을 담당하는 프로그램은 웹 기술을 사용하는 것이다. 웹은 서버에서 주로 실행되는 사용자 인터랙션 처리 코드를 가장 잘 실행할 수 있는 환경이다.

구글의 크롬 넷북은 이러한 클라우드를 사용자에게 잘 전달해줄 수 있는 휴대용 콘솔 역할을 할 수 있다. 프로세서, 스토리지, 프로그램이 거의 모두 서버 개념의 확장인 클라우드에 위치하기 때문에 콘솔 자체는 크게 중요하지 않다.
따라서, 구글의 클라우드 컴퓨팅은 점점 더 웹 표준과 서버쪽 기술에 집중한다. 이런 측면에서 안드로이드 모바일 플랫폼의 현재 모습은 애플의 iOS와 경쟁하기 위해 현실적인 형태를 취하고 있으며 점점 더 웹 콘솔의 역할이 강화될 일종의 전이기transition period 단계에 있다고 볼 수 있다.
모바일의 특성을 살리면서도 크롬 넷북의 성격을 받아들이는 길을 택할 것이다.

애플의 iCloud
이번에 발표된 iCloud는 일반화되어 있는 구글의 클라우드 컴퓨팅 시각과는 조금 다른 측면을 볼 수 있었다.
개인적으로는 분산 컴퓨팅과 서버쪽 기술에서 출발한 구글과 개인화된 클라이언트 컴퓨팅에서 출발한 애플의 특성 차이라고 느꼈다.

1. 프로세서
애플은 클라우드 상에서 실행되는 서비스나 앱에 대해서는 언급이 없다. 여전히 로컬 클라이언트의 CPU에서 대부분의 프로세싱을 처리한다.
프로그램의 주된 형태도 여전히 개인 컴퓨팅 기기에서 실행되는 클라이언트 앱이나 애플리케이션이다.

2. 스토리지
애플의 프로그램 스토리지는 예전처럼 프로그램은 클라이언트 기기에 있고, iCloud는 프로그램 바이너리의 백업 역할을 한다.
데이터 스토리지는 클라이언트 기기에도 있지만, 점점 더 클라우드의 역할이 커질 것으로 보인다. 클라우드의 역할이 커질수록 로컬 스토리지는 클라우드 스토리지의 캐시처럼 역할을 하게 될 것이다.

3. 프로그램
전통적인 로컬 앱과 크게 다르지 않지만, 클라우드 스토리지 활용이 쉬워진다는 차이점이 있다. 구글의 경우 클라우드 기반의 서비스들이 주 프로그램이고 웹이나 앱으로 작성된 사용자 인터랙션 부분은 단순 콘솔 개념의 클라이언트 역할을 하지만, 애플의 경우에는 클라이언트 앱이 핵심 역할을 여전히 수행한다.
클라우드 기반의 서비스는 애플에겐 그야말로 서버 기반 서비스이며 로컬 앱과는 다른 지위를 가지는 것으로 보인다.
물론 애플도 공식적으로는 HTML 5 표준 기반의 웹 앱 지원에 대한 적극 지원을 약속하고 있긴 하지만, 현실적으로는 웹앱에 큰 비중을 두지 않는 것으로 보인다.

애플 iCloud와 구글, 미래는 구름 속
애플의 iCloud는 기존의 클라이언트 컴퓨팅 기조를 유지하면서 프로세싱과 스토리지 측면에서 최대한 클라우드의 장점을 자연스럽게 활용할 수 있도록 하는 iOS 플랫폼의 보완 측면이 강하다.
구글처럼 모든 것을 클라우드에서 처리할 수 있다고 보는 근원적인 발상의 전환과는 차이가 있다.
하지만, 어느것이 더 낫고 못하는가의 문제는 아니다. 여전히 구글은 네트웍은 신뢰할 수 없다network is unreliable는 네트웍 기반 컴퓨팅의 근원적인 약점을 해결 혹은 보완하기 위해 다각도로 노력하고 있다.
최근에 드러나고 있듯이 클라우드 컴퓨팅에서 정보가 한 곳에 모일 경우 개인 정보에 대한 보호, 보안 문제가 해커 뿐만 아니라 정보 당국 압력에 의해서도 위태로와지는 단점도 보인다.
애플의 iCloud는 구글의 컴퓨팅 패러다임 전이처럼 놀라운 일은 아니다. 다만 애플이 해왔던 클라이언트 기반 컴퓨팅 플랫폼의 관점에서 클라우드의 장점을 매우 자연스럽게 결합해내고 있다. 구글이 혁명이라면 애플 iCloud는 개혁 수준이라고 할까.
개인적으로 클라우드의 미래는 아직 완벽하진 않다고 생각한다. 구글 크롬북과 같은 크고 작은 실험들이 어떤 결과를 가져올지에 따라 달라질 것 같다.

댓글

이 블로그의 인기 게시물

[Java] Java G1 GC의 특성에 따른 Full GC 회피 튜닝 방법

Java 6 중반부터 G1 GC가 나오면서 이 새로운 Java VM GC 정책을 두고 성능 튜닝을 어떻게 할지 고민이 많은 것 같다.

일단 생소하기 때문에 어렵다.

그런데 경험들이 조금씩 쌓이면서 문제점도 꽤 발견되는 것 같다.

먼저 G1GC를 이해하는 데 유용한 사이트이다.

Garbage-First CollectorGetting Started with the G1 Garbage CollectorUnderstanding G1 GC LogsTuning Garbage Collection for Mission-Critical Java ApplicationsControlling GC pauses with the GarbageFirst CollectorG1: One Garbage Collector To Rule Them AllGarbage First (G1) Garbage Collection Optionscompare JVM options for public메일 : G1 GC clean up time is too long
JDK 7부터 기본이 된 G1(garbage first) GC는 JVM의 Heap 메모리를 1MB 정도 크기의 region들로 나눠서 region별로 generation을 지정하여 상당히 효율이 좋지만 튜닝하는 게 까다롭다.
(새로운 메모리 처리 구조에 대한 튜닝 경험도 많이 부족해서 더욱 까다롭게 느껴지는 것 같다.)

지금까지 널리 알려진 문제로는 첫째, perm generation collection을 full gc때만 하는 문제가 있다.
즉, 클래스 언로딩을 full gc때만해서 자주 재배포가 발생하는 코드가 있는 경우 문제가 될 수 있다.
앞으로는 perm generation을 완전히 없애도록 JVM의 방향을 잡고 있기 때문에 당분간 이 문제는 해결하지 않을 것으로 보인다.

둘째, G1 GC에서 거대 객체(humongous object)라고 부르는 메모리 사용량이 큰 객체들에 대한 처리는 아직 최적화되지 않았다. 보통 한 region의 50% …

[Java] Heap Dump 분석을 통한 Perm Area Memory Leak 원인 진단

Software 특히 Java 언어를 사용하는 Software 개발 조직에 몸담고 있지만, 마흔을 훌쩍 넘긴 나이에 이런 글을 쓰는 것이 적합한지 의심되는데 특히 국내 SW 환경을 고려한다면 몹시 우스꽝스럽다.

이젠 개발팀장도 아니고 개발실장도 아니고 그위의 관리자이지만, 아직 완전히 제품 코드로부터 역할을 분리하지 못했고, 이러한 시간이 많이 걸리고 책임 소재가 불분명한 문제를 해결할 전문 인력을 두고 있지 않기 때문에 결국 직접 하는 경우가 생긴다. 이것은 미흡한 관리 능력의 결과라고 봐도 좋겠다.

개인적으로는 이러한 일이 전혀 나쁘지 않다. 즐거운 Software Life의 하나일 뿐이다.
관리자가 이러한 삽질을 직접 하는 것이 관리 체계를 무너뜨리는 것 아니냐고 묻겠지만...

oh, give me a break.. 나중에 교육교재 만드는 데 도움이 될까해서 하는 관리 행위의 하나라고 봐주기 바람~~ ㅠ_ㅠ;;

perm gen 과 class leak
Permanent Generation 은 young과 old를 구분하는 Generational Collector 방식인 Sun (now, Oracle)의 HotSpot JVM에서 Old generation 중 한 영역이다.
lifetime이 길다고 판단된 object들을 old generation으로 옮겨서 빈번한 gc의 대상이 되지 않도록 하는 것이 generational collector의 기본 아이디어인데 permanent generation은 old 중에서도 거의 gc 대상이 될 일이 없다고 생각되는 object들을 딴 영역에서 관리하겠다는 아이디어의 산물이다.

HotSpot JVM의 Perm Area 에는 주로 자바의 클래스 객체들이나 문자열 상수 풀에 속한 String 객체들이 위치한다.
메모리 leak의 대상이 되는 것은 string constants 보다는 주로 class 객체들이다.

(class 객체는 주로 객체의 타입을 나타내는 클래스나 인터페이스를 표현하는 객체로 타입명 뒤에 .class…

맥북프로 13인치 2010년 버전의 하드웨어 업그레이드 산전수전 경험기

혼돈의 시작
2010년에 구입한 맥북프로 13인치.

메모리 4GB,  하드디스크 256GB

2013년에 맥북프로 레티나 13인치를 사면서 아내와 딸이 함께 구형 맥북프로를 사용했다.

2016년에 또다시 맥북프로 레티나 13인치를 딸에게 사주면서 버려질 위기에 처한 맥북프로를 아내가 논문 작성용으로 쓰고 싶다고 해서 고민하다가 하드웨어 업그레이드를 결심.
메모리를 좀 늘리고 HDD를 SSD로 바꾸면 충분히 빨라질 것이라고 당연한 판단.

먼저 여기저기 뒤져서 애플에서는 공식 지원하지 않는 맥북프로 업그레이드 방법을 찾아냈다.
기종을 정확하게 아는 게 핵심.
우리 집 맥북프로의 공식 버전명은 MacBooPro 7.1 혹은 MacBook Pro Mid 2010 이었다.

먼저 메모리를 찾아봤다. 16GB까지 업그레이드 가능하다는 주장도 있었으나 주장들이 좀 엇갈려서 안정적으로 4GB 두 개 즉, 8GB로 업그레이드하기로 했다.

8.0GB OWC Memory Upgrade Kit - 2x 4.0GB PC8500 1066MHz 204 Pin (gmarket에서 9만 2천원. 배송비 포함)

다음은 HDD를 대체할 SSD.
이것도 여기저기 찾아봐서 호환이 확실히 되는 걸 찾았다.

MICRON Crucial MX300 275GB SSD (gmarket에서 9만 7천 2백원. 배송비 포함)

한국에서 구매하는 방법은 G-Market 뿐이었던듯.
아마존은 대부분 한국에서는 구매할 수 없는 곳 뿐이었다.

그리고, 마지막으로 맥북을 분해 조립하기 위한 드라이버들.
메모리와 HDD 교체에 필요한 드라이버는 작은 십자 드라이버 하나였다.
(하지만, 종류별로 다 구매했다는 ㅠ_ㅠ 나중에 나오지만 배터리를 교체하려면 Y자 드라이버도 필요하다. 드라이버는 한 개당 gmarket에서 1800원 정도.)

2016년 8월 10일
자, 이제 20만원 가까운 금액을 gmarket에 입금!

2016년 8월 24일
주문한 부품들이 도착한 것은 2주 후

분해와 조립, 무한 반복...
이제 이 맥북도 곧 날라다니겠…