레거시 시스템 현대화를 위한 데이터 우선 전략과 기술적 실행 패턴

많은 기업이 레거시 시스템(Legacy System)을 현대화(Modernization)하려 할 때 가장 먼저 직면하는 벽은 분석이 어려운 코드입니다. 오랫동안 쌓인 스파게티 코드와 비즈니스 로직 그리고 파편화된 많은 줄의 코드들은 역공학(Reverse Engineering)을 어렵게 만듭니다.

대부분 현대화 프로젝트들은 코드를 먼저 분석하고 이를 이해하고 접근하는 방식을 취하지만, 이는 실패하거나 막대한 비용이 발생할 수 있습니다. 본 글은 레거시 시스템 현대화의 기술적 복잡성을 해결하려는 아키텍트와 개발 리더들을 위한 가이드라인을 담고 있습니다.

레거시의 진실은?

레거시 시스템은 사용되지 않는 코드와 비즈니스 로직처럼 보이지만 실제 다른 동작을 하는 코드 그리고 로직과는 무관한 주석이 존재할 수 있습니다. 그러나 데이터베이스(Database)에는 실제로 저장된 값이 담겨 있고 이는 비즈니스의 결과를 볼 수 있는 Fact입니다.

여기서 제가 언급하고자 하는 부분은 “데이터 출처 접근 방식” 입니다. 데이터 출처 접근 방식은 레거시 시스템의 DB 스키마를 데이터를 담는 그릇보다는 시스템 현대화를 위한 지도(Map)으로 바라봅니다. 코드를 읽어 내려가는 대신, 데이터베이스에 흐르는 데이터의 패턴, 제약 조건 그리고 In/Out을 분석하여 현대화할 대상과 범위를 정의합니다.

실행 전략

1단계로 데이터 모델링을 하여 현대화를 위한 영토 지도를 만들어야 합니다. 즉, 새로운 코드를 작성하기 전에 현 시스템의 논리적 모델을 분석해야 합니다. 아래의 작업들이 필요합니다.

• 물리 스키마의 논리화: 실 데이터베이스 테이블 간의 관계를 역공학하여 논리 모델을 구축
• 제약 조건 추출: 레거시 데이터베이스는 FK(Foreign Key)가 설정되지 않은 경우가 많습니다. 즉, 애플리케이션 로직 속에 숨겨진 데이터 간의 연관 관계를 찾아내서 명시해야 합니다.
• 불필요한 데이터 식별: UI이나 보고서에 나타나지 않는 컬럼과 테이블은 현대화 대상에서 과감하게 제외합니다.
• 미래 상태 모델링: 새로운 비즈니스 요구사항을 기반으로 마찰 지점을 파악합니다.

위 작업이 완료되면, 2단계로 데이터 프로파일링을 해야 합니다. 개발/인터페이스/UI 문서에는 특정 필드가 “필수”라고 명시되었지만, 실 데이터는 “옵션”일 수 있습니다. 시스템의 실제 사용 필드를 파악하기 위해 프로파일링을 수행해야 합니다.

1. 통계 분석: 각 열에 대해 null 비율, 카디널리티를 계산합니다.
2. 단일 항목 분석: DEFAULT 값 분포를 확인해야 합니다. 해당 열에 DEFAULT 값이 있는 경우가 99.9% 이상이면 이 데이터는 사용되지 않을 가능성이 높습니다.
3. 상관 분석: 종속성을 감지 해야 합니다. A열의 값에 종속되는 B열의 값을 봐야 합니다.
4. 문제 추출: 비즈니스에 의미가 없는 데이터를 지정해야 합니다.

3단계에서는 기존 시스템의 일관성 없는 명명 규칙이 없는 찾아봐야 합니다. 예를 들어서 고객 아이디를 cust_id, customer_id, c_id 등으로 지정했을 수 있습니다. 이런 것들을 조사해야 합니다.

1. 항목 추출: 기존 스키마에서 모든 열 이름을 추출합니다.
2. 단어 그룹화: 주소, 고객 등의 의미를 가지고 있는 이름들을 그룹화 합니다.
3. 사전 생성: 표준 용어를 정의합니다. (저는 개인적으로는 영어사전에 있는 full name을 선호합니다.)
4. 표준 정의: 모든 데이터 요소에 대한 표준을 정의합니다.
5. 코드 값 정의: 플래그 값들이 존재하면 표준화 합니다.
6. 매핑: 기존 열의 이름을 새 표준에 맞게 매핑합니다.
7. 통합: 매핑된 정보를 기준으로 새 표준에 맞게 변경합니다.

그 다음 4단계로 동기화 브릿지를 구축합니다. 레거시 시스템과 현대화 시스템이 공존하는 기간 동안 데이터 일관성을 유지해야 하기 때문입니다.

• CDC(Change Data Capture) 활용: 레거시 코드를 수정하지 않고도 데이터를 새 시스템으로 실시간 복제합니다.
• 이벤트 기반 아키텍처: 데이터 변경을 이벤트로 발행하여 새로운 서비스들이 이를 소비하게 하고 이를 통해 각 서비스간 결합도를 낮춥니다.

5단계로 점진적 전환을 해야 합니다. “빅뱅” 방식의 전환은 항상 위험이 도사리고 있습니다. 특정 데이터 영역(고객 정보, 주문 정보 등)을 먼저 분리하여 새 시스템으로 옮기고, 레거시 시스템의 해당 기능을 점진적으로 비활성화합니다.

핵심 기술 패턴

CDC (Change Data Capture)

레거시 코드는 손대기 매우 위험합니다. CDC는 데이터베이스 엔진의 트랜잭션 로그를 직접 읽어 들여 소스 코드 수정 없이도 데이터 흐름을 추적할 수 있게 합니다. 이는 레거시를 현대화된 “이벤트 소스”로 변환하는 방법입니다.

트랜잭셔널 아웃박스 패턴 (Transactional Outbox Pattern)

데이터 우선 접근 방식에서 데이터 일관성을 보장하기 위해 사용됩니다. 로컬 트랜잭션내에서 비즈니스 데이터 업데이트와 이벤트 메시지 저장을 수행함으로써, 시스템 장애 시에도 데이터 유실이나 중복 처리를 방지합니다.

부패 방지 계층 (Anti Corruption Layer)

레거시 데이터 모델이 현대화 시스템의 도메인 모델을 오염시키지 않도록 중간에서 변환 역할을 수행하는 계층입니다. 이를 통해 현대화 시스템은 레거시 데이터 구조에 종속되지 않고 현대적인 설계를 유지할 수 있습니다.

리스크 관리와 성공을 위한 Tip

현대화 프로젝트의 70%는 기술적 난이도보다 데이터 무결성 문제로 어려움을 겪습니다. “데이터 우선” 전략이 성공하기 위해서는 아래의 사항을 기억해야 합니다.

• 성능 저하 모니터링: CDC나 실시간 동기화가 레거시 데이터베이스의 성능에 미치는 영향을 철저히 테스트해야 합니다.
• 조직적 협업: 데이터베이스 관리자나 비즈니스 분석가 개발자가 초기 모델링 단계부터 긴밀히 협력해야 합니다.
• 완벽주의 포기: 모든 레거시 데이터를 가져갈 필요는 없습니다. 현재 비즈니스 가치가 있는 데이터에 집중해야 합니다.

끝으로, 현대화는 단순히 과거 기술 스택을 현대 기술 스택으로 넘어가는 것만이 아니라, 불필요한 것들을 정리할 수 있는 기회이기도 합니다. 코드부터 살펴보면 시스템 작동 방식의 복잡함에 기겁할 수 있습니다. 그러나 데이터부터 살펴보면 시스템이 실제로 무엇을 하는지 이해할 수 있습니다. 현대화 계획이 있다면 먼저 운영 데이터베이스를 프로파일링하세요.

Read More

애플리케이션 현대화로 가는 길

 

오래된 기술

어느 회사나 오래된 기술로 만들어진 시스템을 가지고 있을 것이다. 이것과 관련해서 흔히들 “잘 작동하면 만지지 마세요.”라고 얘기한다. 변경 사항이 없을 경우에는 맞는 말이다. 잘 동작되고 있는데 굳이 변경할 필요는 없기 때문이다. 하지만, 문제가 발생하거나 변경을 해야 할 경우에는 어떻게 해야 할까? 오래된 기술을 알고 있는 사람을 고용하기는 매우 어려울 것이다. 10~20년전에 이 코드를 작성한 사람들은 아마 은퇴를 했을 것이고, 젊은 개발자들은 이 기술을 배우고 싶어하지 않을 것이다. 억지로 하라고 하면 이탈로 이어질 것이고, 좋은 개발자는 그 조직에 있지 않게 될 것이다.

새로운 기술 채택 및 비즈니스 상황 대응

새로운 기술과 패턴들은 놀라운 속도로 등장하고 있다. 과거에 존재했던 것들보다 현대에는 관련 기술이 풍부하고 더 최적화되어 있는 것들이 많다. 이런 기술들을 적용하는 것은 디지털 세계에서 생존하는데 매우 중요하지만, 레거시 시스템으로 운용하는 기업은 경쟁의 속도를 따라 갈 수 없다. 비즈니스를 지원하는데 많은 비용과 시간이 소요되기에 필요 시점에 고객이 원하는 기능을 제공할 수 없기 때문이다.

애플리케이션은 언제 구식이 되는가?

빌게이츠는 “성공한 기업은 다른 기업보다 먼저 자신의 제품을 구식으로 만든 기업이다.”라는 말을 했다. 이 분야에서 일하면서 매년 새롭게 기술이 탄생하는 것을 지켜보게된다. 하지만, 새로운 기술이 나왔다고 바로 적용하진 않는다. 일반적으로 10-15년 정도가 애플리케이션의 수명이라고 생각한다. 시스템을 “구식”이라고 정의할 수 있는 기준은 무엇일까?

1. 도입한 솔루션이 있을 경우, 벤더사의 지원을 더이상 받을 수 없을때에 해당된다.
2. 새로운 비즈니스 요구사항을 반영하기 어려운 상황이 발생한 경우에 해당된다. (억지로 반영하다가는 부채만 쌓이게 된다.)
3. 현재는 사용되지 않는 하드웨어 혹은 특정 상황에서만 작동되는 경우에 해당된다.

어떻게 현대화를 해야 할까?

애플리케이션을 현대화하기 위해서는 다음 사항이 고려되야 한다.

• 현대화를 해서 어떤 결과를 얻고자 하는가?
• 어떤 자원을 가지고 있는가?
• 직접 코드를 수정하거나 제어할 수 있는가?
• 변경되거나 새롭게 만들어야 하는 항목에 대해 위험 평가를 수행해야 한다.

현대화에 대한 비용 옵션은 어떤 것들이 있을까?

1. 다음 세대로 미루고 아무것도 하지 않음
   • 가장 쉬운 방법이다. 현대화를 통해 비즈니스 가치를 찾지 못한다면 올바른 선택이 될 수 있다.
   • 어떤 시스템을 현대화하려고 하는데, 연관된 시스템들이 많아서 전부 건들 수 없는 경우에도 해당된다. 모두 완료되어야 현대화가 되기 때문에 불가한 상황이라고 판단
2. 재호스팅 또는 리프트 앤 시프트
   • 클라우드로 아무 수정없이 옮기는 방법이다.
3. 재구축
   • 재호스팅을 하면서 코드를 약간 변경하는 방식이다. 예를 들어서 데이터베이스, 검색 기능등은 클라우드 리소스를 활용한다.
4. 애플리케이션 프론트엔드 현대화
   • 백엔드에서 제공하는 API를 이용해 프론트엔드만 현대화하는 방식이다.
   • UX는 시대에 따라 자주 변하기에 레거시 애플리케이션의 일반적인 문제 중 하나를 제거할 수 있다.
   • 단, API가 잘 만들어져 있어야 한다.
5. 리팩토링
   • 간혹 애플리케이션이 현재 상황에 맞게 구축되지 않았거나 진화가 안되었을 경우에 해당된다.
   • 비즈니스 로직은 변화하지 않으며, 코드가 새롭게 작성되는 방식이다.
6. 완전 재구축
   • 이 경우, 레거시 시스템을 완전 새로운 애플리케이션으로 대체한다.
   • “빅뱅”으로 재구축하기에 철저한 분석, 설계, 테스트 및 데이터 마이그레이션 전략이 필요하다.
   • 또한, 이전 애플리케이션으로 롤백하는 전략이 필요하다.

끝으로

현대화를 하기 위해서는 위험도, 예산, 시간, 리소스, 애플리케이션 종속성과 같은 제약 조건을 고려해야 한다. 가장 좋은 방법은 기존 애플리케이션을 분석하고 평가하여 TO-BE 방향성을 식별하는 것이다. 각 옵션에 대해 비용 및 위험 대비 효과와 같은 ROI를 추정해야 한다. 백데이터가 있어야 현대화 진행에 대한 의사결정을 할 수 있을 것이다.

Read More