금융만을 위한 젝스프레임워크(Jexframework)

젝스프레임워크는 자동 소스생성, 개발에 필요한 표준화된 툴, 재사용 등과 같이 개발 프레임워크의 특징을 가지고 있고 핀테크 서비스를 위한 높은 확장성을 고려하여 구성하였기 때문에 연구 사례로 선정하였다(그림3).

<그림 3> 젝스프레임워크의 구성

 

출처 : ㈜웹케시

젝스프레임워크는 기존 금융 서비스 연동하는 부분(Legacy 연동), 보안 관련 부분(Secure Center), 그리고 실제 서비스가 이루어지는부분 (Service Management)으로 나뉘어져 있고, 개발팀을 위해 개발 툴과 관리 툴을 제공하고 있다(그림4).

금융 관련 개발 프레임워크의 실제 구동 부분은 그림 4와 같이 세 부분으로 나뉘어져 있는 것이 일반적이다. 핀테크와 같이 비즈니스관련 서비스가 추가될 경우 서비스 관리(Service Management)에 기능을 추가하여 활용할 수 있다.

금융 프레임워크 구성은 다양한 디바이스와 채널에 따라 보안체계가 별도로 구축되어야 하고 데이터베이스와의 연동에 따른 보안도 등급에 따라 매우 구체적으로 정의되어야 하기때문에 필요하다면 검증된 상용 소프트웨어를 적용하는 것도 좋은 방안이 될 수 있다.

<그림 4> 젝스프레임워크의 역할별 구분

 

출처 : ㈜웹케시

더보기

다양한 핀테크 서비스를 쉽게 연계하기 위해 개발 프레임워크가 필요하다.

프로젝트 시작 전에 비즈니스의 기능과 특징에 맞춰 틀과 구조를 미리 만들어 놓은 것이다. 프로젝트가 시작한 후 흔들리지 않도록 구성하는 것이 매우 중요하며, 활용이 반복될수록 개발생산성과 만족도를 높여준다. 고객(사용자) 입장에서는 만들어진 것을 사용하면서개발팀에 따라 결과물이 다르게 나오는 것을 줄일 수 있고, 검증된 부분을 사용하면서 비용과 기간을 줄이고 만족도를 높일 수 있다.

단점도 있다. 시간이 흐를수록 다양한 기능들이 추가되면서 프레임워크의 규모가 너무 커져 관리가 어려울 수 있고, 프레임워크를 수정할 경우 연계되어 있는 수많은 소프트웨어들을 재검토해야 하는 문제점이 있다. 미리 정의되거나 일반적인 기능만 포함하는 경우가 많아 대규모 SI 프로젝트에서만 사용하는 경우가 많다.

최근에, 산업 단위로 소프트웨어의 표준을 정의하여 무분별한 소프트웨어 개발을 방지하고 소프트웨어를 체계화하는 작업이 요구되고있다. 산업과 기술 환경을 기초로 특정 비즈니스 프레임워크가 지속적으로 제안되고 있으며, 범국가적 차원으로 프레임워크 중심의 산업별 소프트웨어 청사진이 준비되고 있다(그림1).

<그림 1> 전자정부 표준프레임워크 포탈

 

출처 : 행정안전부 http://www.egovframe.go.kr/

더보기

핀테크의 적용 예

NH에서는 핀테크 오픈플랫폼이라는 개발 프레임워크를 제공하고 있다. 핀테크 업체가 기존 금융 서비스를 활용하는 핀테크 서비스를쉽게 개발할 수 있도록 금융 API 기반 환경을 제공한다(그림6).

그림7도 젝스프레임워크와 마찬가지로 금융 OPEN API를 통해 핀테크 기업과 연계 환경을 제공하고, 이를 관리할 수 있도록 제휴관리,시스템운영, 서비스관리, 플랫폼관리, 보안관리 등 5 개 영역의 관리 서비스를 제공한다. 마지막으로, LEGACY 연계를 통해 기존 금융시스템과 연계를 하는데 핀테크 업체는 이 부분에 관여하지 않도록 구성되어 있다.

<그림 6> NH 핀테크 오픈플랫폼

 

출처 : NH 농협은행

개발 프레임워크는 기존의 인터넷 뱅킹 등에서도 있었다. 인터넷 뱅킹의 개발 프레임워크와 핀테크의 개발 프레임워크에서 큰 차이점은, 핀테크는 타 서비스와의 확장성이 더 높게 고려된다는 점이다. 인터넷 뱅킹은 각 은행마다 별도의 시스템으로 운영되지만 핀테크는금융 기관과 별개인 핀테크 업체가 서비스하는 구성이기 때문이다.

더보기

SW공학의 변천사

1950년대는 SW공학에 대한 개념이 아직 정립되지 않은 시기로, 그 당시에는 SW개발을 위해 HW 공학적인 접근이 시도되었다. 1950년대 말에 추진되었던 대표적인 프로젝트인 SAGE (Semi-Automated Ground Environment) 프로젝트14)에는 레이더 공학자, 통신전문가, 컴퓨터 공학자, 초기 SW공학자 등이 대거 참여하였으며, 이들은 SW를 개발하는데 있어 기존의 HW공학 적인 개념을 적용한 SW공학을 적용하기 시작하였다. 

 

그림에서 보는 바와 같이 SAGE 프로젝트의 SW개발 프로세스는 연속적 폭포수 유형의 모델을 사 용하였으며, 프로젝트에 참여한 수천 명의 SW개발자들을 지원하기 위해 Lincoln Labs Utility System을 개발하여 라이브러리 및 빌드 관리와 테스트를 지원하기도 하였다.

SW공학 트렌드

이번 장은 Barry Boehm의 “A View of 20th and 21th Century Software Engineering”을 재 구성하여 SW공학의 도입 배경과 그 간의 시대적 요구에 따른 변화 과정, 그리고 앞으로 다가올 미래 전망에 대한 내용을 실었다. 어느 분야든 마찬가지겠지만 SW공학 분야에서도 가치 있는 과거 의 주요한 경험을 식별하여 향후 20~30년 내에 영향을 줄 수 있는 미래 변화에 발 빠르게 대응하 기 위해 변천사를 이해하는 것은 매우 중요하다. 

1950년대는 SW개발 프로젝트를 위해 HW공학과 유사한 SW공학 개념이 도입되기 시작하였지만 1960년대에 SW에 대한 수요가 급증하고 이를 구현하는 인력들의 경험과 능력, 수적인 부족이 원 인이 되어 ‘SW의 위기(SW Crisis)’가 발생하면서 본격적으로 SW공학이 도입되었다. 

이어 1970년대는 SW에 대한 수요가 급증하면서 SW개발인력이 부족하게 되었으며, 이를 해결하기 위해 SW전공자들이 아닌 비전공자들을 대거 투입하게 되고, 이러한 인력들은 SW개발 시 SW가 쉽게 수정될 수 있다는 점으로 인해 선코딩-후수정하는 접근방식을 택하게 되었다. 하지만 선코딩 -후수정에 대한 부작용으로 많은 결함들이 발견되면서 구조적 또는 정형적 기법들이 발생하였으 며, 분석, 설계, 구현 등을 순차적으로 진행하는 폭포수 모델을 개발하여 사용하기 시작하였다. 

하지만 정형적 기법은 일반 SW개발자들이 사용하기에는 사용성이 떨어지며, 폭포수 모델은 비용이 많이 소요되고, 진척도가 떨어진다는 점을 인식한 1980년대에는 재사용성을 높여 효율적으로 SW 를 개발하기 위해 SW개발 생산성을 높이기 위한 방법들을 연구하였다. 

1990년대는 시장에서 경쟁 우위를 점하기 위해 제품의 시장출시 시간을 단축해야 했다. 이로 인해 SW개발 생산성에 대한 연구가 활성화되었으며, 폭포수 모델에서 요구사항, 설계 및 구현 등을 동 시에 진행할 수 있는 동시공학(Concurrent Engineering)13)에 집중한 모델을 활용하였다. 

SW를 둘러싼 기술이나 시장 환경이 급속하게 변화하기 시작한 2000년대는 이러한 급속한 변화에 효과적으로 대응하기 위해 애자일 방법론이 본격적으로 도입되었다. 

더보기

SW개발자가 선택할 수 있는 미래의 직군

“개발자 미래에 대한 고민” SW개발이 좋아서 SW개발자가 된 사람들이 5~7년 개발을 하다 보면 미래에 대해서 생각하게 되고 불확실한 미래를 불안해한다. 대부분의 회사에서 개발자의 경력을 보 장해 주지 않기 때문에 막연히 팀장이 되기도 하고 다른 직종으로 옮기기도 한다. 그러다 보니 전문 성 있고 가치가 높은 개발자의 경험과 지식은 묻혀버리고 회사는 기술력을 축적하지 못하게 된다. 

전사적 관점에서 프로젝트에서 개발자가 선택할 수 있는 미래 모습을 제시하는 것도 SW개발자들이 집중하여 역량을 발휘할 수 있는 계기가 된다. 하지만 현실은 그렇게 아름답지만은 않다. 

더보기