ETL이란? 추출·변환·적재와 ELT 워크플로의 경계

작성: Ai Flowi · 게시일 2026-10-11

ETL이란 추출·변환·적재를 뜻하며, 원본에서 레코드를 읽고 합의된 표현으로 변환한 다음 승인된 결과를 대상에 쓰는 데이터 파이프라인입니다. ELT는 순서를 바꿉니다. 추출된 레코드를 먼저 적재하고 대상 환경에서 변환합니다. 중요한 경계는 단순히 어떤 도구로 데이터를 옮기느냐가 아니라 검증, 거부된 레코드, 복구를 어디에서 처리하느냐입니다.

세 단계의 의미

추출은 어떤 원본 레코드가 배치에 속하는지 식별하고 원래 의미를 그대로 유지하면서 읽습니다. CSV 내보내기, 데이터베이스 쿼리, API 응답으로 배치를 제공할 수 있습니다. 나중에 담당자가 레코드가 포함된 이유를 설명할 수 있도록 원본 참조와 선택 규칙을 보존합니다.

변환은 필드 이름, 허용 유형, 단위, 필수 값, 거부 규칙 등 대상 규약을 적용합니다. 앞에 0이 있는 식별자는 숫자로만 이루어져 있어도 텍스트입니다. 숫자로 바꾸면 적재를 시작하기도 전에 정보가 훼손될 수 있습니다. 변경이 감사나 수정에 중요하다면 수정한 값과 함께 원래 값도 보관합니다.

적재는 승인된 레코드를 쓰고 대상에 실제로 무엇이 저장되었는지 확인합니다. 요청을 보냈다는 사실은 쓰기가 확인되었다는 사실보다 약한 근거입니다. 쓰기 후 응답이 사라지면 대상을 확인하기 전까지 결과를 알 수 없습니다. 즉시 같은 요청을 반복하면 중복이 생길 수 있습니다.

판단을 함께 기록한 가상 배치

교육용으로 만든 예시입니다. 이 행과 건수는 기록된 워크플로 실행 결과가 아닙니다. 규약상 품목 ID는 텍스트이고 수량은 음이 아닌 정수여야 하는 재고 내보내기를 가정합니다. 배치에는 네 행이 있습니다. 각 원본 행에 품목 ID와 무관한 고정 참조를 부여합니다.

추출 건수는 4건입니다. 변환 판단은 승인 2건과 거부 2건입니다. A만 쓰기가 확인되었다면 적재는 미완료입니다. 승인된 행 하나는 확인되었고 다른 하나는 대기 중이거나 결과가 불확실합니다. 변환으로 후보 두 개가 나왔다는 이유만으로 두 행이 적재되었다고 보고하지 않습니다.

거부 기록에는 원본 참조, 원래 값, 구체적인 이유가 남아야 합니다. C를 수정하면 C와 연결된 새로운 검토 판단을 만듭니다. 첫 시도의 근거를 지워서는 안 됩니다. 자세한 전송 설정은 다음 가이드를 따릅니다: CSV를 Google Sheets로 전송하는 가이드.

같은 레코드로 ETL과 ELT는 어떻게 다른가요?

ELT가 검증되지 않은 데이터를 게시할 수 있다는 뜻은 아닙니다. 스테이징 영역에는 적절한 접근 권한이 필요하고 보고에 쓰는 테이블과 명확히 구분되어야 합니다. ETL은 부적합한 레코드가 대상에 들어가지 않게 할 수 있지만, 거부 레코드를 안전하게 보존할 장소는 여전히 필요합니다. 어느 순서도 그 자체로 트랜잭션 지원이나 안전한 재처리를 보장하지 않습니다.

관련 자료: 리버스 ETL: 운영 시스템에서의 데이터 활용과 쓰기 경계 이해하기.

체크포인트, 워터마크, 재처리

워터마크는 마지막으로 검토한 갱신 위치처럼 변화하는 원본에서 어디까지 진행했는지 나타냅니다. 체크포인트는 정해진 경계에서 완료된 작업을 기록합니다. 해당 적재를 확인하기 전에 추출 진행 상황을 기록하면 실패 후 레코드를 건너뛸 수 있습니다. 원본 선택의 진행 상황과 대상 저장 확인을 구분합니다.

여러 레코드의 갱신 시각이 같으면 타임스탬프만으로 완전한 경계를 식별하지 못할 수 있습니다. 안정적인 동률 해소 기준을 정의하거나, 중복을 의도적으로 처리하면서 겹치는 범위를 읽습니다. 늦게 발생하는 변경에는 별도의 대조·조정 정책이 필요합니다. 더 새로운 워터마크가 있다고 이전 레코드가 다시는 바뀌지 않는 것은 아닙니다.

재처리하려면 배치와 각 원본 레코드를 식별합니다. 반복 시 덮어쓸지, 병합할지, 무시할지, 검토할지 정합니다. 추가 작업만으로 이 정책이 정해지지는 않습니다. 일부 적재가 실패하면 대상에서 확인된 레코드를 조사하고 선택한 복구 규칙에 따라서만 재시도합니다.

빌더에서 재고 처리 경계를 표현하기

Load CSV, JSON Operations 및 Google Sheets 쓰기 참조 문서를 이 배치 예시의 읽기, 매핑, 대상 인터페이스에 관한 참조 문서로 사용합니다.

이 파이프라인에서 내려야 할 판단은 원본 행이 언제 쓰기 대상이 되는지입니다. A와 B는 재고 규약에 적합하고 C와 D는 거부 대장에 남습니다. 네 행을 모두 쓰기 구성 요소에 보내 놓고 대상의 서식 지정이 검증을 수행할 것이라고 가정하지 않습니다. 제안한 이 재고 파이프라인의 Load CSV, JSON Operations, Append Rows는 카탈로그에 문서화되어 있으나 Ai Flowi의 프로덕션 테스트를 거치지 않았습니다. 읽기, 매핑, 쓰기를 결합한 설정은 테스트되지 않았습니다.

설정 예시이며 기록된 테스트가 아닙니다

1. 가상 내보내기 파일은 Load CSV의 csv_file로 제공합니다. 필드를 선택하기 전에 JSON 행을 확인합니다.
2. 검토된 매핑을 시험하려면 JSON Operations의 data에 확인한 원본 JSON을 넣고 "JQ Expression"을 operations에서 선택합니다. 검토된 검증 및 행 매핑 표현식을 query에 넣습니다. 적재 후보를 선택하기 전에 거부 레코드를 별도로 보관합니다.
3. Append Rows는 승인된 배열을 values로 받습니다. "RAW"를 value_input_option의 값으로 선택하여 제안한 이 쓰기에서 검토된 셀 표현을 유지합니다. range_name을 재고 영역에, spreadsheet_id를 해당 문서에, google_account를 승인된 연결에 연결합니다.
4. 배치를 완료로 표시하기 전에 기록된 값과 승인 행 대장을 비교합니다.

대조·조정에는 합계뿐 아니라 행 식별자도 필요합니다. 대상에 A가 두 번 있으면 행은 두 개이지만 A와 B가 올바르게 적재된 것은 아닙니다. 승인된 원본 참조 집합과 대상에서 확인된 참조 집합을 비교하고, 수량도 검토된 후보와 대조합니다. B의 쓰기를 확인할 수 없다면 대기 상태로 둡니다. 하나가 누락되고 다른 하나가 중복되어도 배치 합계는 일치할 수 있습니다.

CSV를 시트로 전송하는 설정 가이드에서 계정과 연결의 사전 요구 사항을 확인하고, 이 배치 예시에는 사용이 허용된 재고 내보내기 파일을 빌더에 가져옵니다. 재고 규약은 모델 호출 없이 명시적인 규칙을 사용합니다. 제공업체의 모든 요금은 Flowi 구독과 별도입니다.

스키마 변화와 한계

원본 열이 사라지거나 의미가 바뀌거나 단위가 섞이기 시작하면 영향을 받는 규약 경계에서 중단합니다. 필드 이름 변경은 의미가 계속 명확할 때만 안전합니다. 스키마 버전을 유지하고 인식할 수 없는 변경은 거부합니다. 빈 열을 유효한 데이터로 통과시키지 않습니다.

이 배치에는 승인된 레코드, 거부 대장, 대상 쓰기의 근거라는 별도의 결과물 세 가지가 필요합니다. 이 카탈로그 항목은 기본 제공 변경 데이터 캡처, 원자적인 다단계 적재, 정확히 한 번 전달을 입증하지 않습니다. 이러한 요구 사항이 작업을 좌우하면 트랜잭션과 복구 동작이 검증된 시스템을 사용합니다. 기존 레시피의 범위는 문서화된 활용 사례에서 확인합니다.

관련 용어

데이터 정제는 변환 과정의 수정과 미해결 값을 설명합니다. API 통합은 추출이나 적재가 이루어질 수 있는 서비스 경계를 다룹니다.