팀 문서 도구는 많습니다. 그래도 이걸 택한 이유는 세 가지입니다.
첫째, 칸반이 데이터다.
카드가 문서 안에 그려진 그림이 아니라 _data/kanban/*.yml 의 데이터입니다.
그래서 같은 데이터가 개인 보드,
14일 타임라인,
오늘 할 일, 대시보드 진행률에 동시에 반영됩니다.
상태 한 줄을 고치면 네 군데가 같이 바뀝니다. 옮겨 적을 일이 없습니다.
둘째, 변경 이력이 git 에 남는다.
“이 일정 언제 바뀌었지” 를 git log 로 찾을 수 있습니다.
14일 프로젝트에서 이건 생각보다 자주 필요합니다.
셋째, 우리가 이미 쓰는 도구다.
새 도구를 배우는 시간이 0입니다. 팀원이 알아야 할 건 status: 한 줄을 고치고 push 하는 것뿐입니다.
_data/kanban/minseok.yml
│
├──▶ /kanban/minseok/ 개인 보드 (4열 칸반 + 날짜별 목록)
├──▶ /kanban/ 전체 칸반 (5인 비교)
├──▶ /schedule/ 14일 타임라인 (날짜 기준 재배열)
└──▶ /today/ · / 오늘 할 일 · 대시보드 진행률
status 를 doing 으로 바꾸면 네 화면이 전부 갱신됩니다.
진행률 막대도 같은 데이터에서 계산됩니다.
문서 사이트는 안 읽히면 없는 것과 같습니다. 그래서:
word-break: keep-all) — 단어 중간에서 안 끊깁니다main 에 push 하면 GitHub Actions 가 Jekyll 4 로 빌드해서 Pages 에 올립니다.
Pages 기본 Jekyll(3.10) 대신 Actions 를 쓴 건 로컬과 버전을 맞추기 위해서입니다.
빌드가 깨져도 이전 버전이 그대로 서비스되니, 겁내지 말고 고치고 push 하면 됩니다.
이 사이트 사용법에 정리했습니다. 팀원이 알아야 할 것은 두 가지뿐입니다 — 내 카드 상태 바꾸기, 데브로그 쓰기.
]]>9월 16일 프로덕션 오픈까지 14일입니다. 오늘 킥오프에서 정한 것은 세 가지입니다.
9/16 은 못 밉니다. 그래서 조절 변수는 만들 것의 양 하나뿐입니다. D-7(9/09) 알파 시연에서 남은 분량이 감당 안 되면 그날 저녁에 잘라냅니다. 무엇부터 자를지는 범위 문서에 미리 순서를 정해뒀습니다. 그 자리에서 논쟁하면 반나절이 날아가기 때문입니다.
이게 이번 일정의 핵심 장치입니다. 계약이 나오기 전까지 김충식·이은상은 화면 껍데기밖에 못 만듭니다. 계약이 나오는 순간 3인이 동시에 달릴 수 있습니다.
완벽한 계약을 기다리지 않습니다. 9/04 에 v1 을 내고, 통합에서 어긋나는 건 D-9 에 고칩니다.
done 은 PM 만 붙인다각자 “다 했습니다”의 기준이 다릅니다. 누구에겐 로컬에서 되는 것이고, 누구에겐 스테이징에서 앱까지 되는 것입니다.
그래서 담당자는 review 까지만 올리고, PM 이 카드의 완료 기준(DoD) 을 직접 확인한 뒤
done 으로 내립니다. 절차는 리뷰 & 숙지 사이클에 있습니다.
기획서 v6 와 컨셉 영상이 이 레포에 없습니다.
둘 다 PM 로컬(macOS)에만 있어서, 지금 사이트의 서비스 정의·기능 목록·디자인 토큰은
com.remakeday 레포의 실제 구조에서 역으로 정리한 것입니다.
이걸 기다리며 멈추지는 않습니다. 대신:
리스크 R1로 등록했습니다.
오늘 할 일 페이지에 16건이 있습니다. 오늘의 관문은 ERD 초안 + API 계약 v0 + 레포·인프라 스켈레톤이 전부 올라가는 것입니다.
오늘 정한 규약(네이밍·브랜치·API 계약)은 9/16 까지 바꾸지 않습니다. 14일 동안 규약을 다시 논의하는 시간이 곧 기능을 못 만드는 시간입니다.
]]>