데이터 활용

Federation과 BI, DW 없이 데이터를 제공하는 설계

Data Federation 아키텍처의 설계 원리, 비즈 뷰 개념과 권한 승인 프로세스, 캐시 전략, 인덱스 기반 1,000행 조회 제한의 근거, BI 연동과 엑셀 추출 설계를 다룬다.

Data Governance
저자

Kwangmin Kim

공개

2026년 03월 27일

1 정의

정의: 데이터 활용과 Data Federation

데이터 활용(Data Utilization)은 품질이 보장된 데이터를 최종 사용자에게 안전하고 효율적으로 제공하여 의사결정에 활용하게 하는 활동이다.

Data Federation은 원천 데이터베이스를 직접 쿼리하되, 접근 통제와 부하 관리를 시스템이 자동으로 담당하는 가상화 아키텍처이다. 물리적인 데이터 이동(ETL) 없이 분산된 데이터 소스를 통합 인터페이스로 제공한다.

  • 범위: 비즈 뷰 설계, 접근 권한 관리, 캐시 전략, 조회 제한, BI 연동
  • 목적: 운영 DB 보호와 데이터 접근 편의성의 균형
  • 참조: DAMA-DMBOK2 Chapter 8 (Data Integration & Interoperability)

2 개념 및 원리

2.1 거버넌스 프레임워크 내 위치

데이터 활용은 거버넌스 생명주기의 최종 단계에 해당한다. 앞선 단계에서 구축한 기반이 모두 이 단계에서 사용자에게 전달된다.

표준 설계 → 구조 관리 → 코드/마스터 관리 → 비식별화 → 품질 관리 → [데이터 활용] → 변경 관리

Part 06에서 다룬 품질 관리가 “데이터의 정확도”를 보장하는 것이었다면, 이번 Part 07은 “보장된 데이터를 어떻게 안전하게 제공하는가”를 다룬다. Part 05에서 설계한 마스킹 규칙(TB_MASK_RULE)이 실제로 실행되는 지점도 이 단계이다.

2.2 DW와 Federation의 역할 분담

전통적인 데이터 분석 아키텍처는 운영 DB에서 ETL로 데이터를 추출해 DW에 적재하고, 그 DW에서 분석을 수행하는 구조이다. 이 구조는 대용량 집계 분석, 복잡한 조인, 히스토리 데이터 비교 같은 무거운 분석에 최적화되어 있다. 그러나 실제 현장의 데이터 요구 중 상당 부분은 이보다 훨씬 가볍다.

  • “지금 이 고객의 주문 이력이 몇 건인가”
  • “오늘 접수된 반품 건수가 몇 개인가”
  • “현재 재고 부족 상품 목록을 보고 싶다”

이런 요구마다 DW에 새로운 마트를 만들고 ETL을 구성하는 것은 비효율적이다. 개발 리드타임이 길고, 유지보수 비용이 높고, 데이터 신선도가 ETL 주기에 종속된다. Data Federation은 DW를 대체하는 것이 아니라, DW가 과도한 요구에 대한 경량 대안이다.

2.3 비즈 뷰의 개념과 역할

비즈 뷰(Business View)는 분석가가 사용할 데이터를 정의하는 논리적 단위이다. “고객별 월별 주문 현황”이라는 비즈 뷰는 내부적으로 TB_ORDER, TB_ORDER_ITEM, TB_CUSTOMER를 JOIN하는 SQL을 갖고 있다. 분석가는 이 SQL의 내부를 몰라도 된다. “고객별 월별 주문 현황” 뷰를 선택하고 원하는 기간을 입력하면 데이터를 받을 수 있다.

비유하자면, 식당에서 주방 레시피를 모르더라도 메뉴판에서 원하는 음식을 고르면 완성된 요리가 나오는 것과 같다. 비즈 뷰는 데이터의 메뉴판이다.

비즈 뷰는 세 가지 역할을 동시에 수행한다.

접근 추상화: 복잡한 JOIN 로직을 숨기고 분석가에게 비즈니스 개념으로 데이터를 제공한다. 분석가가 TB_ORDER와 TB_CUSTOMER의 JOIN 조건을 알 필요가 없다. “고객별 주문 현황”이라는 비즈니스 개념만 알면 된다.

접근 통제 단위: “이 사용자는 이 뷰에 접근할 수 있다”는 권한 단위가 된다. DB 테이블 단위로 권한을 주면 하나의 분석 요구에 여러 테이블 권한을 각각 부여해야 한다. 비즈 뷰 단위로 권한을 주면 비즈니스 맥락에 맞는 접근 통제가 가능하다.

비식별화 적용 포인트: 뷰 결과에 포함된 중요데이터 칼럼에 마스킹 규칙을 적용하는 것이 뷰 레이어에서 이루어진다. Part 05에서 설계한 마스킹 규칙(TB_MASK_RULE)이 여기서 실행된다.

2.4 뷰 데이터 추출 흐름

분석가가 비즈 뷰를 통해 데이터를 조회할 때의 전체 흐름은 다음과 같다.

분석가 요청 (뷰 선택 + 아규먼트 입력)
  |
  v
비즈 뷰 접근 권한 확인 (TB_VIEW_ACCESS)
  |
  +-- 권한 없음 -> 거부 + 권한 신청 안내
  |
  v
캐시 확인 (동일 파라미터 조회 결과가 캐시에 있는가?)
  |
  +-- 캐시 히트 -> 캐시 반환 (DB 쿼리 없음)
  |
  v
원천 DB 쿼리 실행 (조회 전용 커넥션)
  |
  v
결과에서 중요데이터 칼럼 마스킹 처리 (access_level 기반)
  |
  v
캐시 저장 (TTL 설정)
  |
  v
분석가에게 결과 반환 + 조회 로그 기록 (TB_VIEW_LOG)

이 흐름에서 핵심은 권한 확인 -> 캐시 -> DB 쿼리 -> 마스킹 -> 로깅이 모두 시스템에 의해 자동으로 처리된다는 것이다. 분석가는 뷰를 선택하고 파라미터를 입력하는 것만 하면 된다. 보안 통제는 분석가가 의식하지 않아도 적용된다.

2.5 캐시 전략

같은 뷰를 다수의 사용자가 같은 파라미터로 자주 조회한다면 매번 DB 쿼리를 실행하는 것은 낭비이다. 캐시를 적용하면 첫 번째 조회 이후에는 DB에 부하를 주지 않는다.

캐시 설계의 핵심은 키 설계와 TTL 설정이다.

캐시 키: {view_id}:{env_type}:{parameter_hash} 형태로 설계한다. 동일 뷰라도 파라미터(기간, 필터 조건)가 다르면 다른 캐시 항목이 된다. parameter_hash는 아규먼트 값들을 정렬하여 해시한 값이다.

TTL 설정: 데이터 신선도 요건에 따라 결정한다.

데이터 갱신 주기 권장 TTL 예시
실시간 변경 5~10분 주문 현황, 재고 수량
시간 단위 갱신 30분~1시간 일별 매출 집계
일배치 갱신 수 시간~하루 월별 리포트, 고객 세그먼트

TTL이 너무 짧으면 캐시 효과가 없고, 너무 길면 데이터 신선도가 떨어진다. 뷰별로 cache_ttl_sec을 설정하여 각 뷰의 데이터 특성에 맞게 조정한다.

아규먼트 필수화: 분석가가 조회할 때 기간, 부서, 제품 카테고리 같은 파라미터를 입력하면 이것이 뷰 SQL의 WHERE 조건으로 사용된다. 파라미터 없이 전체 데이터를 한 번에 반환하면 DB에 부하가 집중된다. 아규먼트를 필수(is_required = 'Y')로 설정하면 쿼리 범위를 제한할 수 있다. 이것은 조회 제한과 함께 운영 DB 보호의 핵심 메커니즘이다.

3 왜 필요한가

3.1 Federation 부재 시 비용과 리스크

Data Federation 없이 운영 DB에 직접 접근을 허용하거나, 모든 분석 요구를 DW로만 처리할 때 발생하는 구체적 문제는 다음과 같다.

문제 영역 부재 시 증상 비용/리스크
운영 안정성 분석가의 비효율 쿼리가 운영 DB에 직접 실행 Full Scan으로 인한 서비스 장애, SLA 위반
보안 통제 테이블 단위 권한만 존재, 칼럼 수준 통제 불가 개인정보 노출 사고, 규제 위반 과징금
데이터 신선도 모든 요구를 DW 경유, ETL 주기에 종속 실시간 현황 확인 불가, 의사결정 지연
개발 효율 단순 조회마다 마트 설계 + ETL 개발 필요 분석 리드타임 수 주, 개발 인력 병목
감사 추적 누가 언제 어떤 데이터를 조회했는지 기록 없음 내부 감사 불통과, 정보 유출 추적 불가

3.2 규제 준수 관점

개인정보보호법, 신용정보법, GDPR 등은 개인정보 접근에 대한 로깅과 최소 권한 원칙을 요구한다. Federation의 비즈 뷰는 이 두 요건을 구조적으로 충족한다. 뷰 단위 권한은 최소 권한 원칙의 구현체이고, 조회 로그(TB_VIEW_LOG)는 감사 추적의 구현체이다. 비식별화가 뷰 레이어에서 자동 적용되므로 분석가가 실수로 원본 개인정보를 열람하는 경로를 차단한다.

3.3 인덱스 기반 조회 제한이 필요한 이유

데이터 조회 기능에서 최대 반환 행 수를 1,000행으로 제한하는 것에 대해 불편함을 느끼는 사용자가 있다. “데이터가 더 많은데 왜 1,000행만 보이냐”는 불만이다.

운영 DB에 직접 접근하는 조회 기능에서 Full Scan 쿼리가 실행되면 운영 서버에 심각한 부하가 생긴다. 수천만 건 테이블에 인덱스를 타지 않는 쿼리를 실행하면 다른 사용자의 운영 서비스에 영향을 줄 수 있다. 1,000행 제한은 단순히 기능의 제약이 아니라 운영 서버 보호를 위한 설계이다.

보호 메커니즘 역할 구현 방법
행 수 제한 결과 셋 크기 제한 FETCH FIRST 1000 ROWS ONLY 또는 LIMIT 1000
인덱스 조건 필수 Full Scan 방지 인덱스 칼럼이 WHERE에 포함되지 않으면 쿼리 거부
아규먼트 필수 범위 제한 비즈 뷰의 필수 아규먼트 미입력 시 실행 거부

인덱스 칼럼이 WHERE 조건에 포함되어야만 조회가 실행된다. 조건 없이 전체 데이터를 가져오는 요청은 거부한다. “이 테이블에서 인덱스로 사용 가능한 칼럼이 무엇인지”는 메타데이터에서 자동으로 파악하고 UI에서 인덱스 칼럼을 강조 표시한다.

4 응용 분야

Data Federation은 산업별로 다양한 데이터 활용 시나리오에 적용된다.

분야 거버넌스 활동 구체적 예시
금융 실시간 리스크 현황 조회 트레이딩 포지션 모니터링, 고객 신용등급 확인 (1,000행 이내 단건 조회)
의료 환자 정보 비식별 조회 진료 이력 통계 조회 시 주민번호 마스킹 자동 적용, IRB 승인 연동
제조 생산 현황 실시간 확인 라인별 불량률 조회, 자재 재고 부족 알림 (운영 MES DB 직접 조회)
공공 민원 데이터 현황 제공 부서별 민원 건수 조회, 개인정보 비식별 처리 후 통계 제공
유통 재고/주문 현황 조회 매장별 재고 현황 실시간 확인, 반품 접수 건수 집계
통신 가입자 현황 조회 요금제별 가입자 수 확인, 해지 예측 대상 목록 조회

모든 분야에서 공통적으로 적용되는 원칙은 비식별화 자동 적용, 조회 로그 기록, 운영 DB 부하 보호이다.

5 예시

5.1 Before: Federation 없이 직접 DB 접근

[상황] 마케팅 팀에서 "이번 달 VIP 고객 주문 현황"을 보고 싶다.

1. 마케팅 담당자가 DBA에게 DB 접근 권한 요청 (3일 소요)
2. DBA가 TB_ORDER, TB_CUSTOMER, TB_ORDER_ITEM 3개 테이블에 SELECT 권한 부여
3. 담당자가 직접 SQL 작성 (JOIN 조건 실수 가능성)
4. WHERE 조건 없이 전체 조회 실행 -> 운영 DB CPU 90% 점유 (30분간 서비스 지연)
5. 결과를 엑셀로 복사 -> 고객 주민번호가 원본 그대로 노출
6. 엑셀 파일을 이메일로 공유 -> 개인정보 유출 경로 생성
7. 누가 언제 조회했는지 기록 없음 -> 감사 추적 불가

5.2 After: Federation 비즈 뷰를 통한 접근

[상황] 동일한 요구: "이번 달 VIP 고객 주문 현황"

1. 마케팅 담당자가 "고객별 월별 주문 현황" 비즈 뷰에 접근 권한 신청 (1일 소요)
2. DA 확인 + 보안 관리자 승인 -> MASKED 수준 권한 부여
3. 담당자가 뷰 선택, 기간(2026-03) 입력 -> SQL을 직접 작성할 필요 없음
4. 시스템이 인덱스 칼럼(order_dt) 기반 조회 실행 -> DB 부하 최소화
5. 결과에서 주민번호 자동 마스킹 (850101-1****** 형태)
6. 엑셀 다운로드 시에도 마스킹 유지 + 다운로드 로그 기록
7. 전체 조회 이력이 TB_VIEW_LOG에 자동 기록 -> 감사 추적 가능
비교 항목 Before (직접 접근) After (Federation)
권한 부여 단위 테이블 3개 각각 비즈 뷰 1개
리드타임 3일 (DBA 대기) 1일 (승인 프로세스)
SQL 작성 담당자 직접 (오류 위험) 시스템이 사전 정의된 SQL 실행
DB 부하 Full Scan 가능 인덱스 기반 + 1,000행 제한
비식별화 수동 (누락 가능) 자동 적용
감사 추적 없음 자동 로깅

5.3 1,000행 초과 요구에 대한 대응

1,000행을 초과하는 데이터가 필요한 분석 요구는 Data Federation의 범위가 아니다. 이 경우 DW나 별도의 분석 플랫폼으로 처리해야 한다.

분석 요구 판별
  |
  +-- 1,000행 이하 + 단순 조회 -> Data Federation (비즈 뷰)
  |
  +-- 1,000행 초과 + 집계 분석 -> DW (마트 설계 요청)
  |
  +-- 대용량 + 탐색적 분석 -> 분석 플랫폼 (Spark, BigQuery 등)

데이터 조회 기능의 목적은 운영 현황 확인과 소규모 검증이지, 대용량 분석이 아니다. 이 경계를 사용자에게 명확히 안내하면 “왜 1,000행만 보이냐”는 불만이 “어디서 대용량 분석을 할 수 있냐”는 건설적인 질문으로 바뀐다.

6 코드/도구 예시

6.1 비즈 뷰 정의 테이블

-- 비즈 뷰 정의 테이블
CREATE TABLE TB_BIZ_VIEW (
    view_id         VARCHAR(50)  NOT NULL PRIMARY KEY,
    view_name       VARCHAR(200) NOT NULL,
    view_desc       VARCHAR(1000),
    base_sql        TEXT         NOT NULL,  -- 원천 SQL
    db_conn_id      VARCHAR(50)  NOT NULL,  -- 대상 DB 커넥션
    cache_ttl_sec   INT          DEFAULT 600,
    max_rows        INT          DEFAULT 1000,
    created_by      VARCHAR(50)  NOT NULL,
    created_dt      DATE         NOT NULL,
    is_active       CHAR(1)      DEFAULT 'Y'
);

-- 비즈 뷰 아규먼트 정의
CREATE TABLE TB_BIZ_VIEW_ARG (
    view_id         VARCHAR(50)  NOT NULL,
    arg_name        VARCHAR(50)  NOT NULL,
    arg_type        VARCHAR(20)  NOT NULL,  -- DATE, STRING, NUMBER, CODE
    is_required     CHAR(1)      DEFAULT 'Y',
    default_value   VARCHAR(200),
    description     VARCHAR(500),
    PRIMARY KEY (view_id, arg_name),
    FOREIGN KEY (view_id) REFERENCES TB_BIZ_VIEW(view_id)
);

base_sql에 저장된 SQL에서 아규먼트는 #{arg_name} 형태의 바인드 변수로 표현한다. 시스템이 아규먼트 값을 바인드 변수에 주입할 때 SQL Injection을 방지하기 위해 반드시 PreparedStatement 방식을 사용해야 한다.

6.2 뷰 접근 권한 관리

-- 뷰 접근 권한 관리
CREATE TABLE TB_VIEW_ACCESS (
    access_id       SERIAL       PRIMARY KEY,
    user_id         VARCHAR(50)  NOT NULL,
    view_id         VARCHAR(50)  NOT NULL,
    access_level    VARCHAR(20)  NOT NULL,  -- MASKED, ORIGINAL
    approved_by     VARCHAR(50)  NOT NULL,
    approved_dt     DATE         NOT NULL,
    expire_dt       DATE         NOT NULL,
    is_active       CHAR(1)      DEFAULT 'Y',
    FOREIGN KEY (view_id) REFERENCES TB_BIZ_VIEW(view_id)
);

access_level이 MASKED이면 중요데이터 칼럼에 마스킹을 적용하고, ORIGINAL이면 원본을 보여준다. 대부분의 분석가에게는 MASKED 수준을 기본으로 부여하고, 원본이 필요한 경우에만 별도 승인을 거쳐 ORIGINAL을 부여한다.

6.3 뷰 권한 승인 프로세스

비즈 뷰에 대한 접근 권한은 Part 05에서 설계한 접근 통제 모델과 동일한 승인 프로세스를 따른다.

분석가 권한 신청 -> 뷰 소유자(DA) 확인 -> 보안 관리자 승인
    -> 권한 부여 (만료일 설정) -> 만료 시 자동 비활성화

뷰 단위 권한은 테이블 단위 권한보다 관리가 편하다. “고객별 주문 현황” 뷰 하나에 권한을 부여하면 내부적으로 3개 테이블에 대한 조회가 가능해진다. 테이블 단위라면 3개 테이블 각각에 권한을 부여해야 한다.

6.4 인덱스 메타데이터 테이블

-- 인덱스 메타데이터 조회
CREATE TABLE TB_META_INDEX (
    table_id        VARCHAR(100) NOT NULL,
    index_name      VARCHAR(100) NOT NULL,
    column_id       VARCHAR(100) NOT NULL,
    column_order    INT          NOT NULL,
    is_unique       CHAR(1)      DEFAULT 'N',
    PRIMARY KEY (table_id, index_name, column_id)
);

시스템이 쿼리 실행 전에 WHERE 절을 파싱하여 인덱스 칼럼 포함 여부를 확인한다. 포함되지 않으면 “인덱스 칼럼(예: order_dt, customer_id)을 조건에 포함해주세요”라는 안내와 함께 실행을 거부한다.

6.5 다운로드 로그

-- 다운로드 로그
INSERT INTO TB_VIEW_LOG (
    user_id, view_id, table_id, executed_sql,
    row_count, was_masked, log_dt, action_type
)
VALUES (
    #{userId}, #{viewId}, #{tableId}, #{sql},
    #{rowCount}, #{wasMasked}, CURRENT_TIMESTAMP, 'DOWNLOAD'
);

6.6 BI 연동: 엑셀 기반 BI와 전용 BI 도구

비즈 뷰를 통해 데이터를 조회하는 것 자체가 목적인 경우도 있지만, 많은 경우 조회 결과를 가공하여 보고서나 시각화를 만드는 것이 최종 목적이다.

엑셀 기반 BI의 현실: 많은 조직에서 BI 도구라고 하면 Power BI, Tableau, Looker 같은 전용 도구를 떠올리지만, 실무에서는 여전히 엑셀이 가장 많이 사용되는 분석 도구이다. 비즈 뷰에서 추출한 데이터를 엑셀 파일(.xlsx)로 다운로드하는 기능은 이 현실을 반영한 것이다.

엑셀 다운로드 기능 설계에서 반드시 지켜야 할 보안 원칙이 두 가지 있다.

  • 다운로드 파일에도 비식별화가 적용되어야 한다. 화면에서 마스킹으로 보였던 데이터가 엑셀 다운로드에서는 원본으로 나오면 보안 통제가 무너진다. 다운로드 시점에 조회와 동일한 마스킹 규칙을 적용해야 한다. access_level = 'MASKED'인 사용자가 다운로드한 엑셀에는 마스킹된 값이 들어가야 한다.
  • 다운로드 시에도 조회 로그를 남겨야 한다. “언제 누가 어떤 데이터를 다운로드했는가”가 감사 대상이다. 화면 조회보다 다운로드가 더 위험하다. 화면은 휘발성이지만 파일은 복사, 전달, 저장이 가능하기 때문이다. 다운로드 로그에는 파일 크기와 행 수도 함께 기록한다.

전용 BI 도구 연동: Power BI나 Tableau 같은 전용 BI 도구와의 연동은 두 가지 방식으로 가능하다.

연동 방식 장점 단점
파일 기반 엑셀 다운로드 후 BI에서 임포트. 별도 연동 개발 불필요 수동 갱신, 데이터 신선도 낮음
API/ODBC 연동 BI 도구가 비즈 뷰 API를 직접 호출. 자동 갱신 가능 연동 개발 필요, 인증/권한 처리 복잡

파일 기반이 초기 단계에서 현실적이다. API 연동은 조직의 BI 성숙도가 높아진 이후에 도입하는 것이 적절하다. 어느 방식이든 비식별화와 로깅은 동일하게 적용되어야 한다.

7 관련 주제

카테고리 내 연결

다른 카테고리 연결

Subscribe

Enjoy this blog? Get notified of new posts by email: