[7팀 윤지훈] Chapter 1-2. AI와 테스트를 활용한 안정적인 기능 개발

.gemini/Architecture.md

@@ -0,0 +1,85 @@
+# 아키텍처 설계 문서 V1.0
+
+## 1. 핵심 아키텍처 결정: 반복 일정 저장 방식
+
+### 1.1. PRD 요구사항 분석
+- PM의 PRD 4번(반복 일정 단일 수정) 및 5번(반복 일정 단일 삭제) 요구사항은 반복 시리즈 내 개별 일정에 대한 독립적인 관리가 필요함을 명시합니다.
+
+### 1.2. 채택 아키텍처: 개별 인스턴스(Individual Instances) 저장 방식
+- 반복 일정 생성 시, 반복 종료일까지의 모든 개별 일정 데이터를 미리 생성하여 저장하는 방식을 채택합니다.
+- 각 개별 일정은 고유한 `id`를 가지며, 동일한 반복 시리즈에 속하는 일정들은 공통의 `seriesId` (반복 그룹 ID)를 가집니다.
+
+### 1.3. 설계 상세
+- **반복 일정 생성:**
+    - 사용자가 반복 일정을 생성하면, 시작일부터 반복 종료일까지의 모든 개별 일정 인스턴스가 계산되어 데이터베이스에 저장됩니다.
+    - 각 인스턴스는 고유한 `id`와 해당 반복 시리즈를 식별하는 `seriesId`를 가집니다.
+- **단일 일정 수정 (PRD 4번 '예'):**
+    - 특정 일정 인스턴스만 수정할 경우, 해당 인스턴스의 `seriesId`를 `null`로 변경하여 반복 그룹과의 연결을 끊고 독립적인 '단일 일정'으로 취급합니다.
+    - 이로써 해당 일정은 더 이상 반복 시리즈의 영향을 받지 않습니다.
+- **전체 반복 일정 수정 (PRD 4번 '아니오'):**
+    - 특정 일정 인스턴스를 포함한 전체 반복 시리즈를 수정할 경우, 해당 인스턴스의 `seriesId`와 동일한 `seriesId`를 가진 모든 일정 인스턴스를 대상으로 수정 작업을 수행합니다.
+- **단일 일정 삭제 (PRD 5번 '예'):**
+    - 특정 일정 인스턴스만 삭제할 경우, 해당 인스턴스만 데이터베이스에서 제거합니다.
+- **전체 반복 일정 삭제 (PRD 5번 '아니오'):**
+    - 특정 일정 인스턴스를 포함한 전체 반복 시리즈를 삭제할 경우, 해당 인스턴스의 `seriesId`와 동일한 `seriesId`를 가진 모든 일정 인스턴스를 데이터베이스에서 제거합니다.
+
+### 1.4. 데이터 타입 정의 변경
+- `src/types.ts` 파일의 `Event` 타입에 `seriesId: string | null;` 필드를 추가합니다.
+    ```typescript
+    // src/types.ts (예시)
+    interface Event {
+      id: string;
+      title: string;
+      start: string; // YYYY-MM-DDTHH:mm:ss
+      end: string;   // YYYY-MM-DDTHH:mm:ss
+      seriesId: string | null; // 반복 일정 그룹 ID (단일 일정일 경우 null)
+      // ... 기타 필드
+    }
+    ```
+
+## 2. 기술 스택 및 컨벤션
+
+### 2.1. 핵심 기술 스택
+- **Core:** React (TypeScript)
+- **Testing:** Vitest (단위/통합 테스트), React Testing Library (RTL) (컴포넌트 상호작용 테스트)
+- **API Mocking:** MSW (Mock Service Worker) (네트워크 레벨 모킹)
+
+### 2.2. 공식 컨벤션 참조
+- 모든 테스트 및 코드 구현은 다음 3개의 공식 규칙 문서를 준수해야 합니다.
+    - `docs/kentcdodds-rtl-rules.md` (RTL 쿼리 철학 및 전략)
+    - `docs/rtl-official-query-guide.md` (RTL 쿼리 문법 가이드)
+    - `docs/tidy-first-tdd-workflow.md` (Tidy First 및 TDD 워크플로우)
+
+## 3. 도구 설정
+
+### 3.1. MSW (Mock Service Worker) 설정
+- `Dev-Junior`는 API 모킹을 위해 MSW를 사용해야 합니다.
+- Vitest 환경에서 MSW 서버(`setupServer`)를 설정하고, 각 테스트(`afterEach`) 후에 핸들러를 리셋(`server.resetHandlers()`)하도록 `src/setupTests.ts` 파일에 설정해야 합니다.
+- 공통 핸들러는 `src/__mocks__/handlers.ts`에 정의합니다.
+
+### 3.2. Vitest Mocking 컨벤션
+- 모듈 모킹 시 `jest.fn()` 대신 Vitest의 `vi.fn()` 또는 `vi.spyOn()`을 사용하도록 합니다.
+
+## 4. 컴포넌트 설계 제안
+
+### 4.1. `src/App.tsx` 및 관련 Hooks/Utils
+- `PRD.md`의 반복 일정 기능을 구현하기 위해 `src/App.tsx`, `src/hooks/useEventForm.ts`, `src/hooks/useEventOperations.ts`, 그리고 `src/utils/` 내의 관련 유틸리티 함수들을 수정/확장해야 합니다.
+- `App.tsx`의 기존 코드 구조를 반드시 참고하여 일관성 있는 설계를 유지합니다.
+
+### 4.2. 데이터 흐름 및 상태 관리
+- **`useEventForm` Hook:**
+    - 반복 유형, 반복 간격, 반복 종료일, `seriesId` 등의 상태를 추가하고 관련 로직을 처리하도록 확장합니다.
+    - 폼 제출 시, 선택된 반복 설정에 따라 개별 일정 인스턴스들을 생성하는 로직을 호출합니다.
+- **`useEventOperations` Hook:**
+    - 일정 생성, 수정, 삭제 로직을 포함하며, 반복 일정의 경우 `seriesId`를 기반으로 단일/전체 처리를 분기합니다.
+    - API 호출 시 `seriesId`를 포함하여 백엔드에 전달합니다.
+- **`src/utils/` 유틸리티 함수:**
+    - 반복 유형(매일, 매주, 매월, 매년)과 간격, 시작일, 종료일을 기반으로 개별 일정 날짜들을 계산하는 함수들을 구현합니다. (예: `calculateDailyDates`, `calculateWeeklyDates` 등)
+
+### 4.3. API Endpoint 제안
+- **`POST /api/events-series`:** 새로운 반복 일정 시리즈를 생성합니다. (백엔드에서 개별 인스턴스 생성 로직 처리)
+- **`PUT /api/events-series/:seriesId`:** 특정 `seriesId`를 가진 전체 반복 일정 시리즈를 수정합니다.
+- **`DELETE /api/events-series/:seriesId`:** 특정 `seriesId`를 가진 전체 반복 일정 시리즈를 삭제합니다.
+- **`PUT /api/events/:id/detach`:** 특정 `id`를 가진 단일 일정을 반복 시리즈에서 분리합니다. (해당 일정의 `seriesId`를 `null`로 변경)
+- **`PUT /api/events/:id`:** 단일 일정의 내용을 수정합니다. (seriesId가 null인 경우 또는 detach된 일정)
+- **`DELETE /api/events/:id`:** 단일 일정을 삭제합니다. (seriesId가 null인 경우 또는 detach된 일정)

.gemini/PRD.md

@@ -0,0 +1,58 @@
+# 제품 요구사항 문서 (PRD) V1.0
+
+## 1. 반복 유형 선택
+
+**사용자 스토리:**
+- 사용자는 일정을 생성하거나 수정할 때, 반복 옵션을 선택하여 동일한 일정을 주기적으로 생성할 수 있다.
+
+**수용 기준:**
+- [ ] 사용자는 일정 생성/수정 화면에서 반복 유형을 선택할 수 있다.
+- [ ] 선택 가능한 반복 유형은 '매일', '매주', '매월', '매년'이다.
+- [ ] 모든 반복 유형에 대해 '반복 간격'을 숫자로 입력할 수 있다. (예: '2'주마다, '3'개월마다)
+- [ ] '매월' 반복 시, 시작일이 31일인 경우 해당 월에 31일이 있을 때만 일정이 생성된다. (예: 2월에는 생성되지 않음)
+- [ ] '매년' 반복 시, 시작일이 2월 29일인 경우 윤년에만 일정이 생성된다.
+- [ ] 시스템은 반복 일정 생성 시 다른 일정과의 겹침을 고려하지 않아도 된다.
+
+## 2. 반복 일정 표시
+
+**사용자 스토리:**
+- 사용자는 캘린더에서 어떤 일정이 반복되는 일정인지 한눈에 알아볼 수 있다.
+
+**수용 기준:**
+- [ ] 캘린더 뷰에 표시되는 반복 일정에는 시각적 표시(예: 아이콘)가 포함되어야 한다.
+
+## 3. 반복 종료
+
+**사용자 스토리:**
+- 사용자는 반복 일정이 무한히 생성되지 않도록 특정 날짜에 반복이 종료되도록 설정할 수 있다.
+
+**수용 기준:**
+- [ ] 사용자는 반복 종료 조건으로 '특정 날짜까지'를 선택할 수 있다.
+- [ ] 사용자가 날짜를 선택하여 반복 종료일을 지정할 수 있다.
+- [ ] 최대 반복 종료일은 2025년 12월 31일로 제한된다.
+
+## 4. 반복 일정 수정
+
+**사용자 스토리:**
+- 사용자는 반복 일정 중 하나를 수정할 때, 해당 이벤트만 개별적으로 수정할지 아니면 전체 반복 시리즈를 수정할지 선택할 수 있다.
+
+**수용 기준:**
+- [ ] 사용자가 반복 일정 중 하나를 수정하려고 하면, "해당 일정만 수정하시겠어요?"라는 확인 창이 나타난다.
+- [ ] 확인 창에서 '예'(단일 수정)를 선택하면:
+    - [ ] 해당 일정만 '단일 일정'으로 변경되고, 기존 반복 시리즈에서 분리된다.
+    - [ ] 해당 일정에서 반복 아이콘이 사라진다.
+- [ ] 확인 창에서 '아니오'(전체 수정)를 선택하면:
+    - [ ] 해당 일정을 포함한 모든 과거 및 미래의 반복 일정이 함께 수정된다.
+    - [ ] 모든 관련 일정의 반복 속성과 아이콘은 그대로 유지된다.
+
+## 5. 반복 일정 삭제
+
+**사용자 스토리:**
+- 사용자는 반복 일정 중 하나를 삭제할 때, 해당 이벤트만 삭제할지 아니면 전체 반복 시리즈를 삭제할지 선택할 수 있다.
+
+**수용 기준:**
+- [ ] 사용자가 반복 일정 중 하나를 삭제하려고 하면, "해당 일정만 삭제하시겠어요?"라는 확인 창이 나타난다.
+- [ ] 확인 창에서 '예'(단일 삭제)를 선택하면:
+    - [ ] 해당 특정 날짜의 일정만 삭제된다.
+- [ ] 확인 창에서 '아니오'(전체 삭제)를 선택하면:
+    - [ ] 해당 일정을 포함한 모든 과거 및 미래의 반복 일정이 삭제된다.

.gemini/PROJECT_WORKFLOW.md

@@ -0,0 +1,61 @@
+# 프로젝트 TDD 오케스트라: 온보딩 가이드
+
+## 1. 프로젝트 개요
+이 프로젝트는 React와 TypeScript를 사용하여 TDD(테스트 주도 개발) 방법론에 따라 캘린더 애플리케이션의 '반복 일정' 기능을 구현합니다. 모든 개발 과정은 각자 명확한 역할을 가진 AI 에이전트들의 협업을 통해 오케스트레이션됩니다.
+
+## 2. AI 에이전트와 역할
+
+### 👨‍💼 **1. PM (스티브 잡스)**
+- **역할:** 최고 제품 책임자. **무엇을(What)** 만들지 정의합니다.
+- **입력:** 사용자(오케스트레이터)의 초기 업무 명세.
+- **산출물:** 제품의 상세 요구사항이 담긴 **`.gemini/PRD.md`** 파일을 작성하고 지속적으로 업데이트합니다.
+- **규칙:** 비개발자이며, 코드에는 절대 관여하지 않습니다.
+
+###  FONT-WEIGHT: 600; FONT-STYLE: NORMAL; COLOR: RGB(55,65,81); DISPLAY: INLINE; FONT-FAMILY: SFMONO-REGULAR, MENLO, MONACO, CONSOLAS, "LIBERATION MONO", "COURIER NEW", MONOSPACE; FONT-VARIANT-LIGATURES: NONE; WHITE-SPACE: PRE-WRAP;">**2. 아키텍트 (빌 게이츠)**
+- **역할:** 소프트웨어 아키텍트. **어떻게(How)** 만들지 기술적으로 설계합니다.
+- **입력:** `PRD.md` 파일.
+- **산출물:** 기술 스택, 데이터 구조, 컴포넌트 설계 등이 포함된 **`.gemini/Architecture.md`** 파일을 작성합니다.
+- **규칙:** 코드를 직접 수정하지 않으며, 설계 제안은 오직 `Architecture.md`를 통해서만 수행합니다.
+
+### 👨‍💻 **3. 스크럼 마스터 (마크 주커버그)**
+- **역할:** 스크럼 마스터. 거대한 개발 작업을 TDD 사이클에 맞는 **작은 스토리(Story)**로 분해합니다.
+- **입력:** `PRD.md`와 `Architecture.md` 파일.
+- **산출물:** 개발자가 즉시 TDD를 시작할 수 있도록, 모든 컨텍스트(요구사항, 아키텍처, 파일 경로, 커밋 메시지 등)가 포함된 **`.gemini/stories/Story-XXX.md`** 파일을 생성합니다.
+
+### 👦 **4. 주니어 개발자 (브라이언)**
+- **역할:** TDD 주니어 React 개발자. 주어진 스토리에 따라 **실제 코드를 작성**합니다.
+- **입력:** `Story-XXX.md` 파일.
+- **산출물:** TDD 사이클(RED → GREEN → REFACTOR)의 각 단계에 맞는 **테스트 코드와 프로덕션 코드를 `src/` 경로에 작성**합니다.
+- **규칙:** 스토리 파일에 명시된 작업 범위와 4대 핵심 규칙 문서를 엄격하게 준수합니다.
+
+### 👨‍🏫 **5. 시니어 QA (Off코치)**
+- **역할:** 시니어 QA 엔지니어 및 코드 리뷰어. **테스트 결과를 분석하고 코드를 검토 및 보완**합니다.
+- **입력:** Vitest 테스트 로그 및 브라이언이 작성한 코드.
+- **산출물:**
+    1. 테스트 결과(RED/GREEN)와 실패 원인 분석이 담긴 **`.gemini/log/X-log.md`** 파일.
+    2. "Gold Standard" 패턴에 따라 브라이언의 코드를 **직접 수정하고, 코드 주석으로 피드백**을 남깁니다.
+
+## 3. 핵심 TDD 워크플로우
+1.  **[준비]** `PM`이 `PRD.md`를, `아키텍트`가 `Architecture.md`를 작성합니다.
+2.  **[스토리 생성]** `스크럼 마스터`가 첫 번째 `Story-XXX.md` 파일을 생성합니다.
+3.  **[RED 단계]**
+    - `개발자`가 스토리 파일에 따라 **실패하는 테스트 코드**를 작성합니다.
+    - `QA`가 테스트 로그를 분석하여 의도된 실패(RED)인지 확인하고 로그를 기록합니다.
+4.  **[GREEN 단계]**
+    - `개발자`가 RED 테스트를 통과시키기 위한 **최소한의 프로덕션 코드**를 작성합니다.
+    - `QA`가 테스트 통과(GREEN)를 확인하고, 코드 리뷰 및 보완을 진행하며 로그를 기록합니다.
+5.  **[REFACTOR 단계]**
+    - `개발자`가 기능 변경 없이 코드 품질을 개선하는 **리팩토링**을 수행합니다.
+    - `QA`가 리팩토링 후에도 테스트가 여전히 통과(GREEN)하는지 회귀 테스트를 확인하고, 최종 리뷰를 진행하며 로그를 기록합니다.
+6.  **[반복]** 하나의 스토리가 완료되면, `스크럼 마스터`가 다음 `Story-XXX.md` 파일을 생성하며 위 과정을 반복합니다.
+
+## 4. 주요 디렉토리 및 문서
+- **`.gemini/`**: AI 에이전트들의 작업 공간입니다.
+    - **`agents/`**: 각 에이전트의 역할과 규칙이 정의된 명세서.
+    - **`docs/`**: 모든 에이전트가 따라야 할 핵심 규칙 및 컨벤션 문서.
+    - **`stories/`**: TDD 사이클의 기본 단위가 되는 개발 스토리 파일.
+    - **`log/`**: QA의 테스트 분석 및 코드 리뷰 기록.
+    - **`PRD.md`**: 제품 요구사항 문서.
+    - **`Architecture.md`**: 아키텍처 설계 문서.
+- **`src/`**: 실제 React 애플리케이션 소스 코드.
+    - **`__tests__/`**: Vitest 테스트 코드가 위치하는 디렉토리.

.gemini/agents/01-pm-steve-jobs.md

@@ -0,0 +1,95 @@
+# Role: PM Agent (스티브 잡스)
+
+## Mission
+당신은 '스티브 잡스'이며, 이 프로젝트의 '프로젝트 매니저(PM)'이자 '최고 제품 책임자'입니다.
+
+당신의 핵심 임무는 오케스트레이터(사용자)가 제공한 '초기 업무 명세'를 바탕으로, '빌 게이츠' Architect와 '마크 주커버그' Scrum Master가 참고할 수 있는 상세한 **PRD(제품 요구사항 문서)**를 작성하는 것입니다.
+
+당신은 TDD 사이클과 테스트 과정에서 발생하는 피드백을 수용하여 이 **PRD를 지속적으로 업데이트**해야 합니다.
+
+## Rules
+- **[역할 정의]** 당신은 **비개발자(Non-Developer)**입니다. 아키텍처의 필요성은 이해하지만, 기술적 구현이나 코드에 대해서는 절대 관여하지 않습니다.
+- **[소유권]** PRD와 '업무 명세' 원본은 **오직 당신(스티브 잡스)만이** 피드백을 받아 수정할 수 있습니다.
+- **[Code Modification Prohibition]** 당신은 **절대로 그 어떤 코드 파일(.ts, .tsx, .js 등)도 읽거나 수정해서는 안 됩니다.** 당신의 역할은 오직 '문서(PRD)' 관리에 한정됩니다.
+- **[작성 형식]** PRD는 '사용자 스토리(User Stories)'와 '수용 기준(Acceptance Criteria)' 형식을 우선적으로 사용합니다.
+- **[명확성]** PRD는 'Architect'가 기술 설계를, 'Scrum Master'가 개발 스토리를 명확하게 작성할 수 있도록 구체적이어야 합니다.
+- **[완전성]** 모든 긍정적/부정적 시나리오(예외 처리)를 고려하여 PRD에 반영해야 합니다.
+- **[산출물 위치]** 당신이 생성하는 PRD는 **`.gemini/PRD.md`** 파일 경로에 저장되어야 합니다.
+
+## Initial Business Specs (초기 업무 명세 V1.0)
+당신은 다음 '초기 업무 명세'를 바탕으로 PRD V1.0을 작성해야 합니다.
+
+1.  **반복 유형 선택**
+    * 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
+    * 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
+    * **[추가 요구사항]** 모든 반복 유형은 '반복 간격'(예: "2주마다", "3개월마다")을 지원해야 한다.
+    * 31일에 '매월'을 선택한다면 → 매월 31일에만 생성 (마지막 날 아님)
+    * 윤년 2월 29일에 '매년'을 선택한다면 → 2월 29일에만 생성 (윤년이 아닌 해에는 생성 안 됨)
+    * 반복 일정은 일정 겹침을 고려하지 않는다.
+
+2.  **반복 일정 표시**
+    * 캘린더 뷰에서 반복 일정을 아이콘을 넣어 구분하여 표시한다.
+
+3.  **반복 종료**
+    * 반복 종료 조건을 지정할 수 있다.
+    * 옵션: 특정 날짜까지
+    * (예제 특성상, 2025-12-31까지를 최대 반복 종료 일자로 가정한다.)
+
+4.  **반복 일정 수정**
+    * 수정 시 '해당 일정만 수정하시겠어요?' 라는 확인 창을 표시한다.
+    * '예' (단일 수정):
+        * 해당 일정은 '반복' 속성을 잃고 '단일 일정'으로 변경된다.
+        * 반복 일정 아이콘이 사라진다.
+    * '아니오' (전체 수정):
+        * 해당 일정을 포함한 '모든' 반복 일정이 수정된다.
+        * 반복 일정 속성과 아이콘이 유지된다.
+
+5.  **반복 일정 삭제**
+    * 삭제 시 '해당 일정만 삭제하시겠어요?' 라는 확인 창을 표시한다.
+    * '예' (단일 삭제):
+        * 해당 일정만 삭제한다.
+    * '아니오' (전체 삭제):
+        * 해당 일정을 포함한 '모든' 반복 일정이 삭제된다.
+
+---
+## ✅ Compliance Checklist
+- [ ] PRD가 '.gemini/PRD.md' 경로에 생성되었는가?
+- [ ] PRD가 '사용자 스토리'와 '수용 기준' 형식을 사용하는가?
+- [ ] 초기 업무 명세의 모든 요구사항(긍정/부정 시나리오 포함)이 반영되었는가?
+- [ ] 코드 파일을 읽거나 수정하지 않았는가?
+
+**최종 점수: [X]/4**
+
+## Input/Output 예시
+
+### Input (오케스트레이터 → PM)
+* 초기 업무 명세를 전달하며 PRD 생성을 요청할 때:
+    ```
+    스티브 잡스, 전달된 초기 업무 명세를 바탕으로 PRD V1.0을 작성해주세요.
+    ```
+* QA 또는 다른 에이전트의 피드백을 전달하며 PRD 업데이트를 요청할 때:
+    ```
+    스티브 잡스, QA 피드백('[피드백 내용 요약]')을 반영하여 `.gemini/PRD.md`를 업데이트해주세요.
+    ```
+
+### Output (PM → 파일 시스템: `.gemini/PRD.md`)
+* PRD 파일의 전체 내용을 마크다운 형식으로 생성합니다.
+* **좋은 예시 (PRD 내용 일부):**
+    ```markdown
+    # 제품 요구사항 문서 (PRD) V1.1
+
+    ## 1. 반복 유형 선택
+
+    **사용자 스토리:**
+    - 사용자는 일정을 생성하거나 수정할 때, 반복 옵션(...)을 선택하여 일정을 반복적으로 생성할 수 있다.
+
+    **수용 기준:**
+    - [ ] ...
+    - [ ] (수정됨) '매월' 선택 시 31일 설정은 해당 월에 31일이 있을 경우에만 일정이 생성된다. (예: 2월에는 생성 안 됨)
+    ... (이하 생략) ...
+    ```
+* **나쁜 예시 (Output에 포함되면 안 되는 내용):**
+    * 코드 스니펫 (`<RepeatOptions />` 컴포넌트 코드 등)
+    * 기술적인 구현 방법 설명 ("`calculateDates` 함수를 사용해야 합니다.")
+    * PRD 외의 다른 파일 내용 수정 제안
+---