핵심 인사이트 (3줄 요약)
- 본질: 연방 쿼리(Federated Query)는 데이터를 물리적으로 이동하지 않고, 분산된 이기종 데이터 소스에 단일 쿼리로 접근하는 패턴이다.
- 가치: 데이터 패브릭(Data Fabric)은 연방 쿼리 + 메타데이터 관리 + 자동 거버넌스를 통합하여 데이터 사일로(Silo) 없는 논리적 단일 데이터 계층을 실현한다.
- 판단 포인트: 쿼리 성능(데이터 이동 비용)과 거버넌스 복잡도의 트레이드오프를 이해하고, Data Fabric vs Data Mesh vs Data Lake의 차이를 조직 구조에 맞게 선택해야 한다.
Ⅰ. 개요 및 필요성
1.1 데이터 사일로 문제
현대 기업은 데이터가 수십 개의 이기종 시스템에 분산되어 있다.
[데이터 사일로 현황]
Oracle DB PostgreSQL MongoDB Salesforce CRM
(영업 데이터) (주문 데이터) (로그 데이터) (고객 데이터)
│ │ │ │
└─────────────┴────────────┴──────────────┘
? 통합 분석 어떻게?
문제:
├─ 데이터 복사/이동 → 일관성 문제
├─ ETL 파이프라인 수십 개 → 관리 부담
└─ 실시간 최신 데이터 접근 불가
1.2 연방 쿼리 (Federated Query) 정의
연방 쿼리는 데이터를 중앙으로 이동시키지 않고 각 데이터 소스에 직접 쿼리를 실행하고 결과를 통합하는 기법이다.
| 항목 | ETL 방식 | 연방 쿼리 방식 |
|---|---|---|
| 데이터 이동 | 중앙 저장소로 복사 | 원본 위치에서 쿼리 |
| 데이터 신선도 | 배치 주기 의존 | 실시간 최신 데이터 |
| 인프라 비용 | 중앙 저장소 비용 | 소스별 컴퓨팅 비용 |
| 쿼리 성능 | 로컬 조회 (빠름) | 네트워크 전송 (느릴 수 있음) |
| 거버넌스 | 중앙 관리 | 분산 정책 필요 |
1.3 데이터 패브릭 (Data Fabric) 정의
데이터 패브릭은 이기종 데이터 소스를 논리적으로 통합하는 아키텍처 레이어로, 연방 쿼리 + 메타데이터 관리 + 자동 거버넌스 + 데이터 카탈로그를 포함한다.
📢 섹션 요약 비유: 연방 쿼리는 여러 도서관의 책(데이터)을 한 곳으로 모으지 않고, 각 도서관에 사서(쿼리 엔진)를 보내 원하는 정보를 가져오는 것이다. 도서관(데이터 소스)은 그대로이고, 정보만 모아온다.
Ⅱ. 아키텍처 및 핵심 원리
2.1 연방 쿼리 실행 아키텍처
사용자 쿼리
SELECT o.order_id, c.name, p.price
FROM orders o JOIN customers c ON o.cid = c.id
JOIN products p ON o.pid = p.id
│
▼
┌─────────────────────────────────────────────┐
│ 연방 쿼리 엔진 (Trino/Presto) │
│ │
│ 1. 쿼리 파싱 및 논리 플랜 생성 │
│ 2. 비용 기반 최적화기(CBO) → 실행 계획 │
│ 3. 소스별 서브쿼리 분해(Pushdown) │
│ 4. 병렬 실행 및 결과 병합(Join) │
└────┬────────────┬──────────────┬────────────┘
│ │ │
▼ ▼ ▼
PostgreSQL MongoDB Salesforce API
(orders) (products) (customers)
│ │ │
▼ ▼ ▼
서브쿼리 서브쿼리 서브쿼리
실행 결과 실행 결과 실행 결과
│ │ │
└────────────┴──────────────┘
│ Shuffle Join
▼
최종 결과 반환
2.2 쿼리 최적화: 프레디케이트 푸시다운 (Predicate Pushdown)
최적화 전 (비효율):
모든 customers 데이터를 엔진으로 가져옴
→ 엔진에서 WHERE age > 30 필터링
최적화 후 (푸시다운):
WHERE age > 30 조건을 소스에 전달
→ 소스(Salesforce)에서 이미 필터링 후 전송
→ 네트워크 전송량 대폭 감소
프레디케이트 푸시다운 지원 수준:
┌────────────────┬─────────────────────────────┐
│ 소스 시스템 │ 푸시다운 지원 수준 │
├────────────────┼─────────────────────────────┤
│ PostgreSQL │ 완전 지원 (SQL 네이티브) │
│ MongoDB │ 부분 지원 (배열 연산 제외) │
│ REST API │ 지원 안됨 (전체 데이터 조회) │
│ Iceberg 테이블 │ 파티션 프루닝 지원 │
└────────────────┴─────────────────────────────┘
2.3 주요 연방 쿼리 엔진 비교
| 엔진 | 개발사 | 지원 소스 | 특징 |
|---|---|---|---|
| Trino (구 PrestoSQL) | Trino 재단 | 50+ 커넥터 | 대용량 분산 처리 |
| Presto | Meta | 30+ 커넥터 | 낮은 지연 |
| AWS Athena Federated Query | AWS | Lambda 커넥터 | 서버리스 |
| BigQuery Omni | GCS/AWS/Azure | 멀티클라우드 | |
| Databricks Unity Catalog | Databricks | Delta, JDBC | 통합 거버넌스 |
| Apache Drill | Apache | 파일/NoSQL | 스키마 없는 쿼리 |
2.4 메타데이터 관리 아키텍처
┌──────────────────────────────────────────────────────┐
│ 메타데이터 관리 계층 │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ 데이터 카탈로그 (Hive Metastore) │ │
│ │ 테이블명, 스키마, 파티션, 통계, 위치(URI) │ │
│ └──────────────────────┬───────────────────────┘ │
│ │ │
│ ┌──────────────────────▼───────────────────────┐ │
│ │ AWS Glue Data Catalog │ │
│ │ 자동 스키마 감지, 버전 관리, IAM 연계 │ │
│ └──────────────────────┬───────────────────────┘ │
│ │ │
│ ┌──────────────────────▼───────────────────────┐ │
│ │ Apache Atlas │ │
│ │ 데이터 계보(Lineage), 태그 기반 분류, RBAC │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘
📢 섹션 요약 비유: 연방 쿼리 엔진은 "여행사 코디네이터"와 같다. 고객(사용자)이 "파리와 도쿄를 모두 보고 싶다"고 하면, 코디네이터(쿼리 엔진)가 각 나라의 여행사(데이터 소스)에 최적의 패키지를 요청하고 결과를 조합한다.
Ⅲ. 비교 및 연결
3.1 Data Fabric vs Data Mesh vs Data Lake 비교
| 항목 | Data Lake | Data Fabric | Data Mesh |
|---|---|---|---|
| 데이터 소유 | 중앙 팀 | 중앙 기술, 분산 소스 | 도메인 팀 |
| 접근 방식 | 물리적 통합 | 논리적 통합 | 분산 자율 |
| 거버넌스 | 중앙 집권 | 자동화된 거버넌스 | 연방 거버넌스 |
| 기술 의존성 | 높음 (단일 플랫폼) | 높음 (통합 레이어) | 낮음 (도메인 자율) |
| 확장성 | 플랫폼 확장 | 커넥터 추가 | 도메인 추가 |
| 적합 조직 | 소규모, 중앙집권 | 중규모, 하이브리드 | 대규모, 도메인 분리 |
3.2 연방 쿼리 성능 최적화 전략
성능 병목 요소 및 해결책
1. 네트워크 전송량 최소화
├─ Predicate Pushdown → 소스에서 필터링
├─ Column Pruning → 필요한 컬럼만 조회
└─ Partition Pruning → 관련 파티션만 스캔
2. 조인(Join) 전략 최적화
├─ Broadcast Join: 작은 테이블을 모든 워커에 복사
├─ Bucket Join: 조인 키로 사전 파티셔닝
└─ Sort Merge Join: 대용량 테이블 조인
3. 통계 정보 활용
├─ 테이블 행 수, 컬럼 카디널리티 통계
└─ CBO(Cost-Based Optimizer)가 최적 계획 선택
4. 결과 캐싱
└─ 반복 쿼리 결과 캐시 (Alluxio, Redis)
3.3 Trino 연방 쿼리 설정 예시
-- Trino 카탈로그 설정
-- /etc/trino/catalog/postgres.properties
-- connector.name=postgresql
-- connection-url=jdbc:postgresql://host:5432/db
-- /etc/trino/catalog/mongodb.properties
-- connector.name=mongodb
-- mongodb.connection-url=mongodb://host:27017
-- 연방 쿼리 실행 (이기종 소스 JOIN)
SELECT
o.order_id,
c.customer_name,
p.product_name,
o.amount
FROM postgres.sales.orders o
JOIN mongodb.catalog.products p ON o.product_id = p._id
JOIN salesforce.crm.customers c ON o.customer_id = c.id
WHERE o.created_at >= DATE '2024-01-01'
AND c.region = 'APAC'
ORDER BY o.amount DESC
LIMIT 100;
📢 섹션 요약 비유: Data Fabric vs Data Mesh는 대형 마트 vs 전통 시장의 차이다. 대형 마트(Data Fabric)는 한 곳에서 모든 것을 구매하는 편리함을 주고, 전통 시장(Data Mesh)은 각 가게가 독립적으로 전문 상품을 판매하지만 전체를 조율하는 시장 관리소가 있다.
Ⅳ. 실무 적용 및 기술사 판단
4.1 연방 쿼리 도입 적합성 판단
| 상황 | 권장 방식 | 이유 |
|---|---|---|
| 실시간 데이터 조합 필요 | 연방 쿼리 | 이동 없이 최신 데이터 |
| 복잡한 집계/대용량 분석 | ETL + DW | 성능 최적화 필요 |
| 데이터 거버넌스 강화 | Data Fabric | 메타데이터 통합 관리 |
| 도메인별 자율성 중요 | Data Mesh | 조직 구조 반영 |
| 빠른 프로토타이핑 | 연방 쿼리 | ETL 없이 즉시 탐색 |
4.2 AWS 환경 연방 쿼리 아키텍처
AWS Athena Federated Query 아키텍처
┌─────────────────────────────────────────────────────┐
│ 사용자 (SQL 클라이언트) │
│ │ │
│ ▼ │
│ Amazon Athena (쿼리 엔진) │
│ ├─ AWS Glue Data Catalog (메타데이터) │
│ └─ Lambda 커넥터 (소스별 연결) │
│ │ │
│ ┌────┴──────────────────────────────────┐ │
│ │ │ │
│ ▼ ▼ │
│ Lambda Connector A Lambda Connector B │
│ (RDS PostgreSQL) (DynamoDB) │
│ │ │ │
│ ▼ ▼ │
│ Amazon RDS Amazon DynamoDB │
│ (트랜잭션 데이터) (사용자 세션 데이터) │
└─────────────────────────────────────────────────────┘
4.3 보안 및 거버넌스 고려사항
| 보안 요소 | 구현 방법 |
|---|---|
| 인증/인가 | OAuth2, IAM Role, RBAC |
| 컬럼 레벨 보안 | 뷰(View) 기반 마스킹, Apache Ranger |
| 감사 로그 | Trino 쿼리 로그 → S3/CloudWatch |
| 네트워크 보안 | VPC 격리, TLS 암호화 |
| 데이터 분류 | 민감도 태그 기반 접근 제어 |
4.4 기술사 논술 핵심 포인트
| 논점 | 핵심 내용 |
|---|---|
| 연방 쿼리 vs ETL | 데이터 신선도 vs 쿼리 성능 트레이드오프 |
| CBO 최적화 | 통계 정보 없으면 연방 쿼리 성능 급락 |
| Data Fabric 구축 | 메타데이터 카탈로그가 핵심 인프라 |
| Data Mesh 전환 | 조직 문화(도메인 책임감) 없으면 실패 |
📢 섹션 요약 비유: 연방 쿼리 엔진의 CBO(비용 기반 최적화기)는 네비게이션과 같다. 도로 상황(데이터 통계)을 알아야 최적 경로(실행 계획)를 찾을 수 있고, 정보가 없으면 엉뚱한 우회로를 선택해 시간이 오래 걸린다.
Ⅴ. 기대효과 및 결론
5.1 데이터 패브릭 도입 기대효과
| 효과 | 정량 지표 |
|---|---|
| 데이터 사일로 제거 | ETL 파이프라인 60% 감소 |
| 시간 단축 | 데이터 탐색 시간 80% 감소 |
| 거버넌스 자동화 | 수동 메타데이터 관리 90% 감소 |
| 규정 준수 | GDPR/CCPA 자동 분류·마스킹 |
5.2 진화 방향: AI 기반 데이터 패브릭
AI 강화 데이터 패브릭 (미래)
현재:
메타데이터 수동 태깅, 정책 수동 설정
미래:
├─ AI 자동 분류: 데이터 내용 기반 자동 태깅
├─ 자동 추천: "이 데이터와 관련된 데이터셋"
├─ 자율 거버넌스: 정책 자동 적용·업데이트
└─ 자연어 쿼리: "지난달 아시아 고객 매출 보여줘"
→ SQL 자동 생성 + 연방 쿼리 실행
5.3 결론 요약
연방 쿼리와 데이터 패브릭은 분산된 데이터 자산을 논리적으로 통합하는 현대 데이터 아키텍처의 핵심이다. 기술사 관점에서는 쿼리 성능 최적화 기법(Pushdown, CBO), 메타데이터 관리의 중요성, 그리고 Data Fabric vs Data Mesh의 조직 적합성 차이를 명확히 이해해야 한다.
📢 섹션 요약 비유: 데이터 패브릭은 여러 도시(데이터 소스)를 연결하는 고속도로 네트워크다. 각 도시(소스)는 독립적으로 운영되지만, 고속도로(패브릭)를 통해 어느 도시 정보든 빠르게 접근하고, 교통 관제 시스템(메타데이터)이 최적 경로를 안내한다.
📌 관련 개념 맵
| 관계 | 개념 | 설명 |
|---|---|---|
| 쿼리 패턴 | Federated Query (연방 쿼리) | 이기종 소스 단일 쿼리 조회 |
| 아키텍처 | Data Fabric (데이터 패브릭) | 이기종 소스 논리적 통합 레이어 |
| 비교 | Data Mesh (데이터 메시) | 도메인 자율 분산 데이터 아키텍처 |
| 엔진 | Trino (트리노) | 오픈소스 분산 쿼리 엔진 |
| 엔진 | AWS Athena Federated Query | 서버리스 연방 쿼리 |
| 최적화 | Predicate Pushdown | 필터 조건을 소스로 전달 |
| 최적화 | CBO (Cost-Based Optimizer) | 통계 기반 실행 계획 최적화 |
| 메타데이터 | Hive Metastore | 하둡 기반 메타데이터 저장소 |
| 거버넌스 | Apache Atlas | 데이터 거버넌스·계보 관리 |
👶 어린이를 위한 3줄 비유 설명
- 연방 쿼리는 여러 도서관에서 책을 빌려오는 심부름꾼이에요. 책을 한 곳으로 옮기지 않고, 각 도서관에서 원하는 부분만 복사해와서 합쳐줘요.
📈 관련 키워드 및 발전 흐름도
데이터 사일로 (시스템별 격리 저장)
│
▼
연방 쿼리 (Federated Query)
├─► 쿼리 푸시다운: 원본 시스템에서 필터링 후 전송
├─► 가상 테이블: 원격 데이터를 로컬처럼 조인
└─► 커넥터: Trino · Presto · BigQuery Omni
│
▼
데이터 패브릭 (Data Fabric)
├─► 분산 메타데이터 통합 · 데이터 카탈로그
└─► 자동 데이터 디스커버리 · 거버넌스
│
▼
데이터 메시 (Data Mesh): 도메인 소유권 분산
- 데이터 패브릭은 여러 나라를 연결하는 번역기 겸 지도예요. 어느 나라 데이터든 같은 언어(SQL)로 대화할 수 있게 해줘요.
- CBO(비용 기반 최적화기)는 네비게이션이에요. 가장 빠른 길(실행 계획)을 찾아주는데, 교통 정보(통계)가 없으면 엉뚱한 길을 안내할 수 있어요.