제가 이글을 쓴 이유는  저의 아이디와 패턴의 남용에 대해서 같이 언급하셔서, 큰 상처를 받았습니다. 제가 패턴쪽으로 많은 활동을 하고 있었는데요.

직접 대화를 나누어 오해를 풀었습니다.

저를 향한 글인줄 알았습니다.  직접 대화를 통해 그것이 아니었음을 알았습니다.  제가 너무 민감하게 대했던것 같습니다.

toby님에게 모욕을 당했다는 말은 정중히 사과하겠습니다.

다행히 toby님과 대화는 매우 산뜻하게 끝나고, 심지어 여러가지 mission을 주셨습니다. 🙂

이번 논쟁은 결국 몇분이 말씀해주신것 처럼, 각자가 느낀 도메인의 경험의 차이 그리고 생각의 차이라고 이해해 주셨으면 합니다.

디키 님의 말처럼 반론을 다는것 보다는 다시 저의 의견을 말씀 드리는 것이 올바른 글쓰기라고 생각하여 다시 글을 씁니다.

Ripple Effect (파문효과)에 대한 생각들..

제가 CORBA를 Ripple Effect가 발생하는 한 예로 설명을 드렸습니다. 굳이 CORBA가 아니라도 분산 객체를하신 분이라면 Ripple Effect때문에 많은 고생을 하십니다.

CORBA는 IDL에서 여러가지 기반 코드 (proxy, stub, marshaling/unmarshaling, narrow 등..)를 생성하게 되고  이 생성된 코드에 추가하는 방식을 적용합니다. 그렇기 때문에 하나의 인터페이스가 추가되거나 약간의 데이터 구조가 변경되더라도 그 여파는 결국 여기저기로 미칩니다.

그리고 현재 Web Service들 역시 약간 Approach를 변경했지만, 역시 Ripple Effect를 외면할수 없습니다.  여기서 Approach를 변경했다 함은 IDL과 같은 중간 매개어에서 코드를 생성하지 않고 실제 여러분이 작성한 로직들을 파싱해서 역으로 적절한 코드(위에서 언급한 proxy, stub 등+WSDL)를 생성하게 됩니다.

굉장히 예전에 CORBA에 비해 굉장히 휼룡한 방법입니다. 결국 개발자가 중요시 여기는 것은 자신의 로직이고 Ripple Effect를 줄이자는 피드백을 받은 경우죠. 하지만 아직 Ripple Effect가 완전히 사라진 것은 아닙니다.

현재 Web Service는 이기종간에 완벽한 통신을 상호연동성을 제공하지 못하고 있습니다.   결국 WSIT와 WCF 간의 연동 프로젝트가 그나마 상호운영성에 대한 골치 아픈 문제를 많이 해결해 주고 있을 정도이죠.

파문을 일으킬수 있는 하나의 돌맹이가 숨겨져 있습니다.

바로 Data 이죠. WCF에선 이걸 DataContract라고 하는데 결국 내가 만든 DataStructure를 WSIT가 이해하는지 또한 역으로는 이해하는지 검증을 한 다음에서야  그 다음 단계(Operation, Service)를 진행할 수 있습니다. 현재 Web Service 에서도 결국 파문 효과는 그대로 남아있습니다. 거기다 배포한 클라이언트 코드를 재 배포해야 되는 것은 당연하구요.

그럼 왜 이렇게 파문 효과를 내포하며 분산 객체는 발전하게 된걸까요?

그 이유는 바로 위치 투명성 (Location Trasnparency) 때문입니다. 결국 분산객체에 설계 철학은 프로그램을 사용하는 개발자가 마치 Client쪽 코드같이 사용하는  추상화를 변화의 유연성보다 더 중요시 여겼기 때문입니다.

물론 이러한 문제를 해결하기 위해 Dynamic Invocation이라는 기법이 있긴 하지만, 성능 적인 문제로 역시 사용시 많은 것을 고려해야 합니다.

제가 말하고 싶은 것은 적절히 Concern을 나누는 것은 너무나 많은 요소들을 고려해야 된다는 것입니다.

SoC는 아키텍팅의 가장 핵심이 되는 Key입니다.

문제는 적절한 사이즈로 나뉘는 것은 그리 쉽지가 않은 것이고 단순히 확장성 이외에도 , 배포, 성능과 같은 다양한 QoS를 고려해야 된다는 것이며, 이것이 다양한 이해 당사자들이 얽혀있으면 그야말로 시스템 설계를 위한 SoC가 아닌 이해당사자들의 요구사항을 만족시키기 위해 SoC까지 해야되는 상황이 지금 현실의 프로그램들 입니다.

우리가 한번 Version을 내고 다음 Version을 준비만 하면 되는, 즉 Beta로 들어가면 새로운 요구사항을 더이상 받아 들이지 않고 안정화 작업만 할수 있는 Applicaiton 을 구축하지 않는한, 변화의 여파는 계속 우리를 힘들게 합니다.  우스게 소리일지 모르겠지만, 지인중에 한분이베타에 베타를 만드는 상황을 저에게 열변을 토하기도 하셨습니다.

더구나 갑의 돈을 받기 위한 을의 입장에서는 말도 안되는 요구사항을 받아 들어야 하는 경우를 느낀 분도 있는 분도 계실듯 합니다.

SoC에 대해서 좀더 깊게 생각하실 분이 있다면, 좋은 글을 하나 발견했습니다.
Challenge problems for separation of concerns – http://www.cs.cmu.edu/~aldrich/papers/challenge.pdf

혹시 저처럼 SoC 를 하면서 고충을 느끼시는 분에게는 좋은 자료가 될듯 합니다. 읽어 보시면, SoC 하실때 도움이 될듯 합니다.

결국 자신의 경험과  다양한 시각차를 이해해 주시길 정중히 바랄 뿐입니다.

ps)

그리고 저나 반대쪽으로 글을 다신 분들에게.. 일단 서로의 입장을 이해해 주시길 정중히 부탁드립니다.  이것이 서로 상대방측에 더 이상 상처가 되지 않았으면 합니다. 여기서 그만 해주시길 정중히 요청드립니다.  더 이상 이 논쟁이 가해져, 커뮤니티 간에 싸움으로 까지 번지지 않길 바라고 있습니다.. 서로의 길을 열심히 걸어갔으면 합니다.

Frame효과라는 것이 있습니다.
저의 블로그를 통해 다른 두분의 글을 보신 분은 그분들을 안좋게 보실수 밖에 없고, 또한 저 역시 평소 Toby님이나 영회님의 블로그 애독자분들이 저의 블로그를 보면 저를 안 좋게 보실수 밖에 없습니다.
디키님이 말씀하신 것처럼 양측간에 더 이상의 피해는 원치 않습니다.

어느 분의 말처럼 고개를 숙이고 살때니, 너그러이 이해해 주시길 바랍니다. 감사합니다.