투이컨설팅 이상진 이사
카카오뱅크 오픈 이후 개방형 인프라, 아키텍처로 전환하려는 금융회사들이 많다. 리눅스 기반 오픈소스 인프라 도입을 적극적으로 추진하는 추세이다. 첫째, 오픈소스가 갖는 확장성과 유연성을 활용하기 위해서, 둘째, 기존 소프트웨어 벤더들의 횡포로 인한 운영비용 급증에 대처하기 위해서이다. 카카오뱅크가 예상을 뛰어넘는 거래량 폭발에 신속하게 대응할 수 있었던 것은 리눅스 기반 아키텍처를 채택하고 있었기 때문이다. 우리나라 금융회사들의 리눅스 도입 및 활용 범위 확대는 당연한 추세이다. 하지만, 기술 인프라를 바꾼다는 것은 위험도가 크다. 필자가 경험한 사례를 통해서, 교훈을 정리해본다.
[상황]
A사 프로젝트의 경우 ISP 단계부터 인프라, 아키텍처를 전문적으로 담당하는 B사가 수행하였다. 당연히 B사 제품으로 차세대 인프라가 선정되었다. 개발 조직이 없던 B사는 인프라와 아키텍처(솔루션 포함)를 맡고, 응용프로그램은 C사가 맡아서 개발하였다. 금융회사가 전산시스템을 새로 구축하면서 인프라와 응용프로그램을 분리해서 발주하는 것은 보통 있는 일이며 이 상황에서만 볼 수 있는 이례적인 것은 아니다. A사 차세대시스템 인프라 아키텍처는 B사가 제안한 구성대로 세팅이 이루어졌고, C사는 B사가 제안하고 설계한 인프라, 아키텍처 기본 구성 위에서 개발을 진행하였다. 기존 Unix 시스템을 사용하던 A사는 메인프레임으로 전환을 진행하였다.
[문제]
1. 검증 안된 아키텍처
메인프레임에 java와 C 프레임워크를 사용하는 것은 외국에서도 대규모 프로젝트에서 검증이 안된 기술 체계였다. 응용 프로그램 개발과 동시에 프레임워크도 개발해야 하는 상황에서 개발의 생산성 저하 및 안정성 저하가 프로젝트 처음부터 끝까지 문제점으로 대두되었다. 요건이 상세화되면서 각 영역 간 인터페이스 솔루션은 양방향으로 인터페이스 기능을 수용하지 못하는 등의 기능 미흡 및 부적절 현상이 발생하였고, 실시간 DB 동기화 솔루션은 모든 테이블에 스크립트를 만들어 주어야 하는 등의 운영 복잡성 문제가 발생하여 전체 아키텍처 변경 및 재작업으로 인해 프로젝트는 지연되기 시작했고, 따라서 리스크는 올라갔다.
2. 부족한 시스템 용량
초기 시스템 용량 산정은 B사가 TO-BE 아키텍처 및 솔루션을 확정하지 않고, 기존 AS-IS 소스 변환을 통한 BMT를 시행하여 용량을 산정하였다. 프로젝트가 진행되면서 차세대 프레임워크, 채널 간 연계 솔루션, 업무영역 간 연계 솔루션 등 아키텍처 확정 및 솔루션 탑재로 인하여 시스템 용량 부족 현상이 발생하였고, 처음 용량보다 3배 가까운 용량을 확장하고도 피크 타임에는 부족하여 실시간 업무를 후선 업무로 바꾸는 작업을 감행하게 되었다.
프로젝트는 위와 같은 문제점으로 인하여 지연되었고, 오픈 리스크가 완벽하게 해결되지 않았다. 결국 프로젝트 중단이라는 초유의 사태가 발생하였다. 물론 기술적인 문제 외에 정치적인 이유가 컸지만 결과적으로 프로젝트를 중단하는 빌미를 제공하게 되었다. 프로젝트를 중단함으로써 발주사에 많은 손실을 안겼다.
[교훈]
인프라, 아키텍처의 변경은 기존 운영 인력이 갖고 있는 노하우 및 기술력이 쓸모 없어짐을 의미한다. 즉 새롭게 적용하는 인프라, 아키텍처에 대해 내부 전문가가 없다는 것이다. 운영 인력 중 전문가가 없다는 것은 인프라의 적합성, 용량, 유연성, 가용성 등 필요 요소에 대한 검증을 완벽히 할 수 없다. 위 사례와 같이 제안사에 의존한 프로젝트 진행으로 실패할 가능성이 높아진다.
내부에 전문가가 없다면 외부 인력이라도 직원으로 채용하여 조직 안에서 자체적 검증을 할 수 있는 인력을 반드시 갖춰야 한다.
또한 검증 프로세스도 갖춰 개인의 검증이 아닌 집단으로 검증할 수 있도록 해야 한다. 내부에 전문가 인력이 없거나, 부족하다면 중요 시스템을 동시에 변경하는 방식보다는 중요 시스템을 제외한 나머지 시스템을 순차적으로 변경하여 노하우 및 기술력을 쌓는 기간 및 플랜이 필요하다.
새로운 방식의 인프라 및 아키텍처 도입을 위해서는 위 사례와 같이 AS-IS 시스템의 환경이 아닌 TO-BE 인프라, 아키텍처 및 솔루션이 확정된 상태에서 POC 및 BMT를 구축 프로젝트 시작 전 완료하여야 한다.
프로젝트 후반기에 부하/가용성 테스트 기간을 통상적인 프로젝트보다 충분히 확보하여 새로운 인프라, 아키텍처 도입에 따른 예상치 못한 위험에 대비할 필요가 있다.
[결론]
카카오뱅크가 금융 서비스에 리눅스를 성공적으로 도입할 수 있었던 것은, 카카오에서 이미 리눅스 인프라를 충분히 경험한 뛰어난 전문가 집단을 내부에 확보하고 있었던 덕분이다. 문제가 발생했을 때 외부 벤더가 아니라 자체 역량으로 신속하고 완전하게 해결해나갈 수 있었다. 인프라 기술을 바꾼다는 것은 또한 기존 거래 방식, 애플리케이션, 데이터베이스 등을 전환한다는 의미이다. 사전에 충분한 검증과 확인 그리고 대안 수립이 필요하다. 프로젝트 계획에는 다양한 테스트와 리스크 플랜이 반영되어야 한다.
<참고>
POC : Proof Of Concept ( ‘새로운 솔루션이 원하는 기능을 작동하는가?’ 점검하는 테스트)
BMT : Benchmark Test ( ‘확정된 아키텍처 위에서 하드웨어가 원하는 성능을 내는가?’ 점검하는 테스트)
- 끝 -
※ 위 내용은 '투이톡' 모바일 앱을 통해서도 확인하실 수 있습니다.
하루 5분, 스마트해지는 시간~투이톡!!
