SOA란 무엇인가

SOA란 무엇인가

도대체 SOA란 무엇인가? 

SOA는 서비스들이 중심인데, 여기서 서비스란 비즈니스 프로세스(예를 들면, 신용카드 거래를 인증하거나 구매 주문을 처리하는 일)를 수행하는 일련의 소프트웨어 컴포넌트들을 말한다. 가장 단순한 형태의 SOA는 네트웍 상에서 서로 통신을 하는 일련의 서비스들을 들 수 있다. 그 서비스들은 느슨하게 연결되어 있고(다시 말해 한 애플리케이션이 다른 애플리케이션과 대화하기 위해 그 애플리케이션의 기술적 세부사항을 알 필요는 없다는 의미), 잘 정의된 플랫폼 독립적 인터페이스들을 갖고 있으며, 재사용이 가능하다. SOA는 애플리케이션 개발 과정에서 더 높은 층을 의미하며[굵은 입도(coarse granularity)로도 불림], 비즈니스 프로세스에 초점을 맞추고 표준 인터페이스를 사용함으로써, IT 환경이 가진 근본적인 기술적 복잡성을 덮어준다. 이것은 고등학교 과학 교과서를 유치원 아이들에 맞게 번역하는 것과 같다. 다시 말해 심장의 승모판과 폐정맥을 다루지 않고도 심장이 피를 보내는 일에 대해 아이들에게 설명할 수 있는 것과 같다.



SOA는 코바에 새 옷을 입힌 것이 아닌가?

아니다. SOA는 기존의 밀접하게 결합된 애플리케이션 연결[코바(Corba: common object request broker architecture)]에서 느슨하게 결합된 애플리케이션 연결[웹서비스(Web services) 같은 것]로 진화한 것이다. 밀결합될 경우, 애플리케이션들은 변화하는 비즈니스 요구에 적응하기가 힘들어지는데, 하나의 애플리케이션을 손보면 이 애플리케이션에 결합된 다른 애플리케이션들도 모두 손봐야만 하기 때문이다. 또한 코바 같은 객체 중심(object-oriented) 개발방식은 가는 입도(finer level of granularity)를 사용하기 때문에, 객체들은 직원이나 고객 주문 수준에서 정의될 필요가 있다. 반면 SOA의 경우, 서비스는 더 추상적인 수준(예를 들면, 전화고지서를 찍어내는 등의 비즈니스 프로세스 수준)에서 정의된다.



SOA 용어정리 

엔터프라이즈 서비스 버스(Enterprise service bus): 소프트웨어 인프라로, 표준 인터페이스와 메시징을 사용해 애플리케이션들을 통합한다. SOA를 구현하는 한 가지 방법(주: 가트너의 보고서에 나온 이 용어는 비교적 새로운 것이다.)

느슨한 연결(Loosely coupled): 잘 정의된 인터페이스들을 사용해 서비스들을 연결하는 것. SOA는 느슨하게 연결된 접근법을 사용해 구축되는데, 이 방법을 사용하면 1개 서비스를 손보더라도 이 서비스에 연결된 다른 서비스들을 손볼 필요가 없어진다. 

메시지 중심 미들웨어(MOM: Message -oriented middleware): 때때로 메시지 중심 아키텍처(message-oriented architecture)로도 불리는 MOM은 여러 애플리케이션들, 심지어 이기종 플랫폼들의 애플리케이션들을 연결하기 위한 메커니즘을 제공한다. 데이터는 메시지 대기열(queues)에 위치하게 되며, 따라서 애플리케이션들은 데이터를 보내는 애플리케이션들에 대한 직접적인 연결선을 만들지 않고도 데이터를 검색할 수 있다.

출판-가입(Publish-subscribe): 한 서비스가 요청하면(또는 ‘가입하면’) 다른 서비스가 올리는(또는 ‘출판하는’) 시스템. 출판된 정보가 변경되면, 가입한 서비스들은 자동으로 업데이트된 데이터를 수신한다.

서비스 중심 아키텍처(SOA: Service-oriented architecture): 잘 정의된 인터페이스들을 가진, 재사용이 가능한 일련의 컴포넌트들로 구축되는 기술건축방식.



SOA 도입에 따른 이익은? 

SOA는 대부분의 기업에서 발견되는 ‘모든 것을 갖고 있는’ IT 환경을 통합하는 일을 더 쉽게 해 준다. “이것이 SOA가 제시하는 가장 큰 가치 가운데 하나다. 다시 말해 SOA는 이기종 환경에서 아주 잘 작동한다.”고 웹서비스 컨설팅 회사인 잽씽크 사의 선임분석가 제이슨 브룸버그는 말한다. SOA를 통하면, 개발자들은 애플리케이션들을 연결하는 새로운 코드를 작성하기 위해 과도한 시간을 낭비할 필요가 없어진다. 대신 개발자들은 웹서비스 같은 표준 프로토콜을 사용할 수 있다. 그리고 SOA 코드의 상당 부분은 재사용이 가능하기 때문에 개발 비용도 줄어든다. SOA는 CIO가 기존에 리거시에 투자했던 것(SAP, 시벨, 오라클 등)을 한데 묶어 더 잘(그리고 저렴하게) 활용할 수 있게 해 준다.

“SOA가 좋은 점은 기존의 포트폴리오를 활용할 수 있게 해 준다는 것이다.”라고 IT 컨설팅 회사인 실크로드 사의 사장 팀 바스는 말한다. CIO는 기존 시스템을 제거하고 새로운 시스템으로 대체할 필요가 없어진다. 기존 시스템의 기능들을 파악한 후 그것들을 활용함으로서, CIO는 위험을 최소화하면서 기존 IT 투자의 가치를 극대화할 수 있다고 바스는 말한다. 또 서비스[예를 들면, 단순객체접근프로토콜(SOAP: simple object access protocol)과 웹서비스기술언어(WSDL: Web services description language) 등을 사용하는 서비스]를 구축하면, 내부 프로세스가 부드러워질 뿐만 아니라, 고객과 비즈니스 파트너들과는 회사의 방화벽을 넘어서 더 쉽게 정보를 공유할 수 있게 된다.

SOA의 또 다른 이익은, SOA가 IT 스탭들로 하여금 기술 아키텍처가 아니라 비즈니스 아키텍처 측면에서 생각하도록 강요하기 때문에, CIO와 비즈니스 중역들 사이의 대화를 더 매끄럽게 해 줄 수 있다는 것이다. 예를 들어, 만약 비즈니스 측이 개선된 재고관리 시스템을 구축하고자 한다면, 비즈니스 측의 실무진은 비즈니스 흐름에 기반해 그것을 설계하는 최고의 방법과 비즈니스의 요구를 만족시키는 최선의 방안에 대해 IT 설계사들과 이야기할 수 있다. 그리고 그 디자인을 실제로 구현하는 일도(이 일은 종종 대규모의 통합 작업이 수반되는데) 훨씬 쉬워진다.

이런 대화가 유용성을 가지려면, 비즈니스 측도 그들의 비즈니스를 운영하는 최선의 방법에 대해 생각해야만 한다. 예를 들면, 고객을 최대로 수용하기 위해 구축할 필요가 있는 프로세스들은? 고객 서비스 수준을 높일 수 있는 방법은? 등이다. 기존의 사일로화된 애플리케이션들을 넘어서 정보를 전달하고 공유함으로써, 기업은 실시간으로 더 많은 비즈니스 성과 데이터를 추출할 수 있어 비즈니스 지능을 높일 수 있다. 또 공통의 아키텍처를 통할 경우, 기업의 반응 수준은 획기적으로 높아진다고 양키 그룹의 선임분석가 다나 가드너는 말한다. “미동부해안에서 허리케인이 발생할 경우, 그 결과로 미국의 다른 지역에서 합판을 옮겨야 할 필요성이 크게 높아질 것이다. 이에 대해 기업은 실시간으로 반응할 수 있다.”고 그는 말한다. “기업은 비즈니스에서 일어나고 있는 일에 대한 정보(이전에는 갖지 못했던 정보)를 갖게 된다.” SOA가 완벽하게 구축된다면, 변화하는 비즈니스 요구와 매순간 바뀌는 시장 조건들에 대한 기업의 적응력은 크게 높아질 것이다.

마지막으로 통합이 쉬워지고 민첩성이 높아짐으로써 ROI가 높아진다는 부수적 이익도 맛볼 수 있다. 부스카드는 SOA 투자에 대해 200%의 ROI를 달성했다고 말한다. AXA 파이낸셜의 가장 인기있는 SOA 기반 서비스 가운데 하나는 겟클라이언트(Get Client)로, 이를 통해 고객대면의 전방처리 애플리케이션은 모두 명령어를 발행할 수 있는데, 그러면 그 명령어는 리거시 시스템들을 모두 훑어본 후 특정 고객의 투자에 대한 완벽한 그림을 창출해 낸다. 겟클라이언트 사례는 AXA가 ROI를 달성하는 방법 가운데 하나라고 부스카드는 말한다. 다시 말해 개발자들은 모든 종류의 전방처리 시스템들과 작동하기에 충분할 만큼의 일반적인 형태의 서비스를 디자인할 수 있으며, 이로 인해 개발시간이 단축되고 개발자들은 비즈니스 솔루션에 더 많은 시간을 쏟을 수 있게 된다. 여기에 IT 스탭들은 새 기술을 SOA에 쉽게 결합할 수 있어, 위험과 비용을 줄이면서 새 애플리케이션의 개발 속도를 높일 수 있다.



웹서비스가 SOA에서 하는 역할은?

우선 SOA는 웹서비스를 반드시 필요로 하는 것이 아니라는 점, 그리고 웹서비스도 SOA 없이 배포될 수 있다는 점을 주목할 필요가 있다. 그러나 웹서비스를 이용해 SOA를 구축하는 것이 가장 이상적인 방법이라고 생각하는 사람도 있다. 가트너의 톰슨이 이런 사람 가운데 하나다. 그러나 그는 SOA를 구축하려면 먼저 웹서비스를 제대로 구현해야만 한다고 경고한다. 만약 정확하게 구현되어 있다면, 그 웹서비스는 SOAP와 WSDL을 사용하는 SOA와 다름이 없다.

이에 반해 부스카드는 웹서비스 없이 SOA를 구축했는데, 이 시점에서 회사 내외부 고객 가운데 어느 누구도 그것을 요청하고 있지 않기 때문이다.(하지만 그는 나중에 그런 요청이 들어올 경우를 대비해 항상 촉각을 곤두세우고 있다.) 대신 그는 아이비엠의 웹스피어 MQ를 메시징 및 통합층으로 사용해 리거시 시스템들을 전방처리 애플리케이션들과 결합하고 있다. 동시에 그는 캔들 사의 패스와이(PathWAI) 수트를 함께 사용하고 있는데, 이 제품은 웹스피어 MQ의 성능을 모니터함으로써 웹스피어 MQ의 최적화를 도와준다.

노스롭 그룸만 미션 시스템의 수석엔지니어 존 존슨도 웹서비스 없이 출판-가입 시스템에 기반한 SOA를 구축했다.<’SOA 용어정리’ 박스 참조> 그는 웹 서버와 애플리케이션 서버의 최상부에 메시징 계층으로서 자바 메시지 서비스를 설치했으며, 통합 작업과 데이터 이동 작업을 돕기 위해 소닉 소프트웨어 사의 엔터프라이즈 서비스 버스를 사용하고 있다. 존슨은 그 서비스들이 웹서비스처럼 설계되어 있지만, 웹서비스 인터페이스들을 사용하고 있지는 않다고 말한다. 

SOA의 큰 이점 가운데 하나는 정확한 데이터를 필요한 사람이나 애플리케이션에 전달해 준다는 것이라고 존슨은 말한다. 예를 들면, 한 사용자가 ID를 사용해 로그인을 할 때, 시스템은 그 사용자가 누구인지를 확인한 후 그 사람이 볼 수 있도록 허용된 데이터(예를 들면, 지도와 업무 리스트)를 전달해 준다.



도전과제는 무엇인가?

보안이 가장 큰 과제다. “개방형 환경보다는 폐쇄형 환경을 보호하는 일이 항상 더 쉽다.”고 실크로드의 바스는 말한다. CIO는 웹서비스의 보안 표준들이 아직 확정되지 않았다는 점을 먼저 인지해야만 한다.<’계산된 위험(www.cio.com/archive/100103/risks.html)’ 박스 참조> 이런 보안 문제 가운데 몇 가지를 극복하려면, SOA를 구축할 때 높은 수준의 보안을 요구하지 않는 비즈니스 프로세스들에 우선 초점을 맞추는 식으로 천천히 진행하는 것이 좋다고 바스는 조언한다.

서비스 구성과 관련된 복잡한 일들을 관리하는 것 또한 까다로운 일이 될 수 있으며, 따라서 탄탄한 SOA 지배구조 모델이 필요하다고 바스는 말한다. 예를 들면, 서비스 중심적인 노드들을 네트웍에 갖고 있으며 100명의 사용자가 특정 인터페이스들을 사용하고 있을 경우, 만약 누군가 그 인터페이스를 변경한다는 결정을 내린다면 어떻게 다른 사용자들과 통신을 할 것인가? 

또 다른 이슈는 네트웍 모니터링이다. “SOA를 통해 복잡한 인터넷 중심의 비즈니스 프로세스들을 조율하는 능력을 갖춘다는 말은 동시에 복잡한 모니터링과 감사 역량도 갖춰야 한다는 말이다.”라고 바스는 말한다. 예를 들면, 서비스 중심 네트웍에서 거래처리 작업 하나가 잘못될 경우(이 경우 여러 서비스 제공업체가 관련될 가능성이 높은데), 무엇이 잘못된 것인지, 어디에서 그것이 잘못된 것인지, 또는 누군가 네트웍에 잘못된 정보를 입력한 것인지를 파악하는 일이 아주 어려울 수 있다. “현재의 웹서비스 기술 표준들은 겉으로 드러나는 사항들만 다루고 있을 뿐이어서, 이 서비스 중심의 이상적인 분산 협업, 프로세스 조율, 모니터링 목표를 현실로 만들기에는 아직 부족한 면이 많다.”고 바스는 말한다.

마지막으로 비용 문제가 있다. SOA를 구축하는 것은 결코 값싼 일이 아니다. 기존 시스템 아키텍처를 리엔지니어링하기 위해서는 상당한 돈이 들어갈 것이다. 또 상당한 수준의 인적자산이 필요할 것이다. 예를 들면, 비즈니스 프로세스를 설계하기 위한 비즈니스 분석가, 프로세스들을 설계도로 만들기 위한 시스템 아키텍트, 새로운 코드를 개발하기 위한 소프트웨어 기술자, 그 모든 사람을 조율하기 위한 프로젝트 매니저 등이다.



SOA를 구축하는데 있어 일반적으로 수용되는 베스트 프랙티스가 있는가?

말할 필요도 없는 것처럼 들릴지 모르지만, SOA를 위한 청사진을 확보하는 것은 정말 중요한 일이다. 기업, 특히 여러 비즈니스를 펼치고 있는 대기업에서 전반적인 계획 아래 어떻게 그것이 들어맞을 것인가를 고려하지 않고 신기술을 구매하거나 애플리케이션들을 통합하는 일은 다반사로 일어난다. 따라서 SOA를 구축하는 것과 관련해 가장 큰 과제 가운데 하나는 사람들(IT와 비즈니스 양측 모두)로 하여금 그 아키텍처 목표들에 초점을 맞추도록 만드는 것이다. 

그리고 CIO는 제공해야 할 정확한 수준의 서비스를 파악할 필요가 있다. 그리고 그런 서비스는 너무 가는 입자도를 가져서는 안된다. 그렇게 되면, 더 높은 비즈니스 프로세스 수준에서 기능을 발휘한다는 그 서비스의 목표가 훼손되기 때문이다. 다시 말해 초점을 너무 좁게 잡으면 더 많은 서비스가 필요하게 되고, 이것은 다시 개발 시간을 증가시킨다. 최악의 경우, 너무 많은 서비스가 네트웍에 흐를 수 있게 된다.

또한 CIO는 가장 큰 유용성을 보이는 곳에서 SOA를 사용해야 할 것이다. 바스는 SOA를 구현할 때 서비스 품질(QoS: quality of service)도 고려할 필요가 있다고 지적한다. 거의 실시간에 가까운 반응속도를 요구하지 않는 시스템에서는 느슨하게 연결된 아키텍처가 좋다고 바스는 말한다. 제시간에 필요한 정보를 얻지 못할 경우, 그 결과가 재앙이 아니라 사소한 문제로 그치는 그런 시스템을 골라 SOA를 적용한다.(예를 들면, SOA를 토대로 항공교통 제어 시스템을 구축한다는 것은 나쁜 생각이다.)



아키텍처에 대한 더 많은 정보

신기술에 대해, 그리고 SOA의 사촌인 웹서비스와 기타 협업 도구에 대해 더 많이 알고 싶다면, 태동기술 연구센터(Emerging Technology Research Center, 64.28.79.79/research/current/)를 참조

관련 정보

혼성 애플리케이션: 새로운 비즈니스 모델을 위한 자산 활용법(Composite Applications: Leveraging Assets for New Business Models, www2.cio.com/analyst/report1726.html)

휴위츠 앤 어쏘시에이츠 사가 이질적인 이익집단들 사이에서 새로운 비즈니스 프로세스를 창출하기 위해 혼성 애플리케이션을 사용하는 방법에 대해 보고하고 있다.

웹서비스: 보편적인 통합이 비즈니스 서비스에 파워를 더해 준다(Web Services: Universal Integration Powers Business Services, www2.cio.com/consultant/report1641.html)

액센추어가 엔터프라이즈 애플리케이션 통합(EAI) 기술에 대해 보고하고 있다.

SOA로의 오솔길(The pathway to a service-oriented architecture, www.computerworld.com/developmenttopics/
development/webservices/story/
0,10801,87771,00.html)



CIO들은 SOA에 대해 생각하고 있는가?

많은 CIO가 SOA에 대해 심각하게 고려중이다. 특히 웹서비스를 시험중인 CIO들이 그렇다. SOA의 잠재적 효과가 아주 매혹적이기 때문이다. 민첩성 증대, 통합 속도 증대/비용 절감, 기존 IT 자산의 활용, 비즈니스 프로세스에 대한 집중 등 그 이익은 아주 많다. 

물론 SOA를 구축하려면 상당한 투자를 해야 한다. 또 아직 성숙하지 않은 웹서비스 시장과 관련해 많은 문제가 해결되지 않고 있는 상태다. 하지만 최소한 SOA는 전략적 측면에서 계속 주목할 만한 가치가 있다