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


Archive»


 
 

조직을 관리하는 방법


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


해당글은 https://www.coursera.org/learn/fundamentals-of-management/outline 코세라 강의를 정리한 글입니다.


management function이라고 정의되어 있는데, 딱히 한글로 번역을 하기가 어려워서 (관리 기능..?? ) 리더가 일하는 방법 정도로 정리를 한다.
리더 또는 매니져가 일하는 흐름에 대해서 설명해놨다고 보면 되는데, 크게 아래 그림과 같이 다섯개의 과정으로 정리 된다.




먼저 계획 단계.해야 할 일과 목표를 정의하고, 필요한 소요되는 리소스를 산출한 후에, 환경과 리스크 그리고 대안을 정의하는 계획 단계이다.
다음은 Organize 단계로, 계획을 수행하기 위한 틀을 만드는 단계로 볼 수 있다. 일을 수행하기 위한 조직 구조를 디자인 하고, 프로젝트에 대한 플랜을 수립하고, 필요한 사람들을 연결해놓고, 프로젝트에 대한 수행 프로세스를 정의한다.
이렇게 수행하기 위한 틀이 만들어졌으면, 이 틀안에 내용물을 쏟아 넣어야 한다. 이를 Staffing 단계라고 하는데, 쏟아 넣는 내용물은 사람이 된다. 필요한 역할별로 사람을 뽑아서 배치한후에, 이 인원들이 제대로 일하게 해줘야 하는데, 비젼을 심어주고 목표를 명확하게 해주며, 교육등.. (한마디로 사람관리) 하면서 일을 하는 단계이다.
일을 진행을 하면, 이 일이 잘 되는지 모니터링 하는 단계가 그 다음단계인데, 장애를 제거 하고, 진행 상황을 체크하며, 계획에 문제가 있는 부분을 보정해가면서 프로세스를 보강해 나가는 단계이다.
쭈욱 나열이 되어 있는 것을 정리해보니, 실제로 일하는 방법과 비슷하다. 실제 관리를 잘하고 일을 잘하는 사람들은 저 프로세스대로 일을 하는 듯 싶다.
반대로 일을 잘 못하는 리더나 매니저는 저기서 상당 부분을 빼먹고 그냥 “do it!!”만 열심히 외치는듯



린 스타트업의 프로세스 개요

일단 현재 이해한것 까지 중간 정리, 린스타트업은 도요타의 린 방법론을 기반으로 IMVU CTO인 에릭리스가 정리한 스타트업의 프로세스이다.

기본적으로 스타트업의 제품 및 서비스 개발의 행위를 학습으로 정의하고 있으며, 빠르게 최소한의 기능을 가지고 있는 서비스를 빠르게 개발하여 시장에 릴리즈한 후 고객의 반응을 수치화한 데이타를 기반으로, 판단하여 이를 기반으로, 제품의 개발 방향이 맞는지를 학습하여 끊임없이 서비스를 수정/개발해 나가는 프로세스이다.

전체적인 프로세스를 도식화 하자면 다음과 같다.


※ 이 그림은 일반적으로 소개되는 린스타트업의 프로세스가 아니라, 본인이 이해하고 내용을 가감한 프로세스이다.

 



가설과 구현


먼저 가설을 세우고, 이 가설(아이디어)를 기반으로 서비스를 개발한다. 이때, MVP (Minimum Viable Product)이라는 개념을 사용하는데, 컨셉을 구현하기위한 최소한의 기능만을 가지고 있는 제품(또는 서비스)를 정의한다.

일반적으로 고객은 자신이 무엇을 원하는지를 잘 모른다. 소프트웨어 개발에서 요구 사항 분석이 실패하는 이유중의 대부분이 고객이 요구 사항을 제대로 정의하지 못하기 때문이다. 왜냐? 고객도 무엇을 원하는지를 모르기 때문에, 그렇지만, 고객은 자기가 좋아하는 것과 좋아 하지 않는 것에 대한 구별할 수 있는 능력은 있다. 그래서, MVP를 가지고 고객에게 제시하면 그때 부터 고객은 그 제품이 좋은지 나쁜지에 대해서 이야기할 수 있고, 그 피드백을 기반으로 제품을 개선할 수 있다.

제품이 개선될것을 전제로 하기 때문에, 커다른 덩치 큰 제품을 만들지 않는다. 다 만든 다음에, 나중에 그 방향을 바꾸게 되면, 다 만드는데도 많은 시간이 소요될뿐더러 만든 다음에, 전체 기능을 폐기 하게 되면 그 비능이 크기 때문이다.

MVP 부터 시작해서 고객의 피드백과 반응을 통해서 제품의 방향을 유연하게 설정하면서 고객이 만족할만한 제품을 진화적으로 만들어 나간다.


지표의 정의와 측정


고객의 피드백과 반응을 수집하고 이를 제품에 반영하려면, 이를 수치화 즉 지표화할 필요가 있다. 지표화를 하기 위해서는 무엇을 지표화 해야할지를 결정해야 한다.

서비스 기능 추가 개선후, 가입자 수가 증가 했는지? 아니면 서비스 사용 시간이 늘어났는지? , 어떤 작업을 했으면 그것이 어떤 효과를 나타내는지를 정량적으로 수치화해야 한다.

일반적으로 스타트업이 실패하는 이유중의 하나가, 이 정량화를 기반으로한 측정을 하지 않거나, 적절하지 않은 지표를 정했기 때문인 경우가 많다. 이를 허수지표라고 하는데, 이 허수 지표에 대해서는 뒤에서 다시 언급하도록 한다.


1) AB 테스트

지표 측정 방식에서 효과적으로 활용할 수 있는 추가적인 기법중의 하나가 AB 테스트이다. AB테스트는 같은 서비스를 두개의 고객군을 나눠서 A고객과 B고객에 서로 다른 기능을 제공하여 그 피드백을 살펴보는 방식이다.

신규 기능을 개발했을때,  새로운 기능을 무조건 운영 시스템에 반영을 하는 것이 아니라, 일부고객군에게만 적용한 후에, 그에 대한 반응을 정량적으로 측정한 후, 반응이 좋은 경우에만 그 기능을 운영시스템에 전체 반영하는 기법인데, AB 테스트를 위해서는 먼저, 여러개의 고객군에 서비스를 차등 제공할 수 있는 개인화 기능이 제공되어야 하며, 또한 기능 구현시 마다 배포를 할 수 있는 자동 배포 (Continues Delivery : aka. CD) 프레임웍이 준비되어야 한다.

그리고, 각 테스트 표본집단 별로 신규 기능에 대한 고객 반응을 측정할 수 있는 리포팅 시스템 개발이 전제되어야 한다.

자동화나 리포팅 시스템은 이러한 AB 테스트를 효율적으로 할 수 있는 도구에 불과하다. 무엇보다 중요한것은 AB 테스트를 위한 표본 집단의 선출 방식과, 고객의 반응을 어떤 지표로 정의할 것인가가, 가장 중요하다.


 2) 빅데이타 분석

린 스타트업 프레임웍에서 가장 중요한것은 가설에 대한 테스트 결과를 지표를 통해서 분석해야 하는 것인데, 이를 위해서는 데이타 분석이 필요하다.

단순히 정형화된 데이타를 수집해서 간단한 리포트만을 뽑아내는 것이 아니라, 방문로그,체류 시간, 광고 집행 시기, 마케팅 시기등 다양한 소스에서 오는 데이타에 대한 상관 관계 분석을 통해서 지표를 재정의 및 발전 시켜 나가야 하는데, 이를 위해서는 향후 분석과 데이타에 숨어있는 상관 관계 분석을 위해서 가급적 많은 데이타를 저장할 필요가 있다. 이런 많은 데이타를 정재되지 않은 상태로 저장하기 위해서는 큰 데이타 저장소가 필요한데, 이러한 개념은 과거의 데이타 웨어 하우스와 유사한 data lake 라는 곳에 데이타를 모으고, R등의 데이타 분석 언어를 이용하여 데이타에서 지표를 산출해내고, 이를 리포팅 시스템을 통해서 뽑아낼 수 있다. (이구조에 대해서는 이전 포스트 http://bcho.tistory.com/984 를 참고하기 바란다.)

결과적으로, data lake 나 리포팅등 지표를 확인할 수 있는 통계 시스템이 필요한데, 기존과 데이타의 양이 틀리기 때문에, 빅데이타 기반의 분석 시스템은 린 스타트업 프레임웍에서 대단히 필요한 부분이 된다.

그렇다고 스타트업에서 Spark,Hadoop, DW와 같은 고급 기술을 기반으로 대규모 분석 시스템을 만들 수 는 없는 노릇이고, 가급적이면 처음에는 구글 애널러틱스나, 클라우스 SaaS또는 PaaS형태의 데이타 분석 시스템을 이용하여, 유효 지표를 뽑아내서 사용하는 것이 더 바람직하다.


결국은 학습의 반복


린 스타트업의 핵심 프레임웍은 학습이다. 가설을 세우고 가설을 테스트하고 검증한후, 가설이 틀린 부분을 수정해나가면서 고객의 needs를 알아가는 학습의 과정이며, 회사의 비지니스 모델이 무엇이 적절하고, 어떤 기능이나 서비스가 핵심인지를 계속해서 배워나가는 학습의 반복이다.

새로운 이벤트, 새로운 기술을 넣는 것이 아니라, 이러한 지루한 반복을 통한 학습과 개선을 통해서 서비스(제품)을 개선해나가고 가치를 부여하는 과정이 스타트업이 아닌가 싶다.

※ 린 스타트업 책에서는 제품 개발에 대해서의 학습을 강조했지만, 인사나, 팀 문화, 재무 까지 스타트업에서는 학습의 반복이 아닐까 한다. 처음부터 모든 부분을 알거나 해당 분야에 대한 전문가를 영입해서 사업을 시작할 수 없는 만큼, 스타트업 기업이 성장해감에 따라 회사 경영에 대한 부분도 계속해서 학습하면서 만들어 나가야 한다.

다만, 이 학습은 계속 되고 학습에 따라 회사가 발전해나가야 하지, 이 학습이 목표와 방향성을 잃고 학습이 정체되는 순간, 스타트업은 퇴락의 길을 걷지 않을까?

 

혁신 회계와 지표


앞서 설명한 지표에 대해서는 조금 더 깊게 생각해볼 필요가 있다.


혁신 회계                              


린스타트업에서는 혁신회계라는 재미있는 개념을 소개하는데, 전통적인 기업이 매출과 손익이라는 금전적인 지표를 회계의 지표로 삼는데 반해서, 린 스타트업의 혁시 회계에서는 금전적인 지표 보다는 서비스 성장을 판단할 수 있는 지표를 회계의 지표로 삼는다.

이는 아마도, 스타트업의 모델이 대부분 성장 후에, 상장, 매각, 유료화등의 다양한 출구 전략을 선택하기 때문에, 출구 전략전 사업을 확장을 주요 지표로 하기 때문이 아닌가 싶다. 실제로 대부분의 서비스 기반의 스타트업은 가입자수나 액티브 사용자 수 또는 LTV (Life time value : 사용자당 평생 기대 수익)등을 기반으로 가치를 평가 받아서 투자를 받거나 상장을 하는 모델이기 때문에, 이러한 혁신 회계 지표가 오히려 적절하지 않은가 한다.


지표의 개념이 없는 스타트업


많지는 않지만, 가끔 스타트업의 시스템 구조를 진단 해주다보면, 이런 혁신 지표를 정의하지 않고 경영을 하는 경우가 많은데, 초반에는 그럴 수 있다고 치더라도, 이는 위험한 방식이 아닌가 싶다.

지표에 대한 개념이 없이 수~수십억의 마케팅 비용을 집행하면서, 마케팅을 통한 사용자 유입률이나 사용시간 증가분을 측정하지 않는 등이 대표적인 예인데이는 투자 대비 효과에 분석 준비 없이 비용을 집행하기 때문에, 잘못하면 효과없이 소중한 비용만 낭비하는 결과를 일으킬 수 있다.

앞에서도 설명하였듯이, 린 스타트업 프레임웍에서는 아이디어가 제품화/서비스화 된 결과에 대한 측정을 할 수 있는 유효 지표를 정의하는 것이 선행되어야 한다.


허수 지표에 대해서


그러면 이러한 지표 정의에 있어서 가장 경계해야할것이 허수 지표인데, 예를 들어서 설명하자 A사의 서비스의 가입자수가 꾸준히 늘어나고, 1억 이상의 가입자를 가지고 있다고 할때, 이 서비스가 성공적인 서비스일까? 지표상으로 봤을때는 그럴 수 있다.

그러나 몇가지 현실적인 가정을 만들어보자, A사는 핸드폰을 만드는 회사이고, 음악을 들려주는 앱을 단말이 판매 될때 이 서비스를 프리로드하였다. 그리고, 핸드폰을 초기화할때 이 서비스가 자동으로 가입되도록 하였다. 그렇다면 이 서비스를 실제로 사용하지 않지만 가입한 사용자 수는 많아지게 되고, 가입자 지표는 많지만 서비스가 실제로 사용되지 않기 때문에, 이 지표를 기반으로 1억 이상의 가입자를 처리할 수 있는 시스템을 확장하는 등의 비용이 투자될 수 있고, 또한 사업이 잘된다는 착각에 빠질 수 있다. 가입자 수 보다는 사용자의 재방문율 또는 주별 사용시간등을 측정하는 것이 오히려 현실적일 수 있다.

또 다른 허수 지표의 예를 들어보자, 스마트폰 유료앱을 판매하는 서비스라고 할때, 판매되는 라이센스 수 만 측정하면 될까? 끼어 팔기나 정치적인 원인에 의해서 라이센스가 판매되는 경우는 비지니스에서 흔한 케이스이다. 1000만 라이센스가 판매되었다고 하더라도, 그중에 실제로 사용되는 라이센스가 100만이라면, 이 사업이 제대로 가고 있다고 할 수 있을까? 제대로된 지표는 판매된 라이센스가 아니라 사용되고 있는 (액티베이션된) 라이센스이다.

이 밖에도 잘못된 지표를 양산 하는 경우는 많다. 광고나 이벤트로 인해서 반짝 가입자수가 늘었다가 사용자가 사용하지 않는 서비스등도 그러한 예에 속할 수 있다.

이렇게 일반적으로 생각할 수 있는 가입자 수, 라이센스 판매량등을 지표로 삼아서 사업을 꾸려나갈 수 있지만 실제로 사업에서 유효하 지표가 무엇인지를 제대로 판단하여 정의하고, 이를 기반으로 사업의 방향을 정해야 한다.

이렇게 사업의 진정한 가치와 동떨어지고, 잘못된 판단을 유발할 수 있는 지표를 허수 지표하고 한다.


결론


지금까지나마 간략하게 린 스타트업으 대략적인 프로세스에 대해서 살펴보았고, 그 중에서 가장 중요한 지표(혁신회계)에 대해서 살펴보았다. 무엇보다 중요한 것은 스타트업 서비스에 새로운 가설을 기반으로 한 서비스나 기능을 추가했을 때 이를 측정할 수 있는 지표를 정의하고 측정하는 것이 중요하며, 특히 이 지표 정의시, 스타트업의 성장을 제대로 측정할 수 있는 유효 지표를 정의하고 허수 지표를 제거하는 것이 중요하다.

아키텍쳐 설계 프로세스

아키텍쳐 | 2012.09.04 17:55 | Posted by 조대협

아키텍쳐

아키텍쳐란 무엇일까? 소프트웨어 시스템에 대해서 이야기 하다보면, “아키텍쳐가 어떻다”. “최신 아키텍쳐를 적용했다.” 등 아키텍쳐에 대한 언급이 많다. 그렇다면, 소프트웨어 아키텍쳐에 대한 정의는 무엇일까?

http://www.sei.cmu.edu/architecture/start/glossary/community.cfm 를 보면, 수많은 아키텍쳐에 대한 정의가 있다. 지금부터 설명하고자 하는 아키텍쳐에 대한 정의는 다음과 같다.

아키텍쳐는 비지니스 요구 사항을 만족하는 시스템을 구축하기 위해서 전체 시스템에 대한 구조를 정의한 문서로, 시스템을 구성하는 컴포넌트와, 그 컴포넌트간의 관계, 그리고, 컴포넌트가 다루는 정보(데이타)를 정의한다.”

또한 소프트웨어 아키텍쳐는 현재의 요구사항뿐 아니라 변화되는 비지니스 전략에 대응이 가능하도록 장기적인 로드맵을 수용하여 확장가능한 형태로 디자인 되어야 하며 가능하면, 구현 및 사용하고자 하는 조직의 기술 수준, 조직의 규모와 형태 그리고 비지니스의 형태에 맞춰서 설계 되어야 한다.

아키텍쳐 설계 프로세스



앞에서 아키텍쳐에 대한 정의는 끝냈다. 그렇다면 실제 아키텍쳐는 어떤 형태로 설계해야 할까?

비지니스 아키텍쳐 이해

아키텍쳐는 앞서 정의하였듯이, 비지니스를 성공적으로 이끌기 위해서, 만들어지는 시스템에 대한 설계다. 목적이 비지니스의 성공에 있기 때문에, 그 비지니스 자체가 어떤 목표,전략을 가지고 있는지를 이해해야, 목표에 부합하는 아키텍쳐를 설계할 수 있다.

아키텍쳐 설계 원칙 정의 (Architecture Principals)

비지니스 아키텍쳐가 정의되었으면, 시스템을 설계 하기 위한 테크니컬 아키텍쳐를 설계하기 위한 원칙을 정한다. 품질 속성이나, 기간, 조직 운용론, 기반 기술등 설계의 기본 사상이 되는 원칙을 정의한다.

시스템 아키텍쳐의 (System Architecture) 설계

설계 원칙이 정해졌으면, 비지니스의 요구 사항을 이 설계 원칙에 따라서 설계한다. 시스템 아키텍쳐는 크게 아래와 같이 3가지로 나뉘어 정의된다.

     애플리케이션 아키텍쳐 (Application Architecture) : 개발해야하는 애플리케이션 소프트웨어에 대한 아키텍쳐를 설계한다. 여기에는 컴포넌트의 정의, 컴포넌트 간의 관계, 특정 기능에 대한 컴포넌트간의 호출 흐름, 그리고 컴포넌트간의 통신을 위한 메세지에 대한 규격 정의를 포함한다.

     테크니컬 아키텍쳐 (Technical Architecture) : 애플리케이션의 배포 구조를 정의한다. 애플리케이션을 배포할 하드웨어의 구조와, 애플리케이션 개발에 사용하는 미들웨어 (DBMS, 웹서버등)등의 배포 구조를 함께 정의한다.

     데이타 아키텍쳐 (Data Architecture) : 마지막으로, 애플리케이션에서 다루는 정보(데이타)의 구조와 관계를 정의한다.

이 아키텍쳐의 설계는 기반 지식이 없는 상태에서는 설계가 어렵다. 물론 경험을 가지고 할 수 있겠지만, 참고할 수 있는 레퍼런스가 있다면 실수나 실패를 줄이고, 시간 또한 단축 시킬 수 있다. 참고자료는 CBD,SOA,EAI와 같은 일반적인 애플리케이션을 개발하기 위해서 패턴화된 아키텍쳐 스타일을 응용하거나, 유사한 도메인의 CASE STUDY (선행 사례) 기반의 아키텍쳐, 그리고 솔루션을 사용할 경우, 솔루션 제공사의 컨설팅 서비스를 이용하면, 매우 효율적으로 아키텍쳐 설계를 할 수 있다.


※ 많은 분들이 이 페이지를 방문하시고, 질문이 많으셔서, 상세한 아키텍쳐 설계 프로세스, 아키텍쳐의 정의, 아키텍트의 역할, 그리고, 대용량 시스템 아키텍쳐에 대한 글을 별도 문서로 정리하였습니다.   http://bcho.tistory.com/695


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) 추진 전략  (1) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21