[데이터넷] 메인프레임을 유닉스로 다운사이징한 차세대 시스템이 개통된 이후 길게는 16년이 지났다. 16년이 지나는 동안 많은 개발자를 거치면서 애플리케이션이 운영 및 유지보수 되면서 거대한 ‘레거시 괴물’이 됐다. 이 레거시 괴물 애플리케이션을 유지보수 및 운영하는 조직도 그만큼 비대해졌고, 조직 내의 커뮤니케이션 복잡도도 기하급수적으로 커졌다. <편집자>

- 연재 순서 - 1. 제임스 루이스와 마틴 파울러의 MSA 2. 처음부터 MSA로 시작하는 것은 위험하다 3. 서비스 메시와 아키텍처 결정 포인트 4. NCD 기반 애플리케이션 현대화(이번호)

‘레거시 괴물’이 무서운 것은 십수 년이 지난 지금 그 실체를 전부 아는 사람이 하나도 없고, 단지 떠도는 소문만으로도 담당 업무 팀과 개발자들을 공포의 도가니로 밀어 넣고 있다는 것이다.

유닉스 기반의 레거시 괴물 애플리케이션을 업무팀 단위로 x86 및 최신 기술 기반의 스마트한 애플리케이션으로 현대화해 하나의 팀이 담당할 수 있는 업무 단위로 애플리케이션을 분리하고, 블랙박스(Black-box)인 레거시 괴물 애플리케이션을 현대화해 화이트박스(White-box) 애플리케이션으로 어떻게 가시화하는지에 대해 실제 사례를 들어 살펴보자.

블랙박스 상태인 모놀리식 애플리케이션
필자가 2023년 9월부터 수행한 프로젝트는 NCD(No Code Development) 툴을 이용해 개발 및 유지보수 중이던 애플리케이션을 전자정부 프레임워크 기반의 애플리케이션으로 전환하는 사업이다. 이에 기존 NCD 툴을 이용해 개발한 애플리케이션 소스코드를 전자정부 프레임워크 상에서 개발 및 운영될 수 있도록 소스코드를 전환하는 툴을 개발, 애플리케이션 현대화를 수행했으며, 이를 위해 개인적으로 설정한 주요 목표는 다음과 같다.

- NCD 기반의 블랙박스 애플리케이션을 화이트박스 애플리케이션으로 소스코드 전환 및 가시화
- NCD 기반 경직적인 레거시 애플리케이션 소스코드를 효율적인 구조로 개선
- 구 기술을 사용하는 상용 프레임워크와 애플리케이션을 전자정부 프레임워크 기반의 레스트풀 애플리케이션으로 전환
- 업무 팀별 애플리케이션 패키지 구조 변경 및 형상관리
- SVN, 메이븐, 젠킨스 등을 이용한 형상관리 및 빌드 배포 자동화

먼저 As-Is NCD 기반의 애플리케이션 개발·운영 아키텍처를 살펴보면 [그림 1]과 같다.

NCD 툴을 이용해 생성한 데이터 및 컴포넌트의 로직(Flow) 정보를 이용해 더비(Derby) 내장 데이터베이스에 저장한 후, 메일 소스 생성을 통해 자바 소스코드를 생성·빌드하고 상용 프레임워크에 배포한다. As-Is 아키텍처의 주요 구성요소를 살펴보면, 다음과 같다.

① NCD 매니저: NCD기반 애플리케이션 개발 도구로써 윈도우 애플리케이션. 애플리케이션의 데이터, 서비스, 비즈니스 룰(Flow) 등을 정의하고, 내부 데이터베이스인 더비 DB에 저장
② NCD 서버: NCD 매니저의 요청을 처리하고, 더비 DB에 애플리케이션의 데이터 및 로직 정보를 저장. 매일 소스코드 생성 요청을 받아 NCD에서 작성한 애플리케이션 정보를 기반으로 자바 소스코드 생성
③ 더비 DB: 더비 데이터베이스는 JDK에 포함돼 배포되는 파일 기반의 관계형 데이터베이스로 NCD 매니저를 통해 생성한 정보를 저장하는 NCD 툴 전용 데이터베이스
④ 소스코드 생성/빌드/배포 체계: 소스코드 생성 요청을 통한 소스코드 자동 생성
⑤ 마이플랫폼(MiPlatform) UI 클라이언트: 마이플랫폼 툴을 이용해 개발한 웹클라이언트 UI
⑥ 마이플랫폼 CMD 서버: 마이플랫폼 UI 클라이언트의 요청을 처리하기 위한 액션서브릿(ActionServlet) 서버. 액션서브릿은 마이플랫폼 UI 클라이언트가 요청한 CMD 클래스를 실행해 요청/응답 처리
⑦ NCD 생성 애플리케이션 컴포넌트: NCD 기반으로 자동 생성된 애플리케이션 컴포넌트
    √PC(Procedure Component): 프로시저 컴포넌트는 비즈액터(BizActor)에서 생성한 컴포넌트 모듈들의 실행·집합체로써 CMD와 1:1 매핑되며, 타 시스템에서도 PC 호출을 통해 컴포넌트들을 재사용
    √EC(Execution Component): Q에 정의된 DB 쿼리를 실행하는 컴포넌트
    √Q(Query): 비즈액터 애플리케이션에서 사용하는 쿼리를 정의. EC 컴포넌트는 하나 이상의 Q 컴포넌트 실행을 통해 DB쿼리를 수행
⑧ DB: As-Is 데이터베이스

애플리케이션 현대화 통한 화이트박스 가시화
애플리케이션 현대화를 통한 To-Be 애플리케이션의 개발 및 운영 아키텍처를 살펴보면 [그림 2]와 같다.

NCD 툴을 이용해 자동 생성한 소스코드를 필자가 개발한 전환 툴을 이용해 전자정부 프레임워크에 맞게 전환하고, 각 업무 팀별 SVN 리포지토리에 커밋(Commit)한다. 이후 개발/빌드/배포 프로세스는 동일하며, To-Be 아키텍처의 주요 구성요소를 살펴보면 다음과 같다.

① NCD 생성 소스코드: NCD 운영계 서버에 생성된 소스코드를 가져옴
② 전자정부 프레임워크용 전환 소스코드: NCD 기반으로 생성한 PC/EC/UC/WC/xC 등 소스코드를 전자정부 프레임워크에 맞게 전환하고, while-case 구조 개선 및 데이터셋/맵 전환 등 유지보수성을 강화해 개선. Q소스코드를 전자정부 프레임워크에 맞게 MyBatis 구조의 매퍼(Mapper)로 생성
③ 애플리케이션 품질 지원 센터 전용 DB: NCD 전환 툴 기반 애플리케이션의 개발/테스트 및 품질 강화를 위한 애플리케이션 품질 지원 센터 전용 데이터베이스. To-Be 웹스퀘어 애플리케이션 실행 시 요청/응답(R/R) 전문을 수집해 데이터베이스에 적재. NCD 전환 툴로 전환한 소스코드에 대한 컴포넌트 간 콜-패스 및 사용 테이블 등 부가 정보 적재
④ SVN: To-Be 애플리케이션 소스코드 형상관리 도구로써 NCD 전환 툴로 전환한 소스코드, 개발자가 생성하거나 수정한 소스코드에 대한 형상관리. 애플리케이션 소스코드 형상관리를 위한 NESA, NESB, NESC, NESD, NESW, NESZ 등 업무별로 리포지토리 분리
⑤ 애플리케이션 품질 지원 센터: 애플리케이션 테스트 시 발생한 R/R 전문 데이터 조회 및 월별 통계 제공. NCD 전환 툴로 전환한 소스코드에 대한 조회 및 콜-패스 등 뷰 제공. NCD 전환 툴 기반 애플리케이션 테스트 R/R 레코딩 데이터 기반 재현 테스트 제공 가능
⑥ 웹스퀘어(WebSquare) UI 클라이언트: 웹스퀘어 툴을 이용해 개발한 웹 클라이언트 UI
⑦ 웹스퀘어 컨트롤러: 웹스퀘어 UI 클라이언트의 요청을 처리하기 위한 전자정부 프레임워크(Spring) 컨트롤러 서브릿. 웹스퀘어 서브릿은 웹스퀘어 UI 클라이언트가 요청한 URI에 해당하는 CMD 클래스를 실행해 R/R 처리. 웹스퀘어 컨트롤러는 웹스퀘어 UI 클라이언트가 요청한 CMD 클래스를 실행해 R/R 처리
⑧ NCD 전환 애플리케이션 컴포넌트: NCD 생성 애플리케이션 컴포넌트 소스코드를 전자정부 프레임워크에 맞게 전환한 소스코드.
    √PC: 애플리케이션을 구성하는 컴포넌트 모듈들의 실행 집합체로써 CMD와 1:1 매핑되며, 타 시스템에서도 메소드 호출 또는 웹서비스를 통한 PC 호출을 통해 컴포넌트들을 재사용
    √EC: MyBatis 매퍼에 정의된 DB쿼리를 실행하고 로직을 실행하는 컴포넌트
    √MyBatis 매퍼: Q 컴포넌트에 정의된 SQL 문을 전자정부 프레임워크에 맞게 전환한 MyBatis 매퍼 XML 파일로, EC 컴포넌트는 하나 이상의 매퍼 실행을 통해 DB 쿼리를 수행하고 전처리 및 후처리 로직을 수행함
⑨ DB: To-Be 데이터베이스

애플리케이션 현대화
애플리케이션 현대화를 통해 다음의 작업들을 수행했다.

- 단일 패키지 구조의 컴포넌트 클래스들을 업무별 패키지 구조로 개선 및 형상관리
- 웹스퀘어 컨트롤러 자동 실행을 위해 CMD 클래스에 getter 메소드 추가
- PC/EC/UC 등 컴포넌트 소스코드의 while-case, 데이터셋/맵 구조 개선을 통한 가독성 향상
- Q 컴포넌트를 매퍼 xml 파일로 전환하고, 다이내믹 쿼리 실행을 위한 전용 매퍼 제공
- NCD 툴 기반으로 생성한 소스코드의 컴파일 오류 발생에 대해 정상 소스코드로 전환
- PC 컴포넌트에 대해 로컬에서 직접 호출하도록 브릿지 유틸리티 제공
- PC 컴포넌트에 대해 HTTP를 통해 API로 호출할 수 있도록 프록시 제공
- 가시성 및 개발 생산성을 높이기 위해 웹 기반 ‘애플리케이션 품질 지원 센터’ 제공
- 애플리케이션 소스코드의 업무별 형상관리 및 빌드/배포 프로세스 개선
- 아직 데이터베이스는 통으로 유지

첫 번째, 단일 패키지 구성으로 생성된 기존 애플리케이션 소스코드에 대해 단일 패키지 구조를 업무별 패키지 구조로 개선했다. 또 기존의 NCD 기반 모놀리식 애플리케이션의 소스코드는 모든 업무가 단일 SVN 리포지토리를 이용해 형상관리 했지만, 애플리케이션 현대화를 통해 각각의 업무별 리포지토리로 분리해 형상관리 하도록 했으며, 각 팀별 패키지에 해당하는 코드(java, mapper) 파일을 해당 SVN에 커밋하고 타 업무팀의 클래스는 jar 파일 형태로 라이브러리에 제공했다.

또 기존 NCD 기반의 모놀리식 애플리케이션의 소스코드는 모든 업무가 단일 SVN 리포지토리를 이용해 형상관리했지만 애플리케이션 현대화를 통해 각각의 업무별 리포지토리로 분리해 형상관리하도록 했으며, 각 팀별 패키지에 해당하는 코드(java, mapper) 파일을 해당 SVN에 커밋하고, 타 업무팀의 클래스는 jar 파일 형태로 lib에 제공했다.

두 번째, As-Is CMD 소스코드에 To-Be 웹스퀘어 컨트롤러에서 CMD 모듈을 자동으로 실행하기 위해, 다음의 getter 메소드를 추가해 전환했다.

세 번째, 애플리케이션 현대화를 통한 PC/EC/UC 등의 컴포넌트 소스코드의 ‘while-case’ 구문을 while-case 메소드 호출 순서에 따른 메소드 코드를 재배치함으로써 가독성을 향상시켰다.

네 번째, 애플리케이션 현대화를 통한 PC/EC/UC 등에서 사용하는 데이터에 대해 데이터셋 생성을 통해 명시적으로 칼럼들을 선언하던 코드를 칼럼을 선언하지 않고 사용 시 자동으로 생성하도록 로직을 개선함으로써 개발 생산성을 향상시켰다.

다섯 번째, 애플리케이션 현대화를 통한 Q 파일 내에 선언돼 EC를 통해 쿼리 빌드 및 실행하던 데이터베이스 작업을 전자정부 프레임워크 쿼리 실행 전용 매퍼 코드로 전환, 스프링 MyBatis를 사용해 쿼리 실행 효율 및 쿼리에 대한 가독성을 향상시켰다. 아울러 기존 EC에서 쿼리를 직접 생성하고 Q 컴포넌트에 전달해 실행하던 다이내믹 쿼리를 실행하기 위한 삽입(INSERT)/선택(SELECT)/업데이트(UPDATE)/삭제(DELETE) 등과 같은 전용 매퍼를 제공, MyBatis를 사용해 쿼리 실행 효율성을 향상시켰다.

또 기존 EC에서 쿼리를 직접 생성해 Q 컴포넌트에 전달하고 실행하던 다이나믹 쿼리를 실행하기 위한 INSERT/SELECT/UPDATE/DELETE 등 다이나믹 쿼리 전용 Mapper를 제공, MyBatis 사용해 쿼리 실행 효율성을 향상시켰다.

여섯 번째, NCD 툴을 이용해 데이터 정의 및 로직을 생성하다 보니 생성된 소스코드에 대한 정상 컴파일 여부를 알 수 없으며, 개발자의 수준에 따라 다음과 같은 몇 가지 오류가 발생할 수 있다. 이러한 장애가 발생할 수 있는 오류 케이스에 대해서도 애플리케이션 현대화를 통해 개선했다. 

- 선언 변수명과 사용 변수명의 불일치: NCD 툴을 이용하여 등록한 스크립트에서 사용한 변수명이 실제 선언되지 않은 경우가 다수 발견됨
- null 클래스를 생성하는 컴포넌트 존재 : NCD 툴을 이용하여 소스 코드 내에서 PC/EC 등의 컴포넌트에서 null 클래스를 생성하여 사용하는 케이스가 다수 발견됨
√RsltNum = new DACommon(null, this.bizactorInfo).ExecuteService(refDS, “IN_GeunrojaJohoeJogeon”, “OUT_MmBhrJyDtInfo”);
√RsltNum = new DACommon(new null(), this.bizactorInfo).ExecuteService(refDS, “TMP_IN_GEUNROJA”, “TMP_GeunrojaWonbuNo”);
√RsltNum = new SACommon(new null(), this.bizactorInfo).ExecuteService(this.refDS, “TMP_Svr,saveCreditCardNapguSeunginCancelCheoriLEEC_BRSVC1408335634273_MOD0123456789MOD__IN_Jogeon_17”, “TMP_OUT_GeoraeGoyuNo”);
√RsltNum = new null(this.bizactorInfo).ExecuteService(this.refDS, “IN_BanhwanMyeongseseo”, “”);
- 자바 소스코드 생성 시 문자열 생성 오류: NCD 툴을 이용해 등록한 쿼리 및 스크립트 내에서 ‘”’ 문자를 무분별하게 사용한 경우, 실제 비즈액터 소스 생성 시 자바 소스코드 컴파일 오류가 발생

일곱 번째, 애플리케이션 현대화를 통해 생성된 애플리케이션을 PC 컴포넌트 단위로 호출해 실행할 수 있도록 다양한 브릿지 유틸리티를 제공했다. 로컬에서 비즈액터 전환 모듈을 직접 호출하기 위한 BizaTransBridge 브릿지는 다음과 같은 다양한 유틸리티 메소드를 제공한다.

- nes.biza.trans.bridge.BridgeToBizaTrans.process(String appType, String pcName, Map<String, Object> paramMap, String reqDsNames, String inDsNames, String outDsNames, String resDsNames)
- nes.biza.trans.bridge.BridgeToBizaTrans.process(String pcName, Map<String, Object> paramMap, String reqDsNames, String inDsNames, String outDsNames, String resDsNames)
- nes.biza.trans.bridge.BridgeToBizaTrans.process(String pcName, Map<String, Object> paramMap, String inDsNames, String outDsNames)
- nes.biza.trans.bridge.BridgeToBizaTrans.process(String pcName, DataSet refDS, String inDsNames, String outDsNames)

이어 HTTP 호출을 통해 API 형태로 PC 컴포넌트를 실행할 수 있도록 API 프록시를 제공한다.

여덟 번째, 애플리케이션 현대화를 통해 기존 소스코드를 분석하고 전자정부 프레임워크에 맞게 전환하면서 다음과 같이 각 컴포넌트 간의 호출 정보 및 Q 컴포넌트에서 사용하는 데이터베이스 테이블 정보를 확보할 수 있었으며, 이러한 부가 정보는 애플리케이션의 가시성을 크게 향상시켜 각 담당 업무 팀이 애플리케이션을 분리하고 장악하는데 매우 중요한 정보로 사용된다.

아홉 번째, 애플리케이션 현대화를 통해 전환한 소스코드에 대한 이해도 및 개발 생산성을 높이기 위해 웹 기반의 ‘애플리케이션 품질 지원 센터’를 제공했다.

현실적인 마이크로서비스 구축 방안
이번 글에서는 NCD 기반의 레거시 애플리케이션을 전자정부 프레임워크 맞게 애플리케이션 현대화를 수행하는 과정에 대해 살펴봤다. 4회에 걸쳐 마이크로서비스 아키텍처에 대한 글을 쓰면서 드는 생각은 지금 여러분이 갖고 있는 레거시 애플리케이션의 운영 및 유지보수 시에 직면한 문제가 있다면, 마이크로서비스로의 분리를 고민해 볼 수 있는 충분한 타이밍이라는 것이다.

먼저 레거시 애플리케이션에 대해 외부 또는 내부에 제공하고자 하는 트랜잭션을 도출해 API 게이트웨이 및 프록시를 구성하는 애플리케이션 현대화를 통해 API화하고, 이후 해당 API에 대해 마이크로서비스로 분리한다. 이때 소스코드, 형상관리, 빌드/배포 체계, 컨테이너 등을 우선 분리하고, 데이터베이스는 분리하거나 기존의 데이터베이스를 유지하는 것이 현실적이다.

마이크로서비스 담당 팀 역시 전체적으로 구성하는 것보다는 소스코드 담당자를 우선적으로 분리해 단일 팀으로 구성하고, 인프라 및 데이터베이스 담당자는 전사적으로 공유하는 것도 나쁘지 않다.

모놀리식 애플리케이션에 대해 경계 및 서비스 관리에 대한 자신감이 생기기 시작할 때, 해당 서비스들을 점진적으로 마이크로서비스로 분리할 것을 권장한다. 개발자 및 업무담당자를 중심으로 담당 팀을 구성해 애플리케이션 현대화 및 마이크로서비스로 분리하고, 인프라와 데이터베이스 분리 및 인프라/DB 담당자들의 마이크로서비스 팀 합류는 회사의 사정에 따라 진행하는 것이 우리가 선택할 수 있는 가장 현실적인 마이크로서비스 구축 방안일 것이다.