대부분의 다른 사람들과 마찬가지로 자신 또한 두 발을 내부 기반에 둔 상태에서 시선만 클라우드로 돌리고 있는 것은 아닌지 생각해보자. 점점 가치가 떨어지는 많은 하드웨어를 구매하는 대신, 필요할 때 필요한 부분에만 돈을 지불하는 서비스를 꿈꾸는 것은 유쾌하다. 
 
말만이 아닌 실제로 클라우드로 이전할 때를 대비해 어떤 일을 해야 할까?
 
가장 먼저 생각할 부분은 계약한 클라우드 개발업체의 서비스가 더 이상 필요없을 때 자유롭게 해당 서비스를 해지하고, 다른 서비스를 다시 이용할 수 있는가 하는 것이다. 
  
또한 융통성있게 확장할 수 있어야 하고, 클라우드 서비스를 바꿀 수 있어야 하고, 클라우드간 호환이 돼야 하고, 통상 어드레스를 바꿀 수 있어야 한다. 이와 함께 선택에 따라 클라우드에 코드를 배치할 수 있어야 하기 때문에 코드 선택권이 많아야 한다.
 
클라우드 이전 팁 1 : HTML/자바스크립트 지향 이전
 
현재 '크고 뚱뚱한' 클라이언트를 클라우드 환경으로 원격 접속할 수 있을지 모른다. 그러나 이상적인 방법과는 거리가 멀다. 심지어는 넷스케이프(Netscape)조차 브라우저가 주 클라이언트가 되는 미래를 예측한 바 있다. 태블릿, 울트라북, 스마트폰 등이 경쟁하고 있는 시대에 의지할 수 있는 것은 HTML/자바스크립트 뿐이다.
 
클라우드 이전 팁 2 : 표준 지향
 
아직도 IE6나 이 정도 플랫폼을 사용하고 있는가? 무수히 많은 디바이스의 시대기 때문에 HTML/CSS 같은 표준으로 이전하기 시작할 때다. 
 
물론 직원과 사용자들이 어찌됐든 과거보다는 나은 브라우저를 사용하도록 할 수도 있다. 그러나 웹 표준으로 이전하면, 미래에도 기술 혜택을 제대로 받을 수 있고, SAML, OAuth 같은 인터넷과 클라우드 친화적인 보안 기준을 도입할 수 있다.
 
클라우드 이전 팁 3 : 웹지향 SSO 기반 보안
 
아마 지금 당장은 서로 호환이 되지 않아 단절된 인증 시스템이나 액티브 디렉토리 케베로스(Active Directory Kerberos), NTLM(NT Lan Manager)을 쓰고 있을지 모른다. 그렇다면 지금이야말로 웹 기반의 SAML이나 OAuth로 옮겨갈 때다. 
 
이것이야말로 시스템 일체를 부채살같이 통합하는 방법이다. 이는 지점 별로 통합하는 방법이나 특정 개발업체에 의지하는 방법보다 나은 방법이다. 웹 표준 기반 인증을 도입하면 여러 클라우드 개발업체와의 호환성을 확보할 수 있다. 따라서 특정 클라우드 제공업체의 서비스가 맞지 않을 때 비교적 자유롭게 서비스 업체를 바꿀 수 있다.
 
클라우드 이전 팁 4 : SOA 추진
 
지금이야말로 SOA(Service Oriented Architecture) 전략을 추진할 단계다. 클라우드로 서비스를 이전할 수 있다면, 시스템은 더욱 강건해질 것이다. 
 
자사의 클라우드가 자사 만을 위해 특별한 무언가를 한다면, 예를 들어 포인트 투 포인트 경로를 생성한다면, 확장이나 이전에 있어 융통성을 잃어버리게 된다. SOA 전략은 뭔가 특별한 무언가가 필요할 경우에도 기반 전반에 걸친 트리클 다운을 방지하는 전략이다.
 
클라우드 이전 팁 5: REST(Representational State Transfer)/JSON(JQuery) 구현
 
웹 서비스(Web Service)로 이를 구현할 수 있다. 그러나 SOAP(Simple Object Access Protocol)로는 기대만큼의 상호운영성 수준을 절대 달성할 수 없다. 클라우드로 이전한다면 무언가를 계속 옮길 수 있어야 하고, JAX-XX, WS-XX 버전 종류와 애플리케이션에서 사용하고 있는 것을 걱정하지 말아야 한다. REST/JSON는 유비쿼터스 클라이언트 지원을 구현하는 방법이다.

클라우드 이전 팁 6 : 마이크로소프트 닷넷(.Net) 버리기
 
아직까지 버리지 않았다면 생각을 바꿀 때다. 묘하게도 노드닷JS(Node.js)든, 루비(Ruby)든, 자바(Java)든, 닷넷보다는 지원 수준이 훨씬 넓어지고, 비용은 절감된다. 심지어는 마이크로소프트 윈도우 애저(Azure) 또한 자바를 지원하지만, 닷넷은 (좋게 말해도) 지원하지 않는 경우가 많다. 실력있는 개발자라면 조금만 도움을 받아도 새로운 언어의 기초를 금방 익힐 수 있다.
 
클라우드 이전 팁 7 : 개발 방법 업그레이드
 
대부분의 기업들은 조악한 방법으로 소프트웨어를 개발한다. 이렇게 되면 애플리케이션이 취약해지기 마련이다. 방화벽 뒤에 숨으면 안전할 것이라고 판단하는 전략이야말로 보안에 위배된다. 또한 인재들에게 돈을 아끼는 계획은 어리석다. 그리고 서둘러 개발하면 재앙이라는 댓가가 따른다. 

해커 그룹인 어노니머스의 공격만 보더라도 대부분은 아주 복잡한 방법을 사용해 공격을 하는 것이 아니다. 사실 예방이 어렵지 않은 'SQL 주입'이라는 방법을 썼다. 코드를 쓸 때부터 방어를 생각해야 한다.
 
클라우드 이전 팁 8 : HTTPS 추구
 
우리 모두는 VPN을 사랑한다. 그러나 최대한의 적응성을 확보하기 위해서, 암호화만큼은 인터넷에서 발견할 수 있는 가장 뛰어난 방식을 적용해야 한다.
 
클라우드 이전 팁 9 : 자바 대신 WAR 파일
 
누구나 자바EE(JavaEE)의 ZIP 파일 20 계층을 좋아한다. 5초만에 코드를 컴파일 해, 3분만에 일괄 처리할 수 있다. 그러나 클라우드는 WAR 파일을 선호한다.  
 
물론 자바EE를 지원하는 개발업체도 있다. 그러나 WAR 파일을 이용해야 더 많은 융통성이 생긴다.
 
클라우드 이전 팁 10 : 퍼블릭 버전을 보유한 프라이빗 클라우드 배치
 
프라이빗 클라우드를 배치한다면, 퍼블릭 클라우드 경로 또한 반드시 마련해야 한다. 클라우드 파운드리(Cloud Foundry), 오픈시프트(OpenShift) 등의 장점은 '현지에 맞게 고려하면서 글로벌적으로 이전할 수 있다는 것'이다. 또한 변호사를 대동하고 클라우드를 도입하는 것이 좋다.
 
클라우드 이전 팁 11 : 단계별 이전
 
단시일에 클라우드로 이전할 수 없다. 중요성이 낮은 애플리케이션을 먼저 이전한 후, 방법을 찾고 결과를 지켜봐야 한다.
 
클라우드 이전 팁 12 : 철저한 조사
 
확장할 방법, 지원할 보안 기준, 제공할 SLA, 서비스 공급업체가 보유하고 있어야 말 할 보안 기능에 대해 조사해야 한다. 아이러니하게도, 클라우드로 이전할 경우, 정말 필요한 것은 그동안 해 왔거나 해 왔어야 한 것들이다.
 
예를 들어, 개발업체의 '주장'을 의혹의 눈초리로 봐야 한다. 만약 개발업체들이 자사의 솔루션은 마치 마술과 같은 솔루션이어서 이상한 비 HTTP 프로토콜 같은 것들은 걱정할 필요가 없다고 말한다면, 자동 확장 방법은 어떤지, 우리의 솔루션은 어떤 방법으로 연결할 것인지 질문을 던져야 한다. 
 
또한 표준을 원한다고 말해야 한다. 이들이 말하는 '비밀 소스' 같은 소프트웨어가 안전한지 이를 네트워크에 배치하길 정말 원하는지 고려해야 한다.
 
클라우드로의 이전은 일반적인 '이사'와 마찬가지다. 필요 없는 것들을 버리고, 새롭게 정리하는 것이다. 앞서 언급한 대로만 한다면, 다시는 부딪히고 싶지 않을 정도로 실망한 서비스 공급업체에 발목을 잡히지 않는다. editor@itworld.co.kr