Kafka Connect 입문 — 외부 시스템과 카프카 잇기

이 글은 Apache Kafka Connect 실전 정리 시리즈의 첫 번째 편입니다. Kafka 본체를 어느 정도 알고 나면 자연스럽게 다음 질문이 따라옵니다. "그래서 외부 시스템(MySQL·MongoDB·Elasticsearch·S3 같은) 데이터는 어떻게 카프카로 가져오고 또 어떻게 내보내지?" — 그 답이 바로 Kafka Connect 예요.

이 시리즈는 5편을 통해 Kafka Connect의 개념·아키텍처·설정·변환·운영까지 차근차근 쌓아 갑니다. 한 번에 다 외우려 하지 마시고, 이번 1편에서는 "Kafka Connect가 왜 만들어졌는가, 어떤 부품으로 구성되는가, 직접 코드 짜는 것과 뭐가 다른가" — 이 세 가지 질문의 답만 머리에 들어와도 충분합니다.

본문 흐름은 표준 케이블 비유를 따라 풀어 가요. 외부 시스템과 카프카 사이를 잇는 표준화된 케이블 — 그게 Kafka Connect의 정체입니다. 공식 사양이 궁금하다면 Kafka Connect 공식 문서를 곁에 두고 보면 좋아요.

왜 Kafka Connect가 처음엔 어렵게 느껴질까요

이유는 두 가지예요.

첫째, 이미 Producer·Consumer를 배웠는데 또 Connect를 왜 배워야 하나 싶습니다. Kafka 본체에서 Producer로 메시지를 넣고 Consumer로 받아 가는 법을 익혔는데, 그 위에 또 다른 프레임워크라니 — 학습 부담이 커 보이죠.

둘째, Connector·Task·Worker 같은 부품 이름이 추상적이에요. "이게 다 뭐야?" 싶고, 셋 사이 관계도 한 번에 안 잡힙니다.

해결법은 한 가지예요. Kafka Connect를 "외부 시스템과 카프카 사이의 표준 케이블 시스템" 으로 잡고, "케이블 부품(Connector) — 케이블 한 줄(Task) — 케이블을 꽂아 돌리는 일꾼(Worker)" 3층 구조로 풀면 갑자기 명확해집니다. 이 글은 그 비유를 따라 처음부터 풀어 갑니다.

Kafka Connect가 도대체 뭘 해주는 시스템인가요

Kafka Connect 는 외부 시스템과 카프카 사이의 데이터 이동을 표준화된 방법으로 처리하는 프레임워크입니다. 핵심은 한 줄 — 개발자가 직접 Producer/Consumer 코드를 작성하지 않고 설정 파일만으로 데이터 파이프라인을 만들 수 있다는 점이에요.

회사 비유로 풀면 — 부서끼리 자료를 주고받을 때마다 매번 새로 종이 양식을 디자인하고 운반책을 채용하는 게 아니라, 이미 만들어진 표준 양식과 표준 운반 케이블을 그대로 가져다 쓰는 식입니다. MySQL → Kafka, Kafka → Elasticsearch, MongoDB → Kafka 같은 작업은 거의 모든 회사가 똑같이 하는 일이에요. 매번 코드를 새로 짜는 건 시간 낭비죠. Kafka Connect는 그 공통 작업을 커뮤니티가 공유하는 커넥터(Connector) 로 만들어 재사용할 수 있게 해줍니다.

여기서 시험 함정이 하나 있어요. "Kafka Connect는 그냥 Producer·Consumer의 더 편한 버전이다"라는 단순화는 부정확합니다. Kafka Connect는 별도의 프레임워크고, 분산 처리·자동 재균형·REST API·표준화된 설정 같은 운영 기능이 통째로 들어 있어요. Producer/Consumer 코드를 직접 짜는 건 가능하지만, 운영 단계에 가면 Connect가 제공하는 기능을 다시 처음부터 만들어야 합니다.

Kafka Connect의 역사 — 언제 등장했나

Kafka Connect는 Kafka 0.9에서 처음 추가된 API입니다. 이후 지속적으로 개선돼 현재는 수백 개의 커넥터가 오픈 소스로 제공돼요.

버전	출시	주요 변경 사항
Kafka 0.8	2013	토픽 복제, Producer API 단순화
Kafka 0.9	2015년 11월	새 Consumer API, 보안(암호화·인증)
Kafka 0.9	2015	Kafka Connect API 최초 추가
Kafka 1.0	2016년 5월	Kafka Streams API 추가, Connect API 개선

Kafka Connect가 만들어진 이유를 한 번 짚고 가요. Kafka의 일반적인 사용 패턴은 4가지입니다.

1. 외부 소스 → Kafka — DB·API·파일에서 데이터를 카프카로 (Producer API)
2. Kafka 토픽 간 변환 — Kafka Streams로 토픽 데이터를 변환·집계
3. Kafka → 외부 저장소 — 카프카에서 Elasticsearch·S3·DB로 (Consumer API)
4. 앱에서 Kafka 소비 — 애플리케이션이 직접 카프카 구독

여기서 패턴 1·3이 문제예요. 회사마다 똑같은 코드를 매번 새로 짜고 있었거든요. Kafka Connect는 패턴 1·3을 표준화·재사용 가능하게 만든 결과물입니다.

일반적인 Kafka 데이터 플로우:

[Source]  →  [Connect Source]  →  [Kafka Topics]  →  [Connect Sink]  →  [Sink]
 DB/API            ↑                    ↑                    ↑             ES/DB
                Connector           Streaming            Connector
              (설정만 필요)            API              (설정만 필요)

> 한 줄 정리 — Kafka Connect는 "패턴 1(Source)과 패턴 3(Sink)의 코드를 매번 새로 안 써도 되게" 만든 표준 프레임워크.

Kafka Connect 아키텍처 — Connector·Task·Worker 3층 구조

Kafka Connect의 모든 동작은 이 3층 구조에서 나옵니다. 한 번 잡아두면 평생 갑니다.

설정 파일 (Configuration)
    ↓
Connector (재사용 가능한 코드, JAR)
    ↓ (설정에 따라 생성)
Tasks (실제 작업 단위, 여러 개 생성 가능)
    ↓ (Worker가 실행)
Workers (JVM 프로세스, 서버)

각 부품의 자리를 비유로 풀어 봅시다.

Connector — 표준 케이블 부품

Connector 는 재사용 가능한 코드 단위입니다. JAR 파일로 패키징돼 있어요. 회사 비유로 — 표준 규격으로 만들어진 케이블 부품이에요. 누군가 이미 잘 설계해 둔 케이블을 가져다 끝에 우리 시스템 주소만 적어 꽂으면 됩니다.

특징을 정리하면:

• 누군가 이미 작성한 코드 (직접 작성도 가능)
• 오픈 소스로 많이 제공됨
• 설정(Configuration)을 받아 Task를 생성
• Source Connector (외부 → Kafka)와 Sink Connector (Kafka → 외부)로 구분

# 커넥터 클래스 이름을 설정에 지정하면 Connect가 해당 클래스를 로드해 실행
connector.class=org.apache.kafka.connect.file.FileStreamSourceConnector

Task — 케이블 한 줄 (병렬 처리 단위)

Task 는 실제 데이터 이동 작업의 단위입니다. 회사 비유로 — 한 종류의 케이블 부품에서 만들어진 실제 작업 줄 하나예요. 같은 케이블 부품(Connector)에서 여러 줄(Task)을 동시에 빼서 병렬로 일을 시킬 수 있습니다.

• 하나의 Connector가 여러 Task를 생성할 수 있음
• Task는 Worker에 분산되어 실행
• tasks.max 설정으로 최대 Task 수 제어
• Task가 많을수록 더 많은 병렬 처리

예시: Connector A (tasks.max=3)

Connector A
  ├── Task 1  →  Worker 1
  ├── Task 2  →  Worker 3
  └── Task 3  →  Worker 4

Worker — 케이블 일꾼 (서버 프로세스)

Worker 는 Kafka Connect 프레임워크가 실행되는 JVM 프로세스입니다. 회사 비유로 — 케이블을 꽂아 실제로 돌리는 일꾼이에요. 각 Worker는 일반적으로 별도 서버에서 실행되고, 여러 Task를 동시에 맡습니다.

Connect 클러스터 예시:
┌─────────────────────────────────────────┐
│          Connect Cluster                │
│  ┌────────┐  ┌────────┐  ┌────────┐    │
│  │Worker1 │  │Worker2 │  │Worker3 │    │
│  │Task1   │  │Task2   │  │Task3   │    │
│  │Task4   │  │Task5   │  │Task6   │    │
│  └────────┘  └────────┘  └────────┘    │
└─────────────────────────────────────────┘

여기서 시험 함정이 하나 있어요. Worker = 서버, Task = 작업이라고 외워두면 헷갈리지 않습니다. Worker는 사람(=서버)이고, Task는 그 사람이 하는 일거리예요. 한 사람이 여러 일을 동시에 맡듯이 한 Worker가 여러 Task를 동시에 돌립니다.

전체 아키텍처 한 번에 보기

소스부터 싱크까지 데이터가 흐르는 전체 그림을 한 장에 펼쳐 봅시다.

[소스]          [Connect 클러스터]      [Kafka 클러스터]     [Connect 클러스터]    [싱크]

DB/Twitter  →   Worker1  →          Broker1             Worker1  →           ES
MongoDB     →   Worker2  →  Topics  Broker2  Topics  →  Worker2  →           Postgres
파일        →   Worker3  →          Broker3             Worker3  →           S3
                Worker4                                 Worker4

여기서 시험 함정이 하나 있어요. 위 그림에서 Source용 Connect 클러스터와 Sink용 Connect 클러스터가 따로 그려져 있지만, 실제로는 같은 클러스터일 수 있습니다. 하나의 Connect 클러스터가 Source 커넥터와 Sink 커넥터를 동시에 실행해요. 그림이 분리된 건 데이터 흐름을 보여주려는 시각적 편의일 뿐.

데이터 흐름을 Source/Sink로 나눠 풀어 보면:

Source 방향:
[Source]  →  [Connector]  →  [Task1]  →  [Worker]  →  [Kafka Topic]
                         →  [Task2]  →  [Worker]
                         →  [Task3]  →  [Worker]

Sink 방향:
[Kafka Topic]  →  [Task1]  →  [Worker]  →  [Connector]  →  [Sink]
               →  [Task2]  →  [Worker]
               →  [Task3]  →  [Worker]

> 한 줄 정리 — Connector = 표준 부품 / Task = 그 부품에서 빼낸 작업 줄 / Worker = 줄을 돌리는 일꾼.

"코드를 다시 쓰지 마라" — Kafka Connect의 핵심 철학

Kafka Connect의 가장 중요한 사상은 이미 작성된 코드를 재사용하라입니다. PostgreSQL에서 Kafka로 데이터를 넣고 싶다면:

1. 직접 코드를 작성하지 않습니다
2. Google에 "Kafka Connect PostgreSQL"을 검색합니다
3. 이미 만들어진 JDBC Source Connector를 찾습니다
4. 다운로드해서 설정만 변경합니다

이렇게 가는 게 표준입니다.

# 검색 패턴:
Google: "kafka connect [기술명]"

예시:
- kafka connect mongodb
- kafka connect mysql source
- kafka connect s3 sink
- kafka connect dynamodb

자주 쓰는 커넥터 목록

이미 만들어져 있는 대표적인 커넥터들이에요. 거의 모든 데이터 시스템에 대해 누군가가 만들어 뒀습니다.

Source Connector 예시:

• JDBC (관계형 데이터베이스)
• MongoDB
• Twitter
• Elasticsearch
• DynamoDB
• Cassandra
• FTP
• IoT
• Salesforce
• Blockchain
• GitHub API

Sink Connector 예시:

• Elasticsearch
• HDFS (Hadoop)
• JDBC (관계형 데이터베이스)
• S3
• Cassandra
• DynamoDB

ETL 파이프라인에서 Kafka Connect의 자리

Kafka Connect는 ETL(Extract·Transform·Load) 파이프라인의 핵심 구성 요소입니다. 셋 중에 어디 있는지 명확히 잡아 둡시다.

Extract (추출):  Source Connector가 외부 시스템에서 데이터 추출
Transform (변환): Kafka Streams가 데이터 변환·집계 (별도 처리)
Load (적재):     Sink Connector가 목적지 시스템에 데이터 적재

여기서 시험 함정이 하나 있어요. Kafka Connect는 Extract와 Load만 책임지고, Transform은 보통 Kafka Streams가 담당합니다. Connect 안에서도 Single Message Transform(SMT)으로 간단한 변환은 가능하지만, 복잡한 변환은 Kafka Streams의 자리예요. 이 분담은 4편에서 더 자세히 풀게요.

특히 실시간(Real-time) 데이터 파이프라인과 대규모 확장(Scale-out)이 필요할 때 Kafka Connect가 빛납니다.

Standalone Mode vs Distributed Mode — 절대 헷갈리면 안 되는 차이

Kafka Connect를 실행하는 방식이 두 가지예요. 이게 시험·실무 모두에서 결정적입니다.

Standalone Mode — 1인 사무실

단일 프로세스에서 실행되는 모드. 회사 비유로 — 한 일꾼(Worker)이 혼자 모든 일을 처리하는 1인 사무실 같은 거예요. 개발·테스트·소규모 작업에 적합합니다.

장점 — 설정 단순, 디버깅 쉬움. 단점 — 그 한 프로세스가 죽으면 모든 게 멈춥니다. 장애 허용이 없어요.

Distributed Mode — 여러 일꾼이 함께 일하는 사무소

여러 Worker로 구성된 클러스터 모드. 회사 비유로 — 여러 일꾼이 함께 일하는 사무소예요. 한 명이 빠져도 일이 멈추지 않습니다.

장점:

• 수평 확장 — Worker를 추가하면 처리량이 그대로 늘어남
• 장애 허용 — Worker 하나가 죽어도 자동으로 일이 재분배됨
• REST API 제공 — 운영 자동화 가능

단점 — 설정·운영이 약간 더 복잡.

자동 재균형 (Rebalancing)

Distributed Mode의 핵심 자랑이 자동 재균형입니다. Worker가 하나 죽으면 자동으로 Task가 재분배돼요.

장애 전:
Worker1: Task1(C1), Task1(C2)
Worker2: Task2(C2)
Worker3: Task2(C1)
Worker4: Task3(C1), Task3(C3), Task4(C3)  ← 죽음

장애 후 (자동 재균형):
Worker1: Task1(C1), Task1(C2), Task3(C1)  ← 재분배
Worker2: Task2(C2), Task4(C3)              ← 재분배
Worker3: Task2(C1), Task3(C3)              ← 재분배

이게 Standalone보다 Distributed Mode를 써야 하는 핵심 이유예요. 프로덕션은 무조건 Distributed Mode가 정석입니다.

여기서 시험 함정이 하나 있어요. "Standalone Mode가 더 간단하니까 작은 회사도 그걸로 시작하면 되지 않나?"라는 의문이 들 수 있는데 — 테스트·로컬 개발이 아니라면 Distributed Mode가 답입니다. 한 번 장애를 겪고 나면 절대 Standalone으로 안 돌아가요. 이 부분은 3편(설정·배포)에서 더 자세히 풀게요.

Kafka Connect를 쓰면 좋을 때 vs 직접 코드 짜야 할 때

Kafka Connect가 만능은 아니에요. 자기 자리가 분명합니다.

비교표

항목	Kafka Connect	직접 코드 작성
개발 시간	짧음 (설정만)	길음 (전체 구현)
유지보수	커뮤니티가 담당	직접 담당
안정성	검증된 코드	버그 가능성
유연성	제한적	완전 자유
학습 곡선	낮음	높음
확장성	내장	직접 구현
장애 허용	내장	직접 구현

Kafka Connect를 쓰면 안 되는 경우

다음 자리에선 직접 코드 작성이 더 적합합니다.

• 커넥터가 없는 독특한 소스/싱크
• 매우 복잡한 비즈니스 로직이 필요할 때
• 극도로 세밀한 성능 최적화가 필요할 때

이 경우엔 직접 Producer/Consumer 코드를 짜거나, Kafka Connect 커스텀 커넥터를 직접 개발하는 게 정석. 커스텀 커넥터 개발은 4편에서 풀어 갑니다.

> 한 줄 정리 — 커뮤니티 커넥터가 있으면 Connect, 없거나 매우 특수하면 직접 코드 또는 커스텀 커넥터.

사용 가능한 커넥터를 어디서 찾나 — Confluent Hub

Kafka Connect 커넥터를 찾는 가장 좋은 곳은 Confluent Hub 예요. 회사 비유로 — 케이블 부품 마켓플레이스 같은 거예요. 거의 모든 시스템용 커넥터가 모여 있고, 다운로드 수·평점·문서를 한 자리에서 볼 수 있습니다.

Confluent Hub 사용 흐름:

1. https://www.confluent.io/hub/ 접속
2. 검색창에 원하는 기술 입력 (예: "MongoDB", "MySQL")
3. 다운로드 수와 평점 확인
4. 설치 방법·설정 문서 확인
5. ZIP 다운로드 또는 Confluent Hub CLI로 설치

대안으로:

• Google 검색 — kafka connect [기술명] 패턴
• GitHub 오픈 소스 — 많은 커넥터가 오픈 소스로 공개돼 소스 코드를 직접 볼 수 있음

Kafka Connect 특징 압축 정리

여기까지가 Kafka Connect의 큰 그림입니다. 한 번에 외워둘 6가지 특징:

• 재사용성 — 한 번 작성된 커넥터는 설정만 바꿔 다양한 환경에서 재사용
• 확장성 — Distributed Mode에서 Worker 추가로 수평 확장
• 장애 허용 — Worker 장애 시 자동 재균형으로 연속 운영
• 표준화 — 모든 커넥터가 동일한 API 표준
• 실시간 처리 — ETL 파이프라인 실시간 데이터 처리에 최적화
• 코드 최소화 — 설정 파일만으로 복잡한 데이터 파이프라인 구성

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 Kafka Connect 1편의 핵심입니다. 시험 직전 또는 실무에서 헷갈릴 때 다시 펼쳐 볼 수 있게 압축 노트로 마무리할게요.

• Kafka Connect = 외부 시스템 ↔ 카프카 표준 케이블 시스템
• Kafka 0.9(2015년 11월)에 최초 추가
• 4가지 사용 패턴 중 패턴 1(Source) + 패턴 3(Sink) 을 표준화한 게 Kafka Connect
• 3층 구조 — Connector(JAR 부품) → Task(작업 줄) → Worker(서버 프로세스)
• Source Connector = 외부 → Kafka, Sink Connector = Kafka → 외부
• tasks.max = 한 Connector가 만들 최대 Task 수
• 한 Connect 클러스터가 Source·Sink 동시 실행 가능
• ETL 중 Extract·Load만 담당, Transform은 Kafka Streams 자리
• Standalone Mode = 1인 사무실 (개발·테스트), 죽으면 멈춤
• Distributed Mode = 여러 일꾼 (프로덕션), Worker 죽으면 자동 재균형
• 자동 재균형(Rebalancing) = Distributed Mode 핵심 자랑
• 프로덕션은 무조건 Distributed Mode
• 커넥터 검색 — Confluent Hub 가 정석, Google·GitHub 보조
• 검색 패턴 — kafka connect [기술명]
• Connect 안 SMT(Single Message Transform) = 간단한 변환만, 복잡한 건 Kafka Streams
• 커넥터가 없거나 매우 특수한 경우 = 직접 코드 또는 커스텀 커넥터

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.

• 1편 — Kafka Connect 입문 (현재 글)
• 2편 — Source · Sink Connector
• 3편 — Distributed Mode · REST API
• 4편 — SMT · 커스텀 커넥터
• 5편 — 운영 · 프로덕션 (완)