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

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

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

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님이나 영회님의 블로그 애독자분들이 저의 블로그를 보면 저를 안 좋게 보실수 밖에 없습니다.
디키님이 말씀하신 것처럼 양측간에 더 이상의 피해는 원치 않습니다.

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

Join the conversation! 5 Comments

  1. SoC의 핵심은 요구분석정리라고 생각해도 되는건가요?
    그리고 Web-Service의 핵심은 Service가 가변적이다 라고 이해해도 되는건가요?
    Service가 가변적이니 반복적인 일들이 많이 발생할것 같은 생각이 듭니다.

    -덧붙이는 글-
    잘못 알고 있는 것이 있으면 지적 부탁드립니다.

    응답
    • 안녕하세요 lovewar 님
      아 좀 생각을 하게 하는 글이군요.🙂

      SoC의 핵심이라는 의미가 정확히 와 닿지 않습니다.

      혹시 말씀하시는것이 SoC를 어떻게 정하는 것이냐? 라는 의미로 파악하면 될까요?

      만약 그런것이라면. 프로젝트의 있는 요구사항들을 잘 수렴해, 어떻게 시스템에 각 요소별로 잘 배분할수 있느냐 라고 생각합니다. 아키텍팅의 KEY가 되는 것이죠.

      요구 사항 정리 + 아키텍팅 + 개발 + 테스트까지도 다 영향을 미친다고 볼수 있습니다. 🙂

      저의 경험으로는 Iteration 프로세스 형태로 개발하게 되면 SoC는 굉장히 변하기 쉽습니다. 물론 프로젝트의 특성을 타지만요.
      보통 프로젝트에 핵심이 되는 특별 관리 요소와 인프라성 Concern들을 먼저 구축합니다.
      초기에 중요시 여기던 Concern들이 그 다음 Iteration을 돌면서 피드백을 받거나 다른 Concern들과 실제 맞물리게 되면서, 정제 됩니다. 이때 변화가 발생하겠죠🙂. 그래서 몇번 Iteration을 돌면 초기 선택한 Concern들은 안정화가 되지요. 하지만 Iteration 뒷단으로 가면서 초기 Concern들이 변하게 되면 파급효과가 큽니다. 주의해야죠🙂

      Service가 가변성을 가지고 있다. 이건 프로젝트의 특성(이해 당사자) 에 따라서 좌우된다고 봅니다. 꼭 그런건 아니라고 할수 있습니다. 그리고 가능한 안 그러도록 노력해야지요. 가능한!!! 가변적이지 않게 이해 당사자와 잘 협의하는 것이 중요할듯 합니다.

      한번 구축하고 별로 진화하지 않는 프로젝트라면 별 문제가 없겠지만, 그리고 진화하더라도 정책상 기존의 Service를 Base로 나두고 추가하는 형태로 갈수도 있지만. 아닌 경우도 있을수도 있겠죠.🙂

      다만 배포된 Service가 변하게 되는 경우가 발생하면 상당히 귀찮게 되는 것이 사실입니다. 다시 Proxy를 다 배포해야 되고, 클라이언트쪽 코드도 변경해야 되니깐요? 물론 단순히 Web기반이라면 별 문제 없지만, EAI와 같은 곳에서 쓰이게 된다면 하나가 변경되면 그 파급효과는 클거라고 생각이 듭니다.

      답변이 되셨는지 모르겠네요.🙂

      응답
  2. 포스팅이 올리신걸 보니 반갑군요. 글에도 나타났지만 제가 배려심이나 동정심이 많은 놈은 아닌데 말이죠.

    잘못된 사례 인용이나 용어 사용의 폐해가 만연해 있어서 지적하려던 의도였는데 불편하게 해드려 죄송합니다.

    응답
    • 안녕하세요 영회님.
      이번 사건은 저에겐 충격적인 사건이었습니다.

      과연 무슨 잘못을 했길레, 그런 말을 들었어야 했을까… 많은 생각을 하게한 시간이었습니다.

      매우 힘든 한주였습니다.
      제가 적절하지 못하게 제목을 선정한 잘못도 있고, 저의 목적과는 다른 쪽으로 복잡성 애기가 흘러가기도 하고..
      여튼.. 이 기회로 SoC에 대해서 다시 생각할 수 있게 되었네요.

      다음에 훈수를 해 주실땐 좀더 따뜻한 대화로 부탁드리겠습니다.

      저 역시 부족하지만 제 길을 가겠습니다. 수고하세요🙂

      응답

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

카테고리

Articles, My Thinking, Software Architecture, Software Engineering

태그

, , , ,