Requirements

• 사용자(user): 회원(member), 비회원 총칭
• 작성자: 회원 중에서 그 글을 작성한 사람

1. Backend

phase1: 로컬에서 혼자 사용

• 사용자가 문서를 읽을 수 있어야 한다
• 서버는 문서를 마크다운 문법에 따라 플랫폼에 맞는 형식으로 번역할 수 있어야 한다
  • 일단 HTML만 지원하고 추상화는 하지 말 것.
• 사용자는 문서를 검색할 수 있어야 한다
  • 우선 제목으로는 당연히 되어야 함
  • 내용 검색은 인프라 구성에 따라 성능이 크게 달라질 것: 파일시스템 - DB - 검색엔진
    • 파일시스템 단계(phase 1)에서는 인터페이스만 만들고 구현하지 않는 것도 고려.
• 사용자가 문서의 수정 히스토리를 구체적 내용까지 확인할 수 있어야 한다
• 회원은 문서를 작성할 수 있어야 한다
• 회원이 자신의 문서와 남의 문서를 개정할 수 있어야 한다
• 회원은 자신의 문서를 삭제할 수 있어야 한다
• 서버는 모든 유스케이스를 웹 형식으로 서빙해야 한다
• 서버는 에러가 발생할 경우 적절한 응답을 내려주고 이에 대한 로그를 남겨야 한다
• 서버는 모든 데이터를 로컬 파일시스템을 통해 CRUD해야 한다 서버는 모든 데이터를 DBMS를 통해 CRUD해야 한다
  • 파일시스템을 쓴다고 해서 유의미한 이점이 없음. 그냥 MySQL 쓰다가 나중에 mysqldump 명령어로 데이터만 옮기면 그만.
• 드랍박스 등의 서비스를 사용하여 둘 이상의 PC에서 DB 데이터를 공유할 수 있어야 한다

phase2: 사용성 개선

• 사용자는 지금 보고 있는 문서를 참조하고 있는 모든 문서의 목록을 확인할 수 있어야 한다
• 회원은 문서를 작성/개정할 때 카테고리, 태그, 시리즈 정보를 부여할 수 있어야 한다
  • 카테고리: 한 문서에 하나만 달 수 있음
  • 태그: 한 문서에 여러 개를 달 수 있음
  • 시리즈: 한 문서는 하나의 시리즈에만 들어갈 수 있으며, 시리즈에 포함된 문서는 순서를 지님
• 회원은 문서를 작성/개정할 때 이미지 업로드를 할 수 있어야 한다
• 서버는 로컬 데이터를 주기적으로 백업할 수 있어야 한다

phase3: 서버에 올려서 사용

• 사용자는 로그인과 로그아웃이 가능해야 한다
  • 구체적인 로그인 방법(JWT 등)을 인프라 레이어로 격리해볼 것
• 회원이 문서를 작성할 때 마크다운 문법 및 각주 문법을 사용할 수 있어야 한다
  • FE 편집기가 phase3에서 처음 등장하므로, 파일 업로드를 통해 문서를 작성/개정하는 이전 단계에는 실효성이 없는 기능이다.
• 관리자는 게시글을 비공개 처리할 수 있어야 한다
• 서버는 모든 요청 인입 기록을 로그로 남겨야 한다

phase4-1: SDK

• 회원은 SDK 형태로 웹페이지에 특정 게시글을 모아 포팅할 수 있어야 한다
  • 어디까지 허용할지 생각해볼 것. 자신이 작성자인 글만 가능하게 할지, 제한을 아예 풀지 등등
  • 나중에 블로그로 이어지게 하기 위함
  • 태그, 카테고리 등의 기능을 지원하기 위해 무엇을 추가해야 할지 생각해 볼 것
• 회원은 자신의 글의 열람 통계 정보를 확인할 수 있어야 한다
  • 유입 플랫폼
  • 유입 날짜
  • 유입 국가, 도시
  • 읽은 사람이 회원인 경우 구체적 회원 정보

phase4-2: Wiki

• 사용자는 회원가입이 가능해야 한다
  • 깃허브 OAuth 고려
• 회원은 회원탈퇴가 가능해야 한다
• 회원은 자신이 자신이 작성한 문서에 대한 타인의 열람 및 개정 권한을 관리할 수 있어야 한다
• 회원은 남의 문서를 삭제할 수는 없어야 한다
• 회원은 자신의 문서에 타인에 의한 변경이 있을 때 노티를 받을 수 있어야 한다
• 한 회원이 문서를 개정하기 시작하여 완료하기 전에 다른 회원이 문서를 먼저 개정하면, 문서 개정에 실패해야 한다
  • 스냅샷 버전을 가지고 체크가 이루어져야 한다.
• 회원은 다른 회원에게 자신의 문서에 대한 개정 권한을 부여할 때 세부 내용을 정할 수 있어야 한다
  • 개정시 다른 회원의 동의가 필요한가 (PR, approve)
  • 개정시 기여자를 제외하고 최소 몇 명의 회원의 동의가 필요한가
  • 개정시 최초 작성자의 동의가 필요한가
• 회원이 다른 회원의 동의가 필요한 문서를 개정할 경우, 변경사항이 즉각 반영되어서는 안되며, 다른 회원에게 개정 승인 요청(PR)이 먼저 전달되어야 한다
• 회원은 자신이 작성한, 또는 자신이 기여한 문서에서 만들어진 개정 요청의 목록을 모아 볼 수 있어야 한다
• 회원은 다른 회원의 개정 요청을 확인할 수 있어야 하고, 자신이 개정 권한이 있는 문서인 경우, 승인, 거절, 코멘트를 할 수 있어야 한다
• 회원은 자신이 작성한, 또는 자신이 기여한 문서에서 링크의 끊어짐이 발생했을 때, 이를 알림센터에서 확인할 수 있어야 한다
• 회원은 자신이 작성한, 또는 자신이 기여한 문서에서 개정 요청이 발생했을 때, 이를 알림센터에서 확인할 수 있어야 한다

phase5: 인프라 개선 (DB 마이그레이션 등)

• 서버는 모든 데이터를 DBMS를 통해 관리할 수 있어야 한다
• 서버는 DB 데이터를 주기적으로 백업할 수 있어야 한다
• 서버에 대한 헬스체크가 이루어져야 하며, 헬스체크 실패시 이를 바로 인지할 수 있는 알림이 전달되어야 한다
• SSO: SDK에서는 설정에 따라 위키의 회원정보를 그대로 가져올 수도 있어야 한다
• 사용자는 검색엔진을 통해 노출된 글을 볼 수 있어야 한다
• 사용자는 본문 검색시 결과를 재빠르게 볼 수 있어야 한다 (인프라 레이어에서 검색 구현 방식 개선)
• 서버는 documents의 PK와 노출용 key가 분리하여 저장해야 한다
• 회원은 []() 문법에 url 대신 노출용 PK를 넣어서 내부 링크를 대신할 수 있어야 한다

2. Frontend

phase1: 로컬에서 혼자 사용

• 사용자는 문서의 목록을 볼 수 있어야 한다
• 사용자는 가독성 좋은 문서를 열람할 수 있어야 한다
• 사용자는 문서를 제목 또는 내용으로 검색할 수 있어야 한다
• 회원은 파일 업로드 방식으로 문서를 작성할 수 있어야 한다
• 회원은 파일 업로드 방식으로 문서를 개정할 수 있어야 한다
• 회원은 문서를 삭제할 수 있어야 한다

phase2: 사용성 개선

• 사용자는 문서의 목록을 보기 좋게 볼 수 있어야 한다
  • 분류 기준
    • 전체
    • 특정 카테고리에 속하는 문서
    • 특정 태그에 속하는 문서
    • 특정 시리즈에 속하는 문서
  • 정렬 기준
    • 최근 생성 순
    • 최근 수정 순
• 사용자는 카테고리 트리를 볼 수 있어야 하며, 검색도 가능해야 한다
• 사용자는 태그 리스트를 볼 수 있어야 하며, 검색도 가능해야 한다
• 사용자는 시리즈 리스트를 볼 수 있어야 하며, 검색도 가능해야 한다
• 사용자가 내부 링크, 외부 링크, 끊긴 링크를 구별할 수 있어야 한다
• 사용자는 md 파일을 업로드하여 문서를 작성/개정할 수 있어야 한다
• 사용자가 문서 히스토리를 확인할 때, 각 버전의 변경점을 시각적으로 확인할 수 있어야 한다
• 사용자가 문서를 열람할 때 카테고리, 태그, 시리즈 정보에 따라 문서 상단에 틀 정보가 만들어져야 한다
• 사용자는 틀 정보를 접거나 펼칠 수 있어야 하며, 기본적으로는 접혀 있어야 한다
• 사용자는 에러 발생시 적절하게 포장된 화면을 볼 수 있어야 한다
• 사용자는 데이터 로딩시에 적절하게 포장된 화면을 볼 수 있어야 한다
• 사용자는 심미적인 화면을 볼 수 있어야 한다 (최소한의 디자인 시스템)
  • 참고: https://www.sungikchoi.com/blog/styled-components-design-system-1

phase3: 서버에 올려서 사용

• 사용자는 로그인과 로그아웃이 가능해야 한다
• 회원이 문서를 편집기를 통해 작성 및 개정할 때, 렌더링된 결과를 실시간으로 볼 수 있어야 한다
• 회원이 문서를 편집기를 통해 개정할 때, 이전 버전과의 차이를 볼 수 있어야 한다
• 사용자는 서버 에러가 발생하여 화면 렌더링이 되지 않을 때 일관성 있는 에러 화면을 볼 수 있어야 한다

phase4-1: SDK

• SDK를 사용하는 개발자는 디자인 시스템을 유연하게 갈아끼울 수 있어야 한다

phase4-2: Wiki

• 사용자는 회원가입이 가능해야 한다
  • 깃허브 OAuth 고려
• 회원은 회원탈퇴가 가능해야 한다
• 회원은 회원정보 수정이 가능해야 한다
• 회원은 자신이 작성한, 또는 자신이 기여한 문서에서 만들어진 개정 요청의 목록을 모아 볼 수 있어야 한다
• 회원은 다른 회원의 개정 요청을 확인할 수 있어야 하고, 자신이 개정 권한이 있는 문서인 경우, 승인, 거절, 코멘트를 할 수 있어야 한다
• 회원은 알림 센터에서 알림 목록을 볼 수 있어야 하며, 확인한 알림과 확인하지 않은 알림을 구분할 수 있어야 한다
• 회원은 알림 센터에서 알림을 눌러, 적절한 페이지로 랜딩될 수 있어야 한다
• 서버는 회원이 입력한 마크다운 텍스트에서 위험한 스크립트의 실행 가능성을 배제해야 한다
  • ex) <script> 태그

phase5: 디테일 개선

• 사용자는 검색시 자동완성 기능을 이용할 수 있어야 한다
• 사용자는 []() 문법에 url 대신 노출용 PK가 들어간 글이어도 정상적으로 연결된 내부링크를 클릭할 수 있어야 한다

3. Plan

phase1~3

• MVP

phase4

• 4-1과 4-2 중 어느 쪽을 먼저 진행하든 상관 없다.
• 4-1과 4-2가 모두 완성되고 나면 phase5로 넘어간다.
• 4-1이 완성되고 나면 SDK 포팅을 위한 블로그 개발 작업을 우선 진행해도 괜찮다.

phase5

• phase5부터가 실 사용자의 트래픽을 서버가 버텨내야 하는 단계이므로, 모니터링을 하면서 적절히 필요한 것들을 붙여나가면 된다.