[ADP 필기 요약]_2과목 데이터 처리 기술 이해_②

1. CDC(Change Data Capture)란?

✅ CDC 한 줄 정의

DB나 시스템에서 발생하는 변경(INSERT/UPDATE/DELETE)을 실시간 또는 근실시간으로 감지해서, “변경분만” 효율적으로 전달하는 기술

 

✅ CDC의 핵심 특징

• 운영 DB에서 발생한 변경 데이터만 자동 감지
• ODS/DW/타겟 시스템에 전체가 아니라 변경분만 전송 → 비용/시간 절감
• 변경을 식별해 후속처리 자동화 (동기화, 적재, 알림 등)
• 구현 계층이 다양함
  → 스토리지/DB/로그/애플리케이션 레벨까지 가능

 

1-2. CDC 구현 기법 7가지[📌암기]

① Time Stamp on Rows (타임스탬프 컬럼)

• 방법: 테이블에 updated_at 같은 컬럼 추가 → “마지막 수집 시각 이후” 데이터만 조회
• 장점: 구현 매우 단순 / SQL만으로 가능 / 배치 ETL에 잘 맞음
• 단점: 삭제 추적 불가, 같은 시각 다건 발생 시 중복·누락 리스크

② Version Numbers on Rows (버전 컬럼)

• 방법: 각 행에 version 컬럼 → 변경될 때마다 버전 증가 (참조 테이블 같이 운영하는 경우 많음)
• 장점: 변경 순서 관리가 명확 / 동일 시각 문제 없음
• 단점: 삭제 추적 불가, 이전 값 추적 어려움, 앱/로직에서 버전 관리 필요

③ Status on Rows (상태 컬럼: True/False 등)

• 방법: 타임스탬프 및 버전 넘버 기법에 대한 보완 용도, is_changed, op_type(I/U/D) 같은 상태 컬럼으로 변경 여부/유형 저장
• 장점: INSERT/UPDATE/DELETE 추적 가능(특히 논리 삭제) / 유형 구분 쉬움
• 단점: 테이블 구조 변경 필요 / 데이터 누적 / 상태 관리 로직이 복잡해질 수 있음

④ Time + Version + Status (3종 세트)

• 방법: 시각/순서/유형을 동시에 관리, 3개의 특성을 모두 활용
  예) “특정 시간대 + 특정 버전 범위 + 상태 True” 같은 정교한 조건 가능
• 장점: 변경시점·순서·유형 모두 추적 → 품질/신뢰도 최고
• 단점: 컬럼 증가로 복잡도↑ / 성능 부담↑ / 개발·운영 비용↑

⑤ Triggers on Tables (DB 트리거)

• 방법: 트리거로 변경 이벤트 발생 시 자동 기록/전파 (사전 등록된 대상에 배포)
• 장점: 변경 추적 정확 / 이전 값 기록 가능 / 실시간에 가까움
• 단점: 트리거 많아지면 성능 저하 / 운영 DB 부하↑ / 장애 원인 분석 난이도↑
  → 유지보수성 이슈로 “주의해서” 사용

⑥ Event Programming (이벤트 기반 CDC)

• 방법: 애플리케이션에서 변경을 감지해 이벤트로 발행 (Kafka 등과 찰떡)
• 장점: 실시간 스트리밍 처리 / DB 부하 최소화 / MSA(마이크로 서비스 아키텍처)에 적합
• 단점: 앱 수정 필요 / 이벤트 유실·중복 처리 고려 / 설계 난이도 높음

⑦ Log Scanner & Database (로그 기반 CDC)

• 방법: DB 트랜잭션 로그를 스캔/해석해서 변경 추적
• 장점: 운영 테이블 구조 변경 불필요 / 성능 영향 최소 / 모든 변경 추적 가능
  → 가장 정교하고 “표준적인” CDC 방식으로 많이 언급
• 단점: 구현 난이도 높음 / 벤더 종속 가능 / 전문 솔루션 필요

1-3. CDC 구현 “방식” 관점: PUSH vs PULL

• PUSH: Source(원천)가 변경을 식별 → Target(대상)에 밀어 넣음
• PULL: Target(대상)이 주기적으로 Source를 확인 → 필요 시 가져옴

👉 실시간성이 중요할수록 보통 PUSH 성격이 강해지고, 단순 동기화는 PULL로도 많이 갑니다.

---

2. EAI(Enterprise Application Integration)란?

2-1. EAI 개념 & 특징

기업 내 다양한 시스템(ERP/CRM/SCM 등)을 통합적으로 연계해 데이터·프로세스 흐름을 개선하는 “통합 연계 플랫폼”

• 부서별로 시스템이 다르면 생기는 문제들:
  • 데이터 불일치
  • 중복 입력
  • 프로세스 단절
    → EAI가 중앙에서 연계·중개해 해결

✅ 포인트 하나 더:

• ETL은 배치 중심
• EAI는 실시간/근실시간 중심

2-2. 데이터 연계 방식: Point-to-Point vs Hub & Spoke

❌ 기존: Point-to-Point

• 시스템끼리 1:1로 직접 연결
• 연결 대상이 N개면 연결 수는 N(N-1)/2 → 늘어날수록 폭발
• 표준화 어려움 / 경로 복잡 / 유지보수 비용 급상승

✅ EAI: Hub & Spoke[📌암기]

• 중앙에 Hub(브로커)를 두고, 각 시스템(Spoke)이 Hub를 통해 연계
• 구조가 단순해지고 변경 영향도 줄어듦
• 참고로 자주 나오는 문장:
  • ETL/CDC는 운영DB와 분석DB가 분리된 흐름
  • EAI는 여러 시스템을 Hub에서 통합 연계

2-3. EAI 구성요소

• Adapter(어댑터): 각 시스템 ↔ EAI 허브 연결
• Bus(버스): 시스템 간 데이터 이동 경로
• Broker(브로커): 연동 규칙/라우팅 통제
• Transformer(트랜스포머): 데이터 포맷 변환 담당

2-4. EAI 구현 유형 2가지

① Mediation (Publish/Subscribe)

• EAI 엔진이 중개자로 동작하며, 이벤트를 감지해서 약속된 시스템으로 전달
  → “구독자에게 발행한다” 느낌

② Federation (Request/Reply)

• EAI 엔진이 요청을 일괄로 받아 필요한 데이터를 찾아 응답
  → “요청하면 답한다” 느낌

2-5. EAI 활용 효과[📌암기]

• 개발/유지보수 비용 절감
• 기업 정보 시스템의 지속적 발전 기반
• 협력사/파트너/고객 프로세스 연계
• 웹서비스 등 인터넷 비즈니스 토대 마련
• 지역/계열사 간 데이터 동기화 및 표준화 기반 제공

2-6. EAI vs ESB 비교 (핵심만)

구분	EAI (Enterprise Application Integration)	ESB (Enterprise Service Bus)
기능	미들웨어(Bus)를 이용하여 비즈니스 로직을 중심으로 Application을 통합.연계	미들웨어(Bus)를 이용하여 서비스 중심으로 시스템을 유기적으로 연계
통합관점	Application	Process
로직연동	개별 Application에서 수행	ESB에서 수행
아키텍처	단일 접점인 허브시스템을 이용한 중앙집중식 연결구조	버스(Bus)형태의 느슨하고 유연한 연결구조

• EAI: 애플리케이션(업무 로직) 중심, 허브 중심(중앙집중형) 통합
• ESB: 서비스 중심, 버스 기반(느슨하고 유연한 연결) 연계
  • 로직 연동을 ESB에서 수행하는 성격이 강함

---

마무리 요약 (암기용)

• CDC: “DB 변경분만 잡아서 전달” (변경 감지/추출 기술)
• EAI: “기업 내 시스템들을 허브로 통합 연계” (통합 플랫폼/미들웨어)