카프카 설정 복붙,
이번 4주로 끝냅니다.
“써봤습니다”에서 멈추면 코드 리뷰에서도, 설계 회의에서도, 면접에서도 매번 같은 데서 말문이 막힙니다. 설정 한 줄이 뭘 지키고 뭘 포기하는지 말할 수 있어야 그 순간을 넘어섭니다.
카프카를 매일 쓰는 사람도, 이제 막 배우는 사람도. 4주 뒤엔 설정 앞에서 먼저 입을 엽니다.
카프카를 이제 막 배우는 주니어부터 매일 쓰는 실무자까지, “이 설정이 지키는 게 뭐죠?”에 본인 근거로 답하게 되는 4주.
꼬리질문이 들어올수록,
오히려 답변이 단단해집니다.
장애 대응, 설계 회의, 그리고 면접. 시니어와 갈리는 건 늘 이 순간들이에요. 필요한 건 같은 판단력 하나인데, 그게 없으면 매번 같은 데서 막힙니다. 4주 동안 그 판단력을 같이 만듭니다.
- ✓“Kafka가 왜 큐가 아니라 로그인가”를 한 단락으로 설명합니다
- ✓유실 · 중복 · 순서 · exactly-once는 양 끝의 설정과 처리로 직접 조립합니다
- ✓“acks=all이 정확히 뭘 보장하나”에 설정 복붙 없이 답합니다
- ✓세그먼트 · 페이지캐시 · ISR · High Watermark가 한 로그 모델 위에 연결됩니다
- ✓acks · min.insync.replicas · commit 시점을 유실 · 중복 · 지연의 좌표로 읽습니다
- ✓1,000건이 1,003건 처리되고 998건만 도착한 사고를 설정의 언어로 재구성합니다
- ✓파티션 키가 순서와 처리량 사이에서 무엇을 골랐는지 짚어냅니다
- ✓"일단 all로 두죠"를 넘어, 우리 서비스에 맞는 설정 한 벌과 근거를 남깁니다
아는 단어가 늘어나는 게 아니라,
답변의 구조가 바뀝니다.
외운 정의를 꺼내는 답에서, 우리 서비스의 요구와 포기한 것을 함께 말하는 답으로 옮겨갑니다.
“비동기 처리가 필요해서 Kafka를 썼습니다.”
“한 이벤트를 정산 · 알림 · 분석이 각자 속도로 다시 읽어야 했습니다. 파괴적 소비보다 보존과 재생이 중요해 로그를 골랐습니다.”
“모든 복제본에 저장되니까 유실되지 않습니다.”
“현재 ISR 전체의 확인일 뿐입니다. min.insync.replicas와 unclean leader election까지 같이 봐야, 어떤 장애에서 쓰기를 거절하고 어떤 장애에서 유실을 허용하는지 말할 수 있습니다.”
“Kafka를 썼습니다”는 한 줄이,
준비되지 않으면 꼬리질문 네 개가 됩니다.
이력서에 Kafka를 적은 순간, 면접관은 사용법이 아니라 결정을 확인합니다. “비동기 처리를 위해 썼습니다”라는 답은 종료가 아니라 꼬리질문의 시작입니다.
머릿속에는 topic · partition · consumer group · acks가 있습니다. 그런데 내 서비스에서 무엇을 지키려고 그 설정을 골랐는지는 말할 수 없습니다.
문제는 Kafka 경험이 부족한 게 아닙니다. 설정을 적용해 봤지만, 유실 · 중복 · 지연 · 순서 사이에서 내 이름을 걸고 결정해 본 적이 없는 상태입니다.
같은 장면은 설계 회의에서도 반복됩니다. “일단 acks=all로 가죠” 다음의 이유를 시니어가 말할 때, 우리는 다시 노트북만 봅니다.
4주 뒤에는 먼저 입을 엽니다. “우리 결제 이벤트는 중복 비용보다 유실 비용이 커서, 여기서 쓰기를 거절하는 쪽을 고르겠습니다.” 이 한 문장을 본인 근거로 만드는 것이 이 스터디의 결과입니다.
맞지 않을 수도 있어요. 시간을 아껴드릴게요.
- ✓Kafka를 이제 배우기 시작한 주니어. 1주차가 "로그"라는 멘탈 모델부터 다시 세우니, 처음부터 올바른 모델로 코어를 파고 싶은 분
- ✓곧 팀에 메시징(Kafka)을 들여야 하는데, 파티션 수 · 키 · acks를 무슨 근거로 정할지 막막한 분
- ✓Kafka를 매일 쓰지만 유실 · 중복 장애를 설정 복붙으로 넘겼고, "acks=all이 정확히 뭘 보장하나"에 답이 막히는 실무자
- ✓토픽 · 파티션 · 오프셋을 쓰면서도 왜 이렇게 설계됐는지가 늘 궁금했던 분
- ✗이미 로그 세그먼트 · 복제 프로토콜 레벨로 익숙한 시니어. 이 4주는 좀 얕을 거예요
- ✗Streams · Connect 같은 생태계 도구의 사용법을 기대하는 분. 이 4주는 코어의 설계를 팝니다
- ✗"면접 합격"이 단일 목표인 분. 판단력을 같이 깎는 시간이라 면접은 부수효과
4주 라이브, 탄생부터 확장까지. 소수 정원 그룹 스터디.
혼자 듣는 강의가 아니라 소그룹으로 같이 걷는 그룹 스터디예요. 아래 골격으로 준비 중이고, 일정 · 정원 확정치는 모집 공지에서 안내드려요.
탄생, 깊이, 생존, 확장 네 테마를 한 주에 하나씩 갑니다. 시작일과 요일은 모집이 열릴 때 확정해 안내드려요.
1기(Redis)와 같이 메타버스 Zep에서 모이는 방향으로 준비하고 있어요. 같은 화면을 같이 펼쳐 읽는 결을 살리기 위해서예요.
1기와 같은 그룹 스터디 구조(그룹당 5명 안팎)로 준비 중입니다. 확정 정원은 모집 공지에서 안내드려요.
한 결정을 세 번 만납니다.
결과 → 근거 → 철학.
기능을 차례로 나열하지 않습니다. LinkedIn이 내린 같은 설계 결정을 장애의 결과로 먼저 만나고, 소스와 1차 사료로 근거를 확인한 뒤, 마지막에 무엇을 포기한 설계인지로 닫습니다.
결과로 만난다
1,000건이 1,003건과 998건으로 어긋난 새벽 장애에서 시작합니다. 답을 먼저 주지 않고, 큐 멘탈 모델이 막히는 지점을 남깁니다.
→근거로 내려간다
LinkedIn의 N×M 파이프라인, 로그 선택, 세그먼트, 페이지캐시, ISR과 High Watermark까지 설계 결정의 밑면을 엽니다.
→철학으로 닫는다
end-to-end argument와 복제 로그의 철학 위에서 acks · ISR · commit을 한 좌표맵으로 묶고, 첫 사고의 설정 한 벌을 직접 고릅니다.
블로그 몇 편을 요약한 4주가 아닙니다.
설정의 이유를 말하려면 만든 사람의 문제, 실제 소스의 불변식, 그 뒤의 CS 원리가 한 줄에 이어져야 합니다.
버전에 따라 달라진 기본값과 소스 경로를 섞지 않습니다.
블로그의 요약 대신 설계자와 공식 문서의 원문을 따라갑니다.
가설 → 비교 → 좌표 루프를 Kafka의 실패모드에 맞게 다시 설계했습니다.
역사 · 철학
Jay Kreps는 왜 큐를 버리고 로그를 골랐을까요? LinkedIn 데이터 파이프라인이 무너지던 순간의 실제 의사결정들을 1차 사료로 따라가요.
"The Log: What every software engineer should know about real-time data's unifying abstraction"
— Jay Kreps, 2013
내부 구조 · 불변식 · 실패모드
브로커가 디스크에 로그를 쌓는 법, 복제가 지키는 불변식, 깨질 때 나오는 신호와 복구 경로. 시스템 디자인 lens로 본체를 따라가고, 소스와 설정은 결정의 증거로 짧게 인용해요.
세그먼트 · 인덱스 · ISR · High Watermark · __consumer_offsets · 제로카피
— Kafka 내부 결정의 표면들
CS 브릿지
end-to-end argument, 로그 복제와 합의 알고리즘의 관계, 순차 I/O와 OS 페이지캐시. 교과서와 원논문이 실물에 붙는 순간을 봐요.
"End-to-End Arguments in System Design"
— Saltzer · Reed · Clark, 1984
한 사고에서 시작해, 설계 철학까지 한 줄기로 내려갑니다.
기능 목록 순서가 아닙니다. 1주에 큐 멘탈 모델을 깨고, 2주에 메시지 한 건이 디스크와 복제를 지나는 경로를 엽니다. 3주에 첫 사고의 유실과 중복을 판결하고, 4주에 순서와 end-to-end 설계 철학으로 전체 설정을 하나의 좌표맵에 묶습니다.
메시지가 사라지고 중복됐다 · 큐가 아니라 로그다
이 주의 문제 · 성숙한 메시지 큐들이 이미 있었는데, LinkedIn은 왜 새로 만들었나
- 케이스 1 · 새벽 두 시의 정산. 발생한 결제는 1,000건. 그런데 정산 테이블에는 1,003건(3건 중복), 결제사 캡처는 998건(2건 유실). 프로듀서 · 브로커 · 컨슈머 중 어디부터 의심하나. 이 사고는 미끼라서, 3주차에 설정의 언어로 되찾으러 옵니다.
- 케이스 2 · 컨슘했는데 메시지가 남아 있다. 큐 멘탈 모델이 처음 깨지는 순간. 파괴적 소비 vs 비파괴적 읽기, 오프셋은 받는 게 아니라 읽는 위치를 옮기는 것.
- 케이스 3 · LinkedIn의 N×M 폭발. 시스템 N개와 소비자 M개를 전부 이으면 파이프라인이 몇 개 생기나. Jay Kreps가 로그라는 추상에 도달한 경로(The Log).
- 케이스 4 · 새로 온 팀이 지난주 데이터를 처음부터 읽고 싶다. 큐는 못 주는 능력. 컨슈머 그룹, 같은 로그를 각자의 속도와 독립 시선으로 읽는다.
주차 산출물: 카프카를 "로그" 한 단어 위에서 다시 설명하는 한 장
send() 한 줄이 팔로워의 디스크까지. 그리고 왜 빠른가
이 주의 문제 · 디스크에 쓰는데 왜 인메모리급으로 빠른가
- 케이스 1 · send() 했는데 아직 안 갔다. batch.size와 linger.ms가 만드는 대기. 지연을 내주고 처리량을 사는 첫 트레이드오프.
- 케이스 2 · 브로커 디스크 디렉터리를 직접 연다. .log와 .index와 .timeindex, 파일명이 곧 baseOffset. 왜 파일 하나가 아니라 세그먼트로 쪼개고, 인덱스는 왜 촘촘하지 않고 듬성듬성한가(sparse).
- 케이스 3 · 자체 캐시를 안 만든 결정. 순차 I/O, OS 페이지캐시에 올라타기, 제로카피. "디스크는 느리다"가 참인 조건과 거짓인 조건.
- 케이스 4 · 팔로워가 ISR에서 빠졌다. 그 순간 리더가 죽으면. fetch 기반 복제, LEO와 High Watermark. 컨슈머에게 보여줄 수 있는 경계선은 누가 정하나.
주차 산출물: 메시지 한 건이 지나는 전 구간 도해 (본인 손으로 그린 것)
유실의 정체 · 중복의 정체
이 주의 문제 · 유실과 중복은 버그가 아니라 설정으로 고른 트레이드오프다
- 케이스 1 · ack 받았는데 사라졌다. acks=1에서 리더 교체가 겹치는 정확한 타이밍을 재구성한다. acks=all이면 정말 안 사라지나.
- 케이스 2 · acks=all인데도 사라졌다. min.insync.replicas 없는 반쪽 보장, 그리고 unclean leader election. 가용성을 위해 유실을 허용하는 결정은 언제 정당한가.
- 케이스 3 · 컨슈머 재배포마다 같은 메시지를 또 처리한다. 커밋을 처리 앞에 두면 유실, 뒤에 두면 중복. 자동 커밋의 함정, __consumer_offsets도 결국 로그다.
- 케이스 4 · 재시도가 만든 중복. 멱등 프로듀서(PID · epoch · sequence)와 트랜잭션. exactly-once는 어디까지 보장이고 어디부터 마케팅인가.
- 케이스 5 · 1주차 사고의 범인 지목. 새벽 두 시의 정산(발생 1,000 · 정산 1,003 · 결제사 998)을 설정의 언어로 다시 읽고 범인을 가려낸다.
주차 산출물: 유실 · 중복 설정 좌표 초안 (acks · min.insync.replicas · 커밋 시점)
순서의 정체 · 왜 이렇게 설계됐나
이 주의 문제 · 전역 순서를 포기하면서 카프카는 무엇을 샀나
- 케이스 1 · 결제완료가 주문생성보다 먼저 도착했다. 키 없는 send가 라운드로빈으로 흩어질 때. 파티션 안 순서로 충분한 시나리오와 부족한 시나리오, 키 설계.
- 케이스 2 · 특정 파티션만 터진다. 대형 고객 키가 몰리는 핫 파티션. 키 설계를 바꾸면 무엇이 같이 바뀌나.
- 케이스 3 · 브로커는 왜 이렇게 단순한가. 필터링도 변환도 안 해주는 이유. end-to-end argument로 4주간 본 결정을 전부 다시 읽는다.
- 케이스 4 · 카프카 복제는 합의인가. 로그 복제와 Raft가 어디까지 같고 어디서 갈라지나. KRaft가 온 이유.
주차 산출물: 본인 서비스 기준 설정 좌표맵 v1 (유실 ↔ 지연 ↔ 중복)
사전 → 라이브 → 사후. 이 흐름이 4주 반복됩니다.
사전 자료에서 가설을 세우고, 라이브에서 동료들과 비교하며 다듬고, 정리 한 장으로 남깁니다. 주차가 끝날 때마다 산출물이 하나씩 쌓여요.
주중 사전 (자료 + 가설)
- ·해당 주 사전 자료 읽기
- ·이번 주 결정 지점 4~5개에 본인 답 가설을 적어 라이브 전에 제출합니다. 라이브에서 동료들과 공유하고 비교합니다. 코드는 안 짜와도 됩니다.
평일 저녁 2시간 (대화 · 도해 · 토론)
- ·타자 치는 시간은 없습니다. 직면, 가설 공유 · 비교, Kafka의 답 같이 읽기, 무너진 길, 좌표 정리, 회고의 흐름으로 갑니다.
- ·설정과 코드는 같이 펼쳐 읽는 소재예요. 결정이 담긴 줄마다 멈춰 "왜 이렇게 했나, 우리 가설대로면 어디가 달랐나"를 룸 전체가 짚어요.
- ·진행자 30%, 참가자 70%. 도해와 워크스루는 진행자가 끌고, 토론과 결정은 참가자가 주도합니다.
주중 사후 (정리 한 장)
- ·매주 정리 한 장을 제출합니다. 그 주에 본 결정을 본인 노트에 어떻게 담았는지 한 장으로.
- ·동료의 정리에 코멘트 남기기.
- ·(선택) 더 파보고 싶으면 로컬 클러스터에서 설정을 바꿔 가며 직접 실험해 보기. 안 해도 완주에 지장 없습니다.
모집이 열리는 날,
가장 먼저 알려드립니다.
지금은 결제가 아니라 무료 사전예약입니다. 시작일 · 정원 · 가격이 확정되면 사전예약자에게 가장 먼저 메일로 안내드립니다.
카카오 로그인 한 번이면 예약 완료.
결제도, 참가 확정도 아닙니다. 모집이 열리면 예약해 두신 계정 메일로 일정 · 정원 · 가격을 가장 먼저 안내드려요.
- ✓전자책(카프카 딥다이브) + 4주 라이브가 한 묶음입니다
- ✓라이브는 대화 전용. 코드는 같이 읽는 소재이고 타자 치는 시간은 없습니다
- ✓그릿 모먼츠 동문은 50% 할인 (시리즈 공통)
- ✓1주차 라이브 시작 전 100% 환불 원칙 (1기와 같은 원칙으로 준비)
- ·시작일과 요일
- ·가격 (참고로 1기 Redis 4주는 139,000원이었어요)
- ·확정 정원
자주 묻는 질문.
사전예약하면 뭐가 되는 건가요?+
결제나 참가 확정이 아니라 무료 우선 안내 명단에 이름을 올리는 것입니다. 시작일 · 정원 · 가격이 확정되어 모집이 열리면 예약하신 계정 메일로 가장 먼저 안내드려요. 2기도 1기처럼 소수 정원 선착순으로 진행될 예정이라, 합류를 고민 중이시라면 예약해 두시는 걸 권해요.
면접 대비용 스터디인가요?+
면접 빈출 문제를 외우는 반은 아닙니다. 다만 Kafka 면접에서 점수가 나는 답은 기능 정의가 아니라 우리 요구에서 무엇을 지키고 무엇을 포기했는지를 말하는 답입니다. 매주 장애 케이스에 가설을 적고 동료와 비교하는 이유가 바로 그 답변 구조를 만들기 위해서예요.
라이브에서 코드를 직접 짜나요?+
아니요. 라이브 2시간은 전부 대화 · 도해 · 토론입니다. 설정과 코드는 같이 펼쳐 읽는 소재예요. 결정이 담긴 줄마다 멈춰 "왜 이렇게 했나"를 짚습니다. 직접 실험해 보고 싶으면 사후 선택 과제로 로컬 클러스터를 만져 보세요 (완주에 지장 없음).
Kafka를 실무에서 안 써봤어도 따라갈 수 있나요?+
네. 1주차(탄생)가 로그라는 멘탈 모델과 기본 부품부터 다시 세우는 이유가 그거예요. 써본 분에게는 본인이 겪은 장애가 최고의 교재가 되고, 안 써본 분에게는 처음부터 올바른 모델로 시작하는 기회가 됩니다.
1기(Redis)를 안 들었는데 2기부터 들어도 되나요?+
네. 각 권은 독립적입니다. 시리즈가 쌓아 가는 건 특정 도구 지식이 아니라 트레이드오프를 읽는 판단의 어휘라서, 어느 권에서 시작해도 그 권 안에서 완결돼요.
Java나 Scala를 몰라도 되나요?+
네. 라이브에서 코드를 짜지 않으니 어떤 언어를 써왔든 상관없어요. 모르는 언어의 코드에서도 "여기서 무슨 결정을 했나"를 읽어내는 게 이 스터디가 훈련하는 근육입니다.
Streams나 Connect도 다루나요?+
아니요. 이 4주는 코어(로그 · 저장 · 복제 · 전달 보장)의 설계를 팝니다. 코어를 이 깊이로 이해하고 나면 Streams · Connect 같은 생태계 도구는 공식 문서로 따라갈 수 있는 층이 돼요.
전자책만 따로 살 수 있나요?+
카프카 딥다이브 전자책은 스터디 오픈에 맞춰 「코기토 서재」 단품 판매를 준비하고 있어요. 이 페이지는 스터디 합류(전자책 + 4주 라이브) 기준 안내입니다.
그릿 모먼츠 동문 할인은 어떻게 적용되나요?+
그릿 모먼츠를 완주하셨다면 자동 50% 할인입니다. 모집이 열리면 결제 화면에서 같은 카카오 계정으로 로그인하시면 자동 적용돼요.
4주 후 손에 남는 것은 설정 모음집이 아니라,
새 시스템 앞에서도 트레이드오프를 읽어내는 본인입니다.
2기 사전예약 오픈 · 시작일 · 가격은 모집 공지에서 확정 · 사전예약자에게 가장 먼저 안내드려요.
2기 사전예약하기 →