ELT편집자 확인

ETL은 전통적인 데이터 통합 패턴으로, 데이터를 소스 시스템에서 추출한 후 별도의 변환 엔진이나 서버에서 사전에 정의된 규칙에 따라 변환 작업을 수행하고, 최종적으로 데이터 웨어하우스나 데이터 마트에 적재하는 과정을 거친다. 이 방식은 데이터가 목적지에 로드되기 전에 구조와 품질이 엄격하게 정제되므로, 목적지 시스템의 처리 부하를 줄이고 높은 데이터 품질을 보장할 수 있다. 그러나 분석 요구사항이 변경될 때마다 변환 로직을 수정하고 파이프라인을 재구성해야 하는 유연성 부족과, 대용량 데이터 처리 시 변환 단계에서 병목 현상이 발생할 수 있다는 한계가 있다.

반면 ELT는 데이터를 소스에서 추출한 후, 최소한의 정제만 거쳐 바로 클라우드 데이터 웨어하우스나 데이터 레이크 같은 목적지에 로드한다. 모든 변환 작업은 데이터가 로드된 이후, 목적지 시스템의 컴퓨팅 자원을 활용하여 수행된다. 이 패러다임의 핵심 차이는 '변환의 위치와 시점'에 있다. ELT는 데이터를 먼저 원본 형태 또는 준비된 형태로 저장한 뒤, 필요에 따라 변환하는 방식이기 때문에 데이터의 원본성을 유지하고, 다양한 분석 시나리오에 대응하는 데 유리하다.

두 접근법의 주요 차이점을 다음 표로 정리할 수 있다.

이러한 차이로 인해 ELT는 특히 클라우드와 빅데이터 시대에 부상했다. 클라우드 데이터 플랫폼의 탄력적인 스토리지와 거의 무한한 컴퓨팅 확장성을 활용하면, 대용량 데이터를 빠르게 로드한 후 필요할 때마다 변환 쿼리를 실행하는 ELT 방식이 더 효율적이다. 반면, 엄격한 데이터 거버넌스와 복잡한 비즈니스 규칙이 적용된 금융, 의료 등의 전통적인 엔터프라이즈 환경에서는 데이터 품질과 보안을 중시하는 ETL 방식이 여전히 선호된다.

ELT의 핵심 원리는 데이터 처리의 순서와 장소를 기존 ETL 방식에서 전환하여, 변환 작업을 데이터 저장소 내부로 이동시키는 것이다. 이는 "로드 퍼스트, 변환 레이터(Load First, Transform Later)"라는 접근 방식으로 요약된다. 원시 데이터를 최종 목적지에 먼저 적재한 후, 필요에 따라 그 내부에서 변환과 정제를 수행한다. 이 원리는 현대 클라우드 컴퓨팅 환경과 고성능 데이터 웨어하우스의 등장으로 가능해졌다.

이 원리를 뒷받침하는 주요 개념은 ELT 파이프라인의 분리와 확장성이다. 추출, 로드, 변환의 각 단계가 독립적으로 운영될 수 있으며, 특히 변환 단계는 사용자의 분석 요구사항에 따라 유동적으로 적용된다. 데이터는 한 번 로드되면 다양한 목적을 위해 반복적으로 변환될 수 있다. 이는 데이터의 원본 형태를 보존하면서도 다양한 분석 뷰를 생성할 수 있는 유연성을 제공한다.

또 다른 핵심 원리는 컴퓨팅 리소스와 스토리지 리소스의 분리 및 탄력적 활용이다. 변환 작업은 클라우드 데이터 웨어하우스나 데이터 레이크하우스와 같은 목적지 시스템의 고유한 처리 능력을 활용하여 수행된다. 이는 변환을 위한 전용 ETL 서버를 관리할 필요가 없음을 의미하며, 필요할 때만 컴퓨팅 파워를 확장하여 비용을 최적화할 수 있다.

추출 단계는 ELT 프로세스의 첫 번째 단계로, 하나 이상의 소스 시스템으로부터 원본 데이터를 수집하는 과정이다. 이 단계의 주요 목표는 분석이나 처리가 필요한 모든 데이터를 손실 없이 안정적으로 확보하는 것이다.

데이터 소스는 매우 다양하다. 전통적인 관계형 데이터베이스 관리 시스템부터 API, 로그 파일, SaaS 애플리케이션, IoT 센서, 심지어 스프레드시트나 CSV 파일과 같은 평면 파일까지 포함된다. 추출은 일반적으로 증분 추출 또는 전체 추출 방식으로 수행된다. 증분 추출은 마지막 추출 이후 변경된 데이터만을 식별하여 가져오는 반면, 전체 추출은 매번 소스 데이터의 전체 스냅샷을 가져온다[3].

추출된 데이터는 변환 작업 없이 원본 형태 그대로 중간 스토리지나 대상 시스템으로 전송된다. 이는 ETL 방식과의 근본적인 차이점으로, ELT에서는 데이터 품질 검증이나 구조 변환과 같은 복잡한 로직이 이 초기 단계에서 적용되지 않는다. 대신, 데이터는 가능한 한 빠르고 효율적으로 로드 단계로 이동하기 위해 최소한의 필수 처리(예: 데이터 타입 매핑, 압축)만 거친다.

로드는 추출된 원본 데이터를 데이터 웨어하우스나 데이터 레이크와 같은 최종 목적지 시스템으로 이동시키는 단계이다. 이 단계의 주요 목표는 데이터를 가능한 한 빠르고 효율적으로, 그리고 손상 없이 목표 저장소에 적재하는 것이다. ELT 프로세스에서는 변환 작업이 로드 이후에 수행되므로, 로드 단계에서는 데이터의 구조나 품질을 변경하지 않고 그대로 전송하는 것이 일반적이다. 이는 ETL 방식과의 근본적인 차이점 중 하나이다.

로드 작업의 성격은 목표 시스템의 특성에 크게 의존한다. 클라우드 데이터 웨어하우스를 사용하는 경우, Amazon Redshift, Google BigQuery, Snowflake 등의 서비스는 대용량 데이터의 고속 수집을 위한 전용 커넥터나 API를 제공한다. 데이터 레이크에 로드할 경우, Amazon S3, Azure Data Lake Storage, Google Cloud Storage와 같은 객체 저장소에 파일 형태로 데이터를 업로드한다. 로드 방식은 배치 처리 또는 스트리밍을 통한 실시간 수집으로 구분된다.

로드 단계에서의 주요 고려사항은 데이터 무결성, 처리량, 그리고 비용 효율성이다. 네트워크 대역폭, 목표 시스템의 쓰기 성능, 동시성 제한 등을 고려하여 최적의 로드 전략을 수립해야 한다. 일반적으로는 대용량 데이터를 효율적으로 로드하기 위해 파일 기반의 벌크 로드 방식을 사용하며, 데이터 형식으로는 Parquet나 ORC와 같은 컬럼 기반 저장 형식이 선호된다. 이러한 형식은 저장 공간을 절약하고 이후 변환 및 분석 단계의 쿼리 성능을 향상시킨다.

변환(Transform) 단계는 로드(Load)된 원본 데이터를 분석이나 보고에 적합한 형태로 가공하는 과정이다. ELT 아키텍처에서는 변환이 데이터 저장소 내부에서 이루어지며, 주로 SQL 또는 데이터 웨어하우스의 고성능 처리 엔진을 활용한다. 이 접근 방식은 데이터가 이미 대상 시스템에 존재하기 때문에 변환 로직의 변경이나 실패 시 재처리가 상대적으로 용이하다는 특징이 있다.

변환 작업의 주요 목표는 데이터의 품질을 높이고 비즈니스 요구사항에 맞는 구조를 만드는 것이다. 일반적인 변환 작업에는 데이터 정제(결측치 처리, 중복 제거), 표준화(형식 통일, 코드 값 매핑), 집계(요약, 그룹화), 조인(여러 테이블 통합) 등이 포함된다. 예를 들어, 원시 로그 데이터에서 날짜 필드를 표준 형식으로 변환하거나, 여러 소스의 고객 정보를 하나의 통합 뷰로 조합하는 작업이 여기에 해당한다.

변환은 ELT 파이프라인에서 일반적으로 일괄 처리(Batch) 또는 스트리밍(Streaming) 방식으로 실행된다. 최근에는 데이터 웨어하우스의 성능 향상으로 인해 복잡한 비즈니스 인텔리전스(BI) 쿼리나 머신러닝 모델 학습을 위한 특징 공학(Feature Engineering)도 변환 단계에서 직접 수행되는 경우가 많다. 이는 데이터 이동 없이 분석 환경 내에서 모든 처리를 완료할 수 있음을 의미한다.

변환 로직의 관리와 운영은 중요한 고려사항이다. 코드 버전 관리, 테스트 자동화, 작업 의존성 및 스케줄링, 모니터링 체계를 갖추는 것이 일반적이다. 변환 단계의 출력물은 최종 사용자나 분석가가 직접 접근하는 데이터 마트 또는 분석용 뷰(View)의 형태로 제공된다.

ELT 접근법의 가장 큰 강점은 확장성과 유연성에 있다. 기존 ETL 방식이 변환 단계에서 병목이 발생하거나 데이터 소스나 분석 요구사항이 변경될 때 파이프라인을 재설계해야 하는 경우가 많았던 반면, ELT는 데이터를 먼저 원시 형태로 클라우드 데이터 웨어하우스나 데이터 레이크 같은 목적지에 로드한다. 이로 인해 변환 작업은 필요에 따라, 그리고 여러 번 수행될 수 있으며, 데이터 엔지니어와 데이터 분석가가 동일한 데이터 저장소에서 서로 다른 변환 로직을 적용하는 것이 가능해진다.

확장성 측면에서 ELT는 현대적인 클라우드 인프라의 이점을 최대한 활용한다. 대부분의 클라우드 데이터 플랫폼은 저장소와 컴퓨팅 리소스를 분리하여 독립적으로 확장할 수 있도록 설계되어 있다. 따라서 데이터 볼륨이 급증하더라도 저장 공간을 쉽게 늘릴 수 있고, 변환 작업의 복잡도나 빈도가 높아지면 컴퓨팅 파워만 일시적으로 증설하여 처리할 수 있다. 이는 초기 투자 비용을 절감하면서도 성장에 따른 인프라 부담을 줄여준다.

유연성은 데이터 사용자와 사용 사례에 따라 다양하게 발휘된다. 분석가는 원시 데이터에 직접 접근하여 탐색적 데이터 분석을 수행하거나, 비즈니스 요구에 맞춰 자체적으로 데이터 변환 로직을 정의할 수 있다. 이는 중앙 집중식 ETL 파이프라인에 대한 의존성을 낮추고, 부서별 또는 프로젝트별 맞춤형 데이터 뷰를 빠르게 생성할 수 있게 한다. 또한 새로운 데이터 소스를 통합해야 할 때, 먼저 전체적인 변환 로직을 고민하지 않고도 신속하게 로드 단계만 완료하여 데이터를 사용 가능한 상태로 만들 수 있다.

이러한 확장성과 유연성은 데이터 기반 의사 결정의 속도와 민첩성을 높이는 데 기여한다. 조직은 방대하고 다양한 데이터를 한곳에 모아 놓고, 그때그때 필요한 비즈니스 질문에 답하기 위해 데이터를 변환하고 분석할 수 있다. 이는 고정된 스키마와 파이프라인에 의존하는 전통적인 방식보다 진화하는 데이터 환경에 더 잘 적응할 수 있게 해준다.

ELT 접근 방식은 초기 인프라 투자와 운영 비용 측면에서 ETL과 뚜렷한 차이를 보인다. 특히 클라우드 기반의 데이터 웨어하우스나 데이터 레이크를 사용할 경우, 서버리스 컴퓨팅 모델과 자동 확장 기능 덕분에 인프라 관리 비용과 인력 운영 비용을 크게 절감할 수 있다. 사용한 스토리지와 컴퓨팅 리소스에 대해서만 비용을 지불하는 종량제 모델은 초기 자본 지출을 최소화한다. 또한 변환 작업을 로드 이후로 미루기 때문에, 복잡한 변환 로직을 설계하고 유지 관리해야 하는 전용 ETL 툴의 라이선스 비용과 관련 엔지니어링 비용을 줄일 수 있다.

그러나 이러한 비용 절감 효과는 데이터 변환의 복잡성이 데이터 웨어하우스 내부로 이동함에 따라 새로운 형태의 복잡성으로 전환된다는 점을 고려해야 한다. 변환(Transform) 단계가 분석 데이터베이스 내에서 SQL 또는 다른 스크립트를 통해 수행되므로, 데이터 품질 관리, 변환 작업의 오케스트레이션, 그리고 변환 로직의 버전 관리 책임이 데이터 팀으로 완전히 넘어온다. 이는 데이터 엔지니어와 분석가에게 높은 수준의 기술 숙련도를 요구하며, 잘못 설계된 변환 작업이 고비용의 클라우드 컴퓨팅 리소스를 낭비할 수 있다.

비용 구조는 데이터 사용 패턴에 따라 크게 달라질 수 있다. 대규모 배치 변환 작업을 주기적으로 실행하는 경우 예측 가능한 비용이 발생하지만, 실시간 또는 대화형 분석을 위해 빈번하게 변환 쿼리를 실행하는 환경에서는 컴퓨팅 비용이 급증할 위험이 있다. 따라서 비용을 효과적으로 통제하기 위해서는 리소스 사용량을 세밀하게 모니터링하고, 쿼리 최적화를 지속적으로 수행하며, 필요에 따라 컴퓨팅과 스토리지를 분리하는 아키텍처를 채택하는 것이 중요하다.

결론적으로 ELT는 전통적인 ETL에 비해 상당한 비용 효율성을 제공하지만, 이는 관리의 복잡성을 제거한 것이 아니라 그 초점을 이동시킨 것이다. 총소유비용(TCO)을 최소화하기 위해서는 클라우드 비용 관리 전략과 데이터 파이프라인 내 변환 작업의 효율성을 함께 고려해야 한다.

클라우드 데이터 웨어하우스는 ELT 패러다임의 핵심적 기반이자 주요 동인이다. 전통적인 ETL은 변환 작업을 위해 별도의 처리 서버가 필요했지만, 클라우드 데이터 웨어하우스는 자체적으로 거의 무한에 가까운 컴퓨팅 자원과 스토리지를 제공한다. 이로 인해 데이터를 먼저 원시 형태 그대로 웨어하우스에 로드(Load)한 후, 그 안에서 필요한 변환(Transform)을 수행하는 ELT 접근 방식이 실용적으로 가능해졌다. 클라우드 웨어하우스의 탄력적 확장성은 변환 작업의 부하에 따라 컴퓨팅 자원을 즉시 조정할 수 있게 하여, 대용량 배치 처리부터 실시간 스트림 처리까지 다양한 워크로드를 지원한다.

주요 클라우드 데이터 웨어하우스 플랫폼으로는 Amazon Redshift, Google BigQuery, Snowflake, Microsoft Azure Synapse Analytics 등이 있다. 이들은 ELT 프로세스를 용이하게 하는 몇 가지 공통된 특징을 지닌다.

이러한 플랫폼들은 또한 SQL 기반의 강력한 변환 엔진을 제공하여, 데이터 엔지니어와 분석가가 익숙한 언어로 ELT 파이프라인의 변환 단계를 구축하고 실행할 수 있게 한다. 결과적으로, 클라우드 데이터 웨어하우스는 ELT가 지향하는 민첩성과 확장성을 실현하는 데 필수적인 기술적 토대를 마련해 주었다.

ELT 아키텍처의 발전은 데이터 레이크와의 긴밀한 통합을 통해 그 유연성과 범용성을 크게 확장했다. 기존의 ETL 방식이 정형화된 데이터 웨어하우스를 중심으로 설계되었다면, ELT는 원시 데이터를 그대로 저장하는 데이터 레이크의 철학과 자연스럽게 결합한다. 이 접근법은 모든 형태의 데이터(정형, 반정형, 비정형)를 변환 전에 먼저 중앙 저장소에 로드하는 ELT의 핵심 원리를 데이터 레이크에 적용한 것이다. 결과적으로, 데이터 레이크는 ELT 프로세스에서 '로드' 단계의 최종 목적지이자, 원본 데이터의 단일 진실 공급원 역할을 한다.

이 통합 아키텍처의 주요 이점은 데이터 활용의 유연성과 민첩성에 있다. 분석가나 데이터 과학자는 변환 로직을 사전에 정의하지 않고도 데이터 레이크에 적재된 원시 데이터에 직접 접근할 수 있다. 이는 탐색적 데이터 분석, 머신러닝 모델 학습, 또는 사후에 변경될 수 있는 비즈니스 요구사항에 대응하는 데 매우 유리하다. 필요한 변환은 사용 시점에, 특정 분석 목적에 맞게 데이터 레이크 내에서 또는 그 상위의 클라우드 데이터 웨어하우스에서 수행된다. 아래 표는 데이터 레이크 통합 전후의 ELT 흐름을 비교한다.

그러나 데이터 레이크 통합은 데이터 거버넌스와 품질 관리에 새로운 과제를 제시한다. 원시 데이터가 무분별하게 축적될 경우 '데이터 늪'이 될 위험이 있으며, 데이터의 발견 가능성, 이해 가능성, 보안 정책 일관성을 유지해야 한다. 이를 위해 메타데이터 관리 도구, 데이터 카탈로그, 그리고 접근 제어 메커니즘이 데이터 레이크 플랫폼에 필수적으로 통합된다. 최근의 클라우드 기반 데이터 레이크 하우스는 데이터 레이크의 확장성과 데이터 웨어하우스의 성능 및 거버넌스를 결합하여 ELT 파이프라인을 더욱 효율적으로 지원하는 아키텍처로 진화하고 있다.

ELT는 배치 처리 중심의 전통적인 ETL과 달리 실시간 또는 준실시간 데이터 흐름을 지원하는 데 적합한 아키텍처이다. 클라우드 데이터 웨어하우스와 스트리밍 데이터 수집 기술의 발전으로, 데이터가 발생하는 즉시 추출되어 대상 시스템에 로드되고, 이후에 필요한 변환이 수행되는 패턴이 일반화되었다. 이를 통해 기업은 최신 데이터를 기반으로 한 의사결정을 신속하게 수행할 수 있다.

실시간 ELT 파이프라인의 핵심은 변환 단계의 지연을 제거하는 것이다. 추출과 로드는 CDC나 메시지 큐 같은 기술을 통해 연속적으로 실행되며, 원시 데이터는 데이터 레이크나 데이터 웨어하우스에 즉시 적재된다. 비즈니스 로직에 따른 변환은 대상 시스템 내에서 후속 작업으로 실행되거나, 스트림 처리 엔진을 통해 별도로 처리된다. 이 방식은 데이터의 신선도를 극대화한다.

주요 적용 분야는 실시간 대시보드, 사기 탐지, IoT 센서 데이터 모니터링 등이다. 예를 들어, 온라인 거래 로그는 실시간으로 수집되어 Snowflake나 BigQuery 같은 플랫폼에 로드된 후, 즉시 SQL 또는 dbt를 이용한 변환을 거쳐 운영 보고서에 반영된다. 이는 배치 처리로는 불가능한 저지연 분석을 가능하게 한다.

그러나 실시간 ELT 구현에는 고려사항이 따른다. 지속적인 데이터 수집은 원본 시스템에 부하를 줄 수 있으며, 변환 로직의 오류가 실시간으로 전파될 위험이 있다. 또한, 엄격한 데이터 품질 검증과 데이터 보안 정책을 파이프라인 전 단계에 설계해야 한다.

대규모 비정형 데이터 분석은 ELT 아키텍처가 특히 강점을 발휘하는 핵심 적용 분야이다. 전통적인 ETL 방식은 데이터를 데이터 웨어하우스에 로드하기 전에 미리 정의된 스키마에 맞춰 변환해야 했기 때문에, 로그 파일, 소셜 미디어 피드, 센서 데이터, 이미지, 동영상과 같은 형태가 다양하고 구조가 불규칙한 비정형 데이터를 처리하는 데 한계가 있었다. 반면 ELT는 모든 원본 데이터를 먼저 데이터 레이크나 현대적인 클라우드 데이터 웨어하우스에 그대로 로드한 후, 분석 목적에 따라 필요한 시점에서 변환을 수행한다. 이 접근 방식은 데이터의 원본 형태를 보존하면서도, 분석가와 데이터 과학자가 유연하게 데이터를 탐색하고 새로운 인사이트를 도출할 수 있는 기반을 제공한다.

ELT를 통한 비정형 데이터 분석 파이프라인은 일반적으로 세 단계로 구성된다. 첫째, 다양한 소스로부터의 비정형 데이터를 추출(Extract)하여 오브젝트 스토리지나 데이터 레이크에 원본 그대로 저장한다. 둘째, 이 데이터를 분석 엔진이 위치한 클라우드 데이터 플랫폼으로 로드(Load)한다. 마지막으로, SQL 또는 Python, Apache Spark와 같은 도구를 사용해 데이터 레이크 내에서 직접 변환(Transform)과 분석을 수행한다. 이 과정에서 데이터는 정형화되어 데이터 마트나 분석 보고서로 재구성된다.

이러한 접근법의 주요 이점은 분석의 확장성과 민첩성에 있다. 데이터 사일로를 제거하고 모든 데이터를 중앙 집중화함으로써, 기업은 과거에는 연결하기 어려웠던 다양한 데이터 소스를 결합하여 종합적인 분석을 수행할 수 있다. 또한, 분석 요구사항이 변경되거나 새로운 데이터 소스가 추가될 때마다 복잡한 ETL 파이프라인을 재설계할 필요 없이, 저장된 원시 데이터에 대해 새로운 변환 로직을 적용하기만 하면 된다. 그러나 이는 동시에 강력한 데이터 거버넌스 체계와 데이터 품질 관리 프로세스를 필요로 한다. 원시 데이터가 그대로 저장되기 때문에 데이터 중복, 개인정보 보호 문제, 그리고 '데이터 늪'[8]으로 전락할 위험을 관리해야 하기 때문이다.

ELT 프로세스에서 데이터는 변환 전에 원본 형태로 데이터 레이크나 클라우드 데이터 웨어하우스에 적재된다. 이는 변환 단계에서의 데이터 손실 위험을 줄여주지만, 동시에 민감한 원본 데이터가 그대로 저장될 수 있음을 의미한다. 따라서 데이터 접근 제어, 암호화, 마스킹과 같은 보안 정책을 로드 단계 직후부터 엄격히 적용하는 것이 중요하다.

데이터 거버넌스 측면에서는 데이터 계보와 데이터 품질 관리가 핵심 과제이다. 원본 데이터의 출처, 변경 이력, 변환 작업의 추적성을 보장하는 메타데이터 관리 체계가 필수적이다. 또한, 다양한 소스에서 유입된 원본 데이터에 대해 일관된 품질 검증 규칙을 정의하고, 변환 로직의 신뢰성을 지속적으로 모니터링해야 한다.

데이터 보안 및 거버넌스를 효과적으로 구현하기 위해 다음과 같은 접근 방식을 고려할 수 있다.

이러한 조치들은 데이터의 신뢰성을 높이고, 규제 기관의 감사에 대비하며, 궁극적으로 ELT 파이프라인으로부터 생성되는 분석 결과의 의사결정 가치를 보장하는 기반이 된다.

성능 최적화는 ELT 파이프라인의 효율성과 비용 효율성을 보장하는 핵심 고려사항이다. 추출과 로드 단계의 속도뿐만 아니라, 변환 작업이 대상 데이터 웨어하우스 또는 데이터 레이크 내에서 효율적으로 실행되도록 설계하는 것이 중요하다. 주요 최적화 전략은 데이터 분할, 쿼리 최적화, 적절한 컴퓨팅 리소스 관리에 초점을 맞춘다.

데이터 구조 설계는 성능에 직접적인 영향을 미친다. 로드 단계에서 데이터를 효율적으로 분할(예: 날짜, 지역별)하거나 칼럼형 저장소 데이터베이스의 특성에 맞게 테이블을 구성하면 후속 변환 쿼리의 실행 속도를 크게 향상시킬 수 있다. 또한, 변환 작업을 위한 SQL 또는 코드를 작성할 때는 불필요한 조인이나 전체 테이블 스캔을 피하고, 창 함수나 공통 테이블 표현식(CTE)을 효과적으로 활용해야 한다.

사용하는 클라우드 데이터 플랫폼의 특성을 이해하고 리소스를 동적으로 관리하는 것도 중요하다. 많은 클라우드 데이터 웨어하우스는 변환 작업 수행 시에만 컴퓨팅 클러스터를 자동으로 확장(스케일 아웃)하고 작업 완료 후에는 종료하는 서버리스 컴퓨팅 방식을 지원한다. 이는 지속적인 인프라 비용을 절감하면서도 대규모 변환 작업을 신속하게 처리할 수 있게 해준다. 변환 작업의 실행 일정을 조정하여 피크 시간대를 피하거나, 증분 로드 방식을 채택하여 처리할 데이터 양 자체를 최소화하는 것도 효과적인 최적화 방법이다.