"데이터만 잘 옮기면 되는 것 아닌가요?"

이기종 마이그레이션 프로젝트를 수행할 때 가장 많이 듣는 질문 중 하나입니다. 실제로 많은 분들이 마이그레이션을 단순히 A 데이터베이스에서 B 데이터베이스로 데이터를 복사하는 작업 정도로 생각하십니다. 하지만 지난 몇 년간 수많은 이기종 마이그레이션 프로젝트를 수행하면서 깨달은 진실은 이와 완전히 달랐습니다.

단순 이관은 기술이지만, 메타데이터 변환은 전략이다

프로젝트 초기, 한 금융회사의 마이그레이션을 진행했던 경험이 있습니다. 데이터 이관 자체는 순조롭게 진행되었습니다. 수 TB 데이터가 문제없이 새로운 이기종 데이터베이스로 옮겨졌고, 데이터 건수도 완벽하게 일치했습니다. 프로젝트팀은 성공을 확신했습니다.

하지만 애플리케이션을 새 데이터베이스에 연결하는 순간, 문제가 시작되었습니다. 일부 화면에서 한글이 깨져서 표시되었고, 숫자가 이상하게 나타났으며, 날짜 계산이 맞지 않았습니다. 특정 조회 기능은 아예 동작하지 않았고, 데이터 입력 시 예상치 못한 에러가 발생했습니다. 데이터는 분명 모두 이관되었는데 왜 이런 문제가 발생한 걸까요?

원인은 바로 메타데이터 변환에 있었습니다. 한글 깨짐은 캐릭터셋(Character Set)을 제대로 변환하지 않아서였고, 정렬이 맞지 않는 문제는 Collation 설정이 문제였고, 숫자 오류는 데이터 타입 변환이 잘못되었기 때문이었으며, 입력 에러는 Check 제약조건과 Default 값이 누락되어 발생한 것이었습니다.

메타데이터는 데이터베이스의 설계도입니다. 건물을 짓기 전에 정확한 설계도가 필요하듯이, 데이터베이스도 메타데이터라는 설계도에 따라 작동합니다. 많은 분들이 메타데이터를 단순히 테이블과 컬럼 정보 정도로 생각하시는데, 실제로는 훨씬 더 광범위하고 복잡한 정보를 포함합니다. 즉, 정교하지 못한 메타데이터 변환은 시스템 전체의 기능 마비를 야기할 수 있습니다.

메타데이터 네 가지 관점에서 이해하면 훨씬 명확해진다

메타데이터는 단순히 테이블과 컬럼의 정의가 아닙니다. 데이터가 어떻게 저장되고, 어떻게 흐르고, 누구에게 열려 있고, 어떤 로직이 그 안에서 작동하는지를 정의하는 네 축의 설계 시스템입니다.

먼저 데이터가 어떤 형태로 저장되는가의 문제가 있습니다. 타입, 캐릭터셋, 저장 구조 같은 기초 설정이 여기 해당합니다. 이 축이 어긋나면 데이터가 담긴 것처럼 보이지만 의미가 달라져 있습니다. 그 위에는 데이터가 어떤 규칙을 따라 흘러야 하는지를 정하는 축이 있습니다. 제약조건, 기본값, 시퀀스가 이 역할을 하며, 이 규칙들이 옮겨지지 않으면 이관 후에 설명하기 어려운 데이터가 하나둘 쌓입니다. 세 번째는 데이터가 얼마나 빠르게 누구에게 열려 있는가입니다. 인덱스와 권한이 이 축을 결정하며, 사용자가 가장 먼저 체감하는 영역이기도 합니다. 마지막으로 데이터베이스 안에는 프로시저, 패키지, 트리거 같은 보이지 않는 로직이 함께 존재합니다. 이 로직이 제대로 옮겨지지 않으면 익숙했던 기능 하나가 어느 날 사라진 것처럼 느껴집니다.

위의 내용을 표로 정리하면 다음과 같습니다

이 네 축 중 어느 하나라도 놓치면, 이관이 끝난 후 운영 중에 문제가 드러납니다. 그리고 문제는 에러 메시지가 아니라 사용자의 민원이나 설명하기 어려운 데이터의 형태로 나타나기 때문에, 발견 시점에 원인을 메타데이터로 연결하기 어려운 경우가 많습니다.

메타데이터 변환은 시작이자 끝

프로젝트 시작 단계에서 메타데이터 변환 전략을 수립합니다. 현재 데이터베이스의 메타데이터를 분석하고, 각 컬럼의 실제 사용 패턴을 파악하며, Check 제약조건의 비즈니스 규칙을 이해하고, Default 값의 의미를 파악하며, 사용자와 스키마 구조를 재설계합니다. 이 단계에서의 결정이 프로젝트 전체의 방향을 좌우합니다.

개발 단계에서는 변환된 메타데이터를 기반으로 데이터 이관 스크립트를 작성하고, SQL을 수정하며, 애플리케이션 코드를 조정합니다. 메타데이터가 잘못 정의되어 있으면 이 모든 작업을 다시 해야 합니다. 특히 Check 제약조건이나 Default 값이 빠져 있으면 테스트 단계에서 예상치 못한 에러가 대량으로 발생합니다.

테스트 단계에서는 변환된 메타데이터에서 데이터가 정확하게 저장되고 조회되는지 검증합니다. Check 제약조건이 올바르게 작동하는지, Default 값이 제대로 입력되는지, 권한이 정확하게 설정되었는지 확인합니다. 성능 테스트, 기능 테스트, 통합 테스트 모두 메타데이터를 기반으로 수행됩니다.

운영 단계에 접어들어서도 메타데이터는 중요합니다. 시스템 확장, 성능 튜닝, 장애 대응 등 모든 작업이 메타데이터와 관련되어 있습니다. 새로운 사용자를 추가하거나, 테이블 구조를 변경하거나, 권한을 조정할 때마다 메타데이터 설계의 영향을 받습니다.

결국 메타데이터 변환을 제대로 하지 않으면, 프로젝트의 모든 단계에서 문제가 발생합니다. 반대로 메타데이터 변환을 철저히 준비하면, 나머지 작업은 상대적으로 순조롭게 진행됩니다.

성공적인 프로젝트의 비결

최근 진행한 한 금융권 마이그레이션 프로젝트는 비교적 안정적으로 마무리되었습니다. 200개가 넘는 테이블과 수천 개의 컬럼, 그리고 수백 개의 제약조건을 서로 다른 데이터베이스 환경으로 이관하는 작업이었지만, 오픈 이후 큰 문제 없이 시스템을 운영할 수 있었습니다.

이 프로젝트의 비결은 의외로 단순했습니다. 프로젝트 초기 약 두 달의 시간을 메타데이터 분석과 변환 전략 수립에 집중적으로 투자한 것입니다.

각 테이블이 실제로 어떤 용도로 사용되고 있는지부터 다시 정리했고, 컬럼별로 실제 데이터 분포를 분석하여 새로운 시스템에 가장 적합한 데이터 타입을 선정했습니다. 단순히 정의서를 옮기는 것이 아니라, 데이터가 어떻게 사용되고 있는지를 기준으로 메타데이터를 다시 설계했습니다.

모든 Check 제약조건을 하나하나 정리하여 문서화하고, To-Be 시스템에 맞는 문법으로 재작성했습니다. Default 값 역시 단순히 복사하지 않고, 각 값이 어떤 의미를 가지는지 확인한 뒤 정확하게 변환했습니다. 기존 시스템에서 Schema와 User가 분리되어 있던 구조는 통합하여 스키마를 재구성했고, 사용자 권한 체계도 새 환경에 맞게 전면적으로 재설계했습니다.

물론 이 과정은 시간과 노력이 많이 드는 작업이었습니다. 하지만 그 결과, 이후 개발과 테스트 단계에서 발생할 수 있는 시행착오를 크게 줄일 수 있었습니다. 메타데이터가 탄탄하게 설계되어 있었기 때문에 데이터 이관은 비교적 순조롭게 진행되었고, 애플리케이션 수정 역시 최소한으로 끝낼 수 있었습니다.

무엇보다도 운영 이후 데이터 무결성과 관련된 문제는 거의 발생하지 않았습니다. Check 제약조건과 Default 값이 의도대로 정확히 변환되어 있었기 때문입니다. 데이터는 이전과 동일했지만, 시스템은 훨씬 안정적으로 동작하고 있었습니다.

그래서 메타데이터 변환은 전략이다

메타데이터 변환의 중요성을 이해했다면, 이제 자연스럽게 이런 질문이 따라옵니다. 그러면 메타데이터 변환은 어떻게 접근해야 할까요?

메타데이터 변환에서 반드시 짚고 가야 할 한 가지가 있습니다. 메타데이터 변환은 단순한 기술 작업이 아니라, 비즈니스를 이해하는 작업이라는 점입니다. 데이터 타입을 바꾸는 일 자체가 중요한 것이 아니라, 그 데이터가 실제로 어떻게 사용되고 있으며 어떤 의미를 가지는지를 이해하는 것이 핵심입니다.

예를 들어 고객의 나이를 저장하는 NUMBER(3) 컬럼에 CHECK (age BETWEEN 0 AND 120) 제약조건이 있다면, 이것은 단순한 숫자 범위 제한이 아니라 "이 시스템이 허용하는 고객의 정의"를 담고 있는 비즈니스 규칙입니다. 마찬가지로 주문 상태를 저장하는 VARCHAR2(20) 컬럼에 CHECK (status IN ('PENDING', 'APPROVED', 'REJECTED')) 제약조건이 있다면, 이는 단순한 문자열 검증이 아니라 시스템이 어떤 흐름과 단계를 가지는지를 보여주는 워크플로우의 표현입니다. 또한 created_date 컬럼에 설정된 DEFAULT SYSDATE 역시 단순히 현재 시간을 자동으로 입력하는 기능이 아니라, "이 데이터가 언제 생성되었는지를 시스템 차원에서 기록한다"는 감사(Audit) 정책을 담고 있습니다.

이처럼 메타데이터는 겉으로 보기에는 기술적인 정의처럼 보이지만, 그 안에는 시스템의 규칙과 의도, 그리고 비즈니스의 맥락이 함께 녹아 있습니다. 그리고 바로 이 지점에서, 데이터베이스 기술과 비즈니스 이해가 만납니다.

마이그레이션 프로젝트의 성패는 이 교차 지점을 얼마나 정확하게 이해하고 옮겼는지에 따라 갈립니다. 데이터는 옮길 수 있습니다. 하지만 의미까지 함께 옮길 수 있을지는, 준비에 달려 있습니다.

이 글을 시작으로, Character Set 변환, 문자형 데이터, 숫자형 데이터, 날짜형 데이터가 이기종 데이터베이스 환경에서 어떻게 달라지고, 어떤 점을 반드시 주의해야 하는지 하나씩 살펴보려 합니다. 첫 번째 글에서는 모든 변환의 첫 관문인 캐릭터셋(Character Set) 부터 살펴봅니다.