창고별 배송 수량을 10초마다 집계하는 Flink 작업이 있다고 하자. 작업이 멈췄다가 다시 시작하면 어디서부터 읽어야 할까? 이미 결과를 내보낸 구간에 늦은 배송 이벤트가 도착하면 합계를 고칠 수 있을까?첫 번째 질문에는 체크포인트가 답한다. 체크포인트는 입력 위치와 연산 상태를 함께 저장해 복구 지점을 만든다. 두 번째 질문에는 윈도우와 워터마크가 답한다. 윈도우는 이벤트를 집계할 구간을 정하고, 워터마크는 이벤트 시간이 어디까지 진행됐는지 알려 준다.1. 체크포인트는 입력 위치와 연산 상태를 함께 저장한다Kafka 파티션 하나에서 오프셋 40의 수량 7과 오프셋 41의 수량 5를 처리했다고 하자. 이때 체크포인트에는 창고의 누적 합계 12와 다음에 읽을 오프셋 42가 저장된다. 작업이 오프셋 42의..

Flink DataStream API는 이벤트의 흐름에 변환을 연결하고, 필요한 경우 이전 이벤트의 정보를 상태로 유지하는 API다. 한 레코드의 값을 바꾸는 것부터 키별 누적 집계, 여러 입력의 연결, 사용자 정의 상태 처리까지 구성할 수 있다.핵심은 메서드 이름을 많이 외우는 데 있지 않다. 입력 한 건이 몇 건으로 바뀌는지, 같은 키가 어디로 모이는지, 어떤 정보를 기억하는지, 결과가 새 행인지 기존 값의 갱신인지를 구분해야 한다. 이 글은 작은 유한 입력에서 시작해 Table API와 Kafka 집계까지 연결한다.코드는 Flink·PyFlink 2.2.1의 Python DataStream API를 기준으로 한다. 공식 문서는 2026-11-05에 확인했다. 순수 Python으로 검산한 예제값과 P..

Kafka에 데이터를 쌓는 것과 그 데이터를 계속 계산하는 것은 다른 역할이다. Kafka가 이벤트를 보관하고 전달하는 로그라면, Flink는 들어오는 이벤트를 변환하고 상태를 유지하며 결과를 갱신하는 분산 처리 엔진이다.예를 들어 주문 이벤트를 Kafka에 저장하는 것만으로 사용자별 누적 주문액이 계산되지는 않는다. Flink 작업이 이벤트를 읽고, 유효한 주문을 골라 사용자별 상태를 갱신한 뒤 결과를 저장해야 한다. Source → Transformation → Sink가 이 작업의 기본 구조다.이 글은 Flink·PyFlink 2.2.1, Java 17, Python 3.11을 기준 조합으로 사용한다. 최신 버전이라는 뜻이 아니라 설명과 코드의 기준을 고정한 것이다. 공식 문서는 2026-11-05..

Kafka 브로커가 실행 중이라는 사실만으로 데이터 파이프라인이 정상이라고 판단할 수는 없다. 브로커는 살아 있어도 컨슈머 처리가 멈추거나, 한 파티션에만 데이터가 몰리거나, 복제 사본이 뒤처질 수 있다.모니터링은 어느 경계에서 무엇이 늦어지는지 구분하고 다음 행동을 정하는 일이다. 랙, 요청 지연, 복제 상태, 업무 완료 지표를 연결하고 JMX Exporter → Prometheus → Grafana와 Kafka Exporter의 역할을 구분해 보자.Kafka 지표 설명은 4.1 공식 문서를 기준으로 하며, 외부 도구의 문서는 2026-11-05에 확인했다. 아래 구성은 로컬 실습용 예시로, 모니터링 서버를 실제 기동한 결과를 제시하는 글은 아니다.1. 지표에 측정 경계를 붙인다같은 latency라는 ..

Kafka 성능 최적화는 처리량 숫자 하나를 키우는 작업이 아니다. 같은 입력을 허용 지연과 데이터 보존 조건 안에서 처리할 수 있는지 확인하고, 병목이 있는 경계의 설정을 바꾸는 작업이다.프로듀서의 배치를 키워 전송 효율을 높여도 컨슈머의 DB 쓰기가 느리다면 전체 처리는 빨라지지 않는다. 반대로 확인 응답을 줄여 얻은 속도는 기존과 같은 안정성 조건에서 얻은 개선이 아니다. 여기서는 주문 이벤트가 프로듀서 → 브로커 → 컨슈머 → 업무 저장소로 흐르는 상황을 기준으로 튜닝 순서를 정리한다.설정 이름은 별도 표시가 없으면 Kafka 4.1 Java 클라이언트 기준이다. Python 클라이언트는 뒤에서 구분한다. 공식 문서 확인 기준일은 2026-11-05다.1. 먼저 무엇을 개선할지 정한다같은 “초당 ..

지하철 노선도 한 장을 보고 두 가지 질문을 받았다고 생각해 보자.“빨간색 노선은 무엇인가?”“A역에서 B역까지 가려면 어디에서 갈아타야 하는가?”같은 그림이지만 필요한 처리는 다르다. 첫 질문은 색과 노선 이름을 연결하면 된다. 두 번째 질문은 역과 노선의 연결 관계를 따라가야 한다.AI도 질문에 따라 그림을 처리하는 방식을 바꿀 수 있을까? 복잡한 질문에는 시각 정보를 조금 더 처리하게 할 수 있을까?AdaLoop는 질문에 맞춰 비전 인코더의 계산을 조절하고, 일부 층을 반복 사용해 내부 시각 정보를 갱신하는 방법이다. 언어 모델이 답을 길게 생각하도록 하는 것과 함께, 그 앞의 시각 처리에도 추가 계산을 배분한다.이 글은 Han 등의 공개 논문 AdaLoop: Thinking with the Vis..

이미지를 보고 자연스러운 설명을 만드는 모델이 있다고 하자. 그런데 메뉴판에 적힌 가격을 바꿔도 답변이 그대로라면, 이 모델은 이미지를 얼마나 읽고 있는 것일까?이번 AI 스터디에서는 Kanana-2 Vision Encoder를 공부하고 비평가 역할을 맡았다. 흥미로웠던 부분은 성능 점수 자체보다, 그 점수와 학습 곡선이 어디까지 설명해 주는지를 따져 보는 과정이었다.이 글에서는 카카오가 공개한 개발 방식과 결과를 먼저 살펴보고, 스터디에서 정리한 여섯 가지 질문을 이어서 다룬다. 카카오의 공식 개발기와 모델 카드, 개발기가 인용한 GenLIP 논문을 함께 참고했다. GenLIP는 Kanana 자체를 설명하는 논문이 아니라 별도의 기반 연구다. 아래 수치는 각 자료의 보고값이며 직접 재현한 측정치는 아니..

Kafka에서 send()나 produce()를 호출했다고 곧바로 업무 처리가 끝난 것은 아니다. 프로듀서가 전송을 준비한 시점, 브로커가 레코드를 받아들인 시점, 컨슈머가 업무를 처리한 시점, 처리 위치를 커밋한 시점은 서로 다르다.중복과 누락을 이해하려면 이 경계를 나눠 봐야 한다. 이 글에서는 orders 토픽의 주문 이벤트를 예로 프로듀서의 전송·확인 응답·멱등성, 컨슈머의 그룹·리밸런싱·커밋을 연결하고 Python 예제로 마무리한다.1. 프로듀서는 레코드를 어떻게 보내는가프로듀서는 애플리케이션의 데이터를 Kafka 레코드로 만들어 보낸다. 레코드에는 토픽, 키, 값, 선택적인 파티션·타임스탬프·헤더 등이 들어갈 수 있다.topic: orderskey: order-Avalue: {"event_id..