 | |
|
난이도 : 초급 Kunal Mittal, Director, Domestic TV IT, Sony Pictures Entertainment
2007 년 1 월 30 일 서비스 지향 아키텍처(SOA) 프로젝트의 디자인이 아무리 완벽하게 보여도, 비즈니스 요구 사항을 만족시키지 못하면, 실패한 디자인입니다. 초기 SOA 개발에 필요한 모든 기술적 요구 사항들을 파악하는 원리와 방법을 설명합니다.
기존 IT 프로젝트와 비교해 볼 때, 서비스 지향 아키텍처(SOA) 프로젝트는 요구 사항들을 모으고 요구 사항들을 다루는데 있어서 더 많은 어려움에 직면하게 된다. 선두 기업에서 제공하는 아티클과 연구 자료에 따르면, IT 프로젝트가 실패하는 주 원인은 올바른 요구 사항의 부족 때문이라고 한다. IT 프로젝트 매니저, 아키텍트, 개발자라면, 이러한 문제를 직접 경험해봤을 것이다. 상당히 많은 프로젝트들이 예산을 초과하고, 부실하고, 부정확하고, 자주 변하는 요구 사항 때문에 정해진 개발 기간을 맞추지 못하고 있다. 끝에 가서는, 기술은 문제가 되지 않는다. 가장 효율적인 아키텍처를 가지고, SOA를 채택하고, 모든 표준 기술들을 활용하고, 강력하며, 기대 이상의 것을 수행하지만, 원래의 비즈니스 요구 사항을 맞추지 못한다면 시간과 돈의 낭비일 뿐이다.
요구 사항들을 모으는 데는 특별한 지식(science)과 기술(art)이 필요하다. 예를 들어, 인간적인 요소를 피할 수 없다. 사람들은 종종 마음을 바꾼다. 요구 사항을 100 퍼센트 파악할 수 있다거나, 요구 사항이 변하지 않을 것이라고 가정하는 것은 말이 되지 않는다. 훌륭한 비즈니스 분석가는 사용자들을 개입시키고, 정확한 요구 사항들의 가치에 대해 사용자들을 납득시킨다. 분석가는 이 프로세스에 사용자의 참여가 왜 중요한지를 인식시키고, 변경 또는 누락에 대해 책임도 지도록 한다. "garbage in, garbage out", 즉 빈약한 요구 사항으로 시작했다면, 쓸모 없는 제품만 만들게 될 것이다.
세 Part로 구성된 본 기술자료 시리즈에서는, SOA 구현의 요구 사항 프로세스에 대해 설명할 것이다. Part 1에서는 SOA 프로젝트의 기술적 측면에 초점을 맞추고, 기술적인 요구 사항들을 정의하는 방법을 설명한다. Part 2에서는 요구 사항을 정의하고, SOA의 필수적인 부분인, 서비스의 유스케이스(use case)를 만드는 방법을 설명한다. Part 3에서는 지속적인 SOA 관리에 필요한 요구 사항들을 파악하는 방법을 설명한다. 본 시리즈에서는, 요구 사항들을 파악하는 툴로 IBM® Rational® RequisitePro®를 사용한다.
어디에서 시작해야 하는가?
SOA의 기초나 SOA 구현 로드맵에 대해서는 굳이 설명하지 않겠다. 여러분의 회사도 SOA 로드맵을 정의했거나, 또는 정의하는 과정에 있기 때문에, 그 부분에 대해서는 알고 있을 것이다. 아마도, 이러한 로드맵에서 시작 포인트도 파악했을 것이고, 서너 개의 서비스를 구현할 정도의 프로젝트 비용도 지원 받았을 것이다.
이 단계에서는, 먼저 두 가지 유형의 요구 사항들을 정의해야 한다. 서비스에 대한 요구 사항들과, 이 서비스를 지원하는 기술적 요구 사항이다. 이 글에서는 후자인 기술적 요구 사항에 초점을 맞추기로 한다. 비즈니스 요구 사항에 대해서는 두 번째 글에서 다루기로 한다. 비즈니스 요구 사항을 먼저 다루기를 바라겠지만, 기다려라.
비즈니스 요구 사항을 가장 먼저 다루고 싶지만, 대부분의 SOA 이니셔티브는 IT와 협업하는 비즈니스 팀 보다는 IT가 이끌고 있다. IT 그룹은 비즈니스보다 먼저 새로운 기술을 따른다. 여기에는 거버넌스, 지원, 비용 모델 등의 문제들이 수반된다. 이러한 기술의 최전방에는 Universal Description, Discovery, and Integration (UDDI) 레파지토리, 서비스를 구현하는 기술 프레임웍, Enterprise Service Buses (ESB) 등이 거론된다. 비즈니스 서비스를 선택하고, 개념 정의(POC)를 다루는 IT 그룹들은 거의 보지 못했다. 이들은 서비스도 선택하지만, 기술에 더 치중한다. POC에 어떤 기술을 사용할 것인지, 어떤 Extensible Markup Language (XML) 표준을 사용할 것인지, 무슨 플랫폼을 사용할지, 어떤 ESB를 사용할지에 대해서 생각한다. 이러한 시작 방법이 틀린 것은 아니다. IT 팀이 SOA를 시작할 때 이러한 측면들에 대해 합의를 이루지 못한다고 해서, 다음 회계 년도가 될 때까지 SOA 이니셔티브를 늦추거나 연기하는 것을 보지 못했다. 따라서, 나 역시도 여기에서 출발하여, 서비스의 비즈니스 요구 사항으로 옮겨가겠다.
세 Part로 이루어진 시리즈도 이러한 흐름을 따르기로 했다. 이 글에서는 기술적인 부분을 먼저 이야기를 할 것이다. 다음 두 개의 기술 자료에서는 비즈니스에 초점을 맞출 것이다. 우선, 초기 서비스에 대해 설명하고, 그러한 서비스의 관리와 활용에 대해서 설명하겠다.
SOA 요구 사항의 기술적 부분들
SOA에 대한 기술적 요구 사항을 어떻게 파악할까? SOA를 시작할 때, 세 개에서 다섯 개 정도의 서비스를 정의했다고 가정한다.
|
주의
세 가지를 주의하기 바란다. UDDI, ESB, 표준 개발 툴 또는 프레임웍이다. 내가 이상하다고 생각하겠지만, 다 이유가 있다. UDDI는 대단한 개념이다. 하지만, 여러분이 SOA를 시작할 때, 몇몇의 서비스와 비교적 잘 정의된 소비자 베이스를 갖추고 있을 것이다. 이러한 상황에서, UDDI는 과잉이다.
ESB도 마찬가지다. 몇 가지 서비스를 실행한다고 생각해 보자. 동적 바인딩을 사용하고(엔드 포인트가 결정되지 않음), 이러한 서비스들과 관련한 운영 기준이 있는 한, ESB 역시 과잉이다.
마지막으로, 여러분 회사 마다 개발 프레임웍과 툴을 표준화 했을 것이다. 그렇다면, 잘한 일이다. 그렇지 않았더라도, 상관 없다. 아마도 아키텍트와 개발자들을 배제했을 것이다. 서비스가 서비스 레벨에 대한 동의가 이루어졌다면, 기반 기술은 문제가 되지 않는다. 초기 서비스와 SOA도 마찬가지이다. 물론, 오프쇼어링(offshoring), 줄어든 개발 및 관리 비용, 새로운 리소스의 교육 등, 이러한 표준화와 관련한 문제들도 있다. 이들을 SOA와 분리시켜야 한다.
|
|
시작할 때에는 약간의 서비스를 지원할 수 있어야 한다. 다음 사항들을 정의해야 한다.
- 운영상의 서비스 레벨 계약(SLA)
- 지원 SLA
- 서비스 구현 요구 사항
- 전개 요구 사항
이러한 초기 서비스들이 마련되었다면, 다른 기술적 요구 사항들도 구체화 해야 한다. 다음 사항들이 포함된다.
- SOA 전반에 대한 장기적 운영 전략
- 서비스 발견, 프로비저닝, 전달과 관련한 거버넌스
- 서비스 지향 개발에 대한 베스트 프랙티스와 패턴
- 운영 관련 SLA
- 지원 관련 SLA
이제 ESB, 웹 서비스 관리 플랫폼, 엔터프라이즈 급 SOA를 만드는 기술에 대해 생각할 차례이다.
기술적 요구 사항 파악하기
기술적 요구 사항들을 파악하는 것은 결코 쉬운 일이 아니다. 예를 들어, 누군가에게 시스템의 반응 시간이 얼마나 빨랐으면 좋겠는가라는 질문을 한다면, "빠르면 빠를수록 좋다."라는 답을 들을 것은 자명하다. 기술적으로 볼 때, 이러한 요구 사항은 큰 도움이 되지 못한다. SOA의 경우, 기술적 요구 사항들을 파악하는 것은 더 어려운 일이다. 서비스의 운영 레벨을 정의할 수 있어야 한다. 응답 시간, 업타임(up time), 평균적인 동시 사용자들의 수 등이 그 예이다. 추가적으로, 서비스 레벨도 정의해야 한다. 예를 들어, 중요도 2 또는 3 버그와 비교하여, 중요도 1의 버그 픽스에 걸리는 시간, 새로운 기능이나 향상을 구현하는데 걸리는 시간 등이다. 서비스 소비자들에게서 이러한 요구 사항들을 모으는 일은 지식(science)이라기 보다는 기술(art)에 가깝다. 지식은 적절한 질문들을 정의하는 것이다. 기술은 구체적인 방식으로 그러한 질문에 답을 해주는 것이다.
|
요구 사항 파악 툴
물론, 요구 사항 리파지토리도 필요하다. Rational RequisitePro는 Rational Software Architect와 툴을 사용하여 디자인 및 구현할 때 특히 유용하다. (Rational RequisitePro에 대한 자세한 내용은 참고자료를 참조하라.)
|
|
기술 아키텍트 또는 기술 분석가는 초기 서비스의 소비자와 만나서, 이러한 정보를 파악해야 한다. SOA 프로젝트의 성공은 이러한 요구 사항들을 정확하고 현실적으로 파악할 수 있는 팀의 능력에 달려있다. 예를 들어, 시스템이 초당 백만 히트를 지원할 수 있고, 2초의 응답시간을 지원해야 한다는 요구 사항에 대해 생각해 보자. 이러한 레벨을 충족시키는데 필요한 시간과 돈은 프로젝트의 성공에 있어서 중요한 요소가 된다. SOA 프로젝트 파일럿의 경우, 작게 시작하여 유기적으로 성장할 수 있어야 한다. 반면, 이 서비스가 그러한 최상의 운영 레벨을 필요로 한다면, 다른 서비스 또는 서비스 세트를 선택해야 한다.
기타 요구 사항
SLA와 Operational-Level Agreement(OLA)는 가장 까다로운 기술적인 SOA 요구 사항들이다. 모든 사람들은 서비스가 가능한 빠른 시간에 응답을 하기를, 24/7 지원이 가능하기를, 무한 사용자 수를 지원하기를 바라기 때문이다. 서비스를 범위를 확립하는 것은 어려운 일이고, 서비스 구현에 필요한 시간과 비용과 균형을 맞추는 것은 더 어려운 일이다. 비즈니스 요구 사항들(Part 2 참조), SLA, OLA가 마련되었다면, 구현과 전개 요구 사항들을 맞춰야 한다. 앞서 언급했지만, 이 단계에서 기술, 프레임웍, 툴, 제품, 다른 많은 표준들에 묶여서는 안된다. 기본 표준으로 SOAP과 Web Services Description Language (WSDL)를 사용하여 간단하게 시작하라. 기업이 어떤 표준을 채택하고, 어떤 경험이 있든지 간에, .NET® 또는 Java™를 사용하라. 최소한의 개발 툴만을 선택하라. 개발 관점에서 볼 때, .NET을 선택했다면 Internet Information Server (IIS)를 사용하라. 자바를 선택했다면, Tomcat 또는 Geronimo 같은 간단한 애플리케이션 서버를 사용하라. 이 단계에서 JBoss는 필요 없고, WebLogic 또는 IBM WebSphere®도 제쳐두라. 하지만, 여러분의 기업이 특정 개발 컨테이너(WebSphere, WebLogic 등)로 표준화 되었다면 반드시 이들을 사용하라.
아키텍트는 앞선 생각을 가져야 한다. 작게 시작하지만, 머리 속에는 언제나 큰 그림이 있어야 한다. 자신이 갖고 있는 간단한 툴과 아키텍처를 사용하여 구현을 시작하라. 서비스가 성숙해지면, SOA에 대한 전체적인 기술적 요구 사항들을 정의할 수 있다. 궁극적인 아키텍처, 인프라스트럭처 요구 사항, 툴과 제품 요구 사항, 표준 레벨과 관련하여 더 나은 결정을 내릴 수 있는 더 많은 경험적 지식도 갖게 된다. 여러분이 선택한 서비스는 더 큰 스케일에서 결정을 내리는데 도움이 될 수 있는 요구 사항이 필요하다.
요약
이 글에서, 초기 SOA 프로젝트와 관련한 기술적 요구 사항 보다는 요구 사항 수집 프로세스를 어디서 시작할지를 중점적으로 다루었다. SOA는 큰 비전을 제공한다. 하지만, 이러한 비전을 달성하기 위해서는 작게 시작해야 한다. SOA의 모든 것을 다룬다면, 프로젝트는 지연될 수 있고 비용도 많이 들어, CIO는 비즈니스의 가치를 평가할 수 없을 것이다. 다음 예산 사이클 동안 이니셔티브를 미리 준비해야 하는 위험도 있다.
Capability Maturity Model (CMM)과 연계하여, SOA 프로젝트와, SOA 기술적 요구 사항을 파악할 수 있다. 시작할 때, 여러분은 CMM Level1에 있는 것이다. Level 2 또는 5에서 문제를 해결하려고 하지 말라. 단기적인 SOA 초점을 맞추고, 큰 그림을 머리 속에 그려라.
다음 글에서는 초기 SOA 서비스의 비즈니스 요구 사항을 설명할 것이다. 요구 사항들을 파악하는 방법을 설명하고, Rational RequisitePro 툴을 사용할 것이다. 하지만, 아이디어나 개념은 어떤 툴에도 적용된다. Microsoft® Office Word 또는 여느 공식 요구 사항 레파지토리를 사용하여 같은 정보를 파악할 수 있다.
기사의 원문보기
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | 
| | Kunal Mittal은 자바, J2EE, 웹 서비스 전문 컨설턴트이다. 이러한 분야의 많은 책들을 공동 집필하고, 기고 활동도 했다. Sony Pictures Entertainment의 Domestic TV IT 그룹의 디렉터로서, 아키텍처와 애플리케이션 관리를 담당하고 있다. 여가 시간에는 IBM developerWorks에 기고할 글도 쓰고, SOA와 관련한 자문도 한다. 웹 사이트, www.kunalmittal.com을 참조하라. (kunal@kunalmittal.com) |
기사에 대한 평가
| |
