diff --git a/docs/week02.md b/docs/week02.md
new file mode 100644
index 000000000..eda9d8cfd
--- /dev/null
+++ b/docs/week02.md
@@ -0,0 +1,296 @@
+# 🧭 루프팩 BE L2 - Round 2
+
+> 요구사항을 설계로 옮기는 힘, 도메인을 해석하는 힘을 기른다.
+>
+
+<aside>
+🎯
+
+**Summary**
+
+</aside>
+
+- 기능 요구사항을 **도메인 모델**, **시스템 설계**로 전환하는 흐름을 체험한다.
+- 시퀀스 다이어그램, 클래스 다이어그램, ERD 등을 활용해 **협력 구조와 데이터 구조**를 시각화한다.
+- 상품/주문/브랜드/좋아요 등 도메인을 중심으로 실습해본다.
+- 설계한 결과물을 기반으로 개발 준비를 마친다.
+
+<aside>
+📌
+
+**Keywords**
+
+</aside>
+
+- 요구사항 정리 / 기능 명세
+- 시퀀스 다이어그램
+- 클래스 다이어그램
+- ERD (Entity Relationship Diagram)
+- 도메인 모델 / 엔티티 / VO
+- 설계 문서화
+
+<aside>
+🧠
+
+**Learning**
+
+</aside>
+
+## 📋 요구사항 정리
+
+> **사용자 니즈**를 **기능 명세로 전환**하는 분석 과정이예요.
+>
+
+### 💡 실무에서 왜 중요할까?
+
+- 구현 후 **“이건 제가 원한 기능이 아니에요”** 라는 말을 듣지 말자
+- 기획/디자인/개발 간 **커뮤니케이션의 언어적 기준점**
+- 요구사항을 **객체, 테이블, API 설계로 연결**하기 위한 출발점
+
+### 🛠 어떻게 접근할까?
+
+1. 유저 시나리오 도출 → 자연어 설명
+2. 행위 중심 기능 목록 정리 (예: 사용자 관점에서의 기대 동작)
+3. **유스케이스 흐름** 작성 (Main / Alternate / Exception Flow)
+4. 각 흐름에 예외, 조건 분기, 후속 동작 포함
+
+### 💬 예시
+
+```markdown
+[유저 스토리]
+- 사용자는 상품을 찜할 수 있다.
+- 이미 찜한 상품을 다시 누르면 찜이 취소된다.
+
+[기능 흐름]
+1. 로그인 사용자만 가능
+2. 좋아요 누르면 존재 여부 판단
+3. 없으면 저장, 있으면 삭제
+4. 좋아요 수 반영
+```
+
+### ⚠ 자주 겪는 실수
+
+- 기능 중심만 있고 예외/조건이 없음 (ex. 로그인 여부 고려 안함)
+- 유스케이스 흐름을 너무 **추상적**으로 작성
+- 실제 흐름과 명세가 점차 이격이 발생
+
+---
+
+## 📋 유비쿼터스 언어
+
+> 모든 협업자가 **동일한 언어로 도메인을 이해하고 소통**하기 위한 전략적 용어 체계를 말해요.
+>
+
+### 💡 실무에서 왜 중요할까?
+
+- 용어 불일치로 인한 설계 오류를 줄임 (예: '상품' vs '아이템' 혼용)
+- 기획자, 디자이너, 개발자, QA가 같은 단어로 같은 개념을 이해
+- 코드와 문서 간 용어 정합성 유지 (코드 = 모델, 문서 = 명세)
+
+### 🛠 어떻게 접근할까?
+
+1. 도메인 용어를 정리하고 문서로 공유
+2. 기능/요구사항 문서, ERD, API 명세서, 클래스 명에 동일한 단어 사용
+3. 새로운 용어 도입 전엔 반드시 정의와 맥락 공유
+
+### 💬 예시
+
+```
+상품 → Product
+브랜드 → Brand
+좋아요 → Like
+주문 → Order
+```
+
+### ⚠ 자주 겪는 실수
+
+- 도메인마다 표현이 다른 것과 같이 통일 없이 사용
+- 코드에서는 영문/축약어, 기획서에서는 한글/다른 단어
+- enum, 상태 값 등에서 의미 없는 용어 사용 (ex. 상태1, 상태2)
+
+---
+
+## 📋 시퀀스 다이어그램
+
+> **객체 간 메시지 흐름을 시각화**하여 책임과 협력을 표현하는 도구예요.
+>
+
+### 💡 실무에서 왜 중요할까?
+
+- "누가 무엇을 책임지는가"를 명확히 파악 가능
+- 코드보다 빠르게 흐름 구조를 공유할 수 있음
+- 팀 내 협업(특히 프론트 ↔ 백엔드 ↔ 기획 간)에서 설계 커뮤니케이션 기반이 됨
+
+### 🛠 어떻게 접근할까?
+
+1. 기능 하나당 하나의 시퀀스를 만듦
+    1. **e.g.** 사용자 → Controller → Application → Domain → Infra
+2. 흐름의 순서, 조건 분기, 이벤트 발행 등을 표현
+3. 도구를 활용해 이를 시각화
+
+### 💬 Mermaid 예제
+
+```mermaid
+sequenceDiagram
+	participant User
+	participant LikeController
+	participant LikeService
+	participant ProductReader
+	participant LikeRepository
+
+	User->>LikeController: POST /products/{id}/like
+	LikeController->>LikeService: toggleLike(userId, productId)
+	LikeService->>ProductReader: get(productId)
+	LikeService->>LikeRepository: exists(userId, productId)
+	
+	alt 좋아요가 존재하지 않을 경우
+	LikeService->>LikeRepository: save()
+	
+	else 이미 좋아요한 경우
+	LikeService->>LikeRepository: delete()
+	
+end
+```
+
+### ⚠ 자주 겪는 실수
+
+- 너무 많은 세부 흐름을 다 넣어서 시퀀스가 복잡함
+- 도메인 객체 간 메시지 없이 Service만 호출
+- 시퀀스와 실제 구현이 따로 놀아 유지보수 불가능
+
+---
+
+## 📋 클래스 다이어그램 & 도메인 모델
+
+> **시스템 구성 객체** 간 구조와 책임을 시각화한 설계 도구예요.
+>
+
+### 💡 실무에서 왜 중요할까?
+
+- 도메인 개념 간 책임과 관계를 시각화함
+- 설계 → 코드 전환 시 자연스럽게 연결됨
+- 패키지 구조, 의존성 구조 설계에 기준이 됨
+
+### 🛠 어떻게 접근할까?
+
+1. 엔티티/VO 분리 기준: ID 존재 여부, 생명 주기
+2. 연관 관계: 단방향 기본, 양방향 최소화
+3. 비즈니스 책임은 도메인 객체에 포함시키기
+4. 설계 후, "한 객체에 책임이 몰리지 않았는가?" 점검
+
+### 💬 Mermaid 예제
+
+```mermaid
+classDiagram
+  class Product {
+    Long id
+    String name
+    Price price
+  }
+  class Brand {
+    Long id
+    String name
+  }
+  class Like {
+    Member member
+    Product product
+  }
+  class Member {
+    Long id
+    String name
+  }
+
+  Product --> Brand
+  Like --> Member
+  Like --> Product
+```
+
+### ⚠ 자주 겪는 실수
+
+- 모든 필드를 객체로 표현하려다 지나친 복잡도
+- 도메인 책임 없이 Service에 모든 로직 집중
+- VO를 테이블처럼 다루려는 시도 (ex. Price를 별도 DB로 설계)
+
+---
+
+## 📋 ERD 설계
+
+> **데이터 간 관계**를 정의하여 테이블 구조와 제약을 표현하는 모델이예요.
+>
+
+### 💡 실무에서 왜 중요할까?
+
+- 도메인 모델의 물리적 구현 기반
+- 성능 이슈(조회 쿼리, 인덱스 등)와 직결
+- API, 도메인, DB 간 구조 일관성 유지에 핵심 역할
+
+### 🛠 어떻게 접근할까?
+
+1. 1:N → 외래키, N:M → 조인 테이블로 설계
+2. enum → VARCHAR 또는 코드 테이블
+3. soft delete → `deleted_at` or `is_deleted` 플래그 방식
+4. 상태 관리: `status` 컬럼 활용하여 명확한 상태 전이 표현
+
+### 💬 Mermaid 예제
+
+```mermaid
+erDiagram
+  products {
+    bigint id PK
+    varchar name
+    bigint brand_id FK
+  }
+  brands {
+    bigint id PK
+    varchar name
+  }
+  likes {
+    bigint member_id PK, FK
+    bigint product_id PK, FK
+    timestamp created_at
+  }
+  members {
+    bigint id PK
+    varchar name
+  }
+
+  products ||--o{ likes : ""
+  members ||--o{ likes : ""
+  brands ||--o{ products : ""
+```
+
+### ⚠ 자주 겪는 실수
+
+- 비즈니스 흐름이 반영되지 않은 정규화만 추구
+- 중복 데이터 제거만 집중해 조회 JOIN이 과도해짐
+- 상태 컬럼 없음 → 코드에서 하드코딩으로 해결함
+
+<aside>
+📚
+
+**References**
+
+</aside>
+
+| 구분 | 링크 |
+| --- | --- |
+| 📚 도메인 주도 설계 | https://www.msaschool.io/operation/design/design-two/ |
+| 🎬 시퀀스 다이어그램 | https://www.ibm.com/docs/ko/rsas/7.5.0?topic=uml-sequence-diagrams |
+| 🗃 ERD | https://www.lucidchart.com/pages/er-diagrams |
+| 🧩 머메이드 | https://mermaid.js.org/ |
+
+> 원활한 실습 진행을 위해 다음 도구를 권장합니다.
+* `mermaid` : https://mermaid.live
+* `excalidraw` : https://excalidraw.com/
+* `lucid chart` : https://www.lucidchart.com/
+>
+
+<aside>
+🌟
+
+**Next Week Preview**
+
+</aside>
+
+> 다음 주에는 본격적으로 각 필요 객체들을 구현하고, 단위 테스트를 통해 안정적으로 기능을 작성합니다.
+>
\ No newline at end of file
diff --git a/docs/week02_quests.md b/docs/week02_quests.md
new file mode 100644
index 000000000..15776eb66
--- /dev/null
+++ b/docs/week02_quests.md
@@ -0,0 +1,101 @@
+<aside>
+🛠
+
+**Task**
+
+</aside>
+
+# 📝 Round 2 Quests
+
+---
+
+## ✍️ Design Quest
+
+> **이커머스 도메인(상품, 브랜드, 좋아요, 주문 등)에 대한 설계**를 완료하고, 다음 주부터 개발 가능한 수준의 설계 문서를 정리하여 PR로 제출합니다.
+>
+
+### 📋 과제 정보
+
+- **설계 범위**
+    - 상품 목록 / 상품 상세 / 브랜드 조회
+    - 상품 좋아요 등록/취소 (멱등 동작)
+    - 주문 생성 및 결제 흐름 (재고 차감, 포인트 차감, 외부 시스템 연동)
+- **제외 도메인**
+    - 회원가입, 포인트 충전 (1주차 구현 완료 기준)
+- **요구사항 기반**
+    - 루프팩 이커머스 시나리오 문서를 기준으로 기능/제약사항을 설계에 반영합니다.
+- **제출 방식**
+    1. 아래 파일들을 프로젝트 내 `docs/week2/` 폴더에 `.md`로 저장
+    2. Github PR로 제출
+        - PR 제목: `[2주차] 설계 문서 제출 - 홍길동`
+        - PR 본문에 리뷰 포인트 포함 (예: 고민한 지점 등)
+
+### ✅ 제출 파일 목록 (.docs/design 디렉토리 내)
+
+| 파일명 | 내용 |
+| --- | --- |
+| `01-requirements.md` | 유저 시나리오 기반 기능 정의, 요구사항 명세 |
+| `02-sequence-diagrams.md` | 시퀀스 다이어그램 최소 2개 이상 (Mermaid 기반 작성 권장) |
+| `03-class-diagram.md` | 도메인 객체 설계 (클래스 다이어그램 or 설명 중심) |
+| `04-erd.md` | 전체 테이블 구조 및 관계 정리 (ERD Mermaid 작성 가능) |
+
+## ✅ Checklist
+
+- [ ]  상품/브랜드/좋아요/주문 도메인이 모두 포함되어 있는가?
+- [ ]  기능 요구사항이 유저 중심으로 정리되어 있는가?
+- [ ]  시퀀스 다이어그램에서 책임 객체가 드러나는가?
+- [ ]  클래스 구조가 도메인 설계를 잘 표현하고 있는가?
+- [ ]  ERD 설계 시 데이터 정합성을 고려하여 구성하였는가?
+
+---
+
+## ✍️ Technical Writing Quest
+
+> 이번 주에 학습한 내용, 과제 진행을 되돌아보며
+**"내가 어떤 판단을 하고 왜 그렇게 구현했는지"** 를 글로 정리해봅니다.
+>
+>
+> **좋은 블로그 글은 내가 겪은 문제를, 타인도 공감할 수 있게 정리한 글입니다.**
+>
+> 이 글은 단순 과제가 아니라, **향후 이직에 도움이 될 수 있는 포트폴리오** 가 될 수 있어요.
+>
+
+### 📚 Technical Writing Guide
+
+### ✅ 작성 기준
+
+| 항목 | 설명 |
+| --- | --- |
+| **형식** | 블로그 |
+| **길이** | 제한 없음, 단 꼭 **1줄 요약 (TL;DR)** 을 포함해 주세요 |
+| **포인트** | “무엇을 했다” 보다 **“왜 그렇게 판단했는가”** 중심 |
+| **예시 포함** | 코드 비교, 흐름도, 리팩토링 전후 예시 등 자유롭게 |
+| **톤** | 실력은 보이지만, 자만하지 않고, **고민이 읽히는 글**예: “처음엔 mock으로 충분하다고 생각했지만, 나중에 fake로 교체하게 된 이유는…” |
+
+---
+
+### ✨ 좋은 톤은 이런 느낌이에요
+
+> 내가 겪은 실전적 고민을 다른 개발자도 공감할 수 있게 풀어내자
+>
+
+| 특징 | 예시 |
+| --- | --- |
+| 🤔 내 언어로 설명한 개념 | Stub과 Mock의 차이를 이번 주문 테스트에서 처음 실감했다 |
+| 💭 판단 흐름이 드러나는 글 | 처음엔 도메인을 나누지 않았는데, 테스트가 어려워지며 분리했다 |
+| 📐 정보 나열보다 인사이트 중심 | 테스트는 작성했지만, 구조는 만족스럽지 않다. 다음엔… |
+
+### ❌ 피해야 할 스타일
+
+| 예시 | 이유 |
+| --- | --- |
+| 많이 부족했고, 반성합니다… | 회고가 아니라 일기처럼 보입니다 |
+| Stub은 응답을 지정하고… | 내 생각이 아닌 요약문처럼 보입니다 |
+| 테스트가 진리다 | 너무 단정적이거나 오만해 보입니다 |
+
+### 🎯 Feature Suggestions
+
+- 좋아요 기능의 멱등성을 보장하기 위해 어떻게 설계할 수 있을까?
+- 주문 생성 시 재고/포인트 차감을 어떻게 연결했는가?
+- 도메인 객체를 어떻게 나누고 책임을 위임했는가?
+- ERD 설계 시 어떤 부분에서 고민이 있었는가?
\ No newline at end of file
diff --git a/docs/week2/01-requirements.md b/docs/week2/01-requirements.md
new file mode 100644
index 000000000..208fa39d3
--- /dev/null
+++ b/docs/week2/01-requirements.md
@@ -0,0 +1,175 @@
+# 요구사항 명세 - 루프팩 감성 이커머스 플랫폼
+## 개요
+이 문서는 루프팩 이커머스 시나리오를 기반으로 한 감성 이커머스 플랫폼의 요구사항을 유저 중심으로 명세합니다. 플랫폼은 사용자에게 직관적이고 감성적인 쇼핑 경험을 제공하며, 상품 탐색부터 주문 및 결제까지의 핵심 흐름을 중점으로 설계합니다. 이 요구사항은 기능 구현의 기준점이 되며, 유저 스토리와 기능 흐름을 통해 사용자 니즈를 명확히 반영합니다.
+
+- 설계 범위: 상품 목록 조회, 상품 상세 조회, 브랜드 조회, 상품 좋아요 등록/취소 (멱등 동작 지원), 주문 생성 및 결제 흐름 (재고 차감, 포인트 차감, 외부 시스템 연동).
+- 제외 도메인: 회원가입, 포인트 충전 (1주차 구현 완료 기준으로 가정: 회원 정보와 포인트 잔액은 이미 관리됨).
+- 요구사항 기반: 사용자 중심으로 상품 탐색, 찜 기능, 주문 프로세스를 강조하며, 감성적인 UI/UX를 고려하나 이번 명세에서는 기능적 측면에 초점.
+- 전제 조건: 모든 기능은 인증된 회원(로그인 상태)을 기본으로 가정하나, 상품/브랜드 조회는 비회원도 가능.
+
+이 명세는 유저 스토리 → 기능 흐름 → 요구사항(기본/추가(TBD)/제약) 순으로 구성되어 있습니다.
+
+## 용어 사전 (유비쿼터스 언어)
+모든 문서와 코드에서 동일하게 사용.
+
+- 상품 (Product): 판매되는 아이템
+- 브랜드 (Brand): 상품을 생산/판매하는 회사 또는 라벨
+- 좋아요 (Like): 사용자가 상품에 찜하는 기능
+- 주문 (Order): 사용자가 상품을 구매하는 행위 및 기록
+- 포인트 (Point): 사용자 보유 화폐. 단위는 원
+- 재고 (Stock): 상품의 남은 수량
+
+
+## 1. 상품 목록 조회
+### 유저 스토리
+> 사용자로서, 다양한 상품을 쉽게 탐색하고 싶다.
+> - 기본 순으로 추천된 목록이 나온다
+> - 사용자는 카테고리나 브랜드로 필터링할 수 있다.
+> - 정렬 기능으로 원하는 상품을 빠르게 찾을 수 있다.
+> 
+
+### 기능 흐름
+1. 사용자가 상품 목록 페이지에 접근한다 (회원/비회원 모두 가능).
+2. 시스템이 카테고리, 브랜드, 가격등의 필터와 정렬 기준을 적용하여 상품 목록을 조회한다.
+3. 조회된 상품 목록(기본 정보 포함)을 페이지네이션 형태로 사용자에게 반환한다.
+4. 후속: 사용자가 특정 상품을 선택하면 상품 상세 조회로 이동. 브랜드 영역을 선택하면 브랜드 조회로 이동.
+
+### 요구사항
+#### 기본 요구사항
+
+- 시스템은 회원 및 비회원에게 상품 목록을 제공해야 한다.
+- 상품 목록은 페이지네이션(페이지 번호, 사이즈)을 지원해야 한다.
+- 각 상품 항목은 이름, 가격, 대표 이미지, 좋아요 수, 재고 상태(재고 있음/품절)를 포함해야 한다.
+- 필터링을 지원해야 한다.
+    - 카테고리: 디지털기기, 가구/인테리어, 유아동, 여성의류, 여성잡화, 남성패션/잡화, 생활가전, 생활/주방, 스포츠/레저, 취미/게임/음반, 뷰티/미용, 식물. 가공식품, 건강기능식품, 반려동물용품, 티켓/교환권, 도서/음반/DVD
+    - 브랜드
+    - 가격: 최소가, 최대가
+- 정렬 기능을 제공해야 한다.
+    - 기본, 인기순: 좋아요 수 기준, 최신순: 등록시간 기준, 가격순(오름,내림) 
+- 조회 시 실시간 재고 상태를 반영하여 품절 상품을 필터링하거나 표시해야 한다.
+
+#### TBD: 현재 고려 중인 추가 요구사항
+
+- 검색 기능: 키워드 기반 상품 검색을 지원 (부분 일치, 브랜드/상품명 포함).
+- 할인 정보 반영: 조회 시점에 적용 가능한 할인(세일, 쿠폰)을 가격에 반영하여 표시.
+- 사용자 행동 로그 기반 개인화 추천 (예: 최근 본 상품, 좋아요 패턴).
+
+#### 제약사항
+
+최대 페이지 사이즈는 100으로 제한한다.
+재고가 0인 상품은 목록에서 제외하거나 별도 표시한다.(필터에서 선택 가능)
+
+## 2. 상품 상세 조회
+### 유저 스토리
+> 사용자로서, 상품의 세부 정보를 확인하고 구매 여부를 결정하고 싶다.
+> - 이미지, 설명, 가격, 설명 등을 자세히 볼 수 있다.
+> - 브랜드를 선택하여 해당 브랜드 정보를 확인할 수 있다.
+> - 회원으로서, 상품 상세에서 좋아요로 나중에 쉽게 찾아볼 수 있다. 
+> - 회원으로서, 주문으로 바로 이어질 수 있다
+> 
+
+### 기능 흐름
+1. 사용자가 상품 ID를 통해 상세 페이지에 접근한다.
+2. 시스템이 해당 상품의 상세 정보를 DB에서 조회한다.
+3. 상세 정보(이미지, 설명, 가격, 재고, 좋아요 수 등)를 사용자에게 반환한다.
+4. 후속: 좋아요 등록/해제 또는 주문 생성으로 연결 가능.
+
+### 요구사항
+#### 기본 요구사항
+- 시스템은 상품의 상세 정보를 제공해야 한다 (회원/비회원 모두 가능).
+- 상세 정보는 이름, 가격, 상세 설명, 다중 이미지, 재고 수량, 브랜드 정보, 좋아요 수를 포함해야 한다.
+- 실시간 재고 상태를 반영하여 '품절' 표시 또는 구매 불가 처리.
+- 조회 시 할인 적용 가격을 계산하여 표시.
+
+#### TBD: 현재 고려 중인 추가 요구사항
+- 리뷰: 사용자가 작성한 리뷰 목록과 평점 표시
+- 리뷰 요약: 평균 평점과 리뷰 수를 포함
+- 관련 브랜드 링크: 브랜드 조회로 연결되는 기능 제공
+- 장바구니 추가 기능 (추후 설계 시점에 반영)
+- 관련 상품 추천 (유사 카테고리 또는 브랜드 기반).
+
+#### 제약사항
+
+상품이 존재하지 않거나 삭제된 경우 에러 메시지 반환.
+
+## 3. 브랜드 조회
+### 유저 스토리
+> 사용자로서, 특정 브랜드의 상품을 한눈에 보고 싶다.
+> - 특정 브랜드를 선택하면 해당 브랜드의 상세 정보(이름, 로고, 소개)를 확인할 수 있다.
+> - 브랜드의 상품 목록을 볼 수 있다 (회원/비회원 모두 가능).
+
+### 기능 흐름 - 브랜드 조회
+1. 사용자가 특정 브랜드 ID로 접근한다.
+2. 시스템이 브랜드 정보와, 연관 상품을 조회한다.
+3. 브랜드 상세 정보 및 브랜드의 상품 목록을 반환한다.
+4. 후속: 상품 상세 조회로 연결 가능.
+
+### 요구사항
+#### 기본 요구사항
+- 시스템은 브랜드 정보를 제공해야 한다 (회원/비회원 모두 가능).
+- 브랜드 정보는 이름, 로고 URL, 설명을 포함해야 한다.
+- 브랜드의 연관 상품 목록을 함께 제공해야 한다.
+
+#### TBD: 현재 고려 중인 추가 요구사항
+- 브랜드 목록 조회 기능
+- 검색 기능: 브랜드 이름 키워드 검색
+- 브랜드 팔로우 기능으로 사용자 맞춤 알림.
+
+#### 제약사항
+예외: 브랜드가 존재하지 않을 경우 404 에러.
+
+## 4. 상품 좋아요 등록/취소
+### 유저 스토리
+> 회원으로서, 관심 상품을 찜하여 나중에 쉽게 찾고 싶다.
+> - 사용자는 상품을 찜할 수 있다.
+> - 이미 찜한 상품을 다시 누르면 찜이 취소된다.
+
+### 기능 흐름
+1. 회원이 상품 ID와 함께 좋아요/취소 요청을 보낸다.
+2. 시스템은 요청이 좋아요면 해당 상품에 대한 좋아요를 등록하고, 취소면 좋아요를 삭제한다.
+3. 시스템은 상품의 좋아요 수를 업데이트한다.
+
+### 요구사항
+#### 기본 요구사항
+- 회원 사용자 한정
+- 시스템은 요청이 좋아요면 해당 상품에 대한 좋아요를 등록하고, 취소면 좋아요를 삭제한다.
+- 시스템은 상품의 좋아요 수를 업데이트한다.
+
+#### TBD: 현재 고려 중인 추가 요구사항
+
+- 내 좋아요 목록 조회 기능 제공.
+- 브랜드 좋아요 기능
+- 좋아요 기반 추천 시스템 연동.
+
+#### 제약사항
+좋아요는 상품별로만, 브랜드 좋아요는 제외.
+최대 좋아요 수 제한 없음
+
+## 5. 주문 생성 및 결제 흐름
+### 유저 스토리
+> 회원으로서, 상품을 구매하고 싶다.
+> - 여러 상품을 한 번에 구매할 수 있다.
+> - 재고와 포인트가 충분하면 결제가 완료되어야 한다.
+> - 결제 실패 시 명확한 이유를 알려주어 재시도할 수 있어야 한다.
+> 
+
+### 기능 흐름
+1. 회원이 주문 요청(상품 ID, 수량, 포인트 사용 여부)을 보낸다. 
+2. 시스템이 각 상품의 가격을 계산하여 총 결제 금액을 산출한다.
+3. 시스템이 재고 확인 및 차감 (부족 시 실패).
+4. 시스템이 포인트 잔액을 확인하고 총 결제 금액만큼 차감한다 (부족 시 실패).
+5. 성공 시 주문 생성, 실패 시 롤백 (재고/포인트 복구).
+6. 예외: 재고/포인트 부족 시 에러 반환.
+
+### 요구사항
+#### 기본 요구사항
+- 주문 생성 시 재고 차감
+- 포인트 차감: 총 결제 금액 확인 후 잔액 차감
+- 다중 상품 주문 지원 (items 배열 기반).
+
+#### TBD: 현재 고려 중인 추가 요구사항
+결제 수단 다양화 (계좌이체, 간편결제).
+
+#### 제약사항
+환불 흐름은 이번 설계 제외.
+결제 수단은 포인트만 가정 (추후 확장).
diff --git a/docs/week2/02-sequence-diagrams.md b/docs/week2/02-sequence-diagrams.md
new file mode 100644
index 000000000..1cb760a68
--- /dev/null
+++ b/docs/week2/02-sequence-diagrams.md
@@ -0,0 +1,94 @@
+# 시퀀스 다이어그램
+
+
+
+### 상품 좋아요 등록
+```mermaid
+sequenceDiagram
+    participant User as 회원
+    participant Controller as LikeController
+    participant Service as LikeService
+    participant LikeRepo as LikeRepository
+    participant ProductRepo as ProductRepository
+
+    User->>Controller: POST /api/v1/like/products/{productId}
+    Controller->>Service: addLike(userId, productId)
+    Service->>LikeRepo: existsByUserAndProduct(userId, productId)
+    LikeRepo-->>Service: 존재 여부 반환 (이미 존재 시 무시 또는 에러)
+    
+    alt 존재하지 않음 (등록 가능)
+        Service->>LikeRepo: save(Like(userId, productId))
+        Service->>ProductRepo: incrementLikeCount(productId)
+        ProductRepo-->>Service: 좋아요 수 증가
+    end
+    
+    Service-->>Controller: 성공 응답 (멱등: 이미 등록 시 무시)
+    Controller-->>User: 응답
+```
+
+### 상품 좋아요 해제
+```mermaid
+sequenceDiagram
+    participant User as 회원
+    participant Controller as LikeController
+    participant Service as LikeService
+    participant LikeRepo as LikeRepository
+    participant ProductRepo as ProductRepository
+
+    User->>Controller: DELETE /api/v1/like/products/{productId}
+    Controller->>Service: removeLike(userId, productId)
+    Service->>LikeRepo: existsByUserAndProduct(userId, productId)
+    LikeRepo-->>Service: 존재 여부 반환 (없을 시 무시 또는 에러)
+    
+    alt 존재함 (취소 가능)
+        Service->>LikeRepo: deleteByUserAndProduct(userId, productId)
+        Service->>ProductRepo: decrementLikeCount(productId)
+        ProductRepo-->>Service: 좋아요 수 감소
+    end
+    
+    Service-->>Controller: 성공 응답 (멱등: 이미 취소 시 무시)
+    Controller-->>User: 응답
+```
+
+### 주문 생성 및 결제 흐름
+```mermaid
+sequenceDiagram
+    participant User as 회원
+    participant Controller as OrderController
+    participant Facade as OrderFacade
+    participant ProductService as ProductService
+    participant PointService as PointService
+    participant OrderService as OrderService
+    participant Repository as Repository
+
+    User->>Controller: POST /api/v1/orders (items: [{productId, quantity}, ...])
+    Controller->>Facade: createOrder(command)
+    Note over Facade: @Transactional 시작 - 전체 조율
+    Facade->>ProductService: calculateTotalAmount(items)
+    ProductService-->>Facade: 총 가격 반환
+    loop over items
+        Facade->>ProductService: checkAndDecreaseStock(productId, quantity)
+        ProductService->>Repository: getStockForUpdate(productId)  // 동시성 락
+        Repository-->>ProductService: 재고 반환
+        alt 재고 부족
+            ProductService-->>Facade: 실패
+            Facade-->>Controller: 실패 (롤백)
+        else 재고 충분
+            ProductService->>Repository: decreaseStock(productId, quantity)
+        end
+    end
+    Facade->>PointService: checkAndDeductPoint(userId, totalAmount)
+    PointService->>Repository: getPoint(userId)
+    Repository-->>PointService: 포인트 잔액 반환
+    alt 포인트 부족
+        PointService-->>Facade: 실패
+        Facade-->>Controller: 실패 (롤백: 재고 복구)
+    else 포인트 충분
+        PointService->>Repository: deductPoint(userId, totalAmount)
+        Facade->>OrderService: createOrder(userId, items)
+        OrderService->>Repository: save(Order(status=결제완료))
+        Repository-->>OrderService: 주문 생성
+    end
+    Facade-->>Controller: 성공/실패 응답 (실패 시 전체 롤백: 재고/포인트 복구)
+    Controller-->>User: 주문 결과 응답
+```
diff --git a/docs/week2/03-class-diagram.md b/docs/week2/03-class-diagram.md
new file mode 100644
index 000000000..e69de29bb
diff --git a/docs/week2/04-erd.md b/docs/week2/04-erd.md
new file mode 100644
index 000000000..e69de29bb