최근 Mendix로 구축된 시스템의 데이터를 활용해 Spotfire 대시보드를 만드는 작업을 진행했습니다. 보통의 웹 애플리케이션 개발이 아니라, 데이터 시각화를 위한 백엔드 데이터 구조를 잡는 일이었죠.
그런데 Mendix의 DB 구조... 아시는 분들은 아시겠지만 정말 희한합니다.
1. 문제 상황: Mendix DB의 높은 장벽
Mendix는 ORM(Object Relational Mapping) 기반이라 물리적인 테이블 명이 Module$Entity 형태로 생성되고, 테이블 간의 관계(Join)는 별도의 참조 테이블로 복잡하게 얽혀 있습니다.
우리가 흔히 SQL에서 하듯 LEFT JOIN, INNER JOIN을 걸어서 데이터를 뽑아내려고 보니, 대시보드에 필요한 '기준 정보'들이 전부 각기 다른 테이블에 흩어져 있고 이를 연결하는 물리적 테이블 구조가 너무 복잡했습니다.
"Spotfire에서 이 복잡한 Join을 다 걸어야 하나? 아니면 Mendix DB에서 뷰(View)를 짜야 하나?"
고민 끝에 OData 서비스 연동도 고려해봤지만, 현재 환경에서는 API 활용이 불가능한 상황이었습니다. 데이터 건수는 약 1만 건 정도로 많지 않지만, 구조가 복잡한 게 문제였죠.
2. 해결 전략: Reporting Entity (통계용 테이블) 생성
결국 선택한 방법은 Mendix 안에서 데이터를 미리 조립해서 '납작한 테이블(Flat Table)'로 만들어두는 것이었습니다.
복잡한 연산은 Mendix 안에서 끝내고, Spotfire는 그냥 SELECT *만 하면 되게끔 말이죠.
구현 핵심 아이디어:
- Dashboard Entity 생성: Association(관계) 없이 모든 컬럼을 String, Integer, Decimal 등 기본 타입으로 가진 단일 테이블을 만듭니다. (예: Dashboard_ExternalInspection)
- ETL Microflow 구현: 원본 데이터를 읽어와서(Retrieve), 관계를 타고 값을 가져온 뒤(Map), 대시보드용 테이블에 밀어 넣습니다(Create).
3. 구현 과정: Python 대신 Microflow로 하는 ETL
이 과정을 구현하면서 들었던 생각은 "이거 완전 Airflow로 DAG 짜던 거랑 똑같은데?" 였습니다.
데이터 엔지니어링에서 Python으로 하던 ETL(Extract, Transform, Load) 프로세스를 Mendix의 시각적 도구인 Microflow로 구현하는 것뿐이었죠. 로직은 심플했습니다.
- Extract (Retrieve): 원본 데이터(ExternalInspectionIssue)를 전부 긁어옵니다.
- Transform & Load (Loop & Create):
- Loop를 돌면서 타겟 테이블(Dashboard_Entity)의 객체를 생성합니다.
- 핵심: Member 매핑 단계에서 ExternalInspectionIssue_IF_USER/Inspection.IF_USER/DEPT_NM 처럼 복잡한 경로(Association)를 타고 들어가서, 텍스트 값만 쏙 뽑아 저장합니다.
- Schedule: 이 Microflow를 매일 밤 배치(Scheduled Event)로 돌리면 끝!
4. 결과: 개꿀따리!
결과적으로 아주 손쉽게 해결되었습니다.
- Spotfire: 복잡한 Join 쿼리 없이 단일 테이블만 바라보면 되니 속도도 빠르고 연동이 쉽습니다.
- 유지보수: 데이터 구조가 바뀌더라도 Microflow의 매핑만 수정하면 되니 DB 뷰를 수정하는 것보다 훨씬 직관적입니다.
오랜만에 WebApp 개발 관점이 아니라, 데이터 관점의 ETL을 Mendix로 구현해보니 꽤 신선한 경험이었습니다. Activity 구성도 Retrieve object > Create object + Attribute mapping (in Loop) 정도로 단순해서 금방 구현할 수 있었네요.
Mendix 데이터로 대시보드를 만들어야 하는데 Join 때문에 골머리를 앓고 계신다면, "Mendix 내부 ETL" 방식을 강력 추천합니다. 구현 난이도 대비 효과가 정말 좋습니다!
