카프카 vs 셀러리, 정말 쉽게 — 뭔지·언제 쓰는지·유의할 점

카프카(Kafka)와 셀러리(Celery) — 이름은 자주 들리는데 정확히 뭔지, 언제 쓰는지 헷갈리는 두 도구를 비유로 아주 쉽게 정리했습니다. 한 줄로 먼저 말하면, 카프카는 "메시지가 끝없이 쌓이는 컨베이어벨트", 셀러리는 "잔일을 대신 처리해주는 알바생" 입니다.

들어가며

서비스가 커지면 이런 고민이 생깁니다.

• "회원가입할 때 이메일 보내느라 화면이 3초씩 멈춰요."
• "주문 데이터를 여러 시스템(재고·정산·배송) 에 동시에 흘려보내고 싶어요."
• "매일 밤 정해진 시간에 통계를 돌리고 싶어요."

이럴 때 등장하는 단어가 Kafka 와 Celery 입니다. 둘 다 "일을 나중에/다른 곳에서 처리한다"는 점은 비슷해 보이지만, 역할이 완전히 다릅니다. 하나씩 쉽게 풀어볼게요.

카프카(Kafka) — "끝없이 쌓이는 영수증 롤"

카페 계산대의 영수증 롤을 떠올려 보세요. 주문이 들어올 때마다 영수증이 한 장씩 순서대로 인쇄되어 쌓입니다. 그리고 이 롤은 지워지지 않아서, 주방 직원도·정산 담당자도·배달 담당자도 각자 원하는 시점에 처음부터 죽 읽어갈 수 있습니다.

카프카가 딱 이겁니다. "일어난 일(이벤트)을 순서대로 계속 기록해 두는 거대한 로그" 이고, 여러 프로그램이 그 기록을 각자 읽어갑니다.

용어 (쉽게)

카프카는 언제 쓰나요?

• 데이터를 여러 시스템에 동시에 흘려보내야 할 때 (한 번 쓰면 여러 명이 읽음)
• 엄청 많은 양의 이벤트를 실시간으로 처리할 때 (로그 수집, 클릭 추적, IoT 센서)
• 시스템끼리 직접 연결을 끊고(느슨하게) 확장하고 싶을 때
• "언제 무슨 일이 있었는지" 기록 자체가 중요할 때 (이벤트 소싱)

셀러리(Celery) — "잔일을 대신 해주는 알바생"

이번엔 식당을 떠올려 보세요. 손님(웹 요청)이 오면 점원은 주문서만 바구니에 툭 넣고 바로 다음 손님을 받습니다. 뒤에서는 알바생(워커) 이 바구니에서 주문서를 하나씩 꺼내 요리(무거운 작업) 를 처리하죠. 덕분에 손님은 기다리지 않습니다.

셀러리가 이겁니다. "시간이 걸리는 일을 뒤로 미뤄서, 백그라운드에서 대신 처리해주는 작업 큐" 입니다. (파이썬에서 가장 많이 씁니다.)

용어 (쉽게)

셀러리는 언제 쓰나요?

• 웹 요청 중에 시간이 오래 걸리는 일을 빼내고 싶을 때 (이메일·SMS 발송, 이미지·동영상 변환, PDF 생성)
• 정해진 시간에 반복 작업을 돌릴 때 (매일 밤 통계, 매시간 크롤링) → Celery Beat
• 외부 API 호출처럼 느리거나 실패할 수 있는 작업을 재시도하며 처리할 때

한 문장 비교

💡 둘은 경쟁 관계가 아닙니다. "카프카로 이벤트를 받아 → 셀러리로 무거운 후처리"처럼 같이 쓰기도 합니다. 카프카는 데이터가 흐르는 길, 셀러리는 일을 처리하는 손 이라고 생각하면 쉽습니다.

유의할 점 (실전에서 자주 데는 곳)

카프카

• ⚠️ 운영이 무겁습니다. 그냥 켜두는 서버가 아니라 클러스터를 관리해야 합니다. 소규모 서비스엔 과합니다. (작게 시작할 땐 Redis/RabbitMQ 로 충분)
• ⚠️ 순서 보장은 파티션 안에서만 됩니다. 전체 순서가 필요하면 설계를 신경 써야 합니다.
• ⚠️ 같은 메시지를 두 번 받을 수 있습니다(at-least-once). 받는 쪽이 중복을 걸러도 문제없게(멱등하게) 만들어야 합니다.
• ⚠️ 작업 큐가 아닙니다. "이 일 하나 처리해줘"가 목적이면 카프카보다 셀러리/큐가 맞습니다.
• ⚠️ 보관 기간(retention) 설정을 이해해야 합니다 — 무한정 쌓이면 디스크가 찹니다.

셀러리

• ⚠️ 브로커(Redis/RabbitMQ)가 반드시 필요합니다. 브로커가 죽으면 작업도 멈춥니다.
• ⚠️ 작업이 두 번 실행될 수 있습니다. 재시도·중복에 대비해 멱등하게 짜세요 (예: 결제는 두 번 되면 큰일).
• ⚠️ 결과가 필요하면 result backend 를 따로 설정해야 합니다.
• ⚠️ 아주 오래 걸리는 작업은 타임아웃·재시도 설정을 잘 잡아야 합니다. 무한정 도는 작업 주의.
• ⚠️ 모니터링이 없으면 실패가 조용히 묻힙니다 (Flower 같은 대시보드 권장).
• ⚠️ 기본적으로 파이썬 생태계 도구입니다.

덤 — 여기서 자주 나오는 "청크(chunk)"란?

카프카·셀러리 이야기를 하다 보면 청크(chunk) 라는 말이 자주 튀어나옵니다. 어렵게 생각할 것 없이, "큰 걸 잘게 나눈 한 조각" 입니다.

📦 이삿짐을 트럭에 한 번에 다 실으려 하면 안 들어가죠. 박스 여러 개로 나눠 나르는 게 청크입니다. 박스 하나가 잘못돼도 그 박스만 다시 챙기면 됩니다.

큰 데이터를 통째로 다루면 느리거나, 메모리가 터지거나, 실패하면 처음부터 다시 해야 합니다. 그래서 적당한 크기로 쪼개서 하나씩 처리하는데, 그 조각 하나가 청크예요. 방금 본 카프카·셀러리에서도 이렇게 등장합니다.

청크 쓸 때 유의할 점

• ⚠️ 크기 정하기 — 너무 작으면 조각이 많아 오버헤드↑, 너무 크면 나눈 의미가 사라짐. 적당한 크기가 핵심.
• ⚠️ 경계 문제 — 특히 AI 문서 분할은 문장이 중간에서 잘리면 의미가 깨짐 → 청크끼리 조금 겹치게(overlap) 나누기도 함.
• ⚠️ 순서/조립 — 나눴으면 받는 쪽에서 순서대로 다시 합쳐야 함.

💡 정리하면, 카프카·셀러리·스트리밍·AI 어디서 보든 청크는 똑같이 "덩어리를 나눈 한 토막"입니다. 맥락마다 나누는 대상만 다를 뿐이에요.

어떤 걸 골라야 할까?

• 그냥 "이 느린 일 좀 백그라운드로 빼줘" → 셀러리(또는 간단한 작업 큐).
• 예약/반복 작업이 필요 → 셀러리 + Beat.
• 한 사건을 여러 시스템이 나눠 읽어야 하거나, 초대용량 실시간 데이터 → 카프카.
• 이제 막 시작하는 작은 서비스인데 카프카부터 고민 중이라면 → 아마 아직 필요 없습니다. 먼저 큐로 시작하세요.

마치며

복잡해 보이지만 핵심은 딱 두 문장입니다.

• 카프카 = 사건을 순서대로 쌓아두고 여러 명이 읽어가는 로그(길) — 데이터를 흘려보낸다.
• 셀러리 = 무거운 잔일을 대신 처리하는 알바생(손) — 일을 미뤄서 처리한다.

둘의 정체와 "언제 쓰는지"만 구분해도, 아키텍처 대화가 훨씬 쉬워집니다. 그리고 대부분의 경우 — 작게 시작하고, 정말 필요해질 때 카프카를 얹으세요.