[AWS SUMMIT 2025] 생성형AI를 활용한 데이터베이스 마이그레이션 가속화

들어가며

생성형AI를 활용한 데이터베이스 마이그레이션 가속화

🎙️김지훈 데이터베이스 전문 솔루션즈 아키텍트, AWS

🎙️신주연 데이터베이스 전문 솔루션즈 아키텍트, AWS

🗂️ 세션 토픽: 데이터베이스

이기종 데이터베이스 마이그레이션 시 ‘스키마 변환’ 이라는 중요한 장벽에 직면하게 됩니다. 본 세션에서는 생성형 AI 기능을 탑재한 AWS DMS SC(Schema Conversion)가 어떻게 도움을 주고, 데이터베이스 마이그레이션 과정을 가속화하는 데 어떻게 기여하는지를 공유하는 시간 이었습니다.

DMS(Database Migration Service)에 Schema Conversion 기능  결합

AWS SCT 와 DMS Schema Conversion 비교

기존의 AWS SCT는 Local PC나 온프레이스의 가상환경에 설치하여 사용하다 보니 리소스의 제약을 받았음. 반면에  DMS Schema Conversion은 DMS Console에 접속하여 사용을 하니 리소스의 제약을 받지 않음. 

더불어 생성형 AI와 연계된 기능은 DMS Schema Conversion 에서만 사용 가능.

DMS Schema Conversion 스키마 평가 및 변환 기능

DMS Schema Conversion의 구성요소

• 데이터 프로바이더
  • 소스와 타겟 DB에 접속 하는 역활.
• 인스턴스 프로파일
  • 네트워크 환경이나 보안설정이 포함된 프로파일.
• 마이그레이션 프로젝트
  • Console을 확인 할수 있고, 스키마 변환에 필요한 규칙과 프로세싱을 볼수 있음.

DMS Schema Conversion 의 내부 구조

DMS Schema Conversion 안에는 Iterator라는 반복자가 있어서 소스 데이타베이스 안의 오브젝트(Table, Index, Function, Procedure, Package, view 등)를 읽어 분석을 하고 Parsing 하여 Tree 구조로 만들게 됨.

DMS Schema Conversion은 Tree 구조로 만들어진 오브젝트를 번역 하고 해석해서 타겟 데이터베이스에 적용 할 수 있게 전환 작업을 함.

생성형 AI와의 결합으로 DMS SC 기능 확장.

처음부터 AWS DMS와 AI의 결합을 염두에 뒀던 것은 아니었다고 합니다. AI를 활용해 여러 파일럿 프로젝트를 진행해 보긴 했지만, 만족할 만한 결과를 얻지는 못했던 것이죠. 그래서 DMS 개발팀 내부에서는 ‘우리가 가장 잘하는 것에 집중하자’는 공감대가 형성되었고, 결국 DMS 스키마 변환(SC) 기능과 생성형 AI의 결합을 추진하기로 결정했다고 합니다.

 시행착오 이유

• 전체스키마 변환
  • 스키마 변환의 Object의 갯수가 많을 시에는 AI를 활용하기에는 많은 토큰을 사용하게 됩니다.
    많은 토큰을 사용한다는 건 비용 증가와 많은 시간 소요. 더불어 환각 증상으로 인해 일정한 결과를 얻을 수 없었음.
• 파라미터 및 데이터 변환
  • 해당 변환은 Rule 기반 변환이므로 어느 정도 만족스러웠음.
• 사용자 의도
  • 사용자의 의도를 파악 할 수 없음.(ex. 특정 컬럼의 데이타 타입을 변경했을 시 추후에 들어 올 데이터를 알 수 없음.)
• 성능
  • Index를 추가 하거나 Subquery를 변환하는 했을 시 결과는 괜찮았지만 역시 사용자의 의도를 파악 할 수 없음.

AWS DMS SC의 생성형 AI

기존 DMS SC(스키마 변환)는 분석 대상 SQL이 사전에 정의된 규칙(Rule)과 일치할 경우에만 자동으로 코드를 변환하는 방식이었습니다.  이 때문에 해당 규칙에서 벗어나는 SQL은 사용자가 직접 수정해야 한다고 안내했습니다.

이제는 이러한 규칙(Rule) 기반 방식의 한계를 보완하여, 규칙만으로는 자동 변환이 어려웠던 부분은 생성형 AI가 분석하고 변환을 지원하는 구조로 발전했습니다.

AWS DMS SC의 생성형 AI 특징

먼저, SQL 구문의 정확한 문맥을 파악하는 데 집중합니다. 동시에 최근 AI 보안 문제가 중요한 화두로 떠오름에 따라, LLM과의 통신 과정에서 데이터 보안을 강화하는 방안도 신중하게 고려하고 있습니다.

이를 위해, 분석 대상 SQL은 LLM으로 전송하기 전에 먼저 난독화 과정을 거칩니다. 그 후 LLM으로부터 결과를 받으면, 이를 다시 역난독화하여 원래 형태로 복원합니다. 이렇게 처리된 데이터를 바탕으로 최종적인 검증 및 변환 작업을 수행하게 됩니다.

난독화 예시

생성형 AI의 성능을 높이기 위해 RAG를 통한 프롬프트 엔지니어링

생성형 AI의 신뢰도를 높이는 데 있어 가장 핵심은 사용자의 의도를 정확히 파악하는 것입니다. 

이는 여러 파일럿 프로젝트를 거치면서도 가장 큰 난관으로 여겨졌던 부분이기도 합니다. 

바로 이 중요한 사용자 의도 파악의 정확도를 높이기 위해 선택한게  RAG(Retrieval Augmented Generation) 를 통한 프로프트 엔지니어링 이었습니다.

데몬 프로젝트를 통한 DMS SC 와 생성형 AI를 결합한 DMS SC 결과 비교

Source DataBase : MS-SQL

Target DataBase : Postgresql

기존의 규칙 기반(Rule-based) 변환 방식으로는 복잡한 코드 객체의 자동 변환이 거의 불가능하여 8%의 변환율을 보였습니다. 이 경우 대부분 수동 작업이 필요합니다.

반면에 생성형 AI를 적용한 결과, 동일한 소스 데이터베이스의 코드 객체들이 85%까지 자동으로 변환되었습니다. 완벽 할 수는 없지만 수동 변환에 필요한 시간과 노력을 획기적으로 줄일 수 있음을 시사합니다.

마무리하며

이번 세션은 이기종 데이터베이스 마이그레이션 과정에서, 생성형 AI와 결합한 AWS DMS SC(스키마 변환)가 얼마나 발전된 스키마 변환 역량을 제공하는지 확인할 수 있는 의미 있는 시간이었습니다. 

이 세션을 통해 제가 내린 최종 결론은 다음과 같이 5가지로 요약할 수 있습니다.

1. 기존 규칙 기반 변환의 명확한 한계  : 전통적인 규칙 기반(Rule-based) 스키마 변환 방식이 복잡한 데이터베이스 코드 객체(저장 프로시저, 함수, 트리거 등)를 자동으로 변환하는 데 있어 명확한 한계가 있음. 이는 곧 많은 수동 작업과 시간, 그리고 전문 인력의 투입이 필요함을 의미합니다.

2. 생성형 AI(또는 신기술)의 혁신적인 잠재력 : 생성형 AI와 같은 기술이 이러한 한계를 극복할 수 있는 잠재력을 가지고 있음을 보여줍니다. 복잡한 코드의 문맥을 이해하고, 다른 데이터베이스 시스템에 맞게 재작성하는 능력이 기존 방식보다 뛰어남을 보여줍니다.

3. 데이터베이스 마이그레이션 효율성 극대화  : 자동 변환율의 향상은 데이터베이스 마이그레이션 프로젝트의 전체 기간을 단축하고, 비용을 절감하며, 개발자의 생산성을 크게 높일 수 있음을 의미합니다.

4. 마이그레이션 리스크 감소 : 수동 변환 과정에서 발생할 수 있는 인적 오류(human error)의 가능성을 줄여 마이그레이션 프로젝트의 전반적인 리스크를 낮출 수 있습니다. 자동화된 변환은 일관성을 높이고, 잠재적인 버그를 줄이는 데 기여합니다.

5. 클라우드 전환 가속화  : 이기종 데이터베이스 마이그레이션의 어려움은 기업들이 클라우드로 전환하는 데 있어 큰 걸림돌 중 하나입니다. 이러한 변환 자동화 기술의 발전은 기업들이 더 빠르고 쉽게 클라우드의 이점을 활용할 수 있도록 지원하여 클라우드 전환을 가속화할 수 있습니다.

글 │메가존클라우드, Specialty Service Unit(SSU), Data Platform Team, 강상열 매니저