🐰 [flowbit] #10. 배포를 멈추고, 완성도 끌어올리다

☘️ 1. 오늘 상황

원래 오늘은 배포를 진행하려고 했다.

그런데 예상하지 못한 문제가 하나 생겼다.

기존에 사용하던 AWS 계정이
90일이 지나면서 동일한 이메일로 재사용이 불가능한 상태였다.

즉, 기존 이메일로는 계정을 다시 만들 수 없어서
다른 이메일을 사용해야 하는 상황이 되었다.

결국 계정 문제로 인해
배포는 잠시 미루게 되었다.

처음에는 흐름이 끊긴 느낌이 들었다.

하지만 곧 생각을 바꿨다.

지금은 배포보다 중요한 게 있다

---

☘️ 2. 방향 전환

지금 Flowbit은

기능 구현 완료
API 동작 완료
테스트 코드 최소 구성 완료

이미 동작하는 상태에 가까워졌다.

그래서 오늘은 방향을 바꿨다.

배포를 미루고, 프로젝트를 정리하자

---

☘️ 3. README 작성

오늘 한 작업은 하나였다.

→ README 작성

프로젝트를 처음 보는 사람이
이 구조를 이해할 수 있도록 정리하는 작업이었다.

구성은 다음과 같이 잡았다.

Overview
Problem
Solution
Architecture
Core Features
API Design
Key Design Decisions

특히 가장 신경 쓴 부분은 이것이었다.

왜 이 구조를 선택했는가

단순히 무엇을 만들었는지가 아니라
왜 이렇게 만들었는지를 설명하는 데 집중했다.

드디어 리드미가 생겼다!

---

☘️ 4. 오늘 작업의 의미

오늘은 기능을 추가한 날은 아니었다.

대신

프로젝트를 설명할 수 있는 형태로 만든 날이었다

코드를 작성하는 것과
그 구조를 정리하는 것은 다른 영역이다.

그리고 오늘은 그 차이를 느낀 날이었다.

---

☘️ 5. 현재 상태

Flowbit은 이제

동작하는 기능이 있고
테스트 코드가 존재하며
README를 통해 구조 설명이 가능한 상태가 되었다

---

☘️ 6. 다음 목표 (심화 개발 방향)

배포는 이번 주말에 한 번에 진행하기로 했다.

그 이후에는 단순히 기능을 추가하는 것이 아니라,
이벤트 기반 구조를 중심으로 프로젝트를 한 단계 더 확장해보려고 한다.

앞으로는 다음과 같은 방향으로 심화 개발을 이어갈 예정이다.

이벤트 기반 구조 확장

특정 시점 기준 상태 재구성 기능
이벤트 타입 확장 (상태 변경 외 다양한 이벤트 처리)

→ 단순 기록을 넘어 이벤트를 활용하는 구조로 확장

타임라인/분석 로직 고도화

상태별 체류 시간 계산
이벤트 흐름 기반 데이터 분석

→ 이벤트 데이터를 실제 의미 있는 정보로 변환

캐싱 및 성능 구조 설계

현재 Spring Cache 구조 검증
Redis 기반 캐싱 구조로 확장

→ 데이터 증가 상황을 고려한 성능 설계

도메인 및 확장성 설계

User / 협업 구조 확장 고려
Task와 사용자 관계 설계

→ 단일 사용자 도구 → 협업 시스템으로 확장 가능성 확보

프론트엔드 개선

상태별 시각적 구분 (색상, UI 구조)
타임라인 UI 정리
분석 화면 구성 개선
로딩/비동기 처리 UX 개선

→ 동작하는 화면에서 사용 가능한 UI로 개선

이 작업들은 단기간에 끝내는 것이 아니라
앞으로 한 달 동안 지속적으로 발전시켜 나갈 핵심 영역이다

---

☘️ 7. 다음 작업

다음 작업부터는 기능 추가보다 백엔드 구조를 더 단단하게 만드는 방향으로 진행한다.

먼저 트랜잭션 경계를 정리할 예정이다.

Flowbit에서는 Task 생성과 동시에 TaskEvent가 생성되고,
상태 변경 시에도 Task와 TaskEvent가 함께 변경된다.

이런 작업은 하나의 흐름으로 성공하거나 실패해야 하기 때문에
@Transactional을 적용해 데이터 정합성을 보장하는 구조로 개선할 예정이다.

이후에는 현재 Spring Cache 기반으로 잡아둔 캐싱 구조를
Redis와 연결하여 실제 캐시 저장소로 확장할 계획이다.