패턴들을 자세히 살펴보면, 패턴 내의 컴포넌트들과 그것들의 관계가 항상 '원자적(atomic)'이지만은 않다는 것을 알수 있다. 어떤 문제를 해결하기 위해서는 패턴 내의 컴포넌트가 서로 밀접하게 상호작용해야 하며, 문제의 성격이나 그 문제가 발생한 상황에 따라 컴포넌트의 결합이 불가피할 수도 있기 때문이다.
이것은 패턴간의 관계에서도 마찬가지다. 패턴을 통해 어떤 문제를 해결하기 위한 과정에서 또다른 문제가 야기되기도 하고, 그 문제를 또 다른 패턴으로 해결할 수도 있기 때문이다.
이런 점들을 통해, 특정 패턴 내에 있는 컴포넌트들이나 그것들의 관계는 더 작은 패턴에 의해 서술될 수 있으며, 그것들을 포함하고 있는 더 큰 패턴에 통합될수도 있다는 것을 알수 있다. 실제로도 이런 패턴들은 변형되고 일반화되어 새로운 형태의 패턴으로 발전하기도 한다. [POSA1]

여기서는 가장 널리 알려진 패턴중 하나인 MVC(Model-View-Control)패턴과 그로부터 파생된 패턴들의 관계에 대해 다뤄보도록 하겠다.
― 이 글의 목적은 MVC 패턴과 그로부터 파생된 패턴들의 관계를 설명하는데 있다. 여기서 언급되는 각 패턴의 세부 내용은 다음기회에 다루도록 하겠다. ―


MVC(Model-View-Control) 패턴

MVC 패턴은 애플리케이션을 '프로세싱(processing)', '출력(ouput)', '입력(input)'의 세 개 영역으로 분리한다. MVC 패턴에서는 각 영역을 Model, View, Controller라는 컴포넌트로 표현하는데, 각 컴포넌트가 담당하는 일을 정리하면 다음과 같다.

- Model : 데이터와 그 처리 로직(logic)을 가지고 있다.
- View : 실제 UI요소를 그려준다.
- Controller : 사용자의 입력 정보를 이벤트(event) 형태로 수신한다.

이어 소개할 PAC 패턴은 MVC 패턴에 기반을 두고, 시스템 구성 관점으로 발전시킨 패턴이며, Document-View, MVP, MVVM 패턴은 모두 UI 구조 관점에서 MVC 패턴을 발전시킨 패턴이다.


PAC(Presentation-Abstraction-Control) 패턴
PAC 패턴은 MVC 패턴을 시스템 구조적 관점으로 변형한 패턴이다. PAC 패턴에서는 계층구조(hierarchy)를 이룬 에이전트(agent)들이 서로 협력·상호작용하는 소프트웨어 시스템의 구조를 형성한다.

PAC 패턴의 특징과 MVC 패턴과의 차이점을 그림으로 표현하면 다음과 같다.

- Model : 데이터와 그 처리 로직을 가지고 있다.
- View : 실제 UI 요소를 그려준다.
- Presenter : View와 Model간의 상호작용을 담당한다.

MVP 패턴의 핵심 목표는 View와 Model간의 결합도를 낮추는 데 있다. 여기서는 Presenter가 Model의 데이터를 View에 출력할 수 있도록 할 뿐만 아니라, 이벤트를 View에서 받아 Model의 데이터를 갱신하기도 한다. 실제 구현에서는 Presenter는 View와의 결합도를 감소시키기 위해서, View를 직접 참조하는 대신 View의 Interface를 참조한다. 이를 통해 Presenter는 View의 실제 UI 요소가 어떻게 구현되는지에 관계없이 데이터를 올바르게 표현하도록 할 수 있다. [MSDN]


MVVM(Model-View-ViewModel)

MVVM 패턴은 아래 그림과 같이 사용자와의 상호통신이 활발하고 동적인 사용자 인터페이스를 가지는 클라이언트 응용프로그램에게 적합하도록 MVP패턴을 개선한 패턴이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

전문가들이 어떤 문제(problem)와 맞닥뜨렸을 때, 기존에 사용했던 해결책(solution)과는 완전히 다른 방법으로 그 문제에 접근하는 경우는 매우 드물다. 그들은 일반적으로 이미 해결해 본 문제들 중, 당면한 것과 유사한 문제를 찾아 당시의 해결방법을 당면한 문제 해결에 응용하곤 한다. 여기서 '유사한 문제'란 구체적이고 세세한 사항은 다를 수 있지만, 그 해결책이 가지는 핵심적인 방법은 같은 것을 말한다.
이런 일련의 과정을 효과적으로 수행하기 위해 만든 개념이 바로 패턴(pattern)이다. 패턴에서는 빈번히 발생하는 ‘문제'와 그 문제에 대한 '해법’을 쌍으로 구성해, 특정 문제에 대한 해법을 손쉽게 재활용 할 수 있도록하고 있다.

소프트웨어 영역에서 사용되는 '패턴'의 특징을 보면 다음과 같다.('패턴'이라는 개념은 소프트웨어 영역 뿐만 아니라 건축·경제 등의 분야에서도 사용된다.)

패턴은 특정한 상황(context)에서 반복적으로 발생하는 설계상의 문제와 그에 대한 해법을 제시한다. 많이 알려진 MVC 패턴에서의 문제는 UI가 쉽게 변할 수 있다는 것이다. 이 문제는 사용자와 컴퓨터가 상호작용해야 하는 소프트웨어를 개발할 때 흔히 대두되는데, 이런 문제를 해결하기 위해서는 책임(responsibility)을 엄밀히 구분하면 된다. MVC 패턴에서는 소프트웨어의 핵심 데이터와 기능을 UI로부터 분리하는 방법을 제시했다.

패턴은 이미 그 효과가 입증된 경험을 정리한 것이다. 패턴은 인위적으로 발명되거나 창조되는 것이 아니다. 경험 많은 전문가가 얻은 설계에 대한 지식을 모아, 재사용할 수 있는 형태로 정리한 것이 패턴인 것이다. 그렇기 때문에, 이미 많은 패턴을 숙지하고 있는 사람이라면, 패턴에 해당하는 문제의 해결책을 다시 찾을 필요 없이, 기존의 지식만으로도 즉각 설계에 그 해결책을 적용 할 수 있다.
극소수 전문가들끼리 비밀리에 전수하는 ‘비법(秘法)’과는 달리, 패턴은 누구나 공개적으로 사용할 수 있다. 즉, 패턴은 특정 상황에서 고품질 소프트웨어를 설계할 때, 전문가 수준의 지식을 누구나 쉽게 사용할 수 있게 해준다. MVC 패턴 역시도 수년 간 상호작용 시스템을 개발하며 얻은 경험을 정리한 것이라 할 수 있다.

패턴은 컴포넌트나, 단일 클래스, 객체 같은 수준보다 높은 단계의 추상 레벨에서 발견되고 정의된다. 대체로 패턴은 몇몇 컴포넌트, 클래스, 객체를 서술하며 그것들의 책임, 관계(relationship), 협력(cooperation)에 대한 내용을 상세히 정의한다.
모든 컴포넌트나 클래스, 객체들은 패턴이 해결하고자 하는 문제를 함께 풀어가는데, 단일 컴포넌트로 해결하는 것보다 훨씬 효과적이다. 실제로, MVC 패턴에서는 모델, 뷰, 컨트롤러라는 세가지 컴포넌트의 상호 협력에 대해 명시하고 있으며, 결과적으로 단일 컴포넌트로 만드는 것보다 유연하고 효과적인 시스템을 만들어내고 있다.

패턴은 설계 원칙에 대한 공통 어휘(vocabulary)와 공감대를 형성시켜준다. 패턴의 이름이 적절히 붙는다면, 설계 용어로 쉽게 사용할 수 있다. 패턴의 이름이 설계 용어로 사용되면, 설계에 대해 의견을 나눌 때, 그 효율성이 배가된다. 특정 문제에 대한 해법을 설명할 때, 패턴 이름만 알고 있다면 해법의 메커니즘을 복합하고 장황하게 설명하지 않아도 되기 때문이다. 해법의 어떤 부분들이 패턴의 어떤 컴포넌트에 해당하는지, 혹은 컴포넌트들 간의 어떤 관계가 패턴의 어느 부분과 관계 있는 것 인지만 설명하면 되는 것이다. 예를 들어, 패턴에 대해 익숙한 동료들끼리 “이 소프트웨어의 아키텍처에는 MVC 패턴을 적용합시다” 라고 말할 경우, 동료들은 이 애플리케이션의 기본 구조와 특성들을 부연 설명 없이도 쉽게 파악할 수 있게 된다.

패턴은 소프트웨어 아키텍처를 문서로 정리하는 방법이다. 패턴을 사용하면 특정한 문제에 대한 복안(腹案)을 쉽게 문서로 정리할 수 있는 것이다. 이런 점은 소프트웨어를 확장할 때도 매우 유리하게 작용한다. 소프트웨어를 확장할 때, 기존의 소프트웨어가 MVC 패턴에 맞게 설계되었다는 것을 알고 있다면, 새로운 기능이 모델, 뷰, 컨트롤러 중, 어떤 컴포넌트에 해당하는 확장인지 쉽게 파악할 수 있고, 기존의 설계 원칙에 어긋나지 않게 새로운 기능을 추가해 넣을 수 있기 때문이다.

패턴은 고유한 특성(property)을 제공해야 하는 소프트웨어를 개발할 수 있도록 도와준다. 패턴은 각 컴포넌트가 제공해야 하는 기능적인 골격을 제시하고 있다. 예를 들어 Peer-To-Peer 패턴은 프로세스간 통신에 대한 특성을 포함하고 있고, MVC 패턴은 UI의 가변성과 핵심 기능의 재사용성에 대한 특성을 포함하고 있다. 실제로 개발하고자 하는 소프트웨어가 프로세스간 통신을 필요로 한다면 Peer-To-Peer 패턴을, UI가 자주 변경된다면 MVC 패턴을 적용하거나 참고하면 보다 쉽게 소프트웨어를 설계개발 할 수 있다.

패턴은 복잡한 소프트웨어의 아키텍처를 구축하는 데 도움을 준다. 모든 패턴은 컴포넌트들과 그것들 사이의 역할 및 관계를 정의해 놓고 있다. 이런 패턴은 복잡한 설계를 위한 빌딩블록(Building-Block)으로 사용할 수 있는데, 이를 통해 이미 검증된 설계 방식을 응용하게 되어 설계에 들이는 시간은 단축하고, 그 질은 향상시킬 수 있다. 물론 많이 알려진 패턴이 항상 개발자 스스로가 고안한 해법보다 우수한 것은 아니지만, 설계 방안을 검토할 때 충분히 참고하거나 응용할만한 가치가 있다.
반면, 패턴은 문제 해결을 돕는 것이지, 완전한 해법을 제공하지는 않는다. 패턴이 특정 문제에 대한 해법의 기본 구조를 결정할지라도, 해법의 세부 내용까지 모두 정의하고 있지는 않다. 패턴은 특정 문제 유형의 일반적인 해법에 대한 스키마(scheme)만을 제공할 뿐이지, 사전에 미리 제조되어 그대로 가져다 쓰기만 하면 되는 완전한 조립식 모듈은 아닌 것이다. 그러므로 패턴을 적용하려는 개발자는 설계의 구체적인 세부 내용은 스스로 구현해야 한다. 패턴은 아키텍처 수준의 설계를 돕기 때문에, 패턴을 적용한 해법의 포괄적인 구조는 비슷할 수 있지만, 세부적인 내용에서는 상당히 차이가 날 수 밖에 없다.

패턴을 사용하면 소프트웨어 복잡성을 관리하는 데 유용하다. 모든 패턴은 해결하고자 하는 문제의 해법을 서술한다. 이때 해법에는 필요한 컴포넌트의 종류, 각 컴포넌트의 역할, 숨겨져야 하는 세부 구현, 노출되어야 하는 추상화 부분, 그리고 이것들이 동작하는 방법 등이 서술되어야 한다. 그렇기 때문에 어떤 패턴이 다루고 있는 문제와 맞닥뜨렸을 때, 문제에 대한 해법을 찾느라 시간 들여 골몰할 필요가 없다. 패턴을 올바르게 구현하면, 그 패턴이 제공하는 해법은 자연스레 따라오는 것이다.

<참고자료>

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

최근 보안 분야가 중요시 되고 있는 것이 사실이고, 그에 대한 합당한 이유가 있지만, 나는 개인적으로 "보안"이라는 분야에 큰 매력을 느끼지 못한다. "보안"이라는 분야는 아무리 잘해야 "제로 섬 게임(Zero-sum game)"이고, 대개의 경우는 "네거티브 섬 게임(Negative-sum game)"이 될수 밖에 없는 분야이기 때문이다.
특정 시스템을 기준으로 봤을 때, 해커들의 행위는 어디서나 "네거티브(Negative)"요소일 수 밖에 없다. 보안 전문가가 그 해커들을 아무리 잘 막는다고 해도 그 자체만으로 뭔가 이득(positive)이 생기지 않기 때문에, 결국 보안의 최선은 "제로 섬"이 되는 것이다. 물론 보호하는 정보의 가치와, 누출됐을 때의 손실을 감안해 보안 비용을 산정하지만, 어떤 이유를 들더라도 전체적으로 "제로 섬" 이상이 될 수 없다는 사실은 변하지 않는다.

하지만 현실적으로 "세상은 결코 안전하지 않기 때문에" 어쩔수 없이 보안에 손을 댈 수 밖에 없는 것이 나와 같은 개발자의 처지이다. 이번 포스팅에는 모든 보안의 기초가 될 수 있는 "사용자 패스워드 만드는 법"에 대해 다루고자 한다.

일반적으로 보안을 중시하는 제품에서는 사용자 암호를 반드시 강력한 암호 체계에 맞춰 만들도록 강제하는데, 강력한 암호 체계란 아래 항목을 모두 만족시키는 것을 말한다.

- 8~16 글자로 구성된 문자열
- 다음 네 종류의 문자 중 세 가지 이상이 동시에 사용된 문자열
   :: 대문자 (A B C ...... Z)
   :: 소문자 (a b c ...... z)
   :: 숫자 (1 2 3 4 5 6 7 8 9 0)
   :: 기호 (` ~ ! @ # $ % ^ & * ( ) _ + - = { } | [ ] \ : " ; ' < > ? , . /)
- 일반적인 단어 또는 유사한 단어 사용 금지
- 사용자 이름 또는 유사한 이름 사용 금지

"P@ssw0rd"라는 암호를 예로 들어보자. 이 암호는 8~16글자 범위 안에 구성되어 있으며, 대문자∙소문자∙숫자가 혼재되어 강력한 암호 체계를 만족한다. 물론 "Password"라는 단어를 쉽게 연상시킬 수 있는 조합이기 때문에 "매우 적절"하다는 평을 하기에는 무리가 있으나, 어디까지나 여기서는 '예제'로 만든 것이니 만큼, 논외로 하기로 한다.

이런 내용은 이미 다수의 업체나 조직에서 제시한 바 있으며, 여러 제품에도 이미 강제적으로 포함되어 있는 규칙이기도 하다. 하지만 새로운 제품을 만들어내야 하는 나의 입장에서는 반복적으로 확인하며 적용할 사항이기에 다시 한번 정리해본다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

세상에는 정말로 많은 동명이인(同名異人)이 존재한다. IT분야에도 여지 없이 많은 동명이인이 있고, 오늘 그중 한분인 "김명호 박사"님의 인터뷰 내용에 대한 글을 올려보고자 한다.
같은 IT분야 종사자라 해도, 그 사람의 위치에 따라 "김명호 박사"를 서로 다르게 알것이다. 학계, 특히 데이터베이스 분야의 사람이라면 누구나 KAIST의 김명호 교수를 한번쯤 떠올릴 것이고, 현업 엔지니어 ― 특히 MS 계열의 기술을 사용하는 엔지니어 ― 라면 한국 마이크로소프트의 김명호 상무를 떠올릴 것이다. (물론 성균관대학교의 김명호 교수가 석궁으로 판사를 쏜 사건으로 일반인들에게는 더욱 유명할 것이다.)

이 글에서는 한국마이크로소프트에서 NTO(National Technical Officer) 직함을 가진 후자의 "김명호 박사"의 인터뷰에 대한 내용을 다루고자 한다. 내가 김명호 박사님을 처음 본 것은 TechED 2002 혹은 TechED 2003으로 기억한다. 당시 나는 Microsoft Student Ambassador로 초청받아 TechED 강연자들과 함께 식사를 할 수 있었고, 짧게나마 그분과 대화를 나눌 수 있었던 것이다. (물론 당시의 초청은 Asia Academic Evangelist인 Kurt와의 인터뷰가 목적이었다.)
물론 그 전에 그분에 관한 얘기는 들을 수 있었다. 지금은 마이크로소프트 본사에서 개발자로 있는 영준이형으로부터 "존경해 마지않는 분"이라 이미 소개 받은 터였고, 어떤일을 어떻게 해 온 분이었는지 역시 전해 들은바 있었다.
이후에도 여러 강연을 통해 그분의 기술에 대한 열정과 그에 걸맞는 실력을 확인할 수 있었다. 이번에 소개하는 인터뷰 동영상은 MSDN 사이트를 뒤적이다 우연히 발견하게 된 것인데, 두고 두고 도움이 될만한 내용들이 포함되어 "귀차니즘"을 이겨내고 포스팅 할 가치가 있다 여겨 여기에 소개한다.

이 인터뷰의 내용을 정리하면 다음과 같다.

1. 기술에 대한 학습을 두려워하지 말라
    - 기술은 엔지니어를 괴롭히기 위해서가 아니고, 돕기위해 나온다.
2. 기초를 탄탄히 하라
    - 기초에 관한 정보를 늘 뒤져보지 않아도 돼야 한다.
    - 핵심을 파악하고 핵심은 최고의 깊이까지 학습하라.
      그러기 위해서는 빠른 실무 적용에 대한 성급함을 이겨내야 한다.
3. 집중해서 학습하라.
4. 남에게 설명하려면 120% 준비하라.
5. IT에 국한된 공부만 하지 마라.

길다면 길고, 짧다면 짧은 인터뷰 내용이지만, 나태해진 내 스스로의 모습을 다시 한번 돌이켜보게 되는 조그만 기회가 되지 않았나 싶다. 또한 어느샌가 무감각해진 "공부에 대한 자극"을 되불러오는 계기가 되지 않았나 싶다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

현재 많은 오픈소스 소프트웨어와 많은 라이센스들이 존재한다. 좀 더 나은 소프트웨어을 개발하는데 있어 많은 공개소프트웨어를 사용할 여지가 많아졌고, 내가 만든 소프트웨어들의 라이센스 역시 체계적으로 관리하기 위해서는 오픈소스 관련 라이센스들에 대해서 알아볼 필요성이 있다. 이에 다른이의 블로그 내용과 나의 추가적인 수정·보완 덧붙여 이 내용을 정리해 보고자 한다.


Public Domain
- 자유롭게 복사하거나 개작할수 있고 어떤 목적으로 사용할수 있다.
- 소유권이 포기된 상태이거나 일반 대중에게 완전히 기증된 상태의 저작물이다.

GPL(General Public License)
- 복사하여 사용하고 수정 및 배포도 가능하다.
- GPL 소프트웨어를 이용해 제작·수정된 소프트웨어도 모두 공개해야한다.
- GPL 소프트웨어를 라이브러리로 사용한 소프트웨어도 GPL를 따라야한다.
- 상용 소프트웨어와의 연계가 불가능하다.

LGPL(Lesser General Public License)
- LGPL 소프트웨어를 라이브러리로 사용한 소프트웨어는 공개할 필요가 없다.
- LGPL를 저작물을 직접 수정한 경우, 그 저작물도 LGPL를 따라야 한다.

BSD License
- 소프트에어의 저작권 표시 보증 책임이 없다.
- 소프트웨어의 소스 코드 공개를 요구하지 않는다.
- 상용 소프트웨어에서도 무제한 사용 가능하다.

MPL(Mozilla Public License)
- 소스코드와 실행파일의 라이센스를 분리한다.
- 저작물의 소스 코드는 반드시 공개되어야 하며, 수정했을 경우 통지해야한다.
- 저작물의 실행파일에 MPL 이외의 다른 라이센스를 적용할 수 있다.
- MPL 소프트웨어를 수정한 소프트웨어도 MPL에 따른다.
- 특허와 관련된 사실은 'LEGAL'파일에 기록한다.

Apache License
- 원 저작물을 어떤식으로 사용해도 관계 없다.
- 어떤 문제가 발생해도 책임지지 않는다.
- 파생된 결과물도 아파치 라이센스를 따르지 않아도 된다.
- 원본을 수정해도 원저작자에게 알려주지 않아도 된다.
- 'Apache'라는 이름에 대한 상표권을 침해하지 않아야 한다.

MIT License
- 복사하여 사용하는 것은 물론이고 수정 및 배포도 가능하다.
- 업무용으로 사용 가능하며 심지어는 그냥  판매할 수도 있다.
- 어떤 문제가 발생해도 책임지지 않는다.

EPL(Eclipse Public License)
- 무료로 사용할 수 있으며, 자유롭게 수정할 수 있다.
- 자신이 직접 개발한 부분에 대해 어떤 라이선스를 사용하든 관계 없다.
- 자신의 소스코드를 공재자히 않고, 유료화 할 수 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

현대의 기업 조직 내에서 기업 구성원들은 이미 서로 복잡하게 연결되어 있다. 일상적인 업무 처리를 위한 팀과 팀 간의 연결, 부서와 부서간의 연결 뿐 아니라, 파트너와의 연결, 심지어 경쟁사, 그리고 인터넷을 이용한 고객과의 연결 등이 그 예이다. 이러한 연결은 앞으로 점점 더 복잡하고 넓게 분포될 것이다. 물론 성공적인 비즈니스를 위해 기업 내 구성원들은 유연하게 변화해야 하지만, 이에 못지않게 IT 인프라 또한 기업 환경 변화에 유연하게 적응할 수 있어야 한다. 이러한 변화에 대한 대처 능력을 비즈니스 유연성(agility)이라 한다.
엔터프라이즈 애플리케이션은 기업 구성원이 자신의 비즈니스 목적을 보다 용이하게 달성하기 위해 사용하는 애플리케이션을 의미한다.
그런데 앞서 살펴본 것과 같이 기업 구성원간의 상호 연결의 필연성은 이들이 사용하는 개별 애플리케이션 역시 끊임없이 상호 연결되어야 하는 필요성, 즉 통합에 대한 요구를 내포하게 된다. 뿐만 아니라 누구나 인정하듯 모든 상황에 가장 완벽한 단일한 플랫폼은 존재하지 않으므로 기업 내의 IT 시스템은 이질적인 환경에 노출될 수밖에 없다. 이질적인 플랫폼간의 애플리케이션 통합은 현대 기업 시스템의 필수적인 요구사항이 될 수밖에 없다.
그러나 분석과 설계 단계를 거치면서 성공적으로 구축된 애플리케이션들을 필요에 따라 통합하는 것은 그리 쉬운 일이 아니다. 이를 힘들게 하는 가장 근본적인 이유는 해당 애플리케이션들의 분석과 설계 과정에서 통합에 대한 요구 사항이 결여되어 있기 때문이다.
또한 이것은 개별적인 단위 애플리케이션을 위해서는 비교적 잘 정의된 아키텍처가 있는 반면 애플리케이션과 애플리케이션 통합에 관한 전체적인 아키텍처가 결여되어 있기 때문이기도 하다. SOA는 바로 이러한 유연한 통합에 관한 해결책을 제시한다.

이와 같은 SOA의 도입에 따른 효과를 정리해 보면 아래와 같다.


기존 자산의 이용

SOA를 통해 기업은 현존하고 있는 컴포넌트를 보다 쉽게 통합하여 비즈니스 서비스를 완성할 수 있고, 이것을 기업에 적용시킬 수 있다. 이러한 새로운 서비스 기술은 인터페이스와 이름만 알면 사용이 가능하다. 서비스의 구현은 서비스를 만드는 컴포넌트를 통해 데이터 흐름의 복잡함과 기능적인 컴포넌트를 분리하고 구체화시킨다.
서비스는 조직이 기존의 자산을 이용하며, 서로 다른 기계로부터 서비스를 쉽게 통합할 수 있도록 한다. 이는 서로 다른 운영 시스템을 작동시키며, 서로 다른 프로그램 언어 환경 속에서 개발을 진행하도록 돕는다. 기존의 시스템도 서비스 인터페이스를 통하여 은닉화되고 접근될 수 있다. 가장 중요한 것은 기존의 시스템이 그들의 기능에 서비스의 가치를 부여함으로써 새롭게 변화될 수 있다는 점이다.

IT 컨설팅 회사인 실크로드 사의 사장 팀 바스는 “SOA가 좋은 점은 기존의 포트폴리오를 활용할 수 있게 해 준다는 것이다.”라고 말한다. SOA는 기업이 기존 시스템을 제거하고 새로운 시스템으로 대체할 필요가 없도록 해준다. 기존 시스템의 기능들을 파악한 후 그것들을 활용함으로서, 위험을 최소화하면서 기존 IT 투자의 가치를 극대화할 수 있다는 것이다.


인프라에 독립적

새롭게 개발된 서비스와 다양한 판매자들로부터 얻은 서비스는 잘 정의된 SOA에 의해서 통합될 수 있다. 이러한 서비스들 간의 통합은 존재하고 있는 인프라에 새로운 서비스로서 배치될 수 있다. 그 결과, 기업 내 시스템 인프라는 쉽게 교체될 수 있다. 시간이 지남에 따라 서비스는 하드웨어의 자원으로부터 점점 loosely coupled되고 서비스가 실시간으로 적용이 됨으로써 더 이상 하드웨어 환경에 의존하지 않고 하드웨어를 최적화 할 수 있다.


빠른 시장 접근

서비스는 SOA 의 한 부분으로써 조직의 핵심 자산이 될 것이다. 이러한 서비스를 가지고 SOA를 설계하고 배치시킨다는 것은 시장에의 접근시간을 극적으로 줄여줄 것이다. 이것은 기존의 서비스와 컴포넌트의 재사용, 다자인, 개발, 테스트와 배치 시간을 줄임으로써 가능하다.


비용절감

SOA를 통해 새롭게 요구되는 비즈니스 요구사항을 지원하기 위한 IT 비용을 감소시킬 수 있다. 새로운 서비스를 기존의 서비스들을 통합하여 쉽게 창출할 수 있으며, 기존 레거시에 대한 복잡한 통합 고려사항에 대한 비용을 줄일 수 있기 때문이다. 또한 SOA를 통해 개발부서의 학습곡선을 줄일 수 있다.
SOA를 통하면, 개발자들은 애플리케이션들을 연결하는 새로운 코드를 작성하기 위해 과도한 시간을 낭비할 필요가 없어진다. 대신 개발자들은 웹서비스 같은 표준 프로토콜을 사용할 수 있다. 그리고 SOA 코드의 상당 부분은 재사용이 가능하기 때문에 개발 비용도 줄어든다. 더구나 SOA는 기존에 리거시에 투자했던 것들을 한데 묶어 저렴하게 활용할 수 있도록 해 준다.


위험관리

서비스의 재사용을 통해 새로운 비즈니스를 창출하거나 강화하는 프로세스에 대한 실패 우려를 줄일 수 있다. 또한 서비스를 지원하는 인프라를 관리하고 유지하는 것에 대한 위험은 기존 인프라에 비해 훨씬 줄어들게 된다.


끊임없는 비즈니스 프로세스의 진보

SOA는 특정한 비즈니스 서비스에서 사용되는 컴포넌트의 명령에 의하여 프로세스 흐름이 설명되며, 이것을 명확히 나타낸다. 그리고 비즈니스 운영에 관해서 관리가 가능하도록 사용자들에게 이것을 제공한다. 즉, 프로세스 모델링은 비즈니스 서비스를 반영하는 것이다. 프로세스의 조작은 패턴을 인식함으로써 가능하다. 이러한 기능은, 계속되는 진보에 따른 영향을 관리하는 동안에 프로세스 흐름의 변화를 인식한다.


프로세스 중심의 아키텍처

현존하는 아키텍처나 보아왔던 사례들은 대부분 프로그램 중심적으로 만들어졌다. 즉, 애플리케이션이 프로그래머의 입장에서 만들어진 것이다. SOA 중심의 애플리케이션은 내부에 포함된 비즈니스 로직의 세부사항을 감추는 블랙 박스와 같다. 기존의 방식과 달리 프로세스 중심적인 아키텍처에서 애플리케이션은 프로세스를 위해 개발된다. 프로세스는 단계 별로, 각각을 대표하는 비즈니스 서비스로 분해된다. 이러한 하부 애플리케이션은 사업의 요구사항을 만족시키는 프로세스의 능력을 생성해낸다. 이것은 조직 내에서 프로세스의 이용과 하위 애플리케이션의 재사용을 통해 가능하다.


기업 적응력 향상

SOA의 또 다른 이익은, SOA가 IT 스탭들로 하여금 기술 아키텍처가 아니라 비즈니스 아키텍처 측면에서 생각하도록 강요하기 때문에, IT 스탭들과 비즈니스 중역들 사이의 대화를 더 매끄럽게 해 줄 수 있다는 점이다.
예를 들어, 만약 비즈니스 프로세스가 개선된 재고관리 시스템을 구축하고자 한다면, 비즈니스 실무자는 IT 스탭들과 직접 대화 하면서, 프로세스를 설계/구현할 수 있는 것이다. 결국, SOA가 완벽하게 구축된다면 변화하는 비즈니스 요구와 매순간 바뀌는 시장 조건들에 대한 기업의 적응력은 크게 높아지게 된다.


ROI의 향상

마지막으로 통합이 쉬워지고 유연성이 높아짐으로써 ROI가 높아진다는 부수적 이익도 얻을 수 있다. 다시 말해 개발자들은 모든 종류의 전방처리 시스템들과 작동하기에 충분할 만큼의 일반적인 형태의 서비스를 디자인할 수 있으며, 이로 인해 개발시간이 단축되고 개발자들은 비즈니스 솔루션에 더 많은 시간을 쏟을 수 있게 된다. 여기에 IT 스탭들은 새 기술을 SOA에 쉽게 결합할 수 있어, 위험과 비용을 줄이면서 새 애플리케이션의 개발 속도를 높일 수 있게 된다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SOA는 비지니스 로직과 데이터를 서비스 중심으로 전환함으로써 소프트웨어 아키텍처의 패러다임을 이동시킨다. SOA는 다음과 같은 4가지 원칙을 반영하는데, 이것이 바로 전통적인 소프트웨어 아키텍처 접근방법과의 차이점이다. 따라서, 기존의 아키텍처를 SOA를 기반으로 한 아키텍처로 바꾸어 디자인하기 위해서는 다음 4가지 사항을 유의하여 고려해야 한다.


프로세스 중심

서비스 혹은 애플리케이션 통합에 대한 요구는 결국 비즈니스 프로세스 자동화라는 필요에 의해서 발생된다.
실제로 비즈니스 서비스는 타인에게 자신의 서비스를 제공하는 반면 프로세스 서비스는 이들 간의 통합을 위한 공통 인프라를 제공한다. 비즈니스 서비스가 실제 비즈니스 로직을 제공한다면, 프로세스 서비스는 프로세스 오케스트레이션(Orchestration). 즉, 언제, 어디서, 누구를, 어떻게 통합해야 하는 지 같은 제어 역할을 담당하게 된다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SOA는 다음과 같은 주요 특징을 가진다.

• 서비스는 발견이 가능하고 동적으로 바인딩 된다.
• 서비스는 컴포넌트와 같이 독립된 모듈이다.
• 서비스의 플랫폼간 상호 운용이 가능하다.
• 서비스는 느슨하게 연결된다.
• 서비스는 네트워크 주소로 접근 가능한 인터페이스를 갖는다.
• 서비스는 위치 투명성을 제공한다.
• 서비스의 조립이 가능하다.
• 서비스는 자기 치유(self-healing)를 지원한다.

발견과 동적 바인딩

SOA는 “서비스의 발견과 동적 바인딩”이라는 개념을 지원한다.
어떤 서비스를 필요로 하는 사용자는 작업 수행 중(runtime)에 필요로 하는 서비스를 찾고, 그것을 사용할 수 있는 것이다.
예를 들어 금융관련 애플리케이션에서 신용카드 기능을 포함시키고자 한다고 하면, 금융 애플리케이션은 레지스트리에서 신용카드 기능을 지원하는 서비스를 조회한 후, 자신에게 맞는 서비스를 골라 동적으로 바인딩하게 된다.


모듈 독립성

SOA에서 사용하는 서비스는 컴포넌트에서와 마찬가지로 독립적인 모듈이다. 각각의 서비스는 독립적으로 개발, 유지, 관리되며, 서로의 작동 자체에 큰 영향을 미치지 않는다.
이런 점은 특정 서비스를 수정했을 때 발생하는 파문 효과(ripple effect)를 최소화 시켜 결합도를 낮추는 중요한 특성이 된다.


상호 운용성

SOA에서의 서비스는 플랫폼에 관계없이 상호운용이 가능하다.
각 서비스는 자신을 호출할 수 있는 인터페이스를 제공하고 있다. 이때 호출이 이루어지는 프로토콜과 호출 메시지의 포맷만 이해 할 수 있다면 서로 다른 플랫폼 위에서 개발, 운영 되는 서비스끼리도 통신이 가능한 것이다.


느슨한 연결

각 모듈을 연결하는 방법에는 밀접한 연결(tightly coupling)과 느슨한 연결(loose coupling)이라는 두 가지 방법이 있다. 뒤에 다시 언급하겠지만 느슨한 연결 방법은 단단한 연결 방법에 비해 모듈간의 결합도를 낮춘다.
결합도가 높을수록 한 모듈의 변화가 다른 모듈에도 영향을 주어 파문 효과(ripple effect)를 일으키게 되는데, 파문 효과가 클수록 시스템을 유지보수는 어려워진다. 파문 효과는 하나에 영향이 생겼을 때 다른 것들에 많은 영향을 끼치는 것이다.
대개의 소프트웨어 구조는 결합도가 낮은 것을 지향하는데, SOA에서는 서비스 사용자와 제공자를 느슨하게 연결해 결합도를 낮출 수 있도록 하고 있다.


네트워크 주소로 접근 가능한 인터페이스

네트워크는 SOA의 개념상 그 핵심에 위치하고 있다.
각 서비스는 네트워크 주소를 통해 접근할 수 있는 인터페이스를 제공 하는데, 서비스 사용자는 서비스를 연결하고 있는 네트워크를 통해 그 서비스를 호출하게 된다.
이렇게 네트워크를 통해 사용자가 서비스를 사용할 수 있게 됨에 따라 각각의 서비스는 불특정한 다수의 사용자에 의해 재사용될 수 있게 되는 것이다.


위치 투명성

위치 투명성은 SOA의 핵심 특징 가운데 하나이다.
서비스 사용자는 레지스트리에서 서비스를 찾아 바인딩 하기 전까지는 자신이 사용할 서비스의 정확한 위치를 알지 못한다. 같은 이유로 서비스 제공자가 임의의 이유로 자신의 서비스 위치를 바꾸게 되더라도, 사용자는 쉽게 바뀐 위치의 서비스를 이용할 수 있게 되는 것이다.
또, 서비스를 제공하는 물리적인 위치가 변경 되더라도 DNS의 유지 보수를 통해, 서비스의 제공과 사용에는 큰 영향을 주지 않게 할 수도 있다.


조립

SOA에서의 각 서비스는 재사용성을 높이기 위해 각각의 기능별로 모듈화 되어 있다.
이렇게 모듈화 된 서비스들은 하나의 완성된 기능을 제공하기 위해 조립되는데, 그 방법에는 다음과 같이 크게 세 가지가 있다.

• 애플리케이션에서의 조립
• 서비스 연합(service federation)
• 서비스 오케스트레이션(service ochestration)

애플리케이션에서 서비스를 조립하는 것은 가장 전통적인 방법으로 서비스와 컴포넌트, 애플리케이션의 로직을 기능에 맞게 작성하는 방법이다. 또, 서비스 연합은 보다 큰 범주의 서비스 안에 관련된 서비스들을 모아 관리하는 방법이다. ‘계좌 조회’, ‘입금’, ‘출금’이라는 서비스는 ‘은행 계좌’라는 서비스에 의해 관리되는 것이 그 예이다.
마지막으로 서비스 오케스트레이션은 비즈니스 프로세스를 사용해 각 서비스의 호출 순서와, 에러처리 등을 제어하는 방법이다.


자기 치유(self-healing)

SOA는 자기 치유를 지원한다. 앞에서도 언급했다시피 SOA에 의해 개발된 소프트웨어는 자신이 사용하고 있는 서비스를 발견하고, 동적으로 바인딩 할 수 있다. 만약 SOA에 의해 개발된 소프트웨어가 사용하고 있는 특정 서비스가 임의의 원인에 의해 정상적인 기능을 할 수 없는 경우, 소프트웨어는 그와 같은 기능을 하는 서비스를 새로 찾아 바인딩 하므로서 자신의 내부에 있는 오류의 원인을 제거할 수 있는 것이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

위 그림은 SOA의 기본 구성요소를 도시하고 있는데, 각 요소는 다음과 같다.

• 서비스 사용자(Service Consumer) : '서비스 제공자'에 의해 제공되고 있는 하나 이상의 서비스를 사용한다.
• 서비스 제공자(Service Provider) : '서비스 사용자'가 호출시 입력하는 값을 가공하여, 그에 해당하는 결과를 제공한다. 경우에 따라 '서비스 제공자'는 또 다른 '서비스 제공자'의 서비스를 사용하는 '서비스 사용자'가 될 수도 있다.
• 서비스 레지스트리(Service Registry) : 서비스에 대한 설명 정보(descriptions)를 저장하고 있다. '서비스 제공자'는 자신이 제공하고 있는 서비스를 등록하고, '서비스 사용자'는 자신이 원하는 서비스를 발견하여 사용한다.

여기서 우리는 SOA를 이해하기 위한 세 가지 주요 요소를 추출할 수 있다. '서비스', '메시지' 그리고 '서비스 발견'이 그것이다. 이들 각각에 대한 이해를 통해, 우리는 SOA의 본질에 보다 가까이 갈 수 있다.


서비스

SOA의 관점에서 서비스는 인터페이스를 통해 자신이 가진 비즈니스 프로세스를 처리할 수 있는 컴포넌트로 정의된다. 아래 그림과 같이 서비스는 인터페이스와 구현 부분으로 구성된다.

• 서비스의 인터페이스는 플랫폼에 독립적이다.
• 서비스는 동적으로 발견될 수 있으며, 호출될 수 있다.
• 서비스는 self-contained하다. 즉, 자신의 상태를 스스로 유지한다.

서비스의 탄생으로 인해 자체적으로 소프트웨어를 만드는 기업은 점차 사라지고, 향후에는 만들어져 있는 소프트웨어를 서비스 단위로 구입하여 사용하는 패러다임이 대세를 이룰 것으로 예상된다.

메시지

SOA를 이루는 두 번째 중요한 개념은 메시지이다. 서비스 제공자와 서비스 사용자는 메시지를 통해 서로 통신한다. 서비스 제공자는 서비스 명세를 통해 자신이 가진 서비스의 인터페이스를 공개하는데, 이 명세 내에는 서비스가 제공하는 기능과 이를 이용하기 위해 사용자와 주고 받아야 하는 메시지의 형식이 정의되어 있다. SOA 관점에서 서비스는 플랫폼 독립적이어야 하므로, SOA에서 정의되는 메시지는 특정 기술에 독립적이어야 한다. 아래 그림은 서비스 제공자와 서비스 사용자가 메시지를 통해 통신하는 모습을 보여준다.

• 서비스의 확장성(scalability) 보장
• 서비스 사용자와 제공자의 분리 (decoupling)
• 서비스의 동적인 변경 기능 제공 (hot update)
• 서비스 사용자를 위한 발견 기능 제공 (동적인 발견 기능 포함)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

사실 SOA는 이미 CORBA나 DCOM등의 분산 객체 기술에서 그 기본 개념이 사용되었으나, 기술적인 문제(기술적인 미성숙 및 공개 표준의 부재)와 비즈니스 문제들(주요 소프트웨어 벤더들 간 협력의 부재)로 인하여 그리 큰 주목을 받지 못했다. 하지만 XML 기반의 웹 서비스 기술이 등장하면서 SOA는 새롭게 조명을 받고 있다.

W3C는 SOA를 "호출 가능한 컴포넌트의 집합"으로 정의 하고 있다. 여기서 컴포넌트는 그 인터페이스의 정의 내용이 공개(publish)‧발견(discovery) 가능한 것을 의미한다.
하지만 CBDI는 이 정의에 대해 두 가지 문제점을 지적하고 있다. SOA가 단순한 컴포넌트의 집합이 아니라는 점과, 정의 자체가 아키텍처의 구성 방법 보다는 이미 정의되어 있는 컴포넌트만을 염두 해두고 있다는 점이다. 따라서 CBDI는 SOA를 “애플리케이션의 기능들을 사용자(consumer)에 적합한 크기(granularity)로 공개한 서비스들의 집합으로 제공하고 사용되게 하는 정책(policy), 적용(practice), 또는 프레임워크(framework)"로 정의하고, 이 때 서비스는 ”단일한 표준기반의 인터페이스 형태를 사용하여 구현과 독립적으로 추상화되며, 호출(invoke)되고, 공개(publish)되며, 발견(discover)할 수 있는 것“이라 정의하였다.

즉 SOA란 서비스라 불리는 분할(decomposition)된 애플리케이션 조각들을 단위로 느슨하게 연결해 하나의 완성된 애플리케이션으로 만드는 아키텍처이다.


서비스(Service)의 개념

SOA가 무엇인지 좀 더 명확히 하기 위해서 서비스가 무엇인지 좀더 상세히 설명할 필요가 있다.
일반적으로 서비스란 생산된 재화를 운반·배급하거나 생산이나 소비에 필요한 노무를 제공하는 것을 말한다. 즉 하나의 컴포넌트가 다른 컴포넌트와 인터페이스 계약을 통하여 제공 되어지는 행동을 서비스라고 한다.

사실 “서비스”란 용어는 IT분야에서도 지난 10여 년동안 폭넓게 사용되어왔다. 예를 들면, 이미 1990년대 초기에 트랜잭션 모니터링(Transaction Monitoring) 소프트웨어는 “서비스”란 용어를 사용해 왔다. 이 소프트웨어는 애플리케이션의 플랫폼에 상관없이 미들웨어에서 트랜잭션 모니터링기능을 제공했다. 또한 1990년대 후반부터는 많은 웹 기반 응용시스템들이 검색엔진(search engine)이나 권한(authorization) 관리, 로그인관리 등 공통적으로 사용 할 수 있는 서비스들(shared component services)을 제공해 왔다.

여기서 중요한 사실은 어떤 과정을 거쳐 우리에게 서비스가 제공되는 지는 관심 밖이라는 사실이다. 단지 우리는 원하는 결과물만을 중요하게 생각하고 있다는 것이다.
114 전화번호 안내 서비스를 예로 들어 보도록 하자. 우리는 찾고자 하는 상호를 말하고, 2~3초 정도를 기다린 후 결과물인 전화번호를 서비스 받는다. 여기서 우리는 전화번호를 찾아내기 위한 과정이나, 시스템의 구현 형태, 보안 따위의 문제는 전혀 중요하게 생각하지 않는다. 단지 안내 받은 전화번호와 그 정확성에만 관심을 두고 있다.

그럼 이제 우리가 다루는 SOA에 좀 더 가까운 또 다른 서비스의 예를 들어보도록 하자. 현재 개발하고 있는 시스템에 사용자가 성인인지 여부를 판단해 주는 기능이 필요한 상황이라고 가정해 보자. 하지만 현재 보유하고 있는 관련 데이터가 없어 직접 구현하는 것이 불가능 하다. 이럴 때 이 기능을 서비스로 제공하는 사업자가 있다면 조회 건수당 얼마씩의 비용을 지불하고 손쉽게 이용할 수 있다. 바로 이러한 것들이 SOA에서 말하고 있는 서비스이다. 즉, 우리가 원하는 결과를 어떻게 해서든 제공하고, 우리가 그것을 이용할 수 있도록 하는 것이 서비스인 것이다. 또 이전의 서비스들과 달리 상호운용성을 강조하며 네트워크에서 접근할 수 있도록 공개된 인터페이스를 가지고 있어야 하며,  동적으로 발견‧사용될 수 있어야 한다. 서비스는 여러 애플리케이션으로부터 추출된 것이며, 이들 서비스를 서로 조합하여 비즈니스 프로세스를 구성할 수 있으며, 서비스는 기술적 계층과는 독립성을 갖는다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.