우리가 겪을 장애는
이미 다 적혀 있습니다.
복제 지연, 핫 샤드, 쓰기 스큐, 캐시 정합성. 트래픽이 늘면 순서대로 옵니다. 새벽 호출로 배울지, 5주로 배울지의 차이입니다.
DB 한 대로 버티는 서비스에서, “이제 무엇을 어떻게 늘릴까”에 근거를 대는 개발자로 바뀌는 5주.
도구는 몇 년마다 바뀌고,
그 아래 원리는 그대로 남습니다.
장애 대응, 기술 선택 회의, 그리고 시스템 디자인 면접. 갈리는 순간은 늘 "무엇을 포기할지 정하는" 대목입니다. 필요한 판단력은 하나인데, 그게 없으면 매번 같은 데서 막힙니다. 5주 동안 매주 본인 이름으로 결정을 내려 봅니다.
- ✓복제본을 붙이는 순간 생기는 문제를 붙이기 전에 압니다
- ✓샤딩 키를 정하기 전에 어떤 키가 핫스팟을 만드는지 계산합니다
- ✓격리수준을 올려도 막히지 않는 결함이 무엇인지 먼저 확인합니다
- ✓캐시와 DB가 어긋나는 구조적 이유를 알고 이중 쓰기를 줄입니다
- ✓새 데이터베이스 문서를 열었을 때 무엇부터 확인할지 목록이 생깁니다
- ✓"강한 일관성"이라는 홍보 문구에서 실제 보장 범위를 가려냅니다
- ✓기술 선택 회의에서 "무엇을 포기하는 선택인지"를 먼저 말합니다
- ✓Redis · Kafka · RDB에서 따로 겪은 문제들이 같은 원리였다는 것이 보입니다
아는 단어가 늘어나는 게 아니라,
답변의 구조가 바뀝니다.
한 일을 보고하는 답에서, 무엇을 감수하고 무엇을 지켰는지 함께 말하는 답으로 옮겨갑니다.
“읽기를 복제본으로 분산해서 부하를 줄였습니다.”
“복제 지연이 사용자에게 보이기 시작했습니다. 글을 쓴 직후 본인 글이 안 보이는 문제라서, 본인이 쓴 데이터는 리더에서 읽도록 예외를 두고 나머지는 복제본으로 보냈습니다.”
“REPEATABLE READ로 두면 더 안전하니까요.”
“재고 차감에서 두 트랜잭션이 각자 조건을 확인하고 각자 쓰는 패턴이었습니다. 스냅숏 격리로는 이 쓰기 스큐가 막히지 않아서, 격리수준 대신 명시적 잠금으로 그 구간만 직렬화했습니다.”
서비스가 작을 때는
이 책 전부가 과잉입니다.
아래 네 질문에 근거를 대고 답할 수 있는지가 이 5주의 입구이자 출구입니다.
서비스가 작을 때는 이 책의 내용이 전부 과잉입니다. DB 한 대, 캐시 하나, 트랜잭션은 기본값으로 두면 됩니다. 그래서 읽어도 지금 내 문제가 아니라고 느껴지고, 그게 3장에서 덮이는 진짜 이유입니다.
그런데 트래픽이 늘면 순서가 정해져 있습니다. 읽기가 먼저 무거워지고, 복제본을 붙이고, 복제 지연이 사용자 화면에 보이고, 샤딩을 고민하고, 그 과정에서 트랜잭션이 실제로 무엇을 보장하는지 처음 확인하게 됩니다.
이 순서는 우리 팀만의 경로가 아닙니다. 먼저 커진 회사들이 같은 순서로 지났고, 그때 무엇을 포기했는지가 논문으로 남았고, 이 책이 그 논문들을 한 권으로 정리했습니다.
그러니 선택은 두 가지입니다. 장애로 배우거나, 미리 읽거나. 장애로 배우면 값은 새벽 호출과 사후 회고이고, 미리 읽으면 값은 다섯 번의 저녁입니다.
한 가지가 더 남습니다. 도구는 계속 바뀝니다. RDB를 쓰다 Redis를 붙이고 Kafka를 들이고 언젠가 다른 저장소로 옮깁니다. 매번 처음부터 배우게 되는 건 도구 아래의 공통 원리를 한 번도 정리하지 않았기 때문입니다. 이 책이 그 층을 다룹니다.
맞지 않을 수도 있어요. 시간을 아껴드릴게요.
- ✓트래픽이 늘고 있는데 무엇부터 손봐야 할지 순서가 안 잡히는 분
- ✓한 도구는 깊게 아는데 새 저장소 앞에서는 매번 처음부터 시작하는 느낌인 분
- ✓이 책을 샀고, 몇 장 읽었고, 지금 책장에 꽂혀 있는 분
- ✓샤딩 · 복제 · 격리수준을 실무에서 쓰고 있지만 선택의 근거는 전임자에게 물려받은 분
- ✓Vol.1 Redis나 Vol.2 Kafka를 지나고, 도구 하나가 아니라 그 아래 공통 원리를 보고 싶은 분
- ✗이미 이 책을 완독하고 12장까지 본인 언어로 설명할 수 있는 분. 이 5주는 얕을 거예요
- ✗특정 DB의 튜닝 실무(인덱스 힌트, 쿼리 플랜 최적화)를 기대하는 분. 이 5주는 그 아래층을 봅니다
- ✗책을 대신 요약해 주기를 기대하는 분. 읽고 오는 시간이 매주 필요합니다
5주 라이브, 1장부터 12장까지. 소수 정원 그룹 스터디.
혼자 읽는 완독 챌린지가 아니라 소그룹으로 같이 걷는 그룹 스터디예요. 일정은 확정됐고, 정원과 가격은 모집 공지에서 안내드립니다.
약속, 저장, 분산, 진실, 파생 다섯 테마를 한 주에 하나씩 갑니다. 9월 10일 · 17일 · 24일, 10월 1일 · 8일 목요일 저녁입니다.
1기(Redis)와 2기(Kafka)처럼 메타버스 공간 Zep에서 모입니다. 같은 화면을 같이 놓고 이야기하는 방식이라서예요.
앞선 기수와 같은 소그룹 구조로 준비하고 있어요. 확정 정원은 모집 공지에서 안내드립니다.
책을 먼저 읽지 않습니다.
장면 → 책 → 우리 시스템.
장을 순서대로 요약하지 않습니다. 매주 운영에서 볼 수 있는 장면을 먼저 만나고, 그 장면을 만드는 메커니즘을 책에서 확인한 뒤, 지금 우리 서비스에 같은 조건이 있는지까지 확인합니다.
장면으로 만난다
"쓴 글이 안 보인다", "재고가 마이너스가 됐다" 같은 장면에서 시작합니다. 책의 용어는 아직 꺼내지 않습니다.
→책으로 내려간다
그 장면을 만드는 메커니즘을 책의 해당 절에서 확인합니다. 이때 처음으로 정확한 이름이 붙습니다.
→우리 시스템으로 돌아온다
지금 운영 중인 서비스에서 같은 조건이 성립하는지 확인합니다. 성립하면 이미 있는 잠재 장애이고, 아니면 왜 아닌지가 설계 근거입니다.
책 요약을 대신 해드리는 5주가 아닙니다.
이 책의 문장을 신뢰하려면 그 뒤의 원문, 실제 제품의 동작, 그리고 서비스를 세운 장애가 한 줄에 이어져야 합니다.
마틴 클레프만. 1장부터 12장까지 전권을 5주에 나눠 씁니다.
책이 요약한 논문의 원문 주장을 매주 한두 편 직접 확인합니다.
가설을 적고, 비교하고, 정리로 남기는 루프를 두 기수에서 검증했습니다.
원문 · 논문 계보
이 책의 강점은 각 장 끝의 참고문헌입니다. 매주 그 목록에서 한두 편을 골라 원문의 주장을 직접 봅니다. 책의 요약과 원문의 진술이 어떻게 다른지도 같이 확인해요.
"A Critique of ANSI SQL Isolation Levels"
— Berenson 등, 1995
실물 데이터베이스 대조
책이 일반화한 설명을 실제 제품의 문서와 맞춰 봅니다. PostgreSQL의 MVCC, MySQL의 갭 락, Redis의 복제, Kafka의 로그가 책의 어느 절에 해당하는지 짚어요.
MVCC · 갭 락 · 쿼럼 읽기 · 리더 선출 · 펜싱 토큰
— 책의 개념에 붙는 실물의 이름들
운영 장애 사례
복제 지연, 스플릿 브레인, 시계 역행, 핫 파티션. 실제로 서비스를 세운 장애들이 책의 어느 장에 예고되어 있었는지 대조합니다.
"분산 시스템에서 시계는 거짓말한다"
— 8장이 다루는 전제
한 장면에서 시작해, 책의 뼈대까지 내려갑니다.
목차 순서를 그대로 훑지 않습니다. 1주에 시스템이 무엇을 약속하는지 숫자로 정의하고, 2주에 디스크 위의 자료구조까지 내려갑니다. 3주에 데이터가 여러 대로 흩어질 때 새로 생기는 문제를 보고, 4주에 무엇을 사실로 믿을 수 있는지까지 갑니다. 5주에는 그 뼈대 위에서 캐시와 인덱스와 집계를 파생 데이터로 다시 조립합니다. 매주 케이스마다 책을 펴기 전에 본인 판단을 먼저 적고 대조합니다.
케이스 설명에 낯선 용어가 보여도 괜찮습니다. 그 용어들을 순서대로 세우는 게 이 5주가 하는 일이에요.
이 시스템은 무엇을 약속하고 있는가
이 주의 문제 · "우리 서비스는 안정적이다"라는 말을 어떤 숫자로 증명하나
본인이 결정한다면 · 신뢰성 · 확장성 · 유지보수성은 책의 첫 장이라 대충 넘기기 쉬운 절입니다. 하지만 뒤의 모든 장이 이 세 단어의 교환으로 쓰여 있습니다. 본인 서비스의 부하 매개변수와 응답 목표를 직접 정의하고 시작합니다.
- 케이스 1 · 평균 응답이 200ms인데 고객은 느리다고 한다. 평균과 p99가 갈리는 이유. 그리고 한 요청이 여러 백엔드를 부르면 꼬리 지연이 어떻게 증폭되는지.
- 케이스 2 · 사용자가 열 배가 되면 무엇이 먼저 무너지나. 부하를 무엇으로 세는지에 따라 답이 달라진다. 쓰기가 무거운가 읽기가 무거운가, 팬아웃이 있는가.
- 케이스 3 · 이 데이터를 관계형에 둘까 문서로 둘까. 조인의 비용과 지역성의 이득. 스키마를 쓰기 때 강제할지 읽기 때 해석할지가 팀의 배포 속도까지 바꾼다.
- 케이스 4 · 관계 자체가 데이터인 경우. "친구의 친구"를 SQL로 쓰기 시작하면 나오는 신호. 그래프 모델이 답인 조건과 과잉인 조건.
본인 서비스의 부하 매개변수와 응답 목표를 정의하고, 지금 데이터 모델이 무엇을 얻고 무엇을 내준 선택인지 설명합니다
디스크 위에서 무슨 일이 일어나는가
이 주의 문제 · 많이 읽는 시스템과 많이 쓰는 시스템은 왜 다른 자료구조를 고르나
본인이 결정한다면 · 많은 사람이 이 장에서 책을 덮습니다. 그래서 순서를 바꿉니다. 로그 파일 하나에 append 하는 가장 단순한 저장소부터 직접 설계해 보고, 거기서 부족한 것을 채우는 과정으로 SSTable과 B-tree에 도착합니다.
- 케이스 1 · 인덱스를 걸었더니 쓰기가 느려졌다. 읽기를 사려면 쓰기를 내준다. B-tree가 페이지를 쪼개고 WAL을 쓰는 동안 실제로 몇 번의 디스크 쓰기가 일어나는가.
- 케이스 2 · 어떤 저장소는 쓰기가 유별나게 빠르다. LSM 트리와 컴팩션. 쓰기 증폭이 낮은 대신 읽기가 여러 계층을 훑고, 컴팩션이 밀리면 지연이 튀는 구조.
- 케이스 3 · 필드 하나 추가하는데 배포 순서를 왜 신경 쓰나. 전방 호환과 후방 호환. 구버전 코드가 신버전 데이터를 읽는 그 몇 분이 왜 위험한가.
- 케이스 4 · 운영 테이블에 집계 쿼리를 돌렸다. 행 지향과 열 지향이 갈리는 지점. 같은 데이터를 두 벌로 두는 결정이 정당해지는 조건.
지금 쓰는 저장소가 읽기와 쓰기 중 무엇에 유리하게 설계됐는지 근거를 대고, 스키마 변경 배포 순서를 호환성으로 설명합니다
데이터가 여러 대에 있을 때 생기는 일
이 주의 문제 · 복제와 파티셔닝은 무엇을 해결하고 무엇을 새로 만드나
본인이 결정한다면 · 복제본을 늘리는 결정은 읽기 부하를 줄이는 대신 "지금 이 복제본이 얼마나 뒤처졌는가"라는 문제를 새로 만듭니다. 어떤 사용자 경험까지 감수할 수 있는지 먼저 정하고, 그 선을 지키는 읽기 정책을 직접 설계합니다.
- 케이스 1 · 내가 쓴 글이 새로고침하면 사라진다. 복제 지연이 사용자에게 보이는 첫 형태. 본인이 쓴 데이터만 리더에서 읽는 예외를 어디까지 넓혀야 하나.
- 케이스 2 · 댓글이 원글보다 먼저 보인다. 두 번 읽었는데 시간이 거꾸로 가는 경우, 그리고 인과가 뒤집히는 경우. 각각 다른 보장이 필요하다.
- 케이스 3 · 리더가 죽었다. 누구를 올릴까. 페일오버가 조용히 쓰기를 버리는 순간. 두 노드가 동시에 자기를 리더로 아는 상황은 어떻게 막나.
- 케이스 4 · 샤드 하나만 계속 뜨겁다. 범위 파티셔닝과 해시 파티셔닝의 교환. 대형 고객 한 곳이 만드는 핫스팟과, 재배치 중에도 서비스가 살아 있어야 한다는 제약.
복제 지연을 사용자 경험 기준으로 정의하고, 어떤 읽기를 리더로 보낼지와 샤딩 키를 무슨 근거로 정할지 설명합니다
무엇을 사실로 믿을 수 있는가
이 주의 문제 · 트랜잭션이 지켜 주는 것과 지켜 주지 않는 것의 경계는 어디인가
본인이 결정한다면 · 격리수준은 등급이 아니라 "무엇을 여전히 허용하는가"의 목록입니다. 시계도, 네트워크도, 프로세스 정지도 신뢰할 수 없는 조건에서 그래도 합의에 도달하는 방법까지 갑니다. 여기까지가 이 책의 뼈대입니다.
- 케이스 1 · 재고가 마이너스가 됐다. 각자 조건을 확인하고 각자 쓴 두 트랜잭션. 스냅숏 격리로 막히지 않는 쓰기 스큐를 무엇으로 막나.
- 케이스 2 · 이 격리수준에서 정확히 뭐가 깨지나. 더티 읽기, 갱신 손실, 팬텀을 등급 이름 없이 현상으로 구분한다. 그다음 제품 문서의 등급 이름과 대조한다.
- 케이스 3 · 서버 시계가 3초 밀렸다. 타임스탬프로 순서를 정하던 로직이 무너지는 순간. 잠금 만료를 시간으로 판단하면 왜 위험하고, 펜싱 토큰은 무엇을 대신하나.
- 케이스 4 · "강한 일관성"이라고 쓰인 제품 문서. 선형성이 실제로 요구하는 비용, CAP이 실제로 말한 것과 오해된 것. 합의가 반드시 필요한 지점과 피해도 되는 지점.
트랜잭션과 합의가 필요한 구간을 직접 긋고, 그 판단을 신뢰성 · 확장성 · 유지보수성의 교환으로 다시 설명합니다
같은 데이터를 여러 벌로 두는 기술
이 주의 문제 · 캐시와 검색 인덱스와 집계 테이블은 원본과 어떻게 어긋나지 않나
본인이 결정한다면 · 실무의 데이터는 한 곳에만 있지 않습니다. 원본을 쓰면서 캐시도 지우고 인덱스도 갱신하는 코드가 어디에나 있어요. 이 책의 마지막 세 장은 그 구조를 뒤집습니다. 여러 곳에 각자 쓰는 대신, 하나의 순서 있는 기록에서 나머지가 파생되게 두는 설계입니다. 본인 서비스의 이중 쓰기를 찾아내고 그 경로를 다시 그립니다.
- 케이스 1 · 캐시를 지웠는데도 옛 값이 보인다. DB와 캐시에 각자 쓰는 코드가 만드는 경합. 두 곳에 쓰는 순서를 아무리 잘 정해도 남는 구멍이 있다.
- 케이스 2 · 새벽 배치가 실패하면 아침에야 안다. 입력을 바꾸지 않는 처리는 몇 번 다시 돌려도 안전하다. 일괄 처리가 이 성질로 무엇을 얻고, 결과가 하루 늦다는 대가를 언제 못 받아들이나.
- 케이스 3 · DB 변경을 검색 인덱스에 어떻게 반영하나. 변경 데이터 캡처와 이벤트 소싱. 현재 상태와 변경 기록 중 무엇을 진실로 두는지에 따라 복구 능력이 갈린다.
- 케이스 4 · "정확히 한 번"은 결국 무엇이었나. 3주와 4주에서 본 유실 · 중복 판단을 종단 간 정확성으로 다시 읽는다. 그리고 이 책의 마지막 주장, 데이터베이스의 기능을 쪼개서 파생 데이터로 조립한다는 그림을 놓고 5주를 마무리한다.
지금 서비스의 파생 데이터(캐시 · 인덱스 · 집계)를 원본에서 흐르는 단방향 경로로 다시 그리고, 어긋남이 생기는 지점을 지목합니다
사전 → 라이브 → 사후. 이 흐름이 5주 반복됩니다.
그 주 범위를 읽고 가설을 세우고, 라이브에서 동료들과 비교하며 다듬고, 정리 한 장으로 남깁니다. 주차가 끝날 때마다 내 손으로 쓴 정리가 한 장씩 쌓여요.
주중 사전 (해당 장 읽기 + 가설)
- ·그 주의 책 범위(두세 장)를 읽습니다. 완벽히 이해하고 올 필요는 없어요. 막힌 지점을 표시해 오는 게 더 도움이 됩니다.
- ·이번 주 결정 지점 네 개에 본인 답 가설을 적어 라이브 전에 제출합니다. 라이브에서 동료들과 비교합니다.
목요일 저녁 2시간 (대화 · 도해 · 토론)
- ·타자 치는 시간은 없습니다. 장면을 먼저 만나고, 각자의 가설을 비교하고, 책이 뭐라고 하는지 같이 읽은 뒤, 우리 서비스로 돌아옵니다.
- ·막힌 지점을 가져오시면 그것이 그날의 교재가 됩니다. 책의 어느 문장이 왜 안 읽히는지는 대개 그 앞 절의 전제가 빠져 있기 때문이에요.
- ·케이스별 힌트시트를 같이 폅니다. 요구사항, 떠올릴 후보, 용어, 그리고 Redis · Kafka · RDB에서 만나는 같은 문제까지 담겨 있어요.
- ·진행자 30%, 참가자 70%. 도해와 워크스루는 진행자가 끌고, 토론과 결정은 참가자가 주도합니다.
주중 사후 (정리 한 장)
- ·매주 정리 한 장을 제출합니다. 그 주에 본 트레이드오프를 본인 서비스 기준으로 어떻게 적용할지 한 장으로.
- ·동료의 정리에 코멘트 남기기.
- ·(선택) 더 파보고 싶으면 그 주 참고문헌에서 원문 한 편을 읽고 공유하기. 안 해도 완주에 지장 없습니다.
모집이 열리는 날,
가장 먼저 알려드립니다.
지금은 결제가 아니라 무료 사전예약입니다. 일정은 아래대로 확정됐고, 정원과 가격이 정해지면 사전예약자에게 가장 먼저 메일로 안내드립니다.
카카오 로그인 한 번이면 예약 완료.
결제도, 참가 확정도 아닙니다. 모집이 열리면 예약해 두신 계정 메일로 정원 · 가격 · 합류 방법을 가장 먼저 안내드려요.
- 9월 10일 (목)1주 · 약속1 ~ 2장
- 9월 17일 (목)2주 · 저장3 ~ 4장
- 9월 24일 (목)3주 · 분산5 ~ 6장
- 10월 1일 (목)4주 · 진실7 ~ 9장
- 10월 8일 (목)5주 · 파생10 ~ 12장
매주 저녁 8시부터 10시까지 2시간, 메타버스 공간 Zep에서 모입니다.
- ✓9월 10일(목) 시작, 매주 목요일 저녁 8시부터 2시간, 5주 (10월 8일 종료)
- ✓주차별 아젠다 · 사전과제 · 복습과제 · 힌트시트를 드립니다
- ✓라이브는 대화 전용. 코드는 같이 읽는 소재이고 타자 치는 시간은 없습니다
- ✓그릿 모먼츠 동문은 50% 할인 (시리즈 공통)
- ✓1주차 라이브 시작 전 100% 환불 원칙 (앞선 기수와 같은 원칙)
- ·가격 (참고로 Vol.1 · Vol.2는 자체 전자책을 포함해 139,000원이었어요)
- ·확정 정원
- ·교재 안내 방식 (책은 시판 도서라 각자 준비하시는 방향으로 보고 있습니다)
자주 묻는 질문.
책을 미리 다 읽어야 하나요?+
아니요. 매주 그 주의 범위만 읽고 오시면 됩니다. 5주에 1장부터 12장까지 나눠 가니까 한 주에 두세 장이에요. 완벽히 이해하고 오실 필요도 없습니다. 막힌 지점을 표시해 오시는 게 더 도움이 됩니다. 그게 그날 라이브의 교재가 됩니다.
책은 주시나요?+
이번 권은 시판 도서를 교재로 씁니다. Vol.1 · Vol.2처럼 자체 전자책을 드리는 구조가 아니라, 『데이터 중심 애플리케이션 설계』(마틴 클레프만, 한빛미디어)를 각자 준비하시는 방향으로 보고 있어요. 대신 주차별 아젠다 · 사전과제 · 복습과제 · 힌트시트는 저희가 만들어 드립니다.
혼자 읽는 것과 뭐가 다른가요?+
이 책은 답이 아니라 트레이드오프를 나열하는 책입니다. 결정해 본 적 없는 트레이드오프는 읽어도 남지 않아요. 그래서 매주 책을 펴기 전에 장애 장면을 먼저 만나고, 각자 판단을 적고, 그다음에 책과 대조합니다. 내 판단이 틀렸던 지점이 남는 방식이라, 혼자서는 만들기 어려운 순서예요.
1기(Redis)나 2기(Kafka)를 안 들었는데 괜찮나요?+
네. 각 권은 독립적입니다. 오히려 이번 권은 특정 도구가 아니라 그 아래 공통 원리를 보는 5주라서, 시리즈에 처음 합류하기에도 무리가 없어요. 앞선 권을 들으셨다면 Redis의 복제와 Kafka의 로그가 이 책의 어느 장이었는지 이어지는 감각이 추가로 남습니다.
라이브에서 코드를 직접 짜나요?+
아니요. 라이브 2시간은 전부 대화 · 도해 · 토론입니다. 실제 DB 문서나 설정을 같이 펼쳐 읽기는 하지만 타자 치는 시간은 없어요.
어느 정도 경력이면 맞나요?+
경력 연차보다 운영 중인 시스템이 있는지가 기준에 가깝습니다. 복제나 샤딩을 직접 안 다뤄봤어도 괜찮지만, 데이터베이스를 쓰는 서비스를 하나는 운영해 보셨다면 케이스가 훨씬 잘 붙습니다. 반대로 아직 규모 문제를 만나기 전이라면, 곧 만날 문제의 순서를 미리 아는 값으로 쓰실 수 있어요.
사전예약하면 뭐가 되는 건가요?+
결제나 참가 확정이 아니라 무료 우선 안내 명단에 이름을 올리는 것입니다. 정원과 가격이 확정되어 모집이 열리면 예약하신 계정 메일로 가장 먼저 안내드려요. 앞선 두 기수도 소수 정원 선착순이었고 3기도 같은 방식이라, 합류를 고민 중이시라면 예약해 두시는 걸 권해요.
왜 4주가 아니라 5주인가요?+
이 책은 12장까지 갑니다. 4주에 넣으면 한 주에 세 장씩 훑는 진도가 되고, 그러면 딥다이브가 아니라 완독 챌린지가 돼요. 특히 마지막 세 장(일괄 처리 · 스트림 처리 · 데이터 시스템의 미래)은 앞의 아홉 장을 다시 읽게 만드는 결론부라서 급하게 지나가면 남는 게 없습니다. 한 주를 더 써서 12장까지 제대로 갑니다.
한 주를 못 나가면 어떻게 되나요?+
라이브는 녹화하지 않지만 주차별 아젠다 · 힌트시트 · 복습과제가 남아 있어서 혼자 따라잡을 수 있습니다. 다만 이 스터디의 값은 토론에서 나오니, 5주 중 세 번 이상 참석이 어려우시면 다음 기수를 권해요.
5주 후 손에 남는 것은 완독 인증이 아니라,
처음 보는 데이터 시스템 앞에서도 질문이 서는 본인입니다.
3기 사전예약 오픈 · 9월 10일(목) 시작 · 매주 목요일 저녁 8시부터 2시간 · 5주 · 사전예약자에게 가장 먼저 안내드려요.
3기 사전예약하기 →