Category: Compute

원문: Rendering Digital Humans with Amazon EC2 Spot Instances — Dario Macagnano, Jyothi Madanlal, 2026년 7월 10일 (AWS Physical AI Blog) Amazon Web Services는 이 게시물에 기여해 주신 UneeQ 엔지니어링 팀에 감사드립니다 UneeQ는 실시간 고충실도(high-fidelity) 3D 렌더링을 통해 사실적인 표정을 표현하면서 자연스러운 대화를 나누는 AI 기반 디지털 휴먼(digital humans)을 만듭니다. Unreal Engine 같은 게임 엔진 […]

소개 ​​​​​​​클라우드 전환을 가속화하는 조직들은 공통된 병목에 직면합니다. 바로 핵심 비즈니스를 지탱하는 레거시 시스템의 현대화(Modernization)입니다. 기업이 Oracle에서 Amazon Aurora PostgreSQL-Compatible Edition으로 마이그레이션할 때, 테이블, 인덱스, 뷰 같은 스키마 객체는 AWS Schema Conversion Tool(SCT)과 AWS DMS Schema Conversion으로 안정적으로 변환할 수 있습니다. 실제 병목은 복잡한 비즈니스 로직이 내장된 저장 프로시저, 함수, 패키지에 있습니다. 트랜잭션 제어 패턴, Oracle 전용 내장 함수, 예외 계층 구조, 객체 간 의존성 등은 자동 변환이 어렵고, 엔터프라이즈 규모 프로그램에서는 200 person-months 이상의 전문가 작업이 필요한 경우가 많습니다.​​​​​​ ​​​​AWS SCT나 Kiro 같은 기존 도구는 다양한 마이그레이션 시나리오에 효과적입니다. 그러나 비즈니스 로직이 내장되어 있고, 크로스 스키마 의존성과 복잡한 데이터 변환이 포함된 저장 프로시저에는 여전히 상당한 수동 작업이 필요합니다. 기업에 필요한 것은 점진적인 도구 개선이 아닙니다. 기존 도구가 자동화할 수 있는 범위와 현재 수개월의 전문가 작업이 필요한 영역 사이의 격차를 메우는 체계적 접근이 필요합니다. 구체적으로는, 심층 의존성 매핑과 비즈니스 컨텍스트 이해를 바탕으로 전체 애플리케이션 포트폴리오 규모에서 작동하는 지능형 코드 자동 변환이 필요합니다.​​​ ​​​​이 글에서는 AWS GenAI Innovation Center와 AWS Professional Services가 개발한 GenAI 기반 Modernization 솔루션인 GAMMA(Generative AI for Migration and Modernization Accelerator)를 소개합니다. GAMMA는 Amazon Bedrock 기반의 지능형 멀티 에이전트 프레임워크로 복잡한 Oracle-to-PostgreSQL 코드 변환을 자동화합니다. 엔터프라이즈 Oracle Modernization 프로그램에서 평균 51%의 수동 작업 감소와 72%의 코드 변환 정확도를 달성했습니다. 이 글에서 다루는 내용은 GAMMA의 작동 방식, 복잡도별 세 가지 변환 예제, 포트폴리오 전체에서 정확도가 어떻게 축적되는지, 그리고 시작하는 방법입니다.​​​ 과제: 엔터프라이즈 규모의 복잡한 코드 변환 ​​​기업이 대규모 데이터베이스 및 애플리케이션 Modernization를 시작하면, 스키마 변환은 비교적 쉬운 부분이라는 것을 금세 깨닫게 됩니다. 진짜 어려운 부분은 수십 년간 축적된 비즈니스 로직이 담긴 수천 개의 저장 프로시저, 함수, 애플리케이션 코드 객체를 변환하는 것입니다.​​ ​​​​​​대표적인 시나리오를 살펴보겠습니다. 3,000개의 데이터베이스를 Oracle에서 PostgreSQL로 마이그레이션해야 하는 조직이 있습니다. AWS SCT 같은 도구가 스키마 정의는 효과적으로 변환하지만, 200~700줄의 복잡한 비즈니스 로직을 각각 포함하는 수백 개의 저장 프로시저는 자동 변환이 어렵습니다. 이러한 프로시저는 커스텀 데이터 타입을 참조하고, 순환 의존성이 있으며, 정확한 변환을 위해 도메인 컨텍스트에 대한 이해가 필수적입니다. 엔터프라이즈 규모에서는 수십 개 스키마에 걸쳐 수십만 건의 객체 간 의존성이 존재하고, 수십 년간 축적된 수백만 줄의 비즈니스 로직이 얽혀 있을 수 있습니다.​​​​​ ​​이러한 과제에 대한 기존의 수동 접근 방식은 다음과 같은 한계가 있습니다.​ ​​느린 속도: 복잡한 프로시저 하나하나에 전문가의 검토, 변환, 검증이 필요합니다.​ ​​고비용: 대규모 프로그램에서는 수십 명의 데이터베이스 엔지니어가 수년간 투입되어야 합니다.​ ​​오류 위험: 수동 변환은 포트폴리오 전체에서 불일치를 유발합니다.​ ​​확장 불가: 조율에 드는 부담이 커서 인력을 늘려도 일정이 비례적으로 단축되지 않습니다.​ GAMMA 작동 방식 ​​​​GAMMA는 기존 AWS 마이그레이션 도구가 완전히 자동화하지 못하는 복잡한 코드 변환을 처리하는 3단계 에이전트 기반 Modernization 플랫폼입니다.​​​ 1단계: Modernization 평가 ​​​​​​코드를 변환하기에 앞서, GAMMA는 먼저 레거시 환경을 종합적으로 파악합니다. 멀티 에이전트 시스템이 의존성 그래프를 구성하여 스키마, 프로시저, 테이블, 애플리케이션 코드 간 관계를 매핑하고, 복잡도 핫스팟과 순환 의존성, 마이그레이션 위험 영역을 식별합니다. 엔터프라이즈 환경에서는 수십 개 스키마에 걸친 수십만 개의 노드와 관계를 매핑하게 됩니다. Annotation Agent가 비즈니스 컨텍스트를 그래프에 추가하고, Discovery Q&A Agent가 다양한 위험 요소에 대한 질의 분석을 지원하여, 실행에 앞서 팀이 전체 상황을 파악할 수 있게 합니다.​​​​​ 2단계: Modernization 계획 ​​​​​의존성 그래프가 완성되면, GAMMA는 포트폴리오 전체에서 비즈니스 도메인 경계를 파악하고 복잡도가 높은 영역을 식별합니다. 플랫폼은 처리 계획을 수립하여 어떤 코드 객체를 직접 변환할 수 있는지, 어떤 것에 점진적 변환이 필요한지, 어떤 것에 아키텍처 리팩토링이 필요한지를 분류합니다. 서비스 간 경계에 대한 API 계약도 함께 생성되어, 모놀리식 레거시에서 현대적인 분산 아키텍처로 전환하는 명확한 경로를 제시합니다.​​​​ 3단계: Modernization 실행 ​​​실행 단계에서 GAMMA는 핵심 가치를 발휘합니다. 지능형 에이전트 프레임워크가 다음 메커니즘으로 코드 변환을 자동화합니다.​​ ​​전략 선택: 코드 복잡도와 의존성 분석 결과를 바탕으로 최적의 변환 방식(직접 변환, 점진적 변환, 리팩토링)을 자동 결정합니다.​ ​​LLM 기반 코드 변환: Amazon Bedrock의 파운데이션 모델로 소스 코드의 의미를 이해하고, 대상 플랫폼에 맞는 등가 코드를 생성합니다.​ ​​시맨틱 재시도 및 폴백: 첫 번째 시도에서 오류가 발생하면 전문 에이전트가 실패 원인을 분석하고 대안 전략으로 재시도합니다(최대 10회).​ ​​에이전트 기반 오류 분석: Code Analysis Agent와 Error […]

1부에서는 Amazon EKS의 GPU 노드에서 Gemma 4 31B를 vLLM으로 서빙할 때의 콜드 스타트를 다뤘습니다. 파드가 Ready가 되기까지의 시간을 428초에서 226초로 줄인 과정입니다. 스트리밍 로더로 가중치를 S3에서 직접 읽고 컴파일 캐시를 hostPath와 S3에 남기고 유휴 상태는 sleep/wake로 전환하는 구성이었습니다. 모델은 NVIDIA가 공개한 NVFP4 체크포인트 nvidia/Gemma-4-31B-IT-NVFP4입니다. 가중치 약 31GiB가 g7e.2xlarge의 96GB GPU 1개에 올라갑니다. 2부는 Ready 이후입니다. […]

Gemma 4는 Google이 공개한 오픈 웨이트 모델 패밀리로, E2B부터 31B까지 5가지 크기에 텍스트와 이미지 입력(E2B, E4B, 12B는 오디오도 지원), 최대 256K 토큰 컨텍스트(E2B, E4B는 128K), 추론(thinking) 모드를 제공합니다. 그중 31B는 밀집(dense) 구조의 최상위 모델로, NVFP4(4비트 부동소수점)로 양자화한 가중치 약 31GiB가 96GB GPU 1개에 올라가는 대신 시작할 때마다 수십 GB를 S3에서 GPU로 옮겨야 합니다. Amazon EKS에 […]

AI 시대로 전환이 가속화되면서 Amazon ECS가 다시 주목받고 있습니다. 모델 추론 서버부터 AI 에이전트와 에이전트가 호출하는 도구까지 컨테이너로 배포되는 워크로드가 증가했고, GPU 컴퓨트와 급격한 트래픽 변화를 감당하는 일들이 컨테이너 운영의 일상이 되었기 때문입니다. 하지만 ECS로 컨테이너 워크로드를 운영하다 보면 비슷한 고민과 마주치게 됩니다. EC2에서 제공되던 서비스를 Fargate로 이전할 때 시작 유형(launch type)이 변경되지 않아 어려움을 […]

이 글은 Amazon ECS 실행 구조와 선택 기준을 다루는 시리즈의 2부입니다. 1부에서는 launch type은 호환되는 실행 환경을 표시하는 용도로만 사용하고 실제 실행은 용량 공급자(capacity provider)로 구성한다는 원칙을 바탕으로, Fargate와 ECS Managed Instances, EC2에 걸친 컴퓨트 선택과 Express Mode부터 예약 Task까지의 실행 형태를 살펴봤습니다. 2부에서는 남은 선택지를 다룹니다. 6종으로 증가한 배포 전략에서 시작해 네트워크와 스토리지, 플랫폼 […]

주말 내내 트래픽이 없던 서비스에서 월요일 아침 첫 요청들만 유독 타임아웃으로 실패합니다. Karpenter가 노드를 교체한 뒤부터는 원인을 알 수 없는 연결 오류가 늘었는데, 부하 테스트를 아무리 돌려도 재현되지 않습니다. 최근 이런 증상을 겪었다면 애플리케이션 코드보다 먼저 확인할 것이 있습니다. 워크로드를 실행 중인 인스턴스 타입의 세대와 Nitro 버전입니다. 2025년 6월부터 출시되고 있는 Nitro V6 기반 인스턴스(m8i, […]

Lambda로 서버리스 워크로드를 설계하다 보면 비슷한 고민을 반복해서 만나게 됩니다. 15분 한도를 넘는 장기 워크 플로우는 어떻게 처리할지, 호출 사이에 실행 환경이 멈추는 freeze(일시 정지) 동작이 상시 트래픽 서비스에 맞는지, 사용자나 AI가 생성한 코드를 어디서 안전하게 실행할지 같은 질문입니다. 지금까지는 이 답을 Lambda 외부에서 찾는 경우가 많았습니다. 워크 플로우는 AWS Step Functions로 옮기고, 상시 워크로드는 […]

본 블로그는 LG CNS 와 AWS 가 공동 작성하였습니다. 품질보증 담당자가 QMS, LIMS, SAP, EDMS를 오가며 자료를 모으고 APQR 리포트 한 건을 완성하는 데는 약 12시간이 걸렸습니다. 종근당과 LG CNS는 Agentic AI로 이 시간을 약 1시간으로 줄였습니다. LG CNS는 AWS 프리미어 파트너로, 다수의 대규모 엔터프라이즈 고객을 대상으로 SM(운영 유지보수)/AM(현대화)/Migration 서비스를 제공하고 있습니다. 이 글은 1941년 […]

실리콘투는 한국의 뷰티 브랜드를 전 세계 고객에게 유통하는 글로벌 플랫폼 기업입니다. 수많은 브랜드와 상품, 국가별 물류가 실시간으로 맞물려 돌아가고, 이 방대한 흐름을 CMS, WMS, OMS를 비롯한 여러 사내 시스템이 나눠 맡습니다. 사업이 커질수록 업무 규칙도 함께 불어났고, 그 규칙은 저장 프로시저(SP, Stored Procedure. 데이터베이스에 넣어 두고 불러 쓰는 SQL 로직 묶음), 소스 코드, 그리고 여기저기 […]