블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

다르게 생각해볼만한 클라우드 컴퓨팅 활용 전략


조대협 (http://bcho.tistory.com)


근래에 스타트업 기반의 빠른 속도의 개발을 경험하고, 클라우드 컴퓨팅 도입 전략에 대해서 고민할 기회가 생겨서 여러 자료를 검토하던중에 퍼블릭 클라우드 도입 전략에 대해서 기존과 다른 접근 방식이 필요하다고 생각되어 그 내용을 정리합니다.


특정 벤더의 의존성 배제


퍼블릭 클라우드 하면 거의 공식 처럼 AWS 클라우드가 소위 말해서 갑이었으나, 근래에 들어서 구글이나 마이크로소프트가 큰 딜을 잡아나가면서 약간씩 구도가 바뀌고 있는 형상이다.  

 특히 구글의 Spotify와, Quizlet의 사례를 보면 구글 사용사례이기 때문에 구글이 좋다는 이야기지만, 내용을 디테일하게 살펴보면 꽤나 재미 있는 인사이트를 얻을 수 있다.

  • Quizlet의 사례 https://quizlet.com/blog/whats-the-best-cloud-probably-gcp
  • Spotify의 사례 https://news.spotify.com/us/2016/02/23/announcing-spotify-infrastructures-googley-future/




Quizlet의 사례는 가격과 성능에 대한 이야기인데 내용을 요약하면 비슷한 VM이면 구글이 더 싸고 성능 (CPU,메모리, 네트워크)이 훨씬 좋다는 것이다. 아마존은 다양한 가격정책으로 다양한 컴퓨팅 파워를 제공하지만 그만큼 세밀한 가격 정책에 의해서, 높은 성능을 내려면 그만큼 추가 상품을 사야 하는데 비해서, 구글의 경우에는 기본 VM들의 네트워크가 IO 성능들이 높다는 것이다.


여기서 구글의 우수성을 보는것 보다, 이게 왜 좋은지에 대한 인사이트를 얻어야 하는데, 아마존은 다른 클라우드 벤더에 비해서 포트폴리오가 매우 다양하다. 인코딩, IAM, 하드웨어 기반의 키 보안 기술 등 그래서 한번 특정 클라우드에 들어가면 다른 클라우드로 옮기기가 쉽지 않은게 사실인데, 잘 생각해보면, 근래의 클라우드 기반의 아키텍쳐는 다음과 같은 트렌드를 갖는다.


VM위에 직접 설치해서 사용


EC2와 같은 VM만 있으면 그위에 직접 소프트웨어를 설치해서 운영을 하면 된다는 것이다. 아마존에서 제공하는 RDS나 RedShift 와 같은 서비스도 결국은 MySQL이나 Postgres와 같은 오픈 소스 기반이고 대부분이 오픈소스나 기존 제품을 기반으로 되어있기 때문에 교체가 가능하다는 것이다. 강한 기술조직을 가지고 있는 기업의 경우 직접 이러한 제품들을 설치 및 운영이 가능하기 때문에 특정 벤더에 Lock in이 되는것을 최소화할 수 있다.

단 이런 소프트웨어를 설치해서 사용하기 위해서는 VM 자체의 성능과 가격이 중요해진다. 네트워크나 디스크 IO의 속도나 GPU 지원 여부등이 중요한 판단 포인트로 작용을 하게 된다.


즉 이 이야기는 EC2와 같은 컴퓨팅과 S3와 같은 스토리지와 같은 필수 서비스만 제공한다면 어떤 클라우드가 되던지 크게 문제가 없다는 것으로 생각할 수 있다.


매니지드 서비스의 분리


스타트업이나 또는 운영을 자동화하여 개발에 집중하는 조직의 경우 RDS와 같은 클라우드 서비스 제공자가 운영을 대신 해주는 managed 서비스를 이용하는 것을 선호하는데,  근래에 들어서 매니지드 서비스를 전문적으로 제공하는 업체들이 많아졌다. mongoDB나 Redis와 같은 NoSQL의 솔루션을 매니지드 서비스의 형태로 제공하는 compose.io를 보면, 이러한 서비스를 AWS, IBM Softlayer, Digital Ocean등의 몇몇 클라우드 (IaaS)위에서 제공한다는 것이다. 


내가 어떤 IaaS를 사용하건간에, 전문화된 업체를 통해서 특정 솔루션을 매니지드 서비스 형태로 사용이 가능하다. 또 다른 사례중의 하나는 PaaS 플랫폼으로 유명한 Heroku의 경우인데, Heroku는 PaaS 이지만, 사실상 아래 인프라는 AWS로 되어 있다. 현재는 AWS만 지원 하지만, 클라우드 시장이 커감에 따라서 다른 인프라를 충분히 지원이 가능하다고 볼 수 있다. Heroku의 경우 아마존 회사가 아니라 Salesforce.com에 인수되었기 때문에 아마존을 꼭 사용해야 하는 이유가 없다, Cloud Foundary라는 오픈소스를 이용해서 구현이 되었기 때문에 VM만 있다면 큰 문제 없이 다른 인프라에 배포가 가능하다.  (Heroku는 CF를 기반으로 하지 않는다. IBM의 Bluemix가 CF 기반임)





정리해서 말하자면 인프라 클라우드 사업자가 있고 그 위에 매니지드 서비스를 제공하는 전문 사업자들이 점점 더 늘어날 것이고, 이 사업자들은 인프라에 대한 종속성이 없기 때문에, 인프라 클라우드의 차별화가 그다지 크지 않아질 수 있어서 특정 벤더에 대한 종속성이 약해질것이라고 본다.


오픈 API를 통해서 하이브리드 클라우드 기반의 서비스 분산 배치


오픈 소스로 대체가 불가능한 특별한 서비스들이 있는데, AI나 빅데이타에 관련된 것들이 그러하다, 마이크로 소프트나 구글의 경우 머신 러닝 기능을 OPEN API 형태로 제공하고 있고, 알고리즘이 자사의 노하우가 들어가 있는 형태이기 때문에, 다른 오픈소스로 대처가 어렵다 물론 Spark ML과 같은 라이브러리등이 있기는 하지만 개발에 들어가는 노력이나 알고리즘의 품질이 차이가 많이 난다. 얼마전에 구글이 영상 인식을 가능하게 해주는 VISION API를 발표하였고, 마이크로 소프트도 이 보다 많은 기능을 가지고 있는 영상 인식 API를 발표하였다. 흥미로운 점은 이것들이 API로 서비스가 된다는 것이고 이말인 즉, 원격에서 호출이 가능하다는 이야기다. 

이런 API의 특성상 처리 시간이 호출시간에 비해서(네트워크 시간) 길기 때문에, 리모트로 호출한다고 해서 아주 크게 문제가 되지 않고, 근래의 아키텍쳐 특성상 MSA(마이크로 서비스 아키텍쳐)와 같은 분산 서비스 아키텍쳐가 주류를 이루고 있기 때문에, 메인 시스템과 이러한 API 시스템이 꼭 같은 위치에 있지 않더라도 크게 문제가 없다.


클라우드 서비스 제공자 선택은 가격 보다는 부가 서비스와 기술 지원이 관건


Spotify에 사례를 보면 재미있는 것중에 하나가 구글 클라우드를 선택한 주요 이유가 빅데이타 플랫폼과 기술 지원이다.

 Spotify 의 블로그 내용을 보면 가격은 크게 의사 결정 요소로 작용하지 않았다는 것이다. 실제로 요즘 클라우드 시장이 과열이 되면서 디스카운트가 많이 들어가고 있고, 특히 소위 잘나가는 벤더와 잘나가지 못하는 벤더 (조이언트나 랙스페이드 등)가 갈려지면서, 잘 나가지 못하는 벤더들이 레퍼런스를 잡기 위해서 파격적인 할인에 나서고 있다. 클라우드 컴퓨팅의 인프라 가격은 규모의 경제 측면에서 큰 벤더들이 계속해서 시장을 잠식해 나갈 것이고 자체 기술 개발을 통해서 점점 더 가격을 낮춰갈것이다. 아마존의 경우에도 자사의 데이타 센터에 최적화된 CPU를 인텔에 주문했을정도로 이제 인프라 최적화는 점점 더 가속화되어가고 있고, ARM CPU 기반의 서버도 시장에 조금씩 나오는 만큼 가격 경쟁은 가속화 되리라 본다. 특히 통계를 보면 클라우드 가격은 매년 13% 정도씩 감소하고 있다고 한다.


그러면 Spotify가 구글 클라우드 플랫폼을 선택한 이유는 무엇일까?

빅데이타 플랫폼에서 찾을 수 있다. 구글이 경쟁사 대비 더 좋은 빅데이타 플랫폼 서비스를 제공하고 있다는 것인데, AWS의 빅데이타 플랫폼의 하둡이나 스파크, RedShift와 같은 기존의 오픈 소스를 매니지스 서비스로 제공하는 것이 주요 전략이라면, (물론 Dynamo처럼 직접 원천 기술을 만들어서 제공하는 서비스도 있다.) 구글은 기술의 종가답게 이러한 기술들에 대해서 강점을 가지고 있다고 Spotify 블로그에서 전하고 있다.


즉 앞에서 설명한것과 같이 VM 서비스는 평준화 되어 크게 비교 포인트가 되지 못할 것이며, 부가 서비스들 중에서 AI나 빅데이타 영역과 같이 특화되어 대체가 어려운 서비스를 가지고 있는 업체가 강점을 가지게 될것이다.


아울러 기술 지원 부분은 기술 도입에 있어서 중요한데, AWS의 경우 일주일이 멀다하고 계속해서 신기술과 업데이트가 발표되고 있다. 이러한 상황에서 실무 입장에서 새로운 기술을 일일이 찾아보고 자사의 시스템을 클라우드 서비스 제공자에 최적화 하는데는 많은 공부가 필요하고 서비스 제공자에게 서비스 개선등을 요청하기 위해서 원할한 커뮤니케이션 채널이 필요하다. 이를 흔히 프리세일즈(물건을 팔기전에 기술적으로 기술을 설명해주는)와 포스트 세일즈(물건을 판후에, 잘 사용할 수 있도록 지원하는)라고 하는데, 클라우드는 특성상 Self Service의 개념을 가지고 직접 배워서 직접 사용한다는 개념인데, 그러기에는 기술의 속도가 너무 빨라서 이에 대한 지원이 필요하다는 것이다. 실제로 엔터프라이즈 시장에서 성공했던 오라클이나 IBM과 같은 공룡들도 많은 매출이 제품을 판 후에 구현을 도와주는 포스트 세일즈에서 발생을 하였고, 프리세일즈 과정에도 많은 리소스를 투여했던 것이 사실이다.


아직은 클라우드 서비스 제공자의 프리/포스트 세일즈가 강하지는 않지만 (있기는 있다). 이쪽이 성장하면서 좋은 프리/포스트 세일즈 조직을 가진쪽이 비지니스 딜에 좋은 포지션을 가지게 될것이라고 생각해본다.


하이브리드 클라우드 전략


기업의 클라우드 전략을 보면 크게 두가지 갈래로 나뉘어 지는데, 자체 데이타 센터 구축 전략과 클라우드 활용 전략이다.

페이스북과 같은 경우 자체 클라우드를 사용하고, 애플의 경우에도 자체 데이타 센터를 구축하고 있는 것으로 알려지고 있다. http://fortune.com/2016/02/02/apple-data-center-move/

페이스북이나 구글같은 전통적인 테크 기업이면서 서비스 볼륨이 일정 규모 이상되는 경우는 규모의 경제상의 경제상에서 자체 데이타 센터를 구축하고, 자체 서비스에 맞는 인프라를 최적화 해가는 방향으로 집중을 하고 있다. 


반면 Netflix나 Spotify와 같은 서비스 기업은 서비스 개발에 집중을 하고, 인프라는 퍼블릭 클라우드를 사용하는 형태로 방향을 잡아가고 있다. 아무리 인력을 투여해도 퍼블릭 클라우드에서 개발하는 신규 기능을 따라 잡기도 힘들뿐더러, 비용 최적화 면에서도 규모의 경제 특성상 퍼블릭 클라우드가 유리하다는 판단하에서다.





그러면 퍼블릭 클라우드와, 자체 데이타 센터 무엇이 정답일까? 사실은 잘 모르겠다. 

하나 힌트를 얻자면, 애플의 클라우드 전략에서 살펴볼 수 있는데, 애플은 규모의 경제면에서 자체 클라우드를 갖출 정도로 큰 iCloud 서비스를 사용하고 있지만, 자체 클라우드 전략의 이면에서는 데이타 보안에 대한 부분이 있다. 고객의 중요 데이타를 타사의 클라우드에 넣는 것이 계속해서 부담이 되어 왔다. 


그렇다면, 중요 데이타나 중요 시스템은 자사의 클라우드에서 서비스하고, 다른 서비스나 또는 모자른 자원은 퍼블릭 클라우드를 사용하는 하이브리드 클라우드 전략을 갖추지 않을까 조심스럽게 생각해본다.


근래에 얻은 인사이트를 기록해놓고자 정리를 하였지만, 클라우드 컴퓨팅은 이제 거의 필수제가 되어가는것 같다. 특히나 구글,MS,아마존과 같이 규모의 경제를 앞세운 거대 기업들이 이 주도권을 잡아가면서 다른 사업자들은 힘을 잃어가면서 대형 서비스 제공자만 살아 남을것으로 보이고, Digital Ocean과 같은 niche vendor (특정 도메인에 선택과 집중을 통해서 가치를 창출해나가는)들은 특화된 서비스로 특화된 시장을 열어 나갈것이라고 보인다.


서비스 전략이나 시스템 아키텍쳐 설계도 이러한 클라우드 벤더의 변화에 맞춰서 다양화를 해나가야 하지 않을까?

예전 같으면 AWS를 깔고 시스템을 디자인 했다면, 요즘에 다시 시스템을 디자인 한다면 One of IaaS 서비스 + Compose.IO 와 같은 매니지스 서비스 기반의 설계가 조금 더 실용적이 아닐까 생각해본다.

기업에서 마이크로 블로그의 도입

지금까지 마이크로 블로그에 대해서 알아보았다. 그러면 이 마이크로 블로그 시스템을 기업에 어떻게 적용할 수 있을까

기업 내부 협업 플랫폼으로써의 마이크로 블로그

먼저 기업 내부의 협업 플랫폼으로써 마이크로 블로그를 도입한다면 어떤 기대 효과를 얻을 수 있을지 살펴본다

개인 브랜드 개발

트윗 메시지의 포스팅의 질은 개인의 브랜드와 직결된다. 전문성이 많은 포스트나 현재의 일 진행 상황을 자세하게 기록하면서 개인의 브랜드 가치를 향상 시킬 수 있으며, 특정화된 브랜드는 조직입장에서 업무의 효율성이 높은 직원을 선별해내고, 조직내에서 전문성을 가지고 있는 사람을 쉽게 찾을 수 있게 한다

리스크 조기 감지

마이크로 블로그 내의 RT Hash Tag를 분석함으로써 현재 회사내의 트렌드를 감지할 수 있으며, 이를 통해서 특정 Risk 요인이 있을 경우에 조기에 발견할 수 있는 일종의 사내 조기 경보기와 같은 역할이 가능하다

전문가와 네트워크 구축

실제로 기업의 규모가 커지면 커질수록 많은 비즈니스 부서가 존재하고, 협업이 필요할 때 누가 전문성을 가지고 있는지를 알아내기가 매우 어렵다. 이는 조직의 결재 구조를 따라서 인재를 요청하거나 또는 인맥을 통하여 추천을 받는 방식을 사용하는데,검증이 쉽지 않고 시간이 많이 걸리는 문제가 있다. 마이크로 블로그의 검색을 통해서 특정 분야에 관심이 있는 사람을 검색하고 그 사람의 트윗 메시지를 살펴봄으로써 필요한 전문성이 있는 사람을 쉽게 찾을 수 있고 네트워크를 구축하여 업무적으로 필요한 전문지식에 대해서 도움을 받을 수 있다

지식 공유

마이크로 블로그내에 링크로 저장되어 있는 많은 문서와 전문성을 가진 사람들이 추천하는 링크 그리고 RT된 링크들은 링크된 문서의 신뢰도를 나타내어 주며 기존의 검색엔진(구글과 같은)과 다른 형태의 지식 검색 및 공유 방법을 제공한다. 단순하게 텍스트나 내용의 일치가 아니라 Following하고 있는 사람의 신뢰도와, 많은 사람에 의해서 퍼 날라지거나 인용된 문서의 경우 신뢰도가 높다는 사람의 신뢰 중심의 지식 검색이 가능하게 된다

업무에 대한 컨텍스트 공유

프로젝트나 업무 그룹에 대해서 그룹 필터를 사용하여 진척 상황이나 이슈를 포스팅하여 구성원과 이해 당사자들이 해당 업무에 대한 진행현황(Context)에 대해서 이해할 수 있도록 한다. 현황과 상황은 과거에서부터 현재 어떻게 되고 있다는 Context를 나타내는 만큼, 당사자가 한두번의 브리핑이나 이메일로 현재 업무의 진행 상태를 파악하기가 어렵다. 마이크로 블로그를 통해서 업무에 대해서 계속해서 포스팅을 하면 포스팅 내용이 시간의 순서대로 연결이 되어 업무에 대한 Context의 의미를 가지게 된다

신뢰감 증대 및 관계 개선

마이크로 블로그를 통해서 임원과 같이 조직에서 일반적으로 접하기 쉽지 않은 사람을 Following 하는 행위 자체만으로도 심리적인 유대감을 형성할 수 있다. 거기에 더해서 해당 임원에게 보낸 답변에 대해서 응답이라도 받는 경우에는 구체적인 교감이 있는 것으로 인식이 되서 심리적으로 느끼는 거리가 줄어든다.

또한 마이크로 블로그의 트윗 포스트는 메일이나 게시판과 같이 정형화된 커뮤니케이션이 아니라 좀더 캐주얼하고 비업무적인 부분 (그날의 기분, 일상)도 다루기 때문에 업무적이 아니라 인간적인면 즉 감성적인 커뮤니케이션을 통해서 직원간의 거리를 줄일 수 있게 한다.

결과적으로 좀더 활발한 커뮤니케이션을 유도하여 조직의 구조에서 오는 커뮤니케이션의 장벽을 허물 수 있고 구성원간의 신뢰도를 높일 수 있다

수평적이고 오픈된 커뮤니케이션

기업의 커뮤니케이션 문화는 수직 계층적인 문화를 가지고 있다. 여러 계층을 통하다 보니 커뮤니케이션의 효율성은 떨어지고, 좋은 아이디어나 의견이 하층에서 상층까지 제대로 전달되지 않거나 경영조직의 메시지가 스팸으로 취급되어 버리는 경우가 많다. 마이크로 블로그에서는 조직간의 상하 관계가 없으며 이슈와 주제만으로 커뮤니케이션을 하기 때문에 수직 계층에서 오는 이러한 차이를 극복할 수 있게 하고, 조직의 구조화된 커뮤니케이션 구조를 수평/네트워크화된 형태의 커뮤니케이션 구조로 개선할 수 있다

Near Real Time형태의 커뮤니케이션 스타일

이메일과 게시판, 메모 시스템들을 대체하여 간단한 비동기적인 커뮤니케이션을 효율적으로 수행할 수 있으며 특히 모바일 디바이스 연동을 통해서 장소와 시간에 관계 없는 커뮤니케이션 플랫폼을 구축할 수 있다. 

기업 외부로의 마이크로 블로그

기업이 비즈니스를 하는데 외부 관점으로는 어떻게 마이크로 블로그를 사용할 수 있을까? 주로 대고객 서비스에 마이크로 블로그를 적용할 수 있고, 실제로 S전자,L전자와 같은 글로벌 국내 기업이나 아마존 같은 기업들은 이미 트위터를 통해서 마케팅 활동을 진행하고 있다.

마케팅

새로운 제품에 대한 정보 제공이나 이벤트 행사등에 사용할 수 있다.

고객 서비스

고객의 불만 접수, 고객 모니터링등에 이용 가능하다

본 글을 기업내의 마이크로 블로그 구축 전략을 중점으로 다루고 있기 때문에 기업 외부에 있는 마이크로 블로그를 이용하여 기업 활동을 증진 시키는 방안에 대해서는 자세하게 설명하지는 않는다.

 기업에서 마이크로 블로그 아키텍쳐


Figure 2 Micro blog architecture for enterprise

 사용자 인터페이스

마이크로 블로그는 직원에게 다양한 사용자 인터페이스를 제공하며 기업의 기존 시스템들과 통한된다.

(1)    웹 인터페이스

가장 일반적인 형태의 인터페이스로, 마이크로 블로그 시스템의 고유 웹인터페이스이다.

(2)    모바일 디바이스

이동이 가능한 핸드폰이나 PDA같은 모바일 디바이스로 마이크로 블로그를 서비스 한다. 단말의 종류 서비스 국가에 따라서 서비스 형태가 다르게 제공된다. 스마트 폰의 경우 애플리케이션 형태로 2G이하의 폰의 경우 SMS형태로 서비스가 제공된다.

(3)    포탈

기업의 엔터프라이즈 포탈이 있을 경우, 포탈을 통해서 마이크로 블로그 서비스를 포틀릿 형태로 서비스 한다.

(4)    IM (Instant Messenger)

기업내 메신져와 통합하여 메신져를 통해서 트윗 메시지를 포스팅하거나 반대로 메신져를 통해서 Following하는 대상의 메시지를 받을 수 있게 한다.

(5)    기타 엔터프라이즈 애플리케이션

엔터프라이즈 시스템의 Notification. 예를 들어 Work flow Approval Request등이 기존 이메일 시스템들을 마이크로 블로그로 대체할 수 있다

IDM (Identity Management System)

기업내부에 이미 사용중인 직원 정보 (LDAP 등에 적용된 조직도나 직원 프로필 서비스)시스템인IDM Single Sign On등을 통해서 계정이 통합되어야 한다.

모바일게이트웨이

모바일 디바이스를 지원하기 위해서 통신사의 통신망을 이용하기 위한 게이트웨이이다.

모바일 디바이스의 타입과 연동 방식에 따라 텍스트 기반인 경우 SMS를 멀티미디어 기반의 경우 MMS를 지원하고 스마트폰 기반의 애플리케이션의 경우 TCP/IP 망등을 지원해야 한다.

즉 모바일 디바이스에 따라 모바일 게이트웨이의 연동 방식이 변경될 수 있다.

또한 글로벌 기업의 경우 각 나라마다 텔레콤 회사가 다르기 때문에 사용자의 근무 위치에 따라서 다른 모바일 게이트웨이를 사용하도록 한다.

검색엔진 및 소셜분석 도구

앞서 기업 내부 플랫폼의로써의 마이크로 블로그에서도 언급했듯이 마이크로 블로그의 포스팅 내용은 정보성을 갖는다. 특히 기존의 정확도 기준의 검색 방식이 아니라 마이크로 블로그에 의해서 언급된 비율이나 내가 Following하고 있는 사람이 언급한 정보(같은 이슈를 공유할 가능성이 높기 때문에)는 검색의 정확성이 더 높기 때문에 검색의 방법역시 마이크로 블로그의 가치를 높일 수 있는 검색 시스템이 필요하다

또 마이크로 블로그의 포스팅 내용을 분석하면 리스크 상황이나 트렌드를 읽을 수 있기 때문에 소셜분석도구들을 이용하여 포스팅 내용을 분석하여 의미 있는 데이터로 가공할 수 있다

Policy & Compliance Rule

마이크로 블로그의 기업 도입은 정보 보안의 문제를 해결해야한다. 기업 내부로는 특정 그룹 구성원들간에만 커뮤니케이션이 필요한 경우가 있고 기업 밖으로 배포 되는 정보역시 기업의 보안 정책에 따라서 선별적으로 배포 되어야 한다. Policy & Compliance 컴포넌트는 보안 정책에 따라 이 두가지 부분을 커버한다.

(1)    Selective publishing

직원의 아이디를 연동하여 외부 마이크로 블로그(트위터)로 배포 하고자 할 때, 직원이 선별적으로 외부에 배포하는 글을 선택하거나 또는 시스템에서 보안 정책에 위배되는 키키워드 있을 때 이를 필터링하게 해주는 선별적 배포 기능이다.

(2)    Multilevel access & grouping

임원과 일반 직원 또는 부서(예를 들어 HR부서) 내부에서만 다루어야 하는 정보가 있기 떼문에 특정 그룹이나 조직 단위로 커뮤니케이션을 할 수 있게 한다

Micro blog (Public)

외부 마이크로 블로그 시스템으로, 기업 홍보와 같은 마케팅을 위해서 기업 내부의 포스팅 메세지가 기업 외부의 일반 고객이 사용하는 마이크로 블로그 시스템으로 메시지가 배포 되는 대상이다

기업에서 마이크로 블로그 도입 Challenge

 문화의 변경

마이크로 블로그의 도입은 단순한 IT 시스템의 도입이 아니다. IT 시스템은 정해진 프로세스에 직원들이 프로세스의 구성원으로써 주어진 역할을 수행하면 됬지만, 마이크로 블로그의 도입은 정형화된 프로세스에서 벗어나 직원에게 새로운 커뮤니케이션 및 정보 저장 도구를 주어줌으로써 창의력 발휘를 통해서 업무 생산성의 혁신을 불러오고자 하는데 있다.

 이를 위해서는 마이크로 블로그를 이용한 수평적 그리고 비정형적인 커뮤니케이션 스타일의 도입이라는 문화적인 변경이 필요하다. 이는 관리 지향적인 조직 입장에서 이해당사자들의 설득이 필요한 하나의 도전 과제이다.

 정보 보안

마이크로 블로그에 저장되는 내용들은 업무의 진행상태, 개인의 상태등에 대한 정보로 기업의 비밀에 해당하는 내용이다. 이러한 내용이 유출되지 않도록 보안을 유지해야 하며, 반대로 마이크로 블로그의 장점은 오픈된 환경에서 오는 참여에 있기 때문에 보안의 폐쇄성이 원래 마이크로 블로그의 특징을 해치지 않도록 해야 한다.

 또한 구축하는 국가에 따라서 법률에 접촉되는 여부를 검토해야 한다. 예를 들어 미국의 Sox 법에 의하면 사내 커뮤니케이션 내용은 최소 7년간 보장/유지 해야한다는 내용이 있기 때문에 포스팅 데이터에 대한 유지 역시 정보 보안 부분의 도전 과제에 해당한다.

 구축

마이크로 블로그 시스템이 기업에 도입되기 시작한 것은 근 1년 이내이다. 그렇기 때문에 이렇다할 기업용 마이크로 블로그 시스템이 많지도 않을뿐더러, 각 기업의 구축 요건을 충족시키지도 않고 기존 기업 시스템과의 통합성도 떨어지기 때문에 구축에 있어서 적절한 솔루션을 찾고 커스터마이징하는 것이 큰 과제중의 하나이다

구축 전략

앞서 마이크로 블로그의 활용 방법과 얻을 수 있는 장점 그리고 이를 위한 아키텍쳐에 대해서 설명하였다. 물론 아키텍쳐에 제안된 모든 부분을 처음부터 구축할 수 있다면 가장 좋겠지만, 모든 것이 구축되었다고 해서 모든 장점을 얻을 수 있는 것은 아니다.

 기업의 문화를 바꿔야 하는 일인 만큼, 기대했던 효과가 한꺼번에 나타나지 않을 수 있고, 기업의 업무 환경이나 시스템 환경이 변화할 수 있기 때문에 단계적으로 시스템을 구축하는 것을 권장한다

1단계 마이크로 블로그 시스템의 구축

 첫번째 단계에서는 가장 기본적인 마이크로 블로그 시스템을 구축한다. 필수적인 기능으로는 IDM 시스템 연동,모바일 인터페이스 제공이다. 이 두가지 기능만 가지고도 마이크로 블로그를 서비스할 수 있고 대부분의 장점을 시험할 수 있다

2단계 활성화

구축이 완료된 후에는 활성화 단계로 기업의 문화를 마이크로 블로그를 사용하는 형태로 바꿔 나가면서 마이크로 블로그를 이용한 커뮤니케이션을 활성화 한다. 이 단계가 지나면, 시스템에 추가적으로 필요한 기능이 선별된다

3단계 확장

시스템이 활성화 되면 기능을 확장한다. 이미지 포스팅, 동영상 포스팅과 같은 기능을 추가하여 마이크로 블로그 시스템의 활용성을 높이고, 검색엔진, 소셜분석기능등을 구축하여 활성화를 통해서 축적된 정보를 재가공하여 그 가치를 높인다

4단계 새로운 모델 구축 및 확장

4단계에서는 전통적인 마이크로 블로그 시스템의 한계를 벗어나서 기업 업무 형태에 특화된 자체적인 확장 모델을 개발한다. 현장 근무가 많은 영업 조직의 경우 LBS (Location Based Service:GPS등을 이용한 위치 정보 시스템)과 연계하여 Status 정보에 개인의 위치 정보를 표시하거나 위험한 현장 업무가 많은 건설/건축 업무의 경우 개인의 건강 상태나 재해 여부를 Status로 표시하여 근로자가 위험에 쳐했을 때, 구난 요청을 자동으로 보낼 수 있는 시나리오등이 이에 속한다.

Micro blogging strategy for Enterprise

Terry.Cho (Principal Consultant/Oracle Korea)

마이크로 블로깅의 대명사로 지칭되는 트위터는 2006년 서비스를 시작한 이후로 월간 순방문자수 1820만명(20095 QuickTake 발표 자료 기준)를 기록하며, 대표적인 SNS 서비스로 자리 잡았으며,  미국 대선, 이란 대선등의 굴직한 사회적 이슈에 커다란 영향력을 행사하고 있다. 본 글에서는 마이크로 블로깅이 웹 생태계에서 폭발적인 인기를 얻는 요인에 대해서 분석하여 기업내부에서 마이크로 블로깅을 도입하여 그 장점을 활용하는 접근 전략에 대해서 소개한다

마이크로 블로깅

정의

마이크로 블로깅은, 140자 내외로 자신의 상태나 감정(이하 트윗이라고 칭한다.) 을 표현하고 이러한 다른 사람의 트윗을 필터링을 통해서 구독하여 보는 형태의 서비스 이다.

필터링 메커니즘에메 여러가지 방식이 있지만 트위터와 같은 주요 마이크로 블로깅 서비스가 사용하는 방식은 “Follow”라는 방식으로 특정인의 트윗을 구독하여 보는 형태이다. 그외에도 블로그 태깅과 같은 원리의 “hashtag”나 특정 주제에 관련된 그룹을 형성함으로써 관련 트윗을 구독할 수 있는 “group”과 같은 필터링이 있다

마이크로 블로깅으로 무엇을 하는가?

그렇다면 사람들은 마이크로 블로그를 왜 사용할까? 성공 요인 분석에 앞서 사용자의 마이크로 블로그에 대한 가치를 분석해볼 필요가 있다. TNS The Conference Board가 내놓은 2009 2분기 “Consumer Internet Barometer” 리포트에 따르면 사용자의 41.6%가 친구들과 관계를 유지하기 위해서, 29.1%가 자신의 상태를 업데이트 하기 위해서 그리고 25.8%가 뉴스와 정보를 찾기 위해서 이다.


Figure 1.트위터 서비스를 사용하는 이유 (출처:Consumer Internet Barometer” from TNS and The Conference Board")

1,2위 항목을 정리해보면 다른 사람과의 관계 구축과 자신의 상태를 알림으로써 자신을 네트워크에 프로모션하려고 하는 동기가 약 70%에 도달한다. 즉 인간 관계의 구축과 관리 그리고 인간 관계간의 커뮤니케이션이 주된 사용 이유가 된다. 이성적인 관점보다는 감성적인 관점에서 마이크로 블로깅이 사용되고 있음을 알 수 있다.

그렇다면 마이크로 블로깅으로 사람들은 무엇을 하고 있을까? 자신의 상태와 인간 관계간의 커뮤니케이션이 주요 내용이지만 이런 목적으로 작성된 트윗 메시지들은 다른 가치를 가지게 된다.

먼저 내가 무엇을 하고 있고 어떤 생각을 하고 있다.’라는 내용은 다른 사람입장에서 또 다른 정보가 된다.

예를 들어 웹2.0에 관심이 있는 사람이 보고 있는 웹사이트 URL이나 문서 정보 책정보는 같은 정보가 필요한 다른 사용자에게 유용한 자료가 될 수 있다. 이런 자료는 HashTag를 통해서 검색될 수 있고, 그 자료를 다른 사람이 재사용할 수 있다.

또한 특정 공통 주제에 관심이 있는 사람을 같은 방식의 필터링을 이용해서 찾은 후에, 그 사람의 상태 히스토리 정보를 보면 그사람이 같은 주제에 어느정도 관심이 있는지를 알 수 있고, 그 사람과 트윗 대화를 통해서 관게(Relationship)를 구축하고 주제에 대해서 논의를 할 수 있다.

 마이크로 블로깅의 기간별 HashTag나 키워드를 분석해보면 현재 사람들의 관심사가 무엇이고 트랜드가 어디로 가는지도 알 수 있다.

 개개인의 현재 상태는 하나의 흐름이며 집단 정보이다.마이크로 블로깅의 원래 목적이 개인 상태 정보의 로깅과 커뮤니케이션이지만 이는 앞에서 언급한바와 같이 그 자체가 다른 형태의 정보로 활용될 수 있다.

 성공 비결

IM이나 이메일,전화와 같은 기존의 커뮤니케이션 도구들이 있음에도 불구하고 마이크로 블로깅이 급격하게 성장할 수 있는 이유는 무엇일까?

 사용이 쉽다.

먼저 사용 방법이 매우 쉽다. 이메일 처럼 이메일 클라이언트 오픈 à 주소 입력 à 제목 입력 à 내용 작성 à SEND 하는 일련의 절차 없이 로그인 à작성후 엔터면 바로 자신의 상태를 포스팅할 수 있다.

 언제 어디서나 사용이 가능

마이크로 블로깅이 확산된 주요 원인중의 하나는 모바일 디바이스를 이용한 장소와 시간으로부터의 자유이다. 사용자는 언제 어디서나 모바일 디바이스를 통해서 트윗을 포스팅할 수 있고 반대로 읽을 수 도 있다. 여기에 탄력을 더한 것이 스마트폰의 등장인데, 스마트폰을 통해서 웹애플리케이션 수준으로 마이크로 블로깅을 사용할 수 있게 되었고, 이메일이나 다른 IM에 비해서 비동기적인 커뮤니케이션을 지원하고 간단한 단문형 메시지만을 지원함으로 인해서 모바일 디바이스에 좀더 적절한 애플리케이션 형태를 띄고 있었던 것도 성공 요인이다.

 실시간성

마이크로 블로깅의 트윗 메시지는 140자 내외의 단문 메시지이다. 업데이트 하기도 쉽고 모바일 디바이스의 도움으로 언제어디서나 포스팅이 가능하다. 덕분에 자주 포스팅이 가능하고, 포스팅은 그때 그때 실시간으로 이루어진다. 그래서 포스팅된 정보는 거의 실시간성을 갖는다. 실시간적으로 이슈를 올릴 수 도 있고, 모바일 다바이스를 통해서 그 정보를 실시간으로 접할 수 도 있다.

 실제로 국내의 T 제품 발표회장에서 제품 발표에 대한 정보를 마이크로 블로그를 통해서 실시간으로 중계를 하는 사람들이 있었고, 현장의 내용은 기존의 언론이나 포탈보다 훨씬 더 빠르게 접할 수 있었다.

 Open API

마이크로 블로깅의 특징 중의 하나가, 기능을 Open API라는 형태로 외부로 서비스를 제공한다. 이를 통해서 마이크로 블로깅을 응용한 애플리케이션들이 개발되고 융합을 통해서 마이크로 블로깅의 가치를 증대 시키게 된다.

 실예로 마이크로 블로깅은 단문 텍스트 메시지 기반의 시스템이다. 여기에 링크 기능이 추가가 되는데, 이 링크를 통해서 이미지 업로드, 동영상 업로드등이 가능하게 된다. 스마트 폰에서 작성한 사진과 단문 메시지가 하나의 완성된 형태의 정보가 되고 여기에 마이크로 블로그의 신속성이 더해져서 정보의 가치가 높아진다.

 이란 대선 결과에 불복하는 시위에서 네다 솔탄양의 사망 소식과 동영상이 트위터를 통해서 급속하게 전세계에 퍼져나간 사례가 있는데 이 역시 Open API를 이용한 동영상 연동 기능이 있었기 때문에 가능하였다.

  Open API의 적용 사례로 TweetStats.com Hashtags.com은 트위터내의 RT Hash tag를 분석하여 현재 트위터내에서 어떤 내용들이 가장 이슈이고 어떤 사람들이 주목 받는지를 통계로 나타내는 분석 애플리케이션이다.

 이 처럼 마이크로 블로깅은 커뮤니케이션과 네트워크 관리를 통해서 생성된 개인의 상태 정보를 Open API라는 형태로 외부에 오픈함으로써, 다양한 연동을 통해서 그 가치를 증대시키고 있다.

 요약

지금까지 마이크로 블로깅의 성공 요인에 대해서 간략하게 살펴보았다. 기존의 커뮤니케이션 수단들과의 차이를 정리해보면 다음과 같다.

마이크로 블로깅은 기본적으로 불특정 다수를 대상으로하는 1:N 커뮤니케이션이다. Twit 이라는 말 뜻에서도 알 수 있듯이 마이크로블로깅은 네트워크로 연결된 개인의 재잘거림이다. 이러한 재잘 거림이 뭉쳐져서 하나의 흐름을 만들게 되고 네트워크를 걸쳐서 급격하게 전파 되면서 집단적인 지성으로써 움직이게 된다. 메일처럼 형식적이거나 복잡하지 않고 쉽기 때문에 자주 쉽게 업데이트 할 수 있으며  일상적인 회의나 대화처럼 공간이나 시간의 제약을 받지 않기 때문에 실시간성을 갖는다

 

Face2Face

Email

Messenger

Micro Blog

 

1:N

1:N

1:1

1:N(Anoymous)

Connectivity

Need to arrange

Easy to connect

Easy to connect

Easy to Connect

Sync

Sync

Async

Sync

Async (Near-Real Time)

Place

Limited

Limited place depends on device

Limited place depends on device

No Limit

Communication Range

Closed Group

Closed Group

Closed Group

Open to Anonymous

 

마이크로 블로깅 아키텍쳐

이번에는 기술적인 측면에서 마이크로 블로깅 시스템의 아키텍쳐에 대해서 설명한다. 마이크로 블로깅 시스템은 크게 5개의 컴포넌트로 구성된다.


(1)   인증 (Authentication)

마이크로 블로그 시스템에 로그인하기 위한 사용자 인증 기능을 수행한다.

마이크로 블로그는 Open API를 통해서 다른 시스템과 연동을 하는 경우가 있기 때문에 인증 시스템에서 다른 시스템과 인증을 연동하는 기능이나 Single Sign On 같은 기능을 지원한다.

예를 들어 트위터에 글을 올렸을 때, Face Book으로 자동 포스팅이 되게 하게 위해서는 트위터와 Face book간의 ID를 연결 또는 공유해야 하는데 이 역할은 인증 모듈에서 수행한다.

(2)   검색 (Search Engine)

사용자 찾기, Hash Tag 겁색, RT 검색을 수행한다.

(3)   트윗 메시지 관리 (Posting System)

포스팅된 메시지를 관리하고 보여준다.

(4)   링크 관리

마이크로 블로그는 140자 내외의 텍스트 한계를 가지고 있기 때문에 다른 웹사이트로의 링크를 긴 문자열로 그대로 표현하기 어렵다. 이 긴 링크 문자열을 짧게 해서 사용하는 것을 Shorten이라고 하는데, 단문 텍스트의 한계에 맞게 링크를 Shorten 해줄 수 있는 기능이 필요하다.

(5)   모바일 게이트웨이(Mobile Gateway)

모바일 디바이스와 연동할 수 있는 인터페이스가 필요하다. 폰의 종류에 따라서 SMS기반의 연동, 이미지를 첨부할 수 있는 MMS 기반의 전송 그리고 스마트 폰의 경우 마이크로 블로깅 애플리케이션을 탑재하는 방식등을 이용한 연동등 단말기에 따른 여러가지 연동 방식과 로컬 통신사에 맞춘 모바일 게이트웨이가 필요하다.

(6)   Open API

마이크로 블로깅에 트윗을 포스팅하는 기능, 현재 Following하고 있는 사용자의 트윗들을 읽는 기능, 사용자 인증 연동등의 주요 기능을 Open API형태로 Expose (밖으로 제공)하여 다른 애플리케이션과 연동할 수 있도록 한다.

마이크로 블로깅 시스템의 주요 컴포넌트는 많지 않다. 복잡도도 높지 않다. 디자인에 있어서 고려사항은 마이크로 블로깅은 작은 트윗 메시지가 수시로 발생하고 검색 빈도도 매우 높기 때문에  아키텍쳐 Principal(기본)이 성능과 확장성에 맞춰져야 한다.

다음글에서는 기업에서 마이크로 블로깅을 도입하기 위한 전략에 대해서 소개한다.

EAI 프로젝트 추진 전략

2009-07-16
Oracle Korea / Principal Consultant
Byungwook Cho. (byungwook.cho@oracle.com)

 

EAI는 수년전에 소개된 이후로도 아직까지 국내 기업 시스템에서 신규 프로젝트가 발생되고 있고 업무에서 중요하게 사용되고 있는 시스템중의 하나이다. 본 문서에서는 EAI 프로젝트를 진행함에 있어서 필요한 중요 사항에 대해서 간단하게 정리하여 EAI 프로젝트의 성공적인 수행 전략에 대해서 설명하고자 한다

EAI 프로젝트의 접근 방법

EAI 프로젝트를 성공적으로 수행하기 위해서는 크게 EAI 4가지 관점에서 접근할 필요가 있다.


Business Requirement

제일 먼저 기업에서 EAI 시스템이 가져야할 요구사항이다. 어떤 시스템과 인터페이스를 할것인지, 거래에 대한 추적과 장애 처리를 어떻게 할것인지, 목표 성능은 어느정도 인지 그리고 어떤 시나리오에 따라 시스템들이 통신을 할것인지와 같이  EAI 시스템이 실제적으로 가져야하는 기능적/비기능적 요구 사항이다

Architecture

EAI라고 해서 모두 똑 같은 설계와 아키텍쳐를 가지는 것이 아니다. 앞에서 정의한 요구 사항에 따라서 그 아키텍쳐가 변경이 된다.  아키텍쳐는 EAI 시스템의 요구사항을 구현에 반영하는 중요한 블루프린트가 된다

Process

EAI 프로젝트의 가장 큰 특징중 하나는, EAI의 기본 목적이라는 게 다른 시스템과의 연동이기 때문에, 타 팀과의 Communication이 매우 많다는 것이다. 인터페이스(이하 IF)연계에 대한 서로 요건을 맞추고 테스트를 하고 변경 사항을 반영해야 하는 일이 많고 IF의 수도 보통 300~400개는 기본적으로 넘어버리기 때문에, IF에 대한 연계 방식을 협의하고 개발 및 배포하는 프로세스를 관리하는 것이 매우 중요하다

Development / Production Environment

마지막으로 개발 및 운영 환경에 대한 고려가 필요한데, 앞서 Process에서도 설명했듯이, 타팀과의 IF가 중요하기 때문에, 개발에서 완료된 IF EAI와 연동하는 시스템을 개발하는 팀이 자유롭게 사용할 수 있어야 한다. EAI 자체의 개발환경과 타팀을 위한 개발 환경이 존재해야 하고, 특히나 대외거래(B2B)의 경우 물리적으로 폐쇄망 (X.25와 같이 기업과 기업을 연결하는 독립적인 회선)이 존재하기 때문에, 개발 및 운영 환경을 어떻게 설계하고 환경간의 이행을 어떻게 해야 하는 가에 대한 고려가 필요하게 된다

간략하게 EAI 프로젝트를 수행하는 관점에 대해서 살펴보았다.  지금부터 각각의 관점에 대해서 자세하게 설명하도록 한다

첫번째 관점 Business Requirement

EAI가 기업 업무에서 무엇을 할것인가? 에 대한 정의이다EAI의 거래 업무 타입은 아래 그림과 같이 크게 3가지 패턴으로 정의 될 수 있다.


대내 거래는 기업 내부 시스템간의 업무를 통합하는 패턴이다. 대부분 온라인성 업무가 주류를 이루게 된다. 인터넷 뱅킹에서 계좌 정보를 조회해온다던지, 당행 계좌간 이체를 한다던지와 같은 실시간성 거래가 주류를 이룬다

대외 거래는 기업간의 거래를 정의한다. 계열사로 재무 내역을 전송하거나 전송 받거나, 협력 업체에 물품을 주문한다거나와 같은 업무가 주류를 이루며, 온라인성 업무와 디퍼드거래 그리고 배치성 거래들이 섞여서 구성된다. 대외 거래의 특징은 기업간 거래이기 때문에 분산 트렌젝션(XA)등을 이용한 트렌젝션 보장이 불가능하기 때문에 오류시 양쪽의 트렌젝션정보를 비교할 수 있는 거래로그를 저장하는 것이 중요하다.

또 다른 관점에서는 B2B 거래에 있어서는 별도의 한정된 개수의 폐쇄망(X.25, TCP)을 사용하는 경우가 있기 때문에, 회선이 1~2개 인데, 서버가 >2 일 경우 회선이 연결된 서버로 거래 요청을 라우팅 하는 기능과 회선의 상태를 확인하는 기능등이 중요하다

BATCH거래는 대용량의 데이터를 송신 시스템에서 수신 시스템으로 전송하는 요건인데, 다른 업무 시스템간의 거래 정보를 맞추기 위한 BATCH거래와 정보계(데이터를 분석하여 경영에 필요한 리포트를 뽑아 내는 Warehouse BI성의 업무) 두 가지 형태로 분리된다. 전자의 경우 운영 데이타로 사용되는 데이터에 대한 연계이기 때문에, 전달 보장 요건이 매우 중요하고(경우에 따라 XA를 사용할 수도 있음) 후자의 경우는 분석 데이터이기 때문에 전달 보장 요건은 그리 중요하지 않다.

 BATCH거래의 경우 보통 ETL 솔루션을 사용하기도 하는데, ETL 솔루션의 경우 XA기반의 전달 보장 요건이 없기 때문에, 위의 사례중의 후자 (정보계)에는 적절하지만 운영 데이터를 전송하는 과정에는 EAI 솔루션이 더 적절하다고 볼 수 있다

간략하게나마 기업 내부에서 EAI의 업무 요건에 대해서 살펴보았다.

사실 이외에도 MEP (Message Exchange Pattern) – 온라인성의 경우 SYNC,ASYN, 1:N,N:1 거래에 대한 정의와 BATCH성의 경우 Master-Detail, Merge & Insert등 여러가지 거래 패턴이 존재하며 필요한 거래 패턴에 대한 정의도 이 단계에서 이루어져야 한다.

그외에, EAI의 인프라성 기능 거래 추적, 모니터링 배포 등의 요구 사항도 함께 정의 되어야 한다.

 두번째 관점 EAI 개발 프로세스

두번째 관점은 실제 EAI 프로젝트를 수행하는데 있어서의 프로세스이다.

전통적인 Water-Fall 모델 관점에서 봤을 때, 각 단계 별로 EAI 프로젝트에서 필수적으로 수행해야 하는 작업들은 다음과 같다.


Analysis 단계

분석단계에서는 기업내에서 EAI가 무엇을 할것인가? 를 정의한다.

(1)    인터페이스 타입 정의

인터페이스 타입 정의란, 어떤 업무 시스템들과 연동을 할것인지, 그리고 해당 시스템의 기술적인 인터페이스 타입은 무엇인지(Tuxedo,EJB,Socket,WebService,MQ etc)를 조사하고 서로 협의한다. 이때 XA 지원 인터페이스도 정의한다.

(2)    메시지 패턴 정의

인터페이스를 할 시스템들이 정의되었으면 어떤 방식으로 인터페이스를 할지를 정의한다. 이를 MEP라고 한다. SYNC 방식인지, 1:N으로 분할 거래를 할것인지, ASYNC 방식인지, 디퍼드인지 각 업무별로 연계하는 방식에 대해 정의한다.

(3)    인터페이스 전문 정의

어떤 업무 시스템과 어떤 방법으로 연계할지가 정해지면 실제로 왔다 갔다 하는 메시지(전문)에 대한 포맷을 정의한다. XML로 할것인지, TEXT로 할것인지 헤더에는 어떤 데이터데 들어갈것인지, 메시지 ID는 어떻게 정의할것인지등에 대한 정의를 한다.

분석단계가 끝나면 EAI 시스템이 갖추어야 할 모양과 어떤 업무 시스템간을 어떻게 연동할것인지가 정의된다.

Design 단계

EAI 시스템의 요구 사항이 나오면 디자인 단계에서는 실제 인터페이스별로 아키텍쳐 디자인을 수행한다.

(1)   프로토타입 제작

EAI는 시스템의 특성상 기능적인 면(시스템간 연계) 보다 중요한 것이 비기능적인 요건이다. 시스템간의 연계를 주요 목적으로 하다보니, 거래 데이터의 전달 보장과 장애시에 거래 유실을 방지하는 아키텍쳐가 필요하다. 이를 위해서 디자인 초기에 요건이 나온 인터페이스 연계 타입에 대해서 프로토 타입을 구현을 해서 정상적으로 작동하는지 다른 RISK 요인은 없는지 검증을 하고 현업과 연동을 해봄으로써 현업과 연계 시나리오에 대한 동일한 VIEW를 가지도록 한다.

(2)   프로토타입 검증

프로토 타입이 완성되면 해당 프로토 타입에 대한 검증을 한다. 대부분 Micro Benchmark 테스트 형식으로, 시스템 장애에 대한 장애 발견,원인분석,복구 기능을 검증하고, 장기간 거래에 대한 안정성 성능을 측정하여 시스템에 대한 기초 데이터를 마련한다.

(3)   IF 리스트 수집

프로토 타입에 의해서 검증된 아키텍쳐를 기반으로 현업에서부터 실제 연계 IF 목록을 수집하고 개발 일정을 수립한다. 현업의 시스템 개발과 연계 일정에 대해 의존성을 가지기 때문에, 이 과정에서 자세한 인터페이스 방식과 스케쥴을 정의한다.

디자인 단계에서 가장 중요한 것은 주요 인터페이스 패턴 별로 프로토타입을 개발하고 검증을 하는 것이다. 검증된 프로토 타입을 가지고 실제 구현단계에서는 붕어빵(?) 찍어내듯이 같은 패턴으로 정해진 스케쥴에 따라서 인터페이스를 구현해주게 된다

프로토 타입의 중요성은 비기능적 요건의 경우 시스템의 코어 아키텍쳐와 깊게 연관이 되는 경우가 많고, 인터페이스 연계가 끝난 후에 비기능적인 요건에 문제가 있을 경우, 기존에 구현된 인터페이스를 수정하는데 많은 노력을 필요로 한다. 특히 EAI 프로젝트 특성상 타 업무팀과의 협의를 요하고 인터페이스 변경은 그 타업무팀에 새로운 작업을 요구하기 때문에 커뮤니케이션상의 많은 부담과 책임을 가지고 갈 수 있기 때문에, 요건이 정리된 후 되도록이면 빠르게 아키텍쳐를 프로토타입핑을 통해서 검증하는 것이 중요하다

Implementation 단계

구현 단계에서는 실제 스케쥴에 맞춰서 인터페이스를 연계 하고, 이를 개발이나 STAGING환경으로 이행하면서 연계에 있어서 오류가 있는 부분을 수정한다

(1)   인터페이스 연계

구현단계에서는 일정에 맞춰서 인터페이스를 연계한다. 이때 필히 테스트환경을 구축하여 인터페이스 구축시 마다 인터페이스에 대한 테스트를 수행해야 한다.

(2)   단계적 이행

EAI 개발시스템에서 개발된 인터페이스는 EAI STAGING 시스템으로 개발된다. EAI STAGING 시스템에는 업무 시스템에 대한 개발 시스템이 연동이 되어 있는데. EAI 개발 시스템에 연동을 하지 않는 이유는 개발 시스템에서는 잦은 RESTART와 디버깅등이 개발팀에서 이루어지기 때문에 이에 대한 영향을 타 업무 개발팀에 끼치지 않도록 하기 위함이다. STAGING으로 이행을 할때는 정해진 인터페이스 개발 스케쥴에 맞춰서 이행하여 업무 개발팀이 원할하게 업무 개발을 할 수 있도록 한다.

EAI 프로젝트 과정중에는 많은 이행단계가 있다. 개발,통합테스트,운영 시스템으로의 이행등 많은 과정을 거치는데, EAI 이행의 경우 EAI 시스템만 옮기면 되는 것이 아니라 업무와의 연결 포인트가 변경될 수 있고, 특히 B2B 거래의 경우 실제 회선을 물리적으로 이행을 해야할 경우가 있기 때문에, 이행에 대해서 일반 애플리케이션보다 정교한 계획이 필요하다.

(3)   모니터링 및 수정

EAI 프로젝트에서 인터페이스를 연계해놓고 나면 문제가 예상하지 못했던 인터페이스 에러나, 요건 수정이 발생한다. STAGING 시스템에서 이를 모니터링해서 에러를 수정하고 이에 대한 보강 아키텍쳐를 수립하여 반영하는 반복적인 절차가 필요하고, 인터페이스 요건 변경에 대한 반영역시 필요하다. 소프트웨어 개발 프로젝트의 특성상 요건에 대한 변경을 발생할 수 있으나, 거래 인터페이스 타입의 변경 (대상 시스템 타입이 바뀌거나, MEP 자체가 변경되는)은 발생해서는 안되며, 피치못하게 발생했을 경우 변경된 요건에 대한 아키텍쳐 영향도를 분석(프로토 타입핑을 통해서)후에 결정을 해야 완성된 EAI시스템의 안정성에도 문제가 없게 된다

EAI 프로젝트에서 구현 단계에서는 특히 현업의 요건 변경과, 현업의 인터페이스 미 준비등이 가장 큰 이슈가 된다. 스케쥴에 맞게 준비를 하지 않거나 인터페이스 표준을 따르지 않다가 통합 테스트등 프로젝트 마지막 단계에서 갑자기 몰아서 하면서 많은 문제를 만들어내거나, EAI팀이 인터페이스 연계가 늦어져서 업무 개발이 늦어진다는 변명 아닌 변명이 많은 것이  EAI 프로젝트의 특성이다

이를 방지하기 위해서는 구현단계에서 스케쥴에 맞춰서 인터페이스를 연동해주고, 장애나 문제가 있는 상황을 바로바로 로깅하여 백데이타를 확보하고 인터페이스 연계 지연이나 장애 목록에 대해서는 PMO (프로젝트 관리조직)을 통해서 리포팅하여 나중에 있을 수 있는 논쟁의 여지를 방지할 필요가 있다

세번째 관점. EAI 레퍼런스 아키텍쳐

많은 EAI 상용 EAI 솔루션들이 있지만 이러한 솔루션들은 프레임웍만 제공할뿐 실제 연계 아키텍쳐는 그 프레임웍을 기반으로 따로 설계해야 하는 경우가 보편적이다. 여기서는 EAI시스템이 갖추어야 할 요건에 대해서 통상적인 아키텍쳐를 소개하고자 한다


인터페이스

인터페이스 모듈은 EAI의 가장 기본적인 아키텍쳐 모듈로 송수신 시스템을 통합 시키는 부분에 대한 아키텍쳐이다.

(1)  Inbound

Inbound는 송신 시스템과 연동되어 요청을 받고 응답을 송신 시스템에 보내는 역할을 한다. Inbound는 크게 두가지 모듈로 구성된다.

Ÿ   Adapter

아답터는 다양한 플랫폼으로부터 메시지를 읽어드리는 Entry Point의 역할을 한다. 연동 시스템마다 각각의 아답터가 정의 되어야 한다.

Ÿ   메시지 변환

Adapter에 의해서 요청된 전문(메시지)는 각 연동 시스템의 플랫폼에 따라서 각각 다르다. FML이나 XML, 또는 TEXT형태의 전문, Binary등 여러가지 형태가 될 수 있으나, EAI내부에서 처리하기 위해서 이런 전문형태를 공통적인 데이터 구조로 변환한다. 흔히 상용 솔루션에서는 메시지 처리의 유연성을 가지고 가기 위해서 XML을 사용하고, In-House 개발의 경우 성능의 최적화를 위해서 HashTable형태의 Java POJO Object를 사용하기도 한다.

(2)  Mediation

Mediation은 입력된 메시지를 가공하고 중계하는 EAI의 핵심적인 기능 부분이다.

Ÿ   Routing

Routing은 입력된 메시지를 메시지의 내용(헤더나 인터페이스 정보)에 따라서 적절한 수신 시스템으로 Routing하는 역할을 수행한다. 이 과정은 1:1 Routing이 될 수 도 있지만 N:1, 1:N등 다양한 관계로 Routing을 수행할 수 있어야 한다.

Ÿ   Mapping

입력된 전문을 수신 시스템에서 요구하는 형태로 맵핑하는 작업을 수행한다. 필드간의 맵핑이나 간단한 메시지에 대한 변환을 수행한다.

Ÿ   MEP (Message Exchange pattern)

이부분에서 MEP에 대한 처리도 수행한다.SYNC ASYNC, 디퍼드성 거래에 대해서 JMS 와 같은 큐잉을 이용해서 MEP를 구현한다.

(3)  Outbound

Inbound와 마찬가지로 처리가 끝난 메시지를 수신 시스템의 플랫폼의 Native 메시지 형태로 변환하여 Adapter를 통해서 수신 시스템에 전달한다

모니터링 및 장애 관리

인터페이스 아키텍쳐가 가장 기본적인 연계에 관련된 아키텍쳐라면 EAI 아키텍쳐상의 매우 중요한 요소중의 하나가 거래 추적과 에러 처리 방식이다.

(1)  거래 로그

거래 로그는 EAI 시스템의 장애시 송수신 시스템과 거래 내용을 맞춰서 이를 복구하는데 사용한다. 거래 로그에 사용되는 거래 ID는 전사 표준 전문의 헤더에 정의하는 것이 일반적이고 이 거래 ID는 송신에서 수신 시스템까지 하나의 공통된 ID를 사용해야 한다.

거래 로그에 대한 접근 방식은 크게 저장 장소와 저장 방식에 대해서 고민해야 하는데,  데이터 저장 장소는 FILE DB 두가지를 선택할 수 있다. FILE의 경우 비교적 IO성능이 빠르고, DB 장애에 대해 의존성이 적다는 장점을 가지고 있지만 반대로 거래 추적을 할할 때 일일이 FILE을 뒤져야 하는 단점이 있고, DB의 경우 특정 거래를 찾거나 조건으로 검색을 하기는 용이하지만 별도의 DB하드웨어를 필요로 하고, DB 장애에 독립적이지 못한 문제를 가지고 있다

이를 보완하기 위해서 LOG WRITING하는 방식에 대해서 고려할 수 있는데, JMS 서버를 이용하여 비동기적으로 LOG WRITING하는 방법을 고려할 수 있다. 이 때 JMS의 메세지를 FILE에 저장할지 메모리에 저장할지도 고려해야 하는데, 업무상 감사(AUDIT)요건이 있는 중요한 로그는 JMS File store를 이용하여 저장하고 중요하지 않은 로그는 JMS Memory Store를 이용해서 저장하는 방법이 있다. (Memory Store의 경우 성능적 우위에 있지만, JMS 서버가 RESTART될 때 메모리상의 데이터가 유실되는 문제가 있다.) 

거래로그는 EAI의 필수적인 요건중에 하나이지만 IO를 유발하기 때문에 성능에 가장 큰 영향을 주는 부분으로 세밀한 설계와 검증 과정을 필요로 한다.

(2)  에러 처리 로직 (Error Hospital)

에러 처리 로직은 모니터링 요건과 더블어 EAI의 또다른 필수요건이다.에러 처리 로직의 요건은 장애 감지, 장애 원인 리포팅, 장애 해결 3단계로 이루어 진다.

모든 종류의 장애를 신속하게 감지해야 한다. 특히 B2B거래의 경우 회선 장애에 대한 감지 능력이 보강되어야 하고, 장애가 발생하였을 때 장애 원인을 추적할 수 있도록 그 내용이 리포팅 되어야 하고, 장애 내용에 대해서 해결할 수 있는 절차를 갖추어야 한다

장래 해결 방식은 여러가지로 분리할 수 있는데 장애에 대한 처리 정책을 Fault-Policy라 하고 인터페이스마다 정의하여 인터페이스별로 장애를 처리할 수 있도록 한다

이렇게 장애가 발견되고 리포팅이 되면 모든 장애 내용을 한곳에 모아서 위에서 언급한 Fault-Policy에 따라 처리하는데 모든 장애가 모이는 곳을 Error-Hospital이라고 정의한다

(3)  장애 처리 정책

앞에서 정의한 에러 처리 로직 (Error-Hospital)에 모인 장애 들은 장애 처리 정책에 따라서 처리가 되는데, 일반적으로 크게 아래와 같이 4가지 정책으로 정의할 수 있다.

Policy

Description

Note

Ignore

Simply ignore the fault and purge message.

 

Report

Report the fault. Optionally send notification message (Email,IM,SMS etc)

 

Retry

Automatically retry the transaction with specified time after specified sleep time

After failing all of retry, next error handling policy definition is required.

Manual

handling

Report the fault and let user select policy described above

 

무시하거나(Ignore), 장애 내용을 관리자에게 알리거나 (Report), 자동으로 재시도 하거나 (Retry), 또는 Work list등에 추가하여 관리자가 에러 처리를 수동으로 하도록 하는 방식이다.

인프라 기능

거래이외에 공통적으로, 처리해야 하는 기본적인 기능들이 있다.

(1)   트렌젝션 처리

EAI 프로젝트에서 통상적으로 10~30% XA 기반의 분산 트렌젝션 처리를 사용하는 경우가 있다. 양쪽에 거래에 대한 장애시 거래 데이터가 틀려지는 것을 방지하기 위해서 XA를 사용한다. XA 사용은 시스템의 복잡도를 높이고 높은 수준의 테스트가 필요하기 때문에, XA 거래는 되도록이면 사용하지 않는 것이 좋다.

(2)   동적 배포

EAI 시스템은 24 x 7 으로 무정지로 운영이 되기 때문에 새로운 인터페이스가 추가 되었을때 EAI 시스템을 정지하지 않고 인터페이스 배포가 가능해야 하며, 장애가 난 인터페이스가 다른 연계 인터페이스에 영향을 미치지 않도록 내릴 수 도 있어야 한다.  인터페이스에 대한 동적 배포 기능은 EAI 시스템의 운영 관점에서의 필수요소이다

네번째 관점 EAI 프로젝트 개발 환경과 이행

앞에서도 몇번 언급했던 내용인데, EAI 시스템은 개발중에도 독립적으로 개발이 불가능하고, 다른 업무 시스템과의 연관성을 가지고 개발을 하기 때문에 개발 과정중에도 업무 시스템간에 인터페이스를 해줄 수 있는 시스템이 필요하다.


이를 지원하기 위해서 크게 3가지 환경으로 나눌 수 있는데, 다음과 같다.

분류

역할

참고사항

EAI 개발 환경

EAI 개발팀만 사용, EAI 시스템 자체에 대한 개발, 인터페이스 개발

 

EAI Staging

개발된 인터페이스가 배포되는 환경. 업무 개발 시스템과 연결되어 업무 개발 환경을 지원함

 

EAI Production

실제 운영환경

 

특히 개발환경에서 Staging 환경으로는 주기적인 업데이트가 일어나야 하고, Production 환경으로 옮길때는 별도의 이행 계획을 세워서 이행을 진행한다. (회선과 서버 연결점에 대한 고려가 필요함)

개발환경과 Staging 환경은 별도로 하드웨어를 분리할 필요없이 같은 하드웨어를 공유해서 사용해도 되지만, 필수적으로 두개의 환경을 나눠서 운영하도록 한다.

 

마지막으로 국내 EAI 프로젝트의 특이성

국내에 진출을 한 몇몇 EAI 솔루션 벤더들이 있지만 이 솔루션들이 국내에서는 그리 평탄하게 프로젝트를 진행하고 있지는 않은 것으로 알고 있다. 비즈니스가 없다는 말이 아니라, 제품의 고유 기능만 가지고 국내 EAI 고객의 요구 사항을 맞추기가 어렵고 이로 인해서 Custom 개발이 많이 발생한다는 이야기다.

국내 EAI 요건은 EAI 패키지들이 제공하는 기능에 비해 훨씬 높은 편인데, 몇가지 주요 특이 사항을 나열해 보면 다음과 같다.

 

Ÿ   Config 방식의 연계 선호

전통적인 EAI 솔루션은 GUI 기반의 개발툴에서 송수신 시스템을 연결하는 인터페이스를 구현하고 이를 EAI 시스템으로 배포하는 구조이다.

국내 EAI 시스템을 운영하는 사람은 대부분 개발자적인 소양보다는 운영과 업무 관점의 인력이기 때문에, 개발 기반의 EAI 연계를 선호하지 않는다. 단순히 웹 관리 화면으로 송수신 시스템에 대한 CONFIG 정보 만으로 연동이 이루어지기를  선호하기 때문에 별도의 연계 Config 화면을 구현할 필요가 있다.

Ÿ   변환 라우팅 보다는 연계에 초점

EAI 솔루션의 특징중의 하나가 송수신 중간의 Mediation에 상당히 자유로운 비즈니스 로직을 넣을 수 있다는 것인데, 변환과 라우팅들이 그에 해당한다. 그러나 국내 EAI요건은 필드간의 맵핑이나 간단한 변환만을 사용할 뿐 EAI 개발 도구가 제공하는 복잡하고 강력한 맵핑이나 라우팅은 사용하지 않는다.

Ÿ   높은 성능 요구치

국내 기업의 경우 고객과 기업의 IT 인프라가 상당한 수준으로 발전해 있기 때문에, 시스템에 대한 응답시간에 대한 기대치도 높고 많은 업무가 이미 온라인으로 처리되기 때문에, 초당 트렌젝션양(TPS)에 대한 요구 수준도 매우 높다. 그래서 변환이나 라우팅 같은 고급 기능보다는 단순한 맵핑 기능들만을 사용하면서 성능을 높이고자 하는 요구 사항이 많다.

Ÿ   비표준 전문 구조 사용

특히 대외 B2B 연계의 경우 ebXML등의 국제 표준 전문 형태를 사용하기 보다는 업체간의 협약을 맺어서 단순히 TCP 기반에 TEXT 타입으로 전문 표준을 맺어서 사용하는 경우가 많기 때문에 이 경우 전문 포멧을 핸들링하기 위한 아답터가 별도로 필요할 수 있다.

Ÿ   SOCKET 아답터

Legacy와의 연동이 WebService IIOP,RMI,EJB등의 표준 기술이 아닌 TCP Socket 기반의 연계 패턴이 종종 있다. Socket을 이용한 연동 부분은 EAI 솔루션에서 대부분 제공하지 않기 때문에, In/Out bound Socket 아답터에 대한 구현이 필요한 경우가 많다.

Ÿ   X.25 기반의 대외 연계

대외계(B2B) 거래의 경우 X.25 회선을 이용하는 경우가 아직도 많기 때문에, X.25를 지원하는 아답터가 필요하나 EAI 솔루션에서 제공하지 않는 경우가 많기 때문에 구현이 필요하다

결론

지금까지 간략하게나마 한국에서 EAI 프로젝트를 진행함에 있어서 고려해야할 몇가지 사항에 대해서 정리했다.

 국내의 EAI 환경은 시스템간의 연계 시나리오 자체는 간단하지만, 연계에 대한 비기능적인 요건 (성능이나 장애 처리)에 대한 기대치가 높고, 기술적인 난이도가 높은 시스템이 대부분이다.

 범용적으로 개발된 EAI 솔루션을 가지고 일반적인 소프트웨어 개발 프로젝트식으로 EAI 프로젝트를 수행한다면 십중팔구는 실패를 하거나 시스템의 안정성에 치명적인 결과를 가지고 오게 마련이다.

한국 EAI 시스템에 대한 고객 요구 사항을 적절하게 분석하여 EAI 솔루션 위에 한국 고객의 요건을 반영한 EAI 프레임웍의 개발과 EAI 프로젝트를 위한 개발 프로세스가 잘 정의되어야 복잡하고 난이도가 높은 한국형 EAI 프로젝트를 성공적으로 마무리 할 수 있다.

'아키텍쳐  > EAI' 카테고리의 다른 글

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (2) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21