diff --git "a/00-\353\223\244\354\226\264\352\260\200\353\251\260/05_\354\232\264\354\230\201\353\260\251\354\213\235_\352\260\234\354\240\225.md" "b/00-\353\223\244\354\226\264\352\260\200\353\251\260/05_\354\232\264\354\230\201\353\260\251\354\213\235_\352\260\234\354\240\225.md"
new file mode 100644
index 0000000..87048f4
--- /dev/null
+++ "b/00-\353\223\244\354\226\264\352\260\200\353\251\260/05_\354\232\264\354\230\201\353\260\251\354\213\235_\352\260\234\354\240\225.md"
@@ -0,0 +1,136 @@
+# 스터디 운영 가이드 (개정판)
+
+## 이 문서는 무엇인가요
+
+시스템 설계 책을 함께 읽는 백엔드 개발자 북스터디의 운영 방식을 정리한 문서입니다. 벌칙을 나열한 규칙서가 아니라, 다 같이 더 잘 배우려고 스터디원들이 합의한 운영 방식을 담았습니다.
+
+이번 개정에서 바뀐 건 **주차별 진행 순서**입니다. 팀 진행, 발표, GitHub 공유 같은 기본 방식은 그대로 유지됩니다.
+
+---
+
+## 왜 바꿨나요
+
+기존에는 각자 **설계안을 먼저 작성**하고, 팀 안에서 리뷰나 모의면접을 한 뒤 책 내용을 참고하는 순서였습니다.
+
+대부분의 챕터에서는 이 방식이 잘 맞았습니다. 그런데 일부 주제는 처음 접하는 개념이 많고 난이도가 높았습니다. 개념이 충분히 잡히지 않은 상태에서 설계부터 하다 보니 학습 부담이 크고, 설계 완성도도 떨어지고, 리뷰에서 나눌 이야기도 얕아진다는 의견이 있었습니다.
+
+그래서 앞으로는 **개념을 먼저 충분히 이해한 뒤 설계로 넘어가는** 순서로 진행하기로 했습니다. 설계 연습을 없애는 게 아니라, 이해를 먼저 다지고 설계해보자는 쪽입니다.
+
+```
+[기존]  1차 설계  →  모의면접/리뷰  →  책 학습  →  재설계
+[개정]  개념 학습·공유(1주차)  →  설계·리뷰(2주차)
+```
+
+---
+
+## 진행 방식 한눈에 보기
+
+한 챕터는 2주 단위로 진행합니다.
+
+| 주차 | 하는 일 | 목적 | 산출물 |
+|------|--------|------|--------|
+| **1주차** | 개념 학습 및 공유 | 주제 이해도 높이기 | 학습 정리 (형식 자유) |
+| **2주차** | 설계 및 리뷰 | 이해한 내용을 설계로 옮기고 검증하기 | 설계안 (GitHub 공유) |
+
+---
+
+## 1주차: 개념 학습 및 공유
+
+책과 추가 자료로 개념을 익히는 주간입니다. 완성된 설계안을 만드는 게 목적이 아니라, 주제를 제대로 이해하는 게 목적입니다.
+
+각자 공부한 내용을 자기 방식대로 정리해 공유합니다.
+
+정리에 담으면 좋은 것:
+
+- 공부한 핵심 개념
+- 어려웠던 부분, 헷갈렸던 지점
+- 책 밖에서 추가로 찾아본 개념
+- 실무 적용 사례나 떠오른 궁금증
+
+형식은 자유입니다. Notion, Markdown, 그림, 텍스트 무엇이든 편한 걸로 쓰면 됩니다. 다만 다른 사람이 읽고 이해할 수 있게, 핵심 개념과 궁금했던 점은 드러나게 정리해주세요.
+
+---
+
+## 2주차: 설계 및 리뷰
+
+1주차에 익힌 내용을 바탕으로 각자 설계안을 만들고, 팀 안에서 리뷰와 모의면접을 하는 주간입니다.
+
+### 설계안 작성
+
+1주차에 이해한 개념을 실제 설계로 옮깁니다. 산출물 형식은 자유롭게 쓰되, 본인이 설계한 흐름이 드러나게 작성합니다.
+
+담으면 좋은 것:
+
+- 요구사항 정리
+- 핵심 API 또는 기능 흐름
+- 전체 아키텍처와 주요 컴포넌트
+- 데이터 저장 구조, 읽기/쓰기 흐름
+- 병목이나 장애가 날 수 있는 지점과 대응
+- 이 구조를 선택한 이유와 고민한 트레이드오프
+
+### PR 마감
+
+모의면접 전에 팀원들이 서로의 설계안을 미리 보고 질문을 준비할 수 있어야 리뷰가 깊어집니다. 그래서 설계 PR은 **목요일까지 올리는 것을 권장하고, 늦어도 금요일까지는 꼭** 올려주세요.
+
+PR이 늦게 올라오면 질문을 준비하거나 서로의 설계를 비교할 시간이 부족해집니다. 이번 주차부터 이 일정을 함께 지켜주시면 좋겠습니다. 운영진도 동일하게 목요일, 늦어도 금요일까지 올리겠습니다.
+
+### 리뷰 및 모의면접
+
+발표는 팀 단위로 진행하고, 발표자는 팀 안에서 자율적으로 정합니다. 리뷰의 목적은 정답을 가리는 게 아니라 설계를 함께 다듬는 것입니다. 아래 관점을 같이 이야기해보면 좋습니다.
+
+- **설계 의도**: 왜 이 구조를 선택했나요?
+- **트레이드오프**: 다른 선택지 대비 무엇을 얻고 무엇을 포기했나요?
+- **장애 상황**: 특정 컴포넌트(Redis, DB 등)가 죽으면 어떻게 되나요? 단일 장애 지점은 어디인가요?
+- **확장성**: 트래픽이 늘면 어디가 먼저 병목이 되나요?
+- **일관성**: 데이터 정합성은 어디까지 보장하나요? 캐시와 DB가 다르면 무엇을 기준으로 하나요?
+- **운영 관점**: 장애가 나면 재처리는 어떻게 하나요?
+
+발표자는 설계 의도를 설명하고, 듣는 사람은 질문을 최소 한 개 이상 준비합니다. 팀 전체는 더 나은 구조가 있는지 함께 찾아봅니다.
+
+---
+
+## 팀 운영
+
+4챕터부터 다시 시작하면서 팀 구성을 새로 짤지 고민했습니다. 다만 아직 팀별 진행 방식에 익숙해지는 단계라, 팀은 다음 주차까지 지금 구성 그대로 유지하겠습니다.
+
+팀이 유지되더라도, 앞으로 팀이 바뀌거나 챕터가 넘어갔을 때 혼란이 없도록 공통 운영 방식은 먼저 정리해서 모든 팀에 똑같이 적용합니다. 이 문서가 그 공통 기준입니다.
+
+각 팀은 별도 Zoom에서 진행하고, 산출물은 개인별로 GitHub에 공유합니다.
+
+---
+
+## 챕터 진행 순서
+
+처음 운영 방향을 잡을 때는 챕터를 순서대로 가기보다 필요한 주제를 골라 중간중간 진행하는 방식도 함께 이야기했습니다. 이후 의견을 들어보니, 시스템 설계는 앞 챕터부터 순서대로 따라가야 흐름을 이해하기 좋다는 쪽이 많았습니다. 전체 진행에도 그게 더 안정적이라, 앞으로는 책 순서대로 진행합니다.
+
+- 이번 주차: 4챕터 처리율 제한 장치 설계부터 다시 시작
+- 다음 주차: 5챕터 안정 해시 설계
+
+---
+
+## 장(章)별 예외: 5장 안정 해시
+
+모든 챕터가 "개념 학습 → 설계"에 똑같이 들어맞지는 않습니다. 장의 성격에 따라 유연하게 조정합니다. 지금 정해둔 예외는 5장 하나입니다.
+
+5장 안정 해시는 분량이 비교적 적고, 그 자체로 설계안을 만들기보다 다른 설계에 반영되는 기술 요소의 성격이 큽니다. 단독으로 설계하기에는 애매하다는 의견이 있었습니다.
+
+그래서 5장은 **개념을 충분히 학습한 뒤, 6장 키-값 저장소 설계에서 안정 해시를 반영해 기존 설계를 리팩토링**하는 방식으로 이어갑니다. 이때 안정 해시를 다음 설계 요소와 연결해서 다뤄보면 좋습니다.
+
+- 데이터 파티셔닝
+- 노드 추가/삭제 시 데이터 이동 최소화
+- 복제(replication)
+- 장애 대응
+
+이번 주는 안정 해시 개념을 충분히 잡아두고, 다음 주 설계에서 실제로 활용해보는 흐름입니다.
+
+---
+
+## 정리
+
+- 난이도 높은 주제에서도 부담을 줄이려고, 개념 학습(1주차)을 설계(2주차)보다 앞에 두었습니다.
+- 1주차의 목적은 완성된 설계가 아니라 이해도입니다.
+- 2주차 설계 PR은 목요일 권장, 금요일까지 필수입니다. 리뷰 시간을 확보하기 위해서입니다.
+- 팀은 당분간 지금 구성으로 유지하고, 챕터는 책 순서대로 진행합니다.
+- 5장 안정 해시는 6장 설계에 녹여서 함께 다룹니다.
+
+규칙이라기보다 다 같이 더 잘 배우기 위한 약속입니다. 진행하면서 더 나은 방법이 보이면 언제든 함께 조정합니다.