디지털 Transformation, 데이터센터 & Cloud, 베트남

SaaS 서비스를 개발하고 싶은데 어떻게 하면 되는지에 대한 질문을 받는 경우가 많습니다.

SaaS 애플리케이션을 개발하고 싶은데, SOA로 개발하면 되죠?
웹서비스로 개발하면 되죠?
SaaS가 SOA하고 같은 거죠?
프로토콜은 SOAP을 쓰면 되는 건가요?

SaaS와 SOA의 관계를 이해하기 위해 두 가지 유형의 서비스를 살펴보겠습니다.

애플리케이션 서비스
 - 서비스 제공자가 제공하는 서비스를 인터넷을 통해 이용하고, 이 서비스는 비즈니스 로직을 제공합니다. 
   이런  유형의 서비스는 대부분의 차별화 되어 있지 않고, Commodity 인 경우가 많습니다.
   . 이메일, 회계, 세무, 인사 & 성과, 급여, CRM 등
 
   규모의 경제를 통해 저렴한 가격으로 Commodity 서비스를 제공 합니다. 해당 서비스를 사용하는 회사가 
   데이터의 생성 및 소유권을 갖게 됩니다. 각 회사의 서비스별로 큰 차별점이 많지 않기 때문에 동일한 서비스를
   제공하는 회사가 일반적으로 많고, 시장에서 경쟁이 치열합니다. 따라서, 메타데이터를 통한 각 회사별 설정 및
   멀티태넌트 특징 등이 요구됩니다. 일반적인 SaaS가 바로 이 영역 이라고 할 수 있죠.

정보 제공 서비스
 - 회사가 보유한 지적 재산권, 유용한 정보를 표준 인터페이스를 통해 고객에게 제공하는 서비스 입니다. 
    해당 정보는 서비스 제공자의 소유이고, 사용권한이 라이선스화 되어 있습니다. 
   . Netcraft, MediaMetrix, UPS(상품 배송 상태), FedEx(상품 배송 상태), Reuters, Gartner, Forrester 등

   고객의 필요에 따라 위의 회사의 정보를 구독하게 됩니다. 해당 정보를 직접 조사하는 것보다 서비스로 구독하는
   것이 훨씬 효율적일 것 입니다.

애플리케이션 서비스은 특정 업무를 서비스 제공자가 제공하는 소프트웨어를 인터넷을 통해 서비스로 제공받는 것이고, 정보 제공 서비스는 지적 재산권 정보를 제공 받는 것 입니다. 이 두가지 서비스 모두 SaaS 서비스라고 할 수 있겠죠.

자, 그럼 이제 SOA를 살펴보겠습니다. SOA는 아키텍처 스타일이고, SaaS는 하나의 비즈니스 모델 입니다.

SOA는 보유하고 있는 서비스들의 조합을 통해 새로운 소프트웨어 시스템을 신속하게 만들수 있도록 해주는 아키텍처 스타일입니다. SOA는 위의 애플리케이션 서비스, 정보 제공 서비스를 개발하는데 모두 적용될 수 있습니다.  SaaS를 개발하는데 있어 SOA가 반드시 적용되어야 할 필요는 없지만, SOA는 SaaS 서비스를 만들고 운영하는 것을 최적화 하는데 유용 합니다. 전자세금계산서를 웹을 통해 처리하도록 하는 것은 SaaS이고, 세금계산 애플리케이션을 국세청의 시스템과 연계하여 처리하는 것에는 SOA를 적용하여 개발될 수 있다는 것이죠.

즉, SaaS 서비스를 개발하는데 있어 SOA가 반드시 필요한 것은 아니지만, SOA 아키텍처를 이용하면 다른 시스템과의 연동이 쉬워지기 때문에 유용하게 적용될 수 있다는 것입니다.
그렇기 때문에 앞의 질문에 대한 답이 될 수 있을 것 같습니다.

추가 질문은 올려주시면 답변 드리도록 하겠습니다.

Hanu Kommalapati의 블로그 내용을 인용하였습니다.

블로터닷넷 도안구 기자님이 아래와 같이 써 주셨습니다.

http://bloter.net/archives/7561

신현석 한국마이크로소프트 개발자와 플랫폼 사업총괄 부장은 “아마존의 아마존 웹서비스(Amazon Web Service)가 대표적이며 마이크로소프트의 버추얼어스를 부동산 정보와 결합해 제공하는 메시업, 다음커뮤니케이션과 NHN이 진행하고 있는 메시업, 오픈마루의 다양한 서비스 시도들이 WOA의 초기 모델이라고 볼 수 있습니다”라고 밝혔다.

야후의 교통정보라는 서비스를 마이크로소프트의 버추얼어스나 구글어스와 결합하거나 부동산 전문 업체들이 전세계 지도 서비스 업체들의 인프라를 활용해 3차원적인 정보 서비스를 별도로 만들어 내면서 이전과는 전혀 다른 서비스들이 속속 출현하고 있다. 이런 서비스를 제공하기 위해 자사의 서비스 아키텍처를 좀더 유연하게 만들어 내는 것이 WOA이다.

그렇다면 왜 WOA가 주목을 받을까?

신현석 부장은 “웹이 하나의 플랫폼이 됐기 때문입니다”라고 설명한다. 수 많은 웹 서비스 업체들은 자신들의 서비스를 네티즌들에게 제공하고 있지만 이와는 별개로 수많은 개발자들이 웹서비스 업체의 인프라를 활용해 또 다른 서비스를 만들어 낼 수 있도록 돕고 있다. 이런 서비스 인프라를 만들어 제공하지 않으면 경쟁 업체들이 선점하면서 생태계를 이끌어가기 때문에 웹서비스 업체들이 주목을 하고 있다.

그렇다고 해서 웹서비스 업체들만 관심을 가지는 것은 아니다. 일반 기업들도 인터넷뱅킹 서비스와 같은 다양한 인터넷 서비스를 제공하고 있는데 이런 사이트 구축을 할 때 WOA 형태로 진행할 수 있다. 다만 그동안 기업 내부적으로 SOA의 표준들이 다양하게 사용돼 왔기 때문에 웹 서비스 분야에서도 SOA 표준 중 하나인 SOAP를 사용할지 아니면 WOA의 REST를 사용할지의 선택을 해야 한다. 일장일단이 있기 때문에 어떤 아키텍처로 가져갈지에 대한 다각도의 검토 작업이 필수적이다.

공공 기관들의 경우, 통계정보나 지리정보, 기상정보 등 원천 데이터들을 보유하고 있고, 지속적으로 이를 담는 그릇을 서비스 형태로 만들어가기 위해 노력하고 있는만큼 WOA를 검토할 필요성은 기업이나 웹서비스 업체에 뒤쳐지지 않을 것으로 보인다.

신현석 부장은 “WOA가 SOA를 모두 대체할 수 있다고 보지는 않습니다. 어떤 서비스를 제공하기 위해 최적의 아키텍처는 무엇인지 검토가 필요한 상황이죠”라고 전하고 “SOA가 소개된지 오래됐지만 꾸준히 변화하고 있듯이 이제 막 소개되고 있는 WOA도 적용 가능한 분야를 찾아 진화, 진보해 나갈 것으로 봅니다”라고 밝혔다.

2008년 10월 15일자 디지털타임즈에 위와 같은 제목의 기사가 게재되었습니다.
그 내용 중 제가 밝힌 내용도 나와서 참고로 올려 놓습니다.
http://www.dt.co.kr/contents.html?article_no=2008101602010560744002

SOA의 ROI에 의문이 제기 되고 있다.

"이런 가운데 기존 SOA의 단점을 보완하기 위한 대안찾기 움직임도 활발하다. 웹지향아키텍처(WOA)가 바로 그것으로 `단순함'이라는 웹의 근본적 장점을 충분히 살려 부동산 회사가 외부 지도정보 위에 매물정보를 함께 보여주는 등 기존의 웹 서비스를 차용해 빠르게 새로운 서비스를 개발하는 개념이다.

신현석 한국MS 개발자플랫폼 사업총괄 부장은 "WOA를 SOA와 같은 형태로 기업 환경에 적용하기 위해서는 데이터 암호화나 서비스 단위의 재사용 등 해결해야 할 기술적 과제가 아직 많이 남아있다"며 "그러나 일반 소비자 대상 서비스 영역에서 SOA의 단점을 보완해 활용할 수 있는 가능성은 충분할 것"이라고 말했다."

제일 중요한 것은 "고객이 얼마나 Benefit, 즉 혜택을 느낄 수 있는가" 라고 생각합니다. 그것이 SOA를 기반으로 개발되었든, 아니면 전통적 개발 방식으로 개발되었든 최종 사용자는 차이를 느끼기 어렵기 때문입니다. 그렇다면 비즈니스적으로 비용, 시간 등의 가시적인 효과가 없다면 무슨 이유로? 이런 질문을 해보게 됩니다.

SOA에 대하여 수년간 이야기되고 있고, 아직도 IT의 주요한 Trend 라고 이야기 합니다. 많은 기업들이 SOA를 구현하는 프로젝트를 수행했고, 지금도 진행하고 있습니다. 그렇지만 성공한 프로젝트는 그렇게 많지 않은 것 같습니다. 왜 그럴까요? SOA가 잘못된 개념일까요? 그렇지 않죠. SOA는 훌륭한 개념입니다.

잘 적용된다면 이라는 가정이 필수적이죠. 잘 적용됐을 때의 이점은 분명합니다.
서비스의 재사용으로 인해 비용 절감, 빠른 시장 진입, 비즈니스 유연성 등을 보장 받을 수 있죠.
문제는 개념이 아니라 실행입니다.
비즈니스 부서에서 시작되어야 하는데, IT 부서가 SOA를 Drive하는 형태로 진행된다면 정말 성공하기 어려울 겁니다. 투입되는 막대한 예산에 대한 ROI를 얻기가 정말 어렵죠.

조금 더 구체적으로 설명해보면 SOA 디자인의 핵심은 독특한 비즈니스 기능을 수행하는 서비스를 재활용 가능하도록 만드는 것이었습니다. 웹서비스를 만드는데 기본 프로토콜은 SOAP을 사용했고, WSDL, UDDI 등의 기본적인 표준이 포함됐고 기타 플랫폼과의 상호운영성을 위해 XML 스키마를 이용하여 개발되는 등 복잡하고 어려운 단점이 있습니다. 이에 반해 오늘 설명할 WOA(Web Oriented Architecture)는 데이터에 초점이 맞춰져 있습니다.
또한, 검증된 기술, 바로 WWW을 이루는 HTTP 프로토콜을 그대로 사용하고, SOAP보다 간단한 REST(Representational State Transfer) 프로토콜을 사용하여 URI(Uniform Resource Identifier) 형태로 참조되면서 웹서비스를 구현할 수 있습니다.

이렇게 말하면 WOA가 SOA를 대체하는 개념인가? 하고 궁금하실 겁니다. 그렇지는 않고 상호 보완 관계로 이해하시면 될 것 같습니다. SOA가 사용하는 SOAP, WSDL, UDDI 는 처음에는 스펙이 단순했지만 약 8년간 지나오면서 지원해야 하는 스펙이 타 기술과의 경쟁, 비준 등의 이유로 50개 이상으로 확대 되었습니다. 따라서, 이런 복잡한 방식말고 그냥 쉽게 웹서비스를 가져다가 쓰고 싶은 욕구가 당연히 생기겠죠? 그때 사용한 프로토콜이 바로 REST 입니다. 간단한 것이 대중화가 훨씬 쉬운 법이죠. 아마존의 웹서비스, AWS 중 S3 (Simple Storage Service), EC2(Elastic Cloud Computing) 역시 REST/WOA 방식으로 서비스 되고 있습니다. 처음 개발자들에게 SOA/SOAP, WOA/REST 방식을 선택해서 쓰라고 해봤더니 85%가 WOA/REST 방식을 선택하였기에 해당 서비스가 WOA/REST 방식으로 이루어지고 있는 거죠. 마이크로소프트도 역시 REST 방식의 프로토콜을 이용한 WOA를 지원하는데, .NET Framework 3.0 SP1에서 제공하는 WCF 서비스, ADO.NET 서비스, SQL Server Data Services 등도 모두 이 예에 속합니다.

이렇게 설명하면 WOA가 새로운 기술이라고 생각하시나요? 그렇게 보지 마시고, 기존에 모두 있던 기술, 즉 "REST, HTTP 프로토콜을 활용해 웹서비스를 생성한 것"이라고 이해하시면 되는데, 여기에 이름을 붙였다라고 보시면 될 것 같네요.

자, 이제 그럼 WOA가 어디에 쓰이고, 왜 많이 쓰일까 좀 살펴봐야겠죠. 웹2.0에서 아주 중요한 개념입니다. 웹기반 SW는 브라우저, 웹서비스로도 지원되어 새로운 형태로 메시업되어 사용될 수 있어야 합니다. 이렇게 되면 SW가 단순한 어플리케이션에서 진정한 플랫폼으로 변환 되는 것을 의미합니다. 마이크로소프트의 Virtual Earth를 가져다가 자동차 보험회사에서 사고처리 하는 웹을 구현하는 것도 하나의 예가 되고, Salesforce.com의 AppExchange를 통해 서비스를 조합하여 원하는 형태의 업무가 가능하게 하는 것도 또다른 예가 되겠죠.
즉, 어플리케이션을 웹서비스로 공유하여 내가 만든 기능과 데이터를 다른 사람이 혁신적인 방식으로 유용하게 사용하는, 이전에는 상상하기 어려운 진보를 이루어 내는 겁니다. 누구나 거대한 서비스의 공급망의 일원이 되는 거죠. 단순하고 직관적으로, "Just Work"를 이루어 내는 겁니다. 내부에서 사용하는 방식도 HTTP의 GET, POST, PUT, DELETE 등의 이미 알고 있는 형태로 조작됩니다.

짐작하셨겠지만 장점만 있을까요? 당연히 아니겠죠. Two-phase commit, 메시징에 대한 보안 등은 처리가 안됩니다. SOAP에서 가능한 WS-* 표준이 지원되지 않기 때문이죠. HTTPS를 통한 전송에 대한 보안만 제공됩니다.

WOA에 대해 조금 설명을 해보겠습니다.
1. 네트웍상에 리소스 형태, 즉 URI로 표현, 접근, 조작됩니다. (HTTP 프로토콜)
2. 네트웍상의 모든 자원은 URI 형태로 배치됩니다.
    - URI는 자원임을 알 수 있는 것이 바람직합니다.
      예) http://domain.com/blogs/feeds/sruby.com -> http://domain.com/resources/1234567
3. 자원은 HTTP 동사(즉, GET, POST, PUT, DELETE)로 조작됩니다. using REST
4. 자원의 형식(XHTML, XML, MP3, AVI 등)은 URI에 인코딩 되어야 합니다. .xml 일반적
5. 네트웍상의 자원에 대한 조작은 네트웍상의 컴포넌트를 통해 조작됩니다. (브라우저, 웹서버)
6. 자원에 대한 접근은 계층적으로 이루어지고, 기본 네트웍 지식으로 사용 가능합니다.
7. 보내지는 상태에 대한 전송은 각 컴포넌트가 책임져야 합니다.
8. WOA 자원은 더 큰 네트웍을 표현할 수 있도록 내장 URI를 가져갈 수 있습니다. (예, 주문 컴포넌트는 인벤토리 포함가능)
9. WOA는 Thomas Erl의 "SOA 핵심 원칙"을 따릅니다.

SOA와 WOA의 차이점 입니다.
1. SOA는 작고, 잘 정의된 Endpoint가 있는 경향이 있습니다. WOA는 매우 크고, Open된 많은 Endpoint가 있습니다. 
2. 전통적으로 SOA는 SOAP을 사용한 HTTP 프로토콜 위에 메시지 Layer를 구축하는데, 유일하고 웹 개발자가 그대로 따라하도록 만들어집니다. WOA는 HTTP 및 그에 맞는 전송 메커니즘을 따르게 됩니다.
3. SOA는 벤더를 중심으로 Top Down 형태로 디자인 되고, WOA는 개발자들 중심의 Bottom Up 방식으로 나타납니다. 간단한 절차 코드와 XML 파서만 있으면 됩니다.
4. SOA는 보안 기능을 위해, 즉 메시지 암호화 등을 위해 WS-Security를 사용하는데 반해 WOA는 HTTPS를 사용합니다.
5. 웹 서비스 간의 상호 운영성을 위해 SOA는 XML 스키마를 사용해야만 합니다 WOA는 일반적으로 어떤 포맷도 가능합니다.
6. 전통적으로 SOA는 웹 브라우저 및 매시업 형태로 사용하기 어렵고 성가십니다. WOA는 어디서나 쉽게 사용 가능합니다.

즉, SOA와 WOA는 완전히 별개가 아니고 상호 보완 하는 형태로 이해하는 것이 좋습니다.

현재의 IT 주요 트렌드가 무엇일까요? SOA(Service Oriented Architecture), Web2.0, SaaS(Software as a Service), RIA(Rich Internet Application), 그리고 클라우드 컴퓨팅 (Cloud Computing) 이라고 생각합니다.

한마디로 간단히 정의하면
SOA는 "Reuse & Agility, 재사용과 민첩합"을 목적으로 나온 개념입니다.
Web2.0은 "Network Effect, 네트웍 효과, 소셜 네트웍" 으로 설명할 수 있을 것 같구요,
SaaS는 "Flexbile Pricing & Delivery, 유연한 가격 정책과 서비스의 새로운 Delivery 방식" 이구요,
RIA는 "Experience, 사용자 경험"이 주요 개념입니다.
그렇다면, Cloud Computing은 "Service Utility, 즉 유틸리티, 수도 및 전기와 같은 컴퓨팅"이라고 설명할 수 있을 것입니다.

위와 같은 다른 용어로 시장에서는 설명을 하고 나름대로의 정의를 내리기는 하지만, 사실 SOA, SaaS, Web2.0, RIA, Cloud Computing은 어떻게 보면 다르지 않습니다. 모두 현재까지 나와있는 표준들, 다양한 기술들을 이용하여 조금씩 다른 방식으로 사용하고 있다라고 이야기할 수 있습니다.

마이크로소프트는 이러한 5가지 개념을 소프트웨어 플러스 서비스 라고 하는 Umbrella로 설명하고 있습니다. 어떤 개념을 사용하더라도 결국에는 소프트웨어, 서비스가 공존하는 환경이 펼쳐진다는 것이죠.

모든 기업은 두가지를 고려하게 됩니다. 데이터 및 어플리케이션을 통제하는데 우선순위를 둘 것인지, 아니면 규모의 경제에 우선순위를 둘 것인지를 결정해야 하는 거죠. 이러한 기준에 맞추어 시장에는 현재 4가지의 IT 모델이 존재합니다.
첫째, On-Premise. 하드웨어, 소프트웨어를 모두 관리 및 소유 하는 개념

둘째, Hosting. 호스팅 업체 및 IDC를 통해 내가 개발한 어플리케이션 및 패키지를 내가 지정한 하드웨어에서 구동하고 비용을 지불하는 방식

셋째, SaaS. 다른 누군가가 개발해 놓은 어플리케이션을 사용하고, 나는 하드웨어, 소프트웨어 등의 운영등은 전혀 고민하지 않는 방식. CRM 등의 솔루션이 요즘 많이 이용되고 있죠

넷째, 클라우드컴퓨팅. 어플리케이션이 클라우드 플랫폼에서 구동되는 것, 즉 내가 어플리케이션을 개발할 때 필요한 스토리지, 컴퓨팅 자원을 클라우드 플랫폼 제공자의 것을 사용하는 데, 접속량이 아무리 많아져도 문제없이 서비스 가용성을 보장하는 서비스 방식. (즉, Scalability, 확장성이 보장되는 것이죠) 1,2주 정도 올림픽 프로모션 사이트를 구축하려고 할 때, 대박이 나면 몇 명 정도가 접속할 지 알기 어렵죠. 1만명, 10만명, 100만명에 맞추어 서버 인프라를 구축해야 할지, 아니면 1,000명 수준으로 구축할 지 정말 판단하기 어렵고, 또 2주만 사용하는 사이트 인프라에 많은 비용을 쓰기 어렵겠죠. 한 번 쓰고 나중에 6개월 후에나 다시 쓸지 모르는데 큰 투자가 가능하겠어요? 이럴때 클라우드 컴퓨팅이 아주 적절한 개념이 되겠죠.

즉, On-Premise, Hosting, SaaS, 클라우드 컴퓨팅은 다른 것을 대체하는 개념이 아닌 서로 보완하는 개념으로 IT의 진보와 발맞추어 함께 갈 것이 분명합니다.
그렇다면, 내가 지금은 클라우드컴퓨팅 방식으로 개발해서 비용을 지불했는데, 정책이나 상황이 변해서 On-Premise 방식 또는 Hosting 방식, SaaS 방식으로 바꾸려고 할 때 어느정도 유연하게 바꿀 수 있느냐가 중요한 의사결정 포인트가 될 것인데요, 이와 같은 유연함을 제공할 수 있는 플랫폼을 고민하는 것이 필요한 시점입니다.