기존 Rails 애플리케이션으로 레거시 데이터베이스 마이그레이션

Migrating a legacy database into an existing Rails app

작성자
발행일
2025년 08월 26일

핵심 요약

  • 1 레거시 데이터베이스를 기존 Rails 앱으로 통합하는 ETL(추출, 변환, 로드) 프로세스를 ActiveRecord와 Rake 태스크를 활용하여 구현하는 방법을 설명합니다.
  • 2 외부 Gem 의존성 없이, 별도 어댑터 파일과 고유 교환 키(legacy_id, email)를 사용하여 효율적인 데이터 동기화 및 마이그레이션을 수행합니다.
  • 3 `find_each`를 활용한 행별 마이그레이션 방식과 태스크 순서의 중요성을 강조하며, 대규모 테이블 처리 시 고려사항을 제시합니다.

도입

이 글은 레거시 데이터베이스의 데이터를 기존 Rails 애플리케이션으로 마이그레이션하는 실용적인 접근 방식을 다룹니다. 애플리케이션 재작성 또는 기업 인수와 같은 상황에서 발생하는 데이터 이관 문제를 해결하기 위해, 일반적으로 ETL(Extract, Transform, Load) 파이프라인이 사용됩니다. 상용 도구나 Kiba와 같은 전문 Gem도 있지만, 이 글에서는 Rails에 내장된 ActiveRecord와 Rake 태스크만을 활용하여 불필요한 의존성을 피하고 비용 효율적인 일회성 마이그레이션 솔루션을 제시합니다.

레거시 데이터 마이그레이션은 기존 Rails 애플리케이션에 외부 데이터를 통합하는 과정입니다. 이 과정은 단순히 데이터베이스 행을 복사하는 것을 넘어 데이터 변환 및 추가 처리(예: 파일 다운로드)를 포함할 수 있습니다.

어댑터 파일 정의

레거시 데이터베이스 연결을 위해 /lib 디렉터리에 별도의 어댑터 파일을 생성합니다. 이 파일에는 ActiveRecord::Base를 상속받는 부모 클래스(OldBlog)를 정의하고, self.abstract_class = trueestablish_connection을 사용하여 레거시 데이터베이스에 연결합니다. * readonly? 메서드를 오버라이드하여 모든 모델을 읽기 전용으로 설정합니다. * 레거시 테이블(예: articles, users)에 해당하는 모델을 정의하고, 필요한 경우 사용자 지정 연관 관계(associations) 및 인스턴스 메서드를 추가하여 데이터 접근 편의성을 높입니다. (예: OldBlog::Article, OldBlog::User)

고유 교환 키 활용

시스템 간 데이터 동기화를 위해 각 행에 대한 고유한 교환 키가 필수적입니다. 이는 마이그레이션을 주기적으로 재실행할 때 기존 레코드를 식별하거나 새로운 레코드를 생성하는 데 사용됩니다. * 새로운 Rails 앱의 테이블(예: posts)에 legacy_id 컬럼을 추가하고 인덱스를 생성합니다. * 저자(authors)와 같은 다른 엔티티의 경우 이메일 주소와 같이 기존에 고유한 필드를 교환 키로 활용할 수 있습니다. * 이 교환 키는 마이그레이션 완료 후 제거할 수 있습니다.

Rake 태스크 구현

데이터 추출, 변환, 로드(ETL) 프로세스는 Rake 태스크를 통해 행별(row-by-row)로 구현됩니다. find_each를 사용하여 메모리 문제를 방지합니다. * namespace :etl 내에 usersarticles와 같은 개별 태스크를 정의합니다. * 사용자 마이그레이션: OldSystem::User를 순회하며 Author.where(email: old_user.email).first_or_initialize를 사용하여 기존 저자를 찾거나 새로 생성합니다. 속성을 매핑하고 save(validate: false)로 저장합니다. * 게시물 마이그레이션: OldSystem::Article을 순회하며 Post.where(legacy_id: old_article.id).first_or_initialize를 사용합니다. 제목, 생성일 등을 매핑하고 post.author = old_article.user와 같이 연관 관계를 설정한 후 저장합니다. * 태스크 실행 순서(예: 사용자 먼저, 게시물 나중)는 내부 종속성을 고려하여 중요하게 설정해야 합니다. * ProgressBar를 사용하여 진행 상황을 시각적으로 표시할 수 있습니다.

결론

이 예시는 단순하지만, 마이그레이션해야 할 데이터베이스 테이블 수에 따라 확장 가능하며, 여러 클라이언트 프로젝트에서 성공적으로 적용된 검증된 방식입니다. 내부 종속성(예: 게시물 마이그레이션 전 사용자 마이그레이션)을 주의 깊게 관리해야 합니다. 행별 접근 방식은 매우 큰 테이블에는 시간이 오래 걸릴 수 있으므로, 이러한 경우 CSV 내보내기/가져오기와 같은 대안을 고려할 수 있습니다. 궁극적으로 이 간단한 단계들을 통해 많은 레거시 데이터 마이그레이션 작업을 효과적으로 수행할 수 있습니다.

댓글 0

댓글 작성

0/1000
정중하고 건설적인 댓글을 작성해 주세요.

아직 댓글이 없습니다

첫 번째 댓글을 작성해보세요!