통합 프로젝트 DA의 고민: 이기종 DB 데이터 이행, 어떤 도구가 정답일까? (ETL vs Airflow vs JDBC)

데이터 통합 프로젝트를 수행하며 모델링만큼이나 머리 아픈 것이 바로 '데이터 이행(Migration)'입니다. Oracle, MySQL, PostgreSQL 등 서로 다른 성격의 소스 데이터를 하나의 Mysql로 합쳐야 하는 상황에서,

특히 사내 표준 암호화 함수(Java/C)를 반드시 거쳐야 한다면 선택지는 좁아집니다.

 

비용은 아끼고 효율은 높여야 하는 상황에서 고민 중인 3가지 선택지를 정리해 보았습니다.

---

1. 전통적인 ETL 솔루션 (예: TeraStream, Apache Hop)

가장 정석적인 방법입니다. 이미 회사에 솔루션과 전담 개발자가 있다면 가장 빠르게 착수할 수 있습니다.

• 장점: 데이터 흐름(Lineage) 시각화, 대용량 처리에 최적화된 엔진, GUI 기반의 편리한 매핑.
• 단점: 상용 솔루션의 경우 라이선스 비용 발생. 오픈소스(Apache Hop 등)는 직접 환경을 구축해야 하며, 외부 암호화 함수 연동 시 별도 모듈 설정이 까다로울 수 있음.

2. 워크플로우 오케스트레이터 (예: Apache Airflow)

최근 데이터 엔지니어링의 대세입니다. 스케줄링과 흐름 제어에 특화되어 있습니다.

• 장점: 완전 무료. Python 기반이라 Java(JPype)나 C(ctypes) 암호화 함수를 호출하는 로직을 파이프라인 중간에 삽입하기 매우 유연함.
• 단점: 모든 로직을 코드로 짜야 하므로 DA가 매핑 정의서만 주는 게 아니라 코드 리뷰까지 참여해야 할 수 있음. 인프라(서버, 메타 DB) 관리가 필요함.

3. 직접 개발 (예: Spring JDBC Template, Python Script)

"우리가 직접 짠다!" 방식입니다.

• 장점: 가장 높은 자유도. JDBC Template을 쓰면 트랜잭션 처리나 배치 성능(Batch Update)을 미세하게 조정할 수 있고, 암호화 함수 호출을 비즈니스 로직 안에 바로 넣을 수 있음. 별도의 솔루션 학습 비용이 없음.
• 단점: 이행 중 발생하는 에러 핸들링, 재시도(Retry) 로직, 로깅 등을 모두 직접 구현해야 함. 이행 속도가 개발자의 쿼리/코드 숙련도에 의존함.

---

데이터 이행 도구별 상세 비교 분석표

DA 관점에서 비용, 암호화 함수 연동성, 이기종 DB 지원을 중심으로 상세하게 비교해 보았습니다.

구분	상용/오픈소스 ETL (TeraStream, Hop)	워크플로우 도구 (Airflow)	직접 개발 (JDBC Template)
비용 (Cost)	상용은 고가 / 오픈소스는 무료	무료 (Open Source)	무료 (인건비 중심)
암호화 연동	솔루션별 전용 플러그인 필요 (C/Java 연동 시 설정 까다로움)	매우 우수 (Python/Java 직접 호출)	매우 우수 (코드 내 직접 구현)
이기종 DB 지원	전용 커넥터로 안정적 지원	라이브러리 설치로 대부분 지원	JDBC 드라이버만 있으면 무한 확장
에러 핸들링	UI에서 실패 지점 확인 및 재처리 용이	DAG 단위의 Retry, 알림 설정 강력	직접 구현 필요 (공수 높음)
학습 곡선	중간 (GUI 툴 사용법 숙지 필요)	중간~높음 (Python/Airflow 구조 이해)	낮음~중간 (Java/Spring 숙련도에 의존)
DA 업무 성격	매핑 정의서 + 툴 설정 검토	매핑 정의서 + 코드(DAG) 리뷰	매핑 정의서 + 데이터 정합성 검증

---

이기종 DB 통합 시 DA의 핵심 체크리스트

• 데이터 타입 매핑 (Data Type Mapping):
  • Oracle 계열: NUMBER, VARCHAR2, DATE(시분초 포함) 타입을 MySQL의 DECIMAL, VARCHAR, DATETIME으로 정교하게 매핑해야 합니다. 특히 Tibero의 Empty String 처리 방식(NULL로 인식)과 MySQL의 차이를 명확히 정의해야 합니다.
  • PostgreSQL: Postgres의 특수 타입(JSONB, Array 등)이 있다면 MySQL에서 어떻게 풀어서 적재할지(JSON 컬럼 활용 등) 결정해야 합니다.
• 비정형 데이터의 구조화 (MongoDB → MySQL):
  • 가장 까다로운 부분입니다. MongoDB의 유연한 Document 구조를 MySQL의 고정된 Table 구조로 바꿀 때, "Normalization(정규화)"를 어디까지 할 것인지가 DA의 실력입니다.
  • 중첩된(Nested) 데이터를 별도 테이블로 뺄지, MySQL 8.0의 JSON 기능을 활용해 그대로 넣을지 전략을 세워야 합니다.

---

결론: 무엇을 선택할 것인가?

예산은 타이트하고(공짜 선호), 보안 함수 연동이 필수적인 상황이라면 다음과 같은 전략이 유효해 보입니다.

1. 개발 화력이 충분하다면: Airflow + Python 조합을 추천합니다. 이기종 DB(Tibero, PG 등) 커넥터가 풍부하고 보안 함수 연동이 가장 깔끔합니다.
2. 안정적인 트랜잭션과 익숙함이 중요하다면: JDBC Template 기반의 커스텀 배치 프로그램을 고려할 수 있습니다.

결국 도구는 수단일 뿐, 중요한 것은 이기종 DB 간의 데이터 타입 차이를 극복하는 정밀한 매핑 정의서와 암호화 후 데이터 정합성 검증 전략이 아닐까 싶습니다.