Warning: Unexpected character in input: ''' (ASCII=39) state=1 in /webroot/libs/skin/post_widget_data.php(976) : eval()'d code on line 1 calmglow (최진호)

adsense(728_90)


SOA와 REST, ESB 하드웨어 Enterprise

나는 상당히 오래전부터 REST를 사용해왔고 그 가치를 이 블로그를 통해 언급해왔다. 그리고 실제로도 국내에서 이 REST가 부분적으로는 사용되고 있는 것을 알고 있다. 그럼에도 불구하고 이 REST표준이 전반적으로 산업계에 뿌리내리는 모습을 보이지는 못했고 해외 SOA관련 포럼을 가도 항상 끊이지 않고 설전이 계속되는 주제 중 하나가 바로 REST와 SOAP과의 가치에 대한 것이었다.
물론 REST가 굳이 SOAP과 싸울만한 기술은 아니라고는 해도 굳이 SOAP같은 무거운 프로토콜이 사용되지 않아도 좋을 경량화된 시스템에 무리하게 SOAP이 사용되는 것에 대한 반발심은 'Simple is beautiful'이라고 믿는 많은 엔지니어들에게 항상 재기되었던 것이다.
그런데 최근에는 상당히 긍정적으로 이 REST가 사용될 조짐을 보이고 있다. IBM같은 대형벤더가 SOA 관련 제품을 내놓으면서 REST지원을 내세운다던지, WSDL 2에서 REST description을 가능케 했다던지 하는 뉴스를 접하면서 이제는 REST가 충분히 엔터프라이즈 업계에서도 사용할 환경이 된 것이 아닌가 생각한다.


SOA는 특정 기술이 아닌 아키텍처이기에 이것의 접근과 적용을 도울 수 있는 다양한 제품이나 기술은 얼마든지 가능하다. 그 중에서도 좀 특이한 제품 및 기술이 있는데 다름아닌 ESB 하드웨어. ESB가 해야하는 기본적인 동적 라우팅과 변환, 다양한 프로토콜 지원 등과 같은 기본적인 미들웨어 기능을 왜 우린 항상 소프트웨어로만 하려 했을까? 더욱이 웹서비스와 같은 비록 표준이지만 적용하기에는 속도가 부담스러운 기술을 왜 굳이 소프트웨어로만 하려 했을까? 일반 PC에서는 비디오 가속을 위한 하드웨어도 별도로 나오고 그러는데 어째서 소프트웨어로만 SOA기반의 ESB를 적용하려했는지 다시 생각해보면 의아스럽기도 하다.
IBM의 DataPower는 이러한 기존의 고정관념을 깨고 하드웨어로 ESB를 구현한 제품인데 상당히 얼리어댑터적인 제품인것으로 생각되었지만 지금 미국시장에서는 일반 ESB제품 보다도 더 많이 판매되고 완전 대박을 맛보고 있다고 하니 알다가도 모를 일이다.
DataPower는 SOA적용할 때 가장 귀찮고 힘든 것중의 하나인 보안에 관련되어 특별한 개발을 하지 않아도 하드웨어 수준에서 알아서 필요한 보안관련 처리를 해주며 XSLT변환같은 부분도 소프트웨어가 아닌 하드웨어 수준에서 해버린다. 뿐만 아니라 다양한 Legacy들의 Function들에 대해서도 웹서비스화 시켜주는 것을 하드웨어수준으로 해버리니 비록 웹서비스 기반 미들웨어라고 해도 속도가 장난이 아니라고 한다.

공유하기 버튼

 

SOA 거버넌스(Governance)란? Enterprise

2006년 내가 모 회사 웹서비스 관련 프로젝트를 진행할 때의 이야기이다. 그 회사는 전사적으로 SOA를 적용하기 전에과연 어떠한 것이 자기들의 서비스 자산이 될 수 있으며 그것들이 웹서비스화 되었을 때 장점과 Value는 무엇인지에 대해검증해보기 위해 대고객 서비스 일부에 대해 웹서비스로 통합 프로젝트를 진행하게 되었다. 나는 그 프로젝트에서 초기 단계의웹서비스 기술 컨설팅을 담당하게 되었는데 개발자들과 작업하는 동안 기업이 웹서비스를 구축하고 그것들을 엮어내는 데 있어 기술적인 어려움은 하나도 문제가 되지 않음을 확인하였다. 워낙에나 개발 환경이 좋아지다 보니 기존 레가시 영역들을 웹서비스화하고 그것을 서로 엮는데 개발자들은 거의 반나절만으로 후딱 해치워버리고 말았던 것이다.

그렇게 효과적으로 웹서비스 기술 검증을 해 나가고 있었지만 문제는 다른 곳에서 불거져가고 있었다. 분명 기업 자산의 웹서비스화를 통해 얻게 되는 Value는 확실했다. 과거에는 Legacy들마다 서로 다른 프로토콜과 데이터 포맷등으로 인해 연계에 많은 시간이 소요되었고 실시간으로 서로 다른 정보를 공유할 수 없었던 한계가 있었던 반면에 웹서비스를 통해서라면 언제든지서로 다른 영역의 정보를 자유로히 접근할 수 있었고 새로운 연계 대상이 생겨나도 어렵지 않게 붙혀가는 것이 가능해졌다.

그러나 그러한 자유로움 이면에는 또 다른 위험 요소가 존재했다. 과연 이렇게 편리한 웹서비스가 기업내에 산재하게 되었을 경우 그 서비스들을 어떻게 누가 관리하고 책임질 것인가? 만약 이 웹서비스들에 보안 이슈가 발생하여 보안을 강화하게 되었을 경우각 서비스별로 보안 정책은 어떻게 세울 것이며 그 보안 관리에 따라 추가된 인증서 및 관리 체계는 누가 떠안을 것인가? 지금은얼마 되지 않는 영역끼리의 웹서비스 사용 환경이지만 이것의 활용이 높아졌을 때 자원 관리에 대한 문제는 누가 관리하고 누가 책임지고 진두지휘할 것인가?

SOA는 기업 내의 IT자산들의 연결을 보다 느슨하게 하여(Loosely coupled) 유연하게 만들지만 이러한 유연성이 결국 비즈니스 필요에 의해 자유롭게 연결됨으로 인해 업무적으로는 보다 긴밀하게 연결(Tight coupled) 됨으로 인해서 복잡도를 증가시킨다. 이러한 비즈니스적인 복잡도를 해결하기 위해 요구되었던 아키텍처 구조가 ESB와 서비스 저장및 검색서비스이지만 문제는 SOA가 가지는 이러한 복잡도가 단지 기술적으로만 해결될 수 있는 영역의 것이 아니라는 것이다. 앞서 설명했던 모 회사의 고민은 단지 복잡도를 해결하기 위한 기술 인프라가 아니라 보다 본질적인, 기업 내부에서 그것을 책임지고 관리하고 진두 지휘하는 Role을 가진 조직이 없으며 그것에 대한 정책 역시 마련되지 않았다는 것이다.

위와 같은 이유때문에 비교적 최근(?)에 SOA 거버넌스가 SOA진영에서 화두에 떠오르고 있다. 내가 굳이 거버넌스를'관리'라고 표현하지 않은 이유는 '관리'의 일반적인 뜻과 이 거버넌스의 의미는 다르고 이 의미를 이해해야 SOA거번넌스를이해할수 있기 때문이다.

SOA거버넌스가 어느날 갑자기 거버넌스라는 이름을 달고 나온 것은 아니다. ITIL및 ITSM부분과 맞물리면서 기업 내IT환경에 대한 거버넌스의 필요성이 최근 매우 증대되면서 자연스럽게 SOA 거버넌스라는 개념이 탄생하게 된 것이 아닌가 생각한다. 이 글에서 IT 거버넌스를 심도 깊게 거론하기에는 나 역시 내공이 부족하고 주제에 벗어나게 되므로 일단 간단하게 나마 일반적인 의미의 거버넌스와 관리의 차이와 IT거버넌스와 SOA 거버넌스의 관계등에 대해서만 짤막하게 거론하고 SOA 거버넌스에 대해 다뤄보도록 하자.


거버넌스와 관리(Maintenence)

내가 가진 Collins 영영 사전에 보니 govern과 management에 대해 다음과 같은 정의를 내리고 있다.

To govern a place such as a country, or its people, means to beofficially in charge of the place, and to have responsibility formaking laws....

Management is the control and organizing of a business or other organization. 

거버넌스는 사전적인 의미로 국가가 조직에 일정한 룰을 정하고 그것에 따라 책임과 롤을 정하고 그에 따라 일정 지역이나 조직의 부분들의 영역을 공식화하여 전체시스템을 통치하는 것에 초점이 맞추어져 있다면, 관리(Management)는 그렇게 롤과 책임이 정해진 상황에서 각각의 역할에 따라 조직등을 운영하는 것을 의미하는 것이다. 즉 이 글에서 언급하려고 하는 거버넌스라는 개념은 단순히 어느 조직의 구성원과 자원을 지키고 관리하는 개념이 아니라 그러한 관리가 가능하도록 조직 전체의 구성원과 자원들의 역할과 권한 그리고 책임을 명확히 규정하고 그 시스템이 정해진 룰대로 진행되는지 여부를 관장하는 것을 말한다. 이렇게 정의하고 보니 거버넌스와 관리의 개념은 리더와 관리자의 차이와 같은 구분점이 보이는 것 같다. 내가 거버넌스라는 용어를 한글화 하려 하면서 가장 적절한 우리말로 골랐던 것은 경영이었다. 경영이라는 의미에는 거버넌스가 함축하고 있는 조직 그 너머에 있는 시스템과비즈니스에 대한 관점이 잘 녹아있다고 본다. 자 그렇다면 이렇게 거버넌스와 관리의 차이를 구분할 수 있게 되었으니 IT거버넌스란 대체 무엇인지에 대해 알아보자.

"We define IT governance asspecifying the decision rights and accountability framework toencourage desirable behavior in IT" -Harvard Business School.

"ITgovernance is concerned about two things: IT’s delivery of value to thebusiness and mitigation of IT risks. The first is driven by strategicalignment of IT with the business. The second is driven by embeddingaccountability into the enterprise. Both need to be supported byadequate resources and measured to ensure that the results areobtained." -Board Briefing on IT Governance, IT Governance Institute

IT 거버넌스의 개념은 위에서 설명했던 거버넌스의 개념과 IT를 결합해서 생각하면 크게 무리 없는 개념이다. IT 거버넌스는 기업을 비즈니스관점에서 바라볼 권한과 책임을 가진 사람들이 IT를 보다 효율적으로 통제하고 관리하고 제어하며 그 방향을 제시할수 있는 방법을 나타내는 개념이다. 오늘날처럼 경쟁이 치열하고 복잡한 변화를 감내해야하는 기업환경에서 기업들은 보다 효율적으로 사람과 자원들을 충분히 통제할수 있도록 측정가능하고 관리 가능한 시스템을 원한다. IT가 기업에 있어 점점 중요해질 수 밖에없는 이유가 바로 여기에 있을 것이다. CRM이니 EAI, ERP등이 자꾸 나오면서 IT가 기업 혁신의 선두에 서는 이유가 여기에 있는 것이다. 그런데 이러한 IT가 혁신의 선봉에 설 수도 있지만 때로는 혁신을 가로막는 걸림돌이 되기도 한다. 기업통제를 위해 구축된 IT가 통제불능 상태에 빠질 경우 기업은 거꾸로 IT에 의해 정체되는 상황에 빠질 수도 있을 것이다. 물론 이러한 상황을 막기 위해 기업은 올바른 IT 인프라를 위한 프레임워크즉 아키텍처를 최대한 멋있게(?) 만들려고 노력하고는 있으나 기업이 그동안 간과하고 있었던 것은 그들이 IT자원 자체에만 충실하려 했을 뿐 그것이 운영되고 관리되는 사람과 권한 그리고 정책에는 별다른 관심을 가지지 못했다는 것이다. IT거버넌스는 IT와 관련된 결정을 내릴 수 있는 올바르고 적절한 사람에게 권한을 주고 비즈니스 담당자들이 IT자원과 권한별 결정들의 이행사항을 수치화된 형태로 통제할 수 있게 하는 시스템을 제공한다. IT 거버넌스는 특정 IT 결정을 내리는 것이 아니라 그러한 결정이 내려질 수 있는 구조적인 권한과 역할을 기업 시스템에 제공하고 결정에 따른 결과를 책임지게 하는 것이다. 


상당히 어렵게 IT 거버넌스를 설명하고 말았지만 결국 IT 거버넌스는 우리 주위에 있는 것이다. 애플리케이션 운영팀,네트워크팀, 개발팀 등등 기업 IT자산의 목표를 세분화해서 각 팀별로 권한과 권리를 나눠논 것. 그게 바로 전통적인IT거버넌스라고 할 수 있는 것이다. 그렇다면 SOA 거버넌스는 무엇인가?


SOA 거버넌스 정의



(작성중)

공유하기 버튼

 

Composite Business Services(CBS)에 대하여 Enterprise

손정의의 '감성의 승리' 중에서 그의 발명에 대한 지론을 보면 다음과 같다.

"발명에는 세 가지 패턴밖에 없다는 것입니다. 하나는 문제 해결법입니다. 세상에 어떤 문제가 있다면 그것을 해결하면 되는 것입니다. 둘째 수평적 사고법입니다. 이것은 둥근 것을 사각으로 해 본다든지, 하얀 것을 빨갛게 해 본다든지, 큰 것을 작게 만들어 본다든지, 어쨌든 다른 방향으로 생각하면 됩니다. 셋째는 조합법입니다. 예를 들어 라디오와 카세트를 조합하면 카세트 라디오가 되고, 오르골(자명금)과 시계를 조합하면 자명시계가 됩니다. 그런 조합법입니다. 그런 식으로 자기 나름대로 패턴화하는 방법을 발견해서, 그것을 파고들어가는 것이죠. 이렇게 하면 아주 쉽게 발명의 힌트가 자꾸자꾸 나옵니다. 자신의 창조력을 자극하는 것이죠"

그가 발견한 발명의 패턴 중 마지막은 '조합법'인데 이 조합법이 IT기술에서 화두가 되고 있다. 바로 매쉬업이라는 단어로 말이다. 먼저 매쉬업에 대한 여러 사람들의 정의를 살펴보자. 

"업체들이 제공하는 공개된 기능들을 조합하여 새로운 서비스를 만들어 내거나, 자신의 서비스 기능을 더욱 풍부하게 발전 시키는 것을 매쉬업 이라고 하는데 (원래는 DJ가 2개 이상의 곡을 섞어서 하나로 만드는 것을 지칭하는 단어였다고 한다 : 웹 2.0 경제학 - 김국현에서 발췌)"

"It is sometimes created as a critique or commentary on an existing work or product. The tactic owes much to previous recombinant forms including: content repurposing, most notably by Kenneth Anger in his 1963 film Scorpio Rising; DJ mixing and culture jamming.

Content used in mashups is typically sourced from a third party via a public interface or API, although some in the community believe that only cases where public interfaces are not used count as mashups. Other methods of sourcing content for mashups include Web feeds (e.g. RSS or Atom) and JavaScript.

Many people are experimenting with mashups using Google, eBay, Amazon, AOL, Windows Live, and Yahoos APIs. Wikipedia에서 발췌"

" Mash-ups란 두개 혹은 그 이상의 곡을 섞는다는 뜻의 힙합(hip-hop) mixes라는 속어이다. 이들이 요즘 던지는 캐치 프레이즈는 바로 세개의 M(3Ms)이다: "Mix, Match, & Mutate" (섞어라, 서로 맞춰라, 그리고 변형시켜라). http://gatorlog.com/mt/archives/002316.html 에서 발췌"

 

이 렇게 웹 분야에서 매쉬업이라는 것이 붐을 일으키게 된 것은 ProgrammableWeb으로서의 웹의 진화에 힘입은 바가 크다고 할수 있겠다.즉 표준 기반으로 웹에서의 컨텐츠가 가공되고 제어할수 있는 환경이 제공되면서 이러한 서비스에 대해 재사용에 대한 욕구가 커지게 된 것이다. 매쉬업이라고 하니 상당히 새로운 개념인것 같지만 사실 이미 IT업계에서 재사용성을 높이기 위한 인터페이스, 프로토콜의 표준화에 대한 노력은 어제 오늘의 일이 아니지 않은가? Web 2.0 시대에 오게 되면서 B2C분야와 P2P분야에서 웹이 스스로 프로그래밍 가능한 인프라스트럭쳐로서 발전하게 되면서 이러한 붐을 타게된 것이라고 생각하면 사실 지금의 이러한 현상이 경험있는 IT엔지니어들 입장에서는 그렇게 놀랄만한 일로만 볼 것도 아닐 것 같다.

그런데 좀 더 이 현상을 IT엔지니어 입장에서 살펴보면 한가지 특징을 발견할수 있다. 흔히들 재사용 가능한 비즈니스 의미를 지닌 메소드에 대해서 컴포넌트라는 용어를 쓰지만 누구도 이 웹의 Open API를 이용한 서비스들에 대하여 컴포넌트라는 용어를 쓰지는 않는다. 왜냐하면 이것이 실제로 내부적으로는 컴포넌트라고 불리는 어떠한 구현물이라할 지라도 그것을 사용하는 사용자나 비즈니스적인 의미에서 보았을 때는 Open API에서 제공되는 것은 단지 서비스이지 컴포넌트의 관점에서 바라볼 필요는 없기 때문이리라. 

어 찌되었건간에 이러한 IT 자산들의 통신 표준화에 힘입어 이제 조금씩 서비스라는 용어의 대중화(?)가 진행되고 있다. 그 와중에 매쉬업이라는 단어와 유사한 용어가 SOA혹은 엔터프라이즈 세계에도 쓰이고 있다. 바로 Composite Application 혹은 Composite Business Service라는 용어다.

웹서비스 기술이 어느 정도 엔터프라이즈에서 적용하는데 있어 만족할만한 수준이 되고 이것을 넘어 SOA 및 ESB가 서서히 엔터프라이즈 진영에서 힘을 얻어가자 기업 입장에서 더이상 기존의 컴포넌트 수준에서 IT자산을 꾸역꾸역 만들어가는 단계를 벗어나 기업의 통일된 표준 인터페이스로서 이러한 IT자산을 서비스로 바라볼 수 있는 고지에 있는 현 시점에서 당연히 웹2.0의 매쉬업 흐름과 유사하게 기업 IT자산의 재활용성 측면을 진지하게 고려할 수 있게 된 것이다.

그냥 막연히 서비스라고 하니까 엔지니어나 아키텍트나 비즈니스 전문가가 서로 다른 관점에서 서비스를 바라보는 난처한 상황에 직면하고 IT관점의 서비스와 별도로 Business Service라는 용어를 점차 사용하기 시작하였으며 이러한 비즈니스 서비스들의 의미있고 가치있는 결합의 형태가 바로 Composite Application 혹은 Composite Business Service라고 할 수 있겠다.

예를 들어 다음 그림처럼 소매금융업종의 대출관련 업무의 Composite형태를 살펴보자.

기업의 IT자산들이 서로 엮여서 새로운 가치있는 비즈니스 서비스를 만들어내었다. 즉 Composite Business Service는 기업의 어떤 문제나 일을 수행하는 데 있어 필요한 여러 서비스들의 컴포넌트 묶음이다. 그러나 단순한 묶음이 아니라 '동적'인 묶음이다. 필요에 따라 얼마든지 묶음의 형태가 변화하는 것이 가능하다.

사실 이 Composite Business Service의 정의를 이렇게 내렸지만 이 새로와 보이는 개념에 대한 보다 명확한 요건에 대한 설명이 필요하다. 즉, 어떤게 Composite Business Service로서 이름 붙일 수 있겠느냐 하는 것이다.

이 Composite Business Service(CBS)의 가장 큰 특징은 Loosely coupling의 극대화라고 할 수 있게다. 이제까지 이 느슨한 연결의 정의는 다양하게 쓰였다고 볼 수 있겠으나 CBS에서 말하고 있는 느슨한 연결의 특징은 'Who'와 'How' 그리고 'What'에 대해 극대화된 느슨한 연결을 지향한다는 점이다. 즉 어떠한 사용자가 이 서비스를 사용하느냐에 대해서 추상화 및 비즈니스 정의화 하고 이 서비스를 어떻게 사용할 지그 행위에 대해서 역시 추상화하며 이 서비스가 최종적으로 어떤 구체적인 서비스를 사용할 지에 대해 다시 추상화하여 이 세가지의 요건을 충족시킬때 CBS라는 비즈니스 서비스가 탄생할수 있다고 보는  것이다.

이러한 CBS의 개념이 최근에 여러 컨설턴트나 벤더등에서 회자되기 시작하면서 또 다른 비전을 제시해주고 있는 것으로 보인다.

참고문서: http://www-128.ibm.com/developerworks/webservices/library/ws-soa-composite 외 다수

공유하기 버튼

 

WBSF(Websphere Business Service Fabric)와 IT의 미래 Enterprise

Fabric은 2002년도에 설립된 Webify라는 회사에서 만든 제품으로서 IT를 활용한 biz agility를 목적으로 만들어졌다.이 제품은 CBS(CompositeBusinessService) 라는 각 industry별로 특화된 기 정의된 SOA 자산등을 활용한 비즈니스 컴포넌트를 활용하여 비즈니스 업무를 컴포넌트화 하는 것을 강조하고 있다. 2006년에 IBM으로 인수되면서 WBSF라는 이름(WebSphere Business Service Fabric)으로 core엔진은 바뀌었고 CBS자산들은 industry CBS라는 이름으로 명칭을 유지하게 되었다.

SOA 의 장점이라고 하면 흔히들 time to market을 들고 governance한 비즈니스 환경을 강조하지만 실제로 SOA를 기업에서 갑자기 적용하려면 수많은 시간과 노력과 비용이 소모된다. 그렇게 해도 어떠한 것이 진정 SOA의 value이며 자기들이 이룬 것이 정말 이전에 비해 더 나은 time to market 가치를 이루었다고 확신하기에는 많은 어려움이 따른다. IT벤더와 컨설팅업체들은 기술적인 value와 경험적인 value를 줄 수 있다고 장담하지만 그들에게 한 회사의 장기 전략을 맡기는 것이 너무나 부담될 뿐더러 정작 중요한 것은 자기들이 자기들의 비즈니스 업무에 대하여 IT화하는 데 있어서 기업의 장기 전략이나 기업 자산들을 제대로 꿰뚫고할수 있는 역량을 가진 사람이 기업내에 그리 많지 않다는 것이다.즉, SOA로 나아감에 있어 기업의 입장에서 부담이 되는 것은 IT적인 전문가나 제품을 넘어서 비즈니스에 대한 IT화에 대한 부담이고 정량화되고 잘 모델링된 업무이다.

Fabric은 SOA환경에서 각 industry별로 공통되어 자주 쓰이는 여러 비즈니스 서비스들을 엮어놓은 비즈니스 서비스 컴포넌트들을 제공한다. 단순히 비즈니스 모델링이나 메타데이타만 제공하는 것이 아니라 그것이 운영되고 관리되고 재 설계될 수 있는 IT환경까지도 아예 제공해준다. 즉 SOA로 차근차근 가기 힘든 고객들에게 원샷 원킬로 모든 필요한 부분들을 biz 부터 IT까지 아울러서 제공하는 종합선물 세트라고 볼 수 있겠다.

아무튼 이 Fabric은 내부적으로는 WebSphere Application Server, WebSphere Process Server, WebSphere Integration Developer, WebSphere Registry and Repository등을 포함하고 있으며 이것에 더하여 풍부한 Governance를 위한 기능을 내장하고 있다. 윈도우에서 한번 돌릴려고 하면 추천 사양이 ram은 기본이 3GB라고 한다.

이 Fabric이 당장에 국내 기업에서 적용될 수 있을지 아니면 이 제품이 먼 미래에 새로운 이름으로 인기몰이를 할 지 그것은 알 수 없겠으나 적어도 이 Fabric등은 우리의 5년 앞의 Enterprise의 모습을 보여준다는 측면에서 매우 의미가 있다. 이제는 IT의 IT비즈니스 업무도 컴포넌트화 되어가는 것이다. 이를테면 어느 대부호가 국내 국민은행같은 큰 규모의 은행을 갑자기 온라인으로 만들고자 한다면 타 은행이 몇십년에 걸쳐서 이룩한 IT자산을 이러한 Fabric등의 제품을 가져와서 금새 구축할 수 있는, 메뉴판에서 비즈니스를 고르면 IT가 금새 만들어주는 그런 세상. 그렇게 먼 미래의 모습이라고만 단정할 수는 없다고 생각한다. 적어도 Enterprise업계에서 밥벌어먹고 있는 개발자라면 혹은 운영자라면 한번쯤 이러한 enterprise업계에서 벌어지고 있는 변화의 흐름에 관심을 가져보는 것이 좋지 않을까?

공유하기 버튼

 

8회 자바 개발자 컨퍼런스를 끝내고.. Programming

JCO가 이제껏 해왔던 자바 개발자 컨퍼런스 중 이번처럼 계획적이면서도 참가자들의 호응을 이끌어낼 수 있었던 때가 없었다고 느껴질만큼 흡족했던 행사였다.
해마다 이 컨퍼런스를 갔다오면 수많은 영감과 함께 적어도 1년정도는 품을 수 있는 희망과 열정을 얻게 된다. 사실 이것이 가장 크다고 본다. 사무실에서, 인터넷에서만 기술을 접하다가 그것을 몇천명이 운집해있는 가운데서 접하고 서로 같이 토론하는 사이에 가지게 되는 감정은 비교할 수 없는 자극을 준다.
이번 행사에서는 주로 JCO 스탭들의 사진을 찍는 것에 초점을 맞추어 행사를 도왔다. 플래쉬가 없어서 빛조절에 상당한 난항을 겪어서 제대로 나온 사진이 많지는 않은데... 다음번에는 보다 나은 사진 기술과 장비를 가지고 사람들 사진을 찍어야 할 것 같다.

나는 주로 토론 트랙에서 행사시간을 보냈다. 자바 개발자 컨퍼런스에서 최초에 이 토론트랙을 시도했을 때 그 토론트랙을 준비하고 계획한 것이 바로 나였기에 애착이 있고 해가 갈 수록 토론트랙에 참여하는 사람들의 반응이 좋고 가장 자유로우면서도 동지들을 바로바로 만날 수 있는 기회이기 때문에 토론트랙은 앞으로도 자바 개발자 컨퍼런스에서도 내가 적극적으로 참여하는 트랙이 될 것이다.
그 토론트랙등을 통해서 calmglow가 느꼈던 몇가지를 술회해보고자 한다.

SOA 그 멀고도 먼 길
김민호씨가 얼결에 토론 제안자가 되었던 SOA관련 토론이 있었다. 토론트랙 1회때부터 그 분과 같이 토론을 해보았기 때문에 그래도 그분이 있는 토론이라면 다른 패널들도 SOA에 대해 어느 정도 내공은 있으려니 생각하고 참석을 했는데 참석자 특히 패널들의 SOA에 대한 인식의 수준이 가관이었다. SOA하면 그냥 웹서비스와 다를 게 없다고 생각하고 SOA에 대한 비관적인 미래를 이야기하는 이유가 그저 웹서비스간 상호운영성이 아직 부족하고 XML 데이타가 어쩌고 하면서 SOA는 그저 마케팅적인 이야기일 뿐이라고 이야기한다. 김민호씨와 나는 어안이 벙벙하고 어이가 없어서, 그동안 매년마다 토론트랙에서 SOA에 관련된 내용을 가지고 토론을 했었건만 여전히 SOA에 대해 서로가 다른 방향에서 바라보고 있으며 개발자가 비즈니스 IT아키텍처를 바라보기에는 역시나 멀기만 한 것인가 하는 생각을 하며 씁쓸했다.


그나저나 어서 개발자 컨퍼런스 사진을 올려야겠군.

공유하기 버튼

 

8회 자바 개발자 컨퍼런스 Programming

calmglow는 해마다 자바 개발자 컨퍼런스를 준비하는 JCO의 불성실 멤버이다.
이렇게 컨퍼런스가 다가오는데 다른 이들은 준비하느라 바쁜데 아무런 도움도 안주고 있음에 갑자기 미안해지다가 여기저기 홍보라도 막판에 해야겠다는 생각에 글을 쓰려는데, 예전과 다르게 이번 컨퍼런스는 일반 개발자 혹은 블로거들의 자발적 홍보가 많음을 느끼게 되었다.
그래도 국내에서 개최되는 수많은 컨퍼런스 중에는 자바 개발자 컨퍼런스만한 것이 없다는 생각을 한다. 물론 더 양질의 컨퍼런스를 요구하는 분들도 많지만 현실적으로 준비하는 사람들 역시 직업을 가지고 성실하게 일하면서 짬을 내어 컨퍼런스 준비를 하는 것이기 때문에 이 정도로의 규모만이라도 나는 대단하고 존경받아야 한다고 생각한다.
해마다 자바 개발자 컨퍼런스도 그 내용을 진화시켜나갔다. 한명의 강사가 일방적으로 내용을 전달하는 방식에서 탈피하여 매 회마다 조금씩 토론회의 비중을 높여갔으며 올해도 역시 수많은 논객들이 토론회에서 다양한 주제로 IT를 씹을 것으로 본다. 토론회에는 각 대형 벤더들의 유명한 엔지니어도 참여하여 SOA나 Web 2.0등에 대해 이야기할 것이다.
calmglow 역시 이 토론회에서 SOA관련 토론에 패널로 참여하게 되었다.
사실 자바 개발자 컨퍼런스를 해마다 기다리는 calmglow의 또 다른 이유는 뒷풀이에 있다. 행사가 모두 끝난 후 강사와 도우미 주최자와 여러 커뮤니티 개발자 혹은 지인들이 한데 어울려 밤새도록 술마시며 지난 1년을 돌이켜보는 그 시간이 이 바닥에서는 흔히 접할 수 없는 즐겁고 귀한 기회이기 때문이다.

공유하기 버튼

 

다시 SOA 시작 Enterprise

SOA 나 기타 등등의 기술을 사용하고 공부하면 할 수록 기초가 턱없이 부족함을 느끼고 있다. 다시 기초부터 차근차근 되짚어 나가기로 했다.

공유하기 버튼

 

이전 31 32 33 34 35 36 37 38 39 40 다음


Google Analytics