IBM®
메인 컨텐츠로 가기
    Korea [국가변경]    이용약관
 
 
   
        제품    서비스 & 솔루션    고객지원 & 다운로드    회원 서비스    
메인 컨텐츠로 가기

한국 developerWorks  >  웹서비스  >

SOA에 맞는 재사용(reuse) 방법

developerWorks
문서 옵션

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


난이도 : 중급

Rich Rogers, 선임 기술 스태프, IBM

2005 년 9 월 09 일

소프트웨어 재사용 개념을 서비스 지향 아키텍쳐(SOA)에 적용해 보고, 이러한 재사용 엔지니어링이 SOA의 가치를 높이는데 어떤 영향을 주는지를 살펴보자.

머리말

효과적이고 체계적인 소프트웨어 재사용은 많은 기업들의 꿈 같은 목표이다. 기업이 재사용을 추구하는 이유는 오늘날에도 쉽게 찾아 볼 수 있다. IT 비용 절감과 IT 아키텍쳐와 기반 시스템의 유연성과 응답성에 대한 욕구가 이를 증명하고 있다.

재사용을 방해하는 요소를 규명하기는 쉽다. 하지만 이러한 방해요소를 극복하기 위한 해답은 쉽게 떠오르지 않는다. 서비스 지향 아키텍쳐(SOA)는 소프트웨어 재사용을 실현하기 위한 토대를 제공한다. 소프트웨어를 재사용이 부여하는 많은 혜택들이 바로 SOA의 가치가 된다.




위로


재사용을 권장하는 SOA

developerWorks와 다른 개발자 사이트에서 SOA의 사용법을 다룬 글을 읽어보면 SOA에서 인터페이스의 중요성을 많이 강조하고 있다. 서비스 인터페이스는 통합 디자인의 핵심이다. 인터페이스는 서비스 클라이언트와 서비스 공급자가 프로그래밍 언어와 플랫폼에 상관 없이 서로 통신할 수 있는 곳에 약결합을 구현하는 필수 요소이다. 서비스는 독립적이 된다. 클라이언트는 서비스 컴포넌트의 내부 작동을 알 필요가 없다. 특히나 서비스는 "블랙 박스"로서 작동한다. "화이트 박스"의 재사용 또는 가감(cut & paste)은 "블랙 박스 재사용"만큼 효과적이지 못하다. 체계적인 재사용 프로그램들은 소프트웨어를 수정하지 않은 채 재사용 할 것을 권장하고 있다. 블랙 박스를 재사용 하면 더 나은 효과를 얻을 수 있기 때문이다. (소프트웨어 재사용 평가: 원리, 활용법 및 모델– 참고자료). 서비스는 기능을 캡슐화 한다. 비즈니스 기능이든 일반 유틸리티 기능이든 상관 없다. developerWorks 기술자료, "서비스 지향 아키텍쳐로의 마이그레이션" (참고자료)에 SOA 애트리뷰트에 대해 자세히 설명하고 있다.

SOA의 이러한 모든 특징들이 소프트웨어 재사용이 성공할 수 있는 토대가 된다. 하지만 재사용을 권장하는 SOA 개념과 기술이 있음에도 불구하고 전통적으로 재사용을 방해하는 문제들이 여전히 존재한다.




위로


재사용 방해요소

개발 단계에서 소프트웨어 재사용은 빈번히 발생한다. 코드는 비공식적으로 프로젝트들을 통해 공유된다. 서비스 클라이언트가 서비스에 액세스 할 때, 재사용을 해도 될 만한 상황에서 SOA는 공식적인 재사용 메커니즘을 제공한다. 재사용자(서비스 클라이언트)는 그들이 어떤 코드를 재사용하고 있는지를 실제로 모를 뿐더러 신경 쓰지도 않는다. 그들은 단지 그 서비스가 자신들이 원하는 기능을 제공하고 있다는 것만 알 뿐이다. 그렇다면 무엇이 문제인가? 재사용 가능한 서비스의 생성과 사용에 관련된 문제들을 살펴보자.

- 교육과 문화: 웹 서비스 같은 SOA 기술이 프로젝트 팀에게는 생소할 수 있다. 따라서 이 서비스를 활용하기 전에 이 기술부터 배워야 한다. 프로젝트 팀이 사용할 수 있는 서비스를 효율적으로 찾고, 이 서비스들이 무엇을 하는지를 이해하고, 프로젝트에 주는 혜택을 결정하도록 함으로서 서비스 재사용 가치를 실현할 수 있다. UDDI 레지스트리는 중요하지만 충분하지 않다. 재사용 서비스를 모색하는 팀은 추가 정보가 필요하다. 서비스 학습 곡선은 재사용 가치를 떨어트리고 따라서 재사용 할 것인지 아니면 새로 구현 할 것인지를 결정할 때의 요소가 된다.

- 재사용 서비스의 가용성: 재사용 서비스의 진정한 가치는 서비스 재사용이다. 서비스들이 기업에서 어떤 역할을 할 것인지를 결정하고 실제로 구현하여 사용하는 것은 어려운 일이다. 공유성을 결정하기 위해 영역 분석을 수행해야 한다. 그리고 어떤 유형의 서비스가 재사용 가치가 있는지를 결정해야 한다. 기업의 프로젝트 팀은 솔루션 소프트웨어를 만들 때 그 소프트웨어 안에 재사용 서비스들로 프로젝트 팀은 솔루션을 위한 소프트웨어를 만든다. 여기에는 재사용 서비스들을 획득하고 강화할 수 있는 좋은 서비스 후보들이 포함된다. 이러한 기회들을 어디에서 찾을 수 있는지를 파악하는 것은 상당히 어렵다. 그 기회를 실행에 옮기는 것 역시 힘들다.




위로


재사용 엔지니어링

재사용 엔지니어링은 재사용 전문가(재사용 엔지니어)들로 구성된다. 자산의 소비와 생산 분야에서 프로젝트 팀을 돕는다. Journal of Systems and Software의 "Incentive compatibility and systematic software reuse"(참고자료)에서 Robert Fichman과 Chris Kemerer는 다음과 같이 설명한다.

재사용 센터의 재사용 엔지니어들은 실제로 애플리케이션 개발팀에게 일종의 "대출"을 해주는 것과 같다. 재사용 소비 측면에서 볼 때, 재사용 엔지니어들은 어떤 것이 잠재적으로 재사용 가능한지를 알려주고 수정이 필요할 경우 이를 돕는다. 제품 측면에서 재사용 엔지니어들은 새로운 컴포넌트를 만들어낼 최상의 기회가 어디에 있는지를 규명하고 그러한 컴포넌트가 재사용 될 수 있는 것으로 만드는 작업을 보조한다. 프로젝트가 끝나갈 무렵에, 재사용 엔지니어들은 영역과 재사용 될 새로운 자산을 분별하게 되고 기존 자산 중에서 어떤 것을 "있는 그대로" 보존할 것인지 그리고 픽스와 향상이 필요한 부분은 무엇인지를 분별하게 된다.

재사용 엔지니어들은 기술적으로 숙련되어야 하고 프로젝트 경험을 갖고 있어야 하며 궁극적으로는 재사용 실행자이다. 재사용 엔지니어 역할의 핵심은 그들의 위치를 프로젝트 팀 전반에 걸쳐 확대하는 것이다. 소프트웨어 재사용은 재사용 엔지니어의 임무이고 그들은 전형적으로 그들의 영향력이 미치는 범위 내에서 재사용 결과와 관련된 목표를 정하고 이를 측정한다. 이렇듯 역할에 초점을 맞추는 것은 재사용 프로그램과 SOA 이니셔티브의 성공에 매우 중요하다. 극히 일부 기업들만 체계적인 재사용을 성공적으로 수행하는 이유도 광범위한 포커스 대신 한번에 한 프로젝트에 집중하기 때문이다. (Software Reuse: Architecture, Process and Organization for Business Success -- 참고자료) 재사용 엔지니어링을 기업에 적용했던 나의 경험을 통해서 앞서 설명한 것처럼 전통적인 재사용 방해요소를 다루는 것이 효과적이라는 것을 깨달았다.

교육과 문화

프로젝트 팀과 함께 작업하는 SOA 기술력을 갖춘 재사용 엔지니어들은 SOA의 채택에 대한 장벽을 낮출 수 있다. 프로젝트 매니저들은 그들의 프로젝트에 대한 위험성을 완화시키도록 훈련 받는다. 누군가의 소프트웨어를 재사용한다는 것은 매우 위험한 일일 수 있지만, 재사용 엔지니어들이 사용 가능한 서비스들을 배치하는 전문가들이라는 점에서 이러한 위험성을 완화시킨다. 이들은 프로젝트 팀과 협력하여 필요를 평가하고 이해하고 그런 다음 서비스의 검색, 이해 분석을 신속히 처리하여 어디서 어떻게 이들을 사용할지를 알려준다. 또한 그 서비스를 사용했던 다른 프로젝트에서 경험했던 지식을 공유한다. 이 모든 것은 학습 곡선을 줄이고 재사용 위험성도 줄인다. 엔지니어들은 기존 소프트웨어에 미치는 영향을 최소화하면서 SOA 서비스 사용을 유도하는 최고의 방법에 대해 팀을 교육할 수 있다. 애플리케이션 내에 기능을 제공하는 대신 서비스를 사용하도록 변경할 때 애플리케이션 코드에 미치는 영향을 최소화하는 Adapter 디자인 패턴의 사용을 도입하는 것이 그 한 예이다.

재사용 엔지니어링은 기업 문화에 긍정적인 영향을 미친다. 소프트웨어 재사용은 새로운 것이 아니다. 그리고 개발 조직의 다양한 성공 역사도 갖고 있으며 수 년 동안 시도되었다. 결과적으로, 재사용 개념은 대부분의 사람들이 알고있다. 이것이 긍정적이냐 부정적이냐 아니면 그 중간이냐의 차이일 뿐이다. 재사용 엔지니어들은 검색 박스나 검색 폼으로 결코 나타나지 않는 프로젝트의 필요를 이해할 수 있다. 협동적인 재사용 노력으로 달성될 수 있는 부분이 있다는 것을 인식하게 되면서 프로젝트 팀과 재사용 엔지니어들 간 놀라운 관계를 만든다. 재사용 엔지니어라는 채널을 통해 프로젝트 팀은 재사용 소프트웨어 자산들을 서비스의 형태로 생성할 수 있는 기회들을 이용할 수 있다.

재사용 서비스들의 가용성

서비스 생성은 다양한 방식으로 이루어진다. 어떤 서비스들이 한 기업에 가치가 있는지를 이해하는 것이 첫 번째 단계이다. SOMA (서비스 지향 모델링과 아키텍쳐(Service-Oriented Modeling and Architecture--참고자료)는 매우 안정적인 방식이다. 재사용 엔지니어링은 주제 도메인을 이해할 수 있는 수단을 제공한다는 점에서 SOMA를 보완하고 있다.

도메인 분석은 도메인 전반에 존재하는 공유성을 결정하는 수단이고 따라서 어떤 유형의 서비스가 재사용 가치를 갖고 있는지를 결정한다. 도메인 분석은 많은 방식으로 달성될 수 있다. 재사용 엔지니어링 모델을 사용하여 한 개의 프로젝트를 한번에 발생시킨다. 재사용 엔지니어들이 프로젝트 팀과 협업하듯 이들은 프로젝트 팀이 수행해야 하는 기능을 포착할 수 있다. 주어진 도메인에서 이러한 정보의 분석은 중복 노력이 어디에서 존재하는지 그리고 재사용 가치를 만들기 위해 서비스가 어디에 도입될 수 있는지가 나타난다. 이러한 접근 방식은 기업의 아키텍쳐 방향과 프로젝트 팀이 제공하는 실제 솔루션 아키텍쳐 간 차이로 인해 발견되지 않는 광범위한 재사용에 대한 기회를 이해하는데 특별히 효과적이다. (developerWorks 기술자료, "Elements of service-oriented analysis and design" (참고자료) 발췌.) 이러한 일반 서비스 기회들은 SOA의 가치를 빠르게 나타낼 수 있고 투자를 이끈다는 점에서 매우 매력적이다.

기업 내의 애플리케이션에 대한 사용자 액세스 밸리데이션 같은 일반적인 기능을 생각해보자. 호환성에 대한 관심이 커지면서 이와 같은 비즈니스 제어는 훨씬 중요해졌다. 이 기능을 제공해야 하는 요구사항은 광범위 하기 때문에 솔루션은 정말 기업 전반에 걸쳐 거듭 재 고안 되어야 한다. 하지만 중앙에서 제어 시스템이 부족하고 IT 비용이 많이 낭비되고 있다. 이러한 유형의 기능은 애플리케이션들이 이종의 엔터프라이즈를 통해 사용할 수 있는 재사용 서비스 세트로서 제공된다. 다양한 계층의 사람들(CFO 부터 애플리케이션 개발자까지)은 SOA의 가치를 실현하고 실질적인 방식으로 재사용한다.

재사용 엔지니어들이 이러한 기회를 포착하게 되면서 SOA로의 마이그레이션 비용을 줄일 수 있는 방법들을 이해했다. 재사용 엔지니어들은 서비스 후보 목록을 만든다. 이것은 프로젝트 팀이 그들의 솔루션을 위해 만들었던 소프트웨어이다. 이것은 재사용 가능한 서비스들을 발견하고 강화시킬 만한 좋은 후보가 되어 도메인 분석을 통해 필요를 채울 수 있다. 이러한 기회들이 어디에 존재하는지를 이해하는 것은 어렵다. 재사용 엔지니어들은 범주 별로 브리드 구현을 결정하고 일반 서비스를 만든다. 재사용 엔지니어링 팀은 그 서비스를 전달한다. 대안으로는 이전 프로젝트에서 수행된 작업과 새로운 프로젝트의 요구 사항들을 이어서 새로운 프로젝트의 범위 내에서 서비스를 강화시키는 방법도 있다. "next project generalization" model (Measuring Software Reuse : Principles, Practices, and Economic Models -- 참고자료)은 재사용 가능한 서비스들의 가용성을 높이며, 잃기 쉬운 기회들을 발견 및 수행하는 열쇠이다.




위로


요약

재사용은 성공적인 SOA의 필수 요소이고 SOA 비즈니스 케이스에 기여하는 바가 크다. 재사용 엔지니어링을 통해 소프트웨어 재사용 방식을 SOA에 적용하고 전사적으로 서비스의 생성과 소비에 효율성을 제공할 수 있다.




위로


참고자료




위로


필자소개

Photo of Rich Rogers

Rich Rogers, 선임 기술 스태프, IBM





위로


기사에 대한 평가

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




위로



    IBM 소개개인정보 보호정책문의