|
|
|
|
충분한 검토·기획·적응 단계 필수 |
| 올바른 SOA 구현 방안 |
 |
2007년 09월 17일 00:00:00 |
데이터넷
|
 |
|
|
조직 구조.구성원 변화도 필수 … 민첩한 개발 방법론 고려
많은 기업들이 서비스 지향형 아키텍처(SOA) 프로젝트를 추진하고 있다. 그러나 이들 기업은 대부분 SOA가 모든 것을 해결해 주는 해답이 되리라는 신념으로 인해 여러 가지 문제점에 직면하게 된다. 이번호에서는 SOA가 다양한 혜택을 주는 것은 맞지만 충분한 기획 및 적응 단계를 거치지 않으면 기대했던 만큼의 효과를 거두기 어렵다는 점을 SOA를 구축하는 기업의 사례를 통해 짚어본다. <편집자>
 정대천 // 한국오라클 TSC 부장
daecheun.jeong@oracle.com
한 회사가 있다고 가정을 하자. IT관리자와 CIO, 의사결정권자들은 다양한 관점에서 프로젝트에 대해 논의하고 있다. 이들이 지니고 있는 SOA에 대한 편견은 크게 다음 8가지로 정리해 볼 수 있으며 각각의 내용은 다음의 3개의 영역으로 나눠 생각해 볼 수 있다.
<일반적인 편견>
1. SOA는 명확한 구축 전략이 필요한 것은 아니다. 전략과 기획은 불필요한 비용이 발생한다.
2. 엔터프라이즈 서비스 버스(Enterprise Service Bus, ESB)를 최근에 구입했으므로 이미 SOA를 구축한 것과 같다.
3. 우리는 SOA 솔루션을 구매했고 이제 서비스 지향형 기업이다. 우리는 SOA에 대해 모든 것을 알고 있다.
<프로젝트 관련 편견>
4. SOA가 기존의 e-비즈니스 시스템과 다른 점이 무엇인가? 우리 회사의 정보 처리 시스템은 수십 년 동안 첨단 시스템을 도입해 현재 문제없이 운영되고 있다.
5. 굳이 SOA 시스템을 앞장서서 도입할 필요는 없다. 업계에 충분히 성숙된 이후에 상황을 봐서 검토하면 된다.
6. SOA는 말 그대로 서비스 지향형이기 때문에 프로젝트는 오히려 관리하기가 쉬울 것이다.
<기술에 대한 편견>
7. SOA는 웹 서비스를 기반으로 한다. 애플리케이션 프로그램 인터페이스(APIs)를 웹 서비스로 전환하면 SOA와 크게 다를 바가 없을 것이다.
8. SOA에 대해 이해를 하고 있다. 그러므로 일단 SOA 시스템을 도입하면 운영에는 문제가 없을 것이다.
기업 프로필
앞서 말한 기업의 예를 계속 살펴보도록 하자. 이 회사는 솔루션 공급에 특화된 서비스 제공 업체이다. 과거 수년간 성공적인 비즈니스를 영위해 왔으며 고객 수를 늘려가며 장기적으로 좋은 관계를 유지해 오고 있다. 이러한 계약의 대부분은 수년 전에 체결된 것이고 이 회사 매출에 매우 중요한 역할을 하고 있다.
그러나 예산 압박, 시간 부족, 인력의 부재로 인해 신기술이나 구축 전략과 관련해 직원을 교육하려는 시도가 매우 부족하게 됐다. 그러던 중 이 회사의 운영진은 SOA에 대해 듣게 됐으며, SOA 기반의 프로젝트를 통해 매출이 확대될 수 있음을 알게 된다. 그러나 이들은 직원들에게 SOA에 대한 교육 투자를 하지 않고도, 개발자들이 프로젝트를 통해 SOA에 대해 배울 수 있을 것이라고 낙관하기에 이른다.
파일럿 프로젝트의 어려움
어느 날 프로젝트 매니저들은 최고 경영진이 하는 회의에 참석한다. 이 회의에서 그들은 신규 매출을 창출할 만한 프로젝트를 고안하고 이를 함께 추진할 외부 파트너와 고객사를 찾는 업무를 맡게 된다.
최근에 이 회사의 주요 고객 가운데 하나가 SOA 시스템으로 전향하고자 하는 움직임이 일고 있다. “SOA가 유지 보수 비용을 줄여주고 변화에 대응하는 시간을 줄여준다는 말을 듣고 우리는 이 새로운 시스템에 투자하기로 결정했다”고 고객은 설명했다.
이 파일럿 프로젝트가 성공적이라고 밝혀지면 이 기업은 전략적 애플리케이션의 대규모 마이그레이션과 재구축에 있어서 주요 역할을 수행하고 전체 프로젝트에서 유리한 입장을 차지할 수 있을 것이다. 그러나 이 프로젝트는 반드시 정해진 기한 내에 완료돼야 하며, 예산측면에서도 여유가 있는 것은 아니다.
프로젝트 관리 부서에서 논의 끝에 A 프로젝트 매니저가 이 4주 동안의 프로젝트를 담당하기로 결정이 난다. A는 이 회사의 J2EE 프로젝트를 수행한 경험이 있는 사람이다. 이번 프로젝트는 시간이 촉박한 관계로 제대로 기획되고 짜임새 있게 구성되기 보다는 급하게 짜맞춰진 일회성 프로젝트로 진행되게 된다. 무엇보다도 프로젝트에 투입되는 인력은 기존의 자신들의 역량이나 지식을 그대로 유지한 채 자신들의 임무를 수행하게 된다.
내부 기획 및 인력 구성의 문제
A 매니저는 이번 도전을 받아 들이기로 했으나 프로젝트 인력 구성을 어떻게 해야 할지 고민이 생겼다. 가장 최근의 SOA와 유사한 프로젝트에서 일했던 직원은 조직 내에 유사한 부서로 옮겨 갔으며 외부 직원들은 모두 조직을 떠난 상태였다.
실제로 시스템에 투입되기까지는 약간 여유가 있었으므로 A 매니저는 팀을 구성하고 난 후, 이들을 가장 최신 기술을 배우기 위해 교육을 보내기로 결심하게 된다. 이것은 좋은 생각이었다. 그러나 매니저는 또다시 고민에 봉착하게 된다. ‘우리에게는 숙련된 인력이 부족하다. 그러나 경영진은 이러한 상황을 타개하기 위해 어떤 대책도 세우거나 실행하지 못하고 있다. 오늘 내가 프로젝트 매니저로 임명됐는데 이제 와서 내가 이런 이슈를 꺼내 들게 되면 분명 ‘우리에게는 이미 숙련된 인력이 있다. 새삼스럽게 교육이라니 무슨 말인가?’라고 질책 받을 것이 분명하다.
여기서 A 매니저가 실제로 고민하는 것은 ‘두려움’이다. 숙련된 인력이 부족한 데서 오는 불안감뿐만 아니라 그 자신도 SOA 관련 경험이 부족하다는 생각에서 자신감이 없는 것이다. 그는 매니저이지만 여태껏 자신이 잘 알고 이미 성숙 단계로 접어든 정보 시스템 구현만을 반복해 왔을 뿐 가장 첨단의 시스템을 창조적으로 구현해 본적이 없었다. 마침내 A매니저는 결심한다. “일단 시작해 보자. 결국 그래 봤자 프로젝트일 뿐이다. 일단 팀을 짜고 닥치는 문제들은 하면서 차차 해결해 나가도록 하자.”
그는 왜 제대로 된 프로젝트 전략을 짜는 과정을 생략하고 무작정 프로젝트를 추진하는가? 현재와 같이 급속도로 변하고 시간이 돈으로 계산되는 환경에서 기업은 장기적인 투자에 대해서는 이미 망각한지 오래다. 특히 이 회사와 같이 내부 인력의 지식과 경험과 같은 무형적인 자산에 대해서는 더더욱 그렇다.
이 회사의 경영진은 외부의 인력을 프로젝트 기간 동안 잠시 활용할 줄만 알았을 뿐 이들의 지식과 노하우를 자신들의 조직으로 전수하는 것에 대한 장기적인 계획이 없었다. 그야말로 무방비 상태인 셈이다. 이와 같은 상황에서 아래 두 가지 접근 방법이 채택될 수 있을 것이다.
● 시간이 촉박한 상황 - 프로젝트 완료까지 시간은 부족하고 절대 실패해서는 않되는 크리티컬한 프로젝트이다. 그렇다면 숙련된 인력을 외부에서 고용하고, 팀원들이 그로부터 기술을 배울 수 있도록 한다. 이것은 쉬운 방법은 아니다. 특히 개발자들이 각자 다른 입장을 취하고 있는 경우엔 더욱 그렇다. 그러나 이 방식은 성공적인 것으로 알려져 있다. 이런 경우 외부 인력들이 프로젝트를 주도하고 성공으로 이끌게 된다.
●시간이 여유가 있고 경영진이 장기 투자 의사가 있는 경우 - 이런 경우 2~3개의 작은 프로젝트를 우선적으로 수행하고 팀원 모두가 경험을 통해서 숙달되도록 한다. 외부인력을 투입하지 않거나, 필요하더라도 멘토링이나 약간의 가이드를 주는 수준에서 일하도록 한다.
설계와 구축
몇 가지 분석 과정을 거쳐 새로운 시스템의 아키텍처가 기술적인 안목에서 고려됐다. 또한 가능한 서비스들이 구분되고 마침내 대부분의 업무가 새롭게 구성된 인력들에게 분담됐다.
B 개발자가 새롭게 프로젝트에 투입되기로 결정됐다. B는 소프트웨어 시스템 설계에 풍부한 경험을 갖고 있다. 유일한 문제라면 새로운 기술을 활용한 소프트웨어 개발을 해본 적이 없다는 것이다. 그러나 다행히도 B는 신기술을 배우는 것에 몹시 흥미를 느끼고 있었다. 그는 자신이 유연하고 유지보수가 간편한 새롭고 혁신적인 시스템을 개발할 수 있을 것이라는 확신이 있었다. 몇 가지 문건을 숙지하고 분석 과정을 거쳐 그는 드디어 서비스를 설계하기 시작했다. 모두 웹 서비스였다.
B는 객체 지향적인 접근을 통해 서비스를 2가지 종류로 설계했다. 중심이 되는 ‘줄기 서비스’는 복잡하며 포괄적인 기능을 제공하며, 프로그래밍상의 문제점들에 공통적으로 적용할 수 있는 솔루션 또는 베스트 프랙티스가 되기도 한다. 이에 반해 ‘세부 서비스’는 몇 개의 작은 서비스로 구성되어 별도의 기능을 수행하도록 설계됐다
●줄기 서비스 - 여러 개의 일반적인 인터페이스 방법을 가진 서비스로 다양한 애플리케이션의 구축이 가능한 서비스이다. 결과적으로 이 서비스는 너무나 많은 비즈니스 또는 테크니컬 컴포넌트를 서로 결합시키고, 다수의 클라이언트 시스템과 연결돼, 개발 및 유지보수가 어렵고 유연성이 떨어지게 된다.
●세부 서비스 - 필요 컴포넌트만을 활용해 구축하도록 고안된 서비스로 복합적인 서비스를 제공하는 역량이 부족하게 된다. 따라서 클라이언트는 주요한 비즈니스 프로세스를 구현하기 위해서 여러 가지 서비스를 참조해야 하며, 이를 모두 워크플로우상에 연결함으로 복잡도가 높아진다.
B 개발자의 전체 설계는 웹 서비스를 근간으로 하고 자원의 재활용에 중점을 두고 있다. 그러나 몇 주간의 힘든 코딩 작업을 마친 후에 몇몇 다른 개발자들은 B 개발자의 설계에 대해 반론을 제기하게 된다. 한 개발자는 ‘시스템이 불안정해 보여서 언제 다운될지 모르겠다’고 걱정하고 어떤 개발자는 ‘이번 프로젝트에서 비슷한 코딩을 세 차례나 반복해야 했다’고 불평한다. 다른 개발자는 ‘정보가 부족한 상태에서 협업을 했기 때문에 모두들 인터페이스를 바꾸기 시작했다’고 지적했다. 이러한 평가를 통해 다음의 2가지 내용을 추론해 볼 수 있다.
●구축에 대한 명확한 전략이 필요하다. 즉, 기존 전통적 개발 방식의 프로젝트는 디자인이 정해지면 더 이상의 변경은 없었다. 이와 반대로 ‘민첩성’을 앞세운 SOA 프로젝트는 그 인터페이스들에 의해 정의되며 순환반복 과정(Iterative process)을 통해 변동을 겪게 된다. 인터페이스에 있어서 변화는 이와 연계된 일련의 변화를 불러오고 단순히 잘못 개발됐다는 점을 넘어서 개발자들에게 좌절감을 가져오게 된다.
●레거시 시스템 코드를 중심으로 서비스를 구축하는 개발자들은 실제로 작동하는 유연한 서비스를 개발하기 위해 레거시 시스템과 신 기술(SOA) 양쪽에 대해 깊은 이해와 충분한 지식이 필요하다. 4세대 언어(4GL)가 아무리 훌륭하다고 해도 모든 것에 대한 완벽한 솔루션이 될 수는 없다.
최첨단의 민첩한 시스템일수록 설계의 불확실성이 야기하는 문제는 심각하다. 또한 설계의 문제점은 시스템 도입 초기부터 발견되게 된다.
테스트 및 사용자 경험
3주간의 고된 개발 업무와 몇 차례의 인터페이스 변경 그리고 시스템 테스트를 마친 후 이들 프로젝트 팀은 통합 테스트의 첫 단계에서 충격을 받게 된다. 즉, 시스템의 성능이 도저히 받아들일 수 없는 수준인 것이다. 기술 부족으로 인해 레거시 시스템과의 연결이 너무도 복잡다단해졌으며, 그 결과 비효율성이 너무 높아진 것이다. 이들은 또한 프로토타입과 실제 시스템이 판이하게 다르다는 것을 깨달았다.
물론 몇 가지 목표는 달성했지만 사용자 인터페이스와 같은 부분은 당초의 예상을 훨씬 밑도는 실망스러운 수준이었다. 고객은 불만족한 것을 넘어서 프로젝트 2단계의 추진 여부조차 망설이게 됐다. 개발자들 역시 자신들의 성과에 절대 만족할 수 없었다.
“지난 몇 주 동안 우리는 이 시스템을 구축했지만 우리가 원했던 시스템과는 전혀 다른 결과를 얻었다. 개발과정은 굉장히 힘들었는데도 신규 시스템은 심지어 기존 시스템보다도 느리다. 유지보수조차 어떻게 해야 할지 감이 오질 않는다”고 토로하며 개발자들은 좌절하게 됐다.
교육을 제대로 받지 못한 교육자들과 경험이 부족한 아키텍트는 결과적으로 실용 불가능한 시스템을 설계했다. 기존의 단순한 시스템의 경우 설계가 불충분 하더라도 성능은 기대 이상인 경우가 있었다. 즉, SOA 처럼 분산된 아키텍처일수록 단일하고 강력한 시스템 설계가 핵심적인 역할을 하게 된다.
운영과 거버넌스
이 파일럿 프로젝트는 분산된 SOA로 전향하는 과정에서 어떻게 하면 성공하고 혹은 실패하는가를 잘 보여준다. 그러나 운영에 대해서는 고려되지 않았다. 운영 측면에서는 다음의 2가지를 신중하게 고찰해 봐야 한다.
● 확장성 - 많은 이용자와 클라이언트가 서비스를 이용할수록 시스템 확장성이 핵심 관건이 된다.
●변화관리 - 변화를 관리하는 것은 소프트웨어와 기업 자체에 영향을 미친다. 일반적으로 SOA 시스템으로 전향한다는 것은 기존의 개별독립 조직에서 보다 매트릭스형 조직으로 변화를 의미한다. 이는 개별화된 부서들에 걸쳐 자원과 서비스를 재사용함을 의미한다. 간단하게 들릴지 모르나 이는 현실적으로 매우 어려운 문제이다. SOA를 도입한다는 것은 새로운 커뮤니케이션 채널을 형성하고 기존의 특화되고 독립, 분산된 업무 및 부서간의 동의가 필요하기 때문이다.
SOA의 당면 과제 중 하나는 경제적이고 업무 니즈에 맞춰 충분히 확장 가능한 하드웨어를 제공하는 능력이다.(이를 위해 그리드(Grid)기술이 대두되고 있다.)
조직이 변화하면서 의사결정 과정, 즉 기업의 지배구조도 기존 시스템보다 더욱 복잡한 과제로 부각되고 있다. SOA를 위해서는 조직의 구조는 물론 종업원들의 마음가짐도 변화하는 것이 필요하다.
올바른 SOA 구현 위한 제안
SOA를 위해 제대로 투자를 하고 이를 통해 효과를 거두기 위해서 다음 사항을 고려해야 한다.
1. 조직의 교육에 대한 지속적인 투자
●구축 기술과 레거시 시스템에 대한 깊은 이해지식
●SOA의 기본 표준인 SOAP, 웹서비스 상호운영성(WS-I), 서비스 컴포넌트 아키텍처에 대한 인지
●SOA의 원칙, 설계 패턴에 대한 이해
●SOA의 실행 및 구현 환경에 대한 이해
2. 서비스 분석과 설계
●순환반복적(Iterative) 개발방법론에 대한 고려
●단순, 개방적인 업계 표준(예: WS-I)에 근거한 설계
●서비스 오케스트레이션을 위해 프레임워크를 개발하기보다는 표준화된 BPEL을 활용해 구축
●경우에 따라 웹 서비스가 아닌 다른 방법을(즉, WSIF등) 적절히 사용해 성능 및 트랙젝션 이슈를 해결할 필요가 있음.
●서비스 컨트랙트와 인터페이스를 안정적인 설계하고 모든 개발자들이 이를 숙지함
3. 민첩하고 유연한 구축
●기존의 단순한 애플리케이션 구현 방식이 고객의 요구사항이나 변경요구에 쉽게 적응하기 못한 점을 고려해 고객 업무 요건에 즉각 반응할 수 있는 ‘민첩한’ 개발 방법론을 고려
●이를 위해 개발과정에서 분석, 설계, 구축, 테스트 사이클의 단순화해 운용하면 효과적임. 특히 프로토타입을 개발하는 단기 프로젝트에 유효함
4. 커뮤니케이션
●구축 전략과 실효성에 대한 커뮤니케이션. 기술적인 것을 넘어서 생각하는 방식의 전환에 대한 공감대 형성
●단순한 정보시스템으로서의 SOA를 넘어서 조직의 체질과 문화를 바꾸어 새로운 단계로 접어들게 하는 개념 이해 |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
