AWS Transform Custom을 활용한 ASP.NET 모노리스 애플리케이션을 마이크로서비스로 변환하기

클라우드 이전 시대에는 모노리스 아키텍처가 일반적이었습니다. 그러나 클라우드 환경이 도래한 이후 마이크로서비스가 현대적 아키텍처의 주류로 자리잡았습니다. 이러한 측면에서 레거시 애플리케이션을 클라우드 친화적인 애플리케이션으로 마이그레이션 할 경우, 확장성과 가용성 향상을 위해 마이크로서비스 전환을 고려하게 되지만, 실제 구현은 상당한 복잡도를 수반합니다.

AWS Microservice Extractor for .NET는 ASP.NET 모노리스 애플리케이션의 마이크로서비스 전환을 지원하는 UI 기반 도구였으나, 신규 사용자에 대한 지원이 종료되었습니다. 이에 대안으로 AWS Transform Custom을 사용하실 수 있습니다. 해당 서비스는 Agentic AI 기반으로 Java에서 .NET으로의 언어 변환, API/Library/SDK 버전 업그레이드, 코드 리팩토링, 그리고 아키텍처 변환을 지원합니다. 본 문서에서는 AWS Transform Custom을 활용하여 ASP.NET MVC 애플리케이션을 모노리스에서 마이크로서비스 아키텍처로 전환하는 과정을 예제로써 살펴보고자 합니다.

사전 준비사항

AWS Transform Custom은 Linux, macOS그리고, Windows Subsystem for Linux(WSL)환경을 지원합니다. 그리고, 설치는 script를 통해서 비교적 간단히 설치가 가능합니다. 단, 아래의 명령실행 전에 Node.js 20버전+과 Git 설치를 먼저 수행하십시오. 변환을 위해 사용되는 코드 베이스는 적어도 Git에 의해 관리가 되어야 합니다.

curl -fsSL https://desktop-release.transform.us-east-1.api.aws/install.sh | bash

정상 설치이후에 아래의 명령 실행을 통해서 적절한 버전 정보가 출력이 된다면 정상적으로 설치되었음을 확인할 수 있습니다.

atx --version

실제 사용을 위해서는 AWS 자격증명 인증이 필요하고, 자격증명에 대한 적절한 IAM 권한이 필요합니다. 관련해서는 Getting started 문서를 확인하십시오.

커스텀 변환을 이용한 ASP.NET MVC 모노리스 구조를 마이크로서비스로 분해하기

일반적인 커스텀 변환을 위해서는 아래와 같은 과정으로 진행이 됩니다.

1. 먼저, AWS Transform Custom을 이용하여 개발자의 의도에 따라서 Transformation Definition을 생성합니다.
2. 생성된 Transformation Definition 문서(Markdown)는 지속적인 피드백을 통해서 개선될 수 있습니다.
3. Transformation Definition은 Publish를 통해 동일한 AWS Account하에 공유가 됩니다.
4. Transformation Definition을 이용하여 원하는 소스를 대상으로 대규모 테스트 및 적용이 가능합니다.
5. 테스트 및 적용이후에 필요하면 2번 단계를 통해 지속적인 학습이 가능합니다.

이제 ASP.NET 모노리스 애플리케이션을 마이크로서비스로 변환하는 과정을 살펴보겠습니다. 현재 영어를 사용하여 AI와 대화해야 합니다.

먼저, 설치된 환경에서 atx 명령을 실행합니다. 이후에 아래와 같은 문구를 확인할 수 있습니다.

그림 1 커스텀 변환 새로 생성

커스텀 변환을 위해서 새롭게 생성하는 것이 필요합니다(그림 1). 기본적으로 제공하는 여러 변환이 존재하지만, 모노리스 구조를 마이크로서비스로 분해하는 변환은 누군가가 생성하지 않았다면 존재하지 않기 때문입니다. 저는 create a new one을 입력했지만, 요청 문구는 의도만 정확히 전달하면 좋습니다.

그림 2 개발자 의도에 의한 커스텀 변환 생성 요청

이후에 AWS가 관리하는 변환과 과거에 Publish한 커스텀 변환 리스트를 확인할 수 있습니다. 그럼에도 불구하고 Decompose … 를 입력하여 새롭게 커스텀 변환을 생성합니다(그림 2).

그림 3 커스텀 변환 생성을 위한 자료 요청

이제 Transformation Definition을 생성하기 전에 원하는 방향에 따르는 구체적인 문서나 예제 코드를 제공해달라고 요청하는 것을 볼 수 있습니다(그림 3). 만일, 로컬에 구체적인 문서를 갖고 있다면 해당 자료의 위치를 제공함으로써 Transformation Definition에 반영이 될 수 있습니다. 하지만, 나중에 언제라도 개선할 수 있으므로, 그냥 진행합니다. 그럴 경우 업계 표준적인 방법을 포함한 Transformation Definition이 생성됩니다.

그림 4 Transformation Definition 문서 생성

Transformation Definition은 Markdown형식의 문서로 작업 폴더(~/.aws/atx/custom/../artifacts/tp-staging/)에 생성이 됩니다. 해당 문서를 리뷰한 이후에 수정할 것인지 Publish할 것인지 아니면 변환이 필요한 소스코드를 제공함으로써 변환을 진행할 것인지를 결정합니다(그림 4). 변환(1번)을 선택하면 소스코드가 존재하는 로컬 위치를 제공해야 하며, 해당 소스코드는 Git에 의해서 히스토리가 관리되는 폴더여야 합니다. 해당 소스코드 위치가 확인이 되면 atx가 Transformation Definition에 맞게 변환을 진행합니다.

그림 5 변환 계획을 위한 plan.json 파일 생성

변환 과정은 먼저 Transformation Definition에 따라 코드를 분석하고 그에 맞는 적절한 plan을 계획합니다 (plan.json 파일 생성, 그림 5). 그 외에 필요한 파일들을 작업 폴더에 생성하면서 순차적으로 변환 작업을 진행합니다.

그림 6 변환 완료 후 Git 히스토리 확인

변환 작업은 일반적으로 다음과 같은 단계를 반복적으로 진행합니다.

1. json 파일로부터 진행 단계를 읽습니다.
2. 진행 단계에 따른 코드 변환을 진행합니다.
3. 검증 단계를 진행합니다.
4. 검증이 완료되면, 변경된 코드를 커밋합니다.
5. 모든 단계가 완료될 때까지 1번부터 4번을 반복합니다.

그러므로, 진행된 모든 단계는 Git 히스토리를 통해서 확인할 수 있으며, original 코드와 비교하여 변경이 이뤄진 부분을 단계별 확인이 가능합니다(그림 6).

그림 7 변환 완료

최종적으로 마무리가 되면 atx는 변환 요약을 작성하고 완료되었음을 보고합니다(그림 7). 이후에 개발자는 변환된 코드를 개발환경에서 실행 테스트 및 검증하는 단계를 진행하실 수 있습니다. 전반적으로 대부분의 변환이 완료되었고 적어도 컴파일 시 발생하는 오류를 모두 해결한 정상 빌드를 제공하기 때문에 실행 시 발생할 수 있는 일부 런타임 에러에 대해서는 kiro와 같은 코드 도우미의 도움을 받아서 빠르게 오류 패치 등, 안정화할 수 있습니다.

자동화

앞서서 설명 드린 것처럼 개발자의 의도를 가지고 새로운 커스텀 변환을 생성하여 Publish를 통해 기존의 변환 리스트에 추가할 수 있습니다. atx custom def list 명령을 실행하면, 추가된 변환 정보 역시 확인이 가능합니다(그림 8).

그림 8 커스텀 변환 리스트

AWS Transform Custom은 적절한 명령을 제공하기 때문에 생성된 커스텀 변환을 이용하여 진행 완료할 수 있습니다. 그러므로, Git 명령어와 함께 CI/CD 파이프라인의 단계에서 활용이 가능합니다. 예를 들어, 아래의 명령을 통해서 커스텀 변환이 가능합니다. atx custom def exec 명령이후에 직관적으로 소스 코드의 위치(-p)나 Transformation Name(-n)을 파라메터로 입력하여 처리합니다.

atx custom def exec -p /mnt/…/BobsUsedBooks -n Complete-ASP-NET-Microservices-Frontend-Migration -c "dotnet build" -x -t

명령에 대한 자세한 설명은 Command reference를 통해서 확인하십시오.

마무리

AWS Transform은 복잡해진 레거시 애플리케이션을 현대적인 아키텍처로 전환할 수 있도록 지원하는 서비스입니다. 다양한 언어로 작성된 기존 애플리케이션을 개발자가 선호하는 언어로 변환하고, 오래된 API와 라이브러리를 최신 기술 스택으로 자동 업그레이드함으로써 기술적 부채를 줄이고 현대화 과정을 가속화할 수 있습니다. 특히 AWS Transform Custom은 추가 비용이 발생하지만, 대규모 레거시 환경에서 기술적 부채를 보다 빠르게 해소하는 데 효과적인 선택지가 될 수 있습니다.