분할 후 정복하라, Divide and Conquer!

소프트웨어 공학의 창시자들 중 한사람인 네덜란드의 에츠허르 데이크스트라(Edsger Wybe Dijkstra)는 1970년대에 이미 ‘분할 후 정복’을 주장했다. 전체 문제를 다룰 수 있는 범위로 먼저 나누고 그 다음에 각 단위 업무를 개발하여야 한다는 것이다.
하지만 지금까지도 대상 업무를 나누기 보다는 동시에 개발하는 빅뱅 방식은 여전히 매력을 잃지 않고 있다. 빅뱅 방식이 주는 리스크보다도 효율성과 통합성이 더 중요하다고 생각하기 때문이다.

금융회사의 빅뱅 방식은 복잡도가 높은 시스템들(채널계-계정계-정보계)을 한번에 오픈하는 방식으로 근간이 되는 계정계의 품질 완성도가 완벽하지 않은 상태에서 전체 시스템을 테스트하고, 오픈하려고 하다 보면, 개발 단계 이후 수많은 이슈가 발생하여 프로젝트 일정이 늦춰지거나 심지어 시스템 오픈 일정까지 연기되기도 한다.

게다가 이 방식은 최근 들어 금융권 시스템에서 계정계보다 정보계, 채널계의 중요성이 높아지는상황에서 2년여의 긴 차세대시스템 구축 기간 도중 발생하는 IT신기술을 적절하게 프로젝트에 반영하지 못하는 단점도 있다.

그러나 이러한 문제점에도 불구하고 국내 금융회사의 수직적 IT조직 구조상 IT인프라를 차세대 환경으로 일시에 전환시키는 것이 결과적으로 더 효율적인 방식이라는 의견도 있고, 과거와 달리 프레임워크의 발전으로 시스템의 블록화가 예전보다 유연해지면서 IT신기술의 수용도 용이해졌으며, 그동안 쌓인 빅뱅 방식의 노하우가 세계 제일이라는 장점도 있기 때문에 여전히 빅뱅방식으로 차세대시스템을 구축하는 대형 프로젝트가 진행되고 있는 상황이다.

**빅뱅방식의 프로젝트 현황
2019년 오픈: 산업은행, KSD, KB카드, NH농협카드, 교보생명 등
2020년 오픈: 한국은행, BC카드 차세대 등
2020년 시작: 한화생명, 우체국금융 차세대시스템 등 빅뱅방식으로 진행 예정

대형 프로젝트의 오픈을 위해서는 전체 프로젝트 기간에 걸친 관리가 중요하지만 특히 개발 이후 통합테스트부터 이행까지의 관리가 더욱 중요하다. 프로젝트 후반으로 갈수록 오픈 리스크와 이슈가 대규모 발생하기 때문이다.

필자는 본 글을 통해 복잡한 시스템을 한번에 오픈할 때 일어날 수 있는 문제를 효과적으로 해결하여 빅뱅 방식 대형 프로젝트를 일정에 차질없이 성공적으로 오픈할 수 있는 방법(개발 단계 이후 오픈 노하우)을 알아보고자 한다.

1. 오픈 지표를 통한 프로젝트 전체 진행 관리 및 오픈 공감대 형성

대형 차세대 프로젝트의 경우 통합테스트 후 오픈까지 보통 3~4개월의 영업점 테스트 및 이행 기간을 설정하여 프로젝트를 진행한다. 영업점 테스트 목표를 달성하였다고 프로젝트를 오픈 할 수 있을까? 영업점 테스트는 보통 각 영업점이 많이 사용하는 거래 중심으로 전체 시스템 기능의 20~30%를 커버리지를 확보할 수 있으나 전체 시스템 관점의 기능 및 성능 완전성을 담보하지는 않는다.

이를 보완하여 오픈 가능 여부를 판단하고 오픈 공감대를 형성하기 위하여 오픈지표를 측정하고 관리하여야 한다.

오픈지표는 기능완성도, 데이터완성도, 성능/가용성, 보안, 테마테스트, 이행리허설 등 오픈에 필요한 모든 요소를 설정하고, 오픈 전 한번 측정하는 것이 아닌 3회 이상 차수별 목표를 설정하고, 지속적 측정하여 전체 프로젝트를 오픈 지표 중심으로 관리하여야 한다.

또한 매주 측정자료 공개를 통한 각 차수별 목표 도달이 어려운 부분을 미리 숙지하게 하여 품질을 향상시키며, 각 차수별 목표 달성여부 측정 후에는 steering committee(발주사, 수행사, PMO 최고 의사 결정권자 회의체)를 수행하여 오픈지표 미달 영역의 현실적 향후 계획을 확보하고, 오픈지표의 중요성 분위기를 조성하여야 한다.

2. 영업점테스트와 중점테스트 TWO TRACK 전략 시행

영업점 테스트는 일정을 spot(특정 주말 테스트 방식)으로 지정하여 시행하는 경우가 대부분이다. 영업점 테스트 전 수행사는 영업점 테스트 준비 및 리허설 등의 일정을 가지고 진행하지만 발주사는 이 시기에 따로 진행하는 공식 타스크가 존재하지 않는다. 이때 필요한 것이 중점테스트(또는 오픈테스트) 진행이다. 통합테스트 후 전체 시스템을 발주사가 회기 테스트(테스트 한 부분을 다시 테스트 하는 방식)하는 것이 중요하다. 통합테스트 후에도 많은 소스 및 테이블이 변경되기 때문에 이런 회기 테스트는 꼭 필요한 부분이다.

프로젝트 상황에 따라 미진사항만을 중점적으로 테스트 하거나, 전체 영역을 회기 테스트 할 수 있는 방향으로 공식적 타스크를 만들고, 이 결과를 오픈지표의 기능완성도 영역으로 측정하여 효과를 높이는 전략으로 추진한다.

3. 오픈 전 Daily-Cycle 테스트 시행

오픈 지표도 지속적인 시스템의 안정성을 측정하는 데는 한계가 있다. 목표 시간까지 테스트를 통한 품질을 측정하는 방식이기 때문이다. 이를 보완하기 위해 오픈 전 Daily-Cycle 테스트가 필요하다.

스케줄러에 의한 Daily-Batch 성공률, 센터컷 성공률, 정보계 변경적재 성공률 등을 오픈 전 1~2주동안 매일 실행(휴일 포함)하고 성공률을 측정하여 오픈 후 실제 발생할 수 있는 결함을 최소화 할 수 있다. 지속적 테스트를 통하여 날짜 변경 또는 휴일에 따른 경우의 수, 지속적 테스트를 통한 시스템 테스트 커버리지 확대 등의 이유로 실질적인 시스템의 품질을 높일 수 있다.

중요한 포인트는 온라인 테스트의 경우의 수를 많이 발생시켜 주어야(즉 병행하여 진행 필요) 위 Batch, 센터컷, 정보계 변경적재 등이 목적에 맞게 Daily로 테스트가 가능하다는 것이다. 위에서 언급한 중점테스트와 병행이 효율적 방법이다.
 

4. PM그룹 Daily 협의를 통한 신속한 의사결정체계 가동

오픈지표 측정 및 Daily-Cycle 테스트 등에서 발생한 문제를 해결할 의사결정체가 필요하다.

이슈협의회, 리스크협의회를 통해서 일주일에 1~2번 점검하고 관리하는게 보통의 프로젝트이나, 이는 오픈이 가까워오는 3~4개월 전에는 위 방식으로 문제를 빠르게 해결하기 어렵다. 이를 가장 빠르게 해결할 수 있는 협의체는 PM그룹 협의체이다. 보통 프로젝트 종료 시점이 가까워 올수록 이슈가 하나의 영역으로 귀결되지 않고, 서로 엉켜 있는 경우가 대부분이기 때문에 각 영역(팀)에서 이슈협의회 등을 진행할 경우 프로젝트 전체의 시각에서 효과적으로 진행하기 보다는 각 영역(팀)의 유리한 방향으로 문제를 해결하기 때문에 문제가 잘 해결되지 않고, 영역간의 싸움으로 시간만 가는 경우가 많다.

발주사, 수행사, PMO 각 PM이 Daily로 문제가 있는 영역들을 호출하고 조율하여 해결하는 방식이 가장 빠르고 정확하다.

5. 영업점 테스트 결함 해결률을 통한 오픈 자신감 획득

영업점 테스트의 목표는 실 사용자 관점에서 테스트를 통한 시스템의 품질 향상 및 변화된 시스템의 적응력(변화관리)을 높이는데 있다. 그러나 영업점 테스트 결과를 활용하여 오픈 여부 판단 근거 및 프로젝트 오픈 자신감을 높이는데도 사용할 수 있다.

실제 오픈 후 상황과 가장 비슷한 상황에서 당일 결함을 당일 처리할 수 있다면 오픈에 대한 두려움을 크게 떨쳐낼 수 있기 때문이다.

이를 위하여 영업점 테스트 리허설을 시행하고, 오픈 종합 상황실과 help desk 가동하여 의사소통체계를 원활히 할 수 있는 준비를 철저히 수행하고, 영업점 테스트 후 중복결함 제거 및 결함 해결사항을 실시간으로 반영하여 오픈 후 상황과 가장 비슷한 상황으로 전체 프로젝트의 대응 능력을 높여야 한다.

오픈에 자신감을 얻는다는 것은 프로젝트 각 구성원에 엄청난 변화를 가져온다. 결함처리 속도, 이슈를 해결하는 속도 등이 달라지고, 이를 바탕으로 더욱 상승된 결과가 만들어지는 선순환이 일어나기 때문이다.

6. 정보계 및 후방업무(리스크 영역)의 AS-IS 데이터를 통한 품질 확보

계정계가 안정화 되지 않은 상태에서 후방업무(정보계, 리스크 등) 테스트 진행 시 데이터가 맞지 않아 검증이 쉽지 않다. 즉 계정계의 불완전한 데이터가 원인인지 후방업무 처리 시 발생한 문제인지 원인 파악이 쉽지 않고, 정답지가 없어 해결 후에도 검증이 오래 걸린다.

이를 해결하기 위해서 정보계는 이행 테스트 당일 데이터를 검증용으로 특정 미래 날짜로 변경하여 따로 보관하고, 계정계 테스트 이행한 당일 데이터로 정보계 변경적재를 시행하면 미래날짜로 변경된 데이터가 정답지가 되어 비교하기 쉽고, 원인 파악이 용이해 진다. 즉 계정계 데이터 오류인지 정보계 프로그램 오류인지를 정확히 알 수 있다. 이렇게 정보계에 변경적재된 데이터를 바탕으로 후방업무(리스크 및 각종 마트)도 변경적재 하여 테스트를 수행하면 효율적으로 데이터 품질을 확보 할 수 있다.

정보계 변경적재 측정 시 중요 column만을 대상으로 하지 않고, 원장 테이블 단위로 마이너스 쿼리로 컬럼비교를 시행하면 더욱 정확한 결과를 측정 할 수 있다(마이너스 쿼리란 정답 데이터 – 수행한 데이터의 결과로 틀린 데이터를 전부 추출할 수 있는 방법이다).

위와 같이 정보계와 후방업무의 품질 확보 후 계정계와 연결 테스트를 시행하면 계정계 데이터 안정화 시간을 확보할 수 있을 뿐 아니라 효과적인 테스트를 시행 할 수 있다.

7. 비대면 테스트 조직, 제 3자 테스트, 테스트 전담팀 등 다양한 테스트 주체 활용

차세대 프로젝트 진행 시 다양한 테스트 조직을 구성해서 시행하게 된다.

현업 조직을 동원하여 테스트를 시행하는 경우 현업 업무와 병행하여 테스트를 하고, 테스트 환경(외부 시스템과 연결하는 데이터는 일부 테스트 데이터만 존재, 외부 테스트 연결 가능 시간 존재, AS-IS 시스템과 연결 시 데이터 불일치 등)을 이해하기 어려워 실제적인 테스트를 진행하기 어렵다.

현업이 테스트하여 도출한 많은 결함들 중 상당수가 이런 환경적인 원인이 된 결함을 도출하여 실제 품질을 높이는 데는 한계가 존재한다. 이런 문제를 해결하기 위해서는 테스트 초기부터 현업 직원들로 구성된 테스트 전담팀을 구성할 필요가 있다. 환경을 이해하는 동일인이 테스트 초기부터 오픈까지 테스트를 진행하여 실질적인 품질 향상을 이룰 수 있고, 정확한 시스템 품질 측정 가능하다. 또한 이렇게 차세대 시스템을 이해하는 현업이 오픈 후 Help Desk 업무를 수행하면 원활하게 영업점 및 타 현업을 지원할 수 있다.

비대면 테스트(인터넷, 모바일 등)는 비대면 테스트 전문 업체를 선정하여 진행하는 것이 효과적이다. 업무에 대한 이해도가 일반인과 같으면 큰 문제 없이 진행할 수 있고, 전문적으로 비대면만 테스트를 시행하여 노하우(테스트 시나리오, 테스트 컨디션 도출 등)가 축적되어 있기 때문이다. 기능뿐만 아니라, 모바일 기기별 테스트, 인터넷 브라우저별 테스트, Window 버전별 테스트 등 다양한 테스트를 진행한다.

제3자 테스트(보통 은퇴한 영업점 직원/텔러 등) 및 인턴을 활용한 다른 시각의 black box 테스트를 추가 시행하는 것도 요즘 대규모 프로젝트의 추세이다. 같은 사람이 같은 프로그램을 테스트 하면 효과적으로 깊은(비즈니스 프로세스의 연결 및 예외 데이터를 통한 테스트) 테스트를 수행할 수는 있지만 같은 패턴의 테스트를 시행하게 되어 한계가 존재하기 때문이다.

프로젝트 내에서 3자 테스트 그룹은 개발조직과는 독립적으로 구성되며, 개발조직에서 작성되고 테스트까지 완료된 프로그램에 대하여 재확인 테스트를 수행하여 객관적 품질수준을 확인하고, 이후 단계의 테스트 수행 전략에 반영, 효율적인 테스트 수행을 진행하도록 지원한다.

-끝-