AWS Transform custom 출시: AI 기반 코드 현대화로 기술 부채 해결 가능

기술 부채는 오늘날 엔터프라이즈 개발 팀이 겪고 있는 가장 고질적인 과제 중 하나입니다. 연구에 따르면 조직은 새로운 기능의 개발 대신 기술 부채의 해결에 IT 예산의 20%를 지출한다고 합니다. 레거시 프레임워크를 업그레이드하든, 최신 런타임 버전으로 마이그레이션하든, 오래된 코드 패턴을 리팩터링하든, 필수적이지만 반복적인 이러한 작업은 혁신에 써야 할 귀중한 개발자의 시간을 잡아먹고 있습니다.

오늘, 조직이 대규모로 현대화에 접근하는 방식을 근본적으로 변화시키는 새로운 에이전트인 AWS Transform Custom을 발표하게 되어 기쁩니다. 이 지능형 에이전트는 Java, Node.js 및 Python 업그레이드를 위해 사전 구축된 변환과 사용자 지정 변환을 정의하는 기능을 결합합니다. AWS Transform Custom을 사용하는 고객은 특정 변환 패턴을 학습시키고 전체 코드베이스에서 이를 자동화함으로써 대부분의 경우 실행 시간을 최대 80% 단축하였습니다. 덕분에 개발자는 혁신에 집중할 수 있게 되었습니다.

문서, 자연어 설명 및 코드 샘플을 사용하여 변환을 정의할 수 있습니다. 그런 다음 서비스는 이러한 특정 패턴을 수백 또는 수천 개의 리포지토리에 일관되게 적용하여 명시적 피드백과 변환 프로젝트 내에서 개발자가 직접 수정한 내용과 같은 암시적 신호를 통해 효과성을 개선합니다.

AWS Transform Custom은 다양한 현대화 요구 사항에 적합하도록 CLI와 웹 인터페이스를 모두 제공합니다. CLI를 사용하여 자연어 상호 작용을 통해 변환을 정의하고 로컬 코드베이스에서 대화형으로 또는 자율적으로 변환을 실행할 수 있습니다. 또한 이를 코드 현대화 파이프라인이나 워크플로에 통합할 수 있어 머신 기반 자동화에 이상적입니다. 한편, 웹 인터페이스는 포괄적인 캠페인 관리 기능을 제공하여 팀이 여러 리포지토리에서 대규모로 변환 진행 상황을 추적하고 조정할 수 있도록 지원합니다.

언어 및 프레임워크 현대화
AWS Transform은 추가 정보 없이도 런타임 업그레이드를 지원합니다. 필요한 구문 변경뿐만 아니라 최신 버전에서 발생하는 미묘한 동작 차이와 최적화 기회도 파악하여 적용합니다. 동일한 지능형 접근 방식이 Node.js, Python 및 Java 런타임 업그레이드에도 적용되며, 더 나아가 x86 프로세서에서 AWS Graviton으로 워크로드를 마이그레이션하는 것과 같은 인프라 수준의 전환 작업에도 적용됩니다.

또한 프레임워크 현대화를 정교하게 수행합니다. 조직에서 새로운 기능과 보안 패치를 활용하기 위해 Spring Boot 애플리케이션을 업데이트해야 하는 경우, AWS Transform Custom은 단순히 버전 번호를 업데이트하는 것이 아니라 종속성 변경, 구성 업데이트 및 API 수정의 연쇄적인 영향을 이해합니다.

Angular에서 React로 마이그레이션하는 등 급격한 변화에 직면한 팀을 위해, AWS Transform Custom은 이러한 마이그레이션을 성공으로 이끄는 구성 요소 변환, 상태 관리 전환 및 라우팅 로직 변환의 패턴을 학습할 수 있습니다.

인프라 및 엔터프라이즈 규모의 혁신
서비스가 지속적으로 개선되는 클라우드 기반 환경에서는 진화하는 API와 SDK를 따라잡아야 하는 문제가 특히 심각해집니다. AWS Transform Custom은 Java, Python, JavaScript를 비롯하여 기업에서 사용하는 광범위한 프로그래밍 언어 전반에서 AWS SDK 업데이트를 지원합니다. 이 서비스는 API 변경의 기계적 측면을 이해할 뿐만 아니라 최신 SDK 버전에서 사용할 수 있는 모범 사례와 최적화 기회도 파악합니다.

코드형 인프라 변환 역시 빼놓을 수 없는 핵심 기능이며, 특히 조직에서 다양한 도구 사용 전략을 평가할 때 중요합니다. 표준화 목적으로 AWS Cloud Development Kit(AWS CDK) 템플릿을 Terraform으로 변환하든, 새로운 서비스 기능에 액세스하기 위해 AWS CloudFormation 구성을 업데이트하든, AWS Transform Custom은 이러한 도구의 선언적 특성을 이해하고 인프라 정의의 의도와 구조를 유지할 수 있습니다.

AWS Transform Custom은 이러한 일반적인 시나리오 외에도 수년간의 개발을 통해 축적된 고유한 조직별 코드 패턴을 처리하는 데 탁월합니다. 모든 기업에는 시간이 지남에 따라 진화해야 하는 고유한 아키텍처 규칙, 유틸리티 라이브러리 및 코딩 표준이 있습니다. 이러한 사용자 지정 패턴을 학습하고 체계적으로 리팩터링하여 전체 애플리케이션 포트폴리오에 조직의 지식과 모범 사례를 일관되게 적용할 수 있습니다.

AWS Transform Custom은 엔터프라이즈 개발 워크플로를 염두에 두고 설계되었으므로, 애플리케이션 개발자가 변환된 코드를 검토하고 통합하는 데 집중하는 동안 혁신 센터 팀과 시스템 통합자는 조직 전반의 변환을 정의하고 실행할 수 있습니다. 그러면 DevOps 엔지니어는 기존의 지속적 통합 및 지속적 전달(CI/CD) 파이프라인 및 소스 제어 시스템과의 통합을 구성할 수 있습니다. 또한 AWS Lambda 함수에 특히 유용할 수 있는 Java, Node.js 및 Python 런타임 업데이트를 위해 사전 구축된 변환과 팀이 즉시 시작할 수 있도록 도와주는 AWS SDK 현대화를 위한 변환도 포함되어 있습니다.

시작하기
AWS Transform은 사전 구축된 변환 기능과 사용자 지정 변환 기능을 통해 복잡한 코드 변환을 관리할 수 있게 만들어 줍니다. 먼저 기존 변환을 사용하여 일반적인 현대화 과제, 즉 수명 종료(EOL) 런타임 지원으로 인한 AWS Lambda 함수 업그레이드를 어떻게 처리하는 살펴보겠습니다.

이 예제에서는 Python 3.8이 EOL에 도달하여 더 이상 보안 업데이트를 받지 못하는 상황에서 Python 3.8 Lambda 함수를 Python 3.13으로 마이그레이션하는 방법을 보여 드리겠습니다. 이 데모에서는 CLI를 사용하겠지만 웹 인터페이스의 강력한 캠페인 관리 기능도 살펴보는 것이 좋습니다.

먼저 atx custom def list 명령을 사용하여 사용 가능한 변환 정의를 살펴봅니다. 원하는 경우 명령을 직접 실행하는 대신 atx만 입력하여 대화형 인터페이스를 통해 이 기능에 액세스할 수도 있습니다.

이 명령은 AWS 관리형 기본 변환과 조직 내 사용자가 생성한 기존 사용자 지정 변환을 포함하여 사용 가능한 모든 변환을 표시합니다. AWS 관리형 변환은 AWS/접두사로 식별되며, 이는 AWS에서 유지 관리하고 업데이트함을 나타냅니다. 결과에서 Java 런타임 현대화를 위한 AWS//java-version-upgrade, Python AWS SDK 사용 업데이트를 위한 AWS/python-boto2-to-boto3-migration, Node.js 런타임 업데이트를 위한 AWS/nodejs-version-upgrade 등 여러 옵션을 볼 수 있습니다.

Python 3.8에서 3.13으로 마이그레이션할 때는 AWS/python-version-upgrade 변환을 사용합니다.

atx custom def exec 명령을 사용하여 마이그레이션을 실행합니다. 명령과 모든 관련 옵션에 대한 자세한 내용은 설명서를 참조하세요. 여기에서는 변환 이름을 지정하여 프로젝트 리포지토리에서 실행합니다. 또한 검증을 위한 단위 테스트를 실행하기 위해 pytest를 추가합니다. 더 중요한 것은 --configuration 입력의 AdditionalPlanContext 섹션을 사용하여 업그레이드하려는 Python 버전을 지정하는 것입니다. 참고로 데모에 사용하는 명령은 다음과 같습니다(명확성을 위해 여러 줄을 사용하고 들여 썼습니다).

atx custom def exec 
-p /mnt/c/Users/vasudeve/Documents/Work/Projects/ATX/lambda/todoapilambda 
-n AWS/python-version-upgrade
-C "pytest" 
--configuration 
    "additionalPlanContext= 업그레이드할 대상 Python 버전은 Python 3.13입니다." 
-x -t

그러면 AWS Transform이 마이그레이션 프로세스를 시작합니다. Lambda 함수 코드를 분석하고, Python 3.8 관련 패턴을 식별하고, Python 3.13 호환성에 필요한 변경 사항을 자동으로 적용합니다. 여기에는 더 이상 사용되지 않는 기능의 구문 업데이트, import 문 수정, 버전별 동작 조정이 포함됩니다.

실행 후에는 requirements.txt에서 Python 3.13 호환 패키지 버전으로 업데이트된 종속성에 대한 보고서, 더 이상 사용되지 않는 구문을 현재 버전으로 대체한 인스턴스, AWS Lambda 배포를 위해 업데이트된 런타임 구성 노트, 마이그레이션 검증을 위한 권장 테스트 사례 등을 포함한 포괄적인 요약이 제공됩니다. 또한 성공의 증거로 사용할 수 있는 일련의 증거를 제공합니다.

마이그레이션된 코드는 로컬 브랜치에 있으므로 검토하고 만족스러우면 병합할 수 있습니다. 아니면 마이그레이션이 완전히 완료되고 기대에 부합한다고 확신할 때까지 계속해서 피드백을 제공하고 반복할 수 있습니다.

이 자동화된 프로세스는 일반적으로 몇 시간의 수동 작업이 필요했던 작업을 최신 Python 런타임과의 호환성을 유지하면서 코드 품질도 유지하는 간소하고 일관된 업그레이드로 변경합니다.

새 사용자 지정 변환 만들기
AWS 관리형 변환은 일반적인 시나리오를 효과적으로 처리하지만 조직의 특정 요구 사항에 맞게 사용자 지정 변환을 생성할 수도 있습니다. AWS Transform이 특정 요구 사항을 기반으로 어떻게 학습하는지 알아보기 위해 사용자 지정 변환을 생성하는 방법을 살펴보겠습니다.

atx를 입력하여 atx cli를 초기화하고 프로세스를 시작합니다.

가장 먼저 물어보는 것은 기존 변환 중 하나를 사용할지 아니면 새 변환을 생성할지 여부입니다. 새 변환을 만들겠습니다. 여기서부터는 전체 대화가 명령이 아닌 자연어를 사용하여 진행된다는 점에 유의하세요. new one을 입력했지만 I want to create a new one이라고 입력할 수도 있습니다. 그랬어도 똑같이 이해했을 것입니다.

그러면 수행하려는 변환의 종류에 대한 추가 정보를 입력하라는 메시지가 표시됩니다. 이 데모에서는 Angular 애플리케이션을 마이그레이션할 것이므로 angular 16 to 19 application migration을 입력하면 CLI가 이러한 유형의 마이그레이션에 사용할 수 있는 모든 변환을 찾아줍니다. 제 경우에는 우리 팀이 이미 몇 가지 Angular 마이그레이션을 생성하여 사용 가능하도록 만들었기 때문에 해당 마이그레이션이 표시됩니다. 그러나 Angular 16에서 19로의 마이그레이션에 대한 구체적인 요청과 정확히 일치하는 것은 없다고 경고합니다. 그런 다음 나열된 기존 변환 중 하나를 선택할 것인지 아니면 사용자 지정 변환을 만들 것인지 묻습니다.

자연어를 계속 사용하면서 create a new one을 명령어로 입력하여 사용자 지정 변환을 만들겠습니다. 다시 말씀드리지만, 의도를 명확하게만 표시한다면 이 문을 변형해도 괜찮습니다. 이어서 변환 계획을 사용자 지정하는 데 도움이 되는 유용한 문서, 예제 코드 또는 마이그레이션 가이드가 있는지 여부를 비롯하여 저에게 몇 가지 질문을 합니다.

이 데모에서는 AWS Transform이 제공하는 기본값만 사용하겠습니다. 명령을 입력했는데 세부 정보가 없습니다. 모범 사례를 따르세요.그러면 CLI는 Angular 16을 Angular 19로 마이그레이션하기 위한 포괄적인 변환 정의를 만들 것이라고 응답합니다. 물론 저는 사전 학습된 데이터를 사용하여 모범 사례를 기반으로 결과를 생성했습니다. 늘 그렇듯이 더 나은 결과를 얻으려면 프로세스의 이 단계에서 가능한 한 많은 정보와 관련 데이터를 제공하는 것이 좋습니다. 하지만 모든 데이터를 미리 준비해 둘 필요는 없습니다. 사용자 지정 변환 정의를 만드는 과정을 반복하면서 언제든지 데이터를 계속 제공할 수 있습니다.

변환 정의는 마이그레이션 사전 준비, 처리 및 파티셔닝, 정적 종속성 분석, 특정 변환 규칙 검색 및 적용, 단계별 마이그레이션 및 반복 검증과 같은 단계로 논리적으로 그룹화된 포괄적인 구현 단계 시퀀스 및 요약을 포함하는 마크업 파일로 생성됩니다.

흥미로운 점은 AWS Transform이 16에서 19로 바로 이동하는 것이 아니라 문제를 최소화하기 위해 애플리케이션을 먼저 17에서 18로 마이그레이션한 다음 19로 마이그레이션하는 단계를 생성하는 점진적 프레임워크 업데이트를 수행하는 모범 사례를 선택했다는 점입니다.

이 계획에는 다양한 단계를 확실하게 마무리할 수 있도록 다양한 테스트 및 검증 단계가 포함되어 있다는 점에 유의하세요. 마지막 단계에서는 종료 기준이 포함된 최종 검증을 진행합니다. 이 단계에서는 애플리케이션의 모든 측면을 종합적으로 테스트하여 마이그레이션이 성공적으로 완료되었는지 확인합니다.

변환 정의가 생성되면 AWS Transform이 다음으로 무엇을 하고 싶은지 묻습니다. 변형 정의를 검토하거나 수정할 수 있으며, 만족스러운 결과를 얻을 때까지 필요한 만큼 이 프로세스를 반복할 수 있습니다. 이 변환 정의를 Angular 코드베이스에 바로 적용할 수도 있습니다. 하지만 먼저 이 변형을 저뿐만 아니라 팀원들도 사용할 수 있게 하고 싶습니다. 그래야 모두가 나중에 다시 사용할 수 있으니까요. 그래서 저는 옵션 4를 선택하여 이 변환을 레지스트리에 게시합니다.

이 사용자 지정 변환에는 사용자들이 레지스트리를 탐색할 때 표시되는 이름과 목적에 대한 설명이 필요합니다. AWS Transforms는 컨텍스트에서 자동으로 이를 추출하고 진행하기 전에 수정할지 여부를 묻습니다. “Angular-16-to-19-Migration”이라는 기본 이름이 적절하고 목적이 명확하게 명시되어 있으므로 제안을 수락하고 yes, looks good이라고 대답하여 게시합니다.

이제 변환 정의가 생성되어 게시되었으므로 이를 사용하고 모든 코드 리포지토리에서 여러 번 실행할 수 있습니다. Angular 16으로 작성된 프로젝트를 사용하여 코드 리포지토리에 변환을 적용해 보겠습니다. 이제 후속 프롬프트에서 옵션 1을 선택하면 CLI는 마이그레이션하려는 애플리케이션의 파일 시스템 경로와 필요한 경우 사용할 빌드 명령을 입력하라는 메시지를 표시합니다.

해당 정보를 제공한 후 AWS Transform은 코드베이스를 분석하고 앞서 생성한 정의를 기반으로 철저한 단계별 변환 계획을 수립합니다. 작업이 완료되면 변환 정의를 이 코드베이스에 적용하기 위해 특별히 설계된 상세한 마이그레이션 계획이 포함된 JSON 파일이 생성됩니다. 변환 정의를 만드는 프로세스와 마찬가지로 이 계획을 필요한 만큼 검토하고 반복하여 피드백을 제공하면서 구체적인 요구 사항에 맞게 조정할 수 있습니다.

계획을 수락할 준비가 되면 자연어를 사용하여 AWS Transform에 마이그레이션 프로세스를 시작할 수 있다고 알릴 수 있습니다. looks good, proceed를 입력한 다음, 계획이 실행되고 코드베이스가 한 번에 한 단계씩 변경되는 동안 쉘에서 진행 상황을 계속 지켜보세요.

소요 시간은 애플리케이션의 복잡성에 따라 달라집니다. 제 경우에는 완료하는 데 몇 분이 걸렸습니다. 완료되면, 보고된 상태를 뒷받침하는 모든 증거와 함께 계획의 최종 검증 단계에 포함된 각 종료 기준의 상태 및 변환 요약이 제공됩니다. 예를 들어 Application Build – Production 기준이 통과된 것으로 나오고 제공된 몇 가지 증거에는 증분 Git 커밋, 프로덕션 빌드를 완료하는 데 걸린 시간, 번들 크기, 빌드 출력 메시지, 생성된 모든 출력 파일에 대한 세부 정보가 포함되어 있습니다.

결론
AWS Transform은 조직이 코드 현대화와 기술 부채 문제에 접근하는 방식의 근본적인 변화를 보여줍니다. 이 서비스는 한때 팀별로 세분화되었던 작업을 지식 사일로를 제거하는 통합된 지능형 기능으로 전환하여 모범 사례와 조직의 지식을 조직 전체에서 확장 가능한 자산으로 사용할 수 있도록 합니다. 이를 통해 개발자는 반복적인 유지 관리 및 현대화 작업에 집중하는 대신 혁신과 비즈니스 가치 창출에 더 많은 시간을 할애할 수 있을 뿐만 아니라 현대화 이니셔티브를 가속화할 수 있습니다.

알아야 할 사항
이제 AWS Transform Custom을 정식 버전으로 이용할 수 있습니다. 시작 안내서 페이지로 이동하여 첫 번째 변환 캠페인을 시작하거나 설명서에서 사용자 지정 변환 정의를 설정하는 방법에 대해 자세히 알아보세요.