# 인수인계 메모 ## 프로젝트 개요 - 프로젝트명: 10 Minute Planner 웹 UI - 기술 스택: Vue 3 + Vite + TailwindCSS + JavaScript - 현재 기준 버전: `v0.1.7` - 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에서 구동할 예정이다. ## 현재 구현 상태 - 메인 화면 셸: `src/App.vue` - 플래너 종이 레이아웃: `src/components/PlannerPage.vue` - 우측 달력 컴포넌트: `src/components/MiniCalendar.vue` - 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로 교체하기 쉬운 구조로 정리 중이다. - 상단 전환 버튼으로 `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 세로에 가깝게 키우고 배율을 크게 올려 빈 여백을 줄이는 방향으로 맞추고 있다. ## 확정된 결정사항 - 정적인 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`도 함께 작성해야 하며, 포트 번호와 서비스 구성은 추후 사용자와 확정한다. ## 다음 권장 작업 - `TODO.md` 기준으로 작은 단위씩 구현을 진행한다. - 목표나 통계 기능보다 먼저, 플래너 본문의 입력과 상호작용을 우선 구현한다. - 통계 화면 구현은 현재 `localStorage` 기반으로 먼저 진행해도 된다. - DB는 기능 탐색 속도를 해치지 않는 선에서, 저장 레이어를 분리할 수 있는 적절한 시점에 붙이는 것이 좋다. - 현재 기준 추천 백엔드 방향은 `Vue 프론트엔드 + Node.js API + SQLite 또는 PostgreSQL`이다. - 이미지 저장 기능은 추후 `print-only` 또는 별도 export 전용 레이아웃을 기준으로 구현하면 화면/인쇄/공유 결과를 맞추기 쉽다. - Docker Compose는 프론트엔드와 백엔드를 함께 올리는 기준으로 설계하되, NAS 환경에 맞는 볼륨과 재시작 정책도 함께 고려한다. ## 갱신 규칙 - 중요한 결정, 제약, 버그, 작업 방식 변경이 생기면 이 문서에 이어서 반영한다. - 다음 작업자가 다시 탐색하지 않아도 되도록 짧고 실무적으로 유지한다.