카프카 메시지 전달 보장, 비전공자가 꼭 알아야 할 3가지 방식
카프카 공부하다가 at-least-once, exactly-once 이런 단어 만나면 갑자기 멘탈이 흔들리죠?
저도 처음에 이거 봤을 때 “아, 어차피 메시지 전달하는 거 아닌가? 뭘 이렇게 나눠놓은 거야” 싶었어요. 근데 막상 개념을 파고들어 보니까 왜 이걸 구분해놨는지, 실무에서 이게 왜 중요한지 납득이 가더라고요.
오늘은 비전공자 기준으로, 헷갈리는 부분 위주로 최대한 쉽게 정리해볼게요.
먼저, 카프카에서 “전달 보장”이 왜 문제가 되는 걸까요?
카프카는 프로듀서(보내는 쪽)가 메시지를 보내고, 컨슈머(받는 쪽)가 그걸 가져가는 구조예요.
단순하게 생각하면 “보냈으면 받는 거 아니야?” 싶지만, 현실은 그렇지 않아요. 네트워크는 언제든 끊길 수 있고, 서버는 갑자기 죽을 수 있고, 처리 도중에 오류가 날 수도 있어요.
이런 상황에서 메시지가 아예 사라질 수도 있고, 반대로 같은 메시지가 두 번 처리될 수도 있어요. 카프카는 이 두 가지 위험 사이에서 어떤 걸 선택할지를 세 가지 방식으로 정의해놓은 거예요.
그게 바로 at-most-once, at-least-once, exactly-once예요.
at-most-once: 잃어버려도 괜찮으면 쓰는 방식
at-most-once를 한국어로 풀면 “최대 한 번“이에요.
메시지를 한 번만 전달하려고 시도하고, 실패하면 그냥 넘어가요. 재시도 없음, 확인 없음이에요. 그래서 메시지가 유실될 수 있어요.
“그러면 이걸 왜 써요?” 싶죠? 근데 실제로 쓰는 경우가 있어요.
예를 들어 실시간 로그 수집이에요. 사용자 클릭 로그나 뷰 이벤트처럼 “하나쯤 빠져도 전체 통계에 큰 영향 없는” 데이터가 여기에 해당해요. 대신 처리 속도가 빠르고 시스템 부하가 적어요.
핵심 정리: at-most-once는 빠르지만 메시지 손실 위험이 있어요. 데이터 유실을 감수할 수 있는 상황에서만 써요.
at-least-once: 카프카 기본값, 근데 함정이 있어요
at-least-once는 “최소 한 번” 전달을 보장해요.
메시지가 제대로 처리됐는지 확인(ACK)을 받을 때까지 계속 재시도해요. 그래서 메시지가 사라지는 일은 없어요. 근데 여기서 함정이 생겨요.
같은 메시지가 두 번 이상 전달될 수 있어요.
예를 들어볼게요. 프로듀서가 메시지를 보냈어요. 카프카 브로커(서버)가 메시지를 잘 받았는데, ACK 응답을 보내기 직전에 네트워크가 잠깐 끊겼어요. 프로듀서 입장에서는 “어, 응답이 없네? 실패한 건가?” 하고 같은 메시지를 다시 보내요.
결과적으로 브로커에는 같은 메시지가 두 개 들어가 있는 거예요. 이게 바로 카프카 메시지 중복이 생기는 가장 흔한 이유예요.
카프카의 기본 설정이 at-least-once라서, 아무 생각 없이 쓰다 보면 중복 처리 문제를 만날 수 있어요. 저도 이 부분 공부할 때 “아, 그래서 멱등성(idempotency) 처리가 중요하다는 거구나” 하고 연결이 됐어요.
여러분도 비슷한 경험 있으시죠? 개념 하나를 이해하면 옆에 있던 다른 개념도 같이 이해되는 그 느낌이요.
핵심 정리: at-least-once는 메시지 손실은 없지만, 중복 전달 가능성이 있어요. 컨슈머 쪽에서 중복 처리를 대비해야 해요.
exactly-once: 정확히 한 번, 근데 공짜가 아니에요
exactly-once는 말 그대로 정확히 한 번만 처리되는 걸 보장해요.
유실도 없고, 중복도 없어요. 이상적으로 들리죠? 맞아요, 가장 이상적인 방식이에요. 근데 그만큼 비용이 따라와요.
카프카에서 exactly-once를 구현하려면 두 가지가 필요해요.
첫 번째는 프로듀서 쪽의 idempotent(멱등) 설정이에요. 같은 메시지를 여러 번 보내도 브로커에 딱 한 번만 저장되게 만드는 거예요. 쉽게 말하면 “중복 제거 기능”을 켜는 거예요.
두 번째는 트랜잭션 처리예요. 여러 메시지를 하나의 묶음으로 처리해서, 전부 성공하거나 전부 실패하게 만드는 방식이에요.
이 두 가지를 합쳐야 진짜 exactly-once가 되는데, 설정도 복잡하고 처리 속도도 느려질 수 있어요. 그래서 정말 중복이나 유실이 치명적인 상황에서 써요. 결제 처리, 재고 차감, 금융 트랜잭션 같은 경우가 대표적이에요.
핵심 정리: exactly-once는 가장 안전하지만 성능 비용이 커요. 꼭 필요한 곳에 선택적으로 적용하는 게 포인트예요.
세 가지를 나란히 비교해볼게요
헷갈리지 않게 표로 정리해봤어요.
| 방식 | 메시지 유실 | 메시지 중복 | 성능 | 주요 사용 사례 |
|---|---|---|---|---|
| at-most-once | 있을 수 있음 | 없음 | 빠름 | 로그, 클릭 이벤트 |
| at-least-once | 없음 | 있을 수 있음 | 보통 | 일반적인 데이터 파이프라인 |
| exactly-once | 없음 | 없음 | 느림 | 결제, 금융, 재고 처리 |
세 방식은 “안전할수록 느려지는” 트레이드오프 관계예요.
그래서 카프카를 설계할 때는 “이 데이터가 중복되면 어떤 문제가 생기지?”, “유실되면 얼마나 치명적이지?”를 먼저 따져보고 방식을 선택하는 게 맞아요.
비전공자가 가장 많이 헷갈리는 포인트 두 가지
실제로 공부하면서 제가 헷갈렸던 부분이고, 주변에서도 자주 막히는 지점이에요.
첫 번째: at-least-once인데 왜 중복이 생기지?
“최소 한 번이면 한 번만 오는 거 아냐?” 이렇게 생각하기 쉬운데, “최소”라는 말이 핵심이에요. 한 번 이상 올 수 있다는 뜻이거든요. 네트워크 오류나 재시도 과정에서 같은 메시지가 여러 번 도달할 수 있는 거예요. 처음에 이 차이를 이해하는 데 시간이 좀 걸렸어요.
두 번째: exactly-once는 컨슈머까지 포함하는 개념이에요
exactly-once가 프로듀서에서 브로커까지의 전달만 보장하는 줄 알았는데, 컨슈머가 실제로 처리하는 것까지 포함해야 진짜 exactly-once예요. 컨슈머가 메시지를 받아서 처리하다가 중간에 죽으면, 그 메시지는 다시 처리될 수 있거든요. 그래서 컨슈머 쪽 설계도 같이 신경 써야 해요.
정리하면서
카프카 전달 보장 개념, 어떻게 느껴지셨나요?
솔직히 처음엔 이런 개념들이 “실무에서 쓸 일이 있을까?” 싶기도 했어요. 근데 데이터 엔지니어링에서 파이프라인 설계할 때 이 선택이 시스템 안정성을 좌우하더라고요. 특히 at-least-once에서 중복 문제를 처리하는 방식은 면접에서도 자주 나오는 주제라서, 개념만 외우는 게 아니라 왜 이런 트레이드오프가 생기는지 이해해두는 게 훨씬 도움이 됐어요.
다음번엔 at-least-once 환경에서 중복을 어떻게 방어하는지, 멱등성 처리 방법을 좀 더 파고들어볼게요.
취준 같이 버텨봐요. 화이팅이에요.