Blog | Tag | Local | Media | Guest | Login  RSS

28일날 "데브부산"이 주관이 된 세미나에 다녀왔습니다. 오랜만에 손영수님과 김용현님도 인사 드릴 겸사 겸사
갔었습니다. 뭐 결국 이건 시간상 얼마 못 뵈웠지만 말입니다.

세미나는 전체적으로 비교적 괜찮았습니다.

Web 2.0 의 경우, 그다지 개념을 잡고 있는 편이라 볼 수 없었는데, 조금 더 잡혔다 정도였습니다. 그나저나 중간에 나왔던 비디오 검색인 www.blinkx.com 은 꽤나 인상적이었습니다.
아키텍쳐나 기술적으로도 상당히 흥미가 가더군요.

두번째의 용현님 세션인 TerraServer는...흠...용현님에게 죄송합니다만... 솔직히 모든 내용을 이해하지는 못했습니다. 내용도 내용이지만 이게 왜 SOA와 Web 2.0과 연관 있는지를 이유를 찾지 못했습니다. TerraServer 자체는 그 자체만으로는 충분히 연구해볼만한 작품이긴 합니다만, 다만 세미나 전체의 주체와는 약간 거리가 있었던 발표가 아닌가 싶었습니다. Web 2.0과 SOA에 대한 적용 예제로서 발표하신 듯 한데, 내용이 너무 아키텍쳐와 주요 알고리즘으로 넘어가서 조금 아니다 싶은 생각이 들었습니다. 열심히 발표하신 용현님에게는 조금 미안한 감이 듭니다만...제 생각은 그랬습니다. 차라리 스프링노트 개발팀중에 한명 초청을 하여 기획,구현했던 경험에 대해 들었으면 휠씬 나았을 것이라는 생각이 듭니다.

세번째, 네번째는 영수님 세션이었습니다. 세번째 세션은 오랫동안 SOA에 대해 연구하신 분 답게 설명은 시원시원하고 좋았습니다. SOA 에 대해 조금 더 이해를 깊이 할 수 있었고요. 분산 객체 기술인 CORBA와 WS(XML Web Service), WS-* 기술, SOA 에 대해 연관성을 정리하는데 좋았습니다.

 그런데 쭉 보고 있으니까 SOA를 구현하는데 있어 과연 WS를 업계가 미는 이유가 무엇인가를 생각하게 합니다. - WS와 SOA 등에 대해서는 아직 초보라 잘 모른다고 생각하셔도 할 말 없습니다. 사실은 사실이니까요, 그냥 생각이 그렇다는 겁니다. 뭐 틀리면 할 말 없지만요 ㅎㅎㅎ -
 
 이 복잡한 WS-* 스펙을 개발자들이 전부 이해할 수 있을까 하는 생각도 들고요. WS-* ... 이렇게 까지 많은 스펙을 만들어낼 필요가 있었는가 하는 생각이 듭니다. 뭐랄까 꼭 EJB 같은 생각이 들었습니다. 게다가 구현도 구현이고 새로운 학습을 너무 많이 요구하는 것 같습니다. 아 예전에 WS에 대해 들을 때에도 약간 그런 생각이 들긴 했습니다만...이번에 보니 더 하군요 ㅡㅡ;
 
 REST 와 같이 현재 구조에서 조금만 더 나가는 것도 있는데, 대형 벤더들은 WS가 전부인양 시장이 흘러가는게 아닌가 싶기도 하고요.(최근에는 다른 모습도 보이긴 하더군요.) 하긴 돈은 그게 더 벌긴 하겠네요. 그리고 정말 복잡하고 정교하게 사용해야 할 분야는 WS와 ESB(맞나요? BPEL이 들어가는 그거 말입니다.) 쓰는게 맞겠고요.
  하지만 그런 경우를 제외하고는 REST와 같이 간단하고 이해하기 쉬운 개념들을 도입하는게 휠씬 나아보인다는 생각을 합니다, 레일즈의 ActiveResource를 봐서도 말이죠. 오픈마루 스프링노트에서도 - 서비스 성격이 그렇기도 하지만 - 웹을 리소스로 바라보는 시각으로 많이 작성하셨는데, 이게 상당한 효과를 거둔 것을 볼 수 있었습니다. 저번 루비 세미나에서도 이런 시각에 대해서 얘기를 좀 하셨는데, 정말 신선했습니다. 그걸 보고 생각해보니 WS와 같이 놓고 봐도 그렇게 접근해도 무리없다 싶었습니다. 이창신 님도 쓰신을 통해 이렇게 생각하신 듯 한데, 제가 맞게 받아들였는지 모르겠군요.

 EJB 도 제가 보는 시각이나 업계에서 몇몇 분들이 얘기하는 걸 봐서도, 정말 필요한 분야는 그리 많지 않고, 우리가 주로 대하는 많은 서비스들은 EJB 를 쓸 필요는 없다고 하시는 걸 많이 보았었습니다. WS 도 마찬가지가 아닐까요?
 
그리고 마지막 세션은 WCF 에 대해서였는데, WCF 에 대해서는 Indigo 란다 외에는 잘 알지 못했습니다. 아 닷넷 3.0부터 나왔다는 것도 있군요 ^^: 쭉 본 소감은 작성하기는 편할 것 같네...그리고 왜 그렇게 설정사항이 많은거지 그것도 XML로.. 너 Java 따라갈래? 였습니다. 물론 C# 이니까 어쩔 수 없는 선택이긴 하지만 요새 Java의 엄청난 XML Configuration 의 복잡함과 그에 대한 러닝커브 상승을 그대로 따라가는 듯한 느낌이여서 조금 씁슬했습니다. 과연 정말 그게 좋은 걸까요? RoR의 Convention on Configuration 의 철학을 보다보면 그게 정말 좋은건가 하는 생각을 한번 해봅니다.

뭐 세미나는 이 정도로 했고, 마지막에 다시 두 분과 마지막 인사를 했는데, 뒷풀이 가시는 듯 하더군요. 뒷풀이는 따라가기가 뭣했으니까 좀 그런데, 나중에 기회되면 여러가지로 다시 한번 고견을 듣는 시간을 가졌으면 하는 바램이었습니다.

마지막으로 손영수님, 김용현 님 정말 수고하셨습니다 ^^. 아 우상정님도 - 제가 잘 모르는 분이긴 하지만 - 수고하셨습니다 ^^

 

이올린에 북마크하기(0) 이올린에 추천하기(0)

 태그 : 
이 글의 관련글(Trackback) 주소 :: http://snaiper.tistory.com/trackback/249
BlogIcon 손영수| 2007/08/01 15:17 | PERMALINK | EDIT/DEL | REPLY
안녕하세요 손영수입니다. ^^
세미나에 찾아와 주셔서 감사합니다. 다음에는 꼭 술이라도 한잔 해야 겠군요.

약간의 핑계와 WCF나 SOA를 바라 보는 입장에서 약간의 대변을 하고자 합니다.
일단 용현님의 두번쩨 세션에 대한 안좋은 피드백이 발생한 것은 전적으로 제 책임인거 같습니다.
이 세미나를 기획하고 전체적으로 지휘한것은 저이기 때문이지요.제가 좀더 용현님과 유기적으로 대화를 나누고
동기 부여및 리허설을 해서 잘 다듬었어야 했는데, 어떻게 보면 저의 억지로 괜히 용현님에게 폐만 끼친것 같습니다.

일단 web 2.0에 대한 인식이 RIA로 치우쳐져 있고, 개발자로써 상대적으로 AJAX나 이러한 기술에 치우쳐 있어서
나름대로 경종을 울리기 위한 세미나를 만들기위해 노력했지만 잘 안된것 같습니다.

Web 2.0이라는 것은 구체적인 기술보다는 하나의 패러다임이고 이것을 대하면서 개발자들은 어떻게 이러한 것들을
대처해야 될지 내부저ㄱ인 애기들을 해보고 싶었습니다. Tagging으로 보여지지만 내부적으로 만든 Graph 이론들이
사용되고 있고, WEb 2.0으로 가면 갈수록 어떻게 과부화르를 분산할 것인지에 대한 애기들이 다시 이슈화 되고 있습니다.
Google File System의 내부 구조와 같은 맥락으로 TerraServer의 내부 구조를 만들고 어떻게 내부적으로 과부화를 나누어서 설계할수 잇는지 하나의 예를 보여 드리고 싶은 것이었습니다. 들으시는 분에게 충분한 동기부여가 되지 않은 상태에서 저만의 고집이 아니었나 싶기도 합니다. 용현님에게 다시금 죄송하다는 생각이 듭니다. 이부분은 이렇게 이해해주셨으면 합니다.

이슈 거리가 아닌 개발자로써 어떠한 측면을 가지고 시스템을 설계 해야 되는지에 대한 예를 공유하고 싶었을 뿐입니다. 다음에 좀더 동기 부여 측면들을 공유하고 진행하도록 하겠습니다.

기탁님이 WS에 말씀하신 이유는 아마 빅 밴더들의 힘과 기술의 성숙도가 멀었다는 것이지요.
초창기 Web Service가 CORBA의 복잡한 Application Service ( 현재 WS - *과 매우 비슷) 를 눌리기 위해
내세운 것이 SOAP (Simple Object Access Protocol)입니다. 간단하게 SOAP만 안다면 굳이 CORBA와 같이 복잡하지 않게 해도 사용할수 있다는 환상을 주었고 많은 분이 사용을 했습니다. 지금의 REST와 비슷한 이미지 였죠
단순히 프로토콜과 주고받는 메세지만 알면 된다는 애기였으니깐요.
하지만 결국 Service로 가기 위해서는 다시 이러한 것이 필요하게 되었다는 것입니다. Network 상황을 기반으로 한 상황이기 때문에 결국 다양한 QoS를 만족하기 위해 WS - * 으로 돌아올수 밖에 없었습니다. 그리고 SaaS 시장이나 Web 2.0과 조합이되는 SOA 형태인 Semantic Web Service로 흘러가면 갈수록 더 많은 QoS를 표현하기 위해서는 결국 복잡해 질수 밖에 없습니다. 나의 입맛에 딱 맞는 다양한 QoS를 REST로 만족시키기에는 한계가 있는 것이지요. 물론 간단한 것이 좋지만, 모든 요구사항을 만족할 경우라는 것이 기반 사실이 되어야 겠찌요.

또 하나의 이유는 원래라면 학계의 흐름대로 내가 원하느 서비스를 찾을수 잇는 한계 (UDDI의 키워드 기반의 검색)를 뛰어 넘어 무언가 새로 나오기 위한 시도들이 되어야 햇는데, 통합에만 치우쳐져 있는 대형 밴더들이 이부분을 거의 등안시 했다는 점입니다.
지금까진 솔직히 말하면 너무 공급자 위주의 내가 원하느 서비스가 여기 있으니 갖다 써라는 수동적인 입장으로 되었기 때문에, 어떻게 보면 Broker를 통해 내가 원하는 서비스를 찾는 사실도 안된 상황(어느 정도 내가 원하는 서비스의 속성을 알고 있는 상황)는 REST가 더 현실적이라고 생각이 듭니다. (현재 닷넷 프레임워크에서 REST를 지원하게 받아들여졌습니다.) 그러나 시간이 지나면 지날수록 Web 2.0과 계속 만남을 가지면서 사용자와 요구하는 서비스와 판매자가 생기는 시점에는 지금의 WS-* 보다 더 복잡한 구조가 나오지 않을까 쉽습니다.

WCF가 비 정상적으로 Metadata 지향적인 프로그래밍을 추구하는 스타일은 .NET의 흐름보다는 기존 분산 객체의 위치 투명성과 캡슐화를 보호하고 싶으면서도 QoS 부분의 변화를 보장하기 위한 어쩔수 없는 선택인거 같습니다. 만약 Metadata를 사용하지 않고 기본의 비지니스 로직과 보안 알고리즘이 합쳐져 있다면 보안 알고리즘을 을 변경하기 위해 소스코드를 바꾸어야 하는 상황이 발생하니 어쩔수 없는 선택이 아닌가 쉽습니다. 기본 서비스 로직은 변경될 가망성은 많으나 다양한 QoS와 계속 확장하는 WS - *에 맞추기 위한 선택이라는 점을 봐주시길 바랍니다. 세상의 모든 관계는 Trade-Off 관계이니깐요 ^^

그럼 수고하시고 언제든지 피드백 주시길 바랍니다. 저희가 이런 글을 봐야 더 다음 세미나를 잘 준비할수 있을거라 생각이 드네요 ^^ 감사합니다.~
BlogIcon snaiper | 2007/08/01 17:54 | PERMALINK | EDIT/DEL
^^ 안녕하세요. 먼저 본문과 가까운 길이로 답글 해주신 점 감사합니다. ^^ 이런 수준 높은 답글을 다시니 제가 어떻게 답글을 달아야 할지 정말 난감하더군요 ㅎㅎㅎ ..역시나 졸견일지라도 초보자려니 그렇게 여기시면 감사하겠습니다.

일단 2번째 세션에 대한 의도는 잘 알았습니다. 하지만 그다지 적절하지는 못했던 것 같습니다. 아예 별도의 주제를 잡았다면 어울렸을 것 같습니다만, 세미나 큰 주제의 범위를 보면 좀 넘어서지 않았나 싶습니다.

물론 내부적인 이론이나 부하 분산, DB 파티셔닝 등의 내용은 중요합니다. 게다가 개인적으로 개발자들이 그걸 몰랐다고 생각하지도 않습니다.

하지만 그 내용은 Web 2.0 이 아니더라도 중요한 내용인 것은 잘 아실 겁니다. 만약 주제가 "Web 2.0 서비스의 이론적인 접근과 실제 구현" 정도였더라면 아주 좋은 발표가 되었을 겁니다만, 그게 아니었다라는게 문제였습니다. 저도 왜 이게 세미나 주제와 조금 핀트가 다른지가 의문이었거든요. 주제와 관계없이 생각해봐도 2번째보단 마지막으로 옮기고, 영수님이 약간 뒤의 내용에 대한 설명을 해주는 시간이 필요했을 것으로 생각합니다.

말씀하셨듯이 개선하신다고 하니 앞으로 기대하겠습니다. ^^

그리고 WS에 대해서도 저의 졸견에 현명한 답변을 주신 것에 대해 다시 한번 감사드립니다.

먼저 첫번째 말씀해주신 것에 대해서는...네 다양한 요구들을 수용하려면 복잡해질 수 밖에 없다는 것도 공감합니다. 당연하겠지요. 그래서 본문에도 있지만, 완전히 쓸모없다고는 하지 않았습니다.
하지만 제가 EJB 얘기를 들었던 거도 그런데, 실제로 그 요구사항은 모두 요구하는데가 정말로 많겠냐는 것이었습니다. 그런 복잡한 요구 사항들을 모든 고객이 주지 않을것이라는 거죠. 실제로 필요한 것이 얼마나 될까요?
왠지 뭐랄까 그게 다 쓰일지 안 쓰일지도 모르는데, 너희들의 고민들은 다 안다는 듯이 스펙들을 쏟아내는 느낌입니다. 쓸데없이 러닝 커브만 계속 올라가고요.
WS-* 자체는 뭐랄까... WS-* 자체가 개발자들이 제시할 수 있는 솔루션의 모든 것이 되길 원한다는 느낌입니다. 마치 PL/1 처럼 말입니다.

물론 저도 REST 같은 기술들이 복잡해지길 원하지도 않고 복잡한 요구사항을 제시하는 곳에서 쓰이는 걸 생각하지도 않습니다. 제가 고민하고 의심하고 있었던 이유는 WS-*가 만능 툴로서 여겨지도록 되가는 것이 아닌가를 조금 경계하고 있는 것입니다. 이것도 벤더의 마케팅일까요?

그나저나 REST, 닷넷에도 포함되었군요. java 까지는 알았는데 ㅎㅎㅎ 그리고 지금의 WS-* 보다 복잡한 것은...좌절이군요. 뭔가 모든 것을 쉽게 처리할 수 있는 새로운 개념이 나왔으면 좋겠습니다. 마치 유닉스 파이프 같은 마법같은 개념 말이죠 ^^

그리고 마지막 WCF..네 그 선택 잘 알고 있습니다. 막상 저라도 그렇게 구현했을 수도 있을테니까요. 하지만 WCF의 설정을 편집하기 위해 다시 툴이 만들어질 정도라면 글쎄요. 과연 좋은 걸까 하는 생각이 듭니다. 자바와 같은 과도한 XML의 함정에 빠지지 않았나 하는 생각도 들고요.
차라리 컴포넌트를 조합할 수 있는 환경을 만들어 놓고 그걸 간단한 스크립트로 처리할 수 있도록 하는 것은 어떠했을까요? DirectShow의 필터 그래프 연결하는 개념과 툴을 도입하면 어떠했을까 하는 생각도 하고요. Ruby 진영의 경우 요즘에는 DSL(Domain Specific Language)가 대세입니다. 위에서 말했던 스크립트 도입이 이 DSL 개념을 도입하는거죠. 과도한 XML 사용으로 인해 러닝 커브의 가파른 상승과 해석의 난해함을 제공하기 보다는 다른 방법을 생각해보는 것은 또 어떠했을까 하는 생각입니다. 서울로 가는 방법이 하나가 아닌 것처럼 말입니다.

그런 점을 MS 개발자들이 생각해주었으면 하는 바람입니다. 이미 증명된 솔루션이긴 하지만, 그렇다고 너무 많이 따라가는게 아닌가 해서 한 말이었습니다.

여튼 앞으로도 세미나 많이 열어주세요. 특히 부산에서 ㅎㅎㅎ 열심히 참가하고 좋은 피드백 드릴려고 노력해보겠습니다. 감사합니다.
BlogIcon 손영수| 2007/08/02 14:00 | PERMALINK | EDIT/DEL | REPLY
아마 오해의 소지가 있는 것들은 말로 풀어나가야 겠지요..

WCF의 MOP의 단점들은 생산성과 학습성등에 대한 문제를 해결하기 위해 Pattern & Pracitce에서 이미 Web Service Service Factory로 Add-in한 통합 툴을 제공하고 있습니다. 내부적으로 Metadata가 생성될뿐이지 대부분의 걱정하시는 바는 Service Factory에서 제공하는 툴들이 다 해결해 줍니다.
하나못해 Data가 Java와 호환이 되는지 까지 체크를 해준답니다. 언어보다는 이러한 툴로 생산성을 더 높히는 방식을 제공하고 있습니다. ^^ (Microsoft 3월 MSDN 세미나때 제가 이것을 다루었구요..) 뭐 이건 WCF가 아직 완성 버젼이 아니라 이제 Beta 2 단계이고 WCF에 부산에 세미나가 열린적이 없어 소개를 해드리지는 않았지만, 세미나땐 살짝 언질은 드린 부분입니다.

말씀하신 DSL은 WCF 라는 프레임워크 보다는
CORBA나 Software Factory에서 언급하는 Domain에 집중하면서 재사용성을 극대화 한다는 관점으로 받아 들인다면 Infrastructure단 보다는 Domain (의료, 항만등등)에 맞을거 같습니다. DSL의 용도가 좀 다른데 쓰인다고 할까요?

자세한 부분은 Software Factories라는 책을 참고하셨으면 합니다 ^^ 아마 이것이 Microsoft가 추구하는 전략입니다.

개인적으로 전 분산 시스템 Framework을 위한 DSL을 만드는 것보다는 대부분 편한 툴로 그리고 아주 아주 세밀한 제어는 XML Configuration Tool을 이용해 설정하는 것이 맞다고 봅니다. 이부분에 대해서는 나중에 따로 애기를 나누도록 하시지용. 역시 글로는 끊이 없이 주고 받아야 될거 같아용.

WS-*은 지금 현재로는 쓸데 없는데 너무 많아지는 것이아니냐 인데.
이문제는 예전부터 CORBA 부터 쭉해서 WS - * 처음 나올때 부터 제기 되었던 것입니다.
그리고 EJB 같은 분산 기술과 SOA의 대안이 되기 위한 WS는 와는 약간 출생이 달라 비교대상이 되기는 힘듭니다.
CORBA와 WS는 비교할수 있어두요.

Web Service를 단순히 분산 객체로 본다면 Rest가 현실 적인 대안이겠지만, 이건 관점의 차이라고 할수 밖에 없습니다.
실제 REST가 많이 쓰이는 것도 Interoperability로 치우쳐 있고 Meshup으로보는 곳에서 많이 쓰이고 있습니다.

하지만 Componet 뒤를 있는 Service라는 패러다임으로 볼때.지금 WS - * 으로도 모자란 느낌입니다.
그래서 이러한 부족함을 매꾸기 위해 Semantic web과 결합된 기술까지 나오고 있는 것이지요..

WS - *이 불필요하다고 보이는 부분은 아마도 Web service를 단순히 통합의 기술로 보고 현재까진 통합위주로 사용되기 때문입니다.

하지만 SaaS가 앞으로 계속 폭발적인 성장세를 보일거라는 Gartner에 대한 보고에 의하면 더 Spec이 나왔으면 나왔지, 줄어들지는 않을겁니다. 그리고 SOA라는 패러다임에 완벽한 대안이 되기 위해서는 더 빈틈없이 지원을 해야 됩니다.

그리고 WS - *을 개발자가 다 알아아 할 필요가 없다는 것입니다. 그건 마치 우리가 C의 함수 라이브러리를 사용하기 위해서
내부가 라이브러리 내부 하나 하나 소스롤 다 보는것으로 비유될수 있습니다.

내가 당장 Security에 Transaction만 쓰면 그건에 관련된 기술들만 보면 되고 어떠한 큰 기술이 있는지 흐름만 알면 됩니다. WS - *은 업체들의 표준안이지 개발자들에게는 단순히 Plug-in(SUN의 WSIT)이나 Channel(WCF)로 제공되고 있습니다.
개발자들이 실제 WS- *을 다 살펴볼 필요는 없습니다. 더 나은 WS - *을 만들기 위한 개발자라면 모를까요? 더 나은 WS - *을 만들기 위한 노력은 학자와 업체에서 해야 되는 일이지요 ^^

실제 SOA의 성장 곡선에 보자면 몇명 아는 업체들끼리 시스템을 통합하는 단계를 넘어
외부로 서비스를 노출하고 거래하는 단계로 간다면, 더욱더 REST보단 WS - *으로 더 기울여 질겁니다.

WS - * Spec은 빅밴더들의 시장 선 점유라는 점은 적극 공감합니다.
솔직히 말해 Semantic web service나 ebXML은 거의 찬밥신세인 걸로 보자면요 ^^ 돈을 버는 쪽이 힘을 지배하니깐요 ^^
이상으로 저의 의견을 피력했습니다. 굉장희 길어지는 군요 ^^;; 충성~~
BlogIcon snaiper | 2007/08/02 15:00 | PERMALINK | EDIT/DEL
역시나 고견 감사합니다. 항상 장문으로 답을 주시나 저도 꽤나 부담스럽군요 ㅎㅎㅎ 별로 안되는 지식에 반응을 드리려니 참 힘듭니다 ㅎㅎㅎ

WCF의 그 문제점에서는 툴이라 .. 다행입니다. 어디까지 구성되는지는 직접 찾아봐야 하겠지만 허술하게 추상화가 안되었기를 바랍니다. 아직까지 제가 본 모든 툴을 추상화가 꼭 깨질 때가 있어 결국 다 알아야 할 수도 있는 상황을 꼭 만들어 냈었으니 말입니다.
제일 간단한 예로 MFC 클래스 위자드가 그랬었죠.

그리고 DSL 에 대해서는, 네 그런 용도가 더 맞다고 할 수 있습니다. 하지만 WCF 설정 또한 DSL 의 영역이 아닐 수는 없지 않겠습니까? 과도한 설정의 함정에 빠지지는 않을런지 경계하고 있는거지요. DSL 영역에 대해서는 서로 생각이 다른 듯 합니다 ㅎㅎㅎ
다음 기회에 생각나면 한번 토론해보는 시간을 가져보는 것도 괜찮을 듯 합니다. DSL 말고 더 좋은 방법이 나올 수도 있겠지요.

그 다음에 말씀하신 WS와 EJB 의 비교는 제가 말씀드린 의미는 기술적인 측면에서의 비교가 아닙니다. 약간 오해하신 듯 합니다. 제가 EJB를 말씀드린 이유는 매우 복잡해지는, 때로는 만병통치약 같이 마케팅되는 기술에 또다른 예일 뿐입니다. 제가 드린 말이 충분치 못했던 모양입니다 ^^

그리고 다음 내용은 글쎄요. 아무래도 제가 생각하는 서비스의 정의가 모자란 모양입니다. 아니면 다르거나요. 저는 새로운 의미의 분산 컴포넌트처럼 생각해왔는데, 오해가 있는 모양입니다. 이렇게 생각하는 저로서는 REST로서도 어느 정도의 규모에서는 모자란다는 생각이 들지 않거든요. 조금 더 깊이 생각해보는 시간을 가져봐야 할 듯 합니다. 좋은 내용도 많이 듣는 시간도 필요하겠고요.

그리고 WS-* 를 개발자가 다 알아야 되는건 아니다는 말씀은 완전히 동감하기는 힘듭니다. 어떤 기술이든 잘 알고 잘(효율적으로) 사용하기 위해서는 반드시 그 전체를 알아야 되는 경우가 많았습니다. 닷넷은 단순히 쓰기 위해서는 말씀대로 프레임워크 전체를 알 필요가 없지만 효율적으로 쓰기 위해선 전체를 다 알아야 했지요. 솔직히 IL 같은걸 알 필요가 없지 않을까요? 컴파일러 제작자들이나 알면 되지요. 하지만 닷넷 고급 책들은 몇 권 보니 이에 대한 내용을 다루고 있더군요. 그 외에도 C++ 최적화의 예도 그렇고, 그리고 OS 동작이나 하다못해 IOCP도 그랬습니다. 지금 현재는 확실히 다 알 필요가 없을지 모릅니다. 하지만 어느 정도 기술이 성숙하고 널리 받아들여지는 시기에는 결국 다 알아야 될 필요성이 제기될 것으로 생각합니다.

그리고 마지막으로 WS-* 성장에 대해서는...그럴 것이라고 충분히 예측합니다만, 저로서는 어떻게 될지 모르겠습니다. 좋은 기술들은 항상 빨리 받아들여져서 순식간에 퍼졌었는데, 아직 그렇지 못하다고 느끼고 있으니까요. ㅎㅎㅎ 여튼 한번 기대는 해보겠습니다.

그나저나 SOA와 WS-* 전문가이신 손영수님에게 조그마하게나 응답을 드릴려고 하니이거 정말 힘든걸요? ㅎㅎㅎ ^^::: 역시나 답글이 길어져 버렸습니다. 그냥 글로 쓰고 트랙백으로 달 걸 그랬나요? ^^: 그리고 마지막에 충성하시니 저도...필~승! 입니다
BlogIcon 손영수| 2007/09/08 04:30 | PERMALINK | EDIT/DEL | REPLY
안녕하세요 기탁님 ^^
참고로 도움이 될 만한 글입니다.

http://www.davidchappell.com/blog/2007_07_01_weblog.html

David Chapell 이 쓰신 글이구요.
아무래도 REST vs WS - *에 대한 애기들을 종식시킬만한 글을 잘 정리해서 마소에 기고할 생각입니다.

좋은 주말 되세요 ^^ 충성~~
BlogIcon snaiper | 2007/09/10 13:16 | PERMALINK | EDIT/DEL
그래도 약간 동감안가는 거리가 있긴 하네요. Chapell 얘기도 그다지 동감 안가는 구석이 있다는...조만간에 정리해서 댓글 달죠
BlogIcon snaiper | 2007/09/12 19:16 | PERMALINK | EDIT/DEL
http://blog.naver.com/only2u4u/120042234093
글에 댓글 달았습니다. 결론은 비슷한 얘기인듯 하지만
뭔가 미묘하게 다른 듯 합니다.

ps. 다른분들을 위해...궁금하시지는 않겠지만, 혹시나 해서 URL까지 적어놓았습니다.
Name
Password
Homepage
비밀글 (Secret)