ESB에 대한 잡담
당신은 ESB가 뭐라고 생각하시나요?
이름만 바꾼 EAI hub? 오옷. 딱이야. 이거 말고 ESB를 정의할 수 있는 것은 별로 없어 라고 생각하시는 분들이 대부분이 아닐까요?
근데 실제로도 ESB를 EAI hub처럼 쓰려는 분들이 많죠.
EAI 왜 쓰죠? 기존에 legacy들의 잡다한 프로토콜과 포맷과 산재되어 있는 자원 및 프로세스, 업무를 통합하기 위해 쓰잖습니까? 그런데 그렇게 구축한 EAI가 결국은 또 다른 legacy가 되어버리는 경험을 여러 갑 및 갑을 지원하는 을병정님들은 충분히 하셨을 거라 생각해욥. 뭐, 뭔가 어처구니없다고는 생각해도 어쨌든 이런것들을 현실적인 이유 때문이라도 통합은 해야겠고, 이를테면 3년이나 5년 주기로 이런 통합 이슈는 있다보니 주기적으로 EAI 비스무레한 것들을 진행하기도 합니다만, 이렇게 EAI가 자주 있는 것은 결국 EAI 프로젝트로 만들어진 게 또 다른 legacy가 되었다는 거죠. EAI의 진짜 목적은 이제는 제발 이런 통합 문제로 그만 골치썩고 그보다 높은 레벨의 것들을 걱정해보자인데, 여전히 현재 당면한 통합 문제 해결하기에 급급하죠. 이러니 IT가 아니라 DT(Data & Technology)다 라는 이야기가 나오는 겁니다.
그런데 ESB를 쓴다고 달라지나요? ESB를 EAI처럼 쓴다면 똑같죠. 제 아무리 대단한 ESB라도 기존의 EAI관점에서만 접근해버리면 이를테면,
‘어~ 소켓기반으로 legacy가 되어있구만 ESB가 소켓 지원해야지’
‘원래부터 hex binary 방식으로 되어있던건데 이거 포맷 그대로 유지해야 않겠어?’
아 예 여전히 데이타 중심적인 기업 데이터 통합 방식으로 문제 해결을 해버리고 있습니다. 좋습니다. 사실 속도 문제와 안정성 문제 이거 EAI에서 중요합니다. 증권쪽이나 은행의 일부 업무같은 경우야 뭐 어쩔 수 없다지만 이제는 표준기반으로 갑시다. 표준기반이란게 속도나 보안 문제에서 생각할 게 많다는 것은 알지만, 제 아무리 프로세스 통합이니, 비즈니스 프로세스 기반 기업 환경, RTE 외쳐보았자 IT가 여전히 데이타 통합만 신경쓰고 있다면 말짱 도루묵 아닐까요?
ESB가 그나마 기존의 EAI와 다를 수 있는 건 이러한 표준들을 제대로 지원할 수 있다는 데 있지 않을까 싶습니다. 아니 ‘그나마’라뇨, 사실 이 표준기반이라는 거 큰 차이죠. 표준기반이 구축되어야 비즈니스 프로세스 기반의 기업 IT환경, RTE 구축할 수 있습니다. 백날 RTE, EDA, SOA 떠들어 보았자 헛수고에요.
물론 성능이나 보안 문제 많습니다. 많고요, 성능이나 보안 문제 해결할 방법 제법 있습니다. 굳이 빵빵한 하드웨어 도입해야만 해결가능한 건 아니에요. 꼭 필요한 부분만 보안 해주고 정 안되는 거 legacy가 원하는 대로 해주고 그런 아키텍처 만들어주고 그래도 정 안되면 성능 가속기 얼마든지 있거든요.
2007년에 가트너라는 구라집단에선 2009년에는 대기업들의 대부분이 ESB를 도입할거라 합디다. 더구나 이렇게 구축한 ESB를 묶어가지고 federated ESB를 구축할 거라 예상하는군요. 가트너가 틀린 예측 어디 한 둘입니까? 하지만 이거는 어느 정도 믿어봅시다.
사실 제대로 된 비즈니스 프로세스라던가 EDA나 서비스 기반의 아키텍처라든가 어쨌든 간에 최소한의 비즈니스 의미를 지닌 서비스, 비즈니스 서비스가 존재할만한 공간은 ESB 밖에 없어요. 앗, 갑자기 어려운 용어들을 써버렸구만요. 하여튼간에 ESB가 비즈니스와 IT를 엮게 되는 시발점이 되리라는 것은 분명합니다.
집에서 만든 막걸리를 혼자 마시고 취해 끄적여 보았습니다.
댓글
Tuna · 2008/02/28 09:40
질문입니다. ^^
- ESB가 지원한다는 표준은 EAI도 다 지원하지 않나요? 그럼 툴에는 무슨 차이가?
- 오늘의 표준은 내일에도 표준일까요? 만약 모레에, 새로운 표준이 나온다면 그때에는 지금의 표준이 또다시 레가시가 되어 버리지 않을까요? 그렇담 ESB는 무엇을 해결한 것인가요?
Yozz · 2008/02/28 11:13
헉 술취해서 완전 엉망인 글이었습니다. 살짝 넘어가주심 좋은데. ㅜㅜ
Yozz · 2008/02/28 11:28
제 나름대로 답변을 드리자면,
- 그 표준이란게 데이터 표준이나 프로토콜 표준만을 의미하지는 않고요, 전사차원에서의 비즈니스 서비스화나 이벤트 인프라스트럭쳐 표준이라던지 등등 기업 내에 존재하는 자원들에 대해 보다 추상화되고 비즈니스적으로 의미있게 재사용될 수 있는 수준으로 사용하기 위한 인프라 표준등을 포함한다면 EAI와는 분명 다르지 않을까요?
- 스펙과 표준은 다르지 않을까요. WS-들은 스펙이지 표준은 아니죠. 오늘의 스펙은 내일의 스펙과 분명 다를겁니다. 하지만 표준은 오늘의 표준이 내일의 표준이 되도록 노력해서 만들어진 거겠죠. 아무리 WS-들을 구현했다고 표준기반이라고 볼 수는 없겠죠. ESB는 물론 이러한 스펙들을 최대한 준수하려하고 또한 이러한 스펙 위에 다시 표준을 만들어보려는 거겠죠.
죄송합니다.ㅜㅜ
Tuna · 2008/02/28 13:45
답변 감사합니다. 참고로, 태클 걸자는 건 절대 아니구요, 그냥 관심있는 주제라 얘길 해 보고 싶다고 생각했답니다. 아래 추가질문입니다.
말씀해 주신 표준이란게 현재 ESB에만 있고, EAI에는 없는 기능/개념인가요? 제가 말씀드리고자 하는 요지는, ESB던 EAI던 툴이 중요한 게 아니고, 그 위에 어떤 개념에서 어떤 것을 만들어 가느냐가 더 중요하지 않는가, 그렇담 굳이 ESB가 아니라 EAI툴이라도 별 상관 없지 않는가? 하는 것이죠. 바꾸어 말하자면, SOA의 특징은 툴이나 제품에 있는 것이 아니고 사고방식에 있지 아니한가? 하는 질문이죠. ESB와 EAI 툴의 기능상의 차이는 지극히 사소하고 그 보다는 어떤 컨셉에 기초한 제품인가가 더 중요하지 않나, 그래서 그 위에 어떤 시스템 구조를 만들어 가느냐가 더 중요하지 않나 하는 생각입니다. 결국 EAI랑 ESB랑 뭐가 틀리냐?라는 질문에 대한 답은 ‘제품상으로는 비슷하겠죠. 문제는 그 배경에 있는 사고방식입니다’ 정도의 대답이 어떨까 하는 …
물론 스팩과 표준은 다릅니다. SOA를 도입하려는 기업의 입장에서 표준이란, 어떤 스팩을 선택하느냐하는 것이라고 생각합니다. 즉, ‘서비스의 인터페이스는 웹서비스와 JMS로 한다.’라고 정의하면 그게 바로 표준이 되는 것이죠. 하지만 표준을 위와 같은 것으로 정의한다면 이제까지도 EAI 의 세계에서 여러가지 기업내의 표준을 만들어 왔을 것이고, 그 표준들은 그 시기의 기술의 트랜드를 충분히 반영한 것이었을 것입니다. 표준에는 물론 구현기술의 트랜드에 좌우되지 않는 상위 레벨의 표준과 구현기술에 좌우되는 하위레벨의 표준이 있겠지요. 하지만 SOA의 세계에서도 기술의 발전이 멈추지 않는 한, 하위레벨의 표준은 어차피 변해 가겠지요. 그럼 ESB도 그에 맞추어 바뀌어야 합니다. 그럼 결국 지금까지의 EAI와 무엇이 다르다고 할 수 있을까요?
제 생각에 위에 님이 하신 얘기들은 SOA보다는 MDA의 설명에 더 가깝지 않나 합니다. ESB의 예로, MDA에서 말하는 PIM과 PSM의 얘기를 하고 계신 듯 하다는 얘기죠. PIM을 비지니스 프로세스 및 서비스로써 정의하되, 서비스의 특징인 인터페이스와 구현의 느슨한 결합을 이용해서 PSM, 즉 구현기술의 변화로부터 (가급적) 자유로워지도록 하는 것.
그것이 혹시 님이 위에서 말씀하시려 한 내용이 아닐까요?
Yozz · 2008/02/28 16:25
오옷 저와 비슷한 결론입니다. 다른 일이 있어서 제 의견을 못드릴거 같고 이따가 추가로 답변드릴게요.