Producer/Consumer Interceptor — 레코드가 오가는 길목에 코드를 끼워 넣는다
Kafka Producer/Consumer Interceptor(KIP-42) 및 Kafka Streams TopologyTestDriver 공식 문서 종합 (웹 리서치, 2026) — Apache Kafka KIP-42(Add Producer and Consumer Interceptors), Apache Kafka 공식문서 Testing a Streams Application Apache Kafka KIP-42: Add Producer and Consumer Interceptors
이 모듈을 다 읽으면
- ProducerInterceptor의 onSend()와 onAcknowledgement()가 각각 어느 스레드에서, 어느 시점에 호출되는지 설명할 수 있다
- 인터셉터 체이닝에서 하나가 예외를 던져도 나머지 체인이 계속 진행되는 이유를 설명할 수 있다
kafka-learn-06(프로듀서 직렬화·파티셔닝)과 kafka-learn-47(Connect SMT)을 전제로, 애플리케이션 코드를 건드리지 않고 클라이언트 레벨에서 레코드 흐름에 개입하는 Interceptor(KIP-42)의 동작 시점과 체이닝 규칙을 정리한다.
onSend()와 onAcknowledgement() — 서로 다른 스레드에서 다른 시점에 호출된다
ProducerInterceptor는 send()를 호출한 스레드(submitting thread)에서 onSend()가 실행되고, 이는 kafka-learn-06에서 다룬 키·값 직렬화와 파티션 할당이 일어나기 '전'이다 — 즉 레코드를 직접 수정할 수 있는 시점이다. onAcknowledgement()는 이와 달리 프로듀서의 I/O 스레드에서, 브로커로부터 확인응답이 돌아온 뒤(메타데이터를 포함해) 호출된다. 즉 하나는 '보내기 직전'(수정 가능), 다른 하나는 '응답 받은 직후'(관찰만 가능)라는 서로 다른 시점·스레드에서 동작하는 두 개의 훅이다.
핵심 포인트
- onSend(): submitting thread에서, 직렬화·파티션 할당 '전'에 호출 — 레코드 수정 가능
- onAcknowledgement(): 프로듀서 I/O 스레드에서, 브로커 확인응답을 받은 '후'에 호출 — 관찰용
체이닝 — 하나가 실패해도 나머지가 이어서 실행된다
여러 인터셉터를 리스트로 등록하면 순서대로 체이닝된다. 만약 리스트 안의 어떤 인터셉터가 onSend()에서 예외를 던지면, 그 예외는 잡혀서 로그로 남을 뿐 전체 흐름을 중단시키지 않는다 — 그다음 인터셉터는 그 실패한 인터셉터가 아니라, 마지막으로 성공한 인터셉터가 반환한 레코드를 이어받아 계속 실행된다. 이 덕분에 인터셉터 하나(예: 트레이싱용)의 버그가 다른 인터셉터(예: 감사 로깅용)나 실제 전송 자체를 막지 않는다. 대표 용도는 프로듀서 쪽은 헤더 추가·트레이싱·모니터링, 컨슈머 쪽은 검증·복호화·소비 추적이다 — 그리고 ProducerInterceptor의 메서드는 여러 스레드에서 호출될 수 있어 구현체가 스레드 안전성을 직접 보장해야 한다.
핵심 포인트
- 체인 중 하나가 onSend()에서 예외를 던져도 로그만 남기고 계속 진행 — 다음 인터셉터는 마지막 성공 인터셉터의 결과를 이어받음
- 대표 용도: 프로듀서=헤더 추가·트레이싱·모니터링, 컨슈머=검증·복호화·소비 추적 — ProducerInterceptor는 여러 스레드에서 호출돼 구현체가 스레드 안전성을 직접 보장해야 함