developerWorks에 처음 로그인하면 developerWorks프로파일이 생성됩니다.귀하의 프로파일에서 동의하신 내용이 공개되지만 이 사항은 언제든지 변경 가능합니다. 귀하의 성명(숨김으로 체크되어 있어도 표시됩니다)과 디스플레이 이름은 게시한 컨텐츠나 사이트 엑세스시 표시됩니다.

모든 정보가 안전하게 전송되었습니다.

처음 developerWorks에 로그인할 때 프로파일이 작성되므로, 이를 위해 디스플레이 이름을 선택해야 합니다. 선택하신 디스플레이 이름은 developerWorks에 게시한 컨텐츠에 표시됩니다.

3글자 이상 31글자 이하의 길이로 사용 가능합니다. dW커뮤니티 내에서는 보안상 이메일주소를 제외한 다른 이름을 지정하셔야 합니다.

모든 정보가 안전하게 전송되었습니다.

My developerWorks：

나의 통지：

로그아웃

언어 선택：

설명 행: 핵심 뱅킹 변환의 최악 사례 및 기타 끔찍한 스토리

어떤 대형 IT 프로젝트도 안전하지 않을 때

Fred Simmons, 프로그래머, IBM

요약： 많은 아키텍트들이 증언하는 바와 같이, 대상 솔루션 아키텍처를 추구하는 과정에서 숱하게 많은 끔찍한 경험을 했습니다. 때때로 이런 상황은 경험 부족으로 인해 발생하지만, 주어진 상황에 대해 확고한 아키텍처적 관점을 가지고 있지 않은 결과로서 발생하기도 합니다. 이 기사에서는 이와 유사한 문제를 미연에 방지하고자 하는 바람에서 다양한 실제 상황과 그에 관련된 해결책을 살펴봅니다.

-->

여기에 태그 달기!

원문 게재일: 2010 년 8 월 25 일
번역 게재일: 2010 년 11 월 30 일
난이도: 초급
원문: 보기
PDF: A4 and Letter (23KB | 7 pages)Get Adobe® Reader®
페이지뷰： 2724 회
의견：

우울하고 소모적 논쟁만 가득했던 디자인 미팅

필자는 어렸을 때 해양 괴물이나 우주 생명체 블롭과 같은 공포 영화광이었다. 필자가 실제로 멀리서라도 이처럼 무서운 일을 겪을 것이라고는 상상조차 하지 않았지만, 지금도 이런 공포스러운 이야기에 끌리는 느낌이다.

IBM® Worldwide Banking Center of Excellence에서 필자가 맡고 있는 솔루션 아키텍트로서의 역할을 수행하면서, 실제로 필자는 아키텍트의 뼛속까지 오싹하게 할 수 있을 정도로 끔찍한 고객의 상황을 증언한 적이 있다. 은행에서 핵심 뱅킹 현대화 전략을 개발하는 데 도움을 주는 과정에서 필자가 맞닥뜨렸던 더 놀랍고 믿기 힘든 일들을 몇 가지 소개하고자 한다. 여기서 유령이나 마귀 또는 다른 정체불명의 괴물에 대한 얘기를 하려는 게 아니라, 그런 일(즉, 최악의 사례)이 실제로 있기 때문에 훨씬 더 무섭게 느껴지는 일을 이야기하려는 것이다.

지금부터 독자 여러분과 공유하려는 실화는 일부 조직의 그림자 속으로 나쁜 것들이 몰래 숨어 들어가는 증거다. 이 기사에서 필자의 목적은 그런 나쁜 것들이 숨어 있는 어둠의 공간에서 이들을 끌어내어 낱낱이 밝힘으로써, 이와 유사한 부정적 요소들로 인해 대혼란이 일어날 수도 있을지 여부를 식별하는 데 도움을 주기 위한 것이다.

위로

부정적 요소의 실체 규명

발생한 일: "제대로 충족시키지 못하고 있는 요구사항은 나중에 문서화할 수 있으니, 지금 당장은 제 기능을 발휘하는 디자인에 집중하자."

인터넷 뱅킹 솔루션 디자인에 대한 미팅 도중, A 은행의 한 아키텍트가 외부 고객을 위한 액세스를 인증하려면 일반 사용자 로그인에 25개를 넘는 별개의 홉이 필요하다는 문제를 제기했다. 이 아키텍트는 가용성뿐 아니라 성능에 대해서도 우려했다. 이 은행의 IT 보안팀 핵심 멤버 한 사람이 보안 아키텍처가 수정되어 프로젝트 아키텍트는 그냥 "보안 문제는 전문가에게 맡기고", "지금은 편리하고 실용적인 디자인에만 집중"해야 한다고 답했다.

이 상황이 끔찍한 이유는 이렇다.

중요한 딜레마는 기능상의 측면과 (보안을 포함하여) 그렇지 않은 측면 모두에 대한 아키텍처와 관련된 의사결정을 프로젝트 단위로, 프로젝트 초기에 분석해야 한다는 점이다. 솔루션 디자인의 일부로서, 아키텍트는 솔루션의 모든 비기능적 요소에 초점을 맞출 필요가 있다. 보안 인프라를 고정된 것으로 볼 수도 있겠지만, 다른 접근 방식을 평가하고 판단하기 위한 요구사항이 완전한 솔루션 디자인의 필수적 요소다. 이런 특수한 상황이 발생하는 경우, 팀에서는 계속 다른 접근 방식을 평가하여 보안 성능 문제를 해결했고 결국에는 솔루션의 일부로서 보안 어플라이언스를 구현했다.
발생한 일: "귀사의 주요 ISV로서, 당사는 귀사의 모든 요구사항을 지원할 생각입니다... 우리는 유연한 솔루션을 보유하고 있어 새로운 기능들을 손쉽게 구현할 수 있습니다."

B 은행을 위한 전략적 핵심 뱅킹 프로젝트 진행 중, 솔루션파트너(ISV)가 이런 다소 놀라운 말을 했다. 특정 고객과의 실제 프로젝트 구현의 일환으로서 패키지가 향상되고 확장되고 있다는 점이 분명해졌다.

이 상황이 끔찍한 이유는 이렇다.

한편으로는 패키지로 제공되는 애플리케이션을 고객의 요구에 맞춰 조정할 수 있는 능력이 핵심적 특징이지만, 이 향상된 기능은 단순한 조정 기능보다는 훨씬 발전된 기능이다. 우리는 성급한 RFP(제안 요청서) 평가로 인해 이런 상황을 종종 보며, 고객에게 요구사항이 분명하고 평가를 통해 철저히 유효성을 검증했는지 확인할 것을 촉구한다. 적절한 도구를 사용하여 요구사항 정의를 지원할 뿐 아니라, 이런 도구를 사용하여 요구사항 유효성 검증을 지원하는 것이 좋다. 평가 중, 조직에서는 공급업체의 답변이 미래에 기능에 대한 암시적 약속이 아니라 제품 기능을 완벽하고 분명히 설명하는지 확인해야 한다.

추가적인 우려 사항으로, 핵심 뱅킹 애플리케이션(특히 고객이 직접 완성한 애플리케이션)에서의 기준선을 변경할 경우 새 릴리스로 업그레이드할 수 없어 종종 버전 변경 불능 상황으로 이어진다. 결과적으로, 고객은 반드시 솔루션 디자인의 일부로서 업그레이드 문제를 평가해야 한다.

이 고객은 값비싼 대가를 치르고 소중한 교훈을 얻었다. 프로젝트를 시작한 지 18개월 후, IT 경영팀은 프로젝트를 취소했고 B 은행은 현재 이 프로세스에서 IBM을 신뢰할 수 있는 조언자로 삼아 다른 접근 방식을 모색 중이다.
발생한 일: "다음 릴리스에 기능상의 요구사항의 두 가지 더 추가할 필요가 있지만, 사소한 변경일 뿐이다."

C 은행의 한 주요 관계자가 프로젝트 디자인 담당자와의 디자인 세션에서 이 사항을 제기했다. C 은행은 타사 뱅킹 패키지와의 통합을 제공하기 위해 사내 CICS® 기반 핵심 뱅킹 솔루션을 서비스로 지원하는 과정에 있었다.

이 상황이 끔찍한 이유는 이렇다.

핵심 뱅킹 현대화 프로젝트와 일반적으로 대규모의 복잡한 IT 프로젝트를 성공적으로 수행하려면 정확한 계획과 올바르고 엄격한 프로젝트 관리가 필요하다. 핵심 뱅킹 프로젝트에 막대한 수의 종속 항목이 있는 경우 기준선 변경 제어가 필수적이다. 예외를 만들 필요가 있더라도, 정식 거버넌스 및 프로젝트 관리 프로세스의 일부로 예외를 관리해야 한다. 변경 요청을 관리하고 조정하기 어려울 수 있으므로, 고객은 기준선 프로젝트 제어를 위해 적절한 프로젝트 관리 도구와 방법을 사용해야 한다. 이 특정 사례에서, 관계자들은 약간이긴 하지만 변경 작업이 곧 시간, 비용 및 위험으로 이어진다는 점을 인식하지 못했고, 이런 행동이 계속 줄지 않았다.

C 은행은 결국 프로젝트 진행이 계속 지체되는 바람에 프로젝트 자체를 포기했다. 효과적으로 일하는 프로젝트 디자인과 거버넌스 담당 조직이라면 이런 불행한 결과를 초래하지 않았을 것이다. IBM은 이 은행과 함께 협력하면서 이런 일이 앞으로는 일어나지 않도록 하기 위해 더욱 엄격하고 정확한 프로젝트 관리 기능을 확립하고 있다.
발생한 일: "SOA 솔루션 접근 방법에서 CICS 트랜잭션을 서비스에 직접 맵핑할 수 있는가?"

D 은행과 CICS 웹 서비스를 배치하는 계약을 맺는 중, 이 질문이 바로 이 은행이 어떤 서비스 디자인 방법론도 따르고 있지 않고 있었다는 증거가 되었다.

이 상황이 끔찍한 이유는 이렇다.

시간이 경과하면서, 이 은행은 간단한 데이터 검색에서 복잡한 트랜잭션 기능까지 다양하게 3,000여 개의 CICS 트랜잭션을 빌드했다. 계약을 맺기 전, 이 고객은 비즈니스 또는 기술 요구사항을 평가하지 않고 공통적으로 사용되는 CICS 트랜잭션을 위한 CICS 웹 서비스를 구현하기로 결정했다. 본질적으로, 이 고객은 자산 분석에서 후보 서비스 구현으로 바로 옮겨가고 있는 중이었다. IBM은 프로젝트에서 서비스 디자인을 지원하기 위해 SOMA(Service Oriented Modeling and Architecture)를 채택하고, 이를 조직의 기준 방법론으로 삼으라고 권장했다. 특히, 우리는 고객이 서비스 식별 단계에 집중하여 후보 서비스를 확실히 식별하고, SOMA 서비스 리트머스 테스트 방법론을 이용해 올바른 서비스가 실현되고 있는지 확인하도록 하였다.

이 고객 사례의 결과는 긍정적이었다. 우리는 서비스 디자인에 대한 고객의 접근 방식을 향상시켰다. 일반적으로, 출시 시간 목표를 달성하기 위해 훌륭한 서비스 디자인을 희생시키면 안 된다.
발생한 일: "그냥 기존 메시징 기술을 사용하여 컨텐츠 관리 요구사항을 충족시킬 수는 없는가?"

계정 관리 솔루션 디자인 중, E 은행에서 문서 관리 요구사항을 정의하면서 이 질문이 나왔다. 사용자 인터페이스 개발에 IBM WebSphere® MQ와 관련 기술을 사용하는 상황에서, 개발자들은 처음에는 사용자 정의 경량 컨텐츠 관리 솔루션 작성을 제안했다.

이 상황이 끔찍한 이유는 이렇다.

팀에서 이 솔루션을 위해 실현 가능한 SOA 기반 디자인을 개발했지만, 이 접근 방식이 이런 유형의 요구사항을 해결하기 위해 올바른 방법은 아니었다. 사내 개발을 평가하기 위한 주요 기준은 TCA(총 획득 비용)이지만, E 은행에서는 TCA 문제를 서둘러 해결하느라 컨텐츠 관리 요구사항의 범위나 코드 유지 관리를 위한 장기적 요구사항을 평가하지 않았다.

우리는 수많은 조직들이 단순히 비용을 줄이기 위해 인프라 요구사항의 해결을 위한 사용자 정의 솔루션을 개발하는 모습을 계속 목격하고 있다. 디자인 팀에 대한 자문 역할을 하는 과정에서, 우리는 고객들에게 컨텐츠 관리 기능을 빌드하지 말라는 점을 납득시켰다. 그래서 E 은행은 사용자 정의 솔루션을 개발하는 대신 이런 요구사항을 뒷받침하기 위한 벤더 기반 컨텐츠 관리 솔루션을 구현했다. 선택한 솔루션이 프로젝트에 대한 실제 요구사항보다 중요한 기능을 제공했지만, 해당 벤더 솔루션은 유지 관리 및 개발 관점에서 모두 장기적인 비용 절감 효과를 제공했다.
발생한 일: "서비스 스펙이 WSDL이다. 개발자로서, 이것이 내가 서비스를 개발하는 데 필요한 유일한 문서이다."

F 은행의 주요 개발자 중 한 명이 대출 처리 솔루션에 대한 디자인 검토 토론 중 이런 말을 했다.

이 상황이 끔찍한 이유는 이렇다.

서비스 디자인에 대한 한 가지 중요한 측면은 문서 라이프사이클의 일부로 서비스를 잘 문서화하고 디자인에서 서비스 상호 작용 관련 문제, 서비스 레벨 계약(SLA), 서비스 소유권, 서비스 정책, 서비스 컴포지션 관련 문제 및 기타 관련 메타데이터를 포함한 다양한 기능 및 비기능적 요구사항을 정의해야 한다는 점이다. 요컨대, 서비스 스펙은 단순한 WSDL 이상의 것이다. 뿐만 아니라, 서비스 디자인은 전반적인 거버넌스 권한의 일부로 관리할 필요가 있고, 개발 조직은 이 프로세스에 적극적으로 관여해야 한다.

이 사례에서 제기된 과제는 디자인 프로세스 또는 그런 프로세스의 결여로 인한 문제와 서비스 디자인 및 자산 재사용을 지원하기 위한 도구화 요구사항이었다. 이 사례에서는 결국 더 완전한 서비스 정의를 지원하기 위해 더 폭넓은 서비스 디자인 접근 방식을 채택하고 서비스 레지스트리 및 메타데이터 관리 도구화를 도입했고, 이에 따라 서비스 디자인 최적화와 자산/서비스 재사용 증가로 이어졌다.
발생한 일: "시스템 테스트에 너무 많은 자원이 필요하고 매우 애로 사항이 많다. 시스템 테스트를 올바로 하기에는 하드웨어가 부족하다."

G 은행의 한 IT 임원이 SOA 기반 핵심 뱅킹 프로젝트를 검토하는 과정에서 이런 매우 솔직한 논평을 했다.

이 상황이 끔찍한 이유는 이렇다. 이 은행에 중대한 문제가 있다는 점이 분명했다. 이 은행은 서로 다른 데이터베이스를 가진 30개 이상의 패키지화된 사내 애플리케이션으로 지원해야 할 7가지 환경(유닛 테스트, 통합 테스트, 시스템 테스트, 사용자 인수 테스트, 스트레스/성능 테스트 등)이 있었다. 효율성을 높이기 위해 테스트 예약 및 요구에서 자동 프로비저닝 및 솔루션과 제안하는 향상된 기능의 도입을 권장했다. 이런 변경으로 즉각적인 문제는 해결되지만, 장기적인 문제는 해결되지 않는다. 결과적으로, 이 고객은 현재 개발/테스트 사설 클라우드의 구현을 평가 중이다.

핵심 뱅킹 변환 프로젝트는 매우 복잡하므로, 가상화 및 수동 프로비저닝을 구현하더라도 위험 및 자원 관리 문제가 완전히 해결되지는 않는다고 생각한다. 앞으로는, 전 세계적으로 수많은 은행들이 기존의 핵심 솔루션을 구현 또는 현대화할 길을 모색함에 따라 테스트/개발 클라우드의 구현이 대체로 선호하는 아키텍처가 될 것이라고 예상한다.

우리가 전 세계 곳곳에서 지켜보고 있는 각종 핵심 뱅킹 프로젝트나 대규모의 IT 프로젝트에서 배울 수 있는 교훈이 많이 있다는 점은 분명하다. 대부분의 대형 은행에서는 대규모의 SOA 프로젝트를 구현했고, 그 결과 이미 이런 문제들을 대부분 겪었고 대부분의 경우 문제를 해결했다. 수많은 중견 은행들이 현재 이런 과제들의 해결에 고심하고 있으므로, 이 기사가 각자 진행하는 솔루션 디자인 작업이 위에서 예로 제시한 문제에 봉착하지 않도록 하기 위해 고려해야 할 몇 가지 중요한 문제를 직시하는 데 도움이 되었기를 바란다.

필자의 입장에서는, 이 기사에서 설명한 것과 같은 끔찍한 상황이 때때로 발생하는 것이 오히려 즐겁다고 말할 수 있겠다. 왜냐하면, 이런 상황을 해결해나가면서 분명히 흥미와 희열을 느끼기 때문이다.

참고자료