🐰 [flowbit] #5. Project Timeline - 작업 흐름을 프로젝트 흐름으로 확장했다

☘️ 1. 오늘 목표

어제는
Project 도메인을 추가해서

작업들을 하나의 흐름 안에 넣었다.

이제 구조는 갖춰졌다.

근데 여기서 또 하나 부족한 게 있었다.

→ 프로젝트 단위로 흐름이 안 보인다

지금은

Task 하나의 흐름은 볼 수 있지만
Project 전체 흐름은 볼 수 없다

그래서 오늘 목표는 이거였다.

→ 프로젝트 안에서 어떤 일이 있었는지 한눈에 보이게 만들자

예를 들어,

여러 작업이 동시에 진행되는 상황에서
각 작업을 하나씩 보는 게 아니라

이 프로젝트에서 실제로 어떤 일들이 시간 순으로 일어났는지
한 번에 보고 싶은 경우가 있다.

---

☘️ 2. Task 타임라인의 한계

이미 이런 API는 있다.

GET /tasks/{id}/timeline

이건 작업 하나의 흐름을 보여준다.

근데 실제로 궁금한 건 이거다.

→ 이 프로젝트에서 실제로 무슨 일이 있었는가?

작업 하나만 보면 여전히 부분이다.

그래서 필요한 건

→ Project 기준 흐름

즉,

작업 단위가 아니라
→ 프로젝트 전체가 어떻게 흘러갔는지를 봐야 한다.

---

☘️ 3. Project Timeline API

그래서 만든 API가 이거다.

GET /projects/{id}/timeline

이 API는

프로젝트에 속한 모든 Task를 가져오고
그 Task들의 이벤트를 전부 모아서
시간순으로 정렬해서 반환한다

프로젝트 안에서 발생한 여러 작업 이벤트들이
하나의 시간 흐름으로 정렬되어 내려오는 것을 확인할 수 있다.

이제는

→ Task 하나가 아니라
→ 프로젝트 전체 흐름이 보인다

---

☘️ 4. 흐름을 합치는 방식

구조는 이렇게 흘러간다.

Project → Tasks → TaskEvents

코드 흐름으로 보면 이렇다.

List<Task> tasks = taskRepository.findByProject_IdAndStatusNot(projectId, TaskStatus.DELETED);

List<Long> taskIds = tasks.stream()
        .map(Task::getId)
        .toList();

List<TaskEvent> events = taskEventRepository.findByTaskIdInOrderByCreatedAtAsc(taskIds);

프로젝트에 속한 Task를 먼저 조회한 뒤,
해당 Task들의 id를 기준으로 이벤트를 한 번에 가져오는 구조다.

여기서 핵심은 이거다.

→ 여러 Task의 이벤트를 하나로 합친다

즉, Project 기준으로 직접 조회하는 것이 아니라
Task를 거쳐 Event를 조회하는 구조다.

---

☘️ 5. 왜 이렇게 했나

TaskEvent는 Task 기준으로 기록된다.

그래서 바로 Project로 조회할 수 없다.

중간 과정이 필요하다.

Project로 Task를 찾고
Task로 Event를 찾는다

즉

→ 관계를 타고 올라가는 구조

---

☘️ 6. 시간순 정렬이 핵심 ⭐

이 기능에서 가장 중요한 건

→ 정렬

findByTaskIdInOrderByCreatedAtAsc(...)

이 한 줄로

여러 Task의 이벤트가
하나의 시간 흐름으로 정리된다

단순히 데이터를 모으는 게 아니라
흩어져 있던 이벤트들을 하나의 시간 흐름으로 만들어주는 핵심 포인트다.

이게 중요한 이유는,

→ 여러 작업이 동시에 진행되는 상황에서도
→ 무슨 일이 먼저 일어났고, 그 다음에 어떤 변화가 있었는지를
하나의 흐름으로 볼 수 있기 때문이다.

---

☘️ 7. 관계 매핑 리팩토링 (@ManyToOne)

여기서 한 단계 더 갔다.

기존에는

Long projectId;

이렇게 단순 ID로 관리했는데

이걸 바꿨다.

@ManyToOne(fetch = FetchType.LAZY)
private Project project;

이렇게 바꾸니까

Task → Project 관계가 명확해지고
JPA 기준으로 자연스럽게 조회 가능해졌다

---

☘️ 8. Repository도 같이 바뀐다

이 구조가 되면서

메서드도 바뀐다.

기존:

findByProjectIdAndStatus(...)

변경:

findByProject_IdAndStatus(...)

이건 단순 문법이 아니라

→ 객체 관계 기반 조회로 바뀐 것

---

☘️ 9. 응답 구조도 정리

Entity 그대로 내려주는 건 안 맞아서

TaskResponse도 수정했다.

this.projectId = task.getProject().getId();
this.projectName = task.getProject().getName();

→ 필요한 정보만 내려주는 구조

---

☘️ 10. 오늘 정리

오늘 한 걸 한 줄로 정리하면 이거다.

여러 Task에 흩어져 있던 이벤트를 모아서
프로젝트 전체 흐름으로 재구성했다

---

☘️ 11. 현재 상태

Project 도메인 ✔️
Task ↔ Project 관계 ✔️
Default Project ✔️
Task Timeline ✔️
Project Timeline ✔️

이제는

→ 흐름을 조회하는 게 아니라
→ 흐름을 구성할 수 있는 상태가 됐다

---

☘️ 12. 다음 목표

여기서 끝이 아니다.

지금은 흐름을 나열만 하고 있다.

다음 단계는 이거다.

프로젝트 단위 통계 (얼마나 오래 걸렸는지)
상태별 체류 시간 분석
가장 오래 막힌 구간 찾기

→ 흐름을 해석하는 단계

그리고 한 단계 더 나가면

→ Redis를 붙여서
→ 계산 비용이 큰 조회를 캐싱할 예정

즉

단순 조회 → 흐름 이해 → 흐름 분석 → 성능 최적화 로 확장해 나갈 예정이다