179 lines
18 KiB
Markdown
179 lines
18 KiB
Markdown
# 인수인계 메모
|
|
|
|
## 프로젝트 개요
|
|
|
|
- 프로젝트명: 10 Minute Planner 웹 UI
|
|
- 기술 스택: Vue 3 + Vite + TailwindCSS + JavaScript
|
|
- 현재 기준 버전: `v0.1.27` 준비 중
|
|
- Git 원격 저장소: `https://git.sori.studio/zenn/planner.sori.studio.git`
|
|
|
|
## 기준 디자인
|
|
|
|
- Figma 펼침형 보기: `https://www.figma.com/design/ZgIAmg2YlVWpABD7JVLPzY/Untitled?node-id=1-36&m=dev`
|
|
- Figma 집중형 보기 + 사이드 정보: `https://www.figma.com/design/ZgIAmg2YlVWpABD7JVLPzY/Untitled?node-id=1-2472&m=dev`
|
|
|
|
## 현재 제품 방향
|
|
|
|
- 기본 UX 방향은 `1페이지 + 추가 정보 패널`이다.
|
|
- `2페이지 펼침 보기`는 비교용 보조 모드로 함께 유지한다.
|
|
- 화면 인상은 종이 다이어리 같아야 하지만, 상호작용은 웹앱처럼 빠르고 자연스러워야 한다.
|
|
- 현재는 개인용 단일 브라우저 흐름으로 개발 중이지만, 이후 회원 기반 개인 문서 관리 서비스로 확장해야 한다.
|
|
- 최종적으로는 프론트엔드와 백엔드를 Docker로 묶어서 UGREEN NAS에서 구동할 예정이다.
|
|
- `backend/` 폴더에 백엔드 초안이 추가되었고, 현재는 프론트와 분리된 구조로 관리한다.
|
|
|
|
## 현재 구현 상태
|
|
|
|
- 메인 화면 셸: `src/App.vue`
|
|
- 플래너 종이 레이아웃: `src/components/PlannerPage.vue`
|
|
- 우측 달력 컴포넌트: `src/components/MiniCalendar.vue`
|
|
- 프론트 인증 모달: `src/components/AuthDialog.vue`
|
|
- 프론트 인증 클라이언트: `src/lib/authClient.js`
|
|
- 백엔드 엔트리 포인트: `backend/src/server.js`
|
|
- 백엔드 DB 스키마: `backend/src/db/schema.js`
|
|
- 백엔드 인증 라우트: `backend/src/routes/auth.js`
|
|
- 백엔드 목표 라우트: `backend/src/routes/goals.js`
|
|
- 백엔드 비밀번호/세션 유틸: `backend/src/lib/password.js`
|
|
- Docker Compose 진입점: `docker-compose.yml`
|
|
- 프론트 Dockerfile: `Dockerfile`
|
|
- 백엔드 Dockerfile: `backend/Dockerfile`
|
|
- nginx 프록시 설정: `deploy/nginx/default.conf`
|
|
- 실행 가이드 문서: `README.md`
|
|
- Tailwind 설정은 완료되어 있으며, 이 프로젝트의 스타일링 기준으로 유지한다.
|
|
- 현재 선택 날짜는 시스템 날짜 기준으로 시작한다.
|
|
- `COMMENT`, `TASKS`, `MEMO`는 화면에서 바로 편집할 수 있다.
|
|
- TASKS 왼쪽 라벨은 순번 고정이 아니라 자유 입력 가능하며, 기본값은 빈 상태다.
|
|
- MEMO 왼쪽 라벨 칸도 자유 입력 가능하다.
|
|
- TASKS 체크박스는 토글 가능하며, 체크 상태는 바로 시각적으로 반영된다.
|
|
- STATS 완료율은 전체 15칸이 아니라, 실제로 입력된 TASKS만 기준으로 계산한다.
|
|
- `TIME TABLE`은 드래그로 10분 블록을 연속 선택할 수 있다.
|
|
- `TIME TABLE`은 우클릭 드래그 시 선택된 블록을 지우는 방식으로도 편집할 수 있다.
|
|
- `TIME TABLE` 숫자 영역은 선택/드래그로 텍스트가 잡히지 않도록 막아두었다.
|
|
- `TOTAL TIME`은 타임테이블에서 선택된 블록 수를 기준으로 자동 계산된다.
|
|
- 달력은 연/월 이동이 가능하며, 현재 보이는 월과 선택된 날짜 상태를 분리해서 관리한다.
|
|
- 달력 상단은 월 좌우 화살표, 클릭형 연도 선택, `TODAY` 버튼 구조로 동작한다.
|
|
- 입력 내용이 있는 날짜는 달력 하단에 빨간 점으로 표시된다.
|
|
- 상단 날짜 표시에서는 토요일의 `(토)`만 파란색, 일요일의 `(일)`만 빨간색으로 표시한다.
|
|
- 플래너 상태는 `localStorage`에 저장되며, 날짜별 기록과 선택 날짜, 달력 보고 있던 월까지 복원된다.
|
|
- `localStorage` 접근 로직은 `src/lib/plannerStorage.js`로 분리하기 시작했고, 이후 API/DB adapter로 교체하기 쉬운 구조로 정리 중이다.
|
|
- 프론트는 헤더에서 `LOGIN` / `SIGN UP` 모달을 열 수 있고, 로그인 상태면 닉네임과 `LOGOUT` 버튼을 표시한다.
|
|
- 인증 토큰과 현재 사용자 정보는 프론트 로컬 저장소에 따로 유지하고, 앱 시작 시 `/api/auth/me`로 세션 복원을 시도한다.
|
|
- 프론트 플래너 API 클라이언트는 `src/lib/plannerApi.js`에 추가되었다.
|
|
- 프론트 목표 API 클라이언트는 `src/lib/goalsApi.js`에 추가되었다.
|
|
- 루트에서 `npm run dev:backend`, `npm run db:generate`, `npm run db:migrate`로 백엔드 명령을 호출할 수 있다.
|
|
- 화면 탭은 `PLANNER / STATS / GOALS / SETTINGS` 기준으로 확장되었다.
|
|
- 기존 상단 헤더는 왼쪽 사이드 내비게이션으로 재구성되었고, A5 본문이 더 넓게 보이도록 조정되었다.
|
|
- 상단 전환 버튼으로 `PLANNER / STATS` 화면을 오갈 수 있다.
|
|
- 통계 화면에서는 전체 집중 시간, 평균 완료율, 기록 일수, 최근 7일 흐름, 최근 기록, 베스트 데이를 보여준다.
|
|
- 통계 화면은 시작일/종료일을 직접 선택해 그 기간 기준으로 지표를 다시 계산할 수 있다.
|
|
- `NEXT DAY` 영역의 요일도 본문 날짜와 같은 규칙으로 주말 색상이 적용된다.
|
|
- 플래너 화면에서는 `PRINT DAY` 버튼으로 현재 선택 날짜 문서를 바로 출력할 수 있다.
|
|
- 인쇄 시에는 현재 선택된 하루 플래너 본문만 남기고, 헤더/사이드패널/통계 화면은 숨긴다.
|
|
- 출력 버튼은 `PRINT 1-UP` / `PRINT 2-UP`으로 분리되어 있다.
|
|
- `PRINT 2-UP`은 현재 날짜와 다음 날짜를 A4 가로 기준으로 나란히 출력하는 용도다.
|
|
- 인쇄는 일반 화면을 그대로 찍는 방식이 아니라, 별도의 `print-only` 전용 레이아웃을 사용한다.
|
|
- A5 원본 비율을 유지한 채 A4 가로 안에 들어가도록 `1-UP` / `2-UP` 각각 별도 배율로 압축한다.
|
|
- `PRINT 1-UP`은 A4 세로, `PRINT 2-UP`은 A4 가로 기준으로 분리해서 처리한다.
|
|
- 브라우저 기본 인쇄 머리말/꼬리말이 켜져 있어도 2장으로 넘어가지 않도록 실제 인쇄 영역은 종이보다 조금 작게 잡는다.
|
|
- 인쇄 시 `main`, `print-only`, `print-paper` 래퍼의 패딩/높이/페이지 분할 규칙까지 함께 제어해야 빈 2페이지를 줄일 수 있다.
|
|
- `1-UP`은 여백이 과하지 않도록 다시 확대했고, `2-UP`은 한 페이지 고정 안정성을 위해 가로 폭과 세로 높이를 조금 더 보수적으로 조정했다.
|
|
- `1-UP`은 세로 가운데 정렬을 없애고 상단 기준으로 붙여야 여백이 덜 커 보인다.
|
|
- 현재 `1-UP`은 프레임 자체를 A4 세로에 가깝게 키우고 배율을 크게 올려 빈 여백을 줄이는 방향으로 맞추고 있다.
|
|
- 백엔드 초안은 `Fastify + Drizzle + PostgreSQL` 조합으로 전환되었다.
|
|
- 백엔드에는 `/api/auth/signup`, `/api/auth/login`, `/api/auth/me`가 추가되었다.
|
|
- 백엔드에는 `/api/planner/:entryDate` 단건 조회/저장과 `/api/planner?from=...&to=...` 범위 조회가 추가되었다.
|
|
- 비밀번호는 Node 내장 `crypto.scrypt` 기반 해시로 저장하고, 세션 토큰은 `auth_sessions` 테이블에 해시 형태로 저장한다.
|
|
- 초기 실행 시 `backend/src/db/init.js`에서 테이블이 없으면 자동 생성하도록 맞춰두었다.
|
|
- 플래너 저장은 `planner_entries (user_id, entry_date)` 고유 키 기준으로 upsert 하도록 구성했다.
|
|
- 현재 샌드박스에서는 포트 바인딩 제한 때문에 백엔드 실제 리슨 확인이 막힐 수 있다. `listen EPERM 0.0.0.0:3001`은 코드 자체보다 실행 환경 제약에 가깝다.
|
|
|
|
## 확정된 결정사항
|
|
|
|
- 정적인 HTML보다 Vue가 적합하다.
|
|
날짜 전환, 모드 토글, 사이드 패널 요약, 이후 저장 기능 등 상태 기반 상호작용이 많기 때문이다.
|
|
- TailwindCSS는 Vue를 사용하더라도 반드시 유지해야 하는 스타일링 방식이다.
|
|
- 현재 데이터는 레이아웃과 상호작용 검증을 위한 목업 데이터다.
|
|
- 현재 저장은 `localStorage`를 사용하지만, 적절한 시점에 DB를 붙여 사용자별 저장 구조로 전환해야 한다.
|
|
- 백엔드는 빠른 MVP라면 PocketBase도 가능하지만, 현재 요구사항에서는 전용 Node.js API + DB 구성이 더 유연하다.
|
|
- 이유는 회원가입, 사용자별 문서 관리, 통계 계산, 출력/이미지 저장, 이후 Docker Compose 배포까지 고려하면 서버 로직 제어권이 더 중요하기 때문이다.
|
|
- 상단 날짜는 시스템 날짜 또는 현재 선택된 플래너 날짜 기준으로 자동 표시되어야 한다.
|
|
- `D-DAY`는 지금은 보류이며, 이후 별도의 목표 관리 패널과 연결해서 계산한다.
|
|
- `COMMENT`, `TASKS`, `MEMO`는 모두 입력 가능한 필드가 되어야 한다.
|
|
- TASKS 라벨은 번호만 고정하지 말고 자유 입력이 가능해야 한다.
|
|
- 번호 사용이 필요한 경우를 위해 우측 패널에서 TASKS 라벨을 순번으로 한 번에 채울 수 있어야 한다.
|
|
- `TOTAL TIME`은 타임테이블 선택 상태를 기반으로 자동 계산되어야 한다.
|
|
- 타임테이블은 마우스 드래그로 여러 줄을 지나가더라도 시간 흐름 기준으로 연속 선택되도록 해석해야 한다.
|
|
- 타임테이블 편집은 좌클릭 드래그로 칠하기, 우클릭 드래그로 지우기 방식이 더 자연스럽다.
|
|
- 달력에는 연/월 이동 기능이 필요하다.
|
|
- 내용이 저장된 날짜에는 달력에 빨간 점 표시가 필요하다.
|
|
- 현재 단계의 저장 방식은 `localStorage`이며, 이후 외부 저장소 도입 전까지 기본 저장 경로로 사용한다.
|
|
- 장기적으로는 회원 가입 후 사용자별로 각자 문서를 작성/관리할 수 있어야 한다.
|
|
- 공유 문서 서비스가 아니라, 사용자 개인 보관과 회고 중심의 서비스 구조를 목표로 한다.
|
|
- 사용자는 스스로 통계를 확인할 수 있어야 하고, 특정 날짜에 작성한 문서는 출력 가능해야 한다.
|
|
- 공유를 위해 나중에 이미지 저장 기능도 필요하지만, 실제 출력 품질과 텍스트 선명도는 HTML/CSS 인쇄 레이아웃을 우선 유지하는 편이 좋다.
|
|
- 원격 저장소 `origin`은 `https://git.sori.studio/zenn/planner.sori.studio.git`로 연결되어 있다.
|
|
- 앞으로 버전 체크포인트 커밋은 `v0.1.7 - 작업 요약`처럼 버전 뒤에 짧은 작업 설명을 함께 남기는 형식으로 통일한다.
|
|
- `docker-compose.yml` 초안은 이미 추가되었고, 포트 번호와 실제 외부 공개 범위는 NAS 배포 단계에서 다시 확정하면 된다.
|
|
- `backend/.env.example`에는 기본 `PORT`, `DATABASE_URL`, `CORS_ORIGIN` 예시가 들어 있다.
|
|
|
|
## 다음 권장 작업
|
|
|
|
- `TODO.md` 기준으로 작은 단위씩 구현을 진행한다.
|
|
- 목표나 통계 기능보다 먼저, 플래너 본문의 입력과 상호작용을 우선 구현한다.
|
|
- 통계 화면 구현은 현재 `localStorage` 기반으로 먼저 진행해도 된다.
|
|
- DB는 기능 탐색 속도를 해치지 않는 선에서, 저장 레이어를 분리할 수 있는 적절한 시점에 붙이는 것이 좋다.
|
|
- 현재 기준 추천 백엔드 방향은 `Vue 프론트엔드 + Node.js API + PostgreSQL`이다.
|
|
- Docker 배포를 시작하는 시점이므로 SQLite보다 PostgreSQL을 기본 저장소로 유지하는 편이 낫다.
|
|
- 현재 인증 방식은 Bearer 토큰 기반의 간단한 세션 구조이며, 추후 쿠키/리프레시 토큰 전략으로 확장할 수 있다.
|
|
- 다음 프론트 단계에서는 `src/lib/plannerStorage.js`를 유지하되, 인증 이후 백엔드 저장소 adapter를 추가해서 `localStorage`와 전환 가능하게 만드는 흐름이 좋다.
|
|
- 현재 프론트는 인증만 연결된 상태이고, 플래너 저장은 아직 `localStorage` 기준이다.
|
|
- 로그인 상태에서는 플래너 수정 시 날짜별 서버 저장을 예약하고, 로그인 직후에는 서버 데이터를 먼저 가져오도록 연결하기 시작했다.
|
|
- 현재는 로컬 저장도 계속 유지하면서 서버 저장을 병행하는 과도기 구조다.
|
|
- 로그인 시 서버 플래너 데이터로 `plannerRecords`를 교체하고, 로그아웃 시에는 로컬 저장 기반 데이터로 다시 복귀하도록 정리했다.
|
|
- 이로 인해 다른 사용자 로그인 시 이전 로컬 데이터가 서버 계정 데이터와 섞일 위험을 줄였다.
|
|
- 로그인 상태에서 특정 날짜의 플래너 내용을 완전히 비우면, 서버 저장 대신 해당 날짜 엔트리를 삭제하도록 정리했다.
|
|
- 현재는 로그인 전 플래너 진입을 막고, 인증 후에만 실제 플래너/통계 화면을 사용하도록 변경했다.
|
|
- 클라우드 저장 상태는 헤더가 아니라 오른쪽 하단의 작은 토스트 형태로 표시되도록 변경했다.
|
|
- 저장 완료 토스트는 한 줄짜리의 작은 상태 문구로 줄여서 존재감을 낮췄다.
|
|
- D-DAY는 플래너 안에서 목표를 고르는 구조가 아니라, GOALS 화면에서 목표와 표시 기간을 먼저 설정하는 구조로 정리했다.
|
|
- 플래너 화면 오른쪽 패널에서는 현재 날짜에 적용된 목표가 있을 때만 D-DAY 토글을 켤 수 있고, 목표 검색 UI는 제거했다.
|
|
- 목표는 `active_from`, `active_until` 기간을 가질 수 있고, 현재 날짜가 그 범위에 들어올 때만 플래너 본문 D-DAY 후보가 된다.
|
|
- TASK LABELS도 별도 버튼 2개 대신 동일한 토글 UI로 단순화했다. ON이면 01~15를 채우고 OFF이면 비운다.
|
|
- SETTINGS 화면이 추가되어 닉네임, 이메일, 비밀번호 변경을 분리해서 관리할 수 있다.
|
|
- 백엔드에는 `/api/auth/profile`, `/api/auth/password`, `/api/goals/:goalId` 수정 API가 추가되었다.
|
|
- 백엔드에는 `/api/goals/:goalId` 삭제 API도 추가되었다.
|
|
- 왼쪽 사이드, 플래너 본문 래퍼, 오른쪽 정보 패널 모두 둥근 카드 톤으로 맞춰서 화면 전체의 통일감을 높였다.
|
|
- 플래너 집중 보기에서는 본문과 오른쪽 패널이 각각 독립 스크롤되도록 바뀌어서 동시에 참조하기 쉽다.
|
|
- TASK LABELS, D-DAY 토글은 공통 사이즈의 스위치로 통일했고, `translate` 기반 애니메이션으로 부드럽게 움직이게 했다.
|
|
- 목표 생성 폼은 기본적으로 `표시 시작일 = 오늘`, `표시 종료일 = 목표일` 흐름으로 자동 채워진다.
|
|
- D-DAY 기간은 서로 겹칠 수 없고, 프론트와 백엔드 모두 중복 기간을 감지하면 저장을 막는다.
|
|
- 현재 날짜에 적용된 목표가 있는 경우 D-DAY는 기본적으로 보이고, 해당 날짜에서만 토글로 숨길 수 있다.
|
|
- 목표 상태 개념은 제거했고, 목표는 기간이 있으면 곧바로 D-DAY 후보가 되는 단순 구조로 정리했다.
|
|
- GOALS 화면에서는 수정 중인 카드가 시각적으로 강조되고, 목표 삭제 버튼이 추가되었다.
|
|
- 목표 삭제 시 과거 날짜를 포함해 어떤 날짜에서도 해당 목표는 더 이상 표시되지 않는다.
|
|
- 우측 패널의 `PREV SNAPSHOT`은 선택 날짜 이전의 가장 최근 기록을 읽어서 날짜, 집중 시간, 완료 개수, 코멘트 또는 대표 작업을 보여준다.
|
|
- 우측 패널의 `READ NEXT`는 다음 날 첫 작업, 오늘의 미완료 작업, 오늘 코멘트를 기반으로 이어보기 문구를 자동 생성한다.
|
|
- 백엔드는 SQLite 파일 기반 구조에서 PostgreSQL 연결 구조로 교체되었다.
|
|
- `planner_entries.payload`는 문자열이 아니라 PostgreSQL `JSONB`로 저장되도록 바뀌었다.
|
|
- `docker-compose.yml` 기준으로 `postgres`, `backend`, `frontend(nginx)` 3개 서비스 초안이 추가되었다.
|
|
- 프론트는 nginx에서 `/api`를 백엔드로 프록시하는 구조라서, 배포 시 브라우저가 별도 API 포트를 직접 알 필요가 없다.
|
|
- 프론트 API 클라이언트는 `VITE_API_BASE_URL` 끝에 `/api`가 포함되어 있어도 `/api/api/...` 중복 주소가 생기지 않도록 정규화한다.
|
|
- 로그인 실패 시에는 내부 라우트 문자열이나 서버 경로를 그대로 노출하지 않고, 사용자용 안내 문구만 보여준다.
|
|
- 비로그인 상태에서는 왼쪽 사이드 내비게이션을 숨기고, 중앙 로그인 안내 화면만 보여주도록 정리했다.
|
|
- 배포용 `docker-compose.yml`과 별도로 개발용 `docker-compose.dev.yml`을 추가했다.
|
|
- 개발용 compose는 프론트 `5173`, 백엔드 `3001`, PostgreSQL `5432`를 열고, 소스 마운트 + Vite HMR + Node watch 기반으로 자동 반영된다.
|
|
- 개발/배포 실행 방법은 루트 `README.md`에 먼저 적고, `HANDOFF.md`에는 변경 이유와 주의사항 위주로 남긴다.
|
|
- API 클라이언트는 body가 없는 `GET`, `DELETE` 요청에 `Content-Type: application/json`을 붙이지 않도록 수정했다. 날짜 선택 시 발생하던 `Body cannot be empty...` 오류는 이 문제였다.
|
|
- 날짜 이동 중 목표 자동 보정으로 `goalEnabled`만 꺼지는 경우에는, 실제 내용이 없는 기록이라면 클라우드 동기화 토스트를 띄우지 않도록 정리했다.
|
|
- 집중 보기에서 오른쪽 패널 폭을 넓혀 `1920x1080` 기준 활용도를 높였고, `TASK LABELS / D-DAY / CALENDAR`는 상단 고정 영역으로 올렸다.
|
|
- `STATS`와 `NEXT DAY`는 반반 카드가 아니라 각각 한 줄씩 쓰도록 바꿔서 날짜 길이에 따라 높이가 흔들리는 문제를 줄였다.
|
|
- 미니 달력은 42칸 기준으로 렌더링하고, 요일 헤더를 `SUN ~ SAT` 순서로 고정해서 일요일 시작 달력 기준을 더 명확하게 맞췄다.
|
|
- 비로그인 랜딩 카드는 상단 고정이 아니라 화면 중앙에 오도록 정렬을 수정했다.
|
|
- 현재 환경에서는 Docker 데몬이 꺼져 있어서 `docker compose build` 실검증은 하지 못했고, 데몬 시작 후 다시 확인이 필요하다.
|
|
- 이미지 저장 기능은 추후 `print-only` 또는 별도 export 전용 레이아웃을 기준으로 구현하면 화면/인쇄/공유 결과를 맞추기 쉽다.
|
|
- Docker Compose는 프론트엔드와 백엔드를 함께 올리는 기준으로 설계하되, NAS 환경에 맞는 볼륨과 재시작 정책도 함께 고려한다.
|
|
|
|
## 갱신 규칙
|
|
|
|
- 중요한 결정, 제약, 버그, 작업 방식 변경이 생기면 이 문서에 이어서 반영한다.
|
|
- 다음 작업자가 다시 탐색하지 않아도 되도록 짧고 실무적으로 유지한다.
|