Lambda의 Kafka Queue 모드: 파티션보다 많이 병렬 처리해도 되는 일

새 모드가 풀어 주는 제약

AWS는 2026년 11월 2일 Lambda의 self-managed Apache Kafka 이벤트 소스 매핑에 Queue 소비 모드를 발표했다. 이벤트 소스 매핑은 Kafka에서 레코드를 읽고 함수를 호출하는 연결이다. 이번 지원 조건은 Share Group을 켠 Kafka 4.2 이상이다. 여기서 self-managed에는 AWS 밖의 관리형 Kafka도 포함되지만, 이 발표를 Amazon MSK의 동일 기능 지원으로 확대해 읽어서는 안 된다. AWS 발표, Lambda의 self-managed 정의

기본 Stream은 유지되며 새 Queue를 선택해야 소비 방식이 달라진다. Stream은 파티션 안의 순서를 보존하는 처리에, Queue는 서로 독립적인 레코드의 병렬 처리에 맞는다. 같은 토픽에 두 종류의 매핑을 별도로 둘 수도 있다. 따라서 모든 생산자와 토픽을 한꺼번에 바꾸는 문제보다 어떤 소비 업무를 옮길지가 먼저다. 모드 비교

이 글은 11월 3일 확인한 공식 문서와 자체 설계 사례의 분석이다. 실제 Kafka·Lambda를 설치하거나 호출하지 않았다. 아래 결과표는 가상의 이벤트를 작은 로컬 상태 모형에 적용한 결과이며, 서비스 처리량이나 장애 복구를 측정한 표가 아니다.

파티션을 맡기는 대신 레코드를 나눠 맡긴다

일반적인 Consumer Group에서는 한 파티션을 그룹 안의 한 소비자에게 배정한다. Share Group은 같은 파티션을 여러 소비자가 함께 읽고, 가져간 레코드마다 처리 확인을 남기게 한다. 그래서 소비자 수를 파티션 수보다 늘릴 수 있다. Kafka에 새로운 종류의 저장 토픽을 만드는 것이 아니라 기존 토픽을 소비하는 규칙을 추가하는 것이다. Apache KIP-932의 설계

예를 들어 한 파티션에 사진 A·B·C의 변환 요청이 들어왔다고 하자. A가 큰 파일이라 오래 걸릴 때 B·C의 처리를 다른 소비자가 맡을 여지가 생긴다. 이것이 유용하려면 B의 결과를 먼저 저장해도 A의 결과가 틀어지지 않아야 한다. 반대로 “주문 생성 → 결제 완료 → 취소”는 각 레코드가 서로 다른 상태를 전제로 삼을 수 있다. 파티션에 기록된 순서가 남아 있어도 여러 작업의 완료 순서는 달라질 수 있다.

위 그림은 직접 그린 개념도다. A·B·C의 배정 방식이나 실행 시간은 실제 스케줄러 관측이 아니다.

중복에 안전해도 역순에는 틀릴 수 있다

Lambda의 Kafka 이벤트 소스 매핑은 최소 한 번 처리를 전제로 하며 중복이 생길 수 있다. 함수의 효과를 멱등하게 만드는 것이 기본 권고다. 멱등성이란 같은 요청을 여러 번 적용해도 효과가 한 번 적용한 것과 같도록 설계하는 성질이다. Lambda 문서

그러나 같은 요청을 두 번 받는 문제와 서로 다른 요청이 거꾸로 끝나는 문제는 별개다. 다음은 상품 대표 이미지의 버전을 바꾸는 가상 사례다.

• 이벤트 A: 상품 P의 대표 이미지를 버전 1로 지정한다.
• 이벤트 B: 같은 상품 P의 대표 이미지를 버전 2로 지정한다.
• 기대 결과: 두 이벤트가 끝나면 대표 이미지는 버전 2다.

“대표 이미지 값을 이 버전으로 덮어쓴다”는 연산은 같은 이벤트를 반복하면 값이 그대로다. 하지만 B 뒤에 A가 끝나면 버전 1로 돌아간다. eventId로 중복만 제거해도 A와 B는 서로 다른 이벤트라 둘 다 통과한다.

자체 상태 모형에 넣은 순서	단순 덮어쓰기의 최종 버전	더 큰 버전만 반영하는 모형
A → B	2	2
B → A	1	2
A → B → A 재전달	1	2
B → A → B 재전달	2	2

로컬에서는 위 네 순서를 실제 계산했다. 오른쪽은 상품별로 더 큰 버전만 받아들이는 순수 함수 모형이며, DB에서 경쟁하는 두 트랜잭션을 실행한 결과가 아니다. 실서비스에서는 버전 비교와 갱신을 원자적으로 묶어야 한다. 먼저 읽고 나중에 무조건 쓰면, 두 작업이 모두 옛 버전을 보고 통과할 수 있다.

또한 버전 비교가 모든 업무를 해결하지 않는다. 최신 상태 하나만 필요할 때 오래된 상태를 무시하는 방법이다. 버전 1의 작업이 배송 시작이고 버전 2가 취소라면, 배송 자체를 생략해도 되는지 또는 이미 일어난 배송을 어떻게 취소할지 별도 업무 규칙이 필요하다. 모든 전이를 반드시 수행해야 하는 장부·예약 절차에는 순서 보존이나 명시적인 상태 전이 검사가 더 적합할 수 있다.

이미지 변환도 두 단계로 나눠 봐야 한다

쇼핑몰의 사진 업로드 파이프라인을 설계한다고 하자. 먼저 원본에서 작은 이미지를 만들고, 그다음 상품 페이지가 사용할 대표 이미지 주소를 바꾼다. 두 단계는 순서 요구가 다르다.

처리 단위	Queue 적합성을 판단할 조건	먼저 남길 결과
버전이 고정된 원본의 작은 이미지 생성	다른 사진의 변환 완료 순서와 무관한가?	상품/원본버전/변환규격버전별 결과
생성된 이미지를 현재 대표 이미지로 지정	옛 업로드가 늦게 끝나도 최신 선택을 덮지 않는가?	현재 선택 버전과 원자적 갱신 결과
“완료됐다”는 알림 전송	재전달 때 같은 고객에게 중복 발송하지 않는가?	알림 업무 키와 발송 결과

이는 AWS가 제공하는 샘플 구현이 아니라 독립성을 점검하기 위한 설계안이다. 변환 결과를 버전별 주소에 쓰면 A·B의 파일 생성은 서로 간섭하지 않게 만들 수 있다. 하지만 같은 current.jpg를 덮어쓰면 다시 순서 문제가 생긴다. 이미지 변환이라는 작업 이름만으로 독립성을 결정할 수 없다. 출력 주소와 그 결과를 채택하는 방식까지 봐야 한다.

중복 방지 키도 같은 관점에서 정한다. 원본 ID만 쓰면 새 크롭 규격으로 다시 만드는 정상 작업까지 중복으로 거절할 수 있다. 반대로 매 재시도마다 새 키를 만들면 같은 작업을 알아보지 못한다. 이 사례의 키에는 상품·원본 버전·변환 규격 버전을 함께 넣고, 입력이 같아도 변환기가 바뀌면 새 결과로 취급할지 정한다.

완료 표시를 먼저 쓰고 파일 저장 전에 죽으면 재전달이 필요한 작업을 건너뛴다. 파일을 저장한 뒤 완료 표시 전에 죽으면 같은 작업이 다시 실행될 수 있다. 버전별 출력의 조건부 생성, 진행 중 상태의 만료, 실제 파일 확인 같은 복구 설계가 필요한 이유다. DB 기록과 외부 효과를 함께 다루는 문제는 트랜잭셔널 아웃박스 글에서 이어 볼 수 있다.

레코드가 다시 오지 않는다고 업무 성공은 아니다

Share Group은 레코드의 사용 가능·획득·확인·보관 상태를 관리한다. 획득에는 시간 제한이 있는 잠금이 붙고, 처리 실패나 잠금 만료 시 다시 전달될 수 있다. 거절되거나 전달 한도에 도달한 레코드는 더 이상 전달하지 않는 상태가 될 수 있다. 여기서 Archived는 성공했다는 뜻도, 별도 복구 큐에 복사됐다는 뜻도 아니다. KIP-932의 레코드 수명

Lambda 발표는 처리 중 잠금 갱신과 실패 후 재전달을 설명한다. 재시도에는 Lambda 설정과 브로커의 전달 횟수 한도가 함께 관여하며, 소진된 실패를 받을 목적지도 따로 구성한다. 따라서 함수의 재시도 설정 하나만으로 무한 복구를 가정하지 않는다. 실패 처리와 브로커 조건

이미지 사례에서 운영자가 알아야 하는 것은 “대기량이 줄었다” 하나가 아니다. 각 작업이 결과 파일을 만들었는지, 오래된 버전이라 대표 이미지 반영에서 제외됐는지, 복구 대상으로 남았는지를 나눠야 한다. 오래된 버전이라 반영하지 않은 일은 의도한 완료일 수 있다. 변환 중 오류로 파일이 없는 일과 같은 실패 코드로 묶으면 재처리할 대상을 고르기 어렵다.

기존 토픽에서 시험할 때의 순서

첫 시험은 전체 주문 흐름보다 버전이 고정된 이미지 생성처럼 결과를 별도로 대조할 수 있는 업무가 적합하다. 다음은 실제 실행을 마쳤다는 목록이 아니라 독자가 자기 환경에서 사용할 인수 절차다.

1. 지원 범위를 확인한다. Lambda의 self-managed 연결, 브로커의 Share Group 설정, 사용하는 클라이언트·관리형 공급자의 지원을 기록한다. Kafka 4.2 업그레이드 문서는 Queue의 운영 사용 준비 상태를 명시하고, 4.2.1에는 Share Group 경로의 교착 수정도 적고 있다. 최소 기능 버전 충족과 패치 선택은 별도로 검토한다. Kafka 4.2 업그레이드 문서
2. 운영 효과가 없는 출력으로 분리한다. 기존 Stream 소비와 새 Queue 소비가 같은 토픽을 읽더라도 두 경로가 같은 고객 알림·대표 이미지 갱신을 수행하지 않게 한다. 별도 그룹은 업무 중복 제거를 공유한다는 뜻이 아니다.
3. 동일 입력·역순·재전달을 비교한다. 위 A·B 사례처럼 기대 결과를 먼저 적는다. 파일 저장 직후 실패, 완료 기록 직전 실패, 오래된 입력의 재전달을 추가한다. 순수 함수 모형이 통과한 뒤 실제 저장소의 경쟁 조건도 시험한다.
4. 처리 수보다 결과를 대조한다. 고유 작업별 결과 파일, 현재 버전, 반영 제외 이유, 복구 대상의 합이 입력과 맞는지 본다. 레코드 재전달 횟수와 실제 중복 효과를 같은 지표로 세지 않는다.
5. 옮길 범위와 되돌릴 범위를 정한다. 무해한 출력 시험이 통과한 업무만 전환한다. 되돌릴 때도 시작 위치·이미 처리한 업무 키·남은 복구 대상을 대조해야 한다. 소비 방식을 바꾸는 것만으로 외부에 만든 효과가 사라지지는 않는다.

Queue가 파티션에 따른 병렬성 제약을 완화해도 DB 연결 수나 이미지 저장소, 외부 API의 처리 한도가 늘지는 않는다. 느린 의존성 앞에 더 많은 호출을 쌓으면 재시도까지 더해질 수 있다. 실제 시험에서는 고유 작업 완료 지연, 외부 제한 응답, 중복 효과, 재처리 누락을 함께 관측하고 동시 실행을 조절한다. 이 제어의 원리는 백프레셔와 숨은 작업 대기열과 연결된다.

Kafka Queue 전환 검토 기록지에 독립성·버전·중복 키·실패 지점을 한 작업씩 적을 수 있다. 테크독해가 만든 빈 양식이며 공식 설정 파일이나 실행 도구는 아니다. 사진 생성과 대표 이미지 반영을 별도 행에 적는 것부터 시작하면, 병렬화할 부분과 순서가 필요한 부분을 팀에서 같은 기준으로 논의할 수 있다. 다시 검토할 때는 글의 저장 기능이나 소프트웨어 주제 모음을 이용할 수 있다.