SOA 반패턴 연구

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.

난이도 : 중급

Jenny Ang, Executive IT Architect, IBM
Luba Cherbakov, IBM Distinguished Engineer, IBM
Dr. Mamdouh Ibrahim, Senior Certified Executive IT Architect, IBM

2005 년 11 월 18 일

다양한 서비스 지향 아키텍처(SOA)의 반패턴(antipattern)을 연구해 보자. 반패턴 연구란 "좋지 않은" 결과를 만들어내는 일반적인 상황이나 솔루션에 대한 연구라고 할 수 있다. 웹 서비스에서 SOA로 비즈니스가 대거 이동하면서 SOA의 도입, 채택, 구현 등 성공 요소들이 더욱 확실해졌다. 몇 가지 장벽들은 과거의 중요한 제안들을 실패로 이끈 것들과 매우 유사하다. 물론 SOA에만 해당하는 것도 있다. 이 같은 장애나 그릇된 방법들이 문서화 되면 컨설턴트, 아키텍트, 전문가들이 같은 실수를 반복하지 않고, 이를 피하는 방법도 배우게 된다. 이 글에서 설명하는 반패턴들은 IBM 아키텍트들의 개인적인 경험, 현재 SOA 관련 연구들, 현재 SOA를 사용중인 사람들의 생각을 토대로 만든 것이다.

패턴 vs. 반패턴

"예제(example)는 교육의 또 다른 방법이 아니다. 이것만이 유일한 방법이다" -- Albert Einstein

패턴과 패턴 언어들은 좋은 디자인과 최상의 실례(practice)들을 포착하고, 다른 사람들도 이것을 재사용 할 수 있도록 공식적으로 성문화한다. 이를 통해 일반적인 문제와 솔루션이 생겨난다. 결국 일반적인 개념과 이 개념을 설명하는 어휘, 이들을 한데 연결하는 언어가 SOA에 대한 모든 교육과 커뮤니티의 토대가 된다.

빌딩과 도시 디자인에 대한 Christopher Alexander의 연구는 패턴 기반의 사고방식을 개척했다고 볼 수 있다.(참고자료) 그는 "패턴 언어(Pattern Language)"라는 개념을 통해서 사람들의 디자인 능력은 언어를 사용하는 능력 만큼 자연스러운 것이라는 그의 확신을 표현한 바 있다.

패턴과 패턴 언어는 생리학과 프로세스는 물론 프로젝트 관리와 소프트웨어 엔지니어링 분야에서도 사용된다. 소프트웨어 디자인 패턴은 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Gang of Four로 알려짐)가 공동 저술한 "Design Patterns: Elements of Reusable Object-Oriented Software"의 출간 후에 더욱 많이 사용되고 있다.

소프트웨어 커뮤니티는 패턴들을 사용하여 소프트웨어 수명 주기동안 발생하는 반복적인 문제들을 해결하고 있다. 소프트웨어 아키텍처와 디자인부터 보다 최근에는 소프트웨어 개발 프로세스와 토폴로지까지 적용되고 있다. 이러한 패턴들은 좋은 소프트웨어 솔루션을 만드는 구조와 메커니즘에 대한 총체적인 개념을 담고 있다고 볼 수 있다.

패턴은 "일반적인 문제와 솔루션"으로 정의되곤 한다. 하나의 패턴에는 특정 상황에서 반복되는 문제에 대한 솔루션이 포함되어 있다.

소프트웨어 패턴들은 표 1-패턴 템플릿과 비슷한 구조로 문서화 된다.

소프트웨어 패턴들에는 아키텍트와 디자이너들 사이의 지식과 경험들이 담겨진다. 이들은 공통적인 언어를 제공하고 성공적으로 적용되었던 방식들의 재사용을 유도하여 위험 감소, 품질 향상, 딜리버리 타임(delivery time) 강화 등 소프트웨어 프로젝트의 여러 측면들에 기여한다.

한편, 반패턴은 잘못된 것들을 문서화 한다. 수 백 개의 소프트웨어 개발 프로젝트들을 조사해 보면 소프트웨어 개발 과정에서 여러 가지 실수들이 포착된다. 조사에 따르면, 6개의 프로젝트 중에서 5개는 실패한다. 예산을 훨씬 초과하거나 프로젝트가 상당히 지연되거나 또는 취소된다. 잦은 실패 원인을 검사하는 것은 성공 케이스를 연구하는 것 만큼의 가치가 있다.(참고자료)

이렇게 반복적으로 실패한 소프트웨어 개발 프로젝트나 "그릇된 솔루션"들은 "무엇이, 왜 잘못되었는지"에 대한 유용한 지식을 도출해 내야 한다. 실패의 원인들을 분류하는 것 만으로는 충분하지 않다. 실패를 피하는 방법과 실패에 직면했을 때 회복하는 방법을 연구하는 것이 더욱 효과적이다. 이러한 집합적인 지식이 성문화 되면 소중한 소프트웨어 패턴의 한 부분이 되고 반패턴(antipattern)으로 규정되는 것이다.

반패턴(Antipattern)은 자주 사용되지만 대게는 문제에 대한 비효율적인 솔루션이다. 이 용어는 원래 잘못된 디자인 패턴을 지칭하는데 사용되었다. 패턴과 마찬가지로 반패턴도 모든 소프트웨어 개발 단계로 확장되어 다른 영역까지 이르게 되었다. 반패턴들은 일반적으로 반복되는 솔루션들을 문서화 한다. 솔루션을 정련하여 반패턴을 건강한 솔루션으로 바꾸는 방법을 제시하고 있다. 반패턴들은 보통 증상, 결과, 근본 원인, 잠재적인 솔루션들로 구성된 템플릿으로 되어 있다. 반패턴이 패턴만큼 광범위하게 연구된 것은 아니지만 "analysis-paralysis", "blob", "spaghetti code", "stovepipe systems" 등 몇 가지는 소프트웨어 커뮤니티에서 빠르게 인지하고 있다. 표 2는 Brown의 반패턴 저서에서 인용한 것이다.(참고자료)

왜 반패턴이 중요한가? 반패턴은 문제가 진짜 문제가 되기 전에 문제를 규명하고 그러한 문제가 발생하지 않도록 하는 방법을 제공하여 문제를 방지하는 장치가 될 수 있기 때문이다. 실패 원인에 대한 공식적인 성문화를 통해서 우리는 명확히 알 수 있다. 문제가 일단 발생하면 반패턴은 그 문제에서 회복되는 방법을 제시한다.

반패턴에는 다음과 같은 요소들이 있다.

• 실행되지 않은 것에 대한 문서화
• 공통 어휘
• 자세한 개선책
• 상황과 대안 솔루션에 대한 인식
• 향후 반패턴이 될 가능성이 있는 현재의 솔루션

그림 1은 패턴과 반패턴의 차이점을 묘사한 것이다. 패턴은 해결하고자 하는 문제에서 출발하여 여기에 반복 적용할 수 있는 성공적인 솔루션을 문서화 한다. 이 솔루션에는 몇 가지 장점, 결과, 가능한 문제들이 포함된다. 반패턴은 문제에 대한 잘못된 솔루션을 설명한다. 문제의 원인을 설명하고 방지책이나 솔루션 정정 방법도 설명한다.

위로

SOA: 간단한 소개

지난 5년 동안 서비스 지향에 대해 많이 다루어지고 있다. 서비스와 서비스 지향은 어떤 의미가 있는가?

SOA에 대한 많은 정의들은 산업과 SOA의 성숙도를 반영하면서 변해왔다. 우리는 여기에서 몇 가지 기초적인 정의를 내리고자 한다. (그림 2)

1. 우선, 서비스란 무엇인가? 서비스란 비즈니스 태스크의 반복적인 논리적 표현이다. 우리는 여기에서 소프트웨어나 IT가 아닌 비즈니스 프로세스의 일부를 논의하고 있다는 것을 주목하라.

   기술적인 관점에서 볼 때 서비스라는 용어는 외부화된 스팩으로 (발견 가능한) 소프트웨어 리소스에 해당한다. 이러한 서비스 스팩은 서비스 소비자가 검색, 바인딩, 호출 할 수 있다. 서비스 공급자는 서비스 스팩을 구현하고 양질의 서비스 요구 사항들을 서비스 소비자에게 제공한다. 서비스는 정책 선언을 통해 관리되어야 하며 동적으로 재설정 가능한 아키텍처 스타일을 지원해야 한다

2. 서비스 지향(service orientation)이란 무엇인가? 서비스의 정의에 기반하여 생각한다면, 서비스 지향은 서로 연결된 서비스들의 그룹으로서 비즈니스를 통합하는 방식이다. 우리는 지금 기술에 대한 이야기를 하는 것이 아니다. 비즈니스를 바라보는 새로운 시각과 운영 방식에 대해 이야기 하는 것이다.
3. SOA란 무엇인가? SOA는 서비스 지향성을 지원하는 아키텍처 스타일이다. SOA는 리소스들을 수요에 따라 연결하는 엔터프라이즈급의 IT 아키텍처이다. 이러한 리소스들은 비즈니스와 제휴 된 서비스로서 표현되어 밸류넷, 기업, 비즈니스 라인에 참여 및 구성되어 비즈니스의 필요를 채울 수 있다.
4. 마지막으로, 합성 애플리케이션이란 무엇인가? 통합된 서비스 세트를 일컫는다. 합성 애플리케이션은 실제로 실행되는 서비스로서 구성 및 연결되어 비즈니스가 수행하는 것을 지원한다. SOA 애플리케이션의 기본적인 구성 요소는 서비스이다. 여기에서 서비스는 하위 시스템, 시스템, 컴포넌트에 반대되는 개념이다.

위로

SOA 반패턴을 규명하는 방법

SOA 반패턴은 다음과 같은 접근 방식을 통해 규명되었다.

• 공식적인 반패턴에 대한 연구
• 클라이언트와 직접적인 미팅에 참여한 사람들이 문서화 한 반패턴
• SOA CoE와 CoP 멤버가 경험을 통해 발견한 반패턴
• 반패턴 템플릿/언어의 사용
• 이 프리젠테이션에 삽입된 반패턴은 세 명의 저자의 동의를 받았다.

위로

반패턴 템플릿/언어

반패턴은 다음의 템플릿/언어로 구성된다.

• 이름

  반패턴의 핵심을 표현하는 간결한 이름

• 문제 / 잘못된 솔루션

  반패턴과 관련된 일반적인 실수나 잘못된 솔루션

• 증상

  문제의 증상

• 결과

  이 반패턴을 적용했을 때의 결과

• 근본적인 원인

  패턴이 잘못 적용되거나 문제나 실패한 솔루션이 발생한 곳에 반패턴의 정황을 대입시킨다.

• 제안 솔루션

  문제를 해결하고 더 나은 효과를 보장하는 정제된 솔루션

위로

SOA 반패턴

위와 같은 방법으로 규명된 반패턴들은 세 가지 범주로 나뉜다.

1. SOA 채택 반패턴: 소비자와 비즈니스가 SOA를 채택하는 것을 지연시키거나 방해하는 반패턴이 있다. 이 범주에서 해당하는 반패턴들은 다음과 같다.
   • A1. 충분한 검토 없이 새로운 기술을 성급히 도입하는 것
   • A2. 기존 기술과 SOA와의 차이에 대한 이해의 부족
   • A3. "빅뱅" 접근방식
2. 서비스 규명 & 디자인 반패턴: 실행자들이 SOA의 일부로서 서비스를 규명하고 디자인 할 때 맞닥뜨리게 되는 반패턴이다.
   • I1. 웹 서비스 = SOA
   • I2. "새사일로(silo)" 접근방식
   • I3. 잘못된 레지스트리
3. 서비스 구현 반패턴: 이러한 반패턴에는 서비스를 실현하는 최악의 관례들이 포함되어 있다. 이러한 반패턴들 중 대부분이 웹 서비스 구현에 초점을 맞추고 있다. 웹 서비스는 SOA의 가장 일반적인 구현이다. 이 글에서는 웹 서비스를 제외한 SOA 구현의 반패턴에 대해 규명했다.
   • R1. 볼품없는 서비스
   • R2. 점대점 서비스
   • R3. 컴포넌트가 부족한 서비스

SOA가 성숙해 가고 더 많은 계약들이 수행되면서 더 많은 반패턴들이 규명될 것으로 예상된다.

위로

SOA 채택 반패턴

다음은 소비자와 비즈니스가 SOA를 채택하는데 있어 방해가 되거나 지연시키는 반패턴이다.

A1: 반패턴 이름: 기술 대역폭 (참고: 웹 서비스 = SOA)

• 문제점

  많은 기업들이 비즈니스 관점이 아닌 IT 관점에서 SOA를 시도하곤 한다. 구현은 기술적으로는 그럴듯해 보이고 가끔은 성공적이기도 하지만 비즈니스에 미치는 영향은 없다. 애초부터 비즈니스는 고려하지 않았기 때문이다.

• 정황

  이 반패턴은 대부분 큰 기업에서 관찰된다. IT 부서가 굳건히 확립되어 있고 기술력이 뛰어난 직원들을 고용하고 있으며, 이들은 기술을 강조하는 리더십에 의해 강력한 지원을 받고 있다.

• 증상

  이러한 반패턴의 일반적인 증상은 스폰서가 SOA 채택에 대한 가치를 알릴 수 없다는 것이다. 또한 SOA 구현을 목표로 한 프로젝트와 비즈니스 간 제휴가 부족한 것도 또 다른 증상이다.

• 결과

  이러한 반패턴의 결과로 어떤 투자 수익(ROI)도 내지 못한 채 IT 비용만 올라간다. 게다가 기업은 IT 포트폴리오에 유연성을 제공할 기회도 잃게 된다.

• 근본 원인

  대부분의 경우 이 반패턴의 근본적인 원인은 기업의 강박관념에서 기인한다. 기업은 경쟁사의 움직임에 민감하다. 결과적으로 기업은 비즈니스 요구 사항들과 결부시키기 위한 충분한 시간과 노력을 들이지 않은 채 SOA를 채택할 때 기술적인 노력만 기울이기 십상이다.

• 솔루션

  이러한 반패턴을 해결하는 최고의 방법은 진정한 SOA 가치를 제안하는 것이다. SOA가 클라이언트가 느끼는 고통의 핵심이나 비즈니스 도전 문제를 다루고 있다는 것을 제시함으로서 이를 실현할 수 있다. 이러한 접근 방식은 비즈니스를 지원하는 기술을 도입하기 위한 로드맵을 개발하면 보완이 된다.

• 솔루션 예제: 진정한 SOA 가치 제안에 기반한 SOA 플랫폼을 개발한다.

  세계적인 렌터카 회사는 SOA 솔루션의 가치 제안을 이해하고 있다. SOA가 자신들의 핵심 비즈니스를 지원할 것을 이해하고 있다.

  • 유연한 비즈니스 모델을 통해 새로운 비즈니스 서비스를 공급할 때 속도와 유연성을 높인다.
  • 프로세스를 체계화 해서 비용을 낮추어 운영 비용을 줄인다.
  • 외부 비즈니스 프로세스의 순환 시간과 비용을 줄인다. 소비자에게 혁신적인 서비스를 공급한다.
  • 기업 내에서 쉽고 유연한 통합을 활성화 하여 여러 딜리버리 채널을 지원한다.

A2: 반패턴 이름: 기존 기술과 SOA와의 차이에 대한 이해의 부족

• 문제

  이 반패턴은 SOA는 그저 똑 같은 기술의 다른 이름일 뿐이고 SOA라고 해서 과거에 하지 못했던 완전히 새로운 일을 할 수는 없을 것이라는 회의적인 시각이다. 표면적으로는 그러한 주장이 타당성 있어 보이지만 웹 서비스와 XML의 출현이 중요한 차별요소가 된다.

• 정황

  이러한 반패턴은 오랜 시간동안 사용해 오던 기술에 편안함을 느끼고 변화를 꺼려 하는 IT 종사자들의 경향이다. IT 부서가 고통스러운 기술 변화를 경험했거나 새로운 기술이 뾰족한 수를 내지 못한 상황에서도 발생한다.

• 증상

  가장 분명한 증상은 몇 명 기술 관리자들의 강렬한 반대이다. SOA를 합법적인 비즈니스 문제를 다루는 심각한 접근 방식으로 치부해 버린다. 반대 표현 방식은 SOA 채택에 대한 강력하고 노골적인 논쟁이 될 수도 있고, 비즈니스 문제에 대한 솔루션 방식을 논하는데 있어서 SOA를 무시하는 수동적인 형태가 될 수도 있다.

• 결과

  결국 SOA에 대한 지원이 사라지면서, 비즈니스의 고통점을 해소할 수 있는 SOA의 가치를 실현할 기회를 놓치게 된다.

• 근본 원인

  SOA가 다른 컴퓨팅 패러다임(객체 지향과 컴포넌트 기반 개발)과 같은 원리로 구현되지만 많은 숙련된 IT 팀들 조차도 SOA와 기타 여러 컴퓨팅 패러다임 간 차이를 이해하지 못한다. 이러한 이해의 부족이 이 반패턴의 근본 원인이다. 또 다른 원인으로는 너무나 많은 “패러다임 변화”를 구현했을 때 실패 경험이 있는 IT 팀으로부터 기인한다.

• 솔루션

  이러한 반패턴에 대한 해결책은 SOA가 이전의 솔루션들과 얼마나 다른지를 강조하는 것이다. API와 서비스의 차이점이 연구되어야 하고 오픈 표준에 대한 의존성과 차별화 요소들에 대한 연구도 이루어져야 한다. 또 다른 큰 차이점으로는 엔터프라이즈 서비스 버스(ESB)가 SOA의 핵심 요소로 등장했다는 점이다. 전송 서비스, 중재 서비스, 이벤트 서비스 등 ESB가 제공하는 장치들은 SOA를 채택함으로서 가능한 새로운 기능들이다. 하지만 가장 효과적인 솔루션은 차이점들을 강조하는 성공적인 사례를 제공하여 SOA 솔루션을 구현할 때의 실질적인 성공 요소를 보여주는 것이다.

• 솔루션 예제: SOA 교육

  SOA가 무엇인지, SOA의 가치와 효용에 대해 비즈니스와 IT를 교육한다. 과거의 패러다임 변화와 구별되도록 웹 서비스와 XML 표준의 중요성은 물론 SOA 구현 시 필요한 표준을 이해시킨다.

A3: 반패턴 이름: “빅뱅” 접근방식 (분수를 넘는 행동)

• 문제

  이 반패턴은 "기존 기술과 SOA와의 차이에 대한 이해의 부족 " 반패턴과 정 반대이다. 여기에서의 문제는 SOA를 만병통치약으로 간주해 버린 것이다. 모든 기업 시스템과 아키텍처를 한꺼번에 바꾸려고 한다.

• 정황

  이러한 반패턴은 "충분한 검토 없이 새로운 기술을 성급히 도입하기" 반패턴과 같은 정황이다. 특히 주요 주주들은 기술적인 성향이 강하고 비즈니스 담당자 보다 영향력이 있어서 비즈니스에 미치는 영향에 상관없이 "분수 이상의 것을 취한다. "

• 증상

  SOA를 채택하기 위해 필요한 변화들에 대해서 너무나 많은 사안들이 생겨난다. 이것이 바로 반패턴의 증상이다.

• 결과

  이러한 반패턴의 결과로 SOA가 약속하는 효과를 제대로 전달하지 못하게 된다. 이것 때문에 기존 아키텍처로 회귀하여 SOA의 잠재적 효용성 마저 제거하게 된다. 그리고 근본적인 원인을 찾기 보다는 SOA에 모든 책임을 전가하게 된다.

• 근본 원인

  어떤 기업에서건 열정적인 기술은 이 같은 반패턴의 근본 원인이 될 수 있다. 기술이 IT 결정에 지대한 영향을 끼치는 경우에 특히 그렇다.

• 솔루션

  이러한 반패턴에 대한 솔루션 중 하나는 비즈니스가 지원하는 로드맵을 개발하여 SOA로 점증적으로 이동하는 것이다. SOA로 완전히 변화하여 모든 기업의 문제들을 해결하려는 대신 파일럿 케이스부터 구현하는 점증적인 방식을 채택하여 파일럿이 성공했을 때 그 로드맵을 사용하여 다음 비즈니스 타겟으로 옮겨가는 것이 더 낫다. SOA로 진입하기 위한 교육을 할 수 있다면 더욱 좋다.

• 솔루션 예제: SOA를 구현하는 로드맵 개발

  대형 은행은 자신들의 비즈니스 목표에 SOA 솔루션이 적합하다는 판단을 내렸다. 우선 서비스 통합의 관점에서 성숙도를 평가했다. 그런 다음 로드맵을 만들어서 은행이 점증적으로 SOA 환경으로 이동하여 위험 요소를 최소화 하면서 필요한 비즈니스 기능을 제공한다. 파일럿 프로젝트가 선택되어서 SOA 아키텍처 스타일을 검토하고 SOA 패러다임으로 이동하는 동안 기술이나 조직적인 문제를 해결한다.

위로

SOA 확인 & 디자인 반패턴

지금 소개하는 반패턴들은 실무자들이 SOA 이니셔티브의 일부로서 서비스를 규명하고 설계하면서 부딪치는 반패턴들이다.

I1: 반패턴 이름: 웹 서비스 = SOA (서비스 증식 증후군)

• 문제

  많은 사람들은 SOA를 웹 서비스의 또 다른 이름으로 알고있다. 웹 서비스를 구현하는 것이 SOA 채택에 대한 합법적인 진입점이 되는 것은 사실이지만 그렇다고 해서 웹 서비스와 SOA를 같은 것으로 볼 수는 없다.

• 정황

  요즘 제품화된 웹 서비스 시스템 대부분은 SOA가 아니다. 이들은 단순한 원격 프로시저 호출이거나 SOAP이나 다른 통합 아키텍처를 통한 점대점 메시징 일 뿐이다. 기업들은 웹 서비스를 구현하는 것으로 SOA로 전향했다고 주장한다.

• 증상

  적절한 아키텍처 없이 기존 API를 웹 서비스로 대체하는 것이나 비즈니스와 제휴 되지 않은 서비스 구현이 이 반패턴의 증상이다.

• 결과

  웹 서비스의 증식은 이러한 반패턴의 직접적인 결과이다. 서비스들이 진정한 SOA가 지향하는 가치를 지녔는지 여부를 따지지 않고 웹 서비스로서 아무 인터페이스나 구현한 결과이다. 또한 결과 시스템도 서비스 요청자의 요구사항을 반영하는 인터페이스를 갖추지 못한다.

• 근본 원인

  이러한 반패턴의 근본 원인은 두 개의 범주로 나뉜다. 첫 번째는 성급함이다. 지름길을 취하려는 의도이거나 SOA를 빠르고 저렴하게 수행하려는 태도이다. 두 번째는 SOA와 웹 서비스의 차이점도 잘 모르고 좋은 서비스 모델링 기술이 필요하다는 인식의 부재 때문이다.

• 솔루션

  이러한 반패턴에 대한 솔루션으로는 실현 가능한 SOA 변환 계획을 세우는 것이다. 기업은 SOA 가치를 정의해야 한다. SOA의 가치를 실현하려면 SOA와 웹 서비스 모두 필요하다. SOA와 웹 서비스에 대한 교육도 이루어져야 하고 SOMA (Service-Oriented Modeling and Architecture) 같은 좋은 서비스 모델링 방식도 적용해야 한다.

• 솔루션 예제: 서비스 모델링을 적용하여 대 단위 서비스를 구분하고 SOA 솔루션을 위한 구현 기술로서 웹 서비스를 활용한다.

  좋은 서비스 모델링 기술을 채택하여 비즈니스 솔루션에 대한 대 단위 서비스를 결정하고 웹 서비스를 활용하여 SOA 솔루션을 구현한다. 올바른 서비스 세분성 레벨을 통해 서비스 증식을 최소화 할 수 있다. SOA 가치를 실현하기 위해서는 SOA와 웹 서비스 모두 필요하다.

I2: 반패턴 이름: “사일로(silo)” 접근방식

• 문제

  이 반패턴의 문제는 서비스가 규명되는 방식에서 기인한다. 서비스가 기업의 전략에 초점을 맞추기 보다는 고립된 애플리케이션에 기반하여 구분될 때 SOA 구현에서 기대할 수 있는 가치는 실현될 수 없다.

• 정황

  고립된 채 작업하는 기능 모델에 기반하여 구성된 기업이 이 반패턴의 유력한 후보이다. 각각의 기능적 요새가 주장하는 자율성은 사일로 접근 방식으로 이어진다.

• 증상

  같은 서비스들이 다른 이름을 가진 다른 그룹들로 구분된다. 공통 서비스를 정의할 수 없다거나 서비스 공유가 이루어지지 않는다면 이러한 반패턴이 깊게 침투한 것이다.

• 결과

  “사일로(silo)” 접근방식의 결과로 서비스들은 여러 번 구분 및 구현되기 때문에 불필요하거나 중복된 서비스들이 개발된다. 더욱이 이러한 반패턴 때문에 다른 애플리케이션들의 재사용이 줄어들거나, 완전히 없어지게 된다.

• 근본 원인

  대부분의 경우 기업의 경계선과 제약은 이러한 반패턴의 근본 원인이다. 어떤 기업의 경우 “서비스 노출 결정”에 대한 지정된 방식이 없는데 이것 역시 원인이 된다.

• 솔루션

  솔루션은 요새화 된 서비스 구분과 통신을 관리하는 감독 프레임웍을 만드는 것이다. 또한 공통적인 서비스들이 제안 및 실행되어야 한다. 이는 SOMA 같은 서비스 모델링 방식을 사용하여 실행될 수 있다.

• 솔루션 예제: 공통 서비스 규명

  대부분의 기업들과 마찬가지로 대형 은행은 비즈니스 요새들로 조직되었다. 다양한 은행 고객에게 비슷한 비즈니스 기능들을 제공한다. SOMA가 적용되어 서비스 모델을 개발하여 비즈니스 요새들 간 재사용 기회를 활용하도록 한다. 최상위 레벨에서는 약 90 퍼센트의 비즈니스 서비스가 비슷하고 재사용 기회가 있는 것으로 판명된다.

I3: 반패턴 이름: 잘못된 레지스트리

• 문제

  SOA 관리 모델에 대한 동의 없이 UDDI를 채택하면 프로세스 비효율성과 디자인 비효율성으로 이어진다. 특히 중복되는 레지스트리는 형편없는 퍼포먼스의 원인이 되고 보안 및 순응성에도 위협을 가하게 된다.

• 정황

  레지스트리 관리에 대한 동의는 없지만 UDDI를 사용하려는 기업들에게서 이러한 반패턴이 발생한다.

• 증상

  UDDI는 표준이지 제품이 아니다. 그릇된 사용은 중복된 서비스 레지스트리와 오버래핑 그리고 잘못된 소유권으로 이어질 수 있다. 공유 서비스 모델 내에서 합성 서비스 시나리오를 발견하는 동안 부정확하고 잘못된 서비스 인터페이스 정보의 형태로 나타난다. 레지스트리에 정확한 디스크립션을 가진 서비스 인터페이스에도 불구하고 중복 엔트리들이 부정확한 서비스의 발견을 유도 시킨다. 더욱이 관리 모델의 부재는 다양한 사이클을 가진 프로세스와 함께 등록되지만 곧 버려진다. 예를 들어, 개발자는 내부 UDDI에 세 개의 서비스를 추가할 수 있다. 서비스 관리자는 이중 두 개만 선택하여 제품 UDDI로 이동시킨다. 고아 서비스가 생긴 것이다. 비슷한 상황이 서비스 컴포넌트에도 발생한다.

• 결과

  SLA에 부합되지 않는 어떤 레지스트리에 어떤 서비스가 있는지 확인해야 할 때 이렇게 중복된 레지스트리 때문에 관리가 힘들어지고 런타임 혼란이 생긴다. 게다가 심각하게 형편없는 퍼포먼스와 보안 및 순응성 허점 역시 이러한 중복에서부터 기인한다. 중복에 의한 예상치 못한 비용 역시 이 반패턴의 결과이다.

• 근본 원인

  SOA 관리 모델의 부재가 이 반패턴의 원인이다. 특히 부정확한 서비스 레지스트리 소유권과, 확고한 엔터프라이즈 레벨의 SOA 레퍼런스 아키텍처가 부족하다는 것이 이 문제의 핵심이다.

• 솔루션

  기업은 서비스 레지스트리 사용법, 소유권, 관련 팀들간 통신 등을 정의하는 SOA 관리 모델을 확립해야 한다. 이로서 중복되고 부정확한 서비스 인터페이스 정보가 없어지고 고아 서비스가 생기는 것을 최소화 할 수 있다. 런타임 혼란 역시 단 한 개의 서비스 디스크립션 소스로 해결될 수 있다. 이 디스크립션에는 SLA와 정책들이 포함된다. SOA 엔터프라이즈 레벨 레퍼런스 아키텍처와의 순응성을 확립하는 것 역시 SOA 관리 모델을 제도화 하는데 중요한 단계이다.

위로

SOA 실현 반패턴

다음의 반패턴들은 서비스를 구현하는 최악의 실례들이다.

R1: 반패턴 이름: 볼품없는 서비스

• 문제

  이 반패턴은 개발자가 많은 웹 서비스들을 구현하는 데서 생겨난다. 이 웹 서비스들은 소량의 데이터들과 통신한다. 또 다른 경우는 서비스의 구현이 포괄적인 문서 형태로 데이터를 구성하기 보다는 소량의 정보 조각들과 통신하는 하찮은 다이얼로그가 되는 경우이다.

• 정황

  개발자가 적절한 모델링 없이 구현을 시작하려 들 때 이 반패턴의 희생자가 된다. 개발자는 API를 웹 서비스로 대체해야 하고 SOA의 효용성을 이해하지 못한 채 개발을 해야 할 경우가 있다. 이는 반패턴으로 이어지게 마련이다.

• 증상

  상당히 세분화된 많은 서비스들을 구현해야 한다면 이 반패턴이 적용된 것으로 볼 수 있다.

• 결과

  퍼포먼스의 강등과 값비싼 개발이 이 반패턴의 결과이다. 게다가 소비자들은 이렇게 과도하게 세분화된 서비스들을 모아서 사용해야 하고 서비스들을 사용하는 방법을 터득해야 한다.

• 근본 원인

  더 나은 것을 알지 못하기 때문에 많은 개발자들이 취하는 접근 방식이란 고작 웹 서비스의 형태로 된 API 구현을 모방하는 것이다. 이는 객체 지향 패러다임으로 이동하던 초기에 우리가 겪었던 상황과 매우 비슷하다. 이때 개발자들은 객체 지향 언어를 사용하여 절차 프로그램을 개발했다. 또한 새로운 기술을 시도한다는 흥분이 모든 것을 쓸데 없이 웹 서비스화 해버리는 결과를 초래할 수도 있다.

• 솔루션

  이 같은 반패턴을 해결하려면 개별적인 데이터 조각들을 하나의 문서로 결합하는 디자인을 만드는데 초점이 맞춰져야 한다. 이로서 쓸모 없는 서비스를 제거할 수 있다. 정확한 서비스 세분성에 초점을 맞추고 API와 서비스의 차이를 알려주면 도움이 될 것이다. 하지만 이러한 반패턴을 피하는 가장 효과적인 방법은 비즈니스 목표로 이어지도록 서비스를 정의하는 것이다. 이는 좋은 서비스 모델링 기술을 채택하여 비즈니스 솔루션을 위한 대 단위 서비스를 결정함으로서 이루어 질 수 있다. SOA에 적절한 정확한 세분성 레벨로 구분되기 때문에 쓸모없는 서비스가 있을 수가 없다. Service Litmus Test (SLT) 역시 서비스 레벨을 결정하는데 도움이 된다. 서비스가 필요한 비즈니스 기능을 제공하는지의 여부를 결정하는 것도 SLT의 한 예이다.

R2: 반패턴 이름: 점대점 서비스

• 문제

  근본적인 문제는 사용 정황과 무관하게 통합 방식으로서 미들웨어 솔루션을 점대점 웹 서비스로 대체하려는데서 생긴다.

• 정황

  이 패턴은 장기적인 시스템 통합 계획이 부재한 기업에서 발생한다.

• 증상

  내부 애플리케이션들간 HTTP를 통해 XML이나 SOAP을 사용한다면 이 반패턴의 징조이다.

• 결과

  이 반패턴의 결과는 점대점 통합 솔루션이 기업의 통합 패턴으로 자리잡게 된다. 이렇게 되면SOA 구현에서 얻을 수 있는 효과는 없어진다.

• 근본 원인

  전체 시스템의 장기적 관리나 진화에 대한 인식의 부족이 이 반패턴의 근본적인 원인이다. 이는 단기적인 솔루션에만 치중했기 때문이다. 어디에서나 서비스를 사용할 수 있다는 신기함만으로 이 같은 점대점 서비스 방식이 번식하게 되었다.

• 솔루션

  이 같은 상황을 피하려면 통합 방식으로서 서비스 버스 같은 지능형 커넥터를 사용하는 것을 진지하게 검토해 봐야 한다. 서비스 버스는 애플리케이션이 간단하고 효율적으로 협업하도록 하여 협업 시스템들과 애플리케이션들 간 약결합을 유지하면서 비즈니스 필요를 지원한다.

• 예외

  솔루션 적용에 예외도 있다. 예를 들어, 단기간의 통합 시나리오는 즉각적인 비즈니스 문제들을 해결해야 하고 점대점 서비스가 사용될 수 있는 경우이다. 하지만 이러한 솔루션들이 제품에 꽤 오랫동안 머물러 있는 경향이 있다. 따라서 이러한 반패턴을 적용하는 것을 신중히 검토해야 한다.

R3: 반패턴 이름: 컴포넌트가 부족한 서비스 (한물간 논리적 레이어링)

• 문제

  좋은 서비스 모델링에서는 규명된 서비스들과 이들을 갖고 있는 컴포넌트들 간 제휴가 이루어 진다. 문제는 개발자가 소유 컴포넌트와의 명확한 제휴도 확보하지 않은 채 웹 서비스를 개발해 버리려는 경향 때문에 반패턴이 생긴다.

• 정황

  아키텍처 패턴이 적용되지 않은 상황에서 이 같은 반패턴이 생긴다. 아키텍처 패턴이 정해지지 않으면 이러한 반패턴만 조장된다.

• 증상

  서비스 구현에 대해 연구한 결과 어떤 아키텍처 구조로 연결되지 않은 채 시스템의 일부로 직접적인 접근이 허용되었다. 이 경우 웹 서비스는 레이어링과 영역의 분리에 상관없이 개발된다.

• 결과

  가장 뚜렷한 결과는 서비스 인터페이스 이상으로 유연성이 떨어진다는 점이다. 모듈식 디자인, 정보 숨기기, 논리적 구조화 원리 모두 위반했기 때문이다. 이로서 기존 애플리케이션과 패키지가 가진 한계들을 고스란히 보유하게 되어 미래에도 사용할 수 없게 된다.

• 근본 원인

  좋은 사례들을 무시한 여러 상황들과 마찬가지로 이 반패턴의 근본적인 원인은 좋은 디자인의 부재에서 기인한다.

• 솔루션

  컴포넌트와 SOA의 진정한 힘은 이 두 가지를 모두 갖출 때 실현될 수 있다. 유연한 컴포넌트 기반 애플리케이션으로 지원되는 서비스 인터페이스들이 솔루션이 될 수 있다. 개발자들은 J2EE와 EAD와 레이어링 패턴을 지속적으로 활용해야 한다.

• 솔루션 예제: SOA와 컴포넌트의 가치를 이해한다.

  서비스는 컴포넌트를 사용하여 최적으로 구현된다. 컴포넌트 없이는 서비스 인터페이스에 경직성만 남게 된다. 구현의 확장성과 이동성에 관한 문제도 남아있다. 기존 애플리케이션과 패키지는 그 한계를 계속 유지하게 되고 이로서 변화하는 비즈니스 필요를 지원하는데 필요한 융통성을 잃게 된다. 컴포넌트는 확장성과 유연성을 제공하여 서비스 인터페이스와 약결합 및 재사용 기능을 지원한다.

위로

요약

이 글을 통해 SOA의 채택, 규명과 디자인, 구현에 영향을 미치는 SOA 반패턴에 대해 알아보았다.

감사의 말

이 글에 도움을 주신 분들에게 감사의 말을 전합니다.

• JeanPierre Paillet
• Kerrie Holley
• Kyle Brown
• Mike Ellis
• Olaf Zimmermann
• Prathap Gangula
• Rick Robinson
• Rolando Franco
• Sri Ramanathan

위로

참고자료

• For more information on antipatterns, check out the following books:
  • The Timeless Way of Building, by C. Alexander
  • Notes on the synthesis of form, by C. Alexander
  • The Oregon Experiment, by C. Alexander
  • A Pattern Language: Towns, Buildings, Constructions, by C. Alexander
  • Antipatterns: Refactoring Software, Architecture, and Projects in Crisis, by W. Brown, R. Malveau, H. McCormick III, and T. Mowbray
  • J2EE Antipatterns, by B. Dudney, S. Asbury, J. Krozak, K.Wittkopf
  
  
• Web Services Architecture & Best Practices (IBM WebSphere Developer Technical Journal, Oct 2003)
  
  
• ""쓴 자바"의 맛" (developerWorks, March 2002)
  
  
• SOA and Web services
  
  
• Architecture: Build for the future
  
  

• developerWorks blogs

위로

필자소개

	Jenny Ang, Executive IT Architect, IBM

	Luba Cherbakov, IBM Distinguished Engineer, IBM

	Dr. Mamdouh Ibrahim, Senior Certified Executive IT Architect, IBM

위로

기사에 대한 평가

매우 불만족 (1) 불만족 (2) 보통 (3) 만족 (4) 매우 만족 (5)

위로