1.
Arrowhead는 동경증권거래소가 2007년에 추진한 차세대프로젝트입니다. 이 때 자료를 읽으면서 가장 놀라웠던 기억은 1500쪽이 넘는 RFP였습니다. 상세설계수준으로 RFP를 내놓았습니다. Arrowhead보다 몇 년후에 이루어진 Exture+의 제안요청서를 보았지만 RFP 자체로서 관심이 땡기지 않았습니다. 여의도에서 자주 보았던 제안요청서일 뿐입니다. 그러면 증권사의 차세대는 어떨까요? 최근 신문에서 아래 기사를 보았습니다.
이번 차세대시스템 사업을 통해 하나대투증권은 ▲관리시스템(EAM)과 싱글사인온(SSO) ▲투자정보/MCI 차세대시스템 ▲차세대 메타데이터관리시스템 ▲영향도분석시스템 ▲통합단말 및 투자정보(HTS) 시스템 ▲형상관리 시스템 ▲차세대시스템 프레임워크 구축을 추진하게 된다.
증권사 중 차세대시스템 구축에 나서는 만큼 최신 기술과 방법론이 도입될 전망이다.
투자정보/MCI 차세대시스템 구축의 경우 확장에 능동적이고 유연한 대응을 위한 투자정보/MCI 인프라 전략 수립과 접속서버의 처리속도 향상 및 저비용 고성능 차세대 금융서비스 지원 플랫폼 구축을 내용으로 하고 있으며 리눅스 운영체제를 도입하게 된다.
증권업무 중 고객서비스 영역에서 가장 중요한 통합단말 및 투자정보(HTS) 시스템 구축을 통해 개선된 통합단말 환경 기반의 업무 효율성과 정합성을 제고하는 한편 투자정보(HTS) 시스템 고도화를 통한 경쟁력 확보에 나서게 된다.
500억원 규모 하나대투증권 차세대사업 발주…리눅스OS 등 도입중에서
혹시나 해서 찾아보니까 하나아이앤에스 알림마당 입찰공지에 RFP가 올라왔더군요. RFP를 살펴보니까 요구사항과 관련한 분량이 4~5쪽 분량밖에 없었습니다. MCI와 투자정보분야의 요구사항입니다.
앞서 기사에 나온 최신 기술과 방법론이 무엇을 말하는지 확인할 방법이 없었습니다. 그렇다고 제안요청서가 차세대시스템에 대한 요구사항을 명확히 정의하고 있는 듯 하지 않습니다. 다른 기사를 보면 선도개발을 먼저 한 후 본개발을 한다고 합니다. EXture+개발과 비슷한 모양입니다만 기술적인 요건이든 기능적인 요건이든 차세대시스템의 이미지가 보이지 않습니다.
하나대투증권은 다른 증권사 차세대 프로젝트와 달리 ISP 완료 후 바로 본사업을 하지 않는다. ISP 완료 후 핵심시스템에 대한 파일럿 프로젝트를 선도 사업으로 추진한다. 문 상무는 “본 사업을 진행하기 전에 먼저 소규모로 시스템을 개발하면서 나타날 수 있는 각종 문제를 먼저 경험하게 할 것”이라며 “이를 통해 본사업에서 오류를 최소화할 것”이라고 강조했다.
또 하나 특이한 것은 본사업에 앞서 진행하는 선도 사업을 자체 인력으로만 수행한다는 것이다. 문 상무는 “하나대투증권 IT를 담당하는 100여명의 하나INS 인력은 대규모 시스템 개발 사업을 진행한 경험이 적다”며 “그러기 때문에 사전에 먼저 선도 개발을 진행하면 본사업에서는 지금보다 몇 배 이상의 역량을 갖게 될 것”이라고 설명했다.
[CIO BIZ+/이노베이션리더] 문종귀 하나대투증권 CIO(하나I&S 상무)중에서
물론 제안서를 작성하는 분들은 고객이 요구하는 것을 영업을 통해 확인하고 최신 기술과 방법론을 제안하리라 생각합니다.
다시 Arrowhead로 돌아갑니다. 어떻게 동경증권거래소는 1,500쪽이 넘는 RFP를 내놓았을까요? TSE의 자료중 일부입니다. 아래 그림중 위부분이 일반적인 개발프로세스입니다. 아래부분은 TSE가 채택한 프로세스입니다. 이전에 TSE 프로젝트의 성공요인 – 발주기업의 자세에서 강조하였던 발주자 책임강화를 위하여 개발프로세스에 변화를 주었습니다.
발주자 책임의 핵심은 ‘요구사항’입니다. 요구사항을 명확히 하고 이를 개발기간동안 철저히 관리하여 개발시스템의 품질을 높히는 전략입니다. 2010년 TSE의 CIO가 발표한 東証Arrowheadの開発と要求実現プロセス에 자세히 정리되어 있습니다.
2.
일본의 소프트웨어산업은 한국과 비슷합니다. 미국과 달리 시스템통합(SI)이 중심을 이룹니다. 반면 다른 점이 있습니다. 일본의 SI가 엔지니어링과 같다고 하면 한국의 SI는 노가다와 같습니다. RFP와 밀접한 관련이 있는 요구공학을 바로보는 시각에서 느낍니다. 2011년 일본정보서비스산업협회(情報サービス産業協会,JISA)는 IEEE와 협력하여 세계에서 처음으로 요구공학지식체계(要求工学知識体系), REBOK(Requirements Engineering Body Of Knowledge)을 발간합니다. REBOK이 PMBOK, SWEBOK, BADOK와 어떤 관계가 있는지를 정리한 표입니다.
솔직히 저도 이해하지 못합니다. PMBOK은 오래전에 한번 읽어보았지만 SWEBOK도 잘 모릅니다. BABOK는 생소합니다. 그래도 요구사항이 프로젝트나 시스템 개발 혹은 비지니스분석에 중요한 점을 절감합니다. SWEBOK도 그렇지만 REBOK에 관심을 가진 이유입니다. 要求工学の動向と要求工学知識体系 REBOK을 보면 REBOK이 등장한 배경으로 잦은 프로젝트 실패입니다. 프로젝트 실패를 분석한 조사에 따르면 30%정도가 요구사항을 실패의 원인이라고 합니다.
아래는 REBOK을 설명한 자료입니다. REBOK는 일본아마존에서 판매하고 있습니다.
그러면 SWEBOK에서 정의한 요구사항을 어떻게 정의하고 있을까요? 김익환씨가 자세히 설명하고 있습니다.
SWEBOK – 소프트웨어 요구사항 #1
SWEBOK – 소프트웨어 요구사항 #2
SWEBOK – 소프트웨어 요구사항 #3
SWEBOK – 소프트웨어 요구사항 #4
SWEBOK – 소프트웨어 요구사항 #5
SWEBOK – 소프트웨어 요구사항 #6
SWEBOK – 소프트웨어 요구사항 #7
SWEBOK – 소프트웨어 요구사항 #8
SWEBOK – 소프트웨어 요구사항 #9
이상은 모두 요구공학의 영역입니다. 요구공학을 공부해보고 싶으시면 아래를 방문해보세요 현재 122회까지 온라인으로 강의를 하고 있습니다.
REBOK에 기초로 분석한 要求アナリストの確立と育成을 보면 요구사항분석가가 요구공학 프로세스를 주도하라고 합니다. 비즈니스 분석, 제품 분석, 시스템 분석 및 소프트웨어 분석까지를 겸합니다.
다시 RFP로 돌아가 보면 요구사항은 RFP의 출발입니다. 요구사항은 단순히 문서가 아니라 시스템의 목표이고 품질입니다. 그리고 조직내 다양한 관계의 반영입니다.
