website: 서비스 위키 → 기능 트리 → 노드별 문서, 세 겹으로 엮은 프로젝트 현황판

요약

이번 PR은 코드 변경이 거의 없습니다(인프라 스크립트 권한 fix 1건 제외). 대신 이슈 40여 개를 눈으로 훑어야만 파악되던 "무엇을 만들기로 했는가"와 "어디까지 왔는가"를 세 겹의 문서 체계로 정리했습니다.

1. 서비스 위키 — 논의를 정제한 정식 스펙(정본)
2. README.md 최상단 기능 트리 — 상태 색으로 현황을 한눈에
3. pm/features/ 노드별 문서 — 각 기능의 개요와 실측 진행 상태

작성자 xhae123가 dev → main으로 올렸고, 리뷰 없이 바로 병합됐습니다. 추가 1390줄, 삭제 0줄로 거의 순수 신규 문서 작업입니다.

배경 및 목적

PR 본문에 나온 문제의식이 명확합니다. "무엇을 만들기로 했는지(스펙)"와 "어디까지 왔는지(진행)"가 따로 놀고 있었고, 새로 합류한 사람은 이슈를 일일이 읽어야만 현황을 알 수 있었습니다. 더 골치 아픈 건 "결정만 하고 아무도 안 만드는 중"인 기능이었습니다 — 티켓 자체가 없으니 존재 여부조차 안 보이는 상태였죠.

이걸 해결하기 위해 논의 14건(로그인 정책, 프로젝트 쇼케이스, 지원폼, IA 등)을 GitHub 위키로 옮겨 정식 스펙으로 만들고, 원문은 pm/discussions/에 아카이브했습니다.

구현 내용

세 겹 구조

1. 서비스 위키 = 정식 스펙
개요·원칙 / 아키텍처 결정 / 정보구조·권한 / 기능 명세 4장으로 발행했습니다. "이 기능은 무엇이어야 하는가"에 대한 단일 출처 역할을 하고, 구현이나 논의를 시작하기 전에 여기부터 보게 만들었습니다.

2. README.md 최상단 = 기능 트리
사이트의 모든 화면·기능을 트리로 펼치고 상태 색을 칠했습니다.

🦁 사이트
│
├─ 공개 사이트  /
│  ├─ 🟢 랜딩
│  │   ├─ 🟢 히어로 · 소개 · 통계 · 세션
│  │   └─ 🟡 연간 활동계획
│  ├─ 🔵 프로젝트 쇼케이스
│  ├─ 🟡 멤버 로스터  /members
│  ├─ 🔵 운영진 소개
│  ├─ 🟡 블로그
│  └─ 모집
│      ├─ 🟡 모집 알림 신청
│      └─ ⚪ 지원폼
...

🟢 완료 · 🟡 진행 · 🔵 계획 · ⚪ 미착수 네 단계로 나눴고, 트리의 모든 노드가 상세 문서로 연결되는 링크입니다. 진행률(양)이 아니라 완성도(빠진 것)를 보여주는 지도라는 게 포인트입니다 — 회색(⚪)이 "결정만 하고 착수 안 한 것"으로 바로 눈에 띕니다. 실제로 프로젝트 쇼케이스, 지원폼 같은 기능이 이 색으로 드러났습니다.

3. pm/features/ = 노드별 문서
트리의 각 노드가 문서 하나입니다. pm/features/계정-인증.md를 보면 구조가 잘 드러납니다.

# 계정·인증  🟡 진행

<sup>[⌂ 사이트](README.md)</sup>

## 하위
- 🟡 [로그인](로그인.md)
- 🟡 [첫 로그인 비밀번호 변경](첫로그인-비번변경.md)
...

## 개요
(위키 스펙 기반의 구체적 정의)

## 현재 진행 상태
운영진(어드민) 인증 파운데이션은 배포돼 동작한다. ...
2단(SUPER_ADMIN/ADMIN)이라, 스펙의 역할 4종(일반 유저·멤버 포함)과
멤버 계정 흐름은 아직 코드에 없다.

**관련 이슈·PR**
- #74, #90, #75, #97, #99, #85, #51

각 문서가 개요(스펙 기반 정의) · 진행 상태(관련 이슈/PR을 실제로 읽고 쓴 정성적 현황) · 상하위 내비게이션(빵부스러기 + 하위 목록)이라는 동일한 틀을 갖고 있어서, 어느 노드를 봐도 같은 방식으로 읽힙니다.

변경된 파일

pm/discussions/ 아래 논의 원문 13개, pm/features/ 아래 노드 문서 30여 개, README.md와 CLAUDE.md 수정, 그리고 infra/backup-db.sh 실행권한 fix가 함께 들어갔습니다. 지원자 개인정보가 담긴 pm/applicants/는 PII 이슈로 커밋에서 의도적으로 제외했습니다.

사이드로 딸려온 인프라 fix

커밋 로그를 보면 이 PR은 사실 문서 작업만 담은 게 아닙니다. 맨 앞 커밋이 infra/backup-db.sh 실행권한 문제 수정입니다. git이 이 파일을 한 번도 755로 커밋한 적이 없었고(줄곧 100644), 그동안 서버에서 잘 돌던 건 과거 수동 chmod +x 덕분이었을 뿐이었습니다. 다른 PR(#110) 머지로 서버가 파일을 재체크아웃하면서 권한이 644로 되돌아갔고, cron이 Permission denied로 조용히 실패해 DB 백업 알람이 실제로 울렸습니다. git update-index --chmod=+x로 실행권한 자체를 커밋해 앞으로 어떤 pull/checkout에서도 다시 벗겨지지 않게 고정했고, 이 사고 경위를 pm/docs/learnings.md에 기록했습니다.

기술적 의사결정

상태 색을 "진행률"이 아니라 "완성도"로 설계한 것이 눈에 띄는 결정입니다. 단순히 몇 %가 됐는지가 아니라, ⚪(미착수)를 눈에 띄게 만들어서 "결정은 됐는데 아무도 손 안 댄 것"을 찾아내는 게 목적이라는 걸 명시했습니다. 진행률 바 대신 트리 + 색 조합을 쓴 것도, 프로젝트 규모(부원 ~20명)에서는 대시보드 도구보다 마크다운 트리 하나로 충분하다는 판단으로 보입니다.

위키(스펙) / README(현황) / 노드 문서(상세)를 세 계층으로 분리한 것도 의사결정 포인트입니다. 하나의 문서에 다 몰아넣지 않고, "이게 뭐여야 하는가"와 "지금 어디까지 왔는가"를 물리적으로 다른 곳에 두어 스펙이 바뀔 때와 진행 상황이 바뀔 때 갱신 주기를 분리했습니다.

배운 점 및 개선점

커밋 메시지 중 docs(learnings): 코드 grep만으로 아키텍처 분석하면 pm/docs 결정을 놓친다는 교훈 기록이 흥미롭습니다. 계정정책을 분해하던 중 "Admin/Member 통합 미정"이나 "#94 충돌"을 새로운 리스크로 잘못 보고했는데, 실제로는 product-map.md에 이미 답이 있었고 #94도 이미 홀드 상태였다는 걸 뒤늦게 확인한 겁니다. 코드만 grep해서 판단하면 이미 내려진 pm 결정을 놓친다는 교훈이고, 이게 이번 문서 체계를 만들게 된 실질적 동기 중 하나로 보입니다.

PR 본문에서도 스스로 "이 작업이 드러낸 것"이라며 스펙과 코드가 어긋난 지점 두 곳을 짚었습니다.

• 블로그: 위키는 "승인 없이 바로 게시(사후 숨김)"인데, 코드는 DRAFT → 검수 → 게시(#96) 흐름을 만드는 중
• 계정·인증: 위키는 멤버가 "학번+전화번호"로 로그인하는 걸 전제하는데, 실제 배포는 운영진 "이메일 초대" 기반

문서를 나란히 두고 보니 이런 어긋남이 선명하게 드러났고, 이건 "위키를 고칠지 코드를 스펙에 맞출지" 별도 결정이 필요한 사안으로 남겨뒀습니다. 문서화 자체가 끝이 아니라, 문서화를 하면서 실제 프로덕트의 결정 오류를 찾아내는 도구로 쓰인 셈입니다.

앞으로 개선점으로는 PR 본문에 직접 적혀 있듯, 문서 상태 갱신이 수동(클로드로 재생성)이라는 점과, pm/applicants/처럼 PII가 섞일 수 있는 디렉토리에 대한 .gitignore 처리가 아직 안 돼 있다는 점이 있습니다.