티스토리 툴바


IT /IT 관련 잡담2012/02/01 14:26



안녕하세요. 

제가 브라우저의 다음 패러다임에 대해 글을 적어본 적이 있습니다.  

 
웹은 바다입니다. 오직 바다입니다. 바다 뿐이 없었습니다.
사람들은 네비게이션 달린 브라우저라는 배를 타고 바다를 유람하고 있었습니다. 
사람들은 배를 타고 바다를 항해하며 바다의 파도를 감상할 뿐이었습니다. 

점차 웹은 변화하여 이곳저곳에 섬이 생겼습니다. 
사람들은 섬에 사람들과 교류를 하기 시작했습니다. 
한 섬에서 할 수 있는 일이 너무 제한적이라 섬을 옮겨다니며 교류를 했죠. 

어느 시점에 사람들은 집을 짓고 자신의 집에 그림, 동영상, 사설 등을 모아놓기 시작했습니다. 그리고 더 많은 사람들과 더 많은 것들을 나누고 싶어하기 시작했습니다. 바다 위에 작은 섬들에는 하나 둘 다리가 놓이더니 점차 바다를 메꿔서 커다란 대륙을 형성하였습니다. 

하지만 많은 사람들은 여전히 많은 시간을 바다 위에서 혹은 멀리 있는 섬들을 방문하고 다닙니다. 대륙은 그들에겐 그저 큰 섬일 뿐입니다. 다른 작은 섬들에 가는 것 처럼 큰 섬에도 가서 바다에서 건진 전리품들을 장식해놓습니다. 
그러던 중에 누군가가 "이거 너무 귀찮다."는 생각을 하고, 
자기 배 위에 집을 짓습니다. 그리고 대륙에 있는 집에 포탈을 설치하네요. 

이제 이 사람은 바다 위에서 자유를 얻었습니다.
자기 배를 타고 다니면서 언제든 원할때 포탈을 타고 대륙에 가거나
작은 섬들을 방문하거나 아니면 그냥 바다 위를 표류할 수도 있습니다.
 

글의 주제는 여기에 있습니다. 
간단히 말해서 브라우저는 지금까지는 수동적으로 사용자의 요청을 처리해주는 Viewer 역할을 했습니다. 

비운의 브라우저 Netscape


 브라우저는 웹을 항해하기 위해서 등장했기 때문입니다. 많은 URL들과 많은 정보들, 그 때도 지금도 사용자 대부분은 정보를 공유하기 웹을 사용합니다. 이 후, 점차 웹은 소통을 위한 공간으로 성장해 나갑니다. 웹이 소통하기 위해서는 웹에 존재하는 모든 서비스들이 소통해야 합니다. 

 이런 변화의 요구를 웹 만의 발전을 통해서 이뤄내기는 어렵습니다. 왜냐면 웹의 발전을 모든 서비스가 따라갈 수 있는 것은 아니기 때문입니다. 결국 adobe의 flash처럼 이를 중계하기 위한 솔루션이 등장할 것입니다. 이번 글에서는 이런 변화를 요하는 근거와 이를 통한 웹 서비스의 변화를 다루고자 합니다.

 


 

modem으로 접속하던 PC통신 하이텔!

 

초기 프리챌 커뮤니티!

 

페이스북 초기

 
 
사람들의 소통에 대한 욕망은 전화선을 연결한 56k modem으로 연결하던 PC통신에도 있었습니다. 조금 과거로 돌아가서, PC통신을 하셨던 분들은 이야기 혹은 세롬 데이터맨 이라는 프로그램을 아시나요?


이야기



세롬데이터맨



두 프로그램은 PC통신 클라이언트였습니다. 브라우저는 웹 클라이언트이구요. 말하자면 PC통신을 하던 시기에도 PC통신에 맞는 브라우저가 존재했다는 겁니다. 브라우저에 대해 어떤 고정관념이 있다면 지금 버리시길 바랍니다. 


그럼 사람들이 꾸준히 소통을 바라는 이유는 뭘까요? 



그것은 사람들의 욕구이기 때문이죠. 매슬로우라는 사람은 이렇게 얘기했습니다. 사람들의 욕구는 단계적으로 발현된다. 그리고 사람의 욕구를 5단계로 정리했습니다. 이 이론은 꽤나 세상과 잘 맞아 들어가는 것 같습니다. 현 시대에 많은 사람들이 생리적 욕구와 안전에 대한 욕구를 문제없이 충족하고 있으며, 그 이후의 욕구인 소속감, 친밀감, 사랑에 대한 욕구를 원하게 됐습니다. 


이와 같은 욕망의 변화가 기술에 반영이 됐다고 저는 생각합니다. 


Facebook, Twitter와 같은 SNS는 사람들이 쉽게 친해지고 대화를 나눌 수 있도록 유도합니다. SNS에서 이뤄지는 활동 대부분이 서로의 안부나 근황, 그리고 화젯거리에 대한 이야기 입니다. 

여기서 생기는 문제는 이 공간에서 다뤄질 수 있는 콘텐츠의 질과 범위가 상당히 제약이 생긴다는 점입니다. 다시 말해서 콘텐츠를 만드는 사람들이 자신들의 콘텐츠를 자유롭게 다루기는 조금 부족한 공간이라는 문제가 있습니다. 

 

 통계적 법칙으로 1% 규칙이란게 있습니다. 
 인터넷 커뮤니티, 포럼, 카페와 같은 공간에서 사람들의 활동을 통계를 내보면 1%의 사람들이 콘텐츠를 창조하는 활동을 하고 나머지 99%의 사람들은 가벼운 덧글도 달지 않았다는 통계에 따릅니다.

 오해하지 마실 것은, 이 활동은 "통계"에 근반하기 때문에 전체적으로 그렇다는 것이지 항상 그렇다는 것이 아닙니다. 

 쉽게 풀어드리자면, 한 단위 시간대에 100명의 사람 중에 한 명이 글을 포스팅하는 등의 활동을 하지만 나머지 99명의 사람은 타인의 글을 읽는 등의 활동을 하지만 결코 글을 올리거나 덧글이나 댓글을 쓰지는 않는다고 생각하시면 됩니다. 

 그러므로 1%의 사람들은 커뮤니티, SNS 같은 서비스에는 굉장히 중요한 핵심 요소라고 볼 수 있습니다.  


통계의 법칙은 SNS에서도 증명이 됩니다.


통계의 법칙은 마이크로블로그(Twitter)에서도 증명이 됩니다.


 SNS나 마이크로블로그 서비스만 이용한다면 사람들은 금방 지루함을 느낄 겁니다. 왜냐면 이 공간은 마치 일상 일어나는 대화같은 느낌이라 웃기고 유쾌한 일보다 평범하게 "Hi~요즘어때?" 식의 대화가 주를 이루기 때문입니다. 어떤 콘텐츠라고 불릴 만한 것을 올리고 공유하기에 최적화된 공간이기 때문에 오히려 콘텐츠를 생산하는 장소로는 활용되기 어렵습니다. 그나마 나오는 콘텐츠라는게 "나 어디갔다왔어.", "나 뭐했어." 같은 신변잡기니까요. 여기서 나오는 콘텐츠는 한계가 있습니다.  



 이런 이유로, SNS를 이용하는 사람의 현실 생활이 지루하다면 SNS라고 달라지지 않습니다. 그러니 사람들은 여전히 콘텐츠를 목말라합니다. 할 얘기가 없으면 보라고 TV를 만든 것처럼 SNS 공간에서도 TV가 필요하고, 아이에게는 장난감이 필요하고, 뭐 그런거죠. 때문에 페이스북은 소셜 플러그인을 통해 외부 콘텐츠를 끌어오는 방법을 고안한 것이죠.
 


 Google에서 만든 SNS인 Google+는 이런 문제를 해결하기 위해 일부 개선을 하고 나왔습니다. 
 불특정 다수와의 대화를 개선하기 위해 서클이란 것을 만들었고, 원래 있는건지 아니면 업데이트 된건지 모르겠지만 Google+ 페이지 서비스를 도입했습니다. Google의 페이지는 블로그와 형태가 매우 유사합니다. 블로그라는 공간이 SNS가 나오기 전에는 SNS와 비슷므리한 역할도 했었지만 주력은 역시 주제에 대한 포스팅이죠! 어쨌건 구글의 페이지는 1%의 사람들을 위한 공간입니다. 지속적인 콘텐츠의 생산과 이를 통한 콘텐츠 생산자를 중심으로 생기는 "관계"를 통해 사람들의 소통이 자연스럽게 하면서, 동시에 콘텐츠 생산자는 창작욕구를 만족할 수 있습니다. 이 욕구는 앞서 살펴본 매슬로우의 욕구단계론에서 4단계에 해당하고, 주요 욕구는 타인의 관심, 존경 등입니다. 강연이나 재능기부 등은 주로 이 단계의 욕구에 의한 활동이죠. 지금 제가 블로그에 글을 쓰고 있는 이유도 실은 자기 과시욕이 쩔고 다른 사람들에게 인정받고 싶어하는 욕구 때문입니다. 
 

구글페이지의 예. 음악에 대해 집중적으로 다루는 블로그같이 생겼습니다.



 저는 Google 페이지에 상당히 호의적이고 효과를 거둘거라고 생각하고 있습니다. 왜냐면 저도 이 생각을 했거든요 (-_-)... 그렇다는 얘기는 아마 누구나 이 생각을 한 번쯤은 했단 얘기고, 서비스로 나온 것을 봐서 구글에서는 최소한 1년 전에는 기획에 들어갔다는 뜻이 되겠죠? ^^  하지만 냉정히 얘기해서, 이는 시대착오적인 서비스라고 생각합니다. 구글+는 지속적으로 성장할 것이지만 구글+ 페이지가 이에 큰 공헌을 할 것이라고 생각하지는 않습니다. 


구글+페이지에서 기대할 만한 서비스

더보기




 제가 구글+페이지에 비판적인 이유는  
 지금도 많은 사람들이 굳이 SNS를 이용하지 않는 활동을 하고 있고 자신들의 욕구를 충분히 만족시킬 방법과 방안을 찾아왔으며 그에 합당한 서비스들이 많이 존재하기 때문입니다. SNS의 인기는 기존 공간에 대한 불만에서 온 것이 아니라 더 편하고 자유로운 개선 요구에 의한 것으로 보는게 맞습니다. 그러므로 기존의 서비스들과 연계하여 조화를 이루는 방향으로 가는 것이 옳지, 자신들의 플랫폼 안에 모든 것을 포괄하는 서비스를 만들겠다는 생각은 바람직하지 않기 때문입니다. 

 이는 페이스북의 정책과도 반대되는데, 구글은 마치 정복자처럼 자신들의 구글+에 웹의 서비스들을 하나 둘 병합하는 방향으로 가는 반면, 페이스북은 소셜 플러그인으로 연합하는 방향으로 가고 있습니다. "don't be evil." 이라고 외치던 구글은 어디 갔나요? 


 저는 페이스북 쪽에 서서, 웹 서비스들을 연계하는 방향을 지지합니다. 구글+의 수많은 개선에도 불구하고 향후 웹서비스는 M&A를 통한 통합서비스가 아니라 숱한 군소 업체와 서비스를 연합하는 방향으로 갈 것이라고 주장합니다.

 그렇다면 구글+페이지를 시대착오적 발상이라고 비판한 제가 예상하는 향후 연계 서비스는 어떤 모습일까요?
 그를 저는 Pinterest를 통해 살펴보고자 합니다. 


 
Pinterest 에 대한 소개 자료는 이걸 참고해주세요.   

더보기


Pinterest는 Pin+interest 로 흥미있는 것에 Pin을 의미입니다. 마치 메시지를 적어놓기 위해 포스트잇을 쓰듯이 웹에서 흥미로운 것을 발견하면 이를 포스트잇에 써서 모두 함께 보자~! 는 서비스입니다. 







또한 외부에 자유로운 공유를 할 수 있습니다. :) 
공유를 하면서 Source가 표시되는게 신기하죠?
위는 Embed 태그를 통해 공유된 것이고 이를 공유하는 과정부터 살펴보겠습니다. 

pinterest.com 일부 캡쳐



사용자는 이와 같은 화면에서 자기가 마음에 드는 포스트~~잇~~ 을 떼어다 자신의 공간으로 가져올 수 있을 겁니다(?). (pinterest는 현재 close 서비스 중이라 계정을 신청한다고 바로 이용할 수 없어서 추측성이 조금 들어갑니다. ). 마음에 드는 애플맥북 스킨을 클릭해볼까요? 





Pinterest는 쇼핑을 목적으로 하니까 대충 보고 넘어가도 괜찮겠지요? ^^
외부 사이트와 Pinterest가 연계하는 방식이 중요합니다. 

 

 
 Pinterest는 외부 사이트 연계를 위해 브라우저를 위한 Plugin을 공개하고 이를 통해 이미지 등을 pin할 수 있고, Pinterest는 pin된 자료의 출처와 내용을 파악할 수 있습니다. 

 또한 pin된 이미지를 공유하기 쉽게 소셜 플러그인을 통한 SNS 공유, Embed HTML tag를 통한 외부 사이트 연계를 쉽게 할 수 있도록 해줍니다.  

 만약 pinterest 서비스가 쇼핑 상품이 아닌 다른 콘텐츠의 공유 공간이라면 어땠을까요? 

 Pinterest의 사례에서 보듯이, 외부 연계를 통한 연합은 브라우저를 통해 이루어 낼 수 있습니다. Pinterest는 쇼핑에 집중된 서비스였기 때문에 쇼핑에 대한 정보를 공유하는데 그쳤지만 이후 더 많은 서비스들이 브라우저의 부가기능 plugin을 통해 웹이라는 플랫폼은 자신들의 서비스와 연계하고자 할 것이고 더 멋지고 훌륭한 형태가 등장할 것이라고 예견해봅니다. 

 페이스북은 소셜 플러그인을 통해 잘 해왔지만, 사용자 입장에서는 조금 부족함을 느낄 겁니다. 특히 소셜 플러그인의 가장 큰 약점은 블로그, 웹사이트 등이 이를 지원하지 않으면 사용할 수 없다는 것인데, 소셜 플러그인을 브라우저에 플러그인으로 제공하는 방식으로 바꾼다면 웹이라는 플랫폼을 끌어안기에 부족함이 없을 것이라고 생각합니다. 그리고 이를 통해서 기존의 웹 서비스와 SNS가 제대로 시너지 효과를 낼 수 있을 것입니다.

 특히 이와 같은 미래가 도래했을때 자체 플랫폼에 너무 많은 것을 끌어안은 폐쇄형 서비스에게는 큰 타격이 될 것 입니다. 
 
 이상입니다. 긴 글 읽어주셔서 감사합니다 ^^



저작자 표시 비영리
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
Posted by 화박 화박
IT /IT 관련 잡담2012/01/28 00:12



안녕하세요. (-_-); 

이번 글은 세마포어와 뮤텍스의 근본 원리에 대해서 다뤄볼 생각입니다. 
제목은 별로 신경쓰지 마시고,


흔히 세마포어와 뮤텍스에 대해서 설명할 때 예를 듭니다. 

화장실이 하나다 여러개다. 뻑!!! 뻑!! 아 이 소리는 가려워서 손등을 긁는 소리입니다. 

원론적인 얘기로 돌아가, 
세마포어와 뮤텍스는 왜 생겼을까요?? 
왜 갑자기 화장실이 튀어나올까요? 그리고 그 화장실은 여자용일까요 남자용일까요? 
 
우리는 세마포어와 뮤텍스를 배울때 임계영역(Critical Section)에 대해서 배웁니다.

임계 구역(critical section)또는 공유변수 영역 병렬컴퓨팅에서 둘 이상의 스레드가 동시에 접근해서는 안되는 공유 자원(자료 구조 또는 장치)을 접근하는 코드의 일부를 말한다. 임계 구역은 지정된 시간이 지난 후 종료된다. 때문에 어떤 스레드(태스크 또는 프로세스)가 임계 구역에 들어가고자 한다면 지정된 시간만큼 대기해야 한다. 스레드가 공유자원의 배타적인 사용을 보장받기 위해서 임계 구역에 들어가거나 나올때는 세마포어 같은 동기화 매커니즘이 사용된다.    -wiki

그렇죠? 아는척 하셔야지 제목보고 궁금해서 들어온 체면이 사시지 않겠습니까? 
이 이야기를 곰곰히 풀어보시고, 다시 화장실 얘기로 돌아가봅시다. ( 그 화장실이 여자용인지 좀 물어봐주세요. )
 
즉, 세마포어와 뮤텍스는 여러 스레드(태스크 또는 프로세스)가 임계 구역에 들어가고자 할때 스레드의 배타적 사용을 보장해주기 위해서 나왔습니다. 무슨 얘기인지 어려우시다구요? 쉽게 얘기해서 당신이 화장실에 들어가서 문을 잠그는 이유는 뭡니까? 화장실을 혼자 쓰기 위해서죠. 마찬가지로 스레드와 같은 작업자들도 화장실과 같은(임계영역)을 사용할 때 혼자 사용할 시간을 줘야한다는 것입니다. 

하지만 생각을 해보세요. 화장실을 쓰던 사람이 나왔을 때, 당신이 문을 열고 들어가 문을 닫고 잠그기 전까지 시간의 꽤나 걸립니다. 이 때 누군가 정말 너무 급해서 당신을 밀치고 들어가버리거나, 그러려고 손잡이를 잡아채서 당신과 함께 손잡이를 잡고 있습니다. 서로 먼저 들어가려고 애쓰는 사이, 둘 모두 지려버리거나 하는 불행한(?)일도 일어날 수 있습니다. 

 그렇기 때문에 화장실 예는 정말 뻑!!! 뻑!!! ( 아 자꾸 가렵네요) 예가 좋지 못합니다. 
 화장실의 예가 이렇게 예의 장소같은 냄세가 나는 예가 되버린 이유는 화장실 예를 만든 사람이 후배를 가르치기 귀찮아서 혹은 자신이 무지해서 한 가지를 빼먹었기 때문입니다. 

 그것은 바로 한 시간대에 하나의 작업자만이 화장실 문을 열고 들어가 문을 잠글 수 있다는 정의입니다. 
 이 정의를 IT용어로는 ATOMIC OPERATION = 원자적 연산 이라고 부릅니다. 
 
 원자란 무엇입니까? 맞죠, 바로 더 이상 쪼개질 수 없는 어떤 근원적인 것을 말합니다. 
 원자적 연산이란 이에 따라 더 쪼개질 수 없는 연산을 말하는 것입니다.

 눈치가 빠른 분은 벌써 아셨을 겁니다. 
  "화장실 문에 접근해 손잡이를 잡고 문을 열고 들어가서 문을 닫고 잠근다. " -> 이를 원자적 연산으로 정의해놨습니다. 

 더 호기심이 많은 분들을 위해 글을 써보면,
 원자적 연산이 원자적 연산일 수 있는 이유는 이를 연산하는 주체가 이를 원자적으로 받아들이기 때문입니다. 
 쉽게 얘기해서 CPU에는 원자적 연산으로 정의된 명령군이 있습니다. 
 세마포어나 뮤텍스는 이렇게 정의된 명령군을 어셈블리어(혹은 매크로)로 코딩해놨습니다. ( 해놨겠지? )
 또한 이제 한 프로세서가 하나의 코어를 지니는 시절이 아니기 때문에 멀티 코어에서 오는 원자적 연산 명령어 군은 다른 코어에서 동시에 메모리에 접근하는 것을 막습니다. 이로서 원자성을 보장할 수 있습니다. 

더더욱 호기심 많은 분들에게, 
x86 cpu는 CISC 이고, CISC 명령을 풀어서 리오더링을 하는 슈퍼스카라 적용 cpu입니다. 이 때문에 원자적 연산의 원자성을 깰 수 있기 때문에 메모리 펜스라는 특별한 기능도 있습니다. 


혹시 그 동안 모호한 예로 알고 있어 답답했거나 했던 부분이 있으시면 아는 범위내에서 답변해드릴께요. 
댓글이나 쪽지로 남겨주세요~^^

 
저작자 표시 비영리
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
Posted by 화박 화박
IT /IT 관련 잡담2012/01/26 14:41


안녕하세요.
오늘 제목은 꽤나 자극적입니다. 의도적이든 의도적이지 않던 그렇게 되었습니다.
혹시 제목만으로 기분이 상하신 분이 있다면 사과를 드리면서 왜 이런 제목을 선택하게 되었는지는 본문을 보시면 이해가 되실 것 같습니다. 



1. IT 기술의 발전과 공헌자들

 논지는 IT기술의 시작에서 시작됩니다. IT 기술의 태동은 해커들에 의해서 시작되었습니다. 해커란 어떤 한 일을 무지하게 열심히 하는 사람을 지칭하는 단어입니다. 어원은 여러 설이 있지만 MIT의 학생들이 컴퓨터가 흔하지 않을때 연구목적으로 컴퓨터 사용시간이 제한되어 있는 것을 학교 담을 넘어서 컴퓨터를 몰래 사용하여 연구를 하면서 생겼다는 말이 제일 훈훈합니다. ^^

 그럼 어떤 해커를 뽑을 수 있을까요? 케빈 미트닉? no. 여기서 말하고자 하는 사람들은 그런 범죄자가 아닙니다. 이 글에서 말하고자 하는 해커들은 얼마전에 세상을 떠나신 데니스 리치, 리누즈 토발즈, 팀 버너스 리 와 같은 사람들입니다.  

 데니스 리치는 UNIX를 개발했으며, C언어를 만들었습니다. 
 리누즈 토발즈는 LINUX를 개발했습니다.
 팀 버너스 리는 WWW을 만들었습니다. URL, HTML, HTTP 모두 이 분의 작품이죠. 
 

팀버너스리

 

리누즈토발즈(말끔버전)

 

돌아가신 데니스리치




 2. 이들이 공개한 기술로 눈부신 발전을 이룬 IT기술과 그 기술로 밥벌어먹는 우리들

 언급한 세 분 외에도 수 많은 사람들이 IT기술에 열의를 가지고 매진한 결과 IT기술은 현재에 이르렀습니다.
 만약 이런 공헌자들이 자신이 개발한 기술에 특허를 걸고 공개하지 않았다면 어떻게 됐을까요?
 기술의 발전은 더뎌지고 세상은 IT기술의 위상은 현재와 같지 않을 것 입니다.  

 그랬다면 여러분이 지금 종사하는 IT 업계나 서비스에서 현재와 같은 일자리를 제공받을 수 있었을까요?


 3. 그러므로 스티브 잡스를 꿈꾸지 마시라. 더 큰 꿈을 꾸어보자.
 
 IT 업계에 종사하시는 분들은 좋든 싫든 공헌자들의 혜택을 입고 있습니다. 
 팀 버너스 리는 '인터넷 공동체 안의 모든 사람이 영광을 함께 누려야 한다.‘  라고 했습니다.
 IT 종사자라면 이 분들처럼 자신들이 만든 프로그램이 세상을 이롭게 하는 꿈을 꾸어야 하지 않겠냐는 말입니다. 

 애플의 아이폰은 좋은 상품입니다. 이는 이견의 여지가 없습니다. 
 하지만 그가 좋은 사업가나 기술자냐는 말에는 동의 할 수가 없습니다. 
 애플은 아이폰이란 좋은 상품을 만들어 올린 점유율을 통해 기존에 갑甲이었던 업체들을 밀어내고 또 하나의 거대한 갑甲이 되고 있을뿐입니다. 우리나라에서는 삼성과 같은 대기업에 반감이 심해져 애플을 닮으라며 상생혁신을 외치는데 참으로 웃긴 일입니다. 애플이 중국 폭스콘에 외주준 아이폰 생산라인에서 중국 노동자들이 얼마나 열악한 환경에서 근무했으면 자살과 투신이 그치지가 않고 있습니다. 자신들의 시장에서 상거래를 하려면 자기네한테 돈을 바치라고 강요하고 나섰죠. 만약 안드로이드 시장이 없었다면 벌써 자신들의 말을 따르지 않은 앱들은 추방하고도 남았을 회사입니다. 그럼에도 불구하고 많은 사람들이 스티브 잡스가 대단한 경영자라고 생각한다면, 이는 경제만 살리면 된다고 누구를 대통령에 올려놓은 과오를 똑같이 범하고 있을 뿐입니다. 


 사업이나, 앱을 개발해 큰 돈을 벌고 싶다는 생각을 누구도 말리지 않습니다. 
 하지만 IT를 통해 이와 같은 일을 할 수 있는 기술과 환경을 만들어 준 사람들은 오로지 세상을 위해 스티브잡스, 빌게이츠, 마크 주커버그에 견줄만큼 아니 그 이상의 거액을 벌 수 잇는 기회를 포기하고 세상에 공개했습니다. IT 업계에 종사하면서 꿈을 꾼다면 사업을 생각한다면 이 분들을 생각하면서 임해야 하지 않을까요? 


 IT업계 종사자들이여!! 꿈을 꾼다면 스티브 잡스보다 훌륭하고 뛰어난 사람들을 목표로 하시길 바랍니다. 
 
 자신이 번 돈과 명성은 자기의 세대에 끝나지만, 이 분들의 업적은 두고두고 회자될 것입니다. 





 
저작자 표시 비영리
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
Posted by 화박 화박
IT /IT 관련 잡담2011/11/04 01:07



다운로드 링크 :   

http://battleping.com/setup/BattlePingBeta1.0.exe



 아마 KT 외 인터넷 통신사를 사용하시는 분들은 일정 시간대가 되면 핑이 폭발하는 광경을 많이들 보셨을 겁니다. 핑이 높아진다는 것은 반응속다가 늦다는 뜻이고, 반응속도가 늦다는 뜻은 할당된 대역에 비해 너무 많은 접속으로 지연이 된다는 뜻입니다. 한마디로 요약해서, KT 외에 핑폭이 오는 통신사들은 해외 특히 LA 쪽 망 사업자와 계약할때 회선을 조금만 빌렸다고 가정할 수 있습니다. 

 뭐 그건 그거고, BattlePing 때문에 이렇게 글까지 쓰는 이유는 따로 있습니다. 

 BattlePing이 확실히 효과가 있음에도 불구하고 본인의 실수로 효과를 보지 못하자 '안되잖아!!' 하고 포기하는 분들이 있길래 글을 쓰게 됐습니다. 일단 결론부터 말해서 BattlePing은 "확실히" "절대" 효과가 있어야 정상입니다. ^^

 자~ 그럼 그 이유를 아는김에~ 네트워크 상식도 한번 키워볼까요?

 그 전에, 게임에 앞서 서버 상태를 체크한다고 ns(1~4).riotgames.com 에 핑을 많이 때려보셨을 겁니다. 이게 틀린 방법은 아닙니다. 근데 가끔 어떤 분들은 ns(1~4)가 1번은 무슨 게임 서버고 2번은 무슨 게임 서버고 하는 소리를 하십니다. 저는 이게 뭔소린지 처음엔 이해를 못했습니다.

 저기요...
 ns1.riotgames.com 은 Domain Name 입니다. 즉, ns1.riotgames.com 이라는 서버 주소로 접속하려면 DNS서버에게 "야! ns1.riotgames.com에 접속할거니까 IP주소 좀 알려줘!" 라고 물어봐서 DNS서버가 답해주는 IP로 접속해야 합니다. 한번 생각해보시죠? 게임 서버는 게임 클라이언트가 접속하는 곳 입니다. 게임 클라이언트에게 굳이 이런 과정을 거치게 할 필요가 있을까요? DNS를 거치는 만큼 반응이 느려질텐데요? 

 무슨 얘기를 하려는지 대충 눈치채셨나요?
 ns(1~4).riotgames.com 은 게임 서버와는 관련이 없습니다. 하지만 운이 좋게도 riotgames 서버는 한 곳에 위치해 있었기 때문에 대충 어느정도 핑이 나온다는 예상을 할 수 있던 것입니다.

ns1.riotgames.com 서버

  
 

Custom Game Server

 
게임 서버는 앞서 말한 이유로 굳이 도메인 네임을 받지 않습니다.


자, 그럼 커스텀 게임 서버 주소 64.7.194.161에 집중해주세요. 
배틀핑을 켰을 때와 껏을 때, 어떤 변화가 생기는지 직접 보여드리겠습니다.

non-BattlePing





BattlePing ON


 
차이가 보이시나요?  BattlePing 은 West 7 서버로 연결했습니다. 

보시다시피 BattlePing이 OFF 일때는 UDP패킷을 64.7.194.161 과 주고 받습니다. 
그리고 이 주소는 앞에서 보여드린 Riotgames의 게임서버 IP 중에 하나 입니다. 

하지만 BattlePing을 ON 하면 8.17.252.126 을 통해 패킷을 주고 받게 되는데 

수수꼐끼 그곳



IP의 위치는 이렇습니다. 꽤나 애매하죠? ^^
이게 무슨 IP인가?? 궁금해서 한번 찾아봤습니다. 



도메인 네임이 host.colocrossing.com 이네요. 
www 이 아니라 host 가 들어간 것으로 봐서 특정 목적이 있는 서버의 IP 주소 입니다.

http://www.colocrossing.com 에 들어가보면 네트워크 관련 사업체인걸 알 수 있습니다. 

제가 내린 결론은, [BattlePing을 만든 사람은 이렇게 네트워크 호스팅을 해주는 업체를 물색한 뒤에 지역별로 호스팅 서비스를 받고 BattlePing을 통해 특정 게임의 패킷을 BattlePing에서 설정한 서버로 보내도록 한다.] 입니다. 당연한 얘기지만 그 서버에서는 Riotgames 게임 서버에서 보내는 패킷을 릴레이해서 보내주는 방식이겠죠. 

사실 이 방식은 VPN과 흡사합니다. 차이점은 VPN은 보통 강력한 암호화를 통해 패킷을 보호해주지만 BattlePing 같은 경우에는 그럴 이유가 없다는 차이가 있겠죠. 









 
저작자 표시 비영리
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
Posted by 화박 화박



안녕하세요 ^-^.

나이스게임TV 의 컨텐츠를 즐기는 1인으로서, 
뭔가 더 편하고 재미있게 떠들 수 있었으면 좋겠다 싶어서 맹글었습니다.

프로젝트는 open source로 google code 에서 소스 전문을 받으실 수 있습니다.
http://code.google.com/p/our-playground/
사용툴  git



NicegameTV v1.0 런칭했습니다. ^^ 마켓에서도 다운받으실 수 있을 겁니다. 
현재 지원하는 기능은 다음과 같습니다.
- 10여가지 게시판 지원
- 로그인
- 기타 등등

추가 예정 기능은 다음과 같습니다.
- 자동 로그인
- 글 보여주는 화면 개선
- 글 작성 지원

------------------------------------------------------------------------------------------
현재 버전은 0.71이고 지원하는 기능은 다음과 같습니다.
- 특정 게시판 view
- 방송 일정 

추가 예정 기능은 다음과 같습니다.
- 게시판 추가
- 글 보여주는 화면 개선
- Log-in 
- 댓글 작성


좋은 하루 되세요~
저작자 표시 비영리
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'IT  > 우리들의놀이터' 카테고리의 다른 글

NicegameTV in android v1.0  (2) 2011/08/28
우리 모두의 놀이터 - Open Source project 시작  (0) 2011/07/28
Posted by 화박 화박

use Case diagram






소개
 
 우리 모두의 놀이터는 두 가지 목적을 가지고 시작되었습니다. 
 1. 모바일을 지원하고 싶은 웹(사이트, 커뮤니티)을 보다 적은 비용으로 구현할 수 있게 한다.
 2. 모바일 환경에서 보다 쾌적하게 1의 결과물을 접할 수 있게 한다. 


우리 모두의 놀이터는 더 많은, 그리고 더 소수의 커뮤니티들이 모바일 환경을 지원하기 어려움, 그리고 사용자들이 현 모바일+3G환경에 더 쾌적함을 추구하기 위해서 시작되었습니다. 


 
저작자 표시 비영리
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'IT  > 우리들의놀이터' 카테고리의 다른 글

NicegameTV in android v1.0  (2) 2011/08/28
우리 모두의 놀이터 - Open Source project 시작  (0) 2011/07/28
Posted by 화박 화박
IT /Android 개발2011/07/13 11:17



GHGallery : 원문 보기
 

안녕하십니까? 화박입니다.

이번 글에서는 GHGallery 소스를 약간 수정하면서 체험적 지혜를 나눠볼까 합니다. 

아래는
이 글을 쓰며 참고한 사이트들입니다. 

GsBoB 님의 블로그 글
Android-GridView를-사용할-때-getView에-대한-이해 

Android 레퍼런스 사이트 
GridView

StackOverflow 

Android: Strange out of memory issue



문제.
GHGallery의 코드를 수정하기로 결정하고 대충 갖다 붙혀넣었을때 생기는 문제는 크게 두 가지였다. 이미지가 스크롤의 이동에 따라 갱신이 되고 있었으므로, 3G에서는 도저히 사용못할 오버해드가 되고 있었고 테스트를 위해 불러올 이미지 사이트를 늘였을때는 VM won't let us allocate  라는 메시지를 내뿜으며 뻗어버리는 것이다.


이를 수정하기 위해 두 부분의 코드를 살펴봐야 했다.
첫 째는, 이미지 갱신을 위한 코드인 Adapter의 getView 메소드.
둘 째는, imageView개체에 Bitmap을 넣는 메소드. 


문제파악

첫 번째 문제
첫 번째 문제부터 살펴보면, GHGallery 코드의 getView메소드는 다음과 같이 구현되어 있었다. 

 
public View getView(int position, View view, ViewGroup parent) {

if (view == null) {
view = new ImageView(parent.getContext());
view.setLayoutParams(new GridView.LayoutParams(95, 95));
view.setPadding(2, 2, 2, 2);
}

imageDownloader.download(url[position], (ImageView)view);

return view;
}
  

상기 소스의 의미는 짧게 풀어보면 "갱신하고자 하는 position의 view가 null이면 새 imageView를 넣고, 아닐 경우 그냥 imageDownloader의 download메소드를 호출해 정해진 position에 맞는 url이미지를 view에 넣어준다." 가 되겠다.

이 경우 문제가 되는 이유는, 간단하다. GridView의 경우 화면에 표시되는 position들의 경우 갱신이 없지만, 스크롤을 이동하면서 계속해서 이동하는 position에 맞는 갱신을 하고자 하기 때문이다. 

 0  1  2
 3  4  5
 6  7  8

위와 같은 GridView가 스크롤이 내려간다면 어떻게 될까? 


 0  1  2
 3  4  5
 6  7  8
 9  10  11
 12  13  14

스크롤을 내려 화면에 보이는 imageView 가 3~11이라고 가정했을때, 
9~11까지는 새로 갱신되며, 0~2와 12~14는 차후 갱신 대상이 되는 것이다. 



로컬 작업이면 전혀 문제될 일이 아니겠지만, 만약 이대로 코딩을 하면 프로그램을 쓰는 사람이 와이파이를 찾아 발로 뛰게 될 것 같다는 생각이 든다. 이미지 갱신은 막을 수 없더라도, 최대한 download메소드 호출은 막아야 한다. 


두 번째 문제
vm won't let us allocate... 안드로이드와 같은 운영체제는 임베디드 OS이다. 데스크탑 PC에 비해 조그마한 자원을 가지고 나눠써야 하는 것이다. 그래서 한 프로그램이 너무 많은 메모리를 소유하지 못하도록 할당 가능한 메모리 량에 제한을 두는데 이 제한을 넘어서면 프로그램은 바로 강제종료된다. 그러면서 Log에 남기는 메시지가 바로 vm won't let us allocate ( vm이 할당을 원치 않아요!) 이다. 어쨌든 이 메시지가 나는 이유는 자명한데, 한 GridView에 많은 이미지를 로드했기 때문일 것이다. 
하지만 나는 이 이미지 수를 유지하고 싶다. 어떻게 해야할까? 방법을 찾아보기로 했다. 일단 GridView의 각 View에 ImageView를 넣어주는 부분은 위의 getView메소드에 나와있고, 그렇다면 imageView에 무엇을 채우는지 살펴봐야겠다. 
 


Bitmap bitmap = downloadBitmap(url);
addBitmapToCache(url, bitmap);
imageView.setImageBitmap(bitmap);

downloadBitmap {
 ...
InputStream inputStream = null;
inputStream = entity.getContent();
try {
// Bug on slow connections, fixed in future release.
// return BitmapFactory.decodeStream(inputStream);
return BitmapFactory.decodeStream(new FlushedInputStream(inputStream));
} finally {
if (inputStream != null) {
inputStream.close();
}
entity.consumeContent();
}
}
 ...
 

이 코드는 BitmapFactory를 사용해 다운받은 컨텐트를 Bitmap화 하고 그 Bitmap을 imageView에 넣어줌을 알 수 있다. GridView에서 보여주는 imageView가 40개 정도 된다고 했을때, 꽤나 큰 용량이다. 테스트 시에는 30정도를 로드하고 바로 뻗어버렸다. Bitmap은 기본적으로 Full-size이미지를 의미한다. 

하지만 GridView에 표시되는 해상도라고 해봤자 96x96이다. 어떻게 이미지 사이즈를 줄일 수 없을까?


 
문제 해결 방안
 
첫 번째 문제를 해결하기 위해 가장 먼저 소개하고 싶은 것은 Google의 레퍼런스 코드이다.  일부를 발췌해서 보자. 

 // create a new ImageView for each item referenced by the Adapter
public View getView(int position, View convertView, ViewGroup parent)
 
{
     
ImageView imageView;
     
if (convertView == null) {  
      imageView
= new ImageView(mContext);
       imageView
.setLayoutParams(new GridView.LayoutParams(85, 85));
      imageView
.setScaleType(ImageView.ScaleType.CENTER_CROP);
       imageView
.setPadding(8, 8, 8, 8);
   
} else {
      imageView
= (ImageView) convertView;
   
}
    imageView
.setImageResource(mThumbIds[position]);
   
return imageView;
}
 
 
레퍼런스 코드는 평균점은 맞는 코드이다. GHGallery와 대동소이하다. 생각보다 잘 짜여진 것을 알았지만 왠지 유쾌하지 않다. 현 시점에서 문제가 되는 부분은 imageView의 갱신이 계속 일어난다는 점이기 때문이다. 

갱신을 막아야한다. 

GHGallery 의 내부적으로는 캐쉬를 사용해 반복적인 이미지 다운의 오버해드를 최대한 줄이고 있지만, 이정도로는 만족할 수 없는 것이다. 이를 해결하기 위해 고안한 코드는 다음과 같다. 


private HashMap<Integer, ImageView> container = new HashMap<Integer, ImageView>();
...
 

ImageView imageView = null;

if (convertView == null) {

imageView = new ImageView(parent.getContext());

imageView.setLayoutParams(new GridView.LayoutParams(95, 95));

imageView.setPadding(2, 2, 2, 2);

imageDownloader.download(url[position], imageView);

container.put(position, imageView);

}

else{

imageView = (ImageView)convertView;

}

 

//  Gridview 특징.

//  Gridview 화면에 표시되는 Grid 개체들은 ConverView null 하여 넘긴다

//  하지만 adapter getCount만큼 내부 개체들을 초기화 하기 때문에

//  실제로 내용은 없지만 ConvertView null 아닐 있다.  

 

//그러므로 이미지를 넣은 개체들은 컨테이너에 저장하고 

//이미지뷰를 넣지 않은 개체들은 ( 하지만 초기화 ) 새로 이미지뷰를 넣어준다.   

if( position < container.size() ){

if( (imageView = container.get(position)) == null ){

imageDownloader.download(url[position], imageView);

container.put(position, imageView);

}

}

else{

// 이곳이 문제.

imageView = new ImageView(parent.getContext());

imageView.setLayoutParams(new GridView.LayoutParams(95, 95));

imageView.setPadding(2, 2, 2, 2);

imageDownloader.download(url[position], imageView);

container.put(position, imageView);
 

 <수정안 1>

의도는 container 를 만들어, imageView가 생성될 시 저장하여 갱신시에 꺼내 쓰자는 것이다. 이것만으로 download 메소드 호출 횟수를 상당부분 줄일 수 있다. 의도와는 조금 다르게 이번에는 완전히 사용자 측면에서 속도만을 빠르게 수정한다면 어떻게 할 수 있을까? 




ImageView imageView;

if (convertView == null){

Log.d("DEBUG","position : "+position);

imageView = new ImageView(mContext);

imageView.setLayoutParams(new GridView.LayoutParams(95, 95));

//imageView.setAdjustViewBounds(false);

//imageView.setScaleType(ImageView.ScaleType.CENTER_CROP);

imageView.setPadding(2, 2, 2, 2);

}else{

imageView = (ImageView) convertView;

}

//if(position < container.size())

imageView.setImageBitmap(container.get(position));


return imageView;

 
 
<수정안 2>

위의 코드를 위해 생성자도 수정했다. 

 

private HashMap<Integer, Bitmap> container = new HashMap<Integer, Bitmap>();
...
 

public ImageAdapter(String url[], Context context) {


if (url != null) {

this.url = url;

}

this.mContext = context;

for( int i = 0 , size = url.length ; i < size ; i++  ){

//ImageView temp = new ImageView(context);

//temp.setLayoutParams(new GridView.LayoutParams(95, 95));

//temp.setPadding(2, 2, 2, 2);

//imageDownloader.download(url[i], temp );

container.put( i, imageDownloader.downloadBitmap(url[i]));

}

}

 
<수정안 2 - 생성자와 컨테이너>

한번 테스트해보길... 초기 로드 속도는 답답함을 금치 못하게 하지만 로딩이 끝나고 난 스크롤 속도나 이미지 표시 속도는 거의 딜레이가 없을 정도로 빠르다. 하지만 아직 문제가 남아있는데, imageDownloader는 비동기로 가끔 데이터를 받아올 수 없는 상황이 생긴다. 이게 수정안 1에서는 이미지의 갱신시마다 검증을 했기 때문에 별 문제될 일이 아니지만 수정안 2에서는 꽤 큰 문제가 된다. 하지만 속도는 최고이기 때문에 이 코드를 어떻게든 살리고 싶다. 

 그 방안은 차차 살펴봐야 할듯 --_--;



두 번째 문제 해결 방안은, 필자의 아이디어가 아니므로 코드를 설명하고 끝내기로 하겠다. 

 
//decodes image and scales it to reduce memory consumption
private Bitmap decodeFile(File f){
   
try {
       
//Decode image size
       
BitmapFactory.Options o = new BitmapFactory.Options();
        o
.inJustDecodeBounds = true;
       
BitmapFactory.decodeStream(new FileInputStream(f),null,o);

       
//The new size we want to scale to
       
final int REQUIRED_SIZE=70;

       
//Find the correct scale value. It should be the power of 2.
       
int width_tmp=o.outWidth, height_tmp=o.outHeight;
       
int scale=1;
       
while(true){
           
if(width_tmp/2<REQUIRED_SIZE || height_tmp/2<REQUIRED_SIZE)
               
break;
            width_tmp
/=2;
            height_tmp
/=2;
            scale
*=2;
       
}

       
//Decode with inSampleSize
       
BitmapFactory.Options o2 = new BitmapFactory.Options();
        o2
.inSampleSize=scale;
       
return BitmapFactory.decodeStream(new FileInputStream(f), null, o2);
   
} catch (FileNotFoundException e) {}
   
return null;
}

이는 구글링을 통해 StackOverflow사이트에서 찾은 소스코드이다. 
Bitmap을 리사이즈 하는 방법이 나와 있다. 

Bitmap 을 만들 때 option 사항을 줄 수 있는데, 
간단히 option의 inSampleSize 를 조정하는 것으로 사이즈를 조정할 수 있다. 하지만 위의 소스는 Bitmap의 원본 사이즈와 허용 사이즈를 비교해 스케일을 정하는 알고리즘이 포함되어 있어서 원본의 크기에 따른 스케일링이 가능하다. 


오늘도 문제 해결~~! '-^vv




긴 글 읽어주셔서 감사합니다. -fin



 
저작자 표시 비영리
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
Posted by 화박 화박
IT /IT 기술 관련2011/07/09 09:44

Robert P. Goldberg.  Gerald J. Popek 과 함께 가상화 기술을 연구한 선구자. 
원문 링크
 
Ver.대충

소개.

 한 컴퓨터 시스템 상의 다른 시스템에서 하는 완전한 인스트럭션 단위의 가상화는 익숙한 컴퓨팅 기술이다. 이를 소프트웨어 개발자들이 자주 이용하게 되는 때가 하드웨어 기반이 변경될 경우이다. 예를들어, 만약 프로그래머가 소프트웨어 개발을 어떤 특수한 의도로(aerospace같은) 개발할때 컴퓨터 X가 제작중이고 아직 가용하지 않을때, 그는 적당히 쓸만한 일반적인 머신G에서 시뮬레이터를 작서앟고자 할 것이다. 시뮬레이터는 상세한 시뮬레이션을 X의 환경에 특별히 맞춰 제공할 것이고, 이는 프로세서, 메모리, I/O 디바이스들을 포함한다. 있을 수 있는 타이밍 의존성을 제외하고, 프로그램이 "시뮬레이션된 머신 X"에서 돌아가면 후에 "진짜 머신 X"에서 ( 그게 최종 빌드 & 체크아웃 됐을때 )  돌아가는 것과 같은 효과를 준다. X에서 동작하는 프로그램들은 임의적일 수 있다 -  I/O 디바이스들을 시뮬레이트 하기 위한 코드, 시뮬레이트하는 메모리 상의 데이터 이동이나 시뮬레이트 되는 머신에서의 어떤 명령의 실행을 포함한다. 시뮬레이터는 소프트웨어 필터링 레이어를 제공하는데 이는 X 상의 프로그램들이 오동작 하는 것으로 부터 머신 G의 리소스를 보호한다. 

 만약 몇몇의 다른 프로그래머들이 동시에 X를 위한 소프트웨어를 개발한다면, 아마 G의 운영체제 하에 다수의 시뮬레이터가 동작해야 할 것 이다. 그렇지 않다면, 특수한, 더 강력한 버전의 개발되야 할 것이고 이는 다수의 사용자를 위해 스스로 타임-쉐어링 해야한다. 두 경우에, 결과물은 머신 G상의 하드웨어-소프트웨어 인터페이스로 존재하는 머신 X의 다량 카피본의 환영일 것이다. 
 머신 X와 G가 임의로 결정된다면, 상당히 다른 구조를 가지고 있을 것이다. 이것은 매우 큰 시뮬레이션 프로그램과 각 X의 명령들에 대한 시뮬레이션이란 추가 부담을 의미한다. 이런 이유로, 머신이 1000 to 1 (?) 만큼 느려지는 경우를 찾을 수 있다. 그래서 시뮬레이션은 소프트웨어 개발에 국한되어 사용되고 production mode(?)에는 거의 사용되지 않는다. 
 X와 G가 다르긴 하지만, 그들을 동일하게 선택이 가능하다. - 예., X=G. 이런 경우 우리는 하나의 머신 G에 많은 G의 하드웨어-소프트웨어 복제본을 지원해야 할 것이다. 각 사용자는 그들의 고유한 머신 G의 복사본을 갖고 그의 "고유한" 컴퓨터에 운영체제를 선택해 구동할 수 있다. 그는 또한 자신이 개발이나 디버그할 자신의 운영체제를 선택할 수 있다. 그 이전, 시뮬레이트된 G의 각 명령어들이 실제 G 상의 소프트웨어에 의해 인터프리트 되고 있고, 그렇기에 한 시뮬레이트되는 머신이 다른 머신들에 간섭할 방도가 없다.
 만약 실제와 시뮬레이트 되는 머신들이 동일하다면 그 때는 아마 성능 하락이 20 to 1 정도인 시뮬레이터를 만들 수 있을 것이다.* 이는 좀더 범용적인 시뮬레이터를에 고려될만한 성능향상 같지만, 프로그램이 네이티브 하드웨어처럼 동작한다는게 이상하게 여겨진다, i.e.,머신들이 이를 위해 설계되면, 모든 경우에 느려진다. 이런 경우에 대한 숙고는 그 자신의 다량의 복사본을 엄청나게 더 효율적으로 할 수 있는 시뮬레이터의 개발을 끌어냈다. 이런 시스템들에서, 소프트웨어 인터프리젠테이션 없이 시뮬레이트되는 머신을 의한 많은 소프트웨어들이 하드웨어에서 직접 실행된다. 이런 종류의 시스템을 가상 머신 시스템 ( Virtual Machine systems), 이라고 하고 시뮬레이트 되는 머신들을 가상 머신 ( Virtual Machines : VMs ), 그리고 시뮬레이터 소프트웨어를 가상 머신 모니터 ( Virtual Machine Monitor : VMM )라고 한다. 
  VMM을 구현하는 것은 대상 머신의 아키텍처에 달렸다. 그리고 가상 머신 모니터들이 생성되더라도 아직 성능과 사용에 관한 많은 흥미로운 의문들이 남아 있다.
 IBM의 System/370 을 위한 향상된 가상머신, 가상 머신 시스템의 어플리케이션의 데이터 보안/신뢰성은 중요한 문제가 있고, 가상 머신을 소프트웨어 개발 비용 절감을 위해 사용하는 테크닉은 단지 현재 가상 머신의 흥미로운 점들 중 가장 널리 퍼질 이유가 있었을 뿐이다.
 이 페이퍼에서 우리는 가상머신의 원리, 성능, 그리고 실현에 걸쳐 최근의 작업이슈들을 얘기하고자 한다. 부분적으로, 우리는 가상 머신의 이유, 새 아키턱처 디자인 상의 가상 머신의 영향에 대한 토론, 가상 머신 성능 비용에 대한 숙고, 그리고 마지막으로 가상 머신으로 가능한 유일할 몇 어플리케이션에 대한 탐구에 대한 조사를 했다. Buzen과 Gagliardi 의 지침서, Parmelee et al, 그리고 Meyer 와 Seawright, 챕터 1-3과 같은 박사 논문들을 읽는 것이 아마 추가적인 배경 지식이 되 줄 것이다. 마지막으로 Madnic과 Donovan에 의해 최근에 쓰여진 책은 운영체제 과정의 한 부분으로 가상머신을 훌륭히 소개하고 있다.  
 

Principles  - 원리

가상 머신 시스템은 곧 일반적인 모습으로 등장할 삼세대 아키텍처와 멀티프로그래밍 운영체제를 위해 개발되었다. - 예,OS/360. 이 시스템들의 고유한 아키텍처적 특징은 특권(privileged)와 비특권(non-privileged) 모드의 이중상태를 하드웨어 적 구현이 되겠다. 특권 모드에서 소프트웨어에겐 모든 인스트럭션이 가용하지만 비특권 모드에서는 그렇지 않다. 운영체제는 소규모의 특권모드 소프트웨어 nucleus라고 불리는 프로그램을 내재한다. 사용자 프로그램은 비특권의 하드웨어 인스트럭션의 수행이나 슈퍼바이저  콜을 -e.g., SVCs - 특권 명령을 수행하기 위해서 특권모드 소프트웨어 nucleus에게 요청한다. - e.g., I/O - 비특권 명령군과 슈퍼바이저 콜의 조합은 실질적으로 bare machine과 유사해 보이지만 같지 않은 extended machine(확장머신)임을 정의한다. 
 확장 머신은, 이론 상으로는, 더 휴먼-엔지니어적이고 원본 bare머신보다 프로그램이 용이하다. 

 확장 머신의 등장으로 많은 컴퓨터 시스템에의 설치가 매우 성공적이 되었지만, 이와 관련해서는 아직 많은 문제가 존지한다. 도면 1 에서는 다수의 확장 머신 인터페이스를 보여주고 있는데, 오직 하나의 bare-머신 인터페이스가 제공된다. 그런고로, 오직 하나의 특권 소프트웨어 nucleus가 한 시간대에 동작할 수 있다. 그 결과로, 다른 운영체제 시스템을 돌리 수가 없게 되었고, 이는 진단 프로그램 외에 확장 머신 인터페이스를 대신하는 bare-머신 인터페이스를 요구하는 어떤 소프트웨어 또한 포함한다. 이런 경직된 구조는 유저 소프트웨어의 이식성에( 다른 운영체제를 위해 쓰여진 ), 운영체제의 테스팅과 수정 ( 특권모드 소프트웨어 ), 그리고 테스트와 진단 프로그램들 ( T & D )에 중요한 영향을 미친다. 이런 문제에 직면했을때 설치의 관리는 보통 스케쥴링을 쉬프팅 함으로서 해결하고자 한다: 운영체제 시스템 디버깅, T&D, 사용할 수 없거나 릴리즈된지 오래된 운영체제 시스템, 그리고 일반적인 시스템을 하루의 ( 그리고 밤의 ) 시간을 나누어 스케쥴하는데 사용한다. 
 


 가상머신의 주된 혁신은 앞선 문제를 해결하고자 함이다. 가상 머신 시스템(VMs)의 핵심은 가상 머신 모니터(VMM)으로 이는 단독으로 존재하던 머신 인터페이스를 다수의 환영으로 변환시키는 것이다. 이 인터페이스들(가상머신들) 각각은 실제 컴퓨터 시스템을 대체할 만한 능력을 갖고, 모든 프로세서 인스트럭션을 완수할 수 있고(i.e., 특권 인스트럭션과 비특권 인스트럭션 모두 포함 ) 시스템 자원도 포함한다.(i.e., 메모리와 I/O 디바이스들). 각 운영체제를 그 자신들의 가상 머신에서 구동시키는 것으로 다수의 다른 운영체제 시스템에서 구동하는 효과를 얻을 수 있다.( 특권모드 소프트웨어 nuclei).
 
 아마 가장 널리 아는 가상 머신 시스템은 IBM의 VM/370일 것이다. 각 가상 370 에는 사용자가 System/360 이나 System/370을 선택할 수 있고, DOS/360, OS/VS1, OS/VS2 혹은 OS/360의 어떤 버전이든 구동할 수 있다. 사용자는 Conversational Monitor System(CMS) 를 구동할 수도 있고, 간단하게 단순프로그래밍 된 운영체제 시스템을 가상 머신을 이용해 개발할 수도 있다. 
 
 다른 가상 머신 시스템 개발 현황 ... ( 생략 )



 가상 머신과, 멀티프로그래밍, 가상 저장장치가 독립되는 컨셉이긴 하지만, 이들이 함게 조합된 형태를 갖춘다면 매우 강력할 것이다. 가상 머신은 컴퓨터 시스템의 환경을 형태를 따로 분리하여 유용함을 제공해준다. 멀티프로그래밍과 함께라면 하나의 하드웨어 시스템에서 다양한 다수의  가상머신이 가능하다. 마지막으로, 가상 저장장치까지 더해지면, 메모리 요구량이 실제 가용한 자원을 넘어서는 가상 머신도 가능할 수 있다. 

  가상 머신 의도의 힘에도 불구하고, 실제로는 제한된 수의 머신만이 구현되고 있다. 이런 상황은 삼세대 머신들이 가상 머신을 지원하지 않게 설계된 특징 때문이다. 그 결과, 이 시스템들은 적절한 아키텍처적 지원을 해주지 않아 VMM을 억지스러운 소프트웨어 테크닉이 되게 만들었다. 

 소개부에서 논했던 시뮬레이트된 머신과 마찬가지로 가상 머신은 믿을 수 있는 프로세서, 메모리, I/O 시스템 과 운영체제 콘솔까지의 복제품의 지원이 필요하다. 뿐만 아니라, 가상 머신 컨셉으로서 효율에 요구사항까지 만족시키켜야 하고, 가상 CPU에서의 인스트럭션들을 호스트 하드웨어에서 바로 실행시킬 수 있는 구조가 중요한 위치를 갖으며 필요하다. 가상 머신에서 동작하는 인스트럭션들이 머신의 모드를 수정하는 것으로 특권 인스트럭션까지 포함, I/O, etc... 하기 시작한 뒤로 가상 머신에서 VMM 혹은 다른 가상 머신들에서 간섭하여  제한함으로서 소프트웨어의 직접 실행을 완성할 수 있다. 이런 상황을 막기 위해서 VMM에는 실제 프로세서의 state를 포함 제어하고 유지하는 기능이 꼭 필요하다.

 Third-Generation Implementation Issues
앞서 다뤘던 문제를 해결하기 위한 삼세대 아키텍처는 비특권모드에서 동작하는 가상머신 소프트웨어들이 소프트웨어 테이블에 가상 모드 비트를 갖게 하는 것이다. 가상 모드 비트는 소프트웨어가 bare-머신에서 직접 실행시킬 것인지를 나타내는 상태 비트이다. 굳이 제어하지 않아도 되는 인스트럭션은 VMM으로의 상태 전환 없이 bare-머신에서 직접 실행될 것이다. 다른 인스트럭션들은 VMM에 의해 trap될 것이고 ( 디버거를 연상해보세요 ) 가상 모드 비트를 통해 각 케이스 별로 해야되는 동작들을 정의할 것이다. 
 
 일반적으로, 비-특권 인스트럭션군은 바로 실행하도록 하고, 특권 인스트럭션군은 trap 되고 시뮬레이트되야 할 것이다. 하지만, 이는 항상 이뤄질 수 없게 하는 몇몇의 프로세서 모드가 매핑되기도 전에 반응하는 특권이 아닌 인스트럭션 군이 있다. -i.e., 비특권모드에서 실행될 때는 자동으로 trap되지 않는다. 이런 이유로 이런 소불안전한 프트웨어 설계를 가지고는  가상머신 시스템을 지원하기가 불가능한 경우가 있다. 

 삼-세대 가상머신 시스템들에서, 가상머신들의 메모리는 시스템의 메모리를 매핑하여 사용하는 동작 구조를 사용한다. 가상 머신의 메모리는 실제 메모리의 속성을 간지해야 한다. 주소 영역 0 이나 인터럽트 컨트롤 위치들이 이에 속한다. 메모리 매핑은 현 시스템에서 단순한 리로케이션이나 페이징 둘이 사용된다. 만약 호스트 머신이 페이지된다면, 가상 머신도 페이징 메커니즘을 포함해야 할 것이다. 이런 경우, VMM은 페이지테이블을 조작하여 페이지되는 주소대역을 그들에 맞는 실제 주소로 맵해야 한다. 현재의 기술은 조금 불편하고 필요하지 않은 소프트웨어 오버해드가 있지만 최근의 향상이 이 문제들을 해결할 것이다. 

 I/O 인스트럭션 군이  대게 특권명령이 된 뒤로, 가상 머신의 소프트웨어에 의해 실되는 것은 VMM으로의 trap을 유발한다. 이런 관점에서 VMM은 디바이스나 메모리 주소들을 I/O 명령이 발행되기 전에 변환할 수 있는 가상머신의 장점이 있다. I/O 가 완료되는 인터럽트가 VMM으로 왔을때, 적합한 가상 머신에 반영될 것이다. I/O 명령들이 "비교적 저 주파수"와 함께 동작한 뒤로 VMM 소프트웨어 중재로 인한 성능 하락은 참을만해졌다. 현 컴퓨터 아키텍처들은 부적절하게 쓰여진 채널 프로그램이 다른 가상 머신이나 VMM 자신에게 형향을 미칠 수 있기 때문에 VMM 소프트웨어의 중재로 시스템의 무결성을 유지해야 한다. 이에 대한 부가 효과로 소프트웨어 중재는 한 디바이스의 요청을 위한 것에서 다른 것들을 위한 요청으로 I/O 를 맵하거나 실제로는 물려있지 않은 특별한 디바이들을 제공할 수 있게 됐다. 

 어떻게 가상머신 맵들을 다양한 시스템에 맞게 설계하고 그 맵핑을 머신들이 허용하는 토의는 문언에서 다룬다.최근의 공부에서는 삼-세대 가상 머신 지원을 위해 정형화된 수학적 기법까지 정확한 아키텍처적 상태를 수립하는데 사용되고 있다. 이 결과로 다수의 연구자들이 가상 머신들을 지원하기 위해 현재의 머신들을 수정하고 있다. 

Virtualizable Architectures






 





 
저작자 표시 비영리
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'IT  > IT 기술 관련' 카테고리의 다른 글

Survey of Virtual Machine Research - 번역 중  (0) 2011/07/09
Posted by 화박 화박