calmglow (최진호)

당신이 소위 인생컨설팅 회사의 사장의 입장이라고 하자. 누군가의 인생에 대해 조언을 하고 구체적인 조언을 하는 인생에 관련된 토탈 솔루션을 제공하는 회사의 사장이라고 할 때 당신은 일단 사람들의 인생의 중요한 순간을 나눠서 보다 세부적인 영역으로 구분하여 각각의 컨설턴트들을 배치할 것이다. 사람의 인생은 아마도 다음과 같이 보편적인 영역으로 나눌 수 있을 것이다.

그림 6. 인생의 Business Domain

이것이 바로 당신의 사업 영역이 되겠다. 이제 당신이 다시 결혼 부분에서의 전문 컨설턴트라고 해보자. 당신이 누군가의 결혼에 컨설팅을 하기 위해서는 어떠한 분야를 잘 알고 있어야 할까? 당신이 컨설팅해야할 보다 구체적인 영역을 나열해본다.

그림 7. 결혼분야 에서의 비즈니스 서비스

그림 7이 바로 컨설턴트인 당신이 실제로 고객에게 서비스해야 항목들이다. 상당히 추상적인 수준에서 그림 7까지 오는 동안 많은 부분이 구체화가 되었지만 아직까지도 실제로 각각의 서비스가 어떻게 고객에게 전달되는지에 대해 명확하지 않은 점이 있다. 여기서 다시 ‘결혼식’에 관련된 비즈니스 서비스 부분을 보다 구체화해서 세부적인 서비스 항목을 추출해보자.

그림 8.결혼식 비즈니스 서비스의 세부 서비스 컴포넌트

결혼식은 아무래도 당사자의 취향뿐만 아니라 가용한 금액에 따라 그 수준이 달라질 가능성이 있다. 따라서 컨설턴트는 고객의 잔고를 기반으로 하여 다양한 결혼 절차 프로세스를 미리 준비해야 하고 그에 따른 적절한 예식장을 선택하는 가이드를 제공해야한다. 이렇게 도출된 서비스들을 보다 세부적으로 그 기능별로 구분해보면 어떤 것이 서비스인지를 보다 명확하게 확인할 수 있을 것이다. 이 세가지 서비스를 기능별로 분류해보자.

그림 9.기능별 서비스 컴포넌트의 분류

당신은 지금까지 컨설팅회사 사장이 되어 때로는 컨설턴트가 되어 당신이 제공해야할 컨설팅 분야를 보다 세부적으로 분류하였고 결국 그림9에까지 와서 당신이 제공해야할 서비스를 더 쪼갤 수 없을 정도로 분류해내었다. 위로 갈수록 서비스는 보다 추상적이고 아래로 내려갈 수록 서비스는 보다 구체화되는 것도 인식할 수 있었을 것이다. 이렇게 서비스를 보다 잘게 잘게 쪼개어갈 수록 Granularity는 작아진다. Granularity란 우리나라 말로 ‘잘게 잘게 쪼개어진 정도’를 말한다. 이 granularity라는 개념은 상당히 다양한 용도로 쓰이고 있기 때문에 그것을 명확하게 무엇이다라고 설명하기란 쉬운 일이 아니다. 먼저 이것은 상당히 상대적인 개념이다. Granularity에는 Coarse-Grained와 Fine-Grained라는 개념이 있다. 이는 서로 반대되는 개념으로써 전자는 보다 더 뭉쳐져있는 정도를 말하고 후자는 보다 잘게 잘게 쪼개져있음을 의미한다.

당신이 컨설팅회사 사장이라면 당신이 주로 관심을 가지고 있어야할 부분은 그림 6과 그림 7정도의 수준일 것이다. 당신은 당신 회사가 집중해야할 사업 분야를 어떤 것을 해야할 지 그리고 각 사업분야에 최고의 컨설턴트들을 관리하는 것에 보다 관심을 기울일 것이다. 따라서 당신에게 필요한 Granularity는 상당히 추상화된, 상당히 Coarse-grained한 것들일 것이다. 반면에 컨설턴트는 그림 8이나 그림 9에 관련된 내용에 보다 집중하고 관심을 기울일 것이다. 그들은 실제로 고객에게 서비스를 제공해야하는 사람들이기 때문이다. 즉 컨설턴트들은 컨설팅 회사 사장의 View보다 더 Fine-grained하다는 것을 알 수 있다.

이렇게 Granularity라는 요소는 이것이 비즈니스인가 도메인인가 아니면 서비스인가를 판별하는 중요한 잣대가 된다. Granularity관점에서 보았을 때 비즈니스적으로 더이상 쪼갤 수 없을 만큼 쪼갠 상태의 것을 우리는 서비스 혹은 서비스의 컴포넌트라고 부른다. 위의 그림 9에서 당신은 여러 개의 서비스들을 찾아내었다. 결혼식 서비스에 포함되는 세부 서비스에는 크게 ‘결혼 절차’, ‘예식장 예약’, ‘잔고조회’ 서비스가 있으며 이것들은 각각 기능별로 서로 다른 특징을 가지고 있다. 먼저 ‘잔고 조회’ 서비스는 단순히 고객의 은행DB에서 고객이 소유하고 있는 잔고를 조회하는 단순한 조회성 업무이다. 이 서비스에는 별다른 로직도 들어가지 않고 그저 DB에 대한 내용을 투명성있게 응답해주는 기능만 있다. 주로 이러한 기능을 담당하는 것을 ‘데이타 서비스’라고 부른다. 반면에 ‘예식장 예약’서비스는 해당 서비스가 컨설턴트의 담당이 아니라 실제 특정 예식장과 연계되어 동작해야만 하는 서비스이다. 이렇게 외부 서비스와의 연계에 의한 서비스를 ‘Integration 서비스’라고 부른다. ‘결혼 절차’ 서비스는 이렇게 모여있는 서비스들을 묶어서 적절한 프로세스를 제공하는 서비스이다. 잔고가 500만원 이하라면 저렴한 예식장을 선택하고 그 이상이면 적절한 예식장을 선택하게 하는 프로세스를 생각해볼 수 있을 것이다. 이러한 비즈니스 프로세스가 제공되는 서비스를 ‘프로세스 서비스’라고 부른다. 그외에도 서비스에는 ‘기능(Function) 서비스’라는 것도 존재하며 이러한 기본적인 서비스들이 모여서 비즈니스적인 서비스들이 제공된다.

그렇다면 이렇게 비즈니스적인 부분에서만 서비스가 존재할까? 좀 더 구체적인 구현 수준으로 내려가면 어떨지를 살펴보자. 이번에는 당신은 A예식장의 담당자로서 A예식장의 온라인 예약시스템을 구현해야한다.

그림 10. A예식장의 예약시스템 구성도

그림 10은 A예식장 IT시스템 담당자인 당신이 구축한 시스템이다. Presentation layer에서는 예약에 필요한 사용자의 interaction을 처리할 것이고 Business Logic layer에서는 예약절차에 필요한 A예식장만의 비즈니스 로직을 처리하기 시작할 것이다. 더 밑으로 내려가서 Domain Logic layer에서는 보다 구체적이고 실제적인 데이타를 가지고 처리하는 컴포넌트가 들어있을 것이고 더 밑으로 내려가면 물리적인 데이타베이스가 존재한다. 여기서도 마찬가지로 Granularity는 위로 갈수록 Coarse-grained에 가깝고 아래로 내려갈 수록 Fine-Grained에 가까워진다. 즉 DomainLogic layer에서 다루는 것은 DB의 칼럼같은 보다 잘게 쪼개진 것들을 다루는 반면 Business Logic이나 Presentation layer에서는 예약이나 신용조회, 객석확인과 같은 보다 추상화된 부분들이 다뤄진다. 즉 그 잘게 잘게 쪼개어진 정도가 layer마다 다르다는 것을 알 수 있다.

그런데 아무리 이 시스템으로 Coarse-grained하게 추상화시켜본들 앞서 보았던 비즈니스 수준에서의 추상화 수준으로는 나아갈 수 없는 강한 결합적인 특성을 이 A예식장의 예약시스템에서는 발견할 수 있다. 즉 모든 컴포넌트들은 결국 Container에 종속되어 동작한다는 사실이다. 제 아무리 추상화된 예약이나 신용조회같은 프로세스도 결국은 그것을 실행하기 위한 Runtime에서의 Container나 프로토콜같은 물리적인 영역에 의해 종속된다는 것. 그것이 앞서 보았던 컨설턴트 회사의 시스템에 비교해서 보다 Fine-grained한 영역으로서의 특징을 보여준다고 할 수 있겠다.

그렇다면 Granularity를 결정하는 그 기준에는 무엇이 있을까?

그림 11.Granularity에 영향을 미치는 요소들

그림 11에서 보는 바와 같이 Granularity에 영향을 미치는 요소는 크게 추상화와 데이타 그리고 프로토콜 종속성, 컨테이너 종속성 정도로 볼 수 있다. 구현된 각 시스템들은 아무리 추상화수준이 높다하여도 컨테이너나 프로토콜 종속성 부분을 해결하지 못하기 때문에 비즈니스 서비스에 비하여 Service의 Granularity가 fine-grained한 특성을 가지고 있다.

그렇다면 어째서 Granularity를 이렇게 길게 설명하게 되었을까 되짚어보자. 앞서 ESB가 보다 높은 coarse-grained한 서비스를 위해 존재한다고 하였다. 즉 ESB는 개별 애플리케이션들의 직접적인 integration이 아니라 그보다 더 높은 수준에서의, 서비스 수준에서의 통합을 위해 만들어진 것이다. 그렇게 함으로써 그보다도 더 높은 비즈니스 수준에서의 요구사항에 보다 유연한 대처에 적합하게 만들어진 것이 ESB라고 할 수 있다.

그림 12.기업IT환경에서 ESB가 위치하는 곳

그림 12에서 보는 바와 같이 ESB는 위로는 Top-down방식으로 설계되어 만들어진 비즈니스 서비스를 담고 있으며 아래로는 상당히 물리적인 영역에서 부터 보다 추상화되어 bottom-up방식으로 끌어올려진 기술적인 function위주의 서비스들을 담고 있다. 이렇게 함으로써 ESB는 보다 추상화된 수준으로 IT자산들을 서비스위주로 관리할 수 있으며 위로부터의 변경된 비즈니스 요구사항을 보다 빠르게 조립하여 재구성하는 것이 가능해진다.

SOA는 결국 갈수록 변화에 대한 요구가 치열해지는 기업환경에서 기업의 비즈니스 전략의 변경이 실시간으로 IT에 전파되어 IT가 그 변화에 기민하게 반응할 수 있게 하는데 그 목표를 두고 있다. 때문에 비즈니스 관련자들 관점에서의 비즈니스 분석이 세부적으로 잘 모델링되어 있어야 하고 그것들이 결국 서비스로 도출되면 그 서비스와 실제 IT자산들이 유연하게 연결되어야만 가능하다. ESB는 결국 비즈니스와 IT를 유연하게 연결시켜줄 수 있는 대안으로 나온 것이라고 할 수 있겠다.

이제까지 ESB가 위치하고 있는 곳과 SOA 구현에 있어서 왜 꼭 필요한 것인지를 살펴보았다. 그렇다면 이제 보다 본격적으로 ESB가 갖고 있어야할 특징은 무엇인지 다음 포스트에서 살펴보자