> ## Documentation Index
> Fetch the complete documentation index at: https://www.integrate.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# ETL: ELT(FlyData)와 ETL(Xplenty)를 결합한 순환형 데이터 통합 아키텍처
> FlyData(ELT)로 데이터를 수집하고 Xplenty(ETL)로 가공 데이터를 다시 운영 DB에 반영하는 순환형 데이터 파이프라인 구성 방법을 설명합니다.
## FlyData 소개
Integrate.io의 데이터 전송 서비스는 사실 두 가지로 구성되어 있습니다. 지금까지 주로 다뤄온 것은 ETL 서비스인 **Xplenty**이지만, 이 외에 ELT 서비스인 **FlyData**도 함께 제공됩니다.
본문에 들어가기 전에 FlyData를 간단히 소개합니다. FlyData는 주로 **MySQL 등의 데이터베이스에서 Amazon Redshift와 같은 데이터 웨어하우스로 데이터를 실시간에 가깝게 동기화**하는 데 특화된 클라우드 기반 데이터 통합 서비스입니다. CDC(Change Data Capture) 기술을 활용해 데이터베이스의 변경 사항을 거의 실시간으로 DWH에 반영할 수 있는 것이 특징입니다.
### 주요 특징
* **실시간 CDC 복제**: 데이터베이스의 변경 사항을 즉시 캡처
* **간단한 설정**: 비교적 적은 설정만으로 복제를 시작 가능
* **데이터 웨어하우스에 특화**: 데이터 웨어하우스로의 동기화에 최적화된 설계
| 관점 | 장점 | 단점 |
| ------- | ------------------------------------ | -------------------------------------------- |
| 데이터 동기화 | 실시간에 가까운 데이터 동기화 가능 | 지원 대상이 한정적: 주요 데이터 웨어하우스, 일부 데이터베이스, 파일에만 대응 |
| 기능성 | 데이터 웨어하우스에 특화되어 있어 해당 유스케이스에서는 높은 효율 | ELT 특성상 변환 기능은 없음: 데이터 변환 기능이 없고 이상값 감지만 가능 |
| 아키텍처 | 가벼운 에이전트 기반 아키텍처 | - |
FlyData에 대해서는 이 정도로 살펴보았습니다.
## 개요
현대의 데이터 환경에서는 단순히 데이터를 수집하는 것만으로는 부족하며, 수집한 데이터를 분석·가공한 뒤 다시 운영 시스템에 반영하는 **순환형(Circular) 데이터 흐름**이 중요해지고 있습니다.
이 문서에서는 다음 두 가지 도구를 조합해 이러한 순환 구조를 구현하는 방법을 소개합니다.
| 방향 | 도구 | 역할 |
| ------------ | ------------ | ------------------------------ |
| 수집(Inbound) | FlyData(ELT) | 각 DB → DWH(Snowflake)로의 데이터 수집 |
| 배포(Outbound) | Xplenty(ETL) | DWH → 각 DB로의 가공 데이터 역송신 |
이 두 도구를 조합하면 **데이터 수집 → 중앙 집중 분석 → 결과 역배포**로 이어지는 하나의 완결된 데이터 순환 파이프라인을 구축할 수 있습니다.
## 아키텍처 설명
아래는 순환형 데이터 통합 아키텍처의 구성이며, 이어서 그 흐름을 설명합니다.
각 컴포넌트의 역할은 다음 표와 같습니다.
| 컴포넌트명 | 역할 | 도구명 |
| --------------- | -------------------------------------- | ----------------------------------------------------------------- |
| 소스(레거시 서비스) | 일상적인 업무 데이터의 축적 | MySQL, PostgreSQL, Oracle 등의 데이터베이스, SaaS의 REST API, 사내용 REST API |
| ELT 도구 | 변경이 발생한 데이터를 신속하게 DWH로 적재 | FlyData |
| 데이터 웨어하우스 | 데이터 통합·저장 및 SQL 기반 조정·연산 처리 | Snowflake, BigQuery, Redshift 등 |
| ETL 도구 | 가공 데이터의 변환, 각 대상 DB로의 라우팅, 조정 데이터의 역배포 | Xplenty |
| 데스티네이션(레거시 서비스) | 조정 데이터 반영, 분석 데이터 축적 | MySQL, PostgreSQL, Oracle 등의 데이터베이스, SaaS의 REST API, 사내용 REST API |
## 각 단계의 역할
순환형 데이터 통합 아키텍처의 각 단계를 살펴보겠습니다.
* **단계 1: ELT — FlyData를 통한 데이터 수집**
* CDC(Change Data Capture) 방식으로 각 운영 DB의 변경 내용을 **실시간 또는 준실시간**으로 Snowflake에 연계
* 데이터 변환 없이 원본(Raw) 데이터를 먼저 DWH에 저장(ELT의 핵심)
* 여러 이종 데이터베이스를 하나의 DWH로 통합
* **단계 2: 분석·연산 — Snowflake 내에서의 처리**
* 수집한 원본 데이터를 바탕으로 SQL View, Stored Procedure, dbt 등을 활용해 \*\*조정 데이터(Reconciled Data)\*\*를 생성
* 예: 재고 조정값, 정산 금액, 집계된 사용자 점수 등
* **단계 3: ETL — Xplenty를 통한 데이터 역배포**
* Xplenty의 비주얼 파이프라인으로 Snowflake의 가공 데이터를 읽어옴
* 필요한 변환(필드 매핑, 타입 변환, 필터링) 적용 후
* 각 운영 DB에 **Merge(Upsert)**, **Append**, **Truncate & Insert** 등의 방식으로 역송신
## 사례: EC 플랫폼의 재고·정산 데이터 동기화
### 사례 배경
* 여러 리전(일본, 미국, 한국)에 개별 운영 DB를 보유한 EC 서비스
* 각 리전의 결제 데이터를 중앙에서 집계해 **글로벌 결제 조정값**을 계산
* 계산된 조정값을 각 리전의 DB에 반영해야 하는 요건이 존재
### 단계 1: FlyData로 각 리전 DB → Snowflake로 수집
* \[일본 MySQL] → (CDC) → Snowflake: `raw.jp_payments`
* \[미국 PostgreSQL] → (CDC) → Snowflake: `raw.us_payments`
* \[한국 MySQL] → (CDC) → Snowflake: `raw.kr_payments`
Snowflake에서의 데이터 통합과, FlyData 상에서의 데이터 파이프라인 설정이 여기에 해당합니다.
### 단계 2: Snowflake에서 글로벌 결제 조정값 계산
```sql theme={null}
-- 예: 전체 결제 평균을 기준으로 리전별 조정 금액을 계산
CREATE OR REPLACE VIEW analytics.adjusted_payments AS
SELECT
payment_id,
'JP' AS region,
jp.amount - (global_avg.avg_amount * 0.3) AS adjusted_amount
...
...;
-- 미국, 한국에도 동일한 로직을 적용
```
### 단계 3: Xplenty로 조정 데이터 → 각 리전 DB로 역배포
Xplenty 파이프라인 구성 예시:
```
[Snowflake Source]
analytics.adjusted_payments
↓
[Filter 컴포넌트]
region = 'JP' 로 필터링
↓
[Select 컴포넌트]
payment_id, adjusted_qty 필드 매핑·타입 변환
↓
[Database Destination: JP MySQL]
테이블: payment_adjustment
모드: Merge(Upsert) by payment_id
```
* **JP MySQL**, **US PostgreSQL**, **KR MySQL** 각각에 개별 Xplenty 파이프라인을 구성하거나, 단일 파이프라인 내에서 분기 처리
* Xplenty 스케줄러에서 Snowflake의 계산이 완료된 후 자동 실행되도록 설정(의존 관계 체이닝)
## 장점과 단점
### 장점
| 장점 | 설명 |
| ------------------------------------ | ---------------------------------------------------------------------------- |
| 관심사의 명확한 분리 | \*\*데이터 수집(FlyData)과 데이터 배포(Xplenty)\*\*의 역할이 명확히 나뉘어 있어 각 도구의 강점을 최대한 활용 가능 |
| 단일 진실 공급원(Single Source of Truth) 확보 | Snowflake를 중앙 DWH로 활용함으로써 모든 리전·서비스의 데이터가 한곳에서 관리되고 일관된 기준으로 계산됨 |
| 코드 없는 파이프라인 관리 | Xplenty의 드래그 앤 드롭 방식 비주얼 파이프라인으로 복잡한 ETL 로직도 비개발자가 이해·수정 가능 |
| 확장성 | 새로운 리전 DB나 서비스 DB가 추가되어도 FlyData 연결과 Xplenty 파이프라인만 각각 추가하면 손쉽게 확장 가능 |
| 실시간성 확보(ELT 구간) | FlyData의 CDC 방식은 배치 방식 대비 지연을 최소화해 Snowflake의 데이터를 최신 상태로 유지 |
| 운영 DB 부하 최소화 | 분석·연산 처리가 모두 Snowflake에서 이루어지므로 운영 DB에 무거운 집계 쿼리가 직접 실행되지 않음 |
### 단점
| 단점 | 설명 |
| --------------------- | -------------------------------------------------------------------------------------- |
| 역배포(Write-back) 지연 발생 | 파이프라인 전체의 지연이 누적되므로, 실시간성이 요구되는 결제·재고 할당 등의 트랜잭션 처리에는 적합하지 않음 |
| 데이터 루프(Loop) 위험 | 역배포된 데이터가 다시 FlyData의 CDC에 의해 수집되어 Snowflake로 재유입될 수 있으며, 이를 방지하는 필터링 메커니즘을 별도로 구현해야 함 |
| 도구 간 운영 복잡성 증가 | FlyData, Snowflake, Xplenty 세 시스템을 동시에 운영해야 하므로 모니터링·장애 대응·비용 관리가 복잡해짐 |
| 두 플랫폼 분의 비용 부담 | ELT 도구(FlyData)와 ETL 도구(Xplenty) 각각의 라이선스·이용 비용이 발생하고, Snowflake의 컴퓨팅 비용도 추가됨 |
| 스키마 불일치 위험 | 소스 DB → Snowflake → 대상 DB 사이에서 컬럼명, 데이터 타입, NULL 처리 방식이 다를 경우 매핑 오류가 발생할 수 있음 |
## 주의 사항
1. **데이터 루프 방지(가장 중요)**
* 역배포 데이터에는 출처를 식별할 수 있는 메타 컬럼(`source_system`, `is_adjusted`, `updated_by` 등)을 반드시 추가하십시오.
* FlyData의 CDC 필터 설정 또는 Snowflake의 View 로직에서, 역배포 데이터를 재수집 대상에서 제외하는 처리를 반드시 구현하십시오.
2. **멱등성(Idempotency) 보장**
* Xplenty의 역배포 파이프라인이 중복 실행되더라도 데이터가 이중으로 삽입되지 않도록, 반드시 Merge(Upsert) 모드와 명확한 기본 키(PK)를 설정하십시오.
3. **실행 순서·의존 관계 관리**
* Snowflake의 연산(View 갱신, `dbt run` 등)이 완료된 이후에만 Xplenty 파이프라인이 실행되도록 스케줄 또는 의존 관계 트리거를 설정하십시오.
* Xplenty의 Dependent Execution 또는 Webhook Trigger 기능을 활용할 수 있습니다.
4. **오류 발생 시 부분 롤백 전략**
* 역배포 도중 일부 DB에만 데이터가 반영되고 나머지에서 실패하면 데이터 불일치가 발생합니다.
* Xplenty의 단일 트랜잭션 모드(Single Transaction Mode) 또는 Pre/Post-action SQL을 활용해 롤백 전략을 수립하십시오.
5. **모니터링과 알림 설정**
* FlyData와 Xplenty 양쪽에 장애 알림(Hook)을 설정해, 파이프라인의 어느 구간에서 오류가 발생하더라도 즉시 감지할 수 있도록 하십시오.
* Xplenty의 Slack, PagerDuty, Email Hook을 활용하면 효과적입니다.
6. **민감 데이터 처리**
* 개인정보(PII)나 금융 정보가 포함된 데이터를 역배포하는 경우, Xplenty의 Select 또는 Filter 컴포넌트를 사용해 불필요한 민감 필드를 제외하거나 마스킹 처리하십시오.
## 정리
FlyData(ELT)와 Xplenty(ETL)를 결합한 순환형 데이터 파이프라인은 **중앙 집중형 데이터 관리**와 **운영 시스템으로의 데이터 최신화**를 동시에 실현할 수 있는 강력한 아키텍처입니다.
이 아키텍처는 EC 플랫폼, 금융 시스템, 멀티 리전 SaaS 서비스 등 여러 운영 데이터 소스를 보유하면서 중앙에서 통합·계산한 결과를 각 시스템에 환원하고자 하는 경우에 특히 유용합니다.
다만 실시간 트랜잭션 처리나 엄격한 데이터 일관성이 요구되는 용도에는 적합하지 않으므로, 요건에 맞는 적절한 아키텍처 설계가 중요합니다.