AWS Transform 45억 줄 처리, Codex·Claude로 들어온 현대화 에이전트

AWS가 2026년 5월 14일 AWS Transform agents를 Kiro, Claude Code, Cursor, Codex에서 접근할 수 있게 했다고 발표했습니다. 경로는 세 가지입니다. Kiro power, agent plugins, AWS Transform MCP server입니다. 하루 뒤 AWS Transform 1주년 글은 12개월 동안 45억 줄 이상 코드 처리, 수십만 VM migration, 160만 시간 이상 절감이라는 수치를 공개했습니다. 이 두 발표를 함께 보면 AWS의 메시지는 단순합니다. 현대화 에이전트를 AWS console 안의 별도 서비스가 아니라 개발자가 이미 쓰는 agentic IDE와 CLI 표면으로 옮기겠다는 것입니다.

이 글은 또 하나의 AWS migration 제품 소개가 아닙니다. devlery는 최근 SageMaker OpenAI-compatible API, AgentCore Optimization, AWS Nova Act Service Card처럼 AWS의 agent 인프라를 여러 차례 다뤘습니다. 이번 사건에서 새로 볼 부분은 Transform이 기업 legacy code와 infrastructure modernization을 Codex, Claude Code, Cursor 같은 코딩 에이전트 표면으로 밀어 넣었다는 점입니다. agent가 새 기능을 만드는 단계에서 기존 시스템을 뜯어고치는 단계로 내려왔습니다.

AWS Transform은 처음부터 enterprise modernization을 겨냥했습니다. AWS 1주년 글에 따르면 출발 use case는 VMware infrastructure migration, IBM z/OS COBOL application modernization, .NET upgrades였습니다. re:Invent 2025에는 custom transforms가 추가돼 code, language, API, framework upgrade를 조직 단위로 다루는 방향으로 넓어졌습니다. 2026년 5월 업데이트는 이 작업을 web console 중심에서 IDE, CLI, MCP로 확장합니다. 개발자는 agentic IDE에서 transformation을 시작하고, web console에서 진행 상황을 확인하고, 다시 IDE에서 결과를 볼 수 있습니다.

AWS가 제시한 수치는 공격적입니다. Transform은 12개월 동안 45억 줄 이상을 처리했고, 수십만 VM을 migration했으며, 고객의 manual effort를 160만 시간 이상 줄였다고 설명합니다. 250,000-line mainframe application의 full transformation and testing을 6주에 끝낸 사례도 제시했습니다. infrastructure team은 수천 서버 migration planning을 몇 주가 아니라 몇 시간 단위로 줄였고, assessment는 평균 compute 35%, licensing 45% 절감을 찾아냈다고 AWS는 말합니다. 이 수치는 독립 benchmark가 아니라 AWS가 공개한 customer and service metric입니다. 그래도 이 정도 규모를 공개했다는 사실은 enterprise modernization이 agent 제품의 다음 판매 지점으로 올라왔다는 근거가 됩니다.

기술적으로 바뀐 지점은 job state입니다. AWS What's New 문서는 같은 underlying job 위에서 IDE, web console, MCP integration이 상태를 공유한다고 설명합니다. 기존 migration tool은 대개 console에서 assessment를 만들고, export 파일을 받고, 별도 ticket과 repository 작업으로 나뉘었습니다. Transform agents가 IDE로 들어오면 개발자는 codebase 안에서 modernization job을 시작하고, architect나 program manager는 console에서 승인과 추적을 할 수 있습니다. agent가 만든 diff만 보는 것이 아니라, transformation job 자체가 협업 단위가 됩니다.

AWS의 GitHub awslabs/agent-plugins 저장소도 같은 방향을 보강합니다. README는 Agent Plugins for AWS가 Claude Code, Codex, Cursor를 지원한다고 설명하고, plugin은 agent skills, MCP servers, hooks, references를 묶을 수 있다고 적습니다. aws-transform plugin 설명은 .NET to .NET 8/10, mainframe COBOL to Java, VMware to EC2, SQL Server to Aurora, language/SDK upgrades를 포함합니다. 이 목록은 "AWS 문서를 agent에게 알려준다"보다 훨씬 넓습니다. 레거시 앱 변환, DB 전환, VM migration, 언어 업그레이드가 coding assistant의 capability catalog로 들어갑니다.

Kiro는 이 발표의 배경으로 같이 봐야 합니다. AWS는 2026년 4월 30일 Amazon Q Developer IDE plugins와 paid subscriptions가 2027년 4월 30일 end-of-support에 들어간다고 공지했습니다. 새 Q Developer signup은 2026년 5월 15일부터 막히고, 2026년 5월 29일부터 Q Developer Pro에서 Opus 4.6이 빠집니다. 최신 coding models는 Kiro에 우선 배치된다고 AWS는 설명했습니다. 즉 AWS 개발자 도구의 방향은 Q Developer plugin을 유지하는 것이 아니라, spec-driven Kiro와 Transform agents, agent plugins, MCP를 한 축으로 재배치하는 쪽입니다.

이 재배치에서 spec-driven development는 마케팅 문구가 아니라 control surface입니다. AWS Q Developer end-of-support 글은 Kiro가 structured specifications를 바탕으로 plan, implement, verify를 수행한다고 설명합니다. Specs, Hooks, Steering files, Custom subagents, Powers가 핵심 구성요소입니다. Transform agents가 Kiro power로 들어오면, 레거시 현대화 작업은 "이 파일을 고쳐줘"가 아니라 요구사항, 설계 결정, task list, validation 조건을 가진 job으로 바뀝니다. 특히 COBOL, PL/I, .NET Framework, SQL Server migration처럼 감사와 승인 근거가 필요한 업무에서는 이 차이가 큽니다.

AWS가 1주년 글에서 제시한 mainframe 경로는 agent 작업의 성격을 잘 보여줍니다. Transform은 code, runtime behavior, business rules, data lineage를 분석해 execution graph를 만들고, 원래 legacy code의 business rule과 변환된 code를 연결한다고 설명합니다. PL/I 지원도 추가됐습니다. AWS는 Transform이 PL/I business logic을 syntax-independent specification으로 추출하고, Kiro가 그다음 interactive forward engineering을 맡는다고 설명합니다. agent가 코드를 바로 생성하는 것이 아니라, legacy intent를 specification으로 바꾼 뒤 cloud-native pattern으로 옮기는 단계가 생깁니다.

Windows modernization도 단순한 .NET upgrade에서 벗어났습니다. AWS는 ASP.NET web forms to Blazor UI modernization과 SQL Server to Aurora PostgreSQL migration을 언급했습니다. schema, stored procedure, application data-access code를 함께 변환하는 database modernization beta도 같은 문단에 들어갔습니다. 검증은 syntax validation, semantic equivalence, synthetic data 기반 functional verification 세 층으로 설명됩니다. 여기서 개발팀이 봐야 할 부분은 모델 이름이 아닙니다. 변환이 어떤 evidence를 남기는지, semantic equivalence가 어떤 test corpus로 확인되는지, synthetic data가 실제 edge case를 얼마나 대변하는지가 도입 판단의 중심입니다.

code modernization 쪽 목록은 더 직접적입니다. AWS는 Vue.js, Scala/Glue, Spring Boot, Log4j to SLF4J, Angular to React, Angular to Flutter upgrade를 out-of-the-box transforms로 제시했습니다. Progress 4GL to Java, PHP replatforming, ColdFusion to React/Java, DataDog to CloudWatch Monitors, JBoss to Spring Boot도 같은 목록에 있습니다. 이 목록은 기업 개발팀의 backlog와 닮았습니다. 보안팀은 Log4j와 end-of-life dependency를 보고, platform team은 runtime upgrade를 보고, 비용팀은 DataDog to CloudWatch 같은 monitoring migration을 봅니다. agent가 새 기능 생산성 도구에서 technical debt portfolio tool로 이동하는 장면입니다.

개발자에게 바로 생기는 변화는 작업 시작점입니다. 지금까지 agentic coding tool은 repository 내부 변경에는 강했지만, migration program의 권한, source inventory, target account, approvals, partner delivery와 연결되면 힘이 약해졌습니다. AWS Transform은 Transform environment, workspace, transformation job을 AWS credential과 IAM role로 묶습니다. 개발자가 Codex나 Claude Code에서 aws-transform plugin을 호출할 때, 실제 변환 작업은 AWS 계정과 job record에 연결됩니다. 이 구조가 잘 작동하면 diff는 agent conversation이 아니라 enterprise job의 산출물이 됩니다.

반대로 위험도 커집니다. AWS GitHub README는 generative AI가 실수할 수 있으며 output과 cost를 검토해야 한다고 적습니다. best practices에는 generated code review, plugin을 judgment 대체가 아닌 accelerator로 쓰기, plugin update, least privilege, generated infrastructure code security scanning이 들어갑니다. 이 항목들은 보수적인 문구가 아니라 필수 운영 조건입니다. Transform agents가 VMware, mainframe, database, IAM-authenticated workspace에 접근한다면, "agent에게 맡겼다"는 표현은 충분하지 않습니다. 누가 승인했고, 어떤 role로 실행됐고, 어떤 artifact가 S3에 남았고, 실패 시 어디까지 되돌릴 수 있는지가 기록돼야 합니다.

AWS Agent Plugins README의 "What's new"도 주목할 만합니다. README는 Agent Toolkit for AWS가 live 상태이며, AWS Labs의 MCP servers, plugins, skills의 successor라고 설명합니다. 여기에는 agent action과 human action을 구분하는 IAM condition keys, CloudWatch와 CloudTrail visibility, accuracy and effectiveness 평가를 거친 skills가 포함된다고 적혀 있습니다. 이 문장은 AWS가 plugin 생태계를 hobby extension이 아니라 production governance 표면으로 옮기려 한다는 뜻입니다. agent가 AWS API를 부를 때, 사람의 API call과 agent의 API call을 구분하는 것부터 운영이 시작됩니다.

커뮤니티 반응은 아직 AWS Transform 자체보다 Kiro와 AWS 개발자 도구의 신뢰성에 집중돼 있습니다. Hacker News의 Kiro 토론에서는 Kiro가 VS Code plugin이 아니라 별도 IDE로 간 이유, Q Developer CLI의 가격 대비 가치, AWS가 developer tool을 얼마나 오래 유지할지에 대한 의문이 나왔습니다. Q Developer end-of-support 공지는 이런 의문을 더 키울 수 있습니다. AWS는 12개월 transition window와 기존 고객 접근 유지, console과 Slack/Teams 같은 first-party Q Developer surface는 계속 제공된다고 선을 그었습니다. 그래도 새 표면으로 이전하는 개발팀은 "Kiro와 Transform plugin이 몇 년짜리 약속인가"를 물을 수밖에 없습니다.

경쟁 구도도 흥미롭습니다. GitHub Copilot app은 issue에서 branch, validation, PR까지 이어지는 개발 workflow를 GitHub 안에 묶습니다. Claude Code는 dynamic workflows와 subagent 병렬 실행을 앞세웁니다. OpenAI Codex는 local CLI와 cloud session, ChatGPT surface를 넓히고 있습니다. Cursor와 Windsurf 계열은 IDE 안에서 빠른 코드 변경과 review loop를 장악하려 합니다. AWS Transform은 이들과 정면으로 "코딩 assistant" 경쟁만 하지 않습니다. 대신 다른 agentic IDE 안에 들어가 enterprise modernization specialist로 작동합니다. 이는 AWS가 잘하는 domain, 즉 계정, IAM, migration history, cloud target architecture를 agent tool로 포장하는 방식입니다.

이 전략은 Amazon Q Developer sunset과도 연결됩니다. Q Developer IDE plugin은 여러 IDE 안에서 AWS assistant로 작동했습니다. Kiro는 별도 agentic IDE이고, Transform agents는 Claude Code, Codex, Cursor까지 들어갑니다. AWS는 "모든 개발자가 AWS IDE를 써야 한다"보다 "AWS의 modernization expertise가 어떤 agent surface에서도 호출돼야 한다"는 쪽으로 움직이는 듯합니다. 이 해석이 맞다면 AWS의 실제 경쟁력은 chat UI가 아니라 transformation catalog, IAM-aware job orchestration, cloud migration evidence, partner delivery workflow가 됩니다.

도입을 검토하는 팀은 세 가지 질문부터 잡아야 합니다. 첫째, agent에게 맡길 modernization scope를 작게 정의해야 합니다. 예를 들어 Log4j to SLF4J, Node.js runtime upgrade, 한 서비스의 .NET upgrade처럼 rollback 가능한 범위가 좋습니다. 둘째, Transform job의 artifact 위치와 접근권한을 정해야 합니다. S3 connector, IAM role, workspace permission, source repository permission이 audit 대상입니다. 셋째, agent 결과를 어떤 자동 검증으로 막을지 정해야 합니다. unit test, integration test, semantic equivalence, synthetic data, security scan 중 어떤 gate가 merge 전 필수인지 분명해야 합니다.

이 발표를 과장해서 읽으면 "레거시 현대화가 자동으로 끝난다"가 됩니다. AWS 자료는 그렇게 단순하지 않습니다. 1주년 글도 architect가 transformation plan을 조정하고, DBAs가 assessment를 검토하고 승인하며, human-in-the-loop interaction이 여러 surface로 확장된다고 설명합니다. 실제 제품 방향은 무인 자동화보다 collaborative enterprise foundation에 가깝습니다. agent가 discovery, planning, transformation, testing을 연결하지만, 승인과 검토는 사람과 조직 프로세스에 남습니다.

개발자에게 중요한 변화는 agent의 작업 대상이 새 코드에서 낡은 코드로 확장된다는 점입니다. AI coding tool은 그동안 greenfield prototype, feature implementation, unit test generation에서 성과를 설명했습니다. AWS Transform은 20년 된 payroll, claims, mainframe, .NET Framework, SQL Server, VMware inventory를 agent workflow에 올리겠다고 말합니다. 이 영역은 실패 비용이 높고, 요구사항이 문서보다 code와 runtime behavior에 숨어 있습니다. 그래서 Transform의 경쟁력은 "잘 생성한다"보다 "잘 추적하고 검증한다"에 달립니다.

AWS Transform agents의 IDE 진입은 enterprise AI agent 시장에서 조용하지만 큰 이동입니다. Codex나 Claude Code 안에서 AWS Transform을 부를 수 있다는 것은, agentic IDE가 범용 편집기를 넘어 vendor-specific domain agents를 호출하는 orchestration surface가 된다는 뜻입니다. 45억 줄 처리 수치는 AWS가 이 시장에 규모의 언어를 붙인 첫 신호입니다. 다음 검증 지점은 더 구체적입니다. 실제 팀이 aws-transform plugin으로 만든 migration job이 비용, 권한, test evidence, rollback까지 한 흐름으로 남는지입니다. 그 답이 나오면 agentic coding의 평가 기준은 "얼마나 빨리 코드를 썼나"에서 "얼마나 안전하게 낡은 시스템을 바꿨나"로 넓어집니다.