오늘 이야기의 전체 그림

이전 편까지는 “Kafka 안에서” 벌어지는 일들에 집중했다면, 이번 편은 시야를 조금 바깥으로 넓혀서 본다.

Kafka Connect를 기준으로

애플리케이션, 데이터베이스, 스토리지, 분석 시스템들을 하나의 파이프라인으로 꿰어보는 시간이다.

이번 편에서 정리할 것들

• Connect가 해결하려는 문제
• Source / Sink Connector의 역할
• Worker – Connector – Task 구조
• Task 병렬성과 파티션 설계의 관계
• RDB → Kafka → ClickHouse / S3 같은 전형적인 ETL 패턴
• 실무에서 꼭 챙겨야 할 DLQ, 에러 처리, 스키마 전략

Kafka Connect는 왜 또 나왔을까

Kafka만 있어도, 앱에서 바로 Producer / Consumer 붙여서 이것저것 만들 수 있다.

그런데 어느 순간 이런 생각이 들기 시작한다.

“DB에서 전체 테이블을 Kafka로 옮기고 싶은데, 매번 ETL 앱을 새로 짜야 하나?”

“Kafka 데이터를 S3로 옮겨서 Data Lake를 만들고 싶은데, 또 하나의 Consumer 앱을 써야 하나?”

“운영 환경이 바뀔 때마다 이 코드들을 다 관리할 수 있을까?”