diff --git a/chwwwon/Week03/chapter06.md b/chwwwon/Week03/chapter06.md
new file mode 100644
index 0000000..237301c
Binary files /dev/null and b/chwwwon/Week03/chapter06.md differ
diff --git a/chwwwon/Week03/references03.md b/chwwwon/Week03/references03.md
new file mode 100644
index 0000000..69fed85
--- /dev/null
+++ b/chwwwon/Week03/references03.md
@@ -0,0 +1,119 @@
+# 3주차 발표자료
+
+[Kappa Architecture](https://hazelcast.com/foundations/software-architecture/kappa-architecture/)
+
+# Kappa Architecture의 단일 스트림 처리 엔진 사용
+
+## 1. 개요
+
+- **정의**
+    - Kappa Architecture는 **스트리밍 데이터 기반 아키텍처**
+    - 실시간(Streaming) 및 배치 처리를 **단일 기술 스택**으로 처리할 수 있게 설계된 소프트웨어 아키텍처
+- **목표**
+    - 실시간 데이터 처리를 우선으로 함
+    - 저장된 스트림 데이터를 읽어 **히스토리 데이터 분석(batch-like processing)** 도 가능하게 함
+- **기본 원칙**
+    - 모든 데이터는 **스트림(event/log) 형태로 처리**
+    - 배치 처리 계층을 별도로 두지 않고 스트림 처리 엔진이 모든 변환을 담당
+
+---
+
+## 2. 등장 배경
+
+- 전통적인 Lambda Architecture
+    - **배치 처리 계층 + 실시간 처리 계층**으로 이중 파이프라인 구조를 가짐
+    - 두 계층에 대해 **별도 코드/관리 부담**이 존재
+- Kappa Architecture
+    - 복잡성을 줄이고 **단일 스트림 처리 중심**으로 간단하게 유지·관리하기 위해 제안된 모델
+
+---
+
+## 3. 구성 요소 (논리적 흐름)
+
+![image.png](3%EC%A3%BC%EC%B0%A8%20%EB%B0%9C%ED%91%9C%EC%9E%90%EB%A3%8C/image.png)
+
+### 메시징/이벤트 저장소
+
+- **역할**: 데이터 수집 및 저장 (보통 Apache Kafka 같은 메시지 플랫폼 사용)
+- **특징**: append-only 로그 형태로 데이터를 저장 → **불변(event log)** 형태 유지
+
+### 스트림 처리 엔진
+
+- **역할**: 실시간으로 들어오는 데이터를 처리, 변환, 집계
+- **특징**: 한 번 작성된 처리 로직을 그대로 재처리(batch-like)에도 사용 가능
+
+### 분석/저장 계층
+
+- **역할**: 처리된 데이터를 분석용 DB나 서빙 레이어에 저장하여 쿼리/조회에 이용
+- **특징**: 스트림 처리 결과를 빠르게 사용자 쿼리에 제공
+
+> 한 줄 요약:
+> 
+> 
+> 이벤트 저장 → 스트림 처리 → 결과 저장 → 조회
+> 
+
+---
+
+## 4. 특징
+
+### 단일 기술 스택
+
+- 실시간 처리와 배치(히스토리) 처리를 **동일 스트림 처리 엔진**으로 커버
+- 별도 배치 시스템(예: Hadoop 계열)이 필요 없음
+
+### 실시간 중심 설계
+
+- 데이터가 메시징 엔진에 들어오는 즉시 처리 → 낮은 지연(latency)로 최근 데이터 조회 가능
+
+### 재처리 가능
+
+- 처리 로직을 변경한 후, 메시지 저장소에서 데이터를 다시 읽어 동일 로직으로 결과를 재생성 가능
+
+---
+
+## 5. Kappa vs Lambda (핵심 차이)
+
+| 항목 | Lambda Architecture | Kappa Architecture |
+| --- | --- | --- |
+| 처리 계층 | Batch + Stream | Stream만 존재 |
+| 기술 스택 | 배치 시스템 + 스트림 처리 | 단일 스트림 처리 |
+| 운영 복잡도 | 높음 | 낮음 |
+| 코드 중복 | 존재 (Batch & Stream) | 없음 |
+| 대규모 히스토리 처리 | 강점 (Hadoop 등 활용) | 메시지 로그 기반 재처리로 커버 가능 |
+| 배치 처리 | 별도 시스템 필요 | 필요 시 로그 재읽기 방식으로 처리 |
+- Lambda는 **배치 처리 계층**을 별도 두고, 실시간 + 배치를 각각 처리한다. 이로 인해 **관리/코드 복잡도**가 증가한다.
+- Kappa는 **스트림 처리만으로 양쪽을 커버**하며 단순함을 추구한다.
+
+---
+
+## 6. 장점
+
+- **단순함**: 하나의 파이프라인만 관리하면 됨
+- **유지보수 비용 감소**: 코드/시스템 중복 제거
+- **실시간 데이터 처리 우수**: 실시간 조회/분석 즉시 가능
+- **재처리 유연성**: 같은 스트림 로그를 재읽어 처리 가능
+
+---
+
+## 7. 단점 / 한계
+
+- **스트림에 대한 의존성**: 메시지 로그가 저장소 역할도 하기 때문에 용량/보존 전략 필요
+- **배치 최적화 부족**: 전통적 배치 시스템보다 대용량 데이터 처리 효율 낮을 수 있음
+- **도입 복잡도**: Kafka 및 스트림 처리 엔진에 익숙해야 함
+
+---
+
+## 8. 적용 시 고려사항
+
+- **데이터 보존 정책**: 로그 기반 저장은 데이터 보존/보관 전략 필요
+- **처리 엔진 성능**: 빠른 재처리와 실시간 처리 지원 엔진 필요 (예: Hazelcast, Flink 등)
+- **분석 요구사항**: 실시간 위주 또는 온디멘드 분석에 적합
+
+---
+
+## 9. 요약
+
+- Kappa Architecture는 실시간 데이터 처리 중심의 **단일 스트림 기반 아키텍처**
+- Lambda의 복잡성을 줄이고 운영/코드 중복을 없앤 단순한 모델
+- 스트림 저장소(Kafka)와 스트림 처리 엔진을 활용하여 실시간 + 배치(재처리) 요구를 모두 충족
\ No newline at end of file
diff --git a/chwwwon/Week04/chapter12.md b/chwwwon/Week04/chapter12.md
new file mode 100644
index 0000000..9814571
Binary files /dev/null and b/chwwwon/Week04/chapter12.md differ
diff --git a/chwwwon/Week04/references04.md b/chwwwon/Week04/references04.md
new file mode 100644
index 0000000..d37554b
Binary files /dev/null and b/chwwwon/Week04/references04.md differ