Offcanvas

How To / 데이터센터 / 클라우드

더 늦기 전에 클라우드로 옮겨야 할 17가지

2013.09.17 Andrew C. Oliver   |  InfoWorld
클라우드에 대한 담론이 넘쳐나지만, 여전히 많은 기업이 클라우드 혹은 SaaS의 사각지대에 놓여있다. 그래서 뒤늦게 허둥지둥 클라우드를 도입하는 이른바 '급격한 클라우드화'(emergency cloudification)의 덫에 걸려든다. 생각해보면 이미 우리는 심각한 상황이 닥치기 전 모든 것을 클라우드로 옮겨야 하는 시점에 도달했다. 미리 대비하지 않은 것을 후회하기 전에 이제라도 클라우드로 옮겨야 할 17가지 서비스를 정리해 보자.

1. 백업 : 데이터센터가 두 개거나, DR 센터가 멀리 떨어져 있어 둘 중 하나에 무슨 일이 생겨도 다른 하나가 멀쩡할 수 있는 상황이 아닌 이상, 전통적인 방식으로 '어딘가에' 백업을 해 두는 것만으로는 충분하지 않다.

100년 만에 처음이라는 폭풍이 북동부 지역을 강타하거나 강력한 지진이 동부 해안에 닥치는 상황이 오면 어떻게 될까? 여러분이 백업해 둔 자료는 지리적인 여건을 극복하고 초강력 토네이도나 허리케인으로부터 안전한가? 적어도 클라우드 백업은 안전할 것이다.

2. 팩스 : 21세기에 접어든 지 십여 년이 지난 지금까지도 팩스는 여전히 매우 훌륭하고 안전한 발명품이다. 아직도 많은 사람들이 팩스가 없는 회사는 회사도 아니라고 생각하기 때문에 팩스를 통한 커뮤니케이션이 필요하다. 그렇다고 해서 진짜 팩스 머신을 구매할 필요는 없다. 클라우드가 유명해지기 전부터, 아니 클라우드라는 용어가 생겨나기 전부터 팩스 서비스 대행업체들은 많았기 때문이다. 팩스 번호만 있으면 다른 사람이 팩스로 보낸 문서를 이메일로 받아볼 수 있다.

3. 교육 비디오 : 2주에 한 번, 금요일이면 필자 회사는 '금요일 교육'이라는 것을 실시한다. '더럼'(Durham)의 전 직원들이 한두 개의 방에 모여 시카고 지사와 함께 영상 회의를 통해 기술적인 주제로 이야기를 나눈다. 회의 중 음식도 제공되기 때문에 직원들은 이 시간을 몹시 기다린다('피자 좀 그만 먹자'는 말을 하는 사람들이 있어 지금은 주로 태국 음식을 제공한다). 미래의 희생자, 아니 직원들을 위해 회의 전 과정은 모두 녹화된다. 그리고 그 영상을 대용량 파일로 드롭박스에 올려 공유했다. 그런데 드롭박스는 효율성이 떨어졌고 지금은 유튜브에 필자 회사만의 채널을 올려 그곳에 공유하고 있다. 물론 이 글을 읽는 여러분은 볼 수 없다.

4. CRM : 점원이 한 명 이상인 사업장이라면 CRM을 자체 도입하기 부담스러울 것이다. 이런 경우를 위해 ‘세일스포스’ 같은 업체가 있는 것이고, 슈거CRM(SugarCRM) 같은 값싼 대안이 존재한다. 슈거CRM의 장점은 공짜 버전으로 CRM을 자체 도입하면 훗날 데이터 이전 문제없이 클라우드로 옮겨갈 수 있다는 것이다. 세일스포스도 '파닷'(Pardot)을 인수해 슈거CRM의 주변을 잠식해가고 있다.

5. 파일공유 : 필자의 구글 드라이브로 완전히 이주했다. 그렇지만 아직도 몇몇 이유 때문에 드롭박스를 완전히 버리진 못했다. 드롭박스는 값이 싸고 윈도우 공유(CIFS/SMB/Samba 등)나 미러링(mirroring)이 가능하기 때문이다. 심지어는 http 링크로 공유할 수도 있다. 아직도 드롭박스나 그와 비슷한 서비스를 이용해 보지 못한 사람이라면 정말 간첩이라고 생각할 수밖에 없다. 끊김 없이 사용 가능하고(몇 주 전 ‘30초의 변화’는 예외였지만), 믿을 수 있는 서비스다.

6. 리비전 컨트롤(revision control) : 개인 또는 공용 저장소가 필요하다면 깃허브(GitHub)나 빗버킷(Bitbucket)이 제격이다. 여러 개발자가 이들 서비스를 테스트했고 그 성능을 인정했다. 그동안 회사 자체 저장소 때문에 개발에 사용해야 할 소중한 시간을 얼마나 많이 낭비했던가.

7. 문제 탐지/프로젝트 관리 : 이 활동들에 사용할 수 있는 툴은 매우 다양하다. 그리고 (예를 들자면) 지라(JIRA)를 굳이 호스팅 할 이유가 없다.

8. HR 관리 : 휴가 요청이나 다른 HR 문제에서 이메일과 캘린더를 사용하는 것도 좋지만, 결국은 HR 관리 소프트웨어가 필요하게 된다. 엄청나게 규모가 피플소프트(Peoplesoft)를 운영하는 회사가 아닌 이상 이것들은 어렵지 않게 클라우드로 옮길 수 있다.

클라우드로 옮기기 전 신중하게 생각해야 할 것들
그렇지만 그중에는 손쉽게 클라우드로 옮길 수 없는 것도 있다. 더 많은 생각과 계획을 필요로 하는 것도 있는데 다음과 같은 것이 대표적이다. 그러나 이 역시 결국은 대안을 찾을 수 있고 찾아가고 있다.

9. 아이덴티티 : 우리는 구글로 옮겨갔다. NSA가 구글로 옮겨가 문제가 없었다면, 우리도 괜찮겠지라는 생각이었다. 이는 클라우드에 올인 하기 전 해야 할 중요한 일일 수도 있다. 여러분이 선택한 클라우드 서비스가 아이덴티티 제공업체와 협력해야 할지도 모르니 말이다.

10. 데이터베이스 : 스케일 동시 실행(concurrency), 신뢰성, 회복성, 기타 등등. 특히 몽고DB(MongoDB)나 H베이스(HBase) 같은 새로운 데이터베이스를 고려하고 있다면 더 그렇다. PaaS나 IaaS 업체에게 유틸리티로 구매할 수 있다.

11. 애플리케이션 서버 : 톰켓(Tomcat)이나 PHP, 노드(Node) 인프라스트럭처 설치, 관리를 좋아하는가? 웹스피어(WebSphere)의 시작을 기다리는 것이 좋은가? 기존의 복잡한 레거시 앱을 당장 클라우드로 옮기진 않겠지만, 적어도 삽질만 하는 일은 멈출 수 있을 것이다.

12. 텔레커뮤니케이션 : 왜 현장에 PBX가 있어야 할까? 비디오, 혹은 컨퍼런싱 도구는? 클라우드를 통해 이들 툴을 이용하면 관리 과정이 한결 편해질 것이다. 레거시 인프라 스트럭처의 규모가 큰 경우라면 이전에 조금 시간이 걸리긴 할 것이다.

13. 오피스 스위트(Office Suites) : 구글 독스처럼 간편한 파일 공유 및 협력 프로그램을 손쉽게 이용할 수 있다. 물론 단점도 있다. 그래픽이나 기타 요소들이 잘 호환되지 않고, 기능상의 차이도 분명히 존재한다. 그렇지만 그런 기능을 사용하지 않는 경우나, 그런 기능보다는 (충돌 없이 원활한) 협업 기능이 더 절실한 경우라면 이전의 효과는 확실할 것이다. 신생, 소규모 업체들에는 이전 과정에 일 년 이상의 기간이 소요될 수도 있다는 점도 고려가 필요한 점이다. 기억하자. 로마는 하루아침에 이뤄지지 않았다.

14. 부하 테스트 : 부하 테스트의 가치는 더욱 강조될 것이다. 솔직히 말해 기존의 대표적 부하 테스트 툴 머큐리(Mercury)는 많은 부분에서 아쉬움이 있는 것이 사실이다. 충분히 강력하고 커스텀 자유도도 높지만, 이를 이용해 테스트를 진행하기 위해서는 막대한 서버 자원이 필요하기 때문이다. 충분한 경험을 지닌 전문가가 부족한 것도 머큐리의 단점 중 하나다. 시장의 신흥 공급자들에 주목해보자.

15. 통합 연속성 : 이 영역의 최강자는 단연 젠킨스(Jenkins)다. 현재 이용하는 PaaS 제공업체가 아직도 이를 통합하고 있지 않더라도 머지 않아 변화가 있을 것이다. 클라우드비스(Cloudbees)는 젠킨스를 이미 수용했고 구글 앱 엔진(Google App Engine)은 클라우드비스와 파트너십을 체결했다. 따라서 필자라면 이를 '생각할 것도 없이 지금 당장' 카테고리에 넣을 것이다. 내부 CI를 클라우드로 옮길 순 있지만, 소스 관리(source control)와 애플리케이션 서버를 우선 클라우드로 옮기면 더 편할 것이다.

16. 위키 : 자체 위키(wiki)를 보유하면서 굳이 사서 고생할 필요가 없다. 그렇지만 주의해야 한다. 수많은 클라우드 기반 위키는 위키 파워유저 친화적이지 않고 그저 'WYSIWIG 에디터의 형편 없는 모조품'에 불과하기 때문이다. 절대 다른 사람 말만 듣고 (놀랍게도) 검색이 약점인 구글 독스에 위키를 옮기는 일은 없도록 하자.

17. CMS/웹사이트 : 한때 수백 만 달러를 들여 기업 프레젠스 사이트(presence site)를 만들려는 프로젝트에 참여한 적 있다. 장담컨대, 드루팔(Drupal)이나 플랫 CMS(flat CMS)에 당신의 아이디어보다는 마케팅 직원들이 수정한 내용이 올라가게 될 것이다. 그렇다고 해서 팀사이트(Teamsite) 같은 걸로 화내지 말자. 유저들은 어차피 이해하지 못할 것이고 거기에 열정을 쏟는다 한들 허무한 일이다. ‘클릭’과 ‘수정’(어도비 CQ 스타일이다)을 최대한 가까이 하자. editor@idg.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
Sponsored
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.