Amazon Bedrock 기반 멀티 에이전트 GAMMA로 Oracle-to-PostgreSQL 마이그레이션 가속화하기

소개

클라우드 전환을 가속화하는 조직들은 공통된 병목에 직면합니다. 바로 핵심 비즈니스를 지탱하는 레거시 시스템의 현대화(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 Analysis Agent가 협력하여 변환 문제를 체계적으로 진단하고 해결합니다.
• 검증 및 신뢰도 확인: 모든 변환 결과물은 PostgreSQL에서 컴파일 및 실행하여 정상 동작을 검증합니다. 출력 검증은 0~100 신뢰도 점수를 생성하여 Modernization SME가 신뢰도가 낮은 변환을 우선적으로 검토할 수 있게 합니다.

실전 변환: 세 가지 실제 예제

GAMMA를 보다 구체적으로 설명하기 위해, 복잡도가 점점 높아지는 세 가지 변환 사례를 소개합니다. 각 사례는 실제 고객 프로젝트에서 수행된 변환을 익명화한 것입니다. GAMMA는 단순한 구문 번역을 넘어, 각 객체의 의존성(스키마, 시퀀스, 테이블)을 해석하고 스텁을 생성하며, 자체 실행 테스트를 작성하고, 사람이 검토하기 전에 PostgreSQL에서 엔드투엔드 검증까지 수행합니다.

예제 1: 단순 — 내장 함수 치환 및 의존성 스텁 생성

매핑/감사 테이블에 사용되는 시퀀스 값을 반환하는 간단한 유틸리티 함수입니다. 변환 자체는 일대일 치환이지만, 스키마, 시퀀스, 테이블에 대한 의존성은 여전히 존재합니다.

소스: Oracle PL/SQL

CREATE OR REPLACE FUNCTION data_parameter.get_seq RETURN NUMBER IS 
BEGIN 
  RETURN postal_code_seq.NEXTVAL; 
END; 
/

출력: PostgreSQL PL/pgSQL

CREATE OR REPLACE FUNCTION data_parameter.get_seq() 
RETURNS NUMERIC 
LANGUAGE plpgsql 
AS $$ 
BEGIN 
  RETURN nextval('data_parameter.postal_code_seq'); 
END; 
$$; 

GAMMA는 지원 객체(스키마, 시퀀스, 매핑 테이블)를 스텁으로 함께 생성하고, 인라인 스모크 테스트를 만들어 객체가 독립적으로 검증될 수 있게 합니다. 검증 출력: PostgreSQL 컴파일 PASS(함수 생성, 종료 코드 0); 실행 스모크 테스트 PASS(값 반환; 테스트 INSERT + 롤백 정상).

일반적인 Oracle → PostgreSQL 매핑 (Knowledge Items)

GAMMA가 변환하는 반복적인 패턴은 모두 재사용 가능한 Knowledge Item(KI)으로 축적됩니다. 다음은 내장 매핑 라이브러리의 일부입니다.

예제 2: 중간 — OUT 파라미터, 조건부 DML, RETURNING

여러 OUT 파라미터, 두 개의 조건부 UPDATE 분기, Oracle RETURNING … INTO 절, 포괄적인 예외 핸들러를 가진 저장 프로시저입니다. PostgreSQL 11+ 프로시저 역시 OUT 파라미터를 지원하나, 결과를 얻으려면 반드시 CALL 문을 사용해야 하고 SELECT/FROM 절에서 호출할 수 없다는 제약이 있습니다. GAMMA는 변환 결과를 SELECT로 바로 조회할 수 있도록 RETURNS TABLE 함수 형태를 채택합니다. 두 UPDATE 분기, RETURNING 절, 오류 경로를 모두 유지하면서 SUBSTR은 SUBSTRING으로 매핑합니다.

소스: Oracle PL/SQL (요약)

CREATE OR REPLACE PROCEDURE account_svc.proc_balance_credit ( 
  p_account_id IN VARCHAR2, p_effective_amount IN NUMBER, p_mode IN NUMBER, 
  out_code OUT VARCHAR2, out_mess OUT VARCHAR2, out_balance OUT NUMBER, 
  out_daily_limit_used OUT NUMBER, out_monthly_limit_used OUT NUMBER) AS 
BEGIN 
  IF (p_mode = 1) THEN 
    UPDATE m_stored_value_account SET balance = balance + p_effective_amount, ... 
    WHERE account_id = p_account_id 
    RETURNING balance, daily_limit_used, monthly_limit_used 
      INTO out_balance, out_daily_limit_used, out_monthly_limit_used; 
    out_code := '00'; out_mess := 'APPROVED'; 
  ELSE 
    UPDATE m_stored_value_account SET balance = balance + p_effective_amount, ... 
    WHERE account_id = p_account_id RETURNING balance INTO out_balance; 
    out_code := '00'; out_mess := 'APPROVED'; 
  END IF; 
EXCEPTION WHEN OTHERS THEN 
  out_code := '06'; 
  out_mess := SUBSTR('Error DB Step :' || SQLERRM, 1, 100); 
END; 
/ 

출력: PostgreSQL PL/pgSQL (요약)

CREATE OR REPLACE FUNCTION account_svc.proc_balance_credit( 
  p_account_id VARCHAR, p_effective_amount NUMERIC, p_mode NUMERIC) 
RETURNS TABLE(out_code VARCHAR, out_mess VARCHAR, out_balance NUMERIC, 
  out_daily_limit_used NUMERIC, out_monthly_limit_used NUMERIC) 
LANGUAGE plpgsql AS $$ 
DECLARE v_out_code VARCHAR; v_out_mess VARCHAR; v_out_balance NUMERIC; ... 
BEGIN 
  IF (p_mode = 1) THEN 
    UPDATE m_stored_value_account SET balance = balance + p_effective_amount, ..., 
      modified_date = CURRENT_TIMESTAMP WHERE account_id = p_account_id 
    RETURNING balance, daily_limit_used, monthly_limit_used 
      INTO v_out_balance, v_out_daily_limit_used, v_out_monthly_limit_used; 
    v_out_code := '00'; v_out_mess := 'APPROVED'; 
  ELSE ... END IF; 
  RETURN QUERY SELECT v_out_code, v_out_mess, v_out_balance, 
    v_out_daily_limit_used, v_out_monthly_limit_used; 
EXCEPTION WHEN OTHERS THEN 
  v_out_code := '06'; 
  v_out_mess := SUBSTRING('Error DB Step :' || SQLERRM FROM 1 FOR 100); 
  RETURN QUERY SELECT v_out_code, v_out_mess, v_out_balance, ...; 
END; 
$$; 

핵심 인사이트: OUT 파라미터가 RETURNS TABLE로 변환됩니다. GAMMA는 모든 출력 컬럼, 두 조건 분기, 예외 경로를 유지하면서 인터페이스를 재구성합니다. 호출자 입장에서는 OUT 파라미터 바인딩 대신 반환된 행을 소비하는 방식으로 바뀝니다. 이는 동작 변경이 아니라, 기계적이고 예측 가능한 구조 조정입니다.

예제 3: 고급 — Dynamic SQL, BULK COLLECT, 프로시저 분해

동적 SQL(EXECUTE IMMEDIATE), 컬렉션으로의 BULK COLLECT, 블록별 COMMIT/ROLLBACK 기반 배치 처리, 중첩된 행별 예외 처리, 크로스 스키마 테이블 참조가 결합된 Oracle Housekeeping Procedure입니다. 이 사례는 일대일 치환만으로는 해결할 수 없는 변환입니다. GAMMA는 배치 처리와 오류 격리 동작을 유지하면서도 Oracle 전용 구문을 PostgreSQL 의 동일 구문으로 변환할 수있습니다.

GAMMA가 적용하는 구조적 적응

• EXECUTE IMMEDIATE … BULK COLLECT INTO → ARRAY(…)로 구축된 배열로의 EXECUTE … INTO.
• Oracle ROWNUM <= :vfch 제한 → LIMIT.
• TRUNC(SYSDATE – n) → DATE_TRUNC(‘day’, CURRENT_DATE – n).
• 행별 BEGIN/EXCEPTION/END → 자체 예외 핸들러를 포함하는 별도 헬퍼 함수로 추출되어, 행마다 한 번씩 호출됩니다. 이를 통해 단일 행 실패가 전체 배치를 중단하지 않습니다.

출력: PostgreSQL PL/pgSQL (핵심 루프, 요약)

CREATE OR REPLACE FUNCTION housekeeping.hk_status_cleanup_helper( 
  p_id NUMERIC, p_run_mode INTEGER, p_upd_sql TEXT) RETURNS INTEGER 
LANGUAGE plpgsql AS $$ 
BEGIN 
  IF p_run_mode = 2 THEN EXECUTE p_upd_sql USING p_id; END IF; 
  RETURN 1;   -- success 
EXCEPTION WHEN OTHERS THEN RETURN 0;   -- failure 
END; $$; 
  
-- Batched driver (abridged): 
v_sql := 'SELECT ARRAY(SELECT ' || v_key || ' FROM ' || v_tbl || 
         ' WHERE status = 7 AND modified_date < $1 LIMIT $2)'; 
EXECUTE v_sql INTO v_vti USING v_dat, v_fch; 
WHILE v_ien < COALESCE(array_length(v_vti, 1), 0) LOOP 
  ... FOR v_idx IN v_ist .. v_ien LOOP 
        v_result := housekeeping.hk_status_cleanup_helper(v_vti[v_idx], run_mode, v_upd); 
        IF v_result = 1 THEN v_ok := v_ok + 1; ELSE v_fl := v_fl + 1; END IF; 
      END LOOP; 
  COMMIT; 
END LOOP; 

이 모든 변경은 동작을 바꾸지 않는 구조적 적응입니다. 행 제한, 보존 기간, 커밋 단위가 모두 그대로 유지됩니다. 동작이 달라질 수 있는 변환의 경우, GAMMA는 자동 적용하지 않고 SME 검토를 위해 플래그를 남깁니다.

복합 효과: 포트폴리오 수준 결과

난이도 높은 패턴을 성공적으로 변환할 때마다 재사용 가능한 Knowledge Item으로 축적되므로, 정확도와 속도는 포트폴리오 전체에서 점점 개선됩니다. 500번째 객체를 변환할 때는 앞선 499개에서 학습한 모든 지식이 반영됩니다. 아래 수치는 Knowledge Item 라이브러리가 축적되면서 실제 고객 프로젝트에서 관찰된 추세를 보여줍니다(특정 포트폴리오에 대한 보장이 아닌 참고 수치).

GAMMA에 내장된 Knowledge Items는 이전 엔터프라이즈 고객 프로젝트에서 미리 축적된 것이므로, 팀은 처음부터 시작할 필요가 없습니다. 수천 개의 실제 Oracle 객체에서 학습한 패턴을 바로 활용할 수 있습니다.

벤치마크: 쿼리 변환 포트폴리오 실측

이 추세를 실제 포트폴리오에서 확인하기 위해, Oracle쿼리 대상으로 벤치마크를 수행했습니다. GAMMA와 동일한 변환 엔진의 셀프 서비스 경로인 AWS Transform Custom을 사용해, 복잡도가 서로 다른 3개 애플리케이션(매퍼 300여개)을 원본과 격리된 사본에서 변환하고, 그 결과를 실제 Amazon Aurora PostgreSQL 스키마에 연결해 재검증했습니다. (2026년 8월 단일 실행 기준 관측치이며, 특정 포트폴리오에 대한 보장이 아닌 참고 수치입니다.)

• 매퍼 전체가 1:1로 변환되고 변환 불가로 플래그된 항목은 0건 (변환 소요 시간 약 3.5시간, 총비용 약 $95).
• 비용은 코드량이 아니라 복잡도를 따라갔습니다. 계층 쿼리가 적은모듈 약 $14를 소비했고, CONNECT BY와 MERGE INTO가 밀집한 마스터 모듈은 자동 재시도가 반복되며 약 $30에 달했습니다.
• 같은 방식으로 PL/SQL 객체 25개(6,193줄)를 19분, 약 $11에 변환했습니다.
• 다만 대형 프로시저는 종종 반복 분기가 요약되어 실코드가 80% 줄어들었습니다. 역시 Human-in-the-Loop (HITL)이 필요한 부분이 있으며, 이와 같은 경우Oracle과 PostgreSQL의 실행 결과 대조와 SME 검토가 필요합니다.

아키텍처 개요

GAMMA는 다음과 같은 관리형 AWS 서비스를 기반으로 구축되었습니다.

• Amazon Bedrock: 코드 이해 및 생성을 위한 파운데이션 모델 액세스
• Amazon ECS: 컨테이너화된 에이전트 오케스트레이션
• Amazon Aurora 및 Amazon RDS: 메타데이터 및 변환 상태 관리
• AWS Step Functions: 다단계 변환 워크플로우 조정
• Amazon S3: 소스 코드, 아티팩트, 변환 출력 저장
• Amazon SQS: 비동기 작업 분배
• Amazon CloudWatch: 모니터링, 로깅, 관측성(Observability)
• 이 플랫폼은 AWS Schema Conversion Tool 및 AWS Transform과 통합되며, 이들 도구가 식별하지만 완전히 해결하지 못하는 복잡한 변환 시나리오를 처리하여 보완합니다.

고객 사례

GAMMA는 금융 서비스, 유통, 뱅킹 분야의 여러 고객 프로젝트를 통해 검증되었습니다.

Mitsubishi Electric (Building Systems Group)

Mitsubishi Electric (Building Systems Group)은 Oracle에서 PostgreSQL로 5,000개 데이터베이스를 마이그레이션하는 5년 규모의 Modernization 프로그램을 진행 중이었습니다. AWS SCT가 스키마 변환을 처리한 후, 평균 300줄의 비즈니스 로직을 포함하는 복잡한 저장 프로시저 변환에 약 200 person-months의 작업이 남아있었으며, 이는 기존 자동화 도구로는 처리할 수 없는 객체들이었습니다. GAMMA를 도입한 결과:

• 기존에 변환이 불가능했던 코드에 대해 67%의 변환 정확도 달성.
• 개별 코드 객체 기준 90% 성공률.
• 수동 변환 작업 48% 감소.
• 이 사례는 AWS Summit Tokyo에서도 발표되었으며, GAMMA가 수년 단위의 데이터베이스 Modernization을 관리 가능하고 가속화된 프로젝트로 전환할 수 있음을 보여주었습니다.

GAMMA가 기존 AWS 도구를 보완하는 방법

GAMMA는 AWS Modernization 에코시스템을 대체하는 것이 아니라 함께 작동하도록 설계되었습니다. 일반적인 프로젝트 흐름은 다음과 같습니다.

1. AWS SCT가 스키마 정의를 변환하고, 자동 변환이 불가능한 코드를 식별합니다.
2. GAMMA Assessment가 의존성을 매핑하고 복잡도가 높은 영역을 식별합니다.
3. GAMMA Execution이 복잡한 저장 프로시저와 비즈니스 로직을 변환합니다.
4. AWS Transform이 포트폴리오 규모의 애플리케이션 리플랫포밍(re-platforming)을 처리합니다.
5. Kiro가 잔여 수동 조정과 테스팅을 지원합니다.

언제 무엇을 사용할 것인가

시작하기

AWS Transform Custom으로 셀프 서비스

사내에 PostgreSQL 전문성이 있고 관리 가능한 규모의 포트폴리오(최대 수백 개 객체)를 가진 팀은 직접 변환을 실행할 수 있습니다. 먼저 Oracle-to-PostgreSQL Transformation Definition(TD)을 AWS Transform 레지스트리에 등록해야 합니다. TD가 등록되면, atx CLI로 변환을 실행합니다.

# 0. Prerequisites: Ensure your Oracle-to-PostgreSQL transformation definition (TD) is published to the registry. 
atx custom def list                          # Verify TD is available 
 
# 1. Execute the transformation on your Oracle DDL repository 
atx custom def exec \ 
  -n oracle-to-postgresql \ 
  -p ./oracle_ddl_exports/ \ 
  -g knowledge-items-path=./ki/ 
 
# 2. Review validation output (compile + execute per object); 
#    objects that fail are flagged with the specific error for SME review. 
 
# 3. Iterate: SME corrections feed back as lessons learned by the TD.
atx custom def learnings -n oracle-to-postgresql # 4. Iterate: SME corrections become new Knowledge Items; re-run to benefit.

AWS Professional Services를 통한 포트폴리오 규모

엔터프라이즈 규모 환경(수천 개 데이터베이스, 수백만 줄의 PL/SQL, 순환 크로스 스키마 의존성, 규제 추적성 요건, 라이선스 갱신 기한)에서는 AWS GenAI Innovation Center와 협력하여 AWS Professional Services를 통해 GAMMA를 제공합니다. 다음과 같은 경우 AWS Professional Services 및 AWS Partner 에코시스템을 통한 프로젝트를 고려하세요: 여러 스키마에 걸쳐 500개 이상의 복잡한 저장 프로시저가 있는 경우, 심층적인 도메인 지식이 사전 구축되어야 하는 경우, 또는 실행 전에 마이그레이션 위험을 체계적으로 평가해야 하는 경우입니다. 레거시 포트폴리오에 대한 GAMMA 평가를 시작하려면 담당 AWS 계정 팀 또는 AWS Professional Services에 문의하시기 바랍니다.

결론

레거시 Modernization이 수년간의 수동 작업 병목이 될 필요는 없습니다. GAMMA는 파운데이션 모델, 멀티 에이전트 아키텍처, 체계적 검증을 결합한 지능형 자동화가 기업의 가장 복잡한 Oracle 마이그레이션 과제를 어떻게 해결할 수 있는지 보여줍니다. 성공적인 대규모 Modernization의 핵심은 두 가지입니다. 첫째, 지능형 자동화를 통해 수동 변환 작업을 획기적으로 줄이는 것. 둘째, 프로덕션까지 명확하고 검증된 경로를 확보하는 것. GAMMA는 이 두 가지를 모두 제공하여, 조직이 대규모 Modernization에 자신 있게 착수할 수 있도록 지원합니다.