ETL·CDC·EAI와 데이터 연계 통합

ADP 필기 2과목 「데이터 처리 기술 이해」는 객관식 10문항입니다. 1과목이 낱말의 자리를 묻는다면 2과목은 데이터를 실제로 어떻게 옮기고 쌓는지를 묻습니다. 그 첫 자리가 연계와 통합 — 서로 다른 시스템에 흩어진 데이터를 한곳으로 모으는 일입니다. 이 노트에서 다루는 ETL·CDC·EAI 셋은 이름이 비슷해 헷갈리지만 서 있는 층이 다릅니다. ETL은 옮기는 절차, CDC는 무엇을 옮길지 고르는 방법, EAI는 시스템을 잇는 구조입니다.

뽑고 바꾸고 싣는 세 걸음

ETL(Extract, Transform, Load)은 원천 시스템에서 데이터를 뽑아 필요한 형태로 바꾼 뒤 목적지에 싣는 절차입니다. 이름이 곧 세 단계입니다.

실무에서는 이 셋 사이에 자리가 더 끼어듭니다. 뽑은 데이터를 잠시 두는 스테이징 영역을 두어 원천과 목적지를 떼어 놓고, 값의 분포와 결측을 훑어보는 프로파일링으로 무엇이 잘못돼 있는지 먼저 확인하고, 중복과 오류를 걷어내는 클렌징을 거쳐 통합합니다. 스테이징을 두는 이유가 시험에 나옵니다 — 변환이 실패해도 원천 시스템을 다시 건드리지 않고 그 자리에서 재시도할 수 있기 때문입니다.

변환과 적재의 순서를 바꾼 ELT도 함께 묻습니다. 일단 목적지에 원본 그대로 싣고 그 안에서 변환하는 방식이라, 목적지가 대용량 처리에 강할 때(데이터웨어하우스나 분산 처리 환경) 유리합니다. 원본이 그대로 남으므로 나중에 변환 규칙이 바뀌어도 다시 뽑아 올 필요가 없습니다.

바뀐 것만 골라내기

전체를 매번 다시 옮기면 안전하지만 느립니다. CDC(Change Data Capture)는 마지막으로 옮긴 뒤에 바뀐 것만 찾아내 옮기는 기법입니다. 구현 방식이 여럿이고, 각각 원본에 주는 부담과 놓치는 변경이 다릅니다.

가장 자주 쓰이는 타임스탬프 방식은 이런 모습입니다.

SELECT * FROM orders
 WHERE updated_at > '2026-08-26 03:00:00'
   AND updated_at <= '2026-08-27 03:00:00';

여기서 부등호가 한쪽만 등호인 이유를 짚어 둡니다. 구간의 끝을 다음 회차의 시작으로 그대로 쓰기 때문에, 양쪽을 다 포함하면 경계에 걸친 행이 두 번 옮겨집니다. 그리고 이 질의로는 지워진 주문을 찾을 수 없습니다 — 행이 사라졌으므로 조건에 걸릴 것 자체가 없습니다. 삭제까지 따라가야 하면 트리거나 로그 기반으로 가거나, 실제로 지우는 대신 삭제 표시 열을 두는 방식을 씁니다.

시스템을 잇는 구조

EAI(Enterprise Application Integration)는 기업 안의 애플리케이션들을 이어 데이터와 기능을 주고받게 만드는 통합 방식입니다. 핵심은 잇는 모양입니다.

시스템을 서로 직접 잇는 방식을 포인트 투 포인트라 합니다. 둘일 때는 간단하지만 시스템이 늘면 연결선이 폭발합니다. 시스템이 $n$ 개일 때 필요한 연결 수는 다음과 같습니다.

$\frac{n(n-1)}{2}$

가운데에 허브를 하나 두고 모든 시스템을 허브에만 붙이면 연결 수가 $n$ 개로 줄어듭니다. 이것이 허브 앤 스포크 구조입니다. 바퀴의 축(hub)과 살(spoke)에서 온 이름이고, 형식 변환과 라우팅을 허브가 맡습니다.

허브 앤 스포크의 약점이 단일 장애점이라는 것은 자주 나오는 지문입니다. 허브 하나에 모든 흐름이 걸려 있어 그것이 멈추면 이어진 시스템이 함께 멈추고, 트래픽이 몰리면 병목도 거기서 생깁니다.

몰아서 옮길 것인가, 그때그때 옮길 것인가

언제 옮기느냐로도 갈립니다. 일괄 통합(배치)은 정해진 시각에 모아서 한 번에 옮기고, 실시간 통합은 변경이 생길 때마다 곧바로 옮깁니다.

일괄 통합에서 놓치면 안 되는 개념이 배치 윈도 — 다른 업무를 방해하지 않고 배치를 돌릴 수 있는 시간 구간입니다. 처리량이 늘어 이 구간을 넘기기 시작하면 방법은 셋입니다. 처리 속도를 올리거나, CDC로 옮길 양을 줄이거나, 실시간 통합으로 성격을 바꾸는 것입니다.

연계 방식 자체도 갈래를 알아 두면 좋습니다. 데이터베이스 링크나 JDBC처럼 시스템끼리 곧바로 붙는 직접 연결과, EAI·메시지 큐·웹 서비스처럼 가운데 매개를 두는 간접 연결입니다. 직접 연결은 빠르고 단순하지만 한쪽 구조가 바뀌면 다른 쪽이 함께 깨지고, 간접 연결은 그 결합을 느슨하게 만드는 대신 손이 더 갑니다.

정형이 아닌 것을 모을 때

로그·문서·이미지처럼 표에 담기지 않는 데이터는 모으는 도구부터 다릅니다.

이 도구들이 모두 같은 자리에 있는 것은 아닙니다. Flume과 크롤러는 데이터를 만들어 내는 쪽에 붙어 끌어오는 도구이고, Sqoop은 이미 정형으로 쌓인 것을 옮기는 도구이며, 메시지 큐는 오가는 길 위에 놓이는 완충 장치입니다. 문제에서 도구 이름을 섞어 놓고 「성격이 다른 하나」를 고르라고 할 때 이 구분이 답이 됩니다.

메시지 큐를 두는 이유는 속도 차이를 흡수하기 위해서입니다. 데이터를 만드는 쪽과 처리하는 쪽의 속도가 다를 때 큐가 사이에서 완충해 주므로, 처리 쪽이 잠시 느려져도 데이터를 잃지 않습니다. 이렇게 모은 것을 어디에 어떻게 쌓느냐 — 분산 파일 시스템과 NoSQL, 맵리듀스 — 는 2과목의 다음 자리에서 다룹니다.

2과목의 이 절은 계산 없이 성질을 묻는 문제와, 연결 수처럼 한 번 계산해야 하는 문제가 섞여 나옵니다. 표를 외우는 것으로 앞쪽은 풀리지만 뒤쪽은 식을 손으로 한 번 써 봐야 시험장에서 헷갈리지 않습니다.

연습 문제

1. ETL의 각 단계와 하는 일이 바르게 짝지어진 것은?
   ① 추출 — 코드와 단위를 목적지 규칙에 맞춘다
   ② 변환 — 원천 시스템에서 데이터를 읽어 낸다
   ③ 적재 — 목적지 저장소에 데이터를 밀어 넣는다
   ④ 추출 — 중복과 오류를 걷어낸다

   ③. ①은 변환, ②는 추출이 하는 일입니다. ④의 중복·오류 제거는 클렌징으로 변환 쪽에 붙습니다.
2. 타임스탬프 방식 CDC의 약점으로 옳은 것은?
   ① 원본 트랜잭션에 부하가 크게 붙는다
   ② 삭제된 행의 변경을 잡아내지 못한다
   ③ DBMS 종류에 강하게 묶인다
   ④ 애플리케이션 코드를 반드시 고쳐야 한다

   ②. 행이 사라지면 조건에 걸릴 대상 자체가 없어집니다. ①은 트리거, ③은 로그 기반, ④는 이벤트 방식의 약점입니다.
3. 시스템 8개를 포인트 투 포인트로 모두 이었을 때의 연결 수와, 같은 시스템을 허브 앤 스포크로 바꿨을 때의 연결 수를 각각 구하면?
   ① 28개와 8개
   ② 56개와 8개
   ③ 28개와 7개
   ④ 64개와 16개

   ①. 포인트 투 포인트는 $\frac{8 \times 7}{2} = 28$ 개이고, 허브 앤 스포크는 시스템마다 허브로 한 줄씩이므로 8개입니다. 스무 줄이 줄어듭니다.
4. 야간 배치 창이 4시간이고 통합 서버가 초당 1,250건을 처리합니다. 이 창 안에 옮길 수 있는 최대 건수는?
   ① 300만 건
   ② 720만 건
   ③ 1,800만 건
   ④ 5,400만 건

   ③. 4시간은 $4 \times 3600 = 14400$ 초이고, $1250 \times 14400 = 18{,}000{,}000$ 건입니다. 하루 유입이 2,200만 건이라면 이 창으로는 모자라므로 처리 속도를 올리거나 CDC로 옮길 양을 줄여야 합니다.
5. 허브 앤 스포크 구조에 대한 설명으로 옳지 않은 것은?
   ① 형식 변환과 라우팅을 중앙 허브가 맡는다
   ② 시스템이 $n$ 개일 때 연결 수가 $n$ 개로 줄어든다
   ③ 허브가 멈춰도 시스템끼리 직접 통신하므로 영향이 없다
   ④ 트래픽이 몰리면 허브가 병목이 된다

   ③. 모든 흐름이 허브를 지나므로 허브가 단일 장애점이 됩니다. 직접 통신하는 쪽은 포인트 투 포인트입니다.
6. 서술형 연습입니다. 야간 배치로 매일 전체 주문 테이블을 통째로 옮기던 시스템이 데이터가 늘어 배치 창을 넘기기 시작했습니다. CDC를 도입해 해결하려 할 때 어떤 구현 방식을 고르겠는지 근거와 함께 밝히고, 그 방식이 놓치는 것을 무엇으로 메울지 5줄 이내로 쓰시오.

   채점 기준은 셋입니다. (1) 방식을 고르고 근거를 댔는가 — 예를 들어 원본 트랜잭션에 부하를 더하지 않으면서 삭제까지 잡아야 하므로 로그 기반을 고른다거나, 운영 시스템을 고치기 어렵고 삭제가 드무니 타임스탬프로 시작한다는 식입니다. 근거는 원본 부하·삭제 추적 가능 여부·구현 난도 가운데 최소 하나를 짚어야 합니다. (2) 그 방식이 놓치는 것을 정확히 적었는가 — 타임스탬프는 삭제를 놓치고, 트리거는 원본에 부하를 얹으며, 로그 기반은 DBMS에 묶입니다. (3) 메우는 방법을 구체적으로 적었는가 — 실제로 지우는 대신 삭제 표시 열을 두거나, 주 단위로 전체 대사(對査)를 한 번 돌려 어긋난 행을 맞추는 식입니다. 방식만 고르고 약점과 보완을 적지 않으면 배점의 3분의 1만 붙습니다.