Cloud Build? Build in Cloud?
Techs( younjin.jeong@gmail.com, 정윤진 )
이제는 대세라 부르기도 뭣하다. 작년 KT가 야심차게 기업의 사활을 걸었다며 아마존 클라우드 서비스와 같은 IaaS 를 목표로 뜀박질 하기 이전까지만 해도 국내에서의 클라우드는 그게 뭥미? 또는 그거 지금 필요 없삼 의 반응이 지배적이었다.
하지만 KT로 부터 촉발된 클라우드 사업 경쟁의 시작은, 올해 초부터 호스트웨이의 Flex Cloud 서비스를 필두로 SK 의 T Cloud, LG CNS Cloud 등 수많은 클라우드 플랫폼들이 등장하면서 바야흐로 춘추전국시대를 앞두고 있다. 하지만 2011년 중반 현재까지, 아마존의 클라우드에 필적할 만한 인프라스트럭쳐 클라우드는 국내에는 없어 보이며, 만약 아마존이 국내 시장에 등장한다면 ( 그럴일은 별로 없지만 ) 아마 다른 모든 클라우드들은 초라해 지지 않을까 생각한다.
이제는 아무도 이런 블로그에서 클라우드 하면 이 파이널 판타지 7의 클라우드를 떠올리지 않는다.
클라우드란건, 궁극적으로 서비스를 만들어서 제공해야 하는 입장에서는, 즉 아마존과 같은 클라우드를 서비스 하겠다 하고 퍼블릭 클라우드 사업에 뛰어들 기 위해서는 기술적으로 심각하게 고려되어야 하는 것들이 몇가지 있다.
요즈음 옥션의 광고에서 처럼, 당신이 고객이 되어 본다면 이러한 IaaS 클라우드 서비스에서 고객의 입장으로 클라우드를 사용할 때 고려할 것들은 다음과 같다.
이는, 내가 매번 내부 교육이나 PT에서 강조하는 클라우드의 가장 큰 특성인 "신축성"에 더하여, 퍼블릭 클라우드가 가져야 하는 최소한의 성능 및 요구조건을 이야기 한다. 위의 넷중 하나라도 제대로 동작하지 않는다면, 클라우드는 클라우드로서의 경제성/기능성을 잃게 되고, 고객은 떠날 것이다.
이러한 요구 조건들을 당최 어떻게 충족시킬 것인가?
다시 클라우드를 만드는 사람의 입장에서,
위의 몇가지에서 파생될 수 있는 수많은 가능성은 굳이 언급하지 않아도 골치 아파질 것이다. 이렇게 고려해야 할 것들이 많을진데, 우리나라 클라우드들은 조금 써보면 궁금해 지는 부분이 없지 않아 있다. 아직 상용화 하기엔 이른 부분들이 있어 보이고, 경쟁사를 인식해 너무 서두르는 감이 있지 않나 싶다.
클라우드는, 내부에서 실험적으로 사용하고자 할때 비용과 자원만 있다면 반나절만에도 구축 가능한 플랫폼이다. 하지만 이런 클라우드를 "고객이 사용해 보고 만족할 만한" 플랫폼으로 만드는 것은 수많은 전문 인력들이 수개월 동안 애자일과 같은 모든것이 공유되고 모든 코드가 내부에 공개된 고도의 협동조직이 만드는 것이 아니면 안된다. 전문화된 스토리지 엔지니어와 서버개발자, 백엔드와 프론트 엔드 개발자, 가상화 전문가 등 각 분야에 매우 전문적인 서로다른 인력들이 팀으로 조화되지 않는다면 사실 클라우드 만들기는 돈지랄 하는 소꿉장난이 될 수 밖에 없을 것이다.
우리나라의 기업 및 IT 조직 구조는 사실 이런 형태가 아닌 시스템 하는 사람 모임 시스템 팀, 개발해서 기능 추가하는 사람들의 모임 개발팀, 데이터베이스 관리하는 DBA팀 과 같이 같은 직무를 수행하는 사람들로 이루어 진 경우가 많이 있다. 이러한 구조는 기존의 구조를 "유지" 하는데는 좋을지 몰라도, 클라우드와 같은 "대주제" 를 소화하기에는 이미 너무 구시대적이며, 맞지 않는다. 조직은 기본적으로 다른 조직과 경쟁 할 수 밖에 없는데, 이러한 조직의 형태는 이미 경쟁이 될 수가 없다. 경쟁이 되지 않는데 경쟁을 붙여 놓으면 ( 고가평가) 당연히 싸움이 나고 프로젝트는 산으로 간다.
뭐, 조직내로 숨고 싶어하는 사람들이 많은 국내의 많은 직장인들은 사실 내가 노출되어 능력을 발휘해야 하는 포지션이 되는것이 두려운 분들이 많다는 것도 잘 알고 있다. 이런 분들은 나중에 OP 교육해서 원래 하던대로 하시도록 하고, 그런 성향이 아니며 충분히 능력이 있는 분들을 플랫폼 개발 일선으로 배합해야 하는 것도 매우 중요한 과제 되겠다. 글고 울나라는 아이비 리그 같은 좋은 학교 졸업하신 분들이 ( 꼭 언급된 특정 대학을 비난하고자 하는 의도는 없음 ) 이런 일 잘 할것으로 기대하는데, 사실 꼭 그렇지만은 않다. 이런 분들은 대개 더 높은 곳을 바라 볼 수밖에 없고, 비용이 굉장히 높을 수 밖에 없다. 뭐 그렇다 할 지라도 잘 만들어 주면 좋은데, 이게 또 그렇지 않은 경우가 대부분이랄까. 사실 이런 하이스펙의 인력으로 TF 를 채우는것은 상부로의 보고를 쉽게 만들고 프로젝트 실패를 "원래 할 수 없었던 것" 으로 만들기 위한 회피기동의 최우선 과제 일 뿐이다. 물론 다른 이유들이 더 있겠지만, 이런 부분들이 클라우드 완성을 위한 필요 요소가 되지 않음은 당연지사 일 것이다.
정리하면, 클라우드를 만드는 것은 매우 비용이 많이 들고, 인력의 관리 및 확보가 쉽지 않으며 경험있는 사람이 많지 않기 때문에 이 사람들에게 실패를 통해 기술을 축적할 시간을 주어야 하고, 이를 통한 대다수의 관리자들에가 충분한 교육이 될 수 있도록 하지 않으면 안될 것이다. 이런 과업을 수행하기 위해서 조직의 구조와 문화가 변경되어야 하고, 기존의 조직과는 분리가 되어야 하며, 그 인원의 충원에 있어서도 이전과는 다른 기준을 적용해야 한다. 이런 모든 것들 때문에 클라우드의 실현이 쉽지만은 않은 것이라 생각한다.
예전 Cloud Connect Event 에 갔을때 어떤 사람이 이런말을 했다.
"자동차가 처음 나왔을때, 많은 사람들은 자동차가 순식간에 말과 마차를 대체할 것이라고 생각했습니다. 하지만 당시의 사람들은 그저, 보다 조금 빠른 말과 마차를 원했을 뿐 입니다."
또는, 만약 전쟁사를 좋아한다면 베트남 전쟁시 미군이 최신무기인 미사일에 대한 무한 신뢰로 팬텀 전투기에서 기관포를 아예 제거해 버림으로서 조종사들에게 원성을 샀던 일화를 알고 있을 것이다.
이제, 클라우드를 이용하는 고객의 관점에서 생각해 보자. 클라우드는 이제 시작되었고 ( 물론 실리콘벨리에서는 5년 전 즈음에 시작되었다. ) 이 클라우드에 대한 이론적 사업모델과 실제 아마존/랙스페이스/고그리드 같은 기업들도 생겨났다. 또는 우리는 클라우드에요 라고 말하고 있지는 않지만 그 서비스 구성의 알려진 일부 모델이 클라우드 또는 어플리케이션 클러스터의 형태를 띄는 구글의 서비스, 또 막대한 데이터 양을 처리하는 Flickr 나 Twitter, Facebook 과 같은 서비스 모델들도 생겨났다. 이들은 모두 일종의 선구자들이고, 자동차 산업의 벤츠, 포르쉐, 페라리와 같은 존재들이다. 그들은 그와 같은 모델을 만들기 위해서 어떠한 부분에 가장 많은 자원을 투자했는지 조차 비밀에 부치며 그들의 경쟁력을 유지하고 있다.
하지만 그러한 비밀의 핵심 내용은 사실 간단하다. 현대의 웹 어플리케이션은 많은 부분에서 예전의 도스시절 C로 작성한 어플리케이션 보다 어플리케이션 자체로서의 비밀의 비중이 낮다. 이말은 쉽게 말하면 도스시절보다 현대의 웹세상이 프로그램 만들기가 보다 쉽다는 말이다. 여기에 전제를 달아야 하는것이 바로 '기능 구현 면에서는' 이 될 것이다. 그런데 도스 시절보다 어려워진 것이 웹 세상에 있는데, 웹 세상에 있는 사람들은 보통 이런 부분을 많이 생각하지 않는다. 적어도 국내에서는. 그 부분이 바로, '분산을 위한 어플리케이션 구조' 일 것이다. 다른말로 이런 아키텍처링은, 위에서 말한 모든 회사의 비밀의 핵심이다. 이러한 비밀이 풀리는 순간, 아류의 서비스는 순식간에 등장하여 경쟁력을 약화 시킬것이 분명하다. 하지만 아이러니하게도, 국내에서 이런 부분에 관심을 가지는 분들은 각 기업 연구소에 계신분들은 안계신 듯 하다. 사실 큰 관심도 없어 보인다. 그래서 벤처들이 좋은 기회를 맞이하는 부분도 있을 수 있겠지만, 역시 국내의 여러가지 환경에서 이런 부분에 대한 고려를 해 달라 라는것은 현실적으로 무리가 따르는 것도 사실 아닌가.
클라우드란건 이제 페이스북과 같은 서비스를 시작하려는 불특정다수의 사업가들과 또 이러한 사업가들에게 네트워크 대역폭과 컴퓨팅/스토리지를 판매하려는 일종의 기간사업가 양측 모두에게 매우 매력적인 플랫폼이라 인식되고 있다.
하지만, 난 이런 이야기를 하고 싶다. 서비스의 단위리소스, 즉 웹서버라던가 디비서버, 스토리지 등을 1로 만드는건 그 개발기간이 2로 만드는 것보다 짧고 쉽다. 2로 만드는것은 1로 만드는 것보다는 어렵지만, 3으로 만드는 것 보다는 쉽다. 하지만, 진정한 클라우드의 마법은 3으로 만들었을때 시작되며, 3으로 만들 수 있도록 고려된 서비스는 n 으로 확장 가능할 것이다. 이러한 기술적 또는 클라우드의 특성에 대한 고민 없이 클라우드에 기존 서비스를 그저 "올려" 만 놓는 형태의 클라우드 사용은, 페이스북을 꿈꾸는 당신의 사장님에게 좌절을 안겨다 줄 뿐이다.
뭔가 주제없는듯 글만 길어지는 듯 한데, 클라우드를 만들려고 하는 사람이던, 클라우드를 사용하려고 하는 사람이던 클라우드는 사람과 조직에게 그에대한 경험을 익힐 시간을 필요로 할 것이다. 이러한 시간에 충분히 마이그레이션, 어플리케이션의 구조에 대해 고민하지 않는다면, 클라우드의 사용은 오히려 당신의 조직에 관리하기 어려운 비용만 많이 나가는, 골칫덩이 시스템이 될 것임을 보장한다.
그리고 여담이지만, 기술 매니저가 반드시 그 조직 내에서 정리를 해야 할 사람이 있다면, 그건 클라우드와 가상화 이야기를 듣자마자 그 플랫폼에 오라클 RAC 를 구성하자고 떠드는 사람일 것이다.
세상은 브라우저를 중심으로 빠르게 발전하고 있다. 클라우드만큼 중요시 보아야 할 것들이 바로 모든 플랫폼에서 동작하는 브라우저의 발달이다. 결국 클라우드 - 브라우저 발달은 서로 불가분의 관계로 결합되어 있어, 웹의 어떠한 형태가 다수의 플랫폼에서 접근하는 서비스성이 있는 수많은 고객들이 브라우저의 형태로서 제품을 체험하게 될 것이고, 이러한 웹의 형태에 대해 이해를 하고 클라우드에 대해 이해를 하여 이 맞물리는 접점에 대한 설계에 대한 고민을 할 줄 아는 사람들이 모여야만 수많은 그야말로 수억의 데이터를 처리 할 수 있는 모델이 나타나게 될 것이다. 사실, 사업하는데 처음부터 이런 기술적 고려를 할 필요는 없다. 사업성과 고객유치가 우선이며, 이러한 것들이 충족되고 기획단계에서 이런 확장성에 대한 고려를 마일스톤에 넣기만 한다면 문제 될 것은 많지가 않다. 다만 내가 말하는건, 개념없이 요새같은 세상에 오라클 웹로직 때려박을 생각은 좀 자중하고, asp 코딩하는것도 좀 참아 주길 바랄 뿐이며, 웹에 종사하는 사람이면 적어도 CDN 과 NoSQL, Reddit 같은 것들만 조금 고려해 주면 된다는 말이다.
삼천포로 빠졌는데, 브라우저는 역시 중요하다. 그리고 각 플랫폼 별 공통으로 동작 가능한 어떠한 형태의 코드나 프레임웍들도 중요하다. 이런 기술들이 클라우드와 연계되는 것도 중요하다. 당신이 Comet 으로 설계된 백그라운드 트랜젝션 로직을 RESTful 하게 구현했으면, Jetty 같은 웹 서버를 클라우드에서 어떻게 돌려줄 것인가 하는것도 고민해야 한다는 말이다. 그렇기 때문에 서로다른 직군이 클라우드를 만드는 사람들 처럼 클라우드에서 돌릴 서비스를 만드는 사람들에게도 중요하게 되는 것이다.
글재주가 많이 없어져서, 전체 글을 관통하는 주제를 통일성있게 설명할 능력도 없는것 같다. 굳이 말하자면, 클라우드라는것은 모두에게 중요하고, 클라우드에서 돌릴만한 대용량 서비스를 만드는 부분이나 클라우드를 만드는 부분이나 이제는 새로운 형태의 협업을 요구하고 있다. 이러한 협업과 기술에 대한 이해없이는, 국내에서는 절대로 Amazon / Facebook 서비스가 나타 날 수 없을 것이다. 아류는 판 칠 수 있을지라도.
클라우드는 기업 경제/기술/문화 등 많은 측면에서 다룰만한 주제가 많은 핫 아이템이다. 모두 다 다룰 수는 없는 일이고, 그럴만한 글재주도 되지 않지만, 그 구현의 방법처럼 많은, 말 그대로 '구름처럼 많은' 무엇을 만들기 위해 또 그런 양의 데이터가 움직이는 세상에서 당신이 뭘 해야 할지는 생각해 볼 필요가 있지 않나, 싶다.
( younjin.jeong@gmail.com , 정윤진 )
이제는 대세라 부르기도 뭣하다. 작년 KT가 야심차게 기업의 사활을 걸었다며 아마존 클라우드 서비스와 같은 IaaS 를 목표로 뜀박질 하기 이전까지만 해도 국내에서의 클라우드는 그게 뭥미? 또는 그거 지금 필요 없삼 의 반응이 지배적이었다.
하지만 KT로 부터 촉발된 클라우드 사업 경쟁의 시작은, 올해 초부터 호스트웨이의 Flex Cloud 서비스를 필두로 SK 의 T Cloud, LG CNS Cloud 등 수많은 클라우드 플랫폼들이 등장하면서 바야흐로 춘추전국시대를 앞두고 있다. 하지만 2011년 중반 현재까지, 아마존의 클라우드에 필적할 만한 인프라스트럭쳐 클라우드는 국내에는 없어 보이며, 만약 아마존이 국내 시장에 등장한다면 ( 그럴일은 별로 없지만 ) 아마 다른 모든 클라우드들은 초라해 지지 않을까 생각한다.
예전의 클라우드사마
이제는 아무도 이런 블로그에서 클라우드 하면 이 파이널 판타지 7의 클라우드를 떠올리지 않는다.
클라우드란건, 궁극적으로 서비스를 만들어서 제공해야 하는 입장에서는, 즉 아마존과 같은 클라우드를 서비스 하겠다 하고 퍼블릭 클라우드 사업에 뛰어들 기 위해서는 기술적으로 심각하게 고려되어야 하는 것들이 몇가지 있다.
요즈음 옥션의 광고에서 처럼, 당신이 고객이 되어 본다면 이러한 IaaS 클라우드 서비스에서 고객의 입장으로 클라우드를 사용할 때 고려할 것들은 다음과 같다.
- 인스턴스의 생성/삭제가 허용할 만한 범위내의 시간에서 이루어지는가.
- 내가 원하는 경우 어떠한 형태로든 인스턴스의 데이터에 대한 백업이 가능한가.
- 내 인스턴스를 우리 서비스에 맞는 어플리케이션을 설정하고, 이를 템플릿화 하여 재사용이 가능한가.
- 내가 사용한 트래픽/프로세싱파워/스토리지 공간 등에 대한 과금이 정확하며 합리적인 것인가.
이는, 내가 매번 내부 교육이나 PT에서 강조하는 클라우드의 가장 큰 특성인 "신축성"에 더하여, 퍼블릭 클라우드가 가져야 하는 최소한의 성능 및 요구조건을 이야기 한다. 위의 넷중 하나라도 제대로 동작하지 않는다면, 클라우드는 클라우드로서의 경제성/기능성을 잃게 되고, 고객은 떠날 것이다.
이러한 요구 조건들을 당최 어떻게 충족시킬 것인가?
다시 클라우드를 만드는 사람의 입장에서,
- 고객 인스턴스의 충분한 사용성을 확보하기 위해서, 다음의 리소스에 대해 수많은 테스트와 적절한 플랫폼/아키텍쳐에 대한 고민이 필요하다.
- 스토리지 I/O 성능
- 네트워크 구조 및 구간별 대역폭
- 전체 시스템 내에서 고객 인스턴스들의 오케스트레이션
- 클러스터 노드들의 스펙
- 보다 쉬운 개발 및 관리를 위한 자동화 방법/구조 선택
- 효율적인 모니터링 시스템의 구현
- 사용자 계정별 적절하고도 비교적 정확한 과금방법 구현
- 경쟁사 대비 보다 저렴한 구축비용
- 고객 사용성과 서비스 제공에 대한 적절한 Trade off
위의 몇가지에서 파생될 수 있는 수많은 가능성은 굳이 언급하지 않아도 골치 아파질 것이다. 이렇게 고려해야 할 것들이 많을진데, 우리나라 클라우드들은 조금 써보면 궁금해 지는 부분이 없지 않아 있다. 아직 상용화 하기엔 이른 부분들이 있어 보이고, 경쟁사를 인식해 너무 서두르는 감이 있지 않나 싶다.
클라우드는, 내부에서 실험적으로 사용하고자 할때 비용과 자원만 있다면 반나절만에도 구축 가능한 플랫폼이다. 하지만 이런 클라우드를 "고객이 사용해 보고 만족할 만한" 플랫폼으로 만드는 것은 수많은 전문 인력들이 수개월 동안 애자일과 같은 모든것이 공유되고 모든 코드가 내부에 공개된 고도의 협동조직이 만드는 것이 아니면 안된다. 전문화된 스토리지 엔지니어와 서버개발자, 백엔드와 프론트 엔드 개발자, 가상화 전문가 등 각 분야에 매우 전문적인 서로다른 인력들이 팀으로 조화되지 않는다면 사실 클라우드 만들기는 돈지랄 하는 소꿉장난이 될 수 밖에 없을 것이다.
우리나라의 기업 및 IT 조직 구조는 사실 이런 형태가 아닌 시스템 하는 사람 모임 시스템 팀, 개발해서 기능 추가하는 사람들의 모임 개발팀, 데이터베이스 관리하는 DBA팀 과 같이 같은 직무를 수행하는 사람들로 이루어 진 경우가 많이 있다. 이러한 구조는 기존의 구조를 "유지" 하는데는 좋을지 몰라도, 클라우드와 같은 "대주제" 를 소화하기에는 이미 너무 구시대적이며, 맞지 않는다. 조직은 기본적으로 다른 조직과 경쟁 할 수 밖에 없는데, 이러한 조직의 형태는 이미 경쟁이 될 수가 없다. 경쟁이 되지 않는데 경쟁을 붙여 놓으면 ( 고가평가) 당연히 싸움이 나고 프로젝트는 산으로 간다.
뭐, 조직내로 숨고 싶어하는 사람들이 많은 국내의 많은 직장인들은 사실 내가 노출되어 능력을 발휘해야 하는 포지션이 되는것이 두려운 분들이 많다는 것도 잘 알고 있다. 이런 분들은 나중에 OP 교육해서 원래 하던대로 하시도록 하고, 그런 성향이 아니며 충분히 능력이 있는 분들을 플랫폼 개발 일선으로 배합해야 하는 것도 매우 중요한 과제 되겠다. 글고 울나라는 아이비 리그 같은 좋은 학교 졸업하신 분들이 ( 꼭 언급된 특정 대학을 비난하고자 하는 의도는 없음 ) 이런 일 잘 할것으로 기대하는데, 사실 꼭 그렇지만은 않다. 이런 분들은 대개 더 높은 곳을 바라 볼 수밖에 없고, 비용이 굉장히 높을 수 밖에 없다. 뭐 그렇다 할 지라도 잘 만들어 주면 좋은데, 이게 또 그렇지 않은 경우가 대부분이랄까. 사실 이런 하이스펙의 인력으로 TF 를 채우는것은 상부로의 보고를 쉽게 만들고 프로젝트 실패를 "원래 할 수 없었던 것" 으로 만들기 위한 회피기동의 최우선 과제 일 뿐이다. 물론 다른 이유들이 더 있겠지만, 이런 부분들이 클라우드 완성을 위한 필요 요소가 되지 않음은 당연지사 일 것이다.
정리하면, 클라우드를 만드는 것은 매우 비용이 많이 들고, 인력의 관리 및 확보가 쉽지 않으며 경험있는 사람이 많지 않기 때문에 이 사람들에게 실패를 통해 기술을 축적할 시간을 주어야 하고, 이를 통한 대다수의 관리자들에가 충분한 교육이 될 수 있도록 하지 않으면 안될 것이다. 이런 과업을 수행하기 위해서 조직의 구조와 문화가 변경되어야 하고, 기존의 조직과는 분리가 되어야 하며, 그 인원의 충원에 있어서도 이전과는 다른 기준을 적용해야 한다. 이런 모든 것들 때문에 클라우드의 실현이 쉽지만은 않은 것이라 생각한다.
예전 Cloud Connect Event 에 갔을때 어떤 사람이 이런말을 했다.
"자동차가 처음 나왔을때, 많은 사람들은 자동차가 순식간에 말과 마차를 대체할 것이라고 생각했습니다. 하지만 당시의 사람들은 그저, 보다 조금 빠른 말과 마차를 원했을 뿐 입니다."
또는, 만약 전쟁사를 좋아한다면 베트남 전쟁시 미군이 최신무기인 미사일에 대한 무한 신뢰로 팬텀 전투기에서 기관포를 아예 제거해 버림으로서 조종사들에게 원성을 샀던 일화를 알고 있을 것이다.
이제, 클라우드를 이용하는 고객의 관점에서 생각해 보자. 클라우드는 이제 시작되었고 ( 물론 실리콘벨리에서는 5년 전 즈음에 시작되었다. ) 이 클라우드에 대한 이론적 사업모델과 실제 아마존/랙스페이스/고그리드 같은 기업들도 생겨났다. 또는 우리는 클라우드에요 라고 말하고 있지는 않지만 그 서비스 구성의 알려진 일부 모델이 클라우드 또는 어플리케이션 클러스터의 형태를 띄는 구글의 서비스, 또 막대한 데이터 양을 처리하는 Flickr 나 Twitter, Facebook 과 같은 서비스 모델들도 생겨났다. 이들은 모두 일종의 선구자들이고, 자동차 산업의 벤츠, 포르쉐, 페라리와 같은 존재들이다. 그들은 그와 같은 모델을 만들기 위해서 어떠한 부분에 가장 많은 자원을 투자했는지 조차 비밀에 부치며 그들의 경쟁력을 유지하고 있다.
하지만 그러한 비밀의 핵심 내용은 사실 간단하다. 현대의 웹 어플리케이션은 많은 부분에서 예전의 도스시절 C로 작성한 어플리케이션 보다 어플리케이션 자체로서의 비밀의 비중이 낮다. 이말은 쉽게 말하면 도스시절보다 현대의 웹세상이 프로그램 만들기가 보다 쉽다는 말이다. 여기에 전제를 달아야 하는것이 바로 '기능 구현 면에서는' 이 될 것이다. 그런데 도스 시절보다 어려워진 것이 웹 세상에 있는데, 웹 세상에 있는 사람들은 보통 이런 부분을 많이 생각하지 않는다. 적어도 국내에서는. 그 부분이 바로, '분산을 위한 어플리케이션 구조' 일 것이다. 다른말로 이런 아키텍처링은, 위에서 말한 모든 회사의 비밀의 핵심이다. 이러한 비밀이 풀리는 순간, 아류의 서비스는 순식간에 등장하여 경쟁력을 약화 시킬것이 분명하다. 하지만 아이러니하게도, 국내에서 이런 부분에 관심을 가지는 분들은 각 기업 연구소에 계신분들은 안계신 듯 하다. 사실 큰 관심도 없어 보인다. 그래서 벤처들이 좋은 기회를 맞이하는 부분도 있을 수 있겠지만, 역시 국내의 여러가지 환경에서 이런 부분에 대한 고려를 해 달라 라는것은 현실적으로 무리가 따르는 것도 사실 아닌가.
클라우드란건 이제 페이스북과 같은 서비스를 시작하려는 불특정다수의 사업가들과 또 이러한 사업가들에게 네트워크 대역폭과 컴퓨팅/스토리지를 판매하려는 일종의 기간사업가 양측 모두에게 매우 매력적인 플랫폼이라 인식되고 있다.
하지만, 난 이런 이야기를 하고 싶다. 서비스의 단위리소스, 즉 웹서버라던가 디비서버, 스토리지 등을 1로 만드는건 그 개발기간이 2로 만드는 것보다 짧고 쉽다. 2로 만드는것은 1로 만드는 것보다는 어렵지만, 3으로 만드는 것 보다는 쉽다. 하지만, 진정한 클라우드의 마법은 3으로 만들었을때 시작되며, 3으로 만들 수 있도록 고려된 서비스는 n 으로 확장 가능할 것이다. 이러한 기술적 또는 클라우드의 특성에 대한 고민 없이 클라우드에 기존 서비스를 그저 "올려" 만 놓는 형태의 클라우드 사용은, 페이스북을 꿈꾸는 당신의 사장님에게 좌절을 안겨다 줄 뿐이다.
뭔가 주제없는듯 글만 길어지는 듯 한데, 클라우드를 만들려고 하는 사람이던, 클라우드를 사용하려고 하는 사람이던 클라우드는 사람과 조직에게 그에대한 경험을 익힐 시간을 필요로 할 것이다. 이러한 시간에 충분히 마이그레이션, 어플리케이션의 구조에 대해 고민하지 않는다면, 클라우드의 사용은 오히려 당신의 조직에 관리하기 어려운 비용만 많이 나가는, 골칫덩이 시스템이 될 것임을 보장한다.
그리고 여담이지만, 기술 매니저가 반드시 그 조직 내에서 정리를 해야 할 사람이 있다면, 그건 클라우드와 가상화 이야기를 듣자마자 그 플랫폼에 오라클 RAC 를 구성하자고 떠드는 사람일 것이다.
세상은 브라우저를 중심으로 빠르게 발전하고 있다. 클라우드만큼 중요시 보아야 할 것들이 바로 모든 플랫폼에서 동작하는 브라우저의 발달이다. 결국 클라우드 - 브라우저 발달은 서로 불가분의 관계로 결합되어 있어, 웹의 어떠한 형태가 다수의 플랫폼에서 접근하는 서비스성이 있는 수많은 고객들이 브라우저의 형태로서 제품을 체험하게 될 것이고, 이러한 웹의 형태에 대해 이해를 하고 클라우드에 대해 이해를 하여 이 맞물리는 접점에 대한 설계에 대한 고민을 할 줄 아는 사람들이 모여야만 수많은 그야말로 수억의 데이터를 처리 할 수 있는 모델이 나타나게 될 것이다. 사실, 사업하는데 처음부터 이런 기술적 고려를 할 필요는 없다. 사업성과 고객유치가 우선이며, 이러한 것들이 충족되고 기획단계에서 이런 확장성에 대한 고려를 마일스톤에 넣기만 한다면 문제 될 것은 많지가 않다. 다만 내가 말하는건, 개념없이 요새같은 세상에 오라클 웹로직 때려박을 생각은 좀 자중하고, asp 코딩하는것도 좀 참아 주길 바랄 뿐이며, 웹에 종사하는 사람이면 적어도 CDN 과 NoSQL, Reddit 같은 것들만 조금 고려해 주면 된다는 말이다.
삼천포로 빠졌는데, 브라우저는 역시 중요하다. 그리고 각 플랫폼 별 공통으로 동작 가능한 어떠한 형태의 코드나 프레임웍들도 중요하다. 이런 기술들이 클라우드와 연계되는 것도 중요하다. 당신이 Comet 으로 설계된 백그라운드 트랜젝션 로직을 RESTful 하게 구현했으면, Jetty 같은 웹 서버를 클라우드에서 어떻게 돌려줄 것인가 하는것도 고민해야 한다는 말이다. 그렇기 때문에 서로다른 직군이 클라우드를 만드는 사람들 처럼 클라우드에서 돌릴 서비스를 만드는 사람들에게도 중요하게 되는 것이다.
글재주가 많이 없어져서, 전체 글을 관통하는 주제를 통일성있게 설명할 능력도 없는것 같다. 굳이 말하자면, 클라우드라는것은 모두에게 중요하고, 클라우드에서 돌릴만한 대용량 서비스를 만드는 부분이나 클라우드를 만드는 부분이나 이제는 새로운 형태의 협업을 요구하고 있다. 이러한 협업과 기술에 대한 이해없이는, 국내에서는 절대로 Amazon / Facebook 서비스가 나타 날 수 없을 것이다. 아류는 판 칠 수 있을지라도.
클라우드는 기업 경제/기술/문화 등 많은 측면에서 다룰만한 주제가 많은 핫 아이템이다. 모두 다 다룰 수는 없는 일이고, 그럴만한 글재주도 되지 않지만, 그 구현의 방법처럼 많은, 말 그대로 '구름처럼 많은' 무엇을 만들기 위해 또 그런 양의 데이터가 움직이는 세상에서 당신이 뭘 해야 할지는 생각해 볼 필요가 있지 않나, 싶다.
몰래_똥싸는_IT인.jpg
( younjin.jeong@gmail.com , 정윤진 )
