들어가며
KT AI Data Engineering Center는 최근 Databricks 기반의 MAGMA 플랫폼과 Palantir Foundry 간 연동 PoC를 수행했습니다.
이 과정에서 얻은 주요 기술적 경험을 지난 9월 12일 Databricks CIO Forum에서 발표하기도 했는데요, 이번 글에서는 Forum 참여와 실제 PoC 과정에서 얻은 실무자의 고민과 경험, 그리고 인사이트를 공유해보고자 합니다.
MAGMA 데이터 플랫폼과 Palantir 도입 배경
MAGMA: KT의 통합 데이터 플랫폼
KT는 다양한 도메인의 데이터를 통합적으로 수집·정제·분석하고 이를 외부 플랫폼으로도 제공하기 위해 'MAGMA' 라는 통합 데이터 플랫폼을 운영하고 있습니다.
MAGMA는 Databricks 기반의 Lakehouse 아키텍처를 중심으로 구성되어 있으며, Microsoft Fabric, Palantir 등과의 연동을 통해 데이터 활용의 확장성을 높이고 있습니다.
Palantir Foundry의 도입 배경
Palantir는 단순한 데이터 분석 도구를 넘어, 데이터 거버넌스와 협업 중심의 플랫폼으로 주목받고 있습니다.
특히 Ontology 기반의 데이터 모델링과 시각화 기능은 대규모 조직에서 데이터 자산을 효과적으로 관리하는 데 강점을 보
이죠.
KT의 핵심 데이터가 Databricks Unity Catalog에 존재하는 상황에서, 두 플랫폼의 연계를 검증하는 것이 이번 PoC의 핵심 과제였습니다.
PoC 검증 결과: Databricks x Palantir 연계성 확인
저희는 이번 PoC를 통해 Palantir Foundry와 Databricks Unity Catalog 간의 연동 구조가 자사 데이터 환경에 적합한지를 검증하고자 했습니다.
핵심적으로는 데이터 중복(Copy) 최소화를 목표로, Palantir에서 Databricks의 데이터를 직접 활용하는 구조를 실험하였으며, Palantir에서 처리된 데이터를 Databricks로 Pushdown하는 방식도 함께 테스트하였습니다.
이러한 실전 검증을 바탕으로 KT 내 Palantir 활용 시 적용 가능한 기술적 지침을 수립하였습니다.
핵심 연계 구조
- Palantir의 Virtual Table 기능을 적극 활용해, Databricks Unity Catalog의 데이터를 별도 복제 없이 직접 조회·활용
- ADLS Gen2 → Databricks SQL Warehouse → Palantir ← ADLS Gen2 구조로 데이터 흐름 구성
- Private Link를 통해 보안성과 안정성을 확보한 연계 환경 구축
연동 방식
PoC에서는 크게 두 가지 연동 방식을 검증했으며, Palantir의 Virtual Table을 활용할 경우 두 방식 모두가 필요하다는 점이 확인되었습니다.
특히 데이터 Ingestion 시에는 Unity REST API 방식이 확장성과 안정성 측면에서 더 우수하다는 결론을 도출할 수 있었습니다.
| JDBC 방식 | Unity REST API 방식 | |
|---|---|---|
| 동작 방식 |
|
|
| 활용 방안 |
|
|
| 유의 사항 |
|
|
적재 방식 - Write Mode 비교
각 Write Mode는 데이터의 특성과 목적에 따라 선택되며, 적재 방식에 따라 데이터 처리 방식과 운영 전략이 달라집니다.
| 적재방식 | 연결방식 | Write Mode | Delete 연동 방안 | Palantir 활용 방식 | 한계점 |
|---|---|---|---|---|---|
| Sync | JDBC | Snapshot | 재적재 | 저용량 테이블 대상 1회성 적재 (100GB) |
|
| Append | 별도 삭제 연동 | 원천 테이블 지속적 증가 시 | |||
| Virtual Table to Dataset |
JDBC + Unity REST API |
Default | 재적재 | 1TB 이하 1회성 적재, 다량/주기성 적재 (날짜 등 활용해 1TB 이하로 분리 적재) |
|
| Append | 별도 삭제 연동 | 삭제 없이, 추가만 되는 시계열 테이블 (Insert Only, Delete/Update X) |
|||
| Snapshot (Sync Snapshot과 구동방식 상이) |
별도 삭제 연동 | 삭제 없이, 추가/수정만 되는 시계열 테이블 (Insert/Update Only, Delete X) | |||
| Changelog | 소프트 삭제 컬럼으로 배치 처리 | 별도 컬럼으로 수정 삭제 관리 할 경우 (물리 삭제에 대한 연동이 아님) |
기술적 인사이트
Virtual Table 중심 설계
- Virtual Table 위주로 활용하여 데이터 복사 없이 최신 데이터에 접근 가능
- 다만, Foundry 내 다양한 앱을 활용하려면 Dataset 형태로 저장 필요
실시간성 아키텍처 가이드
- Streaming Table → Materialized View → Virtual Table 구조로 실시간 분석 가능
- Materialized View 변환 시 데이터 Full copy되는 한계로, Palantir Kafka Connector를 이용한 Azure Event Hub 직접 연결 필요성 확인
Compute Pushdown
- Palantir에서 처리되는 연산을 Databricks로 위임하여 데이터 이동 없이 연산 효율 극대화 가능
Private Link 기반 보안
- 모든 연동은 Private Link 기반으로 구성해, SaaS 환경에서도 데이터 보안과 네트워크 분리 실현
엔터프라이즈 거버넌스
- Unity Catalog 기반의 권한·암호화·데이터 계보(Lineage) 관리 등에 대한 검증
Databricks와 Palantir 간의 연계 구조는 단순한 기술 통합을 넘어서 데이터 기반 의사결정 체계를 한 단계 끌어올릴 수 있는 가능성을 보여주었습니다.
비록 새로운 기술이지만 전략적 파트너십을 기반으로 솔루션 본사와의 전담 지원 채널을 통해 적극적인 협력을 받았고, 필요한 기능에 대한 로드맵 반영 가능성도 함께 논의할 수 있었습니다.
PoC 과정에서는 실제 운영 환경을 기반으로 수행하여 잠재적인 제약사항과 확장 가능성을 명확히 파악할 수 있었으며, 이를 통해 본 사업에서는 보다 정교한 데이터 파이프라인 설계와 안정적인 시스템 연동이 가능할 것으로 기대됩니다.
Databricks CIO Forum 발표 요약
지난 9월 12일, Databricks가 주최한 CIO Forum에서 이번 PoC의 경험을 발표하며, 다음과 같은 메시지를 전달했습니다.
- KT x Palantir 파트너십: 방대한 데이터를 Ontology 관점에서 신속한 인사이트 확보
- Databricks x Palantir 전략적 파트너십: Databricks의 유연한 데이터 처리 능력과 Palantir의 강력한 데이터 거버넌스 기능의 결합
- Palantir KT도입 및 대고객 위한 본 도입 환경에 시큐어 퍼블릭 클라우드(Secure Public Cloud) 적용: KT와 고객사의 데이터 주권과 보안을 최우선으로, 국내 규제와 요구에 맞춘 시큐어 퍼블릭 클라우드 환경에서 Palantir를 도입
- Databricks-Palantir 연계 강화 위한 요구사항 전달: 국내 LLM 엔진 활용, 데이터 연계 강화(Streaming, Volume 등), Governance 연계 강화
맺으며
MAGMA와 Palantir 연계 PoC는 단순한 기능 검증을 넘어 KT 데이터 플랫폼 전략의 핵심인 MAGMA와 외부 플랫폼이 어떻게 연결될 수 있는지를 확인하는 과정이었습니다.
이번 PoC는 본격적인 도입에 앞서 KT 데이터 환경에 적합한 아키텍처와 운영 방안을 검증하기 위한 중요한 단계였으며, MAGMA의 확장성과 유연성을 실증한 의미 있는 사례가 되었다고 생각합니다.
앞으로도 KT는 데이터 중심의 조직 운영을 위해 MAGMA 기반의 데이터 생태계를 확장하고, Palantir와 같은 고도화된 분석 플랫폼과의 시너지를 지속적으로 강화해 나갈 예정입니다.
함께한 사람들
AI Data Engineering Center 서광민, 최우형