커뮤니티 공식 사이트 기능 확장 로드맵
배경
NotionNext는 현재 개인 블로그, 포트폴리오, 지식 베이스, 가벼운 콘텐츠 사이트에 매우 잘 맞습니다. 하지만 “커뮤니티 공식 사이트” 용도를 맡으려 하면 몇 가지 구조적인 한계에 금방 부딪힙니다.
- 단일 작성자 모델이 강함
현재 많은 테마와 SEO 메타데이터는 기본적으로AUTHOR,AVATAR,BIO라는 단일 인물 필드를 중심으로 동작합니다. - 조직 정보와 콘텐츠 정보가 계층화되어 있지 않음
커뮤니티 구성원, 이벤트, 신청 폼, 모집 정보, 콘텐츠 글이 모두 일반 페이지/글처럼 처리되어 데이터 역할 구분이 명확하지 않습니다. - 폼과 이벤트의 운영 흐름이 약함
이벤트를 보여줄 수는 있지만, 이벤트 발행, 신청 수집, 구성원 표시, 상태 표시를 하나의 흐름으로 다루는 표준 방식이 부족합니다. - 다수 인물 표시 기능이 부족함
구성원 목록, 아바타 미리보기, 구성원 bio, 역할 태그, 소셜 링크, 구성원 상세 페이지 같은 일반적인 커뮤니티 모듈이 부족합니다.
즉, NotionNext는 현재 “콘텐츠 중심의 커뮤니티 공식 사이트 프레임워크”라기보다 “블로그 템플릿 모음”에 더 가깝습니다.
적용 시나리오
이 방향은 다음에 적합합니다.
- 오픈소스 커뮤니티 공식 사이트
- 학교/캠퍼스 조직 공식 사이트
- 크리에이터 커뮤니티 홈
- DAO / 커뮤니티 홈
- 살롱 / meetup 조직 공식 사이트
- 이벤트, 구성원, 콘텐츠, 모집이라는 네 종류의 정보를 가진 가벼운 운영 사이트
현재 기능과 부족한 점
이미 있는 기반
- 통합 데이터 계층이 있습니다:
lib/db/SiteDataApi.js - 테마 계층이 통일된
props를 소비할 수 있습니다. starter의 Team 컴포넌트처럼 일부 “팀 섹션”의 초기 형태가 있습니다.- 설정 기반 동작과 Notion Config 메커니즘이 있습니다.
- 라우팅과 정적 생성 기능이 있어 목록 페이지와 상세 페이지를 만들기에 적합합니다.
주요 부족한 점
1. 구성원 관리
부족한 기능:
- 구성원 컬렉션 데이터 모델
- 구성원 아바타 목록 / 카드 그리드
- 구성원 bio / role / social links
- 구성원 상세 페이지
- 구성원과 콘텐츠의 연결 관계
2. 커뮤니티 콘텐츠 계층화
기존 콘텐츠를 최소한 네 종류로 나누는 것을 권장합니다.
Post: 일반 콘텐츠 글Member: 커뮤니티 구성원Event: 이벤트Page: 정적 설명 페이지
구현할 때 Member / Event는 기존 Notion 페이지 type 규칙, lib/db/SiteDataApi.js의 데이터 계약, 테마 props와 라우팅의 기존 패턴에 맞춰야 합니다. 글/페이지 흐름과 단단히 갈라지는 별도 흐름은 피합니다.
모든 것을 계속 Post/Page 안에 섞어 두면, 이후 테마, 검색, SEO, 목록 페이지, 내비게이션, 사이드바 유지보수가 점점 어려워집니다.
3. 이벤트 발행과 표시
부족한 기능:
- 이벤트 목록 페이지
- 이벤트 상세 페이지
- 시간 / 장소 / 신청 마감 시간 / 상태 필드
- 종료됨 / 진행 중 / 곧 시작 상태 관리
- 이벤트와 폼 링크의 표준화된 표시
4. 폼 수집
부족한 기능:
- 신청 진입점 필드
- 외부 폼 임베드 / 이동 규칙
- 폼형 페이지의 UI 규칙
- 수집 결과 연동 설명
NotionNext가 완전한 백엔드를 직접 구현할 필요는 없습니다. 더 현실적인 방식은 다음과 같습니다.
- 먼저 외부 폼 링크 / 임베드를 지원합니다.
- 이후 Airtable / Notion Form / Tally / Feishu Form / 자체 API 연동을 검토합니다.
5. 다중 작성자 표시
현재 AUTHOR / AVATAR / BIO는 기본적으로 단일 인물 사이트 모델입니다. 커뮤니티 공식 사이트에는 다음이 더 필요합니다.
- 페이지 단위 작성자 카드
- 다중 작성자/다중 유지보수자
- 구성원 아바타 미리보기
- 구성원 소개와 역할
- 콘텐츠 작성자와 조직 구성원의 분리
권장 데이터 모델
Member
권장 최소 필드:
slugnameavatarbioroletagssocialLinksjoinedDatestatusfeatured
Event
권장 최소 필드:
slugtitlesummarycoverstartDateendDatelocationeventStatusregistrationUrlregistrationEmbedUrlorganizerspeakersfeatured
Post
기존 글 모델은 유지하되, 다음을 추가 지원하는 것을 권장합니다.
authors(배열)relatedMembersrelatedEvents
권장 기능 분리 순서
Phase 1: 커뮤니티 표시 기본 기능
목표: 먼저 “커뮤니티 공식 사이트처럼 보이게” 합니다.
권장 PR:
구성원 컬렉션 지원
- 데이터 계층에서
Member인식 allMembers제공- 구성원 상세 페이지 기본 라우트 지원
- 데이터 계층에서
구성원 카드 목록 컴포넌트
- 아바타
- 이름
- bio
- role
- 소셜 링크
이벤트 컬렉션 지원
- 데이터 계층에서
Event인식 allEvents제공- 이벤트 목록/상세 페이지 기본 기능
- 데이터 계층에서
Phase 2: 커뮤니티 운영 기능
목표: 먼저 “이벤트를 발행하고, 신청을 받고, 조직을 표시할 수 있게” 합니다.
권장 PR:
이벤트 상태 필드 규칙
- upcoming
- ongoing
- ended
- cancelled
신청 진입점 기능
registrationUrlregistrationEmbedUrlregistrationNote
콘텐츠와 조직 정보 계층화
- 내비게이션, 검색, 사이트맵에서
Post / Member / Event / Page구분
- 내비게이션, 검색, 사이트맵에서
Phase 3: 커뮤니티 콘텐츠 협업 기능
목표: 먼저 “여러 사람이 협업해 콘텐츠를 발행할 수 있게” 합니다.
권장 PR:
다중 작성자 지원
authors배열- 작성자 카드
- 작성자를 구성원 페이지로 연결
콘텐츠 연결
- 글과 구성원 연결
- 글과 이벤트 연결
- 구성원 페이지에서 콘텐츠 기여 표시
우선 제안할 Issue
가장 먼저 제안할 만한 것은 “크고 완전한 커뮤니티 시스템”이 아니라, 아래 세 가지 고가치 issue입니다.
Member / Event 콘텐츠 타입 지원
- 모든 커뮤니티 시나리오의 기반입니다.
- 기술적으로도 데이터 계층부터 시작하기 가장 적합합니다.
다중 작성자와 구성원 프로필 카드 지원
- 블로그, 팀 사이트, 커뮤니티 사이트 모두에 가치가 있습니다.
- 재사용 범위가 가장 넓고 업스트림에 수용되기 쉽습니다.
이벤트 페이지와 신청 진입점 필드 지원
- 기능 경계가 명확합니다.
- 점진적인 PR로 나누기에 적합합니다.
권장 MVP Issue 문안 방향
문제를 다음처럼 설명할 수 있습니다.
NotionNext는 현재 개인 블로그를 잘 지원하지만, 커뮤니티 공식 사이트/조직 공식 사이트 시나리오 지원은 부족합니다. 데이터 계층과 테마 계약에
Member/Event타입을 추가하고, 구성원 프로필 카드, 다중 작성자, 이벤트 신청 진입점 같은 기본 기능을 도입해 프로젝트가 단일 작성자 블로그뿐 아니라 다중 구성원 커뮤니티 사이트에도 적합해지도록 제안합니다.
이 표현의 장점:
- 요구가 너무 흩어져 보이지 않습니다.
- 특정 사이트 하나만 위한 커스터마이징처럼 보이지 않습니다.
- “프레임워크 공통 기능 강화”에 더 가깝습니다.
문서화 권장 사항
이 문서는 이 방향의 전체 로드맵으로 사용할 수 있습니다. 이후 실제 구현으로 이어진다면 더 세부적인 설계 문서를 추가하는 것을 권장합니다. 예:
docs/COMMUNITY_SITE_SCHEMA.md(필드와 데이터 계약)docs/COMMUNITY_SITE_EXAMPLES.md(테마와 Notion 설정 예시)
