요약 (TL;DR)

저는 Glue 2.0, 3.0, 4.0 저장소(repositories)를 Glue 5.0에 대비할 수 있도록 준비하는 제안된 AWS Transform Custom 커뮤니티 스킬을 설계했습니다. 이 스킬은 안전한 기계적 변환(mechanical transformations)과 인간의 증거가 필요한 변경 사항을 분리하고, 마이그레이션 보고서(migration report)를 생성하며, 이미 호환되는 파일은 변경 없이 그대로 유지합니다. 제가 실시간 atx 접근 권한이 없었기 때문에, 이 포스트의 벤치마크는 에이전트가 실행한 것이 아니라 수동으로 시뮬레이션되었음을 명시적으로 표시합니다. 이 제안은 issue #75로 공개되어 있으며, 아직 병합(merged)되거나 풀 리퀘스트(pull request) 상태는 아닙니다.

누락된 데이터 엔지니어링 변환

AWS Transform Custom은 단일 저장소 전체에 대해, 또는 AWS Batch 및 Fargate를 통해 수천 개의 저장소에 대해 에이전트 주도 코드 변환(agent-driven code transformations)을 적용할 수 있습니다. 2026년 7월 30일 기준으로, 공개 샘플 저장소인 aws-samples/aws-transform-custom-samples에는 세 가지 커뮤니티 기여 변환이 포함되어 있었습니다: EKS 버전 업그레이드 준비(version-upgrade-readiness) 스킬, JBoss-to-Spring-Boot 마이그레이션, 그리고 Kubernetes 준비 마이그레이션입니다. 이 중 데이터 엔지니어링을 다루는 것은 없었습니다.

제 일상 업무의 대부분이 AWS 데이터 엔지니어링(data engineering), Databricks, 그리고 Delta Lake에 걸쳐 있다는 점을 고려할 때, 그 공백은 명백히 채워야 할 부분이었습니다.

AWS Transform Custom "스킬"의 모습

무엇인가를 작성하기 전에, 저는 가장 심도 있는 기존 사례인 jboss-to-springboot를 연구했습니다. 이 사례가 확립한 패턴은 사실상 다른 두 스킬에 대해서도 성문화되지 않은 사양(unwritten spec)이기 때문입니다:

• README.md — 문제 상황, 스킬이 수행하는 작업, 그리고 atx CLI를 통해 이를 호출하는 방법입니다. 또한 이곳에서 저장소는 명확한 선을 긋습니다. 이들은 준비(readiness) 변환(transformations)이라는 점입니다. 이들은 저장소 아티팩트(artifacts) — 코드 및 코드형 인프라(infrastructure-as-code) — 를 수정하지만, 작업을 배포하거나, 실행 중인 리소스를 변경하기 위해 AWS API를 호출하거나, 데이터 수준의 동등성을 주장하지는 않습니다. 이 구분은 아래의 모든 과정에서 중요합니다.
• SKILL.md — 에이전트 대상 정의(agent-facing definition): 트리거 키워드가 포함된 YAML 프론트매터(frontmatter), 목적(Objective), 명시적인 비목표(Non-Goals), 제약 사항(Constraints), 작업 전/후 예시, "소스 코드 내 시그널 → 참조 파일" 라우팅 테이블, 그리고 번호가 매겨진 검증 / 종료 기준(Validation / Exit Criteria) 체크리스트를 포함합니다.
• references/ — 특정 시그널이 감지될 때만 에이전트가 불러오는 심층 분석 파일들입니다.
• BENCHMARKS.md — 경영진 요약(executive summary) 테이블과 문서화된 재현 가능한 방법론입니다.

정확히 그대로 복사할 가치가 있는 두 가지 설계 선택 사항이 있었습니다. 첫째, 스킬은 무엇인가를 건드리기 전에 어떤 마이그레이션 단계가 실제로 적용되는지 감지하는 **조건부 페이즈 0(conditional Phase 0)**을 실행합니다. 둘째, 에이전트가 절대 자동 변환해서는 안 되는 항목들 — 모호한 의존성, 커스텀 커넥터, 비기계적 동작 변경 등 — 을 관리하는 **플래그 전용 카테고리(flag-only category)**를 유지하며, 대신 이를 보고서에 나타내어 사람이 결정하도록 합니다. 이 두 번째 요소가 제가 만든 그 어떤 것보다 더 중요하게 작용했습니다.

왜 특히 Glue 5.0을 대상으로 하는가

AWS Glue 5.1은 2025년 11월에 Spark 3.5.6, Python 3.11, Scala 2.12.18, Java 17을 기반으로 일반 가용(GA) 상태가 되었습니다. Glue 5.0(Spark 3.5.4, 동일한 Python/Scala/Java 버전)은 여전히 완전히 지원됩니다. 저는 이슈 #75에서 제안된 내용에 맞춰, 이 스킬의 첫 번째 버전 — 그리고 그 안의 모든 고정 요소(fixture)와 벤치마크 — 의 범위를 Glue 5.0으로 특정했습니다. 스킬의 구조는 후속 작업으로서 5.1로 깔끔하게 확장됩니다. 저는 검증되지 않은 주장을 담은 광범위한 스킬보다는, 실제로 실행한 벤치마크를 포함한 더 좁은 범위의 스킬을 출시하는 쪽을 택했습니다.

**glue-version-upgrade-readiness**는 AWS Glue ETL 작업(PySpark 및 Scala)과 해당 IaC(Infrastructure as Code)를 분석하여, 소스 버전 2.0, 3.0 또는 4.0에서 Glue 5.0으로 전환할 수 있도록 준비합니다. 각 리포지토리(Repository)별로 관련 작업만 실행되도록 Phase 0 탐지 플래그(Detection flags)로 제어되며, 다음 항목들을 다룹니다:

• Spark 2.4/3.1/3.3 → 3.5 호환성 및 현대화 패턴 — registerTempTable(Spark 2.0부터 지원 중단되었으나 삭제되지는 않았으며, 런타임 업그레이드와 함께 정리할 가치가 있음)과 같은 지원 중단된 API(Deprecated APIs), 레거시 날짜/시간 파싱 플래그, 그리고 관련 SQL 의미론(Semantics) 변경 사항
• Python 3.7/3.10 → 3.11 호환성 (의존성 버전 고정(Dependency pin) 업데이트 포함)
• Glue 전용 API 및 로깅 인자(Argument) 변경 사항
• 커넥터(Connector) 및 데이터 레이크(Data lake) 포맷 업데이트 — 최신 Glue 버전의 네이티브 Iceberg/Delta/Hudi 지원
• 새로운 런타임(Runtime)을 대상으로 하는 Terraform / CloudFormation / CDK 업데이트

또한, 의도적으로 자동화 대상에서 제외한 항목들도 있습니다: AWS Marketplace 커넥터, 컴파일된/네이티브 의존성(Compiled/native dependencies), 그리고 깔끔한 기계적 대체 수단 없이 Spark 2.x 동작에 의존하는 모든 항목입니다. 이러한 항목들은 조용히 마이그레이션되는 대신, 근거와 함께 MIGRATION_REPORT.md 파일에 작성됩니다.

실시간 액세스 없는 벤치마킹 (Benchmarking)

스킬을 검증하는 의도된 방법은 시드(Seeded)된 테스트 리포지토리를 대상으로 실제 atx CLI를 실행하는 것입니다. 제 환경에서는 AWS Transform Custom에 대한 실시간 액세스 권한이 없었기 때문에, 숫자를 조작하거나 검증을 완전히 생략하는 대신, 의도적으로 호환성 문제가 포함된 세 개의 픽스처(Fixture) 리포지토리를 준비했습니다. 구체적으로는 PySpark Glue 2.0 작업, Scala Glue 3.0 작업, 그리고 Terraform으로 관리되는 Glue 4.0 작업을 준비하였으며, 각 작업을 스킬의 단계별로 수동으로 진행한 후 Python 3.11, Terraform, cfn-lint, sbt와 같은 실제 로컬 도구를 사용하여 결과를 확인했습니다.

아래의 모든 수치는 에이전트가 실행한 것이 아니라 수동으로 시뮬레이션(Manually simulated)된 것이며, 이 라벨은 어디에서도 미화되지 않고 공개 이슈(Public issue)에 그대로 유지되었습니다:

이 수치들은 피스처 (Fixture)에 대해 해당 스킬(skill)의 규정된 단계들을 수동으로 적용한 결과를 측정한 것입니다. 이는 AWS Transform Custom의 자율 실행 정확도 (autonomous execution accuracy)를 측정한 것이 아닙니다. 저는 아직 그 데이터를 가지고 있지 않으며, 수치가 나타나는 모든 곳에서 이 점을 명시했습니다.

Scala 결과는 제가 가장 신뢰하는 결과인데, 정확히는 그것이 완벽한 통과(clean pass)가 아니기 때문입니다. 해당 피스처에는 의도적으로 미발표된 커스텀 커넥터 (custom connector)가 심어져 있습니다. 스킬은 대체제를 추측하기를 올바르게 거부하고 이를 플래그(flag) 처리했으며, sbt compile은 전체 빌드 시 실제로 실패합니다. 반면, _변환된 소스 코드 자체_는 격리된 하네스 (harness) 내에서 깔끔하게 컴파일됩니다. 만약 여기서

두 번째 사항은 유효하지 않았습니다. CDK는 해당 모듈을 실험적(experimental)인 것으로 문서화하고 버전 간의 중대한 변경 사항(breaking changes)에 대해 경고하고 있지만, 합성(synthesis)을 안정성 보장 요소로 구체적으로 명시하지는 않았습니다. 이는 제가 검증 단계로 요구하기로 결정한 사항이었으며, 처음에는 마치 AWS 자체의 가이드라인인 것처럼 작성되었습니다. 저는 스킬 파일, 참조 문서, 그리고 제안서 전반에 걸쳐 문구를 수정하여, 이 요구 사항이 이제 올바르게 귀속되도록 했습니다. 즉, 이것은 문서화된 CDK 권장 사항이 아니라 이 스킬 자체의 안전 장치(safety gate)입니다.

그 자체로는 작은 수정이지만, 이는 발행 전에 발견되거나 리뷰 과정에서 유지 관리자(maintainer)에 의해 발견되는 종류의 문제입니다. 어느 쪽이든 스스로 발견하는 것이 더 낫습니다. 이는 누군가가 반박해야 하는 주장과, 누군가가 단순히 확인할 수 있는 주장의 차이이기 때문입니다.

현재 상태

이것은 제안(proposal) 단계이며, 반영된 기여(landed contribution)가 아닙니다. 전체 스킬, 참조 문서, 그리고 세 가지 벤치마크 피스처(benchmark fixtures)는 로컬에서 빌드 및 검증되었지만, 아직 병합(merge)된 것은 없습니다. 아직 공개된 브랜치가 없기 때문에 여기에는 브랜치를 링크하지 않습니다. 저장소의 기여 가이드라인(contributing guidelines)에 따라, 중요한 작업은 풀 리퀘스트(pull request) 전에 이슈(issue)에서 논의되므로, 현재 정확히 그 단계에 있습니다: issue #75가 유지 관리자의 피드백을 위해 열려 있습니다.

만약 AWS Glue를 대규모로 운영하면서 자체적인 Glue 5.0 또는 5.1 마이그레이션 예외 사례(edge cases)를 겪으셨다면, 해당 이슈나 이곳의 댓글을 통해 알려주시기 바랍니다. 그리고 AWS Transform Custom을 처음 접하신다면, community-sourced-transformations/는 진정으로 아직 탐구되지 않은 진입로(on-ramp)입니다. 현재 존재하는 Java 및 Kubernetes 예시 외에도 기여할 수 있는 여지가 매우 많습니다.