건강보험심사평가원 ITSM 시스템의 메이저 업그레이드 구축 사례

건강보험심사평가원(이하 심평원) ITSM 업그레이드 프로젝트는 통합유지보수를 맡고있는 NDS(농심데이터센터)에서 진행하는 2023 대내외 업무서비스 개선사업 중 하나로써, 심평원은 2015년 STEG의 ITSM 제품인 Egene ITSM 3.5를 도입하여 오랜 시간 안정적인 운영을 해오고 있었으며, 누적된 프로세스 개선 요구를 반영하고, 신기술 기반의 ITSM 운영을 위해 기 사용되었던 프로세스와 데이터를 기반으로 Egene 6.3버전으로 메이저 업그레이드하는 프로젝트이었다.

오랜기간 사용했던 구 버전 솔루션에서 개선하기 어려운 사항들을 수용함과 동시에 이전과 동일한 사용자경험을 주기 위해 구 버전에서 사용했던 메뉴와 기능은 동일한 배치의 UI구조로 개발하여 사용자 재교육에 소요되는 시간을 줄일 수 있도록 구성했다.

본 글에서는 프로젝트에서 활용된 데이터 이관, 프로세스 튜닝, 신규 개발 기능을 중심으로 풀어보고자 한다.

 

1. 데이터이관

1) REP(Reusable Engagement Package)의 활용

※ REP란?

– Reusable Engagement Package의 줄임

< 워크플로우 기반으로 하위 구조를 모두 이관하는 REP 구성 >

 

REP는 솔루션 내에서 지원하는 Data Adapter를 응용한 기능으로, Data Adapter 내 DB to DB 방식을 이용하여 과거 프로세스 데이터를 신규 DB의 프로세스 관련 테이블로 맵핑하여 데이터 마이그레이션 및 프로세스 이관의 소요시간을 획기적으로 줄이기 위한 방법이다.

프로세스를 만들기 위해서는 엔터티 – 워크플로우 – 액티비티 – 타스크 – 폼의 구조를 맞추어 작업할 필요가 있다. 업그레이드 프로젝트인 경우, 동일하게 작성하기 위해 수동으로 데이터를 전환하여 싱크를 맞추는 방법으로 진행하게 되는데, 요청-접수-처리-장애이관/문제이관/지식이관-처리결재-종료 등의 중간 과정이 복잡한 프로세스를 구성할 때 누락되는 항목이나 기능이 있었다. 데이터 누락을 방지하고 동일한 프로세스 구축을 하기 위해서 검토시간을 더 할애하기 때문에, 전체 구축시간의 증가는 피할 수 없었다.

심평원 프로젝트를 진행하며 선제적으로 개발했던 서비스요청 프로세스의 개발기간은 약 3일이 소요되었고, 내부적인 로직을 확인 및 수정하여 현재 시스템에서 구동할 수 있도록 완성하기 까지는 약 5일정도 소요되었다. 수동으로 작성한 프로세스가 완료된 이 후 REP를 구성하여 테스트케이스로 동일한 프로세스를 옮겨 작업하게 되었는데, 프로세스 이관에는 5분내외로 소요되었고 내부적인 로직 확인 및 수정에는 약 3일정도가 소요되었다.

내부 로직 분석 및 수정을 한 번 수행한 직 후였기 때문에 확인 및 수정 단계에서 들어간 공수에 대해서는 다소 단축될 여지가 있으나, 약 3일에서 5분 내외로 소요되는 프로세스 데이터의 이관 소요시간은 효과적이라고 할 수 있었다.

< REP를 이용하여 프로세스 수동이관 소요시간을 크게 단축 >

 

상기 그림에서와 같이 REP를 이용하여 프로세스 이관 소요시간을 크게 단축하였음을 도식화하였다.

다만, 아쉬운 점은 건강보험심사평가원의 버전이 3.5로 평소 4, 5버전의 업그레이드 프로젝트와 달리 특히 낮은 버전이었기에 6.3에서 사용하는 스키마 정보와 다른 항목이 존재하여 데이터를 담는 오브젝트의 형태나 데이터의 적재방식과 출력 로직이 상이했다. 따라서, REP를 사용했음에도 불구하고 후처리 해야 하는 일부 항목들이 발견되었고 해당 테이블 정보를 수정하여 이관하게 되었다.

REP가 본격적으로 사용된다면 이와 같은 발생가능한 변수를 제어하기 위해 각 버전별로 현재 상용되고 있는 제품의 버전과 스키마 정보 및 적재방식이 어떻게 다른 지 정리할 필요가 있다고 생각한다. 각 버전 별 스키마 및 데이터 출력방식과 적재방식이 정리되어 특정 버전에 맞게 사용할 수 있다면, 더욱 완성도 높은 REP가 될 것이다.

2) 패치기능의 활용

※ 패치란?

– 솔루션 내에서 지원하는 기능으로 XML 구조로 데이터를 가공하여 솔루션 간 데이터 이동 및 적용이 가능하도록 구성된 기능

< SQL 기초 지식만 있어도 사용 가능한 로우코드 친화적인 패치기능 >

 

패치기능은 간단한 SQL Select문으로 원하는 테이블의 특정 데이터를 이관하는 Data Picking에 용이하기 때문에, 데이터 마이그레이션 시에 솔루션 내 티켓 생성시 작성되는 REG_DTTM을 기준으로 특정 데이터를 수집하여 패치로 만들어 이관하는 방식으로 최초 데이터 마이그레이션을 진행했다.

1차 이관 이후, 2차 이관 시점을 명확히 할 수 있기에 선택한 방법이었으나 400만 건의 데이터를 이관하는 데에는 부적합한 방식이었다. 대량의 데이터를 패치 이관 시 솔루션에 가해지는 부하가 있었고, 패치 내 문자열 데이터가 많은 경우에는 속도저하가 존재했다. 순수하게 데이터 마이그레이션을 위한 기능은 아니었으나 중간 산출물인 패치가 증적 자료로 활용할 수 있는 여지가 있기 때문에, 속도와 부하를 해결한다면 마이그레이션 툴로써 확장가능성 있는 기능이라고 생각한다.

3) Data Adapter DB to DB의 활용

– 이관이 필요한 AS-IS의 DB 데이터를 TO-BE DB 내에 맵핑 및 데이터 적재하는 내부 기능

– 별도의 DB 유틸 및 DB 권한이 없는 상태에서 솔루션 내부 기능만으로 데이터 이관하기 위한 방법 중 하나

< 데이터소스에 등록된 접속정보 기반, DB to DB로 데이터를 적재하는 Data Adapter >

 

패치기능으로 마이그레이션을 진행해 본 결과, 속도면에서 아쉬움이 많아 Data Adapter 기능을 이용해 AS-IS DB와 TO-BE DB를 연결하여 솔루션을 이용해 데이터를 가져오려고 시도했다. 패치이관과는 다르게 별도의 중간산출물인 패치가 나오지 않아 데이터를 쪼개지 않고 테이블 단위로 데이터를 맵핑해서 옮긴다는 부분에서는 유용했을 뿐만 아니라, 속도 면에서도 패치이관 보다 빠른 편이었다.

하지만, 400만 건의 데이터를 옮기는 데에는 여전히 오랜 시간이 필요했고, 패치와 동일하게 솔루션에 부하가 가해지고 있었기에 일시적 서비스 중단으로 해결할 수 있는 문제는 아니었다. 결국, 2차 이관은 고객사의 DB권한 협조를 요청하여 DB Link를 통해 DB툴을 이용하여 직접 옮기는 것으로 해결했다.

4) 쿼리 튜닝 및 인덱스 설정
데이터 이관 이후, 일부 리스트에서 출력되는 시간이 길다는 요청이 있어 확인해본 결과, 해당 증상은 계층형 쿼리 내에 서브쿼리로 다시 계층형 쿼리를 작성하고 DB Function을 사용한 쿼리로 파악되었다. 속도를 높이기 위해서 불필요하게 사용중인 DB Function을 제거 및 계층형 쿼리 조건절에서 사용하는 컬럼에 대해 인덱스 처리하는 것으로 속도를 향상시켰다.

계층형으로 그려지는 Tree 리스트의 경우에는 모든 Row를 전부 그린 뒤에 페이징 처리하는 로직으로 작성되어 있어 사용자 입장에서 체감하는 출력속도 면에서 아쉬운 점이 있었으나, 일반 리스트의 페이징을 가진 들여쓰기로 Tree 리스트처럼 출력되는 리스트 기능을 개발 받아 적용하여 해결했다.

 

2. 프로세스 튜닝

REP로 옮긴 데이터 및 이관한 데이터를 기반으로 프로세스 테스트 결과 도출되는 에러를 처리하기 위한 방법으로 아래와 같은 방법을 이용하여 수정 및 개발업무를 수행했다.

1) 지원이 종료된 미사용 아톰 정리
과거 Egene 3.5 버전에서 개발되었거나 사용된 아톰 데이터를 기반으로 UIITEM 값을 출력하기 때문에 지원이 종료되거나 Egene 6.3에서 미사용 중인 아톰인 경우 출력되지 않는 문제가 발생했다. 따라서 해당 화면의 출력면에서 만족도 높은 결과를 기대할 수 없으므로, 비표준 아톰 데이터는 수동으로 대체 가능한 아톰정보로 변경하여 처리했다. 향후, 폼 필드 내 UIITEM 값이 표준화된 아톰인지 체크할 수 있다면 지원 종료된 아톰을 정리하는 데 있어 더욱 효과적일 것이라고 예상한다.

2) 아톰 내부 정의된 SQL 수정
Egene 3.5 버전에서 6.3까지 동일하게 사용된 아톰인 경우, 아톰 내부에서 참조하는 SQL이 수정된 케이스가 상당수 존재했는데, 해당 출력 방식을 확인하기 위해서는 동일한 아톰과 데이터를 바탕으로 동일한 값이 출력되는지 체크해 볼 필요가 있었다. 해당하는 아톰을 개발도구로 열어 확인하기 전에는 참조하고 있는 SQL 정보를 알 수 있는 방법이 없었기에 충분한 분석시간이 필요했다.

뿐 만 아니라 ECR_SQL 테이블의 경우, 데이터 이관을 통해 SQL ID가 중복되는 항목에 대해서 덮어쓰기 여부를 판단하기 어렵기 때문에 업그레이드 프로젝트에 이관할 때 해당 SQL 데이터의 영향도를 고려하여 이관해야 하는 점도 분석시간 지연의 원인으로 판단되었다.

아톰 내부에 특정 SQL이 지정된 경우, SQL 이관 시 아톰과 연계된 항목인지 연관체크가 가능한 기능이 구현된다면 분석시간을 단축할 수 있을 것이다.

3) 과거 jsp 개발된 기능을 솔루션 기능으로 대체
심평원 내에서 리눅스 환경에 크론탭을 이용하여 솔루션 내 jspCaller를 호출하는 방식으로 특정 시간에 인터페이스를 위한 배치용 jsp 파일을 호출하여 수행하는 기능이 존재했으나, Data Adapter의 CallFile 기능과 동일하게 사용이 가능하기 때문에 해당 기능으로 대체하여 개발되었다.

기존 개발된 jsp 호출의 경우, 리눅스에 정의되었다는 히스토리를 전달받지 않는 이상 운영 및 관리 측면에서 파악이 어려운 점으로 작용했다. 현재는 Data Adapter 내에서 동일하게 작동하도록 설정하여, 솔루션 내에서 관리되므로 히스토리 전달이 누락되어도 운영 및 관리단에서 Data Adapter를 확인하여 투명하게 관리 가능하다.는 점에서 고객이 만족하는 사례가 되었다.

 

3. 신규 기능 개발

1) 랙 상면도
자산관리에서 파생된 기능으로 각 자산별 랙 위치에 따른 실물자산 관리를 위한 직관적인 기능으로 탈바꿈했다. 기존에 자산에서 연결되었던 구조와 달리 각각 층, 존, 랙, 슬롯으로 이루어지는 계층적 구조로 관리되어 자산의 상태관리 측면에서 사용자로 하여금 상면구조를 지정하여 상세하게 위치를 확인가능한 방식으로 개발되었다.

각각의 자산상태 뿐 아니라, 랙 용량 기준인 42U를 기본으로 각 랙에서 위치하는 시작 유닛과 끝 유닛정보를 지정된 양식의 랙 관리번호로 작성하면 정해진 위치에 맞게 화면에 출력할 수 있도록 구현되어 있어 구체적인 슬롯파악이 가능한 점이 특징이다.

< 좌, 자산관리 파생기능의 기존 랙 관리화면. 우, 신규로 개발된 랙 관리화면 >

 

기존 관리정보와는 다르게 층, 존, 랙, 슬롯 등의 계층에 따른 기준정보 작성 혹은 데이터 마이그레이션이 필요하며 랙은 무조건 상위 개념인 존의 기준으로 채번되기 때문에, 랙의 독자적인 채번이 필요한 경우 불가능한 점으로 이를 개선하고 계층구조 데이터를 최적화한다면, 발전 가능성있는 새로운 관리화면으로써 이용가치가 올라갈 것이라고 생각한다.

2) 사업관리
솔루션 내의 릴레이션 리스트를 다중으로 한 폼에 쌓아 만든 관리기능으로, 고객의 요청에 의해 기존 엑셀을 사용하듯 단일 화면에 원하는 정보를 자유롭게 입력하고 자동계산이 되는 화면을 구성했다. 이 뿐 아니라 각 항목별로 작성해야 할 항목이 많기 때문에 모든 릴레이션 리스트에 엑셀업로드 및 다운로드 기능을 추가하여 원하는 정보를 입력하거나 내려받아 취합이 용이하도록 설정했다.

< 단일화면에서 릴레이션을 이용한 다중 입력처리 및 자동계산 되는 프로젝트 관리 >

 

아쉬운 점으로는 릴레이션 추가 및 삭제 시 자동계산 로직을 호출하기 위해서는 각 릴레이션 버튼 내에 별도의 Handler를 정의하여 매 액션마다 처리하도록 구성이 필요했다. 각 릴레이션 리스트 별로 해당 버튼에 할당하는 부분에서 릴레이션 풀로드 시점을 명확히 구분할 수 없어 동작하지 않는 상황이 있었으나, 타이머를 이용하여 조치하는 것으로 해결했다.

심평원 ITSM 업그레이드 프로젝트를 통해 솔루션 업그레이드를 수행함에 있어서, 고객사의 상황과 조건에 맞는 다양한 방법과 수행방안이 있음을 체감했다. REP를 통해 합리적인 프로세스 이관 로직의 가능성을 판단했으며 프로세스 튜닝을 통해 사용자 경험을 유지할 수 있는 방안을 발견했다.

본 기고에서 기술한 내용들은, 이번 솔루션 업그레이드 프로젝트에서 시도하고 수행했던 방법들로 Egene 솔루션이 다양한 사용자의 요구사항과 변화하는 IT 신기술을 수용하면서 일정한 방향으로 꾸준히 진화해 왔기 때문에 가능한 일이었다. 일부 아쉬운 부분도 있었으나 솔루션을 응용하여 끝내 해결할 수 있었고, 이를 발판삼아 진화해 나가는 것이 Egene 솔루션과 에스티이지의 강점이기 때문에 앞으로도 지속되는 버전 업을 통해 더욱 발전하는 Egene 솔루션이 될 것이라 믿어 의심치 않는다.

㈜에스티이지 PS2팀 박현무 프로