Feat/일정과 작업 분리

README.md

@@ -39,28 +39,30 @@ PinIt 이 추구하는 핵심 목적은 다음 세 가지입니다.
 
 ## 🧩 Domain Overview
 
-### 1. Schedule (일정 도메인)
+### 1. Task (작업 도메인)
 
-사용자가 실제로 수행하는 “할 일/작업”에 해당합니다.
+* 특정 시점 이전에 끝내야 하는 “일” 자체를 관리
+* 마감일, 중요도, 난이도(피보나치: 1, 2, 3, 5, 8, 13, 21)
+* Task 간 의존/우선순위, 작업 쪼개기 대상
+* 상태는 완료/미완료 중심 (시간대 실행 상태는 관리하지 않음)
 
-* 일정 타입 (집중 작업, 행정 작업, 짧은 업무 등)
-* 중요도 / 난이도
-* 예상 소요 시간
-* 마감 일자
-* 현재 상태 (예정, 진행 중, 완료 등)
-* 고정 일정 여부 (캘린더 상에서 움직일 수 있는지 여부)
+### 2. Schedule (일정 도메인)
 
-### 2. Dependency (일정 관계 도메인)
+* 특정 시간대에 실행되는 “일정/약속” 관리 (회의·약속 등 Task 없이도 생성 가능)
+* 지정 시작 시각, 상태(시작/일시정지/중지/완료), 실행 히스토리(누적 소요 시간)
+* 필요 시 기존 Task를 일정으로 복사해 시간 슬롯에 배치, 일정 완료/취소 시 연결된 Task 완료/미완료와 연동
 
-일정 간 “선후 관계”를 관리하는 도메인입니다.
+### 3. Dependency (작업 관계 도메인)
 
-* `from` 일정이 **먼저** 끝나야 `to` 일정을 시작할 수 있음
-* 일정 간 **사이클 검사**를 통해 잘못된 의존 관계를 방지
-* 일정 삭제 시 관련 의존 관계를 적절히 처리
+Task 간 “선후 관계”를 관리합니다.
+
+* `from` Task가 **먼저** 끝나야 `to` Task를 시작할 수 있음
+* Task 그래프를 기반으로 사이클 검사 수행
+* Task 삭제/연결 해제 시 연관된 의존 관계를 정리
 
 > 복잡한 의존관계/사이클 검사는 “복잡한 일정(프로젝트)”을 AI와 함께 구체화할 때 핵심이 되는 도메인입니다.
 
-### 3. Member / User (사용자 도메인)
+### 4. Member / User (사용자 도메인)
 
 사용자의 시간 사용 패턴 및 환경을 담는 도메인입니다.
 
@@ -70,41 +72,42 @@ PinIt 이 추구하는 핵심 목적은 다음 세 가지입니다.
 
 이 정보들을 기반으로, **AI 추천 시 “그 사람에게 맞는 플랜”**을 만들 수 있도록 설계합니다.
 
----
-
-## 🔧 주요 기능 (백엔드 기준)
-
-### 1. 일정 관리 API
+### API 버전 정책 (Task/Schedule 분리)
 
-* **일정 생성**
+* **V0**: 기존 호환용. 일정 생성/수정 시 Task를 함께 생성하거나 수정하며, 요청/응답에 작업 속성(마감일, 중요도/난이도[Fibonacci: 1,2,3,5,8,13,21])이 포함됩니다.
+* **V1**: 분리 권장. 일정 단독 CRUD/상태 전환만 다루며 Task 정보를 노출하지 않습니다.
+* **작업 → 일정 복사**: `POST /v1/tasks/{taskId}/schedules`로 기존 작업을 지정 시각에 일정으로 등록할 수 있습니다.
+* **삭제 플래그**: `DELETE /v1/tasks/{taskId}?deleteSchedules=` 혹은 `DELETE /v0|v1/schedules/{scheduleId}?deleteTaskAlso=` 로
+  연관 삭제 여부를 선택합니다(미설정 시 연관만 해제).
 
-    * 일정의 기본 정보(제목, 타입, 마감일, 중요도, 난이도, 예상 소요 시간 등)를 입력받아 생성
-* **일정 조회**
+---
 
-    * 특정 날짜의 일정 목록 조회
-    * 주간 단위 일정 조회 (ex. `/schedules/week`)
-* **일정 상세 조회**
+## 🔧 주요 기능 (백엔드 기준)
 
-    * 단일 일정의 상세 정보 반환
-* **일정 수정 (PATCH)**
+### 1. 작업(Task) 관리 API
 
-    * 변경된 필드만 부분 업데이트
-    * DTO에 없는 필드가 `null` 로 덮어씌워지는 문제를 피하기 위해
-      **“Patch 전용 객체/도메인 로직”**을 두는 방향으로 설계
-* **일정 삭제**
+* **작업 생성**: 제목/설명/마감일/중요도/난이도[Fibonacci]/TaskType/의존 관계 입력
+* **작업 조회·상세**: 회원별 작업 목록 및 단건 조회
+* **작업 수정 (PATCH)**: 변경 필드만 부분 업데이트(패치 객체로 null 덮어쓰기 방지)
+* **작업 완료/되돌리기**: 완료 ↔ 미완료 상태 전환
+* **작업 삭제**: 의존 관계 함께 삭제, 옵션으로 연관 일정 삭제 또는 분리
+* **작업 → 일정 복사**: 기존 작업을 지정 시각의 일정으로 등록
 
-    * 삭제 시 관련 의존관계를 포함한 도메인 규칙을 지키도록 구현
+### 2. 일정(Schedule) 관리 API
 
-### 2. 일정 의존관계 관리
+* **일정 생성**: V1은 제목/설명/지정 시작 시각만으로 일정 생성(작업 없이 가능), V0 레거시는 Task 속성까지 포함해 일정+작업 동시 생성
+* **일정 조회·상세**: 특정 날짜/주간 목록 조회, 단건 조회
+* **일정 수정 (PATCH)**: 제목/설명/지정 시작 시각 등 변경 필드만 부분 업데이트
+* **일정 상태 전환**: 시작, 일시중지, 재시작, 완료, 취소
+* **일정 삭제**: 상태 규칙을 준수해 삭제, 필요 시 연관 Task 상태 연동
 
-* 일정 간 **선행/후행 관계 등록**
-* 일정 삭제 시, 연관된 의존관계 정리
-* **사이클 검사**
+### 3. 의존관계 관리
 
-    * 사용자의 모든 의존 그래프를 기반으로 위상 정렬 등으로 사이클 여부 검사
-    * 잘못된 의존관계로 인해 계획이 꼬이는 것을 방지
+* Task 간 **선행/후행 관계 등록**
+* **사이클 검사**로 잘못된 의존 그래프 방지
+* Task 삭제/분리 시 연관 의존관계 정리
 
-### 3. 통계 및 피드백을 위한 데이터 수집
+### 4. 통계 및 피드백을 위한 데이터 수집
 
 (구현/설계 범위에 맞추어 점진적으로 확장)
 
@@ -162,4 +165,3 @@ PinIt 이 추구하는 핵심 목적은 다음 세 가지입니다.
 
 
 ---
-

docs/다음 풀 리퀘스트/다음 풀 리퀘스트.md

@@ -0,0 +1,7 @@
+## 프론트/타 서비스가 바뀐 뒤에야 수행할 수 있는 작업들
+
+- [ ] 일정에 존재하는 사이클 체크 관련 기능이 작업으로 이동해야 함
+    - 일정은 의존 관계 및 사이클 체크 기능이 없음. 작업에서만 존재
+- [ ] V0 제거 - 일정은 일정만, 작업은 작업만
+    - README.md 문서와 "Task과 Schedule 분리.md" 참고
+    - 더 이상 프론트는 V0 인터페이스를 사용하지 않음

docs/일정과 작업 분리/Task와 Schedule 분리.md

@@ -0,0 +1,76 @@
+# Task와 Schedule 분리
+
+## 작업(Task)과 일정(Schedule)의 분리 필요성
+
+- 작업
+    - 특정 시점 이전까지 완성되어야 하는 일
+    - 작업은 근데 우선순위가 있다. - 사전일정/사후일정 넣기
+    - 일정 쪼개기 기능은 작업에만 해당됨 - 일정 쪼개기가 아닌 작업 쪼개기
+- 일정
+    - 다른 사람과 함께 정한 반드시 그 시간대에 진행되어야 하는 일
+    - 일정은 우선순위가 없다. - 사전일정/사후일정 없음
+    - 일정은 시작/일시정지/중지/완료 기능이 필요함
+        - 일정은 현재 사용자의 진행하고 있는 상태를 반영해야 함 - ScheduleState 개념이 그대로 존재
+        - 작업은 완료/미완료 상태만 반영하면 됨
+    - 일정을 어느 시간에 넣어야 하는가에 대한 자동화 - 일정 자동 배치 기능
+    - 진행한 일정에 대한 통계 - 일정 통계 기능
+
+- 일정은 반드시 작업과 연결될 필요는 없음
+  - 사용자는 단순히 일정만 등록할 수 있어야 함
+  - 예: 회의, 약속 등
+
+- 작업은 사용자의 원함에 의해, 일정으로 복사될 수 있음
+    - 사용자는 작업을 오늘의 일정에 등록하고, 그 일정에 맞춰 작업을 진행할 수 있음
+    - 만약 해당 일정이 완료되면, 작업도 완료 처리됨
+    - 만약 해당 일정이 취소되면, 작업도 미완료 상태로 돌아감
+
+## Task와 Schedule 의 도메인 상태 분리
+
+- Task
+    - id
+    - title
+    - description
+    - dueDate
+    - isCompleted
+    - ImportanceConstraint
+    - TemporalConstraint
+  - inboundTaskCount
+    - createdAt
+    - updatedAt
+
+- Schedule
+    - id
+    - title
+    - description
+    - designatedStartTime
+    - state (예: 예정, 진행 중, 일시 정지, 완료)
+    - ScheduleHistory
+    - createdAt
+    - updatedAt
+
+> Dependency는 Task 기반으로 각 작업의 우선순위를 정하는 데 사용
+
+## 총 기능
+
+하단 네비게이션 바가 다음과 같이 분류되어야 한다.
+
+- 오늘 할당된 일
+    - 오늘 일정을 디테일하게 볼 수 있는 화면
+- 일정
+- 작업
+- 통계
+
+그리고, + 버튼이 일정과 작업을 함께 관리해선 안된다.
+오늘 할당된 일이 일정과 작업을 함께 확인해서, 오늘 추천할 일을 결정하도록 해야 한다.
+
+(혹은, 오늘 할 일의 빠른 추가용도의 버튼으로 남아있는 것)
+
+---
+
+이 문서대로 코드를 변경한다.
+
+이때, 프론트에 공개되는 API가 변경되어야 할 경우에는, V1로 버저닝 후 새 클래스를 추가한다.(OCP 준수)
+
+
+
+> 이후 일정/작업/통계 도메인 각각 멀티모듈로 변경 필요

docs/일정과 작업 분리/일정과 작업 분리 보완.md

@@ -0,0 +1,34 @@
+## Task
+
+- [x] 일정 삭제 시 연결된 작업 삭제 금지
+    - 작업 삭제 시 연결된 일정도 삭제는 있어야 하는 기능이지만,
+    - 일정 삭제 시 연결된 작업 삭제는 하지 않는다.
+- [ ] 통계는 작업 타입에 따라 집계, 일정 누계 시간에 따라 추가
+    - 일정과 작업이 함께 사용되는 문제. 이걸 통계에서 어떻게 집계할지 고민 필요
+    - Recorder를 어떻게 처리할지...
+- [x] ScheduleControllerAdvice에 Task 예외가 처리되고 있음
+    - 이 예외 처리는 전용 TaskControllerAdvice에 존재해야 함.
+- [x] 작업의 조회 방식
+    1. 데드라인 기반 페이지네이션(정렬) 기능 지원
+    2. 사용자의 선택으로, "지금 시작할 수 있는 일정" 보기
+
+    - 작업 도메인에, 자신으로 들어오는(inbound) 의존 관계가 추가될 때마다 카운트하는 변수 추가
+    - 지금 시작할 수 있는 일정 조회 시, inbound 일정이 0개인 일정 조회
+
+- [x] 작업 조회 페이지네이션
+  - 커서 기반 페이지네이션으로 변경 필요
+
+## Task - Schedule
+
+- [x] 일정과 작업은 일대일 관계임
+    - 실제 @OneToOne 관계로 바꾸는 건 아니지만, 유니크 제약 조건을 둬야 함
+- [x] 작업의 내용을 복사해서 날짜 지정 후 일정 생성은 가능하지만, 반대 방향은 안 됨
+    - 일정에서 작업을 생성하는 건 불가능. 작업에서 일정을 생성하는 것만 가능
+
+생각보다 일정-작업 연동은 강력한 기능이다.
+
+- 작업에서 생성한 일정만 작업과 연동됨
+- 연동이 끊긴 일정은 다시 작업과 연동 불가능
+- 작업에서 생성한 일정이 완료되면 작업도 완료
+- 작업이 완료되면 연동된 일정도 완료
+- 일정 진행 중 연동된 작업이 완료되는 건 막아야 함.

src/main/java/me/gg/pinit/pinittask/application/dependency/service/DependencyService.java

@@ -4,17 +4,23 @@
 import me.gg.pinit.pinittask.domain.dependency.model.Graph;
 import me.gg.pinit.pinittask.domain.dependency.repository.DependencyRepository;
 import me.gg.pinit.pinittask.domain.dependency.repository.FromToPair;
+import me.gg.pinit.pinittask.domain.task.model.Task;
+import me.gg.pinit.pinittask.domain.task.repository.TaskRepository;
 import org.springframework.stereotype.Service;
 import org.springframework.transaction.annotation.Transactional;
 
 import java.util.List;
+import java.util.Map;
+import java.util.stream.Collectors;
 
 @Service
 public class DependencyService {
-    private DependencyRepository dependencyRepository;
+    private final DependencyRepository dependencyRepository;
+    private final TaskRepository taskRepository;
 
-    public DependencyService(DependencyRepository dependencyRepository) {
+    public DependencyService(DependencyRepository dependencyRepository, TaskRepository taskRepository) {
         this.dependencyRepository = dependencyRepository;
+        this.taskRepository = taskRepository;
     }
 
     @Transactional(readOnly = true)
@@ -26,34 +32,54 @@ public boolean checkCycle(Long memberId, List<Dependency> removedDependencies, L
 
 
     @Transactional(readOnly = true)
-    public List<Long> getNextScheduleIds(Long memberId, Long scheduleId) {
+    public List<Long> getNextTaskIds(Long memberId, Long taskId) {
         List<Dependency> allByOwnerId = dependencyRepository.findAllByOwnerId(memberId);
         Graph graph = Graph.of(allByOwnerId);
-        return graph.getNextScheduleIds(scheduleId);
+        return graph.getNextTaskIds(taskId);
     }
 
     @Transactional(readOnly = true)
-    public List<Long> getPreviousScheduleIds(Long memberId, Long scheduleId) {
+    public List<Long> getPreviousTaskIds(Long memberId, Long taskId) {
         List<Dependency> allByOwnerId = dependencyRepository.findAllByOwnerId(memberId);
         Graph graph = Graph.of(allByOwnerId);
-        return graph.getPreviousScheduleIds(scheduleId);
+        return graph.getPreviousTaskIds(taskId);
     }
 
     @Transactional
     public void saveAll(List<Dependency> dependencies) {
+        updateInboundCount(dependencies, 1);
         dependencyRepository.saveAll(dependencies);
     }
 
     @Transactional
     public void deleteAll(List<Dependency> dependencies) {
+        updateInboundCount(dependencies, -1);
         List<FromToPair> fromToPairs = dependencies.stream()
                 .map(dependency -> new FromToPair(dependency.getFromId(), dependency.getToId()))
                 .toList();
         dependencyRepository.deleteByFromToPairs(fromToPairs);
     }
 
     @Transactional
-    public void deleteWithScheduleId(Long scheduleId) {
-        dependencyRepository.deleteAllRelatedToSchedule(scheduleId);
+    public void deleteWithTaskId(Long taskId) {
+        List<Dependency> outgoing = dependencyRepository.findAllByFromId(taskId);
+        updateInboundCount(outgoing, -1);
+        dependencyRepository.deleteAllRelatedToTask(taskId);
+    }
+
+    /**
+     * 추가되는 의존관계에 맞춰, 연결된 Task들의 inbound Count를 조정해준다.
+     *
+     * @param dependencies
+     * @param delta
+     */
+    private void updateInboundCount(List<Dependency> dependencies, int delta) {
+        if (dependencies.isEmpty()) {
+            return;
+        }
+        Map<Long, Long> toCount = dependencies.stream()
+                .collect(Collectors.groupingBy(Dependency::getToId, Collectors.counting()));
+        List<Task> tasks = taskRepository.findAllByIdInWithOptimisticLock(toCount.keySet());
+        tasks.forEach(task -> task.adjustInboundDependencies(Math.toIntExact(toCount.get(task.getId()) * delta)));
     }
 }