“왜 Kafka였나요?”
이 질문을 기다리게 됩니다.
사용 경험을 설계 근거로 바꾸는 4주. 꼬리질문에 막히던 순간마다 내 답이 생깁니다.
카프카 공부는 반드시
엔지니어링 문제와 같이 가야 합니다.
이 산 하나를 넘으면 분산 시스템이 통째로 만만해집니다.
한 번 통과하면 뒤에 있던 문들이 순서대로 열립니다.
이력서의 Kafka 한 줄은 배점이 큰 문항입니다.
준비하고 들어가면 그날 최고점이 되고, 준비 없이 들어가면 그날 최대 감점이 됩니다.
아래 문제들, 바로 답할 수 있나요?
“결제는 됐다고 나오는데, 주문 처리가 안 됐다고 합니다.”
정산 테이블에는 처리 행이 남아 있고, 결제사에는 그 건이 없습니다. 카프카 로그에는 레코드가 그대로 있는데, 컨슈머 그룹의 오프셋은 이미 그 뒤로 넘어가 있습니다.
이 결제는 어디서 끊겼나요? 다시 처리되게 하려면 무엇을 바꾸시겠나요?
“주문 내역이 없다는데, 결제 완료 알림은 먼저 왔어요.”
주문 화면에는 결제 완료가 먼저 찍히고 주문 생성이 3분 뒤에 찍혔습니다. 보내는 쪽은 주문 생성을 먼저 보냈고 두 전송 모두 성공했습니다. 브로커와 컨슈머 오류는 없습니다.
순서가 왜 뒤집혔나요? 다시 생기지 않게 하려면 무엇을 바꾸시겠나요?
여기서 말문이 막혔다면, 면접에서도 똑같이 막힙니다.
현업에서 반복되는 이런 사고를 유형별로 전부 모아 두었고, 4주 동안 카프카 기본기와 엮어서 답하는 훈련을 합니다.
이 4주로 카프카는 이제 종결하세요.
꼬리질문이 들어올수록,
오히려 답변이 단단해집니다.
장애 대응, 설계 회의, 그리고 면접. 시니어와 갈리는 건 늘 이 순간들이에요. 필요한 건 같은 판단력 하나인데, 그게 없으면 매번 같은 데서 막힙니다. 4주 동안 그 판단력을 같이 만듭니다.
- ✓“Kafka가 왜 큐가 아니라 로그인가”를 한 단락으로 설명합니다
- ✓유실 · 중복 · 순서 · exactly-once는 양 끝의 설정과 처리로 직접 조립합니다
- ✓“acks=all이 정확히 뭘 보장하나”에 설정 복붙 없이 답합니다
- ✓세그먼트 · 페이지캐시 · ISR · High Watermark가 한 로그 모델 위에 연결됩니다
- ✓컨슈머 그룹 · 파티션 할당 · 리밸런싱이 처리량과 중복을 동시에 좌우하는 이유를 설명합니다
- ✓"왜 카프카였나"에 보존 · 재생 · 독립 소비라는 우리 요구로 답합니다
- ✓트래픽이 커도 카프카가 맞지 않는 조건을 근거로 말합니다
- ✓acks · 커밋 시점 · 파티션 키를 유실 · 중복 · 지연 · 순서의 트레이드오프로 읽습니다
- ✓"일단 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주 라이브, 탄생부터 확장까지. 소수 정원 그룹 스터디.
혼자 듣는 강의가 아니라 소그룹으로 같이 걷는 그룹 스터디예요.
탄생, 깊이, 생존, 확장 네 테마를 한 주에 하나씩 갑니다. 매주 목요일 저녁 8시 2시간, 네 번입니다.
1기(Redis)와 같이 메타버스 Zep에서 모이는 방향으로 준비하고 있어요. 같은 화면을 같이 펼쳐 놓고 이야기하는 분위기를 살리기 위해서예요.
4~5명씩 그룹으로 나눠 토론합니다. 매주 그룹에서 사회자를 랜덤으로 한 명 뽑아, 그날 토론이 매끄럽게 돌게 진행을 맡아요.
한 결정을 세 번 만납니다.
결과 → 근거 → 철학.
기능을 차례로 나열하지 않습니다.
LinkedIn이 내린 같은 설계 결정을 장애의 결과로 먼저 만나고, 소스와 설계자의 원문으로 근거를 확인한 뒤, 마지막에 무엇을 포기한 설계인지까지 확인합니다.
결과로 만난다
1,000건이 1,003건과 998건으로 어긋난 새벽 장애에서 시작합니다. 답을 먼저 주지 않고, 큐 멘탈 모델이 막히는 지점을 남깁니다.
→근거로 내려간다
LinkedIn의 N×M 파이프라인, 로그 선택, 세그먼트, 페이지캐시, ISR과 High Watermark까지 설계 결정의 밑면을 엽니다.
→철학으로 끝맺는다
end-to-end argument와 복제 로그의 철학 위에서 acks · ISR · commit을 하나의 판단 틀로 묶고 첫 사고의 설정 한 벌을 직접 고릅니다.
블로그 몇 편을 요약한 4주가 아닙니다.
설정의 이유를 말하려면 만든 사람의 문제, 실제 소스의 불변식, 그 뒤의 CS 원리가 한 줄에 이어져야 합니다.
버전에 따라 달라진 기본값과 소스 경로를 섞지 않습니다.
블로그의 요약 대신 설계자와 공식 문서의 원문을 따라갑니다.
가설을 적고, 비교하고, 정리로 남기는 루프를 Kafka의 실패모드에 맞게 다시 설계했습니다.
역사 · 철학
Jay Kreps는 왜 큐를 버리고 로그를 골랐을까요? LinkedIn 데이터 파이프라인이 무너지던 순간의 실제 의사결정들을 그가 직접 남긴 글로 따라가요.
"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 페이지캐시. 그리고 CAP이 말하는 선택을 카프카 설정의 언어로 옮겨 봐요. 교과서와 원논문이 실물에 붙는 순간을 봅니다.
"End-to-End Arguments in System Design"
— Saltzer · Reed · Clark, 1984
한 사고에서 시작해, 설계 철학까지 내려갑니다.
기능을 차례로 훑는 과정이 아닙니다.
1주차에는 메시지 큐와 보존 로그의 차이를 잡고, 2주차에는 메시지 한 건이 디스크에 저장되고 복제되는 과정을 따라갑니다.
3주차에는 첫 사고를 다시 살펴보며 유실과 중복의 원인을 찾고, 재배포할 때 그룹이 멈추는 이유도 짚습니다.
4주차에는 순서 보장과 end-to-end 설계 철학, CAP을 함께 놓고 설정을 결정하는 기준을 정리합니다.
매주 LinkedIn이 실제로 마주했던 설계 문제를 다시 풀어 봅니다. 먼저 본인 가설을 세운 뒤 카프카가 택한 답과 비교합니다.
설명에 낯선 용어가 보여도 괜찮습니다. 4주 동안 필요한 순서대로 하나씩 익힙니다.
카프카가 처음이라면 전자책 맨 앞의 개념 지도 한 장이면 준비가 끝납니다.
직접 실행해 보고 싶은 분을 위한 단일 파티션 실습(부록 A, 약 15분)과 파티션 3개·컨슈머 4개 실습(부록 B·C)은 모두 선택입니다. 라이브에서는 모두 같은 출력 자료를 보며 개념을 익힙니다.
메시지 큐가 왜 필요한가 · 큐가 아니라 로그다
이 주의 문제 · 익숙한 HTTP 호출과 DB만으로 결제 뒤 후속 처리를 이으면, 어디서 무너지나
본인이 결정한다면 · 카프카를 모른 채 시작합니다. 케이스마다 정답을 보기 전에 본인 판단을 먼저 적고, 조건이 공개되면 판단을 고칩니다. 브로커 · 토픽 · 파티션 · 오프셋 같은 이름은 마지막에만 붙어요. LinkedIn이 같은 요구 앞에서 로그를 고른 이야기도 그때 짧게 만납니다.
- 상황 1 · 결제 응답과 멈춘 알림 서버. 알림 서비스가 4초 늦어지자 결제 응답도 4초 걸렸다. 이어서 알림 서버가 30분 동안 멈춘다. 응답 전에 반드시 끝낼 일과 늦어도 되지만 사라지면 안 되는 일을 나눠 어디까지 직접 호출할지 정한다.
- 상황 2 · 같은 결제 사건을 세 팀이 원한다. 알림은 즉시, 정산은 매일 밤, 분석 팀은 일주일 뒤 합류해 지난 7일을 처음부터. 한 번 꺼내면 지워지는 작업 큐로는 안 되는 요구.
- 상황 3 · 컨슘했는데 메시지가 남아 있다. 같은 세 건을 처음부터 읽는 명령을 두 번 실행해도 두 번 다 나온다. 움직인 것은 데이터가 아니라 읽기 시작점. 오프셋과 컨슈머 그룹이라는 이름이 여기서 붙는다.
- 상황 4 · 컨슈머를 네 대로 늘렸는데 처리량이 그대로다. 밀린 처리를 따라잡으려 인스턴스를 늘렸는데 한 대는 아무것도 읽지 않는다. 한 파티션을 두 대가 나눠 읽지 않는 규칙이 있고, 그 규칙 때문에 병렬 처리의 상한이 정해진다. 왜 그렇게 막아 두는지를 처리 순서와 진행도 기록에서 찾아본다.
- 0~10분처음 모델메시지 큐를 어떻게 이해하고 있는지 먼저 그림으로 남깁니다.
- 10~30분직접 호출과 비동기결제 응답은 어디까지 기다릴지, 알림 서버가 멈추면 어떻게 할지 판단합니다.
- 30~50분큐와 보존 로그같은 결제 사건을 세 팀이 서로 다른 속도로 읽어야 하는 상황을 풉니다.
- 50~70분보존과 진행도같은 메시지가 두 번 나오는 이유를 확인하고 오프셋과 컨슈머 그룹을 익힙니다.
- 70~85분병렬성 상한컨슈머 네 대와 파티션 세 개의 할당표를 읽습니다.
- 85~100분한 장 지도구성 요소와 저장 상태, 읽기 상태를 한 장에 정리합니다.
- 100~115분결정 카드직접 호출, 작업 큐, 보존 로그의 경계를 본인 서비스에 적용합니다.
- 115~120분한 줄 공유처음 그림에서 가장 크게 바뀐 판단을 말합니다.
더 깊이 보고 싶다면·파티션 3개와 컨슈머 4개를 쓰는 실습은 전자책 부록의 선택 실습입니다. 라이브에서는 모두가 같은 partition · offset · members 출력 자료를 보며 판단합니다.
카프카 한 장 지도 1번에 구성 요소와 저장 · 읽기 상태를 정리하고 어떤 업무를 직접 호출 · 작업 큐 · 보존 로그에 둘지 근거를 들어 정합니다
send() 한 줄은 어떻게 팔로워 디스크까지 가고 왜 빠를까
이 주의 문제 · 디스크에 쓰는데 왜 인메모리급으로 빠른가
본인이 결정한다면 · 브로커 안에 자체 캐시를 만들 것인가, OS에 전부 맡길 것인가. 대부분의 DB는 전자를 골랐고 카프카는 후자를 골랐습니다. 본인이 설계자였다면 어느 쪽이었을지 가설을 세우고, 카프카가 그렇게 간 근거를 소스에서 확인합니다.
- 상황 1 · send() 했는데 아직 안 갔다. batch.size와 linger.ms가 만드는 대기. 지연을 내주고 처리량을 사는 첫 트레이드오프.
- 상황 2 · 브로커 디스크 디렉터리를 직접 연다. .log와 .index와 .timeindex, 파일명이 곧 baseOffset. 왜 파일 하나가 아니라 세그먼트로 쪼개고, 인덱스는 왜 촘촘하지 않고 듬성듬성한가(sparse).
- 상황 3 · 자체 캐시를 안 만든 결정. 순차 I/O, OS 페이지캐시에 올라타기, 제로카피. "디스크는 느리다"가 참인 조건과 거짓인 조건.
- 상황 4 · 팔로워가 ISR에서 빠졌다. 그 순간 리더가 죽으면. 복제는 팔로워(복제본)가 리더에서 당겨(fetch) 갑니다. 못 따라온 팔로워가 동기화 명단(ISR)에서 빠진 순간 리더가 죽으면 무슨 일이 벌어지나. 컨슈머에게 어디까지 보여줄지 긋는 선(High Watermark)은 누가 정하나.
- 0~10분지도 다시 펴기1주차 지도에 send 한 건이 지나갈 자리를 먼저 그려 둡니다.
- 10~25분프로듀서 대기batch.size와 linger.ms가 지연과 처리량을 어떻게 바꾸는지 확인합니다.
- 25~40분세그먼트와 인덱스디스크 파일을 열어 append와 탐색의 단위를 확인합니다.
- 40~55분페이지캐시와 제로카피디스크에 쓰면서도 빠른 조건과 느려지는 조건을 가립니다.
- 55~75분복제와 가시성팔로워 fetch, ISR, High Watermark를 하나의 안전 경계로 연결합니다.
- 75~95분전체 경로도프로듀서 버퍼부터 팔로워 로그까지 하나의 경로로 이어 그립니다.
- 95~115분내 설정의 대가지연과 처리량, 내구성 중 무엇을 지불할지 적습니다.
- 115~120분한 줄 공유성공 응답이 어디까지 보장하는지 본인 말로 설명합니다.
더 깊이 보고 싶다면·dump-log의 isControl은 트랜잭션 표시가 로그에 남는다는 예고로만 봅니다. 제어 레코드와 격리 수준은 3주차에서 자세히 다룹니다.
카프카 한 장 지도 2번에 저장 · 복제 경로를 더하고 성공 응답이 어디까지 보장하는지 프로듀서 버퍼부터 High Watermark까지 설명합니다
유실과 중복은 어디서 생기나
이 주의 문제 · 유실과 중복은 버그가 아니라 설정으로 고른 트레이드오프다
본인이 결정한다면 · 유실과 중복을 동시에 0으로 만들 수는 없습니다. 본인 서비스가 결제라면, 로그 수집이라면, 알림이라면 각각 어느 쪽을 감수할 것인지. 정답을 외우는 게 아니라 본인이 결정하고, 그 결정을 설정 값으로 옮기는 훈련을 합니다. 설정으로 끝나지 않는 것도 있어요. 커밋을 언제 부를지, 파티션 소유권이 넘어가는 순간에 무엇을 정리할지는 코드에서 본인이 정합니다.
- 상황 1 · 성공 응답은 어디까지 안전한가. acks=1에서 리더 교체가 겹치는 순간부터 시작한다. acks=all도 동기화 명단이 줄어들면 약속의 범위가 달라진다. acks · 최소 ISR · unclean 선출을 함께 놓고, 어떤 장애에서 쓰기를 거절할지 정한다.
- 상황 2 · 컨슈머 재배포마다 같은 메시지를 또 처리한다. 커밋을 처리 앞에 두면 유실, 뒤에 두면 중복. 자동 커밋이 남기는 재처리 구간은 정확히 커밋 주기만큼이다. 직접 커밋으로 옮기면 그 구간은 줄지만, 한 배치 중간이 실패했을 때 어디까지 전진시킬지를 이제 본인이 정해야 한다. __consumer_offsets도 결국 로그다.
- 상황 3 · 배포할 때마다 그룹 전체가 몇 초씩 멈춘다. 인스턴스 하나를 내렸을 뿐인데 모든 컨슈머가 담당 파티션을 반납하고 소비가 끊긴다. 전부 멈추는 방식과 바뀌는 몫만 넘기는 방식이 각각 무엇을 내주는가. 그리고 소유권이 넘어가기 직전에 무엇을 커밋해야 같은 구간을 두 번 처리하지 않는가.
- 상황 4 · 재시도가 만든 중복. 클라이언트 내부 재시도와 애플리케이션의 새 send를 구분한다. 멱등 프로듀서와 Kafka 트랜잭션이 막는 범위를 확인하고, 외부 DB와 HTTP부터는 어떤 중복 방지 장치가 필요한지 정한다.
- 0~10분사고 다시 열기발생 1,000 · 정산 1,003 · 결제사 998의 흔적을 구간별로 나눕니다.
- 10~35분생산 경로 유실acks · 최소 ISR · unclean 선출을 한 블록에서 판단합니다.
- 35~60분소비 경로 중복자동 커밋, 처리 전후 커밋, 배치 중간 실패의 결과를 비교합니다.
- 60~80분소유권 인계리밸런싱 때 멈추는 범위와 반납 직전 정리할 상태를 고릅니다.
- 80~100분중복 방지 경계멱등 프로듀서, Kafka 트랜잭션, 외부 멱등성이 보장하는 범위를 구분합니다.
- 100~115분사고 원인 찾기첫 사고의 원인을 생산 · 저장 · 소비 · 외부 API 구간별로 좁혀 갑니다.
- 115~120분한 줄 공유내 서비스가 받을 유실과 중복을 한 문장으로 말합니다.
더 깊이 보고 싶다면·더 궁금한 분은 힌트시트에서 commitAsync 응답 순서, JoinGroup · SyncGroup, 협력적 전략 전환의 두 번 배포, producer epoch fencing 세부 코드, LSO까지 볼 수 있습니다.
카프카 한 장 지도 3번에 유실 · 중복 구간을 표시하고 데이터마다 감수할 실패를 정한 뒤 acks와 커밋 시점, 외부 멱등 장치를 고릅니다
카프카가 보장하는 순서는 어디까지인가
이 주의 문제 · 전역 순서를 포기하면서 카프카는 무엇을 샀나
본인이 결정한다면 · 모든 메시지의 순서를 지키는 길과, 순서를 파티션 안으로 좁히고 처리량을 사는 길. 카프카는 후자를 골랐습니다. 본인 서비스라면 어디까지의 순서가 진짜 필요한지 선을 긋고, 마지막 질문 하나로 4주를 마무리합니다. 언제 카프카를 쓰고, 언제 쓰지 않을 것인가.
- 상황 1 · 결제완료가 주문생성보다 먼저 도착했다. 키 없는 send가 라운드로빈으로 흩어질 때. 파티션 안 순서로 충분한 시나리오와 부족한 시나리오, 키 설계.
- 상황 2 · 특정 파티션만 터진다. 대형 고객 키가 몰리는 핫 파티션. 키 설계를 바꾸면 무엇이 같이 바뀌나.
- 상황 3 · 브로커는 왜 이렇게 단순한가. 필터링도 변환도 안 해주는 이유. end-to-end argument로 4주간 본 결정을 전부 다시 읽는다.
- 상황 4 · CAP 선택을 설정으로 옮기기. 3주차에서 본 쓰기 거부와 유실 허용에 CAP이라는 이름을 붙인다. 이어서 첫 사고를 다시 살펴보고 acks와 최소 복제본부터 커밋 방식과 파티션 할당 전략까지 생산자와 소비자의 설정을 한 표에 놓는다.
- 0~10분경계 표시앞의 한 장 지도에 유실 · 중복 · 순서 경계를 표시합니다.
- 10~30분순서의 범위주문생성과 결제완료 역전으로 파티션 내부 순서와 키를 설계합니다.
- 30~50분핫 파티션순서와 처리량 중 무엇을 내줄지 정하고 파티션을 늘릴 때 드는 전환 비용도 따집니다.
- 50~65분end-to-end 책임브로커가 단순하게 남은 이유와 애플리케이션의 책임을 연결합니다.
- 65~80분CAP 이름 붙이기3주차의 선택을 통신이 끊긴 상황에 놓고 일관성과 가용성 중 무엇을 지킬지 다시 봅니다.
- 80~105분설정 결정표생산 · 저장 · 소비 · 외부 업무의 경계를 한 표로 정리합니다.
- 105~115분Kafka를 쓰지 않을 때보존과 재생이 필요하지 않은 요구에는 어떤 도구가 맞는지 적습니다.
- 115~120분마지막 한 줄4주 동안 가장 크게 바뀐 판단을 공유합니다.
더 깊이 보고 싶다면·PACELC는 평시에도 지연과 일관성 사이에서 선택해야 한다는 정도로 짧게 다룹니다. 라이브에서는 보호 범위, 남는 실패, 지불 비용 세 가지를 기준으로 판단합니다.
카프카 한 장 지도를 완성하고, 설정 몇 줄만 봐도 이 시스템이 유실 · 중복 · 지연 · 순서 가운데 무엇을 포기했는지 읽어냅니다
사전 → 라이브 → 사후. 이 흐름이 4주 반복됩니다.
사전 자료에서 가설을 세우고, 라이브에서 동료들과 비교하며 다듬고, 정리 한 장으로 남깁니다.
주차가 끝날 때마다 내 손으로 쓴 정리가 한 장씩 쌓여요.
주중 사전 (자료 + 가설)
- ·해당 주 사전 자료 읽기
- ·이번 주에 다룰 상황 4개에 본인 가설을 적어 라이브 전에 제출합니다. 라이브에서 동료들과 공유하고 비교합니다. 코드는 안 짜와도 됩니다.
- ·Kafka가 처음이라면 전자책 맨 앞의 개념 지도 한 장이면 준비가 끝납니다. 직접 실행해 보고 싶으면 부록 A의 15분 단일 파티션 실습을 진행합니다. 파티션 3개와 컨슈머 4개를 쓰는 실습(부록 B·C)도 선택이고 라이브에서는 모두 같은 출력 자료를 함께 봅니다.
평일 저녁 2시간 (대화 · 도해 · 토론)
- ·타자 치는 시간은 없습니다. 문제 상황부터 살펴보고 각자의 가설을 비교합니다. 그다음 Kafka가 택한 답을 읽고 무엇을 얻고 무엇을 내줬는지 정리합니다.
- ·설정과 코드는 같이 펼쳐 읽는 소재예요. 결정이 담긴 줄마다 멈춰 "왜 이렇게 했나, 우리 가설대로면 어디가 달랐나"를 그룹 전체가 함께 짚어요.
- ·매주 같은 카프카 한 장 지도를 다시 펴고 새로 배운 저장 · 복제 · 실패 경계와 설정 비용을 지도에 더합니다.
- ·막히면 케이스별 힌트시트를 같이 펴요. 요구사항, 떠올릴 후보, 용어, 그리고 다른 기술(DB · Redis · TCP)에서 만나는 같은 문제까지 담겨 있어요.
- ·4~5명 그룹으로 토론하고 매주 사회자를 랜덤으로 한 명 뽑습니다. 사회자는 정답을 아는 사람이 아니라 발언이 한쪽으로 쏠리지 않게 돕고 막힌 지점을 함께 풀도록 토론을 이끄는 역할이에요. 순번이 돌기 때문에 누구나 한 번은 진행을 맡아 봅니다.
주중 사후 (남기고 싶은 만큼)
- ·그 주에 본 결정을 본인 노트에 한 장으로 남깁니다. 분량도 형식도 자유이고, 제출은 의무가 아닙니다.
- ·남긴 정리를 공유하면 동료가 코멘트를 달아 줍니다. 읽기만 해도 됩니다.
- ·(선택) 더 파보고 싶으면 로컬 클러스터에서 설정을 바꿔 가며 직접 실험해 보기. 안 해도 완주에 지장 없습니다.
주차마다 한 문장씩 받았습니다.
4주 뒤 남은 문장은 이렇습니다.
Vol.2 Kafka는 주제만 바뀝니다. 사전 자료로 가설을 세우고, 토론에서 동료와 비교하고, 한 장으로 남기는 흐름은 1기와 같아요.
공개에 동의한 답변만 실었습니다. 뜻은 그대로 두고 어미와 표기만 다듬었고, 이름은 모두 뺐어요.
“Redis는 싱글 스레드이면서 멀티 스레드입니다.”
외워 둔 한 줄이 어디까지 참인지로 갈라진 순간입니다.
“궁금한 것만 결과에서 원인을 거슬러 찾았는데, 원인에서 결과로 내려오는 것도 재밌습니다.”
검색으로 답부터 찾던 순서가 뒤집힙니다.
“Redis의 설계 철학을 엿볼 수 있습니다.”
첫 주에 이미 기능 목록에서 설계자의 판단으로 넘어갑니다.
“힘들지만 재밌습니다.”
쉽게 만들지 않았습니다. 대신 혼자 막히게 두지도 않았습니다.
8월 13일 목요일 저녁 8시
소수 정원으로 시작합니다.
전자책(카프카 딥다이브 164쪽)과 4주 라이브가 한 묶음으로 139,000원입니다.
그릿 모먼츠 동문은 로그인하면 50% 할인이 자동 적용돼요.
1주차 시작 전까지 100% 환불입니다.
8월 13일 목요일 저녁 8시에 시작합니다.
매주 목요일 같은 시간에 2시간씩, 8/13 · 8/20 · 8/27 · 9/3 네 번이에요. 합류하시면 드리는 2기 오픈 카톡방으로 1주차 전에 Zep 입장 링크와 사전 준비 안내가 갑니다. 일정이 맞지 않으시면 1주차 시작 전까지 100% 환불돼요.
결제 옵션 불러오는 중…
합류하시면 결제 완료 화면에서 2기 오픈 카톡방 링크를 드립니다. 확정된 시작일과 사전 준비 안내, Zep 입장 링크가 모두 그곳으로 갑니다. 전자책은 결제 직후 내 서재에서 바로 받으실 수 있어요.
- ✓전자책(카프카 딥다이브 164쪽) + 4주 라이브가 한 묶음, 139,000원
- ✓8월 13일(목) 시작 · 매주 목요일 저녁 8시 2시간 · 소수 정원 선착순
- ✓라이브는 대화 전용. 코드는 같이 읽는 소재이고 타자 치는 시간은 없습니다
- ✓그릿 모먼츠 동문은 50% 할인 (시리즈 공통, 로그인하면 자동 적용)
- ✓1주차 라이브 시작 전까지 100% 환불
- ·그룹 편성과 사회자 순번 (1주차 시작 전 안내)
- ·Zep 라이브 공간 링크 (합류자 오픈 카톡방에 공지)
자주 묻는 질문.
스터디는 어떻게 진행되나요?+
강의가 아니라 토론형 그룹 스터디입니다. 4~5명씩 그룹으로 나눠 진행하고 매주 그룹에서 사회자를 랜덤으로 한 명 뽑아요. 사회자는 정답을 가르치는 사람이 아니라 발언이 한쪽으로 쏠리지 않게 돕고 막힌 지점을 함께 푸는 역할입니다. 순번이 돌아 누구나 한 번은 맡아요. 매주 아젠다에 담긴 운영 상황 4개를 차례로 토론합니다. 막히면 상황별 힌트시트(요구사항 · 후보 · 용어 · 다른 기술의 같은 문제)를 같이 펴요. 사전 자료에서 세운 가설을 동료와 비교하고 Kafka가 택한 답과 대조합니다.
언제 시작하나요?+
8월 13일 목요일 저녁 8시에 시작합니다. 매주 목요일 같은 시간에 2시간씩, 8/13 · 8/20 · 8/27 · 9/3 네 번이에요. 합류하시면 드리는 2기 오픈 카톡방으로 1주차 전에 Zep 입장 링크와 사전 준비 안내가 갑니다. 일정이 맞지 않으시면 1주차 시작 전까지 100% 환불되니 부담 없이 정하셔도 돼요.
결제하면 어떻게 되나요? 환불은요?+
결제하면 바로 2기 합류가 확정되고, 전자책(카프카 딥다이브)이 코기토 서재에 들어갑니다. 1주차는 8월 13일(목) 저녁 8시이고, 합류하시면 드리는 2기 오픈 카톡방으로 안내가 갑니다. 1주차 라이브 시작 전까지는 100% 환불이고, 시작 이후에는 4주가 한 흐름이라 환불이 불가합니다. 소수 정원 선착순이라 자리가 차면 결제 버튼이 닫혀요.
면접 대비용 스터디인가요?+
면접 빈출 문제를 외우는 반은 아닙니다. 다만 Kafka 면접에서 점수가 나는 답은 기능 정의가 아니라 우리 요구에서 무엇을 지키고 무엇을 포기했는지를 말하는 답입니다. 매주 장애 케이스에 가설을 적고 동료와 비교하는 이유가 바로 그 답변 구조를 만들기 위해서예요.
라이브에서 코드를 직접 짜나요?+
아니요. 라이브 2시간은 전부 대화 · 도해 · 토론입니다. 설정과 코드는 같이 펼쳐 읽는 소재예요. 결정이 담긴 줄마다 멈춰 "왜 이렇게 했나"를 짚습니다. 직접 실험해 보고 싶으면 사후 선택 과제로 로컬 클러스터를 만져 보세요 (완주에 지장 없음).
Kafka를 실무에서 안 써봤어도 따라갈 수 있나요?+
네. 그래서 1주차에는 로그라는 멘탈 모델과 기본 부품부터 다시 짚습니다. 전자책 본문은 실습 없이 읽을 수 있고, 라이브 전 준비는 맨 앞의 개념 지도 한 장이면 됩니다. 직접 실행해 보고 싶으면 부록 A의 15분 단일 파티션 실습이 있고, 파티션 3개와 컨슈머 4개를 쓰는 실습(부록 B·C)도 선택이에요. 라이브에서는 모두가 같은 출력 자료를 보며 개념을 익힙니다. 써본 분에게는 본인이 겪은 장애가 교재가 되고 안 써본 분에게는 처음부터 올바른 모델로 시작하는 기회가 됩니다.
1기(Redis)를 안 들었는데 2기부터 들어도 되나요?+
네. 각 권은 독립적입니다. 시리즈가 쌓아 가는 건 특정 도구 지식이 아니라 트레이드오프를 읽는 판단의 어휘라서, 어느 권에서 시작해도 그 권 안에서 완결돼요.
Java나 Scala를 몰라도 되나요?+
네. 라이브에서 코드를 짜지 않으니 어떤 언어를 써왔든 상관없어요. 모르는 언어의 코드에서도 "여기서 무슨 결정을 했나"를 읽어내는 게 이 스터디가 훈련하는 근육입니다.
Streams나 Connect도 다루나요?+
아니요. 이 4주는 코어(로그 · 저장 · 복제 · 전달 보장)의 설계를 팝니다. 코어를 이 깊이로 이해하고 나면 Streams · Connect 같은 생태계 도구는 공식 문서로 따라갈 수 있는 층이 돼요.
전자책만 따로 살 수 있나요?+
카프카 딥다이브 전자책은 스터디 오픈에 맞춰 팀그릿 전자책 서점 「코기토 서재」에서 단품 판매를 준비하고 있어요. 이 페이지는 스터디 합류(전자책 + 4주 라이브) 기준 안내입니다.
그릿 모먼츠 동문 할인은 어떻게 적용되나요?+
팀그릿의 다른 라이브 프로그램인 그릿 모먼츠를 완주하셨다면 자동 50% 할인입니다. 모집이 열리면 결제 화면에서 같은 카카오 계정으로 로그인하시면 자동 적용돼요.
4주 후 손에 남는 것은 설정 모음집이 아니라,
새 시스템 앞에서도 트레이드오프를 읽어내는 본인입니다.
2기 모집 중 · 8월 13일(목) 시작 · 139,000원 · 소수 정원 선착순 · 그릿 모먼츠 동문 50% 할인.
2기 합류하기 →